Chuyển Tiêu Đề Gốc:

Bài viết này cung cấp một giải thích kỹ thuật về Arbitrum One của Luo Benben (罗奔奔), cựu đại sứ kỹ thuật của Arbitrum và cựu đồng sáng lập công ty kiểm định tự động hợp đồng thông minh Goplus Security.

Do vì thiếu sự giải thích chuyên nghiệp về Arbitrum và thậm chí OP Rollup trong các bài viết hoặc tài liệu tiếng Trung liên quan đến Layer 2, bài viết này cố gắng điền vào 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. Vì cấu trúc của Arbitrum chính nó quá phức tạp, mặc dù toàn bộ văn bản đã được đơn giản hóa càng nhiều càng tốt, nhưng vẫn vượt quá 10.000 từ, nên nó được chia thành hai phần. Đề xuất thu thập và chuyển tiếp nó như một tài liệu tham khảo!

Giới thiệu ngắn gọn về Rollup sequencer

Nguyên tắc mở rộng Rollup có thể được tóm tắt thành hai điểm:

Tối ưu hóa chi phí: Chuyển hầu hết các nhiệm vụ tính toán và lưu trữ sang offchain L1, 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à bộ sắp xếp / người vận hành.

Trình tự viên gần giống một máy chủ tập trung ở một khía cạnh. Trong “tam giác bất khả thi của blockchain”, “phi tập trung” bị bỏ rơi để đổi lấy lợi ích về TPS và chi phí. Người dùng có thể để cho L2 xử lý hướng dẫn giao dịch thay vì Ethereum, và chi phí thấp hơn nhiều so với việc giao dịch trên Ethereum.

(Nguồn: Chuỗi BNB)

Bảo đảm an ninh: Nội dung giao dịch và trạng thái kết quả trên Layer 2 được đồng bộ hóa với Layer 1 của Ethereum, nơi tính hợp lệ của chúng được xác minh thông qua hợp đồng. Trong khi đó, Ethereum giữ lại các bản ghi lịch sử của L2, vì vậy ngay cả khi sequencer gặp sự cố vĩnh viễn, người khác vẫn có thể tái tạo toàn bộ trạng thái của L2 từ các bản ghi trên Ethereum.

Về cơ bản, tính bảo mật của Rollup dựa trên Ethereum. Nếu một trình tự không biết khóa riêng của tài khoản, nó không thể bắt đầu giao dịch thay mặt cho tài khoản đó hoặc giả mạo số dư tài sản của tài khoản đó (ngay cả khi cố gắng, nó sẽ nhanh chóng bị phát hiện).

Mặc dù bộ xử lý chuỗi, như trung tâm của hệ thống, có thể có một sắc tộc tập trung, trong các giải pháp Rollup chín chắn, một bộ xử lý chuỗi tập trung chỉ có thể tham gia vào hành vi độc hại mềm như kiểm duyệt giao dịch hoặc sự cố độc hại. Tuy nhiên, trong các giải pháp Rollup lý tưởng, có các biện pháp tương ứng để kiềm chế những hành vi đó (như rút tiền bắt buộc hoặc sắp xếp chứng minh như cơ chế chống kiểm duyệt).

(Giao thức Loopring thiết lập một chức năng rút ép buộc trong mã nguồn hợp đồng trên L1 để người dùng gọi)

Để ngăn chặn hành vi độc hại từ các sequencer Rollup, có hai loại phương pháp xác minh trạng thái: Bằng chứng Lừa đảo và Bằng chứng Đúng đắn. Các giải pháp Rollup sử dụng Bằng chứng Lừa đảo được gọi là Optimistic Rollup (OPR), trong khi những giải pháp sử dụng Bằng chứng Đúng đắn thường được gọi là ZK Rollup (Zero-knowledge Proof Rollup, ZKR), thay vì Validity Rollup, do lịch sử của nó.

Arbitrum One là một OPR điển hình, triển khai trên các hợp đồng L1, không actively xác minh dữ liệu được gửi lên mạng mà lạc quan giả định rằng dữ liệu là chính xác. Nếu có lỗi trong dữ liệu được gửi lên, các người xác minh L2 sẽ khởi động các thách thức.

Do đó, OPR cũng ngụ ý một giả định về sự tin cậy: vào bất kỳ thời điểm nào cũng có ít nhất một nút xác minh L2 trung thực. Trong khi đó, hợp đồng ZKR xác minh dữ liệu được gửi bởi sequencer một cách tích cực và hiệu quả về chi phí thông qua các tính toán mật mã.

(Phương pháp vận hành Optimistic Rollup)

(Phương pháp hoạt động ZK Rollup)

Bài viết này sẽ cung cấp một giới thiệu sâu sắc về dự án hàng đầu trong phương pháp Optimistic Rollup — Arbitrum One, bao gồm tất cả các khía cạnh của hệ thống. Sau khi đọc kỹ, bạn sẽ có được một hiểu biết sâu sắc về Arbitrum và Optimistic Rollup (OPR).

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

Các Hợp Đồng Cốt Lõi:

Các hợp đồng quan trọng nhất trong Arbitrum bao gồm SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, v.v. Những điều này sẽ được trình bày chi tiết sau.

Sequencer:

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

Ngoài ra, bộ xử lý ngay lập tức phát sóng các khối L2 mới nhất được tạo ra dưới chuỗi Ethereum, mà bất kỳ nút Layer 2 nào cũng có thể nhận một cách không đồng bộ. Tuy nhiên, tại thời điểm này, những khối L2 này chưa hoàn thành và có thể bị bắt lại bởi bộ xử lý.

Mỗi vài phút, bộ xử lý nén dữ liệu giao dịch L2 đã được sắp xếp, tổng hợp chúng thành các lô và gửi chúng đến hợp đồng SequencerInbox trên Layer 1 để đảm bảo sẵn có dữ liệu và hoạt động của giao thức Rollup. Thông thường, dữ liệu L2 gửi đến Layer 1 không thể bị quay trở lại và có thể có tính cuối cùng.

Từ quá trình trên, chúng ta có thể tóm tắt rằng Lớp 2 có mạng lưới các nút riêng, nhưng các nút này có số lượng ít và thường thiếu các giao thức đồng thuận thường được sử dụng trong các blockchain công khai. Do đó, tính bảo mật của họ kém và họ phải dựa vào Ethereum để đảm bảo độ tin cậy của việc xuất bản dữ liệu và tính hợp lệ của quá trình chuyển đổi trạng thái.

Giao protocôl Arbitrum Rollup:

Xác định cấu trúc của các khối, được gọi là RBlocks, trên chuỗi Rollup, sự tiếp tục của chuỗi, xuất bản RBlocks và quy trình chế độ thử thách, v.v., thông qua một loạt các hợp đồng. Điều quan trọng cần lưu ý là chuỗi Rollup được đề cập ở đây không phải là sổ cái thường được hiểu là Lớp 2, mà là một "cấu trúc dữ liệu giống như chuỗi" trừu tượng được thiết lập độc lập bởi Arbitrum One để thực hiện các 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à thực thể dữ liệu của nó, RBlock, được lưu trữ trong một loạt các hợp đồng trong RollupCore. Nếu có vấn đề với một RBlock, các nhà xác minh sẽ thách thức dựa trên các đơn từ người tạo RBlock.

Validators:

Validators in Arbitrum are actually a special subset of Layer 2 full nodes, currently with whitelist admission.

Validators tạo các RBlocks mới (các khối Rollup, cũng được gọi là nhận định) dựa trên các lô giao dịch được gửi đến hợp đồng SequencerInbox bởi sequencer, và theo dõi trạng thái hiện tại của chuỗi Rollup để thách thức dữ liệu không chính xác được gửi bởi sequencer.

Các nhà xác thực hoạt động cần đặt cược tài sản trên chuỗi Ethereum trước, và đôi khi được gọi là người cược. Mặc dù các nút Layer 2 không đặt cược tài sản vẫn có thể theo dõi hoạt động của Rollup và gửi cảnh báo cho người dùng về các bất thường, nhưng họ không thể can thiệp trực tiếp vào dữ liệu không chính xác được gửi bởi sequencer trên chuỗi Ethereum.

Thách thức:

Các bước cơ bản có thể được tóm tắt dưới dạng phân chia tương tác nhiều vòng và bằng chứng một bước. Trong giai đoạn phân chia, cả hai người thách thức trước tiên tham gia vào việc phân chia tương tác nhiều vòng của dữ liệu giao dịch có vấn đề cho đến khi lệnh opcode có vấn đề được phân tách và xác minh. Mô hình "bằng chứng một bước phân chia nhiều vòng" đượ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. Tất cả các bước được kiểm soát bởi các hợp đồng thông minh và không bên nào có thể gian lận.

Thời gian Thách thức:

Do với 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 kiểm tra nó một cách chủ động, để lại một khoảng thời gian cho các nhà xác minh để làm giả nó. Khoảng thời gian này là thời gian thách thức, là một tuần trên mainnet Arbitrum One. Sau khi kết thúc thời gian thách thức, RBlock sẽ được xác nhận cuối cùng, và các thông điệp tương ứng với các giao dịch từ L2 đến L1 (như các hoạt động rút tiền được thực hiện thông qua cầu chính thức) có thể được phát hành.

ArbOS, Geth, WAVM：

Arbitrum sử dụng một máy ảo gọi là AVM, bao gồm Geth và ArbOS. Geth là phần mềm máy khách được sử dụng phổ biến nhất cho 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 và phối hợp với EVM. Chúng tôi coi 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ã AVM thành Wasm. Trong quá 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ể đại diện cho các mối quan hệ và quy trình làm việc giữa các thành phần khác nhau bằng biểu đồ dưới đây:

Vòng đời Giao dịch L2

Quy trình xử lý giao dịch L2 như sau:

1. Người dùng gửi hướng dẫn giao dịch đến sequencer.
2. Bộ xử lý tuần tự đầu tiên xác minh dữ liệu, bao gồm chữ ký số, của các giao dịch cần xử lý, lọc ra các giao dịch không hợp lệ, sau đó sắp xếp và tính toán chúng.
3. Bộ xử lý chuỗi gửi biên nhận giao dịch cho người dùng (thường rất nhanh), nhưng đây chỉ là “tiền xử lý” được thực hiện bởi bộ xử lý chuỗi trên chuỗi Ethereum, và nó đang ở trạng thái Soft Finality và không đáng tin cậy. Tuy nhiên, đối với người dùng tin tưởng bộ xử lý chuỗi (hầu hết người dùng), họ có thể lạc quan giả định rằng giao dịch đã được hoàn thành và sẽ không bị quay trở lại.
4. Sequencer bao gồm dữ liệu giao dịch được xử lý trước đó thành một Batch sau khi nén cao.
5. Định kỳ (bị ảnh hưởng bởi các yếu tố như khối lượng dữ liệu và tắc nghẽn Ethereum), bộ sắp xếp công bố giao dịch Batch cho hợp đồng Hộp thư Bộ sắp xếp trên L1. Tại thời điểm này, có thể coi rằng giao dịch đã Có tính ổn định mạnh mẽ.

Hợp đồng Hộp thư Sequencer

Hợp đồng nhận các lô giao dịch được gửi bởi bộ sắp xếp để đảm bảo sẵn có dữ liệu. Chi tiết, dữ liệu lô trong Hộp thư Bộ sắp xếp ghi đầy đủ thông tin đầu vào giao dịch của Layer2. Ngay cả khi bộ sắp xếp gặp sự cố 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 Layer2 dựa trên các bản ghi của lô và tiếp quản bộ sắp xếp bị lỗi/thiếu sót.

Trong một phân tương tự vật lý, những gì chúng ta thấy là L2 chỉ là hình chiếu của các gói tin trong Hộp thứ tự, trong khi nguồn sáng là Soft Finality. Bởi vì nguồn sáng Soft Finality không thay đổi dễ dàng, hình dạng của bóng chỉ được xác định bởi các gói tin hoạt động như một đối tượng.

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

Người xác minh sẽ liên tục theo dõi hợp đồng Hộp thư Sequencer. Mỗi khi sequencer xuất bản một Lô vào hợp đồng này, một sự kiện trên chuỗi được kích hoạt. Sau khi phát hiện sự kiện này, người xác minh sẽ tải dữ liệu lô, thực thi nó cục bộ, sau đó công bố một RBlock cho hợp đồng giao thức Rollup trên chuỗi Ethereum.

Hợp đồng cầu Arbitrum có một tham số gọi là bộ tích lũy, ghi lại thông tin về lô L2 mới được gửi và số giao dịch nhận được trên Hộp thư đến chậm, cùng với những điều khác.

（Bộ xử lý liên tục gửi các lô hàng đến Hộp thư Bộ xử lý）

(Thông tin cụ thể của Batch, trường dữ liệu tương ứng với dữ liệu Batch. Kích thước của phần dữ liệu này rất lớn, và ảnh chụp màn hình không được hiển thị đầy đủ.)

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

thêm Sequencer L2Batch Từ Origin()，Sequencer sẽ gọi hàm này mỗi lần gửi dữ liệu Batch đến hợp đồng Sequencer Inox.

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

Các chức năng trên sẽ gọi “bridge.enqueueSequencerMessage()” để cập nhật tham số tổng thuộc tính accumulator trong hợp đồng cầu.

Giá gas

Rõ ràng, giao dịch L2 không thể miễn phí, vì điều này sẽ dẫn đến các cuộc tấn công DoS. Ngoài ra, có chi phí vận hành cho bộ lọc L2 chính, và sẽ có chi phí chồng lên cho việc gửi dữ liệu trên L1. Khi người dùng khởi tạo một giao dịch trong mạng Lớp 2, cấu trúc phí gas như sau:

Chi phí xuất bản dữ liệu do chiếm dụng tài nguyên Layer1 chủ yếu đến từ các lô được nộp bởi sequencer (mỗi lô chứa giao dịch từ nhiều người dùng), và cuối cùng chi phí được chia sẻ giữa các người khởi tạo giao dịch. Thuật toán định giá cho phí giao dịch được tạo ra bởi việc xuất bản dữ liệu là động. Sequencer điều chỉnh giá dựa trên điều kiện lợi nhuận và lỗ gần đây, kích thước lô và giá gas Ethereum hiện tại.

Chi phí mà người dùng phải chi trả cho việc sử dụng các nguồn tài nguyên Layer2 được xác định bằng cách đặt một giới hạn tối đa về khí được xử lý mỗi giây để đảm bảo hoạt động ổn định của hệ thống (hiện tại Arbitrum One là 7 triệu). Các mức giá hướng dẫn về khí cho cả L1 và L2 được theo dõi và điều chỉnh bởi ArbOS, và công thức không được trình bày ở đây.

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

Chứng minh lừa đảo lạc quan

Nhìn lại vào văn bản trước đó, rõ ràng Layer2 (L2) chỉ là một phản chiếu cơ bản của các lô đầu vào giao dịch được gửi bởi bộ sắp xếp trong Hộp thư Bộ sắp xếp:

Transaction Inputs -> Chức năng Chuyển trạng thái (STF) -> Đầu ra trạng thái

Các đầu vào đã được xác định, và STF là bất biến, do đó kết quả đầu ra cũng đã được xác định. Chứng minh gian lận và hệ thống giao thức Arbitrum Rollup công bố trạng thái đầu ra, được biểu diễn bằng một RBlock (còn được gọi là một khẳng định), cho Layer1 và cung cấp chứng minh lạc quan cho nó.

Trên L1, có cả dữ liệu đầu vào được xuất bởi sequencer và trạng thái đầu ra được xuất bởi validator. Sau khi xem xét cẩn thận, liệu việc xuất trạng thái của Layer2 trên chuỗi là cần thiết không? Bởi vì các đầu vào đã hoàn toàn xác định các đầu ra, và dữ liệu đầu vào là công khai, việc gửi kết quả đầu ra hoặc trạng thái dường như là dư thừa. Tuy nhiên, ý tưởng này đã bỏ qua việc cần có một việc giải quyết trạng thái giữa các hệ thống L1 và L2. Điều này đặc biệt cần thiết cho các hành động rút tiền từ L2 về L1, mà yêu cầu bằng chứng về trạng thái.

Khi xây dựng Rollup, ý tưởng cốt lõi là chuyển giao hầu hết các tính toán và lưu trữ sang L2 để tránh chi phí cao của L1. Điều này ngụ ý rằng L1 không biết trạng thái của L2; nó chỉ hỗ trợ người xếp hàng L2 trong việc xuất bản dữ liệu đầu vào cho 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.

Các hành động rút tiền về cơ bản liên quan đến việc mở khóa tài sản tương ứng từ hợp đồng L1 dựa trên các thông điệp mã thông báo qua chuỗi từ L2 và chuyển chúng đến tài khoản L1 của người dùng hoặc hoàn thành các nhiệm vụ khác.

Tại thời điểm này, hợp đồng Layer1 sẽ hỏi: trạng thái của bạn trên Layer2 là gì, và bạn chứng minh thế nào rằng bạn thực sự sở hữu tài sản mà bạn đang khẳng định muốn chuyển nhượng? Ở giai đoạn này, người dùng cần cung cấp các Chứng minh Merkle tương ứng, v.v.

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

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

Ưu điểm của thiết kế này là không cần xác minh mỗi RBlock được phát hành đến L1 một cách tích cực để tránh lãng phí gas. Trong thực tế, đối với OPR, việc xác minh mỗi khẳng định là không thực tế, vì mỗi Rblock chứa một hoặc nhiều L2 blocks, và mỗi giao dịch phải được thực thi lại trên L1. Điều này không khác gì việc thực thi giao dịch L2 trực tiếp trên L1, làm mất đi ý nghĩa của tính mở rộng Layer 2.

ZKR không phải đối mặt với vấn đề này vì Bằng chứng ZK có tính súc tích, chỉ yêu cầu xác minh một bằng chứng nhỏ mà không cần thực sự thực hiện nhiều giao dịch đằng sau bằng chứng. Do đó, ZKR không hoạt động một cách lạc quan; mỗi lần công bố trạng thái đều đi kèm với việc xác minh toán học bởi một hợp đồng Verifier.

Mặc dù bằng chứng gian lận không thể đạt được mức độ ngắn gọn cao như bằng chứng không biết, Arbitrum sử dụng một quá trình tương tác 'phân chia đa vòng - chứng minh một bước' , trong đó cuối cùng chỉ cần chứng minh một opcode máy ảo duy nhất, dẫn đến chi phí tương đối thấp.

Giao thức Rollup

Hãy để chúng ta trước tiên xem xét cổng vào để khởi xướng thách thức và bắt đầu chứng minh, tức là cách mà giao thức Rollup hoạt động.

Hợp đồng nhân vật chính của giao thức Rollup là RollupProxy.sol. Trong khi đảm bảo cấu trúc dữ liệu nhất quán, sử dụng một cấu trúc đặc biệt với hai đại lý. Một đại lý tương ứng với hai triển khai của RollupUserLogic.sol và RollupAdminLogic.sol, không thể phân tích tốt bởi các công cụ như Scan.

Hơn nữa, hợp đồng ChallengeManager.sol chịu trách nhiệm quản lý các thách thức, và các hợp đồng loạt OneStepProver được sử dụng để xác định bằng chứng gian lận.

(Nguồn: trang web chính thức của L2BEAT)

Trong RollupProxy, một loạt các RBlocks (cũng được biết đến là các khẳng định) được gửi bởi các nhà xác minh khác nhau được ghi lại, được đại diện bởi các khối trong sơ đồ: màu xanh lá cây cho đã xác nhận, màu xanh dương cho chưa xác nhận, và màu vàng cho bị chứng minh là không đúng.

RBlock chứa trạng thái cuối cùng sau khi thực thi một hoặc nhiều khối L2 kể từ RBlock trước đó. Các RBlock này tạo thành một Chuỗi Rollup về hình thức (lưu ý sự phân biệt so với sổ cái L2 chính nó). Trong kịch bản lạc quan, Chuỗi Rollup này không nên có forks, vì forking ngụ ý validators nộp các khối Rollup mâu thuẫn.

Để đề xuất hoặc đồng ý với một phát biểu, người xác minh cần đặt cược một số lượng ETH nhất định, trở thành một Người đặt cược. Điều này đảm bảo cơ sở kinh tế cho hành vi trung thực giữa các người xác minh, vì số cược của người thua sẽ bị tịch thu trong trường hợp có thách thức/chứng cớ gian lận.

Khối màu xanh sóng đánh số 111 ở góc dưới bên phải của biểu đồ sẽ cuối cùng bị chứng minh là không đúng vì khối cha của nó, khối số 104, là không chính xác (màu vàng).

Ngoài ra, Validator A đã đề xuất Block Rollup 106, mà Validator B không đồng ý và thách thức.

Sau khi B khởi xướng thách thức, hợp đồng ChallengeManager chịu trách nhiệm xác minh phân đoạn của các bước thách thức:

1. Phân đoạn là quá trình mà cả hai bên lần lượt tương tác. Một bên phân đoạn dữ liệu lịch sử chứa trong một Block Rollup cụ thể, và bên kia chỉ ra phần nào của dữ liệu là có vấn đề. Một quá trình tương tự như sự phân chia đôi (thực sự là N/K) mà liên tục và dần dần thu hẹp phạm vi.

2. Sau đó, có thể xác định cụ thể hơn giao dịch nào và kết quả của nó gây vấn đề, sau đó chia nhỏ hơn vào hướng dẫn máy cụ thể trong giao dịch đó mà bị tranh cãi.

3. Hợp đồng ChallengeManager chỉ xác minh xem phân đoạn “dữ liệu” được tạo ra sau khi phân chia dữ liệu gốc có hợp lệ hay không.

4. Khi bên thách thức và bên bị thách thức xác định hướng dẫn máy cần bị thách thức, bên thách thức gọi oneStepProveExecution() để gửi một bằng chứng gian lận từng bước, chứng minh rằng kết quả thực thi của hướng dẫn máy này là không chính xác.

Chứng minh một bước

Chứng minh bước đơn là cốt lõi của toàn bộ chứng minh gian lận Arbitrum. Hãy xem chứng minh bước đơn chứng minh cụ thể như thế nào.

Điều này đòi hỏi hiểu WAVM trước tiên. Máy ảo Arbitrum Wasm là một máy ảo được biên dịch bởi mô-đun ArbOS và mô-đun nhân Geth (khách hàng Ethereum). Vì L2 rất khác biệt so với L1, nhân Geth ban đầu đã phải được chỉnh sửa nhẹ và làm việc với ArbOS.

Do đó, quá trình chuyển trạng thái trên L2 thực sự là kết quả của sự cộng tác giữa ArbOS+Geth Core.

Khách hàng nút của Arbitrum (sequencer, validator, full node, v.v.) biên dịch chương trình xử lý ArbOS+Geth Core được đề cập ở trên thành mã máy nguyên bản mà máy chủ nút có thể xử lý trực tiếp (cho x86/ARM/PC/Mac/v.v.).

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

Vì sao cần biên dịch thành mã bytecode Wasm khi tạo bằng chứng gian lận? Lý do chính là để xác minh hợp đồng của bằng chứng gian lận theo từng bước, cần 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 tập hợp cụ thể các tập lệnh, và WASM dễ dàng triển khai mô phỏng trên hợp đồng.

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

Sau các vòng trò chia tách tương tác trước đó, bằng chứng một bước duy nhất cuối cùng đã chứng minh hướng dẫn một bước duy nhất trong bộ chỉ thị WAVM.

Như có thể thấy trong mã dưới đây, OneStepProofEntry đầu tiên xác định xem mã hoạt động của hướng dẫn cần được chứng minh thuộc về danh mục nào, sau đó gọi các prover tương ứng như Mem, Math, 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 sauHash sẽ được trả về cho ChallengeManager. Nếu hash không nhất quán với hash sau khi thực hiện thao tác được ghi lại trên Rollup Block, thì thách thức sẽ thành công. Nếu chúng nhất quán, điều đó có nghĩa là không có vấn đề gì với kết quả thực hiện của lệnh này được ghi lại trên Rollup Block, và thách thức sẽ thất bại.

Disclaimer：

1. Bài viết này được sao chép từ [Chuyên viên sáng tạo Web3], Tất cả bản quyền thuộc về tác giả gốc [Luo Benben, cựu đại sứ kỹ thuật của Arbitrum, cống hiến cho cộng đồng web3]. Nếu có ý kiến phản đối về việc tái in này, vui lòng liên hệ với Gate Họcđội ngũ, và họ sẽ xử lý ngay lập tức.
2. Bản Tuyên Bố Miễn Trừ Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.
3. Bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.