97 lines
4.7 KiB
Markdown
97 lines
4.7 KiB
Markdown
|
---
|
||
|
|
eip: 190
|
||
|
|
title: Ethereum Smart Contract Packaging Standard
|
||
|
|
author: Piper Merriam (@pipermerriam), Tim Coulter (@tcoulter), Denis Erfurt (@mhhf), RJ Catalano (@VoR0220), Iuri Matias (@iurimatias)
|
||
|
|
status: Final
|
||
|
|
type: Standards Track
|
||
|
|
category: ERC
|
||
|
|
created: 2017-01-10
|
||
|
|
---
|
||
|
|
|
||
|
|
# Abstract
|
||
|
|
|
||
|
|
This ERC proposes a specification for Ethereum smart contract packages.
|
||
|
|
|
||
|
|
The specification was collaboratively developed by the following Ethereum development framework maintainers.
|
||
|
|
|
||
|
|
* Tim Coulter (Truffle)
|
||
|
|
* Denis Erfurt (Dapple)
|
||
|
|
* Piper Merriam (Populus)
|
||
|
|
* RJ Catalano (Eris PM)
|
||
|
|
* Iuri Matias (Embark)
|
||
|
|
|
||
|
|
# Motivation
|
||
|
|
|
||
|
|
Packaging is a core piece of modern software development which is missing from the Ethereum ecosystem. The lack of packaging limits the ability for developers to reuse code which negatively affects productivity and security.
|
||
|
|
|
||
|
|
A key example of this is the ERC20 standard. There are a few well audited reusable token contracts available but most developers end up writing their own because of the difficulty in finding and reusing existing code.
|
||
|
|
|
||
|
|
A packaging standard should have the following positive effects on the ecosystem:
|
||
|
|
|
||
|
|
* Greater overall productivity caused by the ability to reuse existing code.
|
||
|
|
* Increased security caused by the ability to reuse existing well audited implementations of common patterns (ERC20, crowdfunding, etc).
|
||
|
|
|
||
|
|
Smart contract packaging should also have a direct positive effect on the end user. Wallet software will be able to consume a released package and generate an interface for interacting with any deployed contracts included within that package. With the advent of [ENS](./eip-137.md) all of the pieces will be in place for a wallet to take a human readable name and present the user with an interface for interacting with the underlying application.
|
||
|
|
|
||
|
|
|
||
|
|
# Specification
|
||
|
|
|
||
|
|
The full specification for this standard is maintained separately in the repository [epm/epm-spec](https://github.com/ethpm/epm-spec).
|
||
|
|
|
||
|
|
This EIP refers to the `1.0.0` version of the specification: [https://github.com/ethpm/epm-spec/tree/v1.0.0](https://github.com/ethpm/epm-spec/tree/v1.0.0)
|
||
|
|
|
||
|
|
The specification contains details for a single document referred to as a *"Release Lockfile"*.
|
||
|
|
|
||
|
|
* Release Lockfile Specification: [https://github.com/ethpm/epm-spec/blob/v1.0.0/release-lockfile.spec.md](https://github.com/ethpm/epm-spec/blob/v1.0.0/release-lockfile.spec.md).
|
||
|
|
* JSON Schema for Release Lockfile: [https://github.com/ethpm/epm-spec/blob/v1.0.0/spec/release-lockfile.spec.json](https://github.com/ethpm/epm-spec/blob/v1.0.0/spec/release-lockfile.spec.json)
|
||
|
|
|
||
|
|
> These documents have not been inlined into this ERC to ensure that there is a single source of truth for the specification.
|
||
|
|
|
||
|
|
|
||
|
|
# Use Cases
|
||
|
|
|
||
|
|
This specification covers the following types of smart contract packages.
|
||
|
|
|
||
|
|
1. Packages with contracts intended to be used as base contract such as the common `owned` pattern.
|
||
|
|
2. Packages with contracts that are ready to use as-is such as an ERC20 token contract.
|
||
|
|
3. Packages with deployed contracts such as libraries or services.
|
||
|
|
|
||
|
|
Full explanations and examples of these use cases can be found in the [`README.md`](https://github.com/ethpm/epm-spec/blob/v1.0.0/README.md#use-cases) from the `epm/epm-spec` repository.
|
||
|
|
|
||
|
|
|
||
|
|
# Package Managers
|
||
|
|
|
||
|
|
The *Release Lockfile* is intended for consumption by package management software. Specific care was made to ensure that all of the following functionality can be implemented by package managers.
|
||
|
|
|
||
|
|
|
||
|
|
## Deterministic builds
|
||
|
|
|
||
|
|
Ensures that a package will always resolve to the same set of dependencies and source files. Both source files and dependencies are content addressed to ensure that the referenced resources cannot change.
|
||
|
|
|
||
|
|
|
||
|
|
## Bytecode verification
|
||
|
|
|
||
|
|
Contains the appropriate information for a package manager to inspect a deployed contract and verify that its bytecode matches the bytecode that results from compilation and linking of the package source code.
|
||
|
|
|
||
|
|
|
||
|
|
## Multi-chain deploys
|
||
|
|
|
||
|
|
Supports deployments across multiple chains, allowing a package to define addresses on both the public mainnet and testnet.
|
||
|
|
|
||
|
|
|
||
|
|
## Trusted packages
|
||
|
|
|
||
|
|
Allows for packages which exclude source code or other elements which would be needed for verification of the contract bytecode. This allows for minimalistic packages to be created for special situations where the package manager will not be performing verification.
|
||
|
|
|
||
|
|
|
||
|
|
# Framework support and integration
|
||
|
|
|
||
|
|
Support for ERC190 is either implemented or in progress for the following:
|
||
|
|
|
||
|
|
* [Truffle](https://truffleframework.com/)
|
||
|
|
* [Populus](https://populus.readthedocs.io/en/latest/)
|
||
|
|
* [Dapple](https://dapple.readthedocs.io/en/master/)
|
||
|
|
* [Eris PM](https://github.com/eris-ltd/eris-cli)
|
||
|
|
* [Embark](https://github.com/iurimatias/embark-framework)
|
||
|
|
* [Browser Solidity](https://github.com/ethereum/remix-ide/issues/386)
|