Nếu bạn được yêu cầu giải thích về bộ xử lý phụ cho một người không chuyên hoặc nhà phát triển chỉ trong một câu, bạn sẽ mô tả như thế nào?
Tôi nghĩ những gì Tiến sĩ Đồng Mo nói có thể rất gần với câu trả lời chuẩn - nói thẳng ra, bộ xử lý phụ đang "cho hợp đồng thông minh khả năng thực hiện Phân tích Dune".
Làm thế nào để phân tích câu này?
Hãy tưởng tượng tình huống khi chúng ta sử dụng Dune - bạn muốn tham gia LP trên Uniswap V3 để kiếm một số phí giao dịch, vì vậy bạn mở Dune và tìm thấy 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 các khoản phí giao dịch trong vòng 7 ngày qua, và các cặp giao dịch chính thống các phạm vi biến động trên và dưới, v.v...
Hoặc có lẽ khi StepN trở nên phổ biến, bạn bắt đầu đầu cơ giày và bạn không chắc chắn khi nào nên bán chúng, vì vậy bạn nhìn chằm chằm vào dữ liệu StepN trên Dune mỗi ngày, 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 giày... và dự định bán khi có sự tăng trưởng. Nếu xu hướng chậm lại hoặc giảm xuống, hãy chạy nhanh.
Tất nhiên, bạn không chỉ có thể nhìn chăm chú vào dữ liệu này, mà các nhóm phát triển của Uniswap và StepN cũng đang chú ý đến dữ liệu này.
Dữ liệu này rất ý nghĩa - nó không chỉ giúp phán đoán các thay đổi trong các xu hướng, mà còn sử dụng để tạo ra nhiều mánh khéo hơn, giống như phương pháp '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 phong cách và giá của những đôi giày mà người dùng thường xuyên mua bán, những đôi giày tương tự được đề xuất.
Ví dụ, dựa vào thời gian mà người dùng giữ giày Chuangshi, một 'Chương trình Thưởng Trung thành của Người dùng' sẽ được triển khai để tặng thêm airdrop hoặc các lợi ích cho người dùng trung thành.
Ví dụ, một kế hoạch 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 hoặc Trader cung cấp trên Uniswap, mang lại lợi ích giảm phí giao dịch cho Trader hoặc tăng cổ phần phí LP.
……
Lúc này, vấn đề nảy sinh - khi các công ty Internet lớn chơi với dữ liệu lớn + AI, 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 và không quan tâm.
Nhưng về phía Web3, sự minh bạch và không tin tưởng là đúng đắn chính trị tự nhiên của chúng tôi, và chúng tôi từ chối các hộp đen!
Vì vậy khi bạn muốn thực hiện kịch bản trên, bạn sẽ đối mặt với một tình huống khó khăn - bạn có thể đạt được điều đó thông qua các phương tiện tập trung, 'thủ công' sử dụng Dune để đếm dữ liệu chỉ số ở nền tảng, và sau đó triển khai và thực hiện; hoặc bạn có thể viết hợp đồng thông minh để tự động ghi lại dữ liệu này trên chuỗi, hoàn tất các tính toán và triển khai điểm một cách tự động.
Người trước đây có thể khiến bạn mắc phải vấn đề tin cậy “chính trị không chính xác”.
Phí gas được tạo ra bởi phần sau trên chuỗi sẽ là một con số thiên văn, và ví của bạn (phía dự án) không thể chi trả được.
Đây là thời điểm cho bộ xử lý phụ trình diễn. Kết hợp hai phương pháp vừa rồi, và đồng thời sử dụng bước “hướng dẫn nền” để “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 để “chỉ số +” ngoài chuỗi. Phần “tính toán” “tự chứng minh vô tội”, và sau đó đưa nó vào hợp đồng thông minh. Như vậy, vấn đề tin cậy được giải quyết, và các phí gas lớn biến mất. Hoàn hảo!
Tại sao nó được gọi là một “bộ xử lý phụ”? Trên thực tế, điều này bắt nguồn từ “GPU” trong lịch sử phát triển của Web2.0. Lý do mà 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à vì kiến trúc thiết kế của nó có thể xử lý một số phép tính mà CPU gặp khó khăn cơ bản, chẳng hạn như tính toán lặp song song quy mô lớn, tính toán đồ họa, v.v. Chính vì kiến trúc “bộ xử lý phụ” này mà chúng ta có các bộ phim CG tuyệt vời, trò chơi, mô hình trí tuệ nhân tạo, v.v. ngày nay, vì vậy kiến trúc bộ xử lý phụ này thực sự là một bước tiến trong kiến trúc máy tính. Hiện nay, các nhóm bộ xử lý phụ khác nhau cũng hy vọng giới thiệu kiến trúc này vào Web3.0. Blockchain ở đây tương tự như CPU của Web3.0. Dù là L1 hay L2, chúng đều 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, vì vậy một bộ xử lý phụ blockchain được giới thiệu để giúp xử lý các phép tính như vậy, từ đó mở rộng đáng kể khả năng ứng dụng blockchain.
Vì vậy, những gì bộ xử lý phụ làm có thể được tóm tắt thành hai điều:
Một thời gian trước, Starkware có một khái niệm phổ biến gọi là Bằng chứng lưu trữ, còn gọi là Bằng chứng trạng thái. Nó cơ bản làm bước 1, đại diện bởi Herodotus, Langrage, v.v. Trọng tâm kỹ thuật của nhiều cầu nối qua chuỗi dựa trên công nghệ ZK cũng nằm ở bước 1. 1 trên.
Bộ xử lý hỗ trợ không hơn gì khác ngoài việc thêm bước 2 sau khi hoàn thành bước 1. Sau khi trích xuất dữ liệu mà không tin cậy, nó sau đó có thể thực hiện một phép tính không cần tin cậy.
Vì vậy, để sử dụng một thuật ngữ kỹ thuật tương đối để mô tả nó một cách chính xác, bộ xử lý phụ nên 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à là một tập hợp con của Tính toán Có thể Xác minh.
Một điều cần lưu ý là bộ xử lý phụ không phải là Rollup.
Kỹ thuật, chứng minh ZK của Rollup tương tự như bước 2 ở trên, và quá trình bước 1 'lấy dữ liệu' được thực hiện trực tiếp thông qua Sequencer. Ngay cả một Sequencer 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 nào đó. Thay vì Proof of Storage dưới dạng ZK. Quan trọng hơn là ngoài lớp tính toán, ZK Rollup cũng cần triển khai một lớp lưu trữ tương tự như blockchain L1. Lưu trữ này là vĩnh viễn, trong khi ZK Coprocessor là 'không trạng thái'. Sau khi tính toán hoàn tất, không giữ lại bất kỳ trạng thái nào.
Từ quan điểm của các kịch bản ứng dụng, bộ xử lý phụ có thể được coi là một plug-in dịch vụ cho tất cả Layer1/Layer2, trong khi Rollup tạo lại một lớp thực thi để giúp mở rộng lớp giải quyết.
Sau khi đọc bài viết trên, bạn có thể nảy ra một nghi ngờ, liệu có cần phải thực hiện điều đó với ZK như một bộ xử lý phụ không? Nghe có vẻ giống như một “Biểu đồ với ZK được thêm vào”, và chúng ta không có bất kỳ “nghi ngờ lớn” nào về kết quả trên Biểu đồ.
Điều đó bởi vì khi bạn sử dụng Biểu đồ, bạn về cơ bản không liên quan đến tiền thật. Các chỉ số này phục vụ cho các dịch vụ off-chain. 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ỉ số dữ liệu như Biểu đồ, Alchemy, Zettablock, v.v., nhưng dữ liệu này không thể được đưa trở lại hợp đồng thông minh, vì khi bạn đưa nó trở lại, bạn sẽ thêm sự tin cậy bổ sung 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, sự tin cậy 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 yêu cầu mượn 100 nhân dân tệ, bạn có thể cho mà không chớp mắt. Đúng vậy, còn khi tôi yêu cầu bạn mượn 10.000 nhân dân tệ, hoặc thậm chí là 1 triệu nhân dân tệ?
Nhưng mà, chúng ta có thực sự cần phải sử dụng ZK để xử lý tất cả các kịch bản trên không? Cuối cùng, chúng ta có hai con đường 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 con đường chi nhánh tương ứng. Hỏi, liệu bộ xử lý cộng cũng có một chi nhánh của OP, như OP-Coprocessor không?
Trong thực tế, có - nhưng chúng tôi đang giữ thông tin cụ thể kín đáo vào lúc này, và chúng tôi sẽ phát hành thông tin chi tiết hơn sớm.
Kiến trúc của Brevis bao 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 từ tất cả các chuỗi khối được kết nối và tạo ra các 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 một bộ xử lý phụ tương thích 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 một chuỗi khối khác.
zkQueryNet: Một thị trường máy chủ truy vấn ZK mở nhận truy vấn dữ liệu từ các ứng dụng phi tập trung và xử lý chúng. Các truy vấn dữ liệu này xử lý các truy vấn bằng cách sử dụng các tiêu đề khối đã được xác minh từ zkFabric và tạo ra chứng minh truy vấn ZK. Những máy chủ này có cả các chức năng rất chuyên biệt và ngôn ngữ truy vấn chung để đáp ứng các nhu cầu ứng dụng khác nhau.
zkAggregatorRollup: Một blockchain ZK convolutional hoạt động như lớp tổng hợp và lưu trữ cho zkFabric và zkQueryNet. Nó xác minh các 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 minh của zk của mình cho tất cả các blockchain kết nối.
ZK Fabric là một phần quan trọng trong việc tạo ra bằng chứng cho phần tiêu đề khối. Điều quan trọng là đảm bảo an ninh cho phần này. Dưới đây là biểu đồ kiến trúc của zkFabric:
Khách hàng nhẹ dựa trên bằng chứng không cần biết (ZKP) của zkFabric giúp hoàn toàn không cần tin cậy mà không cần phải dựa vào bất kỳ thực thể xác minh ngoại vi 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ừ blockchain cơ bản và các bằng chứng đáng tin cậy toán học.
Mạng zkFabric Prover thực hiện mạch điện cho mỗi giao thức lightclient của blockchain, và mạng tạo ra các chứng minh tính hợp lệ cho các tiêu đề khối. Những người chứng minh có thể tận dụng các bộ gia tốc như GPU, FPGA và ASIC để giảm thiểu thời gian và chi phí chứng minh.
zkFabric dựa vào giả định bảo mật của blockchain và giao thức mã hóa cơ bản và giả định bảo mật của giao thức mã hóa cơ bản. Tuy nhiên, để đảm bảo hiệu quả của zkFabric, cần ít nhất một người truyền thông trung thực để đồng bộ fork đúng. Do đó, zkFabric áp dụng mạng truyền thông phân cấp thay vì một trạm truyền thông duy nhất để tối ưu hiệu quả của zkFabric. Mạng truyền thông này có thể tận dụng cấu trúc hiện có, như mạng bảo vệ trạng thái trong mạng Celer.
Phân bổ Prover: Mạng lưới prover là một mạng lưới prover ZKP phi tập trung chọn một prover cho mỗi nhiệm vụ tạo chứng minh và trả phí cho những prover này.
Sự triển khai hiện tại:
Các giao thức khách nhẹ hiện đang được triển khai cho các chuỗi khối khác nhau bao gồm Ethereum PoS, Cosmos Tendermint, và BNB Chain đều là ví dụ và bằng chứng về các khái niệm.
Brevis hiện đang hợp tác với uniswap hook, điều này đã giúp tăng cường các custom uniswap pools. 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 ra các dự án dựa trên dữ liệu giao dịch của người dùng lớ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).
Với sự trợ giúp của Brevis, hook đã giải quyết được thách thức. Hooks hiện có thể đọc từ dữ liệu chuỗi lịch sử đầy đủ của một người dùng hoặc LP và chạy các phép tính có thể tùy chỉnh một cách hoàn toàn không tin cậy.
Herodotus là một phần mềm trung gian truy cập dữ liệu mạnh mẽ cung cấp các hàm sau cho các hợp đồng thông minh để truy cập đồng bộ dữ liệu hiện tại và lịch sử trên chuỗi qua lớp Ethereum:
L1 trạng thái từ L2s
Trạng thái L2 từ cả hai L1 và các L2 khác
Các trạng thái L3/App-Chain đến L2 và L1
Herodotus đề xuất khái niệm chứng minh lưu trữ, kết hợp chứng minh việc bao gồm (xác nhận sự tồn tại của dữ liệu) và chứng minh tính toán (xác minh việc thực hiện của một luồng công việc đa bước) để chứng minh rằng một tập dữ liệu lớn (như toàn bộ blockchain Ethereum hoặc một rollup) hoặc tính hợp lệ của nhiều phần 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ách sử dụng cấu trúc dữ liệu như cây Merkle và cây Merkle Patricia. Điều độc đáo về các cấu trúc dữ liệu này là 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 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 tăng cường tính bảo mật của blockchain Ethereum. Bằng cách băm mật mã dữ liệu ở mỗi cấp độ của cây, thay đổi dữ liệu mà không bị phát hiện gần như là không thể. Mọi thay đổi đối với một điểm dữ liệu đòi hỏi thay đổi băm tương ứng trên cây đến băm gốc, mà có thể công khai thấy trong tiêu đề blockchain. Tính năng cơ bản này của blockchain cung cấp một mức độ cao về tính toàn vẹn dữ liệu và tính không thể thay đổi.
Thứ hai, những cây cối này cho phép xác thực dữ liệu hiệu quả thông qua các bằng chứng bao gồm. Ví dụ, khi xác minh việc bao gồm một giao dịch hoặc trạng thái của một hợp đồng, không cần phải tìm kiếm toàn bộ blockchain Ethereum mà chỉ cần đường dẫn trong cây Merkle liên quan.
Chứng minh lưu trữ theo định nghĩa của Herodotus là sự kết hợp của:
Quy trình :
Mọi dữ liệu trên blockchain đều thuộc về một khối cụ thể. Hash khối phục vụ như là đị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ữ, chúng ta cần xác định và xác minh hash 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ộ quy trình.
Sau khi nhận được mã hash khối liên quan, bước tiếp theo là truy cập vào tiêu đề khối. Để làm điều này, tiêu đề khối liên quan đến mã hash khối nhận được trong bước trước cần được băm. Sau đó, so sánh mã hash của tiêu đề khối cung cấp với mã hash khối kết quả:
Có hai cách để có được băm:
(1) Sử dụng mã lệnh BLOCKHASH để lấy
(2) Truy vấn các băm của các khối đã được xác minh trong lịch sử từ Bộ tích lũy Block Hash
Bước này đảm bảo rằng tiêu đề khối đang được xử lý là xác thực. Khi bước này hoàn thành, hợp đồng thông minh có thể truy cập bất kỳ giá trị nào trong tiêu đề khối.
Với tiêu đề khối trong tay, chúng ta có thể đào sâu vào nội dung của nó, cụ thể là:
stateRoot: Một bản tóm lược mật mã của toàn bộ trạng thái blockchain tại thời điểm xảy ra blockchain.
receiptsRoot: Bản rõng được mã hóa của tất cả các kết quả giao dịch (biên nhận) trong khối.
TransactionsRoot: Một 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ể giải mã, cho phép xác minh xem một tài khoản cụ thể, biên nhận hoặc giao dịch có được bao gồm trong khối hay không.
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 chứng minh 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ẽ thay đổi tùy thuộc vào dữ liệu và độ sâu của dữ liệu trong khối.
Mạng được hỗ trợ hiện tại:
Từ Ethereum đến Starknet
Từ Ethereum Goerliđến Starknet Goerli
Từ Ethereum Goerliđến zkSync Era Goerli
Axiom cung cấp một cách cho các 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 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ả trả về bởi Axiom được xác minh trên chuỗi thông qua chứng minh không biết, có nghĩa là hợp đồng thông minh có thể sử dụng chúng mà không cần giả định đáng tin cậy bổ sung.
Axiom vừa mới phát hànhHalo2-repl , là một trình bày 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 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 thư viện chứng minh, hoặc xử lý các phụ thuộc.
Axiom bao gồm hai thành phần công nghệ chính:
AxiomV1 — Bộ nhớ cache blockchain Ethereum, bắt đầu từ Genesis.
AxiomV1Query — Hợp đồng thông minh thực thi các truy vấn chống lại AxiomV1.
(1) Giá trị băm khối bộ nhớ cache trong AxiomV1:
Hợp đồng thông minh AxiomV1 lưu trữ băm khối Ethereum từ khối khởi đầu dưới hai dạng:
Đầu tiên, gốc Merkle Keccak của 1024 băm khối liên tiếp được lưu vào bộ đệm. Những gốc Merkle này được cập nhật thông qua chứng minh ZK, xác minh rằng băm tiêu đề khối tạo thành một 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 đến EVM hoặc một băm khối đã tồn tại trong bộ đệm AxiomV1.
Thứ hai. Axiom lưu trữ Rặng Núi Merkle của các gốc Merkle này bắt đầu từ khối nguyên sinh. Rặng 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ộ nhớ cache, gốc Merkle Keccak.
(2) Thực hiện truy vấn trong AxiomV1Query:
Hợp đồng thông minh AxiomV1Query được sử dụng để truy vấn theo lô để cho phép truy cập không cần tin cậy đến tiêu đề khối Ethereum lịch sử, tài khoản và dữ liệu tùy ý được lưu trữ trong các tài khoản. Các truy vấn có thể được thực hiện trên chuỗi và hoàn thành trên chuỗi thông qua chứng minh ZK chống lại các bản băm khối đã được lưu trữ AxiomV1.
Những chứng minh ZK kiểm tra xem dữ liệu trên chuỗi liên kết có nằm trực tiếp trong tiêu đề khối, hoặc trong cây tài khoản hoặc lưu trữ của khối, bằng cách xác minh chứng minh bao gồm (hoặc không bao gồm) của Trie Merkle-Patricia.
Nexus cố gắng xây dựng một nền tảng chung cho việc tính toán đám mây có thể xác minh bằng cách sử dụng bằng chứng không biết. Hiện tại, nó không phụ thuộc vào kiến trúc máy cụ thể và hỗ trợ risc 5/ WebAssembly/ EVM. Nexus sử dụng hệ thống bằng chứng supernova. Đội đã kiểm tra rằng bộ nhớ cần thiết để tạo ra bằng chứng là 6GB. Trong tương lai, nó sẽ được tối ưu hóa dựa trên cơ sở này để các thiết bị và máy tính bình thường của người dùng có thể tạo ra bằng chứng.
Để chính xác, kiến trúc được chia thành hai phần:
Nexus zero: Mạng máy tính đám mây có thể xác minh phi tập trung được cung cấp bởi chứng minh không biết và zkVM toàn cầu.
Nexus: Mạng tính toán đám mây có thể xác minh phi tập trung được cung cấp bởi tính toán đa bên, 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 các ngôn ngữ lập trình truyền thống, hiện đang hỗ trợ Rust, với nhiều ngôn ngữ khác sẽ được hỗ trợ trong tương lai.
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 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ó quyền truy cập vào sức mạnh tính toán cao hơn (như tính toán, lưu trữ và I / O theo hướng 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 riêng đạ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 (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 trong Ethereum.
Ứng dụng Nexus Zero thừa hưởng tính bảo mật từ Ethereum, vì chúng là chương trình đa năng với các chứng minh không biết và 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ỳ mã nhị phân WASM xác định nào trong môi trường sao chép, nó dự kiến sẽ được sử dụng như một nguồn chứng minh về tính hợp lệ/phân tán/chịu lỗi cho các ứng dụng được tạo ra, bao gồm cả các trình tự zk-rollup, các trình tự optimistic rollup, và các chứng minh Server khác, như chính zkVM của Nexus Zero.
Nếu bạn được yêu cầu giải thích về bộ xử lý phụ cho một người không chuyên hoặc nhà phát triển chỉ trong một câu, bạn sẽ mô tả như thế nào?
Tôi nghĩ những gì Tiến sĩ Đồng Mo nói có thể rất gần với câu trả lời chuẩn - nói thẳng ra, bộ xử lý phụ đang "cho hợp đồng thông minh khả năng thực hiện Phân tích Dune".
Làm thế nào để phân tích câu này?
Hãy tưởng tượng tình huống khi chúng ta sử dụng Dune - bạn muốn tham gia LP trên Uniswap V3 để kiếm một số phí giao dịch, vì vậy bạn mở Dune và tìm thấy 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 các khoản phí giao dịch trong vòng 7 ngày qua, và các cặp giao dịch chính thống các phạm vi biến động trên và dưới, v.v...
Hoặc có lẽ khi StepN trở nên phổ biến, bạn bắt đầu đầu cơ giày và bạn không chắc chắn khi nào nên bán chúng, vì vậy bạn nhìn chằm chằm vào dữ liệu StepN trên Dune mỗi ngày, 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 giày... và dự định bán khi có sự tăng trưởng. Nếu xu hướng chậm lại hoặc giảm xuống, hãy chạy nhanh.
Tất nhiên, bạn không chỉ có thể nhìn chăm chú vào dữ liệu này, mà các nhóm phát triển của Uniswap và StepN cũng đang chú ý đến dữ liệu này.
Dữ liệu này rất ý nghĩa - nó không chỉ giúp phán đoán các thay đổi trong các xu hướng, mà còn sử dụng để tạo ra nhiều mánh khéo hơn, giống như phương pháp '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 phong cách và giá của những đôi giày mà người dùng thường xuyên mua bán, những đôi giày tương tự được đề xuất.
Ví dụ, dựa vào thời gian mà người dùng giữ giày Chuangshi, một 'Chương trình Thưởng Trung thành của Người dùng' sẽ được triển khai để tặng thêm airdrop hoặc các lợi ích cho người dùng trung thành.
Ví dụ, một kế hoạch 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 hoặc Trader cung cấp trên Uniswap, mang lại lợi ích giảm phí giao dịch cho Trader hoặc tăng cổ phần phí LP.
……
Lúc này, vấn đề nảy sinh - khi các công ty Internet lớn chơi với dữ liệu lớn + AI, 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 và không quan tâm.
Nhưng về phía Web3, sự minh bạch và không tin tưởng là đúng đắn chính trị tự nhiên của chúng tôi, và chúng tôi từ chối các hộp đen!
Vì vậy khi bạn muốn thực hiện kịch bản trên, bạn sẽ đối mặt với một tình huống khó khăn - bạn có thể đạt được điều đó thông qua các phương tiện tập trung, 'thủ công' sử dụng Dune để đếm dữ liệu chỉ số ở nền tảng, và sau đó triển khai và thực hiện; hoặc bạn có thể viết hợp đồng thông minh để tự động ghi lại dữ liệu này trên chuỗi, hoàn tất các tính toán và triển khai điểm một cách tự động.
Người trước đây có thể khiến bạn mắc phải vấn đề tin cậy “chính trị không chính xác”.
Phí gas được tạo ra bởi phần sau trên chuỗi sẽ là một con số thiên văn, và ví của bạn (phía dự án) không thể chi trả được.
Đây là thời điểm cho bộ xử lý phụ trình diễn. Kết hợp hai phương pháp vừa rồi, và đồng thời sử dụng bước “hướng dẫn nền” để “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 để “chỉ số +” ngoài chuỗi. Phần “tính toán” “tự chứng minh vô tội”, và sau đó đưa nó vào hợp đồng thông minh. Như vậy, vấn đề tin cậy được giải quyết, và các phí gas lớn biến mất. Hoàn hảo!
Tại sao nó được gọi là một “bộ xử lý phụ”? Trên thực tế, điều này bắt nguồn từ “GPU” trong lịch sử phát triển của Web2.0. Lý do mà 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à vì kiến trúc thiết kế của nó có thể xử lý một số phép tính mà CPU gặp khó khăn cơ bản, chẳng hạn như tính toán lặp song song quy mô lớn, tính toán đồ họa, v.v. Chính vì kiến trúc “bộ xử lý phụ” này mà chúng ta có các bộ phim CG tuyệt vời, trò chơi, mô hình trí tuệ nhân tạo, v.v. ngày nay, vì vậy kiến trúc bộ xử lý phụ này thực sự là một bước tiến trong kiến trúc máy tính. Hiện nay, các nhóm bộ xử lý phụ khác nhau cũng hy vọng giới thiệu kiến trúc này vào Web3.0. Blockchain ở đây tương tự như CPU của Web3.0. Dù là L1 hay L2, chúng đều 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, vì vậy một bộ xử lý phụ blockchain được giới thiệu để giúp xử lý các phép tính như vậy, từ đó mở rộng đáng kể khả năng ứng dụng blockchain.
Vì vậy, những gì bộ xử lý phụ làm có thể được tóm tắt thành hai điều:
Một thời gian trước, Starkware có một khái niệm phổ biến gọi là Bằng chứng lưu trữ, còn gọi là Bằng chứng trạng thái. Nó cơ bản làm bước 1, đại diện bởi Herodotus, Langrage, v.v. Trọng tâm kỹ thuật của nhiều cầu nối qua chuỗi dựa trên công nghệ ZK cũng nằm ở bước 1. 1 trên.
Bộ xử lý hỗ trợ không hơn gì khác ngoài việc thêm bước 2 sau khi hoàn thành bước 1. Sau khi trích xuất dữ liệu mà không tin cậy, nó sau đó có thể thực hiện một phép tính không cần tin cậy.
Vì vậy, để sử dụng một thuật ngữ kỹ thuật tương đối để mô tả nó một cách chính xác, bộ xử lý phụ nên 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à là một tập hợp con của Tính toán Có thể Xác minh.
Một điều cần lưu ý là bộ xử lý phụ không phải là Rollup.
Kỹ thuật, chứng minh ZK của Rollup tương tự như bước 2 ở trên, và quá trình bước 1 'lấy dữ liệu' được thực hiện trực tiếp thông qua Sequencer. Ngay cả một Sequencer 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 nào đó. Thay vì Proof of Storage dưới dạng ZK. Quan trọng hơn là ngoài lớp tính toán, ZK Rollup cũng cần triển khai một lớp lưu trữ tương tự như blockchain L1. Lưu trữ này là vĩnh viễn, trong khi ZK Coprocessor là 'không trạng thái'. Sau khi tính toán hoàn tất, không giữ lại bất kỳ trạng thái nào.
Từ quan điểm của các kịch bản ứng dụng, bộ xử lý phụ có thể được coi là một plug-in dịch vụ cho tất cả Layer1/Layer2, trong khi Rollup tạo lại một lớp thực thi để giúp mở rộng lớp giải quyết.
Sau khi đọc bài viết trên, bạn có thể nảy ra một nghi ngờ, liệu có cần phải thực hiện điều đó với ZK như một bộ xử lý phụ không? Nghe có vẻ giống như một “Biểu đồ với ZK được thêm vào”, và chúng ta không có bất kỳ “nghi ngờ lớn” nào về kết quả trên Biểu đồ.
Điều đó bởi vì khi bạn sử dụng Biểu đồ, bạn về cơ bản không liên quan đến tiền thật. Các chỉ số này phục vụ cho các dịch vụ off-chain. 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ỉ số dữ liệu như Biểu đồ, Alchemy, Zettablock, v.v., nhưng dữ liệu này không thể được đưa trở lại hợp đồng thông minh, vì khi bạn đưa nó trở lại, bạn sẽ thêm sự tin cậy bổ sung 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, sự tin cậy 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 yêu cầu mượn 100 nhân dân tệ, bạn có thể cho mà không chớp mắt. Đúng vậy, còn khi tôi yêu cầu bạn mượn 10.000 nhân dân tệ, hoặc thậm chí là 1 triệu nhân dân tệ?
Nhưng mà, chúng ta có thực sự cần phải sử dụng ZK để xử lý tất cả các kịch bản trên không? Cuối cùng, chúng ta có hai con đường 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 con đường chi nhánh tương ứng. Hỏi, liệu bộ xử lý cộng cũng có một chi nhánh của OP, như OP-Coprocessor không?
Trong thực tế, có - nhưng chúng tôi đang giữ thông tin cụ thể kín đáo vào lúc này, và chúng tôi sẽ phát hành thông tin chi tiết hơn sớm.
Kiến trúc của Brevis bao 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 từ tất cả các chuỗi khối được kết nối và tạo ra các 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 một bộ xử lý phụ tương thích 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 một chuỗi khối khác.
zkQueryNet: Một thị trường máy chủ truy vấn ZK mở nhận truy vấn dữ liệu từ các ứng dụng phi tập trung và xử lý chúng. Các truy vấn dữ liệu này xử lý các truy vấn bằng cách sử dụng các tiêu đề khối đã được xác minh từ zkFabric và tạo ra chứng minh truy vấn ZK. Những máy chủ này có cả các chức năng rất chuyên biệt và ngôn ngữ truy vấn chung để đáp ứng các nhu cầu ứng dụng khác nhau.
zkAggregatorRollup: Một blockchain ZK convolutional hoạt động như lớp tổng hợp và lưu trữ cho zkFabric và zkQueryNet. Nó xác minh các 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 minh của zk của mình cho tất cả các blockchain kết nối.
ZK Fabric là một phần quan trọng trong việc tạo ra bằng chứng cho phần tiêu đề khối. Điều quan trọng là đảm bảo an ninh cho phần này. Dưới đây là biểu đồ kiến trúc của zkFabric:
Khách hàng nhẹ dựa trên bằng chứng không cần biết (ZKP) của zkFabric giúp hoàn toàn không cần tin cậy mà không cần phải dựa vào bất kỳ thực thể xác minh ngoại vi 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ừ blockchain cơ bản và các bằng chứng đáng tin cậy toán học.
Mạng zkFabric Prover thực hiện mạch điện cho mỗi giao thức lightclient của blockchain, và mạng tạo ra các chứng minh tính hợp lệ cho các tiêu đề khối. Những người chứng minh có thể tận dụng các bộ gia tốc như GPU, FPGA và ASIC để giảm thiểu thời gian và chi phí chứng minh.
zkFabric dựa vào giả định bảo mật của blockchain và giao thức mã hóa cơ bản và giả định bảo mật của giao thức mã hóa cơ bản. Tuy nhiên, để đảm bảo hiệu quả của zkFabric, cần ít nhất một người truyền thông trung thực để đồng bộ fork đúng. Do đó, zkFabric áp dụng mạng truyền thông phân cấp thay vì một trạm truyền thông duy nhất để tối ưu hiệu quả của zkFabric. Mạng truyền thông này có thể tận dụng cấu trúc hiện có, như mạng bảo vệ trạng thái trong mạng Celer.
Phân bổ Prover: Mạng lưới prover là một mạng lưới prover ZKP phi tập trung chọn một prover cho mỗi nhiệm vụ tạo chứng minh và trả phí cho những prover này.
Sự triển khai hiện tại:
Các giao thức khách nhẹ hiện đang được triển khai cho các chuỗi khối khác nhau bao gồm Ethereum PoS, Cosmos Tendermint, và BNB Chain đều là ví dụ và bằng chứng về các khái niệm.
Brevis hiện đang hợp tác với uniswap hook, điều này đã giúp tăng cường các custom uniswap pools. 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 ra các dự án dựa trên dữ liệu giao dịch của người dùng lớ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).
Với sự trợ giúp của Brevis, hook đã giải quyết được thách thức. Hooks hiện có thể đọc từ dữ liệu chuỗi lịch sử đầy đủ của một người dùng hoặc LP và chạy các phép tính có thể tùy chỉnh một cách hoàn toàn không tin cậy.
Herodotus là một phần mềm trung gian truy cập dữ liệu mạnh mẽ cung cấp các hàm sau cho các hợp đồng thông minh để truy cập đồng bộ dữ liệu hiện tại và lịch sử trên chuỗi qua lớp Ethereum:
L1 trạng thái từ L2s
Trạng thái L2 từ cả hai L1 và các L2 khác
Các trạng thái L3/App-Chain đến L2 và L1
Herodotus đề xuất khái niệm chứng minh lưu trữ, kết hợp chứng minh việc bao gồm (xác nhận sự tồn tại của dữ liệu) và chứng minh tính toán (xác minh việc thực hiện của một luồng công việc đa bước) để chứng minh rằng một tập dữ liệu lớn (như toàn bộ blockchain Ethereum hoặc một rollup) hoặc tính hợp lệ của nhiều phần 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ách sử dụng cấu trúc dữ liệu như cây Merkle và cây Merkle Patricia. Điều độc đáo về các cấu trúc dữ liệu này là 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 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 tăng cường tính bảo mật của blockchain Ethereum. Bằng cách băm mật mã dữ liệu ở mỗi cấp độ của cây, thay đổi dữ liệu mà không bị phát hiện gần như là không thể. Mọi thay đổi đối với một điểm dữ liệu đòi hỏi thay đổi băm tương ứng trên cây đến băm gốc, mà có thể công khai thấy trong tiêu đề blockchain. Tính năng cơ bản này của blockchain cung cấp một mức độ cao về tính toàn vẹn dữ liệu và tính không thể thay đổi.
Thứ hai, những cây cối này cho phép xác thực dữ liệu hiệu quả thông qua các bằng chứng bao gồm. Ví dụ, khi xác minh việc bao gồm một giao dịch hoặc trạng thái của một hợp đồng, không cần phải tìm kiếm toàn bộ blockchain Ethereum mà chỉ cần đường dẫn trong cây Merkle liên quan.
Chứng minh lưu trữ theo định nghĩa của Herodotus là sự kết hợp của:
Quy trình :
Mọi dữ liệu trên blockchain đều thuộc về một khối cụ thể. Hash khối phục vụ như là đị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ữ, chúng ta cần xác định và xác minh hash 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ộ quy trình.
Sau khi nhận được mã hash khối liên quan, bước tiếp theo là truy cập vào tiêu đề khối. Để làm điều này, tiêu đề khối liên quan đến mã hash khối nhận được trong bước trước cần được băm. Sau đó, so sánh mã hash của tiêu đề khối cung cấp với mã hash khối kết quả:
Có hai cách để có được băm:
(1) Sử dụng mã lệnh BLOCKHASH để lấy
(2) Truy vấn các băm của các khối đã được xác minh trong lịch sử từ Bộ tích lũy Block Hash
Bước này đảm bảo rằng tiêu đề khối đang được xử lý là xác thực. Khi bước này hoàn thành, hợp đồng thông minh có thể truy cập bất kỳ giá trị nào trong tiêu đề khối.
Với tiêu đề khối trong tay, chúng ta có thể đào sâu vào nội dung của nó, cụ thể là:
stateRoot: Một bản tóm lược mật mã của toàn bộ trạng thái blockchain tại thời điểm xảy ra blockchain.
receiptsRoot: Bản rõng được mã hóa của tất cả các kết quả giao dịch (biên nhận) trong khối.
TransactionsRoot: Một 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ể giải mã, cho phép xác minh xem một tài khoản cụ thể, biên nhận hoặc giao dịch có được bao gồm trong khối hay không.
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 chứng minh 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ẽ thay đổi tùy thuộc vào dữ liệu và độ sâu của dữ liệu trong khối.
Mạng được hỗ trợ hiện tại:
Từ Ethereum đến Starknet
Từ Ethereum Goerliđến Starknet Goerli
Từ Ethereum Goerliđến zkSync Era Goerli
Axiom cung cấp một cách cho các 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 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ả trả về bởi Axiom được xác minh trên chuỗi thông qua chứng minh không biết, có nghĩa là hợp đồng thông minh có thể sử dụng chúng mà không cần giả định đáng tin cậy bổ sung.
Axiom vừa mới phát hànhHalo2-repl , là một trình bày 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 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 thư viện chứng minh, hoặc xử lý các phụ thuộc.
Axiom bao gồm hai thành phần công nghệ chính:
AxiomV1 — Bộ nhớ cache blockchain Ethereum, bắt đầu từ Genesis.
AxiomV1Query — Hợp đồng thông minh thực thi các truy vấn chống lại AxiomV1.
(1) Giá trị băm khối bộ nhớ cache trong AxiomV1:
Hợp đồng thông minh AxiomV1 lưu trữ băm khối Ethereum từ khối khởi đầu dưới hai dạng:
Đầu tiên, gốc Merkle Keccak của 1024 băm khối liên tiếp được lưu vào bộ đệm. Những gốc Merkle này được cập nhật thông qua chứng minh ZK, xác minh rằng băm tiêu đề khối tạo thành một 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 đến EVM hoặc một băm khối đã tồn tại trong bộ đệm AxiomV1.
Thứ hai. Axiom lưu trữ Rặng Núi Merkle của các gốc Merkle này bắt đầu từ khối nguyên sinh. Rặng 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ộ nhớ cache, gốc Merkle Keccak.
(2) Thực hiện truy vấn trong AxiomV1Query:
Hợp đồng thông minh AxiomV1Query được sử dụng để truy vấn theo lô để cho phép truy cập không cần tin cậy đến tiêu đề khối Ethereum lịch sử, tài khoản và dữ liệu tùy ý được lưu trữ trong các tài khoản. Các truy vấn có thể được thực hiện trên chuỗi và hoàn thành trên chuỗi thông qua chứng minh ZK chống lại các bản băm khối đã được lưu trữ AxiomV1.
Những chứng minh ZK kiểm tra xem dữ liệu trên chuỗi liên kết có nằm trực tiếp trong tiêu đề khối, hoặc trong cây tài khoản hoặc lưu trữ của khối, bằng cách xác minh chứng minh bao gồm (hoặc không bao gồm) của Trie Merkle-Patricia.
Nexus cố gắng xây dựng một nền tảng chung cho việc tính toán đám mây có thể xác minh bằng cách sử dụng bằng chứng không biết. Hiện tại, nó không phụ thuộc vào kiến trúc máy cụ thể và hỗ trợ risc 5/ WebAssembly/ EVM. Nexus sử dụng hệ thống bằng chứng supernova. Đội đã kiểm tra rằng bộ nhớ cần thiết để tạo ra bằng chứng là 6GB. Trong tương lai, nó sẽ được tối ưu hóa dựa trên cơ sở này để các thiết bị và máy tính bình thường của người dùng có thể tạo ra bằng chứng.
Để chính xác, kiến trúc được chia thành hai phần:
Nexus zero: Mạng máy tính đám mây có thể xác minh phi tập trung được cung cấp bởi chứng minh không biết và zkVM toàn cầu.
Nexus: Mạng tính toán đám mây có thể xác minh phi tập trung được cung cấp bởi tính toán đa bên, 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 các ngôn ngữ lập trình truyền thống, hiện đang hỗ trợ Rust, với nhiều ngôn ngữ khác sẽ được hỗ trợ trong tương lai.
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 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ó quyền truy cập vào sức mạnh tính toán cao hơn (như tính toán, lưu trữ và I / O theo hướng 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 riêng đạ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 (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 trong Ethereum.
Ứng dụng Nexus Zero thừa hưởng tính bảo mật từ Ethereum, vì chúng là chương trình đa năng với các chứng minh không biết và 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ỳ mã nhị phân WASM xác định nào trong môi trường sao chép, nó dự kiến sẽ được sử dụng như một nguồn chứng minh về tính hợp lệ/phân tán/chịu lỗi cho các ứng dụng được tạo ra, bao gồm cả các trình tự zk-rollup, các trình tự optimistic rollup, và các chứng minh Server khác, như chính zkVM của Nexus Zero.