List of touched accounts per tx

[lrettig]

in general this is exactly the list with addresses (accounts) that were updated by this transaction

for example spawn (when it will be supported) will update two addresses:

• principal that pays for gas
• spawned account with additional state (attached template and immutable state)

spend updates 2 accounts:

• principal - gas and balance
• receiver - balance

and so on

_Originally posted by @dshulyak in https://github.com/spacemeshos/api/pull/165#discussion_r909189063_

[lrettig]

@WilfredTA could you weigh in here? I just want to make sure this is doable from the VM perspective (and doesn't cause any major design challenges or inefficiencies). Can the VM easily tell the node which accounts/addresses were "touched" by a given tx? This would include (as @dshulyak points out) balance updates and newly spawned accounts, but presumably with cross-contract calls (internal messages) it would include any account with any state change. Some things to keep in mind:

• how will this data pass across the node<>VM API?
• do we only want to return the list of touched account addresses? or also the state items? or also the actual changes? (e.g., as part of a receipt, see statechange view on etherscan for example). if the latter, what does this data structure look like? how do we capture balance change, nonce change, newly-created account, state item creation/update/delete, etc.?

Also from a usability perspective there are probably classes of state updates that a user may not care about - not something we need to worry about at this moment but worth keeping in mind.

[dshulyak]

By actual changes you mean something like ethereum logs? I think they should no be indexed by the node, what ethereum implemented is very complex (custom query lang), slow and has poor ux. Pretty sure that eth devs would like to get rid of that, but can't at this point. So in practice every indexer (such as etherscan) has to re-index logs in a more performant and easier to use way, which is completely possible using existing query languages (sql/graphql/mongodb lang) and database engines.

So what i suggested is a simplification for a node and svm. Which is i think makes a lot of sense under account abstraction model. We will provide efficient api to query transactions that changed the address. And the consumer of the api is free to index those transactions the way it wants to.

[lrettig]

We will provide efficient api to query transactions that changed the address. And the consumer of the api is free to index those transactions the way it wants to.

Right, but the consumer also needs to know the effects of executing the transaction to properly index it, right? E.g., log outputs, state updates, etc. How does the node communicate this to the consumer?

[dshulyak]

i thought that log outputs will be communicated using additional field on the transaction result. consumer on their end will have an ABI for template that will allow them to decode the log.

there will be some challenges with encoding logs from cross-contract calls. i think they can be solved by specifying event types in the template interfaces, as an option.

ABI should also include metadata that will allow to decode transaction body (not headers). for example for genesis i assume that smapp and explorer will parse transaction type and show relevant info, for example:

• tx type label (spawn/spend)
• for spawn - template address
• for spend - recipient and amount

[lrettig]

Agree re: per-contract/template ABI, but I think state changes are a little different than encoding tx body or logs/events. Ethereum does not include this in the ABI (JSON). The only way to get it is to run a full/archive node in trace mode. We need some sort of API service/endpoint for this. Anyway it's beyond the scope of this issue, I'll open another to investigate.