작성자: 0xhhh (트위터: @hhh69251498 ), Binary DAO
편집자: Red One
3월 27일, Polygon zkEVM 메인넷 테스트 버전이 공식 출시되었고, Vitalik은 첫 번째 거래를 완료했습니다.
Polygon zkEVM에 대한 시리즈의 첫 번째 기사인 이 기사에서는 Polygon zkEVM의 전반적인 아키텍처와 트랜잭션 실행 프로세스를 간략하게 설명하고, Polygon zkEVM이 이더 의 보안을 계승하면서 어떻게 계산 확장성을 달성하는지 분석합니다.
동시에, 다음 두 기사에서는 Polygon zkEVM의 zkEVM Bridge와 zkEVM의 설계 세부 사항과 Polygon zkEVM의 후속 탈중앙화 시퀀서의 로드맵도 자세히 소개합니다.
1. 이더 컴퓨팅 용량 확장을 위한 롤업
먼저 Rollup의 일반적인 작동 원리를 이해해야 합니다. Rollup은 이더리움의 연산 능력을 확장하기 위해 개발되었습니다. 구체적으로, Rollup은 트랜잭션 실행을 Rollup에 아웃소싱하고 트랜잭션과 실행 후 상태를 이더리움 컨트랙트에 저장합니다. 서로 다른 기술적 접근 방식으로 인해 두 가지 유형의 Rollup이 발전했습니다.
낙관적 롤업
이더리움에 전송된 롤업 트랜잭션(Rollup Transaction)과 해당 롤업 상태(Rollup State)는 정확하다고 낙관적으로 믿고 있으며, 사기 증명(Fraud Proof)을 제공하여 아직 이의 제기 기간 내에 있는 롤업 상태에 대해 누구나 이의를 제기(Challenge)할 수 있습니다.
제로 지식 롤업
ZK는 Rollup 거래와 해당 Rollup 상태에 대한 유효성 증명을 Ethereum에 전송합니다(해당 거래를 실행한 후 Rollup 상태가 올바르다는 것을 증명하기 위해 이더 의 계약을 통해 검증됨).
이더 의 공식 정의를 참조하세요.
https://ethereum.org/en/developers/docs/scaling/#롤업
제로 지식 롤업과 낙관적 롤업의 가장 큰 차이점은 상태 유효성을 검증하는 방법이 다르다는 점이며, 이로 인해 확정에 도달하는 데 걸리는 시간도 다릅니다.
Optimistic Rollup은 이더리움에 제출된 거래 및 상태가 정확하다고 낙관적으로 판단하여 7일의 이의 제기 기간(Finity 도달까지 7일)을 둡니다. 이 기간 동안 이더리움 거래의 해당 상태가 정확하지 않다고 판단하는 사람은 누구나 정확한 상태를 제출하여 이의를 제기할 수 있습니다.
영지식 롤업(zk-Rollup)이 최종 완료에 도달하는 데 걸리는 시간은 해당 거래의 유효성 증명이 이더 에 제출되고 검증되는 데 걸리는 시간에 따라 달라집니다. 현재 최종 완료는 가스 비용 때문에 약 1시간 정도 소요될 것으로 예상됩니다.
2. 폴리곤 zkEVM 실행 프로세스
다음으로, Polygon zkEVM이 간단한 거래 확인 프로세스를 통해 전체 프로토콜을 더욱 자세히 이해하는 방법을 살펴보겠습니다. 전체 프로세스는 세 가지 주요 단계로 나눌 수 있습니다.
1. 시퀀서는 여러 사용자 거래를 일괄 처리하여 L1 계약에 제출합니다.
2. 증명자는 각 거래에 대한 유효성 증명을 생성하고 여러 거래의 유효성 증명을 하나의 유효성 증명으로 집계합니다.
3. 집계자는 여러 거래의 유효성 증명(Validity Proof)을 집계하여 L1 계약에 제출합니다.
1. 시퀀서는 사용자 트랜잭션을 일괄 처리하여 L1 계약에 제출합니다.
1) 사용자가 트랜잭션을 시퀀서로 전송하면 시퀀서는 수신된 순서대로 로컬에서 처리합니다(FRFS). 시퀀서가 로컬에서 트랜잭션을 성공적으로 실행하고, 사용자가 시퀀서의 정직성을 신뢰하면 해당 트랜잭션은 최종 트랜잭션으로 간주됩니다. 대부분의 시퀀서에 있는 메모리풀(트랜잭션 풀)은 현재 비공개 상태이므로 사용 가능한 MEV의 양이 상대적으로 적다는 점에 유의해야 합니다.
2) 시퀀서는 여러 트랜잭션을 하나의 배치로 묶습니다(현재 배치는 하나의 트랜잭션만 포함합니다). 여러 배치를 수집한 후, L1에 있는 PolygonZKEvm.sol의 SequenceBatch 함수를 통해 배치들을 L1의 트랜잭션 calldata로 함께 전송합니다.
(여러 배치를 동시에 제출하는 것은 L1 가스 소모를 최소화하기 위한 것입니다)
3) PolygonZkEvm.sol이 Sequencer에서 제공한 배치를 받으면 계약 내에서 각 배치의 해시를 차례로 계산한 다음 이전 배치의 해시를 다음 배치에 기록하여 아래에 표시된 배치 구조를 생성합니다.
4) 각 배치의 거래 순서도 결정되므로, 배치의 순서가 결정되면 L1의 Polygon zkEVM 계약에 제출된 배치에 포함된 모든 거래의 순서도 결정된다고 믿습니다.
위의 실제 프로세스는 Rollup DA 계층으로서 L1이 완료해야 하는 작업이기도 합니다(현재 상태 검증이나 진행 작업은 완료되지 않았습니다).
2. 집계자는 여러 배치 거래에 대한 유효성 증명을 생성합니다.
1) 집계자가 L1의 PolyonZKEVM.sol 계약에 새로운 배치가 성공적으로 제출되었음을 감지하면 이러한 배치를 자체 노드와 동기화한 다음 이러한 트랜잭션을 zkProver로 전송합니다.
2) 이러한 거래를 수신한 후 zkProver는 각 거래에 대한 유효성 증명을 병렬로 생성한 다음 여러 배치에 포함된 거래의 유효성 증명을 단일 유효성 증명으로 집계합니다.
3) zkProver는 여러 개의 집계된 거래의 유효성 증명을 Aggregator에게 전송합니다.
3. 집계자가 L1 계약에 집계 증명을 제출합니다.
집계자는 다음 메서드를 호출하여 L1의 Polygon zkEvm.sol 계약에 유효성 증명과 해당 배치 실행 상태를 제출합니다.
그런 다음 계약은 상태 전환이 올바른지 확인하기 위해 다음 작업을 수행합니다.
L1 계약에서 이 단계가 성공적으로 실행되면 이 배치에 포함된 모든 거래가 실제로 확정(OP의 7일 챌린지 기간 종료에 해당)에 도달하게 됩니다.
3. Polygon-zkEVM에서 Ethereum의 역할
이제 Polygon zkEVM 프로세스 전반을 살펴보았으니 Ethereum이 Rollup을 위해 수행하는 작업을 살펴보겠습니다.
첫 번째 단계에서 시퀀서는 롤업 트랜잭션을 일괄 처리하여 L1 계약에 제출합니다. L1은 DA 계층을 제공할 뿐만 아니라 일부 트랜잭션 순서 도 수행합니다. 트랜잭션이 시퀀서에 제출될 때, 시퀀서는 트랜잭션 순서를 임의로 변경할 수 있으므로 실제로 순서가 정해지지는 않습니다. 그러나 트랜잭션이 일괄 처리에 포함되어 L1 계약에 제출되면 누구도 트랜잭션 순서를 수정할 권리가 없습니다.
두 번째 단계에서 집계자는 유효성 증명을 L1 계약에 제출하여 새로운 상태를 얻습니다. 집계자는 제안자와 유사한 역할을 하며, 계약은 검증자와 유사한 역할을 합니다. 집계자는 새로운 상태가 정확함을 증명하는 유효성 증명을 제공하고, 검증자에게 제공된 유효성 증명에 포함된 트랜잭션 배치와 L1의 저장 위치를 알려줍니다.
그런 다음 검증자는 계약에서 해당 배치를 클레임 이를 유효성 증명과 결합하여 상태 전환의 적법성을 검증합니다. 검증이 성공하면 계약은 유효성 증명에 해당하는 새로운 상태로 실제로 업데이트됩니다.
4. 모듈 형 관점에서 스마트 계약 롤업 구조화
모듈 관점에서 Polygon zkEVM은 스마트 컨트랙트 롤업 유형에 속합니다. 다양한 모듈 분해해 볼 수 있습니다. Delphi에서 제공하는 다이어그램을 보면 Polygon ZkEVM이 실제로 스마트 컨트랙트 롤업의 합의 계층임을 알 수 있습니다. DA 계층과 정산 계층은 실제로 PolygonZkEVM.sol 컨트랙트에 연결되어 있어 명확하게 구분할 수 없습니다. 하지만 다양한 모듈 분해해 보겠습니다.
데이터 가용성 계층: 롤업 트랜잭션이 저장되는 곳입니다. Polygon-zkEVM의 경우, 시퀀서가 SequenceBatch 메서드를 호출하면 실제로 트랜잭션 데이터를 데이터 가용성 계층에 제출합니다.
결제 계층: 구체적으로 Rollup과 L1 간의 자금 흐름 메커니즘, 구체적으로는 Polygon-zkEVM의 공식 브리지를 말합니다(다음 기사에서 자세히 소개하겠습니다).
컨센서스 레이어: 이 계층은 트랜잭션 순서 및 다음 합법적 상태(포크 선택)를 결정합니다. 시퀀서는 L1 계약에서 SequenceBatch를 호출하여 트랜잭션 순서 완료하고, 애그리게이터는 L1 계약에서 TustedVerifyBatches를 호출하여 다음 합법적 상태의 확인을 완료합니다.
실행 계층: 트랜잭션을 실행하고 새로운 상태(World State)를 얻습니다. 사용자가 시퀀서에 트랜잭션을 제출하면 시퀀서가 해당 트랜잭션을 실행하고 새로운 상태를 얻는 과정입니다. (이것이 바로 Rollup을 연산 확장이라고 부르는 이유입니다. L1이 트랜잭션 실행 및 새로운 상태 획득 과정을 Rollup에 아웃소싱하기 때문입니다. 동시에, 시퀀서는 Aggregator를 통해 zkProver에 유효성 증명 생성을 위임합니다.)
5. Polygon-zkEVM이 L1의 보안을 계승하는 이유
위에서 설명한 전체 프로세스를 통해, 시퀀서는 실제로 이더 제안자와 유사한 작업을 수행합니다. 즉, 일련의 거래를 유효한 거래로 제안하고 해당 거래 실행 후 새로운 상태를 제시합니다. L1 계약 검증 로직은 모든 L1 검증자가 각자의 이더 클라이언트에서 실행되는 것과 같습니다. 실제로 모든 이더 검증자는 롤업 검증자 역할을 합니다. 따라서 Polygon zkEVM은 이더 의 보안을 계승한다고 생각합니다.
다른 관점에서 보면, 모든 Rollup 거래와 상태가 이더 에 저장되기 때문에 Polygon zkEVM 팀이 도망가더라도 누구나 이더 에 저장된 데이터를 기반으로 전체 Rollup 네트워크를 복구할 수 있습니다.
6. 폴리곤 zkEVM 인센티브 메커니즘
롤업 인센티브 메커니즘은 주로 시퀀서와 애그리게이터가 지속적으로 작업을 수행할 수 있도록 수익성을 높이는 방법을 말합니다.
먼저, 사용자는 Rollup에서 거래 수수료를 지불해야 합니다. 이 수수료는 ETH로 표시되며 Bridged ETH로 지불됩니다.
시퀀서는 롤업 트랜잭션이 포함된 이러한 배치를 L1 트랜잭션의 Calldata에 업로드하는 비용(SequenceBatch(배치) 호출 비용)을 지불해야 합니다. 동시에, 배치 업로드 시 L1 계약에 일정 금액의 Matic을 지불해야 하며, 이는 애그리게이터가 이러한 배치에 대한 유효성 증명을 제공하는 데 드는 비용으로 사용됩니다.
집계자가 아직 완료되지 않은 L1 계약의 배치에 대한 유효성 증명을 제공하기 위해 trustedVerifyBatches를 호출하는 경우, 유효성 증명 제공에 대한 보상으로 계약에서 시퀀서가 미리 지불한 MATIC 토큰을 인출할 수도 있습니다.
시퀀서의 수입 = 모든 롤업 거래의 가스 수수료 - L1 네트워크 배치를 L1에 업로드하는 데 사용된 가스 수수료 - 집계자에게 지불된 증명 수수료(MATIC으로 표시).
집계 수입 = 시퀀서가 지불한 MATIC 보상 - L1에 대한 유효성 증명에 제출된 가스 수수료 - 유효성 증명 생성에 사용된 하드웨어 수수료.
애그리게이터에 지급되는 증명 수수료를 조정합니다. 시퀀서가 수익성 저하로 인해 파업에 돌입하는 것을 방지하기 위해, 시퀀서가 애그리게이터에 지급하는 증명 수수료를 조정하는 다음과 같은 메커니즘이 제공됩니다.
배치 증명 제공에 대한 수수료를 조정하는 방법은 계약서에 있습니다.
함수 _updateBatchFee(uint64 newLastVerifiedBatch) 내부
이는 BatchFee라는 계약의 변수를 변경하는데, 이 변수는 Sequencer가 각 배치에 대해 지불하는 MATIC 토큰의 수를 결정합니다.
변경 메커니즘은 다음과 같습니다.
계약은 VeryBatchTimeTarget이라는 변수를 유지하는데, 이는 Sequencer가 각 배치를 L1에 제출한 후 이 시간 내에 예상되는 검증 상태를 나타냅니다.
계약서는 VeryBatchTimeTarget을 초과한 후에도 검증되지 않은 모든 배치를 기록하고, 이러한 배치의 총 수는 DiffBatches로 기록됩니다.
따라서 배치가 늦어지면 배치 수수료는 다음 공식을 사용하여 조정됩니다.
MultiplierBatchFee는 1000~1024 범위로 제한된 숫자이며 계약 관리자가 setMultiplierBatchFee 함수를 통해 변경할 수 있습니다.
함수 setMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin
여기서 MultiplierBatchFee와 10^3은 소수점 3자리 이하의 조정 정확도를 달성하기 위해 사용된다는 점에 유의하세요.
마찬가지로, 배치가 진행되면 해당 배치 수수료 조정 메커니즘이 트리거됩니다. DiffBatches는 고급 검증 상태의 배치 수를 나타냅니다.
요약하다
이 글에서는 Polygon zkEVM의 핵심 메커니즘을 간략하게 살펴보고 이더 연산 용량 확장 가능성을 분석했습니다. 이러한 전반적인 개요를 바탕으로, 다음 글에서는 프로토콜을 심층적으로 살펴보고 zkEVM Bridge의 설계 세부 사항, Sequencer의 탈중앙화 접근 방식, zkProver의 구현, 그리고 zkEVM의 설계 원칙을 분석해 보겠습니다.
