{%hackmd @alvatar/5k3vLNn2RgCaiNOipn7SXg %}

[\[BACK TO INDEX\]](index)

# Modular architectures and decentralization (what exactly is Data Availability for?)

Let's get something straight first ser: you can't scale the blockchain without sacrificing something. There is no free lunch. If a network claims to solve everything (decentralization, TPS, latency, security…) it is hiding something. This is a confusing topic for many people in the crypto industry. In this article I'll try to address the fundamental reasons why we want DA in first place.

## What is the objective?

We want everything: performance, decentralization, security. Just like the proverbial magic project that your favorite influencer is gonna dump on you. Mark these words: whatever you get, costs you something.

**Modular architectures are a way to get most of what we want, making some sacrifices that we are willing to make. They are not magical. They choose**

## So you want more transactions, without compromising decentralization?

Decentralization is such a contentious topic. You may have heard of the Nakamoto coefficient. It's a metric. It captures one of the aspects of decentralization, but it doesn't tell us much about the overall decentralization (and that's why is pig lipstick for blockchains). But seriously, the main reason why is a difficult topic to agree on is because decentralization is not about any particular property, but rather about the absence of one: centralization. This may be obvious but bear with me: what we care about is that there are no points or mechanisms of the design that can be seized by a single entity (or a small group) to gain disproportionate control. Here is the thing: whether caused by a new design feature, or a new social behavior emerging, a new device that can be abused for gaining centralizing power can emerge in unexpected ways. There are such disparate reasons for centralization as: a single LSD protocol (such as Lido's stETH) could accumulate too many validators; or some nodes accumulating most of the wealth over time via MEV; or the lack of a culture of people validating leading to very few entities controlling the network.

Here, we focus on one class of decentralization issues that sits at the bottom of them all: maintaining low hardware requirements. You may have heard of the Ethereum motto: every person should be able to validate the network with their laptop. Well, maybe you haven't because most people don't care about this if their token is pumping, but some engineers are actually trying to build something that outlasts a single bull run. The reason is that if we keep hardware requirements low, we make it possible for people to validate at home. If users can do this, and they can choose which node software to run (which is equivalent to choosing which chain to follow, since you don't do it yourself, right?), then users get to decide what is the source of truth and validate or simply follow that chain. This is the true objective of decentralization, the reason why we created blockchains in first place.

## It's all about verification!

Now, the problem arises: as the use of the blockchain increases, if we want to keep nodes small, then not all computation can be done by all nodes, and not all data can be stored by all nodes. We need to compromise. And it is under this light, that we realize that the key for scalable decentralization is that verification needs to be cheap and widespread. Everyone (that is, every user with their phone) needs to be able to:

- Verify that data is **accessible** (ie. availability)
- Verify that the data is **correct** (ie. correctness)

Think of it like this: instead of downloading the data, we verify that it is possible to do so, and instead of executing every transaction, we verify that someone has done it correctly. That's it. These are the two core ideas at the center of modular architectures.

On the flip side, while less than ideal, computation and production of data can be centralized. At least, it gives us room to isolate the parts with less risk (say, block building), and buy us time to design decentralized solutions for the future. Ethereum L2s (Arbitrum, Optimism, ZK Sync…) are an example of this, since they are basically centralized transaction-producing devices (at least for now) that employ Ethereum for everyone to see and agree on what has happened within them.

This is what you, as a user of the blockchain, should care about (at a minimum). If a blockchain can provide you with these guarantees, we can figure out ways in which this can be achieved in the most scalable way possible. This is the path that Ethereum is following, and the source of all the engineering complexity and research effort.

## Modular, Multi-chain or High-performance?

Let's stop for a second. Here is a thought that may have come to your mind: couldn't we just split the blockchain and let different nodes do different parts of the work? This is indeed what most blockchains thought of doing for scaling in the past, (it was the original design of Ethereum for scaling). This is a group of techniques that we can refer to as horizontal scaling. It encompasses designs such as the Cosmos multichain (each app chain handles its own state), sharding in its multiple flavors (parachains, rollups, L1 sharding…), or the use of committees.

One potential problem of many of these schemes is that when you split the data and execution into separate worlds, you tend to reduce the security of the system by trusting only a portion of nodes that have your data (instead of the entire set).

There are also other alternatives to scaling, like high-performance L1s (such as Solana, Aptos, Sui) or [intra-node sharding](https://arxiv.org/abs/1907.03331), but they substantially increase the requirements of the validators, making them expensive to run and necessarily in data centers.

In the first case we sacrifice security, in the second we sacrifice decentralization. There is a case for all those alternative designs, but is not a case for decentralization and large-scale security. Those blockchains are a different design space, and as such will probably be better for some use cases and worse for others. There are great ideas in all those blockchains and architectures.

## So what do we actually need in a modular L1?

In a modular architecture, we are aiming at reducing the responsibilities of each layer, in order to tackle scalability without reducing decentralization. Current modular designs are based on the idea that you only need to guarantee a limited number of things to provide the fundamental benefits of a large-scale decentralized blockchain. What the collective of nodes in a blockchain need to make sure is that:

1. **The network agrees on the order of the proposed blocks.** This is the consensus algorithm. It can be probabilistic (we gain confidence that a chain is correct over time) or deterministic (we can be 100% sure of the finalization of the chain. It generally involves selecting a leader that will propose a block (also either probabilistically like in Proof-of-Work, or deterministically like in BFT Proof-of-Stake). The selection of these leaders, and thus the production of blocks, follows an order predetermined by the entire network (PoW is slightly different here but the outcome is the same).
2. **The block has been proposed by the rightful leader.** What matters here is that it has been proposed (and signed), not necessarily built by the leader. This is a deep topic in itself, but in essence, when these two steps are separated you could introduce mechanisms like Ethereum's PBS (Proposer/Builder separation), or having a decentralizing block builder (so that no single entity has the possibility of extracting all MEV).
3. **The leader has disseminated the block to the network.** Somehow, we need to prove that the node has been fully disseminated. Normally, this is done by sending a full copy of the entire block to all the nodes. However, this is something where modular architectures find an opportunity for optimization, if by design we don't need all the nodes to have the entire block.
4. **The network as a whole has the ability to reconstruct the block.** Finally, it is important that we are certain that we could retrieve the data in the blockchain. Whether we need to contact a single node or several, we want to have a guarantee that it's possible, so we can reconstruct all the data an verify ourselves. Note that we don't really need to reconstruct the block, just make sure that is possible to do so.

The savvy reader may realize that if the nodes just check if the data can be reconstructed, but they don't do it, that means that nodes don't really get to see all the blocks, so how can they check that everything is correct?. Well, that's the trick: they don't. By not doing this work, the network can scale, process more transactions as a whole, without the nodes having to increase neither their storage, their bandwidth usage or their compute power. This in turn means that **whoever puts the data is in charge of proving the validity of the transactions** (hint: this is what rollups do).

## The Availability part

So now we come to the crux of the question: Data Availability. By it, we refer to the mechanisms that focus on solving the points (3) and (4) of the previous list. To be clear, all L1s need to do (1) and (2). What is special about the last two points is that by reducing the requirement to **just knowing that the data is available (ie could be downloaded by anyone)**, we make the system much more efficient, as we don't need to actually download all the data anymore.

If at this point we know just that the data is there, but we know nothing about the data itself, what does this buy us? First of all, that data is the blockchain transactions that you are used to in regular monolithic blockchains, nothing more, nothing less. However, this is now the responsibility of the layers above (generally you would think of rollups), which do all the computations. But this is a topic for another post.

## The Sampling part

Remember how we said that we need the users to be able to do two things, availability and correctness? This is how users ultimately decide which blockchain to follow and consider it the source of truth. They are both required, but actually availability comes first. Just think of it: if the block is not available there is nothing to verify, and we already know that the blockchain cannot be trusted.

This is what the Sampling part of the *Data Availability Sampling* techniques does: it allows light clients (ie you with your phone for example), to check if the data is there without downloading it. As I said before, no single node in the network now holds the entire data, but only chunks of it that can be reconstructed. So the intuition is actually quite simple: we ask several nodes for different parts of the data, and if we receive them correctly we can assume that the rest is also there. This is done with some math and clever mechanisms that gives us extremely high confidence that we can rebuild the block if we keep asking more nodes (I will probably describe these mechanisms in another post). The key property of the data that enables this is that we only need to be able to obtain 50% of the data in order to reconstruct the entire block (thanks to Error-Correcting Codes). Making sure that 50% of the data is available is much easier to do than checking that 100% of the data is available. See [here](https://www.paradigm.xyz/2022/08/das) for a deeper explanation.

Keep in mind that this is only discussing the part in which light clients check the blockchain network to decide whether to trust it or not. Nodes can use this or another mechanism for ensuring the availability (such as Verifiable Information Dispersal).

It's all about giving the power to as many entities as possible to decide what is the correct chain. That's what gives us the strongest guarantee of decentralization.


## Light nodes: power to the users

A very important thing to mention is that modularity may or may not bring another aspect that is known for: light nodes. Light nodes are fully-verifying user-facing clients that have now the power to eliminate trust assumptions on the chain validators. By this we refer to **eliminating the honest majority assumption in blockchains**.

Let me elaborate. When we use blockchains we are accustomed to assume (maybe unknowingly so) that a majority of nodes will behave honestly. In other words, we trust that at least a majority (defined differently under different protocols) will be doing their job correctly (and not lying, hiding data or changing the rules of the protocol). The reason for this is that so far, the majority of blockchain clients rely on this trust, since they are unable to verify everything by themselves (as it's too costly to do all the work that validators do). But modular architectures (DAS + validity proofs) enable us to design light clients that do not need to rely on this. These clients can now fully validate the chain with minimal cost and zero trust on the nodes.

As a consequence, the power that validators have over the users is reverted, as they cannot lie to them. A fully-verifying light client means that while validators do most of the work, users have all the information to know if they are doing it correctly or not, and if they detect any problem they all can stop following the chain immediately. This early detection mechanism is all you need to both deter the validator from misbehaving, or at least from them to get away with it if they choose to do so.

A world of _rules without rulers_: isn't this what we wanted in first place?