Dónde estamos hoy y hacia dónde vamos mañana

Hoy estamos encantados de lanzar la segunda versión beta de MultiChain 1.0 para Linux, Windows y Mac (por ahora la versión de Mac requiere compilación). Esto concluye el desarrollo planificado de MultiChain 1.0: con la excepción de las correcciones de errores, la versión final de MultiChain 1.0 durante el verano no cambiará.

Este mes también marca dos años desde el primer lanzamiento alfa de MultiChain en junio de 2015. Como con cualquier producto nuevo, no estábamos seguros de cómo reaccionaría el mercado, y sabíamos que solo había una forma de averiguarlo: lanzar un producto mínimo viable, lo que significa una versión inicial que proporciona un valor significativo pero es preliminar por diseño. Afortunadamente, a diferencia de nuestro primer producto CoinSpark, MultiChain recibió una respuesta positiva fuerte e inmediata. Esto fue acompañado por un tsunami de solicitudes de funciones sensibles, muchas de las cuales hemos implementado. Paralelamente al desarrollo del producto, el uso también ha crecido notablemente en todos los sentidos. Por ejemplo, el sitio web de MultiChain recibió menos de 3,000 visitantes en julio de 2015, y ahora aporta diez veces ese número mensual.

Rendimiento de MultiChain

En los últimos dos años hemos invertido mucho esfuerzo en optimizar MultiChain, que se bifurcó de Bitcoin Core, la implementación de referencia para la red pública de bitcoin. A continuación se muestra una comparación del rendimiento de la transacción para una configuración de un solo nodo utilizando cinco versiones del producto:

Promedio de transacciones por segundo, incluidos gastos generales de API y creación, firma, extracción y verificación de transacciones y bloques.
Pruebas realizadas con el ab Herramienta de evaluación comparativa del servidor HTTP que envía dos solicitudes simultáneas a sendtoaddress API.
Especificaciones del servidor: Intel Core i7-4770, 4 núcleos a 3.4 MHz, 32 GB de RAM, Seagate 2 TB 7200 RPM SATA, CentOS 6.4.

Naturalmente, el mayor salto se produjo en alfa 22 cuando transición a una billetera con base de datos. Pero desde ese lanzamiento, casi hemos duplicado la velocidad de MultiChain nuevamente. Esperamos haber demostrado que el límite de 4 transacciones de bitcoin por segundo se debe a sus parámetros de red particulares y no tiene relación con las cadenas de bloques en general.

Por supuesto, la optimización del rendimiento es una tarea interminable, y no hay razón para que MultiChain no pueda alcanzar los 10,000 tx / seg en un Procesador de 16 núcleos con los cambios arquitectónicos apropiados Sin embargo, según las conversaciones con nuestros usuarios y socios, parece que pocos esperan necesitar más de 1,000 tx / seg durante los próximos años. Por lo tanto, estamos reenfocando nuestros esfuerzos de desarrollo en nuevas características, lo que nos lleva muy bien al tema de MultiChain 2.0.

Descripción general de MultiChain 2.0

La versión 2.0 de MultiChain será la primera en venir en dos ediciones: Community (código abierto) y Enterprise (comercial). Me voy a centrar aquí en la edición comunitaria gratuita, ya que solo estamos discutiendo los detalles de MultiChain Enterprise con nuestros socios. En cualquier caso, las ediciones Community y Enterprise serán altamente compatibles, ya que: (a) las aplicaciones creadas en la edición Community se ejecutarán sin modificaciones en MultiChain Enterprise, y (b) ambas ediciones podrán conectarse y realizar transacciones entre sí en la misma cadena

Las tres áreas clave de funcionalidad mejorada en ambas ediciones de MultiChain 2.0 serán:

• Modelo de datos más rico para flujos, incluidos documentos JSON.
• Filtros de transacciones programables personalizados para validación en cadena.
• Actualización perfecta del protocolo y los parámetros de un blockchain.

Pasemos a discutir cada uno de estos en detalle.

Modelo de datos más rico para flujos

Las transmisiones MultiChain se introdujeron en septiembre de 2016 y han demostrado ser extremadamente populares. Como se describe en esta publicación, las transmisiones proporcionan una abstracción simple y natural para el almacenamiento, indexación y recuperación de datos de uso general en una cadena de bloques. Una cadena de bloques MultiChain puede contener cualquier cantidad de transmisiones con nombre, cada una de las cuales puede estar abierta a todos para escritura o puede escribirse solo desde ciertas direcciones.

En MultiChain 1.0, cada elemento de transmisión tiene uno o más publicadores (que lo firman), una clave opcional, una carga útil de datos binarios de hasta 64 MB de tamaño y una marca de tiempo (derivada del bloque en el que está incrustado). Cada nodo puede decidir libremente a qué flujos suscribirse, o puede suscribirse a todos los flujos automáticamente. Si un nodo está suscrito a una secuencia, indexa el contenido de esa secuencia en tiempo real, lo que permite una recuperación eficiente por editor, clave, bloque, marca de tiempo o posición.

MultiChain 2.0 enriquecerá esta funcionalidad de transmisión de varias maneras:

• Artículos JSON. Además de los datos binarios, los elementos de flujo admitirán objetos JSON estructurados, almacenados en la cadena de bloques en un formato de serialización eficiente, como UBJSON. Dado que la API MultiChain ya usa JSON en todo momento, estos objetos JSON se podrán escribir y leer de una manera natural y obvia.
• Llaves múltiples. Los elementos de transmisión admitirán varias claves, lo que permite indexar una sola pieza de datos de múltiples maneras para su recuperación utilizando liststreamkeyitems. Estamos evaluando constantemente cuánta funcionalidad de base de datos se debe incluir en MultiChain, y no esperamos admitir la indexación de los subelementos dentro de los elementos de flujo JSON en la versión 2.0. Permitir varias claves por elemento de transmisión proporciona una solución razonable.
• Escrituras atómicas de múltiples elementos.. MultiChain 1.0 permite que una sola transacción escriba en varias secuencias, pero no escriba varios elementos en la misma secuencia. MultiChain 2.0 eliminará esta restricción.
• Fusión JSON. Cualquier lista ordenada de objetos JSON se puede acoplar o resumir de forma natural para crear un objeto "fusionado". El objeto combinado contiene todas las claves que aparecen en los objetos individuales, donde el valor correspondiente a cada clave se toma del último objeto en el que aparece esa clave. Si lo desea, el objeto combinado es el estado final de una fila de la base de datos, cuyas columnas están definidas por el primer objeto y extendidas o actualizadas por los objetos posteriores. MultiChain 2.0 agregará API para recuperar fácil y rápidamente el objeto combinado para los elementos JSON en una secuencia con una clave o editor en particular.

Estas características se derivan de formas comunes en las que los desarrolladores utilizan actualmente las transmisiones. En otras palabras, estamos observando lo que muchas personas están construyendo sobre MultiChain a nivel de aplicación, y estamos incorporando esa funcionalidad a MultiChain, un patrón que pretendemos seguir aplicando. Ahora que los elementos de transmisión incluirán información de tipo, pueden ampliarse fácilmente en el futuro para admitir otros formatos de datos como XML, HDF5 y MÍMICA-contenido identificado. Sin mencionar las posibilidades de compresión transparente en cadena y encriptación.

MultiChain 2.0 también admitirá objetos JSON para metadatos de transacciones sin procesar (es decir, no elementos de flujo), así como los metadatos para la emisión de activos y los eventos de creación de flujo, en lugar de los pares de clave / valor de solo texto implementados en MultiChain 1.0. los listassets API ofrecerá la fusión de JSON en todos los eventos de emisión de un activo, de modo que los metadatos de cada emisión puedan actualizar efectivamente la descripción final del activo.

Filtros de transacciones personalizados

Hemos pensado mucho sobre cómo agregar reglas programables personalizadas a MultiChain. Si bien el paradigma de "contrato inteligente" de Ethereum es popular, tiene una serie de deficiencias clave para las cadenas de bloques autorizadas de alto rendimiento. Primero, los contratos inteligentes introducen una dependencia global en todo el estado de blockchain, lo que perjudica drásticamente la concurrencia y el rendimiento. En segundo lugar, los contratos inteligentes no pueden evitar que se inserten transacciones incorrectas en una cadena de bloques, sino que solo evitan que esas transacciones actualicen el estado de la base de datos de la cadena de bloques. Si bien a largo plazo esperamos que se ofrezca una máquina virtual compatible con Ethereum como una abstracción de alto nivel dentro de MultiChain, no creemos que sea la solución adecuada para la validación de bajo nivel.

MultiChain 2.0 presentará un paradigma diferente llamado filtros de transacción, que valida las transacciones individuales sin referencia a ningún estado global. Esperamos que los filtros se escriban en Javascript y se ejecuten dentro de un motor de tiempo de ejecución incorporado como v8, que se usa en Google Chrome navegador y el Node.js plataforma. Por supuesto, tendremos que asegurarnos de que el código de filtro se ejecute de manera idéntica en cada nodo de una cadena de bloques, bloqueando cualquier fuentes de no determinismo como leer la hora, usar números aleatorios, acceder a la red o al disco, o realizar operaciones matemáticas que dependen de la arquitectura del servidor host. Crear un entorno de tiempo de ejecución de JavaScript determinista es un desafío, pero (sin revelar demasiado) creemos que será útil para otras características de MultiChain en el futuro.

Los filtros pasarán un objeto JSON que describe una transacción individual, estructurada como la salida de decoderawtransaction pero con campos extra. Por ejemplo, cada entrada de transacción en el JSON incluirá una estructura que describe el resultado de la transacción anterior que gasta, y cada dirección irá acompañada de una lista de permisos que actualmente posee esa dirección. El trabajo de un filtro es devolver un valor booleano que indique si la transacción es aceptable y, de lo contrario, proporcionar un error de texto que explique por qué. La API de MultiChain incluirá comandos para crear filtros, probarlos en transacciones anteriores o nuevas y activarlos sujetos al consenso del administrador.

A diferencia de los contratos inteligentes, si se descubre un error en el código de un filtro, se puede reemplazar fácilmente por una nueva versión. No obstante, como todo el código completo de Turing, los filtros aún corren el riesgo de entrar en un bucle infinito. Este problema se mitigará de dos maneras:

• Los filtros solo pueden ser instalados y activados por los administradores de la cadena, sujeto a consenso. Esto le da a cada administrador la oportunidad de examinar el código de un filtro en profundidad antes de votar para que se active.
• Todos los nodos con buen comportamiento validarán las nuevas transacciones utilizando los filtros activos antes de reenviarlos a sus nodos pares. Como resultado, si una transacción envía un filtro a un bucle infinito, la transacción no debe propagarse más allá del nodo que lo creó.

Esperamos que una aplicación popular para filtros valide los elementos de transmisión. Por ejemplo, un filtro podría garantizar que ciertos campos en los elementos JSON de una secuencia contengan números en un rango específico. En MultiChain 1.0, este tipo de validación debe realizarse a nivel de aplicación, ya sea al escribir elementos de transmisión (si la fuente es confiable) o al leerlos. Por el contrario, MultiChain 2.0 permitirá que estas reglas se integren dentro de la propia cadena de bloques, más bien como verificar restricciones en una base de datos relacional.

MultiChain 2.0 incluirá dos características adicionales para que los filtros sean aún más potentes. Primero, introducirá permisos definidos por el usuario, que existen junto con los ocho permisos definidos por MultiChain. Al igual que con los permisos regulares, estos serán otorgados a direcciones específicas por administradores (y en algunos casos, por usuarios con activate privilegios) e incluidos junto con las direcciones en el objeto JSON pasado a un filtro. Por ejemplo, un filtro podría garantizar que solo las direcciones con un permiso definido por el usuario en particular puedan escribir ciertos tipos de datos en una secuencia o realizar transacciones en un activo en particular por encima de un cierto umbral.

En segundo lugar, MultiChain 2.0 admitirá metadatos personalizados (binarios o JSON) dentro de las salidas de transacciones regulares. Esto permitirá que cualquier salida actúe como una fila general de la base de datos, "propiedad" de la dirección dentro. Los filtros verán cualquier metadato dentro de las salidas gastadas y creadas de una transacción como parte de su descripción JSON. Como resultado, MultiChain se convertirá en un motor de base de datos compartida universal, donde la validez de una transacción está determinada por una función personalizable de las filas que crea y elimina. (Si esto suena un poco abstracto, nos aseguraremos de proporcionar algunos ejemplos concretos).

Actualización de blockchain

Dado que las cadenas de bloques están diseñadas para funcionar durante muchos años, es posible que sus características deban modificarse con el tiempo. La versión actual de MultiChain ya ofrece un cierto grado de flexibilidad, permitiendo cambios en los permisos (incluidos los administradores y mineros por consenso), la creación de nuevos activos y flujos y la incorporación o eliminación de nodos de la red sin inconvenientes. Sin embargo, en MultiChain 1.0 un blockchain básico parámetros, como el tamaño máximo de bloque y el tiempo de confirmación de destino, se fijan cuando se crea la cadena y no se pueden cambiar posteriormente.

MultiChain 2.0 agregará la capacidad de actualizar una cadena de bloques, permitiendo que muchos (pero no todos) sus parámetros se modifiquen mientras la cadena continúa ejecutándose. Al igual que otras operaciones importantes, la actualización de una cadena de bloques requerirá un nivel personalizable de consenso del administrador, donde este nivel en sí mismo es un parámetro que se puede cambiar. Las actualizaciones entrarán en vigencia a partir de un determinado bloque y se aplicarán posteriormente a cada bloque posterior hasta la próxima actualización.

Los parámetros de blockchain que se pueden actualizar incluirán:

• Versión del protocolo. Esto permitirá que una cadena de bloques creada con una versión de MultiChain se actualice para admitir las características en una nueva versión, como elementos de flujo JSON o filtros de transacción. De hecho, la versión del protocolo 10008 introducido en MultiChain 1.0 alpha 29 (y utilizado en la versión beta) ya está preparado para el futuro con soporte indocumentado para este tipo de actualización. Una vez que una cadena de bloques MultiChain 1.0 se actualiza al protocolo 2.0, también obtendrá acceso a los otros cambios de parámetros descritos aquí.
• Escalado de blockchain. Las cadenas de bloques que se vuelven populares pueden superar los valores iniciales establecidos para su tiempo de confirmación objetivo o el tamaño máximo de transacción y bloque. MultiChain 2.0 permitirá aumentar o disminuir estos valores según sea necesario.
• Modelo de permisos. MultiChain 2.0 permitirá la actualización de muchos parámetros relacionados con los permisos y la gobernanza, que incluyen: (a) anyone-can-* parámetros que controlan las formas en que una cadena de bloques está abierta o cerrada, (b) admin-consensus-* parámetros que determinan los niveles de consenso del administrador requeridos para ciertas operaciones, y (c) la mining-diversity parámetro que controla la rigurosidad del algoritmo de consenso round-robin.

Una vez que se implementa esta funcionalidad de actualización, no debería haber ninguna razón por la cual una cadena de bloques creada en MultiChain no pueda ejecutarse durante muchas décadas o más.

Mirando hacia el futuro

Ya hemos comenzado a trabajar en MultiChain 2.0, y esperamos cumplir con esta hoja de ruta. Sin duda, también se incluirán otras mejoras. Al igual que con MultiChain 1.0, tendremos versiones alfa en el camino, para que los desarrolladores puedan usar y aprender nuevas funciones a medida que se implementan (y, por supuesto, informar cualquier problema o deficiencia). Naturalmente, continuaremos manteniendo la versión 1.0 durante este período, reparando los errores que aparezcan.

Me gustaría terminar agradeciendo a nuestro equipo de desarrollo, liderado por el Dr. Michael Rozantsev, por su continua excelencia y arduo trabajo. Vemos MultiChain como un proyecto de ingeniería de software directo, en el que la calidad del código y las pruebas cuentan sobre todo. Es un privilegio trabajar con personas que pueden convertir una visión compleja del producto en un software de trabajo estable con una eficiencia y velocidad tan notables.

Por favor publique cualquier comentario en Linkedin.

Fuente: https://www.multichain.com/blog/2017/06/multichain-1-beta-2-roadmap/