tiêu đề cấp đầu tiên

Nền tảng đánh giá khung phát triển bằng chứng không kiến ​​thức "Pantheon"

Trong vài tháng qua, chúng tôi đã đầu tư rất nhiều thời gian và công sức vào việc phát triển cơ sở hạ tầng tiên tiến được xây dựng bằng các bằng chứng ngắn gọn về zk-SNARK. Nền tảng sáng tạo thế hệ tiếp theo này cho phép các nhà phát triển xây dựng các mô hình ứng dụng chuỗi khối mới chưa từng có.

Trong công việc phát triển của mình, chúng tôi đã thử nghiệm và sử dụng nhiều khung phát triển bằng chứng không kiến ​​thức (ZKP) khác nhau. Mặc dù hành trình này rất bổ ích, nhưng chúng tôi nhận ra rằng sự đa dạng của các khung ZKP thường đặt ra thách thức cho các nhà phát triển mới khi họ cố gắng tìm ra khung phù hợp nhất với trường hợp sử dụng cụ thể và các yêu cầu về hiệu suất của họ. Xem xét điểm khó khăn này, chúng tôi tin rằng cần có một nền tảng đánh giá cộng đồng có thể cung cấp kết quả kiểm tra hiệu suất toàn diện, điều này sẽ tạo điều kiện thuận lợi cho việc phát triển các ứng dụng mới này.

Để đáp ứng nhu cầu này, chúng tôi đã giới thiệuNền tảng đánh giá khung phát triển bằng chứng không kiến ​​thức "Pantheon"Sáng kiến ​​cộng đồng vì lợi ích công cộng này. Bước đầu tiên của sáng kiến ​​sẽ khuyến khích cộng đồng chia sẻKết quả kiểm tra hiệu suất tái sản xuất. Mục tiêu cuối cùng của chúng tôi là hợp tác tạo ra và duy trì mộtNền tảng thử nghiệm được công nhận rộng rãi,tiêu đề cấp đầu tiên

Bước 1: Kiểm tra hiệu suất của khung mạch bằng SHA-256

Trong bài viết này, chúng tôi thực hiện các bước đầu tiên trong việc xây dựng ZKP Pantheon, sử dụng SHA-256 trong một loạt các khung phát triển mạch cấp thấp để cung cấp một tập hợp các kết quả kiểm tra hiệu suất có thể lặp lại được. Mặc dù chúng tôi thừa nhận rằng có thể thực hiện được các mức độ chi tiết và nguyên mẫu kiểm tra hiệu suất khác, nhưng chúng tôi đã chọn SHA-256 vì nó phù hợp với nhiều trường hợp sử dụng ZKP, bao gồm hệ thống chuỗi khối, chữ ký số, zkDID, v.v. Cũng đáng nói rằng chúng tôi cũng sử dụng SHA-256 trong hệ thống của riêng mình, vì vậy điều này cũng hữu ích cho chúng tôi!

tiêu đề phụ

hệ thống bằng chứng

Trong những năm gần đây, chúng tôi đã quan sát thấy sự gia tăng của các hệ thống bằng chứng không kiến ​​thức. Theo kịp tất cả những tiến bộ thú vị trong lĩnh vực này là một thách thức và chúng tôi đã lựa chọn cẩn thận các hệ thống bằng chứng sau đây để thử nghiệm dựa trên mức độ trưởng thành và sự chấp nhận của nhà phát triển. Mục tiêu của chúng tôi là cung cấp một mẫu đại diện cho các kết hợp giao diện người dùng/phụ trợ khác nhau.

1. Circom + snarkjs / rapidsnark: Circcom là một DSL phổ biến để viết mạch và tạo các ràng buộc R 1 CS, và snarkjs có khả năng tạo các bằng chứng Groth 16 hoặc Plonk cho Circcom. Rapidsnark cũng là chứng minh của Circcom, nó tạo ra bằng chứng Groth 16 và thường nhanh hơn nhiều so với snarkjs do sử dụng các tiện ích mở rộng ADX và song song hóa việc tạo bằng chứng càng nhiều càng tốt.

2. gnark:gnark là một Golang framework toàn diện từ Consensys hỗ trợ Groth 16, Plonk và nhiều tính năng nâng cao khác.

3. Arkworks: Arkworks là một khung Rust toàn diện cho zk-SNARK.

4. Halo 2 (KZG): Halo 2 là một triển khai zk-SNARK của Zcash và Plonk. Nó được trang bị số học Plonkish rất linh hoạt, hỗ trợ nhiều nguyên tắc hữu ích như cổng tùy chỉnh và bảng tra cứu. Chúng tôi sử dụng nhánh Halo 2 của KZG với sự hỗ trợ của Ethereum Foundation và Scroll.

5. Plonky 2 : Plonky 2 là một triển khai SNARK dựa trên công nghệ PLONK và FRI từ Polygon Zero. Plonky 2 sử dụng các trường Goldilocks nhỏ và hỗ trợ đệ quy hiệu quả. Trong các thử nghiệm hiệu suất của mình, chúng tôi nhắm mục tiêu bảo mật 100 bit suy đoán và sử dụng các tham số mang lại thời gian kiểm chứng tốt nhất cho nỗ lực kiểm tra hiệu suất. Cụ thể, chúng tôi đã sử dụng 28 truy vấn Merkle, hệ số khuếch đại là 8 và thử thách bằng chứng công việc 16 bit. Ngoài ra, chúng tôi đặt num_of_wires = 60 và num_roated_wires = 60.

6. Starky: Starky là khung STARK hiệu suất cao của Polygon Zero. Trong các thử nghiệm hiệu suất của mình, chúng tôi nhắm mục tiêu bảo mật 100 bit suy đoán và sử dụng các tham số mang lại thời gian kiểm chứng tốt nhất. Cụ thể, chúng tôi đã sử dụng 90 truy vấn Merkle, hệ số khuếch đại gấp 2 lần và thử thách bằng chứng công việc 10 bit.

Bảng dưới đây tóm tắt các khung trên và các cấu hình liên quan được sử dụng trong các thử nghiệm hiệu suất của chúng tôi. Danh sách này không có nghĩa là đầy đủ và chúng tôi cũng sẽ điều tra nhiều khuôn khổ/công nghệ tiên tiến nhất (ví dụ: Nova, GKR, Hyperplonk) trong tương lai.

Lưu ý rằng các kết quả kiểm tra hiệu suất này chỉ dành cho khung phát triển mạch. Chúng tôi dự định xuất bản một bài viết riêng trong tương lai với các bài kiểm tra hiệu suất của các zkVM khác nhau (ví dụ: Scroll, Polygon zkEVM, Consensys zkEVM, zkSync, Risc Zero, zkWasm) và khung trình biên dịch IR (ví dụ: Noir, zkLLVM).

Phương pháp đánh giá hiệu suất

Để thực hiện kiểm tra hiệu suất trên các hệ thống bằng chứng khác nhau này, chúng tôi tính toán hàm băm SHA-256 của N byte dữ liệu, trong đó chúng tôi thử nghiệm với N = 64, 128, ..., 64 K (Starky là một ngoại lệ, trong đó mạch lặp lại tính toán của đầu vào 64 byte cố định SHA-256, nhưng giữ nguyên tổng số khối thông báo). cho phépkho lưu trữ nàyMã hiệu suất và cấu hình mạch SHA-256 được tìm thấy trong .

Ngoài ra, chúng tôi đã thực hiện kiểm tra hiệu suất trên từng hệ thống bằng cách sử dụng các chỉ số hiệu suất sau:

• Thời gian tạo bằng chứng (bao gồm cả thời gian tạo nhân chứng)

• Mức sử dụng bộ nhớ tăng đột biến trong quá trình tạo bằng chứng

• Tỷ lệ phần trăm sử dụng CPU trung bình trong quá trình tạo chứng thực. (Số liệu này phản ánh mức độ song song hóa trong quy trình tạo bằng chứng)

tiêu đề phụ

máy móc

Chúng tôi đã chạy thử nghiệm hiệu suất trên hai máy khác nhau:

• Máy chủ Linux: 20 lõi @ 2,3 GHz, RAM 384 GB

• Macbook M 1 Pro: 10 nhân @ 3.2 Ghz, RAM 16 GB

Máy chủ Linux được sử dụng để mô phỏng một kịch bản có số lượng lớn lõi CPU và đủ bộ nhớ. Macbook M 1 Pro thường dùng cho nghiên cứu và phát triển có CPU mạnh hơn nhưng ít nhân hơn.

tiêu đề phụ

chữ

hạn chế số lượng

Trước khi chúng tôi chuyển sang kết quả kiểm tra hiệu suất chi tiết, trước tiên, bạn nên hiểu mức độ phức tạp của SHA-256 bằng cách xem xét số lượng các ràng buộc trong mỗi hệ thống bằng chứng. Điều quan trọng cần lưu ý là không thể so sánh trực tiếp số lượng ràng buộc trong các lược đồ số học khác nhau.

Các kết quả bên dưới tương ứng với kích thước hình ảnh trước là 64 KB. Chúng chia tỷ lệ gần như tuyến tính, mặc dù kết quả có thể thay đổi theo các kích thước hình ảnh trước khác.

• Circcom, gnark và Arkworks đều sử dụng cùng một thuật toán R 1 CS và số ràng buộc R 1 CS để tính toán 64 KB SHA-256 nằm trong khoảng từ 30 M đến 45 M. Sự khác biệt giữa Circo, gnark và Arkworks có thể là do sự khác biệt về cấu hình.

• Cả Halo 2 và Plonky 2 đều sử dụng số học Plonkish, trong đó số dòng nằm trong khoảng từ 2^22 đến 2^23. Việc triển khai SHA-256 của Halo 2 hiệu quả hơn nhiều so với Plonky 2 do sử dụng bảng tra cứu.

• chữ

thời gian tạo bằng chứng

[Hình 1] Thời gian tạo bằng chứng của từng khung SHA-256 trên các kích thước hình ảnh gốc khác nhau đã được kiểm tra bằng máy chủ Linux. Chúng ta có thể nhận được những phát hiện sau:

• Đối với SHA-256, khung Groth 16 (rapidsnark, gnark và Arkworks) tạo ra bằng chứng nhanh hơn khung Plonk (Halo 2 và Plonky 2). Điều này là do SHA-256 bao gồm hầu hết các hoạt động theo bit, trong đó các giá trị dây là 0 hoặc 1. Đối với Groth 16, điều này làm giảm hầu hết các tính toán từ phép nhân vô hướng trên đường cong elip sang phép cộng điểm trên đường cong elip. Tuy nhiên, các giá trị dây không được sử dụng trực tiếp trong các tính toán của Plonk, vì vậy cấu trúc dây đặc biệt trong SHA-256 không làm giảm số lượng tính toán cần thiết trong khung Plonk.

• Trong số tất cả các khung Groth 16, gnark và rapidsnark nhanh hơn Arkworks và snarkjs từ 5 đến 10 lần. Điều này là do khả năng vượt trội của họ trong việc tận dụng nhiều lõi để song song hóa việc tạo bằng chứng. Gnark nhanh hơn 25% so với rapidsnark.

• Đối với khung Plonk, SHA-256 của Plonky 2 chậm hơn 50% so với Halo 2 khi sử dụng kích thước hình ảnh trước lớn hơn >= 4 KB. Điều này là do việc triển khai Halo 2 chủ yếu sử dụng bảng tra cứu để tăng tốc hoạt động theo bit, dẫn đến số hàng ít hơn gấp 2 lần so với Plonky 2. Tuy nhiên, nếu chúng ta so sánh Plonky 2 và Halo 2 với cùng số lượng hàng (ví dụ: SHA-256 trên 2 KB trong Halo 2 so với SHA-256 trên 4 KB trong Plonky 2) thì Plonky 2 nhanh hơn 50% so với Halo 2. Nếu chúng tôi triển khai SHA-256 trong Plonky 2 bằng cách sử dụng bảng tra cứu, chúng tôi sẽ mong đợi Plonky 2 nhanh hơn Halo 2, mặc dù kích thước bằng chứng lớn hơn cho Plonky 2.

• Mặt khác, khi kích thước tiền ảnh đầu vào nhỏ (<= 512 byte), Halo 2 chậm hơn Plonky 2 (và các khung khác) do chi phí thiết lập cố định của bảng tra cứu chiếm phần lớn ràng buộc. Tuy nhiên, hiệu suất của Halo 2 trở nên cạnh tranh hơn khi kích thước hình ảnh trước tăng lên và thời gian tạo đã được chứng minh của nó không đổi đối với kích thước hình ảnh trước lên tới 2 KB, có tỷ lệ gần như tuyến tính như minh họa.

• Đúng như dự đoán, thời gian tạo bằng chứng của Starky ngắn hơn nhiều (5x-50x) so với bất kỳ khung SNARK nào, nhưng điều này phải trả giá bằng kích thước bằng chứng lớn hơn.

• Cũng lưu ý rằng mặc dù kích thước mạch tỷ lệ tuyến tính với kích thước tiền ảnh, nhưng việc tạo bằng chứng cho SNARK tăng siêu tuyến tính do O(nlogn) FFT (mặc dù hiện tượng này không được hiển thị trên biểu đồ do thang logarit rõ ràng).

Chúng tôi cũng đã tiến hành kiểm tra hiệu suất thời gian tạo bằng chứng trên Macbook M 1 Pro, như thể hiện trong [Hình 2]. Tuy nhiên, cần lưu ý rằng rapidsnark không được đưa vào điểm chuẩn này do thiếu hỗ trợ cho kiến ​​trúc arm 64. Để sử dụng snarkjs trên arm 64, chúng tôi phải sử dụng webassembly để tạo nhân chứng, chậm hơn so với tạo nhân chứng C++ được sử dụng trên máy chủ Linux.

Một số quan sát bổ sung khi chạy thử nghiệm hiệu suất trên Macbook M 1 Pro:

• Ngoại trừ Starky, tất cả các khung SNARK đều bị lỗi hết bộ nhớ (OOM) hoặc sử dụng bộ nhớ hoán đổi (dẫn đến thời gian kiểm chứng chậm hơn) khi kích thước hình ảnh trước ngày càng lớn. Cụ thể, khung Groth 16 (snarkjs, gnark, Arkworks) bắt đầu sử dụng bộ nhớ hoán đổi ở kích thước ảnh trước >= 8 KB, trong khi gnark hết bộ nhớ ở kích thước ảnh trước >= 64 KB. Halo 2 gặp giới hạn bộ nhớ khi kích thước hình ảnh trước >= 32 KB. Plonky 2 bắt đầu sử dụng bộ nhớ trao đổi khi kích thước ảnh trước >= 8 KB.

• tiêu đề phụ

Mức sử dụng bộ nhớ cao nhất

[Hình 3] và [Hình 4] lần lượt hiển thị mức sử dụng bộ nhớ cao nhất trong quá trình tạo bằng chứng trên Linux Server và Macbook M 1 Pro. Từ các kết quả kiểm tra hiệu suất này, có thể rút ra các nhận xét sau:

• Trong tất cả các khung SNARK, rapidsnark là bộ nhớ hiệu quả nhất. Chúng tôi cũng thấy rằng Halo 2 sử dụng nhiều bộ nhớ hơn khi kích thước hình ảnh trước nhỏ hơn do chi phí thiết lập cố định của bảng tra cứu, nhưng tiêu thụ ít bộ nhớ hơn khi kích thước hình ảnh trước lớn hơn.

• Starky hiệu quả hơn bộ nhớ gấp 10 lần so với khung SNARK. Một phần vì nó sử dụng ít hàng hơn.

• tiêu đề phụ

sử dụng CPU

Chúng tôi đánh giá mức độ song song hóa của từng hệ thống bằng chứng bằng cách đo mức sử dụng CPU trung bình của SHA-256 trong quá trình tạo bằng chứng cho đầu vào hình ảnh trước 4 KB. Bảng bên dưới hiển thị mức sử dụng CPU trung bình (mức sử dụng trung bình trên mỗi lõi trong ngoặc đơn) trên Máy chủ Linux (20 lõi) và Macbook M 1 Pro (10 lõi).

Các quan sát chính như sau:

• Gnark và rapidsnark thể hiện mức sử dụng CPU cao nhất trên các máy chủ Linux, cho thấy rằng chúng có thể sử dụng hiệu quả nhiều lõi và song song hóa việc tạo bằng chứng. Halo 2 cũng cho thấy hiệu suất song song hóa tốt.

• Mức sử dụng CPU của hầu hết các khung trên máy chủ Linux gấp đôi so với Macbook Pro M 1, ngoại trừ snarkjs.

• tiêu đề cấp đầu tiên

Kết luận và nghiên cứu trong tương lai

Bài viết này so sánh toàn diện kết quả kiểm tra hiệu suất của SHA-256 trên các khung phát triển zk-SNARK và zk-STARK khác nhau. Thông qua so sánh, chúng tôi hiểu rõ hơn về hiệu quả và tính hữu ích của từng khung, với hy vọng giúp các nhà phát triển cần tạo bằng chứng ngắn gọn cho hoạt động SHA-256. Chúng tôi nhận thấy rằng các khung Groth 16 (ví dụ: rapidsnark, gnark) tạo ra bằng chứng nhanh hơn so với các khung Plonk (ví dụ: Halo 2, Plonky 2). Các bảng tra cứu trong số học Plonkish giảm đáng kể các ràng buộc SHA-256 và thời gian chứng minh khi sử dụng các kích thước hình ảnh trước lớn hơn. Ngoài ra, gnark và rapidsnark thể hiện khả năng tuyệt vời trong việc khai thác nhiều lõi để song song hóa các hoạt động. Mặt khác, thời gian tạo bằng chứng của Starky ngắn hơn nhiều, với chi phí là kích thước bằng chứng lớn hơn nhiều. Xét về hiệu quả bộ nhớ, rapidsnark và Starky vượt trội so với các khung khác.

Là bước đầu tiên trong quá trình xây dựng nền tảng đánh giá bằng chứng không có kiến ​​thức "Pantheon", chúng tôi thừa nhận rằng kết quả của bài kiểm tra hiệu suất này còn lâu mới đủ để trở thành một nền tảng kiểm tra toàn diện mà chúng tôi hy vọng sẽ xây dựng được. Chúng tôi hoan nghênh và hoan nghênh phản hồi cũng như phê bình, đồng thời mời mọi người đóng góp cho sáng kiến ​​này để làm cho các bằng chứng không có kiến ​​thức trở nên dễ tiếp cận hơn và ít rào cản gia nhập cho các nhà phát triển. Chúng tôi cũng sẵn sàng cung cấp các khoản tài trợ cho những người đóng góp độc lập riêng lẻ để trang trải chi phí tài nguyên tính toán cho thử nghiệm hiệu suất quy mô lớn. Chúng tôi hy vọng rằng cùng nhau, chúng ta có thể cải thiện hiệu quả và tiện ích của ZKP và mang lại lợi ích rộng rãi hơn cho cộng đồng.

Cuối cùng, chúng tôi xin cảm ơn nhóm Polygon Zero, nhóm gnark tại Consensys, Pado Labs và nhóm Delphinus Lab vì những đánh giá và phản hồi có giá trị về kết quả kiểm tra hiệu suất.