Whilst working on dapp (ldice) which requires transaction result to be produced during block creation I encountered couple limitations of custom transaction design. There are many use cases which are also crippled by the same limitation.
- There is no way to store transaction results in different asset than account.asset to enable undoAsset to work. It is the only way to enable undoAsset to reverse transactions properly.
- There is theoretical possibility to store result in transaction.asset however it will be rejected by node because node will attempt to validate result as part of signed body.
- Custom transaction db access is limited to sender, recipient and transaction itself, so there is no way to establish different db table with tx_id->result.
- Neither applyAsset nor undoAsset have ability to access last block signature.(results are deterministic, there is no point of saving results other than undoAsset in this specific case)
- Amount of transactions stored in account.asset could be limited to prevent performance drop, but that would mean that, reasonably no more than 500 bets could be made by each account. Not feasible.
- Store only N amount of last bet results per account, while N is based on BFT finality block count. I think this could actually work? (If HQ is not willing to introduce any other alternative, like below)
- LiskHQ could add option for additional db access by custom transaction, perhaps limited to transaction results. Different approach is to disable validation of specific tx asset, for example - asset.results, it could be reserved for results only, not be part of signed body.
Looking forward to discuss it further.