Blockscout: Contract verification does not succeed

[weilbith]

The verification of some contracts do not work with blockscout instances. This problem occurred on a private setup as well. Thereby I did a test and deployed a contract to the _Kovan_ testchain. Then I was able to successfully verify the contract at Etherscan. But when I use the exact same verification parameter at Blockscout it fails. As response I always get Bytecode does not match, please try again.. Other contracts do work. But this specific one (not the specific deployment, but each deployment) does not.
The only hint I have is the following log snippet from a local instance:

2019-12-05T16:38:39.160 fetcher=block_realtime [error] GenServer Indexer.Block.Realtime.Fetcher terminating
  ** (stop) exited in: GenServer.call(Indexer.Block.Realtime.WebSocket, {:subscribe, "newHeads", []}, 5000)
    ** (EXIT) time out
    (elixir) lib/gen_server.ex:1009: GenServer.call/3
    (indexer) lib/indexer/block/realtime/fetcher.ex:154: Indexer.Block.Realtime.Fetcher.subscribe_to_new_heads/2
    (indexer) lib/indexer/block/realtime/fetcher.ex:73: Indexer.Block.Realtime.Fetcher.handle_continue/2
    (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
    (stdlib) gen_server.erl:388: :gen_server.loop/7
    (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
Last message: {:continue, {:init, [transport: EthereumJSONRPC.WebSocket, transport_options: %EthereumJSONRPC.WebSocket{url: "ws://xxx.xxx.xxx.xxxx:8546", web_socket: EthereumJSONRPC.WebSocket.WebSocketClient, web_socket_options: %EthereumJSON
State: %Indexer.Block.Realtime.Fetcher{block_fetcher: %Indexer.Block.Fetcher{broadcast: :realtime, callback_module: Indexer.Block.Realtime.Fetcher, json_rpc_named_arguments: [transport: EthereumJSONRPC.HTTP, transport_options: [http: Ether

Mark that I censored the IP address in the log to the archive node. The archive node does not log something related to this event. I'm not sure if this problem also occurs on the public _Kovan_ instance for Blockscout.

Steps to reproduce

• visit the deployed contract with the above link to the Blockscout
• go for verifing the contract
• insert the exact same values as used for Etherscan (link also above)

Expected behaviour

Contract verification succeeds.

Actual behaviour

I always fails, even if it should succeed as Etherscan proofs.

[vbaranov]

@weilbith I successfully verified your contract https://blockscout.com/eth/kovan/address/0x3397553ee19d30543e0f369f2ca8f59f2ea8ec5b/contracts using all the data from Etherscan.

[vbaranov]

I will put here instruction for verification, just in case https://docs.blockscout.com/for-users/untitled/verifying-a-smart-contract https://docs.blockscout.com/for-users/untitled/verifying-a-smart-contract. Can we close this issue?

[weilbith]

@vbaranov thanks for your quick response! :slightly_smiling_face:

I deployed the contract another time and used your verification as template. Thereby I registered that the constructor arguments are different. So using the constructor argument as I for Etherscan it fails to verify on Blockscout (again). Using yours make the verification work.
So I'm confused what this is about. It appears like the constructor arguments for the Blockscout are longer, adding 174 additional bytes. From the code, the constructor consists of two arguments. An address and an uint. Both are encoded with 64 bytes. For this exact example the arguments are 0x0fb5a36f0e12cef9f88d95f0e02cad4ba183336dc and 50. Encoded they are 000000000000000000000000fb5a36f0e12cef9f88d95f0e02cad4ba183336dc0000000000000000000000000000000000000000000000000000000000000032. This is the same as Etherscan accept it and also display in the encoded view. So now on Blockscout we actually have the same. But additionally it gets prefixed with 5f76616c696461746f7273526571756972656450657263656e74206d757374206265206265747765656e203020616e642031303070726f7879206d757374206e6f7420626520746865207a65726f206164647265737321. The interesting thing now is, that the view of the both arguments is incorrect. It shows that the first address argument is supposed to be 6571756972656450657263656e74206d75737420. This snippet can be found within the (for me unknown) prefixed snippet. So it actually tries to parse the first 64 bytes as the address. Just that it is no address, since the first 24 bytes are not zero (40 byte long addresses). The second uint argument is shown to be 44505334223345046509465772205219288912186822148299486539289764630751956181102. And here I can't even find this in the whole constructor argument snippet. No clue where this comes from.

Please help me to understand. I see that your constructor works. But I don't get what the additional data is. Also also why the decoding within the web-view is not correct when I use the extended constructor arguments.
Thanks for your help!

[vbaranov]

Indeed, it looks like a bug. It should be verified with the constructor arguments from Etherscan. In my verification, I used auto-appending of constructor arguments. This is why I didn't face this issue.

[weilbith]

Just as addition:
I "educated" myself to understand this problem better. So as I understand it now is that in contrast to Etherscan, Blockscout expect the user to provide the whole init code of the deployment which returns the bytecode for the contract. This includes the constructor arguments, but also the additional code for the EVM to execute. If I follow the documentation you send me strictly, I get this full set of bytes, just as your automated suggestion feature does as well.
So Etherscan seem to be able to get this missing init code on its own. What makes me wonder is that it appears to work the same for some contracts on Blockscout as well. But not for others like the above one.
Anyways accepting for the moment that the to provide constructor arguments must include the whole init code, the view of the single arguments is still wrong, as described earlier.

Again thanks for your fast support!

[vbaranov]

I figuered out, that additional hash, which is in question 5f76616c696461746f7273526571756972656450657263656e74206d757374206265206265747765656e203020616e642031303070726f7879206d757374206e6f7420626520746865207a65726f206164647265737321 which appears in encoded constructor arguments in Blockscout is nothing else as hex("_validatorsRequiredPercent must be between 0 and 100") + hex("proxy must not be the zero address!"). Thus, we need to exclude all messages from constructor's requires from constructor arguments encoded view on verification. I will create an issue for that.

[vbaranov]

The fix is on master branch and deployed to Kovan chain.