Спикер: Виталик Бутерин, основатель Ethereum. Составитель: 0xxz, Golden Finance Недавно в Брюсселе прошел EthCC7. Организатор пригласил Виталика, основателя Ethereum, выступить с программной речью. Стоит отметить, что в 2024 году исполняется 10 лет со дня создания IC0 Эфириума. После выступления Виталика три основных основателя Эфириума — Виталик Бутерин, Джозеф Любин и Гэвин Вуд — снова сделали групповое фото, чтобы отметить это событие. Эта статья представляет собой программную речь, произнесенную Виталиком, основателем Ethereum, на недавней конференции EthCC7, составленную Golden Finance 0xxz. Усиление темы выступления L1: Оптимизация Ethereum, чтобы он стал высоконадежным, заслуживающим доверия и не требующим разрешений базовым слоем второго уровня.

Видение Эфириума Спектр
Я думаю, что существует целый спектр возможных различных разделений труда относительно роли, которую базовый уровень Ethereum может играть в экосистеме в течение следующих пяти-десяти лет. Вы можете думать об этом как о спектре слева направо. На левой стороне спектра он по сути пытается быть очень минималистичным базовым уровнем, который по сути просто действует как средство проверки доказательства для всех L2. Возможно, также предоставим возможность передавать ETH между разными L2. Но кроме этого, это в основном все. На правой стороне спектра в основном происходит переориентация на dApps, которые работают в основном на L1, а L2 используется только для некоторых очень специфических и высокопроизводительных транзакций. В середине спектра есть несколько интересных вариантов. Я поставил Ethereum в качестве базового слоя второго слева уровня L2. Я поместил крайнюю левую версию. Крайняя версия заключается в том, что мы полностью отказываемся от клиентской части Ethereum, оставляем только консенсусную часть и добавляем несколько валидаторов с нулевым разглашением, по сути превращая весь уровень исполнения в Rollup. Я имею в виду самые крайние варианты слева, а справа это может быть базовый слой, но также попытаться придать L2 больше функциональности. Одна из идей в этом направлении — дальнейшее сокращение времени подкачки Эфириума, которое в настоящее время составляет 12 секунд, а возможно, и до 2-4 секунд. На самом деле цель этого состоит в том, чтобы сделать объединение на основе базовых данных возможным в качестве основного способа работы L2. Итак, теперь, если вы хотите, чтобы L2 имел первоклассный пользовательский опыт, вам нужна собственная предварительная проверка, что означает либо централизованный сортировщик, либо собственный децентрализованный сортировщик. Если их консенсус ускорится, L2 больше не нужно будет это делать. Если вы действительно хотите повысить масштабируемость L1, то потребность в L2 также уменьшится. Итак, это спектр. На данный момент я в основном сосредотачиваюсь на второй версии слева, но то, что я предлагаю здесь, применимо и к другим видениям, и приведенные здесь советы на самом деле не мешают другим видениям. Это то, что я считаю очень важным. Преимущество надежности Ethereum
Большим преимуществом Ethereum является то, что он имеет большую и относительно децентрализованную экосистему ставок.

Левая часть изображения выше — это диаграмма скорости хэширования всех пулов для добычи биткойнов, а правая — диаграмма ставок Ethereum. Распределение вычислительной мощности Биткойна в настоящее время не очень хорошее. Два майнинговых пула в сумме составляют более 50% вычислительной мощности, а четыре майнинговых пула — более 75%. И ситуация с Эфириумом на самом деле лучше, чем показано на графике, потому что вторая большая часть серой части на самом деле неопознана, а это означает, что это может быть комбинация многих людей, и в ней может даже быть много независимых стейкеров. Синий Лидо на самом деле представляет собой странную, слабо скоординированную структуру, состоящую из 37 различных валидаторов. Итак, Ethereum на самом деле имеет относительно децентрализованную экосистему ставок, которая работает довольно хорошо. Мы можем многое улучшить в этой области, но я думаю, что признание этого факта все равно имеет смысл. Это одно из уникальных преимуществ, на которое мы действительно можем опираться.

К преимуществам надежности Ethereum также относятся: ● Наличие многоклиентской экосистемы: существуют клиенты исполнения Geth и клиенты, не использующие Geth, а доля клиентов исполнения, отличных от Geth, даже превышает долю клиентов исполнения Geth. Аналогичная ситуация возникает и в консенсусной клиентской системе. ● Международное сообщество: люди находятся во многих разных странах, включая проекты, L2, команды и т. д. ● Многоцентровая экосистема знаний: есть Ethereum Foundation и есть клиентские команды; даже такие команды, как команда Reth из Paradigm, в последнее время укрепляют свое лидерство в области открытого исходного кода; поэтому экосистема Ethereum как базовый уровень уже имеет эти очень мощные преимущества. Я думаю, что это что-то очень ценное, и от него нельзя так легко отказываться. Я бы даже сказал, что есть четкие шаги, которые можно предпринять для развития этих сильных сторон и даже устранения наших слабостей. В чем Ethereum L1 не соответствует высоким стандартам? Как его можно улучшить?
Вот опрос, который я провел на Farcaster около полугода назад: Если вы не занимаетесь соло-стейкингом, что мешает вам делать соло-стейкинг? Я могу повторить вопрос здесь: кто делает одиночные ставки? Без одиночной ставки, кто из вас считает, что порог в 32 ETH является самым большим препятствием, кто считает, что управление узлом слишком сложно, является самым большим препятствием, и кто считает, что самым большим препятствием является невозможность инвестировать свой ETH в Протокол DeFi одновременно? Кто считает, что самым большим препятствием является страх необходимости размещать закрытые ключи на работающем узле, где их будет легче украсть? Видно, что двумя главными согласованными препятствиями являются: минимальное требование в 32 ETH и сложность работы узла. Всегда важно это осознавать. Часто, когда мы начинаем копаться в том, как максимизировать возможность людей двойного использования своего обеспечения в протоколах DeFi, мы обнаруживаем, что существует большое количество людей, которые вообще не используют протоколы DeFi. Итак, давайте сосредоточимся на основных проблемах и на том, что мы можем сделать, чтобы попытаться их решить. Начните с запуска узла валидатора или, другими словами, начиная с порога в 32 ETH. На самом деле, эти два вопроса связаны между собой, поскольку оба они являются функцией количества валидаторов в Proof of Stake Ethereum. Сегодня у нас около 1 миллиона организаций-валидаторов, каждая из которых имеет на депозите 32 ETH, поэтому, если бы минимальное требование было изменено на 4 ETH, то у нас было бы 8 миллионов или, может быть, более 8 миллионов, может быть, 9 миллионов или 10 миллионов валидаторов. Если бы мы хотели сократить количество валидаторов до 100 000, минимальные требования, вероятно, увеличились бы примерно до 300 ETH. Итак, это компромисс. Эфириум исторически пытался быть в центре компромисса. Однако, если мы сможем найти какие-либо способы улучшить его, у нас появятся дополнительные очки статистики, которые мы можем при желании использовать для снижения минимальных требований или для упрощения работы узла. На самом деле, сейчас я думаю, что агрегирование сигнатур — это даже не основная сложность запуска узла. Вначале мы можем больше сосредоточиться на снижении минимальных требований, но в конечном итоге это затронет и то, и другое. Итак, есть два метода, которые могут улучшить эти два аспекта. Один из методов — разрешить ставку или обеспечить окончательность без необходимости подписи каждого валидатора.По сути, вам нужна какая-то случайная выборка из достаточного количества узлов для достижения значительной экономической безопасности. Сейчас, я думаю, у нас более чем достаточно экономической безопасности. Стоимость проведения атаки 51% в пересчете на количество урезанных ETH составляет одну треть от 32 миллионов ETH, что составляет около 11 миллионов ETH. Кто потратит 11 миллионов ETH, чтобы взломать блокчейн Ethereum? Никто, даже правительство США, этого не хочет. Эти методы отбора проб аналогичны тому, что если бы у вас был дом, входная дверь которого была защищена четырьмя слоями стали, но окно представляло собой всего лишь кусок некачественного стекла, который кто-то мог бы легко разбить бейсбольной битой. Я думаю, что Ethereum в какой-то степени похож на это: если вы хотите провести атаку 51%, вам придется потерять 11 миллионов ETH. Но на самом деле существует множество других способов атаковать протокол, и нам действительно следует еще больше укреплять эту защиту. Вместо этого, если у вас есть подмножество валидаторов, выполняющих окончательность, протокол по-прежнему достаточно безопасен, и вы действительно можете повысить уровень децентрализации. Второй метод — лучшая агрегация сигнатур. Вы могли бы сделать что-то продвинутое, например Starks, и вместо поддержки 30 000 подписей на слот мы могли бы со временем поддерживать больше подписей. Это первая часть. Вторая часть — упростить запуск узлов. Первым шагом является истечение срока действия истории. На самом деле, EIP-4444, в этом отношении достигнут большой прогресс. Второй шаг — клиент без сохранения состояния. Verkle существует уже давно, другой возможный вариант — создать двоичное хэш-дерево, такое как Poseidon, дружественную для Старка хэш-функцию. После этого для проверки блоков Ethereum вам больше не понадобится жесткий диск. Вы также можете позже добавить ZKVM типа 1, который может проверять целые блоки Ethereum, чтобы вы могли проверять блоки Ethereum произвольного размера, загружая данные или даже данные выборки доступности данных, и тогда вам нужно будет проверить только одно доказательство. Если вы это сделаете, запуск узла станет проще. Одна из очень раздражающих вещей в настоящее время с клиентами без сохранения состояния заключается в том, что если вы хотите изменить настройки оборудования или программного обеспечения, обычно вам нужно либо начать с нуля и потерять день, либо вам нужно сделать что-то очень опасное и сложить ключи пополам. будет где-то прорезано, и если у нас клиент без состояния, то больше этого делать не нужно. Вы можете просто запустить новый автономный клиент, закрыть старый, переместить клавиши и запустить новый. Вы потеряете только одну эпоху. Если у вас есть ZKVM, требования к оборудованию практически сводятся к нулю. Таким образом, обе проблемы – порог в 32 ETH и сложность работы узлов – могут быть технически решены. Я думаю, что у этого есть много других преимуществ: это действительно улучшит нашу способность увеличивать индивидуальные ставки людей, это даст нам лучшую экосистему индивидуальных ставок и позволит избежать рисков централизации ставок. У доказательства доли есть и другие проблемы, такие как риски, связанные с ликвидным стейкингом и риски, связанные с MEV. Это также важные вопросы, которые следует продолжать рассматривать. Об этом думают наши исследователи. Восстановление после атаки 51%
Я действительно начал серьезно и серьезно думать. Удивительно, как много людей вообще не задумываются об этой теме и просто относятся к ней как к черному ящику. Что произойдет, если мы действительно столкнемся с атакой 51%? Эфириум может столкнуться с атакой 51%, Биткойн может столкнуться с атакой 51%, а правительство также может столкнуться с атакой 51%, например, с покупкой 51% политиков. Одна из проблем заключается в том, что вы не хотите полагаться исключительно на профилактику, вам также нужен план восстановления. Распространенное заблуждение заключается в том, что люди думают, что атаки 51% направлены на изменение окончательности. Люди обращают на это внимание, потому что именно это подчеркнул Сатоши Накамото в официальном документе. Вы можете потратить вдвое больше: после того, как я купил частный самолет, я провел атаку 51%, вернул свои биткойны, а также сохранил свой частный самолет и летал. Более реалистичная атака может включать внесение депозитов на биржи и такие вещи, как компрометация протоколов DeFi. Но разворот на самом деле не самое худшее. Самый большой риск, о котором нам следует беспокоиться, — это цензура. 51% узлов перестали принимать блоки от остальных 49% узлов или от любого узла, пытающегося содержать какой-либо тип транзакции. Почему это самый большой риск? Поскольку в реверсе окончательности используется Slash, в цепочке есть немедленное проверяемое доказательство того, что по крайней мере треть узлов сделали что-то очень, очень неправильное, и они были наказаны. А цензурная атака не подлежит процессуальному объяснению, нет непосредственных процессуальных доказательств, позволяющих сказать, кто сделал что-то плохое. Теперь, если вы являетесь онлайн-узлом и хотите увидеть, что определенная транзакция не была включена в 100 блоков, но у нас даже нет написанного программного обеспечения для этой проверки, еще одна проблема с проверкой заключается в том, что если кто-то захочет на атаки, они могут это сделать, они начинают с задержки транзакций и блоков, которые им не нравятся, на 30 секунд, затем задерживают на минуту, затем задерживают на две минуты, и у вас даже нет консенсуса, когда реагировать . Итак, я говорю, что цензура на самом деле представляет собой больший риск. В культуре блокчейна существует аргумент, что если произойдет атака, сообщество объединится, и они, очевидно, проведут несколько софт-форков и ликвидируют злоумышленников. Это может быть правдой сегодня, но это основано на множестве предположений о координации, идеологии и многом другом, и неясно, насколько это будет правдой через 10 лет. Итак, многие другие блокчейн-сообщества начинают говорить, что у нас есть такие вещи, как цензура, у нас есть эти ошибки, которые по своей природе в большей степени не могут быть объяснены. Поэтому мы должны опираться на общественный консенсус. Так что давайте полагаться исключительно на общественный консенсус и с гордостью признаем, что будем использовать его для решения наших проблем. На самом деле я предлагаю пойти в противоположном направлении. Мы знаем, что полностью координировать автоматические реакции и автоматически форковать большинство рассматриваемых злоумышленников математически невозможно. Но мы можем приблизиться к этому настолько, насколько это возможно. Вы можете создать форк, который фактически подключит к сети как минимум большинство узлов, основываясь на некоторых предположениях о состоянии сети. Аргумент, который я пытаюсь здесь привести, заключается в том, что на самом деле мы хотим попытаться сделать ответ на атаку 51% максимально автоматизированным. Если вы являетесь валидатором, то на вашем узле должно быть установлено программное обеспечение, которое, если оно обнаружит, что транзакции подвергаются цензуре или какие-то валидаторы подвергнуты цензуре, автоматически децензурирует большую часть цепочки, и все честные узлы будут автоматически децензурированы из-за их текущего кода. те же самые софт-форки. Конечно, опять же, это математически невозможный результат: по крайней мере, любой, кто в тот момент был офлайн, не смог бы сказать, кто был прав, а кто нет. Существует множество ограничений, но чем ближе вы подходите к этой цели, тем меньше работы нужно сделать, чтобы добиться социального консенсуса. Если представить, что на самом деле происходит атака 51%. Это не будет похоже на то, как показано ниже: в какой-то момент Лидо, Coinbase и Кракен внезапно опубликуют сообщение в блоге в 5:46, в котором, по сути, будут говорить: «Эй, ребята, мы сейчас делаем обзор». На самом деле может произойти то, что вы одновременно увидите войну в социальных сетях и одновременно всевозможные другие атаки. Если действительно произойдет атака 51%, то, кстати, я имею в виду, что не следует предполагать, что Lido, Coinbase и Kraken будут у власти через 10 лет. Экосистема Ethereum будет становиться все более популярной, и ей придется хорошо к этому адаптироваться.Мы хотим, чтобы нагрузка на социальный уровень была как можно более легкой, а это означает, что нам нужно, чтобы технический уровень, по крайней мере, выдвинул явного победителя, и если они хотят выйти из цепочки, которая находится на рассмотрении, им следует сплотиться. вокруг нескольких превосходных софт-форков. Я выступаю за то, чтобы мы провели больше исследований и дали очень конкретные рекомендации. Предложение: повысить порог кворума до 75% или 80%.
Я думаю, что порог для кворума (примечание: механизм кворума — это алгоритм голосования, обычно используемый в распределенных системах для обеспечения избыточности данных и конечной согласованности) может быть повышен с двух третей сегодня до 75% или примерно 80%. Основной аргумент заключается в том, что если атакует вредоносная цепочка, такая как цепочка цензуры, восстановление станет очень и очень трудным. Однако, с другой стороны, если увеличить долю Кворума, каковы риски? Если кворум составляет 80%, то вместо 34% узлов, переходящих в автономный режим с остановкой окончательности, это будет 21% узлов, переходящих в автономный режим с остановкой окончательности. Это рискованно. Давайте посмотрим, как это выглядит на практике? Насколько я понимаю, я думаю, что только один раз финальность остановилась примерно на час, потому что более трети узлов были в автономном режиме. И потом, были ли какие-нибудь инциденты, когда от 20% до 33% узлов были отключены от сети? Я думаю, максимум один раз и минимум ноль раз. Поскольку на практике очень немногие валидаторы отключаются от сети, я думаю, что риск этого довольно низок. Преимущества в основном заключаются в том, что планка, которую должен достичь злоумышленник, значительно увеличивается, а диапазон сценариев, в которых цепочка переходит в безопасный режим в случае уязвимости на стороне клиента, значительно увеличивается, поэтому люди могут фактически сотрудничать, чтобы выяснить, что пошло не так. Если порог кворума увеличивается с 67% до 80%, то, если предположить, что доля, которую должен достичь клиент, увеличивается с 67% до 80%, тогда ценность небольшого числа клиентов или ценность, которую небольшое количество клиентов клиенты могут предоставить, действительно начинает увеличиваться. Другие проблемы цензуры Другие проблемы цензуры связаны либо со списками включения, либо с некоторой альтернативой спискам включения. Таким образом, вся эта идея с многопараллельными предложениями, если она сработает, может даже стать заменой списков включения. Вам нужна либо абстракция учетной записи, либо абстракция учетной записи в каком-то протоколе. Причина, по которой вам это нужно, заключается в том, что сейчас кошельки со смарт-контрактами не получают особой пользы от списков включения. Кошельки со смарт-контрактами на самом деле не получают никакой гарантии устойчивости к цензуре на уровне протокола. Им было бы полезно, если бы в протоколе была абстракция учетных записей. Итак, есть много вещей, на самом деле многие из этих вещей ценны в видении центра Л2 и видении центра Л1. Из различных идей, которые я обсуждал, около половины, вероятно, предназначены специально для решений L2 для Ethereum, но другая половина в основном применима к пользователям Ethereum с L2 в качестве базового уровня и L1 или приложениями, ориентированными непосредственно на пользователя. Используйте легкие клиенты где угодно Во многих отношениях то, как мы взаимодействуем с отраслью, немного печально, мы децентрализованы, мы не заслуживаем доверия, кто в этой комнате запускает на своем компьютере легкий клиент, который проверяет консенсус? редкий. Кто использует Ethereum, доверяя браузерному кошельку Infura? Я бы хотел, чтобы через пять лет количество поднятых рук уменьшилось. Я бы хотел увидеть кошельки, которые ни в чем не доверяют Infura. Нам нужно интегрировать легкие клиенты. Infura может продолжать предоставлять данные. Я имею в виду, что для Infura на самом деле хорошо, если вам не нужно доверять Infura, потому что им легче создавать и развертывать инфраструктуру, но у нас есть инструменты для устранения требования доверия. Что мы можем сделать, так это создать систему, в которой конечный пользователь запускает что-то вроде легкого клиента Helios. На самом деле он должен запускаться непосредственно в браузере, напрямую проверяя консенсус Ethereum. Если он хочет проверить что-то в цепочке, например взаимодействовать с цепочкой, тогда вы просто проверяете доказательство Меркла напрямую. Если вы сделаете это, вы фактически приобретете определенную степень недоверия при взаимодействии с Эфириумом. Это для Л1. Кроме того, нам нужна эквивалентная схема для L2. В цепочке L1 есть заголовки блоков, состояния, комитеты синхронизации и консенсус. Если вы проверите консенсус, если вы знаете, что такое заголовок блока, вы сможете пройти через ветку Меркла и посмотреть, каково состояние. Так как же нам обеспечить легкие гарантии безопасности клиента для L2? Корень состояния L2 находится там. Если он основан на Rollup, существует смарт-контракт, и этот смарт-контракт хранит заголовок блока L2. Или, если у вас есть предварительное подтверждение, то у вас есть смарт-контракт, в котором хранится информация о том, кто является предварительным подтверждением, поэтому вы определяете, кто является предварительным подтверждением, а затем прослушиваете две трети их подписей. Итак, когда у вас есть заголовок блока Ethereum, у вас есть довольно простая цепочка доверия, хэш, ветвь Меркла и подпись, которую вы можете проверить, и вы можете получить легкую проверку клиента. То же самое касается любого L2. Раньше я рассказывал об этом людям, и часто мне отвечали: «О боже, это интересно, но какой в ​​этом смысл?»Многие L2 имеют мультиподпись. Почему мы не доверяем мультиподписям для проверки мультиподписей? К счастью, по состоянию на прошлый год это уже не так. Optimism и Arbitrum находятся на первой стадии Rollup, что означает, что у них действительно есть системы доказательств, работающие в цепочке, и комитет безопасности, который может прикрыть их в случае уязвимости, но комитету безопасности необходимо пройти очень высокий порог голосования. Если, скажем, 75% от 8 человек, то численность Арбитрума увеличится до 15 человек. Итак, в случае с Optimism и Arbitrum это не просто мультиподписи, у них есть настоящие системы доказательств, и эти системы доказательств действительно играют свою роль, по крайней мере, с точки зрения обладания большей властью при принятии решения о том, какая цепочка правильная или неправильная. . EVM идет еще дальше: я считаю, что у нее даже нет комитета по безопасности, поэтому она совершенно не заслуживает доверия. Мы действительно начинаем двигаться вперед в этом вопросе, и я знаю, что многие другие L2 тоже продвигаются вперед. Таким образом, L2 — это больше, чем просто мультиподпись, поэтому концепция легких клиентов для L2 действительно начинает иметь смысл. Сегодня мы уже можем проверить ветку Меркла, достаточно написать код. Завтра мы также сможем проверить ZKVM, чтобы вы могли полностью проверить Ethereum и L2 в своем браузерном кошельке. Кто хочет быть ненадежным пользователем Ethereum в браузерном кошельке? чудесный. Кто предпочел бы быть ненадежным пользователем Ethereum на своем мобильном телефоне? А как насчет Raspberry Pi? А как насчет умных часов? С космической станции? Мы это тоже исправим. Итак, нам нужен эквивалент конфигурации RPC, который содержит не только сведения о том, с какими серверами вы общаетесь, но и фактические инструкции по аутентификации легкого клиента. Это то, над чем мы можем работать. Антиквантовая стратегия
Время квантовых вычислений сокращается. Metaculous считает, что квантовые компьютеры появятся в начале 2030-х годов, а некоторые думают и раньше. Поэтому нам нужна квантовоустойчивая стратегия. У нас есть квантово-устойчивая стратегия. Есть четыре части Эфириума, уязвимые для квантовых вычислений, и у каждой есть естественные альтернативы. Квантовоустойчивой альтернативой Verkle Tree является Starked Poseidon Hash, или, если мы хотим быть более консервативными, мы можем использовать консенсусную подпись Блейка, в настоящее время мы используем агрегатную подпись BLS, которую можно заменить агрегатной подписью Старка. Blob использует KZG, что можно доказать с помощью деревьев Меркла Старка, закодированных разделением. В учетных записях пользователей в настоящее время используется ECDSA SECP256K1, который можно заменить подписями на основе хеша, абстракцией и агрегацией учетных записей, кошельками смарт-контрактов ERC 4337 и т. д. Получив это, пользователь может настроить свой собственный алгоритм подписи, в основном используя подпись на основе хеша. Я думаю, нам действительно нужно начать думать о создании подписей на основе хеша, чтобы пользовательские кошельки могли легко перейти на подписи на основе хеша. Упрощение протокола Если вам нужен надежный базовый уровень, протокол должен быть простым. В нем не должно быть 73 случайных хуков и некоторой обратной совместимости, которая существует из-за случайной глупой идеи, которую придумал какой-то случайный парень по имени Виталик в 2014 году. Поэтому есть смысл попытаться действительно упростить и начать по-настоящему устранять технический долг. Журналы в настоящее время основаны на фильтрах Блума, которые работают плохо и недостаточно быстро, поэтому необходимы улучшения журнала, чтобы добавить более сильную неизменяемость, что мы уже делаем на стороне без сохранения состояния, по сути ограничивая состояние каждого блока Views. Эфириум сейчас представляет собой невероятную коллекцию, есть RLP, есть SSZ, есть API, и в идеале мы должны просто использовать SSZ, но, по крайней мере, избавиться от RLP, состояния и двоичного дерева Меркла, как только у вас будет двоичное дерево Меркла, тогда весь Эфириум находится в бинарном дереве Меркла. Fast Finality, Single Slot Finality (SSF) очищает неиспользуемые прекомпиляторы, такие как прекомпилятор ModX, который часто вызывает ошибки консенсуса. Было бы неплохо, если бы мы могли удалить его и заменить высокопроизводительным кодом Solidity. Подведем итог Как надежный базовый уровень, Ethereum обладает уникальными преимуществами, в том числе некоторыми, которых нет у Биткойна, такими как децентрализация консенсуса и значительные исследования по восстановлению 51% атак. Я думаю, что необходимо действительно укрепить эти сильные стороны. Также признайте и исправляйте наши недостатки, чтобы обеспечить соответствие очень высоким стандартам. Эти идеи полностью совместимы с агрессивной дорожной картой L1. Одна из вещей, которая меня больше всего радует в Ethereum, особенно в процессе разработки ядра, — это то, что наша способность работать параллельно значительно улучшилась. Это сильная сторона: мы действительно можем работать над многими вещами параллельно. Таким образом, забота об этих темах на самом деле не влияет на возможность улучшения экосистем L1 и L2. Например, улучшение EVM L1, чтобы упростить криптографию. Проверка хэшей Poseidon в EVM в настоящее время слишком дорога. 384-битная криптография также слишком дорога. Итак, есть некоторые идеи помимо EOF, такие как коды операций SIMD, EVM max и т. д. Есть возможность подключить к EVM этот высокопроизводительный сопроцессор. Это лучше для уровня 2, поскольку проверка доказательств обходится дешевле, и лучше для приложений уровня 1, поскольку протоколы конфиденциальности, такие как zk SNARK, дешевле. Кто использовал соглашение о конфиденциальности? Кто хочет платить 40 долларов вместо 80 долларов? Больше людей выберут первое. Вторая группа пользователей может совершать транзакции на уровне 2, а уровень 1 может значительно снизить затраты. ​