Tác giả: 0xhhh (Twitter: @hhh69251498), Binary DAO
Biên tập: Red One
Vào ngày 27 tháng 3, phiên bản thử nghiệm mainnet Polygon zkEVM ra mắt và Vitalik đã hoàn tất giao dịch đầu tiên trên đó.
Bài viết này, bài đầu tiên trong sê-ri Polygon zkEVM, sẽ giải thích ngắn gọn về kiến trúc tổng thể và quy trình thực hiện giao dịch của Polygon zkEVM, đồng thời phân tích cách Polygon zkEVM đạt được khả năng mở rộng tính toán trong khi vẫn kế thừa tính bảo mật của Ethereum.
Đồng thời, hai bài viết tiếp theo cũng sẽ giới thiệu chi tiết về thiết kế của zkEVM Bridge và zkEVM của Polygon zkEVM, cũng như lộ trình phát triển trình tự phi phi tập trung tiếp theo của Polygon zkEVM.
1. Rollup để đạt được khả năng mở rộng tính toán cho Ethereum
Trước tiên, chúng ta cần hiểu nguyên lý hoạt động chung của Rollup. Rollup được tạo ra để mở rộng khả năng tính toán của Ethereum. Phương pháp, Rollup thuê ngoài việc thực hiện giao dịch cho Rollup và sau đó lưu trữ giao dịch cùng trạng thái sau khi thực hiện trong các hợp đồng Ethereum. Do các phương pháp kỹ thuật khác nhau, hai loại Rollup đã phát triển:
Optimistic rollup
Người ta cho rằng giao dịch Rollup (Rollup Transaction) và trạng thái Rollup tương ứng (Rollup State) được gửi đến Ethereum là chính xác và bất kỳ ai cũng có thể thách thức (Challenge) trạng thái Rollup vẫn đang trong giai đoạn thách thức bằng cách cung cấp bằng chứng gian lận (Fraud Proof).
Tổng hợp không kiến thức
ZK sẽ cung cấp bằng chứng xác thực cho giao dịch Rollup và trạng thái Rollup tương ứng được gửi tới Ethereum (được xác minh bằng hợp đồng trên Ethereum để chứng minh trạng thái của Rollup sau khi thực hiện giao dịch tương ứng là chính xác).
Tham khảo định nghĩa chính thức của Ethereum :
https://ethereum.org/en/developers/docs/scaling/# rollups
Sự khác biệt lớn nhất giữa Zero-knowledge Rollup và Optimistic Rollup là thời gian khác nhau để đạt đến Finality do có nhiều cách khác nhau để xác minh tính hợp lệ của trạng thái;
Optimistic Rollup cho rằng các giao dịch và trạng thái được gửi đến Ethereum là chính xác, do đó có thời hạn khiếu nại là 7 ngày (thời gian để đạt đến trạng thái cuối cùng là 7 ngày). Trong thời gian này, bất kỳ ai phát hiện trạng thái tương ứng của giao dịch trên Ethereum không chính xác đều có thể khiếu nại bằng cách gửi trạng thái chính xác.
Thời gian để một giao dịch zero-knowledge rollup (zk-Rollup) đạt đến độ hoàn thiện phụ thuộc vào thời gian cần thiết để bằng chứng xác thực tương ứng của giao dịch được gửi đến Ethereum và được xác minh. Hiện tại, độ hoàn thiện có thể mất khoảng một giờ (do chi phí gas).
2. Quy trình thực thi Polygon zkEVM
Tiếp theo, hãy cùng xem cách Polygon zkEVM hoạt động thông qua một quy trình xác nhận giao dịch đơn giản để hiểu rõ hơn về giao thức tổng thể. Toàn bộ quy trình có thể được chia thành ba bước chính:
1. Sequencer đóng gói nhiều giao dịch của người dùng thành một lô và gửi đến hợp đồng L1;
2. Prover tạo ra bằng chứng xác thực cho mỗi giao dịch và tổng hợp các bằng chứng xác thực của nhiều giao dịch thành một bằng chứng xác thực;
3. Bên tổng hợp gửi bằng chứng xác thực (Validity Proof) của nhiều giao dịch được tổng hợp vào hợp đồng L1. 
1. Sequencer đóng gói các giao dịch của người dùng thành từng đợt và gửi chúng đến hợp đồng L1
1) Người dùng gửi giao dịch đến Sequencer, bộ xử lý sẽ xử lý giao dịch cục bộ theo thứ tự nhận được (FRFS). Sau khi Sequencer thực hiện thành công giao dịch cục bộ, nếu người dùng tin tưởng vào tính trung thực của Sequencer, giao dịch được cho rằng hoàn tất. Điều quan trọng cần lưu ý là Mempool (nhóm giao dịch) trong hầu hết các Sequencer hiện đang sở hữu tư nhân, do đó lượng MEV khả dụng tương đối nhỏ.
2) Sequencer sẽ gom nhiều giao dịch thành một lô (hiện tại, mỗi lô chỉ chứa một giao dịch). Sau khi thu thập nhiều lô, nó sẽ gửi các lô này cùng nhau đến calldata giao dịch trên L1 thông qua hàm SequenceBatch của PolygonZKEvm.sol trên L1. 
(Lưu ý rằng việc gửi nhiều lô hàng cùng một lúc là để giảm thiểu mức tiêu thụ gas L1)
3) Khi PolygonZkEvm.sol nhận được các lô do Sequencer cung cấp, nó sẽ tính toán hàm băm của từng lô theo lượt trong hợp đồng, sau đó ghi lại hàm băm của lô trước đó trong lô tiếp theo, tạo ra cấu trúc lô như bên dưới.
4) Thứ tự của các giao dịch trong mỗi lô cũng được xác định, do đó, khi thứ tự của lô được xác định, chúng tôi cho rằng thứ tự của tất cả các giao dịch có trong lô được gửi tới hợp đồng Polygon zkEVM trên L1 cũng được xác định.
Quá trình thực tế nêu trên cũng là công việc mà L1 cần hoàn thành với tư cách là lớp DA Rollup (không có công việc xác minh trạng thái hoặc nâng cấp nào được hoàn thành tại thời điểm này).
2. Aggregator tạo ra Bằng chứng hợp lệ cho nhiều giao dịch hàng loạt
1) Khi Aggregator phát hiện một lô mới đã được gửi thành công tới hợp đồng PolyonZKEVM.sol trên L1, nó sẽ đồng bộ hóa các lô này với nút riêng của nó rồi gửi các giao dịch này tới 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 từng giao dịch song song, sau đó tổng hợp các Bằng chứng hợp lệ của các giao dịch được bao gồm trong nhiều đợt thành một Bằng chứng hợp lệ duy nhất. 
3) zkProver gửi Bằng chứng hợp lệ của nhiều giao dịch tổng hợp tới Aggregator.
3. Bên tổng hợp gửi bằng chứng tổng hợp đến hợp đồng L1
Aggregator gửi bằng chứng xác thực và trạng thái thực thi lô tương ứng tới hợp đồng Polygon zkEvm.sol của L1 bằng cách gọi phương pháp sau: 
Sau đó, hợp đồng thực hiện các hoạt động sau để xác minh xem quá trình chuyển đổi trạng thái có chính xác hay không. 
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 lô này sẽ thực sự đạt đến mức Hoàn tất (tương ứng với thời điểm kết thúc thời hạn thử thách 7 ngày của OP).
3. Nhân vật của Ethereum trong Polygon -zkEVM
Bây giờ chúng ta đã tìm hiểu toàn bộ quy trình zkEVM Polygon , hãy cùng xem xét Ethereum làm gì cho Rollup:
Ở bước đầu tiên, Sequencer thu thập các giao dịch Rollup thành các lô và gửi chúng đến hợp đồng L1. L1 không chỉ cung cấp lớp DA mà còn thực hiện một số sắp xếp giao dịch. Khi các giao dịch được gửi đến Sequencer, chúng không thực sự được sắp xếp, vì Sequencer có quyền thay đổi thứ tự giao dịch theo ý muốn. Tuy nhiên, một khi các giao dịch đã được đưa vào một lô và gửi đến hợp đồng L1, không ai có quyền thay đổi thứ tự trong đó.
Ở bước thứ hai, Aggregator gửi Bằng chứng Xác thực đến hợp đồng L1 để đạt được trạng thái mới. Aggregator đóng nhân vật tương tự như Proposer, và hợp đồng đóng nhân vật tương tự như Validator. Aggregator cung cấp Bằng chứng Xác thực để chứng minh trạng thái mới là chính xác và cho Validator biết những lô giao dịch nào liên quan đến Bằng chứng Xác thực I đã cung cấp và chúng được lưu trữ ở đâu trong L1.
Sau đó, Validator sẽ rút Batch tương ứng từ hợp đồng và kết hợp nó với Bằng chứng Hiệu lực để xác minh tính hợp lệ của quá trình chuyển đổi trạng thái. 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 tương ứng với Bằng chứng Hiệu lực. 
4. Cấu trúc tổng hợp hợp đồng thông minh từ góc nhìn mô-đun
Xét về mặt mô-đun, Polygon zkEVM thuộc loại Smart Contract Rollup. Chúng ta có thể thử phân tích mô-đun khác nhau của nó. Từ sơ đồ do Delphi cung cấp, chúng ta cũng có thể thấy Polygon ZkEVM thực chất là Lớp Đồng thuận của Smart Contract Rollup. Lớp DA và Lớp Settlement thực chất được kết nối với hợp đồng PolygonZkEVM.sol và không thể phân biệt rõ ràng. Tuy nhiên, chúng ta hãy thử phân tích mô-đun khác nhau:
Lớp Khả dụng Dữ liệu: Đây là nơi lưu trữ các giao dịch Rollup. Đối với Polygon-zkEVM, khi Sequencer gọi phương pháp SequenceBatch, nó thực sự bao gồm việc gửi dữ liệu giao dịch đến lớp DA.
Lớp quyết toán : Cụ thể là đề 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 (giới thiệu chi tiết trong bài viết tiếp theo).
lớp đồng thuận: Lớp này xử lý sắp xếp giao dịch và xác định trạng thái hợp lệ tiếp theo (lựa chọn fork). Sequencer hoàn tất sắp xếp giao dịch khi gọi SequenceBatch trong hợp đồng L1, và Aggregator hoàn tất việc xác nhận trạng thái hợp lệ tiếp theo khi gọi TustedVerifyBatches trong hợp đồng L1.
Lớp Thực thi: Thực thi các giao dịch và thu thập trạng thái thế giới mới. Đây là quá trình người dùng gửi một giao dịch đến Sequencer, và Sequencer thực thi giao dịch đó và thu thập trạng thái mới. (Đây là lý do tại sao chúng ta thường nói Rollup là sự mở rộng tính toán, vì L1 thuê ngoài quy trình thực thi giao dịch và thu thập trạng thái mới cho Rollup. Đồng thời, Sequencer sẽ ủy thác cho zkProver thông qua Aggregator để giúp tạo ra Bằng chứng Xác thực.) 
5. Tại sao Polygon-zkEVM kế thừa tính bảo mật của L1
Nhìn lên quy trình tổng thể được mô tả ở trên, Sequencer thực sự thực hiện công việc tương tự như Ethereum Proposer, đề xuất một loạt giao dịch là giao dịch hợp lệ và hiển thị trạng thái mới sau khi thực hiện các giao dịch này. Logic xác minh hợp đồng L1 tương đương với việc tất cả các trình xác thực L1 được thực thi trong máy trạm Ethereum của riêng chúng. Trên thực tế, tất cả các trình xác thực Ethereum đều hoạt động như các trình xác thực Rollup. Do đó, chúng tôi cho rằng Polygon zkEVM kế thừa tính bảo mật của Ethereum.
Nhìn lên góc nhìn khác, vì tất cả các giao dịch và trạng thái Rollup đều được lưu trữ trên Ethereum , ngay cả khi đội ngũ Polygon zkEVM bỏ trốn, bất kỳ ai cũng có thể 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ế khích lệ zkEVM Polygon
Cơ chế khích lệ Rollup chủ yếu đề cập đến cách làm cho Sequencer và Aggregator có lợi nhuận để chúng có thể duy trì hoạt động liên tục? 
Đầu tiên, người dùng cần thanh toán phí giao dịch trên Rollup. Phần phí này được tính bằng ETH và được thanh toán bằng Bridged ETH.
Sequencer cần phải trả chi phí tải các lô chứa giao dịch Rollup này lên Calldata của giao dịch L1 (chi phí gọi SequenceBatch (các lô)). Đồng thời, nó cần phải trả một lượng Matic nhất định cho hợp đồng L1 khi tải lô lên, lượng Matic này sẽ được sử dụng để thanh toán chi phí cho Aggregator cung cấp Validity Proof cho các lô này.
Khi Aggregator gọi trustedVerifyBatches để cung cấp Bằng chứng hợp lệ cho các Lô trong hợp đồng L1 chưa được Hoàn tất, Aggregator cũng có thể rút token MATIC đã được Sequencer trả trước trong hợp đồng như một khoản bồi thường cho việc cung cấp Bằng chứng hợp lệ.
Thu nhập của Sequencer = Phí gas của tất cả các giao dịch Rollup - Mạng L1 Phí gas chi cho việc tải các lô lên L1 - Phí bằng chứng trả cho Aggregator (tính bằng MATIC).
Thu nhập của người tổng hợp = Phần thưởng MATIC do Sequencer trả - Phí gas gửi đến Validity Proof tới L1 - Phí phần cứng chi cho việc tạo Validity Proof.
Điều chỉnh phí chứng minh trả cho Aggregator. Để tránh Sequencer bị đình công do không có lợi nhuận, cơ chế sau đây được cung cấp để điều chỉnh phí chứng minh mà Sequencer trả cho Aggregator.
Trong hợp đồng có phương pháp điều chỉnh mức phí cung cấp bằng chứng cho lô hàng:
hàm _updateBatchFee(uint64 newLastVerifiedBatch) nội bộ
Nó thay đổi một biến trong hợp đồng có tên là BatchFee, biến này quyết định số lượng token MATIC mà Sequencer trả cho mỗi Batch.
Cơ chế thay đổi như sau:
Hợp đồng duy trì một biến có tên là VeryBatchTimeTarget, biểu thị trạng thái xác minh dự kiến trong khoảng thời gian này sau khi mỗi lô được Sequencer gửi đến L1.
Hợp đồng sẽ ghi lại tất cả các lô chưa được xác minh sau khi vượt quá VeryBatchTimeTarget và tổng số các lô này sẽ được ghi lại là DiffBatches.
Vì vậy, khi các lô hàng bị trễ, BatchFee sẽ được điều chỉnh theo công thức sau:
MultiplierBatchFee là một số giới hạn trong phạm vi 1000~1024 và có thể được thay đổi bởi người quản lý hợp đồng thông qua hàm setMultiplierBatchFee:
Hàm setMultiplier BatchFee (uint16newMultiplierBatchFee) public onlyAdmin
Cần lưu ý rằng MultiplierBatchFee và 10^3 được sử dụng ở đây để đạt được độ chính xác điều chỉnh sau 3 chữ số thập phân. 
Tương tự, nếu các lô được nâng cao, cơ chế điều chỉnh batchFee tương ứng sẽ được kích hoạt: DiffBatches cho biết số lượng lô có trạng thái xác minh nâng cao.
Tóm tắt
Trong bài viết này, chúng tôi đã phác thảo các 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 mở rộng năng lực tính toán Ethereum. Với tổng quan chung này, trong các bài viết tiếp theo, chúng tôi sẽ đi sâu hơn vào giao thức, phân tích chi tiết thiết kế của Cầu zkEVM, phương pháp tiếp cận phi tập trung của Sequencer, việc triển khai zkProver và các nguyên tắc thiết kế của zkEVM.
