OK, laat me het proberen. Een vProg is als deze kleine EVM-omgeving waarvan de staat volledig is gecodeerd op de basislaag, zodat er geen rollups bovenop nodig zijn. Dit heeft veel voordelen en nadelen. Het belangrijkste voordeel: geen rollup, alles op de basislaag, samenstelling wordt "triviaal". Het belangrijkste nadeel: geen rollup, alle gegevensbeschikbaarheid valt op de gebruikers, en samenstelling wordt duur op lange tijdschalen. vProgs zijn logisch voor situaties waarin atomische samenstelbaarheid snel is (de tijd die nodig is om een bewijs te genereren is van de orde van de netwerklatentie) en frequent. Rollups zijn logisch wanneer je langlopende operaties wilt met voortdurende gegevensbeschikbaarheid. Ook zullen vProgs niet voldoen in elke setting waar externe liquiditeit vereist is. vProgs vervangen geen rollups, ze complementeren ze. In het bijzonder kunnen vProgs mogelijk worden gebruikt in rollup-lockscripts (het deel dat de voorwaarden specificeert waaronder vergrendelde activa, bijv. Kaspa dat naar een rollup is gebridged, kunnen worden ontgrendeld) om beide te profiteren. Maar meestal weet niemand precies wat vProgs zijn, inclusief de mensen die ze momenteel ontwerpen, omdat dat de aard is van ideeën die zich nog ontwikkelen. De atomische samenstelbaarheid van vProgs zou de sleutel kunnen zijn tot canonieke rollup-interoperabiliteit. Ik denk dat dat de ware kracht van dit idee is, en de motivatie erachter.