...
The SELFBALANCE opcode was introduced as part of EIP-1884 in the recent Istanbul upgrade. It provides for cheaper access to the Ether account balance of the “current address.” Newer versions of Solidity will use this operation where appropriate only if Solidity is instructed to target the Istanbul opcodes.
On December 13, 2019, when trying to process mainnet block #9100883, Besu logged an `InvalidBlockException` error. Upon closer inspection, it was found that when processing transaction 0xea29026a2957e47513ae8e99c2aa513d44e17ab66a86e4a66850448cc0639dd6, which used the SELFBALANCE opcode in a contract that was called via a DELEGATECALL, instead of returning the balance of account 0xdacb1734b3259d98c8fdc755993209f9c4682cd2 (which had value), Besu returned the balance of account 0xbdbe2fb20656378753223e3f9ad08840dc579a8c (which had no value).
This led the client to execute a different block of code for zero balance conditions and produce a different result for the transaction, which resulted in a different world state and receipts hash than the block had reported. Because the receipt root hash did not match Besu rejected the block as invalid and stopped processing mainnet blocks. No additional blocks were mined on Besu after the consensus issue, so a chain split did not occur.
Upon further inspection of the EIP, it was found that the EIP did not specify a need for test cases in DELEGATECALL stacks, and no reference tests cover the operation of the SELFBALANCE in any composed context (CALL, CALLCODE, or DELEGATECALL). The sample Geth code in the EIP also implied that the contract address was the appropriate address, but the semantics of the Contract class in go-ethereum and the address of the contract maintained in the Besu MessageFrame differ.
Luckily, because Geth, Nethermind, and Parity produced the same behavior when calling SELFBALANCE through a DELEGATECALL, all other clients stayed in consensus.
...