Buscar

Blog de Alfonso Tienda

Marketing, Startups, Proyectos y Tecnología.

Categoría

Uncategorized

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.

 

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: Algoritmos de consenso

El consenso en la red se refiere al proceso de lograr un acuerdo entre los participantes de la red sobre el estado correcto de los datos en el sistema. El consenso lleva a que todos los nodos compartan exactamente los mismos datos. Un algoritmo de consenso, por lo tanto, hace dos cosas: asegura que los datos en el libro mayor o ledger son los mismos para todos los nodos de la red y, a su vez, evita que actores malintencionados manipulen los datos. El algoritmo de consenso varía con las diferentes implementaciones de blockchain.

Mientras que la cadena de bloques de Bitcoin utiliza Prueba de trabajo (proof of work) como algoritmo de consenso, otros blockchains y ledgers distribuidos están implementando una variedad de algoritmos de consenso, como Proof of Stake, Proof of Burn, Proof of Capacity, Proof of Elapsed Time y muchos otros, dependiendo en sus requisitos únicos.

Proof of Work (PoW)

El algoritmo de consenso de prueba de trabajo implica resolver un desafío computacional complejo y pesado con el fin de crear nuevos bloques en la cadena de bloques de Bitcoin. Coloquialmente, el proceso se conoce como ‘minería’, y los nodos de la red que se dedican a la minería se conocen como ‘mineros’. El incentivo para las transacciones mineras radica en los pagos económicos, donde los mineros que compiten son recompensados ​​con 12.5 bitcoins y una pequeña tarifa de transacción. La prueba es difícil de crear pero fácil de verificar.

Existen múltiples críticas para el algoritmo de consenso PoW. PoW requiere una gran cantidad de energía, dado el algoritmo computacionalmente pesado. Además, PoW tiene una alta latencia de validación de transacciones, y la concentración de la potencia minera se encuentra en países donde la electricidad es barata. En términos de seguridad de la red, PoW es susceptible al ‘51% de ataque ‘, que se refiere a un ataque a un blockchain por un grupo de mineros que controlan más del 50% de la potencia de computación de la red.

Proof of Stake (PoS)

El algoritmo de proof of stake es una generalización del algoritmo de prueba de trabajo. En PoS, los nodos se conocen como los “validadores” y, en lugar de extraer la cadena de bloques, validan las transacciones para obtener una tarifa de transacción. No se debe realizar una minería, ya que todas las monedas existen desde el primer día. En pocas palabras, los nodos se seleccionan aleatoriamente para validar bloques, y la probabilidad de esta selección aleatoria depende de la cantidad de participación que se tenga. Entonces, si el nodo X posee 2 monedas y el nodo Y posee 1 moneda, el nodo X tiene el doble de probabilidades de ser llamado para validar un bloque de transacciones.

La implementación específica de PoS puede variar, dependiendo del caso de uso, o como una cuestión de diseño de software. Las instancias incluyen Proof of deposit y Proof of burn. El algoritmo PoS ahorra costosos recursos computacionales que se gastan en la minería bajo un régimen de consenso PoW.

Proof of Elapsed Time (PoET)

Este algoritmo fue desarrollado inicialmente por Intel. El algoritmo de consenso de Prueba de tiempo transcurrido o proof of elapsed time emula la Prueba de trabajo de estilo Bitcoin. La implementación de Sawtooth de Hyperledger es un ejemplo de PoET.

En lugar de competir para resolver el desafío criptográfico y extraer el próximo bloque, como en el blockchain de Bitcoin, el algoritmo de consenso PoET es un híbrido de una lotería aleatoria y de un orden de llegada. En PoET, cada validador recibe un tiempo de espera aleatorio. El validador con el menor tiempo de espera para un bloque de transacción en particular es elegido líder. Este “líder” crea el siguiente bloque de la cadena.

Para garantizar que efectivamente no se está “mintiendo” para ser el líder del bloque se la cadena, PoET confía en unas instrucciones “seguras” de Intel, ejecuta una instrucción SGX del procesador para generar este tiempo aleatorio de espera.

Simplified Byzantine Fault Tolerance (SBFT)

El algoritmo de consenso SBFT implementa una versión adaptada del algoritmo practical byzantine fault tolerance (PBFT), y busca proporcionar mejoras significativas sobre el protocolo de consenso proof of work de Bitcoin. La idea básica involucra a un único validador que agrupa las transacciones propuestas y forma un nuevo bloque. Tenga en cuenta que, a diferencia de la cadena de bloques de Bitcoin, el validador es una parte conocida, dada la naturaleza permitida del ledger libro mayor. El consenso se logra como resultado de un número mínimo de otros nodos en la red que ratifican el nuevo bloque. Para ser tolerante a errores bizantinos, el número de nodos que debe alcanzar el consenso es 2f + 1 en un sistema que contiene 3f + 1 nodos, donde f es el número de fallas en el sistema. Por ejemplo, si tenemos 7 nodos en el sistema, entonces 5 de esos nodos deben estar de acuerdo si 2 de los nodos están actuando de manera incorrecta.

El ejemplo práctico sería el de ByzCoin, que busca realizar mejoras importantes sobre el protocolo original de Bitcoin. Al abordar el desafío de la escalabilidad debido a la alta latencia, las transacciones de ByzCoin se comprometen irreversiblemente con la cadena de bloques en cuestión de segundos. La ventaja adicional es que los árboles de comunicación optimizan los compromisos de transacción y la verificación en operaciones normales.

Proof of Authority (PoA)

Sólo se puede usar con permissiones ledgers o ledgers autorizados, ya que existen nodos validadores que tienen la autoridad para crear bloques, y están especialmente designados a tal efecto. Los ledgers  que utilizan el PoA requieren la aprobación de la mayoría de los validadores para que se cree un bloque.

Conclusiones

Esta fue una descripción general sobre algún algoritmo de consenso utilizado en el mundo blockchain.  Por supuesto, hay muchos otros posibles. En general, podemos distinguir tres tipos de consenso:

  • El consenso estándar de Prueba de trabajo
  • Consentimiento basado en votación autorizado (PoA, SBFT)
  • Concesión basada en lotería autorizada (PoET)

El consenso que se elija en una implementación de cadena de bloques depende del tipo de red y de los datos manejados.

Los tipos de lotería serían más adecuados para redes grandes. Los tipos de votación son más adecuados para redes más pequeñas y reducen la latencia a un mínimo.

 

 

 

Blockchain: Smart Contracts

En 1996, Nick Szabo acuñó el término smart contract o contrato inteligente.

Los Smart Contracts son simplemente programas informáticos que ejecutan acciones predefinidas cuando se cumplen ciertas condiciones dentro del sistema. Pueden considerarse como protocolos informáticos para facilitar, verificar o hacer cumplir la negociación de un contrato legar. Los Smart Contracts proporcionan el lenguaje de las transacciones que permiten modificar el estado del ledger distribuido. Pueden facilitar el intercambio y la transferencia de cualquier cosa de valor (por ejemplo, acciones, dinero, contenido, propiedad).
Hoy, los contratos inteligentes de Ethereum están diseñados para funcionar en todos los nodos de la red Ethereum.

Blockchain: Inmutabilidad de datos

La inmutabilidad de los datos que se encuentran en el blockchain es quizás la razón más poderosa y convincente para implementar soluciones basadas en blockchain para una variedad de procesos que actualmente se registran en servidores centralizados. Esta característica de inmutabilidad o “inalterable en el tiempo” hace que blockchain sea útil para la contabilidad, las transacciones financieras, la administración de identidades y la propiedad, administración y transferencia de activos, solo por nombrar algunos ejemplos. Una vez que se escribe una transacción en la cadena de bloques, nadie puede cambiarla o, al menos, sería extremadamente difícil cambiarla.

De acuerdo con Antony Lewis, el Director de Investigación en R3,

Cuando la gente dice que las cadenas de bloques son inmutables, no significa que los datos no se puedan modificar, significa que es extremadamente difícil cambiarlo, y si lo intentas, es muy fácil detectar el intento

Profundicemos en esta afirmación un poco más. Es extremadamente difícil cambiar las transacciones en un blockchain, porque cada bloque está vinculado al bloque anterior al incluir el hash del bloque anterior. Este hash incluye el hash de raíz de Merkle de todas las transacciones en el bloque anterior. Si una sola transacción fuera a cambiar, no solo cambiaría el hash raíz de Merkle, sino también el hash contenido en el bloque modificado. Además, cada bloque subsiguiente debería actualizarse para reflejar este cambio. En el caso del modelo de consenso de prueba de trabajo o proof of work, la cantidad de energía requerida para volver a calcular la ausencia de este bloque y cada bloque subsiguiente sería prohibitiva. Por otro lado, si alguien modificó una transacción en un bloque sin realizar los pasos necesarios para actualizar los bloques subsiguientes, sería fácil recalcular los valores hash usados ​​en los bloques y determinar si algo anda mal.

Veamos un ejemplo de cómo funciona esto. En el siguiente diagrama, vemos los bloques originales y las transacciones para el Bloque 11. Específicamente, vemos que la raíz de Merkle para las transacciones en el Bloque 11 es Hash #ABCD, que es el hash combinado para las cuatro transacciones en este bloque. Ahora, digamos que alguien entra e intenta cambiar la Transacción A por la Transacción A ‘. Esto, a su vez, modifica los hashes que se almacenan en el árbol de Merkle, y la raíz de Merkle cambia a Hash # A’BCD. Además, el hash del Bloque Anterior almacenado en el Bloque 12 también necesita ser modificado para reflejar el cambio general en el hash para el Bloque 11

BLOCKCHAIN_IMMUTABILITY

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

Subir ↑