Дашборд производительности блокчейн-платформ

Магистерская диссертация · ИТМО · генерация: 2026-06-08T11:17:38.876Z

Результаты исследования

Коэффициенты трёхуровневой модели и графики из ВКР по восьми блокчейн-платформам.

Рекомендации по выбору

Восемь типовых классов прикладных задач: какие платформы подходят и почему — полный текст раздела 4.3 ВКР.

Репозиторий проекта

Исходники бенчмарков, скрипты сборки дашборда, инструкции воспроизведения. GitVerse: ilvirnizaev/nir-dashboard.

О чём этот дашборд

Агрегированные результаты бенчмарков в рамках магистерской диссертации «Исследование производительности различных блокчейн-платформ». Дашборд собирается из 112 исходных JSON-записей и обновляется конвейером CI/CD при каждом изменении репозитория.

Платформы в наборе: Ethereum, BNB, Avalanche, Solana, Cardano, Sui, Near, Polkadot.

Цель — сопоставить платформы по научно обоснованным критериям и сформулировать практические рекомендации по выбору для типовых сценариев разработки.

Критерии отбора платформ и классификация

Платформы отобраны по критерию разнообразия архитектурных парадигм. В работе принята классификация исследуемых платформ на два архитектурных семейства — EVM-совместимые и альтернативные Layer-1 — по критериям модели исполнения и формата транзакции. Классификация выступает методологическим инструментом: определяет, какие прямые сопоставления корректны, а какие требуют ограничения до независимых от модели исполнения показателей.

Platform Polkadot отмечен как relay chain — инфраструктурный слой, сопоставляется с другими платформами только по протокольным характеристикам.

Платформа Парадигма Консенсус Модель транзакций Финальность (ориентировочно) Семейство Примечание
Ethereum EVM, эталон смарт-контрактной L1 PoS (Beacon Chain) account 12,8 мин (2 эпохи) EVM-совместимые платформы
BNB EVM-клон с PoSA, ограниченный набор валидаторов PoSA (21 валидатор) account ~7,5 с EVM-совместимые платформы
Avalanche Avalanche consensus, EVM-совместимая C-Chain Avalanche (DAG-based sub-second finality) account ~1 с EVM-совместимые платформы
Solana Parallel execution, Proof-of-History PoH + Tower BFT (PoS) account + programs ~400 мс Альтернативные Layer-1
Cardano eUTXO, формальная верификация, Plutus Ouroboros (PoS) eUTXO вероятностная, ~20 с–минуты Альтернативные Layer-1
Sui Object-centric, Move VM Narwhal + Bullshark object-based ~250 мс (fast path) Альтернативные Layer-1
Near Динамическое шардирование (Nightshade) Doomslug + Thresholded PoS account + Wasm-runtime ~2 с (детерминированная через Doomslug) Альтернативные Layer-1
Polkadot Multi-chain, общая безопасность через relay chain BABE + GRANDPA (hybrid) Substrate account / ink! контракты ~12–60 с (GRANDPA) Альтернативные Layer-1 relay chain

Методика измерений

  1. Отбор платформ. В набор включены восемь публичных Layer-1 платформ, охватывающих ключевые архитектурные подходы: Ethereum, BNB Smart Chain, Avalanche, Solana, Cardano, Sui, NEAR, Polkadot. Покрыты три модели данных (счётная, eUTXO, объектная), три семейства консенсусов (BFT, Snow-протоколы, гибридные с PoH), статическое и динамическое шардирование.
  2. Трёхуровневая модель оценки производительности. Каждый уровень соответствует одному физическому и логическому слою системы. Уровень 1 — вычислительный узел: процессор, память, виртуальная машина платформы; измеряется потолок движка TPS_env_max. Уровень 2 — сеть и консенсус: распространение блоков, координация валидаторов; даёт коэффициент K_consensus сохранения производительности. Уровень 3 — профиль пользовательской нагрузки: усложнение транзакции (контрактный вызов или Native Asset); даёт коэффициент K_load.
  3. Мультипликативная формализация. Модель записывается выражением TPS = TPS_env_max · K_consensus · K_load. Безразмерные коэффициенты K_consensus, K_load и производный показатель PoD = 1 / K_consensus (цена децентрализации) позволяют количественно атрибутировать потери производительности по уровням.
  4. Экспериментальная установка. Развёрнуто 16 стендов — по два на каждую из восьми платформ: одноузловой стенд (потолок движка) и многоузловой стенд с реальным протокольным консенсусом каждой платформы (для измерения K_consensus и K_load). Все стенды контейнеризованы и работают на единой серверной установке Dell PowerEdge R740/R750.
  5. Единая нагрузка. Базовая единица транзакции — простой перевод нативного актива между двумя адресами без вызова смарт-контрактов. Выбор обусловлен доступностью на всех восьми платформах, изоляцией консенсусного слоя от вычислительного и единым основанием сравнимости.
  6. Девять универсально сопоставимых показателей (см. таблицу «Критерии сравнения»). Из 13 кандидатов отобраны TPS (последовательный и параллельный), точка насыщения, пропускная ёмкость, время блока, время финальности, коэффициент параллелизма, K_consensus, K_load и PoD. Принципы отбора: единое основание сравнимости, покрытие трёхуровневой модели, опора на установившуюся методологическую базу бенчмаркинга.
  7. Воспроизводимость. Все стенды контейнеризованы (Docker Compose), версии клиентов и SDK зафиксированы. JSON-результаты детерминированы при одинаковых входах. Полная инструкция воспроизведения — в REPRODUCE.md репозитория.

Результаты исследования

Все замеры выполнены на единой серверной установке Dell PowerEdge R740/R750 (2× Intel Xeon Silver 4210, 128 ГБ ECC, NVMe RAID), что устраняет аппаратные различия между платформами. Стенды развёрнуты в двух конфигурациях для каждой платформы: одноузловой (потолок движка) и многоузловой (с реальным протокольным консенсусом).

Сводная таблица замеров и коэффициенты трёхуровневой модели

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

TPS_mainnet = TPS_env_max · K_consensus · K_load

Коэффициенты K_consensus и K_load рассчитаны по четырём замерам, выполненным на серверной установке Dell PowerEdge: TPS_1_simple (параллельный максимум нативного перевода на одноузловом стенде), TPS_4_simple (на многоузловом стенде с реальным протокольным консенсусом) и TPS_4_smart (на многоузловом стенде при усложнённой токен-операции). K_consensus = TPS_4_simple / TPS_1_simple; K_load = TPS_4_smart / TPS_4_simple; PoD = 1 / K_consensus — цена децентрализации.

Платформа (стенд) TPS_1_simple TPS_4_simple TPS_4_smart K_consensus K_load PoD
Ethereum (PoS 64-val) 100 60 36 0,6 0,6 1,67
BNB (Parlia 21-val) 2 000 1 500 900 0,75 0,6 1,33
Avalanche (Snowman++ 5-val) 420 320 243 0,76 0,76 1,32
Cardano (Praos 3-pool) 150 90 83 0,6 0,92 1,67
Polkadot (zombienet 4+2) 600 400 168 0,67 0,42 1,5
Solana (agave 5-val) 6 000 4 800 2 784 0,8 0,58 1,25
Near (Nightshade 3-val) 3 000 500 250 0,17 0,5 5,88
Sui (Mysticeti 4-val) 2 500 2 000 1 040 0,8 0,52 1,25

Сводная таблица соответствует таблице 12 (продолжение) выпускной квалификационной работы.

Графики из ВКР

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

Последовательный TPS на локальных стендах
Последовательный TPS на локальных стендах
Кривые нагрузки: TPS в зависимости от размера пакета
Кривые нагрузки: TPS в зависимости от размера пакета
Соотношение параллельного и последовательного TPS
Соотношение параллельного и последовательного TPS
Время блока и финальности
Время блока и финальности
Максимальный TPS при токен-трансферах
Максимальный TPS при токен-трансферах
Пропускная ёмкость (МБ/с)
Пропускная ёмкость (МБ/с)
K_consensus: доля производительности после введения многоузлового консенсуса
K_consensus: доля производительности после введения многоузлового консенсуса
K_load: доля производительности при переходе к усложнённой нагрузке
K_load: доля производительности при переходе к усложнённой нагрузке
Декомпозиция производительности: TPS_env_max → × K_consensus → × K_load
Декомпозиция производительности: TPS_env_max → × K_consensus → × K_load
Трёхуровневая модель оценки производительности
Трёхуровневая модель оценки производительности

Критерии сравнения

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

Показатель Единица Что характеризует
TPS транзакций/с Пропускная способность платформы при стандартизированной нагрузке (минимальный нативный перевод). Измеряется в двух режимах подачи — последовательном (синхронный UX) и параллельном (батчи 1, 10, 50, 100, 200, 500, 1000, 2000, 5000, 10000) — обеспечивая полную характеристику отклика платформы на различные профили запросов.
Точка насыщения размер пакета Безопасная ширина рабочего окна параллельной нагрузки (max b при sr ≥ 95 %).
Пропускная ёмкость МБ/с Абсолютная байтовая пропускная способность сети при росте полезной нагрузки.
Среднее время блока секунды Протокольная скорость производства блоков.
Время финальности секунды Время до необратимого подтверждения транзакции.
Коэффициент параллелизма безразмерное Глубина архитектурного параллелизма; вычисляется как отношение параллельной и последовательной пропускной способности (Пар/Посл), значение ≥ 1.
K_consensus безразмерное Вклад уровня 2 модели — доля производительности, сохранённая после введения сетевого консенсуса; диапазон (0, 1].
K_load безразмерное Вклад уровня 3 модели — доля производительности, сохранённая при усложнении транзакции; диапазон (0, 1].
PoD безразмерное Цена децентрализации: во сколько раз сеть с консенсусом медленнее идеального движка; обратная величина к K_consensus, значение ≥ 1.

4.3 Практические рекомендации по выбору платформы

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

На основании эмпирических замеров (подраздел 4.1) и численного расчёта коэффициентов модели TPS_mainnet (подраздел 4.2) разработаны практические рекомендации по выбору блокчейн-платформы. Рекомендации сгруппированы по типовым классам прикладных задач. Для каждого класса указаны предпочтительные платформы с обоснованием через конкретные метрики и коэффициенты модели. Сводная таблица рекомендаций представлена ниже.

Таблица 13 — Сводные практические рекомендации по выбору платформы

Класс задач Платформы первого выбора Обоснование
Массовая пользовательская нагрузка Solana, NEAR, Sui, BSC Лучшим общим выбором выступает Solana (параллельный TPS 6 000, финальность 0,8 с, K_consensus = 0,80).
Высокая требуемая децентрализация Polkadot, Cardano, Avalanche Polkadot обеспечивает равномерное распределение влияния между узлами за счёт NPoS-номинирования с регулярной ротацией около 600 активных валидаторов.
Естественный параллелизм данных Sui, NEAR, Solana, Cardano Наибольшие коэффициенты: Sui (объектная модель Move, ×5 556), NEAR (счётная модель со встроенным шардированием Nightshade, ×6 818), Solana (счётная модель с параллельной средой Sealevel, ×2 400), Cardano (eUTXO, ×319).
Приватные корпоративные сети EVM-форки (Quorum, Hyperledger Besu, Geth Clique), Substrate EVM-форки обеспечивают совместимость с публичной сетью и производительность от 25 TPS в режиме Clique-PoA с одним подписантом до 2 000 TPS на Parlia с 21 валидатором.
Высокочастотные финансовые приложения / DEX с низкой задержкой Solana, Sui Только Solana (время блока 0,4 с, финальность 0,8 с) и Sui (время блока 0,38 с, финальность 1,5 с) удовлетворяют требованиям; причём Sui дополнительно предоставляет «быстрый путь» для операций с собственными объектами, не требующих полного консенсуса, что снижает фактическую задержку до сотен миллисекунд.
Прототипирование и обучение NEAR, Sui, Solana Простой локальный запуск без Docker: <code>near-sandbox</code>, <code>sui start</code>, <code>solana-test-validator</code>.
Большие данные on-chain BSC, Sui, Solana Лидером выступает BNB Smart Chain (3,3 МБ/с) благодаря газовому лимиту 140 млн; Sui (2,5 МБ/с) и Solana (2,0 МБ/с) занимают второе и третье места.
Токенизация активов (stablecoin, RWA) Cardano, Avalanche, Sui Cardano — единственная платформа в наборе, где токены реализованы как первоклассный примитив протокола: K_load = 0,92 даёт фундаментальное преимущество в массовых переводах.

Развёрнутое описание классов задач

1Массовая пользовательская нагрузка

К данному классу задач относятся платёжные сервисы, игровые приложения, социальные сети с on-chain действиями, маркетплейсы и кошельковые приложения. Класс характеризуется высокой частотой коротких операций при умеренной сложности транзакций. Ключевые метрики отбора — параллельный TPS не ниже 1 000, K_consensus не ниже 0,75 и время финальности не более 5 секунд. По совокупности этих критериев лучшим общим выбором выступает Solana: достигнутый параллельный TPS 6 000, субсекундная финальность 0,8 секунды и K_consensus = 0,80 обеспечивают одновременное удовлетворение всех трёх требований. Sui (2 500 TPS, финальность 1,5 секунды, K_consensus = 0,80) и BNB Smart Chain (2 000 TPS, финальность 7,5 секунды, K_consensus = 0,75) выступают полноценными альтернативами с акцентом соответственно на объектную модель данных и совместимость с инструментарием Ethereum. NEAR с локальным K_consensus = 0,17 представляет интерес для приложений, ориентированных на горизонтальное масштабирование через шардирование Nightshade — низкое значение коэффициента отражает накладные расходы конвейерного шардирования при малом числе валидаторов локального стенда и может быть существенно выше в production-сети с 195 валидаторами. Платформы Ethereum и Cardano с параллельным TPS 100 и 150 соответственно для данного класса задач не рекомендуются.

2Высокая требуемая децентрализация

К данному классу относятся системы голосования, регистры активов (земельные кадастры, регистрации компаний), системы идентичности, государственные сервисы и криптовалюты как «цифровое золото». Класс характеризуется критичностью устойчивости к коллизионным атакам валидаторов. Ключевой метрикой выступает фактическое число активных валидаторов и архитектурная ориентация на широкий валидаторский набор. Polkadot обеспечивает равномерное распределение влияния между узлами за счёт механизма NPoS-номинирования с регулярной ротацией около 600 активных валидаторов. Cardano с более чем 3 000 стейк-пулов и эпохальной структурой Ouroboros Praos демонстрирует наибольшую формальную децентрализацию среди рассмотренных платформ. Avalanche находит баланс между этими крайностями: более 600 валидаторов при субсекундной финальности, достигаемой благодаря субсемплированному голосованию. Такое сочетание делает платформу привлекательной для приложений, где скорость подтверждения остаётся приоритетом.

3Естественный параллелизм данных

К классу задач с естественным параллелизмом данных относятся системы управления цепочками поставок, где партии товаров обрабатываются независимо друг от друга, мультиарендные SaaS-сервисы, маркетплейсы цифровых активов с независимыми токенами, а также DeFi-протоколы с раздельными пулами ликвидности. Класс характеризуется возможностью разделить транзакции на независимые группы без конфликта по разделяемому состоянию. Ключевая метрика — коэффициент параллелизма (отношение параллельного TPS к последовательному) не ниже 1 000, а также поддержка модели данных без глобальной блокировки. По этим критериям наибольшие коэффициенты демонстрируют Sui (объектная модель Move, ×5 556), NEAR (счетовая модель со встроенным шардированием Nightshade, ×6 818), Solana (счетовая модель с параллельной средой исполнения Sealevel, ×2 400) и Cardano (eUTXO, ×319, где каждый UTXO выступает независимой единицей). Принципиальное практическое следствие: при выборе одной из этих платформ требуется адаптация архитектуры приложения — данные должны быть структурированы так, чтобы транзакции не конкурировали за один и тот же объект, аккаунт или UTXO. В противном случае фактический параллелизм не реализуется, и пропускная способность сводится к последовательному TPS платформы.

4Приватные корпоративные сети

К данному классу относятся межбанковские расчётные системы (consortium blockchain), государственные реестры с ограниченным доступом, B2B-сети снабжения и корпоративные системы документооборота. Класс характеризуется ограниченным набором известных участников и потребностью в контролируемой инфраструктуре. Ключевые метрики — низкая ресурсная стоимость узла, гибкость конфигурации консенсуса и зрелый инструментарий приватного развёртывания. Среди технологических стеков первого выбора выделяются два направления. EVM-форки (Quorum, Hyperledger Besu и Geth Clique) обеспечивают совместимость с публичной сетью и производительность от 25 TPS в режиме Clique-PoA с одним подписантом до 2 000 TPS на Parlia с 21 валидатором. Substrate на базе Polkadot SDK позволяет достичь до 1 000 TPS на собственном парачейне и подходит для государственных систем со специализированными средами исполнения.

С точки зрения аппаратных требований один узел go-ethereum в режиме Clique-PoA с единственным подписантом потребляет около 256 МБ оперативной памяти и одно процессорное ядро. Такой конфигурации достаточно для приватной сети из двух-пяти узлов с нагрузкой до 25 TPS. При необходимости превысить порог в 100 TPS целесообразно перейти на нативный консенсус Parlia либо масштабировать сеть горизонтально через боковые цепи.

5Высокочастотные финансовые приложения

Класс высокочастотных финансовых приложений охватывает децентрализованные биржи, деривативные протоколы, бессрочные свопы, маркет-мейкеры и арбитражные системы. Все эти приложения чувствительны к задержке подтверждения транзакции на уровне долей секунды. Ключевыми требованиями к платформе выступают время блока не более 0,5 секунды и время финальности не более 2 секунд. По совокупности этих требований подходящими выступают только Solana (время блока 0,4 секунды, финальность 0,8 секунды) и Sui (время блока 0,38 секунды, финальность 1,5 секунды); причём Sui дополнительно предоставляет «быстрый путь» для операций с собственными объектами, не требующих полного консенсуса, что снижает фактическую задержку до сотен миллисекунд. Платформы Ethereum (12 секунд время блока, 768 секунд финальность), BNB Smart Chain (7,5 секунды финальность) и Cardano (около 10 минут эпохальной финализации) для высокочастотных приложений не подходят: длительные блоки делают высокочастотные операции экономически неэффективными.

6Прототипирование и обучение

К данному классу относятся учебные проекты, MVP, исследовательские эксперименты, демонстрационные приложения и хакатоны. Класс характеризуется минимизацией порога входа: простой локальный запуск, прозрачный SDK, короткий цикл итераций. Платформы первого выбора — NEAR, Sui и Solana: все три позволяют поднять одноузловую сеть без Docker (near-sandbox, sui start, solana-test-validator) и обладают зрелым SDK (near-api-js, @mysten/sui.js, @solana/web3.js) с обширной обучающей документацией.

7Большие данные on-chain

К классу относятся приложения с потребностью хранить и передавать значительные объёмы данных непосредственно в блокчейне: метаданные NFT, оракульные данные, on-chain сертификаты, документы с цифровыми подписями, аудит-логи. Ключевые метрики — пропускная ёмкость в мегабайтах в секунду, отсутствие жёсткого ограничения на размер транзакции, низкая чувствительность TPS к размеру полезной нагрузки. По этим критериям лидером выступает BNB Smart Chain (3,3 МБ/с) благодаря крупному газовому лимиту 140 миллионов; Sui (2,5 МБ/с) и Solana (2,0 МБ/с) занимают второе и третье места. NEAR (1,5 МБ/с) выгоден равномерной обработкой любого размера полезной нагрузки благодаря конвейерному шардированию. Polkadot relay-цепь (0,015 МБ/с) для данного класса задач непригодна вследствие весовой модели Substrate, в которой вес внешнего вызова линейно пропорционален размеру аргумента.

8Токенизация активов

К данному классу относятся стейблкоины, security tokens, real-world assets (RWA), сертификаты и лицензии — задачи, характеризующиеся массовыми переводами однородных токенов. Ключевая метрика — K_load, отражающий долю производительности, сохранённую при переходе от нативного перевода к токен-операции. Cardano выступает единственной платформой в наборе, где токены реализованы как первоклассный примитив протокола, а не как смарт-контракт: K_load = 0,92 даёт фундаментальное преимущество в массовых переводах. Avalanche обеспечивает компромисс между умеренными накладными расходами ERC-20 (K_load = 0,76) и субсекундной финальностью. Sui с моделью Coin как Move-объекта (K_load = 0,52) предлагает компромисс между объектной природой токена и накладными расходами при конкуренции объектов в крупных пакетах. BNB Smart Chain с большой ёмкостью блока компенсирует накладные расходы ERC-20 абсолютным значением пропускной способности.

Архитектурный анализ результатов

Полученные результаты подтверждают, что модель данных платформы непосредственно определяет характер её производительности. Счётные платформы со стандартной средой исполнения имеют ограниченный потенциал параллелизма — коэффициент параллелизма Ethereum составляет ×1 250. Платформы с параллельной средой исполнения преодолевают это ограничение на архитектурном уровне (Solana достигает ×2 400). Объектно-ориентированная модель Sui и eUTXO-модель Cardano, изначально спроектированные для параллельной обработки, демонстрируют наибольший разрыв между последовательным и параллельным TPS: ×5 556 и ×319 соответственно.

Наиболее высокий коэффициент консенсуса показывают параллельные Solana и Sui (0,80), а также протоколы с компактным валидаторским набором, в частности BSC Parlia с показателем 0,75. По коэффициенту нагрузки лидирует Cardano со значением 0,92. Такой результат объясняется тем, что нативные активы встроены в протокол на уровне структуры транзакции и не требуют обращения к контрактному слою.

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

Выводы

Как воспроизвести

Для получения собственных замеров:

  1. Клонировать репозиторий: git clone <url>
  2. Запустить локальные ноды нужных платформ (инструкции — в INSTRUCTIONS.md каждого *-benchmark/).
  3. Установить зависимости и запустить бенчмарк: cd <platform>-benchmark && npm install && npm run benchmark
  4. Собрать дашборд: cd dashboard && node src/build.js → откроется dist/index.html со свежими цифрами.
  5. Либо запустить через Docker: docker compose -f dashboard/docker-compose.yml up -d, http://localhost:8080.

Конвейер CI/CD (.gitverse/workflows/ci.yml) автоматически прогоняет тесты, бенчмарк и публикует обновлённый дашборд на GitVerse Pages при каждом push в main.