Cuatro casos de uso genuinos de blockchain

El Dr. Gideon Greenspan es el fundador y director ejecutivo de Coin Sciences, la empresa detrás de la plataforma MultiChain para cadenas de bloques privadas.

En este artículo de Opinión , Greenspan describe cuatro casos de uso para cadenas de bloques con permisos y argumenta que las instituciones financieras pueden enfrentar más limitaciones al intentar aprovechar la Tecnología de lo que se pensaba anteriormente.

Casi un año después del lanzamiento de MultiChain, hemos aprendido mucho sobre cómo las cadenas de bloques, en un sentido privado y no criptográfico, pueden y no pueden aplicarse a problemas del mundo real.

Permítanme compartir lo que sabemos hasta ahora.

Para empezar, la primera idea con la que comenzamos (y muchos otros) parece errónea. Esta idea, inspirada directamente por Bitcoin , consistía en que las cadenas de bloques privadas (o "libros contables compartidos") podían utilizarse para liquidar directamente la mayoría de las transacciones de pago e intercambio en el sector Finanzas , utilizando tokens en cadena para representar efectivo, acciones, bonos y más.

Esto es perfectamente viable a nivel técnico, así que ¿cuál es el problema?

En resumen: confidencialidad. Si varias instituciones utilizan un libro de contabilidad compartido, cada una de ellas ve todas las transacciones en él, incluso si no conocen de inmediato la identidad real de las partes involucradas.

Esto resulta ser un problema grave, tanto en términos de regulación como de las realidades comerciales de la competencia interbancaria. Si bien existen diversas estrategias disponibles o en desarrollo para mitigar este problema, ninguna puede igualar la simplicidad y eficiencia de una base de datos centralizada gestionada por un intermediario de confianza, que mantiene un control total sobre quién puede ver qué.

Por ahora, al menos, parece que las grandes instituciones financieras prefieren KEEP la mayoría de las transacciones ocultas en estas bases de datos intermediarias, a pesar de los costos que ello implica.

Baso esta conclusión no solo en mi propia experiencia, sino también en la dirección tomada por varias startups destacadas cuyo objetivo inicial era desarrollar registros compartidos para bancos. Por ejemplo, tanto R3CEV como Digital Asset están trabajando ahora en "lenguajes de descripción de contratos".Corda y DAML respectivamente (los ejemplos anteriores incluyen MLFi <a href="https://www.lexifi.com/product/technology/contract-description-language">Tecnología</a> y Contratos ricardianos).

Estos lenguajes permiten representar las condiciones de un contrato financiero complejo de manera formal e inequívoca en un formato legible por computadora, evitando al mismo tiempo ladeficiencias de EthereumComputación de propósito general de estilo. En cambio, la cadena de bloques solo desempeña una función de apoyo, almacenando o certificando los contratos encriptados 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 la llevan a cabo únicamente las contrapartes del contrato, con la probable participación de auditores y reguladores.

A NEAR plazo, esto es probablemente lo mejor que se puede hacer, pero ¿dónde quedan las ambiciones más amplias para las cadenas de bloques con permisos? ¿Existen otras aplicaciones para las que puedan ser una parte más importante del rompecabezas?

Esta cuestión puede abordarse tanto teórica como empíricamente.

En teoría, nos centramos en las diferencias clave entre las cadenas de bloques y las bases de datos tradicionales, y cómo estas influyen en el conjunto de posibles casos de uso. Y, en nuestro caso, empíricamente, categorizamos las soluciones reales que se están desarrollando actualmente con nuestro producto.

No es sorprendente que, ya sea que nos centremos en la teoría o en la práctica, surjan las mismas clases de casos de uso:

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

Teoría

Antes de explicar esto en detalle, repasemos la teoría. Como ya he comentado, las dos diferencias más importantes entre las cadenas de bloques y las bases de datos centralizadas son las siguientes:

Desintermediación.Las cadenas de bloques permiten que varias partes que no confían plenamente entre sí compartan de forma segura y directa una única base de datos sin necesidad de un intermediario confiable.

Confidencialidad.Todos los participantes de una blockchain ven todas las transacciones que se llevan a cabo. (Incluso si usamos direcciones seudónimas y criptografía avanzada para ocultar algunos aspectos de dichas transacciones, una blockchain siempre filtrará más información que una base de datos centralizada).

En otras palabras, las cadenas de bloques son ideales para bases de datos compartidas donde cada usuario puede leer todo, pero ningún usuario controla quién puede escribir qué. En cambio, en las bases de datos tradicionales, una sola entidad controla todas las operaciones de lectura y escritura, mientras que los demás usuarios están completamente sujetos a sus caprichos.

Para resumirlo en una frase: las cadenas de bloques representan un equilibrio en el que la desintermediación se obtiene a costa de la confidencialidad.

Al examinar los cuatro tipos de casos de uso que aparecen a continuación, volveremos repetidamente a esta cuestión CORE y explicaremos por qué, en cada caso, el beneficio de la desintermediación supera el costo de una confidencialidad reducida.

Sistemas financieros ligeros

Comencemos con la clase de aplicaciones de blockchain más conocidas, en la que un grupo de entidades desea establecer un sistema financiero. Dentro de este sistema, se realizan transacciones e intercambios entre dichas entidades con ONE o más activos escasos.

Para que un activo siga siendo escaso, deben resolverse dos problemas relacionados. Primero, debemos garantizar que la misma unidad del activo no pueda enviarse a más de un lugar (un "doble gasto"). Segundo, debe ser imposible que alguien cree nuevas unidades del activo por capricho (falsificación). Cualquier entidad que pudiera hacer cualquiera de estas cosas podría robar valor ilimitado del sistema.

Una solución común a estos problemas son las fichas físicas, como monedas metálicas o papel impreso de forma segura. Estas fichas resuelven trivialmente el problema del doble gasto, ya que las leyes de la física (literalmente) impiden que una ficha esté en dos lugares al mismo tiempo.

El problema de la falsificación se soluciona dificultando enormemente la fabricación del token. Sin embargo, los tokens físicos presentan varias deficiencias que pueden hacerlos poco prácticos:

• Como activos puros al portador, los tokens físicos pueden ser robados sin posibilidad de recurso.
• Es difícil y costoso crear tokens físicos que no se puedan falsificar.
• Son lentos y costosos de transportar en grandes cantidades o a grandes distancias.

Estas deficiencias pueden evitarse eliminando los tokens físicos y redefiniendo la propiedad de los activos en términos de un libro de contabilidad gestionado por un intermediario de confianza. Anteriormente, estos libros de contabilidad se basaban en registros en papel, y hoy en día suelen funcionar con bases de datos convencionales. En cualquier caso, el intermediario realiza una transferencia de propiedad modificando el contenido del libro de contabilidad, en respuesta a una Request 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 contables? En resumen, la concentración del control.

Al concentrar tanto poder en un ONE lugar, creamos un importante desafío de seguridad, tanto en términos técnicos como Human . Si alguien externo logra acceder a la base de datos, puede modificar el libro mayor a voluntad, robando fondos o destruyendo su contenido por completo.

Peor aún, alguien interno podría corromper el libro mayor, y este tipo de ataque es difícil de detectar o probar. Por lo tanto, dondequiera que tengamos un libro mayor centralizado, debemos invertir una cantidad considerable de tiempo y dinero en mecanismos para mantener su integridad. Y en muchos casos, requerimos una verificación continua mediante la conciliación por lotes entre el libro mayor central y los de cada una de las partes de la transacción.

La blockchain (o "libro contable compartido") ofrece las ventajas de los libros contables sin el problema de la concentración.

En cambio, cada entidad gestiona un "nodo" que contiene una copia del libro mayor y mantiene control total sobre sus propios activos, protegidos por claves privadas. Las transacciones se propagan entre nodos de igual a igual, y la cadena de bloques garantiza el mantenimiento del consenso.

Esta arquitectura elimina cualquier punto de ataque central mediante el cual un hacker o persona con información privilegiada pueda corromper el contenido del libro mayor. Como resultado, se puede implementar un sistema financiero digital de forma más rápida y económica, con la ventaja añadida de la conciliación automática en tiempo real.

¿Cuál es la desventaja? Como se mencionó anteriormente, todos los participantes en un libro de contabilidad compartido ven todas las transacciones, lo que lo hace inutilizable en situaciones donde se requiere confidencialidad. En cambio, las cadenas de bloques son adecuadas para lo que llamo sistemas financieros ligeros, es decir, aquellos en los que el riesgo económico o el número de participantes es relativamente bajo.

En estos casos, la confidencialidad suele ser un problema menor; incluso si los participantes prestan mucha atención a lo que hacen los demás, no Aprende mucho. Y es precisamente porque hay poco en juego que preferimos evitar las complicaciones y el coste de establecer un intermediario.

Algunos ejemplos obvios de sistemas financieros livianos incluyen: el crowdfunding, las tarjetas de regalo, los puntos de fidelidad y las 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 Finanzas convencional, como el comercio entre pares entre gestores de activos que no compiten directamente. Las cadenas de bloques incluso se están probando como sistemas de contabilidad interna en grandes organizaciones donde cada departamento o sede 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 caso de uso que escuchamos repetidamente de los usuarios de MultiChain: rastrear el origen y el movimiento de artículos de alto valor a través de unacadena de suministro, como artículos de lujo, productos farmacéuticos, cosméticos y electrónicos. E igualmente, documentación crítica 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 falsificaciones y robos.

El problema se puede abordar mediante cadenas de bloques de la siguiente manera: cuando se crea un artículo de alto valor, una entidad confiable emite un token digital correspondiente, que autentica su origen. Luego, cada vez que el artículo físico cambia de manos, el token digital se transfiere en paralelo, de modo que la cadena de custodia real se refleja con precisión en una cadena de transacciones en la cadena de bloques.

Si lo desea, el token actúa como un "certificado de autenticidad" virtual, 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, un distribuidor, un minorista o un cliente, puede verificar la cadena de custodia hasta el punto de origen. De hecho, en el caso de documentación como los conocimientos de embarque, podemos prescindir por completo del artículo físico.

Si bien todo esto tiene sentido, el lector perspicaz notará que una base de datos convencional, 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, aceptaría transacciones firmadas que representan cada cambio de propiedad y respondería a las solicitudes entrantes sobre el estado actual de la situación.

Entonces, ¿por qué usar una cadena de bloques? La respuesta es que, para este tipo de aplicación, la confianza distribuida ofrece un beneficio.

Independientemente de dónde se encuentre una base de datos centralizada, habrá personas en ella con la capacidad (y la posibilidad de sobornar) 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 ni grupo pequeño de entidades puede corromper la cadena de custodia, y los usuarios finales pueden confiar más en las respuestas que reciben.

Como beneficio adicional, se pueden intercambiar de forma segura y directa diferentes tokens (por ejemplo, para algunos bienes y el conocimiento de embarque correspondiente), con un intercambio bidireccional garantizado en el nivel más bajo de la cadena de bloques.

¿Qué hay del problema de la confidencialidad? La idoneidad de las cadenas de bloques para la procedencia de la cadena de suministro se debe al sencillo patrón 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 intercambiarse repetidamente entre los participantes de la cadena de bloques.

Si los competidores rara vez realizan transacciones entre sí (por ejemplo, de un fabricante de juguetes a otro, o de un minorista a otro), no pueden Aprende 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 varios registros, cada uno de los cuales representa un pedido o tipo de producto diferente.

Mantenimiento de registros interorganizacionales

Ambos casos de uso anteriores se basan en activos tokenizados, es decir, representaciones en cadena de un elemento de valor transferido entre participantes.

Sin embargo, existe un segundo grupo de casos de uso de blockchain que no está relacionado con los activos. En cambio, la blockchain actúa como un mecanismo para registrar y certificar colectivamente cualquier tipo de datos, ya sea de carácter financiero o de otro tipo.

Un ejemplo de ello es un registro de auditoría de comunicaciones críticas entre dos o más organizaciones, por ejemplo, en los sectores sanitario o jurídico. No se puede confiar a ninguna organización del grupo el mantenimiento de este archivo de registros, ya que la información falsificada o eliminada perjudicaría significativamente a las demás. No obstante, es fundamental que todas estén de acuerdo sobre el contenido del archivo para evitar disputas.

Para resolver este problema, necesitamos una base de datos compartida donde se escriban todos los registros, cada uno acompañado de una marca de tiempo y una prueba de origen. La solución estándar sería crear un intermediario de confianza, cuya función sea recopilar y almacenar los registros de forma centralizada.

Pero las cadenas de bloques ofrecen un enfoque diferente. Ofrecen a las organizaciones una forma de gestionar conjuntamente este archivo, al tiempo que evitan que los participantes individuales (o pequeños grupos de ellos) lo corrompan.

Una de las conversaciones más enriquecedoras que he tenido en los últimos dos años fue con Michael Mainelli, de Z/Yen. Durante 20 años, su empresa ha desarrollado sistemas en los que múltiples entidades gestionan colectivamente un registro de auditoría digital compartido, utilizando sellos de tiempo, firmas digitales y un sistema de consenso por turnos.

Al explicar los detalles técnicos de estos sistemas, quedó claro que son cadenas de bloques con permisos en todos los aspectos. En otras palabras, no hay nada nuevo en el uso de una cadena de bloques para el registro de datos interorganizacionales; simplemente, el mundo finalmente ha tomado conciencia de esta posibilidad.

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

Datos sin cifrar.Esto puede ser leído por cada participante en la cadena de bloques, lo que proporciona una transparencia colectiva total y una resolución inmediata en caso de disputa.

Datos cifrados.Solo los participantes con la clave de descifrado correspondiente pueden leer esta información. En caso de disputa, cualquiera puede revelar esta clave a una autoridad de confianza, como un tribunal, y usar la cadena de bloques para demostrar que los datos originales fueron añadidos por una parte específica en un momento determinado.

Datos en formato hash.Un "hash" actúa como una huella digital compacta, representando un compromiso con un dato específico, manteniéndolo oculto. Dados ciertos datos, cualquiera puede confirmar fácilmente si coinciden con un hash dado, pero inferir datos a partir de él es computacionalmente imposible. Solo el hash se almacena en la cadena de bloques, y los datos originales se almacenan fuera de la cadena por las partes interesadas, quienes pueden revelarlos en caso de disputa.

Como se mencionó anteriormente, el producto Corda de R3CEV ha adoptado este tercer enfoque: almacena hashes en una cadena de bloques para certificar los contratos entre las contrapartes, sin revelar su contenido. Este método puede utilizarse tanto para descripciones de contratos legibles por computadora como para archivos PDF con documentación en papel.

Naturalmente, la confidencialidad no es un problema para la gestión de registros interorganizacionales, ya que el objetivo principal es crear un archivo compartido que todos los participantes puedan ver (incluso si algunos datos están cifrados o hash). De hecho, en algunos casos, una cadena de bloques puede ayudar a gestionar 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 es necesario crear una entidad adicional ni confiarle el mantenimiento de este registro.

Agregación multipartidista

Técnicamente hablando, este último caso de uso es similar al ONE, ya que varias partes escriben datos en un registro gestionado colectivamente. Sin embargo, en este caso, la motivación es diferente: superar la dificultad infraestructural que supone combinar información de un gran número de fuentes distintas.

Imaginemos dos bancos con bases de datos internas de verificación de identidad de clientes. En un momento dado, se dan cuenta de que comparten muchos clientes, por lo que firman un acuerdo de intercambio recíproco en el que intercambian datos de verificación para evitar la duplicación de tareas.

Técnicamente, el acuerdo se implementa mediante la replicación de datos maestro-esclavo estándar, donde cada banco mantiene una copia activa de solo lectura de la base de datos del otro y ejecuta consultas en paralelo en su propia base de datos y la réplica. Hasta aquí, todo bien.

Ahora, imaginemos que estos dos bancos invitan a otros tres a participar en este círculo de intercambio. Cada uno de los cinco bancos gestiona su propia base de datos maestra, junto con cuatro réplicas de solo lectura de las demás. Con cinco bases de datos maestras y 20 réplicas, tenemos un total de 25 instancias de base de datos.

Si bien es factible, esto consume mucho tiempo y recursos en el departamento de TI de cada banco.

Si avanzamos rápidamente hasta el punto en que 20 bancos comparten información de esta manera, nos encontramos con un total de 400 instancias de base de datos. Para 100 bancos, llegamos a 10 000 instancias. En general, si todas las partes comparten información entre sí, el número total de instancias de base de datos crece con el cuadrado del número de participantes. En algún momento de este proceso, el sistema está destinado a colapsar.

¿Cuál es entonces la solución? Una opción obvia es que todos los bancos envíen sus datos a un intermediario de confianza, cuya función es agregarlos en una única base de datos maestra. Cada banco podría entonces consultar esta base de datos remotamente o ejecutar una réplica local de solo lectura en su propia sede.

Si bien este enfoque no tiene nada de malo, las cadenas de bloques ofrecen una alternativa más económica, en la que la base de datos compartida es administrada directamente por los bancos que la utilizan. Las cadenas de bloques también ofrecen la ventaja adicional de...redundancia y conmutación por errorpara el sistema en su conjunto.

Es importante aclarar que una cadena de bloques no actúa simplemente como una base de datos distribuida comoCasandra o Repensar la base de datosA diferencia de estos sistemas, cada nodo de la cadena de bloques aplica un conjunto de reglas que impiden que un participante modifique o elimine los datos añadidos por otro.

De hecho, todavía parece haber cierta confusión al respecto: una plataforma blockchain recién lanzada puede verse comprometida por un solo nodo con mal comportamiento. En cualquier caso, una buena plataforma también facilitará la gestión de redes con miles de nodos, que pueden unirse y abandonar libremente, si se les otorgan los permisos adecuados.

Aunque soy un poco escéptico sobre la conexión frecuentemente citada entre las cadenas de bloques y el Internet de las Cosas, creo que aquí podría residir una fuerte sinergia. Claro que cada "cosa" sería demasiado pequeña para almacenar una copia completa de la cadena de bloques localmente. En su lugar, transmitiría las transacciones con datos a una red distribuida de nodos de la cadena de bloques, quienes los recopilarían para su posterior recuperación y análisis.

Conclusión: Blockchain en las Finanzas

Comencé este artículo cuestionando el caso de uso inicial previsto para las cadenas de bloques en el sector Finanzas , es decir, la liquidación masiva de transacciones de pago e intercambio.

Si bien creo que esta conclusión se está generalizando (con una notable excepción), esto no significa que las cadenas de bloques no tengan otras aplicaciones en este sector. De hecho, para cada uno de los cuatro casos de uso descritos anteriormente, observamos aplicaciones claras para bancos y otras instituciones financieras. Estas son, respectivamente: pequeños círculos comerciales, procedencia para Finanzas comercial, certificación de contratos bilaterales y agregación de datos AML/KYC.

Lo clave para entender es que, arquitectónicamente, nuestras cuatro clases de casos de uso no son específicas de las Finanzas y son igualmente relevantes para otros sectores, como seguros, atención médica, distribución, manufactura y TI.

De hecho, las cadenas de bloques privadas deberían 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 provenga de una única fuente.

En estos casos, las cadenas de bloques ofrecen una alternativa a la necesidad de un intermediario confiable, lo que genera ahorros significativos en molestias y costos.

Este artículo fue publicado originalmente enBlog de MultiChainy se ha vuelto a publicar aquí con el permiso del autor.

Cofre del tesoroimagen vía Shutterstock