Phân tích hệ thống blockchain layer 2 sử dụng ZK

Introduction

Thiết kế tổng thể của Polygon zkEVM tuân theo mô hình Máy trạng thái và do đó mô phỏng Máy ảo Ethereum (EVM) , với mục đích cung cấp trải nghiệm người dùng giống như trong Ethereum. Ngoài việc cho phép thanh toán và chuyển mã thông báo ERC20, giờ đây người dùng có thể chạy các hợp đồng thông minh Ethereum trên đó.

Chiến lược tổng hợp là phát triển một zkProver thực hiện một loạt nhiều giao dịch, chứng minh tính hợp lệ của chúng và chỉ xuất bản bằng chứng hợp lệ có kích thước tối thiểu để xác minh. Điều này giúp giảm thời gian hoàn tất giao dịch và tiết kiệm chi phí gas cho người dùng Ethereum.

Tuy nhiên, zkEVM không chỉ là một bản tổng hợp mà còn là một bản tổng hợp không có kiến thức. Thiết kế của nó tận dụng các kỹ thuật nổi tiếng nhất trong văn hóa dân gian ZK, đồng thời giới thiệu các công cụ ZK mới lạ. Một ví dụ về các công cụ như vậy là Ngôn ngữ nhận dạng đa thức (PIL) mới, đóng vai trò then chốt trong việc cho phép zkProver tạo ra các bằng chứng có thể kiểm chứng.

Các máy trạng thái phù hợp nhất cho các tính toán xác định lặp đi lặp lại, vốn phổ biến trong Ethereum. Ngược lại, các mạch số học sẽ cần các vòng lặp không được kiểm soát, và do đó dẫn đến các mạch lớn hơn không mong muốn.

Definition of success

• Thiết kế kiến trúc của một blockchain layer 2 sử dụng phương pháp zkrollup để xác minh giao dịch
• Các thành phần của một blockchain hoàn chỉnh

Requirement

• Tương thích với các ứng dụng, nền tảng, công nghệ … đang hoạt động với mạng lưới ethereum (Block, evm)
• Khả năng mở rộng tốc độ tính toán, xác thực giao dịch, xây dựng bằng chứng. Thời gian tạo 1 batch được tối ưu tuỳ theo thông lượng mạng của layer 2 (Nếu mà số lượng giao dịch/ giây tăng thì cần giảm thời gian block)
• Data availablity: dữ liệu được lưu off-chain, bằng chứng lưu on-chain, có thể lưu transaction information thông qua call-data
• Tối ưu chi phí và kích thước lưu trữ on-chain thông qua việc giảm kích thước bằng chứng, lưu data trong call-data
• Hệ thống hướng tới decentralized các component nhiều nhất có thể như: Sequencer, Prover …

Phương pháp tiếp cận

Cách tiếp cận chung để thiết kế zkProver nhằm hiện thực hóa một hệ thống bằng chứng dựa trên State Machines như sau:

1. Biến tính toán xác định cần thiết thành tính toán máy trạng thái .
2. Mô tả các chuyển đổi trạng thái theo các ràng buộc đại số . Đây giống như các quy tắc mà mọi chuyển đổi trạng thái phải đáp ứng.
3. Sử dụng phép nội suy các giá trị trạng thái để xây dựng các đa thức mô tả máy trạng thái.
4. Xác định danh tính đa thức mà tất cả các giá trị trạng thái phải đáp ứng.
5. Một hệ thống chứng minh bằng mật mã được thiết kế đặc biệt (ví dụ: STARK, SNARK hoặc kết hợp cả hai) được sử dụng để tạo ra bằng chứng có thể kiểm chứng mà bất kỳ ai cũng có thể xác minh.

Design the system

System Overview

Tương tự như các blockchain khác, hệ thống sẽ gồm các thành phần chính của 1 blockchain thông thường. Sự khác biệt ở layer 2 sẽ là việc tính toán của hợp đồng thông minh sẽ được xử lý off-chain bằng các máy móc chuyên dụng nhằm nâng cao tốc độ xử lý, kết quả tính toán sẽ được xác minh bằng một thuật toán riêng và được lưu lại trên layer 1.

Hệ thống sẽ bao gồm

• Smart contract
• Storage
• EVM
• Node

Component diagram

• Hệ thống sẽ bao gồm các component chính:
  • Node
    • Sequencer
    • Prover
    • RPC
    • Verifier
  • Bridge
  • Storage
  • ZK SNARK/STARK
  • Synchronizer

Component detail diagram

ZkProver

Việc chứng minh và xác minh các giao dịch trong Polygon zkEVM đều được xử lý bởi một thành phần chứng minh không có kiến thức gọi là zkProver. Tất cả các quy tắc để một giao dịch hợp lệ được triển khai và thực thi trong zkProver. Prover dựa vào các giao dịch cần xử lý, state của mạng lưới để tính toán ra proof. zkProver chủ yếu tương tác với hai thành phần, tức là Nút và Cơ sở dữ liệu (DB). Do đó, trước khi tìm hiểu sâu hơn về các thành phần khác, chúng ta phải hiểu luồng điều khiển giữa zkProver, Nút và Cơ sở dữ liệu. Đây là một sơ đồ để giải thích quá trình rõ ràng.

• Prover execute input data, calculate result state and generate proof. It calls the Stark component to generate a proof of the Executor state machine commited polynomials.

Aggregator

The Aggregator client connect to Aggregator server, call Prover to generate the proof of the calculation

Executor

Executors execute input data and calculate result state but not generate proof, provide fast way to check the proposed batch is properly built and fit the amount of work that can be proven in one single batch.

StateDB

StateDB provide a single source of state, store the state of system and database

L2 State

Thiết kế cập nhật L2 State theo thời gian để trạng thái luôn được đồng bộ đúng nhất theo thời gian. Có ba giai đoạn của Trạng thái L2, mỗi giai đoạn tương ứng với ba cách khác nhau mà các nút L2 có thể cập nhật trạng thái của chúng. Cả ba trường hợp đều phụ thuộc vào định dạng của dữ liệu lô được sử dụng để cập nhật Trạng thái L2.

Trong trường hợp đầu tiên , bản cập nhật chỉ được thông báo bằng thông tin (nghĩa là Lô bao gồm các giao dịch đã đặt hàng) đến trực tiếp từ Trusted Sequencer, trước khi có bất kỳ dữ liệu nào trên L1. Trạng thái L2 kết quả được gọi là Trạng thái đáng tin cậy .

Trong trường hợp thứ hai , bản cập nhật dựa trên thông tin được các nút L2 lấy từ mạng L1 . Đó là, sau khi các lô đã được giải trình tự và dữ liệu đã được cung cấp trên L1. Trạng thái L2 được gọi là Trạng thái ảo tại thời điểm này.

Thông tin được sử dụng để cập nhật Trạng thái L2 trong trường hợp cuối cùng bao gồm các bằng chứng không kiến thức đã được xác minh về tính toàn vẹn tính toán. Nghĩa là, sau khi bằng chứng Zero-Knowledge đã được xác minh thành công trong L1, các nút L2 đồng bộ hóa gốc Trạng thái L2 cục bộ của chúng với gốc được cam kết trong L1 bởi Bộ tổng hợp đáng tin cậy. Kết quả là, Trạng thái L2 như vậy được gọi là Trạng thái Hợp nhất .

State machine

Hệ thống sử dụng các state machine để sinh ra

• Main state machine executor

• Secondary state machine

  (a) Binary SM

  (b) Memory SM

  (c) Storage SM

  (d) Poseidon SM

  (e) Keccak SM

  (f) Arithmetic SM

Sequencer

Trusted Sequencer tạo ra các lô, nhưng để đạt được kết quả nhanh chóng của các giao dịch L2 và tránh phải đợi khối L1 tiếp theo, chúng được chia sẻ với các nút mạng L2 thông qua một kênh truyền phát. Mỗi nút sẽ chạy các lô để tính toán Trạng thái L2 kết quả cục bộ.

Khi Trusted Sequencer đã cam kết các chuỗi lô được tìm nạp trực tiếp từ L1, các nút mạng L2 sẽ thực thi lại chúng và chúng sẽ không còn phải tin tưởng vào nó nữa.

Việc thực thi các lô ngoài chuỗi cuối cùng sẽ được xác minh trên chuỗi thông qua bằng chứng Zero-Knowledge và gốc trạng thái L2 kết quả sẽ được cam kết. Khi giao thức zkEVM tiến triển, các gốc trạng thái L2 mới sẽ được đồng bộ hóa trực tiếp từ L1 bởi các nút mạng L2.

Bridge diagram

Bridge có nhiệm vụ nhận và xử lý các yêu cầu chuyển thông tin xuyên các mạng blockchain khác nhau. Ví dụ người dùng muốn gửi ETH từ mạng Ethereum sang blockchain layer 2, người dùng sẽ gửi yêu cầu đến smart contract trên ethereum hoặc smart contract trên layer 2, Aggregator sẽ lắng nghe các events được đăng ký trước để xử lý. Bạn có thể theo dõi diagram bên dưới:

• Bridge client create request deposit or claim to ethereum or zkEVM node (layer 2) to start transfer token
• The Aggregator will sync events with Ethereum and store bridge event to Bridge DB and update Merkle tree root
• The zkEVM node sync bridge event with Aggregator

RPC diagram

Node diagram

Một node sẽ bao gồm tất cả các thành phần như chúng ta đã trình bày ở trên. Các thành phần sẽ được khởi động và chạy đồng thời như một thể thống nhất.

The diagram represents the main components of the software and how they interact between them. Note that this reflects a single entity running a node, in particular a node that acts as the trusted sequencer. But there are many entities running nodes in the network, and each of these entities can perform different roles. More on this later.

• (JSON) RPC: an interface that allows users (metamask, etherscan, ...) to interact with the node. Fully compatible with Ethereum RPC + some extra endpoints specifics of the network. It interacts with the state to get data and process transactions and with the pool to store transactions
• Pool: DB that stores transactions by the RPC to be selected/discarded by the sequencer later on
• Trusted Sequencer: get transactions from the pool, check if they are valid by processing them using the state, and create sequences. Once transactions are added into the state, they are immediately available to the broadcastservice. Sequences are sent to L1 using the etherman
• Broadcast: API used by the synchronizer of nodes that are not the trusted sequencer to synchronize the trusted state
• Permissionless Sequencer: coming soon
• Etherman: abstraction that implements the needed methods to interact with the Ethereum network and the relevant smart contracts.
• Synchronizer: Updates the state by fetching data from Ethereum through the etherman. If the node is not a trusted sequencer it also updates the state with the data fetched from the broadcast of the trusted sequencer. It also detects and handles reorgs that can happen if the trusted sequencer sends different data in the broadcast vs the sequences sent to L1 (trusted vs virtual state)
• State: Responsible for managing the state data (batches, blocks, transactions, ...) that is stored on the state SB. It also handles the integration with the executor and the Merkletree service
• State DB: persistence layer for the state data (except the Merkletree that is handled by the Merkletree service)
• Aggregator: consolidates batches by generating ZKPs (Zero Knowledge proofs). To do so it gathers the necessary data that the prover needs as input through the state and sends a request to it. Once the proof is generated it's sent to Ethereum through the etherman
• Prover/Executor: service that generates ZK proofs. Note that this component is not implemented in this repository, and it's treated as a "black box" from the perspective of the node. The prover/executor has two implementations: JS reference implementation and C production-ready implementation. Although it's the same software/service, it has two very different purposes:
  • Provide an EVM implementation that allows processing transactions and getting all needed results metadata (state root, receipts, logs, ...)
  • Generate ZKPs
• Merkletree: service that stores the Merkletree, containing all the account information (balances, nonces, smart contract code, and smart contract storage). This component is also not implemented in this repo and is consumed as an external service by the node. The implementation can be found here

Smart contract:

Các smart contract để xử lý xác minh bằng chứng ở layer 2 trên layer 1, chuyển tài sản giữa các layer, lưu trữ bằng chứng và root markle tree

• Smart contract Bridge.sol:

  Các hàm chính:

  • bridgeAsset: Chuyển token từ L1 sang L2, thêm lá vào merkle tree, emit event
  • bridgeMessage: Chuyển message dạng bytes có thể execute
  • claimAssert: verify merkle proof and withdraw tokens/ether
  • claimMessage: Verify merkle proof and execute message

• Smart contract GlobalExitRoot.sol

  • updateExitRoot: Update the exit root of one of the networks and the global exit root
  • getLastGlobalExitRoot: Return last global exit root

• Smart contract GlobalExitRootL2.sol

  • updateExitRoot: Update the exit root of one of the networks and the global exit root

• Smart contract zkEVM.sol

  • sequenceBatches: Allows a sequencer to send multiple batches
  • verifyBatches: Allows an aggregator to verify multiple batches
  • trustedVerifyBatches: Allows an aggregator to verify multiple batches
  • sequenceForceBatches: Allows anyone to sequence forced Batches if the trusted sequencer do not have done it in the timeout period

Transaction Flow

• Submit transaction

Các giao dịch trong mạng zkEVM được tạo trong ví của người dùng và được ký bằng khóa riêng của họ.

Sau khi được tạo và ký, các giao dịch được gửi đến nút của Trình sắp xếp thứ tự đáng tin cậy thông qua giao diện JSON-RPC của chúng . Sau đó, các giao dịch được lưu trữ trong nhóm giao dịch đang chờ xử lý , nơi chúng chờ lựa chọn của Trình sắp xếp thứ tự để thực hiện hoặc loại bỏ.

Người dùng và zkEVM giao tiếp bằng JSON-RPC, hoàn toàn tương thích với Ethereum RPC . Cách tiếp cận này cho phép mọi ứng dụng tương thích với EVM, chẳng hạn như phần mềm ví, hoạt động và có cảm giác giống như người dùng mạng Ethereum thực tế.

Giao dịch và Khối trên zkEVM

Trong thiết kế hiện tại, một giao dịch đơn lẻ tương đương với một khối .

Chiến lược thiết kế này không chỉ cải thiện giao tiếp RPC và P2P giữa các nút mà còn tăng cường khả năng tương thích với công cụ hiện có và tạo điều kiện hoàn thiện nhanh chóng trong L2. Nó cũng đơn giản hóa quá trình định vị các giao dịch của người dùng.

• Execute transaction

Trusted Sequencer đọc các giao dịch từ nhóm và quyết định xem có hủy chúng hay đặt hàng và thực hiện chúng hay không. Các giao dịch đã được thực hiện sẽ được thêm vào một đợt giao dịch và Trạng thái L2 cục bộ của Trình sắp xếp thứ tự được cập nhật.

Sau khi một giao dịch được thêm vào Trạng thái L2, nó sẽ được phát tới tất cả các nút zkEVM khác thông qua dịch vụ quảng bá. Điều đáng chú ý là bằng cách dựa vào Trusted Sequencer, chúng tôi có thể đạt được giao dịch cuối cùng nhanh chóng (nhanh hơn trong L1) . Tuy nhiên, Trạng thái L2 kết quả sẽ ở trạng thái đáng tin cậy cho đến khi lô được cam kết trong Hợp đồng đồng thuận.

• batch transaction

Trusted Sequencer phải thực hiện hàng loạt các giao dịch bằng cách sử dụng như sau BatchDatacấu trúc được chỉ định trong PolygonZkEVM.solhợp đồng:

struct BatchData {
  bytes transactions;
  bytes32 globalExitRoot;
  uint64 timestamp;
  uint64 minForcedTimestamp;
}

transactions

Đây là các mảng byte chứa các giao dịch lô được nối.

Mỗi giao dịch được mã hóa theo định dạng Ethereum pre-EIP-115 hoặc EIP-115 sử dụng tiêu chuẩn RLP (Recursive-length prefix) , nhưng các giá trị chữ ký, v, rVà s, được nối như hình bên dưới;

1. EIP-155:

• Batch sequencing

Các lô cần được giải trình tự và xác thực trước khi chúng có thể trở thành một phần của Trạng thái ảo L2.

Trusted Sequencer đã thêm thành công một lô vào một chuỗi các lô bằng cách sử dụng L1 PolygonZkEVM.sol hợp đồng sequencedBatchesánh xạ, về cơ bản là một cấu trúc lưu trữ chứa hàng đợi của các trình tự xác định Trạng thái ảo .

// SequenceBatchNum --> SequencedBatchData
mapping(uint64 => SequencedBatchData)public sequencedBatches;

Các lô phải là một phần của mảng các lô được sắp xếp theo trình tự. Trusted Sequencer gọi Hợp đồng PolygonZkEVM.sol , hợp đồng này sử dụng sequenceBatchesánh xạ, chấp nhận một mảng các đợt được sắp xếp theo thứ tự làm đối số. Vui lòng xem đoạn mã được cung cấp bên dưới.

function sequenceBatches ( 
    BatchData[] memory batches
) public ifNotEmergencyState onlyTrustedSequencer

Giới hạn kích thước lô tối đa và tối thiểu

Hằng số công khai của hợp đồng, MAX TRANSACTIONS BYTE LENGTH , xác định số lượng giao dịch tối đa có thể được bao gồm trong một đợt (300000).

Tương tự, số lô trong một chuỗi bị giới hạn bởi hằng số công khai MAX VERIFY BATCHES (1000) của hợp đồng. Mảng lô phải chứa ít nhất một lô và không nhiều hơn giá trị của hằng số MAX VERIFY BATCHES .

Chỉ tài khoản Ethereum của Trusted Sequencer mới có thể truy cập vào sequencedBatcheslập bản đồ. Điều cần thiết là hợp đồng không ở trong tình trạng khẩn cấp.

Cuộc gọi chức năng sẽ được hoàn nguyên nếu các điều kiện trên không được đáp ứng .

Hiệu lực lô & Tính toàn vẹn trạng thái L2

Các sequencedBatcheschức năng lặp qua mỗi lô của chuỗi, kiểm tra tính hợp lệ của nó. Một lô hợp lệ phải đáp ứng các tiêu chí sau:

• Nó phải bao gồm một globalExitRootGlobalExitRootMap PolygonZkEVMGlobalExitRoot.solMột lô chỉ hợp lệ nếu nó bao gồm một hợp lệ globalExitRoot.

  giá trị có trong

  của cầu L1

  hợp đồng.

• Độ dài của mảng byte giao dịch phải nhỏ hơn giá trị của hằng số MAX_TRANSACTIONS_BYTE_LENGTH

• Dấu thời gian của lô phải lớn hơn hoặc bằng dấu thời gian của lô cuối cùng được giải trình tự, nhưng nhỏ hơn hoặc bằng dấu thời gian của khối thực hiện giao dịch L1 theo trình tự. Tất cả các lô phải được đặt hàng theo thời gian

Nếu một lô không hợp lệ, giao dịch sẽ hoàn nguyên, loại bỏ toàn bộ chuỗi. Mặt khác, nếu tất cả các lô được giải trình tự đều hợp lệ, quá trình giải trình tự sẽ tiếp tục.

Một biến lưu trữ được gọi là lastBatchSequencedđược sử dụng làm bộ đếm lô và do đó, nó được tăng lên mỗi khi một lô được giải trình tự. Nó cung cấp một số chỉ mục cụ thể cho từng lô sẽ được sử dụng làm giá trị vị trí trong chuỗi lô.

Cơ chế băm tương tự được sử dụng trong các chuỗi khối để liên kết một khối với khối tiếp theo được sử dụng theo lô để đảm bảo tính toàn vẹn về mật mã của chuỗi lô. Nghĩa là, bao gồm thông báo tổng hợp của đợt trước trong số dữ liệu được sử dụng để tính toán thông báo tổng hợp của đợt tiếp theo.

Do đó, thông báo của một lô nhất định là hàm băm tích lũy của tất cả các lô đã giải trình tự trước đó , do đó có tên hàm băm tích lũy của một lô, được biểu thị bằng oldAccInputHashcho người già và newAccInputHashcho cái mới.

• Batch aggregation

Flow diagram

Referral

• https://docs.hermez.io/zkEVM/Overview/Overview/#zkprover