Data Availability Concerns

L1/L2
1

Introduction

Kaspa is pursuing an ambitious architectural goal: moving its entire execution layer off-chain into enshrined roll-ups secured by zk-proofs.

Rather than persisting state and calldata on-chain indefinitely, Kaspa’s Layer 1 (L1) is designed to prune historical data and serve primarily as a data dissemination and anchoring layer.

In this system, roll-ups periodically submit zk-commitments that:

  • Prove the correctness of off-chain execution.

  • Enable indirect communication between independent roll-ups through verifiable state transitions.

This reimagining of L1 functionality creates a separation of concerns that brings both promising benefits and challenging implications.

The good

From an L1 perspective, Kaspa’s approach is elegant and efficient:

  • Avoids state bloat: By not storing all execution data on-chain, the protocol avoids the ever-growing state size that burdens full nodes in many other smart contract platforms.

  • Lightweight infrastructure: Users and nodes not interested in specific roll-ups are not forced to store or process their data.

  • Correctness without replication: Thanks to zk-proofs, correctness can be independently verified without everyone re-executing everything.

  • Selective participation: Only those interested in a particular roll-up need to follow and replicate it, reducing unnecessary overhead for the rest of the network.

In essence, the system aligns computational effort with actual interest, while still preserving security and verifiability through cryptographic proofs.

The bad

However, these benefits come with non-trivial trade-offs:

  • No full reconstruction from L1: Since the L1 prunes state, it cannot serve as a canonical archive. Reconstructing a roll-up’s latest state requires cooperation from actors who have preserved it.

  • Withholding risks: If those who hold or mirror roll-up state become inactive or malicious, users may lose access to their funds or be unable to prove ownership/state transitions.

  • Fragmented DA assumptions: With many independent roll-ups, each potentially operated by different entities, users cannot easily assess the data availability guarantees of the roll-up they’re interacting with.

This introduces a form of informational asymmetry - users may trust a roll-up without realizing that their ability to access their funds depends on the unstated behavior of off-chain actors.

For instance, a user interacting with Rollup A may assume it’s as robustly available as Rollup B, not realizing that the latter is backed by a commercial DA service while the former depends on a small, volunteer-run mirror without much community participation.

And the ugly

At the heart of the data availability (DA) issue lies a game-theoretic dilemma, not just a technical one:

  • In most traditional blockchains, shared smart contract state is treated as a common good - all nodes replicate it by default, ensuring broad availability.

  • In Kaspa’s model, state replication is voluntary. Users choose which roll-ups to follow, and by extension, which data to retain. This makes the system highly flexible but also fragile.

Even if a roll-up has sufficient replication today, this could deteriorate over time if interest wanes, or actors exit the network.

This leads us into a classic tragedy of the commons like scenario:

Everyone benefits from someone maintaining data, but no one is individually incentivized to do so for the collective good - especially if they are not directly impacted.

Note: Unlike traditional commons problems, this isn’t just free-riding - it’s structural. Actors may act perfectly rationally by not storing what doesn’t affect them, yet the cumulative result is fragility.

Because there is no global consensus on what data matters or how long it should persist, availability becomes subject to social consensus and economic incentives, not protocol guarantees.

Conclusion and open questions

Kaspa introduces a fascinating shift in blockchain design - from a model of forced consensus and replication to one of voluntary association and market-driven state tracking.

But this raises critical open questions:

  • How can users trust that state will remain available without mandatory replication?

  • What incentives (or penalties) can ensure long-term DA without undermining Kaspa’s lean L1 goals?

  • How will users evaluate the reliability of roll-ups without transparent visibility into their DA infrastructure?

These are non-trivial coordination problems that extend beyond code into social behavior, governance, and incentive design and solving them will (at least in my opinion) be key to Kaspa’s long-term success as a zk-secured, off-chain smart contract platform.

PS: I am going to propose a concrete solution to this problem but since the research post I am writing about this covers a lot of ground and is still expanding in scope, I thought that it makes sense to separate the problem statement from the proposal (and post it already) so they can be discussed independently - maybe somebody has elegant answers that are completely unrelated to my line of thought.

3 Likes
2

Welcome aboard ser!

In the common good setup state replication is voluntary too. Perhaps you mean that users will opt in to state replication rather than opt out as in the default setup? If so, notice that this too is a design choice, and the default L2 client can/should be set up in the same manner we set an L1 node – to store the available state.

I agree pruning provides a new flavour to the state-availability challenge, I disagree that it is a newly introduced challenge, or that the reliance on social consensus is a new assumption that Kaspa introduces.

Cryptographic proofs-of-replication can be baked into the protocol, alleviating the reliance on social consensus. While this does not guarantee real time retrievability (replicas can still refuse to share the state on demand), this problem appears everywhere in crypto (eg L1 miners refusing to share the UTXO set with new nodes).

P.S.
Ideally the platform would be rollup-unfriendly, so maybe we should use another term. In the past we used logic-zones as placeholder, and now I propose vApps from Succinct’s white paper. I mean, the entire design efforts are in order to counter rollups, defined (hereby) as logic zones optimized for more vapps joining under their own state, state commitment / proving; as opposed to vapps which are apps with defined logic which will naturally optimize for interoping with other vapps. Eg Arbitrum vs Aave. Perhaps we should elaborate more on the inherent L1-rollup misalignment, for now referring to this quick comment https://x.com/hashdag/status/1886191148533944366

1 Like
3

In other networks, opting out of replicating historical data is usually supported but replicating the entire smart contract state is actually mandatory for nodes to be able to efficiently validate blocks.

Making data retention the default mode of operation also goes a long way as it is not unreasonable to assume that at least some actors are lazy or altruistic enough to just follow best practices and retain data even if they theoretically don’t have to (especially if the underlying protocol limits state-growth to support this mode of operation).

If so, notice that this too is a design choice, and the default L2 client can/should be set up in the same manner we set an L1 node – to save the available state.

I am not saying that this is a show-stopper and you are right that just defaulting to the rule that everybody tracks everything forever like all other networks do would be an easy and straight forward solution.

But this “solution” also means that you inherit the same limitations around state-growth and scalability as all other networks and I was actually assuming that Kaspa was planning to leverage its modularity to build a more scalable and fluid system where it is no longer necessary for “everybody to just globally store and execute everything” (even if separating execution from the L1).

I agree pruning provides a new flavour to the state-availability challenge, I disagree that it is a newly introduced challenge, or that the reliance on social consensus is a new assumption that Kaspa introduces.

I didn’t say that DA is a “new challenge” - what I am saying is that our system is “modular enough” to make this become a problem if we want to fully leverage our modularity and allow actors to only store and execute parts of the global load (that is somehow relevant for them).

Cryptographic proofs-of-replication can be baked into the protocol, alleviating the reliance on social consensus. While this does not guarantee real time retrievability (replicas can still refuse to share the state on demand), this problem appears everywhere in crypto (eg L1 miners refusing to share the UTXO).

What kind of proofs do you envision as this is usually done with things like data availability sampling and data availability committees (utilizing threshold signatures to attest to the availability of data) which seems to not translate well into the realm of PoW.

And, yes you are absolutely right - it is in fact very related to things like mining attacks that withhold data to prevent others from being able to extend the latest chain (i.e. [1912.07497] BDoS: Blockchain Denial of Service).

What makes this tricky is the fact, that this can now be done by a user rather than a miner (who is at least bound by economic incentives to keep its own statements extendable and eventually reveal the missing data to stay relevant for the mining algorithm).

Imagine I spawn up a new logic zone that nobody else tracks (and for which historic data is eventually lost) and then I compose my state with yours (paying whatever fee is necessary to pay for the assumed “externalities” to make this operation dynamically possible) while never revealing my input data / state to anybody else.

This not only makes me the only person on the planet that can prove correct execution and advance the state commitment on the L1 but it also means that if I decide to never reveal the missing input data then everybody else will forever be locked out of accessing that shared state again.

P.S.
Ideally the platform would be rollup-unfriendly, so maybe we should use another term. In the past we used logic-zones as placeholder, and now I propose vApps from Succinct’s white paper. I mean, the entire design efforts are in order to counter rollups, defined (hereby) as logic zones optimized for more vapps joining under their own state, state commitment / proving; as opposed to vapps which are apps with defined logic which will naturally optimize for interoping with other vapps. Eg Arbitrum vs Aave. Perhaps we should elaborate more on the inherent L1-rollup misalignment, for now referring to this quick comment https://x.com/hashdag/status/1886191148533944366

I agree that we should optimize for decentralization rather than specialized infra providers but tbh. I don’t really care how we call things in our discussions as long as we recognize that Kaspas design choices and default parameters result in unique challenges that need to be addressed if we want to securely leverage our modularity.

And what I am furthermore claiming is that solving these problems algorithmically does not work - but they “have to be solved on the social consensus layer” which means that the moment somebody launches a “vApp” that is supposed to be composable with other “vApps” (at some point in the future) then there needs to be a mechanism in place (backed by strong game-theoretic guarantees) that ensures that the state of that vApp is tracked by a sufficiently large group of actors (that will “never” forget its latest state).

Establishing the social consensus that everybody just tracks everything forever absolutely solves this but if that is the goal / basic assumption for L2 nodes then I don’t understand why we even discuss things like atomic sync composability since if everybody is assumed to have access to the state of all other vApps then they can just natively call into each other?

PS: I think that we can do orders of magnitude better than this and actually “solve” not just some but all of the hardest problems around smart contract enabled chains (scalability, state growth and state expiry) but we first need to recognize the problem and the fact that possible solutions will significantly influence and constrain the “open questions” we are currently trying to answer.

4

Recently, Igra/Kasplex/Sparkle Teams are working on L2s to enable smart contract features on Kaspa. While everyone seems to be jumping from one question to another and lose focus and priority of issues, i.e. fees/nodes requirement/economic model.

This post is to show that this will not be just “another EVM chain replicate”. I am writing to organize all my questions and the difficulties I see in a structured way. Definitely welcome others to add more. Some were already mentioned by @FreshAir08: On the inherent tension between multileader consensus and inclusion-time proving - #3 by FreshAir08.

1. ETH Mempool/Txpool & Node Rules

When a TX nonce value is too large, or the gas fee is too low (e.g., during network congestion), ETH nodes cache the TX in the queue until conditions are met. Then the TX is executed.

Since L2 lacks P2P consensus and relies solely on L1 sequencing, TX execution may differ across nodes. For instance, some nodes may cache transactions that others do not have and executed these TXs later again in future blocks.

Specifically, nodes that has cache TXs with invalid nonce values will re-execute them once the conditions are met. Newly joined nodes cannot re-cache these TXs. It will then look like that “older nodes have more TXs,” when in fact those should have been discarded.

ETH tried to solve this issue by switching this feature off.

2. L2 Node Reconstruction and Consistency

Based rollups means that all TXs are sequenced and ordered by L1. L2 functions solely as a layer for state storage and computation. In theory, L1 L2 logic and consensus should be aligned. In that case, ideally, as long as the data sources are identical, all L2 data, statefulness, and TXs can be simply rebuilt with any L1 archive.

By the way, this is also an overlooked feature of KRC20 protocol. KRC20 needs no compatibility; KRC20 doesn’t generate any block. A TX is an execution. Every TX generates a checkpoint. KRC20 blocks = L1 block. It is the most “based”.

For EVM chain, in contrast, things are way more complicated. EVM L2s produce blocks by themselves, obviously. The biggest issue of typical EVM L2 designs is TXs are NOT executed from L1 directly. It needs a LOT of compatibility stuff, including block binding, TX execution rules, mempool rules etc. As a result, any two of the L2 nodes may diverge in transaction ordering due to caching (as mentioned above) or deep reorgs. Despite the op codes themselves, EVM chains need to incorporate EIP-xxxx, various gas fee mechanisms, and other protocols. All these are included in the ETH client ends. Very difficult to make changes. I don’t know how Igra/Kasplex team will manage this problem.

One solution (maybe) is to supporting multiple supernodes mode: this assures at least syper nodes has same results when executed against the same L1 data.

3. Additional Thoughts

  • ReOrg Handling: When an L1 reorg occurs (this is a very unique Kaspa issue), usually, the resolution is to determine the affected VSPC blocks, and then the L2 must roll back these affected TXs/statefulness and re-execute them based on the new L1 data. This would require significant modification of EVM’s core components if the EVM L2 is on Kaspa.
  • To be attractive to existing EVM devs and dapps, L2 must achieve close-to-complete compatibility. Just allowing for progammaticability with Solidity is not good enough. It needs to get across infrastructure and protocol layers.
  • Wallet compatibility: Imo the EVM ecosystem is too heavy, but for reasons above, if Kaspa makes an EVM L2, it must try its best to be as compatible as possible. Seamless wallet integration is required
  • RPC Compatibility: Since TXs are submitted to L1 (if the L2 is based), read-only RPCs (on-chain data queries) can use existing EVM components directly. However, writing (transaction broadcasting) must be submitted to L1. There are maybe two possible solutions:

(a) Wallets directly construct and submit L1 transactions. The bad news is EVM wallets cannot be used then.

(b) Modify RPC to intercept broadcast calls and relay them to L1 (“relayer” compatible with EVM wallets). This is against decentralization.

  • L2 Explorer: L2 explorers must display the mapping between L2 blocks/transactions and L1 data, which is still not given by neither Kasplex nor Igra.

------------ NON EVM PARTS ------------

I have a sense that Kaspa people don’t really know much about ETH clients. Imo, Kasplex’s design is more trusless and is more challenging by its design. It seems to be based and it is consistent with their design of KRC20. Igra’s plan is not as based, although their transparent communication and update is highly appreciable.

The actual challenge is not with tge question “can they build a L2 that can run”. The question relies upon frontier conditions, such as DA cost. A good question can be: Under 10 BPS, if L2 uses a lot of calldata (not memory or blob), does the L2 have a strategy to manage potential congestion and bloat on L1 (the fee will then rise)? That’s kinda similar to what happened during the KRC20 launch. Unfortunately, these questions are so rare. Only see buzz words of “decentralized nodes”“trust model”“pre-zk” blah blah.

5

Thanks for raising these points. Let me clarify how Igra addresses them:

  1. EVM Compatibility – we’re using Reth with modifications for Kaspa’s reorgs. Our data component handles L1 → L2 translation, while maintaining standard Ethereum RPC interfaces. Users interact normally through MetaMask, so everything else is compatible. In terms of known temporary limitations, there is 20 kBytes limit for payloads.

  2. Reorgs. Kaspa’s frequent shallow reorgs are handled by following L1’s canonical chain. When L1 reorgs, L2 follows. We’ve implemented this in our Reth fork to handle Kaspa’s specific DAG structure.

  3. RPC Decentralization. Anyone can run an Igra node and provide RPC endpoints. There’s no centralized relayer – reading from L1 and serve RPC requests are two independent processes.

Handling congestion is a very valid concern. It would be a good problem to have thought. :slight_smile:
L2 fees naturally flow to L1 miners since all sequencing happens on Kaspa. High-priority transactions pay higher L1 fees, maintaining proper incentives. In line with Fees and throughput regulation dynamics - #4 by hashdag

6

Hi Pavel. So gas is paid in Kas for Igra L2? I assumed the gas was paid in Igra. Edit: I read the documentation about the Kas to iKas bridge so I answered my own question.

7

Hi Gordon! Yes, gas is paid in iKAS, which is the native asset on Igra — same as ETH on Ethereum. iKAS is issued via the canonical bridge from Kaspa L1, so every iKAS is fully backed 1:1 by KAS locked on L1.