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) 3074 (#3317)

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 17:47:07 -05:00 committed by GitHub
parent 8cf86482c8
commit 85c0123469
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
EIPS/eip-3074.md
View File

@ -29,7 +29,7 @@ While it is possible to emulate sponsored transactions (ex. [Gas Station Network
An opcode, at `0xf9`, functions like a `CALL` instruction that additionally:
- sets the caller and origin addresses based on an ECDSA signature, and
- sets the caller addresses based on an ECDSA signature, and
- optionally transfers Ether from the recovered account.
### Definitions
@ -129,7 +129,13 @@ Where `len(data)` is the length of the region of memory defined by `argsOffset`
### Two Return Values
It is important to differentiate between a failure in `TXCALL`'s preconditions versus a failure in the callee. Correctly implementing replay protection requires the invoker to change its state even if the callee fails (to burn the nonce) but doing so if, for example, the signature failed would be nonsensical.
It is important to differentiate between a failure in `TXCALL`'s preconditions versus a failure in the callee. Correctly implementing replay protection requires the invoker to change its state even if the callee fails (to burn the nonce) but doing so if, for example, the signature failed would be nonsensical. Several options exist for encoding these two failure cases: returning two stack elements, reserving a specific revert reason, or choosing different values in a single stack element.
First, it's important to note that all three options are a deviation from the semantics of other `CALL` opcodes, but this deviation is unavoidable.
Reserving a specific revert reason, for example `txcall failed`, is a large departure from other instructions. An invoker would need to inspect the revert reason to determine whether the callee reverted, or the `TXCALL` pre-conditions were invalidated, which implies reading and comparing memory values. Further, to remain sound when a callee reverts with `txcall failed`, `TXCALL` would need to replace the return data with some other value.
Returning a single stack element with different values depending on the situation (ex. `0` on success, `1` when the pre-conditions are violated, and `2` when the callee reverts) introduces the opportunity for a subtle bug: it's trivially easy to misinterpret the return value (`CALL` returns non-zero on success), but it's much harder to ignore a whole new stack value.
### Sponsee in Arguments