ES2914340T3 - Procedimiento y sistema para mejora de la confiabilidad entre redes DLT - Google Patents

Procedimiento y sistema para mejora de la confiabilidad entre redes DLT Download PDF

Info

Publication number
ES2914340T3
ES2914340T3 ES19382513T ES19382513T ES2914340T3 ES 2914340 T3 ES2914340 T3 ES 2914340T3 ES 19382513 T ES19382513 T ES 19382513T ES 19382513 T ES19382513 T ES 19382513T ES 2914340 T3 ES2914340 T3 ES 2914340T3
Authority
ES
Spain
Prior art keywords
dlt
network
networks
validation
smart contract
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19382513T
Other languages
English (en)
Inventor
La Rocha Gomez-Arevalillo Alfonso De
Diaz José Nunez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica IoT and Big Data Tech SA
Original Assignee
Telefonica IoT and Big Data Tech SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica IoT and Big Data Tech SA filed Critical Telefonica IoT and Big Data Tech SA
Application granted granted Critical
Publication of ES2914340T3 publication Critical patent/ES2914340T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091—Interfacing with client-server systems or between P2P systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un procedimiento para mejorar el nivel de confiabilidad de una primera red de Tecnología de registro distribuido, DLT, utilizando una o más redes DLT secundarias, donde la primera y la segunda red DLT comprenden varios nodos de computación y son redes DLT independientes conectadas por una o más redes de telecomunicaciones, comprendiendo el procedimiento las siguientes etapas realizadas en la primera red DLT: a) Recibir en la primera red DLT una solicitud de validación de un contrato inteligente, donde para la validación del contrato inteligente se utiliza una determinada política de confiabilidad; b) Calcular un valor hash h(i) que identifique de forma única la ejecución actual del contrato inteligente correspondiente a la política de confiabilidad y su resultado, y almacenar dicho valor hash en una base de datos de la primera red DLT; c) Obtener el valor hash de la ejecución anterior del contrato inteligente h(i-1); d) Transmitir a una o más segundas redes DLT, a través de la una o más redes de telecomunicaciones, una instrucción de validación que incluya h(i) y una prueba de conocimiento cero, siendo prf(i) prf(i) = Proof Pk, hp(i), diff(i) , donde Proof() es una función preestablecida, Pk es una clave de prueba aleatoria preestablecida, diff(i)= h(i)-h(i-1) y hp(i) = hash(h(i) || diff(i)); e) Recibir, a través de la una o más redes de telecomunicaciones, de cada segunda red DLT a la que se haya enviado una instrucción de validación, un resultado de validación, donde el resultado de validación se obtiene en cada segunda red DLT mediante el cálculo: Verify (Vk, hp(i), prf(i)) donde Verify() es una función de verificación preestablecida, Vk es una clave de verificación aleatoria preestablecida, hp(i) = hash(h(i) || diff(i)); y diff(i)= h(i)-h(i-1) donde h(i) es el valor de h(i) recibido de la primera red DLT y h(i-1) es el valor hash almacenado en la segunda red DLT en la ejecución anterior de la validación del contrato inteligente; f) Cancelar la ejecución del contrato inteligente en la primera red DLT, si el número de resultados de validación negativos es superior a un umbral preestablecido.

Description

DESCRIPCIÓN
Procedimiento y sistema para mejora de la confiabilidad entre redes DLT
Campo técnico
La presente invención se refiere a redes inter-operativas DLT (tecnología de registro distribuido, del inglés Distributed Leger Technology) y, más concretamente, a un procedimiento y sistema para aprovechar el nivel de confiabilidad que ofrece una arquitectura DLT con un elevado número de nodos independientes de pequeñas redes DLT independientes y heterogéneas (inter-operativas).
Antecedentes de la invención
Un registro distribuido (también llamado registro compartido o tecnología de registro distribuido, DLT) implica un consenso de datos digitales replicados, compartidos y sincronizados en múltiples nodos. No hay un administrador central ni un almacenamiento de datos centralizado.
La base de datos del registro distribuido se reparte entre varios nodos (dispositivos) en una red entre pares, donde cada uno replica y guarda una copia idéntica del registro (datos) y se actualiza de forma independiente. Cuando se produce una actualización del registro, cada nodo construye la nueva transacción y, a continuación, los nodos votan mediante un algoritmo de consenso qué copia es la correcta. Una vez que se ha determinado el consenso, todos los demás nodos se actualizan con la nueva copia correcta del registro (la seguridad se consigue mediante claves y firmas criptográficas). Los nodos participantes (dispositivos) de un registro distribuido pueden aplicar un protocolo acordado para verificar, almacenar, mantener y modificar los datos almacenados en el registro distribuido. Una forma de diseño de registro distribuido es el sistema cadena de bloques; es decir, puede decirse que la tecnología cadena de bloques es un tipo de DLT.
En la actualidad, uno de los principales problemas de la DLT es la falta de interoperabilidad entre diferentes redes DLT que utilizan distintos protocolos y/o tecnologías subyacentes. Otro problema es el bajo nivel de confiabilidad que ofrecen las redes autorizadas y privadas con un número reducido de nodos en comparación con las redes públicas y semipúblicas con un elevado número de nodos independientes (porque, en general, el nivel de confiabilidad de la DLT aumenta cuanto mayor es el número de nodos participantes implicados).
En realidad, la interoperabilidad es actualmente una de las principales preocupaciones debido a la adopción masiva de la tecnología DLT. Las redes DLT independientes de distinta naturaleza no pueden comunicarse entre sí ni beneficiarse del nivel de confiabilidad de redes más grandes o públicas. En la actualidad hay varios proyectos que exploran posibles soluciones para permitir la comunicación cruzada entre redes DLT independientes, como por ejemplo:
- Soluciones basadas en protocolos: Pretenden realizar la interconexión entre redes DLT de distinta naturaleza traduciendo a bajo nivel los mensajes y transacciones de una red a otra. Así, a través de estos protocolos de interconexión, los nodos de una red A son capaces de escuchar los eventos, la validación de transacciones o el intercambio de tokens en una red independiente B. Estos procedimientos de bajo nivel requieren cambios sobre los protocolos subyacentes de las redes DLT, y esfuerzos ad-hoc para todos y cada uno de los nuevos tipos de redes que necesitan ser interconectados. Además, en algunos casos, se requiere una infraestructura de pasarela dedicada para garantizar el correcto funcionamiento y la traducción de las operaciones entre redes. Un ejemplo de este tipo de protocolos de interoperabilidad entre redes es el Protocolo Interledger (ILP) de Ripple u Oráculos de Corda, que implementan un mecanismo de interconexión de diferentes sistemas de bases de datos financieras para el caso de uso específico de los pagos P2P. Una solución popular en esta familia de protocolos de interoperabilidad para mejorar la confianza de las redes pequeñas es el uso de cadenas laterales. Las cadenas laterales son pequeñas redes DLT de una tecnología específica que ejecutan su propio registro y consenso. Periódicamente, estas redes hacen un resumen de todas las transacciones realizadas en la red en un intervalo de tiempo específico, y registran el resumen criptográfico en el registro de una red principal de la misma tecnología con un mayor número de nodos (y, por tanto, de confiabilidad). Este enfoque permite una trazabilidad completa de las transacciones y los registros de los resúmenes desde las cadenas laterales hasta la red principal.
- Soluciones basadas en el consenso: Construyen una red DLT superpuesta y un algoritmo de consenso entre redes para garantizar la correcta comunicación, la corrección y la traducción de las transacciones entre diferentes redes independientes. Soluciones como Polkadot o Cosmos, en fase de desarrollo, utilizan una infraestructura DLT superpuesta, con nodos de pasarela dedicados y conectados a cada red DLT independiente que se rige por su propio consenso superpuesto. Este tipo de proyectos permiten el intercambio de tokens de distinta naturaleza entre diferentes redes utilizando su consenso e infraestructura de superposición, así como la comunicación entre contratos inteligentes en diferentes redes.
- Soluciones basadas en la API de interoperabilidad: El último enfoque de interoperabilidad seguido por algunos proyectos es el uso de una API de pasarela para gestionar el registro de resúmenes periódicos (es decir, un hash o una instantánea criptográfica de la red en una marca de tiempo específica) en el registro de las redes públicas, u otras redes con un mayor número de nodos. Este enfoque es equivalente al que siguen las cadenas laterales, con la principal diferencia de que en las cadenas laterales la interoperabilidad se aborda a nivel de protocolo, mientras que el uso de las API de interoperabilidad es a nivel de aplicación.
Sin embargo, las propuestas mencionadas implican varios inconvenientes. Por ejemplo, requieren el despliegue de una infraestructura dedicada para la interconexión de las DLT, siendo el nivel de confiabilidad más alto de todo el sistema el dado por la DLT superpuesta y la infraestructura de la pasarela, requiriendo mecanismos técnicos adicionales para aprovechar el alto nivel de confiabilidad de cualquiera de las redes conectadas. Además, si se aplica un enfoque de interconexión basado en protocolos, se requieren despliegues específicos y cambios de bajo nivel en los protocolos, lo que puede dar lugar a limitaciones de rendimiento y funcionalidad y, esto último, no admite la interoperabilidad de redes de distinta naturaleza.
En cuanto al uso de cadenas laterales, este mecanismo permite la trazabilidad completa de las transacciones en cadenas laterales en una red principal con un alto nivel de confiabilidad. Sin embargo, el uso de cadenas laterales obliga a utilizar la misma tecnología subyacente en la cadena lateral y en la red principal, permitiendo únicamente el aprovechamiento de una única red para la mejora de la confianza.
Por último, el uso de la interoperabilidad basada en la API debe considerarse un parche temporal para los proyectos que no requieren un alto nivel de descentralización y trazabilidad de la información entre redes. La API representa un punto centralizado en la red descentralizada de DLT, y cuando la API extrae información de una red a otra, se pierde la trazabilidad entre la red hija y la red madre
Por lo tanto, se necesita una solución de interoperabilidad mejorada para las redes DLT que supere las limitaciones de las soluciones existentes en el estado de la técnica.
Sumario
Los problemas encontrados en las técnicas del estado de la técnica son generalmente resueltos o eludidos, y las ventajas técnicas son generalmente logradas, por las realizaciones divulgadas que proporcionan un procedimiento y un sistema para mejorar el nivel de confiabilidad de las redes DLT inter-operativas. Se propone una arquitectura técnica para aprovechar el nivel de confiabilidad en escenarios con un elevado número de nodos de computación independientes de redes DLT independientes y heterogéneas. Esta arquitectura define todos los módulos técnicos necesarios para implementar una infraestructura descentralizada auto-gestionada que garantice que cada participante (nodo de computación) de una red DLT conectada al sistema propuesto (implementando el procedimiento propuesto) pueda explotar políticas adicionales de validación y consenso en sus transacciones y contratos inteligentes. Mediante el mecanismo propuesto pueden disfrutar de un nivel de confiabilidad equivalente al que tendrían todos los nodos de la red conectada si formaran parte de una única red DLT común. Cuantas más redes DLT y nodos se conecten al sistema, mayor será el nivel potencial de confianza que puede aprovecharse para las transacciones y los contratos inteligentes en cada red.
La arquitectura propuesta por la presente invención permite la implementación de políticas de validación dedicadas para aprovechar el nivel de confiabilidad de cualquiera de las redes conectadas sin necesidad de una infraestructura dedicada y manteniendo las capacidades de interconexión e intercambio de los enfoques mencionados. Además, la presente invención admite la interconexión de cualquier DLT que ofrezca la ejecución de contratos inteligentes sin necesidad de modificar los protocolos P2P o de consenso subyacentes, asegurando el soporte de las funcionalidades subyacentes y el rendimiento de las redes interconectadas. Además, el mecanismo de mejora de la confianza de la presente invención es de grano fino, ya que la confianza se consigue a nivel de contrato inteligente en lugar de a nivel de red, lo que permite que los contratos inteligentes independientes (programas distribuidos) aprovechen su propia política de confiabilidad según sus casos de uso específicos. Por lo tanto, puede decirse que, en la presente invención, el problema de la interconexión de redes DLT se aborda a nivel de contrato inteligente. El procedimiento y el sistema propuestos permiten a diferentes redes DLT aprovechar el nivel de confiabilidad de otras redes. Así, las aplicaciones DLT desplegadas sobre esta arquitectura de redes inter-DLT se abstraen de las plataformas DLT subyacentes reales (del protocolo y la tecnología particulares utilizados por las redes DLT) y son capaces de ejecutar sin problemas contratos inteligentes con una confianza mejorada en comparación con la red DLT subyacente donde se almacenan y despliegan.
Según un primer aspecto, la presente invención propone un procedimiento para mejorar el nivel de confiabilidad de una primera red de Tecnología de Registro Distribuido, DLT, (del inglés Distributed Ledger Technology) utilizando una o más segundas redes DLT, donde la primera y la segunda red DLT comprenden varios nodos de computación electrónicos y son redes DLT independientes conectadas por una o más redes de telecomunicaciones, comprendiendo el procedimiento las siguientes etapas realizadas en la primera red DLT:
a) Recibir en (un nodo de) la primera red DLT una solicitud de validación de un contrato inteligente, donde para la validación del contrato inteligente se utiliza una determinada política de confiabilidad;
b) Calcular (en el nodo) un valor hash h(i) que identifique de forma única la ejecución actual del contrato inteligente correspondiente a la política de confiabilidad y su resultado, y almacenar dicho valor hash en una base de datos de la primera red DLT;
c) Obtención (en el nodo) del valor hash de la ejecución anterior del contrato inteligente h(i-1);
d) Transmitir (por el nodo de la primera red DLT) a (un nodo de cada) una o más segundas redes DLT, a través de la una o más redes de telecomunicaciones, una instrucción de validación que incluya h(i) y una prueba de conocimiento cero, siendo prf(i) prf(i) = Proof(Pk,hp(i),diff(i))donde Prf() es una función preestablecida (cualquier función de prueba conocida de un algoritmo ZkSnark), Pk es una clave de prueba aleatoria preestablecida, diff(i)= h(i)-h(i-1) y hp(i) = hash(h(i) || diff(i)); el nodo de cada segunda red DLT que recibe dicha instrucción de validación suele distribuir la instrucción de validación a todos los nodos de cada segunda red DLT.
e) Recibir (por ejemplo, por el nodo de la primera red DLT) a través de la una o más redes de telecomunicaciones, de cada segunda red DLT a la que se ha enviado una instrucción de validación, un resultado de validación, donde el resultado de validación se obtiene en cada segunda red DLT calculando (en los nodos de cada segunda red DLT) Verify (Vk, hp(i), prf(i)) donde Verify() es una función de verificación preestablecida (cualquier función de verificación conocida de un algoritmo ZkSnark), Vk es una clave de verificación aleatoria preestablecida, hp(i) = hash(h(i) || diff(i)), y diff(i)= h(i)-h(i-1) donde h(i) es el valor de h(i) recibido de la primera red DLT y h(i-1) es el valor hash almacenado en la segunda red DLT en la ejecución anterior de la validación para el contrato inteligente;
f) Cancelar (por ejemplo, por parte del nodo de la primera red DLT) la ejecución del contrato inteligente por parte de la primera red DLT, si el número de resultados de validación negativos (fallidos) recibidos de las segundas redes DLT, es superior a un primer umbral preestablecido. En una realización, dicho primer umbral preestablecido=0, es decir, si algún resultado de validación es negativo, entonces se cancela la ejecución del contrato inteligente en la primera red DLT.
En una realización, h(i) = hash (addr_SC_App,txid,fx(attr),attr,res) donde addr_SC_App es la dirección de la aplicación que implementa el contrato inteligente; txid el ID de la transacción que activó la política de confiabilidad; fx(attr) la función que activó la ejecución de la política de confiabilidad; attr los atributos de la función; y res el resultado de la función.
En una realización, el cálculo de Verify (Vk, hp(i), prf(i)) en la etapa e) se realiza en todos los nodos de computación de cada una o más segundas redes DLT y el resultado de la validación recibido de cada una o más segundas redes DLT en la etapa e) es positivo (exitoso) sólo si el resultado de la función de verificación es positivo (exitoso) en todos los nodos de computación de dicha segunda red DLT o si el resultado de la función de verificación es positivo (exitoso) en un número de nodos de computación de dicha segunda red DLT superior a un segundo umbral preestablecido.
El contrato inteligente a validar es un contrato inteligente puede ser para la modificación de un registro de la red. En una realización, las comunicaciones entre los nodos de la primera red DLT y los nodos de la una o más segundas redes DLT se realizan a través de instancias de gobernanza en cada nodo de las redes DLT, que gestionan la lógica de interconexión entre nodos de computación de diferentes redes DLT, almacenando cada instancia de gobernanza información sobre el resto de las redes DLT.
En una realización, en la etapa d), la instancia de gobernanza de un nodo de computación de la primera red DLT, utilizando la información de red almacenada de la una o más segundas redes DLT, envía la instrucción de validación a una instancia de gobernanza de un nodo de computación de cada una o más segundas redes DLT a través de una primera red de telecomunicaciones.
En una realización, (la instancia de gobernanza de) cada nodo de cada red DLT tiene un registro con las políticas de confiabilidad disponibles en la red DLT y cuando un usuario de la red quiere añadir una nueva política de confiabilidad a una de las redes DLT, (la instancia de gobernanza de) al menos un nodo de dicha red DLT comprueba si el usuario tiene suficientes permisos para añadir una nueva política de confiabilidad y sólo si el usuario tiene permiso, se registra la nueva política de confiabilidad. Esta comprobación suele ser realizada por todos los nodos de la red DLT.
Cada red DLT (en sus instancias de gobernanza) tiene un registro con las redes DLT disponibles para ser utilizadas para aumentar el nivel de confiabilidad, y cuando un usuario de la red solicita añadir una nueva red DLT, (la instancia de gobernanza de) un nodo de computación de la red DLT donde se recibe la solicitud, envía la solicitud al resto de las redes DLT (a los nodos del resto de las redes DLT), los nodos de las redes DLT verifican (ejecutando una determinada lógica de verificación) si la nueva red DLT es aceptada y sólo si al menos un umbral preestablecido de los nodos de las redes DLT aceptan dicha nueva red DLT, la nueva red DLT se registra (en la instancia de gobernanza de) los nodos de computación de las redes DLT como una nueva red DLT que se utilizará para mejorar el nivel de confiabilidad.
Según un segundo aspecto, la presente invención propone un sistema para mejorar el nivel de confiabilidad de una primera red de Tecnología de Registro Distribuido, DLT, utilizando una o más redes DLT secundarias, donde la primera y la segunda red DLT son redes DLT independientes conectadas por una o más redes de telecomunicaciones, comprendiendo el sistema la primera red DLT y una o más redes DLT secundarias, Cada nodo de computación de la primera red DLT comprende un procesador configurado para:
- recibir una solicitud de validación de un contrato inteligente, donde para la validación del contrato inteligente se utiliza una determinada política de confiabilidad (normalmente dicha solicitud se envía al resto de nodos de computación de la primera red DLT);
- calcular un valor hash h(i) que identifique de forma única la ejecución actual del contrato inteligente correspondiente a la política de confiabilidad y su resultado, y almacenar dicho valor hash en una base de datos de la primera red DLT;
- obtener el valor hash de la ejecución anterior del contrato inteligente h(i-1);
- transmitir a un nodo de computación de cada segunda red DLT una instrucción de validación que incluya h(i) y una prueba de conocimiento cero, siendo prf(i) prf(i) = Proof(Pk,hp(i),diff(i))donde Proof() es una función preestablecida, Pk es una clave de prueba aleatoria preestablecida, diff(i)= h(i)-h(i-1) y ip(i) = hash(h(i) || diff(i));
los nodos de computación de la una o más segundas redes DLT que comprenden:
- un procesador configurado para recibir la instrucción de validación de la primera red DLT directamente o a través de otro nodo de computación de la segunda red DLT; determinar un resultado de validación calculando: Verify (Vk, hp(i), prf(i)) donde Verify() es una función de verificación preestablecida, Vk es una clave de verificación aleatoria preestablecida, hp(t) = hash(h(i) || diff(i)), y diff(i)= h(i)-h(i-1) donde h(i) es el valor de h(i) recibido de la primera red DLT y h(i-1) es el valor hash almacenado en el nodo de computación en la ejecución anterior de la validación para el contrato inteligente;
donde la ejecución del contrato inteligente en la primera red DLT se cancela, si el número de resultados de validación negativos recibidos de la una o más segundas redes DLT es superior a un primer umbral preestablecido. El procesador de los nodos de computación de la una o más segundas redes DLT puede estar configurado además para:
- si recibe la instrucción de validación de un nodo de computación de la primera red DLT: distribuir dicha instrucción de validación a todos los nodos de computación de la segunda red DLT; recibir el resultado de la validación de los nodos de computación de la segunda red DLT; determinar un resultado de validación para la segunda red DLT basado en los resultados de validación en todos los nodos de computación de la segunda red DLT y enviar dicho resultado de validación al nodo de computación de la primera red DLT del que ha recibido las instrucciones de validación.
En un último aspecto de la presente invención, se divulga un programa de ordenador que comprende medios de código de programa de ordenador adaptados para realizar las etapas de los procedimientos descritos, cuando dicho programa se ejecuta en medios de procesamiento, siendo dichos medios de procesamiento, por ejemplo, un ordenador, un procesador de señales digitales, una matriz de puertas programables en campo (FPGA), un circuito integrado específico de la aplicación (ASIC), un microprocesador, un microcontrolador o cualquier otra forma de hardware programable. En otras palabras, un programa de ordenador que comprende instrucciones que hacen que un ordenador que ejecuta el programa realice todas las etapas del procedimiento descrito, cuando el programa se ejecuta en un ordenador. También se proporciona un medio de almacenamiento de datos digital para almacenar un programa de ordenador que comprende instrucciones, haciendo que un ordenador que ejecuta el programa realice todas las etapas de los procedimientos descritos cuando el programa se ejecuta en un ordenador.
En consecuencia, según la invención, se proporciona un procedimiento, un sistema y un medio de almacenamiento según las reivindicaciones independientes. Las realizaciones favorables se definen en las reivindicaciones dependientes.
Estos y otros aspectos y ventajas de la invención serán aparentes y se dilucidarán con referencia a las realizaciones descritas a continuación.
Breve descripción de los dibujos
Para completar la descripción que se realiza y con el objeto de ayudar a una mejor comprensión de las características de la invención, de acuerdo con un ejemplo preferido de realización práctica de la misma, se acompaña a dicha descripción como parte integrante de la misma, un juego de dibujos en los que, a título ilustrativo y no limitativo, se ha representado lo siguiente:
La figura 1 muestra un diagrama esquemático de la arquitectura propuesta según una realización de la presente invención.
La figura 2 muestra un diagrama esquemático de las principales operaciones de ejecución de una política de confiabilidad según una realización de la invención.
La figura 3 muestra un diagrama esquemático de las principales operaciones para el despliegue de una nueva política de confiabilidad en una red según una realización de la invención.
La figura 4 muestra un diagrama esquemático de las principales operaciones para añadir una nueva red al sistema de interoperabilidad según una realización de la invención.
Descripción de las realizaciones
Las presentes invenciones pueden plasmarse en otros sistemas y/o procedimientos específicos. Las realizaciones descritas deben considerarse en todos los aspectos como meramente ilustrativas y no restrictivas. En particular, el alcance de la invención se indica en las reivindicaciones adjuntas y no en la descripción y las figuras. Todos los cambios que entran dentro del significado y rango de equivalencia de las reivindicaciones deben ser abarcados dentro de su alcance.
Las realizaciones de la presente invención proporcionan una mejora en el nivel de confiabilidad de las redes DLT independientes y heterogéneas interoperativas. Cada red DLT comprende uno o más (normalmente muchos) nodos (nodos de computación); los nodos de computación son dispositivos electrónicos de cualquier tipo (por ejemplo, servidores) que incluyen capacidad de almacenamiento de bases de datos (memoria) y capacidad de procesamiento (procesador). Más concretamente, las realizaciones propuestas implementan un sistema de interconexión entre redes DLT basado en contratos inteligentes que permite el intercambio de tokens y la comunicación de contratos inteligentes entre diferentes redes independientes. El sistema de interconexión aprovecha a través de políticas de validación de contratos inteligentes basadas en un algoritmo ZKProof el nivel de confiabilidad de otras de las redes DLT interconectadas. Dicho sistema de interconexión propuesto comprende varios módulos técnicos (elementos funcionales) necesarios para implementar una infraestructura descentralizada auto-gestionada que garantice que cada participante (nodo de computación electrónico) de diferentes redes DLT pueda explotar políticas adicionales de validación y consenso en sus contratos inteligentes
La figura 1 representa la arquitectura del sistema de interconexión propuesto según una de las formas de realización de la presente invención, para permitir esta interoperabilidad mejorada de las redes DLT. El sistema permite la interconexión de redes DLT independientes, de distinta naturaleza, siempre que soporten la ejecución de contratos inteligentes. Para establecer las comunicaciones entre las redes se puede utilizar cualquier tecnología de comunicación conocida (por cable o inalámbrica). Cada red puede tener un número diferente de nodos, un algoritmo de consenso independiente, diferentes capacidades y mecanismos de seguridad subyacentes, y puede implementarse sobre diferentes protocolos y tecnologías P2P. Estas redes pueden ser privadas, públicas o autorizadas. Según todas estas características, cada red DLT conectada tendrá un nivel de confiabilidad subyacente diferente. En la realización mostrada en la figura 1, hay 3 redes DLT interconectadas (A, B y C) con nodos P, Q y R, donde Q>P>R (esto es sólo un ejemplo y la presente invención puede aplicarse a cualquier número de redes de cualquier tamaño).
En la realización mostrada en la figura 1, cada red (en realidad cada nodo de la red) implementa los siguientes elementos funcionales (también llamados módulos o instancias) para realizar las diferentes tareas requeridas (en la práctica, dichos elementos funcionales se implementan normalmente como contratos inteligentes, es decir, como programas distribuidos para ser ejecutados en los nodos de computación de la red DLT). Esto es sólo un ejemplo y algunos de los módulos/contratos pueden ser opcionales, es decir, no todos los módulos son obligatorios para la implementación de la presente invención.
En las redes DLT, los contratos inteligentes suelen ejecutarse en cada nodo de la red. Por lo tanto, los módulos (contratos inteligentes) mostrados en la figura 1 se ejecutan en cada nodo de computación de cada red; es decir, los contratos de gobernanza, los contratos de política de confiabilidad y los contratos inteligentes de aplicación que se muestran en la figura 1 (y que se explicarán ahora) se instalarán y ejecutarán preferentemente en cada nodo de computación de cada red. En sentido estricto, los contratos inteligentes suelen ser desplegados por un nodo de la red, y a partir de ahí los contratos inteligentes son distribuidos e instalados en todos los nodos de las redes.
Contrato de gobernanza: El contrato de gobernanza se encarga de gestionar la lógica de gobernanza del sistema de interconexión (es decir, gestiona la lógica de comunicación con las redes externas) y de listar todas las redes conectadas con la correspondiente tecnología DLT utilizada en cada red, los puntos de conexión disponibles (puntos finales, “endpoints”) para cada red externa (o lo que es lo mismo, el contrato de gobernanza de cada nodo de la red almacena el punto de conexión/nodo específico para acceder a cada red externa desde cada nodo de la red actual), el número medio de nodos y consensos que tiene cada red, y su nivel de confiabilidad subyacente (según las características específicas de cada red). Además, el contrato de gobernanza también almacena todas las políticas de confiabilidad disponibles públicamente en una red. Cada red conectada tiene su propia instancia del contrato de gobernanza instalada en cada nodo de la red (es decir, cada nodo tiene su módulo de contrato de gobernanza) implementado en su tecnología de contrato inteligente subyacente. Estas instancias del Contrato de Gobernanza deben estar sincronizadas y ser las mismas en todas las redes conectadas (exceptuando el registro de políticas que puede ser diferente en cada red, ya que cada red puede utilizar diferentes políticas de confiabilidad). Así, el contrato de gobernanza realiza las siguientes tareas (en otras palabras, incluye los siguientes sub-módulos o sub-elementos funcionales):
Lógica de gobernanza: Determina todas las reglas de gobernanza del sistema de interconexión de redes, como qué usuarios pueden conectar nuevas redes al sistema y los procedimientos de validación necesarios, quién puede añadir nuevas políticas de confiabilidad indexables públicamente al Registro de Políticas, las entidades responsables de la actualización de la información en el registro de redes, las políticas de verificación específicas para permitir el despliegue de nuevas políticas de confiabilidad o cualquier otra regla de gobernanza.
Registro de redes: Almacena toda la información de las redes conectadas (A, B y C en el caso de la figura 1) al sistema con la siguiente tupla: (network_id, technology, number_of_nodes, type_of_network, network_trusted_endpoints, Governance_address, trustjevel). Esta tupla almacena la información básica de cada red necesaria para soportar su funcionamiento sobre el sistema de interconexión, como el protocolo de cadena de bloques utilizado, si es una red pública o con permisos, el tipo de consenso que utiliza, etc. En este registro se puede almacenar información adicional sobre las redes en función de las capacidades adicionales que se quieran soportar en implementaciones alternativas del sistema.
Registro de políticas: Enumera todas las políticas de confiabilidad disponibles en una red DLT específica. Estas políticas pueden ser compartidas por diferentes redes, o pueden ser únicas y exclusivas de la red DLT. Para añadir una nueva política, hay que añadir una nueva entrada en el registro de la siguiente manera (trust_policy_id, policy_address, cost, performance_overhead), donde trust_policy_id representa el identificador único utilizado por el contrato de gobernanza y los contratos de aplicación en la red para instanciar la política; policy_address especifica la dirección del contrato inteligente que implementa la lógica de la política de confiabilidad; cost determina el coste específico necesario para ejecutar la política; y performance_overhead el porcentaje de sobrecarga de rendimiento en que incurrirá el contrato inteligente para ejecutar la política de confiabilidad. El registro de políticas de una red DLT específica almacena información no de todas las políticas de confiabilidad disponibles en todas las redes, sino de las políticas de confiabilidad disponibles en la red DLT específica. Para que una política de confiabilidad pueda ser invocada desde una red DLT de origen, se requiere una implementación de la misma en la red de origen pero también en la red de destino (de la que se quiere aprovechar la confianza). Es decir, para que una política de confiabilidad pueda ser invocada desde una primera red DLT a una segunda red DLT, dicha política de confiabilidad debe estar disponible en ambas redes DLT. Contratos de política de confiabilidad: Estos contratos implementan las políticas de confiabilidad específicas que se ejecutarán cuando sean activadas por un contrato inteligente de aplicación. Implementan el algoritmo de validación específico (es decir, el nivel de confiabilidad externo) y la corrección de intercambio de activos que requiere un contrato inteligente de aplicación para aceptar la ejecución y la modificación de datos en el registro sobre el que se despliega el contrato de política de confiabilidad. Cada política de confiabilidad utiliza un algoritmo basado en ZKProof (el Algoritmo de Confianza ZKProof se explicará más adelante) para validar la ejecución de las políticas de confiabilidad externas, y para asegurar que la confianza externa se aprovecha, y los ataques internos de la red pueden ser identificados. Existe una gran gama de políticas de confiabilidad (es decir, de validación) soportadas por diseño por la arquitectura de la invención, como por ejemplo:
Política externa básica: Se puede utilizar cuando se requiere cualquier validación de confianza externa. Esta política de confiabilidad ejecuta el algoritmo de confianza ZKProof con cualquiera de las redes externas existentes (independientemente de su nivel de confiabilidad). Si la validación de la función ZKProof en la red externa es correcta, se permite a la aplicación del contrato inteligente reanudar su ejecución en la red origen, y modificar el estado del ledger.
Política de alta confiabilidad: Puede activarse cuando se requiere un alto nivel de confiabilidad. En este caso, el algoritmo de confianza ZKProof se activa en varias redes, o en la red con un mayor número de nodos en el sistema. El alto nivel de confiabilidad de esta política conlleva mayores costes de ejecución y sobrecarga de rendimiento.
Política de firma específica: Política que se activa cuando se requiere un conjunto de firmas específicas de entidades de redes externas para la correcta ejecución del contrato inteligente de la aplicación.
Alto rendimiento: Política activada cuando se requiere un alto nivel de rendimiento en el contrato inteligente activador. El tiempo de ejecución de los contratos inteligentes puede diferir entre redes en función de varios factores como, por ejemplo, su algoritmo de consenso, nivel de congestión, número de nodos, tecnología subyacente.... Con esta política de alto rendimiento, cuando un contrato inteligente de aplicación no requiere un nivel específico de confiabilidad (es decir, no es obligatorio ejecutar el contrato inteligente en muchas redes o en una red específica), se seleccionan las redes con menor tiempo de ejecución de los contratos inteligentes para aprovechar la confianza, logrando una baja sobrecarga de tiempo. En otras palabras, el algoritmo de confianza ZKProof (que se explicará más adelante) se activa en las redes con una baja sobrecarga de tiempo, independientemente de su nivel de confiabilidad.
Política de muestreo: Utiliza un algoritmo de muestreo (“round-robin”, aleatorio, etc.) para que sólo cada "n" ejecuciones del contrato inteligente se active el Algoritmo de Confianza ZKProof en una red externa. Esta política supondrá un ahorro de costes y una menor sobrecarga de rendimiento.
Política de eventos: Fuerza la activación de un evento a través del contrato inteligente de la política de una red externa, y la ejecución del contrato inteligente de la aplicación no puede reanudarse hasta que este evento se haya producido.
Política aleatoria: Cuando se desea una política de confiabilidad pero no se requiere ninguna específica. Es decir, no se impone ninguna política de confiabilidad específica ni ningún tipo de política de confiabilidad, por lo que se puede elegir cualquier política de confiabilidad disponible.
Estos son ejemplos de posibles políticas de confiabilidad, pero pueden implementarse políticas de confiabilidad adicionales y personalizadas utilizando Contratos de Políticas de Confiabilidad en cualquiera de las redes DLT conectadas según las necesidades específicas de una aplicación debido a la generalidad de los componentes del marco. Los desarrolladores de aplicaciones pueden seleccionar la política de confiabilidad que mejor se adapte a sus necesidades en términos de coste, sobrecarga de rendimiento y nivel de confiabilidad requerido.
Contratos inteligentes de aplicaciones: Implementan la lógica de los contratos inteligentes de las aplicaciones DLT en las redes. Representan la lógica distribuida de las aplicaciones descentralizadas que quieren ser protegidas aprovechando el uso de políticas de confiabilidad para mejorar la confianza (utilizando esta invención propuesta). En otras palabras, dichos contratos inteligentes de aplicaciones no son más que piezas de lógica distribuida implementadas para el funcionamiento de las aplicaciones descentralizadas de los usuarios que quieren mejorar su nivel de confiabilidad. Por lo tanto, los programadores que implementen una aplicación descentralizada utilizando contratos inteligentes sobre redes DLT, implementando la invención propuesta, podrán hacer cumplir sus contratos inteligentes de aplicación con el mecanismo de mejora de la confianza propuesto. La invención propuesta puede verse como un mecanismo (normalmente código de sistema) implementado en una red DLT para permitir que cualquier aplicación descentralizada mejore su nivel de confiabilidad.
Un ejemplo de cómo funcionan estos contratos (qué transacciones se realizan entre los diferentes módulos y redes) se presenta en la Figura 2 (tomando como arquitectura de referencia la de la Figura 1). Para mayor claridad, en las figuras, las transacciones en cada red se muestran como una única transacción; sin embargo, al tratarse de redes DLT, todos los contratos inteligentes suelen ejecutarse en cada nodo de la red por lo que dichas transacciones en cada red suelen realizarse en cada nodo de la misma.
Consideremos un usuario de la red A que quiere verificar la ejecución de un determinado programa inteligente (por ejemplo, modificar un registro de la red). Esto es solicitado (201) por el usuario al módulo de Contrato de Aplicación en la red A (en realidad el usuario lo solicita a un nodo específico de la red A, y a partir de ahí, normalmente el módulo de Contrato de Aplicación se activa y ejecuta en todos los nodos de la red A). En este ejemplo, se utilizará una política de confiabilidad básica identificada con id=1, donde esta política de confiabilidad implica que el contrato inteligente de aplicación de la red A aprovecha el nivel de confiabilidad de la red B y C (es decir, la red A utiliza las redes B y C para mejorar la confianza de la operación). Esto es sólo un ejemplo y se podría utilizar cualquier otra política de confiabilidad. Antes de que el contrato inteligente de la aplicación pueda modificar su registro de la red, se verá obligado a cumplir la política de confiabilidad correspondiente y el algoritmo de confianza ZKProof. Así, el contrato inteligente de aplicación en la red A se comunica (202) con su Contrato de Gobernanza (Gobernanza A) solicitando la ejecución de la política de confiabilidad 1; como se dijo anteriormente esta política de confiabilidad requiere una ejecución exitosa del Algoritmo de Confianza ZKProof en las redes B y C. La Gobernanza A, utilizando su registro de red, entonces solicita estas ejecuciones a los Contratos de Gobernanza en la red B y C (203, 204). Esto se suele hacer en cada nodo de la red A; es decir, cada contrato de Gobernanza de cada nodo de la red A envía un mensaje solicitando la validación a los Contratos de Gobernanza de los nodos de las redes B y C (la información sobre el nodo específico de las redes B y C al que se comunica cada nodo de la red A, será el "network_trusted_endpoints" almacenado en el registro de red del contrato de gobernanza de cada nodo). La comunicación entre las redes A y la red B se realiza a través de una primera red de comunicaciones utilizando cualquier tecnología de comunicación conocida y la comunicación entre las redes A y la red C se realiza a través de una segunda red de comunicaciones (igual o diferente a la primera red de comunicaciones) utilizando cualquier tecnología de comunicación conocida.
La Gobernanza B y la Gobernanza C utilizan su módulo de registro de políticas para obtener la dirección específica del contrato inteligente de la política de confiabilidad 1 y desencadenar su ejecución (ejecutar el Algoritmo de Confianza ZKProof) en sus correspondientes redes (205, 206). Los resultados de dicha ejecución (207, 208) son devueltos a sus módulos de Gobernanza y de ahí, a la Gobernanza A (209, 210), responsable de procesar y comunicar (211) los resultados de la ejecución de la política de confiabilidad al contrato inteligente de la aplicación. Si el resultado es exitoso, el contrato inteligente de aplicación puede modificar el estado mundial de la red, si no, la ejecución del contrato inteligente de aplicación es cancelada.
Normalmente, en una red DLT, el algoritmo de consenso (en su caso el algoritmo basado en ZKProof), y en general cualquier contrato inteligente, es ejecutado por cada nodo de computación de la red, por lo que esta validación es ejecutada por cada nodo. El Algoritmo ZKProof es activado por el contrato inteligente de la aplicación que está siendo ejecutado por cada nodo en la red A. Esto desencadena la ejecución del código de validación (el Algoritmo ZkProof) en las redes B y C, también ejecutado por todos los nodos de estas redes. Esto es una consecuencia del funcionamiento subyacente de las redes DLT basadas en contratos inteligentes, ya que la lógica distribuida es ejecutada por cada nodo de la red.
Es decir, cuando se divulga que una validación (en este caso un Algoritmo de Confianza ZKProof) o un contrato inteligente se ejecuta en una determinada red, normalmente se quiere decir que dicha validación (dicho algoritmo) o contrato inteligente se ejecuta en todos los nodos de la red. Y la validación en una red será exitosa si lo es en todos los nodos de dicha red o en al menos un determinado número de nodos (según el algoritmo de consenso específico de la red objetivo). Resumiendo, preferiblemente todos los nodos de la red objetivo (de la que se quiere aprovechar la confianza) ejecutan el algoritmo de validación, y la validación debe ser correcta (positiva) al menos en el número mínimo de nodos que dicte el algoritmo de consenso de la red.
Como se ha mencionado anteriormente, la solución propuesta también permite el despliegue de políticas de confiabilidad adicionales. El procedimiento de despliegue de políticas de confiabilidad adicionales, según una realización de la invención, se representa en la Figura 3. Un usuario solicita el despliegue de un nuevo contrato inteligente de política de confiabilidad en la red; para ello, se pone en contacto con la Gobernanza (31) de (un nodo de) la red, que despliega el contrato inteligente de política (32) y ejecuta una validación de dicho contrato inteligente de política (33). En realidad, el usuario lo solicita a un nodo específico de la red A, y a partir de ahí, normalmente la validación se activa y se ejecuta en todos los nodos de la red.
Si el despliegue es exitoso, el usuario deberá solicitar su registro público la Gobernanza (34) para que esté disponible públicamente. La Gobernanza verifica en el Módulo Lógico de la Gobernanza si el usuario tiene suficientes permisos para añadir una nueva política; se pueden implementar funciones adicionales de verificación de los contratos inteligentes desplegados para comprobar su corrección, como un número de firmas independientes que aseguren su corrección o cualquier otro procedimiento deseado como se ha avanzado anteriormente (esto se suele hacer en cada nodo de la red). Si el usuario tiene suficientes permisos y la verificación de corrección es exitosa, la Gobernanza (de cada nodo) actualiza el Registro de Políticas con la nueva política (35) e informa al usuario (36). En una realización, el contrato de gobernanza de al menos un nodo informará a las otras redes de la nueva política, para que esté implementada y disponible también en los nodos de dichas redes.
La aceptación de una nueva red conectada al sistema (para interoperar con las otras redes) sigue un procedimiento análogo al de añadir una nueva política de confiabilidad desde arriba. El procedimiento de añadir una nueva red, según una realización de la invención, se representa en la figura 4. Un usuario, o entidad, puede solicitar (401) la interconexión de una red a través de la Gobernanza de (un nodo de) cualquiera de las redes ya interconectadas (la red A en el caso de la figura 4). Esta Gobernanza activará la lógica de verificación de la red (402, 403) en el resto de las redes conectadas (B y C) y normalmente también en la propia red A. La lógica de verificación puede consistir en la recogida de un mínimo de firmas, en la ejecución de lógicas específicas o en cualquier otro procedimiento que se desee (estos procedimientos de validación pueden ser equivalentes a los de las políticas de confiabilidad, pero deben ser implementados en todas las redes ya conectadas). Esta lógica de verificación puede construirse sobre el algoritmo ZKProof que se explicará más adelante (el algoritmo ZkProof garantiza que la ejecución cruzada de validaciones entre redes es segura y correcta). El Gobernante donde se activó la solicitud de una nueva red, espera a que el resto de Gobernantes de las otras redes le respondan (404, 405), y si todas las verificaciones (o al menos un mínimo preestablecido de ellas, según el algoritmo específico) son exitosas, la nueva red es aceptada al sistema, y el registro de redes actualizado consecuentemente en la red A donde se activó la solicitud de una nueva red (406). La red A envía un mensaje al resto de las redes (407, 408) y éstas actualizan la nueva red en sus registros de redes (409, 410) y envían la confirmación a la red A y, desde allí, al usuario (411,412, 413).
Para asegurar que la ejecución de las políticas de confiabilidad realmente aprovecha el nivel de confiabilidad de las redes externas a una red de origen (por ejemplo, en la figura 1, la red de origen será la red A y las redes externas serían las redes B y C), y que los ataques en el contrato inteligente de una red pueden ser detectados desde estas redes externas mientras se ejecutan las políticas de confiabilidad, el sistema utiliza un Algoritmo de Confianza ZKProof (Prueba de Conocimiento Cero, del inglés Zero Knowledge Proof). El Algoritmo de Confianza ZKProof aprovecha el uso de un protocolo entre redes basado en ZKSnarks (Argumento de conocimiento sucinto no interactivo del conocimiento cero, del inglés Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) para este asunto. El objetivo de este protocolo es detectar y prevenir modificaciones no permitidas o maliciosas sobre los estados de un contrato inteligente. Así, con este Algoritmo de Confianza ZKProof, el contrato inteligente que ejecuta la política de confiabilidad en la red de origen necesita demostrar a la red, de la que está aprovechando la confianza, que su estado no ha sido modificado ilegalmente. Por lo tanto, a través de la ejecución del algoritmo, y sin tener ningún acceso al registro de la red de origen, los nodos de la red de destino, a través de la prueba proporcionada desde la red de origen y la información almacenada de las ejecuciones anteriores de este protocolo, son capaces de detectar y prevenir las modificaciones no válidas del estado. Para mayor claridad, antes de presentar en detalle el funcionamiento del Algoritmo de Confianza ZkProof utilizado en la presente invención, se explica una breve introducción sobre el bloque básico del algoritmo ZKSnarks.
Las ZKSnarks son primitivas criptográficas que, dada una función de cálculo específica C, tal que C = f(w), el conocimiento de la entrada (secreto o testigo) de esta función puede ser probado de forma no interactiva por cualquier otra entidad mediante la construcción de una prueba de conocimiento cero (por eso se dice que las ZkSnarks son una familia de primitivas criptográficas de prueba de conocimiento cero no interactivas). Para utilizar los ZKSnarks en un sistema, se requiere una fase inicial de configuración para generar una clave de prueba y una clave de verificación, llamadas claves del prover y del verificador, Pk y Vk, respectivamente. Estas claves se utilizan luego como entrada para las funciones de generación de pruebas y de verificación, como se detallará a continuación. En la fase de configuración se ejecuta una función generadora, G, para la función de cálculo específica C = f(w)=x para la que se quieren construir las pruebas y verificaciones, junto con una fuente de aleatoriedad, A. A debe mantenerse en secreto, ya que es el material semilla secreto, denominado "residuo tóxico", con el que se generan las claves. A sólo debe utilizarse en la fase de configuración, y debe destruirse inmediatamente después, ya que su conocimiento permite la generación de pruebas falsas. Así, la fase de configuración puede resumirse mediante la siguiente función (Pk,Vk) = G (C,A).
Los mecanismos de ZkSnarks se componen, pues, de dos funciones principales: una función de prueba y una función de verificación. La función de prueba p r f = Proof(Pk,x,w)permite generar una prueba de conocimiento para un testigo, w, es decir, el valor secreto en la función de cálculo C para la que se generaron las claves en la fase de configuración. Por lo tanto, la función de prueba toma como entrada la clave del prover, la salida del cálculo de C = f(w) = xy el testigo, w, y genera una prueba, prf, que cuando se comparte con cualquiera que tenga la clave correcta del verificador, le demuestra el conocimiento del valor del testigo.
La función verificadora se utiliza para validar que el generador de una prueba específica tenía conocimiento de cierto testigo. Así, la función verificadora puede resumirse como ver = V(Vk,x,prf) donde la entrada de la función es la prueba que quiere ser verificada (prf), la clave verificadora generada en la fase de configuración para la función de cálculo específica (Vk) y la pieza pública, (x=f(w)), relacionada con el testigo correcto, w. La salida de la función verificadora, ver, es un valor booleano tal que si la prueba demuestra el conocimiento del valor correcto del testigo, la función verificadora da como resultado verdadero, en caso contrario da como resultado falso. Por lo tanto, ZkSnarks permite el conocimiento de la prueba de un valor específico (testigo, w) sin filtrar ninguna información sobre él a su contraparte. Se puede utilizar cualquier función de prueba y verificador (son conceptos estándar y bien conocidos en el campo de las pruebas de conocimiento cero). Los detalles de las funciones de prueba y de verificación dependen de la primitiva ZkSnark específica seleccionada para la implementación de la invención. El Algoritmo de Confianza ZKProof empleado en una realización preferente de la presente invención, utiliza un protocolo basado en ZKSnarks entre redes para lograr una confianza mejorada como sigue:
La función de cálculo del Algoritmo de Confianza ZKProofmn es la siguiente:
C = hash(w) == x
con sus correspondientes claves generadas del prover y del verificador, Pk y Vk, generadas como se ha explicado anteriormente.
- Sea la Política 1 el contrato de política de confiabilidad utilizado por un contrato inteligente de aplicación de la red DLT A (red de origen) que quiere aprovechar la confianza de una red externa B. El contrato inteligente de aplicación de la DLT A necesita probar a través de la Política A la corrección de su ejecución a la red B. Para lograr esto, la Política A construye una prueba ZKSnark de la siguiente manera:
- El contrato inteligente de la aplicación desencadena la ejecución del Algoritmo de Confianza ZKProof a través del módulo de política de confiabilidad de la red A para la Política 1 (denominada por este medio Política A1). La política A construye entonces el siguiente hash hi:
h(i) = hash(addr_SC_App,txid,fx(attr),attr,res)
donde addr_SC_App es la dirección del contrato inteligente de aplicación; txid el ID de la transacción que desencadenó la política; fx(attr) la función que desencadenó la ejecución de la política y cuyo código quiere aprovechar los niveles externos de confianza; attr los atributos de la función; y res el resultado de la función. El código y la funcionalidad de los contratos inteligentes de la aplicación pueden dividirse a lo largo de diferentes funciones (no todas las funciones de un contrato inteligente desencadenan una modificación en el registro, y si lo hacen, cada función ejecuta una lógica diferente sobre los datos). Este fx(attr) se utiliza para identificar la función específica que desencadenó la ejecución de la política de confiabilidad y con qué atributos específicos (esto permite identificar la lógica específica ejecutada sobre los datos).
El valor de h(i) identifica de forma única la ejecución del contrato inteligente correspondiente a la Política A1 y su resultado.
- La política A1 almacena en una estructura de asignación para cada contrato inteligente de aplicación el valor anterior de h(i), es decir, h(i-1), el hash de la ejecución anterior de la política 1. Utilizando el h(i) calculado y el valor almacenado de h(i-1), calcula
d i f f( i ) = h(i)- h(i — 1)
- Usando h(i) y diff(i) se construye una nueva función hash por la política A:
hp(i) = hash(h(i)\\d iff(i))
Este hash se utiliza para asegurar que la ejecución actual del contrato inteligente, h(i), y el pasado de la política 1, diff(i), no han sido modificados.
- El nuevo valor de h(i) se almacena en el mapeo de la Política A para el contrato inteligente de la aplicación actual. Utilizando el valor de hp(i), valor público, y diff(i), el testigo secreto de la primitiva ZKSnark, se construye la siguiente prueba:
prf(i) = P roof{Pk,hp(i),diff(i))
Esta prueba permitirá a la política B1 (el módulo de política de confiabilidad de la red B para la política 1) validar la corrección de la ejecución del contrato inteligente de aplicación. Así, prf(i) y h(i) se envían a la Política B1 (a través del módulo de gobernanza de A y del módulo de gobernanza de B, como se muestra en la figura 2) para que verifique la ejecución.
Con la recepción de h(i) y prf(i) de la red DLT A, la política B1 comienza a verificar la prueba para validar la ejecución del contrato inteligente de la aplicación como sigue:
- En primer lugar, utilizando la h (i-1) almacenada para el contrato inteligente de la aplicación en el mapeo de la política B1 a partir de ejecuciones anteriores de la política 1 y la h(i) recibida, calcula:
di f f ( i ) = h(i) — h(i — 1)
- Utilizando diff(i) y el h(i) recibido se calcula la siguiente fórmula:
hp(i) = hash(h(i) \| dif f(i))
- Utilizando diff(i), el hp(i) calculado y la prueba recibida, la política B verifica la prueba para validar la consistencia de la ejecución del contrato inteligente de la aplicación utilizando:
Verify(Vk, hp(i),prf(i))
- Si la prueba se verifica correctamente (por todos los nodos de computación de las redes B y C o por un grupo significativo de ellos, dependiendo de la realización), se envía un ACK desde la Política B1 a la Política A1 (a través de los Módulos de Gobernanza B y A) indicando que el contrato inteligente de aplicación puede continuar su ejecución y modificar el registro. Si, por el contrario, la verificación no es correcta, la Política B1 envía un mensaje KO a la Política A1, se cancela la ejecución del contrato inteligente de aplicación (por lo que no se modifica el registro) y, preferentemente, se envía una notificación a las entidades de gobernanza de la red A indicando que se puede haber sufrido un posible ataque en la red. La verificación correcta de la prueba en el Algoritmo de Confianza ZKProof por parte de la red B significa que la ejecución del contrato inteligente y la correspondiente actualización del registro en la red A es correcta y coherente con el historial de los estados del contrato inteligente de aplicación. Si la verificación no tiene éxito, significa que, o bien los estados anteriores del contrato inteligente de la aplicación han sido modificados ilegalmente, o bien la actualización de estados propuesta no es coherente con el historial de estados del contrato inteligente.
En la siguiente tabla se muestra un resumen del Algoritmo de Confianza ZKProof explicado anteriormente mediante un pseudocódigo.
llllllllllllllllllllllllllllllllllll
### FASE DE CONFIGURACIÓN ###
l l l l l l l l l l l l l l l l l l
C = hash(w) == x
(Pk, Vk) = G(C, lambda)
llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
## POLÍTICA A - ALGORITMO DE CONFIANZA ZKPROOF M
llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
var hi = hash(addr_SC_app, txid, fx, attr, res)
var diffi = hi - GetFormLedgerA(addr_SC_app, hi-1)
var hpi = hash(hi|| diffi)
StoreInLedgerA(addr_SC_app, hi)
var proofi = ZKProof(pk, hpi, diffi)
SendPolicyB(proofi, hi)
llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
m POLÍTICA B - ALGORITMO DE CONFIANZA ZKPROOF l l
llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
var proofi, hi = ReceivePolicyA(proofi, hi)
var diffi = hi - GetFromLedgerB(addr_SC_app, hi-1)
var hpi = hash(hi || diffi)
var vrfi = ZKVerify(Vk, hpi, proofi)
si(vrfi) {
StoreInLedgerB(addr_SC_app, hi)
SendPolicyB(OK)
} si no {
SendPolicyB(KO)
}
En resumen, la presente invención admite la implementación de políticas de confiabilidad a nivel de contrato inteligente para aprovechar los diferentes niveles de confiabilidad de cualquiera de las redes DLT conectadas, teniendo así la capacidad de explotar desde una red DLT privada un nivel de confiabilidad equivalente al de una red DLT pública. Para conseguirlo se utiliza un protocolo de algoritmo de confianza ZkProof entre redes. El hecho de tener un enfoque basado en contratos inteligentes permite que estas redes sean públicas, privadas o con permiso (no hay restricción en cuanto al tipo de red a conectar siempre que ejecute contratos inteligentes), y el uso de contratos inteligentes replicados en cada red asegura un nivel de autogobierno del sistema (dictado por la implementación específica del contrato inteligente). En consecuencia, la presente invención permite que pequeñas redes DLT dedicadas (y frecuentemente privadas) utilizadas en casos de uso específicos aprovechen el nivel de confiabilidad de redes de propósito general más grandes. Así, en el panorama actual de la DLT, en el que las empresas se unen en pequeños consorcios y construyen pequeñas redes DLT para proyectos específicos, podrán mejorar el nivel de confiabilidad de estas redes (y proyectos) mediante la interconexión con otras pequeñas redes privadas, o con otras más grandes de propósito general (construyendo una constelación de redes DLT de confianza interconectadas).
La descripción y los dibujos se limitan a ilustrar los principios de la invención.
La solución propuesta se ha presentado aquí según varias realizaciones, pero, por supuesto, se admiten varias implementaciones alternativas de esta arquitectura según las plataformas d Lt subyacentes específicas conectadas a ella, la implementación de contratos inteligentes para los contratos de gobernanza y de políticas, y los algoritmos específicos de validación y gobernanza utilizados en las diferentes redes. En otras palabras, aunque la presente invención se ha descrito con referencia a realizaciones específicas, debe entenderse por los expertos en la materia que lo anterior y varios otros cambios, omisiones y adiciones en la forma y el detalle de la misma pueden hacerse en ella sin apartarse del alcance de la invención como se define en las siguientes reivindicaciones. Además, todos los ejemplos que se recitan en el presente documento tienen como objetivo principal y expreso ser sólo para fines pedagógicos para ayudar al lector en la comprensión de los principios de la invención y los conceptos aportados por el (los) inventor(es) para promover la técnica, y deben interpretarse como sin limitación a tales ejemplos y condiciones específicamente recitados. Además, todas las afirmaciones que aquí se recitan sobre principios, aspectos y realizaciones de la invención, así como los ejemplos específicos de la misma, pretenden abarcar los equivalentes de los mismos.
Los expertos en la materia apreciarán que cualquier diagrama de bloques en el presente documento representa vistas conceptuales de circuitos ilustrativos que incorporan los principios de la invención. Del mismo modo, se apreciará que cualquier gráfico de flujos, diagramas de flujo, diagramas de transición de estado, pseudocódigo, y similares representan diversos procedimientos que pueden ser sustancialmente representados en un medio legible por ordenador y así ejecutados por un ordenador o procesador, independientemente de que dicho ordenador o procesador se muestre explícitamente.

Claims (11)

REIVINDICACIONES
1. Un procedimiento para mejorar el nivel de confiabilidad de una primera red de Tecnología de registro distribuido, DLT, utilizando una o más redes DLT secundarias, donde la primera y la segunda red DLT comprenden varios nodos de computación y son redes DLT independientes conectadas por una o más redes de telecomunicaciones, comprendiendo el procedimiento las siguientes etapas realizadas en la primera red DLT:
a) Recibir en la primera red DLT una solicitud de validación de un contrato inteligente, donde para la validación del contrato inteligente se utiliza una determinada política de confiabilidad;
b) Calcular un valor hash h(i) que identifique de forma única la ejecución actual del contrato inteligente correspondiente a la política de confiabilidad y su resultado, y almacenar dicho valor hash en una base de datos de la primera red DLT;
c) Obtener el valor hash de la ejecución anterior del contrato inteligente h(i-1);
d) Transmitir a una o más segundas redes DLT, a través de la una o más redes de telecomunicaciones, una instrucción de validación que incluya h(i) y una prueba de conocimiento cero, siendo prf(i) prf(i) = Proof(Pk,hp(i),diff(i)), donde Proof() es una función preestablecida, Pk es una clave de prueba aleatoria preestablecida, diff(i)= h(i)-h(i-1) y hp(i) = hash(h(i) || diff(i));
e) Recibir, a través de la una o más redes de telecomunicaciones, de cada segunda red DLT a la que se haya enviado una instrucción de validación, un resultado de validación, donde el resultado de validación se obtiene en cada segunda red DLT mediante el cálculo: Verify (Vk, hp(i), prf(i)) donde Verify() es una función de verificación preestablecida, Vk es una clave de verificación aleatoria preestablecida, hp(i) = hash(h(i) || diff(i)), y diff(i)= h(i)-h(i-1) donde h(i) es el valor de h(i) recibido de la primera red DLT y h(i-1) es el valor hash almacenado en la segunda red DLT en la ejecución anterior de la validación del contrato inteligente;
f) Cancelar la ejecución del contrato inteligente en la primera red DLT, si el número de resultados de validación negativos es superior a un umbral preestablecido.
2. Un procedimiento según la reivindicación 1, en el que h(i) = hash (addr_SC_App,txid,fx(attr),attr,res) donde addr_SC_App es la dirección de la aplicación que implementa el contrato inteligente; txid el ID de la transacción que activó la política de confiabilidad; fx(attr) la función que activó la ejecución de la política de confiabilidad; attr los atributos de la función; y res el resultado de la función.
3. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el cálculo de Verify (Vk, hp(i), prf(i)) se realiza en todos los nodos de computación de cada una o más segundas redes DLT y el resultado de la validación recibido de cada una o más segundas redes DLT es positivo solo si el resultado de la función de verificación es positivo en todos los nodos de computación de dicha segunda red DLT o si el resultado de la función de verificación es positivo en un número de nodos de computación de dicha segunda red DLT superior a un umbral preestablecido.
4. Un procedimiento según cualquiera de las reivindicaciones anteriores en el que el contrato inteligente a validar es un contrato inteligente para la modificación de un registro de red.
5. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que las comunicaciones entre la primera red DLT y la una o más segundas redes DLT se realizan a través de instancias de gobernanza en cada nodo de computación de las redes DLT, que gestionan la lógica de interconexión entre las redes DLT, almacenando cada instancia de gobernanza información sobre el resto de las redes DLT.
6. Un procedimiento según la reivindicación 5, en el que en la etapa d), la instancia de gobernanza de un nodo de computación de la primera red DLT, utilizando información de red almacenada sobre la una o más segundas redes DLT, envía la instrucción de validación a una instancia de gobernanza de un nodo de computación de cada una o más segundas redes DLT a través de una red de telecomunicaciones.
7. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que cada nodo de computación de cada red DLT tiene un registro con las políticas de confiabilidad disponibles en la red DLT y cuando un usuario de la red quiere añadir una nueva política de confiabilidad a una de las redes DLT, al menos un nodo de computación de dicha red DLT comprueba si el usuario tiene suficientes permisos para añadir una nueva política de confiabilidad y sólo si el usuario tiene permiso, se registra la nueva política de confiabilidad.
8. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que cada nodo de computación de cada red DLT tiene un registro con las redes DLT disponibles para ser utilizado para mejorar el nivel de confiabilidad, y cuando un usuario de la red solicita añadir una nueva red DLT, al menos un nodo de computación de la red DLT donde se recibe la solicitud envía la solicitud al resto de las redes DLT, las redes DLT verifican si la nueva red DLT es aceptada y sólo si al menos un umbral preestablecido de las redes DLT acepta dicha nueva red DLT, la nueva red DLT es registrada en los nodos de computación de las redes DLT como una nueva red DLT que se utilizará para mejorar el nivel de confiabilidad.
9. Un sistema para mejorar el nivel de confiabilidad de una primera red de Tecnología de registro distribuido, DLT, utilizando una o más redes DLT secundarias, donde la primera y la segunda red DLT son redes DLT independientes conectadas por una o más redes de telecomunicaciones, comprendiendo el sistema la primera red DLT y una o más redes DLT secundarias, comprendiendo la primera red DLT al menos un nodo de computación que incluye un procesador configurado para:
- recibir una solicitud para validar un contrato inteligente, donde para la validación del contrato inteligente se utiliza una determinada política de confiabilidad;
- calcular un valor hash h(i) que identifique de forma única la ejecución actual del contrato inteligente correspondiente a la política de confiabilidad y su resultado, y almacenar dicho valor hash en una base de datos de la primera red DLT;
- obtener el valor hash de la ejecución anterior del contrato inteligente h(i-1);
- transmitir a un nodo de computación de cada segunda red DLT una instrucción de validación que incluya h(i) y una prueba de conocimiento cero, siendo prf(i) prf(i) = Proof(Pk,hp(i),diff(i))donde Proof() es una función preestablecida, Pk es una clave de prueba aleatoria preestablecida, diff(i)= h(i)-h(i-1) y ip(i) = hash(h(i) || diff(i));
comprendiendo la una o más segundas redes DLT:
- al menos un nodo de computación que comprende un procesador configurado para recibir la instrucción de validación de la primera red DLT directamente o a través de otro nodo de computación de la segunda red DLT; determinar un resultado de validación calculando: Verify (Vk, hp(i), prf(i)) donde Verify() es una función de verificación preestablecida, Vk es una clave de verificación aleatoria preestablecida, hp(t) = hash(h(i) || diff(i)), y diff(i)= h(i)-h(i-1) donde h(i) es el valor de h(i) recibido de la primera red DLT y h(i-1) es el valor hash almacenado en el nodo de computación en la ejecución anterior de la validación del contrato inteligente;
en el que la ejecución del contrato inteligente en la primera red DLT se cancela, si el número de resultados de validación negativos recibidos de la una o más segundas redes DLT es superior a un umbral preestablecido.
10. Un sistema según la reivindicación 9, en el que el procesador del al menos un nodo de computación está configurado además para:
- si recibe la instrucción de validación de un nodo de computación de la primera red DLT: distribuir dicha instrucción de validación a todos los nodos de computación de la segunda red DLT; recibir el resultado de la validación de los nodos de computación de la segunda red DLT; determinar un resultado de validación para la segunda red DLT basado en los resultados de validación en todos los nodos de computación de la segunda red DLT y enviar dicho resultado de validación al nodo de computación de la primera red DLT del que ha recibido las instrucciones de validación.
11. Un medio de almacenamiento de datos digitales no transitorio para almacenar un programa de ordenador que comprende instrucciones que hacen que un ordenador que ejecuta el programa realice el procedimiento según cualquiera de las reivindicaciones 1-8.
ES19382513T 2019-06-20 2019-06-20 Procedimiento y sistema para mejora de la confiabilidad entre redes DLT Active ES2914340T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP19382513.0A EP3754899B1 (en) 2019-06-20 2019-06-20 Method and system for inter-dlt networks trust enhancement

Publications (1)

Publication Number Publication Date
ES2914340T3 true ES2914340T3 (es) 2022-06-09

Family

ID=67060349

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19382513T Active ES2914340T3 (es) 2019-06-20 2019-06-20 Procedimiento y sistema para mejora de la confiabilidad entre redes DLT

Country Status (4)

Country Link
US (1) US11374763B2 (es)
EP (1) EP3754899B1 (es)
BR (1) BR102020012305A2 (es)
ES (1) ES2914340T3 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11245525B2 (en) * 2019-09-10 2022-02-08 Bank Of America Corporation Managing a third-party recipient digital resource vehicle via a distributed trust computing network
CN112866025B (zh) * 2021-01-14 2022-10-11 公安部第三研究所 一种智能合约的分片处理方法
EP4096150A1 (en) 2021-05-24 2022-11-30 Billon Sp. z o.o. A computer-implemented method for improving security of a communication between a dlt network nodes and an external computer system
CN113704350A (zh) * 2021-08-03 2021-11-26 西安交通大学 基于区块链多链技术融合的智能电动汽车数据存储方法

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101849917B1 (ko) * 2016-10-13 2018-05-31 주식회사 코인플러그 스마트 컨트랙트 기반의 인증서 서비스를 제공하는 방법 및 이를 이용한 서버
KR101816651B1 (ko) * 2017-02-14 2018-01-09 주식회사 코인플러그 Utxo 기반 프로토콜의 블록체인 데이터베이스를 사용하여 서비스 제공 서버에 의하여 제공되는 서비스를 이용하기 위한 사용자의 로그인 요청에 대하여 pki 기반의 인증을 통해 로그인을 대행하는 방법 및 이를 이용한 서버
EP3559882A1 (en) * 2017-03-22 2019-10-30 NEC Laboratories Europe GmbH Method for operating a blockchain
US10565192B2 (en) * 2017-08-01 2020-02-18 International Business Machines Corporation Optimizing queries and other retrieve operations in a blockchain
WO2019075560A1 (en) * 2017-10-16 2019-04-25 Btl Group Ltd. METHOD AND SYSTEM FOR FACILITATING DATA TRANSFER BETWEEN BLOCK CHAINS
EP3707623A1 (en) * 2017-11-09 2020-09-16 Nchain Holdings Limited System for simplifying executable instructions for optimised verifiable computation
EP4395229A1 (en) * 2017-11-09 2024-07-03 nChain Licensing AG Systems and methods for ensuring correct execution of computer program using a mediator computer system
US10833861B2 (en) * 2017-11-28 2020-11-10 International Business Machines Corporation Protection of confidentiality, privacy and ownership assurance in a blockchain based decentralized identity management system
WO2019142142A1 (en) * 2018-01-19 2019-07-25 Qed-It Systems Ltd. Proof chaining and decomposition
US11223631B2 (en) * 2018-04-06 2022-01-11 Hewlett Packard Enterprise Development Lp Secure compliance protocols
US10904009B2 (en) * 2018-05-30 2021-01-26 International Business Machines Corporation Blockchain implementing delta storage
EP3803745B1 (fr) * 2018-06-06 2022-11-16 Enrico Maim Système transactionnel sécurisé dans une architecture p2p
CN109274481B (zh) * 2018-08-01 2020-03-27 中国科学院数据与通信保护研究教育中心 一种区块链的数据可追踪方法
US10298395B1 (en) * 2018-09-26 2019-05-21 Accenture Global Solutions Limited Interoperability of zero-knowledge proof enabled blockchains
US11012242B1 (en) * 2018-09-28 2021-05-18 Wells Fargo Bank, N.A. Systems and methods for trusted chain code system
CN111833189A (zh) * 2018-10-26 2020-10-27 创新先进技术有限公司 数据处理方法及装置
TW202034651A (zh) * 2018-11-08 2020-09-16 柯賓漢數位金融科技有限公司 分散式系統中資訊驗證方法
US20200153605A1 (en) * 2018-11-13 2020-05-14 Accelor Ltd. Systems and methods for pre-executing transaction validation for blockchain applications
US20200174990A1 (en) * 2018-11-29 2020-06-04 Anthony Turner Pratkanis Accountably Redactable Data Structures
US11151558B2 (en) * 2018-12-12 2021-10-19 American Express Travel Related Services Company, Inc Zero-knowledge proof payments using blockchain
US10735205B1 (en) * 2019-03-08 2020-08-04 Ares Technologies, Inc. Methods and systems for implementing an anonymized attestation chain
US11323243B2 (en) * 2019-04-05 2022-05-03 International Business Machines Corporation Zero-knowledge proof for blockchain endorsement
US11949691B2 (en) * 2019-05-24 2024-04-02 International Business Machines Corporation Malicious peer identification
CA3141042A1 (en) * 2019-06-13 2020-12-17 Luis Eduardo Gutierrez-Sheris System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records

Also Published As

Publication number Publication date
US11374763B2 (en) 2022-06-28
BR102020012305A2 (pt) 2020-12-29
US20200403799A1 (en) 2020-12-24
EP3754899A1 (en) 2020-12-23
EP3754899B1 (en) 2022-03-02

Similar Documents

Publication Publication Date Title
ES2914340T3 (es) Procedimiento y sistema para mejora de la confiabilidad entre redes DLT
Xu et al. Towards secure network computing services for lightweight clients using blockchain
ES2932500T3 (es) Seleccionar y asegurar delegados de prueba para funciones criptográficas
CN110915166B (zh) 区块链
US20190095879A1 (en) Blockchain payment channels with trusted execution environments
JP5497171B2 (ja) セキュア仮想マシンを提供するためのシステムおよび方法
Jia et al. A2 chain: a blockchain‐based decentralized authentication scheme for 5G‐enabled IoT
Xu et al. A policy enforcing mechanism for trusted ad hoc networks
Hardjono et al. Decentralized trusted computing base for blockchain infrastructure security
US7849326B2 (en) Method and system for protecting master secrets using smart key devices
Soriente et al. Replicatee: Enabling seamless replication of sgx enclaves in the cloud
Petzi et al. {SCRAPS}: Scalable collective remote attestation for {Pub-Sub}{IoT} networks with untrusted proxy verifier
Javaid et al. Defining trust in IoT environments via distributed remote attestation using blockchain
ES2959557T3 (es) Método para operar una aplicación de igual a igual
Ahmed et al. Transparency of SIM profiles for the consumer remote SIM provisioning protocol
Debes et al. Blindtrust: Oblivious remote attestation for secure service function chains
CN111651740B (zh) 一种面向分布式智能嵌入式系统的可信平台共享系统
Sidhu et al. Trust development for blockchain interoperability using self-sovereign identity integration
Anggorojati et al. Capability-based access control with ecc key management for the m2m local cloud platform
Yin et al. Phala network: A secure decentralized cloud computing network based on Polkadot
Gosu et al. Decentralised Authentication Protocol for Devices & Users to Access Private Network Services Using Blockchain
Chollet et al. Secure IoT for a pervasive platform
Zhang et al. Teamwork Makes TEE Work: Open and Resilient Remote Attestation on Decentralized Trust
Bakhtiary et al. Combo-Chain: Towards a hierarchical attribute-based access control system for IoT with smart contract and sharding technique
Belwafi et al. Zero-Trust Communication between Chips