I am currently developing a prototype (and it is kind of working, I am debugging around block 830’000 at the moment), that would calculate very accurately the witness overhead of this
Interesting, do you have an estimate for how big it could be?
I meant that transactions - not in a block, but as sent to the mempool - include witnesses for a 100 block away - as a way to protect against orphans of recent blocks. It wouldn’t be a protocol rule, just a safe UX default, I guess it could be reduced to 10. Blocks would have only the most recent root.
You could generate a transaction with a witness from the tip and it could be included, assuming that block wasn’t orphaned.
this will require having snapshot sync
I don’t think snapshot sync is needed as far as pure stateless mode is concerned. Blocks would include the current state root, a new node could start validating straight away from the tip. You could start mining right away, after 10 blocks you could include transactions with witnesses from the last 10 blocks, after 1 hour from 1 hour etc.
Keeping 24 hours of state doesn’t have be enforced by the protocol - just as a node default. If some miner wants to only mine transactions that are at most 10 minutes old, at the cost of losing some fees, it’s his right.
It could be enforced in the way you described, but the only advantage I can see would be that new miners would be able to mine hours-old transactions instantly after fast syncing. If they want that, I think that could be better solved by off-chain protocols (eg. paid service that sells old state).
One idea we heard (and we can check the viability using the data) is to introduce rent on accounts and code, but stateless clients on the contract storage
It would solve what I think is the single biggest issue which is a free rider problem for token balances storage in current contracts.
I still think full stateless mode with on-chain state purely optional is a better way, for the state size too. Only contracts/accounts that are very heavily used would be on-chain. When some entity (eg. idex) would find out that witness fees in X days > state rent in X days, they would pay state rent for relevant contracts, saving block space for everyone that also uses them. A contract that’s only used once a year would be cheaper completely stateless.
Another argument is UX. Simple users wouldn’t even have to notice the change - as their wallet provider could provide witnesses for their accounts, at the cost of a slightly higher fees. Advanced users/developers would have the option to pay rent if they want.
It could be good to separate rent for code from contract storage rent. This way, most likely someone (eg. exchanges) would pay state rent for code of most used tokens as it would be relatively cheap and save them fees, but keeping contract storage stateless.
Potentially, optional on-chain storage could even come in a second fork after the stateless change, keeping everything fully stateless in the interim.