Пересланный Оригинальный Заголовок: Дизайнер Blockspace: Будущее среды выполнения

За девять лет с момента запуска Ethereum первой децентрализованной программируемой блокчейн-платформы, криптовалюта столкнулась с несколькими препятствиями в попытке масштабировать децентрализованные приложения для миллиардов пользователей. И чтобы разработать решения масштабирования для решения этой проблемы, криптоиндустрия непрерывно финансирует и разрабатывает совершенно новые типы блокчейнов для решения "проблемы производительности".

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

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

Сегодня внедрение EIP4844 и альтернативные слои DA сняли критический узкий проход DA. Несмотря на этот важный этап, имеется информация о необходимости решения других важных узких мест. В прошлом месяце, Базовыйсобранный$1.57M в комиссиях за один деньпри этом заплатив всего $5K за издержки на доступность данных для Ethereum. Это говорит о том, что вычислительная работа, необходимая для проверки и обработки обновлений состояния, остается критическим узким местом и возможностью для улучшения.

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

Сегодняшние вызовы

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

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

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

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

Узкое место №1: Неэффективный доступ к состоянию

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

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

Ethereum специально полагается на структуру данных, известную как дерево Меркла-Патриция (MPT), которое включает в себя @chiqing/объяснение-merkle-patricia-trie-ae3ac6a7e123">четыре поддерева.

Поскольку Ethereum добавляет больше смарт-контрактов и токенов в свое состояние, его состояние trie становится больше и сложнее. По мере роста состояния требуется больше места для хранения, больше вычислительных ресурсов для обработки и больше пропускной способности для передачи. В то же время аппаратные ограничения узла остаются примерно такими же.

Этот рост состояния напрямую влияет на производительность Ethereum, потому что состояние хранится на диске, и операции с диском вызывают большие накладные расходы. В то время как доступ к данным из регистра ЦП может занимать 0,1 наносекунду, это может занять от 10 до 100 микросекунд(100x–1000x медленнее)для доступа к данным с диска, грубо переводящийся в 200 000 инструкций ЦП, которые могли бы быть выполнены за это время. Это эквивалентно консервативной оценке в 36 транзакций ERC-20, которые могли бы совершиться!

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

В целом, примитивы управления состоянием для блокчейнов далеки от достижения своего абсолютного потенциала, и можно сделать много улучшений для повышения вычислительной эффективности.

Узкое место #2: Неэффективные вычисления

Слои выполнения также сталкиваются с проблемой неэффективных вычислений, которая проявляется различными способами.

С одной стороны, многие обрабатывают транзакции последовательно, недоиспользуя современные многоядерные процессоры, способные обрабатывать несколько операций одновременно. Это последовательное выполнение приводит к неизбежным простоям ЦП между транзакциями, что приводит к потере ценных вычислительных ресурсов.

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

Эти неэффективности приводят к субоптимальному использованию вычислительных ресурсов и затрудняют производительность уровней выполнения.

Решения: Неэффективный доступ к состоянию

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

Отсутствие состояния & Вычисления в памяти

Некоторые уровни выполнения решают проблему увеличения объема данных путем простого принятия этого в краткосрочной перспективе. Они переносят хранение данных состояния с медленных дисковых систем на более быструю оперативную память (RAM). Доступ к информации о состоянии в RAM значительно сокращает накладные расходы, связанные с операциями на диске, которые являются медленными и требовательными к ресурсам.

Однако такой подход ставит под сомнение основной принцип децентрализации. Хранение все более больших объемов данных состояния в ОЗУ требует более совершенного и дорогостоящего оборудования, что может ограничить возможность отдельных лиц участвовать в качестве узловых операторов. Следовательно, по мере роста требований к оборудованию меньше субъектов могут позволить себе запускать эти узлы.

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

В результате этих систем должны позволять блок-производителям максимизировать свою скорость, поскольку можно ожидать, что они будут вычислять в памяти, полностью устраняя ввод-вывод с диска во время выполнения. Поскольку задержка оперативной памяти обычно составляет менее 100 наносекунд, задержка доступа к состоянию уменьшается до 1000 раз по сравнению с реализациями на основе диска.

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

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

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

Масштабирование дерева Verkle от Inevitable Ethereum's "Verkle Tree"

Деревья Verkle улучшают структуру традиционных деревьев Merkle за счет оптимизации связей между листьями и корнем и устранения необходимости включения соседних узлов в процесс проверки. В дереве Verkle проверка доказательства включает только значение в узле листа, обязательство к корню узла и одно векторное обязательство на основе полиномиальных обязательств, которое заменяет множественные хеш-обязательства, найденные в деревьях Merkle. Это изменение позволяет деревьям Verkle поддерживать фиксированный размер свидетельства, который не увеличивается с высотой дерева или количеством проверяемых листьев, что значительно повышает эффективность хранения и вычислений во время проверки данных.

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

На уровне L2, команды типа MegaETHактивно применяют концепцию безгосударственности к проектированию оптимистичных роллапов. В их дизайне узел-последователь генерирует свидетельство для каждого блока, содержащее необходимые значения состояния и промежуточные хеши, выдавая дельту состояния, представляющую изменения в состоянии. Проверяющие узлы могут затем повторно выполнить любой блок, извлекая свидетельство из слоя DA или пиринговой сети, не храня всего состояния. Параллельно полные узлы обновляют свое состояние, применяя распространяемые через сеть дельты состояния, что позволяет им оставаться синхронизированными без повторного выполнения транзакций или хранения всей истории состояния.

Тем не менее, стоит отметить, что преимущества отсутствия состояния и возможность вычислений в памяти не являются универсальным решением для производительности слоя выполнения.

TPS в реальном времени от MegaETH «Понимание производительности выполнения Ethereum Execution Layer»

Как сооснователь MegaETH, Илонг Ли, определяет в следующемпрезентация исследованияпри выполнении на Ethereum существуют другие неэффективности в структурах данных и образцах доступа onchain, которые остаются оптимизированными.

Улучшение баз данных

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

Фактически, ограничения существующих конструкций базы данных, обнаруженные в EVM, информировалиMonad’s* решение выйти за пределы чисто оптимизации вычислительной эффективности для достижения параллелизации. Монада обнаружила, что даже после внедрения параллельного выполнения они видели лишь небольшое ускорение производительности, потому что многопоточные запросы на чтение и запись в базу данных блокировали друг друга. В результате Монада реализовала базу данных, совместимую с асинхронным вводом-выводом (AIO) или параллельным доступом, как критическую часть решения.

Асинхронный ввод/вывод

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

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

Асинхронный ввод-вывод можно реализовать как с традиционными жёсткими дисками, так и с твердотельными накопителями (SSD), хотя выгоды более заметны с SSD. Жёсткие диски могут выполнять AIO, но их механическая природа означает, что они по своей сути медленнее, чем SSD, которые хранят данные на флэш-памяти и не имеют подвижных частей, что приводит к более быстрым временам доступа.

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

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

Частота состояния Мерклизации

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

Для поиска и обновления данных в этом дереве требуется один случайный доступ к диску для каждого слоя дерева, который необходимо пройти, и обход наивного дерева Меркля потребует приблизительно восемь последовательных запросов к базе данных на каждую запись.

Подход Solana к обновлению обязательства по состоянию только в конце каждой эпохи позволяет амортизировать затраты на запись на протяжении многих транзакций в этот период. Если запись состояния изменяется несколько раз в одной и той же эпохе, каждая запись не требует немедленного обновления корня Меркла. Это снижает общий вычислительный наклад на обновление состояния в течение эпохи. Следовательно, стоимость чтения из состояния остается постоянной или O(1), потому что состояние можно читать напрямую, не требуя обхода пути Меркла каждый раз.

Снижение частоты мерклизации в Ethereum может снизить накладные расходы на чтение и запись состояния, улучшая производительность. Однако легким клиентам придется повторно воспроизводить изменения блока для отслеживания состояния между эпохами или отправлять транзакции на цепочку для проверки состояния, и такое изменение в настоящее время несовместимо с Ethereum.

Эффективные & Специализированные Структуры Данных

Кроме того, слоистые деревянные структуры в существующих клиентах Ethereum обычно вызывают неэффективные шаблоны доступа к состоянию, что еще больше способствует увеличению объема состояния. Хотя состояние Ethereum структурировано как MPT, оно также хранится в базах данных клиентов Ethereum, таких как LevelDB,PebbleDB(используемый go-ethereum), или MDBX (используемый Erigon), хранящий данные в Merkle-деревьях, таких как B-TreeилиДерево LSM.

В этой настройке структура данных укоренена в другую структуру данных отдельного типа, создавая "усиление чтения" при навигации внутренними древовидными структурами поверх клиентов, работающих в рамках другой системы на основе дерева Меркля. Усиление чтения можно понимать как результат множественных шагов доступа или обновления информации, содержащейся в состоянии, что требует навигации по внешнему дереву для нахождения точки входа в MPT перед выполнением необходимой операции. В результате количество обращений к диску для случайного чтения умножается на логарифмический коэффициент (log(n)).

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

Еще одним узким местом, характерным для древовидных структур, является то, что доступ к данным или их обновление требует прохождения через несколько уровней, что приводит к многочисленным последовательным доступам к диску.Суверенные лабораторииaddresses this inefficiency by advocating for a binary Merkle tree configuration. This pivotal shift to a binary structure drastically reduces the number of potential paths during tree traversal, directly reducing the hash computations needed for updates, insertions, and cryptographic proofs.

Конфигурация бинарного дерева Меркля из "Почти оптимальной мерклизации состояния" Sovereign Labs

Дополнительным примером в этой категории является команда Reth, настраивающая Rethпредварительно извлекать промежуточные узлы trie с диска во время выполненияпутем уведомления службы корневой системы о занимаемых слотах хранения и затронутых учетных записях.

Состояние истечения

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

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

Существует несколько обсуждаемых методов для реализации истечения срока состояния:

• Истечение срока по аренде: Этот метод предполагает взимание абонентской платы или "аренды" для поддержания активности учетных записей в базе данных государства. Если арендная плата не оплачивается, учетные записи архивируются до тех пор, пока не будет уплачена плата за их восстановление.
• Срок действия по времени: Здесь учетные записи считаются неактивными, если они не были использованы — то есть не было никаких транзакций или взаимодействий — в течение определенного периода.

Оба метода нацелены на поддержание только активно используемых данных в непосредственном, доступном состоянии, выталкивая более старые, реже запрашиваемые данные в архивное состояние, которое не нагружает основную систему.

Поддерживая более маленькое и управляемое состояние, истечение срока действия состояния снижает "неразумное увеличение" состояния, которое может серьезно затруднить производительность блокчейна. Меньший размер состояния позволяет узлам быстро перемещаться и обновлять состояние, что приводит к более быстрому выполнению, поскольку узлы тратят меньше времени на сканирование и больше времени на обработку.

Распределение выполнения

Шардинг оптимизирует использование ресурсов и производительность путем распределения задач и данных между ограниченным числом специализированных узлов (не каждый узел выполняет глобальное состояние).

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

Диаграмма шардинга из статьи Виталика "Пределы масштабируемости блокчейна"

Это становится очевидным при изучении NEAR Протоколадизайн шардинга,Паслен, который достигает состояния безгосударственности для масштабирования шардинга без ущерба для минимизации доверия.

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

Подобно разделению построителя-владельца (PBS) на Ethereum, Nightshade явно определяет роли узлов, имеющих состояние, и узлов без состояния. На NEAR состояние валидаторов назначается на конкретные образцы и они несут ответственность за сбор транзакций, их выполнение и производство образцов, специфичных для образца. Они поддерживают полное состояние своего назначенного образца и генерируют свидетельства состояния для использования валидаторами во время процесса проверки.

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

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

Решения: неэффективные вычисления

Параллельное выполнение

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

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

• Параллельный доступ к состоянию
• Параллелизация конкретных операций
• Параллелизация согласования и выполнения

Параллельный доступ к состоянию

Параллельный доступ к состояниюприносит два критически важных преимущества:

• Параллельные EVM распределяют обработку транзакций по нескольким ядрам ЦП. Эта настройка позволяет обрабатывать несколько транзакций параллельно, а не заставлять их стоять в очереди для одного ресурса.
• Когда транзакция ожидает данных из хранилища, что может привести к значительной задержке, система не остается бездействующей. Вместо этого она может переключиться на другую транзакцию, которая готова к выполнению. Это возможно, потому что несколько ядер могут обрабатывать разные задачи независимо и одновременно.

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

Пессимистичное исполнение

Пессимистичная модель исполнения - это способ обработки транзакций, требующий, чтобы транзакции объявляли состояние переменных, к которым они будут обращаться (чтение или запись) во время выполнения. Эта информация включается в метаданные транзакции, что позволяет среде выполнения проанализировать образцы доступа перед выполнением.

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

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

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

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

В Уровень морявремя выполнения, которое реализует эту пессимистичную модель выполнения, транзакции указывают учетные записи, которые они будут читать или записывать во время выполнения. Sealevel анализирует образцы доступа и конструирует параллельные очереди транзакций для каждого потока ЦП на узле валидатора. Если к учетной записи обращаются несколько раз, она перечисляется последовательно в одной очереди, чтобы предотвратить конфликты. Транзакции, которые не обрабатываются в течение времени блока узла-лидера, упаковываются и пересылаются следующему запланированному лидеру для обработки.

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

Определяя, какие контракты будут затронуты, транзакции, которые касаются непересекающихся наборов контрактов, могут быть выполнены параллельно путем выполнения узлов (что может быть достигнуто в модели данных "счета" с жесткими списками доступа). Однако для совместимости со смарт-контрактами в стиле Ethereum, схемы UTXO, такие как ограничивают узлы, производящие блоки, выполнять транзакции с перекрывающимися списками доступа последовательно.

Тем не менее, пессимистичная модель исполнения имеет ограничения. Транзакции должны точно объявлять свои образцы доступа заранее, что может быть сложным для сложных или динамичных транзакций, где образцы доступа могут зависеть от входных данных или условной логики. Неточные или неполные объявления образца доступа могут вызвать неоптимальную производительность и потенциальные ошибки времени выполнения. Кроме того, механизм блокировки может вводить задержки и уменьшать параллельность, когда множество транзакций конкурируют за те же переменные состояния. Эта конкуренция может стать причиной узких мест в производительности, поскольку транзакции могут проводить значительную часть своего времени выполнения в ожидании захвата блокировок на переменных состояния с высоким спросом.

Более важно, эту модель накладывает значительное бремя на разработчиков, которые должны иметь глубокое понимание зависимостей данных их контрактов, чтобы точно указать необходимые доступы к состоянию заранее. Эта сложность может принести вызовы, особенно при проектировании приложений с динамическими и сложными взаимодействиями состояний, таких как децентрализованные биржи или автоматизированные торговые роботы.

Оптимистичное выполнение

В отличие от пессимистичной модели исполнения, оптимистичная модель принимает «спекулятивный» подход к исполнению транзакций, позволяя транзакциям выполняться параллельно без необходимости декларирования доступа к состоянию заранее.

Вместо того, чтобы предотвращать конфликты до их возникновения, транзакции оптимистично выполняются параллельно, предполагая, что они независимы. Время выполнения использует техники, такие как многоверсионный контроль параллелизма(MVCC) и программная транзакционная память (STM) для отслеживания наборов чтения и записи во время выполнения. После выполнения время выполнения обнаруживает любые конфликты или зависимости. Он принимает корректирующие меры, такие как отмена и повторное выполнение конфликтующих транзакций, но может сделать это, считывая из памяти вместо диска для идентификации конфликтующих транзакций.

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

Одна из заметных реализаций этой модели находится в Aptosи MoveVM ofЛаборатория движения*, которая использует технику, известную как Block-STM. В Block-STM транзакции сначала выполняются параллельно; затем конфликтующие транзакции идентифицируются и планируются к повторному выполнению на основе обнаруженных зависимостей. Такой подход обеспечивает непрерывное использование ресурсов обработки, увеличивая пропускную способность при сохранении целостности рабочего процесса транзакции.

Блок-STM от Aptos из "Масштабирование выполнения блокчейна, превращая проклятие упорядочения в благословение производительности"

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

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

Кроме того, модель учетной записи, используемая MoveVM, отличается от используемой в Ethereum EVM, что приводит к меньшему количеству коллизий. В Ethereum токен обычно управляется одним смарт-контрактом, что потенциально может вызвать взаимодействие нескольких токенов через один и тот же адрес контракта, увеличивая вероятность конфликтов. В отличие от этого, MoveVM назначает токены отдельным учетным записям пользователей, уменьшая вероятность таких конфликтов, поскольку каждая транзакция обычно взаимодействует с различными адресами учетных записей.

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

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

Параллелизм данных и задач

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

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

Параллелизм данных

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

Одним из распространенных методов параллелизма данных является одиночная инструкция, множественные данные(SIMD), что позволяет выполнять одну инструкцию одновременно на нескольких элементах данных. Современные ЦП часто имеют встроенные возможности SIMD, позволяющие выполнять параллельные операции над несколькими точками данных. Используя инструкции SIMD, разработчики могут достичь значительного ускорения определенных типов операций, таких как математические вычисления, преобразования данных или обработка сигналов.

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

Работа Firedancer на ED25519проверка подписи демонстрирует мощь SIMD для оптимизации сложных вычислений. Процесс проверки подписи включает арифметические операции в полях Галуа, которые могут быть вычислительно интенсивными. За счет использования инструкций SIMD Firedancer может выполнять эти операции над несколькими элементами данных параллельно, что приводит к значительному улучшению производительности. Эти оптимизации будут критически важны для улучшения производительности Solana, которая уже реализовала параллелизацию доступа к состоянию.

Параллелизм задач

Параллелизм задач включает параллелизацию различных задач или операций в программе на нескольких вычислительных устройствах. Этот подход полезен, когда программа состоит из нескольких независимых задач, которые могут выполняться параллельно. Путем назначения каждой задачи отдельному вычислительному устройству, такому как ядро ЦП или ГПУ, общее время выполнения может быть сокращено.

Параллельное выполнение задач часто используется в ситуациях, где программа должна одновременно выполнять несколько сложных операций. Например, рассмотрим приложение обработки видео, которое должно применять различные фильтры и эффекты к видеопотоку в реальном времени. Вместо использования каждой вычислительной единицы для коллективного последовательного применения каждого фильтра, параллельное выполнение задач может распределить нагрузку между несколькими вычислительными устройствами. Одно вычислительное устройство может быть ответственным за применение фильтра размытия, в то время как другое устройство применяет фильтр коррекции цвета и так далее. Выполняя эти задачи параллельно, приложение может достигнуть более быстрой обработки и обеспечить плавный пользовательский опыт.

Лагранжа @lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) использует параллелизм данных и задач для эффективного распараллеливания и создания доказательств распределенных вычислений на больших наборах данных. На этапе сопоставления входной набор данных разбивается на более мелкие фрагменты, и каждый фрагмент обрабатывается независимо отдельным рабочим процессом или компьютером сопоставления параллельно (параллелизм задач). Операция сопоставления может быть распараллелена в рамках каждой задачи сопоставления между несколькими ядрами или процессорами (параллелизм данных). Аналогичным образом, на этапе сокращения операция "reduce" для значений, связанных с каждым ключом, может быть распараллелена в рамках каждой задачи сокращения (параллелизм данных). В отличие от этого, задачи редюсера выполняются параллельно для нескольких рабочих ролей (параллелизм задач).

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

Проверка произвольной процедуры MapReduce в ZK из “Введение в ZK MapReduce” Лагранжа

Возможность Лагранжа генерировать доказательства хранения для вычислений SQL над @lagrangelabs/объявление-тестовой-сети-euclid-первая-проверяемая-база-данных-и-zk-coprocessor-cc4a5595365c">888,888 хранилищ за 1 минуту 20 секунд демонстрируют мощь ZKMR, а также задачу и параллелизм данных, на которых она основана. Более того, недавний Лагранжев Reckle Treesстатья подчеркивает необходимость параллелизма, поскольку она обеспечивает вычисление пакетных доказательств ончейн-данных также в 𝑂(log𝑛), независимо от размера пакета.

Параллелизация Консенсуса & Выполнение

Хотя в этой статье не затрагивается вопрос согласованности, блокчейны также могут параллельно выполнять процесс согласования и исполнения. Традиционные блокчейны часто обрабатывают транзакции последовательно, достигая согласия относительно транзакций блока (блок N), прежде чем выполнять их. Параллельная обработка фаз согласования и исполнения значительно повышает эффективность исполнения и является техникой, примером которой являются системы, такие как Monad. Поскольку сеть достигает согласия по блоку N, она одновременно выполняет транзакции для предыдущего блока (N-1).

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

Переводчики и снижение накладных расходов

Когда смарт-контракты написаны на языках, таких как Solidity, они сначала компилируются в более низкоуровневый байткод. Затем EVM использует интерпретатор для выполнения этого байткода. Интерпретатор читает и выполняет каждую инструкцию последовательно, подобно переводу иностранного языка в реальном времени, когда он произносится. Парадигма's последний материал о Rethуказывает на то, что это приводит к накладным расходам, поскольку каждая инструкция должна быть обработана индивидуально и преобразована из байткода в машинные инструкции во время выполнения.

Reth решает проблемы неэффективности EVM, интегрируя компилятор JIT (Just-In-Time). Этот компилятор переводит байткод в машинный код непосредственно перед выполнением, обходя ресурсоемкий процесс интерпретации, обычно требуемый во время выполнения.

ВоротаСтатья Rethупоминает, что 50% времени выполнения EVM в системе на основе интерпретатора посвящено процессам, которые теоретически могли бы оптимизировать JIT, что указывает на возможность удвоения скорости выполнения с реализацией JIT. Однако, как отмечает Yilong вэта презентация, в то время как JIT может значительно сократить время, необходимое для обработки определенных операционных кодов, это может не существенно повлиять на общее выполнение. Это происходит потому, что существенная часть из 50% времени выполнения EVM, занимаемого JIT, включает в себяоперации "хост" и "системы" (Слайд 13), которые не поддаются JIT-оптимизациям, таким как «арифметика» или «контроль», из-за их невычислительной природы.

Хотя интерпретаторы могут ограничивать производительность, они создают возможность для "перевода", что увеличивает объем кода, который может использовать новые виртуальные машины, снижая накладные расходы для разработчиков при использовании дизайнерского блокспейса. Например, Movement Labs разработала Fractal, позволяющий разработчикам развертывать свои контракты, основанные на Solidity, на MoveVM. Fractal работает путем компиляции Solidity в промежуточный язык, содержащий инструкции, сформулированные в виде операций EVM, которые затем сопоставляются соответствующим байт-кодам MoveVM, что позволяет контрактам Solidity работать в среде MoveVM.

Специализированные и настраиваемые State-машины

Настройка уровня выполнения включает в себя разработку специализированных конечных автоматов, оптимизированных для конкретных приложений. Это не только означает, что среда выполнения может полностью отказаться от виртуальной машины, но и позволяет приложениям адаптировать архитектура набора инструкций (ISA), структуры данных и модель выполнения под их конкретные потребности. Ключевое преимущество в производительности инструкций ISA под конкретное приложение заключается в снижении накладных расходов на перевод вычислительных шаблонов приложения в инструкции общего назначения традиционной ISA. ЦП общего назначения используют базовые наборы инструкций (т.е. add, load, branch) для поддержки выполнения различных типов программного обеспечения. Однако, когда приложения часто повторяют одни и те же многоэтапные операции, реализация этих шаблонов с помощью последовательностей простых инструкций становится неэффективной.

Например, приложения баз данных могут постоянно обходить деревья структур данных, искать записи, обновлять значения и балансировать деревья. На обычном ЦП такие операции более высокого уровня требуют их разбиения на длинные последовательности микроопераций более низкого уровня, таких как загрузка, сохранение, ветвления и арифметические операции, выполняемые отдельно на общем оборудовании. В отличие от этого ISA, настроенный для баз данных, может объединять эти повторяющиеся шаблоны в оптимизированные более широкие инструкции, использующие специализированное оборудование. Инструкция "TraverseTree" может вычислять адреса памяти, загружать соответствующие узлы и сравнивать ключи с использованием параллельных схем сравнения, разработанных для этой операции. "UpdateEntry" может непосредственно получать запись из оптимизированной структуры хранения базы данных, изменять ее и фиксировать новое состояние, все это в одной инструкции.

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

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

В качестве альтернативы можно использовать универсальные среды выполнения, которые позволяют произвольно программируемым модулям, которые приложения могут подключать для оптимизации своей производительности. Этот подход придает приоритет опыту разработчика перед чистой производительностью.

БеглыйиCWDиспользуйте стратегию, которая находит баланс между оптимизацией вычислительной производительности и улучшением опыта разработчика и совместимости экосистемы. Этот подход сосредотачивается на использовании WebAssembly (Wasm) в качестве виртуальной машины для выполнения кода. Wasm стал предпочтительным выбором в веб-разработке благодаря широкой поддержке языков и широкому распространению его использования.

Решение разработчика использовать Wasm вместо нативного выполнения клиента отражает стратегическое предпочтение универсальности и широкой доступности общего среды выполнения. Хотя нативное выполнение, которое выполняет код напрямую на аппаратном обеспечении без виртуальной машины, может предложить лучшую производительность, оно ограничивает кросс-платформенную совместимость и менее доступно для разработчиков. В отличие от этого, Wasm обеспечивает унифицированную и безопасную среду выполнения на различных платформах, не достигая той же скорости, что и нативное выполнение. Этот компромисс соответствует философиям дизайна Fluent и CWD, приоритизируя производительность разработчика и более широкую интеграцию экосистемы над максимальной эффективностью производительности.

Развертывание CosmWasm (CWD), в частности, иллюстрирует этот подход, используя не только Wasm для выполнения смарт-контрактов, но и включая его в более обширную структуру, разработанную для поддержки тонкостей операций с блокчейном. Обогащенный «периферийной логикой», этот фреймворк предлагает расширенное управление учетными записями, настраиваемый механизм газа и оптимизированное упорядочение транзакций. Эти функции способствуют созданию гибкой, эффективной и безопасной среды разработки, которая позволяет разработчикам относительно легко создавать масштабируемые и сложные dApps.

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

Микро-роллап-дизайн Stackr из “Введение в Stackr SDK”

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

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

Заключение

Есть несколько путей к оптимальной производительности уровня исполнения.

Нет ни одной единственной оптимизации доступа к состоянию или параллелизации, которая является проприетарной точкой технического дифференцирования между слоями исполнения при попытке захвата dapps. По мере того, как мы прошлись, преимущества ресурсной параллелизации на Solana могут быть одинаково применены к UTXO-модели Fuel. Любой может использовать Amazon’sпроницательные решения для улучшения горизонтальной масштабируемости через шардинги улучшить производительность слоя выполнения.

В то время как производительность уровня исполнения является критическим вектором для завоевания строителей децентрализованных приложений, новые L1 и L2, сфокусированные на улучшении исполнения, должны конкурировать по другим переменным, включая безопасность, интероперабельность и совместимость с существующими инструментами. По этой причине распространение новых уровней интероперабельности — от Nebra до Statenet до AggLayer Polygon — будет критическим для разработчиков, покупающих дизайнерское блок-пространство, поскольку они могут создавать или покупать специализированное блок-пространство, не жертвуя синхронной композицией и общей ликвидностью традиционных универсальных L1.

Улучшения в управлении состоянием и вычислительной эффективности взаимосвязаны.

Среди сообществ, разрабатывающих новые уровни исполнения, параллелизация доступа к состоянию стала определяющим мемом для обещанных ими улучшений производительности. Хотя это имеет веские основания, так как это может привести к 5x улучшение в исполнении EVM, доказательства ранних экспериментов Monad по параллелизации показывают, что его роль переоценена, если другие улучшения, такие как асинхронный ввод/вывод, не разрабатываются параллельно.

Исходя из этого, мы можем заключить, что вычислительная эффективность часто достигается только тогда, когда мы улучшаем способы доступа к состоянию и его хранения. Эффективное управление состоянием сокращает время и ресурсы, необходимые для доступа и манипулирования данными, что ускоряет обработку и снижает вычислительную нагрузку.

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

В конце дня ценности блокпространства влияют на пространство дизайна для слоев исполнения.

Понимая, как мы можем улучшить слои выполнения, мы можем сейчас выделить, что классы оптимизаций различаются в зависимости от двух критических выборов дизайна — кто выполняет транзакции и сколько узлов должно быть вовлечено? Техники, доступные разработчикам для решения узких мест выполнения, значительно различаются в зависимости от первоначальных ответов команды на эти вопросы.

С одной стороны, монолитные L1-платформы, такие как Solana и Monad, не принимают разделение роли валидатора на гетерогенные мощные и слабые узлы для увеличения производительности. «Принятие» увеличения объема состояния в краткосрочной перспективе не является жизнеспособным решением, поэтому они полагаются на улучшения на уровне базы данных и других компонентов движка производства блоков, таких как консенсус, чтобы компенсировать более широкое количество исполняющих узлов, которое считается критическим компонентом и основной ценностью сети. Поскольку модели безопасности этих L1-платформ основаны на консенсусе более распределенного набора валидаторов с менее мощными аппаратными требованиями, их данные должны быть записаны в базу данных, которая находится на диске, что обязательно дешевле для разрешения и максимально децентрализованной блокчейн-сети.

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

Предположим, что централизованные "исполнители" транзакций и переходов состояния считаются приемлемыми при стремлении к децентрализованному будущему. В таком случае законы физики утверждают, что системы, способные 1) добавлять блоки к цепочке, не требуя повторного выполнения транзакций несколькими действующими лицами, 2) увеличивать требования к валидаторам для максимизации вычислений в памяти (и игнорировать проблему роста состояния), и 3) снижать задержки и узкие места в консенсусе, явно побеждают по сравнению с системами, полагающимися на обширную децентрализацию и согласование между узлами.

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

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

Как отмечает Sreeram, "минимальная жизнеспособная децентрализация" не означает, что "валидация должна быть безразрешительной", а означает, что она должна быть "просто правильно стимулированной". Это подразумевает, что хорошо контролируемая система, в которой валидаторы сталкиваются с серьезными последствиями за недобросовестное поведение, может поддерживать безопасность и живучесть без необходимости излишней децентрализации (Gateh/t Sreeram).

Такие модели управления уже тестируются в практических приложениях. Например, роллапы, такие как Arbitrum, изучают системы управления или комитеты для обеспечения порядка транзакций и выбора лидеров, и они рассматривают механизмы, при помощи которых последователи используют данные onchain для соблюдения политик порядка транзакций.

Несмотря на эти достижения, нет определенного "парето-оптимального фронтира" для балансировки децентрализации и производительности.

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

*обозначает компанию портфеля Archetype

Disclaimer:

1. Эта статья взята из [Gateзеркало )], Пересылка оригинального названия 'Designer Blockspace: The Future of Execution Environments', Все авторские права принадлежат оригинальному автору [Бенджамин Функ]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learn команды, и они оперативно с этим справятся.

2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.

3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.