В начале у Ethereum были две стратегии масштабирования в своей дорожной карте. Одна (например, см. этот ранний бумагас 2015 года) было «шардирование»: вместо проверки и хранения всех транзакций в цепочке каждому узлу было бы достаточно проверить и хранить лишь небольшую долю транзакций. Точно так же работает любая другая сеть пирингового взаимодействия (например, BitTorrent), так что, безусловно, мы могли бы добиться того же эффекта в работе блокчейнов. Другим решением были протоколы уровня 2: сети, которые могли бы располагаться поверх Ethereum таким образом, чтобы в полной мере пользоваться его безопасностью, сохраняя при этом основную часть данных и вычислений вне главной цепи. «Протоколы уровня 2» подразумевали каналы состоянияв 2015 году, Плазмав 2017 году, а затемrollupsв 2019 году Rollups более мощные, чем каналы состояния или Plasma, но им требуется большой объем полосы пропускания данных on-chain. К счастью, к 2019 году исследования по шардингу решилипроблема проверки «доступности данных» в масштабе. В результате две дороги сошлись, и мы получили дорожная карта, ориентированная на rollupкоторая остается стратегией масштабирования Ethereum и по сегодняшний день.

Всплеск, редакция дорожной карты 2023 года.

Дорожная карта, ориентированная на роллап, предлагает простое разделение труда: Ethereum L1 сосредотачивается на том, чтобы быть надежным и децентрализованным базовым уровнем, в то время как L2 берут на себя задачу помощи экосистеме в масштабировании. Это шаблон, который повторяется повсюду в обществе: судебная система (L1) не предназначена для того, чтобы быть ультра-быстрой и эффективной, она существует для защиты контрактов и прав собственности, и предпринимателям (L2) приходится строить на этом сверху.надежныйбазаслойи доставить человечество на (метафорическую и буквальную) Марс.

В этом году дорожная карта, ориентированная на роллапы, имела важные успехи: пропускная способность данных Ethereum L1 значительно увеличилась сEIP-4844 блобы, и теперь существуют несколько EVM rollupsна этапе 1. Очень гетерогенная и плюралистическая реализация шардинга, где каждый уровень L2 действует как «щард» со своими собственными внутренними правилами и логикой, теперь является реальностью. Но, как мы видели, пройдя этот путь, у нас возникают собственные уникальные проблемы. Итак, наша задача сейчас - завершить дорожную карту, ориентированную на роллапы, и решить эти проблемы, сохраняя при этом надежность и децентрализацию, делающие Ethereum L1 особенным.

The Surge: ключевые цели

• 100,000+ TPS на L1+L2
• Сохраните децентрализацию и надежность L1
• По крайней мере, некоторые L2 полностью наследуют основные свойства Ethereum (недоверительные, открытые, устойчивые к цензуре)
• Максимальная совместимость между L2. Ethereum должен чувствовать себя как одна экосистема, а не как 34 разных блокчейна.

В этой главе

• К слову: трилемма масштабируемости
• Дальнейшие успехи в выборке данных о доступности
• Сжатие данных
• Обобщенная Plasma
• Совершенствующиеся системы доказательств L2
• Межслоевая интероперабельность и улучшения пользовательского опыта
• Масштабирование исполнения на уровне L1

Кстати: трилемма масштабируемости

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

Особенно следует отметить, что трилемма не является теоремой, и в сообщении, вводящем трилемму, не приводится математическое доказательство. Однако в нем представлено эвристическое математическое объяснение: если узел, дружественный к децентрализации (например, потребительский ноутбук), может проверять N транзакций в секунду, и у вас есть цепь, обрабатывающая k*N транзакций в секунду, то либо (i) каждая транзакция видна только 1/k узлам, что подразумевает, что злоумышленнику достаточно скомпрометировать несколько узлов, чтобы провести плохую транзакцию, либо (ii) ваши узлы будут мощными, и ваша цепь не будет децентрализованной. Цель сообщения никогда не была в том, чтобы показать, что нарушить трилемму невозможно; скорее, она была в том, чтобы показать, что нарушить трилемму сложно - для этого нужно как-то думать за пределами рамок, которые подразумевает аргумент.

На протяжении многих лет было обычным делом, что некоторые высокопроизводительные цепочки утверждали, что они решают трилемму, не предпринимая ничего умного на фундаментальном уровне архитектуры, обычно используя хитрости программной инженерии для оптимизации узла. Это всегда вводит в заблуждение, и запуск узла в таких цепочках всегда оказывается намного сложнее, чем в Ethereum. Этот постзатрагивает некоторые из множества тонкостей, почему это так (и, следовательно, почему только разработка клиентского программного обеспечения L1 не может масштабировать сам Ethereum).

Тем не менее, комбинация выборки доступности данных и SNARK решает трилемму: она позволяет клиенту убедиться в том, что некоторое количество данных доступно, и некоторое количество шагов вычислений было выполнено правильно, загружая при этом только небольшую часть этих данных и выполняя гораздо меньший объем вычислений. SNARK не требуют доверия. Выборка доступности данных имеет нюансы модель доверия few-of-N, но он сохраняет основное свойство не масштабируемых цепочек, которое заключается в том, что даже атака на 51% не может принудить сеть к принятию недоброкачественных блоков.

Еще одним способом решения этой трилеммы являются архитектуры Plasma, которые используют умные методы, чтобы переложить ответственность за наблюдение за доступностью данных на пользователя способом, совместимым с стимулами. В 2017-2019 годах, когда все, что нам нужно было для масштабирования вычислений, — это защита от мошенничества, Plasma была очень ограничена в том, что она могла безопасно делать, но внедрение SNARK делает архитектуры Plasma гораздо более жизнеспособныйдля более широкого спектра случаев использования, чем раньше.

Дальнейший прогресс в выборке доступности данных

Какую проблему мы решаем?

Как на 13 марта 2024 года, когдаОбновление Dencunпошел в эфир, у блокчейна Ethereum есть три ~125 кБ «блоба» на каждый 12-секундный слот, или ~375 кБ на слот пропускной способности для доступа к данным. Предполагая, что данные транзакций публикуются onchain непосредственно, передача ERC20 составляет ~180 байт, и поэтому максимальная TPS роллапов на Ethereum:

375000 / 12 / 180 = 173,6 Т/с

Если мы добавим каллдату Ethereum (теоретический максимум: 30 миллионов газа за слот / 16 газа на байт = 1,875,000 байтов за слот), это станет равным 607 TPS. С PeerDAS план заключается в увеличении целевого количества блобов до 8-16, что даст нам 463-926 TPS в каллдате.

Это значительное увеличение по сравнению с Ethereum L1, но этого недостаточно. Мы хотим гораздо большей масштабируемости. Наша цель в среднесрочной перспективе - 16 МБ в слот, что в сочетании с улучшениями в сжатии данных rollup даст нам ~58 000 TPS.

Что это и как это работает?

PeerDAS - это относительно простая реализация «1D-выборки». Каждый блоб в Ethereum представляет собой многочлен степени 4096 над простым полем из 253 бит. Мы транслируем «доли» этого многочлена, где каждая доля состоит из 16 оценок в смежных 16 координатах, взятых из общего набора из 8192 координат. Любые 4096 из 8192 оценок (с текущими предложенными параметрами: любые 64 из 128 возможных выборок) могут восстановить блоб.

PeerDAS работает так, что каждый клиент слушает небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого блоба, и дополнительно запрашивает блобы на других подсетях, которые ему нужны, обращаясь к своим сверстникам в глобальной p2p-сети (которые также слушают другие подсети). Более консервативная версия, SubnetDAS, использует только механизм подсети, без дополнительного уровня запроса одноранговых узлов. В настоящее время предлагается использовать SubnetDAS для узлов, участвующих в Proof of Stake, а для других узлов (т.е. "clients") для использования PeerDAS.

Теоретически мы можем масштабировать 1D выборку довольно далеко: если мы увеличим максимальное количество блобов до 256 (таким образом, цель до 128), то мы достигнем нашей цели в 16 МБ, в то время как выборка доступности данных будет стоить каждому узлу всего 16 выборок128 блобов512 байт на образец на блоб = 1 МБ пропускной способности данных на слот. Это едва укладывается в нашу терпимость: это выполнимо, но это означало бы, что клиенты с ограниченной пропускной способностью не смогут отбирать образцы. Мы могли бы оптимизировать это немного, уменьшив количество блобов и увеличив размер блоба, но это сделало бы восстановление более дорогостоящим.

И в конечном итоге мы хотим пойти дальше и сделать2D сэмплирование, который работает по принципу случайной выборки не только в пределах блобов, но и между блобами. Линейные свойства обязательств KZG используются для «расширения» набора блобов в блоке с помощью списка новых «виртуальных блобов», которые избыточно кодируют ту же информацию.

2D сэмплирование. Источник: a16z крипто

Важно, что вычисление расширения обязательств не требует наличия блобов, поэтому схема фундаментально дружественна к распределенной конструкции блоков. Узел, фактически строящий блок, должен иметь только обязательства блоба KZG и может полагаться на DAS для проверки доступности блобов. 1D DAS также по своей сути дружественен к распределенной конструкции блоков.

Какие есть ссылки на существующие исследования?

• Оригинальный пост, в котором представлена информация о доступности данных (2018): https://github.com/ethereum/research/wiki/Примечание-о-доступности-данных-и-кодировании-стирания
• Следующая статья: 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-components/16541 , и бумага: https://eprint.iacr.org/2024/1362
• Презентация о PeerDAS от Франческо: https://www.youtube.com/watch?v=WOdpO1tH_Us
• 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 в пользу квантово-устойчивой альтернативы без доверенной настройки. В настоящее время мы не знаем кандидатов, которые дружелюбны к распределенному построению блоков. Даже дорогостоящая техника "грубой силы" использования рекурсивных STARKs для генерации доказательств достоверности для восстановления строк и столбцов не подходит, потому что, хотя технически STARK имеет размер O(log(n) * log(log(n)) хэшей (сРАЗМЕШИВАТЬ) на практике STARK почти так же большой, как весь блоб.

Реалистичные пути, которые я вижу на долгосрочную перспективу, это:

• Реализовать идеальный 2D DAS
• Stay with 1D DAS, sacrificing sampling bandwidth efficiency and accepting a lower data cap for the sake of simplicity and robustness
• (Жесткий поворот) отказаться от DA и полностью принять Plasma как основную архитектуру уровня 2, на которую мы сосредотачиваемся

Мы можем рассматривать их вдоль спектра компромисса:

Обратите внимание, что такой выбор существует даже в случае, если мы решим масштабировать выполнение на L1 напрямую. Это потому, что если L1 должен обрабатывать много TPS, блоки L1 станут очень большими, и клиенты захотят эффективный способ подтвердить их правильность, поэтому нам придется использовать ту же технологию, которая поддерживает rollups (ZK-EVM и DAS) на L1.

Как оно взаимодействует с другими частями дорожной карты?

Потребность в 2D DAS отчасти уменьшается, или по крайней мере откладывается, если применяется сжатие данных (см. ниже), и это уменьшается еще больше, если широко используется Plasma. DAS также представляет собой вызов для протоколов и механизмов распределенного построения блоков: хотя DAS в теории дружелюбен к распределенной реконструкции, это необходимо сочетать на практике ссписок включенияпредложения и механика выбора вилок, окружающих их.

Сжатие данных

Какую проблему мы решаем?

Каждая транзакция в роллапе занимает значительный объем пространства данных в цепочке: передача ERC20 занимает около 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов уровня 2. При 16 МБ на слот мы получаем:

16000000 / 12 / 180 = 7407 TPS

Что, если помимо решения числителя, мы также можем решить знаменатель и сделать так, чтобы каждая транзакция в rollup занимала меньше байтов onchain?

Что это и как это работает?

Лучшее объяснение на мой взгляд эта диаграммаиз двух лет назад:

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

• Агрегация подписей - мы переходим от подписей ECDSA к подписям BLS, у которых есть свойство, что множество подписей можно объединить в одну подпись, подтверждающую действительность всех исходных подписей. Это не рассматривается для L1, потому что вычислительные затраты на верификацию, даже с агрегацией, выше, но в среде с недостаточными данными, вроде L2s, это, вероятно, имеет смысл. Функция агрегации ERC-4337представляет один путь для реализации этого.
• Замена адресов указателями - если адрес использовался ранее, мы можем заменить 20-байтовый адрес 4-байтовым указателем на местоположение в истории. Это необходимо для достижения наибольших выгод, хотя для реализации требуется усилий, поскольку это требует (по крайней мере, части) истории блокчейна, чтобы эффективно стать частью состояния.
• Пользовательская сериализация для значений транзакций - большинство значений транзакций имеют очень немного цифр, например, 0.25 ETH представляется как 250,000,000,000,000,000 вэй. Максимальные базовые сборы газа и приоритетные сборы работают аналогично. Таким образом, мы можем представлять большинство валютных значений очень компактно с использованием пользовательского десятичного формата с плавающей запятой или даже словаря особенно распространенных значений.

Какие есть ссылки на существующие исследования?

• Исследование из sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• Контракты, оптимизированные для Calldata для L2s, от ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• Альтернативная стратегия - роллапы на основе доказательств действительности (так называемые ZK роллапы) публикуют различия состояний вместо транзакций: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• BLS кошелек - реализация агрегации BLS через ERC-4337: https://github.com/getwax/bls-wallet

Что осталось сделать, и какие компромиссы?

Основное, что осталось сделать, это фактически реализовать вышеуказанные схемы. Основные компромиссы:

• Переход на подписи BLS требует значительных усилий и снижает совместимость с доверенными аппаратными чипами, которые могут повысить безопасность. Для замены этого можно использовать оболочку ZK-SNARK для других схем подписи.
• Динамическое сжатие (например, замена адресов указателями) усложняет клиентский код.
• Публикация различий состояний на цепочку вместо транзакций снижает проверяемость и делает неработоспособным множество программного обеспечения (например, блок-эксплореров).

Как оно взаимодействует с другими частями дорожной карты?

Принятие ERC-4337 и, в конечном итоге, увековечение частей этого стандарта в L2 EVM может значительно ускорить внедрение техник агрегации. Увековечение частей ERC-4337 на L1 может ускорить его внедрение на L2.

Generalized Plasma

Какую проблему мы решаем?

Даже с блоками объемом 16 МБ и сжатием данных 58 000 TPS не обязательно достаточно для полного захвата потребительских платежей, децентрализованных социальных сетей или других секторов с высокой пропускной способностью, и это становится особенно верным, если мы начнем учитывать конфиденциальность, что может снизить масштабируемость на 3-8 раз. Для приложений с высоким объемом и низкой стоимостью один из вариантов сегодня - это validium , который хранит данные вне цепи блоков и имеет интересную модель безопасности, при которой оператор не может украсть средства пользователей, но может исчезнуть и временно или постоянно заморозить все средства пользователей. Но мы можем поступить лучше.

Что это и как оно работает?

Plasma — это решение для масштабирования, которое включает в себя оператор, публикующий блоки вне блокчейна и помещающий корни Меркла этих блоков в блокчейн (в отличие от роллапов, где весь блок помещается в блокчейн). Для каждого блока оператор отправляет каждому пользователю ветвь Меркла, доказывающую, что произошло или не произошло с активами этого пользователя. Пользователи могут вывести свои активы, предоставив филиал Merkle. Важно отметить, что эта ветка не обязательно должна быть укоренена в последнем состоянии - по этой причине, даже если доступность данных не работает, пользователь все равно может восстановить свои активы, удалив последнее доступное состояние. Если пользователь отправляет недействительную ветку (например, выход из актива, который он уже отправил кому-то другому, или сам оператор создает актив из воздуха), механизм ончейн-оспаривания может вынести решение о том, кому актив принадлежит по праву.

Диаграмма цепи Plasma Cash. Транзакции, расходующие монету i, помещаются в i-ю позицию в дереве. В этом примере, предполагая, что все предыдущие деревья действительны, мы знаем, что сейчас у Ивы есть монета 1, у Дэвида - монета 4, а у Джорджа - монета 6.

Ранние версии Plasma могли обрабатывать только случаи использования платежей и не могли эффективно обобщить их. Однако, если требуется, чтобы каждый корень был подтвержден с помощью SNARK, Plasma становится намного мощнее. Каждая игра-вызов может быть значительно упрощена, потому что мы убираем большинство возможных путей для манипуляции оператора. Также открываются новые пути для расширения техник Plasma на более общий класс активов. Наконец, в случае, если оператор не манипулирует, пользователи могут мгновенно вывести свои средства, не дожидаясь однотедельного периода вызова.

Один из способов (и не единственный способ) создать плазменную цепь EVM: использовать ZK-SNARK для построения параллельного дерева UTXO, отражающего изменения баланса, сделанные EVM, и определяющего уникальное сопоставление того, что является «тем же монета» в разные исторические периоды. Затем на этом можно построить конструкцию Plasma.

Одна из ключевых идей заключается в том, что система Plasma не обязательно должна быть идеальной. Даже если вы можете защитить только часть активов (например, даже только монеты, которые не двигались на прошлой неделе), вы уже значительно улучшили статус-кво ультрамасштабируемого EVM, который является валидиумом.

Другой класс конструкций - гибридные плазменные / роллапы, такие как Интмакс. Эти конструкции помещают очень небольшое количество данных на пользователя onchain (например, 5 байт), и таким образом, получают свойства, которые находятся где-то между plasma и rollups: в случае Intmax вы получаете очень высокий уровень масштабируемости и конфиденциальности, хотя даже в мире 16 МБ ёмкость теоретически ограничена примерно до 16,000,000 / 12 / 5 = 266,667 TPS.

Какие есть ссылки на существующие исследования?

• Оригинальная статья о Plasma: https://plasma.io/plasma-deprecated.pdf
• Плазма Кэш: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Плазменный Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-Выход
• Intmax (2023): https://eprint.iacr.org/2023/1082

Что осталось сделать, и какие компромиссы?

Основная оставшаяся задача - запустить системы Plasma в производство. Как упоминалось ранее, «плазма против валидиума» не является бинарной: любой валидиум может улучшить свои безопасные свойства хотя бы немного, добавив функции Plasma в механизм выхода. Часть исследований заключается в получении оптимальных свойств (с точки зрения требований к доверию, стоимости газа L1 в худшем случае и уязвимости для DoS) для EVM, а также альтернативных прикладных конструкций. Кроме того, необходимо непосредственно решить большую концептуальную сложность Plasma по сравнению с роллапами, как через исследования, так и через создание лучших обобщенных фреймворков.

Основным компромиссом в использовании дизайнов Plasma является то, что они зависят больше от операторов и сложнее создавать.”основанный“, хотя гибридные конструкции плазма/роллап часто могут избежать этого недостатка.

Как она взаимодействует с другими частями дорожной карты?

Чем более эффективными могут быть решения Plasma, тем меньше давления на L1 в плане функциональности высокопроизводительной доступности данных. Перенос активности на L2 также снижает давление MEV на L1.

Зрелые системы доказательств L2

Какую проблему мы решаем?

Сегодня большинство роллапов еще не являются действительно безопасными; существует совет по безопасности, который имеет возможность переопределить поведение (оптимистичное или валидное)Система проверки. В некоторых случаях система доказательств вообще не работает, а если и работает, то имеет только «рекомендательную» функцию. Дальше всего впереди находятся (i) несколько специфичных для приложения роллапов, таких как Fuel, которые не требуют доверия, и (ii) на момент написания этой статьи Optimism и Arbitrum, два роллапа с полным EVM, которые достигли вехи частичного отсутствия доверия, известной как «стадия 1». Причина, по которой роллапы не пошли дальше, заключается в опасениях по поводу ошибок в коде. Нам нужны ненадежные роллапы, и поэтому мы должны решить эту проблему в лоб.

Что это и как это работает?

Сначала давайте вспомним систему «stage», впервые представленную вЭтот пост. Существуют более подробные требования, но в общем:

• Этап 0: пользователь должен иметь возможность запустить узел и синхронизировать цепь. Нормально, если проверка полностью доверяется/централизована.
• Этап 1: должна существовать (бесповерочная) система доказательств, которая гарантирует, что принимаются только допустимые транзакции. Допускается наличие совета безопасности, который может отменить систему доказательств, но только при голосовании с порогом 75%. Кроме того, кворум-блокирующая часть совета (то есть 26%+) должна быть вне основного здания компании, разрабатывающей rollup. Механизм обновления с более слабыми функциями (например, DAO) допускается, но он должен иметь задержку, достаточно длинную, чтобы пользователи могли вывести свои средства, если он утвердит злонамеренное обновление, прежде чем оно войдет в действие.
• Этап 2: должна существовать (не требующая доверия) система доказательства, которая гарантирует, что принимаются только действительные транзакции. Советы безопасности могут вмешиваться только в случае доказуемых ошибок в коде, например. если две избыточные системы доказательств не согласуются друг с другом или если одна система доказательств принимает два разных корня пост-состояния для одного и того же блока (или ничего не принимает в течение достаточно длительного периода времени, например, недели). Механизм обновления допускается, но он должен иметь очень длительную задержку.

Цель - достичь этапа 2. Основной вызов при достижении этапа 2 - получить достаточное доверие к тому, что система доказательств действительно достаточно надежна. Существует два основных способа сделать это:

• Формальная верификация: мы можем использовать современные математические и вычислительные техники, чтобы доказать, что система доказательств (оптимистичных или допустимости) принимает только блоки, которые проходят спецификацию EVM. Такие техники существуют десятилетиями, но недавние достижения, такие как Lean 4сделали их намного более практичными, и прогресс в AI-помощи в доказательстве потенциально может ускорить эту тенденцию дальше.
• Мульти-доказательства: создавайте несколько систем доказательств и размещайте средства в мультисигнатурный кошелек 2 из 3 (или более) между этими системами доказательств и советом по безопасности (и/или другим гаджетом с доверительными предположениями, например, ТEEs). Если системы доказательств согласны, совет по безопасности не имеет власти; если они не согласны, совет по безопасности может только выбрать одну из них, он не может односторонне навязать свой ответ.

Стилизованная диаграмма мультидоказательства, сочетающая в себе одну систему оптимистических доказательств, одну систему доказательств валидности и совет безопасности.

Какие есть ссылки на существующие исследования?

• Семантика EVM K (формальная верификация работа с 2017 года): https://github.com/runtimeverification/evm-semantics
• Презентация идеи мульти-доказателей (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
• Taiko планирует использовать мультипробы: https://docs.taiko.xyz/core-concepts/multi-proofs/

Что осталось сделать, и какие компромиссы?

Для формальной верификации много. Нам нужно создать формально верифицированную версию полного доказателя SNARK EVM. Это невероятно сложный проект, хотя это один изМы уже начали. Есть одна хитрость, которая значительно упрощает задачу: мы можем сделать формально верифицированный SNARK прувер минимальной виртуальной машины, например. RISC-VилиКаир, а затем написать реализацию EVM на этой минимальной виртуальной машине (и формально доказать ее эквивалентность какой-либо другой спецификации EVM).

Для многообещающих субъектов остались две основные составляющие. Во-первых, нам нужно иметь достаточное доверие как минимум к двум различным системам доказательств, чтобы быть уверенными в их отдельной безопасности и в том, что если они сломаются, то по разным и независимым причинам (таким образом, они не сломаются одновременно). Во-вторых, нам нужно обеспечить очень высокий уровень уверенности в основной логике, объединяющей системы доказательств. Это намного меньший кусок кода. Есть способы сделать его крайне компактным - просто хранить средства в Безопасный мультиподписной контракт Подписантами которых являются контракты, представляющие отдельные системы доказательства, но это имеет компромисс в виде высоких затрат на газ в сети. Необходимо найти баланс между эффективностью и безопасностью.

Как оно взаимодействует с другими частями дорожной карты?

Перенос активности на L2 снижает давление MEV на L1.

Улучшения взаимодействия между уровнями L2

Какую проблему мы решаем?

Одна из основных проблем с экосистемой L2 сегодня заключается в том, что пользователям сложно в ней ориентироваться. Более того, самые простые способы сделать это часто повторно вводят доверие: централизованные мосты, RPC-клиенты и так далее. Если мы серьезно относимся к идее, что L2 являются частью Ethereum, нам нужно сделать использование экосистемы L2 похожим на использование унифицированной экосистемы Ethereum.

Пример патологически плохого (и даже опасного: лично я потерял 100 долларов из-за ошибки выбора цепи здесь) пользовательского опыта межуровневого взаимодействия - хотя это не вина Polymarket, взаимодействие между уровнями должно быть ответственностью кошельков и сообщества стандартов Ethereum (ERC). В хорошо функционирующей экосистеме Ethereum отправка монет с L1 на L2 или из одного L2 в другой должна чувствовать себя так же, как отправка монет в пределах того же L1.

Что это и как это работает?

Существует множество категорий улучшений взаимодействия между уровнями L2. В общем, чтобы придумать это, нужно заметить, что теоретически Ethereum, ориентированный на роллап, — это то же самое, что и шардинг выполнения L1, а затем спросите, где текущая вторичная эфирная вселенная Ethereum не соответствует этому идеалу на практике. Вот несколько примеров:

• Адреса, специфичные для цепочки: цепочка (L1, Optimism, Arbitrum...) должна быть частью адреса. После внедрения этого могут быть реализованы потоки отправки между L2, просто поместив адрес в поле "отправить", на этом этапе кошелек может определить, как выполнить отправку (включая использование протоколов моста) в фоновом режиме.
• Запросы на оплату для конкретной цепи: должно быть легко и стандартизированно создавать сообщение формата "отправь мне X токенов типа Y на цепи Z". У этого есть два основных случая использования: (i) платежи, будь то от человека к человеку или от человека к сервису-торговцу, и (ii) запросы dapps на средства, например, приведенный выше пример Polymarket.
• Обмен криптовалютами между разными блокчейнами и оплата газа: должен существовать стандартизированный открытый протокол для выражения операций между разными блокчейнами, таких как «Я отправляю 1 ETH на Optimism тому, кто отправит мне 0,9999 ETH на Arbitrum» и «Я отправляю 0,0001 ETH на Optimism тому, кто включит эту транзакцию на Arbitrum».ERC-7683это одна попытка бывшего, иRIP-7755 это одна попытка последнего, хотя оба также более общие, чем только эти конкретные случаи использования.
• Легкие клиенты: пользователи должны иметь возможность фактически проверять цепочки, с которыми они взаимодействуют, а не просто доверять поставщикам RPC. A16z крипто ГелиосЭто делает для самого Ethereum, но нам нужно распространить это безопасное доверие на уровни L2.ERC-3668 (CCIP-чтение)это одна из стратегий для этого.

Как легкий клиент может обновить свое представление о цепи заголовков Ethereum. Как только у вас есть цепь заголовков, вы можете использовать доказательства Merkle для проверки любого объекта состояния. И как только у вас есть правильные объекты состояния L1, вы можете использовать доказательства Merkle (и, возможно, подписи, если вы хотите проверить предварительные подтверждения) для проверки любого объекта состояния на L2. Helios уже это делает. Расширение до последнего является вызовом стандартизации.

• Кошельки Keystore: сегодня, если вы хотите обновить ключи, которые управляют вашим кошельком смарт-контракта, вы должны сделать это на всех N цепочках, в которых существует этот кошелек. Кошельки хранилища ключей — это метод, который позволяет ключам существовать в одном месте (либо на L1, либо позже, возможно, на L2), а затем считываться с любого L2, имеющего копию кошелька. Это означает, что обновления должны выполняться только один раз. Чтобы быть эффективными, кошельки хранилища ключей требуют, чтобы L2 имели стандартизированный способ бесплатного чтения L1; Для этого есть два предложения L1SLOADиREMOTESTATICCALL.

Стилизованная схема работы кошельков keystore.

• Более радикальные идеи "общего токен-моста": представьте мир, где все L2 являются свидетельствами доказательства правильности, которые фиксируются в Ethereum каждый слот. Даже в этом мире перемещение активов с одного L2 на другой L2 "естественным образом" потребовало бы вывода и внесения депозита, что требует значительного количества газа L1. Один из способов решить эту проблему - создать общий минимальный роллап, единственной функцией которого было бы поддерживать балансы того, сколько токенов какого типа принадлежит какому L2, и позволить этим балансам обновляться массово с помощью серии операций отправки между L2, инициированных любым из L2. Это позволило бы производить переводы между L2 без необходимости платить газ L1 за каждый перевод и без необходимости использования методов на основе поставщиков ликвидности, таких как ERC-7683.
• Синхронная компонуемость: позволяет выполнять синхронные вызовы либо между определенными L2 и L1, либо между несколькими L2. Это может быть полезно для повышения финансовой эффективности протоколов DeFi. Первое может быть выполнено без какой-либо перекрестной координации L2; Последнее потребовало бы общая последовательность.Основанные роллапыавтоматически дружелюбны ко всем этим техникам.

Какие есть ссылки на существующие исследования?

• Адреса, специфичные для цепочки: 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
• Дизайн кошелька Scroll Keystore: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Гелиос: https://github.com/a16z/helios
• ERC-3668 (иногда называемый CCIP-read): 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 включала бы ускорение этих технологий верификации.

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

• ЕОФ - новый формат байт-кода EVM, более дружественный к статическому анализу, что позволяет быстрее реализовывать его. Для учета этой эффективности можно было бы снизить затраты на газ с помощью байт-кода EOF.
• Многомерная ценообразование газаустановка отдельных базовых сборов и ограничений для вычислений, данных и хранения может увеличить среднюю мощность Ethereum L1 без увеличения его максимальной мощности (и, следовательно, создания новых рисков безопасности).
• Снизить газовые издержки определенных операций и предварительных компиляций - исторически у нас былинесколько раундыизувеличение Газ стоимостьдля определенных операций, цена которых была занижена, чтобы избежать атак отказа в обслуживании. То, чего у нас было меньше, и что можно сделать гораздо больше, - это снижение стоимости газа для операций, цена которых завышена. Например, сложение намного дешевле умножения, но стоимость операций ADD и MUL в настоящее время одинакова. Мы могли бы сделать ADD дешевле, а даже более простые операции, такие как PUSH, еще дешевле.
• EVM-MAXиSIMD: EVM-MAX («модульные арифметические расширения») - это предложение, позволяющее более эффективную нативную математику с большими числами в виде отдельного модуля EVM. Значения, вычисленные при вычислениях EVM-MAX, могут быть доступны только другими опкодами EVM-MAX, если они не будут специально экспортированы; это позволяет больше места для хранения этих значений в оптимизированные форматыSIMD («одиночная инструкция множественные данные») - это предложение, позволяющее эффективно выполнять одну и ту же инструкцию над массивом значений. Вместе они могут создать мощное копроцессорнаряду с EVM, который можно использовать для намного более эффективной реализации криптографических операций. Это было бы особенно полезно для протоколов конфиденциальности и для систем доказательств L2, поэтому это поможет как масштабированию L1, так и L2.

Эти улучшения будут обсуждаться более подробно в будущем сообщении на Splurge.

Наконец, третья стратегия - это родные роллапы (или "увековеченные роллапы"): в основном, создание множества копий EVM, которые работают параллельно, приводя к модели, эквивалентной тому, что могут предоставить роллапы, но намного более интегрированной в протокол.

Какие есть ссылки на существующие исследования?

• Дорожная карта масштабирования 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
• EOF: 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
• Джастин Дрейк о использовании SNARKs и нативных роллапов для масштабирования: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

Что осталось сделать, и какие компромиссы?

Существует три стратегии масштабирования L1, которые могут быть осуществлены индивидуально или параллельно:

• Улучшить технологии (например, клиентский код, бессостоятельные клиенты, истекшие истории) для упрощения проверки L1, а затем увеличить лимит газа
• Делайте определенные операции дешевле, увеличивая среднюю мощность без увеличения рисков в крайнем случае.
• Нативные роллапы (т.е. "создание N параллельных копий EVM", хотя, возможно, предоставляют разработчикам много гибкости в параметрах копий, которые они развертывают)

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

Большой вопрос, который должна ответить любая дорожная карта масштабирования L1, заключается в следующем: какова конечная цель того, что должно находиться на L1, а что - на L2? Очевидно, что абсурдно помещать все на L1: потенциальные случаи использования подразумевают сотни тысяч транзакций в секунду, и это сделало бы L1 полностью невозможным для проверки (если мы не выберем маршрут нативного rollup). Но нам действительно нужен какой-то принцип, чтобы убедиться, что мы не создаем ситуацию, при которой мы увеличиваем газовый лимит в 10 раз, серьезно ущемляем децентрализацию Ethereum L1 и обнаруживаем, что мы лишь перешли к миру, где вместо того, чтобы 99% активности находилось на L2, 90% активности находится на L2, и результат в целом выглядит практически таким же, за исключением необратимой потери большей части того, что делает Ethereum L1 особенным.

Одно из предполагаемых видений "разделения труда" между L1 и L2.источник.

Как она взаимодействует с другими частями дорожной карты?

Привлечение большего количества пользователей на L1 подразумевает улучшение не только масштаба, но и других аспектов L1. Это означает, что больше MEV останется на L1 (в отличие от того, чтобы стать проблемой только для L2), и поэтому будет еще более настоятельной необходимостью обращаться к этому явно. Это значительно увеличивает ценность быстрых слотов на L1. И это также в значительной степени зависит от успешной верификации L1 («Verge»).

Отказ от ответственности:

1. Эта статья взята из [ Виталик Бутерин], Все авторские права принадлежат оригинальному автору [Виталик Бутерин]. Если есть возражения против этого переиздания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно решат это.
2. Ответственность за отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.