"We Like the Stark"
"We Like the Stark"
A Deepdive into Everything StarkWare
2022 was quite a year. At PHD Capital, we’re looking ahead at some of the largest trends and market narratives that have the greatest chance at making a lasting impact on crypto. In our previous post, we discussed a broad overview of the Ethereum L2 and L3 landscape. It’s time to get a little more granular. Buckle up, we’re doing a deep dive into everything StarkWare, StarkNet, StarkGate, StarkMesh, and StarkEx. That’s a lot of Stark terms. At least one of those was made up.
StarkEx: First to the scene
Even though StarkWare’s software-as-a-service platform StarkEx launched in 2020, it arguably was their 2021 launch that pioneered ZK-Rollup (ZKR) technology for the foreseeable future. StarkNet is their flagship Ethereum L2, and its general-purpose nature enables the aforementioned blossoming “fractal scaling” L3 network on top. What does that look like?
Cross-app coordination and composability (stacking protocols like Lego blocks).
Cheap and easy deposits and withdrawals from L2 to L3s without having to touch the L1.
Customizable app-specific rollups, much like the Cosmos use-case, without sacrificing a strong shared settlement layer.
While StarkEx was the team’s first iteration with ZK technology, it was not made for composability-first use-cases. That said, it’s safe to say that StarkEx has found product-market-fit and still holds an important place in the broader scaling ecosystem. As of Q1 2023, the SaaS-like solution has facilitated nearly $800B in trading volume with nearly $500M in TVL. To date, four well-known protocols that used StarkEx’s scaling solution have included dYdX, Immutable X, Sorare, and DiversiFi.
StarkEx achieves scalability through a split architecture: an off-chain Prover and an on-chain Verifier. This hybrid approach allows large batches of transactions to get bundled off-chain into a STARK proof, massively cutting down on aggregate costs. The on-chain verification takes just a few steps with low computational overhead.
You might have heard of validity proofs and fraud proofs in various threads and articles before your eyes glossed over. To put it simply: StarkEx uses validity proofs (versus Optimistic Rollups’ fraud proofs) to ensure that valid data is committed on-chain.
Here’s a simple explainer between the difference:
Fraud Proof: I (smart contract) will accept whatever data anyone sends as true, but if you send me a proof showing that something I accepted was false, I’ll go back and fix it.
Validity Proof: before I (smart contract) accept the incoming data, it must prove that it is valid
So yes, there are inherent benefits in using validity proofs, but a drawback is that proofs are needed with every transition in the blockchain’s state, instead of only when someone challenges the new state (impacting scalability).
StarkWare also enables different data availability (DA) structures based on the needs of the app developers. A quick refresher on the Data Availability Dilemma:
Data availability is the practice of storing data off of the operating system or network (in this case, the Ethereum blockchain) and only presenting the needed data at the needed time.
Apps that want on-chain DA can opt for the ZKR solution, while others might choose the hybrid off-chain (Validium) solution. Third, StarkWare proposed an “Adamantium” structure: an off-chain DA solution where users manage their own DA. This is more costly than letting StarkWare’s data availability committee (DAC) handle things, but it is better suited for “power users” that may need high security of their funds. For developers that want to begin playing with all of these different structures for their applications, StarkEx’s playground is immediately available and open access. For developers that already have back-ends running for their apps and logic set in place, the team provides a REST API for a relatively quick integration/launch.
For decentralization’s sake, it’s worth being aware of what components are handled by the StarkWare team. These mostly include aspects relating to generating proofs and handling the on-chain components like the Verifier contract, functions like on-chain deposits and withdrawals and Escape Hatch withdrawals, and potential blockchain re-organization mechanisms. For developers that choose the Validium structure (which relies on the DAC), this committee by default includes ConsenSys, Infura, Nethermind, Cephalopod, Iqlusion, and StarkWare itself.
The SaaS operation flow is as follows:
An Operator (e.g. an exchange) batches user transactions off-chain and sends them to StarkEx
StarkEx validates the transaction and updates account balances
StarkEx generates a STARK proof and sends the validity proof to Ethereum, where a Verifier smart contract commits the new balance on-chain
StarkNet: the heart of the ecosystem
StarkNet was designed to excel where StarkEx does not: composability between different apps. A contract that is dreamt up by any developer can interact with any other contract launched under the permissionless StarkNet umbrella. These contracts can also interact with Ethereum L1 asynchronously. In StarkEx’s permissioned structure, applications themselves are responsible for submitting transactions. In StarkNet, it’s all handled by the network’s sequencers.
Launched over one year ago in November 2021, StarkNet is designed to benefit from economies of scale: the more transactions in a batch, the less gas each individual on-chain entity has to pay. So while StarkEx is great for self-contained protocols, StarkNet is great for protocols that benefit from plugging into and chatting with other neighboring protocols – and it gets cheaper to do so as the network grows. Take Game of Life 2, a compute-heavy game that launched recently on StarkNet. You can imagine a world where games with DeFi components might need native swap functionality. With StarkNet, they can seamlessly call from a neighboring DEX or any other contracts, all with Ethereum L1 only verifying a single proof.
Verifying STARK proofs requires much less computational resources compared to proving the actual computation done by StarkNet. As with all ZKRs, StarkWare’s sequencer is not currently decentralized (although there are plans for this in the future) and all transactions are verified by StarkWare cloud servers. Because StarkNet’s nodes must validate both StarkNet and Ethereum simultaneously, the team implemented checkpoints to reach finality on the rollup side much quicker.
StarkNet is currently in alpha, live on mainnet. It’s worth noting the design trade-offs of using Cairo, the team’s native Turing-complete language. It makes it easier and faster to develop and maintain code in the ecosystem, but the barrier to entry for developers is inherently selective and limiting. This is where the third-party transpilers come into play to mitigate this aspect. For developers wanting to dive into writing and deploying contracts to the L2, the Hello StarkNet tutorial offers a simple walkthrough. For those looking to bridge over to StarkNet and play with the 100+ protocols, use the official StarkGate bridge, Orbiter, or LayerSwap.
What lies ahead in 2023 and beyond for StarkWare?
Throughout 2022, the zkEVM narrative gained steam and a lot of venture capital. Of course, we can expect the StarkWare team to fiercely compete in this sub-vertical as well. There’s ongoing effort to develop their alpha compiler from EVM to StarkWare’s Cairo language. In Vitalik’s post from August 2022 discussing the various types of zkEVMs, he classifies that they range from Type-1 (Ethereum-equivalent) to Type-4 (high-level equivalence at the language level). Essentially on the Type-1 end of the scale, we have extremely high compatibility with Ethereum and a tradeoff of many ZK-related inefficiencies (such as prover time). At the opposite end, we have systems that give developers much more leeway given that they are not constrained to full Ethereum compatibility; this results in a ZK-STARK friendly environment and faster prover times. Nethermind’s Warp transpiler allows teams to easily onboard from Solidity to Cairo, and thus StarkWare’s zkEVM will be most similar to a Type-4 network.
August 2022 saw the first implementation of recursive proofs. Recursive proofs achieve a rare trifecta of (1) improved scalability, (2) improved cost, and (3) improved latency without one being a tradeoff of the others. This is a core component of the team’s L3 scaling strategy; StarkEx apps and StarkNet L2 can scale with a single proof through the use of SHARP (aka SHARed Prover). SHARP was at first a non-recursive proof that increased the transaction processing rate by taking several apps’ transactions, combining them into a single proof, and posting it for a validity check. This is hard-coded logic. The next evolution of this is recursive proofs, which does this for general computation. Cool stuff. Essentially, a single proof attests the validity of several “up-stream” proofs, and SHARP proves statements upon their arrival. Those proofs are merged over and over into a single proof (a recursive proof), and then it is submitted to the on-chain Verifier.
Basically: recursive proofs = a huge increase in the number of transactions that Ethereum “sees” through a single proof. Think of traditional STARK scaling as a bucket under a running faucet of transactions. The single bucket gets posted to Ethereum. Recursive proofs let us fill up many buckets, pour them into a mega-bucket when they’re full, then submit to L1. Squint and check out the graphic below:
Vitalik has recently voiced his thoughts on applications that he would like to see going forward in 2023. Among his ideas were hybrid off/on-chain systems like voting, but also “auditable centralized services.” StarkEx can actually be used as an alternative to the “Proof of Reserves” system that has been pushed for after the implosion of FTX and other centralized finance platforms. Instead of just implementing PoR, centralized exchanges can implement non-custodial features to inherently and completely prevent the theft of users' funds. Essentially, every aspect of the CEX could remain as-is: user sign up, KYC and AML, the order books remain centralized, etc. The difference would be that transactions are sent to StarkEx for on-chain verification via the aforementioned REST API. With this structure, if an exchange choses to be malicious - or even shuts down entirely - funds are impossible to steal. Users could submit a withdrawal directly from Ethereum L1 post-collapse. Decentralization is not binary. It’s important that apps begin taking steps to adopt hybrid structures, and StarkWare’s technology stack can enable unique use-cases like these.
Projects Building on StarkWare and other Alpha
We’re just at the beginning of an L2 application era. On the second chart, check out the sheer volume of “testnet” and “not live” vs already-deployed projects. It's a striking metric to see not only how many teams kept building on StarkWare throughout 2022, but the amount that are currently building on testnet or launching at some point in the future.
For the real alpha, take a look at the vibrant community of builders, currently 100+ strong: StarkWare Projects (🌾 alfa).
There are a bunch of narratives to cling to when looking through these projects, but we’re particularly excited for ZKX – an order book-based derivatives DEX. Post-FTX, traders need strong alternatives to CeFi products without sacrificing user experience. ZKX is a first-mover in offering perpetuals on StarkNet and offers strong gamification mechanisms (such as earning USDC for trading/staking and linking governance to trading volume).
Since the ZKSync team has confirmed they’re releasing a token, it’s logical to assume StarkNet will do the same. There’s definitely been some rumours to that effect. To maximize your chance of being eligible for the airdrop check out the thread below:
Final thoughts
Exciting things are ahead for the StarkWare team and their vast suite of scaling tools. From a high level, think of StarkNet as the giant, generalized network-of-networks focused on composability (with all of its beautiful, interlocking DeFi Lego-block glory) and StarkEx as the app-specific, permissioned, tailor-made engine for businesses. Both work in parallel and compliment each other, both utilize validity proofs, and both support general computation. In fact, StarkEx Validiums and StarkEx rollups (and maybe one day Adamantiums) can port over to StarkNet in their fractal scaling/L3/L4 world.
While the team is focused on decentralization of the network and infrastructure, they are taking the well-trodden path of most rollups: limit risks by starting with a whitelist of dApps and a single sequencer. Part of this process of progressive decentralization will include the launch of a governance token, although the specifics around community decentralization have yet to be expanded on. Its token went live on mainnet in mid-November.