Chúng tôi xin cảm ơn nhóm Polygon Zero, dự án gnark Consensys, Pado Labs và nhóm Delphinus Lab vì những nhận xét và phản hồi quý giá của họ về bài viết này.
Chúng tôi đã dành 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 quá trình phát triển, chúng tôi đã thử nghiệm và sử dụng một số 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á Hiệu suất Phát triển Bằng chứng Không Kiến thức "Patheon", một sáng kiến cộng đồng vì lợi ích công cộng. Bước khởi đầu này sẽ khuyến khích cộng đồng chia sẻ kết quả kiểm tra hiệu suất có thể tái tạo cho các khuôn khổ ZKP khác nhau. Mục tiêu cuối cùng của chúng tôi là cùng nhau tạo ra và duy trì một nền tảng đánh giá hiệu suất được công nhận rộng rãi để đánh giá các khuôn khổ phát triển mạch cấp thấp, máy ảo zkVM và trình biên dịch cấp cao, và thậm chí cả các nhà cung cấp dịch vụ tăng tốc phần cứng. Chúng tôi hy vọng sáng kiến này sẽ cung cấp cho các nhà phát triển một tài liệu tham khảo rộng hơn để so sánh hiệu suất khi lựa chọn khuôn khổ, từ đó đẩy nhanh việc áp dụng ZKP. Hơn nữa, bằng cách cung cấp một bộ kết quả kiểm tra hiệu suất có thể truy cập phổ biến, chúng tôi hy vọng sẽ khuyến khích việc nâng cấp và lặp lại các khuôn khổ ZKP. Chúng tôi cam kết sâu sắc với 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: 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 những bước đầu tiên hướng tới việc xây dựng ZKP Patheon bằng cách cung cấp một bộ kết quả kiểm tra hiệu suất có thể tái tạo được sử dụng SHA-256 trên nhiều nền tảng phát triển mạch cấp thấp. Mặc dù chúng tôi thừa nhận rằng các mức độ chi tiết và nguyên hàm kiểm tra hiệu suất khác có thể khả thi, chúng tôi đã chọn SHA-256 vì tính ứng dụng của nó trong nhiều trường hợp sử dụng ZKP, bao gồm hệ thống blockchain, chữ ký số, zkDID, v.v. Cũng cần lưu ý rằng chúng tôi sử dụng SHA-256 trong chính hệ thống của mình, vì vậy đây cũng là một lựa chọn thuận tiện cho chúng tôi! 😂
Tiêu chuẩn của chúng tôi đánh giá hiệu suất của SHA-256 trên các nền tảng phát triển mạch zk-SNARK và zk-STARK khác nhau. Thông qua so sánh này, chúng tôi mong muốn 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 thực tiễn của từng nền tảng. Mục tiêu của chúng tôi là những phát hiện này sẽ giúp các nhà phát triển đưa ra quyết định sáng suốt khi lựa chọn nền tảng phù hợp nhất cho dự án của mình.
Thử nghiệm hiệu năng của chúng tôi đã đánh giá hiệu năng của SHA-256 trên nhiều nền tảng khác nhau để phát triển mạch zk-SNARK và zk-STARK. Bằng cách so sánh các nền tảng này, chúng tôi mong muốn 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 thực tiễn của từng nền tảng. Mục tiêu của chúng tôi là cung cấp cho các nhà phát triển những hiểu biết sâu sắc để giúp họ đưa ra quyết định sáng suốt khi lựa chọn nền tảng tối ưu.
Hệ thống chứng minh
Trong những năm gần đây, chúng tôi đã chứng kiến sự gia tăng đột biến của các hệ thống chứng minh không kiến thức. Mặc dù 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, chúng tôi đã cẩn thận lựa chọn các hệ thống chứng minh sau đây để thử nghiệm dựa trên mức độ hoàn thiện và khả năng ứng dụng của các 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 front-end/back-end khác nhau.
Circom + snarkjs / rapidsnark: Circom là một DSL phổ biến để viết mạch và tạo ràng buộc R1CS, trong khi snarkjs có thể tạo bằng chứng Groth16 hoặc Plonk cho Circom. Rapidsnark cũng là một trình chứng minh (proverer) cho Circom, tạo bằng chứng Groth16 và nhìn chung nhanh hơn snarkjs rất nhiều nhờ sử dụng phần mở rộng ADX, cho phép song song hóa việc tạo bằng chứng bất cứ khi nào có thể.
gnark: gnark là một framework Golang toàn diện từ Consensys hỗ trợ Groth16, Plonk và nhiều tính năng nâng cao khác.
Arkworks: Arkworks là một framework Rust toàn diện dành cho zk-SNARK.
Halo2 (KZG): Halo2 là một triển khai zk-SNARK của Zcash và Plonk. Nó đi kèm với thuật toán Plonkish cực kỳ linh hoạt và hỗ trợ nhiều hàm nguyên thủy hữu ích, chẳng hạn như cổng tùy chỉnh và bảng tra cứu. Chúng tôi sử dụng nhánh Halo2 của KZG, được hỗ trợ bởi Ethereum Foundation và Scroll.
Plonky2: Plonky2 là một triển khai SNARK dựa trên công nghệ PLONK và FRI của Polygon Zero. Plonky2 sử dụng trường Goldilocks nhỏ và hỗ trợ đệ quy hiệu quả. Trong các bài kiểm tra hiệu suất, chúng tôi nhắm mục tiêu 100 bit bảo mật suy đoán và sử dụng các tham số mang lại thời gian chứng minh tốt nhất cho bài 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 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à nền tảng STARK hiệu suất cao của Polygon Zero. Trong quá trình thử nghiệm hiệu suất, chúng tôi nhắm đến bảo mật 100 bit và sử dụng các tham số mang lại thời gian chứng minh tốt nhất. Cụ thể, chúng tôi đã sử dụng 90 truy vấn Merkle, hệ số khuếch đại 2x và thử thách bằng chứng công việc 10 bit.
Bảng sau đây tóm tắt các framework đã đề cập ở trên và các cấu hình liên quan được sử dụng trong quá trình kiểm tra hiệu suất của chúng tôi. Danh sách này không phải là danh sách đầy đủ, và chúng tôi cũng sẽ nghiên cứu thêm nhiều framework/kỹ thuật tiên tiến khác trong tương lai (ví dụ: Nova, GKR, Hyperplonk).
Xin lưu ý rằng những kết quả 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 sẽ xuất bản một bài viết riêng trong tương lai để đánh giá 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 khuôn khổ biên dịch IR (ví dụ: Noir, zkLLVM).
khung
Số học
thuật toán
Phạm vi số
Cấu hình khác
Circom + snarkjs / rapidsnark
R1CS
Groth16
BN254 vô hướng
ghê tởm
R1CS
Groth16
BN254 vô hướng
Arkworks
R1CS
Groth16
BN254 vô hướng
Halo2 (KZG)
Plonkish
KZG
BN254 vô hướng
Plonky2
Plonk
Thứ sáu
Cô bé tóc vàng
hệ số thổi phồng = 8
bằng chứng công việc bit = 16
vòng truy vấn = 28
số_dây_=60 số_dây_định_tuyến=60
Starks
KHÔNG KHÍ
Thứ sáu
Cô bé tóc vàng
hệ số thổi phồng = 2
bằng chứng công việc bit = 10
vòng truy vấn = 90
Phương pháp đánh giá hiệu suất
Để thực hiện các bài kiểm tra hiệu năng trên 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 đó mạch lặp lại phép tính SHA-256 cho đầu vào 64 byte cố định, nhưng vẫn duy trì tổng số khối thông báo như cũ). Mã hiệu năng và cấu hình mạch SHA-256 có thể được tìm thấy trong kho lưu trữ này.
Ngoài ra, chúng tôi đã thực hiện các bài kiểm tra hiệu suất trên từng hệ thống bằng cách sử dụng các số liệu hiệu suất sau:
Thời gian tạo bằng chứng (bao gồm thời gian tạo bằng chứng)
Tăng đột biến mức sử dụng bộ nhớ trong quá trình tạo bằng chứng
Tỷ lệ phần trăm trung bình sử dụng CPU trong quá trình tạo chứng thực. (Chỉ số này phản ánh mức độ song song hóa trong quá trình tạo chứng thực)
Xin lưu ý rằng chúng tôi đang đưa ra một số giả định "tùy ý" về quy mô 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 lên chuỗi.
máy móc
Chúng tôi đã thực hiện các bài kiểm tra 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 M1 Pro: 10 lõi @ 3,2 GHz, RAM 16 GB
Máy chủ Linux được sử dụng để mô phỏng một kịch bản với nhiều lõi CPU và bộ nhớ lớn. Macbook M1 Pro, thường được sử dụng cho mục đích R&D, có CPU mạnh hơn nhưng ít lõi hơn.
Chúng tôi đã bật tùy chọn đa luồng, nhưng không sử dụng khả năng tăng tốc GPU trong bài kiểm tra hiệu năng này. Chúng tôi dự định sẽ thực hiện kiểm tra hiệu năng GPU trong tương lai.
Kết quả đánh giá hiệu suất
Số lượng ràng buộc
Trước khi đi sâu vào kết quả kiểm tra hiệu năng chi tiết, trước tiên chúng ta cần hiểu rõ độ 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 lược đồ số học khác nhau.
Kết quả bên dưới áp dụng cho 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 ảnh gốc khác, nhưng chúng được chia 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, và số lượng ràng buộc R1CS cho phép tính SHA-256 64KB 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 thuật toán Plonkish, trong đó số hàng dao độ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, trong đó việc thực hiện bảng theo dõi cần 2^16 bước chuyển đổi.
Hệ thống chứng minh
Số lượng ràng buộc (64KB SHA-256)
Circom
32 triệu
ghê tởm
45 triệu
Arkworks
43 triệu
Halo 2
4M hàng (K=22)
Plonky2
8 triệu hàng (K=23)
Starks
2^16 bước chuyển tiếp
Thời gian tạo bằng chứng
[Hình 1] Chúng tôi đã kiểm tra thời gian tạo bằng chứng cho từng khung SHA-256 trên nhiều kích thước ảnh gốc khác nhau bằng máy chủ Linux. Chúng tôi nhận thấy kết quả như sau:
Đối với SHA-256, các framework Groth16 (rapidsnark, gnark và Arkworks) tạo ra các bằng chứng nhanh hơn các framework Plonk (Halo2 và Plonky2). Điều này là do SHA-256 chủ yếu bao gồm các phép toán bitwise, trong đó giá trị wire là 0 hoặc 1. Đối với Groth16, điều này giúp giảm phần lớn khối lượng tính toán từ phép nhân vô hướng đường cong elliptic sang phép cộng điểm đường cong elliptic. Tuy nhiên, giá trị wire không được sử dụng trực tiếp trong các phép tính Plonk, do đó cấu trúc wire đặc biệt trong SHA-256 không làm giảm khối lượng tính toán cần thiết trong framework Plonk.
Trong số tất cả các framework Groth16, gnark và rapidsnark nhanh hơn Arkworks và snarkjs từ 5 đến 10 lần. Điều này là do khả năng song song hóa việc tạo bằng chứng trên nhiều lõi vượt trội. Gnark nhanh hơn rapidsnark 25%.
Đối với nền tảng Plonk, SHA-256 của Plonky2 chậm hơn 50% so với Halo2 khi sử dụng kích thước tiền ảnh lớn hơn >= 4KB. Điều này là do việc triển khai Halo2 chủ yếu sử dụng bảng tra cứu để tăng tốc các phép toán bitwise, dẫn đến số dòng ít hơn gấp đôi so với Plonky2. Tuy nhiên, nếu so sánh Plonky2 và Halo2 với cùng số dòng (ví dụ: SHA-256 trên 2KB trong Halo2 so với SHA-256 trên 4KB trong Plonky2), Plonky2 nhanh hơn Halo2 50%. Nếu triển khai SHA-256 bằng bảng tra cứu trong Plonky2, chúng ta có thể kỳ vọng Plonky2 sẽ nhanh hơn Halo2, mặc dù kích thước bằng chứng của Plonky2 lớn hơn.
Mặt khác, khi kích thước tiền ảnh đầu vào nhỏ (<=512 byte), Halo2 chậm hơn Plonky2 (và các nền tảng khác) do chi phí thiết lập cố định của bảng tra cứu chi phối ràng buộc. Tuy nhiên, khi kích thước tiền ảnh tăng lên, hiệu suất của Halo2 trở nên cạnh tranh hơn, với thời gian tạo bằng chứng được giữ nguyên cho kích thước tiền ảnh lên đến 2KB, và tỷ lệ gần như tuyến tính như thể hiện trong hình.
Đúng như dự kiế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ỳ khuôn khổ SNARK nào, nhưng phải trả giá bằng kích thước bằng chứng lớn hơn.
Ngoài ra, 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 lại tỷ lệ siêu tuyến tính do FFT O(nlogn) (mặc dù điều này không rõ ràng trên đồ thị do tỷ lệ logarit).
Chúng tôi cũng đã thực hiện thử nghiệm hiệu suất thời gian tạo chứng thực trên Macbook M1 Pro, như thể hiện 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 suất này do không hỗ trợ kiến trúc ARM64. Để sử dụng SnarkJS trên ARM64, chúng tôi phải tạo chứng thực bằng WebAssembly, chậm hơn so với việc tạo chứng thực bằng C++ 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 M1 Pro:
Tất cả các framework SNARK, ngoại trừ Starky, đều gặp 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 tiền ảnh tăng lên. Cụ thể, các framework Groth16 (snarkjs, gnark và Arkworks) bắt đầu sử dụng bộ nhớ hoán đổ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, và Plonky2 bắt đầu sử dụng bộ nhớ hoán đổi khi kích thước tiền ảnh >= 8KB.
Các framework dựa trên FRI (Starky và Plonky2) nhanh hơn khoảng 60% trên Macbook M1 Pro so với trên máy chủ Linux, trong khi các framework khác đạt được thời gian chứng minh tương tự trên cả hai máy. Do đó, mặc dù Plonky2 không sử dụng bảng tra cứu, nhưng nó đạt được thời gian chứng minh gần như giống hệt Halo2 trên Macbook M1 Pro. Điều này chủ yếu 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 băm, vốn nhạy cảm hơn với chu kỳ xung nhịp CPU và kém khả năng song song hóa hơn KZG hoặc Groth16.
Sử dụng bộ nhớ đỉnh
Hình 3 và 4 cho thấy mức sử dụng bộ nhớ cao nhất trong quá trình tạo chứng thực trên Máy chủ Linux và Macbook M1 Pro. Có thể đưa ra những nhận xét sau dựa trên kết quả kiểm tra hiệu năng này:
Trong số tất cả các framework SNARK, rapidsnark là framework tiết kiệm bộ nhớ nhất. Chúng ta cũng thấy rằng Halo2 sử dụng nhiều bộ nhớ hơn khi kích thước tiền ảnh nhỏ do chi phí thiết lập bảng tra cứu cố định, nhưng lại tiêu thụ ít bộ nhớ hơn khi kích thước tiền ảnh lớn.
Starky có hiệu suất sử dụng bộ nhớ cao hơn 10 lần so với các nền tảng SNARK, một phần là do nó sử dụng ít hàng hơn.
Cần lưu ý rằng mức sử dụng bộ nhớ tối đa trên Macbook M1 Pro vẫn tương đối ổn định do kích thước ảnh trước lớn hơn khi sử dụng bộ nhớ hoán đổi.
Sử dụng CPU
Chúng tôi đã đánh giá mức độ song song hóa của từng hệ thống chứng minh bằng cách đo mức sử dụng CPU trung bình trong quá trình tạo chứng minh cho SHA-256 với đầu vào tiền ảnh 4KB. Bảng sau đây hiển thị mức sử dụng CPU trung bình trên Máy chủ Linux (20 lõi) và Macbook M1 Pro (10 lõi) (mức sử dụng trung bình trên mỗi lõi được hiển thị trong ngoặc đơn).
Những quan sát chính như sau:
Gnark và rapidsnark cho thấy mức sử dụng CPU cao nhất trên máy chủ Linux, chứng minh khả năng sử dụng hiệu quả nhiều lõi và song song hóa việc tạo bằng chứng. Halo2 cũng cho thấy hiệu suất song song hóa tốt.
Hầu hết các framework đều sử dụng CPU gấp đôi trên máy chủ Linux so với Macbook Pro M1, ngoại trừ snarkjs.
Mặc dù ban đầu người ta dự đoán rằng các framework dựa trên FRI (Plonky2 và Starky) có thể gặp khó khăn khi sử dụng hiệu quả nhiều lõi, nhưng chúng không hề kém hơn một số framework Groth16 hoặc KZG trong các bài kiểm tra hiệu năng của chúng tôi. Vẫn chưa rõ liệu có sự khác biệt nào về hiệu suất sử dụng CPU trên các máy có nhiều lõi hơn (ví dụ: 100 lõi) hay không.
Hệ thống chứng minh
Sử dụng CPU (sử dụng trung bình trên mỗi lõi)
(Máy chủ Linux)
Sử dụng CPU (sử dụng trung bình trên mỗi lõi)
(MBP M1)
snarkjs
557% (27,85%)
486% (48,6%)
thác ghềnh
1542% (77,1%)
Không có
ghê tởm
1624% (81,2%)
720% (72%)
Arkworks
935% (46,75%)
504% (50,4%)
Halo2 (KZG)
1227% (61,35%)
588% (58,8%)
Plonky2
892% (44,6%)
429% (42,9%)
Starks
849% (42,45%)
335% (33,5%)
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 hiệu suất của SHA-256 trên nhiều nền tảng phát triển zk-SNARK và zk-STARK. So sánh này cung cấp thông tin chi tiết về hiệu quả và tính thực tiễn của từng nền tảng, hy vọng sẽ 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 nền tảng Groth16 (ví dụ: rapidsnark, gnark) tạo bằng chứng nhanh hơn các nền tảng Plonk (ví dụ: Halo2, Plonky2). Bảng tra cứu trong số học Plonkish làm giảm đáng kể thời gian ràng buộc và chứng minh SHA-256 khi sử dụng kích thước tiền ảnh lớn hơn. Hơn nữa, gnark và rapidsnark chứng minh khả năng tuyệt vời trong việc tận dụng song song hóa đa lõi. Mặt khác, Starky đạt được thời gian tạo bằng chứng nhanh hơn đáng kể, nhưng phải trả giá bằng kích thước bằng chứng lớn hơn đáng kể. Rapidsnark và Starky vượt trội hơn các nền tảng khác về hiệu quả bộ nhớ.
Là bước đầu tiên hướng tới việc xây dựng nền tảng đánh giá hiệu năng không kiến thức Patheon, chúng tôi thừa nhận rằng những kết quả kiểm tra hiệu năng này còn lâu mới đủ cho nền tảng đánh giá toàn diện mà chúng tôi hướng tới. Chúng tôi hoan nghênh phản hồi và phê bình, đồng thời kêu gọi mọi người đóng góp cho sáng kiến này, giúp các chứng minh không kiến thức dễ tiếp cận hơn với các nhà phát triển. Chúng tôi cũng sẵn sàng tài trợ cho từng cá nhân đóng góp để trang trải các nguồn lực tính toán cần thiết cho việc kiểm tra hiệu năng quy mô lớn. Cùng nhau, chúng tôi hy vọng sẽ cải thiện hiệu quả và tính thực tiễn của ZKP vì lợi ích chung của cộng đồng.
Cuối cùng, chúng tôi muốn 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 quý báu của họ về kết quả kiểm tra hiệu suất.
