Vì thiếu sự giải thích chuyên nghiệp về các bài viết hoặc tài liệu liên quan đến giao thức Layer2, đặc biệt là đối với Arbitrum và OP Rollup, trong cộng đồng người Trung Quốc, bài viết này nhằm mục đích lấp đầy khoảng trống này bằng cách giải thích cơ chế hoạt động của Arbitrum. Do tính chất phức tạp của bản thân Arbitrum nên toàn văn dù đã được đơn giản hóa hết mức có thể vẫn vượt quá 10.000 từ. Vì vậy, nó được chia thành hai phần, nên lưu lại và chia sẻ làm tài liệu tham khảo ”.

Tổng quan về Trình tự cuộn lên

Nguyên tắc chia tỷ lệ Rollup có thể được tóm tắt ở 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 Lớp 2, được vận hành theo L1. L2 chủ yếu chạy trên một máy chủ duy nhất, được gọi là trình sắp xếp/toán tử, tạo thành một chuỗi riêng biệt.

Trình sắp xếp chuỗi xuất hiện gần giống như một máy chủ tập trung về mặt nhận thức, từ bỏ tính phân cấp trong 'bộ ba blockchain không thể' để đạt được lợi thế về TPS và chi phí. Người dùng có thể sử dụng 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.

(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 được đồng bộ hóa với Ethereum L1 và tính hợp lệ của chúng được xác minh thông qua các hợp đồng chuyển đổi trạng thái. Đồng thời, Ethereum vẫn giữ lại lịch sử của L2, vì vậy ngay cả khi trình sắp xếp chuỗi bị hỏng vĩnh viễn, những người khác vẫn có thể tái tạo lại toàn bộ trạng thái của L2 thông qua các bản ghi Ethereum.

Về cơ bản, tính bảo mật của Rollup phụ thuộc vào 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 thay mặt cho tài khoản đó hoặc thao túng 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).

Trong khi trình sắp xếp trình tự, với tư cách là trung tâm trung tâm, có khía cạnh tập trung, thì trong các giải pháp Tổng hợp hoàn thiện, trình sắp xếp trình tự tập trung chỉ có thể tham gia vào các hoạt động độc hại nhẹ, chẳng hạn như kiểm duyệt giao dịch hoặc các sự cố độc hại. Trong kịch bản Tổng hợp lý tưởng, sẽ có các biện pháp tương ứng để hạn chế những hành động như vậy, chẳng hạn như rút tiền bắt buộc hoặc sắp xếp các bằng chứng cho cơ chế chống kiểm duyệt.

(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ơ chế xác minh trạng thái nhằm ngăn chặn các hành động độc hại của trình sắp xếp tổng hợp được chia thành hai loại: Bằng chứng gian lận và Bằng chứng hợp lệ. Các giải pháp tổng hợp sử dụng Bằng chứng gian lận được gọi là Tổng hợp OP (Tổng hợp lạc quan, OPR), trong khi những giải pháp sử dụng Bằng chứng hợp lệ thường được gọi là Tổng hợp ZK (Tổng hợp bằng chứng không có kiến thức, ZKR) thay vì Tổng hợp hợp lệ do lịch sử.

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

Do đó, OPR ngụ ý một giả định về độ tin cậy: tại bất kỳ thời điểm nào, có ít nhất một nút xác thực L2 trung thực. Mặt khác, các hợp đồng ZKR xác nhận một cách tích cực và không tốn kém dữ liệu do trình sắp xếp trình tự gửi thông qua các tính toán mật mã.

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

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

Bài viết này giới thiệu chuyên sâu về dự án hàng đầu trong Optimistic Rollup—Arbitrum One, 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à Optimistic Rollup/OPR.

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

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 ở các phần sau.

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

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

Đồng thời, trình sắp xếp chuỗi ngay lập tức phát Khối L2 được tạo mới nhất dưới chuỗi Ethereum ngoài chuỗi. Bất kỳ nút Layer2 nào cũng có thể nhận các Khối L2 này một cách không đồng bộ. Tuy nhiên, các Khối L2 này không có giá trị cuối cùng tại thời điểm này và có thể được khôi phục bởi trình sắp xếp chuỗi.

Cứ sau vài phút, trình sắp xếp chuỗi lại 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 đế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 Tổng hợp. Nói chung, dữ liệu L2 được gửi tới Lớp 1 không thể được khôi phục và có thể có tính xác định 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 khai sử dụng phổ biến nên nó cung cấp tính bảo mật rất kém. Nó phải dựa vào Ethereum để đảm bảo độ tin cậy của việc phát hành dữ liệu và tính hiệu quả của việc chuyển đổi trạng thái. tình dục.

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

Đây là 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 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 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 một RBlock mới (Khối cuộn lên, 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, cũng như theo dõi trạng thái của chuỗi Tổng hợp hiện tại và kiểm tra dữ liệu không chính xác do trình sắp xếp trình tự gửi.

Trình xác thực hoạt động cần đặt cọc trước tài sản trên chuỗi ETH. Đôi khi chúng tôi còn gọi nó là Staker. Mặc dù các nút Lớp 2 không đặt cọc 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à bằng chứng một 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 “nhiều vòng phân đoạn-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 tiết kiệm xăng nhất. Tất cả các liên kết đều được kiểm soát theo hợp đồng và không bên nào có thể gian lận.

Giai đoạn 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. Giai đoạn cửa sổ này là giai đoạn 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. Chỉ các thông báo tương ứng được truyề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) mới có thể được giải phóng.

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ẹ cho 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 trên L2

Luồng xử lý của một giao dịch trên 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ình sắp xếp thứ tự trước tiên 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ệ và thực hiện trình tự và tính toán.

3. Trình sắp xếp thứ tự gửi biên lai giao dịch cho người dùng (thường rất nhanh), đây chỉ là quá trình “tiền xử lý” được thực hiện bởi trình sắp xếp trong chuỗi ETH. Nó ở trạng thái Soft Finality và không đáng tin cậy. Nhưng đối với những người dùng (hầu hết người dùng) tin tưởng vào trình sắp xếp thứ tự, 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 chuỗi sẽ nén dữ liệu giao dịch gốc được xử lý trước ở mức độ cao và đóng gói nó 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ó Hard Finality.

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. Nếu chúng ta xem xét vấn đề này một cách sâu hơn, dữ liệu lô trong Hộp thư đến tuần tự sẽ ghi lại hoàn toàn thông tin đầu vào giao dịch của Lớp2. Ngay cả khi trình sắp xếp chuỗi bị 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 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 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ỉ trình sắp xếp thứ tự mới có thể gửi dữ liệu tới nó. Hộp nhanh tương ứng là Hộp thư đến của người trì hoãn hộp chậm và 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 Hộp thư đến tuần tự. Bất cứ khi nào trình sắp xếp thứ tự phát hành một lô vào hợp đồng, một sự kiện trên chuỗi sẽ được tạo ra. Sau khi Trình xác thực phát hiện sự kiện này xảy ra, nó sẽ tải xuống dữ liệu lô. Sau khi thực thi cục bộ, RBlock sẽ được cấp 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à bộ tích lũy, ghi lại lô L2 mới được gửi, cũng như số lượng và thông tin của 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 Hộp thư đến của Trình sắp xếp)

（Thông tin cụ thể của Lô; 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 From Origin()

Trình sắp xếp chuỗi sẽ gọi chức năng này mỗi lần để gửi dữ liệu Hàng loạt tới hợp đồng Sequencer Inox.

bắt buộc bao gồm()

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 tham số tích lũy trong hợp đồng bridge.

Định giá gas

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í vận hành để 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 sẽ như sau:

Chi phí xuất bản dữ liệu phát sinh do chiếm tài nguyên Lớp 1

Chi phí này chủ yếu đến từ các lô do trình sắp xếp trình tự 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 giữa 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 thứ tự 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í phát sinh do người dùng chiếm tài nguyên Lớp 2

Giới hạn gas cho TPS được thiết lập để đảm bảo hệ thống hoạt động ổn định (hiện tại là 7 triệu tại Arbitrum One). Giá hướng dẫn khí cho cả L1 và L2 đều được ArbOS theo dõi và điều chỉnh và công thức hiện không được nêu chi tiết ở đâ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.

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

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 sắp xếp trình tự gửi trong hộp nhanh, nghĩa 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 là hệ thống công bố trạng thái gốc đầu ra dưới dạng RBlock (hay còn gọi là xác nhận) lên L1 và thực hiện bằng chứng lạc quan về nó.

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. Chúng ta hãy xem xét kỹ: 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 trạng thái kết quả đầu ra có vẻ dư thừa phải không? 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 và L2, nghĩa là hành vi rút L2 về L1 đòi hỏi phải có 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à đặt hầu hết công việc tính toán và lưu trữ trên L2 để tránh chi phí cao của L1. Điều này có nghĩa là L1 không biết trạng thái của L2, nó chỉ giúp ích cho L2. Trình sắp xếp thứ tự 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 của L2.

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

Lúc này, hợp đồng Lớp 1 sẽ hỏi: Trạng thái của bạn ở Lớp 2 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 mà tin tưởng một cách 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 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, 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 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 phải được thực hiện lại trên L1. Nó không khác gì việc thực hiện các giao dịch L2 trực tiếp trên L1, điều này khiến việc mở rộng Lớp 2 trở nên vô nghĩa.

ZKR không gặp phải vấn đề này vì ZK Proof rất ngắn gọn. Nó chỉ cần xác minh một Bằng chứng rất nhỏ và không cần thực hiện nhiều giao dịch tương ứng với Bằng chứng. Vì vậy, 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 Người xác minh để 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 “nhiều vòng phân đoạn-bằng chứng một bước”. Cuối cùng, điều cần chứng minh chỉ là một mã vận hành máy ảo duy nhất và chi phí tương đối nhỏ.

Giao thức tổng hợp

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

Hợp đồng cốt lõi của giao thức Rollup là RollupProxy.sol, sử dụng cấu trúc tác nhân kép hiếm có trong khi vẫn đảm bảo cấu trúc dữ liệu nhất quán. Một tác nhân 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 bằng các công cụ như Quét.

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 chuỗi 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)

Điều này cho thấy việc ghi lại một loạt RBlocks (còn gọi là xác nhận), trong RollupProxy, được gửi bởi các Người xác thực khác nhau, đó là các hộp trong hình bên dưới: Đã xác nhận màu xanh lá cây, chưa được xác nhận màu xanh lam, đã xác nhận màu vàng.

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 một Chuỗi tổng hợp chính thức (lưu ý rằng bản thân sổ cái L2 thì khác). 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ị 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 minh.

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

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.

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

1. Phân đoạn là một quá trình trong đó cả hai bên thay phiên nhau 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ư 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. Khi người thách thức và bên bị thách thức xác định được lệnh máy sẽ bị thách thức, người thách thức gọi hàm 'oneStepProveExecution()' 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 của 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 toàn bộ 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 phải hiểu WAVM trước. Máy ảo Wasm Arbitrum là một máy ảo được biên soạn bởi mô-đun ArbOS và mô-đun lõi Geth (máy khách Ethereum). Vì L2 rất 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 tự, trình xác minh, 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 dễ dàng 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 đoạn 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 xác định mã hoạt động của lệnh cần được chứng minh thuộc về danh mục 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 hiện 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 phần 2, 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 kết nối/nhắn tin 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.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [WeChat]. Mọi bản quyền thuộc về tác giả gốc [Lu Benben]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch 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 đều bị cấm.