OK, låt mig försöka. En vProg är som den här lilla EVM-miljön vars tillstånd är helt kodat på baslagret, så det behöver inga rollups ovanför det. Detta har många för- och nackdelar. Den största fördelen: ingen sammanslagning, allt på baslagret, sammansättningen blir "trivial". Den största nackdelen: ingen sammanslagning, all datatillgänglighet faller på användarna och sammansättningen blir dyr på stora tidsskalor. vProgs är meningsfullt för situationer där atomisk komponerbarhet är snabb (den tid det tar att generera ett bevis är i storleksordningen för nätverkslatensen) och frekvent. Sammanslagningar är meningsfulla när du vill ha långsiktiga åtgärder med kontinuerlig datatillgänglighet. Dessutom kommer vProgs inte att klippa det i någon miljö där extern likviditet krävs. vProgs ersätter inte rollups, de kompletterar dem. I synnerhet kan vProgs potentiellt användas i rollup-låsningsskript (den del som anger de villkor under vilka låsta tillgångar, t.ex. Kaspa som är bryggade till en sammanslagning, kan låsas upp) för att gynna båda. Men för det mesta vet ingen exakt vad vProgs är, inklusive de människor som för närvarande designar dem, eftersom det är så idéer som fortfarande utvecklas. vProgs atomära komponerbarhet kan vara nyckeln till kanonisk interoperabilitet för samlad drift. Jag tror att det är den verkliga kraften i den här föreställningen och motivationen bakom den.