EIP-4938 eth/67: GetNodeData 메시지 제거 ("eth/67 - Removal of GetNodeData")
최종 확정 · 네트워크·노드 · 원문 상태 Final · 2022-03-23 작성
노드끼리 데이터를 주고받는 와이어 프로토콜에서 GetNodeData와 NodeData 메시지를 없애고 새 프로토콜 버전 eth/67을 도입합니다.
왜 필요한가
이더리움 노드들은 와이어 프로토콜(wire protocol)이라는 공통 규약으로 블록과 상태 데이터를 주고받습니다. 그중 GetNodeData는 상태 트라이(state trie)의 조각이나 컨트랙트 코드를 해시값으로 요청하는 메시지로, 블록을 전부 실행하지 않고 상태를 내려받는 패스트 싱크(fast sync)를 위해 만들어졌습니다. 이 요청에 답하려면 노드가 '해시에서 트라이 노드를 찾는 매핑' 형태로 상태를 저장해야 한다는 문제가 있습니다. 이 저장 방식은 부담이 크고 실제로 일부 클라이언트는 상태를 다른 방식으로 저장하기 때문에 이 요청에 아예 응답할 수 없습니다. 프로토콜은 클라이언트가 실제로 할 수 있는 일만 담아야 하므로, 구현이 불가능한 메시지를 규약에서 걷어내자는 제안입니다.
무엇이 바뀌나
지금
- 와이어 프로토콜에 GetNodeData와 NodeData 메시지가 포함되어 있습니다
- 이 요청에 답하려면 노드가 해시에서 트라이 노드로 가는 매핑을 데이터베이스에 저장해야 합니다
- 일부 클라이언트는 상태 저장 방식이 달라 이 요청을 처리할 수 없습니다
EIP-4938 이후
- 새 버전 eth/67에서 두 메시지가 제거됩니다
- 노드가 해시 기반 매핑을 저장할 필요가 없어집니다
- 같은 기능은 스냅 프로토콜(snap protocol)의 GetByteCodes와 GetTrieNodes로 대신합니다
누구에게 영향이 있나
- 클라이언트 팀: GetNodeData를 처리하기 위한 해시 기반 상태 저장을 유지할 필요가 없어지고 eth/67 버전을 새로 배포해야 합니다.
- 노드 운영자: 새로 동기화하는 노드는 패스트 싱크 대신 스냅 프로토콜 기반 동기화를 사용하게 됩니다. 구버전 클라이언트도 eth/66으로 당분간 계속 동작합니다.
- 일반 사용자: 노드 간 통신 규약의 정리이므로 트랜잭션, 수수료, 지갑 사용에는 변화가 없습니다.
심층 설명
제거되는 메시지 두 가지
eth 프로토콜에서 GetNodeData (0x0d)와 NodeData (0x0e)를 제거합니다. eth/66 기준 인코딩은 각각 [request_id: P, [hash_0: B_32, hash_1: B_32, ...]]와 [request_id: P, [value_0: B, value_1: B, ...]]입니다. 즉 요청 ID와 32바이트 해시 목록을 보내면, 해당 해시에 대응하는 값(트라이 노드 또는 컨트랙트 코드)의 목록을 돌려받는 구조였습니다.
제거 동기: 저장 구조 강제와 구현 불가
GetNodeData와 NodeData는 eth/63에서 패스트 싱크를 위해 도입됐습니다. 패스트 싱크는 모든 블록을 실행하지 않고 상태 트라이 노드와 컨트랙트 코드를 해시로 요청해 상태를 내려받는 방식입니다. 이 요청을 서빙하려면 클라이언트가 상태를 '해시 → 트라이 노드' 매핑으로 저장해야 하는데, 이런 매핑을 데이터베이스에 두지 않아도 되게 하는 것이 제거의 주된 동기입니다. 현재 일부 클라이언트는 상태를 호환되는 방식으로 저장하지 않아 이 요청을 서빙할 수 없으며 와이어 프로토콜은 클라이언트의 실제 능력을 정확히 반영해야 하고 일부 클라이언트가 구현할 수 없는 메시지를 담아서는 안 된다는 것이 원문의 논리입니다.
대체 수단: 스냅 프로토콜
GetNodeData의 대체재는 별도의 snap 프로토콜에 이미 있습니다. 구체적으로 GetByteCodes (0x04)와 GetTrieNodes (0x06) 메시지를 대신 쓸 수 있습니다. snap 프로토콜로 패스트 싱크 알고리즘을 구현하는 것도 가능하지만 원문은 snap sync에 사용할 것을 권장합니다.
하위 호환성: 하드포크 없는 버전 교체
이 EIP는 eth 프로토콜을 바꾸므로 새 버전 eth/67의 롤아웃이 필요합니다. 와이어 프로토콜은 여러 버전을 동시에 지원할 수 있어서 새 버전을 내놓아도 구버전 클라이언트는 eth/66을 계속 쓸 수 있고 즉시 깨지지 않습니다. EVM 합의 규칙은 바꾸지 않으므로 하드포크가 필요 없습니다. 보안 고려사항은 원문에 '없음'으로 명시되어 있으며 상태는 Final로 확정된 네트워킹 표준입니다.