Fault proof는 실행 클라이언트가 아니라 재현 계약이다: OP Stack BLOBBASEFEE 버그로 보는 L2 검증 경계

10분 읽기·2026.07.11·출처 6개·00

오늘의 질문

롤업의 fault proof 프로그램이 L2 블록을 거의 같은 방식으로 실행하면 충분할까, 아니면 운영 클라이언트와 바이트 단위로 같은 환경을 재현해야 할까?

blockchain-dev.md

Fault Proof Soundness

Fault proof는 실행 클라이언트가 아니라 재현 계약이다: OP Stack BLOBBASEFEE 버그로 보는 L2 검증 경계

카테고리: blockchain_dev
예상 읽기 시간: 10분
오늘의 질문: 롤업의 fault proof 프로그램이 L2 블록을 “거의 같은 방식”으로 실행하면 충분할까, 아니면 운영 클라이언트와 바이트 단위로 같은 환경을 재현해야 할까?
핵심 출처:
- kona-client/v1.6.0 release - 2026-06-19, 확인일 2026-07-11
- kona-host/v1.6.0 release - 2026-06-19, 확인일 2026-07-11
- fix(Kona-executor): Pin blob base fee #21328 - 병합 2026-06-10, 확인일 2026-07-11
- Upgrade 19b — Karst Hardfork - 2026, 확인일 2026-07-11
- OP Stack Fault Proof Specification - 문서, 확인일 2026-07-11

1. 왜 지금 봐야 하나

2026년 6월 19일, Optimism monorepo에는 kona-client/v1.6.0과 kona-host/v1.6.0 릴리스가 올라왔다. 둘 다 첫 문장부터 “critical security fix”이자 “required update”라고 표시되어 있다. 핵심 수정은 OP Stack fault-proof program에서 post-Jovian 블록의 BLOBBASEFEE 값을 1로 고정하는 것이다.

표면적으로 보면 작은 실행환경 변수 하나처럼 보인다. 하지만 릴리스 노트는 이 차이가 dispute-game soundness를 깨뜨릴 수 있었다고 설명한다. kona executor는 EIP-4844 blob 환경을 parent header에서 유도했고, post-Jovian에서는 blobGasUsed가 DA footprint를 담는다. 부모 footprint가 약 4.26M을 넘으면 BLOBBASEFEE > 1이 될 수 있었고, canonical chain을 실행하는 op-geth/op-reth는 이 값을 1로 고정한다. 즉 운영 체인이 보는 EVM 환경과 fault proof 프로그램이 재현하는 EVM 환경이 달라질 수 있었다.

롤업 개발자에게 이 사건은 “버그가 있었다”보다 더 중요한 질문을 던진다.

fault proof는 별도의 실행 클라이언트가 아니라, 정식 체인 실행을 정확히 재현하겠다는 계약이다.

Optimistic rollup의 보안은 “누군가 잘못된 L2 state root를 올리면 누구나 도전할 수 있다”는 구조에 서 있다. 그런데 도전 프로그램이 canonical execution과 다른 규칙으로 블록을 실행하면, 올바른 상태가 틀렸다고 나오거나 틀린 상태가 맞다고 나올 수 있다. 이때 깨지는 것은 단순 테스트가 아니라 withdrawal 안전성과 dispute game의 신뢰 경계다.

2. 핵심 개념

OP Stack fault proof 시스템은 크게 세 부분으로 나뉜다.

Fault Proof Program: L1 데이터, dispute 입력, rollup 설정을 받아 L2 상태 전이를 stateless하게 재현한다.
Fault Proof VM: 프로그램의 한 instruction step까지 추적하고, 그 step을 L1에서 증명할 수 있게 한다.
Interactive Dispute Game: 큰 상태 차이를 이진 탐색처럼 쪼개 마지막 한 instruction까지 내려간다.

여기서 중요한 단어는 “stateless”다. stateless execution은 아무 상태나 대충 다시 만드는 것이 아니다. pre-image oracle을 통해 필요한 입력을 가져오고, 같은 chain config, 같은 hardfork rule, 같은 EVM 환경, 같은 deposit 처리, 같은 fee 계산을 적용해 canonical client와 같은 결과를 내야 한다.

이번 버그의 중심인 BLOBBASEFEE는 EVM opcode다. Ethereum L1에서는 EIP-4844 이후 blob gas market의 base fee를 읽는 값이다. 하지만 OP Stack L2에서는 L1과 같은 방식의 blob gas market을 그대로 실행하지 않는다. L2에는 L1-cost fee, DA footprint, rollup 특유의 upgrade schedule이 있고, Ecotone/Jovian/Karst 같은 OP Stack fork가 L1 EVM 기능과 L2 수수료 회계를 조합한다.

문제는 이렇게 정리할 수 있다.

zsh — 생존확인.sh

canonical OP execution: BLOBBASEFEE = 1
fault proof replay:     parent header에서 blob env 유도 → 특정 post-Jovian 조건에서 BLOBBASEFEE > 1
결과: 같은 L2 블록을 서로 다른 EVM 환경에서 실행

스마트컨트랙트 입장에서는 block.blobbasefee를 읽는 코드가 있으면 분기, 이벤트, 저장값, revert 여부가 달라질 수 있다. 그런 차이가 dispute game 안에서 발생하면 proof program은 “정확한 재현기”가 아니라 “다른 체인 규칙을 가진 실행기”가 된다.

3. 최신 이슈와 연결

kona-client/v1.6.0 릴리스는 이 수정을 세 가지 맥락에 묶어 설명한다.

첫째, 이 릴리스는 Upgrade 19, 즉 Karst hardfork에 필요하다. Upgrade 19b 제안은 OP Stack이 Ethereum Fusaka/Osaka 계열의 실행 변화와 정렬되고, Rust 기반 kona-client를 primary fault proof program으로 승격하며, op-geth/op-program 지원을 종료하는 흐름을 설명한다. 다시 말해 fault proof 구현이 보조 도구에서 핵심 보안 경로로 올라오는 시점이다.

둘째, 수정은 단순히 BLOBBASEFEE 하나만이 아니다. 같은 릴리스는 pre-refund EVM gas per block을 MAX_GAS_LIMIT로 제한하고, EIP-1559 parameter에서 zero elasticity/denominator를 거부하며, interop proof를 위해 superchain-registry dependency set을 내장한다고 적었다. 공통점은 “proof program이 허용하는 입력 공간을 canonical client와 더 가깝게 좁힌다”는 것이다.

셋째, kona-host/v1.6.0도 같은 soundness fix와 함께 witness fetch reliability를 고쳤다. fault proof는 client만 맞으면 끝나는 게 아니다. host가 preimage와 witness를 안정적으로 공급해야 하고, 일시적 fetch 실패가 잘못된 fallback으로 이어지면 proof 경로 자체가 흔들린다.

GitHub PR #21328은 제목 그대로 Pin blob base fee다. 설명은 “Update kona executor to pin the blob base fee to 1 on OP Stack”이라고 짧다. 하지만 이 짧은 변경이 중요한 이유는, proof system에서 환경 변수 하나가 전체 state transition의 입력이기 때문이다.

4. 개발자 관점 해석

이 사건을 L2/rollup 개발자의 언어로 바꾸면 네 가지 원칙이 나온다.

첫째, fault proof는 “대체 구현”이 아니라 “동일성 테스트 대상”이다.
op-reth, op-geth, kona-client, op-program이 같은 블록에 대해 같은 post-state를 내야 한다. 코드베이스가 다르다는 점은 proof diversity의 장점이지만, chain rule이 다르면 diversity가 아니라 fork다.

둘째, hardfork compatibility는 opcode 표만 맞추는 일이 아니다.
Fusaka/Osaka EIP를 L2에 들여올 때 “이 opcode가 존재하는가”만 보면 부족하다. L1에서 온 opcode라도 L2에서는 fee market, L1 data cost, deposit transaction, system contract 업데이트와 연결된다. BLOBBASEFEE처럼 L1 의미가 L2에서 고정값으로 재정의되는 경우를 명시해야 한다.

셋째, dispute-game soundness는 희귀 경로에서 깨진다.
일반 RPC, sequencer, block explorer에서는 문제가 안 보일 수 있다. 실제 취약점은 “post-Jovian”, “parent footprint가 특정 임계값 이상”, “컨트랙트가 BLOBBASEFEE를 읽음”, “그 블록이 dispute replay에 들어감” 같은 조건 조합에서 드러난다. 그래서 proof program 테스트는 happy path보다 fork boundary와 환경 opcode matrix를 먼저 봐야 한다.

넷째, 운영 업그레이드는 보안 업그레이드다.
릴리스가 required update라고 표시된 이유는 fault proof 참여자가 오래된 프로그램으로 dispute에 참여하면 올바른 검증 결과를 보장할 수 없기 때문이다. op-challenger, proof host, client image, absolute prestate, respected game type, rollup config가 서로 맞아야 한다.

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

OP Stack 체인을 운영하거나 L2 상태 검증, bridge withdrawal, fault proof monitoring을 다룬다면 아래를 점검하자.

내가 신뢰하는 withdrawal path가 어떤 dispute game type을 respected로 보고 있는가?
체인의 Upgrade 19/Karst 적용 여부와 kona-client/kona-host 버전이 일치하는가?
op-geth/op-program에 남아 있는 운영 의존성이 없는가? 있다면 end-of-support 이후 어떤 risk acceptance 문서가 있는가?
proof program과 canonical execution client가 같은 hardfork schedule, chain config, L1 block info, EIP-1559 parameter를 쓰는가?
환경 opcode 테스트에 다음 값들이 들어 있는가?
- BASEFEE
- BLOBBASEFEE
- CHAINID
- PREVRANDAO
- fork 전후 extraData 기반 EIP-1559 parameter
dispute replay 테스트가 “빈 블록/일반 transfer”뿐 아니라 DA footprint가 큰 post-Jovian 블록을 포함하는가?
release note의 “required”, “critical security fix”, “soundness” 키워드를 자동 알림으로 받고 있는가?
challenger를 운영한다면 proof image와 prestate hash 변경을 CI에서 확인하는가?

6. 오늘 10분 액션

오늘 바로 할 수 있는 실험은 “환경 opcode 차이표”를 만드는 것이다.

내가 운영하거나 통합하는 OP Stack 체인의 현재 fork 이름을 확인한다.
canonical execution client와 fault proof program 버전을 적는다.
아래 표를 채운다.

zsh — 생존확인.sh

항목              canonical client 값/규칙     proof program 값/규칙     테스트 있음?
BASEFEE           ?                            ?                         ?
BLOBBASEFEE       ?                            ?                         ?
EIP-1559 params   extraData/chain config       ?                         ?
deposit tx        txpool 금지/derivation 인증   ?                         ?
L1 cost fee       GasPriceOracle/L1 info       ?                         ?

마지막 줄에 장애 가정을 하나 쓴다.

zsh — 생존확인.sh

만약 proof program이 BLOBBASEFEE를 canonical client와 다르게 계산하면,
우리 withdrawal 모니터/bridge UI/challenger는 어떤 잘못된 신호를 낼까?

이 질문에 답할 수 있으면, “롤업을 쓴다”에서 “롤업의 검증 경계를 이해한다”로 한 단계 넘어간 것이다.

7. 더 볼 자료

중복 회피 메모

최근 blockchain_dev 글은 ERC-4626 vault NAV 조작, P-256/passkey precompile, MODEXP gas repricing, ERC-1271 fail-closed 검증, Arbitrum BoLD finality, encrypted mempool/MEV, EIP-7702 delegation, bridge source authentication, OP Stack interop 안전성을 다뤘다. 이번 글은 OP Stack interop 메시지 UX나 optimistic rollup challenge period 자체가 아니라, kona-client/kona-host의 BLOBBASEFEE soundness fix를 통해 fault proof program이 canonical L2 execution과 동일한 환경을 재현해야 하는 이유에 집중해 중복을 피했다.

zsh — 생존확인.sh

{
  "category": "blockchain_dev",
  "reading_time_minutes": 10,
  "thumbnail_prompt": "A technical editorial illustration of an optimistic rollup fault proof lab, two execution traces comparing BLOBBASEFEE values, a dispute game tree, OP Stack nodes, preimage oracle, and a red soundness boundary warning, modern clean blockchain style, no text"
}

오늘 10분 액션+5%