EIP-7892 블롭 파라미터 전용 하드포크 (Blob Parameter Only Hardforks)
최종 확정 · 확장성·데이터 · 원문 상태 Final · 2025-02-28 작성
블롭 용량을 정하는 세 가지 숫자(target, max, baseFeeUpdateFraction)만 설정 파일로 바꾸는 경량 하드포크(BPO 포크)를 정의합니다. 클라이언트 코드 수정 없이 블롭 용량을 자주, 조금씩 올릴 수 있게 됩니다.
왜 필요한가
이더리움은 거래 실행을 레이어 2(L2)에 맡기고 본체는 L2가 올리는 데이터를 보관하는 데이터 가용성(Data Availability) 층 역할을 합니다. L2가 빠르게 성장하면서 이 데이터 공간, 즉 블롭(blob) 수요도 계속 늘어 용량이 포화되고 있습니다. 그런데 지금은 블롭 용량을 늘리려면 크고 드문 정규 하드포크를 기다려야 합니다. 정규 하드포크는 클라이언트 전반의 조율, 테스트, 업그레이드 작업이 커서 L2 성장 속도를 따라가기 어렵습니다. 또 큰 확장 기술이 새로 들어오면 적정 블롭 한도를 미리 알기 어려워 개발자들이 안정성과 용량 사이에서 어중간한 값을 골라야 하는 문제도 있습니다. 이 EIP는 블롭 관련 숫자만 바꾸는 작은 전용 포크를 정의해 메인넷 성능과 안정성을 지켜본 뒤 필요할 때 빠르고 안전하게 용량을 올릴 수 있게 합니다. 롤업 입장에서는 이더리움이 계속 확장된다는 예측 가능성이 생깁니다.
무엇이 바뀌나
지금
- 블롭 용량을 바꾸려면 크고 드문 정규 하드포크를 기다려야 합니다
- 포크마다 클라이언트 코드 수정과 긴 조율, 테스트가 필요합니다
- 새 확장 기술 도입 직후에는 안정성 때문에 보수적인 한도를 골라야 합니다
EIP-7892 이후
- 블롭 파라미터만 바꾸는 BPO 포크를 설정 파일만으로 예약하고 활성화합니다
- 코드 변경 없이 지정한 활성 시각에 새 파라미터가 바로 적용됩니다
- 메인넷 상태를 관찰한 뒤 용량을 단계적으로 올릴 수 있습니다
누구에게 영향이 있나
- L2·롤업: 블롭 용량이 계속 늘어난다는 예측 가능성이 생겨 다른 데이터 가용성 솔루션 대신 이더리움을 선택할 근거가 됩니다.
- 클라이언트 팀: 포크마다 쓰던 대량의 준비 코드(보일러플레이트) 없이 설정 항목 추가만으로 블롭 파라미터를 바꿀 수 있습니다.
- 노드 운영자·검증자: 실행 계층과 합의 계층의 BPO 포크 일정이 일치하도록 설정을 갱신하고 포크 시각에 맞춰야 합니다.
- 테스트 팀: 파라미터가 설정으로 분리되어 클라이언트 구현자의 개입을 최소화한 채 여러 값을 실험할 수 있습니다.
심층 설명
BPO 포크의 정의
BPO 하드포크는 클라이언트 코드 변경 없이 설정만으로 블롭 관련 파라미터를 바꾸는 프로토콜 업그레이드입니다. 대상 파라미터는 블록당 기대 블롭 수인 target, 블록당 최대 블롭 수인 max, 블롭 가스 가격 조정 속도를 정하는 baseFeeUpdateFraction 세 가지입니다. 새 파라미터는 지정한 활성 시각에 즉시 효력을 갖습니다. 일관성을 위해 정규 하드포크가 이 파라미터들을 바꿀 때도 반드시(MUST) 블롭 스케줄 설정에 항목을 추가하는 방식으로 바꿔야 합니다.
실행 계층 설정: blobSchedule과 활성 시각
EIP-7840이 정의한 blobSchedule 객체의 각 포크를 최상위 <fork_name>Time 필드와 연결합니다. 이 필드는 활성 슬롯의 Unix 타임스탬프를 JSON 숫자로 담습니다. BPO 포크 이름은 bpo1, bpo2처럼 bpo<index> 규칙을 따르며(SHOULD) index는 1부터 시작하고 사전순 정렬 대상이 아니므로 왼쪽 0 채움은 필요 없습니다. 활성 타임스탬프는 Prague 이후 포크에만 필요하고, 백포팅이 없으므로 cancunTime과 pragueTime은 0으로 둡니다. 원문 예시의 수치와 일정은 순전히 예시이며 실제 값은 이 명세의 범위 밖입니다.
블롭 베이스 수수료 계산 변경
EIP-4844의 get_base_fee_per_blob_gas와 calc_excess_blob_gas 함수가 블롭 스케줄(BlobSchedule: target, max, base_fee_update_fraction)을 명시적으로 인자로 받도록 바뀝니다. EIP-7691에서 BLOB_BASE_FEE_UPDATE_FRACTION을 갱신했던 방식과 같이, 두 함수는 현재 블록의 블롭 스케줄을 사용합니다. 상수 TARGET_BLOB_GAS_PER_BLOCK은 GAS_PER_BLOB * blob_schedule.target으로 대체되어 제거됩니다.
합의 계층 설정과 EL·CL 일치 요건
합의 계층 설정에 BLOB_SCHEDULE 필드가 새로 들어갑니다. ELECTRA_FORK_EPOCH 이후 블롭 파라미터가 바뀌는 포크마다 한 항목씩, EPOCH와 MAX_BLOBS_PER_BLOCK을 기록합니다. 정규 포크든 BPO 포크든 블롭 파라미터를 바꾸면 항목이 생깁니다. 요건은 세 가지입니다. 실행·합의 클라이언트는 일치하는 BPO 포크 일정을 공유해야 하고(MUST), 실행 계층 blobSchedule의 슬롯은 합의 계층 설정에 적힌 에포크의 시작과 정렬되어야 하며(MUST), 실행 계층의 max는 합의 계층의 MAX_BLOBS_PER_BLOCK과 같아야 합니다(MUST).
compute_fork_digest 수정
포크 다이제스트 계산 함수에 current_epoch와 blob_schedule 인자가 추가됩니다. 스케줄을 에포크 내림차순으로 정렬해 현재 에포크에 적용되는 항목을 찾고 그 max_blobs_per_block 값을 4바이트 big-endian으로 만들어 기존 4바이트 다이제스트와 XOR 마스킹합니다. 적용되는 항목이 없으면 기존 다이제스트를 그대로 반환하는데, 이 덕분에 파라미터 변경 없이 BPO 메커니즘만 먼저 배포할 수 있습니다. 이 다이제스트는 주로 p2p 계층의 도메인 분리에 쓰이며 4바이트면 포크와 체인을 실용적으로 구분하기에 충분합니다.
P2P 네트워킹: nfd 필드와 토픽 회전
합의 계층 ENR에 nfd(next fork digest) 항목이 추가됩니다. 값은 SSZ Bytes4 형식의 ForkDigest로, 정규 포크든 BPO 포크든 다음 예정 포크의 다이제스트를 알립니다. BPO 전용 파라미터를 싣는 대신 다이제스트를 쓰는 이유는 용도에 중립적이고 장기 유연성이 크기 때문입니다. 피어를 탐색할 때 노드는 기존 eth2 키의 ENRForkID::next_* 필드와 함께 nfd를 평가해야 합니다(MUST). Status 요청·응답은 바뀌지 않지만 응답에 갱신된 fork_digest가 들어가야 합니다. 가십 토픽 구조도 바뀌지 않지만 ForkDigestValue가 바뀌므로 BPO 포크 시점에 모든 토픽이 자동으로 회전합니다.
왜 정규 하드포크나 온체인 투표가 아닌가
정규 하드포크는 파라미터 조정을 넘어서는 광범위한 조율과 구현 변경이 필요합니다. 예를 들어 Lighthouse에서는 전형적인 하드포크 구현에 프로토콜 변경 전부터 수천 줄의 준비 코드가 들어갑니다. 파라미터를 코드가 아닌 노드 설정에 두면 클라이언트 구현자의 개입을 최소화한 채 빠른 실험과 조정이 가능합니다. 온체인 투표를 만들지 않은 이유로는 최근 가스 한도를 36M으로 올리는 데 1년 가까이 걸린 점, 블롭 용량이 빠르게 움직이는 목표라 스테이킹 커뮤니티가 추적할 준비가 안 된 점, 훨씬 많은 코드 변경과 거버넌스 논쟁이 필요한 점을 듭니다. BPO 포크는 더 단순하고 예측 가능한 방식이면서 블롭 용량이 안정되면 온체인 투표를 도입할 여지도 남깁니다. 이 EIP는 Final 상태의 Informational 문서입니다.