Ảo giác chi phí Zero-Knowledge: Vì sao ZK-Rollup âm thầm chảy máu

Tháng trước, tôi được xem một báo cáo nội bộ từ một team ZK-Rollup. Tôi không được phép nêu tên, nhưng tôi được phép phân tích. Điều khiến tôi chú ý không phải con số doanh thu, mà là một dòng chi phí nằm ngoài sổ sách. Họ gọi nó là “compute buffer” — một khoản mơ hồ để che đi việc tiền điện và bảo trì GPU đang ngốn hết lợi nhuận. Nếu bạn chỉ nhìn vào số dư on-chain, bạn sẽ thấy một hệ thống có vẻ lành mạnh: phí người dùng vẫn vào đều, TVL không giảm, chi phí gas trên L1 thấp. Nhưng sự thật nằm ngoài dữ liệu, trong cấu trúc của nó. Cấu trúc ở đây là một cụm máy chủ âm thầm tạo ra bằng chứng mỗi ngày, và nó đang nuốt trọn lợi nhuận của operator. Với những ai chưa theo dõi kỹ: ZK-Rollup là một giao thức Layer 2, gom hàng nghìn giao dịch thành một batch, tạo ra một zero-knowledge proof để chứng minh batch đó hợp lệ, rồi đưa bằng chứng lên Ethereum. Phí người dùng trả cho ba thứ: chi phí calldata trên L1, phí xác minh bằng chứng trong hợp đồng, và chi phí tạo bằng chứng ngoài chuỗi — phần cuối cùng gần như vô hình. Các dashboard như L2BEAT hay Dune Analytics chỉ đo được hai con số đầu tiên vì chúng nằm trên chuỗi. Phần thứ ba, chiếm tới 70-80% tổng chi phí, không hề xuất hiện trong bất kỳ giao dịch nào. Dựa trên kinh nghiệm audit của tôi, hầu hết các team đều tính sai chi phí này trong whitepaper. Họ công bố một con số “cost per proof” dựa trên một chiếc máy ảo với tham số duy nhất, không ai ngờ tới hằng số ẩn: thời gian chờ, sao chép dữ liệu, fallback khi GPU lỗi, hay chi phí đào tạo lại prover khi giao thức nâng cấp. Mỗi batch không chỉ tốn vài phút tính toán, nó còn kéo theo một chuỗi phụ thuộc — dependency graph — mà nếu một node chậm, toàn bộ pipeline bị tắc. Khi tôi reverse-engineer một hệ thống như vậy, tôi nhận ra rằng chi phí thực tế không tỉ lệ tuyến tính với số giao dịch, mà tỉ lệ với khả năng chịu lỗi của hệ thống. Bạn muốn batch nhanh hơn 2 lần? Bạn phải tăng GPU lên 4 lần, chứ không phải 2 lần. Hãy thử làm một phép tính thực tế. Với một batch 10.000 giao dịch, một hệ thống Groth16 trên GPU cần khoảng 10-30 phút để tạo proof. Để đạt được thông lượng ổn định dưới áp lực giao dịch, operator phải vận hành một cụm ít nhất 8-16 GPU. Chi phí phần cứng, điện năng, làm mát, giám sát, nhân sự vận hành — tất cả cộng lại có thể từ 50.000 đến 150.000 USD mỗi tháng. Khi thị trường tăng, phí giao dịch cao, khoản này được bù đắp. Nhưng trong thị trường giảm — như hiện tại — người dùng giao dịch ít, phí thu được không đủ để trả tiền điện, chưa nói đến phần cứng. Đây không phải một lỗi trong mã nguồn, mà là một lỗi trong kỳ vọng: giả định rằng chi phí chứng minh sẽ tự động biến mất nhờ tiến bộ công nghệ. Mọi người thường nhìn vào TPS như một thước đo sức khỏe. Tôi nhìn vào một con số khác: thời gian trung bình giữa khi một giao dịch xuất hiện trong mempool và khi nó được finalize. Nếu con số này tăng đột biến ở một số khung giờ, rất có thể operator đang xếp hàng các batch bởi vì cụm GPU không đủ công suất. Điều này không xuất hiện trong calldata, cũng không xuất hiện trong phí xác minh. Sự thật về một hệ thống không nằm ở giao dịch mà nó xử lý, mà nằm ở các giao dịch nó từ chối xử lý. Điều phản trực giác ở đây: EIP-4844 không hề cứu ZK-Rollup, nó làm lộ ra điểm yếu thật sự. Trước bản nâng cấp, calldata chiếm tới 40% chi phí vận hành, khiến ai cũng đổ lỗi cho đắt đỏ của Ethereum L1. Sau khi chi phí calldata giảm hơn 90%, người ta chờ đợi phí người dùng giảm theo. Nhưng thực tế, chi phí tạo proof bỗng lộ diện như một tảng băng chìm. Khi chi phí calldata không còn là nút thắt, phần chi phí ngoài chuỗi mà các team cố giấu trở thành trung tâm của vấn đề. Có một nghịch lý thú vị: các ZK-Rollup lớn bắt đầu chuyển sang mô hình “hybrid proof” — tức là thay vì chứng minh toàn bộ batch, họ dùng một cơ chế giống optimistic để batch được xác nhận trước, sau đó tính proof dần. Điều này vi phạm nguyên tắc “validity proof” mà họ từng tuyên bố. Nhưng không ai nói thẳng ra. Họ gọi đó là “finality acceleration”, một cách nói lịch sự cho việc: cụm prover không đủ nhanh và không đủ rẻ. Khi bạn đọc hợp đồng thông minh, bạn không thấy cụm GPU; nhưng khi bạn nhìn vào thời gian finality thực tế, bạn thấy cấu trúc kinh tế đang sụp đổ. Nếu bạn đang nắm giữ token của một ZK-Rollup, có một câu hỏi bạn phải tự đặt ra: ai đang trả tiền cho cụm GPU kia? Nếu câu trả lời là “quỹ dự trữ của team”, thì quỹ đó đang chảy máu mỗi ngày. Trong một thị trường giảm kéo dài, các quỹ này không thể trụ vững. Những bài phân tích thông thường chỉ nhìn vào revenue từ phí, mà bỏ qua capital expenditure đằng sau hạ tầng. Sự thật nằm ngoài dữ liệu, trong cấu trúc của nó. Chi phí không nằm trong log, mà nằm trong hardware. ZK-Rollup sẽ tồn tại, nhưng có thể chỉ dành cho chuyển tiền đơn giản, còn với các ứng dụng phức tạp, chi phí proof là một rào cản mà không ai thừa nhận. Lần tới khi ai đó hứa hẹn “ZK sẽ thay thế tất cả”, hãy hỏi họ: bạn đã tính chi phí bằng chứng chưa? Và quan trọng hơn, bạn đã tính một cách trung thực chưa?