본문으로 건너뛰기

거버넌스 계약

TON에서는 TVM, 캐체인, 수수료, 체인 토폴로지와 관련된 노드 운영의 합의 매개변수(그리고 이러한 매개변수가 저장되고 업데이트되는 방식)는 이전 세대의 블록체인이 채택했던 구시대적이고 유연하지 못한 하드코딩 방식과 달리 특수 스마트 컨트랙트에 의해 제어됩니다. 이러한 방식으로 TON은 포괄적이고 투명한 온체인 거버넌스를 구현합니다. 특별 계약 세트 자체는 매개변수에 의해 관리되며 현재 선거인, 컨피그, DNS 계약이 포함되어 있으며 향후에는 추가 통화 민터 등으로 확장될 예정입니다.

선거인​

선거인 스마트 컨트랙트는 검증 라운드가 서로를 변경하는 방식, 블록체인 검증 의무를 가진 사람, 검증 보상이 분배되는 방식을 제어합니다. 검증자가 되어 Elector와 상호작용하려면 검증자 지침을 확인하세요.

선거인은 credits 해시맵에 인출되지 않은 톤코인의 데이터를, elect 해시맵에 새로운 애플리케이션을, past*선거* 해시맵에 이전 선거에 대한 정보를 저장합니다(후자는 검증인의 잘못된 행동에 대한 _complaints와 이미 완료된 라운드의 검증인의 frozen 지분 안에 저장되며, 이는 stake_held_for(ConfigParam 15) 때문에 보류됩니다). 선거인 컨트랙트에는 세 가지 목적이 있습니다:

  • 검증인 선출 신청 처리
  • 선거 개최
  • 프로세스 유효성 검사기 오작동 보고서
  • 유효성 검사 보상 배포

애플리케이션 처리​

애플리케이션을 생성하려면 향후 검증자는 해당 매개변수(ADNL 주소, 공개 키, max_factor 등)가 포함된 특수 메시지를 작성하고, 이를 일부 TON 합계(지분이라고 함)에 첨부하여 선거인에게 보내야 합니다. 그러면 선거인은 해당 매개변수를 확인한 후 신청서를 등록하거나 즉시 보낸 사람에게 스테이크를 반환합니다. 신청은 마스터체인에 있는 주소에서만 접수된다는 점에 유의하세요.

선거 실시​

선거인은 각 블록의 시작과 끝에서 강제로 호출될 수 있는 옵션이 있는 특별한 스마트 콘트랙트입니다(소위 틱 앤 톡 트랜잭션). 실제로 선거인은 각 블록에서 호출되며 새로운 선거를 실시할 때가 되었는지 여부를 확인합니다.

선출 과정의 일반적인 개념은 모든 신청, 특히 TON 금액과 '최대 요인'(이 신청자가 가장 약한 검증인과 비교하여 수행하기로 합의한 검증 작업의 최대 비율)을 고려하여 각 검증인에게 TON 금액에 비례하되 모든 '최대 요인' 조건이 충족되는 방식으로 가중치를 설정하는 것입니다.

기술적으로 다음과 같이 구현됩니다:

  1. 선출자는 현재 네트워크 최소 min_stake(구성 매개변수 17) 이상의 지분 금액을 가진 모든 애플리케이션을 가져갑니다.
  2. 스테이크별로 내림차순으로 정렬합니다.
  3. 참가자가 최대 유효성 검사기 수(max_validators ConfigParam 16)보다 많으면 목록의 꼬리 부분을 삭제합니다.
  4. 1부터 N(남은 참가자 수)까지 i`를 순환합니다.
  • 목록에서 첫 번째 i 요소를 가져옵니다(내림차순으로 정렬).
  • i_번째 후보자가 마지막으로 합격한다고 가정하고(따라서 가중치가 가장 낮습니다) '최대 요인'에 대한 유효 지분(코드에서는 true_stake)을 계산합니다. 즉, j 번째(j<i) 지원자의 유효 지분은 min(stake[i]*max_factor[j], stake[j])로 계산됩니다.
  • 참가자의 총 유효 지분(TES)을 1에서 i-th까지 계산합니다. 이 TES가 이전에 알려진 최대 TES보다 높으면 현재 최적의 가중치 구성으로 간주합니다.
  1. 현재 최적의 구성, 즉 최대 지분을 활용하는 가중치 구성을 가져와서 구성 컨트랙트(컨피그 컨트랙트, 아래 참조)로 보내 새로운 검증자 집합이 되도록 합니다.
  2. 유효성 검사자가 되지 않은 신청자의 지분과 초과분(있는 경우) stake[j]-min(stake[i]*max_factor[j], stake[j] 등 사용하지 않은 모든 지분을 신청자가 요청할 수 있는 크레딧 테이블에 넣습니다.

이렇게 하면 100,000명의 후보와 2.7의 계수를 가진 9명의 참가자가 있고 10,000명의 참가자가 있는 경우. 마지막 참가자는 선출되지 않습니다: 그가 없으면 유효 지분은 900,000이고, 그가 있으면 9 * 27,000 + 10,000 = 253,000에 불과합니다. 반대로 100,000과 2.7의 계수를 가진 후보자가 한 명이고 10,000을 가진 참가자가 9명인 경우, 이들은 모두 검증자가 됩니다. 그러나 첫 번째 후보자는 10*2.7 = 27,000 톤만 스테이킹하고 초과분 73,000 톤은 '크레딧'으로 전환됩니다.

결과 유효성 검사 집합에는 몇 가지 제한이 있으며, 특히 '최소 유효성 검사자', '최대 유효성 검사자'(ConfigParam 16), '최소 스테이크', '최대 스테이크', '최소 총 스테이크', '최대 스테이크 팩터'(ConfigParam 17) 등 TON 구성 파라미터에 의해 제어된다는 점에 유의해 주세요. 현재 애플리케이션으로 이러한 조건을 충족할 수 없는 경우 선거가 연기됩니다.

유효성 검사기 오작동 보고 프로세스​

각 검증자는 때때로 무작위로 새 블록을 생성하도록 할당됩니다(검증자가 몇 초 후에 실패하면 이 임무는 다음 검증자에게 전달됩니다). 이러한 할당 빈도는 검증자의 가중치에 따라 결정됩니다. 따라서 누구나 이전 검증 라운드에서 블록을 가져와 생성된 예상 블록 수가 실제 블록 수에 가까운지 확인할 수 있습니다. 통계적으로 유의미한 편차(생성된 블록 수가 예상보다 적을 때)는 검증자가 잘못 작동하고 있음을 의미합니다. TON에서는 머클 증명을 사용하여 잘못된 동작을 비교적 쉽게 증명할 수 있습니다. 선거인 콘트랙트는 보관 비용을 지불할 준비가 된 사람이 제안한 벌금과 함께 이러한 증명을 수락하고 불만 사항을 등록합니다. 그런 다음 현재 라운드의 모든 검증인이 불만 사항을 확인하고, 불만 사항이 정확하고 제안된 벌금이 부정 행위의 심각도에 해당하면 투표합니다. 가중치에 따라 2/3 이상의 표를 얻으면 불만 사항이 수락되고, '과거_선거'의 해당 요소의 '동결' 해시맵에서 벌금이 보류됩니다.

검증 보상 분배​

각 블록의 선거인은 새로운 선거를 실시할 때가 되었는지 확인하는 것과 같은 방식으로, 저장된 '과거 선거'에 대해 '동결'된 자금을 해제할 때가 되었는지 확인합니다. 해당 블록에서 선거인은 해당 검증 라운드에서 누적된 수익(가스 수수료 및 블록 생성 보상)을 검증인 가중치에 비례하여 해당 라운드의 검증인에게 분배합니다. 그 후 보상을 받은 지분은 크레딧 테이블에 추가되고, 해당 선거는 past_elections 테이블에서 제거됩니다.

구성​

컨피그 스마트 컨트랙트는 TON 구성 매개변수를 제어합니다. 로직은 누가 어떤 조건에서 어떤 파라미터를 변경할 수 있는 권한을 가지고 있는지 결정합니다. 또한 제안/투표 메커니즘과 검증자 세트 롤링 업데이트도 구현합니다.

유효성 검사기 세트 롤링 업데이트​

컨피그 컨트랙트가 선거인 컨트랙트로부터 새로운 검증자 세트가 선출되었음을 알리는 특별한 메시지를 받으면, 컨피그는 새로운 검증자 세트를 컨피그파람 36(다음 검증자)에 넣습니다. 그런 다음, TickTock 트랜잭션 중 각 블록에서 컨피그는 새 검증자 세트를 적용할 시간인지 확인하고(검증자 세트 자체에 utime_since 시간이 포함됨), 이전 세트를 구성파람 34(현재 검증자)에서 구성파람 32(이전 검증자)로, 구성파람 36에서 구성파람 34로 옮깁니다.

제안/투표 메커니즘​

제안서 저장을 위한 스토리지 비용을 지불할 준비가 된 사람은 누구나 컨피그 컨트랙트에 해당 메시지를 전송하여 하나 이상의 구성 매개변수 변경을 제안할 수 있습니다. 그러면 현재 세트의 모든 검증자는 개인 키로 승인 메시지에 서명하여 이 제안에 투표할 수 있습니다(해당 공개 키는 컨피그 파라미터 34에 저장됩니다). (검증자의 가중치에 따라) 3/4의 표를 얻거나 얻지 못하면 해당 제안은 라운드에서 승리하거나 패배합니다. 임계 라운드 수(min_wins ConfigParam 11)에서 승리하면 제안이 수락되고, 임계 라운드 수(max_losses ConfigParam 11)에서 패배하면 제안이 폐기됩니다. 일부 매개변수는 임계값으로 간주되므로(임계값 집합 자체가 구성 매개변수 ConfigParam 10) 더 많은 라운드가 수락되어야 한다는 점에 유의하세요.

구성 매개변수 인덱스 -999, -1000, -1001은 긴급 업데이트 메커니즘에 투표하고 구성 및 선거인의 코드를 업데이트하기 위해 예약되어 있습니다. 해당 인덱스가 있는 제안서가 비상 키에 해당하는 충분한 라운드에서 충분한 표를 얻으면 컨피그 컨트랙트의 코드 또는 선거인 컨트랙트의 코드가 업데이트됩니다.

긴급 업데이트​

검증자는 투표 메커니즘을 통해 구성 매개변수를 업데이트할 수 없는 경우 투표를 통해 특별한 공개 키를 할당할 수 있습니다. 이는 네트워크가 활발하게 개발되는 동안 필요한 일시적인 조치입니다. 네트워크가 성숙해짐에 따라 이 조치는 단계적으로 폐지될 것으로 예상됩니다. 개발 및 테스트가 완료되는 대로 키는 다중 서명 솔루션으로 이전될 것입니다. 그리고 네트워크의 안정성이 입증되면 비상 메커니즘은 완전히 폐기될 것입니다.

검증자들은 실제로 2021년 7월에 해당 키를 TON 재단에 할당하기로 투표했습니다(마스터체인 블록 12958364). 해당 키는 구성 업데이트 속도를 높이는 데만 사용할 수 있습니다. 어떤 체인에 있는 컨트랙트의 코드, 저장소, 잔액에 간섭할 수 있는 권한은 없습니다.

긴급 업데이트 내역:

  • 2022년 4월 17일, 당시 가스 제한으로는 선거를 진행할 수 없을 정도로 선거 신청이 폭증했습니다. 특히 선거에는 1000만 개 이상의 가스가 필요했는데, 블록 soft_limit과 hard_limit은 각각 10m와 20m로 설정(ConfigParam 22), special_gas_limit과 block_gas_limit은 각각 10m와 10m로 설정(ConfigParam 20)되어 있었습니다. 이렇게 하면 새로운 검증자를 설정할 수 없고, 블록 가스 제한에 도달하여 마스터체인에서 내부 메시지를 처리하는 트랜잭션이 블록에 포함될 수 없습니다. 결과적으로 구성 업데이트에 대한 투표를 할 수 없게 되었습니다(현재 라운드가 종료되지 않아 필요한 수의 라운드에서 승리할 수 없었습니다). 비상 키를 사용하여 구성 파라미터 22 soft_limit을 22m로, hard_limit을 25m로 업데이트하고(블록 19880281에서), 구성 파라미터 20 special_gas_limit을 20m로, block_gas_limit을 22m로(블록 19880300에서) 업데이트했습니다. 그 결과 선거가 성공적으로 진행되었고, 다음 블록은 10 001 444 가스를 소비했습니다. 총 선거 연기는 약 6시간이었으며, 베이스 체인의 기능에는 영향을 미치지 않았습니다.
  • 2023년 3월 2일, 선거 신청자 수가 20M도 선거를 진행하기에 부족할 정도로 크게 증가했습니다. 그러나 이번 마스터체인은 더 높은 hard_limit으로 인해 외부 메시지를 계속 처리했습니다. 비상 키를 사용하여 컨피그 파라미터 20 special_gas_limit을 25m로, block_gas_limit을 27m로 업데이트했습니다(블록 27747086에서). 그 결과 다음 블록에서 선거가 성공적으로 진행되었습니다. 총 선거 연기 시간은 약 6시간이었으며, 선거 외에 마스터체인과 베이스체인의 기능에는 영향을 미치지 않았습니다.
  • 2023년 11월 22일, 키가 스스로 포기(블록 34312810)하는 데 사용되었습니다. 그 결과 공개 키가 32개의 0바이트로 대체되었습니다.
  • Ed25519 서명 확인을 OpenSSL 구현으로 전환하면서 특수한 경우[공개키의 모든 바이트가 동일함] 확인(https://github.com/ton-blockchain/ton/blob/7fcf26771748338038aec4e9ec543dc69afeb1fa/crypto/ellcurve/Ed25519.cpp#L57C1-L57C1)이 비활성화되었습니다. 그 결과, 공개키 0 확인이 의도한 대로 작동하지 않았습니다. 이 문제를 사용하여 비상 키가 12월 9일에 업데이트 다시 한 번 (블록 34665437, tx)에서 sha256("유효한 커브 포인트 아님")인 82b17caadb303d53c3286c06a6e1affc517d1bc1d3ef2e4489d18b873f5d7cd1로 바이트 시퀀스를 변경했습니다. 이제 네트워크 구성 매개변수를 업데이트하는 유일한 방법은 유효성 검사기 합의를 통해서만 가능합니다.

참고 항목​

  • [미리 컴파일된 계약](/개발/스마트-계약/핵심-계약/사전 컴파일)