Solayer Litepaper (RU)
SOLAYER CHAIN: Бесконечно масштабируемая аппаратно-ускоренная SVM-сеть
Jason Li, Chaofan Shou, Qi Su, Chaz Cui и Tony Ke
(lxj,shou,changzecui)@berkeley.edu, qisu@cs.ucsb.edu,
yuanyu.ke@link.cuhk.edu.hk
7 января 2025 г.
Мы представляем SOLAYER CHAIN — архитектуру блокчейна нового поколения, которая масштабирует единую глобальную машину состояний для достижения беспрецедентной пропускной способности, низкой задержки и надежной композиции. В отличие от традиционного вертикального масштабирования или шардированных роллапов, SOLAYER CHAIN поддерживает атомарные переходы состояний, распределяя нагрузку между микросервисами и специализированными аппаратными ускорителями. Она разгружает проверки подписей, фильтрацию транзакций, симуляцию предварительного выполнения, планирование и хранение данных на отдельные масштабируемые кластеры, каждый из которых оптимизирован для своей функции. Транзакции спекулятивно выполняются перед поступлением к секвенсору, а затем финализируются через гибридный консенсус Proof-of-Authority-and-Stake. Архитектура использует Infiniband RDMA для межузловой коммуникации с задержкой порядка микросекунд и передовые стратегии управления параллелизмом для минимизации повторного выполнения. Хранилище ключ-значение без общей памяти, разделенное на несколько узлов, поддерживает произвольно большие данные аккаунтов с балансировкой нагрузки. SOLAYER CHAIN выводит производительность блокчейна на пределы аппаратного обеспечения, нацеливаясь на более 1М TPS и пропускную способность сети свыше 100 Гбит/с. Этот дизайн предоставляет путь для приложений следующего поколения, требующих высокой пропускной способности, низких комиссий и бесшовной композиционной среды. SOLAYER CHAIN также вводит множество улучшений пользовательского опыта. Хуки позволяют разработчикам внедрять пост-транзакционную логику — такую как арбитраж, ликвидации и бухгалтерский учет — непосредственно внутри цепочки, в то время как джамбо-транзакции, кросс-чейн вызовы и встроенная поддержка OAuth дополнительно улучшают опыт разработчиков и пользователей.
Отказ от ответственности: Информация, содержащаяся в этой статье, предоставляется исключительно для информационных и исследовательских целей и не является инвестиционным советом, финансовым советом, торговым советом или каким-либо другим видом рекомендаций. Детали реализации могут изменяться и отличаться от описанных здесь.
Масштабируемость блокчейна остается фундаментальной проблемой для децентрализованных систем, поскольку растущие объемы транзакций требуют более быстрой обработки, большего объема хранилища данных и надежных протоколов консенсуса — всё это без компромиссов по безопасности или децентрализации. Высокопроизводительные блокчейны могут сократить время и комиссии за транзакции, улучшить пользовательский опыт и открыть двери для масштабных приложений. По мере зрелости отрасли спрос на блок-пространство продолжает расти. На платформах, таких как Ethereum, повышенный спрос увеличивает комиссии за газ из-за аукционов на комиссии; на Solana переполненная сеть может привести к отклонению или истечению срока действия транзакций. Типичные метрики, такие как транзакции в секунду (TPS), освещают пропускную способность, однако блокчейны превзошли простые переводы и теперь поддерживают полнофункциональные смарт-контракты и сложную функциональность. Для удовлетворения этих требований необходимо переосмыслить, как предоставляется блок-пространство и как управляется состояние.
Горизонтальные подходы к масштабированию, такие как роллапы Layer 2 (L2) Ethereum, переносят обработку транзакций с основной цепочки в отдельные, независимо обновляемые состояния, возвращая окончательные результаты обратно на L1. Хотя это увеличивает пропускную способность, оно фрагментирует когда-то единую глобальную состояние, ослабляя композиционность, атомарные переходы состояний и ликвидность. Например, если актив разделен между несколькими пулами на разных роллапах, своп между роллапами может страдать от более высокого проскальзывания по сравнению с одним, объединенным пулом ликвидности. Вертикальные стратегии масштабирования, например, Solana, стремятся максимизировать пропускную способность внутри единой машины состояний, оптимизируя виртуальную машину для параллельного выполнения, пишут высокопроизводительное программное обеспечение и работают на мощном потребительском аппаратном обеспечении. Это сохраняет атомарность транзакций и упрощает выполнение, позволяя системе координировать изменения чисто и поддерживать композиционность. Успех Solana в размещении многочисленных запусков токенов и генерации больших объемов торговли на блокчейне отражает силу этого дизайна.
Несмотря на свои преимущества, подход Solana сталкивается с внутренними аппаратными ограничениями. Чтобы соответствовать текущей пропускной способности, валидаторам уже требуются процессоры с частотой выше 3,1 ГГц, более 500 ГБ высокоскоростной оперативной памяти и как минимум 2,5 ТБ высокопроизводительного NVMe-хранилища. С загрузкой ЦП около 30% при высокой нагрузке дальнейшие улучшения только за счет программной оптимизации ограничены. Вместо этого становится необходимым дополнительное ускорение — например, разгрузка некоторых задач на FPGA — для достижения еще более высокой производительности. Более того, валидаторы должны хранить и получать доступ к постоянно расширяющимся данным аккаунтов. Стандартное потребительское оборудование неизбежно будет заменено специализированными решениями, такими как NVMe-oF, для масштабирования хранилища без ущерба для низкой задержки. Аналогично, пропускная способность сети сталкивается с давлением: пиринговая (P2P) коммуникация уже потребляет около 0,8 Гбит/с на валидатор, что создает риск превышения интернет-лимита в 1 Гбит/с, типичного для потребительских сетевых сред, если пропускная способность продолжит расти.
Рисунок 1: Архитектура системы
Чтобы решить эти возникающие узкие места, мы выступаем за мульти-исполнительную, аппаратно-ускоренную SVM-сеть. Дизайн показан на Рисунке 1. Этот дизайн бесконечно масштабирует блокчейн с единой машиной состояний, распределяя нагрузку между специализированным оборудованием и кластерами, сохраняя при этом глобальное атомарное состояние. В следующих разделах описывается, как эта архитектура декомпозирует критические стадии конвейера на микросервисы для масштабирования неатомарных компонентов, таких как входящий трафик и публикация состояния, аппаратное ускорение для планирования и блокировок, шардированная база данных для масштабирования хранения и новый гибридный консенсусный протокол на основе Solana, который гарантирует как безопасность, так и низкую задержку. Для дальнейшего повышения удобства использования SOLAYER CHAIN вводит поддержу хуков на уровне цепочки, кросс-чейн вызовы контрактов, джамбо-транзакции, бесшовную поддержку кошельков и подписантов на основе OAuth. В целом, SOLAYER CHAIN стремится стать самой удобной цепочкой с более чем 1М TPS и пропускной способностью сети свыше 100 Гбит/с.
В следующих подразделах мы представляем предпосылки технологий, используемых SOLAYER CHAIN.
Solana представляет собой новую архитектуру блокчейна, которая кардинально отличается от традиционных механизмов консенсуса благодаря своему протоколу Proof-of-History (PoH) и параллельной среде выполнения. SVM использует архитектуру "shared-nothing", где наборы чтения и записи каждой транзакции определяются перед выполнением. Это позволяет рантайму строить граф зависимостей, максимально увеличивая параллельное выполнение при сохранении гарантий сериализуемости. В отличие от последовательной модели выполнения Ethereum Virtual Machine (EVM), SVM обрабатывает неконфликтующие транзакции одновременно на доступных ядрах ЦПУ. Модель памяти SVM реализует механизм контроля параллелизма с множественными версиями (MVCC), поддерживая несколько версий данных для поддержки одновременных операций чтения, обеспечивая при этом строгий порядок сериализации операций записи на основе последовательности PoH.
EVM и SVM демонстрируют противоположные подходы к контролю параллелизма. EVM использует оптимистичный контроль параллелизма, при котором транзакции обрабатываются одновременно с предположением, что конфликты будут редкими. Однако, поскольку транзакции не объявляют свои доступы к состоянию заранее, конфликты — такие как одновременные попытки изменения одного и того же состояния — обнаруживаются только во время выполнения, требуя откатов и повторных попыток. В отличие от этого, SVM использует пессимистичный контроль параллелизма, при котором транзакции должны объявлять свои паттерны доступа к состоянию заранее. Это позволяет параллельному движку выполнения Solana Sealevel выполнять неконфликтующие транзакции одновременно, полностью избегая конфликтов. Комбинируя явные объявления доступа к состоянию с продвинутыми моделями памяти и выполнения, Solana достигает непревзойденной масштабируемости и эффективности в обработке блокчейнов.
Удаленный прямой доступ к памяти (RDMA) позволяет осуществлять передачу данных без копирования непосредственно между пространствами памяти приложений через сетевые системы. Современные реализации RDMA используют специализированные сетевые интерфейсные карты (RNIC), которые реализуют как транспортный протокол, так и операции прямого доступа к памяти в аппаратуре. Эта архитектура обходит традиционные сетевые стеки операционных систем, устраняя переключения контекста и нагрузку на ЦПУ, связанные с обработкой сетевых операций ввода-вывода. Набор протоколов RDMA реализует как ориентированные на соединение (Reliable Connected), так и безсоединительные (Unreliable Datagram) режимы транспорта, при этом первый обеспечивает гарантированную упорядоченную доставку, а второй оптимизирован для сценариев с низкой задержкой, где приложения могут терпеть потенциальную потерю пакетов. Семантика памяти протокола позволяет завершать удаленные операции памяти без прерывания удаленного ЦПУ, достигая конечных задержек ниже одной микросекунды для небольших сообщений в оптимизированных развертываниях. Это достигается через сложную модель защиты, где области памяти должны быть явно зарегистрированы в RNIC, который затем поддерживает таблицы страниц для прямого виртуального в физический адресный перевод.
InfiniBand — это выдающаяся реализация RDMA, предлагающая высокоскоростную, низколатентную сетевую архитектуру, ориентированную на высокопроизводительные вычисления и центры обработки данных. Она использует адаптеры Host Channel Adapters (HCA) для разгрузки обработки протоколов и перевода памяти на аппаратуре, тем самым снижая участие ЦПУ в операциях передачи данных. InfiniBand поддерживает скорости передачи данных от 10 Гбит/с (Single Data Rate) до 100 Гбит/с на порт, используя как медные, так и оптические волоконные соединения. Эта высокая пропускная способность, в сочетании с ультранизкими задержками — до 600 наносекунд от конца до конца — делает InfiniBand особенно эффективной для приложений, требующих быстрого обмена данными, таких как искусственный интеллект и высокопроизводительные вычислительные нагрузки. Ее эффективность и масштабируемость привели к широкому принятию в распределенном машинном обучении и других ресурсоемких приложениях.
2.3 Программно-определяемые сети
Программно-определяемые сети (SDN) разделяют управляющую плоскость и плоскость данных, позволяя программируемо контролировать поведение сети через логически централизованный контроллер. Современные архитектуры SDN реализуют трехуровневую модель: плоскость данных состоит из программируемых элементов пересылки, которые обрабатывают пакеты на основе правил сопоставления-действия, плоскость управления реализует сетевые политики и вычисление маршрутов, а плоскость управления предоставляет высокоуровневую оркестрацию сети.
Плоскость пересылки эволюционировала от фиксированных таблиц сопоставления-действия до полностью программируемых конвейеров обработки пакетов с использованием языков, таких как P4, позволяя реализовывать пользовательские протоколы и сложные трансформации пакетов на скорости передачи данных. Контроллеры SDN реализуют распределенные консенсусные протоколы для поддержания согласованности состояния сети между репликами контроллеров, предоставляя при этом северо-восточные API, которые абстрагируют сложность сети для приложений. Плоскость пересылки обычно использует архитектуру конвейера, где пакеты проходят через несколько стадий сопоставления-действия, каждая из которых способна выполнять произвольные модификации заголовков пакетов и поддерживать локальное состояние. Эта программируемость позволяет реализовывать сложные сетевые функции, такие как балансировка нагрузки, инженерия трафика и виртуализация сети непосредственно в плоскости данных при сохранении производительности на уровне линии.
3. Масштабирование обработки транзакций
Общая архитектура SOLAYER CHAIN изображена на Рисунке 1. Каждая транзакция достигает начальной точки входа, где проводится проверка подписи (sigverify) и локальная дедупликация. Проверенная транзакция затем отправляется в кластер предварительного выполнения, который проводит предварительное выполнение. Мы обсуждаем этот конвейер в подразделе 3.1. Эффект транзакции и промежуточные снимки отправляются секвенсору через Infiniband. Секвенсор использует SDN-коммутатор и дополнительный FPGA для принятия решения, должна ли транзакция пройти простой путь (т.е. все аккаунты транзакции находятся на последней версии при предварительном выполнении) или сложный путь (т.е. хотя бы один аккаунт имеет более новую версию). Для транзакции простого пути изменение состояния напрямую применяется через RDMA с локальным кэшем на SDN. Для транзакции сложного пути она попадает в локальный мемпул с субмиллисекундной скоростью обработки. Секвенсор планирует транзакции в локальном мемпуле для достижения справедливого и оптимального параллельного выполнения всех транзакций. Алгоритм планирования описан в подразделе 3.2. Мы обсуждаем распределенную базу данных, которая хранит данные аккаунтов в подразделе 3.3. После выполнения транзакции и записи изменения состояния, транзакция распространяется через глобальные PoPs.
Рисунок 2: Количество транзакций, требующих повторного выполнения, по сравнению с количеством транзакций, отставших у исполнителя.
Конвейер обработки транзакций SOLAYER CHAIN отражает некоторые основные стадии Solana: проверка подписи (sigverify), дедупликация, планирование, банковские операции и хранение. Банковские стадии по своей природе последовательны, требуя либо крупнозернистых блокировок, либо однопоточного выполнения для поддержания согласованности. Однако, в то время как Solana выполняет эти стадии в монолитной архитектуре, операции проверки подписи, дедупликации и хранения могут быть разделены и распределены. SOLAYER CHAIN использует это наблюдение, декомпозируя эти стадии на независимые микросервисы, развернутые по эластичной вычислительной инфраструктуре. Наша система реализует динамическое выделение ресурсов через контроллер, основанный на обратной связи, который мониторит входящие потоки транзакций и автоматически масштабирует вычислительную мощность.
Ключевым моментом в нашем дизайне является то, что значительная часть транзакций может быть предварительно выполнена независимо, при условии, что они не демонстрируют зависимостей чтения-записи на аккаунтах, к которым обращаются конкурирующие транзакции (т.е. не происходит грязного чтения). Согласно Рисунку 2, симуляция предварительного выполнения транзакций из 1000 слотов, начиная с 304992000, показывает, что только 2% транзакций необходимо повторно выполнить из-за грязного чтения, даже если исполнитель значительно отстает от цепочки. Опираясь на это наблюдение, SOLAYER CHAIN вводит стадию симуляции, предшествующую планированию транзакций. Эта стадия, которую можно горизонтально масштабировать по узлам, выполняет спекулятивное выполнение транзакций против наиболее недавно зафиксированного состояния на узле. Во время симуляции система захватывает как эффекты транзакций, так и набор промежуточных снимков выполнения на границах доступа к аккаунтам. Хотя некоторые транзакции могут демонстрировать конфликты из-за перекрывающихся паттернов доступа к аккаунтам, наш подход позволяет параллельное предварительное выполнение большинства неконфликтующих транзакций.
Отметим, что транзакции, выполняющие только операции чтения, могут быть полностью проверены и подтверждены на границе, полностью обходя центральную банковскую стадию. Для дальнейшего снижения перегрузки конфликтующих транзакций транзакции, обращающиеся к "горячим" аккаунтам, могут быть предварительно выполнены для всех возможных будущих значений этих аккаунтов. Каждый аккаунт имеет краткосрочную модель прогнозирования, реализованную с использованием двойного экспоненциального сглаживания Winter-Holt (DESP) для каждого байта в аккаунте. В зависимости от частоты доступа к аккаунту оператор узла предварительного выполнения может вручную внедрить более точную модель прогнозирования, и транзакция может быть симулирована миллионами раз с различными возможными данными аккаунта. Для оставшихся транзакций, которые все еще конфликтуют с предыдущими мерами, при обнаружении конфликтов подписчик результатов симуляции может быстро восстановить правильное состояние выполнения из ближайшего действительного снимка в результатах симуляции, устраняя необходимость полного повторного выполнения транзакции. Этот дизайн значительно снижает вычислительные накладные расходы, традиционно связанные с банковской стадией, при сохранении строгих гарантий согласованности.
3.2 Планирование транзакций с учетом семантики
Модель обработки транзакций Solana использует анализ паттернов доступа на уровне аккаунтов для пакетирования транзакций, предотвращая грязные чтения через строгую изоляцию. Планировщик разделяет транзакции на пакеты на основе их заявленных паттернов доступа к аккаунтам, оптимизируя для параллельного выполнения. Хотя этот подход позволяет выполнять транзакции без блокировок внутри пакетов на стадии банковских операций, он по своей сути консервативен, рассматривая все обращения к аккаунтам внутри транзакции как конкурирующие. SOLAYER CHAIN расширяет эту модель, вводя детализированное прогнозирование последовательности операций чтения-записи. Анализируя временной порядок обращений к аккаунтам внутри транзакций, наша система строит оптимизированное расписание блокировок, позволяющее параллельное выполнение транзакций, обращающихся к одним и тем же аккаунтам, когда их фактические последовательности операций чтения-записи не конфликтуют во время выполнения. Этот динамический подход к планированию значительно снижает конкуренцию за блокировки, сохраняя при этом гарантии сериализуемости.
SOLAYER CHAIN использует свою стадию симуляции для получения оценочных последовательностей операций чтения-записи транзакций до их вступления в фазу планирования. Формально, для транзакции t мы определяем ее след выполнения как последовательность:
E(t) = {(op1, a1, c1), (op2, a2, c2), ..., (opn, an, cn)}
где opi ∈ {read, write} представляет тип операции, ai представляет доступный аккаунт, а ci представляет предсказанную временную стоимость выполнения между opi и opi+1. Для любых двух транзакций ti и tj с перекрывающимися аккаунтами A(ti) ∩ A(tj), мы определяем временную последовательность Sa(t) для аккаунта a как упорядоченную последовательность операций {(opk, tk)|ak = a}, где tk — относительная временная метка. Вычислительный разрыв между последовательными операциями определяется как Gk = ck · α, где α — среднее время выполнения инструкции. Две транзакции могут выполняться параллельно, если для всех a ∈ A(ti) ∩ A(tj) их последовательности Sa(ti) и Sa(tj) не имеют конфликтов записи-записи, и для любых пар чтение-запись (read, tk) ∈ Sa(ti), (write, tl) ∈ Sa(tj) разрыв Gk > δ, где δ — настраиваемое число, представляющее ошибку оценки, которую могут сделать симуляции. Обратите внимание, что хотя цель состоит в том, чтобы найти расписание без блокировок, блокировка всё же используется во время выполнения, поскольку расписание основано на оценке и может быть некорректным. Учитывая, что эта проблема аналогична задаче упаковки бинов, лучший алгоритм для решения оптимального расписания является NP-трудным. Чтобы гарантировать, что расписание может быть найдено на уровне субмиллисекунд, мы используем алгоритм "Shortest Makespan First" (SMF), жадный алгоритм, широко используемый в системах баз данных, для нахождения близкого к оптимальному расписания.
Кроме того, SOLAYER CHAIN использует ансамбль параллельных планировщиков, который одновременно исследует несколько стратегий планирования для оптимизации пропускной способности транзакций. Ансамбль включает в себя несколько оригинальных алгоритмов разделения аккаунтов Solana в качестве базового уровня, а также алгоритм SMF. Каждый алгоритм в ансамбле генерирует кандидатное расписание с оценочной временной стоимостью, и планировщик выбирает расписание с наименьшей временной стоимостью.
3.3 Шардированная база данных с RDMA
Системы блокчейнов сталкиваются с серьезными проблемами масштабируемости из-за постоянно растущего размера состояния. Например, состояние Ethereum в настоящее время превышает 1,1 ТБ, что подчеркивает необходимость эффективных решений для управления состоянием. Хотя хранение этих данных в памяти критично для доступа с низкой задержкой, ограничения памяти отдельных серверов требуют распределенного подхода. SOLAYER CHAIN реализует сложный механизм шардирования на основе архитектуры хранилища ключ-значение, сопоставляя 32-байтовые адреса аккаунтов с соответствующими данными состояния. В отличие от Solana, которая накладывает ограничение на размер данных аккаунта в 10 МБ, SOLAYER CHAIN поддерживает произвольные размеры данных для каждого аккаунта.
Каждый узел базы данных в SOLAYER CHAIN хранит шард данных. Основная архитектура каждого узла базы данных SOLAYER CHAIN состоит из трех основных компонентов. Во-первых, таблица переходов, находящаяся в памяти, поддерживает сопоставления между адресами аккаунтов и соответствующими адресами памяти, длиной данных и номером версии (т.е. сколько раз аккаунт был записан). Во-вторых, смежный регион данных хранит фактические данные состояния аккаунтов вместе с сопутствующими примитивами синхронизации и метаданными. Мы наблюдаем, что большинство изменений состояния в Solana не изменяют длину данных в аккаунте. В редких случаях изменения размера состояния данные аккаунта могут не храниться в смежной памяти и позже перераспределяться в смежную память во время рутинного балансирования. В-третьих, локальный кэш в памяти поддерживает часто запрашиваемые данные аккаунтов с использованием политики вытеснения LRU (Least Recently Used) для сокращения количества сетевых обращений к популярным аккаунтам.
Чтобы обеспечить эффективный доступ к данным между узлами исполнителя, SOLAYER CHAIN использует протокол InfiniBand RDMA (Remote Direct Memory Access). Этот подход предлагает несколько преимуществ: доступ к данным с ультранизкой задержкой (на уровне наносекунд) между узлами, обход накладных расходов операционной системы, снижение использования ЦПУ во время передачи данных и перемещение данных без копирования между узлами. Инфраструктура RDMA позволяет SOLAYER CHAIN поддерживать высокую производительность даже когда данные нужно получить с удаленных узлов, обеспечивая стабильную скорость обработки транзакций в распределенной системе.
Система реализует динамическое балансирование нагрузки через фоновый механизм перераспределения, который работает в периоды низкой сетевой активности. Этот процесс мониторит паттерны доступа к аккаунтам, анализирует исторические следы доступа к памяти и перераспределяет данные между узлами для оптимизации локальности и минимизации необходимости удаленного доступа к данным для распространенных паттернов транзакций. Процесс перераспределения учитывает несколько факторов, включая частоту доступа к аккаунтам, размер данных, топологию сети, ограничения по емкости узлов и текущее распределение нагрузки. Этот адаптивный подход гарантирует, что часто совместно используемые данные находятся на одном узле, уменьшая необходимость удаленного доступа к данным и улучшая общую пропускную способность транзакций.
Существующие дизайны на основе роллапов обычно разгружают проверку на большой набор обычных валидаторов, которые должны реконструировать или оспаривать транзакции, размещенные на Layer 1 (L1). Однако проверка потоков транзакций на скорости 1 Гбит/с превышает возможности большинства обычных узлов. Более того, размещение данных объемом 1 Гбит на любом слое доступности данных (DA) или L1 чрезвычайно дорого, что приводит к насыщению доступной пропускной способности и повышению комиссий на блокчейне. В результате мы вводим архитектуру Proof-of-Authority-and-Stake (не путать с Proof of Stake and Authority или PoSA): доверенное лицо выступает в роли секвенсора (лидера) и публикует шреды (набор транзакций в блоке), а каждый провайдер ставит и голосует, чтобы решить, может ли шред быть принят. Solana используется в качестве резервного консенсусного места, когда секвенсор ведет себя вредоносно.
Наш протокол группирует транзакции в шреды, каждая из которых содержит номер слота, вектор транзакций, метаданные версий для доступных аккаунтов и хэши связей (например, версию последнего шреда). Наличие версий аккаунтов критично, поскольку позволяет каждому шреду указывать точный контекст состояния, в котором секвенсор выполнил транзакции. Ссылаясь на эти версии состояния, любой узел, получивший шред, может восстановить соответствующую часть реестра и вычислить результирующий "эффект-хэш" — криптографический дайджест пост-транзакционных состояний. Только минимальная пара (Effect Hash, Shred Hash) публикуется на Solana для обеспечения доступности данных, в то время как большая часть объемных данных распространяется каждому провайдеру. Этот дизайн ограничивает накладные расходы на блокчейне и предотвращает насыщение емкости L1.
При получении шреда провайдер проверяет, содержит ли его локальный реестр правильную версию аккаунта. Если нет, он запрашивает недостающие шреды, необходимые для восстановления нужного состояния от лидера. Затем провайдер повторно выполняет все транзакции в шреде, получая эффект-хэш. Если локально вычисленный хэш совпадает с встроенным эффект-хэшом шреда, провайдер голосует за принятие шреда в SOLAYER CHAIN. Как только шред накапливает голоса от 51% выбранных провайдеров, секвенсор собирает доказательство для шреда и отмечает шред как финализированный, если все предыдущие шреды также финализированы. Если секвенсор предлагает недействительные или вредоносные шреды, честные провайдеры обнаружат несоответствия между ожидаемыми и вычисленными эффект-хэшами и проголосуют против них. В секвенсоре невозможно включить недействительные транзакции. Повторные нарушения отмечают секвенсор как офлайн, вызывая переключение на резервный секвенсор из набора Proof-of-Authority. Повторное избрание происходит на Solana как секвенсор, находящийся в состоянии сбоя, что означает, что SOLAYER CHAIN больше не может обрабатывать транзакции. Все честные провайдеры голосуют за переизбрание и переходят к следующему секвенсору, как только голосование достигает 2/3. Если 2/3 провайдеров не являются вредоносными, переизбрание может завершиться за секунды. Кроме того, чтобы сдерживать нечестных или ленивых провайдеров, секвенсор периодически распространяет преднамеренно недействительные шреды: любой провайдер, который "слепо" голосует за такой шред, автоматически штрафуется и исключается из дальнейших раундов. Этот механизм предотвращает пассивное принятие шредов и гарантирует, что каждый провайдер постоянно повторно выполняет транзакции. Для борьбы с цензурной устойчивостью, если секвенсор неоднократно игнорирует транзакцию (например, цензурирует ее), любой пользователь может вставить игнорируемую транзакцию в будущий шред, отправив данные транзакции на Solana соответствующей программе; отказ секвенсора принять транзакцию на Solana также маркирует его как неотзывчивого или вредоносного.
Поскольку для провайдеров нереалистично использовать дорогостоящее HPC-оборудование и аппаратные ускорители для отслеживания цепочки и проверки каждого шреда, секвенсор использует метод кругового выбора (round-robin) для случайного выбора только 2/3 онлайн-набора провайдеров для выполнения шреда. Провайдеры далее подразделяют задачу на разные узлы, которыми они владеют, используя метод кругового выбора. Если провайдер имеет 10 узлов, каждый узел должен обрабатывать только 1/15 всех шредов. Провайдеры могут использовать облако для масштабирования узлов для эластичной обработки большего трафика. Обратите внимание, что для достижения 51% голосов необходимо, чтобы только 4/5 выбранных провайдеров проголосовали за шред, что позволяет провайдерам быть недоступными. В крайних случаях, когда более 1/5 выбранных провайдеров недоступны, секвенсор должен выбрать дополнительных провайдеров для участия в проверке шреда. В противном случае секвенсор будет отмечен как офлайн. Секвенсор не имеет стимула проводить атаки типа отказа в обслуживании (например, всегда выбирая одних и тех же провайдеров для проверки всех шредов), поскольку если секвенсор больше не сможет финализировать блоки, он будет отмечен как офлайн.
Провайдеры получают комиссии от обработанных шредов и инфляционные награды $LAYER в качестве стимулов к участию. Однако, если они проявляют вредоносное поведение или неоднократно не обрабатывают шреды, они сталкиваются с многоуровневыми штрафными санкциями и исключаются из набора провайдеров до ручного повторного присоединения. Первое нарушение приводит к потере накопленных комиссий за этот эпох. Второе нарушение в этом эпохе влечет за собой штраф в 1% от поставленных токенов, а каждое последующее нарушение в рамках этого эпоха приводит к штрафу в 5% от ставки.
5. Улучшение пользовательского опыта
5.1 Интеграция без привязки к кошелькам и с приоритетом DApp
Традиционные интеграции цепочек требуют поддержки на уровнях как кошельков, так и dApp. Для L2 на основе EVM это обусловлено тем, что EIP-155 требует включения ID цепочки в полезную нагрузку подписи, что кошельки обеспечивают. Однако подписи транзакций SVM не включают ID цепочки в структуру транзакции. Вместо этого каждая транзакция содержит недавний хэш блока, и повторное воспроизведение транзакции на других цепочках просто приводит к ее отклонению. Во-вторых, в экосистемах EVM кошельки отвечают за распространение транзакций, тогда как в SVM dApp отвечает за распространение транзакций. Используя SDK SOLAYER CHAIN, dApps могут позволить пользователям создавать транзакции непосредственно на SOLAYER CHAIN с использованием любого кошелька, совместимого с Solana, без необходимости явной поддержки кошелька. Хотя прямая поддержка кошельков остается желательной для бесшовного отображения активов, она не является строгим требованием для выполнения транзакций и привлечения пользователей.
Во многих он-чейн средах повторное выполнение транзакций для обнаружения пост-выполнительных возможностей — таких как арбитраж, ликвидации или индексация аккаунтов в реальном времени — может быть вычислительно затратным для офф-чейн сущностей. Для решения этой проблемы мы вводим Hooks: механизм, который автоматически выполняет пользовательскую логику сразу после того, как транзакция взаимодействует с одной или несколькими он-чейн программами. Концептуально, Hooks служат встроенным слоем "backrunning": как только целевая программа обновляет свое состояние, один или несколько Hooks могут запускать проверки арбитража, действия по ликвидации, бухгалтерские операции или любой другой случай использования, требующий своевременного осведомления о состоянии.
Технически, Hook имеет ту же самую структуру, что и транзакция: пользователи Hooks предоставляют аккаунты и данные, а газ списывается с назначенного аккаунта каждый раз, когда Hook активируется. Hook может быть отключен после трех случаев отсутствия средств для оплаты газа в аккаунте плательщика комиссии. SOLAYER CHAIN предоставляет предкомпилированный код, который управляет регистрацией и аукционами Hooks. Пользователи подают заявки на присоединение своих Hooks к конкретным программам, соревнуясь в модели, похожей на голландский аукцион, где топ-16 заявок (на каждую программу) имеют право на выполнение в следующую эпоху. Если транзакция затрагивает несколько программ с зарегистрированными Hooks, будут выполнены только 16 общих Hooks (отсортированных по убыванию ставки). После завершения транзакции эти Hooks вызываются по очереди, и ставка для каждого Hook распределяется следующим образом: 40% инициатору транзакции, 40% владельцу программы и 20% сети.
Эта модель стимулирования снижает стоимость исчерпывающего повторного выполнения, одновременно поощряя участников экосистемы к интеграции Hooks. Распределение 40-40-20 гарантирует, что как конечные пользователи, так и владельцы программ получают выгоду от более высоких ставок, в то время как сеть собирает часть для компенсации дополнительных накладных расходов на блокчейне. Встраивая Hooks непосредственно в конвейер выполнения, SOLAYER CHAIN также снижает возможность спама или эксплуатации off-chain MEV, поскольку логика в реальном времени становится доступной любой стороне, готовой сделать ставку. В целом, Hooks предоставляет справедливый и ориентированный на производительность подход к автоматизации пост-транзакционных действий без перегрузки основной сети.
5.3 Кросс-чейн вызовы контрактов
SOLAYER CHAIN имеет двунаправленный нативный мост, реализованный внутри секвенсора, для передачи сообщений и активов из Solana в SOLAYER CHAIN. Мост игнорирует реорганизации Solana, реализуя страховой фонд, который автоматически покрывает потери из-за реорганизации. Если общая стоимость актива (измеренная через оракул), переданная до финализации, ниже размера страхового фонда, актив становится немедленно доступным в SOLAYER CHAIN. В противном случае актив становится доступным после финализации транзакции. Все сообщения могут быть переданы мгновенно (игнорируя реорганизации) или после финализации путем установки флага в транзакции. Приемный Hook автоматически вызывается, как только сообщение становится доступным, и может вызывать дополнительные программы.
SOLAYER CHAIN также вводит мост кросс-чейн вызовов программ через зеркалирование аккаунтов, где каждая программа и аккаунт SOLAYER CHAIN имеют соответствующий Program Derived Address (PDA) в основной сети Solana. Центральным элементом этого дизайна является инструкция типа MainnetCall, позволяющая атомарные кросс-чейн операции, организованные через встроенную системную программу. Каждый раз, когда программа SOLAYER CHAIN вызывает MainnetCall, транзакция направляет инструкции к связанному PDA в Solana. Таким образом, программы могут переводить средства, запускать кросс-чейн вызовы функций и даже выполнять сложную он-чейн логику, охватывающую обе сети, все это в рамках одной атомарной операции. Чтобы обеспечить атомарность, инструкция MainnetCall никогда не отменяется (даже если транзакция Solana отменяется) и может быть вставлена только в конце транзакции, но не между ними, чтобы при возникновении реорганизации Solana не было воздействия, так как транзакция Solana просто должна быть вновь распространена до финализации. Комбинируя оба моста, можно реализовать решения, включая, но не ограничиваясь, кросс-чейн свопами в одной транзакции и ребалансировкой кросс-чейн хранилищ доходности.
Для поддержки сложной логики транзакций, особенно для транзакций Hooks, SOLAYER CHAIN вводит джамбо-транзакции. Этот новый тип транзакций значительно увеличивает предел размера транзакции, позволяя выполнять больше кросс-программных вызовов. Комиссии за джамбо-транзакции растут экспоненциально с увеличением размера транзакции. Используя джамбо-транзакции, пользователи могут читать и писать тысячи аккаунтов, выполнять тысячи инструкций или развертывать несколько программ в рамках одной транзакции.
Пользователи могут использовать свои аккаунты Google, X, Reddit или любые сервисы, поддерживающие OAuth, в качестве кошельков. SOLAYER CHAIN имеет нативную поддержку транзакций, подписанных с использованием OAuth. Основной рабочий процесс похож на zkLogin от Sui.