I like to reduce the transactions sizes by separating my wallet into groups by usage, so that i on’t have to toch token-holding utxos while only sending ada. A lot of dApp txbuilders do like to consolidate your utxos into a huge one holding all your ada and tokens. Especially those coming from ergo ecosystem, where the have utxo storage rent, to minimize it. Though just thinking about it, a tx that only takes ada from a token-holding utxo shouldn’t need to include any information about the tokens in the tx. Don’t you only have to reference and sign the input utxos? Their content are alraeady known from the previous transation that created them, and if all the tokens go back to change, the coins going to change address can be deterministically computed as “sum(inputs) - sum(recipient outputs) - fee”.
If the txdata was only stored minimalistically excluding all this redundant information that the syncing nodes already know or can compute, it would reduce tx sizes and fees, and the blockchain bloat, and allow a bit higher TPS. And it would make those utxo consolidations make sense and make them more optimized than grouped utxos.
1 Like
In principle, this could maybe work, but:
- At the moment none of the outputs of a transaction has a special role from the point of view of the blockchain. That one of them is a change output is only a concept known to the wallet app building the transaction, but the chain only cares that the sum of all outputs (plus fee plus deposits deposited plus native tokens minted) is the sum of all inputs (plus rewards withdrawn plus deposits paid back plus native tokens burnt). To realise what you suggest, we would have to introduce a new concept of change output on the blockchain/ledger level taking everything that is left.
- The inputs are only referenced by transaction hash and index. A wallet app building and a node validating a transaction have to look up what actually is on that input in the set of still unspent transaction outputs, UTxOs, the ledger. With your suggestion, the change outputs wouldn’t carry that information directly anymore, but it would have to be computed from the transaction which means all inputs and outputs of that transaction have to be kept, even if they themselves are already spent. Worse, some of the inputs might also be such change outputs, so the transcactions that have created them would also have to be kept completely and computed over and over again.
- In the end, this would massively blow up the information nodes have to keep in active memory (in contrast to historical blocks, they only keep the ledger, the current UTxO set there at the moment).
So, no, while the current representation of transactions might be a bit redundant (only a bit because only one output could be computed in that way, all others have to be given explicitly), I don’t think your suggestion of one implicit output is better in the end.
Better UTxO management by wallet apps and dApps should be the goal. (Actually, I don’t think that it’s a good design that dApps can and do mess with users’ wallets. Should be decisions of the wallet app, not the dApp.)
2 Likes
Great that it’s already not rendundant in the inputs, i couldn’t test that as any token transaction would have the token in both inputs and outputs so i was not sure if those bloat the chain, i could only test, that puttin the tokens in recipient or change address didn’t affect the tx size. Still not sure why the change address couldn’t have the contents empty so they could be calculated as the remainder. Since so many transaction put most tokens into change, it could optimize the size a lot. Why couldn’t a next hardfork introduce such option (if 1 output is missing coin/token contents, then consider it change and calculate it, more than 1 empty outputs or not enough remainder to fill the empty output’s minimum ada would be considered invalid).
Proper wallet manangement does help, but when you want to use dApps, you are at mercy of their tx builders that often mess up your management.
Because later transactions need the information what exactly is on which output. Having wallet apps and nodes need to recalculate that for change outputs every time they are used (even indirectly) is far worse than the little bit of redundancy and cost for users using suboptimal wallet apps and dApps.
would those queries always ask some fullnode or snapshot in the end, which already had it computed once? The node memories would have the change outputs already calculated during syncing. Only the storage on the actual chain would miss that redundancy.