I’m pleased to announce the latest release of solt - the Solidity tool.
Formerly solc-sjw
, the project quickly outgrew the basic usage of writing Solidity standard json output for your smart contracts
and has been renamed as a result
with a more streamlined set of commands and options to suit all your Solidity contract verification from the command line,
no matter the project’s structure or framework you’re using to develop with.
Installing the latest version (v0.4.0 at time of writing)
These installation steps are available in the README of the repository which will have the latest versions and kept up to date, but are replicated here for those wanting to play along at home. (Although I highly encourage you to follow the repository for notifications on future releases)
Linux
wget https://github.com/hjubb/solt/releases/latest/download/solt-linux-x64 -O ~/.local/bin/solt
chmod +x ~/.local/bin/solt
Mac
wget https://github.com/hjubb/solt/releases/latest/download/solt-mac -O ~/.local/bin/solt
chmod +x ~/.local/bin/solt
solt write
Using solc-sjw
, developers were able to write a JSON file containing the source codes of every smart contract in a base folder,
which could be used with Etherscan’s verification portal. This approach was good
to test drive passable solutions, but fell short of the potential for a tool like this. I set out with a simple goal, to remove the
problem of supplying verified source code for your deployed smart contracts. Using the latest version of solt
you are now able to achieve the same result as the previous solc-sjw
tool with some major improvements.
Input can now be either a folder (as before), OR a specific file (as heavily requested)
The previous JSON output writer functionality can be replicated, on either a folder or file by running:
solt write src/somefolder
# or
solt write src/somefolder/contract.sol
in the base of your smart contract’s repo (where you’d usually have a truffle config or a ./src
or ./contracts
folder).
This outputs the normal solc-input[-name].json
so you can write out multiple JSON files if you are verifying a lot of
contracts at once. The usual --npm
, --no-optimization
and --runs
flags are available, so you’ll need to match
whatever the optimization specific flags with whatever your config might be, or your build tool’s defaults.
If you’re deploying separately released contracts through a repo with shared dependencies that might look like this:
$ solt write src/SystemA/OurToken.sol
# collecting etc...
file written to: solc-input-ourtoken.json
$ solt write src/SystemB/Controller.sol
# collecting etc...
file written to: solc-input-controller.json
Better error handling (ongoing)
You’ll now conveniently be presented with an error if solt
found non-relative/absolute dependencies, usually resulting
from having NPM imported libraries if you’re using something like Truffle. The new file functionality removes the
headaches developers were having where they would have to manually remove tests, migrations and other unrelated contracts from the output,
and entirely eliminates the need to exclude file extensions if you use .sol or .t.sol files for testing.
Some cryptic errors that resulted in trying not to spew too much stacktrace from the CLI has been fixed up so that you’ll
get at least some help to point you in the direction of the problem, although in most cases that was covered by not having the --npm
flag or not running yarn
/ npm install
in the repo before trying to collect those dependencies (it me).
solt verify
The most important and exciting improvement, the reason for the project’s name change and expansion in functionality comes
with the second mode of operation, verifying smart contracts from the command line. There are tools out there that might
plug into your framework or ecosystem, one of the most notable I’ve seen for Truffle being Rosco’s truffle-verify-plugin,
which itself recently received an update!. Some people however
don’t have the option, whether by their choice of development tooling or otherwise. This is where solt
comes in.
Someone using the tools from dapp.tools for instance, in conjunction with something like dapp-pm to manage their dependencies was out of luck until now, and I’ve tried to make it as easy as possible for users to get their deployed contracts verified with as little headache as possible. This means including all the API keys necessary so that (best case) you shouldn’t need to create, store, and manage your own Etherscan API key if you don’t want to, although you can do that as well.
The most basic usage for solt verify
takes the form of:
$ solt verify [file] [address] [contract name] -c [compiler version like 'v0.6.12']
[file]
Points to your solc-input.json
that was generated in the solt write
step
[address]
This is simply your 0x
address of the deployed contract
[contract name]
This can take a couple of forms:
- the name of the main smart contract (this is required by Etherscan, might be able to automate in future). Right now
it will search your
solc-input.json
for a key in the"content":
section for the first match, so it can be as long or short as you want e.g.MyERC
will match a key of./src/mytoken/MyERC.sol
. - the name as before with our own mapping or custom name. This is what you see on Etherscan’s code section of a contract under “Contract Name:”
which is useful for remapping the name to the overall purpose of the contract with its dependencies e.g.
src/mytoken/ERC20Impl.sol:UsefulToken
. If you don’t use a custom mapping it’ll just take the file name without extension, so the previous example will show up asERC20Impl
on Etherscan.
--compiler / -c
The compiler flag is the same as Etherscan’s web portal and I might be able to extract this from build artifacts,
but at the moment it’s easy enough to specify.
Made easier is the fact that whatever you specify here is the first available match, so specifying -c v0.6
will match v0.6.12+commit.27d51765
and -c v0
(if for some reason you like to live dangerously) will at the time of writing this match v0.7.5-nightly.2020.10.29+commit.be02db49
--network
This simply uses a different Etherscan API endpoint, all of which should be supported the same from my testing as their explorer. Chances are if you can see a deployed contract on Etherscan’s explorer you can probably verify it by the same value in this flag as the subdomain (if you are verifying on mainnet you can leave this blank)
--infura
and --etherscan
API Keys
I’ve packaged API keys with the tool, and I can only see the packaged Etherscan key becoming problematic, so this should rarely need to be specified. If however you want to use your own keys (so other users don’t have to create accounts, generate keys and use them here if the shared keys get rate limited), you can specify these or pass them through some CI process or environment variable in the command line:
solt verify ... --infura $INFURA_KEY --etherscan $ETHERSCAN_KEY
Putting It All Together, a Dapp Example
For simplicity, I won’t go into how to get dapp.tools up and running on your machine,
nor will I won’t go into much detail about setting up the deployment process for a project using dapp.tools,
as these can vary form being as simple as talking directly to your json-rpc eth node with an account unlocked, to deploying with custom scripts
using other libraries and languages that use the compiled ABIs. I will simply substitute the deployment step with [run deployment magic here 🧙]
.
Project initialisation
You’ll want to create and enter the directory your contracts will be created and verified from like some variation of the following:
$ cd ~/coolprojects
$ mkdir verified && cd verified
Following this you’ll want to run:
$ dapp init
which will generate your basic project structure, and a Makefile used for building / debugging / deploying your project.
Next, we’ll create a simple ERC20 token, because the world can’t have enough of them – but wait, instead of writing out
an IERC20.sol and implementing it, or specifying some cool mapping(account=>uint256) balances
and other variables,
we will just use OpenZeppelin’s contracts via a simple dapp-pm command:
$ dapp-pm openzeppelin/openzeppelin-contracts@v3.2.0 ERC20.sol
Implementing a token
Now all we need is our own implementation of the token with a cool name, symbol and maybe even mint some, so that they can actually be sent to other users or traded somewhere.
Dapp tools already made us a file at ./src/Verified.sol
which will be our starting point, the only thing we need to add is the import for
OZ’s ERC20.sol
and a constructor which mints us some tokens to play with:
Now we have a contract to deploy, and we can do so with our [run deployment magic here 🧙]
step.
(For actual dapp tools deployment you can look at their instructions or use remixd and deploy via injected Web3)
NB: you will want to take note of whether optimization took place through compilation with how many runs for this next step
If you want to follow the same config as me, I didn’t use any optimization, with compiler version v0.6.7
. As a result
my solt write
step will look like:
$ solt write ./src/Verified.sol --no-optimization
which will output a file called solc-input-verified.json
. Taking note of my deployed address, I can verify my contract (which is deployed to rinkeby)
with the following command:
$ solt verify solc-input-verified.json 0xD66888E0815B87c19b04Fa9DcD495CAb49928912 Verified -c v0.6.7 --network rinkeby
which, after executing and waiting for the result, should return us a Pass - Verified
at the end of execution, or if you’ve just run the exact
same command as I wrote above, it will probably tell you it’s already been verified…
You can check out the output result for my deployed cool token here.
Congratulations you are now the proud owner of 100% of the 10*10^-18 total CoolTokens in existence, don’t spend them all in one place!
Wrapping Up
If you’ve found solt
useful reach out to me and let me know on Twitter @harris_s0n or by showing your appreciation
on the repository on GitHub. If you have any suggestions for feature improvements don’t hesitate to reach out on either platform either by DM, tagging me, or raising an issue!
I’ll be looking forward to adding extra features as requested and building the Solidity tool you look forward to using.
If you got this far thanks for your time, I hope I save you some in the future with solt
!