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

Outputting the CBOR Metadata positions in the bytecode #14827

Open
kuzdogan opened this issue Jan 31, 2024 · 1 comment · May be fixed by #15710
Open

Outputting the CBOR Metadata positions in the bytecode #14827

kuzdogan opened this issue Jan 31, 2024 · 1 comment · May be fixed by #15710
Assignees
Labels
feature high impact Changes are very prominent and affect users or the project in a major way. low effort There is not much implementation work to be done. The task is very easy or tiny. must have Something we consider an essential part of Solidity 1.0.

Comments

@kuzdogan
Copy link
Member

kuzdogan commented Jan 31, 2024

In compiler's output bytecode, some values need special attention during source code verification. These fields can be different between the compiled bytecode vs the on-chain bytecode. Still, they shouldn't break the verification because they are typically filled/assigned after compilation or the changes are not because of a change in the executed code (but comments etc.)

  1. Libraries: External library addresses are linked with --link or in JSON-input libraries:. This would replace the placeholder in format __$53aea86b7d70b31448b230b20ae141a537$__ with the library address in the bytecode.
  2. Immutables: Immutable variables in the bytecode are set to 000000... in the bytecode in compilation and only assigned a value in the constructor during deployment.
  3. CBOR metadata: Appended to the runtime bytecode. Contains the metadata hash so any slight change to the source files or the metadata file contents will change this value. If during verification the onchain CBOR does not match the compiled one, this will yield a partial match.

It is trivial to find libraries and immutables in a compiled bytecode because the former has special __$ placeholders and the latter's indexes are output in immutableReferences in the compiler.

However, the CBOR metadata part is not trivial to find:

  1. The bytecode can contain other contract bytecodes nested (e.g. factories) so only the main contract's CBOR is at the end of the bytecode and the other contracts' positions are unknown.
  2. Even if there's a single contract, the CBOR metadata is not necessarily at the end of the bytecode for the creation bytecode. It can be anywhere.

That's why verifiers typically use workarounds to find the exact positions such as adding whitespaces to all sources to change the metadata hashes. That requires recompiling the contract and is an expensive operation.

I suggest the compiler outputs the bytecode positions of the CBOR encoded metadata parts of the contracts, similar to how it's done in immutableReferences. This would make the source-code verification processes easier and also extracting the CBOR parts for other purposes.

Edit: Wrote an article about this, for some context: https://docs.sourcify.dev/blog/finding-auxdatas-in-bytecode/

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label May 15, 2024
@ekpyron ekpyron added low effort There is not much implementation work to be done. The task is very easy or tiny. high impact Changes are very prominent and affect users or the project in a major way. must have Something we consider an essential part of Solidity 1.0. and removed stale The issue/PR was marked as stale because it has been open for too long. labels May 15, 2024
@nikola-matic nikola-matic self-assigned this Aug 5, 2024
@ethereum ethereum deleted a comment from github-actions bot Jan 20, 2025
@cameel cameel linked a pull request Jan 20, 2025 that will close this issue
1 task
@cameel
Copy link
Member

cameel commented Jan 21, 2025

Looks like we actually had an earlier issue for this: #9332.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature high impact Changes are very prominent and affect users or the project in a major way. low effort There is not much implementation work to be done. The task is very easy or tiny. must have Something we consider an essential part of Solidity 1.0.
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

4 participants