개발자가 로컬에서 blob 거래를 미리 실행해 볼 때, 결과가 실제 Ethereum 거래 형식과 달라 잘못된 판단을 내릴 수 있던 부분을 Foundry가 고쳤다.
EIP-4844의 blob 거래는 대용량 데이터를 별도 blob으로 싣고, 본문 거래에는 그 blob을 가리키는 versioned hash를 넣는다. rollup이 L1에 데이터를 올릴 때 주로 쓰이며, 일반 gas와 별도로 blob gas·blob fee라는 규칙을 가진다.
eth_simulateV1은 여러 가상의 거래와 상태 변경을 실제로 보내지 않고 실행해
보는 RPC다. 하지만 시뮬레이터가 sidecar의 blob에서 hash를 만들지 않거나, 허용량과
수수료를 실제 규칙과 다르게 다루면 ‘로컬에서는 통과, 실제 노드에서는 실패’가
될 수 있다.
Foundry Anvil은 2026-07-29 16:54 UTC에 시뮬레이션 경로에서 blob sidecar로부터
versioned hash를 채우고, 활성 hard fork의 블록당 누적 blob gas 한도를 확인하도록
수정했다. 반환 거래도 canonical envelope·blob header field를 갖추도록 만들었다.
maxFeePerBlobGas를 생략했을 때 반환값은 명세 기본값인 0으로 유지하되,
검증을 끈 가상 실행에는 호출 내부의 허용적인 blob price를 사용한다.
출처: https://github.com/foundry-rs/foundry/commit/28dc6b4b0109147d6827cafa0e229eff580a676f
실제 diff의 실행 순서를 줄인 의사코드다.
기존 방식
for request in simulatedCalls:
execute(request)
return request as received
// sidecar → versioned hash, 누적 blob gas, 반환 envelope가 일관되지 않을 수 있었음
변경 방식
for request in simulatedCalls:
request.populateBlobHashesFromSidecar()
request.transactionType = request.preferredType()
used = numberOfBlobHashes(request) * DATA_GAS_PER_BLOB
reject if blockBlobGasUsed + used > activeFork.maxBlobGasPerBlock
execute(canonicalize(request))
return canonical transaction envelope
rollup·지갑·배처 개발자는 시뮬레이션 결과로 거래를 만들거나 실패 원인을 찾는다. 따라서 blob hash, fee cap, 블록 한도가 실제 제출 규칙과 같아야 한다. 특히 여러 blob 거래를 한 가상 블록에 넣는 테스트에서 한도 초과를 미리 잡을 수 있다. 이는 프로덕션 체인 규칙을 바꾸는 변경이 아니라, 로컬 개발 노드가 그 규칙을 더 정확히 재현하게 만드는 변경이다.
L2 확장성의 상당 부분은 blob data availability에 기대고 있다. 그만큼 개발 도구도 단순 EVM 호출을 넘어, blob fee와 hard fork별 파라미터를 정확하게 모델링해야 한다. 개발자 경험은 편한 RPC 이름보다 실제 네트워크와의 의미적 일치에서 나온다.
1차 출처: https://github.com/foundry-rs/foundry/commit/28dc6b4b0109147d6827cafa0e229eff580a676f