Прототип Ethereum, который распределяет задачи по восстановлению данных между узлами, показал снижение расчетных вычислительных затрат на восстановление в 11–18 раз в симуляциях с 1000 узлами. Результаты предполагают, что операторы могут сократить дублирование работы с помощью менее масштабных изменений, чем полная сетевая схема RowDAS.
В отчете исследователя Чабы Кирая от 3 сентября описывается сокращенный вариант дизайна как возможный первый шаг к RowDAS. Он назначает задачи восстановления без внедрения новых сетевых каналов строк, предусмотренных в полном предложении.
Блобы содержат данные, используемые решениями второго уровня (rollups). PeerDAS, система Ethereum для проверки доступности данных блобов, позволяет узлам загружать только часть данных. Узлы с высоким уровнем хранения (high-custody nodes) хранят как минимум 64 из 128 столбцов данных, что достаточно для восстановления недостающих данных блобов; суперузлы хранят все 128.
Многие узлы с высоким уровнем хранения могут повторять одно и то же восстановление. Сокращенный дизайн сначала назначает им определенные блобы, позволяя другим узлам получать восстановленные данные вместо немедленного самостоятельного восстановления.
Что показывают симуляции восстановления блобов в Ethereum
В одной конфигурации с четырьмя блобами, 10% суперузлов и без удержания столбцов, расчетная стоимость восстановления в сети снизилась с 48,6 секунд процессорного времени в модели PeerDAS до 2,75 секунд процессорного времени в сокращенном дизайне. При доле суперузлов в 20% соответствующие показатели составили 91 и 6,6 секунд процессорного времени.
Эти общие цифры описывают накопленную вычислительную работу по всей симулированной сети, а не фактическое время восстановления. Расчеты применяют измеренную стоимость в 162 миллисекунды на восстановление блоба на процессоре Ryzen 9 8945HS. Скорость транзакций и экономия на комиссиях не входили в отчетные измерения.
Базовая модель PeerDAS уже включает случайные задержки и проверки, которые подавляют дублирование восстановления. Поэтому сравнение учитывает работу, сэкономленную благодаря этим задержкам в существующем поведении клиентов.
В сокращенном варианте назначенные узлы обмениваются восстановленными ячейками через существующие каналы распределения столбцов. Узлы с высоким уровнем хранения сохраняют отложенную роль восстановления для всего, что еще отсутствует, сохраняя резервный механизм в стиле PeerDAS.
Полная версия RowDAS, указанная в черновике EIP-8371, добавит еще один маршрут восстановления: каналы строк позволят небольшим узлам объединять свои данные и совместно восстанавливать их, когда их совокупные данные превысят порог восстановления. Сокращенный дизайн сохраняет сегодняшнюю зависимость от узлов с высоким уровнем хранения и не может обеспечить дополнительную отказоустойчивость.
Измерения ограничены симулированными, внутренними сетями с использованием реальной криптографии. Кирай не сообщал о результатах devnet, а конфигурация полного дизайна с 128 строками подсети остается экстраполяцией из меньшего количества подсетей. Более масштабные симуляции и тесты в реальной сети еще впереди.
EIP-8371 не меняет лимиты блобов, и предложенное разделение между назначением задач и сетевым взаимодействием строк еще не включено в текст черновика. Непосредственная возможность более узкая: снижение процессорной нагрузки, необходимой для восстановления, при этом более широкие преимущества отказоустойчивости зависят от более позднего уровня строк.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
