Vai al contenuto
Financial Context Wiki

Blobspace

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...