Badacze Ethereum eksplorują proponowany projekt, który przenosi dane ładunku wykonawczego (execution-payload) do blobów publikowanych obok bloków, mając na celu zmniejszenie zapotrzebowania na przepustowość i umożliwienie większej skalowalności.

W niedawnym poście badawczym zatytułowanym „Bloki umarły. Niech żyją Bloby”, współautorem którego jest Toni Wahrstatter i inni współtwórcy Ethereum, autorzy przedstawiają EIP-8142, czyli „Block-in-Blobs” – wstępny projekt propozycji wprowadzony po raz pierwszy w tym roku.

Projekt zakładałby kodowanie danych transakcyjnych bezpośrednio w blobach — formacie danych wprowadzonym w ulepszeniu Ethereum EIP-4844 — zamiast wymagać od walidatorów pobierania i ponownego wykonywania pełnych ładunków wykonawczych.

Według badaczy, pomysł ten ma na celu wyeliminowanie wąskiego gardła w architekturze Ethereum.

Rosnące rozmiary bloków, w połączeniu z wyższymi limitami gazu, oznaczają, że walidatorzy muszą pobierać i weryfikować coraz większy zbiór danych. Zwiększa to presję na przepustowość i ogranicza skalowalność.

W marcu 2024 roku, bloby zostały wprowadzone jako część planu działania Ethereum w zakresie dostępności danych podczas aktualizacji Dencun.

Dostarczone poprzez EIP-4844, znane również jako proto-danksharding, bloby są zaprojektowane do bardziej efektywnego przenoszenia dużych fragmentów danych niż standardowe calldata transakcji.

Zamiast przechowywać wszystkie szczegóły transakcji bezpośrednio w łańcuchu (onchain) i wymagać od walidatorów przetwarzania tych danych, bloby umożliwiają kryptograficzne zatwierdzanie i weryfikację danych bez pełnej replikacji w całej sieci.

Block-in-Blobs

EIP-8142 rozwija tę ideę.

Zamiast traktować bloby jako pomocniczą warstwę danych, propozycja przenosi podstawowe dane ładunku wykonawczego — już zakodowane w standardowym formacie RLP Ethereum — do samych blobów.

Walidatorzy weryfikowaliby wówczas kryptograficzne zobowiązania (commitments) do tych blobów, a z czasem polegaliby na próbkowaniu dostępności danych (data availability sampling). W ten sposób mogą weryfikować małe fragmenty danych, aby upewnić się, że cały zbiór danych istnieje, bez konieczności pobierania go w całości.

Zmiana staje się szczególnie istotna w przyszłości, w której systemy zkEVM będą obsługiwać weryfikację wykonania.

Dowody zerowej wiedzy (zero-knowledge proofs) mogą potwierdzić, że transakcje zostały przetworzone poprawnie, eliminując potrzebę ponownego wykonywania każdej transakcji przez walidatorów.

Jednakże same te dowody nie gwarantują, że dane transakcyjne są faktycznie dostępne. „W ramach zkEVM, walidatorzy weryfikują dowody, a nie bezpośrednio transakcje” – napisał Wahrstatter. Zauważył również, że bez oddzielnego mechanizmu dane mogłyby zostać zatajone, a mimo to przechodziłyby pomyślnie kontrole konsensusu.

Propozycja argumentuje, że Block-in-Blobs ma na celu wypełnienie tej luki.

Poprzez osadzanie danych transakcyjnych w blobach z kryptograficznymi zobowiązaniami, propozycja czyni dostępność danych jawną, a nie niejawną, umożliwiając walidatorom próbkowanie danych zamiast pobierania ich w całości, przy jednoczesnym zachowaniu gwarancji bezpieczeństwa.

Istnieją również szersze implikacje dotyczące sposobu, w jaki Ethereum rozlicza dane.

Obecnie Ethereum nadal oddziela gaz wykonawczy od wykorzystania danych blobów. W ramach nowego modelu, oba te elementy mogłyby zostać ujednolicone w jeden system „gazu danych” (data gas). Jeśli zostanie to pomyślnie wdrożone, badacze twierdzą, że wyrówna to koszty we wszystkich formach dostępności danych i pozwoli uniknąć nakładających się limitów.

ERC-8211 firmy Biconomy

Niezależnie od tego, trwają prace nad ulepszeniem struktury i wykonania samych transakcji.

Biconomy, we współpracy z zespołem UX Ethereum Foundation, zaproponowało ERC-8211, standard, który przekształca transakcje w programowalne przepływy pracy (workflows).

Zamiast stałych parametrów ustawianych podczas podpisywania, ERC-8211 umożliwia transakcjom pobieranie danych onchain w czasie rzeczywistym, walidację warunków i wykonywanie wielu kroków w sekwencji za pomocą jednego podpisu. Celem jest zmniejszenie liczby nieudanych transakcji i umożliwienie bardziej złożonych, sterowanych przez agentów interakcji w protokołach DeFi, jak wyjaśniono w wątku Biconomy na X.

Oba te rozwiązania wpisują się w szerszą falę eksperymentów w ekosystemie Ethereum. Badacze nakreślili wieloletnie ścieżki modernizacji do końca dekady, po zeszłorocznym wdrożeniu podwójnego hard forka.