Can Moon Math Save Crypto?
In this article, I will give an overview and evaluation of key current and planned solutions to the biggest problems in the cryptocurrency space today. I covered what (and why) exactly these problems are in depth in my previous article.
This article contains the third part of my four-part mega-article, Defusing Crypto’s Ticking Time Bomb. I have also turned Parts 1 and 2, as well as Part 4 into separate articles, if you wish to read them separately.
Here, I will focus on the solutions proposed by Ethereum, which are currently being implemented — as well as There are plenty of others who have covered these topics individually in greater depth than I could hope to manage, but here I am attempting to put them all in one place. So forgive me in advance if I leave things out.
If you could click and hold the little clapping icon👏 on the bottom of your screen, you will be able to give this article up to 50 claps. I would appreciate you doing so, as this took a lot of time and effort to create. Enjoy!
Ethereum
Because I can’t cover every blockchain on Earth, I’m going to (mostly) go through solutions on the Ethereum roadmap. Ethereum has an extremely comprehensive roadmap which really tries to address many of the problems I have outlined — and many other blockchains are also pursuing these same solutions — so it should more than suffice for a broad overview of the solution space. If you’re an Ethereum maxi, please go easy on me if I leave things out!
A reminder that some of the key problems to fix are:
- People will stop running nodes as chain size grows & storage costs increase, so chain scalability is constrained by the need to preserve the p2p network (tragedy of the commons problem)
- All non-mining/staking nodes are volunteers, and the work they perform (routing work, data storage, transaction validation) is not economically incentivised, leading to cutting corners and not performing essential tasks (free rider problem)
Let’s dive into it.
Statelessness
To learn more about statelessness, see: Vitalik Article 1, Vitalik Article 2, Polynya Article 1
“State refers to information that a node must hold in order to be able to process new incoming blocks and transactions. It is typically contrasted with history, information about past events which can be held for later rebroadcasting and archiving purposes, but is not strictly needed to continue to process the chain.”
- Vitalik Buterin [Article 1]
Statelessness is the idea that we can get people to validate blocks using light clients that don’t store state. This way, the argument goes, we can have more people validating transactions and subsequently improve decentralisation in spite of a growing chain size.
One version of statelessness is called weak statelessness — where full nodes fully verify blocks and provide proofs called ‘witnesses’ with each block which light clients can then verify. When full nodes come across an invalid block, they will send what are called fraud proofs to light clients, giving them only enough information to reject the invalid block. The argument for weak statelessness is that this fraud-proof mechanism only requires one honest full node to send out fraud proofs (packages of data) to light clients in order to have the network reject invalid blocks. Though I will note that in this hypothetical scenario, the bandwidth costs on that single honest node broadcasting the fraud proof to all other nodes would be significant — and this desired behaviour is not something the full node is paid for doing. So we would be trusting altruistic behaviour in the face of adverse incentives (which header-first mining in Bitcoin — and basic logic — proves is not an effective strategy).
The second version of statelessness is called strong statelessness, where no nodes store the full blockchain state and transaction senders are responsible for storing state that is needed to generate proofs for accounts relevant to them. Strong statelessness has its difficulties, however — and would shift a lot of responsibility to the users, rather than have the network solve the problem. Whether this is a good or bad thing seems to reduce down to a subjective value judgement.
“Strong statelessness is a very “elegant” solution in that it completely moves responsibility to the users, though to maintain a good user experience in practice there would need to be some kind of protocol created to help maintain state for users that are not personally running nodes or that need to interact with some unexpected account. The challenges with making such protocols are significant. Additionally, all statelessness increases the data bandwidth requirements of the network, and strong statelessness requires transactions to declare which accounts and storage keys they are interacting with (this notion is called access lists).”
Vitalik Buterin [Article 1]
It is important to note that neither of these approaches solve the underlying problem of incentivising people to actually run lightweight nodes and verify transactions for the network. The goal here was to bolster the p2p network by reducing data storage requirements for nodes, but even if statelessness makes this technically possible — it doesn’t make it incentivised behaviour. Remember game theory and the free rider problem — “if everybody else is doing it, then I don’t need to” is exactly how markets fail to provide and maintain public goods.
Yes, it would be good if people ran light nodes. But “you should do this thing because it’s good, except we won’t pay you to do it and nothing bad happens to you if you don’t do it” is the same reason people don’t go around picking up other people’s rubbish. It’s the *exact* same reason people download torrents but don’t seed them to others, a phenomenon called ‘leeching’ [see examples 1, 2, 3, 4]. It’s the same reason that there’s always someone who doesn’t do any work in the group assignment. It’s still ultimately a volunteer based solution to conserving the p2p network at scale.
It’s basic game theory and human nature.
Weak statelessness also fails to solve the problem that somebody, somewhere has to incur the costs of storing the growing chain state, and is not compensated for doing so. Fraud proofs still need to come from someone who actually stores the entire chain state and can fully verify blocks instead of just doing header-only validation. This ‘someone’ is full nodes. Because the chain state just keeps on growing, so too will data storage and bandwidth costs for full nodes over time. Even if one ran a staking node, the consensus-collected staking payout has nothing to do with data storage and bandwidth costs. There is nothing which makes staking rewards necessarily cover these costs, and should the token price fall sufficiently (or not appreciate fast enough) and render full nodes unprofitable — what then? Over time, the blockchain state continues growing — which means node operating costs are rising and the real p2p network doing all the heavy lifting is still being degraded.
I have some additional unanswered questions about spam attacks and sybil resistance related to weak statelessness (e.g. what happens if light nodes are spammed with valid fraud proofs, or if attackers set up sybil light nodes) — though I’m sure smarter people than I have figured those things out. There are also debates about the extent to which light nodes actually contribute to the p2p network more broadly, given that they rely wholly on full nodes to function. This is similar to debates about weak subjectivity, and how non-archive nodes (most full nodes on every non Bitcoin chain) in the first place require more trust than archive nodes.
Under strong statelessness, the chain state is stored in a more distributed way by users — meaning users incur the cost of storing relevant data. This is a more viable solution, but is not without its own issues. Bandwidth costs rise for users, and data availability/redundancy issues would increase. There also becomes a need to create a protocol which helps store and manages relevant state for users — which is what we were wanting the blockchain to do in the first place. Funding the creation and updating of such services for users may also run us into another public goods problem. Yet, to be honest, one of the biggest problems I see with users storing all data which is relevant to them at any given time is that it feels like a massive downgrade from the web2 model. One could also easily imagine a world where to overcome this, the average person outsources data-storage responsibilities to centralised companies which introduce closure around data flows in order to provide their services. I mean, we did it with storing our money in banks.
Whether we want a relatively large, distributed and decentralised set of archive nodes so that we can access historical data (which we inevitably will, for a multitude of reasons) — or we just want the ever-growing state size of the blockchain to be stored by nodes — then people are going to need to incur the costs of providing those services. Making the average node not need to store state or history doesn’t change this fact, or incentivise the provision of infrastructure to achieve those ends. It just shifts the burden of doing so onto other network participants. In weak statelessness, full nodes bear all the costs. In strong statelessness, it is users and whoever builds the infrastructure to help users store relevant data. Both situations are less than ideal — and in both cases, archive nodes are not incentivised whatsoever.
If the chain’s data is going to exist, parties still need to bear the costs of storing it — and so long as they are not paid for this, expenses will grow at scale. Private businesses will only provide data services if they can monetise data flows and introduce closure. We haven’t gotten very far.
“In reality, “stateless” does not really mean “no state”! What it actually means is that you made state someone else’s problem…”
Ben Edginton, ‘What’s new in Eth2'
State Expiry
In a similar vein to statelessness, we have state expiry. State expiry is when blockchain state that has not been accessed for a certain period of time is allowed to be dropped by full nodes (no longer counted as part of the blockchain’s ‘state’).
“There are many choices for the exact mechanic for how state can be renewed (eg. pre-paying a “rent” fee, or simply touching the account), but the general principle is that unless a state object is renewed explicitly, it is inactivated in some way. Hence, any action that creates new state objects (or refreshes existing ones) only burdens other nodes for a limited period of time, and not as is currently the case forever.”
Vitalik Buterin [Article 1]
State which is deemed expired can still be resurrected, however! It can be resurrected using the same sort of methodology used in statelessness — by somebody providing a proof (a ‘witness’) showing that the data is part of the inactive state. However, as Vitalik mentions: “In order to be able to generate such proofs, users themselves would need to store and maintain at least the part of the inactive state that corresponds to inactive state objects that they care about.”
In my opinion, state expiry seems like one of the solutions to state bloat which would actually impact the core problem in a desirable way. It’s a move in the right direction, because it actually serves as a counteracting force (though not necessarily enough of a counteracting force) to the growing chain size.
However, just like with statelessness, it does not suddenly incentivise the provision and maintenance of archive nodes which store historical state (this would still remain a problem) and full nodes on the p2p network which store the current state of the blockchain. Further, asking users to start storing their own data and to manually reactivate expired state is not really the most elegant solution to the problem of state bloat.
Alternatively, some suggest that we should just offload expired state to data storage blockchains like Arweave and Filecoin.
“Users can revive expired data by providing a witness proof and paying gas to have the corresponding data reappended to the active tree. What about expired state? […] This will almost certainly be very, very expensive, so we’ll need some sort of infrastructure for expired state. I believe Solana is exploring using Arweave for similar state rent schemes, though I wasn’t able to find any details. IPFS, BitTorrent, Filecoin and others are all options.”
Polynya, ‘Statelessness + State Expiry’
There are still deeper, incentive level problems here which technical solutions are not fixing. Just because state gets expired, it doesn’t mean that the amount of state being stored by full nodes is suddenly a sustainable amount which volunteers would be willing to incur the costs of storing. What if state grows faster than it expires by an amount that the cost of running a full node continually increases? Ethereum’s state is already increasing at an accelerating rate — why would this trend continue as adoption and usage grows? And even if we were to expire so much state that the blockchain size remained constant (an idea we can discuss later), we would still have the problem that because the entire peer to peer network consists of volunteers, the chain can’t scale.
Ultimately, full and archive nodes are still volunteers and are still not paid for data storage and bandwidth — and that is why we are trying to reduce the state size in the first place. And even though users could pay a rent-style fee when old state gets revived, there would be no fee-pricing mechanism which accounts for the real-world data storage costs reviving state imposes on full nodes. And the fee would not go to the peer to peer network storing the data, but to miners and stakers, anyway! If expired state is being revived for a certain fee, that fee should bear relevance to the cost of storing and retrieving that data — and actually be paid to those incurring it. The volunteer problem, scalability problem and data storage/pricing problem are not solved here.
In addition to all this, there is also a LOT of complexity in the implementation and integration of state expiry (and statelessness) into the Etheruem blockchain — see here for more. It gets really complicated, and a lot of decisions and tradeoffs will need to be made.
Sharding
One of the most popular methods for achieving scalability without moving transactions (data) off-chain is sharding. Sharding is (essentially) when you split the blockchain into multiple parallel blockchains (‘shards’), and they each contribute data to blocks that go on the chain. Each shard can process as much (or more) data as the entire blockchain could previously, leading to higher throughput (scalability).
To quote Vitalik:
“Sharding fundamentally gets around the above limitations, because it decouples the data contained on a blockchain from the data that a single node needs to process and store. Instead of nodes verifying blocks by personally downloading and executing them, they use advanced mathematical and cryptographic techniques to verify blocks indirectly.
As a result, sharded blockchains can safely have very high levels of transaction throughput that non-sharded blockchains cannot. This does require a lot of cryptographic cleverness in creating efficient substitutes for naive full validation that successfully reject invalid blocks, but it can be done: the theory is well-established and proof-of-concepts based on draft specifications are already being worked on.”
Vitalik Buterin, ‘The Limits to Blockchain Scalability’
This sounds great! Scalability on the base layer! In fact, sharding is such an appealing solution to scaling that it is also being implemented by Ethereum, Near, Elrond, Cardano, Tezos, Polkadot, Zilliqa and many other blockchains — albeit with differences in type and implementation.
Except, as economist Thomas Sowell wisely said — and as you should know by now: “there are no solutions, only tradeoffs.” So what’s the catch?
In the same article, Vitalik cites two major limits to scalability through sharding — ‘minimum user count’ and ‘history retrievability’. He explains it more simply and concisely than I ever could, so I’m just going to quote these parts of his article directly:
In short:
- When you shard, you split up the node set across shards. This makes each shard equivalent to a blockchain with a smaller total set of nodes. If you do this too much, then problems start to arise.
- Data sharding (each shard’s nodes only storing its own shard’s data) means that unless the total node count of the network is sufficiently increased to offset the effective node reduction from sharding, we could run into critical issues with data storage, data availability and processing the entire blockchain — where there certain data just isn’t stored, and certain shards fail to process all of their transactions.
- Splitting up the validator set also reduces decentralisation per shard, lowering shard security by making it easier to attain 51% of a shard. This, and other problems can only be stopped by increasing the total network node-count so that the number of nodes in each shard is equal to the total number of nodes prior to sharding the blockchain.
- Sharding increases the chain throughput, putting greater pressure on archive nodes proportional to the scalability gains to store the blockchain history. (Archive nodes are still not paid for this exponentially more expensive work)
The ultimate problem here is that simply ‘increasing’ the number of nodes to counteract the strain sharding puts on the chain is not an easy task. These light nodes are volunteers, and as we know, there are massive incentive issues at play here. There are no economic incentives to be a light node and do the work which light nodes do, and there is a prisoner’s dilemma-style situation where people have an individual incentive to stop running a node and free ride on the work of other nodes, however lightweight and cheap the nodes may be to run.
In his article, Vitalik describes the fundamental solution to making sharding (and the blockchain) sustainable — a solution to increasing the minimum node count of the chain:
“For a blockchain to be decentralized, it’s crucially important for regular users to be able to run a node, and to have a culture where running nodes is a common activity.” — Vitalik Buterin
This is what solving the trilemma comes down to, in the end. Culture.
The blockchain can’t shard (scale) too much because it needs more nodes? Then just develop a culture of node running. This touches on the heart of the volunteer problem and the scalability problem. While a culture of righteously self-sacrificial altruistic nodes would, of course, increase the scalability potential of any blockchain, we have already thoroughly outlined that:
- ‘Culture’ is not a commercially scalable approach (volunteers = volunteer scale)
AND - It is not an economically viable approach on an incentive level (the game theory of the prisoner’s dilemma and the free rider effect kicks in and there is a market failure to provide the needed infrastructure).
Sharding does not fix the volunteer problem, and only improves blockchain scalability at the cost of security. The fundamental trilemma trade-off still exists. If increasing the minimum node count to retain decentralisation is needed to scale the chain securely under sharding — well, that was already the case without it.
Moving Computation Off-Chain — Rollups
In this section, I’m going to explain (roughly) what rollups are and how they work. This understanding will help us evaluate their effectiveness in solving the problems of blockchains we’ve outlined.
If you’d like to skip right to the evaluation, scroll down until you reach the bit titled: ***Rollups Summary/TLDR***
A key part of the current blockchain scaling solutions is the idea of ‘blockchain departmentalisation’. The idea is that we can unbundle the consensus layer, execution layer and data availability layers of the blockchain should we so wish, and split the tasks up across multiple chains (which means, off-chain). So called ‘monolithic chains’, which try and do everything on layer 1, have been deemed inadequate. Blockchain departmentalisation is generally done with the main goal of addressing the scalability problem — not any of the others which we have discussed.
I will defer to an article by rollup aficionado Polynya to describe what these different blockchain ‘layers’ do:
“Execution: Execute transactions as fast as possible. This is where we’ll see most innovation, and we could see large-scale applications build their dedicated execution chains optimized for specific usecases. Example: Reddit building their own rollup.
Consensus: Provide security, coordination and store transaction proofs and “metadata”. Perhaps it’d be better to call these “Security chains” going forward as the other two types may also have consensus mechanisms, albeit much simpler ones.
Data availability: Provide data availability and store compressed data for transactions”
There are different ways we could mix and match these layers. Rollups are simply off-chain execution layers. Validiums are when consensus, execution and data availability are all on different chains. And Volitions can be rollups or validiums for a given consensus layer (e.g. Ethereum, Proof of Stake) depending on what the user chooses.
“Rollups only do execution, while relying on a different chain for security and data availability. Execution: chain 1; consensus and data availability: chain 0.
Validiums are rollups which use a secondary source for data availability (which makes them not rollups, but validiums). Execution: chain 1; consensus: chain 0; data availability: chain 2.
Volition builds on this by offering users the choice of rollup and validium within the same state. Execution: chain 1; consensus: chain 0; data availability: chain 0 (rollup mode), chain 2 (validium mode).”
It is worth noting that there are such things as ‘data availability chains’, which Polynya describes as follows:
“Data Availability Chain — A new breed of L1s with no execution layers, focused entirely on data availability for other chains. They have their own consensus mechanisms purely for data. It’s important to note these chains are useless by themselves, and need other execution chains — whether monolithic or validiums — to leverage them.”
Ethereum’s strategy is to achieve scalability by only using the base layer for consensus and data availability, and to move all the heavy computational lifting off-chain to rollups (an approach detailed by Polynya here). In this way, they hope to increase chain throughput whilst retaining decentralisation on the base layer.
Let’s learn a bit about rollups so that we can examine this strategy.
What rollups do is execute a whole heap of transactions off-chain — and then only submit the final state to be posted to the main chain. This way, nodes don’t need to verify as many transactions as if every single transaction took place on-chain — instead just verifying a ‘rollup’ or ‘batch’ of all of the transactions which took place off-chain.
The reason that rollups can process so many more transactions than the main chain is because they are not consensus-based systems, and instead rely on centralised block producers called ‘sequencers’, who have very powerful and expensive hardware. Centralisation enables the processing of vastly more transactions, because the single ‘node’ does not need to repeatedly achieve consensus with other nodes every time it processes a transaction.
Rollup users must deposit funds into one of these smart contracts before getting an equivalent amount unlocked on the rollup. A third party, known as a sequencer, credits the user with funds on the rollup after receiving proof of the latter’s deposit in the rollup contract
- Alchemy
But wait just a minute here — we can’t just go around trusting centralised sequencers to not do something shady. So how are they kept in check? There are two main methods. One is using fraud proofs (described by Vitalik here), which involves individuals checking that rollup transactions are valid and signalling a red alert when they find some misbehaviour, so that the main chain rejects the invalid transactions. This requires sequencers to share transaction data (make the data available) so that people can verify it to submit fraud proofs. This innocent until proven guilty method is employed by optimistic rollups.
The other method is validity proofs (see link for explanation), which are submitted with every batch sequencers post to the main chain — and definitively proves that the entire batch is valid. The validity proof is verified by full nodes on the consensus layer, and confirms the validity of the batch. This method is employed by ZK-rollups. Those who compute the ZK proofs are called ‘Provers’. It is important to note that ZK-Rollup sequencers must still make the data available. If they didn’t, then users would not be able to see their balances and interact with the rollup.
“With rollups, we do the transaction processing off-chain, but we post transaction data on-chain. The amount of data we post on-chain is the minimum amount required to locally validate the rollups transaction. By putting data on-chain, anyone can detect fraud, initiate withdrawals, or personally start producing transaction batches.”
Preethi Kasireddy, A Normie’s Guide To Rollups
If you’d like to know more about what’s going on under the hood and how these proofs work, these three articles describe them in greater depth, and in varying levels of complexity: (simple, intermediate, technical; video).
However, a key takeaway is that regardless of the method of proof used, data availability is essential to making this whole rollup thing work.
“If the data availability solution/layer used by a rollup is unable to keep up with the amount of data the rollup’s sequencer wants to dump on it, then the sequencer (and the rollup) can’t process more transactions even if it wanted to, leading to higher gas fees like we see in Ethereum today.
This is exactly why data availability is extremely important — guaranteeing data availability allows us to ensure rollup sequencers behave, and maximizing the data space throughput of a data availability solution/layer is crucial if rollups are to maximize their transaction throughput.”
Yuan Han Li, ‘WTF is Data Availability?’, (emphasis added)
So data availability is a fundamental constraint on scaling with rollups. Now, the ‘Data Availability Problem’ is that we need to make sure that sequencers make data available on the data availability layer (in this case, the Ethereum L1), for the above reasons. We don’t want sequencers withholding data from the network, but since they exist outside of consensus we can’t easily compel them to give it to us.
“The obvious solution to the data availability problem would just be to force the full nodes to download all the data dumped by the sequencer onto the data availability layer/solution — but we know this gets us nowhere since it would require the full nodes to keep up with the sequencer’s rate of transaction computation, thereby raising the hardware requirements of running a full node and worsening decentralization.”
Yuan Han Li, ‘WTF is Data Availability?’
Because full nodes can’t download all the data at once, but still need to be able to download any given piece of data when they need to verify specific things (and because users need data availability too), there needs to be a method of determining whether sequencers are making data available (on the data availability layer) at all times. This method is called ‘data availability proofs’.
One strategy, called ‘data availability sampling’ is to have full nodes request random pieces of data from sequencers. If the sequencer doesn’t have the specific pieces of data that are requested, then the network node will send out a red alert. With many full nodes doing random data sampling, no one node has to store all the data the sequencer holds — but the network can still test that the sequencer is holding most of the data. Sequencers don’t know what data is going to be requested, so if they are trying to withhold data and make data unavailable, they will likely be caught out. This can be combined with something like data sharding, where nodes in a given shard only store their own shard’s data, and use sampling to check data availability for other shards.
However, a malicious sequencer could still get away with not storing a very small portion of the data — a single transaction, for example — because the only way to ensure that every piece of data is available is to actually download every piece of data. Data availability sampling only gives us probabilistic guarantees. So the plan is to also throw in some very smart technique called erasure coding, as well as fraud proofs (or validity proofs!) and anything else we can come up with to make things as secure as possible. See here for a thorough academic article on this (co-authored by Vitalik Buterin).
***Rollups Summary/TLDR***
Okay. Let’s say we can sort out the details, and make all this work. Where do rollups get us? Well, they don’t solve the volunteer problem of paying people to run nodes in the p2p network. They partially assist in slowing the data storage problem by moving computation off-chain. They do not price and pay for data storage on the network (despite adding data to the chain). They do not solve the network closure problem either. So they aren’t a fix-all. But what rollups certainly do, is give us a template to help achieve scalability beyond whatever the base-layer capacities of a blockchain are — and if you count off-chain scaling as scaling, then you can (generously) say that they at solve the scalability problem. Their ability to use honest-minority assumptions for block production is a significant advantage — allowing them to inherit the security of the main chain.
What rollups need, above all, is the strongest and most secure settlement layer that they can possibly get. Bitcoin would be an obvious choice, but it is not rollup-compatible. Though, its reliance on a block subsidy for security does leave something to be desired. Ethereum is a promising second candidate, with lots of adoption and solid decentralisation. Ethereum is also positioning itself to be a data availability and consensus layer for rollups to settle on. You could just as well put rollups on *insert your favourite chain* here.
Problems and Challenges With Rollups
In my opinion, there are also some pretty serious problems to still be figured out with rollups. And I’m not talking about things like working with the complexity of ZK Rollups, secure cross-rollup communication, or figuring out inter-rollup composability. I think those things are achievable.
For rollups, there is the quite significant problem of centralisation as an attack vector. With just one sequencer per rollup, there is a risk of the sequencer being attacked and the portion of users which rely on that rollup being disrupted. Whether it is a hacking, a physical attack, government coercion, or downtime due to a power outage or earthquake — central points of failure are never ideal and can be massively disruptive. This is not to mention the fact that since rollups are off-chain entities and cannot be regulated by consensus, there is nothing stopping sequencers from not putting certain transactions onto the chain if they so choose, for whatever reason. We’ll discuss this more in a second.
In the face of all this, it has been suggested that we should ‘decentralise’ rollups, by creating for each rollup its own Proof of Work / Proof of Stake consensus layer! Others have suggested that we shard rollups. Maybe it’s turtles all the way down… some certainly think so. But just how ‘decentralised’ these rollups will really be (and should be) is another question entirely.
Is a small ring of people staking to ‘elect’ a sequencer from a pool of two or three sequencers decentralised? Do the ‘stakers’ get paid a portion of the sequencer’s profits (transaction fees) — or some token which gives them a discount in the rollup? Such a token would still eat into the sequencer’s profits. There needs to be an economic incentive to participate in this secondary consensus layer, or people won’t do it at a meaningful scale. And why exactly would sequencers and those building the rollups decide to share their profits with stakers? With leading rollup companies like Starkware being valued at $8 Billion, why would they decentralise and take a profit cut? It’s not like end users would notice the difference. If I was a sequencer-prover which a rollup depended on, my incentive is to run my own centralised rollup. No consensus layer needed.
Furthermore, calling a rollup decentralised and thinking we’ve solved our problems just because we introduced a closed voting ring to elect who produces blocks is a stretch — because not only would there be only a handful of block producers, but the rollup staking ring itself (which has its own security budget) could be compromised and 51% attacked. It costs money to stake, and asking people to spend money to ‘decentralise’ a rollup at little benefit to themselves is a stretch. Furthermore, creating a consensus layer at L2 splits the staking budget between the main chain and the new consensus layer that has been built. With multiple rollups, this problem gets amplified.
In other proposed rollup ‘decentralisation’ models, multiple sequencers will be the ones staking, competing to produce their own blocks for the rollup (just like a L1 consensus layer). But sequencers need to be able to run and maintain expensive hardware so they can achieve computational scale — which is clearly at odds with the rollup’s capacity for decentralisation. How decentralised can a rollup be if there are only a handful of people actually able to participate and be sequencers per rollup? This is not decentralisation — it’s just contending with the age old decentralisation-scalability dilemma off-chain, and then opting for centralised but scalable block production instead of decentralisation and low scalability.
Even if we could leverage all of the nodes participating in the main chain’s (in this case, Ethereum’s) consensus mechanism — and we had statelessness implemented so there were as many nodes as possible — it doesn’t mean a wide range of sequencers/provers suddenly appears for us to elect. The pool of block producers is constrained by the need for high throughput capacity, so we are still fundamentally limited by the scalability-decentralisation trade-off. If we then decided to lower the scalability standards of rollups to have a more decentralised range of block producers, we lose out on scale. If we lowered it even more, to make our rollups really decentralised and secure — but they would fail to scale and we would have just recreated the main chain with all its trade-offs on layer 2.
Of course, it is worth mentioning that nobody NEEDS to use rollups, and the failure of any given rollup does not in any way impact the more decentralised and secure base layer of a chain like Ethereum at all. But rollups failing would be tantamount to the base layer failing in the sense that the scalability problem (which is the only problem rollups attempt to fix) was never solved. Ultimately, what all this shows is that the layer 2 solution is itself struggling with the same inescapable trade-offs as the base layer.
In reality, there are no concrete plans for how to decentralise rollups — only promises. So while the scalability vs decentralisation trade-off is able to be massively reduced by disaggregating the execution layer from the consensus layer and only centralising the execution layer (the rollup), we are still just making tradeoffs.
“So what’s the result? Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented.” — Vitalik Buterin
For a short list of some other problems with such a centralised block production system, see this section of Vitalik’s older writeup on sharding (the link will scroll you to the correct point in the article).
There’s another matter relating to rollups cannibalising the main chain’s security. The main chain’s native token, in this case ETH, derives from people demanding it so that they can use it to pay fees (gas) and interact with the base-layer Ethereum blockchain. If most transactions occur off-chain at negligible fees which get paid to sequencers (as is the great promise of rollups), this should cannibalise the economic value which would otherwise be flowing to the ETH currency. As we have learned before — the economics of a blockchain’s native token are important because that is what is used to incentivise the network’s security. A counterargument to this line of thinking is that rollup transactions are a bonus to what is already a fully saturated base-chain — but if people could just use rollups for cheap, I don’t see why would they stay on the base layer? I won’t venture into this debate in any further here.
Finally, there is the subject of rollup profitability. What is the incentive for companies like Optimism, Arbitrum, StarkWare and Zksync to bring rollups to Ethereum? They obviously wouldn’t spend so much money unless they were going to make it back, plus some. I’ve already hinted at the answer in the above — and the answer is fees. In order to fund the whole operation of designing, building and running the rollup (no one of these things is an easy task), companies like Starkware will collect fees from transactions which they process. Now — just how large the fee-payment they collect is would depend on their specific business model. They’ll work something like this. Given that the goal is to process as many transactions as possible for the main chain, I imagine they will try to go for a low-fee, high transaction volume business model. Others will try implement a token with a supply they control a portion of — but this is just fees with extra steps. I am not sure exactly how much volume would be required to cover all the costs of building and running the rollup — but one would hope that they’d break even and that the whole process would be a competitive use of the capital.
While I have no problem with fees in themselves (they’re essential to making a blockchain run), if you’ll recall the previous section on The Network Closure Problem, you might see how they can pose a problem here. A given rollup operator will receive transactions, process them, take a few, and put the batch on the chain. Whether they are fully centralised, or running on Proof of Stake, they have a dis-incentive to share their transactions because for them, transactions represent profit — and there is no volunteer p2p network to propagate the transactions around between rollups (though perhaps some thought should be given to this idea). Just like Infura, the business model of rollup operators is transaction monetisation. And just like Infura, a rollup operator could simply exclude your transaction from going onto the chain if they wanted to. Section 5.1 of the Bitcoin whitepaper is discarded once more. With no p2p network, and a narrow range of block producers — this is more problematic. However centralised or decentralised a rollup might be would not change the fact that they are not incentivised to share transactions, and not punished for withholding them.
In terms of getting around block producers potentially excluding certain transactions, I have seen discussion of ‘secondary transaction channels’ and ‘light unassisted exits’ for rollups (and these might be the same thing, I’m not sure) as solutions. To the best of my (limited) understanding, it seems like a decentralised rollup with stakers can have stakers “submit lists of transactions which the next block must include.” This seems like it could work, assuming the rollup PoS had sufficient security (cost of attack) and decentralisation. Though, again, I don’t see why sequencers would even subject themselves to governance by other parties when they could just opt for a centralised rollup.
Data Storage Blockchains — Arweave and Filecoin
Let’s go back to the Data Storage Problem — which, if you remember, was never actually solved. Blockchains grow and grow and grow, and nobody even pays for the storage of data — it is handled by volunteers in the p2p network and archive nodes. Often, the p2p network only stores the current state (which itself grows indefinitely and at an increasing rate) because the full blockchain history is too costly to store. If we optimistically assume that the chain size does not grow to the point where the cost of storing it exceeds the profits of all business models relying on it, there may be at least some small number of parties willing to perform archival functions and store the entire history of a blockchain.
Data storage blockchains are blockchains which are designed to … store data. Like all blockchains, they are powered by a cryptocurrency — which is used to incentivise network participants to do the work outlined by consensus (which in this case, is … storing data). This is cool. Normal blockchains don’t do this.
Some suggest that the data storage problem of blockchains can be solved by offloading data onto data storage chains. Users pay to have data stored, and to retrieve it too, if the model has retrieval costs. They could also act as data availability layers for those interested in disaggregating blockchains. Recall that Solana (a chain which is scaling extremely fast) ‘solved’ its data storage problem by archiving its blockchain state to Arweave and requiring full nodes to only store the past two days’ worth of data. Here, I’m going to be discussing two major players in the space: Arweave and Filecoin.
Filecoin and Arweave have different models, so let’s first go through their basic functioning both before discussing their viability.
Filecoin Model
In Filecoin, “clients [users] spend FIL tokens for storing and retrieving data, and miners earn tokens by storing and serving data.”
“The Filecoin network employs Proof-of-Spacetime and Proof-of Replication to guarantee that miners have correctly stored the data they committed to store.”
“Proof-of-Replication is a novel Proof-of-Storage which allows a server to convince a user that some data has been replicated to its own uniquely dedicated physical storage.”
“Proof-of-Spacetime “enables an efficient prover to convince a verifier that they are storing some data for some period of time.” “The Filecoin protocol employs Proof-of-Spacetime to audit the storage offered by miners.”
The Filecoin blockchain supports two decentralised exchanges which pairs miners and users: one for data storage (the ‘Storage Market’) and one for data retrieval (the ‘Retrieval Market’). “In brief, clients and miners set the prices for the services they request or provide by submitting orders to the respective markets.” This is a free-market pricing system, where price is determined by the intersection of suppliers’ willingness to sell data storage/retrieval and buyers’ willingness to pay for it. This self-determined pricing system helps ensure that miners do not incur economic losses which would make the provision of the service unsustainable.
Filecoin’s network of full nodes “guarantees that miners are rewarded and clients are charged if the service requested has been successfully provided.”
“Clients can store their data by paying Storage Miners in Filecoin tokens.”
“A client submits a bid order to the on-chain Storage Market orderbook. When a matching ask order from miners is found, the client sends the piece to the miner. Both parties sign a deal order and submit it to the Storage Market orderbook. Clients should be able to decide the amount of physical replicas of their pieces either by submitting multiple orders (or specifying a replication factor in the order). Higher redundancy results in a higher tolerance of storage faults”
“Clients can retrieve data by paying Retrieval Miners in Filecoin tokens.”
“They submit a bid order to the Retrieval Market orderbook by gossiping their order to the network. When a matching ask order from miners is found, the client receives the piece from the miner. When received, both parties sign a deal order and submit it to the blockchain to confirm that the exchange succeeded”
Storage Miners must also ‘pledge’ (basically, stake) to provide storage to the Network. “Storage Miners pledge their storage to the network by depositing collateral via a pledge transaction [basically, staking] in the blockchain. The collateral is deposited for the time intended to provide the service, and it is returned if the miner generates proofs of storage for the data they commit to store. If some proofs of storage fail, a proportional amount of collateral is lost.”
Although there’s more (forgive me Filecoin maxis), that’s the essence of Filecoin. See here or here if you want some videos to start going a little deeper into the project.
Arweave Model
Instead of a blockchain, Arweave uses something called a ‘blockweave’. In Arweave, “each block is linked to two prior blocks: the previous block in the ‘chain’ (as with traditional blockchain protocols), and a block from the previous history of the blockchain (the ‘recall block’).” This ‘recall block’ associated with every block on the chain is what differentiates the blockweave from the blockchain.
Every time miners want to start mining on a new block (to make money), a recall block (a previous block on the chain) will be selected at random for the block, and miners will need to prove that they have it in order to start mining. This incentivises miners to store past data. This mechanism is called ‘Proof of Access’, or ‘PoA’, and is reminiscent of data availability sampling solutions discussed earlier in the article.
A major difference between Arweave and Filecoin is described in the Yellowpaper:
“PoA takes a probabilistic and incentive-driven approach to maximising the number of redundant copies of any individual piece of data in the network. By contrast, other decentralised storage networks specify an exact number of redundant copies that should be provided for a given piece of data, and mediate this using a system of ‘contracts’”
So, how does Arweave actually pay for data storage? Similar to Filecoin, when users want to add data to Arweave, they need to pay miners in the chain’s native token, AR. But unlike Filecoin, the price of data determined is not set by market forces. Here’s how it works:
“Transaction pricing in the Arweave network comes in two components: a highly conservative estimate of the perpetual storage cost, and an instantly released transaction reward to incentivise a miner to accept new transactions into the new block.” — Arweave Yellowpaper
Essentially, what the Arweave team has done, is:
- Looked at the historical trend of data storage costs (which declines over time as technology improves)
- Conservatively extrapolated this trend forward, to get an approximate prediction of how much data storage costs in the future will likely be.
- Make users pay some AR (the Arweave native token) when they add transactions to a block.
- Give part of each fee to miners immediately, while “most of the transaction fee goes to a storage endowment”. The endowment releases the fees to miners over time, and is meant to cover the cost of storing that data forever — being based on the conservative cost-of-storage estimates baked into the consensus mechanism.
- Arweave will also give a (temporary) block subsidy to miners until the AR supply cap is reached, at which point the network will rely solely on fees.
- The network does not release endowment funds if, by the protocol’s own estimates, miners will be sufficiently compensated by fees + the block reward. In these instances, it will save endowment funds to release in future instances where fees + the block reward are not covering mining costs.
So when you ‘deposit’ data on Arweave, you pay an initial cost for perpetual storage based off of the conservative cost-estimates made by the chain, and this gets paid out to miners like rent over time. The goal of this mechanism is to allow “the network to distribute appropriate quantities of tokens to miners over time, in order to sustainably incentivise the perpetual storage of arbitrary quantities of data.” By arbitrary, they mean any amount of data put onto the chain. Arweave’s promise of perpetual data storage also lies in stark contrast to Filecoin, which has users store data for a period of time.
Discussion of Data Storage Blockchains
Data storage chains can be used by any user to store data — but also might be able to be used by other blockchains to store historical chain data. Let’s critically evaluate some potential problems:
***Modelling Risk***
Some people take issue with assumptions about data storage costs made by Arweave. Anyone who’s done financial modelling or valuations or investing before may have heard that the past results are not necessarily indicative of what will happen in the future. While it is true that the future is inherently uncertain, for the sake of discussion we can grant Arweave the benefit of the doubt that their conservative estimates will play out and not be disrupted by black-swan events.
***Paying for Bandwidth Costs***
Retrieving data from the blockchain has a cost. For example, it is not costless to send entire movies to somebody else — it costs bandwidth. If you’re a miner on Filecoin or Arweave, you’re going to be serving up a lot of data to a lot of people and frequently incurring the cost of doing so.
Now, Filecoin has built into it a pricing mechanism for the private retrieval of data. This is an intelligent move, as it ensures the bandwidth cost of miners is actually compensated for — meaning the network pays for this critical function and achieves self-sufficiency. Arweave does not have such a mechanism, and does not in its payment mechanism incentivise miners to perpetually serve data to users. This is problematic, because we want our blockchains to pay for the infrastructure necessary for them to survive with certainty. If miners are not sufficiently compensated for serving data, and doing so would put them into economic losses — then they either won’t serve data, or will be forced to leave the network.
However, both networks fail to make nodes pay for the bandwidth needed to make data available to the public. This makes them both unsuitable for IPFS-style casual data access. On our regular blockchains, which are public ledgers, everybody can access data freely (though due to the fact that they only pay for mining and staking, they don’t pay for bandwidth either).
***Up-Only Risk***
To function properly, these blockchains must pay nodes more than it costs to store data. If they don’t do this, then nobody will run a node and store data for the people.
But remember, nodes get paid in the native currency of their chain (FIL/AR), whose market price fluctuates due to market forces. So put another way, the coins earned from being a miner need to be sold at prices which compensate miners for the costs of storing data (likely denominated in USD or some other currency) — or nodes will be running at a loss, which is unsustainable and will lead to network collapse.
Such a model works ‘on the way up’, when the token price is increasing and it is profitable to mine on the network. But if the price of the network’s coin falls low enough, it will be unprofitable for miners to continue storing data they have already agreed to store at past prices — at which point they would be incentivised to delete the data and leave the network. If this is confusing, try considering the limit case (which applies to any blockchain): if the price of AR/FIL went to zero, miners would have no incentive to continue spending money storing and serving data they have previously accepted.
Indeed, the Arweave yellowpaper describes that the profitability of miners is “naturally satisfied by consistent release of tokens from the endowment” only when “assuming a stable token price in fiat terms” and accurate cost-modelling predictions. It’s a good thing the prices of cryptocurrencies aren’t volatile or anything… In my opinion, the assumption of a stable or always-increasing token price is suspect. Whether due to aggressive speculation, global macroeconomic events, or black swan events (e.g. war) — the prices of cryptocurrencies are never guaranteed.
It should be noted that Arweave suffers from this problem more than Filecoin, because it attempts to cover the costs of perpetual data storage with one-off upfront payments at the point of ‘depositing’ data. Users pay a certain amount of AR tokens to miners today to store data forever — but the price of these AR tokens fluctuates and miners may not actually be compensated for the data they are being required to store.
In the event of a downwards price spiral or prolonged price decline, both Filecoin and Arweave miners would suffer economic losses. In Arweave, the losses would last until the token price appreciated enough to cover the cost of storing all of the data that has ever been put on Arweave. In Filecoin, the losses would at some point stop when the previously agreed upon storage contract expires. Whether in either case miners could (and would) actually afford to incur losses for an uncertain period of time is questionable. At scale, the amount of losses would be greater — and the problem exacerbated.
To me, this is reminiscent of the Luna downward price spiral, where the model’s stability relied on the LUNA token price continually going up.
The Arweave whitepaper also states that “the incentive to maintain the weave also increases as the network and documents will reinforce the value of the tokens”. I think what they are getting at with this comment is that as increasingly important and needed data is stored on the network, people will be ‘incentivised’ to pay for it — and cover the potential losses of miners should the above scenario happen. However, economics teaches us that another possible outcome is that you could just get a market failure to provide the service instead, because 1) people don’t provide massive services at scale for free, 2) even if they tried to, incurring economic losses would not be sustainable, and 3) there may be a prisoners-dilemma scenario, where people reason: “if someone is going to pay for it, then I don’t need to.”
How about new data? If the token price collapses for whatever reason, does the acceptance of new data onto either network also put miners into losses?
Filecoin has a free-market price for data storage for a fixed period of time that is set between miners and users. This means that in the event of a downward price spiral, miners would not take on data unless they thought that the USD value of the FIL currency they were being paid in would exceed the costs of data storage for the storage period. So they would be able to either refrain from accepting new data until the FIL token price stabilised, or they could agree to store data on conservative estimates of the FIL price.
Arweave does not use a market pricing system for its data pricing — so how does it know what the price of the AR token is in order to adjust how much to pay miners for new data with endowment funds? Instead of markets or oracles, Arweave uses a mechanism outlined here to estimate its token price.
I won’t delve too much into it here, but I believe that this ‘proxy’ approach is strictly inferior to a real-world market pricing approach. One of the assumptions is that: “as inflation rewards decrease, the price of AR should increase in order to keep up with the costs of mining” (emphasis added). Furthermore, it relies on using increasing mining difficulty as a proxy for price going up — but there are often significant divergences between mining difficulty and price on other chains which could lead to serious mispricing of data.
For some examples of how difficulty is not always a good estimate for price (due to significant directional divergence AND the fact that it increases at different rates to price), see Litecoin, Ethereum, Bitcoin, Dogecoin and Monero. These divergences between mining difficulty and token price are frequent enough and last long enough to make estimating your (token denominated) profits on the basis of mining difficulty a bad strategy. Implied approximations are not equivalent to real price, and this has economic consequences. Imagine trying to run a profitable shoe business by approximating the price of leather using the price of cows instead of using the real price of leather in your calculations. There’s a good chance you’d run into economic losses and be unprofitable. This is all notwithstanding the fact that the Arweave Consensus Mechanism does not pay for the serving of data to users either.
To summarise: data storage blockchains pay their miners in cryptocurrency, but miners have real-world hashing/data storage/data retrieval costs denominated in alternative currencies like dollars. The price of the native currency of the chain which nodes get paid in (FIL/AR) fluctuates freely due to market forces. Both protocols will induce people to put data on the chain. But if the token price falls enough, the historical payment to store the data (including any endowment funds) may no longer cover the costs of storing the data. In such a scenario, miners are incentivised to leave the network, and the chain would likely stop functioning.
***The Security Problem***
Reliance on an alternative chain for any network function poses security risks. Since Filecoin and Arweave run on completely different consensus mechanisms to any chain that would be leveraging them for data storage (e.g. Solana, Ethereum), they could be targeted for long-range attacks on reliant chains.
Attacking a data storage chain directly impacts any chains relying on it. If a chain like Ethereum relies on a data storage blockchain for a given function (e.g. archiving historical data), then Ethereum reduces their security threshold for that particular network function to the whatever that data storage chain’s level of security is. This also means that any incidental attacks on Filecoin or Arweave which have nothing to do with chains relying on it would threaten the stability of chains relying on them.
Also, I am not sure if there is some bridging risk when trying to get a blockchain to communicate with a data storage chain — but the history of bridges in crypto essentially consists of a history of catastrophic failures. So there’s that.
***Arweave Wildfire***
On a completely different note — Arweave claims to solve “the problem of data sharing in a decentralised network by making the rapid fulfilment of data requests on the network a necessary part of participation” with a system called ‘Wildfire’. This is a direct attempt to solve part of the volunteer (or ‘free rider’) problem of blockchains, where the collection and sharing of transactions is not an economically incentivised behaviour, and is handled by a volunteer network.
What Wildfire does, is create a ranking system for each node based on how quickly they respond to requests and accept data from others. If your ranking is low, it means new blocks and transactions are distributed to you more slowly, which eats into your mining profits. If your ranking is very bad, you can get blacklisted from the network entirely. This is intended to create a financial incentivise nodes to share data.
I think Wildfire is a very good attempt to address a fundamental problem, which other chains would do well to pay notice to. Though I am not really sold on how effective it will be. It has added an incentive to share data flows around the network (you don’t lose profits) — but it fails to truly dis-incentivise the undesired behaviour of transaction hoarding, which is still clearly profitable. This means that there is still a direct profit incentive for people to undertake the undesirable behaviour — which, if it outweighs the dis-incentive Wildfire introduces — means the undesirable outcome will still occur. Because of this, people will still try to figure out ways to game the wildfire system. Furthermore, if large and network-valuable miners are blacklisted because of Wildfire, it would undermine security by lowering the hashrate — which is probably not a worthwhile trade-off.
Wildfire only incentivises miners to perform a basic network function to help maintain openness — it does not economically incentivise a p2p network to exist. So a key aspect of the volunteer problem remains unsolved. However, I am very impressed with this innovation and attempt to solve a fundamental problem. They see the problem, and are attempting to remedy it.
Concluding Thoughts on Data Storage Blockchains
I have been relatively critical here, but that’s kind of the point of the article. Ultimately, I am very glad that pure data storage blockchains exist (all blockchains store data), and I think there are some really cool ideas being tested and explored in both Filecoin and Arweave. Unlike other chains, they actually take the data storage/pricing problem seriously and attempt to address it in innovative ways. I want the experiments to continue, and am interested to see how it all plays out. But at least for the purpose of solving the data storage problem for other chains, I do not feel confident in them — owing to questions regarding their long-term viability, and also due to issues regarding bandwidth and open, self-sustainable public data availability.
That being said, for chains which have elected to scale more rapidly (e.g. Solana), using a data storage chain for the archiving of data is probably necessary to preserve the p2p network, and preferable to nothing.
What’s next?
That concludes part III in this four-part series. In the next and final article, we will cover a completely new set of solutions to crypto’s fundamental problems — and gain a fresh new perspective on how we might finally be able to solve them.
I hope you enjoyed the third section from my mega-article Defusing Crypto’s Ticking Time Bomb. If you did, clicking and holding the little clapping icon👏 on the bottom of your screen and giving this article up to 50 claps would be a great help.
See you in the next one.
