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)

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

Bài viết này được viết bởi Luo Benben, cựu đại sứ kỹ thuật 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 Bảo mật Giải thích kỹ thuật của Arbitrum One.

Vì 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 vòng tròn Trung Quốc, bài viết này cố gắng lấp đầy điều này lĩnh vực bằng cách phổ biến cơ chế vận hành Trọng tài của các vị trí tuyển dụng. Vì bản thân cấu trúc của Arbitrum quá phức tạp nên toàn bộ bài viết cũng 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!

Bộ sắp xếp cuộn lên được đơn giản hóa description

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 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, từ bỏ "sự phân quyền" trong "ba khía cạnh không thể có của blockchain" để đổ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: BNB Chain)

Đả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, xác minh hiệu lực của việc chuyển đổi trạng thái 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 ngừ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, tính 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, như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 hoạt động xấu xa mềm như xem xét giao dịch. Tuy nhiên, trong giải pháp Tổng hợp lý tưởng , thì có những phương tiện tương ứng để ngăn chặn nó (chẳng hạn như các cơ chế chống kiểm duyệt như buộc rút lui hoặc phân loại bằng chứng).

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

Để ngăn chặn việc sắp xếp Rollup phương pháp xác minh trạng thái cho các tác nhân độc hại được chia thành hai loại: Bằng chứng gian lận và Bằng chứng hợp lệ. Lược đồ tổng hợp sử dụng bằng chứng gian lận được gọi là OP Rollup (Tổng hợp tối ưu, OPR) và do một số vấn đề lịch sử nên lược đồ tổng hợp sử dụng bằng chứng hợp lệ thường được gọi là ZK Rollup (Zero-know Proof Rollup, ZKR).

Arbitrum One là một OPR điển hình. Nó triển khai các hợp đồng trên L1 và không tích cực xác minh dữ liệu đã gửi. Điều 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 bao hàm 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 vào bất kỳ lúc 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 chủ động nhưng tiết kiệm chi phí cho dữ liệu do trình sắp xếp trình tự gửi.  

(Chế độ hoạt động Optimistic Rollup)

< /p>

(Chế độ thao tác ZK Rollup)

Bài viết này sẽ giới thiệu nó chuyên sâu Arbitrum One, dự án hàng đầu trong Optimistic Rollup, 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 của Arbitrum bao gồmSequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, v.v. Thông tin chi tiết sẽ được giới thiệu sau.

Trình sắp xếp chuỗi:

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 một cách nhanh chóng (thường là <1s ) Trả lại biên lai cho người dùng. 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, bộ sắp xếp sẽ nén dữ liệu giao dịch L2 đã sắp xếp, tổng hợp thành một đợt và gửi đến hợp đồng hộp thư đến 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ể 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ó nút riêng mạng, tuy nhiên số lượng các nút này còn thưa thớt và nhìn chung không có giao thức đồng thuận thường được sử dụng trong các chuỗi công khai nên tính bảo mật rất kém, 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à hiệu quả của việc chuyển đổi trạng thái.

Giao thức Arbitrum Rollup:

Xác định cấu trúc khối RBlock của chuỗi Rollup , phương pháp tiếp tục chuỗi, phát hành RBlock và một loạt hợp đồng như 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 trình xác thực của Arbitrum thực chất 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 dựa trên lô giao dịch được trình sắp xếp thứ tự gửi tới hợp đồng SequencerInbox(Khối cuộn lên, còn được gọi là xác nhận),và theo dõi trạng thái của chuỗi Tổng hợp hiện tại, đồng thời xác nhận dữ liệu không chính xác do trình sắp xếp trình tự gửi.

Active Validator cần cầm 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 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 chia tương tác và chứng minh 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 "bằng chứng 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 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 hoạt động kiểm tra và dành trước một khoảng thời gian để người xác minh làm sai lệch. Thời gian 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 và các thông báo tương ứng 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 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 Hai phần. 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 phần mềm này. 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

Một luồng 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ệ cũng như thực hiện sắp xếp 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), nhưng đây chỉ là trình sắp xếp thứ tự trong chuỗi ETH. "tiền xử lý" được thực hiện ở trạng thái Cuối cùng mềm 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), 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, tắc nghẽn ETH, v.v.), trình sắp xếp chuỗi sẽ gửi dữ liệu tới Bộ sắp xếp thứ tự trên L1. Hợp đồng hộp thư đến xuất bản lô giao dịch. 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 tuần tự< /h3>

Hợp đồng sẽ nhận được lô giao dịch do trình sắp xếp trình tự gửi để đảm bảo tính sẵn có của dữ liệu. Xem xét kỹ 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 tuần tự 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à tiếp quản phần bị lỗi /thiết bị sắp xếp chạy trốn.

Sử dụng phương pháp vật lý, L2 mà chúng ta thấy chỉ là hình chiếu của lô trong SequencerInbox và 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ể tới nó. Và chỉ Dữ liệu của trình sắp xếp mới có thể được nộp cho 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à sau khi thực thi cục bộ, phát hành RBlock cho hợp đồng giao thức Rollup trên chuỗi ETH.  

Có một chức năng gọi là tích lũy trong cầu nối của Arbitrum hợp đồng Các thông số của bộ tích lũy sẽ được ghi lại cho lô L2 mới gửi, cũng như số lượng và thông tin các giao dịch mới nhận vào 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ể theo lô, trường dữ liệu tương ứng với Dữ liệu hàng loạt, 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 sẽ gọi hàm này mỗi lần gửi dữ liệu Batch tới 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 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á 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. Trong Ngoài ra, còn có chi phí vận hành của chính bộ phân loại L2 cũng như 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, cấu trúcphí gas như sau: 

Chi phí xuất bản dữ liệu phát sinh do chiếm giữ Tài nguyên lớp 1,Chủ yếu đến từ các lô do trình sắp xếp thứ 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 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 chịu do chiếm tài nguyên Lớp 2 đặt giới hạn gas mỗi giây có thể đả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ù quy 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 hãy lưu ý về nó Nhìn vào những chi tiết này, có thể thấy rõ rằng phí giao dịch Rollup rẻ hơn nhiều so với phí giao dịch trên 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à công cụ phân loại trong hộp nhanh Hình chiếu của lô đầu vào giao dịch được gửi trong , đó là:

Đầu vào giao dịch -> STF -> Đầu ra trạng thái. Đầu vào đã được xác định, STF không thay đổi và 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à 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à 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 chuỗi 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 trạng thái kết quả đầu ra 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 của L1, nghĩa là L1 không biết trạng thái của L2. Nó chỉ giúp bộ phân loại L2 công bố dữ liệu đầu vào của tất cả các giao dịch chứ 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 dựa trên 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 và chuyển chúng vào tài khoản L1 của người dùng hoặc thực hiện các nhiệm vụ khác đồ đạ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 cách nào để chứng minh rằng bạn thực sự có những tuyên bố này để vượt qua? . 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.

Vì vậy, nếu chúng tôi xây dựng một Bản tổng hợp 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ù 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 bằng chứng lạc quan sẽ cho rằng có ít nhất một Người xác thực trung thực bất cứ lúc nào. 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 phải được thực hiện lại trên L1, 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 làm mất đi giá trị ý 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 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 sự thực hiện nhiều bước tương ứng đằng sau Bằng chứng giao dịch. 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 phương pháp vòng tròn "bằng chứng chia nhiều vòng-một bước" Trong Quá trình tương tác, điều cuối cùng 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 cuộn lên

Trước tiên, chúng ta hãy xem lối vào để bắt đầu thử thách và bắt đầu proofs , tức là cách thức 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. Trong khi đả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 được sử dụng, một tác nhân tương ứng với The hai triển khai RollupUserLogic.sol và RollupAdminLogic.sol hiện 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 chịu trách nhiệm quản lý các thách thức và chuỗi hợp đồng OneStepProver để xác định bằng chứng gian lận.

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

Trong RollupProxy, các bản ghi được xử lý bằng nhiều cách khác nhau Trình xác thực Một loạt RBlock được gửi (còn gọi là xác nhận), tức 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 The 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, người xác minh cần phải cam kết 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ị tịch thu, đâ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 ả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ó.

Cuối cùng thì thử thách ở B , hợp đồng ChallengeManager chịu trách nhiệm xác minh quy trình phân chia của các bước thử thách:

1. Phân chia là một quá trình trong đó cả hai bên thay phiên nhau thực hiện Dữ liệu lịch sử chứa trong mỗi Khối tổng hợp được phân đoạn 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 còn 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 đấu và người bị thách thức xác định hướng dẫn máy sẽ bị thách thức, người thách thức gọi oneStepProveExecution() để gửi lệnh A step- bằng chứng gian lận từng bước chứng minh rằng có điều gì đó không đúng với kết quả thực hiện lệnh máy này.

Bằng chứng một bước< / h3>

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 trước tiên đòi hỏi phải hiểu WAVM, 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 ở nhiều chỗ nên lõi Geth ban đầu phải được sửa đổi nhẹ và hoạt động cùng với ArbOS.

Vì vậy, quá trình chuyển đổi trạng thái trên L2 thực sự là công việc chung của ArbOS+Geth Core.

Trọng tài Máy khách nút (trình tự sắp xếp, 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 (dành cho 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ộ hướng dẫn nhất định và WASM rất dễ thực hiện mô phỏng trên hợp đồng.

Nhưng so với mã máy Native thì WASM chạy nhanh hơn một chút chậm hơn, 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 đó, chứng minh 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ư bạn có thể thấy từ đ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ề danh mục nào, sau đó gọi bộ chứng minh tương ứng như vậy như Mem, Math, v.v. Chuyển hướng dẫn từng bước vào hợp đồng của người chứng minh.

Kết quả cuối cùng sauHash sẽ được trả về ChallengeManager. Nếu hàm băm Nếu hàm băm sau thao tác lệnh không nhất quán với hàm băm đượ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 ta sẽ phân tích Arbitrum và thậm chí cả hợp đồng Layer2 và Layer1 A mô-đun xử lý các chức năng nhắn tin/cầu nối chuỗi chéo và làm rõ hơn cách Lớp 2 thực sự sẽ đạt được khả năng chống kiểm duyệt.