1/ Majoritatea probelor ZK sunt construite pentru a produce demonstrații corecte. Puține sunt construite să fie rapide, auditabile și pregătite pentru producție. Partea I a introdus demonstrarea pe grafuri mai întâi. Partea a II-a a arătat cifrele. Partea a III-a este foaia de parcurs pentru a introduce Venus în producție. Bine ați venit la finalul trilogiei zkVM. 🧵

2/ Faza 1: Performanță. Construim folosind graful computațional – nu HAL – ca interfață de execuție de bază încă din prima zi. Integrarea timpurie cu cudaGraph arată deja îmbunătățiri de 9–12% față de RTX 5090. Țintă: 15%+, cu multi-GPU ca următorul. Orice optimizare se compune.

3/ Faza 2: Securitate Aceeași performanță care conduce graficul poate verifica automat protocolul de demonstrație în sine. Ideea cheie: tipurile de argumente ZK sunt mici și numerabile – SumCheck se descompune în doar două. Construiește o bibliotecă de încredere finită, verifică mecanic orice protocol.

4/ Faza 3: integrarea cu rbuilder. Construcția de blocuri abia așteaptă un prover lent. Așadar, construim un pipeline asincron cu preempțiune conștientă de reorganizare și un plan de rezervă elegant când dovedirea se deblochează. Scopul: ca ZK să demonstreze că se potrivește în producția live block fără să încetinească.

5/ Faza 4: Economie. Poate un nod zkEVM să se susțină singur? Modelăm taxele de dovadă, cota MEV și stimulentele de protocol în raport cu costurile hardware și operațiuni pe 3 configurații GPU (de la RTX 5090 la 8x) pentru a găsi punctul de echilibru. Primul pe graf câștigă doar dacă este viabil de rulat.

6/ Majoritatea probelor ZK sunt construite pentru a produce demonstrații corecte. Demonstrațiile corecte sunt baza de bază. Construim unul care este, de asemenea, rapid, auditabil, pregătit pentru producție și sustenabil de rulat. Asta face posibil graficul pe primul loc. Citește Partea a III-a: