Scaling Blockchains With Off-chain Data

Reeditado por Platón

seguidores: 0

Cuando un hash vale más que un millón de palabras

Por ahora, está claro que muchos casos de uso de blockchain no tienen nada que ver con las transacciones financieras. En cambio, el propósito de la cadena es permitir la agregación descentralizada, la ordenación, la marca de tiempo y el archivo de cualquier tipo de información, incluidos datos estructurados, correspondencia o documentación. El valor central de blockchain es permitir a sus participantes acordar de manera permanente y comprobable exactamente qué datos se ingresaron, cuándo y por quién, sin depender de un intermediario confiable. Por ejemplo, SAP lanzó recientemente plataforma blockchain, que admite MultiChain e Hyperledger Fabric, se dirige a una amplia gama de cadenas de suministro y otras aplicaciones no financieras.

La forma más sencilla de usar una cadena de bloques para registrar datos es incrustar cada pieza de datos directamente dentro de una transacción. Cada transacción de blockchain está firmada digitalmente por una o más partes, replicada en cada nodo, ordenada y marcada por el algoritmo de consenso de la cadena, y almacenada permanentemente de una manera a prueba de manipulaciones. Por lo tanto, cualquier dato dentro de la transacción será almacenado de manera idéntica pero independiente por cada nodo, junto con una prueba de quién lo escribió y cuándo. Los usuarios de la cadena pueden recuperar esta información en cualquier momento futuro.

Por ejemplo, MultiChain 1.0 permitió que se crearan una o más "secuencias" con nombre en una cadena de bloques y luego se usaran para almacenar y recuperar datos sin procesar. Cada secuencia tiene su propio conjunto de permisos de escritura, y cada nodo puede elegir libremente a qué secuencias suscribirse. Si un nodo está suscrito a una secuencia, indexa el contenido de esa secuencia en tiempo real, permitiendo que los elementos se recuperen rápidamente en función de su pedido, marca de tiempo, número de bloque o dirección del editor, así como a través de una "clave" (o etiqueta) por el cual los artículos pueden ser etiquetados. MultiChain 2.0 (desde alfa 1) extendió las secuencias para admitir texto Unicode o datos JSON, así como múltiples claves por elemento y múltiples elementos por transacción. También agregó funciones de resumen como "combinación JSON" que combinan elementos con la misma clave o editor de una manera útil.

Confidencialidad y escalabilidad.

Si bien el almacenamiento de datos directamente en una cadena de bloques funciona bien, adolece de dos deficiencias clave: confidencialidad y escalabilidad. Para comenzar con la confidencialidad, el contenido de cada elemento de transmisión es visible para todos los nodos de la cadena, y este no es necesariamente un resultado deseable. En muchos casos, una pieza de datos solo debe ser visible para un determinado subconjunto de nodos, incluso si se necesitan otros nodos para ayudar con su pedido, marca de tiempo y notarización.

La confidencialidad es un problema relativamente fácil de resolver, encriptando la información antes de incluirla en una transacción. La clave de descifrado para cada dato solo se comparte con aquellos participantes que deben verla. La entrega de claves se puede realizar en cadena utilizando criptografía asimétrica (como descrito aquí) o mediante algún mecanismo fuera de la cadena, como se prefiere. Cualquier nodo que carezca de la clave para descifrar un elemento no verá más que galimatías binarias.

La escalabilidad, por otro lado, es un desafío más significativo. Digamos que cualquier plataforma de cadena de bloques decente debería admitir un rendimiento de red de 500 transacciones por segundo. Si el propósito de la cadena es el almacenamiento de información, el tamaño de cada transacción dependerá principalmente de la cantidad de datos que contenga. Cada transacción también necesitará (al menos) 100 bytes de sobrecarga para almacenar la dirección del remitente, la firma digital y algunos otros bits y piezas.

Si tomamos un caso fácil, donde cada elemento es una pequeña estructura JSON de 100 bytes, el rendimiento general de datos sería de 100 kilobytes por segundo, calculado a partir de 500 × (100 + 100). Esto se traduce en menos de 1 megabit / segundo de ancho de banda, que está cómodamente dentro de la capacidad de cualquier conexión a Internet moderna. Los datos se acumularían a una tasa de alrededor de 3 terabytes por año, que no es una cantidad pequeña. Pero con discos duros de 12 terabytes ahora ampliamente disponibley RAID Controladores que combinan múltiples unidades físicas en una única lógica, podríamos almacenar fácilmente 10-20 años de datos en cada nodo sin demasiados problemas o gastos.

Sin embargo, las cosas se ven muy diferentes si estamos almacenando piezas de información más grandes, como la documentación escaneada. Un escaneo JPEG de calidad razonable de una hoja de papel A4 puede tener un tamaño de 500 kilobytes. Multiplique esto por 500 transacciones por segundo, y estamos viendo un rendimiento de 250 megabytes por segundo. Esto se traduce en 2 gigabits / segundo de ancho de banda, que es más rápido que la mayoría de las redes locales, y mucho menos las conexiones a Internet. En Amazon Web Services 'más barato precio publicado de $ 0.05 por gigabyte, significa una factura anual de ancho de banda de $ 400,000 por nodo. ¿Y dónde almacenará cada nodo los 8000 terabytes de datos nuevos generados anualmente?

Está claro que, para las aplicaciones blockchain que almacenan muchos datos grandes, el almacenamiento directo en cadena no es una opción práctica. Para agregar un insulto a la lesión, si los datos se cifran para resolver el problema de la confidencialidad, se les pide a los nodos que almacenen una gran cantidad de información que ni siquiera pueden leer. Esta no es una propuesta atractiva para los participantes de la red.

La solución hash

Entonces, ¿cómo resolvemos el problema de la escalabilidad de datos? ¿Cómo podemos aprovechar la notarización descentralizada de datos de la cadena de bloques, sin replicar esos datos en cada nodo de la cadena?

La respuesta es con una tecnología inteligente llamada "hash". Un hash es un número largo (piense en 256 bits, o alrededor de 80 dígitos decimales) que identifica de forma única un dato. El hash se calcula a partir de los datos utilizando un función unidireccional que tiene una propiedad criptográfica importante: dado cualquier dato, es fácil y rápido calcular su hash. Pero dado un hash particular, es computacionalmente inviable encontrar un dato que genere ese hash. Y cuando decimos "computacionalmente inviable", nos referimos a más cálculos que átomos en el universo conocido.

Los hashes juegan un papel crucial en todas las cadenas de bloques, al identificar de manera única las transacciones y los bloques. También subyacen al desafío computacional en sistemas de prueba de trabajo como bitcoin. Se han desarrollado muchas funciones hash diferentes, con nombres gobbledygook como BLAKE2, MD5 y RIPEMD160. Pero para que se pueda confiar en cualquier función hash, debe soportar una extensa revisión académica y pruebas. Estas pruebas vienen en forma de intentos de ataque, como "preimagen" (encontrar una entrada con el hash dado), "segunda preimagen" (encontrar una segunda entrada con el mismo hash que la entrada dada) y "colisión" (encontrar cualquier dos entradas diferentes con el mismo hash). Sobrevivir a este guante está lejos de ser fácil, con una larga y trágica historia de funciones hash rotas que demuestran la famosa máxima: "No tires tu propia criptografía".

Para volver a nuestro problema original, podemos resolver la escalabilidad de datos en blockchains incrustando los hash de grandes piezas de datos dentro de las transacciones, en lugar de los datos en sí. Cada hash actúa como un "compromiso" con sus datos de entrada, y los datos se almacenan fuera de la cadena de bloques o "fuera de la cadena". Por ejemplo, utilizando la popular función hash SHA256, una imagen JPEG de 500 kilobytes se puede representar mediante un número de 32 bytes, una reducción de más de 15,000 ×. Incluso a una velocidad de 500 imágenes por segundo, esto nos devuelve cómodamente al territorio de los requisitos de ancho de banda y almacenamiento factibles, en términos de los datos almacenados en la propia cadena.

Por supuesto, cualquier participante de blockchain que necesite una imagen fuera de la cadena no puede reproducirla desde su hash. Pero si la imagen se puede recuperar de otra manera, el hash en cadena sirve para confirmar quién la creó y cuándo. Al igual que los datos normales de la cadena, el hash está incrustado dentro de una transacción firmada digitalmente, que se incluyó en la cadena por consenso. Si un archivo de imagen se cae del cielo y el hash de esa imagen coincide con un hash en la cadena de bloques, se confirma el origen y la marca de tiempo de esa imagen. Entonces, la cadena de bloques proporciona exactamente el mismo valor en términos de notarización que si la imagen se incrustara directamente en la cadena.

Una cuestión de entrega

Hasta aquí todo bien. Al incrustar hashes en una cadena de bloques en lugar de los datos originales, tenemos una solución fácil al problema de la escalabilidad. Sin embargo, queda una pregunta crucial:

¿Cómo entregamos el contenido original fuera de la cadena a los nodos que lo necesitan, si no es a través de la propia cadena?

Esta pregunta tiene varias respuestas posibles, y sabemos que los usuarios de MultiChain las aplican a todas. Un enfoque básico es configurar un repositorio centralizado en alguna parte confiable, donde todos los datos fuera de la cadena se cargan y luego se recuperan. Este sistema podría usar naturalmente el "direccionamiento de contenido", lo que significa que el hash de cada pieza de datos sirve directamente como su identificador para la recuperación. Sin embargo, si bien esta configuración podría funcionar para una prueba de concepto, no tiene sentido para la producción, porque el objetivo de una cadena de bloques es eliminar intermediarios de confianza. Incluso si los hashes en cadena evitan que el intermediario falsifique datos, aún podría eliminar datos o no entregarlos a algunos participantes, debido a una falla técnica o las acciones de un empleado deshonesto.

Una posibilidad más prometedora es la comunicación punto a punto, en la que el nodo que requiere algunos datos fuera de la cadena lo solicita directamente desde el nodo que lo publicó. Esto evita depender de un intermediario confiable, pero tiene tres defectos alternativos:

Requiere un mapa de direcciones blockchain a direcciones IP, para permitir que el consumidor de algunos datos se comunique directamente con su editor. Las cadenas de bloques generalmente pueden evitar este tipo de configuración de red estática, que puede ser un problema en términos de conmutación por error y privacidad.
Si el nodo del editor original ha abandonado la red o está temporalmente fuera de servicio, nadie más podrá recuperar los datos.
Si una gran cantidad de nodos están interesados en algunos datos, entonces el editor se verá abrumado por las solicitudes. Esto puede crear una congestión de red severa, ralentizar el sistema del editor y generar demoras prolongadas para quienes intentan recuperar esos datos.

Para evitar estos problemas, lo ideal sería utilizar algún tipo de mecanismo de entrega descentralizado. Los nodos deberían poder recuperar los datos que necesitan sin depender de ningún sistema individual, ya sea un repositorio centralizado o el editor original de los datos. Si varias partes tienen un dato, deben compartir la carga de entregarlo a cualquier otra persona que lo desee. Nadie necesita confiar en una fuente de datos individual, porque los hashes en cadena pueden probar que los datos no han sido alterados. Si un nodo malicioso me entrega los datos incorrectos para un hash, simplemente puedo descartar esos datos e intentar preguntarle a alguien más.

Para quienes tienen experiencia con intercambio de archivos punto a punto protocolos como Napster, Gnutella o BitTorrent, todo esto sonará muy familiar. De hecho, muchos de los principios básicos son los mismos, pero hay dos diferencias clave. Primero, suponiendo que estamos usando nuestra cadena de bloques en un contexto empresarial, el sistema se ejecuta dentro de un grupo cerrado de participantes, en lugar de Internet en su conjunto. En segundo lugar, la cadena de bloques agrega una columna vertebral descentralizada de pedidos, sellado de tiempo y notarización, lo que permite a todos los usuarios mantener una visión demostrablemente consistente y resistente a la manipulación de exactamente lo que sucedió, cuándo y por quién.

¿Cómo podría un desarrollador de aplicaciones blockchain lograr esta entrega descentralizada de contenido fuera de la cadena? Una opción común es tomar una plataforma existente para compartir archivos de igual a igual, como la de nombre divertido Sistema de archivo interplanetario (IPFS), y úselo junto con blockchain. Cada participante ejecuta tanto un nodo blockchain como un nodo IPFS, con algo de middleware coordinado entre los dos. Al publicar datos fuera de la cadena, este middleware almacena los datos originales en IPFS, luego crea una transacción de blockchain que contiene el hash de esos datos. Para recuperar algunos datos fuera de la cadena, el middleware extrae el hash de la cadena de bloques, luego usa este hash para obtener el contenido de IPFS. El nodo IPFS local verifica automáticamente el contenido recuperado contra el hash para garantizar que no se haya cambiado.

Si bien esta solución es posible, todo es bastante torpe e inconveniente. Primero, cada participante tiene que instalar, mantener y actualizar tres piezas de software separadas (nodo blockchain, nodo IPFS y middleware), cada una de las cuales almacena sus datos en un lugar separado. En segundo lugar, habrá dos redes peer-to-peer separadas, cada una con su propia configuración, puertos de red, sistema de identidad y permisos (aunque debe tenerse en cuenta que IPFS aún no admite redes cerradas). Finalmente, unir estrechamente IPFS y blockchain juntos haría que el middleware sea cada vez más complejo. Por ejemplo, si queremos que los datos fuera de la cadena a los que hacen referencia algunas transacciones de blockchain se recuperen instantáneamente (con reintentos automáticos), el middleware debería estar constantemente en funcionamiento, manteniendo su propio estado complejo. ¿No sería bueno si el nodo blockchain hiciera todo esto por nosotros?

Datos fuera de cadena en MultiChain 2.0

Hoy estamos encantados de lanzar el tercera versión preliminar (alpha 3) de MultiChain 2.0, con una solución totalmente integrada y sin problemas para datos fuera de la cadena. Cada pieza de información publicada en una transmisión puede estar dentro o fuera de la cadena como se desee, y MultiChain se encarga de todo lo demás.

No realmente, queremos decir todo. Como desarrollador que se basa en MultiChain, no tendrá que preocuparse por los hashes, el almacenamiento local, el descubrimiento de contenido, la entrega descentralizada o la verificación de datos. Esto es lo que sucede detrás de escena:

El nodo de publicación MultiChain escribe los nuevos datos en su almacenamiento local, cortando elementos grandes en trozos para facilitar la digestión y la entrega.
La transacción para publicar elementos de flujo fuera de la cadena se crea automáticamente, y contiene los trozos hash y los tamaños en bytes.
Esta transacción se firma y se transmite a la red, propagándose entre nodos e ingresando a la cadena de bloques de la manera habitual.
Cuando un nodo suscrito a una secuencia ve una referencia a algunos datos fuera de la cadena, agrega los trozos hash para esos datos a su cola de recuperación. (Al suscribirse a una secuencia antigua, un nodo también pone en cola los elementos fuera de la cadena publicados anteriormente para su recuperación).
Como proceso en segundo plano, si hay fragmentos en la cola de recuperación de un nodo, las consultas se envían a la red para localizar esos fragmentos, tal como se identifican por sus hashes.
Estas consultas fragmentarias se propagan a otros nodos en la red de una manera punto a punto (limitado a dos saltos por ahora; consulte los detalles técnicos a continuación).
Cualquier nodo que tenga los datos para un fragmento puede responder, y esta respuesta se transmite al suscriptor a lo largo de la misma ruta que la consulta.
Si ningún nodo responde la consulta del fragmento, el fragmento se devuelve a la cola para volver a intentarlo más tarde.
De lo contrario, el suscriptor elige la fuente más prometedora para un fragmento (en función de los saltos y el tiempo de respuesta), y le envía una solicitud para los datos de ese fragmento, nuevamente a lo largo de la misma ruta de igual a igual que la respuesta anterior.
El nodo de origen entrega los datos solicitados, utilizando la misma ruta nuevamente.
El suscriptor verifica el tamaño de los datos y el hash contra la solicitud original.
Si todo se verifica, el suscriptor escribe los datos en su almacenamiento local, haciéndolos disponibles de inmediato para su recuperación a través de las API de transmisión.
Si el contenido solicitado no llegó o no coincidió con el hash o el tamaño deseado, el fragmento se devuelve a la cola para su recuperación futura de una fuente diferente.

Lo más importante, todo esto sucede extremadamente rápido. En redes con baja latencia, pequeñas cantidades de datos fuera de la cadena llegarán a los suscriptores dentro de una fracción de segundo de la transacción que los referencia. Y para aplicaciones de alta carga, nuestras pruebas muestran que MultiChain 2.0 alpha 3 puede soportar una tasa de más de 1000 elementos fuera de la cadena o 25 MB de datos fuera de la cadena recuperados por segundo, en un servidor de rango medio (Core i7) con un buen Conexión a Internet. Todo funciona bien con elementos fuera de la cadena de hasta 1 GB de tamaño, mucho más allá del límite de 64 MB para datos en cadena. Por supuesto, esperamos mejorar aún más estos números a medida que pasamos tiempo optimizando MultiChain 2.0 durante su fase beta.

Cuando se usan datos fuera de cadena en lugar de datos en cadena, los desarrolladores de aplicaciones MultiChain tienen que hacer exactamente dos cosas:

Al publicar datos, pase un indicador de "fuera de cadena" a las API apropiadas.
Cuando utilice las API de consulta de flujo, considere la posibilidad de que algunos datos fuera de la cadena aún no estén disponibles, según lo informado por el indicador "disponible". Si bien esta situación será rara en circunstancias normales, es importante que los desarrolladores de aplicaciones la manejen adecuadamente.

Por supuesto, para evitar que cada nodo recupere todos los elementos fuera de la cadena, los elementos deben agruparse en flujos de manera apropiada, con cada nodo suscrito a esos flujos de interés.

Los elementos dentro y fuera de la cadena se pueden utilizar dentro de la misma secuencia, y las diversas funciones de consulta y resumen de la secuencia se relacionan con ambos tipos de datos de manera idéntica. Esto permite a los editores tomar la decisión adecuada para cada elemento de una secuencia, sin afectar el resto de una aplicación. Por ejemplo, un flujo de elementos JSON sobre las actividades de las personas podría usar datos fuera de la cadena para identificar información personal y datos en cadena para el resto. Los suscriptores pueden usar la fusión JSON de MultiChain para combinar ambos tipos de información en un solo JSON para leer.

Si desea probar los elementos de la transmisión fuera de la cadena, simplemente siga las instrucciones regulares de MultiChain Cómo Empezar tutorial y asegúrese de no omitir la sección 5.

¿Qué es lo siguiente?

Con un soporte perfecto para los datos fuera de la cadena, MultiChain 2.0 ofrecerá un gran paso adelante para las aplicaciones de blockchain centradas en la marca de tiempo y la notarización de datos a gran escala. A largo plazo, ya estamos pensando en un montón de posibles mejoras futuras de esta función para las ediciones Community y / o Enterprise de MultiChain:

Implementación de flujo leer permisos utilizando una combinación de elementos fuera de la cadena, hashes salados, consultas fragmentadas firmadas y entrega cifrada.
Permitir que los datos fuera de la cadena sean explícitamente "olvidados", tanto voluntariamente por nodos individuales, como por todos los nodos en respuesta a un mensaje en cadena.
Suscripciones de flujo selectivo, en el que los nodos solo recuperan los datos de los elementos fuera de la cadena con publicadores o claves particulares.
Usar Merkle árboles para permitir que un solo hash dentro de la cadena represente un número ilimitado de elementos fuera de la cadena, dando otro gran salto en términos de escalabilidad.
Motores de almacenamiento conectables, que permiten mantener los datos fuera de la cadena en bases de datos o sistemas de archivos externos en lugar de en el disco local.
Nodos de aprendizaje a lo largo del tiempo donde cada tipo de datos fuera de la cadena generalmente está disponible en una red, y enfoca sus consultas de manera adecuada.

Nos encantaría escucha tus comentarios en la lista anterior, así como artículos fuera de la cadena en general. Con MultiChain 2.0 aún oficialmente en alfa, hay mucho tiempo para mejorar esta función antes de su lanzamiento final.

Mientras tanto, ya hemos comenzado a trabajar en "Filtros inteligentes", la última característica importante planificada para MultiChain 2.0 Community. Un filtro inteligente es un código incrustado en la cadena de bloques que implementa reglas personalizadas para validar datos o transacciones. Los filtros inteligentes tienen algunas similitudes con los "contratos inteligentes" y pueden hacer muchas de las mismas cosas, pero tienen diferencias clave en términos de seguridad y rendimiento. Esperamos contarle más a su debido tiempo.

Por favor publique cualquier comentario en Linkedin.

Detalles técnicos

Si bien los elementos de transmisión fuera de la cadena en MultiChain 2.0 son fáciles de usar, contienen muchas decisiones de diseño y características adicionales que pueden ser de interés. La lista a continuación será principalmente relevante para los desarrolladores que crean aplicaciones blockchain, y se puede omitir por tipos menos técnicos:

Políticas por flujo. Cuando se crea una secuencia MultiChain, opcionalmente se puede restringir para permitir solo datos dentro o fuera de la cadena. Hay varias razones posibles para hacerlo, en lugar de permitir que cada editor decida por sí mismo. Por ejemplo, los artículos en cadena ofrecen una garantía de disponibilidad irresistible, mientras que los artículos viejos fuera de cadena pueden volverse irrecuperables si su editor y otros suscriptores abandonan la red. Por otro lado, los artículos en cadena no se pueden "olvidar" sin modificar la cadena de bloques, mientras que los artículos fuera de cadena son más flexibles. Esto puede ser importante en términos de reglas de privacidad de datos, como las nuevas regulaciones GDPR de Europa.
Metadatos en cadena. Para los artículos fuera de la cadena, la transacción dentro de la cadena todavía contiene el editor (es) del artículo, la (s) clave (s), el formato (JSON, texto o binario) y el tamaño total. Todo esto ocupa muy poco espacio y ayuda a los desarrolladores de aplicaciones a determinar si la falta de disponibilidad de un elemento fuera de la cadena es motivo de preocupación para una consulta de flujo en particular.
Límite de dos saltos. Cuando se transmiten consultas fragmentarias a través de la red punto a punto, existe una compensación entre la accesibilidad y el rendimiento. Si bien sería bueno que cada consulta se propague a lo largo de cada ruta, esto puede obstruir la red con "charlas" innecesarias. Por lo tanto, por ahora las consultas fragmentarias se limitan a dos saltos, lo que significa que un nodo puede recuperar datos fuera de la cadena de cualquier par de sus pares. En las redes más pequeñas de menos de 1000 nodos que tienden a caracterizar blockchains empresariales, creemos que esto funcionará bien, pero es fácil para nosotros ajustar esta restricción (u ofrecerla como parámetro) si resulta que estamos equivocados.
Almacenamiento local. Cada nodo MultiChain almacena datos fuera de la cadena dentro del directorio "fragmentos" de su directorio regular de blockchain, utilizando un formato binario eficiente e índice LevelDB. Se utiliza un subdirectorio separado para los elementos en cada una de las secuencias suscritas, así como para los publicados por el propio nodo. Dentro de cada uno de estos subdirectorios, los fragmentos duplicados (con el mismo hash) solo se almacenan una vez. Cuando un nodo se da de baja de una secuencia, puede elegir si desea o no purgar los datos fuera de la cadena recuperados para esa secuencia.
Caché binario. Al publicar grandes piezas de datos binarios, ya sea en cadena o fuera de cadena, puede que no sea práctico para los desarrolladores de aplicaciones enviar esos datos a la API de MultiChain en una sola solicitud JSON-RPC. Por lo tanto, MultiChain 2.0 implementa una memoria caché binaria, que permite que grandes cantidades de datos se acumulen en múltiples llamadas API, y luego se publiquen en un breve paso final. Cada elemento en el caché binario se almacena como un archivo simple en el subdirectorio "caché" del directorio blockchain, lo que permite que los gigabytes de datos también se envíen directamente a través del sistema de archivos.
API de monitoreo. MultiChain 2.0 alpha 3 agrega dos nuevas API para monitorear la recuperación asincrónica de datos fuera de la cadena. La primera API describe el estado actual de la cola y muestra cuántos fragmentos (y cuántos datos) están esperando o siendo consultados o recuperados. La segunda API proporciona estadísticas agregadas para todas las consultas y solicitudes de fragmentos enviadas desde que se inició el nodo, incluidos los recuentos de diferentes tipos de fallas.
Vaciar al publicar. Al publicar un elemento fuera de la cadena, MultiChain se asegura de que su copia local de los datos esté completamente escrita (o "vaciada") en la unidad de disco físico antes de que la transacción haga referencia a que los datos se transmiten a la red. De lo contrario, si el nodo tuvo la mala suerte de perder energía inmediatamente después de transmitir la transacción, los datos fuera de la cadena podrían perderse permanentemente. Esto no es un problema para MultiChain en sí, ya que los retrasos entre los intentos de recuperación de un fragmento crecen automáticamente con el tiempo. Pero podría causar problemas a nivel de aplicación, donde todos saben de la existencia de algunos datos pero nadie puede encontrarlos.
Rendimiento editorial. Al vaciar los datos fuera de la cadena al disco de esta manera, MultiChain puede incurrir en una penalización de rendimiento, ya que los discos físicos son lentos. Por ejemplo, un disco duro de rango medio de 7200 rpm solo puede realizar alrededor de 100 escrituras aleatorias de datos por segundo, limitando a su vez la velocidad a la que un nodo individual puede publicar elementos fuera de la cadena. Hay tres soluciones posibles para este problema. Primero y más simple, los nodos pueden usar una unidad de dispositivo de estado sólido (SSD) en lugar de un disco duro normal, que admite 10,000 operaciones de escritura aleatoria por segundo. En segundo lugar, se pueden publicar múltiples elementos fuera de la cadena en una sola transacción utilizando la API "createrawsendfrom". En este caso, MultiChain escribe todos los datos fuera de la cadena a los que hace referencia una transacción en una sola operación de disco. Finalmente, MultiChain se puede configurar para que no elimine los datos fuera de la cadena al disco antes de transmitir la transacción que hace referencia a ella. Usa esta opción con cuidado.
Integración de moneda nativa. Para casos de uso que lo requieran, MultiChain siempre ha ofrecido la opción de usar una moneda nativa en una cadena de bloques para evitar el spam de transacciones y / o incentivar validadores de bloque ("mineros"). En estos casos, las transacciones deben ofrecer a los mineros una tarifa mínima que sea proporcional a su tamaño en bytes, para ser retransmitidos y confirmados en la cadena. Este mecanismo se ha extendido para permitir que se evite el correo no deseado fuera de la cadena, al requerir una tarifa adicional mínima por kilobyte de datos fuera de la cadena a los que se hace referencia en una transacción.
Archivar nodos. Si un nodo desea suscribirse a cada flujo y, por lo tanto, recuperar y almacenar todos los elementos publicados fuera de la cadena, puede configurarse para hacerlo utilizando el parámetro de tiempo de ejecución "autosubscribe". Cualquiera de estos nodos actuará como respaldo para toda la red, garantizando que los elementos fuera de la cadena no se perderán ni estarán disponibles, sin importar qué otros nodos desaparezcan. Uno puede imaginarse que compañías externas ofrecen esto como un servicio comercial.