Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух местах:
Исторические данные: любые транзакции и созданные учетные записи в любой момент в прошлом должны быть постоянно хранимы всеми клиентами и загружаться любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации со временем, даже если емкость цепи остается неизменной.
Функция протокола: добавление новых функций значительно проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать мощное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но в то же время мы должны сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных о транзакции или смарт-контракт на сумму 1 миллион долларов в сети, зайти в пещеру на десять лет и выйти, обнаружив, что он все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи для обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно сам L1.
Если мы решим сбалансировать эти две потребности и свести к минимуму или обратить вспять ненужные сложности, избыточность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Живые организмы могут это сделать: хотя большинство организмов стареют с течением времени, немногие счастливцы этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы цепочки Beacon хранили максимум шесть месяцев старых данных. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является высшим вызовом для долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
Очистка: основные цели.
Снизить требования к хранению клиентов, уменьшая или устраняя необходимость в том, чтобы каждый узел постоянно хранил все исторические записи, а также окончательное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
На момент написания этой статьи полностью синхронизированным узлам Ethereum требуется примерно 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиента консенсуса. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и чеках, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит газа не увеличивается, размер узлов будет продолжать расти на сотни ГБ каждый год.
Что это такое и как это работает?
Одной из ключевых упрощенных особенностей проблемы хранения истории является то, что, поскольку каждый блок ссылается на предыдущий блок через хэш-ссылку (и другие структуры), для достижения консенсуса по текущему блоку достаточно достичь консенсуса по истории. Пока сеть достигает консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником, а также доказательство Меркла, и это доказательство позволяет любому другому участнику проверить его правильность. Консенсус представляет собой модель доверия N/2 из N, в то время как история — это модель доверия N из N.
Это дает нам много вариантов для хранения исторических записей. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так работают сети семян на протяжении десятилетий: хотя сеть в целом хранит и распределяет миллионы файлов, каждый участник хранит и распределяет только несколько из них. Возможно, вопреки интуиции, этот метод даже не обязательно снижает надежность данных. Если мы сможем сделать работу узлов более экономически выгодной, мы можем создать сеть из 100,000 узлов, в которой каждый узел хранит случайные 10% исторических записей, тогда каждая запись будет скопирована 10,000 раз — что совершенно эквивалентно сети из 10,000 узлов с коэффициентом копирования, где каждый узел хранит все содержимое.
Сегодня Ethereum уже начал избавляться от модели, при которой все узлы постоянно хранят всю историю. Консенсусные блоки (то есть часть, связанная с консенсусом на основе доказательства доли) хранятся только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 нацелен на введение годичного срока хранения для исторических блоков и квитанций. Долгосрочная цель - создать единый срок (возможно, около 18 дней), в течение которого каждый узел отвечает за хранение всего, а затем создать пиринговую сеть из узлов Ethereum, которая будет хранить старые данные в распределенной сети.
Коды стирания могут использоваться для повышения надежности при сохранении одинакового коэффициента репликации. Фактически, Blob уже использует коды стирания для поддержки образцов доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных о выполнении и консенсусных блоках также в Blob.
Распределенное хранение и извлечение объектов SSZ в Portal;
Как увеличить лимит газа (Paradigm).
что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя построение и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории исполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение - это (i) просто ввести существующие библиотеки torrent, а также (ii), называемое нативным решением Ethereum Portal Network. Как только мы введем любое из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл одновременно включить его для всех клиентов, иначе существует риск, что клиент выйдет из строя, ожидая загрузки полной истории из-за подключения к другим узлам, которые на самом деле не предоставляют ее.
Основные соображения касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение - остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь - сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Какова глубина интеграции исторического хранилища в протокол?
Одним из крайних параноидальных подходов к (1) будет использование доказательства хранения: на самом деле это требует от каждого валидатора на основе доли хранения определенного процента исторических данных и регулярной проверки их на предмет соблюдения этого требования с помощью криптографических методов. Более мягкий подход заключается в установлении добровольного стандарта для процентного соотношения исторических данных, хранящихся каждым клиентом.
Что касается (2), базовая реализация включает только ту работу, которая уже была завершена сегодня: Portal уже хранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный узел хранения истории или архивный узел, даже если другие архивные узлы не находятся онлайн, они смогут это сделать через прямую синхронизацию из сети Portal.
Как это взаимодействует с другими частями дорожной карты?
Если мы хотим сделать запуск или работу узлов чрезвычайно простыми, то уменьшение требований к историческому хранилищу можно сказать более важно, чем безсостояние: из 1,1 ТБ, необходимых для узла, около 300 ГБ — это состояние, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Ethereum на смарт-часах и настройке всего за несколько минут.
Ограничение исторического хранилища также делает более новыми узлы Ethereum более жизнеспособными, поддерживая только последнюю версию протокола, что делает их более простыми. Например, теперь можно безопасно удалить множество строк кода, поскольку все пустые хранилища, созданные во время DoS-атаки 2016 года, были удалены. Поскольку переход на Эфир стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
Даже если мы устраним необходимость в хранении истории на клиенте, потребности в хранении на клиенте будут продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут платить единовременную плату, тем самым навлекая бремя на текущие и будущие клиенты Ethereum.
Состояние сложнее "исторического" срока, потому что EVM изначально была разработана с предположением, что как только объект состояния создан, он всегда будет существовать и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы (даже включая генерацию списка!) могут работать без состояния. Однако есть точка зрения, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы могли бы захотеть сделать состояние устаревшим, чтобы поддерживать децентрализацию Ethereum.
Что это такое и как это работает
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из трех способов: (i) отправив ETH на новый аккаунт, (ii) создав новый аккаунт с помощью кода, (iii) установив ранее неиспользуемый слот хранения), этот объект состояния остается в этом состоянии навсегда. Напротив, мы хотим, чтобы объект автоматически устаревал с течением времени. Ключевой задачей является сделать это так, чтобы достичь трех целей:
Эффективность: не требуется大量 дополнительных вычислений для выполнения процесса истечения.
Удобство использования: если кто-то провел пять лет в пещере и вернется, он не должен терять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переходить на совершенно незнакомую модель мышления. Кроме того, приложения, которые в настоящее время устарели и не обновляются, должны продолжать работать нормально.
Неудовлетворение этих целей может привести к легкому решению проблемы. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения (который может быть продлен путем сжигания ETH, что может происходить автоматически в любой момент при чтении или записи), и есть цикл, который проходит через состояние, чтобы удалить объекты состояния с истекшими сроками. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также трудно рассуждать о крайних случаях, когда значения хранятся и иногда сбрасываются на ноль. Если вы установите таймер истечения в пределах контракта, это технически упростит жизнь разработчику, но усложнит экономику: разработчику придется подумать о том, как "переложить" постоянные затраты на хранение на пользователей.
Эти проблемы являются теми, над которыми ядро сообщества разработчиков Ethereum работает на протяжении многих лет, включая такие предложения, как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "известных наименее плохих решений":
Решение для устаревших статусов
Рекомендации по истечению срока действия состояния на основе адресного периода.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
7
Поделиться
комментарий
0/400
Hash_Bandit
· 11ч назад
видел это раньше... как в дни майнинга, когда мы оптимизировали синхронизацию узлов. Эфиру действительно нужно больше хэшрейт-эффективности, если честно.
Посмотреть ОригиналОтветить0
ILCollector
· 08-04 07:11
Рекомендуется упаковать данные с использованием L2
Посмотреть ОригиналОтветить0
TokenomicsTrapper
· 08-03 21:09
назвал эту проблему раздувания месяцев назад... классическая спираль смерти технического долга на подходе
Посмотреть ОригиналОтветить0
HackerWhoCares
· 08-03 21:09
Хранение данных остается большой проблемой.
Посмотреть ОригиналОтветить0
DefiPlaybook
· 08-03 21:07
Анализ данных показывает, что проблема с взрывом состояния уже затронула 87% узлов в блокчейне.
Виталик анализирует будущее развития Ethereum: Анализ плана The Purge
Виталик: возможное будущее Эфира, The Purge
Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух местах:
Исторические данные: любые транзакции и созданные учетные записи в любой момент в прошлом должны быть постоянно хранимы всеми клиентами и загружаться любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиентов и времени синхронизации со временем, даже если емкость цепи остается неизменной.
Функция протокола: добавление новых функций значительно проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать мощное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но в то же время мы должны сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных о транзакции или смарт-контракт на сумму 1 миллион долларов в сети, зайти в пещеру на десять лет и выйти, обнаружив, что он все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли полностью децентрализоваться и удалить ключи для обновления, им необходимо быть уверенными, что их зависимости не будут обновлены разрушительным для них образом - особенно сам L1.
Если мы решим сбалансировать эти две потребности и свести к минимуму или обратить вспять ненужные сложности, избыточность и упадок, сохраняя при этом непрерывность, это абсолютно возможно. Живые организмы могут это сделать: хотя большинство организмов стареют с течением времени, немногие счастливцы этого не делают. Даже социальные системы могут иметь очень долгий срок жизни. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы цепочки Beacon хранили максимум шесть месяцев старых данных. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату является высшим вызовом для долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
Очистка: основные цели.
Снизить требования к хранению клиентов, уменьшая или устраняя необходимость в том, чтобы каждый узел постоянно хранил все исторические записи, а также окончательное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
История истечения срока действия（历史记录到期）
Государственная истечение (状态到期)
Очистка признаков（特征清理）
! Виталик: возможное будущее для Ethereum, чистка
Истечение срока истории
Решает какую проблему?
На момент написания этой статьи полностью синхронизированным узлам Ethereum требуется примерно 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ дискового пространства для клиента консенсуса. Большая часть этого объема - это история: данные о исторических блоках, транзакциях и чеках, большая часть из которых имеет многолетнюю историю. Это означает, что даже если лимит газа не увеличивается, размер узлов будет продолжать расти на сотни ГБ каждый год.
Что это такое и как это работает?
Одной из ключевых упрощенных особенностей проблемы хранения истории является то, что, поскольку каждый блок ссылается на предыдущий блок через хэш-ссылку (и другие структуры), для достижения консенсуса по текущему блоку достаточно достичь консенсуса по истории. Пока сеть достигает консенсуса по последнему блоку, любой исторический блок или транзакция или состояние (баланс счета, случайное число, код, хранилище) могут быть предоставлены любым отдельным участником, а также доказательство Меркла, и это доказательство позволяет любому другому участнику проверить его правильность. Консенсус представляет собой модель доверия N/2 из N, в то время как история — это модель доверия N из N.
Это дает нам много вариантов для хранения исторических записей. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Именно так работают сети семян на протяжении десятилетий: хотя сеть в целом хранит и распределяет миллионы файлов, каждый участник хранит и распределяет только несколько из них. Возможно, вопреки интуиции, этот метод даже не обязательно снижает надежность данных. Если мы сможем сделать работу узлов более экономически выгодной, мы можем создать сеть из 100,000 узлов, в которой каждый узел хранит случайные 10% исторических записей, тогда каждая запись будет скопирована 10,000 раз — что совершенно эквивалентно сети из 10,000 узлов с коэффициентом копирования, где каждый узел хранит все содержимое.
Сегодня Ethereum уже начал избавляться от модели, при которой все узлы постоянно хранят всю историю. Консенсусные блоки (то есть часть, связанная с консенсусом на основе доказательства доли) хранятся только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 нацелен на введение годичного срока хранения для исторических блоков и квитанций. Долгосрочная цель - создать единый срок (возможно, около 18 дней), в течение которого каждый узел отвечает за хранение всего, а затем создать пиринговую сеть из узлов Ethereum, которая будет хранить старые данные в распределенной сети.
Коды стирания могут использоваться для повышения надежности при сохранении одинакового коэффициента репликации. Фактически, Blob уже использует коды стирания для поддержки образцов доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных о выполнении и консенсусных блоках также в Blob.
! Виталик: Возможное будущее Ethereum, Чистка
с какими существующими исследованиями связана?
ЭИП-4444;
Торренты и EIP-4444；
Портальная сеть;
Портал сети и EIP-4444；
Распределенное хранение и извлечение объектов SSZ в Portal;
Как увеличить лимит газа (Paradigm).
что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя построение и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории исполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение - это (i) просто ввести существующие библиотеки torrent, а также (ii), называемое нативным решением Ethereum Portal Network. Как только мы введем любое из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл одновременно включить его для всех клиентов, иначе существует риск, что клиент выйдет из строя, ожидая загрузки полной истории из-за подключения к другим узлам, которые на самом деле не предоставляют ее.
Основные соображения касаются того, как мы стремимся предоставить "древние" исторические данные. Самое простое решение - остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет статус Эфира как места для постоянной записи. Более сложный, но более безопасный путь - сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Какова глубина интеграции исторического хранилища в протокол?
Одним из крайних параноидальных подходов к (1) будет использование доказательства хранения: на самом деле это требует от каждого валидатора на основе доли хранения определенного процента исторических данных и регулярной проверки их на предмет соблюдения этого требования с помощью криптографических методов. Более мягкий подход заключается в установлении добровольного стандарта для процентного соотношения исторических данных, хранящихся каждым клиентом.
Что касается (2), базовая реализация включает только ту работу, которая уже была завершена сегодня: Portal уже хранил ERA файл, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный узел хранения истории или архивный узел, даже если другие архивные узлы не находятся онлайн, они смогут это сделать через прямую синхронизацию из сети Portal.
Как это взаимодействует с другими частями дорожной карты?
Если мы хотим сделать запуск или работу узлов чрезвычайно простыми, то уменьшение требований к историческому хранилищу можно сказать более важно, чем безсостояние: из 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 работает на протяжении многих лет, включая такие предложения, как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "известных наименее плохих решений":
! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
Частичное истечение срока действия состояния
Некоторые предложения о истечении статуса следуют тем же принципам. Мы разделяем статус на блоки. Каждый навсегда сохраняет "верхнюю карту",