Что я выяснил, изучая консенсус Rayls, архитектуру расчётов и квитанции о транзакциях.
Я начал с простого вопроса:
Если блокчейн обещает окончательность менее чем за секунду, означает ли это, что вся транзакция завершается менее чем за секунду?
На первый взгляд ответ кажется очевидным. Транзакция подтверждается, сеть достигает консенсуса, и операция завершена.
Но финансовая инфраструктура устроена сложнее.
Транзакция может быть зафиксирована в одном реестре, в то время как более крупная операция всё ещё зависит от другого реестра, ретранслятора, проверки доказательства или выполнения на стороне целевой сети.
Изучая Rayls, я понял, что для понимания заявлений об окончательности нужно смотреть не только на громкие цифры скорости.
Главное — знать, какая среда Rayls обрабатывает транзакцию, какое событие считается окончательным и относится ли заявление ко всему процессу или только к одному его этапу.
1. Окончательность и завершение транзакции — не одно и то же
Представьте перевод между двумя финансовыми учреждениями.
Отправляющее учреждение регистрирует распоряжение. Транзакция обрабатывается. Затем принимающему учреждению может потребоваться проверить и завершить свою часть операции.
Слово «мгновенно» может скрывать тот факт, что процесс состоит из нескольких этапов.
В блокчейн-системах есть похожее различие.
- Окончательность консенсуса: сеть согласовала место транзакции в зафиксированной истории.
- Исполнение: транзакция успешно применяет изменения к состоянию блокчейна.
- Сквозное завершение: предполагаемая операция завершена во всех задействованных системах.
Эти понятия связаны, но не взаимозаменяемы.
Транзакция может стать окончательной в исходном реестре, хотя весь межсетевой процесс ещё не завершён.
Это не делает заявление об окончательности бессмысленным. Это означает, что нужно точно понимать, что именно измеряется.
2. В Rayls предусмотрены разные пути обработки транзакций
Rayls — это не просто один блокчейн с одним механизмом расчётов. Архитектура включает несколько сред, предназначенных для разных задач.
Rayls Sovereign предоставляет частные реестры для отдельных учреждений.
Rayls Private Network соединяет реестры Sovereign через общий Private Network Hub.
Rayls Public Chain предоставляет публичную среду, совместимую с EVM.
Согласно «официальной документации по архитектуре» Rayls (https://docs.rayls.com/docs/rayls-high-level-architecture), источник истины зависит от пути транзакции.
Путь транзакции — источник истины
Внутри одного реестра Sovereign — реестр учреждения
Между реестрами Sovereign внутри Private Network — Private Network Hub
Между реестрами Sovereign через Public Chain — Public Chain
Это важное различие.
Транзакция, обработанная целиком в реестре одного учреждения, — это не то же самое, что транзакция, переводящая средства между учреждениями. Транзакция с участием Public Chain проходит по другому пути расчётов.
Поэтому вместо одного лишь вопроса «Насколько быстр Rayls?» полезнее спросить:
В какой среде рассчитывается эта транзакция и что именно стало окончательным?
3. Как Axyl обеспечивает окончательность?
Rayls использует Axyl как механизм консенсуса для своей Public Chain. В документации также указано, что в июле 2026 года Rayls Sovereign перешёл на Axyl, заменив Clique — механизм доказательства полномочий.
Однако пока Private Network Hub использует механизм доказательства полномочий Hyperledger Besu.
Это означает, что Axyl не следует называть механизмом консенсуса для всех сред Rayls.
Её конструкцию стоит изучить, поскольку она разделяет несколько обязанностей.
Narwhal: обеспечение доступности данных
Axyl использует Narwhal для организации пакетов транзакций в ориентированный ациклический граф, или DAG.
Вместо того чтобы считать, что данные о транзакциях всегда должны последовательно создавать отдельные участники, эта конструкция поддерживает параллельное распространение данных.
Цель — сделать соответствующие данные о транзакциях доступными валидаторам.
Bullshark: согласование порядка
Недостаточно просто обеспечить доступность данных. Сеть также должна согласовать порядок фиксации транзакций.
Bullshark обрабатывает DAG и устанавливает единый порядок в соответствии с правилами консенсуса протокола.
В основе конструкции лежат допущения о византийской отказоустойчивости консенсуса: они помогают честным валидаторам согласовать единую историю, даже если некоторые участники действуют некорректно или становятся недоступны в пределах предусмотренных протоколом допусков к сбоям.
Reth: исполнение транзакций
После установления порядка транзакций за исполнение EVM отвечает Reth.
Здесь возникает ещё одно важное различие.
Транзакцию можно отправить в сеть, но она всё равно может не исполниться успешно. Консенсус и исполнение выполняют разные задачи: первый устанавливает согласованный порядок, а второе применяет допустимые транзакции к состоянию EVM.
Это различие становится особенно важным, когда разработчики проверяют квитанции транзакций.
Источники: «Обзор Rayls Axyl» (https://docs.rayls.com/docs/meet-axyl-the-consensus-behind-rayls) и «Техническая документация Axyl» (https://docs.rayls.com/docs/about-the-axyl-consensus-algorithm).
4. Деталь, которая привлекла моё внимание: транзакции без квитанций
Читая документацию Axyl, я обнаружил важную оговорку для разработчиков, заслуживающую внимания.
В документации объясняется, что недействительные транзакции могут пропускаться без создания квитанции.
Например, транзакции с неверной подписью, недостаточным балансом, несоответствующим nonce или дубликаты.
Также отмечается, что Public Chain не предоставляет публичный мемпул.
Почему это важно?
Разработчики часто предполагают, что отправленная транзакция остаётся в ожидании, пока её не подтвердят или не отменят. Но если недействительная транзакция пропускается без квитанции, приложение не может безопасно считать, что она просто ждёт включения в блок.
Для кошелька или платёжного приложения это создаёт важную проблему с точки зрения пользовательского опыта.
Что должен отображать интерфейс, если пользователь отправил транзакцию, но квитанция не появилась?
Следует ли продолжать показывать статус «ожидание»? Нужно ли повторять попытку? Как не перепутать неудачную отправку с транзакцией, которая уже завершилась?
В документации рекомендуется отслеживать отправленные транзакции, сохранять их хеши, опрашивать сеть на предмет квитанций и считать отсутствие квитанции после разумного тайм-аута возможным признаком того, что транзакция была отброшена.
Это полезный урок:
Окончательность — свойство консенсуса, но обработка статуса транзакции также относится к ответственности разработчиков приложения.
Быстрый механизм консенсуса не избавляет от необходимости надёжно обрабатывать ошибки.
5. Что происходит, когда транзакция перемещается между учреждениями?
Private Network Hub в Rayls добавляет к обсуждению ещё один уровень.
Согласно «официальной документации Hub» (https://docs.rayls.com/docs/private-network-hub), Hub помогает координировать транзакции между реестрами Sovereign и проверяет связанные с ними криптографические доказательства.
В документации описаны два соответствующих механизма:
- Коммиты состояния по времени, при которых информация о заголовках блоков периодически публикуется из реестра Sovereign в Hub.
- Доказательства транзакций, которые отправляются участвующими реестрами Sovereign и проверяются по соответствующим данным о состоянии.
Hub также поддерживает пакетную обработку, позволяя объединять тысячи транзакций в одну транзакцию Hub.
По заявлению Rayls, Private Network может обрабатывать более 15 000 транзакций в секунду с окончательностью менее чем за секунду — в зависимости от конфигурации и типа транзакции.
Это уточнение важно.
Показатель пропускной способности сам по себе не говорит, насколько быстро завершается каждый отдельный платёж. И окончательность транзакции, зафиксированной в одной среде, не доказывает, что завершились все последующие этапы в другой среде.
Для серьёзной оценки я бы разделил три показателя:
1. Задержка консенсуса: сколько времени занимает фиксация транзакции?
2. Задержка исполнения: сколько времени требуется, чтобы успешно применить транзакцию?
3. Сквозная задержка: сколько времени занимает вся операция во всех задействованных системах?
Эти показатели отвечают на разные вопросы.
6. Доказывает ли окончательность менее чем за секунду, что каждая транзакция завершается меньше чем за секунду?
Само по себе — нет.
В официальной документации Rayls говорится, что Axyl обеспечивает детерминированную окончательность менее чем за секунду; также заявлена производительность свыше 15 000 транзакций в секунду.
Эти заявления — полезная отправная точка. Но изучение конструкции и независимая проверка производительности в рабочей среде — это две разные задачи.
Для этой статьи я изучил опубликованную документацию Rayls по архитектуре, консенсусу и Private Network Hub. Я не проводил тестирование производительности в рабочей среде и не проверял показатели пропускной способности независимо.
Для воспроизводимого тестирования необходимо указать среду, типы транзакций, нагрузку, продолжительность теста и точку, в которой измеряется задержка.
Я бы также хотел знать:
- Измеряется время от отправки до фиксации консенсусом или от отправки до успешного исполнения?
- Измеряется локальная транзакция или операция между реестрами?
- Это наилучший результат, среднее значение или измерение хвостовой задержки?
- Что происходит, если валидаторы становятся недоступны или транзакции оказываются недействительными?
- В межсетевых процессах заканчивается ли измерение на окончательности в исходной сети или продолжается до завершения на стороне получателя?
Без этих подробностей одна громкая цифра не ответит на все вопросы эксплуатации.
Это не означает, что заявления Rayls неверны. Это означает, что не следует трактовать конкретную гарантию окончательности как универсальное обещание для всех путей обработки транзакций.
7. Что разработчикам следует проверить, прежде чем полагаться на заявление об окончательности?
Если бы я оценивал блокчейн-инфраструктуру для финансовых приложений, я бы начал с пяти вопросов.
1. Какая среда является авторитетной?
Определите, где рассчитывается операция: в Sovereign, Private Network Hub или Public Chain.
2. Что в этом контексте означает «окончательная»?
Нужно ли приложению зафиксировать транзакцию, успешно исполнить её или завершить операцию в нескольких системах?
3. Что происходит, если квитанция не приходит?
Прежде чем проектировать интерфейс, выясните, как обрабатываются недействительные, пропущенные или отброшенные транзакции.
4. Как приложение обрабатывает неопределённость?
Отслеживайте хеши транзакций, задавайте разумные тайм-ауты и не повторяйте операции вслепую, если они уже могли завершиться успешно.
5. Можно ли независимо воспроизвести заявление о производительности?
Ищите чётко определённую среду, нагрузку, методику измерений и статистику задержек.
Эти вопросы актуальны не только для Rayls. Они полезны при оценке любого блокчейна, обещающего быстрые расчёты.
Заключительные мысли
Я начал это исследование, рассчитывая найти простой ответ на вопрос о скорости транзакций.
Вместо этого важнее оказалось то, что окончательность зависит от пути транзакции и среды, в которой происходят расчёты.
В документации Rayls описан Axyl для Public Chain и Sovereign, тогда как Private Network Hub сейчас использует механизм доказательства полномочий Besu. У Hub есть собственная модель валидации и пакетной обработки, а в документации Axyl отмечена практическая проблема: недействительные транзакции не создают квитанций.
Важно различать окончательность транзакции в конкретном реестре и завершение всей предполагаемой операции во всех задействованных системах.
Для финансовой инфраструктуры скорость важна. Но одной скорости недостаточно, чтобы определить качество расчётов.
Я бы продолжал задавать простые вопросы:
Где были рассчитаны транзакции? Что именно стало окончательным? И какие доказательства подтверждают, что предполагаемая операция завершена?
Эти вопросы дают гораздо больше информации, чем одна лишь цифра скорости.
Официальные источники
- «Архитектура Rayls: обзор высокого уровня» (https://docs.rayls.com/docs/rayls-high-level-architecture)
- «Знакомство с Axyl: консенсус в основе Rayls» (https://docs.rayls.com/docs/meet-axyl-the-consensus-behind-rayls)
- «Технические спецификации Axyl» (https://docs.rayls.com/docs/about-the-axyl-consensus-algorithm)
- «Rayls Private Network Hub» ( https://docs.rayls.com/docs/private-network-hub )
- «Краткое введение в Rayls Sovereign» (https://docs.rayls.com/docs/a-warm-introduction-rayls-sovereign)
- «Краткое введение в Rayls Public Chain» (https://docs.rayls.com/docs/a-warm-intro-do-rayls-public-chain)
Примечание к исследованию: в этой статье анализируется опубликованная техническая документация Rayls. Это не независимое тестирование производительности в рабочей среде.