EthBackNode: зачем вашему приложению “прокладка” между ним и Ethereum-нодой

Если вы когда-либо пробовали написать крипто-кошелёк, платёжный шлюз или просто “бэкенд, который умеет отправлять и принимать ETH”, то довольно быстро выясняется неприятная вещь: Ethereum-нода — это не ваш бэкенд

Это мощный кусок инфраструктуры, который говорит с вами языком протокола (JSON-RPC), и совершенно не обязан быть удобным для продуктовой разработки.

На бумаге всё выглядит тривиально: “подключились к geth, запросили баланс, отправили транзакцию, получили хеш”. А на практике вы внезапно начинаете писать то, что хотели бы не писать:

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

В этом месте и появляется EthBackNode — open-source сервис на Go, который играет роль “адаптера” между вашим приложением и Ethereum-нодой, и даёт чистый 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