This situation might be familiar to you. You have started developing your smart contracts locally using something like Truffle / Buidler / Ganache / Embark / Waffle or any of the amazing tools, and now you reached a point where you would like to deploy your contracts to a live network like Testnet or Mainnet.

Until now, you had 3 different options

  1. Run something like truffle migrate --network=rinkeby in your terminal, and let the tool do the rest.
  2. If you would like to sign the transactions using Metamask/Ledger/Trezor, you might copy/paste or import your code from Github into Remix and deploy directly there.
  3. In the case that you want to have a more structured deployment pipeline (btw highly recommended so can then also be audited), you might be already using something like CireclCI/Travis/Jenkins to run your delivery pipeline (building/testing/auditing/deploying/verifying). Of course, if you hold dear of your private keys, this will only take you as far as deploying to Testnet, as otherwise, you will be exposing your private keys in your CI provider, which might not be the best of ideas if those keys actually hold some sort of admin role in your multi-million dollar system.

What are the current limitations for each option and what else could it be done?

Deploying from your local terminal

A typical Truffle migration run in the terminal

In the case that you are already using any of the previously mentioned CLI tools, this will be the easiest option to deploy your code to a live network. Simply run a command, and voila! your code is live somewhere.

Of course, this has one main issue, YOU are the only one who is aware of all the relevant information for that given deployment. Things like; where that code has been deployed, which addresses are the new contracts being deployed to, how much gas did the entire deployment take, which are the artifacts the deployment has generated (ABI are especially useful to interact with your deployed contracts), etc. are question you only can answer.

Now, with every deployment you might be doing, you will need to either store manually all that information somewhere (looking at all of you guys who are storing that in an Excel sheet!), make it publicly available through something like Etherscan or simply build a custom system into which you can store everything. Also, good luck if you would like to deploy/sign your transactions using something like Metamask.

And not only that, if you work in a team, until you sync manually all that data somewhere, you will be the only one with the required knowledge to fully grasp where everything is, heavily reducing data availability across your entire team.

Deploying using Remix

Deploying a Smart Contract through Remix

Another option people often do is deploying their contracts through Remix, independently if the contracts were coded using the tool in the first place or not. The reason why people tend to do so are mainly 2:

  1. You can sign your transactions using Metamask/Ledger/Trezor
  2. You have already coded everything using Remix

As compelling as it sounds to be able to easily use Metamask / Ledger / Trezor to sign your transactions and keep track of the deployments, you still lack things like tracking the deployment in a shared environment for your entire team to be fully aligned; collect and store all the artifacts your deployment generated like the ABI, bytecode, etc, and especially, if your system is more complex than a single contract, A LOT of manual work is required which can lead to errors. The most obvious example is if you need to deploy a contract and provide that address in the constructor of another contract or during an init sequence. As the entire process is really manual, this is a recipe for disaster and mistakes might happen sooner or later (and I am not even talking about all the wasted time doing something like this will take you)

Use a CI provider like CircleCI/Jenkins/Travis/etc

Finally, if you work in a bigger project, you certainly are already using a CI provider like CircleCI/Jenkins/Gitlab or Travis to manage your entire build and delivery pipeline.

Most likely you have set up your pipeline to build your project, automatic audit testing with services like Mythx or tools like Mythril, running all your unitary tests written either in JS or Solidity, some integration tests and finally, deployments to some network.

But you might have noticed that I haven’t mentioned promoting a build to Mainnet, and this is mainly because, in many cases, you don’t want to expose your private keys in external CI providers as those keys might hold certain privileges in the deployed system.

Ok, now that we have described the 3 main methods people are deploying today, what other options are available which addresses some of the mentioned limitations?

Deploy using Superblocks

Back in February, we added support to manage your deployments through the Superblocks platform. If you do not already know what Superblocks is, we are creating a platform to build, test, manage and monitor your Smart Contracts projects. One of our first additions is a feature that allows you to track and sign your deployment scripts securely without ever having to expose your private keys.

Superblocks dashboard - Deployment list

Before I continue how to set it up, I must remark that tracking and singing your deployments using Metamask/Ledger/Trezor will also work with any existing CI you might already use like CircleCI, Travis or even the command line! In fact, to make it even simpler for you, we automatically harvest additional metadata like the job and commit information when deploying through Superblocks/CircleCI/TravisCI/Jenkins or Gitlab. Now you can backtrace any given deployment to the job and commit which triggered it in the first place! 🎉🎉

Getting Started

We are going to use Truffle as an example and sign the transactions using Metamask.

** Note: You could also use our custom SuperHDWallet provider which allows you to sign your Txs client-side but still keep track of your entire deployment routine (commit/job/transactions/etc)

To start signing and tracking your deployments through Superblocks follow these 3 simple steps:

  1. Add our custom web3 provider library to your project.npm install --save-dev super-web3-provider

2. Import it into your truffle.config.js

3. Navigate to your project settings and generate a new project token.

Superblocks dashboard - Generate Project Token

4. Finally copy/paste your project id into your provider

Superblocks Dashboard - Where to find the Project Id

Signing transactions remotely using Metamask

Now that you have configured your provider, navigate to your project deployments section and click on the newly created deployment. This will take you to the deployment details page, where transactions that require signing will start appearing in the dashboard. Click the sign button, review in Metamask and finally confirm it.

Now your newly signed and broadcasted transaction will appear under the History section.

**Note: Make sure the Network and the From addresses configured in your provider is actually matching the ones selected in Metamask. We added a safety feature making sure you don’t deploy to either the wrong network or from the wrong account accidentally.

Alternative: Signing transactions locally using SuperHDWallet

As we mentioned, earlier, when it comes to signing, there are currently 2 options supported. If you prefer to either run the deployment locally in your terminal or in a CI, you still have the possibility to keep track of your deployment using the platform.

Superblocks Dashboard - Deployment Details

Bonus Point: Collet deployment Artifacts

So finally, we added a way for you to be able to collect your artifacts associated with each deployment. This will allow you to do the following:

  • Collect the ABI, Metadata, Bytecode, SourceMap for every contract deployed.
  • Retrieve your ABI directly from our API so it can be consumed by client applications.
  • Easily import deployment contracts for interaction and monitoring (more news coming soon!)

For now, we are only supporting Truffle, but support for other tools is coming. To start collecting your deployment artifacts, simply exec after your deployment is done:npx superblocks-cli collect-artifacts

They will automatically appear in the Artifacts for the deployment

Superblocks Dashboard — Artifact Collection

Example Reference Projects

We are creating a base of reference projects to help you out on getting up to speed as fast as possible and be able to showcase to you all the cool stuff we are gonna be adding to the platform.

Truffle — https://github.com/SuperblocksHQ/truffle-reference-project

OpenZeppelin — https://github.com/SuperblocksHQ/open-zeppelin-reference-project

P. S. For discussions and questions you can go to our Discuss Forum

༼ つ ◕_◕ ༽つ Go go go, check it out!