Переходим к масштабированию.
Существуют два направления: краткосрочное и долгосрочное.
О краткосрочном масштабировании я писал ранее. Кратко:
Списки доступа на уровне блоков (ожидаются в Glamsterdam) позволят параллельно проверять блоки.
ePBS (ожидается в Glamsterdam) реализует множество функций; одна из них — возможность безопасно использовать большую часть слота (а не только несколько сотен миллисекунд) для проверки блока.
Пересчет стоимости газа обеспечивает соответствие затрат газа реальному времени выполнения операций и другим сопутствующим расходам. Мы также начинаем внедрять многомерный газ, который позволяет ограничивать разные ресурсы по отдельности. Оба механизма дают возможность использовать большую часть слота для проверки блоков без риска исключительных ситуаций.
Многомерный газ реализуется по многоэтапной дорожной карте.
Первым шагом в Glamsterdam станет разделение расходов на “создание состояния” и “исполнение и calldata”. Сейчас SSTORE, который изменяет слот с ненулевого на ненулевой, стоит 5 000 газа; если изменяет с нулевого на ненулевой — 20 000. В Glamsterdam дополнительная стоимость увеличится существенно (например, до 60 000); наша задача — с помощью этого изменения и роста лимита газа масштабировать вычислительные мощности значительно больше, чем емкость состояния, по причинам, которые я уже описывал (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). Таким образом, в Glamsterdam SSTORE будет взимать 5 000 “обычного” газа и, например, 55 000 “газа создания состояния”.
Газ создания состояния не будет учитываться в лимите газа транзакций (~16 миллионов), поэтому появится возможность создавать более крупные контракты.
Вопрос: как это реализовать в EVM? Опкоды EVM (GAS, CALL и др.) рассчитаны на одну размерность. Наш подход: мы поддерживаем два инварианта:
Если функция вызывается с X газом, этот вызов получит X газа, пригодного для “обычного”, “создания состояния” или других будущих размерностей
Если вы вызываете опкод GAS, он показывает Y газа; после вызова функции с X газом у вас остается минимум Y-X газа, пригодного для любых операций после вызова
Мы создаём N+1 “размерность” газа: по умолчанию N=1 (“создание состояния”), дополнительная — “резервуар”. По умолчанию выполнение в EVM расходует специализированные размерности, если возможно, иначе — резервуар. Например, если у вас (100 000 газа создания состояния, 100 000 резервуара), то при трёх использованиях SSTORE для создания нового состояния остатки газа будут: (100 000, 100 000) → (45 000, 95 000) → (0, 80 000) → (0, 20 000). GAS возвращает резервуар. CALL передаёт указанное количество газа из резервуара плюс весь не-резервуарный газ.
В дальнейшем мы перейдём к многомерному ценообразованию, где разные размерности будут иметь разные плавающие цены газа. Это обеспечит долгосрочную экономическую устойчивость и оптимальность (см.
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). Механизм резервуара решает проблему подзапросов, описанную в конце той статьи.
Долгосрочное масштабирование состоит из двух частей: ZK-EVM и blobs.
Для blobs планируется дальнейшее развитие PeerDAS с целью довести его до состояния, в котором он сможет обрабатывать ~8 МБ/сек данных. Этого достаточно для нужд Ethereum, без попытки стать глобальным слоем данных. Сегодня blobs используются для L2, а в будущем данные блоков Ethereum будут напрямую попадать в blobs. Это необходимо, чтобы можно было проверить гипермасштабированную цепочку Ethereum без личной загрузки и повторного исполнения: ZK-SNARKs избавляют от повторного исполнения, PeerDAS на blobs позволяет проверить доступность данных без личной загрузки.
Для ZK-EVM задача — поэтапно повысить уровень доверия к нему:
Клиенты, позволяющие участвовать в качестве аттестатора с ZK-EVM, появятся в 2026 году. Они пока недостаточно безопасны для работы всей сети, но, например, 5% сети смогут использовать их. (Если ZK-EVM сломается, штрафа не будет, просто есть риск построить блок на неверной основе и потерять доход)
В 2027 году мы начнем рекомендовать большему меньшинству сети использовать ZK-EVM, одновременно полностью сосредоточившись на формальной верификации и максимизации безопасности. Даже 20% сети, работающей на ZK-EVM, позволит значительно увеличить лимит газа, поскольку это даст дешевый путь для одиночных стейкеров, которых и так менее 20%.
Когда система будет готова, перейдём к обязательному доказательству 3 из 5: для валидности блока потребуется 3 из 5 типов доказательств из разных систем. К этому моменту ожидается, что все узлы (кроме тех, кому нужен индекс) будут полагаться на доказательства ZK-EVM.
Продолжать совершенствовать ZK-EVM, сделать его максимально надежным и формально проверенным. Это затронет и любые изменения VM (например, RISC-V).
Отказ от ответственности:
- Данная статья перепечатана с [vitalikbuterin]. Все авторские права принадлежат оригинальному автору [vitalikbuterin]. Если у вас есть возражения против перепечатки, пожалуйста, обратитесь к команде Gate Learn, и они оперативно рассмотрят ваш запрос.
- Отказ от ответственности: Мнения и взгляды, изложенные в статье, принадлежат исключительно автору и не являются инвестиционными рекомендациями.
- Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведённых материалов запрещены.
