Введение

То, что блокчейны хранят и на что ссылаются во время обработки транзакций, называется состоянием. В Ethereum состояние является свойством, которое облегчает консенсус узлов. Каждый полный узел должен хранить и обновлять это состояние во время каждого периода действительных блоков. Состояние, важное для блокчейнов, имеет и недостатки; оно растет со временем. Они являются серьезной проблемой в блокчейнах, таких как Bitcoin и Ethereum, потому что увеличение размера влечет за собой соответствующее увеличение аппаратных требований к узлам. Пороговое значение пространства со временем исключает некоторые узлы, что приводит к централизации.EIP-2935предлагает внести бессостоятельность в Ethereum, снимая с узлов бремя размера. EIP-2935 - это предложение об улучшении, которое пытается достичь бессостоятельности, храня и обслуживая последние 8192 хэша блоков из состояния для бессостоятельного выполнения в Ethereum.

Краткий обзор текущей структуры Ethereum

Блоки

Блоки представляют собой пакеты транзакций с ссылкой (хеш) предыдущего блока, включенной в цепочку. Хеши в каждом блоке происходят криптографически из данных блока. Это включение связывает цепочки вместе с помощью хешей, а пакетирование подразумевает, что все участники сети согласуются и синхронизируют состояние одновременно. Кроме того, согласование пакетированных блоков сигнализирует Ethereum о необходимости обновить свое глобальное состояние у каждого участника в сети в качестве узла.

Alt: Изменение состояния в Ethereum

Как только новый блок обрабатывается и передается с валидатором в сети, все остальные участники добавляют его в свое хранилище и обновляют свое глобальное состояние. Валидатор каждого блока выбирается случайным образом Случайная Децентрализованная Автономная Организация (RANDAO)Параметр. Структура блока строго упорядочена, а процессы создания блока и консенсуса определены в рамках протокола доказательства доли Ethereum.

Блок содержит несколько полей в своем заголовке и теле. Например, заголовок блока включает поля slot, proposer_index, parent_root, state_root и body. Тело блока включает randao_reveal, eth1_data, graffiti, proposer_slashings, attester_slashings, attestations, deposits, voluntary_exits, sync_aggregate и execution_payload. Каждое поле содержит различные параметры и обрабатывает различные потребности.

Ethereum’s 12-секундныйПериод создания блока, также называемый "слотом", происходит из обеспечения достаточного времени для синхронизации участников сети с новыми блоками и согласования мнений. В течение этого периода:

1. Предлагающий блок случайным образом выбирает валидатора,
2. Валидатор объединяет транзакции вместе и выполняет их для определения нового глобального состояния,
3. Они включают эту информацию в новый блок и транслируют ее остальному набору валидаторов через протокол сплетен,
4. Другие валидаторы повторно выполняют транзакции, чтобы гарантировать их действительность и соглашаются с глобальным изменением состояния как консенсус,
5. Если валидатор подтверждает новый блок как действительный, он добавляет его в свое хранилище.

Финальность блока и транзакции означает, что он не может быть изменен без значительного сжигания ETH в распределенной сети. У Ethereum есть подход "блоки контрольных точек" для управления финализацией. Первый блок в каждой эпохе считается контрольной точкой этого слота. Валидаторы голосуют за это предположение, чтобы сделать его действительной контрольной точкой. Если две трети всего стейкинга ETH с голосами валидаторов избирают пару контрольных точек, контрольные точки повышаются до оправданных. Предыдущие оправданные контрольные точки обновляются после обновления следующих контрольных точек и становятся окончательными. Если злонамеренный актор хочет отменить окончательный блок, ему нужно согласиться на потерю как минимум трети общего количества стейкнутого ETH. Хотя существует механизм под названием утечка бездействиясоздана для восстановления окончательности путем наложения крупных штрафов на средства валидаторов и сокращения наград аттестантов в случае постоянной неисправности большого количества валидаторов.

При обработке блока Ethereum применяет хэш-функцию для преобразования данных блоков в уникальные строки. В хэш-функции каждый вход порождает уникальный выход. Значения хэша в блоках являются единственной неизменной частью. Они могут быть изменены сжиганием трети общего количества заложенного ETH. Однако этот объем получается путем пересчета хэшей дерева Меркля до контрольной точки. Результат хэширования для каждого блока возвращается с параметром blockHash. Параметр blockHash включает все данные в блоке.

Хэш-значения блоков и другие необходимые параметры хранятся в деревьях Меркля. Эфириум использует архитектуру деревьев Меркля с различными версиями, такими как Меркль-Патриция-Дерево.

Деревья Меркла и Меркла-Патриции

Структуры деревьев трай, особенно Мерклевы деревья, являются фундаментальными для хранения блокчейнов. Без Мерклевых деревьев блокчейны становятся отдельными блоками, которые трудно обрабатывать каждый раз. Благодаря Мерклевым деревьям, или вообще структурам трай, блокчейны достигают завершенности с базовыми фрагментами. Это позволяет им стать участниками сети с низкими аппаратными требованиями.

Деревья Меркла - это структурированный способ хеширования больших объемов фрагментов и их разделения на части. С помощью Меркелизации данные организуются парами; каждая из них хешируется вместе. Процесс Меркелизации повторяется до тех пор, пока не будет получен один корневой хеш Меркла.

Ethereum предпочитает Merkle Patricia Tries, структуру двойного дерева Меркла. Он использует бинарные деревья для базовой обработки данных, таких как данные транзакций, поскольку этот подход более эффективен для таких ситуаций. Однако в сложных случаях Ethereum использует более сложные деревья Меркла Патриции, например, при обработке состояния.

В сценарии хранения данных дерева состояний Ethereum использует отображение ключ-значение. Ключи представляют адреса, а значения представляют объявления учётных записей. Деревья состояний более динамичны, чем бинарные деревья. Таким образом, новые учётные записи могут часто вставляться, и ключи могут часто вставляться и удаляться. Для этого процесса требуется быстрая структура данных, которая не требует повторного вычисления всего набора данных.

Корень trie зависит только от данных, а не от порядка. Внесение обновлений в данные в разном порядке не изменит сам корень.

Alt: Бинарное дерево Меркля

Ethereum использует модифицированное дерево Меркля Патриции, которое имеет некоторые особенности от PATRICIA (Practical Algorithm to Retrieve Information Coded in Alphanumeric)и Мерклево дерево с модификациями вдоль него. Эта архитектура детерминирована и криптографически верифицируема. Единственным способом создания корневого состояния в этой структуре является его вычисление из каждого отдельного куска состояния. Два идентичных состояния могут легко быть доказаны путем сравнения корневого хэша и хэшей, которые к нему привели.

В конечном итоге, изменение состояния с разными значениями невозможно, поскольку это приведет к другому хешу корневого состояния. Все структуры деревьев в исполнительном слое Ethereum используют дерево Меркля-Патриции. В сети есть три дерева: Дерево состояния, Дерево хранилища и Дерево транзакций. Кроме того, у каждого блока есть свое собственное дерево квитанций. Хотя деревья Меркля-Патриции эффективны во многих отношениях, Ethereum мотивирована заменить их деревьями Веркле для достижения безсостоятельности.

Alt: Дерево Меркла-Патрисии-Три

Газ

Газ - это свойство, необходимое в EVM для выполнения. Поскольку EVM использует и нуждается в вычислительных ресурсах для выполнения, возврат этих усилий оплачивается газом для обеспечения безопасности EVM. Плата за газ рассчитывается как необходимое количество газа, умноженное на стоимость за единицу. Это динамическое значение и зависит от типа операции.

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559внес значительные изменения в механизм оплаты комиссии за транзакции. Оплата за газ для включения транзакций в блоки ранее осуществлялась методом, похожим на аукцион. С EIP-1559 появилось минимальное значение, называемое базовой платой, и введена чаевые, называемые приоритетной платой. Предполагается, что блоки начнутся с транзакции с наивысшей приоритетной платой. После обработки блока базовая плата сжигается, а приоритетная плата используется для стимулирования валидаторов.

Государство

Состояние блокчейна можно определить как набор данных (или переменных), описывающих определенную систему в определенный период. Интернет имеет состояние практически с самого начала, но оно хранилось на одном сервере. С появлением Web3 было введено глобальное состояние, поддерживаемое на открытой и распределенной сети, защищенной с помощью децентрализованных методов. Каждый может просматривать и проверять состояние распределенной сети в любое удобное для него время.

Ethereum включает в себя учетные записи, балансы, развернутые смарт-контракты и связанное хранение в глобальном состоянии. Состояние Ethereum растет с добавлением и изменением этих параметров. Рост состояния становится проблематичным, когда аппаратные затраты на хостинг полной ноды становятся запретительными. С учетом этих вызовов, Виталик Бутерин представилконцепция бесгосударственного Ethereum в 2017 году. Предложенные методы по исправлению роста состояния в Ethereum включают истечение срока действия данных и состояния.

Различия между истечением срока действия данных и истечением срока действия состояния

Истечение срока действия данных

Истечение срока данных или истории означает удаление избыточных данных у клиентов после определенного периода. С помощью "слабых точек проверки субъективности" клиенты могут синхронизироваться с начала и удалять исторические ненужные данные.

Субъективность относится к узлам сети, полагающимся на социальную информацию для достижения согласия относительно текущего состояния. В этом свете слабая субъективность относится к цепочке, которая может продвигаться объективно с некоторым начальным семенем информации, полученной социально. Однако контрольные точки слабой субъективности подразумевают, что все узлы в сети, ответственные за согласие, принадлежат к канонической цепочке. Контрольные точки слабой субъективности помогают Ethereum PoS иметь последнее состояние (контрольная точка слабой субъективности) из доверенного источника для синхронизации.

EIP-4444предоставляет практический путь к@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems"> достигнуть истечение срока данных через слабую субъективность. Предложение не ставит своей целью изменить способ обработки узлами Ethereum данных состояния; скорее, оно изменяет доступ к историческим данным.

Истекший срок

State Expiry seeks to eliminate state from individual nodes if it hasn’t been accessed recently. Expiry may be implemented by termination being a factor of rent or time. Expiry by rent means imposing a surcharge on accounts for storing the state. On the other hand, expiry by time means rendering accounts inactive if they remain inactive for a certain period.

И Данные, и истечение срока действия состояния являются открытыми исследовательскими областями. На данный момент для достижения этих предложенных статусов применяются подходы, включающие их передачу через централизованные сети/поставщиков. До сих пор слабая безсостоятельность и истечение срока действия состояния были частично достигнуты в Ethereum.

Бессостоятельный Ethereum

Введение в безгосударственность и безгосударственную платформу Ethereum

Stateless Ethereum вводит новые концепции в основной протокол. В идеале, отсутствие состояния не означает, что состояние не существует. Скорее, это означает, что клиенты могут выбирать состояние, которое им хотелось бы поддерживать. Когда клиенты получают подтвержденные блоки, они также получают соответствующего свидетеля для этого блока. Свидетели для каждого блока состоят из всех данных, необходимых для выполнения транзакций, содержащихся в этом блоке.

EIP-161впервые был представлен подход к уменьшению состояния. Ethereum подвергся атаке DoS (Отказ в обслуживании), и эта уязвимость позволила создавать пустые учетные записи, увеличивающие глобальное состояние Ethereum. EIP-161 предложил удалить пустые учетные записи со значением ноль (0) на их номере, возникшие в результате этой атаки, с низкими затратами. Предложение было реализовано, что привело к откату состояния.

Еще одна попытка достичь состояния отсутствия была предложена через EIP-4788Этот проект предполагал выявление корней блоков цепочки маяка в EVM. Подобно подходу Мост Eth1-Eth2соединяя цепочку Beacon (уровень консенсуса) и уровень исполнения, это предложение позволяет минимизировать доверие между EVM и уровнем консенсуса.

Поскольку каждый блок выполнения содержит корень родительского маяка, пропущенные события слотов не требуют изменения корня предыдущего блока. Таким образом, предпосылки выполнения сужаются до резервирования небольшого пространства для доверенного оракула в каждом блоке выполнения. Предложение предлагает хранить небольшую историю корней блоков в корневом контракте для улучшения эффективности оракула.

Безгосударственность в Ethereum возможна как слабая, так и сильная безгосударственность.

Слабая безгосударственность

Слабая безгосударственность - это статус, который не устраняет необходимость в хранении состояния во всех узлах. Вместо этого он отличается тем, как узлы проверяют изменения в состоянии Ethereum. Он возлагает ответственность за хранение состояния на предлагающих блоки и требует, чтобы другие узлы проверяли блоки без хранения полных данных состояния.

Предлагателям блоков необходимо хранить полные данные о состоянии. Однако клиенты-проверяющие не обязаны хранить данные о состоянии в сети. Вместо этого они могут хранить корень состояния (хэш всего состояния). Слабая безсостоятельность требует Разделение заявителя-строителя (PBS)иVerkle пытаетсяреализация.

Производители создают свидетелей, используя данные состояния, чтобы доказать изменения состояния, а проверяющие проверяют доказательства по отношению к хешу корня состояния.

Сильное бессостояние

Сильная отсутствие состояния устраняет необходимость для любого узла хранить данные состояния. Он работает путем включения отправленных транзакций и свидетелей, собранных блок-предложителями. Блок-предложители хранят только состояние, над которым они работают, генерируя свидетелей для соответствующих учетных записей. Предложение всё ещё требует дальнейшего развития и включает такие требования как Списки доступаили EIP-2930.

Однако некоторые изменения и свойства могут быть использованы для достижения отсутствия состояния. EIP-2935 предлагает предоставлять исторические хеши блоков из состояния для возможности выполнения без состояния.

Введение в EIP-2935

EIP-2935 нацелен на сохранение исторических хэшей блоков в состоянии блокчейна в специальных ячейках хранения, называемых HISTORY_STORAGE_ADDRESS. Этот процесс позволит безсостояний выполняться, облегчая доступ к необходимой исторической информации в безсостояний клиентах.

EIP-2935 предлагает хранить последние 8192 исторических хэшей блоков в системном контракте для использования в качестве части логики обработки блоков. Проблема, которую пытается решить данный предложение, заключается в том, что EVM предполагает, что у клиента есть последний хэш блока. Этот подход на основе предположений не применим к будущему Ethereum и особенно к безсостояничным клиентам.

Включение хэшей предыдущих блоков в состояние позволит упаковывать эти хэши с хэш-функциями в поле зрения свидетеля. Позднее свидетелю будет предоставлено состояние для проверки выполнения и достижения безсостояний. Это предложение называется предварительной специализацией Verkle, потому что его можно реализовать до адаптации к деревьям Verkle в основном протоколе, и оно облегчает частичную безсостоятельность.

Расширение диапазона блоков, обслуживаемых blockHash, до 8192 блоков позволит мягкий переход к исполнительным методам. Rollups могут извлечь пользу из этого более длинного окна истории, обращаясь к этому контракту напрямую, потому что данные blockHash хранятся в этом контракте. Кроме того, этот EIP упростит проверку доказательств, касающихся 8192 блоков HISTORY_SERVE_WINDOW, по сравнению с текущим состоянием.

Понимание EIP-2935

EIP-2935 позволяет клиентам Ethereum, особенно безсостояничным, легко получать доступ к последним хешам блоков. Для этого вводится четыре новых параметра.

• BLOCKHASH_SERVE_WINDOW: Сообщает клиентам, сколько прошлых хэшей блоков они должны хранить. Значение по умолчанию - 256.
• HISTORY_SERVE_WINDOW: Этот параметр определяет, сколько блоков хэшей хранится. Значение по умолчанию составляет 8191.
• SYSTEM_ADDRESS: Специальный адрес (изначально введенный в EIP-4788), который выступает в качестве "вызывающего" для записи хэшей блоков в хранилище.
• HISTORY_STORAGE_ADDRESS: Адрес контракта, где хранятся хеши блоков.

Спецификации предложения направляют хэши последних блоков HISTORY_SERVE_WINDOW для хранения в кольцевом буфере длиной HISTORY_SERVE_WINDOW.

Ring Buffer

EIP-2935 использует дополнительную функцию, называемую кольцевым буфером для временного хранения. Кольцевой буфер - это свойство, которое позволяет сети повторно использовать одно и то же хранилище для разных данных. Хранилище в кольцевом буфере ограничено одним и тем же местом хранения каждый раз. Кольцевой буфер на EIP-2935 используется только для обслуживания необходимого окна HISTORY_SERVE_WINDOW, поскольку EIP-4788 и накопители состояний маяка обеспечивают доказательство против любого предка.

Правила выбора вилки и спецификации

После разделения, когда сеть начнется с учетом этих рекомендаций EIP, параметр HISTORY_STORAGE_ADDRESS будет называться SYSTEM_ADDRESS с вводом block.parent.hash (по умолчанию 32 байта), газовым лимитом 30.000.000 и значением 0. Этот процесс вызовет функцию set() контракта истории.

Процесс форка после предложения отличается от обычного процесса форка. Эта операция set() является общей системной операцией, но вызов следует этим соглашениям:

• Должен быть выполнен до завершения
• Не учитывается при ограничении газа блока
• Не следует механизму сжигания EIP-1559
• Если кода нет по адресу HISTORY_STORAGE_ADDRESS, вызов должен завершиться неудачно без фатальных ошибок.

Этот процесс должен заполнить период блока HISTORY_SERVE_WINDOW, чтобы соответствовать периоду срабатывания кольцевого буфера. Исторический контракт будет содержать только родительский хэш блока вилки, который служит в качестве хэша-ссылки и новой точки начала хэширования.

Контракт истории хэш-блока будет иметь две операции: get() и set(). Операция set() активируется, если вызывающий контракт в транзакции равен SYSTEM_ADDRESS, который был введен с EIP-4788. Если вызывающий и SYSTEM_ADDRESS не равны или не выполняют условия, активируется операция get().

Операция get() используется в EVM для поиска хэшей блоков. Она позволяет вызывающим сторонам указать номер блока, который они запрашивают, если ввод calldata не является 32 байтами (что означает, что это действительный block.parent.hash), и если запрос находится за пределами диапазона ([block.number-HISTORY_SERVE_WINDOW, block.number-1]), то отменяется транзакция.

set() принимает в качестве входных данных block.parent.hash как calldata, когда вызывающий вызывает контракт с транзакцией. Он также устанавливает значение хранилища как calldata[0:32] при block.number-1 % HISTORY_SERVE_WINDOW.

HISTORY_STORAGE_ADDRESS будет развернут через EIP-4788, который вышеупомянут как способ доступа к хэшам блоков в EVM непосредственно через уровень согласия. HISTORY_STORAGE_ADDRESS будет иметь значение nonce равное 1 и будет освобожден от стандарта очистки нулевого nonce EIP-161.

Логика перехода BLOCKHASH

Одной из проблем, связанных с этим EIP, является выбор наилучшего способа перехода к логике разрешения BLOCKHASH после разделения. Рассматривается два основных подхода:

• Дождитесь завершения HISTORY_SERVE_WINDOW блоков для сохранения всей необходимой истории,
• Храните все последние хеши блоков HISTORY_SERVE_WINDOW на блоке ветвления.

Разработчики выбирают первый вариант. Он более практичен, потому что не требует никаких временных изменений.

В чем разница между EIP-2935 и подобными EIP?

Подобные EIP были предложены ранее для обеспечения и достижения безсостоянийного выполнения. EIP-2935 отличается от этих предыдущих предложений, поскольку нацеливается на выявленные ниже сложности.

• Подход структуры Trie: EIP-2935 не использует структуру, похожую на Trie, с несколькими уровнями, а вместо этого выбирает один список. Напротив, EIP-4444 предложил обрезать исторические данные в клиентах выполнения, старше года. Другие EIP с аналогичными амбициями имеют Веркле-деревья в качестве требований.
• Написание EIP в EVM-коде: EIP-2935 не требует изменения EVM.
• Серийное неограниченное хранение хэшей: Серийное неограниченное хранение хэшей неэффективно. Этот EIP преодолевает эту проблему, объединяя хэши.

Рекомендации по безопасности

Поскольку EIP-2935 использует смарт-контракты, он рискует подвергнуться атакам ветвления. Однако размер корневого состояния делает любую попытку обновления медленной, а атаку ветвления значительно более затратной.

Что это могло бы принести?

• Ускорение систем доверительных оракулов: В оракулах на основе Uniswap v2 любой, у кого есть доступ к узлу Ethereum, может сгенерировать доказательство хранения Uniswap и отправить его для проверки в сети. Средняя цена определяется между текущим блоком и блоком предоставленного доказательства, с проверенным доказательством до 256 блоков, поскольку blockHash поддерживает до 256 блоков. Благодаря EIP-2935 этот процесс можно улучшить, позволив доступ к более старым хешам блоков, что означает, что доказательства могут быть проверены за более длительный период.
• Разрешение контрактов на рассмотрение утверждений о прошлом состоянии, без доверия: улучшение EIP-2935 создает возможность смотреть на данные блокчейна изнутри EVM, без доверия. Клиент может запрашивать историю, получать ее хэшированную версию и проверять ее с другими узлами. Решение может сделать легкие клиенты эффективными и легкими в реализации.
• Мост между L1 <> L2: Для проверки сообщения с L2, L1 должен знать о корнях состояний L2 и хэшах блоков. Однако L1 в своем текущем состоянии не может получить доступ к произвольным хэшам блоков из-за ограничений на газ и архитектурных ограничений. EIP-2935 позволяет L1 проверять произвольные исторические данные с возможностью проверки доказательств включения для старых событий. Доступ и мощность проверки улучшатся, а производительность моста тоже.

Заключение

EIP-2935 представляет собой важный шаг к достижению долгосрочной цели состояния Stateless Ethereum. Хранение последних 8192 хешей блоков в специальном контракте в пределах состояния решает фундаментальное ограничение в текущем дизайне. Предположение Ethereum, что клиенты имеют врожденный доступ к последним хешам блоков. В контексте бессостоятельного выполнения, где клиенты больше не поддерживают полное состояние, это предположение устаревает. EIP-2935 разрешает это путем введения легкого, эффективного и невторгающего механизма, который позволяет бессостоятельным клиентам получать доступ к необходимым историческим данным без модификации EVM или зависимости от сложных структур данных, таких как попытки Verkle.

Помимо бессостоятельного выполнения, данный предложение открывает широкие выгоды в экосистеме Ethereum. Оно улучшает возможности доверительных оракулов, расширяет возможности легких клиентов и укрепляет взаимодействие между решениями уровня 1 и уровня 2, обеспечивая надежную верификацию старых данных состояния. Его реализация основана на чистом и газоэффективном дизайне, используя кольцевое буферное хранилище и контракты на уровне системы, которые избегают необходимости жесткой привязки к EVM, предлагая простоту и масштабируемость.

Поскольку Ethereum продолжает свое развитие в сторону большей децентрализации, масштабируемости и доступности, EIP-2935 служит фундаментальным улучшением. Он сокращает разрыв между текущей состоятельной архитектурой и представленным безсостоятельным будущим, и заложивает основу для более надежной, эффективной и разрешенной инфраструктуры в пределах блокчейн-экосистемы.

Отказ от ответственности:

1. Этот статья перепечатана из [ исследование2077]. Все авторские права принадлежат оригинальному автору [Yiğit Yektin]. Если есть возражения к этому повторному изданию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно с этим справятся.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Команда Gate Learn делает переводы статей на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.