Openzeppelin & Compound Governance Part 1

엘리시아가 온체인 거버넌스를 구현하기 위해 Compound 거버넌스를 뜯어본 1부다. 제안 생성부터 집행까지의 전체 절차와 각 단계의 기간, 투표권 위임 구조, 그리고 실제 31번 제안의 트랜잭션 input data 를 디코딩해 인자 하나하나를 확인하는 데까지 간다.

핵심 포인트

OpenZeppelin 은 Compound 거버넌스의 audit 을 진행하면서 Compound 와 협업해, 그와 유사하되 더 모듈화·개선된 거버넌스 라이브러리를 4.3 에 내놓았다.
Compound 거버넌스는 Comp(투표권 토큰), GovernorBravo(제안·투표), Timelock(지연 실행) 세 컨트랙트로 구성된다.
절차는 제안 생성 → 이틀 리뷰 → 3일 투표 → 통과 시 이틀 대기(queue) → 집행(execute) 순이며, queue 와 execute 는 누구나 실행할 수 있다.
Comp 1개가 투표권 1개이며, 65,000개 이상 보유자는 Governance Proposal 을 직접 올릴 수 있다.
그 진입장벽이 너무 높다는 논란(당시 가격 기준 약 300억원 이상) 때문에 토큰 100개로도 올릴 수 있는 Autonomous Proposal 이 등장했다.

상세 정리

거버넌스의 정의를 프로토콜 참여자 간의 자율적 의사결정 과정으로 두고 시작한다.
Proposal 의 실체는 "어떤 컨트랙트의 어떤 함수를 어떤 인자로 실행할 것인가" 를 미리 저장해 둔 데이터다.
그래서 파라미터 변경뿐 아니라 컨트랙트 업그레이드도 Proposal 로 처리할 수 있다. 결국 누군가 코드를 실행하는 일이므로 미리 세팅해 두고 투표에 부치는 구조다.
Autonomous Proposal 의 조건: 바로 투표가 시작되지 않고, 자신을 지지하는 위임 투표권이 65,000개를 넘어야 시작된다. 제안은 쉽게, 진입은 어렵게 설계한 셈이다.
투표권은 직접 행사하거나 대리자에게 위임(delegation)할 수 있다.
`GovernorBravo` 의 이름은 Alpha 에 이은 버전 2 라는 뜻이며, Compound 거버넌스의 42번째 투표에서 Bravo 로 마이그레이션이 이뤄졌다.
`propose` 함수는 targets, values, signatures, calldatas, description 다섯 인자를 받는다. 여러 validation 을 거친 뒤 새 Proposal 구조체를 만들며, startBlock 과 endBlock 은 자동 생성된다.
실제 사례 분석: 31번 제안은 각종 CToken 의 `reserveFactor` 를 조정하는 내용이며, Created 트랜잭션의 input data 를 디코딩해 인자를 확인한다.
`targets` 는 대상 컨트랙트 주소들로, 이 제안에서는 여러 CToken 이다.
`values` 는 전송할 이더 양이며, 함수 실행에 이더가 필요 없어 전부 0 이다.
`signatures` 는 호출할 함수의 인터페이스로 `_setReserveFactor(uint256)` 가 들어 있다.
`calldatas` 는 함수 인자이며, 16진수를 변환하니 75000000000000000 즉 7.5%×10^18 로 제안 상세와 일치했다.