OK, la meg prøve. En vProg er som dette lille EVM-miljøet hvis tilstand er fullstendig kodet på basislaget, så det trenger ingen rollups over det. Dette har mange fordeler og ulemper. Den største fordelen: ingen opprulling, alt på underlaget, sammensetningen blir "triviell". Den største ulempen: ingen opprulling, all datatilgjengelighet faller på brukerne, og sammensetning blir dyrt på store tidsskalaer. vProgs gir mening for situasjoner der atomkomponerbarhet er rask (tiden det tar å generere et bevis er i størrelsesorden nettverksforsinkelsen) og hyppig. Samleoppdateringer er fornuftige når du vil ha langdistanseoperasjoner med kontinuerlig datatilgjengelighet. vProgs vil heller ikke kutte det i noen setting der ekstern likviditet er nødvendig. vProgs erstatter ikke rollups, de utfyller dem. Spesielt kan vProgs potensielt brukes i samlelåsskript (delen som spesifiserer betingelsene under hvilke låste eiendeler, f.eks. Men stort sett er det ingen som vet nøyaktig hva vProgs er, inkludert menneskene som for tiden designer dem, fordi slik er ideene som fortsatt utvikler seg. vProgs' atomkomponerbarhet kan være nøkkelen til kanonisk rollup-interoperabilitet. Jeg tror det er den sanne kraften i denne forestillingen, og motivasjonen bak den.