mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-23 20:28:21 +00:00
Automatically merged updates to draft EIP(s) 2711 (#2736)
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:
parent
632c56d500
commit
0298105902
@ -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]`
|
||||
* `[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.
|
||||
`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.
|
||||
Where `senderPayload` is one of:
|
||||
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`.
|
||||
|
||||
@ -58,19 +74,19 @@ rlp([
|
||||
1,
|
||||
// The maximum amount of gas that this transaction can use
|
||||
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,
|
||||
// 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,
|
||||
// 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,
|
||||
// The price per gas used by this transaction.
|
||||
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,
|
||||
// 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,
|
||||
// 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
|
||||
]
|
||||
])
|
||||
@ -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.
|
||||
|
||||
## Backwards Compatibility
|
||||
The `ORIGIN` opcode currently has a note in the Yellow Paper that reads:
|
||||
> 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.
|
||||
No known issues.
|
||||
|
||||
## 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.-->
|
||||
|
Loading…
x
Reference in New Issue
Block a user