TL;DR
- На концепцию Parallel EVM делают ставку несколько ведущих венчурных фондов: Paradigm, Jump, Dragonfly и др.
- Репрезентативный проект — Monad, а также Sei, MegaETH, Polygon, Neon EVM, BSC и т. д. Некоторые из них L1, некоторые L2. Полной публичной информации о конкретных различиях между командами нет.
- Хотя Parallel EVM буквально означает «распараллеливание», на самом деле это особая оптимизация производительности каждого компонента EVM, поэтому ее усилия, скорее всего, представляют собой предел производительности согласно стандарту EVM.
- Сложность: Помимо реконструкции всего стека технологий, есть также возможность заранее предсказать, будут ли параллельные транзакции конфликтовать, и эффективность повторного выполнения после возникновения конфликтов.
- Задача: как добиться дифференциации экосистемы с открытым исходным кодом и как найти баланс между децентрализацией и производительностью.
После того, как алгоритм консенсуса, DA (уровень данных) и технология доказательства с нулевым разглашением были широко изучены и апробированы, следующей жесткой технологией, привлекающей внимание, является Parallel EVM.Рынок капитала также вложил в это сотни миллионов долларов. повествование, и родилось множество уникальных технологий.
Сообщество начало обращать внимание на Parallel EVM (распараллеливание EVM), которое возникло из-за того же ключевого слова, которое упомянули Георгиос Константопулос (технический директор Paradigm) и Хасиб Куреши из Dragonfly, когда предвкушали тенденции 2024 года в конце 2023 года. Однако подробностей по этой теме не так много, и многие люди считают, что это не новая концепция. EVM и параллельные вычисления являются относительно зрелыми концепциями соответственно. Почему объединение этих двух слов является важной тенденцией? Шерстяная ткань?
Но это по-прежнему очень нишевая тема, настолько, что, если вы посмотрите на годовые сводки и прогнозы тенденций многих исследовательских институтов, параллельная EVM не упоминается. Так что это все еще новая концепция, которая еще не сформировала широкомасштабного консенсуса. Более того, эта концепция похожа на такие темы, как алгоритм консенсуса и DA: все они чисто технологические, поэтому на нее обращает внимание еще меньше людей.
Самым прямым преимуществом Paralle EVM является возможность существующим децентрализованным приложениям достичь производительности уровня Интернета. Можно даже сказать, что Parallel EVM — единственная новая технология, которая может не только использовать (большое количество зрелых) существующих смарт-контрактов, но и обеспечить высокопроизводительную параллельную пропускную способность публичной сети.
Paradigm уже давно с нетерпением ждет выхода в игру, и Jump делает большие ставки.
По данным Fortune, Paradigm планирует возглавить последний раунд инвестиций Monad, собрав $200 млн при оценке в $3 млрд. Хотя это первая концепция параллельного EVM команды, в которую Paradigm планирует инвестировать, на самом деле они обращают внимание на эту технологию уже много лет.Георгиос Константопулос (технический директор Paradigm) упомянул этот термин в 2021 году.
Интересно также происхождение слова монада. В философской системе философа Лейбница Монады являются основными элементами, составляющими Вселенную. Это неделимые сущности, на которые не влияет физика. Каждая Монада отражает всю Вселенную и когда-то переводилась на китайский язык как «монада».
В информатике Монада — это шаблон проектирования в языках функционального программирования, который помогает программистам справляться со сложностью реального мира с почти математической чистотой, делая код более модульным, простым для понимания и сопровождения.
Еще одна интересная вещь заключается в том, что Монада и Кочевник являются «анаграммами» друг друга.
Помимо монад, при обсуждении этой темы Георгиос также упомянул Sei и Polygon. Однако еще одна важная причина, по которой он так оптимистично настроен в отношении Parallel EVM, заключается в том, что они разработали клиент Ethereum, Reth. Он позиционируется как высокопроизводительный клиент исполнительного уровня Ethereum, реализованный на языке Rust. Reth разрабатывается быстрыми темпами и только что вступил в стадию бета-тестирования. Возможно, они рассмотрят возможность внедрения Parallel EVM непосредственно на Reth, но, учитывая объем исследований и разработок, возможно, лучше инвестировать в другие команды для продвижения Parallel EVM. Согласно документации Monad, в разработке они в основном используют C++ и Rust.
Когда Reth был запущен, члены команды Erigon также обвинили его в плагиате открытого исходного кода Akula, что также привело к нехватке средств у проекта Akula и остановке разработки. Георгиос ответил, что Reth не является ответвлением какого-либо другого клиента, и код не исходит от какого-либо другого клиента, но на него действительно повлияли и вдохновили Гета, Эригона и Акулу. ()
Еще одним ключевым участником являются Jump Trading и Jump Capital. Основатель Monad пришел из Jump Trading и имеет богатый опыт в высокочастотной торговле; среди инвесторов Sei есть Jump Capital, а Jump активно участвует в экосистеме Solana, включая инфраструктуру и проекты. .
Dragonfly, один из первых инвесторов Monad, также уделяет внимание смежным направлениям: она инвестировала в NEAR, специализирующуюся на технологии шардинга, а также в публичные сети, такие как Aptos, Avalanche и Nervos.
Обновления алгоритма консенсуса недостаточно, наконец-то настала очередь исполнительного уровня
В последних нескольких войнах публичных цепочек исполнительный уровень оставался местом, которому пренебрегали. Хотя у них есть много инноваций на уровне исполнения, сообщество все еще помнит используемый ими алгоритм консенсуса, и все сообщество также считает, что производительность этих высокопроизводительных публичных цепочек обусловлена инновациями алгоритма консенсуса.
Но это не так: если вы хотите получить высокопроизводительную публичную цепочку, необходимо согласовать алгоритм консенсуса и уровень исполнения, что также соответствует недостаткам деревянной бочки. Для тех публичных цепочек, которые основаны на EVM и только улучшают алгоритм консенсуса, необходимы более сильные узлы для повышения производительности. Например, BSC ограничивает объем газа, который может обрабатываться блоком, до уровня 2000 TPS, что требует настройки машины, в несколько раз превышающей инвестиции в полный узел Ethereum. Полигон теоретически может достигать 1000 TPS, но обычно это всего лишь десятки-сотни.
Для архивных узлов BSC требуется как минимум 16-ядерный процессор и 128 ГБ памяти, а для узлов Ethereum требуется только как минимум 4-ядерный процессор и 16 ГБ памяти.
Команда BSC уже давно знает об этих проблемах, поэтому она также работает с NodeReal над разработкой технологии Parallel EVM. Только таким образом мы сможем еще больше увеличить количество транзакций, которые может обработать каждый блок, разрешить параллельное выполнение большего количества транзакций и увеличить верхний предел TPS.
Параллелизм: не только переход с одноядерного процессора на многоядерный
В большинстве систем блокчейна транзакции выполняются полностью последовательно.Вы можете думать об этом как об одноядерном процессоре.Следующий расчет может быть выполнен только после завершения текущего расчета. Хотя этот метод медленный, его преимуществами являются простота и низкая сложность системы.
Но если будущей системе блокчейна потребуется доступ к пользовательскому масштабу на уровне Интернета, одноядерного процессора определенно будет недостаточно. Таким образом, переход на параллельную виртуальную машину с многоядерным процессором может одновременно обрабатывать несколько транзакций и увеличивать пропускную способность. Однако при инженерной реализации возникает множество проблем: например, что делать, если две транзакции, обрабатываемые одновременно, записывают данные в один и тот же смарт-контракт? Необходимо разработать новый механизм разрешения этого противоречия. Для параллельного выполнения других совершенно несвязанных смарт-контрактов пропускная способность может быть увеличена в зависимости от количества потоков параллельной обработки и масштаба.
Кроме того, Parallel EVM не только улучшает возможности параллельного выполнения, но и оптимизирует эффективность однопоточного выполнения. Генеральный директор Monad Кеоне Хон сказал: «…настоящим узким местом (EVM) является частое чтение и запись статуса при обработке данных…». Он также сказал, что параллельное выполнение — это лишь часть дорожной карты, а более масштабная задача Monad — сосредоточиться на EVM и сделать его максимально эффективным.
Поэтому, хотя Parallel EVM буквально означает «распараллеливание», на самом деле это особая оптимизация производительности каждого компонента EVM, поэтому ее усилия, скорее всего, представляют собой предел производительности согласно стандарту EVM.
EVM не равен Solidity
Написание смарт-контрактов — важный навык для большинства разработчиков блокчейнов. Инженеры могут использовать Solidity или другие языки смарт-контрактов высокого уровня для написания соответствующих реализаций логики, исходя из потребностей бизнеса. Однако на самом деле EVM не может напрямую понять логику Solidity. Ему необходимо пройти некую «трансляцию» и перевести (скомпилировать) ее на язык низкого уровня, который может понять машина (код операции / байт-код байт-кода), прежде чем она сможет быть прочитанным виртуальной машиной. Разработчикам Solidity не нужно понимать этот процесс перевода, поскольку уже существуют зрелые инструменты для его реализации.
В конце концов, это «перевод», поэтому тоже будут некоторые накладные расходы (дополнительные накладные расходы). Инженеры с опытом низкоуровневого кодирования могут писать логику программы напрямую, используя коды операций в Solidity. Это позволяет добиться высочайшей производительности, а это означает, что пользователи могут экономить Gas при совершении транзакций. Например, протокол Seaport, запущенный Opensea, широко использует встроенную сборку в смарт-контрактах, чтобы максимально сократить расходы на газ для пользователей.
Таким образом, если Parallel EVM удастся наконец реализовать, это не только предоставит возможности распараллеливания, но и оптимизирует производительность всего стека EVM. Обычным разработчикам приложений не нужно тратить много энергии на оптимизацию только для того, чтобы сэкономить немного газа, поскольку базовая виртуальная машина достаточно мощна, чтобы сгладить эти различия.
Производительность EVM варьируется, и «стандарт» не равен «инженерной практике».
«Виртуальную машину» также можно назвать «уровнем выполнения» — это механизм, в котором смарт-контракты окончательно рассчитываются и обрабатываются после их компиляции в коды операций. «Байт-код», определенный виртуальной машиной Ethereum (EVM), теперь стал отраслевым стандартом. Стандарт перед разработкой Авторы могут один раз написать смарт-контракты и развернуть их в нескольких сетях, что чрезвычайно экономически эффективно.
Поэтому, пока он полностью совместим со стандартом «байт-кода» EVM, его можно называть EVM, но методы реализации могут сильно различаться. Например, клиент Ethereum Geth использует язык Go для реализации стандарта EVM. Однако Ipsilon, исследовательская группа исполнительного уровня Ethereum Foundation, поддерживает независимую реализацию EVM, разработанную на C++.Другие клиенты Ethereum могут напрямую вызывать эту библиотеку для выполнения как EVM.
Например, многие продукты промышленного производства имеют соответствующие международные стандарты. Например, когда продукт покидает завод, количество колоний должно быть меньше определенного значения, прежде чем его можно будет продать. Это «стандарт». Но как соответствовать этому заводскому стандарту, каждая фабрика может выбирать из десятков различных методов стерилизации, а некоторые фабрики могут найти более экономичные способы удовлетворить это требование.Это «практика».
Поскольку есть реализация evmone, можно сделать и другие реализации. Итак, в этом примере EVM стандарт EVM определяет некоторые основные методы работы «байт-код» (например, поддержку самых простых арифметических операций, таких как сложение, вычитание, умножение и т. д.). Когда каждый байт-код имеет определенный вход, существует определенный выход. . Когда дело доходит до соответствия этому критерию, реализации (и методы) сильно различаются, оставляя много возможностей для настройки и инженерной оптимизации.
Сходства и различия параллельного EVM
В треке Parallel EVM, помимо самой горячей Monad, есть еще Sei, MegaETH, Polygon, Neon EVM, BSC и т. д., а Reth-клиент Paradigm также хочет реализовать функции распараллеливания.
С точки зрения позиционирования Monad, Sei, Polygon и BSC являются блокчейнами уровня 1, а MegaETH может быть уровнем 2. Neon EVM основан на сети Solana. Кроме того, Reth является клиентом с открытым исходным кодом, а MegaETH продолжит частично развиваться на основе проектов Reth.
Конечно, между этими командами все еще существует конкуренция, а все технические детали и конструкторская документация полностью не раскрыты. Возможно, это снова похоже на гонку вооружений, как у BTC Layer 2, Restake и Ethereum Layer 2. Хотя между технологиями (и открытым исходным кодом) существуют тонкие различия, более важным является то, как создать уникальность экосистемы.
Технические трудности Parallel EVM
Для последовательно выполняемых транзакций узким местом является ЦП и процесс чтения и записи состояния. Но преимущество в том, что этот метод достаточно прост, безошибочен и все задачи можно выполнить пошагово. Для виртуальных машин, которые выполняются параллельно, могут возникнуть конфликты состояний, поэтому эту часть решения необходимо добавить до или после выполнения.
Простой пример: если виртуальная машина поддерживает параллельное выполнение четырех потоков, и каждый поток может обрабатывать транзакцию одновременно, то если все эти четыре транзакции являются транзакциями с одним и тем же пулом транзакций в Uniswap, они не могут выполняться параллельно. Расчет, поскольку каждая транзакция будет влиять на цену транзакции в этом пуле транзакций. Но если эти четыре потока одновременно работают над четырьмя совершенно не связанными друг с другом вещами, то проблем нет.
Это потребует проектирования и разработки различными командами, но, по крайней мере, необходимо гарантировать, что после параллельного выполнения необходим модуль для обнаружения конфликтов и повторного выполнения в случае их возникновения. Конечно, если транзакции, которые могут конфликтовать, можно заранее спрогнозировать и отсеять, эффективность параллельной работы всей виртуальной машины также может быть увеличена.
Помимо различий в инженерной реализации виртуальной машины Parallel EVM, каждая команда обычно перепроектирует и повышает производительность чтения и записи базы данных состояния, а также разрабатывает алгоритм консенсуса, такой как MonadDb и MonadBFT, разработанный Monad.
испытание
Для Parallel EVM есть две возможные проблемы: будет ли долгосрочная инженерная ценность передана Ethereum; и централизация узлов.
Поскольку различные команды все еще находятся на стадиях разработки и тестирования технологии Parallel EVM, они еще не решили открыть исходный код всех инженерных деталей. Однако после входа в тестовую сеть и основную сеть эти проектные документы будут опубликованы, а также могут быть поглощены Ethereum или другими публичными цепочками. Поэтому на данный момент необходимо быстрее продвигать экологическое строительство и строить больше экологических рвов.
Однако эта проблема не так уж и серьезна: с одной стороны, для разработчиков Crypto теперь есть больше лицензий с открытым исходным кодом на выбор (например, лицензия Uniswap, которая может сделать код общедоступным, но не позволяет разветвляться на коммерческие проекты). с другой стороны, позиционирование Monad по своей сути отличается от позиционирования Ethereum. Даже если Ethereum сможет достичь окончательности одного сокета (SSF) в будущем, окончательность транзакций все равно будет составлять не менее 12 секунд, что далеко не достаточно для сценариев высокочастотных приложений.
Еще одна проблема, которая является общей для всех высокопроизводительных публичных цепочек, — это как развернуть больше узлов, чтобы удовлетворить основные требования пользователей к неразрешенности и доверительности: децентрализация. Возможно, некоторые показатели можно выразить количественно, например «TPS, разделенный на требования к оборудованию узла», чтобы мы могли контролировать переменные и сравнивать, какая публичная цепь/клиент имеет более высокий TPS на основе конкретных требований к оборудованию. В конце концов, чем ниже требования к оборудованию узла, тем больше возможных узлов.
Далее мы продолжим отслеживать прогресс каждого проекта Parallel EVM и подробно обсуждать их технологии и различия.
