ES2954424T3 - Mercado inteligente, descentralizado y autónomo para computación y almacenamiento distribuidos - Google Patents

Mercado inteligente, descentralizado y autónomo para computación y almacenamiento distribuidos Download PDF

Info

Publication number
ES2954424T3
ES2954424T3 ES19850790T ES19850790T ES2954424T3 ES 2954424 T3 ES2954424 T3 ES 2954424T3 ES 19850790 T ES19850790 T ES 19850790T ES 19850790 T ES19850790 T ES 19850790T ES 2954424 T3 ES2954424 T3 ES 2954424T3
Authority
ES
Spain
Prior art keywords
node
computing
nodes
client
management
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
ES19850790T
Other languages
English (en)
Inventor
Claudio Lima
Navjit Dhaliwal
Rohit Gupta
Elad Harison
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.)
Iagon As
Original Assignee
Iagon As
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=69582142&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2954424(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Iagon As filed Critical Iagon As
Application granted granted Critical
Publication of ES2954424T3 publication Critical patent/ES2954424T3/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
    • 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/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • 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/1044—Group management mechanisms 
    • H04L67/1046—Joining mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/505—Clust

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Environmental & Geological Engineering (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Electrotherapy Devices (AREA)
  • Hardware Redundancy (AREA)

Abstract

Los métodos, sistemas y aparatos pueden proporcionar tecnología que proporcione una red descentralizada. La tecnología puede incluir un nodo de gestión que genera una lista de una pluralidad de nodos informáticos que se encuentran dentro de un nivel. La tecnología puede incluir además un primer nodo informático que proporcione recursos informáticos para que los utilicen otros nodos. El primer nodo informático determina que el primer nodo informático está dentro del nivel basándose, al menos en parte, en los recursos informáticos y envía una notificación al nodo de gestión para agregar el primer nodo informático a la lista en función de la determinación. La tecnología también puede incluir un nodo cliente que realiza una identificación del nivel en función de una capacidad informática que se prevé que se utilizará para ejecutar una o más tareas asociadas con el nodo cliente. El nodo cliente identifica el nodo de gestión basándose en la identificación y solicita la lista al nodo de gestión. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Mercado inteligente, descentralizado y autónomo para computación y almacenamiento distribuidos
CAMPO TÉCNICO
Las realizaciones se refieren, en general, a un mercado de computación en la nube descentralizado. En detalle, algunas realizaciones pueden estar dirigidas a un mercado para acceder a los recursos computacionales de forma descentralizada.
ANTECEDENTES
Las demandas de recursos computacionales de algunos usuarios y empresas pueden fluctuar. Por ejemplo, un servicio de transmisión de video, tal como NETFLIX o HULU, puede necesitar un mayor volumen de recursos computacionales después de las 17:00 h, cuando es posible que los usuarios no estén ocupados con sus tareas laborales. El mismo servicio de transmisión de video puede tener una menor necesidad de recursos antes de las 17:00 h, cuando las personas están ocupadas y no pueden usar el servicio de transmisión de video. Tales fluctuaciones de la demanda pueden ser problemáticas, ya que puede que no sea prudente que el servicio de transmisión de video sea el propietario de los recursos. Más bien, puede ser preferible que el servicio de transmisión de video alquile recursos en función de la demanda fluctuante. Del mismo modo, los propietarios de recursos computacionales, como operadores de centros de datos, ordenadores de sobremesa o incluso propietarios de teléfonos móviles, generalmente disponen de recursos computacionales sobrantes que pueden utilizar para generar recompensas o ingresos gratuitos para ellos.
El documento US 2009/164576 A1 se refiere a procedimientos, sistemas, dispositivos y dispositivos de almacenamiento configurados que se utilizan en relación con un sistema de transmisión entre pares (peer-to-peer) con una pluralidad de nodos de procesamiento-circuito-par que comparten datos de transmisión pasando los datos de transmisión de nodos principales a nodos secundarios. Los nodos basados en ordenador están configurados y adaptados para detectar la salida de un primer nodo par secundario del sistema de transmisión entre pares. El primer nodo par secundario es un nodo par secundario del nodo par principal y el primer par secundario proporciona datos a uno o más pares secundarios adicionales. En respuesta a la salida detectada, se selecciona un segundo par secundario para proporcionar datos a uno o más pares secundarios adicionales. Los datos se proporcionan al segundo par secundario para facilitar el establecimiento de una conexión entre el par secundario seleccionado y el uno o más pares secundarios adicionales y el nodo par principal.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Las diversas ventajas de las realizaciones resultarán evidentes para el experto en la materia a partir de la lectura de la siguiente memoria descriptiva y las reivindicaciones adjuntas, y con referencia a los siguientes dibujos, en los que: La FIGURA 1 ilustra un ejemplo de una arquitectura inteligente, descentralizada y autónoma según una realización;
La FIGURA 2 muestra una arquitectura de distribución de recursos computacionales según una realización;
La FIGURA 3 muestra una arquitectura de computación descentralizada según una realización;
La FIGURA 4 muestra un diagrama de flujo de un ejemplo de un procedimiento para ejecutar una operación de unión de nodos según una realización;
La FIGURA 5 muestra un diagrama de flujo de un ejemplo de un procedimiento para agregar un nodo de cliente a la red según una realización;
La FIGURA 6 muestra un ejemplo de una sección de ajustes de procesamiento según una realización;
La FIGURA 7 muestra un ejemplo de una interfaz gráfica de usuario según una realización;
La FIGURA 8 muestra un ejemplo de una interfaz gráfica de usuario según una realización;
La FIGURA 9 muestra un ejemplo de una configuración de cliente y una interfaz de desarrollador abierta según una realización;
La FIGURA 10 muestra un diagrama de flujo de un ejemplo de un procedimiento de gestión de la reputación según una realización; y
La FIGURA 11 muestra un diagrama de flujo de un ejemplo de un procedimiento de actualización de reputaciones según una realización.
DESCRIPCIÓN DE REALIZACIONES
La FIGURA 1 ilustra una arquitectura 100 que genera un mercado completamente descentralizado, inteligente y autónomo para permitir el comercio de recursos computacionales como el procesamiento de CPU/GPU y el almacenamiento de datos. Para la gestión del mercado, la asignación de recursos, la gestión de la reputación y la optimización del rendimiento general, se utilizan principios de microeconomía teórica de juegos e inteligencia artificial (IA). Algunas realizaciones incluyen Blockchain o tecnología de registro distribuido (DLT) para permitir la autenticación de los participantes el mercado, la auditoría de las transacciones, la seguridad de los datos y las garantías generales de seguridad.
Los clientes pueden estar representados por los nodos de cliente 102a-102n. Los nodos de cliente 102a-102n pueden atravesar la red para emparejarse con recursos computacionales distribuidos apropiados (por ejemplo, fiables y de bajo coste) (por ejemplo, almacenamiento y procesamiento computacional) que pueden estar representados por mineros de nivel 1 a nivel N 122a-122n. Es decir, los nodos de cliente 102a-102n pueden acceder a la red para realizar un pedido que se publicará en un mercado computacional descentralizado y autónomo (descrito a continuación). Debe entenderse que el número de nodos de cliente 102a-102n puede ser diferente del número de mineros de nivel 1 a nivel N. Es decir, la "n" de los nodos de cliente 102n puede ser un número diferente de la "n" y la "N" en los mineros de nivel N 122n.
Un mercado descentralizado puede significar que no se necesita ningún componente centralizado para mantener el funcionamiento general de la arquitectura 100. Por ejemplo, una arquitectura descentralizada puede significar que no existe un componente centralizado, o que cualquier componente centralizado puede no ser crítico para el funcionamiento general de la arquitectura 100.
Los proveedores de recursos computacionales (a veces denominados utilitarios) pueden estar representados por nodos de cómputo de nivel 1 a nivel N 122a-122n. Los nodos de cómputo de nivel 1 a nivel N 122a-122n pueden ofrecer recursos computacionales. Los nodos de cómputo de nivel 1 a nivel N pueden asignar y/o establecer la cantidad de recursos ofrecidos por los nodos de cómputo de nivel 1 a nivel N 122a-122n. En algunas realizaciones, los nodos de cómputo de nivel 1 a nivel N 122a-122n pueden permitir que una capa de inteligencia artificial (IA) 110 determine una cantidad o recurso computacional basándose en tokens y/o incentivos de precio, usos y otros parámetros.
En algunas realizaciones, la capa de IA 110 puede proporcionar una calculadora en línea a los nodos de cómputo de nivel 1 a nivel N 122a-122n para introducir sus tarifas de electricidad en KwH (kilovatios por hora) y la capa de IA 110 puede calcular el coste de electricidad esperado. La capa de IA 110 supone que, estadísticamente, los nodos de cómputo de nivel 1 a nivel N 122a-122n pueden necesitar estar disponibles un tercio del tiempo antes de que los nodos de cliente 102a-102n noten que no están disponibles.
Para el almacenamiento, la capa de IA 110 también puede solicitar a los mineros que introduzcan la fecha de compra de su almacenamiento (por ejemplo, disco duro) y luego la capa de IA 110 puede amortizar el coste por GB teniendo en cuenta el coste minorista habitual de dicho almacenamiento. El coste de la electricidad junto con el coste de almacenamiento puede constituir el coste real de los nodos de cómputo de nivel 1 a nivel N 122a-122n que pueden utilizarse durante la puja en una subasta. Puede ocurrir un proceso similar con otros componentes de hardware (por ejemplo, del procesador) para estimar el precio.
Estos recursos pueden publicarse en el mercado descentralizado P2P 114, algunos de los cuales pueden crearse dinámicamente para diferentes tipos de recursos y utilizarse con fines de tolerancia a fallos. Cuando hay una coincidencia entre los recursos buscados por los nodos de cliente 102a-102n y los recursos ofrecidos por los nodos de cómputo de nivel 1 a nivel N 122a-122n, la transacción de un contrato inteligente puede completarse utilizando tecnologías Blockchain y/o DLT. En algunas realizaciones, la lógica del contrato completa la transacción automáticamente.
Los nodos de cómputo de nivel 1 a nivel N 122a-122n pueden ofrecer varios niveles de servicio (por ejemplo, N niveles de servicios). Asimismo, los nodos de cliente 102a-102n pueden desear ciertos niveles de servicio. Los niveles pueden especificar los niveles de rendimiento computacional y de almacenamiento con diferentes niveles de tiempo de actividad, disponibilidad y/o fiabilidad.
Por ejemplo, el nivel 1 puede utilizarse para computación distribuida de alto rendimiento. El nivel 2 puede utilizarse para pequeñas y medianas empresas, y para informática de consumo. El nivel 3 puede utilizarse para informática de dispositivos móviles, y así sucesivamente. Aunque anteriormente se describen tres niveles, la cantidad de niveles ofrecidos no está limitada, por lo que se pueden ofrecer más o menos de tres niveles.
El mecanismo subyacente para permitir la creación de un mercado se basa en un protocolo de red entre pares (P2P). En este ejemplo particular, el protocolo Kademila P2P DHT 108 y/o la capa de IA 110 pueden gestionar el descubrimiento, la mensajería, la sincronización y la asignación de recursos de todos los nodos pares.
Además, un sistema de gestión de la reputación 124 puede clasificar los nodos de cómputo de nivel 1 a nivel N 122a-122n de alto rendimiento (por ejemplo, proveedores de recursos computacionales), mejorar la asignación de recursos y aislar los nodos maliciosos y no autorizados de la arquitectura 100. Por ejemplo, el sistema de gestión de la reputación 124 también puede desplegar un servicio de gestión de la reputación que realice un análisis predictivo basado en el aprendizaje automático y asigne una calificación (por ejemplo, en una escala de 1 a 5, siendo 1 la peor y 5 la mejor) a cada nodo de cómputo de nivel 1 a nivel N 122a-122n. Los resultados de este servicio estarán disponibles para todos los usuarios, quizás a través de la capa Blockchain, lo que ayudará a evitar cualquier requisito adicional de almacenamiento o procesamiento en los nodos de cómputo de nivel 1 a nivel N 122a-122n y los nodos de cliente 102a-102n, como garantiza la versión distribuida que se describe anteriormente.
El sistema de gestión de la reputación 124 puede proporcionar sus clasificaciones a la capa de IA 110 con el fin de recompensar a los nodos de cómputo de nivel 1 a nivel N 122a-122n de alto rendimiento con incentivos financieros y/o más tareas. Es decir, la capa de IA 110 puede dar un tratamiento preferencial a los nodos de cómputo de nivel 1 a nivel N 122a-122n de alto rendimiento.
Por lo tanto, algunas realizaciones se refieren a un procedimiento y una arquitectura 100 para asignar, autenticar, gestionar y descubrir recursos computacionales distribuidos (potencia computacional y almacenamiento) en una red entre pares distribuida mediante el uso de Blockchain y/o DLT para crear un mercado basado en transacciones que comercializa recursos computacionales con clientes que buscan almacenamiento y potencia computacional de alta calidad y bajo coste. Por ejemplo, al menos dos de los recursos incluyen procesamiento informático descentralizado P2P 116 y almacenamiento descentralizado P2P 118.
La capa de IA 110 puede gestionar y potenciar al menos algunas de las operaciones para crear una plataforma de computación en la nube autónoma, descentralizada e inteligente. Tal como se ilustra, las API (interfaces de programación de aplicaciones) 106 pueden facilitar las llamadas entre las interfaces de usuario 104 y la cadena de bloques 108. La cadena de bloques 108 puede servir como libro de contabilidad o registro de transacciones, clasificaciones, solicitudes de servicio, ofertas de recursos, puntuaciones de reputación, etc.
A continuación, se proporcionan con más detalle aspectos relativos a la construcción de un mercado impulsado por la IA para descentralizar completamente la computación y el almacenamiento en la nube entre los nodos de cómputo de nivel 1 a nivel N 122a-122n. Por el contrario, algunos otros sistemas pueden tener un componente centralizado global que es necesario y crítico para el funcionamiento general del sistema. Las realizaciones de la presente solicitud pueden relacionarse con la computación y el almacenamiento distribuidos para construir una solución de computación en la nube totalmente abierta, descentralizada e infinitamente escalable que incluya mercados flexibles y seguros para el comercio de recursos computacionales y almacenamiento.
La aparición de las tecnologías Blockchain, DLT y criptomonedas puede haber permitido soluciones a escala de Internet. Las redes Blockchain, DLT y/o P2P pueden utilizarse para crear soluciones de almacenamiento y computación en la nube a escala de Internet verdaderamente descentralizadas con recursos escalables. En algunas realizaciones, puede enviarse cualquier tarea que pueda encapsularse como un contenedor (por ejemplo, una aplicación con todas sus partes puede necesitar incluir librerías y otras dependencias, contenedores Docker, etc.) y los nodos de cliente 102a-102n solo pueden tener que pagar por la duración de la ejecución de la tarea. Por lo tanto, los usuarios pueden acceder a una capacidad de computación de alta disponibilidad casi ilimitada a un menor coste y con una mayor eficiencia.
Tal como se ilustra en la FIGURA 1, la arquitectura 100 incluye interfaces de cliente 104 para nodos de cliente 102a-102n. Las interfaces de cliente 104 y/o los nodos de cliente 102a-102n pueden ser de varias plataformas (por ejemplo, WINDOWS, MAC OS y LINUX). Las interfaces de cliente 104 pueden operar en los nodos de cliente 102a-102n o pueden estar a distancia de los nodos de cliente 102a-102n. Las interfaces de cliente 104 y los nodos de cliente 102a-102n pueden conectarse a la infraestructura de red de recursos computacionales y almacenamiento distribuidos a través de un mercado descentralizado inteligente y P2P 114.
La capa de inteligencia artificial 110, denominada "Protocolo de Alexandria", puede permitir la asignación de recursos computacionales distribuidos y la optimización del rendimiento en algunas realizaciones. La capa de inteligencia artificial 110 aprende continuamente de las interacciones en el mercado descentralizado P2P 114 y optimiza la estrategia para los participantes en el mercado descentralizado P2P 114. Por ejemplo, la capa de inteligencia artificial 110 puede realizar las siguientes operaciones:
1. Planificar y optimizar la asignación de recursos P2P distribuidos y el rendimiento del procesamiento informático descentralizado P2P 116 y el almacenamiento descentralizado P2P 118;
2. Construir reputaciones para nodos del sistema, tal como los nodos de cliente 102a-102n (por ejemplo, utilitarios), mineros de nivel 1 a nivel N 122a-122n (por ejemplo, clientes) y/o nodos de gestión (descritos a continuación);
3. Predecir el tiempo de actividad y la disponibilidad de los nodos de cliente 102a-102n;
4. Predecir el tiempo de finalización aproximado de las tareas para los mineros de nivel 1 a nivel N 122a-122n en función de las especificaciones de las tareas;
5. Recomendar la mejor estrategia de fijación de precios para los nodos de cliente 102a-102n con el fin de maximizar la utilización de los recursos locales, así como el potencial de beneficios.
A medida que la arquitectura 100 escala a más tareas y participantes, los modelos de aprendizaje automático y/o profundo de la capa de inteligencia artificial 110 pueden aprender de los datos adicionales y volverse cada vez más eficientes y útiles desde la perspectiva de los participantes.
En algunas realizaciones, la capa de inteligencia artificial 110 puede incluir un gestor de amenazas 126 que evalúa las amenazas a la arquitectura 100. En algunas realizaciones, el gestor de amenazas 126 puede modificar el comportamiento y/o los parámetros de la capa de inteligencia artificial 110 para mitigar tales riesgos. Por ejemplo, en algunas realizaciones, el gestor de amenazas 126 puede modificar el comportamiento y/o los parámetros de la capa de inteligencia artificial 110 para mitigar tales riesgos, como, por ejemplo, excluyendo algunos de los nodos de cómputo 122a-122n identificados como que suponen un riesgo potencial para la arquitectura 100.
En algunas realizaciones, la capa de inteligencia artificial 110 puede implementar un mecanismo de consenso. Como su nombre indica, el mecanismo de consenso implica distribuir una tarea computacional a varios nodos de cómputo (por ejemplo, tres u otro número impar) de los nodos de cómputo de nivel 1 a nivel N 122a-122n, y luego seleccionar el resultado proporcionado por la mayoría de los nodos de cómputo de nivel 1 a nivel N 122a-122n. Los nodos de cómputo de nivel 1 a nivel N 122a-122n cuyos resultados no coincidan con los resultados seleccionados no obtienen ninguna recompensa y, además, son penalizados en términos de su puntuación de reputación.
Algunas realizaciones se refieren a la construcción de un mercado de computación y almacenamiento distribuidos descentralizados. Aspectos de la arquitectura 100, como la cadena de bloques descentralizada P2P 108 (y/o DLT) y el mercado descentralizado P2P 114, los nodos de cómputo de nivel 1 a nivel N 122a-122n, los nodos de cliente 102a-102n y la capa de IA 110 para recursos computacionales distribuidos (almacenamiento y computación), se muestran con más detalle en la arquitectura 200 de la FIGURA 2. La arquitectura 200 puede implementarse fácilmente como parte de la arquitectura 100 donde los componentes superpuestos se incluyen unos dentro de otros.
La arquitectura 200 puede estar formada por al menos tres capas que incluyen 1) una capa de aplicaciones descentralizadas (Dapps) e interfaz cliente-Web 202; 2) una capa Blockchain y/o DLT 216 (por ejemplo, una capa Ethereum, IOTA, Corda, Eo s , Hyperledger, etc.), y 3) una capa de red P2P 214.
La capa de red P2P subyacente 214 puede incluir un protocolo de red que permita a cualquier nuevo nodo unirse a la capa de red P2P 214 y ser insertado y sincronizado con otros pares. Una vez añadidos nuevos nodos, los proveedores de recursos computacionales (nodos de cómputo de los nuevos nodos) pueden entonces configurar la forma en que desean que los recursos computacionales de los nodos de cómputo estén disponibles en el mercado y las recompensas que eligen para esos servicios. Los servicios también pueden añadirse a Blockchain y/o DLT 216, y categorizarse por diferentes niveles 1 a N 204a-204n de servicios, donde los nodos de cómputo de los nodos 206a-206n, 208a-208n, 210a-210n pueden registrarse automáticamente para publicar la disponibilidad de los recursos mediante punteros hash (hash pointers) encriptados.
Cada nivel 1 a N 204a-204n de servicios publica un conjunto único de recursos computacionales dentro de ciertos parámetros (por ejemplo, potencia de computación y almacenamiento entre ciertos límites) donde los clientes y los proveedores de nodos de cómputo pueden interactuar para comercializar estos recursos computacionales de forma descentralizada. Una vez que se confirma la coincidencia de un servicio y se lleva a cabo un contrato inteligente o cualquier transacción lógica de código inteligente en la capa de Blockchain y/o DLT 216, pueden intercambiarse tokens entre los nodos de cómputo y de cliente para pagar por ese servicio.
Por ejemplo, el nivel uno 204a puede corresponder a potencia de procesamiento y almacenamiento de nivel empresarial. El nodo 210a puede ser un nodo de cómputo que ofrece servicios en la categoría de nivel uno 204a. Es decir, el nodo 210a puede proporcionar potencia de procesamiento y almacenamiento de nivel empresarial. El nodo 210a puede publicar en el nivel uno 204a, el nivel exacto de potencia de procesamiento y almacenamiento, requisitos de precios, acuerdos de servicio, limitaciones de tiempo (por ejemplo, debe ser una tarea que pueda ejecutarse en menos de dos horas o entre las 2:00 y las 6:00 horas), etc. del nodo 210a. El nodo 210n puede ser un nodo de cliente. El nodo 210n puede requerir niveles de servicio de nivel uno 204a y, por lo tanto, recibir una lista de toda la información del nodo publicada en el nivel uno 204a. El nodo 210n puede determinar que la publicación del nodo 210a es aceptable y seleccionar el nodo 210a. El nodo 210n puede realizar pruebas de latencia antes de seleccionar el nodo 210a para mitigar la posibilidad de comunicaciones de alta latencia. El nodo 210n puede entonces descargar la carga de trabajo al nodo 210a. Después de que el nodo 210a complete la carga de trabajo, el nodo 210n puede verificar que la carga de trabajo se ha ejecutado satisfactoriamente y, así, proporcionar tokens al nodo 210a.
En algunas realizaciones, el nodo 210n puede tener la opción de seleccionar nodos de cómputo de un país específico y/o nodos de cómputo con ciertas características de latencia. Se admiten múltiples redes P2P específicas de cada región. Por ejemplo, una red P2P para el oeste de Estados Unidos, el este de Estados Unidos, el este de Europa, la India, el Sudeste Asiático, etc. Esto no solo simplifica la selección de nodos de cómputo geopolíticamente próximos, sino que también permite cumplir requisitos específicos de tratamiento de datos como el Reglamento GDPR en la Unión Europea.
Los niveles de servicio 204a-204n pueden determinarse como sigue. Por ejemplo, los utilitarios de la red pueden ser predominantemente usuarios domésticos con equipos portátiles y de sobremesa. En algunos ejemplos, estos utilitarios pueden definirse como utilitarios de nivel dos 204b. Los proveedores de software y hardware de nivel empresarial y los operadores de centros de datos también pueden unirse a la arquitectura 300 para vender potencia de computación y almacenamiento. Los utilitarios empresariales pueden definirse como utilitarios de nivel uno 204a. Por último, los utilitarios de nivel N 204n pueden definirse como relacionados con la categoría de dispositivos móviles y de Internet de las cosas (IoT), que tienen menor capacidad de computación y de almacenamiento, pero aun así pueden ofrecer estos recursos a la red entre pares de la arquitectura 200.
El nivel dos 204b puede subdividirse, a su vez, en varias subcategorías que representan diferentes rangos de potencia de computación, tal como se muestra a continuación. Por ejemplo, T2.small puede representar cualquier equipo con hasta dos CPU, entre 2 y 4 GB de RAM, y con una velocidad de CPU de hasta 2 GHz. La estrategia de clasificación por niveles y subcategorización tiene en cuenta la futura incorporación de proveedores de nivel 1. Estos niveles de servicio 1 y 2204a, 204b se enumeran en la Tabla I a continuación. En algunas realizaciones, la Tabla I puede incluir proveedores de servicios de nivel N 204n.
Tabla I - cate orización de niveles de servicio en función de recursos com utacionales utilitarios
Figure imgf000006_0001
Un agente (por ejemplo, un agente de software, una aplicación y/u otro software) puede determinar la cantidad de CPU y RAM de un nodo de cómputo y determinar automáticamente el nivel al que pertenecen los recursos del nodo de cómputo. El agente también puede entonces localizar un nodo de gestión para ese nivel y listar el nodo de cómputo con el nodo de gestión para la venta de sus recursos computacionales. Los usuarios del nodo de cómputo tienen la opción de listar (o el nodo de cómputo puede hacerlo automáticamente) el periodo de tiempo durante el cual los recursos computacionales no deben ser utilizados por otros. Además, el nodo de cómputo puede proporcionar el precio (por ejemplo, en USD) por cada hora (u otro periodo de tiempo) para compartir sus recursos computacionales. Los nodos de cliente pueden cobrarse en incrementos de intervalos de N minutos (por ejemplo, 15 minutos) por la utilización de recursos utilitarios. Una vez que un nodo de cómputo es listado en un mercado para proporcionar servicios de cómputo, puede denominarse utilitario.
La FIGURA 3 ilustra una arquitectura de computación descentralizada 300 que incluye niveles P2P en la red P2P 302. Aspectos de la arquitectura 100 (FIGURA 1) y la arquitectura 200 (FIGURA 2), como el mercado 114 de Blockchain (y/o DLT) descentralizado P2P, nodos de cómputo de nivel 1 a nivel N 122a-122n, nodos de cliente 102a-102n y capa de IA 110 para recursos computacionales distribuidos (almacenamiento y computación), nodos 206a-206n, 208a-208n, 210a-210n, cadena de bloques, mercado de recursos computacionales descentralizados 212 y la capa de interfaz descentralizada de aplicaciones y clientes web 202, se muestran con más detalle en la arquitectura 300 de la FIGURA 3 . La arquitectura 300 puede implementarse fácilmente como parte de las arquitecturas 100 (FIGURA 1) y 200 (FIGURA 2) con componentes superpuestos que se incluyen unos dentro de otros.
En la red P2P 302, los recursos computacionales pueden ser compartidos utilizando una Blockchain y/o DLT (por ejemplo, Ethereum, IOTA, Corda, EOS, Hyperledger, etc.) para gestionar transacciones que involucran recursos computacionales. Los niveles P2P pueden determinarse en función de un mercado de recursos computacionales tal como se describe en el presente documento.
En algunas realizaciones, los elementos de la red P2P 302 incluyen:
1. Clientes: nodos de cliente 312, 316 que buscan recursos computacionales para ejecutar sus tareas y están dispuestos a pagar por dichos recursos;
2. Utilitario: nodos de cómputo 308a, 308b, 310a-310c que desean vender sus recursos computacionales sobrantes y almacenar recursos a cambio de una recompensa; y
3. Propietarios de mercados o bolsas de intercambio (exchanges): nodos de gestión seleccionados dinámicamente 304, 306 que facilitan el descubrimiento de utilitarios por parte de los clientes. Puede haber múltiples propietarios de mercados en la red según el rango de recursos computacionales y de almacenamiento que venden los utilitarios y para la participación favorable en esquemas de verificación y cumplimiento.
Cabe señalar que los nodos 304, 306, 308a, 308b, 310a- 310c, 312 pueden tener múltiples modos. Por ejemplo, cualquiera de los nodos 304, 306, 308a, 308b, 310a-310c, 312 puede tener un modo dual, donde puede funcionar como dos o más de un cliente, nodo P2P utilitario (por ejemplo, proveedor de recursos) y propietario de mercado.
Tal como se muestra en la FIGURA 3, para un ejemplo particular de un nivel de servicio, puede haber dos mercados para los recursos computacionales, que se identifican mediante el nodo de gestión 304 (por ejemplo, T2nano) y el nodo de gestión 306 (por ejemplo, T2large) en la red P2P 302. Los nodos de cómputo 310a-310c, 308a, 308b que venden recursos computacionales pueden listarse en uno de estos dos mercados a través del nodo de gestión 304, 306 apropiado. Por ejemplo, los nodos de cómputo 310a-310c, 308a, 308b pueden transmitir su disponibilidad de recursos a través de los nodos de gestión 304, 306.
De forma similar, los nodos de cliente 312, 316 que verifican búsquedas de recursos computacionales pueden identificar a un propietario de mercado apropiado de los nodos de gestión 306, 304 para un nivel de servicio deseado y obtener una lista de utilitarios de los nodos de gestión 304, 306 que pueden proporcionar ese servicio.
Puede ejemplo, puede haber tres subcategorías de recursos computacionales dentro de un nivel particular (por ejemplo, Nivel 2): 1) nano, 2) mediano y 3) grande. "Nano" puede denotar un recurso pequeño (por ejemplo, almacenamiento y procesamiento informático) que un utilitario puede ofrecer al mercado, "mediano" puede denotar un recurso mediano (por ejemplo, almacenamiento y procesamiento informático) que un utilitario puede ofrecer y "grande" puede denotar los grandes recursos (por ejemplo, almacenamiento y procesamiento informático) que puede ofrecer un utilitario.
Los nodos 304, 306, 308a, 308b, 310a-310c, 312 pueden tener direcciones Blockchain y/o DLT públicas. Los nodos 304, 306, 308a, 308b, 310a-310c, 312 pueden considerarse entidades racionales que participan para maximizar el valor que pueden generar a partir de la red P2P 302. En algunas realizaciones, pueden aplicarse principios de la teoría de juegos. Por otro lado, también puede haber algunos nodos maliciosos en la red y a continuación se exponen algunas formas a modo de ejemplo de minimizar su impacto en las operaciones de la red.
En algunas realizaciones, el plano de control 322 puede incluir un gestor de amenazas 324, que puede ser similar al gestor de amenazas 126, para identificar escenarios de modelos de amenazas y soluciones. Es decir, dado que algunas realizaciones incluyen un sistema total o sustancialmente descentralizado que no cuenta con una gestión centralizada crítica, puede haber varios escenarios en los que diferentes participantes podrían intentar manipular la arquitectura 300 en beneficio propio. El gestor de amenazas 324 puede identificar dichos escenarios clave y desarrollar soluciones técnicas para garantizar que el sistema global siga funcionando con un alto rendimiento y fidelidad.
Por ejemplo, en un ataque Eclipse, un atacante puede impedir la participación de un nodo individual en una red P2P. Tal ataque es posible, por ejemplo, si el atacante controla más del 50 % de los nodos de la red. De acuerdo con una realización a modo de ejemplo, la adición de una dirección IP junto con una dirección pública de Blockchain (por ejemplo, Ethereum) puede utilizarse para generar una identificación de red P2P para los nodos, tal como:
Red P2P Kad emlia id = hash (dirección pública de Ethereum, dirección IP, código de país)
Así, los riesgos asociados con un ataque Eclipse pueden mitigarse mediante la asignación de una ID como se describe anteriormente.
El ataque Sybil puede ser una versión extendida del ataque Eclipse en la que un atacante obtiene el control de la mayoría de los nodos 304, 306, 308a, 308b, 310a-310c, 312, 316 en la red P2P 302, degradando así reputación y el funcionamiento de la red P2P 302. De hecho, este ataque es un requisito previo para el éxito del ataque Eclipse. Una de las manifestaciones de un ataque Sybil en la arquitectura 300 es que un atacante puede controlar el mercado y los nodos de cómputo 310a-310c, 308a, 308b (por ejemplo, los utilitarios) y tomar el control de las computaciones de los clientes, recibiendo pagos por el trabajo de los nodos de cómputo 310a-310c, 308a, 308b sin realizar ningún trabajo real. Un nodo de cliente de los nodos de cliente 312, 316 que depende de un único nodo de cómputo de los nodos de cómputo 310a-310c, 308a, 308b o un conjunto de nodos de cómputo 310a-310c, 308a, 308b para realizar ese trabajo por ellos no tendrá forma de saber si la salida recibida es correcta o falsa.
Las soluciones técnicas y estrategias de mitigación descritas anteriormente para el ataque Eclipse pueden resultar útiles. También pueden emplearse varias otras técnicas que ayudarán a que los nodos "buenos" de los nodos de gestión, computación y cliente 304, 306, 308a, 308b, 310a-310c, 312, 316 en la red P2P 302 a poder minimizar el impacto de un ataque Sybil. Estas técnicas giran en torno a la gestión de la reputación y la verificación cruzada de los resultados de la computación. Por lo tanto, algunas realizaciones pueden mantener los detalles de gestión y verificar los resultados de la computación para protegerse contra los ataques Sybil.
En algunos ataques, utilitarios codiciosos pueden presentar una oferta de bajo coste para las tareas, pero luego proporcionar un servicio de baja calidad a los nodos de cliente 312, 316. Es posible que los nodos de cliente 312, 316 no sepan inmediatamente que utilitarios codiciosos están proporcionando computaciones inconsistentes o de baja calidad para las tareas que le fueron encomendadas. Esta puede ser una forma de ataque Sybil, aunque a pequeña escala, en la que hay utilitarios codiciosos que quieren obtener una compensación por las tareas sin completarlas realmente. Las técnicas propuestas para hacer frente a los ataques Sybil también ayudarán tanto a evitar que estos utilitarios codiciosos ganen el proceso de subasta como a detectar resultados en los que estos utilitarios codiciosos no realizaron la computación necesaria.
En algunas realizaciones, puede haber propietarios de mercado maliciosos (por ejemplo, nodos de gestión). En este escenario de ataque, se aborda el impacto de la presencia de propietarios de mercados maliciosos en la red P2P 302. En este escenario, los posibles tipos de ataque incluyen a) colusión con nodos de cómputo maliciosos (por ejemplo, utilitarios) e inhibición de la participación de los nodos buenos en el proceso de subasta; y b) no almacenar y/o no compartir información con los nodos de cliente 312, 316 con el fin de reducir la utilidad general del sistema. Los siguientes problemas pueden abordarse de la siguiente manera como parte de la solución y pueden implementarse y/o propagarse a través del gestor de amenazas 324:
1) Construir una reputación para los propietarios de mercado, de forma similar a como se construye una reputación para los nodos de cómputo 308a, 308b, 310a-310c (tal como se describe en el presente documento); 2) Rotar a los propietarios de mercado para cada nivel de servicio. Como se explicará, la arquitectura 300 utiliza el número de semana del año para calcular el valor hash del Nivel 1 para los valores de entrada. Por lo tanto, incluso para el mismo nivel, los nodos de cómputo 308a, 308b, 310a-310c vuelven a listarse cada semana utilizando un nuevo nodo de gestión que puede seleccionarse de la red P2P 302. Los nodos de cliente 312, 316 pueden ser capaces de encontrar nuevos nodos de gestión, ya que también mantienen actualizado el hash que utilizan para realizar la búsqueda. Cabe señalar que, en algunas realizaciones, la presente arquitectura 300 siempre puede basarse en el Tiempo Universal Coordinado (UTC). Por lo tanto, puede que no sea necesario sincronizar globalmente los relojes a través de la red P2P 302. Si un nodo de cliente de los nodos de cliente 312, 316 realiza una búsqueda de un nodo de gestión desde los nodos de gestión 304, 306 para un nivel y no recibe información sobre el nodo de cómputo, la arquitectura 300 puede reintentar automáticamente un nuevo nodo de gestión aumentando el número de semanas en 1. Es decir, para garantizar la resiliencia, algunas realizaciones también pueden admitir tener múltiples nodos de red que actúen como copropietarios de un mercado, ya sea en un modo activo-activo o activo-pasivo. Los nodos que acuerdan actuar como propietarios del mercado forman una red entre pares utilizando protocolos como Chord o Kademlia, y determinan el propietario exacto del mercado de un valor de recurso de cómputo generando un hash y buscando ese valor hash.
3) Puede haber propietarios de mercado redundantes (nodos de gestión) para cada nivel. Los nodos de gestión redundantes pueden ser vecinos sucesores directos del nodo de gestión designado. Así, por ejemplo, suponiendo que el nodo de gestión 306 es el propietario del mercado del Nivel 1, entonces los nodos de cómputo 310a-310c también pueden listarse a sí mismos en el nodo sucesor directo, que es el Nodo 2. Cuando el nodo de cliente 310 obtiene la lista de nodos de cómputo 310a-310c del nodo de gestión 306 también puede ponerse en contacto con el Nodo 2 y obtener la lista de nodos de cómputo 310a-310c. Si los dos conjuntos de datos varían significativamente, incluso después de ponerse en contacto con los nodos de cómputo 310a-310c, entonces el nodo de cliente 312 puede omitir el pago al nodo de gestión 306 y también difundir una mala reputación del nodo de gestión 306.
En algunas realizaciones, un cliente de precarga puede conectarse a la arquitectura 300. Es decir, los nodos de cliente 312, 316 también pueden hacer un mal uso de los recursos en la red P2P 302 haciendo que sus tareas sean ejecutadas por los nodos de cómputo 308a, 308b, 310a-310c, pero sin marcar los pagos a los nodos de cómputo 308a, 308b, 310a-310c y los nodos de gestión 304, 306. Esto se resuelve utilizando Blockchain y/o DLT como depósito en garantía y haciendo cumplir las transacciones mediante un contrato inteligente.
En algunas realizaciones, una de las técnicas de verificación de resultados empleadas es asegurarse de que los nodos de cómputo no devuelvan "resultados basura" a los nodos de cliente (por ejemplo, inyección de troyanos). Para mitigar esto, algunas realizaciones pueden incluir el paso de inyectar automáticamente un valor de salida conocido y un valor verificable en el cómputo del cliente. Cuando se completa una tarea, los resultados de salida del nodo de cómputo deben tener este valor conocido incluido en los resultados de salida. Las tareas de Docker relacionadas con el alojamiento web también pueden aceptar una "URL de control de estado" que se puede verificar continuamente para asegurarse de que el nodo de cómputo aloja el sitio web (o servicio web) que se espera que aloje el nodo de cómputo. Si falta el valor conocido, entonces la arquitectura 300 puede determinar que un nodo de cómputo no ha procesado la tarea según las especificaciones del nodo de cliente y, por lo tanto, no se le debe pagar.
La FIGURA 4 muestra un procedimiento 400 para ejecutar una operación de unión de nodos. El procedimiento 400 generalmente puede ser implementado mediante un dispositivo de computación y operado en conjunción con cualquiera de las realizaciones descritas en el presente documento, por ejemplo, la arquitectura 100 (FIGURA 1), la arquitectura 200 (FIGURA 2) y la arquitectura 300 (FIGURA 3) que han sido expuestas. En una realización, el procedimiento 400 se implementa en uno o más módulos como un conjunto de instrucciones lógicas almacenadas en un medio de almacenamiento legible por máquina u ordenador, tal como memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM), ROM programable (PROM), firmware, memoria flash, etc., en lógica configurable como, por ejemplo, matrices lógicas programables (PLA), matrices de compuertas programables en campo (FPGA), dispositivos lógicos programables complejos (CPLD), en hardware de lógica de funcionalidad fija utilizando tecnología de circuitos como, por ejemplo, circuito integrado de aplicaciones específicas (ASIC), semiconductor complementario de óxido metálico (CMOS) o tecnología de lógica transistor-transistor (TTL), o cualquier combinación de los mismos.
Por ejemplo, el código de programa informático para llevar a cabo las operaciones que se muestran en el procedimiento 400 puede estar escrito en cualquier combinación de uno o más lenguajes de programación, incluyendo lenguajes de programación orientados a objetos como JAVA, SMALLTALK, C++ o similares, así como lenguajes de programación convencionales, como el lenguaje de programación "C" o similares. Además, las instrucciones lógicas pueden incluir instrucciones de ensamblaje, instrucciones de arquitectura de conjunto de instrucciones (ISA), instrucciones de máquina, instrucciones dependientes de máquina, microcódigo, datos de establecimiento de estado, datos de configuración para circuitos integrados, información de estado personalizada para circuitos electrónicos y/u otros componentes estructurales inherentes al hardware (por ejemplo, procesador anfitrión, unidad central de procesamiento/CPU, microcontrolador, etc.).
En el bloque de procesamiento 402 ilustrado un nodo de cómputo se une a una red (por ejemplo, una red P2P). El bloque de procesamiento 402 puede incluir la generación de una identificación (ID) de red P2P que se genera de la siguiente manera: ID de red p2p = hash (dirección pública de Blockchain y/o DLP, dirección IP, código de país). En algunas realizaciones, el bloque de procesamiento 402 determina una lista de nodos publicados que ayudan a nuevos nodos a unirse a la red. De manera alternativa, o simultáneamente, puede proporcionarse una API para devolver una lista de nodos de una Blockchain que devuelva una lista aleatoria de nodos verificados que ya forman parte de la red P2P.
En algunas realizaciones, los datos utilizados para generar la ID de la red P2P pueden proporcionarse a través de un servicio de directorio que la red puede proporcionar para permitir que nuevos usuarios se unan a la red P2P. De manera alternativa, estos datos pueden distribuirse permitiendo a los nuevos usuarios consultar la Blockchain directamente para recuperar la lista de usuarios que son parte potencial de la red P2P.
En este ejemplo particular, el nodo que se une a la red es un nodo de cómputo. Por lo tanto, el nodo de cómputo (por ejemplo, un trabajador y/o utilitario) selecciona el nivel de servicio 404 que puede proporcionar el nodo de cómputo. Esto puede basarse en la potencia de procesamiento (por ejemplo, varias CPU, tipos de CPU, varias GPU, tipos de GPU) y el almacenamiento disponible (por ejemplo, RAM, almacenamiento a largo plazo, tal como unidades de estado sólido y/o unidades de disco duro, etc.).
El bloque de procesamiento 406 ilustrado determina si los requisitos de recursos seleccionados para el nivel cumplen con el registro histórico del nodo de cómputo. Por ejemplo, es posible que el nodo de cómputo necesite tener una utilización de CPU y/o GPU de menos del 50 % en la última hora para poder optar a la venta de recursos computacionales. Es decir, el uso histórico de recursos (por ejemplo, la cantidad disponible de recursos) del nodo de cómputo debe cumplir con los requisitos mínimos (por ejemplo, la cantidad mínima de recursos que se van a vender) del nivel. Dependiendo de la aplicación, el tiempo, etc., pueden adoptarse otros umbrales. Además, puede haber diferentes definiciones de niveles para diferentes clases de recursos computacionales. Si no se cumplen los requisitos de recursos, el bloque de procesamiento 404 ilustrado se ejecuta para seleccionar otro nivel de servicio.
Si se cumplen los requisitos de recursos, el bloque de procesamiento 408 ilustrado genera una ID de red de nodo de gestión basándose en el nivel de servicios. Por ejemplo, el nodo de cómputo puede generar una ID de red P2P de nodo de gestión para el nodo de gestión del nivel de servicio que será proporcionado por ese nodo de cómputo. La ID de red de nodo de gestión puede identificar al propietario del mercado del nivel. En algunas realizaciones, para garantizar que un solo propietario de mercado no monopolice un determinado nivel de servicio (reduciendo así la probabilidad de ataques maliciosos y/o de control centralizado), también puede añadirse un número aleatorio (por ejemplo, el número de semana) a la función hash. La ID de red P2P del propietario del mercado puede identificarse de la siguiente manera "hash (vCPU, RAM, número de semana)".
El bloque de procesamiento 410 ilustrado notifica al nodo de gestión la adición del nodo de cómputo y cualquier característica relevante del nodo de cómputo (por ejemplo, recursos disponibles, solicitudes de precios, etc.). Por ejemplo, el nodo de cómputo puede registrarse con el nodo de gestión. La información de registro puede estar en forma de tupla (por ejemplo, dirección IP, intervalo de tiempo de disponibilidad, recursos disponibles, etc.). Una copia de este registro también puede almacenarse en una Blockchain y/o DLT con fines de auditoría.
La FIGURA 5 ilustra un procedimiento 500 para añadir un nodo de cliente a la red. El procedimiento 500 generalmente puede implementarse en conjunción con cualquiera de las realizaciones descritas en el presente documento, como, por ejemplo, la arquitectura 100 (FIGURA 1), la arquitectura 200 (FIGURA 2), la arquitectura 300 (FIGURA 3) y el procedimiento 400 (FIGURA 4) que ya se han expuesto. Más particularmente, el procedimiento 500 puede implementarse en uno o más módulos como un conjunto de instrucciones lógicas almacenadas en un medio de almacenamiento legible por máquina u ordenador, como RAM, ROM, PROM, firmware, memoria flash, etc., en lógica configurable. como, por ejemplo, PLA, FPGA, CPLD, en hardware de lógica de funcionalidad fija utilizando tecnología de circuitos como, por ejemplo, tecnología ASIC, CMOS o TTL, o cualquier otra combinación.
El bloque de procesamiento 502 ilustrado conecta un nodo de cliente a una red e identifica un nodo de gestión para un nivel de servicio deseado. Por ejemplo, un usuario de un nodo de cliente puede especificar el nivel del servicio requerida para su tarea, que se especifica como una imagen de Docker. Según el nivel seleccionado, los nodos de cliente pueden buscar al propietario del mercado correspondiente (por ejemplo, el nodo de gestión). El proceso de búsqueda puede ser similar o idéntico al proceso de búsqueda del nodo de cómputo descrito anteriormente en el procedimiento 400.
En el bloque de procesamiento 504 ilustrado, el nodo de cliente puede ponerse en contacto con el nodo de gestión y recibir una lista de todos los nodos de cómputo del nodo de gestión. En el bloque de procesamiento 506 ilustrado, el nodo de cliente puede entonces realizar una subasta. Durante esta subasta, el nodo de cliente puede comunicarse con todos los nodos de cómputo para obtener información sobre precios. Puede utilizarse una granularidad (por ejemplo, quince minutos) para recibir respuestas especificando el precio de ejecución (el periodo de tiempo en que la subasta está abierta). Las respuestas también pueden utilizarse como verificación de que los nodos de cómputo aún pueden compartir sus recursos computacionales.
En el bloque de procesamiento 508 ilustrado, el nodo de cliente mide las latencias de todos los nodos de cómputo que proporcionaron respuestas. Todos los nodos de cómputo que tengan una latencia superior a un umbral especificado (por ejemplo, un valor predeterminado de 5 segundos) pueden ser descartados. En algunas realizaciones, la latencia se mide como el tiempo que tarda un mensaje del nodo de cómputo al nodo de cliente en llegar al nodo de cliente. En el bloque de procesamiento 510 ilustrado, al recibir las ofertas de precios de los nodos de utilitarios y/o el análisis de latencia, el nodo de cliente puede seleccionar uno o más nodos de cómputo de los nodos de cómputo con la oferta más baja que cumplan con el umbral de latencia. En algunas realizaciones, el nodo de cliente puede seleccionar un nodo de cómputo más caro si la latencia está por debajo de un umbral de velocidad que indica que el nodo de cliente es preferible a nodos de cómputo más económicos.
El bloque de procesamiento 512 ilustrado envía una imagen para su ejecución al uno o más nodos de cómputo seleccionados. Es decir, el nodo de cliente puede comunicarse con uno o más nodos de cómputo y enviar una imagen de Docker para que se ejecute. En el bloque de procesamiento 514 ilustrado, el nodo de cliente recibe los resultados de las computaciones realizadas por uno o más nodos de cómputo. Por ejemplo, los resultados de las computaciones de uno o más nodos de cómputo se devuelven al nodo de cliente y se almacenan en un directorio predeterminado o a través de una devolución de llamada a un identificador de recursos uniforme (URI).
El bloque de procesamiento 516 ilustrado proporciona pagos. En algunas realizaciones, el precio que paga el nodo de cliente puede ser el segundo precio más bajo de todas las ofertas de los nodos de cómputo, como se describe en una subasta Vickrey. Esta forma de mecanismo de subasta puede garantizar que la mejor estrategia de oferta de un nodo de cómputo sea compartir honestamente el coste del suministro recursos computacionales. Los detalles de la subasta también pueden registrarse en Blockchain. En algunas realizaciones, el nodo de cliente también puede pagar al nodo de gestión. El monto del pago al nodo de gestión será la diferencia en el monto entre la oferta más baja (la oferta proporcionada por uno o más nodos de cómputo) y la segunda oferta más baja.
Por ejemplo, en una subasta Vickrey, decir la verdad es la mejor estrategia para que los nodos de cómputo ofrezcan una puja sobre su coste de suministro de recursos computacionales. Los nodos de cómputo pueden ser seleccionados en función del coste más bajo, pero la compensación que reciben es el segundo coste más bajo listado en el mismo mercado. Algunas realizaciones pueden ampliar aún más el protocolo de subasta Vickrey para tener en cuenta que se pueden seleccionar múltiples ganadores al final de la subasta debido a la necesidad de que los archivos sean fragmentados y replicados y, por lo tanto, almacenados en múltiples mineros. Además, algunas realizaciones pueden tener en cuenta múltiples escenarios de fallo que resultan del hecho de que todos los participantes en la subasta estén en línea y no se conozcan entre sí.
El procedimiento 500 puede ser gestionado en su totalidad por un contrato inteligente.
La FIGURA 6 ilustra la sección de ajustes de procesamiento 600 en una aplicación (u otro software) que permite a los utilitarios configurar valores para vender sus recursos. Tal como se muestra, un usuario y/o un nodo de cómputo pueden establecer parámetros 606. Los parámetros 606 pueden incluir un tamaño de espacio en disco 604 que está disponible para su uso por parte de los nodos de cliente, y una configuración de nivel 602 que la aplicación puede definir automáticamente basándose en las entradas del usuario y la configuración del nodo de cómputo.
La FIGURA 7 ilustra una interfaz gráfica de usuario 700 que permite a un usuario y/o nodo de cliente adquirir recursos computacionales de nodos de cómputo de una red para la ejecución distribuida de tareas. La interfaz gráfica de usuario 700 ilustra cómo los clientes pueden configurar los requisitos para el nivel de capacidad de computación que se requiere para ejecutar sus tareas. Por ejemplo, después de que el nodo de cliente haya especificado los requisitos de la tarea 702 para el nodo de cliente y haya especificado la imagen de Docker 704 para que se ejecute, un agente de software puede comunicarse con el nodo de gestión para el nivel y obtener una lista de utilitarios disponibles (nodos de cómputo). Tal como se muestra en la FIGURA 8, los detalles del utilitario y las opciones para seleccionar uno pueden proporcionarse al usuario del nodo de cliente.
Por ejemplo, la interfaz gráfica de usuario 800 lista los recursos utilitarios 802 proporcionados al mercado. Si un usuario no selecciona uno de los recursos utilitarios 802, entonces el agente también puede configurarse para seleccionar automáticamente un recurso utilitario de los recursos utilitarios 804 con el coste más bajo posible siempre que la latencia para el utilitario asociado de una prueba de latencia esté por debajo una cantidad predeterminada. En algunas realizaciones, el nodo de cliente puede configurar un directorio donde se almacenan los resultados de la prueba. Una vez que los resultados del cómputo están disponibles, el usuario puede recibir un correo electrónico confirmando que el trabajo ha sido completado. Además, la aplicación puede proporcionar una notificación para las mismas acciones.
La FIGURA 9 ilustra una configuración de cliente y una interfaz de desarrollador abierta 900 que utiliza API REST 910. Un mercado puede integrarse en una aplicación que también permite a los usuarios vender y comprar capacidad de almacenamiento. La misma capacidad puede proporcionarse a través de las API REST 910 para vender, comprar y administrar recursos computacionales. Una plataforma abierta de este tipo permitirá a los desarrolladores crear aplicaciones nuevas e innovadoras para aprovechar recursos computacionales masivos, económicos y de fácil acceso. Tal como se ilustra, la interfaz 900 puede incluir aplicaciones electrónicas 902, una interfaz usuario-web 908, servicios web de nodo 904 y un motor de Docker 906.
A continuación, se muestra un pseudocódigo para implementar las API Rest 910:
Figure imgf000011_0001
Una tarea puede ser gestionada para un cliente empaquetada como un contenedor individual en el motor de Docker 906. Existen múltiples cargas de trabajo que requieren un conjunto de tareas interdependientes que pueden necesitar ser ejecutadas secuencialmente a través de algunas operaciones paralelas intermedias. Se proporciona un sistema de gestión de flujo de trabajo general, que los clientes pueden utilizar para definir y enviar un flujo de trabajo de tareas. A su vez, el sistema de gestión del flujo de trabajo puede programar, gestionar y optimizar automáticamente la ejecución de todas las tareas para proporcionar la mejor fiabilidad, rendimiento y rentabilidad para completar todas las tareas necesarias.
La FIGURA 10 ilustra un procedimiento 1000 para la gestión de reputaciones. El procedimiento 1000' puede implementarse generalmente en conjunción con cualquiera de las realizaciones descritas en el presente documento, como, por ejemplo, la arquitectura 100 (FIGURA 1), la arquitectura 200 (FIGURA 2), la arquitectura 300 (FIGURA 3), el procedimiento 400 (FIGURA 4) y el procedimiento 500 (FIGURA 5) ya expuestos. Más particularmente, el procedimiento 1000 puede implementarse en uno o más módulos como un conjunto de instrucciones lógicas almacenadas en un medio de almacenamiento legible por máquina u ordenador, como RAM, ROM, PROM, firmware, memoria flash, etc., en lógica configurable. como, por ejemplo, PLA, FPGA, CPLD, en hardware de lógica de funcionalidad fija utilizando tecnología de circuitos como, por ejemplo, tecnología ASIC, CMOS o TTL, o cualquier combinación de los mismos.
De acuerdo con algunas realizaciones, el uso de la innovadora gestión de la reputación y la ingeniería de incentivos permite que el sistema sea autosuficiente. Los nodos de cómputo, los nodos de gestión y los nodos de cliente maliciosos o defectuosos, como se describe en la sección anterior, pueden ser descartados de las arquitecturas basándose en puntuaciones de reputación bajas.
Cada nodo de la red puede tener una copia de la reputación de cada otro nodo. La reputación puede ser una representación agregada de la experiencia directa de ese nodo trabajando con los otros nodos, y también los mensajes de difusión de reputación que han sido recibidos por ese nodo. Esta reputación puede ser calculada para cada otro nodo, ya sea un nodo de utilitario, propietario del mercado o cliente.
De acuerdo con una realización a modo de ejemplo, la gestión de la reputación puede realizarse de la siguiente manera. En el bloque de procesamiento 1002 ilustrado, un nodo de cómputo puede completar una transacción. En el bloque de procesamiento 1004 ilustrado, después de completar con éxito la transacción, el nodo de cómputo puede generar un certificado de finalización. El bloque de procesamiento 1006 ilustrado difunde el certificado de finalización a todos los demás nodos conocidos por el nodo de cómputo en la red. El certificado de finalización puede contener un puntero hash a un bloque de cadena de bloques que registra la transacción de pago del nodo de cliente al nodo de cómputo. Después de que los otros nodos reciban el certificado de finalización, la reputación del nodo de cómputo se calcula de la siguiente manera:
nueva reputación de utilitario = f (antigua reputación de utilitario * reputación de cliente)
o 1 si cualquiera de estos dos valores es 0
Ecuación 1
Para el mismo par de nodos de cómputo y cliente, la reputación aumenta como máximo una vez a la semana.
a reputación puede estar asociada con la ID de la red P2P de un nodo, lo que, a su vez, significa que está asociada con la dirección pública de la cadena de bloques. Además, la reputación puede ser un número entero que aumenta monótonamente. Cuanto mayor sea el valor, mayor será la reputación, siendo cero la peor. Un valor de cero también significa que se desconoce la reputación de un nodo. La peor reputación y la reputación desconocida pueden tratarse indistintamente, ya que un nodo malicioso siempre puede regenerar su ID de red P2P y volver a unirse a la red como un nodo desconocido.
La FIGURA 11 ilustra un procedimiento de actualización de reputaciones. El bloque de procesamiento 1102 ilustrado recibe un certificado de finalización. El bloque de procesamiento 1104 ilustrado calcula una puntuación de reputación para un nodo asociado al certificado de finalización. El bloque de procesamiento 1106 ilustrado determina si se recibe un nuevo certificado de finalización para un nodo dentro de un límite de tiempo. Por ejemplo, la reputación de un nodo puede ser una función decreciente del tiempo. Así, si un utilitario no presta un servicio, se degrada gradualmente con el tiempo. Si no se recibe un nuevo certificado, el bloque de procesamiento 1108 ilustrado puede degradar la reputación de la siguiente manera:
nueva reputación = calificaciones de los últimos 30 días * a calificaciones anteriores * (1 - a),
Ecuación 2
En la ecuación anterior, a controla el coeficiente de ponderación asignado a las calificaciones más nuevas. Tal como se ha descrito, la reputación de los nodos puede formar parte de la determinación del momento en que los nodos deciden ofrecer y/o recibir servicios.
Las realizaciones son aplicables para su uso con todos los tipos de chips semiconductores de circuitos integrados ("IC"). Ejemplos de estos chips IC incluyen, entre otros, procesadores, controladores, componentes de conjuntos de chips, matrices lógicas programabas (PLA), chips de memoria, chips de red, sistemas en chip (SoC), ASIC de controladores SSD/NAND y similares. Además, en algunas de las figuras, los conductores de señales se representan con líneas. Algunos pueden ser diferentes, para indicar más rutas de señales constituyentes, pueden incluir etiquetas numéricas para indicar múltiples rutas de señales constituyentes y/o flechas en uno o más extremos para indicar la dirección del flujo de información principal. Sin embargo, esto no debe interpretarse de manera limitativa. Más bien, tales detalles añadidos pueden ser utilizados en conjunción con una o más realizaciones a modo de ejemplo para facilitar la sencilla comprensión de un circuito. De hecho, cualquier línea de señal representada, con o sin información adicional, puede comprender una o más señales que pueden transmitirse en múltiples direcciones y puede implementarse con cualquier tipo adecuado de esquema de señal, por ejemplo, líneas digitales o analógicas implementadas con pares diferenciales, líneas de fibra óptica y/o líneas unipolares.
Aunque las realizaciones no se limitan a esto, pueden proporcionar ejemplos de tamaños/modelos/valores/rangos. A medida que las técnicas de fabricación (por ejemplo, la fotolitografía) se vuelven más sofisticadas, se prevé que puedan fabricarse dispositivos de menor tamaño. Además, para simplificar la ilustración y el análisis, y para que ciertos aspectos de las realizaciones no adolezcan de falta de claridad, las conexiones convencionales de alimentación/tierra a los chips IC y a otros componentes pueden o no mostrarse en las figuras. Además, las disposiciones pueden mostrarse en forma de diagrama de bloques para evitar que las realizaciones resulten confusas, y también en vista del hecho de que los detalles con respecto a la implementación de tales disposiciones de diagramas de bloques dependen en gran medida del sistema informático dentro del cual se implementa la realización, es decir, dichos detalles deben estar dentro del alcance del experto en la materia. Cuando se establecen detalles específicos (por ejemplo, circuitos) para describir realizaciones de ejemplo, debe ser evidente para el experto en la materia que las realizaciones pueden implementarse sin estos detalles específicos o con variaciones de los mismos. En consecuencia, la descripción debe considerarse ilustrativa y no limitativa.
El término "acoplado" puede utilizarse en el presente documento para referirse a cualquier tipo de relación, directa o indirecta, entre los componentes descritos, y puede aplicarse a conexiones eléctricas, mecánicas, de fluidos, ópticas, electromagnéticas, electromecánicas u otras. Además, los términos "primero", "segundo", etc. se utilizan en el presente documento solo para facilitar el análisis y no tienen un significado temporal o cronológico particular, a menos que se indique lo contrario.
Tal como se utiliza en la presente solicitud y en las reivindicaciones, una lista de elementos unidos por el término "uno o más de" puede significar cualquier combinación de los términos enumerados. Por ejemplo, la frase "uno o más de A, B o C" puede denotar A; B; C; A y B; A y C; B y C; o A, B y C.

Claims (15)

REIVINDICACIONES
1. Red entre pares (302) que comprende:
un nodo de gestión (304, 306) que está configurado para generar una lista de una pluralidad de nodos de cómputo (308a, 308b, 310a-310c) que están dentro de un nivel;
un primer nodo de cómputo (308a, 310a) configurado para proporcionar recursos computacionales para que los utilicen otros nodos (308b, 310b, 310c), estando configurado el primer nodo de cómputo (308a, 310a), además, para llevar a cabo una determinación de que el primer nodo de cómputo (308a, 310c) 310a) está dentro del nivel, basándose al menos en parte en los recursos computacionales y configurado para enviar una notificación al nodo de gestión (304, 306) con el fin de agregar el primer nodo de cómputo (308a, 310a) a la lista en función de la determinación; y
un nodo de cliente (312, 316) configurado para realizar una identificación del nivel basándose en una capacidad de cómputo que se prevé utilizar para ejecutar una o más tareas asociadas al nodo de cliente (312, 316), configurado para identificar el nodo de gestión (304, 306) en función de la identificación y configurado para solicitar la lista al nodo de gestión (304, 306).
2. Red según la reivindicación 1, en la que los recursos computacionales incluyen una o más unidades de procesamiento central disponibles y una memoria disponible; o en la que el nodo de gestión (304, 306) está configurado para transmitir la lista al nodo de cliente (312, 316).
3. Red según la reivindicación 1, en la que el nodo de cliente (312, 316) está configurado para identificar un nodo de menor coste de entre la pluralidad de nodos de cómputo (308a, 308b, 310a-310c).
4. Red según la reivindicación 3, en la que el nodo de cliente (312, 316) está configurado para ejecutar una prueba de latencia con el fin de determinar una latencia entre el nodo de cliente (312, 316) y el nodo de menor coste, preferiblemente en la que el nodo de cliente (312, 316):
está configurado para determinar que la latencia es superior a un valor umbral; y
en respuesta a que la latencia esté por encima del valor umbral, está configurado para determinar que la una o más tareas deben descargarse al primer nodo de cómputo (308a, 310a) para su ejecución.
5. Red según la reivindicación 1, en la que el primer nodo de cómputo (308a, 310a) está configurado para determinar un coste de utilización de los recursos computacionales sobre la base de al menos un coste de la electricidad y de una entrada del usuario; o en la que el primer nodo de cómputo (308a, 310a) transmite una identificación de los recursos computacionales al nodo de gestión (304, 306).
6. Al menos un medio de almacenamiento legible por ordenador que comprende un conjunto de instrucciones, que cuando son ejecutadas por una pluralidad de dispositivos informáticos, permiten a la pluralidad de dispositivos informáticos:
generar, mediante un nodo de gestión (304, 306), una lista de una pluralidad de nodos de cómputo (308a, 308b, 310a-310c) que están dentro de un nivel;
proporcionar, mediante un primer nodo de cómputo (308a, 310a), recursos computacionales para que los utilicen otros nodos;
realizar, mediante el primer nodo de cómputo (308a, 310a), una determinación de que el primer nodo de cómputo (308a, 310a) está dentro del nivel basándose al menos en parte en los recursos computacionales;
enviar, mediante el primer nodo de cómputo (308a, 310a), una notificación al nodo de gestión (304, 306) para agregar el primer nodo de cómputo (308a, 310a) a la lista en función de la determinación;
realizar, mediante un nodo de cliente (312, 316), una identificación del nivel basándose en una capacidad de cómputo que se prevé utilizar para ejecutar una o más tareas asociadas al nodo de cliente (312, 316); identificar, mediante el nodo de cliente (312, 316), el nodo de gestión (304, 306) en función de la identificación; y solicitar, mediante el nodo de cliente (312, 316), la lista al nodo de gestión (304, 306).
7. Al menos un medio de almacenamiento legible por ordenador según la reivindicación 6, en el que los recursos computacionales incluyen una o más unidades de procesamiento central disponibles y una memoria disponible; o en el que las instrucciones, cuando se ejecutan, hacen que la pluralidad de dispositivos informáticos transmita, mediante el nodo de gestión (304, 306), la lista al nodo de cliente (312, 316).
8. Al menos un medio de almacenamiento legible por ordenador según la reivindicación 6, en el que las instrucciones, cuando se ejecutan, hacen que la pluralidad de dispositivos informáticos identifique, mediante el nodo de cliente (312, 316), un nodo de menor coste de entre la pluralidad de nodos de cómputo (308a, 308b, 310a-310c).
9. Al menos un medio de almacenamiento legible por ordenador según la reivindicación 8, en el que las instrucciones, cuando se ejecutan, permiten que la pluralidad de dispositivos informáticos ejecute, mediante el nodo de cliente (312, 316), una prueba de latencia con el fin de determinar una latencia entre el nodo de cliente (312, 316) y el nodo de menor coste,
preferiblemente en el que las instrucciones, cuando se ejecutan, permiten a la pluralidad de dispositivos informáticos: determinar, mediante el nodo de cliente (312, 316), que la latencia es superior a un valor umbral; y
en respuesta a que la latencia esté por encima del valor umbral, determinar, mediante el nodo de cliente (312, 316), que una o más tareas deben descargarse al primer nodo de cómputo (308a, 310a) para su ejecución.
10. Al menos un medio de almacenamiento legible por ordenador según la reivindicación 6, en el que las instrucciones, cuando se ejecutan, permiten a la pluralidad de dispositivos informáticos:
determinar, mediante el primer nodo de cómputo (308a, 310a), un coste de utilización de los recursos computacionales sobre la base de al menos en un coste de la electricidad y de una entrada del usuario; o en el que las instrucciones, cuando se ejecutan, hacen que la pluralidad de dispositivos informáticos transmita, mediante el primer nodo de cómputo (308a, 310a), una identificación de los recursos computacionales al nodo de gestión (304, 306).
11. Procedimiento que comprende:
generar, mediante un nodo de gestión (304, 306), una lista de una pluralidad de nodos de cómputo (308a, 308b, 310a-310c) que están dentro de un nivel;
proporcionar, mediante un primer nodo de cómputo (308a, 310a), recursos computaciones para que los utilicen otros nodos;
realizar, mediante el primer nodo de cómputo (308a, 310a), una determinación de que el primer nodo de cómputo (308a, 310a) está dentro del nivel basándose al menos en parte en los recursos computacionales;
enviar, mediante el primer nodo de cómputo (308a, 310a), una notificación al nodo de gestión (304, 306) para agregar el primer nodo de cómputo (308a, 310a) a la lista en función de la determinación;
realizar, mediante un nodo de cliente (312, 316), una identificación del nivel basándose en una capacidad de cómputo que se prevé utilizar para ejecutar una o más tareas asociadas al nodo de cliente (312, 316); identificar, mediante el nodo de cliente (312, 316), el nodo de gestión (304, 306) en función de la identificación; y solicitar, mediante el nodo de cliente (312, 316), la lista al nodo de gestión (304, 306).
12. Procedimiento según la reivindicación 11, en el que los recursos computacionales incluyen una o más unidades de procesamiento central disponibles y una memoria disponible; o que comprende, además, transmitir, mediante el nodo de gestión (304, 306), la lista al nodo de cliente.
13. Procedimiento según la reivindicación 11, que comprende, además, identificar, mediante el nodo de cliente (312, 316), un nodo de menor coste de entre la pluralidad de nodos de cómputo (308a, 308b, 310a-310c).
14. Procedimiento según la reivindicación 13, que comprende, además, ejecutar, mediante el nodo de cliente (312, 316), una prueba de latencia con el fin de determinar una latencia entre el nodo de cliente (312, 316) y el nodo de menor coste,
preferiblemente que comprende, además:
determinar, mediante el nodo de cliente (312, 316), que la latencia es superior a un valor umbral; y
en respuesta a que la latencia esté por encima del valor umbral, determinar, mediante el nodo de cliente (312, 316), que una o más tareas deben descargarse al primer nodo de cómputo (308a, 310a) para su ejecución.
15. Procedimiento según la reivindicación 11, que comprende, además:
determinar, mediante el primer nodo de cómputo (308a, 310a), un coste de utilización de los recursos computacionales sobre la base de al menos un coste de la electricidad y una entrada del usuario; o
que comprende, además, transmitir, mediante el primer nodo de cómputo (308a, 310a), una identificación de los recursos computacionales al nodo de gestión (304, 306).
ES19850790T 2018-11-08 2019-11-07 Mercado inteligente, descentralizado y autónomo para computación y almacenamiento distribuidos Active ES2954424T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862757327P 2018-11-08 2018-11-08
PCT/IB2019/001212 WO2020099924A1 (en) 2018-11-08 2019-11-07 Intelligent, decentralized and autonomous marketplace for distributed computing and storage

Publications (1)

Publication Number Publication Date
ES2954424T3 true ES2954424T3 (es) 2023-11-22

Family

ID=69582142

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19850790T Active ES2954424T3 (es) 2018-11-08 2019-11-07 Mercado inteligente, descentralizado y autónomo para computación y almacenamiento distribuidos

Country Status (11)

Country Link
US (1) US11799954B2 (es)
EP (1) EP3878161B1 (es)
JP (1) JP7393426B2 (es)
KR (1) KR20210096619A (es)
CN (1) CN112997469B (es)
AU (1) AU2019380719A1 (es)
CA (1) CA3118374A1 (es)
ES (1) ES2954424T3 (es)
IL (1) IL282920B2 (es)
SA (1) SA521421975B1 (es)
WO (1) WO2020099924A1 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11676135B2 (en) * 2019-07-19 2023-06-13 Ebay Inc. Blockchain consensus protocol using predictive proof of metrics
CN113765956B (zh) * 2020-06-03 2024-05-24 华为技术有限公司 报文处理方法、设备、系统及存储介质
CN112016923A (zh) * 2020-08-28 2020-12-01 北京大学深圳研究生院 基于区块链的网内跨域身份管理方法、系统以及算力网络
CN112653682B (zh) * 2020-12-16 2022-12-27 深圳前海微众银行股份有限公司 一种区块链日蚀攻击检测的方法及装置
US11575743B1 (en) * 2021-07-23 2023-02-07 Vmware, Inc. Peer-to-peer software distribution
WO2023173324A1 (en) * 2022-03-16 2023-09-21 Nvidia Corporation Application programming interface to select storage

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6671724B1 (en) * 2000-03-21 2003-12-30 Centrisoft Corporation Software, systems and methods for managing a distributed network
US7577750B2 (en) 2003-05-23 2009-08-18 Microsoft Corporation Systems and methods for peer-to-peer collaboration to enhance multimedia streaming
JP2005122616A (ja) 2003-10-20 2005-05-12 Nippon Telegr & Teleph Corp <Ntt> ネットワーク型グリッドコンピューティングシステム
CN100488146C (zh) 2006-09-14 2009-05-13 华为技术有限公司 在p2p网络中建立点对点连接的方法及在p2p网络中的节点
US20090164576A1 (en) * 2007-12-21 2009-06-25 Jeonghun Noh Methods and systems for peer-to-peer systems
CN101321161A (zh) * 2008-07-21 2008-12-10 南京大学 一种基于市场模型的点对点网络信誉管理方法
CN101448026B (zh) * 2008-12-16 2012-05-23 中国科学技术大学 网格市场中基于信任过滤的计算节点选择方法
US8924982B2 (en) 2010-01-12 2014-12-30 Amazon Technologies, Inc. Managing private use of program execution capacity
EP2572495B1 (en) 2010-05-20 2016-07-06 Telefonaktiebolaget LM Ericsson (publ) System and method for managing data delivery in a peer-to-peer network
US8640137B1 (en) 2010-08-30 2014-01-28 Adobe Systems Incorporated Methods and apparatus for resource management in cluster computing
CN102255811B (zh) * 2011-07-14 2014-03-12 华为技术有限公司 一种获取节点间代价的方法，设备和系统
US9158458B2 (en) * 2011-09-21 2015-10-13 Os Nexus, Inc. Global management of tiered storage resources
US9537748B1 (en) 2012-04-24 2017-01-03 EMC IP Holding Company LLC Finding shortest path in multi-access nodes in cloud service
GB2503463A (en) * 2012-06-27 2014-01-01 Ibm Overriding abstract resource manager methods to provide resources to implement nodes in a service definition
US9818137B1 (en) 2013-04-19 2017-11-14 Amazon Technologies, Inc. Estimating the operating cost of computing resources provided by a service provider
US10248977B2 (en) * 2013-08-24 2019-04-02 Vmware, Inc. NUMA-based client placement
WO2017112866A1 (en) 2015-12-23 2017-06-29 Idac Holdings, Inc. Methods of offloading computation from mobile device to cloud
US10148498B1 (en) 2016-03-30 2018-12-04 EMC IP Holding Company LLC Provisioning storage in a multi-site cloud computing environment
US10382358B1 (en) * 2016-06-13 2019-08-13 Amazon Technologies. Inc. Multi-tiered data processing service
US10873540B2 (en) * 2016-07-06 2020-12-22 Cisco Technology, Inc. Crowd-sourced cloud computing resource validation
US10360606B2 (en) 2016-07-19 2019-07-23 Cisco Technology, Inc. Crowd-sourced cloud computing in a multiple resource provider environment
US10404614B2 (en) * 2016-11-21 2019-09-03 Vmware, Inc. Multi-cloud resource allocation
US10447806B1 (en) * 2017-06-09 2019-10-15 Nutanix, Inc. Workload scheduling across heterogeneous resource environments
US10853334B2 (en) * 2018-03-02 2020-12-01 Salesforce.Com, Inc. Technologies for providing service isolation, scalability, and proactive tenant migration in multi-tenant ecosystems
US10621004B2 (en) * 2018-03-19 2020-04-14 Accenture Global Solutions Limited Resource control stack based system for multiple domain presentation of cloud computing resource control
US10956229B2 (en) * 2018-10-04 2021-03-23 International Business Machines Corporation Managing resource sharing and task bidding on the internet of things (IoT)
CN109523243A (zh) * 2018-11-19 2019-03-26 济南浪潮高新科技投资发展有限公司 一种雾计算环境下基于区块链的数据存储方法
US11799952B2 (en) * 2019-01-07 2023-10-24 Intel Corporation Computing resource discovery and allocation
CN110086854A (zh) * 2019-03-28 2019-08-02 广东紫晶信息存储技术股份有限公司 一种分布式私有云系统

Also Published As

Publication number Publication date
JP7393426B2 (ja) 2023-12-06
EP3878161B1 (en) 2023-05-31
US20220006860A1 (en) 2022-01-06
CN112997469A (zh) 2021-06-18
JP2022511686A (ja) 2022-02-01
CN112997469B (zh) 2023-12-26
IL282920A (en) 2021-06-30
WO2020099924A1 (en) 2020-05-22
SA521421975B1 (ar) 2024-02-01
US11799954B2 (en) 2023-10-24
KR20210096619A (ko) 2021-08-05
IL282920B2 (en) 2024-07-01
EP3878161A1 (en) 2021-09-15
IL282920B1 (en) 2024-03-01
CA3118374A1 (en) 2020-05-22
AU2019380719A1 (en) 2021-06-10

Similar Documents

Publication Publication Date Title
ES2954424T3 (es) Mercado inteligente, descentralizado y autónomo para computación y almacenamiento distribuidos
TWI387284B (zh) 用於以積點為基礎之對等式儲存之方法、系統、及記錄相關指令的電腦儲存媒體
US12058195B1 (en) Systems and methods for IT management of distributed computing resources on a peer-to-peer network
US9948514B2 (en) Opportunistically connecting private computational resources to external services
US11763332B2 (en) Edge computing platform supported by smart contract enabled blockchain network
US20180095997A1 (en) Secure automated resource-exchange system
Gupta et al. CompuP2P: An architecture for internet computing using peer-to-peer networks
US11665105B2 (en) Policy-based resource-exchange life-cycle in an automated resource-exchange system
US20200142728A1 (en) Cooperative cloud infrastructure using blockchains for hardware ownership and access
KR102206026B1 (ko) 블록체인 기반의 작업 요청 및 결과물의 거래 방법 및 시스템
Sandholm et al. Notes on Cloud computing principles
Wang et al. Measurement and utilization of customer-provided resources for cloud computing
EP4310763A1 (en) Secure and trustworthy crossing network for transferring assets outside of exchange
US12093997B1 (en) Systems and methods for bartering services and goods using distributed ledger techniques
US11665067B2 (en) Managing reconfigurations of distributed computing systems
Alrawahi et al. Multi-attribute combinatorial marketplaces for cloud resource trading
US11483381B1 (en) Distributing cloud migration
Gattermayer Vstříc decentralizovanému peer-to-peer clusteru
Gattermayer Towards a Decentralised Peer-To-Peer Cluster
Network Infrastructure Marketplace
Jaradat et al. An enhanced grid performance data replica selection scheme satisfying user preferences quality of service
Gupta Protocols for sharing computing resources and dealing with nodes' selfishness in peer-to-peer networks
Vilajosana et al. Dymra: A decentralized resource allocation framework for collaborative learning environments
Vassiliy Self organizing dynamic ad hoc grids
Wang uopStore: an E-commerce Platform with a Peer-to-Peer Infrastructure