Переслать оригинальное название:Технический анализ Artela: Почему «Parallel EVM» связан с битвой за выживание экосистемы Ethereum EVM?
Недавнее ведущее инвестирование Paradigm в размере ошеломляющих $225 миллионов долларов в раунд финансирования Monad вызвало шоковые волны на рынке, поджигая волну интереса к "параллельному EVM". Но что именно решает "параллельный EVM"? Каковы узкие места и ключевые проблемы в разработке параллельного EVM? Я считаю, что "параллельный EVM" представляет собой последнюю стойку EVM против высокопроизводительных цепей уровня 1, битва, которая определит выживание экосистемы Ethereum EVM. Почему? Давайте погрузимся в мое понимание:
Виртуальная машина Ethereum EVM собственная «последовательная» способность обработки транзакций накладывает значительные ограничения на производительность как цепочек уровня 1, совместимых с EVM, так и цепочек уровня 2, совместимых с EVM. Это происходит потому, что все они в основе полагаются на одну и ту же структуру для обработки состояния и окончательности транзакции.
В отличие от этого, высокопроизводительные цепи уровня 1, такие как Solana, Sui и Aptos, обладают врожденными преимуществами параллельной обработки. В этой связи цепочки на основе EVM должны решить свои врожденные недостатки параллельных возможностей для эффективной конкуренции с этими высокопроизводительными публичными цепочками уровня 1. Давайте рассмотрим различные подходы к реализации параллельного EVM на примере сети Artela, восходящей звезды в области параллельного EVM:
Представленные цепями, такими как Monad, Artela и SEI, эти цепи значительно повышают TPS, обеспечивая параллельные возможности транзакций в псевдо-среде EVM. Эти независимые параллельные цепи уровня 1 EVM обладают уникальными механизмами консенсуса и техническими характеристиками, но они по-прежнему сохраняют цель совместимости и расширения в экосистеме EVM. По сути, они перестраивают цепи EVM, "изменяя их кровный род", чтобы лучше служить экосистеме EVM.
2) На примере цепей, таких как Eclipse и MegaETH, эти цепи используют независимое согласование и возможности "предварительной обработки" транзакций цепи второго уровня для фильтрации и обработки состояний транзакций перед отправкой их на основную сеть. Они также могут выбирать выполнение слоя любой другой цепи для завершения состояний транзакций. Этот подход в основном абстрагирует EVM в подключаемый исполнительный модуль, позволяя выбирать лучший "уровень выполнения" в зависимости от потребностей, тем самым достигая параллельных возможностей. Однако, хотя эти решения могут обслуживать EVM, они работают за пределами каркаса EVM.
3) Представленные цепочками, такими как Polygon и BSC, эти цепочки достигли определенной степени параллельной обработки EVM. Однако их оптимизация ограничивается алгоритмическим слоем, не углубляясь в консенсус и слои хранения. Следовательно, их параллельные возможности больше похожи на конкретную функцию, чем на комплексное решение проблем параллелизации EVM.
4) Примером служат цепи, такие как Aptos, Sui и Fuel, - эти цепи не являются строго EVM-цепями. Вместо этого они используют свои врожденные возможности высокой параллельной обработки и применяют промежуточное программное обеспечение или техники разбора кода для достижения совместимости с окружением EVM. Это очевидно в случае Starknet, решения второго уровня Ethereum. Совместимость Starknet с EVM требует специального проводника из-за его языка Cario и функций абстракции учетных записей. Эта проблема совместимости является распространенной проблемой для не-EVM-цепей, которые пытаются связать с EVM-цепями.
Упомянутые выше четыре подхода имеют свои особенности. Например, Layer 2 с параллельными возможностями фокусируется на гибкости модульных комбинаций цепей “исполнительного уровня”, в то время как EVM-совместимые цепи выделяют индивидуальные особенности конкретных функций. Что касается других не-EVM цепей с функциями совместимости EVM, их целью является больше проникновение в ликвидность Ethereum. Реальная цель - тщательно укрепить экосистему EVM, оставив только один усиленный EVM уровень 1 для улучшения параллельных возможностей.
Итак, каковы ключевые факторы укрепления параллельной общественной цепи уровня 1 EVM? Как мы можем восстановить цепь EVM, продолжая обслуживать экосистему EVM? Вот две ключевые точки:
Способность к доступу к состоянию ввода-вывода диска и получению информации. Поскольку чтение и запись данных занимают время, простая сортировка и планирование транзакций не могут существенно улучшить возможности параллельной обработки. Для этого также требуется внедрение кэширования, фрагментации данных и даже технологий распределенного хранения для балансировки скорости чтения и возможности конфликтов состояний из фундаментального процесса хранения и чтения состояний.
Имея эффективную сетевую коммуникацию, синхронизацию данных, оптимизацию алгоритма, усиление виртуальной машины и различные оптимизации компонентов слоя механизма консенсуса, такие как разделение вычислений и задач ввода-вывода, требующие полной оптимизации и улучшения с различных аспектов, включая архитектуру компонентов нижнего уровня и совместные процессы. Это в конечном итоге приводит к способности быстрого выполнения параллельных транзакций с управляемым потреблением вычислений и высокой точностью.
Относительно конкретного проекта параллельной цепи уровня 1 EVM самого по себе, какие технологические инновации и оптимизации фреймворка необходимы для достижения "параллельного EVM"?
Для полного достижения возможностей координации и оптимизации ресурсов "параллельной EVM" с нижним уровнем архитектуры Artela представляет Эластичные вычисления и Эластичное блочное пространство. Как их понимать? Эластичные вычисления позволяют сети динамически выделять и корректировать вычислительные ресурсы в соответствии с потребностью и нагрузкой, в то время как эластичное блочное пространство динамически корректирует размер блока в зависимости от количества транзакций и размера данных в сети. Весь принцип эластичного дизайна работает аналогично эскалаторам в торговых центрах, которые автоматически чувствуют поток пешеходов, что имеет смысл.
Как упоминалось ранее, производительность чтения диска состояния I/O имеет решающее значение для параллельной EVM. Совместимые с EVM цепочки, такие как Polygon и BSC, добиваются улучшения эффективности в 2-4 раза благодаря алгоритмическому параллелизму, но это лишь оптимизация на уровне алгоритма. Слой консенсуса и слой хранения не прошли глубокой оптимизации. Каким было бы истинное глубокое оптимизирование?
В ответ на это Artela прибегает к решениям технологий баз данных, улучшая как чтение, так и запись состояний. Для записи состояний вводится технология Write-Ahead Logging (WAL), которая регистрирует изменения перед их записью на диск. Эта асинхронная операция позволяет избежать немедленной записи на диск при изменении состояния, что уменьшает операции ввода-вывода диска. Для чтения состояний в основном применяются асинхронные операции с использованием стратегий предварительной загрузки для повышения эффективности чтения. Предсказывая, какие состояния понадобятся на основе истории выполнения контрактов и предварительно загружая их в память, происходит улучшение эффективности запросов ввода-вывода диска.
Другими словами, это алгоритм, который обменивается временем выполнения на память, фундаментально улучшая параллельные вычислительные возможности виртуальной машины EVM и оптимизируя проблему конфликта состояний с самого начала.
Кроме того, Artela представляет возможности модульного программирования Aspect для более эффективного управления сложностью и улучшения эффективности разработки. Внедрение разбора кодирования WASM для улучшения гибкости программирования и предоставление разрешений на доступ к API низкого уровня позволяет достичь безопасной изоляции уровня выполнения. Это позволяет разработчикам эффективно разрабатывать, отлаживать и развертывать смарт-контракты в среде Artela, активируя возможности настройки и расширения сообщества разработчиков. В частности, разработчиков будут стимулировать оптимизировать свой код смарт-контрактов для параллелизма, поскольку снижение вероятности конфликтов состояний критично для логики вызова и алгоритма каждого смарт-контракта.
Вот и все.
Для всех несложно видеть, что концепция «Параллельного EVM» в сущности оптимизирует процесс выполнения статуса транзакции.@monad_xyzутверждает, что способна достигать 10 000 транзакций в секунду, и ее техническое ядро не представляет ничего иного, как достижение параллельной обработки крупных транзакций через специализированные базы данных, удобство для разработчиков, консенсус отложенного выполнения и технология суперскалярного конвейера и т. д. Это не слишком отличается от эластичных вычислений и асинхронных операций ввода-вывода Artela.
Фактически, то, что я хочу выразить, заключается в том, что этот тип высокопроизводительной параллельной цепи EVM является результатом интеграции продуктов web2 и технических возможностей. Он действительно усваивает суть "технической обработки" в условиях высокой нагрузки изредка на зрелом рынке приложений web2.
Если вы посмотрите в отдаленное будущее массового принятия, «Параллельный EVM» действительно является базовой инфраструктурой для экосистемы EVM, чтобы столкнуться с более широким рынком web2, и разумно, что капитал рынок настроен так бычий.
утверждение:
Эта статья воспроизведена из [Просмотр на цепи], авторские права принадлежат оригинальному автору [Хао Тян], если у вас есть возражения по поводу перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда и команда обработает это как можно скорее в соответствии с соответствующими процедурами.
Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.
Другие языковые версии статьи переведены командой Gate Learn и не упоминаются в Gate.com, переведенная статья не может быть воспроизведена, распространена или украдена.
