EIP-7691 블롭 처리량 증가 (Blob throughput increase)
최종 확정 · 확장성·데이터 · 원문 상태 Final · 2024-04-17 작성
블록당 블롭 개수를 목표 3개·최대 6개에서 목표 6개·최대 9개로 늘립니다. L2가 쓰는 L1 데이터 공간을 두 배로 키워 단기적으로 이더리움의 확장성을 높입니다.
왜 필요한가
이더리움은 롤업 중심 로드맵에 따라 L2에 확장을 맡기고 L2는 데이터를 L1의 블롭(blob)이라는 전용 공간에 올립니다. 덴쿤(Dencun) 포크에서 블롭 개수는 목표 3개, 최대 6개로 정해졌는데, 당시에는 메인넷의 P2P 네트워크가 어떻게 반응할지 예측하기 어려워 보수적으로 잡은 값이었습니다. 덴쿤이 가동된 뒤 모니터링 결과 네트워크는 안정적이었고 리오그(re-org, 블록이 뒤집히는 일) 비율도 줄어드는 추세였습니다. 또 노드 사이 메시지 전파 분석에서 IDONTWANT 메시지를 도입하면 대역폭을 크게 아낄 수 있다는 점도 확인됐습니다. 즉 네트워크에 여유가 생겼다는 근거가 쌓였고 피어다스(peerDAS) 같은 본격적인 확장 기술이 나오기 전까지 블롭 개수를 올려 당장의 수요를 받아내자는 것이 이 제안입니다.
무엇이 바뀌나
지금
- 블록당 블롭 목표 3개, 최대 6개 (덴쿤 포크 기준)
- 목표와 최대가 1:2 비율이라 블롭 수수료가 오르고 내리는 반응이 대칭적
- L2가 쓸 수 있는 L1 데이터 공간이 상대적으로 작음
EIP-7691 이후
- 블록당 블롭 목표 6개, 최대 9개로 두 배 수준 확대
- 목표와 최대가 2:3 비율이 되고, 수수료 갱신 분수를 새로 정해 반응 속도를 보정
- 피어다스 등 장기 확장 기술이 나오기 전까지 L2 데이터 공간에 숨통
누구에게 영향이 있나
- L2(롤업): L1에 올릴 수 있는 블롭 공간이 두 배 수준으로 늘어 데이터 게시 비용 부담이 줄어들 여지가 생깁니다.
- 클라이언트 팀: 합의 계층과 실행 계층 모두 상수 값만 교체하면 되는 작은 변경이라 구현·테스트 부담이 적습니다.
- 검증자·솔로 스테이커: 블록이 커지면서 대역폭 부담이 늘 수 있습니다. 원문은 로컬 빌드 블록의 최대 블롭 수를 제한하는 플래그 같은 보완책을 검토할 수 있다고 적습니다.
- 사용자: L2 수수료의 재료가 되는 L1 데이터 비용이 수급에 따라 달라지므로 간접적으로 영향을 받습니다.
심층 설명
새 파라미터
합의 계층용으로 MAX_BLOBS_PER_BLOCK_ELECTRA = 9, TARGET_BLOBS_PER_BLOCK_ELECTRA = 6을 정의합니다. 실행 계층용으로는 MAX_BLOB_GAS_PER_BLOCK = 1179648, TARGET_BLOB_GAS_PER_BLOCK = 786432, BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE = 5007716을 정의합니다. 합의 계층 값은 PECTRA_FORK_EPOCH부터 기존 최대·목표 값을 대체하고 실행 계층 값은 이 EIP가 활성화되는 에폭부터 기존 최대·목표·갱신 분수를 대체합니다.
EIP-4844 함수와의 연결
EIP-4844에 있는 MAX_BLOB_GAS_PER_BLOCK과 TARGET_BLOB_GAS_PER_BLOCK 참조는 활성화 블록을 처리할 때부터 이 EIP의 새 값으로 바뀝니다. BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE도 활성화 블록부터 기존 값을 대체합니다. 그 결과 EIP-4844에 정의된 get_base_fee_per_blob_gas와 calc_excess_blob_gas 함수는 포크의 첫 블록부터 새 값으로 동작합니다.
갱신 분수를 다시 정한 이유
EIP-4844의 목표:최대는 1:2라 수수료 반응이 대칭적이었습니다. 블롭이 가득 차면 베이스피가 약 12.5% 오르고 비면 약 11.1% 내렸습니다. 이 EIP의 2:3 비율은 그 대칭을 깹니다. 목표 아래로는 최대 6개까지 빌 수 있지만 목표 위로는 3개까지만 찰 수 있어 빈 구간에 더 크게 반응하게 됩니다. 빈 블록 하나를 만회하려면 가득 찬 블록 두 개가 연속으로 필요하므로 이는 의도된 설계지만 적절한 민감도 수준을 찾아야 하는 과제가 생깁니다. BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE = 5007716은 가득 찬 쪽 반응을 유지하는 안과 빈 쪽 반응을 유지하는 안의 중간값으로 골랐습니다. 결과는 가득 찬 블록에서 약 +8.2%, 빈 블록에서 약 -14.5%입니다.
단순성을 택한 설계
이 EIP는 클라이언트 팀의 테스트와 구현 부담을 최소화하는 것을 목표로 합니다. 상수 교체 수준의 작은 변경으로 묶어 두면, 팀들이 피어다스(peerDAS)와 다른 확장 연구에 더 많은 자원을 쓸 수 있기 때문입니다. 원문은 이 값이 최적의 블롭 한도는 아닐 수 있지만 단기 증가를 위한 절충안이라고 명시합니다.
하위 호환과 포크 경계
합의 클라이언트는 데네브(deneb) 포크에서는 기존 MAX_BLOBS_PER_BLOCK과 TARGET_BLOBS_PER_BLOCK을 계속 쓰다가, ELECTRA 포크가 활성화되면 MAX_BLOBS_PER_BLOCK_ELECTRA와 TARGET_BLOBS_PER_BLOCK_ELECTRA로 전환합니다. 실행 클라이언트는 캔쿤(cancun) 포크에서는 기존 값과 BLOB_BASE_FEE_UPDATE_FRACTION을 쓰다가, 프라하(prague) 포크가 활성화되면 새 값과 BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE를 씁니다.
보안 고려 사항
메인넷과 테스트넷에서 큰 블록·블롭 테스트를 거치면 한도 증가가 네트워크에 악영향을 주지 않는다는 확신을 얻을 수 있고 이 테스트와 분석은 클라이언트 팀이 아닌 주체도 수행할 수 있어 팀 부담이 적습니다. 포크 전환 시점의 한도 증가는 구현 관점에서 비교적 단순하지만 포크 에폭 전후로 모니터링을 늘려야 하며 안정기가 지나면 증가가 성공했다고 볼 만합니다. 한편 솔로 스테이커 우려에 대해서는, 로컬에서 빌드하는 블록의 최대 블롭 수를 지정하는 플래그 도입 같은 접근을 검토할 수 있다고 적습니다. 이 EIP는 Final 상태로 확정된 명세입니다.