A velvet fork (at least as I mean it here) is basically a vote between a subset of miners on the the state at a point in the past. The upside of velvet forks is that you don’t need consensus for it to be useful, and the downside is that you can read the state of a “SAFE” block and trust that.
In the context of Utreexo, which is the Bitcoin version of state commitment, the best we currently have is to assumeutreexo at a given block, only to speed up the IBD (initial block download) but then you must go backwards in time and verify every block since genesis to make sure that this assumed utreexo is indeed valid.
A soft fork that forces miners to commit in the coinbase to a valid Utreexo roots, would be ideal, because you can start IBD from 6 blocks or 100 blocks ago or whatever you point in the past you deem safe from reorg, then read the Utreexo commitment at that block, and trust that it MUST be valid by consensus.
We will never have a soft fork like this most probably, but we can have miners vote on what Utreexo commitment do they endorse and acknowledge as correct, then after enough votes, say after 51% of the blocks in a period longer than 2016 blocks vote on a given utreexo commitment in the past, you can take that utreexo commitment for granted.
Design
A simple way to add this to a coinbase transaction is the following:
OP_RETURN "UTREEXO" <32 bytes Utreexo roots commitment> <4 bytes block endorsement>
This way, each miner can attest to the Utreexo roots after this block, then also vote on block (by block number) where it endorses the Utreexo at this block AND the endorsed block in that block, so endorsement can be transient.
Where Rootstock can come in
If Rootstock changes the precompiled contract for block reward sharing, so that a miner’s share is forfeited if they don’t include a valid “UTREEXO” tag, then we keep the fork choice unaffected, but we incentivize merge miners to add this tag to their coinbase transaction.
Instead of forfeiting, we can partially weigh based on these nice to have features.
Why do I want to see this
- It is a good service for Bitcoin light nodes with fraud proofs, like Floresta, which I personally prefer more than running Bitcoin core, especially after
libbitcoinkernel. - I would rather have Rootstock nodes more aware of Bitcoin chain, hopefully by embedding Floresta in RSKJ for example, which makes future changes like Syncchains more palatable.
- The same Velvet Fork can be applied for Rootstock itself, so that we can implement Ephemeral Sidechains, more efficiently, by letting miners vote on a Rootstock checkpoint, right on Bitcoin itself.