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

Введение

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

Параллельная Вселенная

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

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

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

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

В части I этой серии мы сначала исследуем некоторые основы не криптографических параллельных систем, а затем пространство проектирования параллельного выполнения для блокчейнов, сосредотачиваясь на трех основных областях:

1. Обзор параллельных криптосистем
2. Подходы к доступу к памяти и состоянию
3. Возможности параллельного проектирования

Non-Crypto Параллельные Системы

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

1. Медицинская диагностика: Параллельная обработка фундаментально изменила медицинскую диагностику, приводя к значительному увеличению скорости и разрешения при работе с различными модальностями, такими как МРТ, КТ, рентген и оптическая томография. Nvidia находится на передовой этих достижений, предоставляя радиологам улучшенные возможности искусственного интеллекта благодаря своему набору инструментов для параллельной обработки, который позволяет системам диагностики эффективнее обрабатывать увеличивающиеся объемы данных и вычислений.
2. Астрономия: Некоторые новые явления, такие как понимание черных дыр, стали возможны только благодаря параллельным суперкомпьютерам.
3. Игровой движок Unity: движок Unity использует возможности GPU, которые предназначены для выполнения массивных графических нагрузок, чтобы помочь в повышении производительности и скорости. Движок оснащен многопоточными и параллельными функциями обработки, обеспечивая плавный игровой опыт и создание сложных детальных игровых сред.

Давайте рассмотрим три блокчейна, которые реализовали параллельные среды выполнения. Сначала мы изучим Solana, за которым последуют две цепочки на основе EVM, Monad и Sei.

Обзор параллельного дизайна – Solana

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

Solana использует детерминированную параллелизацию, которая происходит из опыта Анатолия работы с встроенными системами, где обычно все состояния объявляются заранее. Это позволяет ЦП знать все зависимости, что позволяет ему предварительно извлекать необходимые части памяти. Результатом является оптимизированное выполнение системы, но, опять же, это требует от разработчиков дополнительной работы заранее. На Solana все зависимости памяти для программы обязательны и указываются в составленной транзакции (т. е. Списки доступа), что позволяет времени выполнения планировать и эффективно выполнять несколько транзакций параллельно.

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

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

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

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

Обзор параллельного дизайна - Sei

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

Блокчейн Sei использует выполнение транзакций с помощью «Оптимистичного контроля параллелизма (OCC)». Одновременная обработка транзакций происходит, когда несколько транзакций одновременно активны в системе. В этом подходе к транзакциям есть две фазы: выполнение и проверка.

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

Источник: https://blog.sei.io/sei-v2-the-first-parallelized-evm/

Реализация Sei приводит к снижению комиссий за газ и расширению дизайн-пространства для разработчиков EVM. Исторически среды EVM ограничивались до <50 TPS, что заставляло разработчиков создавать приложения, следующие анти-паттернам. Sei V2 позволяет разработчикам подходить к секторам, которые обычно требуют высокой производительности и низких сборов, таким как DeFi, DePIN и игры.

Обзор параллельного дизайна - Монада

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

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

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

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

Уникальные подходы к доступу к состоянию и памяти

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

Доступ к состоянию Solana: AccountsDB / Cloudbreak

Solana использует горизонтальное масштабирование для распределения и управления данными состояния по нескольким устройствам SSD. Многие блокчейны сегодня используют общие базы данных (такие как LevelDB) с ограничениями на обработку большого количества одновременных чтений и записей данных состояния. Чтобы избежать этого, Solana создала собственную настраиваемую accountsDB, используя Cloudbreak.

Cloudbreak разработан для параллельного доступа к операциям ввода/вывода вместо полной зависимости от ОЗУ, которая по своей сути быстрая. Операции ввода/вывода (Input/Output) относятся к чтению данных с внешнего источника или записи данных во внешний источник, такой как диск, сеть или периферийное устройство. Изначально Cloudbreak использовал индекс в ОЗУ для сопоставления открытых ключей с учетными записями, удерживающими балансы и данные. Однако на момент написания этой статьи и версии 1.9 индекс был перемещен из ОЗУ на твердотельные накопители (SSD). Этот сдвиг позволяет Cloudbreak одновременно обрабатывать 32 операции в очереди (I/O), повышая пропускную способность по всему ряду SSD. Следовательно, данные блокчейна, такие как учетные записи и транзакции, могут быть эффективно доступны, как если бы они были в ОЗУ, используя файлы, отображенные на память. Ниже приведена иллюстративная иерархия памяти. Хотя ОЗУ быстрее, у нее меньше емкость, чем у SSD, и обычно она дороже:

Иллюстративная диаграмма иерархии памяти

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

Доступ к шести штатам: SeiDB

Sei переработал свое хранилище, SeiDB, чтобы решить несколько проблем: увеличение записи (сколько метаданных требуется для поддержания структур данных, чем меньше, тем лучше), раздутие состояния, медленные операции и постепенное снижение производительности. Новый редизайн теперь разбит на две части: хранилище состояния и фиксация состояния. Запись и проверка любых изменений данных обрабатывается фиксацией состояния, в то время как база данных, которая отслеживает все данные в любой момент, обрабатывается хранилищем состояния (ХС).

В Sei V2 используется фиксация состояния, использующая отображение памятиАрхитектура дерева IAVL (MemIAVL)Память, отображенное дерево IAVL, хранит меньше метаданных, что уменьшает хранение состояния и время синхронизации состояния, делая работу полной ноды намного проще. Память, отображенное дерево IAVL, представлено в виде трех файлов на диске (kv, ветвь, листья); следовательно, меньше метаданных нужно отслеживать, что помогает снизить хранение состояния более чем на 50%. Новая структура MemIAVL помогает снизить коэффициент усиления записи, поскольку уменьшает метаданные, необходимые для поддержания структур данных.

Обновленный SeiDB позволяет гибкую поддержку базы данных для уровня хранения состояния. Sei считает, что у различных узловых операторов будут разнообразные требования и потребности в хранении. Поэтому СС был разработан с учетом различных бэкэндов, обеспечивая операторам свободу и гибкость, например, PebbleDB, RocksDB, SQLite и т. д.

Доступ к состоянию: MonadDB

У доступа к состоянию Monad есть несколько важных тонкостей. Во-первых, большинство клиентов Ethereum используют два типа баз данных: базы данных B-Tree (т.е. LMDB) или базы данных слияния журналов (LSM) (т.е. RocksDB, LevelDB). Оба из них являются общими структурами данных, не явно разработанными для блокчейнов. Кроме того, эти базы данных не используют самые современные достижения в технологии Linux, особенно в отношении асинхронных операций и оптимизации I/O. Наконец, сам Ethereum управляет состоянием с использованием Патриция Меркл Три, которая специализируется на криптографии, верификации и доказательствах. Основная проблема заключается в том, что клиенты должны интегрировать этот конкретный Патриция Меркле дерево в более общие базы данных (т.е. B-Tree / LSM), что приводит к значительным недостаткам в производительности, таким как чрезмерный доступ к диску.

Все вышеперечисленное помогает создать почву для того, почему Monad решил создать собственную базу данных MonadDB, специально разработанную для более эффективной обработки данных блокчейна и доступа к состоянию. Некоторые ключевые особенности MonadDB включают параллельный доступ к базе данных, специальную базу данных, оптимизированную для данных Merkle Trie, эффективный доступ к состоянию при использовании стандартного объема ОЗУ, а также децентрализацию и масштабируемость.

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

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

Сводка сравнений для Solana против Sei против Monad

Заключение

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

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

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

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

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

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