status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 20:28:21 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 2711 (#2728)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Micah Zoltu 2020-06-16 11:01:35 +08:00 committed by GitHub
parent b6c0299bb5
commit c6e7099625
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
EIPS/eip-2711.md
View File

@ -28,12 +28,13 @@ As of `FORK_BLOCK_NUMBER` an [EIP-2718](./eip-2718.md) transaction with a `Trans
* `[0, nonce, to, value, data, chainId, gasLimit, gasPrice, senderV, senderR, senderS, gasPayerV, gasPayerR, gasPayerS]` * `[0, nonce, to, value, data, chainId, gasLimit, gasPrice, senderV, senderR, senderS, gasPayerV, gasPayerR, gasPayerS]`
* `[1, nonce, to, value, data, chainId, gasLimit, senderV, senderR, senderS, gasPrice, gasPayerV, gasPayerR, gasPayerS]` * `[1, nonce, to, value, data, chainId, gasLimit, senderV, senderR, senderS, gasPrice, gasPayerV, gasPayerR, gasPayerS]`
* `[2, nonce, to, value, data, chainId, senderV, senderR, senderS, gasLimit, gasPrice, gasPayerV, gasPayerR, gasPayerS]` * `[2, nonce, to, value, data, chainId, senderV, senderR, senderS, gasLimit, gasPrice, gasPayerV, gasPayerR, gasPayerS]`
* `[3, nonce, to, value, data, senderV, senderR, senderS, gasLimit, gasPrice, gasPayerV, gasPayerR, gasPayerS]`
`senderV, senderR, senderS` is a signature of an RLP array of the items preceding the sender signature items. The address recovered from this signature is the address returned by the `CALLER` opcode (0x33, aka `msg.sender`) for the first level of the transaction, and the address whose `nonce` is used, and the address whose ETH is deducted if any value is attached to the transaction. `senderV, senderR, senderS` is a signature of an RLP array of the items preceding the sender signature items. The address recovered from this signature is the address returned by the `CALLER` opcode (0x33, aka `msg.sender`) for the first level of the transaction, and the address whose `nonce` is used, and the address whose ETH is deducted if any value is attached to the transaction.
`gasPayerV, gasPayerR, gasPayerS` is a signature of an RLP array of the items preceding the gas payer signature items. The address recovered from this signature is the address returned by the `ORIGIN` opcode (0x32, aka `tx.origin`) for the transaction, and the address whose ETH balance the gas costs for the transaction are deducted from. `gasPayerV, gasPayerR, gasPayerS` is a signature of an RLP array of the items preceding the gas payer signature items. The address recovered from this signature is the address returned by the `ORIGIN` opcode (0x32, aka `tx.origin`) for the transaction, and the address whose ETH balance the gas costs for the transaction are deducted from.
Both signatures for this transaction type have a `v` value that is either `0` or `1` and represents the parity of the `y` value of the ECDSA signing process. Both signatures for this transaction type have a `v` value that represents the parity of the `y` value of the secp256k1 signing process where `0` means `y` is even and `1` means `y` is odd.
If the `chainId` is `0` the transaction **MUST** be valid on all chains. If the `chainId` is not `0` then the trnsaction **MUST NOT** be valid on any chain that doesn't have a matching `chainId`.
### Example ### Example
``` ```
@ -76,7 +77,7 @@ rlp([
## Rationale ## Rationale
### ChainID not encoded with `v` ### ChainID not encoded with `v`
While we could save one byte in the common case by bundling the y-parity bit of the signature with the Chain ID like in EIP-155, this adds complexity to signing tools that the authors deem not worth it given the size (in bytes) of the transaction overall. While we could save one byte in the common case by bundling the y-parity bit of the signature with the Chain ID like in EIP-155, this adds complexity to signing tools that the authors deem not worth it given the size (in bytes) of the transaction overall.
### Optional ChainID for subtype 3 ### ChainID 0
Sometimes it is useful to have a transaction that *can* be replayed on multiple chains. An example of this is when you construct a vanity signature for a transaction and have the `from` be whatever address that signature recovers to. With the ability to have someone else be a gas payer (setting both the gas limit and the gas price), one can have transactions that deploy contracts which live at the same address on every chain. While this can be accomplished with CREATE2 using legacy transactions, we have the opportunity here to simplify the process and enable potentially other future uses of deterministic transactions by making ChainID optional. Sometimes it is useful to have a transaction that *can* be replayed on multiple chains. An example of this is when you construct a vanity signature for a transaction and have the `from` be whatever address that signature recovers to. With the ability to have someone else be a gas payer (setting both the gas limit and the gas price), one can have transactions that deploy contracts which live at the same address on every chain. While this can be accomplished with CREATE2 using legacy transactions, we have the opportunity here to simplify the process and enable potentially other future uses of deterministic transactions by making ChainID optional.
### `SENDER` sets `gasLimit` and `gasPrice` ### `SENDER` sets `gasLimit` and `gasPrice`
This type of transaction is useful when the transaction may execute differently depending on what these values are set to. By having the `SENDER` set both, we ensure that the `SENDER` has full control over the transaction details. This type of transaction is useful when the transaction may execute differently depending on what these values are set to. By having the `SENDER` set both, we ensure that the `SENDER` has full control over the transaction details.