Add side effect counter to logs #5017
Assignees
Comments
Closed
Closed
MirandaWood
added a commit
that referenced
this issue
Apr 17, 2024
Closes #5017 This PR adds side effect counters to logs, tracks them throughout the kernels, sorts them (only in private kernel tail, public kernel tail is todo), and hashes them to one value in the tail. ## Private path Encrypted and unencrypted logs flow via a private call: - A private fn calling `emit_(un)encrypted_log` now actually pushes the hash of the log to the `PrivateContext` as a `SideEffect` - These logs hashes are maintained through `PrivateCircuitPublicInputs` - They are collected in `init` and `inner` kernels - Like note hashes, we now provide index hints in the `tail` and sort the logs hashes - In the final step of `tail`, we either run `to_public`, keeping individual logs hashes, or `finish_tail` (converting `.end` to `CombinedAccumulatedData`), where logs are hashed to a single value - As before, the single value is rolled up and recalculated in L1 ## Public path Unencrypted logs flow via a public call: - A private fn calling `emit_unencrypted_log` now actually pushes the hash of the log to the `PublicContext` as a `SideEffect` - These logs hashes are maintained through `PublicCircuitPublicInputs` - They are collected in `init` and `inner` kernels - Like note hashes, we currently don't sort in the public tail (I've added a ts hack like the note hash one) - In the final step of `tail`, we hash logs to a single value - As before, the single value is rolled up and recalculated in L1 ## TODOs - Since individual logs are not hashed by the circuits (this is part of #1165 which should be done once #1641 is finished), instead a hash is passed via the oracles, the context circuits can't calculate the length of each log. So the length is still passed in. - In the kernels, logs currently sit as `SideEffects` but should be some special counted logs struct. It makes sense to me to first separate logs which are linked to note preimages (no issue, but part of kernel epic), then assign each type of logs its own struct. - I added some hacks/qs (see comments below). --------- Co-authored-by: Leila Wang <leizciw@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current thinking is to drop the ability to have an arbitrary number of logs per tx and instead specify a limit on the number of non/revertible un/enc logs per tx, following the same methodology as note hashes and nullifiers.
The text was updated successfully, but these errors were encountered: