👾 Виталик Бутерин про долгосрочное будущее протокола Ethereum
В этом году речь Виталика на EthCC касалась долгосрочного будущего протокола Ethereum. Он решил рассмотреть не экосистему, а конкретно блокчейн и его инфраструктуру — консенсус. Собрали в конспект основные тезисы выступления Виталика, а также сделали озвучку на русском языке к видео.
Этапы роадмапа Ethereum
Как мы видим эти аспекты нашего протокола через 10 лет? Сейчас протокол находится в середине длительного и сложного переходного периода, который должен сделать его мощнее и стабильнее по многим параметрам.
В конце прошлого года я опубликовал обновленные версии roadmap-документов, в которых я описывал пять больших категорий того, что сейчас меняется в протоколе. Эти пять категорий: Merge, Surge, Verge, Purge и Splurge. Merge — это Proof-of-Stake, Surge — сегментирование (шардинг), Verge — деревья Verkle, Purge — state expiry (удаление старой истории). Ну, а Splurge, по сути, — все остальные прикольные штуки. Работы по каждой из категорий хватает.
Как движется работа по Merge
Сейчас закончен блок работ по улучшенной выборке форков. Что касается тест-сетей, они готовы примерно на 90%. Осталось только подключить Ropsten, а это должно случиться уже скоро. И затем состоится the Merge в майннете. Потом будет Post-merge с включенной функцией вывода средств, чтобы народ, который только начал стейкать смог вернуть свои деньги.
Есть еще некоторые клевые штуки, которые мы хотим внедрить в будущем. Single secret leader election нужен для того, чтобы уменьшить предсказуемость выбора следующего создателя блока. Это защитит от DDoS-атак. SSLE сделает невозможным предсказание следующего создателя блока до момента, когда он этот блок выпустит. Это, по сути, серьезно повышает безопасность, ведь не зная, кого атаковать, потенциальный хакер не сможет остановить создание блоков.
Single-slot finality раньше назывался single slot confirmation, теперь — finality. Мы движемся к реальности, в которой Ethereum сможет подтверждать блоки в одном слоте. Этой темой я сам и другие участники команды занимались где-то последние полгода. Исследователи consensus тоже продуктивно над ней трудятся, работают над оптимизациями. Лучшая агрегация сигнатур — тоже часть single-slot finality. Много работы еще предстоит над Proof-of-Stake, но в итоге механизм PoS выйдет реально крутым.
Что ждет протокол на стадии Surge
Так, теперь пару слов о Surge. Это шардинг. По сути дела, перед тем как приняться за #4488, мы решили немного переставить цифры, и вот у нас получается #4844, то есть прото-данкшардинг (proto-danksharding). Мы пытаемся заложить фундамент под полный шардинг, чтобы имелись все форматы данных. В то же время пусть немного, но расширяем пространство данных для нужд роллапов (rollups), чтобы их значительно удешевить. Их цена может упасть раз в десять.
Потом в планах остальные доработки: увеличение объема доступного нам пространства для ускорения подтверждений, чтобы у Ethereum была не только масштабируемость, но и низкие задержки, по крайней мере, чтобы выдавать подтверждение о включении транзакции.
Так что да, много клевых штук, и в итоге Ethereum станет более масштабируемой системой. Текущая версия протокола может обрабатывать где-то 15–20 транзакций в секунду, а вот этот Ethereum, с роллапами и шардингом, по крайней мере в теории за секунду сможет справляться с сотней тысяч.
Что ждет протокол на стадиях Verge и Purge
В Verge появятся stateless-клиенты. Теперь можно будет верифицировать блоки Ethereum и даже стать валидатором без лишних сотен гигов данных. Это хорошо в плане децентрализации. Purge — это попытка снизить требования к свободному пространству на винте и со временем упростить протокол. Благодаря этому система станет более мощной, безотказной и безопасной, еще более децентрализованной, но процесс перехода длинный и сложный, реализуется куча всего, и работу над каждым из этих блоков уже ведет своя конкретная команда.
Долгий, долгий роадмап и большие перемены
В чем разница между биткоином и Ethereum? Биткоинеры оценивают готовность
Я эту мысль уже пару раз повторял. И если задуматься о том, к чему Ethereum в итоге хочет прийти, то так и есть: сам протокол действительно старается отыгрывать роль безопасного базового уровня, но при этом еще и реально сохраняя функционал, нужный, чтобы пользователи могли решать свои задачи. И для этого надо прикручивать новые фичи, больше работать. После the Merge, Ethereum будет готов на 55%. Мы приближаемся ко второй половине длинного пути к большой цели. Завершение переходного периода означает глубинные перемены. Здесь я имею в виду серьезные изменения в восприятии Ethereum как протокола.
Изменения будут в монетарной политике и в модели безопасности. Переход с Proof-of-Work на Proof-of-Stake сократит эмиссию с 5 миллионов монет в год до вот такого причудливого уравнения: 166 х корень квадратный из общей суммы депозитов. То есть миллион ETH, стейкинг будет всего 166 000; при ста миллионах стейкинг дойдет лишь до 1,66 млн. Но в любом случае сокращение существенное; цифра будет уже плавающая, но точно гораздо ниже предыдущей.
Proof-of-Stake гораздо безопаснее Proof-of-Work, но не лишен некоторых компромиссов, например, понятие слабой субъективности. Об этом и я много раз говорил, и наша команда тоже. Исследователи Ethereum создали инструменты для измерения, но это изменяет модель безопасности.
Выборка доступности данных. Сюда в основу заложена идея о возможности работы блокчейна буквально без единой ноды для обработки всей цепи. Логично для распределенных систем. Никто даже не подумал бы делать BitTorrent так, чтобы он заставлял скачивать ВСЕ фильмы, да? Но именно так блокчейны сегодня и работают.
Попытка как бы «подружить» настоящее распределение, которое реализовано, например, в пиринговых сетях, где разные их сегменты отвечают за свои части данных, с элементами безопасности, которые дает сам блокчейн, — та самая цель, к которой сейчас стремится протокол.
Кстати, в этих статьях я описываю все изменения намного подробнее: раз и два.
Изменения в системе хранения данных
Доступ к истории уровня L2: многие dApp, которые изначально создавались на Ethereum, исходили из предположения, что можно использовать доступ к истории, можно заглядывать в архивные записи и транзакции.
И dApp применяющее протокол Web3, сможет показать вам всю историю вашего с ним взаимодействия. Ethereum так работал с самого момента создания, но это скоро уйдет в прошлое благодаря EIP-4444. Этот функционал доступа, восстановления и выведения всей и вся истории Ethereum уже не будет основным требованием к нодам. Нельзя заставлять ноды хранить постоянно растущий объем данных.
Есть и альтернативы: куча очень безопасных и децентрализованных методов хранения истории, которые не заставляют каждую ноду хранить всю историю Ethereum. Например, протоколы L2, Graph, разработки ребят из сети Portal, над этим работают и другие группы. Кто-то вовсе пытается выгружать сегменты истории Ethereum в BitTorrent. Еще есть целая куча block explorer’ов. Думаю, можно сделать мультиплексор или даже протокол, запрашивающий пруфы для безопасности.
Это также изменение модели безопасности. В принципе, к этому изменению многие dApp’ы уже адаптировались. Многие уже напрямую не работают с API Web3, а используют Graph. И в целом я думаю, что экосистема к этому уже адаптирована, но всё равно такое изменение нужно, чтобы Ethereum стал более децентрализованным и масштабируемым.
Новая криптография Ethereum
В плане безопасности версия Ethereum 2015 полагалась только на Keccak-хэши и криптографию на базе эллиптических кривых. Версия Ethereum 2023, помимо них, будет включать продвинутые варианты применения эллиптических кривых — например, деревья Verkle, если успеем их закончить к 2023 году, но возможно, уже в 2024 году.
Также будут сопряжения эллиптических кривых — усложненная версия этой математической логики. На них уже работает The Beacon Chain. Еще универсальная доверенная система для выборки доступности данных. И еще, возможно, в итоге рандомность будет усилена с помощью VDF. Внедряются новые криптографические допущения, но они несут существенные выгоды.
Например, сегодняшний Ethereum применяет BLS-сигнатуры, зависящие от сопряжений. Это дает нам возможность привлекать сотни тысяч валидаторов, а благодаря им пользователи могут стейкать напрямую с минимумом всего 32 ETH.
Кто помнит, каким был минимум до нашего решения перейти на BLS? Полторы тысячи.
Мы внедрили security assumption на базе новой криптографии, преимущество от этого — стейкинг стал доступнее в 50 раз.
Что касается включения транзакций
EIP-1559 — внедрили в прошлом году, и результат огонь, многое поменялось. Но понадобилось и сильно изменить подход к включению транзакций.
Account abstraction: по сути, можно отправлять транзакции, с верификацией не только подписями на эллиптических кривых, но и на базе какого угодно алгоритма. Тогда и multisig, и кошельки для смарт-контрактов и social recovery станут лучше.
В теории с account abstraction также можно использовать более короткие подписи, применять их агрегацию, и это мощная фишка роллапов. Агрегация подписей позволит убрать 65 байт подписи из каждой транзакции и использовать всего 65 байт на целый блок. Так что в случае реализации всего этого, роллап может подешеветь в три раза.
Разделение proposer/builder также способно изменить подход к включению транзакций. Приходится пересматривать старые подходы к некоторым аспектам.
Это также потребовало создания более мощной экосистемы R&D, чтобы реализовать изменения, да еще на 5 клиентах, обеспечить единообразие внедрения
во все пять, отловить все баги, пройти весь этот pipeline и довести до уровня продакшн.
Зачем Ethereum нужно остепениться
Перейду к более «осторожной» части выступления. Все изменения сводятся к тому, чтобы Ethereum наконец «остепенился». Сейчас я думаю, что мы входим в эпоху быстрых перемен, когда мощь Ethereum быстро возрастает.
Мы внедрим EIP-1559, перейдем на Proof-of-Stake, деревья Verkle, single secret leader election, усовершенствуем EVM — и всё это в общем-то круто. Но к какому-то моменту темп внесения в протокол изменений снова нужно будет сбавить. Это вовсе не значит, что Ethereum полностью закостенеет, но он скорее будет походить на экосистему, которой повышают безопасность и предсказуемость, а не такую, которая меняется чисто ради крутизны и внешних впечатлений.
Итак, зачем «остепеняться»? Одна из причин — будущее разделение уровней. Этот подход, когда уровень L1 — это безопасность и надежность, а L2 — быстрые итерации, работа, отличная масштабируемость, крайне низкие задержки, крутые фишки для пользователей и тому подобное. В теории можно получать выгоду одновременно от обоих. Это будет возможно, благодаря фундаменту в виде безопасного L1, который и обеспечит безопасность, и сделает акцент не на том, чтобы просто всех обогнать или всё делать максимально быстро, а на выживании, причем выживании намного дольше, чем проекты типа Luna. Уровню L1 нужна оптимизация в безопасность, а L2 можно приспособить под крутые и впечатляющие штуки.
Более того, L2 уже такие штуки делает, за последние пару дней были и анонсы zkEVM, очень активно работают команды и Optimistic, и ZK. Optimism добавил компрессию, Arbitrum тоже потихоньку развивается в сторону стабильности и функционала, не так давно свои анонсы сделал StarkNet, и у нас появляется всё более четкое представление о будущем StarkNet. Например, они очень круто поработали над Cairo. Развивается zkSync, Polygon, ZK-Rollup. Этот список команд очень длинный.
Тезис “Functionality Escape Velocity” простыми словами гласит: «При достаточной мощности уровня L1 остальное можно вешать на L2». Итак, простой, скучный и медленный L1 в сочетании с шустрым L2 — штука хорошая, но для этого L1 должен
быть достаточно хорошим фундаментом. Довольно просто, напоминает полноту по Тьюрингу: если есть достаточно мощный комп, то этой мощи хватит на создание чего угодно. Но если ее не хватает, то этот комп очень быстро превратится в бесполезный набор деталей. С точки зрения теоретических возможностей двух компов, из 1990 и 2020 года, разница не будет слишком существенной: она сведется к масштабу задач и скорости их выполнения. А при сравнении ранних компьютеров с карманным калькулятором разница огромна. Minecraft на калькуляторе просто не запустится.
А вот на компе из 1990-го — пожалуйста.
Так что тезис “Functionality Escape Velocity” вполне применим и к блокчейнам: от них требуется базовый набор элементов, достаточно данных для роллапов, rich statelesessness, чтобы обеспечить работу логики вроде SNARK’ов или fraud proof, базовый функционал сопротивления цензуре, наличие актива — то есть список довольно простых вещей, многие из которых Ethereum уже включает.
Другие реформы в Ethereum: газ, Selfdestruct, EVM
Как только отвлекаешься от пиления новых фич, появляется больше времени на другие не менее полезные штуки. В Ethereum на этом пути есть компромиссные решения, и вот одно из них: сложность внедряемого изменения в сравнении со сложностью конечного результата. Например, запрет на SELFDESTRUCT.
В общем, код SELFDESTRUCT, во-первых, не то чтобы полезен, а во-вторых — ну очень плох в плане привносимой сложности в саму EVM и ее реализацию, и вдобавок усложняет внедрение в протокол других изменений. Если этот код убрать, это существенным образом повысит простоту, но платой за это будет потеря обратной совместимости для очень ограниченного числа приложений.
Реформа стоимости газа. Нынешняя система работы газа зачастую излишне мудреная: и избыточная сложность, и чрезмерная подгонка под весьма специфические ситуации. Совершенствование EVM: формат объектов, EIP, которые позволяют добавлять в код EVM другие разделы. Так что многие из этих возможностей не только расширяют функционал Ethereum, но и делают его проще. Необходимое число строк кода в клиенте со временем тоже уменьшится.
Есть еще пара приложений, спроектированных таким образом, что ну никак не поддерживают эти изменения, и такие sApps придется переписать. Конечно, такое должно реализовываться с заблаговременным предупреждением, чтобы все, кого это затронет, были в курсе, а все приложения, которые жестко зависят от определенных взаимосвязей в протоколе, можно было бы изменить или заменить.
После реализации такого масштаба — а это напряг, который нужно выдержать только раз, — будущие поколения скажут нам большое спасибо.
Идеальная долгосрочная цель
Итак, мы сейчас находимся в моменте, когда общая сложность сети повышается, но очень надеемся, что в будущем она начнет снижаться благодаря упрощениям. Клиентам Ethereum не понадобится поддерживать древние версии протокола. После Merge можно будет создать клиент Ethereum, который вообще не будет «знать», что когда-то был этап Proof-of-Work. Это приведет к серьезному упрощению по многим аспектам.
Да, в краткосрочной перспективе где-то отвалится обратная совместимость, но число таких случаев будет очень ограниченным. Один из моих постулатов тут: «Да, это нормально». На каком-то этапе экосистеме придется немного потерпеть для светлого будущего. Потом консенсус по всему понадобится сильнее нынешнего, а где-то работа будет тормозить, и это будет выглядеть совсем иначе, чем текущая версия Ethereum.
Каких моментов лучше избегать
Вот список конкретных моментов, которых я опасаюсь и считаю, что лучше без них.
Добавление поддержки нескольких EVM. Мы одновременно поддерживаем EVM, E-WASM, Cairo и еще много всего. Из-за этого повышается сложность консенсуса. Отказаться от EVM будет трудно, если же станем добавлять, то придем к трем разным EVM, а число строк кода протокола будет вечно расти как на дрожжах.
Слишком сильная привязка к SNARK’ам базовых уровней до существенного улучшения circuit legibility. То есть до реального появления инструментов, чтобы копаться в cirtcuit’ах zkSNARK и до точного понимания по каждому ограничению. Поэтому мое мнение о SNARK’ах такое: они еще недостаточно изучены,
Также лично меня напрягает эта мысль: «Ну и что, что протокол целиком никто не сможет понять — а мы разделимся». Я думаю, что Ethereum — это
trustless-протокол, в том числе и потому, что он простой, и любой загоревшийся идеей его понять сможет это сделать. Это как бы накладывает серьезные ограничения.
Какие еще крутые штуки нужно внедрить
Одной из таких штук может быть интуитивно понятный, легкий клиент для уровней и консенсуса, и исполнения, и L2 — и при этом он станет клиентом по умолчанию.
Проще говоря, я хотел бы прийти к такой реальности, вместо использования плагина MetaMask, я хотел бы видеть применение какого-либо кошелька, по сути являющегося легким клиентом, который напрямую использует децентрализованные протоколы и подключается непосредственно к сети Ethereum. И чтобы это происходило и в базовом Ethereum, и в L2. Это же касается и StarkNet, и Optimism, и DigiSync, и Arbitrum, и Squirtle, и еще Polygon — тоже как-то подключаться в систему.
И по сути получались бы легкие клиенты с прямым доступом и верификацией всех этих систем.
Улучшенная поддержка home stakers и мелких децентрализованных staking-пулов.
То есть даже тем юзерам, кому нужны staking-пулы за неимением 32 эфирок (или какой у нас в итоге получится минимум), нужно обеспечить возможность присоединения к мелкому пулу, а не гнать их в крупные.
Еще возможность запуска полной ноды на железе поскромнее. По-моему, в будущем, по мере появления всё новых zkSNARK’ов, с этим пунктом может стать лучше. Ситуация также улучшится благодаря деревьям Verkle. Ведь тогда не потребуется полтерабайта дискового пространства. Так что в теории после внедрения деревьев Verkle и хорошей оптимизации клиента всё будет гоняться только в оперативке. Есть вариант, что валидаторам всё же понадобится что-то хранить на винте и требования чуть возрастут, но, надеюсь, не сильно. Лично я всё еще хочу сделать реальностью стейкинг на мобильных телефонах. Мы можем увести нашу экосистему по пути к существенной децентрализации, существенному снижению зависимости от отдельных субъектов, существенно меньшему риску утечки личных данных, и сделать сеть Ethereum устойчивой настолько, насколько этого желают многие, как мне кажется.
Путь к намеченным целям децентрализации сейчас труднее, поскольку протокол быстро меняется, возрастает общая сложность, но когда он станет проще, а темп изменений замедлится, работа над большей децентрализацией упростится.
Изменения в дальней перспективе
Апгрейды для «квантового сопротивления». Весьма вероятно, что квантовые компьютеры появятся, и с учетом этого нам понадобится перейти на новую криптографию. Так что можно будет использовать хэши, STARK’и, решетки и изогении. В целом приход квантовых компьютеров заставит нас привыкать к новым инструментам, и, очевидно, экосистеме тоже придется с этим справляться. Также понадобится чем-то пожертвовать, но это неизбежно, если наша цель — безопасный Ethereum.
Если zkEVM отработает как надо, вырастет число транзакций на базовом уровне; если мы добьемся хорошей circuit legibility и очень хорошей реализации zk, и можно будет SNARK-верифицировать EVM, то это можно применить и на базовом уровне.
Можно расширять пространство для транзакций, расширять его за счет использования пространства доступности данных…
Если новые методы криптографии позволят существенно повысить эффективность и простоту, то надо будет их внедрить. Возможно, в будущем простые хэши, арифметически рациональные хэши станут достаточно малорисковыми и удобными, так что мы решим уйти от деревьев Verkle и переключимся на STARK-пруфинг арифметически рациональных хэшей на Merkle tries.
И я считаю, нужно сохранять непредвзятость — в том смысле, что мы не знаем,
какая потребности будут в 2032 году. В качестве одного из примеров такого: вся эта история с MEV. Центральная роль понятия MEV, вокруг которого приходится адаптировать весь протокол, была нам не особо-то и понятна в 2019 году. К этому пониманию мы пришли в 2021, теперь MEV — хорошо изученный аспект, и сейчас, в 2022, мы его учитываем при работе с протоколом. Так что в будущем нельзя
исключать ситуаций, когда нам понадобится пересмотреть наш подход к борьбе с атаками 51%,
Переход на Proof-of-Stake — серьезное изменение, но оно принесет кучу преимуществ. Популярность шардинга исходит из понимания, что достижение видения Ethereum предполагает гораздо меньшую плату за транзакцию и мы хотим как-то выйти на поддержку 50 000 транзакций в секунду. Не выйдет сделать децентрализованно — что же, сделаем централизованным образом. Шардинг — штука важная, но есть баланс: что нужно сделать, а что можно отдать на откуп уровню L2.
