Аппаратная защита не на всех узлах: как TEE меняет устойчивость BFT-консенсуса

Исследователи предложили математическую модель и протокол Raftel для BFT-консенсуса в сетях, где только часть узлов работает внутри аппаратных анклавов. Результат: выигрыш в производительности, но с жёстким порогом эффективности.

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

Зачем вообще нужны аппаратные анклавы в консенсусе

Классические алгоритмы византийской отказоустойчивости (BFT) требуют, чтобы не более одной трети узлов в сети были скомпрометированы. Это фундаментальное ограничение: при 3f + 1 репликах система выдерживает до f византийских узлов. Хоть один сверх — и гарантий нет.

Trusted Execution Environment (TEE) — аппаратные изолированные enclave вроде Intel SGX или ARM TrustZone — пытаются обойти эту границу. Идея простая: если код и данные узла защищены аппаратно, даже владелец машины не может их подменить. Значит, узел внутри TEE нельзя считать полноценным византийским участником — он не сможет послать противоречивые сообщения. Такие узлы становятся «доверенными», и порог отказоустойчивости сдвигается.

Проблема в том, что существующие исследования TEE-усиленного консенсуса обычно предполагают бинарную картину: либо все реплики работают в анклавах, либо ни одна. В реальном мире такого не бывает. Инфраструктура гетерогенна: у одних провайдеров есть SGX, у других — нет. Одни узлы обновлены, другие — нет. Новая работа, принятая на конференцию EuroSys 2027, впервые формально описывает именно эту промежуточную ситуацию.

Постановка задачи: частичное доверие

Авторы вводят так называемую universal partial-TEE model — модель, в которой произвольное подмножество реплик выполняется внутри TEE, а остальные работают без аппаратных гарантий. Это принципиально меняет картину формирования кворумов.

В классическом HotStuff для достижения консенсуса нужно собрать кворум из 2f + 1 голосов при 3f + 1 участниках. Если часть узлов аппаратно защищена, возникает вопрос: можно ли считать голос TEE-узла «более надёжным»? И если да, как это формализовать в протоколе, не ломая доказательства безопасности?

Ключевой результат: порог в две трети

Главная теорема работы — формула границы отказоустойчивости:

f < max { n/3, m/2 }

где n — общее число реплик, m — число реплик с TEE, а f — максимально допустимое число византийских узлов.

Эта формула демонстрирует пороговый эффект. Пока TEE-узлов меньше двух третей от общего числа, ограничение определяется классическим порогом n/3 — аппаратные анклавы не дают никакого выигрыша. Только когда m превышает 2n/3, граница сдвигается, и система начинает выдерживать больше отказов, чем предсказывает чистая BFT.

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

Архитектура протокола Raftel

На основе теоретической модели авторы построили протокол Raftel — первый протокол семейства HotStuff, явно спроектированный для частично-TEE среды. Он опирается на два конструктивных принципа.

Двойные кворумы. Протокол поддерживает два типа кворумов: «чистые TEE-кворумы» (состоящие только из аппаратно защищённых узлов) и «смешанные кворумы» (включающие и обычные реплики). Это позволяет гибко адаптироваться к реальной топологии сети: если TEE-узлов достаточно, консенсус идёт через них с повышенными гарантиями; если нет — откатывается на стандартный BFT-механизм.

Быстрый путь через TEE-лидера. Когда лидером раунда становится узел внутри SGX, аппаратная гарантия non-equivocation (невозможности отправить разные сообщения разным участникам) позволяет обойтись без части этапов голосования. Это ускоряет как основной путь консенсуса, так и смену лидера (view-change) — один из самых болезненных этапов в HotStuff.

Поверх Raftel авторы также построили chained-Raftel — пайплайнизированную версию, где этапы голосования для разных блоков накладываются друг на друга, что типично для современных BFT-протоколов и позволяет увеличить пропускную способность.

Реализация и результаты

Оба протокола реализованы поверх Intel SGX и протестированы в двух сетевых окружениях: локальной сети (LAN) и распределённой глобальной сети (WAN).

Заявленные цифры:

• Raftel в WAN: до 625 транзакций в секунду (TPS) при латентности менее 670 мс
• Выигрыш над HotStuff: до +308 TPS по пропускной способности
• При этом производительность приближается к уровням протоколов с полным TEE-покрытием

Цифры впечатляют на фоне классического HotStuff, но требуют контекста. 625 TPS в WAN — это, конечно, далеко от показателей централизованных платёжных систем (Visa обрабатывает десятки тысяч TPS), но для BFT-протоколов с реалистичными допущениями о сети вполне конкурентно. Для сравнения, оригинальный HotStuff на аналогичных стендах обычно показывает 200–400 TPS в зависимости от задержек.

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

Скептицизм и нюансы

Как всегда с академическими результатами, стоит помнить о нескольких вещах.

Во-первых, модель угроз. Авторы исходят из того, что TEE непроницаемы — внутри enclave атакующий не может выполнить произвольный код. Но история Intel SGX показала, что это не всегда так: атаки типа Spectre, Foreshadow, Plundervault и другие side-channel эксплойты неоднократно компрометировали изоляцию SGX. Каждое поколение процессоров закрывает одни дыры и открывает другие. Если TEE-узлы можно скомпрометировать через side-channel, вся модель частичного доверия разваливается, и протокол откатывается к стандартному порогу n/3.

Во-вторых, масштабируемость. Тестирование на типичных для академии конфигурациях (обычно 4–16 узлов) не гарантирует, что результаты сохранятся при сотнях или тысячах участников. Авторы не оговаривают верхний предел числа реплик, при котором протокол остаётся практически реализуемым.

В-третьих, разнородность оборудования. Intel SGX — не единственная TEE-платформа. ARM TrustZone, AMD SEV, RISC-V Keystone имеют другую архитектуру и другие ограничения. Протокол формально абстрагируется от конкретной реализации TEE, но на практике детали имеют значение: объём enclave-памяти SGX ограничен, вызовы в enclave дороги, и реальная производительность сильно зависит от паттернов доступа к памяти.

Что это значит для индустрии

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

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

Raftel и chained-Raftel — промежуточный шаг на пути к практическим протоколам, которые умеют работать в реальной гетерогенной инфраструктуре. Теоретическая база выглядит solid, экспериментальные результаты — обнадёживающие, но до промышленного внедрения ещё далеко. Потребуется аудит безопасности кодовой базы, тестирование на более крупных развёртываниях и, главное, ответ на вопрос о side-channel устойчивости SGX в реальных условиях.