Tutorial Hyperledger

Hyperledger es una plataforma opensource para crear aplicaciones blockchain en una red de negocio de carácter empresarial.
Para ello la filosofía que persigue es que los participantes de la red deben ser conocidos, las redes deben ser permisionadas, debe tener una tasa de transacciones por segundo muy alta y debe guardar la privadad y confidencialidad de las transacciones y de los datos.

Entre los casos de uso que están aplicando Hyperledger podemos encontrar el Supply Chain, Provenance, Derechos de la propiedad, Fintech, Healthcare, entre otros.

Hyperledger consta de varios sub-proyectos o frameworks (Burrow, Fabric, Iroha, Sawtooth) y varias herramientas (Caliper, Cello, Composer, Explorer, Quilt).
Hyperledger está gobernado por la Linux Foundation y tiene un gran soporte por parte de IBM.
Lo más conocido de Hyperledger es Fabric y Composer. Fabric es el más activo de los 10 proyectos actuales. Este tutorial está centrado en Hyperledger Fabric.

Hyperledger Iroha

Inicialmente tuvo contribuciones de Soramitsu, Hitachi, NTT Data y Colu. Está enfocado en la sencillez de implementación utilizando C++, enfatizando el desarrollo de apps móviles y utilizando el algoritmo de consenso YAC.

Por cierto, si quieres obtener criptomonedas gratis al aprender, puedes dar un vistazo a Coinbase que es además un excelente Exchange.

Hyperledger Indy

Este framework está enfocado en la identidad digital en Internet. Utiliza DID (Identificadores Descentralizados) y Credenciales Verificables para añadir una capa de identidad en Internet.

Hyperledger Sawtooth

Ha sido uno de los primeros proyectos en unirse a la Linux Foundation y está arropado por Intel. Permite el uso permisionado o no permisionado. Utiliza el algoritmo de consenso Proof of Elapsed Time

Hyperledger Fabric

Ha sido de los primeros proyectos en madurar, bajo la mano de IBM. Utiliza Peers, un Ordering service y un servidor de membresía. Tiene la capacidad de usar smart contracts (denominados chaincode) y permite el uso de varios canales.

Contenidos:

Las características de Fabric

Introducción

Fabric es una DLT privada permisionada con soporte para canales. No necesita una criptomoneda para poder funcionar.
Composer es un conjunto de herramientas para modelar y construir redes de negocio en blockchain. Construida con Javascript, utiliza varias herramientas muy conocidas como Node.js, npm y Yeoman.
Fabric puede utilizar modelos de consenso de tipo plug and play, para adecuar a cada caso de uso el más eficiente.
Por ejemplo si se usa en una sola empresa se puede usar un algoritmo de consenso de tipo Crash Bizantine Fault Tolerant mientras que si se usa entre varias empresas podría usar un algoritmo de consenso de tipo Tolerante a Fallos Bizantinos.
Es permisionada, es decir se administra quien puede leer o escribir en la blockchain.
Guarda el estado de los activos digitales en una base de datos de tipo "clave-valor".
Tiene smart contracts denominados "chaincode", que pueden ser implementados en código Go o Java o Javascript.
Asimismo puede usar una gestión de identidades de tipo plug and play, como LDAP o OpenID, para ajustarse a las necesidades de cada empresa o caso de uso.

El diseño de Fabric trabaja con varios conceptos com son los assets, el chaincode, el ledger, la privacidad, los servicios de membresía y el consenso.

Assets

Los assets permiten modelar el intercambio de cualquier cosa que tenga valor a través de la red de negocio, desde comida, coches o divisas.
Incluso cosas intangibles como contratos o derechos de la propiedad intelectual.
Básicamente se almacenan como una colección de pares "clave-valor" con cambios de estado registrados como transacciones en el ledger.

Chaincode

El chaincode permite modificar estos assets, mediante la lógica de negocio se definen las reglas para leer o alterar estos pares "clave-valor" u otra información de la base de datos del "estado".

Ledger

En el ledger se guardan todos los cambios de estados, de manera secuencial y resistente a la manipulación de estos datos.
Estos cambios de estado se producen a partir de las invocaciones del chaincode en forma de transacciones que emiten varios participantes de la red de negocio. Así pues el ledger está compuesto de una blockchain para almacenar la secuencia de cambios y de una base de datos de los estados.

Privacidad

Mediante el uso de canales se mantiene la privacidad de las transacciones en la red.

Servicios de membresía

Dado que todos los participantes de la red de negocio tienen identidades conocidas dentro de una organización, se usa PKI con certificados X509 para generar certificados criptográficos a las organizaciones, participantes o usuarios de las aplicaciones.
Existen también los proveedores de servicios de membresía que definen dentro de cara organización el rol de cada Peer.

Consenso

El algoritmo de consenso es la pieza fundamental a la hora de ordenar las transacciones en un bloque, desde la propuesta y el "endorsement" hasta la ordenación, validación y escritura.

Red de negocio (Business Network)

Una red de negocio consta de varios nodos que se comunican por la red. Hay 3 tipos de nodos: los clientes que envían transacciones a los peers,
los peers que registran las transaciones, mantienen una copia del ledger y del estado y los ordering service que ordenan, validan las transacciones, las meten en bloques y las envían a los Peers. El servicio de autoridad de certificados se usa para generar certificados y claves para gestionar y configurar las identidades de la red de negocio.
El ordering service ordena las transacciones por tiempo y las prepara para incluirlas en un bloque.
Los peers que pertenecen a las organizaciones, almacenan el ledger y los smart contracts.
Las transacciones se registran en la blockchain, mientras que el estado de los assets se almacena en una base de datos.
Tanto el estado de los assets como los registros se comparten entre los varios peers del sistema utilizando el algoritmo de consenso.

Para definir una red de negocio hace falta como mínimo un Ordering Service. Este es configurado y gestionado por un administrador de una determinada organización, dando permisos sólo a esa organización. Posteriormente se añade como mínimo un Peer que almacena una copia del ledger. Este Peer se comunica con el Ordering Service mediante un canal.

Secuencia de llamadas

A continuación se muestra como las aplicaciones interaccionan con los Peers para acceder al ledger. Las transacciones de consulta se retornan de modo inmediato,
mientras que las transacciones que contienen actualizaciones requieren interacciones entre aplicaciones, peers y ordering services.

Componentes de una red de negocio

Asset

Un asset es un activo digital modelado dentro del sistema Hyperledger. Puede ser cualquier cosa desde un coche, un alimento, etc... tienen un identificador y varias propiedades, y pueden estar relacionados con otros asset o con participantes.

Participante

Un participante es un actor de la red que puede ser el dueño de un asset y puede enviar transacciones. Al igual que un asset, constan de un identificador y varias propiedades.

Identidades

Vienen definidas por un certificado digital con su clave privada, se asignan a los participantes de la aplicación. Estas identidades se guardan en las "cards".

Transacciones

Definen la lógica de negocio de la aplicación. Es decir como los participantes se relacionan con los assets.

Query

Definen consultas sobre el estado de los assets de la blockchain.

Eventos

Se definen en fichero de modelado y permiten al mundo off-chain darse cuenta de los cambios on-chain. Las aplicaciones pueden suscribirse a varios eventos y así mostrar alertas especificas de lo que ocurre en los assets.

ACL (lista control accesos)

Permiten definir los permisos de los participantes a la hora de acceder a los varios assets

El Hyperledger Composer

Es un conjunto de herramientas para desarrollar y agilizar la creación de aplicaciones blockchain. Se comunica con Fabric de manera muy fácil y permite diseñar pruebas de concepto y desplegar en cuestión de pocas semanas.
Composer empaqueta todos los archivos en un fichero BNA (Business Network Archive).

Un fichero BNA contiene:

Todo esto va empaquetado en un BNA y permite desplegar una aplicación blockchain fácilmente en varios entornos, ya sean locales o en el cloud.

Para ejecutar Hyperledger Composer se puede realizar en el ordenador local o en el cloud (Bluemix de IBM). Se utiliza lo que se denomina un "playground", que es un entorno de pruebas donde podemos editar todos los ficheros anteriores y desplegarlos en Fabric de manera transparente. Permite modelizar y testear una aplicación blockchain fácilmente y rápidamente.

El playground ya viene precargado con varios ejemplos, así es que es muy recomendable utilizarlo para hacerse una idea de como modelizar una aplicación blockchain dentro del ecosistema Hyperledger.

Instalación de Hyperledger

A la hora de elegir un entorno para instalar Hyperledger, es aconsejable utilizar una versión de Linux, en general se recomienda un Ubuntu 16.04 o un MacOS.

Requisitos

Hace falta toda una serie de programas que son los siguientes:

Existe un script de github que gestiona los requisitos. Lo podemos instalar con cURL. Si no tenemos instalado cURL lo haremos con : 

sudo apt install curl

A continuación se descarga el script y se ejecuta: 

curl -O https://hyperledger.github.io/composer/latest/prereqs-ubuntu.sh
  chmod u+x prereqs-ubuntu.sh
  prereqs-ubuntu.sh

Composer

Para instalar el composer hay que utilizar npm para instalar varias herramientas:

Fabric

Existe otro script que contiene el script de instalación de Fabric. Creamos un directorio, descargamos el script con cURL y lo desempaquetamos:

mkdir ~/fabric-dev-servers && cd ~/fabric-dev-servers
  curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.tar.gz
  tar -xvf fabric-dev-servers.tar.gz
  cd ~/fabric-dev-servers
  ./downloadFabric.sh

Para arrancar Fabric hacemos:

cd ~/fabric-dev-servers
y 
./startFabric.sh

Para detener Fabric hacemos:
./stopFabric.sh

Y para arrancar el playground:
composer-playground

Una vez hecho esto podemos acceder al playground desde el navegador en la url: 

http://localhost:8080

Se puede instalar Kitematic para manejar los contenedores de Docker visualmente e Insomnia para manejar las peticiones a las API REST si se desea.

Desarrollo de aplicaciones con Hyperledger

El primer paso consiste en crear una definición de la red de negocio. Ahí se define el modelo de datos, la lógica de las transacciones y las reglas de acceso.
Se puede usar Yeoman para generar un esqueleto:

yo hyperledger-composer:businessnetwork

Una vez tengamos desarrollado los modelos y la lógica de negocio podemos empaquetarlo con:

composer archive create -t dir -n .

Esto creará un fichero del tipo mired@0.0.1.bna

A continuación creamos las credenciales del administrador de la red de negocio:

createPeerAdminCard.sh

con eso se nos crea una "card" denominada "PeerAdmin@hlfv1"

A continuación hay que instalar el BNA en Fabric:

composer network install --card PeerAdmin@hlfv1 --archiveFile mired@0.0.1.bna

Luego arrancar la red:
composer network start --networkName mired --networkAdmin admin --networkAdminEnrollSecret adminpw
  --card PeerAdmin@hlfv1 --file miredadmin.card --networkVersion 0.0.1

Importar la card:
composer card import --file miredadmin.card

Podemos hacer un ping a la red de negocio:
composer network ping --card admin@mired

E incluso publicar una API REST para comunicarse con la blockchain:
composer-rest-server

Existe una opción para generar un esqueleto de aplicación angular usando Yeoman:

yo hyperledger-composer

Esta aplicación se puede iniciar con:
npm start

Para actualizar una BNA se requiere realizar los siguientes pasos:
Cambiar la "version" del package.json de 0.0.1 a 0.0.2
Volver a crear el paquete esta vez con el nombre: mired@0.0.2.bna
Instalar la nueva red en Fabric:

composer network install --card PeerAdmin@hlfv1 --archiveFile mired@0.0.2.bna

Upgradar la red a la nueva versión:
composer network upgrade -c PeerAdmin@hlfv1 -n mired -V 0.0.2

Hacer un ping a la red:
composer network ping --card admin@mired

Regenerar el API REST:
composer-rest-server

Lenguaje de modelado de Composer

Los modelos utilizan un lenguaje orientado a objetos, similiar a un lenguaje Java. Se usa un espacio de nombres para agrupar recursos: 

namespace org.tutorial.basic

Luego estos se pueden importar dentro de otros ficheros .cto con:
import org.tutorial.basic

Los tipos primitivos son: String (UTF8), Double (número decimal 64bit), Integer (número entero con signo 32 bit), Long (número entero con signo 64bit), DateTime (fecha y hora con timezone) y Boolean (un valor verdadero o falso).

Pueden asignarse valores por defecto con la palabra clave: 

default="texto"
o valores opcionales con la palabra: 
optional

Se pueden definir arrays con los corchetes [] y enums:

enum Estado {
          o PENDIENTE
            o FINALIZADO
        }

Luego se pueden definir assets con la palabra 

asset
que pueden heredar de otros assets con la palabra 
extends
 Las propiedades de un asset se definen con una "o" el tipo de datos y el nombre de la propiedad. Y si queremos incluir una relación se define con "-->"

A continuación se pueden definir participantes con la palabra 

participant
que pueden heredar de otros participantes con la palabra:
extends
 Las propiedades de un participant también se definen con una "o" el tipo de datos y el nombre de la propiedad. Y si queremos incluir una relación se define con "-->"

Lo mismo se aplica para las transacciones y los eventos, pueden heredar e incluyen propiedades y relaciones.

Existe un tipo de clase abstracta que no representa assets, participantes ni transacciones. No pueden ser referenciadas. Sirven para agrupar propiedades: 

abstract concepto Direccion {
  o String calle
    o String ciudad
    o String pais
}

Chaincode

Para definir la lógica de ejecución se utilizan ficheros javascript. Usa los comentarios y metadatos para definir estas funciones.
Se describen como 

async nombreTransaccion()
porque van orientadas a eventos como Node.
Son atómicas y podemos lanzar una excepción con 
throw new Error("error")
 lo que provoca un rollback y se pierden todos los cambios.

Dentro del código se puede hacer uso de varias librerías: Common, Runtime, Admin, y Client.
Estas permiten gestionar activos, emitir eventos o gestionar la red.

Queries

Las consultas a la red de negocio se definen en ficheros .qry. Las consultas van precedidas de la palabra query y contienen una "description" y un "statement" que es la consulta de base de datos propiamente dicha. 

query seleccionaMiAsset {
description: "Selecciona todos los assets de tipo MiAsset"
               statement: SELECT org.tutorial.MiAsset
}

Playground

Es posible y recomendable definir todo este código completo en el Playground y testearlo directamente.
Incluso se puede exportar todo el código completo a un fichero .bna para su despliegue en Fabric funcionando en nuestra red local.

Preguntas frecuentes