Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем увеличиваются. Это происходит в двух аспектах:
Исторические данные: любые транзакции, проведенные в любой момент времени в прошлом, и любые созданные аккаунты должны храниться всеми клиентами постоянно и загружаться любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функция протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но в то же время мы должны сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных торговой транзакции или смарт-контракт на сумму 1 миллион долларов на цепочке, войти в пещеру на десять лет, а затем выйти и обнаружить, что он по-прежнему там, ожидая вашего чтения и взаимодействия. Чтобы DApp могли с уверенностью полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным образом - особенно L1 сам по себе.
Если мы решим добиться баланса между этими двумя потребностями и при этом минимизировать или обратить вспять избыточность, сложность и упадок, сохраняя непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы сигнальной цепи хранили старые данные в течение максимум шести месяцев. Найти этот путь для Ethereum более универсальным способом и двигаться к долгосрочному стабильному конечному результату является конечной проблемой долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
Снижение требований к хранилищу клиентов путем уменьшения или устранения необходимости в том, чтобы каждый узел постоянно хранил все исторические записи или даже конечное состояние.
Снижение сложности протокола путем устранения ненужных функций.
Содержание статьи:
Историческая запись истекла
Состояние истечения срока
Очистка функционала（特征清理）
История истечения
Какую проблему решает?
На момент написания этой статьи полностью синхронизированный узел Ethereum требует около 1.1 ТБ дискового пространства для работы клиента, а также сотни ГБ дискового пространства для клиентa консенсуса. Большая часть из этого - это история: данные о исторических блоках, сделках и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевая упрощенная характеристика проблемы хранения истории заключается в том, что поскольку каждый блок связан с предыдущим блоком через хэш (и другие структуры), для достижения консенсуса по текущему блоку достаточно достичь консенсуса по истории. Пока сеть достигнет консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его корректность. Консенсус — это модель доверия N/2 из N, в то время как история — это модель доверия N из N.
Это предоставляет нам множество вариантов хранения истории. Естественный выбор - это сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распространяет миллионы файлов, каждый участник хранит и распространяет лишь несколько из них. Возможно, вопреки интуиции, этот метод даже не обязательно снижает надежность данных. Если мы можем создать более экономичную систему, позволяя узлам работать более эффективно, мы можем построить сеть из 100 000 узлов, где каждый узел хранит случайные 10% истории, тогда каждая единица данных будет скопирована 10 000 раз - что совершенно соответствует коэффициенту копирования в сети из 10 000 узлов, где каждый узел хранит все данные.
Сегодня Эфир начал избавляться от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок (то есть часть, связанная с консенсусом на основе доли) хранит только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 направлен на введение годового срока хранения для исторических блоков и записей. Долгосрочная цель заключается в создании единого периода (возможно, около 18 дней), в течение которого каждый узел будет нести ответственность за хранение всего, а затем создать одноранговую сеть, состоящую из узлов Эфира, которая будет хранить старые данные в распределенной сети.
Коды стирания могут быть использованы для повышения устойчивости при сохранении одинакового фактора репликации. Фактически, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и помещение данных выполнения и консенсуса блока также в blob.
Каковы связи с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444；
Портал сети;
Портальная сеть и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как увеличить лимит газа (Paradigm).
Что еще нужно сделать, какие компромиссы нужно учитывать?
Основная работа заключается в создании и интеграции конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение - это (i) просто внедрить существующую библиотеку торрент, а также (ii) решение Ethereum, называемое сетью Portal. Как только одно из них будет внедрено, мы сможем активировать EIP-4444. Сам EIP-4444 не требует жесткого форка, но требует новой версии сетевого протокола. Поэтому имеет смысл активировать его для всех клиентов одновременно, иначе существует риск сбоя клиента из-за подключения к другим узлам, ожидая загрузки полной истории, но на самом деле не получая ее.
Основные компромиссы касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение — завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет позицию Эфира как места для постоянной записи. Более сложный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторического хранилища в протокол?
Экстремальный параноидальный подход к (1) будет включать в себя доказательство хранения: фактически требуя от каждого валидатора доказательства доли хранения определенного процента исторических данных и регулярно проверять их на наличие этих данных в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процентного соотношения исторических данных, хранящихся каждым клиентом.
Что касается (2), базовая реализация включает только работу, завершенную на сегодня: Portal уже хранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет заключаться в фактическом подключении его к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, они смогут сделать это через прямую синхронизацию из сетевого портала, даже если нет других архивных узлов, работающих онлайн.
Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали исключительно простыми, то уменьшение требований к хранилищу истории можно считать более важным, чем безсостояние: из необходимых 1,1 ТБ узла около 300 ГБ — это состояние, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Эфир на смарт-часах, который можно настроить всего за несколько минут.
Ограничение хранения истории также делает более новыми узлы Ethereum более жизнеспособными, поддерживающими только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранилища, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
Срок действия
Какую проблему это решает?
Даже если мы устраним необходимость хранения истории на клиенте, требования к хранению на клиенте будут продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, коды контрактов и хранилища контрактов. Пользователи могут оплатить единовременную плату, тем самым навлекая на нынешних и будущих клиентов Ethereum бремя.
Состояние сложнее "исторического" в том смысле, что EVM изначально проектировался с учетом предположения, что как только объект состояния создан, он будет всегда существовать и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не такой уж плохой: только специализированные классы строительств блоков должны фактически хранить состояние, в то время как все остальные узлы (включая генерацию списков!) могут работать без состояния. Тем не менее, существует точка зрения, что мы не хотим слишком сильно полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы сохранить децентрализацию Ethereum.
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из следующих трех способов: (i) отправив ETH на новый счет, (ii) создав новый счет с помощью кода, (iii) установив ранее не затрагиваемый слот хранилища), этот объект состояния навсегда остается в этом состоянии. Напротив, то, что мы хотим, это чтобы объект автоматически устаревал с течением времени. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователя: если кто-то зайдет в пещеру на пять лет и вернется, он не должен терять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переходить на совершенно незнакомую модель мышления. Кроме того, существующие устаревшие и не обновляемые приложения должны продолжать нормально функционировать.
Неудовлетворение этих целей делает решение проблем достаточно простым. Например, вы можете заставить каждый объект состояния также хранить счетчик истечения срока действия (который можно продлить с помощью сжигания Эфира, что может происходить автоматически при любом чтении или записи), и есть процесс, который перебирает состояния, чтобы удалить объекты состояния с истекшим сроком действия. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также сложно рассуждать о крайних случаях, когда значения хранятся, а затем иногда сбрасываются до нуля. Если вы установите таймер истечения срока действия в рамках контракта, это технически упростит жизнь разработчикам, но усложнит экономическую сторону: разработчики должны учитывать, как "переложить" постоянные затраты на хранение на пользователей.
Эти вопросы являются теми, над которыми ядро разработчиков Ethereum работало в течение многих лет, включая такие предложения, как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "известных наименее худших решений":
Решение для устаревших статусов
Рекомендации по истечению срока состояния на основе адресного цикла.
Частичное истечение состояния
Некоторые предложения по истечению срока действия состояния следуют одним и тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", где блок пуст.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Ethereum The Purge: снижение сложности, повышение устойчивости и безопасности
Будущее Эфириума: The Purge
Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем увеличиваются. Это происходит в двух аспектах:
Исторические данные: любые транзакции, проведенные в любой момент времени в прошлом, и любые созданные аккаунты должны храниться всеми клиентами постоянно и загружаться любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функция протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но в то же время мы должны сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных торговой транзакции или смарт-контракт на сумму 1 миллион долларов на цепочке, войти в пещеру на десять лет, а затем выйти и обнаружить, что он по-прежнему там, ожидая вашего чтения и взаимодействия. Чтобы DApp могли с уверенностью полностью децентрализоваться и удалить ключи обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным образом - особенно L1 сам по себе.
Если мы решим добиться баланса между этими двумя потребностями и при этом минимизировать или обратить вспять избыточность, сложность и упадок, сохраняя непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы сигнальной цепи хранили старые данные в течение максимум шести месяцев. Найти этот путь для Ethereum более универсальным способом и двигаться к долгосрочному стабильному конечному результату является конечной проблемой долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
! Виталик: возможное будущее для Ethereum, чистка
The Purge: Основная цель.
Снижение требований к хранилищу клиентов путем уменьшения или устранения необходимости в том, чтобы каждый узел постоянно хранил все исторические записи или даже конечное состояние.
Снижение сложности протокола путем устранения ненужных функций.
Содержание статьи:
Историческая запись истекла
Состояние истечения срока
Очистка функционала（特征清理）
История истечения
Какую проблему решает?
На момент написания этой статьи полностью синхронизированный узел Ethereum требует около 1.1 ТБ дискового пространства для работы клиента, а также сотни ГБ дискового пространства для клиентa консенсуса. Большая часть из этого - это история: данные о исторических блоках, сделках и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевая упрощенная характеристика проблемы хранения истории заключается в том, что поскольку каждый блок связан с предыдущим блоком через хэш (и другие структуры), для достижения консенсуса по текущему блоку достаточно достичь консенсуса по истории. Пока сеть достигнет консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его корректность. Консенсус — это модель доверия N/2 из N, в то время как история — это модель доверия N из N.
Это предоставляет нам множество вариантов хранения истории. Естественный выбор - это сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распространяет миллионы файлов, каждый участник хранит и распространяет лишь несколько из них. Возможно, вопреки интуиции, этот метод даже не обязательно снижает надежность данных. Если мы можем создать более экономичную систему, позволяя узлам работать более эффективно, мы можем построить сеть из 100 000 узлов, где каждый узел хранит случайные 10% истории, тогда каждая единица данных будет скопирована 10 000 раз - что совершенно соответствует коэффициенту копирования в сети из 10 000 узлов, где каждый узел хранит все данные.
Сегодня Эфир начал избавляться от модели, при которой все узлы постоянно хранят всю историю. Консенсусный блок (то есть часть, связанная с консенсусом на основе доли) хранит только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 направлен на введение годового срока хранения для исторических блоков и записей. Долгосрочная цель заключается в создании единого периода (возможно, около 18 дней), в течение которого каждый узел будет нести ответственность за хранение всего, а затем создать одноранговую сеть, состоящую из узлов Эфира, которая будет хранить старые данные в распределенной сети.
Коды стирания могут быть использованы для повышения устойчивости при сохранении одинакового фактора репликации. Фактически, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и помещение данных выполнения и консенсуса блока также в blob.
Каковы связи с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444；
Портал сети;
Портальная сеть и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как увеличить лимит газа (Paradigm).
Что еще нужно сделать, какие компромиссы нужно учитывать?
Основная работа заключается в создании и интеграции конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение - это (i) просто внедрить существующую библиотеку торрент, а также (ii) решение Ethereum, называемое сетью Portal. Как только одно из них будет внедрено, мы сможем активировать EIP-4444. Сам EIP-4444 не требует жесткого форка, но требует новой версии сетевого протокола. Поэтому имеет смысл активировать его для всех клиентов одновременно, иначе существует риск сбоя клиента из-за подключения к другим узлам, ожидая загрузки полной истории, но на самом деле не получая ее.
Основные компромиссы касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение — завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет позицию Эфира как места для постоянной записи. Более сложный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция исторического хранилища в протокол?
Экстремальный параноидальный подход к (1) будет включать в себя доказательство хранения: фактически требуя от каждого валидатора доказательства доли хранения определенного процента исторических данных и регулярно проверять их на наличие этих данных в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процентного соотношения исторических данных, хранящихся каждым клиентом.
Что касается (2), базовая реализация включает только работу, завершенную на сегодня: Portal уже хранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет заключаться в фактическом подключении его к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, они смогут сделать это через прямую синхронизацию из сетевого портала, даже если нет других архивных узлов, работающих онлайн.
Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали исключительно простыми, то уменьшение требований к хранилищу истории можно считать более важным, чем безсостояние: из необходимых 1,1 ТБ узла около 300 ГБ — это состояние, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Эфир на смарт-часах, который можно настроить всего за несколько минут.
Ограничение хранения истории также делает более новыми узлы Ethereum более жизнеспособными, поддерживающими только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранилища, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
Срок действия
Какую проблему это решает?
Даже если мы устраним необходимость хранения истории на клиенте, требования к хранению на клиенте будут продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, коды контрактов и хранилища контрактов. Пользователи могут оплатить единовременную плату, тем самым навлекая на нынешних и будущих клиентов Ethereum бремя.
Состояние сложнее "исторического" в том смысле, что EVM изначально проектировался с учетом предположения, что как только объект состояния создан, он будет всегда существовать и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не такой уж плохой: только специализированные классы строительств блоков должны фактически хранить состояние, в то время как все остальные узлы (включая генерацию списков!) могут работать без состояния. Тем не менее, существует точка зрения, что мы не хотим слишком сильно полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы сохранить децентрализацию Ethereum.
! Виталик: Возможное будущее Ethereum, Чистка
Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из следующих трех способов: (i) отправив ETH на новый счет, (ii) создав новый счет с помощью кода, (iii) установив ранее не затрагиваемый слот хранилища), этот объект состояния навсегда остается в этом состоянии. Напротив, то, что мы хотим, это чтобы объект автоматически устаревал с течением времени. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователя: если кто-то зайдет в пещеру на пять лет и вернется, он не должен терять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переходить на совершенно незнакомую модель мышления. Кроме того, существующие устаревшие и не обновляемые приложения должны продолжать нормально функционировать.
Неудовлетворение этих целей делает решение проблем достаточно простым. Например, вы можете заставить каждый объект состояния также хранить счетчик истечения срока действия (который можно продлить с помощью сжигания Эфира, что может происходить автоматически при любом чтении или записи), и есть процесс, который перебирает состояния, чтобы удалить объекты состояния с истекшим сроком действия. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также сложно рассуждать о крайних случаях, когда значения хранятся, а затем иногда сбрасываются до нуля. Если вы установите таймер истечения срока действия в рамках контракта, это технически упростит жизнь разработчикам, но усложнит экономическую сторону: разработчики должны учитывать, как "переложить" постоянные затраты на хранение на пользователей.
! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
Эти вопросы являются теми, над которыми ядро разработчиков Ethereum работало в течение многих лет, включая такие предложения, как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "известных наименее худших решений":
Частичное истечение состояния
Некоторые предложения по истечению срока действия состояния следуют одним и тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", где блок пуст.