Communities

Kaspa Q&A
Kaspa Q&A
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Kaspa Q&A

Post History

60%
+1 −0
Kaspa Q&A What is "vprogs"?

There is a WiP Yellowpaper here: https://github.com/kaspanet/research/tree/main/vProgs vProgs stand for verifiable programs, i.e. programs whose execution commands (transactions) are sequenced on...

posted 5h ago by FreshAir28‭  ·  edited 5h ago by FreshAir28‭

Answer
#2: Post edited by user avatar FreshAir28‭ · 2025-10-02T21:04:48Z (about 5 hours ago)
  • There is a WiP Yellowpaper here:
  • https://github.com/kaspanet/research/tree/main/vProgs
  • vProgs stand for verifiable programs, i.e. programs whose execution commands (transactions) are sequenced onchain, executed offchain and finally settled onchain. It is no coincidence this sounds similar to based rollups - the discussion is a direct continuation to the based rollup architecture effort. The name stands to emphasize the fact that vProgs in the longer term are not meant to be only mega-programs "rolling up" several small contracts together, rather can be DAO or even standalone independent smart contracts.
  • So far for the laconic description. As for what problem is solved by vProgs - the immediate problem with the above vision is that smart contracts, by design, are entities that like to communicate with each other seamlessly. To communicate synchronously, you need to know what the state of the other is, which means you must have ran it. Naively, this means you must run it all the time, i.e. essentially you are both part of the same "rollup" if you allow yourself to communicate with eachother.
  • This is what strereotypically causes the gravitation of smart contracts to rollups, but it also locks the smart contracts in a rollup ecobubble they cannot escape from.
  • The vProg YP gives a sketch on how to allow vProgs to synchronously communicate with eachother, while using "zk-catchup" to only run your interlocutor vProg's transactions when it is absolutely necessary to compute your own state, rather than at all time.
  • There is a WiP Yellowpaper here:
  • https://github.com/kaspanet/research/tree/main/vProgs
  • vProgs stand for verifiable programs, i.e. programs whose execution commands (transactions) are sequenced onchain, executed offchain and finally settled onchain. It is no coincidence this sounds similar to based rollups - the discussion is a direct continuation to the based rollup architecture effort. The name stands to emphasize the fact that vProgs in the longer term are not meant to be only mega-programs "rolling up" several small contracts together, rather can be DAO or even standalone independent smart contracts.
  • So far for the laconic description. As for what problem is solved by vProgs - the immediate problem with the above vision is that smart contracts, by design, are entities that like to communicate with each other seamlessly. To communicate synchronously, you need to know what the state of the other is, which means you must have ran it. Naively, this means you must run it all the time, i.e. essentially you are both part of the same "rollup" if you allow yourselves to communicate with eachother.
  • This is what stereotypically causes the gravitation of smart contracts to rollups, but it also locks the smart contracts in a rollup ecobubble they cannot escape from.
  • The vProg YP gives a sketch on how to allow vProgs to synchronously communicate with eachother, while using "zk-catchup" to only run your interlocutor vProg's transactions when it is absolutely necessary to compute your own state, rather than at all time.
#1: Initial revision by user avatar FreshAir28‭ · 2025-10-02T21:03:05Z (about 5 hours ago)
There is a WiP Yellowpaper here:
https://github.com/kaspanet/research/tree/main/vProgs

vProgs stand for verifiable programs, i.e. programs whose execution commands (transactions) are sequenced onchain, executed offchain and finally settled onchain. It is no coincidence this sounds similar to based rollups -  the discussion is a direct continuation to the based rollup architecture effort. The name stands to emphasize the fact that vProgs in the longer term are not meant to be only mega-programs "rolling up" several small contracts together, rather can be DAO or even standalone independent smart contracts. 

So far for the laconic description. As for what problem is solved by vProgs - the immediate problem with the above vision is that smart contracts, by design, are entities that like to communicate with each other seamlessly. To communicate synchronously, you need to know what the state of the other is, which means you must have ran it. Naively, this means you must run it all the time, i.e. essentially you are both part of the same "rollup" if you allow yourself to communicate with eachother. 
This is what strereotypically causes the gravitation of smart contracts to rollups, but it also locks the smart contracts in a rollup ecobubble they cannot escape from.

The vProg YP gives a sketch on how to allow vProgs to synchronously  communicate with eachother, while using "zk-catchup" to only run your interlocutor vProg's transactions when it is absolutely necessary to compute your own state, rather than at all time.