Ethereum опубликовала дорожную карту масштабирования. Чем она отличается в этот раз?

Заголовок: Ethereum публикует дорожную карту масштабирования: чем она отличается в этот раз?

Автор оригинала: @VitalikButerin Перевод: Peggy

Источник оригинала:

Репост: Mars Finance

Редакторский комментарий: По мере расширения экосистемы Ethereum становится всё более важным реализовать масштабирование сети без ущерба для безопасности и децентрализации. В этой статье Виталик Бутерин подробно описывает путь расширения Ethereum: краткосрочные меры — оптимизация механизма Gas, параллелизация проверки блоков и другие технические улучшения для повышения эффективности выполнения, а долгосрочные — использование ZK-EVM и архитектуры данных blobs для увеличения масштабов сети.

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

Ниже — оригинальный текст:

Теперь поговорим о масштабировании (scaling). Здесь выделяют две части: краткосрочное и долгосрочное расширение.

Краткосрочное расширение

О краткосрочных мерах я уже писал в других местах. Основные идеи примерно такие:

· Блоковые списки доступа (block-level access lists) (будут внедрены в обновлении Glamsterdam) позволят реализовать параллельную проверку блоков.

· ePBS (также будет введён в Glamsterdam) обладает несколькими характеристиками, одна из которых — возможность безопасно использовать большую часть времени каждого слота для проверки блока, а не ограничиваться несколькими сотнями миллисекунд, как сейчас.

· Пересмотр цен на Gas (gas repricing) обеспечит соответствие стоимости операций в Gas их фактическому времени выполнения (и другим затратам). Мы также начали исследовать механизм многомерного Gas (multidimensional gas), позволяющего устанавливать отдельные лимиты для различных ресурсов. В совокупности эти меры позволят использовать больший процент времени слота для проверки блока, не опасаясь экстремальных ситуаций.

Что касается многомерного Gas, у нас есть поэтапный план. Первый этап — в обновлении Glamsterdam разделить «затраты на создание состояния» и «затраты на выполнение и calldata».

Например, сейчас: операция SSTORE, если менять значение в слоте с ненулевого на ненулевое, стоит 5000 gas; с нулевого на ненулевое — 20000 gas.

В обновлении Glamsterdam при пересмотре цен на Gas этот дополнительный расход будет значительно увеличен (например, до 60000). Цель — повысить лимит Gas, одновременно расширяя возможности выполнения быстрее, чем растёт размер состояния.

Объяснение уже было дано ранее:

Таким образом, в Glamsterdam операция SSTORE будет стоить 5000 «обычного gas», а также — например — 55000 «затрат на создание состояния».

Важно отметить: затраты на создание состояния не учитываются в лимите транзакций примерно в 16 миллионов Gas.

Это означает, что создание более крупных контрактов станет возможным.

Как реализовать многомерный Gas в EVM?

Здесь возникает вопрос: дизайн EVM предполагает один измеритель Gas, например, GAS, CALL и другие opcodes основаны на этом предположении.

Наше решение — сохранить два постоянных параметра:

Если вы инициируете вызов с X gas, то этот вызов получит X gas, который можно использовать для «обычных операций», «создания состояния» или других возможных будущих ресурсов.

Если opcode GAS возвращает Y gas, а вы инициируете вызов, потребляющий X gas, то после завершения вызова у вас останется минимум Y − X gas для дальнейших операций.

Конкретная реализация — введение N+1 измерений Gas. По умолчанию N=1 (создание состояния), дополнительное измерение называется reservoir (резервуар).

Логика выполнения EVM такова:

• В первую очередь расходуются ресурсы из специального измерения (reservoir).

• Если ресурсов недостаточно, — из reservoir.

Например, у вас есть: (100000 gas на создание состояния, 100000 reservoir).

Если вы создаёте три новых состояния с помощью SSTORE, то расход газа будет таким: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000).

При такой схеме:

Opcode GAS возвращает значение reservoir.

CALL передает указанное количество gas из reservoir, а также все остальные non-reservoir gas.

Многомерное ценообразование Gas

Далее мы планируем ввести ценообразование по нескольким измерениям (multi-dimensional pricing), чтобы разные ресурсы имели разные плавающие цены на Gas.

Это даст преимущества:

• лучшую долгосрочную экономическую устойчивость,

• более эффективное распределение ресурсов.

Подробности — в соответствующем материале.

Механизм reservoir как раз решает проблему суб-вызовов (sub-call), упомянутую в конце той статьи.

Долгосрочное расширение

Долгосрочные меры включают два направления: ZK-EVM и Blobs.

Blobs

Что касается blobs, мы планируем продолжать развитие PeerDAS, в конечном итоге достигая пропускной способности около 8 МБ/с.

Этот масштаб:

• полностью удовлетворит потребности Ethereum,

• не превратится в «глобальный слой данных».

На данный момент blobs в основном используются для L2. В будущем планируется, чтобы данные блоков Ethereum напрямую записывались в blobs.

Цель — позволить пользователям проверять расширенную сеть Ethereum без необходимости скачивать и переисполнять всю цепочку:

• ZK-SNARKs устраняют необходимость повторного исполнения,

• PeerDAS + blobs позволяют проверять доступность данных без скачивания всей информации.

ZK-EVM

Что касается ZK-EVM, наша цель — постепенно увеличивать зависимость сети от него.

2026 год: появятся клиенты, поддерживающие ZK-EVM, позволяющие узлам участвовать в аттестации с помощью ZK-EVM. Но они ещё недостаточно безопасны для полной зависимости всей сети. Однако, если около 5% сети будет их использовать, это допустимо. (Если возникнут проблемы с ZK-EVM, вас не лишат залога, но вы можете строить блоки на недействительных данных и потерять вознаграждение.)

2027 год: мы начнем рекомендовать большему числу узлов запуск ZK-EVM, сосредоточившись на формальной верификации и повышении безопасности. Даже при 20% использования ZK-EVM можно значительно увеличить лимит Gas, поскольку это даст возможность низкозатратной проверки для соло-стейкеров, которых сейчас менее 20%.

После достижения технической зрелости: мы введем механизм 3 из 5 — блок должен содержать как минимум 3 доказательства из 5 различных систем, чтобы считаться валидным. Тогда большинство узлов, кроме индексных, будут полагаться на ZK-EVM.

Долгосрочно: продолжать совершенствовать ZK-EVM, делая его более устойчивым и проходящим строгую формальную проверку. На этом этапе возможны изменения на уровне виртуальной машины, например, в направлении RISC-V.

Подробности — в соответствующем материале.