Tiêu đề gốc: "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ả gốc: Luo Benben, cựu đại sứ kỹ thuật Arbitrum, cộng tác viên đam mê Web3

Bài viết này được viết bởi cựu đại sứ kỹ thuật và thông minh của Arbitrum Luo Benben, 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, giải thích về công nghệ 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, điều này Bài viết cố gắng phổ biến cơ chế hoạt động của Arbitrum thông qua khoa học, để lấp chỗ trống trong lĩnh vực này. 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 nhất có thể nên được chia thành hai phần. Nên 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 ở 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.

Máy phân loại trông giống như một máy chủ tập trung, từ bỏ "phân quyền" để đổi lấy TPS trong "Ba góc bất khả thi của Blockchain" 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 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ù bộ sắp xếp là một hệ thống tập trung với vai trò là trung tâm của hệ thống, trong giải pháp Rollup tương đối hoàn thiện, bộ sắp xếp tập trung chỉ có thể được triển khai Ác mềm các hành vi như xem xét giao dịch hoặc thời gian ngừng hoạt động độc hạiNhưng trong một 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 nó (chẳng hạn như các cơ chế chống kiểm duyệt như buộc rút tiền hoặc sắp xếp bằng chứng).

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

Phương thức xác minh trạng thái để ngăn chặn trình sắp xếp Rollup làm điều ác được chia thành Có hai loại: Bằng chứng gian lận và Bằng chứng hiệu lực. Sơ đồ 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ố lý do lịch sử, sơ đồ Tổng hợp sử dụng bằng chứng hợp lệ thường được gọi là ZK Rollup (Tổng hợp bằng chứng không có kiến thức, ZKR) thay vì Tổng hợp hiệu lực. .

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, lạc quan tin rằng 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 xác minh một cách tích cực nhưng chi phí thấp 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ã.  

(Bản tổng hợp lạc quan Phương thức hoạt động)

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

Bài viết này sẽ giới thiệu chuyên 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 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ồm SequencerInbox, DelayedInbox, L1 Gateway, L2 Gateway, 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à Biên nhận là đượ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 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 lô (Batch) và gửi đến Lớp 1 Hộp thư đến hợp đồng SequencerInboxđể đả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 tôi 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 thường được sử dụng bởi các chuỗi công khai nên tính bảo mật rất kém và 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ả 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 thức tiếp tục của chuỗi, phát hành RBlock, cũng như 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 như mọi người vẫn 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 RBlock thực thể dữ liệu của nó được lưu trữ trong RollupCore In. loạt hợp đồng. 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:

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

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

Người xác thực đang hoạt động 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 là Staker. Mặc dù các nút Layer2 không cam kết cũng có thể giám sát động lực chạy 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 các hướng dẫn opcode có vấn đề được phân tách và xác minh. Mô hình "bằng chứng gian lận 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 mỗi RBlock được gửi vào chuỗi , hợp đồng Không có hoạt động kiểm tra nào, để lại một khoảng thời gian cho người xác minh xác minh hành vi giả mạo. 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 giai đoạn thử thách kết thúc, RBlock cuối cùng sẽ được xác nhậnvà 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 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 cho Ethereum và Arbitrum đã sửa đổi nhẹ 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 sơ đồ để 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

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, bộ phân loại 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ệ và thực hiện phân loại 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 việc này chỉ được thực hiện bởi trình sắp xếp chuỗi trong chuỗi ETH " Quá trình tiền xử lý", ở trạng thái Cuối cùng mềm, 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. Bộ 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 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 tuần tự 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 trình tự

p> h2>

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 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 trình tuần tự 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 nó đến. dữ liệu được gửi của 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 lắng nghe 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 và sự kiện đó sẽ được đưa ra. Trình xác thực sẽ lắng nghe Sau khi sự kiện này xảy ra, dữ liệu lô sẽ được tải xuống. 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 bridge của Arbitrum có một tham số gọi là bộ tích lũy , sẽ ghi lại. lô L2 mới gửi cũng như số lượng và thông tin giao dịch mới nhận trên Hộp thư đến chậm.

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

(Thông tin cụ thể về batch, trường dữ liệu tương ứng với dữ liệu Batch, phần dữ liệu này có kích thước lớn, ả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 Batch 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á gas

Rõ ràng, giao dịch L2 không thể miễn phí, vì điều này sẽ thu hút các cuộc tấn công DoS , ngoài chi phí vận hành của chính bộ phân loại 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 Layer2,cấu trúc phí gas như sau: 

Dữ liệu được tạo bằng cách chiếm tài nguyên Lớp 1 Chi phí xuất bảnchủ 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 gánh chịu do chiếm dụng tài nguyên của Lớp 2 đặt ra tốc độ xử lý khí mỗi giây có thể đảm bảo hệ thống hoạt động ổn định Giới hạn trên (hiện tại là 7 triệu cho Arbitrum One). Giá hướng dẫn khí của L1 và L2 đều đượ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 biết những chi tiết này Rõ ràng là 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à một trình sắp xếp chuỗi dự đoán lô đầu vào giao dịch được gửi trong hộp nhanh, đó là:

Đầu vào giao dịch -> ; Đầ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à xuất bản 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). 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à cũng có 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ỹ xem có cần thiết phải công bố trạng thái của Layer2 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à đặ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 trình sắp xếp 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 là để mở khóa số tiền tương ứng từ hợp đồng của L1 và chuyển chúng cho người dùng theo thông báo chuỗi chéo do L2 đưa ra. Tài khoản L1 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: Trạng thái của bạn trên Layer2 là gì và làm cách nào để chứng minh rằng bạn thực sự sở hữu nó? Kê khai tài sản được kê biên. 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 ta 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ư gian lận bằng chứng (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 nộp cho 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 và nếu xảy ra trạng thái sai, 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 cần được thực hiện lại trên L1, khác với việc thực hiện trực tiếp nó trên L1. L1 cũng không khác, đ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 ngắn gọn. Nó chỉ cần xác minh một Bằng chứng nhỏ và không cần phải thực hiện bằng chứng đằng sau. nó tương ứng với nhiều giao dịch. Do đó, ZKR không hoạt độ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 "bằng chứng chia nhiều vòng-một bước" ” Quá trình tương tác theo lượt, đ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 xét, thử thách và bắt đầu điểm vào bằng chứng là cách giao thức Rollup hoạt động.

Hợp đồng cốt lõi của giao thức Rollup là RollupProxy.sol, sử dụng proxy kép hiếm có trong khi vẫn đảm bảo cấu trúc dữ liệu nhất quán. 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 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, ghi lại một loạt RBlock (hay còn gọi là xác nhận) được gửi bởi những Người xác thực khác nhau, đó là các hộp trong hình bên dưới: Màu xanh lá cây - Đã xác nhận, màu xanh lam - không được xác nhận, màu vàng - giả mạo.

RChặn phương tiện 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 phải đặ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 thách thức/bằng chứng gian lận, 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 người xác minh B không đồng ý và phản đối nó.

Sau khi B bắt đầu thử thách, hợp đồng ChallengeManager có trách nhiệm xác minh quy trình phân chia của các bước thử thách:

1. lần lượt giữa cả hai bên Trong quá trình này, 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) 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à người 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

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 bạn phải hiểu rõ về WAVM, Máy ảo Wasm Arbitrum, được biên soạn bởi mô-đun ArbOS và máy ảo mô-đun lõi Geth (máy khách Ethereum). Vì L2 rất khác với L1 về nhiều mặt nên lõi Geth ban đầu phải được sửa đổi nhẹ và hoạt độ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.

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

Nếu bạn thay đổi ngôn ngữ đích đã 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 ngôn ngữ đơn lẻ đó. step proof , 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 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 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 tích tương tác trước đó, bằng chứng từng 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 loại opcode của lệnh cần được chứng minh thuộc về loại nào, sau đó gọi người chứng minh tương ứng, chẳng hạn như Mem, Math, v.v., chuyển hướng dẫn từng bước vào hợp đồng người chứng minh.

Kết quả cuối cùng sau Hash sẽ quay lại 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 kết nối/nhắn tin xuyên chuỗi giữa Layer2 và Layer1, đồng thời làm rõ hơn cách Layer2 thực sự sẽ đạt được khả năng chống kiểm duyệt.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia