OK, lasă-mă să încerc. Un vProg este ca acest mediu EVM mic a cărui stare este complet codificată pe stratul de bază, deci nu are nevoie de rollup-uri deasupra lui. Acest lucru are multe avantaje și dezavantaje. Principalul avantaj: fără rulare, totul pe stratul de bază, compoziția devine "trivială". Principalul dezavantaj: fără rollup, toată disponibilitatea datelor cade pe utilizatori, iar compoziția devine costisitoare pe scară mare de timp. vProg-urile au sens pentru situațiile în care componabilitatea atomică este rapidă (timpul necesar pentru a genera o dovadă este de ordinea latenței rețelei) și frecventă. Pachetele au sens atunci când doriți operațiuni pe distanțe lungi cu disponibilitate continuă a datelor. De asemenea, vProgs nu va fi suficient în niciun cadru în care este necesară lichiditate externă. vProg-urile nu înlocuiesc rollup-urile, ci le completează. În special, vProg-urile pot fi utilizate în scripturile de blocare a rollup-ului (partea care specifică condițiile în care activele blocate, de exemplu, Kaspa conectat la un rollup, pot fi deblocate pentru amândouă). Dar, de cele mai multe ori, nimeni nu știe exact ce sunt vProg-urile, inclusiv oamenii care le proiectează în prezent, pentru că aceasta este natura ideilor care încă se dezvoltă. Componabilitatea atomică a vProgs ar putea fi cheia interoperabilității rollup canonice. Cred că aceasta este adevărata putere a acestei noțiuni și motivația din spatele ei.