This gives a standardized view of SYSTEM transactions – transactions that are enforced by block validity rules (i.e. if the transaction is not included, it is considered invalid) but not executed by users. Note that this does not change consensus at all, but just gives a unified view of a special type of transactions (which we already have – block rewards) in preparation of future extension (for example, EIP96 (https://github.com/ethereum/EIPs/pull/210) is one that uses SYSTEM transactions). Using this view, an Ethereum Virtual Machine itself can handle all account state changes without needing additional work from the client.
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.
We only define the semantics for SYSTEM transactions here but ignore encoding or decoding because it is not needed.
A SYSTEM transaction MUST NOT have a
from address. Thus it MUST NOT cost any account’s balance or gas to executed (which creating can create coins from “nowhere”). When executed in EVM, however, the
CALLER opcode MUST return address
0xffffffffffffffffffffffffffffffffffffffff. The nonce of the transaction MUST be 0. Besides those, it acts just like a normal transaction.
A SYSTEM transaction can only be executed as a top-level transaction in a block. In other words, EVM’s
DELEGATECALL opcodes MUST NOT execute a SYSTEM transaction.
A SYSTEM transaction MAY NOT be included in the block’s
transactions_root currently is used to only include user-executed transactions. (Block reward transaction, the only SYSTEM transaction we have right now, is not included in
transactions_root. So keeping the current semantics would be preferred.) It is considered to be enforced by the block validity rules, and the rules SHOULD contain enough information about details of all SYSTEM transactions to be executed, and when (before or after user-executed transactions, and the order of all SYSTEM transactions to be executed).
Block Rewards SYSTEM Transaction
The current block rewards can be considered as a SYSTEM transaction. Note that usually in other cryptocurrencies (like Bitcoin), block rewards are indeed usually considered a normal transaction.
This SYSTEM transaction would have its
gas_price set to 0, and
gas_limit set to 21000. It has the
to address set to the block miners, and the value set to 5 ETC. The
data for this transaction is empty.
This ECIP has been implemented in SputnikVM (https://github.com/ethereumproject/sputnikvm/pull/251).
Discussions and Concerns
gas_limitis still a variable in a SYSTEM transaction because different
gas_limitcan result in different execution results, and
gas_pricecan be queryed in EVM.
- EIP96 (https://github.com/ethereum/EIPs/pull/210), using its BLOCKHASH handled as a SYSTEM transaction, has the unsettled issue that whether the call executed by “SUPERUSER” is included in
transactions_root. It is recommended NOT to include it as to keep it compatible with this ECIP.
- Not having a
fromaddress in all SYSTEM transactions makes sure that they will never be considered valid user-executed transactions.