This week I sat down with one of Starknet’s Core Engineers, Ilya Lesokhin, and he raised the following question:
Why are we working so hard to stay true to our tech, submitting STARK proofs on-chain for every state update, attempting to “boil the ocean” with a new STARK-friendly VM - Cairo, when the market clearly says “just shut up and deploy anything ASAP, as long as you promise us that your security tech will arrive later?
This got me thinking. As a scientist, I love the technology which I co-invented and I want to see it deployed and used in practice. But putting on the entrepreneur and business-person hat, I have to confess that insisting on the tech does limit our speed to adoption. So here are my arguments as to why we’re not doing that, from a business perspective.
The Tiger-Riding problem: The “riding a tiger and trying not to fall off” parable describes a situation where you’re moving too fast to change course and fix things. In our context, suppose we were to take the fastest blockchain stack out there and say “this is our tech, start using it, STARK proofs coming any minute”. Doing this would mean we’re mounting the tiger and starting to ride on its back. The tiger - the underlying proofless-but-blazing-fast tech stack, would continue to accelerate towards ever lower costs and ever greater scale, and at any given point in time, if we’d like to pause and add the missing tech, the markets would ask “Why stall? Why get off the tiger’s back? We’ll wait a bit longer as we’re enjoying the ride”. The problem with this is that inevitably there will be a day of reckoning (see Figure 1), a day when some attacker will compromise the system in a catastrophic way because we never managed to put in the oh-so-necessary security tech (remember Mt. Gox?). Being responsible to your collaborators, customers, and fellow teammates means you shouldn’t go down this route.
Figure 1
True believers build correctly: Here’s a mock example. Imagine Alice and Bob are competing in the early days of commercial aviation. Alice is building a machine that actually flies, a complicated ordeal. Her first models fly only a few meters and transport nothing but the brave pilot. Bob, on the other hand, takes a freight train and claims he’s working on adding wings to it, but in the meantime it’ll go on rails. Thanks to this shrewd business decision, Bob has a huge commercial advantage over Alice in the early days, because customers will actually pay him for transporting their goods on his “airplane”. The point of this somewhat ridiculous example is this. If there is any added value that is unique to commercial aviation - which wasn’t clear at all in the early days of aviation (and isn’t clear today with respect to STARKs and validity proofs) - the only way to eventually monetize the technology is to follow Alice’s path.
Mass adoption beachhead: Mass adoption of blockchains has yet to start, as is clear from comparing total TPS (transactions per second) and TVL for all of crypto to those of traditional finance, or from measuring the fraction of humanity that uses crypto in their daily consumption commerce (the proverbial cup of coffee). We are building crypto technology for global scale, and we believe our technology - STARK proofs, with the scalability and safety offered by Cairo and Starknet - is essential for mass adoption, because it can scale immensely with no reduction in security and no additional trust assumptions. By focusing on building the right technology for that scenario, we cannot compromise on solutions that may seem “good enough” now but will cave under the pressure of mass usage. By analogy, it is harder to build a bridge for a highway than for a one-lane road, and it takes longer to finish that bridge. But when massive traffic arrives, the sturdier bridge will be the one used.
How do we defend the shortcuts that we have made? There are aspects related to decentralization and security that we have had to compromise on. In particular, we’ve started with a single centralized sequencer/prover and upgrades to the system are centrally managed. In an extreme scenario, these choices could also lead to catastrophic failures. If all projects are making certain shortcuts while developing their technology, what makes one kind of shortcut (like the kind we’re making) better than a shortcut taken by another team?
I want to offer two answers. The first is that choosing to not compromise on what constitutes the very core proposition of your technology, its engine and source of power, is better than compromising on core tech. When building a sturdy commercial airplane, you shouldn’t compromise on its ability to fly, but you may compromise on things like ability to fly at night or in rough weather.
The second answer is that by staying steadfast in promoting your core technology, it's more likely that you’ll be able to remove the training wheels that are ubiquitously used in early stage projects. For Starknet, this means that we believe it will be easier to decentralize the sequencer and prover of a centralized system than it is to add STARK proofs to systems not designed to support them.
We may be wrong in our reasoning, and many companies with great vision and clear values have failed for myriad reasons. The point in this short writeup is to explain, at this early point in time, how we reason about the technology and business choices we’re making.