Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию раздутость и сложность любого блокчейн-протокола будут увеличиваться со временем. Это происходит в двух аспектах:
Исторические данные: любые транзакции, проведенные в любой момент времени в прошлом, и любые созданные учетные записи должны постоянно храниться всеми клиентами и загружаться любыми новыми клиентами, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций значительно проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долгосрочно сохраняться, нам необходимо оказать мощное противодействие этим двум тенденциям, снижая сложность и расширение с течением времени. Но в то же время мы должны сохранить одну из ключевых характеристик, делающих блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных торгового вызова или смарт-контракт на сумму 1 миллион долларов в сети, зайти в пещеру на десять лет и выйти, обнаружив, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключ для обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно сам L1.
Если мы решим добиться баланса между этими двумя потребностями и одновременно минимизировать или обратить вспять громоздкость, сложность и упадок, это абсолютно возможно. Биологические организмы могут это сделать: хотя большинство организмов стареет со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы маяка хранили максимум шесть месяцев старых данных. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является конечной задачей долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
Снизить требования к хранению клиентов, уменьшив или устранив необходимость в том, чтобы каждый узел постоянно хранил все исторические записи или даже окончательное состояние.
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиентского программного обеспечения консенсуса. Большая часть этого пространства занята историей: данными о исторических блоках, транзакциях и квитанциях, большинство из которых имеют многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать расти на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевой упрощенной характеристикой проблемы хранения истории является то, что каждый блок ссылается на предыдущий блок через хеш-ссылки (и другие структуры), поэтому для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Пока сеть достигла консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником и Merkle-доказательством, которое позволяет любому другому проверить его правильность. Консенсус является моделью доверия 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) просто внедрить существующие библиотеки torrent, а также (ii), называемое нативным решением Ethereum под названием Portal Network. Как только одно из них будет внедрено, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл активировать его для всех клиентов одновременно, иначе существует риск, что клиенты выйдут из строя, ожидая загрузки полной истории, подключаясь к другим узлам, но на самом деле не получая ее.
Основные компромиссы касаются того, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — это завтра прекратить хранить древнюю историю и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала построить и интегрировать torrent-сеть для распределенного хранения истории. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что самый большой набор узлов действительно хранит все данные?
Насколько глубоко интегрировано историческое хранилище в протокол?
Экстремальный параноидальный подход к (1) будет включать в себя доказательство хранения: фактически требуя, чтобы каждый валидатор доказательства доли хранил определенный процент истории и регулярно проверял, делает ли он это в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента истории, хранимой каждым клиентом.
Что касается (2), базовая реализация включает только работу, завершенную сегодня: Portal уже сохранил файл ERA, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не онлайн, они смогут сделать это через прямую синхронизацию из сети портала.
Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы работа или запуск узлов стали исключительно простыми, то можно сказать, что снижение требований к историческому хранилищу важнее, чем безсостояние: из 1,1 ТБ, необходимых узлу, около 300 ГБ составляют состояние, а оставшиеся около 800 ГБ стали историей. Лишь с достижением безсостояния и EIP-4444 можно реализовать видение запуска узла Ethereum на смарт-часах и настройки всего за несколько минут.
Ограничение исторического хранения также делает реализацию более новых узлов Ethereum более жизнеспособной, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые хранилища, созданные во время атаки DoS в 2016 году, были полностью удалены. Поскольку переход на proof-of-stake стал историей, клиенты могут безопасно удалить весь код, связанный с proof-of-work.
Срок действия
Какие проблемы решает?
Даже если мы устраним необходимость в хранении истории на клиентской стороне, потребность в хранении на клиентской стороне будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут заплатить одноразовую плату, тем самым навлекая бремя на текущие и будущие клиентов Ethereum.
Состояние сложнее "исторического" в том смысле, что EVM изначально построен на предположении, что как только объект состояния создан, он будет существовать всегда и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что проблема может не быть такой уж плохой: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все другие узлы (даже включая генерацию списков!) могут работать без состояния. Тем не менее, существует точка зрения, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы, возможно, захотим сделать состояние устаревшим для поддержания децентрализации Ethereum.
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из трех способов: (i) отправив ETH на новый аккаунт, (ii) создав новый аккаунт с помощью кода, (iii) установив ранее не использованный слот хранения), этот объект состояния остается в этом состоянии навсегда. Напротив, мы хотим, чтобы объект автоматически устаревал с течением времени. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для запуска процесса истечения.
Удобство для пользователя: если кто-то войдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, приложения, которые в настоящее время устарели и не обновляются, должны продолжать нормально работать.
Неудовлетворение этих целей делает решение проблемы довольно простым. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения (который может быть продлен сжиганием Эфира, что может происходить автоматически в любой момент при чтении или записи), и иметь цикл, который проходит по состояниям для удаления объектов состояния с истекшей датой. Тем не менее, это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству использования. Разработчикам также сложно рассуждать о крайних случаях, когда значения хранятся и иногда сбрасываются в ноль. Если вы установите таймер истечения в рамках контракта, это технически упростит жизнь разработчикам, но сделает экономику более сложной: разработчикам необходимо учитывать, как "переложить" постоянные расходы на хранение на пользователей.
Все это проблемы, над которыми ядро разработки Эфир сообщества работало в течение многих лет, включая такие предложения, как "аренда блокчейна" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих решений":
Решение для некоторых устаревших статусов
Рекомендуется срок действия статуса на основе периода адреса.
Частичное истечение срока действия состояния
Некоторые предложения о состоянии истекают и следуют тем же принципам. Мы разделяем состояние на блоки. Каждый навсегда хранит "высшую карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только если данные были недавно доступны. Существует механизм "воскресения", который активируется, если данные больше не хранятся.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
3
Репост
Поделиться
комментарий
0/400
GasWaster
· 2ч назад
Отбросив лишнее, мы достигли сути.
Посмотреть ОригиналОтветить0
ChainSherlockGirl
· 2ч назад
Скорее худей, Виталик Бутерин, у тебя в блокчейне уже почти все ликвидировано.
Виталик представил видение Ethereum The Purge: Падение сложности для достижения долгосрочного устойчивого развития
Виталик: Возможное будущее Эфириума, The Purge
Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию раздутость и сложность любого блокчейн-протокола будут увеличиваться со временем. Это происходит в двух аспектах:
Исторические данные: любые транзакции, проведенные в любой момент времени в прошлом, и любые созданные учетные записи должны постоянно храниться всеми клиентами и загружаться любыми новыми клиентами, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функции протокола: добавление новых функций значительно проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долгосрочно сохраняться, нам необходимо оказать мощное противодействие этим двум тенденциям, снижая сложность и расширение с течением времени. Но в то же время мы должны сохранить одну из ключевых характеристик, делающих блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных торгового вызова или смарт-контракт на сумму 1 миллион долларов в сети, зайти в пещеру на десять лет и выйти, обнаружив, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключ для обновления, им необходимо быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно сам L1.
Если мы решим добиться баланса между этими двумя потребностями и одновременно минимизировать или обратить вспять громоздкость, сложность и упадок, это абсолютно возможно. Биологические организмы могут это сделать: хотя большинство организмов стареет со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы маяка хранили максимум шесть месяцев старых данных. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является конечной задачей долгосрочной масштабируемости Ethereum, технической устойчивости и даже безопасности.
! Виталик: возможное будущее для Ethereum, чистка
Чистка: основные цели.
Снизить требования к хранению клиентов, уменьшив или устранив необходимость в том, чтобы каждый узел постоянно хранил все исторические записи или даже окончательное состояние.
Снизить сложность протокола, устранив ненужные функции.
Содержание статьи:
История истечения срока действия（历史记录到期）
Состояние истекает
Очистка характеристик（特征清理）
Истечение истории
Решает какую проблему?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиентского программного обеспечения консенсуса. Большая часть этого пространства занята историей: данными о исторических блоках, транзакциях и квитанциях, большинство из которых имеют многолетнюю историю. Это означает, что даже если лимит Gas вообще не увеличивается, размер узла будет продолжать расти на сотни ГБ каждый год.
Что это такое и как это работает?
Ключевой упрощенной характеристикой проблемы хранения истории является то, что каждый блок ссылается на предыдущий блок через хеш-ссылки (и другие структуры), поэтому для достижения консенсуса по текущему состоянию достаточно достичь консенсуса по истории. Пока сеть достигла консенсуса по последнему блоку, любой исторический блок, транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником и Merkle-доказательством, которое позволяет любому другому проверить его правильность. Консенсус является моделью доверия N/2 из N, в то время как история — это модель доверия N из N.
Это дает нам множество вариантов, как хранить исторические записи. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работает сеть семян на протяжении десятилетий: хотя сеть в целом хранит и распределяет миллионы файлов, каждый участник хранит и распределяет лишь несколько из них. Возможно, вопреки интуиции, такой подход даже не обязательно снижает устойчивость данных. Если мы можем сделать работу узлов более экономически эффективной, мы можем создать сеть из 100,000 узлов, в которой каждый узел хранит случайные 10% исторических записей, тогда каждая запись данных будет скопирована 10,000 раз - что абсолютно совпадает с коэффициентом копирования сети из 10,000 узлов, где каждый узел хранит все данные.
Сегодня Эфир начал избавляться от модели, при которой все узлы хранят всю историю навсегда. Консенсусный блок (то есть часть, связанная с консенсусом на основе долевого участия) хранит только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 нацелен на введение годового срока хранения для исторических блоков и квитанций. Долгосрочная цель заключается в создании единого периода (возможно, около 18 дней), в течение которого каждый узел отвечает за хранение всего, а затем создание одноранговой сети из узлов Эфира, которая будет хранить старые данные в распределенной сети.
! Виталик: Возможное будущее Ethereum, Чистка
Коды стирания могут быть использованы для повышения надежности при сохранении одинакового коэффициента репликации. На самом деле, Blob уже использует коды исправления, чтобы поддерживать выборку доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных выполнения и консенсусного блока также в blob.
с чем связаны существующие исследования?
ЭИП-4444;
Торренты и EIP-4444；
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как повысить лимит газа (Paradigm).
Что еще нужно сделать, что нужно взвесить?
Основная работа, которая осталась, включает в себя создание и интеграцию конкретного распределенного решения для хранения истории - по крайней мере, истории выполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение состоит в том, чтобы (i) просто внедрить существующие библиотеки torrent, а также (ii), называемое нативным решением Ethereum под названием Portal Network. Как только одно из них будет внедрено, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл активировать его для всех клиентов одновременно, иначе существует риск, что клиенты выйдут из строя, ожидая загрузки полной истории, подключаясь к другим узлам, но на самом деле не получая ее.
Основные компромиссы касаются того, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — это завтра прекратить хранить древнюю историю и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала построить и интегрировать torrent-сеть для распределенного хранения истории. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что самый большой набор узлов действительно хранит все данные?
Насколько глубоко интегрировано историческое хранилище в протокол?
Экстремальный параноидальный подход к (1) будет включать в себя доказательство хранения: фактически требуя, чтобы каждый валидатор доказательства доли хранил определенный процент истории и регулярно проверял, делает ли он это в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента истории, хранимой каждым клиентом.
Что касается (2), базовая реализация включает только работу, завершенную сегодня: Portal уже сохранил файл ERA, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не онлайн, они смогут сделать это через прямую синхронизацию из сети портала.
Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы работа или запуск узлов стали исключительно простыми, то можно сказать, что снижение требований к историческому хранилищу важнее, чем безсостояние: из 1,1 ТБ, необходимых узлу, около 300 ГБ составляют состояние, а оставшиеся около 800 ГБ стали историей. Лишь с достижением безсостояния и EIP-4444 можно реализовать видение запуска узла Ethereum на смарт-часах и настройки всего за несколько минут.
Ограничение исторического хранения также делает реализацию более новых узлов Ethereum более жизнеспособной, поддерживая только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые хранилища, созданные во время атаки DoS в 2016 году, были полностью удалены. Поскольку переход на proof-of-stake стал историей, клиенты могут безопасно удалить весь код, связанный с proof-of-work.
Срок действия
Какие проблемы решает?
Даже если мы устраним необходимость в хранении истории на клиентской стороне, потребность в хранении на клиентской стороне будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут заплатить одноразовую плату, тем самым навлекая бремя на текущие и будущие клиентов Ethereum.
Состояние сложнее "исторического" в том смысле, что EVM изначально построен на предположении, что как только объект состояния создан, он будет существовать всегда и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что проблема может не быть такой уж плохой: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все другие узлы (даже включая генерацию списков!) могут работать без состояния. Тем не менее, существует точка зрения, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы, возможно, захотим сделать состояние устаревшим для поддержания децентрализации Ethereum.
! Виталик: Возможное будущее Ethereum, Чистка
Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из трех способов: (i) отправив ETH на новый аккаунт, (ii) создав новый аккаунт с помощью кода, (iii) установив ранее не использованный слот хранения), этот объект состояния остается в этом состоянии навсегда. Напротив, мы хотим, чтобы объект автоматически устаревал с течением времени. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для запуска процесса истечения.
Удобство для пользователя: если кто-то войдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, приложения, которые в настоящее время устарели и не обновляются, должны продолжать нормально работать.
Неудовлетворение этих целей делает решение проблемы довольно простым. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения (который может быть продлен сжиганием Эфира, что может происходить автоматически в любой момент при чтении или записи), и иметь цикл, который проходит по состояниям для удаления объектов состояния с истекшей датой. Тем не менее, это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству использования. Разработчикам также сложно рассуждать о крайних случаях, когда значения хранятся и иногда сбрасываются в ноль. Если вы установите таймер истечения в рамках контракта, это технически упростит жизнь разработчикам, но сделает экономику более сложной: разработчикам необходимо учитывать, как "переложить" постоянные расходы на хранение на пользователей.
Все это проблемы, над которыми ядро разработки Эфир сообщества работало в течение многих лет, включая такие предложения, как "аренда блокчейна" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих решений":
Частичное истечение срока действия состояния
Некоторые предложения о состоянии истекают и следуют тем же принципам. Мы разделяем состояние на блоки. Каждый навсегда хранит "высшую карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только если данные были недавно доступны. Существует механизм "воскресения", который активируется, если данные больше не хранятся.
![Виталик: возможное будущее Эфира, Очищение](https://