---
title: "Blobspace"
description: "Guida basata sulla verifica di blobspace Ethereum, capacità codificata e utilizzabile, campionamento e custodia PeerDAS, conservazione temporanea, derivazione dei rollup e limiti correnti dipendenti dal fork."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Blobspace
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Blobspace è la capacità limitata e temporanea di Ethereum per la disponibilità dei dati nei blob impegnati insieme ai blocchi. Non è blockspace di esecuzione EVM, storage dei contratti, filesystem permanente né token. Una transazione di tipo 3 contiene hash versionati; i dati autenticati del blob viaggiano nei sidecar del livello di consenso o nelle colonne di dati PeerDAS. L'EVM può consultare un hash versionato e verificare un'apertura puntuale, ma non leggere direttamente la payload del blob.
PeerDAS estende i blob con codifica di cancellazione, divide la matrice estesa in `128 columns` e consente ai nodi di custodire e campionare sottoinsiemi, senza imporre a ogni nodo di scaricare ogni blob completo. Ciò permette una valutazione probabilistica locale della disponibilità, non dimostra la validità dell'esecuzione del rollup, la finalità Ethereum, la sicurezza del bridge o il recupero permanente. La capacità cambia in base al fork. Al `2026-08-13`, la mainnet Ethereum dopo Fusaka BPO2 ha un obiettivo di `14 blobs per block` e consente al massimo `21`; ogni transazione di blob è limitata a `6 blobs`.
## Come funziona
1. Fissa rete, blocco o slot, fork e pianificazione Blob-Parameter-Only attivi, oltre a rollup e versione di derivazione. I parametri storici `3/6`, quelli Pectra `6/9`, gli attuali `14/21`, quelli di testnet e quelli futuri non sono intercambiabili.
2. Identifica l'oggetto pubblicato: transazione di tipo 3, hash versionati, commitment e prove KZG, indici dei blob, origine L1 e se il rollup ha realmente usato blob Ethereum anziché calldata o DA alternativa. Un commitment vincola i dati, ma da solo non prova che i byte fossero disponibili.
3. Separa le unità. Un blob contiene `4,096 field elements * 32 bytes = 131,072 encoded bytes`; una payload senza restrizioni usa generalmente `31 bytes` per elemento di campo, ossia `126,976 usable bytes`. Compressione, framing, padding, gas del blob, celle estese per erasure coding e byte applicativi sono quantità diverse.
4. Verifica i limiti della pianificazione. L'obiettivo guida la retroazione dei prezzi, ma non è capacità riservata. Il massimo per blocco è un limite di consenso, non il throughput atteso. Il limite PeerDAS di `6 blobs per transaction` è distinto dall'attuale massimo di `21 blobs per block`.
5. Verifica il percorso di disponibilità. PeerDAS usa estensione di cancellazione unidimensionale, celle e colonne autenticate, gossip e richieste ai peer. Con i parametri attuali, un nodo campiona almeno `8 columns` e ha obblighi di custodia; acquisire almeno `64 of 128 columns` permette di ricostruire la matrice estesa.
6. Traccia stati distinti del ciclo di vita: commitment incluso, colonne ottenute e verificate, controllo DA locale superato, blocco L1 safe o finalized, batch del rollup decodificato e derivato, finestra minima di servizio attiva e archivio indipendente testato. La disponibilità non rende veri tutti gli stati successivi.
7. Simula colonne mancanti, eclipse o partizione, propagazione ritardata, riorganizzazione L1, divergenza di pianificazione o client, aggiornamento del formato rollup e perdita dell'archivio. Recupera, ricostruisci e conserva i dati necessari prima della scadenza della finestra; per la contabilità dei costi di batcher e utenti usa il tema separato sulle commissioni dei blob.
## Esempi svolti
- **Unità in byte di un blob.** La capacità codificata è `4,096 * 32 = 131,072 bytes = 128 KiB`. La payload arbitraria generale è `4,096 * 31 = 126,976 bytes = 124 KiB`. La differenza è `4,096 bytes`, cioè il `3.125%` della capacità codificata; compressione e framing del rollup riducono ulteriormente la payload applicativa.
- **Capacità attuale per blocco.** All'obiettivo, `14 * 131,072 = 1,835,008 encoded bytes = 1.75 MiB` e `14 * 126,976 = 1,777,664 usable bytes = 1.6953125 MiB`. Al massimo, `21 * 131,072 = 2,752,512 encoded bytes = 2.625 MiB` e `21 * 126,976 = 2,666,496 usable bytes = 2.54296875 MiB`. Sono limiti mainnet specifici della data e precedenti a compressione e framing.
- **Limiti di transazione e blocco.** Una transazione con `6 blobs` trasporta `786,432 encoded bytes = 0.75 MiB` e `761,856 usable bytes = 0.7265625 MiB`. Un blocco massimo da `21-blob` richiede almeno `4 transactions`, per esempio `6 + 6 + 6 + 3`; un blocco-obiettivo da `14-blob` può essere `6 + 6 + 2`. Nessuna distribuzione riserva capacità a un rollup.
- **Finestra di servizio e volume nominale.** `4,096 epochs * 32 slots * 12 seconds = 1,572,864 seconds = 18.2044444444 days`. Con `7,200 slots per day` nominali e obiettivo `14-blob`, il volume codificato è `100,800 blobs per day = 12.3046875 GiB per day`, mentre quello generalmente utilizzabile è `11.920166015625 GiB per day`. Slot mancati e inclusione effettiva cambiano il totale; la finestra non promette un archivio permanente.
## Rischi
- Applicare un fork o una pianificazione Blob-Parameter-Only obsoleti.
- Mescolare limiti di mainnet, testnet o un'altra rete.
- Trattare l'obiettivo come capacità garantita o riservata.
- Trattare il massimo come throughput normale atteso.
- Confondere il limite di sei blob per transazione con quello del blocco.
- Mescolare unità codificate, utilizzabili, compresse, framed e di gas del blob.
- Omettere padding o overhead del formato rollup.
- Etichettare calldata o DA alternativa come blobspace Ethereum.
- Accettare un hash versionato non corrispondente al commitment del blob.
- Trattare un'apertura KZG valida come prova della disponibilità dei byte.
- Trattare il campionamento come download locale completo di ogni blob.
- Confondere disponibilità dei dati e validità della transizione di stato.
- Confondere controllo DA locale e finalità L1 o del rollup.
- Perdere colonne per ritardo, eclipse, partizione o peer correlati.
- Non riuscire a ricostruire o richiedere ai peer nonostante la capacità nominale.
- Perdere o riordinare il commitment in una riorganizzazione L1.
- Lasciare scadere la finestra minima prima di derivazione o contestazione.
- Dipendere da un archivio o indexer non disponibile, corrotto o incompleto.
- Fallire la derivazione dopo un aggiornamento di compressione o protocollo.
- Presumere bridge o exit sicuri solo perché i dati dei blob erano disponibili.
## Errori comuni
- Blobspace è storage permanente che i contratti possono leggere come calldata.
- Ogni byte di un blob da `128 KiB` è payload applicativa senza restrizioni.
- Con PeerDAS, ogni nodo Ethereum scarica e conserva per sempre ogni blob completo.
- Un commitment KZG, un campione riuscito o un'inclusione finalizzata provano che lo stato del rollup è corretto e che gli utenti possono uscire.
- La capacità mainnet è fissata per sempre a `3/6`, `6/9` o alla pianificazione attuale `14/21`.
## Argomenti correlati
- [Commissioni dei blob e costi dei rollup](/it/crypto/blob-fee-rollup-cost/)
- [Campionamento della disponibilità dei dati](/it/crypto/data-availability-sampling/)
- [Rollup](/it/crypto/rollup/)
## Fonti
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethereum.org/EIPS/eip-7594) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7840: Add blob schedule to EL config files](https://eips.ethereum.org/EIPS/eip-7840) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [EIP-7892: Blob Parameter Only Hardforks](https://eips.ethereum.org/EIPS/eip-7892) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Checkpoint #8: Jan 2026](https://blog.ethereum.org/2026/01/20/checkpoint-8) - Ethereum Foundation Blog (consultato: 2026-08-13)
- [Fulu -- Data Availability Sampling Core](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/das-core.md) - Ethereum Consensus Specifications (consultato: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultato: 2026-08-13)
- [Blockchain Data Storage Strategies](https://ethereum.org/developers/docs/data-availability/blockchain-data-storage-strategies/) - Ethereum.org (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/blobspace/index.mdx