Blockscout: Unable to "Verify&Publish" source code

[drortirosh]

Describe your issue here.

The "Verify&Publish" for blockscout suggests to use source flattener, and upload the entire source as a single file.
However, with the latest solc version (0.6.x), this is sometimes NOT possible:

The "opengsn" project uses the ABIEncoderV2, but some external sources don't use it.
As a result, when flattening the file the "pragma ABIEncoderV2" is applied to entire code, instead of just parts.
The consequence is that the generated bytecode for flattened file is different.
We already deployed the contract to mainnet, kovan, ropsten along with source code - but currently we found out that we can't upload source code for the XDAI deployment.

For deployment to ethereum network, we uploaded the "standard-json" file that was used to compile, and thus kept the separate files separate.
https://kovan.etherscan.io/address/0xA17C8F25668a5748E9B80ED8Ff842f8909258bF6#code
The same contract was deployed to xDAI, but currently we can't upload its sources: https://blockscout.com/poa/xdai/address/0xA58B6fC9264ce507d0B0B477ceE31674341CB27e/contracts

Steps to reproduce

git clone https://github.com/opengsn/gsn.git && cd gsn && yarn && truffle compile

the code is generated in build/contracts/RelayHub.sol

Then if you flatten the contracts/RelayHub.sol (and remove duplicate SPDX comments and "pragma ABIEncoderV2" , since flatteners don't recognize them yet) and compile it, you get slightly different output, enough to be rejected by "Verify&Publish" ...

Expected behaviour

Verify&Publish should accept a single "json-standard" file instead of input file.
Simply, if the input starts with {"language":"Solidity","sources":...
try to parse it as a json-standard input.

[vbaranov]

@drortirosh thanks for a thorough description. Sounds like it is time to allow verification with standard JSON input in Blockscout. I will start working on it soon.

[acrylix]

@vbaranov any updates on accepting solidity standard JSON inputs for contract verifications?

[vbaranov]

@drortirosh @acrylix we added integration with Sourcify tool. Now it is possible to verify contracts by attaching source files without flattening them together with JSON with compilation metadata. This feature is available on xDai instance of Blockscout.

[xuhcc]

@vbaranov Compilation metadata and standard JSON input are different things. Unfortunately Sourcify doesn't yet support the latter: https://github.com/ethereum/sourcify/issues/319

[vbaranov]

@xuhcc

Compilation metadata and standard JSON input are different things

yeah, that is right. Though, I like Sourcify's approach with a single files drop zone. It makes the verification process faster. From your perspective, is it harder to get JSON with metadata vs Solidity Standard JSON input file? Just from curiosity, why do you like the second approach more?

[xuhcc]

I'm using buidler/hardhat for development and it generates standard JSON input during the compilation, so it's really easy for me to provide standard JSON to a verification service. There's also a tool called solt that can generate standard JSON. But I'm not aware of a simple way to generate metadata JSON in my development environment.

Another reason is that dapp I'm currently working on consists of ~40 contracts and it's tedious to upload them one by one. With standard JSON you can upload just one file which includes all sources.

[drortirosh]

All is true.
The idea is not to optimize the verification time, but the DEVELOPER time:
The compilers (hardhat, truffle) uses a "standard json input" file, and save it.
I don't want to have yet another tool to generate the input for the source verifier - it should be able to use the development toolchain.
The only drawback of the "standard json" is that it doesn't comain the compiler version, and as developers we have to enter it manually.

I really don't care to use the OUTPUT of the compiler instead (it contains all source code, binaries - and also metadata info, such as compiler version in use) - but in that it differs between hardhat and truffle.

[mudgen]

Any progress on this? I made a duplicate issue here: #3587

[rkalis]

I want to add to this thread that I'll gladly add blockscout verification to truffle-plugin-verify if you guys add a verify API that uses Solidity Standard Input JSON (similar to Etherscan). That's what I use for the Etherscan verification, and I don't want the usage between Etherscan and Blockscout verification in the plugin to differ too much.

@vbaranov by integration with sourcify, do you mean that if it's verified in sourcify, that any Blockscout explorer automatically picks that up as well? I've been wanting to add sourcify verification to the plugin as well, so if that automatically propagates to blockscout that'd be very cool.

[hellwolf]

whelp, it's so painful to verify sources at the moment on blockscout.

[d10r]

@vbaranov by integration with sourcify, do you mean that if it's verified in sourcify, that any Blockscout explorer automatically picks that up as well? I've been wanting to add sourcify verification to the plugin as well, so if that automatically propagates to blockscout that'd be very cool.

+1 for this

[d10r]

Here's an example for a contract I failed to verify on Blockscout (multiple attempts in both single flattened file and multi-file mode), but succeeded to verify through https://sourcify.dev/.
Entry on sourcify

Would love to get this verified on blockscout too in order to see the full beauty of txs like this (starts an _airstreem_ / streaming airdrop).

If I correctly understood the feedback of Viktor in the chat, blockscout can already sync from sourcify, but not yet partial matches as is the case here. What I didn't yet understand is how such a syncing attempt is triggered. Some manual action needed for that?