Aimeedeer
Add a "what is a transaction?" section to about page
As more people look at realtps and more chains are included, with more differing transaction models, we're going to need to be more specific about what we track.
What we consider a transaction is not very clear, and with the prospect of integrating ICP (https://github.com/Aimeedeer/realtps/issues/41), which has some new semantics yet to what we've previously integrated, I am thinking about what exactly it is we are counting.
We also need to consider "what is a chain?". For example, near has sharding and we are counting transactions across all shards. Avalanche and Polkadot have subnets, but they are more independent, and we consider them separately. We need to justify this somehow. ICP has subnets, but they operate kinda automatically, more like shards, and I would probably consider throughput of the entire network, subnets included.
Right now I am thinking:
- EVM is kind of our baseline, we can always draw comparisons to an EVM transaction. If it looks like an EVM transaction it is a transaction.
- Our "transaction" is more like "an atomic user write request". The definition of transaction differs from chains, but what we are looking at is how many user-originating writes a system can process per unit time.
- Subnets / shards that are "integrated" from a user standpoint are collated into a single number. Subnets that appear to the user as distinct networks are tracked separately.
Solana and Stellar pack "instructions" / "operations" into atomic "transactions". On solana we count transactions, on stellar we count operations. That is not a reasonable inconsistency.
DAG networks so far seem to have some type of collation service that periodically checkpoint their dag into linear blocks; similar to how near packs its subnet activity into "hyperblocks".
Another completely different option would be to give chains the most generous definition of a transaction: ICP->all update messages, stellar->ops, solana->all instructions (including vote instructions).
That would require no judgements, though I think the main purpose of this site is to make those judgements, to make a reasonable comparison.
Either way, we're going to end up writing prose for most chains to explain the exact methodology.
If the matter gets contentious we may end up compromising and providing two numbers: the most generous number (the ones chains prefer), and a "normalized" number that attempts to provide the most reasonable comparison.
Providing two values is probably the way to go.
As hard as it is to determine a common "unit" for transactions on different chains, it is essential. Otherwise the whole point of ranking them all in one table becomes meaningless (like comparing kilometres and miles).
But to not show the underlying, chain specific, transaction count which each chain publishes is a loss of information.
