1/ Hầu hết các ZK provers được xây dựng để tạo ra các chứng minh chính xác. Rất ít được xây dựng để nhanh chóng, có thể kiểm toán và sẵn sàng cho sản xuất. Phần I đã giới thiệu về chứng minh theo đồ thị. Phần II đã cho thấy các con số. Phần III là lộ trình để đưa Venus vào sản xuất. Chào mừng bạn đến với phần cuối của bộ ba zkVM. 🧵

2/ Giai đoạn 1: Hiệu suất. Chúng tôi đang xây dựng với đồ thị tính toán – không phải HAL – như giao diện thực thi cốt lõi từ ngày đầu tiên. Tích hợp cudaGraph sớm đã cho thấy cải thiện từ 9–12% trên RTX 5090. Mục tiêu: 15%+, với việc chứng minh multi-GPU tiếp theo. Mỗi tối ưu hóa đều tích lũy.

3/ Giai đoạn 2: Bảo mật Biểu đồ giống như biểu đồ hiệu suất cũng có thể kiểm tra máy móc giao thức chứng minh. Điểm mấu chốt: Các loại lập luận ZK là nhỏ và có thể đếm được – SumCheck phân rã thành chỉ hai loại. Xây dựng một thư viện đáng tin cậy hữu hạn, xác minh bất kỳ giao thức nào một cách cơ học.

4/ Giai đoạn 3: tích hợp rbuilder. Việc xây dựng khối không thể chờ đợi một prover chậm. Vì vậy, chúng tôi đang xây dựng một pipeline bất đồng bộ với khả năng nhận biết reorg và khả năng quay lại một cách duyên dáng khi việc chứng minh kéo dài. Mục tiêu: chứng minh ZK phù hợp với việc sản xuất khối trực tiếp mà không làm chậm lại.

5/ Giai đoạn 4: Kinh tế học. Một nút zkEVM có thể tự duy trì không? Chúng tôi đang mô hình hóa phí chứng minh, phần chia MEV, và các ưu đãi giao thức so với chi phí phần cứng và vận hành trên 3 cấu hình GPU (từ một RTX 5090 đến 8x) để tìm điểm hòa vốn. Chỉ có chiến thắng đầu tiên nếu nó khả thi để vận hành.

6/ Hầu hết các ZK provers được xây dựng để tạo ra các chứng minh chính xác. Các chứng minh chính xác là tiêu chuẩn cơ bản. Chúng tôi đang xây dựng một cái cũng nhanh, có thể kiểm toán, sẵn sàng cho sản xuất và bền vững để vận hành. Đó là điều mà graph-first có thể thực hiện. Đọc Phần III: