[Devcon 6] Day 4 on Post-Merge Ethereum Client Architecture
Post-Merge Ethereum Client Architecture
[Devcon 6] Devcon 시리즈
- [Devcon 6] Day 1 on Ethereum Transaction Insight
- [Devcon 6] Day 2 on Update of EVM
- [Devcon 6] Day 3 on Ethereum Assembly
- [Devcon 6] Day 4 on Post-Merge Ethereum Client Architecture
개요
Ethereum Devcon 6 는 The Merge 에 대해 중점적으로 다루어졌다. Devcon 의 마지막 날인 Day 4 에는 Merge 이후의 Post-Merge 의 Ethereum Client Architecture 에 대해 설명하는 세션이 진행되었다. 이 글에서는 세션에 대한 요약으로서 Post-Merge 가 직면한 과제들과 그에 대한 Solution 들을 분석해보려고 한다.
분석
Differences
- LibP2P vs DevP2P
- Discv5 vs Discv4/DNS
- SSZ vs RLP
- Sha256 vs keccak
- BLS vs ECDSA
Key Differences
Time Driven Consensus (Block Creation)
- 0s Block: 12초 마다 새로운 slot 이 생성된다.
- 4s Attestations: Validators 가 블록이 유효한 지 확인하고 투표한다.
- 8s Aggregates: Aggregator 들이 블록을 수집한다.
Large execution state
- Syncing, Pruning, Indexing 에 대한 변경
- 그 외의 performance 를 위한 변경
문제: Deployment model
위의 architecture 를 위해 User 가 Node 를 실행할 때 두 client 를 모두 실행해야할까? 현재는 그렇지만 2가지 해결방안이 있다.
방법 1: Light Consensus client
Execution client 내부에 Light Consensus client 를 구현한다. 만약 단순히 트랜잭션을 보내거나, API 호출을 할 노드가 필요하다면 좋은 선택이다.
장점
- 기본적인 node 를 실행하는 users 에게 적절하다.
- system 요구사항을 감소시킨다.
단점
- 새로운 slot 이 처리될 때까지 기다려야 한다.
- validators 에게 적절하지 않다.
방법2: Combine client
Execution client 와 Consensus client 를 하나의 프로세스로 실행한다.
장점
- 새로운 node 를 시작하는 user 에게 적절하다.
단점
- client 가 다양하다 (EC: 약 4개, CC: 약 5개 따라서 20개의 client 조합을 위해 실행환경을 개발해야 한다.)
- 의존성이 충돌한다
- core 개발에 알아야할 사항이 너무 많다.
- scope creep 을 유발한다.
문제: 데이터 중복
Consensus client 와 Execution client 가 실행 Data 를 중복으로 저장하는 문제이다. Client 들은 데이터를 저장하고 peer 들에게 전달하기 위하여 API 도 가지고 있어야 한다. 이에 대한 solution 으로 두 가지 방법을 비교해보자.
방법 1: Engine API(engine_getPayloadBodies)
Execution client 로부터 실행 Data 를 얻는다.
장점
- transaction data 의 duplication 을 없앤다.
- 효율이 좋다.
단점
- execution client 에 많은 요청
- 결합도 증가
방법 2: 이전 블록 제거
두 client 에 Data 를 저장하지만, consensus client 는 이전(5개월이 지난) 블록 데이터를 제거한다.
장점
- 중복 트랜잭션을 제거하는 것 보다 간단하다.
- consensus client 의 disk 요구사항이 고정된다.
단점
- archive nodes 를 도울 수 없다.
- 블록체인의 사상에 맞지 않다.
결론
Consensys 의 Lead Blockchain Protocol Enginner 인 Adrian Sutton 은 실제 개발을 하면서 생각하는 문제점과 Solution을 매우 구체적이고 쉽게 설명해주었다. 강연을 들으며 문제점이 나올 때는 머릿속으로 해결 방안을 떠올렸으며, 공감되는 해결 방안이 나올때는 짜릿함을 느꼈다.
지금의 Ethereum 에 이르기까지 수많은 문제와 직면하고 해결해왔을 모든 기여자들에게 감사하고, 나 또한 그러한 기여자가 될 수 있도록 기원하며 Devcon 6 를 마무리한다.
