EIP-8371 RowDAS, 분산 블롭 재구성 (RowDAS - Distributed Blob Reconstruction)
Hegota 포함 제외 (DFI) · 확장성·데이터 · 원문 상태 Draft · 2026-08-05 작성
PeerDAS에서 슈퍼노드에 몰리던 블롭 재구성 작업을 행(row) 단위 가십 토픽으로 네트워크 전체에 나눕니다. 모든 노드가 재구성에 참여해 슈퍼노드 부담을 크게 줄이고 슈퍼노드 없이도 복구할 수 있는 경로를 만듭니다.
왜 필요한가
PeerDAS(EIP-7594)는 블록에 실린 블롭(blob) 데이터를 소거 부호(erasure coding)로 늘려 128개 열(column)로 나누고 그중 절반인 64개 이상을 받은 노드가 전체를 되살리도록 설계됐습니다. 이 재구성은 사실상 128개 열을 모두 구독하는 슈퍼노드가 맡습니다. 블롭 수가 늘면 슈퍼노드 한 대가 떠안는 재구성 부담도 그만큼 늘어납니다. 게다가 슈퍼노드들은 같은 일을 겹쳐서 합니다. 각자 빠진 블롭을 전부 되살리고 이 일을 네트워크 안에서 나눌 방법이 없습니다. 원문은 슈퍼노드 의존이 집중 지점이기도 해서 네트워크 복원력이 바람직한 수준에 못 미친다고 봅니다. RowDAS는 노드마다 블롭 공간의 다른 부분을 우선 되살리게 해서 더 빠르고 CPU를 덜 쓰고 더 튼튼한 구조를 만들려는 제안입니다.
무엇이 바뀌나
지금
- 재구성은 128개 열을 모두 구독하는 슈퍼노드가 맡고 블롭 수가 늘수록 부담이 그만큼 늘어납니다
- 슈퍼노드마다 빠진 블롭을 전부 따로 되살려 같은 일을 겹쳐서 합니다
- 열을 절반 이상 가진 노드만 되살릴 수 있어 슈퍼노드 의존이 집중 지점이 됩니다
EIP-8371 이후
- 행(row) 토픽으로 재구성 작업을 네트워크 전체에 나누어 슈퍼노드 부담을 줄입니다
- 노드마다 지정된 행을 먼저 되살리고 다른 곳에서 완성된 행은 작업을 취소합니다
- 일반 노드들이 행 토픽에서 셀을 모아 되살릴 수 있어 슈퍼노드 없이도 복구 경로가 생깁니다
누구에게 영향이 있나
- 슈퍼노드 운영자: 1단계에서는 자기 행 서브넷에 배정된 행만 되살리고 2단계 전체 재구성은 권장(SHOULD) 사항으로 바뀝니다. 다른 곳에서 완성된 행은 건너뛰어 CPU와 대역폭 부담이 줄어듭니다.
- 클라이언트 팀: 새 가십 토픽 data_row_{subnet_id}, 셀 단위 델타(EIP-8136) 지원, 단계별 재구성 타이머, 노드 ID로 같은 행 서브넷 피어를 찾는 탐색 로직을 구현해야 합니다. 정확한 전송 형식은 consensus-specs에서 따로 정합니다.
- 검증자·일반 노드 운영자: 셀 단위 델타를 지원하면 행 서브넷 하나를 구독하도록 권장되며 보관 의무는 없습니다. 64개 이상 커스터디 그룹을 가진 스테이킹 노드는 행 재구성자가 되어 1단계 재구성 의무가 생깁니다.
- L2(롤업) 노드: 개별 블롭을 바로 가져오는 기능은 포함되지 않지만 슈퍼노드를 더 적은 자원으로 운영할 수 있습니다. 슬롯과 블롭 인덱스로 행 서브넷을 계산할 수 있어 향후 블롭 검색 확장의 기반이 됩니다.
심층 설명
용어 정의와 상수
원문은 두 역할을 구분합니다. 슈퍼노드(supernode)는 128개 열 서브넷을 모두 구독하는 노드입니다. 행 재구성자(row reconstructor)는 128개 열 서브넷 가운데 64개 이상을 구독해 어떤 행이든 혼자 되살릴 수 있는 노드이며 모든 슈퍼노드는 행 재구성자이기도 합니다. 메인넷에서는 검증자 커스터디 요건이 64개 이상 커스터디 그룹에 이르는 스테이킹 노드가 행 재구성자에 포함됩니다. 새로 정의하는 상수는 ROW_SUBNET_COUNT = 128 하나입니다. 이 값은 최대 블롭 수와 무관한 고정 상수입니다. 원문은 이 EIP가 새 가십섭 토픽, 재구성 규칙 변경, 기존 열 토픽 동작의 소폭 변경으로 이루어진다고 요약합니다.
열 토픽의 fanout 확장
EIP-7594는 재구성으로 얻은 열을 네트워크에서 받은 것처럼 노출하도록 이미 규정합니다. 구독 중인 서브넷이면 재구성한 DataColumnSidecar를 토픽 메시 이웃에 보내야 하고(MUST) 구독하지 않는 서브넷이면 가십 송출 과정에서 가용성을 알려야 합니다(SHOULD). 이 EIP는 셀 단위 동작을 지원하는 피어를 상대로 두 규칙을 덧붙입니다. 첫째, 재구성 전에 가십섭 fanout으로 받은 광고를 이용해 구독하지 않는 열 서브넷의 피어에게서 필요한 셀을 모을 수 있습니다(MAY). 둘째, 재구성 후에는 fanout으로 구독하지 않는 열 서브넷의 피어에게 되살린 셀을 제공해야 합니다(SHOULD). 모든 열이 아니라 무작위로 고른 일부 열에만 광고할 수 있고 해당 열 토픽 구독자와 경쟁하지 않도록 fanout 메시지를 늦출 수도 있습니다.
행 서브넷과 두 가지 매핑 함수
새 토픽 이름은 data_row_{subnet_id}이며 폐기된 blob_sidecar_{subnet_id}와는 다릅니다. 행 서브넷은 eager push 없는 셀 단위 델타(EIP-8136)를 반드시 쓰고 GroupID는 열 서브넷과 마찬가지로 블록 루트입니다. 블롭을 서브넷에 배정하는 함수 get_blob_row_subnet(blob_index, slot)은 hash(b"ROW_SUBNET" + uint_to_bytes(uint64(slot)))을 시드로 compute_shuffled_index를 적용한 슬롯별 의사 무작위 순열입니다. 블롭 수가 ROW_SUBNET_COUNT 이하면 한 슬롯의 블롭들은 서로 다른 서브넷을 받고, 초과하면 ROW_SUBNET_COUNT로 나눈 나머지가 같은 블롭이 한 서브넷을 공유해 서브넷당 최대 ceil(blob_count / ROW_SUBNET_COUNT)개 행을 나릅니다. 시드가 슬롯에만 의존하므로 체인 상태 없이 계산할 수 있습니다. 노드의 지정 행 서브넷은 get_row_subnet(node_id)로 정하며, hash(uint_to_bytes(uint256(node_id)))의 [8:16] 바이트를 ROW_SUBNET_COUNT로 나눈 나머지입니다. 커스터디 그룹 유도가 같은 해시의 [0:8]을 쓰므로 추가 해시 비용 없이 두 배정이 서로 독립됩니다. 행 재구성자는 지정 행 서브넷을 반드시 구독하고(MUST) 다른 노드는 셀 단위 델타를 지원할 때 구독하는 것이 권장됩니다(SHOULD). 구독해도 보관 의무는 없습니다.
행 서브넷 운영 규칙: 부분 메시지, 피어 탐색, 검증
행 서브넷은 부분 메시지만 나르며 전체 메시지 형태는 정의하지 않습니다. Partial Messages Extension을 지원하지 않는 노드는 행 서브넷을 구독해서는 안 되고(MUST NOT) 확장을 지원하지 않는 메시 피어는 잘라낼 수 있습니다(MAY). EIP-8136의 비차별 지침은 전체 메시지 대체 경로가 있는 열 토픽에 적용되며 미지원 노드에게는 열 토픽과 getBlobs가 그대로 열려 있습니다. 행 서브넷 소속은 노드 ID만으로 계산되므로 ENR 확장이 필요 없습니다. 노드는 discv5 조회 등으로 찾은 노드 ID에 get_row_subnet을 적용해 같은 서브넷 피어를 찾고 건강한 메시를 유지할 만큼 연결을 확보해야 합니다(SHOULD). 서브넷 구성원은 전체 노드의 약 1 / ROW_SUBNET_COUNT에 불과해 무작위 피어 중에는 충분히 나타나지 않기 때문입니다. SSZ 컨테이너, 비트맵 인코딩, GroupID 유도는 ethereum/consensus-specs에서 EIP-8136 방식을 따라 정의합니다. 비트맵은 서브넷에 배정된 행을 blob_index 순서로, 행 안에서는 cell_index 순서로 덮습니다. 행 서브넷에서 받은 셀은 해당 블롭의 KZG 약정으로 검증한 뒤에만 전달하거나 써야 하고(MUST) 잘못된 셀을 준 피어는 열 서브넷과 같은 규칙으로 벌점을 받습니다. 피어는 배정된 각 행의 셀을 절반만 제공하도록 제한할 수 있으며(MAY) 이 제한은 행 단위로 적용됩니다. 어떤 경로로든 셀을 받으면 갱신된 비트맵을 피어에게 보내야 하고(SHOULD) 디바운스할 수 있습니다.
3단계 재구성과 타이머 규칙
모든 재구성 의무는 그 행의 서로 다른 검증된 셀을 64개 이상 가진 경우에만 발생합니다. 구독만으로는 보유로 치지 않습니다. 행 재구성자가 아닌 노드도 지정 행 서브넷의 각 행에서 셀을 64개 이상 모아 비트맵으로 알리는 것이 권장됩니다(SHOULD). 행 서브넷이 구성원들의 커스터디 셀을 모으므로 자기 커스터디가 아니어도 됩니다. 1단계: 행 재구성자는 지정 행 서브넷에 배정된 행 가운데 셀이 충분한 행을 반드시 되살리고(MUST) 비트맵을 갱신합니다. 자기 열 구독만으로 가능하며 짧은 무작위 지연(권장 범위 TBD)으로 노드 간 동시 실행을 피합니다. 2단계: 조금 더 긴 무작위 지연(TBD) 동안 getBlobs, 열, 행에서 셀을 모은 뒤, 슈퍼노드는 빠진 행을 모두 되살려야 하고(SHOULD) 다른 행 재구성자는 해도 됩니다(MAY). 모든 열 서브넷을 구독하는 슈퍼노드만 다른 곳에서 완성되는 행을 보고 중복 작업을 취소할 수 있기 때문입니다. 3단계: 2단계보다 긴 지연(TBD) 뒤, 행 서브넷에 가입한 어떤 노드든 아직 미완성인 행을 되살려야 합니다(SHOULD). 앞 단계가 실패했을 때만 작동해 기대 CPU 비용은 0에 가깝습니다. 모든 지연은 그 슬롯의 유효한 블록 루트를 처음 얻은 시점부터 재고, 의무는 슬롯당 블록 루트 하나(현재 헤드 분기 또는 처음 본 유효 블록 루트)에만 붙습니다. 같은 슬롯의 다른 블록 루트는 선택 사항(OPTIONAL)이라 이중 제안으로 작업을 부풀릴 수 없습니다. 다른 경로로 먼저 완성된 행은 대기 중인 재구성을 반드시 취소하고(MUST) 지연에는 최대값(TBD)을 두어 복구가 무한정 미뤄지지 않게 합니다.
설계 결정: 왜 고정 128개 서브넷에 슬롯별 순열인가
서브넷 수를 최대 블롭 수에 묶지 않은 이유는 Blob Parameter Only 포크 때마다 모든 노드의 서브넷 배정이 바뀌어 행 메시가 한꺼번에 무너졌다 다시 짜이는 것을 피하기 위해서입니다. 고정 상수면 노드와 서브넷의 배정이 포크를 넘어 안정되고 블롭 수는 슬롯별 블롭 매핑에만 영향을 줍니다. 128이라는 값은 서브넷당 기대 노드 수를 건강한 범위에 두기 위한 선택입니다. 2026년 8월 기준 메인넷에는 약 12K 노드가 있고 그중 약 2K가 슈퍼노드, 약 500이 64~127개 열을 보관해 행 재구성자는 약 2.5K입니다. ROW_SUBNET_COUNT = 128이면 전원 참여 시 서브넷당 약 94개 노드, 약 20개 행 재구성자가 됩니다. 이 값은 현재 계획된 최대 블롭 수보다 크므로 실제로는 서브넷당 슬롯마다 행 하나를 나르며 그보다 많아도 노드당 부하는 ceil(blob_count / ROW_SUBNET_COUNT)로 묶입니다. 단순 회전((blob_index + slot) % ROW_SUBNET_COUNT) 대신 슬롯별 의사 무작위 순열을 쓰는 이유는 회전이 한 서브넷을 blob_count개 슬롯 동안 연속으로 바쁘게 했다가 길게 쉬게 해 부하가 몰리기 때문입니다. 순열을 쓰면 한 슬롯의 두 블롭이 같은 서브넷에 겹치지 않고 compute_shuffled_index는 클라이언트가 이미 구현한 함수입니다. 매핑이 공개돼도 블록 빌더가 블롭 인덱스를 정하므로 숨겨서 얻는 이득은 거의 없고 표적 억제에 대한 보장은 열 토픽이 계속 맡습니다. 원문은 이 EIP가 FullDAS가 아니며 셀 단위 하위 선형 샘플링, 열 방향 인코딩, L2의 개별 블롭 검색은 포함하지 않는다고 못 박습니다.
보안 고려 사항
이 EIP는 DAS 네트워킹을 바꾸지만 PeerDAS의 커스터디 배정과 확률적 보장은 그대로 둡니다. 행 배포는 추가 복구 경로이고 기존 경로는 거의 그대로여서 추가 비용은 비트맵 신호와, 데이터가 일부 숨겨졌을 때 행 서브넷 구성원당 배정된 행마다 최대 반 행 분량의 헛된 셀 요청으로 한정됩니다. 모든 재구성 의무가 검증된 셀 64개 보유를 조건으로 하므로 가용하지 않은 데이터로 재구성 CPU를 유발할 수 없습니다. 예외는 2단계 전체 재구성을 일부러 늦추는 점인데, 구현체들이 이미 하는 관행이고 홉마다가 아닌 한 번의 지연입니다. 블록 생산자가 한 행에서 셀 하나만 빼고 나머지 행에 64개 열 분량을 풀어 결국 가용하지 않을 블록에 복구 작업을 일으키는 공격은 PeerDAS에서 물려받은 것입니다. PeerDAS에서는 모든 슈퍼노드가 이 작업을 중복하지만 여기서는 1단계가 행 재구성자당 약 한 행으로 나누고 2단계가 완성된 행을 건너뛰어 총 작업량이 줄어듭니다. 슈퍼노드는 모든 열의 비트맵을 보고 복구 불가능한 행을 알아채 그 블록의 작업을 건너뛸 수 있습니다. 행 배포는 최적화일 뿐이므로 노드는 행 서브넷 상태에 따라 샘플링이나 가용성 판정 규칙을 바꾸거나 판정을 늦춰서는 안 되며(MUST NOT) 열 토픽과 요청 응답이 권위 있는 경로로 남습니다. 비트맵을 셀마다 보내면 메시지 복잡도가 제곱으로 늘 수 있어 디바운스, 속도 제한, 피어당 추적 GroupID 수 제한이 권장됩니다. 광고한 셀을 반복해서 주지 않는 피어는 지연 메시지를 보내는 피어처럼 피어 점수에서 다룹니다. 행 서브넷 배정은 노드 ID의 공개 함수라 노드 ID를 갈아 특정 서브넷을 장악하거나 고립시킬 수 있지만 2단계 재구성과 열 토픽이 해당 행을 덮으므로 영향은 현 상태로 후퇴하는 데 그칩니다.
호환성, 현재 상태, 포크 논의
행 토픽은 셀 단위 델타를 지원하는 libp2p 가십섭 구현을 가진 피어로 한정됩니다. 원문은 글램스테르담(Glamsterdam) 이전에도 메인넷에서 지원 피어 비율이 상당하고 글램스테르담 포크와 EIP-8136 이후에는 대다수가 지원할 것으로 봅니다. 미지원 피어에게는 getBlobs와 열 토픽이 그대로 열려 있습니다. 각 단계의 권장 지연 범위, 지연 최대값, 전송 형식은 아직 TBD입니다. 이 EIP는 상태가 Draft라 명세가 더 바뀔 수 있습니다. 포크 논의로는 08.06 ACDC #184에서 EIP-8371(RowDAS)이 헤고타(Hegota) 후보(PFI)로 접수됐고 PeerDAS 재구성 부하를 로우 토픽으로 분산한다는 취지였습니다. 이후 10.15 ACDC #189에서 헤고타 후보에서 제외(DFI)됐습니다. 클라이언트 지지가 낮고 현재 블롭 수요가 적어 급하지 않다고 본 것입니다.