Khi khái niệm về bộ đồng xử lý trở nên phổ biến trong những tháng gần đây, trường hợp sử dụng ZK mới này ngày càng nhận được nhiều sự chú ý hơn.

Tuy nhiên, chúng tôi nhận thấy rằng hầu hết mọi người vẫn còn tương đối xa lạ với khái niệm bộ đồng xử lý, đặc biệt là vị trí chính xác của bộ đồng xử lý - bộ đồng xử lý là gì và không phải là gì, vẫn còn tương đối mơ hồ. Đối với việc so sánh các giải pháp kỹ thuật của một số rãnh đồng xử lý trên thị trường, vẫn chưa có ai phân loại nó một cách có hệ thống. Bài viết này hy vọng sẽ giúp thị trường và người dùng hiểu rõ hơn về đường đi của bộ đồng xử lý.

1. Đồng xử lý là gì và không phải là gì?

Nếu bạn được yêu cầu giải thích bộ đồng xử lý cho một người không rành về kỹ thuật hoặc nhà phát triển chỉ trong một câu, bạn sẽ mô tả nó như thế nào?

Tôi nghĩ những gì Tiến sĩ Dong Mo nói có thể rất gần với câu trả lời tiêu chuẩn—nói một cách thẳng thắn, bộ đồng xử lý đang “cung cấp cho các hợp đồng thông minh khả năng thực hiện Dune Analytics”.

Làm thế nào để giải mã câu này?

Hãy tưởng tượng kịch bản mà chúng tôi sử dụng Dune - Bạn muốn thực hiện LP trong Uniswap V3 để kiếm một số phí xử lý, vì vậy, bạn mở Dune và tìm khối lượng giao dịch gần đây của các cặp giao dịch khác nhau trên Uniswap, APR của phí xử lý trong 7 ngày qua, và các cặp giao dịch chính. Phạm vi dao động trên và dưới, v.v…

Hoặc có thể khi StepN trở nên phổ biến, bạn bắt đầu suy đoán về giày và không biết khi nào nên bán nên bạn nhìn chằm chằm vào dữ liệu StepN trên Dune hàng ngày, lượng giao dịch hàng ngày, số lượng người dùng mới, giá sàn của giày… và lên kế hoạch cho một khi đã có sự tăng trưởng. Nếu xu hướng chậm lại hoặc đi xuống, hãy chạy nhanh.

Tất nhiên, bạn có thể không chỉ nhìn chằm chằm vào những dữ liệu này mà nhóm phát triển của Uniswap và StepN cũng đang chú ý đến những dữ liệu này.

Những dữ liệu này rất có ý nghĩa - nó không chỉ giúp đánh giá những thay đổi trong xu hướng mà còn được sử dụng để tạo ra nhiều thủ thuật hơn, giống như cách tiếp cận “dữ liệu lớn” thường được các công ty Internet lớn sử dụng.

Ví dụ: dựa trên kiểu dáng và giá cả của những đôi giày mà người dùng thường mua và bán, những đôi giày tương tự được khuyến nghị.

Ví dụ: “Chương trình phần thưởng lòng trung thành của người dùng” sẽ được triển khai dựa trên khoảng thời gian người dùng nắm giữ Giày sáng tạo để mang đến cho người dùng trung thành nhiều airdrop hoặc lợi ích hơn.

Ví dụ: gói VIP tương tự như Cex có thể được triển khai dựa trên TVL hoặc khối lượng giao dịch do LP cung cấp trên Uniswap hoặc Trader, giúp Trader giảm phí giao dịch hoặc tăng lợi ích chia sẻ phí của LP…

Lúc này, vấn đề nảy sinh - dữ liệu lớn + AI của các công ty Internet lớn về cơ bản là một hộp đen. Họ có thể làm bất cứ điều gì họ muốn. Người dùng không thể nhìn thấy nó và không quan tâm.

Nhưng tại Web3, tính minh bạch và không đáng tin cậy là sự đúng đắn về mặt chính trị tự nhiên của chúng tôi và chúng tôi từ chối hộp đen!

Vì vậy, khi muốn hiện thực hóa kịch bản trên, bạn sẽ phải đối mặt với một tình huống khó xử - hoặc bạn có thể đạt được nó thông qua các phương tiện tập trung, sử dụng Dune “thủ công” để đếm dữ liệu chỉ mục trong nền, sau đó triển khai và triển khai nó; hoặc bạn có thể viết Thiết lập hợp đồng thông minh để tự động thu thập những dữ liệu này trên chuỗi, hoàn thành các phép tính và tự động triển khai các điểm.

Điều đầu tiên sẽ dẫn bạn đến những vấn đề về niềm tin “không chính xác về mặt chính trị”.

Phí gas do cái sau tạo ra trên chuỗi sẽ là một con số khổng lồ và ví (phía dự án) của bạn không thể mua được.

Đây là lúc để bộ đồng xử lý lên sân khấu. Kết hợp hai phương pháp vừa rồi, đồng thời sử dụng bước “thủ công phụ trợ” để “tự chứng minh vô tội” thông qua các phương tiện kỹ thuật. Nói cách khác, sử dụng công nghệ ZK để “lập chỉ mục + Phần “tính toán” “tự chứng minh sự vô tội”, sau đó đưa nó vào hợp đồng thông minh. Bằng cách này, vấn đề về lòng tin sẽ được giải quyết và khoản phí gas khổng lồ sẽ không còn nữa. Hoàn hảo!

Tại sao nó được gọi là “bộ đồng xử lý”? Thực chất, điều này xuất phát từ “GPU” trong lịch sử phát triển của Web2.0. Lý do tại sao GPU được giới thiệu như một phần cứng tính toán riêng biệt và tồn tại độc lập với CPU vào thời điểm đó là do kiến trúc thiết kế của nó có thể xử lý một số phép tính mà về cơ bản CPU khó xử lý, chẳng hạn như các phép tính lặp lại song song quy mô lớn, đồ họa tính toán, v.v. Chính nhờ kiến trúc “bộ đồng xử lý” này mà ngày nay chúng ta có những bộ phim CG, trò chơi, mô hình AI, v.v. tuyệt vời, vì vậy kiến trúc bộ đồng xử lý này thực sự là một bước nhảy vọt trong kiến trúc điện toán. Giờ đây, nhiều nhóm đồng xử lý khác nhau cũng hy vọng sẽ đưa kiến trúc này vào Web3.0. Blockchain ở đây tương tự như CPU của Web3.0. Cho dù đó là L1 hay L2, chúng vốn không phù hợp với các nhiệm vụ “dữ liệu nặng” và “logic tính toán phức tạp” như vậy, do đó, một bộ đồng xử lý blockchain được giới thiệu để giúp xử lý các phép tính như vậy, do đó mở rộng đáng kể khả năng của các ứng dụng blockchain.

Vì vậy, những gì bộ đồng xử lý thực hiện có thể được tóm tắt thành hai điều:

1. Lấy dữ liệu từ blockchain và sử dụng ZK để chứng minh rằng dữ liệu tôi nhận được là đúng và không bị giả mạo;
2. Thực hiện các phép tính tương ứng dựa trên dữ liệu tôi vừa nhận được và một lần nữa sử dụng ZK để chứng minh rằng kết quả tôi tính toán là đúng và không bị giả mạo. Kết quả tính toán có thể được gọi bằng hợp đồng thông minh “Phí thấp + Không cần tin cậy”.

Cách đây một thời gian, Starkware có một khái niệm khá phổ biến là Storage Proof hay còn gọi là State Proof. Về cơ bản nó thực hiện bước 1, được đại diện bởi Herodotus, Langrage, v.v. Trọng tâm kỹ thuật của nhiều cầu nối chuỗi dựa trên công nghệ ZK cũng nằm ở bước 1.1 trở đi.

Bộ đồng xử lý không gì khác hơn là bước 1, sau đó là bước 2. Sau khi trích xuất dữ liệu mà không cần tin cậy, hãy thực hiện phép tính không tin cậy và thế là xong.

Vì vậy, để sử dụng một thuật ngữ tương đối kỹ thuật để mô tả nó một cách chính xác, bộ đồng xử lý phải là một tập hợp con của Bằng chứng lưu trữ/Bằng chứng trạng thái và một tập hợp con của Tính toán có thể xác minh được.

Một điều cần lưu ý là bộ đồng xử lý không phải là Rollup.

Về mặt kỹ thuật, bằng chứng ZK của Rollup tương tự như bước 2 ở trên và quy trình “lấy dữ liệu” ở bước 1 được triển khai trực tiếp thông qua Sequencer. Ngay cả một Trình sắp xếp chuỗi phi tập trung cũng chỉ sử dụng một số loại cơ chế cạnh tranh hoặc đồng thuận để đạt được điều này. Hãy lấy dạng ZK này thay vì bằng chứng lưu trữ. Điều quan trọng hơn là ngoài lớp tính toán, ZK Rollup còn cần triển khai lớp lưu trữ tương tự như chuỗi khối L1. Bộ lưu trữ này là vĩnh viễn, trong khi Bộ đồng xử lý ZK là “không trạng thái”. Sau khi tính toán hoàn tất, không có trạng thái Tất cả nào được giữ lại.

Từ góc độ các kịch bản ứng dụng, bộ đồng xử lý có thể được coi là một phần bổ trợ dịch vụ cho tất cả Lớp 1/Lớp 2, trong khi Rollup tạo lại lớp thực thi để giúp mở rộng lớp giải quyết.

2. Tại sao tôi phải sử dụng ZK? Dùng OP có ổn không?

Sau khi đọc phần trên, có thể bạn sẽ thắc mắc liệu ZK có nên được sử dụng làm bộ đồng xử lý không? Nghe có vẻ rất giống “Biểu đồ có thêm ZK” và dường như chúng tôi không có bất kỳ “nghi ngờ lớn” nào về kết quả của Biểu đồ.

Đó là bởi vì khi bạn sử dụng Graph, về cơ bản không liên quan đến tiền thật. Các chỉ mục này phục vụ các dịch vụ ngoài chuỗi. Những gì bạn thấy trên giao diện người dùng phía trước là khối lượng giao dịch, lịch sử giao dịch, v.v. Dữ liệu có thể được cung cấp thông qua nhiều nhà cung cấp chỉ mục dữ liệu như Graph, Alchemy, Zettablock, v.v., nhưng những dữ liệu này không thể được đưa trở lại hợp đồng thông minh, bởi vì khi bạn đưa nó trở lại, bạn sẽ có thêm niềm tin vào dịch vụ chỉ mục. Khi dữ liệu được liên kết với tiền thật, đặc biệt là TVL có khối lượng lớn, niềm tin bổ sung này trở nên quan trọng. Hãy tưởng tượng lần sau khi một người bạn hỏi bạn vay 100 nhân dân tệ, bạn có thể cho vay mà không chớp mắt. Vâng, còn khi tôi hỏi bạn vay 10.000 nhân dân tệ, thậm chí 1 triệu nhân dân tệ thì sao?

Nhưng một lần nữa, chúng ta có thực sự phải sử dụng ZK để đồng xử lý tất cả các tình huống trên không? Rốt cuộc, chúng tôi có hai tuyến kỹ thuật, OP và ZK, trong Rollup. ZKML phổ biến gần đây cũng có khái niệm OPML về các tuyến nhánh tương ứng. Khi được hỏi, bộ đồng xử lý cũng có một nhánh của OP, chẳng hạn như OP-Coprocessor phải không?

Trên thực tế, thực sự là có - nhưng hiện tại chúng tôi đang giữ bí mật các chi tiết cụ thể và chúng tôi sẽ sớm công bố thông tin chi tiết hơn.

3. Bộ đồng xử lý nào tốt nhất - So sánh một số giải pháp kỹ thuật bộ đồng xử lý phổ biến trên thị trường

Brevis

Kiến trúc của Brevis bao gồm ba thành phần: zkFabric, zkQueryNet và zkAggregatorRollup.

Sau đây là sơ đồ kiến trúc Brevis:

zkFabric: Thu thập các tiêu đề khối từ tất cả các chuỗi khối được kết nối và tạo ra bằng chứng đồng thuận ZK chứng minh tính hợp lệ của các tiêu đề khối này. Thông qua zkFabric, Brevis triển khai bộ đồng xử lý có thể tương tác cho nhiều chuỗi, cho phép một chuỗi khối truy cập bất kỳ dữ liệu lịch sử nào của chuỗi khối khác.

zkQueryNet: Thị trường công cụ truy vấn ZK mở chấp nhận các truy vấn dữ liệu từ dApps và xử lý chúng. Truy vấn dữ liệu xử lý các truy vấn này bằng cách sử dụng các tiêu đề khối đã được xác minh từ zkFabric và tạo bằng chứng truy vấn ZK. Các công cụ này có cả chức năng chuyên môn cao và ngôn ngữ truy vấn chung để đáp ứng các nhu cầu ứng dụng khác nhau.

zkAggregatorRollup: Chuỗi khối tích chập ZK hoạt động như một lớp tổng hợp và lưu trữ cho zkFabric và zkQueryNet. Nó xác minh bằng chứng từ cả hai thành phần, lưu trữ dữ liệu đã được xác minh và cam kết gốc trạng thái được xác thực zk của nó cho tất cả các chuỗi khối được kết nối.

ZK Fabric là phần quan trọng trong việc tạo bằng chứng cho tiêu đề khối. Điều rất quan trọng là đảm bảo tính bảo mật của phần này. Sau đây là sơ đồ kiến trúc của zkFabric:

Ứng dụng khách ánh sáng dựa trên bằng chứng không kiến thức (ZKP) của zkFabric làm cho nó hoàn toàn không đáng tin cậy mà không cần dựa vào bất kỳ thực thể xác minh bên ngoài nào. Không cần phải dựa vào bất kỳ thực thể xác minh bên ngoài nào, vì tính bảo mật của nó hoàn toàn đến từ chuỗi khối cơ bản và bằng chứng đáng tin cậy về mặt toán học.

Mạng zkFabric Prover triển khai mạch điện cho giao thức lightclient của mỗi blockchain và mạng tạo ra bằng chứng hợp lệ cho các tiêu đề khối. Nhà cung cấp 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í kiểm chứng.

zkFabric dựa trên các giả định bảo mật của chuỗi khối và các giao thức mã hóa cơ bản cũng như các giả định bảo mật của các giao thức mã hóa cơ bản. Tuy nhiên, để đảm bảo tính hiệu quả của zkFabric, cần có ít nhất một người chuyển tiếp trung thực để đồng bộ hóa đúng nhánh. Do đó, zkFabric sử dụng mạng chuyển tiếp phi tập trung thay vì một rơle duy nhất để tối ưu hóa hiệu quả của zkFabric. Mạng chuyển tiếp này có thể tận dụng các cấu trúc hiện có, chẳng hạn như mạng bảo vệ trạng thái trong mạng Celer.

Phân bổ người chứng minh: Mạng người chứng minh là mạng người chứng minh ZKP phi tập trung, chọn một người chứng minh cho mỗi nhiệm vụ tạo bằng chứng và trả phí cho những người chứng minh này.

Triển khai hiện tại:

Các giao thức máy khách nhẹ hiện được triển khai cho nhiều chuỗi khối khác nhau bao gồm Ethereum PoS, Cosmos Tendermint và Chuỗi BNB đóng vai trò là ví dụ và bằng chứng về khái niệm.

Brevis hiện đã hợp tác với uniswap hook, công cụ này bổ sung rất nhiều nhóm uniswap tùy chỉnh. Tuy nhiên, so với CEX, UnisWap vẫn thiếu khả năng xử lý dữ liệu hiệu quả để tạo các dự án dựa vào dữ liệu giao dịch lớn của người dùng (chẳng hạn như các chương trình khách hàng thân thiết dựa trên khối lượng giao dịch). Chức năng.

Với sự giúp đỡ của Brevis, Hook đã giải quyết được thử thách. Giờ đây, hook có thể đọc toàn bộ dữ liệu chuỗi lịch sử của người dùng hoặc LP và chạy các phép tính có thể tùy chỉnh theo cách hoàn toàn không cần tin cậy.

Herodotus

Herodotus là phần mềm trung gian truy cập dữ liệu mạnh mẽ, cung cấp các hợp đồng thông minh với các chức năng sau để truy cập đồng bộ dữ liệu hiện tại và lịch sử trên chuỗi trên lớp Ethereum:

1. Trạng thái L1 từ L2
2. Trạng thái L2 từ cả L1 và L2 khác
3. Trạng thái L3/Chuỗi ứng dụng thành L2 và L1

Herodotus đề xuất khái niệm bằng chứng lưu trữ, 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 quy trình làm việc nhiều bước) để chứng minh rằng một tập dữ liệu lớn (chẳng hạn như toàn bộ chuỗi khối Ethereum hoặc cuộn lên) hoặc tính hợp lệ của nhiều phần tử.

Cốt lõi của blockchain là cơ sở dữ liệu, trong đó dữ liệu được mã hóa và bảo vệ bằng các cấu trúc dữ liệu như cây Merkle và cây Merkle Patricia. Điều độc đáo ở các cấu trúc dữ liệu này là khi dữ liệu được cam kết an toàn với chúng, bằng chứng có thể được tạo ra để xác nhận rằng dữ liệu được chứa trong cấu trúc.

Việc sử dụng cây Merkle và cây Merkle Patricia giúp tăng cường tính bảo mật của chuỗi khối Ethereum. Bằng cách băm mật 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. Bất kỳ thay đổi nào đối với điểm dữ liệu đều yêu cầu thay đổi hàm băm tương ứng trên cây thành hàm băm gốc, được hiển thị công khai trong tiêu đề blockchain. Tính năng cơ bản này của blockchain cung cấp mức độ toàn vẹn dữ liệu cao và tính bất biến.

Thứ hai, những cây này cho phép xác minh dữ liệu hiệu quả thông qua bằng chứng đưa vào. Ví dụ: khi xác minh việc bao gồm một giao dịch hoặc trạng thái của hợp đồng, không cần phải tìm kiếm toàn bộ chuỗi khối Ethereum mà chỉ cần tìm kiếm đường dẫn trong cây Merkle có liên quan.

Bằng chứng về việc lưu trữ theo định nghĩa của Herodotus là sự kết hợp của:

1. Bằng chứng ngăn chặn: Những bằng chứng này 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ật mã (chẳng hạn như cây Merkle hoặc cây Merkle Patricia), đảm bảo rằng dữ liệu được đề cập thực sự có trong tập dữ liệu.
2. Bằng chứng tính toán: Xác minh việc thực hiện quy trình làm việc gồm nhiều bước, chứng minh tính hợp lệ của một hoặc nhiều phần tử trong một tập dữ liệu rộng, chẳng hạn như toàn bộ chuỗi khối Ethereum hoặc tổng hợp. Ngoài việc chỉ ra sự hiện diện của dữ liệu, chúng còn xác minh các phép biến đổi hoặc hoạt động được áp dụng cho dữ liệu đó.
3. Bằng chứng không có kiến thức: Đơn giản hóa lượng hợp đồng thông minh dữ liệu cần tương tác. Bằng chứng không có kiến thức 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ý tất cả dữ liệu cơ bản.

Quy trình làm việc

1. Lấy khối băm

Mọi dữ liệu trên blockchain thuộc về một khối cụ thể. Khối băm đóng vai trò là mã định danh duy nhất của khối và tóm tắt tất cả nội dung của nó thông qua tiêu đề khối. Trong quy trình chứng minh lưu trữ, trước tiên chúng ta cần xác định và xác minh hàm băm khối của khối chứa dữ liệu mà chúng ta quan tâm. Đây là bước đầu tiên trong toàn bộ quá trình.

2. Lấy tiêu đề khối

Sau khi thu được hàm băm khối có liên quan, bước tiếp theo là truy cập tiêu đề khối. Để thực hiện việc này, tiêu đề khối liên quan đến hàm băm khối thu được ở bước trước cần được băm. Sau đó, hàm băm của tiêu đề khối được cung cấp sẽ được so sánh với hàm băm khối kết quả:

Có hai cách để lấy được hàm băm:

1. Sử dụng opcode BLOCKHASH để truy xuất
2. Truy vấn hàm băm của các khối đã được xác minh trong lịch sử từ Block Hash Accumulator

Bước này đảm bảo rằng tiêu đề khối đang được xử lý là xác thực. Sau khi hoàn thành bước này, hợp đồng thông minh có thể truy cập bất kỳ giá trị nào trong tiêu đề khối.

3.Xác định các gốc cần thiết (tùy chọn)

Với block header trong tay, chúng ta có thể đi sâu vào nội dung của nó, cụ thể:

stateRoot: Bản tóm tắt mật mã của toàn bộ trạng thái blockchain tại thời điểm blockchain xảy ra.

biên laiRoot: Bản tóm tắt được mã hóa của tất cả các kết quả giao dịch (biên lai) trong khối.

TransactionsRoot: Bản tóm tắt mật mã của tất cả các giao dịch xảy ra trong khối.

có thể được giải mã, cho phép xác minh xem một tài khoản, biên nhận hoặc giao dịch cụ thể có được đưa vào khối hay không.

4.Xác thực dữ liệu dựa trên thư mục gốc đã chọn (tùy chọn)

Với gốc mà chúng tôi đã chọn và xem xét rằng Ethereum sử dụng cấu trúc Merkle-Patricia Trie, chúng tôi có thể sử dụng bằng chứng bao gồm Merkle để xác minh rằng dữ liệu tồn tại trong cây. Các bước xác minh sẽ khác nhau tùy thuộc vào dữ liệu và độ sâu của dữ liệu trong khối.

Các mạng hiện được hỗ trợ:

1. Từ Ethereum đến Starknet
2. Từ Ethereum Goerli đến Starknet Goerli
3. Từ Ethereum Goerli đến zkSync Era Goerli

tiên đề

Axiom cung cấp một cách để các nhà phát triển truy vấn các tiêu đề khối, tài khoản hoặc giá trị lưu trữ từ toàn bộ lịch sử của Ethereum. AXIOM giới thiệu một phương pháp liên kết mới dựa trên mật mã. Tất cả các kết quả do Axiom trả về đều được xác minh trên chuỗi thông qua bằng chứng không có kiến thức, nghĩa là hợp đồng thông minh có thể sử dụng chúng mà không cần giả định tin cậy bổ sung.

Axiom gần đây đã phát hành Halo2-repl, một REPL halo2 dựa trên trình duyệt được viết bằng Javascript. Điều này cho phép các nhà phát triển viết các mạch ZK chỉ bằng Javascript tiêu chuẩn mà không cần phải học một ngôn ngữ mới như Rust, cài đặt các thư viện kiểm chứng hoặc xử lý các vấn đề phụ thuộc.

Axiom bao gồm hai thành phần công nghệ chính:

1. AxiomV1 — Bộ đệm chuỗi khối Ethereum, bắt đầu với Genesis.
2. AxiomV1Query — Một hợp đồng thông minh thực hiện các truy vấn đối với AxiomV1.

Băm khối bộ nhớ đệm trong AxiomV1:

Hợp đồng thông minh AxiomV1 lưu trữ các khối băm Ethereum kể từ khối gốc dưới hai dạng:

Đầu tiên, gốc Keccak Merkle của 1024 khối băm liên tiếp được lưu trữ. Các gốc Merkle này được cập nhật thông qua bằng chứng ZK, xác minh rằng hàm băm tiêu đề khối tạo thành chuỗi cam kết kết thúc bằng một trong 256 khối gần đây nhất có thể truy cập trực tiếp vào EVM hoặc hàm băm khối đã tồn tại trong bộ đệm AxiomV1.

Thứ hai, Axiom lưu trữ Dãy núi Merkle của các gốc Merkle này bắt đầu từ khối nguồn gốc. Dãy núi Merkle được xây dựng trên chuỗi bằng cách cập nhật phần đầu tiên của bộ đệm, gốc Keccak Merkle.

Thực hiện truy vấn trong AxiomV1Query:

Hợp đồng thông minh AxiomV1Query được sử dụng cho các truy vấn hàng loạt nhằm cho phép truy cập không đáng tin cậy vào các tiêu đề, tài khoản và dữ liệu tùy ý của khối Ethereum lịch sử được lưu trữ trong tài khoản. Các truy vấn có thể được thực hiện trên chuỗi và được hoàn thành trên chuỗi thông qua bằng chứng ZK dựa trên băm khối được lưu trong bộ nhớ đệm AxiomV1.

Các bằng chứng ZK này kiểm tra xem dữ liệu trên chuỗi có liên quan nằm trực tiếp trong tiêu đề khối hay trong tài khoản hoặc bộ lưu trữ của khối hay không, bằng cách xác minh bằng chứng bao gồm (hoặc không bao gồm) của bộ ba Merkle-Patricia.

Nexus

Nexus cố gắng sử dụng bằng chứng không có kiến thức để xây dựng nền tảng chung cho điện toán đám mây có thể kiểm chứng được. Hiện tại, nó là công nghệ bất khả tri về kiến trúc máy và hỗ trợ risc 5/WebAssembly/EVM. Nexus sử dụng hệ thống chứng minh siêu tân tinh. Nhóm đã kiểm tra rằng bộ nhớ cần thiết để tạo bằng chứng là 6GB. Trong tương lai, nó sẽ được tối ưu hóa trên cơ sở này để các máy tính thiết bị khách thông thường có thể tạo ra bằng chứng.

Nói chính xác, kiến trúc được chia thành hai phần:

1. Nexus zero: Mạng điện toán đám mây có thể xác minh phi tập trung được hỗ trợ bởi bằng chứng không có kiến thức và zkVM phổ quát.
2. Nexus: Mạng điện toán đám mây có thể kiểm chứng phi tập trung được hỗ trợ bởi tính toán của nhiều bên, sao chép máy trạng thái và máy ảo WASM phổ quát.

Các ứng dụng Nexus và Nexus Zero có thể được viết bằng các ngôn ngữ lập trình truyền thống, hiện đang hỗ trợ Rust và sẽ có thêm nhiều ngôn ngữ khác.

Các ứng dụng Nexus chạy trên mạng điện toán đám mây phi tập trung, về cơ bản là một “blockchain không có máy chủ” có mục đích chung được kết nối trực tiếp với Ethereum. Do đó, các ứng dụng Nexus không kế thừa tính bảo mật của Ethereum nhưng đổi lại có được quyền truy cập vào sức mạnh tính toán cao hơn (chẳng hạn như điện toán, lưu trữ và I/O theo sự kiện) do kích thước mạng của nó giảm. Các ứng dụng Nexus chạy trên một đám mây chuyên dụng nhằm đạt được sự đồng thuận nội bộ và cung cấp “bằng chứng” tính toán có thể kiểm chứng được (chứ không phải bằng chứng xác thực) thông qua các chữ ký ngưỡng trên toàn mạng có thể kiểm chứng được trong Ethereum.

Các ứng dụng Nexus Zero kế thừa tính bảo mật của Ethereum, vì chúng là các chương trình phổ biến với bằng chứng không có kiến thức có thể được xác minh trên chuỗi trên đường cong elip 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 được sao chép, nên nó dự kiến sẽ được sử dụng làm nguồn bằng chứng về tính hợp lệ/sự phân tán/khả năng chịu lỗi cho các ứng dụng được tạo, bao gồm trình sắp xếp chuỗi zk-rollup, trình sắp xếp chuỗi cuộn lên lạc quan và các máy chủ bằng chứng khác, chẳng hạn như chính zkVM của Nexus Zero.

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

1. Bài viết này được in lại từ [panewslab]. Mọi bản quyền đều thuộc về tác giả gốc [ABCDE]. 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.