Розробка на Cosmos SDK: де прототип не витримує навантаження
Прототип мережі застосунку зазвичай збирається на кількох валідаторах і синтетичному потоці транзакцій. У такому режимі Cosmos SDK дає рівні блоки й передбачуване підтвердження — і створює відчуття, що до основної мережі залишається змінити конфігурацію.
Коли кількість валідаторів зростає, а потік стає реальним, поведінка змінюється якісно, а не кількісно.
Перше вузьке місце — консенсус. Раунд потребує обміну пропозиціями та голосами між усіма учасниками, тому зі зростанням набору валідаторів час раунду зростає, а не залишається сталим.
Блоки заповнюються до межі, черга транзакцій не розсмоктується між блоками, затримка підтвердження йде з секунд у десятки секунд, а комісії стають непередбачуваними для користувача.
Друге — відсутність ізоляції відмов. Важкий обробник в одному модулі займає час блоку цілком: решта транзакцій чекає, стан зростає, відстаючі вузли не встигають наздоганяти.
Розсинхронізація версій у частини валідаторів або помилка в логіці модуля зупиняють виробництво блоків — простій мережі потребує узгодженого перезапуску та ручних дій операторів.
Третє — експлуатаційні межі: зростання стану, час синхронізації нового вузла, відсутність плану оновлення без зупинки. Проявляється це вже після запуску, коли конфігурацію зафіксовано. Розбираємо, як це закривається на етапі проєктування.
Що дає власна мережа: передбачуване навантаження та ізоляція відмов
Мережа застосунку на Cosmos SDK — це окремий блокчейн під одне завдання, а не секція в спільному. Ресурси, правила й ритм оновлень налаштовуються під конкретний сценарій, тому пік в одному сервісі не зачіпає сусідні. Нижче — чотири ефекти, які видно в експлуатації, а не в презентації.
Ізоляція відмов
Падіння вузла або перевантаження одного сервісу зупиняє лише його: решта мережі продовжує приймати транзакції, а відновлення відбувається заміною вузла з готового набору.
Ми розводимо критичні контури за різними наборами валідаторів, тому клас відмов «одне перевантаження — весь продукт» зникає.
Передбачувана пропускна здатність
Місце в блоці не ділиться з чужими застосунками, тому затримка підтвердження розраховується заздалегідь. Ми задаємо ліміт блоку та вартість операцій під профіль навантаження, вимірюємо частку відхилених транзакцій на піку й утримуємо її в узгодженому порозі.
Незалежні валідатори
Підтвердження блоків розподілено між незалежними валідаторами: немає єдиної точки, яка може зупинити мережу або непомітно переписати історію. Поріг згоди та склад набору фіксуються в конфігурації — це ж стає основою для аудиту й вимог регулятора.
Час оновлення мережі
Оновлення логіки проходить через управлінську пропозицію і застосовується на узгодженому блоці: термін вимірюється днями, а не кварталами, і не потребує зупинки мережі. Зворотний сценарій також описано заздалегідь — повернення до попереднього стану за перевіреною процедурою.
Варіанти архітектури мережі: ізольована, мережа застосунку, спільна
Архітектура задає, хто платить за навантаження, як оновлюється логіка і наскільки відкриті ваші активи. Три варіанти нижче — не абстракція, а реальні розвилки при запуску мережі на актуальній гілці Cosmos SDK.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ізольована мережа | Закритий контур: облік активів і розрахунки в межах одного продукту | Зовнішні смарт-контракти недоступні, інтеграції — лише через власний шлюз |
| Мережа застосунку | Потрібні власна логіка, комісії та порядок включення транзакцій | Валідатори, оновлення й моніторинг залишаються на вашому боці |
| Спільна мережа | Швидкий старт, ліквідність, готові інструменти | Транзакції ділять спільну чергу, логіка обмежена можливостями смарт-контрактів |
Критерії вибору
Вважаємо три величини: пікове навантаження, частоту змін правил і потребу в зовнішніх смарт-контрактах. Якщо правила змінюються щомісяця, а валідаторів ви не контролюєте, спільна мережа економить місяці на старті — ціною керування комісіями та черговістю транзакцій.
Що не варто переносити у власну мережу
Персональні дані, ключі підпису та важкі обчислення залишаються поза блокчейном. У спільний стан переходить лише те, що потребує узгодження між учасниками: права, баланси, підсумки розрахунків. Решту дешевше й безпечніше тримати у звичайній інфраструктурі.
Етапи розробки: від схеми мережі до передачі в експлуатацію
Розробка appchain — це не «написати модулі», а послідовність етапів, де результат кожного перевіряємо до переходу до наступного. Нижче — порядок робіт, за яким іде наша команда: від розбору вимог до передачі мережі в експлуатацію разом із навчанням вашої команди.
Порядок робіт
- Розбір вимог. Фіксуємо, які операції справді мають жити в блокчейні, хто виступає валідатором, які дані йдуть у зовнішні системи. На виході — перелік модулів і критерії приймання, за якими потім здаємо мережу.
- Схема мережі. Проєктуємо топологію та ролі: вузли валідаторів, архівні й публічні вузли, доступи, резервне копіювання стану. Схему узгоджуємо до першого рядка коду — змінювати її пізніше помітно дорожче.
- Налаштування модулів. Збираємо застосунок із готових модулів і пишемо власні: параметри управління, права на операції, логіка комісій. Усе, що може змінюватися, виносимо в управління, а не в код.
- Складання тестової мережі. Піднімаємо локальний контур для швидких ітерацій і публічний тестнет, де сценарії проганяються на реальних валідаторах. Помилки конфігурації ловимо тут, а не на продуктивній мережі.
- Навантажувальна перевірка. Проганяємо профіль транзакцій, близький до очікуваного, і дивимося поведінку на піку: час включення блоку, зростання стану, відставання вузлів і відновлення після перезапуску.
- Виведення в робочий режим і передача. Запускаємо поетапно — від обмеженого кола валідаторів до повного складу. Передаємо регламенти оновлення й відновлення, налаштовуємо алерти й навчаємо вашу команду.
Що залишається замовнику: конфігурації, документація, регламенти
Комплект на виході — це не архів із вихідними кодами, а набір артефактів, за яким ваша команда далі працює без нас. Ми передаємо їх разом із розбором: кожне рішення проговорюємо на дзвінку й фіксуємо причину, чому параметр виставлено саме так.
- Конфігурації мережі — стартові файли, параметри вузлів і значення, змінені щодо типових, із поясненням, що станеться при їх редагуванні.
- Схема мережі — топологія валідаторів, повних і публічних вузлів, точки підключення, зони відмови та порядок відновлення при втраті сегмента.
- Ролі та ключі — реєстр: який ключ кому належить, де зберігається, хто має право підпису та як проходить ротація.
- Політики доступу — розмежування прав за принципом мінімально необхідного, розділення ключів адміністратора мережі та ключів застосунку, апаратне зберігання критичних ключів.
- Регламент оновлень — шлях зміни від тестової мережі до основної: хто готує, хто голосує, вікно робіт, критерії відкату до попереднього стану.
- Інструкції для чергової команди — що моніторити, які пороги вважати тривожними, що робити при зупинці блоків, розсинхронізації вузла й падінні сервісу.
- Документація інтеграцій — опис зовнішніх інтерфейсів, форматів запитів і обмежень за навантаженням.
Ці артефакти — критерій приймання: якщо за ними черговий інженер може підняти мережу й провести оновлення без нас, роботу здано. Перше планове оновлення проходимо разом із вашою командою, далі — за регламентом.
Кейс: виведення мережі застосунку в робочий режим за дві ітерації
Оператор мережі застосунків прийшов із робочим прототипом на Cosmos SDK: на тестовому контурі все сходилося, але за реального потоку транзакції накопичувалися в черзі, а валідатори розходилися за висотою блоків.
Завдання звучало так — утримати час відгуку, знизити частку відхилених транзакцій і зробити мережу стійкою до відмови окремого вузла. Нижче — заміри до й після та те, що довелося переробити по ходу.
Що показали заміри до й після
На вході час підтвердження транзакції на піку сягав 12 секунд, відхилялося 4–6% потоку, а зупинка одного валідатора затримувала обробку на хвилини.
Ми розвели логіку застосунку та шар узгодження стану, додали пріоритети для термінових операцій і обмежили споживання ресурсів на одну транзакцію.
Після повторного заміру час підтвердження скоротився втричі, частка відхилених упала нижче 0,5%, а виведення вузла з активного набору перестало впливати на обробку запитів — перебудова набору валідаторів займає секунди замість хвилин.
Що переробили по ходу
Перша ітерація спиралася на загальну схему зберігання стану: при зростанні кількості акаунтів запис почав гальмувати читання, і це проявлялося саме в пікові години. Ми переробили модель ключів, рознесли гарячі й архівні дані та додали індекси під найчастіші запити. Перенесення стану пройшли покроково — без зупинки мережі та втрати історії операцій.
Що робити, якщо частина логіки вже працює в чужій мережі?
Коротка відповідь: переносити всю логіку цілком потрібно рідко. Розвилка залежить від того, наскільки широкий у вашої логіки інтерфейс із чужою мережею — якщо це один виклик на вході, переноситься він, а не весь продукт.
Нижче три сценарії, між якими реально обирають на старті, і що кожен означає для сумісності модулів і даних.
Сумісність перевіряємо за двома шарами. Модульний: чи збігаються інтерфейси між модулями, версії бібліотек у дереві залежностей Cosmos SDK і порядок ініціалізації при старті мережі.
Шар даних: схема зберігання стану, ключі, формат серіалізації та генезис-файл, з якого піднімається новий блокчейн. Розбіжність тут не ламає збірку — воно дає інший стан після запуску й спливає вже на звірці.
| Сценарій | Коли підходить | Обмеження |
|---|---|---|
| Залишити як є | Логіка працює, потрібен лише власний зовнішній контур: валідатори, канал зв’язку, правила доступу | Правила оновлень і збори чужої мережі поза вашим контролем |
| Гібридна схема | Частина модулів перевірена й стабільна, частина потребує власних правил | Два стани потрібно синхронізувати, потрібен шар підтвердження між мережами |
| Повний перенос | Потрібні власні правила консенсусу та незалежний запуск мережі | Переписуються всі модулі плюс міграція накопиченого стану |
На практиці частіше йдемо гібридною схемою: переносимо модуль за модулем, кожен проганяємо на тестовій мережі та звіряємо поведінку з початковою. Стару мережу тримаємо робочою до підтвердження — це і є точка відкату, якщо звірка покаже розбіжність стану.
Технічні питання, які ставлять перед запуском мережі
Перед запуском основної мережі технічні сумніви повторюються: чи витримає вона пікове навантаження, чи можна доопрацювати логіку після старту, як захищено доступ до ключів. Відповідаємо коротко — деталі розбираємо на технічній сесії за вашою архітектурою.
Як мережа поводитиметься при зростанні навантаження?
Масштабування йде двома важелями: параметрами блоку — лімітом газу, розміром і темпом виробництва блоків — і додаванням валідаторів із розподілом трафіку.
Ми заздалегідь проганяємо модель вашої активності та фіксуємо запас до деградації, а моніторинг показує вузьке місце раніше, ніж його помітять користувачі.
Чи можна додати модуль або змінити правила після запуску?
Так. Логіка застосунку на Cosmos SDK збирається з модулів, і новий модуль підключається плановим оновленням: вузли узгоджено переходять на нову версію на заданій висоті блоку, накопичений стан зберігається.
Правила змінюються через управління — параметри набирають чинності за результатами голосування, а не редагуванням сервера вручну.
Де зберігаються ключі та як відновлюється доступ?
Ключі валідатора й казначейства тримаємо в ізольованих сховищах апаратного типу, підпис збирається за схемою з кількома підтверджувальними.
Відновлення побудовано на розділенні секрету між відповідальними: втрата одного носія не блокує доступ, порядок дій зафіксовано в регламенті.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб оцінка задачі спиралася на факти, а не на здогадки, нам потрібен контекст щодо мережі та її сценарію. Надішліть вхідні дані у вільній формі — розробка на Cosmos SDK рідко починається з чистого аркуша, і вже зібрані напрацювання помітно скорочують шлях до робочого прототипу.
- Мета мережі та сценарій: які операції фіксуються в блокчейні, хто учасники, що має зберігатися в стані.
- Логіка модулів і токеноміка: випуск і розподіл токена, комісії, права адміністратора, порядок оновлення параметрів мережі.
- Навантаження й топологія: скільки вузлів і валідаторів очікується, вимоги до відмовостійкості, чи потрібна ізоляція контуру.
- Інтеграції: гаманці, біржові та платіжні сервіси, міжмережеві пересилання, зовнішні інтерфейси й аналітика.
- Поточні напрацювання: репозиторій, прототип, тестова мережа, схеми даних, результати попередніх перевірок.
- Обмеження та критерії готовності: строки, регуляторні вимоги, доступи до інфраструктури, хто з боку замовника ухвалює рішення щодо продукту.
Зі свого боку повернемося з планом робіт за етапами — прототип, складання модулів, запуск тестової мережі, підготовка до основної, — складом команди та розподілом ролей: хто веде модулі, хто інфраструктуру й реліз. Зазначимо строки й точки, де потрібне ваше рішення, щоб проєкт не стояв.
Опишіть задачу — повернемося з оцінкою та планом робіт.
