Протокол Эфириума проходит через самое значительное обновление масштабирования с момента внедрения транзакций с блобами в EIP-4844. В рамках обновления Фусака PeerDAS представляет новый способ обработки данных блобов, обеспечивая примерно на порядок большую пропускную способность доступности данных (DA) для l2.
Подробнее о дорожной карте масштабирования блобов (opens in a new tab)
Масштабируемость
Видение Эфириума заключается в том, чтобы быть нейтральной, безопасной и децентрализованной платформой, доступной для каждого в мире. По мере роста использования сети это требует балансировки трилеммы масштабируемости, безопасности и децентрализации сети. Если бы Эфириум просто увеличил объем данных, обрабатываемых сетью в рамках ее текущего дизайна, он бы подвергся риску перегрузки узлов, на которые Эфириум опирается для своей децентрализации. Масштабируемость требует строгой разработки механизмов, минимизирующей компромиссы.
Одной из стратегий достижения этой цели является создание разнообразной экосистемы решений для масштабирования уровня 2, а не обработка всех транзакций в Мейннете . или роллапы обрабатывают транзакции в своих собственных отдельных цепях и используют Эфириум для верификации и безопасности. Публикация только критически важных для безопасности коммитментов и сжатие полезной нагрузки позволяет l2 более эффективно использовать пропускную способность DA Эфириума. В свою очередь, l1 несет меньше данных без ущерба для гарантий безопасности, в то время как l2 привлекают больше пользователей при более низких затратах на газ. Изначально l2 публиковали данные как calldata в обычных транзакциях, которые конкурировали с транзакциями l1 за газ и были непрактичны для массовой доступности данных.
Прото-данкшардинг
Первым крупным шагом к масштабированию l2 стало обновление Dencun, которое внедрило прото-данкшардинг (EIP-4844). Это обновление создало новый специализированный тип данных для роллапов, называемый блобами. Блобы (binary large objects) — это эфемерные фрагменты произвольных данных, которые не требуют выполнения в EVM и хранятся узлами только в течение ограниченного времени. Эта более эффективная обработка позволила l2 публиковать больше данных в Эфириуме и масштабироваться еще дальше.
Несмотря на то, что использование блобов уже имеет значительные преимущества для масштабирования, это лишь часть конечной цели. В текущем протоколе каждому узлу в сети по-прежнему необходимо загружать каждый блоб. Узким местом становится пропускная способность, требуемая от отдельных узлов, при этом объем данных, которые необходимо загрузить, напрямую увеличивается с ростом количества блобов.
Эфириум не идет на компромиссы в отношении децентрализации, и пропускная способность является одним из самых чувствительных параметров. Даже при наличии мощных вычислительных ресурсов, широко доступных любому, кто может себе это позволить, ограничения пропускной способности исходящего канала (opens in a new tab) даже в крупных городах развитых стран (таких как Германия (opens in a new tab), Бельгия (opens in a new tab), Австралия (opens in a new tab) или США (opens in a new tab)) могут привести к тому, что узлы смогут работать только из центров обработки данных, если требования к пропускной способности не будут тщательно настроены.
Операторы узлов сталкиваются со все более высокими требованиями к пропускной способности и дисковому пространству по мере увеличения количества блобов. Размер и количество блобов ограничены этими рамками. Каждый блоб может содержать до 128 КБ данных, в среднем 6 блобов на блок. Это был лишь первый шаг к будущему дизайну, который использует блобы еще более эффективным образом.
Выборка доступности данных
Доступность данных — это гарантия того, что все данные, необходимые для независимой валидации цепи, доступны всем участникам сети. Это гарантирует, что данные были полностью опубликованы и могут быть использованы для надежной проверки нового состояния цепи или входящих транзакций.
Блобы Эфириума обеспечивают надежную гарантию доступности данных, которая обеспечивает безопасность l2. Для этого узлам Эфириума необходимо загружать и хранить блобы целиком. Но что, если мы сможем распределять блобы в сети более эффективно и избежать этого ограничения?
Другой подход к хранению данных и обеспечению их доступности — это выборка доступности данных (Data Availability Sampling, DAS). Вместо того чтобы каждый компьютер, на котором работает Эфириум, полностью хранил каждый отдельный блоб, DAS вводит децентрализованное разделение труда. Это снижает нагрузку по обработке данных за счет распределения небольших, управляемых задач по всей сети узлов. Блобы делятся на части, и каждый узел загружает только несколько частей, используя механизм равномерного случайного распределения по всем узлам.
Это создает новую проблему — доказательство доступности и целостности данных. Как сеть может гарантировать, что данные доступны и все они верны, когда отдельные узлы хранят только небольшие фрагменты? Злонамеренный узел может предоставить поддельные данные и легко нарушить строгие гарантии доступности данных! Здесь на помощь приходит криптография.
Для обеспечения целостности данных EIP-4844 уже был реализован с коммитментами KZG. Это криптографические доказательства, создаваемые при добавлении нового блоба в сеть. Небольшое доказательство включается в каждый блок, и узлы могут проверить, что полученные блобы соответствуют коммитменту KZG блока.
DAS — это механизм, который строится поверх этого и гарантирует, что данные верны и доступны. Выборка — это процесс, при котором узел запрашивает только небольшую часть данных и проверяет ее на соответствие коммитменту. KZG — это схема полиномиальных коммитментов, что означает, что любая отдельная точка на полиномиальной кривой может быть проверена. Проверяя всего пару точек на полиноме, клиент, выполняющий выборку, может получить надежную вероятностную гарантию доступности данных.
PeerDAS
PeerDAS (EIP-7594) (opens in a new tab) — это конкретное предложение, которое реализует механизм DAS в Эфириуме, знаменуя собой, вероятно, самое большое обновление со времен Слияния. PeerDAS предназначен для расширения данных блобов, разделяя их на столбцы и распределяя подмножество между узлами.
Эфириум заимствует умную математику для достижения этой цели: он применяет стирающее кодирование в стиле Рида-Соломона к данным блобов. Данные блобов представляются в виде полинома, коэффициенты которого кодируют данные, затем этот полином вычисляется в дополнительных точках для создания расширенного блоба, удваивая количество вычислений. Эта добавленная избыточность позволяет восстанавливать стертые данные: даже если некоторые вычисления отсутствуют, исходный блоб может быть восстановлен до тех пор, пока доступна хотя бы половина всех данных, включая расширенные части.
В реальности этот полином имеет тысячи коэффициентов. Коммитменты KZG — это значения в несколько байт, что-то вроде хеша, известные всем узлам. Каждый узел, хранящий достаточное количество точек данных, может эффективно восстановить полный набор данных блоба (opens in a new tab).
Интересный факт: та же техника кодирования использовалась в DVD. Если вы поцарапали DVD, плеер все равно мог его прочитать благодаря кодированию Рида-Соломона, которое добавляет недостающие части полинома.
Исторически данные в блокчейнах, будь то блоки или блобы, транслировались всем узлам. С подходом PeerDAS к разделению и выборке транслировать все всем больше не нужно. После обновления Фусака сеть уровня консенсуса организуется в темы/подсети протокола сплетен: столбцы блобов назначаются определенным подсетям, и каждый узел подписывается на заранее определенные подмножества и хранит только эти части.
С PeerDAS расширенные данные блобов делятся на 128 частей, называемых столбцами. Данные распределяются по этим узлам через выделенный протокол сплетен в определенных подсетях, на которые они подписаны. Каждый обычный узел в сети участвует как минимум в 8 случайно выбранных подсетях столбцов. Получение данных только из 8 из 128 подсетей означает, что этот узел по умолчанию получает только 1/16 всех данных, но поскольку данные были расширены, это составляет 1/8 от исходных данных.
Это обеспечивает новый теоретический предел масштабирования, в 8 раз превышающий текущую схему «каждый загружает всё». Поскольку узлы подписываются на различные случайные подсети, обслуживающие столбцы блобов, вероятность того, что они равномерно распределены, очень высока, и, следовательно, каждая часть данных существует где-то в сети. Узлы, на которых работают валидаторы, обязаны подписываться на большее количество подсетей с каждым запускаемым ими валидатором.
Каждый узел имеет уникальный случайно сгенерированный ID, который обычно служит его публичным идентификатором для подключений. В PeerDAS это число используется для определения случайного набора подсетей, на которые он должен подписаться, что приводит к равномерному случайному распределению всех данных блобов.
Как только узел успешно восстанавливает исходные данные, он затем перераспределяет восстановленные столбцы обратно в сеть, активно устраняя любые пробелы в данных и повышая общую отказоустойчивость системы. Узлы, подключенные к валидаторам с совокупным балансом ≥4096 ETH, должны быть суперузлами и, следовательно, должны подписываться на все подсети столбцов данных и хранить все столбцы. Эти суперузлы будут постоянно устранять пробелы в данных. Вероятностная самовосстанавливающаяся природа протокола обеспечивает надежные гарантии доступности, не ограничивая при этом домашних операторов, хранящих только части данных.
Доступность данных может быть подтверждена любым узлом, хранящим лишь небольшое подмножество данных блоба, благодаря механизму выборки, описанному выше. Эта доступность является обязательной: валидаторы должны следовать новым правилам выбора форка, что означает, что они будут принимать блоки и голосовать за них только после того, как проверят доступность данных.
Прямое влияние на пользователей (особенно пользователей l2) — это снижение комиссий. Благодаря увеличению пространства для данных роллапов в 8 раз, операции пользователей в их цепи со временем становятся еще дешевле. Но снижение комиссий после обновления Фусака потребует времени и будет зависеть от BPO.
Blob-Parameter-Only (BPO)
Теоретически сеть сможет обрабатывать в 8 раз больше блобов, но увеличение количества блобов — это изменение, которое необходимо должным образом протестировать и безопасно выполнить поэтапно. Тестовые сети обеспечивают достаточную уверенность для развертывания функций в Мейннете, но нам необходимо обеспечить стабильность p2p-сети, прежде чем включать значительно большее количество блобов.
Чтобы постепенно увеличивать целевое количество блобов на блок без перегрузки сети, Фусака вводит форки Blob-Parameter-Only (BPO) (opens in a new tab). В отличие от обычных форков, которые требуют широкой координации экосистемы, согласия и обновлений программного обеспечения, BPO (EIP-7892) (opens in a new tab) — это заранее запрограммированные обновления, которые со временем увеличивают максимальное количество блобов без вмешательства.
Это означает, что сразу после активации обновления Фусака и запуска PeerDAS количество блобов останется неизменным. Количество блобов начнет удваиваться каждые несколько недель, пока не достигнет максимума в 48, в то время как разработчики будут следить за тем, чтобы механизм работал должным образом и не оказывал негативного влияния на узлы, поддерживающие работу сети.
Будущие направления
PeerDAS — это лишь шаг к более масштабному видению масштабирования FullDAS (opens in a new tab) или данкшардинга. В то время как PeerDAS использует одномерное (1D) стирающее кодирование для каждого блоба в отдельности, полный данкшардинг будет использовать более совершенную схему двумерного (2D) стирающего кодирования для всей матрицы данных блобов. Расширение данных в двух измерениях создает еще более сильные свойства избыточности и более эффективное восстановление и верификацию. Реализация FullDAS потребует существенных оптимизаций сети и протокола, а также дополнительных исследований.
Дополнительная литература
- PeerDAS: Выборка доступности данных узлами (Peer Data Availability sampling), Франческо Д'Амато (opens in a new tab)
- Документация по PeerDAS Эфириума (opens in a new tab)
- Доказательство безопасности PeerDAS без AGM (opens in a new tab)
- Виталик о PeerDAS, его влиянии и тестировании обновления Фусака (opens in a new tab)
Последнее обновление страницы: 6 июня 2026 г.

