Мультичейн гаманець: де ламається логіка при зростанні мереж
Мультичейн гаманець ламається не на першій мережі, а на третій-четвертій. Поки підтримується один ланцюжок, логіка підпису, обліку балансів і відстеження транзакцій живе в одному місці й працює передбачувано.
Щойно додаються Ethereum, BSC, Polygon, Solana і TON, кожна мережа приносить свої правила: різний формат адрес, свою модель комісій, свій момент фінальності транзакції. І тоді починають спливати збої, які на тестах в одній мережі просто не відтворюються.
Перший і найпомітніший — розсинхрон балансів. Гаманець показує залишок по одній мережі, а списання проходить по іншій; після відправки токенів інтерфейс ще якийсь час тримає стару суму, бо оновлення по мережах надходить з різною затримкою.
Користувач бачить «неправильний» баланс і або повторює операцію, або втрачає довіру до застосунку. Причина — не одна спільна шина даних, а розрізнені запити до кожної мережі без єдиної точки узгодження стану.
Другий клас відмов — завислі транзакції. У мережах з різним навантаженням комісія, адекватна для одного ланцюжка, виявляється недостатньою для іншого, і операція надовго застрягає в очікуванні.
Без коректної обробки статусів такі транзакції не замінюються і не скасовуються, а просто висять — і користувач не розуміє, списалися кошти чи ні.
Третій — помилки підпису. Різні мережі вимагають різного формату підпису і різної схеми виведення ключів, і одна помилка в цьому шарі призводить до того, що транзакція відхиляється мережею або підписується не тим ключем. Нижче розбираємо, як ці збої закриваються на рівні архітектури, а не точковими правками.
Що дає єдина архітектура мультичейн гаманця
Єдина архітектура гаманця будується навколо одного шару підпису та одного шару обліку стану, а відмінності мереж виносяться в адаптери.
Ethereum, BSC, Polygon, Solana і TON працюють через різні моделі акаунтів і формати підпису, але клієнт бачить один баланс, одну історію та один сценарій надсилання.
Це і є головний вимірюваний ефект: нова мережа підключається адаптером, а не переписуванням ядра — термін додавання скорочується з тижнів до днів, а логіка підтверджень, повторних спроб і відображення комісій залишається спільною.
Другий ефект — частка успішних транзакцій. Коли невірний nonce, застаріла ціна газу або відхилений вузол обробляються в одному місці, а не на кожному екрані по-своєму, користувач отримує зрозумілу причину відмови та коректний повтор замість «транзакція не пройшла».
На практиці це підвищує частку доведених до підтвердження операцій і знижує потік звернень до підтримки щодо типових збоїв.
Третій — час відновлення після збою вузла або провайдера.
Адаптери ізольовані, тому відмова одного постачальника даних не валить інші мережі: трафік перемикається на резервне джерело, стан підтягується з локального кешу, а черга непідтверджених операцій дограється після повернення зв'язку. Клас відмов звужується з «гаманець не працює» до «одна мережа тимчасово недоступна».
Така архітектура окупається не сама по собі, а на горизонті: кожна наступна мережа і кожна нова функція лягають у готові шари, а не тягнуть за собою перезбирання продукту.
Підходи до реалізації: вбудовані модулі, зовнішні сервіси, гібрид
Коли застосунок підтримує Ethereum, BSC, Polygon, Solana і TON одночасно, ключовий вибір — де живе логіка підпису транзакцій і робота з мережами. Від цього залежать терміни запуску, контроль над ключами і те, як поводитиметься гаманець при додаванні шостої-сьомої мережі. Розберемо три схеми, між якими реально обирають на старті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудовані модулі | Потрібен повний контроль ключів і передбачувана робота офлайн | Кожна нова мережа — окрема робота з інтеграції, зростання кількості мереж сповільнює релізи |
| Зовнішні сервіси | Швидкий запуск, підтримка багатьох мереж «з коробки» | Ключі та підпис проходять через чужу інфраструктуру, залежність від чужого аптайму |
| Гібридна схема | Власний контур для ключів + зовнішні вузли для читання мережі | Складніша архітектура, потрібна акуратна синхронізація стану |
Вбудовані модулі дають максимальний контроль: приватні ключі не залишають пристрій, підпис обчислюється локально, а поведінка гаманця не залежить від сторонніх сервісів.
Ціна — кожна мережа потребує своєї логіки роботи з адресами, комісіями та форматами транзакцій, тому при зростанні кількості мереж терміни додавання чергової зростають нелінійно.
Зовнішні сервіси знімають це навантаження: підключення нової мережі часто зводиться до налаштування, а не до розробки. Але контроль ключів розмивається — частина операцій іде через чужий контур, і будь-який збій на боці сервісу стає збоєм гаманця.
Гібрид — компроміс, який найчастіше і обирають: ключі та підпис залишаються в захищеному контурі застосунку, а читання балансів і надсилання транзакцій ідуть через зовнішні вузли. Так зберігається контроль над ключами, а додавання мережі не перетворюється на окремий проєкт.
Етапи впровадження: від аудиту поточної схеми до передачі регламентів
Роботу починаємо з аудиту поточної схеми: дивимося, як зараз зберігаються ключі, хто і як ініціює підпис, які мережі вже підключені та де розходяться баланси.
На цьому етапі фіксуємо ризики — від одного спільного ключа на всі мережі до відсутності журналу операцій — і тільки після цього проєктуємо цільову архітектуру мультичейн гаманця.
- Аудит схеми та інвентаризація активів. Зводимо список мереж (Ethereum, BSC, Polygon, Solana, TON), типів адрес і поточних сховищ ключів. На виході — карта: де активи, хто має доступ, які операції йдуть повз гаманець.
- Проєктування моделі ключів і доступів. Визначаємо, які мережі працюють на спільній seed-фразі, які потребують окремої, як розділяються ролі оператора й адміністратора. Розкладаємо, що йде в захищене сховище, а що залишається в гарячому контурі.
- Налаштування підпису транзакцій. Збираємо підпис під кожну мережу з урахуванням її формату: різні схеми адресації, різні поля комісії, різні вимоги до nonce. Перевіряємо, що підпис формується локально і приватний ключ не залишає захищений контур.
- Перевірка транзакцій на тестових мережах. Проганяємо повний цикл — збірка, підпис, відправлення, підтвердження — на кожному блокчейні окремо. Окремо перевіряємо сценарії збою: відхилена транзакція, зависла в мемпулі, нестача коштів на комісію.
- Регламенти експлуатації. Описуємо порядок додавання нової мережі, ротації ключів, відновлення доступу та реакції на інцидент. Регламент має читатися черговим інженером без додаткових пояснень.
- Передача документації та навчання команди. Віддаємо схеми архітектури, інструкції з операцій, чек-листи перевірок. Проводимо розбір на живих сценаріях, щоб команда замовника могла супроводжувати гаманець самостійно.
Кожен етап закривається перевіркою — без неї не переходимо до наступного. Так на виході виходить не набір скриптів, а працююча система з зрозумілими точками контролю та передбачуваною поведінкою при збої.
Політики доступу та управління ключами в мультичейн гаманці
Управління ключами — та частина гаманця, де помилка в конфігурації коштує найдорожче: витік одного seed-файлу обнуляє весь баланс за всіма мережами одразу.
Тому ми віддаємо замовнику не «працюючий застосунок», а комплект артефактів, за якими команда може безпечно експлуатувати та розвивати продукт без нас.
- Схема зберігання ключів — де живе приватний ключ (захищене сховище пристрою, апаратний модуль, серверне сховище з шифруванням), як розділені гарячий і холодний контури, що відбувається при компрометації пристрою.
- Політики доступу — матриця ролей: хто підписує транзакції, хто змінює ліміти, хто лише переглядає баланс; правила підтвердження великих операцій і розподіл обов'язків між адміністраторами.
- Конфігурації мереж — файли з параметрами підключення до Ethereum, BSC, Polygon, Solana і TON: адреси вузлів, резервні провайдери, комісії, таймаути, правила перемикання при недоступності основного каналу.
- Регламент резервного копіювання та відновлення — як і з якою періодичністю зберігаються зашифровані копії, де вони лежать, як перевіряється відновлення доступу на тестовому контурі.
- Схема потоків підпису — діаграма, що показує шлях транзакції від інтерфейсу до відправлення в мережу: де перевіряються ліміти, де спрацьовує підтвердження, де логується подія.
- Документація з ротації ключів — покроковий порядок планової заміни ключів і відкликання скомпрометованих без зупинки сервісу.
- Журнал аудиту операцій — які події пишуться, у якому форматі, скільки зберігаються і як вивантажуються для розбору інцидентів.
Кожен артефакт узгоджений з вашою службою безпеки і передається в робочому вигляді — не як чернетка, а як документ, за яким новий інженер вводиться в проєкт за лічені дні.
Кейс: як скоротили частку завислих транзакцій утричі
Завдання надійшло від команди, яка вела мультичейн-гаманець із підтримкою Ethereum, BSC, Polygon, Solana та TON. Користувачі скаржилися на «завислі» транзакції: списання з рахунку проходило, а підтвердження в мережі не надходило.
Частка успішних транзакцій трималася на рівні 82%, а підтримка тонула в однотипних зверненнях — кожна друга заявка була про «гроші пішли, але не дійшли».
Що було до
Розбір показав три причини. Перша — єдиний таймаут підтвердження для всіх мереж: там, де блок виходить швидко, транзакція вже була в блоці, а гаманець усе ще чекав і показував статус «в обробці».
Друга — невірний розрахунок комісії при піковому навантаженні: транзакція йшла із заниженою ставкою і висіла в мемпулі годинами. Третя — ручне відновлення: інженер піднімав історію за логами, це займало до 40 хвилин на звернення.
Що змінили
Налаштували окрему політику підтвердження під кожну мережу і додали автоматичний перерахунок комісії за поточним навантаженням перед відправкою.
Ввели фоновий моніторинг статусу: якщо транзакція не підтвердилася за розрахункове вікно, система сама перевідправляє її з коректною ставкою, а користувач бачить зрозумілий статус замість нескінченного очікування.
Що стало
Частка успішних транзакцій зросла з 82% до 96%. Час додавання нової мережі скоротився з двох тижнів до трьох днів — конфігурація мережі описується декларативно, без правок у ядрі.
Час відновлення завислої операції впав з 40 хвилин до 5: сценарій відпрацьовує автоматика, інженер підключається лише до нестандартних випадків. Потік звернень у підтримку з цієї теми скоротився приблизно втричі.
Проєкт вів Trust Wallet-класу сценарій мультичейн-підписів — ми перенесли логіку на свою архітектуру і закрили клас завислих транзакцій на рівні відправки, а не розбору наслідків.
Чим відрізняється мультичейн гаманець від набору окремих гаманців?
Окремі гаманці — це кілька незалежних сховищ ключів, кожне зі своїм форматом, своєю seed-фразою та своїм способом підпису.
Користувач тримає N застосунків або N профілів, між якими немає спільного стану: баланси не зводяться, історія не збирається, а переказ між мережами вимагає ручного перенесення адреси з одного вікна в інше.
Помилка на цьому стику — не рідкість, бо адресні формати в мереж різні й людське око їх не розрізняє.
Мультичейн гаманець будується навколо єдиного інтерфейсу та спільного реєстру. Ключовий матеріал виводиться один раз з однієї seed-фрази різними шляхами, і для кожної мережі виходить своя коректна адреса — при цьому користувач бачить один список активів і одну історію операцій.
Реєстр зберігає стан по всіх мережах в єдиній моделі, тому баланс, комісія та статус транзакції читаються однаково, незалежно від того, яка мережа під капотом.
Наскрізний підпис — головна технічна відмінність. Транзакція збирається в спільному шарі, підписується один раз і йде в потрібну мережу в її власному форматі: десь це account-модель з nonce, десь UTXO-подібна логіка або інша схема підтверджень.
Користувач підтверджує дію один раз, а гаманець сам приводить підпис до вимог мережі — без перемикання застосунків і повторного введення пароля.
Звідси й різниця в експлуатації. Набір окремих гаманців дає N точок відмови, N оновлень і N місць, де може витекти ключ. Єдиний гаманець зводить це до одного контуру: одна політика доступу, один аудит, один сценарій відновлення.
Додавання нової мережі — це розширення реєстру та адаптера підпису, а не новий застосунок, який користувачеві доведеться освоювати з нуля.
Що робити, якщо вже розгорнуто один гаманець і потрібно додати мережі
Розширення мультичейн гаманця майже ніколи не вимагає переписування з нуля — якщо архітектура з самого початку розділяла ядро та мережеві адаптери.
Ключі, підпис транзакцій, робота з seed-фразою та локальним сховищем залишаються спільними: вони не залежать від того, у якій мережі ви підписуєте. Змінюється лише шар інтеграції — клієнт ноди, формат адрес, правила комісій та модель підтверджень.
Якщо цей шар винесено в окремий модуль з єдиним інтерфейсом, додавання мережі перетворюється на підключення нового адаптера, а не на ревізію всього застосунку.
Першим кроком ми дивимося, наскільки поточне ядро готове до кількох мереж одночасно. Перевіряємо, де в коді зашиті припущення про одну мережу: формат адреси, спосіб оцінки комісії, момент фіналізації транзакції, обробка реорганізацій.
Кожне таке місце — точка, яку доведеться узагальнити. Далі описуємо єдиний контракт адаптера: отримання балансу, побудова та підпис транзакції, відстеження статусу, робота з токенами.
Після цього нова мережа підключається як реалізація цього контракту, а інтерфейс користувача та логіка зберігання ключів не змінюються.
Міграція тут — не перенесення даних, а розширення моделі. Існуючі гаманці продовжують працювати в попередній мережі, нова додається поруч: той самий seed, окрема гілка деривації адрес, свій список токенів і своя історія операцій.
Користувач не втрачає доступ і не перестворює гаманець. Ми окремо перевіряємо, що деривація адрес для нової мережі дає коректні значення і що відновлення з seed-фрази повертає всі мережі одразу.
Інтеграція із зовнішніми сервісами — оглядачами блоків, провайдерами котирувань, сервісами обміну — йде через той самий адаптерний шар, щоб збій одного провайдера не валив інші мережі. Ми додаємо ізоляцію: помилки в новій мережі не впливають на роботу вже підключених. Тести розширюються на новий сценарій — підпис, відправлення, підтвердження, відкат при відхиленні.
Практика показує: при розділеному ядрі додавання мережі займає тижні, а не місяці, і не вимагає заморозки поточного релізу. Якщо ядро монолітне, ми спочатку виділяємо адаптерний шар на існуючій мережі — це безпечний рефакторинг без зміни поведінки, — а потім підключаємо нові. Так розширення йде без переписування і без ризику для працюючих користувачів.
Обговоримо задачу: повернемося з оцінкою та планом
Щоб оцінка була реалістичною, а не «середньою по ринку», нам потрібно зрозуміти межі задачі: які мережі в першій версії, звідки беруться ключі, хто відповідає за інфраструктуру вузлів. Нижче — питання, які ми ставимо на старті. Відповіді на них перетворюються в план робіт з етапами, термінами та зонами відповідальності.
- Які мережі обов'язкові в першій версії, а які можна додати пізніше без переробки архітектури?
- Як зберігаються ключі: тільки на пристрої користувача чи передбачається відновлення через резервну фразу та хмару?
- Чи потрібні апаратні гаманці та підключення зовнішніх підписувачів?
- Хто надає доступ до вузлів мереж: власна інфраструктура чи сторонні провайдери, і чи є вимоги щодо відмовостійкості?
- Які операції критичні: перекази, обмін усередині застосунку, стейкінг, робота з токенами стандартів різних мереж?
- Чи потрібна підтримка кількох акаунтів, мультипідпис або ролі для командного доступу?
- Які перевірки безпеки обов'язкові: аудит коду, тестування на проникнення, програма пошуку вразливостей?
- Чи є вимоги регуляторів і правила зберігання даних користувачів у конкретних юрисдикціях?
Після розбору ми повертаємося з оцінкою за етапами, планом релізів і описом того, як буде влаштована підтримка після запуску. Опишіть задачу у зручному форматі — листування, дзвінок або короткий опис із прикладами сценаріїв.
