OTP-005: Argument-addressable contracts
This proposal defines a way to address contracts by their arguments instead of by their initial data.
Motivation
Initial data can differ significantly from the arguments. This proposal allows us to avoid executing untrusted code from another contract in the context of the current one or executing TVM code off-chain for deployment, which could be risky in some cases.
Specification
This specification defines a way to write arguments into an initial data cell to be read by the contract code during deployment.
Prefix
The prefix is defined by the smart contract itself, but by default it is assumed to be a single zero bit
. This prefix is used by the contract code to distinguish between deployed and not-deployed states.
Arguments encoding
Arguments are encoded using Auto Encoder.
Contract Requirements
- A contract MUST expose a
lazy_deployment_completed
get method that returnstrue
if the contract is deployed andfalse
otherwise. - A contract MUST expose the
org.ton.deploy.lazy.v0
interface.
Drawbacks
- Contracts could be in a semi-deployed state.
- There are multiple ways to write arguments, resulting in different initial data and different addresses.
- You can deploy a pre-initialized contract that would have a different address despite being fully functional.
- Gas usage upon deployment is unpredictable. Deployments are usually expensive, but this proposal makes them even more expensive.