ERC-1202 온체인 투표 인터페이스 (Voting Interface)
Review · 기타 · 2018-07-08 작성
스마트 컨트랙트로 투표를 만들고 표를 던지고 결과를 조회·실행하는 공통 인터페이스입니다. 어떤 호환 컨트랙트에서든 같은 방식으로 투표에 참여하고 결과를 체인에 표준 형식으로 남길 수 있게 합니다.
왜 필요한가
투표는 EVM 프로그래밍의 가장 오래된 사례 가운데 하나이고, DAO(탈중앙 자율 조직)와 조직 거버넌스의 핵심 절차입니다. 그런데 공통 표준이 없으면 프로젝트마다 투표 컨트랙트를 제각각 만들게 되고 여러 DAO의 투표를 한 화면에서 다루는 범용 앱이나 UI를 만들기 어려워 더 많은 사용자의 참여를 이끌기 힘듭니다. 투표 결과가 표준 형식으로 체인에 기록되지 않으면 다른 컨트랙트나 DAO가 그 결과를 읽어 프로그램으로 집행하기도 어렵습니다. 이 표준은 투표하기, 결과 보기, 투표 상태 설정을 위한 공통 API를 정의해 범용 투표 UI, 위임 투표와 자동 투표, 결과의 표준적인 온체인 기록, ERC-20·ERC-721 같은 토큰 표준과의 호환, 토큰 수량에 따른 투표 가중치 기록, 투표 마감 시한 설정 같은 기능의 토대를 마련하려고 합니다.
구현해야 하는 것
function execute(uint256 proposalId, bytes memory extraParams) payable external;: 제안 번호 proposalId에 해당하는 제안을 실행합니다.function votingPeriodFor(uint256 proposalId) external view returns (uint256 startPointOfTime, uint256 endPointOfTime);: 해당 제안의 투표 시작 시점과 종료 시점을 알려 줍니다.function eligibleVotingWeight(uint256 proposalId, address voter) external view returns (uint256);: 해당 제안에서 특정 주소가 행사할 수 있는 투표 가중치를 알려 줍니다.
심층 설명
필수 인터페이스 IERC1202Core
표준을 따르는 컨트랙트는 IERC1202Core를 반드시 구현해야 합니다(MUST). castVote는 제안 번호 proposalId, 선택지 support, 가중치 weight, 사유를 담은 reasonUri, 추가 데이터 extraParams를 받아 표를 던집니다. castVoteFrom은 같은 정보에 투표자 주소 from을 더해 다른 주소를 대신해 투표를 제출할 때 씁니다. execute는 proposalId에 해당하는 제안을 실행합니다. 투표가 접수되면 VoteCast 이벤트로 투표자, 제안 번호, 선택지, 가중치, 사유가 기록됩니다. 세 함수 모두 payable로 선언되어 호출 시 이더를 함께 보낼 수 있습니다.
다중 선택 투표 IERC1202MultiVote
IERC1202MultiVote는 선택 구현(MAY)이지만 순위 선택 투표나 가중치를 달리 나누는 투표처럼 여러 선택지를 지원하려는 컨트랙트라면 반드시 구현해야 합니다(MUST). castMultiVote는 선택지 배열 uint8[] support와 가중치 배열 uint256[] weight를 받아 한 번의 호출로 여러 선택지에 표를 나눠 던지고 결과를 MultiVoteCast 이벤트로 기록합니다. 단일 선택이면 핵심 인터페이스만으로 충분하고 복잡한 투표 방식이 필요할 때만 이 인터페이스를 더하는 구조입니다.
조회 인터페이스와 ERC-5269
IERC1202Info는 투표 정보를 읽는 view 함수를 정의합니다. votingPeriodFor(proposalId)는 투표 시작 시점 startPointOfTime과 종료 시점 endPointOfTime을 돌려주고 eligibleVotingWeight(proposalId, voter)는 특정 주소가 그 제안에서 행사할 수 있는 가중치를 돌려줍니다. 가중치 분배는 컨트랙트 내부에서 결정되거나 생성자(constructor)에서 설정된다고 전제합니다. 또 호환 컨트랙트는 인터페이스 지원 여부를 알리는 ERC-5269를 구현하는 것이 권장됩니다(SHOULD).
의도적으로 범위에서 뺀 것들
이 표준은 네 가지를 의도적으로 다루지 않습니다. 첫째, 위임(delegation)은 별도 EIP로 다룰 수 있도록 제외했습니다. 둘째, 투표 자격과 가중치 계산 방식도 제외했습니다. OpenZeppelin의 GovernorBravo 구현이 쓰는 스냅샷이나 쿼드러틱 보팅 같은 계산이 그 예이고 이 표준은 현재와 미래의 가중치 계산 방식을 모두 수용할 만큼 유연하게 설계되었습니다. 셋째, 제안(proposal)의 내용은 proposalId로 식별만 할 뿐 온체인 여부나 실행 가능 여부는 다루지 않으며 ERC-5247 같은 별도 제안에 맡깁니다. 넷째, 오프라인 서명을 모아 다른 계정이 트랜잭션을 올리는 서명 집계·보증도 범위 밖이며 ERC-5453이 그 예입니다.
설계 배경: 투표 공개와 익명성
원문 근거(Rationale)는 특정 주소의 투표를 쉽게 확인할 수 있도록 ballotOf라는 view 함수를 만들었다고 설명합니다. 구현자가 투표 내역 공개를 원하지 않으면 이 함수 호출을 전부 거부하는 방식으로 익명 투표를 지원할 수 있습니다. 다만 스마트 컨트랙트 호출은 모두 블록 기록에 남으므로 암호학 기법을 쓰지 않는 한 비밀이 크게 보장되지는 않는다고 밝힙니다. 또 각 주소는 하나의 결정에만 투표한다고 가정하며 투표력을 여러 선택지에 나누고 싶은 사용자는 새 지갑 주소를 만들어 토큰 일부를 옮긴 뒤 두 계정에서 각각 투표하는 방식을 쓸 수 있다고 설명합니다.
하위 호환성과 제안 상태
선택지 support의 자료형을 uint8로 정한 것은 널리 쓰이는 거버넌스 컨트랙트인 GovernorBravo와의 하위 호환성을 위해서이며 원문은 이 크기를 미래에 키울 수 있다고 밝힙니다. 한편 이 제안은 2018년에 만들어져 현재 검토(Review) 상태입니다. 아직 최종 확정되지 않아 명세가 바뀔 수 있는 제안이므로, 구현하려는 개발자는 원문의 최신 상태를 확인하는 것이 좋습니다.
쓸 때 주의할 점
- 표준 인터페이스의 용도를 한정해야 합니다: 이 표준은 토큰 분배, 합의에 따른 행동, 다중 서명 지갑 같은 다른 컨트랙트와 연결되어 쓰일 것으로 예상됩니다. 핵심 보안 고려 사항은 표준 인터페이스가 후속 동작의 수행과 투표 접수라는 입력 수신에만 쓰이도록 보장하는 것이며 향후 감사 도구도 표준 인터페이스를 기반으로 만들어질 것으로 기대됩니다.
- 중복 투표의 해석이 정해져 있지 않습니다: 이 표준은 단순함을 위해 아주 기본적인 형태로 유지되었습니다. 같은 사람이 여러 번 투표하면 가중치를 늘리는 것인지, 여러 선택지에 투표하는 것인지, 나중 투표가 이전 투표를 덮어쓰는 것인지 같은 해석은 구현마다 다를 수 있습니다. 이 표준의 확장이나 구현은 대규모·고액 자산 애플리케이션에 쓰기 전에 철저히 감사받아야 합니다.
- 익명성·무작위성·마감 시한은 구현이 어렵습니다: 익명성, 무작위성, 시간 기반 마감, 순서 보장 같은 요구사항은 이더리움에서 달성하기 쉽지 않은 것으로 알려져 있습니다. 이런 요구를 강제해야 하는 애플리케이션이나 조직은 감사를 거치고 오래 검증된 공유 라이브러리에 의존할 것을 권합니다.
- 매표와 이해충돌 악용 가능성: 투표가 표준화되어 온체인에 오르면 특정 방향으로 투표한 사람에게 보상을 주는 별도 컨트랙트를 만들 수 있게 됩니다. 이전에는 구현하기 어려웠던 매수(bribery)와 이해충돌 악용 문제가 생길 수 있습니다.