CBOR data should be included into the bytecode

[KitHat]

Problem
The OpenZeppelin Upgrades plugin uses contract bytecode to distinguish between artifacts and locate storage layouts. Currently, resolc generates identical bytecode for contracts that differ only in their storage layout (e.g., different __gap sizes), causing the plugin to fail to differentiate between contract versions.
Example
These two contracts produce identical bytecode:

contract GapV1 {
    string greeting;
    uint256[49] private __gap;
    uint256 end;
}

contract GapV2 {
    string greeting;
    uint256 new1;
    uint256 new2;
    uint256[47] private __gap;
    uint256 end;
}

Root Cause
resolc does not append CBOR metadata to the bytecode, which would normally differentiate contracts with identical runtime logic but different source code or storage layouts.
Related Issues

Depends on: #379 (should be tested after this issue is resolved)

[xermicus]

We are currently working out how to do this. See the already open PR predating this issue, further discussion is happening on the forum

It may not be as straight forward since pallet-revive relies on bytecode hashes for instantiation (i.e. with libraries we can't simply change the bytecode hash with appending CBOR data).

As a side note / suggestion: The OZ plugin should fail early on missing or incorrect CBOR data. It seems very dangerous to blindly make assumptions on some bytecode and then deploy said bytecode without performing basic validity checks.

[leonardocustodio]

I don't know if this can be useful or not but I wonder what kind of CBOR data we use. Recentely I've come across this: https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/ which basically applies a few "limits" to how CBOR should be encoded/decode so we have a deterministic version of it. I've started a typescript implementation for a project of my own but I guess the rust reference is a better source.

Rust ref: https://docs.rs/dcbor/latest/dcbor/
Resource: https://developer.blockchaincommons.com/dcbor/

[KitHat]

Hey @xermicus !
I am really sorry for the long reply. Taking into account the vision of Revive for CBOR data, that's how I can suggest to resolve the problem.
Appending the CBOR to the bytecode seems like a workaround inherited from Ethereum and Revive should not be accepting all of the workarounds by default.
At the same time, CBOR currently is nowhere to be found in the artifacts produced by resolc -- and this is the root of the problem. We can make a workaround on our side looking for the CBOR in other places, but it is just not generated.

What about failing early in case of missing CBOR -- well, we can implement it with a look at Ethereum implementation but it will make it impossible to support the Polkadot AssetHub for OpenZeppelin Upgrades. Let's define the place for the CBOR in resolc artifacts and I think that this can satisfy all the goals.

[xermicus]

If you think it's valuable to have the metadata hash embedded in a different way that'd be even better.

I'm just worried that we eventually have to give in and stick the same hacky workarounds they use on Ethereum. That was always the usual pattern so far.

[KitHat]

I think that we can't make Upgrades plugin work reliably without this metadata present somewhere inside the artifact, so yes, it would be really valuable for us.