@adlrocha - The Pieces of the Blockchain Lego
Just a small piece of the Web3 universe
When people hear the word “blockchain” what comes immediately to everyone’s minds are projects like Bitcoin, Ethereum or Solana. Of course, these projects are the core foundation for many more, but they are only a small part of the great gamut of projects that make up the blockchain ecosystem. What I like to call the blockchain Lego.
A few days ago I came across this great blog post from Coinbase describing the different layers of the Web3 stack. I personally wouldn’t call it the Web3 stack (for me, as it happens to others Web3 is way more than just plain blockchains), however, the post perfectly illustrates how the blockchain ecosystem is way more than just the Protocol Layer represented by the aforementioned projects. Instead of illustrating the different types of blockchain projects as a stack, I like to think about them as the different pieces of a Lego, that can be combined to build new decentralized applications and projects.
I enjoyed so much how the folks at Coinbase classified the different kinds of blockchain projects, that I am going to politely borrow their classification and build upon them to define the different pieces of the blockchain Lego:
Protocol Bricks are the foundational pieces for any blockchain application. They implement the protocols that enable cryptocurrencies, the deployment of smart contracts, the interoperability between networks, and improve their scalability. Some examples of protocol bricks are the aforementioned Ethereum and Solana for L1 smart contract deployment; Avalanche or Optimisms as L2 solutions to improve the performance and capabilities of L1 protocols; bridges for the interoperability and seamless asset exchange between networks; or oracles like Chainlink to leverage off-chain information on-chain. Each of these projects are designed to “do one thing right”. They are not interchangeable (i.e. you must either use one or the other), they can be combined to build complex functionalities, and this is the reason why I like to think about them as bricks more than layers of a stack. The same decentralized application can be deployed over Ethereum, leveraging a bridge with Binance to interact with assets held in the Binance chain, and use a Chainlink oracle to trigger actions according to off-chain events. You can combine the bricks to build your very own royal palace.
Access Tiles represent the interface between end users and decentralized applications. They offer users a gateway to interact with all of these decentralized protocols and systems. Some examples of Access Tiles are browsers and wallets responsible for managing user identities and offering an interface to interact with the low-level infrastructure; aggregators like Zapper that source information from several projects and systems to offer a global view of the ecosystem; or hosting (PaaS/Iaas-like) projects like Infura or Pinata which offer an entrypoint for DApps and developers to the different networks without them having to worry about operating their own nodes and infrastructure. Access Tiles are general tools, they are not specific for a project or an infrastructure, offering a general interface to access any project. They are your door to the blockchain (ok, and Web3) space.
Use-case Tiles can be seen as the “websites” of the blockchain Lego. They implement specific use cases leveraging protocol, infrastructure, and middleware bricks for their operation (more about the latter in a moment). They can be combined, but they usually offer a very specific use case, so they are consumed by users in isolation. We see here games like Axie Infinity; NFT/Metaverse proposals like Decentraland’s; DeFi financial services like Uniswap; or NFT platforms like OpenSea. All of them are specialized for their niche and solve a really specific user problem. They usually come with their own interface to interact with the service (minimizing the need of access pieces for the interaction).
And here is where I make a slight detour from Coinbase’s classification and introduce two new piece types:
Infrastructure Bricks (a.k.a L0 protocols) are specialized pieces that implement decentralized protocols and systems to complement blockchain applications. These pieces are more aligned with my own vision of what Web3 is deemed to be. Inside this group we find projects like IPFS or Filecoin for decentralized storage; the Graph protocol or IPLD as foundational pieces to source data from the Merkle forest; Swarm or XMTP for decentralized communication; or Celestia as a data availability solution. Infrastructure bricks offer the missing functionality many blockchain projects lack, helping them build consistent solutions (specially for less financial and more cloud-based use cases)
Finally, Middleware Bricks are general purpose projects and protocols built to abstract complex functionalities over simple API/interface for others to use in more complex use cases. Some important middleware bricks out there are frameworks like OpenZeppelin, decentralized identity and naming solutions like ENS, Unstoppable Domains, Serto and Veramo (former uPort); or every DeFi project and protocol providing staking, lending, token swapping, etc. The DeFi ecosystem and its projects are a good example of a box of protocol bricks that can be combined to create really complex financial use cases (take flash loans as an example). Unfortunately, this is out of the scope of this article, and if I may, I will leave this discussion for some other time.
It may have come obvious to you while you were reading about these pieces of the blockchain Lego, but let me make it explicit: throughout the description I’ve used tiles to describe pieces that are closer to end-users and less prone to be combined to build the substrate for a more complex functionality. Bricks, on the other hand, are general building blocks “ready-to-combine” for whatever you need to build (see image below for the visual difference between tiles and bricks).
Two important Protocol Bricks
In some of my previous publications I’ve been writing a lot about L0, L1 and L2, but I’ve been neglecting two very important building blocks from the blockchain Lego: oracles and bridges.
Blockchain Bridges
Blockchain bridges are protocols implemented to allow the transfer of tokens and/or arbitrary data from one blockchain network to another. They are a key piece to achieve the interoperability between different blockchain systems, and their state. Blockchain networks connected through a bridge can be of a really different nature: they can target different smart contract technologies (or none), run a different consensus algorithm, and store their state with different formats.
There are several ways of implementing bridges, but they can all be classified into two main groups:
Centralized bridges that rely on trusting a small number (federation) of nodes to orchestrate the exchange. Users delegate their trust in a set of centralized players that can interact with the two chain bridges and handle the freezing of the asset in one side and the corresponding minting in the other, as well as the ownership exchange. These implementations are usually fast and convenient, but are more vulnerable to attacks due to the small number of participants involved in the protocol (as reported in recent attacks to centralized bridges).
Trustless bridges do not require a centralized infrastructure to operate. They are usually implemented through a decentralized protocol that runs a consensus over a two-phase commit, i.e. it performs the freezing and minting mentioned above in a decentralized manner through a set of smart contracts.
Regardless of their flavor and their current utility, they may not be the definite interoperability solution, as already suggested by Vitalik.
Bridges are not only used to interconnect blockchain networks, but also to connect blockchains with data in the real world. But instead of calling them off-chain bridges, we call them oracles.
Blockchain Oracles
Oracles build bridges between the state in blockchain networks (or smart contracts) and the outside world. These systems send and verify real-world data (like the real-time price of a stock, or the weather on the moon) and inject this data inside a blockchain network. Oracles are generally used to start on-chain events triggered by real-world occurrences.
But if blockchains only store validated and verified data, how can an oracle ensure that the data being injected in a blockchain is legit? It really depends on the implementation of the oracle. The most common approach (and the one implemented by projects like Chainlink) is through decentralized oracles. Decentralized oracles implement a protocol where users are incentivized to submit and verify the data that is being injected in the blockchain. Similarly to how proof-of-stake works, where validators proposing or voting new blocks are penalized if the block is invalid, users in decentralized oracles are rewarded and penalized according to if the data injected (and verified) was correct or not. For new data entering the blockchain to be accepted, quorum must be reached by a majority (or minimum number) of participants voting the data as legit.
As it happened with on-chain bridges, oracles are a key requirement for the implementation of more complex real-world use cases leveraging blockchains, as they allow the interaction with traditional databases and services out of the world of blockchains (where data can’t be trusted).
Wrapping up!
The blockchain space looks more like a Lego than a stack, where one can combine the available pieces to build whatever they want, need, or dream. In this article I tried to illustrate the different pieces that we can currently find in the blockchain box, zooming in into bridges and oracles, two important pieces for the current state of affairs. However, blockchains and the pieces of this Lego are just a really smart part of the Web3 universe full of many more incredible pieces. Winter may be coming to the markets, but who cares! I can’t wait to see what is the next thing to be“buidl” using all of these Lego pieces.