Thank you for your interest in this post! We’re undergoing a rebranding process, so please excuse us if some names are out of date. Also have in mind that this post might not reference the latest version of our products. For up-to-date guides, please check our documentation site.
Announcing the EVM package implementation of the most popular smart contract library
These are great times for smart contract development. The pieces for Ethereum 2.0 are coming together, and new tools and practices are blooming. Last week, OpenZeppelin 2.0 came out with an improved, stable API and 100% test coverage plus a full independent audit. Maturity is around the corner.
This sets the right ground to release OpenZeppelin-eth, the EVM package implementation of OpenZeppelin.
An EVM package is basically an on-chain piece of code that you can reuse. Think of it as a code dependency that you can update to fix bugs without deploying anything. This means you don’t need to worry about maintaining or deploying your dependencies, since you can leverage other team’s work while having full control over your own upgrades at the same time.
So, whenever the EVM package maintainer (or a forked version) comes up with a bug fix, new feature or optimization, you will have the option of easily upgrading your code to the latest version without deploying a new contract, without manually migrating state, and preserving the same contract address.
As of today there are thousands of projects depending on OpenZeppelin in Github alone. Picture the scenario where a bug in the library is found and every single project needs to fix it on-chain, multiplying their efforts. Lots of time and money are spent in performing independent code reviews, new deployments, and state migrations — a chaos that many attackers could take advantage of.
Thanks to EVM packages, you can make use of OpenZeppelin-eth without worrying about any of the above. You just need to upgrade your linked package to the latest version (or preferred fork), and you’re done. Ready to focus on what really matters: buidling your own stuff.
You can easily deploy your own ERC20 token using OpenZeppelin-eth following these simple steps:
1- Set up your ZeppelinOS project if you don’t have one already.
$ zos init MyToken Successfully written zos.json
2- Link the OpenZeppelin-eth EVM package to it
$ zos link openzeppelin-eth Installing openzeppelin-eth via npm… Successfully written zos.json
3- Deploy your own version of OpenZeppelin-eth into your local Ethereum blockchain. This step is only needed if you’re in a development environment, otherwise you can skip it: the package already contains the addresses of the mainnet and testnet deployments in its configuration files.
$ zos push --deploy-dependencies --network local Compiling contracts Deploying openzeppelin-eth contracts (…) Using custom deployment of openzeppelin-eth Updated zos.dev.json
4- Deploy your own StandaloneToken instance linked to the package. You can check the full argument list of here.
// Make sure you replace $OWNER with your own address $ zos create openzeppelin-eth/StandaloneERC20 --args MyToken,MTK,18,100000000000,$OWNER,[],[],$SENDER --network local Creating proxy to logic contract 0x82b1bb96e9e01a3ed187df80730f64e1db80a140 and initializing by calling initialize with: - name (string): “MyToken” - symbol (string): “MTK” - decimals (uint8): “18” - initialSupply (uint256): “100000000000” - initialHolder (address): “ $OWNER ” - minters (address[]): [] - pausers (address[]): [] - sender (address): “ $SENDER ” Instance created at 0xf20a412847fcd2a210d4726b64f243cab39748f5 0xf20a412847fcd2a210d4726b64f243cab39748f5 Updated zos.dev.json
Thats it! You have deployed your own ERC20 token in the address 0xf20a412847fcd2a210d4726b64f243cab39748f5, just like that. Easy peasy 🙂
While the code is almost the same, the main difference is that OpenZeppelin-eth is upgradeable and ready to use. This means that you don’t need to download the code, customize and deploy it yourself since OpenZeppelin-eth, just like any other EVM package, is already deployed and installed on the Ethereum network. You just have to link it to your project, deploy it, and you’re good to go!
If you’re already using OpenZeppelin-solidity in your project, that’s ok too! Good old OpenZeppelin-solidity and OpenZeppelin-eth are maintained together by the same team, meaning they get the same updates at the same time.
Anyway, we do recommend using the EVM package implementation given the usability and upgradeability benefits. And remember: only you can decide if, when, and how to upgrade it.
This is a trend we see coming in many projects and that has been already adopted by Zeppelin, Gnosis, Aragon, Livepeer, and Level K. We want to encourage teams and developers to start making their own EVM packages and building the next-generation tools for smart contract development:
Learn how to make your own EVM package now!