-
Notifications
You must be signed in to change notification settings - Fork 233
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: hash logs inside circuit (#5934)
## A follow-up to #5718: - [x] - Hash logs inside the circuit (closing #1165) Complete, with some caveats. In most cases, whatever log is being broadcast can be converted to bytes with one of the traits (in `log_traits`) and sha hashed. Note we now need these traits because `sha256_slice` has (understandably) been removed, so we must define a fixed length input for generic types. The one exception to this is broadcasting a contract class which ends up emitting up to 518,400 bytes. This is still hashed in ts via a new oracle method `emit_contract_class_unencrypted_log`. I believe it's fine to hash this outside of the circuit, because correctness will be guaranteed by the bytecode commitment (as opposed to a generic log, where we need the hash to come from the circuit to trust it). - [x] - Accumulate logs length inside the circuit Complete, perhaps we should track lengths of each log to more easily split them into revertible/non-revertible later on? - [x] - Flat hash the logs in `tail` + update documentation Now that `sha256_slice` is removed, we would have to flat hash all the empty space up to max logs - unsure whether this would give us any benefit? EDIT: After some testing, it is more efficient for larger numbers of logs (~9+) in both the circuit and L1, so I have implemented flat hashing. - [x] - Add a `logsCache`, like `noteCache`, to track logs + ordering in ts in nested executions Note that the `logsCache` is only implemented (and required) in the private context for now. Public calls don't require squashing and removal of logs representing nullified notes, so an array (`allUnencryptedLogs`) will do. It currently just keeps track of ordering when we have nested calls, but will be useful for removing transient logs (#1641). - [x] - Investigate + solve issue with `tx.ts` error not throwing I'm not sure why this check exists - the comment: ``` // This check is present because each private function invocation creates encrypted FunctionL2Logs object and // both public and private function invocations create unencrypted FunctionL2Logs object. Hence "num unencrypted" // >= "num encrypted". ``` implies that functions must emit both types of logs? A tx with one private call, which emits one encrypted log, should fail here, and I don't see why. EDIT: Have removed the check as it seems redundant. --- Note that in nested calls that have more than one side effect, logs will have duplicate side effect counters and so cannot be sorted correctly (#6052). Currently the logs collected in `allUnencryptedLogs` are the only place that have correctly ordered logs in this case.
- Loading branch information
1 parent
b39f1db
commit 6b99527
Showing
61 changed files
with
1,222 additions
and
608 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.