Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to "Verify&Publish" source code #3211

Closed
drortirosh opened this issue Jul 22, 2020 · 16 comments · Fixed by #4908
Closed

Unable to "Verify&Publish" source code #3211

drortirosh opened this issue Jul 22, 2020 · 16 comments · Fixed by #4908
Assignees
Labels
contract verification waiting on feedback Waiting for original opener to respond if bug is fixed

Comments

@drortirosh
Copy link

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
Copy link
Member

@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
Copy link

acrylix commented Nov 17, 2020

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

@vbaranov
Copy link
Member

@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.

@vbaranov vbaranov added the waiting on feedback Waiting for original opener to respond if bug is fixed label Dec 22, 2020
@xuhcc
Copy link

xuhcc commented Dec 22, 2020

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

@vbaranov
Copy link
Member

@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
Copy link

xuhcc commented Dec 22, 2020

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
Copy link
Author

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
Copy link

mudgen commented Jan 25, 2021

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

@rkalis
Copy link

rkalis commented Feb 15, 2021

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
Copy link

hellwolf commented Mar 16, 2021

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

@d10r
Copy link
Contributor

d10r commented Mar 22, 2021

@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
Copy link
Contributor

d10r commented Mar 27, 2021

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?

@DaveAppleton
Copy link

Can I add to all this, that with Blockscout being the default explorer on Polygon this issue has become way more important.

@heri16
Copy link

heri16 commented Jun 19, 2021

Is blockscout project dead?

@helderjnpinto
Copy link
Contributor

any development in this part verify and publish smart contracts ? also read from proxy implementations?

@helderjnpinto
Copy link
Contributor

I'm just put here my pain and my thoughts :).
For a simple contract and tiny i can verify manually.
For a complex contract several dependencies and also Proxy implementantion is not easy always fail for some reason the bytecode don't match (tested with Hyperleder Besu + blockscout).
There are plugins to verify via (truffle and hardhat) to etherscan.com, blockscout just need to implement same api parameters like etherscan with this anyone can fork this plugins and change to blockscout api uri or simply add a setup to change the etherscan URL in this plugins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contract verification waiting on feedback Waiting for original opener to respond if bug is fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.