Skip to content

Latest commit

 

History

History
41 lines (25 loc) · 3.48 KB

ECIP-1030.md

File metadata and controls

41 lines (25 loc) · 3.48 KB
Raw

Title

ECIP: 1030
Title: Defining the SYSTEM Transaction
Author: Wei Tang <[email protected]>
Status: Draft
Type: Standard
Layer: Meta
Created: 2017-08-24

Abstract

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 (ethereum/EIPs#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.

Specification

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 CALL, CREATE, CALLCODE, or DELEGATECALL opcodes MUST NOT execute a SYSTEM transaction.

A SYSTEM transaction MAY NOT be included in the block's transactions_root. 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.

Implementations

This ECIP has been implemented in SputnikVM (ETCDEVTeam/sputnikvm#251).

Discussions and Concerns

  • gas_price and gas_limit is still a variable in a SYSTEM transaction because different gas_limit can result in different execution results, and gas_price can be queryed in EVM.
  • EIP96 (ethereum/EIPs#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 from address in all SYSTEM transactions makes sure that they will never be considered valid user-executed transactions.