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 · 13 comments

Comments

Projects
None yet
8 participants
@pipermerriam
Member

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 from ERC: Ethereum Smart Contract Packaging Standard to ERC: Ethereum Smart Contract Packaging Specification Jan 10, 2017

@nogo10

This comment has been minimized.

Show comment
Hide comment
@nogo10

nogo10 Jan 12, 2017

What about ether.camp Studio IDE?

nogo10 commented Jan 12, 2017

What about ether.camp Studio IDE?

@pipermerriam

This comment has been minimized.

Show comment
Hide comment
@pipermerriam

pipermerriam Jan 12, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@hitchcott

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

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

This comment has been minimized.

Show comment
Hide comment
@VoR0220

VoR0220 Jan 12, 2017

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

VoR0220 commented Jan 12, 2017

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

@VoR0220

This comment has been minimized.

Show comment
Hide comment
@VoR0220

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

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

This comment has been minimized.

Show comment
Hide comment
@pipermerriam

pipermerriam Jan 12, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@pipermerriam

pipermerriam Jan 12, 2017

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@VoR0220

VoR0220 Jan 12, 2017

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

VoR0220 commented Jan 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jan 13, 2017

Member

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

Member

Souptacular commented Jan 13, 2017

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

@pipermerriam

This comment has been minimized.

Show comment
Hide comment
@pipermerriam

pipermerriam Jan 13, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@pipermerriam

pipermerriam Feb 2, 2017

Member

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

Member

pipermerriam commented Feb 2, 2017

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

@danfinlay

This comment has been minimized.

Show comment
Hide comment
@danfinlay

danfinlay Feb 15, 2017

Contributor

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

Contributor

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.

Show comment
Hide comment
@stvenyin

stvenyin Sep 30, 2018

I,know it for etherem.org
That's all
Thank you very much,

stvenyin commented Sep 30, 2018

I,know it for etherem.org
That's all
Thank you very much,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment