Descripción general de las API de Sawtooth de Hyperledger

¿Qué es Hyperledger Sawtooth?

Es una plataforma blockchain empresarial que ayuda a desarrollar aplicaciones y redes de contabilidad distribuida. Está diseñada con la filosofía de mantener los registros distribuidos, lo que ayuda a mantener seguros los contratos inteligentes, especialmente cuando se utilizan en empresas. Sawtooth separa el sistema central del dominio de la aplicación. Esto ayuda a simplificar el desarrollo de aplicaciones blockchain. Los desarrolladores de aplicaciones pueden especificar reglas comerciales que sean específicas para sus aplicaciones. Pueden elegir el lenguaje de su elección y no es obligatorio que conozcan el diseño subyacente del sistema central. La naturaleza modular de Sawtooth ayuda a las empresas y consorcios a tomar decisiones políticas. Las aplicaciones pueden elegir sus propios algoritmos de consenso, reglas de transacción y permisos para adaptarse a sus propias necesidades comerciales. Es de código abierto y es un proyecto que se enmarca dentro del paraguas de Hyperledger.

Ayuda a los desarrolladores a crear contratos inteligentes en varios lenguajes como Python, C++, Javascript, Go, Java y Ethereum Virtual Machine.

¿Qué es una API?

API significa Interfaz de Programación de Aplicaciones. En pocas palabras, permite que dos aplicaciones se comuniquen entre sí. Es un intermediario de software que comprende protocolos de comunicación y herramientas para crear software. Especifica la forma en que los componentes deben interactuar entre sí. Existen diferentes API para sitios web, sistemas operativos o aplicaciones. Se utiliza para programar componentes GUI. GUI significa Interfaz Gráfica de Usuario. Ayuda a desarrollar programas fácilmente al proporcionar todos los bloques de construcción necesarios.

Algunas de las características clave de Hyperledger Sawtooth son:

• Los nodos de Sawtooth se comunican mediante mensajes que se serializan mediante los Protocol Buffers de Google.
• Admite el protocolo de consenso RAFT, un algoritmo diseñado para transacciones de baja latencia y alto rendimiento. Es un algoritmo basado en votación y tiene tolerancia a fallas incorporada.

• También admite el algoritmo de consenso de prueba de tiempo transcurrido y el simulador PoET, que renuncia a la tolerancia a fallas bizantinas.

API de Sawtooth de Hyperledger

Proporciona a los clientes una API RESTish pragmática que les permite interactuar con un validador utilizando los estándares comunes HTTP/JSON. Es un proceso completamente separado. Una vez que comienza a ejecutarse, se pueden enviar transacciones y se pueden leer bloques utilizando la interfaz común neutral en cuanto al lenguaje. Cuando se mejora o rediseña el validador, la API REST crecerá junto con él, proporcionando así una interfaz consistente que satisface las necesidades de los desarrolladores de aplicaciones desde un punto de vista futurista. Un validador admite una API web para acceder a transacciones, bloques y almacenamiento de estado. Permite enviar transacciones a la red. La API REST trata al validador como una caja negra para enviar transacciones y obtener resultados. No se utiliza como una herramienta para toda la comunicación del validador.

Especificación API abierta

La API Rest se documenta de manera integral mediante la especificación de API abierta. Esta documentación actúa como una única fuente de información que documenta todos y cada uno de los aspectos implementados de la API. Puede ser leída tanto por humanos como por máquinas. Una API abierta es una interfaz estándar, independiente del lenguaje, que permite que tanto humanos como computadoras descubran y comprendan las capacidades del servicio sin acceder a la documentación, el código fuente o la inspección del tráfico de red. Si se define correctamente, un cliente puede comprender e interactuar con el servicio remoto utilizando una lógica de implementación mínima.

Códigos de estado HTTP

La API Rest, con el objetivo de mejorar la claridad, admite una cantidad limitada de códigos de estado HTTP comunes. La granularidad de los errores de transmisión se proporciona mediante respuestas de error específicas en el sobre de respuesta JSON. Algunos de los códigos comunes son:

• 200: Esto significa que el resultado es "OK". Significa que los recursos de datos se obtuvieron correctamente.
• 202: Esto se refiere a "Aceptado". Esto significa que los recursos publicados se han enviado al validador, pero aún no se han confirmado. También incluye un enlace para verificar el estado de los recursos enviados.
• 400: Esto se refiere a "Solicitud incorrecta". Esto significa que no se pudo completar la solicitud porque estaba mal formada.

Sobre de datos

La API REST utiliza un sobre de datos que se utiliza para enviar metadatos a los clientes de una manera que es fácil de personalizar. Los datos se devuelven en un sobre para todas las solicitudes exitosas que tendrán al menos una de las cuatro propiedades siguientes:

• Datos: Contiene los recursos reales o los recursos que se están obteniendo.
• Encabezado: Esto ayuda a saber si no se estableció un encabezado explícito en el momento de la solicitud original.
• Enlace: proporciona un enlace a los recursos que se obtuvieron. Los parámetros de encabezado y paginación se configuran explícitamente.
• Paginación: contiene información sobre la paginación de recursos.

Errores

En caso de que se produzcan problemas durante el procesamiento de una solicitud, la API REST envía un sobre de respuesta con una propiedad: "error". Para explicar el problema que se ha producido, consta de tres valores:

• Código: código analizable por máquina que es específico del error.
• Título: Este es un titular corto que puede ser leído por humanos.
• Mensaje: Es una explicación detallada del problema.

Parámetros de consulta

Esto ayuda a especificar la manera en que se debe realizar una solicitud a un validador. Algunos de los parámetros que incluye son:

• • Encabezado: es el identificador del bloque que se utiliza como encabezado de la cadena. Se puede utilizar para solicitar versiones anteriores del estado.
  • Conteo: hace referencia a la cantidad de recursos que se deben recuperar. El valor predeterminado es 1000.

• Esperar: se le indica a la API REST que espere hasta que los lotes se hayan confirmado en la cadena de bloques. Esto se hace antes de responder al cliente. El valor del tiempo de espera se puede configurar como un número entero positivo.

Puntos finales

Esto incluye referencias RESTful a todos los recursos almacenados en el libro de contabilidad Sawtooth que pueden ser de interés para los clientes. Esto puede incluir metadatos RESTish como el estado del lote o información como bloques y transacciones.

Puntos finales de recursos

Se proporcionan varias rutas de recursos para obtener los recursos que están almacenados en la cadena o aquellos que están en el estado del validador. En una API RESTful típica, una solicitud GET puede obtener uno o varios recursos en función de si se especificó o no un identificador de recurso en particular. Esto incluye lo siguiente:

• Bloques: los bloques actuales en la cadena de bloques a los que se hace referencia mediante identificación.
• Lotes: Los lotes almacenados a los que se hace referencia mediante id.
• Transacciones: Las transacciones a las que se hace referencia mediante id.
• Estado: el estado del libro mayor al que hacen referencia las direcciones de hoja.

Puntos finales de envío

Para enviar validaciones a un validador de dientes de sierra, deben estar envueltas en un lote. Debido a la naturaleza asincrónica de las cadenas de bloques, el estado de los lotes enviados se verifica con un punto final correspondiente. El parámetro de consulta de espera es aceptado por ambas solicitudes, lo que permite a los clientes recibir una respuesta una vez que se confirman los lotes.

Desarrollos futuros

Para realizar un seguimiento del rendimiento de la cadena de bloques y del validador, se pueden implementar puntos finales adicionales para obtener métricas. Esto puede incluir comunicaciones entre pares, estado del sistema, procesamiento de bloques, etc. Esto requeriría un diseño y desarrollo significativos tanto dentro del validador principal como de la API REST.

Conclusión

Teniendo en cuenta las características, las API y la arquitectura de Hyperledger Sawtooth, será de inmenso valor para industrias como el comercio minorista, la atención médica, las finanzas y la banca proporcionar un entorno descentralizado, transparente, libre de manipulaciones, seguro y confiable para el buen funcionamiento de las operaciones de cualquier negocio.