Báo cáo ABCDE: Phân tích sâu về bộ xử lý đồng hành và các giải pháp từ các nhà cung cấp khác nhau
Tuyển chọn TechFlowTuyển chọn TechFlow
Báo cáo ABCDE: Phân tích sâu về bộ xử lý đồng hành và các giải pháp từ các nhà cung cấp khác nhau
Hệ thống hóa và so sánh các phương án kỹ thuật hiện có trên thị trường trong lĩnh vực bộ xử lý phụ, nhằm mang đến cho thị trường và người dùng cái nhìn rõ ràng hơn về赛道 xử lý phụ
Chuyên sâu báo cáo Web3Tác giả: Kris & Laobai ABCDE / Mo Dong Celer Network
Trong vài tháng gần đây, khái niệm coprocessor (bộ xử lý phụ) ngày càng trở nên sôi động, và trường hợp sử dụng ZK mới mẻ này bắt đầu thu hút sự chú ý của ngày càng nhiều người.
Tuy nhiên, chúng tôi nhận thấy rằng phần lớn mọi người vẫn còn khá xa lạ với khái niệm coprocessor, đặc biệt là việc định vị chính xác coprocessor — cụ thể nó là gì và không phải là gì — vẫn còn mơ hồ. Đồng thời, chưa có ai hệ thống hóa so sánh các phương án kỹ thuật giữa các dự án trong lĩnh vực coprocessor trên thị trường. Bài viết này mong muốn mang đến cho thị trường và người dùng cái nhìn rõ ràng hơn về赛道 xử lý phụ.
Một. Coprocessor là gì, và không phải là gì?
Nếu bạn chỉ được dùng một câu để giải thích rõ ràng khái niệm coprocessor cho một người không có chuyên môn hoặc lập trình viên, bạn sẽ mô tả như thế nào?
Tôi nghĩ câu nói của Tiến sĩ Dong Mo có lẽ rất gần với đáp án chuẩn — đơn giản mà nói, coprocessor chính là «trao cho hợp đồng thông minh khả năng như Dune Analytics».
Chúng ta nên hiểu câu này ra sao?
Hãy tưởng tượng bạn đang dùng Dune — bạn muốn làm LP trên Uniswap V3 để kiếm phí giao dịch, vì vậy bạn mở Dune lên, tìm khối lượng giao dịch gần đây nhất của các cặp giao dịch trên Uniswap, APR phí giao dịch 7 ngày gần nhất, khoảng dao động giá trên-dưới của các cặp giao dịch phổ biến v.v...
Hoặc khi StepN nổi lên, bạn bắt đầu đầu cơ giày, nhưng không chắc nên bán lúc nào, vì vậy mỗi ngày bạn theo dõi sát sao dữ liệu StepN trên Dune: khối lượng giao dịch hàng ngày, số lượng người dùng mới, giá sàn của đôi giày... và lên kế hoạch rút lui ngay khi thấy xu hướng tăng trưởng chậm lại hoặc bắt đầu giảm.
Dĩ nhiên, có thể không chỉ mình bạn đang theo dõi những dữ liệu này, đội phát triển Uniswap và StepN cũng quan tâm đến chúng.
Những dữ liệu này rất có ý nghĩa — chúng không chỉ giúp xác định xu hướng thay đổi, mà còn có thể tạo ra nhiều ứng dụng thú vị hơn nữa, giống như cách các "đại gia internet" thường dùng chiến lược «dữ liệu lớn».
Ví dụ, dựa trên phong cách và mức giá giày mà người dùng thường xuyên mua bán, hệ thống có thể đề xuất những đôi giày tương tự.
Ví dụ, dựa trên thời gian người dùng giữ giày nguyên bản (genesis shoe), triển khai một «chương trình thưởng khách hàng trung thành», tặng thêm airdrop hoặc phúc lợi cho người dùng trung thành.
Ví dụ, dựa trên TVL hoặc khối lượng giao dịch do LP hoặc Trader cung cấp trên Uniswap, thiết lập một chương trình VIP kiểu CEX, giảm phí giao dịch cho Trader hoặc tăng tỷ lệ chia phí cho LP...
Tới đây nảy sinh vấn đề — các công ty internet lớn chơi «dữ liệu lớn + AI», thực chất là một hộp đen, họ muốn làm gì thì làm, người dùng không nhìn thấy, cũng chẳng quan tâm.
Nhưng ở Web3, tính minh bạch và phi tin cậy (trustless) là tiêu chuẩn đạo đức vốn có của chúng ta, ta từ chối hộp đen!
Do đó, khi bạn muốn hiện thực hóa các kịch bản kể trên, bạn sẽ đối mặt với một tình thế tiến thoái lưỡng nan — hoặc bạn thực hiện bằng phương pháp tập trung, «thao tác thủ công ở backend», dùng Dune để thống kê các dữ liệu index rồi triển khai; hoặc bạn viết một hợp đồng thông minh, tự động trích xuất dữ liệu trên chuỗi, hoàn tất tính toán và triển khai phân phối.
Phương án thứ nhất khiến bạn rơi vào vấn đề «mất niềm tin» — vi phạm nguyên tắc chính trị.
Phương án thứ hai sẽ tạo ra chi phí Gas khổng lồ trên chuỗi, ví của bạn (hoặc của bên phát triển dự án) không chịu nổi.
Đây chính là lúc coprocessor xuất hiện — kết hợp cả hai phương pháp trên, đồng thời «tự chứng minh tính minh bạch» cho bước «thao tác thủ công ở backend» bằng kỹ thuật, nói cách khác, dùng công nghệ ZK để «tự chứng minh tính minh bạch» cho phần «index + tính toán ngoài chuỗi», sau đó đưa dữ liệu vào hợp đồng thông minh. Như vậy, vừa giải quyết vấn đề niềm tin, vừa loại bỏ khoản phí Gas khổng lồ, hoàn hảo!
Tại sao lại gọi là «coprocessor»? Thực ra tên gọi này bắt nguồn từ lịch sử phát triển Web2.0 với «GPU». GPU từng được giới thiệu như một phần cứng tính toán riêng biệt, tách biệt khỏi CPU, bởi kiến trúc thiết kế của nó có thể xử lý các tác vụ mà CPU vốn dĩ khó thực hiện, như tính toán song song quy mô lớn, xử lý đồ họa, v.v. Chính nhờ kiến trúc «coprocessor» này, hôm nay chúng ta mới có phim ảnh CG tuyệt đẹp, trò chơi điện tử hấp dẫn, mô hình AI tiên tiến, v.v. Vì vậy, kiến trúc coprocessor thực chất là một bước nhảy vọt trong kiến trúc hệ thống máy tính. Hiện tại, các nhóm phát triển coprocessor cũng mong muốn áp dụng kiến trúc này vào Web3.0, nơi blockchain đóng vai trò như «CPU của Web3.0», dù là L1 hay L2, đều vốn dĩ không phù hợp với các nhiệm vụ «nặng dữ liệu» và «logic tính toán phức tạp». Do đó, việc giới thiệu một coprocessor blockchain để hỗ trợ xử lý các phép tính này sẽ cực kỳ mở rộng khả năng ứng dụng của blockchain.
Tóm lại, coprocessor làm hai việc:
-
Lấy dữ liệu từ blockchain, và dùng ZK chứng minh rằng dữ liệu lấy về là thật, không bị làm giả;
-
Thực hiện các phép tính tương ứng dựa trên dữ liệu đã lấy, sau đó tiếp tục dùng ZK chứng minh rằng kết quả tính toán cũng là thật, không bị làm giả, để kết quả có thể được hợp đồng thông minh gọi lại với «phí thấp + không cần tin tưởng».
Gần đây, Starkware nổi lên một khái niệm gọi là Storage Proof (Chứng minh lưu trữ), còn gọi là State Proof (Chứng minh trạng thái), về cơ bản làm đúng bước thứ nhất nêu trên. Các đại diện tiêu biểu là Herodotus, Langrage, v.v., và nhiều cây cầu nối跨链 dựa trên ZK cũng tập trung trọng điểm vào bước thứ nhất này.
Coprocessor đơn giản là thực hiện xong bước 1 rồi thêm bước 2 — sau khi trích xuất dữ liệu một cách phi tin cậy, tiếp tục thực hiện tính toán phi tin cậy là xong.
Vì vậy, nếu dùng ngôn ngữ kỹ thuật hơn để mô tả chính xác, coprocessor nên được coi là siêu tập hợp (superset) của Storage Proof/State Proof, đồng thời là tập con của Verifiable Computation (Tính toán có thể kiểm chứng).
Một điểm cần lưu ý là coprocessor KHÔNG PHẢI Rollup.
Về mặt kỹ thuật, bằng chứng ZK của Rollup tương tự bước 2 đã nêu, còn bước 1 «lấy dữ liệu» được thực hiện trực tiếp qua Sequencer. Ngay cả với Sequencer phi tập trung, việc lấy dữ liệu cũng chỉ thông qua một dạng cơ chế cạnh tranh hoặc đồng thuận, chứ không dùng dạng bằng chứng ZK như Storage Proof. Quan trọng hơn, ZK Rollup ngoài lớp tính toán còn phải xây dựng một lớp lưu trữ giống như blockchain L1, và lớp lưu trữ này tồn tại vĩnh viễn, trong khi ZK Coprocessor thì «không trạng thái» (stateless), sau khi hoàn thành tính toán, không cần lưu giữ toàn bộ trạng thái.
Xét về ứng dụng, coprocessor có thể được xem như một plugin dịch vụ dành cho mọi Layer1/Layer2, còn Rollup thì tự khởi động một layer thực thi mới nhằm mở rộng khả năng xử lý cho layer thanh toán.
Hai. Vì sao phải dùng ZK, dùng OP có được không?
Sau khi đọc phần trên, bạn có thể thắc mắc: Liệu coprocessor nhất thiết phải dùng ZK? Nghe có vẻ giống như một «Graph được thêm ZK», trong khi dường như chúng ta cũng chẳng nghi ngờ mấy về kết quả từ Graph.
Nói thì nói vậy, nhưng đó là vì bình thường khi dùng Graph, hầu như không liên quan đến tiền thật. Những dữ liệu index này phục vụ các dịch vụ off-chain, tức là những dữ liệu bạn thấy trên giao diện người dùng như khối lượng giao dịch, lịch sử giao dịch… có thể do nhiều nhà cung cấp như Graph, Alchemy, Zettablock cung cấp. Tuy nhiên, những dữ liệu này không thể đưa ngược lại vào hợp đồng thông minh, bởi một khi đưa vào sẽ làm tăng thêm niềm tin vào dịch vụ index đó. Khi dữ liệu liên quan đến tiền thật, đặc biệt là TVL quy mô lớn, thì sự tin tưởng bổ sung này trở nên quan trọng. Hãy tưởng tượng, nếu một người bạn mượn bạn 100 nghìn, bạn có thể chẳng chớp mắt mà đưa luôn; nhưng nếu họ mượn 10 triệu hay 100 triệu thì sao?
Tuy nhiên, liệu tất cả các kịch bản trên coprocessor thực sự đều phải dùng ZK? Trong Rollup chúng ta có hai hướng kỹ thuật là OP và ZK, gần đây ZKML thịnh hành cũng đã có khái niệm OPML tương ứng được đề xuất như một nhánh phát triển, vậy liệu có tồn tại nhánh OP cho coprocessor, ví dụ như OP-Coprocessor?
Thật ra là có — tuy nhiên chi tiết cụ thể ở đây chúng tôi xin giữ bí mật, sớm thôi chúng tôi sẽ công bố thêm thông tin chi tiết.
Ba. Coprocessor哪家强 — So sánh các phương án kỹ thuật coprocessor phổ biến trên thị trường
Brevis
Kiến trúc Brevis gồm ba thành phần: zkFabric, zkQueryNet và zkAggregatorRollup.
Dưới đây là sơ đồ kiến trúc Brevis:
zkFabric: Thu thập tiêu đề khối (block headers) từ tất cả các blockchain được kết nối, và tạo ra bằng chứng ZK về tính hợp lệ của các tiêu đề khối này. Thông qua zkFabric, Brevis đạt được coprocessor đa chuỗi tương tác, cho phép một blockchain truy cập dữ liệu lịch sử bất kỳ từ blockchain khác.
zkQueryNet: Một thị trường động cơ truy vấn ZK mở, có thể chấp nhận truy vấn dữ liệu từ dApp và xử lý chúng. Các truy vấn dữ liệu sử dụng tiêu đề khối đã được xác thực từ zkFabric để xử lý, đồng thời tạo ra bằng chứng truy vấn ZK. Các động cơ này có chức năng chuyên biệt cao, cũng có ngôn ngữ truy vấn tổng quát, đáp ứng nhu cầu ứng dụng đa dạng.
zkAggregatorRollup: Một blockchain cuộn ZK, đóng vai trò là tầng tổng hợp và lưu trữ cho zkFabric và zkQueryNet. Nó xác minh các bằng chứng từ hai thành phần này, lưu trữ dữ liệu đã được xác thực, và gửi root trạng thái đã được xác minh bằng zk tới tất cả các blockchain được kết nối.
ZK Fabric là phần then chốt tạo proof cho tiêu đề khối, đảm bảo an toàn cho phần này là vô cùng quan trọng. Dưới đây là sơ đồ kiến trúc zkFabric:
zkFabric dựa trên client nhẹ sử dụng bằng chứng tri thức không (ZKP), hoàn toàn loại bỏ sự tin tưởng, không cần dựa vào bất kỳ thực thể xác minh bên ngoài nào. An toàn của nó hoàn toàn đến từ blockchain nền tảng và bằng chứng đáng tin cậy về mặt toán học.
Mạng Prover zkFabric triển khai mạch cho giao thức client nhẹ của mỗi blockchain, mạng này tạo bằng chứng hợp lệ cho tiêu đề khối. Người chứng minh có thể tận dụng các bộ tăng tốc như GPU, FPGA và ASIC để giảm thiểu thời gian và chi phí tạo bằng chứng.
zkFabric phụ thuộc vào các giả định an toàn của blockchain và giao thức mã hóa nền tảng. Tuy nhiên, để đảm bảo hiệu lực của zkFabric, cần ít nhất một relay trung thực đồng bộ đúng fork. Vì vậy, zkFabric sử dụng mạng relay phi tập trung thay vì một relay đơn lẻ để tối ưu hiệu lực. Mạng relay này có thể tận dụng các cấu trúc hiện có, như mạng giám sát trạng thái trong Celer Network.
Hiện trạng triển khai:
Hiện đã triển khai giao thức client nhẹ cho nhiều blockchain (bao gồm Ethereum PoS, Cosmos Tendermint và BNB Chain) như ví dụ và chứng minh khái niệm.
Brevis hiện đã hợp tác với uniswap hook, hook đã thêm mạnh mẽ các pool uniswap tùy chỉnh, nhưng so với CEX, Uniswap vẫn thiếu chức năng xử lý dữ liệu hiệu quả để tạo ra các tính năng dựa trên dữ liệu giao dịch người dùng lớn (ví dụ như chương trình trung thành dựa trên khối lượng giao dịch).
Với sự trợ giúp của Brevis, hook đã giải quyết được thách thức này. Hook giờ đây có thể đọc từ dữ liệu lịch sử chuỗi đầy đủ của người dùng hoặc LP, và chạy các tính toán tùy chỉnh một cách hoàn toàn phi tin cậy.
Herodotus
Herodotus là một middleware truy cập dữ liệu mạnh mẽ, cung cấp cho hợp đồng thông minh khả năng truy cập đồng bộ dữ liệu hiện tại và lịch sử trên chuỗi Ethereum qua các lớp:
-
L1 states from L2s
-
L2 states from both L1s and other L2s
-
L3/App-Chain states to L2s and L1s
Herodotus đề xuất khái niệm Chứng minh Lưu trữ (Storage Proof), kết hợp bằng chứng bao gồm (xác nhận sự tồn tại của dữ liệu) và bằng chứng tính toán (xác minh việc thực hiện luồng công việc nhiều bước), nhằm chứng minh tính hợp lệ của một hoặc nhiều phần tử trong tập dữ liệu lớn (như toàn bộ blockchain Ethereum hoặc rollup).
Cốt lõi của blockchain là cơ sở dữ liệu, trong đó dữ liệu được bảo vệ bằng mật mã thông qua các cấu trúc dữ liệu như Merkle tree, Merkle Patricia tree. Điểm đặc biệt của các cấu trúc này là một khi dữ liệu được cam kết an toàn vào chúng, có thể tạo ra bằng chứng xác nhận dữ liệu nằm trong cấu trúc.
Việc sử dụng Merkle tree và Merkle Patricia tree nâng cao độ an toàn của blockchain Ethereum. Bằng cách băm dữ liệu ở mỗi cấp của cây, gần như không thể thay đổi dữ liệu mà không bị phát hiện. Mọi thay đổi tại điểm dữ liệu đều yêu cầu thay đổi giá trị băm tương ứng trên cây đến root hash, điều này dễ thấy công khai trong tiêu đề blockchain. Đặc điểm cơ bản này của blockchain đảm bảo mức độ cao về tính toàn vẹn và bất biến của dữ liệu.
Thứ hai, các cây này cho phép xác minh dữ liệu hiệu quả thông qua bằng chứng bao gồm. Ví dụ, khi xác minh sự tồn tại của giao dịch hoặc trạng thái hợp đồng, không cần tìm kiếm toàn bộ blockchain Ethereum, chỉ cần xác minh đường đi trong Merkle tree liên quan.
Storage Proof do Herodotus định nghĩa là sự kết hợp của:
-
Bằng chứng bao gồm: Xác nhận sự tồn tại của dữ liệu cụ thể trong cấu trúc dữ liệu mã hóa (ví dụ như Merkle tree hoặc Merkle Patricia tree), đảm bảo dữ liệu liên quan thực sự tồn tại trong tập dữ liệu.
-
Bằng chứng tính toán: Xác minh việc thực hiện luồng công việc nhiều bước, chứng minh tính hợp lệ của một hoặc nhiều phần tử trong tập dữ liệu rộng lớn, ví dụ như toàn bộ blockchain Ethereum hoặc rollup. Ngoài việc chỉ ra sự tồn tại của dữ liệu, chúng còn xác minh các chuyển đổi hoặc thao tác được áp dụng lên dữ liệu đó.
-
Bằng chứng tri thức không (zero-knowledge proof): Giảm lượng dữ liệu mà hợp đồng thông minh cần tương tác. Bằng chứng ZK cho phép hợp đồng thông minh xác nhận tính hợp lệ của yêu cầu mà không cần xử lý toàn bộ dữ liệu nền tảng.
Quy trình hoạt động:
1. Lấy block hash
Mọi dữ liệu trên blockchain đều thuộc về một block cụ thể. Block hash là định danh duy nhất của block đó, tóm tắt toàn bộ nội dung qua block header. Trong quy trình Storage Proof, bước đầu tiên là xác định và xác minh block hash của block chứa dữ liệu quan tâm, đây là bước thiết yếu.
2. Lấy block header
Sau khi có block hash liên quan, bước tiếp theo là truy cập block header. Để làm điều này, cần băm block header liên kết với block hash đã lấy ở bước trước. Sau đó so sánh giá trị băm block header cung cấp với block hash đã có:
Có hai cách lấy hash:
(1) Sử dụng opcode BLOCKHASH để truy xuất
(2) Tra cứu từ Block Hash Accumulator các hash block đã được xác minh trong lịch sử
Bước này đảm bảo block header đang xử lý là thật. Sau khi hoàn tất, hợp đồng thông minh có thể truy cập bất kỳ giá trị nào trong block header.
3. Xác định root cần thiết (tùy chọn)
Có block header, ta có thể đi sâu vào nội dung của nó, cụ thể là:
stateRoot: Bản tóm tắt mã hóa toàn bộ trạng thái blockchain tại thời điểm block xảy ra.
receiptsRoot: Bản tóm tắt mã hóa của tất cả kết quả giao dịch (biên lai) trong block.
transactionsRoot: Bản tóm tắt mã hóa của tất cả giao dịch xảy ra trong block.
Các root này có thể được giải mã để xác minh sự tồn tại của tài khoản, biên lai hoặc giao dịch cụ thể trong block.
4. Xác minh dữ liệu dựa trên root đã chọn (tùy chọn)
Với root đã chọn và xét đến việc Ethereum dùng cấu trúc Merkle-Patricia Trie, ta có thể dùng bằng chứng bao gồm Merkle để xác minh sự tồn tại của dữ liệu trong cây. Các bước xác minh sẽ khác nhau tùy theo dữ liệu và độ sâu trong block.
Hiện hỗ trợ các mạng:
-
Từ Ethereum sang Starknet
-
Từ Ethereum Goerli* sang Starknet Goerli*
-
Từ Ethereum Goerli* sang zkSync Era Goerli*
Axiom
Axiom cung cấp cách để nhà phát triển truy vấn tiêu đề khối, giá trị tài khoản hoặc lưu trữ từ toàn bộ lịch sử Ethereum. Axiom giới thiệu phương pháp mới dựa trên liên kết mật mã. Tất cả kết quả trả về bởi AXIOM đều được xác minh trên chuỗi thông qua bằng chứng tri thức không, nghĩa là hợp đồng thông minh có thể sử dụng chúng mà không cần thêm giả định tin cậy nào.
Gần đây, Axiom đã phát hành Halo2-repl, là một REPL halo2 viết bằng Javascript chạy trên trình duyệt. Điều này cho phép nhà phát triển viết mạch ZK chỉ bằng Javascript chuẩn, không cần học ngôn ngữ mới như Rust, cài đặt thư viện chứng minh hay xử lý các phụ thuộc.
Axiom gồm hai thành phần kỹ thuật chính:
- AxiomV1 — Bộ nhớ đệm blockchain Ethereum, từ Genesis trở đi.
- AxiomV1Query — Hợp đồng thông minh thực hiện truy vấn đối với AxiomV1.
(1) Bộ nhớ đệm block hash trong AxiomV1:
Hợp đồng thông minh AxiomV1 lưu trữ block hash Ethereum từ block genesis dưới hai dạng:
Thứ nhất, lưu trữ root Merkle Keccak của 1024 block hash liên tiếp. Các root Merkle này được cập nhật qua bằng chứng ZK, xác minh xem tiêu đề khối hash có tạo thành chuỗi cam kết kết thúc tại một trong 256 block gần nhất có thể truy cập trực tiếp qua EVM hoặc block hash đã tồn tại trong bộ nhớ đệm AxiomV1 hay không.
Thứ hai, Axiom lưu trữ Merkle Mountain Range (MMR) của các root Merkle này từ block genesis. MMR này được xây dựng trên chuỗi, thông qua cập nhật các root Merkle Keccak ở phần đầu tiên của bộ nhớ đệm.
(2) Thực hiện truy vấn trong AxiomV1Query:
Hợp đồng thông minh AxiomV1Query dùng để truy vấn theo lô, nhằm đạt truy cập phi tin cậy đến dữ liệu tùy ý trong tiêu đề khối Ethereum lịch sử, tài khoản và lưu trữ tài khoản. Truy vấn có thể diễn ra trên chuỗi và hoàn tất trên chuỗi thông qua bằng chứng ZK đối với block hash trong bộ nhớ đệm AxiomV1.
Các bằng chứng ZK này kiểm tra xem dữ liệu chuỗi liên quan có nằm trực tiếp trong tiêu đề khối hay không, hoặc nằm trong Trie tài khoản hoặc lưu trữ của block, thông qua xác minh bằng chứng bao gồm (hoặc không bao gồm) của Merkle-Patricia Trie.
Nexus
Nexus cố gắng tận dụng bằng chứng tri thức không để xây dựng một nền tảng chung cho điện toán đám mây có thể kiểm chứng. Hiện tại hỗ trợ mọi kiến trúc máy, tương thích với risc-v/WebAssembly/EVM. Nexus sử dụng hệ thống bằng chứng supernova, nhóm thử nghiệm cho thấy bộ nhớ cần để tạo bằng chứng là 6GB, trong tương lai sẽ tiếp tục tối ưu để thiết bị đầu cuối thông thường có thể tạo bằng chứng.
Chính xác hơn, kiến trúc gồm hai phần:
-
Nexus zero: Mạng điện toán đám mây phi tập trung có thể kiểm chứng, được hỗ trợ bởi bằng chứng tri thức không và zkVM phổ quát.
-
Nexus: Mạng điện toán đám mây phân tán có thể kiểm chứng, được điều khiển bởi tính toán đa phương, sao chép máy trạng thái và máy ảo WASM phổ quát.
Ứng dụng Nexus và Nexus Zero có thể được viết bằng ngôn ngữ lập trình truyền thống, hiện hỗ trợ Rust, trong tương lai sẽ hỗ trợ thêm nhiều ngôn ngữ khác.
Ứng dụng Nexus chạy trên mạng điện toán đám mây phi tập trung, về bản chất là một «blockchain serverless» phổ quát kết nối trực tiếp với Ethereum. Do đó, ứng dụng Nexus không kế thừa độ an toàn của Ethereum, nhưng đổi lại, nhờ quy mô mạng nhỏ hơn, có thể đạt được khả năng tính toán cao hơn (như tính toán, lưu trữ và I/O điều khiển sự kiện). Ứng dụng Nexus chạy trên đám mây chuyên dụng, có thể đạt được đồng thuận nội bộ, và cung cấp «bằng chứng» (proof) về tính toán có thể kiểm chứng thông qua chữ ký ngưỡng toàn mạng có thể xác minh trong Ethereum (chứ không phải bằng chứng thật sự).
Ứng dụng Nexus Zero thực sự kế thừa độ an toàn của Ethereum, vì chúng là chương trình phổ quát kèm bằng chứng tri thức không, có thể xác minh trên chuỗi trên đường cong elliptic BN-254.
Vì Nexus có thể chạy bất kỳ tệp nhị phân WASM xác định nào trong môi trường sao chép, dự kiến nó sẽ được dùng như nguồn tính hợp lệ / phân tán / chống lỗi cho các ứng dụng tạo bằng chứng, bao gồm sequencer zk-rollup, sequencer optimistic rollup và các prover khác như chính zkVM của Nexus Zero.
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
ABCDE
