Автор: Виталик Бутерин
Составитель: Карен, Foresight News
Особая благодарность Джастину Дрейку, Франческо, Сяо-Вэй Вану, @antonttc и Георгиосу Константопулосу.
Изначально в дорожной карте Ethereum было две стратегии масштабирования. Один из них (см. более раннюю статью 2015 года) — это «шардинг»: каждому узлу необходимо проверять и хранить лишь небольшую часть транзакций, а не проверять и сохранять все транзакции в цепочке. Любая другая одноранговая сеть (например, BitTorrent) работает таким же образом, поэтому мы, безусловно, можем заставить блокчейн работать таким же образом. Другой — протоколы Layer2: эти сети будут располагаться поверх Ethereum, что позволит им в полной мере воспользоваться преимуществами его безопасности, сохраняя при этом большую часть данных и вычислений вне основной цепочки. Протоколы Layer2 относятся к каналам состояния в 2015 году, Plasma в 2017 году, а затем к Rollup в 2019 году. Объединения более мощны, чем каналы состояния или Plasma, но они требуют большой пропускной способности внутрицепной передачи данных. К счастью, к 2019 году исследование шардинга решило проблему проверки «доступности данных» в большом масштабе. В результате два пути сошлись, и мы получили дорожную карту, ориентированную на Rollup, которая и сегодня остается стратегией масштабирования Ethereum.
The Surge, издание дорожной карты на 2023 год
Дорожная карта, ориентированная на Rollup, предлагает простое разделение труда: Ethereum L1 ориентирован на то, чтобы стать мощным и децентрализованным базовым уровнем, а L2 призван помочь в масштабировании экосистемы. Эта модель повсеместно распространена в обществе: судебная система (L1) существует не для достижения сверхскорости и эффективности, а для защиты контрактов и прав собственности, а предприниматели (L2) строят на этом прочном фундаменте Строят, чтобы вести человечество (в прямом и переносном смысле) к ) Марс.
В этом году дорожная карта, ориентированная на объединение, достигла важных результатов: с запуском блоков EIP-4844 пропускная способность данных Ethereum L1 значительно увеличилась, а несколько объединений виртуальных машин Ethereum (EVM) вступили в первую фазу. Каждый L2 существует как «шард» со своими внутренними правилами и логикой. Разнообразие и диверсификация методов реализации шардинга теперь стали реальностью. Но, как мы видели, движение по этому пути сопряжено с некоторыми уникальными проблемами. Поэтому наша задача сейчас — завершить дорожную карту, ориентированную на Rollup, и решить эти проблемы, сохраняя при этом надежность и децентрализацию, которые характеризуют Ethereum L1.
Всплеск: ключевые цели
1. В будущем Ethereum может достичь более 100 000 TPS через L2;
2. Поддерживать децентрализацию и надежность L1;
3. По крайней мере, некоторые L2 полностью наследуют основные атрибуты Ethereum (ненадежный, открытый, устойчивый к цензуре);
4. Эфириум должен ощущаться как единая экосистема, а не как 34 разных блокчейна.
Содержание этой главы
Треугольник масштабируемости
Дальнейший прогресс в выборке доступности данных
Сжатие данных
Обобщенная плазма
Зрелая система проверки L2
Улучшения совместимости между уровнями 2
Продлить выполнение на L1
Треугольник масштабируемости
Треугольник масштабируемости — это идея, предложенная в 2017 году, которая видит противоречие между тремя свойствами блокчейна: децентрализацией (более конкретно: низкой стоимостью эксплуатации узлов), масштабируемостью (обработка большого количества транзакций) и безопасностью (злоумышленнику придется скомпрометировать большую части узлов в сети, что может привести к сбою одной транзакции).
Стоит отметить, что парадокс треугольника не является теоремой, и статья, описывающая парадокс треугольника, не сопровождается математическим доказательством. Это дает эвристический математический аргумент: если удобный для децентрализации узел (например, потребительский ноутбук) может проверять N транзакций в секунду, и у вас есть цепочка, которая обрабатывает k*N транзакций в секунду, тогда (i) каждая транзакция может быть только видят 1/k узлов, а это означает, что злоумышленнику нужно скомпрометировать только несколько узлов, чтобы провести вредоносную транзакцию, или (ii) ваш узел станет мощным, а ваша цепочка не будет децентрализованной. Целью этой статьи никогда не было доказать, что нарушение парадокса треугольника невозможно, скорее, она была призвана показать, что нарушение трилеммы сложно и что это требует некоторой степени мышления вне рамок аргументации;
На протяжении многих лет некоторые высокопроизводительные сети часто заявляли, что они решили трилемму, не меняя фундаментально свою архитектуру, часто применяя методы разработки программного обеспечения для оптимизации узлов. Это всегда вводит в заблуждение, запустить узел в этих цепочках гораздо сложнее, чем запустить узел на Ethereum. В этой статье мы рассмотрим, почему это так и почему разработка клиентского программного обеспечения L1 сама по себе не может масштабировать Ethereum?
Однако сочетание выборки доступности данных и SNARK решает парадокс треугольника: оно позволяет клиенту проверить, что определенный объем данных доступен и определенное количество вычислительных шагов доступно, загружая при этом только небольшой объем данных и выполняя их. очень небольшой объем вычислений. Правильно выполнено. СНАРК не заслуживают доверия. Выборка доступности данных имеет тонкую модель доверия «несколько из N», но она сохраняет фундаментальное свойство немасштабируемых цепочек, а именно то, что даже атака 51% не может заставить сеть принять плохие блоки.
Еще одним решением трилеммы является архитектура Plasma, в которой используются умные методы, позволяющие возложить ответственность за мониторинг доступности данных на пользователя способом, совместимым с стимулами. Еще в 2017–2019 годах, когда у нас были только доказательства мошенничества как средство расширения вычислительной мощности, Plasma была очень ограничена с точки зрения обеспечения безопасности, но с популярностью SNARK (кратких неинтерактивных аргументов с нулевым разглашением), Plasma архитектура больше. Более широкий спектр вариантов использования стал более осуществимым.
Дальнейший прогресс в выборке доступности данных
Какую проблему мы решаем?
Когда обновление Dencun будет запущено 13 марта 2024 года, блокчейн Ethereum будет иметь 3 больших двоичных объекта размером примерно 125 КБ на 12-секундный слот, или примерно 375 КБ доступной пропускной способности данных на слот. Если предположить, что данные о транзакциях публикуются непосредственно в цепочке, передача ERC20 составляет примерно 180 байт, поэтому максимальный TPS Rollup на Ethereum составляет: 375000 / 12 / 180 = 173,6 TPS.
Если мы добавим данные вызовов Ethereum (теоретический максимум: 30 миллионов Gas на слот / 16 Gas на байт = 1 875 000 байт на слот), это составит 607 TPS. С помощью PeerDAS количество больших двоичных объектов можно увеличить до 8–16, что обеспечит 463–926 TPS для данных вызовов.
Это значительное улучшение по сравнению с Ethereum L1, но недостаточное. Мы хотим большей масштабируемости. Наша среднесрочная цель — 16 МБ на слот, что в сочетании с улучшениями сжатия данных при объединении приведет к примерно 58 000 TPS.
что это такое? Как это работает?
PeerDAS — это относительно простая реализация «1D выборки». В Ethereum каждый блоб представляет собой полином степени 4096 в 253-битном простом поле. Мы транслируем полиномиальные доли, где каждая доля содержит 16 оценок по 16 соседним координатам из общего числа 8192 координат. Из этих 8192 оцененных значений любые 4096 (согласно предлагаемым на данный момент параметрам: любые 64 из 128 возможных выборок) могут восстановить блоб.
PeerDAS работает, заставляя каждого клиента прослушивать небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого большого двоичного объекта, и запрашивая одноранговые узлы в глобальной p2p-сети, которые будут прослушивать в разных подсетях, запрашивать большие двоичные объекты на другие подсети, которые ему нужны. Более консервативная версия SubnetDAS использует только механизм подсети без дополнительного опроса пирингового уровня. Текущее предложение состоит в том, чтобы узлы, участвующие в Proof of Stake, использовали SubnetDAS, в то время как другие узлы (то есть клиенты) использовали PeerDAS.
Теоретически мы можем довольно сильно масштабировать «1D-выборку»: если мы увеличим максимальное количество больших двоичных объектов до 256 (нацеливаясь на 128), то мы сможем достичь целевого показателя в 16 МБ, и каждая выборка доступности данных будет составлять 16 выборок на узел * 128. большие двоичные объекты * 512 байт на выборку на один большой двоичный объект = 1 МБ полосы пропускания данных на слот. Это едва ли находится в пределах нашего допустимого диапазона: это выполнимо, но это означает, что клиенты с ограниченной полосой пропускания не могут осуществлять выборку. Мы можем несколько оптимизировать это, уменьшив количество больших двоичных объектов и увеличив их размер, но это сделает пересборку более дорогостоящей.
Поэтому в конечном итоге мы хотим пойти еще дальше и выполнить 2D-сэмплирование, то есть случайную выборку не только внутри больших двоичных объектов, но и между ними. Используя свойства линейности обязательств KZG, набор больших двоичных объектов в блоке расширяется за счет нового набора виртуальных больших двоичных объектов, которые избыточно кодируют ту же информацию.
Итак, в конечном итоге мы хотим пойти еще дальше и выполнить 2D-сэмплирование, то есть случайную выборку не только внутри больших двоичных объектов, но и между ними. Свойство линейности обязательств KZG используется для расширения набора больших двоичных объектов в блоке списком новых виртуальных больших двоичных объектов, которые избыточно кодируют одну и ту же информацию.
2D выборка. Источник: криптовалюта a16z.
Важно отметить, что вычисление масштабирования обязательств не требует больших двоичных объектов, поэтому схема принципиально удобна для построения распределенных блоков. Узлам, которые фактически создают блоки, необходимо только иметь обязательство KZG больших двоичных объектов, и они могут полагаться на выборку доступности данных (DAS) для проверки доступности блока данных. Одномерная выборка доступности данных (1D DAS) также по своей сути удобна для построения распределенных блоков.
Каковы связи с существующими исследованиями?
Исходное сообщение о доступности данных (2018 г.): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding.
Дополнительный документ: https://arxiv.org/abs/1809.09044
Пояснительная статья о DAS, парадигме: https://www.paradigm.xyz/2022/08/das
Доступность 2D с обязательствами KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
PeerDAS на ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-comComponents/16541 и документ: https://eprint.iacr.org/ 2024/1362
EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
SubnetDAS на ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
Нюансы восстановления данных при 2D-выборке: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256
Что еще нужно сделать? Каковы компромиссы?
Далее завершается внедрение и развертывание PeerDAS. После этого начался постепенный процесс увеличения количества больших двоичных объектов в PeerDAS при тщательном наблюдении за сетью и улучшении программного обеспечения для обеспечения безопасности. Тем временем мы надеемся увидеть больше научных работ по стандартизации PeerDAS и других версий DAS и их взаимодействия с такими проблемами, как безопасность правил выбора вилки.
На дальнейших этапах в будущем нам необходимо проделать дополнительную работу, чтобы определить идеальную версию 2D DAS и доказать ее свойства безопасности. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, которая является квантовобезопасной и не требует доверенной установки. В настоящее время мы не знаем, какие кандидаты дружелюбны к построению распределенных блоков. Даже использование дорогостоящих методов «грубой силы», даже использование рекурсивных STARK для генерации доказательств достоверности для восстановления строк и столбцов, недостаточно, потому что, хотя технически STARK представляет собой хэш-значение O(log(n) * log(log(n)) (с использованием STIR), но на самом деле STARK почти такого же размера, как и вся капля.
Мой долгосрочный реалистичный путь таков:
Внедрить идеальный 2D DAS;
Придерживайтесь 1D DAS, пожертвуйте эффективностью полосы пропускания выборки и примите более низкие ограничения по объему данных для простоты и надежности.
Откажитесь от DA и полностью используйте Plasma в качестве основной архитектуры Layer2, на которой мы фокусируемся.
Обратите внимание, что эта опция существует, даже если мы решим масштабировать выполнение непосредственно на уровне L1. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиенту понадобится эффективный способ проверки их правильности, поэтому нам придется использовать Rollup (например, ZK) на Уровень L1 — EVM и DAS) та же технология.
Как мне взаимодействовать с другими частями дорожной карты?
Потребность в 2D DAS будет уменьшена или, по крайней мере, отложена, если будет реализовано сжатие данных, и еще больше сократится, если Plasma станет широко использоваться. DAS также создает проблемы для протоколов и механизмов построения распределенных блоков: хотя DAS теоретически удобен для распределенной реконструкции, на практике это необходимо сочетать с предложением списка включения и окружающим его механизмом выбора вилки.
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает много места в цепочке данных: передача ERC20 занимает около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протокола уровня. При 16 МБ на слот получаем:
16000000 / 12 / 180 = 7407 ТПС
Что, если бы мы могли решить не только проблему числителя, но и проблему знаменателя, чтобы каждая транзакция в объединении занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это фотография двухлетней давности:
При нулевом сжатии каждая длинная последовательность нулевых байтов заменяется двумя байтами, указывая, сколько нулевых байтов имеется. Идя еще дальше, мы используем определенные свойства транзакций:
Агрегация подписей: мы переходим от подписей ECDSA к подписям BLS. Особенностью подписей BLS является то, что несколько подписей можно объединить в одну подпись, которая может доказать достоверность всех исходных подписей. На уровне L1 подписи BLS не учитываются из-за высоких вычислительных затрат на проверку даже при агрегации. Но в среде с дефицитом данных, такой как L2, имеет смысл использовать подписи BLS. Агрегационная природа ERC-4337 позволяет реализовать эту функциональность.
Замена адресов указателями. Если адрес использовался ранее, мы можем заменить 20-байтовый адрес 4-байтовым указателем, указывающим на место в истории.
Пользовательская сериализация значений транзакций. Большинство значений транзакций имеют очень мало цифр, например, 0,25 ETH представлены как 250 000 000 000 000 000 wei. Максимальная базовая плата за обработку и плата за приоритетную обработку также аналогичны. Поэтому мы можем использовать собственный десятичный формат с плавающей запятой для представления большинства денежных значений.
Каковы связи с существующими исследованиями?
Изучите последовательность.xyz: https://sequence.xyz/blog/compressing-calldata
Контракт на оптимизацию данных вызовов L2: https://github.com/ScopeLift/l2-optimizooooors.
Сводки, основанные на доказательствах достоверности (также известные как свертки ZK), публикуют различия в состоянии вместо транзакций: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2 -data -след-на-l1/9975
BLS Wallet — агрегация BLS через ERC-4337: https://github.com/getwax/bls-wallet
Что еще нужно сделать и каковы компромиссы?
Главное, что нужно сделать дальше, — это реализовать вышеуказанное решение. К основным компромиссам относятся:
1. Переход на подписи BLS требует больших усилий и снижает совместимость с доверенными аппаратными чипами, повышающими безопасность. Вместо этого можно использовать оболочки ZK-SNARK других схем подписи.
2. Динамическое сжатие (например, замена адресов указателями) усложнит клиентский код.
3. Публикация различий в статусах в цепочке вместо транзакций снизит возможность аудита и сделает многие программы (например, обозреватели блоков) неработоспособными.
Как мне взаимодействовать с другими частями дорожной карты?
Принятие ERC-4337 и, в конечном итоге, включение его частей в EVM L2 может значительно ускорить внедрение конвергентных технологий. Размещение частей ERC-4337 на уровне L1 может ускорить его развертывание на уровне L2.
Обобщенная плазма
Какую проблему мы решаем?
Даже при наличии 16-мегабайтных блоков и сжатии данных 58 000 TPS может быть недостаточно для полного удовлетворения потребностей потребительских платежей, децентрализованных социальных сетей или других областей с высокой пропускной способностью, особенно если мы начинаем учитывать факторы конфиденциальности, которые могут снизить масштабируемость. Снижение на 3 -8 раз. Для сценариев приложений с большим объемом транзакций и низкой стоимостью одним из текущих вариантов является использование Validium, который хранит данные вне цепочки и использует интересную модель безопасности: операторы не могут украсть средства пользователей, но они могут временно или навсегда заморозить все средства пользователей. Но мы можем добиться большего.
Что это такое и как это работает?
Plasma — это решение для масштабирования, в котором оператор публикует блоки вне цепочки и помещает корни Меркла этих блоков в цепочку (в отличие от Rollup, который помещает в цепочку целые блоки). Для каждого блока оператор отправляет каждому пользователю ветку Меркла, чтобы доказать, что изменилось или не изменилось в активах этого пользователя. Пользователи могут вывести свои активы, предоставив форк Merkle. Важно отметить, что эта ветка не обязательно должна быть внедрена в последней версии. Таким образом, даже если возникнет проблема с доступностью данных, пользователи все равно смогут восстановить свои активы, получив последний доступный им статус. Если пользователь совершает недействительную ветвь (например, отзывает актив, который он уже отправил кому-то другому, или оператор сам создает актив из воздуха), законное право собственности на актив можно определить с помощью ончейн-вызова. механизм.
Схема цепочки Plasma Cash. Транзакция стоимостью i монеты помещается на i-ю позицию в дереве. В этом примере, предполагая, что все предыдущие деревья действительны, мы знаем, что Ева в настоящее время владеет токеном 1, Дэвид владеет токеном 4, а Джордж владеет токеном 6.
Ранние версии Plasma были способны обрабатывать только сценарии использования платежей и не могли эффективно продвигаться дальше. Однако Plasma станет намного более мощной, если мы потребуем, чтобы каждый корень был проверен с помощью SNARK. Каждую игру-испытание можно значительно упростить, поскольку мы исключаем большинство возможных способов обмана операторов. В то же время открываются новые пути, позволяющие технологии Plasma распространиться на более широкий спектр классов активов. Наконец, если оператор не обманывает, пользователи могут вывести средства сразу, не дожидаясь недельного испытательного периода.
Один из способов (не единственный) создать цепочку EVM Plasma: использовать ZK-SNARK для построения параллельного дерева UTXO, которое отражает изменения баланса, внесенные EVM, и определяет «один и тот же токен» в разные моменты истории. «Единственное сопоставление. . Затем поверх него можно построить плазменные структуры.
Ключевой вывод заключается в том, что плазменные системы не обязательно должны быть идеальными. Даже если вы можете защитить только часть активов (например, только токены, которые не перемещались за последнюю неделю), вы значительно улучшили текущее состояние гипермасштабируемой EVM (то есть Validium).
Другой тип структуры — гибрид Plasma/Rollup, например Intmax. Эти конструкции помещают в цепочку очень небольшой объем данных на каждого пользователя (например, 5 байт) и при этом достигают некоторых свойств между Plasma и Rollup: в случае Intmax можно добиться очень высокой масштабируемости и конфиденциальности, хотя даже при емкости 16 МБ теоретически она ограничена примерно 16 000 000 / 12 / 5 = 266 667 TPS.
Каковы связи с существующими исследованиями?
Оригинальная статья Plasma: https://plasma.io/plasma-deprecated.pdf
Plasma Cash: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#?-Выход
Интмакс (2023): https://eprint.iacr.org/2023/1082
Что еще нужно сделать? Каковы компромиссы?
Основная оставшаяся задача — ввести систему «Плазма» в практическое производственное использование. Как упоминалось выше, «Плазма» или «Валидиум» — это не выбор «или-или»: любой «Валидиум» может улучшить свои свойства безопасности, по крайней мере, в некоторой степени, включив функции «Плазмы» в свой механизм выхода. Целью исследования является получение наилучших свойств EVM. (рассматривается с точки зрения требований к доверию, стоимости газа L1 в наихудшем случае и способности противостоять DoS-атакам), а также альтернативных структур, специфичных для приложения. Кроме того, Plasma концептуально более сложна, чем Rollup, которая требует непосредственного исследования и. создание более эффективных общих рамок.
Основным недостатком использования конструкций Plasma является то, что они в большей степени зависят от оператора и их сложнее базировать, хотя гибридные конструкции Plasma/Rollup часто позволяют избежать этого недостатка.
Как мне взаимодействовать с другими частями дорожной карты?
Чем эффективнее решение Plasma, тем меньше давления на уровень L1, связанный с возможностями высокопроизводительной доступности данных. Перенос деятельности на уровень L2 также снижает нагрузку MEV на уровень L1.
Зрелая система проверки L2
Какую проблему мы решаем?
В настоящее время большинство накопительных пакетов на самом деле не являются надежными. Существует комитет безопасности, который имеет возможность контролировать (оптимистично или обоснованно) поведение системы. В некоторых случаях система аттестации вообще не работает, а если и работает, то имеет лишь «консультативную» функцию. Современные накопительные пакеты включают в себя: (i) некоторые ненадежные накопительные пакеты для конкретных приложений, такие как Fuel (ii) на момент написания этой статьи Optimism и Arbitrum достигли этапа частичной ненадежности, известного как «Фаза 1»; Полный накопительный пакет EVM. Причина, по которой Rollup не смог добиться дальнейшего прогресса, заключалась в опасениях по поводу ошибок в коде. Нам нужен не требующий доверия Rollup, поэтому нам придется столкнуться с этой проблемой лицом к лицу и решить ее.
Что это такое и как это работает?
Во-первых, давайте рассмотрим систему «стадий», первоначально представленную в этой статье.
Этап 0: пользователи должны иметь возможность запускать узел и синхронизировать цепочку. Если проверка полностью доверенная/централизованная, это тоже нормально.
Этап 1: Должна существовать (не требующая доверия) система подтверждения, гарантирующая, что будут приниматься только действительные транзакции. Разрешается создание комитета по безопасности, который может обойти систему сертификации, но при этом должно быть достигнуто пороговое число голосов в 75%. Кроме того, часть комитета, блокирующая кворум (т. е. 26%+), должна находиться за пределами основной компании, создающей накопительный пакет. Допускается более слабый механизм обновления (такой как DAO), но он должен иметь достаточно длительную задержку, чтобы в случае одобрения вредоносного обновления пользователи могли вывести свои средства до того, как они начнут действовать.
Этап 2: Должна существовать (не требующая доверия) система подтверждения, гарантирующая, что будут приниматься только действительные транзакции. Комитету по безопасности разрешается вмешиваться только в том случае, если, например, в коде есть очевидные ошибки. Если две избыточные системы доказательства несовместимы друг с другом или если одна система доказательства принимает два разных корня пост-состояния для одного и того же блока (или не принимает ничего в течение достаточно длительного периода времени, например недели). Механизм обновления разрешен, но должен иметь длительную задержку.
Наша цель – достичь Фазы 2. Основная задача на этапе 2 — обрести достаточную уверенность, чтобы доказать, что система действительно заслуживает доверия. Есть два основных способа сделать это:
Формальная проверка: мы можем использовать современную математику и вычислительные методы, чтобы доказать (оптимистично и достоверно), что система принимает только блоки, соответствующие спецификации EVM. Эти технологии существуют уже несколько десятилетий, но недавние достижения (такие как Lean 4) сделали их более практичными, а достижения в области доказательств с помощью ИИ могут еще больше ускорить эту тенденцию.
Мультидоказательства: создайте несколько систем доказательств и вложите деньги в эти системы доказательств с помощью комитетов безопасности (или других устройств с предположениями о доверии, таких как TEE). Если система доказательств согласна, комитет безопасности не имеет полномочий; в противном случае комитет безопасности может выбирать только между одним из них и не может в одностороннем порядке навязать свой ответ.
Стилизованный график нескольких испытателей, объединяющий систему оптимистического доказательства, систему доказательства валидности и комитет по безопасности.
Каковы связи с существующими исследованиями?
EVM K Semantics (формальная работа по проверке с 2017 года): https://github.com/runtimeverification/evm-semantics
Лекция об идее множественных доказательств (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
Тайко планирует использовать множественные доказательства: https://docs.taiko.xyz/core-concepts/multi-proofs/
Что еще нужно сделать? Каковы компромиссы?
Для формальной проверки нагрузка огромна. Нам необходимо создать формально проверенную версию всего средства доказательства SNARK для EVM. Это чрезвычайно сложный проект, хотя мы уже начали над ним работать. Есть трюк, который значительно упрощает эту задачу: мы можем создать формально верифицированное средство доказательства SNARK для минимальной виртуальной машины (такой как RISC-V или Cairo), а затем реализовать EVM в этой минимальной виртуальной машине (и формальное доказательство ее эквивалентности другим спецификациям виртуальной машины Ethereum).
Есть две основные части мультидоказательства, которые еще предстоит завершить. Во-первых, нам нужно иметь достаточную уверенность как минимум в двух разных системах доказательств, чтобы гарантировать, что каждая из них достаточно безопасна, и чтобы гарантировать, что, если с ними что-то пойдет не так, проблемы должны быть разными и не связанными друг с другом (чтобы они не происходят одновременно Возникает проблема). Во-вторых, нам необходимо иметь очень высокую степень доверия к базовой логике системы доказательства слияния. Эта часть кода намного меньше. Есть способы сделать его очень маленьким, просто храня средства в безопасном контракте с мультиподписью, где контракты представляют каждую систему подтверждения в качестве подписантов, но это увеличит стоимость газа в цепочке. Нам необходимо найти некий баланс между эффективностью и безопасностью.
Как мне взаимодействовать с другими частями дорожной карты?
Перемещение активности на L2 снижает давление MEV на L1.
Улучшения совместимости между уровнями 2
Какую проблему мы решаем?
Основная проблема, с которой сталкивается сегодняшняя экосистема L2, — это сложность навигации пользователей внутри нее. Кроме того, самые простые подходы часто вновь вводят предположения о доверии: централизованные кроссчейны, клиенты RPC и т. д. Нам нужно, чтобы использование экосистемы L2 было похоже на использование единой экосистемы Ethereum.
Что это такое?
Существует множество категорий улучшений совместимости между уровнями 2. Теоретически, Rollup-ориентированный Ethereum — это то же самое, что выполнение шарда L1. Текущая экосистема Ethereum L2 на практике все еще имеет следующие недостатки по сравнению с идеальным состоянием:
1. Адрес конкретной цепочки. Адрес должен содержать информацию о цепочке (L1, Optimism, Arbitrum...). Как только это будет достигнуто, процесс отправки между L2 может быть реализован путем простого помещения адреса в поле «отправить», после чего кошелек сможет самостоятельно обрабатывать отправку в фоновом режиме (включая использование межсетевых протоколов). .
2. Платежные запросы для конкретной цепочки. Создание сообщений вида «Отправьте мне X токенов типа Y в цепочке Z» должно быть простым и стандартизированным. У этого есть два основных сценария применения: (i) будь то оплата между людьми или оплата между людьми и торговыми услугами (ii) DApp запрашивает средства;
3. Межсетевой обмен и оплата Gas: должен существовать стандартизированный открытый протокол для выражения межсетевых операций, например: «Я отправлю 1 Ethereum человеку, который отправил мне 0,9999 Ethereum на Arbitrum (на Оптимизме)» и « Я отправлю 0,0001 эфира (по Оптимизму) человеку, который включил эту транзакцию в Arbitrum». ERC-7683 — это попытка первого, а RIP-7755 — попытка второго, хотя оба имеют более широкое применение, чем эти конкретные варианты использования.
4. Легкие клиенты. Пользователи должны иметь возможность фактически проверять цепочку, с которой они взаимодействуют, а не просто доверять провайдеру RPC. Helios от a16z crypto может сделать это (для самого Ethereum), но нам нужно распространить эту недоверчивость на L2. ERC-3668 (CCIP-чтение) — одна из стратегий достижения этой цели.
Представление о том, как легкие клиенты обновляют свою цепочку заголовков Ethereum. Получив цепочку заголовков, вы можете использовать доказательства Меркла для проверки любого объекта состояния. Если у вас есть правильный объект состояния L1, вы можете использовать доказательства Меркла (и подписи, если вы хотите проверить предварительное подтверждение) для проверки любого объекта состояния на L2. Гелиос сделал первое. Переход к последнему является проблемой стандартизации.
1. Кошелек хранилища ключей. Сегодня, если вы хотите обновить ключ, который управляет вашим кошельком со смарт-контрактом, вы должны обновить его во всех N цепочках, где существует кошелек. Кошельки хранилища ключей — это технология, которая позволяет ключам существовать только в одном месте (либо на L1, либо, возможно, позже на L2), а затем любой L2, у которого есть копия кошелька, может прочитать ключи из него. Это означает, что обновление нужно выполнить только один раз. Чтобы повысить эффективность, кошелек Keystore требует, чтобы L2 имел стандартизированный способ бесплатного считывания информации с L1. Для этого есть два предложения, а именно L1SLOAD и REMOTESTATICCALL;
Как работает кошелек Keystore
2. Более радикальная концепция «моста общих токенов». Представьте себе мир, в котором весь L2 представляет собой совокупность, проверяющую достоверность, и каждый слот передается в Ethereum. Даже в таком мире перевод активов из одного L2 в другой L2 в их исходном состоянии по-прежнему требует снятия средств и депозитов, что требует уплаты значительных комиссий за газ L1. Одним из способов решения этой проблемы является создание общего минималистского накопительного пакета, единственная функция которого состоит в том, чтобы поддерживать, какой L2 владеет каждым типом токена и сколько баланса у каждого, и позволять этим балансам проходить через серию транзакций, инициируемых любыми операциями отправки L2. через L2 для пакетных обновлений. Это позволит осуществлять переводы между уровнями 2 без необходимости платить комиссию за газ L1 за каждый перевод и без использования технологий на основе поставщиков ликвидности, таких как ERC-7683.
3. Синхронная композиционность: позволяет выполнять синхронные вызовы между конкретными уровнями L2 и L1 или между несколькими уровнями L2. Это помогает повысить финансовую эффективность протоколов DeFi. Первое может быть реализовано без какой-либо координации между уровнями 2; второе требует общего порядка; Методы на основе объединения автоматически работают со всеми из них.
Каковы связи с существующими исследованиями?
Конкретный адрес цепочки: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
Прокрутите дизайн кошелька хранилища ключей: https://hackmd.io/@haichen/keystore
Гелиос: https://github.com/a16z/helios
ERC-3668 (иногда называемый чтением CCIP): https://eips.ethereum.org/EIPS/eip-3668
Предложение «Основанных (совместных) предварительных подтверждений», предложенное Джастином Дрейком: https://ethresear.ch/t/based-preconfirmations/17353
L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
REMOTESTATICCALL в Оптимизме: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
AggLayer, включающий в себя идею общего моста токенов: https://github.com/AggLayer
Что еще нужно сделать? Каковы компромиссы?
Многие из приведенных выше примеров сталкиваются с дилеммой стандартов: когда и какие уровни стандартизировать. Если вы стандартизируете слишком рано, вы рискуете закрепить плохое решение. Если вы стандартизируете слишком поздно, вы можете создать ненужную фрагментацию. В некоторых случаях существует краткосрочное решение, которое имеет более слабые свойства, но его легче реализовать, и долгосрочное решение, которое «в конечном итоге является правильным», но для реализации требуются годы.
Эти задачи являются не просто техническими проблемами, это также (возможно, даже в первую очередь) социальные проблемы, которые требуют сотрудничества между L2 и кошельком, а также L1.
Как мне взаимодействовать с другими частями дорожной карты?
Большинство этих предложений представляют собой структуры «более высокого уровня» и поэтому мало влияют на соображения уровня L1. Единственным исключением является общий порядок, который оказывает существенное влияние на максимальную извлекаемую ценность (MEV).
Продлить выполнение на L1
Какую проблему мы решаем?
Если L2 станет очень масштабируемым и успешным, а L1 по-прежнему сможет обрабатывать только очень небольшие объемы транзакций, для Ethereum может возникнуть ряд рисков:
1. Экономическое состояние активов ETH станет более нестабильным, что, в свою очередь, повлияет на долгосрочную безопасность сети.
2. Многие L2 извлекают выгоду из прочных связей с высокоразвитой финансовой экосистемой L1, и если эта экосистема значительно ослабнет, стимулы стать L2 (в отличие от того, чтобы стать независимым L1) ослабнут.
3. L2 потребуется много времени, чтобы достичь той же гарантии безопасности, что и L1.
4. В случае сбоя L2 (например, из-за злонамеренного поведения оператора или его исчезновения) пользователям все равно необходимо восстановить свои активы через L1. Следовательно, L1 должен быть достаточно мощным, чтобы хотя бы время от времени справляться с очень сложными и запутанными завершающими штрихами L2.
По этим причинам чрезвычайно важно продолжать расширять сам уровень L1 и гарантировать, что он сможет продолжать соответствовать растущему числу вариантов использования.
что это такое? Как это работает?
Самый простой способ масштабирования — напрямую увеличить лимит газа. Однако это может привести к централизации L1, тем самым подорвав еще одну важную особенность, которая делает Ethereum L1 таким мощным: его авторитет как надежного базового уровня. До сих пор ведутся споры о том, насколько устойчивым является простое увеличение лимита газа, и на это также будут влиять другие технологии, которые будут реализованы для облегчения проверки более крупных блоков (например, истечение срока истории, безгражданство, подтверждение действительности L1 EVM). Еще одна важная вещь, которую необходимо продолжать улучшать, — это эффективность клиентского программного обеспечения Ethereum, которое сегодня намного эффективнее, чем пять лет назад. Эффективная стратегия ограничения выбросов газа L1 будет включать ускорение разработки этих технологий проверки.
EOF: новый формат байт-кода EVM, который более удобен для статического анализа и обеспечивает более быструю реализацию. Учитывая этот рост эффективности, байт-код EOF может снизить затраты на газ.
Многомерное ценообразование на газ: установка различных базовых комиссий и лимитов на вычисления, данные и хранение может увеличить среднюю емкость Ethereum L1 без увеличения максимальной мощности (тем самым избегая создания новых рисков безопасности).
Снижение затрат на газ для определенных кодов операций и предварительных компиляций. Исторически мы несколько раз увеличивали затраты на газ для некоторых заниженных операций, чтобы избежать атак типа «отказ в обслуживании». Единственное, что можно было бы сделать больше, — это снизить затраты на газ для завышенных кодов операций. Например, сложение намного дешевле, чем умножение, но в настоящее время коды операций ADD и MUL стоят одинаково. Мы можем сделать ADD дешевле и даже более простые коды операций, такие как PUSH, дешевле. EOF в целом более оптимизирован в этом отношении.
EVM-MAX и SIMD: EVM-MAX — это предложение, позволяющее реализовать более эффективную аналоговую математику больших чисел в виде отдельного модуля EVM. Если они не экспортированы намеренно, значения, рассчитанные с помощью вычислений EVM-MAX, доступны только для других кодов операций EVM-MAX. Это дает больше места для хранения этих значений в оптимизированном формате. SIMD (одна инструкция и несколько данных) — это предложение, которое позволяет эффективно выполнять одну и ту же инструкцию над массивом значений. Вместе они создают мощный сопроцессор наряду с EVM, который можно использовать для более эффективной реализации криптографических операций. Это особенно полезно для протоколов конфиденциальности и систем защиты L2, поэтому поможет при масштабировании L1 и L2.
Эти улучшения будут обсуждаться более подробно в будущих статьях Splurge.
Наконец, третья стратегия — это собственные накопительные пакеты (или закрепленные накопительные пакеты): по сути, создание множества копий EVM, которые работают параллельно, в результате чего получается модель, эквивалентная той, которую может предоставить Rollup, но более естественно интегрированная в протокол.
Каковы связи с существующими исследованиями?
Дорожная карта масштабирования Ethereum L1 от Polynya: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
Многомерное ценообразование на газ: https://vitalik.eth.limo/general/2024/05/09/multidim.html.
EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
Конец цитаты: https://evmobjectformat.org/
EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
SIMD: https://eips.ethereum.org/EIPS/eip-616
Собственные накопители: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
Интервью Макса Резника о ценности масштабирования L1: https://x.com/BanklessHQ/status/1831319419739361321
Джастин Дрейк рассказывает о масштабировании с помощью SNARK и собственных накопительных пакетов: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
Что еще нужно сделать и каковы компромиссы?
Существует три стратегии расширения L1, которые можно выполнять индивидуально или параллельно:
Улучшите методы (например, клиентский код, клиенты без отслеживания состояния, срок действия истории), чтобы упростить проверку L1, а затем увеличьте лимиты газа.
Сократите затраты на конкретные операции и увеличьте среднюю мощность без увеличения риска наихудшего сценария;
Собственные накопительные пакеты (т. е. создание N параллельных копий EVM).
Понимая эти различные технологии, мы обнаружим, что существуют разные компромиссы. Например, собственные накопительные пакеты страдают от многих тех же недостатков компонуемости, что и простые накопительные пакеты: вы не можете отправить одну транзакцию для синхронного выполнения операций в нескольких накопительных пакетах, как это можно сделать в рамках контракта на одном и том же уровне L1 (или L2). способ. Повышение ограничения газа подорвет другие преимущества, которых можно достичь за счет упрощения проверки L1, например, увеличение доли пользователей, использующих проверяющие узлы, и увеличение количества одиночных стейкеров. В зависимости от реализации удешевление конкретных операций в EVM (виртуальной машине Ethereum) может увеличить общую сложность EVM.
Большой вопрос, на который должна ответить любая дорожная карта масштабирования L1: каково окончательное видение L1 и L2? Очевидно, что помещать все на L1 нелепо: потенциальные варианты использования могут включать сотни тысяч транзакций в секунду, что сделает L1 совершенно непроверяемым (если мы не выберем собственный маршрут Rollup). Но нам нужны некоторые рекомендации, чтобы гарантировать, что мы не попадем в ситуацию, когда 10-кратное увеличение газовой шапки серьезно повредит децентрализации Ethereum L1.
Взгляд на разделение труда между L1 и L2
Как мне взаимодействовать с другими частями дорожной карты?
Привлечение большего количества пользователей в L1 означает не только улучшение масштабирования, но и улучшение других аспектов L1. Это означает, что больше MEV останется на уровне L1 (а не будет просто проблемой L2), поэтому необходимость явной обработки MEV станет более актуальной. Это значительно увеличит ценность быстрых слотов на L1. В то же время это также во многом зависит от плавного хода проверки L1 (The Verge).
Рекомендуемое чтение: (Новая статья Виталика: Возможное будущее Ethereum, слияние)
