Support easy multifile verification on block explorers

[abcoathup]

Abstract

Support easy multifile verification on block explorers, as many developers flatten contracts to verify.
Whilst not a compiler issue per-se, we need the ecosystem to support.

Previously discussed indirectly: #8989

Motivation

There is a community expectation that code controlling any value will be verified on block explorers.

Etherscan verify API only supports flattened files

from: https://etherscan.io/apis#contracts
Contracts that use "imports" will need to have the code concatenated into one file as we do not support "imports" in separate files. You can try using the Blockcat solidity-flattener or SolidityFlattery

This means that many developers flatten their contracts to verify.

Flattening with SPDX License Identifiers is now a problem as developers either need to ensure that they use a single compatible license otherwise they could be changing/removing the license of third party code that they are importing.
https://forum.openzeppelin.com/t/solidity-0-6-8-introduces-spdx-license-identifiers/2859

Etherscan web interface supports multiple files but the files have to be in a single directory and the imports changed so that the imports use a single directory.

Creating this issue here to raise awareness of the problem so that we can solve for the ecosystem.
https://twitter.com/ethchris/status/1296430655979618309?s=20

If we could make multifile verification easy for all developers then there would no longer be a need to flatten.

Example

The following simple ERC20 token inheriting from the OpenZeppelin Contracts ERC20 implementation was deployed to Rinkeby using Truffle.

SimpleToken.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

/**
 * @title SimpleToken
 * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.
 * Note they can later distribute these tokens as they wish using `transfer` and other
 * `ERC20` functions.
 */
contract SimpleToken is ERC20 {

    /**
     * @dev Constructor that gives msg.sender all of existing tokens.
     */
    constructor () public ERC20("Simple Token", "SIM") {
        _mint(msg.sender, 1000000 * (10 ** uint256(decimals())));
    }
}

To verify as multifile, the SimpleToken.sol contract along with the five imported contracts had to be placed in a single directory, copying the required contracts from node_modules/@openzeppelin/contracts and then modifying any imports whether relative or from @openzeppelin/contracts to be relative to a single directory.

The contract could then be verified uploading the files from the one directory:

1)  Address.sol |   | (6078 Bytes)
2)  Context.sol |   | (933 Bytes)
3)  ERC20.sol |   | (10765 Bytes)
4)  IERC20.sol |   | (2696 Bytes)
5)  SafeMath.sol |   | (5201 Bytes)
6)  SimpleToken.sol |   | (559 Bytes)

The end result is the six contracts being verified, but the contracts still had to have their imports modified, so they are not the exact same text as what was used to compile/deploy.

https://rinkeby.etherscan.io/address/0xd43C0a135F36A8D8a3961d3d56BdCccD47CBD319#code

---

Compare with the process of flattening (or even using a tool that connects to the API) - except for the issue of multiple SPDX License identifiers since Solidity 0.6.8

$ npx truffle-flattener ./contracts/SimpleToken.sol > ./FlatSimpleToken.sol
npx: installed 64 in 13.339s

[chriseth]

Thanks for opening this issue! We will try to tackle a specific verification failure like #9573 but I fear that a generic issue like this is not really helpful:

The compiler has been generating metadata files that are meant to make verification a breeze for years. So apart from fixing bugs, I don't think the compiler (this repository) can really improve the situation. Still, flattening is preferred over these metadata files, even though they contain more information like optimizer settings and so on which you usually have to manually enter after flattening.

The sourcify project tries to solve the user-interface part of verification and one goal is indeed to provide easy to use npm packages like you describe at the end of the issue description.

We could discuss here how to improve etherscan's multi-file verification here, but I don't think this is helpful.

[abcoathup]

Hi @chriseth,

I created the issue here to raise awareness with the team of this pain point in the community.
Feel free to close.
I have posted a version of this on the OpenZeppelin Community Forum: https://forum.openzeppelin.com/t/easy-multifile-verification-on-block-explorers/3621

A short term workaround could be a tool that copies a contract and it's dependencies to a single directory and updates the imports to be local to the directory. This would enable use of Etherscans web based verification.

Though long term we need deploy tools to verify to block explorers and/or sourcify via APIs automagically.

Unfortunately the community will still flatten contracts until we have easy multifile verification.

[abcoathup]

Using Buidler and NomicLabs we can say goodbye to flattening.

https://github.com/nomiclabs/buidler/tree/development/packages/buidler-etherscan

Verified on Etherscan looks as follows:
https://rinkeby.etherscan.io/address/0x2E1DCeFc2a998118354d90172737A91097431C20#code

Closing this issue as resolved.