New transaction formats

[vbuterin]

Specification

When block.number >= FORK_BLKNUM, allow two new types of transaction:

[0, network_id, nonce, gasprice, startgas, to, value, data, v, r, s]
[1, network_id, startgas, to, data]

The first type of transaction replicates the functionality of existing regular transactions, with the sender equal to ecrecover(sha3(rlp.encode([0, network_id, nonce, gasprice, startgas, to, value, data])), v, r, s), and the second type replicates the functionality of EIP #208 (formerly EIP #86) transactions, where the sender is set to NULL_SENDER (a constant equal to 2^160 - 1).

When block.number >= DEPRECATION_BLKNUM (set DEPRECATION_BLKNUM = FORK_BLKNUM + 500000), disallow the older transaction types.

Specification, version 2

Have a hard "meta-standard" that ALL present and future transactions will have the following form:

[version_number, network_id, protocol_specific_params, data]

Under this standard, implement the above as:

[0, network_id, [nonce, gasprice, startgas, to, value, v, r, s], data]
[1, network_id, [startgas, to], data]

Specification, version 3

Add a valid_until field to type 0 transactions (and also type 1 transactions, or not? Should discuss) immediately before the "nonce" argument in type 0 transactions, and immediately before "startgas" in type 1 transactions.

Rationale

Creates a cleaner and more forward-compatible way of representing transactions, as well as removing technical debt created by EIP #208 and EIP #155 and replacing it with more explicit mechanisms that achieve the same function.

Also, upgrades replay protection with ETC and other alt-ethereum chains by making it compulsory and two-way.

Version 2 has the benefit that it makes a principled distinction between parameters that the protocol cares about and parameters that account code cares about, and makes an explicit 2-layer data structure when with EIP 86 the data structure will have to become 2-layer anyway with nonces, gasprices and the like being part of the transaction data field.

In future transaction versions, arguments could be added such as:

• Subsets of address space that the transaction has read and write permission to (eg. four fields could be added for READSTART, READEND, WRITESTART, WRITEEND, which would accept 0-20 bytes as arguments, and would, with zero-byte-right-padding, represent the minimum and maximum addresses that the tx can read and write to). This would improve parallelizability.
• Information about what shard the transaction is intended for.
• If the gas schedule becomes multidimensional (eg. a 2D scheme with the second dimension being storage pricing is quite possible), startgas may need to be replaced with a vector.

[winsvega]

[0, network_id, nonce, gasprice, startgas, to, value, data, v, r, s]
[1, network_id, startgas, to, data]

is startgas = gasLimit in terms of RLP ?
what is 0 and 1 and network_id ? is it new fields encoded in RLP ?

[vbuterin]

0 and 1 are transaction version numbers. network_id is the same as in EIP155. Yes, startgas = gaslimit.

[winsvega]

so new RLP format of the transaction? are you sure?

[vbuterin]

It's merely a proposal for now :)

[winsvega]

should we close this issue?

[janx]

+1, much more simpler than current tricks, and it can also accommodate future changes.

Q: what's the point of leaving startgas as a separate field?

[axic]

I would propose:

[0, flags, network_id, nonce, gasprice, startgas, to, value, data, v, r, s]
[1, flags, network_id, startgas, to, data]

Where flags can enable features (i.e. fields specified). Bit 0 of flags could stand for "valid until block", a number present after data or s, which refers to the feature specified in #599.

Admittedly, in case of version 1, the valid until block feature could be part of the contract and supplied through the "data" field. Though that would not remove a transaction from the memory pool until it is actually executed.

Examples:

[0, 0, network_id, nonce, gasprice, startgas, to, value, data, v, r, s]
[0, 1, network_id, nonce, gasprice, startgas, to, value, data, v, r, s, 4200000]
[1, 0, network_id, startgas, to, data]
[1, 1, network_id, startgas, to, data, 4200000]

[vbuterin]

Assuming EIP 599 is included, are we expecting the valid_until field to be used some of the time, or most or all of the time? If it's the latter, then it should just be part of the base data structure without any dependency on flags.

[Arachnid]

It's only really useful if nodes generally refuse to relay transactions that don't include it (or have it set excessively high), which means we would expect most or all transactions to include it.

[emansipater]

Simple suggestion to improve atomicity: what if in this new transaction format the absence of a "to" address meant that the code from data was run in the context of the originating account (as opposed to in the context of a newly created contract, as is currently done). One such piece of code could be the creating of a new contract of course, but there could also be arbitrary operations done with the EOA as message.sender, including multiple interdependent calls, finally making EOAs equal to contracts in their capabilities. This would be a significant improvement allowing for things like: Looking up an ENS entry and then performing an operation towards it; making purchases from multiple contracts only if all of them succeed, sending a payment directly to a multisig and then immediately registering the payment with another contract during a crowdsale, etc. etc. etc. Right now EOAs themselves can't do any of these things, and it would be a fairly simple change.