Indexer Inner Transaction Design

Confused about this indexer database design decision. Why are inner txs stored twice?. Take for example round 23645256 intra 62 in the txn table. They are stored initially in the itx field in round 23645256 intra 62 and then those same fields are repeated on intra 63, intra 64, and intra 65.

See image:

Why even bother repeating these rows? Seems like a waste of extra rows when this info is already available in the root txn.

This is optimized for querying, by structuring it this way we’re able to match on an inner transaction and return the root transaction.

For more efficient storage, it would probably be better to reconstruct the inner transaction tree from individual transactions. The downside is that would require a more complicated query and more post processing to reconstruct the original root transaction.

Some of these decisions were speculative. We didn’t know how inner transactions would evolve so we wanted to keep things simple and flexible. As you’ve observed, the cost to that simplicity is that inner transactions are stored twice.

1 Like

Thanks for the response! That makes sense. If I may follow up with another question. I was gonna make a separate post but not sure if that makes sense since it’s very specific.

Regarding the ledger tx count being included in the block_header, I noticed it started at block 3317192. Before this block, there was no tx count included. Wondering why block 3317192 lists the tc at 1. It also stays at 1 for 2 blocks before increasing to 2 at block 3317194. The first tx on mainnet definitely did not happen at block 3317192 so why was it initialized at 1?

The TxnCounter was not part of the consensus protocol when we launched, which is why you don’t see it until round 3317192 on mainnet. In addition, there were some empty blocks before it. The value would have been omitted until the first transaction after the protocol upgrade.

It looks like there was one transaction on round 3317192, which is why you see the value is 1. There were no transactions on round 3317193, so it remained 1. There was one transaction on round 3317194, so it was incremented to 2. Etc.

So is the txn counter not the true count of all txns on the blockchain since it omits those txns which occurred before block 3317192? Also how were ASA/App ID’s determined prior to the inclusion of a txn counter?

TxnCounter was added along with ASAs as a way to generate the unique IDs :slight_smile:

1 Like