Cuatro casos de uso genuinos de blockchain

Donde los libros contables compartidos agregan valor real en TI empresarial

Casi un año después del primer lanzamiento MultiChain, hemos aprendido mucho sobre cómo las cadenas de bloques, en un sentido privado y sin criptomonedas, pueden y no pueden aplicarse a problemas del mundo real. Permítame compartir lo que sabemos hasta ahora.

Para empezar, la primera idea con la que nosotros (y muchos otros) comenzamos parece estar equivocada. Esta idea, inspirada directamente en bitcoin, era que las cadenas de bloques privadas (o "libros de contabilidad compartidos") podrían usarse para liquidar directamente la mayoría de las transacciones de pago e intercambio en el sector financiero, utilizando tokens en cadena para representar efectivo, acciones, bonos y más.

Esto es perfectamente viable a nivel técnico, entonces, ¿cuál es el problema? En una palabra, confidencialidad. Si varias instituciones están utilizando un libro mayor compartido, entonces cada institución ve cada transacción en ese libro mayor, incluso si no conocen de inmediato las identidades del mundo real de las partes involucradas. Esto resulta ser un gran problema, tanto en términos de regulación como de realidades comerciales de la competencia interbancaria. Si bien hay varias estrategias disponibles o en desarrollo para mitigar este problema, ninguna puede igualar la simplicidad y eficiencia de una base de datos centralizada administrada por un intermediario confiable, que mantiene un control total sobre quién puede ver qué. Al menos por ahora, parece que las grandes instituciones financieras prefieren mantener ocultas la mayoría de las transacciones en estas bases de datos intermedias, a pesar de los costos involucrados.

Baso esta conclusión no solo en nuestra propia experiencia, sino también en la dirección tomada por varias startups prominentes cuyo objetivo inicial era desarrollar libros de contabilidad compartidos para los bancos. Por ejemplo, tanto R3CEV como Digital Asset ahora están trabajando en "lenguajes de descripción de contrato", en Cuerda y DAML respectivamente (ejemplos anteriores incluyen MMLFi y Contratos ricardianos) Estos lenguajes permiten que las condiciones de un contrato financiero complejo se representen formalmente y sin ambigüedades en un formato legible por computadora, evitando al mismo tiempo deficiencias de cómputo de propósito general de estilo Ethereum. En cambio, la cadena de bloques solo juega un papel de apoyo, almacenando o notariando los contratos en forma cifrada, y realizando una detección básica de duplicados. La ejecución real del contrato no tiene lugar en la cadena de bloques, sino que solo la realizan las contrapartes del contrato, con la probable incorporación de auditores y reguladores.

En el corto plazo, esto es probablemente lo mejor que se puede hacer, pero ¿dónde deja las ambiciones más amplias para las cadenas de bloques autorizadas? ¿Existen otras aplicaciones para las que puedan formar una parte más significativa del rompecabezas?

Esta pregunta puede abordarse tanto teórica como empíricamente. Teóricamente, al centrarse en las diferencias clave entre blockchains y bases de datos tradicionales, y cómo estos informan el conjunto de posibles casos de uso. Y en nuestro caso, empíricamente, clasificando las soluciones del mundo real que se construyen hoy en MultiChain. No es sorprendente que, ya sea que nos centremos en la teoría o la práctica, surjan las mismas clases de casos de uso:

• Sistemas financieros ligeros.
• Seguimiento de procedencia.
• Mantenimiento de registros interorganizacionales.
• Agregación multipartidista.

Antes de explicar esto en detalle, repasemos la teoría. Como he discutido antes, las dos diferencias más importantes entre blockchains y bases de datos centralizadas se pueden caracterizar de la siguiente manera:

1. Desintermediación. Las cadenas de bloques permiten a múltiples partes que no confían completamente entre sí compartir de manera segura y directa una sola base de datos sin requerir un intermediario confiable.
2. Confidencialidad: Todos los participantes en una cadena de bloques ven todas las transacciones que tienen lugar. (Incluso si usamos direcciones seudónimas y criptografía avanzada para ocultar algunos aspectos de esas transacciones, una cadena de bloques siempre filtrará más información que una base de datos centralizada).

En otras palabras, las blockchains son ideales para bases de datos compartidas en las que cada usuario es capaz de leer todo, menos no solo usuario controla quién puede escribir qué. Por el contrario, en las bases de datos tradicionales, una sola entidad ejerce control sobre todas las operaciones de lectura y escritura, mientras que otros usuarios están completamente sujetos a los caprichos de esa entidad. Para resumirlo en una oración:

Las cadenas de bloques representan una compensación en la que se obtiene la desintermediación a costa de la confidencialidad.

Al examinar los cuatro tipos de casos de uso a continuación, volveremos repetidamente a esta compensación principal, explicando por qué, en cada caso, el beneficio de la desintermediación supera el costo de la confidencialidad reducida.

Sistemas financieros livianos

Comencemos con la clase de aplicaciones de blockchain que serán más familiares, en las que un grupo de entidades desea establecer un sistema financiero. Dentro de este sistema, uno o más activos escasos se tramitan e intercambian entre esas entidades.

Para poder cualquier para que los activos sigan siendo escasos, se deben resolver dos problemas relacionados. Primero, debemos asegurarnos de que la misma unidad del activo no se pueda enviar a más de un lugar (un "doble gasto"). En segundo lugar, debe ser imposible para cualquiera crear nuevas unidades del activo por capricho ("falsificación"). Cualquier entidad que pueda hacer cualquiera de estas cosas podría robar un valor ilimitado del sistema.

Una solución común a estos problemas son las fichas físicas, como monedas de metal o papel impreso de forma segura. Estas fichas resuelven trivialmente el problema del doble gasto, porque las reglas de la física (literalmente) evitan que una ficha se encuentre en dos lugares al mismo tiempo. El problema de la falsificación se resuelve haciendo que la ficha sea extremadamente difícil de fabricar. Aún así, los tokens físicos sufren varias deficiencias que pueden hacerlos poco prácticos:

• Como activos portadores puros, los tokens físicos se pueden robar sin dejar rastro ni recurso.
• Son lentos y costosos de mover en grandes cantidades o en largas distancias.
• Es complicado y costoso crear tokens físicos que no se pueden falsificar.

Estas deficiencias se pueden evitar dejando atrás los tokens físicos y redefiniendo la propiedad de los activos en términos de un libro mayor administrado por un intermediario confiable. En el pasado, estos libros de contabilidad se basaban en registros en papel, y hoy tienden a ejecutarse en bases de datos regulares. De cualquier manera, el intermediario realiza una transferencia de propiedad modificando el contenido del libro mayor, en respuesta a una solicitud autenticada. A diferencia de la liquidación con tokens físicos, las transacciones cuestionables pueden revertirse rápida y fácilmente.

Entonces, ¿cuál es el problema con los libros de contabilidad? En una palabra, concentración de control. Al poner tanto poder en un solo lugar, creamos un importante desafío de seguridad, tanto en términos técnicos como humanos. Si alguien externo puede piratear la base de datos, puede cambiar el libro a voluntad, robando los fondos de otros o destruyendo su contenido por completo. Peor aún, alguien en el interior podría corromper el libro mayor, y este tipo de ataque es difícil de detectar o probar. Como resultado, siempre que tengamos un libro mayor centralizado, debemos invertir mucho tiempo y dinero en mecanismos para mantener la integridad de ese libro mayor. Y en muchos casos, requerimos una verificación continua mediante la reconciliación basada en lotes entre el libro mayor central y los de cada una de las partes de la transacción.

Ingrese la cadena de bloques (o "libro mayor compartido"). Esto proporciona los beneficios de los libros de contabilidad sin sufrir el problema de la concentración. En cambio, cada entidad ejecuta un "nodo" que contiene una copia del libro mayor y mantiene el control total sobre sus propios activos, que están protegidos por claves privadas. Las transacciones se propagan entre nodos de una manera entre pares, con la cadena de bloques asegurando que se mantenga el consenso. Esta arquitectura no deja ningún punto de ataque central a través del cual un pirata informático o una persona con información privilegiada pueda corromper el contenido del libro mayor. Como resultado, se puede implementar un sistema financiero digital de manera más rápida y económica, con el beneficio adicional de la reconciliación automática en tiempo real.

Entonces, ¿cuál es el inconveniente? Como se discutió anteriormente, todos los participantes en un libro mayor compartido ven todas las transacciones que tienen lugar, dejándolo inutilizable en situaciones donde se requiere confidencialidad. En cambio, las cadenas de bloques son adecuadas para lo que llamo ligero sistemas financieros, es decir, aquellos en los que las apuestas económicas o el número de participantes es relativamente bajo. En estos casos, la confidencialidad tiende a ser un problema menor, incluso si los participantes prestan mucha atención a lo que están haciendo los demás, no aprenderán mucho de valor. Y es precisamente porque Hay mucho en juego que preferimos evitar la molestia y el costo de establecer un intermediario.

Algunos ejemplos obvios de sistemas financieros livianos incluyen: crowdfunding, tarjetas de regalo, puntos de fidelidad y monedas locales, especialmente en los casos en que los activos se pueden canjear en más de un lugar. Pero también estamos viendo casos de uso en el sector financiero convencional, como el comercio entre pares entre administradores de activos que no están en competencia directa. Las cadenas de bloques incluso se están probando como interno sistemas de contabilidad, en grandes organizaciones donde cada departamento o ubicación debe mantener el control de sus fondos. En todos estos casos, el menor costo y la fricción de las cadenas de bloques proporcionan un beneficio inmediato, mientras que la pérdida de confidencialidad no es una preocupación.

Seguimiento de procedencia

Aquí hay una segunda clase de casos de uso que escuchamos repetidamente de los usuarios de MultiChain: rastrear el origen y el movimiento de artículos de alto valor en una cadena de suministro, como artículos de lujo, productos farmacéuticos, cosméticos y electrónicos. E igualmente, elementos críticos de documentación tales como conocimientos de embarque o cartas de crédito. En las cadenas de suministro que se extienden a través del tiempo y la distancia, todos estos artículos sufren de falsificación y robo.

El problema puede abordarse utilizando blockchains de la siguiente manera: cuando se crea el elemento de alto valor, una entidad confiable emite un token digital correspondiente, que actúa para autenticar su punto de origen. Luego, cada vez que el elemento físico cambia de manos, el token digital se mueve en paralelo, de modo que la cadena de custodia del mundo real se refleja precisamente en una cadena de transacciones en la cadena de bloques.

Si lo desea, el token actúa como un "certificado de autenticidad" virtual, que es mucho más difícil de robar o falsificar que un trozo de papel. Al recibir el token digital, el destinatario final del artículo físico, ya sea un banco, distribuidor, minorista o cliente, puede verificar la cadena de custodia hasta el punto de origen. De hecho, en el caso de la documentación, como los conocimientos de embarque, podemos eliminar el elemento físico por completo.

Si bien todo esto tiene sentido, el lector astuto notará que una base de datos regular, administrada (por ejemplo) por el fabricante de un artículo, puede realizar la misma tarea. Esta base de datos almacenaría un registro del propietario actual de cada artículo, aceptando transacciones firmadas que representan cada cambio de propiedad, y respondería a las solicitudes entrantes sobre el estado actual del juego.

Entonces, ¿por qué usar una cadena de bloques en su lugar? La respuesta es que, para este tipo de aplicación, hay un beneficio para la confianza distribuida. No importa dónde se encuentre una base de datos centralizada, habrá personas en ese lugar que tienen la capacidad (y pueden ser sobornadas) de corromper su contenido, marcando artículos falsificados o robados como legítimos. Por el contrario, si se rastrea la procedencia en una cadena de bloques que pertenece colectivamente a los participantes de una cadena de suministro, ninguna entidad individual o pequeño grupo de entidades puede corromper la cadena de custodia, y los usuarios finales pueden tener más confianza en las respuestas que reciben. Como beneficio adicional, se pueden intercambiar diferentes tokens (por ejemplo, para algunos bienes y el conocimiento de embarque correspondiente) de forma segura y directa, con un intercambio bidireccional garantia en el nivel más bajo de blockchain.

¿Qué pasa con el problema de la confidencialidad? La idoneidad de blockchains para la procedencia de la cadena de suministro es un resultado feliz del patrón simple de transacciones de esta aplicación. A diferencia de los mercados financieros, la mayoría de los tokens se mueven en una sola dirección, desde el origen hasta el punto final, sin ser intercambiados repetidamente entre los participantes de la cadena de bloques. Si los competidores rara vez realizan transacciones entre ellos (por ejemplo, fabricante de juguetes a fabricante de juguetes, o minorista a minorista), no pueden aprender las "direcciones" de blockchain de los demás y conectarlas con identidades del mundo real. Además, la actividad se puede dividir fácilmente en múltiples libros de contabilidad, cada uno de los cuales representa un orden o tipo de bien diferente.

Mantenimiento de registros interorganizacionales.

Los dos casos de uso anteriores se basan en activos tokenizados, es decir, representaciones en cadena de un elemento de valor transferido entre los participantes. Sin embargo, hay un segundo grupo de casos de uso de blockchain que no está relacionado con los activos. En cambio, la cadena actúa como un mecanismo para registrar y notarizar colectivamente cualquier tipo de datos, cuyo significado puede ser financiero o de otro tipo.

Un ejemplo de ello es una pista de auditoría de comunicaciones críticas entre dos o más organizaciones, por ejemplo, en el sector de la salud o legal. No se puede confiar en ninguna organización individual del grupo para mantener este archivo de registros, porque la información falsificada o eliminada dañaría significativamente a los demás. Sin embargo, es vital que todos estén de acuerdo con el contenido del archivo para evitar disputas.

Para resolver este problema, necesitamos una base de datos compartida en la que se escriban todos los registros, con cada registro acompañado de una marca de tiempo y prueba de origen. La solución estándar sería crear un intermediario confiable, cuya función es recopilar y almacenar los registros de forma centralizada. Pero las cadenas de bloques ofrecen un enfoque diferente, dando a las organizaciones una forma de administrar conjuntamente este archivo, al tiempo que evitan que los participantes individuales (o pequeños grupos del mismo) lo corrompan.

Una de las conversaciones más esclarecedoras que tuve en los últimos dos años fue con Michael Mainelli of Z / Yen. Durante 20 años, su compañía ha estado construyendo sistemas en los que múltiples entidades administran colectivamente un rastro de auditoría digital compartido, utilizando marcas de tiempo, firmas digitales y un esquema de consenso round robin. Cuando explicó los detalles técnicos de estos sistemas, quedó claro que son blockchains autorizados en todos los aspectos. En otras palabras, no hay nada nuevo sobre el uso de una cadena de bloques para el mantenimiento de registros interorganizacionales: es solo que el mundo finalmente se ha dado cuenta de la posibilidad.

En términos de los datos reales almacenados en la cadena de bloques, hay tres opciones populares:

• Datos sin cifrar. Esto puede ser leído por todos los participantes en la cadena de bloques, proporcionando total transparencia colectiva y resolución inmediata en caso de disputa.
• Datos encriptados. Esto solo puede ser leído por los participantes con la clave de descifrado adecuada. En el caso de una disputa, cualquiera puede revelar esta clave a una autoridad confiable, como un tribunal, y usar la cadena de bloques para demostrar que una determinada parte agregó los datos originales en un determinado momento.
• Datos hash. UNA "hachís"Actúa como una huella digital compacta, que representa un compromiso con una pieza de datos en particular mientras mantiene esos datos ocultos. Dados algunos datos, cualquier parte puede confirmar fácilmente si coincide con un hash dado, pero deduciendo datos en su hash es computacionalmente imposible. Solo el hash se coloca en la cadena de bloques, con los datos originales almacenados fuera de la cadena por las partes interesadas, que pueden revelarlo en caso de una disputa.

Como se mencionó anteriormente, el producto Corda de R3CEV ha adoptado este tercer enfoque, almacenar hashes en una cadena de bloques para notarizar contratos entre contrapartes, sin revelar su contenido. Este método se puede utilizar tanto para descripciones de contratos legibles por computadora, como para archivos PDF que contienen documentación en papel.

Naturalmente, la confidencialidad no es un problema para el mantenimiento de registros interorganizacionales, porque todo el propósito es crear un archivo compartido que todos los participantes puedan ver (incluso si algunos datos están cifrados o cifrados). De hecho, en algunos casos, una cadena de bloques puede ayudar a administrar el acceso a datos confidenciales fuera de la cadena, al proporcionar un registro inmutable de las solicitudes de acceso firmadas digitalmente. De cualquier manera, el beneficio directo de la desintermediación es que no se debe crear y confiar en ninguna entidad adicional para mantener este registro.

Agregación multiparte

Técnicamente hablando, esta clase final de caso de uso es similar a la anterior, ya que varias partes están escribiendo datos en un registro administrado colectivamente. Sin embargo, en este caso, la motivación es diferente: superar la dificultad de infraestructura de combinar información de un gran número de fuentes separadas.

Imagine dos bancos con bases de datos internas de verificaciones de identidad del cliente. En algún momento notan que comparten muchos clientes, por lo que entran en un acuerdo de intercambio recíproco en el que intercambian datos de verificación para evitar el trabajo duplicado. Técnicamente, el acuerdo se implementa utilizando estándares replicación de datos maestro-esclavo, en el que cada banco mantiene una copia en vivo de solo lectura de la base de datos del otro, y ejecuta consultas en paralelo contra su propia base de datos y la réplica. Hasta aquí todo bien.

Ahora imagine que estos dos bancos invitan a otros tres a participar en este círculo de intercambio. Cada uno de los 5 bancos ejecuta su propia base de datos maestra, junto con 4 réplicas de solo lectura de los demás. Con 5 maestros y 20 réplicas, tenemos 25 instancias de bases de datos en total. Si bien es factible, esto consume tiempo y recursos notables en el departamento de TI de cada banco.

Avancemos rápidamente hasta el punto en que 20 bancos comparten información de esta manera, y estamos viendo 400 instancias de bases de datos en total. Para 100 bancos, llegamos a 10,000 instancias. En general, si cada parte comparte información entre sí, el número total de instancias de la base de datos aumenta con el cuadrado del número de participantes. En algún momento de este proceso, el sistema está obligado a fallar.

Entonces, ¿cuál es la solución? Una opción obvia es que todos los bancos envíen sus datos a un intermediario confiable, cuyo trabajo es agregar esos datos en una sola base de datos maestra. Cada banco podría consultar esta base de datos de forma remota o ejecutar una réplica local de solo lectura dentro de sus cuatro paredes. Si bien no hay nada de malo en este enfoque, las cadenas de bloques ofrecen una alternativa más barata, en la que los bancos que la utilizan dirigen la base de datos compartida. Las cadenas de bloques también aportan el beneficio adicional de redundancia y conmutación por error para el sistema en su conjunto.

Es importante aclarar que una cadena de bloques no está actuando solo como una base de datos distribuida como Cassandra or RepensarDB. A diferencia de estos sistemas, cada nodo de blockchain impone un conjunto de reglas que impiden que un participante modifique o elimine los datos agregados por otro. De hecho, todavía parece haber cierta confusión al respecto: una plataforma blockchain lanzada recientemente puede romperse por un solo nodo que se comporta mal. En cualquier caso, una buena plataforma también facilitará la administración de redes con miles de nodos, uniéndose y saliendo a voluntad, si se le otorgan los permisos adecuados.

Aunque soy un poco escéptico de la conexión tan citada entre blockchains y el Internet de las Cosas, Creo que es aquí donde radica una fuerte sinergia. Por supuesto, cada "cosa" sería demasiado pequeña para almacenar una copia completa de la cadena de bloques localmente. Más bien, transmitiría transacciones con datos a una red distribuida de nodos de blockchain, que lo cotejaría todo para su posterior recuperación y análisis.

Conclusión: blockchains en finanzas

Comencé este artículo cuestionando el caso de uso inicial previsto para blockchains en el sector financiero, a saber, la liquidación en masa de las transacciones de pago y cambio. Si bien creo que esta conclusión se está convirtiendo en sabiduría común (con una excepción notable), no significa que las cadenas de bloques no tengan otras aplicaciones en esta industria. De hecho, para cada una de las cuatro clases de casos de uso descritos anteriormente, vemos aplicaciones claras para bancos y otras instituciones financieras. Respectivamente, estos son: pequeños círculos comerciales, procedencia para financiamiento comercial, notarización de contratos bilaterales y la agregación de datos ALD / KYC.

La clave para entender es que, arquitectónicamente, nuestras cuatro clases de casos de uso no son soluciones y para financiar, y son igualmente relevantes para otros sectores como seguros, salud, distribución, fabricación y TI. De hecho, las cadenas de bloques privadas deben considerarse para cualquier situación en la que dos o más organizaciones necesiten una visión compartida de la realidad, y esa visión no se origina en una sola fuente. En estos casos, las cadenas de bloques ofrecen una alternativa a la necesidad de un intermediario confiable, lo que lleva a ahorros significativos en problemas y costos.

Por favor publique cualquier comentario en Linkedin.

Fuente: https://www.multichain.com/blog/2016/05/four-genuine-blockchain-use-cases/