Транзакция
Тип транзакции, представленный в EIP-4844 Ethereum, предназначенный для снижения комиссий за транзакции путем отдельного хранения блобов данных от основных данных транзакции.
Blob transactions, introduced via Ethereum Improvement Proposal (EIP) 4844 (also known as Proto-Danksharding), represent a significant architectural shift aimed at reducing transaction fees, particularly for Layer 2 scaling solutions. Unlike traditional Ethereum transactions that embed data directly within the main transaction calldata, blob transactions utilize a separate, albeit still on-chain, data structure called 'blobs'. These blobs are designed to be cheaper to post and are subject to different gas limits and pricing mechanisms than regular transaction data. The primary motivation is to lower the cost of data availability for rollups. Rollups bundle transactions off-chain and post a compressed summary or proof to the main Ethereum chain (Layer 1). The cost of posting this data to Layer 1 is a major bottleneck. EIP-4844 introduces a new transaction type that allows rollups to post larger amounts of data more cheaply by separating it into these blobs. These blobs are not directly processed by the Ethereum Virtual Machine (EVM) but are instead committed to via a KZG (Kalai-Shen-Goldwasser) polynomial commitment scheme. This commitment is included in the block header, ensuring data availability without requiring every node to download and store the full blob data indefinitely. This separation and specialized handling significantly reduce the gas cost associated with data availability, making rollups more economically viable and thus enhancing Ethereum's overall scalability.
graph LR
Center["Транзакция"]:::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;
🧒 Простыми словами
Представьте общую записную книжку, за которой все следят. Транзакция — это как написать строчку в этой книжке: «Алиса дает 5 яблок Бобу». Но вы не можете просто написать это; вы должны поставить свою уникальную сургучную печать (подпись), чтобы все знали, что это действительно вы разрешили.
🤓 Expert Deep Dive
EIP-4844 кардинально меняет стратегию доступности данных в Ethereum, вводя «блобы» и KZG-коммитменты. Блобы — это непрерывные фрагменты данных, прикрепляемые к блоку, с максимальным размером и отдельным лимитом газа, отличным от calldata. Важно отметить, что блобы напрямую недоступны для логики смарт-контрактов EVM; их основная цель — проверка доступности данных. Коммитмент к данным блобов достигается с помощью KZG-полиномиальных коммитментов, где данные блоба представляют собой коэффициенты полинома, а коммитмент — точку на эллиптической кривой. Это позволяет эффективно генерировать и проверять доказательства. Узлы обязаны загружать данные блобов в течение ограниченного периода времени (например, ~4096 блоков или ~27 часов) для целей проверки, после чего они могут удалить их, уменьшая раздувание состояния. Стоимость газа для публикации блобов значительно ниже, чем для calldata, и рассчитывается на основе размера блоба и отдельной «цены газа за блобы». Этот механизм является предшественником полного Danksharding, где пространство блобов будет расширено и распределено по нескольким шардам. Компромиссы включают сложность схемы KZG-коммитментов и требование временного хранения для узлов, но основным преимуществом является существенное снижение затрат на публикацию данных роллапов.