Data availability refers to the ability of all participants in a blockchain network to access the data needed to verify transactions and blocks. This characteristic is crucial for maintaining the network’s decentralization and trustlessness, enabling nodes to independently verify the blockchain’s history and state. DAS is a method for verifying data availability without downloading the complete dataset, and is particularly suitable for lightweight nodes with limited storage capacity.

The concept of DAS was first introduced by Al-Bassam et al. [22]. In a DAS scheme, a potentially malicious block proposer encodes the block’s contents into a short commitment com and a larger codeword π using an erasure code. The commitment com is placed in the block header. To verify that the block data is available, lightweight nodes randomly sample a few positions in π. If those samples can be obtained successfully, then with high probability the entire block data is available. Early implementations of this idea discussed DAS only informally [30–32], without precise security definitions or formal proofs. Hall-Andersen et al. [23] addressed this gap by formally defining DAS as a cryptographic primitive and introducing erasure-code commitments as a way to guarantee data availability. They proved that a secure DAS scheme can be built from any erasure-code commitment that meets certain binding and availability properties.

To improve the efficiency of DAS in practice, Hall-Andersen et al. developed the FRIDA [26], which applies the FRI protocol to data availability. FRIDA avoids a trusted setup and achieves communication complexity that grows polylogarithmically with the block size. It was among the first schemes to explicitly integrate an IOPP into a DAS design, demonstrating that the FRI protocol can be adapted for checking data availability.

In parallel, Wagner et al. [33] presented PeerDAS, a scheme intended for integration into Ethereum. PeerDAS uses RS codes in combination with KZG polynomial commitments to enable sampling-based data availability checks for light clients. Their work describes optimizations for selecting random sample columns and verifying the corresponding commitments efficiently.

Despite these advances, existing DAS protocols still face scalability challenges. Even schemes with polylogarithmic complexity (such as FRIDA and PeerDAS) incur substantial communication and verification costs when block sizes become very large. Moreover, static choices of code rate or sampling density may be suboptimal under changing network conditions or adaptive adversaries. These limitations motivate ISTIRDA. ISTIRDA introduces adaptive folding and dynamic rate adjustment to tune the coding and sampling process for the data scale and threat model. In effect, ISTIRDA retains the security guarantees of IOPP-based DAS while significantly lowering communication and verification overhead in high-throughput, large-block settings. To highlight the advantages of our proposed scheme, Table 1 presents a comparison of existing schemes.

Key parameters. Let L⊆Σn be a language over alphabet Σ. For x,y∈Σn, the Hamming distance is d(x,y)=|{i∈[n]:xi≠yi}|. Write d(x,L)=miny∈Ld(x,y) and define the proximity set Lε={x∈Σn: d(x,L)≤εn}.

Completeness. If x∈L, an honest P makes V accept with probability at least 1−δ.

Soundness. If x∉Lε, any P^′ convinces V with probability at most γ.

Query complexity. Q=∑i=1rqi≪n.

Fig. 1 depicts the workflow of an IOPP. IOPP is an interactive protocol between a prover P and a verifier V that certifies x∈Lε with sublinear query access to x. The protocol runs for r rounds with per-round query budgets q1,…,qr. In round i, ci=Vi(m1,…,mi−1), mi=Pi(ci,x), Qi⊆[n], |Qi|≤qi, and V reads {xj}j∈Qi and checks consistency with mi. After r rounds V accepts if all checks pass.

In this paper, the sequence {ri} jointly drives adaptive folding and dynamic code-rate adjustment, contracting the evaluation domain over rounds and reducing communication and verification cost so that data availability can be certified with sublinear read access.

As visualized in Fig. 2, a message polynomial of degree strictly less than k is evaluated at n pairwise distinct field points to produce n coded symbols; because RS codes are maximum distance separable, any k symbols suffice to reconstruct the message.

Let Fq be a finite field and let α1,…,αn∈Fq be pairwise distinct. An (n,k,d) RS code encodes a message polynomial m(x)∈Fq[x] with deg⁡m<k (equivalently, deg⁡m≤k−1) by evaluation: c=(m(α1),…,m(αn)),R=kn. Since RS codes are maximum distance separable, the minimum (Hamming) distance is dmin=n−k+1 and the unique-decoding radius is t=⌊(n−k)/2⌋. Equivalently, encoding admits the cyclic form c(x)=m(x)xn−kmodh(x), for a suitable generator polynomial h(x), where n−k is the number of parity symbols.

For illustration, take n=8 and k=4. Then R=12 and dmin=n−k+1=5, so up to t=⌊(dmin−1)/2⌋=⌊(n−k)/2⌋=2 symbol errors can be uniquely corrected. Increasing redundancy (i.e., decreasing k/n) improves error-correction capability but raises communication and storage costs. In this paper, dynamic code-rate adjustment adapts k/n to balance target robustness against resource budgets, selecting appropriate rates across rounds and data scales.

Fig. 3 illustrates the end-to-end flow of the proposed protocol: The original data is first Reed-Solomon encoded to obtain the codeword π, which is then bound to the block header commitment com. This interaction phase then proceeds, progressing by round i. The prover publicly publishes a queryable view πi (derived from π through folding/state transfer). The verifier, comprised of two submodules, V1→tran→V2, collaborates to initiate sparse queries on πi and perform algebraic and cross-round consistency checks under the constraints of the public commitment com. tran is responsible for transferring/contracting the evaluation domain between rounds. Once all checks pass, the extractor extra combines the commitment with the sampled symbols to recover the original data. If any step fails, the data is deemed unusable.

In what follows, we refine STIR [29] by removing redundant steps and introducing two mechanisms: adaptive folding and dynamic code-rate adjustment. Unlike STIR’s fixed folding schedule, ISTIR selects the folding ratio per round based on the remaining evaluation domain, residual polynomial degree, and security/redundancy targets, thereby avoiding late-round over-redundancy and premature domain contraction; this reduces both evaluation points and communication, especially at large data scales. The dynamic code-rate rule re-optimizes the rate at each recursion rather than letting it decay on a fixed schedule, balancing early-round bandwidth savings with stronger late-round soundness. We then analyze the resulting complexity parameters, which serve as performance indicators for ISTIRDA.

We further prove that ISTIR satisfies opening consistency under our model, ensuring transcripts remain well-structured across rounds, either close to a valid codeword or rejected, thus precluding attacks that exploit recursive folding. This security foundation enables the standard transformation from ISTIR to an erasure-code commitment and, following FRIDA’s framework [26], to a complete DAS scheme, which we call ISTIRDA.

Table 2 lists the protocol parameters and definitions. The specific protocol execution steps are as follows.

Initialization. Define function f0:L0→F as a queried oracle. For an honest execution, the condition f0∈RS[F,L0,d0] holds true. Thus, the prover can respond accurately to oracle queries about polynomial f0. This polynomial belongs to the space F<d0[X] and is restricted to domain L0.

Initial Folding Step. The verifier randomly selects a folding scalar r0fold from the field F and transmits it.

Interactive Protocol Rounds. For round index i=1,…,M: (a)

Prover Polynomial Folding Transmission: The prover computes and submits the folded function hi:Li→F. Under honesty, hi corresponds exactly to the evaluated folding polynomial h^i:=PolyFold(fi−1,ki,ri−1fold) on domain Li.

Final Round. At this stage, the prover outputs a polynomial ρ∈F<dM[X] consisting of dM coefficients. When acting honestly, the polynomial satisfies ρ^=Fold(fM,kM,rMfold).

Verifier Decision Phase. The verifier executes the following verification steps: (a)

Iterative Verification Procedure: For i=1,…,M: i.

For each j∈[ti−1], the verifier evaluates Fold(fi−1,ki−1,ri−1fold)(ri−1,jISTIR,query). To do so, fi−1 must be accessed at all ki−1 evaluation points in Li−1, where the relation xki−1=ri−1,jISTIR,query holds.

Algorithm 1 gives the Fiat-Shamir compact form of the interactive protocol described above, where the challenge is derived in the random oracle model via rt=Hash(Tr). Throughout, we define ft≡kt (folding factor/rate), τmin denotes the decoding margin, requiring (1−ρ)/2≥τmin.

Complexity Parameters.

The protocol involves a total of 2M+1 communication rounds. During each round indexed by i∈{1,…,M}, the prover transmits the folded polynomial hi with length |Li|, a set of out-of-domain responses βi,1,…,βi,u, and the oracle function Filli, which contains at most ti−1+u symbols.

In the final stage, the prover additionally sends dM=d/∏j=0Mkj field elements. Hence, the total proof size accumulates to ∑i=1M(|Li|+u+ti−1)+d∏j=0Mkj. On the verifier’s side, it processes t0 queries, each requiring the evaluation of k0 points. Since the same set of k0 points is always accessed as a unit, this allows for treating them as a single composite symbol, and the input query cost in this alphabet is thus t0. For subsequent rounds i∈{1,…,M}, the verifier issues ti queries to the folded polynomial: Fold(fi−1,ki−1,ri−1fold), which necessitates reading ki−1 grouped symbols from the previous function fi−1.

In addition, the verifier may submit up to |Hi|≤ti−1 individual queries to fi. When i=1, these queries directly access terminal data. For i>1, however, fi represents a virtual layer, where each access is rerouted either to a single point evaluation of Filli−1, or to a corresponding position in hi−1, which again involves accessing ki−1 symbols. Because the ki symbols are accessed simultaneously, they can be compressed into a single higher-level symbol. Therefore, the query complexity of the proof string is 2⋅∑i=1Mti.

For different encoded data sizes D=|Data|, we compare the commitment size, encoding size, communication complexity per query, and the total communication complexity of being able to reconstruct the data with probability at least 1−2−40.

Fig. 4 presents a performance comparison among ISTIRDA, FRIDA, and other baseline schemes (Naive, Merkle) under different data sizes (D=1, D=32, D=128 MB), with respect to four evaluation metrics: Commitment size (KB), Encoding (MB), Communication cost per query (KB), and Total communication cost (MB). The communication cost incurred by ISTIRDA exhibits a significant advantage over that of the FRIDA scheme. Specifically, as the data size increases, the communication cost of FRIDA ranges from 1.25 to 2.46 times that of ISTIRDA. This advantage becomes even more pronounced in scenarios with large-scale data.

Prover computational time. In our tested dataset, the prover’s computational time for ISTIRDA is slightly longer compared to FRIDA. According to measurements, its slowdown ranges from approximately 0.64 to 0.95 times. As shown in Table 3, when processing data of size |Data|=16 MB, ISTIRDA takes 36.63 s to generate a proof sequentially, whereas FRIDA requires only 29.52 s.

Verifier computational time. The data shows that when the data size D=1 MB, FRIDA’s verification time is shorter than that of ISTIRDA. At D=16 MB, the verification times of both schemes are comparable. However, for data sizes exceeding 16 MB, ISTIRDA’s verification time becomes shorter than FRIDA’s, and the gap continues to widen as the data size increases. The underlying reason for this phenomenon is that when D<16 MB, ISTIRDA’s folding operation introduces computational overhead that outweighs its efficiency advantages. For larger data sizes, the folding operation’s computational overhead increases slowly. Its growth rate is significantly lower than the verifier’s data complexity growth. Therefore, for data sizes exceeding 16 MB, ISTIRDA’s verification time is significantly lower than that of FRIDA.

Fig. 5 shows how the time to reach a confident decision varies with node count and packet loss. We observe that as node count and packet loss increase, FRIDA’s TTC rises sharply, indicating that it becomes increasingly sensitive to load concentration. In contrast, ISTIRDA’s TTC curve is much flatter, indicating that its distributed P2P collaborative architecture shares the load and maintains relatively fast convergence to confidence. Thus, under large-scale or degraded network conditions, ISTIRDA exhibits a clear robustness advantage over FRIDA.