Phê phán "môn học nổi bật" trong lĩnh vực mã hóa - Chứng minh không kiến thức (ZKP)
Tuyển chọn TechFlowTuyển chọn TechFlow
Phê phán "môn học nổi bật" trong lĩnh vực mã hóa - Chứng minh không kiến thức (ZKP)
Hệ thống ZK có thể cần được sử dụng cùng với các công cụ an toàn như xác minh hình thức hoặc các công cụ liên quan đến an toàn khác như Ecne.
Chuyên sâu báo cáo Web3*Ghi chú: Trước hết, đây là bản nháp được viết trong vòng một giờ. Mục đích chủ yếu là thu thập thông tin nhanh chóng, do đó có thể tồn tại rất nhiều lỗi tiềm tàng và thông tin chưa đầy đủ.
Các chỉ trích chính đối với ZK bao gồm hai điểm:
-
Thứ nhất là thời gian tạo bằng chứng quá dài (do đó xuất hiện các benchmark khác nhau, các giao thức ZK mới và các tối ưu hóa phần cứng);
-
Thứ hai là độ an toàn của hệ thống và ứng dụng vẫn cần được kiểm nghiệm.
Hiệu suất sinh bằng chứng
Chứng minh kiến thức không (zero-knowledge proof) là công nghệ rất phổ biến trong lĩnh vực blockchain. Do tài nguyên tính toán trên chuỗi khan hiếm và đắt đỏ, chứng minh ZK cho phép thực hiện các phép tính này bên ngoài chuỗi; mặc dù tổng thời gian tạo bằng chứng bên ngoài chuỗi tiêu tốn rất lớn, nhưng nó vẫn nén bằng chứng cuối cùng và việc xác minh tính toán liên quan, từ đó cho phép tính toán “xảy ra trên chuỗi”.
Vấn đề thời gian tạo bằng chứng ZK quá lâu thường bị các nhà nghiên cứu và lập trình viên bỏ qua, vì về bản chất đây là sự đánh đổi mà ZK buộc phải chấp nhận.
Mặc dù họ không chỉ trích trực tiếp khuyết điểm này của ZK, nhưng họ đã đưa ra rất nhiều phương pháp và thảo luận nhằm giải quyết ngược lại vấn đề này.
Nói cách khác, họ ngầm bàn về thời gian tạo bằng chứng cực kỳ dài của ZK thông qua việc đề xuất nhiều giải pháp và thực hiện hàng loạt benchmark.
a) Benchmark
Trước khi đo hiệu suất ứng dụng ZK, trước tiên chúng ta cần kiểm tra hiệu suất của các cam kết cơ sở (commitment) dưới nền tảng giao thức ZK.
Ví dụ, FRI dẫn đến STARK, KZG dẫn đến SNARK thông thường, IPA dẫn đến Bulletproof. Việc kiểm tra hiệu suất của các cam kết cơ sở này tuy không trực quan đối với hiệu suất ứng dụng ZK, nhưng lại hữu ích để hiểu rõ vấn đề thời gian tạo bằng chứng dài của ZK.
Từ liên kết ở trên, ta thấy rằng các giao thức cam kết cơ sở này không chỉ phức tạp về tính toán (có thể dẫn đến thời gian tạo bằng chứng dài), mà còn tiêu tốn rất nhiều bộ nhớ.
Tất nhiên, mức tiêu thụ bộ nhớ nhiều hơn chủ yếu liên quan đến yêu cầu cấu hình phần cứng, điều này khác biệt so với chủ đề chúng ta đang thảo luận hôm nay.
Đối với các bài kiểm tra hiệu suất SNARK cụ thể, a16z crypto chia chúng thành phần đầu cuối (frontend) và phần hậu cuối (backend):
-
Phần đầu cuối thường là ngôn ngữ cấp cao như Cairo hoặc zkVM – những thứ mà lập trình viên ứng dụng ZK tiếp xúc;
-
Phần hậu cuối là các thao tác mật mã học cơ sở gần hơn với thời gian tạo bằng chứng SNARK, chẳng hạn như các cam kết.
Trong đó, tác giả đề cập rằng việc tạo bằng chứng SNARK có chi phí tính toán khoảng 100 lần, và mỗi giao thức ZK đều có chi phí bổ sung riêng, ví dụ:
“Trong Groth16, P phải làm việc trên nhóm hỗ trợ ghép nối (pairing-friendly group), các thao tác trên nhóm này thường chậm ít nhất 2 lần so với các nhóm không hỗ trợ ghép nối. Điều này dẫn đến việc chậm thêm ít nhất hệ số 6 so với ước lượng 100-|C| nêu trên.”
Nhìn chung, có thể nói rằng chi phí hiệu suất bổ sung của zk-SNARK nằm trong khoảng từ 200 đến 1000 lần.
Ngoài ra, bài viết cũng đề cập đến các hạn chế khác của zk-SNARK, ví dụ như thiết lập đáng tin cậy (trusted setup) và việc sử dụng bộ nhớ.
Bài viết của Modulus Labs đã đo hiệu suất thực tế của một số giao thức ZK. Một vài benchmark dựa trên số lượng tham số, điều này khá khó hình dung đối với chúng ta. Tuy nhiên, trong ứng dụng, bài viết đề cập rằng trong trường hợp sử dụng của Worldcoin, ngay cả khi dùng Plonky2 được coi là "nhanh nhất", vẫn cần vài phút để tạo bằng chứng và tiêu thụ hàng chục GB bộ nhớ, khiến việc chạy trên máy tính cá nhân là không khả thi.
b) Đệ quy và xử lý theo lô
Để giảm thời gian tạo bằng chứng, chúng ta có thể song song hóa việc tạo nhiều bằng chứng.
Thông thường, có hai cách thực hiện điều này: một là xử lý theo lô (batching), hai là đệ quy (recursion).
Nói đơn giản, xử lý theo lô là chứng minh đồng thời một nhóm bằng chứng rồi sau đó gộp chúng lại, trong khi đệ quy là xác minh các bằng chứng khác bên trong một bằng chứng. Nói chung, phương pháp đệ quy còn có lợi thế bổ sung là kích thước bằng chứng nhỏ hơn.
Một số phương pháp gộp phổ biến hơn bao gồm Halo2, Plonky2. Mỗi người thực hiện xử lý theo lô và đệ quy theo cách riêng, từ đó giảm thời gian tạo bằng chứng.
Ngoài lớp giao thức ZK, lớp ứng dụng ZK cũng có thể được tối ưu hóa định hướng. Ví dụ, có thể sử dụng đồng thời nhiều giao thức ZK (STARK + SNARK), hoặc áp dụng chiến lược đệ quy theo vĩ mô để tinh chỉnh theo từng ứng dụng cụ thể.
Nói chung, điều này thực tế làm giảm thời gian tạo bằng chứng về mặt phân bổ giao thức và bằng chứng. Khi khám phá các giao thức ZK mới, việc giảm thời gian tạo bằng chứng luôn là yếu tố cân nhắc quan trọng nhất.
c) Tăng tốc phần cứng
Ngoài ra, cũng có rất nhiều nỗ lực nhằm giảm thời gian tạo bằng chứng của ứng dụng ZK ở cấp độ vật lý và nút mạng từ góc độ phần cứng.
Đầu tiên, giống như các giao thức mới được đề cập ở trên, các giao thức ZK được thiết kế sao cho thân thiện nhất có thể với phần cứng, ví dụ như HyperPlonk.
Paradigm cho biết tốc độ tạo bằng chứng ZK chậm chủ yếu là do liên quan đến khối lượng lớn các phép MSM và FFT, vốn không thân thiện với phần cứng, dẫn đến việc tạo bằng chứng cuối cùng chậm do các vấn đề như truy cập bộ nhớ ngẫu nhiên. Đối với các phép tính mật mã cơ bản này, các giao thức ZK cần có sự cân nhắc nhất định về cấu thành và quy mô để trở nên thân thiện hơn với phần cứng.
Một số công ty tăng tốc phần cứng ZK cho biết GPU thực tế là lựa chọn phần cứng kinh tế và linh hoạt nhất hiện nay, và cuối cùng chúng ta sẽ chuyển từ FPGA sang giai đoạn ASIC. Theo các công ty phần cứng ZK, phiên bản ASIC đầu tiên của họ có thể giảm trực tiếp ít nhất 30% thời gian tạo bằng chứng ZK.
Hơn nữa, do cấu hình máy chủ khác nhau, việc sử dụng các máy chủ đám mây khác nhau làm nút có thể liên quan đến các tối ưu hóa đặc thù phần cứng khác nhau.
An toàn bảo mật
Một chỉ trích khác đối với ZK hiện nay là mã mạch (circuit code) vẫn phải đúng (không có lỗi).
Nếu giao thức ZK bị tấn công từ góc độ tính vững chắc (soundness), tính toàn vẹn (completeness) hay tính kiến thức không (zero-knowledge), thì chúng ta sẽ không còn hệ thống ZK hợp lệ nữa. Chúng ta có thể xem các ví dụ tấn công từ nhiều góc độ khác nhau tại liên kết này.
Mặc dù ứng dụng ZK có thể được gọi là không cần tin cậy (trustless), chúng ta vẫn cần đảm bảo rằng mã nguồn và kiến trúc của giao thức ZK và ứng dụng là chính xác. Trong lĩnh vực blockchain tồn tại nhiều lỗi ZK khác nhau. Ví dụ, do vấn đề cơ sở mã mạch ZK quá lớn trong zkEVM, Vitalik đã đề cập đến nhu cầu đa bên chứng minh (multi-prover) cho các ứng dụng ZK.
Do đó, hệ thống ZK có thể cần kết hợp với các công cụ an toàn như kiểm chứng hình thức (formal verification) hoặc các công cụ liên quan đến an toàn khác như Ecne. Ở cấp độ ứng dụng, cần có nhiều cuộc kiểm toán hơn, đặc biệt là với các dự án lớn như zkEVM.
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
msfew / Suning Yao
