EIP-4844, znane też jako proto-danksharding, to propozycja zmiany protokołu Ethereum, która wprowadziła nowy typ transakcji przenoszącej tak zwane bloby – duże porcje danych, które nie są dostępne dla maszyny wirtualnej Ethereum (EVM), są relatywnie tanie w publikacji i po pewnym czasie automatycznie usuwane z warstwy bazowej. Rozwiązanie to zostało zaprojektowane jako etap przejściowy na drodze do pełnego shardingu danych.
Jak działają bloby
Jeden blob to stała, zdefiniowana w protokole ilość danych podzielona na tysiące elementów pola, co w sumie odpowiada około 128 kilobajtom. Bloby mają własny, niezależny rynek opłat – tak zwany blob gas – z regułą aktualizacji opłaty bazowej działającą na podobnej zasadzie jak mechanizm spalania opłat wprowadzony wcześniej w ogólnym rynku gazu Ethereum. Opłata za publikację bloba jest pobierana przed wykonaniem transakcji i spalana, bez możliwości jej zwrotu w razie niepowodzenia transakcji.
Do blobów odwołują się specjalne skróty wersjonowane, oparte na kryptograficznych zobowiązaniach typu KZG. Dedykowany precompile weryfikuje dowód KZG dla wskazanego punktu danych i potwierdza zgodność zobowiązania z odpowiadającym mu skrótem wersjonowanym, co pozwala smart kontraktom na łańcuchu głównym weryfikować fragmenty danych bloba bez konieczności ich pełnego przechowywania.
Tymczasowy charakter danych
Bloby (wraz z ich tak zwanymi „sidecars”) są przechowywane przez węzły warstwy konsensusu jedynie przez ograniczony okres – zgodnie z parametrami protokołu odpowiada to około osiemnastu dniom. Po tym czasie dane bloba są usuwane z warstwy konsensusu, a odpowiedzialność za ich dalszą archiwizację przechodzi na inne podmioty ekosystemu, na przykład operatorów rollupów czy niezależne serwisy indeksujące dane historyczne.
Przykład praktyczny
Rollupy optymistyczne, które publikują swoje dane w blobach, wykorzystują dowód KZG dla każdej wczytywanej wartości i weryfikują go za pomocą precompile’u point-evaluation, natomiast rollupy oparte na dowodach kryptograficznych stosują protokół dowodzący równoważności między własnym zobowiązaniem obliczeniowym i zobowiązaniem związanym z danym blobem, co pozwala potwierdzić, że opublikowane dane odpowiadają rzeczywiście wykonanym transakcjom.
Zmiany limitów pojemności
Początkowe parametry pojemności blobów wprowadzone razem z EIP-4844 były stosunkowo niskie i były kilkukrotnie zwiększane w kolejnych aktualizacjach protokołu Ethereum w miarę rozwoju infrastruktury sieciowej i wzrostu wykorzystania rollupów. Stan na sierpień 2026 roku: w wyniku kolejnych aktualizacji doprowadzających limity znacząco ponad poziom wprowadzony pierwotnie przy uruchomieniu EIP-4844, Ethereum zwiększyło docelową i maksymalną liczbę blobów na blok w ramach mechanizmu określanego jako fork BPO (blob parameter only), co pozwoliło obniżyć koszt publikacji danych dla rollupów. Kolejne zwiększenia limitów są wprowadzane stopniowo i zależą od bieżącego wykorzystania dostępnej przepustowości blobów oraz oceny deweloperów protokołu co do gotowości infrastruktury sieciowej na dalszy wzrost.
Ryzyka i ograniczenia
Dane opublikowane w blobach nie są trwałe – po około osiemnastu dniach znikają z warstwy konsensusu Ethereum, a odpowiedzialność za ich długoterminową archiwizację przechodzi na inne podmioty ekosystemu, co należy uwzględniać przy projektowaniu aplikacji zależnych od historycznej dostępności tych danych. EIP-4844 było świadomie zaprojektowane jako rozwiązanie przejściowe – pełny sharding danych wymaga dodatkowych elementów, takich jak dwuwymiarowe próbkowanie dostępności danych, budowa proponowania bloków oddzielona od ich zatwierdzania (PBS) oraz dowody przechowywania danych (proof of custody).
Redakcyjnie: parametry pojemności blobów zmieniają się wraz z kolejnymi forkami typu BPO, dlatego wszelkie konkretne liczby dotyczące limitów powinny być zawsze opatrzone datą odniesienia, a nie przedstawiane jako stały, niezmienny parametr protokołu.
Podsumowanie
EIP-4844 wprowadziło do Ethereum tani, tymczasowy sposób publikowania danych transakcyjnych rollupów w postaci blobów, weryfikowanych kryptograficznie za pomocą zobowiązań KZG. Mechanizm ten znacząco obniżył koszty działania rollupów i stanowi etap przejściowy w drodze do pełnego shardingu danych, przy czym jego parametry pojemności są stopniowo zwiększane w kolejnych aktualizacjach protokołu.
