Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New transaction formats #232

Closed
vbuterin opened this issue Mar 21, 2017 · 14 comments
Closed

New transaction formats #232

vbuterin opened this issue Mar 21, 2017 · 14 comments
Labels

Comments

@vbuterin
Copy link
Contributor

vbuterin commented Mar 21, 2017

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
Copy link
Contributor

[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
Copy link
Contributor Author

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

@winsvega
Copy link
Contributor

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

@vbuterin
Copy link
Contributor Author

It's merely a proposal for now :)

@winsvega
Copy link
Contributor

should we close this issue?

@janx
Copy link
Member

janx commented Apr 22, 2017

+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
Copy link
Member

axic commented Apr 23, 2017

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link

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.

@recmo
Copy link
Contributor

recmo commented Feb 6, 2018

To add to @emansipater's use cases: it allows you to atomically set an allowance on a number of tokens and call a contract using the tokens. This is very useful for decentralized exchanges.

Note that this code-in-context-of-from transaction (let's call it 'cicof') is a sole sufficient operator! All other current transactions types can be implemented as a cicof tx:

  • Ether send and contract call transactions both become a simple call cicof tx.
  • Contract creation becomes a create cicof tx.

The to and value fields can be dropped entirely from the transaction format as these are now unused.

@alexvandesande
Copy link

Would the (1) have a similar effect to this: #877 ?

@github-actions
Copy link

github-actions bot commented Jan 2, 2022

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Jan 2, 2022
@github-actions
Copy link

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants