OK, laissez-moi essayer. Un vProg est comme ce petit environnement EVM dont l'état est complètement encodé sur la couche de base, donc il n'a pas besoin de rollups au-dessus. Cela a de nombreux avantages et inconvénients. Le principal avantage : pas de rollup, tout est sur la couche de base, la composition devient "triviale". Le principal inconvénient : pas de rollup, toute la disponibilité des données repose sur les utilisateurs, et la composition devient coûteuse sur de grandes échelles de temps. Les vProgs ont du sens dans des situations où la composabilité atomique est rapide (le temps nécessaire pour générer une preuve est de l'ordre de la latence du réseau) et fréquente. Les rollups ont du sens lorsque vous souhaitez des opérations à long terme avec une disponibilité continue des données. De plus, les vProgs ne suffiront pas dans un contexte où une liquidité externe est requise. Les vProgs ne remplacent pas les rollups, ils les complètent. En particulier, les vProgs peuvent potentiellement être utilisés dans des scripts de verrouillage de rollup (la partie qui spécifie les conditions sous lesquelles les actifs verrouillés, par exemple, Kaspa bridés à un rollup, peuvent être déverrouillés) pour bénéficier aux deux. Mais surtout, personne ne sait exactement ce que sont les vProgs, y compris les personnes qui les conçoivent actuellement, car telle est la nature des idées qui sont encore en développement. La composabilité atomique des vProgs pourrait être la clé de l'interopérabilité canonique des rollups. Je pense que c'est le véritable pouvoir de cette notion, et la motivation qui la sous-tend.