Ethereum [ $ETH ] пересматривает свой подход к масштабированию, поскольку растущий объём сетевых данных делает запуск полного узла всё более ресурсоёмким. По мере увеличения количества аккаунтов и смарт-контрактов полным исполнительным узлам сейчас требуется примерно от 0,9 до 1,3 ТБ дискового пространства. При этом базовый прирост состояния может достигать около 100 ГБ в год, а значит, рост пропускной способности способен ещё больше усложнить работу узлов.

Именно эта проблема объясняет, почему Виталик Бутерин из Ethereum смотрит дальше простого увеличения числа обрабатываемых транзакций — в сторону сокращения объёма данных, которые узлы обязаны хранить. В публикации на X он отдал должное разработчикам Bitcoin за создание Utreexo — системы, позволяющей узлам хранить значительно меньше данных, — и отметил, что предложения по масштабированию Ethereum сейчас изучают схожие идеи. Название Utreexo происходит от модели UTXO (unspent transaction output — непотраченный выход транзакции) из Bitcoin, в которой балансы существуют в виде отдельных тратуемых выходов, а не записей на аккаунтах. Вместо хранения полного набора UTXO на диске узел Utreexo держит лишь небольшой хеш-аккумулятор, организованный в виде леса деревьев Меркла, а каждая транзакция содержит доказательства, позволяющие узлу убедиться, что её входы действительно не потрачены.

Проще говоря, Бутерин хочет, чтобы Ethereum допускал несколько способов управления состоянием узлов, поскольку это уменьшает объём данных, которые узлам приходится хранить. Решение проблемы роста состояния позволило бы Ethereum масштабироваться без роста издержек на децентрализацию по мере масштабирования — именно от этого баланса теперь зависит долгосрочный путь масштабируемости сети. Такой баланс формировал исследования Ethereum на протяжении многих лет: ранние предложения о «плате за состояние» (state rent) были отложены в пользу работ над концепцией statelessness, а дорожная карта отдельно решает вопрос хранения данных через EIP-4444, который ограничивает объём исторических данных блоков, обязанных храниться исполнительными клиентами.

Ethereum стремится к более лёгкому хранению данных

Предлагаемое изменение важно, поскольку примерно 80–82% данных, хранящихся в Ethereum, создаётся в виде новых постоянных записей — против 14% на аккаунты и 4% на код контрактов. Каждому полному узлу придётся хранить всё больше информации, чтобы следовать за сетью. По мере роста балансов токенов и других типов записей подход в стиле UTXO может предложить альтернативный способ обработки платежей, не добавляющий больших объёмов постоянных записей.

По оценкам, если бы Ethereum применил подход в стиле UTXO для целевых платежей, требования к хранению данных на узлах снизились бы почти на 99,8%. Проще говоря, это означает, что по мере совершения транзакций Ethereum потенциально мог бы увидеть рост транзакционной активности без пропорционального увеличения объёмов хранения. Кроме того, Ethereum мог бы по-прежнему использовать текущий метод хранения постоянных сложных данных для приложений, которым это необходимо.

Такая более лёгкая модель хранения может оказаться практичнее, если учесть, как мало хранящейся в Ethereum информации используется регулярно: менее 4% записей аккаунтов и хранилищ затрагивается в течение 30 дней. Обычно база данных UTXO занимает примерно 11–11,5 ГБ, тогда как Utreexo сокращает локально хранимую информацию до менее чем 1 КБ. Компромисс заключается в дополнительных данных доказательств при верификации.

Для Ethereum схожий баланс позволил бы держать часто используемую информацию в быстром доступе, перемещая неактивные записи в другое место, — это снизило бы нагрузку на хранилища узлов без удаления исторической информации.

Итог

Сейчас Ethereum исследует более лёгкое хранение данных, чтобы масштабироваться с сохранением децентрализации, а Utreexo демонстрирует, как сеть могла бы сократить объём хранения на узлах без ограничения функциональности. Любое подобное изменение пройдёт через процедуру предложений по улучшению (EIP) и хардфорков Ethereum, поэтому это скорее направление исследований, за которым стоит следить, чем ближайшее изменение протокола.

Источник: AMBCrypto