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

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

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-17 13:16:34 +08:00 committed by GitHub
parent 632c56d500
commit 0298105902
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 26 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
EIPS/eip-2711.md
View File

@ -29,10 +29,26 @@ As of `FORK_BLOCK_NUMBER` an [EIP-2718](./eip-2718.md) transaction with a `Trans
* `[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]`
`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. Where `senderPayload` is one of:
`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. 1. `[0, nonce, to, value, data, chainId, gasLimit, gasPrice]`
2. `[1, nonce, to, value, data, chainId, gasLimit]`
3. `[2, nonce, to, value, data, chainId]`
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. `senderV, senderR, senderS` is the result of `secp256k1(senderPrivateKey, keccak256(rlp([1, rlp(senderPayload)])))`. The address recovered from this signature is the address...
1. ...returned by the `CALLER` opcode (0x33, aka `msg.sender`) for the first level of the transaction
2. ...returned by the `ORIGIN` opcode (0x32, aka `tx.origin`)
3. ...whose `nonce` is used
4. ...whose ETH balance is deducted if any value is attached to the transaction.
Where `gasPayerPayload` is one of:
1. `[0, nonce, to, value, data, chainId, gasLimit, gasPrice, senderV, senderR, senderS]
2. `[1, nonce, to, value, data, chainId, gasLimit, senderV, senderR, senderS, gasPrice]
3. `[2, nonce, to, value, data, chainId, senderV, senderR, senderS, gasLimit, gasPrice]`
`gasPayerV, gasPayerR, gasPayerS` is the result of `secp256k1(gasPayerPrivateKey, keccak256(rlp([1, rlp(gasPayerPayload)])))` The address recovered from this signature is the address...
1. ...whose ETH balance is deducted to pay for gas
For both signatures, the `v` value (`senderV` and `gasPayerV`) 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`. 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`.
@ -58,19 +74,19 @@ rlp([
1, 1,
// The maximum amount of gas that this transaction can use // The maximum amount of gas that this transaction can use
500000, 500000,
// The `y` parity bit (known as `v`) of the `SENDER`s signature of `rlp([0, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 500000, 1])` // secp256k1(senderPrivateKey, keccak256(rlp([1, rlp([1, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 1, 500000])]))).yParity
0, 0,
// The `r` value of the `SENDER`s signature of `rlp([0, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 500000, 1])` // secp256k1(senderPrivateKey, keccak256(rlp([1, rlp([1, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 1, 500000])]))).r
0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef,
// The `s` value of the `SENDER`s signature of `rlp([0, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 500000, 1])` // secp256k1(senderPrivateKey, keccak256(rlp([1, rlp([1, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 1, 500000])]))).s
0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe,
// The price per gas used by this transaction. // The price per gas used by this transaction.
1000000000, 1000000000,
// The `y` parity bit (known as `v`) of the `SENDER`'s signature of `rlp([0, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 500000, 1, 0, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 1000000000])` // secp256k1(gasPayerPrivateKey, keccak256(rlp([1, rlp([1, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 1, 500000, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 1000000000])]))).yParity
1, 1,
// The `r` value of the `SENDER`'s signature of `rlp([0, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 500000, 1, 0, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 1000000000])` // secp256k1(gasPayerPrivateKey, keccak256(rlp([1, rlp([1, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 1, 500000, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 1000000000])]))).r
0xbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdead, 0xbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdead,
// The `s` value of the `SENDER`'s signature of `rlp([0, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 500000, 1, 0, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 1000000000])` // secp256k1(gasPayerPrivateKey, keccak256(rlp([1, rlp([1, 3, 0xbaadf00dbaadf00dbaadf00dbaadf00dbaadf00d, 0, 0x, 1, 500000, 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef, 0xcafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe, 1000000000])]))).s
0xbabecafebabecafebabecafebabecafebabecafebabecafebabecafebabecafe 0xbabecafebabecafebabecafebabecafebabecafebabecafebabecafebabecafe
] ]
]) ])
@ -93,10 +109,7 @@ The inner transaction needs a nonce to protect themselves from replay attacks.
We could have the `GAS_PAYER` provide a second nonce, but this would increase the payload size and require `GAS_PAYER` to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price. It would also create the possibility of a deadlock if the `SENDER` nonces aren't ordered the same as the `GAS_PAYER` nonces, and if the `SENDER` nonce isn't the lowest valid nonce for the `SENDER` then the `GAS_PAYER` can't sign and submit yet. Finally, client complexity increases slightly if a transaction has two nonces because you have to protect yourself from deadlocks and do more work to determine validity. We could have the `GAS_PAYER` provide a second nonce, but this would increase the payload size and require `GAS_PAYER` to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price. It would also create the possibility of a deadlock if the `SENDER` nonces aren't ordered the same as the `GAS_PAYER` nonces, and if the `SENDER` nonce isn't the lowest valid nonce for the `SENDER` then the `GAS_PAYER` can't sign and submit yet. Finally, client complexity increases slightly if a transaction has two nonces because you have to protect yourself from deadlocks and do more work to determine validity.
## Backwards Compatibility ## Backwards Compatibility
The `ORIGIN` opcode currently has a note in the Yellow Paper that reads: No known issues.
> This is the sender of original transaction; it is never an account withnon-empty associated code.
The "sender of the original transaction" is a bit more ambiguous as of this EIP. While we call the account whose `nonce` is used and whose ETH balance `value` is withdrawn from the `SENDER`, that is merely a colloquiale term and no longer normative as of this EIP since a transaction of this type has two signers. It is possible that there are deployed contracts who expect `ORIGIN` to be the same as the `CALLER` of the first call frame, and that would no longer be true for these transactions.
## Test Cases ## Test Cases
<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.--> <!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->