Blockchain: desarrollo en Ethereum

Stack tecnológico

Ethereum e Hyperledger Fabric se están convirtiendo en el estándar de facto de la industria Blockchain:

• El protocolo Bitcoin no es Turing completo por lo que ofrece muchas limitaciones en el desarrollo. Actualmente de implementaciones como The Lightning Network se encuentran en un estado primario.
• Son utilizados por la comunidad de desarrolladores más numerosa, como se puede ver reflejado en lugares como StackOverflow.

El entorno de desarrollo se ve influenciado por los clientes más avanzados para Ethereum e Hyperledger Fabric, desarrollados en JavaScript.

Teniendo en cuenta estos factores, stacks tecnológicos como MEAN JS parecen proporcionar una solución que se adapta a estas necesidades:

• MongoDB: Base de datos NoSQL orientada a documentos. Su propósito es el de servir de base de datos off-chain (especialmente útil en el uso de Ethereum, ya que Hyperledger Fabric incluye opcionalmente CouchDB que también sigue el mismo paradigma).
• ExpressJS: Framework para aplicaciones web.
• AngularJS: Framework que permite extender el comportamiento de HTML para aplicaciones web dinámicas. En el stack aplica a la capa de frontend.
• Node.js: Plataforma que permite crear tu propio servidor web y construir aplicaciones. Tiene un único de hilo de ejecución, utilizando entradas y salidas asíncronas. NPM es el gestor de librerías/paquetes.

Es importante destacar que MEAN JS no tiene que ser necesariamente un stack inamovible. Por ejemplo, reemplazando el frontend (AngularJS) por otro diferente (Bootstrap, React…). Adicionalmente a todo esto, y de cara a facilitar el despliegue de las aplicaciones/pruebas de concepto, una de las herramientas que permite realizar esta tarea de una forma más sencilla y orientada a microservicios es Docker, reduciéndose dicho despliegue a dos pasos:

1. Instalar Docker Community o Enterprise Edition.
2. Ejecutar “docker-compose up” en la carpeta padre del proyecto.

Para la escalabilidad, y de cara a la promoción a entornos productivos, se puede emplear una plataforma cloud como AWS o Azure, permitiendo de esta forma:

• Gestionar el hosting de una aplicación Node.js.
• Integrar el código de una forma cercana al plug & play al utilizar Docker.

A continuación se detalla un ejemplo de integración con Ethereum. En el próximo artículo abordaremos la integración de este stack con Hyperledger Fabric. 

Descripción general

En primer lugar, será necesario “levantar” los nodos de la Blockchain:

1. Añadir la imagen Docker del cliente elegido (TestRPC, Geth o Parity) al proyecto. Ejemplo de configuración con Parity usando Proof-of-Authority en fichero Docker-Compose:

    

2. Ejecutar “docker-compose up” levantará el nuevo contenedor a partir de la imagen añadida, junto al resto de contenedores existentes (Frontend, Backend, MongoDB).

Para la integración con la Blockchain desde el Backend, se hará uso de las siguientes librerías referenciándolas en el package.json:

• web3: Abre la conexión con el servidor de Blockchain. Permite realizar operaciones básicas genéricas sobre la misma (consulta de direcciones, coinbase, transacciones, bloques…).

• truffle: Gestiona y facilita la interacción con los Smart Contracts, desplegándolos, migrándolos y llamando a sus métodos.  Ejemplo de llamada que implica transacción:

Ejemplo de llamada que no implica transacción (sólo lee):

Para el desarrollo de los Smart Contracts, el lenguaje de programación más utilizado es Solidity. Este lenguaje, similar a JavaScript, permite la gestión de las direcciones y los permisos de uso para cada método.

Para un rol como proveedor de servicios de consultoría tecnológica, y teniendo en cuenta el estado actual de la tecnología Ethereum, la configuración de la misma para una prueba de concepto implicaría:

• Uso de Proof-of-Authority como algoritmo de consenso. Adaptado a consorcios privados de empresas, evitando de esta manera un gasto energético no necesario en ámbitos cerrados.
• Elección de Parity como cliente de Ethereum:
  • Permite varios nodos.
  • Permite varios algoritmos de consenso.
  • Cuenta con una interfaz gráfica que permite la configuración de cuentas y gestión de Smart Contracts.
  • Incorpora gran parte de la funcionalidad proporcionada por Geth.
  • La conjunción con Docker permite su portabilidad entre diversos entornos, incluyendo el local.

Por lo tanto, la arquitectura lógica a alto nivel de Ethereum, teniendo en cuenta el stack tecnológico mencionado anteriormente, quedaría de la siguiente forma:

Aplicaciones complementarias

En muchas ocasiones, es complicado mostrar al cliente que realmente se está ejecutando la aplicación sobre una red Blockchain, ya que la interfaz de usuario es la única parte que se ve y está orientada a funcionalidad, no a tecnología. Adicionalmente, la Blockchain se encuentra en la parte más inferior del stack tecnológico, lo que supone una dificultad añadida.

Por lo tanto, de cara a demostrar que las transacciones ejecutadas por pantalla se están persistiendo contra la Blockchain, es necesario el uso de aplicaciones satélite como un explorador de bloques o un monitor del estado de la red (mostrando información como bloques por segundo…). Estas aplicaciones satélite se añaden al proyecto Docker y leen directamente de la red Blockchain sin pasar por nuestra aplicación definida con MEAN JS. Netstats:

Testing y Mock

Para realizar el testing, a nivel de Backend Node.js se pueden utilizar el paquete NYC con Mocha, popular por su lenguaje descriptivo a la hora de definir dichas pruebas.

En la parte de Blockchain, se definirían tests unitarios con Truffle. Como se puede observar, teniendo en cuenta la aplicación de dicha herramienta, Truffle vendría a llevar un rol similar al de Maven/Gradle en Java.

En ambas capas de test, se utilizará el modo de sobrescritura de Docker-Compose (docker-compose –f <nombre_fichero_docker_compose_general> -f <nombre_fichero_sobrescritura> up) para reemplazar estrictamente el contenedor a probar.

De cara a paralelizar el trabajo entre capas, se proporcionará una Swagger API que permitirá obtener respuestas desde un periodo temprano al desarrollador de Frontend en su modo mock (esta API deberá cambiar mínimamente durante el desarrollo). Para su despliegue se empleará también el modo sobrescritura de Docker-Compose, reemplazando de este modo el Backend de la aplicación y manteniendo la interfaz de la API.