Что такое Firedancer? Подробный обзор Solana 2.0

О чём эта статья?

Solana — самый быстрый блокчейн. Но он может стать ещё быстрее. Текущий клиент валидатора Solana Labs хорош, но оптимизирован для быстрого выхода на рынок. Используя накопленный опыт, возможность начать с чистого листа и десятилетия работы с высокопроизводительными вычислениями, Jump стремится сделать Solana ещё быстрее и надёжнее. Опираясь на свой опыт в высокочастотной торговле, Jump разрабатывает Firedancer. Это самый производительный клиент валидатора среди всех блокчейнов. Проект предусматривает полную переработку текущего клиента валидатора Solana на языке программирования C.

В этой статье мы рассмотрим валидаторы и важность разнообразия клиентов валидатора. Затем объясним, почему Jump создаёт новый клиент валидатора и почему опыт компании в высокочастотной торговле делает её идеальной командой для разработки Firedancer. После этого разберём, что такое Firedancer, как он работает, почему он быстр, как обеспечивается его безопасность и на каком этапе находится его разработка.

К концу статьи вы получите полное представление о новом клиенте валидатора Jump. Вы познакомитесь с революционными оптимизациями, благодаря которым он стал самым производительным клиентом валидатора среди всех блокчейнов. Вы также поймёте, почему Firedancer критически важен для производительности и надёжности сети Solana. Это единственная статья о Firedancer, которая вам понадобится.

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

Что такое валидаторы и разнообразие клиентов валидатора?

Валидатор — это компьютер, участвующий в работе блокчейна на основе Proof of Stake. Валидаторы составляют основу сети Solana. Они обрабатывают транзакции и участвуют в консенсусе. Валидатор помогает защищать сеть, блокируя определённое количество нативных токенов Solana в качестве стейка. Это можно сравнить с залогом, который создаёт для валидатора финансовые риски перед сетью. Такие риски мотивируют валидаторов выполнять свои задачи точно и эффективно, поскольку за свой вклад они получают вознаграждение. За вредоносные действия и ошибки валидаторы также несут наказание. При ненадлежащем поведении стейк валидатора сокращается в ходе процесса, известного как слэшинг. Поэтому валидатору выгодно правильно выполнять свои обязанности, чтобы увеличивать стейк.

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

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

Разнообразие клиентов оценивается по доле стейка, проходящей через каждый клиент, и общему количеству доступных клиентов. На момент написания статьи в сети Solana насчитывалось 1979 валидаторов. В основной сети эти валидаторы используют два клиента, предоставленные Solana Labs и Jito Labs. Solana запустилась в марте 2020 года с одним клиентом валидатора, разработанным Solana Labs. В августе 2022 года Jito Labs выпустила второй клиент валидатора. Этот клиент представляет собой форк кода Solana Labs, который поддерживает и развёртывает Jito. Клиент оптимизирует извлечение MEV (максимальной извлекаемой ценности) внутри блоков. Клиент Jito создаёт псевдомемпул, поскольку Solana передаёт блоки потоково без мемпула. Для справки: мемпул, или пул памяти, — это очередь ожидающих и неподтверждённых транзакций. Псевдомемпул позволяет валидаторам просматривать эти транзакции, оптимально объединять их в пакеты и отправлять в Block Engine от Jito.

По состоянию на октябрь 2023 года клиент Solana Labs контролировал 68,55% активного стейка, а Jito — 31,45%. Количество валидаторов, использующих клиент Jito, выросло на 16% по сравнению с предыдущим отчётом о состоянии от Solana Foundation. Растущее использование клиента Jito указывает на положительную тенденцию к разнообразию клиентов.

Хотя эти новости о росте радуют, ситуация далека от идеальной. Важно подчеркнуть, что клиент Jito — это форк клиента Solana Labs. Это означает, что Jito использует многие компоненты исходной кодовой базы валидатора и потенциально уязвим для ошибок и эксплойтов, которые могут затронуть клиент Labs. В идеальном будущем у Solana будет как минимум четыре независимых клиента валидатора. Разные команды будут создавать эти клиенты на разных языках программирования. Ни одна реализация не будет контролировать более 33% стейка: на каждый клиент будет приходиться примерно ~25%. В такой идеальной конфигурации не будет единой точки отказа во всём стеке валидатора.

Разработка второго независимого клиента валидатора жизненно важна для реализации этого будущего, и Jump намерена воплотить его в жизнь.

Почему Jump создаёт новый клиент валидатора?

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

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

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

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

Возможно, этот сценарий кажется знакомым. Требования к успешной торговой системе похожи на требования к успешному блокчейну. Блокчейны должны быть производительными и отказоустойчивыми сетями с низкой задержкой. Медленный блокчейн — это неудачная технология, неспособная удовлетворить требования современных корпоративных приложений. Он лишь мешает инновациям, масштабированию и практическому применению. Благодаря более чем двадцатилетнему опыту масштабирования глобальных сетей и разработки высокопроизводительных систем Jump идеально подходит для создания независимого клиента валидатора. Этим процессом руководит Kevin Bowers, директор по науке Jump Trading.

Почему скорость света слишком мала?

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

Рассмотрим в качестве примера процессор Intel Core i9 13900K. Он оснащён 24 ядрами x86 с базовой тактовой частотой 2,2 ГГц и максимальной частотой в турборежиме 5,8 ГГц. В худшем случае свету пришлось бы пройти по этому процессору суммарное расстояние ~52,0 мм. Манхэттенское расстояние процессора, то есть расстояние между двумя точками, измеренное вдоль осей под прямым углом, составляет ~73,6 мм. При максимальной тактовой частоте процессора 5,8 ГГц свет за один такт проходит в воздухе ~51,7 мм. Это означает, что за один такт сигнал почти успевает пройти туда и обратно между любыми двумя точками процессора.

В действительности ситуация намного хуже. В этих расчётах используется скорость света в воздухе, тогда как сигналы проходят через диоксид кремния (SiO2). За один такт при частоте 5,8 ГГц свет может пройти в диоксиде кремния ~26,2 мм. В кремнии (Si) за такой же такт свет проходит лишь ~15,0 мм — немногим больше половины длинной стороны процессора.

Команда Firedancer утверждает, что последние технологические достижения в вычислительной технике были связаны с увеличением количества ядер в процессорах, а не с повышением их скорости. Когда требовалась более высокая производительность, пользователям предлагали покупать дополнительное оборудование. Пока узким местом остаётся пропускная способность, этот подход работает. Но настоящее узкое место — скорость света. Это естественное ограничение приводит к параличу принятия решений. Отдельная оптимизация не даёт немедленного результата, поскольку система состоит из множества компонентов и ни один из них не оптимизирован должным образом. Неоптимизированные компоненты со временем будут работать всё хуже, поскольку им будет доступно меньше вычислительных ресурсов. Что же делать?

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

Что такое Firedancer?

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

Цели Firedancer:

• Документировать и стандартизировать протокол Solana (в конечном итоге любой человек должен иметь возможность создать валидатор Solana, опираясь только на документацию, а не на код валидатора на Rust)
• Повысить разнообразие клиентов валидатора
• Улучшить производительность экосистемы

Как работает Firedancer?

Модульная архитектура

Firedancer отличается от текущих клиентов валидатора Solana своей уникальной модульной архитектурой. В отличие от клиента валидатора Solana Labs на Rust, который работает как единый процесс, Firedancer состоит из множества отдельных процессов Linux на C, называемых тайлами. Тайл — это процесс и выделенная ему память. Такая тайловая архитектура лежит в основе принципов работы Firedancer и его подхода к надёжности и эффективности.

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

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

Ключевое преимущество архитектуры Firedancer — возможность за считаные секунды заменять и обновлять каждый тайл без простоя. Это резко контрастирует с клиентом Solana Labs на Rust, который перед обновлением необходимо полностью остановить. Разница обусловлена отсутствием у Rust стабильного ABI (двоичного интерфейса приложений). Это препятствует обновлениям на лету в среде, полностью построенной на Rust. Использование процессов на C и двоичная стабильность модели среды выполнения C значительно сокращают простои, связанные с обновлениями. Это возможно, поскольку тайлы управляют состоянием валидатора в разных рабочих областях. Эти объекты общей памяти сохраняются, пока валидатор включён. После перезапуска или обновления каждый тайл может без проблем продолжить обработку с того места, где остановился.

В целом Firedancer построен на тайловой архитектуре, учитывающей NUMA. Что это означает, мы рассмотрим в следующем разделе. Пока достаточно знать, что такая архитектура выделяет отдельные аппаратные ресурсы каждому потоку. На каждый тайл приходится одно ядро CPU. Архитектура обеспечивает высокопроизводительный обмен сообщениями между тайлами, оптимизированный с учётом локальности памяти, распределения ресурсов и задержек компонентов.

Сетевая обработка

Сетевая обработка Firedancer рассчитана на интенсивные нагрузки сети Solana по мере её масштабирования до скоростей в несколько гигабит в секунду. Этот процесс разделён на входящие и исходящие операции.

Входящие операции в основном связаны с получением транзакций от пользователей. Производительность Firedancer критически важна: если валидатор отстаёт в обработке пакетов, сообщения консенсуса могут потеряться. Текущая рабочая пропускная способность ноды Solana составляет ~0,2 Гбит/с, а самый большой зафиксированный всплеск на ноде Jump достигал ~40 ГБ/с. Такой всплеск показывает необходимость надёжного и масштабируемого решения для обработки входящего трафика.

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

Firedancer призван устранить прежние недостатки однорангового интерфейса Solana для обработки транзакций. Одним из его главных недостатков было отсутствие контроля перегрузки для входящих транзакций. Это привело к серьёзным сбоям сети 14 сентября 2021 года (17 часов) и 30 апреля 2022 года (7 часов).

В ответ Solana провела несколько обновлений сети, чтобы корректно обрабатывать высокую транзакционную нагрузку. Firedancer следует этому подходу и использует QUIC для управления потоками. QUIC — это мультиплексированный транспортный сетевой протокол, лежащий в основе HTTP/3. Он играет важную роль в защите от DDoS-атак и управлении сетевым трафиком. Однако важно учитывать, что в некоторых случаях затраты перевешивают преимущества. QUIC в сочетании со специализированным оборудованием дата-центров для защиты от DDoS-атак устраняет стимул для переполнения сети транзакциями.

Спецификация QUIC объёмом 151 страница значительно усложнила разработку. Команда Firedancer не смогла найти существующую библиотеку на C, которая отвечала бы её требованиям к лицензированию, производительности и надёжности, поэтому создала собственную реализацию. Реализация QUIC от Firedancer под названием fd_quic использует оптимизированные структуры данных и алгоритмы, чтобы свести к минимуму выделение памяти и предотвратить её исчерпание.

Собственный сетевой стек Firedancer лежит в основе его возможностей обработки. Стек разработан с нуля для использования масштабирования на стороне приёма (RSS). RSS — это форма сетевой балансировки нагрузки с аппаратным ускорением, которая распределяет сетевой трафик между разными ядрами CPU для повышения параллелизма сетевой обработки. Каждое ядро CPU обрабатывает часть входящего трафика с минимальными накладными расходами. Такой подход превосходит традиционную программную балансировку нагрузки, поскольку устраняет необходимость в сложных планировщиках, блокировках и атомарных операциях.

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

Эта система тайлов позволяет использовать в стеке Firedancer различные концепции высокопроизводительных вычислений, включая:

• Учёт NUMA — NUMA (неоднородный доступ к памяти) представляет собой архитектуру компьютерной памяти, в которой процессор получает доступ к собственной памяти быстрее, чем к памяти, связанной с другим процессором. Учёт NUMA позволяет клиенту Firedancer эффективно управлять памятью в многопроцессорных конфигурациях. Это важно для обработки большого объёма транзакций, поскольку оптимизирует использование доступных аппаратных ресурсов.
• Локальность кэша — локальность кэша означает использование данных, уже находящихся в кэше рядом с процессором. Обычно это сложная форма временной локальности, то есть использования недавно запрошенных данных. Упор на локальность кэша в Firedancer позволяет обрабатывать сетевые данные с минимальной задержкой и максимальной скоростью.
• Параллелизм без блокировок — параллелизм без блокировок подразумевает разработку алгоритмов, которым не нужны механизмы блокировки, такие как мьютексы, для управления одновременными операциями. В Firedancer он позволяет параллельно выполнять несколько сетевых операций без задержек из-за блокировок. Параллелизм без блокировок повышает способность Firedancer одновременно обрабатывать большое количество транзакций.
• Большой размер страниц — использование больших страниц при управлении памятью упрощает работу с наборами данных, сокращая количество обращений к таблицам страниц и потенциальную фрагментацию памяти. Для Firedancer это означает более эффективное управление памятью, что полезно при обработке больших объёмов сетевых данных.

Система сборки

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

Почему Firedancer работает так быстро?

Продвинутый параллелизм данных

Для криптографических задач, таких как проверка подписей ED25519, Firedancer использует продвинутый параллелизм данных, доступный в современных процессорах. Современные CPU поддерживают инструкции Single Instruction, Multiple Data (SIMD), которые обрабатывают несколько элементов данных одновременно, а также оптимизации для выполнения нескольких инструкций за один такт CPU. Обычно выполнение одной инструкции над массивом или вектором элементов данных параллельно эффективнее с точки зрения площади кристалла, времени и энергопотребления. Поэтому улучшения в параллельной обработке данных могут сильнее влиять на пропускную способность, чем простое повышение скорости вычислений.

Firedancer применяет параллелизм данных, в частности, для оптимизации проверки подписей. Такой подход позволяет одновременно обрабатывать массивы или векторы элементов данных, повышая пропускную способность и сокращая задержку. В основе этой реализации ED25519 лежит арифметика полей Галуа. Она хорошо подходит для криптографических алгоритмов и двоичных вычислений. В полях Галуа такие операции, как сложение, вычитание, умножение и деление, определены в соответствии с двоичной природой компьютерных систем. Ниже приведен пример поля Галуа, определенного числом 23:

Проблема лишь в том, что ED25519 использует поле Галуа, определенное числом 2255-19. Элементы поля можно представить как числа от 0 до 2255-19. Базовые операции выглядят так:

• x + y → обычное сложение по модулю 2255-19
• x - y → обычное вычитание по модулю 2255-19
• x * y → обычное умножение по модулю 2255-19
• 1/x → x в степени 2255-21 по модулю 2255-19

Сложение, вычитание и умножение почти соответствуют арифметике uint256_t — арифметике беззнаковых целых чисел, где максимальное значение равно 2256-1. Деление вычислять сложно. Обычные CPU и GPU не поддерживают арифметику uint256_t, не говоря уже о «почти арифметике uint256_t» и тем более об исключительно сложном нестандартном делении. Реализация такой арифметики с высокой производительностью зависит от того, насколько эффективно ее удастся эмулировать.

Реализация Firedancer разбивает арифметические операции, используя более гибкое представление чисел. Если применить принципы обычного деления и умножения столбиком с переносом чисел из одного разряда в другой, эти разряды можно обрабатывать параллельно. Самый быстрый способ эмулировать такую арифметику — представить uint256_t в виде шести 43-битных цифр с 9-битным «переносом». Это позволяет использовать существующие 64-битные операции CPU и оставляет достаточно места для битов переноса. Такое представление чисел сокращает потребность в частом распространении переноса и позволяет Firedancer эффективнее обрабатывать большие числа.

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

Ускоренная с помощью AVX512 реализация Firedancer работает быстро. На одном ядре сервера Icelake с частотой 2,3 ГГц ее производительность на такт ядра более чем вдвое превышает результат демонстрации на Breakpoint 2022. Реализация обеспечивает 100%-ную загрузку векторных линий и масштабный параллелизм данных. Это еще одна блестящая демонстрация команды Firedancer: из-за задержек, ограниченных скоростью света, выполнять независимые задачи параллельно гораздо проще, чем делать их по одной, даже при использовании специализированного оборудования.

Использование FPGA для высокоскоростной передачи данных по сети

CPU могут выполнять около ~30 000 проверок подписей в секунду на ядро. Они энергоэффективны, но не справляются с крупномасштабными операциями. Это ограничение связано с последовательной обработкой. GPU увеличивают производительность примерно до ~1 миллиона проверок в секунду на ядро. Однако они потребляют около ~300 Вт на устройство и имеют присущую пакетной обработке задержку.

FPGA оказываются лучшей альтернативой. Они обеспечивают пропускную способность на уровне GPU, но потребляют значительно меньше энергии — около 50 Вт на FPGA. Их задержка также ниже десятимиллисекундной задержки GPU. При задержке около ~200 микросекунд FPGA обеспечивают гораздо более быстрый отклик при обработке в реальном времени. В отличие от пакетной обработки на GPU, FPGA в Firedancer обрабатывают каждую транзакцию отдельно в потоковом режиме. Использование FPGA в Firedancer обеспечивает впечатляющую производительность: 8 миллионов подписей в секунду при энергопотреблении менее 400 Вт для 8 FPGA.

Команда продемонстрировала процесс проверки подписей ED25519 в Firedancer на Breakpoint 2022. Он включал несколько этапов, в том числе вычисление SHA-512 в чистом конвейере RTL, а также различные проверки и вычисления в специализированном процессорном конвейере ECC-CPU. По сути, команда Firedancer написала компилятор и ассемблер для собственного процессора, взяла код Python из RFC (Request for Comments), запустила его с объектами с перегруженными операторами для генерации машинного кода, а затем разместила машинный код поверх ECC-CPU.

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

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

Оптимизация кодирования Рида — Соломона для передачи данных по сети

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

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

Многочлен строится потому, что традиционная формула прямой (y = mx + b) требует больших вычислительных затрат. Для ускорения Firedancer использует многочлены Лагранжа — специализированный метод построения многочленов. Они упрощают создание многочлена, необходимого для кодирования Рида — Соломона. Кроме того, процесс преобразуется в более эффективное умножение матрицы на вектор, которое подходит для многочленов более высоких степеней. Эта матрица имеет строгую структуру с рекурсивно повторяющимися шаблонами, причем первая строка полностью определяет весь шаблон. Благодаря такой структуре все элементы можно умножить быстрее. Для умножения на эту матрицу Firedancer использует подход O(n log n), представленный в статье 2016 года. Это самый быстрый из известных теоретических подходов к кодированию Рида — Соломона. В результате информация о четности вычисляется эффективнее, чем традиционными методами:

• Кодирование RS со скоростью более ~120 Гбит/с на ядро
• Декодирование RS со скоростью до ~50 Гбит/с на ядро
• Эти показатели приведены в сравнении с текущей скоростью кодирования RS около ~8 Гбит/с на ядро (rust-rse)

Благодаря оптимизированному подходу к кодированию Рида — Соломона Firedancer вычисляет информацию о четности в 14 раз быстрее традиционных методов. В результате данные быстро и надежно кодируются и декодируются, что необходимо для высокой пропускной способности и низкой задержки в глобальном масштабе.

Как обеспечивается безопасность Firedancer?

Возможности

Сейчас все валидаторы используют ПО на основе исходного клиента валидатора. Firedancer может повысить разнообразие клиентов и цепочки поставок Solana, если будет отличаться от клиента Solana Labs. В частности, это предполагает использование других зависимостей и отказ от Rust при разработке клиента.

Клиенты валидатора Solana Labs и Jito работают как единый процесс. После запуска монолитного приложения в рабочей среде повысить его безопасность сложно. Для оперативных обновлений безопасности в чистом Rust валидаторам с этими клиентами пришлось бы останавливать работу. Команда Firedancer может с самого начала заложить безопасную архитектуру в новый клиент.

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

Сложности

Несмотря на отличия от клиента Solana Labs, Firedancer должен точно воспроизводить его поведение. В противном случае несовместимость может привести к ошибкам консенсуса и создать угрозу безопасности. Риск можно снизить, стимулируя распределение доли стейка между обоими клиентами и продолжительное время удерживая долю Firedancer ниже 33% от общего стейка. В любом случае команда Firedancer должна реализовать полный набор функций протокола, независимо от сложности их корректной и безопасной реализации. Все должно соответствовать Firedancer. Поэтому команда не может разрабатывать код изолированно и должна сверять его с функциональностью клиента Labs. Ситуацию осложняет отсутствие спецификаций и документации, из-за чего Firedancer приходится воспроизводить неэффективные конструкции протокола.

Команда Firedaner также должна учитывать, что разрабатывает новый клиент на C. В C нет встроенных гарантий безопасности памяти, которые предоставляют такие языки, как Rust. Одна из основных целей кодовой базы Firedancer — сократить число уязвимостей безопасности памяти и уменьшить их последствия. Этой цели нужно уделять особое внимание, поскольку проект Firedancer развивается быстро. Firedancer должен сохранять скорость разработки, не допуская подобных ошибок. Песочница OS изолирует тайлы от OS. Тайлам разрешен доступ только к ресурсам и системным вызовам, необходимым для их работы. Поскольку каждый тайл имеет четко определенное назначение, а команда Firedancer разработала большую часть кода клиента, его разрешения сведены к минимуму согласно принципу наименьших привилегий.

Реализация многоуровневой защиты

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

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

Изоляция тайлов — результат параллельной архитектуры Firedancer. Каждый тайл выполняет отдельный процесс Linux и имеет одно четко определенное назначение. Например, тайл QUIC обрабатывает входящий трафик QUIC и передает инкапсулированные транзакции в тайл проверки. Затем тайл проверки проверяет подписи. Тайлы QUIC и проверки взаимодействуют через интерфейс общей памяти — процессы Linux могут передавать данные друг другу. Этот интерфейс общей памяти между двумя тайлами служит границей изоляции. Если бы ошибка в тайле QUIC позволила злоумышленнику выполнять произвольный код при обработке вредоносного пакета QUIC, другие тайлы не пострадали бы. В монолитном процессе это привело бы к немедленной компрометации. Эксплуатируя такую уязвимость на нескольких валидаторах, злоумышленник мог бы нанести вред всей сети. Он может снизить производительность тайла QUIC, но архитектура Firedancer ограничивает воздействие только этим тайлом.

Песочница OS изолирует тайлы от OS. Тайлам разрешен доступ только к ресурсам и системным вызовам, необходимым для их работы. Поскольку каждый тайл имеет четко определенное назначение, а команда Firedancer разработала почти весь код, его разрешения сведены к минимуму согласно принципу наименьших привилегий. Тайлы размещаются в отдельных пространствах имен Linux и получают ограниченное представление о системе. Из-за этого тайл не может получить доступ к большей части файловой системы, сети и другим процессам в той же системе. Пространства имен создают границу, ориентированную на безопасность. Однако злоумышленник все еще может обойти ее с помощью эксплойта ядра для повышения привилегий. Интерфейс системных вызовов — последний доступный из тайлов вектор атаки на ядро. Для защиты Firedancer использует seccomp-BPF, который фильтрует системные вызовы до их обработки ядром. Клиент может разрешить тайлам только выбранную группу системных вызовов. В некоторых случаях можно фильтровать параметры системных вызовов. Это важно, поскольку Firedancer может гарантировать, что системные вызовы чтения и записи работают только с определенными файловыми дескрипторами.

Реализация встроенной программы безопасности

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

Процесс начинается с инфраструктуры фаззинга для самостоятельного использования. Фаззинг — это метод автоматического обнаружения сбоев и ошибочных состояний, указывающих на уязвимости. Для этого каждый компонент, принимающий недоверенные пользовательские данные, подвергается стресс-тестированию. К таким компонентам относятся интерфейс P2P (парсеры) и виртуальная машина SBPF. OSS-Fuzz обеспечивает постоянное фаззинг-покрытие при изменении кода. Команда безопасности также настроила отдельный экземпляр ClusterFuzzer для непрерывного фаззинга, направляемого покрытием. Разработчики и инженеры по безопасности создают средства фаззинга — специальные версии модульных тестов для критически важных компонентов. Разработчики также могут добавлять новые фаззинг-тесты, которые автоматически подхватываются и запускаются. Цель состоит в том, чтобы тщательно протестировать все части с помощью фаззинга до перехода на следующий этап.

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

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

Итак, мы подходим к вопросу: каков текущий статус Firedancer?

Каков текущий статус Firedancer и что такое Frankendancer?

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

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

Что уже работает?

Frankendancer реализует все сетевые функции валидатора Solana:

• Входящие операции: QUIC, TPU, Sigverify, Dedup
• Исходящие операции: упаковка блоков, создание, подписание и отправка шредов (Turbine)

Frankendancer использует высокопроизводительный сетевой код Firedancer на C поверх среды выполнения и кода консенсуса Solana Labs на Rust.

Архитектура Frankendancer рассчитана на оптимизацию для высокопроизводительного оборудования. Хотя она поддерживает маломощные стандартные облачные хосты с обычными операционными системами Linux, команда Firedancer оптимизирует Frankendancer для серверов с большим числом ядер. Долгосрочная цель — повысить эффективность и производительность с помощью оборудования, уже доступного в облаке. Клиент поддерживает несколько одновременных подключений, аппаратное ускорение, случайное распределение потоков для балансировки нагрузки — то есть равномерного распределения сетевого трафика — и множество границ процессов для дополнительной изоляции компонентов.

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

Какова его производительность?

Frankendancer может обрабатывать 1 000 000 входящих сетевых транзакций в секунду (TPS) на тайл. Производительность линейно масштабируется с числом используемых ядер, поскольку каждый тайл использует одно ядро CPU. Frankendancer достиг этого результата всего на четырех ядрах, полностью загрузив сетевую карту (NIC) с пропускной способностью 25 Гбит/с.

Благодаря оптимизации Turbine Frankendancer значительно улучшил исходящие сетевые операции. Современное стандартное оборудование ноды обеспечивает скорость 6 Гбит/с на тайл. В частности, существенно выросла скорость шреддинга — разделения данных блока и их отправки валидаторам по сети. По сравнению с современными стандартными нодами Solana скорость шреддинга Frankendancer выше примерно на ~22% без деревьев Меркла и почти вдвое выше с деревьями Меркла. Это огромное улучшение текущей производительности распространения блоков и приема транзакций валидаторами.

Сетевая производительность Firedancer показывает, что клиент достиг аппаратного предела. Он обеспечивает максимально возможную производительность на современном стандартном оборудовании валидатора. Это важная техническая веха, которая демонстрирует способность клиента эффективно справляться с экстремальными нагрузками.

Frankendancer уже работает в testnet

Сейчас Frankendancer размещает стейк, голосует и производит блоки в testnet. Он совместимо работает вместе примерно с ~2900 другими валидаторами Solana Labs и Jito. Это развертывание демонстрирует стабильную производительность Firedancer на массовом оборудовании. Сейчас он работает на сервере Equinix Metal m3.large.x86 с CPU AMD EPYC 7513. Такой же тип сервера используют многие другие валидаторы. Это экономичное решение с оплатой по требованию, которая зависит от местоположения. Тарифы варьируются от $3,10 до $4,65 в час.

Прогресс Firedancer на пути к запуску в mainnet открывает несколько возможностей для оборудования нод:

• Современное оборудование валидаторов может обеспечить гораздо более высокую производительность каждой ноды
• Эффективность Firedancer позволяет валидаторам использовать более доступное оборудование с менее высокими характеристиками, сохраняя сопоставимую производительность
• Архитектура Firedancer позволяет использовать достижения в области оборудования и пропускной способности

Эти разработки вместе с другими инициативами, такими как Wiredancer — эксперименты команды Firedancer с аппаратным ускорением — и модульная среда Runtime/SVM на базе Rust, делают Firedancer перспективным решением.

Прогресс Firedancer также открывает дискуссию о возможности параллельного запуска валидаторами клиента Solana Labs вместе с Firedancer в рамках процесса side-caring. Такой подход может повысить жизнеспособность сети за счет преимуществ обоих клиентов и снизить потенциальное влияние проблем в любом из них на сеть в целом. Кроме того, возникает вопрос, решат ли такие проекты, как Jito, создать форк Firedancer. Это может привести к дальнейшей оптимизации извлечения MEV и эффективности обработки транзакций. Ответ покажет только время.

Заключение

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

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

Если вы дочитали до этого места, спасибо, anon! Укажите свой адрес электронной почты ниже, чтобы не пропускать новости Solana. Хотите узнать больше? Присоединяйтесь к нашему Discord и начните создавать будущее на самом производительном блокчейне уже сегодня.

Дополнительные материалы

• Сайт Jump
• Репозиторий Firedancer на GitHub
• Breakpoint 2023: новости Firedancer
• Breakpoint 2023: обеспечение безопасности Firedancer
• Breakpoint 2023: быстрое кодирование Рида — Соломона для сетевого взаимодействия
• Breakpoint 2023: работа FPGA при 8 млн TPS
• Техническая веха fd_quic в Firedancer
• Обновления сети Solana

Приложение

Введение в компьютерное оборудование и сети

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

Для полезных вычислений обычно нужны четыре ресурса: вычислительные мощности, оперативная память, дисковое хранилище и сеть. Вычисления, которые в основном выполняют CPU, GPU и потенциально FPGA, происходят невероятно быстро — со скоростью в миллиарды операций в секунду. Доступ к RAM обычно медленнее, чем выполнение вычислений в CPU. Дисковое хранилище обеспечивает долговременное хранение данных для вычислений. Однако доступ к данным на твердотельных накопителях (SSD) и жестких дисках (HDD) намного медленнее операций CPU. SSD зачастую медленнее в тысячи раз, а HDD — в десятки тысяч раз. Сеть, включая интернет и локальные сети, работает медленнее всего. Она может быть более чем в миллион раз медленнее CPU.

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

Центральный процессор (CPU)

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

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

В CPU также есть кеши — небольшие высокоскоростные блоки памяти внутри процессора. В них хранятся часто используемые данные и инструкции, поэтому извлекать их можно быстрее, чем из RAM. Обычно существует несколько уровней кеша (L1, L2, L3 и иногда L4), которые различаются объемом и скоростью. Сначала используется кеш L1 — самый маленький и быстрый. Если нужных данных там нет, CPU проверяет более крупный и немного более медленный кеш L2, а затем следующие уровни. Такая иерархическая система кеширования сокращает время ожидания данных из RAM и повышает общую скорость обработки. Эффективное использование кеша крайне важно для таких приложений, как Firedancer, где расстояние от CPU до RAM может снижать производительность. Это особенно актуально для обсуждения скорости света и использования FPGA.

Отдельно отметим, что термин «x86» обозначает семейство CPU, основанных на определенной архитектуре, которую первоначально разработала компания Intel. Эта архитектура известна совместимостью с широким спектром программного обеспечения, поскольку большинство продаваемых настольных компьютеров и ноутбуков построено на архитектуре семейства x86.

Графический процессор (GPU)

GPU — специализированный процессор, изначально разработанный для ускорения рендеринга изображений и видео в компьютерной графике. Его основная задача — управлять графической производительностью и повышать ее, особенно в задачах с изображениями высокого разрешения и сложными графическими вычислениями, например в видеоиграх или 3D-моделировании.

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

Оперативная память (RAM)

RAM — это кратковременная память компьютера, в которой хранятся активно используемые или обрабатываемые данные. Именно здесь CPU «помнит», над чем работает в данный момент, и хранит необходимую информацию для быстрого доступа и обработки.

RAM с кодом коррекции ошибок (ECC) может обнаруживать и исправлять распространенные типы внутреннего повреждения данных. Эта функция необходима в средах, где важна точность данных, например в научных вычислениях, финансовых транзакциях или нодах блокчейна. RAM с ECC автоматически обнаруживает и исправляет небольшие ошибки в хранимых данных. Коррекция ошибок выполняется дополнительным оборудованием в модулях RAM, которое проверяет сохраненные данные.

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

Дисковое хранилище

Дисковое хранилище обеспечивает долговременное хранение данных, даже когда компьютер выключен. Существует два основных типа дисковых накопителей: жесткие диски (HDD) и твердотельные накопители (SSD).

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

SSD, напротив, используют для хранения данных флеш-память. Флеш-память — это электронное энергонезависимое хранилище, данные в котором можно стирать и перезаписывать. В отличие от HDD, в накопителях с флеш-памятью нет движущихся частей. Данные хранятся во взаимосвязанных микросхемах флеш-памяти. SSD быстрее HDD, поскольку могут мгновенно получать доступ к данным, не ожидая вращения диска или перемещения головки чтения и записи. Благодаря этой скорости SSD отлично подходят для приложений, где критически важен быстрый доступ к данным. Однако стоимость гигабайта в SSD выше, чем в HDD.

Также существуют SSD NVMe (Non-Volatile Memory Express). Эти SSD используют свой скоростной потенциал через компьютерную шину Peripheral Component Interconnect Express (PCIe). Накопители NVMe обеспечивают значительно более высокую скорость и меньшую задержку, чем традиционные SSD. Они идеально подходят для интенсивных нагрузок, например высокочастотной торговли и блокчейн-приложений, где критически важны быстрая обработка и извлечение данных. Хотя NVMe стоят дороже, они становятся стандартом для высокопроизводительных вычислений.

Материнская плата

Источник: схема Gigabyte X570 Elite из публикации в r/buildapc на Reddit

Материнская плата компьютера — это большая печатная плата, которая соединяет компоненты компьютера и обеспечивает обмен данными между ними. К этим компонентам относятся CPU, GPU, RAM, накопители и периферийные устройства, например клавиатуры и мыши.

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

Материнская плата управляет потоком данных внутри системы. Она контролирует передачу данных из CPU в RAM для обработки, из RAM в накопители для сохранения и из GPU на видеовыходы для отображения графики. Кроме того, на материнской плате находится системная BIOS (Basic Input/Output System). BIOS играет ключевую роль в управлении системой и ее мониторинге. При запуске BIOS инициализирует и тестирует аппаратное обеспечение компьютера. Она также следит за состоянием системы, контролируя такие показатели, как температура, напряжение и скорость вращения вентиляторов.

В архитектуре Firedancer материнская плата играет ключевую роль. Расстояние между CPU и RAM существенно влияет на производительность: чем оно меньше, тем выше скорость передачи данных. Это особенно важно для таких приложений, как Firedancer, которым нужны высокая пропускная способность и низкая задержка. Поэтому архитектура с учетом NUMA и потенциальное использование FPGA соответствуют потребностям Firedancer в оптимальном распределении памяти и эффективной обработке. Далее в статье мы объясним, что означает учет NUMA и что такое FPGA.

Операционные системы, виртуальные машины и оптимизация на уровне ядра

Операционная система (OS) — основное программное обеспечение, управляющее аппаратными и программными ресурсами компьютера. Она выступает посредником между пользователем и аппаратным обеспечением компьютера. OS предоставляет интерфейс для взаимодействия с системой, а также распределяет ресурсы между приложениями и управляет ими. Популярные примеры — Windows, macOS и Linux.

Ядро лежит в основе каждой операционной системы. Это важнейший компонент, который напрямую взаимодействует с аппаратным обеспечением системы. Ядро полностью контролирует все процессы в системе. Оно управляет распределением памяти, планированием процессов и запросами ввода-вывода. Работая на столь низком уровне, ядро играет важную роль в производительности и стабильности системы.

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

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

Понимание этих концепций крайне важно в контексте Firedancer. Для повышения производительности Firedancer применяет несколько оптимизаций на уровне ядра:

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

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

Входящий и исходящий трафик

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

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

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

Конвейеры и параллелизм данных

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

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

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

Программируемая пользователем вентильная матрица (FPGA)

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

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

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

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

‍