Plataforma blockchain R-chain: arquitectura general y evolución

Hola a quienes están siguiendo el desarrollo del uso de plataformas descentralizadas en procesos corporativos e interempresariales. Nuestras publicaciones sobre este tema se interrumpieron a principios de 2018. No, Raiffeisenbank no ha dejado de trabajar en esta dirección: ha llegado el momento de pasar de los cálculos metodológicos y la familiarización con las capacidades de las tecnologías individuales a la implementación de casos de negocio específicos en un entorno industrial o lo más cercano posible a él. Este artículo es bastante voluminoso e informativo al mismo tiempo. Por ello, esperamos su implicación y advertimos sobre el formato tutorial.











En 2016-2017, completamos una serie de proyectos de investigación para construir una plataforma de financiación comercial descentralizada. Se utilizó la prueba Ethereum (Rinkeby) como la plataforma de contabilidad distribuida subyacente y Ethereum Swarm como una herramienta descentralizada para compartir archivos. Además de los problemas generales de la construcción de una plataforma descentralizada, probamos las posibilidades de los contratos inteligentes, el uso de oráculos y los contratos inteligentes de arbitraje. Algunos de estos resultados son





Basado en estos proyectos de investigación,





El resultado de este trabajo bastante largo fue, como dicen los militares, la "aceptación para el suministro" de IT Raiffeisenbank de la plataforma R-Chain descentralizada regular. Ahora se ofrece como un elemento de servicio al cliente para grupos corporativos de varios tamaños.



Compartimos las características principales de la construcción de esta plataforma, y ​​también hablamos sobre la evolución del uso de varios componentes "técnicos" en ella: plataformas blockchain y sistemas de archivos distribuidos.

Contenido

• Características de los sistemas corporativos e interempresariales
• Arquitectura de plataforma general
  
  
  • Arquitectura de componentes de software
  • Proceso empresarial integral
  • Beneficios de utilizar un proceso empresarial integral
  • Desventajas de utilizar un proceso empresarial genérico
  • Supervisión de la red del host
• Evolución del uso de varios componentes técnicos
• Experiencia en investigación y operación de plataformas corporativas y su posterior desarrollo.

Características de los sistemas corporativos e interempresariales

Para que la implementación de la plataforma en operación industrial se desarrolle de manera fluida y sin excesos inesperados para los desarrolladores, es necesario entender que la plataforma propuesta al futuro participante debe cumplir con los siguientes requisitos:

• La plataforma debe tener un operador , una entidad legal que sea responsable ante los participantes de su funcionamiento. La opción: cada uno por sí mismo, todo se decidirá por consenso de los participantes, y así sucesivamente, típico de las plataformas públicas de blockchain, no funcionará aquí.
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

Muchos en esta lista se sorprenderán al descubrir que faltan las palabras "transacciones por segundo" y otras calificaciones de desempeño. Nuestra experiencia muestra que la productividad no es la condición más importante para una implementación exitosa de la plataforma. El rendimiento simplemente tiene que ser "suficiente", y hay muchas arquitecturas de flujo de datos que pueden aumentar drásticamente el rendimiento de la plataforma subyacente, desde los registros de datos hasta los turbo streams laterales. La probabilidad de que su proyecto muera debido a la falta de atención a los puntos anteriores es hiperbólicamente más alta.

Arquitectura de plataforma general

Arquitectura de componentes de software

Las aplicaciones que utilizamos en nuestros proyectos de investigación en 2016-2017 se escribieron sobre la base de la integración directa de interfaces de diálogo con los componentes "técnicos" de la plataforma distribuida: geth y swarm. Pero, tras analizar las posibilidades y consecuencias de este enfoque, llegamos a la conclusión de que es necesario introducir otra capa entre el backend empresarial y los componentes "técnicos": un adaptador de objetos empresariales unificados. Esta técnica pertenece a patrones bastante estándar para la construcción de arquitectura de software, lo que, sin embargo, no reduce su efectividad. Como resultado, la arquitectura de software del nodo de nuestra plataforma comenzó a verse así:







En esta arquitectura, la aplicación empresarialno funciona directamente con abstracciones de componentes DLT, sino con un cierto "proceso de negocio universal" condicional (en lo sucesivo denominado proceso): crea un proceso, cambia el estado del proceso. La reducción de la estructura de datos del proceso universal y las operaciones sobre él a los datos y operaciones utilizados en el cliente DLT se lleva a cabo mediante un conjunto de componentes designados como "Espejo de procesos comerciales". El "espejo" también realiza la transformación inversa de la información recibida del cliente DLT y también filtra la información por procesos que no están relacionados con el participante, el propietario del nodo. Así, en cada nodo se mantiene en estado síncrono una base de datos de procesos de negocio en los que participa este nodo, y en el formato más conveniente para una aplicación empresarial . Aplicación de negociosinteractúa con esta base de datos, una base de datos de procesos comerciales, que recibe información sobre el estado de los procesos y transfiere operaciones para cambiar estos estados.

Proceso empresarial integral

Naturalmente, surgió la pregunta, qué propiedades deben estar dotadas de un proceso empresarial universal para que garantice, por un lado, el máximo aprovechamiento de las ventajas de las plataformas blockchain, y por otro, la máxima flexibilidad y funcionalidad para su uso en una Aplicación Empresarial. Una condición adicional fue la capacidad de implementar las propiedades seleccionadas en la mayoría de las plataformas DLT comunes, cuya funcionalidad es significativamente diferente en algunos aspectos (Ethereum / Quorum / Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Basándonos en la experiencia de proyectos propios y ajenos, llegamos a las siguientes conclusiones.



Un proceso empresarial universal debe tener los siguientes atributos:

• Parámetros del proceso (tipo de proceso, estado, atributos de contexto del proceso)
• Lista de roles de los participantes del proceso
• Lista de documentos electrónicos relacionados con el proceso
• Mapa de transición de procesos

Al mismo tiempo, la plataforma debe, a nivel de componente blockchain, proporcionar las siguientes condiciones para la propagación del proceso en la red:

• Completitud e integridad de la información
• Confidencialidad de documentos electrónicos fuera del círculo de participantes en el proceso
• Control de seguimiento del mapa de transición del proceso
• Almacenamiento del historial de cambios en los estados del proceso

Para implementar estas capacidades, se han desarrollado contratos inteligentes "marco" con los correspondientes conjuntos de propiedades y métodos.



Detengámonos en algunos de los atributos y condiciones enumerados: qué, cómo y por qué.



Parámetros de proceso- son condicionalmente abiertos, ya que se transmiten directamente a través de un contrato inteligente. Para algunas plataformas de blockchain, son fundamentalmente públicas (Ethereum / Masterchain), para otras pueden cerrarse mediante medios estándar para garantizar la privacidad de los datos (Quorum - contratos inteligentes privados, Hyperledger Fabric - canales y datos privados). Probablemente, el más importante de los parámetros del "núcleo" del proceso en nuestra implementación es el "tipo de proceso", ya que lleva no solo carga semántica, sino también funcional - dependiendo del "tipo de proceso", el adaptador DLT elige una plantilla de contrato inteligente que este proceso será presentarte. ¿Por qué es necesario? Obviamente, existen innumerables tipos de transacciones y los mismos procesos comerciales diversos que aseguran su implementación.En un número bastante grande de casos, los procesos comerciales esencialmente difieren solo en el mapa de transición (desde el punto de vista de la plataforma) y se pueden implementar con un solo contrato inteligente que admita un mapa de transición arbitrario (más sobre eso a continuación). Pero momentos bastante únicos pueden asociarse con un proceso empresarial específico:

• (, )
• (, )
• (, )

Intentar formalizar, "formatear" y agrupar toda esta diversidad potencial en una única plantilla de contratos inteligentes es absolutamente utópico. El desarrollo de una plantilla única para un tipo específico de proceso empresarial es una forma mucho más eficiente, que proporciona una alta flexibilidad y la capacidad de "flashear" los elementos necesarios del proceso y verificaciones críticas directamente en el "núcleo" del componente blockchain. Esto excluirá cualquier posibilidad de manipulación por parte de participantes individuales. Además, la plataforma en su conjunto combinará la unificación de interfaces para la interacción de aplicaciones comerciales con procesos y alta modularidad de la implementación de su funcionalidad específica.



Los "atributos del kernel" de nuestro proceso también incluyen "estado" y "nota": el primero es una breve descripción del estado del proceso ("Nuevo", "Cancelado", "Cerrado", "Con aprobación"), el segundo es una cadena "larga" con una descripción más detallada del "estado". Limitamos la longitud de una nota a alrededor de 1000 caracteres (por ejemplo, "Fondos insuficientes en la cuenta"), ya que los documentos electrónicos adjuntos al proceso están destinados a transferir cantidades importantes de información (especialmente confidencial).



Mapa de transición de procesos- describe si un participante con un rol específico puede cambiar el estado del proceso y a cuál. El control sobre la admisibilidad de las transiciones lo realiza el "núcleo" del componente blockchain y no puede ser forjado por un participante "impotente". Además, el mapa de navegación puede ser utilizado, por ejemplo, por una aplicación empresarial para determinar las posibles acciones del propietario del nodo en el estado actual del proceso para la gestión adecuada de los componentes del diálogo.



Transferencia de datos confidenciales.Para transferir información confidencial se utilizan documentos electrónicos que se adjuntan al proceso. La aplicación comercial carga los documentos necesarios en el almacenamiento de archivos local "Mirrors" y los indica en la operación para cambiar el estado del proceso. Antes de transferir del almacenamiento local a DFS, el documento se cifra con las claves públicas de los nodos destinatarios, los participantes en el proceso. Una vez que el contenedor de cifrado formado de esta manera se transfiere a DFS, el enlace y el hash del documento original se transfieren al contrato inteligente del proceso. Al recibir información sobre un cambio en el estado del proceso, los detalles del archivo se recuperan en la base de datos del proceso empresarial y luego el contenedor criptográfico se extrae del DFS mediante el enlace y se descifra con la clave del nodo receptor. Se realiza una verificación para garantizar que el hash del documento especificado en el contrato inteligente del proceso coincida,el documento se coloca en el almacenamiento de archivos local y está disponible para la aplicación empresarial. Por lo tanto, la aplicación empresarial solo funciona con la versión "abierta" del documento: el "Mirror" se hace cargo de todas las preocupaciones sobre su transferencia segura.



El historial del cambio de estado del proceso es una secuencia de "cuadros", cada uno de los cuales corresponde a una operación del cambio de estado del proceso. En nuestra implementación, almacenamos los siguientes datos para cada "marco" del historial:

• estado
• Nota
• el identificador del iniciador de la transacción de cambio de estado

El historial de cambios se registra en el nivel del contrato inteligente y permite no solo rastrear la secuencia de transiciones para fines de auditoría, sino que también permite que la aplicación comercial procese correctamente la cadena de eventos, incluso en el caso de su llegada única (por ejemplo, congelación, interrupción en el funcionamiento, etc.).



Asegurar la importancia legal- un tema muy importante, señalado por nosotros en la sección "Características de los sistemas corporativos e interempresariales". Inicialmente partimos del concepto de que la importancia legal no debe proporcionarse por medio de una plataforma blockchain, sino mediante el uso de una PKI externa que tenga soporte regulatorio o un nivel adecuado de confianza entre los participantes de la plataforma. En términos generales, un documento electrónico que proporcione una base legal para sus acciones (documento de pago, contrato, demanda, etc.) y adjunto al proceso debe estar firmado sobre la base de una PKI "kosher" (en Rusia, GOST, en algún lugar del extranjero, por ejemplo, SSL o PGP / GPG). La aplicación comercial verificará la firma "externa" y tomará la acción apropiada. O no, según el resultado. Alguien diráque esto no es "evangélico" y "tenemos que convencer a los abogados del significado legal de las transacciones de blockchain". Pasamos por muchos pasos de este viaje y el resultado siempre fue el mismo. Sin embargo, en el caso de RusiaLa certificación Masterchain abre ciertas oportunidades en este sentido, como dicen, "¡Feliz caza!"

Beneficios de utilizar un proceso empresarial integral

¿Qué nos dio este enfoque al final?

• Ampliar el círculo de potenciales desarrolladores de aplicaciones empresariales descentralizadas. «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

Aquí, probablemente, como se canta en una canción famosa - "Detrás de ellos se puede escuchar un murmullo ..." - por ejemplo, que el código de cadena Hyperledger Fabric o Corda, a diferencia de Solidity, un poco demasiado elegante, le permite implementar una lógica de procesos comerciales casi infinitamente compleja, y este enfoque profana su funcionalidad. Bueno, sí, tendrán toda la razón. A los murmuradores, les recordaré algunos mensajes bien conocidos del campo de la ingeniería de software:

• ¿Dónde colocar la lógica empresarial, en los procedimientos almacenados de la base de datos o en el código de las aplicaciones empresariales?
• ¿Qué es mejor, una computadora central o una computadora especial?
• ¿Está seguro de que la línea de base que elija mantendrá la compatibilidad durante las actualizaciones futuras? ¿Y en general sobrevivirá los próximos 2 años?

La respuesta es bastante simple si:

• Tienes mucho dinero, tiempo y especialistas en blockchain gratis
• Estás seguro de que la base de blockchain que has elegido no tendrá que cambiarse de la palabra "nunca".
• Realmente necesita "exprimir" las capacidades de la plataforma en un 101%

Bueno, entonces - una calculadora especial ... en el sentido de Hyperledger Fabric o Corda con costuras en el cheyncode y otros "cincelados en piedra". Si no, piensa por ti mismo ...

Supervisión de la red del host

Quizás para algunos sea una revelación, pero el monitoreo bien organizado es la base para el funcionamiento exitoso de los sistemas de software en una empresa. Y este concepto incluye no solo (e incluso no tanto) el monitoreo de la infraestructura estándar de los servidores, sino el monitoreo funcional de los componentes del software. Su plataforma distribuida no solo debe funcionar correctamente, sino que también debe cometer errores correctamente, proporcionando al servicio de soporte una cantidad suficiente de información sana que le permitirá identificar, identificar y corregir una falla rápidamente. Es incluso mejor si el sistema de monitoreo tiene capacidades proactivas: le permite identificar posibles "cosas malas" y bloquea sus posibles consecuencias antes de que "sucedan".



Si en todo momento no comprende en qué estado se encuentran los nodos de su red y qué está sucediendo en ellos, pero van a funcionar "de acuerdo con las señales de los usuarios", es mejor liberar inmediatamente espacio en la cola y no tomarse el tiempo de los estimados clientes.



En base a lo anterior, desde el inicio del desarrollo de nuestra plataforma, se incorporó un sistema de monitoreo proactivo. Describamos el principio de su funcionamiento:

• En la base blockchain de la plataforma, se establece un contrato inteligente especial que se encarga de recopilar y distribuir los datos de seguimiento (por brevedad, nos referiremos a este contrato inteligente como SCM)
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  > pista de auditoría de aplicaciones comerciales

A un cierto valor o combinación de valores para los indicadores de monitoreo, Mirror pausa automáticamente el procesamiento de sus colas de operaciones, bloquea la aparición de posibles consecuencias indeseables, por ejemplo:

• En caso de un retraso crítico en la etiqueta de control del canal blockchain, que se interpreta como un nodo que abandona la red blockchain o una interrupción completa de su funcionamiento.
• En caso de un retraso crítico en la etiqueta de control del canal DFS, que se interpreta como la pérdida de un nodo de la red DFS o una interrupción completa de su funcionamiento
• En caso de errores en la cola de operaciones, todas las operaciones posteriores asociadas con este objeto comercial (proceso comercial universal) se bloquean

Se prestó especial atención al manejo de errores de base de datos utilizados por el "Mirror". Esta base de datos se utiliza no solo como una interfaz con aplicaciones comerciales, sino también como una pila de estado para la máquina de estado de las colas de operaciones "Mirror". La experiencia ha demostrado que en presencia de errores específicos al cambiar datos en las tablas de la base de datos, pueden ocurrir operaciones de bucle con reenvío masivo de transacciones y otros placeres. Una vez, debido a un error similar, en dos días “hicimos” un volumen semestral de la cadena en Quorum. Por tanto, si se detecta un error de este tipo, el "Mirror" se apaga por completo y espera una respuesta manual del servicio de soporte.



Los Nodos de Monitoreo Central recuperan información de todos los nodos de la red (incluidos ellos mismos, por cierto) del SCM y la analizan, lo que permite la detección oportuna de condiciones peligrosas o potencialmente peligrosas como, por ejemplo:

• - DFS-
• - DFS-
• -
• «»
• «»

La siguiente imagen muestra un ejemplo del monitor más simple para una de nuestras redes de prueba:







Se desarrollaron e implementaron más esquemas de monitoreo proactivo de "alto nivel", incluidas aplicaciones comerciales, pero aquí llegamos al límite inestable de la propiedad intelectual de clientes específicos.



No ocultemos el hecho de que en algunas de nuestras redes blockchain, el tráfico de monitoreo constituye la inmensa mayoría del tráfico total. En este sentido, incluso se pensó en utilizar un horario flotante para la frecuencia de "inspección de paquetes", más a menudo durante las horas de trabajo y menos durante las horas no laborables. Pero vale la pena. De Verdad.



En general, supervise todo lo que pueda pensar siempre que lo permita el ancho de banda de su red descentralizada. Alabarás a los dioses de la programación más de una o dos veces, bueno, ya los autores de este artículo, por supuesto :)



Porque como dice una de las interpretaciones de la ley de Murphy: "El error generalmente radica en una posición que nadie duda".

Evolución del uso de varios componentes técnicos

Habiendo considerado las condiciones generales para el despliegue y operación de redes corporativas descentralizadas, así como los principios arquitectónicos que usamos para construir la plataforma R-Chain, ahora pasamos a la historia de cómo y por qué sus componentes técnicos individuales evolucionaron en el proceso de implementación de proyectos específicos.



El primero fue el proyecto de emisión de una garantía internacional , en el que nuestros socios eran colegas de Bielorrusia - marzo-diciembre de 2018.



Comenzamos con la configuración Ethereum - Ethereum Swarm - Crypto-Pro (criptografía DLT-DFS), que ha demostrado su eficacia en proyectos de investigación. En lugar de la red de PoA de prueba pública de Ethereum Rinkeby utilizada, se plantearon la red privada de Ethereum PoA y la red privada de Ethereum Swarm. Inicialmente, no hubo problemas técnicos, pero nos encontramos con un problema "criptográfico": uno de los participantes bielorrusos se negó rotundamente a utilizar las herramientas criptográficas que ofrecimos, refiriéndose a la ley local sobre gestión de documentos electrónicos. En ese momento, no era posible encontrar una solución de alta calidad "en el momento", pero había una comprensión firme del difícil e importante papel de la criptografía en el éxito de los proyectos internacionales.



Ya en el proceso de ejecución de transacciones de control en la infraestructura de red real (cada participante implementó un nodo en sus recursos), se identificaron fallas en el trabajo de Ethereum Swarm: las pérdidas de archivos estaban al nivel del 20%. Se ha sugerido que la pérdida se debe a problemas en el cliente Swarm al enviar varios archivos en paralelo. En general, esta suposición se confirmó: experimentalmente, logramos encontrar una pausa entre el envío de archivos individuales a Swarm en 5 segundos. Durante la transición a una configuración de red completamente de combate, que, debido a las peculiaridades de la segmentación de red aplicada en la infraestructura de Raiffeisenbank, requería la creación de un nodo de tránsito Swarm, surgió un problema crítico: Ethereum Swarm permitió que se perdieran hasta el 30% de los archivos al trabajar a través de un nodo de tránsito.La arquitectura “en capas” y el buen sistema de monitoreo hicieron posible llevar a cabo con éxito el problema real de la garantía en el modo de “bombeo manual de gasolina”, pero el destino de Ethereum Swarm estaba sellado. Debe decirse que la capacidad declarada de Ethereum Swarm para trabajar en topologías sin conexión directa de remitente-receptor fue una de las principales razones para elegirlo como base tecnológica para DFS, y su incapacidad para trabajar de manera confiable en este modo creó muchos problemas.y su incapacidad para trabajar de manera confiable en este modo creó muchos problemas.y su incapacidad para trabajar de manera confiable en este modo creó muchos problemas.



Cabe señalar que la red privada basada en Ethereum en este proyecto está satisfecha con su recuperabilidad. El cronograma del proyecto asumió que el cierre de la garantía emitida se realizaría 3 meses después de su emisión, y durante esta pausa, algunos de los participantes pararon sus nodos. Sin embargo, al reiniciar la red sin bailar con panderetas en 1 día, recuperó su integridad y la operación de cierre de garantía se desarrolló sin quejas.



El siguiente proyecto fue la creación de una red intragrupo para el Grupo de Empresas Ascona - septiembre de 2018 - hora actual.



En base a la experiencia del proyecto de garantía internacional, se eligió IPFS (InterPlanetary File System) como base tecnológica para DFS. Funcionó bien para enviar archivos en paralelo y no requirió ajustes de modo especiales. Quizás el único punto débil de IPFS es la imposibilidad (¡especificado!) De trabajar en topologías de "tránsito". Cuando se construyen redes con un gran número de participantes, la implementación por cada uno de ellos de una "estrella completa" de acceso de cada uno a cada uno es, por decirlo suavemente, un problema organizacional. Por otro lado, todos los participantes implementan el acceso entre ellos y los nodos de "soporte" del operador. Por lo tanto, para organizar la distribución fluida de archivos, se implementó el siguiente mecanismo:

• Cuando se adjunta un archivo a un contrato inteligente de un determinado proceso comercial, se genera el evento DeliveryFile que contiene un enlace al archivo
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

Así, el proyecto Ascona se inició en la configuración Ethereum - IPFS - Crypto-Pro.



El uso de Crypto-Pro para cifrar archivos y firmas "externas" de documentos legalmente significativos aseguró la simplicidad de la vinculación legal, así como la ausencia de reclamos de los departamentos de Seguridad de la Información, lo que a su vez tuvo un efecto extremadamente positivo en el momento de obtener las aprobaciones necesarias tanto del banco como partes de las empresas del Grupo de Empresas Ascona. En general, el proyecto se desarrolló en un estado de funcionamiento y, habiendo pasado la etapa piloto, estaba en la línea de meta para pasar a producción y aquí ...



... y aquí en dos proyectos a la vez - condicionalmente "ajenos", pero en los que participamos como expertos, en configuraciones similares capturamos mega-bifurcaciones de miles de bloques, con la pérdida de transacciones de una parte de la red. Un análisis de los registros y las interpretaciones de la comunidad de blockchain llevó a una conclusión decepcionante: el uso de Ethereum PoA (y en algunos casos incluso PoW) en redes compactas con una pequeña cantidad de nodos (y las redes corporativas pertenecen exactamente aquí) tiene un alto riesgo de tales monstruos. Además, en nuestra red de prueba, un misterioso error comenzó a aparecer periódicamente, cuando un nodo se salía de la red y ya no quería sincronizarse con él. Incluso después de reinstalar Ethereum y eliminarlo por completo. En resumen, quedó claro que la cadena alimentaria necesitaba una alternativa a la base blockchain. Y rápido. Muy rapido.



La solución resultó ser Quorum, prácticamente, el hermano de Ethereum. El número de mejoras en el "Mirror" fue mínimo, la aplicación empresarial, por supuesto, no requirió ninguna mejora en absoluto.



Por el momento, la transición a Quorum solo ha traído ventajas:

• El consenso de la balsa utilizado elimina las horquillas
• La ausencia de bloques vacíos reduce el tamaño de la cadena

La ausencia de bifurcaciones nos permite prescindir de una pausa a la espera de la finalización condicional de las transacciones, que antes se requería para no manejar una posible reversión de transacciones, y teníamos hasta 6 ciclos de generación de bloques. Esto, en primer lugar, aumenta naturalmente el rendimiento de la plataforma y, en segundo lugar, elimina problemas muy difíciles que surgen si la bifurcación ha superado la pausa calculada y el estado de los objetos comerciales "reflejados" que toca deja de ser coherente con su estado de blockchain.



La única característica, quizás, desagradable de Quorum es la capacidad de generar un megabloque de varios megabytes de tamaño al reiniciar después de una larga pausa, lo que simplemente atasca el adaptador DLT al intentar descargar su contenido. Pero, estrictamente hablando, la mesa de servicio no debería dormir tanto tiempo.



Como resultado de toda esta evolución dramática, llegamos a la configuración Quorum - IPFS - Crypto-PRO , que ahora usamos en el mercado nacional ruso.



Quizás alguien haga una pregunta lógica: "Bueno, ¿no has oído hablar antes de Quorum o qué?"... Hemos oído hablar de Quorum, Hyperledger Fabric y EOS. El autor de este artículo incluso asistió al primer taller de Corda en ruso en el otoño de 2017. Probablemente, específicamente para una respuesta inteligente a tales preguntas, Hegel inventó su Dialéctica. El pequeño equipo que inició la investigación en 2016 tenía una buena experiencia en el desarrollo de aplicaciones interactivas para Windows, y el Ethereum público (la primera prueba es comprensible) tenía el umbral de entrada más bajo de las plataformas blockchain. Y dado que estábamos interesados ​​en realizar una investigación específicamente sobre el tema de la cadena de bloques, y no en hurgar en diferentes dockers, sin los cuales no es realista lanzar Quorum "para adultos" o Hyperledger Fabric (y no en todas las plataformas virtuales de Windows es posible), entonces la elección era obvio. A medida que los resultados de la investigación comenzaron a atraer la atención de las unidades de negocio del banco y sus socios,se hizo posible expandir el equipo, confiar las botas a los zapateros y las tartas a las tartas, hacerse con servidores Linux, etc. Y, naturalmente, nadie desechó las soluciones desarrolladas mientras mantuvieran su potencial de desarrollo. Dialéctica y Evolución.

Experiencia en investigación y operación de plataformas corporativas y su posterior desarrollo.

El autor de este artículo participó en una cantidad bastante grande de proyectos de blockchain llevados a cabo en Raiffeisenbank, en la Asociación FinTech y en algunos otros lugares, como desarrollador y como experto en plataformas descentralizadas. Algunos de ellos eran puramente proyectos de investigación, algunos terminaron como pilotos, algunos crecieron hasta convertirse en redes industriales bastante grandes de varias docenas de nodos.



¿Cuáles son las principales conclusiones que se pueden extraer de toda esta experiencia?



1. Existe una cierta variedad de plataformas blockchain, que son muy diferentes en sus cualidades de "consumidor":

• "Umbral de entrada" y facilidad de implementación de la red
• banda ancha
• funcionalidad de contratos inteligentes
• opciones de cierre de información
• tiempo y costo de desarrollo

Por tanto, creo que es imposible decir que alguna de las plataformas resultará absolutamente dominante. Cada uno tiene su propio círculo de usuarios y tareas potenciales, donde su uso es más racional y rentable. Esto se aplica a Ethereum, Quorum, Hyperledger Fabric y Corda. Aquí, al igual que con los lenguajes de programación, sólo Vasya y Petya, que conocen un idioma cada uno, discutirán hasta el punto de la estupidez sobre cuál es mejor: "ventajas" o "sapo". Y Semyon Petrovich y Albert Ivanovich, que conocen a una docena de ellos, hablarán en paz, cuando las "ventajas" sean mejores y cuando "sapo".



2. A pesar del hecho de que algunas de las plataformas DLT (por ejemplo, Hyperledger Fabric y Corda) brindan la capacidad de transferir grandes elementos de datos; de hecho, los archivos, muy probablemente, la base de la cadena de bloques con mecanismos de contrato inteligente y la funcionalidad de transferencia de archivos permanecerán separados. Esto se debe a los siguientes puntos:

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

3. Actualmente, existe una escasez crónica de especialistas para los servicios de soporte técnico de las plataformas descentralizadas. Más precisamente, simplemente no existen. Absolutamente. En la mayoría de los proyectos que conozco, la mayor parte del trabajo de soporte técnico la realizan los desarrolladores o ingenieros de investigación que crearon estas plataformas, lo que, por supuesto, no es bueno. Creo que esto se debe a la juventud de la dirección y paulatinamente se está desarrollando el desarrollo de instrucciones técnicas, plantillas de respuesta, esquemas de seguimiento y otros materiales metodológicos necesarios para organizar el trabajo eficiente del servicio de apoyo. Uno de los problemas aquí es la falta de buenos cursos de descripción general en ruso en plataformas blockchain específicas. Todo tiene que pasar de mano en mano. Pero un especialista en soporte en una empresa no es un desarrollador y está enfocado en otros temas: monitoreo,diagnóstico de errores, asegurando la disponibilidad y recuperación de los sistemas después de accidentes (¿crees que no tendrás accidentes? Sí, claro). Y, francamente, la probabilidad de que un proyecto corporativo muera debido a un apoyo deficiente es significativamente mayor que debido a una mala calidad de desarrollo. Por lo tanto, atraer a especialistas de buena calidad con experiencia en el soporte y la operación de sistemas empresariales es un factor importante, si no el más importante, en el hecho de que el proyecto vivirá y se desarrollará durante mucho tiempo, y no se marchitará tan pronto como un par de padres fundadores lo abandonen.Por lo tanto, atraer a especialistas de alta calidad con experiencia en el soporte y la operación de sistemas empresariales es un factor importante, si no el más importante, en el hecho de que el proyecto vivirá y se desarrollará durante mucho tiempo, y no desaparecerá tan pronto como un par de padres fundadores lo abandonen.Por lo tanto, atraer a especialistas de buena calidad con experiencia en el soporte y la operación de sistemas empresariales es un factor importante, si no el más importante, en el hecho de que el proyecto vivirá y se desarrollará durante mucho tiempo, y no se marchitará tan pronto como un par de padres fundadores lo abandonen.



4. Uno de los ámbitos legales más turbios es la formalización de las relaciones entre el operador y los participantes de la red, que se ve agravada por el hecho de que el operador, por un lado, no es el propietario de la red y sus recursos, y por otro lado, está obligado a asegurar su funcionamiento, aunque el esta medida está en conflicto con los intereses de los participantes individuales. El equilibrio entre los derechos y obligaciones del operador, sus "medios de influencia" sobre los participantes de la red, la responsabilidad financiera del operador: todo esto es ahora objeto de disputas muy difíciles. La pregunta más simple:¿Cómo garantizar el reemplazo sincrónico del software crítico por parte de todos los participantes de la red, a pesar de su aparente simplicidad, resulta en discusiones muy acaloradas? La aparición de ejemplos de formalización legal de la posición del operador y participantes de la red basados ​​en la experiencia de plataformas que ya han ingresado a prod acelerará significativamente la introducción de redes descentralizadas como un elemento significativo de las relaciones corporativas e intercorporativas.



Si ha llegado al final, también hay una ventaja: algunas de las preguntas sobre el estado actual y las rutas de desarrollo de las plataformas corporativas descentralizadas se reflejan en el material preparado por el autor de este artículo para uno de los recursos de blockchain (el material está diseñado para una amplia gama de lectores ).