Cómo funciona el servidor de nodos Hiero y cómo la red Hedera procesa las transacciones

Si has seguido aunque sea brevemente el mercado de redes descentralizadas, probablemente hayas escuchado sobre la red Hedera. Durante mucho tiempo, su motor permaneció como código comercial cerrado con una licencia específica. La situación cambió cuando el proyecto pasó bajo el paraguas de la Linux Foundation y recibió el nombre de código abierto Hiero.

El código fuente del nodo de consenso, escrito en Java, está disponible en el repositorio hiero-consensus-node. Este es el servicio exacto que acepta solicitudes gRPC, ejecuta transacciones a través del consenso DAG y ejecuta contratos inteligentes.

Qué hay dentro del monorrepositorio

El código se divide en dos módulos hijos principales:

• platform-sdk/ — el nivel inferior de la plataforma. Maneja las conexiones de red entre nodos, el algoritmo de consenso y el almacenamiento persistente del estado de la red.
• hedera-node/ — la capa de aplicación. Contiene servicios para cuentas, tokens, archivos y ejecución de código EVM.

La división es lógica. La plataforma maneja el trabajo matemático pesado del consenso distribuido, mientras que el módulo de aplicación convierte ese consenso en una API conveniente para los desarrolladores.

Servicios, Protobuf y Solidity

La comunicación cliente-a-nodo está construida sobre el protocolo gRPC. Toda la especificación está definida en esquemas Protobuf separados. A través de estos protocolos, el nodo maneja tareas centrales:

• Tokenización (HTS). Permite emitir y transferir tokens sin escribir contratos inteligentes.
• Registro de consenso (HCS). Permite registrar marcas de tiempo y mensajes en un libro mayor distribuido.
• Contratos inteligentes. Una máquina virtual EVM se ejecuta dentro del nodo, soportando el compilador Solidity con la directiva pragma solidity <=0.8.9.

El soporte de la versión de Solidity está actualmente limitado a la versión 0.8.9. Para contratos estándar de OpenZeppelin o lógica de negocio típica, esto es suficiente, aunque no podrás acceder a las últimas características del lenguaje todavía.

Infraestructura y calidad del código

El repositorio revela inmediatamente sus orígenes corporativos. No hay ninguno del caos típico de las utilidades pequeñas de código abierto. Los pipelines de CI/CD incluyen pruebas de rendimiento diarias (Single Day Performance Tests) y pruebas de resistencia de larga duración (Longevity Tests).

El proyecto está certificado bajo los estándares OpenSSF Scorecard y CII Best Practices, y la cobertura de pruebas se rastrea a través de Codecov.

Por otro lado, la sección de issues tiene más de mil quinientas tareas abiertas. Esto es normal para sistemas grandes que han pasado a código abierto, pero los nuevos desarrolladores necesitarán invertir tiempo en entender cómo está estructurado el proyecto.

Por dónde empezar a aprender

El proyecto está construido con Gradle. Para ejecutarlo localmente, necesitarás una versión reciente de Java y suficiente RAM.

Si quieres profundizar en los detalles de la arquitectura, es útil consultar la documentación:

• La carpeta hedera-node/docs/design/ contiene diagramas arquitectónicos y decisiones de diseño de servicios.
• La documentación en platform-sdk/docs/ describe la estructura interna de la plataforma de consenso en sí.

A quién le será útil este proyecto

Para un desarrollador Web3 típico que solo necesita emitir un token o desplegar una dApp, ejecutar tu propio nodo no es necesario. Es mucho más simple usar SDKs listos para usar en tu lenguaje de programación preferido.

Este repositorio es principalmente interesante para equipos de ingeniería. Aquellos que diseñan sus propias redes empresariales basadas en la tecnología Hashgraph, investigan la tolerancia a fallas BFT asíncrona, o estudian sistemas Java de alta carga. El código contiene buenos ejemplos de optimización de memoria y estructuración de servicios gRPC para alta carga.