I started working on Rske (a light client meant for edge devices) on one hand to have such light client, but also to force myself to reason about my ideal design for Union bridge.
Here are some of the ideas that I think the Union bridge should consider:
1. Find the canonical Bitcoin chain
I wanted to avoid the assumption of no network partitioning, instead I assumed a minimum work for a Bitcoin chain based on the time since last trusted checkpoint, and some assumptions about the trendline of bitcoin hashrate.
In BitVM, there is no access to a clock, but BitVM designs already engaged with this problem, with either static minimum work, or whitelisted watchtowers that submit block headers.
2. PoW Fraud Proof
- Read all the bitcoin coinbase transactions backwards from the tip of the proposed bitcoin chain
- Assume a minimum ratio of honest miners H, say 1%
- Calculate the number of RSKBLOCK tags that you need to see so that the chance of censoring that H is < 5 sigma. That is usually W~=1500 RSKBLOCK tags for H >= 1%.
- Verify that there is no fork larger than H in W.
- Get the earliest RSK block that W endorses (This is where it gets tricky unfortunately, see the next section to see my suggestion to fix this).
- This RSK block, is “Finalized” or “checkpointed” or whatever, the important part here is that it is safe to withdraw from, and thus it is safe to withdraw from any of its parents.
3. Fix RSKBLOCK tag
Armadillo helps you be fairly confident that there is no RSK fork within a window of bitcoin blocks, however it doesn’t help you much knowing the latest RSK block that is endorsed by these RSKBLOCK tags, because there is no clear commitment to that.
You would have to download all RSK blocks (not just headers) to verify that every RSKBLOCK tag is pointing to either a canonical RSK header, OR to an uncle RSK header. Even then, it might be the case that some RSKBLOCK tag isn’t pointing to any uncle that is actually mentioned in later blocks, it is just orphaned.
This was already deemed to expensive in ZK proofs, which is why the undocumented “superchain” was invented, except the “superchain” has no proof of availability, but this proposal actually uses RSKBLOCK tags as the superchain.
Note that downloading all RSK blocks is also too expensive for light clients, not just zk proofs.
So how to make RSKBLOCK tag act as a super chain? Well we need the following fields:
struct SuperHeader {
/// An offset to the number of Bitcoin blocks back until the RSKBLOCK
/// tag that commits to an RSK block that is on the canonical RSK chain.
parent: u16,
/// An offset to the number of Bitcoin blocks back until the RSKBLOCK
/// tag that commits to an RSK block that is an uncle to this or previous RSK block.
uncle: u16,
}
Whether these should be in addition to the current 32 bytes, or replacing some of the CPV bytes, is something I don’t have a strong opinion about, except to say I would rather make the commitment to RSK block 32 bytes instead of 20, and extend the RSKBLOCK tag, and add fields like the cumulative work and other previously suggested informations.
How are this fields useful?
Similar to Pow Fraud Proof in Floresta or other clients, we assume that any invalid (or unavailable) block is going to cause a fork, as long as >= H miners are honest, and we delay finalization (and thus withdrawals) until there is no fork that long any more.
The Parent field lets you endorse previous super blocks that are in the canonical chain, and the Uncle field let’s you endorse previous super blocks that are not in the canonical chain.
I am not sure if it is very likely that you would need to endorse more than one super uncle, I suspect no.
Risk
The main risk here is that it only takes H miners to halt finalization and withdrawals of funds, but that is a tradeoff that I am perfectly happy to make.
We have seen how fast withdrawals can cause lose of funds (in Liquid lately), and in fact I think Rootstock withdrawals is 10 times faster than I wish it to be.
Ask yourself? is it possible for most of us to be busy and absent minded for a day and a half? I think yes, and in any case it is much safer to demand everyone’s attention at most once every two weeks instead of every day.
If this risk is unacceptable, the solution is simply to increase H, say to 10% or 33% or whatever sounds reasonable to everyone.
Conclusion
I think we should add super parents and super uncles pointers in the RSKBLOCK tags, possibly in the CPV bytes or extend the tag further than 32 bytes. I think this will be extremely helpful for both Union bridge, and light clients.
What I am looking for now is feedback from the community, especially @SergioDemianLerner, and hopefully give me a sense whether this is something that is could be adopted, or if I would be going against the grain too much and waisting everyone’s time.
