파라미터 변경하기

이 문서는 TON 블록체인의 설정 파라미터에 대한 기본적인 설명과 함께 검증자의 합의를 통해 이러한 파라미터를 변경하기 위한 단계별 지침을 제공합니다.

읽는 사람이 Fift와 Lite Client에 대해 이미 알고 있다고 가정합니다. 이는 FullNode-HOWTO (low-level)와 Validator-HOWTO (low-level)에서 검증자의 설정 제안에 대한 투표가 설명된 섹션에서 다뤄집니다.

1. 설정 파라미터

설정 파라미터는 검증자와 TON 블록체인의 기본 스마트 컨트랙트의 동작에 영향을 미치는 특정 값입니다. 모든 설정 파라미터의 현재 값은 마스터체인 상태의 특별한 부분으로 저장되며 필요할 때 현재 마스터체인 상태에서 추출됩니다. 따라서 특정 마스터체인 블록에 대한 설정 파라미터의 값을 언급하는 것이 의미가 있습니다. 각 샤드체인 블록은 최신 알려진 마스터체인 블록에 대한 참조를 포함합니다. 해당 마스터체인 상태의 값들이 이 샤드체인 블록에 대해 활성화된 것으로 간주되며 블록의 생성과 검증 중에 사용됩니다. 마스터체인 블록의 경우, 이전 마스터체인 블록의 상태가 활성 설정 파라미터를 추출하는 데 사용됩니다. 따라서 마스터체인 블록 내에서 일부 설정 파라미터를 변경하려고 해도 다음 마스터체인 블록부터 변경사항이 활성화됩니다.

각 설정 파라미터는 설정 파라미터 인덱스 또는 단순히 인덱스라고 불리는 부호 있는 32비트 정수로 식별됩니다. 설정 파라미터의 값은 항상 Cell입니다. 일부 설정 파라미터는 없을 수 있습니다. 이 경우 해당 파라미터의 값은 Null로 간주됩니다. 또한 항상 존재해야 하는 필수 설정 파라미터의 목록이 있습니다. 이 목록은 설정 파라미터 #10에 저장됩니다.

모든 설정 파라미터는 부호 있는 32비트 키(설정 파라미터 인덱스)와 정확히 하나의 셀 참조로 구성된 값을 가진 Hashmap인 설정 사전으로 결합됩니다. 다시 말해, 설정 사전은 TL-B 타입 (HashmapE 32 ^Cell)의 값입니다. 실제로 모든 설정 파라미터의 컬렉션은 마스터체인 상태에 TL-B 타입 ConfigParams의 값으로 저장됩니다:

_ config_addr:bits256 config:^(Hashmap 32 ^Cell) = ConfigParams;

ConfigParams가 설정 사전 외에도 마스터체인의 설정 스마트 컨트랙트의 256비트 주소인 config_addr을 포함하고 있음을 알 수 있습니다. 설정 스마트 컨트랙트에 대한 자세한 내용은 나중에 제공될 것입니다.

활성 설정 파라미터의 값을 포함하는 설정 사전은 트랜잭션에서 스마트 컨트랙트의 코드가 실행될 때 특별한 TVM 레지스터 c7를 통해 모든 스마트 컨트랙트에서 사용할 수 있습니다. 더 정확히 말하면, 스마트 컨트랙트가 실행될 때 c7는 현재 Unix 시간(블록 헤더에 등록된 대로)과 같은 스마트 컨트랙트 실행에 유용한 여러 "컨텍스트" 값을 포함하는 튜플의 유일한 요소인 튜플로 초기화됩니다. 이 튜플의 열 번째 항목(즉, 제로 기반 인덱스 9)에는 설정 사전을 나타내는 Cell이 포함됩니다. 따라서 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은 참조가 없는 Cell과 정확히 104 데이터 비트를 포함하고 있음을 알 수 있습니다. 첫 네 비트는 11000100이어야 하고, 그 다음 32비트에는 현재 활성화된 "글로벌 버전"이 저장되며, 현재 활성화된 기능에 해당하는 플래그가 있는 64비트 정수가 따릅니다. 모든 설정 파라미터에 대한 더 자세한 설명은 TON 블록체인 문서의 부록에서 제공될 예정입니다. 현재로서는 crypto/block/block.tlb의 TL-B 스키마를 검사하고 검증자 소스에서 다른 파라미터가 어떻게 사용되는지 확인할 수 있습니다.

음수 인덱스를 가진 설정 파라미터와는 대조적으로, 음수 인덱스를 가진 설정 파라미터는 임의의 값을 포함할 수 있습니다. 적어도 검증자에 의해 그들의 값에 대한 제한이 강제되지 않습니다. 따라서 블록 생성에는 중요하지 않지만 일부 기본 스마트 컨트랙트에서 사용되는 중요한 정보(예: 특정 스마트 컨트랙트가 작동을 시작해야 하는 Unix 시간)를 저장하는 데 사용될 수 있습니다.

2. 설정 파라미터 변경하기

설정 파라미터의 현재 값이 마스터체인 상태의 특별한 부분에 저장된다고 이미 설명했습니다. 그렇다면 이들은 어떻게 변경되나요?

사실, 마스터체인에는 설정 스마트 컨트랙트라고 불리는 특별한 스마트 컨트랙트가 있습니다. 이의 주소는 이전에 설명한 ConfigParams의 config_addr 필드에 의해 결정됩니다. 데이터의 첫 번째 셀 참조는 모든 설정 파라미터의 최신 복사본을 포함해야 합니다. 새로운 마스터체인 블록이 생성될 때, 설정 스마트 컨트랙트가 주소 config_addr로 찾아지고 새로운 설정 사전이 데이터의 첫 번째 셀 참조에서 추출됩니다. 몇 가지 유효성 검사(예: 음수가 아닌 32비트 인덱스 i를 가진 값이 실제로 TL-B 타입 (ConfigParam i)의 유효한 값인지 확인) 후에 검증자는 이 새로운 설정 사전을 ConfigParams를 포함하는 마스터체인의 부분에 복사합니다. 이는 모든 트랜잭션이 생성된 후에 수행되므로 설정 스마트 컨트랙트에 저장된 새로운 설정 사전의 최종 버전만 검사됩니다. 유효성 검사가 실패하면 "진짜" 설정 사전은 변경되지 않고 그대로 유지됩니다. 이런 방식으로 설정 스마트 컨트랙트는 설정 파라미터의 유효하지 않은 값을 설정할 수 없습니다. 새로운 설정 사전이 현재 설정 사전과 일치하면 검사가 수행되지 않고 변경도 이루어지지 않습니다.

이런 방식으로 모든 설정 파라미터의 변경은 설정 스마트 컨트랙트에 의해 수행되며, 설정 파라미터 변경 규칙을 결정하는 것은 바로 이 코드입니다. 현재 설정 스마트 컨트랙트는 설정 파라미터를 변경하기 위한 두 가지 모드를 지원합니다:

설정 스마트 컨트랙트의 데이터에 저장된 공개 키에 해당하는 특정 개인 키로 서명된 외부 메시지를 통해. 이는 한 엔티티가 제어하는 더 작은 사설 테스트 네트워크와 공개 테스트넷에서 사용되는 방법입니다. 운영자가 쉽게 모든 설정 파라미터의 값을 변경할 수 있기 때문입니다. 이 공개 키는 오래된 키로 서명된 특별한 외부 메시지로 변경될 수 있으며, 0으로 변경되면 이 메커니즘이 비활성화된다는 점에 유의하세요. 따라서 출시 직후의 미세 조정에 사용하고 나서 영구적으로 비활성화할 수 있습니다.
검증자가 찬성 또는 반대 투표를 하는 "설정 제안"을 생성함으로써. 일반적으로 설정 제안은 모든 검증자(가중치 기준)의 3/4 이상의 투표를 수집해야 하며, 한 라운드뿐만 아니라 여러 라운드(즉, 여러 연속된 검증자 세트)에서도 제안된 파라미터 변경을 확인해야 합니다. 이는 TON 블록체인 메인넷에서 사용될 분산 거버넌스 메커니즘입니다.

두 번째 방법으로 구성 파라미터를 변경하는 방법에 대해 더 자세히 설명하고자 합니다.

3. 설정 제안 생성하기

새로운 설정 제안은 다음과 같은 데이터를 포함합니다:

변경할 설정 파라미터의 인덱스
설정 파라미터의 새로운 값(또는 삭제하려면 Null)
제안의 만료 Unix 시간
제안이 중요한지 여부를 나타내는 플래그
선택적인 이전 값 해시와 현재 값의 셀 해시(제안은 현재 값이 표시된 해시를 가진 경우에만 활성화될 수 있음)

마스터체인에 지갑이 있는 누구나 적절한 수수료를 지불하면 새로운 설정 제안을 생성할 수 있습니다. 하지만 기존 설정 제안에 대해서는 검증자만 투표할 수 있습니다.

중요한 설정 제안과 일반 설정 제안이 있다는 점에 유의하세요. 중요한 설정 제안은 중요한 파라미터를 포함한 모든 설정 파라미터를 변경할 수 있습니다(중요한 설정 파라미터 목록은 설정 파라미터 #10에 저장되어 있으며 이것 자체도 중요합니다). 하지만 중요한 설정 제안을 생성하는 것은 더 비싸고, 일반적으로 더 많은 검증자 투표를 더 많은 라운드에서 수집해야 합니다(일반 및 중요 설정 제안에 대한 정확한 투표 요구사항은 중요 설정 파라미터 #11에 저장되어 있습니다). 반면에 일반 설정 제안은 더 저렴하지만 중요한 설정 파라미터를 변경할 수 없습니다.

새로운 설정 제안을 생성하려면, 먼저 제안된 새로운 값을 포함하는 BoC(bag-of-cells) 파일을 생성해야 합니다. 이를 수행하는 정확한 방법은 변경하려는 설정 파라미터에 따라 다릅니다. 예를 들어, UTF-8 문자열 "TEST"(즉, 0x54455354)를 포함하는 파라미터 -239를 생성하려면 다음과 같이 config-param-239.boc를 생성할 수 있습니다: Fift를 호출하고 다음을 입력합니다

<b "TEST" $, b> 2 boc+>B "config-param-239.boc" B>file
bye

결과적으로 필요한 값의 직렬화를 포함하는 21바이트 파일 config-param-239.boc가 생성됩니다.

더 복잡한 경우, 특히 음수가 아닌 인덱스를 가진 설정 파라미터의 경우 이 단순한 접근 방식은 쉽게 적용할 수 없습니다. fift 대신 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}

이제 capReportVersion을 나타내는 비트 #3(+8)을 활성화하고 싶다고 가정해봅시다(활성화되면 이 기능은 모든 콜레이터가 생성하는 블록의 블록 헤더에서 지원하는 버전과 기능을 보고하도록 강제합니다). 따라서 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!
constant capIhr
constant capCreateStats
constant capBounceMsgBody
constant capReportVersion
constant capSplitMergeTransactions

그리고

// version capabilities
1 capCreateStats capBounceMsgBody or capReportVersion or config.version!

마지막 8 config! 없이 config.version!이 우리가 필요한 것을 본질적으로 수행한다는 것을 알 수 있으므로, 예를 들어 create-param8.fif라는 임시 Fift 스크립트를 생성할 수 있습니다:

#!/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.fif config-param8.boc 또는 더 나은 방법으로 crypto/create-state -s create-param8.fif 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)

마스터체인에 있는 모든 (지갑) 스마트 컨트랙트에서 적절한 양의 Toncoin과 함께 설정 스마트 컨트랙트로 보낼 내부 메시지의 본문을 얻었습니다. 설정 스마트 컨트랙트의 주소는 라이트 클라이언트에서 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-메서드 proposal_storage_price의 파라미터는 중요 플래그(이 경우 0), 이 제안이 활성화될 시간 간격(1.1 메가초), 총 비트 수(104)와 데이터의 셀 참조 수(0)입니다. 후자의 두 수량은 create-config-proposal.fif의 출력에서 볼 수 있습니다.

이 제안을 생성하기 위해 2.3408 Toncoin을 지불해야 함을 알 수 있습니다. 처리 수수료를 지불하기 위해 메시지에 최소 1.5 Toncoin을 추가하는 것이 좋으므로, 요청과 함께 4 Toncoin을 보낼 것입니다(초과 Toncoin은 모두 반환됩니다). 이제 우리는 wallet.fif(또는 사용 중인 지갑에 해당하는 Fift 스크립트)를 사용하여 4 Toncoin과 config-msg-body.boc의 본문을 포함하는 설정 스마트 컨트랙트로의 전송을 생성합니다. 이는 일반적으로 다음과 같이 보입니다:

$ 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비트 해시와 동일한 설정 제안의 고유 식별자입니다. 이 쌍의 두 번째 구성 요소는 이 설정 제안의 상태를 설명하는 튜플입니다. 이 튜플의 첫 번째 구성 요소는 설정 제안의 만료 Unix 시간(1586779546)입니다. 두 번째 구성 요소(0)는 중요성 플래그입니다. 다음은 삼중항 [8 C{FDCD...} -1]로 표현된 설정 제안 자체입니다. 여기서 8은 수정할 설정 파라미터의 인덱스이고, C{FDCD...}는 새로운 값을 가진 셀(이 셀의 해시로 표현됨)이며, -1은 이 파라미터의 이전 값의 선택적 해시입니다(-1은 이 해시가 지정되지 않았음을 의미합니다). 다음으로 현재 검증자 세트의 식별자를 나타내는 큰 숫자 1124...2998가 보이고, 그 다음에는 지금까지 이 제안에 투표한 모든 현재 활성 검증자의 집합을 나타내는 빈 목록 ()이 있으며, 그 다음에는 8646...209와 동일한 weight_remaining이 있습니다 - 이는 제안이 이 라운드에서 충분한 검증자 투표를 수집하지 못한 경우 양수이고, 그렇지 않으면 음수입니다. 그런 다음 세 개의 숫자 3 0 0이 보입니다. 이 숫자들은 rounds_remaining(이 제안은 최대 3라운드, 즉 현재 검증자 세트의 변경을 생존할 것입니다), wins(전체 검증자의 3/4 이상이 가중치로 투표한 라운드의 수), 그리고 losses(제안이 3/4의 검증자 투표를 수집하는 데 실패한 라운드의 수)입니다.

C{FDCD...}의 해시 FDCD... 또는 이 해시의 충분히 긴 접두사를 사용하여 셀을 고유하게 식별하여 라이트 클라이언트에게 설정 파라미터 #8에 대한 제안된 값을 검사하도록 요청할 수 있습니다:

> dumpcell FDC
C{FDCD887EAF7ACB51DA592348E322BBC0BD3F40F9A801CB6792EFF655A7F43BBC} =
  x{C400000001000000000000000E}

값이 x{C400000001000000000000000E}임을 알 수 있습니다. 이는 실제로 우리가 설정 제안에 포함시킨 값입니다. 라이트 클라이언트에게 이 Cell을 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비트 해시 - 큰 10진수 6465...6321로 식별됩니다. 설정 제안의 식별자를 유일한 인수로 하는 get-메서드 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 디렉토리에 있는 특별한 Fift 스크립트 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-HOWTO에서 검증자 선거 참여에 대해 설명된 것과 유사한 방식으로, validator-engine-console에서 sign <validator-key-id> 566F744...28A1을 사용하여 현재 검증자의 개인 키로 투표 요청에 서명해야 합니다. 하지만 이번에는 현재 활성화된 키를 사용해야 합니다.
다음으로, 다른 스크립트 config-proposal-signed.fif를 호출해야 합니다. 이는 config-proposal-req.fif와 유사한 인수를 가지지만, 투표 요청에 서명하는 데 사용된 공개 키의 base64 표현과 서명 자체의 base64 표현이라는 두 가지 추가 인수가 필요합니다. 이것도 Validator-HOWTO에서 설명된 프로세스와 매우 유사합니다.
이런 방식으로, 이 설정 제안에 대한 서명된 투표를 담은 내부 메시지의 본문이 포함된 파일 vote-msg-body.boc가 생성됩니다.
그 후, vote-msg-body.boc는 처리를 위한 약간의 Toncoin(일반적으로 1.5 Toncoin이면 충분)과 함께 마스터체인에 있는 모든 스마트 컨트랙트(일반적으로 검증자의 제어 스마트 컨트랙트가 사용됨)에서 보내는 내부 메시지로 전달되어야 합니다. 이것도 검증자 선거 중에 사용되는 절차와 완전히 유사합니다. 이는 일반적으로 다음을 실행하여 달성됩니다:

$ 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-메서드 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-HOWTO의 섹션 5에서 설명한 대로 validator-engine이 validator-elect-req.fif와 validator-elect-signed.fif를 찾는 것과 동일한 디렉토리에 Fift 스크립트 config-proposal-vote-req.fif와 config-proposal-vote-signed.fif를 설치해야 합니다. 그 후에는 단순히 validator-engine-console에서 다음을 실행하여:

    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 컴파일러의 정확한 버전도 공개해야 합니다. 그래야 모든 검증자(또는 그들의 운영자)가 설정 제안의 코드를 재현할 수 있고(해시를 비교할 수 있고) 제안된 변경사항에 대해 찬성 또는 반대 투표를 결정하기 전에 소스 코드와 코드의 변경사항을 연구하고 논의할 수 있습니다.

1. 설정 파라미터​

2. 설정 파라미터 변경하기​

3. 설정 제안 생성하기​

4. 설정 제안에 대한 투표​

5. 설정 제안에 대한 투표를 자동화하는 방법​

6. 설정 스마트 컨트랙트와 선거 스마트 컨트랙트의 코드 업그레이드​