Proposal: Optimizing Ordinals Protocol Performance for Log-Based Protocols

[jolestar]

Background

The Ordinals protocol is currently facing a performance issue related to protocols built on top of it, such as BRC20, which use Inscriptions as logs. After these Inscriptions are inscribed and indexed, they essentially become obsolete, with users no longer concerned about them and often spending the BTC contained within. However, the Ordinals protocol continues to track SatPoint changes for these Inscriptions, leading to an increasing number of Inscriptions in certain transactions. This significantly impacts the performance of Ordinals protocol indexers.

Problem Statement

The continuous tracking of SatPoint changes for Inscriptions used as logs in higher-layer protocols (e.g., BRC20) is causing unnecessary computational overhead and degrading the performance of Ordinals indexers.

Examples of Problematic Transactions

To illustrate the severity of this issue, consider the following examples:

1. Transaction ID: 80c233e3d72b5dbb735b7e06acd4accd74f33b5703292a36d9d0faba79e45c63

2. Transaction ID: 832e9a18d07e9dcdaa21d4a2b548c28d17f0ad21ac5853976600d2c2853d4878

   The two transactions involve changes to over 10,000 Inscriptions. The sheer volume of Inscription updates in a single transaction demonstrates the scale of the tracking overhead.

Proposed Solutions

To address this issue, we propose the following solutions:

1. Selective Tracking of Inscriptions
   Implement a mechanism to stop tracking SatPoint changes for Inscriptions that are used as logs by protocols like BRC20. This would involve identifying such Inscriptions and excluding them from ongoing SatPoint change tracking.

2. One-Time Inscription Flag
   Introduce a new attribute or instruction at the Ordinals protocol level to flag an Inscription as "one-time" or "ephemeral". This flag would indicate that the Inscription should not be tracked for SatPoint changes after its initial inscription, similar to the OP_RETURN opcode in Bitcoin UTXO.

[casey]

Thanks for making this issue!

I think this is worth considering. We could add an optional flag, off by default, --no-index-brc20, which, if set, causes ord to treat BRC-20 inscriptions as being unbound. I.e, not having any particular location. ord would still recognize that these inscriptions were created, but would not track them.

However, we know that there are a large number of BRC-20 inscriptions, however, we don't know what the performance impact of these inscriptions actually is, so profiling whether or not such a change would impact indexing speed is the first thing that would need to be done.

Here's a branch which unconditionally unbinds BRC-20 inscriptions: 4a873d0

I have a bunch on my plate at the moment, and don't know when I'll be able to get to this.