About Contracts Verification

Contracts verification is an important step for the deployment of EVMv1 smart contracts. The goals of the production pipeline of the contracts verification are:

1. Automated verification after each smart contracts deployment.
2. Reproducible verification process locally as a developer.
3. Support major block explorer solutions.
4. Keep the pipeline lean.

Production Pipeline

• It uses truffle-plugin-verify.
• Scripts:
  • info-print-contract-addresses.js
  • etherscan-verify-framework.sh
  • code snippets:

    cd packages/ethereum-contracts
    npx truffle exec --network ${{ matrix.network }} scripts/info-print-contract-addresses.js : addresses.vars
    source addresses.vars
    source tasks/etherscan-verify-framework.sh ${{ matrix.network }}

• Workflows integrated with the pipeline:
  • handler.deploy-to-testnets.yml
• Supported systems:
  • Etherscan and its cousins.
  • Sourcify (not yet working reliable for all chains with the plugin being used)
• Supported networks: See networks.json - the explorer field contains the primary etherscan-like explorer for the network.

While etherscan-like explorers are the only ones we explicitly verify for, other explorers may now also show verified contracts if they use the sourcify repository of verified contracts. Examples of such alternative explorers are Avascan, available for Avalanche and Blockscout, available for various networks.

Security Considerations

Verifiability

The Solidity compiler generates contract metadata which contains the contract ABI, compiler version and settings, hashes of source files, natspec docs and more - see related Solidity docs.
A hash of this metadata and the compiler version are CBOR encoded and appended to the bytecode deployed on chain, such that the compile-time metadata is cryptographically verifiable.
Check out the sourcify playground for an intuitive and interactive explanation.

Availability

Making metadata (most importantly - the underlying sourcecode) available is a process independent of the actual contract deployment.

With sourcify there now exists an open and decentralized repository for verified contracts.
The process of getting contracts verified on sourcify via the truffle verification plugin is still not very reliable, thus not all Superfluid contracts may be verified on sourcify all the time.

Contracts additionally get verified on etherscan-like explorers via their API.
After verification of a contract, this explorers provide a UI interface which not only shows the contract source code, but also provides forms which allow to query and modify (if a wallet is connected) the contract state based on its ABI. It essentially provides a minimal, autogenerated Dapp for every verified contract, based on its public interface. As an example, see the Polygon Superfluid Host contract.

Proxies

Etherscan-like explorers also have a convenience feature for explicit support of EIP-1967, rendering additional tabs "Read Proxy" and "Write Proxy" for contracts using this ERC. That's the case for many Superfluid protocol contracts.
Important: This convenience feature needs to be used with caution! Etherscan assumes that the ERC is used as intended. A malicious contract may pretend to delegate to a contract as signaled in the EIP-1967 storage slot, while in reality doing something else. In this case the Etherscan UI can be misleading. Such cases can be discovered by carefully studying the logic of the proxy contract itself.

Bugs & Future Work

• Since truffle is being sunset, investigate upgrading to hardhat and/or foundry and its plugin as new pipeline