Transaction Destination Opcode
EIP-3520 introduces a new EVM instruction called ENTRYPOINT, which provides access to the original recipient of a transaction. This enables contracts to identify the entry-point of a transaction on the blockchain and deduce the original intention of the transaction by applying introspection on the original transaction data itself. This can open new pathways for EIP-721 NFTs and 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. 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 to prevent software misbehaviours from arising. Overall, EIP-3520 provides a way for smart contracts to acquire access to the original transaction data at any given step in the call chain execution, which could result in cross-contract calls ultimately consuming less gas if the data passed between them is reduced as a side-effect of this change. However, the gas reduction would be an implementation-based optimization that would be solely applicable for rudimentary memory arguments rather than storage-based data, the latter of which is most commonly utilized in these types of calls. As a result, the overall gas reduction observed by this change will be negligible for most implementations.
Video
Original
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.
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 NFTs and 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 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 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.
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.
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.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all