Joining Forces: SHARP
Save Costs and Enhance Ethereum’s Scalability: If it’s Written in Cairo, SHARP Can Prove it
TL;DR
- SHARP (SHARed Prover) generates STARK proofs of aggregated Cairo programs, allowing any app to submit transactions to the same proof. Think UberPool but for STARK Proofs. This ‘ride-sharing’ dynamic means even small apps can access the massive power of STARK scaling.
- If it’s written in Cairo, SHARP can prove it, however diverse the dApps are. Processing SHARP bundles approximately 220K transactions into a single proof on Ethereum Mainnet.
- Recursive proving with SHARP enables parallel processing and verification of multiple STARK proofs, enhancing scalability and efficiency.
- A further reduction in gas fees of up to 30% will be delivered by the upcoming Dynamic Layouts customization for SHARP.
The Scaling Journey
Scaling Ethereum is a journey. It requires ongoing innovation in order to find the next solution that will further raise scaling capabilities. In June 2020, StarkWare launched StarkEx, the first STARK-based L2 scaling solution. In September 2020 it announced Cairo, the first programming language designed to gain maximum efficiency with STARK proofs. Cairo, and the general computation it allows, paved the way for swift and secure coding of proofs for any business logic and arbitrary computational statements. With this innovation came a new wave of developers into the StarkWare ecosystem.
But while these developers wanted the scalability, security, and efficiency of StarkEx, many of their projects didn’t have enough transaction activity to fill up a STARK proof. Similarly, users were still hampered by the unpredictability of rising gas fees triggered by Ethereum network congestion.
And then came SHARP.
What is SHARP?
SHARP (a SHARed Prover) is a powerful system designed to generate STARK proofs for aggregated Cairo programs. Cairo, being a general computation programming language, allows for the accommodation of various code logics in one single proof. SHARP processes batches of transactions off-chain, and validates the proof for their computation on-chain, amortizing the cost of all transactions across a single proof. The generated unified STARK proof is validated through an on-chain Solidity verifier contract, enabling SHARP to enhance throughput, reduce gas fees, and minimize latency.
For example, SHARP can process any Cairo code from entirely different programs and logic, all the way to NFT minting and even Starknet network OS. If it’s in Cairo, SHARP can prove it, and it can aggregate a variety of programs under one proof. The efficiency that SHARP brings results in the capability of bundling thousands of transactions into a single proof on Mainnet. The costs of processing the proof on-chain are split between all transactions in the batch, so the more transactions bundled, the lower the gas fees each transaction will cost.
Let’s use an example to illustrate this idea:
Imagine that you and your sister are purchasing gifts for your parents — a new phone, a mug, and a tee shirt. Each gift is ordered from a different online retailer and will be delivered to your respective homes on different dates, varying in size and packaging. Your plan is to gift wrap each item and ship them to your parents via mail.
However, there’s a predicament at the post office. Small and medium-sized boxes are unavailable, leaving only large, one-size-fits-all boxes. This presents two options:
Option 1: Pack and ship each item separately in its own large box as soon as it arrives. While this may expedite the shipment of individual gifts, it requires the additional effort of packing three separate boxes and making three trips to the post office to send three separate packages. As a result, this method proves to be neither time-efficient nor cost-effective.
Option 2: Pack and ship all items together in a single large box. This means you only handle one box, instead of three.
In this example, SHARP is Option 2, allowing for the efficient use of resources and more streamlined time management.
SHARP
While SHARP was birthed for the StarkWare Ecosystem, it is capable of proving any Cairo program with a valid execution. Its efficiency in saving time and costs makes SHARP a solution for whatever requires an innovative proving method.
Recursive SHARP
Since its inception, SHARP has undergone a handful of efficiency upgrades. One of the most powerful has been the shift from a linear to a recursive model.
With recursive proving, SHARP proves each statement upon its arrival, instead of first collecting a bundle of statements to fill up a proof, and only then starting the process for the whole bundle of statements. This is a time-efficient way to verify computational statements, much quicker than the calculation itself.
This is achieved by the parallel processing of incoming statements, allowing to bypass previous scalability barriers which required the combined statement to be proved only once all individual statements have been received. Now, not only can SHARP prove the correctness of thousands of transactions but also verify multiple STARK proofs using the corresponding STARK verifiers. This allows the generation of a single proof that attests to the validity of multiple upstream proofs.
With recursion implemented, SHARP proves incoming statements immediately. From there, these proofs themselves can be repeatedly proved and merged into recursive proofs. This recursive proving process is implemented until, eventually, the final proof is submitted to an on-chain Solidity verifier contract. It’s like a nesting pattern: A Cairo program verifies the upstream proofs, which in turn produces a new proof, with a STARK verifier confirming their validity.
Whereas the post office in our analogy initially offered only one standard box size, recursive SHARP has introduced a breakthrough with smaller boxes of different sizes, each specifically designated for an individual item. Although these boxes are not precisely tailored to the size of each specific item, this innovative approach enables the packing of gifts in smaller boxes as they arrive, eliminating unnecessary expenses of unused space and reducing delays. Instead of waiting for all three gifts to be received before packing them into one large box, the smaller boxes allow for immediate packing and preparation for shipping once all gifts are ready.
What’s Next: Dynamic Layouts
Our team is currently developing Dynamic Layouts as the next customization of SHARP services. With Dynamic Layouts, the prover will calculate the required resources for each specific logic and generate a tailored proof accordingly.
Drawing a parallel to our post office analogy once more, Dynamic Layouts can be likened to the idea of custom shipping boxes. These custom boxes perfectly accommodate the shape of each present, ensuring you only pay for the exact size required, avoiding unnecessary fees. Similarly, with Dynamic Layouts, we will create a tailored proof for each logic and the unique computation resources it requires, ensuring you only pay for the computation you use. If it’s in Cairo, SHARP can prove it accurately.
Our team hopes to introduce this improvement in both adaptability and efficiency, by the next SHARP version. Dynamic Layouts will aim to massively reduce gas fees.
By leveraging the power of STARK-based recursive proof generation, this technology is greatly improving the scalability and efficiency of the Ethereum network.
You can read more about StarkEx and Starknet in the following links: StarkEx, Starknet