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

Review unconstrained ContractClassRegisterer log hash #8978

Open
nventuro opened this issue Oct 2, 2024 · 0 comments
Open

Review unconstrained ContractClassRegisterer log hash #8978

nventuro opened this issue Oct 2, 2024 · 0 comments
Labels
A-security Area: Relates to security. Something is insecure. C-aztec.nr Component: Aztec smart contract framework team-spf Nico's team

Comments

@nventuro
Copy link
Contributor

nventuro commented Oct 2, 2024

The ContractClassRegisterer calls emit_contract_class_unencrypted_log_private, which returns the hash of the bytecode registration log from an oracle. This value is not constrained, because hashing such a large bytecode would result in a circuit so large that Noir is unable to handle it (or rather was unable a couple months ago - this may have changed).

The code hints at this not being an issue because we've committed to the bytecode anyway, but I think it may be missing something.

The point of the registerer is to ensure that a contract's bytecode is available: if a public call is made to a contract, then the sequencer must execute its code which of course requires knowing what it is in the first place. The kernel circuits assume that the sequencer is listening to contract class registration events, and therefore knows the bytecode if the contract was ever registered. The sequencer is only allowed to not make the public call if it can prove nullifier non-inclusion, i.e. non-registration, since in this case there is no guarantee that the bytecode has been distributed.

If the above is correct, then not constraining the log hash can be very dangerous: a malicious user could deploy a contract and inject a bad log hash via a malicious oracle. Sequencers that do not know the bytecode would then be unable to produce proofs for transactions that include calls to this contract.

@nventuro nventuro added C-aztec.nr Component: Aztec smart contract framework A-security Area: Relates to security. Something is insecure. team-spf Nico's team labels Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-security Area: Relates to security. Something is insecure. C-aztec.nr Component: Aztec smart contract framework team-spf Nico's team
Projects
Status: Todo
Development

No branches or pull requests

1 participant