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

Bài viết này là phần diễn giải kỹ thuật của 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 toán tự động hóa hợp đồng thông minh Goplus Security.

Được viết bởi: Luo Benben, cựu đại sứ kỹ thuật của Arbitrum và cộng tác viên đam mê web3

**Bài viết này là cách diễn giải kỹ thuật của 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 toán tự động hóa hợp đồng thông minh Goplus Security. **

Do thiếu sự diễn giải chuyên nghiệp về Arbitrum và thậm chí cả OP Rollup trong các bài viết hoặc tài liệu liên quan đến Lớp 2 trong giới Trung Quốc, 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 bản thân cấu trúc của Arbitrum quá phức tạp nên toàn văn vẫn vượt quá 10.000 từ dù đã được đơn giản hóa hết mức có thể nên chia làm hai phần, đề nghị sưu tầm và chuyển tiếp làm tài liệu tham khảo! **

Mô tả ngắn gọn về trình sắp xếp cuộn lên

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 tác vụ tính toán và lưu trữ sang chuỗi 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à trình sắp xếp/điều hành.

Bộ sắp xếp trông giống như một máy chủ tập trung. Trong “ba khía cạnh không thể có của blockchain”, “phân quyền” bị loại bỏ để đổ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à chi phí thấp hơn nhiều so với giao dịch trên Ethereum.

(Nguồn: Chuỗi BNB)

Đảm bảo an ninh: **Nội dung giao dịch và trạng thái sau giao dịch trên L2 sẽ được đồng bộ hóa với Ethereum L1 và tính hợp lệ của việc chuyển đổi trạng thái sẽ được xác minh thông qua hợp đồng. **Đồng thời, các bản ghi lịch sử của L2 sẽ được lưu giữ trên Ethereum. Ngay cả khi trình sắp xếp chuỗi vĩnh viễn không hoạt động, 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, bảo mật của Rollup 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ể thực hiện giao dịch dưới tên tài khoản hoặc không thể giả mạo số dư tài sản của tài khoản (ngay cả khi có, nó sẽ nhanh chóng bị phát hiện).

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

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

Các phương pháp xác minh trạng thái để ngăn trình tuần tự tổng hợp thực hiện hành vi xấu được chia thành hai loại: Bằng chứng gian lận và Bằng chứng hợp lệ. Sơ đồ tổng hợp sử dụng bằng chứng gian lận được gọi là OP Rollup (Optimistic Rollup, OPR), trong khi do một số lý do lịch sử, sơ đồ Rollup sử dụng bằng chứng hợp lệ thường được gọi là ZK Rollup** (Zero-know Proof Rollup, ZKR ) thay vì Validity Rollup .

Arbitrum One là một OPR điển hình, triển khai các hợp đồng trên L1 và không chủ động xác minh dữ liệu đã gửi, lạc quan là không có vấn đề gì với dữ liệu. Nếu dữ liệu được gửi không chính xác, nút xác minh L2 sẽ chủ động bắt đầu thử thách.

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

(Phương thức vận hành Optimistic Rollup)

(Chế độ vận hành ZK Rollup)

Bài viết này sẽ giới thiệu sâu về Arbitrum One, dự án hàng đầu về 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. Sau khi đọc kỹ, bạn sẽ hiểu sâu sắc về Arbitrum và tổng hợp lạc quan/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. **Chi tiết sẽ được giới thiệu sau.

Trình tự sắp xếp:

Nhận và sắp xếp các giao dịch của người dùng, tính toán kết quả giao dịch và trả lại biên lai 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 mình được liệt kê trên L2 trong vòng vài giây và trải nghiệm cũng giống như nền tảng Web2.

Đồng thời, trình sắp xếp chuỗi cũng sẽ phát Khối L2 mới nhất ngay trong chuỗi Ethereum và bất kỳ nút Layer2 nào cũng có thể nhận nó một cách không đồng bộ. Nhưng tại thời điểm này, các Khối L2 này chưa phải là khối cuối cùng và có thể được trình sắp xếp chuỗi khôi phục lại.

Cứ sau vài phút, trình sắp xếp chuỗi sẽ nén dữ liệu giao dịch L2 đã sắp xếp, tổng hợp thành các đợt và gửi chúng đến hợp đồng hộp thư đến SequencerInbox trên Layer1 để đả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 tới Lớp 1 không thể khôi phục và có thể là dữ liệu cuối cùng.

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

Giao thức tổng hợp trọng tài:

Một loạt các hợp đồng xác định cấu trúc khối RBlock của chuỗi Rollup, phương thức tiếp tục 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 Lớp 2 mà mọi người đều hiểu, mà là một “cấu trúc dữ liệu giống chuỗi” trừu tượng được Arbitrum One thiết lập độc lập để 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. Thực thể dữ liệu RBlock của nó được lưu trữ trong một loạt hợp đồng trong RollupCore. Nếu có vấn đề với RBlock, Người xác thực sẽ thách thức người gửi RBlock.

Trình xác thực:

Các nút xác thực của Arbitrum thực sự là một tập hợp con đặc biệt của các nút đầy đủ Lớp 2 và hiện có quyền truy cập vào danh sách trắng.

Trình xác thực tạo 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 được trình sắp xếp trình tự gửi tới hợp đồng SequencerInbox,** và giám sát trạng thái của chuỗi Tổng hợp hiện tại, đồng thời đánh giá các giao dịch do trình xác thực gửi trình sắp xếp thứ tự. Thử thách với dữ liệu không chính xác. **

Trình xác thực đang hoạt động cần thế chấp trước tài sản trên chuỗi ETH, đôi khi chúng tôi còn gọi là Staker. Mặc dù các nút Lớp 2 không cam kết cũng có thể giám sát động lực hoạt động của Rollup và gửi cảnh báo bất thường cho người dùng, nhưng chúng không thể can thiệp trực tiếp vào dữ liệu lỗi do trình sắp xếp chuỗi trên chuỗi ETH gửi.

thử thách:

Các bước cơ bản có thể được tóm tắt thành nhiều vòng phân đoạn tương tác và kiểm chứng từng bước. Trong quá trình phân đoạn, trước tiên, các bên thách thức tiến hành nhiều vòng phân đoạn trên dữ liệu giao dịch có vấn đề cho đến khi họ phân tách các hướng dẫn mã hoạt động có vấn đề và tiến hành xác minh. Mô hình “**Chứng minh một bước chia nhỏ 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 tiết kiệm xăng nhất. **Tất cả các khía cạnh đều được kiểm soát theo 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 tới chuỗi, hợp đồng sẽ không chủ động kiểm tra, để lại một khoảng thời gian cho người xác minh làm sai lệch. ** Khoảng thời gian này là khoảng thời gian thử thách kéo dài 1 tuần trên mạng chính Arbitrum One. Sau khi thời gian thử thách kết thúc, RBlock cuối cùng sẽ được xác nhận và các thông báo tương ứng được chuyển từ L2 đến L1 trong khối ** (chẳng hạn như các hoạt động 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ó tên 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 trong Ethereum và Arbitrum đã thực hiện những sửa đổi nhẹ đối với nó. **ArbOS chịu trách nhiệm về 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 coi sự kết hợp của cả hai là AVM gốc, là máy ảo được Arbitrum sử dụng. WAVM là kết quả của việc biên dịch mã AVM thành Wasm. **Trong quy trình thử thách Arbitrum, “bằng chứng một bước” cuối cùng sẽ xác minh hướng dẫn WAVM. **

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

Vòng đời giao dịch L2

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

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

2. Trước tiên, trình sắp xếp sẽ xác minh các giao dịch sẽ được xử lý thành chữ ký số và dữ liệu khác, loại bỏ các giao dịch không hợp lệ, đồng thời thực hiện 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à quá trình “tiền xử lý” được thực hiện bởi trình sắp xếp chuỗi trong chuỗi ETH. Nó ở trạng thái Soft Finality và được 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), họ có thể lạc quan rằng giao dịch đã hoàn tất và sẽ không bị khôi phục.

4. Trình sắp xếp nén dữ liệu giao dịch gốc được xử lý trước ở mức độ cao và đóng gói dữ liệu đó thành một Lô.

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

Hợp đồng hộp thư đến theo trình tự

Hợp đồng sẽ nhận được lô giao dịch do người sắp xếp trình tự gửi để đảm bảo tính sẵn có 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 Lớp 2. **Ngay cả khi trình sắp xếp chuỗi khô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 Lớp 2 dựa trên bản ghi lô và thay thế trình sắp xếp chuỗi bị lỗi/đang chạy. . **

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

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

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

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

(Trình sắp xếp liên tục gửi các lô tới SequencerInbox)

• *

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

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

thêm Sequencer L2Batch From Origin(), trình sắp xếp sẽ gọi hàm này mỗi lần để gửi dữ liệu Lô tới hợp đồng Sequencer Inox.

force Inclusion(), Chức năng này 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 sau khi chúng ta nói về hợp đồng Hộp thư đến bị trì hoãn.

Hai hàm trên sẽ gọi bridge.enqueueSequencerMessage() để cập nhật bộ tích lũy tham số tích lũy trong hợp đồng bridge.

Giá xăng

Rõ ràng, các 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òn có chi phí vận hành cho chính bộ phân loại L2 và sẽ có chi phí cho việc 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, cấu trúc phí gas như sau:

Chi phí xuất bản dữ liệu phát sinh do chiếm tài nguyên Lớp 1 chủ yếu đến từ lô do người sắp xếp gử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 cho những người khởi tạo giao dịch. Thuật toán định giá phí được tạo ra khi phát hành dữ liệu rất linh hoạt và trình sắp xếp sẽ định giá dựa trên trạng thái lãi lỗ gần đây, quy mô lô và giá gas Ethereum hiện tại.

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

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.

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

Nhắc lại những điều trên, L2 thực chất chỉ là hình chiếu của lô đầu vào giao dịch được trình phân loại gửi trong hộp nhanh, tức là:

Đầu vào giao dịch -> STF -> Đầu ra trạng thái. Đầu vào đã được xác định và STF không thay đổi nên kết quả đầu ra cũng được xác định **Hệ thống chống gian lận và giao thức Arbitrum Rollup công bố gốc trạng thái đầu ra lên L1 dưới dạng RBlock (hay còn gọi là xác nhận) và là một hệ thống chứng minh lạc quan. **

Trên L1, có dữ liệu đầu vào được công bố bởi trình sắp xếp thứ tự và trạng thái đầu ra được công bố bởi trình xác minh. Hãy xem xét kỹ xem có cần thiết phải công bố trạng thái của Lớp 2 lên chuỗi không?

Vì đầu vào đã xác định hoàn toàn đầu ra và dữ liệu đầu vào được hiển thị công khai nên việc gửi kết quả đầu ra - trạng thái có vẻ dư thừa? Nhưng ý tưởng này bỏ qua nhu cầu thực tế về giải quyết trạng thái giữa hai hệ thống L1-L2, nghĩa là hành vi rút L2 về L1 yêu cầu bằng chứng về trạng thái.

Khi xây dựng Rollup, một trong những ý tưởng cốt lõi là đưa phần lớn công việc tính toán và lưu trữ lên L2 để tránh chi phí cao cho L1, nghĩa là L1 không biết trạng thái của L2, nó chỉ giúp L2 trình sắp xếp xuất bản 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 L2.

**Hành vi rút tiền về cơ bản là tuân theo thông báo chuỗi chéo do L2 đưa ra, mở khóa số tiền tương ứng từ hợp đồng L1, chuyển 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. **

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

Do đó, nếu chúng tôi xây dựng Rollup mà không có chức năng rút tiền thì về mặt lý thuyết là không thể đồng bộ hóa trạng thái với L1 và không cần hệ thống chứng minh 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 các ứng dụng 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 trạng thái đầu ra được gửi tới L1 có chính xác hay không và tin tưởng một cách lạc quan rằng mọi thứ đều chính xác. **Hệ thống chứng minh lạc quan sẽ cho rằng luôn có ít nhất một Người xác thực trung thực. Nếu xảy ra trạng thái không chính xác, trạng thái đó 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 phải chủ động xác minh mọi RBlock được cấp cho L1 để tránh lãng phí gas. Trên thực tế, đối với OPR, việc xác minh mọi xác nhận là không thực tế, vì mỗi Rblock chứa một hoặc nhiều khối L2 và mỗi giao dịch cần được thực hiện lại trên L1, không khác gì thực hiện các giao dịch L2 trực tiếp trên L1, điều này làm mất đi ý nghĩa của việc mở rộng Lớp 2.

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

**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 theo lượt “bằng chứng nhiều bước chia thành nhiều vòng”. Cuối cùng, thứ cần được chứng minh chỉ là một Máy ảo duy nhất mã hoạt động, chi phí tương đối nhỏ. **

Giao thức cuộn lên

Trước tiên chúng ta hãy xem cách thức hoạt động của giao thức Rollup, đây là điểm khởi đầu để bắt đầu các thử thách và bắt đầu bằng chứng.

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

Ngoài ra còn có hợp đồng **ChallengeManager.sol chịu trách nhiệm quản lý các thử thách và chuỗi hợp đồng OneStepProver để xác định bằng chứng gian lận. **

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

Trong RollupProxy, một loạt RBlocks (còn gọi là xác nhận) được gửi bởi Người xác thực khác nhau sẽ được ghi lại, đó là các hộp trong hình bên dưới: xanh lục - đã xác nhận, xanh lam - chưa được xác nhận, vàng - giả mạo.

**RBlock chứa trạng thái cuối cùng sau khi thực hiện một hoặc nhiều khối L2 kể từ RBlock cuối cùng. **Các RBlock này tạo thành Chuỗi tổng hợp chính thức (lưu ý rằng bản thân sổ cái L2 là khác nhau). Trong những trường hợp lạc quan, Chuỗi tổng hợp này sẽ không có phân nhánh vì phân nhánh có nghĩa là Người xác thực đã gửi Khối tổng hợp xung đột.

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

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

**Ngoài ra, người xác minh A đã đề xuất Khối tổng hợp số 106, nhưng B không đồng ý và phản đối nó. **

Sau khi B bắt đầu thử thách, hợp đồng ChallengeManager chịu trách nhiệm xác minh chi tiết các bước thử thách:

1. Phân đoạn là một quá trình trong đó 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ử có trong Khối tổng hợp nhất định và bên kia chỉ ra phần nào của đoạn dữ liệu có vấn đề. Một quá trình tương tự như sự phân đôi (thực tế là N/K) liên tục và 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 và kết quả có vấn đề, sau đó chia nhỏ nó thành một lệnh máy đang 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 sau khi phân đoạn dữ liệu gốc có hợp lệ hay không.

4. Sau khi người thách thức và người bị thách thức đã xác định được lệnh máy cần thử thách, 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 hiện lệnh máy này. **

Bằng chứng một bước

Bằng chứng một bước là cốt lõi của bằng chứng gian lận của Arbitrum. Chúng ta hãy xem chứng minh một bước cụ thể chứng minh điều gì.

Điều này đòi hỏi trước tiên phải hiểu về WAVM, **Wasm Arbitrum Virtual Machine, là một máy ảo được biên dịch bởi mô-đun ArbOS và mô-đun lõi Geth (máy khách Ethereum). **Vì L2 hoàn toàn khác với L1 nên lõi Geth ban đầu phải được sửa đổi nhẹ và hoạt động với ArbOS.

Do đó, quá trình chuyển đổi trạng thái trên L2 thực chất là công việc chung của ArbOS+Geth Core.

Máy khách nút của Arbitrum (trình sắp xếp trình tự, trình xác thực, nút đầy đủ, v.v.) biên dịch chương trình xử lý ArbOS+Geth Core nêu trên thành mã máy gốc mà máy chủ nút có thể xử lý trực tiếp (đối với x86/ARM/PC/Mac/v.v.).

Nếu bạn thay đổi ngôn ngữ đích thu được sau khi biên dịch thành Wasm, bạn sẽ nhận được WAVM được người xác minh sử dụng khi 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 các chức năng của máy ảo WAVM.

**Vậy tại sao nó cần được biên dịch thành mã byte Wasm khi tạo bằng chứng gian lận? **Lý do chính là để xác minh hợp đồng chống gian lận một bước, cần sử dụng hợp đồng thông minh Ethereum để mô phỏng máy ảo VM có thể xử lý một bộ tập lệnh nhất định và WASM rất dễ thực hiện 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 gốc, vì vậy các nút/hợp đồng của Arbitrum sẽ chỉ sử dụng WAVM khi tạo và xác minh bằng chứng gian lận.

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

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

Kết quả cuối cùng sauHash sẽ được trả về ChallengeManager. Nếu hàm băm không nhất quán với hàm băm sau thao tác lệnh được ghi trên Khối tổng hợp thì thử thách đã 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 thi của lệnh này được ghi trên Khối tổng hợp và thử thách đã thất bại.

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