Обмеження Bitcoin на рівні приблизно 7 транзакцій за секунду допомогло сформулювати проблему масштабованості блокчейнів. В іншому порівнянні пропускну здатність Visa оцінюють приблизно у 2 000 транзакцій за секунду. Цей розрив пояснює, чому протягом наступного десятиліття галузь розвивала швидший консенсус, паралельне виконання та ефективніше поширення даних мережею, а не вважала початкову архітектуру достатньою (огляд масштабованих блокчейнів).
Цей історичний контекст важливий, але типова відповідь на проблему досі надто поверхова. У презентаціях постачальники показують піковий TPS, тоді як робочим командам потрібно знати, чи надійно надходять депозити, чи стають розрахунки фінальними в межах вікна зобов'язань, чи створює перемикання між RPC дублікати та чи може фінансова команда звірити кожну зміну стану. Високопродуктивний блокчейн корисний лише тоді, коли його швидкість зберігається під реалістичним навантаженням і він належно поєднується з гаманцями, підписанням, відправленням у мережу, подіями та обліком.
Зміст
- Чому піковий TPS — неправильне запитання
- Чотири метрики, які справді визначають продуктивність
- Порівняння підходів до консенсусу та виконання
- Прихований зв'язок між пропускною здатністю, затримкою та фінальністю
- Як зіставити архітектуру з реальним навантаженням
- Операційні вимоги поза блокчейном
- Ризики, контроль і перевірки перед запуском
Чому піковий TPS — неправильне запитання
Піковий TPS — це лабораторний результат, а не SLA для робочого середовища. Тест може використовувати прості перекази, контрольоване обладнання, вигідне географічне розташування, порожні мемпули та відсутність конкурентного виконання смартконтрактів. У вашому застосунку є користувачі, повторні спроби, тиск комісій, зростання стану, розподіл валідаторів, політики гаманців та операційні винятки.
Історичне порівняння важливе з однієї причини: воно показує, чому лабораторний максимум не прогнозує поведінку в робочому середовищі. Використовуйте розрив між приблизно 7 TPS та 1 273 TPS як вихідну точку для відтворення навантаження, а не для ранжування постачальників. Дослідження Blockbench проводили в контрольованих умовах, тоді як платіжний оператор має перевіряти затримку включення на рівні p95 під час перевантаження, повторні спроби через різних RPC-провайдерів і конкурентний транзакційний трафік.
Вимірюйте навантаження, а не рекламне гасло
Визначайте продуктивність у чотирьох вимірах:
- Стабільна пропускна здатність: кількість транзакцій за секунду, яку система підтримує з репрезентативними даними, маршрутами контрактів, підписами та конкуренцією за ресурси.
- Затримка включення: час від відправлення до включення, представлений на рівнях p50, p95 та p99, а не як середнє значення.
- Фінальність розрахунку: час, після якого система обліку може вважати зміну стану безпечною.
- Масштабованість за умов змін: як погіршуються пропускна здатність, затримка та фінальність зі збільшенням кількості валідаторів, географічного розподілу, розміру стану та числа одночасних користувачів.
Попросіть постачальника відтворити ваше навантаження. Тест простого переказу не відображає виплату у беттінгу, платіж у стейблкоїнах із перевірками політик чи торгову транзакцію, що конкурує за порядок виконання. Він також майже нічого не говорить про вбудований гаманець, який має координувати підписання, керування nonce, повторні спроби відправлення в мережу, доставку подій та звірку операційного журналу.
Саме цей міст між консенсусом і продуктовими операціями є практичною точкою оцінювання. Швидше створення блоків допомагає лише тоді, коли запити гаманця надійно потрапляють у мережу, повторні відправлення не створюють дублікатів, події надходять у придатній до аудиту послідовності, а стан операційного журналу залишається узгодженим у разі збою.
Практичне правило: вважайте піковий TPS верхньою межею потужності. Критеріями вибору мають бути стабільна пропускна здатність на вашому навантаженні, затримка p95, фінальність і криві погіршення продуктивності.
Не обирайте рішення лише за заявленою швидкістю. Виберіть архітектуру, що відповідає навантаженню, а потім перевірте поведінку її консенсусу, виконання, гаманця, відправлення в мережу та обліку під тиском, наближеним до робочого. Продуктивність блокчейну важлива, але сама по собі вона не забезпечує роботу фінансового продукту.
Чотири метрики, які справді визначають продуктивність
Кожна метрика відповідає на окреме операційне запитання. Об'єднання їх в один показник швидкості приховує саме той сценарій збою, який найбільше впливає на клієнтів.
Пропускна здатність
Пропускна здатність — це кількість успішно оброблених релевантних транзакцій за секунду. Вимірюйте її як стабільний TPS протягом визначеного навантаження, фіксуючи тип транзакції, розмір даних, шлях виконання та паралельність. Мережа, яка короткочасно демонструє високий пік, але ставить у чергу звичайні робочі дії під навантаженням, не виконала вимогу.
Затримка
Затримка вимірює час, зазвичай у мілісекундах або секундах, від відправлення до включення. Розкладайте її на поширення транзакції, приймання до мемпулу, визначення порядку, створення блока та виконання. Показуйте p50 для типового користувача і p95 або p99 для хвоста розподілу, адже платіжний продукт може здаватися ненадійним, коли медіана швидка, але помітна частина операцій очікує надто довго.
Фінальність
Фінальність — це момент, коли транзакцію можна вважати остаточно виконаною відповідно до моделі консенсусу блокчейну. Вимірюйте її в мілісекундах або секундах від відправлення чи включення і зазначайте, чи є вона детермінованою або ймовірнісною. Ймовірнісного підтвердження може бути достатньо для деяких операцій із низьким ризиком, тоді як переміщення казначейських коштів та облік зобов'язань можуть вимагати суворішого правила розрахунку.
Масштабованість
Масштабованість описує, як поводяться інші метрики зі зростанням системи. Вимірюйте пропускну здатність, затримку та фінальність, збільшуючи кількість валідаторів, географічну відстань, розмір стану, складність транзакцій та паралельне навантаження. Дослідження консенсусу показують, чому це важливо. В одному емпіричному порівнянні пропускна здатність PBFT знизилася приблизно з 1 200 TPS за 4 вузлів до приблизно 218 TPS за 100 вузлів, тоді як PoW, PoS та DPoS зі збільшенням кількості вузлів залишалися порівняно стабільнішими (дослідження консенсусу та шардингу).
| Метрика | Одиниця вимірювання | Що вона насправді вимірює |
|---|---|---|
| Пропускна здатність | Стабільна кількість транзакцій за секунду | Потужність для завершеного навантаження |
| Затримка | Мілісекунди або секунди за процентилями | Час до включення та видимої для користувача відповіді |
| Фінальність | Мілісекунди або секунди до детермінованого чи прийнятного розрахунку | Час, після якого облік може безпечно визнати результат |
| Масштабованість | Криві метрик зі зростанням вузлів, стану та навантаження | Чи зберігається продуктивність під час зростання робочої системи |
Між цими вимірами є суперечності. Більші блоки можуть збільшити номінальну пропускну здатність, але довше поширюються мережею. Коротші інтервали створення блоків можуть скоротити очікування, але залишають валідаторам менше часу на отримання, перевірку даних і голосування. Швидше виконання не компенсує повільне або невизначене правило розрахунку.
SLA постачальника має називати навантаження, процентиль, умову фінальності, середовище валідаторів і профіль перевантаження. Без цих параметрів слово «швидкий» є продуктовим прикметником, а не інженерним зобов'язанням.
Порівняння підходів до консенсусу та виконання
Консенсус визначає правила розрахунку, але продуктивність у робочому середовищі також залежить від будови мемпулу, паралельності виконання, поведінки секвенсора, доступності даних і ринку комісій. Ці рішення визначають, чи може вбудований гаманець надійно відправити транзакцію, чи отримають сервіси відправлення передбачувані сигнали підтвердження та коли операційний журнал може зафіксувати операцію.
Консенсус найдовшого ланцюга у стилі Накамото, пов'язаний із Bitcoin та Ethereum до переходу на Proof of Stake, підтримує відкриту участь і ймовірнісний розрахунок. Для цих мереж показник близько 7 TPS відображає ціну відкритої участі та ймовірнісного розрахунку, який подовжує вікно фінальності, перш ніж операційний журнал зможе зафіксувати результат. Компроміс очевидний: широка участь і нейтральність супроводжуються повільнішим фактичним розрахунком та ризиком реорганізацій.
Механізми BFT-фінальності, зокрема варіанти Tendermint і HotStuff, координують набір валідаторів для швидшого досягнення згоди. Вони можуть забезпечити детермінований або майже детермінований розрахунок, але комунікація між валідаторами та вимоги до кворуму збільшують мережеві й обчислювальні витрати зі зростанням набору. Наведені раніше вимірювання PBFT показують, як кількість валідаторів може впливати на пропускну здатність, тому припущення постачальника щодо кількості вузлів потрібно перевіряти.
Мемпули на основі DAG, зокрема Narwhal, Bullshark та AptosDAG, відокремлюють поширення даних від визначення порядку. Це може зменшити вузькі місця між надходженням транзакцій та їх упорядкуванням консенсусом. Водночас складність реалізації зростає, а блокчейн усе одно потребує визначеної моделі фінальності, перш ніж баланси гаманців або фінансові операційні журнали зможуть визнати результат остаточним.
Оптимістичні та ZK-ролапи переносять виконання з базового рівня, використовуючи його для розрахунку, розгляду оскаржень або перевірки доказів. Вони можуть збільшити потужність застосунку, але оцінювання має враховувати залежність від секвенсора, час виведення коштів, доступність даних, вартість доказів та ризик MEV. Швидший шлях виконання не гарантує негайного розрахунку або надійного відправлення в мережу.
Опубліковані показники демонструють, чому контекст тесту важливий. В одному порівнянні для Solana вказано близько 65 000 TPS у заявленому тесті основної мережі та фінальність приблизно 400 мілісекунд. В окремому галузевому порівняльному огляді наведено середні показники близько 1 053,7 TPS для Solana, 854,1 для Sui та 378,3 для BNB Chain (галузевий порівняльний огляд). Ці вимірювання описують різні умови, тому пікова спроможність не може замінити показник стабільної потужності в робочому середовищі.
Ethereum L1, Arbitrum та Optimism можуть відповідати різним вимогам до безпеки, ліквідності, компонованості й розрахунку. Середовище з нижчою пропускною здатністю може бути обґрунтованим вибором, якщо децентралізація, доступ до екосистеми або розрахунок на базовому рівні важливіші за миттєву потужність виконання. Потрібно визначити, яка комбінація консенсусу, мемпулу, секвенсора, середовища виконання та рівня розрахунку відповідає ризикам застосунку й вимогам до операційного журналу.
Прихований зв'язок між пропускною здатністю, затримкою та фінальністю
Блокчейн може бути швидким в одному вимірі та повільним в іншому. Час слота 400 мілісекунд не означає, що транзакція досягає детермінованої фінальності за 400 мілісекунд, адже мережі можуть знадобитися додаткові блоки, голоси чи умови розрахунку, перш ніж залежні системи зможуть покладатися на результат.
Першим обмеженням є поширення даних. Кожен блок має дістатися валідаторів, а наближення обсягу даних до пропускної здатності мережі збільшує час, потрібний для включення та голосування. Дослідження бездозвільного консенсусу прямо описує цей зв'язок: затримки поширення блоків знижують пропускну здатність, а вища швидкість передавання даних збільшує час очікування (дослідження бездозвільного консенсусу).
Аналізуйте хвіст розподілу, а не середнє
Перевантаження мемпулу часто збільшує затримку ще до того, як блокчейн досягне видимої межі пропускної здатності. Користувачі надсилають транзакції, комісії змінюються, черги впорядкування подовжуються, а логіка заміни чи повторних спроб створює додатковий тиск. Система може виглядати здоровою за медіаною, тоді як показники p95 і p99 стають неприйнятними для виведень, результатів гри або авторизації платежів.
Відстежуйте принаймні такі сигнали:
- Затримка включення p50: звичайний шлях типового запиту.
- Затримка включення p95: досвід, що виявляє регулярне перевантаження та коливання інфраструктури.
- Затримка включення p99: операційний хвіст, що спричиняє звернення до підтримки та ручне втручання.
- Затримка фінальності: час від включення до порога розрахунку, який використовує ваш продукт.
- Глибина реорганізації: кількість замінених блоків або змін стану, які має відкотити залежна логіка.
Глибина реорганізації — прихована змінна. Транзакція з імовірнісним підтвердженням може швидко відображатися в інтерфейсі гаманця, але фінансова система має враховувати можливість зміни спостережуваного стану. Через це фактичний розрахунковий шлях повільніший, ніж підказує перше підтвердження.
Для платіжних і торгових команд правильний тест має включати контрольоване перевантаження, географічний розподіл, реалістичний стан, повторні спроби та конкурентні типи транзакцій. Дослідження тестування за конкретним навантаженням рекомендує відтворювані сценарії та кількісні метрики замість нерозрізнених маркетингових заяв (рекомендації щодо тестування). Практичне запитання полягає не в тому, чи здатен блокчейн працювати швидко в спокійному тесті. Важливо, чи може весь технологічний стек зберегти прийнятну затримку хвоста та безпечну фінальність під час завантаження мережі.
Ширше застосування цих принципів до потоків зі стейблкоїнами описано у матеріалі про інфраструктуру платежів у стейблкоїнах.
Як зіставити архітектуру з реальним навантаженням
Розгляньмо iGaming-оператора, який приймає депозити у стейблкоїнах та здійснює виплати. Видимою продуктовою подією є ставка, але інфраструктурний шлях охоплює гаманець гравця, сервіс відправлення в мережу, підтвердження блокчейну, логіку розрахунку та оновлення внутрішнього балансу.
Гравець надсилає транзакцію з вбудованого гаманця. Застосунок підписує її відповідно до політики гаманця, надсилає через рівень відправлення в мережу й отримує подію, коли мережа її помічає. Оператор не повинен вважати «прийнято до відправлення» рівнозначним «кошти остаточно зараховано». Потрібні окремі стани для спостереження, включення, достатнього підтвердження та фінальності відповідно до політики ризику.
Одна ставка — кілька інфраструктурних рішень
Вибір блокчейну впливає на досвід гравців, ліквідність, поведінку комісій і впевненість у розрахунку. Команда може використати один блокчейн для гаманців, які поповнюють гравці, та інший для казначейських розрахунків, якщо перший дає користувачам кращий доступ, а другий — потрібні властивості інституційного розрахунку.
Резервування відправлення в мережу важливіше за піковий показник, коли гравець очікує депозит або виплату. Сервіс має керувати кількома RPC-маршрутами, контролювати їхній стан, зберігати ідентичність транзакції та не створювати другу бізнес-операцію лише через те, що відповідь на перше відправлення не надійшла вчасно.
Підтвердження розрахунку визначає, коли оператор обліковує зобов'язання, дозволяє виведення чи оновлює доступний баланс. Модель фінальності блокчейну має відповідати обліковій політиці оператора, а не типовому екрану гаманця.
Вбудовані MPC-гаманці визначають, як контролюються ключі гравців і казначейства. Окремі гаманці для гравця або агента можуть розділити баланси й дозволи, а контрольований клієнтом Co-Signer — зберегти операційне затвердження поза межами одного сервісу.
Проєктуйте автомат станів явно
Застосунок має моделювати кожну транзакцію як зміну стану з журналом подій:
- Подано: бізнес-операція створює запит на підписану транзакцію.
- Відправлено: мережевий шлюз приймає транзакцію для поширення.
- Помічено або включено: блокчейн повідомляє про транзакцію, а згодом додає її до блока.
- Розраховано: виконано політику підтвердження або правило детермінованої фінальності.
- Звірено: операційний журнал зіставляє зовнішню подію з внутрішнім балансом і зобов'язанням.
Це розділення запобігає поширеному збою. Якщо інтерфейс гаманця оновлюється під час подання, а операційний журнал — лише після розрахунку, продуктова, операційна та фінансова команди можуть бачити різні баланси одного гравця. Події WebSocket у реальному часі допомагають доставляти відомості про депозити, підтвердження, виведення та результати політик, але джерелом достовірних даних про бізнес-стан залишається операційний журнал.
Отже, архітектуру визначає навантаження. Чистий TPS впливає на планування потужності, тоді як надійність відправлення в мережу, фінальність, політика підписання та звірка визначають, чи отримають користувачі й фінансова команда надійний продукт.
Операційні вимоги поза блокчейном
Швидкий блокчейн не керує вашими ключами, не запобігає дублюванню бізнес-операцій і не звіряє зовнішній стан із внутрішнім обліком. Ці засоби контролю належать рівню застосунку та розрахунку.
Порогове MPC-підписання дає кворуму часток ключа змогу авторизувати транзакцію без відновлення повного приватного ключа на одному пристрої. У робочих операціях сесії підписання мають зберігати ідентифікатор сесії, ідентифікатори учасників і затверджень, хеш повідомлення та хеш остаточного підпису, щоб аудитори й фахівці з реагування на інциденти могли відтворити події (операційні рекомендації щодо MPC у Web3).
API-ключі з обмеженою сферою дії та рольові дозволи мають визначати, який сервіс може створювати гаманці, запитувати підписи, відправляти транзакції в мережу або ініціювати виплати. Для гарячого операційного шляху потрібні межі політик, ліміти витрат, правила затвердження та контрольований клієнтом Co-Signer, а не один необмежений обліковий запис.
Зробіть повторні спроби безпечними
Високонавантажені API часто використовують підписані часові мітки та nonce, щоб відхиляти застарілі чи повторно відтворені запити. Вікно актуальності часто становить від 30 до 120 секунд, а один nonce не повинен прийматися двічі в межах цього вікна (рекомендації щодо захисту від повторного відтворення).
Платіжним кінцевим точкам також потрібні ключі ідемпотентності. Якщо RPC-маршрут перестав відповідати після приймання транзакції, повторна спроба має повернути початковий збережений результат, а не виконати виплату ще раз. Одна документована платформа використовує 30-хвилинне вікно кешування для ідемпотентних повторних спроб, демонструючи потребу чітко визначити строк зберігання, а не залишати його невизначеним (документація з ідемпотентності).
| Ризик навантаження | Потрібний засіб контролю |
|---|---|
| Компрометація ключа або надмірні повноваження | Порогове MPC-підписання, ключі з обмеженою сферою, затвердження політик і ліміти витрат для кожного ключа |
| Завершення часу очікування RPC та перемикання | Ключі ідемпотентності, відстеження ідентичності транзакції та виявлення дублікатів |
| Повторне відтворення запитів | Підписані часові мітки, nonce, перевірка актуальності та журнали повторного відтворення |
| Перевантажений ринок комісій | Оцінювання gas, правила заміни, черги застряглих транзакцій та обробка безрезультатних повідомлень |
| Невизначений розрахунок | Політики підтвердження, обробка реорганізацій і подвійний стан журналу |
| Аудит і фінансова перевірка | Незмінні записи з послідовним додаванням, журнали підписаних транзакцій та звіти звірки |
| Операційні прогалини | Події WebSocket і метрики глибини мемпулу, підтверджень, збоїв та реорганізацій |
Операційний журнал із послідовним додаванням записів перетворює активність у блокчейні на простежувані зміни внутрішнього стану. Рекомендації щодо журналів передбачають криптографічно засвідчені записи з послідовним додаванням, тоді як інфраструктура платежів у стейблкоїнах зазвичай поєднує подвійний запис із двочасовою історією, щоб зовнішні події можна було звірити з внутрішнім обліком (документація операційного журналу з послідовним додаванням).
BroLabel пропонує один із варіантів реалізації цього операційного рівня, поєднуючи вбудовані MPC-гаманці, відправлення в мережі, події WebSocket, операційний журнал із послідовним додаванням та API розрахунків у підтримуваних мережах. Важливе не ім'я постачальника. Ці засоби контролю потрібно проєктувати разом незалежно від того, чи заявляє базова мережа 1 000 TPS або 100 000 TPS.
Щоб порівняти архітектуру зберігання активів і межі підписання, перегляньте матеріал про зберігання цифрових активів.
Ризики, контроль і перевірки перед запуском
Рішення про вибір постачальника має спиратися на докази, а не завершуватися слайдом із тестовими показниками. Згрупуйте ризики за консенсусом, застосунком та операціями, а потім вимагайте засіб контролю і спостережуваний сигнал для кожного.
Ризики на рівні консенсусу охоплюють глибину реорганізації, невизначену фінальність та концентрацію валідаторів. Вимагайте задокументованих припущень про фінальність, виміряної історії реорганізацій і перевірки розподілу валідаторів. Інфраструктурні ризики охоплюють відмови RPC, поведінку мемпулу, затримки поширення та збої під час перевантаження. Перевірте перемикання з контролем затримки та переконайтеся, що повторні спроби зберігають ідентичність транзакції.
Операційні ризики охоплюють зберігання ключів, помилки авторизації, повторні відправлення й прогалини у звірці. Вимагайте підтвердження часток MPC-ключа, дозволів з обмеженою сферою, захищених від повторного відтворення nonce, записів ідемпотентності та процесу підтвердження у двох журналах. Структурований набір критеріїв вибору системи управління ризиками допоможе команді задокументувати відповідальність, допустимий ризик, докази й ескалацію до запуску.
Вимагайте спостережуваність із першого дня
Відповідальний покупець має бачити:
- Пропускну здатність навантаження: посекундні результати для реального набору транзакцій.
- Затримку хвоста: затримку підтвердження p95 і p99, а не лише середні показники.
- Стан консенсусу: сповіщення про реорганізації, затримки фінальності та інциденти, пов'язані з валідаторами.
- Стан підписання: відмови підписувачів, заборони політик і доступний бюджет помилок.
- Узгодженість обліку: лічильники розбіжностей між розрахунком та відправленням і невирішені записи операційного журналу.
До запуску визначте, чи потрібне продукту виконання в одному блокчейні, відправлення в кілька мереж або розрахунок через обгорнуті активи. Нехай рішення визначають докази. Якщо тест перемикання виявляє ризик дублювання, виправте ідемпотентність до збільшення потужності. Якщо фінальність не відповідає обліку зобов'язань, змініть політику розрахунку або архітектуру. Якщо рівень гаманця не може надати придатні до аудиту події підписання й операційного журналу, швидший блокчейн не зробить систему готовою до роботи.
Цільовий огляд архітектури підписання наведено в матеріалі про MPC-гаманці.
BroLabel надає API-first інфраструктуру для вбудованих MPC-гаманців, відправлення в мережі, розрахункових процесів, подій WebSocket та операційного журналу з послідовним додаванням. Відвідайте BroLabel, щоб оцінити модульний шлях від тестування навантаження й інтеграції в пісочниці до контрольованих операцій у робочому режимі.
