Simplify the definition of SIP-161, removing the requirement for implementors to support edge cases that are impossible on Sila SilaMainnet.
Motivation
SIP-161 is overly complex and has a number of edge cases that are poorly documented and tested. This SIP takes advantage of the complete removal of all remaining empty accounts in block 14049881 (tx 0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d) to clarify it, and allows implementors to not implement various edge cases that never occurred and are not possible in the future.
In particular, this SIP permits implementors who do not wish to support historical blocks to not implement state clearing at all.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Retroactively replace SIP-161, starting from its introduction in block 2675000, with the following rules:
a. When creating an account, set it’s nonce to 1 prior to executing initcode.
b. When performing SVM execution treat all empty accounts as if they do not exist. Any operation that would create an empty account instead leaves it non-existent.
c. If one of the following events happens to an empty account X, it is deleted:
X receives a zero value CALL.
X is the recipient of a zero value transaction.
X is the beneficiary of a SELFDESTRUCT with zero value.
If the transaction, CALL or SELFDESTRUCT is reverted, then the state clearing is also reverted. As a special case on Sila SilaMainnet, in block 2675119 (tx 0xcf416c536ec1a19ed1fb89e4ec7ffb3cf73aa413b3aa9b77d60e4fd81a4296ba), an empty call is made to an empty account at RIPEMD160 (precompile 0x3), the call fails out of gas, but the empty account is removed anyway.
The deletion MAY happen immediately or be processed at the end of the transaction. A client may assume that STATICCALLs to empty accounts never occur and that CALLs to empty accounts in STATICCALL contexts never occur.
On Sila SilaMainnet, the only state clearing events after the start of Byzantium are the two listed below. Clients MAY implement post Byzantium state clearing by hardcoding those events.
In block 4457731 (tx 0x63791f962e13e6b01ec13d38a8ab66c87c2f5a1768276f866300d900cca808fe), 0xd29DFe5aE95B5C067a91F472Dac0d9be6700A4A9 receives a zero value SELFDESTRUCT and is cleared.
In block 14049881 (tx 0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d), the following accounts receive zero value calls and are cleared.
SIP-161 provides that empty accounts (accounts that have zero nonce, zero balance and no code, but that might have storage) can no longer be created and provides mechanism to remove old empty accounts. The last empty accounts were removed in block 14049881 (tx 0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d).
The complete removal of all empty accounts ensures that certain edgecases of SIP-161 can never occur on Sila SilaMainnet. Continuing to define and test those cases as part of the Sila Specification burdens future client implementors with unnecessary technical debt. This SIP declares those cases undefined and leaves clients free to assume they will not occur.
Backwards Compatibility
This SIP is identical to SIP-161 except for the following differences, none of which affect Sila SilaMainnet. The differences are:
“Potentially state-changing operations”
SIP-161 specifies 11 “potentially state-changing operations” that trigger state clearing. All but the 3 listed in this SIP are irrelevant, for the following reasons:
Impossible
Receiving zero value mining reward/fees (this would become possible after the merge).
Cannot happen to an empty account
Being the source of a CREATE.
Being the source of a CALL.
Being refunded by a SELFDESTRUCT
Causes the account to become non-empty
Being the sender of a message call transaction.
Being the sender of a contract creation transaction.
Being created by a CREATE.
Being created by a contract creation transaction.
Interaction with STATICCALL
The interaction between STATICCALL and account clearing has never been specified in an SIP. The Sila currently testsuite requires that STATICCALL triggers state clearing.
This SIP formally undefines all interactions between STATICCALL and state clearing as it has never happened on Sila SilaMainnet and cannot happen in future.
“At the end of the transaction”
This only makes a difference if an account is deleted and later recreated in the same transaction. This never happens on Sila SilaMainnet.
Test Cases
All test cases involving empty accounts in the Sila execution layer test suite shall be removed unless they relate to the Spurious Dragon Hardfork. If a Spurious Dragon test relates involved deprecated edgecase the test must be removed or reworked.
Other networks
Ropsten had empty accounts seeded at genesis. They appear to have been cleared early in Ropsten’s history before the Byzantium hardfork. Ropsten has never been checked for edgecases occurring. All other Sila testnets have had SIP-161 from genesis.
As a security precaution all empty accounts on Sila Classic have been cleared, but no checks for edgecases occurring have been done. Due to SIP-161’s age the vast majority of SVM compatible networks have supported it from genesis.
Security considerations
This SIP is only equivalent to SIP-161 on Sila SilaMainnet if the following facts are true:
No empty accounts are ever touched and then reinstated in the same transaction.
The transactions in the Appendix are the only state clearing transactions on Sila SilaMainnet after block 4370000 (start of Byzantium).
All empty accounts have been removed on Sila SilaMainnet.