저자: Vitalik, 이더리움 창시자

원제목: 《The roads not taken》

번역: Mary Ma, 우说区块链

이더리움 개발 커뮤니티는 이더리움의 초기 단계에서 많은 결정을 내렸고, 이러한 결정은 프로젝트의 발전 궤적에 큰 영향을 미쳤습니다. 어떤 경우에는 이더리움 개발자들이 의식적으로 결정을 내리고, 우리가 비트코인에서 문제라고 생각하는 부분을 개선했습니다. 다른 경우에는 우리는 완전히 새로운 것을 창조하고 있었고, 단순히 공백을 채우기 위해 무언가를 생각해내야 했지만 선택할 수 있는 것이 많았습니다. 또 어떤 부분에서는 더 복잡한 것과 더 단순한 것 사이에서 균형을 잡아야 했습니다. 때로는 비교적 단순한 것을 선택하기도 했지만, 때로는 더 복잡한 것을 선택하기도 했습니다.

이 글은 제가 기억하는 이더리움의 이러한 갈림길에 주목할 것입니다. 많은 기능들이 핵심 개발圈에서 진지하게 논의되었고; 어떤 것은 거의 고려되지 않았지만, 아마도 정말로 고려해야 할 것입니다. 하지만 그럼에도 불구하고, 우리는 다른 이더리움이 어떤 모습일지, 그리고 우리가 그로부터 무엇을 배울 수 있을지를 살펴볼 필요가 있습니다.

더 간단한 PoS 메커니즘을 채택해야 할까요?

이더리움이 곧 통합할 Gasper PoS 메커니즘은 복잡한 시스템이지만, 매우 강력한 시스템이기도 합니다. 그것의 몇 가지 속성은 다음과 같습니다:

• 매우 강력한 단일 블록 확인: 거래가 블록에 포함되면, 일반적으로 몇 초 이내에 해당 블록은 최종적으로 확인되며, 많은 노드가 부정직하지 않거나 극단적인 네트워크 지연이 없다면, 이는 되돌릴 수 없습니다.

• 경제적 최종성: 블록이 최종적으로 확인되면, 공격자가 수백만 ETH의 손실을 감수하지 않는 한 되돌릴 수 없습니다.

• 매우 예측 가능한 보상: 검증자는 매 에포크(6.4분)마다 신뢰할 수 있는 보상을 받을 수 있습니다.

• 매우 높은 검증자 수 지원: 위의 특성을 가진 다른 대부분의 체인과 달리, 이더리움 신호 체인은 수십만 명의 검증자를 지원합니다(예: Tendermint는 이더리움보다 더 빠른 최종성을 제공하지만, 몇 백 명의 검증자만 지원합니다).

하지만 이러한 특성을 가진 시스템을 만드는 것은 어렵습니다. 이는 수년간의 연구와 수년간의 실패한 실험이 필요하며, 일반적으로 많은 노력이 필요하고, 최종 출력은 상당히 복잡합니다.

만약 우리의 연구자들이 그렇게 많은 합의에 대해 걱정할 필요가 없고, 더 많은 자유로운 사고 시간을 가질 수 있다면, 아마도, 단지 아마도, 롤업이 2016년에 발명될 수 있었을 것입니다. 이것은 우리에게 하나의 질문을 던집니다: 우리는 정말로 우리의 PoS에 대해 이렇게 높은 기준을 요구해야 할까요? 왜냐하면 더 간단하고 약한 PoS조차도 PoW의 현상보다 큰 개선이 될 것이기 때문입니다.

많은 사람들은 PoS 자체가 복잡하다고 오해하지만, 실제로는 많은 PoS 알고리즘이 거의 나카모토 PoW 합의만큼 간단합니다. NXT의 PoS는 2013년부터 존재했으며, 원래는 즉시 사용할 수 있는 후보였습니다; 비록 몇 가지 문제가 있지만, 이러한 문제는 쉽게 수정할 수 있으며, 우리는 2017년, 심지어 처음부터 합리적으로 실행 가능한 PoS를 가질 수 있었습니다. Gasper가 이러한 알고리즘보다 더 복잡한 이유는 단지 그것이 수행하려는 작업이 훨씬 더 많기 때문입니다. 그러나 만약 우리가 처음부터 너무 높은 목표를 세우지 않는다면, 우리는 더 제한된 목표를 달성하는 데 집중할 수 있습니다.

제 생각에는 처음부터 PoS를 구현하는 것은 잘못된 결정이었습니다; PoW는 초기 발행량 분배를 확대하고 이더리움을 더 접근 가능하게 만드는 데 도움이 되었으며, 열정적인 커뮤니티를 장려할 수 있었습니다. 그러나 2017년, 심지어 2020년에는 더 간단한 PoS로 전환하는 것이 환경 파괴(및 환경 파괴로 인한 반 암호화폐 정서)를 줄이고, 더 많은 연구 인재들이 확장 문제에 대해 자유롭게 생각할 수 있게 했을 것입니다. 우리는 결국 더 나은 PoS를 만들기 위해 많은 자원을 소비해야 할까요? 저는 그럴 것이라고 생각하지만, 지금으로서는 어쨌든 우리는 결국 그렇게 할 것입니다.

샤딩의 복잡성 제거

이더리움 샤딩은 2014년부터 연구가 시작된 이후 점점 더 단순한 방향으로 발전해 왔습니다. 처음에는 내장 실행 및 크로스 샤드 거래의 복잡한 샤딩이 있었습니다; 그런 다음 우리는 사용자에게 더 많은 책임을 전가하여 프로토콜을 단순화했습니다. 크로스 샤드 거래에서 사용자는 두 샤드에 대해 각각 Gas 비용을 지불해야 했습니다; 이어서 우리는 롤업 중심의 로드맵으로 전환했으며, 여기서 프로토콜 관점에서 샤딩은 단지 데이터 샤딩일 뿐입니다. 마지막으로, danksharding을 통해 샤딩 비용 시장이 하나로 통합되어 최종 설계는 비샤드 체인처럼 보이지만, 여기서 데이터 가용성 샘플링이 샤딩 검증을 가능하게 합니다.

하지만 우리가 반대의 길을 간다면 어떻게 될까요? 실제로 몇몇 이더리움 연구자들은 더 복잡한 샤딩 시스템을 깊이 탐구했습니다: 샤딩은 체인으로 작동하며, 분기 선택 규칙이 있으며, 서브 체인은 부모 체인에 의존하고, 크로스 샤드 메시지는 프로토콜에 의해 라우팅되며, 검증자는 샤드 간에 순환하고, 심지어 DApp은 샤드 간에 자동으로 로드 밸런싱을 수행합니다.

이 방법의 문제는 이러한 형태의 샤딩이 대부분 아이디어와 수학 모델일 뿐이며, Danksharding은 완전하고 거의 구현 가능한 규격이라는 것입니다. 따라서 이더리움의 상황과 제약을 고려할 때, 제 생각에는 샤딩의 단순화와 모호성 제거는 절대적으로 올바른 조치입니다. 즉, 더 야심찬 연구도 매우 중요한 역할을 합니다: 그것은 유망한 연구 방향을 설정하며, 심지어 매우 복잡한 아이디어조차도 "합리적으로 단순한" 버전이 있으며, 이러한 아이디어는 여전히 많은 이점을 제공하고, 향후 몇 년 내에 이더리움의 발전(심지어 2층 프로토콜)에 큰 영향을 미칠 가능성이 높습니다.

EVM에서 기능 선택

실제로 보안 감사 외에도 EVM의 규격은 기본적으로 2014년 중반에 출시될 수 있었습니다. 그러나 그 이후 몇 달 동안 우리는 분산형 블록체인에 진정으로 중요한 새로운 기능을 탐색하기 위해 계속해서 적극적으로 노력했습니다. 일부 기능은 EVM에 추가되었고, 일부는 추가되지 않았습니다.

• 우리는 POST 연산 코드를 추가하는 것을 고려했지만, 그렇게 하지 않기로 결정했습니다. POST 연산 코드는 비동기 호출을 수행하며, 거래가 완료된 후 실행됩니다.

• 우리는 ALARM 연산 코드를 추가하는 것을 고려했지만, 그렇게 하지 않기로 결정했습니다. ALARM의 기능은 POST와 유사하지만, 미래의 특정 블록에서 비동기 호출을 실행하여 계약이 작업을 예약할 수 있도록 합니다.

• 우리는 로그(log)를 추가했습니다. 이는 계약이 상태를 건드리지 않고 기록을 출력할 수 있게 하며, DApp 인터페이스와 지갑이 이를 해석할 수 있습니다. 주목할 점은 ETH 전송이 로그를 발행하도록 하는 것도 고려했지만, "사람들이 곧 스마트 계약 지갑으로 전환할 것이기 때문에" 그렇게 하지 않기로 결정했습니다.

• 우리는 SSTORE를 확장하여 바이트 배열을 지원하는 것을 고려했지만, 복잡성과 안전성에 대한 우려로 그렇게 하지 않기로 결정했습니다.

• 우리는 프리컴파일(precompiles)을 추가했습니다. 이는 로컬 구현을 사용하여 전용 암호화 작업을 실행하는 계약으로, EVM에서 실행하는 것보다 훨씬 저렴합니다.

• 출시 후 몇 달 동안 우리는 상태 임대(state rent)를 반복적으로 고려했지만, 결코 포함되지 않았습니다. 이는 너무 복잡했습니다. 오늘날 사람들은 더 나은 상태 만료(state expiry) 솔루션을 적극적으로 탐색하고 있지만, 무상태 검증과 제안자/구축자 분리(PBS)는 현재 훨씬 낮은 우선 순위를 의미합니다.

오늘날 대부분의 기능을 추가하지 않기로 한 결정은 매우 좋은 결정으로 입증되었습니다. POST 연산 코드를 추가할 명확한 이유가 없습니다. ALARM 연산 코드는 실제로 안전하게 구현하기가 매우 어렵습니다: 1…9999 블록의 모든 사람이 ALARM을 설정하면, 100000 블록에서 대량의 코드가 실행될 경우 어떻게 될까요? 그 블록은 처리하는 데 몇 시간이 걸릴까요? 일부 예약된 작업이 이후 블록으로 밀려날까요? 그러나 이러한 상황이 발생하면 ALARM은 어떤 보장을 유지할 수 있을까요? 바이트 배열의 SSTORE는 안전하게 수행하기가 어렵고, 최악의 경우 증인 크기를 크게 확장할 수 있습니다.

상태 임대 문제는 더 도전적입니다: 만약 우리가 첫날부터 실제로 어떤 상태 임대를 구현했다면, 이더리움은 항상 지속 가능한 상태의 정상화 가정에 따라 발전할 필요가 없었을 것입니다. 이더리움은 더 구축하기 어려워지겠지만, 더 확장 가능하고 지속 가능할 수 있습니다. 동시에, 당시 우리의 상태 만료 계획은 현재의 계획보다 훨씬 나빴습니다. 때때로 좋은 아이디어는 몇 년이 걸려야 실현되며, 더 나은 방법이 없습니다.

LOG의 대안

LOG는 두 가지 다른 방법으로 수행될 수 있습니다.

1. 우리는 ETH 전송이 자동으로 LOG를 발행하도록 할 수 있습니다. 이는 거래소와 많은 다른 사용자에게 많은 에너지를 절약하고 소프트웨어 오류 문제를 줄이며, 모든 사람이 LOG에 대한 의존성을 가속화할 수 있게 하여 스마트 계약 지갑의 채택에 도움이 될 것입니다.

2. 우리는 LOG 연산 코드가 필요 없으며, 이를 ERC로 변환할 수 있습니다: 표준 계약이 있으며, submitLog라는 함수를 가지고, 이더리움 예치 계약의 기술을 사용하여 해당 블록의 모든 로그의 Merkle 루트를 계산합니다. EIP-2929 또는 블록 범위의 저장소(상당히 TSTORE와 유사하지만 블록 이후에 삭제됨)는 이를 저렴하게 만들 것입니다.

우리는 첫 번째 방법을 강력히 고려했지만, 이를 거부했습니다. 주요 이유는 로그가 LOG 연산 코드에서만 발생하기 때문에 더 쉽기 때문입니다. 우리는 또한 대부분의 사용자가 스마트 계약 지갑으로 신속하게 전환할 것이라고 매우 잘못 예상했습니다. 이는 명확하게 연산 코드를 사용하여 전송을 기록할 수 있습니다.

우리는 두 번째 방법을 고려하지 않았지만, 돌아보면 이것도 하나의 선택이었습니다. 두 번째 방법의 주요 단점은 빠른 스캔 로그를 위한 블룸 필터 메커니즘(Bloom filter)이 부족하다는 것입니다. 그러나 블룸 필터 메커니즘은 너무 느려서 DApp에 친숙하지 않으므로, 현재 점점 더 많은 사람들이 TheGraph를 사용하여 쿼리를 수행하고 있습니다.

전반적으로 이러한 방법 중 어느 것이든 현상보다 나을 가능성이 있습니다. LOG를 포함하지 않으면 일이 더 간단해지지만, LOG를 포함하면 모든 ETH의 전송을 자동으로 기록하는 것이 더 유용하게 만들 것입니다.

오늘날, 저는 EVM의 LOG 연산 코드를 최종적으로 제거하는 것에 찬성할 수 있습니다.

현재 EVM이 완전히 다른 길을 선택했다면?

당초 EVM은 두 가지 매우 다른 길을 선택할 수 있었습니다:

1. EVM을 변수, if 문, 루프 등의 내장 구조를 가진 더 고급 언어로 만드는 것.

2. EVM을 기존의 가상 머신(LLVM, WASM 등)의 복사본으로 만드는 것.

첫 번째 길은 실제로 고려된 적이 없습니다. 이 길의 매력은 컴파일러를 더 간단하게 만들고, 더 많은 개발자가 EVM에서 직접 코딩할 수 있게 해준다는 것입니다. 또한 ZK-EVM의 구조를 더 간단하게 만들 수 있습니다. 이 길의 약점은 EVM 코드가 구조적으로 더 복잡해진다는 것입니다: 더 이상 간단한 연산 코드 목록이 아니라, 어떤 식으로든 저장해야 하는 더 복잡한 데이터 구조가 됩니다. 즉, 우리는 양쪽 모두를 만족시키는 기회를 놓쳤습니다: 일부 EVM의 변화는 많은 이점을 가져올 수 있으며, 기본 EVM 구조를 유지할 수 있습니다: 동적 점프를 금지하고, 서브루틴을 지원하기 위한 연산 코드를 추가하며(또한 참조: EIP-2315), 32바이트의 단어 경계에서만 메모리에 접근하도록 허용하는 것입니다.

두 번째 길은 여러 번 제안되었고, 여러 번 거부되었습니다. 이를 지지하는 주장은 일반적으로 기존 언어(C, Rust 등)에서 EVM으로 프로그램을 컴파일할 수 있게 해준다는 것입니다. 반대 의견은 이더리움의 독특한 제약을 고려할 때, 실제로는 아무런 이점을 제공하지 않는다는 것입니다:

기존의 고급 언어의 컴파일러는 일반적으로 전체 코드 크기에 신경 쓰지 않지만, 블록체인 코드는 코드 크기의 각 바이트를 줄이기 위해 대량으로 최적화해야 합니다.

우리는 가상 머신의 여러 구현이 필요하며, 두 구현이 동일한 코드를 다르게 처리하지 않도록 엄격하게 요구해야 합니다. 우리가 작성하지 않은 코드에 대해 보안 감사 및 검증을 수행하는 것은 더 어렵습니다.

가상 머신 규격이 변경되면, 이더리움은 항상 그것과 함께 업데이트해야 하며, 점점 더 비동기화될 것입니다.

따라서 EVM은 우리가 오늘날 가지고 있는 것과 완전히 다른 실행 가능한 경로가 영원히 존재하지 않을 수 있지만, 많은 더 작은 세부 사항(점프, 64비트 vs 256비트 등)이 다르게 처리될 수 있다면 더 나은 결과를 가져올 수 있습니다.

ETH 공급은 다른 방식으로 분배되어야 할까요?

현재 ETH 공급량은 Etherscan의 이 그래프로 대략적으로 나타낼 수 있습니다:

현재 약 절반의 ETH가 이더리움 공모에서 판매되었으며, 누구나 비트코인 주소로 BTC를 보낼 수 있으며, 초기 ETH 공급 분배는 오픈 소스 스크립트를 통해 계산되었습니다. 나머지 대부분은 기본적으로 채굴을 통해 생성되었습니다. 검은색 부분의 1200만 ETH는 "기타"로 표시되며, 사실은 이더리움 재단과 약 100명의 이더리움 프로토콜 초기 기여자들 간에 분배된 예비 채굴 부분입니다.

이 과정에 대한 주요 비판은 두 가지입니다:

• 예비 채굴과 이더리움 재단이 공모 자금을 관리하는 것은 신뢰할 수 있는 중립성을 갖추지 못했습니다. 일부 수취인 주소는 폐쇄된 과정을 통해 인위적으로 선택되었으며, 이더리움 재단은 신뢰를 받아야 하며, 공모에서 얻은 자금을 더 많은 ETH를 얻기 위해 대출로 활용할 수 없습니다(우리는 그러지 않았고, 아무도 그렇게 주장하지 않았지만, 신뢰를 요구하는 것조차도 일부 사람들을 불쾌하게 했습니다).

• 예비 채굴은 매우 초기 기여자에게 과도한 보상을 주었고, 후속 기여자에게는 너무 적은 보상을 주었습니다. 75%의 예비 채굴은 출시 전 기여자의 작업을 보상하는 데 사용되었고, 출시 후 이더리움 재단에는 300만 ETH만 남았습니다. 6개월 동안 생존을 위해 판매된 수요는 재고를 약 100만 ETH로 줄였습니다.

어느 정도 이러한 문제는 관련이 있습니다: 중앙화에 대한 인식을 최소화하려는 희망이 더 작은 예비 채굴을 촉진했지만, 더 작은 예비 채굴은 더 빨리 고갈됩니다.

이것이 유일한 해결책은 아닙니다. Zcash는 다른 접근 방식을 채택했습니다: 블록 보상의 20%가 프로토콜에 하드코딩된 수취인 그룹에 고정 분배되며, 이 그룹은 4년마다 재협상합니다(현재까지 한 번 발생했습니다). 이는 더 지속 가능하지만, 지나치게 중앙화되어 더 심한 비판을 받을 수 있습니다(이더리움 커뮤니티보다 Zcash 커뮤니티가 더 공개적으로 더 많은 기술 전문가의 리더십을 수용하는 것처럼 보입니다).

가능한 대안 경로는 오늘날 일부 DeFi 프로젝트에서 유행하는 "DAO from day 1" 경로와 유사합니다. 여기에서 가능한 허수아비 제안은 다음과 같습니다:

• 우리는 2년 내에 각 블록 보상에서 2 ETH를 개발 기금에 할당하기로 동의합니다.

• 이더리움 공모에서 ETH를 구매한 사람은 그들이 좋아하는 개발 기금에 대한 투표를 할 수 있습니다(예: "각 블록 보상에서 1ETH는 이더리움 재단에, 0.4ETH는 Consensys 연구팀에, 0.2 ETH는 Vlad Zamfir에게…").

• 투표로 지지받은 수취인은 개발 기금의 몫이 모든 사람의 투표 중위수에 해당하며, 비례적으로 계산되어 총합이 각 블록당 2ETH가 됩니다(중위수는 자기 거래를 방지하기 위해: 자신에게 투표하면, 다른 구매자 중 최소한 절반이 당신을 언급하지 않는 한 아무것도 얻지 못합니다).

공모는 법인에 의해 운영될 수 있으며, ETH 개발 기금과 동일한 비율로 공모 과정에서 받은 비트코인을 분배하겠다고 약속합니다(또는 태우거나, 비트코인 플레이어를 기쁘게 하려면 그렇게 할 수 있습니다). 이는 이더리움 재단이 많은 자금을 얻고, 비이더리움 재단 그룹도 많은 자금을 얻어(더 많은 생태계의 분산화를 초래하며), 이 모든 것이 신뢰할 수 있는 중립성을 조금도 해치지 않을 수 있습니다. 물론 주요 단점은 토큰 투표가 정말로 형편없다는 것이지만, 실용적으로 볼 때, 2014년은 여전히 초기이자 이상적인 시점이며, 토큰 투표의 가장 심각한 단점은 공모가 끝난 후 오랜 시간이 지나야 나타날 것입니다.

이렇게 하는 것이 더 나은 아이디어가 될까요? 그리고 더 나은 선례를 세울까요? 아마도! 현실적인 관점에서 볼 때, 개발 기금이 완전히 신뢰할 수 있는 중립적이라 하더라도, 오늘날 이더리움의 채굴자들에게 큰 소리치는 사람들은 아마도 DAO 분할에 대해 두 배로 소리칠 가능성이 높습니다.

우리는 이 모든 것에서 무엇을 배울 수 있을까요?

전반적으로, 때때로 저는 이더리움의 가장 큰 도전이 두 비전 간의 균형에서 온다고 느낍니다: 하나는 보안과 단순한 순수 블록체인을 중시하고, 다른 하나는 고급 애플리케이션을 구축하기 위한 높은 성능과 기능을 갖춘 플랫폼입니다. 위의 많은 예는 그 중 하나의 측면일 뿐입니다: 우리는 기능이 적고 비트코인과 더 유사한 것을 원할까요, 아니면 기능이 더 많고 개발자에게 더 적합한 것을 원할까요? 우리는 개발 자금이 더 중립적이게 만드는 것을 걱정할까요, 아니면 개발자가 충분한 보상을 받아 이더리움이 더 나아지도록 하는 것을 먼저 걱정할까요?

저 개인의 꿈은 이 두 비전을 동시에 실현하려고 하는 것입니다. 매년 규격이 줄어드는 기본 층과, 2층 프로토콜 중심의 강력하고 개발자 친화적인 고급 애플리케이션 생태계입니다. 즉, 이러한 이상적인 세계에 도달하는 데는 오랜 시간이 걸리며, 이것이 시간이 필요하다는 것을 더 명확하게 인식할 수 있다면, 우리는 단계별로 로드맵을 고려하는 것이 큰 도움이 될 것입니다.

오늘날, 우리가 바꿀 수 없는 많은 것들이 있지만, 여전히 우리가 바꿀 수 있는 많은 것들이 있으며, 기능과 단순성을 개선할 수 있는 확고한 길이 여전히 존재합니다. 때때로 이 길은 우여곡절이 있습니다: 우리는 먼저 샤딩을 구현하기 위해 일부 복잡성을 추가해야 하며, 샤딩은 그 위에 많은 2층 확장성을 구현할 수 있습니다. 즉, 복잡성을 줄이는 것은 가능하며, 이더리움의 역사는 이를 증명해왔습니다.

• EIP-150은 호출 스택 깊이 제한이 더 이상 관련이 없게 만들어 계약 개발자의 보안 우려를 줄였습니다.

• EIP-161은 "빈 계정" 개념을 필드가 0인 계정과 분리했습니다.

• EIP-3529는 일부 환급 메커니즘을 삭제하여 Gas 토큰이 더 이상 실행 가능하지 않게 만들었습니다.

진행 중인 아이디어인 Verkle 트리조차도 복잡성을 더 줄일 수 있습니다. 그러나 미래에 이 두 가지 비전을 더 잘 균형 잡는 방법은 우리가 더 적극적으로 생각하기 시작해야 할 문제입니다.