Cuatro candidatos a patrones de arquitectura para aplicaciones descentralizadas basadas en Blockchain

Blockchain tiene un conjunto diverso de casos de uso, que van desde las finanzas hasta una Internet descentralizada. Sin embargo, la mayoría de los casos de uso de blockchain se pueden implementar utilizando relativamente pocos patrones. Por ejemplo, Una colección de patrones para aplicaciones basadas en Blockchain proporciona una lista de 15 patrones de Blockchain.

Los patrones de grano fino, como los descritos anteriormente, son útiles. Sin embargo, el diseño del sistema necesita un nivel mucho mayor de abstracciones. También es útil tener macropatrones más detallados, que llamamos patrones de arquitectura. Esta publicación describe cuatro patrones de arquitectura de este tipo.

Empecemos. Para describir patrones, usaré la plantilla descrita por Aleksandra Tešanovic en ¿Qué es un patrón?

Patrón de arquitectura para IAM.

Contexto: los entornos de IAM incluyen muchos usuarios y proveedores de servicios. Los sistemas IAM brindan a cada usuario una cuenta y un conjunto de capacidades que permiten a los usuarios acudir a los proveedores de servicios, demostrar que son propietarios de las cuentas y luego recibir servicios según sus capacidades.

Fuerzas: Necesidad de implementar un entorno IAM descentralizado donde un solo usuario malintencionado o pocos usuarios no puedan afectar significativamente el sistema.

Solución: El patrón candidato propuesto utiliza la especificación DID del World Wide Web Consortium (W3C) y la especificación W3C Verifiable Claims de la siguiente manera.

Supongamos que Alice necesita una identidad (DID, que es un identificador único). Como se muestra en la figura para crear un nuevo DID, Alice crea una entrada en la cadena de bloques. Esta entrada incluye un identificador generado aleatoriamente, un enlace al repositorio con los datos de su perfil y un hash de los datos del perfil. El perfil de usuario contiene una clave pública y un conjunto de afirmaciones verificables. El identificador aleatorio generado ahora se convierte en el DID de Alice porque solo ella posee la clave privada que corresponde a la clave pública.

Las reclamaciones verificables son tokens de delegación firmados por una autoridad competente. El creador también los registra en una cadena de bloques junto con el hash del reclamo de una manera similar al DID.

Alice obtiene las afirmaciones verificables en primer lugar acudiendo a las autoridades. Por ejemplo, el departamento de registro personal o equivalente es la autoridad adecuada para reclamos verificables de nombre, dirección y fecha de nacimiento. Suponiendo que las autoridades emitan afirmaciones verificables, Alice primero demuestra que su propiedad del DID utiliza un protocolo de desafío-respuesta. Luego, envía solicitudes de reclamos verificables de sus atributos, que pueden incluir, por ejemplo, su nombre, dirección, título y fecha de nacimiento. Para actualizar los datos de su perfil, Alice agregará una nueva entrada a la cadena de bloques con un nuevo hash del perfil.

En el protocolo de desafío-respuesta, el validador genera una semilla aleatoria, la encripta usando la clave pública de Alice y luego desafía a Alice a demostrar que tiene la clave privada al descifrar la semilla encriptada. Dado que Alice tiene la clave privada, debe ser la propietaria del DID.

Un usuario diferente o una organización (autenticador), Bob, que quiere identificar a Alice, primero recibe el DID de Alice, lee todas las entradas relacionadas con ese DID de la cadena de bloques, recupera los datos del perfil de Alice y los verifica. Bob puede verificar la identidad de Alice (identificación) nuevamente usando el protocolo desafío-respuesta. Entonces Bob puede confirmar las afirmaciones verificables y estar seguro de que las afirmaciones sobre Alice son ciertas.

Podemos superponer la mayoría de los casos de uso de IAM sobre este patrón de arquitectura. Por ejemplo, podemos lograr el control de acceso emitiendo reclamos verificables para las acciones que queremos que realicen los usuarios o aceptando solo usuarios que tengan ciertas propiedades (por ejemplo, edad, descripción del trabajo, pertenencia al grupo) en sus reclamos verificables. Una implementación puede optar por almacenar en caché subconjuntos relevantes de los datos del perfil en una base de datos para mejorar el rendimiento.

Patrón de arquitectura para el historial auditable o el espacio de trabajo

Contexto: Dos o más partes realizan transacciones o trabajan juntas, y sus actividades deben registrarse de manera indiscutible.

Fuerzas: Necesidad de implementar un registro de auditoría descentralizado o un espacio de trabajo donde un solo usuario deshonesto o pocos usuarios no puedan afectar significativamente el sistema.

Solución: el sistema propuesto registra actividades y crea entradas en la cadena de bloques para esos registros. La entrada contiene el hash de los registros de actividad y, por lo tanto, los registros no se pueden disputar más adelante.

Por ejemplo, supongamos que Alice quiere pagar un impuesto. Tax Server acepta la aplicación de pago, crea un recibo digital, registra su hash en la cadena de bloques y envía el recibo a Alice. Alice puede verificar el recibo calculando el hash y comparándolo con el valor almacenado en la cadena de bloques. Después de esto, Bob no puede negar el recibo porque el hash del recibo y la hora se registran en la cadena de bloques.

Si las actividades son numerosas, puede ser necesario solucionar las limitaciones de rendimiento de la cadena de bloques. Por lo tanto, algunas implementaciones pueden registrar un hash de varios registros de actividad como un bloque en lugar de un solo registro de actividad.

Patrón de arquitectura para registro o mercado

Contexto: un registro es una colección de entradas de datos que se pueden buscar y recuperar a través de la red. Un mercado es un registro que permite a los usuarios comprar los servicios o productos representados por entradas de datos. Por ejemplo, un registro puede ser un catálogo de API disponibles.

Fuerzas: Necesidad de implementar un entorno descentralizado donde un solo usuario deshonesto o pocos usuarios no puedan afectar significativamente el sistema.

Solución: el patrón propuesto funciona de la siguiente manera.

Primero consideremos un registro. Con la arquitectura propuesta, cuando un usuario emite una actualización de registro (para agregar o modificar una entrada), el cliente registra el cambio en la cadena de bloques. Si los datos de la actualización son grandes, el registro de la cadena de bloques puede contener un enlace a los datos y un valor hash de los datos. Si los datos almacenados en el registro deben modificarse, el cliente de registro agrega un nuevo registro a la cadena de bloques con información modificada.

En el diagrama anterior, cada usuario tiene un cliente de registro que se ejecuta en la máquina local (por ejemplo, una computadora portátil o un teléfono). Cada cliente de registro lee los registros de actualización de la cadena de bloques, verifica los datos de actualización con el hash incluido en los registros y reconstruye la vista más actual de los registros a partir de las actualizaciones. Por ejemplo, al leer los registros de blockchain sobre API, sus adiciones, modificaciones y eliminaciones, el cliente de registro puede crear una vista que muestre las API actuales incluidas en el registro. Para evitar tener que leer y verificar todos los registros cada vez que se utiliza el registro, los clientes pueden almacenar datos en una base de datos e indexarlos. El cliente debe verificar periódicamente la cadena de bloques y actualizar el registro.

Blockchain funciona bien como un "mercado de servicios", ya que el mismo servicio puede venderse muchas veces. Sin embargo, debido a limitaciones de rendimiento, los mercados basados ​​en blockchain no son adecuados para artículos que se pueden vender solo una vez.

Para ilustrar, la funcionalidad de un registro basado en blockchain, veamos cuándo Alice quiere suscribirse al “servicio de noticias meteorológicas” en el mercado de blockchain. Cuando envía su solicitud, el registro crea credenciales para el servicio y las comparte con Alice. El pago puede realizarse de una de varias maneras: utilizando Bitcoins, a través de un contrato inteligente en el que los pagos se realizan de manera oportuna o por algún medio fuera de los límites.

Patrón de arquitectura para contratos inteligentes y cosas gestionadas

Bajo este patrón, consideramos dos casos. Primero, consideramos los contratos inteligentes y, como segundo, consideramos un caso especial común de contratos inteligentes: "Cosas administradas".

Patrón de contratos inteligentes

Contexto: varios usuarios quieren cumplir con un contrato, descrito como un programa ejecutable. El contrato se somete a transiciones de estado según las condiciones definidas en el contrato, y en un momento dado, todos pueden ponerse de acuerdo sobre el estado actual del contrato.

Fuerzas: necesidad de implementar un entorno donde un solo usuario deshonesto o pocos usuarios no puedan afectar significativamente el sistema.

Solución: los contactos inteligentes son parte de las tecnologías blockchain y están respaldados por implementaciones blockchain, como Ethereum. Un contrato se describe utilizando un lenguaje de contrato inteligente y se distribuye a todos los participantes. A medida que cambian las condiciones definidas en el contrato, cada participante ejecuta el contrato y registra el estado actual en la cadena de bloques utilizando el algoritmo de consenso.

Patrón de cosas gestionadas

Contexto: Necesitamos rastrear la propiedad de cosas inteligentes del mundo real. Aquí, las cosas inteligentes son objetos del mundo real que son capaces de ejecutar lógica informática dentro de ellos. El propietario puede controlar y realizar acciones sobre las cosas del mundo real. Además, el propietario puede transferir su propiedad a otra persona.

Fuerzas: necesidad de implementar un entorno donde un solo usuario deshonesto o pocos usuarios no puedan afectar significativamente el sistema.

Solución: A continuación se describe la implementación del patrón utilizando Car como el elemento administrado como ejemplo.

Podemos implementar una cadena de bloques para algo administrado, en este caso, un automóvil, en dos pasos. Primero, el fabricante registra el DID y la clave pública del propietario del automóvil. Cuando cambia la propiedad, el propietario agrega un nuevo registro en la cadena de bloques que especifica el nuevo propietario. En segundo lugar, al verificar la propiedad, el automóvil primero recupera todos los registros en la cadena de bloques y verifica que el propietario agregue cada registro en ese momento. Esto se hace comprobando la clave pública del usuario que escribió el registro con la clave pública incluida en el registro de propiedad anterior. El último propietario de esta cadena válida es el propietario actual.

Después de determinar el propietario, el automóvil registra al propietario actual, Alice, recuperando su clave pública y realizando un inicio de sesión basado en el protocolo de desafío-respuesta con el teléfono de Alice, que tiene la clave privada de Alice.

Dicho sistema reduce los riesgos asociados con los artefactos controlados de forma remota. Por ejemplo, en una implementación que no sea de blockchain, alguien con acceso puede cambiar la propiedad de su automóvil. Sin embargo, con el modelo basado en blockchain, para controlar de forma remota el automóvil, un posible atacante debe cambiar el registro de propiedad en el blockchain, lo cual es muy difícil de lograr sin ser el propietario.

Sin embargo, es difícil evitar que alguien que tiene acceso a la "cosa" cambie físicamente la lógica que se ejecuta en el interior (por ejemplo, reemplazando el firmware del automóvil). Una solución a este problema es construir alguna forma de autodestrucción que se active cuando se detecte la manipulación del artefacto.

Por ejemplo, Alice le compra el automóvil a Bob mediante un contrato inteligente que le paga a Bob y actualiza la propiedad del vehículo. Después de la transacción, Alice camina hacia el automóvil, que lee el DID de Alice desde el teléfono, recupera su clave pública, la autentica mediante un protocolo de desafío-respuesta comunicándose con el teléfono que tiene la clave privada de Alice, verifica su propiedad y desbloquea el coche.

Conclusión

Discutimos cuatro patrones de arquitectura basados ​​en blockchain. El documento de GitHub, Casos de uso de integración basados ​​en Blockchain, muestra estos patrones en acción, y describe cómo se pueden implementar más de 30 casos de uso de blockchain utilizando estos cuatro patrones.

Si tiene opiniones sobre los patrones anteriores o conoce otros patrones, realmente me gustaría escucharlos.

Espero que esto haya sido útil. Si le gusta esto, también le puede interesar un análisis detallado de blockchain en nuestro artículo recientemente publicado, "Una encuesta centrada en casos de uso de Blockchain: status quo y direcciones futuras".