Что из себя представляет EIP-4844? Разбираемся, что такое прото-данкшардинг и блобы, как они работают и как отправить свою первую блоб-транзакцию, используя новое предложение об улучшении Ethereum.
Введение
EIP-4844 (Ethereum Improvement Proposal) вводит в блокчейн Ethereum новый тип транзакций, который позволяет блокчейн‑роллапам проводить расчеты по своим транзакциям дешевле. Эти новые транзакции содержат большие куски данных, называемые «блобами», которые удаляются через короткий промежуток времени.
В этой статье мы рассмотрим:
Что такое EIP-4844?
Что такое блоб‑транзакции?
Зачем они были введены?
Прежде чем перейти к ответу на вопрос о том, что такое EIP-4844, нам необходимо разобраться с различными видами транзакций.
Типы транзакций в блокчейне
При выполнении «нормальной» транзакции все ваши данные хранятся в цепочке вечно. Наиболее распространенным типом транзакций сегодня является транзакция типа 2, но существуют и другие:
Транзакции типа 0: так называемые «legacy» (устаревшие) транзакции старого формата
Транзакции типа 1: они же транзакции со «списком доступа» (access list, введены EIP-2930).
Транзакции типа 2: новая «норма» (введена EIP-1559)
Транзакции типа 3: так называемые «блоб»‑транзакции (введены в EIP-4844).
Вот именно о транзакциях третьего типа, блобах, представленных в новом EIP-4844, мы и поговорим в этой статье.
Что такое блоб-транзакция?
Блоб‑транзакции, представленные в EIP-4844 как «прото‑данкшардинг», добавляют в Ethereum новую структуру данных, которая удаляется из цепочки примерно через 20–90 дней.
Этот большой кусок данных, который мы в конце концов удаляем, известен как «блоб» (blob) — аббревиатура, означающая «Binary Large OBject».
Блоб‑транзакции были включены в обновление Ethereum Dencun 03/13/2024, и блокчейн‑роллапам это очень понравилось. Они были добавленны из EIP-4844, также известного как «прото‑данкшардинг» (названного так в честь исследователей, которые его создали, а не потому, что название звучит круто).
Многие люди используют аналогию с «мотоколяской» (sidecar), где блоб — это коляска, а мотоцикл — это транзакция.
Продолжая аналогию, представьте, что мы поджигаем мотоколяску и выбрасываем ее где‑то через месяц.
Размещение данных в блобе значительно удешевляет для роллапов проведение транзакций в L1. Но прежде чем мы поймем, почему/как это работает, нам нужно разобраться с ценообразованием на газ для транзакций. Даже если вам кажется, что вы уже хорошо в этом разбираетесь, все‑равно почитайте пожалуйста следующий раздел.
Зачем транзакциям в блокчейне вообще нужен какой-то там газ?
Прежде чем мы поймем, зачем в новом EIP-4884 были добавлены блобы, давайте сначала разберемся, почему с нас взимается плата за отправку транзакции.
Когда мы делаем что‑либо в бокчейне, каждый узел блокчейна должен вычислить или сохранить какие‑то данные. Мы платим «за газ», потому что при отправке транзакции мы просим тысячи компьютеров выполнить много работы, что конечно же будет стоить им каких‑то денег.
Вычисления: Затраты на электроэнергию
Хранение: Аппаратные затраты
Отправка сообщений: Сетевой трафик также генерирует расходы
И так, если бы мы захотели сохранить 20 ГБ фильма «Шрек» в блокчейне, нам пришлось бы помочь тысячам узлов оплатить оборудование, необходимое для хранения фильма «Шрек».
Поэтому всякий раз, когда мы просим узел «сделать что‑нибудь», мы должны заплатить за газ. Если мы скажем: «Вам нужно хранить 20 ГБ фильма „Шрек“ вечно» (именно так раньше работал Ethereum, где все данные хранились по сути вечно), то мы должны заплатить гораздо больше, чем если бы мы попросили их хранить Шрека всего несколько месяцев.
Пока запомните это, мы еще к этому вернемся.
Почему мы решили добавить блоб-транзакции?
Так зачем же мы дали транзакциям это дополнительное поле для сброса данных?
Что ж, это возвращает нас к самой большой проблеме Ethereum на сегодняшний день:
Отправка 1 доллара по Ethereum обходится мне в 2 доллара, что является проблемой масштабирования. Это вытекает из трилеммы блокчейна — концепции, согласно которой сеть блокчейна в любой момент времени может достичь только двух из трех следующих свойств:
Децентрализация
Безопасность
Масштабируемость
Ethereum стремится быть максимально децентрализованным и безопасным, поэтому ему сложно масштабироваться.
Как сообщество, мы решили, что оптимистические и основанные на методах доказательства с нулевым разглашением («zero‑knowledge») блокчейн‑роллапы — это то, как мы будем масштабировать ETH в ближайшей и долгосрочной перспективе Ethereum. Роллапы помогают нам масштабировать ETH, выполняя транзакции в своей роллап‑цепочке, объединяя их и затем регистрируя («settle») их обратно в L1 (Ethereum). Это делает транзакции дешевле, сохраняя при этом многие свойства безопасности Ethereum.
Многие блокчейны второго уровня (Layer-2), обрабатывающие транзакции, такие как zkSync, Arbitrum и Optimism, позволяют проводить гораздо больше транзакций гораздо дешевле, поскольку они сжимают их в пакеты (батчи).
Когда эти L2 отправляют пакет обратно в Ethereum, Ethereum в свою очередь приходится проделать немного работы, чтобы убедиться в том, что пакет транзакций валиден, и вот здесь‑то и кроется проблема.
Ethereum нужно только один раз убедиться в том, что пакет валиден, после чего эти данные больше никогда не понадобятся. Но до появления EIP-4844 у Ethereum не было (хорошего) способа удалить данные, поэтому он хранил их вечно.
Проблема очевидна:
Нам нужна эта большая порция данных всего для одной проверки.
Больше эти данные никому не нужны.
Но после этой проверки каждый узел ETH на планете должен хранить эти данные.
Это как если бы каждый раз, когда вы сдавали экзамен в школе, вам приходилось бы носить его с собой. Через 20 лет вы, по сути, просто ходите с огромной охапкой бумаг — от докторской диссертации до контрольной по правописанию, когда вы учили, как пишется слово «кошка».
Возвращаясь к нашему предыдущему примеру со Шреком, мы видим, как все это связано.
Роллапы тратили уйму газа на отправку огромного блока данных, который был нужен им лишь на одно мгновение. А роллапы — это ключ к масштабированию Ethereum, поэтому мы должны уделять им особое внимание. Можем ли мы что‑то сделать, чтобы облегчить им жизнь?
«А что, если мы просто удалим данные после подтверждения транзакций?»
Так на свет и появились блобы.
Как блобы используются для проверки роллап-транзакций?
Как же блобы используются на практике?
Вместо того чтобы отправлять пакте транзакций и хранить эти данные вечно, сейчас процесс происходит следующим образом:
Роллап (например, zkSync) сжимает список транзакций.
Отправляет сжатый список в виде блоба в Ethereum L1 вместе с доказательствами.
L1 проверяет пакет транзакций.
Через какое‑то время блоб удаляется из L1
Мы собираемся немного углубиться в технические аспекты, так что приготовьтесь.
Вот пример блоб‑транзакции на Etherscan. Это пример транзакции zkSync, отправляющей пакет транзакций в Ethereum с прикрепленными блобами. Как же эти блобы используются?
Если мы нажмем на синюю секцию "2 blobs", мы увидим сам блоб, а также небольшой снапшот того, насколько дешевле стала эта транзакция из-за того, что мы используем блоб вместо calldata!
Если бы EVM имел прямой доступ к данным блобов, узлам пришлось бы хранить эти данные вечно. Узлам EVM/Ethereum необходимо хранить историю всех вычислений, которые они производят, поэтому, если они будут производить вычисления непосредственно на блобах, нам придется хранить эти вычисления и, следовательно, хранить весь блоб. Но мы не хотим этого делать, потому что не хотим хранить блоб вечно. Мы бы вернулись к тому, с чего начинали! Поэтому EVM не может получить доступ к данным блоба.
Создатели EIP-4844 были достаточно умны, чтобы добавить новый опкод и прекомпилированный код, которые должны с этим помочь:
Опкод BLOBHASH: Получает хэш любого из блобов в транзакции.
Прекомпилированный код point evaluation: Выполняет некоторую математическую магию. Дополнительную информацию ищите в evm.codes.
С помощью этих двух новых инструментов мы можем использовать «математическую магию криптографии» для проверки того, что блоб является валидным, без необходимости хранить данные блоба на цепочке или загружать их в среду, где EVM может получить к ним доступ.
Когда валидатор/оператор zkSync хочет отправить список транзакций обратно в L1, он вызывает commitBatches:
function commitBatches(
StoredBatchInfo calldata,
CommitBatchInfo[] calldata _newBatchesDataА в объект _newBatchesData передаются некоторые доказательства, которые в сочетании с хэшем блоба (получаемым с помощью опкода BLOBHASH) позволяют смарт-контракту убедиться в том, что пакет транзакций является действительным. В дальнейшем функция вызовет:
/// @dev Проверяет, что блобы содержат правильные данные, вызывая прекомпилированный код point evaluation. Для этого нам понадобятся:
/// версионный хэш || точка открытия || значение открытия || обязательство || доказательство
/// В _pubdataCommitments будут содержаться последние 4 значения, версионный хэш берется из опкода BLOBHASH
/// pubdataCommitments - это список: точка открытия (16 байт) || заявленное значение (32 байта) || обязательство (48 байт) || доказательство (48 байт)) = 144 байта
function _verifyBlobInformation(
bytes calldata _pubdataCommitments,
bytes32[] memory _blobHashes
) internal view returns (bytes32[] memory blobCommitments) {Который будет выполнять фактическую проверку блобов.
Опкод BLOBHASH выдает нам хэш блоба, а не весь блоб целиком, и мы можем объединить его с некоторыми доказательствами и другими «математическими штуковинами», которые затем можно передать в новый прекомпилированный код `point evaluation` (что эта функция в конечном итоге тоже делает). Point evaluation выполняет некоторую «математическую магию», чтобы проверить правильность хэша блоба. Подробнее о вводимых данных вы можете прочитать в evm.codes.
Но мы не удаляем блобы сразу. Это связано с тем, что мы хотим, чтобы у других узлов было время убедиться в правильности вычисляемого BLOBHASH, поэтому сообщество Ethereum позволяет блобам распространяться. На самом деле это занимает всего несколько блоков, но мы оставляем окно в 20–90 дней для удаления.
И бум! Теперь мы можем убедиться в том, что транзакции L2 являются валидными. Этот массивный блоб представляет собой все транзакции, но мы можем проверить их достоверность, используя только хэш и немного умной математики.
Вот так и работают блобы.
Как отправить блоб-транзакцию
Мы создали minimal repo, чтобы показать вам, как отправить блоб‑транзакцию, используя новый Eip-4884 в web3.py. Настройка похожа на настройку (нормальных) транзакций EIP-1559 . Вам нужно будет создать TransactionPayload EIP-2718, который будет выглядеть примерно так:
tx = {
"type": 3,
"chainId": 31337, # Anvil
"from": acct.address,
"to": "0x0000000000000000000000000000000000000000",
"value": 0,
"maxFeePerGas": 10**12,
"maxPriorityFeePerGas": 10**12,
"maxFeePerBlobGas": to_hex(10**12),
"nonce": w3.eth.get_transaction_count(acct.address),
}
# Это представляет собой TransactionPayload EIP-2718.И ключевая часть — добавление самого блоба. Вы не добавляете блоб к пейлоаду в EIP-2718 TransactionPayload, а вместо этого отправляете блоб вместе с пейлоадом. Согласно EIP, RLP (рекурсивный префикс длины: способ, которым Ethereum кодирует данные транзакций) выглядит следующим образом:
rlp([tx_payload_body, blobs, commitments, proofs])С другой стороны, транзакция EIP-1559 содержит в RLP только tx_payload_body. Поэтому в Python мы можем представить это следующим образом:
# Это сгенерирует блобы, обязательства и доказательства для нашего блоба tx
signed = acct.sign_transaction(tx, blobs=[BLOB_DATA])Ethers и другие библиотеки для кодирования транзакций также занимаются генерацией доказательств и другими «блобными» делами. Полный скрипт для отправки блоб‑транзакции может выглядеть следующим образом:
import os
from dotenv import load_dotenv
from eth_abi import abi
from eth_utils import to_hex
from web3 import HTTPProvider, Web3
load_dotenv()
def send_blob():
rpc_url = os.getenv("RPC_URL")
private_key = os.getenv("ANVIL_PRIVATE_KEY")
w3 = Web3(HTTPProvider(rpc_url))
text = "<( o.O )>"
encoded_text = abi.encode(["string"], [text])
print("Text:", encoded_text)
# Данные блоба должны состоять из 4096 32-байтовых элементов
# Так что да, блобы должны быть довольно большими.
BLOB_DATA = (b"\x00" * 32 * (4096 - len(encoded_text) // 32)) + encoded_text
acct = w3.eth.account.from_key(private_key)
tx = {
"type": 3,
"chainId": 31337, # Anvil
"from": acct.address,
"to": "0x0000000000000000000000000000000000000000",
"value": 0,
"maxFeePerGas": 10**12,
"maxPriorityFeePerGas": 10**12,
"maxFeePerBlobGas": to_hex(10**12),
"nonce": w3.eth.get_transaction_count(acct.address),
}
gas_estimate = w3.eth.estimate_gas(tx)
tx["gas"] = gas_estimate
# Это сгенерирует блобы, обязательства и доказательства для нашего блоба tx
signed = acct.sign_transaction(tx, blobs=[BLOB_DATA])Дополнительную информацию смотрите в GitHub-репозитории.
После EIP-4844: Будущее данкшардинга и блобов
EIP-4844, также известный как «прото‑данкшардинг», является промежуточным шагом на пути к будущему Ethereum — «данкшардингу», который имеет гораздо больше крутых функций. Они помогут Ethereum масштабироваться более справедливым и подотчетным образом. Однако для полноценного данкшардинга потребуется еще много разработок и исследований, а вот роллапы уже сегодня имеют реальную ценность. Поэтому экосистема EVM решила, что стоит выпустить это обновления уже сейчас, в то время как остальная часть данкшардинга еще прорабатывается.
Документация Ethereum отлично объясняет будущее данкшардинга; вы можете прочитать больше на сайте Ethereum.
Многомерное ценообразование на газ
Появилось и такое явление, как «многомерное ценообразование на газ».
Исторически сложилось так, что все запросы на вычисления и хранение данных на узле ETH объединяются в 1 единицу: «газ» (gas). Однако с блобами мы создали новую единицу измерения вычислений — «блоб‑газ» (blob gas). В одном блоке может быть только столько блобов, сколько данных может поместиться в блок. Поскольку предложение блобов отличается от предложения транзакций, спрос на них также может отличаться. Поскольку спрос на блобы может сильно отличаться от спроса на место в блоке, у блобов есть свой рынок газа.
Вы можете увидеть это в коде Python выше, там было поле транзакции под названием maxFeePerBlobGas. Блобы получают расчет стоимости газа на основе спроса блобов. По сути, это означает, что при оценке стоимости газа с помощью блобов выполняются два расчета:
Нормальные расходы на газ в зависимости от потребности в блочном пространстве
Стоимость блоб‑газа в зависимости от спроса на блобы
Это создает прецедент того, что в будущем в экосистеме EVM может появиться еще больше рынков для расчета различных затрат на выполнение различных операций.
Заключение
Что такое EIP-4844?
EIP-4844 — это предложение по улучшению блокчейна Ethereum/EVM, которое добавляет поддержку «блобов» в транзакциях, что удешевляет процесс подтверждения транзакций:
Blob‑транзакции — это новый тип транзакций, который позволяет хранить данные в цепи в течение короткого периода времени. Эти «недолговечные данные» известны как «блоб» или «binary large object».
Мы можем получить доступ не к самим данным, а к их хэшу с помощью нового опкода BLOBHASH.
Использование блоб‑транзакций позволяет роллапам регистрировать транзакции в L1 гораздо дешевле, чем раньше.
Как теперь проверяются транзакции в роллапах?
Вы отправляете транзакцию с блобом, а также некоторые данные для доказательства.
Ваш контракт получает доступ к хэшу блоба с помощью опкода BLOBHASH.
Затем он передаст ваш блоб‑хэш в сочетании с данными доказательства новому прекомпилированному коды point evaluation, чтобы помочь проверить пакет транзакций.
Статья подготовлена в рамках курса "Solidity Developer". На странице курса можно ознакомиться с полной программой, а также посмотреть записи открытых уроков.