EthBackNode: навіщо вашому додатку “прокладка” між ним та Ethereum-нодою

Якщо ви коли-небудь пробували написати крипто-гаманець, платіжний шлюз або просто "бекенд, який вміє відправляти та приймати ETH", то досить швидко з'ясовується неприємна річ: Ethereum-нода - це не ваш бекенд

Це потужний шматок інфраструктури, який говорить з вами мовою протоколу (JSON-RPC), і зовсім не повинен бути зручним для продуктової розробки.

На папері все виглядає тривіально: підключилися до geth, запросили баланс, відправили транзакцію, отримали хеш. А на практиці ви раптово починаєте писати те, що хотіли б не писати:

• де зберігати ключі та як їх видавати адресами,
• як відновлювати гаманець по seed phrase,
• як відстежувати вхідні/вихідні транзакції великим пулом адрес,
• як зробити повідомлення “в реальному часі”, а не нескінченний polling,
• як усе це переживає рестарт сервісу та не втрачає стан.

У цьому місці і з'являється EthBackNode — open-source сервіс на Go, який відіграє роль “адаптера” між вашим додатком JSON-RPC 2.0 API під типові бекенд-задачі.

Чому безпосередньо з Ethereum JSON-RPC жити складно (і іноді дорого)

Ethereum JSON-RPC - штука правильна, але низькорівнева. Вона показує можливості ноди, а чи не відповідає питанням “як зробити продукт”. При інтеграції ви швидко розумієте, що те саме завдання розпадається на десяток дрібних завдань, і половина з них взагалі не про блокчейн.

Наприклад, “прийняти оплату на адресу”:

1. Потрібно надати клієнтові адресу.
2. Потрібно переконатися, що адреса пов'язана з конкретним замовленням/рахунком.
3. Потрібно моніторити мережу та зрозуміти, що транзакція дійсно прийшла.
4. Потрібно дочекатися підтверджень (і пам'ятати, що бувають реорги).
5. Потрібно відправити подію у ваш бекенд: “оплата прийшла, можна відвантажувати”.
6. Потрібно зберегти весь цей стан так, щоб перезапуск сервісу не вдав, що “нічого не було”.

Якщо у вас одне замовлення на день - можна "на коліні". Якщо у вас десятки/сотні адрес і це хоч трохи критично для бізнесу — починається інженерія.

І тут важливо помітити: середній розробник backend-систем зазвичай хоче рівно одну річ — передбачуваний API, зрозумілі події та мінімальну поверхню атаки. А не занурення у тонкощі “як влаштований вузол”.

Що робить EthBackNode

EthBackNode - це "легкий" сервіс, який ви ставите поряд з нодою (або підключаєте до неї), а ваш додаток спілкується вже з ним. Зовні він виглядає як один JSON-RPC 2..0 endpoint, усередині — набір модулів (менеджерів), які відповідають за адреси, передплати, транзакції та смарт-контракти.

Ключові функції, які він надає через API:

1) Генерація та керування адресами

Сервіс вміє створювати та вести адреси на стороні бекенду. Важливо не те, що “адресу можна згенерувати” (можна і самим), а те, що з'являється єдине місце, де адреса живе як сутність: прив'язка до вашого userId/invoiceId, зберігання, відновлення.

2) Відновлення гаманців по seed phrase (BIP-39/44)

Особливий біль — імпорт та відновлення гаманців. В EthBackNode передбачено роботу з seed phrase (BIP-39) та деривацією (BIP-44), щоб ви могли будувати “нормальні” сценарії відновлення без власного велосипеда.

3) Моніторинг вхідних/вихідних транзакцій

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

4) Переклади: ETH та ERC-20

EthBackNode дозволяє виконувати переклади як нативного ETH, так і ERC-20 токенів. Для бекенд це виглядає як одна операція “transfer”, а не як окремий набір низькорівневих викликів та перевірок. Плюс є оцінка комісії (fee estimation) — без неї ви або гадаете, або робите додаткові запити самі.

5) Callback-повідомлення про події

Мабуть, те, що дійсно заощаджує нерви: сповіщення про події. Замість кожні N секунд запитувати “а чи прийшло?”, ви можете налаштувати callback і отримувати подію “була транзакція / новий блок / підтвердження” у ваш бекенд.

Архітектурні деталі, які виглядають нудно, але вирішують половину проблем

У подібних сервісах зазвичай важливо не “багато фіч”, а те, як воно житиме в експлуатації.

Go + fasthttp

Продуктивність та простота деплою. Один бінарник, швидкий старт, зрозуміле навантаження. У крипто-бекендах це не абстрактна “оптимізація”, а банальна необхідність: багато адрес, багато подій, багато запитів.

Підключення до ноди: HTTP-RPC та IPC

EthBackNode підтримує роботу з нодою як через HTTP-RPC, так і через IPC-сокет. IPC часто вибирають, коли сервіс та geth живуть на одній машині: менше мережної поверхні, менше проблем з налаштуванням доступу, і часто просто надійніше..

BadgerDB як вбудоване сховище

Ще один прагматичний вибір: вбудована база, без обов'язкового зовнішнього Postgres/Redis на старті. Це сильно знижує поріг: можна підняти сервіс, дати йому каталог під дані, і він зберігатиме свій стан сам.

Конфігурація в HCL

HCL — людський формат із “хешикорповського світу”. Він товаришує з інфраструктурним підходом (Git, ревью, оточення), і при цьому читається простіше, ніж JSON-конфіги на 200 рядків.

Модульність: менеджери адрес, підписок, транзакцій, контрактів

Це важливіше, ніж здається. Коли у вас все "в одній купі", кожна зміна стає ризикованою. Коли є явні межі, простіше тестувати, простіше розширювати, простіше розуміти.

Де це реально корисно

EthBackNode не намагається бути "універсальним індексатором" або аналітичною платформою. Його ніша є прикладним бекендом для продуктів.

• Платежні процесори: видача депозитних адрес, моніторинг оплат, повідомлення, наступні висновки/свіпи.
• Кастодіальні гаманці: пул адрес, виведення коштів, відстеження статусів.
• Сервіси сповіщень: один компонент стежить за мережею, інші отримують події.
• Backend-for-frontend: мобільне/веб API не знає про блокчейн — знає лише про бізнес-події.
• Біржі та сервіси з безліччю адрес: масове спостереження за депозитами без самописного “сканера всього блокчейну”.

Невеликий приклад: як це виглядало б в інтернет-магазині

Припустимо, у вас невеликий e-commerce, і ви хочете приймати оплату в ETH та одному популярному ERC-20 стейблкоїні.

Сценарій може бути таким:

1. Користувач оформляє замовлення → ваш бекенд створює orderId.
2. Бекенд просить у EthBackNode нову адресу для цього замовлення.
3. Бекенд реєструє callback-URL: “якщо щось прийшло на цю адресу – повідом мені”.
4. Користувач платить.
5. EthBackNode бачить транзакцію та відправляє у ваш callback подію: сума, токен, хеш, статус.
6. Ви чекаєте на потрібну кількість підтверджень і переводите замовлення в стан “оплачений”.
7. За розкладом (або одразу) ви виводите кошти на основну адресу зберігання.

В результаті “крипто частина” перестає розповзатися за кодом вашого магазину. Вона живе в одному сервісі, де її логічно обслуговувати та тестувати..

Чому це важливо (без гасел)

У Web3 багато складнощів, які не є “магією блокчейну”. Це просто інженерна рутина: адреси, ключі, підписки, статус транзакцій, підтвердження, повідомлення, збереження стану.

EthBackNode знижує поріг входу для звичайних backend-команд: замість того, щоб розмовляти з нодою її мовою, ви розмовляєте з сервісом мовою завдань. І це, мабуть, найкорисніша форма “абстракції” у прикладній крипто-розробці: не приховати блокчейн, а зробити його експлуатацію передбачуваною.

Якщо у вас продукт, який повинен надійно приймати та відправляти ETH/ERC-20, і ви не хочете перетворювати основний код на набір милиць навколо JSON-RPC — такий адаптерний шар виглядає не розкішшю, а здоровим глуздом.

За матеріалами itprolab.dev