На грани детерминизма: жизненный цикл транзакций в Solana Sealevel и объектной среде выполнения Sui

Что такое жизненный цикл блокчейн-транзакции?

Блокчейны обрабатывают транзакции. Транзакции влияют на состояние, то есть обновлённое представление аккаунтов в блокчейне. Жизненный цикл транзакции — одно из наиболее наглядных выражений архитектурной философии блокчейна. Он помогает техническим специалистам понять, как сеть оптимизирована с точки зрения пропускной способности и безопасности, гарантий детерминизма, относительных инженерных затрат и потенциальных проблем в реальных условиях.

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

Жизненный цикл транзакций Solana

Блокчейн Solana построен на уникальной архитектуре, которая использует Proof-of-Stake (PoS) как механизм консенсуса, а Proof-of-History (PoH) — как механизм отсчёта времени для эффективного упорядочивания транзакций.

Архитектурная модель Solana ориентирована на аккаунты. Иными словами, «всё в Solana — это аккаунт».

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

Транзакция Solana

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

Сообщение транзакции — это структура данных, содержащая заголовок, ключи аккаунтов, недавний хеш блока и инструкции. Заголовок содержит MessageHeader, который описывает организацию ключей аккаунтов Message.

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

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

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

Message содержит единый общий плоский список всех аккаунтов, необходимых всем инструкциям транзакции. Этот плоский список создаётся при формировании Message, а инструкции преобразуются в набор CompiledInstructions. Затем эти CompiledInstructions ссылаются по индексу на необходимые им аккаунты из единого общего списка.

Общий список аккаунтов упорядочен по требуемым разрешениям:

• Аккаунты с правом записи, являющиеся подписантами.
• Аккаунты только для чтения, являющиеся подписантами.
• Аккаунты с правом записи, не являющиеся подписантами.
• Аккаунты только для чтения, не являющиеся подписантами.

С учётом этого порядка поля MessageHeader описывают, какие разрешения требуются аккаунтам в транзакции.

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

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

Транзакции отправляются из клиента через Gulf Stream — протокол пересылки транзакций Solana и проходят через два многоэтапных конвейерных процесса валидатора: Transaction Processing Unit (TPU) и Transaction Validation Unit (TVU).

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

TPU работает, когда валидатор находится в режиме лидера, то есть создаёт блоки, а TVU — когда валидатор работает в режиме проверки блоков. В обоих случаях конвейерное оборудование схоже: сетевой ввод, запись на диски, сетевой вывод и так далее. Однако используется оно по-разному. Проще говоря, TPU создаёт записи реестра, а TVU проверяет их.

На высоком уровне транзакции отправляются через клиент и передаются посредством Gulf Stream по QUIC в TPU лидера. Транзакция проходит проверки, после чего банковский этап планирует её исполнение. Обновления состояния записываются обратно в состояние банка в памяти. Валидаторы голосуют за блоки через gossip, а блоки финализируются с помощью Tower BFT — варианта PBFT с механизмами блокировки, взвешенными по стейку.

Gulf Stream

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

Solana устраняет необходимость в глобальном мемпуле благодаря детерминированному расписанию лидеров. На него влияет взвешенный по стейку алгоритм Stake-Weighted Quality of Service (SWQoS), который приоритизирует сообщения транзакций, маршрутизируемые через валидаторы со стейком.

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

Ещё одно преимущество Gulf Stream связано с тем, что в традиционных сетях с мемпулом создатели блоков должны повторно передавать те же транзакции уже в составе блока. Поэтому каждая транзакция распространяется по сети как минимум дважды. Solana не нужно перегружать gossip для синхронизации ожидающих транзакций, а самим транзакциям не приходится конкурировать за место в блоке посредством аукционов газа. Вместо этого они распределяются по расписанию.

Transaction Processing Unit (TPU)

TPU — это основная логика валидатора, отвечающая за создание блоков. Транзакции извлекаются из клиента и передаются в пакетах данных через компонент QUIC streamer. Он выделяет память под пакеты и считывает данные из конечной точки QUIC — этот процесс называется Fetch Stage. Каждый поток передаёт пакет в рамках ограничений передачи QUIC, определяемых клиентом (IP-адресом и публичным ключом ноды) и сервером.

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

Банковский этап — ключевой компонент исполнения в среде выполнения Solana. Он планирует входящие пакеты, дополнительно фильтрует их на предмет конфликтов и определяет, следует ли обрабатывать, удерживать или пересылать их пакетами. Если нода является создателем блока, удерживаемые и недавно полученные пакеты обрабатываются компонентом Bank. Этот компонент представляет в памяти полное состояние реестра в заданном слоте.

В банковском этапе и компоненте планировщика транзакция отслеживается в двух состояниях:

• Необработанное состояние, в котором транзакция доступна для планирования
• Состояние ожидания, в котором транзакция планируется или обрабатывается

После завершения обработки транзакцию иногда можно повторить. В этом случае она возвращается в необработанное состояние, иначе её состояние удаляется. Обработанные действительные транзакции с помощью тиков PoH формируются в «Entry», объединяются в блоки и транслируются пирам сети в виде шредов через Turbine — протокол распространения блоков Solana. На Broadcast Stage он создаёт коды стирания для «восстановления» потерянных пакетов данных перед их передачей соответствующему пиру сети.

Transaction Validation Unit (TVU)

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

На этапах Shred Fetch Stage и проверки подписи лидера для шредов ноды, не являющиеся лидерами, получают шреды от других нод по UDP и пакетно проверяют подписи. Действительные шреды повторно передаются пирам на Retransmit Stage, а каждая транзакция последовательно воспроизводится на Replay Stage.

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

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

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

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

Среда выполнения Solana использует движок исполнения Sealevel, чтобы транзакции, обращающиеся к аккаунтам только для чтения, выполнялись параллельно. Транзакции, обращающиеся к пересекающимся аккаунтам с правом записи, сериализуются и выполняются последовательно.

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

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

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

При взаимодействии со средой выполнения конвейеры TPU и TVU используют несколько разные пути. Среда выполнения TPU гарантирует, что «записи» фиксируются с помощью тиков PoH до фиксации памяти. Среда выполнения TVU гарантирует, что «записи» проверяются до обработки любых транзакций.

Консенсус

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

Формально отказоустойчивый механизм консенсуса должен обладать следующими свойствами:

• Единое соглашение: никакие две ноды не принимают разные решения.
• Целостность: ни одна нода не принимает решение более одного раза.
• Допустимость: если нода принимает значение, оно должно быть предложено другой нодой.
• Завершение: каждая нода, которая не завершила работу аварийно, в итоге принимает некоторое значение.

На базовом уровне цель консенсуса — добиться согласия между нодами. В Solana существует несколько ситуаций, когда нодам необходимо согласие. Особенно важны три сценария:

Ротация лидеров

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

Расписание лидеров формируется из заранее определённого начального значения по следующему алгоритму: высота тика PoH, то есть монотонно возрастающий счётчик, периодически используется как начальное значение стабильного псевдослучайного алгоритма.

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

Синхронизация

Без надёжных временных меток валидатор не может определить порядок входящих блоков. Solana использует механизм Proof-of-History как криптографические часы для упорядочивания транзакций до достижения консенсуса. Согласно документации Anza о синхронизации:

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

Важно помнить, что Proof-of-History не является механизмом консенсуса, однако существенно влияет на производительность консенсуса Proof-of-Stake в Solana.

Атомарная фиксация

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

Чтобы избежать частичного исполнения, Solana обеспечивает атомарность в среде выполнения в смысле ACID, а также гарантирует согласие всех нод с результатом транзакции: либо изменения откатываются, если возникает ошибка, либо фиксируются, если всё проходит успешно.

Уровень подтверждения в Solana показывает финальность блока (слота) с учётом числа проголосовавших за него валидаторов и глубины их голосов в механизме блокировок Tower BFT. Он отражает, насколько уверенно сеть согласовала данный слот на основании голосов валидаторов. Каждый валидатор голосует за слоты, точнее за высоты блоков, и обязуется не голосовать за конфликтующие форки. Блокировки Tower BFT обеспечивают выполнение этого правила.

В Solana предусмотрено три статуса подтверждения: processed, confirmed и finalized. Блок считается подтверждённым, когда за него голосует квалифицированное большинство валидаторов со стейком (≥66%), и финализированным, когда поверх него создаётся как минимум 32 подтверждённых блока.

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

Alpenglow

На момент написания статьи Solana использует Tower BFT и реестр PoH, чтобы сеть могла достичь консенсуса даже при отказе некоторых участников.

Недавно исследовательская команда Anza предложила новую архитектуру более простого и производительного протокола консенсуса — Alpenglow. Alpenglow призван полностью переработать устаревшие компоненты текущей архитектуры консенсуса, включая Proof of History, Tower BFT и использование gossip для распространения голосов.

В основе Alpenglow лежат Votor и Rotor, которые ускоряют достижение консенсуса Solana:

Votor — двухуровневый механизм голосования, предназначенный для финализации блока за один раунд при доступности 80% стейка и за два раунда при доступности как минимум 60% стейка.

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

Sui

В отличие от Solana с её моделью, ориентированной на аккаунты, блокчейн Sui использует объектно-ориентированную модель данных. Данные состояния представлены в виде объектов с уникальными идентификаторами, свойствами и методами.

В Sui смарт-контракт также является объектом. Он называется пакетом Sui Move, имеет уникальный идентификатор и управляет объектами. Пакеты Sui Move состоят из набора модулей байткода Move. Каждый модуль имеет уникальное имя, а сочетание ончейн-ID пакета и имени модуля однозначно идентифицирует модуль.

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

Объекты могут использовать следующие модели владения:

• Объекты, принадлежащие адресу: такой объект принадлежит определённому 32-байтовому адресу — адресу аккаунта или ID объекта. Доступ к нему есть только у владельца.
• Неизменяемые объекты: неизменяемый объект нельзя изменить, передать или удалить. У него нет владельца, и он глобально доступен всем пользователям.
• Общие объекты: общий объект доступен всем пользователям.
• Обёрнутые объекты: объект помещается внутрь другого объекта. Обёрнутые объекты не существуют независимо, и получить к ним доступ можно только через объект-обёртку.

Транзакция Sui

В Sui транзакции состоят из группы команд, которые выполняются над входными данными и определяют результат транзакции. Эти группы команд называются программируемыми блоками транзакций (PTB) и определяют все пользовательские транзакции в Sui. PTB позволяют пользователю вызывать несколько функций Move, управлять своими объектами и «монетами» в одной транзакции без публикации нового пакета Move.

Структура PTB определяется следующим образом:

{
    inputs: [Input],
    commands: [Command],
}

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

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

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

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

После отправки Full node сертифицирует все предоставленные метаданные, передавая транзакцию ноде-валидатору — это этап сертификации. Нода-валидатор выполняет все необходимые проверки транзакции и подписывает её для подтверждения действительности, если проверки пройдены. Чтобы нода-валидатор признала транзакцию действительной, она должна:

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

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

Если блокировка прошла успешно, валидатор подписывает транзакцию и возвращает подпись Full node.

Full node Sui по сути предоставляет представление состояния сети только для чтения. В отличие от нод-валидаторов, Full node не может подписывать транзакции, хотя может проверять целостность цепочки, повторно исполняя транзакции, ранее зафиксированные кворумом валидаторов. Full node собирает не одну подпись валидатора, а максимально возможное число подписей параллельно. Однако для формирования сертификата транзакции достаточно квалифицированного большинства — ⅔+ стейка.

Исполнение и контрольные точки

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

Во время исполнения транзакции делятся на две категории: транзакции с объектами владельца и транзакции с общими объектами:

Транзакции с объектами владельца

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

Транзакции с общими объектами

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

Ранее мемпул Sui под названием Narwhal предотвращал обычные перегрузки, отделяя распространение транзакций от упорядочивания. Он хранил сертифицированные подписанные транзакции в направленном ациклическом графе (DAG), но сам их не упорядочивал. Консенсусный порядок затем обеспечивал Bullshark.

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

Развивая эти достижения, Mysticeti теперь заменяет и Narwhal, и Bullshark, объединяя распространение и упорядочивание транзакций в одном протоколе. Mysticeti выстраивает транзакции в общий порядок, дополнительно упрощая процесс и обеспечивая ещё меньшую задержку и более высокую пропускную способность. Кроме того, благодаря модели владения Sui, ориентированной на объекты, большинство транзакций остаются независимыми и не конкурируют за место в глобальном порядке.

После исполнения транзакций валидатор подписывает их эффекты и возвращает их Full node. Эффекты транзакции — это список всех выполненных ею действий: изменённых объектов, израсходованного газа, статуса исполнения и других данных.

Подписи эффектов образуют набор сертификатов эффектов, которые Full node собирает у квалифицированного большинства валидаторов. Это гарантирует финализацию транзакции.

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

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

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

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

Финализация

Транзакция в Sui финализируется, как только квалифицированное большинство (2𝑓 + 1) валидаторов принимает и совместно подписывает её сертификат, даже до упорядочивания сертификата консенсусом или исполнения. После этого конфликтующая транзакция уже не может появиться, а исходную транзакцию нельзя отозвать. Для транзакций только с объектами владельца результат исполнения известен сразу после финализации. Для транзакций с общими объектами результат определяется только после упорядочивания сертификата консенсусом. Финализация достигается за два сетевых цикла передачи данных.

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

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

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

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

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

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

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

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

Выводы об исполнении, масштабируемости и архитектурных компромиссах

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

Исполнение

Solana как сеть, ориентированная на аккаунты, динамически обнаруживает конфликты аккаунтов через их блокировку на Banking Stage. Транзакции, не изменяющие один и тот же аккаунт, обрабатываются параллельно, а конфликтующие транзакции — последовательно.

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

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

Пределы масштабируемости

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

Solana использует одного лидера, а распределение исполнения ограничивается конкуренцией за аккаунты. Поэтому из-за единой глобальной нешардированной модели состояния и ориентированного на лидера приёма транзакций в каждом слоте сеть, по-видимому, достигает определённого предела горизонтального масштабирования. Однако внутри этого предела Solana активно оптимизирует работу с помощью чётко определённой конвейерной обработки, дополненной PoH. Транзакции можно точно упорядочить, обработать менее чем за 400 мс и оптимистически подтвердить менее чем за секунду. В плане вертикального масштабирования Solana существенно масштабируется вместе с оборудованием валидаторов, особенно числом ядер CPU и объёмом RAM, что полностью соответствует её базовой архитектуре.

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

Архитектурные компромиссы

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

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

Итоги

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

Solana построена на модели, ориентированной на аккаунты, а транзакции проходят ряд многопоточных процессов и конвейеров для проверки действительности. Транзакции отправляются лидеру, который запускает конвейер TPU для их проверки и соответствующего планирования: параллельно при отсутствии конфликтов и последовательно при их наличии. Когда валидатор не создаёт блоки, он запускает конвейер TVU для репликации и проверки транзакций. И TPU, и TVU используют общую среду выполнения. В результате Solana обрабатывает тысячи транзакций за очень короткое время, поскольку среда выполнения может заранее и детерминированно выявлять непересекающиеся аккаунты и параллельно исполнять неконфликтующие транзакции. Благодаря этому Solana отлично подходит для реальных сценариев, таких как высокочастотная торговля, глубоко компонуемые приложения DeFi, требовательные к инфраструктуре dApp и потребительские dApp с низкой задержкой.

Sui, в свою очередь, использует модель, ориентированную на объекты, где каждый объект отслеживается по уникальному идентификатору. На основе владения объектами сеть может статически определить возможность параллельного исполнения транзакции, если та затрагивает непересекающиеся наборы объектов. Благодаря модели с двумя путями исполнения, то есть разделению транзакций на транзакции с объектами владельца и транзакции с общими объектами, а также использованию подписанных контрольных точек для синхронизации Full node, сеть может обрабатывать лёгкие транзакции без нагрузки на уровень консенсуса. При этом она обеспечивает надёжную быструю финализацию и эффективную синхронизацию новых нод. Это позволяет горизонтально масштабироваться с ростом нагрузки и особенно полезно для приложений с массовыми взаимодействиями объектов: DeFi, игр, бирж, ориентированных на активы, и программируемых активов.

Источники

• Официальная документация Solana
• Официальная документация Anza
• Официальная документация Sui
• Gulf Stream: протокол пересылки транзакций Solana без мемпула
• Sealevel — параллельная обработка тысяч смарт-контрактов
• Cross-Program Invocation и PDA — сочетание двух мощных механизмов в Anchor
• Narwhal и Tusk: мемпул на основе DAG и эффективный консенсус BFT
• Горизонтальное масштабирование исполнения Sui с Pilotfish
• SUI и Solana: сравнение — TrustWallet
• Tower BFT: высокопроизводительная реализация PBFT в Solana
• David J DeWitt и Jim N Gray: «Параллельные системы баз данных: будущее высокопроизводительных систем баз данных», Communications of the ACM, том 35, номер 6, страницы 85–98, июнь 1992 г. doi:10.1145/129888.129894
• Jim N Gray и Leslie Lamport: «Консенсус при фиксации транзакций», ACM Transactions on Database Systems (TODS), том 31, номер 1, страницы 133–160, март 2006 г. doi:10.1145/1132863.1132867
• Leslie Lamport: «Время, часы и упорядочивание событий в распределённой системе», Communications of the ACM, том 21, номер 7, страницы 558–565, июль 1978 г.
• Michael J Fischer, Nancy Lynch и Michael S Paterson: «Невозможность распределённого консенсуса при одном сбойном процессе», Journal of the ACM, том 32, номер 2, страницы 374–382, апрель 1985 г. doi:10.1145/3149.214121
• Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, Mingwei Tian: «MYSTICETI: достижение пределов задержки с несертифицированными DAG», [cs.DC], июль 2024 г.
• Giorgos Tsimos, Anastasios Kichidis, Alberto Sonnino, Lefteris Kokoris-Kogias: «HammerHead: репутация лидеров для динамического планирования», [cs.CR], сентябрь 2023 г.