개요: 이 기사는 Buterin이 ERC-4337과 EIP-3074 사이의 모순을 해결하기 위해 EIP-7702를 제안한 이후 이 문제에 대한 ZeroDev CEO Derek Chiang의 견해입니다. AA 생태계 내 프로젝트 창립자의 개인적인 경험을 바탕으로 이 글은 이더 의 현재 거버넌스 모델과 문제점을 객관적으로 지적하고 요점을 지적했습니다.

이더 의 다양한 거버넌스 모순 중 하나는 연구자들이 결정한 로드맵과 Geth 등 클라이언트 개발팀의 견해 차이에 있으며, Vitalik은 CTO와 유사한 역량으로 최종 말이 되었습니다.

Derek은 Vitalik의 역할에 대해 긍정적인 평가를 한 후 이더 이 거버넌스 모델에서 어떤 개선을 해야 하는지 지적했는데, 이는 이더 커뮤니티와 Bitcoin 커뮤니티 모두에게 좋은 참고 자료입니다.

텍스트: 이전에 이더 AA(계정 추상화)와 관련된 이벤트를 이해하지 못했다면 여기에 간단한 검토가 있습니다.

몇 주 전, EIP-3074 제안은 이더 핵심 개발자들에 의해 승인되었으며 다음 하드 포크"Pectra"에 포함될 예정입니다. 이 제안은 EVM에 두 개의 새로운 opcode를 제공하여 이더 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는 승인을 받는 데 몇 년이 걸렸습니다. 이더 핵심 개발자가 4337 커뮤니티의 반발에 직면한 것은 3074가 최종적으로 승인된 이후 였습니다.

한편, ERC-4337의 작성자들은 EIP-3074에 대한 우려를 이더 핵심 팀에 반복적으로 표명했지만 소용이 없었습니다 . 이제 이더 3074를 승인 취소하고 다른 EIP(7702)로 대체할 계획입니다.

위의 프로세스에는 본질적으로 잘못된 것이 없습니다.

· EIP에 대한 논의가 수년이 걸리는 것은 정상입니다.

· EIP가 승인된 후 거부되는 것은 정상입니다.

· EIP 승인 후 새로운 이슈가 발견될 경우 승인이 취소될 수 있습니다.

그러나 상황이 더 원활하게 진행될 수도 있었습니다. 상황이 다음과 같이 흘러간다고 상상해 봅시다:

3074를 논의할 때 4337 커뮤니티는 이더 핵심 개발자와 적극적으로 상호 작용했습니다. 이 전제가 사실이라면 결과는 두 가지뿐입니다.

· 4337 커뮤니티 피드백을 고려한 후 제안 3074가 승인되고 수정될 수 있습니다. 이 경우 4337 커뮤니티는 3074를 수락하고 이더 핵심 팀은 3074를 철회할 필요가 없습니다.

· 또는 3074는 승인되지 않았지만 4337 커뮤니티와 이더 핵심 팀이 협력하여 7702처럼 모두가 만족할 수 있는 제안을 내놓았습니다.

모두의 목소리가 들리고 드라마틱한 반전은 없다. 그러면 정말 좋았을 텐데, 왜 그렇지 않을까요?

무엇이 잘못되었나요?

전 과정을 돌이켜보면 사건의 양측은 서로를 비난하고 있다.

이더 핵심 개발자(및 EIP-3074의 작성자)는 EIP가 긴 프로세스를 거쳐야 하는 ACD(All Core Developers) 토론 프로세스에 적극적으로 참여하지 않았기 때문에 이것이 "4337 후원자"의 잘못이라고 생각합니다. 심의를 거쳐 결국 Geth 및 기타 이더 클라이언트 개발 팀에 의해 승인되고 구현될 것입니다.

일부 사람들은 제안 3074가 고려되는 동안 제안 3074가 승인될 때까지 기다렸다가 나중에 반응하는 대신 "4337 지지자"가 완전히 참여하고 자신의 견해를 표현할 수 있다고 믿습니다. 결국, 전체 ACD 프로세스는 잘 문서화되어 있고, 회의는 누구에게나 열려 있으며, TimBeiko와 같은 사람들은 매 ACD 회의 후에 적극적으로 요약 트윗을 게시합니다. 그렇다면 4337 서포터들이 이 주제에 대해 그토록 많은 관심을 갖고 있다면, 왜 관련 모임에 적극적이고 신속하게 참여하지 않는 걸까요?

반면 4337 핵심 멤버들은 ACD 회의에 참석해 최대한 3074에 반대해왔다는 점을 지적했지만 이더 핵심 개발자들은 듣지 않았다. 4337 커뮤니티 회원들 대부분은 3074가 이미 식어버렸다고 생각하는 사람들이 많았고, 3074가 승인될 가능성이 높다는 사실조차 몰랐다는 생각이 대부분이었습니다.

많은 사람들은 ACD 회의의 전체 과정이 이더 커뮤니티에서 "진지한 일을 하는" 사람들에게 매우 불투명하고 비우호적이지만 적시에 ACD 업데이트 진행 상황을 추적할 수 없다는 점을 지적했습니다. 일부 사람들은 ACD가 이해관계자(이 경우 4337 커뮤니티)로부터 적극적으로 피드백을 요청해야 한다고 믿습니다.

그러나 나는 양쪽 모두 요점을 놓치고 있다고 생각합니다. 이 뒤에는 더 깊은 문제가 있으며, 우리가 이를 해결하거나 적어도 인정하지 않는 한 양측이 서로를 비난하는 거버넌스 사고에 계속 갇히게 될 것입니다.

사고의 근본 원인 해결: 로드맵

대중적인 믿음과는 달리, 거버넌스 사고의 근본 원인은 ACD가 이더 프로토콜 업데이트에 대한 거버넌스 권한의 유일한 소스가 아니었고 다른 거버넌스 권한 소스로 대체되었다는 것입니다. 여기서 문제는 또 다른 거버넌스 권한이 AA 및 확장성과 같은 핵심 이더 문제에 대해 ACD보다 더 많은 영향력을 갖고 있음에도 불구하고 거의 인정되지 않는다는 것입니다.

이 글에서 나는 이 힘을 '로드맵'이라고 부른다.

아래에서 지적하겠지만, "3074-4337-7702" 거버넌스 실패 사건 전체는 이더 의 기존 로드맵의 힘이 ACD의 힘을 압도한 사건이다. 거버넌스에 관해 이야기할 때, 보이는 힘을 압도하는 보이지 않는 힘이 있다는 것을 알게 되면 이에 대해 극도로 걱정해야 합니다. 왜냐하면 보이지 않는 것은 종종 설명하기 어렵고 너무 많은 사람들이 알아차릴 수 없기 때문입니다. 노출되어야 합니다.

로드맵이란 무엇입니까?

이더 커뮤니티에 있는 사람이라면 누구나 "집계 중심 로드맵", "ETH2.0 로드맵" 또는 이 사건과 관련된 "AA 로드맵" 그림"에서 "로드맵"이라는 단어를 자주 보았을 것입니다.

관점 설명하기 위해 핵심 개발자들이 이더 확장 방법을 논의하는 ACD 회의를 상상해 보겠습니다.

· 핵심 개발자 Bob: 블록 생성 속도를 10배 높이고, 블록 크기를 10배 늘리고, 수수료를 100배 낮추자고 제안하는 EIP-1234를 지지합니다.

· 기타 핵심 개발자: ...당신 미쳤어요?

그것에 대해 생각해 봅시다. 이더 핵심 팀은 왜 Bob의 말을 거부했습니까? 그는 매우 합리적으로 보이는 확장 방법을 제안했으며, 이를 통해 매우 높은 TPS를 달성했습니다.

그 이유는 이 가상의 EIP-1234가 이더 의 "롤업 중심" 확장 로드맵을 위반하기 때문입니다. 이는 탈중앙화 위해서는 일반 사용자가 저렴한 비용으로 노드를 실행할 수 있는 것이 중요하다는 점을 지적합니다. 이더 노드를 실행하는 데 드는 비용이 크게 증가하므로 받아 들여질 가능성이 없습니다.

저는 이 예를 사용 하여 ACD 거버넌스 프로세스에 참여하고 프로토콜 업데이트를 결정하는 핵심 개발자가 "로드맵"이라고 부르는 더 높은 수준의 힘에 의해 안내된다는 점을 설명하고 싶습니다. 현재 이더 의 로드맵을 둘러싼 "확장 로드맵", "AA 로드맵", "MEV 로드맵" 등이 있으며, 이들은 함께 이더 의 전체 로드맵을 구성하며 핵심 개발자는 이를 기반으로 작업을 수행해야 합니다.

핵심 개발자의 관점 로드맵과 일치하지 않는 경우

로드맵은 이더 거버넌스 프로세스의 공식적인 부분이 아니기 때문에 핵심 팀이 로드맵을 준수할 것이라는 보장이 없는 경우가 많습니다. 게다가 로드맵을 "승인"하는 공식적인 프로세스가 없기 때문에 모든 로드맵이 똑같이 "정통"인 것은 아닙니다. 이더 로드맵 뒤에 있는 연구자들은 "합법성"을 얻고 이를 통해 이더 핵심 개발 팀의 지원을 얻기 위해 핵심 개발자와 커뮤니티에 로드맵을 홍보하기 위해 열심히 노력해야 합니다.

AA 및 계정 추상화와 관련하여 Vitalik 자신은 여러 차례 4337 중심의 AA 로드맵을 추진했지만 일반적으로 포럼과 ACD에서 4337을 옹호한 사람은 주로 4337 뒤에 있는 팀, 특히 Yoav와 Dror입니다. 회의 중심의 AA 로드맵.

그러나 이러한 노력에도 불구하고 일부 이더 핵심 개발자는 4337 중심의 AA 로드맵에 여전히 강력하게 반대하고 있습니다 . 그들은 7560(향후 이더 클라이언트에 의해 구현될 4337의 기본 버전)이 너무 복잡하고 "AA 결말"을 위한 유일한 실행 가능한 솔루션이 아니라고 믿습니다. 결국 ACD는 3074 제안을 승인하기로 결정했습니다 . 비록 3074가 전체 AA 생태계를 분열시킬 것이라고 믿었던 4337 팀의 반대에도 불구하고 말입니다.

3074가 승인된 후 전체 4337 커뮤니티가 강력하게 반응하여 이더 핵심 개발자가 3074 토론에 다시 참여하도록 했습니다. 그러다가 논의는 교착상태에 빠졌고, 4337의 작성자도 3074의 작성자도 서로를 설득할 수 없었습니다. 마지막 순간에 Vitalik은 3074의 대안으로 EIP-7702를 제안했는데 , 이는 분명히 "AA 엔딩" 중심에 있었습니다. 4337에서 충돌을 해결하고 최종 결과가 AA 로드맵에 적합하도록 만들었습니다.

Vitalik의 역할: 이더 의 사실상 CTO

Vitalik은 자신을 연구원이라고 밝히지만, 위의 이야기를 통해 Vitalik은 다른 연구원들과는 별개의 거버넌스 권한을 가지고 있음 이 분명해졌습니다. 따라서 질문이 생깁니다. Vitalik은 이더 거버넌스에서 어떤 역할을 합니까?

개인적으로 비탈릭을 매우 큰 회사의 CTO로 생각하는 것은 아마도 부적절하지 않을 것이라고 생각합니다. (그런데 현실적으로 이더 의 "회사"에는 CEO가 없다고 가정합시다)

직원이 50명 이상인 기술 회사에서 근무한 적이 있다면 CTO가 모든 기술 결정에 참여할 수는 없다는 것을 알고 있을 것입니다. 회사가 일정 규모에 도달하면 다양한 기술 솔루션에 대한 의사 결정 프로세스는 필연적으로 분산됩니다. 일반적으로 회사의 제품/ 업무 의 각 영역에는 전담 팀이 있으며, 이 팀은 일반적으로 세부 사항을 자유롭게 결정할 수 있습니다. 해결책.

게다가 CTO가 반드시 모든(또는 모든) 주제에 대한 최고 전문가일 필요는 없습니다. 회사에는 특정 분야에서는 CTO보다 뛰어난 엔지니어가 있을 수 있습니다. 따라서 솔루션의 기술적 세부 사항을 논의할 때 최종 결정을 내리는 사람은 종종 개별 엔지니어입니다.

그러나 CTO는 회사의 기술 비전을 설정합니다. 비전의 실행은 개발자의 몫입니다.

이것이 완벽한 비유는 아니지만, 이더 생태계에서 Vitalik의 역할을 합리적으로 요약한다고 생각합니다. Vitalik은 모든 기술적 결정에 관여하지 않을 뿐만 아니라 그럴 수도 없습니다. 그는 모든 분야의 최고 전문가도 아니다. 그러나 그는 기술적 전문성뿐만 아니라 "로드맵이 이더 비전과 일치하는지 여부" 때문에 모든 주요 이더 계획(확장, AA, POS...)에 대한 로드맵을 공식화하는 데 압도적인 영향력을 갖고 있습니다. (그의 비전의 최종 판사).

모든 성공적인 제품은 비전에서 시작됩니다

Vitalik이 이더 의 CTO인 것이 충분히 논란의 여지가 없다고 생각한다면 가장 논란이 되는 부분이 있습니다. Vitalik을 CTO로 받아들여야 한다는 것입니다 .

스타트업 창업자로서 저는 모든 성공적인 제품 뒤에는 일관된 장기 비전이 있어야 한다고 믿습니다. 그렇습니다. 이더 실제 사용자의 질문을 해결하기 때문에 "제품"이기도 합니다. 일관성 있는 비전은 스타트업 창업자와 같은 소수의 사람들에 의해 개발되어야 하며, 종종 단 한 명의 창업자에 의해서도 개발되어야 합니다.

이더 의 장점은 수많은 구성 요소가 포함된 매우 복잡한 시스템임에도 불구하고 구성 요소가 완벽하게 결합되어 매일 수십억 달러의 거래 활동을 결제하는 잘 갖춰진 탈중앙화 컴퓨터를 형성한다는 것입니다.

우리는 일부 위원회의 설계를 통해서가 아니라 오늘날의 일관되고 아름다운 이더 만들 수 있었던 것은 Vitalik의 비전과 적극적인 리더십 덕분이었습니다. 이더 2015년 Vitalik의 아이디어였으며 오늘날에도 여전히 그렇습니다.

물론, 이것이 현재의 이더 만드는 데 많은 책임을 맡고 있는 다른 연구자와 엔지니어들의 기여를 폄하하는 것은 아닙니다. 그러나 이더 다른 누구보다 훨씬 더 큰 Vitalik의 비전을 구현한 것이기 때문에 이것은 모순이 아닙니다.

솔직히, 그것에 대해 불평할 수 있나요? 이더 생태계의 개방성, 검열 저항, 혁신 속도에 매력을 느끼면서도 그것이 Vitalik의 비전에서 시작됐다고 불평한 적이 있나요? 아마도 당신은 그런 식으로 생각하지 않았기 때문에 불평하지 않았을 것입니다. 하지만 지금은 그렇게 생각하고 있지만 정말 괜찮습니까?

탈중앙화 어떻게 해결하나요?

하지만 탈중앙화? 만약 한 사람이 이더 에 대해 그렇게 압도적인 힘을 가지고 있다면, 어떻게 그것이 탈중앙화 있다고 말할 수 있습니까?

이 질문에 답하려면 Vitalik이 쓴 탈중앙화 의 의미에 관한 고전적인 기사를 검토해야 합니다. 이 기사의 주요 통찰력은 탈중앙화 에는 세 가지 유형이 있다는 것입니다.

· 아키텍처 탈중앙화: 시스템이 정지되기 전에 몇 개의 노드가 실패할 것인가?

· 논리적 탈중앙화: 전체 시스템이 정상적으로 작동하도록 하면서 시스템의 각 하위 시스템이 독립적으로 발전할 수 있는가? 아니면 긴밀하게 조율해야 합니까?

· 정치적 분권화: 궁극적으로 시스템을 통제하는 사람이나 조직은 얼마나 됩니까?

이러한 정의에 따르면 이더 분명히 구조적으로 탈중앙화 있으며 다양한 구성 요소(예: 컨센서스 레이어 과 실행 계층) 간의 강력한 결합이 부족하기 때문에 탈중앙화 주장할 수 있습니다.

정치적 탈중앙화 측면에서 좋은 소식은 Vitalik은 물론 개인이나 조직이 이더 종료할 수 없다는 것입니다. 그러나 Vitalik이 이더 의 비전과 로드맵을 개발하는 데 중요한 역할을 했기 때문에 이더 의 정치적 탈중앙화 생각만큼 높지 않다고 주장할 수도 있습니다 .

그러나 저는 이더 계속 혁신하기를 원한다면 정치적 탈중앙화 희생하더라도 Vitalik을 사실상의 CTO로 받아들여야 한다고 믿습니다.

이더 실제로 Bitcoin과 같은 거의 불변의 블록체인으로 "견고"하다면 Vitalik은 직접 은퇴할 수 있습니다. 그러나 마지막 단계에 도달하기 전에 모든 당사자가 존중하고 제안된 기술 솔루션이 우수한지 여부뿐만 아니라 다음을 기반으로 기술 결정에 대한 판단을 내릴 수 있을 만큼 신뢰할 수 있는 권한을 갖는 것이 중요합니다. 그러한 결정이 이더 의 비전과 일치하는지 여부.

비탈릭과 같은 인물이 없다면 오직 두 가지 결과만이 가능하며, 두 가지 모두 3074를 둘러싼 이야기에서 생생하게 설명됩니다.

이더 거버넌스 프로세스는 Vitalik이 개입하기 전에 3074 논쟁이 교착 상태에 도달했기 때문에 어느 쪽도 타협할 의지가 없고 누구도 진전을 이룰 수 없는 끝없는 교착 상태에 빠질 수 있습니다 .

· 아니면 이더 일관되지 않은 설계를 가진 한 사람의 "프랑켄슈타인"이 될 수도 있습니다 .") 앞서 언급한 3074와 4337은 서로 양보하지 않을 수도 있으며, 결국 AA 생태계는 호환되지 않는 두 개의 병렬 공간으로 완전히 분리됩니다 .

공동체의 역할

위의 고려 사항을 거친 후, 우리는 이더 거버넌스에 대한 완전한 사고 모델의 개요를 거의 설명하고 있지만 지금까지 논의에서 커뮤니티라는 부분이 명백히 누락되었습니다.

Vitalik이 이더 에 대한 비전을 정의하고 연구자가 로드맵을 정의하고 핵심 개발자가 로드맵을 구현한다면 커뮤니티는 어떤 역할을 합니까? 당연히 아무것도 하지 않는 것과 같지 않습니까?

다행히도 커뮤니티는 실제로 가장 중요한 역할을 합니다. 그 이유는 비전이 있기 전에 가치가 있기 때문입니다. 우리는 특정 가치를 중심으로 단결하기 때문에 하나의 커뮤니티로 모이고 Vitalik의 비전은 궁극적으로 이러한 가치와 일치해야 하며 그렇지 않으면 커뮤니티의 지지를 잃게 됩니다 .

이더 커뮤니티의 모든 사람들은 모든 사람이 액세스할 수 있고 검열되지 않고 신뢰할 수 있으며 중립적 탈중앙화 컴퓨터를 갖는 것이 세상에 좋을 것이라고 믿습니다. 우리는 이더 에서 매일 수행하는 작업을 통해 위의 가치를 지지하고 확인하며 이를 통해 Vitalik, 연구원 및 핵심 개발자가 개발한 비전, 로드맵 및 코드에 정당성을 제공합니다.

이더 거버넌스의 VVRC 모델

따라서 이더 거버넌스, Values ​​​​⇒ Vision ⇒ Roadmap ⇒ Client 또는 줄여서 VVRC 의 완전한 정신 모델은 다음과 같습니다.

· V==가치==커뮤니티;

· V==비전==비탈릭;

· R==로드맵==연구원;

· C==클라이언트==핵심 개발자;

이들은 함께 다음과 같은 역할을 수행합니다.

· 커뮤니티는 특정 가치를 중심으로 뭉칩니다.

· Vitalik은 이러한 가치와 일치하는 비전을 표현합니다.

· 연구원들은 비전을 바탕으로 로드맵을 개발합니다.

· 핵심 개발자는 로드맵에 따라 클라이언트를 구현합니다.

물론 현실은 단순한 모델이 포착할 수 있는 것보다 훨씬 더 복잡합니다. 실제로 이더 핵심 개발자는 클라이언트 코드 변경을 통해 실제로 제안에 "투표"할 수 있는 유일한 사람입니다. Vitalik과 다른 연구자들은 자문 역할만 하고, 그들의 의견이 핵심 개발자들에게 받아들여지지 않는 경우가 있기 때문에 EIP-3074가 승인되었습니다.

그런데 VVRC 모델은 이더 의 거버넌스 모델이 정상적인 상황에서 어떻게 작동하는지 합리적으로 포착하고 있으며, EIP-3074와 같은 일이 다시 발생하지 않도록 프로세스를 "디버깅"해야 한다고 생각합니다.

이더 의 거버넌스 모델을 개선하는 방법

이제 우리는 이더 거버넌스 프로세스가 어떻게 작동하는지에 대한 정신적 모델을 가지게 되었으며 이를 개선하기 위한 몇 가지 아이디어를 제시합니다.

고려 중인 EIP에 대한 논의 진행 상황에 대한 가시성이 높아져야 합니다. 전체 커뮤니티는 EIP가 승인된 것에 "놀라"서는 안 되며, 3074와 같은 놀라운 제안 승인 방법이 다시 나타나서는 안 됩니다.

EIP 웹사이트에 있는 EIP의 현재 "상태"는 ACD 프로세스의 상태를 반영하지 않습니다. 그렇기 때문에 핵심 개발자들이 승인하기로 투표했고 애초에 승인을 고려했다는 징후조차 없음에도 불구하고 3074가 여전히 "검토 중"이라고 표시되는 이유입니다.

이상적으로는 EIP가 승인되려고 할 때 이더 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이 모든 로드맵의 정당성의 기초가 되는 이더 의 "비전"이라는 고유한 힘을 대표한다고 제안합니다. 우리는 Vitalik을 대기업의 CTO에 비유하며 이더 혁신의 속도를 유지하여 이더"프랑켄슈타인" 스타일의 스티치 몬스터로 변질되는 것을 방지하려면 유사 CTO로서의 그의 역할이 필요하다는 점을 인정합니다.

마지막으로 이더 거버넌스 모델을 설명하는 VVRC 모델을 제안합니다 : 가치(커뮤니티) ⇒ 비전(Vitalik) ⇒ 로드맵(연구원) ⇒ 클라이언트(핵심 개발자). 그런 다음 이 모델의 "버그"를 수정하는 다양한 방법을 제안합니다.

이더 거버넌스는 "기계를 만드는 기계"입니다. 이더 올바르게 작동하려면 합리적인 거버넌스가 있어야 합니다. 따라서 3074는 거버넌스 사건의 귀중한 예를 제공하며, 이더 커뮤니티가 향후 이더 거버넌스 프로세스를 개선하기 위해 이로부터 유용한 교훈을 배울 수 있기를 바랍니다.

블록비츠(Theblockbeats) BlockBeats 공식 커뮤니티 에 오신 것을 환영합니다.

텔레그램 구독 그룹: https://t.me/theblockbeats

텔레그램 커뮤니케이션 그룹: https://t.me/BlockBeats_App

공식 트위터 계정: https://twitter.com/BlockBeatsAsia