이더리움 거버넌스 반성: 왜 모두가 EIP-3074 사건에 불만을 느끼는가?

저자: imToken

본 문서는 최근 EIP -3047 사건에 대한 나의 생각을 설명하며, Vitalik과 Yoav에게 내용 검토에 감사드립니다.

이 사건에 대해 잘 모르신다면, 간단히 되짚어 보겠습니다:

얼마 전, EIP -3074 제안이 핵심 개발자들의 승인을 받아 이더리움의 다음 하드포크 Pectra에서 구현될 예정입니다. 이 제안의 목적은 일반 이더리움 계정(EOA) 사용자도 계정 추상화(Account Abstraction, 일반적으로 AA로 약칭)의 많은 편리함을 누릴 수 있도록 하는 것입니다.

그러나 이후 ERC -4337 커뮤니티, 특히 해당 제안의 초안자들은 EIP -3074 제안에 대해 강력히 반대하며, 그 이유는 주로 EIP -3047이 중앙화 위험을 악화시킬 수 있으며, 이더리움 계정 추상화 로드맵과 일치하지 않기 때문입니다. 이 로드맵의 핵심은 EIP -4337 및 그 근친인 EIP -7560(원주 추상 계정이라고도 함)입니다.

지난주, Vitalik은 EIP -3074의 대안으로 EIP -7702를 제안했습니다. 이 또한 EOA 사용자에게 계정 추상화의 이점을 제공하는 것을 목표로 하지만, 현재 EIP -4337 표준에 더 잘 맞춰져 있으며, 최종 형태인 EIP -7560으로 부드럽게 전환할 수 있습니다.

번역자 주: ERC -4337과 ERC -7560은 이더리움 생태계에서 계정 추상화와 관련된 제안으로, 사용자 계정 관리 및 상호작용 방식을 개선하고 사용자 경험과 보안을 향상시키기 위해 고안되었습니다.

ERC -4337은 사용자가 프록시 계약(Proxy Contract)을 통해 자신의 계정을 관리할 수 있도록 하여, 사용자 DApp 상호작용 시의 복잡성과 위험을 줄입니다. ERC -7560은 ERC -4337 등의 제안에서의 개념을 이더리움의 기본 레이어에 직접 통합하여 모든 계정이 자연스럽게 계정 추상화 기능을 갖추도록 하여, 더 깊은 통합과 최적화를 제공합니다.

ERC -4337은 ERC -7560으로의 전환을 위한 중요한 단계이며, 두 제안은 이더리움 계정 추상화 로드맵의 핵심을 형성합니다.

현재 핵심 개발자 팀은 EIP -7702에 대해 논의하고 있으며, 일부 초기 신호와 커뮤니티 피드백에 따르면 EIP -7702는 Pectra 하드포크에서 EIP -3074를 대체할 가능성이 높습니다.

이 결과에 대해 개인적으로 매우 만족스럽게 생각합니다: EOA 사용자는 ERC -4337을 위해 구축된 도구와 인프라를 통해 계정 추상화가 가져다주는 대부분의 이점을 누릴 수 있게 될 것입니다.

그러나 이 목표를 달성하는 과정은 저에게 불만을 남겼고, 최선의 경로가 아니었다고 느낍니다. 이는 최근 많은 사람들의 공통된 감정이기도 합니다. 저는 더 완벽한 프로세스가 있었다면 우리는 혼란을 줄이고 더 빨리 합의에 도달할 수 있었을 것이라고 확신합니다.

이 글에서는 다음을 다룰 예정입니다:

• 과정에서 존재하는 문제 분석
• 이더리움 거버넌스를 이해하기 위한 사고 프레임워크 제안
• 개선 방안 논의, 향후 유사한 상황을 피하기 위한 방법

왜 모두가 불만을 느끼는가?

이 사건은 많은 사람들에게 불만을 주었으며, 그 이유는 몇 가지입니다:

• 긴 승인 과정: EIP -3074는 수년이 걸려서야 승인을 받았습니다.
• 피드백 지연: 핵심 개발자들은 EIP -3074가 통과된 후에야 ERC -4337 커뮤니티의 반대 의견을 광범위하게 들었습니다.
• 경고가 무위로 돌아감: 4337 제안의 저자들은 여러 차례 핵심 개발자에게 3074에 대한 우려를 제기했지만, 효과는 미미했습니다.
• 방향 전환: 이제 우리는 EIP -3074를 철회하고 EIP -7702로 대체하는 상황에 직면해 있습니다.

객관적으로 볼 때, 위의 각 단계는 단독으로 보면 문제가 없습니다:

• 오랜 시간의 논의는 합리적입니다.
• 승인 후 반대에 직면하는 것도 정상적인 현상입니다.
• 새로운 문제가 발생하면 원래 결정을 조정하거나 취소하는 것도 논리적입니다.

그러나 우리는 아마도 이 과정이 더 원활할 수 있었음을 인정할 것입니다. 만약 일이 이렇게 진행되었다면:

핵심 개발자들이 EIP -3074에 대해 논의하는 동안, ERC -4337 커뮤니티가 적극적으로 참여했더라면, 결과는 두 가지 가능성만 있었을 것입니다:

• EIP -3074가 EIP -4337 커뮤니티의 피드백을 고려하여 승인되었을 경우(수정이 있을 수 있음), 그러면 EIP -4337 커뮤니티는 EIP -3074를 지지하게 되어 3074의 결정을 뒤집을 필요가 없었습니다.
• 또는 EIP -3074가 승인되지 않았지만, EIP -4337 커뮤니티가 핵심 개발자와 협력하여 모두가 만족할 수 있는 제안을 추진했을 것입니다. EIP -7702와 같은 방식으로요.

모든 사람의 목소리가 들렸고, 극적인 반전도 없었습니다. 이것이 이상적인 결말이었어야 했습니다------하지만 왜 실현되지 않았을까요?

문제는 어디에 있는가?

전체 과정을 되짚어보면, 양측 모두 서로를 비난하고 있습니다.

핵심 개발자(특히 EIP -3074의 저자)는 EIP -4337 팀이 이더리움 핵심 개발자 회의(ACD) 프로세스에 더 적극적으로 참여했다면 문제가 발생하지 않았을 것이라고 생각합니다.

이 프로세스에서 제안은 오랜 시간 논의되어야 하며, 최종적으로 클라이언트 팀이 수용하고 프로토콜에 통합됩니다. 그들은 EIP -4337 팀이 언제든지 개입하여 우려를 제기할 수 있었던 반면, EIP -3074가 승인된 후에야 개입한 것이라고 주장합니다. 결국 이더리움 핵심 개발자 회의 프로세스는 공개적이고 투명하며, Tim Beiko와 같은 사람들은 매 회의 후 요약을 트위터에 올립니다. 만약 EIP -4337 팀이 정말로 그렇게 걱정했다면, 왜 시간을 투자하여 참여하지 않았을까요?

반면, 계정 추상화 팀(EIP -4337의 저자)은 그들이 실제로 이더리움 핵심 개발자 회의에 참석했으며, EIP -3074에 반대할 기회를 놓치지 않았다고 강조합니다. 그러나 핵심 개발자들은 그들의 의견을 수용하지 않았습니다. EIP -4337 커뮤니티의 구성원들은 대체로 놀라워하며, 많은 사람들이 EIP -3074가 포기된 줄 알았고, 심지어 EIP -3074가 여전히 고려되고 있다는 사실조차 몰랐습니다.

또한, 이더리움 핵심 개발자 회의 프로세스가 너무 복잡하다는 의견도 있습니다. 전일제 직업이 있는 사람이나 매 단계의 업데이트를 따라갈 수 없는 사람들에게는 참여하기 어렵습니다. 또 다른 의견은, 핵심 이해관계자(예: EIP -4337 커뮤니티)의 의견을 적극적으로 요청하는 것이 이더리움 핵심 개발자 회의의 책임이어야 한다고 주장합니다.

제 생각에는 양측 모두 문제의 핵심을 완전히 파악하지 못했습니다. 더 깊은 문제가 작용하고 있으며, 이를 해결하거나 최소한 직시하지 않는 한 우리는 거버넌스 실패를 반복적으로 경험하고 무의미한 상호 비난에 빠질 것입니다.

문제의 본질

거버넌스 실패의 진정한 본질은 사람들이 이더리움 핵심 개발자 회의를 일반적으로 오해하고 있다는 것입니다. 이더리움 핵심 개발자 회의는 사실 프로토콜 업데이트의 유일한 결정 권한이 아니며, 이 사례에서는 다른 형태의 거버넌스 권력이 실제로 이더리움 핵심 개발자 회의 위에 군림하여 결정적인 역할을 했습니다.

문제는 이 중요한 거버넌스 권력이 이더리움의 중대한 사안, 예를 들어 계정 추상화 및 확장성 문제에 대해 막대한 영향을 미치지만, 공식적으로 인정받는 경우는 드물다는 것입니다.

저는 이 힘을 "로드맵"이라고 부르겠습니다.

간단히 말해, EIP -3074에서 EIP -7702로의 전환 과정은 "로드맵"의 힘이 이더리움 핵심 개발자 회의의 결정 권력을 압도한 전형적인 사례입니다.

거버넌스의 관점에서 볼 때, 보이지 않는 힘이 보이는 힘을 압도할 때 우리는 경각심을 가져야 합니다. 왜냐하면 보이지 않는 것은 감독을 받지 않기 때문에, 이 숨겨진 힘을 드러내고 검토해야 하기 때문입니다.

로드맵이란 무엇인가?

이더리움 커뮤니티에서 로드맵이라는 단어는 익숙할 것입니다. 예를 들어, Rollup을 중심으로 한 로드맵, ETH 2.0 로드맵, 또는 이번 논의의 초점인 계정 추상화 로드맵 등이 있습니다.

상상해 보세요, 이더리움 핵심 개발자 회의에서 네트워크 규모를 확장하는 방법에 대해 논의하고 있습니다:

핵심 개발자 Bob이 제안합니다: 저는 EIP -1234를 지지합니다. 이 제안은 블록 시간을 10배 빠르게 하고 블록 용량을 10배 늘리며 거래 수수료를 100배 줄이는 것입니다.

다른 개발자들이 대답합니다: 당신 진심인가요?

생각해 보세요, 왜 Bob의 제안이 신속하게 거부되었을까요? 그는 실제로 유효한 확장 솔루션을 제안했습니다. Solana와 같은 다른 퍼블릭 체인도 그렇게 운영하고 있으며, 효과가 뚜렷합니다.

그 이유는 Bob의 제안이 이더리움이 고수하는 Rollup 중심의 확장 로드맵과 정반대이기 때문입니다. 이 로드맵은 블록체인의 탈중앙화 특성을 유지하기 위해 일반 사용자가 쉽게 노드를 운영할 수 있는 것이 중요하다고 강조합니다. 따라서 Bob의 제안은 노드를 운영하는 난이도를 크게 높이기 때문에 로드맵과 일치하지 않아 자연스럽게 배제되었습니다.

이 예를 통해 제가 보여주고 싶은 것은, 이더리움 핵심 개발자 회의에 참여하고 프로토콜 업데이트를 책임지는 핵심 개발자들이 실제로는 제가 말하는 로드맵이라는 더 높은 지침 원칙을 따르고 있다는 것입니다. 여기에는 다양한 로드맵이 있으며, 확장 로드맵, 계정 추상화 로드맵, MEV 로드맵 등이 포함되어 있으며, 이들은 이더리움의 전체 로드맵을 구성하고 핵심 개발자들이 결정을 내리는 근거가 됩니다.

핵심 개발자와 로드맵이 일치하지 않을 때

로드맵이 공식 거버넌스의 일부가 아니기 때문에, 핵심 개발자들이 항상 로드맵과 일치할 수 있는 것은 아닙니다. 특히 "로드맵 승인"이라는 공식 프로세스가 없기 때문에 모든 로드맵이 동일한 인정을 받는 것은 아닙니다. 따라서 로드맵 뒤에 있는 기획자들은 핵심 개발자와 광범위한 커뮤니티에 적극적으로 홍보하여 인정을 얻고, 핵심 개발자들의 지지와 승인을 얻어야 합니다.

계정 추상화의 예를 들면, Vitalik은 여러 차례 EIP -4337을 중심으로 한 로드맵을 찬양했지만, 실제로는 주로 EIP -4337 팀, 특히 Yoav와 Dror가 회의, 온라인 포럼 및 이더리움 핵심 개발자 회의에서 이 로드맵을 적극적으로 옹호했습니다.

그러나 그럼에도 불구하고 일부 핵심 개발자들은 EIP -4337을 중심으로 한 로드맵에 반대 의견을 가지고 있으며, 그들은 EIP -7560(즉 EIP -4337의 원주 버전, 미래 클라이언트가 구현해야 함)이 너무 복잡하며 계정 추상화의 최종 형태를 구현하는 유일한 방법이 아니라고 생각합니다. 결국 EIP -4337 팀이 EIP -3074에 반대한다고 하더라도, 이더리움 핵심 개발자 회의는 EIP -3074를 승인했습니다.

하지만 EIP -3074가 승인된 후, EIP -4337 커뮤니티의 강력한 반대는 핵심 개발자들이 EIP -3074를 재검토하도록 촉구했습니다. 양측은 논쟁을 벌였고, 결국 Vitalik이 EIP -7702를 EIP -3074의 대안으로 제안하면서 상황이 계정 추상화 로드맵을 따르는 방향으로 발전하게 되었습니다.

Vitalik의 역할

비록 Vitalik이 자신을 연구자로 생각하지만, 이번 사건을 통해 그는 이더리움 거버넌스에서 독특한 역할을 하고 있다는 것을 알 수 있습니다. 이는 Vitalik이 이더리움 거버넌스에서 어떤 역할을 하고 있는지를 묻는 질문을 불러일으킵니다.

우리는 Vitalik을 대규모 회사의 CTO로 상상할 수 있습니다.

만약 당신이 50명 이상의 규모의 기술 회사에서 일한 경험이 있다면, CTO가 모든 기술적 결정에 참여할 수 없다는 것을 이해할 것입니다. 회사 규모가 커짐에 따라 기술적 결정은 자연스럽게 분산되고, 각 제품 분야의 하위 팀은 일반적으로 구체적인 실행 세부 사항을 자율적으로 결정할 수 있습니다.

또한 CTO가 모든 분야의 최고 전문가일 필요는 없습니다. 회사 내에는 특정 분야에서 CTO보다 더 뛰어난 엔지니어가 있을 수 있습니다. 따라서 기술 논쟁에서 최종 결정을 내리는 것은 종종 엔지니어들이 됩니다.

그러나 CTO는 회사의 기술 비전을 수립하는 책임이 있으며, 구체적인 실행은 개발자에게 맡깁니다.

이 비유가 완벽하지는 않지만, Vitalik이 이더리움 생태계에서 맡고 있는 역할을 상당히 정확하게 묘사합니다.

Vitalik은 모든 기술적 결정에 참여하지 않습니다------그는 그렇게 할 수 없으며, 모든 분야의 최고 전문가도 아닙니다. 그러나 그는 이더리움의 모든 핵심 측면(예: 확장성, 계정 추상화, 지분 증명 등)에 대한 로드맵에 막대한 영향을 미치며, 이는 단순히 그의 기술 지식 때문만이 아니라, 그가 최종적으로 로드맵이 이더리움의 비전------즉 그의 비전------과 일치하는지를 판단할 수 있기 때문입니다.

성공적인 제품 뒤에 있는 원동력은 비전

저는 기업가로서, 모든 성공적인 제품 뒤에는 명확한 비전이 있다고 생각합니다. 이러한 비전은 종종 소수의 사람들, 일반적으로 창립 팀, 때로는 단 한 명의 핵심 창립자에 의해 확립됩니다.

이더리움의 매력은 이렇게 복잡한 구조를 가진 시스템이 어떻게 협력하여 매일 막대한 가치를 순환시키는 탈중앙화 컴퓨터가 될 수 있는가입니다. 이는 위원회식 결정으로 이루어진 것이 아니라, Vitalik이 그의 비전을 통해 이끌어낸 결과입니다. 우리는 오늘날과 같은 조화롭고 효율적인 이더리움을 갖게 되었습니다. 2015년의 구상에서 오늘날까지, 이더리움은 Vitalik의 지혜를 구현한 것입니다.

이는 다른 연구자와 엔지니어의 기여를 폄하하는 것이 아닙니다. 그들은 이더리움의 발전에 많은 기여를 했습니다. 그러나 동시에, 이더리움은 Vitalik의 비전의 극치로, 다른 어떤 개인의 영향력을 훨씬 초월합니다.

정직하게 스스로에게 물어보세요. 이더리움의 개방성, 검열 저항성 및 혁신적인 활력 때문에 참여하게 되었을 때, 이 모든 것이 Vitalik의 초기 구상에서 비롯된 것에 대해 신경 썼나요?

아마도 이전에는 깊이 생각하지 않았겠지만, 이 점을 이해한 후에 정말로 신경 쓰나요?

이더리움은 명확한 비전으로 태어났고, 그 비전을 지속적으로 실현하는 과정에서 성장하고 있으며, 이것이 바로 그 매력입니다.

그렇다면 탈중앙화는?

당신은 아마도 이렇게 질문할 것입니다. 만약 한 사람이 이더리움에 이렇게 큰 영향을 미친다면, 어떻게 그것이 탈중앙화라고 할 수 있을까요?

이 질문에 대한 답을 찾기 위해, 우리는 Vitalik이 쓴 고전적인 글을 참고할 수 있습니다. 이 글은 탈중앙화의 다중적 의미를 설명합니다. 글의 핵심은 탈중앙화가 세 가지 측면을 포함한다는 것입니다:

구조적 탈중앙화: 얼마나 많은 노드가 실패해야 시스템이 작동을 멈추는가?

논리적 탈중앙화: 시스템의 각 부분이 전체 기능에 영향을 주지 않고 독립적으로 진화할 수 있는가?

정치적 탈중앙화: 얼마나 많은 사람이나 실체가 이 시스템을 통제하고 있는가?

이더리움은 구조적 및 논리적으로 탈중앙화되어 있습니다. 왜냐하면 그것은 많은 노드 간에 분산될 수 있으며, 서로 다른 구성 요소(예: 합의 메커니즘 및 실행 레이어)가 상대적으로 독립적으로 발전할 수 있기 때문입니다.

정치적 탈중앙화에 관해서는 좋은 소식은 Vitalik을 포함한 어떤 단일 실체도 이더리움을 종료할 수 없다는 것입니다. 그러나 Vitalik이 이더리움의 비전과 로드맵을 설정하는 데 중요한 위치를 차지하고 있다는 것은 정치적 탈중앙화에서妥協가 있을 수 있음을 의미합니다.

제 생각에는 이더리움이 지속적으로 혁신하기 위해서는 Vitalik을 사실상의 CTO 역할로 받아들여야 하며, 이는 어느 정도 정치적 탈중앙화를 감소시킬 수 있습니다. 이더리움이 비트코인처럼 안정적이지 않은 성숙 단계에 있는 동안, 기술적 우열에 기반하여 결정을 내리는 것뿐만 아니라, 이러한 결정이 이더리움의 장기 비전과 일치하는지를 보장하는 존경받는 권위자가 필요합니다.

Vitalik과 같은 역할이 없다면, 이더리움은 두 가지 상황에 직면할 수 있으며, 이번 EIP -3074 사건은 생생한 예입니다:

• 결정 정체: 각 당사자가 타협을 원치 않아 프로젝트가 정체되고, EIP -3074의 논쟁이 Vitalik의 개입으로 정체를 깨뜨리기 전까지 계속되었습니다.
• 설계 혼란: 시스템이 조화롭지 않은 조합체가 될 수 있으며, EIP -3074와 EIP -4337이 평행하면서도 호환되지 않는 상황이 발생할 뻔했습니다.

따라서 이더리움이 여전히 빠르게 진화하는 단계에 있는 동안, Vitalik의 리더십은 탈중앙화되면서도 방향성을 잃지 않는 생태계를 유지하는 데 필수적입니다.

커뮤니티의 중요성

이제 우리는 이더리움 거버넌스에 대한 포괄적인 이해 프레임워크를 거의 구축했지만, 지금까지 논의 중에 하나의 핵심 부분이 언급되지 않았습니다------커뮤니티의 역할입니다.

Vitalik이 비전을 설정하고, 연구자들이 이를 바탕으로 로드맵을 계획하며, 핵심 개발자들이 이를 실행한다면, 커뮤니티는 그 과정에서 어떤 역할을 할까요? 분명히 무시할 수는 없겠죠?

사실 커뮤니티는 가장 핵심적인 역할을 합니다. 왜냐하면 비전이 형성되기 전에 더 기본적인 것이 존재하기 때문입니다------가치관입니다. 우리는 공유하는 가치관 덕분에 커뮤니티를 형성하며, 이러한 가치관은 Vitalik의 비전의 기초가 되어야 하며, 일치하지 않으면 커뮤니티는 존재할 수 없습니다.

아마도 성장 배경의 영향이나 과거 경험의 영감으로 인해, 이더리움 커뮤니티의 모든 사람은 어느 순간에 모두가 접근할 수 있고 검열할 수 없는, 진정한 탈중앙화 컴퓨터를 구축하는 것이 세상에 얼마나 중요한지를 깨달았습니다. 우리는 매일 이더리움에서 하는 모든 일이 이러한 가치관을 실천하고 확인하는 것이며, 이러한 행동을 통해 우리는 Vitalik, 연구자 및 핵심 개발자들이 제안한 비전, 로드맵 및 코드에 생명과 정당성을 부여합니다.

이더리움 거버넌스 간소화 모델: VVRC 프레임워크

이더리움의 거버넌스를 정교하게 설계된 기계처럼 상상해 보세요. 우리는 이를 네 가지 핵심 부분으로 간소화할 수 있습니다: 가치관(Values), 비전(Vision), 로드맵(Roadmaps) 및 클라이언트(Clients), 이를 줄여서 VVRC 모델이라고 부릅니다.

• 가치관(Values): 모든 것은 이더리움 커뮤니티가 공유하는 기본 원칙과 신념에서 시작됩니다.
• 비전(Vision): Vitalik은 창립자로서 커뮤니티의 가치관을 바탕으로 이더리움의 미래 발전에 대한 비전을 그립니다.
• 로드맵(Roadmaps): 명확한 비전이 생기면 연구 팀은 이러한 꿈을 실현하기 위한 구체적인 단계를 마련합니다. 그들은 목표를 향해 나아가는 기술 경로를 설계합니다.
• 클라이언트(Clients): 마지막으로, 핵심 개발자 팀은 로드맵에 따라 코드를 작성하고 클라이언트 소프트웨어를 유지 관리하여 모든 기술 계획이 현실로 변환되고 사용자와 개발자가 실제로 사용할 수 있도록 합니다.

이 프로세스는 매끄럽게 들리지만, 현실에서는 더 복잡할 수 있습니다. 예를 들어, 핵심 개발자들은 실제 소프트웨어 구현을 책임지기 때문에 최종 결정 권한을 가지고 있습니다. Vitalik과 다른 연구자들은 더 많은 조언을 제공하며, 때때로 그들의 제안이 채택되지 않을 수도 있습니다. 이는 EIP -3074 사건에서 나타났습니다.

전반적으로 VVRC 모델은 이더리움이 이상적인 상황에서 거버넌스를 추진하는 방식을 이해하는 데 도움을 주며, 동시에 이 과정을 지속적으로 조정하고 개선해야 한다는 점을 상기시킵니다. EIP -3074와 같은 문제가 다시 발생하지 않도록 말입니다.

이더리움 거버넌스 개선 방안

이더리움 거버넌스 구조를 최적화하고 EIP -3074/EIP -7702 사건의 재발을 방지하기 위해 몇 가지 개선 제안을 제시합니다:

EIP 투명성 향상: 진행 중인 EIP가 커뮤니티에 더 공개적이고 투명하게 되어, EIP -3074가 갑자기 수용되어 모두를 놀라게 하는 상황을 피해야 합니다. 실제로 EIP s 웹사이트에 표시된 EIP 상태는 이더리움 핵심 개발자 회의의 심의 진행 상황과 동기화되지 않기 때문에, 핵심 개발자들이 EIP -3074에 동의했더라도 그 상태는 여전히 "검토 중"으로 표시됩니다. 제안으로는 이더리움 재단의 소셜 미디어 플랫폼을 통해 커뮤니티에 곧 채택될 EIP를 미리 알리는 것입니다.

커뮤니티 참여 강화: 커뮤니티 구성원들이 이더리움 핵심 개발자 회의에서 EIP가 하위 프로젝트에 미치는 영향을 논의할 특정 시간을 설정하여, EIP -3074가 EIP -4337 커뮤니티에 미친 예기치 않은 영향을 방지할 수 있습니다. 또한 연구자들이 그들의 피드백이 핵심 개발자에게 중요하게 여겨지지 않는다고 느낀다면, EIP -4337 팀이 겪었던 어려움처럼, 커뮤니티 구성원을 초대하여 논의에 참여시켜 자신의 입장을 강화할 수 있습니다.

상호 이해 및 지속적인 소통: 핵심 개발자와 연구자들은 서로를 이해해야 하며, 그들은 모두 거버넌스의 핵심 세력입니다. 다만 초점이 다를 뿐입니다. 핵심 개발자는 클라이언트를 구현함으로써 "실행 권한"을 가지며, 이는 "투표 권한"을 가진 것과 같습니다. 반면 연구자들은 그들의 로드맵을 적극적으로 공유하고 논의함으로써 더 넓은 커뮤니티의 지지를 얻어 "로드맵 영향력"을 형성합니다.

양측의 의견이 일치하지 않을 때, 핵심 개발자는 연구자들의 생각을 직접 뒤집는 경향이 있을 수 있으며, 이는 그들이 EIP -4337 팀에게 했던 것과 같습니다. 그러나 이렇게 하면 반발이 일어날 수 있습니다. 왜냐하면 양측의 갈등이 발생할 때 권력 균형이 깨지기 때문입니다. EIP -3074 통과 후 발생한 혼란이 그 예입니다.

반대로 연구자들이 저항에 직면했을 때, 그들은 더 이상 핵심 개발자와 협력하지 않기로 선택할 수 있으며, 이는 RIP(Rollup Improvement Proposal) 프로세스가 탄생하고 원주 계정 추상화(EIP -7560)가 주로 RIP로 추진된 이유 중 하나입니다.

비록 RIP가 L2 실험이 L1에서 직접 채택하기 어려운 프로토콜 업데이트를 돕는 것은 유익하지만, EIP 거버넌스 과정에 참여하는 것을 대체할 수는 없습니다. 연구자들은 로드맵이 일치할 때까지 핵심 개발자와의 소통을 지속해야 합니다.

이러한 조치를 통해 거버넌스의 투명성을 높이고, 커뮤니티 참여를 강화하며, 핵심 개발자와 연구자 간의 효과적인 협력을 촉진하여 향후 발생할 수 있는 거버넌스 문제를 줄일 수 있습니다.

결론

이더리움의 EIP -3074/EIP -7702 사건은 그 거버넌스 구조의 복잡성을 드러냅니다: 공식적인 거버넌스 프로세스(핵심 개발자들이 EIP와 이더리움 핵심 개발자 회의 제안을 바탕으로 추진하는 것) 외에도 연구자들이 제안한 비공식 로드맵이 막대한 영향을 미칩니다. 이 두 힘이 조화를 이루지 않을 때, 결정 정체나 갑작스러운 방향 전환이 발생할 수 있으며, 이때 Vitalik의 역할이 특히 중요합니다. 그는 이더리움의 비전을 이해하고 이를 통해 각 당사자를 조정할 수 있는 능력을 가지고 있습니다. 이는 프로젝트의 정신적 리더와 유사합니다.

우리는 이더리움의 거버넌스를 간소화하여 모델화했습니다: 커뮤니티의 가치관 → Vitalik의 비전 → 연구 팀의 로드맵 → 핵심 개발자의 실행(VVRC 모델). 이 체인은 결정이 어떻게 광범위한 아이디어에서 구체적인 기술적 실행으로 세분화되는지를 보여줍니다.

거버넌스 효율성을 개선하기 위해서는 이 이상적인 모델에서 벗어난 실제 운영 문제를 수정해야 합니다. 결국, 좋은 이더리움 거버넌스는 프로젝트를 추진하는 핵심 메커니즘입니다. EIP -3074 사건은 거버넌스의 약점을 드러내는 사례로, 우리가 배우고 개선할 수 있는 기회를 제공합니다. 이를 통해 미래에 유사한 도전에 더 잘 대응하고 이더리움의 지속적인 건강한 발전을 촉진할 수 있습니다.