(17편) 가지 않은 길 — 비탈릭 부테린 생각 따라잡기

21 min readApr 5, 2022

팝캣티움 리서치 리포트

팝캣티움은 팝캣(Popcat)을 모티브로 만들어진 대한민국 최초의 퍼블릭 밈(Meme) 블록체인으로서 유능하고 열정이 넘치는 암호화폐인들이 자신들의 재미를 추구하고 창의력을 마음껏 발산하기 위한 목적을 갖고 있습니다.

본 리서치 리포트는 암호화폐 및 블록체인 기술과 시장에 대한 인사이트를 폭넓고 깊이 있게 제공함과 동시에 팝캣티움의 정신을 널리 알리고자 팝캣티움 생태계 참여자들의 자발적인 참여로 만들어지고 있습니다.

“비탈릭 부테린 생각 따라잡기”는 비탈릭 부테린의 블로그 포스팅을 토대로 암호화폐 및 블록체인 기술과 시장에 대한 인사이트를 짚어봄과 동시에 암호화폐 산업이 나아가야 할 방향에 대해 고민해보기 위한 팝캣티움 리서치의 의견을 제공합니다.

Summary

이더리움의 역사는 생각보다 오래되었습니다. 2013년부터 제로베이스로부터 현재의 이더리움에 이르기까지 이더리움을 설계해온 비탈릭 부테린에게는 “만약 지금과는 다른 방식으로 이더리움을 개발했었으면 어떻게 되었을까?” 하는 생각이 종종 들었을 것 같습니다.

무엇보다 완전한 이더리움 2.0을 구현하기 위해서는 샤딩과 같이 매우 복잡한 수준의 개발이 이루어져야 하기 때문에 과연 이 방식이 최선이었던 것인지에 대해 스스로 질문을 많이 할 수 밖에 없는 상황일 것 같기도 합니다.

이번 포스팅은 이더리움에 반영되지 않았지만 매우 중요했던 사안들을 한 번 돌이켜보고 앞으로의 방향에 대해 고민해보는 내용을 담고 있습니다.

가지 않은 길

2022 Mar 29See all posts

이더리움 프로토콜 개발 커뮤니티는 초기의 이더리움 단계에서 많은 결정을 해왔고, 이런 결정들은 프로젝트의 궤도에 지대한 영향을 끼치고 있습니다. 이더리움 개발자들은 의식적으로 비트코인이 실수했었다고 생각되는 부분들을 개선하기 위한 의식적인 결정들을 해왔었습니다. 어떤 경우에는 완전히 새로운 것들을 만들어내야만 했는데, 완전한 공백을 무언가로 채워나가는 그런 작업들이었습니다. 하지만 그런 선택을 위해서는 많은 옵션들이 존재했었습니다. 또 여전히 어떤 곳에서는 우리의 결정으로 인해 좀 더 간단하거나 복잡한 것들 사이에서 상충관계라는 결과를 가지게 되었습니다. 때로는 좀 더 간단한것을 선택했었지만, 때로는 좀 더 복잡한 것들을 선택하기도 했었습니다.

이 포스팅을 통해서 저는 우리가 거쳐왔던 이러한 포크들을 기억해내며 한 번 살펴볼까 합니다. 이러한 특징들의 상당수는 코어 개발 단계에서 심각하게 논의되었습니다. 어떤 것들은 전혀 논의되지 않았지만, 아마도 논의가 되었어야 하는 것들도 있을 겁니다. 하지만 심지어 여전히, 이더리움이 다른 모습을 가지고 있다면 어떤 것이었을지, 그리고 그것들을 통해서 우리가 앞으로 진행하는 과정에서 배울 무엇인가가 있기에 충분한 가치가 있는 작업이 될 것 같네요.

좀 더 간단한 버전의 PoS를 추구했어야 했나?

이더리움이 곧 적용시킬 Gasper 지분증명 방식은 상당히 복잡하지만 매우 강력한 시스템입니다. Gasper의 특징들을 한 번 살펴보죠.

매우 강력한 단일 블록 컨펌 : 블록에 트랜잭션이 담기자마자, 대부분 몇 초내로 그 블록은 돌이킬 수 없는 상태가 되어버립니다. 악의적인 상당 수의 노드가 일부러 거슬러버리거나, 극도의 네트워크의 지연이 발생하지 않는 한 이 컨펌은 확정되어 버립니다.
경제적 완결성(Finality) : 블록이 완결되면, 공격자가 수 백만개의 ETH 코인을 슬래싱 당하지 않고서는 그 블록의 컨펌을 돌이킬 수 없습니다.
매우 예측가능한 보상 : 밸리데이터들은 풀에 인센티브를 줄이면서 안정적으로 매 Epoch마다 (6.4분 정도 됩니다) 보상을 받습니다. ,
매우 많은 수의 밸리데이터가 참여 가능 : 위와 같은 특성을 지닌 대부분의 다른 체인들과 달리, 이더리움 비콘 체인은 수 십만개의 밸리데이터가 참여할 수 있습니다. (예를 들어, 텐더민트는 이더리움보다 빠르긴 하지만, 고작 몇 백개의 밸리데이터만 참여할 수 있습니다.)

하지만 위와 같은 특성을 지닌 시스템을 만드는 것은 어려운 일입니다. 수 년간의 리서치와 수년간의 실패, 그리고 엄청난 노력이 들어갔습니다. 그리고 최종적인 결과는 꽤 복잡하게 되어버렸죠.

만약 우리의 리서치 팀이 합의 알고리즘에 대해서 그렇게 심각하게 생각하지 않고, 좀 더 여유가 있었던 상황이라면 아마도, 추측이지만, 롤업이 2016년 쯤에 도입되었을 수도 있었습니다. 그럼 질문이 하나 생기겠죠. 매우 간단하지만 미약한 수준의 PoS조차 기존의 PoW 방식에 비해서 매우 큰 이점이 있었다면, 우리가 정말 그토록 높은 수준의 PoS를 위한 기준이 필요했었을까요?

많은 사람들이 PoS가 본질적으로 상당히 복잡하다고 착각하지만, 실제로 나카모토 PoW 알고리즘처럼 매우 간단한 수준의 PoS 알고리즘도 현실에 많이 존재하고 있습니다. NXT 지분증명은 이미 2013년부터 있었고, 자연스럽게 후보군이었습니다. 물론 어느 정도 이슈가 있었지만, 비교적 간단히 패치될 수 있는 수준의 이슈였고, 우리들도 초기인 2017년부터는 합리적으로 꽤 잘 작동하는 PoS를 만들 수 있었고, 심지어 시작부터도 만들 수는 있었습니다. Gapser가 이러한 알고리즘보다 복잡하게 된 이유는 기존에 존재하던 PoS 알고리즘을 능가하는 수준의 것으로 만들기 위했기 때문입니다. 하지만 우리가 초기에 좀 더 중도적인 태도를 갖고 있었다면, 우리들은 아마도 처음에 좀 더 제한적인 수준의 목표를 달성하는데 집중했었을 수 도 있었을 것 같네요.

제 생각에는 초기부터 PoS를 하는 것은 잘못된 선택이었을 것 같네요. PoW는 초기에 발행량의 배분을 퍼뜨리는데 상당히 도움이 되었고, 이더리움이 보다 많은 사람들이 접근 가능하도록 만들었습니다. 또, 취미로 채굴하는 사람들을 자극하기도 했죠. 하지만 좀 더 간단한 수준의 PoS로 2017년 혹은 2020년쯤에 전환하는 것은 환경파괴를 좀 더 줄일 수 있었을 지 모르겠네요. (그리고 자연파괴를 이유로 암호화폐를 반대하는 사람들을 좀 진정시켰을 수 있겠네요.) 또, 뛰어난 리서처들이 스케일링에 대해서 자유롭게 생각할 기회를 갖게 되었을지도 모르겠습니다. 결과적으로 우리가 더 나은 PoS를 만들어내기 위해서 더 많은 리소스를 소모한 것이 과연 좋은 선택이었나요? 네. 하지만 어쨌든 우리는 결국 그렇게 해낼 것 같네요.

샤딩의 탈복잡화( de-complexification)

이더리움 샤딩은 2014년부터 작업된 아이디어 단계때부터 덜 복잡하게 만들고자 하는 일관된 궤도에 있었습니다. 첫째로 우리에게는 레이어에 내장되어 실행되고 크로스샤드 트랜잭션을 처리하는 아주 복잡한 샤딩이 있었습니다. 그때, 우리들은 유저에게 좀 더 책임을 줄 수 있도록 함으로써 프로토콜을 좀 더 간단하게 만들었습니다. (예를 들어, 크로스-샤드 트랜잭션에서는 유저가 두 샤드에게 개별적으로 가스를 지불해야만 했습니다.) 또, 우리들은 샤드가 단순한 데이터 덩어리라는 프로토콜으로부터의 관점을 토대로 롤업이 중심이 되는 로드맵으로 변경했습니다. 결국 최종적인 설계는 Danksharing을 통해서 샤드 수수료 시장들은 하나로 통합되었으며, 샤드가 없는 체인과 유사하게 보이지만 데이터 가용성 샘플링이 샤드가 적용된 상황에 대한 검증이 마법처럼 잘 일어나도록 설계되었습니다.

만약 우리가 정반대의 방향으로 갔었다면 어떻게 되었을까요? 음, 실제로 좀 더 복잡한 구조의 샤딩 시스템에 대해 심도있게 탐구했던 이더리움 리서처들도 있었습니다. 샤드들이 체인들이 되고, 부모체인(Parent chains)에 의존하는 차일드체인(Child chains)들에 대한 포크 룰을 결정할 수 있으며, 샤드간의 메시지가 프로토콜에 의해 전파되고, 밸리데이터들은 샤드들을 넘나들 수 있고, 심지어 샤드 사이에서 어플리케이션들이 자동적으로 균형있게 잘 구현될 수 있는 그런 시스템들 말이죠.

이러한 접근방식의 문제점은 이것입니다. 샤딩의 이러한 형태들은 대게 아이디어일뿐이고, 수학적인 모델을 기반으로 했을뿐입니다. 이에 반해 Danksharding은 이미 구현이 가능하다고 검증된 기술을 기반으로 개발되었습니다. 그래서 저는 이더리움이 갖고 있던 상황과 제한적 요소를 고려해볼 때, 그러한 샤딩 계획을 폐기하고 최대한 간단한 형태로 만드는 것이 최고의 선택이었다고 생각합니다. 즉, 야망이 있는 리서처들 역시 매우 중요한 역할을 수행합니다. 유망한 리서치 방향에 대해서 규정짓습니다. 심지어 위에서 언급했던 복잡한 버젼의 아이디어들조차 합리적으로 간단한 형태로 많은 도움을 줄 수 있는 버전들이 존재하고, 앞으로의 이더리움 프로토콜의 개발에 (심지어 레이어2 프로토콜 조차도) 상당히 좋은 영향을 끼칠 가능성도 존재합니다.

EVM 기능을 추가해야할까 혹은 축소해야할까?

현실적으로 EVM의 스펙은 기본적인 수준으로, 보안 검수를 진행하지 않았다면 2014년 중반에는 런칭이 가능했었습니다. 하지만, 하지만 향후 몇 개월동안 우리들이 탈중앙화 어플리케이션의 구현을 가능하게 하는 블록체인으로서 가장 중요하다고 생각되는 기능들을 적극적으로 탐구하게 되었습니다. 몇 가지 기능들은 개발되지 않았습니다.

POST opcode를 도입하는 것을 고려했으나, 진행하지 않았습니다. POST opcode는 나머지 트랜잭션들이 종료된 이후에 비동기 호출을 가능만들 수 있었습니다.
ALARM opcode를 도입하는 것을 고려했었으나, 진행하지 않았습니다. ALARM은 POST와 유사한 기능을 할 수 있었는데, 컨트랙트가 예정된 구동을 할 수 있게 만들 수 있었지만 미래의 블록에서 비동기 호출을 실행하는 것은 불가능했습니다.
logs를 추가했었는데, 컨트랙트가 상태(state)를 건들이지 않고서도 결과값을 낼 수 있지만, Dapp 인터페이스나 지갑에 의해 해결되어야 했습니다. 특히, 우리들은 ETH 전송 시 로그를 남기는 방식을 고려했지만, 결과적으로 그렇게 진행하지는 않았습니다. 어쨋든 사람들이 스마트컨트랙트 지갑으로 곧 전환할 것이라는 추측때문이었습니다.
SSTORE이 Byte 배열을 지원하도록 기능을 늘리는 방안을 고려했지만, 그렇게 진행하지 않았습니다. 복잡성과 보안에 대한 걱정때문이었습니다.
precompiles를 추가했었는데, 이를 통해 컨트랙트가 기본 구현이 가능한 특정한 암호학적 구동함으로써 EVM에서 진행되었을 때보다 훨씬 더 저렴한 가스비용을 소모할 수 있도록 만들었습니다.
런칭 직후 몇 달동안 state rent (상태 대여)가 재 고려되었고, 다시 한 번 고려되었지만 결국 포함되지는 않았습니다. 너무 복잡했기 때문이죠. 오늘날 훨씬 더 개선된 상태 만료 구조(state expiry schemes)에 대해서 활발히 연구가 진행되고 있습니다. 상태없는 검증(stateless verification)과 제안자/설계자 분리로 인해서 낮은 우선순위를 갖고 있긴 하지만요.

이런 것들은 오늘 고려해보면, 더 많은 기능을 추가하지 않기로 했던 대부분의 결정은 매우 좋은 결정이었다는 것이 증명되었습니다. POST opcode를 추가해야만 하는 명백한 이유가 없었습니다. ALARM opcode는 안전하게 구현하는 것이 실제로 매우 어렵습니다. 예를들어, 1번 블록부터 99,999번 블록까지 100,000번 블록에서 엄청난 ALARM 코드를 실행하려고 하게되면 어떻게 될까요? 블록이 처리되는데 몇 시간이 걸릴까요? 예정되어 있던 구동이 이후에 생성되는 블록들에서 처리될까요? 하지만 만약 그런 일들이 일어났다면, ALARM이 제대로 기능하도록 어떻게 보장할 수 있을까요? SSTORE이 byte 배열을 안전하게 지원하는 것은 어렵고, 최악의 상황에서는 Witness(역자 주 : 블록에서 서명이 포함된 부분)의 사이즈를 엄청나게 확대했어야 했을 겁니다.

상태 대여(State rent) 이슈는 더 어렵습니다. (역자 주 : State에 대해서 잠깐 얘기하겠습니다. 블록체인의 데이터는 모두 지갑 계정에 대한 내용들입니다. 계정들은 잔고, 논스, 코드 등과 같은 정보를 기본적으로 모두 저장하고 있습니다. 이러한 데이터들을 State라고 부릅니다. 블록체인이 오랜 기간동안 유지되면서, 이러한 계정의 정보들이 누적되어 계속 커지게 되면서 사용되지 않는 부분이 계속 방치됩니다. State rent는 이렇게 사용되지 않고 있는 계정들의 공간을 대여하고자 하는 것입니다.) 1일차부터 우리가 어떤 종류의 상태대여를 했다고 가정해봅시다. 영구적인 상태(Persistent state)에 대한 일반적인 가정으로 스마트 컨트랙트 생태계가 성장 할 수 없었을 것입니다.

이더리움 설계가 더 어려웠을 수도 있지만, 좀 더 확장성을 갖고 지속성이 있도록 설계되었을 수도 있었습니다. 동시에 우리가 당시에 갖고 있던 상태만료구조(State expiry schemes)에 대한 계획은 현재의 계획보다 훨씬 더 낮은 수준이었습니다. 때로는 좋은 아이디어를 구현하는데 수 년이 걸리고, 그것보다 더 좋은 방법은 없습니다.

LOG의 대안들

LOG는 다른 두가지 방식으로 개발되었을 수도 있었습니다.

ETH를 전송하면 자동적으로 log를 생성하도록 만들 수도 있었습니다. 이를 통해 다른 사용자와 거래소를 위한 엄청난 양의 노력과 소프트웨어 버그 이슈를 줄일 수도 있었을 것 같습니다. 그리고 사람들이 로그에 의존하게 만들어서 아이러니컬하게도 스마트 컨트랙트 지갑이 수용되는 상황을 가속화했었을 수도 있었겠네요.
LOG opcode때문에 전혀 어려움을 겪지 않았을 수도 있었습니다. 대신에 저희는 ERC를 만들었죠. ERC는 submitLog 펑션을 가진 스마트컨트랙트입니다. 또, 블록안의 머클 루트에 있는 모든 로그를 연산하기 위해 이더리움 예치 컨트랙트 기술를 활용하는 컨트랙트죠. EIP-2929나 블록 수준에서의 저장 (TSTORE와 동일하지만 블록 이후에 사라집니다.) 기술 등이 이러한 것들을 좀 더 가볍게 했었을 수도 있었겠네요.

우리는 (1)을 심각하게 고려했지만, 결국 개발하지 않았습니다. 그 이유는 간단했습니다. Log를 불러오는데 LOG opcode를 활용하는게 더 간단했기 때문이죠. 그리고 매우 잘못된 생각이긴 했지만 우리는 대부분의 유저들이 빠르게 opcode를 통해서 명쾌하게 log를 전송할 수 있는 스마트 컨트랙트 기반의 지갑에 적응할 것이라 예상했었습니다.

(2)는 고려되지 않았지만, 돌이켜보니 항상 옵션이었던 것 같습니다. (2)의 단점은 log를 빠르게 스캔하는 Bloom 필터 메커니즘의 부족때문이었던 것 같습니다. 하지만 나중에 검증되었듯이 Bloom 필터 메커니즘은 Dapp에 유저친화적으로 쓰이기에는 너무 느렸습니다. 그리고 요즘에서야 사람들이 쿼리를 구동하기 위해서 TheGraph를 더 많이 쓰게 되었네요.

전체적으로 볼 때, 이러한 접근 방법들의 어떤 것도 지금의 상황보다 더 개선된 방식이었을 수도 있습니다. LOG를 프로토콜 외부에 두는 방식은 간단했지만, 프로토콜 내부에 ETH 전송에 대한 로그를 자동적으로 남기는 것은 매우 유용했을 것 같습니다.

오늘날에는 저는 EVM에서 LOG opcode를 궁극적으로 폐기하는 방식을 선호하긴 합니다.

EVM이 완전히 다른 것이었다면?

EVM에 채택될 수도 있었던 완전히 다른 두 가지 길이 있었습니다.

EVM을 변수와 if 구문, loop 등이 가능한 내장된 형태로 만들어 높은 수준의 언어로 만드는 방법
EVM을 현존하는 VM (LLVM이나 WASM 등)의 모방형태로 만드는 방법

첫 번째 방법은 결코 고려되지 않았습니다. 이 방법의 매력은 컴파일러를 간단하게 만들고 보다 많은 개발자들이 EVM에서 직접 코딩을 할 수 있도록 만들 수 있다는 점입니다. ZK-EVM 구조도 훨씬 더 간단하게 만들 수 있었을 것 같네요. 이 방법의 약점은 EVM 코드를 구조적으로 더 복잡하게 만들어야 한다는 점이었습니다. 간단한 opcode들의 행의 목록을 대신해서, 어떻게든 저장되어야만 하는 좀 더 복잡한 데이터 구조를 가질 수도 있었습니다. 즉, 우리가 놓친 최선의 두 가지 상황을 위한 기회들이 있었는데요, EVM이 기본적인 EVM 구조를 굳건하게 하면서도 상당한 수준의 이점을 만들어내는 상황이 첫 번째입니다. 역동적인 점프(Dynamic jump)를 제지하고, 서브루틴(Subroutines)을 지지하는 opcodes 설계를 추가하는 그런 방법들입니다. (EIP-2315도 한 번 살펴보세요). 이런 방법들은 32바이트 단어 경계에서만 메모리 액세스를 허용합니다.

두 번째 길은 여러번 제안이 되었고, 여러번 거절이 되었습니다. 주로 얘기가 나왔던 주장은 C, Rust와 같은 기존의 언어를 EVM에 적용함으로써 프로그램을 컴파일 할 수 있도록 만들 수 있다는 내용이었습니다. 그런 주장들은 이더리움의 특수한 제한상황을 고려해서 실질적인 도움을 줄 수 없을 것이라는 명목으로 반대되었습니다.

기존의 높은 수준의 언어를 통한 컴파일러들은 전체 코드 사이즈에 대해서는 그닥 상관하지 않는 경향이 있는데, 이에 반해 블록체인의 코드는 코드 사이즈의 모든 byte를 절감하기 위해 최적화 되어야만 합니다.
우리는 두 동작이 결코 같은 코드를 다르게 처리하지 않는다는 어려운 요구사항을 가진 VM을 복수로 구동해야 합니다. 우리가 개발하지 않은 코드에 대해서 이러한 부분에 대한 보안감사와 검증은 매우 어렵습니다.
만약 VM의 스펙이 달라진다면, 이더리움은 그것을 계속 업데이트하거나 점점 동기화되지 않은 상태로 진행될 것입니다.

그래서, 아마도 우리가 현재까지 개발한 EVM과 근본적으로 다른 EVM을 만드는 것은 아마도 불가능했었을 것 같습니다. 만약 다르게 개발을 했었다면 더 나은 결과를 만들어낼 수 있는 디테일에는 (jumps, 64bit vs 256 bit 등에서 말이죠) 상당히 차이가 있겠지만요.

ETH의 배분이 현재와는 다르게 진행되었어야 했을까?

현재의 ETH 공급은 대략적으로 Etherscan에서 제공되는 차트로 파악이 됩니다.

현재 존재하는 ETH의 절반정도는 공개 세일을 통해서 판매가 되었습니다. 누구나 BTC를 표준화된 주소에 보낼 수 있었고, 초기의 ETH 공급 배분이 비트코인 블록체인에서 그 주소로 보내어지는 트랜잭션을 스캔하는 오픈 소스 스크립트에 의해 계산되었죠. 나머지 대부분은 채굴에 의해 생성되었습니다. 아주 적은 부분을 차지하는 1200만개 ETH는 “Other”로 표현이 되어있는데, 이것들은 사전채굴이 되어서 이더리움 재단에 의해 약 100개 이상의 이더리움 프로토콜 기여자에게 배분된 것들입니다.

이 과정에 대한 두 가지 주된 비판은 다음과 같습니다.

이더리움 재단이 세일을 통해 모금을 한 것과 마찬가지로 사전채굴을 한 것은 확실하게 중립적이지 않다는 지적입니다. 몇몇 수취 지갑주소가 수동으로 비공개된 상황에서 진행되었는데, 이더리움 재단은 스스로에게 더 많은 ETH를 제공하기 위해 판매 중에 받은 자금을 다시 활용하여 판매된 것으로 만들어내는 일종의 자기 대출을 하지 않았다는 신뢰를 받아야 했습니다. (우리는 그렇게 하지 않았고, 우리가 그렇게 했다고 아무도 비판하지 않았지만, 전적으로 신뢰할 수 있어야 한다는 요구 사항조차 논란의 여지가 됩니다.)
사전 채굴이 초기 기여자에 대해서 과도하게 보상되었고, 차후의 기여자에게 너무 적은 보상을 제공했다라는 비판이 있습니다. 75%의 사전 채굴이 이더리움 런칭 이전의 작업에 대해서 보상으로 이루어졌고, 런칭 이후에 이더리움 재단은 오직 300만 ETH만 갖고 있었습니다. 6개월 내로 재단은 경제적인 압박으로 인해 판매를 해야만했고, 현재는 100만 ETH 가량으로 보유량이 줄어들게 되었습니다.

이러한 과정에서 문제점들은 중앙화에 대한 인식을 최소화하려는 의지와 관련이 있는데, 이 때문에 사전채굴량을 더 적게 만들었고, 이러한 적은 양의 사전채굴에 할당된 수량은 빠르게 소진되어 버렸습니다.

이런 방법이 할 수 있었던 유일한 방법은 아니긴 합니다. Zcash는 조금 다른 접근방법을 취하고 있습니다. 지속적으로 블록 보상의 20%는 하드 코딩된 프로토콜 내부의 수취자에게 전달되는데, 매 4년마다 수취자는 보상에 대해 재협상을 해야합니다. (아직까지는 한 번만 재협상이 되었네요.) 이러한 구조는 좀 더 지속가능한데, 하지만 매우 중앙화되었다는 비판을 받기도 합니다. (Zcash 커뮤니티는 이더리움 커뮤니티보다 기술관료주의적인 리더십에 대해서 조금 더 개방적인 태도를 갖고 있는 것 같네요.)

다른 한 가지 대안은 프로토콜의 1일차부터 DAO를 활용하는 것과 같은 방법을 쓰는 것 입니다. 최근에 디파이 프로젝트들에서 많이 유행하는 방식이죠. 여기 가능한 유사한 제안들이 있습니다.

향후 2년동안, 매 블록 보상에서 2ETH는 개발 자금으로 활용되는 것에 동의한다.
이더리움의 공개판매에서 ETH를 구매했던 사람은 누구나 개발 자금의 분배에 대해 그들이 선호하는 투표를 할 수 있다. (예를 들어, 매 블록의 1ETH는 이더리움 재단으로, 0.4ETH는 컨센시스 리서치 팀으로, 0.2ETH는 Vlad Zamfir에게 보내진다.)
투표를 받은 수취자들은 개발 자금에서 모든 투표의 중앙값에 해당하는 만큼의 비중으로 받고, 배분되는 ETH의 총 합계가 매 블록마다 2ETH가 되도록 조정됩니다. (중앙값을 활용하는 이유는 자기 자신에게 투표하여 왜곡시키는 결과를 막기 위함. 만약 당신이 스스로에게 투표했다면 최소 절반 이상의 다른 ETH 구매자들이 당신을 언급하지 않는한, 당신은 아무것도 받을 수 없습니다.)

그런 판매 세일은 수취한 비트코인과 동시에 동일한 비율로 ETH 개발 펀드를 분배할 의무를 가진 법적인 주체를 활용하는 방법도 있습니다. (우리가 정말 비트코인 홀더들을 기쁘게 하고 싶다면 소각해버려도 되구요.) 이러한 방법들은 아마도 신뢰할 수 있는 중립성을 해치지 않으면서도 이더리움 재단이 좀 더 많은 자금을 얻는 결과를 가져왔을 것이고, 또 이더리움 재단이 아닌 그룹들도 많은 펀딩을 받을 수 있겠죠. (좀 더 탈중앙화된 생태계를 만들면서요). 안 좋은 점은 물론 코인을 통한 투표가 정말 별로라는 것입니다. 하지만 2014년은 정말 초기 단계이자 이상적인 시간이었고, 대부분의 심각한 코인 투표의 단점들이 세일이 끝난 이후에 시작된다는 것을 실질적으로 깨달았었을 수도 있겠네요.

이러한 아이디어가 더 낫고, 또 좋은 선례들이 되었었을까요? 그럴지도 모르겠네요. 현실적으로 개발 펀드가 완전히 신뢰할 수 있는 중립성을 갖고 있었다 할지라도, 요즘에도 이더리움의 사전채굴에 대해 불평하는 사람들은 DAO fork에 대해 비판하는 것보다 두 배 정도 더 목소리를 높이고 있을 수도 있었겠네요.

이런 것들을 통해 무엇을 배울 수 있을까?

일반적으로 저는 이더리움의 가장 큰 어려움은 두 가지 비젼을 조화시키는데서 온다는 느낌을 받습니다. 하나는 보안과 간단함을 중시하는 순수하고 간결한 블록체인이라는 비젼이고, 둘째는 보다 진보된 어플리케이션을 구축하기 위해 더 높은 성능을 가진 기능적인 플랫폼입니다.

위의 많은 예시들은 결국 우리가 비트코인과 유사하게 더 적은 기능을 가진 것을 원하는지 아니면 개발자 친화적이고 더 많은 기능을 가진 것을 원하는지에 대한 관점에 대한 것들입니다. 또, 개발을 위한 펀드를 신뢰할 수 있는 중립성을 갖게 만들고 비트코인처럼 되는 것에 대해 너무 많은 걱정을 하는가 혹은 더 나은 이더리움을 만드는 것에 우선순위를 두고 개발이 원활하게 진행될 수 있도록 자금을 모으는 것을 중요하게 생각하는가에 대한 것들입니다. (역자 주 : 비트코인은 단순 페이먼트를 위한 용도에 대한 개발을 중시하고, 더 이상의 포크를 통한 플랫폼화를 추구하지 않기 때문에 비트코인 개발자를 위한 펀드가 상당히 빈약하고 한편으로는 신뢰할 수 있는 중립성을 갖고 있다고 비탈릭은 생각하고 있습니다. 이에 반해 이더리움은 플랫폼으로서 더 많은 성능과 기능을 만들어내기 위해서 좀 더 적극적인 개발자 펀드가 필요하고, 이 때문에 완전히 탈중앙화된 비트코인에 비해서 펀드의 중립성이 다소 약화된다고도 할 수 있습니다.)

저의 개인적인 희망은 이러한 두 비젼을 동시에 달성하는 것입니다. 기초 레이어의 스펙은 매년 좀 더 간결해지고 간소화되고, 레이어2 프로토콜을 중심으로 개발자 친화적인 생태계가 구축되는 상황을 희망하고 있습니다. 즉, 이러한 이상적인 상황을 달성하기 위해서는 꽤나 긴 시간이 걸리겠지만, 좀 더 명확한 현실인식은 이를 위해서는 시간이 걸리고, 명확한 로드맵을 갖고 한 걸음 한 걸음 전진해 나가는 것이 매우 도움이 될 수 있다는 것을 이해하는 것입니다.

현재 우리가 바꿀 수 없는 것들이 정말 많습니다만, 여전히 바꿔 낼 수 있는 것들도 많이 있습니다. 또 기능성과 간결성을 개선하기 위해 열려있는 좋은 길들도 여전히 있습니다. 때로는 그런 길이 구불구불한 길이겠죠. 처음에 레이어2 에서의 확장성을 가능하게 하게 만드는 샤딩을 현실화하기 위해서는 좀 더 많은 복잡함이 필요할 것입니다. 즉, 복잡성을 줄이는 것은 가능하지만, 이더리움의 역사는 이미 이러한 것들을 증명했습니다.

EIP-150을 통해서 호출 스택(call stack)의 깊이 제한(depth limit)이 더 이상 관련이 없도록 만듬으로써 컨트랙트 개발자들이 보안에 대한 우려를 덜어낼 수 있게 했습니다.
EIP-161을 통해서 필드가 비어있는 계정으로 부터 “비어있는 계정”에 대한 컨셉을 분리시켜 더 이상 존재하지 않도록 만들었습니다.
EIP-3529는 환불 메커니즘의 일부를 제거했으며, 가스 토큰을 더 이상 사용 할 수 없도록 만들었습니다.

버클 트리(Verkle Trees)와 같이 진행중인 아이디어들은 복잡성을 상당수 감소시킵니다. 하지만 두 개의 비젼을 미래에 어떻게 더 조화시킬지에 대한 의문은 여전히 우리가 적극적으로 생각하기 시작해봐야 할 것들입니다.