From 26c4026cbc9ccdba6569d99ec217a1f019e856fe Mon Sep 17 00:00:00 2001 From: Florian Kluge Date: Mon, 4 Dec 2023 15:25:10 +0100 Subject: [PATCH 1/6] the start --- 0011-chunking-o1js.md | 97 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 0011-chunking-o1js.md diff --git a/0011-chunking-o1js.md b/0011-chunking-o1js.md new file mode 100644 index 0000000..da16312 --- /dev/null +++ b/0011-chunking-o1js.md @@ -0,0 +1,97 @@ +# Chunking in o1js + +This RFC describes how we plan to integrate chunking, which has been described in detail in [RFC0002](./0002-chunking.md), into o1js and expose it to developers. + +## Summary + +One paragraph explanation of the feature. Describe the "why" and feature benefit. + +## Motivation + +Reflect the will of the PRD (product requirements document). If the PRD is a linkable artifact, include the link here. If not, summarize the product requirement in your own words. Describe the delta of this change. + +Be sure to include: + +- What are the hypotheses behind how this change meets the needs of a PRD? +- What is the expected outcome or outcomes and what are the exit conditions along the way? Include assessment criteria and ideally measurements that will either verify this hypothesis or yield opportunities to halt and abandon the implementation. +- What are we optimizing for in this particular solution? Reflect on alternatives in a later section. +- What use cases does it support? + +## Detailed design + +In general: + +- Be specific. This document is meant to share intent to your colleagues. Share what you believe you will actually do. +- Be decisive. No maybes. Any uncertainty can be captured in the unresolved questions section at the end. +- Provide design contex so that we can align on and commit to a technical design. + +Beyond the design of the change itself, also include details around: + +- Security implications +- Performance +- The impact of this change on other components or systems +- Dissect edge cases with examples + +**Evergreen, wide-sweeping Details** + +Evergreen details are hypothesized to be true for the lifetime of this component or system. They are also hard to pinpoint a location in a spec as they are too widesweeping. + +Evergreen details are included directly in the RFC in this section. + +**Ephemeral details** + +Ephemeral details must live in the spec so that they can evolve over time. + +In this section, link to one or more lines of code in committed GitHub code or one or more lines within a PR or PR draft. + +When in doubt, "the spec" can be a block comment in source code, but there are a few conventions for our existing systems: + +In proof systems-related projects: + +- The spec is inline comments that are generated by using [cargo-spec](https://github.com/mimoo/cargo-specification) + +For Mina Daemon: + +- Large areas are captured by a [separate specs area](https://github.com/MinaProtocol/mina/tree/develop/docs/specs) +- Default to inline comments. Prefer [cargo-spec](https://github.com/mimoo/cargo-specification) format, so we can extract them later. + +For SnarkyJS and other zkApps-related projects: + +- The spec is inline comments. Prefer [cargo-spec](https://github.com/mimoo/cargo-specification) format, so we can extract them later. + +## Test plan and functional requirements + +1. Testing goals and objectives: + - Specify the overall goals and objectives of testing for the proposed feature or project. This can help set the expectations for testing efforts once the implementation details are finalized. +2. Testing approach: + - Outline the general approach or strategy for testing that will be followed. This can include mentioning the types of testing to be performed (e.g., unit testing, integration testing, performance testing) and any specific methodologies or tools that will be utilized. +3. Testing scope: + - Define the scope of testing by identifying the key areas or functionalities that will be covered by testing efforts. +4. Testing requirements: + - Specify any specific testing requirements that need to be considered, such as compliance requirements, security testing, or specific user scenarios to be tested. +5. Testing resources: + - Identify the resources required for testing, such as testing environments, test data, or any additional tools or infrastructure needed for effective testing. + +## Drawbacks + +Why should we _not_ do this? + +## Rationale and alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +## Prior art + +Discuss prior art, both the good and the bad, in relation to this proposal. + +Prior art is any evidence that your feature (invention, change, proposal) is already known. + +Think about the lessons from other blockchain projects or similar updates and provide readers of your RFC with a fuller picture. If there is no prior art, that is fine. Your ideas are interesting whether they are new or adapted from another source. + +## Unresolved questions + +- What parts of the design do you expect to resolve through the RFC process before this RFC gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before merge? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? From 10b52df4ab60f8c0a87020eaf9d4bf3c30806549 Mon Sep 17 00:00:00 2001 From: Florian Kluge Date: Tue, 30 Jan 2024 12:11:51 +0100 Subject: [PATCH 2/6] continue --- 0011-chunking-o1js.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/0011-chunking-o1js.md b/0011-chunking-o1js.md index da16312..4712165 100644 --- a/0011-chunking-o1js.md +++ b/0011-chunking-o1js.md @@ -1,24 +1,27 @@ # Chunking in o1js -This RFC describes how we plan to integrate chunking, which has been described in detail in [RFC0002](./0002-chunking.md), into o1js and expose it to developers. +This RFC describes how we plan to integrate chunking in o1js, making it accessible to developers. The original chunking implementation has been described in detail in [RFC0002](./0002-chunking.md). ## Summary -One paragraph explanation of the feature. Describe the "why" and feature benefit. +Chunking in our proof system enhances its capacity, allowing it to handle circuits with a significantly higher number of constraints — the previous limit of 2^16 constraints is expanded to 2^32. This advancement empowers developers using o1js to create and prove more complex computations, paving the way for a broader spectrum of innovative applications and use cases. For instance, consider the process of hashing a single data blob using SHA256, which demands approximately 5000 constraints. Under the old constraint limit, a user could perform about 13 SHA256 hashes within a single circuit. The enhanced limit greatly reduces such restrictions, offering far more flexibility and potential in the types of computations that can be executed in a single operation. ## Motivation -Reflect the will of the PRD (product requirements document). If the PRD is a linkable artifact, include the link here. If not, summarize the product requirement in your own words. Describe the delta of this change. +The motivation, assessment criteria, and exit criteria can be found in the original [Chunking PRD](https://www.notion.so/o1labs/Chunked-Commitments-PRD-890c836529c545f082a3eeecd3d4f510). -Be sure to include: - -- What are the hypotheses behind how this change meets the needs of a PRD? -- What is the expected outcome or outcomes and what are the exit conditions along the way? Include assessment criteria and ideally measurements that will either verify this hypothesis or yield opportunities to halt and abandon the implementation. -- What are we optimizing for in this particular solution? Reflect on alternatives in a later section. -- What use cases does it support? +This RFC describes the process of exposing and implementing chunking in o1js, making it available to o1js developers. Chunking itself has already been implemented in Kimchi and Pickles, the remaining work only requires exposing the new functionality to o1js via the bindings layer. ## Detailed design +Currently, the circuit writing API in o1js is exposed via the `SmartContract` and `ZkProgram` API. Under the hood, we use the OCaml bindings (js_of_ocaml) as an [interface to Pickles](https://github.com/o1-labs/o1js-bindings/blob/43fa328c4ef4a225e1343a7f26fc3d85adf67b21/ocaml/lib/pickles_bindings.ml#L577-L624). + +In the TypeScript layer, [compiling circuits](https://github.com/o1-labs/o1js/blob/16e66f9fba51ac4832691c3fc7a52bae60a08fd7/src/lib/proof_system.ts#L683-L688) calls into the bindings layer via `Pickles.compile`, passing in the individual branches (rules or methods) of the smart contract or ZkProgram and returning prover artifacts. + +In order to make chunking work in o1js, we have to modify the `Pickles.compile` to accept the number of chunks that are required in order to construct the proof. The Pickles [test](https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/test/chunked_circuits/test_chunked_circuits.ml) serves as an example on how to modify the `Pickles.compile` function to prove larger circuits and specify the amount of chunks. + +--- + In general: - Be specific. This document is meant to share intent to your colleagues. Share what you believe you will actually do. From 3ff5d7c9111743eb3703f1e2d0c401ad77fffa31 Mon Sep 17 00:00:00 2001 From: Florian Kluge Date: Tue, 30 Jan 2024 16:04:45 +0100 Subject: [PATCH 3/6] continue --- 0011-chunking-o1js.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/0011-chunking-o1js.md b/0011-chunking-o1js.md index 4712165..d12129a 100644 --- a/0011-chunking-o1js.md +++ b/0011-chunking-o1js.md @@ -20,6 +20,8 @@ In the TypeScript layer, [compiling circuits](https://github.com/o1-labs/o1js/bl In order to make chunking work in o1js, we have to modify the `Pickles.compile` to accept the number of chunks that are required in order to construct the proof. The Pickles [test](https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/test/chunked_circuits/test_chunked_circuits.ml) serves as an example on how to modify the `Pickles.compile` function to prove larger circuits and specify the amount of chunks. +Calculating how many chunks are needed to prove a circuit depends on the amount of constraints used in circuit. Before passing the parameter to the function and compiling the circuit, we have to calculate the amount of chunks needed. Luckily, o1js already has a function that can inspect methods and count the amount of constraints, we get this information by calling `.analyzeMethods()` on the `ZkProgram` or `SmartContract`. + --- In general: From edfc5d3e430e3809938959d27d0ad9a48cb41b95 Mon Sep 17 00:00:00 2001 From: Florian Kluge Date: Wed, 31 Jan 2024 12:16:52 +0100 Subject: [PATCH 4/6] remaining sections --- 0011-chunking-o1js.md | 94 ++++++++++++++++++++----------------------- 1 file changed, 44 insertions(+), 50 deletions(-) diff --git a/0011-chunking-o1js.md b/0011-chunking-o1js.md index d12129a..0229651 100644 --- a/0011-chunking-o1js.md +++ b/0011-chunking-o1js.md @@ -20,83 +20,77 @@ In the TypeScript layer, [compiling circuits](https://github.com/o1-labs/o1js/bl In order to make chunking work in o1js, we have to modify the `Pickles.compile` to accept the number of chunks that are required in order to construct the proof. The Pickles [test](https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/test/chunked_circuits/test_chunked_circuits.ml) serves as an example on how to modify the `Pickles.compile` function to prove larger circuits and specify the amount of chunks. -Calculating how many chunks are needed to prove a circuit depends on the amount of constraints used in circuit. Before passing the parameter to the function and compiling the circuit, we have to calculate the amount of chunks needed. Luckily, o1js already has a function that can inspect methods and count the amount of constraints, we get this information by calling `.analyzeMethods()` on the `ZkProgram` or `SmartContract`. +Calculating how many chunks are needed to prove a circuit depends on the amount of constraints used in a circuit. Before passing the parameter to the function and compiling the circuit, we have to calculate the amount of chunks needed. Luckily, o1js already has a function that can inspect methods and count the amount of constraints, we get this information by calling `.analyzeMethods()` on the `ZkProgram` or `SmartContract`. ---- +### Technical Implementation -In general: +The implementation should not require and API changes for the developer, all changes happen internally and hidden from the public facing API. A naive overview of the changes: -- Be specific. This document is meant to share intent to your colleagues. Share what you believe you will actually do. -- Be decisive. No maybes. Any uncertainty can be captured in the unresolved questions section at the end. -- Provide design contex so that we can align on and commit to a technical design. +1. Adjusting OCaml bindings to Pickles - [pickles_bindings.ml](https://github.com/o1-labs/o1js-bindings/blob/1db0524c5c7c93f0df9db3fb3bdfa0414bdaf90b/ocaml/lib/pickles_bindings.ml#L563) -Beyond the design of the change itself, also include details around: + - Modifying the `pickles_compile` function to accept an additional parameter `num_chunks`, which will then be passed into `Pickles.compile_promise`. `num_chunks` will be calculates in o1js directly. -- Security implications -- Performance -- The impact of this change on other components or systems -- Dissect edge cases with examples +2. Adapting the compile function in [proof_system.ts](https://github.com/o1-labs/o1js/blob/0d82ad1d67417c72b06fc8456a0a2b54bcc46652/src/lib/proof_system.ts) -**Evergreen, wide-sweeping Details** + - `compileProgram` function should accept a new argument `numChunks` which represents the amount of chunks needed to compile the circuit + - `numChunks` inside of `compileProgram` will then be passed into `Pickles.compile` via the bindings layer -Evergreen details are hypothesized to be true for the lifetime of this component or system. They are also hard to pinpoint a location in a spec as they are too widesweeping. +3. Before calling into `compileProgram`, the number of chunks must be calculated. This can be done by utilizing the `analyzeMethods` function which exists on both `SmartContract` and `ZkProgram`. + - For `ZkProgram`, this change can be done in `proof_systems.ts` and the `ZkProgram` function + - For `SmartContract`, the change is needed in [zkapp.ts](https://github.com/o1-labs/o1js/blob/0d82ad1d67417c72b06fc8456a0a2b54bcc46652/src/lib/zkapp.ts) - in the `SmartContract.compile` method. -Evergreen details are included directly in the RFC in this section. +- ## Changing the type definitions of the bindings to represent the change in the `pickles_compile` function -**Ephemeral details** +## Test plan and functional requirements -Ephemeral details must live in the spec so that they can evolve over time. +1. Testing Goals and Objectives: -In this section, link to one or more lines of code in committed GitHub code or one or more lines within a PR or PR draft. +- o1js can compile and prove circuits that are bigger than 2^16 constraints, up to ideally 2^32 (the new limit introduced by chunking) +- A proof using a larger circuit limit can be deployed to and verified on a testnet +- Circuits that exceed the old limit of 2^16 constraints can be recursively verified in each other -When in doubt, "the spec" can be a block comment in source code, but there are a few conventions for our existing systems: +2. Testing Approach: -In proof systems-related projects: +- multiple tests in o1js that test the new limits of the circuits. Tests in Kimchi and Pickles already exists, they can be used as [examples](https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/test/chunked_circuits/test_chunked_circuits.ml) -- The spec is inline comments that are generated by using [cargo-spec](https://github.com/mimoo/cargo-specification) +3. Testing Scope: -For Mina Daemon: +- Proofs can be constructed and verified locally as well as deployed to a testnet. -- Large areas are captured by a [separate specs area](https://github.com/MinaProtocol/mina/tree/develop/docs/specs) -- Default to inline comments. Prefer [cargo-spec](https://github.com/mimoo/cargo-specification) format, so we can extract them later. +## Drawbacks -For SnarkyJS and other zkApps-related projects: +Proving larger circuits will increase proving time and memory consumption. Given the memory limit in most browsers and WASM, this could cause problems for users trying to prove large circuits in a browser. -- The spec is inline comments. Prefer [cargo-spec](https://github.com/mimoo/cargo-specification) format, so we can extract them later. +## Rationale and alternatives -## Test plan and functional requirements +Not exposing Chunking and continuing to rely on recursion for large computations. This adds a significant overhead for developers and adds complexity of applications. -1. Testing goals and objectives: - - Specify the overall goals and objectives of testing for the proposed feature or project. This can help set the expectations for testing efforts once the implementation details are finalized. -2. Testing approach: - - Outline the general approach or strategy for testing that will be followed. This can include mentioning the types of testing to be performed (e.g., unit testing, integration testing, performance testing) and any specific methodologies or tools that will be utilized. -3. Testing scope: - - Define the scope of testing by identifying the key areas or functionalities that will be covered by testing efforts. -4. Testing requirements: - - Specify any specific testing requirements that need to be considered, such as compliance requirements, security testing, or specific user scenarios to be tested. -5. Testing resources: - - Identify the resources required for testing, such as testing environments, test data, or any additional tools or infrastructure needed for effective testing. +## Prior art -## Drawbacks +Chunking working in [OCaml and Pickles](https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/test/chunked_circuits/test_chunked_circuits.ml) directly. -Why should we _not_ do this? +## Unresolved questions -## Rationale and alternatives +While trying to prototype Chunking in o1js, I came up with the following unresolved questions. The tests can be found in [this](https://github.com/MinaProtocol/mina/tree/chunking_rfc_unresolved) branch. -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +1 Changing the loop that constructs the circuit from `2^17` (roughly `2^16` constraints) iterations to `2^18` iterations (or `2^17` constraints) and also adjusting `num_chunks: 4` and `override_wrap_domain:N1` compiles the program correctly, generates a proof _but_ doesn't verify the proof: -## Prior art +```sh +Uncaught exception: -Discuss prior art, both the good and the bad, in relation to this proposal. + (Pickles.verify dlog_check) -Prior art is any evidence that your feature (invention, change, proposal) is already known. +Raised at Base__Error.raise in file "src/error.ml" (inlined), line 8, characters 14-30 +Called from Base__Or_error.ok_exn in file "src/or_error.ml", line 84, characters 17-32 +Called from Dune__exe__Invalid_proof in file "src/lib/pickles/test/chunked_circuits/invalid_proof.ml", line 92, characters 2-9 +``` -Think about the lessons from other blockchain projects or similar updates and provide readers of your RFC with a fuller picture. If there is no prior art, that is fine. Your ideas are interesting whether they are new or adapted from another source. +This can be reproduced by running `dune exec ./invalid_proof.exe` inside of the test folder `src/lib/pickles/test/chunked_circuits`. -## Unresolved questions +Is this behaviors expected? If so, why and how can we prevent the construction of invalid circuits and proofs in o1js? Changing `num_chunks` and `override_wrap_domain` results in an (expected) compilation error - so the chosen values seem to be logical and correct. + +On the other hand, setting `num_chunks:8` and the loop iteration to `2^19` compiles the circuit and yields a valid proof. (see `valid_proof.ml`) + +2 What is the maximum allowed number chunks? From my understanding, setting iteration to `2^20` and `num_chunks:16` requires that the wrap domain must be `N3`, but it only accepts `N0 | N1 | N2`. Setting the wrap domain to anything `<= N2` yields an error. How do we deal with large number chunks and constraints? See `large_wrap_domain.ml` for this case. -- What parts of the design do you expect to resolve through the RFC process before this RFC gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before merge? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? +3 Running a small MVP of Chunking in o1js through the bindings yields the following error: `there are not enough random rows to achieve zero-knowledge (expected: 3, got: 2)`. It seems like some values aren't passed correctly. This also needs to be resolved during implementation. From 2173cec05f6aab9ec8ced2e3aa01b3a513c8efce Mon Sep 17 00:00:00 2001 From: Florian Kluge Date: Wed, 31 Jan 2024 12:37:33 +0100 Subject: [PATCH 5/6] minor --- 0011-chunking-o1js.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/0011-chunking-o1js.md b/0011-chunking-o1js.md index 0229651..478a1ef 100644 --- a/0011-chunking-o1js.md +++ b/0011-chunking-o1js.md @@ -59,7 +59,7 @@ The implementation should not require and API changes for the developer, all cha ## Drawbacks -Proving larger circuits will increase proving time and memory consumption. Given the memory limit in most browsers and WASM, this could cause problems for users trying to prove large circuits in a browser. +Proving larger circuits will increase proving time and memory consumption. Given the memory limit in most browsers and WASM, this could cause problems for users trying to prove very large circuits. ## Rationale and alternatives @@ -71,7 +71,7 @@ Chunking working in [OCaml and Pickles](https://github.com/MinaProtocol/mina/blo ## Unresolved questions -While trying to prototype Chunking in o1js, I came up with the following unresolved questions. The tests can be found in [this](https://github.com/MinaProtocol/mina/tree/chunking_rfc_unresolved) branch. +While trying to prototype Chunking in o1js, I came up with the following unresolved questions. The tests can be found in [this](https://github.com/MinaProtocol/mina/tree/chunking_rfc_unresolved/src/lib/pickles/test/chunked_circuits) branch. 1 Changing the loop that constructs the circuit from `2^17` (roughly `2^16` constraints) iterations to `2^18` iterations (or `2^17` constraints) and also adjusting `num_chunks: 4` and `override_wrap_domain:N1` compiles the program correctly, generates a proof _but_ doesn't verify the proof: @@ -89,8 +89,9 @@ This can be reproduced by running `dune exec ./invalid_proof.exe` inside of the Is this behaviors expected? If so, why and how can we prevent the construction of invalid circuits and proofs in o1js? Changing `num_chunks` and `override_wrap_domain` results in an (expected) compilation error - so the chosen values seem to be logical and correct. -On the other hand, setting `num_chunks:8` and the loop iteration to `2^19` compiles the circuit and yields a valid proof. (see `valid_proof.ml`) +On the other hand, setting `num_chunks:8`,`override_wrap_domain:N2` and the loop iteration to `2^19` compiles the circuit and yields a valid proof. (see `valid_proof.ml`) -2 What is the maximum allowed number chunks? From my understanding, setting iteration to `2^20` and `num_chunks:16` requires that the wrap domain must be `N3`, but it only accepts `N0 | N1 | N2`. Setting the wrap domain to anything `<= N2` yields an error. How do we deal with large number chunks and constraints? See `large_wrap_domain.ml` for this case. +2 What is the maximum allowed number chunks? From my understanding, setting iteration to `2^20` and `num_chunks:16` requires that the wrap domain must be `16`, but it only accepts `N0 | N1 | N2`. Setting the wrap domain to anything `<= N2` yields an error. How do we deal with large number chunks and constraints? `override_wrap_domain` is of type `Pickles_base.Proofs_verified.t` which only accepts `N0 | N1 | N2`. +See `large_wrap_domain.ml` for this case. `This circuit was compiled for proofs using the wrap domain of size 15, but the actual wrap domain size for the circuit has size 16` 3 Running a small MVP of Chunking in o1js through the bindings yields the following error: `there are not enough random rows to achieve zero-knowledge (expected: 3, got: 2)`. It seems like some values aren't passed correctly. This also needs to be resolved during implementation. From ad8e246da191fa23b49f9e742365f2dd8dde60be Mon Sep 17 00:00:00 2001 From: Florian Date: Wed, 31 Jan 2024 14:26:44 +0100 Subject: [PATCH 6/6] feedback --- 0011-chunking-o1js.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/0011-chunking-o1js.md b/0011-chunking-o1js.md index 478a1ef..3862112 100644 --- a/0011-chunking-o1js.md +++ b/0011-chunking-o1js.md @@ -24,7 +24,7 @@ Calculating how many chunks are needed to prove a circuit depends on the amount ### Technical Implementation -The implementation should not require and API changes for the developer, all changes happen internally and hidden from the public facing API. A naive overview of the changes: +The implementation should not require any API changes for the developer, all changes happen internally and are hidden from the public-facing API. A naive overview of the changes: 1. Adjusting OCaml bindings to Pickles - [pickles_bindings.ml](https://github.com/o1-labs/o1js-bindings/blob/1db0524c5c7c93f0df9db3fb3bdfa0414bdaf90b/ocaml/lib/pickles_bindings.ml#L563) @@ -39,17 +39,15 @@ The implementation should not require and API changes for the developer, all cha - For `ZkProgram`, this change can be done in `proof_systems.ts` and the `ZkProgram` function - For `SmartContract`, the change is needed in [zkapp.ts](https://github.com/o1-labs/o1js/blob/0d82ad1d67417c72b06fc8456a0a2b54bcc46652/src/lib/zkapp.ts) - in the `SmartContract.compile` method. -- ## Changing the type definitions of the bindings to represent the change in the `pickles_compile` function - ## Test plan and functional requirements 1. Testing Goals and Objectives: - o1js can compile and prove circuits that are bigger than 2^16 constraints, up to ideally 2^32 (the new limit introduced by chunking) -- A proof using a larger circuit limit can be deployed to and verified on a testnet +- A proof using a larger circuit limit (between 2^16 and 2^32 constraints) can be deployed to and verified on a testnet - Circuits that exceed the old limit of 2^16 constraints can be recursively verified in each other -2. Testing Approach: +1. Testing Approach: - multiple tests in o1js that test the new limits of the circuits. Tests in Kimchi and Pickles already exists, they can be used as [examples](https://github.com/MinaProtocol/mina/blob/develop/src/lib/pickles/test/chunked_circuits/test_chunked_circuits.ml)