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

Automatically merged updates to draft EIP(s) 3074 (#3315)

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

 - It only modifies existing Draft, Review, 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:
Sam Wilson 2021-03-03 13:20:09 -05:00 committed by GitHub
parent 729c1ab196
commit e2069379f8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
EIPS/eip-3074.md
View File

@ -58,19 +58,18 @@ An opcode, at `0xf9`, functions like a `CALL` instruction that additionally:
| `gas` | `value` | `argsOffset` | `argsLength` | `retOffset` | `retLength` |
The arguments memory region shall be encoded as `type || abi.encode(sponsee, nextra, mingas, to, valueTotal, valueSponseeMax, data, v, r, s)`, where:
The arguments memory region shall be encoded as `type || abi.encode(v, r, s, sponsee, nextra, mingas, to, value, data)`, where:
- `type: uint8` - [EIP-2718](./eip-2718.md) transaction type (currently always `SPONSORED_TYPE`);
- `sponsee: address` - address of the sponsee;
- `nextra: uint256` - extra data, which can be used in the invoker to implement replay protection;
- `to: address` - address of the callee;
- `mingas: uint256` - minimum gas limit which must be provided with the call into `TXCALL`;
- `valueTotal: uint256` - exact amount of Ether in wei to be received by the callee;
- `valueSponseeMax: uint256` - maximum amount of Ether in wei that can be deducted from the sponsee's balance;
- `value: uint256` - exact amount of Ether in wei to be received by the callee;
- `data: bytes` - the calldata for the call into `to`; and
- `v: uint8`, `r: bytes32`, `s: bytes32` - signature for the package, including chain id as specified in [EIP-155](./eip-155.md).
The signature (`v`, `r`, `s`) arguments are computed from `secp256k1(keccak256(type || abi.encode(nextra, mingas, to, valueTotal, valueSponseeMax, data, invoker, chainid)))`.
The signature (`v`, `r`, `s`) arguments are computed from `secp256k1(keccak256(type || abi.encode(nextra, mingas, to, value, data, invoker, chainid)))`.
#### Outputs
@ -89,10 +88,8 @@ The signature (`v`, `r`, `s`) arguments are computed from `secp256k1(keccak256(t
- The address recovered from `v`, `r`, and `s` does not match `sponsee`
- Gas limit supplied with the call into `TXCALL` is less than the signed `mingas`
- The transaction's remaining gas is less than the signed `mingas`
- The value sent with the call is less than `valueTotal - min(valueSponseeMax, valueTotal)`
- The value sent with the call is greater than `valueTotal`
- The sponsee's balance is less than `valueTotal` minus the value sent with the call
- The current execution context is static (i.e. `STATICCALL`) and `valueTotal` is non-zero
- The value sent with the call is not equal to the signed `value`
- The current execution context is static (i.e. `STATICCALL`) and `value` is non-zero
`success` shall be a one in all other cases.
@ -105,6 +102,12 @@ The signature (`v`, `r`, `s`) arguments are computed from `secp256k1(keccak256(t
`calleeSuccess` shall be a one in all other cases.
##### Return Data
The memory region defined by `retOffset` and `retLength` shall be filled in the same way as the `CALL` instruction with similar arguments.
The return data area accessed with `RETURNDATASIZE` (`0x3d`) and `RETURNDATACOPY` (`0x3e`) shall be set in the same way as the `CALL` instruction.
### Gas Fees
The gas fees for `TXCALL` are calculated according to the following pseudo-code:
@ -114,9 +117,6 @@ S_cd = len(data) # In 256-bit words, rounded up
fees = 3200 + (6 * S_cd)
if valueTotal > msg.value and valueSponseeMax != 0:
fees += 400
if preconditions_good(...):
return fees + cost_of_call(...)
else:
@ -135,10 +135,6 @@ It is important to differentiate between a failure in `TXCALL`'s preconditions v
Including `sponsee` in the arguments to `TXCALL` is a gas optimization. Without it, invokers would have to do their own `ecrecover` before calling into `TXCALL` to verify/adjust any state for replay protection.
### Sponsoring an Account with Ether
Allowing `TXCALL` to transfer Ether on the sponsee's behalf provides a uniform interface for all transactions a sponsee might want to perform. Sponsees with sufficient Ether might use a sponsor when swapping Ether for an ERC-20 on a subsidized exchange, or when relying on that sponsor to resubmit transactions to optimize gas pricing.
### Reserving an [EIP-2718](./eip-2718.md) Transaction Type
While clients should never directly interpret transaction-like packages as true transactions, reserving an [EIP-2718](./eip-2718.md) transaction type for transaction-like packages reduces the likelihood of a transaction-like package being misinterpreted as a true transaction.
@ -171,6 +167,10 @@ TODO
## Security Considerations
### Reentrancy
- Checking `msg.sender == tx.origin` no longer prevents reentrancy.
### Signature Verification & Reply Protection
- Potential impersonation attacks if there is a bug in the signature verification.