Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
ERC: Ethereum Smart Contract Packaging Specification #190
This ERC proposes a specification for Ethereum smart contract packages.
The specification was collaboratively developed by the following Ethereum development framework maintainers.
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:
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.
The full specification for this standard is maintained separately in the repository epm/epm-spec.
This EIP refers to the
The specification contains details for a single document referred to as a "Release Lockfile".
This specification covers the following types of smart contract packages.
Full explanations and examples of these use cases can be found in the
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.
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.
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.
Supports deployments across multiple chains, allowing a package to define addresses on both the public mainnet and testnet.
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.
Implementations are currently underway for the following frameworks.
Implementation has not yet begun in the following frameworks but is on the roadmap.
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.
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.