EDIT: I've previously posted about both the merge and Sharding. All of these subjects are related and intertwined so I would really suggest you give them a quick read

Objectively speaking, Ethereum by far has the top-tier ecosystem on the market with some of our favorite projects and dApps built on it.

However, Ethereum is also infamous for its high gas fees, slow transactions, and overall lack of scalability and efficiency.

One of the major reasons behind this problem is “data availability” or more precisely the lack of it.

In order to explain what “data availability” is, we first need to talk about Ethereum nodes and how and where they store data. We also need to discuss L2s a little bit so I’ll try to make this as easy as possible for the average Joe to understand.

- What are Ethereum nodes?

Ethereum nodes are essentially a group of computers that keep a full and comprehensive record of every single activity that happens on the entire Ethereum blockchain.

This obviously takes up a HUGE amount of precious and expensive space and processing power which renders Ethereum quite inefficient.

The main issue here is that a lot of this stored data is not being used and will most likely never be used. But its still there non the less and will always be there even after merging and sharding are implemented.

- What is data availability?

Data availability as a concept and practice is not something new. It has been around for a while. But things get complicated when blockchains are involved and thus this concept on Ethereum is still new and not fully implemented.

Data availability is the practice of storing data off of the operating system or network (in this case, the Ethereum blockchain) and only presenting the needed data at the needed time.

Here’s a nice analogy:

Let’s say you work on a computer but that computer has so much data stored that it’s making it very slow and clunky in performance. You also realize that you don’t need ALL of the data at once yet you still want to keep that data just in case you ever needed it someday.

What you do is you end up storing said data on a designated computer or hard drive and only extract the information you need at the current moment thus relieving much of the strain on the computer you work on.

Now, this process is a bit more complicated when blockchains and the billions of dollars of transactions and assets on them are involved because there should always be irrefutable evidence that the stored data is indeed there and isn’t being tampered with.

This is where L2s get involved.

- How can L2s help with data availability?

After the merge is fully implemented and Sharding is introduced, L2s will gain a lot of extra throughput to process information and gain faster prover times.

As mentioned before, the Ethereum beacon chain itself won’t be scalable. This responsibility will fully lie on L2s some of which are already working on scaling solutions focused on data availability.

This is why I was focused on mentioning Polygon in all of my previous posts regarding the merge and sharding because they’re developing a data availability scaling solution (Polygon Avail) and they actually just released the testnet yesterday (it was part of the reason that made me compelled to write this post and explain the importance of data availability for the future of Ethereum

Scaling solutions like the one being developed by Polygon store all the massive counts of data off of the Ethereum chain and provide only the needed information at a given moment while still giving irrefutable proof that the entire compilation of the Ethereum database is indeed intact and untampered with.

- Conclusion?

When we talk about dank sharding, we’re actually talking about multiple upgrades but the most important of them all is indeed data availability.

If Ethereum wants to stay secure and decentralized but also fix the scalability problem, then data availability should be the main focus (and it is).

I hope I was able to explain the importance of data availability in a way that the average Ethereum user can understand without getting into so much technical detail.

As per usual, I’d love your feedback in the comments and would happily answer any questions there as well!