Одним из вызовов, с которым сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем увеличиваются. Это происходит в двух аспектах:
Исторические данные: все транзакции, проведенные в любой момент в истории, и любые созданные аккаунты должны храниться всеми клиентами на постоянной основе и загружаться любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к увеличению нагрузки на клиента и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функция протокола: добавление новых функций гораздо легче, чем удаление старых функций, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодавление на эти две тенденции, со временем снижая сложность и расширение. Но в то же время нам нужно сохранить одно из ключевых свойств, которое делает блокчейн великим: долговечность. Вы можете разместить NFT, письмо любви в данных о транзакции или смарт-контракт на 1 миллион долларов в блокчейне, зайти в пещеру на десять лет и, выйдя, обнаружить, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи для обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно L1.
Если мы решим сбалансировать эти две потребности и при этом минимизировать или обратить вспять громоздкость, сложность и упадок, сохранив непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют с течением времени, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, код операции SELFDESTRUCT в значительной степени исчез, узлы цепи Beacon хранили старые данные максимум шесть месяцев. Найти этот путь для Ethereum более универсальным способом и двигаться к долгосрочному стабильному конечному результату — это высший вызов для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
Снижение требований к хранению клиента за счет уменьшения или устранения необходимости для каждого узла постоянно хранить все исторические записи или даже конечное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
История истечения срока действия（历史记录到期）
Состояние истечения срока действия（状态到期）
Очистка функции（特征清理）
История истечения срока
Какую проблему решает?
На момент написания этой статьи для полностью синхронизированного узла Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для консенсусного клиента. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
Ключевой упрощенной характеристикой проблемы хранения истории является то, что поскольку каждый блок связан с предыдущим через хэш (и другие структуры), для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Пока сеть достигла консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его правильность. Консенсус является моделью доверия N/2 из N, в то время как история — моделью доверия N из N.
Это предоставляет нам множество вариантов для хранения истории. Одним из естественных выборов является сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так функционировали сети семян на протяжении десятков лет: хотя сеть в целом хранила и распространяла миллионы файлов, каждый участник хранил и распространял лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если мы можем создать более экономичный способ работы узлов, мы можем построить сеть из 100,000 узлов, где каждый узел хранит случайные 10% истории, тогда каждая единица данных будет копироваться 10,000 раз - что совершенно аналогично сети из 10,000 узлов с коэффициентом копирования, где каждый узел хранит все данные.
Теперь Ethereum начал отходить от модели, в которой все узлы постоянно хранят всю историю. Консенсусные блоки (то есть часть, связанная с консенсусом на основе доли) хранятся только около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 предназначен для введения годового срока хранения для исторических блоков и квитанций. Долгосрочная цель заключается в создании единого периода (возможно, около 18 дней), в течение которого каждый узел будет нести ответственность за хранение всего, а затем будет создана пиринговая сеть из узлов Ethereum, которая будет хранить старые данные в распределенном сетевом формате.
Коды стирания могут быть использованы для повышения надежности при сохранении одинакового фактора репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и включение выполнения и данных блоков консенсуса также в blob.
Каковы связи с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444；
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как повысить лимит газа (Paradigm).
Что еще нужно сделать, что нужно учесть?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включает согласие и blob. Самое простое решение состоит в том, чтобы просто внедрить существующую библиотеку torrent, а также решение на Эфире, называемое сетью Portal. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл включить его одновременно для всех клиентов, иначе существует риск сбоя клиента из-за подключения к другим узлам с ожиданием загрузки полной истории, но на самом деле она не будет получена.
Основные компромиссы касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение — остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но ослабляет статус Эфира как постоянного места записи. Более трудный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем убедиться, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция хранения истории в протокол?
Один из экстремальных параноидальных подходов к (1) будет включать в себя доказательство хранения: фактически требуя от каждого валидатора proof-of-stake хранить определенный процент исторических данных и регулярно проверять криптографически, делают ли они это. Более мягкий подход заключается в том, чтобы установить добровольный стандарт для процентного соотношения исторических данных, хранящихся каждым клиентом.
Что касается (, базовая реализация включает только ту работу, которая уже выполнена на сегодня: Портал уже хранил ERA-файл, содержащий всю историю Ethereum. Более полная реализация будет включать в себя фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не находятся онлайн, они смогут сделать это через прямую синхронизацию с сети Портала.
)# Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали крайне простыми, то сокращение требований к историческому хранению можно считать более важным, чем безсостояние: из необходимых узлу 1.1 ТБ около 300 ГБ составляет состояние, а оставшиеся около 800 ГБ стали историей. Только при реализации безсостояния и EIP-4444 можно достичь видения о том, чтобы запустить узел Ethereum на умных часах и настроить его всего за несколько минут.
Ограничение исторического хранилища также делает более новые узлы Ethereum более жизнеспособными, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые хранилищные слоты, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении на клиенте будет продолжать расти примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут оплатить единовременную плату, тем самым навсегда обременив текущих и будущих клиентов Ethereum.
Статус гораздо труднее "истечь", чем история, потому что EVM изначально была разработана на основе такого предположения: как только объект состояния создан, он будет существовать всегда и может быть прочитан в любой момент любыми транзакциями. Если мы введем безсостояние, некоторые считают, что эта проблема, возможно, не так уж и плоха: только специализированные классы строителей блоков должны фактически хранить состояние, тогда как все остальные узлы (даже те, которые включают генерацию списков!) могут работать без состояния. Однако есть мнение, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим для поддержания децентрализации Ethereum.
Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из трех способов: (i) отправка ETH на новый аккаунт, (ii) создание нового аккаунта с помощью кода, (iii) установка ранее не использованного слота хранения), этот объект состояния навсегда остается в этом состоянии. Напротив, мы хотим, чтобы объект автоматически устаревал с течением времени. Ключевая задача состоит в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется大量 дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователя: если кто-то зайдет в пещеру на пять лет и вернется, он не должен потерять доступ к ETH, ERC20, NFT, CDP позициям...
Дружественность к разработчикам: разработчикам не нужно переключаться на полностью незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.
Неудовлетворение этих целей может легко решить проблему. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения (который может быть продлен путем сжигания ETH, что может происходить автоматически при чтении или записи в любое время) и иметь цикл для обхода состояния с целью удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству пользователя. Разработчикам также трудно рассуждать о крайних случаях, когда хранимые значения иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения внутри контракта, это технически упростит жизнь разработчикам, но это сделает экономику более сложной: разработчики должны подумать о том, как "перенести" постоянные затраты на хранение на пользователей.
Эти вопросы являются теми, над которыми ядро разработчиков Ethereum работает на протяжении многих лет, включая такие предложения, как "блокчейн-рента" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
Решение для устаревших частей состояния
Рекомендации по истечению статуса на основе периодов адресов.
Частичное истечение состояния
Некоторые истекающие предложения состояния следуют тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "топ-карт" , где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только в том случае, если они были недавно доступны. Существует механизм "воскрешения", если данные больше не хранятся.
Основное различие между этими предложениями заключается в следующем: (i) как мы определяем "недавно", и (ii) как мы
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
4
Репост
Поделиться
комментарий
0/400
0xTherapist
· 3ч назад
Перезагрузка давно должна была произойти, пора худеть.
Посмотреть ОригиналОтветить0
NoodlesOrTokens
· 08-10 22:26
в блокчейне塞的太满啦 赶紧清理
Посмотреть ОригиналОтветить0
PumpDetector
· 08-10 22:18
умные деньги наблюдали за этим очищением... именно о чем мы предупреждали в 2017 году, если честно
Посмотреть ОригиналОтветить0
LiquidatorFlash
· 08-10 22:12
в блокчейне исторические данные +3.47T, риск Хеджирование, сделайте насчет до обнуления
Ethereum Пурга план: историческое устаревание и упрощение состояния против сложной экспансии
Будущее Эфира: The Purge
Одним из вызовов, с которым сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола со временем увеличиваются. Это происходит в двух аспектах:
Исторические данные: все транзакции, проведенные в любой момент в истории, и любые созданные аккаунты должны храниться всеми клиентами на постоянной основе и загружаться любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к увеличению нагрузки на клиента и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функция протокола: добавление новых функций гораздо легче, чем удаление старых функций, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долго существовать, нам необходимо оказать сильное противодавление на эти две тенденции, со временем снижая сложность и расширение. Но в то же время нам нужно сохранить одно из ключевых свойств, которое делает блокчейн великим: долговечность. Вы можете разместить NFT, письмо любви в данных о транзакции или смарт-контракт на 1 миллион долларов в блокчейне, зайти в пещеру на десять лет и, выйдя, обнаружить, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи для обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно L1.
Если мы решим сбалансировать эти две потребности и при этом минимизировать или обратить вспять громоздкость, сложность и упадок, сохранив непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют с течением времени, некоторые счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, код операции SELFDESTRUCT в значительной степени исчез, узлы цепи Beacon хранили старые данные максимум шесть месяцев. Найти этот путь для Ethereum более универсальным способом и двигаться к долгосрочному стабильному конечному результату — это высший вызов для долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
! Виталик: возможное будущее для Ethereum, чистка
Чистка: Основная цель.
Снижение требований к хранению клиента за счет уменьшения или устранения необходимости для каждого узла постоянно хранить все исторические записи или даже конечное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
История истечения срока действия（历史记录到期）
Состояние истечения срока действия（状态到期）
Очистка функции（特征清理）
История истечения срока
Какую проблему решает?
На момент написания этой статьи для полностью синхронизированного узла Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для консенсусного клиента. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и квитанциях, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит Gas не увеличивается, размер узла будет продолжать увеличиваться на сотни ГБ каждый год.
! Виталик: Возможное будущее Ethereum, Чистка
Что это такое и как это работает?
Ключевой упрощенной характеристикой проблемы хранения истории является то, что поскольку каждый блок связан с предыдущим через хэш (и другие структуры), для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Пока сеть достигла консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником вместе с доказательством Меркла, и это доказательство позволяет любому другому проверить его правильность. Консенсус является моделью доверия N/2 из N, в то время как история — моделью доверия N из N.
Это предоставляет нам множество вариантов для хранения истории. Одним из естественных выборов является сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так функционировали сети семян на протяжении десятков лет: хотя сеть в целом хранила и распространяла миллионы файлов, каждый участник хранил и распространял лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает надежность данных. Если мы можем создать более экономичный способ работы узлов, мы можем построить сеть из 100,000 узлов, где каждый узел хранит случайные 10% истории, тогда каждая единица данных будет копироваться 10,000 раз - что совершенно аналогично сети из 10,000 узлов с коэффициентом копирования, где каждый узел хранит все данные.
Теперь Ethereum начал отходить от модели, в которой все узлы постоянно хранят всю историю. Консенсусные блоки (то есть часть, связанная с консенсусом на основе доли) хранятся только около 6 месяцев. Blob хранится всего около 18 дней. EIP-4444 предназначен для введения годового срока хранения для исторических блоков и квитанций. Долгосрочная цель заключается в создании единого периода (возможно, около 18 дней), в течение которого каждый узел будет нести ответственность за хранение всего, а затем будет создана пиринговая сеть из узлов Ethereum, которая будет хранить старые данные в распределенном сетевом формате.
Коды стирания могут быть использованы для повышения надежности при сохранении одинакового фактора репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и включение выполнения и данных блоков консенсуса также в blob.
Каковы связи с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444；
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как повысить лимит газа (Paradigm).
Что еще нужно сделать, что нужно учесть?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включает согласие и blob. Самое простое решение состоит в том, чтобы просто внедрить существующую библиотеку torrent, а также решение на Эфире, называемое сетью Portal. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл включить его одновременно для всех клиентов, иначе существует риск сбоя клиента из-за подключения к другим узлам с ожиданием загрузки полной истории, но на самом деле она не будет получена.
Основные компромиссы касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение — остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но ослабляет статус Эфира как постоянного места записи. Более трудный, но более безопасный путь — сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем убедиться, что максимальный набор узлов действительно хранит все данные?
Насколько глубока интеграция хранения истории в протокол?
Один из экстремальных параноидальных подходов к (1) будет включать в себя доказательство хранения: фактически требуя от каждого валидатора proof-of-stake хранить определенный процент исторических данных и регулярно проверять криптографически, делают ли они это. Более мягкий подход заключается в том, чтобы установить добровольный стандарт для процентного соотношения исторических данных, хранящихся каждым клиентом.
Что касается (, базовая реализация включает только ту работу, которая уже выполнена на сегодня: Портал уже хранил ERA-файл, содержащий всю историю Ethereum. Более полная реализация будет включать в себя фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не находятся онлайн, они смогут сделать это через прямую синхронизацию с сети Портала.
)# Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали крайне простыми, то сокращение требований к историческому хранению можно считать более важным, чем безсостояние: из необходимых узлу 1.1 ТБ около 300 ГБ составляет состояние, а оставшиеся около 800 ГБ стали историей. Только при реализации безсостояния и EIP-4444 можно достичь видения о том, чтобы запустить узел Ethereum на умных часах и настроить его всего за несколько минут.
Ограничение исторического хранилища также делает более новые узлы Ethereum более жизнеспособными, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые хранилищные слоты, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
! Виталик: Возможное будущее Ethereum, Чистка
( Срок действия
)# Какую проблему решает?
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении на клиенте будет продолжать расти примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут оплатить единовременную плату, тем самым навсегда обременив текущих и будущих клиентов Ethereum.
Статус гораздо труднее "истечь", чем история, потому что EVM изначально была разработана на основе такого предположения: как только объект состояния создан, он будет существовать всегда и может быть прочитан в любой момент любыми транзакциями. Если мы введем безсостояние, некоторые считают, что эта проблема, возможно, не так уж и плоха: только специализированные классы строителей блоков должны фактически хранить состояние, тогда как все остальные узлы (даже те, которые включают генерацию списков!) могут работать без состояния. Однако есть мнение, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим для поддержания децентрализации Ethereum.
Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из трех способов: (i) отправка ETH на новый аккаунт, (ii) создание нового аккаунта с помощью кода, (iii) установка ранее не использованного слота хранения), этот объект состояния навсегда остается в этом состоянии. Напротив, мы хотим, чтобы объект автоматически устаревал с течением времени. Ключевая задача состоит в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется大量 дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователя: если кто-то зайдет в пещеру на пять лет и вернется, он не должен потерять доступ к ETH, ERC20, NFT, CDP позициям...
Дружественность к разработчикам: разработчикам не нужно переключаться на полностью незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.
Неудовлетворение этих целей может легко решить проблему. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения (который может быть продлен путем сжигания ETH, что может происходить автоматически при чтении или записи в любое время) и иметь цикл для обхода состояния с целью удаления объектов состояния с истекшей датой. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству пользователя. Разработчикам также трудно рассуждать о крайних случаях, когда хранимые значения иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения внутри контракта, это технически упростит жизнь разработчикам, но это сделает экономику более сложной: разработчики должны подумать о том, как "перенести" постоянные затраты на хранение на пользователей.
Эти вопросы являются теми, над которыми ядро разработчиков Ethereum работает на протяжении многих лет, включая такие предложения, как "блокчейн-рента" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
Частичное истечение состояния
Некоторые истекающие предложения состояния следуют тем же принципам. Мы делим состояние на блоки. Каждый навсегда хранит "топ-карт" , где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только в том случае, если они были недавно доступны. Существует механизм "воскрешения", если данные больше не хранятся.
Основное различие между этими предложениями заключается в следующем: (i) как мы определяем "недавно", и (ii) как мы