L2가 서로의 상태를 바로 읽을 때: OP Stack interop로 보는 cross-chain 안전성

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: L2 간 메시지를 “빠르게” 만들 때, 내 앱은 어떤 체인의 어떤 안전 수준을 믿고 실행하고 있는가?
• 핵심 출처:
  • Prepare for interop on OP Sepolia and Unichain Sepolia - 게시일 미표기, 확인일 2026-06-15
  • OP Stack Interoperability Explainer - 게시일 미표기, 확인일 2026-06-15
  • OP Stack Specification: Interop - 게시일 미표기, 확인일 2026-06-15
  • OP Supernode documentation - 게시일 미표기, 확인일 2026-06-15
  • ethereum-optimism/optimism op-node v1.16.7 release - 2026-02-26, 확인일 2026-06-15

1. 왜 지금 봐야 하나

OP Stack interop는 “체인이 많아져도 사용자는 하나의 네트워크처럼 느끼게 하자”는 시도다. Optimism 문서는 OP Sepolia와 Unichain Sepolia가 2026년 7월 testnet에서 두 체인짜리 interop dependency set을 만들 예정이라고 안내한다. 정확한 activation timestamp와 버전은 아직 확정 전이며, governance 승인 뒤 superchain-registry에 게시될 예정이다. mainnet OP Stack 체인의 interop는 별도 일정으로 뒤따른다.

개발자에게 중요한 점은 이 이슈가 단순한 브리지 UX 개선이 아니라는 것이다. 기존 cross-chain 메시지는 대개 L1을 허브로 삼아 withdraw와 deposit을 거치거나, 별도 브리지·검증자·유동성 네트워크를 믿었다. OP Stack interop는 같은 OP Stack 계열 체인끼리 더 낮은 지연으로 서로의 상태를 읽게 하려 한다. 그러면 앱은 “A 체인에서 이벤트가 났으니 B 체인에서 바로 실행한다”는 패턴을 더 자주 쓰게 된다.

하지만 속도가 빨라질수록 실패 모드도 날카로워진다. 메시지가 빠르게 도착하는 것과 그 메시지가 안전한 것은 다르다. 어떤 블록이 unsafe인지, safe인지, finalized인지, 그리고 cross-chain dependency가 같은 수준으로 검증되었는지가 애플리케이션의 돈과 권한을 좌우한다.

2. 핵심 개념

OP Stack interop의 기본 단위는 initiating message와 executing message다.

첫 번째 트랜잭션은 source chain에서 실행되고 로그 이벤트를 남긴다. 스펙은 이 로그를 initiating message로 본다. 두 번째 트랜잭션은 destination chain에서 실행되며, CrossL2Inbox에 “내가 참조하는 source chain의 로그가 실제로 존재한다”고 주장한다. 이때 source chain, block, log index 같은 식별자가 필요하다.

핵심 안전 규칙은 간단하다.

destination chain의 블록이 어떤 cross-chain 메시지를 실행했다면, 그 블록은 source chain의 대응 initiating message를 재현·검증하기 전까지 안전해질 수 없다.

즉 interop는 “메시지를 전달하는 API”가 아니라 fork-choice와 safety label에 들어가는 규칙이다. 스펙은 유효하지 않은 executing message를 포함한 블록은 reorg out될 수 있다고 설명한다. Sequencer는 메시지를 포함하기 전에 유효성을 확인해야 하고, proof system도 executing message의 유효성을 검사할 수 있어야 한다.

여기서 dependency set이 중요해진다. 어떤 체인이 B 체인 메시지를 받을 수 있다면, A 체인의 verifier는 B 체인의 관련 로그와 safety 상태를 따라가야 한다. 체인이 늘어나면 단순히 RPC URL이 늘어나는 것이 아니라, 안전 판단의 입력이 늘어난다.

3. 최신 이슈와 연결

이번 rollout 안내에서 가장 눈에 띄는 운영 변화는 op-supernode다. 문서는 activation 전에 OP Sepolia와 Unichain Sepolia 노드 운영자가 기존의 균질한 op-node 토폴로지에서 다음 구조로 이동해야 한다고 설명한다.

1. 하나 이상의 op-supernode가 dependency set의 모든 체인을 derive한다.
2. 나머지 op-node들은 Light CL 모드로 supernode를 따라간다.
3. 각 chain에는 별도 execution client가 필요하다. 안내 문서는 interop activation이 op-geth 지원 종료 이후이므로 op-reth 기반 계획을 권한다.

op-supernode는 dependency set 안의 여러 체인을 한 프로세스의 virtual node로 실행하고, L1 RPC와 beacon client를 공유한다. 중요한 기능은 cross-chain message verification이다. 각 체인의 consensus layer가 자기 체인의 safety에 대한 단일 출처로 남되, supernode가 “이 블록의 cross-chain dependency가 검증됐는가”를 보고 advance 또는 invalidate 신호를 낸다.

GitHub release와 PR 흐름도 같은 방향을 보여준다. 2026년 2월 op-node/v1.16.7 release에는 supernode와 관련된 safe/local safe label 조정, block replacement, supervisor 설정 등이 포함되었다. 별도 PR 설명에 따르면 invalid cross-chain executing message가 발견되면 supernode가 해당 블록을 invalidate하고 chain rewind 및 replacement block 경로를 사용한다. 즉 interop는 SDK 함수 추가가 아니라 노드의 안전 상태 계산과 블록 교체 로직까지 건드리는 변화다.

4. 개발자 관점 해석

첫 번째 해석은 cross-chain call을 일반 함수 호출처럼 보면 안 된다는 것이다. 같은 Superchain 안에서 메시지가 빨라져도, 실행은 두 체인의 상태 전이에 걸쳐 있다. source chain에서 로그가 생기고, destination chain에서 그 로그를 참조해 실행한다. 중간에 source chain 안전 수준이 바뀌거나, destination block이 잘못된 메시지를 포함하면 결과는 재조정될 수 있다.

두 번째 해석은 RPC가 단순 조회 인프라가 아니라 신뢰 경계가 된다는 점이다. interop-prep 문서는 --l2.follow.source가 비어 있거나 non-supernode를 가리키면 op-node가 cross-chain validation 없이 safe head를 진행할 수 있다고 경고한다. 앱 백엔드가 그런 RPC를 “safe”라고 믿고 settlement, mint, unlock을 진행하면, 실제 프로토콜 safety와 애플리케이션 safety가 갈라진다.

세 번째 해석은 브리지 자산의 실패 모드가 달라진다는 것이다. OP Stack token bridging 스펙은 SuperchainERC20이 crosschainBurn과 crosschainMint를 사용하고, 같은 주소 배포와 SuperchainTokenBridge 권한을 통해 fungibility를 맞추려 한다고 설명한다. 이는 lock/unlock 유동성 문제를 줄일 수 있지만, 토큰 컨트랙트 권한·same-address 보장·messenger replay protection·domain binding을 모두 제대로 구현해야 한다는 뜻이기도 하다.

네 번째 해석은 dependency set이 커질수록 “가장 느리거나 잘못 설정된 체인”이 UX를 끌어내릴 수 있다는 점이다. 어떤 destination block이 여러 source chain의 메시지를 실행한다면, 모든 dependency가 같은 safety level로 확인되어야 한다. 완전 연결된 cluster는 사용자 경험에는 좋아 보이지만, 운영자에게는 모든 체인을 따라가야 하는 비용과 장애 전파 면적을 만든다.

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

• cross-chain 기능마다 요구 safety level을 명시하라. 예: 포인트 적립은 unsafe 허용, 출금·mint·권한 변경은 safe 또는 finalized만 허용.
• RPC 공급자가 interop activation 이후 어떤 노드 토폴로지를 쓰는지 확인하라. op-supernode를 따르지 않는 safe view를 그대로 믿으면 안 된다.
• 이벤트 기반 메시지를 처리할 때 source chain id, block hash, log index, destination chain id, message hash를 로그로 남겨라. 장애 때 “어떤 상태를 믿고 실행했는지”가 추적 가능해야 한다.
• 토큰을 SuperchainERC20 스타일로 설계한다면 crosschainMint와 crosschainBurn 호출 권한을 최소화하고, bridge 외 권한자가 있다면 감사 로그와 emergency pause를 별도로 둬라.
• 같은 주소 배포를 전제로 삼는다면 CREATE2 salt, init code hash, constructor argument를 배포 파이프라인에서 검증하라.
• destination chain에서 메시지를 실행하기 전 source chain의 메시지 포함 여부뿐 아니라 원하는 safety level까지 확인하는 policy layer를 둬라.
• “빠른 interop”를 제품 문구로 쓰기 전에 failure mode 문구도 준비하라. 예: dependency 지연 시 pending, invalidation 시 rollback, source chain reorg 시 재시도.

6. 오늘 10분 액션

10분만 써서 내 코드베이스의 cross-chain 가정을 표로 만들어보자.

1. bridge, message, chainId, source, destination, finalized, safe 키워드로 코드 검색을 한다.
2. 각 기능을 한 줄로 적는다. 예: “Chain A deposit 이벤트를 보고 Chain B에서 포인트 지급”.
3. 그 옆에 현재 믿는 신호를 적는다. 예: RPC latest, confirmation N개, bridge callback, indexer event.
4. 마지막 칸에 필요한 safety level을 적는다. 돈·권한·mint는 최소 safe 이상으로 표시한다.
5. “RPC가 cross-chain validation 없는 safe head를 준다면 어떻게 되는가?”를 한 줄 failure scenario로 적는다.

이 표가 있으면 OP Stack interop뿐 아니라 다른 L2, 브리지, oracle 이벤트를 붙일 때도 같은 질문을 재사용할 수 있다.

7. 더 볼 자료

• Prepare for interop on OP Sepolia and Unichain Sepolia
  • activation 범위, node operator 요구사항, Light CL 전환, op-reth 주의사항을 확인할 수 있다.
• OP Stack Interoperability Explainer
  • dependency set, initiating/executing message, op-supernode의 역할을 개념적으로 설명한다.
• OP Stack Specification: Interop
  • 메시지 정의와 fork-choice 수준의 유효성 조건을 확인할 수 있다.
• OP Supernode documentation
  • 여러 체인을 한 프로세스의 virtual node로 실행하는 운영 모델과 shared L1/beacon client 구조를 설명한다.
• Token Bridging - OP Stack Specification
  • SuperchainERC20, SuperchainTokenBridge, burn/mint 기반 fungibility 모델을 확인할 수 있다.

중복 회피 메모

최근 blockchain_dev 글은 PeerDAS/data availability, EIP-7928 병렬 실행 전제, Solana Alpenglow finality, FOCIL inclusion list, ZK Gateway settlement layer, 멀티시그 ProxyAdmin, Ethereum gas/block size limit을 다뤘다. 이번 글은 특정 L1 확장 파라미터나 단일 rollup settlement가 아니라 OP Stack interop activation을 계기로 cross-chain dependency set, op-supernode, safe head 검증, L2 간 메시지의 실패 모드를 개발자 운영·보안 관점에서 정리한 점이 다르다.