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 (#3314)

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:
Micah Zoltu 2021-03-04 01:23:47 +08:00 committed by GitHub
parent 91e5e34c6e
commit 729c1ab196
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
EIPS/eip-3074.md
View File

@ -11,11 +11,11 @@ created: 2020-10-15
## Simple Summary
Creates a new EVM instruction, analogous to `CALL` (`0xF1`), that sets `CALLER` (`0x33`) and `ORIGIN` (`0x32`) based on an ECDSA signature.
Creates a new EVM instruction, analogous to `CALL` (`0xF1`), that sets `CALLER` (`0x33`) based on an ECDSA signature.
## Abstract
This EIP creates an EVM instruction (`TXCALL`) which forwards a `CALL`, setting `CALLER` and `ORIGIN` according to an ECDSA signature.
This EIP creates an EVM instruction (`TXCALL`) which forwards a `CALL`, setting `CALLER` according to an ECDSA signature.
## Motivation
@ -157,38 +157,6 @@ More logic can be implemented around the call into `TXCALL`, giving more control
Earlier approaches to this problem included mechanisms for replay protection. This proposal explicitly does not handle replay protection, but instead includes a signed-but-unused field (`nextra`) which is expected to be used by invoker contracts to implement replay protection. Delegating replay protection to the invoker sidesteps the issue of giving a precompile contract its own storage, while opening the door to more innovative replay protection methods in the future.
### Changing `SENDER` & `ORIGIN`
Existing contracts were built under assumptions that this proposal changes or outright breaks.
> `extcodesize(msg.sender) == 0` asserts that the caller is not a contract.
This is not strictly true without this proposal (ex. contracts under construction have no code.) Contracts relying on this assumption are therefore insecure regardless.
> `tx.origin` is the gas payer.
It is unlikely that contracts making this assumption (i.e. ones which already implement sponsored transactions) would continue to be used after this proposal is implemented.
> `tx.origin == msg.sender` asserts that the current execution frame is the topmost frame.
Several properties are unique to the topmost execution frame:
1. The return value is inaccessible.
2. Reverting or returning in the topmost frame ends execution.
3. The caller is an EOA and not a contract.
Properties (1) and (2) no longer hold when `tx.origin == msg.sender`, while property (3) is maintained: only an EOA can sign a transaction-like package.
It is unlikely, but not impossible, for a contract to only return a value when called by an EOA. It is difficult to imagine uses cases for such behavior, so invalidating property (1) seems to have low impact.
Property (2) would likely have the greatest impact, for two reasons: it creates the opportunity for atomicity where there was none before, and it makes pre- and post-conditions undetectable to the callee. Since the topmost frame is always executed, a contract in that frame can be certain—barring revert and out-of-gas conditions—that it will execute, regardless of the state changes it makes. With `TXCALL`, an invoker could revert the callee if certain post-conditions were not met, allowing a retry at a later time. That said, a miner can break either of these assumptions by, respectively, executing two separate but adjacent transactions, or simply excluding a transaction that doesn't meet the pre- or post-conditions.
> Only one `tx.origin` can exist in a single transaction.
Reentrancy guards that rely on `tx.origin` cease to function under this proposal.
If setting `ORIGIN` is unacceptable, an alternative is to not set `ORIGIN` and for `TXCALL` to fail if `sponsor == sponsee`.
## Backwards Compatibility
No known issues.
@ -203,13 +171,6 @@ TODO
## Security Considerations
### Changing `SENDER` & `ORIGIN`
- `tx.origin` is not always the gas payer.
- Checking `msg.sender == tx.origin` does not prevent reentrancy.
- Contracts cannot prevent or detect pre- or post- conditions by checking `msg.sender == tx.origin`.
- Return values which were only accessible to EOAs are accessible to invoker contracts.
### Signature Verification & Reply Protection
- Potential impersonation attacks if there is a bug in the signature verification.