RSKIP567: Fork-Aware Consensus

RSKIP
1

As an effort to communicate better the research done and to open the space for criticism and discussions, I plan going forward to create a topic here for each topic that I work on.

To bootstrap this, I will share the RSKIP that I worked last quarter and updated this quarter: Fork-Aware Consensus. This is based on Sergio’s series of proposals to improve fork detection. RSKIP link.

Following here a quick summary to those who can’t open the link.

What is Fork-Aware Consensus?

It is a possible replacement for Armadillo where we take the idea of verifying RSK tags from the Armadillo node on BTC to each RSK node instead. To do this, we change the extendedData field on RSK block headers to include a new element carrying data from BTC coinbase transactions. We call this extension the Fork-Balance Proof.

What is Included in the Fork-Balance Proof?

Take any RSK block A, merged-mined with BTC block B (not necessarily broadcast on the BTC network due to difficulty). We include in A’s Fork-Balance Proof the last bytes of the coinbase transaction included in the PARENT BLOCK of B, as well as other fields to prove that these bytes are correct, belong to the correct block and that this block is indeed B’s parent.

What is the logic behind detection?

The logic is the same as Armadillo: We look for tags that include the hash of blocks we cannot identify in the canonical chain (+uncles). The difference is that we check this continuously for each block and build a metric based on the proportion of these tags we find. When this proportion is above a certain threshold, we trigger a flag on blocks to signal that a hidden fork is very likely to exist.

What users/nodes do with this information?

The main objective of fork-aware consensus is to bring awareness to the user. We don’t expect them to filter blocks, but we expect them to hold on high value or sensitive transactions, and perhaps delay confirmation using this information, cutting incentives to the possible attacker.

Finally, this is not implemented yet and it can coexist with Armadillo as long as we need, so the project may change over time.

2 Likes
2

Thank you very much for this, and I am already excited for superchains discussion as well.

I see the RSKIP has been updated with more details and graphs, so I will spend some time reading this update.

However, my main question has always been; why not just implement Armadillo in RSKj? Is it really that hard to implement a Bitcoin SPV in RSKj?

Yes I am usually pushing for RSKj to embrace being a sidechain and not independent blockhain, but I also think Rootstock headers are too big already, and I would rather to remove fields from it not add to it.

Also any scheme that can make IBD faster (without super expensive and possibly buggy ZK clients) would require that we already watch Bitcoin chain, so I think adding the same data in extendedData is redundant.

Is there something in RSKj codebase or consensus assumption that makes this RSKIP easier to deploy than just shipping Armadillo in RSKj?

3

Hi Nuh! Thanks a lot for the comments.

The problem with Armadillo is that as it is designed, it is a centralization point with a problem of incentives. It does not really align well with the design we want to put all security against hidden forks on the back of the node running this. Also, trying to create something like “Committee-based Armadillo” would just create fees and a complex design that more failure points. It would feel like a patch more than a solution.

About the extensive header, if RSK nodes had to also run a BTC node, then this field would indeed be redundant, but this a deeper design choice that involves the whole protocol, so I can’t really do much about it.

4

I don’t think RSK nodes need to run BTC nodes, just download headers and coinbase transactions, Rootstock is already aware of headers using a precompiled smart contract, if I am not mistaken. So I don’t see that expecting RSKj to gossip bitcoin headers and coinbase txns to be very radicle, and it could be part of this RSKIP, the other part remains the definition of SAFE tag.

I might be mistaken, in which case I would hope someone explain to us why can’t RSK nodes be aware of the BTC headers and coinbase txns.