StarkEx: Why, What and How?

StarkWare or: How I learned to stop worrying and love complexity

STARK proofs (and their practical application by StarkWare) are one of the most exciting leaps in technology since the invention of Bitcoin. Like any technological leap, STARKs are also mind-bendingly complex. This complexity can be a limiting factor for people’s understanding of the technology, and as a result, become a limiting factor in onboarding the masses into web3. The purpose of this essay is to provide a simple explanation of STARKs, and how StarkWare implements this technology, for the purpose of accelerating blockchain adoption.

Before we dive into how STARKs work, it is worth highlighting the power of this technology through a little case study. This case study provides an excellent example for the power of STARKs.

Case Study: Sorare and STARKs

Sorare is the creator of popular online fantasy sports games for European Soccer, the NBA and Major League Baseball. Users get digital cards to represent the players in a game, and these cards come as NFTs. To create an NFT for a customer, Sorare pays ‘gas’ on Ethereum (gas is the fee paid to execute a transaction on Ethereum — more on that below); at their peak, Sorare was paying $1m per week in gas fees to mint (create) NFTs. It was important for Sorare to provide Ethereum security, but the gas costs were high. Sorare then integrated with StarkEx, (StarkWare’s Saas platform) and switched from minting directly on Ethereum to minting on Layer 2. The result: their gas costs reduced from $1m per week to $10k per week. With a single technology change, Sorare reduced a substantial business cost by 100x, while maintaining the same user experience and customer security. When we talk about 1000x advances in technology, we are getting into the realms of the printing press and micro-processors. STARKs are promising to change the blockchain on a similar scale.

The Blockchain Law of Physics

Before learning about STARKs, it is helpful to understand the benefits and limitations of blockchains themselves. If you’re already familiar with the blockchain trilemma, you can skip this part and go straight to the section that explains L2s and how they work.

This essay will focus on the Ethereum blockchain specifically. By nearly any measure, Ethereum is the largest and most successful blockchain (excluding Bitcoin, which is not a smart contract platform for general use): It accounts for more than 50% of Total Value Locked on all blockchains and around 4000 active developers (higher than all other chains combined). Ethereum is also the basis security layer for STARK-based technology.

To understand the benefits and limitations of Ethereum, we should start with a model for understanding blockchain tradeoffs created by Ethereum co-founder Vitalik Buterin, called the Blockchain Trilemma.

The blockchain trilemma is something like the laws of physics for the blockchain: it states that blockchains must tradeoff between three key factors: security, decentralisation and scalability, and that it can only ever optimise for two of them. Just like the laws of gravity exist throughout the universe, no blockchain can escape the blockchain trilemma. Understanding the blockchain trilemma is a prerequisite to understanding the power of STARKs:

• Decentralisation has two factors: The first is the number of ‘nodes’ in a network. A node is a copy of the entire blockchain — simply put, it is a database of all the transactions that ever happened on that blockchain. A network with a single node is centralised — e.g. the files saved on your laptop’s hard drive or a list of customer’s accounts saved on a server in the back of a real estate agent’s office. A network with multiple nodes, controlled by a single entity, is also centralised — e.g. a bank that has their customer database stored on two cloud networks across several regions. A network with many nodes, with many different entities controlling those nodes, is decentralised. Ethereum has between 7000–8000 nodes at a given time.This is several multiples more than Ethereum competitors like Solana (~2k) or Polygon (~100), making it highly decentralised. However, It is worth noting one criticism of Ethereum: there is a concentration of ownership of those nodes — about 50% of Ethereum nodes are run by three entities (Lido, Coinbase and Kraken). This relates to the second factor of decentralisation which is ‘inclusivity’. This means that anyone that wants to run a node is able to do so. The limiting factor for inclusivity (other than access to the internet) is the cost of running a node. This cost is dictated by the computational power required to run a block (a copy of the latest batch of transactions) and the cost of staking (how much of a specific crypto-currency you need to lock up [known as staking] in order to run a node). A blockchain that requires the computational power of a room full of servers will not be inclusive, because only people or entities that can afford a room full of servers will be able to run a node. Conversely, a blockchain that only requires the amount of computational power contained in a smartphone will be highly inclusive, because anyone with a smartphone can participate in running a node.
• Security is a measure of how immutable a blockchain is; put another way, how easy is it for any party to change, or falsify, a transaction on the blockchain. If a party is able to falsify a transaction on a blockchain, they can make the ledger say whatever they want — for example, they can add a few extra zeros to their balance and zero out someone else’s. For a centralised application, it is technically simple to falsify transactions on a ledger (even though one might risk their reputation, hefty fines or even jail time). This is why regulators exist, and why banks have thousands of people on their compliance teams and spend hundreds of millions of dollars on compliance technology. The way blockchains ensure security is by requiring 51% of all nodes to verify a block before it gets committed to a blockchain — therefore, for someone to be able to falsify a transaction on Ethereum, they would have to control 51% of all nodes, which on a highly decentralised blockchain is both technically and financially extremely (extremely) difficult. As a result, a blockchain that is highly decentralised is also highly secure.
• Scalability is measured by how many transactions you can run on a blockchain at any given time (often measured in transactions per second). The limiting factor in blockchain scalability is actually decentralisation — a blockchain is only as scalable as the weakest node (eg slowest computer) in its network. The volume of transactions per second a blockchain can process is dictated by the size and creation frequency of blocks in a blockchain (a block being an updated version of the database, with each new block representing the most updated version of that database — a chain of blocks then becomes a blockchain). Less inclusive blockchains that require powerful, expensive computers to run their nodes can produce a higher volume of transactions per seconds than blockchains that require less sophisticated machines. Blocks have capacity limits, because they need to be small enough that the smallest computer on the network can run, and fill up when there is high demand on the network. If someone wants to make sure their transaction gets prioritised in a block (e.g. they want to make sure their purchase of an NFT gets recorded onto Ethereum immediately), they pay extra ‘gas’ (the fee required to execute transactions) to node operators in order to get their transaction to the front of the line before other transactions. Think of it as an auction — the more transactions competing to fit in a block with limited space (more demand [transactions], limited supply [blockspace]), the more expensive the cost to execute any single transaction. In 2021 during the height of the bull market, the average cost of a transaction on Ethereum was $21 USD. So regardless if someone transfers $1m or $10 in Eth, completing that transaction would cost $21 at peak network congestion in 2021.

A blockchain like Ethereum, that is highly decentralised and highly inclusive (and therefore safest for users) is inherently less scalable. As a result, even though Ethereum is the leading smart contract blockchain, it cannot deliver the throughput to impact the lives of billions of people (global payments networks, national identity solutions, global supply chains, social media) and fulfil Ethereum’s goal of becoming the World’s Computer.

Layer 2 Solve Ethereum Scalability

Layer 2s set out to solve Ethereum’s scalability problems. Simply put, a Layer 2 scalability platform sits between an application and Ethereum. An overly simplified analogy (which will be expanded below) is that a Layer 2 does to transactions what a zip file does to data. When transactions are sent from an application to Ethereum via a Layer 2 protocol, the resulting space used on an Etherum block is orders of magnitude smaller (up to 1000x smaller) than if those transactions were sent directly from the application to Ethereum. So how does this work?

The first step is to understand the difference between ‘on-chain’ and ‘off- chain’. On-chain activity happens on a blockchain. If a transaction, computation, data storage, etc happens on-chain, that means that it is conducted and stored on all of the nodes of a blockchain. On-chain transactions and on-chain storage are expensive because of limitations in block size. For blockchains that prioritise scalability over decentralisation and security, on-chain transactions are cheaper. Off-chain computation and storage, on the other hand, is many multiples cheaper. Cloud platforms are ‘off-chain’ compute and storage specialists — it costs very little to spin up a new compute instance to run an application, and little more to create a database to store as much data as you want. AWS and Azure are centralised tools: They have no blocks limiting scalability, so they can scale computation and storage almost infinitely.

How does this apply to Layer 2s like StarkWare’s scaling solutions? Simply put, Layer 2s takes all of the high-computational activity required to run apps such as NFT marketplaces (mint, transfer and swap NFTs) or crypto exchanges (record customer balances, exchange rates, crypto payments, wallet signatures, etc) and runs their calculations off-chain, where computation and storage are cheap. On Layer 2, there is no need to pay gas fees, so running these highly complex calculations now costs a fraction of what it would on-chain. Of course, this begs the obvious question — if these calculations are run off-chain, how do they get on-chain?

A Transactions Journey in StarkEx System

To get from off-chain to on-chain, a transaction goes through several steps. The example below is for StarkWare’s Layer 2 SaaS platform called StarkEx. This is the platform used by StarkWare customers like Sorare, ImmutableX and dYdX to achieve Layer 2 scalability without having to write their own smart contracts — rather, customers build their applications on top of StarkEx APIs like you would with most b2b technology platforms.

Off-Chain: App Operator and StarkEx System

First, the transaction is generated by the end-user on the operator’s application (e.g. Sorare’s customer logs into Sorare and buys an NFT). The operator will review the transaction to make sure it is valid (has a digital signature, the user has an appropriate balance, adheres to the required business rules), and then send it to their own StarkEx instance. Each application has their own StarkEx instance, configured for their particular use case — perpetuals, spot trades, NFTs, etc. The StarkEx instance then runs its own logic over the transactions, again, making sure they meet all required business rules.

Off-Chain Prover

For the final off-chain step, transactions are sent from the StarkEx instance to the STARK Prover. The STARK Prover is where the transaction ‘roll up’ happens. Similar to what a zip file does with data, the STARK Prover takes hundreds of thousands of transactions (sometimes millions) and produces a very long string of numbers that represent all of these transactions, called a Proof. Interesting to note: nearly all StarkEx operators send their transactions of the STARK Prover to ‘share’ the proof that the prover generates — so we call the Shared Prover ‘Sharp’.

Going On-Chain

Once the Proof is complete (either when it is completely full of transactions or after a specified period of time) the action moves on-chain. The proof gets sent on-chain to the STARK Verifier smart contract. This smart contract sits on the Ethereum blockchain — like all Ethereum smart contracts, it is public and open-source. The STARK Verifier smart contract cannot accept a non-valid proof. If money was moved without a customer’s consent (e.g. digital signature), if an account did not have the available balance to complete a transaction, the proof will be rejected. If a proof is valid (meets all business rules), then that proof will be written on to the Ethereum blockchain, giving those transactions ‘Ethereum-level’ finality and security (on the ledger forever). In this way, STARK proofs enforce Ethereum Layer 1 security on StarkEx’ off-chain process.

The proof verification is one of two pieces of information that StarkEx sends from off-chain to on-chain. The second piece of information is the State Update. The State Update represents the new balances of all customers accounts after all transactions in the batch were processed. This is required to be stored on-chain so that, in the event off-chain services stop working, a customer can still withdraw their funds from Ethereum.

Data Availability

The State Update is written from each operator’s own StarkEx instance to a separate on-chain smart contract called the StarkEx smart contract — ImmutableX has their own StarkEx smart contract, as does dYdX, Sorare, etc. The simplest way to store the State Update would be to record all the transactions on chain; however, just like compute, data storage is incredibly expensive on-chain. Rather than storing each transaction, an operator has two options for how to store their data — we call this the Data Availability Mode.

Rollup mode

An operator can choose Rollup Mode (which dYdX uses); in Rollup Mode, the difference between the balances of the previous state and the balances of the next state is transmitted to the operator’s StarkEx smart contract on Ethereum. This allows third parties to reverse engineer StarkEx’s state independently by going over the incremental changes reported by each state update. This is orders of magnitude cheaper than storing the entire history of all transactions on-chain, and even cheaper than reporting as calldata the transactions list. It also allows more confidentiality than showing the transactions list, as only the starting state and the ending state (potentially thousands of transactions later) are revealed.

Validium mode

The other Data Availability mode is Validium; in Validium mode, the state updates are stored with Data Availability Committee (DAC) members. DAC members are independent third parties that agree to receive and hold each state update on behalf of the operators — a DAC member commits to publishing the state updates on-chain if an operator (or StarkWare) ever go off-line, which guarantees that a user is always able to retrieve their funds (a critical component of self-custody). DAC members include Consensys, Chainstack and StarkWare, and many more reputable parties. Operators choose Validium mode because it is cheaper than Rollup mode; in Validium mode, only the DAC members’ signatures verifying that they have the latest state update are stored on chain in the StarkEx smart contract. An additional feature of Validum mode is that transactions and balances are not stored on-chain — this is a huge benefit for companies that want to protect the confidentiality of their users.

Ultimately, the StarkEx smart contract is the critical piece for ensuring self-custody; by having the latest state update on-chain, a user can always withdraw their funds. And by requiring a user’s signature for every transaction, the balance can never change without a user’s specific approval. This way, even if StarkEx collapses, even if the operator goes out of business, a user can write directly to the StarkEx smart contract on Ethereum to retrieve their balance. This is the key to making StarkEx a scalable and secure self-custody platform, and protecting against FTX like disasters.