온체인 거버넌스: 기술 스택 설명

거버넌스는 정치적 프로세스처럼 이야기되지만, 그 뒤에 있는 메커니즘은 순수한 소프트웨어 엔지니어링이다: 스마트 컨트랙트, 토큰 회계, 그리고 누가 시스템을 변경할 수 있는지와 어떻게 변경할 수 있는지를 결정하는 컨센서스 규칙. DAO를 평가하거나 프로토콜 업그레이드 경로를 살펴본다면, 미션 스테이트먼트를 읽는 것보다 기술 스택을 이해하는 것이 더 중요하다.

핵심 구성 요소

대부분의 온체인 거버넌스 시스템은 작은 부분들로 구성되어 있다:

• 투표 컨트랙트 — 제안을 추적하고, 투표를 집계하며, 정족수 임계값을 적용
• 토큰 또는 평판 가중치 — 특정 주소의 투표가 얼마나 중요한지 결정 (토큰 가중, 이차, 또는 위임)
• 타임락 컨트랙트 — 통과된 제안 실행을 지연시킴. 보통 24-72시간. 변경이 적용되기 전에 사용자가 반응할 수 있도록
• 실행 모듈 — 투표가 통과된 후 실제로 영향을 받는 컨트랙트를 호출하는 코드 경로

Compound의 Governor Bravo와 OpenZeppelin의 Governor 컨트랙트는 대부분의 새로운 프로젝트가 포크하거나 확장하는 참조 구현이다. 하나의 코드베이스를 읽어 패턴을 이해하고 싶다면 OpenZeppelin의 Governor.sol을 읽어라. 충분히 주석이 달려 있고 전체 제안 생명 주기를 보여준다: 제안, 투표, 큐, 실행.

제안이 실제로 시스템을 통해 어떻게 움직이는가

제안은 단순히 비공식적으로 투표되는 포럼 게시물이 아니다. 온체인에서는 calldata다: 대상 컨트랙트 주소, 함수 선택자, 그리고 인코딩된 파라미터. 누군가 거버넌스 제안을 제출할 때, 그들은 투표가 통과되면 실행될 정확한 트랜잭션을 제출하는 것이다.

흐름은 일반적으로 다음과 같다:

1. 제안자가 calldata와 설명을 제출하며, 스팸을 방지하기 위해 최소 토큰 잔액이 필요한 경우가 많다
2. 투표 지연 (일반적으로 1 블록에서 며칠)이 발생하여 투표가 시작되기 전에 보유자가 검토할 시간을 갖는다
3. 투표 기간이 진행된다 (Compound는 기본적으로 대략 3일을 사용하지만, 많은 포크는 더 긴 기간을 설정한다)
4. 정족수와 승인 임계값이 충족되면 제안이 타임락으로 들어간다
5. 타임락 지연 후 누구나 execute를 호출하여 트랜잭션을 실행할 수 있다

투표 종료와 실행 사이의 간격은 보안 백스톱이다. 커뮤니티가 악의적이거나 버그가 있는 제안을 발견할 수 있는 창이며, 극단적인 경우 긴급 대응을 조정할 수 있다 — 프로토콜이 긴급 가디언 역할이나 멀티시그 오버라이드를 가지고 있다고 가정할 때. 초기 단계 거버넌스에서는 많은 프로토콜이 이를 갖추고 있다.

가중치 로직이 복잡해지는 곳

단순한 토큰 가중 투표는 알려진 문제가 있다: 가장 많은 토큰을 보유한 사람이 결과를 제어하며, 투표자 참여도는 보통 낮다. 일부 거버넌스 포럼은 일상적인 제안에 대해 순환 공급량의 한 자리 수 퍼센트의 참여도를 보고한다.

프로젝트들은 여러 개선책을 시도했다:

• 위임 — 토큰 보유자가 토큰을 이전하지 않고 투표력을 위임자에게 할당한다. Compound와 Uniswap이 대표 투표를 처리하는 방식이다
• 이차 투표 — 추가 투표의 비용이 이차적으로 증가하여 고래 지배를 줄이려고 한다. 다만 Sybil 저항 (한 사람이 많은 주소를 만드는 것)은 여전히 미해결 문제다
• 확신 투표 — 일부 Gitcoin 인접 도구에서 사용되며, 투표력이 토큰이 한 입장에 유지되는 기간이 길수록 축적되어 스냅샷 투표보다 지속된 선호도를 선호한다

이들 중 어느 것도 토큰 투표의 낮은 참여도, 플루토크래시 성향의 역학을 완전히 해결하지 못한다. 이들은 완화책이지, 해결책이 아니다. 그리고 다른 주장을 하는 어떤 용어 설명도 기술을 과장하고 있다.

체인 외 신호 대 온체인 실행