Oracle Blockchain Cloud Service (OBCS)

Hace ya varios meses que Oracle amplió su oferta cloud con esta nueva tecnología. Pero ha costado un poco encontrar el enfoque para escribir este post. Tratar la arquitectura sería el principio más lógico, pero un enfoque técnico (un ejemplo quizás) sería más entretenido. Posiblemente no sea suficiente un post para desvelar por qué esta tecnología es tan interesante  y justificar el interés de Oracle para incorporarlo a su oferta cloud. La conclusión ha sido empezar con un poco de difusión antes de entrar en aspectos técnicos. Así que vamos a introducir diferentes aspectos alrededor de la tecnología blockchain enfocados a desvelar qué puede aportar al escenario tecnológico empresarial actual, su utilidad, así como algunas consideraciones sobre su diferenciación respecto otras tecnologías. Empezamos.

 

¿Qué es un blockchain?

Para ayudarnos a entender qué es un blockchain, es conveniente introducir previamente un par de conceptos. En primer lugar, el concepto “ledger”. De sobra conocido para aquellos que estén familiarizados con la contabilidad, y que tiene fuerte influencia en la manera de trabajar de determinados ERP, que organizan sus flujos de información en torno al concepto de movimiento de entrada/salida (o de partida/contrapartida más exactamente),  un ledger equivale a un libro contable. A un libro mayor, concretamente.

Esta es la imagen con la que me gustaría que nos quedáramos. Un libro que sigue el principio de la partida doble. Un libro en el que, a partir de un estado inicial, se registran todos los movimientos, dejando traza en su origen y en su destino, de manera que a final de ejercicio cada concepto que aparecía en la situación inicial ha tenido una serie de movimientos plenamente justificados (su blockchain) que reflejan un saldo (su estado final/balance) o ha quedado saldado.

 

Segundo concepto: DLT (Distributed Ledger Technologies). Si nos imaginásemos la transformación digital de ese libro mayor (ledger) a nivel empresarial (multiusuario, multiempresa, globalizado, securizado y veraz) posiblemente llegaríamos a algo similar a que un DL (Distributed Ledger) es un tipo de estructura de datos que reside en múltiples dispositivos, distribuidos en diferentes ubicaciones y/o regiones (la nube).

 

Las DLT incluyen tecnologías blockchain y contratos inteligentes (smart contracts). Es decir, no son sólo estructuras de datos distribuidas, sino que también establecen unas “reglas de juego”, que se aplican según protocolos peer-to-peer (no hay un servidor central que controle todo).
Las DLT existían antes de Bitcoin, pero fue su blockchain el que hizo converger una serie de elementos (computación distribuida, transacciones con timestamp, redes P2P, criptografía y un nuevo algoritmo de consenso) que daría lugar a tres principales características definitorias de un DLT:

  • Un modelo de datos que refleja el estado actual del ledger.
  • Un lenguaje de transacciones para cambiar el estado del ledger.
  • Un protocolo que permite consensuar entre los participantes en la red del DLT, qué transacciones serán aceptadas y en qué orden (su nuevo estado).

 

Según Oracle, las principales características de un blockchain son:

  • Base de datos distribuida del tipo Clave-Valor
  • Compartida, transparente y descentralizada
  • Sin punto único de
  • Inmutable e Irreversible
  • Encriptado
  • Ecosistema cerrado
  • Velocidad en Casi Tiempo real

 

Más formalmente, entenderemos por blockchain una base de datos distribuida del tipo clave-valor, que permite a una comunidad compartir un DLT unificado, sobre el que realizar transacciones de manera rápida y segura. Cada miembro controla sus datos mediante una clave privada que le identifica y no existe supervisión por parte de una autoridad central ya que las transacciones se verifican de manera distribuida por los miembros mediante algoritmos de consenso. La red no tiene puntos críticos de fallo, por lo que las entidades pueden aparecer, desaparecer e incluso funcionar mal, sin llegar a perjudicar al blockchain en su totalidad.

 

La necesidad de blockchain

Es interesante distinguir entre utilidad y necesidad. Uno de los primeros ejemplos de aplicación de blockchain a la empresa que veremos es el de la trazabilidad: en una cadena de producción, en la cadena alimentaria desde un producto, desde su pesca o recolección hasta que llega a nuestra mesa… o las famosas criptomonedas.
Son ejemplos de uso/aplicación/utilidad. Pero ¿por qué es necesaria una tecnología como blockchain? El ejemplo de las criptomonedas nos acerca más a la que considero la necesidad real: la seguridad.

 

Si pensamos en las criptomonedas, para evitar que puedan ser robadas/reutilizadas/… o cualquier tipo de fraude, en un entorno distribuido, multiusuario, basado en código abierto a menudo, … requieren de una trazabilidad y seguridad impoluta. Y eso hace un blockchain, garantizar la llamada “inmutabilidad” de las transacciones confirmadas en su DLT.

 

Desde la perspectiva de los almacenes de datos, las necesidades de seguridad no son nuevas y están en principio ya resueltas (salvo brechas). Pero la inmensa mayoría de medidas de seguridad actuales son, por decirlo de alguna manera, “externas” a la información y blockchain aporta dos elementos nuevos en seguridad:

  • La seguridad de un blockchain es intrínseca a los datos almacenados. Hay dependencia entre TODA la cadena de bloques que componen el blockchain desde el estado actual a su inicio. La seguridad de la información no es proporcionada por el motor DBMS, sino que está embebida en los mismos datos y una alteración ilegítima en cualquier bloque quedará evidenciada en cuanto se examine (no podemos hacer un backup, llevar los datos a otra máquina, y modificarlos libremente).
  • Las actualizaciones no se realizan mediante sentencias (tipo SQL), y no hay modificaciones ni borrados. Un “lenguaje” de transacciones (smart contracts) permite modificar el estado del ledger (siguen siendo comandos, pero con reglas de negocio asociadas). No hay comandos específicos/privilegiados que permitan a un DBA/Superusuario cambiar el estado del blockchain a su antojo. Además las transacciones realizadas deben ser validadas por los miembros de ese blockchain mediante algoritmos de consenso para modificar su estado de manera permanente.

 

Desde un punto de vista de productividad también hay factores de interés para organizaciones que actúan en entornos B2B. La arquitectura de blockchain permite eliminar costes de integración en los siguientes aspectos:

  • Las organizaciones participantes operan en tiempo casi real (minutos).
  • En general, no será necesario añadir procesos de validación y/o conciliación adicionales, que están implícitos en los contratos y los algoritmos de consenso.
  • Las necesidades regulatorias en ámbito de seguridad están satisfechas.
  • Se ofrece como PAAS en la nube Oracle (escalable y configuración dinámica).
  • Facilidad de integración (REST API; SDKs para Java, Node.js y GO; integración Plug and play con Oracle SaaS, PaaS y aplicaciones on-premise).

Tipos de blockchain

Hay esencialmente dos tipos de blockchain claramente diferenciados. Su elección estará en función del tipo de uso para el que se diseña la aplicación:

  • Públicos (permissionless). Cualquiera puede conectarse al blockchain, enviar transacciones y leerlas una vez validadas. Como en el caso de las criptomonedas, cualquiera puede operar con ellas en igualdad de condiciones.
  • Autorizados (permissioned). Una comunidad de usuarios se adhiere, previa autorización, a ese blockchain. Existen mecanismos para dar diferente visibilidad o privilegios a algunos miembros.

 

A su vez, los blockchain autorizados se subdividen en dos subtipos:

  • Privados: existe un fundador, una entidad central, que administra los permisos de escritura y lectura (aunque esta podría ser pública) de su red de miembros.
  • Consorcio: un grupo predefinido de nodos controla el algoritmo de consenso (pueden validar transacciones), por lo que se consideran parcialmente privados. La principal diferencia es una capa de control de acceso que permite definir grupos de participantes con diferentes permisos de escritura, lectura, o visibilidad parcial, sobre ciertos tipos de transacciones u objetos, de manera que sólo vean parte de las transacciones (tipo VPD).

 

Por su enfoque empresarial, Oracle implementa un blockchain autorizado de tipo Consorcio.

 

¿Qué implementaciones de blockchain hay?

Oracle (en la línea seguida con otros productos de su cartera como Linux), no ha empezado el desarrollo de su blockchain desde cero, sino que se ha sumado a Hyperledger, una iniciativa colaborativa de código abierto creada para fomentar el progreso de la tecnología blockchain.

Se trata de una colaboración global acogida por la Linux Foundation, orientada al desarrollo de frameworks para aplicaciones blockchain de negocio, incluyendo líderes en el mundo de las finanzas, banca, IoT, fabricación, suministros y tecnología.

 

Hyperledger ofrece diversos frameworks, priorizando cada uno determinadas características para adaptarse mejor a diferentes necesidades/realidades del mundo de los negocios:

  • Burrow. Ofrece un cliente modular para blockchain autorizados, parcialmente adaptado a la especificación EVM (Ethereum Virtual Machine).
  • Fabric. Framework Autorizado, con soporte para canales (visión restringida para cada usuario, al estilo de una VPD).
  • Indy. Destaca su implementación de seguridad descentralizada.
  • Iroha. Focalizado en aplicaciones móviles.
  • Sawtooth. Soporte para blockchains tanto Públicos como Autorizados, perteneciente también a la familia de transacciones EVM.

 

Oracle ha optado por “Fabric” como base para implementar su blockchain en la nube, al que ha aportado una serie de mejoras para adaptarse mejor a las necesidades corporativas. En contrapartida, no ha tenido que realizar todo el esfuerzo de desarrollo desde cero, e irán evolucionando juntos.

 

¿Qué se puede hacer con blockchain que no se pueda hacer con un RDBMS o NoSQL?

Cada necesidad de negocio tiene unas características que hacen que determinadas tecnologías se adapten mejor que otras, proporcionando mayor cobertura a dichas necesidades o incluso ventajas competitivas. Nada nuevo bajo el sol: habrá que identificar a qué negocio puede aportar ventajas un blockchain. La mejor pista posiblemente sea identificar aquellos casos de uso en que la trazabilidad de los datos y poder seguir sus cambios sea un factor diferencial. También aquellos en que haya que compartir determinada información (escenario B2B), o “pasarse un testigo”, del que debamos saber en todo momento dónde está y por los estados que ha pasado hasta llegar a él.

 

Por ejemplo, podríamos pensar en los actuales sistemas de venta de entrada. Si en lugar de sustentarse en RDBMS (o en NoSQL, si los hay), podrían beneficiarse del uso de blockchains para dificultar la reventa. Quizá también alguno de los casos de uso típicos de BD de grafos podrían implementarse de forma más segura con blockchain.

 

Por otra parte, aunque hemos comparado blockchain con un libro contable, no se nos ocurriría a priori desarrollar una contabilidad (a nivel de ERP comercial estàndard) sobre un blockchain.

 

En cambio, el tiempo de respuesta de la BD NoSQL Key-value que pueda estar tras un carro de la compra, no podrá ser igualado por un blockchain, con sus algoritmos de consenso, etc., por lo que tampoco parece buena opción mientras que el tracking del paquete enviado una vez realizada la venta, parece más viable.

 

¿Cómo integrar OBCS con nuestras aplicaciones?

Para utilizar un blockchain (consultar o modificar su estado) son necesarios tres elementos:

  • Obviamente, la plataforma, una Instancia de red de blockchain. En el caso de OBCS, sólo será necesario definirla y configurarla para que esté operativa en minutos.
  • Desarrollar un(os) chaincode(s). Los smart contracts, que, en base a las reglas de negocio que hayamos definido, actualizará el estado del blockchain.
  • Una aplicación que consulte o actualice el estado del blockchain (únicamente invocando a sus chain codes).

 

Los chaincode se desarrollan en Go, Node.js, o Java y se instalan en la instancia OBCS. Definen el esquema de datos en el DLT, lo inicializan, y actualizan su estado a petición de las aplicaciones, o responden a sus consultas. Los chaincodes también pueden enviar eventos para notificar a las aplicaciones y realizar operaciones de downstream en el cliente.

 

Hay dos opciones para desarrollar aplicaciones.

Utilizar un SDK para acceder a las APIs y hacer consultas o actualizaciones al ledger. Necesitaremos instalar y utilizar el SDK de Hyperledger Fabric para desarrollar aplicaciones para Oracle Blockchain Platform. Hay dos SDKs, uno para Java y otro para Node.js. En ambos casos, tras su instalación, es necesario parchear el SDK para que pueda conectarse a OBCS.

Usar las APIs REST proporcionadas por Oracle Blockchain Platform para invocar transacciones, consultas, o ver el estado de una transacción.

 

¿Cómo integrar blockchain con nuestro Datapool?

Esta es una pregunta interesante, que merecerá ser contestada detalladamente en algún momento. Sería interesante disponer de un LKM de ODI que permita obtener el estado actual (valor) de una clave determinada en el blockchain (o para ser más eficientes, de una colección de claves) y simétricamente, un IKM que permita invocar chaincodes para insertar/actualizar datos residentes en un blockchain.

 

Pensando en clave BDA, sería interesante contar disponer de integración con hive o spark (aunque esto quizá ya sea posible). Esperamos que esta introducción haya resultado interesante.

 

 

Evolución, innovación y transformación
39 especializaciones avaladas por Oracle
Oportunidades ilimitadas
Posts 100% Oracle
Sigue nuestro día a día