ERC: Ethereum Smart Contract Packaging Specification

[pipermerriam]

EIP: Draft
Title: Ethereum Smart Contract Packaging Specification
Authors: Piper Merriam, Tim Coulter, Denis Erfurt (mhhf), RJ Catalano (VoR0220), Iuri Matias (iurimatias)
Status: Draft
Type: Standards Track
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 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.

This EIP refers to the 1.0.0 version of the specification: 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.
• JSON Schema for Release Lockfile: 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.

Rationale

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 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 it's 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.

Implementation

Implementations are currently underway for the following frameworks.

• Truffle
• Dapple
• Populus
• Eris PM

Implementation has not yet begun in the following frameworks but is on the roadmap.

• Embark

[nogo10]

What about ether.camp Studio IDE?

[pipermerriam]

They are welcome to implement this in their IDE as well. I believe that Tim Coulter has already started a generic JS library that should make integration in any JS based application a lot easier.

[IstoraMandiri]

Glad to see this coming into fruition, it will be a welcome improvement to our workflow.

I'm not sure if it's outside the scope of this EIP, but have you considered extending the spec to somehow include a link to UI assets within a package?

A simple link would allow the package to automatically show it's intended custom UI in a dapp browser - you could even have a config object with multiple build targets (for different dapp browsers like status.im, mist, spectrum, etc.) secured by their IPFS content hash.

Maybe this is something for a different project that utilises epm.

[VoR0220]

Outside of the spec for version 1. Welcome for discussion for version 2.

[VoR0220]

Though i personally would feel thats outside of the standard scope and would best be implemented by the package manager. We were very careful to narrow the scope down to making it so contracts could interact and make it registry agnostic.

[pipermerriam]

I'm not sure if it's outside the scope of this EIP, but have you considered extending the spec to somehow include a link to UI assets within a package?

@hitchcott

As @VoR0220 said, out of scope for this version but this specification is one which we plan to continue to develop so worth discussing for the next version. I'd encourage you to open an issue in the ethpm/epm-spec](https://github.com/ethpm/epm-spec) repository with this idea. It would be helpful if you put some thought into the various use cases for this as well.

[pipermerriam]

I'm a bit unfamiliar with the ERC/EIP process. Wondering if someone can answer the following questions.

1. What does ERC stand for.
2. Is there a formal or informal process for how one of these gets accepted/established.

[VoR0220]

1. Ethereum Request for Comments?
2. I believe you need to send up a PR per @Souptacular

[Souptacular]

@VoR0220 @pipermerriam We are updating the EIP/ERC process and will have news on Monday :)

[pipermerriam]

@Souptacular thanks for the info. I'll keep an eye out. Appreciate you guys taking the time to improve this.

[pipermerriam]

PR opened (correct me if that was the wrong thing to do) #203

[danfinlay]

Dapple has also integrated support, you can deploy to ethpm with dapple pkg publish.

[axic]

@pipermerriam this EIP doesn't have a copyright statement. Can you please add one? EIP-1 suggests CC0 - see the eip-x.md template.

[ghost]

Package management with EthPM & NPM, using the ERC190 standard.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[brandonaaskov]

@pipermerriam just want to make sure you saw ☝️

[xinbenlv]

This seems already FINAL, see https://eips.ethereum.org/EIPS/eip-190
Consider closing?