Tiêu đề gốc: "Tăng cường Lasso+Jolt thông qua các cam kết nhanh hơn – với những hậu quả sâu rộng"

Tác giả gốc: Justin Thaler

Bản tổng hợp gốc: Luccy, BlockBeats

Ghi chú của biên tập viên:

a16z Crypto đã ra mắt hai công nghệ liên quan đến SNARK: Lasso và Jolt. Chúng giải quyết ba vấn đề chính: hiệu suất, trải nghiệm của nhà phát triển và khả năng kiểm tra.

Lasso là một tham số tra cứu mới có thể làm tăng đáng kể chi phí của bộ chuẩn; Jolt (Just One Lookup Table) là một công cụ được thiết kế để làm việc với Ethereum Virtual Khung được thiết kế Rollups tương thích với máy, một cách mới để xây dựng SNARK VM bằng Lasso. Lasso và Jolt có thể tăng tốc đáng kể việc mở rộng và xây dựng các ứng dụng trong Web3, đồng thời chúng cùng nhau thể hiện một cách tiếp cận mới đối với thiết kế SNARK có thể cải thiện hiệu suất của các chuỗi công cụ được triển khai rộng rãi theo mức độ lớn trở lên.

Bài đọc liên quan: "a16z ra mắt các công cụ chứng minh không có kiến thức mới Lasso và Jolt: cải thiện hiệu suất SNARK và trải nghiệm phát triển》

Đối tác nghiên cứu của a16z Justin Thaler, phó giáo sư tại Khoa Khoa học Máy tính tại Đại học Georgetown, cung cấp cái nhìn sâu sắc về những phát triển công nghệ SNARK mới nhất, nhấn mạnh sự cần thiết phải có được SNARK với các bộ chứng minh hiệu suất cao bằng cách thay đổi các thành phần khác nhau của quá trình triển khai hiện có, bao gồm một số chính công nghệ. Justin đề xuất sử dụng IOP đa thức dựa trên kiểm tra tổng và sơ đồ kết hợp các bộ chứng minh nhanh hơn, các bằng chứng lớn hơn như Ligero/Brakedown, cộng với đệ quy để đạt được hệ thống SNARK hiệu quả hơn. Ngoài ra, ông nhấn mạnh nhu cầu cấp thiết về các hệ thống SNARK đơn giản hơn, dễ phát triển hơn để cải thiện khả năng kiểm tra và bảo mật.

Đầu năm nay, chúng tôi đã ra mắt Lasso và Jolt, SNARK không chỉ mạnh hơn mà còn dễ xây dựng và kiểm tra hơn.

Lasso là một loại tham số tra cứu mới với bộ chuẩn nhanh hơn đáng kể. Dựa trên Lasso, Jolt cung cấp một mô hình thiết kế mới về cơ bản để thiết kế cái gọi là zkVM - SNARK, cho phép người chứng minh chứng minh rằng nó chạy đúng chương trình máy tính (được chỉ định bằng hợp ngữ của một máy ảo cụ thể).

Trọng tâm của cả Lasso và Jolt là một công cụ kỹ thuật được gọi là giao thức kiểm tra tổng mà họ sử dụng để giảm thiểu lượng dữ liệu mà người chứng minh phải cam kết. (và "kích thước" của từng lát dữ liệu). Chi phí chuyển giao dữ liệu là một trở ngại chính trong hoạt động của bộ chuẩn SNARK.

Hôm nay, Ben Diamond và Jim Posen (D&P) của Ulvetanna đã xuất bản một bài báo có thể thay đổi cuộc chơi. Đóng góp cốt lõi của D&P là sửa đổi sơ đồ cam kết Ligero/Brakedown để người chứng minh có thể thanh toán "từng chút một" cho giá trị của mỗi cam kết. Tôi sẽ giải thích cách họ đạt được điều này và tại sao, kết hợp với Lasso, điều này lại mang lại sự cải thiện đáng kể về hiệu suất SNARK. D&P gọi cách triển khai của họ là Binius.

Những phát triển này không chỉ cải thiện hiệu suất mà còn cho thấy rằng chúng tôi đã hiểu sai về các khía cạnh chính của thiết kế SNARK. Ví dụ: Jolt đã chỉ ra rằng khi chúng tôi thiết kế thủ công các máy ảo "thân thiện với SNARK", chúng tôi thực sự đang tùy chỉnh chúng để phù hợp với các ràng buộc nhân tạo của các SNARK phổ biến ngày nay. D&P đã chỉ ra rằng điều tương tự cũng đúng đối với các hàm băm thân thiện với SNARK. Ở cuối bài viết này, tôi cũng sẽ trình bày chi tiết những gì cần thay đổi về thiết kế SNARK, cả về cách chúng tôi nghĩ về nó và những gì chúng tôi xây dựng.

Đạt được SNARK Circuit-SAT tốt hơn thông qua Lasso

Jolt có thể được coi là ứng dụng Lasso An được áp dụng cho việc thực thi VM, theo định nghĩa bao gồm việc thực thi lặp đi lặp lại một vòng lặp tìm nạp-giải mã-thực thi đơn giản của VM. Tuy nhiên, bản thân Lasso có khả năng ứng dụng rộng rãi hơn.

Bước đầu tiên trong D&P là sử dụng Lasso để cung cấp SNARK tốt hơn nhằm đảm bảo sự hài lòng của mạch (chính xác hơn là "mạch" được hỗ trợ là hệ thống hạn chế Plonkish). Điều này có thể được coi là áp dụng Lasso cho một tính toán (có khả năng) không đồng nhất (trái ngược với việc thực thi VM, vốn đã đồng nhất ở chỗ VM thực hiện lặp đi lặp lại cùng một vòng lặp tìm nạp, giải mã và thực thi). Ứng dụng này lợi dụng thực tế là Lasso thực sự mạnh hơn việc tìm tham số: nó là tham số cho các quan hệ tuyến tính thưa thớt tổng quát, được sử dụng để thiết lập mối quan hệ M⋅t = a, trong đó M là ma trận thưa thớt (tức là hầu hết các ma trận thưa thớt của nó). mục nhập bằng 0), trong khi t và a là các vectơ (có thể đã cam kết).

Giống như Jolt, ứng dụng Lasso này có một đặc tính quan trọng là hầu hết tất cả các giá trị mà người chứng minh cần cam kết bằng mật mã đều nhỏ, nghĩa là chúng nằm trong khoảng từ 0 đến 2b, trong đó b là một số không lớn lắm (chúng tôi gọi b là độ phức tạp bit của từng giá trị lời hứa). Ví dụ: trong Jolt, b ≤ 25 đối với hầu hết các giá trị được cam kết.

Trong một bài viết khác, Srinath Setty và tôi đã đề xuất một giải pháp thay thế khái quát hóa Plonkish cho SNARK mà chúng tôi tin là đơn giản hơn về mặt khái niệm nhưng có thể không dễ dàng tích hợp với những đóng góp tiếp theo từ D& ;P.

Các hệ thống ràng buộc Plonkish mới này dựa trên Lasso sẽ giúp việc tích hợp công nghệ Lasso cơ bản vào các công cụ hiện có (chẳng hạn như Halo2) trở nên dễ dàng hơn, nhiều công cụ trong số đó chuyên về Hỗ trợ Plonkish.

Một sơ đồ cam kết đa thức có giá trị nhỏ nhanh hơn

Trước hết, như tôi đã nói ở Bài viết trước của tôi Như đã giải thích trong , hầu hết SNARK bao gồm hai thành phần: cái gọi là IOP đa thức và một nguyên hàm mật mã được gọi là sơ đồ cam kết đa thức. Nút thắt chính của người chứng minh thường là sơ đồ cam kết đa thức.

Ngày nay, có hai loại cơ chế cam kết đa thức được sử dụng rộng rãi. Một là dựa trên mật mã đường cong elip, ví dụ phổ biến nhất trong số đó là các cam kết KZG và Bulletproofs/IPA. Một loại khác dựa trên giá trị băm, ví dụ phổ biến nhất hiện nay là FRI.

Đối với các kế hoạch cam kết dựa trên đường cong và dựa trên hàm băm, việc cam kết với các giá trị nhỏ sẽ nhanh hơn các giá trị lớn. Tuy nhiên, xét về mặt chi phí của chứng minh, đó là một hàm bậc thang liên quan đến kích thước của giá trị: khi kích thước của giá trị tăng lên, chi phí về cơ bản vẫn giữ nguyên, đôi khi có những bước nhảy đáng kể.

Trong trường hợp dựa trên đường cong, điều này là do thuật toán Pippenger, gần như cho phép người chứng minh cam kết các giá trị từ 1 đến 20 bit bằng cách sử dụng một nhóm duy nhất hoạt động, sử dụng Sử dụng hai thao tác nhóm để cam kết các giá trị 20 đến 40 bit, sử dụng ba thao tác nhóm để cam kết các giá trị 40 đến 60 bit, v.v. (Ở đây, 20 là một giá trị thay thế cho "logarit của độ dài của vectơ cam kết", thường nằm trong khoảng từ 20 đến 30 và chi phí cam kết nói trên sẽ được khấu hao.) Đối với các kế hoạch cam kết dựa trên hàm băm, nhiều dự án ngày nay đang làm việc trên phần mở rộng các miền có một trong các miền cơ sở nhỏ hơn. Lời hứa tính toán sẽ nhanh hơn nếu tất cả các giá trị đã cam kết nằm trong trường cơ sở, kích thước trường cơ sở phổ biến hiện nay là từ 31 đến 64 bit.

Tuy nhiên, các chương trình cam kết hiện tại bị hạn chế ở mức độ mà chúng có thể hưởng lợi từ những giá trị nhỏ. Trong trường hợp dựa trên đường cong, việc cam kết giá trị 2 bit (tức là giá trị trong {1, 2, 3, 4}) không nhanh hơn việc cam kết giá trị 20 bit (tức là từ 0 đến 2^20≈1 triệu Số) Nhanh: Cả hai đều yêu cầu một thao tác nhóm đơn lẻ thông qua thuật toán của Pippenger. Điều tương tự cũng xảy ra với các sơ đồ dựa trên hàm băm phổ biến ngày nay, chúng xử lý tất cả các phần tử miền cơ bản như nhau.

D&P làm cho chức năng bước này của sơ đồ cam kết đa thức dựa trên hàm băm Ligero/Brakedown trở nên mượt mà hơn thông qua sự kết hợp của hai kỹ thuật, cho phép Người chứng minh "trả tiền" một cách đại khái tính bằng bit giá trị của mỗi cam kết. Họ đạt được điều này thông qua sự kết hợp của hai công nghệ. Đầu tiên, chúng hoạt động trên miền GF[2^128], có đặc điểm là hai (điều này rất khác với các SNARK phổ biến ngày nay, có đặc điểm ít nhất là 2^31). Họ đã xây dựng miền dưới dạng tháp, nghĩa là GF[2^128] được xây dựng dưới dạng phần mở rộng của GF[2^64], GF[2^64] được xây dựng dưới dạng phần mở rộng của GF[2^32], v.v. TRÊN . Thứ hai, họ sử dụng các kỹ thuật liên quan đến nối mã để đảm bảo rằng việc cam kết giá trị 1 bit thực sự rẻ hơn khoảng 2 lần so với cam kết giá trị 2 bit và việc cam kết giá trị 2 bit rẻ hơn khoảng 2 lần so với cam kết một giá trị 2 bit. Giá trị 4 bit, v.v. (Để biết tổng quan về các kỹ thuật này, hãy xem Câu hỏi thường gặp chi tiết hơn về Công nghệ đi kèm của tôi.)

Hiệu quả có thể rất ấn tượng. Trong SNARK hiện tại của D&P dành cho Keccak, tất cả các giá trị đã cam kết là các bit riêng lẻ và việc cải tiến chúng giúp giảm thời gian thực hiện các giá trị một bit này nhiều hơn một bậc độ lớn. Ví dụ: trong Jolt, một phần ba đến hai phần ba giá trị đã cam kết chỉ là một bit.

Những cải tiến đáng kể trong việc băm SNARK

Hai đóng góp đầu tiên là khi áp dụng cho các tính năng của hai Xét về mức độ hài lòng của mạch trên hiện trường, SNARK nhanh hơn được tạo ra, có thể nhanh hơn một hoặc thậm chí hai bậc độ lớn so với công việc trước đó.

D&P sau đó áp dụng SNARK này để triển khai hàm băm Keccak (và một hàm khác gọi là Grøstl), tạo ra các tỷ lệ cho các hàm băm này. SNARK nhanh hơn nhiều so với bất kỳ hàm nào trước. Sau khi được tối ưu hóa hoàn toàn, tôi hy vọng SNARK của họ sẽ chứng minh được hơn 5.000 hoán vị Keccak-f mỗi giây trên một luồng (máy được sử dụng trong điểm chuẩn là phiên bản AWS c7i.16xlarge với bộ xử lý Intel Sapphire Rapids 8488C) và có rất nhiều khả năng song song có sẵn. Điều này có nghĩa là 20-25 MiB dữ liệu có thể được băm trong khoảng 30 giây xử lý đơn luồng.

Tác động

Bản thân các SNARK tốt hơn để băm có sức mạnh rất lớn vì SNARK được sử dụng trong nhiều câu lệnh Mật mã, chẳng hạn như như kiến thức về đường dẫn xác thực Merkle, cuối cùng sẽ rút gọn thành giá trị băm. Trên thực tế, đây là điểm nghẽn chính trong zkEVM Loại 1 cũng như SNARK dựa trên hàm băm đệ quy.

Vì vậy, mặc dù Lasso tạo ra SNARK tốt hơn cho hàm băm, nhưng nó và Jolt cũng được hưởng lợi từ điều đó: SNARK tốt hơn cho hàm băm cho phép Lasso và Jolt cạnh tranh với (Phiên bản đệ quy) là được sử dụng cùng với sơ đồ cam kết đa thức dựa trên hàm băm Ligero/Brakedown. Trình chứng minh của các sơ đồ này rất nhanh, nhưng yêu cầu người xác minh thực hiện khá nhiều thao tác băm (theo căn bậc hai của kích thước đa thức của cam kết). Điều này gây khó khăn cho việc áp dụng SNARK đệ quy bằng cách sử dụng Ligero/Brakedown vì người chứng minh khó chứng minh rằng nó thực hiện chính xác thao tác băm của người xác minh. Khó khăn này sẽ biến mất sau khi sử dụng SNARK băm nhanh hơn.

Đặc biệt, đối với các mạch có hàng tỷ cổng, kích thước của bằng chứng Ligero/Brakedown ở mức MB và trình xác minh V chủ yếu thực hiện các thao tác hiện trường (đối với đệ quy rất rẻ) và các phép toán băm. Xem xét rằng SNARK có thể băm 20 MB dữ liệu trong 30 giây xử lý một luồng (và hoàn toàn có thể song song hóa), người chứng minh sẽ cần ít hơn 10 giây xử lý một luồng để áp dụng đệ quy hệ thống chứng minh này.

Ngoài ra, khi sử dụng đệ quy, việc tối ưu hóa kích thước chứng minh của Ligero/Brakedown là không hợp lý mà nên tối ưu hóa thời gian chạy của chứng minh đệ quy . Vì các hoạt động băm đắt hơn các hoạt động tại hiện trường nên Ligero/Brakedown phải được cấu hình để trình xác minh V thực hiện ít hoạt động băm hơn, ngay cả khi điều này có nghĩa là bằng chứng lớn hơn và nhiều hoạt động tại hiện trường hơn. Điều này sẽ tăng tốc độ chứng minh đệ quy vượt quá ước tính 10 giây nói trên.

Nhìn chung, việc kết hợp Lasso và Jolt với sơ đồ cam kết của D&P (ứng dụng đệ quy) sẽ cải thiện hơn nữa hiệu suất của Lasso và Jolt. Điều này là do Keccak và Grøstl nhanh hơn các hàm băm thân thiện với SNARK phổ biến hiện nay và Ligero/Brakedown chứng tỏ nhanh hơn FRI bất kể hàm băm nào được sử dụng.

Xem xét lại quan điểm băm thân thiện với SNARK

Jolt cho thấy hầu hết các dự án zkVM đều hiểu sai về máy ảo "thân thiện với SNARK" là gì. Thuộc tính chính tạo nên lệnh "thân thiện với SNARK" được gọi là khả năng phân tách. Các tập lệnh thực tế, thay vì các tập lệnh được thiết kế bằng tay cho cái gọi là tính thân thiện với SNARK, đương nhiên đáp ứng được đặc tính này. Chúng tôi đã thiết kế thủ công các máy ảo để phù hợp với những hạn chế của SNARK phổ biến ngày nay, nhưng những hạn chế này là giả tạo. D&P cho thấy điều này cũng đúng đối với các hàm băm thân thiện với SNARK. Trong thời gian tới, công việc trong tương lai là tối ưu hóa hoàn toàn SNARK của D&P thành các hàm băm tiêu chuẩn và so sánh hiệu suất của chúng với các hàm băm phổ biến hiện nay khi áp dụng cho các hàm băm có vẻ thân thiện với SNARK.

Bằng chứng kiểm tra tổng tên miền nhỏ nhanh hơn

Các cam kết hiện tại của D&P Chi phí đã giảm xuống còn điểm là, trong quá trình triển khai Keccak SNARK hiện tại của họ, nút thắt cổ chai của người chứng minh không còn là sơ đồ cam kết đa thức nữa mà là giao thức kiểm tra tổng (cốt lõi kỹ thuật của IOP đa thức cơ bản của Lasso và Jolt).

Tuy nhiên, việc triển khai chương trình bằng chứng kiểm tra tổng hiện tại, bao gồm cả D&P, không được tối ưu hóa để tận dụng thực tế là các giá trị được tính tổng đều là " sự thật "nhỏ". Nghĩa là, việc kiểm tra tổng hiện tại chứng minh rằng các chương trình thực hiện rất ít thao tác trường hữu hạn, nhưng hầu hết các thao tác này xảy ra trong "toàn bộ trường" GF[2^128], mặc dù hầu hết các giá trị được tính tổng đều tồn tại trong một In nhỏ hơn tên miền phụ, chẳng hạn như GF[2], GF[2^8] hoặc GF[2^16].

Trong bài đăng khác của tôi, tôi đã tối ưu hóa bộ chứng minh kiểm tra tổng để tận dụng các giá trị nhỏ. Tùy thuộc vào kích thước của các giá trị, điều này có thể cải thiện công việc của người kiểm tra tổng theo hệ số 2 hoặc thậm chí theo nhiều bậc độ lớn.

Việc kết hợp những hoạt động tối ưu hóa này vào quá trình triển khai D&P là công việc ngắn hạn trong tương lai.

Vai trò của sự tương tác trong thiết kế SNARK

Ngày nay được công nhận rộng rãi là có SNARK bằng chứng hiệu suất hàng đầu sử dụng IOP đa thức với tương tác tối thiểu (tức là các vòng không đổi), kết hợp với sơ đồ cam kết đa thức có tính tương tác cao, tức là FRI. (Chống đạn/IPA cũng có tính tương tác cao, mặc dù ít được kết hợp với thiết bị chuẩn nhanh.) Điều này trái ngược với cách thiết kế SNARK, thiết bị chuẩn nhanh. Các tương tác trong IOP đa thức có thể được khai thác để giảm chi phí của người chứng minh, trong khi các tương tác trong sơ đồ cam kết đa thức được khai thác để giảm chi phí của người xác minh, thường phải trả chi phí cho người chứng minh.

Vì chi phí của bộ chứng minh là nút thắt chính về khả năng mở rộng của SNARK nên các tương tác trong IOP đa thức là chìa khóa để đạt được SNARK có khả năng mở rộng cao hơn và số lượng lớn các tương tác trong sơ đồ cam kết đa thức trên thực tế có thể gây hại khả năng mở rộng.

Chi tiết hơn, FRI (và Bulletproofs/IPA) khai thác các tương tác để giảm thiểu kích thước bằng chứng, nhưng điều này lại làm mất thời gian chứng minh. Thay vào đó, chúng ta nên theo đuổi cách chứng minh nhanh nhất có thể, ngay cả khi điều này có nghĩa là chỉ thu được một bằng chứng có kích thước hơi cận tuyến tính. Sau đó chúng ta có thể áp dụng đệ quy để giảm kích thước của bằng chứng. Đây chính xác là những gì được thực hiện trong cam kết đa thức Ligero/Brakedown, chỉ bao gồm một vòng tương tác và có bộ chứng minh rất nhanh nhưng với bằng chứng có kích thước căn bậc hai. Trước công việc của D&P, SNARK đệ quy sử dụng các sơ đồ cam kết này rất khó khăn vì trình xác thực Ligero/Brakedown phải thực hiện một số lượng lớn các đánh giá băm. Trên thực tế, một số tác phẩm, chẳng hạn như Orion, chỉ đơn giản là "bỏ hàm băm của trình xác thực trong đệ quy", hạn chế kích thước bằng chứng và giảm bớt công việc của trình xác thực. Tuy nhiên, vì SNARK để đánh giá hàm băm bằng chứng nhanh hơn nên vấn đề này sẽ biến mất.

Tương tác trong nhiều vòng của IOP đa thức giúp ích rất nhiều cho người chứng minh. Cụ thể, giao thức kiểm tra tổng sử dụng nhiều vòng tương tác để giảm thiểu chi phí cam kết của người chứng minh. Ở cấp độ thấp hơn, các giao thức kiểm tra tổng sử dụng đa thức đa biến và tương tác qua nhiều vòng, trong khi IOP đa thức phổ biến nhất hiện nay sử dụng đa thức một biến và tương tác qua một số vòng nhỏ. Các phương pháp đơn biến đạt được chức năng tương tự như các phương pháp đa biến, nhưng phải trả giá bằng việc yêu cầu người chứng minh phải cung cấp một lượng lớn dữ liệu bổ sung vào những thời điểm quan trọng.

Điều xảy ra ở đây là giao thức kiểm tra tổng cho phép người chứng minh thực hiện các thao tác hiện trường bổ sung (nhanh) để giảm sự tham gia của người chứng minh vào kế hoạch cam kết. của các hoạt động mật mã được sử dụng (chậm). Đây là một chiến thắng cho thời gian của người chứng minh. Ngược lại, các sơ đồ cam kết có tính tương tác cao cho phép người chứng minh thực hiện các hoạt động mã hóa bổ sung (so với các sơ đồ tương tác tối thiểu), không làm giảm công việc của người chứng minh mà để giảm chi phí của người xác minh, chẳng hạn như kích thước bằng chứng và Công việc của người xác minh. Tốt hơn nên sử dụng đệ quy thay vì tương tác, chuyển các chi phí xác minh này cho người chứng minh, chỉ với thời gian chứng minh tăng nhẹ (bây giờ chúng tôi có SNARK đủ nhanh để băm).

Chúng ta nên khai thác các tương tác trong IOP đa thức để giảm thiểu lượng dữ liệu mà người chứng minh cần phải cam kết. Sơ đồ cam kết đa thức để cam kết dữ liệu phải nhanh nhất có thể đối với người chứng minh, với chi phí xác minh tuyến tính. Chỉ cần một vòng tương tác là đủ. Sau đó, chi phí xác minh có thể được giảm thông qua đệ quy mà không tạo ra nút thắt cổ chai mới cho người chứng minh.

Phác thảo những phát triển mới

D&P sử dụng Lasso để mang lại khả năng đáp ứng mạch tốt hơn (mạch- SAT)SNARK .

SARK này có thể sử dụng bất kỳ sơ đồ cam kết đa thức đa tuyến tính nào. Ngoài ra, chúng còn cung cấp sơ đồ cam kết đa thức nhanh hơn (Ligero/Brakedown được khởi tạo trên các miền có đặc điểm hai). Nói tóm lại, bằng cách sử dụng các trường tháp nhị phân và tầng mã, họ đảm bảo rằng việc thực hiện các giá trị rất nhỏ diễn ra rất nhanh (nhanh hơn ít nhất một bậc so với công việc trước đó). Sơ đồ này rất nhanh đối với người chứng minh, nhưng chi phí xác minh tương đối cao (người xác minh cần thực hiện nhiều thao tác băm).

Cùng với nhau, hai sự phát triển này cung cấp SNARK cực nhanh cho các hàm băm tiêu chuẩn như Keccak. Một lần nữa, chi phí xác minh này tương đối cao.

SARK được băm nhanh hơn cho phép các SNARK này có tính đệ quy, mặc dù chi phí xác minh của chúng tương đối cao.

Đệ quy lần lượt giải quyết được vấn đề tốn rất nhiều chi phí xác minh.

Tác động của các bài báo học thuật về mật mã lên hệ sinh thái SNARK

Những kết quả nghiên cứu mới này có nghĩa là , để có được bộ chứng minh SNARK hiệu suất cao, về cơ bản chúng ta nên thay đổi mọi thành phần được triển khai ngày nay, bao gồm:

IOP đa thức (Bằng chứng tương tác): Chúng phải như vậy dựa trên việc kiểm tra tổng thể để giảm thiểu lượng dữ liệu mà người chứng minh cần gửi.

Các sơ đồ cam kết đa thức: Chúng ta nên kết hợp các bộ chứng minh nhanh hơn, các sơ đồ chứng minh lớn hơn như Ligero/Brakedown, với đệ quy. Ligero/Brakedown có các đặc tính an toàn giống hệt như FRI. Chúng minh bạch, có khả năng bảo mật trong các giai đoạn sau của điện toán lượng tử, chỉ dựa trên hàm băm, v.v.

Hàm băm: Tôi ủng hộ việc sử dụng các hàm băm như Keccak và Grøstl, những hàm này ít nhất cũng tốt như cái gọi là hàm băm "thân thiện với SNARK" ngày nay Chứng minh nhanh chóng. Nếu chúng tôi muốn thiết kế các hàm băm thân thiện với SNARK hơn, chúng tôi sẽ phải bắt đầu lại từ đầu, có tính đến sự hiểu biết đã được cải thiện của chúng tôi về các khả năng và hạn chế thực tế của SNARK hiệu suất cao.

Bộ hướng dẫn của zkVM: Chúng ta nên sử dụng bộ hướng dẫn tiêu chuẩn của RISC-V, thay vì bộ hướng dẫn được thiết kế xoay quanh những hạn chế của các hệ thống đã được chứng minh trước đó. Chúng ta cũng không nên thiết kế mạch theo cách thủ công để thực hiện từng lệnh. Thay vào đó, các nhà thiết kế zkVM chỉ cần chỉ định bảng đánh giá cho từng lệnh và sử dụng tham số tra cứu tổng thể dựa trên kiểm tra như Lasso.

Các miền mà chúng bao gồm: Vì nhiều lý do kỹ thuật khác nhau, SNARK phổ biến ngày nay thường yêu cầu các miền có tính năng tương đối lớn (việc triển khai thường sử dụng ít nhất 231 tính năng). SNARK dựa trên các giao thức kiểm tra tổng thể không có hạn chế này và D&P đã chỉ ra cách khai thác các miền có tính năng rất nhỏ, chẳng hạn như GF [2128], để đạt được những cải tiến đáng kể về hiệu suất.

May mắn thay, những bước phát triển tương tự dẫn đến những thay đổi này cũng khiến SNARK trở nên đơn giản và dễ xây dựng hơn, mặc dù vẫn còn chỗ để cải tiến thêm. Đặc biệt, Jolt loại bỏ nhu cầu thiết kế thủ công các tập lệnh cho zkVM hoặc tối ưu hóa thủ công các mạch thực hiện các tập lệnh này, vì nó thay thế các mạch này bằng thông số kỹ thuật đơn giản của bảng đánh giá cho mỗi lệnh thô. Kiến trúc mô-đun và chung này giúp dễ dàng thay thế các lược đồ cam kết miền và đa thức, triển khai đệ quy và thường giảm diện tích bề mặt cho các lỗi cũng như số lượng mã cần được duy trì và xem xét.

Sự đơn giản này không chỉ quan trọng đối với khả năng sử dụng và tốc độ phát triển. Nó giúp giải quyết một vấn đề bảo mật quan trọng. Một hệ thống dựa trên SNARK bao gồm hàng nghìn dòng mã, đòi hỏi sự hiểu biết về nhiều hệ thống ràng buộc tùy chỉnh hoặc DSL, sẽ không bao giờ có thể kiểm tra đủ để đảm bảo giá trị hàng tỷ đô la.

Tôi hy vọng bài viết này sẽ thuyết phục được nhiều dự án hơn đầu tư phát triển SNARK tuân thủ mô hình thiết kế này.

Một số điểm tôi đưa ra vẫn cần được xác minh đầy đủ bằng cách triển khai trong tương lai gần (ví dụ: so sánh Keccak SNARK của D&P với những so sánh có vẻ thân thiện đó của hàm băm SNARK và triển khai đầy đủ đệ quy để giảm kích thước bằng chứng). Trong thời gian chờ đợi, quá trình triển khai Jolt ban đầu của chúng tôi (với sơ đồ cam kết dựa trên đường cong) đã gần hoàn tất. Sau khi hoàn thành, sẽ rất đáng để triển khai lại Jolt để sử dụng sơ đồ cam kết dựa trên hàm băm của D&P. Điều này hơi phức tạp, chủ yếu là do việc chuyển từ miền nguyên tố lớn sang miền hai miền riêng yêu cầu xác định lại các bảng tra cứu cho tất cả các ứng dụng Lasso. Tôi cũng hy vọng rằng SNARK dựa trên các mạch Plonkish mới của Lasso sẽ đơn giản hóa quá trình tích hợp Lasso vào các công cụ hiện có vì nó có thể cung cấp các mạch mà mọi người đã viết vào đó.

Đây là những bước tiếp theo rõ ràng. Tôi rất vui muốn biết điều gì sẽ xảy ra khi cộng đồng tiếp thu hoàn toàn khả năng của giao thức kiểm tra tổng để giảm thiểu chi phí cam kết.

「Liên kết gốc"

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia