Giới thiệu bonsol: ZK trên Solana, tính toán có thể xác minh sẽ mang lại những trường hợp sử dụng mới nào?
Tuyển chọn TechFlowTuyển chọn TechFlow
Giới thiệu bonsol: ZK trên Solana, tính toán có thể xác minh sẽ mang lại những trường hợp sử dụng mới nào?
Tính toán xác minh được (VC) là việc thực hiện một khối công việc cụ thể theo cách có thể tạo ra bằng chứng về quá trình thực hiện công việc đó, và bằng chứng này có thể được xác minh công khai mà không cần chạy lại phép tính.
Chuyên sâu báo cáo Web3Tác giả: Austbot
Biên dịch: TechFlow
Anagram Build dành phần lớn thời gian để nghiên cứu các trường hợp sử dụng mã hóa mới và áp dụng những trường hợp này vào các sản phẩm cụ thể. Gần đây, một trong những dự án nghiên cứu của chúng tôi đã đi sâu vào lĩnh vực tính toán có thể xác minh (VC). Nhóm chúng tôi đã tận dụng nghiên cứu này để tạo ra một hệ thống mã nguồn mở mới có tên là Bonsol. Chúng tôi chọn lĩnh vực nghiên cứu này vì tính toán có thể xác minh mang lại nhiều trường hợp sử dụng hiệu quả, đồng thời các L1 đều đang nỗ lực cải thiện chi phí và khả năng mở rộng của VC.
Trong bài viết này, chúng tôi có hai mục tiêu:
-
Thứ nhất, chúng tôi muốn đảm bảo rằng bạn hiểu rõ hơn về khái niệm VC và các sản phẩm mà nó có thể kích hoạt trong hệ sinh thái Solana.
-
Thứ hai, chúng tôi muốn giới thiệu đến bạn sản phẩm mới nhất của mình: Bonsol.
Tính toán có thể xác minh là gì?
Thuật ngữ "tính toán có thể xác minh (Verifiable Compute)" có lẽ không xuất hiện trong bản tóm tắt đầu tư của các startup bùng nổ thị trường, nhưng thuật ngữ "zero-knowledge" (ZK) thì chắc chắn sẽ. Vậy hai thuật ngữ này nghĩa là gì?
Tính toán có thể xác minh (VC) là việc thực thi một khối công việc cụ thể theo cách tạo ra bằng chứng cho quá trình xử lý, và bằng chứng đó có thể được kiểm tra công khai mà không cần chạy lại phép tính đó.
Zero-knowledge (ZK) đề cập đến khả năng chứng minh một tuyên bố liên quan đến dữ liệu hoặc phép tính mà không cần tiết lộ tất cả dữ liệu hoặc đầu vào của phép tính đó. Trên thực tế, hai thuật ngữ này thường bị pha trộn với nhau, và ZK đôi khi là một cái tên sai lệch. Nó chủ yếu liên quan đến việc lựa chọn thông tin nào cần công khai để chứng minh một tuyên bố. VC là một thuật ngữ chính xác hơn, và cũng là mục tiêu tổng thể của nhiều kiến trúc hệ thống phân tán hiện tại.
VC giúp chúng ta xây dựng các sản phẩm mã hóa tốt hơn như thế nào?
Vậy tại sao chúng ta muốn thêm hệ thống VC hoặc ZK vào các nền tảng như Solana và Ethereum? Câu trả lời dường như liên quan nhiều hơn đến an toàn cho nhà phát triển. Nhà phát triển hệ thống đóng vai trò trung gian giữa sự tin tưởng của người dùng vào một "hộp đen" và các chức năng kỹ thuật làm cho sự tin tưởng đó trở nên khách quan. Bằng cách tận dụng công nghệ ZK/VC, các nhà phát triển có thể giảm diện tích tấn công trong các sản phẩm họ đang xây dựng. Hệ thống VC chuyển trọng tâm niềm tin sang hệ thống chứng minh và khối lượng công việc tính toán được chứng minh. Điều này tương tự như sự đảo ngược niềm tin khi chuyển từ phương pháp web2 điển hình (client/server) sang phương pháp blockchain web3 — niềm tin chuyển từ phụ thuộc vào cam kết của công ty sang tin tưởng vào mã nguồn mở và hệ thống mã hóa của mạng lưới. Từ góc nhìn người dùng, không có hệ thống "zero-trust" thực sự nào tồn tại; đối với họ, mọi thứ vẫn giống như một hộp đen.
Ví dụ, với hệ thống đăng nhập ZK, trách nhiệm của nhà phát triển trong việc duy trì cơ sở dữ liệu và hạ tầng an toàn sẽ giảm đi, vì hệ thống chỉ cần xác minh một số thuộc tính mã hóa nhất định đã đạt được hay chưa. Công nghệ VC đang được áp dụng trong nhiều lĩnh vực nơi cần sự đồng thuận, với điều kiện duy nhất đảm bảo đồng thuận là toán học phải hợp lệ.
Mặc dù có nhiều ví dụ thành công về việc sử dụng VC và ZK ngoài thực tế, nhưng nhiều hệ thống hiện tại vẫn phụ thuộc vào tiến độ phát triển ở nhiều lớp khác nhau của ngăn xếp phần mềm mã hóa để đạt được tốc độ và hiệu quả đủ cao cho sản xuất.
Là một phần công việc tại Anagram, chúng tôi có cơ hội nói chuyện với nhiều nhà sáng lập/mã hóa viên để tìm hiểu cách trạng thái hiện tại của ngăn xếp phần mềm mã hóa ảnh hưởng đến đổi mới sản phẩm. Trải qua nhiều cuộc trao đổi, chúng tôi nhận thấy một xu hướng thú vị: một loạt dự án đang tích cực chuyển logic sản phẩm lên chuỗi sang môi trường off-chain, vì việc thực hiện trên chuỗi trở nên quá đắt đỏ hoặc họ cần thêm các logic kinh doanh phức tạp hơn. Cuối cùng, các nhà phát triển này phải tự tìm kiếm các hệ thống và công cụ để cân bằng giữa phần on-chain và off-chain ngày càng mạnh mẽ của sản phẩm họ đang xây dựng. Đây chính là lúc VC trở thành yếu tố then chốt trong hành trình kết nối thế giới on-chain và off-chain bằng phương pháp đáng tin cậy và có thể kiểm chứng.
Hiện tại, hệ thống VC/ZK hoạt động như thế nào?
Hiện nay, các hàm VC và ZK chủ yếu được thực hiện trên các lớp tính toán thay thế như Rollup, sidechain, relay, oracle hoặc coprocessor, có thể được gọi lại thông qua runtime hợp đồng thông minh. Để thực hiện luồng công việc này, nhiều chuỗi L1 đang nỗ lực cung cấp các lối tắt bên ngoài runtime hợp đồng thông minh (ví dụ như system call hoặc precompile), nhằm thực hiện các thao tác nếu thực hiện trực tiếp trên chuỗi sẽ quá tốn kém.
Hiện có một vài mô hình phổ biến trong hệ thống VC. Tôi sẽ đề cập đến bốn mô hình đầu tiên mà tôi biết. Trừ trường hợp cuối cùng, bằng chứng ZK đều được thực hiện off-chain, nhưng điểm khác biệt nằm ở thời điểm và địa điểm bằng chứng được xác minh, tạo nên ưu thế riêng cho từng mô hình.
Xác minh hoàn toàn trên chuỗi
Đối với các hệ thống chứng minh VC và ZK có thể tạo ra bằng chứng nhỏ, ví dụ như Groth16 hoặc một số biến thể Plonk, bằng chứng sau đó được gửi lên chuỗi và được xác minh trực tiếp trên chuỗi bằng mã đã triển khai trước đó. Các hệ thống như vậy hiện khá phổ biến. Cách tốt nhất để thử phương pháp này là dùng Circom với bộ xác minh Groth16 trên Solana hoặc EVM. Tuy nhiên, nhược điểm là các hệ thống chứng minh này khá chậm. Chúng thường yêu cầu học một ngôn ngữ mới. Việc xác minh một hàm băm 256 bit trong Circom thực tế đòi hỏi phải xử lý từng bit một. Dù có nhiều thư viện cho phép bạn chỉ cần gọi hàm băm, nhưng đằng sau đó, bạn vẫn phải tự tái hiện các hàm này trong mã Circom. Những hệ thống này rất phù hợp khi phần tử ZK/VC trong trường hợp sử dụng của bạn khá nhỏ, hoặc khi bạn cần chứng minh rằng bằng chứng là hợp lệ trước khi thực hiện một hành động xác định khác. Hiện tại, Bonsol thuộc nhóm đầu tiên này.
Xác minh ngoài chuỗi
Bằng chứng được gửi lên chuỗi để mọi bên đều có thể thấy, và sau đó có thể được xác minh bằng tính toán off-chain. Trong mô hình này, bạn có thể hỗ trợ bất kỳ hệ thống chứng minh nào, nhưng vì việc xác minh không diễn ra trên chuỗi, bạn không thể đạt được mức độ chắc chắn tương đương cho bất kỳ hành động nào phụ thuộc vào việc nộp bằng chứng. Mô hình này phù hợp với các hệ thống có cửa sổ thách thức, nơi các bên có thể "phản đối" và cố gắng chứng minh rằng bằng chứng là sai.
Mạng xác minh
Bằng chứng được gửi đến mạng xác minh, và mạng này hoạt động như một oracle gọi đến hợp đồng thông minh. Bạn nhận được tính chắc chắn, nhưng đồng thời cũng phải tin tưởng vào mạng xác minh.
Xác minh đồng bộ trên chuỗi
Mô hình thứ tư và cuối cùng này khá khác biệt: trong trường hợp này, việc tạo bằng chứng và xác minh xảy ra đồng thời trên chuỗi. Điều này có nghĩa là L1 hoặc hợp đồng thông minh trên L1 thực sự có thể chạy sơ đồ ZK trên dữ liệu đầu vào của người dùng và cho phép chứng minh việc thực thi trên dữ liệu riêng tư. Ngoài thực tế, có rất ít ví dụ rộng rãi về cách tiếp cận này, và những gì bạn có thể làm thường bị giới hạn ở các thao tác toán học cơ bản hơn.
Tổng kết
Cả bốn mô hình này đều đang được thử nghiệm trong các hệ sinh thái chuỗi khác nhau, và chúng ta sẽ sớm thấy liệu có mô hình mới nào xuất hiện và mô hình nào chiếm ưu thế. Ví dụ, trên Solana, chưa có người chiến thắng rõ ràng nào, và cảnh quan VC/ZK vẫn còn ở giai đoạn sơ khai. Trên nhiều chuỗi, bao gồm cả Solana, phương pháp phổ biến nhất là mô hình đầu tiên — xác minh hoàn toàn trên chuỗi là tiêu chuẩn vàng, nhưng như đã thảo luận, nó cũng đi kèm một số nhược điểm, chủ yếu là độ trễ và giới hạn chức năng mạch của bạn. Khi đi sâu vào Bonsol, bạn sẽ thấy nó tuân theo mô hình đầu tiên nhưng có một vài điểm khác biệt.
Giới thiệu Bonsol
Bonsol là một hệ thống VC gốc trên Solana mới mà đội ngũ Anagram chúng tôi đã xây dựng và công bố mã nguồn mở. Bonsol cho phép các nhà phát triển tạo ra các tệp thực thi có thể xác minh liên quan đến dữ liệu riêng tư và công khai, sau đó tích hợp kết quả vào hợp đồng thông minh Solana. Lưu ý rằng dự án này phụ thuộc vào chuỗi công cụ RISC0 phổ biến.
Cảm hứng cho dự án này đến từ một câu hỏi thường xuyên được đặt ra khi chúng tôi trao đổi hàng tuần với nhiều dự án: “Làm thế nào tôi có thể chứng minh trên chuỗi một thứ gì đó dựa trên dữ liệu riêng tư?” Mặc dù “thứ gì đó” trong mỗi trường hợp là khác nhau, nhưng mong muốn cốt lõi là giống nhau: giảm sự phụ thuộc tập trung.
Trước khi đi sâu vào chi tiết hệ thống, hãy cùng xem xét hai trường hợp sử dụng khác nhau để minh họa sức mạnh của Bonsol.
Tình huống một
Một Dapp cho phép người dùng mua vé số trong các nhóm token khác nhau. Các nhóm này được "rót" mỗi ngày từ một nhóm toàn cục, khiến số lượng token trong nhóm (số lượng từng loại token) bị ẩn đi. Người dùng có thể mua quyền truy cập vào phạm vi ngày càng cụ thể hơn về số dư token trong nhóm. Nhưng có một điều kiện: ngay khi người dùng mua phạm vi đó, nó sẽ được công khai cho tất cả người dùng. Sau đó, người dùng phải quyết định có mua vé số hay không. Họ có thể cho rằng không đáng để mua, hoặc có thể mua vé số để đảm bảo một phần lợi ích trong nhóm.
Bonsol bắt đầu hoạt động khi nhóm được tạo và khi người dùng thanh toán để mở phạm vi. Khi tạo/nạp nhóm, chương trình ZK nhận đầu vào riêng tư là số lượng từng loại token. Loại token là đầu vào đã biết, và địa chỉ nhóm cũng là đầu vào đã biết. Bằng chứng được tạo ra là bằng chứng về việc chọn ngẫu nhiên từ nhóm toàn cục vào nhóm hiện tại. Bằng chứng cũng chứa cam kết về số dư. Hợp đồng trên chuỗi sẽ nhận bằng chứng này, xác minh và lưu trữ các cam kết này, để khi nhóm cuối cùng đóng lại và số dư được chuyển từ nhóm toàn cục đến người trúng thưởng, họ có thể xác minh xem số lượng token có thay đổi kể từ lần chọn ngẫu nhiên ban đầu hay không.
Khi người dùng mua quyền "mở" để xem phạm vi số dư token ẩn, chương trình ZK lấy số dư token thực tế làm đầu vào riêng tư và tạo ra một chuỗi giá trị, đi kèm với bằng chứng đã cam kết. Đầu vào công khai của chương trình ZK này là bằng chứng tạo nhóm trước đó và đầu ra của nó. Theo cách này, toàn bộ hệ thống được xác minh. Bằng chứng trước đó phải được xác minh trong bằng chứng phạm vi, và số dư token phải băm thành cùng một giá trị như đã cam kết trong bằng chứng đầu tiên. Bằng chứng phạm vi cũng được gửi lên chuỗi và như đã nói, làm cho phạm vi hiển thị với tất cả người tham gia.
Mặc dù có nhiều cách để triển khai hệ thống kiểu xổ số này, nhưng các thuộc tính của Bonsol làm giảm đáng kể sự tin tưởng vào tổ chức tổ chức xổ số. Nó cũng nhấn mạnh tính tương tác giữa Solana và các hệ thống VC. Chương trình Solana (hợp đồng thông minh) đóng vai trò then chốt trong việc thiết lập niềm tin, vì nó xác minh bằng chứng rồi cho phép chương trình thực hiện bước tiếp theo.
Tình huống hai
Bonsol cho phép các nhà phát triển tạo bộ công cụ để các hệ thống khác sử dụng. Bonsol bao gồm khái niệm triển khai, nơi nhà phát triển có thể tạo một số chương trình ZK và triển khai chúng đến các nhà vận hành Bonsol. Hiện tại, các nhà vận hành mạng Bonsol có một số cách cơ bản để đánh giá xem việc thực thi yêu cầu chương trình ZK có lợi về mặt kinh tế hay không. Họ có thể thấy một số thông tin cơ bản về việc chương trình ZK cần bao nhiêu tính toán, kích thước đầu vào và tiền boa do người yêu cầu cung cấp. Nhà phát triển có thể triển khai một bộ công cụ mà họ nghĩ nhiều Dapp khác sẽ muốn sử dụng.
Trong cấu hình chương trình ZK, nhà phát triển chỉ định thứ tự và loại đầu vào cần thiết. Nhà phát triển có thể phát hành một InputSet đã được cấu hình sẵn một hoặc toàn bộ đầu vào. Điều này có nghĩa là họ có thể cấu hình trước một phần đầu vào, giúp người dùng xác minh tính toán trên tập dữ liệu rất lớn.
Ví dụ, giả sử nhà phát triển tạo một hệ thống có thể chứng minh trên chuỗi rằng việc chuyển quyền sở hữu NFT bao gồm một tập hợp cụ thể các ví. Nhà phát triển có thể có một InputSet đã cấu hình sẵn chứa nhiều thông tin giao dịch lịch sử. Chương trình ZK tìm kiếm tập hợp đó để tìm chủ sở hữu khớp. Đây là một ví dụ nhân tạo, có thể được thực hiện bằng nhiều cách.
Xét thêm một ví dụ khác: nhà phát triển có thể viết một chương trình ZK có thể xác minh rằng một cặp khóa đã ký đến từ một cặp khóa hoặc cặp khóa phân cấp, mà không tiết lộ khóa công khai của các cặp khóa ủy quyền đó. Giả sử điều này hữu ích cho nhiều Dapp khác, và chúng sử dụng chương trình ZK này. Giao thức cung cấp một khoản tiền boa nhỏ cho tác giả chương trình ZK. Vì hiệu suất rất quan trọng, nhà phát triển có động lực làm cho chương trình của họ chạy nhanh để các nhà vận hành sẵn sàng thực thi nó, trong khi nhà phát triển cố gắng ăn cắp công việc của người khác cần thay đổi chương trình theo cách nào đó để triển khai, vì nội dung chương trình ZK được xác minh. Bất kỳ thao tác nào thêm vào chương trình ZK đều ảnh hưởng đến hiệu suất, mặc dù điều này chắc chắn không tuyệt đối đáng tin cậy, nhưng có thể giúp đảm bảo rằng nhà phát triển được thưởng vì đổi mới.
Kiến trúc Bonsol
Những trường hợp sử dụng này giúp mô tả mục đích của Bonsol, nhưng hãy cùng xem xét kiến trúc hiện tại, mô hình khuyến khích và quy trình thực thi của nó.
Hình ảnh trên mô tả quy trình mà người dùng cần thực hiện một phép tính có thể xác minh, thường được thực hiện thông qua một dapp yêu cầu người dùng thực hiện một số thao tác. Điều này sẽ có dạng một yêu cầu thực thi, bao gồm thông tin về chương trình ZK đang được thực thi, đầu vào hoặc tập đầu vào, thời gian mà phép tính phải được chứng minh và tiền boa (đây là cách thu phí trung gian). Yêu cầu được các trung gian (relay) nhận, họ phải cạnh tranh để tuyên bố quyền sở hữu thực thi và bắt đầu tạo bằng chứng. Tùy theo khả năng của trung gian vận hành cụ thể, họ có thể từ bỏ nếu tiền boa không đáng hoặc chương trình zk hoặc đầu vào quá lớn. Nếu họ quyết định thực hiện phép tính này, họ phải tuyên bố thực hiện. Nếu họ là người đầu tiên giành được tuyên bố, bằng chứng của họ sẽ được chấp nhận cho đến một thời điểm nhất định. Nếu họ không tạo ra bằng chứng kịp thời, các nút khác có thể tuyên bố thực thi. Để tuyên bố, trung gian phải đặt cọc một khoản tài sản đảm bảo, hiện tại được mã cứng là tiền boa/2, sẽ bị phạt nếu họ không tạo ra bằng chứng đúng.
Bonsol được xây dựng dựa trên lập luận rằng nhiều phép tính hơn sẽ được chuyển sang một lớp mà tại đó chúng có thể được xác minh và xác minh trên chuỗi, và Solana sẽ nhanh chóng trở thành chuỗi được lựa chọn hàng đầu cho VC và ZK. Giao dịch nhanh, tính toán rẻ và cộng đồng người dùng ngày càng tăng khiến Solana trở thành nơi lý tưởng để thử nghiệm những ý tưởng này.
Việc xây dựng có dễ dàng không? Tất nhiên là không!
Không có nghĩa là không có thách thức khi xây dựng Bonsol. Để đưa bằng chứng Risc0 lên Solana và xác minh trên đó, chúng tôi cần làm cho nó nhỏ lại. Nhưng chúng tôi không thể làm điều đó đơn giản mà không hy sinh độ an toàn của bằng chứng. Do đó, chúng tôi sử dụng Circom để gói bằng chứng Stark của Risc0 — vốn có thể khoảng 200KB — rồi gói nó trong bằng chứng Groth16, luôn có kích thước 256 byte. May mắn thay, Risc0 cung cấp một số công cụ ban đầu cho việc này, nhưng nó làm tăng thêm nhiều chi phí và phụ thuộc vào hệ thống.
Khi bắt đầu xây dựng Bonsol và sử dụng các công cụ hiện có để gói Stark với Snark, chúng tôi tìm cách giảm phụ thuộc và tăng tốc độ. Circom cho phép biên dịch mã Circom thành C++ hoặc wasm. Chúng tôi thử biên dịch mạch Circom thành tệp wasmu được tạo bởi LLVM. Đây là cách nhanh và hiệu quả nhất để làm cho bộ công cụ Groth16 di động và vẫn nhanh. Chúng tôi chọn wasm vì tính di động, trong khi mã C++ phụ thuộc vào kiến trúc CPU x86, nghĩa là các Macbook mới hoặc máy chủ dựa trên Arm sẽ không thể sử dụng mã này. Tuy nhiên, trong khung thời gian chúng tôi phải làm việc, điều này trở thành ngõ cụt. Vì hầu hết thí nghiệm nghiên cứu sản phẩm của chúng tôi đều bị giới hạn thời gian cho đến khi chứng minh được giá trị, chúng tôi chỉ có 2-4 tuần phát triển để thử nghiệm ý tưởng này. Bộ biên dịch llvm wasm không thể xử lý mã wasm được tạo ra. Qua nhiều nỗ lực hơn, chúng tôi có thể vượt qua khó khăn này, nhưng chúng tôi đã thử nhiều cờ tối ưu và cách làm cho trình biên dịch llvm hoạt động như plugin wasmer để biên dịch trước mã này thành llvm, nhưng không thành công. Với mạch Circom khoảng 1,5 triệu dòng mã, bạn có thể hình dung lượng mã wasm sẽ rất lớn. Sau đó, chúng tôi chuyển sang thử tạo cầu nối chỉ giữa C++ và kho mã Rust của trung gian. Điều này cũng nhanh chóng thất bại vì mã C++ chứa một số mã assembly đặc thù cho x86 mà chúng tôi không muốn can thiệp. Để công bố hệ thống ra công chúng, cuối cùng chúng tôi đơn giản là khởi chạy một hệ thống sử dụng mã C++ nhưng loại bỏ một số phụ thuộc. Trong tương lai, chúng tôi hy vọng mở rộng một tuyến tối ưu hóa khác mà chúng tôi đang phát triển — đó là biên dịch mã C++ thành đồ thị thực thi. Các thành phần C++ được biên dịch từ Circom chủ yếu chỉ là các phép số học mô-đun trên trường hữu hạn với bộ tạo số nguyên tố rất lớn. Điều này cho thấy kết quả hứa hẹn với các thành phần C++ nhỏ và đơn giản hơn, nhưng cần thêm công việc để làm việc với hệ thống Risc0. Bởi vì mã C++ được tạo ra có khoảng 7 triệu dòng, bộ tạo đồ thị dường như đạt giới hạn kích thước ngăn xếp, và việc tăng giới hạn này dường như gây ra lỗi khác mà chúng tôi không có thời gian xác định. Mặc dù một số phương pháp này không đạt được kết quả như mong đợi, chúng tôi đã có thể đóng góp cho các dự án mã nguồn mở và hy vọng rằng vào một lúc nào đó những đóng góp này sẽ được hợp nhất vào phiên bản chính.
Chuỗi thách thức tiếp theo liên quan nhiều hơn đến lĩnh vực thiết kế. Một phần quan trọng của hệ thống là khả năng có đầu vào riêng tư. Những đầu vào này cần đến từ đâu đó, và do giới hạn thời gian, chúng tôi không thể thêm một hệ thống mã hóa MPC hoành tráng nào để cho phép đầu vào riêng tư tạo thành vòng kín trong hệ thống. Do đó, để đáp ứng nhu cầu này và giải tỏa tắc nghẽn cho nhà phát triển, chúng tôi đã thêm khái niệm máy chủ đầu vào riêng tư, cần xác minh người yêu cầu đã xác thực người yêu cầu hiện tại thông qua chữ ký tải trọng, và phục vụ họ. Khi mở rộng Bonsol, chúng tôi dự định triển khai một hệ thống giải mã ngưỡng MPC, qua đó các nút trung gian có thể cho phép người yêu cầu giải mã đầu vào riêng tư. Mọi thảo luận về đầu vào riêng tư khiến chúng tôi nghĩ đến sự phát triển thiết kế mà chúng tôi dự định cung cấp trong kho Bonsol — đó là Bonsolace, một hệ thống đơn giản hơn, cho phép bạn, với tư cách là nhà phát triển, dễ dàng chứng minh các chương trình zk này trên hạ tầng của riêng mình. Bạn có thể tự chứng minh, sau đó xác minh trên cùng hợp đồng với mạng chứng minh. Trường hợp sử dụng này phù hợp với các trường hợp dữ liệu riêng tư có giá trị rất cao, nơi việc truy cập dữ liệu riêng tư phải được giảm thiểu tối đa.
Cuối cùng, một điểm khác về Bonsol mà chúng tôi chưa thấy được sử dụng ở nơi nào khác với Risc0 là chúng tôi buộc phải cam kết (băm) dữ liệu đầu vào khi nó vào chương trình zk. Chúng tôi thực sự kiểm tra trên hợp đồng rằng đầu vào mà người chứng minh cam kết phải khớp với đầu vào mà người dùng mong đợi và gửi vào hệ thống. Điều này gây ra một chút chi phí, nhưng nếu không có nó, có nghĩa là người chứng minh có thể gian lận và chạy chương trình zk trên đầu vào mà người dùng không chỉ định. Phần còn lại của công việc phát triển Bonsol rơi vào phát triển Solana thông thường, nhưng cần lưu ý rằng chúng tôi cố ý thử một số ý tưởng mới ở đó. Trong hợp đồng thông minh, chúng tôi sử dụng flatbuffers làm hệ thống serial hóa duy nhất. Đây là một công nghệ khá mới mẻ, và chúng tôi hy vọng sẽ phát triển và xây dựng nó thành một framework, vì nó rất phù hợp để tạo SDK đa nền tảng. Điểm cuối cùng về Bonsol là hiện tại nó cần biên dịch trước để hoạt động hiệu quả nhất, kế hoạch biên dịch trước này sẽ được thực hiện trong Solana 1.18, nhưng trước đó, chúng tôi đang nỗ lực xem liệu nhóm có quan tâm đến nghiên cứu này hay không, và khám phá các công nghệ khác ngoài Bonsol.
Tổng kết
Ngoài Bonsol, đội ngũ xây dựng Anagram còn đi sâu vào nhiều lĩnh vực của VC. Các dự án như Jolt, zkllvm, spartan 2, Binius là những dự án chúng tôi đang theo dõi, cũng như các công ty đang làm việc trong lĩnh vực mã hóa đồng hình đầy đủ (FHE).
Hãy xem kho phần mềm Bonsol, và đặt câu hỏi về ví dụ bạn cần hoặc cách bạn muốn mở rộng nó. Đây là một dự án rất sớm, bạn có cơ hội để thể hiện bản thân.
Nếu bạn đang thực hiện một dự án VC thú vị, hãy đăng ký chương trình Anagram EIR.
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
@anagramxyz
