Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух аспектах:
Исторические данные: любые транзакции, проведенные и любые аккаунты, созданные в любой момент в прошлом, должны быть постоянно хранимы всеми клиентами и загружены любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепи останется неизменной.
Функции протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать мощное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но в то же время нам нужно сохранить одно из ключевых свойств, которые делают блокчейн великим: долговечность. Вы можете поместить NFT, любовное письмо в данных транзакции или смарт-контракт на сумму 1 миллион долларов в цепочку, войти в пещеру на десять лет, а затем выйти и обнаружить, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли с уверенностью полностью децентрализоваться и удалить ключи для обновления, им нужно быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно L1.
Если мы решим добиться баланса между этими двумя потребностями и одновременно минимизировать или предотвратить чрезмерность, сложность и упадок, это абсолютно возможно. Биологические организмы могут это сделать: хотя большинство организмов стареют с течением времени, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в значительной степени исчезла, узлы Beacon Chain хранили данные старше шести месяцев. Найти этот путь для 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.
Распределенное хранение и извлечение объектов SSZ в Portal
Как увеличить лимит газа (Paradigm)
Что еще нужно сделать, что нужно учесть?
Основная работа, которая осталась, включает в себя построение и интеграцию конкретного распределенного решения для хранения истории — по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самым простым решением является (i) простое внедрение существующей библиотеки торрентов, а также (ii) решения на базе Эфир, называемого сетью Portal. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. EIP-4444 сам по себе не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл включить его одновременно для всех клиентов, иначе существует риск, что клиенты выйдут из строя из-за ожидания загрузки полной истории, подключаясь к другим узлам, но на самом деле не получая её.
Основные компромиссы связаны с тем, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные поставщики для копирования. Это легко, но это ослабляет Эфир как место для постоянной записи. Более сложный, но более безопасный подход — сначала создать и интегрировать torrent-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубоко мы интегрируем хранилище истории в протокол?
Экстремальный параноидальный подход к (1) будет заключаться в доказательстве хранения: фактически требуя от каждого валидатора на основе доли хранить определенный процент исторических данных и регулярно проверять их на наличие этого в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента исторических данных, хранящихся каждым клиентом.
Что касается (, базовая реализация охватывает только ту работу, которая была завершена сегодня: Портал уже сохранил ERA файл, содержащий всю историю Эфира. Более полная реализация будет заключаться в фактическом подключении к процессу синхронизации, так что если кто-то захочет синхронизировать узел хранения полной истории или архивный узел, даже если другие архивные узлы не находятся в сети, они смогут сделать это через прямую синхронизацию с портальной сетью.
) Как это взаимодействует с другими частями дорожной карты?
Если мы хотим сделать запуск или работу узлов чрезвычайно простым, то снижение требований к историческому хранилищу можно сказать важнее, чем безсостояние: из 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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
6
Поделиться
комментарий
0/400
OnchainGossiper
· 07-27 20:51
Клиент синхронизируется так медленно, что я хочу блевануть.
Посмотреть ОригиналОтветить0
MidnightSnapHunter
· 07-26 22:22
Виталик Бутерин наконец-то собирается ликвидироваться?
Посмотреть ОригиналОтветить0
PriceOracleFairy
· 07-24 21:24
ngl Протокол бloat реальный... проблемы масштабирования не дают мне спать в 3 утра fr
Посмотреть ОригиналОтветить0
WhaleWatcher
· 07-24 21:14
Виталик Бутерин, помоги мне рассчитать стоимость хранения.
Виталик говорит о The Purge: путь долгосрочной устойчивости Ethereum
Виталик: возможное будущее Ethereum, The Purge
Одной из проблем, с которой сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух аспектах:
Исторические данные: любые транзакции, проведенные и любые аккаунты, созданные в любой момент в прошлом, должны быть постоянно хранимы всеми клиентами и загружены любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к увеличению нагрузки на клиентов и времени синхронизации с течением времени, даже если емкость цепи останется неизменной.
Функции протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода со временем.
Чтобы Ethereum мог долго существовать, нам необходимо оказать мощное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но в то же время нам нужно сохранить одно из ключевых свойств, которые делают блокчейн великим: долговечность. Вы можете поместить NFT, любовное письмо в данных транзакции или смарт-контракт на сумму 1 миллион долларов в цепочку, войти в пещеру на десять лет, а затем выйти и обнаружить, что оно все еще ждет вас для чтения и взаимодействия. Чтобы DApp могли с уверенностью полностью децентрализоваться и удалить ключи для обновления, им нужно быть уверенными, что их зависимости не будут обновляться разрушительным для них образом - особенно L1.
Если мы решим добиться баланса между этими двумя потребностями и одновременно минимизировать или предотвратить чрезмерность, сложность и упадок, это абсолютно возможно. Биологические организмы могут это сделать: хотя большинство организмов стареют с течением времени, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в значительной степени исчезла, узлы Beacon Chain хранили данные старше шести месяцев. Найти этот путь для 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.
! Виталик: Возможное будущее Ethereum, Чистка
с какими существующими исследованиями связана?
Что еще нужно сделать, что нужно учесть?
Основная работа, которая осталась, включает в себя построение и интеграцию конкретного распределенного решения для хранения истории — по крайней мере, истории выполнения, но в конечном итоге также включая консенсус и blob. Самым простым решением является (i) простое внедрение существующей библиотеки торрентов, а также (ii) решения на базе Эфир, называемого сетью Portal. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. EIP-4444 сам по себе не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл включить его одновременно для всех клиентов, иначе существует риск, что клиенты выйдут из строя из-за ожидания загрузки полной истории, подключаясь к другим узлам, но на самом деле не получая её.
Основные компромиссы связаны с тем, как мы стараемся предоставить "древние" исторические данные. Самое простое решение — остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные поставщики для копирования. Это легко, но это ослабляет Эфир как место для постоянной записи. Более сложный, но более безопасный подход — сначала создать и интегрировать torrent-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы стремимся гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубоко мы интегрируем хранилище истории в протокол?
Экстремальный параноидальный подход к (1) будет заключаться в доказательстве хранения: фактически требуя от каждого валидатора на основе доли хранить определенный процент исторических данных и регулярно проверять их на наличие этого в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процента исторических данных, хранящихся каждым клиентом.
Что касается (, базовая реализация охватывает только ту работу, которая была завершена сегодня: Портал уже сохранил ERA файл, содержащий всю историю Эфира. Более полная реализация будет заключаться в фактическом подключении к процессу синхронизации, так что если кто-то захочет синхронизировать узел хранения полной истории или архивный узел, даже если другие архивные узлы не находятся в сети, они смогут сделать это через прямую синхронизацию с портальной сетью.
) Как это взаимодействует с другими частями дорожной карты?
Если мы хотим сделать запуск или работу узлов чрезвычайно простым, то снижение требований к историческому хранилищу можно сказать важнее, чем безсостояние: из 1,1 ТБ, необходимых узлу, около 300 ГБ — это состояние, а оставшиеся около 800 ГБ стали историей. Только достигнув безсостояния и EIP-4444, можно реализовать видение запуска узла Ethereum на смарт-часах и настройки всего за несколько минут.
Ограничение истории хранения также делает более осуществимым создание новых узлов Ethereum, которые поддерживают только последнюю версию протокола, что упрощает их. Например, теперь можно безопасно удалить многие строки кода, поскольку все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством работы.
! [Виталик: Возможное будущее Ethereum, Чистка]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(
Срок действия состояния
) Что решает?
Даже если мы устраним необходимость в хранении истории клиентом, потребность в хранении клиентом будет продолжать расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: балансы счетов и случайные числа, коды контрактов и хранилища контрактов. Пользователи могут оплатить единовременный сбор, тем самым навсегда возложив бремя на нынешних и будущих клиентов Ethereum.
Состояние сложнее "исторического" срока действия, потому что EVM изначально проектировался на основе предположения, что как только объект состояния создан, он всегда будет существовать и может быть прочитан в любой момент любой транзакцией. Если мы введем бессостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, а все другие узлы (даже включая генерацию списков!) могут работать без состояния. Тем не менее, существует мнение, что мы не хотим слишком полагаться на бессостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы поддерживать децентрализованность Ethereum.
Что это такое и как это работает?
Сегодня, когда вы создаете новый объект состояния (это может произойти одним из трех способов: (i) отправив ETH на новый аккаунт, (ii) создав новый аккаунт с помощью кода, (iii) установив ранее неиспользуемый слот хранилища), этот объект состояния остается в этом состоянии навсегда. Напротив, мы хотим, чтобы объект автоматически устаревал с течением времени. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большого количества дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователя: если кто-то уйдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружелюбие к разработчикам: разработчикам не нужно переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально работать.
Неудовлетворение этих целей может легко решить проблему. Например, вы можете заставить каждый объект состояния также хранить счетчик срока действия (который можно продлить за счет сжигания ETH, что может произойти автоматически в любое время при чтении или записи), и есть цикл, который проходит по состояниям, чтобы удалить объекты состояния с истекшим сроком действия. Однако это вводит дополнительные вычисления (даже требования к хранению), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также трудно рассуждать о крайних случаях, когда значения хранения иногда сбрасываются на ноль. Если вы установите таймер истечения в пределах контракта, это технически упростит жизнь разработчиков, но усложнит экономику: разработчики должны учитывать, как "перенести" постоянные затраты на хранение на пользователя.
Эти проблемы являются теми, над которыми ядро разработчиков Ethereum трудится на протяжении многих лет, включая такие предложения, как "аренда блокчейна" и "восстановление". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
Частичное истечение срока действия состояния
Некоторые предложения по истечению срока действия статусов следуют одним и тем же принципам. Мы делим статусы на блоки. Каждый навсегда хранит "верхнюю карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только если они были недавно доступны. Существует механизм "воскрешения", если данные больше не хранятся.
Главное различие между этими предложениями заключается в следующем: (i) как мы определяем "недавно", и (ii) я