ERC725
Introduction
EOAs (Externally Owned Accounts) are controlled by private keys and can perform specific operations such as CALL to interact with other addresses and CREATE to create other smart contracts. However, they do not have any internal logic or storage capabilities.
Smart contracts, on the other hand, can be controlled by EOAs or other smart contracts, which provide a flexible ownership management mechanism. They can store data and perform more complex operations, making them useful for a wide range of use cases, including digital assets, decentralized applications, DAO and smart contract based accounts.
ERC725X
There is a growing need for more functionalities beyond the basic CALL and CREATE that externally owned accounts (EOA) can do. These two opcodes enables interaction with other addresses on the blockchain to perform tasks such as calling functions, transferring native tokens, and creating new contracts. As the number of use cases for smart contracts increases, so does the need for additional functionality.
One such operation is the ability to manipulate storage of a contract and execute other contracts logic in the caller context (delegatecall), which is not possible with EOA but can be helpful to extend the logic of a contract. Additionally, the ability to create contracts at predetermined addresses (CREATE2), as well as, performing calls without causing any state changes (staticcall) are also important features that are currently not available to EOAs.
The need for these additional operations highlights the importance of having more functionality built into smart contracts. This standard aims to provide this functionality and enable the creation of more advanced and versatile smart contracts.
Specification
ERC725X is a standard that provides four types of operations that can be performed in a smart contract. These operations are defined as follows:
The DELEGATECALL operation is very dangerous as it can alter the state of the contract and also change owner variables at will. Additionally it can destroy the contract by calling selfdestruct on other contracts.
| Operation number | Operation type | Description |
|---|---|---|
| 0 | CALL | Transfer native tokens or calls smart contract functions. |
| 1 | CREATE | Create a new smart contract based on the contract address and nonce. |
| 2 | CREATE2 | Create a new smart contract based on the contract address, bytecode and the salt. The address can be predetermined. |
| 3 | STATICCALL | Call another smart contract while disallowing any modification to the state during the call. |
| 4 | DELEGATECALL | Run the function from another contract, but use the context of the current contract. |
ERC725Y Generic Data Key/Value Store
Using smart contracts to store data on the blockchain can be beneficial when that data will be used or referenced by other smart contracts.
One limitation of this approach is that once a smart contract is deployed with a specific set of variables containing data, it cannot be modified to include new variables. This can be a problem if additional data needs to be stored in the future, as it would require deploying a new version of the contract.
For example, if a token contract is deployed with variables for the token name, symbol, and decimals, it is not possible to add new variables for the creators or future collaborators.
What is needed is a dynamic way to attach data to a contract even after it has been deployed.
Specification
ERC725Y solves this problem by standardizing a mapping of data keys to data values to store data dynamically and to have the ability to add or remove data across time without the need to redeploy the contract.
Instead of representing the variable with a specific name such as age, or name, etc .. They are referenced as bytes32 data key. Same as solidity treat variables under the hood.
See the section "Layout of State Variables in Storage" in the Solidity documentation for more information about the structure of smart contract storage.
Normal contract vs ERC725Y
Thanks to ERC725Y, contracts become more interoperable, as their storage is represented in the same way. Contracts and interfaces can then read and write data from or to the storage in the same manner via the functions getData(...) and setData(...).
ERC725Y Data Representation
Since the data is set in the contract's storage as bytes32/bytes data key/value pair, a representation of this data should be standardized to avoid having each user writing the data in a different way and to have the ability to getData from other people's contract storage in a unified way.
LSP2 - ERC725YJSONSchema is the standard used by the LSPs to organize how the data should be represented as bytes32/bytes pairs.
Ownership
An EOA (Externally Owned Account) is controlled by a private key, which means that only the holder of this private key can execute transactions and perform CALL or CREATE operations from this EOA. This can be limiting in certain use cases, such as when it is necessary to share the ability to interact with the address from multiple individuals or entities. Sharing the private key, however, would compromise the security of the EOA as anyone with access to the private key would be able to execute transactions from the EOA.
One solution to this problem is to use a smart contract, which can be programmed to have specific addresses that can execute transactions.
§§§§eswaq ERC725 utilizes the ERC173 standard for ownership management. Under this standard, an address is designated as the owner of the contract, and is the only one able to interact with other addresses and create contracts using the execute(..) functions. The owner is also the only one able to set data in the contract using the setData(..) function.
This method provides significant control over who can access and operate the contract, and eliminates the need to share private keys. The owner of the contract is defined as an address, which can be an EOA (Externally Owned Account) or another contract with specific features, such as a DAO voting contract or a KeyManager.