롤업의 7일 대기는 왜 보안 파라미터일까: Arbitrum BoLD로 보는 fraud proof finality

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: optimistic rollup에서 “출금 7일”은 느린 UX일까, 아니면 잘못된 상태 전이를 되돌릴 수 있는 마지막 안전장치일까?
• 핵심 출처:
  • Overview of BoLD - 문서, 확인일 2026-06-26
  • BoLD: a technical deep dive - 문서, 확인일 2026-06-26
  • BoLD for Arbitrum chains - 문서, 확인일 2026-06-26
  • Arbitrum Nitro v3.11.0 - 게시일 2026-06-22, 확인일 2026-06-26
  • Network upgrades | Arbitrum DAO - 문서, 확인일 2026-06-26

1. 왜 지금 봐야 하나

최근 L2 글을 읽다 보면 “빠른 finality”, “몇 초 내 confirmation”, “즉시 브리지”라는 표현을 자주 만난다. 하지만 optimistic rollup의 보안 모델을 공부할 때는 이 표현을 그대로 믿으면 안 된다. 사용자 화면에 보이는 soft confirmation과, Ethereum 같은 parent chain에서 더 이상 뒤집기 어려운 hard finality는 다른 층위의 개념이다.

Arbitrum의 BoLD(Bounded Liquidity Delay)는 이 차이를 잘 보여준다. Arbitrum DAO의 네트워크 업그레이드 문서는 Arbitrum BoLD가 승인·실행되어 Arbitrum One과 Nova에 2025년 2월 12일 활성화되었다고 정리한다. 2026년 6월 22일 공개된 Nitro v3.11.0 릴리스도 validator image, WASM replay/proving, BoLD 관련 validator 수정처럼 검증 소프트웨어가 계속 운영 대상임을 보여준다.

BoLD의 핵심은 “7일을 없애자”가 아니다. 오히려 optimistic rollup에서 왜 challenge period가 필요한지, 그리고 악의적 검증자가 그 기간을 무한히 늘리지 못하게 하려면 dispute protocol이 어떤 모양이어야 하는지를 보여준다.

오늘 가져갈 한 문장은 이것이다.

optimistic rollup의 finality는 시간 숫자가 아니라, 잘못된 상태 주장(assertion)을 누가, 언제까지, 어떤 비용으로 반박할 수 있는가의 함수다.

2. 핵심 개념

Optimistic rollup은 이름 그대로 “일단 상태 전이가 맞다고 낙관하고, 틀렸다는 증거가 나오면 벌한다”는 모델이다. 단순화하면 흐름은 이렇다.

1. L2에서 트랜잭션이 실행된다.
2. validator가 parent chain에 L2 상태에 대한 assertion을 올린다.
3. challenge period 동안 다른 validator가 이 assertion을 검증한다.
4. 틀린 assertion이면 fraud proof dispute가 열린다.
5. 반박이 없거나 dispute에서 이기면 assertion이 확정된다.
6. 확정된 assertion을 기준으로 L2→L1 withdrawal이 처리된다.

여기서 assertion은 “이 inbox 메시지들을 이 순서로 실행하면 이 state root가 나온다”는 주장이다. Ethereum은 L2의 모든 계산을 매번 다시 실행하지 않는다. 대신 dispute가 생겼을 때 interactive fraud proof를 통해 차이를 좁히고, 마지막에는 Ethereum이 한 스텝의 계산을 검증할 수 있게 만든다.

BoLD 문서는 Arbitrum One의 기본 challenge period를 6.4일로 설명한다. unchallenged assertion은 이 기간 뒤 confirm될 수 있고, challenged assertion은 BoLD challenge가 추가 상한을 갖는다. Overview 문서는 BoLD가 두 challenge period, Security Council 개입을 위한 2일 grace period, 작은 computation delta 안에서 dispute가 끝나도록 설계되었다고 설명한다.

중요한 것은 “기다리는 기간” 자체가 아니라 누가 시간을 통제하느냐다. 기존 1-vs-1 dispute 방식에서는 공격자가 계속 새 분쟁을 만들어 정직한 party를 순차 게임에 묶어둘 수 있었다. 이것이 delay attack이다. 악의적 party가 bond를 잃을 각오만 있으면 assertion confirmation과 withdrawal을 오래 지연시킬 수 있다.

BoLD는 이 문제를 “all-vs-all” 구조로 바꾼다. 같은 시작점에서 여러 end state 주장이 경쟁하더라도, 정직한 state history를 아는 한 명의 validator가 많은 악의적 claim을 병렬로 상대할 수 있게 한다. 그래서 이름도 Bounded Liquidity Delay다. liquidity가 빠져나가는 시간을 완전히 없애는 것이 아니라, 악의적 dispute가 만들어낼 수 있는 지연을 상한 안에 묶는다.

3. 최신 이슈와 연결

2026년 현재 BoLD를 다시 볼 이유는 두 가지다.

첫째, BoLD는 이미 “연구 아이디어”가 아니라 운영 중인 L2 보안 구성요소다. Arbitrum DAO의 network upgrades 문서는 Arbitrum BoLD가 on-chain Tally vote를 거쳐 Arbitrum Sepolia, One, Nova에 승인·실행되었다고 표시한다. 즉, 개발자가 Arbitrum 위에 앱을 만들 때 withdrawal, validator, dispute, assertion이라는 단어는 문서 속 이론이 아니라 실제 운영 파라미터다.

둘째, Nitro 릴리스가 보여주듯 rollup validation은 계속 변하는 소프트웨어다. v3.11.0 릴리스는 validator 전용 Docker image, WASM module root, unified replay/MEL proving, BoLD validator fix 같은 내용을 포함한다. 이것은 “rollup은 배포하면 끝”이 아니라, parent chain contract, validator client, replay machine, challenge manager가 함께 맞아야 하는 시스템이라는 뜻이다.

셋째, Arbitrum docs의 BoLD adoption 문서는 모든 Arbitrum chain이 곧바로 permissionless validation을 켜야 한다고 말하지 않는다. 오히려 기존·신규 Arbitrum chain에 대해 BoLD는 채택하되 validation은 permissioned로 유지하는 경로를 강하게 권고한다. permissionless validation은 누구나 state를 advance하고 challenge할 수 있게 하므로 spam, resource exhaustion, bond token 경제성, 운영 대응 같은 새로운 공격면을 연다.

따라서 BoLD의 학습 포인트는 “탈중앙화가 더 좋다”라는 구호가 아니다. 개발자가 배워야 할 것은 다음 구분이다.

보안 속성: single honest party assumption, delay attack bound, fraud proof correctness
운영 파라미터: challenge period, validator whitelist, bond token, Nitro version, bridge warning
제품 영향: withdrawal delay, incident response, validator monitoring, user-facing finality wording

4. 개발자 관점 해석

1) finality는 UX 숫자가 아니라 상태 주장 생명주기다

L2 앱에서 “거래 완료”를 한 줄로 표현하고 싶어도, 실제로는 여러 단계가 있다.

• Sequencer가 transaction을 받아 L2 block에 넣은 상태
• Validator가 그 L2 state를 assertion으로 parent chain에 올린 상태
• Challenge period가 지나 assertion이 confirm된 상태
• Withdrawal proof가 parent chain에서 실행 가능한 상태

사용자에게는 첫 번째 단계가 거의 즉시처럼 보인다. 하지만 bridge, high-value settlement, cross-chain lending, oracle-triggered liquidation 같은 기능은 네 번째 단계의 의미를 무시하면 안 된다. “Arbitrum에서 확인됨”과 “Ethereum에서 되돌리기 어려움”을 같은 단어로 쓰면 리스크 설명이 틀어진다.

2) permissionless validation은 보안 향상이지만 운영 비용도 늘린다

BoLD는 permissionless validation을 가능하게 만든다. 하지만 가능하다는 말과 모든 체인에서 안전하다는 말은 다르다. BoLD adoption 문서는 Arbitrum One의 파라미터는 충분한 연구와 테스트를 거쳤지만, 다른 Arbitrum chain 구성에 대해 permissionless BoLD를 공식적으로 똑같이 권장하지 않는다고 경고한다.

왜일까? 검증을 열면 누구나 assertion을 올리고 challenge를 걸 수 있다. 정직한 party가 이긴다는 보안 증명은 중요하지만, 실제 운영자는 다음 비용을 감당해야 한다.

• challenge transaction gas
• validator node compute와 RPC 안정성
• bond token 유동성과 가격 변동
• 이벤트 모니터링과 자동 대응
• 사용자가 withdrawal delay 증가를 이해하도록 알리는 커뮤니케이션

즉 permissionless validation은 “권한 제거”인 동시에 “공격면 공개”다.

3) fraud proof는 컨트랙트만으로 완성되지 않는다

BoLD technical deep dive는 onchain ChallengeManager와 offchain challenge manager client, state manager backend, validator software를 함께 설명한다. 이 조합이 중요하다. Rollup contract가 아무리 잘 설계되어 있어도, 정직한 validator가 올바른 state를 계산하지 못하거나, parent chain 이벤트를 놓치거나, challenge move를 제때 제출하지 못하면 보안 가정은 약해진다.

Nitro v3.11.0 릴리스의 validator image와 replay/proving 관련 변경도 이 맥락에서 읽어야 한다. fraud proof 시스템은 Solidity contract 하나가 아니라 다음을 포함한 운영 시스템이다.

parent chain contracts
+ validator client
+ deterministic replay machine
+ state database
+ RPC/network reliability
+ challenge automation
+ release/upgrade discipline

4) bridge 보안은 “메시지가 왔다”보다 “어떤 assertion을 기준으로 왔나”를 물어야 한다

L2→L1 withdrawal이나 cross-chain bridge를 설계할 때 자주 놓치는 질문이 있다. 메시지가 존재한다는 사실만으로 충분한가? 아니면 그 메시지가 포함된 L2 state assertion이 parent chain에서 confirm되었는가?

Optimistic rollup에서는 후자가 핵심이다. 아직 challenge 가능한 assertion에 기반해 큰 금액을 풀어주면, 나중에 assertion이 틀렸다고 판명될 때 회계가 깨질 수 있다. 빠른 출금을 제공하는 유동성 provider나 intent bridge도 이 리스크를 사라지게 하지 않는다. 단지 누가 이 finality risk를 가격에 반영하고 떠안는지 바꿀 뿐이다.

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

L2 또는 bridge 관련 기능을 만들고 있다면 아래를 점검해보자.

• finality label 분리: UI/API에서 sequencer_confirmed, asserted_on_parent, challenge_period_elapsed, withdrawable 같은 단계를 구분하는가?
• withdrawal 정책: 사용자가 보는 예상 출금 시간은 challenge period와 extra delay를 반영하는가?
• high-value action gating: 큰 금액의 담보 이동, oracle 반영, cross-chain mint/burn은 어떤 단계 이후 허용하는가?
• validator dependency: 내 서비스가 특정 validator, RPC, indexer 장애에 과도하게 의존하지 않는가?
• upgrade monitoring: Nitro/ArbOS/Rollup contract upgrade 공지를 추적하고, 체인별 활성화 날짜를 운영 캘린더에 넣는가?
• permissionless 설정 확인: Orbit/Arbitrum chain을 운영한다면 disableValidatorWhitelist, validator allowlist, bond asset, challenge period를 문서화했는가?
• 사용자 설명: “빠른 확인”과 “L1 확정”의 차이를 고객지원 문구에 넣었는가?

6. 오늘 10분 액션

오늘은 코드를 많이 쓰기보다, 내가 쓰는 L2의 finality vocabulary를 정리해보자.

1. Arbitrum Docs의 BoLD Overview에서 assertion, challenge period, delay attack 정의를 읽는다.
2. 내가 만든 서비스의 입출금/브리지/정산 플로우에서 “언제 완료라고 표시하는지”를 표시한다.
3. 완료 상태를 최소 3단계로 나눈다.

soft_confirmed: L2에서 사용자에게 즉시 보여줄 수 있는 상태
parent_asserted: parent chain에 assertion 또는 관련 메시지가 올라간 상태
finalized_for_withdrawal: challenge period와 필요한 dispute window가 지난 상태

4. 코드나 문서에서 confirmed, finalized, settled를 섞어 쓰는 곳을 하나 찾아 이름을 바꾼다.

작은 리팩터링이지만 효과가 크다. finality 단어를 정확히 쓰면, 나중에 bridge, liquidation, cross-chain order 같은 기능을 설계할 때 어떤 리스크를 누구에게 전가하는지 더 잘 보인다.

7. 더 볼 자료

• Overview of BoLD
• BoLD: a technical deep dive
• BoLD for Arbitrum chains
• Arbitrum Nitro v3.11.0 release
• Arbitrum DAO network upgrades

중복 회피 메모

최근 blockchain_dev 글은 EIP-8184 encrypted mempool/MEV, EIP-7702 wallet delegation, bridge incident parsing, IBC source authentication, EIP-7732 ePBS, blob fee, OP Stack interop, Solana Alpenglow finality를 다뤘다. 이번 글은 새로운 L1 EIP나 브리지 사고가 아니라 Arbitrum BoLD를 통해 optimistic rollup의 fraud proof finality, challenge period, delay attack 상한, validator 운영 파라미터를 설명한다. 특히 “빠른 L2 UX”와 “parent-chain 확정”을 구분하는 실무 체크포인트에 집중해 기존 finality·bridge 글과 관점을 분리했다.