Breaking the Crypto Status Quo

Much of the innovation in crypto has been workarounds to features of Ethereum. The proliferation of these workarounds indicates that there is demand for different core models, distributed services that don’t look like Ethereum, and that work in completely different ways.

Introduction

In this article we explore where Crypto (the technological paradigm and the industry) is today, and where it could go if we relax some of our assumptions.

Crypto started as a currency and then made the natural transition into banking/finance.  It has found its product/market fit here.  We will show how several features and design decisions common to most current Crypto networks make them well suited to banking/finance applications, but ill suited to other domains.  Ethereum, its L2s, its clones, and its competitors are all designed for banking/finance.  They are designed around a ledger and the core object that they deal with is money.  They are “bank-shaped solutions”.  Other domains can benefit from the open, distributed execution model at the core of Crypto software, but they won’t be able to be stuffed into a bank-shaped solution. 

We need different models.

In this piece, we will show that there is demand for different models and how significant parts of the ecosystem are workarounds to features of the bank-shaped systems (Ethereum et al).  We will reevaluate some of the current core tenets, features, and design decisions of Crypto and show how they are not necessary or desirable for applications outside banking/finance, including some apps that would be considered Web2.  And finally, we will describe a Crypto layer that looks nothing like the bank-shaped solutions we have today.

But first, let’s define what Crypto is.

Crypto is the open-source execution of software.  The open-source software development model allows software to be created publicly, out in the open, where everyone can see it and know exactly how it works. Crypto is a model to execute that software publicly, out in the open, where everyone can see it and know exactly how it works and how it will keep working.

This definition is pretty broad.  It doesn’t include transactions, or blocks, or chains, or even state.  Those are all building blocks for the particular set services that current Crypto networks provide.  Bitcoin provides the service of a simple ledger.  Ethereum is also just a ledger, but one that can be interpreted as performing changes to a more complex global state.  Both incentivize hardware owners by minting and transferring virtual currency to the hardware providers, and all the hardware provider has to do is run the open-source software. All Crypto services need to “pay” the hardware somehow, but they don’t have to be a ledger.

What types of services fit this definition?  Any service where independent users have to interact and communicate.  Traditional open source software doesn’t work for these types of services.  The open source model works great for applications where everyone needs their own independent instance, like an operating system or a web browser.  But for a service where there is effectively one instance, like a banking system or a social network, someone has to run that instance, and the result is closed and opaque.  Crypto brings open source software and open execution to these types of applications.  They can be executed by anyone to produce a shared service that everyone can use.

With this definition, we can see how Crypto relates to public cloud services like AWS or Azure.  It’s not a competitor or a replacement.  Public cloud is a great way to run a service where independent users are not interacting/communicating, for example, an online store where customers are just buying things from the site.  It’s unlikely that Crypto will be a better solution for applications like this.  They don’t need the benefits of public execution.  

Ethereum (et al) is just the first version of a very young technology.  The real innovation and opportunity is not in optimizing the first version, but in building the second.

Workarounds

Many parts of the Crypto industry seem to be workarounds for features in the core model (Ethereum). Workarounds are partial solutions that often come with undesirable side effects.  We suspect the proliferation of these workarounds indicates that there is demand for different core models, distributed services that don’t look like Ethereum, and that work in completely different ways.  

The “ideal” solution for app developers and app users would be for all apps to run in the same virtual machine (on Ethereum, for example).  Developers would always get maximum interoperability.  Users would always know where apps live.  And everyone would always get maximum security because security (stake) would always be concentrated in one place.

But everyone being on Ethereum gets expensive, arguably because Ethereum in its current form doesn't scale with demand.  Block capacity is a finite resource per unit time.  

Enter L2s, a workaround for the high cost of running an app on Ethereum.  The root cause of that high cost being Ethereum’s inability to scale with demand, so L2s have to workaround that scalability problem as well.

L2s give up a lot to workaround this problem.  They lose interoperability between apps on the L2 and apps on the L1.  Apps on different L2s can’t talk to each other easily either.  Both problems need complex bridging and messaging systems, which need off-chain components to work.  Many projects are trying to solve these problems in various ways, but those “solutions” are really workarounds to the side effects of other workarounds.

We can’t build a new layer in the computing stack as a series of workarounds.  Crypto, as a computing layer, is still in its infancy.  We will only get so far (and with great effort) by patching the first core model.  That does not mean that Ethereum is broken or wrong in any way.  It is, at its core, a platform for banking/finance and as such, doesn’t necessarily work well for other types of applications.  L2s and other workarounds are an attempt to fit a square peg in a round (bank-shaped) hole.

The following sections describe 5 different traits shared by pretty much all current Crypto networks.  While these traits may be desirable for banking/finance applications, they are likely holding back broader Crypto adoption.

Crypto is v̶i̶r̶t̶u̶a̶l̶ ̶c̶u̶r̶r̶e̶n̶c̶y̶

Bitcoin is a virtual currency.  Ethereum has a virtual currency at its core and a way to program logic (contracts) around that currency.  This is certainly one of the key innovations that made the first generation of Crypto possible.  A virtual currency allows the software to pay the hardware provider directly and allows the user to pay for their transactions with only software in between.  This system has a lot of great properties but isn’t the only way to incentivize the hardware provider.

What about a project whose service is a public good?  A not-for-profit Crypto project.  Hardware providers would be donating valuable hardware resources.  Donations that can reduce their taxes (a frequently used incentive).  The system would have to keep track of and prove the donations of hardware providers as a sort of on-chain receipt, which would allow hardware providers to document their tax deductions.  No currency is necessary in this system, just receipts.

Distributed computing projects like SETI@Home, Folding@Home, and many others, show that there are things people are willing to donate hardware resources to.  Lots of commercial computing hardware sits idle much of the time.  

Crypto is a̶ ̶l̶e̶d̶g̶e̶r̶

If you’re making a currency, you probably want a ledger.  Ledgers are how we’ve been keeping track of money for a really long time, on paper and on computers.  And having all that history is great, because we love studying what money things did in the past.  Current crypto systems using a ledger isn’t a mistake or something that needs to be fixed.  It’s the perfect foundation for banking/finance applications.

But most apps aren’t like banking.  Most apps don’t need to be able to reproduce their state at any point in time in the past.  Maybe they collect some useful historical data, but for the most part they only care about their current state.

The most trafficked site on the internet, Google, YouTube, Facebook, Twitter, Instagram, etc., aren’t bank-like and aren’t implemented as ledgers.  You can’t go back and reproduce the state of YouTube from years ago.  There’s no need to.  The data of these sites keeps changing and marching forward, but they don’t need to keep track of every change that was made along the way.

If you only care about the current state, then you only have to pass around state changes and not actual transactions.  We’re already seeing projects like Mina and other ZK projects exploring this direction.

Crypto is a̶s̶y̶n̶c̶h̶r̶o̶n̶o̶u̶s̶

Everything on the internet is asynchronous, but Crypto transactions are very asynchronous.   There is a lot of time between submitting a request (a transaction) and receiving a response (whether it was executed or not).  Because of this, it’s very hard to 

1. Do some computation locally
2. Based on that computation, call some Crypto service
3. Do some other computation locally, based on the result of the Crypto call

The reason it’s so hard is that because there’s so much time between 1 and 3, the local state can change, making the result of the Crypto call no longer valid or relevant.

There’s no reason that a Crypto system has to be so asynchronous.  The long delay between request and response is a side effect of the block building system.  A system that could respond, maybe with some proof of inclusion or correctness or execution, in a more web2-like timescale (less than a second), would be much easier to compose with other systems.  

Maybe even other Crypto systems could use each other’s services as part of their own.  One network, in the process of executing its own transactions, could call out to another network.  A low latency response could be included in the results of the transaction’s execution results, enabling synchronous-like composability.

This may require some coordination, some agreement on protocols between systems.  The TCP/IP protocol allows separate computer systems to establish persistent, reliable connections between each other over an inherently unreliable messaging system (the internet).  It makes a pseudo-synchronous connection out of an asynchronous one.  To do so, it requires both ends of the connection to agree to some standards and procedures.  Crypto could have similar protocols to allow networks to interact with each other, but it won’t be able to do so with the current very long time between request and response. 

Crypto is i̶r̶r̶e̶v̶e̶r̶s̶i̶b̶l̶e̶ ̶t̶r̶a̶n̶s̶a̶c̶t̶i̶o̶n̶s̶

Irreversible transactions are a core philosophical decision of Bitcoin that has been carried over into pretty much every other Crypto project.  Irreversible transactions are great for a seller, but awful for a buyer.  The buyer paying the seller is only one half of a transaction.  The seller has to provide the other half in the form of the goods or services delivered to the buyer.  If the good or service also lives in the same virtual system as the currency transaction (like financial products or NFTs), great.  This is a great feature for virtual financial products.  The system can enforce that both sides of the transaction happen correctly and there’s no need to reverse the transaction, ever.  

Except…

When the goods or services are not in the same system as the currency, the currency transaction can’t “know” if the goods were delivered or the service was rendered.  Sometimes they aren’t.  Sometimes it’s fraud on the part of the seller.  Sometimes it's a misunderstanding.  Sometimes it’s identity theft.  Lots of transactions need to be reversed and you can’t rely on the seller to be honest about it.  The current system of irreversible transactions puts us in the position of trusting the seller.  It doesn’t work for real life.

But that’s not even the biggest problem with irreversible transactions.  Irreversible transactions make it too dangerous to self custody.  The problem with wallets is not the UI or the authentication scheme or the programmability.  The problem with wallets is that the thing they protect is all or nothing.  If there is a compromise, all the value in the wallet could be gone, with no recourse, because all transactions from the theft are irreversible.  Contrast this to a credit card, which arguably serves a similar purpose to a Crypto wallet: authorizing transactions.  You don’t have to worry about protecting your credit card, because if it’s stolen, the transactions can be reversed.   

In the centralized financial system, banks decide when a transaction needs to be reversed.  I don’t think anyone would argue that they try to do this fairly, or in any way that takes into account anyone's interests but their own.  Centralizing the reversal decision is certainly a problem, but that doesn’t change the fact that transactions sometimes need to be reversed.

One could imagine a system where if there was a transaction dispute, one party could register their desire to reverse the transaction in question.  Both parties could present their side to a “jury” of randomly selected volunteers, all on-chain.  The distributed “jury” would decide if the transactions should be reversed or not.  There would have to be some cost to dispute a transaction and that would go to incentivize the jurors.  For example, a police report could be submitted to prove theft.  The jury could execute legal court orders.  The system would be able to interact with the real world in much needed, practical ways.

Crypto is g̶l̶o̶b̶a̶l̶l̶y̶ ̶c̶o̶n̶s̶i̶s̶t̶e̶n̶t̶

Consistency in distributed systems means that at any given time, the same read operation returns the same result on different nodes.  If I tell Node1 to write a value to state X, then I try to read the value from Node2, I’ll get the value that I wrote to X.  At no time will Node1 and Node2 return different values for X.

The current set of Crypto platforms achieve consistency at the block level.  After a new block is published, everyone applies the new transactions at roughly the same time and everyone gets to the new state together.  The tradeoff for this high consistency is high latency.  Transactions take a long time between being published, to being “finalized”.

Money transactions benefit from this lock-step consistency and (sometimes) don’t mind the latency.  This is a great feature for a financial system, because everyone always sees the same balance in an account, for example.  However, many applications need different tradeoffs in consistency and latency.

An application that needs low latency writes (transactions) might use a distributed database that practices “eventual consistency” instead.  In such a system, any node can accept and execute a write immediately, and then broadcast that write to the rest of the nodes.  As those nodes receive the write, they execute it and update their copy of the data.  Eventually, all the nodes have the same new version of the data, but while it’s updating, some nodes have the old version and some have the new version, and that’s OK.  

What happens if someone, on Node1 writes a value into some address X (X=1), and someone else on another node, Node2, writes a different value to address X (X=2)?  Both nodes accept the write and tell the user that it was successful.  Node1 starts propagating X=1 to the network and Node2 propagates X=2 to the network.  Eventually, both changes reach all nodes and all nodes resolve the conflict in a deterministic way, so they all order the transactions in the same way.  One value will win and the other will get overwritten, even though the transaction that wrote the losing value was successful.

This is terrifying if the value being written is your account balance, but most applications aren’t banks.  Think of an application like Twitter, where the writes are the messages you post.  Every user is writing to their own part of the state, so conflicts are rare to begin with.  You could submit 2 different tweets, A and B, to 2 different nodes at the same time.  For some period of time, some nodes would show only tweet A in your stream, some would show only tweet B, but eventually all nodes would show A then B (the deterministic order).  Lots of apps are more like Twitter and less like Banks.

Crypto could be…

Crypto is the open-source execution of software, so it has to provide a way for software developers to trust hardware owners to run their software correctly.  Ethereum created a way to incentivize hardware providers and guarantee that the software/protocol is being run correctly.  The service that Ethereum provides, the EVM, allows dApp developers to run their software on the provided, distributed hardware, without having to figure out a way to incentivize the hardware or figure out how to make sure their code is being run correctly.  Ethereum bridges the trust between the hardware provider and the software developer once, in a way that it can be used by many software developers (dApps).

Ethereum draws the boundary around that trust in a specific constrained way.  The shape of that boundary shapes how the platform can be used and what it's good at.  Ethereum made a bank-shaped hole that can be filled nicely with banking/finance apps.  But there’s certainly other shapes that trust could take.

In the end, the hardware owner has to run a piece of open source software and has to trust that running the software will get them paid.  The software developer has to trust that their software is being run correctly.  What if we take this to the extreme, ignoring all the things that Crypto is today?  What’s the most generic shape we can make this trust, so that lots of types of apps can fit into it, and can reuse the same trust?

A system like this might look very different from what we have today.  What if a hardware owner could run a truly general purpose virtual machine, without all the restrictions of the EVM, in which any distributed software project could run.  The virtual machine doesn’t have to restrict what the software running in it can do (like the EVM does).  The hardware provider could decide which projects to run in their instance of the virtual machine based on how much they expect to be paid for running the software and how much hardware resources the project needs.  The virtual machine would generate proofs/evidence that:

• The software being run is the exact software produced by the open source project.
• The running software is allocated the resources it needs.
• The software is actually running.
• The software is running inside this trusted virtual machine and not outside of it

Maybe the hardware owner has to stake cryptocurrency to the virtual machine so they can be penalized if any of the above is not happening.

On the surface, this model is a little like Ethereum, in that it provides a virtual machine for others to run software on.  However, the shape of the trust is radically different.  Instead of trusting that transactions are executed correctly (bank-shaped trust), this model doesn’t put any restrictions on what the software can do (beyond the resources it’s allowed to consume).

In this model, any project can produce software that provides pretty much any service.  It doesn’t have to be restricted to a closed ecosystem.  It can call out to other third party services and do whatever it needs to provide the service to the user.

The user can trust that the software is being run as published, in a distributed, decentralized way.   This means that no single entity can shut down the service.  The developer may abandon it and stop creating new versions, but it’s the hardware providers that decide to run it or not.  So if the service is valuable to users and their usage generates incentives for the hardware provider, the service will keep running.  All old versions are always runnable.  This is similar to Ethereum dApps.

In practice, a project still has to write a distributed system to provide whatever the service is, but they don’t have to bootstrap the network of “trusted”, staked nodes.  This model moves the trust down to a lower level where it can be more easily shared and is more generalized.

Conclusion

It may take a while for this to play out but we're confident we'll continue to see Crypto evolve in ways that enable a broader set of use cases beyond finance in the coming years. We at Stratos are excited to fund these new opportunities.