EIP-7934: 이더리움을 더 안전하고 예측 가능하게 만드는 RLP 블록 크기 제한
Source: Dev.to
위 링크에 포함된 전체 글을 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)
이더리움이 바이트‑크기 제한이 필요했던 이유
Fusaka 이전에 이더리움은 블록 가스 한도에만 의존했습니다. 가스는 연산량을 측정하지만 바이트 크기와는 밀접하게 연관되지 않습니다. 악의적인 블록은 다음과 같은 내용을 담을 수 있습니다:
- 거대한 calldata를 가진 저가스 트랜잭션 다수
- 큰 영수증을 생성하는 저비용 연산
- 과도하게 큰 RLP 구조
이 모든 것이 가스 규칙상 “유효”하기 때문에 실제 문제를 일으킵니다:
- 전파 지연 → 일시적 포크 – 가십 네트워크는 10 MiB 초과 블록을 버립니다.
- 과다 블록 DoS – 큰 RLP 페이로드는 디코딩에 많은 CPU를 요구합니다.
- 무제한 하드웨어 요구사항 – 블록이 커질수록 전체 노드에 필요한 최소 대역폭과 CPU가 증가합니다.
EIP‑7934는 예측 가능한 상한을 강제해 EL과 CL이 일관되게 동작하도록 합니다.
제안: 10 MiB 하드 캡 (2 MiB 마진 포함)
정의된 상수
| Constant | Value (bytes) | Purpose |
|---|---|---|
MAX_BLOCK_SIZE | 10 485 760 | CL 가십 하드 제한 |
SAFETY_MARGIN | 2 097 152 | 비콘 블록 헤더를 위해 예약 |
MAX_RLP_BLOCK_SIZE | 8 388 608 | 최대 RLP 실행 페이로드 |
블록 검증 규칙
# Reject blocks whose RLP‑encoded size exceeds the limit
if len(rlp.encode(block)) > MAX_RLP_BLOCK_SIZE:
reject_the_block()
이 규칙이 적용되는 위치
- 블록 생성 – 빌더는 RLP 크기가 제한 내에 있는지 확인해야 합니다.
- 블록 검증 – 클라이언트는 초과 크기 블록을 거부합니다.
- 가십 – CL은 10 MiB 초과 블록을 절대 전파하지 않습니다.
- RPC – 초과 크기 블록은 API를 통해 제출될 수 없습니다.
시각적 분해: 10 MiB 제한이 작동하는 방식
- MAX_BLOCK_SIZE: 전체 블록 크기 10 MiB.
- SAFETY_MARGIN: 비콘 블록 헤더를 위해 예약된 2 MiB.
- MAX_RLP_BLOCK_SIZE: 실행 페이로드에 사용할 수 있는 8 MiB.
이 할당은 CL 가십 규칙과 정확히 일치하며 EL > CL 불일치를 방지합니다.
왜 10 MiB인가? 근거
- 합의 레이어는 이미 10 MiB의 하드 제한을 적용하고 있습니다.
- 현재 이더리움 블록은 약 1–2 MiB로, 충분한 여유 공간이 있습니다.
- 미래 처리량은 안전하고 결정론적인 경계에 달려 있습니다.
- 단순하고 결정론적인 상한선은 구현 및 감시가 더 쉽습니다.
프로토콜 변경 및 개발자 영향
클라이언트 구현자
- 블록 생성, 가져오기 파이프라인, 가십 검증 및 RPC API에 RLP 바이트‑크기 검사를 통합합니다.
- 테스트 픽스처 추가 (Fusaka 사양 테스트에 포함).
롤업 / L2 개발자
- calldata‑무거운 트랜잭션을 배치할 때, 큰 번들은 8 MiB RLP 제한을 초과할 수 있습니다.
- 압축, 청크화 또는 병렬 제출을 고려하세요.
- 증명/영수증 크기도 전체 바이트 수에 포함됩니다.
- 가스만이 아니라 물리적 블록 제약을 기준으로 설계합니다.
노드 운영자
- 추가 설정이 필요하지 않습니다.
- 혜택: 전파 속도 향상, 우발적인 리오그 감소, 부하가 걸린 상황에서도 더 안전한 네트워크.
보안 영향
- 과도한 블록 DoS 완화 – 노드가 RLP 제한을 초과하는 블록을 디코딩하려 시도하지 않습니다.
- CPU 소모 감소 – 상한선이 검증 시간을 예측 가능하게 합니다.
- 네트워크 단편화 제거 – EL과 CL이 이제 허용 가능한 블록 크기에 대해 일치합니다.
- 전파 변동성 감소 – 보다 안정적인 합의를 제공합니다.
트레이드‑오프 및 고려된 대안
| 대안 | 거절 사유 |
|---|---|
| 가스 기반 동적 크기 조정 | 가스는 바이트 크기의 강력한 예측 변수가 아닙니다. |
| 제한을 20–30 MiB로 상향 | 탈중앙화와 홈 스테이커에 해를 끼칩니다. |
| 소프트 제한(경고만) | 여전히 전파 지연을 초래합니다. |
요약
10 MiB 하드 캡은 모든 클라이언트 팀에서 구현하기 가장 안전하고 쉬운 방법입니다. 이는 향후 처리량 업그레이드를 위한 명확한 가드레일을 제공합니다.
EIP‑7934가 Fusaka에 어떻게 적용되는가
Fusaka는 인프라에 초점을 맞춘 업그레이드로, 이더리움을 L2 확장의 다음 단계에 대비하도록 준비합니다. EIP‑7934는 증가된 블록 가스 한도(EIP‑7935 → 60 M)와 기타 처리량 개선이 네트워크를 불안정하게 만들지 않도록 보장합니다.
관련 EIPs
- EIP‑7935 – 블록 가스 한도를 60 M으로 증가시킵니다.
- EIP‑7825 – 트랜잭션당 가스 상한.
- EIP‑7892 – 블롭 데이터 가용성 개선.
Developer Takeaways (Quick Reference)
- 블록당 최대 실행 RLP 페이로드: 8 MiB
- 최대 EL + CL 블록 크기: 10 MiB
- 칼ldata 배치가 6–7 MiB에 근접하면 청크 처리가 필요합니다.
- 가스 ≠ 바이트 – 두 요소를 모두 고려해 설계하세요.
- 노드 클라이언트가 이제 초과 크기 블록을 조기에 거부하여 향후 업그레이드 시 전파 안전성을 향상시킵니다.
결론
EIP‑7934는 사용자 인터페이스(UX) 기능이 아니라, 롤업 및 데이터 가용성 솔루션에 대한 수요가 지속적으로 증가함에 따라 이더리움을 안정화시키는 구조적 업그레이드입니다. 엄격한 바이트‑크기 상한을 적용함으로써 이더리움은 다음과 같은 이점을 얻습니다:
- 예측 가능한 블록 검증 시간
- 감소된 DoS 공격 표면
- 일관된 EL – CL 동작
- 낮은 전파 변동성
- 보다 안전한 가스‑limit 증가
경계값은 작아 보일 수 있지만, 이더리움의 장기적인 확장성을 위해 필수적입니다.