거버넌스 살펴보기 #1 : 이더리움
거버넌스 살펴보기 시리즈를 통해 우리가 사용하고 있는 블록체인 기반의 제품/인프라들의 의사결정 과정이 어떻게 일어나고 있는지를 하나씩 살펴보고 목적성 및 구성원들의 성격에 따라 어떤 거버넌스 구조를 차용하고 있는지 알아볼 예정이다. 그 첫번째 시작은 이더리움이다.
*상기 내용은 이더리움 재단이 공유한 내용을 기반으로 한다.
거버넌스란?
이더리움에 대한 기술적 분석 및 역사는 이미 너무 좋은 글들이 많기에 바로 거버넌스에 대해 이야기 해보자.
이더리움 거버넌스 페이지에서는 거버넌스를 다음과 같이 정의한다.
“거버넌스는 결정을 내릴 수 있도록 하게 해주는 시스템이다”
실제로 거버넌스의 사전적 정의 그리고 기업 관점에서의 정의도 이와 비슷한데, 대체로 운영 및 의사 결정을 하게 해주는 시스템 또는 방식이라고 서술한다.
기존 중앙화 시스템에서 디렉터 또는 이사진들이 회사의 방향성을 정하는 것, 주주들이 안건에 투표하여 변화를 이끌어내는 것, 정치인들이 법안을 제출하여 유권자들을 대변하는 것 모두 거버넌스라는 시스템을 기반으로 작동하는 행위이다.
즉, 지금까지 사회에서의 보편적으로 통용되던 “거버넌스”라는 것은 중앙화 상태에서의 “의사 결정 시스템”을 포괄하는 단어였으며 이는 블록체인에서 이야기하는 “거버넌스 = 탈중앙화” 공식과는 매우 다른 개념으로 존재해왔다.
탈중앙화 거버넌스
탈중앙화된 거버넌스라는 것은 정의에 따라 천차만별이지만 이더리움은 이를 “특정 소유 주체가 존재하지 않은 상태에서의 의사 결정 과정을 통해 네트워크의 지속성과 번영을 가능케 하는 시스템” 이라고 정의 한다.
소유 주체가 없는 시스템에서 전통적으로 받아들여져왔던 거버넌스는 탈중앙화 세상에서 적합하지 않기에 이에 맞는 “탈중앙화된 거버넌스”가 필요하다는게 이더리움 거버넌스의 논제이다.
이더리움의 거버넌스
이더리움의 거버넌스는 프로토콜 상에서 어떤 변화들이 일어날지를 결정하는 의사결정 프로세스이다. 이는 프로토콜을 누가 사용할 수 있는지에 대한 “권한” “허가’에 대한 프로세스가 아니라, 프로토콜 상에서 일어날 수 있는 변화에 대한 건의/실행을 할 수 있는 프로세스이며 이는 이더리움 생태계에 의존하는 사람들의 규모를 고려하여 매우 높은 수준의 기준이 요구된다.
블록체인에서 사용되는 거버넌스는 크게 On-Chain, Off-Chain, 하이브리드으로 나누어 지는데, On Chain 거버넌스의 경우 제안된 프로토콜의 변화가 이해관계자들의 허가를 통해 통과되면 바로 코드로 적용되거나 또는 거버넌스 토큰을 행사하여 투표하는 구조를 뜻하며 반면 Off-Chain의 경우 포럼 및 소셜 미디어에서 소프트 컨센서스를 빌딩하기 위한 논의가 이루어지고 이를 추후에 Council 또는 권한을 위임 받은 집단이 결정하여 프로토콜에 적용하는 구조이다. 하이브리드는 Off, On-Chain 모두를 차용한 구조를 뜻한다.
On-Chain 거버넌스의 대표적 예시로는 Tezos, EOS등이 있고 Off-Chain 거버넌스의 예시로는 비트코인, 이더리움이 있다.
이더리움의 이해관계자
이더리움 홀더: 이더리움을 소유한 사람들
어플리케이션 유저: 이더리움 위에서 작동하는 어플리케이션을 사용하는 사람들
어플리케이션 개발자: DeFi, NFT, 지갑 등의 어플리케이션을 개발하는 사람들
Node 운영자: 블록과 거래기록들을 전파하는 노드를 운영하는 사람들
EIP Authors: EIP를 통해 이더리움 프로토콜의 변화에 대해 건의하는 사람들
검증인: 노드를 통해 블록 검증 및 추가 하는 사람들
프로토콜 개발자: 흔히 코어 개발자라고 불리는 이더리움에 프로토콜에 기여하는 개발자들
EIP: Ethereum Improvement Proposals
이더리움의 거버넌스는 EIP 형식을 기반으로 진행되는데 이는 이더리움의 프로토콜 변화에 대한 안건을 제출할때 사용되는 표준 형식이다 (비트코인의 거버넌스 형식인 BIP을 참고해 탄생했다). EIP는 프로토콜 상의 변화가 어떻게 일어나고 문서화 되어야 하는지에 대한 기준을 제시하여 제안, 논의, 반영등의 과정들이 매끄럽게 일어날 수 있도록 하는 목정성을 가지고 있다.
<EIP 형식>
EIP에 대해서는 EIP1: EIP Purpose and Guidelines에서 자세히 다루고 있으며 크게 세가지 형식을 가지고 있다.
Standards Track
Standards Track은 이더리움 체인에 직접적으로 변화를 주는 안건이다. 블록 및 거래 기록 검증 법칙, Application Standard, 프로토콜의 상호작용성 등이 이에 포함된다. Standards Track 안에서도 종류에 따라 다음과 같은 카테고리로 세분화된다.
Core : 컨센서스 포크가 필요한 개선 (EIP-5, EIP-101) 또는 그만큼 중요한 안건으로 코어 개발자들의 논의가 필요한 안건
Networking : devp2p 그리고 Light Ethereum Subprtocol에 대한 개선
Interface : Client API/RPC에 대한 개선 및 기준에 대한 이름 변경
ERC : 토큰 스탠다드 등 어플리케이션 단게의 기준 정의
Meta EIP
Meta EIP는 이더리움과 관련된 프로세스에 대한 개선과 관련단 안건이다. Standard Track과 비슷 하지만 Meta EIP에서 제안되는 안건들은 프로토콜의 코드에 직접적인 변화/영향을 주는 것들이 아니며 의사결정 프로세스, 가이드라인, 환경 등에 프로토콜 외부 조건에 대한 개선에 관한 것들이다.
Informational EIP
Informatioal EIP의 경우 이름 그대로 정보 전달을 목적으로 하는 EIP이다. 위 두 EIP는 개선안의 성향을 띈다면, Informational EIP의 경우 정보/이슈를 서술 하는 것에 초점을 맞춘 EIP이다. Meta EIP에서는 커뮤니티의 컨센서스가 필요할 정도의 안건들이 공유되기에 이해관계자들이 쉽게 무시할 수 없는 반면, Informational EIP 경우는 이더리움 커뮤니티의 목소리를 대변하는 것이 아니기에 이해관계자들이 원한다면 굳이 팔로우 업 하지 않아도 된다.
<EIP 템플릿/상태>
EIP의 승인과정을 알아보기전에 먼저 EIP 템플릿과 EIP의 상태에 대해 알아보자
EIP 템플릿
EIP: EIP Number (EIP Editor의해 결정됨)
Title: 제목은 완성된 문장이 아닌 짧은 단어들
Description: 하나의 짧은 문장
Author: EIP를 작성하는 사람들의 이름/이메일
Discussions-to: EIP의 토론 내용이 담긴 URL
Status: 안건의 상태 - Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living
Last-call-deadline: Last call 기간이 끝나는 날짜 (이는 뒤에서 추가적으로 설명할 예정)
Type: 위에서 언급한 EIP의 형식 Standards Track, Meta, Informational 중 하나
Category: Standards Track일 경우 Core, Networking, Interface, or ERC 중 선택
Created: EIP가 생성된 날짜
Requires: EIP Number
Withdrawal-reason: EIP가 작성자에 의해 철회되었을떄 그 이유를 명시
<EIP 상태>
Idea - 드래프트 전 단계로 아이디에이션 정도의 상태
Draft - EIP 형식을 갖춘 상태로 안건의 발전 및 수정을 위해 EIP repository에 포함됨
Review - Peer Review를 받기 준비된 상태
Last Call - 최종승인 되기 전에 마지막으로 리뷰가 진행되는 상태로 약 14일 정도의 기간을 가지는 상태
Final - 승인되어 최종 기준으로 선택된 상태. Final EIP는 에러 수정 또는 기준에 영향을 주지 않는 설명을 추가할때만 편집되어야 함
Stagnant - Draft, Review, 또는 Last Call 상태에서 어떠한 활동도 6개월 동안 발생하지 않으면 Stagnant 상태로 전환됨. Draft 상태로의 전환은 EIP Editor들을 통해 가능
Withdrawn - EIP 작성자가 제출한 EIP를 회수한 사태. 한번 Withdrawn 되면 Stagnant와 달리 구제가 불가능
Living - EIP1 처럼 Final 상태에 도달하지 않고 계속 업데이트가 되어야 하는 안건들의 상태
EIP의 승인 과정
Core EIP기준으로 이를 승인하고 프로토콜에 적용하는 하는 과정을 보면 크게 5가지로 나누어진다.
Core EIP 생성하기 - Core카테고리에 들어가는 EIP를 생성하고 이더리움 커뮤니티 포럼인 이더리움Magicians 또는 이더리움 리서치를 통해 커뮤니티의 반응 및 피드백을 수용하는 단계이다
EIP를 Protocol Core Developer들에게 제출하기 - Protocol Core Developer들은 이더리움 프로토콜의 핵심 개발자/리서쳐들로 이루어진 집단이며 Core EIP의 적용여부에 핵심적인 역할을 하는 집단이기도 하다. 제출자 (Authors)는 EIP를 All Core Devs Call에 제출하여야 하는데 이는 EIP가 다음 네트워크 업데이트떄 포함될지 여부를 논의하는 자리이다. 제출을 위해 충족되어야 하는 조건은 다음과 같다
EIP가 EIP Editors들에 의해 EIPs Repository에 등록. 이는 EIP 상태 페이지 등을 통해 현재 진행되고 있는 EIP들을 관리하기 위함
EIP Editor는 누구인가?
EIP Editor는 제안된 EIP들이 형식을 잘 갖추었는지, 기술적으로 합리적인지 등에 대한 판단을 내리며 작성자와 소통 및 EIP 상태 관리 등을 담당하는 역할군이다.
Editor 관련해서는 안수빈님의 “EIP 누가 담당하나요? (feat. EIP-5069)”에 잘 설명되어 있다.
Core 카테고리에 속하는 EIP일 것
EIP 상태가 “Draft” 또는 “Review”일 것
*조건을 충족한 EIP는 크게 세 종류의 결과를 맞이한다.
다음 네트워크 업데이트에서 고려 대상이 된다
기술적 수정이 요구된다
우선순위가 아니거나 기술적 노력에 비해 중대하지 않은 안건인 경우 거절된다
Final 상태를 위해 반복하기 - 대체로 처음 제출한 EIP는 수많은 피드백과 수정을 거치면서 안건을 개선되며 이 과정에서 Protocol Core Developer들에게 여러번 제출하는 과정을 거친게 된다
EIP를 Network 업데이트에 포함하기 - EIP가 승인되었다면 관련 기술적 사항을 테스트 하여 다음 업데이트에 포함하게 된다.
Network 업데이트 활성화하기 -승인된 EIP 테스텟넷에서 우선적으로 활성화되고 이더리움 메인 Network에서 활성화된다. 이때 노드들은 새로운 버전으로 소프트웨어를 업데이트하여 동의 표시를 행사한다.
만약 업데이트 내용에 동의하지 않는다면?
보통의 경우에는 충분한 기간동안 오프체인에서 컨센서스를 빌딩하는 과정을 통해 EIP가 네트워크 업데이트 적용되기에 모두가 “행복한 결과(?)”를 맞이하지만 여전히 업데이트에 동의하지 않는 집단들이 존재할 수 있다.
만약 동의하지 않는다면 노드들은 업데이트를 반영하지 않는 방식으로 거부 의사를 표시할 수 있으며, 이 경우 통과된 EIP가 반영된 메인 체인과 그렇지 않은 체인으로 나누어지기 되며 “Chain Split”이 발생하게 된다.
대표적인 예시가 2016년 발생한 The DAO Hack으로 인한 Chain Split이다. 경위를 간단히 설명하자면,
The DAO는 투자자들이 참여하는 형태의 VC로써 설립되어 약 2000억원 어치의 이더를 DAO Token 발행을 통해 모금하였다.
하지만 컨트랙의 취약점이 발견되어 약 800억원의 이더가 해커에 의해 털리는 사태가 발생. (이는 이더리움 네트워크의 문제가 아닌 The DAO 컨트랙의 문제였다).
이더리움 커뮤니티는 해커를 블랙리스트 처리하는 코드를 추가하여 빼았긴 이더를 동결하는 소프트 포크 방안을 제안했는데, 이에 해커는 소프트 포크에 반대하는 채굴자들에게 약 100만 이더리움 +100 비트코인 풀을 통해 제공하겠다는 제안을 하며 맞불을 놓았다.
다음 방안은 이더리움 네트워크를 The DAO 해킹 전으로 롤백하여 모금된 이더를 투자자들에게 돌려주는 하드 포크였다.
이더리움 생태계의 이해관계자들의 열띤 논의 끝에 2016년도 7/20일에 하드 포크가 실행되었고 이에 동의하지 않는 사람들은 포크가 되지 않은 오리지널 이더리움 체인을 추종하기로 하였고 이것이 현재 “이더리움 클래식”으로 알려진 체인이다.
*하드 포크 반대 진영들은 하드 포크가 블록체인의 근간인 불변성을 해친다고 주장 + 네트워크의 문제가 아닌 하나의 프로젝트로 인해 하드포크를 실행하는 것이 과연 맞는 판단인가에 대한 의문을 제기했다.
TL:DR
There is no “right” Governance
애초에 거버넌스 시리즈를 쓰는 이유는 어느 거버넌스 모델이 정답인가를 판단해보고자 함이 아니라, 각기 다른 조직들이 어떤 목적성을 가지고 그에 맞는 그들만의 거버넌스 모델을 운영하고 있는지 알아보고 추후에 더 많은 조직들이 목적성에 따라 차용할 수 있는 거버넌스 스탠다드를 만드는데 일조하고자 함이다.
이더리움 거버넌스는 이더리움이라는 국가 내에 여러 이해관계자들이 공존하는 최대 규모의 인프라 레이어라는 특성에 기반하여 누구나 안건과 의견을 자유롭게 제출할 수 있지만 EIP Editors 및 Core Developere들이 거버넌스 과정에 직접적인 영향을 끼치는 Filtering형식에 가까운 거버넌스 구조를 차용하고 있다.
이더리움의 정신적 지주와도 같은 비탈릭은 이더리움과 달리 다른 프로토콜 DAO들에서 많이 사용되는 거버넌스 온체인 투표만을 위해 존재하는 거버넌스 토큰 구조에 대해 회의적인 반면, 생태계의 직접적으로 기여하는 이해관계자들이 온체인 상에서 본인의 의견을 행사할 수 있는 권리를 가진다는 점에서 거버넌스 토큰 (다른 Cash Flow를 생성해내지 않아도)의 존재에 당위성을 부여하는 사람들이 있는 것 처럼 조직마다 추구하는 가치 및 구성원의 형태에 따라 “적합한” 거버넌스가 존재할 뿐 “정답”인 거버넌스는 없는 듯 하다.
다음 번에는 어떤 거버넌스를 다루어 볼까?