Bytecode mismatch during verification

[coreycaplan3]

As background, I've verified dozens of contracts without any issues before, but this one is giving me issues with bytecode not matching.

My recommendation would be deploying this file via Remix and attempting to verify it on the Harmony explorer: https://github.com/FATEx-DAO/fatex-dex-protocol/blob/master/contracts/fatex/FateRewardControllerV2_flat.sol

I've made modifications to the original FateRewardControllerV2.sol file to exclude things that could cause the verifier to produce different bytecode, like:

• Arrays in constructors
• ABI Encoder V2
• Replace usages of implemented contracts as interfaces, (like RewardSchedule)
• Deploying with optimizations on and off, and attempting to verify the file with optimizations on/off

If you are able to deploy and verify it, can you please share what you did to do so and transfer ownership to the following address: 0x4853365bc81f8270d902076892e13f27c27e7266

[victaphu]

Hi, I'll take a look at this thanks

[Ciantera-Rose]

Hi there @victaphu ...Any updates or feedback regarding a resolution to this issue?

[victaphu]

in progress these bytecode mismatch can be quite a challenge to solve. will report back here once we find a resolution

[coreycaplan3]

It may help if the server responded with a diff of what it got vs what's on-chain, like what Etherscan does.

[victaphu]

not sure if this makes a difference; the verifier code uses nodejs 12

@coreycaplan3 to your point about the difference between what server got and what is on chain; makes sense; maybe @hypnagonia we can consider this as part of the returned error message

[coreycaplan3]

I don't think we have control over which version of nodejs Remix uses when deploying like this, though.

[victaphu]

FateRewardControllerV2.json.zip

This is using a copy I have deployed. https://explorer.harmony.one/address/0xeef905fa398203987352b7f0dc4cdb1be246e2e5?activeTab=7

[coreycaplan3]

I see. If you check the compiled binaries (bytecode), you can see that it does indeed match the bytecode that is on-chain now

[victaphu]

Interesting; we are looking at the deployedBytecode field (not the bytecode field)

Can you share me your deployed address and I can generate the above as well?

[coreycaplan3]

Here is an example deployment.

You can see the input data (minus the constructor args) matches the bytecode exactly and the bytecode found here matches the deployed bytecode exactly.

Here is the JSON file

This is the minified .sol file

[coreycaplan3]

Also, I'm using the optimizer with 10,000 iterations

[victaphu]

Ok I used your configuration to compile and the results follow: FateRewardControllerV2.json.zip

[victaphu]

These are the two values that appear at the end of the bytecode which is different: 92831660048201529051929391909116916370a0823191602480820192602092909190829003018186803b1580156100ef57600080fd5b505afa158015610103573d6000803e3d6000fd5b505050506040513d602081101561011957600080fd5b50519291505056fea 264697066735822122061caadd258602d2566efe6983c099185ce1dfcf7f356eae6508e7300ec69fa9b 64736f6c634300060c00334f776e61626c653a206e6577206f776e657220697320746865207a65726f2061646472657373416464726573733a20696e73756666696369656e742062616c616e636520666f722063616c6c536166654d6174683a206d756c7469706c69636174696f6e206f766572666c6f775361666545524332303a204552433230206f7065726174696f6e20646964206e6f7420737563636565645361666545524332303a20617070726f76652066726f6d206e6f6e2d7a65726f20746f206e6f6e2d7a65726f20616c6c6f77616e6365a2646970667358221220 435e7de01078338534adb9b33222f47318495da886f158dd53d4fde1ad8b28376 4736f6c634300060c0033

Everything else matches; this is from the generated JSON file on the server side. Any idea what those two values are? This snippet is the at the very end of the deployedBytecode

[coreycaplan3]

Can you format the two snippets differently? I'm not sure where the two snippets begin and end because of the weird line breaks. Perhaps separate them using blocks of code using "```" markdown styling?

[victaphu]

Ok, so I've isolated it to what appears to be two sets of metadata hashes. a2646970667358221220cb6b6e63052e8a95df28b9fb3f9e4f5e47c9ee103524afd4b7daff839cc05ce564736f6c634300060c0033 and a26469706673582212205a34ddc9134accdb0e68e6073d3a752e1cc43f72cf634938fe3df5b9b0f5b19464736f6c634300060c0033

The code strips out the second hash but leaves in place the first hash. This metadata doesn't match up and because of that the explorer rejects the validation. Let me test a bit more and get back to you

[coreycaplan3]

Please let me know what progress you make on this and if I can help!

[victaphu]

https://explorer.harmony.one/address/0x47c412ff16c9e01de9a032b8ef580d2fc21df28c?activeTab=7

Solved it! But you're not gonna like how to fix it ...

I was thinking why it generated two metadata files ... and it dawned on me that maybe you have more than one concrete class in the solidity file. I checked and indeed you do; a MockLpToken class and the FateRewardControllerV2

I commented out MockLpToken and deployed (to test) and that was the cause. Somehow you need to incorporate MockLpToken without having it be part of the flattened FateRewardControllerV2 file.

[coreycaplan3]

Awesome, thank you!!

I can just make a factory and factory interface for deploying the MockLpToken. That should abstract it away.

Any idea if it's possible to perform a long-term fix for this on the explorer?

[victaphu]

@coreycaplan3 definitely, we are looking at ways to improve the explorer and really appreciate input from the community.

One such option is to allow multi-file uploads so you don't need to flatten the files. Others include figuring out how to use the metadata more effectively.

Not sure about the timeline tho, there is so much to do!

Give it another test, and if this looks good would you be able to close the issue.

[coreycaplan3]

It worked!