es un libro mayor distribuido para almacenar, gestionar y sincronizar obligaciones financieras entre diversas organizaciones financieras.
Corda tiene una documentación bastante buena con video-lecciones, que se puede encontrar . Intentaré describir brevemente cómo está estructurado Corda por dentro.
Analicemos las características principales de Corda y su singularidad entre otras blockchain:
- Corda no tiene su propia criptomoneda.
- Corda no utiliza el concepto de minería ni el sistema de Prueba de Trabajo.
- La transmisión de datos ocurre solo entre los participantes de la transacción / contrato. No hay una difusión global a todos los nodos de la red.
- No hay un controlador central que gestione todas las transacciones.
- Corda admite diversos mecanismos de consenso.
- El consenso se logra entre los participantes a nivel de acuerdo / contrato individual, no a nivel de todo el sistema.
- La transacción es confirmada solo por los participantes involucrados.
- Corda ofrece una conexión directa entre el lenguaje jurídico humano formal y el código de los contratos inteligentes.
El libro mayor
El concepto de libro mayor en Corda es subjetivo. No hay un único almacenamiento central de datos. En su lugar, cada nodo mantiene una base de datos separada de los hechos que conoce.
Por ejemplo, imagina una red de 5 nodos, donde un círculo es un hecho conocido por ese nodo.
Como podemos ver, Ed, Carl y Demi conocen el hecho 3, mientras que Alice y Bob ni siquiera lo sospechan. Corda garantiza la conservación de hechos comunes en la base de cada nodo, asegurando que los datos sean idénticos.
Estados
El estado es inmutable un objeto que representa un hecho conocido por uno o varios nodos de la red en un momento determinado.
Los estados pueden almacenar datos arbitrarios, como acciones, bonos, créditos, información de identificación.
Por ejemplo, el siguiente estado representa un IOU: un acuerdo de que Alice le debe a Bob una cantidad X:
El ciclo de vida de un hecho a lo largo del tiempo se representa como una secuencia de estados. Cuando es necesario actualizar el estado actual, creamos uno nuevo, y marcamos el actual como histórico.
Transacciones
Las transacciones son propuestas para actualizar el libro mayor. No se transmiten a todos los participantes del libro mayor y son accesibles solo para aquellos participantes de la red que tienen derecho legítimo a verlas y gestionarlas.
Una transacción se añadirá al libro mayor si:
- contractualmente válido
- firmado por todos los participantes necesarios
- no contiene gastos dobles (double-spends)
Corda utiliza un modelo UTXO (unspent transaction output), donde cada estado del ledger es inmutable.
Al crear una transacción, se pasa el output del estado de la transacción anterior (por hash e índice).
Ciclo de vida de la transacción:
- Creación (En este momento, la transacción es solo una propuesta para actualizar el ledger)
- Recopilación de firmas (Los participantes necesarios de la transacción aprueban la propuesta de actualización añadiendo su firma a la transacción)
- Compromiso de la transacción en el ledger
Después de añadir la transacción al ledger, los estados de entrada se marcan como históricos y no pueden ser utilizados en transacciones futuras.
Además de los estados de entrada y salida, la transacción puede contener:
- Comandos (parámetro de la transacción que indica el objetivo de la transacción)
- Adjuntos (calendario de festividades, conversor de divisas)
- Ventanas temporales (plazos de validez)
- Notario (Notary, participantes especiales de la red que validan transacciones)
Contratos
Cuando hablamos de la validez de una transacción, nos referimos no solo a la presencia de las firmas necesarias, sino también a la validez por contrato. Cada transacción está relacionada con un contrato que la acepta y valida los estados de entrada y salida. La transacción se considera válida solo si todos sus estados son válidos.
Los contratos en Corda se escriben en cualquier lenguaje de JVM (por ejemplo, Java, Kotlin).
class CommercialPaper : Contract {
override fun verify(tx: LedgerTransaction) {
TODO()
}
}
Es necesario heredar de la clase Contract y sobreescribir el método verify. En caso de que la transacción no sea válida, se debe lanzar una excepción.
La validación de transacciones debe ser determinista, es decir, el contrato siempre debe aceptar o rechazar la transacción. Debido a esto, la validez de la transacción no puede depender del tiempo, números aleatorios, archivos del nodo de la red, etc.
En Corda, los contratos se ejecutan en lo que se llama una sandbox: una JVM ligeramente modificada que garantiza la ejecución determinista de los contratos.
Hilos
Para automatizar la comunicación entre los nodos de la red, se añadieron flujos.
Un flujo es una secuencia de pasos que indica al nodo cómo realizar una actualización específica del ledger, en qué momento se debe firmar y validar la transacción.
A veces se requieren horas o incluso días para que una transacción sea firmada por todas las partes y se registre en el libro contable. ¿Qué sucederá si se desconecta un nodo que participa en la transacción? Los flujos tienen puntos de control donde el estado del flujo se guarda en la base de datos del nodo. Al restaurar un nodo en la red, continuará desde el punto donde se detuvo.
Consenso
Para que una transacción llegue al libro contable, debe alcanzar dos consensos: sobre su validez y sobre su unicidad.
La decisión sobre la validez de la transacción solo la toman las partes directamente involucradas en ella.
Los nodos notariales realizan la verificación de la unicidad de la transacción, previniendo el gasto doble.
Imaginemos que Bob tiene $100, y quiere transferir $80 a Charlie y $70 a Dan, usando el mismo estado de entrada.
Tal truco no será posible en Corda. Aunque la transacción pase la verificación de validez, la verificación de unicidad fallará.
Conclusión
La plataforma Corda, desarrollada por el consorcio de blockchain R3, no es un ejemplo puro del uso de la tecnología blockchain. Corda es una herramienta bastante especializada para organizaciones financieras.
Fuente: habr.com
