Desarrollo de CorDapps: Introducción

15744044622_9451e331b5_b.jpg

Imagen de Flavio Ricci

Tenía muchas ganas de traer este tema por el blog y de compartir con vosotros esta nueva temática que se distancia del Frontend y de JavaScript durante un tiempo. Como muchos ya sabréis, durante los últimos meses, me encuentro trabajando activamente para comprender ciertos conceptos sobre blockchain y el desarrollo de aplicaciones distribuidas.

Mi conocimiento todavía es muy limitado comparado con el de mis compañeros, pero sí he podido investigar y probar pequeñas cosas que me han aportado bastante comprensión. Durante las próximas semanas, quería hablaros sobre una tecnología que se encuentran desarrollando varias empresas del sector financiero dentro del abanico del R3.

El R3 es un consorcio fundado por varias empresas del sector preocupadas en conseguir desarrollar servicios, productos y soluciones de forma distinta a la que se hace hoy en día. La idea surge de poder usar toda la potencia de los blockchain actuales y conseguir un marco de trabajo que ayude a crear casos de uso del mundo real que escalen y sean productivos para los desarrolladores.

El mundo blockchain se encuentra en plena efervescencia y mientras el ‘hype’ inicial empieza a calmarse, el estado actual de las compañías es el de encontrar herramientas que generen un ecosistema maduro.

Corda y las CorDapps nacen con esta idea, nacen como una forma de ayudar a los desarrolladores a crear aplicaciones financieras de una manera diferente, aprovechándose al máximo de las técnicas de blockchain, pero intentando que escalen y puedan ser útiles.

El conocimiento que he sacado de Corda y las CorDapps puede que te ayude en encontrar soluciones distribuidas en tu día a día aunque no te dediques a desarrollar aplicaciones financieras, por lo que te invito a que sigas conmigo en lo que, por ahora, serán 6 posts que explicarán cómo empezar a desarrollar CorDapps con Corda:

¿Qué es una CorDapp?

La creación y exposición de APIs ha supuesto una forma bastante productiva de compartir información entre diferentes entes, ya fuesen otras empresa o usuarios finales. La API es el estándar para comunicar información y permitir realizar acciones de manera automatizada.

El que por medio de HTTP podamos exponer al mundo nuestro dominio de trabajo, es una buena manera para conseguir nuevas oportunidades de negocio y supone la posibilidad de explotar una ingente cantidad de datos que hasta ahora no tenían un uso claro.

Las empresas que mejor han sabido explotar las capacidades de las APIs han sido aquellas que mayor crecimiento han tenido en los últimos años y empresas como Google, Facebook o Amazon han favorecido mucho a esa cultura de ‘apificar’ el negocio.

Sin embargo, a lo largo de los años, nos hemos dado cuenta que las APIs – ya sean públicas o privadas – no han sido la panacea que nos prometían. La forma de diseñar APIs y los protocolos sobre los que se ha asentado la forma de comunicarse, no se han estandarizado del todo y están suponiendo problemas en instituciones que necesitan un alto número de interacciones con empresas de todo el mundo.

Uno de estos problemas se ha detectado dentro de la forma en que las empresas gestionan sus acuerdos financieros con otros proveedores y clientes. Por lo general, las APIs han escalado tan mal que hemos conseguido crear sistemas muy acoplados que no son fáciles de mantener.

Por tanto, lo que hasta ahora estaba pasando es algo muy parecido al siguiente diagrama:

Captura de pantalla de 2017-02-27 15-02-49.png

 

Cuando dos entidades necesitan compartir información, contratos o identidades entre ellas, se han estado creando APIs específicas para cada una de estas problemáticas. Como cada banco o entidad tiene sus propias formas de funcionar, el contrato de la API se convierte en algo poco reutilizable.

Lo que provoca esto es algo inmanejable. Si para cada banco o entidad con el que necesito compartir contratos yo tengo una API específica, tengo un montón de sistemas parecidos que comparten información parecida, pero con protocolos y flujos de funcionamiento totalmente diferentes. No existe estandarización, no existe reutilización de componentes.

Que bueno sería que en vez de solo comunicarnos, pudiésemos colaborar con otras entidades de una forma más transparente, donde existiera un estándar y donde todas las entidades se encontrasen interconectadas en una misma red donde los acuerdos y la información se compartiera por medio de unas reglas pactadas entre todas las partes implicadas: Esto es lo que se proponen las CorDapps.

demo-1.png

Una CorDapp es una tecnología desarrollada por el R3 para crear aplicaciones distribuidas orientadas al mundo financiero – veremos a lo largo de la serie que el framework es bastante genérico como para usarse para un propósito más general.

Las CorDapps se encuentran desarrolladas con el framework creado por el R3 llamado Corda. Corda es una herramienta que cuenta con todo lo necesario para desarrollar aplicaciones web que hemos visto en nuestro día a día. Corda nos permite:

  • Crear Smart Contracts.
  • Exponer APIS para poder hacer uso de nuestros Smar Contracts.
  • Exponer ficheros estáticos para servir frontales que hagan más usable nuestros servicios expuestos.
  • Testear todas estas pieza de código por medio de herramientas de testing.
  • Comunicarnos con otros nodos de la red.
  • Desplegar y configurar nuevos nodos.
  • Persistir información que no tenga que encontrarse guardada en nuestra ledger distribuida.
  • Securizar toda aquella información que sea critica dentro del sistema dentro del sistema de transacciones.
  • Ofrecer un sistema de descubrimiento y orquestación de APIS, nodos y servicios.
  • Automatizar un proceso de consenso de confirmación .

Las CorDapps por lo tanto, no son más que una manera de hacer aplicaciones distribuidas modularizables. Cada CorDapp cuenta con una responsabilidad muy especifica que puede ser útil por si misma.

Las CorDapps pueden estar compuesta a su vez por otras CorDapps que extienden el funcionamiento y emplian el negocio sobre el que pueden trabajar. Es un sistema de plugins muy parecidos a los de otras plataformas.

La idea es que en el futuro estas CorDapps se puedan descargar y consumir en un gran repositorio como el de NPM o Maven para favorecer la reutilización y la compartición dentro de la comunidad.

Y decimos comunidad porque Corda y las CorDapps son un proyecto Open Source donde cualquier desarrollador puede aportar al core del framework.

Actualmente los casos de uso que se están encontrado para un framework como Corda son estos:

  • Gestión de identidades personales y corporativas que ayuden en los procesos de onboarding.
  • Gestión de acuerdos internacionales entre diferentes entidades o participantes como puedan ser cartas de crédito, hipotecas, alquileres, préstamos o acuerdos de bienes materiales.
  • Gestión y trazabilidad de información sensible que pueda ayudar en procesos de auditoria y como mediador de disputas.
  • Gestión automatizada de procesos que requieren un sistema de notaría.
  • Gestión del registro de bienes e inmuebles para saber el ciclo de vida por el que pasa un producto desde su construcción, hasta su distribución y venta posterior.
  • Gestión de activos con coste monetario.
  • Gestión de comisiones y pagos.

Pero cada día se encuentran otros nuevos.

¿Pero esto no es un blockchain?

¿Smart Contracts? ¿Ledger? ¿Nodos? ¿Seguridad? ¿Transacciones? Si has investigado sobre blockchain, todos estos términos te sonarán bastante.

Una de las críticas que suele recibir la plataforma es que Corda se suele vender como un blockchain creado para la banca moderna, pero cargándose todos los principios éticos de los blockchain.

Sin embargo, Corda no se describe a si misma como un blockchain y sí más bien como una plataforma que permite desarrollar aplicaciones distribuidas por medio de técnicas usadas en el blockchain. Por lo que, ni ellos mismos se definen como un blockchain al uso.

Para poner un poco de luz sobre esto, vamos a explicar ciertos conceptos que suelen darse en los blockchain y explicaremos cuáles de ellos cumple y cuáles no y su por qué:

Corda es una red P2P

Corda se comporta como una red Peer to Peer. Es decir, dentro de una red, donde hay nodos conectados, el nodo A puede hacer peticiones al nodo B y el nodo B puede hacer peticiones al nodo A sin problemas.

No existe un nodo dentro de la red que represente un control sobre el resto. Corda no es una red Maestro/Esclavo, sino que todos los nodos integrantes cooperan los unos con los otros.

Las redes en Corda suelen ser privada y controladas, es decir, ningún nodo puede sindicarse de manera anónima y todos tienen que cumplir con los certificados y las claves necesarias para operar en una red de Corda determinada.

Esto difiere de las redes blockchain convencionales que, aunque también tratan sobre una red P2P, suelen tener una naturaleza más pública, donde en cualquier momento podemos desplegar un nodo en la red sin consentimiento de ningún nodo intermedio.

La topología de ambas redes también puede variar un poco de unos a otros blockchains. Mientras en el resto de blockchain contamos con una topología parecida a esta:

disorganized-network-1.png

Descentralizado

En Corda presentamos más una topología como esta:

descarga (3).png

Bus

Como todo, depende del blockchain que analicemos – esto es demasiado genérico -, pero creo que el ejemplo es bastante claro.

Corda mantiene una DLT

Una DLT son las siglas de Distributed Ledger Technology. La clave de todo blockchain es poder gestionar una ledger. Una ledger es una estructura de datos que permite almacenar estados inmutables en bloques que se encadenan los unos con los otros.

Dentro de una ledger – o libro de cuentas en castellano – se almacenan aquellas transacciones que son importantes para el negocio. Yo podría saber el estado en cada momento del sistema simplemente con trazar esta estructura de datos.

En la mayoría de blockchain, este estado del sistema es almacenado de forma distribuida, es decir, todos los nodos que componen una red tiene una copia exacta de este estado. Esto provoca que si un nodo de la red se caiga, la red no sufra perdidas de información ya que se mantienen N copias exactas.

En Corda existe la ledger como núcleo principal de la tecnología, pero no existe una ledger distribuida. Es descentralizada. Es decir, cada nodo no tiene una copia exacta de la ledger, sino que cada nodo, almacena aquellas transacciones que le involucran en un tratado. Si un nodo de Corda cae, solo se caerían las transacciones que le implican a ese nodo. Pero no podríamos restablecer todo el sistema a partir de un solo nodo.

Esto tiene sentido ya que Corda es una red privada y controlada, donde solo queremos compartir aquello que no nos queda más remedio. Este sistema escala mejor, pero supone un problema a nivel de uno de los principios básicos del blockchain que trata sobre descentralizar el poder de decisión de una red.

Corda gestiona Smart Contracts

Una de las novedades que aportan los blockchain a nivel tecnológico es la posibilidad de poder ejecutar pequeños paquetes de código sobre un modelo determinado en una red distribuida. Es decir, yo genero una lógica de negocio que el sistema sabe serializar y deserializar y distribuir por la red para ser ejecutado en el momento que necesitemos.

Esta lógica se usa para comprobar el estado de una transacción y verificar que se está generando una entidad, modelo u objeto consistente con lo que la red ha pactado.

En Corda existe este concepto. Es la mayor abstracción de su sistema y es una forma de crear modelos con una serie de verificación pactadas por los participantes de un convenio en particular. Estos Smart Contract son los que deciden si algo puede ser almacenado en la ledger o no.

Corda tiene un sistema de transaccionariado basado en el consenso

El consenso en una red blockchain es una forma de decidir dentro de una red y de manera democrática que una transacción es valida para ser confirmada en la ledger.

En la mayoría de blockchain, este consenso tiene que conseguir la aprobación de la mitad + 1 uno de nodos de la red.  En Corda, el consenso cambia y solo tiene que conseguirse el consentimiento de las partes involucradas en una transacción – por ejemplo el Banco A y el Banco B – y de un nodo que hace de árbitro dentro de la red denominado el Notario – Hablaremos del notario en próximos posts de la serie.

Es uno de los problemas y encrucijadas en los que se encuentra Corda y todos los blockchain en su día a día. El consenso es un tema de debate entre la comunidad. El consenso el que permite que un nodo no coja demasiado poder dentro de una red, el problema es que en consenso muy democrático, el sistema no escala muy bien.

Por lo general, en una red con consensos democráticos una transacción tarda unos 11 segundos en ser confirmada.  Estos tiempos no son asumibles en muchos sistemas del mundo real. Si el consenso lo hacemos mas selecto, ganamos en escalabilidad porque solo deciden los nodos participantes, pero los nodos tienen demasiado poder.

Como todo, dependerá del contexto, pero para un sistema bancario donde se reciben tantas transacciones por segundo, el consenso es algo importante.

Corda securiza sus transacciones

Si hemos dicho que estamos exponiendo información entre varios nodos, necesitamos que una transacción que ha sido confirmada, no pueda se rmanipulada. Es por eso que todas las transacciones son firmadas por los nodos. De esta manera tenemos una forma de saber quién y cómo ha guardado una transacción.

Además cuenta con algoritmos de encriptado sobre los datos insertados que hace que si una transacción se ha manipulado, tanto en tiempo de confirmación como en tiempo de custodia, el sistema pueda verificar que es bueno y que malo.

Tanto Corda como otros blockchain cuentan con sus sistemas de seguridad y encriptación.

En Corda no existe minado de bloques

Como hemos dicho, estos sistemas de blockchain suponen un consumo de recursos de cómputo – para confirmar y verificar transacciones – y de espacio – para guardar la ledger – bastante grande. Por lo tanto, estás redes suelen recompensar a los nodos con dinero por cómputo. Es lo que se suele llamar el minado de bloques.

En Corda, debido a que no tenemos estos problemas de escalabilidad no se necesitan estos incentivos en la red. Por lo que nos ahorramos. Otro punto por el que se cuestiona que Corda sea un blockchain.

También hay redes como Ethereum que penaliza a transacciones que consumen demasiado cómputo, de esta manera es más difícil hackear el sistema con bucles infinitos o ataques para generar tráfico o cómputo innecesario.

En Corda no existe una criptomoneda como tal

Los sistemas blockchain más famosos como Bitcoin o Ethereum, han tenido una gran repercusión por ser sistemas donde se gestiona monedas propias descentralizadas y sin control de entidades privadas. La propia red es la que sirve de reguladora.

Corda no tiene como finalización la gestión de nuevas monedas. Podemos gestionar tratados monetarios y llevar ciertos procesos de contabilidad, pero siempre como utilidad para que el contrato se lleve a buen puerto, por tanto, la criptomoneda no es uno de sus puntos fuertes.


Como vemos, no es un blockchain al uso, su sistema de consenso le desacredita mucho como un sistema donde el poder está totalmente descentralizado. Sin embargo, hay potencial a la hora de desarrollar aplicaciones con Corda. Nos facilita el trabajo para muchas acciones.

Una de las críticas que más recibe es la de que cualquier aplicación que ya se encuentra en el mercado podría presentar estas funcionalidades con unos cuantas mejoras de seguridad en nuestras bases de datos y un poco de cambio en la manera de comunicarse entre los sistemas. Puede que sea cierto.

Pero es bueno aprender sobre sus propuestas y ver cómo están gestionando diferentes conceptos como son el transaccionariado, los Smart Contracts o los flujos de comunicación.

¿Con qué tecnología se desarrolla una CorDapp?

Kotlin como lenguaje de programación

original.png

Las CorDapps pueden ser desarrolladas con código Java. Una CorDapp se ejecuta en la Máquina Virtual de Java y por tanto Java podría ser un buen lenguaje para crear CorDapps.

Sin embargo, los desarrolladores de Corda nos recomiendan hacer uso de Kotlin. El propio Corda se encuentra desarrollado por medio de Kotlin, por lo que crear aplicaciones con este lenguaje no es descabellado.

La selección de este lenguaje viene meditada por la naturaleza funcional del lenguaje. Gestionar una ledger es una manera de trabajar con la persistencia de estados inmutables, por lo tanto un lenguaje que pueda evitar los efectos laterales, puede ayudarnos a cometer menos errores en las CorDapps.

El uso de funciones puras y la transparencia referencial, van a ser un factor denominantes si necesitamos comprobar la verificación de los contratos dentro de los diferentes participantes de una transacción, por lo que Kotlin, me parece una buena elección dentro del ecosistema Java.

Las CorDapp necesitan de un rendimiento de ejecución elevado debido al tipo de información que se está intercambiando, por lo que la preferencia de Kotlin sobre Scala viene por los tiempos de los que dispone una y otra.

Lo bueno de encontrarnos en este ecosistema es que la interoperabilidad es la que se presupone y si en cualquier momento necesitamos una librería que se encuentra desarrollada en Java, podremos hacer uso de ella sin problema.

Kotlin está desarrollado por la gente de JetBrains por lo que la calidad y la mantenibilidad a largo plazo está asegurada. Creemos que es una buena elección dentro de las posibilidades que había.

Comunicación interna por medio de colas

activemq-logo.png

Otras tecnologías con las que trabaja Corda es con Artemis. Artemis es una librería que nos permite realizar comunicaciones por medio del protocolo AMQP. De esta manera podemos trabajar de manera asíncrona. Corda se encargará de gestionar toda estas comunicaciones y nos abstrae por medio de clases y métodos específicos. Los veremos más adelanto en el posts de flujos.

Exposición de APIS por medio de Jersey

descarga-1

Además de comunicación interna entre diferentes nodos de la red de colaboración que se crea. También se pueden exponer servicios para permitir a frontales y servicios de terceros a hacer uso de nuestra CorDapp. Corda tiene como dependencia Jersey como manejador de enrutamiento HTTP, pero no sería muy complicado usar la herramienta que más prefiramos.

Persistencia de entidades por medio de Hibernate

hibernate.png

Puede que necesitemos cierta información que no queramos compartir con el resto de nodos participantes de la red, tanto por regulaciones o por estrategia esto es un caso que puede darse.

Podríamos montar un sistema de persistencia a nuestro gusto, pero Corda ya cuenta con soporte y ciertos módulos para trabajar sobre Hibernate de una forma bastante rápida e intuitiva.

Para quien no lo sepa, Hibernate es un ORM que nos va a permitir ‘mapear’ una base de datos relacional en un modelo de objetos. Su uso está muy extendido en la mayoría de sistemas modernos y se presenta como una gran opción por su rendimiento y prestaciones.

Almacenamiento de la DLT en una base de datos H2

h2-logo-2

La ledger descentralizada que comparten todos los nodos de una red es almacenada en una base de datos SQL de Java llamada H2. Es un proyecto Open Source y su uso es totalmente transparente para nosotros, pues la forma en la que se almacena la información en esta ledger supone el núcleo central del framework y la parte que más han querido abstraerse del desarrollo.

Soporte para cualquier tipo de frontal

descarga (2).png

Si nuestra CorDapp precisa de un frontal para su correcto funcionamiento, podremos usar la tecnología que precisemos. Corda lo único que se va a preocupar es de servir los estáticos que hayamos indicado, el trabajo de front se delega al desarrollador.

Conclusión

Como vemos, todo un mundo esto de las CorDapps y sus posibles usos. Hemos hablado de muchos conceptos complejos que en los próximos años serán claves para entender las aplicaciones que desarrollamos.

A lo largo de esta serie, te ayudaremos a desarrollar en Corda y a realizar CorDapps que puedan ser útiles para tu empresa o tus clientes. Los siguiente posts se centran en enseñarte cómo poder empezar, y a explicar aquellos conceptos clave del framework.

Si os habéis quedado con ganas de más, este artículo os podrá ayudar.

Por ahora creo que es buen momento para que lo dejemos.

Nos leemos 🙂

Capítulos de la serie ‘Desarrollo de CorDapps’:

  • Desarrollo de CorDapps: Introducción
  • Desarrollo de CorDapps: Cómo empezar
  • Desarrollo de CorDapps: Los contratos
  • Desarrollo de CorDapps: Las transacciones
  • Desarrollo de CorDapps: Los flujos
  • Desarrollo de CorDapps: Los nodos
Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s