Protocol DAO (pDAO)
Rocket Pool Protocol DAO(pDAO)는 프로토콜의 방향을 결정하는 책임을 지며 RPL 거버넌스에 의해 운영됩니다. 구성원과 투표권은 프로토콜에 직접 참여하는 대소 노드 운영자들로 구성됩니다. pDAO는 rETH 보유자, 노드 운영자, RPL 보유자를 포함한 Rocket Pool 커뮤니티 전체를 위해 봉사합니다. pDAO는 Rocket Pool 프로토콜의 안전과 Ethereum 네트워크의 건강을 우선시합니다. pDAO가 누구이고 무엇인지에 대한 명시적인 정의는 pDAO 헌장을 참조하세요.
Houston의 새로운 pDAO 기능
pDAO 책임의 온체인 실행
Houston 업그레이드는 pDAO 거버넌스 시스템의 실행 프로세스에 대한 온체인 대체 시스템을 도입합니다. 이는 낙관적 사기 증명 시스템을 사용하여 모든 노드 운영자가 제안을 제기하고 "pDAO 프로토콜 매개변수" 조정 및 재무 자금 지출에 대한 제안에 투표할 수 있도록 합니다. pDAO가 제어할 수 있는 매개변수의 전체 목록을 보려면 여기를 클릭하세요. Houston 이전에는 핵심 팀이 커뮤니티 거버넌스 프로세스의 요청에 따라 pDAO 업무를 실행하는 책임을 지고 있었습니다. 예를 들어, 팀은 거버넌스 투표된 지불 일정에 따라 월별 IMC 및 GMC 지불을 수행합니다. 이 권한은 이러한 책임을 인계받을 새로운 권력 구조가 설정될 때까지 팀이 일시적으로 보유하는 계획이었습니다. Houston은 팀에 대한 이러한 의존성을 제거하여 프로토콜을 더 분산화되고 신뢰가 필요 없게 만듭니다.
Security Council
Houston 업그레이드에는 프로토콜의 잠재적 문제에 대해 신속하게 대응할 수 있는 새로운 보안 위원회도 포함되어 있습니다. 이러한 구성원은 pDAO에 의해 선출될 수 있으며 지연 없이 변경을 제안하고 실행할 수 있는 능력을 가집니다. pDAO는 보안 위원회의 구성원을 선출하고 제거할 권한을 가집니다. 이것은 중요한 역할이며 pDAO는 강력한 진입 요구 사항과 오래된 구성원을 교체하는 프로세스를 개발해야 합니다. pDAO 가디언은 Houston 시작 시 보안 위원회의 유일한 구성원이 됩니다.
반복적인 재무 지출
RPL은 5%의 인플레이션율을 가지고 있습니다. 이 인플레이션의 22%는 RPIP-25에 정의된 대로 pDAO로 전달됩니다. pDAO는 이 자금을 다양한 목적으로 사용할 수 있습니다. 예를 들어, 유동성 공급자(LP) 보너스와 같은 인센티브, 제3자 개선 및 프로젝트를 위한 보조금 및 현상금, Rocket Pool 프로토콜 개발 자금 지원 등이 있습니다. Houston 업그레이드는 각 보상 기간마다 지정된 수혜자에게 반복적인 재무 지불을 가능하게 하는 새로운 기능도 도입합니다.
Protocol DAO (pDAO) 제안
0이 아닌 투표권을 가진 모든 노드는 언제든지 pDAO 제안을 제기하거나 참여할 수 있습니다. 제안은 다음 유형 중 하나일 수 있습니다:
- pDAO 설정 변경
- 일회성 재무 지출
- 반복적인 재무 지출 (관리 위원회)
- Security council 멤버십
자세한 내용과 근거는 제안 유형을 참조하세요. pDAO 제안은 프로토콜 수준에서 변경을 실행하기 위해 존재하는 온체인 엔티티라는 것을 이해하는 것이 중요합니다.
pDAO 제안의 수명 주기
제안은 온체인에 올라가기 전에 거버넌스 프로세스에 의해 예고되어야 합니다. 제안은 4개의 기간으로 구성되며, 이 모든 기간은 pDAO 제어 가능한 매개변수입니다:
- Vote Delay Period:
proposal.vote.delay.time - Vote Phase 1:
proposal.vote.phase1.time - Vote Phase 2:
proposal.vote.phase2.time - Execution:
proposal.execute.time
Vote Delay Period
제안의 결과를 결정하기 위해 프로토콜은 필요한 정족수를 알아야 합니다. 제안자는 이 값을 오프체인에서 계산하고 제안과 함께 제출합니다. 이 값은 낙관적으로 받아들여지지만, 사기가 발생한 경우 검증자는 챌린지/응답 프로세스를 수행하여 값이 올바르지 않음을 증명할 수 있습니다. 유효하지 않은 제안은 폐기됩니다.
제안자와 챌린저가 RPL을 잠가야 하는 몇 가지 이유가 있습니다.
proposal.bond는 유효한 제안을 장려하고 스팸을 억제합니다.proposal.challenge.bond는 유효하지 않거나 악의적인 제안을 제거하도록 장려합니다.
챌린저는 올바르지 않다고 주장하는 Merkle-sum 트리의 인덱스를 제공합니다. 모든 노드 운영자는 사기성 제안에 도전하는 데 참여할 수 있으며 (그렇게 함으로써 보상을 받을 수 있습니다). 참여에 관심이 있다면 pDAO 챌린지 프로세스에 대해 자유롭게 읽어보세요. 투표 지연 기간이 끝날 때까지 챌린지에서 패배하지 않은 제안은 투표 단계로 진입합니다.
proposal.vote.delay.time이 만료되면 제안은 더 이상 챌린지받거나 패배할 수 없습니다.
Vote Period 1
투표 기간 동안 노드 운영자와 위임자는 다음 네 가지 옵션 중 하나로 투표할 수 있습니다:
그들의 투표권은 선택한 옵션에 포함됩니다.
다음 명령을 사용하여 수행할 수 있습니다:
거부권 정족수(proposal.veto.quorum 매개변수에 의해 정의됨)가 충족되면 제안은 즉시 패배하고 제안자는 보증금을 잃습니다. 이는 스팸, 저품질 제안 또는 오프체인 프로세스를 먼저 거치지 않은 제안을 억제하기 위한 것입니다. smartnode 명령 rocketpool pdao proposals finalize은 제안자의 잠긴 RPL 보증금을 소각하여 거부된 제안을 마무리하는 데 사용됩니다.
기간 1의 기간은 proposal.vote.phase1.time 매개변수에 의해 결정됩니다. 제안은 proposal.quorum이 충족되는지 여부와 관계없이 2단계로 전환됩니다.
Vote Period 2
위임자는 투표 기간 2 동안 투표할 수 있지만, 그들의 투표는 로컬 투표권만큼만 가치가 있습니다. 기간 1에서 투표하지 않은 투표자는 여전히 기간 2 동안 투표할 수 있습니다. 위임자의 선택에 동의하지 않는 노드 운영자는 위임자의 투표를 뒤집을 기회를 갖습니다.
투표를 뒤집는 과정은 매우 간단합니다. 투표 기간 2 동안 rocketpool pdao proposals vote를 호출하고 안내에 따르세요. 위임자의 투표권은 위임받은 사람의 투표권에 의해 뒤집힙니다.
제안의 결과는 투표 기간 2가 끝나면 결정됩니다. 결과가 결정되고 실행되려면 proposal.vote.phase2.time이 끝날 때까지 proposal.quorum 총 투표권이 도달해야 합니다. 정족수가 충족되고 합의가 도달하면 제안은 투표 기간을 통과하고 성공으로 표시됩니다.
proposal.quorum이 충족되지 않으면 더 이상의 조치를 취할 수 없습니다. 정족수가 충족되지 않으면 제안은 종료되고 최종적인 것으로 간주됩니다.
Execution
두 투표 기간이 모두 지나고 제안이 성공하면, 제안을 실행할 수 있으며 변경 사항(페이로드에 의해 정의됨)이 Rocket Pool 프로토콜에 적용됩니다. 제안을 실행하려면 다음 명령을 사용하세요:
실행할 제안을 선택하라는 메시지가 표시되며, 이 단계 후에 제안이 프로토콜에 적용됩니다!
제안이 투표 기간을 통과한 후, 제안자는 챌린지로 패배하거나 거부되지 않은 한 잠긴 RPL 보증금을 청구할 수 있습니다.
제안을 실행할 수 있는 기간 proposal.execute.time이 있습니다. 이 타이머가 끝에 도달하면 제안은 만료됩니다.
그것이 전부입니다! 위에서 언급한 모든 변수는 pDAO 제어 가능한 매개변수임을 명심하세요. pDAO가 온체인 제안을 사용하여 변경할 수 있는 권한이 있는 모든 매개변수의 전체 목록은 여기를 클릭하세요.
챌린지 프로세스
전체 네트워크 투표권 트리는 가스 제한으로 인해 오프체인에 저장됩니다. 사용자가 새 제안을 제출할 때 대상 블록 번호에서 네트워크 투표 트리를 구성할 책임이 있습니다. 이 트리는 오프체인에서 생성되지만 온체인에 제출된 Merkle 루트를 통해 검증할 수 있습니다. 프로토콜은 검증자에게 제안자가 제출한 세부 정보를 확인하는 것에 의존합니다.
모든 노드는 제안의 정확성을 추적하고 검증하는 데 참여할 수 있습니다. 이 책임을 선택하려면 rocketpool service config 명령을 사용하고 Smartnode and TX Fee Settings 메뉴로 이동한 다음 Enable PDAO Proposal Checker 상자를 선택하세요.
이 설정이 활성화되면 노드는 새 제안을 확인하고 정확성을 검증하며 유효하지 않은 제안에 대해 챌린지를 제출합니다. 유일한 전제 조건은 RPL Locking이 활성화되어 있어야 한다는 것입니다.
이 확인은 몇 가지 다른 노드 관련 작업과 함께 5분마다 실행됩니다. 사기성 제안에 대한 챌린지가 어떻게 보이는지 예제를 살펴보겠습니다. smartnode 명령 rocketpool service logs node를 사용하여 진행 상황을 모니터링할 수 있습니다:
우리 노드가 사기성 제안을 발견하고 이를 챌린지하는 프로세스를 시작했음을 볼 수 있습니다. 블록 1283202는 제안 177이 제기된 블록이며, 이는 이 제안에 대한 투표권이 블록 1283202에서 계산된다는 것을 의미합니다. 이러한 Voting Info Snapshots가 어떻게 보이는지 궁금하다면 이 디렉토리에서 찾을 수 있습니다: ~/.rocketpool/data/voting
제안자가 잘못된 투표 정보를 제출한 것이 발견되었기 때문에 우리 노드는 제안 177의 인덱스 5에서 계약 호출 Function: createChallenge를 수행하고 제안자가 챌린지에 응답하기를 기다립니다.
제안자의 투표 정보가 올바르지 않기 때문에 제안자는 제시간에 챌린지에 응답할 수 없습니다 (proposal.challenge.period에 의해 결정됨). 제안은 이 시점에서 패배한 것으로 간주됩니다. 제안이 패배하면 우리 노드는 제안 177의 인덱스 5에서 계약 호출 defeatProposal을 자동으로 수행하여 제안을 종료합니다.
제안을 패배시키는 데 참여한 챌린저는 올바르지 않은 것으로 입증된 인덱스를 제출하면 제안자의 보증금의 비례 금액을 지불받습니다. 다른 모든 챌린저는 보증금만 돌려받습니다.
이제 제안이 패배했으므로 우리 노드(챌린저)는 원래 RPL 보증금과 사기성 제안을 패배시킨 보상으로 제안자의 RPL 보증금을 청구할 수 있습니다.
pDAO 제안 및 챌린지 시스템의 세부 사항을 파고들고 싶다면 기술 사양을 살펴보세요. 낮은 수준의 세부 사항을 다루는 예제를 연구하는 데 관심이 있다면 챌린지 프로세스에 대한 이 섹션으로 건너뛰세요.