Polygon zkEVM의 전체 아키텍처 및 거래 실행 프로세스 상세 설명

저자: 0xhhh（Twitter: @hhh69251498 ），Binary DAO

편집자: Red One

3월 27일, Polygon zkEVM 메인넷 테스트 버전이 공식 출시되었고, Vitalik은 그 위에서 첫 거래를 완료했습니다.

이 글은 Polygon zkEVM 시리즈 기사 중 첫 번째로, Polygon zkEVM의 전체 아키텍처와 거래 실행 프로세스를 간략히 설명하고, Polygon zkEVM이 어떻게 계산 확장을 구현하고 동시에 이더리움의 보안을 계승하는지를 분석합니다.

또한 다음 두 개의 기사에서 Polygon zkEVM의 zkEVM Bridge와 zkEVM의 설계 세부 사항, 그리고 Polygon zkEVM의 향후 탈중앙화 Sequencer 로드맵에 대해 자세히 소개할 것입니다.

1. Rollup은 이더리움의 계산 확장을 위해

먼저, Rollup의 대략적인 작동 원리를 명확히 할 필요가 있습니다. Rollup의 출현은 이더리움에 계산 확장을 구현하기 위한 것으로, 구체적인 구현 방법은 거래 실행을 Rollup에 아웃소싱하고, 거래와 거래 실행 후의 상태(State)를 이더리움의 계약 내에 저장하는 것입니다. 기술 경로의 차이로 인해 두 가지 유형의 Rollup이 발전했습니다:

Optimistic Rollup
이더리움에 전송된 Rollup 거래(Rollup Transaction)와 해당 Rollup 상태(Rollup State)가 모두 올바르다고 낙관적으로 가정하며, 누구나 사기 증명(Fraud Proof)을 제공하여 도전 기간 중의 Rollup 상태에 대해 이의를 제기할 수 있습니다(Challenge).

Zero-knowledge Rollup
ZK는 이더리움에 전송된 Rollup 거래와 해당 Rollup 상태에 대해 유효성 증명(이더리움의 계약에서 검증하여 Rollup 실행 후의 상태가 올바른지를 증명)을 제공합니다.

이더리움 공식 정의 참조:
https://ethereum.org/en/developers/docs/scaling/#rollups
Zero-knowledge Rollup과 Optimistic Rollup의 가장 큰 차이는 상태 유효성 검증 방식의 차이로 인해 최종성(Finality)에 도달하는 시간이 다르다는 것입니다;
Optimistic Rollup은 이더리움에 제출된 거래와 상태가 모두 올바르다고 낙관적으로 가정하므로 7일의 도전 기간이 존재합니다(최종성에 도달하는 시간은 7일입니다). 이 기간 동안 이더리움에서 거래에 해당하는 상태가 올바르지 않음을 발견한 누구나 올바른 상태를 제출하여 도전할 수 있습니다.
Zero-knowledge Rollup(zk-Rollup)의 최종성 도달 시간은 거래에 대한 유효성 증명(Validity Proof)이 이더리움에 제출되고 검증되는 데 소요되는 시간에 따라 달라집니다. 현재는 약 1시간 정도의 최종성이 일반적입니다(가스 비용 문제를 고려해야 하기 때문입니다).

2. Polygon zkEVM 실행 프로세스

다음으로, 간단한 거래 확인 프로세스를 통해 Polygon zkEVM이 어떻게 작동하는지 살펴보겠습니다. 전체 프로토콜에 대한 구체적인 이해를 위해 이 과정은 주로 세 단계로 나눌 수 있습니다:

1. Sequencer는 여러 사용자 거래를 패키지로 묶어 L1의 계약에 제출합니다;
2. Prover는 각 거래에 대해 유효성 증명(Validity Proof)을 생성하고, 여러 거래의 유효성 증명을 하나의 유효성 증명으로 집계합니다;
3. Aggregator는 여러 거래의 유효성 증명(Validity Proof)을 L1의 계약에 제출합니다.
   
4. Sequencer는 사용자 거래를 패키지로 묶어 L1 계약에 제출합니다.

1) 사용자는 거래를 Sequencer에 전송하고, Sequencer는 수신된 거래의 속도 순서에 따라 로컬에서 처리합니다(FRFS). Sequencer가 로컬에서 거래를 성공적으로 실행한 후, 사용자가 Sequencer가 정직하다고 믿는다면, 이 시점에서 거래가 최종성에 도달했다고 간주할 수 있습니다. 여기서 주의할 점은 현재 대부분의 Sequencer 내부 Mempool(거래 풀)은 비공식적이므로, 현재 얻을 수 있는 MEV는 비교적 적습니다.
2) Sequencer는 여러 거래를 하나의 배치에 묶습니다(현재는 하나의 배치에 하나의 거래만 포함됨) 그리고 여러 배치를 수집한 후, L1의 PolygonZKEvm.sol의 SequenceBatch() 함수를 통해 여러 배치를 함께 L1의 거래 Calldata에 전송합니다.

(여기서 여러 배치를 한 번에 제출하는 것은 L1의 가스 소비를 최대한 줄이기 위함입니다)

3) PolygonZkEvm.sol이 Sequencer가 제공한 배치를 수신하면, 계약 내에서 각 배치의 해시를 순차적으로 계산하고, 후속 배치에 이전 배치의 해시를 기록합니다. 따라서 아래 그림과 같은 배치 구조를 얻게 됩니다.

4) 각 배치 내의 거래 순서도 확정되어 있으므로, 배치의 순서가 확정되면, 우리는 배치에 포함되어 L1의 Polygon zkEVM 계약에 제출된 거래의 순서가 모두 확정되었다고 간주합니다.

위의 실제 과정은 L1이 Rollup DA 계층으로서 수행해야 하는 작업입니다(이때는 어떤 상태 검증이나 진행 작업도 완료되지 않았습니다).

2. Aggregator는 여러 배치의 거래에 대해 유효성 증명을 생성합니다.

1) Aggregator는 L1의 PolyonZKEVM.sol 계약에서 새로운 배치가 성공적으로 제출되었음을 감지하면, 이 배치를 자신의 노드에 동기화하고, zkProver에 이 거래를 전송합니다.
2) zkProver는 이 거래를 수신한 후, 각 거래에 대해 유효성 증명을 생성하고, 여러 배치에 포함된 거래의 유효성 증명을 집계하여 하나의 유효성 증명(Validity Proof)으로 만듭니다.

3) zkProver는 여러 거래의 유효성 증명을 Aggregator에 전송합니다.

3. Aggregator는 L1의 계약에 집계 증명을 제출합니다.

Aggregator는 이 유효성 증명(Validity Proof)과 해당 배치 실행 후의 상태를 함께 L1의 Polygon zkEvm.sol 계약에 제출하며, 다음 방법을 호출합니다:

계약 내에서는 상태 전환이 올바른지 검증하기 위해 다음 작업을 수행합니다.


이 단계가 L1 계약 내에서 성공적으로 실행되면, 이 배치에 포함된 모든 거래는 실제로 최종성에 도달하게 됩니다(해당 OP의 7일 도전 기간이 종료됨).

3. 이더리움이 Polygon-zkEVM에서 수행하는 역할

위에서 우리는 Polygon zkEVM의 전체 프로세스를 이해했으며, 이더리움이 Rollup을 위해 수행한 작업을 되짚어볼 수 있습니다:

첫 번째 단계, Sequencer는 Rollup 거래를 수집하여 배치로 묶은 후, L1 계약에 제출합니다. L1은 단순히 DA 계층의 기능을 제공하는 것이 아니라, 실제로 일부 거래 정렬 기능도 수행합니다; 거래를 Sequencer에 제출할 때 거래는 실제로 정렬되지 않으며, Sequencer는 거래 순서를 마음대로 변경할 수 있는 권한이 있지만, 거래가 배치에 포함되어 L1 계약에 제출된 후에는 누구도 거래 순서를 수정할 수 없습니다.

두 번째 단계, Aggregator는 유효성 증명을 L1 계약에 제출하여 새로운 상태에 도달하고, Aggregator는 Proposer와 유사한 역할을 하며, 계약은 Validator와 유사한 역할을 합니다; Aggregator는 새로운 상태가 올바르다는 것을 증명하기 위해 유효성 증명을 제공하고, Validator에게 내가 제공한 유효성 증명이 어떤 거래 배치와 관련이 있으며, 이들이 L1의 어느 위치에 존재하는지를 알려줍니다.

그 후 Validator는 계약에서 해당 배치를 추출하고, 유효성 증명과 결합하여 상태 전환의 합법성을 검증할 수 있으며, 검증이 성공하면 계약 내에서도 해당 유효성 증명에 대한 새로운 상태로 업데이트됩니다.

4. 모듈화 관점에서 Smart Contract Rollup 구조

모듈화 관점에서 보면, Polygon zkEVM은 Smart Contract Rollup 유형에 속하며, 우리는 그것의 각 모듈을 해체해 볼 수 있습니다. Delphi에서 제공한 그림에서, 실제로 Polygon ZkEVM은 Smart Contract Rollup의 합의 계층, DA 계층 및 결제 계층이 모두 PolygonZkEVM.sol 계약에 결합되어 있어 잘 구분할 수 없습니다. 그러나 우리는 각 모듈을 해체해 보려고 합니다:

데이터 가용성 계층(Data Availability Layer): Rollup 거래가 저장되는 곳으로, Polygon-zkEVM의 경우 Sequencer가 SequenceBatch() 방법을 호출할 때, 실제로 DA 계층에 거래 데이터를 제출하는 것을 포함합니다.

결제 계층(Settlement Layer): Rollup과 L1 간의 자금 흐름 메커니즘을 구체적으로 지칭하며, Polygon-zkEVM의 공식 브리지를 지칭합니다(다음 기사에서 자세히 소개될 예정입니다).

합의 계층(Consensus Layer): 거래 정렬 및 다음 합법적 상태를 결정하는 방법(분기 선택)을 포함합니다. Sequencer가 L1 계약의 SequenceBatch()를 호출할 때 거래 정렬 작업을 완료하고, Aggregator가 L1 계약의 TustedVerifyBatches()를 호출할 때 다음 합법적 상태 확인 작업을 완료합니다.

실행 계층(Execution Layer): 거래를 실행하고 새로운 세계 상태를 얻는 과정으로, 사용자가 Sequencer에 거래를 제출하고 Sequencer가 실행을 완료한 후 새로운 상태를 얻는 과정입니다(따라서 우리는 Rollup이 계산 확장이라고 자주 말합니다. L1이 거래 실행을 통해 새로운 상태를 얻는 이 과정을 Rollup에 아웃소싱하고, Sequencer는 Aggregator를 통해 zkProver에게 유효성 증명 생성을 위임합니다).

5. 왜 Polygon-zkEVM이 L1의 보안을 계승한다고 말하는가

위에서 설명한 전체 프로세스를 보면, 실제로 Sequencer는 이더리움 Proposer와 유사한 작업을 수행하여 유효한 거래 배치를 제안하고, 이 배치 거래 실행 후의 새로운 상태를 제공합니다; L1 계약의 검증 논리는 모든 L1 Validator가 자신의 이더리움 클라이언트에서 한 번 실행하는 것과 같으며, 실제로 모든 이더리움 검증자가 Rollup의 검증자로 작용하므로 우리는 Polygon zkEVM이 이더리움의 보안을 계승한다고 생각합니다.

또 다른 관점에서 보면, Rollup의 모든 거래 및 상태가 이더리움에 저장되므로, Polygon zkEVM 팀이 도망가더라도 누구나 이더리움에 저장된 데이터를 기반으로 전체 Rollup 네트워크를 복구할 수 있는 능력을 가지고 있습니다.

6. Polygon zkEVM 인센티브 메커니즘

Rollup 인센티브 메커니즘은 주로 Sequencer와 Aggregator가 이익을 얻어 지속적으로 작업을 유지할 수 있도록 하는 방법을 지칭합니다.

먼저 사용자는 Rollup에서 거래 수수료를 지불해야 하며, 이 수수료는 ETH로 계산되며, Bridged ETH로 지불됩니다.

Sequencer는 이러한 Rollup 거래가 포함된 배치를 L1 거래의 Calldata에 업로드하는 비용(SequenceBatch(batches() 호출 비용)을 지불해야 하며, 동시에 배치를 업로드할 때 일정량의 Matic을 L1 계약에 지불하여 이후 Aggregator가 이러한 배치에 대해 유효성 증명을 제공하는 비용을 지불해야 합니다.

Aggregator는 trusted VerifyBatches를 호출하여 L1 계약 내에서 아직 최종성에 도달하지 않은 배치에 유효성 증명을 제공하는 동시에, Sequencer가 계약 내에서 미리 지불한 MATIC 토큰을 인출하여 유효성 증명 제공에 대한 보상으로 사용할 수 있습니다.

Sequencer의 수익 = Rollup의 모든 거래 가스 비용 - 배치를 L1에 업로드하는 데 소요된 L1 네트워크 가스 비용 - Aggregator에 지급하는 증명 비용(MATIC 기준).

Aggregator의 수익 = Sequencer가 지급한 MATIC 보상 - L1에 유효성 증명을 제출하는 가스 비용 - 유효성 증명 생성에 소요되는 하드웨어 비용.

Aggregator에 지급하는 증명 비용을 조정하고, Sequencer가 이익이 없어서 작업을 중단하지 않도록 하기 위해, Sequencer가 Aggregator에 지급하는 증명 비용을 조정하기 위한 다음 메커니즘을 제공합니다.

계약 내에는 배치에 대한 증명 비용을 조정하기 위한 다음과 같은 방법이 존재합니다:

function _updateBatchFee(uint64 newLastVerifiedBatch) internal

이 방법은 계약 내의 BatchFee라는 변수를 변경하며, 이 변수는 Sequencer가 각 배치에 대해 지불하는 MATIC 토큰 수량을 결정합니다.

변경 메커니즘은 다음과 같습니다:

계약 내에는 VeryBatchTimeTarget이라는 변수를 유지하여, 각 배치가 Sequencer에 의해 L1에 제출된 후 이 시간 내에 상태가 검증되기를 기대합니다.

계약 내에서는 VeryBatchTimeTarget을 초과하여 아직 검증되지 않은 배치의 총 수를 기록하고, 이 배치의 총 수를 DiffBatches로 기록합니다.

따라서 배치가 지연될 경우, 다음 공식을 사용하여 BatchFee를 조정합니다:

MultiplierBatchFee는 1000~1024 범위로 제한된 수이며, 계약 관리자가 setMultiplierBatchFee() 함수를 통해 변경할 수 있습니다:

Function setMultiplierBatchFee (uint16 newMultiplierBatchFee) public onlyAdmin

여기서 MultiplierBatchFee와 10^3을 사용하는 것은 소수점 세 자리의 조정 정밀도를 구현하기 위함입니다.


마찬가지로 배치가 조기에 검증되면 해당 배치 비용 조정 메커니즘도 작동합니다: DiffBatches는 조기에 검증된 배치의 수를 나타냅니다.

요약

이 글에서는 Polygon zkEVM의 핵심 메커니즘을 정리하고, 이더리움의 계산 확장을 구현하는 가능성을 분석했습니다. 전체적인 개요를 갖춘 후, 다음 기사에서는 프로토콜 내부로 깊이 들어가 zkEVM Bridge의 설계 세부 사항과 Sequencer의 탈중앙화 경로, zkProver의 구현 및 zkEVM의 설계 원리를 차례로 분석할 것입니다.