Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: squash transient note logs (AztecProtocol#6268)
Closes AztecProtocol#1641 ## This PR: ### Logs as `SideEffect`s -> `LogHash` or `NoteLogHash` Adds new structs to track logs in the kernel circuits, so we can track individual log lengths (and assign gas accordingly) and separate logs linked to notes from generic logs. The length changes contribute to AztecProtocol#4712 but this PR does not close it - we need some more work in ts to ensure logs from the non-revertible side actually persist to the tx. ### Adds `note_encrypted_logs` To aid the kernels/pxe/note dbs in managing note encrypted logs, most of the changed files are adding a new array of note logs to anything already containing `.encrypted_logs_<hashes/hash>`. Since all our current contracts/tests only emit encrypted logs for notes, the values expected in `.encrypted_logs` have basically moved over to `.note_encrypted_logs`. A later PR will add code for generic encrypted logs (see below). Includes adding logs to the note cache in `client_execution_context` and removing `LogsCache`, as the note cache handles note specific logs. ### Squashes transient note logs Removes any logs linked to note hashes nullified in the same tx. This involves adding note logs to transient hints for the private kernel tail and chopping them inside the circuit. ### TODOs/Notes - This PR ended up pretty large, so while we can silo log hashes now, it would be cleaner to do in a follow up PR. - There are some small changes to public/AVM contexts which are mostly to replace `SideEffect` with `LogHash` and a couple of things addressed in comments below. - Currently, the only encrypted logs that are emitted are linked to notes. To allow for generic values emitted as encrypted logs, I'll need to add a new oracle call and methods, which makes sense to do once we encrypt inside the circuit (AztecProtocol#1139). - Total logs length (e.g. `encrypted_log_preimages_length` is no longer required now we track indvidual lengths (it's also not trusted since it comes from contexts), so it can be removed from the kernels. - We originally tried to track log lengths the same way as `ts`, which adds 4 bytes to each nested 'group' of logs: `L2BlockL2Logs.txLogs = TxL2Logs -> .functionLogs = FunctionL2Logs -> .logs = <Un>EncryptedL2Log[]` but this never actually matched up because we accumulate and sort logs regardless of what call they came from. E.g. 3 groups of `FunctionL2Logs` would each have +4 length when added to a tx, but we take the contents, sort them, then add to a single `FunctionL2Logs.logs` array before assigning to a tx, so end up with a single +4 length. This length value is only used on L1 to destructure the blob of bytes representing logs. Any incorrect lengths would lead to a logs hash mismatch, so we don't need to match them in the circuit anyway. For this reason, I've removed a few unnecessary +4s from the circuits.
- Loading branch information
1 parent
74e98d4
commit 4574877