Більшість посібників із розробки децентралізованих застосунків досі починаються не з того. Вони радять вибрати Solidity, підключити гаманець, пройти аудит і запуститися. Така послідовність створює демонстрацію контракту, а не продукт, за яким фінансова команда може закрити звітний період.
Публічний блокчейн виконає все, що ви розгорнули. Але він не пояснить операційній команді, який депозит уже остаточний, хто мав право підписати виплату або чому вчорашній баланс більше не збігається з даними мережі. Обробку подій, архітектуру операційного журналу, звірку, правила підписання та відновлення після незворотних помилок варто закладати в архітектуру з першого дня. Контракт — це лише замок.
Зміст
- Що насправді охоплює розробка децентралізованих застосунків
- Чотири рівні, потрібні кожному dApp
- Вибір моделі гаманця та підписання
- Потоки подій та архітектура операційного журналу
- Моделі інтеграції за типом бізнесу
- Першочергові засоби контролю відповідності й ризиків
- Як перейти від пісочниці до робочого режиму
- Поширені запитання
Що насправді охоплює розробка децентралізованих застосунків
Підхід, зосереджений лише на контракті, — головна проблема. Смартконтракт із приєднаною вебсторінкою ще не є застосунком. Розробка децентралізованих застосунків означає створення програмного забезпечення, ключові зміни стану якого виконуються в публічному блокчейні, тоді як користувачі, оператори й аудитори працюють через позамережеві системи, які можуть запускати самостійно.
Уявіть контракт як замок сховища. Банку все одно потрібні касири, процедури підписання, виписки й порядок закриття дня. Гаманці, відправлення транзакцій у мережу, моніторинг подій і звірка виконують роль цих процедур. Команди, які не планують їх заздалегідь, стикаються з прогалиною в тиждень запуску: депозит зависає в очікуванні, а за операційний журнал ніхто не відповідає.
Масштаб використання вже вимагає, щоб ці процедури витримували навантаження. За даними галузевого звіту DappRadar за 2024 рік, наприкінці року децентралізовані застосунки в середньому мали 24,6 млн унікальних активних гаманців щодня, а річне зростання становило 485%.
До сфери робіт також належать правила: хто може запитувати переказ, які мережі й активи дозволені, коли стан очікування перетворюється на зарахований баланс і як фінансова команда зберігає власні копії даних. Ви можете експортувати інформацію про рахунки й транзакції через застосунок або документований API, але саме ви відповідаєте за копії, яких потребують бухгалтерський облік, відповідність вимогам і безперервність роботи.
Мета BroLabel — спростити створення фінансових продуктів, щоб командам не доводилося самостійно будувати кожен рівень інфраструктури. Далі розглянемо архітектурні рівні, моделі підписання, події та операційний журнал, інтеграцію за типом бізнесу, контроль ризиків, перехід від пісочниці до робочого режиму й запитання покупців, які зазвичай виникають останніми.
Чотири рівні, потрібні кожному dApp
Порт — зрозуміліша аналогія, ніж типовий слайд зі стеком. Контракт установлює митні правила. Рівень підписання зберігає ключі від воріт. Відправлення в мережу рухає кораблі. Операційний журнал — це портова книга, якій довіряє фінансова команда під час закриття дня.
Більшість застосунків не складаються з безлічі контрактів. Емпіричне дослідження dApp в Ethereum показало, що 70,57% застосунків використовували лише один смартконтракт, а 90,46% — менше трьох. Основна складність припадає на гаманці, індексацію, відповідність вимогам та операції. Слабкий контракт важко виправити після розгортання. Слабкий позамережевий рівень можна оновити. Якість контракту не дорівнює якості системи.
Що ламається, коли один із рівнів слабкий
Сприймайте колонку зі збоями як інцидент, через який вас викличуть.
| Рівень | Завдання | Типовий збій | Приклад компонента |
|---|---|---|---|
| Ончейн-контракти | Перевірювані зміни стану та правила авторизації | Незворотні логічні помилки після розгортання | Контракти токенів, ескроу або виплат |
| Підписання та гаманці | Авторизація кожної транзакції за визначеними правилами | Компрометація ключа або слабкий процес схвалення | Підписання MPC 2-з-3 із Co-Signer під контролем клієнта |
| Відправлення в мережу | Надсилання транзакцій і відстеження їхнього стану в різних мережах | Завислі, замінені або непомітно відхилені транзакції | Відправлення в 10 підтримуваних мереж |
| Події та операційний журнал | Фіксація спостережень, підтверджень і рішень | Дубльовані, втрачені або перезаписані записи | Операційний журнал лише з доповненням і звіркою |
| Інтерфейс застосунку | Відображення балансів, процесів і станів очікування | Транзакції в очікуванні показані як остаточні | Веб-, мобільний або Telegram-інтерфейс |
BroSettlement охоплює підписання та відправлення в мережі: DKG, MPC-підписання, надсилання в мережу та Co-Signer під контролем клієнта у 10 мережах. Поруч працюють незмінний операційний журнал, події в реальному часі, REST і засоби OpenAPI з автентифікацією Ed25519. Це API-first інфраструктура для вбудованих MPC-гаманців, операційних журналів, карткових продуктів та інтеграцій для фіатного вводу/виводу.
Власне, придбане або відсутнє
Позначте стан кожного рівня, перш ніж планувати команду на спринт.
- Обсяг, який неможливо спрогнозувати. Придбайте рівень відправлення в мережі та операційний журнал замість черги, яку згодом доведеться переписати.
- Навантаження з питань відповідності. Суворіші аудиторські вимоги потребують експортованого журналу, а не застосункових логів, що ротуються.
- Кількість мереж. Одна й десять мереж — це різні завдання для рівня відправлення.
- Швидкість виходу на ринок. Придбайте рівні, збої яких можуть мати незворотні наслідки. Залиште собі інтерфейс, якщо саме він є вашим продуктом.
Вибір моделі гаманця та підписання
Один приватний ключ на одному сервері або ноутбуці одного інженера — це архітектура з ризиком повної втрати. Одна компрометація дає змогу авторизувати всі виплати. Такий підхід не варто використовувати за межами прототипу.
Три моделі гаманців охоплюють більшість продуктів, які описують засновники. Споживчі застосунки використовують гаманці користувачів. Автоматизовані системи — окремий гаманець для кожного агента, щоб кожен агент мав власника. Операторські платформи, зокрема iGaming, застосовують окремий гаманець для кожного гравця, щоб адреса депозиту не була спільним гарячим гаманцем.
Де насправді зберігається ключ
| Модель підписання | Де зберігається ключовий матеріал | Єдина точка відмови | Найкраще застосування |
|---|---|---|---|
| Один приватний ключ у застосунку | Один сервер, пристрій або інженер | Так | Лише прототипи й тестові середовища |
| Ончейн-контракт multisig | Контракт із кількома визначеними власниками | Частково, і лише якщо підписанти справді незалежні | Казначейства, яким потрібне ончейн-управління |
| MPC 2-з-3 із Co-Signer під контролем клієнта | Розділені частки ключа; жодна частка не може підписати самостійно | Жодна окрема частка чи сторона не може підписати самостійно | Робочі виплати та вбудовані гаманці |
| Кастодіальний ключ у провайдера | У системах провайдера | Провайдер | Просте підключення з низьким рівнем контролю оператора |
Керування ключами — це проблема організаційного контролю, а не лише вибір алгоритму. NIST SP 800-57 поділяє роботу на захист ключового матеріалу, організаційні правила та планування безпеки, а також використання криптографічних функцій у конкретному застосунку. Схема 2-з-3 без цих меж — лише складніше сховище ключів.
Які правила має забезпечувати Co-Signer
Клієнтський Co-Signer у BroSettlement має працювати за письмово зафіксованими правилами підписання.
- Хто може створити запит. Визначені ролі, а не спільний обліковий запис адміністратора.
- Хто може схвалити. Інша система, не та, що сформувала транзакцію.
- Ліміти суми. На одну транзакцію й на день, із другим схваленням понад порогове значення.
- Аварійне відновлення. Хто може відновити частку, а хто не може.
- Що фіксується в журналі. Кожний запит, схвалення, відхилення та спроба відправлення в мережу.
Якщо ваша конфігурація використовує Co-Signer під керуванням клієнта або контрольовані клієнтом матеріали підписання чи відновлення, ви експлуатуєте й захищаєте ці компоненти. Це охоплює контроль доступу, резервні копії та правила схвалення. MPC усуває залежність від одного місця зберігання ключа. Але він не усуває зловмисну транзакцію, слабкий процес схвалення або недоступність підписанта в день виплати зарплати.
Відокремте створення від авторизації та перевіряйте правила до видачі будь-якого підпису. API-ключі з обмеженими правами, списки дозволених IP-адрес і захист від повторного відтворення створюють другий рубіж, щоб викрадений токен не давав змоги підписувати звідусіль. Якщо ви ще порівнюєте моделі рахунків, прочитайте про гаманці з абстракцією рахунку, а потім вирішіть, чи користувач володітиме смартрахунком, чи ви вбудуєте гаманець за описаними вище правилами.
Практичне правило: якщо одна людина або одна скомпрометована система може самостійно переміщувати кошти, модель не готова до робочих виплат.
Потоки подій та архітектура операційного журналу
На цьому рівні головний ворог — сприйняття першої побаченої події мережі як остаточної. Сповіщення про депозит — це спостереження, а не зарахування.
Документація Geth про публікацію та підписку описує підписки JSON-RPC через повнодуплексне з'єднання, зазвичай WebSocket або IPC. Вузол повертає ідентифікатор підписки й надсилає сповіщення, коли відбувається подія, на яку оформлено підписку. Ви припиняєте опитування, але не отримуєте гарантій доставки, повноти бухгалтерського обліку чи остаточності.
Депозит, стан якого ще може змінитися
Припустімо, оператор відстежує депозит гравця у TRC20.
- deposit.observed записує стан очікування. Гравець бачить «очікується», а не доступний для витрат баланс.
- deposit.confirmed переводить запис у наступний стан лише після досягнення вашого порога підтверджень.
- Виплата виконується лише після проходження правил оператора.
З'єднання розриваються. Сповіщення дублюються й надходять не за порядком. Execution API Ethereum дозволяє повторно надсилати вилучені логи з полем removed: true. Додайте сторнувальний запис. Не видаляйте початкове спостереження. Саме через необхідність такого розділення команди вивчають відокремлення сервісів для безпечніших релізів, перш ніж дозволити одному споживачу одночасно відстежувати мережу й виконувати виплати.
Три записи замість одного рядка
Зберігайте зовнішню подію мережі, внутрішній запис операційного журналу й бізнес-рішення окремо. Якщо об'єднати їх, реорганізація блокчейну перезапише єдиний доказ, який мала фінансова команда.
| Поле | Призначення |
|---|---|
| chain | мережа, у якій спостерігалася подія |
| transaction hash | ідентифікує ончейн-транзакцію |
| log index | розділяє кілька логів усередині однієї транзакції |
| event version | дає обробникам змогу опрацьовувати виправлені або сторновані події |
| subscription ID | пов'язує кожне сповіщення з його потоком |
Для виведень потрібен ключ ідемпотентності, щоб повторна спроба не створила другу виплату. Запускайте звірку за розкладом — щогодини є розумним базовим варіантом — і порівнюйте суми та стани в журналі з авторитетними даними мережі. Кожну розбіжність спрямовуйте людині, а не лише записуйте в лог. Інтеграційна поверхня для цього — REST API, автентифікація Ed25519 та події WebSocket. Процес проходження цього сліду рецензентами має бути описаний у письмовому процесі аудиту.
WebSocket підвищує оперативність і зменшує навантаження від опитувань. Це шина сповіщень, а не остаточний розрахунок.
Перевірка проста: чи може фінансова команда пояснити кожну зміну балансу лише за операційним журналом, без логів застосунку? Якщо ні, журнал досі є лише кешем.
Моделі інтеграції за типом бізнесу
Один стек обслуговує п'ять різних типів власників балансу. Те, хто утримує гроші й як вони виходять із системи, змінює гаманець, події та журнал, який ви звіряєте.
| Бізнес-модель | Модель гаманця | Потік подій | Головне в операційному журналі |
|---|---|---|---|
| Криптобіржа | Гаманці користувачів для депозитів і виведень | deposit.observed, deposit.confirmed, стан виведення | Зіставлення балансів клієнтів зі станом мережі |
| iGaming-оператор | Окрема адреса депозиту TRC20 USDT для кожного гравця | Події депозиту й результат перевірки правил оператора до виплати | Звірка балансів гравців |
| Необанк або фінтех-застосунок | Вбудований гаманець для кожного користувача | Стани депозиту, переказу та виведення | Зіставлення журналу рахунків із фіатними виписками |
| Платформа AI-агентів | Окремі гаманці агентів із рольовим доступом | Події транзакцій та результати перевірки правил | Аудиторський слід для кожного агента й власника |
| Корпоративне казначейство | Структура з кількох гаманців і правилами схвалення | Події підтвердження та схвалення | Зіставлення казначейського журналу з банківськими записами |
iGaming: одна адреса на гравця
Не використовуйте одну адресу USDT спільно для кількох гравців. Надайте кожному гравцеві окрему адресу депозиту TRC20 USDT, споживайте події депозитів і перевіряйте правила оператора до підписання виплати. Ведіть журнал лише з доповненням для звірки балансів гравців. Правила — це ворота. Журнал — це те, що відкриває фінансова команда, коли гравець оскаржує зарахування.
Агентам потрібен визначений власник
AI-агенти отримують окремі некастодіальні гаманці з рольовим доступом та аудиторським слідом. Кожна дія має власника. Без цього некерований агент і скомпрометований запит виглядають однаково, а команда ризиків не розуміє, кого саме зупинити.
Складніші журнали, ті самі мережі
MPC-гаманці BroSettlement працюють у 10 мережах, зокрема BTC, ETH, SOL, BNB, TRX, POL, BASE та ARB. Перш ніж планувати запуск, підтвердьте набір для свого робочого процесу в актуальній документації API. Та сама база підходить для бірж, необанків, платіжних шлюзів, DeFi-платформ, корпоративних казначейств, стейблкоїн-платформ, iGaming і бетингу.
Необанк або казначейська команда мають приділяти операційному журналу більше уваги, ніж потоку подій. Самі лише сповіщення мережі не узгодять фіатні виписки. Зафіксуйте кількість гаманців, типи подій і відповідального за звірку, перш ніж вибирати модель. Якщо за звірку ніхто не відповідає, у вас лише демонстрація.
Першочергові засоби контролю відповідності й ризиків
Головна причина збою — відповідальність без визначеного власника. Провайдер не компенсує помилкову адресу. Мережа не скасує некоректне відправлення. Аудит не опрацює інцидент, що стався в понеділок.
Публічні блокчейни, валідатори, емітенти токенів і незалежні провайдери можуть зазнавати збоїв, затримувати чи відхиляти транзакції, змінювати порядок блоків або видимий стан транзакції. Це потрібно враховувати у власних правилах підтвердження, звірки й обслуговування кінцевих користувачів. Ви також відповідаєте за адреси, вибір мережі та активу, суми, дані отримувача, інструкції до транзакції та рішення з питань відповідності. Блокчейн-транзакції можуть бути незворотними.
Найпростіший приклад — виведення на правильну адресу в неправильній мережі. Ніхто не зможе повернути його за вас.
Що насправді доводить тест
Сканери дають різні результати й не знаходять усі вразливості, тому одна перевірка не може бути умовою релізу. Поєднуйте сканування з фаззингом на основі властивостей і ручною перевіркою, з урахуванням призначення контракту. Фінансові контракти потребують перевірки арифметики та оракулів. Токен-контракти — перевірки авторизації та дозволів. Завершений аудит є доказом стану коду в конкретний момент, але не безперервним планом контролю.
Звіт CertiK Hack3d про безпеку Web3 за 2025 рік зафіксував приблизно $3,35 млрд збитків, що на 37,06% більше, ніж у 2024 році. Лише атаки на ланцюги постачання спричинили близько $1,45 млрд збитків у двох інцидентах. Тому моніторинг залежностей та інтеграцій гаманців має входити до переліку перевірок перед запуском.
AML-перевірки застосовуються лише тоді, коли їх налаштовано для конкретного сервісу й визначено його конфігурацією, клієнтським договором, чинними вимогами або залученим провайдером. Будь-який регульований сервіс чи роль зі зберігання активів мають бути визначені підписаним договором і забезпечені належними дозволами. Коли ці перевірки фактично налаштовані, пояснення AML-моніторингу від Portreeve дає зрозумілий зовнішній погляд, який має узгоджуватися з вашим процесом керування відповідністю вимогам.
Які засоби контролю потрібно зафіксувати
- Перевірки до відправлення в мережу для адреси та мережі перед будь-яким підписом.
- Списки дозволених адрес отримувачів для казначейства та напрямків виплат.
- Ліміти сум із подвійним схваленням понад порогове значення.
- Рольовий доступ, щоб запит, схвалення та відправлення залишалися розділеними.
- План дій для призупинення, реагування на інцидент і сповіщення користувачів.
- Безперервна звірка з даними мережі за розкладом, за яким уже працює завдання операційного журналу.
Керівник команди з відповідності має письмово відповісти, хто схвалює операції, хто може зупинити процес і хто повідомляє користувачів про затримку чи сторнування транзакції.
Як перейти від пісочниці до робочого режиму
Робоче й тестове середовища відокремлені. Доступ до тестового середовища не підтверджує доступність, ліміти чи продуктивність у робочому середовищі. Успішний тест у пісочниці — це репетиція, а не твердження про пропускну здатність.
- Перевірте обсяг робіт. У застосунку й актуальній документації API підтвердьте середовище, увімкнену мережу, актив, тип транзакції, ліміти та операційні вимоги кожного робочого процесу. Невідповідність на цьому етапі зірве запуск ще до першого реального користувача.
- Створіть і протестуйте рішення в пісочниці. Відпрацюйте підписання та відправлення в мережу з тестовими коштами. Швидкість у тесті не дорівнює швидкості в робочому режимі.
- Зафіксуйте правила підписання. Ролі, системи схвалення, ліміти сум, відновлення та журналювання. Визначте, хто контролює Co-Signer.
- Підключіть події та операційний журнал. Стабільні бізнес-ключі, ідемпотентні обробники та сторнування лише через додавання нових записів. Не створюйте тут другу модель подій.
- Проведіть навчання зі звірки. Перевірте дубльовані сповіщення, розірване з'єднання й змодельовану реорганізацію блокчейну. Суми мають збігтися до того, як хтось назве дату запуску.
- Оформте договори й засоби контролю. Підпишіть потрібний договір для регульованих послуг або зберігання активів, налаштуйте AML-перевірки для конкретного сервісу й завершіть план реагування на інциденти. Стандартний доступ до BroSettlement надається після реєстрації та активації тарифного плану в застосунку. Стандартний план самообслуговування не потребує окремої генеральної угоди про надання послуг. Для регульованих ролей усе одно потрібен окремий договір.
- Запустіться з малим обсягом. Почніть із поетапних лімітів, а протягом перших тижнів переглядайте події та розрахунок комісій. Підвищуйте ліміти лише після цієї перевірки.
Визначайте дату запуску лише після того, як інженерна, фінансова та команда з відповідності погодять етапи 1–5.
Поширені запитання
Чи достатньо аудиту смартконтракту перед запуском?
Ні. Аудит описує код у конкретний момент. Для запуску також потрібні правила підписання, обробка подій, звірка та план дій.
Нам потрібен MPC чи достатньо multisig?
Це залежить від незалежності підписантів. MPC 2-з-3 із Co-Signer під контролем клієнта підходить для робочих виплат. Ончейн-multisig підходить казначействам, яким потрібне видиме в блокчейні управління.
Як уникнути подвійного зарахування депозиту?
Використовуйте стабільний бізнес-ключ, що складається з мережі, хешу транзакції, індексу логу та версії події, і обробляйте його ідемпотентно. Якщо лог надходить із полем removed зі значенням true, додайте сторнувальний запис.
Чи гарантує WebSocket отримання кожного депозиту?
Ні. WebSocket підвищує оперативність і зменшує потребу в опитуванні, але не гарантує доставку, повноту бухгалтерського обліку чи остаточність. Планова звірка з даними мережі все одно необхідна.
Які мережі підтримуються?
Загалом 10 мереж, зокрема BTC, ETH, SOL, BNB, TRX, POL, BASE та ARB. Перш ніж планувати робочий процес, підтвердьте повний список в актуальній документації API.
Хто відповідає, якщо кошти надіслано не на ту адресу?
Ви. Адреса, мережа, актив і сума належать до відповідальності клієнта, а транзакція може бути незворотною.
BroLabel надає робочим командам вбудовані MPC-гаманці, Co-Signer під контролем клієнта, відправлення в мережі, операційний журнал лише з доповненням і події WebSocket, щоб розробка децентралізованих застосунків не зупинялася на контракті. Якщо ви визначаєте правила підписання, обробку депозитів і звірку до запуску, почніть у пісочниці та підключіть ці засоби контролю разом із нами. Bro has your back! Відвідайте BroLabel, коли будете готові перевірити стек на реальному робочому процесі.
