1/ Akta dig för hypen: även om SNARKs och zkVMs visar enorma löften, är de inte redo för komplexa distributioner med höga insatser. Buggar finns överallt, formell verifiering är i sin linda och bevis kan vara hundratusentals gånger långsammare än inbyggd körning.

2/ Jag har precis publicerat ett inlägg som beskriver en strukturerad färdplan för zkVM-utveckling. Den separerar "säkerhetssteg" från "hastighetssteg", vilket ger oss ett transparent sätt att spåra framsteg. Läs den här:

3/ När det gäller säkerhet identifierar jag tre steg för formell verifiering: • Verifierade protokoll • Verifierade verifierare • Verifierade bevisare Tills vi når steg 2 kan vi inte riktigt kalla en zkVM "säker" - och att komma dit är fortfarande troligt flera år bort.

4/ När det gäller prestanda överstiger omkostnaderna jämfört med inbyggd körning fortfarande 100 000 × – en icke-startfunktion för de flesta användningsfall. Mitt inlägg föreslår fem "prestandasteg" för att minska den overheaden med storleksordningar och så småningom möjliggöra bevis på enheten.

5/ Avgörande är att vi måste isolera ett bevissystems grundläggande effektivitet. Just nu buntar många prestandatester ihop allt – bevissystem, teknik, hårdvaruförbättringar och handjusterade förkompileringar – i en enda topplinje, vilket döljer var vi verkligen står.

6/ Så ja, zkVMs och SNARKs har en enorm potential, men vi flirtar med katastrof om vi låtsas att de är redo för bästa sändningstid. Jag kommer att använda dessa steg för att spåra zkVM-framsteg under de kommande åren – och hoppas att andra också kommer att göra det. Kolla in mitt inlägg här: