Presentación de las secuencias de MultiChain

Sello de tiempo: 15 de septiembre de 2016 8:56 a.m.
Nodo de origen: 1213525

Para bases de datos de series de tiempo y valores clave inmutables compartidas

Hoy nos enorgullece lanzar la última versión de MultiChain, que implementa un nuevo conjunto de funcionalidades cruciales llamadas “streams”. Los flujos proporcionan una abstracción natural para los casos de uso de blockchain que se centran en la recuperación general de datos, la marca de tiempo y el archivo, en lugar de la transferencia de activos entre los participantes. Las secuencias se pueden utilizar para implementar tres tipos diferentes de bases de datos en una cadena:

  1. Una base de datos de valores clave o un almacén de documentos, al estilo de NoSQL.
  2. Una base de datos de series temporales, que se centra en el orden de las entradas.
  3. Una base de datos basada en la identidad donde las entradas se clasifican según su autor.

Estos pueden considerarse como 'qué', 'cuándo' y 'quién' de una base de datos compartida.

Conceptos básicos de transmisiones

Se puede crear cualquier cantidad de secuencias en una cadena de bloques MultiChain, y cada secuencia actúa como una colección independiente de elementos de solo agregado. Cada elemento en una secuencia tiene las siguientes características:

  • Uno o mas editores que han firmado digitalmente ese artículo.
  • Un opcional clave para conveniente recuperación posterior.
  • Cosas datos, que puede variar desde un pequeño fragmento de texto hasta muchos megabytes de binario sin formato.
  • A fecha y hora, que se toma del encabezado del bloque en el que se confirma el elemento.

Detrás de escena, cada elemento en una secuencia está representado por una transacción de blockchain, pero los desarrolladores pueden leer y escribir secuencias sin tener conocimiento de este mecanismo subyacente. (Los usuarios más avanzados pueden usar transacciones crudas para escribir en múltiples flujos, emitir o transferir activos y / o asignar permisos en una sola transacción atómica).

Las transmisiones se integran con el sistema de permisos de MultiChain de varias maneras. Primero, las transmisiones solo pueden ser creadas por aquellos que tienen permiso para hacerlo, de la misma manera que los activos solo pueden ser emitidos por ciertas direcciones. Cuando se crea una secuencia, está abierta o cerrada. Cualquiera que tenga permiso para enviar una transacción de blockchain puede escribir secuencias abiertas, mientras que las secuencias cerradas están restringidas a una lista modificable de direcciones permitidas. En el último caso, cada secuencia tiene uno o más administradores que pueden cambiar esos permisos de escritura con el tiempo.

Cada cadena de bloques tiene una secuencia 'raíz' opcional, que se define en su parámetros y existe desde el momento en que se crea la cadena. Esto permite que una cadena de bloques se use inmediatamente para almacenar y recuperar datos, sin esperar a que se cree explícitamente una secuencia.

Como yo he discutido previamente, la confidencialidad es el mayor desafío en una gran cantidad de casos de uso de blockchain. Esto se debe a que cada nodo en una cadena de bloques ve una copia completa de todo el contenido de la cadena. Las transmisiones proporcionan una forma natural de admitir datos cifrados en una cadena de bloques, de la siguiente manera:

  1. Los participantes utilizan una secuencia para distribuir sus claves públicas para cualquier esquema de criptografía de clave pública.
  2. Se utiliza una segunda secuencia para publicar datos, donde cada pieza de datos se cifra mediante criptografía simétrica con una clave única.
  3. Un tercer flujo proporciona acceso a datos. Para cada participante que debería ver un dato, se crea una entrada de flujo que contiene la clave secreta de esa información, encriptada usando la clave pública de ese participante.

Esto proporciona una manera eficiente de archivar datos en una cadena de bloques, al tiempo que los hace visibles solo para ciertos participantes.

Recuperando de corrientes

El valor central de las secuencias está en la indexación y recuperación. Cada nodo puede elegir a qué flujos suscribirse, con la cadena de bloques que garantiza que todos los nodos que se suscriban a un flujo en particular verán los mismos elementos dentro. (Un nodo también se puede configurar para suscribirse automáticamente a cada nueva secuencia creada).

Si un nodo está suscrito a una secuencia, la información se puede recuperar de esa secuencia de varias maneras:

  • Recuperando elementos de la secuencia en orden.
  • Recuperando elementos con una clave particular.
  • Recuperar elementos firmados por un editor en particular.
  • Listado de las claves utilizadas en una secuencia, con recuentos de elementos para cada clave.
  • Listado de los editores en una secuencia, con recuentos de elementos.

Como se mencionó al principio, estos métodos de recuperación permiten que las corrientes se utilicen para bases de datos de valores clave, bases de datos de series de tiempo y bases de datos basadas en identidad. Todas las API de recuperación ofrecen comienzo y contar parámetros, lo que permite recuperar subsecciones de listas largas de manera eficiente (como una cláusula LIMIT en SQL). Valores negativos para comienzo permitir que se recuperen los elementos más recientes.

Las transmisiones pueden contener múltiples elementos con la misma clave, y esto naturalmente resuelve la tensión entre la inmutabilidad de blockchain y la necesidad de actualizar una base de datos. A cada 'entrada' efectiva de la base de datos se le debe asignar una clave única en su aplicación, con cada actualización de esa entrada representada por un nuevo elemento de flujo con su clave. Las API de recuperación de flujo de MultiChain se pueden usar para: (a) recuperar la primera o la última versión de una entrada determinada, (b) recuperar el historial de la versión completa de una entrada, (c) recuperar información sobre varias entradas, incluidas la primera y la última versiones de cada uno.

Tenga en cuenta que debido a la arquitectura punto a punto de una cadena de bloques, los elementos en una secuencia pueden llegar a diferentes nodos en diferentes órdenes, y MultiChain permite que los elementos se recuperen antes de que se 'confirmen' en un bloque. Como resultado, todas las API de recuperación ofrecen una opción entre pedido global (el predeterminado) o local. El pedido global garantiza que, una vez que la cadena ha alcanzado un consenso, todos los nodos reciben las mismas respuestas de las mismas llamadas API. El orden local garantiza que, para cualquier nodo en particular, el orden de los elementos de una secuencia nunca cambiará entre llamadas API. Cada aplicación puede hacer la elección adecuada para sus necesidades.

Streams y la hoja de ruta de MultiChain

Con el lanzamiento de las transmisiones, hemos completado el último trabajo importante para MultiChain 1.0, y ahora estamos firmemente en el camino hacia la versión beta. Esperamos pasar los próximos meses ampliando nuestro conjunto de pruebas internas (¡ya es bastante grande!), Terminando los puertos de Windows y Mac, agregando algunas API más útiles, actualizando el Explorer para transmisiones, ajustes de aspectos del mecanismo de consenso, lanzamiento de nuestra demostración web y, en general, limpieza de códigos y mensajes de ayuda. Lo más importante, continuaremos reparando cualquier error tan pronto como sea descubierto, para que nuestros errores no interrumpan su trabajo.

A largo plazo, ¿dónde encajan las transmisiones en la hoja de ruta de MultiChain? Dando un paso atrás, MultiChain ahora ofrece tres áreas de funcionalidad de alto nivel:

  • Permisos para controlar quién puede conectarse, realizar transacciones, crear activos / flujos, extraer / validar y administrar.
  • Activos incluyendo emisión, reemisión, transferencia, intercambio atómico, custodia y destrucción.
  • con API para crear transmisiones, escribir, suscribirse, indexar y recuperar.

Después del lanzamiento de MultiChain 1.0 (y una versión premium), ¿qué sigue en esta lista? Si nos fijamos en el Comando API que se utiliza para crear transmisiones, notará un parámetro aparentemente superfluo, con un valor fijo de stream. Este parámetro permitirá que MultiChain admita otros tipos de entidades de alto nivel en el futuro.

Los posibles valores futuros para el parámetro incluyen evm (por un Ethereum-máquina virtual compatible), sql (para una base de datos de estilo SQL) o incluso wiki (para texto editado en colaboración). Cualquier entidad compartida cuyo estado esté determinado por una serie ordenada de cambios es un candidato potencial. Cada una de esas entidades necesitará: (a) API que proporcionen la abstracción correcta para actualizar su estado, (b) mecanismos apropiados para que los nodos suscritos sigan ese estado y (c) API para recuperar de manera eficiente parte o la totalidad del estado. Estamos a la espera de saber qué otras entidades de alto nivel serían más útiles, para ser implementadas por nosotros o por terceros a través de una arquitectura de complemento.

¿Qué pasa con los contratos inteligentes?

En un sentido general, MultiChain adopta el enfoque en el que datos está incrustado inmutablemente en una cadena de bloques, pero el código para interpretar que los datos están en el nodo o la capa de aplicación. Esto es deliberadamente diferente del paradigma de los "contratos inteligentes", como lo ejemplifica Ethereum, en el que el código está incrustado en la cadena de bloques y se ejecuta en una máquina virtual. En teoría, porque los contratos inteligentes son Turing completo, pueden reproducir el comportamiento de MultiChain o cualquier otra plataforma blockchain. En la práctica, sin embargo, los contratos inteligentes de estilo Ethereum tienen muchas deficiencias dolorosas:

  • Cada nodo tiene que realizar cada cálculo, ya sea de interés o no. Por el contrario, en MultiChain cada nodo decide a qué secuencias suscribirse y puede ignorar los datos contenidos por otros.
  • La máquina virtual utilizada para contratos inteligentes tiene un rendimiento drásticamente peor que el código que se ha compilado de forma nativa para una arquitectura de computadora determinada.
  • El código de contrato inteligente está incorporado de manera inmutable en una cadena, evitando que se agreguen características y se corrijan errores. Esto se demostró con fuerza en el desaparición de The DAO.
  • Transacciones enviadas a un contrato inteligente no se puede actualizar el estado de un blockchain hasta que se conozca su orden final, debido a la naturaleza del cálculo de propósito general Esto conduce a demoras (hasta que se confirma una transacción en un bloque), así como posibles reversiones (en el caso de una bifurcación en la cadena). Por el contrario, MultiChain puede tratar cada tipo de transacción no confirmada de la manera apropiada: (a) los activos entrantes actualizan inmediatamente el saldo no confirmado de un nodo, (b) los elementos de flujo entrantes están disponibles instantáneamente, con su pedido global finalizado posteriormente, (c) cambios de permisos se aplican de inmediato y luego se reproducen en bloques entrantes.

No obstante, como he he dicho antes, ciertamente no descartamos los contratos inteligentes como un paradigma útil para las aplicaciones blockchain, si vemos casos de uso sólidos. Sin embargo, en MultiChain, los contratos inteligentes se implementarían en una capa similar a una secuencia en la parte superior de la cadena de bloques, en lugar del nivel de transacción más bajo. Esto preservará el rendimiento superior de MultiChain para entidades de cadena de bloques más simples como activos y transmisiones, al tiempo que ofrece un cálculo en cadena más lento donde realmente se necesita. Pero hay menos casos de los que podría pensar.

 

Por favor publique cualquier comentario en Linkedin.

 

Anexo técnico

Todos los comandos relacionados con las transmisiones se documentan en su totalidad en el Página de API de MultiChain, pero aquí hay un breve resumen:

  • Crea una transmisión usando create stream or createfrom ... stream
  • Agregar un elemento a una secuencia con publish or publishfrom
  • Recupere una lista de transmisiones usando liststreams
  • Iniciar o detener el seguimiento de una transmisión con subscribe y unsubscribe
  • Recuperar elementos de transmisión usando liststreamitems, liststreamkeyitems y liststreampublisheritems
  • Enumere las claves de transmisión y los editores con liststreamkeys y liststreampublishers
  • Para elementos de flujo grandes, recupere los datos completos utilizando gettxoutdata (consulta: maxshowndata a continuación)
  • Controle los permisos por transmisión con llamadas como grant [address] stream1.write
  • Ver los permisos de una transmisión usando listpermissions stream1.*

Algunas otras notas para desarrolladores relacionadas con las transmisiones:

  • El create El permiso permite que una dirección cree transmisiones.
  • Los permisos relevantes por transmisión son write, admin y activate
  • Nuevo parámetros de blockchain: root-stream-name (dejar en blanco para ninguno), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
  • Nuevo parámetros de tiempo de ejecución: autosubscribe para suscribirse automáticamente a las nuevas secuencias creadas y maxshowndata para limitar la cantidad de datos en las respuestas de la API (ver gettxoutdata encima).
  • El tamaño máximo de los datos de un elemento de flujo está fijado por max-std-op-return-size parámetro blockchain, así como el más pequeño de los maximum-block-size y max-std-tx-size valores menos unos pocos cientos de bytes.
  • Los nodos que usan el formato antiguo de billetera no pueden suscribirse a las transmisiones, y debe ser actualizado.

 

Sello de tiempo:

Mas de Multicain