거버넌스 메커니즘

거버넌스 메커니즘

개요

블록체인 거버넌스 메커니즘은 블록체인 생태계의 이해 관계자가 의사 결정에 대한 합의에 도달하기 위한 일련의 의사 결정 규칙 및 조치 표준을 의미합니다. 그 목적은 탈중앙화 네트워크가 시간이 지남에 따라 지속적으로 반복적으로 발전할 수 있도록 하는 것입니다. 블록체인에서 합의 메커니즘, 확장성, 보안 등과 같은 일부 중요한 기술은 거버넌스 메커니즘을 통해 합리적인 인센티브를 제공함으로써 더 잘 해결할 수 있습니다. 완전한 블록체인 거버넌스 메커니즘은 권리 분배, 경제적 인센티브 및 기술적 실현을 포함하여 블록체인 기술, 경제 및 정치 과학의 조합이어야 합니다. 블록체인의 생태계 구조는 개발자, 채굴자, 사용자로 구성되며 거버넌스의 각 역할은 고유한 가치를 발휘하고 상응하는 책임을 지고 상응하는 이익을 얻어야 합니다. 거버넌스의 중요성은 커뮤니티 분열과 혼란의 발생을 줄이고 커뮤니티가 프로젝트 갱신 및 반복의 효율성을 개선하고 참여하려는 커뮤니티 구성원의 열정을 높이는 데 돕습니다.

거버넌스 현황 분석

현재 거버넌스는 빅 모델에서 오프체인 거버넌스와 온체인 거버넌스로 나뉩니다. 오프체인 거버넌스는 핵심 개발자가 제어합니다. 노드는 소프트웨어를 설치하여 결정 신호를 보내고 전체 노드를 실행하는 사람에게 모든 책임을 위임합니다. 이것은 더 높은 사회적 조정 비용이 필요하고 합리적인 인센티브 메커니즘이 부족합니다. 새로운 개발자의 참여를 제한됩니다. 온체인은 온체인 제안 투표 메커니즘의 형태로 필수 업그레이드를 통해 명확한 거버넌스 프로세스 집합을 가지며 의사 결정 권한은 이해 관계자에게 줍니다.

비트코인, 이더리움 등 오프체인 거버넌스의 대표적인 퍼블릭 체인은 프로토콜 업그레이드가 주로 코어 개발자에 의해 운영되고 일반 채굴자와 사용자 그룹은 선택권이 없어 참여도가 낮고 시민권이 취약합니다. 오프체인 거버넌스의 단점을 인식한 일부 퍼블릭 체인은 커뮤니티 결정을 디지털화하고 이해 관계자의 조정 비용을 크게 줄이기 위해 자체 온체인 거버넌스 메커니즘을 시작했습니다. 체인의 거버넌스 메커니즘에서 권리를 분배하는 일반적인 방법은 종종 직접 민주주의와 간접 민주주의의 선택과 균형입니다.

직접 민주주의는 Decred 및 Tezos와 같이 높은 수준의 탈중앙화를 통해 ”1 토큰 1표” 접근 방식을 사용하여 규칙을 공식화하는 데 통화 보유자가 직접 참여하는 것입니다. 직접 민주주의에서는 투표율, 전문성, 토큰 집중과 같은 문제가 자주 발생합니다. 간접 민주주의는 대의제이며 EOS 슈퍼 노드, Polkadot의 이사회, DFINITY의 “팔로우 투표” 메커니즘과 같은 다양한 방법을 통해 대표자를 선출하고 이들에게 의존하여 권리를 행사합니다. 간접 민주주의는 거버넌스 구조 설계, 배분 및 인센티브와 같은 문제를 고려해야 합니다.

PlatON거버넌스 메커니즘

우리는 의사결정권이 ‘이해관계자’, 즉 국민에게 있어야 한다고 생각합니다. 그러나 국민투표의 시행은 시행비용과 투표율, 전문성, 거버넌스 효율성 등의 문제를 고려해야 하므로 국민투표가 거버넌스의 규범이 되어서는 안 되며, 큰 이견이 있는 상황에서 거버넌스 방식이 되어야 합니다. 우리의 PPoS 설계에서 후보 노드의 생성은 그 자체가 선거이며 노드의 이익은 퍼블릭 체인 생태계의 흥망과 밀접한 관련이 있으며 더 많은 거버넌스 책임을 맡고 더 많은 거버넌스 권한을 가져야 합니다.따라서 PlatON 거버넌스에서는 직접 민주주의와 간접 민주주의를 결합한 모델을 채택했으며 핵심 원칙은 다음과 같습니다.
정상적인 조건에서는 후보 노드가 투표되고 지배되는 것은 간접 민주주의이며, 주요 차이점에서는 커뮤니티가 공개적으로 투표되고 지배되는 것은 직접 민주주의입니다.

참여 역할

  • 후보 노드:노드는 특정 토큰을 스테이킹하여 후보가 되며, 다른 사용자는 자신의 토큰을 후보에게 위탁할 수 있습니다. 시스템은 전체 권리와 이익(스테이킹 + 위탁)에 따라 후보의 순위를 매기고 상위 201명의 후보를 백업 후보노드로 선출합니다. 
  • 토큰 보유자:모든 토큰 보유자.
  • 핵심 개발자:PlatON 퍼블릭 체인과 커뮤니티를 공동으로 구축하는 핵심 개발자.

권리의 분배

  • 후보 노드
    • 제안 시작
    • 국민투표 제안에 투표
    • 국민투표가 아닌 제안에 투표
    • 제안에 대한 동의하고 공동 제안
  • 토큰 보유자
    • 국민투표 제안 개시
    • 국민투표 제안에 투표
    • 안에 대한 동의하고 공동 제안
  • 개발자
    • github코드 컨트롤
    • 제안 검토
    • 제안 실현

제안 분류

  • 국민투표 제안:국민투표 제안은 논란의 여지가 있는 시나리오에서 발생합니다. 코인 보유자는 누구나 국민투표 제안을 시작할 수 있으며 결과를 얻기 위해서는 국민투표를 실시해야 합니다. 시나리오는 다음과 같습니다.
    • 기본법 개정
    • The Dao의 포크와 유사한 주요 포크를 진행
    • 체인 작동 중지
  • 비 국민투표 제안: 비 국민투표 제안은 일반 제안이며 결과는 후보 노드에서 생성되며 제안 유형은 다음 유형으로 나눌 수 있습니다.
    • 텍스트 제안: 구현할 필요가 없는 결정의 경우 텍스트 제안을 사용하여 시작할 수 있습니다.
    • 소프트웨어 업그레이드 제안: 원활한 업그레이드의 목적을 달성하기 위해 체인에서 업그레이드 투표를 시작하는 데 사용됩니다.
    • 매개변수 수정 제안: 시스템 매개변수와 같은 관리 가능한 매개변수를 수정하는 데 사용합니다.
    • 계정 제안: 계정 락업 또는 락업 해제에 사용(컨트랙트 포함)
    • 인센티브 제안: 거버넌스 펀드 계정의 잔액을 할당하는 데 사용합니다.
    • 제안 취소: 체인에서 투표 중인 소프트웨어 업그레이드 제안을 취소하는 데 사용됩니다.

거버넌스 프로세스

governace-flow

1) 제안 시작

국민투표 제안은 누구나 시작할 수 있으며, 비 국민투표 제안은 후보 노드에 의해 시작됩니다. 각 제안에는 github의 PIP에 저장되고 EIP와 유사한 핵심 개발자가 관리하는 해당 텍스트 설명이 있어야 합니다.

스팸 제안을 제어하기 위해 모든 유형의 제안은 제안 비용으로 제안 처리 수수료를 지불해야 합니다.

2) 제안 심사(선택)

  • 국민 투표 제안: 국민 투표 제안은 정상적이지 않기 때문에 체인에서 동시에 여러 개의 국민 투표 제안이 시작될 수 있습니다.이 제안은 높은 보증금에 따라 정렬되며 가장 높은 보증금을 가진 제안이 매월 선택해서 투표 단계에 진입합니다.
  • 비 국민투표 제안: 제안이 성공적으로 시작되면 투표 기간이 시작되며 여러 제안을 동시에 투표할 수 있습니다.

3) 제안 투표

  • 국민투표 제안
    국민투표 제안의 핵심은 권리와 이익을 위한 투표입니다. 투표는 2주 동안 진행되며 “예”, “아니오” 및 “기권”의 세 가지 투표 옵션이 있습니다. 스테이킹 및 위탁에 참여하는 토큰만 투표할 수 있습니다. 투표 양식은 “후보 노드 투표 + 개인 투표 범위” 모드를 채택합니다. 즉, 후보 노드의 투표 가중치는 자신이 스테이킹한 토큰과 위탁된 토큰 수의 합이며, 위탁자가 후보 노드에 동의하지 않을 경우 위탁자는 스스로 투표할 수 있으며 투표 가중치는 위탁된 수량입니다. 가중치에 해당하는 투표 옵션을 덮어씁니다. 모든 투표는 투표가 끝날 때까지 토큰을 잠급니다.
    다수의 토큰이 소수의 노드에 의해 제어되어 발생하는 투표 집중화 문제를 완화하기 위해 투표에 참여하는 후보 노드의 수는 충분히 커야 합니다. 제안은 여전히 ​​통과되지 않습니다.
  • 비 국민투표 제안
    비 국민투표 제안에 대한 투표의 핵심은 후보 노드의 투표입니다. 제안서의 투표 기간 내에 후보 노드로 선출된 모든 노드는 투표할 수 있습니다. 투표 기간은 일반적으로 2주이며 소프트웨어 업그레이드 제안의 투표 기간은 상황에 따라 제안 후보자가 결정할 수 있습니다. 투표 형식은 후보 노드에 대해 1인 1 투표 시스템을 채택하고 있으며, 투표 후 후보 노드의 스테이킹 토큰은 투표가 끝날 때까지 잠겨 있습니다. 소프트웨어 업그레이드 제안 외에도 “예”, “아니오” 및 “기권”과 같은 다른 유형의 투표에 대한 세 가지 투표 옵션이 있습니다. 투표 절차를 단순화하기 위해 소프트웨어 업그레이드 제안에 대한 명시적인 옵션이 없습니다.각 후보 노드는 로컬 노드 업그레이드 여부에 따라 투표 위치를 나타낼 수 있습니다.자세한 내용은 업그레이드 메커니즘을 참조하십시오.

4) 투표 결과 계산

  • 국민투표 제안: 국민투표 제안 결과의 계산 차원은 다음과 같습니다.
    • 후보 노드 지지율 : 투표 가능한 총 후보 노드 수에 대한 투표 후보 노드 수의 비율
    • 토큰 지원율: 투표에 참여하는 총 토큰 수에 대한 지원 토큰 수의 비율
    • 토큰 참여율: 총 스테이킹된 토큰 수에 대한 투표에 참여하는 총 토큰 수의 비율
  • 후보 노드 지지율>P%, 토큰 지지율>Q%, 토큰 참여율>K%를 동시에 만족할 경우 제안은 통과되며, 그렇지 않으면 제안은 투표되지 않습니다.
  • 비투표 제안: 비 국민투표 제안의 계산 차원은 다음과 같습니다.
    • 후보 노드 지지율 : 투표 가능한 총 후보 노드 수에 대한 투표 후보 노드 수의 비율
    • 후보 노드의 참여율: 투표 가능한 총 후보 노드 수에 대한 투표 후보 수의 비율
  • 후보노드 지지율>M%, 후보노드 참여율>N%가 동시에 만족할 경우  제안은 투표로 통과되며, 그렇지 않으면 제안은 투표로 통과되지 않습니다.


제안 유형별 지지율 및 참여율은 다음과 같습니다.

유형참여율지지율
텍스트 제안>50%>=66.7%
취소 제안>50%>=66.7%
매개변수 제안>50%>=66.7%
업그레이드 제안=100%>=66.7%

업그레이드 메커니즘

업그레이드 메커니즘은 네트워크가 계속해서 반복되고 개선될 수 있도록 보장합니다. 블록체인 시스템 운영 중 발생할 수 있는 다양한 상황에 대해 주로 다음 4가지 상황에서 대상 업그레이드 방법을 제공합니다.

  • 최적화 업그레이드: 이 유형의 업그레이드는 현재 체인 버전의 기능 최적화입니다. 각 노드는 업그레이드가 합의에 영향을 미치지 않는지 여부와 관계없이 상황에 따라 업그레이드 여부를 결정할 수 있습니다.
  • 업그레이드에 투표: 이 카테고리의 업그레이드는 새로운 기능을 추가하거나 합의 메커니즘에 영향을 미치는 패치를 수정하는 것입니다. 업그레이드는 체인에서 소프트웨어 업그레이드 제안을 시작하고 투표 결과를 통해 업그레이드를 구현할지 여부를 결정하고 네트워크를 중단하지 않고 원활한 업그레이드를 완료해야 합니다. 
  • 수리 및 업그레이드: 노드가 낮은 버전 또는 비정상적인 트랜잭션으로 인해 정상적으로 합의에 참여할 수 없는 경우 검증자는 새 버전의 소프트웨어를 설치하여 네트워크 합의 참여를 복원할 수 있습니다.
  • 스냅샷 업그레이드: 블록체인 시스템이 주요 이상 현상을 만나 전체 체인이 블록을 제대로 생성하지 못하는 경우 이전의 정상적인 네트워크 상태를 기반으로 스냅샷을 생성한 다음 스냅샷을 기반으로 네트워크를 복원할 수 있습니다.

아래에서는 온체인 투표 업그레이드 메커니즘에 중점을 두고 설명하겠습니다.

1) 업그레이드 제안 시작

업그레이드 제안은 검증인만 시작할 수 있습니다. 개시 시에는 일반 거래 수수료보다 높은 수수료를 지불해야 합니다. 소프트웨어 업그레이드 제안의 매개변수에 다음 매개변수를 제공해야 합니다.

  • 업그레이드 대상의 버전 번호입니다. 버전 번호는 1.2.0과 같이 세 자리 숫자로 구성됩니다. 업그레이드 대상 버전 번호의 처음 두 자리는 현재 체인 버전 번호의 처음 두 자리보다 커야 합니다.
  • github이 업그레이드 정보를 설명하는 파일의 ID인 PIP-ID입니다. ID는 유일한 것이어야 합니다.
  • 업그레이드 제안에 대한 투표를 위한 합의 라운드의 수는 N입니다. 이 매개변수는 투표 컷오프 블록 높이, 즉 현재 컨센서스 라운드 시작 시 N번째 컨센서스 라운드의 230번째 블록 컷오프 투표를 계산하는 데 사용됩니다.

체인에는 하나의 소프트웨어 업그레이드 제안만 있을 수 있습니다. 즉, 투표에 이미 소프트웨어 업그레이드 제안이 있거나 체인에서 구현 중인 경우 다른 소프트웨어 업그레이드 제안을 시작할 수 없습니다. 이때 특별한 이유나 긴급 상황이 발생하여 즉시 새 소프트웨어 업그레이드 제안을 시작해야 하는 경우 취소 제안을 시작하여 소프트웨어 업그레이드 제안을 취소할 수 있습니다.

취소 제안 설명: 체인에서 투표 중인 업그레이드 제안이 있는 경우에만 취소 제안을 시작할 수 있습니다. 제안된 거래를 취소하려면 다음 매개변수가 필요합니다:

  • 취소된 업그레이드 제안 거래 해시
  • 업그레이드 정보의 GitHub 설명 파일 ID, 즉 PIP-ID입니다.ID는 유일한 것이어야 합니다.
  • 제안 투표의 합의 라운드를 취소합니다. 이 매개변수로 계산된 투표 차단 블록 높이는 취소된 업그레이드 제안의 투표 차단 블록 높이를 초과할 수 없습니다.

2) 업그레이드 제안에 투표

소프트웨어 업그레이드 제안이 성공적으로 시작된 후 투표 단계에 들어갑니다. 검증자만이 투표에 참여할 수 있습니다. 즉, 투표 거래는 노드의 스테이킹 계정으로만 시작할 수 있습니다. 투표하기 전에 로컬 노드를 업그레이드하여 1인 1표로 투표를 통계해야 합니다.

우리는 소프트웨어 업그레이드 제안에 대한 투표 거래에서 “지지”, “반대”, “기권”에 대한 투표 옵션을 설정하지 않았지만 다음과 같이 노드 행동을 통해 입장을 표명했습니다.

  • 지지: 로컬 노드 버전이 제안 업그레이드 버전으로 업데이트된 후 업그레이드 제안에 대한 투표가 시작됩니다.
  • 중립: 노드를 업그레이드하도록 선택할 수 있지만 투표는 하지 않고 버전 설명 트랜잭션을 시작하여 이 노드가 업그레이드되었음을 선언하므로 제안의 통과 여부에 관계없이 일반적으로 합의에 참여할 수 있습니다. 
  •  반대: 로컬 노드를 업그레이드할 필요가 없으며 투표가 필요하지 않습니다.

제안 투표 거래를 업그레이드하려면 다음 매개변수가 필요합니다.

  • 제안 거래를 시작하는 해시
  • 노드의 실제 버전 번호:성공적으로 투표하려면 이 버전 번호가 투표에서 업그레이드 대상의 버전 번호와 같아야 합니다.
  • 노드 서명:서명은 노드 버전 번호의 노드 프라이빗 키 서명입니다.

투표 기간 동안 노드가 업그레이드되었지만 현재 실행 중인 논리는 여전히 이전 버전의 논리입니다. 새 버전의 로직으로 전환하기 전에 구현이 완료될 때까지 기다려야합니다.

3) 업그레이드 제안 투표 결과 통계

거버넌스 메커니즘

업그레이드 제안의 투표 결과는 투표 컷오프 블록 높이에게 통계됩니다. 투표 주기의 투표 상황이 위와 같은 경우:

  • 결제 주기 1의 총 검증인 수: P1, 검증인이 시작한 업그레이드 투표 수는 M1입니다.
  • 결제 주기 2의 총 검증인 수: P2, 검증인이 시작한 업그레이드 투표 수는 2입니다.
  • 결제 주기 N의 총 검증인 수 : Pn, 검증인이 시작한 업그레이드 투표 수는 Mn입니다.

즉,최종 지지율은:거버넌스 메커니즘

SR≥66.7이면 제안이 통과되고 구현 단계에 들어갑니다.

4) 업그레이드 제안 구현

VRF 후보 노드 선택의 무작위성과 합의에 영향을 미치지 않기 위해 업그레이드를 구현할 때 합의 라운드의 검증 노드가 모두 업그레이드된 노드인지 확인해야 합니다.

따라서 제안 투표 블록 높이 컷오프 때 제안서의 지지율이 66.7%에 도달하면 다음 합의 라운드의 첫 번째 블록에서 업그레이드가 구현되고 업그레이드되지 않은 노드는 더 이상 합의에 참여하도록 선택되지 않습니다. . 현재 결제 주기에서 제거되지 않은 업그레이드되지 않은 노드는 VRF에서 합의에 참여하도록 선택되지 않지만 현재 결제 주기의 스테이킹된 수익을 계속 받을 수 있습니다.

5) 버전 선언

서로 다른 버전 간에 데이터 비호환성이 있을 수 있으므로 버전 문제로 인한 합의 실패를 방지하기 위해 체인의 노드 버전을 제어해야 하므로 버전 선언을 도입했습니다. 노드는 자신의 노드 버전이 현재 체인 버전 또는 소프트웨어 업그레이드 제안 투표의 대상 버전 번호와 일치함을 나타내기 위해 버전 선언을 시작하여 업그레이드 전후에 정상적으로 합의에 참여할 기회를 가질 수 있습니다.

후보 노드와 검증자 노드만 버전 선언을 시작할 수 있습니다. 새로 추가된 노드는 버전 선언을 실행하기 전에 후보 노드가 되어야 합니다. 각 단계 버전 선언의 조건은 다음과 같습니다.

거버넌스 메커니즘


노드 버전과 체인의 버전이 일치하지 않는 경우(버전 번호의 처음 두 자리 숫자가 다름), 스테이킹이 많더라도 노드는 합의에 참여하도록 선택되지 않습니다. 이때 노드는 버전 선언 트랜잭션을 시작하여 노드가 체인 버전과 일치함을 선언할 수 있습니다. 후속 결제 주기에서 합의에 참여하기 위해 체인에 투표 소프트웨어 업그레이드 제안이 있는 경우 업그레이드 버전과 일치하는 버전 설명이 발행될 수 있고 버전 선언은 투표가 아닙니다. 업그레이드 제안이 통과된 후 업그레이드 대상과 버전 번호가 동일한 노드가 투표 없어도 선언이 가능하고 정상적으로 합의에 참여할 수 있습니다.

빠른 업그레이드

체인에서 업그레이드 투표를 시작하는 것은 심중적으로 봐야할 문제입니다. 이론적으로 제안을 철회할 가능성이 없어야 합니다. 모든 결과는 투표를 위해 검증자에게 제출되어야 합니다. 그러나 우리는 온체인에서 하나의 소프트웨어 업그레이드 제안만 투표할 수 있도록 허용하므로 긴급 상황을 신속하게 업그레이드해야 할 때 온체인에 처리되지 않은 제안이 있으면 긴급 처리 속도에 직접적인 영향을 미칩니다. 그래서 검증자가 시작가능한 취소(철회) 제안을 도입했습니다. 투표 주기는 자체적으로 결정할 수 있지만 취소된 제안의 투표 주기 내에 있어야 합니다. 취소 제안을 개시하고 각 노드의 신속한 대응으로 투표 중인 소프트웨어 업그레이드 제안을 단시간에 취소할 수 있어 비상 계획을 신속하게 이행할 수 있습니다. 온체인에서 투표 중인 업그레이드 제안이 있는 경우에만 취소 제안을 시작할 수 있습니다. 취소 제안은 일단 시작되면 구현해야 하므로 비상 시에만 취소 제안을 사용하는 것이 권장합니다.

제안된 거래를 취소하려면 다음 매개변수가 필요합니다:

  • 취소된 업그레이드 제안 거래 해시
  • github이 업그레이드 정보를 설명하는 파일의 ID인 PIP-ID입니다. .ID는 유일한 것이어야 합니다.
  • 제안 투표를 취소하기 위한 합의 라운드의 수입니다.(이 매개변수로 계산된 투표 컷오프 블록 높이는 취소된 업그레이드 제안의 투표 컷오프 블록 높이를 초과할 수 없습니다.)

매개변수 거버넌스

후보 노드는 매개변수 거버넌스 제안을 시작하여 일부 시스템 매개변수를 수정할 수 있습니다. 매개변수 제안과 업그레이드 제안의 교차 구현으로 인해 발생하는 문제를 방지하기 위해 체인에 투표 업그레이드 제안 또는 매개변수 제안이 있는 경우 새로운 매개변수 수정 제안을 시작할 수 없습니다. 매개변수 제안에 대한 투표 기간은 2주입니다. 현재 우리가 지원하는 거버넌스 매개변수는 다음과 같습니다.

  • staking모듈
Key설명범위
stakeThreshold후보 노드 후보가 되기 위한 최소 스테이킹 토큰 수[10w,1000w] LAT
operatingThreshold위탁자가 매번 위탁 및 상환에 대한 최소 토큰 수[10, 10000] LAT
maxValidators후보 노드의 수량[43, 10000]
unStakeFreezeDuration검증 노드가 퇴출되고 스테이킹 자산이 락업되는 정산 주기 수(maxEvidenceAge,336] Epoch
rewardPerMaxChangeRange“위탁 보상 비율” 수정마다 최대 조정 가능한 커미션 보너스 범위(‱)[1,2000]
rewardPerChangeInterval“위탁 보상 비율”을 통해 다시 수정하려면 기다려야 하는 결제 주기 수[2, 28]
  • slashing모듈
Key설명범위
slashBlocksReward블록 생성률은 0, 감소된 블록 보상 블록 수[0, 50000) blocks
slashFractionDuplicateSign이중 서명 보고 패널티 노드 자체 스테이킹 금액 비율(‱)(0,10000]
duplicateSignReportReward제보자가 패널티를 통해 받을 수 있는 보상 비율(%)(0, 80]
maxEvidenceAge이중 서명 제보하는 증거가 유효한 결제 주기의 수(0, unStakeFreezeDuration)Epoch
zeroProduceCumulativeTime제로 블록 생성을 위한 지속적인 합의 라운드 수 및 이 기간 동안의 제로 블록 생성 횟수 누적[zeroProduceNumberThreshold ,50]
zeroProduceNumberThreshold제로 블록 생성에 대한 페널티 임계값[1,zeroProduceCumulativeTime]
ZeroProduceFreezeDuration노드는 제로 블록 생성 페널티 인해로 락업 당한 시간[1,unStakeFreezeDuration)
  • block모듈
Key설명범위
MaxBlockGasLimitBlock GasLimit은 도달할 수 있는 최대 가스 제한을 동적으로 조정[9424776, 300000000] gas
  • reward
Key설명범위
increaseIssuanceRatioPlaTON 네트워크 LAT 연간 추가 발행 비율(‱)[0, 2000]
  • restricting
Key설명범위
minimumRelease락업 계획 해제 기간의 최소 해제 금액[100, 10000000]

보상 및 처벌 메커니즘

거버넌스 메커니즘을 설계할 때 보다 관심 있고 유능한 전문가가 거버넌스에 참여하도록 장려하는 동시에 네트워크 리소스 점유와 같은 악의적인 행위를 처벌할 수 있는 좋은 시스템이 필요합니다.

보상

  • 제안 보상: 제안 보상은 제안이 투표를 통과한 후 제안 시작 계정에 자동으로 분배됩니다.
  • 투표 보상: 투표 후 제안서의 투표가 종료될 때까지 토큰을 락업 상태로 유지해야 하므로 투표 보상은 투표 락업 시간의 길이에 비례하며 투표 종료 시 각 투표 계정에 분배됩니다. 
  • 개발자 보상: 개발자 보상은 온체인에서 제안을 시작하고 투표 결과에 따라 제안을 공개할지 여부를 결정해야 합니다.
  • Vulnerability현상금: Vulnerability의 존재를 확인한 후 온체인에서 제안을 시작해야 하며 투표 결과에 의해 공개 여부를 결정합니다.

처벌

정직한 노드가 버전을 위장하여 업그레이드를 달성하면 체인 업그레이드가 성공하면 검증인이 합의에 참여하도록 선택되고 블록이 합의될 수 없기 때문에 블록 생성률이 낮아 시스템 처벌을 받게 됩니다.심각하면 검증노드 지격을 실격시킬 수 있습니다.

거버넌스 펀드

거버넌스 펀드는 재단(Foundation)에서 나오며, 매년 일정 비율의 펀드가 재단의 계정에서 거버넌스 계정으로 이체되며, 거버넌스 계정의 잔액은 인센티브 및 급여 분배 제안에 대한 투표를 통해 할당됩니다. 제안이 투표를 통해 통과되면 다중 서명의 방식을 통해 자동으로 분배됩니다.

출판사 : PlatONWorld-KR, 재 인쇄 소스를 지정하십시오 :https://platonworld.org/kr/platonkorea/%ea%b1%b0%eb%b2%84%eb%84%8c%ec%8a%a4-%eb%a9%94%ec%bb%a4%eb%8b%88%ec%a6%98/

Like (0)
Previous 7월 23, 2021 12:00
Next 9월 1, 2021 18:28

相关推荐

답글 남기기

Please Login to Comment