Can't call this contract from the constructor

[iAmMichaelConnor]

Issue found by @LHerskind.
When a contract is deployed, a constructor is executed. That constructor might wish to make calls to other functions of the contract: in particular to internal public functions. Or, the constructor might make calls to other functions, which then re-enter some other function of this.

The problem is, neither kernel circuit (neither public nor private) "knows about" this contract yet, because the contract's data doesn't get inserted into the contract tree until the base rollup circuit.

One suggested approach to resolving this would be:

In both kernel circuits, detect whether the tx is_contract_deployment, and extract the contract_deployment_data. The contract_deployment_data contains the function_tree_root (iirc). If some 'call' to this is made in a later kernel iteration (i.e. after the iteration which processes the constructor), the kernel circuit can prove existence of the call's (contract_address, function_selector, etc) in the function_tree_root. It can't prove existence of the function_tree_root in the contract_root (because it hasn't been inserted), but that's ok as long as the function_tree_root matches the one in the contract_deployment_data. With this approach, the kernel circuit processes any calls to this 'optimistically', with the assumption that they'll be inserted into the contract tree by the base rollup circuit later.

[iAmMichaelConnor]

Tagging @dbanks12 @suyash67 @jeanmon for thoughts.

[jeanmon]

Sounds like after transient/pending commitments, read requests, nullifiers, we need to support transient function calls :-)

If I am understanding correctly, we should not have any ordering issue here as there should be only one constructor call per transaction and this one is called first and therefore will be processed first by the private kernel circuit. Correct @iAmMichaelConnor ?

[iAmMichaelConnor]

That might be correct. Even if a constructor wasn't processed first (which might become the case in an 'account abstraction' world, where account contract entrypoints might need to be executed first), am I correct in thinking the constructor will always be processed by the kernel before any functions which are called by the constructor?

Related to this topic, there's been talk of removing the contract tree altogether (https://discourse.aztec.network/t/contract-classes-upgrades-and-default-accounts/433/14#get-rid-of-the-contract-tree-6). That might actually make this issue simpler to solve, but it's a complicated set of considerations.

[jeanmon]

@iAmMichaelConnor Yes, a parent or ancestor function is processed before a child/descendant in the private kernel. If you represent the function calls with a tree (an edge being a call), we process depth-first search but 'horizontally in a stack-based/reverse order'.

[rahul-kothari]

I believe this was fixed in #2549 @alexghr ?