Vitalik 및 다양한 로드맵이 Ethereum 거버넌스 프로세스에 미치는 영향
원저자: ZeroDev CEO Derek Chiang
원본 편집: Faust, geek web3
개요: 이 기사는 Buterin이 ERC-4337과 EIP-3074 사이의 모순을 해결하기 위해 EIP-7702를 제안한 이후 이 문제에 대한 ZeroDev CEO Derek Chiang의 견해입니다. AA 생태계 내 프로젝트 창립자의 개인적인 경험을 바탕으로 이 기사는 이더리움의 현재 거버넌스 모델과 그 문제점을 객관적으로 지적하고 요점을 지적했습니다.
이더리움의 다양한 거버넌스 모순 중 하나는 연구자들이 결정한 로드맵과 Geth 등 클라이언트 개발팀의 견해 차이에 있으며, Vitalik은 CTO와 유사한 역량으로 최종 말이 되었습니다.
Derek은 Vitalik의 역할에 대해 긍정적인 평가를 한 후 Ethereum이 거버넌스 모델에서 어떤 개선을 해야 하는지 지적했는데, 이는 Ethereum 커뮤니티와 Bitcoin 커뮤니티 모두에게 좋은 참고 자료입니다.
텍스트: 이전에 Ethereum AA(계정 추상화)와 관련된 이벤트를 이해하지 못했다면 여기에 간단한 검토가 있습니다.
몇 주 전, EIP-3074 제안은 이더리움 핵심 개발자들에 의해 승인되었으며 다음 하드포크 "Pectra"에 포함될 예정입니다. 이 제안은 EVM에 두 개의 새로운 opcode를 제공하여 Ethereum EOA 계정에 거의 기본 AA 경험을 제공합니다.
그 이후로 ERC-4337 커뮤니티의 많은 사람들, 특히 4337 제안자들은 이 제안이 많은 보안 위험을 가져오고 이더리움의 AA 로드맵과 일치하지 않을 것이라는 우려를 이유로 EIP-3074에 강력하게 반대해 왔습니다. 이더리움의 이전 로드맵에서는 ERC-4337 및 유사한 제안 7560("nativeAA"라고도 함)을 중심으로 한다는 것이 명확하게 명시되어 있습니다.
5월 초 Vitalik은 EIP-3074의 대체품으로 EIP-7702를 제안하여 4337과 3074 사이의 균형을 유지했습니다. 이는 EOA 사용자에게 AA 경험을 제공할 수 있지만 어느 정도 ERC-4337과 더 유사합니다. "AA 최종 솔루션" 7560.
현재 이더리움 핵심 개발자들은 EIP-7702를 고려하고 있습니다. 현재 예비 토론 결과와 커뮤니티 정서는 EIP-7702가 위에서 언급한 EIP-3074를 대체할 가능성이 있음을 나타냅니다.
개인적으로 저는 이 결과에 매우 만족합니다. EOA 사용자는 곧 ERC-4337 생태계 내에서 다양한 제품을 경험하고 AA가 제공하는 대부분의 혜택을 누릴 수 있게 될 것입니다. 그러나 지난 몇 주 동안 많은 사람들이 지적한 것처럼 위의 결과를 달성할 수 있는 더 나은 방법이 있다고 생각하지 않을 수 없습니다. 더 나은 거버넌스 프로세스를 통해 우리는 많은 노력을 절약하고 원하는 결과를 훨씬 더 빨리 얻을 수 있었다고 생각합니다.
이 기사에서 내가 원하는 것은:
거버넌스 프로세스에서 무엇이 잘못되었는지 확인
이더리움 거버넌스에 대한 사고를 위한 정신적 모델 제안
향후 유사한 거버넌스 사고를 방지하기 위해 개선 사항을 권장합니다.
EIP-3074 사건 요약 및 반영
위에서 언급한 이야기는 많은 사람들을 화나게 했습니다. 그 이유는 다음과 같습니다.
EIP-3074는 승인을 받는 데 몇 년이 걸렸습니다. Ethereum 핵심 개발자가 4337 커뮤니티의 반발에 직면한 것은 3074가 최종적으로 승인된 이후였습니다.
반면, ERC-4337 작성자들은 EIP-3074에 대한 우려를 이더리움 핵심 팀에 반복적으로 표명했지만 소용이 없었습니다. 이제 이더리움은 3074를 승인 취소하고 다른 EIP(7702)로 대체할 계획입니다.
위의 프로세스에는 본질적으로 잘못된 것이 없습니다.
EIP에 대한 논의가 수년이 걸리는 것은 정상입니다.
EIP가 승인된 후 거부되는 것은 정상입니다.
EIP 승인 후 새로운 문제가 발견되면 승인이 취소될 수 있습니다.
그러나 상황이 더 원활하게 진행될 수도 있었습니다. 상황이 다음과 같이 흘러간다고 상상해 봅시다:
3074에 대해 논의하는 동안 4337 커뮤니티는 Ethereum 핵심 개발자와 적극적으로 협력했습니다. 이 전제가 사실이라면 결과는 두 가지뿐입니다.
4337 커뮤니티 피드백을 고려한 후 제안 3074가 승인되고 수정될 수 있으며, 이 경우 4337 커뮤니티는 이를 수락하고 Ethereum 핵심 팀은 이를 철회할 필요가 없습니다.
또는 3074는 승인되지 않았지만 4337 커뮤니티와 Ethereum 핵심 팀이 협력하여 7702처럼 모두가 만족할 수 있는 제안을 내놓았습니다.
모두의 목소리가 들리고 드라마틱한 반전은 없다. 그러면 정말 좋았을 텐데 왜 그렇지 않았나요?
무엇이 잘못되었나요?
전 과정을 돌이켜보면 사건의 양측은 서로를 비난하고 있다.
이더리움 핵심 개발자(및 EIP-3074 작성자)는 EIP가 오랜 과정을 거쳐야 하는 ACD(All Core Developers) 토론 과정에 적극적으로 참여하지 않았기 때문에 이것이 "4337 후원자"의 잘못이라고 생각합니다. 심의를 거쳐 최종적으로 Geth 및 기타 Ethereum 클라이언트 개발 팀에 의해 승인되고 구현될 것입니다.
일부 사람들은 제안 3074가 고려되는 동안 제안 3074가 승인될 때까지 기다렸다가 나중에 반응하는 대신 "4337 지지자"가 완전히 참여하고 자신의 견해를 표현할 수 있다고 믿습니다. 결국, 전체 ACD 프로세스는 잘 문서화되어 있고 회의는 누구에게나 열려 있으며 TimBeiko와 같은 사람들은 ACD 회의가 끝난 후 적극적으로 요약 트윗을 게시합니다. 그렇다면 4337 서포터들이 이 주제에 대해 그토록 많은 관심을 갖고 있다면, 왜 관련 모임에 적극적이고 신속하게 참여하지 않는 걸까요?
반면 4337 핵심 멤버들은 ACD 회의에 최대한 참석해 3074에 반대해왔다는 점을 지적했지만 이더리움 핵심 개발자들은 듣지 않았다. 4337 커뮤니티 회원들의 경우 대부분 의외라고 느꼈습니다. 많은 사람들은 3074가 이미 식어버렸다고 생각했고, 3074가 승인될 가능성이 높다는 사실조차 몰랐습니다.
많은 사람들은 ACD 회의의 전체 과정이 이더리움 커뮤니티에서 "진지하게 일하지만" 적시에 ACD 업데이트 진행 상황을 추적할 수 없는 사람들에게 매우 불투명하고 비우호적이었다는 점을 지적했습니다. 일부 사람들은 ACD가 이해관계자(이 경우 4337 커뮤니티)로부터 적극적으로 피드백을 요청해야 한다고 믿습니다.
그러나 나는 양쪽 모두 요점을 놓치고 있다고 생각합니다. 이 뒤에는 더 깊은 문제가 있으며, 우리가 이를 해결하거나 적어도 인정하지 않는 한 양측이 서로를 비난하는 거버넌스 사고에 계속 갇히게 될 것입니다.
사고의 근본 원인 해결: 로드맵
대중적인 믿음과는 달리, 거버넌스 사고의 근본 원인은 ACD가 이더리움 프로토콜 업데이트에 대한 거버넌스 권한의 유일한 소스가 아니고 다른 거버넌스 권한 소스로 대체되었다는 것입니다. 여기서 문제는 또 다른 거버넌스 권한이 AA 및 확장성과 같은 핵심 Ethereum 문제에 대해 ACD보다 더 많은 영향력을 갖고 있음에도 불구하고 거의 인정되지 않는다는 것입니다.
이 글에서 나는 이 힘을 '로드맵'이라고 부른다.
아래에서 지적하겠지만, "3074-4337-7702" 거버넌스 실패 사건 전체는 이더리움의 기존 로드맵의 힘이 ACD의 힘을 압도한 사건이다. 거버넌스에 관해 이야기할 때 보이는 힘을 압도하는 보이지 않는 힘이 있다는 것을 알게 되면 이에 대해 극도로 걱정해야 합니다. 왜냐하면 보이지 않는 것은 종종 설명하기 어렵고 너무 많은 사람들이 알아차릴 수 없기 때문입니다. 노출되어야 합니다.
로드맵이란 무엇입니까?
Ethereum 커뮤니티에 있는 사람이라면 누구나 "롤업 중심 로드맵", "ETH 2.0 로드맵" 또는 이 경우 "AA 로드맵"에서 "로드맵"이라는 단어를 자주 보았을 것입니다.
요점을 설명하기 위해 핵심 개발자들이 Ethereum 확장 방법을 논의하는 ACD 회의를 상상해 보겠습니다.
핵심 개발자 Bob: 저는 EIP-1234를 지지합니다. 이 제안에서는 블록 생성 속도를 10배 높이고, 블록 크기를 10배 늘리고, 수수료를 100배 낮추자고 제안합니다.
다른 핵심 개발자: ...당신 미쳤어요?
그것에 대해 생각해 봅시다. Ethereum 핵심 팀은 왜 Bob의 말을 거부했습니까? 그는 매우 합리적으로 보이는 확장 방법을 제안했으며, 이를 통해 매우 높은 TPS를 달성했습니다.
그 이유는 이 가상의 EIP-1234가 이더리움의 "롤업 중심" 확장 로드맵을 위반하기 때문입니다. 이는 분산화를 위해서는 일반 사용자가 저렴한 비용으로 노드를 실행할 수 있는 것이 중요하다는 점을 지적합니다. 따라서 가상의 EIP-1234는 가능성이 낮습니다. Ethereum 노드를 실행하는 데 드는 비용이 크게 증가하므로 허용됩니다.
저는 이 예를 사용하여 ACD 거버넌스 프로세스에 참여하고 프로토콜 업데이트를 결정하는 핵심 개발자가 "로드맵"이라고 부르는 더 높은 수준의 힘에 의해 안내된다는 점을 설명하고 싶습니다. 현재 이더리움의 로드맵을 둘러싸고 있는 '확장 로드맵', 'AA 로드맵', 'MEV 로드맵' 등이 있으며, 이들이 함께 이더리움의 전체 로드맵을 구성하고 있으며 핵심 개발자는 이를 기반으로 작업을 수행해야 합니다.
핵심 개발자의 관점이 로드맵과 일치하지 않는 경우
로드맵은 이더리움 거버넌스 프로세스의 공식적인 부분이 아니기 때문에 핵심 팀이 로드맵을 준수할 것이라는 보장이 없는 경우가 많습니다. 게다가 로드맵을 "승인"하는 공식적인 프로세스가 없기 때문에 모든 로드맵이 똑같이 "정통"인 것은 아닙니다. Ethereum 로드맵 뒤에 있는 연구자들은 "합법성"을 얻고 이를 통해 Ethereum 핵심 개발 팀의 지원을 얻기 위해 핵심 개발자와 커뮤니티에 로드맵을 홍보하기 위해 열심히 노력해야 합니다.
AA 및 계정 추상화와 관련하여 Vitalik 자신은 여러 차례 4337 중심의 AA 로드맵을 추진했지만 일반적으로 포럼과 ACD에서 4337을 옹호한 사람은 주로 4337 뒤에 있는 팀, 특히 Yoav와 Dror입니다. 회의 중심의 AA 로드맵.
그러나 이러한 노력에도 불구하고 일부 Ethereum 핵심 개발자는 4337 중심의 AA 로드맵에 여전히 강력하게 반대하고 있습니다. 그들은 7560(향후 이더리움 클라이언트에 의해 구현될 4337의 기본 버전)이 너무 복잡하고 "AA 결말"을 위한 유일한 실행 가능한 솔루션이 아니라고 믿습니다. 결국 ACD는 제안 3074를 승인하기로 결정했지만, 이는 3074가 전체 AA 생태계를 분열시킬 것이라고 믿었던 4337 팀의 반대에도 불구하고 이루어졌습니다.
3074가 승인된 후 전체 4337 커뮤니티가 강력하게 반응하여 Ethereum 핵심 개발자가 3074 토론에 다시 참여하도록 했습니다. 그러다가 논의는 교착상태에 빠졌고, 4337의 작성자도 3074의 작성자도 서로 설득할 수 없었습니다. 마지막 순간에 Vitalik은 3074의 대안으로 EIP-7702를 제안했는데, 이는 'AA 엔딩' 중심으로 명확하게 호환됩니다. 4337에서 갈등을 해결하고 최종 결과가 AA 로드맵에 잘 들어맞도록 했습니다.
Vitalik의 역할: Ethereum의 사실상 CTO
Vitalik은 자신을 연구원이라고 밝히지만, 위의 이야기를 통해 Vitalik은 다른 연구원들과는 별개의 거버넌스 권한을 가지고 있음이 분명해졌습니다. 따라서 질문이 생깁니다. Vitalik은 Ethereum 거버넌스에서 어떤 역할을 합니까?
개인적으로 비탈릭을 매우 큰 회사의 CTO로 생각하는 것은 아마도 부적절하지 않을 것이라고 생각합니다. (그런데 현실적으로 이더리움의 "회사"에는 CEO가 없다고 가정합시다)
직원이 50명 이상인 기술 회사에서 근무한 적이 있다면 CTO가 모든 기술 결정에 참여할 수는 없다는 것을 알고 있을 것입니다. 회사가 특정 규모에 도달하면 다양한 기술 솔루션에 대한 의사 결정 프로세스가 필연적으로 분산됩니다. 일반적으로 회사의 제품/비즈니스의 각 영역에는 전담 팀이 있으며, 이 팀은 일반적으로 세부 사항을 자유롭게 결정할 수 있습니다. 해결책.
게다가 CTO가 반드시 모든(또는 모든) 주제에 대한 최고 전문가일 필요는 없습니다. 회사에는 특정 분야에서는 CTO보다 뛰어난 엔지니어가 있을 수 있습니다. 따라서 기술적인 세부 사항을 논의할 때 최종 결정을 내리는 것은 엔지니어 개인인 경우가 많습니다.
그러나 CTO는 회사의 기술 비전을 설정합니다. 비전의 실행은 개발자의 몫입니다.
이것이 완벽한 비유는 아니지만, 이더리움 생태계에서 Vitalik의 역할을 합리적으로 요약한다고 생각합니다. Vitalik은 모든 기술적 결정에 관여하지 않으며, 그럴 수도 없습니다. 그는 모든 분야의 최고 전문가도 아니다. 그러나 그는 기술적 전문성뿐만 아니라 "로드맵이 이더리움 비전과 일치하는지 여부( 그의 비전의 최종 판사).
모든 성공적인 제품은 비전에서 시작됩니다
Vitalik이 Ethereum의 CTO가 되는 것이 충분히 논란의 여지가 없다고 생각한다면, 가장 논란이 되는 부분이 있습니다: 우리는 Vitalik을 CTO로 받아들여야 합니다.
스타트업 창업자로서 저는 모든 성공적인 제품 뒤에는 일관된 장기 비전이 있어야 한다고 믿습니다. 그렇습니다. Ethereum은 실제 사용자의 실제 문제를 해결하기 때문에 "제품"이기도 합니다. 일관성 있는 비전은 스타트업 창업자와 같은 소수의 사람들에 의해 개발되어야 하며, 종종 단 한 명의 창업자에 의해서도 개발되어야 합니다.
이더리움의 장점은 수많은 구성 요소가 포함된 매우 복잡한 시스템임에도 불구하고 구성 요소가 완벽하게 결합되어 매일 수십억 달러의 거래 활동을 결제하는 잘 갖춰진 분산형 컴퓨터를 형성한다는 것입니다.
우리는 일부 위원회의 설계를 통해서가 아니라 오늘날의 일관되고 아름다운 이더리움을 만들 수 있었던 것은 Vitalik의 비전과 적극적인 리더십 덕분이었습니다. 이더리움은 2015년 Vitalik의 아이디어였으며 오늘날에도 여전히 그렇습니다.
물론, 이것이 현재의 이더리움을 만드는 데 많은 책임을 맡고 있는 다른 연구자와 엔지니어들의 기여를 폄하하는 것은 아닙니다. 그러나 이더리움은 다른 누구보다 훨씬 더 큰 Vitalik의 비전을 구현한 것이기 때문에 이것은 모순이 아닙니다.
솔직히, 그것에 대해 불평할 수 있나요? 이더리움 생태계의 개방성, 검열 저항, 혁신 속도에 매력을 느끼면서도 그것이 비탈릭의 비전에서 시작됐다고 불평한 적이 있나요? 아마도 당신은 그런 식으로 생각하지 않았기 때문에 불평하지 않았을 것입니다. 하지만 지금은 그렇게 생각하고 있지만 정말 괜찮습니까?
탈중앙화를 어떻게 해결하나요?
하지만 분권화는 어떻습니까? 한 사람이 이더리움에 대해 이렇게 압도적인 힘을 가지고 있다면 어떻게 그것이 탈중앙화되었다고 말할 수 있습니까?
이 질문에 답하려면 Vitalik이 쓴 분산화의 의미에 관한 고전적인 기사를 검토해야 합니다. 이 기사의 핵심 통찰력은 탈중앙화에는 세 가지 유형이 있다는 것입니다.
아키텍처 분산화: 얼마나 많은 노드 장애로 인해 시스템 작동이 중단됩니까?
논리적 분산화: 전체 시스템이 정상적으로 작동하도록 하면서 시스템의 각 하위 시스템을 독립적으로 개발할 수 있습니까? 아니면 긴밀하게 조율해야 합니까?
정치적 분권화: 궁극적으로 시스템을 통제하는 사람이나 조직은 얼마나 됩니까?
이러한 정의에 따르면 이더리움은 분명히 구조적으로 분산되어 있으며 다양한 구성 요소(예: 합의 계층과 실행 계층) 간의 강력한 결합이 부족하기 때문에 논리적으로도 분산되어 있다고 주장할 수 있습니다.
정치적 분권화 측면에서 좋은 소식은 어떤 개인이나 조직도 이더리움을 폐쇄할 수 없다는 것입니다. Vitalik도 마찬가지입니다. 그러나 Vitalik이 Ethereum의 비전과 로드맵을 개발하는 데 중요한 역할을 했기 때문에 Ethereum의 정치는 생각만큼 분산되어 있지 않다고 주장할 수도 있습니다.
그러나 나는 이더리움이 계속 혁신하기를 원한다면 정치적 분권화를 희생하더라도 Vitalik을 사실상의 CTO로 받아들여야 한다고 믿습니다.
Ethereum이 Bitcoin과 같은 거의 불변의 블록체인에 실제로 "견고"하다면 Vitalik은 직접 은퇴할 수 있습니다. 그러나 마지막 단계에 도달하기 전에 모든 당사자가 존중하고 제안된 기술 솔루션이 우수한지 여부뿐만 아니라 다음을 기반으로 기술 결정에 대한 판단을 내릴 수 있을 만큼 신뢰할 수 있는 권한을 갖는 것이 중요합니다. 그러한 결정이 이더리움의 비전과 일치하는지 여부.
Vitalik과 같은 사람이 없으면 두 가지 결과만 가능하며, 두 가지 모두 3074를 둘러싼 이야기에서 생생하게 설명됩니다.
Ethereum 거버넌스 프로세스는 Vitalik이 개입하기 전에 3074 논쟁이 교착 상태에 도달했기 때문에 어느 쪽도 타협할 의지가 없고 누구도 진전을 이룰 수 없는 끝없는 교착 상태에 빠질 수 있습니다.
또는 이더리움은 일관되지 않은 "사람"을 가진 프랑켄슈타인이 될 수 있습니다. 앞서 언급한 3074와 4337은 서로 양보하지 않을 수도 있으며, 결국 AA 생태계는 호환되지 않는 두 개의 병렬 공간으로 완전히 분리됩니다.
공동체의 역할
위의 생각 후에 우리는 이더리움 거버넌스에 대한 완전한 사고 모델의 개요를 거의 설명하고 있지만 지금까지 우리의 논의에서 커뮤니티라는 부분이 명백히 누락되었습니다.
Vitalik이 Ethereum의 비전을 정의하고, 연구자가 로드맵을 정의하고, 핵심 개발자가 로드맵을 구현한다면 커뮤니티는 어떤 역할을 합니까? 당연히 아무것도 하지 않는 것과 같지 않습니까?
다행히도 커뮤니티는 실제로 가장 중요한 역할을 합니다. 그 이유는 비전이 있기 전에 가치가 있기 때문입니다. 우리는 특정 가치를 중심으로 단결하기 때문에 하나의 커뮤니티로 모이고 Vitalik의 비전은 궁극적으로 이러한 가치와 일치해야 하며 그렇지 않으면 커뮤니티의 지원을 잃게 됩니다.
이더리움 커뮤니티의 모든 사람들은 모든 사람이 액세스할 수 있고 검열되지 않고 신뢰할 수 있으며 중립적인 분산형 컴퓨터를 갖는 것이 세상에 좋을 것이라고 믿습니다. 우리는 Ethereum에서 매일 수행하는 작업을 통해 위의 가치를 지지하고 확인하며 이를 통해 Vitalik, 연구원 및 핵심 개발자가 개발한 비전, 로드맵 및 코드에 정당성을 제공합니다.
이더리움 거버넌스의 VVRC 모델
따라서 Ethereum 거버넌스, 가치 ⇒ 비전 ⇒ 로드맵 ⇒ 클라이언트 또는 줄여서 VVRC의 완전한 정신 모델은 다음과 같습니다.
V==가치==커뮤니티;
V==비전==비탈릭;
R==로드맵==연구원;
C==클라이언트==핵심 개발자;
이들은 함께 다음과 같은 역할을 수행합니다.
커뮤니티는 특정 가치를 중심으로 뭉칩니다.
Vitalik은 이러한 가치와 일치하는 비전을 표현합니다.
연구원들은 비전을 기반으로 로드맵을 개발합니다.
핵심 개발자는 로드맵에 따라 클라이언트를 구현합니다.
물론 현실은 단순한 모델이 포착할 수 있는 것보다 훨씬 더 복잡합니다. 실제로 Ethereum 핵심 개발자는 클라이언트 코드 변경을 통해 실제로 제안에 "투표"할 수 있는 유일한 사람입니다. Vitalik 및 기타 연구자들은 자문 역할만 수행하며 때로는 핵심 개발자가 그들의 의견을 수용하지 않는 경우가 있기 때문에 EIP-3074가 승인되었습니다.
그런데 VVRC 모델은 이더리움의 거버넌스 모델이 정상적인 상황에서 어떻게 작동하는지 합리적으로 포착하고 있으며, EIP-3074와 같은 일이 다시 발생하지 않도록 프로세스를 "디버깅"해야 한다고 생각합니다.
Ethereum의 거버넌스 모델을 개선하는 방법
이제 우리는 이더리움 거버넌스 프로세스가 어떻게 작동하는지에 대한 정신적 모델을 가지게 되었으며 이를 개선하기 위한 몇 가지 아이디어를 제시합니다.
고려 중인 EIP에 대한 논의 진행 상황에 대한 가시성이 높아져야 합니다. 전체 커뮤니티는 EIP가 승인된 것에 "놀라"서는 안 되며, 3074와 같은 놀라운 제안 승인 방법이 다시 나타나서는 안 됩니다.
EIP 웹사이트에 있는 EIP의 현재 "상태"는 ACD 프로세스의 상태를 반영하지 않습니다. 그렇기 때문에 핵심 개발자들이 승인하기로 투표했고 애초에 승인을 고려했다는 징후조차 없음에도 불구하고 3074가 여전히 "검토 중"이라고 표시되는 이유입니다.
이상적으로는 EIP가 승인되려고 할 때 Ethereum Foundation은 커뮤니티 인식을 높이기 위해 소셜 미디어에 결과를 크고 명확하게 발표하는 것입니다.
때때로 핵심 개발자는 3074 및 4337 커뮤니티의 경우처럼 특정 EIP가 다운스트림 프로젝트 및 사용자에 미치는 영향을 과소평가할 수 있습니다. ACD 회의는 시간이 제한되어 있고 시간대에 따라 조율되어야 하므로 회의에서 "관련 담당자"만 발언할 수 있는 경우가 많습니다.
그렇긴 하지만, 특정 EIP 제안이 채택될 경우 커뮤니티 구성원이 후속 영향에 대해 논평할 수 있도록 때때로 발언 시간을 할당하는 것이 합리적입니다.
연구자들이 4337의 경우처럼 자신의 의견이 핵심 개발자들에게 잘 받아들여지지 않는다고 생각한다면, 커뮤니티 회원들에게 자신의 주장을 강화하기 위해 참여하도록 요청할 수 있습니다.
핵심 개발자와 연구자는 서로 다른 강점에도 불구하고 모두 이더리움 거버넌스의 일부라는 사실을 서로 인식하는 것이 중요합니다. 이더리움 클라이언트를 변경하고 업데이트할 수 있는 핵심 개발자의 권리는 프로토콜 자체를 변경하여 "투표"할 수 있는 유일한 권리입니다. 로드맵을 변경하고 해석할 수 있는 연구자의 권리는 일반적으로 연구자가 자신의 아이디어에 대해 적극적으로 이야기하고 글을 쓰는 덕분에 대중의 지지를 더 많이 받습니다.
이 두 세력이 충돌할 때 핵심 개발자는 연구원의 의견을 직접 뒤집는 경향이 있을 수 있습니다. 예를 들어 핵심 개발자는 4337 팀의 반대를 뒤집었습니다. 그러나 그러한 전복은 3074의 승인에 뒤따른 극적인 사건이 보여 주듯이 두 강대국이 충돌할 때 불안정해질 수 있기 때문에 갈등으로 이어질 수 있습니다.
마찬가지로, 저항에 직면하면 연구자들은 핵심 개발자와의 협력을 포기하고 싶은 유혹을 받을 수 있습니다. 제 생각에는 이것이 RIP 프로세스가 만들어진 이유 중 하나이며 기본 AA(7560)가 이제 대부분 RIP가 아닌 RIP로 수행되는 이유 중 하나입니다. EIP 승진 이유.
L1에 논란의 여지가 있는 프로토콜 업데이트를 실험하는 L2에는 실질적인 이점이 있지만 RIP를 EIP 거버넌스 프로세스에 참여하는 대신 사용할 수는 없습니다. 연구원들은 양 당사자의 가치가 로드맵에 완전히 부합할 때까지 핵심 개발자와 계속 협력해야 합니다.
결론적으로
3074/7702 사건은 이더리움 거버넌스가 실제로 어떻게 작동하는지를 보여주었습니다. 핵심 개발자가 주도하는 EIP/ACD 프로세스의 명시적인 거버넌스 능력 외에도 연구원이 주도하는 로드맵의 암묵적인 거버넌스 능력도 있습니다. 이러한 힘이 잘못 정렬되면 정체 현상과 채찍질이 발생하며 어떤 방식으로든 균형을 맞추려면 또 다른 힘인 Vitalik이 필요할 수 있습니다.
그런 다음 우리는 Vitalik이 모든 로드맵의 정당성의 기초가 되는 독특한 힘, 즉 Ethereum의 "비전"을 대표한다고 제안합니다. 우리는 Vitalik을 대기업의 CTO에 비유하며 이더리움이 혁신의 속도를 유지하여 이더리움이 "프랑켄슈타인" 스타일의 스티치 몬스터로 변질되는 것을 방지하려면 유사 CTO로서의 그의 역할이 필요하다는 점을 인정합니다.
마지막으로 이더리움 거버넌스 모델을 설명하는 VVRC 모델을 제안합니다: 가치(커뮤니티) ⇒ 비전(Vitalik) ⇒ 로드맵(연구원) ⇒ 클라이언트(핵심 개발자). 그런 다음 이 모델의 "버그"를 수정하는 다양한 방법을 제안합니다.
이더리움 거버넌스는 "기계를 만드는 기계"입니다. 이더리움이 올바르게 작동하려면 합리적인 거버넌스가 있어야 합니다. 따라서 3074는 거버넌스 사건의 귀중한 예를 제공하며, 이더리움 커뮤니티가 향후 이더리움 거버넌스 프로세스를 개선하기 위해 이로부터 유용한 교훈을 배울 수 있기를 바랍니다.
