-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Comments
[0, network_id, nonce, gasprice, startgas, to, value, data, v, r, s] is startgas = gasLimit in terms of RLP ? |
0 and 1 are transaction version numbers. network_id is the same as in EIP155. Yes, startgas = gaslimit. |
so new RLP format of the transaction? are you sure? |
It's merely a proposal for now :) |
should we close this issue? |
+1, much more simpler than current tricks, and it can also accommodate future changes. Q: what's the point of leaving |
I would propose:
Where Admittedly, in case of Examples:
|
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. |
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. |
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. |
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:
The |
Would the (1) have a similar effect to this: #877 ? |
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. |
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. |
Specification
When
block.number >= FORK_BLKNUM
, allow two new types of transaction: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 toNULL_SENDER
(a constant equal to 2^160 - 1).When
block.number >= DEPRECATION_BLKNUM
(setDEPRECATION_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:
Under this standard, implement the above as:
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:
The text was updated successfully, but these errors were encountered: