Buscar

Blog de Alfonso Tienda

Marketing, Startups, Proyectos y Tecnología.

Hyperledger Fabric

Elementos de Hyperledger Fabric

Vamos a repasar lo que son los elementos de Hyperledger Fabric.

Canales

Los canales son mecanismos de partición de datos que permiten la visibilidad de las transacciones solo para las partes interesadas. Cada canal es una cadena independiente de bloques de transacciones que contiene solo transacciones para ese canal en particular. Por ejemplo, los miembros de un canal pueden ver sus precios pero no los precios a los que se vende un producto a los miembros de otro canal.

Los canales permiten que las organizaciones utilicen la misma red, a la vez que mantienen la separación entre varias cadenas de bloques. Solo los miembros del canal en el que se realizó la transacción pueden ver los detalles de la transacción. En otras palabras, los canales dividen la red para permitir la visibilidad de las transacciones solo para las partes interesadas. Este mecanismo funciona mediante la delegación de transacciones a diferentes ledgers. Solo los miembros del canal participan en el consenso, mientras que otros miembros de la red no ven las transacciones en el canal.

Chaincode

El chaincode (Smart Contracts) encapsula las definiciones de los activos y la lógica de negocios (o transacciones) para modificar esos activos. Las invocaciones de transacción producen cambios en el libro mayor. El chaincode en Fabric (los Smart Contracts) se desarrollan en el lenguaje de programación GO.

Ledger

El ledger contiene el estado actual de la red y una cadena de invocaciones de transacciones. Un libro de contabilidad compartido y autorizado es un sistema de registros de solo anexión y sirve como una fuente única de verdad.

Red

La red es la colección de pares de procesamiento de datos que forman una red blockchain. La red es responsable de mantener un libro mayor constantemente replicado.

Servicio de ordering

El servicio de ordering u ordenación es una colección de nodos que ordena transacciones en un bloque.

Estado global

El estado global refleja los datos actuales sobre todos los activos en la red. Esta información se almacena en una base de datos para un acceso eficiente. Las invocaciones de Chaincode ejecutan transacciones contra los datos de estado actuales. Para que estas interacciones de chaincodes sean extremadamente eficientes, los últimos pares clave / valor para cada activo se almacenan en una base de datos de estado. La base de datos del estado es simplemente una vista indexada de las transacciones que han hecho commit en el blockchain. Por lo tanto, puede regenerarse en cualquier momento. La base de datos del estado se recuperará automáticamente (o se generará, si es necesario) tras el arranque de los nodos, antes de que se acepten nuevas transacciones. La base de datos de estado predeterminada, LevelDB, se puede reemplazar con CouchDB.

  • LevelDB es la base de datos de estado / clave predeterminada para Hyperledger Fabric, y simplemente almacena pares clave / valor.
  • CouchDB es una alternativa a LevelDB. A diferencia de LevelDB, CouchDB almacena objetos JSON. CouchDB es único ya que admite consultas con clave, compuesto, rango clave y completo de datos.

Ambas son muy similares en su estructura y función.

Membership service provider

El proveedor de servicios de membresía (MSP) administra la identidad y el acceso permitido para clientes y pares. Hyperledger Fabric es una red autorizada, lo que significa que solo los participantes que han sido aprobados pueden obtener acceso a la red. Para gestionar la membresía y la identidad de la red, los proveedores de servicios de membresía (MSP) administran los ID de usuario y autentican a todos los participantes en la red. Una red de cadena de bloques Hyperledger Fabric puede ser gobernada por uno o más MSP. Esto proporciona la modularidad de las operaciones de membresía y la interoperabilidad a través de diferentes estándares y arquitecturas de membresía. El objetivo es disponer de membresías o MSPs diferentes para los actores de una aplicación determinada del blockchain, por ejemplo una cadena de suministros. Las políticas se definen para dictar las políticas de lectura / escritura de un canal o las políticas de aprobación de un chacode.

En Hyperledger Fabric, los MSP también permiten la membresía dinámica para agregar o eliminar miembros para mantener la integridad y el funcionamiento de la cadena de suministro. Por ejemplo, para revocar una membresía, sin comprometer el resto de la red. Esta característica es crítica, especialmente para aplicaciones empresariales, donde las relaciones comerciales cambian con el tiempo.

Para empezar, los usuarios se autentican usando una autoridad de certificación. La autoridad de certificación identifica las identidades de la aplicación, el nodo, el endosante y el orderer, y verifica estas credenciales. Una firma se genera a través del uso de un Algoritmo de Firma y un Algoritmo de Verificación de Firma.

Específicamente, la generación de una firma comienza con un Algoritmo de firma, que utiliza las credenciales de las entidades asociadas con sus respectivas identidades y genera un endoso. Se genera una firma, que es una matriz de bytes que está vinculada a una identidad específica. A continuación, el algoritmo de verificación de firma toma la identidad, el endoso y la firma como entradas, y las salidas ‘aceptan’ si la matriz de bytes de la firma corresponde con una firma válida para el endoso ingresado, o las salidas ‘rechazan’ si no. Si la salida es ‘aceptar’, el usuario puede ver las transacciones en la red y realizar transacciones con otros actores en la red. Si el resultado es ‘rechazo’, el usuario no se ha autenticado correctamente y no puede enviar transacciones a la red ni ver ninguna transacción anterior.

En general, las Autoridades de Certificación administran certificados para un blockchain autorizado. Fabric-CA es la autoridad de certificación predeterminada para Hyperledger Fabric, y maneja el registro de identidades de usuario. La autoridad de certificación Fabric-CA está a cargo de emitir y revocar certificados de inscripción (E-Certs).

Roles

Hay tres tipos diferentes de roles dentro de una red Hyperledger Fabric:

Cliente

Los clientes son aplicaciones que actúan en nombre de una persona para proponer transacciones en la red.

Pares

Los pares mantienen el estado de la red y una copia del libro mayor (ledger). Hay dos tipos diferentes de pares: los que endosan (endorsing) y los que hacen el commit. Sin embargo, existe una superposición entre los pares de endoso y de commit, en el sentido de que los pares de endoso son un tipo especial de pares de commit. Todos los pares hacen commit sobre el ledger.
– Los endosantes simulan y respaldan transacciones
– Los pares de commit verifican las aprobaciones y validan los resultados de las transacciones, antes de hacer commits de la transaccion sobre el blockchain.

Servicio de orden

El servicio de orden acepta transacciones endosadas, las ordena en un bloque y entrega los bloques a los pares que harán el commit.

Flujo de consenso

Para llegar al consenso habrá que seguir tres pasos:

  1. Propuesta de transacción, donde las aplicaciones clientes mandarán sus transacciones hacia el blockchain, a los pares de “endoso”
  2. Cada nodo de endoso simula la transacción propuesta, sin actualizar el ledger. Los nodos de endoso capturarán el conjunto de datos leídos y escritos, llamados conjuntos RW. Estos conjuntos de RW capturan lo que se leyó del estado global mientras se simulaba la transacción, así como lo que se habría escrito si se hubiera ejecutado la transacción. Estos conjuntos RW son luego firmados por el nodo de endoso y devueltos a la aplicación cliente para ser utilizados en futuros pasos del flujo de transacción. Estos nodos de endoso tendrán, por lo tanto, los smart contracts que han de simular.
  3. La aplicación envía la transacción endosada y los conjuntos RW al servicio de ordenación.
  4. El servicio de ordenación toma las transacciones aprobadas y los conjuntos RW, ordena esta información en un bloque y entrega el bloque a todos los nodos de commit. El servicio de ordenación acepta las transacciones endosadas y especifica el orden en que esas transacciones harán commit en el ledger. La implementación específica de ‘ordenar’ (Solo, Kafka, BFT) es configurable en Fabric, siendo Kafka el predeterminado.
  5. Los nodos de commit validan la transacción comprobando que los conjuntos de RW aún coinciden con el estado global actual. Específicamente, que los datos de lectura que existieron cuando los endosantes simularon la transacción son idénticos al estado global actual. Una vez validada la transacción se ejecuta y el estado global cambia. Si la transacción falla, esto es que el estado global no corresponde con el endosado, la transacción ordenada en un bloque seguirá incluyéndose en ese bloque, pero se marcará como no válida, y el estado global no se actualiza. Los nodos de commit son responsables de agregar bloques de transacciones al ledger y actualizar el estado. Pueden tener smart contracts, pero no es un requisito.
  6. Por último, los nodos de commit son los encargados de notificar de forma asíncrona a la aplicación cliente el éxito o el fracaso de la transacción.

Verificación de identidad

Además de la gran cantidad de comprobaciones de endoso, validez y control de versiones que se llevan a cabo, también hay verificaciones de identidad en cada paso del flujo de la transacción. Las ACLs se implementan en las capas jerárquicas de la red (desde el servicio de pedido hasta los canales), y los payloads se firman, verifican y autentican repetidamente a medida que una propuesta de transacción pasa por los diferentes componentes.

 

 

 

Anuncios

Creando una aplicación en Hyperledger Sawtooth

Una aplicación en sawtooth está compuesta fundamentalmente de dos partes. Una aplicación cliente, que envía transacciones al blockchain, generalmente a través de la API REST Sawtooth y proporciona una interfaz de usuario para la aplicación (linea de comandos, página web, o cualquier interfaz capaz de usar http). La otra parte es un procesador de transacciones, que contiene la lógica de negocio de la aplicación y se comunica con el validador, que envía las transacciones recibidas del cliente para su validación.

Crear una aplicación requiere algunos pasos importantes:

  1. Definir los activos que residirán en el ledger distribuido,
    así como las transacciones que actuarán sobre estos activos para cambiar su estado. Básicamente qué es lo que vamos a guardar y cómo se modifica. Desde un punto de vista de objetos, el activo son las propiedades del objeto y las transacciones sus métodos.
  2. Diseñar la lógica de transacción que opera en estos activos. Esto es, la lógica de los métodos del objeto, siguiendo nuestro ejemplo.

Cuando se recibe una transacción por un nodo de Sawtooth, esta transacción se redirige a los demás nodos. Uno de los nodos es elegido por el algoritmo de consenso para publicar un bloque. Este bloque contendrá las transacciones que se hayan recibido y ejecutado de forma satisfactoria, y se hará un broadcast al resto de nodos. Cada nodo recibe este bloque y verifica su validez. En ese momento notificará a la aplicación el cambio de estado.

Vamos a desarrollar un caso práctico de una moneda. Muy básico. Se crea y se transfiere, aceptando o no la transferencia.

Vamos a utilizar un fork de uno de los materiales de hyperledger. Este fork está aquí:

git clone https://github.com/afoone/education.git

Una vez clonado podéis ir education/LFS171x/sawtooth-material/sawtooth-tuna y ejecutar:

docker-compose up

A continuación, en un navegador podemos poner la URL:

http://localhost:8000/

Publico esta entrada que iré mejorando durante los próximos días explicando cada una de las partes de una aplicación Sawtooth.

 

Instalando Hyperledger Sawtooth

En este blog vamos a ver cómo instalar Hyperledger Sawtooth para hacer nuestras primeras pruebas con redes blockchain. Las pruebas las hago con MacOS, si bien pueden funcionar en Linux o Windows, siempre que cumplan los siguientes requisitos de programas instalados:

  •  cURL
  • Git
  • Docker
  • Docker Compose

Las pruebas las estoy haciendo con la versión 18 de docker community. Este post asume que las herramientas citadas las domina el lector.

Instalar Hyperledger Sawtooth implicará agregar claves de firma para el creador del software a nuestro entorno, incluido el repositorio que contiene el código en nuestro sistema, y realizar una actualización / instalación típica. Un nodo de validación de Sawtooth se puede ejecutar a partir de imágenes Docker preconstruidas o de forma nativa utilizando Ubuntu 16.04 o posterior. Nuestro ejemplo es un nodo validador único que utiliza el consenso de modo de desarrollo, una API de REST, tres procesadores de transacción y un contenedor de cliente.

Vamos a utilizar el siguiente docker-compose.yml estándar de Intel:

# Copyright 2017 Intel Corporation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# ------------------------------------------------------------------------------

version: "2.1"

services:

settings-tp:
 image: hyperledger/sawtooth-settings-tp:1.0
 container_name: sawtooth-settings-tp-default
 depends_on:
 - validator
 entrypoint: settings-tp -vv -C tcp://validator:4004

intkey-tp-python:
 image: hyperledger/sawtooth-intkey-tp-python:1.0
 container_name: sawtooth-intkey-tp-python-default
 depends_on:
 - validator
 entrypoint: intkey-tp-python -vv -C tcp://validator:4004

xo-tp-python:
 image: hyperledger/sawtooth-xo-tp-python:1.0
 container_name: sawtooth-xo-tp-python-default
 depends_on:
 - validator
 entrypoint: xo-tp-python -vv -C tcp://validator:4004

validator:
 image: hyperledger/sawtooth-validator:1.0
 container_name: sawtooth-validator-default
 expose:
 - 4004
 ports:
 - "4004:4004"
 # start the validator with an empty genesis batch
 entrypoint: "bash -c \"\
 sawadm keygen && \
 sawtooth keygen my_key && \
 sawset genesis -k /root/.sawtooth/keys/my_key.priv && \
 sawadm genesis config-genesis.batch && \
 sawtooth-validator -vv \
 --endpoint tcp://validator:8800 \
 --bind component:tcp://eth0:4004 \
 --bind network:tcp://eth0:8800 \
 \""

rest-api:
 image: hyperledger/sawtooth-rest-api:1.0
 container_name: sawtooth-rest-api-default
 ports:
 - "8008:8008"
 depends_on:
 - validator
 entrypoint: sawtooth-rest-api -C tcp://validator:4004 --bind rest-api:8008

shell:
 image: hyperledger/sawtooth-all:1.0
 container_name: sawtooth-shell-default
 depends_on:
 - rest-api
 entrypoint: "bash -c \"\
 sawtooth keygen && \
 tail -f /dev/null \
 \""

Ahora debería ser suficiente con ejecutar el compose:

docker-compose up

El último de los servicios es un shell de utilidades, que podemos asimismo abrir:

docker-compose exec shell bash

No me voy a entretener con docker, pero comentar que lo que hacemos es abrir el shell de un contenedor de docker (bash), y estamos dentro de la red de docker. Como vemos en el contenedor (instrucción depends on), éste se comunica con el contenedor de rest-api. Probémoslo:

curl http://rest-api:8008/blocks

La rest-api debería devolver un json con datos, batches, etc. Como podemos ver en el composer, hemos sacado el puerto 8008 de la rest api al host, por lo que desde nuestro host (mi maravilloso mac) deberíamos también acceder a esta información (http://localhost:8008/blocks) en el navegador, por ejemplo.

Vamos a repasar un poco lo que tenemos instalado. Para información de cada componente se puede consultar la entrada Hyperledger Sawtooth: Introducción

  • hyperledger/sawtooth-xo-tp-python. Este es un procesador de transacciones, que en este caso está escrito en python. XO es una familia de transacciónes de ejemplo incluida en el SDK de Sawtooth. Es una implementación del popular juego tres en raya. Podéis consultar más información en https://sawtooth.hyperledger.org/docs/core/releases/latest/app_developers_guide/intro_xo_transaction_family.html
  • hyperledger/sawtooth-settings-tp. Es un contenedor que tiene un procesador de transacciones que gestiona las transacciones de configuración.
  • hyperledger/sawtooth-intkey-tp-python. Es un contenedor que contiene un procesador de transacciones que gestiona las transacciones de la familia IntegerKey. La familia de transacciones IntegerKey permite a los usuarios establecer, incrementar y disminuir el valor de las entradas almacenadas en un diccionario de estado.
  • hyperledger/sawtooth-validator. El validador sawtooth
  • hyperledger/sawtooth-rest-api. El api rest que usaremos
  • hyperledger/sawtooth-all. Un shell con todas las operaciones que necesitaremos.

Ya lo tenemos instalado. Lo siguiente es crear una aplicación. Una aplicación en sawtooth está compuesta fundamentalmente de dos partes. Una aplicación cliente, que envía transacciones al blockchain, generalmente a través de la API REST Sawtooth y proporciona una interfaz de usuario para la aplicación (linea de comandos, página web, o cualquier interfaz capaz de usar http). La otra parte es un procesador de transacciones, que contiene la lógica de negocio de la aplicación y se comunica con el validador, que envía las transacciones recibidas del cliente para su validación.

Veremos todo esto en el post siguiente: Creando una aplicación en Hyperledger Sawtooth

 

 

 

Hyperledger Sawtooth: Introducción

Hyperledger es una plataforma modular para construir redes y aplicaciones de ledgers distribuidos, basados en la tecnología de blockchain. Sawtooth simplifica el desarrollo de aplicaciones separando el sistema principal de Hyperledger del nivel de aplicación. Los desarrolladores de las aplicaciones, de esta forma, pueden especificiar la lógica de negocio de susu aplicaciones usando los lenguajes de programación que quieran sin necesidad de entender el diseño del sistema principal de Hyperledger.

Sawtooth tiene gran flexibilidad y modularidad y dispone de soporte para muchos lenguajes de programación diferentes.

Componentes de Sawtooth

Hyperledger Sawtooth tiene varios componentes:

Estado global

El estado global contienen el estado actual del ledger y una cadena de invocaciones a transacciones. El estado para todas las aplicaciones que se ejecutan en la red está representado en cada nodo. El proceso de validación de transacción en cada nodo asegura el mismo resultado en las mismas transacciones y el ledger resultante será asimismo el mismo. El estado está divicido dentro de namespaces de cada aplicación, lo que permite flexibilidad para los programadores de las aplicaciones para definicr, compartir y reusar el estado global entre procesadores de transacciones.

Lotes (Batch)

Son clusters de transacciones que se ejecutan juntas. un batch puede contender una transación o varias transaciones relacionadas que harán commit juntas. Es la “transaccionalidad” del blockchain, por la cual si una transacción falla, el resto también fallará. Cada transacción, de hecho, está incluida en un batch.

Cuando un cliente crea una transacción, el lote se envía al validador. Las transacciones se organizan en un lote en el orden en el que se ha de ejecutar el commit. El validador entonces, a su vez, aplica cada transacción dentro del lote, lo que lleva a un cambio en el estado global. Si una transacción en el lote no es válida, habrá un rollback, o más bien no se ejecutará la transacción.

En resumen, el procesamiento por lotes de transacciones permite que un grupo de transacciones se aplique en un orden específico, y si alguno no es válido, entonces ninguna de las transacciones se aplica.

Validadores

Los validadores validan transacciones.  En cualquier red blockchain, modificar el estado global requiere crear y aplicar una transacción. En Hyperledger Sawtooth, los validadores aplican lotes de transacciones que provocan cambios en el estado. Más específicamente, los validadores agrupan lotes en bloques, envían los bloques y se aseguran de que las transacciones den como resultado cambios de estado que sean consistentes para todos los participantes en la red, de acuerdo con el algorimo de consenso de red que se haya seleccionado.

Para comenzar, un usuario crea un lote que contiene una o más transacciones y lo envía a un validador, generalmente a través de un cliente que se comunica con una API REST. El validador verifica las transacciones y aplica el lote si todas las transacciones se consideran válidas, lo que da como resultado un cambio en el estado.

Aplicaciones Sawtooth

Las aplicaciones sawtooth son aplicaciones distribuidas, como los smart contracts, y están separadas del framework core.

Al igual que con cualquier framework de blockchain, las actualizaciones de transacciones deben ser aprobadas y compartidas entre muchas partes que no son de confianza. En Hyperledger Sawtooth, la lógica de negocio para una aplicación, el modelo de datos que se usa para registrar y almacenar datos de estado y la lógica del cliente se definen como una aplicación Sawtooth, también llamada familia de transacciones. Una aplicación consta de un procesador de transacciones (la lógica del lado del servidor) y uno o más clientes (para usar desde la web, la línea de comandos de la CLI o las aplicaciones móviles).

Una familia de transacciones define un conjunto de operaciones o tipos de transacciones que están permitidos en los ledgers distribuidos. Esto permite flexibilidad en el nivel de versatilidad y riesgo que existe en una red. Las familias de transacciones pueden proporcionar smart contracts ‘más seguros’, porque especifican un conjunto predefinido de plantillas aceptables de smart contracts, en oposición a la programación de smart contracts desde cero.

Procesadores de transacciones

Los procesadores de transacciones ejecutan la lógica de negocio en servidor. La mayoría de nodos ejecutan varios procesadores de transacciones, uno por cada caso de uso específico o aplicación. Cada nodo en la red de Sawtooth ejecuta un conjunto idéntico de procesadores de transacciones

Debido a que Hyperledger Sawtooth separa la capa de aplicación de la capa de consenso y del marco principal, las empresas pueden desarrollar procesadores de transacciones que hacen exactamente lo que necesitan sus aplicaciones.

Cada nodo dentro de la red Hyperledger Sawtooth ejecuta al menos un procesador de transacciones (la mayoría de las redes ejecutan varias). Cada procesador de transacciones maneja sus propias transacciones entrantes según lo enviado por clientes autorizados. Hyperledger Sawtooth permite a los desarrolladores de aplicaciones especificar un espacio de nombres para cada procesador de transacciones (un rango de direcciones específico de la aplicación en estado), que proporciona flexibilidad para definir, compartir y reutilizar datos entre procesadores de transacciones. El uso de namespaces en el estado global permite a los programadores centrarse en el desarrollo de la lógica de aplicaciones, en lugar de crear mecanismos de comunicación entre los procesadores de transacciones.

Los procesadores de transacciones de Hyperledger Sawtooth se pueden escribir en una variedad de idiomas, incluidos Javascript, Java, Rust, Python y Go, lo que permite flexibilidad para que las empresas creen sus propias aplicaciones. Hyperledger Sawtooth proporciona SDK en varios idiomas comunes.

Red

La capa de red que es responsable de comunicar entre validadores en una red de Hyperledger Sawtooth, incluyendo la conectividad inicial, peer discovery y envío de mensajes.

Cada organización que ingresa en la red de Sawtooth ejecuta al menos un nodo validador y recibe bloques que son transmitidos por nodos pares. Cada nodo validador ejecuta las siguientes cosas:

  • El proceso de validación
  • La API REST (opcional) para escuchar solicitudes tales como publicaciones de transacciones o consultas de estado
  • Uno o más procesadores de transacciones
  • Una API REST es opcional, los clientes pueden usar una API REST externa o comunicarse directamente con el validador usando ZeroMQ y búferes de protocolo (protobufs).

 

Algoritmo de consenso

Una característica clave de Hyperledger Sawtooth es su flexibilidad al permitir diferentes algoritmos de consenso. Como recordatorio, el algoritmo de consenso determina qué nodo de la red publicará el próximo bloque en el libro mayor. Hyperledger Sawtooth proporciona una interfaz abstracta que admite los algoritmos de tipo PBFT y Nakamoto. El consenso en Sawtooth es modular, lo que significa que el algoritmo de consenso se puede modificar fácilmente.

Proof of Elapsed Time (PoET) es el algoritmo de consenso que implementa consenso basado en el tiempo, lo cual reduce el consumo energético en grandes redes distribuidas cuando se compara con Proof of Work. Es un sistema de lotería aleatorio, que elige pares individuales para ejecutar transacciones. Es  de estilo Nakamoto y está diseñado para ser un protocolo de grado de producción capaz de soportar redes grandes. El algoritmo tiene un modo de desarrollo (DEV)  que es un algoritmo simplificado de líder aleatorio útil para el desarrollo y la prueba en redes de un solo nodo o pequeñas.

La gran ventaja del algoritmo PoET frente a Prueba de trabajo (PoW) implementado por Bitcoin en que PoW consume grandes cantidades de energía, mientras que la prueba de tiempo transcurrido es capaz de garantizar la confianza y la aleatoriedad al elegir un líder sin el alto consumo de energía.

PoET está disponible en dos versiones:

  • PoET-SGX, que depende de Intel® Software Guard Extensions (SGX) para implementar un sistema de lotería de elección de líderes
  • Simulador PoET, que es el algoritmo de consenso PoET desplegado en un simulador SGX.

Funciona de la siguiente manera. Cada validador dentro de la red solicita un tiempo de espera desde un enclave o una función de confianza. Aquí es donde entra en juego el ‘Tiempo transcurrido’. El validador con el tiempo de espera más corto para un bloque específico es nombrado líder y crea el bloque que hará commit contra el ledger. Como resultado, se elige un líder aleatorio, y la capacidad de computación que tiene no le dará una ventaja. Utilizando funciones simples, la red puede verificar que el validador ganador realmente ‘ganó’, demostrando que tuvo el menor tiempo de espera antes de asumir la posición de liderazgo.

Si bien PoET proporciona muchos beneficios y ayuda tremendamente con la escalabilidad, existe una desventaja en el algoritmo de consenso PoET. Y ese es el tema de los forks. El algoritmo PoET puede conducir un estado en el que dos “ganadores” proponen un bloqueo. Cada fork debe ser resuelto por validadores, y esto da como resultado un retraso para alcanzar coherencia en la red.

 

Características Destacables

Algunas características que quiero destacar sobre Sawtooth son:

  • Permite sistemas anónimos o autorizados
  • Un motor paralelo de ejecución de transacciones.
  • Soporte de Smart Contracts de Ehereum (Solidity)
  • Sistema de consenso dinámico que nos permite cambiar en caliente los algoritmos de consenso.
  • Múltiples lenguajes de desarrollo.

 

Hyperledger Iroha. Introducción y funcionamiento.

Hyperledger Iroha forma parte del ecosistema hyperledger. Iroha cumple tres propósitos generales:

  1. Proporciona un entorno para que los desarrolladores de C ++ contribuyan a Hyperledger
  2. Proporciona infraestructura para soporte de aplicaciones móviles y web
  3. Proporcionar un framework para crear APIs y un nuevo algoritmo de consenso

Arquitectura de Iroha y participantes de la red

Describo a continuación los puntos más importantes de la arquitectura de Hyperledger Iroha:

  • Torii (gate) – Este elemento proporciona los interfaces de entrada y salida de los clientes, a través de un modelo basado en grpc (grpc.io). Las llamadas no son bloqueantes, lo que hace de Torii un servicio asíncrono.
  • El consenso está a cargo de que los pares acuerden el contenido de la cadena en la red. El mecanismo de consenso utilizado por Iroha es YAC (Yet Another Consensus), que es un algoritmo tolerante a errores bizantino basado en votar por block hash.
  • Los validadores comprueban las reglas de negocio la validez (formato correcto) de las transacciones o consultas. Hay dos tipos distintos de validación que ocurren en Hyperledger Iroha: La validación sin estado (stateless) es rápida y realiza chequeos de esquema y firma de la transacción. Por otro lado, la validación  con estado (stateful) es más lenta y verifica permisos y el estado actual del sistema, para ver si son posibles las reglas y políticas de negocio deseadas. Por ejemplo, ¿una cuenta tiene fondos suficientes para transferir?
  • Simulator genera una instantánea temporal de lo almacenado para validar las transacciones ejecutándolas en esta instantánea y formando una propuesta verificada, que consiste únicamente en transacciones válidas.
  • Synchronizer ayuda a sincronizar nuevos pares en el sistema o pares desconectados temporalmente.
  • Ametsuchi es el almacenamiento de blockchain que consta de un índice de bloque (actualmente Redis), un almacén de bloque (archivos actualmente planos) y un componente de “world state view” (actualmente PostgreSQL).

Por otra parte, hay tres participantes principales en una red de Iroha:

  • Los clientes, que pueden o bien consultar datos a los que tienen acceso / permiso
    o realizar una acción de cambio de estado, ‘transacción’, que consiste en operaciones atómicas, llamadas ‘comandos’. Por ejemplo, en una sola transacción, un usuario puede transferir fondos a tres personas (tres comandos separados). Pero, si él / ella no tiene fondos suficientes para cubrir para todos, la transacción completa será rechazada.
  • Los pares, que mantienen el estado actual y su propia copia del libro mayor (ledger). Hyperledger Iroha está diseñado para que un único par pueda ser una sola computadora o escalar para crear un clúster, lo que significa que se utilizan diferentes computadoras para el almacenamiento del ledger, de los índices, validaciones y lógica p2p.
  • Ordering Service, que ordena las transacciones de órdenes de servicio en un pedido conocido. Hay algunas opciones para el algoritmo utilizado, pero una de las opciones más populares es Apache Kafka.

YAC (Yet Another Consensus)

Hyperledger Iroha actualmente implementa un algoritmo de consenso llamado YAC (Yet Another Consensus), que se basa en votar por hash de bloques. El consenso implica tomar bloques después de que hayan sido validados, colaborar con otros bloques para decidir el commit y propagar los commits entre pares. El consenso de YAC cumple dos funciones: ordenamiento y consenso.

El servicio de ordenación es responsable de ordenar todas las transacciones, empaquetarlas en propuestas y enviarlas a sus pares en la red. El servicio de ordenación es un punto final para establecer un orden de las transacciones y su emisión (en forma de propuesta). Ordering no es responsable de realizar la validación stateful de las transacciones.

El algoritmo es básicamente el siguiente:

  1. El servicio de orden comparte una propuesta para todos los pares. Una propuesta es un bloque sin firmar creado y compartido por sus pares en la red por el servicio de orden. Contiene un lote de transacciones ordenadas.
  2. Los pares calculan el hash de una propuesta verificada y lo firman. La tupla <Hash, Signature> resultante se denomina voto.
  3. En función de los hashes creados en el paso anterior, cada par calcula una lista de ordenes u orden de pares. Para hacer esto, la función de ordenar necesitará tener conocimiento de todos los pares que votan en la red, y se basa en el hash del bloque propuesto. El primer par en la lista se llama el líder. El líder es responsable de recolectar los votos de otros pares y enviar el mensaje de commit.
  4. Cada par vota y el líder recolecta todos los votos y determina la mayoría de votos para un cierto hash. El líder envía un mensaje de confirmación que contiene los votos del bloque de confirmación. Esta respuesta se llama commit.
  5. Después de recibir la confirmación, los pares verifican la confirmación y aplican el bloque al ledger. En este punto, el consenso está completo.

En el caso de que el líder falle o caiga su servicio (tarda mucho en responder con un commit o no recoje todos los votos, por ejemplo), otros pares establecen un tiempo para recibir un mensaje de commit del líder. Si el temporizador expira, el siguiente interlocutor en la lista de transacciones se convierte en el nuevo líder.

Flujo de transacciones de Iroha

El flujo de una transacción en Iroha es el siguiente:

  1. Un cliente envía una transacción a Torii, que enruta la misma hacia un par que hará la validación stateless.
  2. Una vez validada sin estado la transacción, se envía al servicio de ordenación.
  3. El servicio de ordenación, una vez ordena correctamente las transacciones, las envía a los pares en forma de proposals. Estas proposals contienen un conjunto de transacciones ordenadas. El servicio de ordenación hace estas proposals con un número dado de transacciones ordenadas. Para evitar que esto suponga un bloqueo, si no se reciben en un tiempo delimitado suficientes transacciones para un proposal, el proposal se enviará con las transacciones que hayan al cumplir este tiempo.
  4. En este momento, cada par realizará la validación con estado (stateful) en el Simulator y creará un bloque que consiste tan sólo en transacciones validadas. Este bloque se envía a la consensus gate, que ejecuta la lógica del algoritmo de consenso YAC.
  5. Se determina una lista ordenada de pares y se elige un líder según la lógica de consenso de YAC. Cada par emite un voto firmando y enviando su bloque propuesto al líder.
  6. Si el líder recibe suficientes bloques propuestos y firmados (es decir, más de dos tercios de los pares), entonces comienza a enviar un mensaje de commit, indicando que este bloque debe aplicarse a la cadena de cada par participante en el consenso. Una vez que se ha enviado el mensaje de commit, el bloque propuesto se convierte en el siguiente bloque de la cadena de cada par a través del Synchronizer.

Librerías de desarrollo móvil

Una de las características más definitorias de Hyperledger Iroha es su enfoque en proporcionar librerías móviles. Uno de los principales objetivos de Hyperledger Iroha es crear un sistema de ledger distribuido en el  que las aplicaciones puedan utilizar de forma fácil. Para lograr esto, existen librerías open source para iOS, Android y Javascript. Estas bibliotecas permiten una compatibilidad sencilla no solo con Hyperledger Iroha, sino también, potencialmente, con otras redes a través de funciones API flexibles.

Android: https://github.com/hyperledger/iroha-android
iOS: https://github.com/hyperledger/iroha-ios

 

 

 

 

 

 

Big Data Analytics en laboratorios. #esalud

El creciente volumen de datos de una multitud de fuentes ofrece oportunidades para mejorar la atención médica. Los laboratorios clínicos tienen un papel clave que desempeñar en el análisis e interpretación de esos datos, proporcionando así a los profesionales de la salud información para guiar la toma de decisiones. Los laboratorios han sido históricamente un servicio transaccional, se recibe un pedido, se recoje el espécimen, se realiza un examen, se informan los resultados y se acaba ahí. Sin embargo, en aras de aumentar el valor clínico (y económico) de los laboratorios, el big data y business analytics será una herramienta fundamental para ese análisis.

Cómo los laboratorios han utilizado el análisis de datos

Los profesionales de laboratorio han sido expertos en generar resultados de pruebas y grandes datos durante muchas décadas. Colectivamente, se generan miles de millones de resultados cada año y una gran proporción de los sistemas de información hospitalaria se centran en los laboratorios y los datos de laboratorio. Hay más experiencia para evaluar datos entre los laboratoristas que en cualquier otro grupo de profesionales de la salud. Comenzamos observando los resultados de las pruebas, las pruebas de competencia, los datos de control de calidad, las distribuciones de los resultados de las pruebas de los pacientes y las evaluaciones de los métodos. Hemos estado utilizando datos para determinar las causas raíz de fallas, defectos y oportunidades.

De los datos a las estadísticas

Los grandes conjuntos de datos recopilados por los laboratorios proporcionan una base para comprender las enfermedades emergentes y rastrear las enfermedades crónicas. Al agregar y analizar datos de estos grandes repositorios obtenemos información que nos permite enfocar las intervenciones donde más se necesitan y monitorear el éxito de las diferentes intervenciones.

¿Qué podemos analizar? Visión general.

Algunas ideas nos las puede dar la bibliografía, por ejemplo en “A real‑time dashboard for managing pathology processes” establece unos pasos para la realización de un dashboard para laboratorios:

Captura de pantalla 2018-06-14 a las 12.43.54

En el punto 12, como vemos, establece una necesidad para la planificaición de carga de manera predictiva (punto 12 del ciclo 3). Por lo tanto, la carga predictiva de un laboratorio parece un punto en el que se puede avanzar.

En este artículo se indica:

Requisito 12: planificación de la carga de trabajo: pronostica la duración futura del trabajo utilizando modelos de predicción y ayuda a los gerentes con la planificación del flujo de trabajo para evitar los cuellos de botella

Por otra parte, en “Clinical laboratory analytics: Challenges and promise for an emerging discipline”  tiene varios ejemplos pero en todos incluye la informació financiera y de historia de salud en DataWarehouses.

Más concreto parece “Predictive Analytics to Support Real-Time Management in Pathology Facilities” sí tiene varias propuestas que podrían ser relevantes en un ámbito general de laboratorio.

Predecir el número de pruebas entrantes por tipo

Los laboratorios operan en un entorno en constante cambio y aparentemente impredecible.Esta situación hace que sea difícil asignar correctamente los recursos dentro de un servicio de laboratorio, por ejemplo, en términos de programar el número óptimo de técnicos de laboratorio en un día determinado.

Un objetivo a largo plazo es abordar esta problemática mediante la recuperación de datos relevantes de la carga del laboratorio para que las herramientas de data mining del LIS puedan acceder. Los datos históricos sobre pruebas pasadas y tipos de casos nuevos nos permitirán desarrollar modelos predictivos utilizando técnicas estadísticas. A saber, utilizaremos variables relevantes a la complejidad  y número de casos como la variable dependiente y desarrollaremos modelos de regresión logística para predecir el comportamiento de esta variable en el futuro. Simultáneamente, extraeremos datos de laboratorio para desarrollar asociaciones entre la complejidad del caso y los atributos específicos que podamos recuperar, como el número de diapositivas, manchas utilizadas, etc. En esta etapa de nuestro trabajo, esperamos basarnos en métodos de minería de datos no supervisados, como la asociación o fundamentalmente técnicas de regresión.

Predecir la carga de trabajo

La necesidad de medir la carga de trabajo en un servicio de laboratorio es crítica para la gestión a fin de mantener los niveles de servicio apropiados. Si bien podemos estimar de forma analítica o por la experiencia la carga de trabajo del laboratorio, estimar la carga de los recursos disponibles y  la carga total de laboratorio por recurso o tipo de recurso. Asimismo, con medidas de complejidad podemos obtener la capacidad de cada uno de los recursos y además predecir la capacidad futura de los recursos en formación.

Podremos utilizar los datos anotados con tiempos y dedicación como una entrada a un modelo de optimización estocástica para predecir la carga de trabajo de los recursos disponibles teniendo en cuenta su disponibilidad, subespecialidades, priorización de los casos y variaciones de sesión. Tener ese poder predictivo debería permitir a los administradores de las instalaciones planificar mejor la asignación de recursos humanos por subespecialidades, desarrollar horarios de trabajo flexibles (incluidos los recursos “flotantes” cuando estén disponibles) y preparar contingencias para eventos inesperados.

Predecir el rendimiento del proceso

Existen varios cuellos de botella potenciales en un proceso de laboratorio, desde el momento en que se reciben los casos hasta el momento en que se envía el informe de patología. Para ayudar a administrar el proceso y aprovechar al máximo los recursos disponibles, es importante capturar datos precisos en cada punto de entrada y salida en cada paso del proceso. Sin embargo, esto puede requerir un cambio en las prácticas y el equipo.

Si nos atenemos de forma meramente ilustrativa al proceso clínico de laboratorio modelado por el Ministerio de Sanidad de Chile, un proceso de laboratorio puede ser semejante a este:

Captura de pantalla 2018-06-14 a las 14.14.13.pngLa captura de datos en los momentos en que un elemento deja una estación y se mueve a otra daría información más precisa de la cual predice el rendimiento futuro. Además, aunque los tiempos de procesamiento en algunos casos son fijos y no pueden ser realmente manipulados (por lo tanto, actúan como parámetros fijos), hay algunos que pueden verse influidos al agregar recursos adicionales al procesamiento.

El modelo de predicción de rendimiento en tiempo real resultante podría monitorear el volumen real de informes que están en un proceso, que están esperando aceptación, que están siendo analizados o que están informándose, representando así una medida de desempeño general para un servicio de laboratorio. Más allá de la medición del rendimiento, los modelos de simulación podrían simular diferentes estrategias para tratar los cambios en los casos entrantes y los parámetros de la carga de trabajo, y estar asociados con el modelo de predicción del rendimiento. Una vez que un modelo detecta la desviación del rendimiento previsto (para un contexto dado descrito como día de un mes, etc.), automáticamente consulta uno de los escenarios y lo aplica (o lo presenta a un administrador) para detectar la anomalía detectada. ser dirigido.

Estas técnicas analíticas se corresponden a los modelos de process mining en desarrollo por la Eindhoven University of Technology y sirven para:

  • Descubrimiento del proceso real
  • Compliance de lo ejecutado con el proceso
  • Mejora del proceso
  • Detección de cuellos de botella

Otras herramientas de análisis según nuestra investigación

Para nuestra investigación hemos analizado unos 39.000 informes de laboratorios anonimizados. Con las restricciones en el número de campos hemos detectado varias posibilidades para data mining en procesos de laboratorio, aplicando varias técnicas.

Clusterización de pacientes

El objeto de una clusterizacion de pacientes es ubicar o asignar estadísticamente los pacientes por tipos. Estos tipos serán aquellos que tienen un comportamiento similar en base a las variables de entrada que se consideran relevantes (estadísticamente relevantes) En nuestro sencillo análisis de los datos (Usando las herramientas estadísticas de knime) realizamos el siguiente flujo:

 

Básicamente realizamos un análisis jerárquico previo para intentar detectar el posible número de clusters en el sistema. Hay que decir que los datos incorporados no disponen de variables que sin duda serían muy relevantes, como el servicio de origen o el diagnóstico primario del paciente. El dendograma resultante es el siguiente:

Captura de pantalla 2018-06-14 a las 14.32.53.png

Vemos que a a partir del dendograma, y con las variables que disponemos, relativamente pronto se generan 3 clusters, así que probamos la clusterización por el método de k-medias con tres clusters, y el resultado en un scatterplot, teniendo edad y número de informes es el siguiente:

Captura de pantalla 2018-06-14 a las 14.36.10.png

Básicamente tendríamo 3 clusters de paciente en base a su edad y frecuentación, los primeros serían los jóvenes poco frecuentadores (azul), siguiendo con los jóvenes hiperfrecuentadores (rojo) y los mayores. Hay que decir que en esta muestra sólo se han analizado sexo, frecuentación, y laboratorio. Sistemas más complejos podrían disponer de muchas más variables para la entrada de un cluster, y sería un modelo multidimensional.

¿Con qué objetivo clusterizamos un paciente? Primero,  como herramienta para posteriores estudios de regresión, esto es, tener un dato más y, teniendo en cuenta el cluster o grupo al que pertenece un paciente realizar un modelo predictivo sobre el  conjunto del cluster. Segundo, para filtrar y disponer de una clasificación con sentido estadístico en las herramientas de BI. El sistema retroalimentaria las herramientas de BI pudiendo filtrar los datos por el cluster a que pertenece.

Otra prueba efectuada es la media de determinaciones por informe. Otro resultado de clustering es el siguiente, también con dos dimensiones, según la edad del paciente:

Captura de pantalla 2018-06-14 a las 16.23.25

Estos resultados se pueden combinar de muchas maneras.

Estadística predictiva: Correlación

 

En probabilidad y estadística, la correlación indica la fuerza y la dirección de una relación lineal y proporcionalidad entre variables estadísticas. Para ello hemos hecho un estudio simple. El primero de los aspectos es un análisis de PCA que nos indicará entre qué variables hay una correlación, para posteriormente analizar esa correlación y hacer predicciones de variables.

Captura de pantalla 2018-06-14 a las 16.29.39

En el modelo vemos cierta correlación negativa entre la media de determinaciones por informe y el sexo. Teniendo en cuenta que hemos llamado “0” a hombre y “1” a mujer, podemos predecir que a más edad y siendo mujer, menos determinaciones por informe.

Captura de pantalla 2018-06-14 a las 16.43.40.png

Este tipo de resultados valdría para generar fórmulas y conocer el coste predictivo de cada nuevo paciente. Con estudios con fechas podríamos ver el tiempo entre pruebas, etc.

Estadística predictiva: Regresión

Los estudios de regresión nos permitirán precedir el comportamiento de una variable (llamada dependiente) a partir de otra serie de variables (llamadas independientes). Los estudios de regresión nos permitirían ver el comportamiento de los indicadores de laboratorio, no sólo desde un punto de vista de análisis de datos o BI, sino realizar las gráficas predictivas de cómo estarán estos indicadores en el futuro.

Cada uno de los KPI’s calculados son susceptibles de un análisis de regresión, si estos KPI tienen una evolución temporal. Por ejemplo, para calcular la carga de trabajo en un laboratorio concreto, se establece la siguiente regresión, tomando en cuenta la temporalidad de los datos:

Captura de pantalla 2018-06-14 a las 16.54.57

En este caso, es una regresión polinomial para el cálculo de la previsión de informes en base al mes (básicamente 6.7m – 0.5 m2 +16) que se aplicaría directamente sobre el mes m.

Estas regresiones, como comentamos, se pueden generar para todos los KPI que se generen a partir de series temporales o tengan temporalidad dichos KPI. Estos modelos pueden usar la regresión lineal o un model Holt-Winters para su desarrollo, que permite centrar mejor la estacionalidad, como en el siguiente gráfico:

JPI-8-7-g007

Ejemplos de variables que pueden ser susceptibles de modelos predictivos:

  • Carga de trabajo total
  • Carga de trabajo por servicio solicitante
  • Carga de trabajo por determinaciones / máquinas
  • Tiempos de respuesta
  • Coste por servicio/ determinaciones / total

 

Detección de resultados anómalos

 

Algunos estudios muestran evidencias relacionadas con business analytics que pueden predecir el comportamiento del resultado de las pruebas y detectar resultados anómalos. Es posible, por lo tanto, generar modelos de redes neuronales a tal efecto.

Algún estudio había definido algoritmos de verificación para pruebas hematológicas o pruebas bioquímicas como la glucosa, el sodio y el potasio. En estos estudios, los criterios de evaluación se definieron utilizando enfoques basados en lógica, simples y basados en reglas (if-then-is) . Estos enfoques simples basados en reglas tienen criterios de evaluación limitados y no están abiertos al desarrollo continuo. En la actualidad, el enfoque de la red neuronal artificial (ANN, por sus siglas en inglés) permite el uso de más biomarcadores en el diagnóstico de una enfermedad, está abierto por naturaleza a un desarrollo continuo.

Tomando como entrenamiento los datos y la información de corrección, en aquello casos que haya sido necesario, se elaboraría el modelo neuronal que clasificaría los casos en aquellos “válidos” y en aquellos que considere “anómalos”, informando al especialista de laboratorio de dicha circunstancia.

 

Referencias

Aplicaciones de Blockchain: Para qué lo podemos usar

Hay ciertos factores a considerar cuando se evalúa la tecnología de blockchain. Com norma general, Blockchain será útil en los siguientes casos:

  • Necesitamos una base de datos compartida entre varias sedes u organizaciones.
  • No es necesaria confianza mutua entre las partes involucradas en el proceso
  • Hay múltiples partes involucradas o escritores en una base de datos
  • Existen hoy en día terceros en los que confiamos como fedatarios (como un notario)
  • La criptografía se está utilizando actualmente o debería usarse.
  • Los datos de un proceso de negocio se ingresan en muchas bases de datos diferentes a lo largo del ciclo de vida del proceso y es importante que estos sean consistentes.
  • Hay reglas uniformes que gobiernan a los participantes en el sistema
  • La toma de decisiones de las partes es transparente, en lugar de confidencial
  • Existe la necesidad de un historial objetivo e inmutable o un registro de los hechos para la referencia de las partes
  • La frecuencia de la transacción no supera las 10,000 transacciones por segundo.

No sería de utilidad (o habría que planteársela) si:

  • El proceso involucra datos confidenciales. De hecho, las regulaciones sobre privacidad de datos no permiten la transparencia de blockchain.
  • El proceso almacena una gran cantidad de datos estáticos, o los datos son bastante grandes. Hay que tener en cuenta que almacenamos los datos en varios servidores. A causa de este factor de replicación, no tiene sentido usarlo si los datos cambian poco o bien para datos muy voluminosos.
  • Las reglas de las transacciones cambian con frecuencia. Los smart contracts no están pensados para ello.

De cualquier modo, dejo más abajo algunos ejemplos de aplicaciones actuales o futuras:

  • Las transacciones bancarias pueden hacerse en minutos, en lugar de en horas o días. La banca desde hace mucho tiempo no solo tenía libros contables, sino la necesidad de conciliar esos libros en todas las organizaciones bancarias. Cuando realizas una transferencia de un banco a otro, se envía un mensaje con la transferencia, pero esos bancos tienen un proceso de reconciliación que puede llevar días. El proceso de reconciliación en un ledger distribuido podría considerarse “instantáneo”
  • Certificación de la procedencia de diamantes, pescado o cualquier otra materia en la cual haya fraude o requiera una autenticidad. Es un registro de propiedad utilizado como guía de autenticidad o calidad. Debido a la sobrecarga involucrada en los registros de procedencia tradicionales, solo estaban disponibles para artículos de gran coste, como obras de arte. Con las eficiencias obtenidas de la tecnología blockchain, los registros de procedencia pueden estar disponibles para una gama más amplia de productos. Esta información mejorada puede ayudar a los consumidores a medida que toman decisiones de compra. Empresas certificadoras pueden aprovechar blockchain, registrar sus auditorías e inspecciones. Esto reduciría los gastos generales necesarios para certificar productos. Como consumidor que lee de una cadena de bloques, podríamos verificar la autenticidad de un producto al ver la cadena de custodia completa de un artículo.
  • Sistemas de identidad, como el DNI, descentralizados y comprobables, como el proyecto Aadhar en la India, que permitan garantizar la privacidad
  • Derechos de propiedad de activos. La propiedad de un activo en particular puede transferirse en su totalidad o en parte. Como resultado, los derechos de propiedad u obligaciones vinculados a un activo en particular pueden pertenecer a varias entidades diferentes al mismo tiempo. Por ejemplo, si compra un terreno, tiene derecho a usarlo. Sin embargo, el uso del terreno probablemente esté limitado por las leyes o el gobierno local. El derecho de uso de la tierra puede ser quitado de la ejecución hipotecaria si no paga los impuestos a la propiedad. De manera similar, su derecho a usar la tierra está limitado a los usos permitidos según las leyes de zonificación de esa zona.
  • Derechos de propiedad intelectual. Un blockchain puede registrar un hash de un documento. Como ejemplo, los fotógrafos pueden colocar un hash de sus fotografías digitales únicas en la cadena de bloques. El hash de una fotografía digital será constante siempre que el archivo de la fotografía no haya sido alterado. Por lo tanto, el blockchain puede controlar y rastrear la distribución de la fotografía, detectar la introducción de imágenes falsas y usarse para resolver disputas sobre quién introdujo la imagen por primera vez.
  • Gestión de cadenas de suministro. Permitiendo sistemas lean o just-in-time, sin los problemas actuales. Actualmente, hay puntos débiles en la administración de la cadena de suministro. Estos puntos débiles ocurren cuando hay varios sistemas ERP en uso en todas las organizaciones. Los datos no fluyen bien a través de los handshakes o puntos de interfaz entre los sistemas. Estos puntos débiles generalmente ocurren durante la transferencia de propiedad, o cambio en el estado entre dos partes. La visibilidad está limitada en los puntos de entrega de fondos, materias primas, componentes o productos terminados.
  • Registros educativos, añadiendo los títulos oficiales que se obtienen, para evitar tener problemas con algún máster, por ejemplo. Es muy importante por ejemplo en certificaciones para médicos, sobretodo a nivel internacional.
  • Historia de salud (historia clínica), donde diferentes entidades pueden añadir episodios, permitiendo una historia clínica única.
  • Seguros médicos, para su verificación, procesamiento de reclamaciones, etc…
  • Procesos de compliance de medicamentos recetados en blockchain, ya que implican la recopilación y verificación de información de muchas fuentes. Se verifican los requisitos de autorización / prescripción previa y terapia escalonada para ver si un paciente puede recibir un medicamento en particular o si se prefieren otros medicamentos. Se deben realizar todos los chequeos de los formularios, los cheques de asistencia a los pacientes y las verificaciones de existencias de las farmacias.

Módulos de Hyperledger: Cello y Composer

 

Como continuación del post Blockchain Hyperledger: Introducción, vamos a analizar algunos módulos de Hyperledger.

Hyperledger Cello

Para las empresas que quieren implementar un Blockchain-as-a-Service, Hyperledger Cello proporciona un conjunto de herramientas que cumplen con esta necesidad. Particularmente para PYMES que desean reducir o eliminar el esfuerzo requerido en la creación, gestión y terminación de blockchains, Hyperledger Cello permite el despliegue de blockchains en la nube. Los diferentes operadores pueden crear y administrar dichas cadenas de bloques a través de un tablero de instrumentos, y los usuarios (por lo general, desarrolladores de chaincode) pueden obtener una instancia de blockchain de forma inmediata.

Cello tiene como objetivo llevar el modelo on-demand SaaS ‘como un servicio’, lo que ayuda a impulsar el desarrollo y la implementación de los frameworks de Hyperledger. Hyperledger Cello fue inicialmente aportado por IBM, con patrocinadores de Soramitsu, Huawei e Intel.

Los desarrolladores de aplicaciones y administradores de sistemas que usan Cello pueden aprovisionar y mantener redes de Hyperledger. Por ejemplo, se puede crear un grupo de ledgers distribuidos en clústers de contenedores y, luego, administrar y monitorizar esas redes con un dahsboard configurable. Además, se puede construir una plataforma Blockchain-as-a-Service (BaaS).

Hyperledger-Cello-to-govern-multi-tenant-blockchain-as-a-service-v2

Hyperledger Explorer

Hyperledger Explorer es una herramienta para visualizar las operaciones de blockchain. Es el primer explorador de blockchain para los ledgers autorizados, lo que permite a cualquier persona explorar los proyectos de ledgers distribuidos que están siendo creados por los miembros de Hyperledger desde dentro de la red, sin comprometer su privacidad. El proyecto fue contribuido por DTCC, Intel e IBM.

Diseñado para crear una aplicación web fácil de usar, Hyperledger Explorer puede ver, invocar, implementar o consultar:

  • Bloques
  • Transacciones y datos asociados
  • Información de red (nombre, estado, lista de nodos)
  • Smart Contracts (códigos de cadena y familias de transacciones)
  • Otra información relevante almacenada en el ledger.

La capacidad de visualizar datos es de importancia crítica, a fin de extraer valor de ella. Hyperledger Explorer proporciona esta funcionalidad. Los componentes clave incluyen un servidor web, una interfaz de usuario web, sockets web, una base de datos, un repositorio de seguridad y una implementación de blockchain.

hyperledger-exolorer-incubation-v11.gif

Hyperledger Composer

Hyperledger Composer es uno de los módulos más interesantes y que será en un futuro uno de los más populares, ya que proporciona un conjunto de herramientas para desarrolladores que facilitan la tarea de construir redes de blockchain.

Hyperledger Composer ha creado un lenguaje de modelado que le permite definir los activos, los participantes y las transacciones que conforman la red utilizando vocabulario del dominio. Además, la lógica de transacción la escriben los desarrolladores que usan Javascript. Esta interfaz simple permite a las personas de negocios y tecnólogos trabajar juntos en la definición de su red de negocios.

Estas herramientas te permiten:

  • Modelar la red
  • Creación más rápida de aplicaciones blockchain, eliminando el esfuerzo requerido para construir aplicaciones blockchain desde cero, de hecho generan esqueletos de aplicaciones en AngularJS
  • Generar API REST para interactuar con su red blockchain
  • Riesgo reducido con un diseño eficiente y bien probado que alinea la comprensión entre los analistas funcionales y técnicos
  • Mayor flexibilidad ya que las abstracciones de mayor nivel hacen que sea mucho más simple iterar.
  • Sistema de testing

Construido en Javascript, Hyperledger Composer proporciona un conjunto de componentes fácil de usar que los desarrolladores (especialmente desarrolladores de Javascript) pueden aprender e implementar rápidamente. El proyecto fue contribuido por Oxchains e IBM.

Dejo un video de una introducción a Composer (en inglés)

 

Blockchain Hyperledger: Introducción

Hyperledger es un proyecto open source creado para avanzar las tecnologías blockchain en cualquier tipo de ámbito. Coordinado por The Linux Foundation, es una colaboración global de miembros de diversas industrias y organizaciones. Cuenta en este momento con una gran cantidad de soluciones. Hyperledger se puede ver como un sistema operativo para marketplaces, redes de intercambio de datos, microempresas y comunidades digitales descentralizadas. Intenta asimismo reducir significativamente el coste y la complejidad de los negocios.

Los blockchain de Hyperledger son por lo común “permissioned” o autorizadas (ver Tipos de Blockchain : Públicos y privados ), lo que significa que las partes que se unen a la red están autenticadas mediante un módulo de autenticación y autorizadas para participar en la red. El objetivo principal de Hyperledger es crear frameworks para ledgers distribuidos, open source, con capacidades corporativas y código suficiente para dar respuesta a las necesidades empresariales.

En los blockchain sin permiso, como la cadena de bloques de Bitcoin o la cadena de bloques de Ethereum, cualquiera puede unirse a la red, así como también escribir y leer transacciones. Los actores en el sistema no son conocidos, lo que significa que podría haber algunos actores maliciosos dentro de la red.

Hyperledger reduce estos riesgos de seguridad y garantiza que solo las partes que deseen realizar transacciones sean las que forman parte de la transacción y, en lugar de mostrar el registro de las transacciones en toda la red, solo son visibles para las partes involucradas. Por lo tanto, Hyperledger ofrece todas las capacidades de la arquitectura blockchain: privacidad de datos, intercambio de información, inmutabilidad, una pila completa de protocolos de seguridad, etc.

Hyperledger tiene (mayo-08) muchos proyectos bajo su paraguas:

hyperledger-community-update-feb-20-2018-6-638.jpg

Hay también algunas diferencias fundamentales entre hyperledger y los blockchain sin permiso como Bitcoin o Ethereum que pasamos a resumir:

Bitcoin

Ethereum

Hyperledger

Basado en Criptomonedas

No

Autorizados

No

No

Si, aunque Sawtooth puede configurarse sin permiso

Pseudo-anónimo

No

No

Auditable

Immutable ledger

Modularidad

No

No

Smart contracts

No

Consensus protocol

PoW

PoW

Varios

Componentes de los Frameworks Hyperledger

Los frameworks de blockchain comerciales Hyperledger se utilizan para crear blockchains para uso empresarial. Son diferentes a los públicos como Bitcoin blockchain y Ethereum. Los frameworks de Hyperledger incluyen:

  • Un ledger distribuido de solo adición
  • Un algoritmo de consenso para aceptar cambios en el ledger
  • Privacidad de las transacciones a través de un acceso permitido
  • Contratos inteligentes para procesar solicitudes de transacción.

Components_of_blockchain.jpg

En los siguientes puntos veremos cada uno de estos frameworks.

Hyperledger Iroha

Hyperledger Iroha es un framework diseñado para ser simple y fácil de incorporar en proyectos de infraestructura que requieren tecnología ledger distribuida. Hyperledger Iroha hace hincapié en el desarrollo de aplicaciones móviles con bibliotecas cliente para Android e iOS, lo que lo diferencia de otros marcos de Hyperledger. Inspirado por Hyperledger Fabric, Hyperledger Iroha busca complementar Hyperledger Fabric e Hyperledger Sawtooth, a la vez que proporciona un entorno de desarrollo para que los desarrolladores de C ++ contribuyan a Hyperledger.

Hyperledger Iroha presenta una construcción simple, un diseño C ++ moderno y domain-driven, junto con el algoritmo de consenso YAC.

Hyperledger Sawtooth

Hyperledger Sawtooth, contribuido por Intel, es un framework de blockchain que utiliza una plataforma modular para construir, desplegar y ejecutar ledgers distribuidos. Las soluciones de ledgers distribuidos construidas con Hyperledger Sawtooth pueden utilizar varios algoritmos de consenso basados en el tamaño de la red. Incluye el algoritmo de consenso Prueba de tiempo transcurrido (PoET), que proporciona la escalabilidad de la cadena de bloques de Bitcoin sin el alto consumo de energía. PoET permite una red altamente escalable de nodos de validación. Hyperledger Sawtooth está diseñado para ofrecer versatilidad, con soporte para despliegues autorizados y sin permiso, siendo la única tecnología hyperledger (por el momento) que permite ambos despliegues. Tiene varias características importantes:

  • Dispone de un acuerdo de estado distribuido, lo que implica que todos los nodos dispongan del mismo conocimiento de la información, ningún nodo puede obviar la información de los demás.
  • Es capaz de crear interfaces para cualquier lógica de transacción, en la integración con Hyperledger Burrow consigue poder ejecutar cualquier código de máquina virtual Ethereum, como solidity y ejecutarse en Sawtooth

En un caso de uso de cadena de suministros o procedencia, como veremos en un video más adelante, permite hacer crecer a la red y cambiar los mecanismos de consenso en caliente. Esta característica permite una alta escalabilidad y flexibilidad en este framework.

El siguiente es un bonito video sobre un caso de uso de trazabilidad de procedencia de pescado:

 

Hyperledger Fabric

Hyperledger Fabric fue la primera propuesta para un framework en Hyperledger, que combina el trabajo previo realizado por Digital Asset Holdings, el libconsensus de Blockstream y OpenBlockchain de IBM. Hyperledger Fabric tiene una arquitectura modular, que permite que componentes como el consenso y los servicios de identificación sean plug-and-play. Hyperledger Fabric permite que las entidades realicen transacciones confidenciales sin pasar información a través de una autoridad central. Esto se logra a través de diferentes canales que se ejecutan dentro de la red, así como la división del trabajo que caracteriza a los diferentes nodos dentro de la red. Por último, es importante recordar que, a diferencia de Bitcoin, que es una cadena pública, Hyperledger Fabric admite implementaciones autorizadas. Es útil en casos de uso donde hay una gran red de blockchain y deseas compartir datos sólo con ciertas partes,  ya que permite crear canales privados con esos participantes.

 

La principal diferencia en Hyperledger Fabric con respecto a Bitcoin y Ethereum es que se trata de una implementación de una tecnología de ledger distribuida autorizada.
Bitcoin y Ehereum son redes esencialmente públicas y sin permiso, donde todos pueden unirse anónimamente.

Hyperledger Indy

Hyperledger Indy es un ledger distribuido especialmente diseñado para hacer una identidad distribuida, permite tener un lugar de confianza para administrar las claves, esquemas, pruebas y otra información que necesita, para habilitar las interacciones de pares confiables entre diferentes identidades, tal como se almacenan en una instancia de cadena de bloques de Hyperledger Indy. Esta identidad es propiedad de la persona que subyace a la misma. Se puede usar para compartir diferentes datos correlacionables entre la persona identificada e identidades con las que se desea interactuar, filtrando la información privada y no divulgando información que no se desee compartir.
Uno de los principales usos de Hyperledger Indy es la creación de una utilidad pública global para la identidad que está siendo creada por la Fundación Sovrin.

Según el proyecto:

Hyperledger Indy permite que los usuarios autentiquen la identidad en función de los atributos que desean almacenar y compartir. Esto puede reducir la cantidad de responsabilidad contenida dentro de una empresa porque los datos se pueden mantener con el usuario y volver a presentarlos de una manera que puede confiar y validar que lo que se ha dicho realmente fue dicho y es confiable para las otras partes con las que hace negocios.

Hyperledger Burrow

Conocido formalmente como eris-db, Hyperledger Burrow fue lanzado en diciembre de 2014. Hyperledger Burrow es una máquina de smart contracts autorizada que proporciona un cliente modular de blockchain con un intérprete de smart contracts autorizado incorporado a la especificación del Ethereum Virtual Machine (EVM). Es la única implementación de EVM con licencia de Apache.

Los siguientes son los principales componentes de Burrow:

  • El Gateway proporciona interfaces para integración de sistemas e interfaces de usuario
  • El motor de aplicación de smart contract facilita la integración de la lógica de negocio compleja
  • Consensus Engine tiene el doble propósito de:
    • Mantener la pila de red entre los nodos
    • Pedidos de transacciones
  • La Application Blockchain Interface (ABCI) proporciona la especificación de la interfaz para el motor de consenso y el motor de aplicación de smart contracts para conectarse.

Crea un blog o un sitio web gratuitos con WordPress.com.

Subir ↑