Multi-version protocol support in transaction indexer

[kalloc]

Description
The indexer currently supports only a single protocol version for transaction decoding.
When a protocol upgrade happens, transactions may be encoded differently, leading to decoding errors.
We need to add support for handling multiple protocol versions (old + new) during and after upgrades.

Proposed Solutions

1. Multi-decoding attempt

   • Try decoding with the old version first.
   • If it fails, attempt decoding with the new version.
   • Useful when no strict slot boundary is known.

2. Slot-based flag switch

   • Define a specific slot number in configuration.
   • Before that slot → use old decoder.
   • After that slot → use new decoder.
   • Predictable and efficient when upgrade slot is known.

Acceptance Criteria

• Indexer correctly decodes transactions from both protocol versions.
• Decoding errors from old/new versions do not crash the indexer.
• Ability to configure strategy:
  • Multi-decoding
  • Slot-based switch
• Configuration is documented and easy to update.

Priority
High — required for stable operation during protocol upgrades.

Implementation Notes

• Add protocol version handlers to the decoding layer.
• Support strategy selection via config.
• Ensure logs clearly indicate which decoder was used.

Let's discuss it

[kalloc]

@sonicfromnewyoke I wana do it, but I need your advices

[sonicfromnewyoke]

@sonicfromnewyoke I wana do it, but I need your advices

i'd prefer to simply reuse the method what is in use in geyser like replica account info

so, you just have aenum with all the supported versions. On the decoding side you just parse the incoming data against the enum and pass further.
On the receiver side - you match this enum and pick the fitable version for you

this is the only way to not sink in the complexity of maps, slots, block heights when the update was deployed, etc

your thoughts @kalloc @KellianDev ?

[kalloc]

Use account change as a trigger of update?

[sonicfromnewyoke]

Use account change as a trigger of update?

no, without any kind of triggers. Simpler, just keep all the versions in one enum, defined on the compile time (similar to what you described in the 1st proposed solution).

carbon aims to be the indexing framework, so it means that carbon should be able to index data from snapshots, and historical data streams.

the approach that you described as a 1st proposed solution sounds as a best one to me, prom the perspective of further development of carbon

P.S. i'd even prefer to use external sdk-s (like meteora sdk, or orca's) in the enum of program. Like different versions of sdk satisfies different versions of the program

[kalloc]

Use account change as a trigger of update?

no, without any kind of triggers. Simpler, just keep all the versions in one enum, defined on the compile time (similar to what you described in the 1st proposed solution).

But, it may increase CPU usage. Would it be a problem?

[sonicfromnewyoke]

Use account change as a trigger of update?

no, without any kind of triggers. Simpler, just keep all the versions in one enum, defined on the compile time (similar to what you described in the 1st proposed solution).

But, it may increase CPU usage. Would it be a problem?

you are right. This slightly increase the CPU usage. However we have a room for performance optimisations:

• using borowed types insted of owned
• zero-copy (borsh -> bytemuck)
• get rid of allocations
• etc

should be more than enough to make it even more performant than now