El poderoso potencial y desafíos de Blockchain en la cadena de suministro

Introducción

En este documento, exponemos el resultado de un análisis acerca de como Blockchain puede revolucionar la Cadena de Suministro y cómo lo hará. Nuestra conclusión es que la respuesta es un sí calificado.
Para responder realmente a esta pregunta, tenemos que entender qué son exactamente Blockchains y qué es lo que nos aportan. Durante el proceso, presentaremos una forma más matizada de mirar Blockchain e introduciremos algunos nuevos conceptos, ideas y taxonomía que proporcionarán un marco conceptual para responder a esta pregunta.
Aunque este documento está escrito en el contexto de Supply Chains, creemos que las ideas son aplicables a una amplia gama de problemas multilaterales.

¿Qué son los Blockchain?

Para entender Blockchain uno debe comenzar con la criptomoneda Bitcoin. Cuando Bitcoin irrumpió en escena en 2008, se convirtió en la primera criptomoneda ampliamente adoptada (como una tercera alternativa a las dos clases principales de monedas existentes, a saber, monedas FIAT como el dólar estadounidense y monedas de productos básicos como el oro).
Lo interesante de Bitcoin (a diferencia de las monedas de FIAT) es que no requirió ningún intermediario de confianza como los Bancos en general o los Bancos Centrales en particular para su funcionamiento.
La propiedad más importante de Bitcoin era su naturaleza de desintermediación. A medida que Bitcoin comenzó, la gente comenzó a preguntarse si los principios de Bitcoin podrían aplicarse a otros problemas. Los principios arquitectónicos generales detrás de Bitcoin se “extrajeron” como Blockchains.
La nomenclatura específica de “Blockchain” se deriva de algunos de los bloques de construcción subyacentes de Bitcoin. Pero es importante entender que Blockchain es más un conjunto de principios que se pueden interpretar de muchas maneras diferentes y, por lo tanto, hay docenas de tipos y variaciones de Blockchains. Veremos más sobre esto más adelante.
Entonces, ¿cuáles son las ideas claves subyacentes de Blockchain? Blockchain se ha convertido en una base de datos compartida o en un Ledger en el que cualquiera puede escribir y todos pueden leer y sin un propietario central.
Ahora, creemos que la analogía de la Base de datos compartida es algo engañosa. Esto se debe a que, si bien es cierto que cualquiera puede escribir en Blockchain, estas escrituras están mediadas por reglas complejas y validaciones específicas de ese Blockchain. Por ejemplo, en Bitcoin Blockchain, una de las reglas es que una persona no puede gastar dinero (es decir, Bitcoins) que no tiene. Si bien una base de datos típica tiene algunas reglas (llamadas restricciones), por lo general no son compatibles con la lógica empresarial sofisticada.
[su_pullquote align=”right”]Blockchain es una tecnología que permite la realización confiable y segura de cualquier tipo de transacciones entre dos o mas personas sin necesidad de intermediarios, a través de internet.[/su_pullquote]
Por lo tanto, una base de datos compartida mediada es una mejor analogía. Ahora, una base de datos también tiene la connotación de “cosa” que contiene los datos en lugar de los datos en sí. Los datos en sí se denominan Estado. A los efectos de esta discusión, es el estado compartido subyacente y sus características las que más adelante informarán la discusión. Entonces, en base a esto, las características clave de Blockchains son:
[su_pullquote align=”right”]Blockchain también es llamada tecnología de contabilidad distribuida (Distributed Ledger Technology – DLT), consiste en una ingente base de datos compartida entre muchos participantes, de carácter público o privado, protegida criptográficamente y organizada en bloques relacionados entre si matematicamente.[/su_pullquote]

• Estado (datos) compartido mediado (para fines de escritura)
• No hay un propietario central del estado compartido mediado.
• “Cualquiera” puede “escribir” en el estado compartido mediado
• “Cualquiera” puede “leer” el estado compartido (no se requieren mediadores)
• Retraso en la versión única de la verdad.
  • El estado compartido tiene una única versión probable de la verdad. (La probabilidad de que una transacción se “revierte” disminuye exponencialmente). La falta de un propietario central implica que deben distribuirse tanto el estado compartido (datos) como los medios (es decir, la lógica de negocios).

¿Puede el estado compartido mediado revolucionar la cadena de suministro?

La respuesta a esta pregunta es un sí no calificado. Actualmente, las cadenas de suministro y los procesos comerciales relacionados están muy fragmentados en miles de socios comerciales. Los procesos empresariales se pueden mejorar dramáticamente al pasar de un estado altamente fragmentado a un estado compartido mediado.
La cadena de suministro puede pasar a una versión única de la verdad que a su vez permite un sentido y respuesta casi real, lo que a su vez conduce al drama más allá de las métricas comerciales, como niveles de inventario más bajos, niveles de servicio más altos, menores costos totales de desembarque, etc.
Entonces, ¿cuál es el truco? El problema es que Blockchain no se trata solo de un estado compartido mediado por (no propietario), sino que también viene con otros (para muchos casos de uso) con menos características bienvenidas, por ejemplo:

• “Cualquiera” puede “leer” el estado compartido (no se requieren mediadores).

La mayoría de los participantes en la cadena de suministro no quieren que su información sea compartida con sus competidores, y mucho menos “todos”.
Otra forma de demostrar esto es que solo hay un subconjunto relativamente pequeño de problemas en la cadena de suministro cuando esta es una característica aceptable.
Nos referiremos a esto como el problema de “todos pueden leer todo”.

Comunidades de Blockchain

Ademas de mí mismo, otras personas intentan resolver varios problemas comerciales donde intervienen varias partes con Blockchain, todos ellos siguen chocando contra el problema de “todos pueden leerlo todo”. Y así nació la idea de Permissioned Blockchain (Blockchain Autorizados). Estos también se conocen como Private Blockchain.
Existe un gran debate en la comunidad tecnológica sobre si estos son verdaderamente Blockchain o simplemente bases de datos distribuidas de lujo. Una de las diferencias radica en cómo estos sistemas distribuidos alcanzan el consenso.
Pero ese debate no es particularmente relacionado con los beneficios de este enfoque.
Entonces, ¿qué son Permissioned Blockchain (Blockchain Autorizados)?
En la cadena de bloques original (ahora llamada cadenas bloqueadas no-públicas o públicas para diferenciarlas), “cualquier persona” podía iniciar una escritura mediada en el estado compartido y “cualquiera” podía leer el estado compartido.
La idea detrás de Permissioned Blockchain es que alguna autoridad central verificaría “quién” podría participar en el Blockchain. Entonces, en lugar de que “cualquiera” pudiera leer o escribir en Blockchain, ahora solo los miembros de la comunidad podrían hacerlo. Por esta razón, preferimos el término Community Blockchain.
Entonces las características de Community Blockchains son:

• Estado compartido mediado
• Hay un propietario central que determina quién puede par cipar en la cadena comunitaria Blockchain.
• “Cualquier miembro de la comunidad “puede” escribir” en el estado compartido mediado
• No hay un propietario central del estado compartido mediado
• “Cualquier miembro de la comunidad “puede” leer” el estado compartido (sin mediadores)
• “Retraso en la versión única de la verdad”.

 
Entonces, ¿los Blockchains comunitarios resuelven los problemas de Public Blockchains?
Desafortunadamente, en su mayor parte, no. Una vez más, el punto de vista es esta característica:

• ” Cualquier miembro de la comunidad “puede” leer” el estado compartido (sin mediadores)

El problema es cómo se llega a la “comunidad”. Por ejemplo, si tomamos el ejemplo de Global Trade, tal vez la comunidad estaría compuesta por Compradores, Vendedores, Navieras, Transportistas Terrestres, 3PL, 4PL’s, Puertos, Aduanas, Agentes de Carga, etc.
Incluso en una comunidad como esta, los compradores (por ejemplo) no querrían (dirían) que otros compradores vean información sobre sus (digamos) pedidos.

¿Micro-community blockchains al rescate?

Una solución aparente al problema de “cada miembro puede leer todo” es la idea de Micro-Community Blockchains. Aquí tenemos Micro-Comunidades donde la membresía es tan pequeña que el hecho de que cada miembro puede leer todo ya no es un problema. Este es el enfoque adoptado por proyectos como HyperLedger.
Hay dos tipos de microcomunidades que parecen plausibles a primera vista.

1. Parwise Micro-Community Blockchains (por pares)
   En este enfoque, cada par de socios comerciales tiene una microcomunidad por parejas.Si bien es un avance sobre la mensajería punto a punto como EDI, esta es una balcanización masiva del estado de la cadena de suministro compartido y las ventajas que se derivan de eso.Cosas simples como Single-Version-of-the Truth, transacciones comerciales de dos partes con más de dos paréntesis (workflow arity > 2) no son factibles con este enfoque.
2. Per-Business-Transaction Micro-Community BlockchainsEn este enfoque, cada transacción comercial individual (por ejemplo, cada orden individual) forma una microcomunidad con los participantes de solo esa orden específica. Si bien este enfoque puede funcionar para aplicaciones muy simples, tiene algunos problemas importantes.
   1. Se basa en las escrituras mediadas que tienen el alcance de una sola transacción comercial. Esto es raro. Por ejemplo, las escrituras mediadas para una transacción comercial requieren acceso a información de datos maestros así como a información sobre transacciones relacionadas (que pueden ser entre otras partes).
   2. Las diferentes Micro-Community son inconsistentes entre sí. En otras palabras, no hay una versión única de la verdad. Ni siquiera una Demorada versión única de la verdad de un solo Blockchain.
   3. Incluso por transacción en visibilidad de “todo el mundo puede ver todo” continua siendo un problema en muchos casos.
   4. Los permisos de cross-micro-community son un problema.

Consideremos un ejemplo para ilustrar estos problemas. En la figura a continuación vemos un simple Escenario de Drop Ship. En un escenario Drop Ship, un Comprador coloca un Pedido en un Vendedor que a su vez comparte el Pedido con un Fuller que a su vez crea un Envío y lo presenta a un Transportista para que lo recoja y entregue.

En este ejemplo, si Order1 pertenece aun una Micro-Comunidad Blockchain y Shipment1 es de otra Micro-Comunidad Blockchain, tenemos muchos problemas:

1. Supongamos que solo el Comprador y el Vendedor deben ver el precio en ORDER1, mientras que Fullfillment no tiene motivos para ver el precio. Esto no se puede lograr con una sola ORDER1 Blockchain.
   1. Una de las opciones es dividir Order en dos réplicas de pedido ligeramente diferentes, una con el precio y otra sin el precio. Ahora hemos introducido un problema mas de sincronización.
2. El sistema de registro para los estados ENVIADO y RECIBIDO está en ENVÍO1. La orden simplemente debe reflejar estos estados. Sin embargo, esto plantea muchos problemas.
   1. En el mejor de los casos, hay un retraso entre los Estados de envío que se propagan a la Orden.
   2. ¿Quién es responsable de esta sincronización? ¿Es posible garantizar que siempre haya una parte que tenga los permisos suficientes para realizar esta sincronización?
3. Supongamos que el envío se ENVÍA, pero este estado no se ha sincronizado con el pedido aún (que se encuentra en estado ABIERTO) y el comprador CANCELA el pedido. Ahora tenemos un estado inconsistente. La falta de consistencia entre las microcomunidades puede causar incoherencias masivas.
4. El Comprador, el Vendedor y el Proveedor necesitan los detalles del nivel de artículo en el Envío. El Operador debe tener una vista agregada del envío basada en el código de producto. Debido a que la información se replica en todas las partes de la transacción, no es posible lograr esto.

 
¿Podrían resolverse algunos de estos problemas si se ordenan ORDER1 y SHIPMENT1 en una sola y más grande Micro-Comunidad? Incluso esto es problematico.
Supongamos que ORDER1 tiene dos líneas de pedido, una completada por Fullfiller 1 y otra por Fullfiller 2. Fulfiller 2 contrata a un Transportista diferente y hay un Envío diferente (por ejemplo, SHIPMENT2). Entonces, ahora tendríamos que poner SHIPMENT2 también en la misma Micro-Comunidad. Pero las partes que pueden ver SHIPMENT1 son diferentes de las que pueden ver SHIPMENT2.
En general, el problema es que las transacciones de la Cadena de Suministro no están compartimentadas. En cambio, forman una estructura de tipo gráfico. ¿Dónde se encuentran los límites de este gráfico? Además, mientras más amplia sea la Micro-Comunidad, más grave se vuelve el problema de que todo el mundo puede ver.
Además, en las actuales cadenas de suministro inteligentes de hoy, las escrituras externas de una sola parte no son el único tipo de escrituras. Los agentes inteligentes monitorean constantemente el estado compartido real y se desencadenan por ciertos eventos. Estos agentes trabajan leyendo un poro del estado compartido (o llamado subred), determinan cómo reaccionar a estos eventos (generalmente usando algoritmos de optimización, programación lineal, programación entera, optimización heuristica, algoritmos Estocástico, algoritmos de aprendizaje automático, etc., y luego retornar a el estado compartido. Cada agente inteligente funciona normalmente en una subred diferente (o en ortogonal).
Los ejemplos de agentes inteligentes incluyen Connous Forecasting, Last Minute Allocation, Prioritized Expedite, Supply Disruption, Re-promising, etc. Agentes inteligentes.
La siguiente figura muestra una vista simplificada de cómo diferentes agentes pueden (ortogonalmente) dividir el estado general compartido.
Esto da como resultado la necesidad de un modelo de permisos profundo y matricial en lugar de un modelo de permisos compartimentados y poco profundos para Micro-community Blockchains.

Estos agentes inteligentes están en el corazón del potencial revolucionario del estado compartido mediado y son esencialmente imposibles con el enfoque Micro-Community Blockchain.
 

BACKCHAIN e Iniciadores de BACKCHAIN

Debido al problema de que “cada miembro puede leer todo” y luego de ver que las cadenas de bloques de microcomunidades no resuelven el problema, aparentemente estamos atrapados en un pequeño subconjunto del espacio del problema.
Sin embargo, hay luz al final del túnel. En el cambio de Blockchain Público a Comunitario sacrificamos parte de la descentralización de Blockchain públicas para un beneficio. En este caso particular, introdujimos la centralización en la decisión de quién puede ser miembro de la comunidad (desventaja) para restringir las habilidades de lectura y escritura a una comunidad vetada (beneficio).
Con el Patrón de Backchain (que exploraremos con cierto detalle), sacrificamos un elemento adicional de descentralización para un aumento masivo de beneficios.
En el patrón Backchain, las escrituras están mediadas por una entidad centralizada, llamada Backchain Initiator (desventaja debido a la centralización adicional) por la capacidad de abordar casi todos los problemas de la cadena de suministro de múltiples partes en tiempo real (beneficio).
En el patrón Backchain, todos los pares encaminan sus escrituras a través del Backchain Initiator. El Backchain Initiator es la única fuente con acceso de lectura (sin cifrar) a todo el estado compartido mediado. El Backchain Initiator también mantiene una Versión Única Transitoria de la Verdad del estado compartido.
Esto permite que el Backchain Initiator ejecute escrituras mediadas arbitrariamente complejas que pueden acceder al estado compartido completo.

 
El Backchain Initiator también puede ejecutar Intelligent Agents, ya que puede recuperar cualquier subred requerida debido a su acceso de lectura sin restricciones a todo el estado compartido mediado. El Backchain Initiator también puede mantener una única versión de la verdad a diferencia del enfoque Micro-comunitario.
Esto expande esencialmente el rango de problemas direccionables a todo el espacio problemático de la cadena de suministro multipartita. Además, da como resultado los beneficios comerciales de pasar al estado Compartido Mediado en términos de mejoras dramáticas en las métricas de la cadena de suministro.
Una vez que una transacción es mediada por el Backchain Initiator , es cortada por el socio comercial y luego desmenuzada (o encriptada) y colocada en un Blockchain llamada Backchain por el Backchain Initiator. De esta forma, cada parte aún tiene un registro inmutable y no repudiable en todas las transacciones.
Esto tiene la muy importante propiedad de exigir a las partes que solo coloquen la “Confianza Transitoria” en el Backchain Initiator en lugar de “Confianza Perpetua”. La figura a continuación ilustra el principio de la Versión Única de la Verdad (SVOT) en este esquema.

Tenga en cuenta que debido a que la información en la Backchain está encriptada o codificada criptográficamente, la Backchain puede ser una cadena de bloques pública o comunitaria. También nos referimos a esta Backchain como una “Content Backchain” para distinguirla de la “Hold Backchain”, de la que hablaremos a continuación.

 

Hold Backchain

Debido a que Backchain Initiator coloca las transacciones en una Blockchain descentralizada (Backchain), reducimos la necesidad de confianza en una entidad centralizada de “Perpetua a Transitorio”.
Si el Backchain Initiator se ve comprometido en algún momento del mes o bien cierra, esto no tiene ningún impacto en la validez de las transacciones históricas y su no repudiabilidad. Esta es una reducción masiva en dependencia de una entidad centralizada.
¿Pero podemos ir más allá e incluso tener mecanismos para reducir el problema de la confianza transitoria?
Debido a que la Backchain está activada por un Backchain Initiator centralizado, existe la posibilidad de un Initiator comprometido. Uno de los principales propósitos de Blockchain es eliminar la posibilidad de intermediarios comprometidos.
El problema básico es escribir de forma validada. La forma en que normalmente hacen esto los mediadores centralizados de estados compartidos, es hacer devoluciones de llamadas a las partes afectadas (socios comerciales) para validar el estado final de la transacción justo antes de comprometerse con el estado compartido. Sin embargo, a los efectos de tratar con un mediador comprometido, esto no funciona, ya que el mediador (el Backchain Initiator en este caso) podría simplemente ignorar los resultados de la validación en la devolución de llamada que se envió al socio comercial afectado.
En cambio, se usa otro mecanismo que se basa en el concepto de Retenciones (Hold). La mayoría de las transacciones comerciales (como pedidos, envíos, movimientos y facturas, etc.) tienen el concepto de retención. La idea de las suspensiones es que “detienen”, “retienen” o “limitan” la transacción comercial de alguna manera. Existen varios tipos de retenciones, como retenciones de crédito, de inventario, de facturas, etc.
Una característica importante de Holds es que se los considera parte del propio Proceso de Negocio (es decir, no son un concepto técnico como (digamos) “deshacer” una transacción). El segundo aspecto importante de Holds es que son Transacciones comerciales de primera clase por derecho propio y son típicamente asincrónicas en relación con la Transacción comercial que están “reteniendo”.
El patrón de Backchain introduce una nueva categoría de Holds llamada Mediator Hold. Llamaremos Retenciones “normales” como Retenciones de crédito, Retenciones normales. Las retenciones normales son aplicadas por los socios comerciales a las Transacciones Comerciales basadas en actividades de socios comerciales (incluidos ellos mismos). Básicamente tratan al Mediador como transparente o ausente.
Por el contrario, el Mediator Hold es un Hold donde un socio comercial ha perdido la confianza o tiene algún otro problema con el Mediator (Backchain Initiator). Para asegurarse de que el Backchain Initiator no pueda alterar las Retenciones de Mediador, los Socios de Mediación son colocados por los socios comerciales directamente en otra Blockchain llamada Hold Backchain. Las Retenciones normales van al Backchain Initiator como todas las otras escrituras.
El Hold Backchain tendrá una ventana de retención integrada en su protocolo Blockchain. La ventana de retención es una duradera en la que una transacción se escribe en la Content Backchain (contenido) durante la cual los socios comerciales pueden colocar una retención de mediador en una transacción de negocio.

Por ejemplo, si la ventana de retención es de una hora, los socios comerciales tendrán una hora para levantar una retención de mediador antes de considerar que la transacción ya no está sujeta a este tipo de retención.
Al igual que todas las demás Retenciones, la Retención de Mediación está integrada en el proceso de negocios en sí y todas las partes reaccionarán en función de este proceso de negocios. El Backchain Initiator (que presumiblemente no se considera comprometido) leerá la cadena de espera y reaccionará potencialmente a un Mediator Hold colocado por un socio comercial.
El elemento crítico aquí es que el mediador centralizado no tiene la capacidad de influir en la ubicación de Mediator Holds. Y así, si las transacciones producidas a través del Backchain Initiator se ven comprometidas (es decir, se viola la confianza transitoria), estas transacciones pueden ser rechazadas (dentro de la Ventana de Espera).
En una cadena de bloques comunitaria, elevar una retención de mediador debería ser un evento muy raro. La única solución infalible es dejar de utilizar el Backchain Initiator y pasar a un “modo reducido” de funcionamiento de utilizar solo Front Chains (ver más abajo para la definición de esto). Por ejemplo, las empresas pueden recurrir a una Front Chains de microcomunidad en modo reducido o EDI tradicional. En la práctica, dado que el Backchain Initiator probablemente será una entidad responsable de algún tipo, el problema se escalará a algún mecanismo de gobernanza definido.
La figura anterior muestra la interacción de un socio comercial con una Front Chains, un Backchain Initiator, la Content Backchain y la Hold Backchain.

Cifrado Vs. Cristógrafo – Content Backchain

La Content Backchain (cadena de contenido) que contiene los registros de transacciones divididos por socio comercial (profundo, matricial) por causa de los permisos de lectura no almacena la transacción completa (dividida) en forma “clara”. En cambio, el contenido (la transacción dividida) se almacena en Formulario encriptado o cifrada.
Nota: Usamos el término “Permisos profundos y matriciales” para descubrir los Permisos de todos los miembros (All-members-can-see-everything), que son las características de las llamadas Blockchain Permitidas (que, como mencionamos antes, preferimos llamarlas Community Blockchain para evitar esta confusión).
La estructura de un mensaje de registro en la cadena de contenido se parece a:

1. Metadatos (sin encriptar)
2. Contenido completo (encriptado o codificado criptográficamente)

Existen pros y contras del Encriptado vs Cirado (Hashing) del contenido completo que exploraremos en esta sección.
Desde el enfoque de encriptación, todo el contenido está encriptado (aparte de algunos metadatos). La ventaja de esto es que un socio comercial puede usar su clave de descifrado para recrear todo el (subconjunto) del estado de la cadena de suministro al que tienen acceso (profundo) de lectura.
La desventaja de este enfoque es que todo el estado de la cadena de suministro compartido se replica a todos los miembros (esta es una propiedad básica de Blockchain), dando a un socio comercial una clave para “descifrar” el cifrado de otros socios comerciales.
Por esta razón, preferimos una Content Backchain criptográficamente codificada.
Se puede pensar que un hash criptográfico es esencialmente una “huella digital” de una pieza de contenido. Cada fragmento de contenido tendrá un hash criptográfico o huella digital únicos.
La característica distintiva de los algoritmos hash criptográficos es que es muy fácil “ir” del contenido al hash criptográfico, pero es imposible ir en la dirección opuesta.
Entonces, ¿por qué es esto útil? En primer lugar, otros socios comerciales nunca podrán intentar descifrar su contenido. En segundo lugar, si tiene el contenido, puede “demostrar” fácilmente que esa transacción (contenido) se ha producido presentándolo y mostrando que el hash criptográfico de su contenido presentado coincide con el hash criptográfico en la Backchain de contenido.
Entonces, ¿cómo puede un socio comercial obtener el contenido (transacción) que ha sido criptográficamente codificado y colocado en la cadena de contenido? Esencialmente, el Backchain Initiator pasa el contenido encriptado en rebanadas al socio comercial utilizando medios tradicionales (que no sean Blockchain).
Todos los socios comerciales monitorean constantemente el Content Backchain para cualquier transacción relevante para ellos. Si “ven” uno para “ellos mismos” inmediatamente verifican el contenido (que deberían haber recibido directamente del Backchain Initiator) con el hash en la Backchain. Si los valores hash no coinciden, deberían generar un Invalid-Hash Mediator Hold en el Hold Backchain. Si nunca recibieron el contenido original, deberían generar un No-Content-Received Mediator Hold en el Content Backchain.
El primero debería ser una situación rara. Esto último puede ocurrir con mayor frecuencia si, por ejemplo, existe un problema de conectividad entre el Backchain Initiator y el socio comercial.
Una vez más, al igual que con cualquier Mediator Hold, la resolución más drástica es pasar a un modo reducido de funcionamiento operando únicamente en Front Chains. En la práctica, especialmente en un entorno comunitario, estos se escalarán a mecanismos de gobernanza comunitaria.
 

 

Tratar con distintas vistas los resultantes del proceso de “n” vías

Una parte clave del Backchain Initiator es dividir las transacciones multipartidistas de “n” vías en “n” transacciones de una sola parte antes de hash y/o cifrado. Esta división multipartita de transacción se realiza utilizando el permiso de lectura correspondiente de cada parte en la transacción multipartita.
Debido a que las diferentes partes (en general) tienen diferentes permisos de lectura profunda en una transacción multipartita particular, en general tendrán diferentes “vistas” autorizadas de la misma transacción multipartita subyacente.
Por ejemplo, en el ejemplo de Drop-Ship anterior, el permiso de lectura del Fulfiller no les permitía ver el precio en el PEDIDO, mientras que el Comprador y el Vendedor podían hacerlo. Del mismo modo, el Vendedor y Fulfiller pueden tener acceso a la información compartida en el mismo PEDIDO que el Comprador no tiene acceso.
Esto conduce a un problema potencial con el no repudio de transacciones multipartitas (un propósito clave de Backchain).
Cada parte solo puede “probar” su visión de la transacción multipartita subyacente. Presentando su punto de vista y mostrando que tiene el cifrado al hash en la Backchain. El primer problema es que su punto de vista puede tener información que consideran privada, pero la única forma de “probarla” es presentar toda la vista. Esto presentaría problemas de seguridad. El segundo problema es porque su vista en general será diferente de las vistas de otras partes, lo que demuestra que la transacción multipartida compartida en el registro de transacciones de Backchain (en general) no será posible.
Esto se resuelve en el Backchain Initiator Pattern calculando todas las intersecciones posibles de las vistas de transacción de un solo partido y el hashing (o encriptado) también de estas intersecciones. Este algoritmo se conoce como el algoritmo multi-party-intersection.

Frontchains y Backchain

En base a la discusión anterior, ahora podemos ver cómo los Blockchain pueden revolucionar las cadenas de suministro. Ayuda a pensar en términos de una clasificación ortogonal de Blockchain, a saber. FrontChains y Backchain.
FrontChains se utiliza para aquellas aplicaciones de la cadena de suministro donde está bien que “todos” (o “cada miembro”) tengan acceso a todo el estado de datos compartidos de la cadena de suministro. Un ejemplo de FrontChain sería un FrontChain para la procedencia de artículos de alto valor (por ejemplo, Diamantes) en una cadena de suministro.
Lo importante a tener en cuenta es que no decimos que toda la cadena de suministro se ejecuta en FrontChains, sino que las aplicaciones de cadena de suministro específicas se ejecutan en FrontChain. FrontChains también se puede usar para operaciones de “modo reducido”. Por ejemplo, si se pierde la confianza en el Iniciador de Backchain, los socios comerciales podrían recurrir a una FrontChain Pairwise Micro-community.
Para las aplicaciones de la cadena de suministro donde esto no es deseable (que es la mayoría), se utiliza el Backchain Pattern .
Esto comprende 3 en es lógicas.
1) Un Iniciador de Backchain (no un Blockchain)
2) El contenido Backchain
3) El Hold Backchain
O en # 2 y # 3 se combinarán en una sola Blockchain (simplemente llamada “Backchain”).

Conclusion

Al comienzo de esta discusión, evaluamos que el potencial para que Blockchain revolucione las Cadenas de Suministro era un sí calificado. Ahora podemos ver cuál es esa calificación. La cualidad principal es la necesidad de tener un mediador no de Blockchain (es decir, el Backchain Initiator) para cubrir la mayoría de los casos de uso revolucionarios del estado compartido mediado de una sola versión de la verdad.
Sin embargo, a través del uso de Content Backchain reducimos la confianza necesaria de la confianza perpetua a la confianza transitoria. Y con Hold Backchain protegemos aún más contra las violaciones de la confianza transitoria.