Post History
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...
#2: Post edited
- 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
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.