매개변수 변경하기
이 문서의 목적은 TON 블록체인의 구성 매개변수에 대한 기본적인 설명을 제공하고, 다수의 검증인의 합의를 통해 이러한 매개변수를 변경하는 단계별 지침을 제시하는 것입니다.
구성 제안에 대한 검증인의 투표에 대해 설명하는 섹션의 풀노드-하투(로우레벨)와 라이트 클라이언트, 검증인-하투(로우레벨)에서 설명한 것처럼 독자들은 이미 Fift, Lite Client 등에 익숙하다고 가정하겠습니다.
1. 구성 매개변수
구성 매개변수**는 검증자 및/또는 TON 블록체인의 기본 스마트 컨트랙트의 동작에 영향을 미치는 특정 값입니다. 모든 구성 매개변수의 현재 값은 마스터체인 상태의 특수한 부분으로 저장되며, 필요할 때 현재 마스터체인 상태에서 추출됩니다. 따라서 특정 마스터체인 블록과 관련하여 구성 매개변수의 값을 말하는 것이 합리적입니다. 각 샤드체인 블록에는 알려진 최신 마스터체인 블록에 대한 참조가 포함되어 있으며, 해당 마스터체인 상태의 값은 이 샤드체인 블록에 대해 활성화된 것으로 간주되어 생성 및 유효성 검사 중에 사용됩니다. 마스터체인 블록의 경우, 이전 마스터체인 블록의 상태가 활성 구성 매개변수를 추출하는 데 사용됩니다. 따라서 마스터체인 블록 내에서 일부 구성 매개변수를 변경하려고 해도 변경 사항은 다음 마스터체인 블록에 대해서만 활성화됩니다.
각 구성 매개변수는 구성 매개변수 인덱스 또는 간단히 인덱스라고 하는 부호화된 32비트 정수 인덱스로 식별됩니다. 구성 매개변수의 값은 항상 셀입니다. 일부 구성 매개변수가 누락될 수 있으며, 이 경우 해당 매개변수의 값은 Null로 간주되기도 합니다. 또한 항상 존재해야 하는 필수 구성 매개변수 목록이 있으며, 이 목록은 구성 매개변수 #10에 저장됩니다.
모든 구성 매개변수는 구성 사전, 즉 부호화된 32비트 키(구성 매개변수 인덱스)와 정확히 하나의 셀 참조로 구성된 값으로 구성된 해시맵으로 결합됩니다. 즉, 구성 사전은 TL-B 유형(HashmapE 32 ^Cell)의 값입니다. 실제로 모든 구성 매개변수 모음은 마스터체인 상태에 TL-B 타입의 ConfigParams 값으로 저장됩니다:
_ config_addr:bits256 config:^(Hashmap 32 ^Cell) = ConfigParams;
구성 사전과 별도로 ConfigParams에는 마스터체인에 있는 구성 스마트 컨트랙트의 256비트 주소인 config_addr이 포함되어 있음을 알 수 있습니다. 구성 스마트 컨트랙트에 대한 자세한 내용은 나중에 제공될 예정입니다.
모든 구성 매개변수의 활성 값을 포함하는 구성 사전은 코드가 트랜잭션에서 실행될 때 모든 스마트 콘트랙트가 특수 TVM 레지스터 c7을 통해 사용할 수 있습니다. 보다 정확하게는 스마트 컨트랙트가 실행될 때 c7은 튜플로 초기화되며, 이 튜플의 유일한 요소는 현재 유닉스 시간(블록 헤더에 등록된 대로)과 같이 스마트 컨트랙트 실행에 유용한 여러 "컨텍스트" 값을 가진 튜플입니다. 이 튜플의 열 번째 항목(즉, 0 기반 인덱스 9를 가진 항목)에는 구성 사전을 나타내는 셀이 포함되어 있습니다. 따라서 TVM 명령어 PUSH c7; FIRST; INDEX 9 또는 이와 동등한 명령어인 CONFIGROOT를 통해 액세스할 수 있습니다. 실제로 특수 TVM 명령어인 CONFIGPARAM과 CONFIGOPTPARAM은 이전 작업을 사전 조회와 결합하여 구성 매개변수를 인덱스별로 반환합니다. 이러한 지침에 대한 자세한 내용은 TVM 설명서를 참조하세요. 여기서 중요한 점은 모든 스마트 콘트랙트(마스터체인 또는 샤드체인)에서 모든 구성 매개변수에 쉽게 접근할 수 있으며, 스마트 콘트랙트가 이를 검사하고 특정 검사를 수행하는 데 사용할 수 있다는 것입니다. 예를 들어, 스마트 콘트랙트는 구성 매개변수에서 워크체인 데이터 저장 가격을 추출하여 사용자가 제공한 데이터 청크를 저장하는 데 드는 가격을 계산할 수 있습니다.
구성 매개변수의 값은 임의적이지 않습니다. 실제로 구성 매개변수 인덱스 i가 음수가 아닌 경우, 이 매개변수의 값은 TL-B 유형(ConfigParam i)의 유효한 값이어야 합니다. 이 제한은 유효성 검사기에 의해 적용되며, 해당 TL-B 유형의 유효한 값이 아니면 음수가 아닌 인덱스가 있는 구성 매개변수의 변경을 허용하지 않습니다.
따라서 이러한 파라미터의 구조는 소스 파일 crypto/block/block.tlb에서 결정되며, 여기서 (ConfigParam i)는 i의 다른 값에 대해 정의됩니다. 예를 들어
_ config_addr:bits256 = ConfigParam 0;
_ elector_addr:bits256 = ConfigParam 1;
_ dns_root_addr:bits256 = ConfigParam 4; // root TON DNS resolver
capabilities#c4 version:uint32 capabilities:uint64 = GlobalVersion;
_ GlobalVersion = ConfigParam 8; // all zero if absent
구성 매개변수 #8에는 참조가 없는 셀과 정확히 104개의 데이터 비트가 포함되어 있음을 알 수 있습니다. 처음 4비트는 11000100이어야 하며, 현재 활성화된 "글로벌 버전"이 있는 32비트가 저장되고, 현재 활성화된 기능에 해당하는 플래그가 있는 64비트 정수가 이어집니다. 모든 구성 매개변수에 대한 자세한 설명은 TON 블록체인 문서의 부록에 제공될 예정이며, 현재로서는 crypto/block/block.tlb에서 TL-B 체계를 검사하고 검증자 소스에서 다른 매개변수가 어떻게 사용되는지 확인할 수 있습니다.
음수 인덱스가 아닌 구성 매개변수와 달리 음수 인덱스가 있는 구성 매개변수는 임의의 값을 포함할 수 있습니다. 적어도 값에 대한 제한은 유효성 검사기에 의해 적용되지 않습니다. 따라서 블록 생성에 중요하지는 않지만 일부 기본 스마트 콘트랙트에서 사용되는 중요한 정보(예: 특정 스마트 콘트랙트가 작동을 시작해야 하는 유닉스 시간)를 저장하는 데 사용할 수 있습니다.
2. 구성 매개변수 변경하기
구성 매개변수의 현재 값은 마스터체인 상태의 특수한 부분에 저장된다고 이미 설명드렸습니다. 어떻게 변경될 수 있을까요?
실제로 마스터체인에는 설정 스마트 콘트랙트라는 특별한 스마트 콘트랙트가 존재합니다. 이 주소는 앞서 설명한 '컨피그 파라미터'의 '컨피그_addr' 필드에 의해 결정됩니다. 데이터의 첫 번째 셀 참조에는 모든 구성 매개변수의 최신 사본이 포함되어야 합니다. 새로운 마스터체인 블록이 생성되면, 구성 스마트 콘트랙트는 해당 주소인 config_addr로 조회되고, 데이터의 첫 번째 셀 참조에서 새로운 구성 사전이 추출됩니다. 몇 가지 유효성 검사(예: 음수가 아닌 32비트 인덱스 i를 가진 값이 실제로 TL-B 유형(ConfigParam i)의 유효한 값인지 확인) 후 검증자는 이 새 구성 사전을 ConfigParams가 포함된 마스터체인 부분에 복사합니다. 이는 모든 트랜잭션이 생성된 후에 수행되므로 구성 스마트 컨트랙트에 저장된 새 구성 사전의 최종 버전만 검사됩니다. 유효성 검사에 실패하면 "참" 구성 사전은 변경되지 않은 상태로 유지됩니다. 이러한 방식으로 구성 스마트 컨트랙트는 구성 매개변수의 유효하지 않은 값을 설치할 수 없습니다. 새 구성 사전이 현재 구성 사전과 일치하면 유효성 검사가 수행되지 않고 변경되지 않습니다.
이러한 방식으로 구성 매개변수에 대한 모든 변경은 구성 스마트 컨트랙트에 의해 수행되며, 구성 매개변수 변경 규칙을 결정하는 것은 해당 코드입니다. 현재 구성 스마트 컨트랙트는 구성 매개변수 변경을 위해 두 가지 모드를 지원합니다:
- 구성 스마트 컨트랙트의 데이터에 저장된 공개 키에 해당하는 특정 개인 키로 서명된 외부 메시지를 사용합니다. 이는 운영자가 구성 매개변수의 값을 쉽게 변경할 수 있기 때문에 공개 테스트넷과 한 주체가 관리하는 소규모 비공개 테스트 네트워크에서 사용되는 방식입니다. 이 공개 키는 이전 키로 서명된 특별한 외부 메시지에 의해 변경될 수 있으며, 이 공개 키가 0으로 변경되면 이 메커니즘은 비활성화된다는 점에 유의하세요. 따라서 출시 직후 미세 조정을 위해 사용했다가 영구적으로 비활성화할 수 있습니다.
- 이후 검증인이 찬성 또는 반대 투표를 하는 '구성 제안'을 생성하는 방식입니다. 일반적으로 구성 제안은 전체 검증인의 3/4 이상(가중치 기준)의 표를 모아야 하며, 한 라운드뿐만 아니라 여러 라운드에 걸쳐 (즉, 여러 검증인 세트가 제안된 매개변수 변경을 확인해야 함) 투표를 진행해야 합니다. 이것이 TON 블록체인 메인넷에서 사용할 분산 거버넌스 메커니즘입니다.
구성 매개변수를 변경하는 두 번째 방법에 대해 더 자세히 설명해드리겠습니다.
3. 구성 제안서 만들기
새로운 구성 제안서에는 다음 데이터가 포함됩니다:
- 변경할 구성 매개 변수의 인덱스
- 구성 매개 변수의 새 값(또는 삭제할 경우 Null)
- 제안의 만료 유닉스 시간
- 플래그는 제안이 중요한지 여부를 나타냅니다.
- 현재 값의 셀 해시가 있는 선택적 이전 값 해시 (현재 값에 표시된 해시가 있는 경우에만 제안을 활성화할 수 있음)
마스터체인에 지갑이 있는 사람은 누구나 적절한 수수료를 지불하면 새로운 구성 제안을 생성할 수 있습니다. 그러나 검증자만 기존 구성 제안에 찬성 또는 반대 투표를 할 수 있습니다.
중요** 구성 제안과 일반 구성 제안이 있다는 점에 유의하세요. 중요 구성 제안은 소위 중요 구성 매개변수 중 하나를 포함하여 모든 구성 매개변수를 변경할 수 있습니다(중요 구성 매개변수 목록은 구성 매개변수 #10에 저장되며, 그 자체로 중요함). 그러나 중요 구성 제안을 만들려면 비용이 더 많이 들고 일반적으로 더 많은 라운드에서 더 많은 검증인 투표를 수집해야 합니다(일반 및 중요 구성 제안에 대한 정확한 투표 요구 사항은 중요 구성 매개변수 #11에 저장되어 있습니다). 반면에 일반 구성 제안은 더 저렴하지만 중요 구성 매개변수를 변경할 수 없습니다.
새 구성 제안을 만들려면 먼저 제안된 새 값이 포함된 BoC(백 오브 셀) 파일을 생성해야 합니다. 이 작업을 수행하는 정확한 방법은 변경하려는 구성 매개변수에 따라 다릅니다. 예를 들어 UTF-8 문자열 "TEST"(즉, 0x54455354)가 포함된 매개 변수 -239를 만들려면 다음과 같이 config-param-239.boc를 만들면 됩니다.
<b "TEST" $, b> 2 boc+>B "config-param-239.boc" B>file
bye
결과적으로 필요한 값의 직렬화가 포함된 21바이트 파일 config-param-239.boc이 생성됩니다.
보다 정교한 경우, 특히 음수가 아닌 인덱스가 있는 구성 매개변수의 경우 이 간단한 접근 방식을 쉽게 적용할 수 없습니다. 저희는 fift 대신 create-state(빌드 디렉토리에서 crypto/create-state로 제공)를 사용하고, 일반적으로 TON 블록체인의 제로 상태(다른 블록체인 아키텍처의 "제네시스 블록"에 해당)를 만드는 데 사용되는 소스 파일 crypto/smartcont/gen-zerostate.fif 및 crypto/smartcont/CreateState.fif의 적절한 부분을 복사 및 편집하는 것을 권장합니다.
예를 들어, 현재 활성화된 글로벌 블록체인 버전과 기능을 포함하는 구성 매개변수 '#8'을 생각해 보세요:
capabilities#c4 version:uint32 capabilities:uint64 = GlobalVersion;
_ GlobalVersion = ConfigParam 8;
라이트 클라이언트를 실행하고 getconfig 8을 입력하면 현재 값을 확인할 수 있습니다:
> getconfig 8
...
ConfigParam(8) = (
(capabilities version:1 capabilities:6))
x{C4000000010000000000000006}
이제 비트 #3(+8)으로 표시되는 기능인 capReportVersion을 활성화하고 싶다고 가정해 보겠습니다(이 기능을 활성화하면 모든 콜레이터가 생성하는 블록의 블록 헤더에 지원되는 버전과 기능을 강제로 보고하도록 합니다). 따라서 version=1과 capabilities=14가 필요합니다. 이 예제에서는 여전히 올바른 직렬화를 추측할 수 있고 Fift를 입력하여 직접 BoC 파일을 생성할 수 있습니다.
x{C400000001000000000000000E} s>c 2 boc+>B "config-param8.boc" B>file
(그 결과 원하는 값이 포함된 30바이트 파일 config-param8.boc이 생성됩니다.)
그러나 더 복잡한 경우에는 이것이 옵션이 아닐 수 있으므로 이 예제를 다르게 해보겠습니다. 즉, 소스 파일 crypto/smartcont/gen-zerostate.fif와 crypto/smartcont/CreateState.fif에서 관련 부분을 검사할 수 있습니다.
// version capabilities --
{ <b x{c4} s, rot 32 u, swap 64 u, b> 8 config! } : config.version!
1 constant capIhr
2 constant capCreateStats
4 constant capBounceMsgBody
8 constant capReportVersion
16 constant capSplitMergeTransactions
및
// version capabilities
1 capCreateStats capBounceMsgBody or capReportVersion or config.version!
마지막 8 config!가 없는 config.version!은 기본적으로 필요한 작업을 수행하므로 임시 Fift 스크립트(예: create-param8.fif)를 만들 수 있다는 것을 알 수 있습니다:
#!/usr/bin/fift -s
"TonUtil.fif" include
1 constant capIhr
2 constant capCreateStats
4 constant capBounceMsgBody
8 constant capReportVersion
16 constant capSplitMergeTransactions
{ <b x{c4} s, rot 32 u, swap 64 u, b> } : prepare-param8
// create new value for config param #8
1 capCreateStats capBounceMsgBody or capReportVersion or prepare-param8
// check the validity of this value
dup 8 is-valid-config? not abort"not a valid value for chosen configuration parameter"
// print
dup ."Serialized value = " <s csr.
// save into file provided as first command line argument
2 boc+>B $1 tuck B>file
."(Saved into file " type .")" cr
이제 빌드 디렉터리에서 fift -s create-param8.5 config-param8.boc 또는 더 나은 방법으로 crypto/create-state -s create-param8.5 config-param8.boc를 실행하면 다음 출력을 볼 수 있습니다:
Serialized value = x{C400000001000000000000000E}
(Saved into file config-param8.boc)
를 실행하면 이전과 동일한 내용의 30바이트 파일 config-param8.boc이 생성됩니다.
원하는 구성 매개변수 값을 가진 파일이 있으면, 소스 트리의 crypto/smartcont 디렉터리에서 찾을 수 있는 create-config-proposal.fif 스크립트를 적절한 인수를 사용하여 호출합니다. 다시 말씀드리지만, fift 대신 create-state(빌드 디렉토리에서 crypto/create-state로 제공)를 사용하는 것이 좋습니다. 이는 블록체인 관련 유효성 검사를 더 많이 수행할 수 있는 특별한 확장 버전의 Fift이기 때문입니다:
$ crypto/create-state -s create-config-proposal.fif 8 config-param8.boc -x 1100000
Loading new value of configuration parameter 8 from file config-param8.boc
x{C400000001000000000000000E}
Non-critical configuration proposal will expire at 1586779536 (in 1100000 seconds)
Query id is 6810441749056454664
resulting internal message body: x{6E5650525E838CB0000000085E9455904_}
x{F300000008A_}
x{C400000001000000000000000E}
B5EE9C7241010301002C0001216E5650525E838CB0000000085E9455904001010BF300000008A002001AC400000001000000000000000ECD441C3C
(a total of 104 data bits, 0 cell references -> 59 BoC data bytes)
(Saved to file config-msg-body.boc)
마스터체인에 있는 모든 (지갑) 스마트 컨트랙트로부터 적절한 양의 톤코인과 함께 구성 스마트 컨트랙트로 전송할 내부 메시지 본문을 얻었습니다. 설정 스마트 컨트랙트의 주소는 라이트 클라이언트에서 'getconfig 0'을 입력하면 얻을 수 있습니다:
> getconfig 0
ConfigParam(0) = ( config_addr:x5555555555555555555555555555555555555555555555555555555555555555)
x{5555555555555555555555555555555555555555555555555555555555555555}
구성 스마트 컨트랙트의 주소가 -1:5555...5555임을 알 수 있습니다. 이 스마트 컨트랙트의 적절한 get 메서드를 실행하면 이 구성 제안을 생성하는 데 필요한 지불을 확인할 수 있습니다:
> runmethod -1:5555555555555555555555555555555555555555555555555555555555555555 proposal_storage_price 0 1100000 104 0
arguments: [ 0 1100000 104 0 75077 ]
result: [ 2340800000 ]
remote result (not to be trusted): [ 2340800000 ]
get-method proposal_storage_price의 매개 변수는 중요 플래그(이 경우 0), 이 제안이 활성화되는 시간 간격(1.1메가초), 데이터의 총 비트 수(104) 및 셀 참조(0)입니다. 후자의 두 수량은 'create-config-proposal.fif'의 출력에서 확인할 수 있습니다.
이 제안서를 작성하려면 2.3408 Toncoin을 지불해야 한다는 것을 알 수 있습니다. 처리 수수료를 지불하기 위해 최소 1.5 Tonoin을 메시지에 추가하는 것이 좋으므로 요청과 함께 4 Toncoin을 보내겠습니다(초과된 Toncoin은 모두 반환됩니다). 이제 wallet.fif(또는 사용 중인 지갑에 해당하는 파이브 스크립트)를 사용하여 지갑에서 config-msg-body.boc의 본문과 4 Ton코인을 포함하는 구성 스마트 컨트랙트로 전송을 생성합니다. 일반적으로 다음과 같이 보입니다:
$ fift -s wallet.fif my-wallet -1:5555555555555555555555555555555555555555555555555555555555555555 31 4. -B config-msg-body.boc
Transferring GR$4. to account kf9VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVQft = -1:5555555555555555555555555555555555555555555555555555555555555555 seqno=0x1c bounce=-1
Body of transfer message is x{6E5650525E835154000000085E9293944_}
x{F300000008A_}
x{C400000001000000000000000E}
signing message: x{0000001C03}
x{627FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA773594000000000000000000000000000006E5650525E835154000000085E9293944_}
x{F300000008A_}
x{C400000001000000000000000E}
resulting external message: x{89FE000000000000000000000000000000000000000000000000000000000000000007F0BAA08B4161640FF1F5AA5A748E480AFD16871E0A089F0F017826CDC368C118653B6B0CEBF7D3FA610A798D66522AD0F756DAEECE37394617E876EFB64E9800000000E01C_}
x{627FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA773594000000000000000000000000000006E5650525E835154000000085E9293944_}
x{F300000008A_}
x{C400000001000000000000000E}
B5EE9C724101040100CB0001CF89FE000000000000000000000000000000000000000000000000000000000000000007F0BAA08B4161640FF1F5AA5A748E480AFD16871E0A089F0F017826CDC368C118653B6B0CEBF7D3FA610A798D66522AD0F756DAEECE37394617E876EFB64E9800000000E01C010189627FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA773594000000000000000000000000000006E5650525E835154000000085E9293944002010BF300000008A003001AC400000001000000000000000EE1F80CD3
(Saved to file wallet-query.boc)
이제 라이트 클라이언트의 도움을 받아 외부 메시지 'wallet-query.boc'를 블록체인에 전송합니다.
> sendfile wallet-query.boc
....
external message status is 1
잠시 기다린 후, 지갑의 수신 메시지를 검사하여 구성 스마트 컨트랙트의 응답 메시지를 확인하거나 운이 좋으면 구성 스마트 컨트랙트의 list_proposals 메서드를 사용하여 모든 활성 구성 제안 목록을 검사할 수 있습니다.
> runmethod -1:5555555555555555555555555555555555555555555555555555555555555555 list_proposals
...
arguments: [ 107394 ]
result: [ ([64654898543692093106630260209820256598623953458404398631153796624848083036321 [1586779536 0 [8 C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} -1] 112474791597373109254579258586921297140142226044620228506108869216416853782998 () 864691128455135209 3 0 0]]) ]
remote result (not to be trusted): [ ([64654898543692093106630260209820256598623953458404398631153796624848083036321 [1586779536 0 [8 C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} -1] 112474791597373109254579258586921297140142226044620228506108869216416853782998 () 864691128455135209 3 0 0]]) ]
... caching cell FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC
모든 활성 구성 제안 목록이 쌍으로 표시되는 정확히 하나의 항목으로 구성되어 있음을 알 수 있습니다.
[6465...6321 [1586779536 0 [8 C{FDCD...} -1] 1124...2998 () 8646...209 3 0 0]]
첫 번째 숫자 6465..6321은 구성 제안의 고유 식별자이며 256비트 해시와 같습니다. 이 쌍의 두 번째 구성 요소는 이 구성 제안의 상태를 설명하는 튜플입니다. 이 튜플의 첫 번째 구성 요소는 구성 제안의 만료 유닉스 시간(1586779546)입니다. 두 번째 구성 요소(0)는 중요도 플래그입니다. 다음으로 [8 C{FDCD...} -1] 삼중으로 설명되는 구성 제안이 나오는데, 여기서 8은 수정할 구성 매개변수의 인덱스, C{FDCD...}은 새 값을 가진 셀(이 셀의 해시로 표시됨), -1은 이 매개변수의 이전 값의 선택적 해시(-1은 이 해시가 지정되지 않았음을 의미함)입니다. 다음으로 현재 검증인 집합의 식별자를 나타내는 큰 숫자 1124...2998, 지금까지 이 제안에 투표한 모든 현재 활성 검증인 집합을 나타내는 빈 목록 (), 그리고 8646...209와 같은 weight_remaining(제안이 이번 라운드에서 아직 충분한 검증인 투표를 수집하지 않은 경우 양수, 그렇지 않은 경우 음수)이 표시됩니다. 그러면 세 개의 숫자가 표시됩니다: 3 0 0. 이 숫자는 라운드_남은(이 제안은 최대 세 라운드, 즉 현재 검증인 집합의 변경까지 살아남을 것입니다), 승리(제안이 전체 검증인의 3/4 이상의 표를 가중치별로 모은 라운드 수), 패배(제안이 전체 검증인 표의 3/4를 모으지 못한 라운드 수)입니다.
라이트 클라이언트에 'FDCD...해시 또는 이 해시의 접두사를 충분히 길게 지정하여 해당 셀을 고유하게 식별할 수 있도록C{FDCD...}셀을 확장하도록 요청하여 구성 매개변수#8`에 대해 제안된 값을 검사할 수 있습니다:
> dumpcell FDC
C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} =
x{C400000001000000000000000E}
이 값은 x{C400000001000000000000000E}이며, 실제로 구성 제안에 임베드한 값임을 알 수 있습니다. 라이트 클라이언트에 이 셀을 TL-B 유형(ConfigParam 8)의 값으로 표시하도록 요청할 수도 있습니다.
> dumpcellas ConfigParam8 FDC
dumping cells as values of TLB type (ConfigParam 8)
C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} =
x{C400000001000000000000000E}
(
(capabilities version:1 capabilities:14))
이 기능은 다른 사람이 만든 구성 제안을 고려할 때 특히 유용합니다.
이제부터 구성 제안은 256비트 해시, 즉 큰 십진수 6465...6321로 식별됩니다. 구성 제안의 식별자와 동일한 유일한 인수를 사용하여 get-method get_proposal을 실행하여 특정 구성 제안의 현재 상태를 검사할 수 있습니다:
> runmethod -1:5555555555555555555555555555555555555555555555555555555555555555 get_proposal 64654898543692093106630260209820256598623953458404398631153796624848083036321
...
arguments: [ 64654898543692093106630260209820256598623953458404398631153796624848083036321 94347 ]
result: [ [1586779536 0 [8 C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} -1] 112474791597373109254579258586921297140142226044620228506108869216416853782998 () 864691128455135209 3 0 0] ]
이전과 본질적으로 동일한 결과를 얻지만, 구성 제안서가 하나만 있고 처음에 구성 제안서의 식별자가 없는 경우입니다.
4. 구성 제안에 대한 투표
구성 제안이 생성되면 현재 라운드와 여러 후속 라운드(선출된 검증인 세트)에서 현재 모든 검증인의 3/4 이상(가중치, 즉 지분 기준)의 투표를 수집해야 합니다. 이러한 방식으로 구성 매개변수를 변경하는 결정은 현재 검증인 세트뿐만 아니라 여러 후속 검증인 세트의 과반수가 승인해야 합니다.
구성 제안에 대한 투표는 구성 매개변수 #34에 (영구 공개 키와 함께) 나열된 현재 검증인만 가능합니다. 절차는 대략 다음과 같습니다:
- 유효성 검사기 운영자는 구성 매개변수
#34에 저장된 현재 유효성 검사기 집합에서 유효성 검사기의 (0 기반) 인덱스인val-idx를 조회합니다. - 오퍼레이터는 소스 트리의
crypto/smartcont디렉토리에 있는 특수 파이브 스크립트config-proposal-vote-req.fif를 호출하며, 인자로val-idx와config-proposal-id를 지정합니다:
$ fift -s config-proposal-vote-req.fif -i 0 64654898543692093106630260209820256598623953458404398631153796624848083036321
Creating a request to vote for configuration proposal 0x8ef1603180dad5b599fa854806991a7aa9f280dbdb81d67ce1bedff9d66128a1 on behalf of validator with index 0
566F744500008EF1603180DAD5B599FA854806991A7AA9F280DBDB81D67CE1BEDFF9D66128A1
Vm90RQAAjvFgMYDa1bWZ-oVIBpkaeqnygNvbgdZ84b7f-dZhKKE=
Saved to file validator-to-sign.req
- 그 후, 검증자에 연결된
validator-engine-console에서sign <validator-key-id> 566F744...28A1을 사용하여 현재 검증자의 개인 키로 투표 요청에 서명해야 합니다. 이 과정은 검증자 선거에 참여하기 위한 검증자-HOWTO에서 설명한 것과 유사하지만 이번에는 현재 활성 키를 사용해야 합니다. - 다음으로 또 다른 스크립트
config-proposal-signed.fif를 호출해야 합니다. 이 스크립트에는config-proposal-req.fif와 유사한 인수가 있지만, 투표 요청에 서명하는 데 사용되는 공개 키의 base64 표현과 서명 자체의 base64 표현이라는 두 가지 추가 인수가 필요합니다. 다시 말하지만, 이는 Validator-HOWTO에 설명된 프로세스와 매우 유사합니다. - 이렇게 하면 이 구성 제안에 대한 서명된 투표가 담긴 내부 메시지 본문이 포함된 파일 'vote-msg-body.boc'가 생성됩니다.
- 그 후,
vote-msg-body.boc은 마스터체인에 있는 스마트 컨트랙트(일반적으로 검증자의 제어 스마트 컨트랙트가 사용됨)의 내부 메시지로 소량의 톤코인(일반적으로 1.5 톤코인이면 충분함)과 함께 처리해야 합니다. 이는 검증자 선출 시 사용되는 절차와도 완전히 유사합니다. 이는 일반적으로 실행을 통해 이루어집니다:
$ fift -s wallet.fif my_wallet_id -1:5555555555555555555555555555555555555555555555555555555555555555 1 1.5 -B vote-msg-body.boc
(간단한 지갑을 사용하여 유효성 검사기를 제어하는 경우)를 호출한 다음 라이트 클라이언트에서 결과 파일 wallet-query.boc을 전송합니다:
> sendfile wallet-query.boc
구성 스마트 컨트랙트에서 제어 스마트 컨트랙트로 보내는 응답 메시지를 모니터링하여 투표 쿼리의 상태를 확인할 수 있습니다. 또는 구성 스마트 컨트랙트의 get-method show_proposal을 통해 구성 제안의 상태를 검사할 수 있습니다:
> runmethod -1:5555555555555555555555555555555555555555555555555555555555555555 get_proposal 64654898543692093106630260209820256598623953458404398631153796624848083036321
...
arguments: [ 64654898543692093106630260209820256598623953458404398631153796624848083036321 94347 ]
result: [ [1586779536 0 [8 C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} -1] 112474791597373109254579258586921297140142226044620228506108869216416853782998 (0) 864691128455135209 3 0 0] ]
이번에는 이 구성 제안에 투표한 유효성 검사기의 인덱스 목록이 비어 있지 않아야 하며, 유효성 검사기의 인덱스가 포함되어야 합니다. 이 예제에서 이 목록은 (0)이며, 이는 구성 매개변수 #34에 인덱스가 0인 유효성 검사기만 투표했음을 의미합니다. 목록이 충분히 커지면 제안 상태의 마지막 정수(3 0 0의 첫 번째 0)가 1씩 증가하여 이 제안이 새로 승리했음을 나타냅니다. 승리 횟수가 구성 매개변수 #11에 표시된 값보다 크거나 같으면 구성 제안이 자동으로 수락되고 제안된 변경 사항이 즉시 적용됩니다. 반면에 검증자 집합이 변경되면 이미 투표한 검증자 목록이 비어 있고, rounds_remaining 값(3 0 0의 3)이 1씩 감소하며, 음수가 되면 구성 제안이 파기됩니다. 파괴되지 않고 이 라운드에서 승리하지 못하면 패배 횟수(3 0 0의 두 번째 0)가 증가합니다. 구성 매개변수 #11에 지정된 값보다 커지면 구성 제안이 폐기됩니다. 결과적으로 한 라운드에서 투표하지 않은 모든 검증인은 암묵적으로 반대표를 던진 것입니다.
5. 구성 제안에 대한 자동화된 투표 방법
검증인 선거에 참여하기 위해 validator-engine-console의 createelectionbid 명령이 제공하는 자동화와 유사하게, validator-engine과 validator-engine-console은 이전 섹션에서 설명한 대부분의 단계를 자동으로 수행하여 제어 지갑에서 사용할 수 있는 vote-msg-body.boc을 생성하는 방법을 제공합니다. 이 방법을 사용하려면, 검증인 엔진이 validator-elect-req.fif와 validator-elect-signed.fif를 조회하는 데 사용하는 것과 동일한 디렉토리(/participate/nodes/validator)에 [검증인-HOWTO] 섹션 5에 설명된 대로 Fift 스크립트 config-proposal-vote-req.fif와 config-proposal-vote-signed.fif를 설치해야 합니다. 그 후, 간단히
createproposalvote 64654898543692093106630260209820256598623953458404398631153796624848083036321 vote-msg-body.boc
를 유효성 검사기 엔진 콘솔에 추가하여 구성 스마트 컨트랙트에 전송할 내부 메시지 본문으로 'vote-msg-body.boc'를 생성합니다.
6. 구성 스마트 컨트랙트 및 선거인 스마트 컨트랙트 코드 업그레이드하기
구성 스마트 콘트랙트 자체의 코드 또는 선거인 스마트 콘트랙트의 코드를 업그레이드해야 할 수도 있습니다. 이를 위해 위에서 설명한 것과 동일한 메커니즘이 사용됩니다. 새 코드는 값 셀의 유일한 참조에 저장되어야 하며, 이 값 셀은 구성 매개변수 -1000(구성 스마트 컨트랙트 업그레이드용) 또는 -1001(선거인 스마트 컨트랙트 업그레이드용)의 새 값으로 제안되어야 합니다. 이러한 매개변수는 중요한 척하기 때문에 구성 스마트 콘트랙트를 변경하려면 많은 검증자 투표가 필요합니다(이는 새로운 헌법을 채택하는 것과 비슷합니다). 이러한 변경은 먼저 테스트 네트워크에서 테스트하고 공개 포럼에서 제안된 변경에 대해 논의한 후 각 검증인 운영자가 제안된 변경에 대한 찬반 투표를 결정하게 될 것으로 예상됩니다.
또는 중요한 구성 매개변수 0(구성 스마트 컨트랙트의 주소) 또는 1(선거인 스마트 컨트랙트의 주소)을 다른 값으로 변경할 수 있으며, 이는 이미 존재하고 올바르게 초기화된 스마트 컨트랙트와 일치해야 합니다. 특히, 새로운 구성 스마트 콘트랙트는 영구 데이터의 첫 번째 참조에 유효한 구성 사전을 포함해야 합니다. 서로 다른 스마트 콘트랙트 간에 변경 데이터(예: 활성 구성 제안 목록 또는 검증자 선거의 이전 및 현재 참가자 목록)를 올바르게 전송하는 것은 쉽지 않으므로, 대부분의 경우 구성 스마트 콘트랙트 주소를 변경하는 것보다 기존 스마트 콘트랙트의 코드를 업그레이드하는 것이 더 좋습니다.
구성 또는 선거인 스마트 컨트랙트의 코드를 업그레이드하기 위해 이러한 구성 제안을 생성하는 데 사용되는 두 가지 보조 스크립트가 있습니다. 즉, create-config-upgrade-proposal.fif는 Fift 어셈블러 소스 파일(기본적으로 auto/config-code.fif, FunC 컴파일러가 crypto/smartcont/config-code.fc에서 자동으로 생성한 코드에 해당)을 로드하고 해당 구성 제안(구성 파라미터 -1000에 해당)을 생성합니다. 마찬가지로 create-elector-upgrade-proposal.fif는 Fift 어셈블러 소스 파일(기본적으로 auto/elector-code.fif)을 로드하고 이를 사용하여 구성 파라미터 -1001에 대한 구성 제안서를 생성합니다. 이러한 방식으로 두 스마트 컨트랙트 중 하나를 업그레이드하기 위한 구성 제안을 생성하는 것은 매우 간단합니다. 그러나 모든 검증자(또는 운영자)가 구성 제안서의 코드를 재현하고(해시를 비교하고) 제안된 변경 사항에 대한 찬반 투표를 결정하기 전에 소스 코드와 이 코드의 변경 사항을 연구하고 토론할 수 있도록 스마트 콘트랙트의 수정된 FunC 소스, 컴파일에 사용된 FunC 컴파일러의 정확한 버전도 게시해야 합니다.