Remove historic private data root from app circuit public inputs - add to PrivateCallData

[dbanks12]

No description provided.

[dbanks12]

Do we actually want to do this? How will inputs change when we have full historic trees to check? Maybe we leave this in but separately add this to PrivateCallData.

[jeanmon]

In between, some refactoring tasks changed the setting. Currently, the various data roots (nullifierTreeRoot, privateDataTreeRoot, etc, ..) lie in a data structure named HistoricBlockData.
HistoricBlockData is used in private AND public world, for instance, is a member of:

• PublicCircuitPublicInputs
• PrivateCircuitPublicInputs
• PublicProcessor

Removing privateDataTreeRoot from HistoricBlockData does not seem a viable option as public world related data certainly needs this information.

Creating a separate data structure e.g., PrivateHistoricBlockData which would be HistoricBlockData removed from privateDataTreeRoot seems a bit of an overkill unless there is strong reason.

@dbanks12 What do you think?
@Maddiaa0 I saw you implemented related factoring tasks. Is my analysis correct and do you have any opinion on this?

[Maddiaa0]

All of the information is available in public and private mainly so the block hash can be reconstructed and checked in the base rollup circuit ( so that all of the tree roots are from the same block )

I dont have a particularly strong opinion around changes, however im not entirely sure why it should move into calldata, do we not want to allow all users to be able to make claims about the historic state?

[dbanks12]

I think I agree that it doesn't make sense to move this. I created this ticket before we really had any other historic info.

I suspect that we are never setting this historic root from Noir. I think we need to be setting it whenever we are outputting read requests. Does this sound right @Maddiaa0?

Here are the next steps discussed in scrum:

1. Try removing kernelProver code that overrides historic root (probably will lead to failure)
2. Look for other locations in Noir where historic roots are set and possibly mimic here
3. Maybe set historic privateDataRoot when read-requests are created in Noir
4. Confirm whether the historic roots actually checked somewhere in C++ circuits (probably base rollup). If not, create ticket to do so.

[jeanmon]

@dbanks12
Result from 1. the CI is fully green:

https://app.circleci.com/pipelines/github/AztecProtocol/aztec-packages/13029/workflows/87d643fa-caaa-4d0f-bf7b-68a1a4262ba7

[jeanmon]

My understanding is that TS script code is setting these tree roots as part of the acir simulator and pass then them to noir code.

Relevant code:

aztec-packages/yarn-project/acir-simulator/src/client/simulator.ts

Line 80 in 280722a

const historicBlockData = await this.db.getHistoricBlockData();

aztec-packages/yarn-project/acir-simulator/src/client/simulator.ts

Line 90 in 280722a

const context = new ClientExecutionContext(

Passing to noir code:

aztec-packages/yarn-project/aztec-nr/aztec/src/context.nr

Line 280 in 280722a

private_data_tree_root : fields[113],

@Maddiaa0 Is my analysis correct? (l am not sure about the noir code part.)

@dbanks12 I think that the above TS line sets all the historic roots (which would answer 2.)

[jeanmon]

Answer to 4., all members are used in kernel or rollup code, except the 2 following members:

• blocks_tree_root
• private_kernel_vk_tree_root

The latter is certainly not used because we still work with native code. What about the former? @Maddiaa0 @dbanks12