Celer: Điện Pantheon - Nền tảng đánh giá khung phát triển ZKP
Tuyển chọn TechFlowTuyển chọn TechFlow
Celer: Điện Pantheon - Nền tảng đánh giá khung phát triển ZKP
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.
Chuyên sâu báo cáo Web3
Trong vài tháng qua, chúng tôi đã dành rất nhiều thời gian và công sức để phát triển cơ sở hạ tầng tiên tiến được xây dựng dựa trên các bằng chứng ngắn gọn 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 những mô hình ứng dụng blockchain hoàn toàn 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 nhiều khung phát triển bằng chứng không kiến thức (ZKP). Mặc dù hành trình này rất bổ ích, nhưng chúng tôi cũng nhận ra rằng sự đa dạng của các khung ZKP thường gây khó khăn 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à yêu cầu hiệu suất của mình. Nhận thấy vấn đề này, chúng tôi cho rằng cần có một nền tảng đánh giá cộng đồng cung cấp kết quả kiểm tra hiệu suất toàn diện, điều này sẽ thúc đẩy mạnh mẽ 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 ZKP «Bàn thờ Pantheon», một sáng kiến cộng đồng phi lợi nhuận. Bước đầu tiên của sáng kiến sẽ khuyến khích cộng đồng chia sẻ các kết quả kiểm tra hiệu suất có thể tái hiện từ nhiều khung 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 kiểm tra được công nhận rộng rãi, đánh giá các khung phát triển mạch cấp thấp, máy ảo zkVM cấp cao, trình biên dịch và thậm chí cả các nhà cung cấp tăng tốc phần cứng. Chúng tôi hy vọng sáng kiến này sẽ giúp các nhà phát triển có thêm tham chiếu so sánh hiệu suất khi lựa chọn khung làm việc, từ đó đẩy nhanh quá trình phổ biến ZKP. Đồng thời, thông qua việc 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 mong muốn thúc đẩy việc nâng cấp và lặp lại chính các khung ZKP. Chúng tôi sẽ đầu tư mạnh vào kế hoạch này và mời tất cả thành viên cộng đồng có cùng chí hướng tham gia đóng góp!
Bước đầu tiên: Kiểm tra hiệu suất khung mạch dùng SHA-256
Trong bài viết này, chúng tôi thực hiện bước đầu tiên trong việc 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 hiện cho chuỗi các khung phát triển mạch cấp thấp sử dụng thuật toán SHA-256. Dù thừa nhận rằng các mức độ kiểm tra hiệu suất và nguyên thủy khác cũng khả thi, 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 blockchain, chữ ký số, zkDID, v.v.
Thêm nữa, đáng chú ý là chúng tôi cũng đang sử dụng SHA-256 trong hệ thống riêng của mình, nên điều này khá thuận tiện cho chúng tôi! 😂
Kiểm thử hiệu suất của chúng tôi đánh giá hiệu năng của 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 nhằm mục đích cung cấp cái nhìn sâu sắc về hiệu quả và tính thực tiễn của mỗi khung cho các nhà phát triển. Mong rằng kết quả kiểm thử này sẽ giúp các nhà phát triển tham khảo khi lựa chọn khung tối ưu và đưa ra quyết định sáng suốt.
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ự bùng nổ của các hệ thống bằng chứng không kiến thức. Việ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, do đó chúng tôi đã lựa chọn cẩn thận các hệ thống sau đây dựa trên mức độ trưởng thành và mức độ á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ột mẫu đại diện cho các tổ hợp frontend/backend khác nhau.
-
Circom + snarkjs / rapidsnark: Circom là một ngôn ngữ DSL phổ biến để viết mạch và sinh 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 tạo bằng chứng cho Circom, tạo bằng chứng Groth16 và thường nhanh hơn nhiều so với snarkjs nhờ sử dụng mở rộng ADX, đồng thời cố gắng song song hóa việc tạo bằng chứng tối đa.
-
gnark: gnark là một khung Golang toàn diện từ Consensys, hỗ trợ Groth16, Plonk và nhiều tính năng cao cấp hơn.
-
Arkworks: Arkworks là một khung Rust toàn diện dành cho zk-SNARKs.
-
Halo2 (KZG): Halo2 là triển khai zk-SNARK của Zcash dựa trên Plonk. Nó đi kèm với số học Plonkish cực kỳ linh hoạt, 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 bản phân nhánh Halo2 với KZG được hỗ trợ bởi Ethereum Foundation và Scroll.
-
Plonky2: Plonky2 là triển khai SNARK dựa trên công nghệ PLONK và FRI từ Polygon Zero. Plonky2 sử dụng trường Goldilocks nhỏ và hỗ trợ đệ quy hiệu quả. Trong kiểm thử hiệu suất, chúng tôi nhắm đến độ an toàn suy đoán 100 bit và sử dụng các tham số mang lại thời gian tạo bằng chứng tốt nhất cho công việc kiểm thử. Cụ thể, chúng tôi dùng 28 truy vấn Merkle, hệ số khuếch đại 8 và thách thức proof-of-work 16 bit. Ngoài ra, chúng tôi đặt num_of_wires = 60 và num_routed_wires = 60.
-
Starky: Starky là khung STARK hiệu suất cao từ Polygon Zero. Trong kiểm thử hiệu suất, chúng tôi nhắm đến độ an toàn suy đoán 100 bit và sử dụng các tham số mang lại thời gian tạo bằng chứng tốt nhất. Cụ thể, chúng tôi dùng 90 truy vấn Merkle, hệ số khuếch đại 2 lần và thách thức proof-of-work 10 bit.
Bảng dưới đây tóm tắt các khung nêu trên cùng các cấu hình liên quan mà chúng tôi dùng trong kiểm thử hiệu suất. Danh sách này không đầy đủ, và chúng tôi sẽ nghiên cứu thêm nhiều khung/công nghệ tiên tiến khác (ví dụ: Nova, GKR, Hyperplonk) trong tương lai.
Lưu ý rằng các kết quả kiểm thử hiệu suất này chỉ áp dụng cho các khung phát triển mạch. Chúng tôi dự định xuất bản một bài báo riêng trong tương lai để kiểm tra hiệu suất 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 luận đánh giá hiệu suất
Để kiểm thử hiệu suất các hệ thống bằng chứng khác nhau này, chúng tôi tính toán giá trị băm SHA-256 của dữ liệu N byte, trong đó chúng tôi thử nghiệm với N = 64, 128, ..., 64K (trừ Starky, nơi mạch lặp lại việc tính toán SHA-256 với đầu vào cố định 64 byte nhưng giữ tổng số khối tin nhắn không đổi). Mã hiệu suất và cấu hình mạch SHA-256 có thể tìm thấy tại kho lưu trữ này.
Ngoài ra, chúng tôi sử dụng các chỉ số hiệu suất sau để kiểm thử từng hệ thống:
-
Thời gian tạo bằng chứng (bao gồm thời gian tạo chứng cứ)
-
Sử dụng bộ nhớ đỉnh điểm 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 bằng chứng. (Chỉ số này phản ánh mức độ song song hóa trong quá trình tạo bằng chứng)
Lưu ý rằng chúng tôi đang đưa ra một số giả định "tùy tiện" về kích thước bằng chứng và chi phí xác minh bằng chứng, vì các khía cạnh này có thể được giảm nhẹ bằng cách kết hợp với Groth16 hoặc KZG trước khi đăng lên chuỗi.
Máy móc
Chúng tôi thực hiện kiểm thử hiệu suất trên hai máy khác nhau:
-
Máy chủ Linux: 20 nhân @2.3 GHz, 384GB RAM
-
Macbook M1 Pro: 10 nhân @3.2GHz, 16GB RAM
Máy chủ Linux được dùng để mô phỏng kịch bản có nhiều nhân CPU và dung lượng bộ nhớ dồi dào. Trong khi đó, Macbook M1 Pro thường được dùng cho phát triển lại có CPU mạnh hơn nhưng ít nhân hơn.
Chúng tôi đã bật đa luồng tùy chọn, nhưng không sử dụng tăng tốc GPU trong kiểm thử hiệu suất này. Chúng tôi dự định thực hiện kiểm thử hiệu suất 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 các kết quả kiểm thử chi tiết, việc xem xét số lượng ràng buộc trong mỗi hệ thống bằng chứng để hiểu độ phức tạp của SHA-256 là rất hữu ích. Cần lưu ý rằng không thể so sánh trực tiếp số lượng ràng buộc giữa các sơ đồ số học khác nhau.
Các kết quả dưới đây tương ứng với kích thước ảnh gốc 64KB. Mặc dù kết quả có thể khác biệt với các kích thước ảnh gốc khác, chúng có thể thay đổi tỷ lệ tuyến tính một cách thô sơ.
-
Circom, gnark, Arkworks đều sử dụng thuật toán R1CS giống nhau, số lượng ràng buộc R1CS để tính toán SHA-256 64KB nằm trong khoảng từ 30 triệu đến 45 triệu. Sự khác biệt giữa Circom, gnark và Arkworks có thể là do sự khác nhau về cấu hình.
-
Halo2 và Plonky2 đều sử dụng số học Plonkish, với số hàng dao động từ 2^22 đến 2^23. Nhờ sử dụng bảng tra cứu, việc triển khai SHA-256 của Halo2 hiệu quả hơn nhiều so với Plonky2.
-
Starky sử dụng thuật toán AIR, trong đó bảng theo dõi thực thi cần 2^16 bước chuyển đổi.
Thời gian tạo bằng chứng
[Hình 1] kiểm tra thời gian tạo bằng chứng của từng khung đối với SHA-256 trên các kích thước ảnh gốc khác nhau bằng máy chủ Linux. Chúng tôi rút ra các nhận xét sau:
-
Đối với SHA-256, các khung Groth16 (rapidsnark, gnark và Arkworks) tạo bằng chứng nhanh hơn các khung Plonk (Halo2 và Plonky2). Điều này là do SHA-256 chủ yếu gồm các phép toán bit, trong đó giá trị dây nối là 0 hoặc 1. Với Groth16, điều này làm giảm đáng kể tính toán từ phép nhân vô hướng đường cong elliptic xuống phép cộng điểm đường cong elliptic. Tuy nhiên, giá trị dây nối không được dùng trực tiếp trong tính toán Plonk, do đó cấu trúc dây nối đặc biệt trong SHA-256 không làm giảm lượng tính toán cần thiết trong các khung Plonk.
-
Trong 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 nhờ khả năng tuyệt vời trong việc tận dụng nhiều nhân để song song hóa việc tạo bằng chứng. Gnark nhanh hơn rapidsnark 25%.
-
Đối với các khung Plonk, khi sử dụng kích thước ảnh gốc lớn (>= 4KB), SHA-256 của Plonky2 chậm hơn 50% so với của Halo2. Điều này là do triển khai của Halo2 chủ yếu dùng bảng tra cứu để tăng tốc các phép toán bit, dẫn đến số hàng ít hơn 2 lần so với Plonky2. Tuy nhiên, nếu so sánh Plonky2 và Halo2 với cùng số hàng (ví dụ: SHA-256 trên 2KB trong Halo2 so với trên 4KB trong Plonky2), Plonky2 nhanh hơn Halo2 50%. Nếu chúng ta triển khai SHA-256 bằng bảng tra cứu trong Plonky2, ta nên 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 ảnh gốc nhỏ (<=512 byte), 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, Halo2 chậm hơn Plonky2 (và các khung khác). Tuy nhiên, khi kích thước ảnh gốc tăng lên, hiệu suất của Halo2 trở nên cạnh tranh hơn, và thời gian tạo bằng chứng của nó ổn định với kích thước ảnh gốc lên tới 2KB, gần như mở rộng tuyến tính như biểu đồ cho thấy.
-
Như dự kiến, thời gian tạo bằng chứng của Starky ngắn hơn nhiều so với bất kỳ khung SNARK nào (5-50 lần), nhưng đổi lại là kích thước bằng chứng lớn hơn đáng kể.
-
Cần lưu ý thêm rằng, mặc dù kích thước mạch tỷ lệ tuyến tính với kích thước ảnh gốc, việc tạo bằng chứng cho SNARKs tăng trưởng 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 log).
Chúng tôi cũng thực hiện kiểm thử thời gian tạo bằng chứng trên Macbook M1 Pro như [Hình 2]. Tuy nhiên, cần lưu ý rằng do thiếu hỗ trợ cho kiến trúc arm64, rapidsnark không được bao gồm trong kiểm thử này. Để dùng snarkjs trên arm64, chúng tôi phải dùng webassembly để tạo chứng cứ, điều này chậm hơn so với việc dùng C++ trên máy chủ Linux.
Có thêm một vài nhận xét khi chạy kiểm thử trên Macbook M1 Pro:
-
Ngoại trừ Starky, tất cả các khung SNARK đều gặp lỗi hết bộ nhớ (OOM) hoặc bắt đầu dùng bộ nhớ swap (gây chậm thời gian tạo bằng chứng) khi kích thước ảnh gốc tăng. Cụ thể, các khung Groth16 (snarkjs, gnark, Arkworks) bắt đầu dùng swap khi kích thước ảnh gốc >= 8KB, và gnark gặp OOM khi >= 64KB. Halo2 chạm giới hạn bộ nhớ khi kích thước ảnh gốc >= 32KB. Plonky2 bắt đầu dùng swap khi kích thước ảnh gốc >= 8KB.
-
Các khung dựa trên FRI (Starky và Plonky2) chạy nhanh hơn khoảng 60% trên Macbook M1 Pro so với trên máy chủ Linux, trong khi các khung khác có thời gian tạo bằng chứng tương tự trên cả hai máy. Do đó, ngay cả khi không dùng bảng tra cứu, Plonky2 đạt được thời gian tạo bằng chứng gần như bằng 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 nhân hơn. FRI chủ yếu thực hiện các phép băm, nhạy cảm với chu kỳ đồng hồ CPU, nhưng mức độ song song hóa thấp hơn KZG hay Groth16.
Sử dụng bộ nhớ đỉnh điểm
[Hình 3] và [Hình 4] lần lượt hiển thị mức sử dụng bộ nhớ đỉnh điểm trong quá trình tạo bằng chứng trên Máy chủ Linux và Macbook M1 Pro. Từ các kết quả kiểm thử này, ta rút ra các nhận xét sau:
-
Trong tất cả các khung SNARK, rapidsnark là hiệu quả bộ nhớ 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 ảnh gốc nhỏ, nhưng tiêu thụ tổng thể ít hơn khi kích thước lớn.
-
Starky hiệu quả bộ nhớ hơn các khung SNARK từ 10 lần trở lên. Một phần là do nó dùng ít hàng hơn.
-
Cần lưu ý rằng do việc dùng bộ nhớ swap, khi kích thước ảnh gốc tăng, mức sử dụng bộ nhớ đỉnh điểm trên Macbook M1 Pro giữ tương đối ổn định.
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 tỷ lệ sử dụng CPU trung bình trong quá trình tạo bằng chứng SHA-256 với đầu vào ảnh gốc 4KB. Bảng dưới đây cho thấy tỷ lệ sử dụng CPU trung bình trên Máy chủ Linux (20 nhân) và Macbook M1 Pro (10 nhân) (phần trong ngoặc là tỷ lệ trung bình mỗi nhân).
Các nhận xét chính như sau:
-
Gnark và rapidsnark thể hiện mức sử dụng CPU cao nhất trên máy chủ Linux, cho thấy khả năng sử dụng hiệu quả nhiều nhân và song song hóa việc tạo bằng chứng. Halo2 cũng thể hiện hiệu suất song song hóa tốt.
-
Hầu hết các khung có mức sử dụng CPU trên máy chủ Linux gấp đôi so với trên Macbook Pro M1, ngoại trừ snarkjs.
-
Mặc dù ban đầu dự đoán các khung dựa trên FRI (Plonky2 và Starky) có thể khó sử dụng hiệu quả nhiều nhân, nhưng trong kiểm thử của chúng tôi, chúng không thua kém các khung Groth16 hoặc KZG nào. Liệu hiệu suất có khác biệt trên máy có nhiều nhân hơn (ví dụ 100 nhân) vẫn cần quan sát thêm.
Kết luận và hướng nghiên cứu tương lai
Bài viết này so sánh toàn diện các kết quả kiểm thử hiệu suất của SHA-256 trên nhiều khung phát triển zk-SNARK và zk-STARK khác nhau. Qua so sánh, chúng tôi hiểu sâu hơn về hiệu quả và tính thực tiễn của từng khung, nhằm giúp các nhà phát triển cần tạo bằng chứng ngắn gọn cho thao tác SHA-256.
Chúng tôi nhận thấy các khung Groth16 (ví dụ rapidsnark, gnark) nhanh hơn các khung Plonk (ví dụ Halo2, Plonky2) trong việc tạo bằng chứng. Bảng tra cứu trong số học Plonkish làm giảm đáng kể ràng buộc và thời gian tạo bằng chứng của SHA-256 khi dùng ảnh gốc lớ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 nhân để vận hành song song. Mặt khác, Starky có thời gian tạo bằng chứng ngắn hơn nhiều nhưng đổi lại là kích thước bằng chứng lớn hơn đáng kể. Về hiệu quả bộ nhớ, rapidsnark và Starky vượt trội hơn các khung khác.
Là bước đầu tiên trong việc xây dựng nền tảng đánh giá ZKP «Bàn thờ Pantheon», chúng tôi thừa nhận rằng kết quả kiểm thử này còn xa mới đủ để trở thành nền tảng kiểm tra toàn diện mà chúng tôi mong muốn xây dựng. Chúng tôi hoan nghênh và sẵn sàng đón nhận phản hồi, phê bình, và mời mọi người đóng góp cho sáng kiến này để việc sử dụng bằng chứng không kiến thức trở nên dễ dàng và ít rào cản hơn cho các nhà phát triển. Chúng tôi cũng sẵn sàng tài trợ cho các cá nhân đóng góp độc lập để chi trả chi phí tài nguyên tính toán cho các kiểm thử quy mô lớn. Chúng tôi hy vọng có thể cùng nhau nâng cao hiệu quả và tính thực tiễn của ZKP, 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 chân thành cảm ơn đội ngũ Polygon Zero, đội ngũ gnark từ Consensys, Pado Labs và đội ngũ Delphinus Lab vì những đánh giá và phản hồi quý giá về kết quả kiểm thử hiệu suất.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
