Cựu đại sứ kỹ thuật trọng tài giải thích cấu trúc thành phần của Arbitrum (Phần I)

Tác giả: Benben Luo, cựu đại sứ kỹ thuật Arbitrum và cộng tác viên geek web3

**Bài viết này là một diễn giải kỹ thuật về Arbitrum One của Benben Luo, cựu đại sứ kỹ thuật của Arbitrum và cựu đồng sáng lập của Goplus Security, một công ty kiểm toán tự động hóa Hợp đồng thông minh. **

Bởi vì các bài viết hoặc tài liệu liên quan đến Lớp 2 trong vòng tròn Trung Quốc thiếu sự giải thích chuyên nghiệp về Trọng tài và thậm chí OP Rollup, bài viết này cố gắng lấp đầy khoảng trống trong lĩnh vực này bằng cách phổ biến cơ chế hoạt động của Arbitrum. Do sự phức tạp của cấu trúc của chính Arbitrum, toàn văn vẫn còn hơn 10.000 từ trên cơ sở đơn giản hóa càng nhiều càng tốt, vì vậy nó được chia thành hai bài viết, được khuyến nghị thu thập và chuyển tiếp làm tài liệu tham khảo!**

Mô tả ngắn gọn về trình tự Rollup

Nguyên tắc mở rộng quy mô rollup có thể được tóm tắt trong hai điểm:

Tối ưu hóa chi phí: Giảm tải hầu hết các tác vụ tính toán và lưu trữ cho L1 ngoài chuỗi, tức là L2. **L2 chủ yếu là một chuỗi chạy trên một máy chủ duy nhất, tức là một trình sắp xếp / nhà điều hành.

Trình sắp xếp chuỗi trông gần với một máy chủ tập trung, từ bỏ “Phân cấp” trong “Blockchain Impossible Three Times” để đổi lấy TPS và lợi thế về chi phí. Người dùng có thể để L2 xử lý các hướng dẫn giao dịch thay vì Ethereum với chi phí thấp hơn nhiều so với giao dịch trên Ethereum.

**Bảo mật: Nội dung giao dịch trên L2 và trạng thái sau khi giao dịch sẽ được đồng bộ hóa với Ethereum L1 và tính hợp lệ của quá trình chuyển đổi trạng thái sẽ được xác minh thông qua hợp đồng. Đồng thời, lịch sử L2 sẽ được giữ lại trên Ethereum và ngay cả khi trình sắp xếp thứ tự ngừng hoạt động vĩnh viễn, những người khác có thể khôi phục toàn bộ trạng thái L2 thông qua các bản ghi trên Ethereum.

Về cơ bản, tính bảo mật của Rollups dựa trên Ethereum. Nếu trình sắp xếp chuỗi không biết khóa riêng của tài khoản, nó không thể bắt đầu các giao dịch dưới tên của tài khoản đó hoặc giả mạo số dư tài sản trong tài khoản đó (và ngay cả khi có, nó vẫn nhanh chóng được nhận ra).

Mặc dù trình sắp xếp trình tự được tập trung làm xương sống của hệ thống, trong sơ đồ Rollup tương đối trưởng thành, trình tự tập trung chỉ có thể thực hiện các hành vi xấu xa mềm như xem xét giao dịch hoặc thời gian chết độc hại, nhưng trong sơ đồ Rollup lý tưởng, có các phương tiện tương ứng để hạn chế nó (chẳng hạn như cơ chế chống kiểm duyệt như rút tiền bắt buộc hoặc bằng chứng đơn hàng).

Các phương pháp xác minh trạng thái để ngăn chặn trình tự tổng hợp trở nên xấu xa được chia thành hai loại: Bằng chứng gian lận và Bằng chứng hợp lệ. Rollups sử dụng bằng chứng gian lận được gọi là OP Rollups (Optimistic Rollups, OPRs), và do một số hành lý lịch sử, Rollups sử dụng bằng chứng hợp lệ thường được gọi là ZK Rollups (Zero-knowledge Proof Rollups, ZKR) thay vì Validity Rollups.

Trọng tài Một là một OPR điển hình triển khai hợp đồng trên L1 và không chủ động xác thực dữ liệu đã gửi, lạc quan tin rằng không có vấn đề gì với dữ liệu. Nếu có lỗi trong dữ liệu đã gửi, Nút xác thực của L2 sẽ bắt đầu thử thách.

Vì vậy, OPR cũng ngụ ý một giả định tin cậy: có ít nhất một Nút xác thực L2 trung thực tại bất kỳ thời điểm nào. Mặt khác, hợp đồng của ZKR sử dụng mật mã để xác minh chủ động nhưng hiệu quả về chi phí dữ liệu được gửi bởi trình sắp xếp.

Trong bài viết này, chúng tôi sẽ giới thiệu sâu về Arbitrum One, dự án hàng đầu về các bản tổng hợp lạc quan, bao gồm tất cả các khía cạnh của toàn bộ hệ thống và sau khi đọc kỹ, bạn sẽ hiểu sâu về Arbitrum và optimistic rollup / OPR.

Các thành phần và quy trình làm việc cốt lõi của Arbitrum

Hợp đồng cốt lõi:

Các hợp đồng quan trọng nhất của Arbitrum bao gồm SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, v.v. Thêm về điều đó sau.

Sequencer:

Giao dịch của người dùng được nhận và sắp xếp, kết quả giao dịch được tính toán và biên lai được trả lại cho người dùng một cách nhanh chóng (thường là < 1s). Người dùng thường có thể thấy các giao dịch của họ trên chuỗi L2 chỉ trong vài giây, giống như nền tảng Web2.

Đồng thời, trình sắp xếp chuỗi cũng sẽ phát sóng Khối L2 mới nhất trong thời gian thực theo chuỗi Ethereum và bất kỳ Nút Layer2 nào cũng có thể nhận được nó không đồng bộ. Nhưng tại thời điểm này, các Khối L2 này chưa được hoàn thiện và có thể được Rollback bởi trình sắp xếp.

Cứ sau vài phút, trình sắp xếp sẽ nén dữ liệu giao dịch L2 đã sắp xếp, tổng hợp thành các lô và gửi nó đến hộp thư đến hợp đồng SequencerInbox trên Lớp 1 để đảm bảo tính khả dụng của dữ liệu và hoạt động của giao thức Rollup. Nói chung, dữ liệu L2 được gửi đến Lớp 1 không thể được khôi phục và có thể được hoàn thiện.

Từ quy trình trên, chúng ta có thể tóm tắt: Layer2 có mạng lưới node riêng, nhưng số lượng node này khan hiếm, và nhìn chung không có giao thức đồng thuận nào được sử dụng bởi public chain, vì vậy tính bảo mật rất kém, và nó phải được gắn vào Ethereum để đảm bảo độ tin cậy của việc phát hành dữ liệu và hiệu quả của quá trình chuyển đổi trạng thái.

Giao thức Arbitrum Rollup:

Một loạt các hợp đồng xác định cấu trúc của RBlock khối của chuỗi Rollup, sự tiếp tục của chuỗi, phát hành RBlock và quy trình chế độ thử thách. Lưu ý rằng chuỗi Rollup được đề cập ở đây không phải là sổ cái Layer2 như chúng ta hiểu, mà là một “cấu trúc dữ liệu chuỗi” trừu tượng được thiết lập bởi Arbitrum One để thực hiện cơ chế chống gian lận.

Một RBlock có thể chứa kết quả của nhiều khối L2 và dữ liệu cũng rất khác nhau và thực thể dữ liệu RBlock của nó được lưu trữ trong một loạt các hợp đồng trong RollupCore. Nếu có vấn đề với RBlock, Trình xác thực sẽ thách thức người cam kết của RBlock đó.

Validator:

Node validator của Arbitrum thực sự là một tập hợp con đặc biệt của Layer2 Full Nodes, hiện có quyền truy cập Allowlist.

Trình xác thực tạo một RBlock mới (Khối tổng hợp, còn được gọi là xác nhận) dựa trên lô giao dịch do trình sắp xếp gửi đến hợp đồng SequencerInbox và theo dõi trạng thái của chuỗi Rollup hiện tại để thách thức dữ liệu sai do trình sắp xếp trình tự gửi.

Trình xác thực đang hoạt động yêu cầu đặt cọc trước tài sản trên chuỗi ETH, đôi khi được gọi là người đặt cược. Mặc dù các nút Layer2 không stake cũng có thể theo dõi động lực đang chạy của Rollups, gửi cảnh báo bất thường cho người dùng, v.v., chúng không thể can thiệp trực tiếp vào dữ liệu lỗi được gửi bởi trình sắp xếp chuỗi trên chuỗi ETH.

Thách thức:

Các bước nền tảng có thể được tóm tắt dưới dạng phân đoạn tương tác nhiều vòng và bằng chứng một bước. Trong phiên phân khúc, cả hai bên được thử thách thực hiện nhiều vòng phân chia theo lượt dữ liệu giao dịch có vấn đề cho đến khi hướng dẫn Mã hoạt động bước có vấn đề được chia nhỏ và xác minh. Mô hình “phân đoạn nhiều vòng - bằng chứng một bước” được các nhà phát triển Arbitrum coi là cách triển khai bằng chứng gian lận hiệu quả nhất về khí đốt. Mọi thứ đều nằm trong tầm kiểm soát hợp đồng và không bên nào có thể gian lận.

Thời gian thử thách:

Do tính chất lạc quan của OP Rollup, sau khi mỗi RBlock được gửi đến chuỗi, hợp đồng không chủ động kiểm tra nó, để lại một khoảng thời gian cho người xác thực làm sai lệch. Khoảng thời gian này là khoảng thời gian thử thách, là 1 tuần trên Arbitrum One Mainnet. Sau khi thời gian thử thách kết thúc, RBlock sẽ được hoàn tất và thông báo tương ứng từ L2 đến L1 trong khối (chẳng hạn như thao tác rút tiền được thực hiện thông qua cầu nối chính thức) có thể được phát hành.

ArbOS, Geth, WAVM:

Máy ảo được Arbitrum sử dụng được gọi là AVM, bao gồm hai phần: Geth và ArbOS. Geth là phần mềm máy khách được sử dụng phổ biến nhất của Ethereum và Arbitrum đã thực hiện các sửa đổi nhẹ đối với nó. ArbOS chịu trách nhiệm cho tất cả các chức năng đặc biệt liên quan đến L2, chẳng hạn như quản lý tài nguyên mạng, tạo khối L2, làm việc với EVM, v.v. Chúng tôi nghĩ về sự kết hợp của cả hai như một AVM gốc, là máy ảo được sử dụng bởi Arbitrum. WAVM là kết quả của việc biên dịch mã của AVM thành Wasm. Trong quy trình thử thách Trọng tài, “bằng chứng một bước” cuối cùng sẽ xác minh các hướng dẫn WAVM.

Ở đây, chúng ta có thể minh họa mối quan hệ và quy trình làm việc giữa các thành phần trên trong sơ đồ sau:

Vòng đời giao dịch L2

Dưới đây là cách giao dịch L2 hoạt động:

1. Người dùng gửi hướng dẫn giao dịch cho trình sắp xếp.

2. Bộ giải trình tự trước tiên xác minh các dữ liệu như Chữ ký số của giao dịch cần xử lý, loại bỏ giao dịch không hợp lệ, sắp xếp và tính toán.

3. Trình sắp xếp chuỗi gửi biên lai giao dịch cho người dùng (thường rất nhanh), nhưng đây chỉ là “tiền xử lý” của chuỗi ngoài ETH trình tự, ở trạng thái Soft Finality và không đáng tin cậy. Nhưng đối với những người dùng tin tưởng vào trình sắp xếp thứ tự (hầu hết người dùng), điều lạc quan là giao dịch đã được hoàn thành và sẽ không bị khôi phục.

4. Trình tự đóng gói dữ liệu thô giao dịch được xử lý trước thành một lô sau khi nén cao.

5. Thỉnh thoảng (bị ảnh hưởng bởi các yếu tố như khối lượng dữ liệu, tắc nghẽn ETH, v.v.), trình tự sẽ xuất bản các lô giao dịch lên hợp đồng Hộp thư đến của Trình sắp xếp trên L1. Tại thời điểm này, giao dịch có thể được coi là có một Hard Finality.

Hợp đồng hộp thư đến Sequencer

Hợp đồng sẽ nhận được hàng loạt giao dịch được gửi bởi trình tự để đảm bảo tính khả dụng của dữ liệu. Nhìn sâu hơn, dữ liệu lô trong SequencerInbox ghi lại hoàn toàn thông tin đầu vào giao dịch của Layer 2, ngay cả khi sequencer ngừng hoạt động vĩnh viễn, bất kỳ ai cũng có thể khôi phục trạng thái hiện tại của Layer 2 dựa trên bản ghi lô, thay thế cho trình sắp xếp chuỗi pull / Rug bị lỗi.

Về mặt vật lý, những gì chúng ta thấy là L2 chỉ là một hình chiếu của lô trong SequencerInbox và nguồn sáng là STF. Bởi vì STF nguồn sáng không dễ dàng thay đổi, hình dạng của bóng chỉ được xác định bởi lô hoạt động như đối tượng.

Hợp đồng Sequencer Inbox, còn được gọi là Fastbox, là một trình sắp xếp trình tự gửi các giao dịch được xử lý trước cho nó và chỉ trình sắp xếp chuỗi mới có thể gửi dữ liệu đến nó. Hộp nhanh tương ứng là hộp chậm Delayer Inbox và các chức năng của nó sẽ được mô tả trong quá trình tiếp theo.

Trình xác thực sẽ luôn lắng nghe hợp đồng SequencerInbox và bất cứ khi nào trình sắp xếp phát hành một lô cho hợp đồng, nó sẽ đưa ra một sự kiện trên chuỗi và sau khi Trình xác thực nghe thấy sự kiện này, nó sẽ tải xuống dữ liệu lô và sau khi thực thi cục bộ, nó sẽ phát hành RBlock cho hợp đồng giao thức Rollup trên chuỗi ETH.

Hợp đồng bắc cầu của Arbitrum có một tham số gọi là accumulator, sẽ ghi lại số lượng lô L2 mới nộp, cũng như số lượng giao dịch mới nhận và thông tin trên hộp thư đến chậm.

Hợp đồng SequencerInbox có hai chức năng chính:

thêm Sequencer L2Batch From Origin(), mà sequencer gọi mỗi lần để gửi Batch data vào hợp đồng Sequencer Inox.

force Inclusion(), có thể được gọi bởi bất kỳ ai và được sử dụng để thực hiện các giao dịch chống kiểm duyệt. Cách thức hoạt động của chức năng này sẽ được giải thích chi tiết hơn sau khi chúng ta nói về hợp đồng Hộp thư đến bị trì hoãn.

Cả hai hàm đều gọi bridge.enqueueSequencerMessage() để cập nhật bộ tích lũy tham số bộ tích lũy trong hợp đồng cầu nối.

Giá gas

Rõ ràng, các giao dịch L2 không thể miễn phí vì các cuộc tấn công DoS, chi phí vận hành của chính bộ sắp xếp thứ tự L2 và chi phí gửi dữ liệu trên L1. Khi người dùng bắt đầu giao dịch trong mạng Lớp 2, phí gas được cấu trúc như sau:

Chi phí xuất bản dữ liệu được tạo ra bởi việc chiếm tài nguyên Lớp 1 chủ yếu đến từ các lô được gửi bởi trình sắp xếp chuỗi (mỗi lô có nhiều giao dịch của người dùng) và chi phí cuối cùng được chia đều bởi những người khởi tạo giao dịch. Thuật toán định giá phí được tạo ra bởi xuất bản dữ liệu là động và trình sắp xếp chuỗi sẽ định giá dựa trên lãi và lỗ gần đây, kích thước lô và giá gas Ethereum hiện tại.

Chi phí phát sinh của người dùng do chiếm dụng tài nguyên Lớp 2 được đặt thành số lượng khí tối đa mỗi giây có thể đảm bảo hoạt động ổn định của hệ thống (hiện tại là 7 triệu cho Arbitrum One). Giá hướng dẫn khí cho cả L1 và L2 được theo dõi và điều chỉnh bởi ArbOS, và công thức sẽ không được lặp lại ở đây trong thời gian này.

Mặc dù quy trình tính giá gas cụ thể phức tạp hơn, nhưng người dùng không cần phải nắm bắt những chi tiết này và rõ ràng là Phí giao dịch Rollup rẻ hơn nhiều so với ETH Mainnet.

Bằng chứng gian lận lạc quan

Tóm lại, L2 thực sự chỉ là một phép chiếu đầu vào hàng loạt của các giao dịch được gửi bởi trình sắp xếp trong Fastbox, tức là:

Đầu vào giao dịch -> STF -> State Outputs。 Đầu vào được xác định, STF không đổi và đầu ra cũng được xác định, và hệ thống chống gian lận và giao thức Arbitrum Rollup là một hệ thống xuất bản gốc của trạng thái đầu ra sang L1 dưới dạng RBlock (hay còn gọi là khẳng định) và lạc quan chứng minh điều đó.

Trên L1 có dữ liệu đầu vào được xuất bản bởi trình sắp xếp và cũng có trạng thái đầu ra được xuất bản bởi trình xác thực. Chúng ta hãy xem xét kỹ hơn, có cần thiết phải công bố trạng thái của Layer 2 on-chain không?

Bởi vì đầu vào đã xác định đầy đủ đầu ra và dữ liệu đầu vào được hiển thị công khai, việc gửi đầu ra - trạng thái có vẻ dư thừa, nhưng ý tưởng này bỏ qua thực tế là việc giải quyết trạng thái thực sự được yêu cầu giữa các hệ thống L1-L2, nghĩa là hành vi được đề xuất của L2 theo hướng L1 và cần phải có bằng chứng về trạng thái.

Khi xây dựng một rollup, một trong những ý tưởng cốt lõi là đặt hầu hết các tính toán và lưu trữ trên L2 để tránh chi phí cao của L1, có nghĩa là L1 không biết trạng thái của L2, nó chỉ giúp trình tự L2 công bố dữ liệu đầu vào của tất cả các giao dịch, nhưng không chịu trách nhiệm tính toán trạng thái của L2.

Hành vi rút tiền về cơ bản là mở khóa các khoản tiền tương ứng từ hợp đồng L1 theo thông điệp tương tác chuỗi chéo do L2 đưa ra, chuyển chúng vào tài khoản L1 của người dùng hoặc hoàn thành những việc khác.

Tại thời điểm này, hợp đồng Lớp 1 sẽ hỏi: trạng thái của bạn trên Lớp 2 là gì và làm thế nào bạn có thể chứng minh rằng bạn thực sự sở hữu tài sản mà bạn tuyên bố vượt qua. Tại thời điểm này, người dùng nên cung cấp Bằng chứng Merkle tương ứng, v.v.

Vì vậy, nếu chúng ta xây dựng một bản tổng hợp không có chức năng rút tiền, về mặt lý thuyết có thể không đồng bộ hóa trạng thái với L1 và không cần hệ thống bằng chứng trạng thái như bằng chứng gian lận (mặc dù nó có thể gây ra các vấn đề khác). Nhưng trong thực tế, điều này rõ ràng là không khả thi.

Trong cái gọi là bằng chứng lạc quan, hợp đồng không kiểm tra xem đầu ra được gửi cho L1 có ở trạng thái chính xác hay không và lạc quan rằng mọi thứ đều chính xác. Hệ thống bằng chứng lạc quan giả định rằng có ít nhất một trình xác thực trung thực tại bất kỳ thời điểm nào và nếu có trạng thái sai, nó sẽ bị thách thức bởi bằng chứng gian lận.

Ưu điểm của thiết kế này là không cần phải chủ động xác nhận mọi RBlock được xuất bản lên L1 để tránh lãng phí gas. Trên thực tế, OPR không thực tế để xác minh từng khẳng định, bởi vì mỗi rblock chứa một hoặc nhiều Khối L2 và nó không khác gì thực hiện các giao dịch L2 trực tiếp trên L1 để thực hiện lại từng giao dịch trên L1, điều này làm mất ý nghĩa của tỷ lệ Lớp 2.

ZKR không có vấn đề này, bởi vì ZK Proof có sự đơn giản và chỉ cần xác minh một Proof nhỏ, và không cần phải thực sự thực hiện nhiều giao dịch đằng sau Proof. Do đó, ZKR không lạc quan và mỗi khi trạng thái phát hành được xác minh về mặt toán học bởi hợp đồng Verfier.

Mặc dù bằng chứng gian lận không thể ngắn gọn như Bằng chứng không có kiến thức, Arbitrum sử dụng quy trình tương tác từng bước “bằng chứng chia nhỏ nhiều vòng” và cuối cùng chỉ cần chứng minh một Mã hoạt động máy ảo duy nhất, chi phí tương đối nhỏ.

Giao thức tổng hợp

Chúng ta hãy xem giao thức Rollup, điểm khởi đầu để bắt đầu các thách thức và khởi chạy bằng chứng, hoạt động như thế nào.

Hợp đồng cốt lõi của giao thức Rollup là RollupProxy.sol, sử dụng cấu trúc proxy kép hiếm để đảm bảo tính nhất quán của cấu trúc dữ liệu, một proxy tương ứng với hai triển khai RollupUserLogic.sol và RollupAdminLogic.sol, không thể phân tích cú pháp tốt trong các công cụ như Quét.

Ngoài ra, còn có hợp đồng ChallengeManager.sol để quản lý thử thách và loạt hợp đồng OneStepProver để xác định bằng chứng gian lận.

Trong RollupProxy, một loạt các RBlocks (hay còn gọi là khẳng định) được gửi bởi các trình xác thực khác nhau được ghi lại, đó là các ô vuông trong sơ đồ sau: xanh lá cây - được xác nhận, màu xanh lam - chưa được xác nhận, màu vàng - giả mạo.

RBlock chứa trạng thái cuối cùng của một hoặc nhiều khối L2 sau khi thực hiện kể từ RBlock cuối cùng. Các RBlocks này về mặt hình thái tạo thành một Rollup Chain chính thức (lưu ý rằng bản thân sổ cái L2 là khác nhau). Trong một kịch bản lạc quan, Rollup Chain này không nên được fork, bởi vì có một fork có nghĩa là có những validator đã gửi các Rollup Blocks xung đột.

Để đưa ra hoặc đồng ý với một khẳng định, trước tiên người xác thực cần đặt cược một lượng ETH nhất định cho khẳng định và trở thành người đặt cược. Bằng cách này, trong trường hợp có bằng chứng thách thức / gian lận, tài sản thế chấp của người thua cuộc sẽ bị cắt giảm, đây là cơ sở kinh tế để đảm bảo hành vi trung thực của người xác thực.

Khối màu xanh 111 ở góc dưới bên phải của hình ảnh cuối cùng sẽ bị làm sai lệch vì khối mẹ 104 của nó là Khối sai (màu vàng).

Ngoài ra, người xác thực A đề xuất Khối tổng hợp 106, trong khi B không đồng ý, thách thức nó.

Sau khi B bắt đầu thử thách, hợp đồng ChallengeManager chịu trách nhiệm xác thực phân tích các bước thử thách:

1. Phân đoạn là một quá trình trong đó hai bên thay phiên nhau tương tác, với một bên phân đoạn dữ liệu lịch sử có trong khối tổng hợp và bên kia chỉ ra phần nào của đoạn dữ liệu có vấn đề. Tương tự như một quá trình phân đôi (N / K, thực sự) dần dần thu hẹp phạm vi.

2. Sau đó, bạn có thể tiếp tục xác định giao dịch nào và kết quả có vấn đề, sau đó chia nhỏ hơn nữa thành một lệnh máy bị tranh chấp trong giao dịch đó.

3. Hợp đồng ChallengeManager chỉ kiểm tra xem các “đoạn dữ liệu” được tạo ra có hợp lệ hay không sau khi chia nhỏ dữ liệu gốc.

4. Khi người thách thức và bên bị thách thức xác định vị trí lệnh máy cần thách thức, người thách thức gọi oneStepProveution() và gửi bằng chứng gian lận một bước để chứng minh rằng có vấn đề với kết quả thực thi lệnh máy.

Chứng minh một bước

Bằng chứng một bước là trung tâm của bằng chứng gian lận trong suốt Arbitrum. Chúng ta hãy xem những gì một bằng chứng bước chứng minh.

Điều này đòi hỏi sự hiểu biết về WAVM, Máy ảo Wasm Arbitrum, là một máy ảo được biên dịch từ các mô-đun ArbOS và các mô-đun lõi Geth (máy khách Ethereum). Vì L2 rất khác với L1 theo nhiều cách, lõi Geth ban đầu phải được sửa đổi nhẹ và hoạt động với ArbOS.

Vì vậy, chuyển đổi trạng thái trên L2 thực sự là một tính năng phổ biến của ArbOS + Geth Core.

Node Client của Arbitrum (Sequencer, Validator, Full Node, v.v.) biên dịch chương trình được xử lý bởi ArbOS + Geth Core ở trên thành mã máy gốc (cho x86 / ARM / PC / Mac / v.v.) có thể được xử lý trực tiếp bởi máy chủ Node.

Nếu bạn thay đổi ngôn ngữ đích đã biên dịch thành Wasm, bạn sẽ nhận được WAVM mà trình xác thực sử dụng để tạo bằng chứng gian lận và hợp đồng xác minh bằng chứng một bước cũng mô phỏng chức năng của máy ảo WAVM.

Lý do chính là hợp đồng xác minh bằng chứng gian lận một bước sử dụng Hợp đồng thông minh Ethereum để mô phỏng một máy ảo VM có thể xử lý một bộ lệnh nhất định và WASM rất dễ thực hiện trên hợp đồng.

Tuy nhiên, WASM chậm hơn một chút so với mã máy gốc, vì vậy WAVM sẽ chỉ được sử dụng bởi Node / Hợp đồng của Arbitrum khi bằng chứng gian lận được tạo và xác minh.

Sau các vòng phân đoạn tương tác trước đó, bằng chứng một bước cuối cùng đã được chứng minh là lệnh một bước trong tập lệnh WAVM.

Như bạn có thể thấy trong đoạn mã sau, OneStepProofEntry trước tiên xác định Mã hoạt động của lệnh được chứng minh thuộc về loại nào, sau đó gọi người chứng minh tương ứng như Mem, Toán học, v.v. và chuyển hướng dẫn từng bước vào hợp đồng prover.

Kết quả cuối cùng của afterHash sẽ trở về ChallengeManager và nếu hàm băm không nhất quán với hàm băm được ghi trên Khối tổng hợp, thử thách sẽ thành công. Nếu nó nhất quán, điều đó có nghĩa là kết quả thực hiện của lệnh được ghi trên Khối tổng hợp là tốt và thử thách không thành công.

Trong bài viết tiếp theo, chúng tôi sẽ phân tích các mô-đun hợp đồng xử lý các chức năng tương tác / bắc cầu chuỗi chéo giữa Arbitrum và thậm chí Lớp 2 và Lớp 1, và làm rõ thêm cách Lớp 2 thực sự phải chống kiểm duyệt.