Pantheon: Nền tảng đánh giá khung phát triển ZKP của Celer

Nguồn gốc: Celer Network

Chúng tôi xin cảm ơn các nhóm Polygon Zero, Consensys gnark, Pado Labs và Delphinus Lab vì những đề xuất và phản hồi có giá trị của họ về bài viết này.

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

Chúng tôi đã đầu tư rất nhiều thời gian và công sức trong vài tháng qua để 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 đổi mới 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 blockchain 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 có kiến thức (ZKP). Mặc dù hành trình này rất bổ ích nhưng chúng tôi nhận thấy rằng sự đa dạng của các khung ZKP thường tạo 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 các trường hợp sử dụng cụ thể và yêu cầu về hiệu suất của họ. Lưu ý đến vấn đề 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 rất nhiều 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 đã ra mắt nền tảng đánh giá khung phát triển bằng chứng không có kiến thức "Pantheon" Sáng kiến cộng đồng 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ả thử nghiệm hiệu suất có thể lặp lại của các khung ZKP khác nhau. Mục tiêu cuối cùng của chúng tôi là hợp tác cùng nhau để tạo và duy trì một nền thử nghiệm được công nhận rộng rãi nhằm đánh giá các khung phát triển mạch cấp thấp, trình biên dịch và zkVM cấp cao cũng như thậm chí cả các nhà cung cấp khả năng tăng tốc phần cứng. Chúng tôi hy vọng rằng sáng kiến này sẽ cho phép các nhà phát triển có thêm tài liệu tham khảo để so sánh hiệu suất khi lựa chọn khung, từ đó đẩy nhanh việc quảng bá ZKP. Đồng thời, chúng tôi hy vọng sẽ thúc đẩy việc nâng cấp và lặp lại chính khung ZKP bằng cách cung cấp một bộ kết quả kiểm tra hiệu suất có thể tham khảo chung. Chúng tôi đang đầu tư rất nhiều vào sáng kiến này và mời tất cả các thành viên cộng đồng có cùng chí hướng tham gia cùng chúng tôi và đóng góp cho nỗ lực này!

 Bước 1: Sử dụng SHA-256 để thực hiện kiểm tra hiệu suất trên khung mạch

Trong bài đăng này, chúng tôi thực hiện những bước đầu tiên để xây dựng ZKP Pantheon, cung cấp một bộ kết quả kiểm tra hiệu suất có thể tái tạo bằng SHA-256 trong một loạt khung phát triển mạch cấp thấp. Mặc dù chúng tôi thừa nhận rằng có thể có các mức độ chi tiết và nguyên thủy kiểm tra hiệu suất khác, nhưng chúng tôi đã chọn SHA-256 vì tính phù hợp của nó 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. Điều đáng nói là 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 đó cũng rất hữu ích cho chúng tôi!

Các thử nghiệm hiệu suất của chúng tôi đánh giá hiệu suất SHA-256 trên nhiều khung phát triển mạch zk-SNARK và zk-STARK khác nhau. Thông qua so sánh, chúng tôi tìm cách cung cấp cho các nhà phát triển những hiểu biết sâu sắc về hiệu quả và tính hữu ích của từng khung. Mục tiêu của chúng tôi là kết quả của bài kiểm tra hiệu suất này có thể cung cấp tài liệu tham khảo để các nhà phát triển đưa ra quyết định sáng suốt khi chọn khung tốt nhất.

Hệ thống chứng minh

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

Circom + snarkjs / rapidsnark: 

Circom là DSL phổ biến để ghi mạch và tạo ra các ràng buộc R1CS, còn snarkjs có thể tạo bằng chứng Groth16 hoặc Plonk. Rapidsnark cũng là người chứng minh của Circom, nó tạo ra bằng chứng Groth16 và nhờ sử dụng tiện ích mở rộng ADX, nó thường nhanh hơn nhiều so với snarkjs và tạo ra bằng chứng song song bất cứ khi nào có thể.

gnark: 

gnark là một khung Golang toàn diện của Consensys hỗ trợ Groth16, Plonk và nhiều tính năng nâng cao khác.

Arkworks : 

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

Halo2 (KZG): 

Halo2 là Zcash Với việc triển khai zk-SNARK của Plonk. Nó đi kèm với số học Plonkish rất linh hoạt và hỗ trợ nhiều nguyên thủy hữu ích như cổng tùy chỉnh và bảng tra cứu. Chúng tôi sử dụng phân nhánh Halo2 của KZG với sự hỗ trợ của Ethereum Foundation và Scroll.

Plonky2: 

Plonky2 dựa trên PlonK từ Polygon Zero và triển khai SNARK của công nghệ FRI. Plonky2 sử dụng các trường Goldilocks nhỏ và hỗ trợ đệ quy hiệu quả. Trong thử nghiệm hiệu suất của chúng tôi, chúng tôi nhắm mục tiêu bảo mật suy đoán 100-bit và sử dụng các tham số mang lại thời gian thử nghiệm tốt nhất cho nỗ lực thử nghiệm 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_routed_wires = 60.

Starky : 

Starky là Hiệu suất cao nhất của Polygon Zero khuôn khổ STARK. Trong các thử nghiệm hiệu suất của chúng tôi, chúng tôi nhắm mục tiêu bảo mật suy đoán 100 bit 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 sau đâ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 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ẽ xem xét nhiều khung/công nghệ tiên tiến nhất trong tương lai (ví dụ: Nova, GKR, Hyperplonk).

Xin lưu ý rằng các kết quả kiểm tra hiệu suất này chỉ áp dụng cho khuôn khổ 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 để thực hiện 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à các khung trình biên dịch IR (ví dụ: Noir, zkLLVM).

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

Theo thứ tự Để kiểm tra hiệu suất của các hệ thống chứng minh 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, ..., 64K (Starky là một ngoại lệ, trong đó các mạch được lặp lại SHA- 256 sửa lỗi tính toán cho đầu vào 64 byte nhưng vẫn giữ nguyên tổng số khối thông báo). Bạn có thể tìm thấy mã hiệu suất và cấu hình mạch SHA-256 trong kho lưu trữ này.

Ngoài ra, chúng tôi đã kiểm tra hiệu suất của 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 bằng chứng)

Mức sử dụng bộ nhớ cao nhất trong quá trình tạo bằng chứng

Phần trăm sử dụng CPU trung bình trong quá trình xây dựng bản trình diễn. (Số liệu này phản ánh mức độ song song trong quy trình tạo bằng chứng)

Lưu ý rằng chúng tôi Một số Các giả định "tùy ý" đang được đưa ra về kích thước bằng chứng và chi phí xác minh bằng chứng, vì những khía cạnh này có thể được giảm thiểu bằng cách kết hợp với Groth16 hoặc KZG trước khi đưa vào chuỗi.

Máy

Chúng tôi đã tiến hành thử nghiệm hiệu năng trên hai máy khác nhau:

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

Macbook M1 Pro: 10 lõi @3,2GHz, RAM 16GB

Máy chủ Linux được sử dụng để mô phỏng các tình huống có nhiều lõi CPU và bộ nhớ dồi dào. Và Macbook M1 Pro, loại thường được sử dụng cho hoạt động nghiên cứu và phát triển, có CPU mạnh hơn nhưng ít lõi hơn.

Chúng tôi đã bật tính năng đa luồng tùy chọn nhưng chúng tôi không sử dụng tính năng tăng tốc GPU trong bài kiểm tra hiệu suất này. Chúng tôi dự định tiến hành thử nghiệm hiệu suất GPU trong tương lai.

Kết quả đánh giá hiệu suất 

Số ràng buộc số lượng ràng buộc

Trước khi chúng ta tiếp tục thảo luận về kết quả kiểm tra hiệu suất chi tiết, trước tiên cần hiểu mức độ phức tạp của SHA-256 bằng cách xem xét số lượng ràng buộc trong mỗi hệ thống chứng minh. Đ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 sơ đồ số học khác nhau.

Kết quả bên dưới tương ứng với kích thước ảnh gốc là 64KB. Mặc dù kết quả có thể khác nhau tùy theo kích thước tiền ảnh khác nhưng chúng có tỷ lệ gần như tuyến tính.

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

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

Starky sử dụng thuật toán AIR, yêu cầu 2^16 bước chuyển đổi để thực thi bảng theo dõi.

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

Đối với SHA-256, Groth16 framework (rapidsnark, gnark và Arkworks) tạo ra bằng chứng nhanh hơn khung Plonk (Halo2 và Plonky2). Điều này là do SHA-256 bao gồm chủ yếu các hoạt động bit, trong đó các giá trị tuyến tính là 0 hoặc 1. Đối với Groth16, điều này làm giảm hầu hết việc tính toán từ phép nhân vô hướng đườ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 tính toán của Plonk, do đó cấu trúc dây đặc biệt trong SHA-256 không làm giảm lượng tính toán cần thiết trong khung Plonk.

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

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

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

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

Một điều khác cần lưu ý là ngay cả khi kích thước mạch là giống như kích thước hình ảnh gốc Về mặt tuyến tính, việc tạo bằng chứng cho SNARK cũng phát triển siêu tuyến tính do O(nlogn) FFT (mặc dù hiện tượng này không rõ ràng trên biểu đồ do thang logarit).

Hình 1

Chúng tôi cũng đã tiến hành thử nghiệm hiệu suất thời gian tạo bằng chứng trên Macbook M1 Pro, như được hiển thị trong hình 2. Tuy nhiên, điều quan trọng cần lưu ý là rapidsnark không được đưa vào thử nghiệm hiệu năng này do thiếu hỗ trợ cho kiến trúc arm64. Để sử dụng snarkjs trên arm64, chúng tôi phải sử dụng webassembly để tạo nhân chứng, tốc độ này 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ố nhận xét bổ sung khi chạy thử nghiệm hiệu năng trên Macbook M1 Pro:

Ngoại trừ Starky, tất cả các khung SNARK đều ở trong ảnh gốc Bất cứ lúc nào kích thước tăng lên, bạn sẽ gặp phải lỗi hết bộ nhớ (OOM) hoặc sử dụng bộ nhớ trao đổi (dẫn đến thời gian kiểm chứng chậm hơn). Cụ thể, các khung Groth16 (snarkjs, gnark, Arkworks) bắt đầu sử dụng bộ nhớ trao đổi khi kích thước tiền ảnh>= 8KB, trong khi gnark hết bộ nhớ khi kích thước tiền ảnh>= 64KB. Halo2 gặp phải giới hạn bộ nhớ khi kích thước tiền ảnh>= 32KB. Plonky2 bắt đầu sử dụng bộ nhớ trao đổi khi kích thước tiền ảnh>= 8KB.

Khung công tác dựa trên FRI (Starky và Plonky2) trên Macbook M1 Pro nhanh hơn khoảng 60% so với trên máy chủ Linux, trong khi các khung công tác khác có thời gian chứng minh tương tự trên cả hai máy. Vì vậy, ngay cả khi không sử dụng bảng tra cứu trong Plonky2, nó vẫn đạt được thời gian chứng minh gần như tương đương với Halo2 trên Macbook M1 Pro. Nguyên nhân chính là do Macbook M1 Pro có CPU mạnh hơn nhưng ít lõi hơn. FRI chủ yếu thực hiện các hoạt động băm và nhạy hơn với chu kỳ xung nhịp của CPU, nhưng khả năng song song của nó không tốt bằng KZG hay Groth16.

Hình 2

Mức sử dụng bộ nhớ tối đa Mức sử dụng bộ nhớ tối đa

[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ản thử nghiệm trên Linux Server và Macbook M1 Pro. Những nhận xét sau đây có thể được đưa ra dựa trên các kết quả kiểm tra hiệu suất này:

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

Starky có hiệu suất bộ nhớ cao hơn 10 lần so với khung SNARK . Một phần lý do là nó sử dụng ít hàng hơn.

Cần lưu ý rằng do sử dụng bộ nhớ trao đổi, kích thước hình ảnh gốc sẽ lớn hơn, do đó mức sử dụng bộ nhớ tăng đột biến trên Macbook M1 Pro vẫn tương đối ổn định.

Hình 3

Hình 4

Mức sử dụng CPU Mức sử dụng CPU

Chúng tôi đo mức trung bình SHA-256 trong quá trình tạo bằng chứng về việc sử dụng CPU đầu vào hình ảnh trước 4KB để đánh giá hiệu suất mức độ song song của từng hệ thống chứng minh. Bảng sau đây 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 M1 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, thể hiện khả năng sử dụng hiệu quả nhiều lõi và Song song hóa tạo ra bằng chứng. Halo2 cũng thể hiện hiệu suất song song tốt.

Việc sử dụng CPU của hầu hết các khung công tác trên máy chủ Linux gấp 2 lần mức đó của Macbook Pro M1, ngoại trừ snarkjs.

Mặc dù ban đầu người ta mong đợi rằng các khuôn khổ dựa trên FRI (Plonky2 và Starky) có thể khó sử dụng nhiều lõi một cách hiệu quả nhưng chúng hoạt động không thua kém một số khung Groth16 hoặc KZG trong các thử nghiệm hiệu suất của chúng tôi. Vẫn còn phải xem liệu có sự khác biệt trong việc sử dụng CPU trên máy có nhiều lõi hơn hay không (ví dụ: 100 lõi).  

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

Bài viết này cung cấp sự 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. Sự so sánh này cung cấp cái nhìn sâu sắc về hiệu quả và tính hữu dụng của từng khung mà chúng tôi hy vọng có thể giúp các nhà phát triển cần tạo bằng chứng ngắn gọn cho các hoạt động SHA-256. Chúng tôi nhận thấy rằng các khung Groth16 (ví dụ: rapidsnark, gnark) tạo ra bằng chứng nhanh hơn các khung Plonk (ví dụ: Halo2, Plonky2). Các bảng tra cứu trong số học Plonkish giảm đáng kể các ràng buộc và thời gian chứng minh SHA-256 khi sử dụng kích thước tiền ảnh lớn hơn. Ngoài ra, gnark và rapidsnark thể hiện khả năng tuyệt vời trong việc tận dụng nhiều lõi để hoạt động song song. Mặt khác, thời gian tạo ra bằng chứng của Starky ngắn hơn nhiều nhưng lại phải trả giá bằng kích thước bằng chứng lớn hơn nhiều. Về hiệu quả bộ nhớ, rapidsnark và Starky vượt trội hơn các framework khác.

Là bước đầu tiên trong việc 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 Điều này Kết quả kiểm tra hiệu suất còn lâu mới đủ để trở thành nền tảng kiểm tra toàn diện mà chúng tôi hy vọng xây dựng. Chúng tôi hoan nghênh và hoan nghênh các 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 để giúp các nhà phát triển sử dụng bằng chứng không có kiến thức một cách dễ dàng hơn và giảm bớt rào cản. Chúng tôi cũng sẵn sàng cung cấp các khoản tài trợ cho các cá nhân đóng góp độc lập để trang trải chi phí tài nguyên máy tính cho việc thử nghiệm hiệu suất trên quy mô lớn. Chúng tôi hy vọng có thể hợp tác cùng nhau để nâng cao hiệu quả và tính thiết thực của ZKP và mang lại lợi ích cho cộng đồng một cách rộng rãi hơn.

Cuối cùng, chúng tôi xin cảm ơn các nhóm Polygon Zero, Consensys Gnark, Pado Labs và Delphinus Lab vì những đánh giá và phản hồi có giá trị của họ về kết quả kiểm tra hiệu suấ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