Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC: Ethereum Smart Contract Packaging Specification #190

Open
pipermerriam opened this issue Jan 10, 2017 · 15 comments
Open

ERC: Ethereum Smart Contract Packaging Specification #190

pipermerriam opened this issue Jan 10, 2017 · 15 comments

Comments

@pipermerriam
Copy link
Member

@pipermerriam pipermerriam commented Jan 10, 2017

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".

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.

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

@pipermerriam pipermerriam changed the title ERC: Ethereum Smart Contract Packaging Standard ERC: Ethereum Smart Contract Packaging Specification Jan 10, 2017
@nogo10
Copy link

@nogo10 nogo10 commented Jan 12, 2017

What about ether.camp Studio IDE?

@pipermerriam
Copy link
Member Author

@pipermerriam pipermerriam commented Jan 12, 2017

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.

@hitchcott
Copy link

@hitchcott hitchcott commented Jan 12, 2017

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
Copy link

@VoR0220 VoR0220 commented Jan 12, 2017

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

@VoR0220
Copy link

@VoR0220 VoR0220 commented Jan 12, 2017

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
Copy link
Member Author

@pipermerriam pipermerriam commented Jan 12, 2017

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
Copy link
Member Author

@pipermerriam pipermerriam commented Jan 12, 2017

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
Copy link

@VoR0220 VoR0220 commented Jan 12, 2017

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

@Souptacular Souptacular commented Jan 13, 2017

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

@pipermerriam
Copy link
Member Author

@pipermerriam pipermerriam commented Jan 13, 2017

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

@pipermerriam
Copy link
Member Author

@pipermerriam pipermerriam commented Feb 2, 2017

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

@danfinlay
Copy link
Contributor

@danfinlay danfinlay commented Feb 15, 2017

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

@stvenyin

This comment was marked as spam.

@axic
Copy link
Member

@axic axic commented May 23, 2019

@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
Copy link

@ghost ghost commented Mar 17, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.