Superchain interop은 왜 브리지 기능이 아니라 fork choice 문제일까

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: L2끼리 2초 안에 메시지를 주고받게 만들려면, 왜 컨트랙트보다 먼저 “어떤 블록을 safe로 볼 것인가”를 바꿔야 할까?
• 핵심 출처:
  • Prepare for interop on OP Sepolia and Unichain Sepolia - 2026년 7월 대상 공지, 2026-07-27 확인
  • OP Stack interoperability explainer - 현재 문서, 2026-07-27 확인
  • OP Stack Interop specification - 현재 사양, 2026-07-27 확인
  • Super Root - OP Stack Specification - 현재 사양, 2026-07-27 확인
  • Fault Proof - OP Stack Specification - 현재 사양, 2026-07-27 확인
  • Superchain ETH Bridge - 현재 문서, 2026-07-27 확인

1. 왜 지금 봐야 하나

멀티체인 UX에서 가장 흔한 불편은 “체인을 바꾸고, 브리지를 기다리고, 래핑된 자산을 구분해야 한다”는 점이다. Optimism의 OP Stack interop은 이 문제를 단순히 더 빠른 브리지 UI로 풀려 하지 않는다. 공식 문서는 interop을 OP Stack 블록체인들이 서로의 상태를 읽게 만드는 프로토콜 묶음으로 설명한다.

2026년 7월 공지에서 더 현실적인 변화가 보인다. OP Sepolia와 Unichain Sepolia는 2026년 7월 interop 활성화 대상 testnet으로 안내되었고, 활성화 이후 두 체인은 2-chain dependency set을 이룬다. 운영자는 기존처럼 각 체인을 독립 op-node로만 따라가는 대신, 두 체인을 함께 derive하고 cross-chain message를 검증하는 op-supernode와 이를 따라가는 Light CL topology로 옮겨야 한다. 공지는 --l2.follow.source가 제대로 설정되지 않으면 safe head가 cross-chain validation 없이 activation block을 지나갈 수 있고, 그 노드는 interop chain의 verifier나 RPC source가 될 수 없다고 경고한다.

개발자에게 이 이슈가 중요한 이유는 “Superchain에서 ETH 전송이 빨라진다”가 아니다. 핵심은 이것이다.

cross-chain message를 빠르게 실행하려면, destination chain의 블록 안전성은 더 이상 destination chain 혼자 결정할 수 없다.

즉 interop은 브리지 컨트랙트 하나를 추가하는 문제가 아니라, fork choice, safe head, dependency set, fault proof가 함께 바뀌는 상태 검증 문제다.

2. 핵심 개념

OP Stack interop의 기본 단위는 두 개의 트랜잭션이다.

1. source chain에서 어떤 트랜잭션이 실행되고 log event를 만든다. 이 log event가 initiating message다.
2. destination chain에서 다른 트랜잭션이 그 initiating message와 identifier를 포함해 실행된다. 이때 CrossL2Inbox가 executing message를 남긴다.

여기까지만 보면 평범한 메시징 브리지처럼 보인다. 차이는 안전성 판단에 있다. OP Stack 사양은 destination chain의 fork choice rule이 유효하지 않은 executing message를 포함한 블록을 reorg out한다고 설명한다. sequencer는 executing message를 포함하기 전에 identifier가 source chain의 initiating message를 정확히 가리키는지 확인해야 한다.

이 구조에서 중요한 용어는 dependency set이다. 어떤 chain이 어떤 source chain의 initiating message를 받아들일 수 있는지 정한 집합이다. dependency set에 들어간 체인은 서로의 상태를 읽을 수 있지만, 그만큼 서로의 데이터 게시, derivation, 검증 지연이 내 safe head에 영향을 줄 수 있다.

그래서 op-supernode가 등장한다. interop explainer에 따르면 op-supernode는 dependency set에 있는 여러 체인의 consensus layer를 한 프로세스 안에서 함께 호스팅하고, L1 client와 beacon client를 공유하며, cross-chain verification을 수행한다. 각 체인의 consensus layer가 자기 체인의 안전성에 대한 source of truth로 남지만, supernode가 advance 또는 invalidate 신호를 주는 좁은 authority interface를 통해 cross-chain 검증 결과를 반영한다.

한 문장으로 줄이면 다음과 같다.

interop은 “메시지를 믿는 컨트랙트”가 아니라 “메시지 의존성을 만족하지 못한 블록을 safe로 올리지 않는 노드 규칙”이다.

3. 최신 이슈와 연결

2026년 7월 OP Sepolia/Unichain Sepolia interop 준비 공지는 이 원리를 운영 요구사항으로 바꿔 적는다.

• OP Sepolia chain ID 11155420과 Unichain Sepolia chain ID 1301이 testnet dependency set을 형성한다.
• 활성화 후 두 체인의 블록은 서로의 initiating message를 참조하는 executing message를 포함할 수 있다.
• 어떤 블록이 safe가 되려면 그 블록 안의 모든 cross-chain dependency가 같은 safety level에 도달해야 한다.
• 일반 op-node fleet은 Light CL로 바뀌고, safe/finalized view를 op-supernode에서 상속받는다.
• execution client는 chain마다 따로 필요하다. 공지는 interop 시점에는 op-reth를 계획하라고 안내한다.

이 말은 앱 개발자에게도 중요하다. RPC endpoint가 “블록을 반환한다”는 사실만으로는 충분하지 않다. 그 블록이 local-safe인지, cross-safe인지, finalized인지, 그리고 interop dependency까지 검증된 view인지가 제품 의미를 바꾼다.

Super Root 사양은 이 차이를 API로 드러낸다. superroot_atTimestamp는 dependency set 전체의 상태를 보수적으로 보여준다. safe_timestamp, local_safe_timestamp, finalized_timestamp는 각 체인의 head 중 최소값으로 계산된다. data는 요청한 timestamp에서 모든 체인이 fully verified data를 가질 때만 non-null이다. 반면 optimistic_at_timestamp는 아직 완전히 검증되지 않은 per-chain output도 담을 수 있다.

즉 “최신 상태를 빨리 보고 싶다”와 “검증된 cross-chain 상태를 근거로 돈을 움직이고 싶다”는 서로 다른 API 계약이다.

4. 개발자 관점 해석

블록체인 앱을 만들 때 우리는 종종 finality를 단일 숫자로 단순화한다. 예를 들어 “몇 confirmations 후 확정” 또는 “L2 safe head 이후 확정”처럼 말한다. interop에서는 이 표현을 더 잘게 나눠야 한다.

첫째, local-safe와 cross-safe를 구분해야 한다. source chain만 보면 안전해 보이는 message도 destination chain 입장에서는 아직 dependency 검증이 끝나지 않았을 수 있다. 사용자가 destination chain에서 받은 자산을 다시 담보로 넣거나, 다른 chain으로 재전송하거나, 고가치 거래에 쓰게 한다면 cross-safe 여부를 UI와 backend policy에 반영해야 한다.

둘째, dependency set이 커질수록 weakest-link risk가 커진다. explainer는 Superchain interop cluster가 fully-connected mesh를 지향한다고 설명한다. 모든 chain이 서로를 dependency set에 넣으면 UX는 좋아지지만, 운영자는 모든 chain의 log event indexing, derivation, L1 consensus state 확인, cross-chain bookkeeping을 따라가야 한다. 한 체인의 데이터 게시 지연이나 검증 실패가 다른 체인의 safe progress에 영향을 줄 수 있다.

셋째, fault proof도 단일 L2 output dispute에서 super root dispute로 확장된다. Fault Proof 사양은 interop이 Super Fault Dispute Game을 도입한다고 설명한다. 이 게임은 한 체인의 output root가 아니라 dependency set 전체의 super root state transition을 다툰다. state transition은 timestamp 단위로 진행되고, 각 timestamp 전환은 128 step으로 쪼개진다. 현재 dispute game은 dependency set에서 최대 127개 chain을 지원할 수 있다고 명시한다. 이는 “체인을 무한히 붙이면 된다”가 아니라, 검증 비용과 증명 구조가 실제 확장 한계를 갖는다는 뜻이다.

넷째, 브리지 컨트랙트의 invariant가 바뀐다. Superchain ETH Bridge 문서는 source chain에서 SuperchainETHBridge.sendETH가 ETH를 ETHLiquidity에 넣고, destination chain에서 relayETH가 ETHLiquidity에서 같은 양을 꺼내 destination에 보낸다고 설명한다. 모든 OP Stack chain에서 유통 중인 ETH는 L1 lockbox에 의해 backing되어야 하고, 새 ETH는 L1에 잠긴 경우에만 L2에 mint될 수 있다. 여기서 중요한 invariant는 “한 체인의 contract balance”가 아니라 “dependency set 전체의 circulation, liquidity, L1 backing”이다.

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

interop 기능을 직접 쓰지 않더라도, OP Stack 기반 앱이나 인프라를 운영한다면 다음을 점검해볼 만하다.

• RPC 신뢰 수준 표시: 현재 사용하는 RPC가 local-safe, cross-safe, finalized 중 어떤 view를 제공하는가?
• 메시지 상태 모델: cross-chain action을 initiated, executed-optimistic, cross-safe, finalized처럼 단계화했는가?
• 재사용 제한: cross-safe 전 자산이나 메시지를 재담보, 재브리지, 고위험 action에 쓰지 못하게 막을 필요가 있는가?
• dependency set 관측성: source chain별 lag, missing initiating message, invalid executing message, replacement block 수를 지표로 볼 수 있는가?
• 운영 topology: 노드를 직접 운영한다면 op-supernode, Light CL, chain별 execution client, shared L1/beacon client 장애 경계를 그렸는가?
• 컨트랙트 검증: destination contract가 L2ToL2CrossDomainMessenger 같은 canonical messenger에서 온 호출만 받는지, source bridge 주소와 chain ID를 확인하는지 테스트했는가?
• 경제적 invariant: bridge/liquidity 계정의 총량, L1 backing, source deposit과 destination withdrawal의 합이 맞는지 모니터링하는가?

6. 오늘 10분 액션

1. Optimism interop overview에서 Initiating Message, Executing Message, Dependency Set 정의를 읽고, 내 말로 한 줄씩 번역한다.
2. 내 앱의 cross-chain 기능 하나를 골라 “이 상태는 local-safe만 필요하다 / cross-safe가 필요하다 / finalized가 필요하다”로 나눈다.
3. UI에 표시할 상태명을 네 개로 적어본다: sent on source, executed on destination, cross-safe, finalized.
4. 만약 OP Stack node를 운영한다면 op-node가 어떤 source에서 safe/finalized view를 받는지, interop activation 이후 --l2.follow.source가 필요한지 체크리스트에 넣는다.

7. 더 볼 자료

• Prepare for interop on OP Sepolia and Unichain Sepolia
• OP Stack interoperability explainer
• OP Stack Interop specification
• Super Root specification
• Fault Proof specification
• Superchain ETH Bridge

중복 회피 메모

로컬 content/generated와 Supabase의 최근 blockchain_dev 글을 확인했다. 최근 글은 Chainlink SVR/OEV, Arbitrum Timeboost L2 sequencing, KelpDAO/LayerZero DVN RPC quorum, EIP-4444 history expiry, EIP-7917 proposer lookahead, EIP-7939 CLZ opcode, EIP-7907 code size gas, Solana Alpenglow finality, Taiko bridge origin verification, OP Stack fault proof soundness, ERC-4626 NAV manipulation, P-256/passkey precompile, MODEXP repricing, PeerDAS/blob fee reserve를 다뤘다. 이번 글은 특정 브리지 사고나 단일 L2 fault proof 버그가 아니라 OP Stack interop의 dependency set, op-supernode topology, cross-safe fork choice, super root API, Super Fault Dispute Game을 연결해 “빠른 브리지 UX는 노드의 안전성 규칙 변화 위에서만 가능하다”는 관점에 집중해 중복을 피했다.