Anagram Build dành phần lớn thời gian của chúng tôi để nghiên cứu các nguyên tắc tiên tiến về tiền điện tử và áp dụng những nguyên tắc này vào các sản phẩm cụ thể. Một trong những dự án nghiên cứu gần đây của chúng tôi đã đưa chúng tôi vào lĩnh vực Verifiable Compute (VC); nhóm của 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 gọi là BonsolChúng tôi đã chọn lĩnh vực nghiên cứu này với sự xuất hiện của các trường hợp sử dụng hiệu quả mà VC cho phép và những nỗ lực đồng lòng trên nhiều L1 khác nhau để tối ưu hóa hiệu quả chi phí và khả năng mở rộng của VC.

Trong blog này, chúng tôi có hai mục tiêu.

• Đầu tiên, chúng tôi muốn đảm bảo rằng bạn hiểu rõ hơn về VC như một khái niệm và các sản phẩm có thể được kích hoạt trong hệ sinh thái Solana.
• Thứ hai, chúng tôi muốn giới thiệu với bạn sản phẩm mới nhất của chúng tôi, Bonsol.

Verifiable Compute là gì, nhỉ?

Thuật ngữ 'Verifiable Compute' có thể không xuất hiện trong các bộ bài đầu tư của các công ty khởi nghiệp trong thị trường tăng trưởng, nhưng thuật ngữ 'Zero Knowledge' lại thường xuất hiện. Vậy, hai thuật ngữ này có ý nghĩa gì?

Verifiable Compute (VC) đang chạy một khối lượng công việc cụ thể một cách sao cho nó tạo ra một bằng chứng về hoạt động của mình mà có thể được kiểm tra công khai mà không cần chạy lại quá trình tính toán. Zero Knowledge (ZK) là khả năng chứng minh một tuyên bố về dữ liệu hoặc một quá trình tính toán mà không tiết lộ tất cả dữ liệu hoặc các đầu vào cho quá trình tính toán. Các thuật ngữ này đôi khi bị lẫn lộn trong thế giới thực, ZK có phần là một từ gọi không chính xác. Nó liên quan nhiều đến việc chọn thông tin cần được công khai để chứng minh một tuyên bố về nó. VC là thuật ngữ chính xác hơn và là mục tiêu tổng thể trong nhiều kiến trúc hệ thống phân phối hiện tại.

Làm thế nào VC giúp chúng tôi xây dựng sản phẩm tiền điện tử tốt hơn?

Vì vậy, tại sao chúng ta muốn thêm các hệ thống VC hoặc ZK, trên các nền tảng như Solana và Ethereum? Có vẻ như câu trả lời là nhiều hơn về bảo mật cho nhà phát triển. Nhà phát triển hệ thống đóng vai trò trung gian hòa giải giữa niềm tin của người dùng cuối vào hộp đen và các chức năng kỹ thuật làm cho niềm tin đó có giá trị khách quan. Bằng cách sử dụng các kỹ thuật ZK / VC, nhà phát triển có thể giảm diện tích bề mặt để tấn công trong các sản phẩm họ đang xây dựng. Các hệ thống VC chuyển vị trí tin cậy sang hệ thống chứng minh và khối lượng công việc tính toán được chứng minh. Đây là một sự đảo ngược niềm tin tương tự xảy ra khi chuyển từ cách tiếp cận máy khách / máy chủ web2 điển hình sang cách tiếp cận blockchain web3. Sự tin tưởng chuyển từ dựa vào lời hứa của công ty sang tin tưởng vào mã nguồn mở và các hệ thống mật mã của mạng. Không có hệ thống zero-trust thực sự từ quan điểm của người dùng và tôi cho rằng đối với người dùng cuối, tất cả dường như giống như một hộp đen.

Ví dụ, bằng cách sử dụng hệ thống đăng nhập ZK, một nhà phát triển sẽ có ít trách nhiệm hơn trong việc duy trì cơ sở dữ liệu an toàn và cơ sở hạ tầng hơn là chỉ một hệ thống xác minh một số thuộc tính mật mã đã được đạt được. Các kỹ thuật VC đang được áp dụng ở nhiều nơi nơi mà sự đồng thuận cần thiết để đảm bảo rằng điều duy nhất cần thiết để tạo ra sự đồng thuận là toán học là hợp lệ.

Mặc dù có nhiều ví dụ hứa hẹn về việc sử dụng VC và ZK trong thực tế, nhiều trong số đó hiện đang phụ thuộc vào việc phát triển đang diễn ra ở mọi cấp độ của ngăn xếp phần mềm tiền điện tử để làm cho nó nhanh và hiệu quả đủ để sử dụng trong sản xuất.

Là một phần của công việc của chúng tôi tại Anagram, chúng tôi có cơ hội nói chuyện với nhiều nhà sáng lập / nhà phát triển tiền điện tử để hiểu rõ tình trạng hiện tại của ngăn xếp phần mềm tiền điện tử đang làm chậm sự đổi mới sản phẩm. Lịch sử, các cuộc trò chuyện của chúng tôi đã giúp chúng tôi xác định một xu hướng thú vị. Cụ thể, một nhóm dự án đang chuyển logic sản phẩm trên chuỗi khỏi chuỗi vì nó trở nên quá đắt đỏ, hoặc họ cần thêm logic kinh doanh kỳ lạ hơn. Vì vậy cuối cùng, những nhà phát triển này tìm cách tìm hệ thống và công cụ để cân bằng phần trên và ngoài chuỗi của các sản phẩm họ đang phát triển mà ngày càng mạnh mẽ hơn. Đây là nơi mà VC trở thành một phần quan trọng của con đường phía trước trong việc giúp kết nối thế giới trên và ngoài chuỗi bằng cách sử dụng phương pháp không tin cậy và có thể xác minh được.

Let’s go! Vậy hệ thống VC/ZK hoạt động như thế nào ngày nay?

Các chức năng VC và ZK hiện đang chủ yếu được thực hiện trên các lớp tính toán thay thế (còn được gọi là rollups, sidechains, relays, oracles, hoặc coprocessors) có sẵn thông qua một cuộc gọi lại đến thời gian chạy hợp đồng thông minh. Để cho phép quy trình làm việc này, nhiều chuỗi L1 đang tiến hành nỗ lực để cung cấp phím tắt bên ngoài thời gian chạy hợp đồng thông minh (ví dụ, syscall hoặc precompiles) để cho phép họ thực hiện những việc mà nếu không sẽ quá tốn kém trên chuỗi.

Hiện có một vài chế độ thông dụng của các hệ thống VC hiện tại. Tôi sẽ đề cập đến bốn chế độ hàng đầu mà tôi biết đến. Trong tất cả trường hợp ngoại trừ trường hợp cuối cùng, các bằng chứng ZK diễn ra ngoài chuỗi, nhưng nơi và khi nào các bằng chứng được xác minh mới tạo nên điểm nổi bật của mỗi chế độ này.

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 các bằng chứng nhỏ, chẳng hạn như Groth16 hoặc một số giống Plonk, bằng chứng sau đó được gửi trên chuỗi và được xác minh trên chuỗi bằng cách sử dụng mã đã triển khai trước đó. Các hệ thống như vậy hiện rất phổ biến và cách tốt nhất để thử điều này là sử dụng Circom và trình xác minh Groth16 trên Solana hoặc EVM. Hạn chế là các hệ thống chứng minh này khá chậm. Họ cũng thường yêu cầu học một ngôn ngữ mới. Để xác minh hàm băm 256 bit trong Circom, bạn thực sự cần phải xử lý thủ công từng bit trong số 256 bit đó. Có rất nhiều thư viện cho phép bạn chỉ gọi các hàm băm, nhưng đằng sau hậu trường, bạn cần triển khai lại các hàm này trong mã Circom của mình. Các hệ thống này rất tuyệt vời khi phần tử ZK và VC trong trường hợp sử dụng của bạn nhỏ hơn và bạn cần bằng chứng hợp lệ trước khi một số hành động xác định khác được thực hiện. Bonsol hiện thuộc loại đầu tiên này.

Xác minh ngoại chuỗi

Bằng chứng được gửi đến chuỗi để tất cả các bên có thể thấy rằng nó ở đó và sau đó có thể sử dụng tính toán ngoài chuỗi để xác minh. Trong chế độ này, bạn có thể hỗ trợ bất kỳ hệ thống chứng minh nào, nhưng vì bằng chứng không xảy ra trên chuỗi, bạn không nhận được cùng một quyết định cho bất kỳ hành động nào phụ thuộc vào việc gửi bằng chứng. Điều này tốt cho các hệ thống có một số loại 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à không chính xác.

Mạng Xác minh

Bằng chứng được gửi đến mạng xác minh, và mạng xác minh đó hoạt động như một người tiên tri để gọi hợp đồng thông minh. Bạn có được tính xác định, nhưng bạn cũng cần phải tin tưởng vào mạng xác minh.

Xác minh trên chuỗi đồng bộ

Chế độ thứ tư và cuối cùng khá khác biệt; trong trường hợp này, việc chứng minh và xác minh xảy ra cùng một lúc và hoàn toàn trên chuỗi. Đây là nơi L1 hoặc một hợp đồng thông minh trên L1 thực sự có thể chạy một lược đồ ZK trên thông tin nhập của người dùng, cho phép thực hiện được chứng minh trên dữ liệu riêng. Không có nhiều ví dụ phổ biến về điều này trong tự nhiên, và thường thì những loại thứ bạn có thể thực hiện với điều này bị hạn chế ở các phép toán toán học cơ bản hơn.

Tóm tắt

Các chế độ này đang được thử nghiệm trên các hệ sinh thái chuỗi khác nhau, và chúng ta sẽ xem xem mô hình mới nổi lên và mô hình nào trở nên chiếm ưu thế. Ví dụ, trên Solana, không có một người chiến thắng rõ ràng, và cảnh quan VC và ZK rất sớm. Phương pháp phổ biến nhất trên nhiều chuỗi, bao gồm Solana, là chế độ đầ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ó đi kèm với một số hạn chế. Chủ yếu là độ trễ và nó giới hạn những gì mạch của bạn có thể làm. Khi chúng ta đào sâu vào Bonsol, bạn sẽ thấy nó tuân theo chế độ đầu tiên với một chút xoắn.

Giới thiệu Bonsol!

NhậpBonsol, một hệ thống VC native mới của Solana mà chúng tôi tại Anagram xây dựng và mã nguồn mở. Bonsol cho phép một nhà phát triển tạo một chương trình thực thi có thể xác minh trên dữ liệu riêng tư và công cộng và tích hợp kết quả vào hợp đồng thông minh của Solana. Lưu ý rằng dự án này phụ thuộc vào bộ công cụ RISC0 phổ biến.

Dự án này được lấy cảm hứng từ một câu hỏi của nhiều dự án chúng tôi làm việc hàng tuần: "Làm thế nào tôi có thể làm điều này với dữ liệu cá nhân và chứng minh nó trên chuỗi?" Mặc dù "điều" khác nhau trong từng trường hợp, nhưng mong muốn cơ bản là như nhau: giảm thiểu sự phụ thuộc tập trung của chúng.

Trước khi chúng ta đào sâu vào chi tiết hệ thống, hãy bắt đầu bằng cách minh họa sức mạnh của Bonsol thông qua hai trường hợp sử dụng riêng biệt.

Kịch bản một

Một ứng dụng phi tập trung cho phép người dùng mua vé rút thăm vào các hồ bơi của các loại mã thông báo khác nhau. Các hồ bơi được “rót” mỗi ngày từ một hồ bơi toàn cầu một cách sao cho số tiền trong hồ bơi (số tiền của mỗi loại mã thông báo) được ẩn. Người dùng có thể mua quyền truy cập vào các phạm vi cụ thể của các mã thông báo trong hồ bơi ngày càng chi tiết hơn. Nhưng có một vấn đề: sau khi một người dùng mua phạm vi, nó trở thành công khai đối với tất cả người dùng cùng một lúc. Người dùng sau đó phải quyết định mua vé. Họ có thể quyết định rằng việc mua không đáng giá, hoặc họ có thể đảm bảo một cổ phần trong hồ bơi bằng cách mua vé.

Bonsol xuất hiện khi pool được tạo ra và khi người dùng thanh toán để biết phạm vi. Khi pool được tạo ra/chia, chương trình ZK nhận vào các đầu vào riêng tư của số lượng mỗi mã token để chia. Các loại token là các đầu vào đã biết, và địa chỉ pool là một đầu vào đã biết. Bằng chứng này là bằng chứng của việc chọn ngẫu nhiên từ pool toàn cầu vào pool hiện tại. Bằng chứng này chứa một cam kết đến các số dư. Hợp đồng trên chuỗi sẽ nhận bằng chứng này, xác minh nó, và giữ các cam kết để khi pool cuối cùng đóng cửa và số dư được gửi từ pool toàn cầu đến chủ sở hữu vé rifa, họ có thể xác minh rằng số lượng token không thay đổi kể từ lúc chọn ngẫu nhiên ở đầu pool.

Khi người dùng mua một “mở” của các phạm vi số dư token ẩn, chương trình ZK lấy các số dư token thực tế như là đầu vào riêng tư và tạo ra một loạt các giá trị được cam kết cùng với bằng chứng. Một đầu vào công khai của chương trình ZK này là bằng chứng tạo pool đã cam kết trước đó và các đầu ra của nó. Điều này giúp 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 hash thành cùng một giá trị đã cam kết trong bằng chứng đầu tiên. Bằng chứng phạm vi cũng được cam kết vào chuỗi và, như đã nói trước đó, khiến phạm vi trở nên rõ ràng đối với tất cả các bên tham gia.

Mặc dù có nhiều cách để thực hiện hệ thống vé rifa này, các đặc điểm của Bonsol làm cho việc không tin tưởng nhiều vào tổ chức tổ chức rifa. Nó cũng nhấn mạnh sự tương tác giữa Solana và hệ thống VC. Chương trình Solana (hợp đồng thông minh) đóng một vai trò quan trọng trong việc trung gian niềm tin đó vì nó xác minh các bằng chứng và sau đó cho phép chương trình thực hiện hành động tiếp theo.

Kịch bản hai

Bonsol cho phép các nhà phát triển tạo ra một nguyên thủy được sử dụng bởi các hệ thống khác. Bonsol chứa 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 nó cho các nhà khai thác Bonsol. Các nhà khai thác mạng Bonsol hiện có một số cách cơ bản để đánh giá xem yêu cầu thực thi cho một trong các chương trình ZK có lợi về mặt kinh tế hay không. Họ có thể xem một số thông tin cơ bản về mức độ tính toán của chương trình ZK, kích thước đầu vào và mẹo mà người yêu cầu đang cung cấp. Một nhà phát triển có thể triển khai một nguyên thủy mà họ nghĩ rằng nhiều Dapps khác sẽ muốn sử dụng.

Trong cấu hình cho một 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 mà đã được cấu hình trước một số hoặc tất cả các đầu vào. Điều này có nghĩa là họ có thể cấu hình một số đầu vào sao cho họ có thể tạo ra các nguyên tố có thể 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ụ, hãy nói rằng một nhà phát triển tạo ra một hệ thống mà, với một NFT nhất định, có thể chứng minh trên chuỗi việc chuyển quyền sở hữu bao gồm một tập hợp cụ thể các ví. Nhà phát triển có thể có một tập hợp đầu vào được cấu hình trước chứa một loạt thông tin giao dịch lịch sử. Chương trình ZK tìm kiếm qua tập hợp đó để tìm ra các chủ sở hữu phù hợp. Đây là một ví dụ cố ý và có thể thực hiện theo nhiều cách khác nhau.

Xem xét một ví dụ khác: một nhà phát triển có thể viết một chương trình ZK có thể xác minh rằng chữ ký keypair đến từ một keypair hoặc tập hợp keypair phân cấp mà không tiết lộ các khóa công khai của những keypair quyền lực đó. Hãy nói rằng điều này hữu ích cho nhiều ứng dụng phân phối khác nhau, và họ sử dụng chương trình ZK này. Giao thức cung cấp cho tác giả của chương trình ZK này một số gợi ý sử dụng nhỏ. Bởi vì hiệu suất quan trọng, nhà phát triển được khuyến khích tạo ra các chương trình của họ nhanh chóng để các nhà vận hành muốn chạy chúng, và nhà phát triển muốn sao chép công việc của một nhà phát triển khác sẽ cần phải thay đổi chương trình một cách nào đó để triển khai nó vì có một sự xác thực của nội dung của chương trình ZK. Bất kỳ hoạt động nào được thêm vào chương trình ZK sẽ ảnh hưởng đến hiệu suất, và mặc dù nó chắc chắn không phải là hoàn hảo, điều này có thể giúp đảm bảo rằng nhà phát triển được đền bù cho sự đổi mới.

Kiến trúc Bonsol

Những trường hợp sử dụng này giúp mô tả điều Bonsol hữu ích, nhưng hãy xem xét kiến trúc hiện tại, mô hình động viên hiện tại và luồng thực thi của nó.

Hình ảnh trên mô tả một luồng từ người dùng cần thực hiện một loại tính toán có thể xác minh nào đó, thường sẽ thông qua một ứng dụng phi tập trung cần điều này để cho phép người dùng thực hiện một số hành động. Điều này sẽ có dạng Yêu cầu Thực thi chứa thông tin về ZKprogram đang được thực thi, các đầu vào hoặc tập hợp đầu vào, thời gian cần chứng minh tính toán và tiền boa (đó là cách mà các Relay được trả). Yêu cầu được nhận bởi Relay và họ phải cạnh tranh để quyết định họ có muốn yêu cầu này và bắt đầu chứng minh hay không. Dựa trên khả năng cụ thể của các nhà vận hành relay, họ có thể chọn bỏ qua điều này vì boa không đủ hoặc zkprogram hoặc đầu vào quá lớn. Nếu họ quyết định họ muốn thực hiện phép tính này, họ phải thực hiện yêu cầu trên nó. Nếu họ là người đầu tiên nhận được yêu cầu, thì 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 thể sản xuất chứng cứ đúng giờ, các nút khác có thể yêu cầu thực thi. Để yêu cầu Relay phải đặt ra một số cược hiện tại được cài đặt cứng cố định thành boa / 2 sẽ bị cắt giảm nếu họ không thể sản xuất chứng cứ chính xác.

Bonsol được xây dựng dựa trên giả thuyết rằng việc tính toán sẽ di chuyển đến một lớp nơi nó được chứng minh và xác minh trên chuỗi, và rằng Solana sẽ là một chuỗi 'điểm đến' cho các nhà đầu tư và ZK sớm. Giao dịch nhanh của Solana, tính toán rẻ và người dùng ngày càng tăng làm cho đó trở thành một nơi tuyệt vời để thử nghiệm những ý tưởng này.

Có dễ xây dựng không? Chắc chắn không!

Điều đó không có nghĩa là không có thách thức trong việc xây dựng Bonsol. Để lấy bằng chứng Risco0 và xác minh nó trên Solana, chúng tôi cần làm cho nó nhỏ hơn. Nhưng chúng ta không thể chỉ làm điều đó mà không đánh đổi các thuộc tính an ninh của bằng chứng. Vì vậy, chúng tôi sử dụng Circom và bọc Risc0 Stark có thể có dung lượng ~200kb và bọc nó trong bằng chứng Groth16 cuối cùng luôn là 256 byte. May mắn thay, Risc0 đã cung cấp một số công cụ mới mẻ cho điều này, nhưng nó đã thêm rất nhiều chi phí và phụ thuộc vào hệ thống.

Khi chúng tôi bắt đầu xây dựng Bonsol và sử dụng công cụ hiện có để bọc Stark với Snark, chúng tôi đã tìm cách giảm sự phụ thuộc và tăng tốc độ. Circom cho phép biên dịch mã Circom thành C ++ hoặc wasm. Đầu tiên chúng tôi đã cố gắng biên dịch mạch Circom thành một tệp wasmu do LLVM tạo ra. Đây là cách nhanh nhất và hiệu quả nhất để làm cho dụng cụ Groth16 di động và vẫn nhanh. Chúng tôi đã chọn wasm do tính di động của nó vì mã C ++ phụ thuộc vào kiến trúc cpu x86, có nghĩa là Macbook mới hoặc máy chủ dựa trên Arm sẽ không thể sử dụng tính năng này. Nhưng điều này đã trở thành một ngõ cụt đối với chúng tôi trên dòng thời gian mà chúng tôi phải làm việc. Bởi vì hầu hết các thử nghiệm nghiên cứu sản phẩm của chúng tôi được đóng hộp thời gian cho đến khi chúng chứng minh giá trị của chúng, chúng tôi đã có 2-4 tuần thời gian phát triển để kiểm tra ý tưởng này. Trình biên dịch ong bắp cày llvm không thể xử lý mã wasm được tạo. Với nhiều công việc hơn, chúng tôi có thể đã vượt qua điều này, nhưng chúng tôi đã thử nhiều cờ tối ưu hóa và cách để trình biên dịch llvm hoạt động như một plugin wasmer để biên dịch trước mã này thành llvm, nhưng chúng tôi đã không thành công. Bởi vì mạch Circom có khoảng 1,5 triệu dòng mã, bạn có thể tưởng tượng rằng số lượng Wasm trở nên khổng lồ. Sau đó, chúng tôi chuyển hướng sang cố gắng tạo cầu nối giữa C ++ và cơ sở mã chuyển tiếp Rust của chúng tôi. Điều này cũng gặp phải một thất bại nhanh chóng vì C ++ chứa một số mã lắp ráp cụ thể x86 mà chúng tôi không muốn loay hoay. Để đưa hệ thống ra công chúng, chúng tôi chỉ đơn giản là khởi động hệ thống theo cách sử dụng mã C ++ nhưng loại bỏ một số phụ thuộc. Trong tương lai, chúng tôi muốn mở rộng trên một dòng tối ưu hóa khác mà chúng tôi đang làm việc. Đó là lấy mã C ++ và thực sự biên dịch nó thành một biểu đồ thực thi. Những tạo tác C ++ này từ bộ sưu tập Circom chủ yếu chỉ là số học mô-đun trên một trường hữu hạnvới một số nguyên tố nguyên tố rất lớn như bộ phát sinh. Điều này đã cho thấy một số kết quả hứa hẹn đối với các tác phẩm C++ nhỏ hơn và đơn giản hơn, nhưng cần thêm nhiều công việc để làm cho nó hoạt động với hệ thống Risc0. Điều này là vì mã C++ được tạo ra có khoảng 7 triệu dòng mã, và trình tạo đồ thị dường như đạt đến giới hạn kích thước ngăn xếp, và việc tăng chúng dường như tạo ra các lỗi khác mà chúng tôi chưa có thời gian xác định. Mặc dù một số con đường này không thành công, chúng tôi đã đóng góp vào các dự án OSS và hy vọng rằng vào một thời điểm nào đó những đóng góp đó sẽ được upstreamed.

Nhóm thách thức tiếp theo là nhiều hơn trong không gian thiết kế. Một phần thiết yếu của hệ thống này là có thể có đầu vào riêng. Những đầu vào đó cần phải đến từ đâu đó và do hạn chế về thời gian, chúng tôi không thể thêm vào một số hệ thống mã hóa MPC ưa thích để cho phép các đầu vào riêng tư nằm trong hệ thống trong một vòng khép kín. Vì vậy, để giải quyết nhu cầu này và bỏ chặn các nhà phát triển, chúng tôi đã thêm khái niệm về một máy chủ đầu vào riêng cần xác thực người yêu cầu đó, được xác thực bằng chữ ký của tải trọng là người yêu cầu bằng chứng hiện tại và phục vụ nó cho họ. Khi chúng tôi mở rộng Bonsol, chúng tôi dự định triển khai hệ thống giải mã ngưỡng MPC theo đó các nút Chuyển tiếp có thể cho phép người yêu cầu giải mã các đầu vào riêng. Tất cả các cuộc thảo luận này về đầu vào tư nhân đưa chúng ta đến một sự phát triển thiết kế mà chúng tôi dự định cung cấp trong repo 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 cơ sở hạ tầng của riêng bạn. Thay vì bao thanh toán cho mạng prover, bạn chỉ có thể tự chứng minh nó và xác minh nó trên cùng một hợp đồng mà mạng prover sử dụng. Trường hợp sử dụng này dành cho các trường hợp sử dụng dữ liệu riêng tư có giá trị rất cao, trong đó quyền truy cập vào dữ liệu riêng tư phải được giảm thiểu bằng mọi giá.

Một điểm cuối cùng về Bonsol mà chúng ta chưa thấy ở những nơi khác sử dụng Risc0 là chúng ta buộc phải cam kết (băm) trên dữ liệu đầu vào vào chương trình zk. Và chúng ta thực sự kiểm tra trên hợp đồng rằng những đầu vào mà bên chứng minh phải cam kết phải khớp với những gì người dùng mong đợi và gửi vào hệ thống. Điều này đến với một số chi phí, nhưng nếu không có nó có nghĩa là bên chứng minh có thể gian lận và chạy chương trình zk trên những đầu vào mà người dùng không chỉ định. Phần còn lại của việc phát triển Bonsol rơi vào phát triển Solana bình thường nhưng cần lưu ý rằng chúng tôi cố ý thử nghiệm một số ý tưởng mới ở đó. Trên hợp đồng thông minh, chúng tôi đang sử dụng flatbuffers như là hệ thống tuần tự duy nhất. Đây là một kỹ thuật hơi mới mẻ mà chúng tôi muốn thấy phát triển và trở thành một framework vì nó phù hợp để tự động tạo ra các sdk là đa nền tảng. Một điểm cuối cùng về Bonsol là hiện tại nó cần một trình biên soạn trước để hoạt động hiệu quả nhất, trình biên soạn này được dự kiến sẽ xuất hiện trong Solana 1.18, nhưng cho đến khi đó chúng tôi đang làm việc để xem liệu các nhóm có quan tâm đến nghiên cứu này và nhìn xa hơn Bonsol vào các công nghệ khác.

Kết thúc

Bên cạnh Bonsol, nhóm xây dựng Anagram đang tìm hiểu sâu vào nhiều nơi trong lĩnh vực 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 với các công ty đang làm việc trong không gian Mã hóa Homomorphically Đầy Đủ (FHE), nếu bạn không biết đó là gì, hãy theo dõi vì chúng tôi sẽ bàn luận về điều đó vào một thời điểm nào đó.

Vui lòng kiểm tra kho lưu trữ Bonsol và tạo một vấn đề cho các 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 và bạn có cơ hội để để lại dấu ấn của mình.

Nếu bạn đang làm việc trên các dự án VC thú vị, chúng tôi khuyến khích bạnđăng ký tại đây cho chương trình EIR của Anagramnơi bạn có thể thử nghiệm luận văn của mình, xây dựng một công ty và đối mặt với những vấn đề lớn nhất cùng đội ngũ Anagram. Hãy thoải mái đóng góp hoặc đặt bất kỳ câu hỏi nào.

免责声明：

1. Bài viết này được in lại từ [SolanaAnagram], Tất cả bản quyền thuộc về tác giả gốc [austbot]. Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ Gate Họcđội, và họ sẽ xử lý nhanh chóng.

2. Miễn trách nhiệm về trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.

3. Các bản dịch của bài viết ra các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.