Виталик Бутерин о путях развития Ethereum
Виталик Бутерин опубликовал новый пост, посвященный грядущим и возможным изменениям в Ethereum. Его ключевой вопрос можно сформулировать так: стоит ли внедрять новые функции в сам протокол (“enshrinement”) или строить их поверх него? Вот хороший TL;DR поста для тех, кому не хочется читать 40 тысяч знаков ↓
Минимализм vs. Расширение возможностей
Ранние дни: Изначально Ethereum строился как минималистичное ядро, уже поверх которого наслаиваются функциональные возможности. Однако в последнее время растет интерес к расширению количества функций в самом ядре.
Скоуп дискуссии: Хотя многие считают, что дебаты вокруг L1 и L2 в первую очередь связаны с масштабированием, они также касаются различных потребностей пользователей: обмен активами, конфиденциальность, расширенная криптография и т.д.
Ранняя философия протокольного минимализма
Видение: Ethereum 2.0 стремится к созданию чистого и простого протокола, позволяющего пользователям добавлять функциональные возможности.
Функция state transition: В идеале это должен быть просто вызов виртуальной машины. Однако стремление сделать транзакции «просто вызовом» привело к осложнениям.
Эволюция абстракции аккаунтов
❯ EIP-86: Ранний пропоузал по упрощению транзакций. Однако он перемещал сложность из EVM в другие части стека Ethereum.
❯ EIP-2938: Более работоспособное решение, хотя оно не было минималистичным и требовало введения ряда новых фич.
❯ ERC-4337: Разработан таким образом, чтобы не затрагивать сам протокол Ethereum и не требовать хард форка. Тем не менее, он рассматривается для внедрения в протокол из-за ряда проблем:
- Газоэффективность: Перемещение функций в протокол позволяет снизить затраты на газ.
- Риск багов в коде: Внедрённая функция может быть хардфоркнута для исправления ошибок, что позволяет сохранить средства пользователей.
- Поддержка опкодов EVM: Нативная абстракция аккаунтов может улучшить функциональность опкодов.
- Цензуроустойчивость: Внедрение может повысить устойчивость к цензуре.
Внедрение zkEVM
❯ Цель: Интегрировать zkEVM непосредственно в протокол Ethereum.
❯ Текущий сценарий: Существует множество ZK-роллапов, которые проверяют исполнение блоков внутри ZK-SNARK.
❯ Проблема: Существующие системы используют для борьбы с ошибками механизм «совета безопасности» (Security Councils).
❯ Предложение: Стандартизировать проверку выполнения EVM в ZK в качестве функции протокола, используя социальный консенсус Ethereum для апгрейдов и устранения ошибок.
❯ Осложнения: Обеспечение совместимости, ускорение времени доказательства и решение проблемы разделения на stateful и stateless.
Внедрение разделения между пропоузерами и билдерами блоков
❯ Предыстория: Из-за MEV производство блоков требует больших затрат и сильно зависит от масштаба.
❯ Текущее решение: Внепротокольное разделение пропоузеров-билдеров (MEV-Boost).
❯ Предложение: «Внедрённая PBS», которая непосредственно встраивается в протокол, обеспечивая более высокую безопасность.
Внедрение частных мемпулов
❯ Проблема: Транзакции становятся публичными до включения в цепочку, что делает пользователей уязвимыми для фронтраннинга.
❯ Решение: Создать приватные мемпулы, которые шифруют транзакции до момента их включения в блок.
❯ Задачи: Поиск метода шифрования, который был бы одновременно безопасным и эффективным для L1 Ethereum.
Внедрение ливкидного стейкинга
❯ Спрос: Пользователи хотят стейкать ETH без сложностей и иметь двойную функциональность (стейкинг + использование в качестве залога).
❯ Решение: Провайдеры ликвидного стейкинга, такие как Lido и Rocketpool.
❯ Риск: Доминирование одного провайдера может привести к централизации.
❯ Возможный вариант: Функциональность ликвидного стейкинга внутри протокола для снижения централизации.
Внедрение большего количества прекомпайлов
❯ Что такое прекомпайлы (precompiles)? Это контракты Ethereum, выполняющие сложные криптографические операции.
❯ Текущий сценарий: Несколько специфических хэш-функций и операции с эллиптическими кривыми.
❯ Предложение: Добавить больше прекомпайлов для таких операций, как secp256r1, BLS-12-377 и т.д.
❯ Контраргумент: Предыдущие прекомпайлы используются недостаточно. Стоит рассмотреть более универсальные решения, такие как EVM-MAX или SIMD.
Основные выводы
- Последствия внедрения: Хотя минимизация внутрипротокольных функций желательна, блокчейн — это социальная система, требующая осторожного внедрения некоторых из них.
- Риски централизации и сложности: Внедрение определенных функций может предотвратить централизацию в других областях, но усложнить протокол.
- Потребности пользователей динамичны: Кажущиеся приоритетными функции могут оказаться недостаточно востребованными.
- Минимально жизнеспособное внедрение: Вместо того чтобы полностью интегрировать функции, протокол может внедрить их ключевые компоненты для облегчения реализации.
- Изъятие (де-внедрение): Некоторые функции могут быть удалены для повышения эффективности, например, малоиспользуемые прекомпайлы.
- Будущее направление: Баланс между внутрипротокольными и внепротокольными возможностями будет постоянно меняться и требовать постоянной переоценки.