L2가 또 다른 L2에 정산한다면: ZK Gateway로 보는 공유 settlement layer의 신뢰 경계

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 롤업이 Ethereum L1이 아니라 Gateway 같은 다른 ZKChain에 배치를 정산하면, 사용자는 정확히 무엇을 더 믿고 무엇을 덜 기다리게 될까?
• 핵심 출처:
  • ZKsync Governance: ZIP-10 Activate ZK Gateway as a Settlement Layer - 제안 2025-05-16, 투표 종료 2025-05-29, 확인일 2026-06-12
  • OpenZeppelin: Inside ZKStack's Crosschain Architecture — Part I - 게시일 2025-07-17, 확인일 2026-06-12
  • OpenZeppelin: Inside ZKStack's Crosschain Architecture — Part II - 게시일 미확인, 확인일 2026-06-12
  • matter-labs/era-contracts release-v27: Gateway overview - 게시일 미확인, 확인일 2026-06-12
  • ZKsync Era Documentation: Advanced local setup with ZKsync Gateway - 게시일 미확인, 확인일 2026-06-12

1. 왜 지금 봐야 하나

ZKsync Governance의 ZIP-10은 ZK Gateway를 Elastic Network의 선택적(shared) settlement layer로 활성화하는 제안이고, 투표가 2025년 5월 29일 종료된 뒤 실행 상태로 표시되어 있다. 핵심 문장은 “ZK Chains가 배치를 더 싸게 정산하고, 앞으로 더 빠른 trustless interop을 가능하게 한다”는 것이다. 여기까지만 읽으면 “L2 수수료 절감 뉴스”처럼 보인다.

하지만 개발자에게 더 중요한 질문은 비용이 아니다. settlement layer는 롤업의 배치가 commit, prove, execute되는 곳이다. 즉 “이 체인의 상태 전이가 유효하다고 누구에게 증명하는가”, “출금 메시지는 어디서 최종 확인되는가”, “장애가 났을 때 사용자가 어느 계층을 통해 빠져나오는가”를 정하는 보안 경계다.

ZK Gateway가 흥미로운 이유는 L2가 항상 L1에 직접 정산해야 한다는 단순 모델을 깨기 때문이다. 어떤 ZKChain은 Ethereum L1에 직접 배치를 올릴 수 있고, 다른 ZKChain은 Gateway에 배치를 정산한 뒤 Gateway가 다시 L1에 정산할 수 있다. OpenZeppelin의 ZKStack 아키텍처 글은 이 구조를 L2ToL1LogsTree, ChainTree, SharedTree라는 세 종류의 Merkle tree와 재귀 proof 흐름으로 설명한다.

따라서 오늘의 학습 포인트는 “Gateway가 좋다/나쁘다”가 아니다. 공유 settlement layer를 쓰는 순간 신뢰 경계가 어떻게 재배치되고, 브리지·출금·인덱서·앱 UX가 어떤 실패 모드를 새로 가져야 하는지 보는 것이다.

2. 핵심 개념

한 문장으로 정리하면, ZK Gateway는 여러 ZKChain의 배치 정산과 메시지 증명을 한 중간 settlement layer에 모아 비용과 상호운용성을 최적화하려는 구조다.

먼저 settlement layer를 분리해서 보자. 롤업은 사용자의 모든 트랜잭션을 L1에서 실행하지 않는다. 대신 L2에서 실행하고, 일정 단위의 batch를 만들어 어떤 상위 계층에 제출한다. 그 상위 계층에서 batch를 commit하고, validity proof를 verify하고, execute 단계에서 상태 루트와 메시지를 확정한다. 이 상위 계층이 settlement layer다.

ZKStack 문맥에서 각 ZKChain은 DiamondProxy라는 계약 묶음을 settlement layer에 가진다. 이 계약은 batch 상태, 설정, 업그레이드, prove/execute 흐름을 관리한다. 기본적으로는 이 DiamondProxy가 Ethereum L1에 있지만, Gateway로 migrate하면 Gateway 위에 새 DiamondProxy가 생기고 이후 batch publication이 Gateway를 통한다.

OpenZeppelin Part I이 설명하는 세 tree는 다음처럼 역할이 다르다.

1. L2ToL1LogsTree: 특정 batch 안에서 settlement layer가 알아야 하는 로그와 메시지의 root다. 예를 들어 출금 로그, L1→L2 트랜잭션 실행 상태, 프로토콜 업그레이드 로그가 여기에 들어간다.
2. ChainTree: 하나의 ZKChain이 성공적으로 정산한 batch들의 누적 기록이다. settlement layer의 MessageRoot가 체인별 root를 관리한다.
3. SharedTree: 하나의 settlement layer에 올라탄 여러 ZKChain의 ChainTree root를 다시 모은다. Gateway가 settlement layer라면 Gateway의 SharedTree는 Gateway 위에 정산하는 여러 체인의 root를 커밋한다.

Part II는 batch commitment의 핵심 값을 fullRootHash = hash(localLogsRootHash, aggregatedRoot)로 설명한다. 여기서 localLogsRootHash는 그 체인 자신의 batch 로그 root이고, aggregatedRoot는 settlement layer 역할 여부에 따라 달라진다. 일반 ZKChain은 기본값에 가깝지만, Gateway는 자기 위에 정산하는 체인들의 chainRoots를 커밋한다. 그래서 Gateway에 정산한 체인의 L1 출금 proof는 단순히 “내 체인의 로그가 batch에 있다”만으로 끝나지 않고, “그 로그가 Gateway의 aggregated commitment를 거쳐 L1까지 이어진다”를 보여주는 재귀 proof가 된다.

3. 최신 이슈와 연결

ZIP-10은 Gateway를 optional shared settlement layer로 whitelisting하는 제안이다. 제안서에 따르면 Gateway는 chainID 9075인 ZK Chain으로 배포되며, ZK token을 base token으로 쓰고, permanent rollup으로서 ChainAdmin의 행동과 무관하게 Ethereum을 DA layer로 사용한다고 설명한다. 또한 초기 릴리스에서는 Matter Labs가 Gateway의 sole sequencer이고, 시간이 지나며 탈중앙화 설정으로 전환할 계획이라고 명시한다.

GitHub의 era-contracts release-v27 Gateway overview도 같은 방향을 말한다. Gateway는 fast interop을 위해 빠른 proof generation/verification이 필요하지만 L1 verification은 비쌀 수 있다는 문제, 그리고 여러 chain이 같은 layer에 settle할 때 proof aggregation으로 비용을 줄일 수 있다는 문제를 해결하려는 proof aggregation layer다. 동시에 현재는 settlement layer 목록이 whitelist이며 Gateway와 L1만 허용된다고 설명한다.

ZKsync 문서의 local setup도 개발자에게 좋은 신호를 준다. 로컬에서 gateway chain을 만들고 convert-to-gateway로 settlement layer로 바꾼 뒤, era chain을 migrate-to-gateway하는 절차가 문서화되어 있다. 마지막 결과 설명에는 L1에서 era로 들어가거나 나오는 deposit/withdraw가 gateway를 통한다고 되어 있다. 즉 이 구조는 추상 아키텍처가 아니라 개발 환경에서 재현 가능한 운영 모델로 내려오고 있다.

여기서 중요한 최신성은 “공유 settlement layer가 실제 거버넌스, 계약 릴리스, 개발 문서에 동시에 나타난다”는 점이다. 이것은 L2 경쟁 뉴스가 아니라, 앞으로 롤업 앱이 어느 L2인가뿐 아니라 그 L2가 어디에 settle하는가를 설정값으로 다뤄야 한다는 신호다.

4. 개발자 관점 해석

첫 번째 해석은 “브리지 경로가 settlement 경로와 분리되지 않는다”는 점이다. 앱은 보통 chainId, RPC, explorer, bridge URL 정도만 설정한다. 하지만 Gateway 구조에서는 사용자의 출금 proof가 L1 직행인지, Gateway의 aggregated root를 거치는지에 따라 대기 시간, 실패 지점, 고객지원 문구가 달라질 수 있다. 같은 ZKStack 계열 chain이라도 settlement layer가 바뀌면 출금 검증 경로가 바뀐다.

두 번째 해석은 “비용 절감은 새로운 운영 의존성을 산다”는 점이다. Gateway가 여러 체인의 proof를 모아 비용을 낮출 수 있다면 좋다. 하지만 Gateway sequencer 지연, Gateway batch prove 지연, Gateway→L1 execute 지연은 그 위에 올라탄 모든 체인의 사용자 경험에 영향을 준다. 이것은 단일 L2 장애가 아니라 shared settlement congestion이라는 새 병목이다.

세 번째 해석은 “DA와 settlement를 섞어 말하면 안 된다”는 점이다. ZIP-10은 Gateway가 permanent rollup이고 Ethereum을 DA로 사용한다고 설명한다. 그래도 개별 ZKChain이 Gateway에 settle한다고 해서 모든 위험이 사라지는 것은 아니다. 개발자는 내 chain의 DA 모드, Gateway의 DA 모드, proof aggregation 경로, 메시지 root 경로를 따로 봐야 한다. “결국 Ethereum 보안”이라는 표현은 너무 압축되어 있다.

네 번째 해석은 “거버넌스 권한도 신뢰 경계의 일부”라는 점이다. ZIP-10은 Gateway adoption이 각 ChainAdmin의 optional choice이고, opt out 가능성을 언급한다. 동시에 초기 Gateway sequencer가 Matter Labs라는 점도 명시한다. 개발자는 이를 가격이나 정치 뉴스가 아니라 migration authority, sequencer authority, whitelist authority, upgrade authority로 읽어야 한다.

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

1. 지원하는 각 chain마다 settlement_layer 필드를 명시하라. 값은 ethereum_l1, zk_gateway, other처럼 제품 설정으로 드러나야 한다.
2. 입금/출금 플로우에 message_path를 따로 기록하라. 예: L1 -> Gateway -> ZKChain, ZKChain -> Gateway -> L1.
3. 인덱서에서 batch 상태를 한 단계만 보지 말고 local batch committed/proven/executed, gateway batch included, l1 finalized처럼 단계별 상태로 쪼개라.
4. 사용자에게 “출금 처리 중”만 보여주지 말고 어느 계층에서 대기 중인지 표시하라. Gateway 대기와 L1 finality 대기는 서로 다른 장애 대응이 필요하다.
5. ChainAdmin 또는 governance가 settlement layer migration을 실행할 수 있다면, 앱 설정·브리지 경로·문서·고객지원 매크로가 함께 바뀌는 runbook을 만들어라.
6. shared settlement layer 장애를 모니터링하라. 단일 chain RPC는 정상이어도 Gateway prove/execute가 지연되면 출금 UX는 깨질 수 있다.
7. “싸다”는 이유만으로 Gateway 경로를 기본값으로 고정하지 말고, 고액 출금·기관 고객·위험 회피 사용자에게 L1 직접 settlement chain을 선호하는 옵션이 필요한지 검토하라.

6. 오늘 10분 액션

오늘은 내 코드베이스나 설계 문서에서 chain 설정을 10분만 점검해보자.

1. chainId, rpcUrl, explorerUrl, bridgeUrl이 있는 설정 파일을 연다.
2. 각 chain 옆에 settlement_layer와 withdrawal_message_path 두 필드를 추가한다고 가정한다.
3. 현재 제품이 이 값을 알 수 없으면 unknown으로 적는다.
4. unknown인 chain이 하나라도 있으면, 그 chain의 공식 문서에서 “settlement”, “DA”, “withdrawal proof”, “Gateway”, “shared bridge”를 검색할 TODO를 남긴다.
5. 마지막으로 사용자 문구를 하나 바꿔본다. “출금은 약 N분 걸립니다” 대신 “출금은 L2 batch 확정 → settlement layer 증명 → L1 실행 순서로 진행됩니다”라고 써보면 내가 어떤 단계를 모르는지 드러난다.

이 액션의 목적은 ZK Gateway를 당장 붙이는 것이 아니다. 롤업을 단순 네트워크 목록이 아니라 settlement graph로 보는 습관을 만드는 것이다.

7. 더 볼 자료

• ZIP-10 Activate ZK Gateway as a Settlement Layer: Gateway 활성화의 거버넌스 맥락, optional adoption, 초기 sequencer 가정을 확인하기 좋다.
• OpenZeppelin Part I: L2ToL1LogsTree, ChainTree, SharedTree를 구조적으로 이해하는 데 좋다.
• OpenZeppelin Part II: Gateway를 거치는 withdrawal proof와 recursive proof 경로를 따라가기 좋다.
• era-contracts Gateway overview: Gateway가 proof aggregation layer로 어떤 문제를 풀려는지 짧게 확인할 수 있다.
• ZKsync Era launch docs: 로컬에서 gateway chain을 만들고 era chain을 Gateway에 migrate하는 명령 흐름을 확인할 수 있다.

중복 회피 메모

최근 blockchain_dev 글은 FOCIL의 inclusion list와 fork-choice, Solana Alpenglow finality, EIP-7928 block-level access list, PeerDAS/data availability, Arbitrum Nova 오프보딩, native account abstraction을 다뤘다. 이번 글은 다른 L2 위에 L2가 정산하는 공유 settlement layer와 재귀 proof/출금 경로/ChainAdmin migration 신뢰 경계에 집중해 기존 finality·DA·검열 저항·체인 오프보딩 글과 관점을 분리했다.