EIP-8136 데이터 컬럼 전파의 셀 단위 델타 (Cell-Level Deltas for Data Column Broadcast)

콜 결정 없음 · 네트워크·노드 · 원문 상태 Last Call · 2025-01-23 작성

PeerDAS에서 블롭 데이터 컬럼을 통째로 주고받는 대신, 아직 없는 셀만 골라 주고받게 하는 네트워킹 최적화입니다. 하드포크 없이 노드별로 점진 배포할 수 있습니다.

왜 필요한가

블록이 참조하는 블롭은 대부분 이미 각 노드의 멤풀(mempool, 대기 중인 거래 저장소)에 들어와 있습니다. 즉 노드는 데이터의 상당 부분을 이미 갖고 있는데도, 지금 구조에서는 블롭 하나만 멤풀에 없어도 합의 계층이 전체 데이터 컬럼을 네트워크에서 다 받을 때까지 기다려야 데이터 가용성 검사를 통과할 수 있습니다. 이미 가진 데이터를 다시 받느라 대역폭을 낭비하고 빠진 조각 하나 때문에 전체를 기다리는 셈입니다. 이 EIP는 컬럼을 잘게 나눈 단위인 셀(cell) 수준에서 서로 무엇을 갖고 있는지 알리고 없는 셀만 받아오게 해서 이 낭비를 줄입니다.

무엇이 바뀌나

지금

EIP-8136 이후

누구에게 영향이 있나

심층 설명

Gossipsub Partial Messages 확장 기반 동작

이 최적화는 Gossipsub의 Partial Messages Extension을 사용해 셀 비트맵을 교환하고 셀을 요청·제공합니다. 단일 기준 문서를 유지하기 위해 상세 명세는 ethereum/consensus-specs 저장소에 정의되어 있습니다. 멤풀에 블롭 대부분이 있는 일반적인 경우, 노드는 이미 가진 셀을 건너뛰고 빠진 셀만 받으면 되므로 대역폭을 아낍니다.

설계 원칙: 최소 의미 변경과 역호환

설계는 두 가지 기준을 따릅니다. 첫째, 의미(semantics) 변경을 최소화합니다. 둘째, 하드포크가 필요 없는 역호환을 지킵니다. 그 결과 새 프로토콜을 만드는 대신 기존 gossipsub 동작을 확장하는 형태가 됐고 gossipsub의 메시(mesh)와 가십 속성은 그대로 유지됩니다. 가장 큰 변화로, 셀 전파의 기본 전략이 푸시에서 풀로 바뀝니다. 데이터를 미리 밀어 보내는 eager push도 여전히 가능하지만 기본 동작은 아닙니다.

기각된 대안 설계 세 가지

첫째, gossipsub 메시지 단위를 컬럼이 아닌 셀 하나로 줄이는 방안입니다. 비트맵이 일급 개념으로 없으면 셀마다 메시지 오버헤드가 생기고 보유 셀을 알리는 IDONTWANT가 피어의 푸시와 항상 경쟁합니다. 콘텐츠 해시 기반 메시지 ID에는 어느 블록의 셀인지 맥락이 없어 없는 셀을 요청하거나 우선순위를 정할 수 없습니다. 메시지 ID 의미를 바꾸는 우회도 별도 토픽이 필요하고 메시지 ID와 메시지의 1:1 가정을 깨뜨릴 수 있습니다. 둘째, 새 RPC 메서드 추가는 gossipsub 작업 위에 RPC가 얹혀 네트워크·연산 부하만 늘릴 위험이 있고 이를 고치다 보면 결국 제안된 설계에 도달합니다. 셋째, gossipsub과 별개의 새 프로토콜은 장기적으로 탐구할 가치는 있지만 이 최적화를 위해서는 과한 변경이며 특히 하드포크 없이 배포하려는 목표와 맞지 않습니다.

역호환성과 피어 점수

역호환 문제는 없습니다. 노드는 기존과 같은 규칙으로 gossipsub 메시를 구성하고 가십을 주고받습니다. 최적화는 교환하는 양쪽 노드가 모두 확장을 지원할 때만 작동하고 한쪽이라도 지원하지 않으면 기존처럼 전체 gossipsub 메시지를 교환합니다. 제때 메시지를 주는 피어에 좋은 점수를 주고 잘못된 메시지를 주는 피어를 감점하는 gossipsub의 피어 점수 체계도 바뀌지 않으며 확장 유무와 무관하게 같은 방식으로 동작해야 합니다.

보안 고려사항과 구현 함정

기본 설정에서는 표준 gossipsub의 푸시 동작보다 셀 전파에 약간의 지연이 더해지는 대신 대역폭 효율을 얻습니다. 시간이 지나면서 eager 셀 푸시 정책을 다듬어 전파 지연을 기존 수준으로 맞추거나 개선할 수 있으며 이 지연은 롤아웃 중과 이후에 모니터링되는 핵심 지표입니다. 구현상 주의점은 세 가지입니다. 확장을 지원하는 피어와 메시를 맺는 쪽이 효율적이더라도 이를 우대하면 네트워크가 갈라질 위험이 있으므로 미지원 피어를 차별해서는 안 됩니다(SHOULD NOT). 피어 점수는 Partial Messages 지원 여부와 무관하게 대체로 같아야 하고 셀을 하나씩 주는 피어가 한 번에 주는 피어보다 높은 점수를 받아서는 안 됩니다. 또 서로 다른 Group ID로 메시지를 뿌리는 스팸에 견딜 수 있어야 하며 적대적인 비메시 피어에 대비해 메시 피어 메시지용 공간을 예약해야 합니다(SHOULD). 배포는 점진적으로 진행되며 필요하면 되돌릴 수 있습니다.

진행 상태

이 EIP는 Last Call 상태이며 last-call-deadline은 2026-11-01입니다. 하드포크가 필요 없는 네트워킹 최적화라서 포크 일정과 무관하게 클라이언트별로 배포할 수 있습니다. 2026년 8월 10일 ACDT #91 콜에서 논의됐으나 별도 결정은 없었습니다.

EIP 원문 · ← EIPs