90 lines
5.5 KiB
Markdown
90 lines
5.5 KiB
Markdown
---
|
|
eip: 3520
|
|
title: Transaction Destination Opcode
|
|
author: Alex Papageorgiou (@alex-ppg)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-3520-transaction-destination-opcode/6058
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2021-04-16
|
|
requires: 3508
|
|
---
|
|
|
|
## Simple Summary
|
|
|
|
Provide access to the original recipient of a transaction.
|
|
|
|
## Abstract
|
|
|
|
This EIP introduces the following EVM instruction: `ENTRYPOINT`.
|
|
|
|
This instruction is meant to provide access to the original recipient of the transaction, the `to` address, enabling new ways of introspection to be applied in conjunction with [EIP-3508](./eip-3508.md).
|
|
|
|
## Motivation
|
|
|
|
It is undeniable that smart contracts are becoming more interconnected than ever. Up until this point, smart contracts have entirely relied on compliant interfaces and introspection to introduce a new step in the call chain of a complex multi-contract interaction. However, this presents a forwards-only approach which limits the types of interactions that can manifest.
|
|
|
|
The purpose of this EIP is to provide a way via which a contract is able to identify the entry-point of a transaction on the blockchain and deduce what was the original intention of the transaction by applying introspection on the original transaction data itself.
|
|
|
|
This EIP enables the development of new types of smart contracts as it can open new pathways for [EIP-721](./eip-721) NFTs and [EIP-20](./eip-20) tokens to detect which action their transaction is part of, such as detecting a liquidity provision to a decentralized exchange or a loan within a collateralized lending protocol.
|
|
|
|
## Specification
|
|
|
|
### ENTRYPOINT (`0x4a`)
|
|
|
|
The `ENTRYPOINT` instruction uses 0 stack arguments and pushes the original `to` member of the transaction onto the stack. The address yielded by the instruction is a 160-bit value padded to 256-bits. The operation costs `G_base` to execute, similarly to `ORIGIN` (`0x32`).
|
|
|
|
The address returned by the `ENTRYPOINT` opcode will be equivalent to the `to` address parameter specified in the nearest `AUTHCALL` up the stack. If there is no `AUTHCALL` in the stack then `ENTRYPOINT` will retrieve the original transaction's `to` field.
|
|
|
|
## Rationale
|
|
|
|
### AUTHCALL (`0xf7`) Interaction
|
|
|
|
The [EIP-3074](./eip-3074.md) introduced a new call instruction called `AUTHCALL` (`0xf7`) that will replace a transaction's `ORIGIN` (`0x32`) with the context variable `authorized`. The intention of `AUTHCALL` is to prevent discrimination between smart contracts and EOAs which `ORIGIN` initially facilitated. The `ENTRYPOINT` opcode by itself re-introduces discrimination into the system as it indirectly allows one to evaluate whether the smart contract code being executed is done so by an EOA by validating that `ENTRYPOINT == ADDRESS` where `ADDRESS` (`0x30`) retrieves the currently executing account address. Therefore, it is sensible also replace the values retrieved by the `ENTRYPOINT` opcode to the target of an `AUTHCALL`.
|
|
|
|
This interaction ensures full compatibility with [EIP-3074](./eip-3074.md) and ensures that no form of discrimination is introduced back into the system by this EIP.
|
|
|
|
### Naming Conventions
|
|
|
|
The `ENTRYPOINT` instruction came to be by defining a sensible name that immediately and clearly depicts what it is meant to achieve by signaling the first interaction of a particular call, i.e. the entry-point.
|
|
|
|
### Instruction Address Space
|
|
|
|
Equivalent to [EIP-3508](./eip-3508).
|
|
|
|
### Gas Cost
|
|
|
|
The opcode ENTRYPOINT (`0x4a`) essentially performs the same thing as the opcode ORIGIN (`0x32`) and thus shares the exact same gas cost.
|
|
|
|
### Dependency on EIP-3508
|
|
|
|
The `ENTRYPOINT` (`0x4a`) instruction alone has no perceivable benefit as it can be replaced by the `AUTHCALL` (`0xf7`) instruction and as such should solely be introduced to the system in conjunction with the `ORIGINDATA*` opcodes defined in [EIP-3508](./eip-3508.md).
|
|
|
|
## Backwards Compatibility
|
|
|
|
The EIP does not alter or adjust existing functionality provided by the EVM and as such, no known issues exist.
|
|
|
|
## Test Cases
|
|
|
|
TODO.
|
|
|
|
## Security Considerations
|
|
|
|
### Introspective Contracts
|
|
|
|
The `ENTRYPOINT` instruction allows the association of the `ORIGINDATALOAD` and `ORIGINDATACOPY` values with a particular smart contract address and interface, enabling introspection to be applied based on the function signature invoked and the arguments provided to reliably deduce the call-path via which a particular smart contract was invoked and allowing a more granular level of interaction to be defined in such special cases.
|
|
|
|
However, this type of introspection should solely be applied on pre-approved contracts rather than user-defined ones as the value stemming from this type of introspection entirely relies on a contract's code immutability and proper function, both of which a user supplied contract can easily bypass.
|
|
|
|
### Caller Discrimination
|
|
|
|
The instructions of this EIP should not be utilized as a way to discriminate between EOA callers and smart contracts, as this type of differentiation can be broken by an `AUTHCALL` as defined in the specification chapter.
|
|
|
|
### Contract Creation Behaviour
|
|
|
|
The behaviour of the `ENTRYPOINT` opcode during a contract creation will result in the opcode yielding the zero-address as the first address interacted with in the transaction. This should be taken into account by contract implementations in a similar fashion to how `ecrecover` invalid signatures are handled to prevent software misbehaviours from arising.
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|