The Future of Blobs

The Future of Blobs

Post-quantum data availability and beyond

Francesco Risitano · 12 October 2026

Francesco Risitano · 2026
The Future of Blobs

LeanVM Construction 1 — RLC + FRI Fold

RLC + FRI fold diagram

1. Commit rows and sample the RLC challenge. The transcript binds every row root before sampling ρ\rho.

D=H(root⁡(C0),…,root⁡(CB−1)),ρ=H(D)D = H(\operatorname{root}(C_0),\ldots,\operatorname{root}(C_{B-1})), \qquad \rho = H(D)

2. Build one extension-field aggregate codeword. Every column is combined with powers of ρ\rho.

C⋆[j]=∑i=0B−1ρiCi[j]C^\star[j] = \sum_{i=0}^{B-1}\rho^i C_i[j]

3. Fold the aggregate in the leanVM trace. Each round halves the domain.

C(t+1)[j]=C(t)[2j]+C(t)[2j+1]2+βtC(t)[2j]−C(t)[2j+1]2xjC^{(t+1)}[j] = \frac{C^{(t)}[2j] + C^{(t)}[2j+1]}{2} + \beta_t \frac{C^{(t)}[2j] - C^{(t)}[2j+1]}{2x_j}

4. Assert exact RS membership. The final folded vector must be constant.

C(log⁡n)[0]=C(log⁡n)[1]=⋯C^{(\log n)}[0]=C^{(\log n)}[1]=\cdots

benchmark parameters prove message throughput proof
leanDAS headline B=240, n=4096B=240,\ n=4096, half-rate 5.28 s 364 KB/s 356 KiB
Implementation: circuit.py
Run: cargo run --release --bin leandas -- -m 240 -n 4096 --zkvm
Francesco Risitano · 2026
The Future of Blobs

LeanVM Construction 2 — Barycentric Check Per Row

Barycentric row check diagram

1. Commit rows and sample the barycentric point. The same challenge is used for all row checks.

D=H(root⁡(C0),…,root⁡(CB−1)),r=Decode⁡E(D)D = H(\operatorname{root}(C_0),\ldots,\operatorname{root}(C_{B-1})), \qquad r = \operatorname{Decode}_{\mathbb{E}}(D)

2. Build the evens/odds barycentric slices. For row domain roots u=w2u=w^2:

sL[j]=rM−1ru−j−1,sR[j]=−rM+1rw−1u−j−1s_L[j]=\frac{r^M-1}{r u^{-j}-1}, \qquad s_R[j]=-\frac{r^M+1}{r w^{-1}u^{-j}-1}

3. Check every row independently. For Ci=(v0,…,v2M−1)C_i=(v_0,\ldots,v_{2M-1}):

∑j=0M−1sL[j] v2j=∑j=0M−1sR[j] v2j+1\sum_{j=0}^{M-1} s_L[j]\,v_{2j} = \sum_{j=0}^{M-1} s_R[j]\,v_{2j+1}

blobs bytecode cycles Poseidon16 ExtOp proof throughput
8 59,560 131,254 81,920 180,236 316.09 KiB 836.91 KiB/s
16 59,656 213,286 163,840 311,308 334.89 KiB 930.65 KiB/s
32 59,848 377,350 327,680 573,452 351.21 KiB 949.17 KiB/s
Implementation: lean_da.py, barycentric.py
Run: cargo run --release -p lean-da -- --n-blobs 32
Francesco Risitano · 2026
The Future of Blobs

LeanVM Construction 3 — Systematic Row Digests + Column Merkle Commitments + Row Barycentric Checks

Column Merkle commitment diagram

1. Hash each cell. Split every row into aligned cells of LL extension-field elements. Cell jj starts at offset jLjL, then its base-field limbs are chunked and chain-hashed into one 8-FE digest.

celli,j=Ci[jL .. (j+1)L)∈EL\mathrm{cell}_{i,j}=C_i[jL\,..\,(j+1)L)\in\mathbb{E}^{L}

qi,j=Hchain(chunks⁡(limbs⁡F(celli,j)))∈F8q_{i,j}=H_{\mathrm{chain}}(\operatorname{chunks}(\operatorname{limbs}_{\mathbb{F}}(\mathrm{cell}_{i,j})))\in\mathbb{F}^{8}

2. Chain only systematic cell digests into one digest per row. The row digest ignores parity cells.

rowi=Hchain(qi,0,…,qi,Nsys−1)\mathrm{row}_i=H_{\mathrm{chain}}(q_{i,0},\ldots,q_{i,N_{\mathrm{sys}}-1})

Rrows=Hchain(row0,…,rowB−1)R_{\mathrm{rows}}=H_{\mathrm{chain}}(\mathrm{row}_0,\ldots,\mathrm{row}_{B-1})

3. Merkle-commit each column, then bind row and column commitments together. Non-power-of-two row counts are zero-padded inside each column tree.

colj=Merkle⁡(q0,j,q1,j,…,qB−1,j,0,…,0)\mathrm{col}_j=\operatorname{Merkle}(q_{0,j},q_{1,j},\ldots,q_{B-1,j},0,\ldots,0)

Rcol=Merkle⁡(col0,…,colN−1)R_{\mathrm{col}}=\operatorname{Merkle}(\mathrm{col}_0,\ldots,\mathrm{col}_{N-1})

D=H(Rrows,Rcol),r=DD=H(R_{\mathrm{rows}},R_{\mathrm{col}}), \qquad r=D

4. Run the standard row barycentric LDT. The same evens/odds identity is checked for every row.

∑j=0M−1sL[j] Ci[2j]=∑j=0M−1sR[j] Ci[2j+1]\sum_{j=0}^{M-1}s_L[j]\,C_i[2j] = \sum_{j=0}^{M-1}s_R[j]\,C_i[2j+1]

blobs bytecode cycles Poseidon16 ExtOp proof throughput
12 228,887 261,655 133,135 245,772 319.83 KiB 770.04 KiB/s
24 382,927 448,463 266,271 442,380 338.14 KiB 711.70 KiB/s
44 688,871 819,943 493,631 770,060 361.56 KiB 1,102.26 KiB/s
46 689,939 821,011 513,087 802,828 363.20 KiB 1,150.06 KiB/s
Implementation: lean_da_column_commit.py
Run: cargo run --release -p lean-da -- --construction column-commit --n-blobs 46 --tracing
Francesco Risitano · 2026
The Future of Blobs

LeanVM Construction 3 — the commitment visualised

leanDA commitment pipeline

Francesco Risitano · 2026
The Future of Blobs

LeanAIR

LeanAIR circuit design

Francesco Risitano · 2026
The Future of Blobs

da.fast — Autoresearch data availability algorithm

  • Foundations of Data Availability Sampling — Hall-Andersen, Simkin and Wagner: define the desired properties
  • Lean formalization exists: github.com/b-wagn/fv-pq-da
Francesco Risitano · 2026
The Future of Blobs

BiB — Block-in-Blobs

EIP-8142 title

EIP-8142 abstract

Francesco Risitano · 2026
The Future of Blobs

To blob or not to blob

  • The proposal. Under BiB we gossip payload blobs anyway. So blob transactions look redundant — drop them, and put the data in calldata instead.
  • It bloats the payload. Calldata is payload; blobs are not.
  • It changes the retention class. Payload must be retained to the history requirement. Blobs have a fixed, bounded lifespan.
Francesco Risitano · 2026
The Future of Blobs

Blob Packing

  • Defer blob packing to the builder. Blobs are not formed until the builder has built the payload, so the bandwidth all lands on the hot path — no sparse blob pool, and no ahead-of-time distribution.
  • Allow dynamically sized cells. Every blob is 128 cells whatever its size, and each cell commits to data of arbitrary size.
  • Price it as fixed plus marginal. The 128 cells and their Merkle paths are a fixed overhead per blob regardless of size; the data itself is a cost per byte.
Francesco Risitano · 2026
The Future of Blobs

Blobpool proving

  • Generate a proof per blob transaction.
  • Generate recursive proofs of the blob transaction in the pool, and use EIP-8288 for recursive aggregation.
Francesco Risitano · 2026
The Future of Blobs

Decentralised state & history

  • Shard peers into state custody groups. Each peer is assigned a shard rather than the whole state.
  • Enhanced BALs carry merkle branches for the boundaries of each shard, and the BALs are placed in blobs.
  • Each peer maintains a finalized snapshot of its assigned shard and advances it using those enhanced BALs.
  • Availability of state updates is ensured by erasure coding.
  • Durability is ensured by replicating each shard across peers.
  • Mempools are maintained by requesting state proofs from peers and updating them with BALs.
Francesco Risitano · 2026