Thread by @ali01

One view in crypto is that a single blockchain (like Bitcoin or Ethereum) will someday emerge victorious and proceed to dominate all use cases. I disagree. It’s more likely that many networks will emerge as winners in their own subdomains of the crypto sphere

A monster thread 👇

First, the basics: Cryptonetworks have the potential to evolve into the infrastructure of the next generation internet. Once this revolution has played out, there will exist applications as complex as Facebook that are decentralized and open source
outlast.me/crypto-the-fut…

Such applications will be owned and governed directly by their respective communities, rather than by single companies or institutions. In this new paradigm, developers, investors, and even users will all be stakeholders of the networks that they participate in.

And, because crypto-assets make it possible to directly capture some of the value that is created by open source, this vision is economically sustainable and self-reinforcing in a way that open source alone has never been.

The right cryptoeconomic incentives can encourage anyone in the world to contribute — be it with resources, ideas, code, or product. This, combined with crypto's open source nature, has the potential to organize human cooperation at an unprecedented scale.

https://twitter.com/ali01/status/964921177918488576

For all of this to work, however, we need a kind of “world computer” that can run a special type of program — a program whose correct execution does not depend on the trustworthiness of any one entity, not even those who control the computers that run it.

Certain blockchains today have the ability to play the role of such a computer. The programs running on top of them (known today as “smart contracts”) are cryptographically and game theoretically guaranteed by the underlying blockchain to execute *as written*.

Ethereum pioneered the first truly global, decentralized world computer by generalizing the ideas behind Bitcoin. Ever since its conception in 2014, it has unquestionably become one of the most important projects in the space.

The smart contracts that run on top of it today have proven to be powerful building blocks. Their trustless verifiability is the core reason why they can credibly disintermediate the organizations that today sit in the middle of many of our interactions.

The growing world of decentralized finance (DeFi), for example, has demonstrated that smart contracts on Ethereum can better encode a lot of the inefficient and error-prone logic that today runs inside of human brains within financial institutions.

As it turns out, highly formulaic contracts about things like fundraising, trading, lending, derivatives, payments, and insurance are often better expressed in code than in legalese (:

And, of course, it makes perfect sense that DeFi has emerged as the first crypto category to get some traction on top of Ethereum. DeFi’s requirements are well matched to Ethereum’s features and limitations.

Having to wait a minute or two to take out a loan from @compoundfinance, for example, might not be ideal, but it’s still orders of magnitude better than having to deal with a bank. Ethereum’s performance limitations don’t really get in the way of that use case.

On the other hand, Ethereum’s strengths (its relative simplicity, uniform security model, and established track record) are the exact set of features that you would want as a developer if you’re building a high stakes financial application.

Other kinds of applications, however, will require different things from a blockchain.

Let’s work through an example of a radically different approach to building a blockchain. But first, remember that none of the following should be taken as investment advice (for more info, see a16z.com/disclosures).

@a16z’s recent investment in @withflow_, a blockchain with an ingenious architecture, is a bet that the tradeoff space that blockchains inhabit is far too large and high dimensional for a single blockchain to span all of it.

The team behind it is @dapper_labs. They have deep experience building crypto-enabled games (this is the team that built @CryptoKitties). The resulting architecture for Flow is optimized for mainstream consumer applications with a focus on games.

So, what exactly is different about it?

The contrarian hypothesis at the heart of Flow’s architecture is that sharding is not the only viable approach to scaling a blockchain.

The term “sharding” in crypto (and all of distributed systems) refers to the subdivision of a system into various smaller subsystems (“shards”) such that the total amount of work to be done can be split across them. Think of it as the divide and conquer approach to scalability.

A sharded architecture for a blockchain implies that each node is responsible for validating only a subset of the transactions validated by the whole network. This is in contrast to the way most blockchains work today, where every node must validate every transaction.

One problem with sharding is that it creates greater complexity for developers. In a sharded world, even simple applications have to deal with the fact that different shards progress independently, so they are not automatically in sync with one another — they are asynchronous.

This makes it harder to write applications that span shard boundaries or that build on top of other applications (perhaps built by other developers) that reside on different shards; it gets in the way of software composability:
jessewalden.com/4-eras-of-bloc…

All of that complexity might be warranted (or even necessary) for certain applications, but consumer apps like games (that depend on greater responsiveness and are often lower stakes) might be better served by a single shard architecture.

So, is there a region in the tradeoff space that allows for that?

Just about every distributed computer system in history that has reached global scale has had to rely on sharding to some extent. No single router on the internet forwards every data packet. No single Google datacenter stores the entire index for the web.

Nevertheless, while this may suggest that sharding will inevitably be part of the solution someday, we have only begun to explore the extent to which blockchains can scale without it.

Flow has made great strides in that direction. How does it work?

For context, blockchain based networks tend to be subject to a tradeoff that is known as the scalability trilemma. It claims that blockchains can optimize for only two of the following three properties:

a/ Decentralization — The number of independent nodes that collectively have control over the network.

b/ Scalability — The network’s throughput (number of instructions processed per second)

c/ Security — The network’s ability to withstand attacks from adversaries with resources that are commensurate with those of the whole network combined.

The @dapper_labs team has conceived of an architecture for a blockchain wherein the separation of labor between nodes is vertical (across the different validation stages for each transaction) rather than horizontal (across different transactions, as with sharding).

In other words, every node still participates in the validation of every transaction, but they do so only at one of the stages of validation. They can therefore specialize for — and greatly increase the efficiency of — their particular stage of focus.

Crucially, this allows each class of node to fall into its own region of the Scalability Trilemma. The system as a whole can thereby get the best of all worlds.

The team’s insight is that it is possible to split a traditional node in a blockchain like Ethereum into four different kinds of nodes, each with its own distinct role:

a/ Consensus Nodes are responsible for consensus in the network — that is, they decide what transactions make it onto the blockchain and in what order.

b/ Execution Nodes perform the computation associated with each transaction once their presence and order on the blockchain has been finalized by the Consensus Nodes.

c/ Verification Nodes are responsible for keeping the Execution Nodes in check.

d/ And finally, Collection Nodes form a peer-to-peer network that offers the network connectivity and data availability.

Consensus and Verification Nodes together are the foundation of security in the Flow network. They leverage cryptoeconomic incentives to hold the rest of the network accountable. Collection and Execution Nodes, on the other hand, allow the network to scale.

The beauty of this separation is that Consensus and Verification Nodes, whose role is the most critical for the integrity of the network, can optimize for the security + decentralization side of the triangle in the trilemma.

Execution and Collection Nodes, conversely, do work that is fully deterministic (making them less vulnerable to attack). Their work is also verified and held accountable by the other node types. They can therefore safely optimize for security + scalability.

In fact, in order for the system to scale, Execution Nodes will likely be professionally managed datacenters — highly performant and well connected to the internet, albeit less decentralized than the other node types.

This clever separation of concerns is what allows Flow to bend the rules of the trilemma and scale beyond other blockchains but without sharding. It’s a great example of a system that, through ingenious architectural choices, lands in a different region of the tradeoff space.

Applications that greatly benefit from the developer ergonomics of a single shard and that depend on high throughput might find a comfortable home on Flow in the same way that DeFi has on Ethereum. To learn more about Flow, check out: withflow.org

The architectural design space in crypto is broader than most people think. The landscape of applications to be built on top is broader still. It’s hard to imagine that one blockchain with its singular set of choices could come close to spanning the entire crypto universe.

{fin}