EIP-2935: храним хеши блоков в состоянии
Опкод BLOCKHASH видит только последние 256 блоков — около 51 минуты. Старше этого он возвращает ноль. Но L2, проверяющим (provers) и лёгким клиентам нужно заглядывать глубже, а клиентам без состояния нужны эти хеши прямо в состоянии, а не в специальном кеше заголовков. EIP-2935 помещает их в кольцевой буфер внутри системного контракта.
- BLOCKHASH и заголовки блоков
- бессостоятельный Ethereum (witness'ы)
Prague / Electra, май 2025. EVM всегда позволяла контракту запросить хеш прошлого блока: BLOCKHASH(n). Так контракт может привязать факт к конкретному блоку или засеять немного псевдослучайности. Но есть загвоздка, которая тихо формировала ончейн-дизайн целое десятилетие: она дотягивается назад лишь на 256 блоков — примерно 51 минуту. Запросите что-то старше — получите ноль. По мере того как вокруг Ethereum вырастали роллапы, кросс-чейн проверяющие и лёгкие клиенты, это короткое жёсткое окно стало реальным ограничением — а способ, которым оно было реализовано, стал препятствием для бессостоятельного Ethereum. EIP-2935 перестраивает поиск хешей блоков на более прочном фундаменте. Давайте выведем его.
Проблема: BLOCKHASH видит только недавнее прошлое, из побочного кеша
BLOCKHASH(n) возвращает хеш блока n — но только если n входит в последние 256 блоков; иначе выдаётся ноль. Тут вредят две вещи. Во-первых, окно крошечное: многим приложениям — роллапу, проверяющему более старое состояние, кросс-чейн проверяющий (cross-chain prover) Контракт или система, которая доказывает факт об одной сети другой (или роллапу), проверяя хеши блоков и доказательства Меркла. Ей часто нужны хеши блоков намного старше 256, которые BLOCKHASH предоставить не может. , проверяющему историческое включение, лёгкому клиенту, догоняющему цепочку — нужны хеши намного старше 51 минуты. Во-вторых, и это тоньше, опкод обслуживался из клиентского кеша заголовков: каждый узел держал недавние заголовки в собственной памяти, чтобы отвечать на BLOCKHASH. Для полного узла это нормально, но это ровно тот вид внеполосного состояния, который стремится устранить бессостоятельный Ethereum (stateless Ethereum) Будущее, в котором узел может валидировать блок, используя только блок плюс криптографическое «свидетельство» (witness) состояния, которого он касается, без хранения полного состояния. Всё, что читает EVM, поэтому должно быть частью свидетельствуемого состояния — побочный кеш заголовков сюда не вписывается. : клиент без состояния, валидирующий блок по witness, не имеет кеша заголовков, к которому можно обратиться.
→ Шаг 2: помещаем хеши в состояние, в кольцевой буфер.
EIP-2935: системный контракт записывает хеш каждого родителя
Исправление переиспользует шаблон, который эта книга уже видела. Назначенный системный контракт (system contract) Контракт на фиксированном, зарезервированном протоколом адресе, чьё хранилище сам протокол записывает каждый блок. И контракт истории EIP-2935, и контракт beacon root из EIP-4788 работают так — кольцевой буфер живёт в обычном хранилище контракта, так что EVM читает его обычным SLOAD. хранит недавние хеши блоков, и протокол обновляет его автоматически: в начале обработки блока n он записывает хеш родительского блока в хранилище контракта, в слот (n − 1) mod 8191. Поскольку индекс закольцовывается, контракт — это кольцевой буфер (ring buffer) Массив фиксированной длины, адресуемый по индексу-по-модулю-длины, так что новые записи перезаписывают самые старые. Здесь он хранит последние 8191 хешей блоков в 8191 слотах хранилища, в постоянном объёме — та же структура, которую EIP-4788 использует для beacon root. фиксированного размера, хранящий последние 8191 хешей (~27 часов). Теперь контракт читает исторический хеш обычным SLOAD по этому адресу — без специального пути опкода, без кеша заголовков — и, что решающе, хеши являются частью состояния, а значит, и любого witness.
→ Шаг 3: бо́льшая дальность и кусочек бессостоятельного будущего.
Выигрыш: дальше назад и поддаётся свидетельствованию
Разом выпадают два выигрыша. Дальность прыгает с 256 до 8191 блоков — окно в 32 раза длиннее, на которое роллапы и проверяющие могут опираться для исторических доказательств. А поскольку хеши теперь живут в состоянии, клиент без состояния может обращаться к ним прямо из witness блока, не держа кеш заголовков — устраняя один из неудобных внеполосных кусочков, стоящих между сегодняшним Ethereum и полностью бессостоятельным, готовым к Verkle Ethereum. Это также делает доверенно-минимизированные кросс-чейн и исторические доказательства дешевле и проще, поскольку контракту достаточно прочитать хранилище. И это приятное повторение уже знакомой идеи: как и beacon root из EIP-4788, протокол поддерживает небольшой кольцевой буфер в системном контракте, превращая особую потребность в данных в обычное, читаемое состояние.