Dobře, zkusím to. vProg je jako toto malé prostředí EVM, jehož stav je kompletně zakódován na základní vrstvě, takže nad ním nepotřebuje žádné rollupy. To má mnoho výhod i nevýhod. Hlavní výhoda: žádný rollup, vše na základní vrstvě, kompozice se stává "triviální". Hlavní nevýhoda: žádný souhrn, veškerá dostupnost dat padá na uživatele a složení se prodražuje ve velkém časovém měřítku. vProgs mají smysl pro situace, kdy je atomická skládání rychlá (doba potřebná k vygenerování důkazu je v řádu latence sítě) a častá. Kumulativní aktualizace mají smysl, pokud chcete operace s dlouhým dosahem s průběžnou dostupností dat. vProgs to také neomezí v žádném prostředí, kde je vyžadována externí likvidita. vProgs nenahrazují rollupy, ale doplňují je. Konkrétně vProgs může být potenciálně použit v kumulativních uzamykacích skriptech (část, která specifikuje podmínky, za kterých lze odemknout uzamčené prostředky, např. Kaspa přemostěné na kumulativní skripty) ve prospěch obojího. Ale většinou nikdo přesně neví, co vProgy jsou, včetně lidí, kteří je v současné době navrhují, protože taková je povaha nápadů, které se stále vyvíjejí. Atomická kompozibilita vProgs by mohla být klíčem ke kanonické interoperabilitě. Myslím, že to je skutečná síla tohoto pojmu a motivace, která za ním stojí.