Subscribe to Dino
DinoLight nodes and their benefits
Originally published on March 8th, 2023. Special thanks to those who reviewed the article and offered feedback: Sreeram Kannan (@sreeramkannan) Toghrul Maharramov (@toghrulmaharram) Dubbelosix (@dubbel06) Polynya (@apolynya) Hasu (@hasufl) Ryan Berckmans (@ryanberckmans)Overview of blockchain nodesBefore we discuss light nodes, let’s put them into context with an overview of blockchain nodes more broadly. Typically, blockchain nodes are thought about as:Validator nodesFull nodesLight nodes (A...
DinoMinimum viable blockchains
Originally published on September 5th, 2022The minimum viable product (MVP), a concept popularized by Steve Blank and Eric Reiss, has dominated startup culture for almost 20 years. An MVP is “a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.”If this sounds like a simple and obvious idea, that’s because it is. But it’s also profound and overlooked by most entrepreneurs. I won’t get into the MVP idea, (...
<100 subscribers
DinoLight nodes and their benefits
Originally published on March 8th, 2023. Special thanks to those who reviewed the article and offered feedback: Sreeram Kannan (@sreeramkannan) Toghrul Maharramov (@toghrulmaharram) Dubbelosix (@dubbel06) Polynya (@apolynya) Hasu (@hasufl) Ryan Berckmans (@ryanberckmans)Overview of blockchain nodesBefore we discuss light nodes, let’s put them into context with an overview of blockchain nodes more broadly. Typically, blockchain nodes are thought about as:Validator nodesFull nodesLight nodes (A...
DinoMinimum viable blockchains
Originally published on September 5th, 2022The minimum viable product (MVP), a concept popularized by Steve Blank and Eric Reiss, has dominated startup culture for almost 20 years. An MVP is “a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.”If this sounds like a simple and obvious idea, that’s because it is. But it’s also profound and overlooked by most entrepreneurs. I won’t get into the MVP idea, (...
Share Dialog
Share Dialog
Originally published on July 19th, 2022
In order to understand modular blockchains, we must first understand the concept of “modularity”.
The word modularity can be used in a number of ways, but it generally refers to the degree to which a system is composed of separate parts or “modules”.
In some cases, modularity is used to describe the physical separation of parts within a system. For example, a modular computer system is one in which the various parts are housed in separate units that can be easily connected and disconnected.
In other cases, modularity refers to the logical separation of parts within a system. For example, a modular software program is one in which the various functions are organized into separate modules that can be executed independently.
Modularity has many advantages. It makes systems easier to design, build, maintain and customize to meet the needs of a particular user or application.
In his talk at ETHDenver, Lane Rettig walks through modular systems we deal with every day - ranging from university curricula and music to the human body and brain.
Lane does a great job so I won’t go into most of his examples (I recommend watching his talk!), but it is worth emphasizing how modularity is not just a technology concept and has proven to successfully scale all facets of our lives.
The one example I will go further into, monolithic vs. microservice architectures, builds upon the modular software idea that we touched on earlier in the article and nicely segues into blockchains.
Applications used to be built as monoliths (think about monolithic applications as big blobs of code) and were hard to scale.
Let’s use a simple ecommerce example borrowed from this tutorial. The main functions of the ecommerce application are Search, Payments, and Reviews / Ratings. All three functions are bundled together in one big blob of code running on one instance.
If the ecommerce store gets popular, the engineers must run more instances that each replicate the big blob of code.
But what happens if Search and Payments grow 100x while Reviews / Ratings only grows 10x?
The engineers would still need to replicate the code for Reviews / Ratings 100x, even though it is unnecessary, because the functions are bundled together.
This is a hypothetical example but Amazon and companies like it faced similar problems in the early 2000’s. “Development delays, coding challenges, and service interdependencies inhibited Amazon’s ability to meet the scaling requirements of its rapidly growing customer base.”
In response, the industry shifted towards microservices. There are countless examples of top-tier tech companies who use them including Netflix, Uber and Google. In fact, Google open-sourced Kubernetes based on their internal microservice management software, which has become the industry standard and is helping all types of companies leverage microservices.
If our hypothetical ecommerce application transitioned to using microservices, the architecture would look something like the diagram below where all three functions scale independently. The application would be easier and more cost efficient to operate.
The goal of this section is to make one point: web2 applications we use today are already modular!
Why isn’t this obvious? Well, web2 end users were never concerned with software architecture. Architecture was left to the engineers and end users just worried about application utility and experience.
Since web3 financializes backend infrastructure and blends it with governance and culture, a new audience of people are thinking about it.
https://twitter.com/FEhrsam/status/1538971044916101121?s=20
Ok, so we’ve discussed modularity and a few real-world examples. Now let’s explore modular blockchains.
The ideas behind modular blockchains (as well as the term itself) were introduced in 2019 by Mustafa Al-Bassam, co-founder of Celestia. In the article he states “Our long-term vision is to help build a blockchain ecosystem with modular data availability layers and execution engines that can be integrated together. We believe that is the next generation of scalable blockchain architectures.”
Modular blockchains entered the zeitgeist, however, in late 2021 when blog posts by Polynya, a pseudonymous crypto expert, started gaining attention. This is the first post I was made aware of, seemingly inspired by a deep understanding of computer chip design.
People quickly built on this foundation including Anthony Sassano, Bankless, and of course, Celestia. Celestia has since taken the modular blockchain narrative to new heights, hosting conferences and a library of educational resources.
The industry now (mostly) agrees that modular architectures are the way forward.
So, what is a modular blockchain and what is its predecessor, the monolithic blockchain?
The main idea is no different than the monolithic vs. microservice architectures we discussed earlier. Monolithic blockchains are big blobs of code that bundle blockchain functions together while modular blockchains disaggregate functions into layers.
Let’s explore the layers from a high-level view that offers an easy mental model and a low-level view that offers a more nuanced perspective.
We will begin with an analogy borrowed from this Polygon article.
When you buy a cup of coffee, it’s unlikely that you give the barista your bank account information. Instead, you might swipe a credit card.
After you swipe the card, your credit card company queues up the transaction with other recent transactions and periodically “settles” them with your bank. This means your bank doesn’t actually need to process individual transactions. Instead, it acts as the arbiter of truth and simply compares your total debits and credits whenever it interacts with your credit card company.
This relationship involves two layers:
Execution layer (credit card)
Settlement layer (bank)
Modular blockchains are quite similar. Consider two main layers:
Execution layer (rollup)
Settlement layer (Ethereum, for example)
Let’s now assume you are buying that cup of coffee using a web3 payment application.
After you make the payment (likely using a QR code instead of a card) the rollup queues up your transaction with other recent transactions and, as you might have guessed, periodically “settles” them with Ethereum.
What does this mean?
On the execution layer, assuming it is a rollup that supports arbitrary smart contracts, your transactions are ordered and executed with all types of other transactions. Rollup network participants then use fancy math to either prove that transactions were executed correctly or that transactions were executed incorrectly. It is done in a way that settlement layer (Ethereum in this case) smart contracts can verify with near certainty.
To make this concrete, assume over a period of time the rollup executes 100 transactions and over another period of time it executes 1000 transactions. Ethereum would do the same amount of work in both scenarios, as it only needs to execute one transaction each time it verifies a batch of transactions. This is important because the less execution work Ethereum needs to do, the more decentralized it can stay.
Once again, this section is oversimplified and meant to provide an easy way to think about blockchain layers. The next section is more comprehensive.
While we’re at it - another easy mental model is a ZIP file!
https://twitter.com/pseudotheos/status/1516462479735468048?s=20
Time to go deeper into the weeds.
In the previous section we discussed two main layers:
Execution layer
Settlement layer
Let’s reframe this and introduce two additional layers:
Execution layer
Settlement layer
Consensus layer
Data availability layer
Where did the two new layers come from?
In the previous section I excluded consensus and data availability, considering them parts of the settlement layer. This is a common simplification and design pattern, as splitting up settlement / consensus / data availability often creates much more complex security assumptions. That said, everything comes with tradeoffs (e.g. security vs. flexibility) and developers are experimenting with all types of designs.
Peter Watts posted an awesome graphic to visualize different combinations and it's still just a tiny subset of what’s possible.
By this point, if you are technically oriented, you might be wondering what each layer does at a more granular level.
For that, I’ll point you to a few fantastic resources and you can venture down the rabbit hole:
Learn Modular by Celestia
Modular Blockchains: A Deep Dive by Volt Capital
The Hitchhiker's Guide to Ethereum by Jon Charbonneau
There are aspects of the modular stack I’d like to dive deeper into, but I’ll leave them for future articles. Feel free to message me with suggestions too!
We are still at the beginning of the modular revolution.
It’s clear that modular architecture is a technically superior way to scale blockchains but it’s still unclear what the dominant design(s) will be. It’ll be fun to watch a thousand flowers bloom over the next few years as we figure out what works best.
Let the games begin!
Originally published on July 19th, 2022
In order to understand modular blockchains, we must first understand the concept of “modularity”.
The word modularity can be used in a number of ways, but it generally refers to the degree to which a system is composed of separate parts or “modules”.
In some cases, modularity is used to describe the physical separation of parts within a system. For example, a modular computer system is one in which the various parts are housed in separate units that can be easily connected and disconnected.
In other cases, modularity refers to the logical separation of parts within a system. For example, a modular software program is one in which the various functions are organized into separate modules that can be executed independently.
Modularity has many advantages. It makes systems easier to design, build, maintain and customize to meet the needs of a particular user or application.
In his talk at ETHDenver, Lane Rettig walks through modular systems we deal with every day - ranging from university curricula and music to the human body and brain.
Lane does a great job so I won’t go into most of his examples (I recommend watching his talk!), but it is worth emphasizing how modularity is not just a technology concept and has proven to successfully scale all facets of our lives.
The one example I will go further into, monolithic vs. microservice architectures, builds upon the modular software idea that we touched on earlier in the article and nicely segues into blockchains.
Applications used to be built as monoliths (think about monolithic applications as big blobs of code) and were hard to scale.
Let’s use a simple ecommerce example borrowed from this tutorial. The main functions of the ecommerce application are Search, Payments, and Reviews / Ratings. All three functions are bundled together in one big blob of code running on one instance.
If the ecommerce store gets popular, the engineers must run more instances that each replicate the big blob of code.
But what happens if Search and Payments grow 100x while Reviews / Ratings only grows 10x?
The engineers would still need to replicate the code for Reviews / Ratings 100x, even though it is unnecessary, because the functions are bundled together.
This is a hypothetical example but Amazon and companies like it faced similar problems in the early 2000’s. “Development delays, coding challenges, and service interdependencies inhibited Amazon’s ability to meet the scaling requirements of its rapidly growing customer base.”
In response, the industry shifted towards microservices. There are countless examples of top-tier tech companies who use them including Netflix, Uber and Google. In fact, Google open-sourced Kubernetes based on their internal microservice management software, which has become the industry standard and is helping all types of companies leverage microservices.
If our hypothetical ecommerce application transitioned to using microservices, the architecture would look something like the diagram below where all three functions scale independently. The application would be easier and more cost efficient to operate.
The goal of this section is to make one point: web2 applications we use today are already modular!
Why isn’t this obvious? Well, web2 end users were never concerned with software architecture. Architecture was left to the engineers and end users just worried about application utility and experience.
Since web3 financializes backend infrastructure and blends it with governance and culture, a new audience of people are thinking about it.
https://twitter.com/FEhrsam/status/1538971044916101121?s=20
Ok, so we’ve discussed modularity and a few real-world examples. Now let’s explore modular blockchains.
The ideas behind modular blockchains (as well as the term itself) were introduced in 2019 by Mustafa Al-Bassam, co-founder of Celestia. In the article he states “Our long-term vision is to help build a blockchain ecosystem with modular data availability layers and execution engines that can be integrated together. We believe that is the next generation of scalable blockchain architectures.”
Modular blockchains entered the zeitgeist, however, in late 2021 when blog posts by Polynya, a pseudonymous crypto expert, started gaining attention. This is the first post I was made aware of, seemingly inspired by a deep understanding of computer chip design.
People quickly built on this foundation including Anthony Sassano, Bankless, and of course, Celestia. Celestia has since taken the modular blockchain narrative to new heights, hosting conferences and a library of educational resources.
The industry now (mostly) agrees that modular architectures are the way forward.
So, what is a modular blockchain and what is its predecessor, the monolithic blockchain?
The main idea is no different than the monolithic vs. microservice architectures we discussed earlier. Monolithic blockchains are big blobs of code that bundle blockchain functions together while modular blockchains disaggregate functions into layers.
Let’s explore the layers from a high-level view that offers an easy mental model and a low-level view that offers a more nuanced perspective.
We will begin with an analogy borrowed from this Polygon article.
When you buy a cup of coffee, it’s unlikely that you give the barista your bank account information. Instead, you might swipe a credit card.
After you swipe the card, your credit card company queues up the transaction with other recent transactions and periodically “settles” them with your bank. This means your bank doesn’t actually need to process individual transactions. Instead, it acts as the arbiter of truth and simply compares your total debits and credits whenever it interacts with your credit card company.
This relationship involves two layers:
Execution layer (credit card)
Settlement layer (bank)
Modular blockchains are quite similar. Consider two main layers:
Execution layer (rollup)
Settlement layer (Ethereum, for example)
Let’s now assume you are buying that cup of coffee using a web3 payment application.
After you make the payment (likely using a QR code instead of a card) the rollup queues up your transaction with other recent transactions and, as you might have guessed, periodically “settles” them with Ethereum.
What does this mean?
On the execution layer, assuming it is a rollup that supports arbitrary smart contracts, your transactions are ordered and executed with all types of other transactions. Rollup network participants then use fancy math to either prove that transactions were executed correctly or that transactions were executed incorrectly. It is done in a way that settlement layer (Ethereum in this case) smart contracts can verify with near certainty.
To make this concrete, assume over a period of time the rollup executes 100 transactions and over another period of time it executes 1000 transactions. Ethereum would do the same amount of work in both scenarios, as it only needs to execute one transaction each time it verifies a batch of transactions. This is important because the less execution work Ethereum needs to do, the more decentralized it can stay.
Once again, this section is oversimplified and meant to provide an easy way to think about blockchain layers. The next section is more comprehensive.
While we’re at it - another easy mental model is a ZIP file!
https://twitter.com/pseudotheos/status/1516462479735468048?s=20
Time to go deeper into the weeds.
In the previous section we discussed two main layers:
Execution layer
Settlement layer
Let’s reframe this and introduce two additional layers:
Execution layer
Settlement layer
Consensus layer
Data availability layer
Where did the two new layers come from?
In the previous section I excluded consensus and data availability, considering them parts of the settlement layer. This is a common simplification and design pattern, as splitting up settlement / consensus / data availability often creates much more complex security assumptions. That said, everything comes with tradeoffs (e.g. security vs. flexibility) and developers are experimenting with all types of designs.
Peter Watts posted an awesome graphic to visualize different combinations and it's still just a tiny subset of what’s possible.
By this point, if you are technically oriented, you might be wondering what each layer does at a more granular level.
For that, I’ll point you to a few fantastic resources and you can venture down the rabbit hole:
Learn Modular by Celestia
Modular Blockchains: A Deep Dive by Volt Capital
The Hitchhiker's Guide to Ethereum by Jon Charbonneau
There are aspects of the modular stack I’d like to dive deeper into, but I’ll leave them for future articles. Feel free to message me with suggestions too!
We are still at the beginning of the modular revolution.
It’s clear that modular architecture is a technically superior way to scale blockchains but it’s still unclear what the dominant design(s) will be. It’ll be fun to watch a thousand flowers bloom over the next few years as we figure out what works best.
Let the games begin!
No comments yet