Transakcja
Typ transakcji wprowadzony w EIP-4844 Ethereum, zaprojektowany w celu obniżenia opłat transakcyjnych poprzez przechowywanie danych w blobach oddzielnie od głównych danych transakcji.
Transakcje blob, wprowadzone poprzez Ethereum Improvement Proposal (EIP) 4844 (znane również jako Proto-Danksharding), stanowią znaczącą zmianę architektoniczną mającą na celu obniżenie opłat transakcyjnych, szczególnie dla rozwiązań skalujących warstwy drugiej (Layer 2). W przeciwieństwie do tradycyjnych transakcji Ethereum, które osadzają dane bezpośrednio w głównym calldata transakcji, transakcje blob wykorzystują oddzielną, choć nadal on-chain, strukturę danych zwaną 'blobami'. Bloby te są zaprojektowane tak, aby ich publikowanie było tańsze i podlegają innym limitom gazu oraz mechanizmom cenowym niż zwykłe dane transakcyjne. Głównym celem jest obniżenie kosztu dostępności danych dla rollupów. Rollupy agregują transakcje off-chain i publikują skompresowane podsumowanie lub dowód w głównym łańcuchu Ethereum (Layer 1). Koszt publikowania tych danych w Layer 1 jest głównym wąskim gardłem. EIP-4844 wprowadza nowy typ transakcji, który pozwala rollupom na publikowanie większych ilości danych taniej, poprzez rozdzielenie ich do tych blobów. Bloby te nie są bezpośrednio przetwarzane przez Ethereum Virtual Machine (EVM), lecz są potwierdzane za pomocą schematu zobowiązań wielomianowych KZG (Kalai-Shen-Goldwasser). To zobowiązanie jest zawarte w nagłówku bloku, zapewniając dostępność danych bez konieczności pobierania i przechowywania pełnych danych blob przez każdy węzeł w nieskończoność. To rozdzielenie i specjalistyczne przetwarzanie znacząco redukuje koszt gazu związany z dostępnością danych, czyniąc rollupy bardziej opłacalnymi ekonomicznie i tym samym zwiększając ogólną skalowalność Ethereum.
graph LR
Center["Transakcja"]:::main
Pre_digital_signature["digital-signature"]:::pre --> Center
click Pre_digital_signature "/terms/digital-signature"
Pre_private_key["private-key"]:::pre --> Center
click Pre_private_key "/terms/private-key"
Rel_block["block"]:::related -.-> Center
click Rel_block "/terms/block"
Rel_smart_contract["smart-contract"]:::related -.-> Center
click Rel_smart_contract "/terms/smart-contract"
Rel_data_availability["data-availability"]:::related -.-> Center
click Rel_data_availability "/terms/data-availability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Wyjaśnij jak 5-latkowi
Wyobraź sobie wysyłanie dużej paczki (Twojej transakcji), gdzie kiedyś płaciłeś dużo za dołączenie wszystkich materiałów wypełniających do środka. Transakcje blob pozwalają wysłać te materiały wypełniające osobno i znacznie taniej, co sprawia, że całkowity koszt dostawy jest znacznie niższy.
🤓 Expert Deep Dive
EIP-4844 fundamentalnie zmienia strategię dostępności danych w Ethereum poprzez wprowadzenie 'blobów' i zobowiązań KZG. Bloby to ciągłe porcje danych dołączane do bloku, z maksymalnym rozmiarem i oddzielnym limitem gazu, różnym od calldata. Co kluczowe, bloby nie są bezpośrednio dostępne dla logiki kontraktów EVM; ich głównym celem jest weryfikacja dostępności danych. Zobowiązanie do danych blob jest realizowane za pomocą zobowiązań wielomianowych KZG, gdzie dane blob reprezentują współczynniki wielomianu, a zobowiązanie jest punktem na krzywej eliptycznej. Pozwala to na efektywne generowanie i weryfikację dowodów. Węzły są zobowiązane do pobierania danych blob przez ograniczony czas (np. ~4096 bloków lub ~27 godzin) w celach weryfikacyjnych, po czym mogą je usunąć, redukując nadmierne obciążenie stanu. Koszt gazu za publikowanie blobów jest znacznie niższy niż dla calldata, obliczany na podstawie rozmiaru bloba i oddzielnej 'ceny gazu za blob'. Ten mechanizm jest prekursorem pełnego Dankshardingu, gdzie przestrzeń blobów zostanie rozszerzona i rozproszona na wiele shardów. Kompromisy obejmują złożoność schematu zobowiązań KZG i tymczasowe wymagania dotyczące przechowywania dla węzłów, ale główną korzyścią jest znacząca redukcja kosztów publikowania danych przez rollupy.