Corda Blockchain: Arquitectura, Desarrollo de CorDapps y Operaciones de Nodo

Qué es Corda y dónde encaja

Corda es una plataforma de registro distribuido permisionada y de código abierto, creada para redes empresariales en las que los participantes tienen identidades conocidas y estrictos requisitos de privacidad de datos. A diferencia de las blockchains públicas que replican todo el estado en cada nodo, Corda comparte los datos de las transacciones solo con las partes involucradas y sus notarios. Este diseño la hace adecuada para mercados financieros regulados, financiamiento del comercio y flujos de trabajo interbancarios donde la confidencialidad es un requisito legal y no una preferencia.

La plataforma es desarrollada por R3 y cuenta tanto con una distribución de código abierto como con una edición comercial, Corda Enterprise. Las redes Corda suelen ser operadas por consorcios: un conjunto de nodos identificados, un servicio de permisos y uno o más servicios de notario. Si está comparando Corda con infraestructura de cadena pública, las preguntas operativas difieren: se gestionan membresías, jerarquías de certificados y conectividad de red privada en lugar de endpoints RPC públicos. Para cargas de trabajo en cadenas públicas, consulte la guía de endpoints RPC multicadena.

• Membresía permisionada con identidades del mundo real y certificados X.509
• Privacidad de transacciones punto a punto en lugar de replicación global del estado
• Servicios de notario para consenso de unicidad y prevención de doble gasto
• Contratos inteligentes (CorDapps) escritos en Java o Kotlin sobre la JVM
• Diseñada para activos regulados, tokenización y flujos de trabajo interbancarios

Supuestos y requisitos previos

Esta guía asume que tiene conocimientos prácticos de desarrollo en la JVM, conceptos básicos de criptografía como firmas digitales y cadenas de certificados, y familiaridad con bases de datos relacionales. Los ejemplos utilizan convenciones de Corda 4.x, que sigue siendo la línea más ampliamente desplegada para CorDapps empresariales. Corda 5 introduce un modelo de despliegue y empaquetado diferente, por lo que debe verificar los comandos específicos de la versión en la documentación oficial para su versión objetivo.

Necesitará un JDK (se usa 17 en las compilaciones recientes de Corda 4.x), Gradle y acceso a una distribución de nodo Corda o a los artefactos de Corda Enterprise. Para el desarrollo local, el repositorio de ejemplos de Corda proporciona una plantilla de CorDapp con un wrapper de Gradle. No se requiere ningún endpoint público; los nodos Corda se comunican mediante AMQP/TLS en los puertos que configure.

El modelo mental de Corda: estados, flujos y notarios

Corda modela los hechos compartidos como estados, que son estructuras de datos inmutables que representan un acuerdo entre partes. Un estado normalmente incluye los participantes, los datos y una restricción de contrato. Las transiciones de estado son propuestas por flujos, que son programas de varios pasos que coordinan la firma, la verificación y la finalidad entre nodos. Los flujos son la unidad de lógica de negocio y el lugar donde se implementa la secuencia de pasos de recopilar firmas, verificar y registrar.

Los notarios proporcionan consenso de unicidad. Cuando un flujo consume un estado de entrada, el notario verifica que el estado no haya sido consumido ya y firma la transacción. Diferentes implementaciones de notario ofrecen distintas ventajas y desventajas: un notario de nodo único es simple pero constituye un punto único de fallo; un notario validador ve el contenido de la transacción; un notario no validador solo ve referencias de estados de entrada. Elegir un modelo de notario es una decisión arquitectónica que afecta la privacidad y la disponibilidad.

Los contratos son código de verificación determinista adjunto a los estados. Se ejecutan en cada nodo que recibe la transacción y no deben depender del tiempo real, de servicios externos ni de valores aleatorios. Este requisito de determinismo es una fuente común de errores cuando los desarrolladores portan lógica desde aplicaciones convencionales.

• Estado: hecho compartido inmutable con participantes y restricción de contrato
• Flujo: programa de coordinación de varios pasos que propone transiciones de estado
• Contrato: verificación determinista adjunta a un estado
• Notario: consenso de unicidad y prevención de doble gasto
• Transacción: propuesta firmada que consume entradas y produce salidas

Configuración de un entorno de desarrollo local de Corda

La forma más rápida de entender Corda es ejecutar la CorDapp de ejemplo localmente. Clone el repositorio de ejemplos y luego use el wrapper de Gradle para compilar y desplegar nodos. Los comandos a continuación asumen un shell tipo Unix y una instalación de JDK 17. Reemplace las rutas según sea necesario para su entorno.

La tarea deployNodes genera directorios de nodo bajo build/nodes, cada uno con su propia configuración, certificados y base de datos. Ejecutar runnodes inicia todos los nodos y el notario en ventanas de terminal separadas o procesos en segundo plano. Esta red local es suficiente para desarrollar y probar flujos antes de pasar a una red de prueba compartida o a un consorcio en producción.

git clone https://github.com/corda/samples-java.git
cd samples-java/Basic/flow-library
./gradlew clean deployNodes
./build/nodes/runnodes

Escritura y prueba de un flujo mínimo

Un flujo que emite un estado normalmente sigue cuatro pasos: construir la transacción, firmarla localmente, recopilar firmas de las contrapartes y finalizarla con el notario. El ejemplo a continuación es un esqueleto simplificado de un flujo en Kotlin. Es ilustrativo y no una CorDapp completa; los flujos de producción necesitan manejo de errores, seguimiento del progreso y resolución explícita de contrapartes.

Pruebe los flujos con los arneses MockNetwork o TestNetwork proporcionados por Corda. Estos permiten crear nodos en memoria, ejecutar flujos y verificar los estados registrados sin desplegar una red completa. Para pruebas de integración, use una red local deployNodes y dirija los flujos a través del cliente RPC del nodo.

class IssueFlow(private val state: MyState) : FlowLogic<SignedTransaction>() {
    @Suspendable
    override fun call(): SignedTransaction {
        val notary = serviceHub.networkMapCache.notaryIdentities.first()
        val tx = TransactionBuilder(notary)
            .addOutputState(state, MyContract.ID)
            .addCommand(MyContract.Commands.Issue(), ourIdentity.owningKey)
        tx.verify(serviceHub)
        val signed = serviceHub.signInitialTransaction(tx)
        val sessions = state.participants
            .filter { it != ourIdentity }
            .map { initiateFlow(it) }
        val fullySigned = subFlow(CollectSignaturesFlow(signed, sessions))
        return subFlow(FinalityFlow(fullySigned, sessions))
    }
}

Despliegue de un nodo Corda y conexión a una red

Un nodo Corda se configura mediante node.conf, que especifica el nombre legal del nodo, la conexión a la base de datos, el puerto P2P, el puerto RPC y la configuración de la zona de compatibilidad. En una red permisionada, el nodo debe obtener un certificado del doorman o del gestor de identidades de la red antes de poder realizar transacciones. El procedimiento exacto de incorporación depende de si ejecuta una zona compatible con Corda Network o una red privada de Corda Enterprise.

Para despliegues en producción, ejecute el nodo como un servicio systemd o contenedor, respalde el directorio de datos del nodo con almacenamiento duradero y use una base de datos gestionada en lugar de la base de datos H2 integrada. La interfaz RPC del nodo debe estar vinculada a una red privada y protegida con credenciales; nunca la exponga a Internet público. Si está evaluando infraestructura gestionada para otras cadenas junto con Corda, la guía de alojamiento de nodos blockchain cubre patrones operativos generales.

myLegalName = "O=Example Corp, L=London, C=GB"
dataSourceProperties = {
    dataSourceClassName = "org.postgresql.ds.PGSimpleDataSource"
    dataSource.url = "jdbc:postgresql://DB_HOST:5432/corda"
    dataSource.user = "DB_USER"
    dataSource.password = "DB_PASSWORD"
}
p2pAddress = "0.0.0.0:10002"
rpcSettings = {
    address = "0.0.0.0:10003"
    adminAddress = "0.0.0.0:10004"
}

Procedimiento de diagnóstico: verificación de la salud del nodo y ejecución de flujos

Cuando un flujo se atasca o una transacción falla, trabaje de afuera hacia adentro: confirme que el proceso del nodo está en ejecución, confirme que la conexión RPC funciona y luego inspeccione el progreso del flujo y los registros del nodo. El siguiente procedimiento utiliza la interfaz RPC del nodo a través de un pequeño script cliente. Reemplace RPC_HOST, RPC_PORT y las credenciales con los valores de su nodo.

Primero, verifique que el nodo sea accesible y que la identidad esté registrada. Luego enumere los flujos en curso e inspeccione el registro del nodo en busca de excepciones. Un modo de fallo común es un flujo que espera indefinidamente la firma de una contraparte porque el nodo de la contraparte está fuera de línea o la sesión del flujo no se estableció. Otro es un rechazo del notario debido a un doble gasto o a un estado de entrada desconocido.

import net.corda.client.rpc.CordaRPCClient
import net.corda.core.utilities.NetworkHostAndPort

fun main() {
    val client = CordaRPCClient(NetworkHostAndPort("RPC_HOST", 10003))
    client.start("RPC_USER", "RPC_PASSWORD").use { connection ->
        val proxy = connection.proxy
        println("Node identity: " + proxy.nodeInfo().legalIdentities)
        println("Registered flows: " + proxy.registeredFlows())
        println("Network size: " + proxy.networkMapSnapshot().size)
    }
}

Resultados de verificación esperados

Tras un despliegue local exitoso, runnodes debería iniciar el notario y los nodos de las partes sin errores de certificado, y el cliente RPC debería imprimir la identidad legal del nodo y un mapa de red no vacío. Una ejecución de flujo exitosa debería producir una transacción firmada visible en la bóveda del nodo y una entrada correspondiente en el almacenamiento de transacciones. Si está probando un contrato, una transacción deliberadamente inválida debería ser rechazada en el paso de verificación con una violación de la restricción del contrato.

Registre sus propias mediciones de referencia en lugar de confiar en cifras publicadas. Una tabla simple de resultados que puede completar después de ejecutar el procedimiento:

• | Comprobación | Comando u observación | Resultado esperado |
• | Proceso del nodo | systemctl status corda o estado del contenedor | En ejecución, sin bucle de reinicio |
• | Conectividad RPC | Llamada nodeInfo() del cliente RPC | Devuelve identidades legales |
• | Mapa de red | networkMapSnapshot().size | Coincide con el número esperado de participantes |
• | Finalización del flujo | Consulta a la bóveda del estado emitido | Estado presente con los participantes correctos |
• | Rechazo del contrato | Enviar transacción inválida | Excepción de verificación, ningún estado registrado |

Solución de problemas comunes de Corda

Errores de certificado e identidad suelen significar que el certificado del nodo no coincide con la raíz de confianza de la red o que el nombre legal en node.conf difiere del sujeto del certificado. Regenerar los certificados del nodo a través del proceso del operador de la red en lugar de editarlos manualmente.

Fallos de conexión a la base de datos a menudo provienen de controladores faltantes, URL JDBC incorrectas o desajustes en la migración del esquema tras una actualización. Ejecute la herramienta de migración del nodo contra una copia de seguridad primero y verifique que el usuario de la base de datos tenga los privilegios necesarios.

Tiempos de espera de flujos y sesiones atascadas indican que una contraparte no es accesible o que un flujo está esperando una respuesta que nunca llegará. Verifique la conectividad P2P entre nodos, confirme que ambos nodos estén en versiones compatibles de Corda e inspeccione la salida del rastreador de progreso del flujo. Para patrones de confiabilidad más amplios, consulte la guía de confiabilidad y consistencia de RPC.

• Discrepancia de certificado: verifique el nombre legal y la raíz de confianza
• Errores de base de datos: compruebe el controlador, la URL y el estado de la migración
• Flujos atascados: confirme la accesibilidad de la contraparte y la compatibilidad de versiones
• Rechazo del notario: inspeccione el historial de consumo del estado de entrada
• Fallo del contrato: revise el determinismo y las restricciones de los adjuntos

Limitaciones y compensaciones

El modelo de privacidad de Corda es una fortaleza para las redes reguladas, pero una limitación para los casos de uso que requieren verificabilidad pública o participación sin permisos. Dado que los datos de las transacciones se comparten solo con las partes involucradas, un observador externo no puede auditar de forma independiente el libro mayor completo sin acceso. Esto es intencional, pero significa que Corda no es un reemplazo directo de la transparencia de una cadena pública.

Operativamente, las redes Corda requieren coordinación: incorporación de miembros, rotación de certificados, selección de notarios y actualizaciones de versión entre los participantes. Estas son tareas de gobernanza tanto como técnicas. El rendimiento y la latencia dependen de la configuración del notario, el rendimiento de la base de datos y la topología de la red, por lo que debe medir su propio despliegue en lugar de asumir que las cifras publicadas se aplican.

Corda 5 representa un cambio arquitectónico significativo hacia un modelo de despliegue empaquetado y nativo de contenedores. Los equipos que planifican redes de larga duración deben considerar la planificación de la migración y las ventanas de soporte de versiones en sus decisiones de arquitectura.

Próximos pasos e infraestructura relacionada

Una vez que su CorDapp se ejecute localmente, los siguientes pasos son unirse a una red de prueba, reforzar la configuración del nodo y establecer monitoreo para fallos de flujos y salud de la base de datos. Para equipos que operan entornos multicadena junto con Corda, OnFinality proporciona infraestructura RPC gestionada para redes públicas; revise las redes compatibles y los precios de RPC para planificar la capacidad. Los nodos dedicados están disponibles a través del servicio de nodos dedicados para cargas de trabajo que necesitan recursos aislados, y el servicio de API cubre patrones de acceso gestionado. Para la selección de endpoints en cadenas públicas, consulte a RPC Assistant en lugar de asumir que un único proveedor se adapta a todas las redes.