Cựu Đại sứ công nghệ Arbitrum giải thích cấu trúc các thành phần của Arbitrum (Phần 1)
Tuyển chọn TechFlowTuyển chọn TechFlow
Cựu Đại sứ công nghệ Arbitrum giải thích cấu trúc các thành phần của Arbitrum (Phần 1)
Một bài viết giới thiệu về cơ chế hoạt động của Arbitrum.
Chuyên sâu báo cáo Web3Tác giả: La Benben, cựu Đại sứ Kỹ thuật Arbitrum, người đóng góp web3 đam mê công nghệ
Bài viết này là phân tích kỹ thuật về Arbitrum One do La Benben – cựu Đại sứ Kỹ thuật Arbitrum và cựu Đồng sáng lập công ty kiểm toán hợp đồng thông minh Goplus Security – thực hiện.
Do các bài viết hoặc tài liệu bằng tiếng Trung liên quan đến Layer2 thiếu những giải thích chuyên sâu về Arbitrum hay thậm chí về OP Rollup, bài viết này cố gắng lấp đầy khoảng trống đó bằng cách phổ biến cơ chế vận hành của Arbitrum. Vì cấu trúc của Arbitrum quá phức tạp, dù đã được đơn giản hóa tối đa, toàn văn vẫn vượt quá 10.000 ký tự, nên được chia thành hai phần trên và dưới; đề nghị lưu lại như tài liệu tham khảo và chia sẻ!
Tổng quan về Sequencer của Rollup
Nguyên lý mở rộng quy mô của Rollup có thể được tóm tắt trong hai điểm:
Tối ưu chi phí: Giao phần lớn công việc tính toán và lưu trữ ra khỏi chuỗi L1, tức là lên L2. L2 chủ yếu là một chuỗi chạy trên một máy chủ đơn lẻ, còn gọi là Sequencer (hoặc Operator).
Về mặt cảm nhận, Sequencer gần giống một máy chủ tập trung, hy sinh "tính phi tập trung" trong "tam giác bất khả thi blockchain" để đổi lấy lợi thế về TPS và chi phí. Người dùng có thể để L2 xử lý giao dịch thay cho Ethereum, với chi phí thấp hơn nhiều so với giao dịch trực tiếp trên Ethereum.
Bảo mật: Nội dung giao dịch và trạng thái sau giao dịch trên L2 sẽ được đồng bộ lên Ethereum L1, và hiệu lực chuyển đổi trạng thái sẽ được xác minh qua hợp đồng. Đồng thời, lịch sử giao dịch L2 sẽ được lưu trữ trên Ethereum; ngay cả khi Sequencer ngừng hoạt động vĩnh viễn, bất kỳ ai cũng có thể khôi phục toàn bộ trạng thái L2 từ dữ liệu trên Ethereum.
Về bản chất, độ an toàn của Rollup dựa vào Ethereum. Nếu Sequencer không biết khóa riêng của một tài khoản, nó không thể gửi giao dịch nhân danh tài khoản đó hoặc làm sai lệch số dư tài sản (ngay cả khi làm vậy thì cũng nhanh chóng bị phát hiện).
Mặc dù Sequencer mang màu sắc tập trung như trung tâm hệ thống, trong các giải pháp Rollup trưởng thành, Sequencer tập trung chỉ có thể thực hiện các hành vi ác ý dạng nhẹ như kiểm duyệt giao dịch hoặc cố tình ngừng hoạt động, nhưng trong các giải pháp Rollup lý tưởng, sẽ có các biện pháp tương ứng để kiềm chế (ví dụ như cơ chế chống kiểm duyệt như rút tiền bắt buộc hoặc chứng minh sắp xếp).
(Hàm rút tiền bắt buộc do giao thức Loopring đặt trong mã nguồn hợp đồng trên L1, dành cho người dùng gọi)
Cách thức xác minh trạng thái nhằm ngăn chặn hành vi xấu của Sequencer Rollup được chia thành hai loại: Chứng minh gian lận (Fraud Proof) và Chứng minh hiệu lực (Validity Proof). Các giải pháp Rollup dùng Chứng minh gian lận được gọi là OP Rollup (Optimistic Rollup, OPR), trong khi do một số gánh nặng lịch sử, các Rollup dùng Chứng minh hiệu lực thường được gọi là ZK Rollup (Zero-knowledge Proof Rollup, ZKR), chứ không phải Validity Rollup.
Arbitrum One là một OPR điển hình. Hợp đồng triển khai trên L1 của nó không chủ động xác minh dữ liệu được gửi đến, mà tin tưởng rằng dữ liệu này không có vấn đề. Nếu dữ liệu gửi đến có lỗi, các nút xác minh (validator) trên L2 sẽ chủ động khởi xướng thách thức.
Do đó, OPR ngầm chứa một giả định tin cậy: tại mọi thời điểm, luôn tồn tại ít nhất một nút xác minh L2 trung thực. Trong khi đó, hợp đồng ZKR chủ động xác minh dữ liệu do Sequencer gửi đến một cách hiệu quả và chi phí thấp thông qua tính toán mật mã học.
(Cơ chế vận hành của Optimistic Rollup)
(Cơ chế vận hành của ZK Rollup)
Bài viết này sẽ đi sâu vào dự án hàng đầu trong dòng Optimistic Rollup — Arbitrum One, bao quát mọi khía cạnh của hệ thống, giúp bạn hiểu rõ sâu sắc về Arbitrum và Optimistic Rollup/OPR sau khi đọc kỹ.
Các thành phần cốt lõi và quy trình hoạt động của Arbitrum
Hợp đồng cốt lõi:
Các hợp đồng quan trọng nhất của Arbitrum gồm có SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, v.v. Sẽ được giới thiệu chi tiết sau.
Sequencer:
Nhận giao dịch từ người dùng, sắp xếp thứ tự, tính toán kết quả và nhanh chóng (thường <1 giây) trả biên lai cho người dùng. Người dùng thường thấy giao dịch của mình được ghi trên L2 trong vài giây, trải nghiệm giống như nền tảng Web2.
Đồng thời, Sequencer cũng phát sóng tức thì khối L2 mới tạo ra ra khỏi chuỗi Ethereum, bất kỳ nút Layer2 nào cũng có thể nhận bất đồng bộ. Tuy nhiên lúc này, các khối L2 này chưa có tính xác định cuối cùng, và có thể bị Sequencer hoàn tác.
Cứ vài phút một lần, Sequencer sẽ nén dữ liệu giao dịch L2 đã sắp xếp, tập hợp thành lô (Batch), và gửi lên hợp đồng hộp thư (SequencerInbox) trên Layer1, nhằm đảm bảo tính sẵn sàng dữ liệu và vận hành giao thức Rollup. Nói chung, dữ liệu L2 đã gửi lên Layer1 không thể hoàn tác, và đạt được tính xác định cuối cùng.
Từ quy trình trên, ta có thể khái quát: Layer2 có mạng lưới nút riêng, nhưng số lượng nút rất ít, thường không có giao thức đồng thuận như các chuỗi công cộng, nên độ an toàn rất kém, phải phụ thuộc vào Ethereum để đảm bảo độ tin cậy của việc công bố dữ liệu và tính hiệu lực 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, cách nối dài chuỗi, việc công bố RBlock, quy trình thách thức, v.v., tất cả đều nằm trong một loạt hợp đồng. Lưu ý, chuỗi Rollup ở đây không phải là sổ cái Layer2 theo nghĩa thông thường, mà là một cấu trúc dữ liệu dạng chuỗi trừu tượng do Arbitrum One thiết lập riêng để thực hiện cơ chế chứng minh gian lận.
Một RBlock có thể chứa kết quả của nhiều khối L2, và dữ liệu khác biệt rõ rệt. Thực thể dữ liệu RBlock được lưu trữ trong một loạt hợp đồng RollupCore. Nếu một RBlock có vấn đề, Validator sẽ thách thức người gửi RBlock đó.
Validator (Nút xác minh):
Các nút validator của Arbitrum thực chất là tập con đặc biệt của các nút toàn phần (full node) Layer2, hiện tại có cơ chế danh sách trắng (whitelist).
Validator dựa vào batch giao dịch mà Sequencer gửi đến hợp đồng SequencerInbox để tạo RBlock mới (khối Rollup, còn gọi là assertion), đồng thời giám sát trạng thái hiện tại của chuỗi Rollup, thách thức dữ liệu sai do Sequencer gửi lên.
Validator chủ động cần đặt cọc tài sản trên chuỗi ETH trước, đôi khi chúng ta gọi họ là Staker. Các nút Layer2 không đặt cọc có thể giám sát hoạt động của Rollup, gửi cảnh báo cho người dùng, nhưng không thể can thiệp trực tiếp trên chuỗi ETH đối với dữ liệu sai do Sequencer gửi lên.
Thách thức:
Các bước cơ bản có thể được tóm tắt là phân đoạn tương tác nhiều vòng và chứng minh từng bước. Trong giai đoạn phân đoạn, hai bên tranh chấp thực hiện phân đoạn theo nhiều vòng, cho đến khi tách ra lệnh opcode gây tranh cãi, rồi tiến hành xác minh. Mô hình "phân đoạn nhiều vòng - chứng minh từng bước" này được các nhà phát triển Arbitrum coi là cách triển khai chứng minh gian lận tiết kiệm gas nhất. Mọi bước đều được kiểm soát bởi hợp đồng, không bên nào có thể gian lận.
Thời gian thách thức:
Do bản chất "lạc quan" (optimistic) của OP Rollup, mỗi khi một RBlock được gửi lên chuỗi, hợp đồng không chủ động kiểm tra, mà để mở một cửa sổ thời gian cho validator chứng minh tính sai. Cửa sổ thời gian này gọi là thời gian thách thức, hiện tại trên mainnet Arbitrum One là 1 tuần. Sau khi hết thời gian thách thức, RBlock mới được xác nhận cuối cùng, và các tin nhắn từ L2 chuyển sang L1 trong khối đó (ví dụ như rút tiền qua cầu chính thức) mới được phép thực hiện.
ArbOS, Geth, WAVM:
Máy ảo mà Arbitrum sử dụng tên là AVM, gồm hai phần: Geth và ArbOS. Geth là phần mềm khách Ethereum phổ biến nhất, Arbitrum đã sửa đổi nhẹ nó. ArbOS chịu trách nhiệm cho mọi chức năng đặc biệt liên quan đến L2, như quản lý tài nguyên mạng, tạo khối L2, phối hợp với EVM, v.v. Chúng ta coi tổ hợp này như một AVM gốc (native AVM), chính là máy ảo mà Arbitrum sử dụng. WAVM là kết quả khi biên dịch mã AVM sang Wasm. Trong quy trình thách thức Arbitrum, bước "chứng minh từng bước" cuối cùng xác minh chính là lệnh WAVM.
Ở đây, chúng ta có thể biểu diễn mối quan hệ giữa các thành phần trên và quy trình làm việc bằng sơ đồ sau:
Vòng đời giao dịch L2
Quy trình xử lý một giao dịch L2 như sau:
1. Người dùng gửi lệnh giao dịch đến Sequencer.
2. Sequencer trước tiên xác minh dữ liệu như chữ ký số của giao dịch đang chờ xử lý, loại bỏ giao dịch vô hiệu, rồi sắp xếp và tính toán.
3. Sequencer gửi biên lai giao dịch cho người dùng (thường rất nhanh), nhưng đây chỉ là "xử lý sơ bộ" của Sequencer ngoài chuỗi ETH, ở trạng thái Soft Finality, không đáng tin cậy. Tuy nhiên, đối với người dùng tin tưởng Sequencer (đa số người dùng), có thể lạc quan cho rằng giao dịch đã hoàn tất và sẽ không bị hoàn tác.
4. Sequencer nén dữ liệu giao dịch gốc đã xử lý sơ bộ, gói gọn thành một Batch (lô).
5. Cứ sau một khoảng thời gian nhất định (phụ thuộc vào lượng dữ liệu, mức độ tắc nghẽn ETH, v.v.), Sequencer sẽ công bố Batch giao dịch lên hợp đồng Sequencer Inbox trên L1. Lúc này có thể coi giao dịch đã đạt được tính xác định cuối cùng Hard Finality.
Hợp đồng Sequencer Inbox
Hợp đồng sẽ nhận batch giao dịch do Sequencer gửi lên, đảm bảo tính sẵn sàng dữ liệu. Xét sâu hơn, dữ liệu batch trong SequencerInbox ghi lại đầy đủ thông tin đầu vào giao dịch Layer2, ngay cả khi Sequencer 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 Layer2 từ dữ liệu batch, và thay thế Sequencer gặp sự cố hoặc bỏ trốn.
Hiểu theo cách vật lý, L2 mà chúng ta thấy chỉ là hình chiếu của batch trong SequencerInbox, nguồn sáng là STF. Vì nguồn sáng STF không dễ thay đổi, nên hình dạng bóng đổ chỉ do batch – vật chắn – quyết định.
Hợp đồng Sequencer Inbox còn được gọi là hộp nhanh (fast inbox), Sequencer chuyên gửi các giao dịch đã xử lý sơ bộ lên đây, và chỉ có Sequencer mới được phép gửi dữ liệu lên đây. Đối ứng với hộp nhanh là hộp chậm (Delayed Inbox), chức năng sẽ được mô tả trong quy trình sau.
Validator luôn theo dõi hợp đồng SequencerInbox. Mỗi khi Sequencer công bố Batch lên hợp đồng này, một sự kiện trên chuỗi sẽ được kích hoạt; Validator khi phát hiện sự kiện này sẽ tải dữ liệu batch về, thực thi cục bộ, rồi gửi RBlock lên hợp đồng giao thức Rollup trên chuỗi ETH.
Hợp đồng cầu (bridge) của Arbitrum có một tham số gọi là bộ tích lũy (accumulator), ghi nhận dữ liệu batch L2 mới gửi lên, cũng như số lượng và thông tin giao dịch mới nhận được trên hộp chậm (slow inbox).
(Sequencer liên tục gửi batch lên SequencerInbox)
(Thông tin cụ thể của Batch, trường data tương ứng với dữ liệu Batch, kích thước dữ liệu khá lớn nên ảnh chụp màn hình không hiển thị hết)
Hợp đồng SequencerInbox có hai hàm chính:
addSequencerL2BatchFromOrigin(), Sequencer gọi hàm này mỗi lần gửi dữ liệu Batch lên hợp đồng SequencerInbox.
forceInclusion(), Hàm này bất kỳ ai cũng có thể gọi, nhằm thực hiện giao dịch chống kiểm duyệt. Cơ chế hoạt động của hàm này sẽ được giải thích chi tiết khi nói đến hợp đồng Delayed Inbox.
Cả hai hàm trên đều gọi bridge.enqueueSequencerMessage() để cập nhật tham số accumulator trong hợp đồng cầu.
Định giá Gas
Rõ ràng, giao dịch L2 không thể miễn phí, vì điều đó sẽ dẫn đến tấn công DoS, thêm nữa là chi phí vận hành Sequencer/L2 và chi phí gửi dữ liệu lên L1. Khi người dùng khởi tạo giao dịch trong mạng Layer2, cấu trúc phí gas như sau:
Chi phí công bố dữ liệu phát sinh do chiếm dụng tài nguyên Layer1, chủ yếu đến từ batch do Sequencer gửi lên (mỗi batch chứa nhiều giao dịch của người dùng), chi phí cuối cùng do những người khởi tạo giao dịch chia sẻ. Giá phí công bố dữ liệu được định giá động, Sequencer sẽ định giá dựa trên tình hình lãi/lỗ gần đây, kích thước batch, và giá gas hiện tại của Ethereum.
Chi phí do chiếm dụng tài nguyên Layer2, thiết lập một giới hạn gas xử lý mỗi giây để đảm bảo hệ thống vận hành ổn định (hiện tại Arbitrum One là 7 triệu). Giá hướng dẫn gas L1 và L2 đều do ArbOS theo dõi và điều chỉnh, công thức tạm thời không trình bày ở đây.
Mặc dù quá trình tính toán giá gas cụ thể khá phức tạp, người dùng không cần cảm nhận các chi tiết này, và có thể thấy rõ phí giao dịch Rollup rẻ hơn nhiều so với mạng chính ETH.
Chứng minh gian lận kiểu lạc quan
Nhìn lại phần trước, L2 thực tế chỉ là hình chiếu của dữ liệu đầu vào giao dịch (batch) mà Sequencer gửi vào hộp nhanh, tức là:
Transaction Inputs -> STF -> State Outputs. Đầu vào đã xác định, STF không đổi, thì đầu ra cũng xác định. Chứng minh gian lận và hệ thống giao thức Arbitrum Rollup chính là hệ thống công bố root trạng thái đầu ra dưới dạng RBlock (hay còn gọi là assertion) lên L1 và thực hiện chứng minh kiểu lạc quan.
Trên L1 có dữ liệu đầu vào do Sequencer công bố, và trạng thái đầu ra do Validator công bố. Chúng ta hãy cân nhắc kỹ hơn: có thực sự cần thiết phải công bố trạng thái L2 lên chuỗi không?
Vì đầu vào đã hoàn toàn quyết định đầu ra, và dữ liệu đầu vào công khai, việc gửi thêm kết quả đầu ra - trạng thái dường như thừa? Nhưng suy nghĩ này đã bỏ qua rằng thực tế giữa hai hệ thống L1-L2 cần có việc thanh toán trạng thái, tức là hành vi rút tiền từ L2 sang L1, cần có bằng chứng về trạng thái.
Khi xây dựng Rollup, tư tưởng cốt lõi nhất là đưa phần lớn tính toán và lưu trữ lên L2 để tránh chi phí cao của L1, điều này cũng có nghĩa là L1 không biết trạng thái L2, nó chỉ giúp Sequencer L2 công bố dữ liệu đầu vào 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ề bản chất là căn cứ vào tin nhắn xuyên chuỗi do L2 cung cấp, giải phóng lượng vốn tương ứng từ hợp đồng trên L1, chuyển vào tài khoản L1 của người dùng hoặc hoàn thành việc khác.
Lúc này hợp đồng trên Layer1 sẽ hỏi: trạng thái của bạn trên Layer2 là gì, làm sao chứng minh bạn thực sự sở hữu lượng tài sản tuyên bố muốn chuyển đi. Lúc này người dùng phải cung cấp Merkle Proof tương ứng, v.v.
Vì vậy, nếu chúng ta xây dựng một Rollup không có chức năng rút tiền, về lý thuyết không cần đồng bộ trạng thái lên L1, và cũng không cần hệ thống chứng minh trạng thái như chứng minh gian lận (dù có thể gây ra vấn đề khác). Nhưng trong ứng dụng thực tế, điều này rõ ràng là không khả thi.
Trong chứng minh kiểu lạc quan, hợp đồng không kiểm tra xem trạng thái đầu ra gửi lên L1 có đúng hay không, mà lạc quan cho rằng mọi thứ đều chính xác. Hệ thống chứng minh lạc quan giả định rằng tại mọi thời điểm luôn có ít nhất một Validator trung thực; nếu trạng thái sai xảy ra, sẽ có thách thức thông qua chứng minh gian lận.
Thiết kế này có lợi là không cần xác minh chủ động từng RBlock gửi lên L1, tránh lãng phí gas. Thực tế, với OPR, việc xác minh từng assertion là không thực tế, vì mỗi Rblock chứa một hoặc nhiều khối L2, việc thực thi lại từng giao dịch trên L1 sẽ tương đương với việc thực thi giao dịch L2 trực tiếp trên L1, mất đi ý nghĩa mở rộng của Layer2.
ZKR không gặp vấn đề này, vì ZK Proof có tính ngắn gọn, chỉ cần xác minh một Proof rất nhỏ, không cần thực sự thực thi hàng loạt giao dịch đằng sau Proof đó. Vì vậy ZKR không vận hành kiểu lạc quan, mỗi lần công bố trạng thái đều có hợp đồng Verifier xác minh bằng toán học.
Dù chứng minh gian lận không có tính ngắn gọn cao như chứng minh kiến thức không tiết lộ, Arbitrum sử dụng một quy trình tương tác luân phiên "phân đoạn nhiều vòng - chứng minh từng bước", cuối cùng chỉ cần chứng minh một lệnh opcode duy nhất của máy ảo, chi phí tương đối thấp.
Giao thức Rollup
Chúng ta hãy 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à giao thức Rollup hoạt động như thế nào.
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, sử dụng một cấu trúc proxy kép hiếm gặp, một proxy ứng với hai bản triển khai RollupUserLogic.sol và RollupAdminLogic.sol, hiện tại các công cụ như Scan vẫn chưa thể 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ý thách thức, và chuỗi hợp đồng OneStepProver để xác định chứng minh gian lận.
Trong RollupProxy, ghi lại một chuỗi RBlock (còn gọi là assertion) do các Validator khác nhau gửi lên, tức là các ô vuông trong hình dưới: màu xanh lá - đã xác nhận, màu xanh dương - chưa xác nhận, màu vàng - đã bị chứng minh sai.
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 đó. Những RBlock này về hình thức tạo thành một chuỗi Rollup (lưu ý là khác với sổ cái L2). Trong trường hợp lý tưởng, chuỗi Rollup này không nên có phân nhánh, vì phân nhánh có nghĩa là có Validator gửi các khối Rollup mâu thuẫn nhau.
Để đề xuất hoặc đồng thuận một assertion, validator cần đặt cọc một lượng ETH nhất định cho assertion đó, trở thành Staker. Như vậy, khi xảy ra thách thức/chứng minh gian lận, tài sản đặt cọc của bên thua sẽ bị tịch thu, đây là cơ sở kinh tế đảm bảo hành vi trung thực của validator.
Ô màu xanh dương số 111 ở góc dưới bên phải trong hình cuối cùng sẽ bị chứng minh sai, vì khối cha số 104 của nó là sai (màu vàng).
Ngoài ra, validator A đề xuất khối Rollup số 106, nhưng 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 quá trình phân đoạn từng bước:
1. Phân đoạn là quá trình tương tác luân phiên giữa hai bên, một bên chia đoạn dữ liệu lịch sử trong một Rollup Block, bên kia chỉ ra phần dữ liệu nào có vấn đề. Tương tự như tìm kiếm nhị phân (thực tế là N/K), dần thu hẹp phạm vi.
2. Sau đó, có thể tiếp tục xác định giao dịch và kết quả nào có vấn đề, rồi phân đoạn sâu hơn tới lệnh máy gây tranh cãi trong giao dịch đó.
3. Hợp đồng ChallengeManager chỉ kiểm tra xem 'đoạn dữ liệu' được tạo ra 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 bị thách thức đã xác định được lệnh máy bị thách thức, người thách thức gọi oneStepProveExecution(), gửi chứng minh gian lận từng bước, chứng minh kết quả thực thi lệnh máy này có vấn đề.
Chứng minh từng bước
Chứng minh từng bước là cốt lõi của chứng minh gian lận Arbitrum. Hãy xem chứng minh từng bước cụ thể chứng minh nội dung gì.
Điều này cần hiểu trước về WAVM, Wasm Arbitrum Virtual Machine, là một máy ảo được biên dịch từ hai mô-đun: ArbOS và mô-đun lõi Geth (client Ethereum). Do L2 và L1 có nhiều điểm khác biệt, lõi Geth gốc phải được sửa đổi nhẹ và phối hợp với ArbOS để hoạt động.
Vì vậy, việc chuyển đổi trạng thái trên L2 thực chất là kết quả của sự phối hợp giữa ArbOS và Geth Core.
Client nút của Arbitrum (Sequencer, Validator, nút toàn phần, v.v.) biên dịch chương trình xử lý ArbOS+Geth Core thành mã máy gốc (native machine code) mà máy chủ nút có thể xử lý trực tiếp (cho x86/ARM/PC/Mac/v.v.).
Nếu ngôn ngữ đích khi biên dịch được chuyển sang Wasm, ta sẽ có được WAVM – dùng khi validator tạo chứng minh gian lận, và hợp đồng xác minh chứng minh từng bước cũng mô phỏng chức năng của máy ảo WAVM.
Tại sao khi tạo chứng minh gian lận lại phải biên dịch sang bytecode Wasm? Chủ yếu vì hợp đồng xác minh chứng minh gian lận từng bước cần mô phỏng một máy ảo (VM) có thể xử lý một tập lệnh nhất định bằng hợp đồng thông minh Ethereum, và WASM dễ dàng mô phỏng trên hợp đồng.
Tuy nhiên, so với mã máy gốc, WASM chạy chậm hơn một chút, nên chỉ khi tạo và xác minh chứng minh gian lận, các nút/hợp đồng Arbitrum mới dùng đến WAVM.
Sau quá trình phân đoạn tương tác nhiều vòng trước đó, chứng minh từng bước cuối
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
