zkEVM 시리즈 (2): Polygon zkEVM의 Sequence 및 Bridge에 대한 더 많은 기술 세부사항

저자: 0xhhh, EthStorage (Twitter:@hhh69251498)

폴리곤 zkEVM에 대한 첫 번째 글에서 (zkEVM 시리즈 (1)｜Polygon zkEVM의 전체 구조와 거래 실행 프로세스), 우리는 Polygon zkEVM의 전체 구조와 거래 실행 프로세스를 요약하고, Polygon zkEVM이 어떻게 계산 확장을 구현하면서 L1의 보안을 계승하는지를 분석했습니다. 이번 글에서는 이전 글에서 구축한 프레임워크를 바탕으로, polygon zkEVM의 Sequencer와 Bridge에 대한 더 많은 기술 세부 사항을 깊이 있게 탐구하고, 향후 잠재적인 탈중앙화 Sequencer 구조의 다양한 특징에 대해 논의하겠습니다.

1. zkEVM Bridge 심층 분석

이전 글에서 우리는 Polygon zkEVM을 소개하는 과정에서 Polygon zkEVM의 네이티브 브리지를 매우 중요한 부분으로 놓쳤습니다. (주: 본 문서에서 L2는 Rollup을, L1은 Ethereum을 지칭합니다.)

1. 크로스 체인 데이터 상태 관리

Polygon zkEVM은 L1과 L2 각각에 대해 Exit Tree를 유지하고 있으며, 이름은 각각 L1 Exit Merkle tree와 L2 Exit Merkle tree입니다. 그러나 이 두 나무를 더 잘 관리하기 위해 Polygon zkEVM은 이 두 나무를 결합하는 똑똑한 방법을 사용했습니다. 아래 그림과 같습니다:

즉, L1 Exit Tree Root를 Global Exit Tree의 왼쪽 리프 노드로, L2 Exit Tree Root를 Global Exit Tree의 오른쪽 리프 노드로 사용합니다. 그러나 여기서 L1 Tree Root와 L2 Tree Root는 Sparse Merkle Tree(SMT)이며, Global Exit Tree는 Binary Merkle Tree입니다.

L1/L2 Exit Tree 리프 노드의 기본 정보는 다음과 같습니다:

2. 크로스 체인 프로세스

Polygon zkEVM의 계약 설계에서는 Bridge와 Consensus 계약을 가능한 한 분리하려고 했습니다. 현재 L1에 배포된 계약은 주로 3개로 나뉘며, 아래 그림과 같습니다:

이들 간에는 상속 관계가 없으며, 모두 독립적인 계약입니다. PolygonZkEVMBridge와 PolygonZkEVM은 Global Exit Tree Root를 업데이트하거나 검증하기 위해 PolygonZkEVMGlobalExitRoot를 호출합니다.

1) L1 → L2의 크로스 체인 프로세스

L1 → L2의 크로스 체인 프로세스는 위 그림의 주황색으로 표시된 세 단계에 해당합니다:

다음 코드의 BatchData 구조체에서 globalExitRoot에 해당합니다:

PolygonZkEVMBridge의 L2 계약

https://testnet-zkevm.polygonscan.com/tx/0x2a742f2f8a7b8635a76cc70b4574bebb1a81b2c0c1a618188773a1f8f2283bb8

https://testnetzkevm.polygonscan.com/address/0x39e780d8800f7396e8b7530a8925b14025aedc77#code

2) L2 → L1의 크로스 체인 프로세스

사용자는 L2에 배포된 Bridge 계약(PolygonZkEVMBridge.sol)의 Bridge() 함수를 호출하여 L2-Bridge-Tx를 전송합니다. 이로 인해 L2 Exit Tree에 새 노드가 추가되고, L2 Exit Tree Root와 Global Exit Tree Root가 순차적으로 업데이트됩니다.

그 후 Sequencer는 이 L2-Bridge-Tx를 특정 Batch에 넣어 L1의 합의 및 DA 계약(PolygonZkEVM.sol)으로 전송합니다.

그 후 Aggregator가 trustedVerifyBatches()를 호출하여 L1에 유효성 증명을 제출할 때, 실제로 L2 Exit Root도 Input으로 업로드되며, 이는 다음 함수의 NewLocalExitRoot를 나타냅니다. 이는 L2에 새로운 BridgeToL1 거래가 있음을 나타내지만, 이러한 거래는 현재 L1에서 인출할 수 없으며, 새로운 NewLocalExitRoot가 성공적으로 검증될 때까지 기다려야 합니다.

그 후 이 입력된 New Local ExitRoot는 검증 회로의 일부로 사용되며, 이 검증 논리는 L2에서 발생한 새로운 BridgeToL1 거래가 L2 Exit Tree Root를 현재 제출된 New Local ExitRoot로 변경했는지를 확인합니다.

이 Validity Proof가 검증되면 L1의 Global Exit RootManager는 L2 Exit Tree Root와 Global Exit Tree Root를 업데이트합니다: globalExitRootManager.updateExitRoot(newLocalExitRoot);

이때 사용자는 L1에 배포된 Bridge 계약(PolygonZkEVMBridge.sol)의 ClaimAsset() 함수를 호출하고 해당 Merkle Path를 제공하여 인출할 수 있으며, 크로스 체인 거래가 완벽하게 종료됩니다.

2. Polygon zkEVM의 검열 저항성

이전 글에서는 Trusted Sequencer를 소개했습니다. 이는 공식적으로 운영되는 Single Sequencer로, 기본적으로 L2 네트워크의 거래는 이 Trusted Sequencer에 제출되며, 즉각적인 Sequencer Finality를 얻을 수 있습니다.

하지만 실제로 사용자는 Trusted Sequencer를 거치지 않고도 L1 계약에 직접 거래를 제출할 수 있는 또 다른 방법이 있으며, 이를 통해 전체 네트워크는 여전히 일정 수준의 검열 저항성을 유지할 수 있습니다.

1. 실행 프로세스

1) 사용자는 L1 계약의 Force Batch 함수를 호출하여 이 함수를 통해 원하는 L2 거래를 L1 계약으로 직접 보낼 수 있습니다.

2) 계약에서는 이러한 Transactions를 Batch로 패키징하고, 계약 내의 Force Batches 매핑에 기록합니다.

3) Trusted Sequence는 Force Batches에 새로운 Force Batch가 있을 때 이를 로컬 노드에 동기화하고, 다음 L1에 Batches를 제출할 때 이 ForceBatch를 포함합니다.

4) 그러나 여기에는 특별한 상황이 존재합니다. 만약 Trusted Sequence가 다운되거나 특정 사용자가 제출한 Force Batch를 의도적으로 제출하지 않는 경우, 5일 후 사용자는 L1 계약의 SequenceForceBatches() 함수를 호출하여 이 ForceBatch를 L1 계약의 Sequenced Batches에 넣을 수 있습니다. 이는 이 Force Batch가 Rollup 내에서 거래 순서가 L1 계약에 의해 최종적으로 결정되었음을 의미하며, Trusted Sequence도 이 Force Batch의 거래 순서를 변경할 수 없습니다. (실제로 모든 Rollup은 Arbitrum의 Sequence Inbox 및 Inbox와 같은 검열 저항 특성을 제공하기 위해 이러한 특성을 가지고 있습니다.)

그러나 이 방법으로 Rollup 거래를 제출하는 것은 가능한 한 피하는 것이 좋습니다. Force Batch를 호출하여 L1에 자신의 거래를 제출할 때 거래 내용이 노출되기 때문입니다. 이때 거래 순서는 아직 확인되지 않았습니다(Sequence가 ForceBatch를 동기화하고 다시 Sequence Batch()를 통해 L1에 제출할 때 거래 순서가 진정으로 확인됩니다). 동시에 거래를 취소할 수 없으므로, 이때 도난당할 가능성이 큽니다.

이것은 실제로 검열 저항성을 제공하지 않는 것처럼 보입니다. Force Batch 방식에는 도난당할 위험이 있기 때문에 사용자가 이 기능을 실제로 사용할까요?

2. Sequencer의 실제 상태

위의 내용을 통해 알 수 있듯이, Sequence는 L1에서 Force Batch의 거래를 로컬 노드로 동기화하여 실행합니다. 따라서 Sequence의 실제 상태는 아래 그림과 같습니다:

Bn은 사용자가 Sequence에 직접 제출한 거래 실행 후의 결과를 나타냅니다;

FBn은 Sequence가 Force Batch의 거래를 동기화하여 실행한 후의 결과를 나타냅니다.

https://zkevm.polygon.technology/

3. L2 네트워크에 존재하는 세 가지 다른 Finality

다음으로 우리는 Polygon의 전체 구조를 검토하여 향후 탈중앙화 Sequencer에 대한 생각을 위한 기초를 마련하겠습니다. 우리는 다음 사항에 주목해야 합니다.

Sequencer와 Aggregator에 대해 그들의 상태는 모두 Syschronizer를 통해 1층 계약에서 동기화되며, 그들 간에는 직접적인 통신이 없습니다.

1) 세 가지 Finality

따라서 현재 전체 네트워크에는 세 가지 다른 정도의 Finality가 존재한다고 볼 수 있으며, 우리는 이를 Sequencer Finality, DA Finality 및 Verified Finality로 명명합니다.

a. 첫 번째 Sequencer Finality는 일부 문서에서 Soft Finality라고도 불리지만, 저는 Sequencer Finality라는 이름이 더 적합하다고 생각합니다. 이 Finality는 사실 Single Sequencer가 제공하는 상태 약속입니다.

Sequencer가 사용자 거래를 수신한 후 실행하여 제공하는 상태는 가장 안전하지 않은 상태입니다. 그러나 현재 공식 Single Sequencer의 상황에서는 안전성을 보장하면서도 극도의 사용자 경험을 제공합니다. 현재 단일 Sequencer의 Rollup 네트워크에서는 즉각적인 확인의 기쁨을 경험할 수 있습니다. 그러나 Single Sequencer의 가장 큰 위험은 Sequencer가 다운되는 것이며, 이는 전체 L2 네트워크를 사실상 마비시킬 수 있습니다. 그러나 DA 계층은 Ethereum에 위치하고 있기 때문에 L2 네트워크의 다운되기 전 상태를 일부 복구할 수 있습니다. 그러나 L1으로 전송되지 않은 L2 거래는 복구할 수 없습니다.

b. 두 번째 DA Finality는 이러한 거래가 L1의 DA 계층 계약에 제출되었음을 나타내며, 이때 거래 순서도 확정됩니다.

Trusted Sequencer는 Sequence Batch를 호출하여 거래를 L1에 전송하며, 이 경우 거래는 DA 계층에 포함됩니다. Polygon의 설계에서는 단일 Trusted Sequencer의 이유로 인해 L1 계약에 DA를 위해 업로드된 거래가 모두 유효한 거래임을 보장할 수 있습니다. 우리는 거래가 Trusted Sequencer에 의해 L1 계약에 업로드될 때, 이 거래가 Rollup 네트워크에 의해 인정되었으며, 이후 Aggregator가 Validity Proof를 제공하여 이 거래가 실제로 Revert될 수 없음을 보장할 수 있다고 볼 수 있습니다(단, L1 Reorg 제외).

c. 세 번째 Verified Finality는 이 거래가 Validity Proof의 검증을 통과했음을 나타내며, 진정한 Finality에 해당합니다. 일부 문서에서는 이를 Hard Finality라고도 부릅니다.

Aggregator가 DA 계층에 업로드된 거래에 대해 제공한 Validity Proof가 계약에 의해 검증되었을 때, 우리는 이 거래가 Revert될 수 없다고 간주합니다(단, L1 Reorg 제외). 우리는 이전 글에서 DA 계층에 제출된 거래가 Validity Proof 검증을 통과하는 데 걸리는 시간이 30분이며, Aggregator는 Validity Proof를 제공하여 충분한 Matic 보상을 받을 수 있다고 언급했습니다.

2) Aggregator 상태 동기화의 절충

여기서 Validity Proof 제공이 수익성이 있다고 가정해 보겠습니다. 그러면 Aggregator에게 가장 좋은 거래 동기화 방법은 L1의 DA 계층 계약에서 동기화하는 것이 아니라, Trusted Sequencer와 rpc 링크를 직접 설정하여 Trusted Sequencer로부터 최신 거래를 직접 가져오는 것입니다. 이렇게 하면 Validity Proof 생성이 더 빨라져, DA 계약에서 거래를 가져오는 다른 Aggregator보다 경쟁 우위를 가질 수 있습니다. Validity Proof 제공은 선착순이므로, 한 배치의 거래에 대해서는 단 하나의 집합 Validity Proof만 필요합니다. 첫 번째로 Validity Proof를 제출한 Aggregator는 해당 거래의 Matic 보상을 가져갈 수 있으며, 다른 Aggregator가 생성한 Validity Proof는 더 이상 보상을 받을 수 없습니다.

그러나 현재 실제로 Polygon은 Trusted Sequencer와 같은 역할을 하며, Validity Proof 생성 및 제출 작업을 처리하는 Trusted Aggregator도 있습니다. https://zkevm.polygon.technology/

4. Sequencer의 미래

다음으로 우리는 탈중앙화 Sequencer에 대한 생각을 계속하겠습니다. 첫 번째 질문은 왜 탈중앙화 Sequencer가 필요한가입니다. 우리는 Rollup이 Ethereum의 계산 능력을 확장하면서 Ethereum의 보안성과 탈중앙화 정도를 계승하기를 원하기 때문입니다. 현재 Single Sequencer 솔루션은 분명히 Ethereum의 탈중앙화 정도 목표를 달성하지 못합니다. 탈중앙화 Sequencer의 미래를 그리기 전에, 먼저 Sequencer의 작업을 되돌아보겠습니다. Polygon zkEVM을 예로 들면, 현재 Trusted Sequencer는 거래 처리를 FCFS에 따라 처리하며, 먼저 도착한 거래가 먼저 처리됩니다. 병렬 Mempool도 비공개로 되어 있어 사용자의 거래가 MEV에 노출되지 않도록 최대한 보호합니다.

일정량의 거래가 수집되면 이를 Batch로 패키징하여 L1 계약의 DA 위치에 업로드합니다. 이전 글에서도 언급했듯이, Sequencer가 업로드한 Batch는 실제로 후속 Batch에 이전 Batch의 해시를 포함하여 거래 순서를 확정했습니다. 따라서 우리는 Sequencer의 작업이 L1 Proposer의 작업과 유사하다고 볼 수 있습니다. 거래를 제안하고 거래 순서를 확인합니다.

우리는 Polygon zkEVM에서 탈중앙화 Sequencer를 소개하기 시작했으므로, Polygon zkEVM의 탈중앙화 Sequencer 솔루션인 Proof Of Efficiency(효율 증명)를 먼저 소개하겠습니다.

1. Proof-Of-Efficiency1) 솔루션 설명 POE의 설계에서는 누구나 Sequencer가 되어 L1에 Rollup Block을 제출할 수 있도록 허용하며, Rollup 네트워크의 거래 순서는 거래가 L1의 Rollup DA 계약에 제출된 순서에 따라 결정됩니다. (Polygon zkEVM에서 Batch는 Block과 동등합니다.) 아래 그림과 같이 사용자는 거래를 어떤 Sequencer에게 보낼지 스스로 선택할 수 있으며, 심지어 자신이 Sequencer가 될 수도 있습니다. 이러한 Sequencer는 충분한 거래를 수신한 후 이를 Batch로 패키징하여 L1에 제출합니다.

이러한 Sequencer는 수익 문제를 고려해야 합니다:

Sequencer 비용 = L1 가스 비용 + zkProof 생성 수수료

Sequencer 수익 = L2 가스 수수료

따라서 Sequencer는 최소한 몇 건의 거래를 Batch로 만들어 L1에 제출해야 수익성이 있는지를 고려해야 합니다. 그러나 Sequencer는 또 다른 문제인 시의성 문제도 고려해야 합니다. 만약 Sequencer의 거래 제출 속도가 너무 느리면, 사용자는 더 빠른 확인을 제공하는 다른 Sequencer로 이동할 수 있습니다.

2) 솔루션 실행 가능성

우선 이 솔루션이 작동할 수 있는 핵심 이유는 Polygon의 DA 부분이 어떤 상태 약속도 하지 않고 단지 거래 순서만 확정했기 때문입니다. 상태 약속(Sequencer가 거래 실행 후 대응하는 새로운 세계 상태를 약속하지만, 이 상태는 Validity Proof 또는 Fraud Proof로 검증되지 않은 상태)은 Validity Proof를 제출할 때만 제공됩니다. 이것이 이 솔루션이 실행될 수 있는 핵심 이유입니다.

실제로 Arbitrum은 거래를 DA 계약에 제출할 때 어떤 상태 약속도 하지 않지만, Optimism은 거래를 DA 계층에 제출할 때 상태 약속을 포함합니다. 따라서 이론적으로 Arbitrum은 POE를 사용하여 탈중앙화 Sequencer를 구현할 수 있지만, Optimism은 불가능합니다.

3) 왜 상태 약속을 포함하면 POE를 사용할 수 없는가? 여러 Sequencer가 거의 동시에 L1에 Batch를 제출할 때, 실제로 어떤 Sequencer도 DA 계약에서 L2의 거래 순서가 어떻게 될지 보장할 수 없기 때문입니다. 따라서 상태 약속을 포함하면, 전체 Batch가 Validity Proof 또는 Fraud Proof 검증을 통과하지 못할 가능성이 높습니다.

4) 무효 거래를 어떻게 처리할 것인가?

무효 거래는 예를 들어 계좌의 Nonce가 너무 낮거나 계좌 잔액이 가스 비용을 지불하기에 부족한 거래를 의미합니다. 이러한 거래는 L1(Geth)에서 블록에 포함되지 않습니다. 왜냐하면 블록에 무효 거래가 포함되면 전체 블록이 무효 블록이 되기 때문입니다. Validator는 이러한 블록에 투표하지 않으며, Proposer도 이러한 블록을 제안하지 않습니다.

현재 Single Sequencer의 경우, L2 네트워크는 이러한 무효 블록을 식별할 수 있으며, L1 DA 계약에서 이러한 거래를 포함하지 않도록 할 수 있습니다. 이는 L1의 블록 공간 낭비를 방지할 수 있습니다.

그러나 POE를 채택하면 Sequencer는 이러한 무효 거래를 식별할 수 있는 능력을 잃게 되므로, L1의 검증 거래로 인한 상태 변경 과정에서도 이러한 상황을 고려해야 하며, Sequencer가 무효 거래를 제출하면 사용자 수수료를 받을 수 없습니다.

5) Public Mempool(공공 거래 풀)?

POE를 채택하면 이러한 탈중앙화 Sequencer 간에 Public Mempool이 존재할 경우, 사용자의 거래가 서로 다른 Sequencer에 여러 번 제출될 수 있습니다. 물론 첫 번째로 제출된 거래만 유효하며, 이 거래만이 사용자 수수료를 받을 수 있습니다.

6) Sequencer가 실행 결과를 예측할 수 없는 이유

이러한 Permissonless Sequencer 모델에서는 Sequencer가 사용자에게 즉각적인 Sequencer Finality를 제공할 수 없습니다. 왜냐하면 Sequencer가 예측한 최종 블록체인 거래 순서와 실제 거래 순서 간에 편차가 발생할 수 있기 때문입니다. 이 편차는 여러 Sequencer가 거의 동시에 L1의 DA 계약에 거래 Batch를 제출할 수 있기 때문에 발생합니다. 이러한 경우 이러한 거래 Batch의 실제 순서가 예측 순서와 동일할 것이라고 보장하기 어렵습니다.

따라서 Sequencer가 자신의 상태를 동기화할 때, L1의 DA 계약에서 최신 제출된 거래 Batch를 동기화하여 실행하여 최신 상태를 얻습니다. 다른 Sequencer에서 상태를 동기화하는 것이 아닙니다.

7) L2의 MEV가 L1으로 유출

거래는 누구나 Sequencer가 되어 Rollup 네트워크의 거래를 제출할 수 있으며, 거래 Batch 제출은 실제로 L1의 일반 거래와 다르지 않습니다. 따라서 이는 MEV Boost의 전체 프로세스를 거치게 되며, 이는 L2 네트워크의 MEV가 MEV Boost 모듈로 유출됨을 의미합니다.

8) Aggregator의 설계

POE의 설계에서 Aggregator 역시 Permissionless입니다. 그러나 Validity Proof는 실제로 올바른 거래 하나만 필요하므로, 거래에 대한 올바른 Validity Proof를 제출한 첫 번째 Aggregator만 보상을 받을 수 있습니다. 따라서 Aggregator로서, 제출하는 Validity Proof의 증명 범위, 제출 시간 및 Validity Proof 제출로 얻을 수 있는 Matic 보상 간의 관계를 균형 있게 고려해야 하며, 최종적으로 가장 경쟁력 있는 전략을 찾아야 합니다.

이러한 자유 시장 경쟁 전략을 활용하면 거래에 대한 Validity Proof 생성 속도를 최대한 빠르게 할 수 있습니다.

https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/119888 )

8) 요약

POE는 완전한 PermissionLess 네트워크를 제공할 수 있으며, 전체 네트워크는 다운될 위험이 없을 수 있습니다. 그러나 L1의 DA 계약에는 무효 거래(예: 동일한 Nonce의 거래)가 포함될 수 있으며, MEV는 L1 네트워크가 가져가고, DA Finality와 Verified Finality만 제공할 수 있습니다.

2. Based Rollup

Based Rollup은 Rollup 네트워크의 Single Sequencer 작업을 Ethereum의 proposer에게 위임하려는 것입니다. 각 Proposer가 L1 블록을 제안할 때 유효한 Rollup 블록을 포함해야 합니다.

따라서 L1 네트워크의 Block Builder는 L2 거래를 수신하고 최대 가치를 가진 Rollup Block을 구축하기 위해 Rollup의 전체 노드를 실행해야 합니다.

이러한 솔루션의 장점은 L1의 보안성과 탈중앙화 정도를 최대한 계승할 수 있지만, Sequencer Finality와 Verified Finality만 제공할 수 있으며, L2의 MEV도 L1으로 유출되고, Ethereum 클라이언트 코드를 수정해야 하므로 L1의 보안성에 영향을 미칠 수 있습니다.

3. Shared Sequencing

Shared Rollup은 Based Rollup과 달리 Rollup Block의 구축 및 제출 작업을 Ethereum의 Proposer에게 맡기는 것이 아니라 Shared Sequencers의 위원회에 맡깁니다.

3.1. 구체적인 프로세스는 다음과 같습니다:

a. 서로 다른 Rollup의 사용자는 Shared Sequencers가 있는 네트워크에 직접 Rollup 거래를 보낼 수 있습니다.
b. Shared Sequencers는 내부에서 BFT 합의를 실행하여 매 라운드마다 Sequencer Leader를 선택하여 거래를 정렬하고 해당 Rollup Block을 구축합니다.
c. 그런 다음 이러한 Rollup Block을 서로 다른 Rollup 네트워크의 L1에 해당하는 DA 계약에 제출합니다.
d. 서로 다른 Rollup 네트워크는 L1의 DA 계약을 통해 네트워크의 최신 거래를 동기화한 다음, 자신의 Validity Proof 또는 Fraud Proof 검증 프로세스로 들어갑니다.

3.2. Shared Sequencer 구조의 잠재적 영향

1) 여러 Rollup 네트워크가 하나의 Shared Sequencer 위원회를 공유합니다.
2) 단일 Rollup의 관점에서 볼 때, 공식적으로 운영되는 Single Sequencer를 이 Shared Sequencer 위원회에 위임한 것에 불과합니다.
3) 매 라운드마다 Shared Sequencer 위원회에서 Sequencer Leader를 선택하여 이 Shared Sequencers 네트워크에 접속하는 Rollup Block을 구축하고, 이러한 Rollup Block을 Ethereum의 DA 계약에 제출합니다.
a. 예를 들어 A가 Arbitrum에서 USDC를 Optimism으로 크로스 체인하려고 할 때, 정상적인 프로세스는 Arbitrum에서 Lock을 먼저 수행하고 Lock이 성공한 후 Optimism에서 Arbitrum의 Lock Proof(예: Merkle Tree Path + Tree Root)를 제출한 다음 Optimism에서 해당 USDC 자산을 Mint하는 것입니다.
b. 사용자가 Shared Sequencers에 이러한 거래를 제출할 때, 매 라운드의 Sequencer Leader는 Arbitrum Lock 작업과 Optimism Mint 작업을 동시에 수행하는 Rollup Block에서 실행할 수 있습니다. 이는 사용자 경험을 크게 향상시킬 수 있습니다.
c. 그러나 여전히 동일한 Rollup 네트워크의 사용자 경험을 제공할 수는 없습니다. 예를 들어 Mint할 때 여전히 Lock Proof를 제공해야 합니다.
d. 따라서 우리는 이 Shared Sequencers 네트워크에 접속하는 Rollup들이 거의 완전한 동기화 시스템에 가깝다고 볼 수 있습니다.
e. 거의 완전한 동기화 시스템은 어떤 역할을 할까요?
f. 원자적 크로스 체인 서비스를 제공할 수 있습니다. 매 라운드에 선택된 Sequencer Leader는 모든 Rollup 거래를 정렬할 권한을 가지므로, 원자적 크로스 체인 거래를 구축할 수 있는 능력을 가지고 있습니다.

4) 크로스 체인 MEV 관점

매 라운드의 Leader Sequencer는 모든 Rollup Block의 정렬 권한을 가지므로 이론적으로 모든 크로스 체인 MEV를 포착할 수 있습니다. 이후 Shared Sequencer는 MEV Boost와 같은 MEV 구조를 도입하거나 직접 연결해야 할 것입니다. 현재 각 Rollup 네트워크의 블록 간격은 Ethereum의 블록 간격보다 훨씬 빠르기 때문입니다. 예를 들어 Optimism은 2초마다 블록을 생성하고, Arbitrum은 가장 빠르게 0.25초마다 블록을 생성합니다. 따라서 매 라운드의 Sequencer Leader가 Rollup Block을 구축하는 데 필요한 계산량은 결코 적지 않습니다. 따라서 생태계가 성숙해지면 최대 가치를 가진 Rollup Block을 구축하는 데 도움을 줄 수 있는 MEV 구조가 생길 것입니다.

5) 탈중앙화 및 생존성 관점에서 Shared Sequencers

Shared Sequencer 위원회 내부는 매 라운드마다 BFT 합의를 사용하여 Sequencer Leader를 선택하여 모든 Rollup Block을 제안하므로, 탈중앙화 및 생존성은 현재 Single Sequencer 솔루션보다 훨씬 강력합니다.

6) 생태계 관점에서

a. 서로 다른 Rollup은 더 나은 공존의 이유를 가지게 됩니다. 사용자는 다양한 Rollup 네트워크에서 자산을 쉽게 이동할 수 있으며, Ethereum 생태계의 부하 균형을 더 잘 실현할 수 있습니다.
b. 서로 다른 Shared Sequencer를 구축하는 프로젝트 간에는 생존 경쟁이 발생할 수 있습니다. 사용자 관점과 현재 모든 Rollup이 Single Sequencer인 관점에서 볼 때, Shared Sequencer 경로에서 승자가 모든 것을 차지하는 문제가 발생할 수 있습니다.

7) Finality 관점

본질적으로 여전히 Single Sequencer이므로, Sequencer Finality와 Verified Finality는 이전과 동일합니다.

3.3. 잠재적 위험

Rollup 간에 반드시 동형 Rollup이 아닐 수 있습니다. 예를 들어 Arbitrum과 polygon zkEVM 간의 크로스 체인 거래는 Arbitrum과 polygon zkEVM에서 거래의 Verified Finality가 일치하지 않을 수 있습니다. 예를 들어 Polygon zkEVM에서 mint 거래가 Verified Finality를 얻었지만(Validity Proof를 제출했지만), 이 시점에서 Arbitrum의 Lock 거래는 DA Finality만 얻었을 수 있습니다(7일의 도전 기간을 기다려야 함). 이때 Arbitrum 거래를 성공적으로 Revert하면, Polygon zkEVM에서 무비용으로 많은 크로스 체인 자산을 mint한 것이 됩니다.

3.4 요약

장점:

a. MEV는 Rollup 네트워크가 가져갈 수 있으며, 추가로 더 많은 크로스 체인 MEV를 얻을 수 있습니다.
b. 사용자 크로스 Rollup 경험이 좋으며, Rollup 간의 경쟁 관계를 공생 관계로 전환할 수 있습니다. 각 Rollup은 고유한 가치를 제공할 수 있으며, 다른 Rollup 네트워크와 결합하여 사용자에게 다양한 맞춤형 서비스를 제공하는 네트워크를 형성할 수 있습니다.
c. Single Sequencer에 비해 네트워크의 탈중앙화 정도가 크게 향상되었으며, 네트워크의 안정성이 크게 강화되었습니다. 특정 Sequencer Leader가 블록을 생성하지 않을 경우, 즉시 새로운 Sequencer Leader가 블록을 생성하도록 교체됩니다.
d. 네트워크의 세 가지 Finality는 이전 Single Sequencer와 일관성을 유지합니다. 단점: 본질적으로 여전히 Single Sequencer 모델이며, 새로운 공격 벡터가 도입되었습니다.

5. 요약

이번 글에서는 Polygon zkEVM의 Bridge와 Sequencer에 대한 더 많은 기술 세부 사항을 자세히 설명했습니다. 다음 글은 마지막 글로, zkEVM의 기술 세부 사항을 계속해서 해부할 예정이니 기대해 주시기 바랍니다.