EVM with verified source code on ropsten

I want to share how I verified the zos smart contract source code on etherscan, I think have them verified helps a lot when I want to do a quick interaction with the contract, I personally used it a lot. So I went through a lot of trouble and digging around in order to do it, this is what I did:

I had to go into node_modules folder and dig around to get the right contract source code and compiler version, when I entered the node_modules/zos I end up in models/network/ProjectDeployer and I saw that they were still using the contracts from zos-lib, that surprised me because the latest contracts are in https://github.com/zeppelinos/zos/tree/master/packages/lib/contracts.

So I took a look to the version of the compiler used that is in the build files in node_modules/zos-lib/build and flattened the contract source by using the truffle-flattener that I have as a global dependency in my system running truffle-flattener contracts/application/App.sol > contracts/application/AppFalettened.sol

Once done all this I went to my App contract and verify it on etherscan, important note: The optimizer is not used.

Verified App contract https://ropsten.etherscan.io/address/0x7e5a2087cd5fcd00f93a88653c272fa7a92d5bee#code

Verified Package contract https://ropsten.etherscan.io/address/0x46ccb0c97193521055847bc9bb31271e84f521c2#code

Verified ImplementationDirectory contract https://ropsten.etherscan.io/address/0x89576483a621237cb9070196d91fb76f252dc236#code

Another thing that caught my attention is that in the zos.ropsten.json file the ImplemetationDirectory contract is referred as “provider” when in reality is a directory that can be sued with the ImplementationProvider interface, maybe it should be called directory instead of provider or implementation-directory in the .json files?

Also, now every smart contract deployed using zos that have the same code are now verified! So at least now every zos smart contract deployed on ropsten will have the read/write options enabled on etherscan :champagne:

4 Likes

Now I also verified the openzeppelin mainnet contracts in https://github.com/OpenZeppelin/openzeppelin-eth/blob/master/zos.mainnet.json

App: https://etherscan.io/address/0x2ba1a8c7352a5b5ea3ea3408f89e1ba7920d36ce#code

Package: https://etherscan.io/address/0x778dddf23ec1b5cb18394c6c110480caadb3b0f6#code

ImplementationProvider: https://etherscan.io/address/0x06cebabebbe51b87e9d5d9bac398092bd12cd5b2#code

Thanks to etherscan similar match contracts verification all contracts deployed and that will eb deploeyd with teh same source code and compiler will be automatically verified ! :beers:

1 Like

Woah! Thank you for sharing! :smile:

I’m sure others can benefit from this, @spalladino should definitely see this!
I’m thinking we should add clearer documentation to the verify command.

I found it, but it works only with etherchain, I dont knwo how much sense it has to add it for etherscan… since etherscan automatically verify all contracts that has similar match with the one that is verified. So once the zos-lib contract changes we just need to verify it once and voila :mage:

2 Likes

This is really timely! I was just playing around with Etherscan thinking “How can I get this verified?”. Maybe we can sync up on slack and you can talk me through the process. I think it would make an interesting tutorial.

Hola @Dennison, its all described there, actually is not taht hard, you need the source code, the compiler version and if it was optimized or not. How I got it is described on the post.

The thing is all future deployed contracts of zeppelin libs with teh same source code and compiler version are going to be automatically verified now on etherscan. So I guess that next time a a change is done on teh contracts or the compiled bytecode used by the libraries changed someone from zeppelin can verifiy it and it will automatically verified future new contracts.

Hey @augustol, thanks so much for doing this! It has been on our TODO list for quite some time, and it’s awesome to see that you’ve picked it up. Thanks a lot!!

Yep, that’s because we moved to a monorepo a while ago; so packages/lib in the zos repo actually gets published as the zos-lib npm package.

True. We wanted to highlight the fact that we were interested in just tracking the provider interface, which is something that can solve a name into an address, whereas directory is the implementation of that interface. But having two names can be confusing, so it may be a good idea to just keep one of them.

We added support for etherscan on release 2.1, since back at the time only etherchain had an API for source code verification. Either way, the verify command only verifies your contracts, not the zOS ones, so we really needed this!

Yep! We should add this to our release process whenever we change the contracts - as is going to happen for release 2.2. Thanks!

2 Likes