> For the complete documentation index, see [llms.txt](https://maru-2.gitbook.io/maru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://maru-2.gitbook.io/maru/user-guide/maru-demo-faq/why-starky.md). # Why starky? * Easy to understand basic framework structure, every **STARK** is just a table, where each row represents a state and constraints represent state transitions. Actual implementation details are well-isolated and basic things could be written without any knowledge about underlying cryptographic concepts. * Integrated with **Plonky2**. Starky naturally produces large proofs, but these proofs can be easily compressed by Plonky2. Also some functions can be offloaded to an already existing Plonky gates. * **CTLs** are already implemented in recent versions. For more complicated proofs CTLs allow task-based proof decomposition. This decomposition leads to tremendously more homogenous data in each table, bringing constraint complexity down and improving proof generation efficiency. * Ease of decomposition allows wide code reuse. While customized solutions work really well, it’s always better to create scaffolding from already working parts and then customize them one-by-one. * Modularity also brings the ability to parallelize development. Team effort not only slashes development time, but enables code cross-review and simplify onboarding of new team members. * Streamlined development process. Starky imposes some limitations on project structure, but it also serves as a starting point with a defined set of actions to reach your goal. While not as flexible as Plonky2 itself, Starky handles most of the business-oriented projects well enough. Research projects may benefit from more flexibility, but Starky gets things done. #### Pure tech reasons The real power comes from the combination of starky and plonky2 - only using one of them leaves a lot of performance gains on the table: Most people know that the **FRI blowup factor** presents a tradeoff - a small blowup factor means a faster prover, slower verifier, and bigger proofs, while a big blowup factor means a slower prover, faster verifier, and smaller proofs. It’s also relatively well-known that the blowup factor increases in increments of powers of two (for FFT reasons), so increasing the blowup factor means making the prover around twice as slow. What people don’t know is that the maximum degree of any one constraint in your circuit is limited by the blowup factor. Specifically, it can be at most the blowup factor plus one. What this means is that the blowup factor provides another tradeoff - by increasing the blowup factor, you gain access to more complex “custom gates”, which often allows for smaller circuits. However, this comes at the cost of a \~2x slowdown in “raw” prover time, so it’s only worth it for circuits that can be made more than twice as small with higher-degree custom gates. In practice, this is not the case for most computations. Most of the time, if you want the fastest prover, you want to crank the blowup factor as far down as humanly possible - ideally all the way down to 2 (any less and FRI doesn’t work). However, this is the case for FRI recursion, which is dominated by **SNARK-friendly** hashing. Therefore, the prover with the fastest recursion is not the same as the prover with the fastest “raw” prover time Plonky2 uses a blowup factor of 8 so that it can utilize a custom gate to do an entire round of Poseidon in a single row of the circuit, and it builds atop **PLONK** because it provides the flexibility needed to pack those gates into the smallest area possible. This leads to a proof system that’s blazing fast at recursion, but slower at pretty much everything else. Starky, on the other hand, is a **STARK**, not a **PLONK**. That means it doesn’t need the overhead from copy constraints and permutation polynomials that **PLONK** does. By removing this overhead, starky can turn the blowup factor all the way down to 2 while still being able to write meaningfully-expressive **degree-3** constraints. This leads to the fastest “raw” proving time for the vast majority of statements, even though it’s slower than **plonky2** when it comes to recursion. The real magic happens when we combine them - since starky and **plonky2** are defined over the same field and hash functions, **plonky2** is incidentally quite good at verifying starky proofs - and since **plonky2** is also good at recursion, it’s good at merging starky proofs too. Therefore, by combining the two, we can have our cake and eat it too - we can prove our statements with starky, which is fastest at that, and then merge them together with plonky2, which is fastest at that. If we only use **plonky2**, we’re leaving a ton of performance gains on the table. Only by using it together with starky do we fully take advantage of the FRI blowup factor. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://maru-2.gitbook.io/maru/user-guide/maru-demo-faq/why-starky.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.