Which operations can change ethereum address balance?

Question

I am writing a program that would monitor changes in balance of a set of ethereum addresses. I did the same for UTXO based coins, and the logic was pretty simple. All of the changes were directly recorded in blocks. But ethereum appears to be more complicated. Which operations I have to monitor to be sure I won't miss anything? It is important that I have to monitor changes of balance, not the balance itself.

Operations that are capable of changing balance, that I found:
1. Basic transactions on the blockchain level
2. Block rewards for mining
3. Smart contract internal transactions

Is there anything else that I have to be aware of? When ETH 2.0 arrives, will the staking reward format be different from the current types of balance update?

Answer 1

I would add SELFDESTRUCTs to the list. They are quite unique, as they can transfer ether to a smart contract without executing its code. Also, I would add special one-time transfers performed by EIP-779 at block 1920000.

Answer 2

You can try making a list of operations, but the most robust would be to run an instrumented node that processes every transaction as mentioned for example in How to get contract internal transactions

The third item in your question will already require it.

As @Mikhail noted, SELFDESTRUCT is also an important one.

Another case I can think of that you are missing is sending ether along with contract creation.

So rather than trying to create a "list of operations", it's probably most robust to have an instrumented node processing every transaction, than try to figure out all the edge cases. There might be scenarios with CREATE2 (along with SELFDESTRUCT). (There's also the irregular state change mentioned by @Mikhail.)

If the attempt to have a "list of operations" is to be able to check statically without processing transactions, there's probably a theory that the EVM's pseudo Turing Completeness means it's not possible to do statically: you have to run EVM code to determine if it actually did change the balance of an address.

Answer 3

As noted by both users above @mikhail-vladimirov and @eth SELFDESTRUCT is a unique method (meaning not used often) for transferring ETH

The two main benefits of this method are:

1: you do not execute code on the receipt (as noted by Mikhal) and

2: Gas cost savings are optimized by repeatedly invoking selfdestruct() at a single contract address.

Due to the SELFDESTRUCT opcode implementation, the contract's state object is only removed after the entire transaction call terminates.

This means the contract instance can continue to be called and receive ether even after invoking SELFDESTRUCT, as long as it is within the same transaction call. Instead of creating a selfdestructing contract for each payment, significant gas savings are achieved by repeatedly reusing the same contract instance for invoking SELFDESTRUCT.

See the go-ethereum implementation of SELFDESTRUCT, marking state object for as suicided, and flagging the state object for deletion to see the nuances of the SELFDESTRUCT opcode.

Here are some examples of its usage:

Described by Ethereum Core Contributor holiman posted Jun 18, 2016 https://gist.github.com/holiman/f66bae83540728c209e521c42bd06362

Used by MakerDAO

https://github.com/nexusdev/solidity-quirks/blob/3ebdffe3425f47b84538631f811b81a49e4c54d8/contracts/delivery_test.sol

A Modern (pragma solidity >0.7.0) usage of this pattern: https://github.com/etherportal/EtherPortal/blob/main/contracts/EtherPortal.sol

Cheers