Що означає продуктивність мережі поза одним красивим числом TPS

Число транзакцій за секунду (TPS) — найвідоміший, але водночас найменш інформативний вимірник продуктивності блокчейн-мережі. Воно показує кількість оброблених транзакцій, але не відповідає на головне питання: який досвід отримує користувач і розробник у реальних умовах. Цей матеріал розбирає, з яких компонентів насправді складається продуктивність мережі, чому одне число TPS не дозволяє порівнювати системи та які метрики потрібні для чесної оцінки.

Що підтверджує механіка, а що ні

Теза: продуктивність блокчейн-мережі є багатовимірною характеристикою, яку неможливо адекватно відобразити одним скалярним значенням TPS. Реальна корисність мережі для людей і розробників визначається комбінацією затримок, стабільності, передбачуваності та складу транзакцій, а не піковою швидкістю в ідеальних умовах.

Межа аналізу: цей матеріал описує концептуальну рамку для розуміння продуктивності. Він не містить поточних вимірювань мережі Solana, не порівнює конкретні значення з іншими блокчейнами й не замінює матеріали про формування блоку та порядок транзакцій чи про компроміси між швидкістю, вартістю й децентралізацією. Базове уявлення про архітектуру можна отримати в огляді протоколу Solana простими й точними словами.

Механізм і зв’язки

Коли говорять «мережа обробляє X транзакцій за секунду», виникає кілька фундаментальних питань, на які це число не відповідає.

Що саме рахується як одна транзакція

Транзакція — не однорідна одиниця. Одна транзакція може бути простим переказом токенів між двома адресами, а може містити кілька внутрішніх викликів програм (CPI — Cross-Program Invocation), кожен із яких виконує логіку, читає й записує стан. Обчислювальна вартість цих двох операцій відрізняється на порядки. Тому порівнювати TPS двох мереж без урахування складу транзакцій — це порівнювати кількість деталей, які зібрали на двох заводах, не зважаючи на те, що один завод збирає гачки, а інший — двигуни.

Щоб TPS мало сенс, потрібна принаймні специфікація: який саме тип транзакцій рахується, яка частка містить програмні виклики, який обсяг даних читання й запису стану припадає на одну транзакцію.

Затримка та фінальність проти пропускної здатності

TPS — це міра пропускної здатності (throughput). Але для користувача, який натискає кнопку, критично важлива затримка (latency) — час від моменту відправлення транзакції до моменту, коли вона вважається фінальною. Мережа може теоретично пропускати тисячі транзакцій за секунду, але якщо конкретна транзакція користувача чекає у черзі кілька секунд, досвід буде поганим.

Фінальність — окремий параметр. У деяких архітектурах транзакція «підтверджена» через кілька сотень мілісекунд, але фінальна — лише після кількох наступних блоків. Межа між «підтверджено» та «фінально» має пряме значення для розробників: від цього залежить, коли можна безпечно показати користувачу результат операції.

Пікова продуктивність проти стійкої

Піковий TPS — це максимальна швидкість, яку мережа демонструє в штучних або максимально сприятливих умовах. Стійкий TPS (sustained throughput) — це швидкість, яку мережа здатна підтримувати тривалий час без деградації. Різниця між ними може бути суттєвою, і саме стійкий TPS визначає, чи придатна мережа для реального навантаження.

Дисперсія та передбачуваність

Дві мережі з однаковим середнім TPS можуть вести себе кардинально по-різному. Якщо в одній підтвердження завжди займає приблизно однаковий час, а в іншій — коливається від мілісекунд до кількох секунд, друга мережа створює непередбачуваний досвід. Дисперсія часу підтвердження (jitter) — це окремий вимірник, який впливає на архітектуру клієнтських застосунків: розробник має закладати буфери, обробляти таймаути, показувати індикатори завантаження.

Вплив складу навантаження на продуктивність

Продуктивність мережі не є константою — вона залежить від того, які саме транзакції надходять. Навантаження, що складається з однотипних простих переказів, обробляється інакше, ніж навантаження з великою кількістю складних програмних викликів, які звертаються до одних і тих самих об’єктів стану. Конфлікти доступу до стану (state contention) можуть суттєво знизити ефективну пропускну здатність навіть за умови наявності вільних обчислювальних ресурсів.

Це означає, що продуктивність мережі — це функція не лише від її архітектури, а й від реального профілю використання в конкретний момент.

Вимірник	Що показує	Чого не показує
TPS (піковий)	Максимальну кількість транзакцій за секунду в ідеальних умовах	Стійкість, реальний досвід, склад транзакцій
TPS (стійкий)	Пропускну здатність за тривалого навантаження	Затримку окремої транзакції, дисперсію
Затримка (latency)	Час від відправлення до підтвердження	Фінальність, пропускну здатність
Фінальність (finality)	Момент, після якого транзакцію неможливо відкликати	Швидкість обробки інших транзакцій
Дисперсія (jitter)	Стабільність часу підтвердження	Середню швидкість, причину коливань
Дроп-рейт (drop rate)	Частку відхилених транзакцій	Причини відхилення, досвід успішних транзакцій

Що підтверджують джерела

Щоб перейти від абстрактної рамки до конкретної оцінки продуктивності будь-якої мережі, потрібен набір даних і чітка методологія. Ось що було б необхідно для обґрунтованої оцінки.

Що потрібно для вимірювання

• Специфікація навантаження: опис типів транзакцій, їхнього складу, кількості програмних викликів, обсягу читання й запису стану. Без цього будь-яке число TPS позбавлене контексту.
• Тривалість тесту: пікові виміри протягом секунд не відображають стійку продуктивність. Потрібен час, достатній для виявлення деградації, накопичення черг, змін у поведінці валідаторів.
• Середовище: конфігурація вузлів (апаратне забезпечення, мережеві умови), кількість валідаторів, їхня географічна розподіленість. Продуктивність на однорідному тестовому стенді відрізняється від продуктивності на географічно розподіленій мережі.
• Метрики дисперсії: не лише середній час підтвердження, а й перцентилі (наприклад, 50-й, 90-й, 99-й), щоб розуміти, який досвід отримує переважна більшість користувачів, а не лише медіанний.
• Дроп-рейт: кількість транзакцій, які були відхилені або не ввійшли в блок протягом розумного часу.

Позиції сторін та їхні інтереси

Різні учасники екосистеми мають різні мотиви в тому, як подавати продуктивність:

• Команди протоколу зацікавлені показати максимальну пропускну здатність, оскільки це привертає увагу розробників. Їхні публічні цифри часто відображають піковий TPS на синтетичному навантаженні.
• Валідатори цікавить стійка продуктивність за реального навантаження, оскільки від цього залежить їхня ефективність, витрати на інфраструктуру та репутація.
• Розробники застосунків потребують розуміння затримки, дисперсії та дроп-рейту за типового для їхнього застосунку профілю навантаження. Для них піковий TPS мережі має другорядне значення.
• Кінцеві користувачі сприймають продуктивність як комбінацію швидкості реакції інтерфейсу, надійності та вартості. Вони не думають категоріями TPS.

Ця розбіжність інтересів пояснює, чому публічні цифри продуктивності часто не збігаються з суб’єктивним досвідом використання.

Що потрібно перевірити перед прийняттям будь-якого числа TPS

1. Чи вказано специфікацію транзакцій (тип, склад, обсяг стану)?
2. Чи вказано тривалість тесту та чи це пікове чи стійке значення?
3. Чи описано середовище (кількість вузлів, апаратне забезпечення, топологія мережі)?
4. Чи наведено перцентилі затримки, а не лише середнє?
5. Чи вказано дроп-рейт?
6. Чи є незалежне підтвердження (репродукція тесту третьою стороною)?

Якщо хоча б на одне з цих питань немає відповіді, число TPS слід трактувати як маркетинговий орієнтир, а не як інженерну характеристику.

Слабкі місця й компроміси

Компроміси між вимірниками

Продуктивність не є вектором, який можна максимізувати за всіма напрямками одночасно. Існують структурні компроміси:

• Пропускна здатність проти затримки: у системах з пакетною обробкою (блоками) збільшення розміру блоку може підвищити TPS, але водночас збільшити час очікування транзакції перед включенням у блок.
• Стійкість проти пікової швидкості: система, оптимізована для максимального піку, може бути менш стійкою за тривалого навантаження через накопичення черг, зростання споживання пам’яті або фрагментацію ресурсів.
• Однорідність проти гнучкості: система, яка добре обробляє однотипні транзакції, може деградувати при змішаному навантаженні, і навпаки.

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

Ризики покладання на одне число

Розробник, який обирає мережу за максимальним заявленим TPS, наражається на кілька ризиків:

• Невідповідність реальному навантаженню: піковий TPS на простих переказах не передбачає продуктивності для застосунку зі складною логікою та інтенсивним доступом до стану.
• Сприйняття деградації як норми: якщо очікування ґрунтуються на піковому числі, будь-яке реальне уповільнення сприймається як аномалія, хоча воно може бути нормативним для стійкого режиму.
• Неправильне проєктування архітектури застосунку: розробник може не закладати обробку таймаутів, повторних відправлень та черг, вважаючи, що мережа «достатньо швидка».

Невизначеність

Продуктивність мережі в конкретний момент є емпіричною величиною, яка залежить від множини змінних: поточного складу транзакцій, поведінки валідаторів, стану мережі, навантаження на конкретні програми. Будь-яка статична оцінка продуктивності має термін придатності. Принципи й рамки, описані в цьому матеріалі, є стабільними; конкретні числа — ні.

Крім того, існує невизначеність у самій методології вимірювання: різні інструменти моніторингу можуть рахувати транзакції по-різному (наприклад, чи рахувати невдалі транзакції, чи рахувати внутрішні виклики як окремі транзакції). Без уніфікованої методології порівняння навіть в межах однієї мережі може бути некоректним.

Висновок і наступна перевірка

Що можна стверджувати на рівні принципу

• TPS — один із багатьох вимірників, який без контексту (специфікація транзакцій, тривалість, середовище) не несе інформативного значення.
• Реальна продуктивність мережі для користувача й розробника є багатовимірною: вона включає затримку, фінальність, дисперсію, дроп-рейт і залежить від профілю навантаження.
• Пікова продуктивність і стійка продуктивність — різні характеристики, і для практичних цілей важливіша друга.
• Публічні цифри продуктивності від команд протоколів відображають їхні інтереси й методології, які можуть не збігатися з інтересами розробників застосунків.
• Існують структурні компроміси між різними вимірниками продуктивності, і жодна мережа не може бути оптимальною за всіма параметрами одночасно.

Що потребує актуальних даних

• Конкретні значення стійкого TPS, затримки, перцентилів та дроп-рейту мережі Solana за поточного навантаження.
• Порівняння продуктивності за різних профілів транзакцій (прості перекази проти складних програмних викликів).
• Динаміка продуктивності з часом та залежність від кількості активних валідаторів.
• Результати незалежного бенчмаркінгу з відкритою методологією.

Наступний крок для читача

Щоб зрозуміти, як архітектурні рішення Solana впливають на описані тут вимірники продуктивності, рекомендуємо перейти до матеріалу про компроміси Solana між швидкістю, вартістю й децентралізацією. Якщо вам потрібне базове уявлення про архітектуру, перед цим варто ознайомитися з протоколом Solana простими й точними словами. Загальне уявлення про розділ доступне на сторінці «Під капотом Solana: протокол, клієнти й економіка».

Обмеження цього матеріалу: Стаття описує концептуальну рамку оцінки продуктивності й не містить поточних метрик мережі Solana. Вона не є інструкцією з бенчмаркінгу, не порівнює Solana з іншими мережами за конкретними числами й не розглядає питання безпеки, які висвітлені в окремому розділі «Безпека Solana: спокійно, конкретно, перевірено». Практичні продукти, що працюють на мережі, зібрані в розділі «Продукти Solana: що працює для людей».

Редакція солана.укр

Джерела для перевірки. Актуальні технічні деталі варто звіряти з первинними джерелами: документація Solana про обробку транзакцій.