feat!: constrain the GetContractInstance opcode in AVM

[dbanks12]

Design-ish document

1. Implements GetContractInstance opcode
2. Removes timestamp from the bytecode retrieval & bytecode manager and instead include it only in update_check along with a new lookup to public inputs to constrain it.
3. Removes deduplication of bytecode retrieval (see document)

Important question:

Is it acceptable that the GetContractInstance opcode performs two permutations to memory to accomplish its two writes? I wish I discussed this with others sooner, but I didn't think enough about it. If that's not acceptable, our other options are:

1. Extend this gadget to use 2 rows per invocation where the second row just writes the second result value
2. Return exists back to execution and let the execution trace handle the write from a register.

Followup work:

1. Handle magic addresses
2. Make sure we're actually deduplicating class id derivation, address derivation and bytecode hashing

[dbanks12]

• feat!: constrain NullifierExists AVM opcode #15636
• feat!: CLAUDE-GENERATED use class ID to deduplicate bytecode hashing and class ID derivation, use address for address derivation #15683
• feat!: constrain the GetContractInstance opcode in AVM #15430 👈 (View in Graphite)
• next

This stack of pull requests is managed by Graphite. Learn more about stacking.

[fcarreiro]

is the timestamp the same for the whole TX? if yes I'm surprised you need it in all the places; you might be able to avoid it in most lookups (just thinking out loud, haven't checked)

[dbanks12]

I moved it into only the update_check module and removed it from all of the interfaces. Update check now performs a lookup to the public inputs to retrieve timestamp. Removed it from TODOs in description!

[fcarreiro]

I'm a bit lost now. Where was the class id / derivation checked and is it being deduplicated?

Also: you mentioned in your doc that you'd make sure we are correctly deduplicating everything that we can (class id, bytecode hashing and decomposition etc). Can you confirm this is correct?

[dbanks12]

Class ID derivation is only necessary during bytecode retrieval. So it is done by the Bytecode Manager. Address derivation is done any time you need to retrieve a contract instance, so it is triggered by Contract Instance Manager. During contract instance retrieval, we just need to validate the instance, so we don't care where the class ID comes from, just that it can be used to derive the provided address.

I don't think we are de-duplicating any of those to be honest! I was not planning on addressing that in this PR. I dove deeper into this for a while today and here is where I'm at:

1. We can deduplicate bytecode hashing & class ID derivation by contract class ID as the unique identifier. I think this is easy in simulation and circuit.
2. We can deduplicate address derivation by address. This is also easy in simulation and circuit.
3. Update checking, nullifier checking, contract instance retrieval and bytecode retrieval will not be deduplicated.
4. Bytecode ID is no longer deduplicating... anything. So if things like bytecode decomposition and instruction fetching were relying on deduplication there, that won't work anymore.

I'm happy to work on this, but I'm not sure how substantial an effort it will be. So I'm tempted to say we should treat it as a separate piece of work.

[dbanks12]

Maybe it was actually easier than I thought. Take a look at this PR stacked on top. #15683

[sirasistant]

LGTM on my side