ERC-190 Smart contract packaging standard (Ethereum Smart Contract Packaging Standard)
Final · Other · created 2017-01-10
Defines a common format for bundling smart contract code into packages for distribution and reuse. It lets package managers pin dependencies and verify the bytecode of deployed contracts.
Why it is needed
Packaging is a core element of modern software development, yet the Ethereum ecosystem has long lacked it. Without a standard for bundling, publishing and consuming code, it is hard for developers to find and reuse code that already exists. The original text cites ERC20 tokens as the representative case. Even though a few well-audited, reusable token contracts exist, most developers write their own token contracts from scratch because existing code is hard to find and use. This duplicated work lowers productivity and hurts security, since unverified code multiplies. If verified implementations of common patterns can be easily obtained as packages, productivity and security across the whole ecosystem rise together, and wallet software can also read published packages and build interfaces that let users interact with the deployed contracts inside them.
In depth
The specification text is maintained in a separate repository
This ERC does not include the full specification in its body. The specification is maintained separately in the epm/epm-spec repository, and the ERC points to version 1.0.0. It states that the document was not copied into the ERC in order to keep a single source of truth for the specification. The core of the specification is a single document called the Release Lockfile. The repository provides the Release Lockfile specification document together with a JSON schema that can validate it mechanically. A package manager reads this lockfile to install and verify the package.
It covers three types of packages
This standard covers three kinds of packages. The first contains base contracts that other contracts inherit, such as the common owned pattern. The second contains contracts that can be deployed and used as they are, such as an ERC20 token contract. The third contains already deployed contracts, such as libraries or services. Detailed descriptions and examples of each type are in the README of the epm/epm-spec repository.
It guarantees deterministic builds
The Release Lockfile is designed so that a package always resolves to the same set of dependencies and source files. Both source files and dependencies are referenced by content addressing, so if the content of a referenced resource changes, its address changes, which prevents the target of a reference from being silently swapped. A given package unpacks to the same code in any environment where it is installed. This is listed first among the features a package manager must be able to implement.
It can verify the bytecode of deployed contracts
The Release Lockfile contains the information a package manager needs to inspect a deployed contract and confirm that its bytecode matches the result of compiling and linking the package source code. This lets tooling check that the code on chain actually came from the published source. Because you can confirm that a contract you want to reuse matches the source it claims, this contributes directly to security.
It supports multi-chain deployments and trusted packages
A single package can define deployments across several chains, so it can hold addresses on both the public mainnet and testnets. It also allows packages that omit some elements, such as the source code needed for verification. These are called trusted packages, and they make it possible to create packages with a minimal configuration for special situations in which the package manager does not perform verification.
It is built and supported jointly by the major frameworks
This specification was developed jointly by maintainers of Ethereum development frameworks, including Truffle (Tim Coulter), Dapple (Denis Erfurt), Populus (Piper Merriam), Eris PM (RJ Catalano) and Embark (Iuri Matias). It states that, as of the time the original was written, ERC190 support had been implemented or was in progress in these frameworks and in Browser Solidity. The status of this proposal is Final, meaning it is a settled standard.