이더리움은 반드시 "떠나도 작동하는 테스트"를 통과해야 한다

이더리움은 반드시 "떠나도 작동하는 테스트"를 통과해야 한다 이더리움은 금융, 거버넌스 등 다양한 영역에서 트러스트리스(trustless)하고 신뢰 최소화된 애플리케이션들의 터전이 되어야 한다. 이더리움은 서비스보다는 도구에 가까운 애플리케이션을 지원해야 한다. 한번 사면 영원히 내 것인 망치처럼, 벤더가 유지보수에 흥미를 잃거나(더 나쁘게는 해킹당하거나 가치 착취적으로 변하더라도) 모든 기능을 상실하지 않는 그런 애플리케이션 말이다. 애플리케이션에 벤더에 의존하는 기능이 있더라도, 이더리움은 그 의존성을 최대한 줄이고, 의존성이 실패할 경우에도 사용자를 최대한 보호할 수 있어야 한다. 하지만 이런 애플리케이션을 구축하는 것은, 베이스 레이어 자체가 계속 사용 가능하려면 벤더의 지속적인 업데이트에 의존해야 하는 상황에서는 불가능하다. 그 "벤더"가 올코어데브(all core devs) 프로세스라 하더라도 말이다. 이더리움 블록체인은 우리가 이더리움 애플리케이션에서 추구하는 특성들을 갖춰야 한다. 그러므로 이더리움 자체가 반드시 "떠나도 작동하는 테스트"를 통과해야 한다. 이것은 이더리움이 원한다면 경직화(ossify)할 수 있는 지점에 도달해야 함을 의미한다. 프로토콜 변경을 멈출 필요는 없지만, 이더리움의 가치 제안이 아직 프로토콜에 없는 기능에 엄격하게 의존하지 않는 상태에 도달해야 한다. 여기에는 다음이 포함된다: 1. 완전한 양자 내성. "당분간 효율성을 조금 더 쥐어짜기 위해 양자 내성을 최대한 늦추자"는 함정에 빠지지 말아야 한다. 개별 사용자에게는 그럴 권리가 있지만, 프로토콜은 그래서는 안 된다. "오늘날 이더리움 프로토콜은 100년간 암호학적으로 안전하다"고 말할 수 있는 것은 우리가 최대한 빨리 도달하고, 자부심의 포인트로 고집해야 할 목표다. 2. 충분한 확장성으로 확장할 수 있는 아키텍처. 프로토콜은 시간이 지남에 따라 수천 TPS로 확장할 수 있는 속성을 가져야 한다. 특히 ZK-EVM 검증과 PeerDAS를 통한 데이터 샘플링이 그렇다. 이상적으로는 추가 확장이 "파라미터 변경만으로" 이루어지는 지점에 도달해야 하고—이상적으로 그 변경들도 BPO 스타일 포크가 아니라 가스 리밋에 사용하는 것과 같은 검증자 투표 메커니즘으로 이루어져야 한다. 3. 수십 년을 버틸 수 있는 상태 아키텍처. 이것은 이더리움이 수십 년간 수천 TPS로 운영되면서도 동기화나 하드 디스크, I/O 요구사항을 깨뜨리지 않을 것이라고 편안하게 느낄 수 있는 형태의 부분적 무상태성(partial statelessness)과 상태 만료(state expiry)를 결정하고 구현하는 것을 의미한다. 또한 이 장기적 환경에서 잘 작동하도록 트리와 저장소 타입을 미래 대비하는 것도 포함한다. 4. 범용적인 계정 모델 (이것이 "완전한 계정 추상화"다: 서명 검증을 위한 내장 ECDSA에서 벗어나기) 5. DoS 취약점이 없다고 확신할 수 있는 가스 스케줄, 실행과 ZK-증명 모두에서 6. 수십 년간 지속되고 탈중앙화를 유지할 수 있다고 확신하는 PoS 경제 모델, 이더리움에서의 지분증명 반 년(5년)과 그 이상의 십년간 배운 모든 것을 바탕으로, 그리고 ETH를 트러스트리스 담보로서 유용하게 지원하는 것 (예: 거버넌스 최소화된 ETH 담보 스테이블코인) 7. 중앙화 압력에 저항하고 미지의 미래 환경에서도 검열 저항성을 보장할 것이라 확신하는 블록 빌딩 모델 이상적으로, 우리는 향후 몇 년간 고된 작업을 해서, 미래에는 거의 모든 혁신이 클라이언트 최적화를 통해 일어나고 파라미터 변경으로 프로토콜에 반영되는 지점에 도달해야 한다. 매년 이 박스들 중 최소 하나, 이상적으로는 여러 개를 체크해야 한다. 진정으로 올바른 것이 무엇인지에 대한 지식을 바탕으로 한 번에 제대로 하고(중간에서 타협한 임시방편이 아니라), 이더리움의 기술적, 사회적 견고함을 장기적으로 극대화해야 한다. 이더리움은 제대로 간다. (Ethereum goes hard.) 이것이 gwei다. 출처 원본