Introducing inscriptions-sequence-consensus-hash

[lgalabru]

Following up on ordinals/ord#2574.

Objective

The primary objective is to create a robust mechanism for ensuring data integrity and consistency across ordinal indexers. This involves introducing a consensus hash built using a Merkle root, derived from blockchain events. This enhancement aims to address the current limitations in the ordinals protocol, particularly in improving provability.

Problem

The current system is lacking of a consensus hash, limiting capabilities in detecting regressions and indexing divergences. To overcome these limitations, we propose the generation of a Merkle root. This root will be derived from specific blockchain events, namely inscription reveals and transfers. By employing cryptographic consensus hashes in the form of a Merkle root, ordinal indexers can enhance their upgrade process, establish verifiable checkpoints, and prevent the publication of inaccurate indexes.

Proposed Protocol

Event Types for Consideration

• Inscription Revealed: This event occurs when an inscription's content becomes publicly known.
• Inscription Transferred: This event is recorded when the ownership of an inscription changes hands.
  Event Processing and Merkle Tree Construction
• Events are chronologically sorted based on their on-chain inclusion timestamps.
• These sorted events are then structured into a Merkle tree. This tree structure enables efficient and secure verification of the contents.
  Generating the Consensus Hash
• The Merkle proof, derived from the constructed tree, is combined with the consensus hash of the previous block, and the hash of the current Bitcoin block.
  This combination generates the new consensus hash for the current block.
• This hash serves as a reliable reference point for validating the integrity and consistency of ordinal indexers' data.

Inscription events

A satoshi being inscribed per the rules of a given sequence, would be augmenting the said sequence:

0        1        2                18               52              72                   74                  82
|--------|--------|-----------------|----------------|---------------|--------------------|-------------------|
 Sequence  Action   Ordinal Number    Inscription ID   Content hash    Output post-reveal  Offset post-reveal  

• Sequence : Sequence being inscribed - 0x00 if the sequence being indexed is the blessed sequence (which is the only stable sequence to date). We are versioning sequences because rules are changing overtime. Post-Jubilee, this byte will be bumped to 0x01.
• Action: inscription = 0x01
• Ordinal Number: Ordinal number being inscribed - uint128
• Inscription ID: Id of the inscription. Composed of:
  • Transaction ID - 32 bytes,
  • Inscription index (intra-transaction) - uint16
    Example: 94e524cbdaf19c27491ac6fe22e7884e35f11ee3ba290ddf218efeaf5d5e9bddi0 = 0x94e524cbdaf19c27491ac6fe22e7884e35f11ee3ba290ddf218efeaf5d5e9bdd + 0x0000
• Content hash: hash160 of the inscription enveloppe - 20 bytes
• Output post-reveal: Outpoint pointing to the satoshi, post reveal - uint16
• Offset post-reveal: Outpoint pointing to the satoshi, post reveal - uint64

Transfer events

• A satoshi is being transferred:

0        1        2                  36                         80                         124
|--------|--------|-------------------|-------------------------|---------------------------|
 Sequence  Action    Inscription ID      Satpoint pre-transfer      Satpoint post-transfer      

• Sequence : Sequence being inscribed - 0x00 if the sequence being indexed is the blessed sequence (which is the only stable sequence to date). We are versioning sequences because rules are changing overtime. Post-Jubilee, this byte will be bumped to 0x01.
• Action: transfer = 0x02
• Ordinal Number: Ordinal number being inscribed - uint128
• Inscription ID: Id of the inscription. Composed of:
  • Transaction ID - 32 bytes,
  • Inscription index (intra-transaction) - uint16
    Example: 94e524cbdaf19c27491ac6fe22e7884e35f11ee3ba290ddf218efeaf5d5e9bddi0 = 0x94e524cbdaf19c27491ac6fe22e7884e35f11ee3ba290ddf218efeaf5d5e9bdd + 0x0000
• Satpoint pre-transfer: Satpoint pointing to the inscription id, pre transfer. Composed of:
  • Transaction ID - 32 bytes,
  • Output index - uint16
  • Offset - uint64
• Satpoint post-transfer: Satpoint pointing to the inscription id, post transfer. Composed of:
  • Transaction ID - 32 bytes,
  • Output index - uint16
  • Offset - uint64

Outcome

Implementing this protocol will lead to:

• Enhanced data provability and integrity within the ordinals ecosystem.
• Reduced instances of regression and indexing errors.
• Streamlined upgrade processes for ordinal indexers with reliable checkpoints for data validation.

[raphjaph]

How would the Merkle tree be built exactly?

Just the hash of these events paired up sequentially by the order they occur?