가스 한도만 보면 부족하다: EIP-7825와 EIP-7934로 보는 Ethereum 블록의 두 가지 안전 경계

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 블록 가스 한도를 올려도, 왜 개별 트랜잭션 가스와 RLP 바이트 크기를 따로 제한해야 할까?
• 핵심 출처:
  • EIP-7825: Transaction Gas Limit Cap - 생성일 2024-11-23, 확인일 2026-06-14
  • EIP-7934: RLP Execution Block Size Limit - 생성일 2025-04-16, 확인일 2026-06-14
  • Ethereum Foundation Blog - Fusaka Update: Transaction Gas Limit Cap arrives with EIP-7825 - 2025-10-21, 확인일 2026-06-14
  • Ethereum Foundation Blog - Fusaka Mainnet Announcement - 2025-11-06, 확인일 2026-06-14
  • ethereum/EIPs - EIP-7825 Empirical Report - 2025-07, 확인일 2026-06-14

1. 왜 지금 봐야 하나

Ethereum의 확장 논의는 자주 “블록 가스 한도를 더 올릴 수 있나?”로 압축된다. 하지만 Fusaka 계열 변경을 보면 프로토콜 팀이 실제로 다루는 질문은 조금 다르다. 처리량을 늘릴수록, 한 블록 안에서 최악의 트랜잭션 하나가 검증 시간·전파·메모리 사용을 얼마나 흔들 수 있는지를 먼저 제한해야 한다.

EIP-7825는 개별 트랜잭션이 사용할 수 있는 gas limit을 16,777,216, 즉 2^24 gas로 제한한다. Ethereum Foundation의 Fusaka 가스캡 공지는 이 제한이 전체 block gas limit을 낮추는 것이 아니라, 한 트랜잭션이 블록 대부분을 독점하지 못하게 만드는 장치라고 설명한다. 특히 배치 작업, 대형 배포 스크립트, 라우터, 트랜잭션 빌더는 Holesky·Sepolia 같은 테스트넷에서 새 한도를 확인하라고 권한다.

반면 EIP-7934는 gas가 아니라 RLP로 인코딩된 execution block의 바이트 크기를 제한한다. EIP는 consensus layer gossip이 10 MiB를 넘는 블록을 전파하지 못할 수 있다는 점을 문제로 잡고, 2 MiB safety margin을 제외한 MAX_RLP_BLOCK_SIZE를 기준으로 oversized block을 invalid 처리하자고 한다. 즉 “gas가 충분히 낮다”와 “네트워크가 블록을 안정적으로 전파할 수 있다”는 같은 말이 아니다.

최근 이 공부방의 blockchain_dev 글은 PeerDAS와 blob data availability, EIP-7928 block-level access list, FOCIL inclusion list, ZK Gateway settlement, Solana finality, ProxyAdmin 권한 사고를 다뤘다. 오늘은 그와 겹치지 않게 처리량을 올리기 전에 프로토콜이 최악값을 어떻게 잘라내는가에 집중한다.

2. 핵심 개념

오늘의 핵심 개념은 **자원 경계(resource boundary)**다. 블록체인에서 “비용을 gas로 계산한다”는 말은 맞지만, gas 하나가 모든 자원 위험을 완벽히 대표하지는 않는다.

첫 번째 경계는 트랜잭션 단위의 실행 경계다. EIP-7825 이전의 문제는 이론상 한 트랜잭션이 전체 block gas limit에 가까운 gas limit을 가질 수 있다는 점이다. 이런 트랜잭션은 블록 안의 다른 트랜잭션을 밀어내고, 검증자가 블록을 처리할 때 부하를 한 지점에 집중시킨다. 그래서 EIP-7825는 txpool validation 단계에서 gasLimit > 16,777,216인 트랜잭션을 거부하고, block validation 단계에서도 그런 트랜잭션이 들어간 블록을 invalid로 본다.

두 번째 경계는 블록 단위의 전파 경계다. EIP-7934는 len(rlp.encode(block))가 제한을 넘으면 블록을 만들거나 받아들이지 말라고 한다. 여기서 중요한 점은 이 제한이 gas와 독립적이라는 것이다. 어떤 데이터 구조는 gas로 보면 괜찮아 보여도 RLP byte size, receipt, access list, calldata 구성 때문에 전파 비용이 커질 수 있다. consensus layer가 전파하지 못하는 크기의 execution payload는 정상적인 합의 참여를 방해한다.

세 번째 경계는 미래 병렬 실행을 위한 예측 가능성이다. Ethereum Foundation 공지는 EIP-7825가 parallel execution을 준비하는 기반이라고 설명한다. 병렬 실행은 “스레드를 여러 개 쓰면 빠르다”가 아니라, 작업 단위를 나누고 worst-case skew를 줄일 수 있을 때 의미가 있다. 한 트랜잭션이 블록 대부분을 차지하면 병렬화할 작업 단위가 사라진다.

3. 최신 이슈와 연결

Fusaka Mainnet Announcement는 Fusaka가 PeerDAS, blob throughput, L1 execution capacity, secp256r1 precompile, CLZ opcode 같은 여러 변경을 포함한다고 정리한다. 그 안에서 EIP-7825와 EIP-7934는 눈에 덜 띄지만 개발자에게는 중요한 “안전 난간”이다.

EIP-7825 empirical report는 Q1 2025 기준 6개월 Ethereum mainnet 데이터에서 2^24 cap을 넘는 트랜잭션이 약 96,564건, 영향률 0.0383%였다고 보고한다. 또 CDF 분석에서는 16,777,216 gas 이하 트랜잭션이 99.96%라고 정리한다. 이 숫자는 “거의 아무도 영향이 없다”는 낙관만 뜻하지 않는다. 오히려 영향이 적은 지금 프로토콜 경계를 명시하면, 나중에 block gas limit을 올릴 때 최악 케이스를 더 안정적으로 다룰 수 있다는 뜻이다.

EIP-7934는 다른 실패 모드를 겨냥한다. 블록이 gas limit 안에 있어도 RLP 인코딩 크기가 너무 크면 consensus layer gossip의 전파 제약과 충돌할 수 있다. 이 경우 일부 노드는 블록을 보고 일부 노드는 못 보는 네트워크 fragmentation이 생기고, 일시적 fork나 reorg 위험이 커진다. 그래서 EIP-7934의 핵심은 throughput을 낮추는 것이 아니라, execution layer와 consensus layer가 같은 크기 현실을 보게 만드는 것이다.

4. 개발자 관점 해석

첫째, gas estimation은 유효성 검사가 아니다. 많은 앱은 eth_estimateGas 결과에 버퍼를 붙여 gas limit을 만든다. 하지만 EIP-7825 이후에는 “예상 gas가 충분한가?”와 별도로 “내가 설정한 gasLimit이 프로토콜 cap 이하인가?”를 검사해야 한다. 특히 배치 mint, 대량 claim, 포지션 정리, 멀티콜, migration script는 한 번에 끝내려는 습관이 cap과 충돌할 수 있다.

둘째, 배치 작업은 atomicity와 chunking 사이의 설계 문제가 된다. 한 트랜잭션에 1만 명의 업데이트를 몰아넣는 방식은 개발자에게 편하지만, 실패하면 전체가 revert되고 이제는 cap에도 걸릴 수 있다. 반대로 chunking을 하면 중간 상태, 재시도, idempotency, partial completion UI를 설계해야 한다. 프로토콜의 gas cap은 앱 개발자에게 “대형 작업을 상태 머신으로 나누라”는 압력으로 작동한다.

셋째, 블록 빌더와 노드 운영자는 gas와 byte size를 함께 모니터링해야 한다. EIP-7934는 block construction logic이 RLP size limit을 엄격히 지켜야 한다고 말한다. MEV bundle, private orderflow, 대형 calldata 트랜잭션, access list를 조합하는 환경에서는 “gas는 남았는데 byte limit에 가까운” 블록이 생길 수 있다. 이런 블록은 수익성이 높아 보여도 전파 실패와 orphan risk를 키운다.

넷째, 프론트엔드와 지갑은 실패 메시지를 더 구체적으로 보여줘야 한다. 사용자가 “out of gas”와 “gasLimit cap 초과”와 “블록 바이트 크기 제약으로 빌더가 포함하지 않음”을 모두 같은 실패로 보면 복구 행동을 못 한다. 적어도 개발자 도구와 내부 대시보드에서는 이 원인을 분리해야 한다.

5. 내 프로젝트에 적용할 체크포인트

• 트랜잭션 생성 코드에서 gasLimit > 16_777_216을 사전에 막는가?
• estimateGas * 1.2 같은 버퍼 로직이 cap을 넘을 때 자동으로 잘라내거나 경고하는가?
• contract deployment, batch operation, multicall, migration script의 최대 gas 사용량을 테스트넷에서 측정했는가?
• 한 번에 처리하던 작업을 여러 트랜잭션으로 나눌 때 idempotency key, cursor, checkpoint, retry policy가 있는가?
• 사용자가 partial completion 상태를 이해할 수 있게 UI와 고객지원 문구가 준비되어 있는가?
• 자체 builder, relayer, bundler, sequencer를 운영한다면 block gas usage와 함께 RLP encoded size를 기록하는가?
• 모니터링에서 tx rejected: gas limit cap, oversized payload, bundle too large, block propagation delay를 별도 이벤트로 분리하는가?
• 테스트 fixture에 “cap 바로 아래”, “cap 바로 위”, “여러 chunk 중 하나 실패”, “pre-signed tx gasLimit 초과” 케이스가 있는가?

6. 오늘 10분 액션

오늘은 내 저장소에서 대형 트랜잭션 경로 하나만 찾는다.

1. 코드베이스에서 multicall, batch, claimMany, airdrop, migrate, deploy, gasLimit, estimateGas를 검색한다.
2. 그중 한 경로를 골라 “최대 몇 개 항목을 한 트랜잭션에 넣는가?”를 적는다.
3. 테스트넷 또는 로컬 fork에서 가장 큰 입력으로 gas estimate를 한 번 실행한다.
4. 결과 옆에 16,777,216 gas cap 대비 비율을 적는다. 예: 12.4M / 16.78M = 74%.
5. 80%를 넘으면 TODO를 남긴다: chunk size limit, resume cursor, partial completion event, retry-safe function.
6. 인프라를 운영한다면 다음 대시보드 항목을 하나 추가한다: max(tx.gasLimit), p95(tx.gasLimit), block_rlp_size_estimate 중 하나.

핵심은 오늘 당장 모든 배치 로직을 고치는 것이 아니다. “우리 시스템에서 한 트랜잭션이 너무 많은 일을 하는 지점”을 한 곳이라도 찾아내는 것이다.

7. 더 볼 자료

• EIP-7825: Transaction Gas Limit Cap
  • txpool validation과 block validation에서 cap을 어디에 적용하는지 확인하기 좋다.
• EIP-7934: RLP Execution Block Size Limit
  • gas와 별개인 byte-size 경계가 왜 필요한지 볼 수 있다.
• Ethereum Foundation Blog - Fusaka Update: Transaction Gas Limit Cap arrives with EIP-7825
  • 앱·툴링 개발자가 실제로 어떤 점을 테스트해야 하는지 정리되어 있다.
• Ethereum Foundation Blog - Fusaka Mainnet Announcement
  • Fusaka 안에서 PeerDAS, BPO, execution-layer guardrail이 어떻게 함께 묶이는지 볼 수 있다.
• EIP-7825 Empirical Report
  • cap이 과거 mainnet 트랜잭션에 어느 정도 영향을 주는지 수치로 확인할 수 있다.

중복 회피 메모

최근 blockchain_dev 글은 PeerDAS/data availability, EIP-7928 block-level access list와 병렬 실행 전제, FOCIL inclusion list, ZK Gateway settlement layer, Solana Alpenglow finality, Humanity Protocol ProxyAdmin 권한 사고를 다뤘다. 이번 글은 특정 DA·settlement·권한 사고가 아니라 처리량을 올릴 때 최악의 트랜잭션 gas와 최악의 블록 byte size를 프로토콜 경계로 제한하는 이유에 집중한다. EIP-7928 글이 “블록이 실행 전에 접근 대상을 말해야 하는 이유”였다면, 이번 글은 “블록과 트랜잭션이 커질 수 있는 최대치를 왜 별도 차원으로 잘라야 하는가”를 다룬다.