-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Comments
@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. |
@vbaranov any updates on accepting solidity standard JSON inputs for contract verifications? |
@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 Compilation metadata and standard JSON input are different things. Unfortunately Sourcify doesn't yet support the latter: ethereum/sourcify#319 |
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? |
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. |
All is true. 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. |
Any progress on this? I made a duplicate issue here: #3587 |
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. |
whelp, it's so painful to verify sources at the moment on blockscout. |
+1 for this |
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/. 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? |
Can I add to all this, that with Blockscout being the default explorer on Polygon this issue has become way more important. |
Is blockscout project dead? |
any development in this part verify and publish smart contracts ? also read from proxy implementations? |
I'm just put here my pain and my thoughts :). |
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
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.
The text was updated successfully, but these errors were encountered: