Si alguna vez ha intentado escribir una billetera criptográfica, una pasarela de pago o simplemente un "backend que pueda enviar y recibir ETH", rápidamente queda claro algo desagradable: el nodo Ethereum no es su backend.
Esta es una poderosa pieza de infraestructura que le habla en un lenguaje de protocolo (JSON-RPC) y no tiene por qué ser conveniente para el desarrollo de productos.
Sobre el papel, todo parece trivial: "conectarse a geth, solicitar saldo, enviar transacción, recibir hash". Pero en la práctica, de repente empiezas a escribir lo que te gustaría no escribir:
- dónde almacenar las claves y cómo emitirles direcciones,
- cómo restaurar una billetera usando una frase inicial,
- cómo realizar un seguimiento de las transacciones entrantes/salientes en un gran conjunto de direcciones
- cómo hacer notificaciones “en tiempo real” en lugar de encuestas interminables
- cómo todo esto sobrevive a un reinicio del servicio y no pierde su estado.
Aquí es donde aparece EthBackNode: un servicio de código abierto en Go que desempeña el papel de "adaptador" entre su aplicación y el nodo Ethereum, y proporciona una API JSON-RPC 2.0 pura para tareas de backend estándar.
Por qué vivir directamente con Ethereum JSON-RPC es difícil (y a veces caro)
Ethereum JSON-RPC es algo bueno, pero de bajo nivel. Muestra las capacidades del nodo y no responde a la pregunta "cómo hacer un producto". Al realizar la integración, rápidamente te das cuenta de que la misma tarea se divide en una docena de tareas pequeñas, y la mitad de ellas no tienen nada que ver con blockchain.
Por ejemplo, “aceptar pago a la dirección”:
- Debes darle una dirección al cliente.
- Debe asegurarse de que la dirección esté asociada a un pedido/factura específico.
- Debe monitorear la red y comprender que la transacción realmente llegó.
- Debes esperar la confirmación (y recuerda que hay reorganizaciones).
- Debes enviar un evento a tu backend: "se recibió el pago, puedes realizar el envío".
- Necesitamos guardar todo este estado para que al reiniciar el servicio no se pretenda que "no pasó nada".
Si tienes un pedido al día, puedes hacerlo de rodillas. Si tiene docenas o cientos de direcciones y esto es al menos algo crítico para el negocio, comienza la ingeniería.
Y aquí es importante tener en cuenta: el desarrollador backend promedio generalmente quiere exactamente una cosa: una API predecible, eventos comprensibles y una superficie de ataque mínima. Y no sumergirse en las complejidades de “cómo funciona el nudo”.
¿Qué hace EthBackNode?
EthBackNode es un servicio “ligero” que se instala junto al nodo (o se conecta a él) y su aplicación ya se comunica con él. Desde fuera parece un JSON-RPC 2...0 endpoint, dentro: un conjunto de módulos (administradores) responsables de direcciones, suscripciones, transacciones y contratos inteligentes.
Funciones clave que proporciona a través de la API:
1) Generación y gestión de direcciones
El servicio puede crear y mantener direcciones en el backend. Lo importante no es que “la dirección se pueda generar” (puedes hacerlo tú mismo), sino que hay un único lugar donde la dirección vive como entidad: vinculación a tu ID de usuario / ID de factura, almacenamiento, recuperación.
2) Restauración de billeteras usando frase inicial (BIP-39/44)
Un problema aparte es la importación y restauración de carteras. EthBackNode proporciona trabajo con frase inicial (BIP-39) y derivación (BIP-44) para que pueda crear escenarios de recuperación "normales" sin su propia bicicleta.
3) Monitoreo de transacciones entrantes/salientes
La parte más práctica: seguimiento de direcciones. El servicio asume la tarea de “monitorear estas direcciones e informar cuando suceda algo”. Es decir, no convierte su aplicación en un escáner de bloques y no escribe la lógica de suscripción nuevamente.
4) Transferencias: ETH y ERC-20
EthBackNode le permite transferir tokens ETH nativos y ERC-20. Desde el punto de vista del backend, esto parece una única operación de "transferencia", en lugar de un conjunto separado de llamadas y comprobaciones de bajo nivel. Además, hay una estimación de la tarifa; sin ella, usted mismo está “adivinando” o haciendo solicitudes adicionales.
5) Notificaciones de devolución de llamada sobre eventos
Quizás, lo que realmente salva los nervios: las notificaciones de eventos. En lugar de preguntar "¿ha llegado?" cada N segundos, puede configurar una devolución de llamada y recibir el evento "hubo una transacción/nuevo bloqueo/confirmación" en su backend.
Detalles arquitectónicos que parecen aburridos pero resuelven la mitad de los problemas
En este tipo de servicios, lo importante normalmente no son “muchas funciones”, sino cómo funcionarán en funcionamiento.
Ir + rápidohttp
Rendimiento y facilidad de implementación. Un binario, inicio rápido y carga comprensible. En los backends criptográficos, esto no es una "optimización" abstracta, sino una necesidad banal: muchas direcciones, muchos eventos, muchas solicitudes.
Conexión a un nodo: HTTP-RPC e IPC
EthBackNode admite trabajar con el nodo tanto a través de HTTP-RPC como a través de un socket IPC. A menudo se elige IPC cuando el servicio y geth viven en la misma máquina: hay menos superficie de red, menos problemas con la configuración de acceso y, a menudo, simplemente es más confiable...
BadgerDB como almacenamiento integrado
Otra opción pragmática: base de datos integrada, sin el obligatorio Postgres/Redis externo al inicio. Esto reduce considerablemente el umbral: puede generar un servicio, darle un directorio para datos y él mismo almacenará su estado.
Configuración en HCL
HCL es un formato humano del “mundo Hashicorp”. Es compatible con el enfoque de infraestructura (Git, revisiones, entornos) y, al mismo tiempo, es más fácil de leer que las configuraciones JSON de 200 líneas.
Modularidad: gestores de direcciones, suscripciones, transacciones, contratos
Esto es más importante de lo que parece. Cuando tienes todo en un solo lugar, cada cambio se vuelve riesgoso. Cuando hay límites claros, es más fácil probar, ampliar y comprender.
¿Dónde es realmente útil?
EthBackNode no intenta ser un “indexador universal” o una plataforma de análisis. Su nicho es el backend de aplicaciones para productos.
- Procesadores de pagos: emisión de direcciones de depósito, seguimiento de pagos, notificaciones, retiros/barridos posteriores.
- Monederos de custodia: conjunto de direcciones, retiro de fondos, seguimiento de estado.
- Servicios de notificación: un componente monitorea la red, el resto recibe eventos.
- Backend-for-frontend: la API móvil/web no conoce la cadena de bloques, solo conoce los eventos comerciales.
- Intercambios y servicios con múltiples direcciones: monitoreo masivo de depósitos sin un "escáner de toda la cadena de bloques" escrito por él mismo.
Un pequeño ejemplo: cómo se vería en una tienda online
Digamos que tienes un pequeño comercio electrónico y quieres aceptar pagos en ETH y una moneda estable ERC-20 popular.
El escenario podría ser así:
- El usuario realiza un pedido → su backend crea un
orderId. - El backend solicita a EthBackNode una nueva dirección para este pedido.
- El backend registra una URL de devolución de llamada: "si llegó algo a esta dirección, avíseme".
- El usuario paga.
- EthBackNode ve la transacción y envía un evento a su devolución de llamada: cantidad, token, hash, estado.
- Espera el número requerido de confirmaciones y transfiere el pedido al estado "pagado".
- Según un cronograma (o inmediatamente), usted retira fondos a la dirección de almacenamiento principal.
Como resultado, la "parte criptográfica" deja de propagarse por el código de su tienda. Vive en un servicio, donde es lógico mantenerlo y probarlo...
Por qué es esto importante (sin eslóganes)
Web3 tiene muchas complejidades que no son "magia blockchain". Es solo una rutina de ingeniería: direcciones, claves, suscripciones, estado de transacciones, confirmaciones, notificaciones, estado de almacenamiento.
EthBackNode reduce la barrera de entrada para los comandos backend habituales: en lugar de hablar con el nodo en su idioma, habla con el servicio en el idioma de la tarea. Y esta es quizás la forma más útil de “abstracción” en el desarrollo criptográfico aplicado: no ocultar la cadena de bloques, sino hacer que su funcionamiento sea predecible.
Si tiene un producto que necesita recibir y enviar ETH/ERC-20 de manera confiable y no desea convertir el código principal en un conjunto de muletas en torno a JSON-RPC, dicha capa adaptadora no parece un lujo, sino sentido común.
Basado en materiales de itprolab.dev
Leer también
Apple publica nuevas reglas sobre aplicaciones de criptomonedas
Según TechCrunch, varios desarrolladores de Apple unieron fuerzas recientemente para crear la "Unión de Desarrolladores". El sindicato pidió a Apple que brindara a los usuarios de Apple Store la oportunidad de descargar pruebas gratuitas de sus aplicaciones. Esta es una de las primeras veces que los desarrolladores independientes de iOS intentan contraatacar las políticas de la Apple Store.
Lity. Nuevo lenguaje de contrato inteligente
Actualmente hay más de 1.700 aplicaciones descentralizadas (DApps) publicadas en la red Ethereum y su número sigue aumentando. Y aunque todas las Dapps se basan en contratos inteligentes, la confiabilidad de los contratos inteligentes en sí es cuestionable: los ciberdelincuentes ya han ganado más de mil millones de dólares pirateándolos.
