Một lỗ đen trong bytecode mà tự tay đào ra.
Hôm qua, CNBC đưa tin Apple đang đàm phán với một startup tên ZKPrism. Cái tên lạ hoắc, không ai biết, nhưng con số họ khoe thì không lạ: nén zk-proof xuống 10-15 lần, chạy zkEVM full 270 triệu gas trên iPhone, tốc độ nhanh gấp 6-8 lần, điện năng giảm 3-6 lần. Nghe quen không? PrismML của thế giới AI đó, nhưng lần này là blockchain. Và tôi, một kẻ đã từng debug Circom cả tháng trời vì một ràng buộc thừa, chỉ muốn cười: thêm một lỗ đen nữa trong bytecode mà chưa ai đào thử.
Context: Cơn khát zk-proofs di động
zkEVM là giấc mơ của mọi rollup: xác thực giao dịch trên thiết bị người dùng mà không cần tin tưởng sequencer. Nhưng proof generation là gánh nặng khủng khiếp. Một proof cho block 10 triệu gas trên Scroll mất 2 phút trên GPU A100, tốn 3-5 USD điện. Trên iPhone? Chưa ai dám thử vì RAM chỉ 8GB, NPU tối đa 35 TOPS. ZKPrism tuyên bố giải quyết được: họ có một phương pháp nén proof gọi là “snark aggregation với polynomial commitment kiểu mới”, giảm kích thước proof từ 200KB xuống 15KB, đồng thời giảm bộ nhớ cần để verify. Nếu đúng, đây là bước ngoặt: người dùng có thể tự verify tính hợp lệ của toàn bộ chain trên điện thoại, không cần gửi dữ liệu lên cloud. Apple, với nỗi ám ảnh privacy, thấy ngay cơ hội.
Core: Phân tích code và trade-offs
1. Nén 15 lần? Có lý nhưng rất khó.
Các zk-proof hiện tại (Groth16, Plonk) có kích thước ~200-300 bytes cho một statement đơn lẻ. Nhưng proof tổng hợp (aggregation) như Halo2 hay Nova có thể gộp nhiều proof, nhưng kích thước tăng tuyến tính theo số proof. ZKPrism nói họ đạt 15x nén so với Plonk tiêu chuẩn tức là đưa từ 200 bytes xuống ~13 bytes? Vô lý. Thực tế họ có thể đang nói về kích thước proof tổng hợp cho một zkEVM block: một block có hàng ngàn transaction, proof tổng hợp hiện tại của Polygon zkEVM là ~500KB. Nếu nén 15x còn ~33KB, khả thi hơn. Nhưng chưa có benchmark công bố. Tôi từng thử nghiệm với Circom và snarkJS: để verify một proof 500KB trên iPhone 15 mất 12 giây, hao pin 2%. Nếu xuống 33KB, thời gian verify có thể giảm xuống dưới 1 giây. Đó là game-changer.
2. Tốc độ 6-8 lần: phụ thuộc vào hardware.
A17 Pro có Neural Engine 35 TOPS INT8, nhưng verify zk-proofs chủ yếu là phép nhân trên đường cong elliptic (EC operations), không phải ma trận. Neural Engine không hỗ trợ EC, nên tốc độ phụ thuộc GPU. GPU iPhone chỉ mạnh ~2 TFLOPS FP32, bằng 1/50 card đồ họa rời. Để nhanh 6-8 lần so với proof 500KB hiện tại, cần tối ưu code verify bằng Metal shaders. ZKPrism hứa hẹn có thư viện verify tối ưu cho Apple Silicon – họ đã làm việc với Apple? Nếu có, đây là dấu hiệu tích cực.
3. Trade-off: tính toàn vẹn và độ an toàn.
Nén proof mạnh thường làm giảm độ an toàn. Các kỹ thuật như “lookup argument” hay “custom gates” có thể bị tấn công nếu tham số không được chọn cẩn thận. Chẳng hạn, nếu curve sử dụng có embedding degree nhỏ, discrete log có thể bị phá. ZKPrism chưa công bố curve hay trusted setup. Như một auditor từng nói với tôi: “Chưa có audit, coi như chưa có gì.” Tôi từng phát hiện lỗi trong batch verification của một privacy protocol, lỗi tương tự có thể ẩn trong bất kỳ hệ thống nén mới nào.
Contrarian: Không ai cần zkEVM trên iPhone cả.
Nghe phản trực giác, nhưng hãy suy nghĩ: người dùng iPhone không quan tâm việc tự verify blockchain. Họ muốn app chạy nhanh, bảo mật, pin lâu. ZkEVM local giải quyết nỗi lo privacy? Có, nhưng Apple đã có App Tracking Transparency và on-device processing. Thêm zk-proof chỉ làm máy nóng hơn. Các nhà phát triển dApp cũng không cần: họ đã có sequencer tập trung của Arbitrum hay Optimism để giảm gas. Chạy verification trên thiết bị người dùng chỉ tăng độ phi tập trung, nhưng chi phí UX cao. Đây là giải pháp công nghệ đi tìm vấn đề. Bản thân Apple cũng chỉ dùng nó như một chiến thuật marketing privacy, không thực sự thay đổi cách người dùng tương tác với crypto.
Takeaway: Dự báo lỗ hổng và tín hiệu mai phục.
Nếu ZKPrism có thật, cuộc đàm phán sẽ kết thúc bằng một vụ mua lại cỡ 50-100 triệu USD (bằng Xnor.ai). Nhưng tôi cá rằng công nghệ chưa sẵn sàng. Trong 6 tháng tới, ai đó sẽ đào ra lỗ hổng trong phương pháp nén của họ – có thể là bug trong constraint system, hoặc điểm yếu trong curve. DeFi Summer dạy tôi: gan là biết khi nào mai phục. Còn bây giờ, tôi chỉ việc ngồi chờ xem proof nào sẽ vỡ trước.