I’ll try to explain why it is more problematic to track the receivers than the spenders, just to see why this isn’t already there in the node.
There are two ways tokens enter the system:
Through migration (i.e., in the genesis block and in the hard forks).
This is accounted for in the json files associated with the migration.
Through mining (i.e., the beneficiary rewards)
This is accounted for with the coinbase reward for each height.
Migrated tokens enter the system only at the first key block of a consensus protocol version:
- The genesis block.
- The hard fork blocks with associated token migration. All hard forks so far have an associated token migration.
Reward tokens enter the system at each key block (except for the genesis block), and are immediately put into the lock account where they stay for the reward delay period.
So, to sum this part up:
- Migrated tokens end up in their accounts in the json file.
- Reward tokens end up in the lock account.
The more interesting (and difficult) part is the distribution of tokens from one account to another.
All transactions are associated with the nonce of exactly one account. In a few cases (e.g., state channels) more than one account needs to sign the transaction, but the transaction itself is always associated with exactly one account, through the account nonce. So, all transactions has a unique combination of account and nonce.
However, the transactions can distribute tokens from multiple accounts, and to multiple accounts.
Even the simplest transaction, the spend transaction, decreases tokens from the sender account (amount and fee), and increases tokens for two accounts (the amount to the receiver, and the fee to the lock account for the duration of the reward delay).
And a contract call transaction can spend tokens to any number of accounts, and even from any number of accounts either through calls to other contracts, or by signature delegation for naming service or oracle operations).
So, even for the actual transactions, it is not simple to see how a transaction distributes tokens from and to accounts.
Then we have the distribution that happens without explicit transactions.
Again, the introduction of migrated tokens are pretty straightforward, and can be seen in the json files, so I won’t spend more time on that now.
After the reward delay, the coinbase and fees are distributed from the lock account according to this:
- The coinbase of a key block goes to the beneficiary in that key block.
- The fees of a generation of micro blocks are split between the beneficiaries of the opening and closing key blocks of that generation.
- If there was a report of fraud (Proof of Fraud), the fraudulent miner doesn’t get anything, the reporter gets a fraction, and the remaining sum is given to the lock account.
After the BRI entered the protocol, a part of the previously described rewards goes to the BRI account.
In the beginning of development, we did have coinbase transactions for rewards, but they caused more difficulty than the problem they solved. I do agree that for the purpose of accounting, the transactions would have been nice, but they would also have increased the size of the chain, and they would not have solved the whole problem (e.g., the distribution from the ordinary transactions).
One thing we have discussed, and it even went as far as a couple of weeks of development, is to record the side effects of each transaction. The effort was cancelled since it turned out to be harder than expected, and we had more pressing matters to attend to. I personally think we should have pursued this effort, but it is a matter of priorities.
The side effects could be of different nature, but the most straightforward one would be to record every increase and decrease in balances of accounts, tied to every transaction. The same could also be done for each key block. The numbers are of course there already in the node, but collecting them isn’t as easy as it might seem. In particular, doing it without significantly increasing the processing time is hard.
The problem can be solved by having a specialized node which only validates the chain and records the side effect. And this was also once the ambition. The current middleware initiative is what came out, and while it doesn’t give all the information one could whish for, it certainly helps out with some solid information.
The only proper solution (note: my personal view) to this problem is to have an instrumented node, with proper regression testing etc, where the instrumentaion can be removed in compile time to not inflict any decrease in execution performance if you are not interested in the information.
Such a node could have an API for proper accounting of all token transfers. And then a third party software could audit these token transfers and check them against the balances and root hashes.
I hope I at least shed some light into why the information you want is not there (yet). I do agree that this information should be as transparent as possible, and accesible to more people than the core developers.
Please keep pushing for it, and we will hopefully get it there at some point.