How to Support Partial State Availability

Traditional blockchains like Ethereum require all full nodes to store and process the entire state—every account balance, smart contract code, and storage slot. This creates a massive bottleneck for scalability and decentralization, as the hardware requirements for running a node grow with the network. Partial State Availability addresses this by decoupling data availability from execution. Nodes can participate in consensus and validate transactions by only fetching the specific pieces of state relevant to the blocks they are verifying, a concept central to stateless clients and data availability sampling.

The core mechanism enabling PSA is a cryptographic commitment to the full state, typically a Merkle root or a Verkle tree root, included in the block header. When a node needs to execute a transaction that interacts with a specific account, it does not need the full state tree. Instead, it requests a state witness—a cryptographic proof (like a Merkle proof) that proves the value of that account against the committed root in the header. This allows light clients and even full nodes to operate with a fraction of the data, shifting the burden of storing the full state to a smaller subset of specialized nodes.

Implementing PSA requires changes at both the consensus and execution layers. For example, Ethereum's roadmap includes Verkle Trees (EIP-6800) to enable efficient stateless verification by compressing proof sizes. A block builder must provide the state witnesses for all transactions within the block, or the data must be made available so that any verifier can reconstruct them. Protocols like Ethereum's Danksharding and Celestia's Data Availability Layer separate the block's data availability from its execution, ensuring that data is published and can be sampled by light nodes.

For developers, supporting PSA means designing applications with this architecture in mind. Smart contracts should minimize cross-contract state dependencies within a single transaction to keep witnesses small. Tools like the Ethereum Stateless Ethereum Testnet allow for experimentation. The primary benefit is horizontal scalability: the network's throughput is no longer limited by the processing power of a single node, enabling faster sync times, lower hardware requirements, and greater participation in network validation.

Key challenges remain, including ensuring the liveness of data availability networks, managing the overhead of proof generation for block producers, and defining economic incentives for nodes that store the full state. However, PSA is a foundational step towards scalable, decentralized blockchains where users can verify chain validity without needing terabytes of storage, paving the way for widespread adoption.

Blockchain state refers to the complete set of data that defines the current condition of the network, including account balances, smart contract code, and storage variables. In traditional monolithic blockchains like Ethereum, every full node must download, compute, and store the entire state to validate new blocks. This requirement creates significant barriers to node operation and scalability. Partial state availability is a paradigm where nodes only need to verify the availability and correctness of the specific state data relevant to their operations, relying on cryptographic proofs for the rest.

To work with partial state, you must understand the role of a Data Availability (DA) layer. This is a separate network or protocol component responsible for guaranteeing that all transaction data for a block is published and accessible, even if individual nodes don't download it all. Solutions like Celestia, EigenDA, and Avail use techniques like Data Availability Sampling (DAS) and erasure coding to allow light clients to probabilistically verify data is available. Your system's security model depends on the guarantees provided by its chosen DA layer.

You should be familiar with core cryptographic primitives. Merkle proofs (or their advanced variants like Verkle trees) are essential for proving the inclusion of specific data in a larger dataset without revealing the whole set. KZG polynomial commitments or STARKs are often used to create compact proofs of correct data encoding in erasure-coded schemes. Knowledge of fraud proofs and validity proofs (ZK-proofs) is also crucial, as these mechanisms allow one honest node to challenge incorrect state transitions, safeguarding the network even under partial data availability.

From an architectural perspective, you need to decide on a state model. The rollup-centric model, used by Optimistic Rollups and ZK-Rollups, is the most common implementation of partial state. Here, execution happens off-chain, and only state roots and proofs are posted to a base layer (L1). Alternatively, modular blockchain designs separate execution, consensus, settlement, and data availability into distinct layers. Your choice dictates how state updates are communicated, challenged, and finalized across the system.

Finally, practical implementation requires tooling. You'll need to interact with DA layer RPCs (e.g., Celestia's blobstream), work with light client libraries for data sampling, and integrate proof verification logic into your node software. Understanding the gas economics and cost structures of posting data to your chosen DA layer is also a key prerequisite for designing a sustainable application.

In traditional blockchain architectures, like Ethereum's full nodes, every participant must store and process the complete global state. This requirement creates a significant barrier to node operation, leading to centralization and limiting scalability. Partial State Availability addresses this by allowing nodes to operate with a light client model for state, downloading only the specific account balances, smart contract code, or storage slots they need to interact with. This is enabled by cryptographic proofs, such as Merkle proofs or Verkle proofs, which allow a node to verify that a piece of data is part of the canonical state without possessing the whole dataset.

Implementing PSA requires a robust data availability layer. Nodes must be assured that the state data they request is actually published and can be retrieved. This is where solutions like data availability sampling (DAS) come into play. In a system like Celestia or Ethereum's danksharding roadmap, light nodes perform multiple random samplings of erasure-coded block data. If a sufficient number of samples are successfully retrieved, the node can be statistically confident that the entire data block—and thus any specific state element—is available. The core technical challenge is ensuring that the proofs for specific state are always constructible if the underlying data is available.

For developers, supporting PSA means designing applications and clients to request and verify state on-demand. A wallet, for instance, would use a state proof to verify a user's balance. The flow involves: 1) Identifying the state key (e.g., a storage slot in a contract), 2) Querying a network of full nodes or a bridge server for the corresponding Merkle/Verkle proof and the data, 3) Verifying the proof against a trusted state root (which light clients track via consensus). Libraries like @ethereumjs/statemanager are beginning to integrate proof verification for this purpose.

A major consideration is the security model. PSA shifts some trust assumptions from consensus participants to the data availability layer and the providers of proofs (potentially untrusted). Fraud proofs or validity proofs are essential to punish providers who supply incorrect data. Systems like Optimistic Rollups use fraud proofs to challenge incorrect state transitions, which inherently rely on the disputed state data being available for verification. True PSA scalability is achieved when the cost of sampling data availability is low and the process of generating/verifying proofs is efficient.

The future of PSA is closely tied to Verkle trees and ZK-proofs. Verkle trees allow for much smaller proofs (witness sizes) compared to Merkle Patricia trees, making on-demand state verification practical. Furthermore, zk-SNARKs can be used to create succinct proofs of state inclusion or even execution, enabling ultra-light clients. As these technologies mature, supporting partial state availability will become the standard for building scalable and decentralized blockchain applications, moving away from the 'everyone stores everything' model.

Partial state availability is a data availability solution where only the state changes (deltas) required to process a transaction are made available, rather than the entire state. This is fundamental for validium and volition architectures, where data is stored off-chain. The core challenge is ensuring that any participant can reconstruct the specific state needed to validate a transaction or challenge an invalid state transition. This requires a cryptographic commitment (like a Merkle root) to the full state and a mechanism to provide cryptographic proofs for specific parts.

Implementation begins with defining the state tree. Typically, a sparse Merkle tree or a Verkle tree is used. Each leaf represents a key-value pair (e.g., an account balance). The root of this tree is the state commitment. When a sequencer produces a batch of transactions, it must publish: 1) The new state root, 2) The transaction data, and 3) For each transaction, a Merkle proof (or Verkle proof) demonstrating how the accessed state keys were part of the old root. These proofs are the "partial state" that needs to be made available for verifiers.

The next step is integrating a Data Availability (DA) layer. You cannot simply post proofs to the L1; they must be retrievable. Solutions include using a Data Availability Committee (DAC) with signatures attesting to data holding, or a Data Availability Sampling (DAS) scheme like those used by Celestia or EigenDA. For a DAC, your contract would store the committee's public keys and verify a threshold of signatures confirming the data for a batch is available before accepting the new state root.

Here is a simplified Solidity interface for a contract that checks DAC attestations before updating its state root:

solidityCopy
interface IPartialStateContract {
    function updateStateRoot(
        bytes32 newStateRoot,
        bytes32 batchHash,
        bytes[] calldata signatures
    ) external;
}

The batchHash commits to all necessary Merkle proofs for that batch. The contract must verify that a quorum of known committee members signed this hash.

For verifiers and fraud provers, you must build a client that can perform state reconstruction. This client subscribes to data from your chosen DA layer. When it needs to verify a transaction, it requests the specific Merkle proofs for that transaction's input states from a peer-to-peer network or a dedicated service. Using these proofs and the old trusted state root, it can locally compute the pre-state, execute the transaction, and check if the output matches the claimed new state root.

Finally, consider the upgrade and security lifecycle. Committee members must be rotatable, with a secure process for updating the contract's stored keys. For DAS-based systems, ensure light clients can perform sampling by integrating the relevant cryptographic primitives. Always implement a robust challenge period during which fraud proofs can be submitted using the available partial state. This entire architecture shifts the security assumption from "all data is on-chain" to "the data for any challenged transaction is available," enabling significant scalability gains.

A cross-chain bridge relayer is responsible for submitting data—like transaction proofs or state roots—from a source chain to a destination chain. Partial state availability occurs when this relayer cannot access the complete, canonical data it needs, often due to network partitions, node failures, or data pruning on the source chain. A robust relayer design must handle these scenarios to prevent the bridge from stalling, which could lock user funds or halt message passing. This is a critical fault tolerance mechanism, moving beyond the assumption of a perfectly available source chain.

The core strategy involves designing the relayer to work with available data attestations rather than requiring the full chain history. For optimistic rollup bridges, this might mean a relayer can submit a state root with a fraud proof window, even if it only has the post-state and not every intermediate transaction. For light client-based bridges, the relayer could depend on a threshold of signatures from a validator set attesting to a block header, rather than needing to sync the entire chain. The system's logic must define the minimum data payload required for the destination chain contract to verify the claim.

Implementation requires careful contract design on the destination chain. The verification contract must accept and validate partial proofs. For example, a Merkle proof for a specific account state within a block can be verified against a block header submitted by the relayer; the contract does not need the entire block body. This is how bridges like the Ethereum Beacon Chain light client on Gnosis Chain operates. The contract stores a verified header, and relayers can subsequently prove events (like token locks) by providing a Merkle proof linking the event to that header's state root.

To operationalize this, a relayer service should implement a fallback data sourcing layer. If the primary archival RPC node is unavailable, the relayer can query alternative providers—including public RPC endpoints, decentralized networks like POKT, or indexers like The Graph—for the specific data needed for the proof. The code snippet below shows a simplified relayer function that attempts multiple data sources before failing.

javascriptCopy
async function fetchBlockHeaderWithFallback(blockNumber, sources) {
  for (const rpcUrl of sources) {
    try {
      const header = await fetchFromRPC(rpcUrl, 'eth_getBlockByNumber', [blockNumber, false]);
      if (header) return header;
    } catch (error) {
      console.warn(`Source failed: ${rpcUrl}`, error);
    }
  }
  throw new Error('All data sources unavailable for block: ' + blockNumber);
}

Monitoring and alerting are essential for managing partial availability. Relayer operators should track metrics like source RPC success rate, data payload completeness, and proof generation latency. An increase in fallback usage signals deteriorating source chain access. Furthermore, the system should be designed to prioritize critical data—like large withdrawal proofs—and may temporarily deprioritize relaying less urgent data if resources are constrained, ensuring the bridge's core asset security remains operational during incidents.

Implementing partial state availability is a critical step for scaling blockchain applications, particularly those with large data footprints like gaming or social networks. The core principle is to allow nodes to operate without storing the entire global state, instead fetching specific data on-demand via protocols like Ethereum's Portal Network or Celestia's data availability sampling. This reduces hardware requirements and lowers the barrier to running a node, which enhances network decentralization and resilience. Your implementation should focus on defining a clear data partitioning strategy, selecting a robust data availability layer, and integrating a light client protocol for efficient state queries.

For developers, the next step is to experiment with existing frameworks. On Ethereum, you can interact with the Portal Network client, trin, to understand how historical data is served. For rollup-centric architectures, explore how validiums and optimiums leverage external data availability solutions like Celestia or EigenDA to post data commitments off-chain. A practical exercise is to modify a simple smart contract, such as an ERC-20 token with a large allowlist, to store its non-critical state off-chain and verify its availability using a Merkle proof submitted on-chain. This demonstrates the gas savings and scalability benefits firsthand.

The landscape of data availability is rapidly evolving. Key areas for further research include the security trade-offs of different DA layers, the development of more efficient proof systems like zk-proofs of data availability, and interoperability standards for cross-chain state proofs. Follow the development of EIP-4844 (proto-danksharding) on Ethereum, which introduces blob-carrying transactions to reduce DA costs for L2s. Engage with the community through forums like the Ethereum Research portal and the Celestia blog. By building with partial state availability today, you are preparing your application for a more scalable and decentralized multi-chain future.