Phần đầu tiên của loạt zkEVM: kiến trúc tổng thể và quy trình thực hiện giao dịch của Polygon zkEVM

Tác giả: 0xhhh, Ethstorage (Twitter: @hhh69251498 )

Editor:Red One

Vào ngày 27 tháng 3, phiên bản beta của mạng chính Polygon zkEVM đã chính thức ra mắt và Vitalik đã hoàn thành giao dịch đầu tiên trên đó.

Bài viết này là bài viết đầu tiên trong loạt bài viết về Polygon zkEVM, mô tả ngắn gọn kiến trúc tổng thể và quy trình thực hiện giao dịch của Polygon zkEVM và phân tích cách Polygon zkEVM đạt được quy mô tính toán trong khi kế thừa tính bảo mật của Ethereum.

Trong hai bài viết tiếp theo, chúng tôi cũng sẽ trình bày chi tiết chi tiết thiết kế của Cầu zkEVM và zkEVM của Polygon zkEVM, cũng như lộ trình cho Trình sắp xếp phi tập trung tiếp theo của Polygon zkEVM.

Đầu tiên, Rollup là để đạt được quy mô tính toán cho Ethereum

Trước tiên, chúng ta cần phải rõ ràng về cách hoạt động của Rollups. Sự xuất hiện của Rollup là mở rộng quy mô tính toán của Ethereum, phương pháp thực hiện cụ thể là thuê ngoài thực hiện các giao dịch cho Rollup, sau đó lưu trữ giao dịch và trạng thái (State) sau khi thực hiện giao dịch trong hợp đồng Ethereum.

** Tổng hợp lạc quan **

Một cách lạc quan, Giao dịch tổng hợp và Trạng thái tổng hợp tương ứng được gửi đến Ethereum là chính xác và bất kỳ ai cũng có thể thách thức Trạng thái tổng hợp vẫn đang trong giai đoạn thử thách bằng cách cung cấp Bằng chứng gian lận.

** Tổng hợp không có kiến thức **

ZK sẽ cung cấp bằng chứng hợp lệ cho giao dịch tổng hợp được gửi đến Ethereum và trạng thái tổng hợp tương ứng (được xác minh bởi hợp đồng trên Ethereum để chứng minh rằng bản tổng hợp ở trạng thái chính xác sau khi thực hiện giao dịch tương ứng).

Tham khảo định nghĩa chính thức của Ethereum:

Sự khác biệt lớn nhất giữa Zero-knowledge Rollup và Optimistic Rollup là thời gian để đạt được sự cuối cùng là khác nhau do các cách khác nhau để xác minh tính hợp lệ của trạng thái.

Optimistic Rollup lạc quan rằng các giao dịch và trạng thái được gửi đến Ethereum là chính xác, vì vậy có thời gian thử thách 7 ngày (thời gian để đạt được kết quả cuối cùng là 7 ngày), trong đó bất kỳ ai thấy rằng trạng thái tương ứng của giao dịch trên Ethereum là không chính xác đều có thể thách thức bằng cách gửi trạng thái chính xác.

Thời gian cần thiết để Zero-knowledge Rollup (zk-Rollup) đạt được kết quả cuối cùng phụ thuộc vào thời gian cần thiết để Bằng chứng hợp lệ của giao dịch được gửi đến Ethereum và được xác minh. Hiện tại, có thể mất khoảng 1 giờ để cuối cùng (vì cần phải xem xét chi phí xăng).

Thứ hai, Quy trình thực thi Polygon zkEVM

Chúng ta hãy xem cách Polygon zkEVM hoạt động với quy trình xác nhận giao dịch đơn giản, để hiểu cụ thể về giao thức tổng thể và toàn bộ quy trình của nó có thể được chia thành ba bước chính:

1. Trình tự đóng gói nhiều giao dịch của người dùng thành các lô và gửi chúng cho hợp đồng L1.

2. Prover tạo ra Bằng chứng hợp lệ cho mỗi giao dịch và tổng hợp bằng chứng hợp lệ của nhiều giao dịch thành một Bằng chứng hợp lệ duy nhất.

3. Tổng hợp nộp Bằng chứng hợp lệ của bên tổng hợp tổng hợp nhiều giao dịch vào hợp đồng L1.

**1 Trình tự đóng gói các giao dịch của người dùng thành các lô và gửi chúng cho hợp đồng L1.

1. Người dùng gửi giao dịch cho Sequencer và Sequencer sẽ xử lý giao dịch cục bộ theo thứ tự nhận (FRFS), khi Sequencer thực hiện giao dịch cục bộ, nếu người dùng tin rằng Sequencer là trung thực, thì anh ta có thể coi giao dịch đã đạt đến cuối cùng. Điều quan trọng cần lưu ý ở đây là hầu hết các Mempool trong Sequencer hiện đang ở chế độ riêng tư, vì vậy có tương đối ít MEV có thể nhận được trong thời điểm hiện tại.

2. Sequencer sẽ đóng gói nhiều giao dịch thành một lô (hiện tại chỉ có một giao dịch trong một đợt) và sau đó gửi nhiều lô cùng nhau đến Calldata giao dịch của L1 thông qua hàm SequenceBatch() của PolygonZKEvm.sol trên L1.

(Cần lưu ý rằng nhiều lô được gửi cùng một lúc để giảm mức tiêu thụ khí của L1 càng nhiều càng tốt.)

3. Khi PolygonZkEvm.sol nhận được các lô do Sequencer cung cấp, nó sẽ lần lượt tính toán hàm băm của từng lô trong hợp đồng, sau đó ghi lại hàm băm của lô trước đó trong lô tiếp theo, vì vậy chúng ta có được cấu trúc Batch trong hình sau.

4) Thứ tự giao dịch trong mỗi lô cũng được xác định, vì vậy khi thứ tự của lô được xác định, chúng tôi xem xét thứ tự của tất cả các giao dịch được bao gồm trong lô được gửi đến hợp đồng L1 Polygon zkEVM đã được xác định.

Quy trình thực tế trên cũng là công việc mà L1 cần hoàn thành dưới dạng lớp Rollup DA (chưa có công việc xác minh trạng thái hoặc tiến bộ nào được hoàn thành tại thời điểm này).

**2. Aggregator tạo Validity Proof cho nhiều lô giao dịch

1. Khi Bộ tổng hợp lắng nghe việc gửi thành công các lô mới trong hợp đồng PolyonZKEVM.sol trên L1, nó sẽ đồng bộ hóa các lô này với nút của nó và gửi các giao dịch này đến zkProver.

2. Sau khi nhận được các giao dịch này, zkProver sẽ tạo Bằng chứng hợp lệ cho mỗi giao dịch, sau đó tổng hợp Bằng chứng hợp lệ của các giao dịch chứa trong nhiều lô thành Bằng chứng hợp lệ.

3. zkProver gửi Bằng chứng hợp lệ về việc tổng hợp nhiều giao dịch đến Aggregator.

3. Tổng hợp nộp hợp đồng để chứng minh tổng hợp cho L1

Aggregator sẽ gửi Bằng chứng hợp lệ này cho hợp đồng Polygon zkEvm.sol trên L1 cùng với trạng thái tương ứng của việc thực hiện lô bằng cách gọi phương thức sau:

Các hành động sau đây sau đó được thực hiện trong hợp đồng để xác minh rằng quá trình chuyển đổi trạng thái là chính xác.

Khi bước này được thực hiện thành công trong hợp đồng L1, tất cả các giao dịch có trong phần này của lô sẽ thực sự đạt đến Finality (tương ứng với việc kết thúc thời gian thử thách 7 ngày của OP).

3. Vai trò của Ethereum trong Polygon-zkEVM

Bây giờ chúng ta đã xem xét quy trình tổng thể của Polygon zkEVM, hãy xem lại những gì Ethereum đã làm cho Rollup:

Trong bước đầu tiên, Sequencer thu thập các giao dịch tổng hợp và đóng gói chúng thành các lô, sau đó được gửi đến hợp đồng L1. L1 không chỉ cung cấp chức năng của lớp DA, mà còn thực sự hoàn thành một số chức năng đặt hàng giao dịch, khi bạn gửi một giao dịch cho Sequencer, giao dịch không thực sự được đặt hàng, vì Sequencer có quyền thay đổi thứ tự giao dịch theo ý muốn, nhưng khi giao dịch được đưa vào Batch và nộp cho hợp đồng L1 thì không ai có quyền thay đổi thứ tự giao dịch.

Trong bước thứ hai, Bộ tổng hợp đưa Bằng chứng hợp lệ đến hợp đồng L1 để đạt đến trạng thái mới, Bộ tổng hợp là vai trò giống như Người đề xuất và hợp đồng tương tự như vai trò Người xác thực và Bộ tổng hợp cung cấp Bằng chứng hợp lệ để chứng minh rằng trạng thái mới là chính xác và cho Người xác thực biết Tính hợp lệ mà tôi cung cấp Những lô giao dịch nào liên quan đến Proof và chúng ở đâu trong L1.

Sau đó, trình xác thực trích xuất lô tương ứng từ hợp đồng và kết hợp nó với Bằng chứng hợp lệ để xác minh tính hợp pháp của quá trình chuyển đổi trạng thái và nếu xác minh thành công, hợp đồng sẽ thực sự được cập nhật lên trạng thái mới của Bằng chứng hợp lệ tương ứng.

Thứ tư, cấu trúc Smart Contract Rollup từ góc độ mô-đun

Nếu từ góc độ mô-đun, Polygon zkEVM thuộc loại Smart Contract Rollup, chúng ta có thể thử giải cấu trúc các mô-đun của nó và từ sơ đồ do Delphi đưa ra, chúng ta cũng có thể thấy rằng Polygon ZkEVM thực sự là Lớp đồng thuận, Lớp DA và Giải quyết Smart Contrat Rollup Các lớp thực sự được ghép nối với hợp đồng PolygonZkEVM.sol, không được phân biệt rõ. Nhưng hãy thử giải cấu trúc các mô-đun:

Lớp sẵn sàng dữ liệu: Nơi các giao dịch tổng hợp được lưu trữ và trong trường hợp Polygon-zkEVM, khi Sequencer gọi phương thức SequenceBatch(), nó thực sự bao gồm việc gửi dữ liệu giao dịch đến lớp DA.

Lớp thanh toán: Cụ thể đề cập đến cơ chế dòng tiền giữa Rollup và L1, cụ thể là cầu nối chính thức của Polygon-zkEVM (sẽ nói thêm về điều này trong bài viết tiếp theo).

Lớp đồng thuận: Chứa thứ tự các giao dịch và cách xác định trạng thái hợp lệ tiếp theo (lựa chọn fork), Sequencer hoàn thành thứ tự các giao dịch khi nó gọi SequenceBatch() trong hợp đồng L1 và xác nhận trạng thái pháp lý tiếp theo khi Aggregator gọi TustedVerifyBatches() trong hợp đồng L1.

Lớp thực thi: Quá trình mà một giao dịch được thực hiện và thu được trạng thái thế giới mới, khi người dùng gửi giao dịch đến Sequencer và trạng thái mới thu được sau khi Trình sắp xếp được thực thi ( Đó là lý do tại sao chúng ta có xu hướng nói rằng Rollups là mở rộng quy mô tính toán, bởi vì L1 thuê ngoài quá trình thực hiện các giao dịch để có được trạng thái mới cho Rollups và Sequencer ủy quyền zkProver để giúp tạo Bằng chứng hợp lệ thông qua Aggregator.

5. Tại sao Polygon-zkEVM kế thừa tính bảo mật của L1

Đánh giá từ quy trình tổng thể được mô tả ở trên, Sequencer thực sự làm một cái gì đó tương tự như Ethereum Proposer, đề xuất rằng một loạt các giao dịch là các giao dịch hợp lệ và đưa ra trạng thái mới của lô giao dịch này sau khi thực hiện và logic xác minh của hợp đồng L1 tương đương với tất cả các trình xác thực L1 sẽ được thực thi trong các máy khách Ethereum của riêng họ, trên thực tế, tất cả các trình xác thực Ethereum đều đóng vai trò là trình xác thực của Rollup, vì vậy chúng tôi nghĩ Polygon zkEVM Kế thừa tính bảo mật của Ethereum.

Mặt khác, vì tất cả các giao dịch và trạng thái của Rollups được lưu trữ trên Ethereum, ngay cả khi nhóm Polygon zkEVM chạy trốn, bất kỳ ai vẫn sẽ có khả năng khôi phục toàn bộ mạng Rollup dựa trên dữ liệu được lưu trữ trên Ethereum.

6. Cơ chế khuyến khích đa giác zkEVM

Ưu đãi tổng hợp chủ yếu là về cách làm cho Sequencer và Aggregator có lợi nhuận và do đó giữ cho công việc tiếp tục?

Trước hết, người dùng cần phải trả phí giao dịch của riêng họ trên Rollup, được tính bằng ETH và được thanh toán bằng ETH Bridged.

Sequencer sẽ cần phải trả chi phí tải Batch chứa giao dịch Rollup lên Calldata của giao dịch L1 (chi phí gọi SequenceBatch (batches ()) và Matic sẽ cần phải trả một số tiền nhất định của Matic cho hợp đồng L1 cùng lúc với lô được tải lên, sau này sẽ trả chi phí Aggregator cung cấp Bằng chứng hợp lệ cho các lô này.

Trong khi Aggregator gọi VerifyBatches đáng tin cậy để cung cấp Bằng chứng hợp lệ cho các lô trong hợp đồng L1 chưa phải là cuối cùng, Sequencer cũng có thể lấy ra các mã thông báo MATIC được trả trước bởi Sequencer trong hợp đồng như một phần thưởng cho việc cung cấp Bằng chứng hợp lệ.

Doanh thu của Sequencer = phí gas cho tất cả các giao dịch trong bản tổng hợp - phí gas mạng L1 được chi cho việc tải Hàng loạt lên L1 - phí chứng thực được trả cho Bộ tổng hợp (mệnh giá MATIC).

Doanh thu của bộ tổng hợp = Phần thưởng MATIC do Sequencer trả - phí gas được gửi đến bằng chứng hợp lệ cho L1 - phí phần cứng được sử dụng để tạo bằng chứng hợp lệ.

Điều chỉnh phí chứng thực đã trả cho Đại lý và để ngăn chặn Sequencer không có lợi khi đình công, cơ chế sau đây được cung cấp để điều chỉnh phí chứng thực mà Sequencer đã trả cho Đại lý.

Có một phương pháp trong hợp đồng điều chỉnh chi phí cung cấp bằng chứng cho các lô:

hàm _updateBatchFee(uint64 newLastVerifiedBatch) nội bộ

Nó thay đổi một biến trong hợp đồng được gọi là BatchFee, xác định số lượng mã thông báo MATIC mà Sequencer trả cho mỗi đợt.

Cơ chế thay đổi như sau:

Hợp đồng duy trì một biến VeryBatchTimeTarget đại diện cho trạng thái dự kiến của mỗi lô sẽ được xác thực trong thời gian đó sau khi được Sequencer cam kết với L1.

Hợp đồng sẽ ghi lại tất cả các lô chưa được xác thực sau khi vượt quá VeryBatchTimeTarget và tổng số lô này sẽ được ghi nhận là DiffBatches.

Do đó, khi một Batches bị trễ, BatchFee sẽ được điều chỉnh theo công thức sau:

MultiplierBatchFee là một số được giới hạn trong phạm vi 1000 ~ 1024, có thể được thay đổi bởi quản trị viên hợp đồng thông qua bộ hàm MultiplierBatchFee ():

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin

Cần lưu ý rằng việc sử dụng MultiplierBatchFee và 10 ^ 3 ở đây là để đạt được độ chính xác điều chỉnh sau 3 dấu thập phân.

Tương tự, nếu các lô được đặt trước, cơ chế điều chỉnh batchFee tương ứng sẽ được kích hoạt: DiffBatches cho biết số lượng lô ở trạng thái xác minh sớm.

Tóm tắt

Trong bài viết này, chúng tôi sắp xếp cơ chế cốt lõi của Polygon zkEVM và phân tích tính khả thi của nó trong việc đạt được quy mô tính toán Ethereum. Với một phác thảo tổng thể, trong các bài viết sau, chúng tôi sẽ đi sâu vào nội thất của giao thức, phân tích các chi tiết thiết kế của Cầu zkEVM, tuyến đường phân cấp của Sequencer, việc triển khai zkProver và các nguyên tắc thiết kế của zkEVM.

——Còn tiếp——