Được viết bởi: Austbot
Biên soạn bởi: TechFlow 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 crypto mới và triển khai chúng vào các sản phẩm cụ thể. Một trong những dự án nghiên cứu gần đây nhất của chúng tôi liên quan đến lĩnh vực Máy tính có thể xác minh (VC). Đội ngũ của chúng tôi đã sử 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ì điện toán có thể kiểm chứng mang lại nhiều trường hợp sử dụng hợp lệ và các L1 khác nhau đang làm việc cùng nhau để tối ưu hóa hiệu quả chi phí và mở rộng của điện toán có thể kiểm chứng.
Trong bài viết này chúng tôi có hai mục tiêu
Trước 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 mà nó có thể hỗ trợ trong hệ sinh thái Solana .
Thứ hai, chúng tôi muốn giới thiệu với bạn tác phẩm mới nhất của chúng tôi: Bonsol
Tính toán có thể kiểm chứng là gì?
Thuật ngữ "tính toán có thể kiểm chứng" có thể không xuất hiện trong sách hướng dẫn đầu tư của một công ty khởi nghiệp thị trường bò , nhưng thuật ngữ "không có kiến thức" thì sẽ xuất hiện. Vì vậy, những thuật ngữ này có nghĩa là gì?
Tính toán có thể xác minh ( VC ) đang chạy một khối lượng công việc cụ thể theo cách tạo ra bằng chứng về hoạt động của nó có thể được xác minh công khai mà không cần chạy lại phép tính . Không có kiến thức (ZK) đề cập đến khả năng chứng minh các tuyên bố về dữ liệu hoặc tính toán mà không tiết lộ tất cả dữ liệu hoặc đầu vào của tính toán. Trong thế giới thực, các thuật ngữ này hơi bị nhầm lẫn với nhau và ZK có phần là một cách gọi sai. Nó liên quan nhiều hơn đến việc lựa chọn thông tin cần được tiết lộ để chứng minh cho tuyên bố của mình. VC là thuật ngữ chính xác hơn và là mục tiêu chung của nhiều kiến trúc hệ thống phân tán hiện có.
VC có thể giúp chúng tôi xây dựng các sản phẩm crypto tốt hơn bằng cách 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 vấn đề bảo mật dành cho nhà phát triển. Các nhà phát triển hệ thống đóng vai trò trung gian giữa niềm tin của người dùng vào hộp đen và khả năng kỹ thuật khiến niềm tin đó trở nên khách quan và hợp lệ. Bằng cách tận dụng công nghệ ZK/VC, các nhà phát triển có thể giảm bề mặt 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 của sự tin cậy sang hệ thống chứng thực và khối lượng công việc tính toán được chứng thực. Điều này tương tự như sự đảo ngược niềm tin xảy ra khi chuyển từ phương pháp máy trạm /máy chủ web2 điển hình sang phương pháp blockchain web3. Niềm tin chuyển từ việc dựa vào lời hứa của công ty sang tin cậy vào mã mã nguồn mở và hệ thống crypto của mạng. Từ góc độ người dùng, không có hệ thống không tin cậy thực sự nào cả, tôi cho rằng tất cả đều giống như một hộp đen đối với người dùng.
Ví dụ: bằng cách sử dụng 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à cơ sở hạ tầng an toàn sẽ giảm đi do hệ thống chỉ cần xác minh rằng một số thuộc tính crypto nhất định đã được triển khai. Công nghệ VC đang được áp dụng ở nhiều nơi cần có sự đồng thuận để đảm bảo rằng điều kiện duy nhất cho sự đồng thuận cần thiết là toán học hợp lệ.
Mặc dù có nhiều câu chuyện thành công khi sử dụng VC và ZK nhưng nhiều trong đó hiện dựa vào tiến trình phát triển ở mọi cấp độ của ngăn xếp phần mềm crypto để làm cho nó đủ nhanh và hiệu quả để đưa vào sản xuất.
Là một phần công việc chúng tôi làm 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 crypto để hiểu trạng thái hiện tại của ngăn xếp phần mềm crypto tác động như thế nào đến việc đổi mới sản phẩm. Lịch sử , cuộc trò chuyện đã giúp chúng tôi xác định được một xu hướng thú vị. Cụ thể, một nhóm dự án đang tích cực chuyển logic sản phẩm ra Chuỗi Chuỗi nó trở nên quá đắt hoặc họ cần thêm logic việc kinh doanh mới lạ hơn. Vì vậy, cuối cùng, những nhà phát triển này thấy mình đang cố gắng tìm kiếm các hệ thống và công cụ cân bằng giữa các phần trên Chuỗi và ngoài Chuỗi của sản phẩm mà họ đang phát triển, những phần này ngày càng trở nên mạnh mẽ. Đây là nơi VC trở thành một phần quan trọng trong việc giúp kết nối thế giới trên Chuỗi và ngoài Chuỗi bằng phương pháp không đáng tin cậy và có thể kiểm chứng được.
Hệ thống VC/ZK hiện tại hoạt động như thế nào?
Ngày nay, các hàm VC và ZK chủ yếu được thực thi trên các lớp điện toán thay thế (chẳng hạn như cuộn lên, sidechain, rơle, oracle hoặc bộ đồng xử lý) và có sẵn thông qua điều chỉnh hồi thời gian chạy hợp đồng thông minh. Để kích hoạt quy trình làm việc này, nhiều Chuỗi L1 đang nỗ lực cung cấp các phím tắt bên ngoài thời gian chạy hợp đồng thông minh (chẳng hạn như lệnh gọi hệ thống hoặc biên dịch trước) để thực hiện một số thao tác vốn có thể quá tốn kém trên Chuỗi.
Có một số mô hình phổ biến của các hệ thống VC hiện tại. Tôi sẽ đề cập đến bốn điều đầu tiên mà tôi biết. Ngoại trừ trường hợp cuối cùng, bằng chứng ZK được thực hiện ngoài Chuỗi, nhưng chính thời điểm và địa điểm bằng chứng được xác minh sẽ mang lại cho các chế độ này những lợi thế tương ứng.
Đã được xác minh đầy đủ trên Chuỗi
Đối với các hệ thống chứng minh VC và ZK có khả năng tạo ra các bằng chứng nhỏ, chẳng hạn như Groth16 hoặc một số biến thể Plonk, bằng chứng sau đó sẽ được gửi tới 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ư thế này hiện nay rất phổ biến và cách tốt nhất để thử phương pháp là sử dụng Circom và Solana hoặc trình xác thực Groth16 trên EVM. Nhược điểm 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. Việc xác minh hàm băm 256 bit trong Circom thực sự yêu cầu xử lý thủ công từng 256 bit. Mặc dù có nhiều thư viện cho phép bạn gọi các hàm băm một cách đơn giản nhưng bạn cần triển khai lại các hàm này trong mã Circom. Các hệ thống này rất tuyệt vời khi các phần tử ZK và VC trong trường hợp sử dụng của bạn nhỏ hơn và khi bạn cần chứng minh điều gì đó hoạt động trước khi thực hiện một số hành động xác định khác. 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 trên Chuỗi để tất cả các bên có thể xem và sau đó có thể được xác minh bằng cách sử dụng tính toán Chuỗi. Trong chế độ này, bạn có thể hỗ trợ bất kỳ hệ thống bằng chứng nào, nhưng vì bằng chứng không được thực hiện trên Chuỗi nên bạn không thể có được kết quả cuối cùng tương tự cho bất kỳ hoạt động nào dựa trên việc gửi bằng chứng. Điều này sẽ tốt cho một hệ thống có một loại cửa sổ thách thức nào đó, trong đó các bên có thể "phủ quyết" và cố gắng chứng minh rằng bằng chứng là không chính xác.
Xác minh mạng
Bằng chứng được gửi đến mạng xác minh và mạng xác minh hoạt động như oracle gọi hợp đồng thông minh. Bạn có được sự chắc chắn, nhưng bạn cũng cần phải tin tưởng vào mạng xác minh.
Xác minh đồng bộ trên Chuỗi
Chế độ thứ tư và cuối cùng khá khác nhau; trong trường hợp này, bằng chứng và xác minh được thực hiện trên Chuỗi cùng một lúc. Đây là nơi L1 hoặc hợp đồng thông minh trên L1 thực sự có thể chạy các sơ đồ ZK trên đầ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 sở hữu tư nhân . Không có nhiều ví dụ mở rộng và nói chung những gì bạn có thể làm với phương pháp này chỉ giới hạn ở các phép toán cơ bản hơn.
Tóm tắt
Tất cả bốn mô hình này đang được thử nghiệm trong các hệ sinh thái Chuỗi khác nhau và chúng ta sẽ xem liệu những mô hình mới có xuất hiện hay không và mô hình nào sẽ vị trí chủ đạo. Ví dụ: trên Solana , không có người chiến thắng rõ ràng và bối cảnh VC và ZK vẫn đang ở giai đoạn đầu. Trên nhiều Chuỗi, bao gồm cả Solana , phương pháp phổ biến nhất 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ó cũng có 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 tìm hiểu về Bonsol, bạn sẽ thấy nó tuân theo mẫu đầu tiên nhưng có một vài điểm thay đổi.
Giới thiệu Bonsol
Bonsol, đây là hệ thống VC gốc Solana mới được chúng tôi xây dựng và mã nguồn mở tại Anagram. Bonsol cho phép các nhà phát triển tạo ra một tệp thực thi có thể kiểm chứng được liên quan đến dữ liệu sở hữu tư nhân và công khai, đồng thời tích hợp kết quả vào hợp đồng thông minh Solana . Xin lưu ý rằng dự án này dựa trên chuỗi Chuỗi RISC0 phổ biến.
Dự án này được lấy cảm hứng từ một câu hỏi được đặt ra cho nhiều dự án mà chúng tôi nói chuyện hàng tuần: "Làm cách nào tôi có thể chứng minh điều này trên Chuỗi bằng cách sử dụng dữ liệu sở hữu tư nhân ?" Mặc dù "điều" trong mỗi trường hợp là khác nhau, nhưng mong muốn cơ bản là giống nhau: để giảm sự phụ thuộc tập trung của họ.
Trước khi đi vào chi tiết của hệ thống, hãy minh họa sức mạnh của Bonsol thông qua hai trường hợp sử dụng khác nhau.
cảnh 1
Dapp cho phép người dùng mua vé số từ nhiều nhóm token khác nhau. Các nhóm này được "nghiêng" hàng ngày so với nhóm toàn cầu sao cho số tiền trong nhóm (đối với mỗi token) bị ẩn. Người dùng có thể mua token truy cập vào phạm vi nhóm ngày càng cụ thể. Nhưng có một nhược điểm: Sau khi người dùng mua phạm vi đó, phạm vi đó sẽ có sẵn cho tất cả người dùng cùng một lúc. Sau đó, người dùng phải quyết định có nên mua vé số hay không. Họ có thể quyết định rằng nó không đáng mua hoặc họ có thể mua một vé để đảm bảo rằng họ có cổ phần trong nhóm.
Bonsol phát huy tác dụng khi nhóm được tạo và khi người dùng trả tiền cho phạm vi. Khi tạo/nghiêng nhóm, chương trình ZK sẽ nhận được đầu vào sở hữu tư nhân về số lượng của mỗi token . Loại token là đầu vào đã biết và địa chỉ nhóm là đầu vào đã biết. Bằng chứng là bằng chứng về sự lựa chọn ngẫu nhiên từ nhóm toàn cầu vào nhóm hiện tại. Bằng chứng cũng bao gồm một cam kết về số dư. Một hợp đồng trên Chuỗi sẽ nhận được bằng chứng này, xác thực nó và lưu các cam kết này để khi nhóm cuối cùng đóng cửa và số dư được gửi từ nhóm toàn cầu đến chủ sở hữu xổ số, họ có thể xác minh token kể từ lựa chọn ngẫu nhiên tại đầu nhóm Số lượng có thay đổi không?
Khi người dùng mua "mở" với phạm vi số dư token ẩn, chương trình ZK sẽ lấy số dư token thực tế làm đầu vào sở hữu tư nhân và tạo ra sê-ri các giá trị số được cam kết cùng với bằng chứng. Đầu vào công khai cho chương trình ZK này là bằng chứng đã cam kết trước đó về việc tạo nhóm và đầu ra của nó. Bằng 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 được băm theo cùng giá trị như đã hứa trong bằng chứng đầu tiên. Bằng chứng về phạm vi cũng được gửi trên Chuỗi và như đã đề cập trước đó, làm cho phạm vi hiển thị cho tất cả người tham gia.
Mặc dù có nhiều phương pháp để triển khai hệ thống giống như vé rút thăm như vậy, nhưng các đặc tính của Bonsol khiến yêu cầu về độ tin cậy đối với tổ chức tổ chức rút thăm là rất thấp. Nó cũng nêu bật khả năng tương tác của hệ thống Solana và VC. Chương trình Solana (hợp đồng thông minh) đóng vai trò quan trọng trong việc tạo dựng niềm tin vì nó xác minh 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 2
Bonsol cho phép các nhà phát triển tạo ra các 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, các nhà phát triển có thể tạo một số chương trình ZK và triển khai chúng cho các nhà khai thác Bonsol. Các nhà khai thác mạng Bonsol hiện có một số phương tiện cơ bản để đánh giá liệu yêu cầu thực hiện chương trình ZK có mang lại lợi ích về mặt kinh tế hay không. Họ có thể xem một số thông tin cơ bản về số lượng phép tính mà chương trình ZK sẽ yêu cầu, kích thước đầu vào và mẹo do người yêu cầu cung cấp. Các nhà phát triển có thể triển khai bộ công cụ mà họ cho rằng nhiều Dapp khác sẽ muốn sử dụng.
Trong cấu hình của chương trình ZK, nhà phát triển chỉ định thứ tự và loại đầu vào được yêu cầu. Nhà phát triển có thể xuất bản một Bộ đầu vào được cấu hình sẵn với một số hoặc tất cả đầu vào. Điều này có nghĩa là họ có thể định cấu hình một phần đầu vào để giúp người dùng xác thực các phép tính trên các tập dữ liệu rất lớn.
Ví dụ: giả sử nhà phát triển tạo ra một hệ thống có thể chứng minh rằng việc chuyển quyền sở hữu trên Chuỗi liên quan đến một nhóm ví cụ thể dựa trên NFT. Nhà phát triển có thể có bộ đầu vào được cấu hình sẵn trong đó lượng lớn thông tin giao dịch lịch sử. Chương trình ZK tìm kiếm bộ sưu tập để tìm chủ sở hữu phù hợp. Đây là một ví dụ giả định có thể được thực hiện theo nhiều phương pháp.
Hãy xem xét một ví dụ khác: Nhà phát triển có thể viết chương trình ZK có thể xác minh rằng chữ ký cặp khóa đến từ cặp khóa hoặc cặp khóa phân cấp mà không tiết lộ khóa chung của các cặp khóa được ủy quyền đó. Giả sử điều này hiệu quả với nhiều Dapp khác và họ sử dụng chương trình ZK này. Thỏa thuận cung cấp một khoản phí sử dụng nhỏ cho tác giả của chương trình ZK này. Vì hiệu suất là rất quan trọng nên các nhà phát triển được khích lệ làm cho chương trình của họ chạy nhanh để người vận hành muốn chạy chúng và nhà phát triển đang cố gắng đánh cắp công việc của nhà phát triển khác sẽ cần phải thay đổi chương trình theo cách nào đó trước khi có thể triển khai, cũng như trường hợp với ZK Nội dung của chương trình được xác minh. Bất cứ điều gì được thêm vào chương trình ZK sẽ ảnh hưởng đến hiệu suất và mặc dù điều này chắc chắn không phải là không thể sai lầm nhưng nó có thể giúp đảm bảo rằng các nhà phát triển được khen thưởng vì sự đổi mới.
Kiến trúc Bonsol
Các trường hợp sử dụng này giúp mô tả mục đích của Bonsol, nhưng chúng ta hãy xem cấu trúc hiện tại, mô hình khích lệ hiện tại và quy trình thực thi của nó.
Hình ảnh trên mô tả một quy trình trong đó người dùng cần thực hiện một số loại tính toán có thể xác minh được. Điều này thường đạt được thông qua một dapp yêu cầu người dùng thực hiện một số hành động. Điều này sẽ ở dạng một yêu cầu thực thi trong đó về chương trình ZK đang được thực thi, đầu vào hoặc bộ đầu vào, thời trong đó tính toán phải được chứng minh và mẹo (đây là cách sạc rơle). Yêu cầu được tiếp nhận bởi người tiếp sức, người này phải chạy đua để quyết định xem có yêu cầu quyền sở hữu đối với việc thực thi này hay không và bắt đầu chứng thực. Tùy thuộc vào khả năng của một người vận hành rơle cụ thể, họ có thể chọn từ bỏ vì tiền boa không có giá trị hoặc chương trình hoặc đầu vào zk quá lớn. Nếu họ quyết định thực hiện phép tính này, họ phải thực hiện một tuyên bố về nó. Nếu họ là người đầu tiên nhận đượ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 đưa ra bằng chứng kịp thời, nút khác có thể tuyên bố thực thi. Để yêu cầu, người chuyển tiếp phải đăng một số tài sản thế chấp, hiện được mã hóa cứng là tip/2, tài sản này sẽ bị cắt nếu họ không đưa ra được bằng chứng chính xác.
Bonsol được xây dựng dựa trên luận điểm rằng nhiều tính toán hơn sẽ được chuyển đến một lớp nơi nó được xác minh và xác minh trên Chuỗi và Solana sẽ sớm trở thành chuỗi được lựa chọn cho VC và ZK . Các giao dịch nhanh chóng, điện toán giá rẻ và cơ sở người dùng tăng trưởng của Solana khiến nơi đây trở thành một nơi tuyệt vời để thử nghiệm những ý tưởng này.
Cái này có dễ xây dựng không? dĩ nhiên là không!
Điều đó không có nghĩa là không có thách thức khi xây dựng Bonsol. Để mang bằng chứng Risco0 đến Solana và xác minh nó trên đó, chúng tôi cần làm cho nó nhỏ hơn. Nhưng chúng ta không thể đơn giản làm điều này mà không hy sinh tính bảo mật của bằng chứng. Vì vậy, chúng tôi sử dụng Circom để bọc Risc0 Stark, có thể có dung lượng khoảng 200kb, sau đó bọc 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ó bổ sung thêm rất nhiều chi phí và sự phụ thuộc vào hệ thống.
Khi chúng tôi bắt đầu xây dựng Bonsol và gói Stark và Snark bằng các công cụ hiện có, chúng tôi đã tìm phương pháp giảm sự phụ thuộc và tăng tốc độ. Circom cho phép mã Circom được biên dịch 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 tệp wasmu do LLVM tạo ra. Đây là phương pháp nhanh nhất và hiệu quả nhất để giúp bộ Groth16 của bạn có thể di động mà vẫn nhanh chóng. Chúng tôi chọn wasm vì tính di động của nó, trong khi mã C++ dựa trên kiến trúc CPU x86, điều đó có nghĩa là Macbook hoặc máy chủ dựa trên Arm mới sẽ không thể sử dụng mã này. Nhưng theo lịch trình chúng tôi phải làm việc, điều đó trở thành ngõ cụt đối với chúng tô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 đều có giới hạn thời gian cho đến khi giá trị được chứng minh nên chúng tôi có 2-4 tuần thời gian phát triển để thử nghiệm ý tưởng. Trình biên dịch wasm llvm không thể xử lý mã wasm được tạo. Nếu nỗ lực nhiều hơn, chúng tôi có thể khắc phục được điều này, nhưng chúng tôi đã thử nhiều cờ tối ưu hóa và phương pháp để làm cho trình biên dịch llvm hoạt động như một plug-in 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. Vì mạch Circom có khoảng 1,5 triệu dòng mã nên bạn có thể tưởng tượng số lượng wasm sẽ khá lớn. Sau đó, chúng tôi chuyển sự chú ý sang việc cố gắng tạo cầu nối giữa C++ và cơ sở mã trung kế Rust của chúng tôi. Điều này cũng nhanh chóng bị đánh bại vì C++ chứa một số mã hợp ngữ dành riêng cho x86 mà chúng tôi không muốn sử dụng. Để giới thiệu hệ thống này ra công chúng, cuối cùng chúng tôi chỉ cần khởi chạy một hệ thống làm cho nó sử dụng mã C++ nhưng loại bỏ một số phần phụ thuộc. Trong tương lai, chúng tôi hy vọng mở rộng một dòng tối ưu hóa khác mà chúng tôi đang nghiên cứu. Đó thực sự là biên dịch mã C++ thành biểu đồ thực thi. Các khối xây dựng C++ mà Circom biên dịch về cơ bản chỉ là số học mô-đun đun trên các trường hữu hạn với các bộ tạo số nguyên tố rất, rất lớn. Điều này cho thấy một số kết quả đầy hứa hẹn đối với các bản dựng C++ nhỏ hơn, đơn giản hơn, nhưng cần nhiều công việc hơn để làm cho nó hoạt động với hệ thống Risc0. Điều này là do mã C++ được tạo có khoảng 7 triệu dòng mã và trình tạo biểu đồ dường như đang đạt đến giới hạn kích thước ngăn xếp và việc tăng các giới hạn đó dường như tạo ra các trục trặc khác mà chúng tôi chưa có thời gian xác định. Mặc dù trong đó phương pháp không đạt được kết quả như mong đợi nhưng chúng tôi vẫn có thể đóng góp cho dự án mã nguồn mở và hy vọng rằng đến một lúc nào đó những đóng góp này sẽ được hợp nhất ngược dòng.
Sê-Ri 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 sở hữu tư nhân. Những đầu vào này cần phải đến từ một nơi nào đó và do hạn chế về thời gian, chúng tôi không thể thêm một số hệ thống crypto MPC ưa thích để cho phép các đầu vào sở hữu tư nhân tạo thành một vòng khép kín trong hệ thống. Vì vậy, để đáp ứng 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 máy chủ đầu vào sở hữu tư nhân, cần thiết để xác minh rằng 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ý của tải trọng và phục vụ họ. Khi mở rộng Bonsol, chúng tôi dự định triển khai hệ thống giải mã ngưỡng MPC mà qua đó nút chuyển tiếp có thể cho phép người yêu cầu giải mã đầu vào sở hữu tư nhân. Tất cả cuộc thảo luận về đầu vào sở hữu tư nhân này đưa chúng ta đến quá trình phát triển thiết kế mà chúng tôi dự định cung cấp trong kho lưu trữ Bonsol. Đó là Bonsolace, một hệ thống đơn giản hơn giú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 mình. Bạn có thể tự mình chứng minh và sau đó xác minh nó trên cùng một 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 sử dụng dữ liệu sở hữu tư nhân có giá trị rất cao trong đó quyền truy cập vào dữ liệu sở hữu tư nhân phải được giảm thiểu.
Một điểm cuối cùng về Bonsol mà chúng tôi chưa từng thấy ở nơi khác với Risc0 là chúng tôi thực thi cam kết (băm) dữ liệu đầu vào khi nó đi vào chương trình zk. Trên thực tế, chúng tôi kiểm tra đầu vào mà người chứng minh phải cam kết theo hợp đồng để đảm bảo nó 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 phát sinh một số chi phí, nhưng 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 trong quá trình phát triển của Bonsol rơi vào quá trình phát triển Solana bình thường, nhưng cần lưu ý rằng chúng tôi cố tình thử một số ý tưởng mới ở đó. Trong hợp đồng thông minh, chúng tôi sử dụng bộ đệm phẳng làm hệ thống tuần tự hóa duy nhất. Đây là một công nghệ hơi mới mà chúng tôi hy vọng có thể phát triển và tạo ra thành một khuôn khổ vì nó rất phù hợp để tạo SDK đa nền tảng. Một lưu ý cuối cùng về Bonsol là hiện tại nó yêu cầu biên dịch trước để hoạt động hiệu quả nhất. Quá trình biên dịch trước này dự kiến sẽ được triển khai trong Solana 1.18, nhưng cho đến lúc đó chúng tôi đang nỗ lực để xem liệu đội ngũ có quan tâm đến việc nghiên cứu vấn đề này và vượt qua Bonsol Khám phá các công nghệ khác hay không.
Tóm tắt
Ngoài Bonsol, đội ngũ xây dựng Anagram đã nghiên cứu sâu về nhiều nơi trong thế giới 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 hoạt động trong lĩnh vực crypto đồng hình hoàn toàn (FHE).
Vui lòng kiểm tra kho phần mềm Bonsol và hỏi vấn đề 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 và bạn có cơ hội tỏa sáng.
Nếu bạn đang làm việc trong một dự án VC thú vị, vui lòng đăng ký chương trình Anagram EIR .
