Ethereum представляет план масштабирования. Чем он отличается от предыдущих?

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

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

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

Ниже приводится оригинал текста:

Теперь поговорим о масштабировании. В основном его можно разделить на две части: краткосрочное масштабирование и долгосрочное масштабирование.

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

Что касается краткосрочного масштабирования, я уже писал об этом в другом месте. Основная идея примерно такова:

· Списки доступа на уровне блоков (будут введены в обновлении Glamsterdam) могут обеспечить параллелизацию проверки блоков.

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

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

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

Например, в настоящее время: операция SSTORE стоит 5000 газа, если слот хранения изменяется с ненулевого → ненулевого; она стоит 20000 газа, если изменяется с нулевого → ненулевого.

В случае пересмотра цен на газ в Гламстердаме эти дополнительные расходы значительно увеличатся (например, до 60000). Цель этого заключается в повышении стоимости при одновременном значительном увеличении темпов расширения исполнительных возможностей по сравнению с темпами расширения размера штата.

Что касается причин, я уже писал об этом ранее: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Поэтому в Гламстердаме: Эта операция SSTORE потребляет 5000 «базового газа», т. е. 55000 «газа для создания состояния».

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

Это означает: Станет возможным создавать контракты большего объема, чем сейчас.

Как достигается многомерность газа в EVM?

Вот проблема: Конструкция EVM предполагает, что газ имеет только одно измерение; например, GAS, CALL и другие операционные коды основаны на этом предположении.

Наше решение заключается в поддержании двух инвариантов:

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

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

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

Логика выполнения EVM заключается в следующем:

По возможности отдавайте предпочтение газу из специализированных измерений.

Если этого недостаточно, потребляйте из резервуара.

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

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

В этом дизайне:

Операционный код GAS возвращает резервуар

CALL пропустит указанное количество газа из резервуара и весь газ, не находящийся в резервуаре.

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

Позже мы дополнительно представим многомерное ценообразование, позволяющее устанавливать разные плавающие цены на газ для разных ресурсов.

Это принесет:

Лучшая долгосрочная экономическая устойчивость

Оптимизированная эффективность распределения ресурсов

Подробнее см. на сайте: https://vitalik.eth.limo/general/2024/05/09/multidim.html

Механизм резервуара аккуратно решает проблему подвызова, упомянутую в конце этой статьи.

Долгосрочное масштабирование

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

Пятна

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

Эта шкала:

Достаточно для удовлетворения собственных потребностей Ethereum

И не предназначен для того, чтобы стать «глобальным уровнем данных».

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

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

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

PeerDAS + blobs позволяют проверять доступность данных без необходимости загрузки всех данных

ZK-EVM

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

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

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

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

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

См.: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[Ссылка на исходную статью]