RCP-241013A: Cross-chain consensus ordering

[dr-orlovsky]

authors: @dr-orlovsky
layers: consensus
breaking: consensus, api, serialization
related: RCP-240731A

Background

#10

Motivation

With the ordering rules we have in place if two operations are present on different chains, they are compared by their timestamp. This has a number of issues:

• blocks do not always increment timestamps with their height; specifically this can be seen in Liquid and Bitcoin testnets, when the block time is short and frequently blocks at larger height have smaller timestamp than their predecessors (see WitnessPos ordering fails on regtest rgb-core#273)
• miners on blockchains with less security than bitcoin mainnet may manipulate consensus ordering by deliberately putting lower timestamps to their blocks, being ordered before mainnet events

Proposal

• introduce blockchain information directly into consensus ordering data
• for the same chain order basing on the height and not timestamp information
• ordering items from different blockchain check their timestamp:
  • if the absolute timestamp difference is less than 10 mins (typical bitcoin block time), ignore timestamp and height, and instead apply chain ordering rule (see below)
  • otherwise, order using timestamp information
• chain ordering is the following (from higher to lower priority): bitcoin, liquid, other future chains

Rationale

Selection of 10 minutes as a timestamp window: since we are using absolute difference, this means that for all blocks mined (or reported by miners) from 10 mins before to 10 mins after a current bitcoin block, the bitcoin block will take a priority. Given that liquid block time of 1 minute, this provides security 20x threshold, which would be hard to the liquid miners to manipulate. Making a larger time window would mean reduced incentives for the users to use non-bitcoin blockchains; making smaller window - simplify miner manipulations. Thus, while ±10 min is still arbitrary value, where only order of it is important (so it can be easily ±9 or ±11, but certainly not ±1 or ±20), selection of 10 mins equal to the block time makes just most obvious choice of this arbitrary value.

Implementation

RGB-WG/rgb-core#275