DRAFT

DAIN

DAINDecentralised Artificial Intelligence Network

Jose Ramon Garcıa Luque1 and Luis Garcıa San Luis21)AI Cognitive Architect at Sabadell Bank2)CIO at Deutsche Bank Spain

(Dated: 31 de julio de 2019)

Version 1.0.1

Este documento recoge las ideas fundamentalespara la construccion de una red de computaciondistribuida no-permisionada para el empleo depoder computacional no aprovechado de disposi-tivos convencionales en la prestacion de serviciosde inteligencia artificial.

Inicialmente se realizara una introduccion a losproblemas presentes de las principales tecnologıassobre las que se basa esta plataforma recogien-do las lecciones aprendidas en esta ultima decadacon las que formar una propuesta con la que dar-les respuesta. Se expondran las principales cau-sas que explican la necesidad e idoneidad de es-ta plataforma en el entorno tecnologico actual ylas oportunidades de negocio que su aplicabilidadabre entre particulares y empresas en un futu-ro inminente. Se detallara el funcionamiento delos mecanismos y los principios tecnologicos basi-cos capaces de cubrir los requerimientos expues-tos. Y, finalmente, se aportaran algunas de lasdemostraciones necesarias que argumentan esteideario. Todas las ideas expresadas en este docu-mento son una declaracion de intenciones sobre elalcance del proyecto dain en una fase tempranade madurez.

DRAFT

DAIN 2

I. INTRODUCCION

Las plataformas cloud como los PaaS, IaaS o SaaS sonde proposito generalista y deben por definicion ser ca-paces de manejar grandes volumenes de datos de amplioespectro y diversa finalidad. Solo de esta forma puedencomponer una coleccion completa segun su proposito deservicios especıficos y personalizados para cada usuario.

DLT basa su descentralizacion en la redundancia, im-pidiendo que estos sistemas sean aptos para sustituir losCentros de Procesamiento de Datos desde el punto devista de la eficiencia y de la economıa de los datos.

Cuando hablamos de redes no-permisionadas, las es-trategias abordadas para superar este reto, obvian quelas debilidades que se pretenden abolir de la arquitectu-ra DLT nacen del mismo lugar que sus fortalezas, enfren-tando contradicciones que solo pueden gestionarse balan-ceando los beneficios con las desventajas. Dicha situacionde compromiso se alcanza por medio de los algoritmos deconsenso que, si bien cumplen su proposito adoptando di-ferentes estrategias, no aportan una solucion completa alproblema y, a la postre, resultan igualmente insatisfacto-rias por alguna o varias de las siguientes razones:

No resuelven el problema de la congestion.

No permiten a la red escalar de forma que compensea productores y consumidores.

No son completamente eficientes desde el punto devista computacional

Acaban derivando en la especializacion de los nodosy la centralizacion de la red.

Estos problemas tecnicos terminan por impactar dosde los principales pilares del negocio:

La calidad del servicio; que provoca la reduccion dela demanda en la red.

Los sistemas de incentivos; cuyo correcto funciona-miento es vital para garantizar la rentabilidad dela actividad de los nodos en redes no-permisionada.Su mal diseno se traduce en dificultades para atraernueva participacion de nodos a la red, garantizarsu fidelidad al sistema y evitar el abandono de losnodos. En definitiva, compone la pieza clave paragarantizar la oferta del servicio.

Ambas, demanda y oferta, estan intrınsecamente rela-cionadas y juegan un papel vital en la supervivencia dela red y su penetracion en el mercado, siendo necesarioun punto de equilibrio entre ambas para ofrecer garantıassobre la sostenibilidad de la red. Estos impedimentos ha-cen de los algoritmos de consenso actuales inapropiadospara ofrecer servicios de forma masiva manteniendo dichopunto de equilibrio.

En la actualidad, estos problemas de las redes no-permisionadas disenadas para la ejecucion de codigo co-mo los Smart-Contracts o DApps, pueden considerarse

aceptables en funcion de la importancia que la soluciondesarrollada tenga que darle a la proteccion contra lacensura y la resiliencia. Pero este beneficio, generalmen-te, no logra justificar desde el punto de vista empresarialla perdida de la soberanıa y gobierno del software desa-rrollado; dado que la descentralizacion del codigo y losdatos pone trabajas al correcto manejo de la informaciony el versionado del software.

Sı obtiene beneficio, no obstante, aquel software desa-rrollado con intenciones maliciosas o fraudulentas quebuscan evadir la censura de las autoridades y actuar deforma transfronteriza; convirtiendo ası las caracterısticastecnologicas de la red en un reclamo para este tipo deactividades.

Las empresas que apalancan sus soluciones en este tipode plataformas se ven obligadas a compartir el ecosiste-ma con estos actores y lidiar con el uso que el softwaremalintencionado hace de la red, con las consecuentes re-percusiones que de ello puede derivarse: dano a la marca,ataques ciberneticos, congestion y degradacion del servi-cio de la red, vinculacion con actividades sospechosas odelictivas...

Por contra, el usuario final de la solucion empresarialdesarrollada en la plataforma, tampoco percibe una me-jora significativa con respecto un sistema centralizado enterminos de eficiencia o funcionalidad, pudiendo inclusosuponer un atraso por los problemas comentados.

Parte de estos problemas nacen de la imposibilidad decertificar servicios generalistas, ya que estos no respondea un problema de decision que puedan automatizarse yejecutarse maquina-a-maquina, lo que hace que de por sıno sean confiables, aun a pesar de que el codigo resida enuna cadena criptografica.

En otras palabras, hay que desmitificar la idea de queun codigo es confiable por el mero hecho de estar enuna cadena ya que no existen herramientas para que unamaquina tercera e imparcial pueda certificar automati-camente que un codigo Turing Complete desarrollado ysubido a la cadena hace un uso adecuado, legal y bienin-tencionado de la plataforma. Tampoco puede certificarseque el codigo disenado cubre los requerimientos funciona-les para los cuales su disenador asegura haberlo disenado;pudiendo este software perseguir cualquier intencion des-honesta. Sobran los ejemplos de puertas traseras en loscodigos implementados en cadenas de bloques, redes pi-ramidales anti-censura o contratos inteligentes que no ha-cen exactamente aquello que venden.

Puesto que la ejecucion de codigo por parte de un ter-cero tiene un comportamiento de caja negra, la ejecucionconfiable de estos codigos por un tercero tampoco pue-de resolverse con un problema de decision, por lo quedebe re-formularse el concepto de certificacion para po-der resolverse heurısticamente con tecnicas basadas en elQuorum. Esto es, haciendo que el mismo codigo se ejecu-te en varias maquinas para identificar posibles discrepan-cias que desenmascaren a actores maliciosos. Si bien estastecnicas cumplen su proposito, resultan extensivas desdeel punto de vista de recursos computacionales, reforzan-

DRAFT

DAIN 3

do los multiples problemas de escalabilidad y congestioncomentados.

Por todos estos motivos, las nubes-descentralizadas no-permisionadas tal y como las conocemos no pueden cubrircon la misma eficiencia la oferta de servicios genericoso intensivos en datos como los prestados por sus parescentralizadas, explicando algunos de los fracasos de lastecnologıas que persiguen este objetivo. Pero, es que, debase, el proposito perseguido no deberıa ser ese.

Toda red basada en computacion descentralizada, pa-ra poder ser mas eficiente que su par centralizada, debeevitar el dilema de emplear codigo a medida y almace-nar datos, para poder centrar su oferta de servicios en lacomputacion dirigida, delegando el almacenamiento a lossistemas tradicionales y el codigo ejecutable en aquellosalgoritmos que pudieran certificarse funcionalmente conun problema de decision, como podrıan ser un amplioespectro de algoritmos de IA, entre los cuales entrarıantodo el espectro de algoritmos de Machine Learning.

En este sentido, las tecnologıas de computacion descen-tralizada debe entenderse como un marketplace abiertode poder de computacion para la difusion y resolucionde problemas comprobables, donde los usuarios puedanponer su confianza en la correcta y barata ejecucion decodigo. En caso de que la cadena deba guardar informa-cion relativa al servicio prestado, esta debe cumplir conlos principios de importancia, tamano, independencia, in-mutabilidad y utilidad atemporal.

En este documento se postula una propuesta para darrespuesta a estos problemas presentados, mediante el usode tres vehıculos:

Enfocar DLT a la prestacion de servicios de IA,los cuales pueden certificarse a nivel funcional sal-vando los problemas de la certificacion de codigo,empleando set de datos de validacion aplicados alos modelos producidos mediante un proceso quesı resuelve un problema de decision automatizabley ejecutable maquina-a-maquina. Esta tecnica noprecisa mas que el almacenamiento de la configura-cion de los modelos cumpliendo con los principiosde importancia, tamano, independencia, inmutabi-lidad y utilidad atemporal requeridos a los datos.

Formar una propuesta de produccion y ejecuciondescentralizada y distribuida de codigo confiablehaciendo uso de las ultimas tecnicas de inteligen-cia artificial y criptografıa que sea capad de esca-lar, conservar la confidencialidad de la informaciony aprovechar las caracterısticas y capacidades detodos los nodos para ası garantizar la rentabilidadde la actividad de todos actores participantes de lared.

Introducir la computacion distribuida en el gen delconsenso para implementar tecnicas novedosas. Es-te es un paso necesario para crear nuevos algoritmosque adopten estrategias diferentes que no obliguena alcanzar situaciones de compromiso y que sean ca-

paces de resolver el problema de base que se encuen-tra detras del consenso en redes no-permisionadas:la honestidad de los productores de bloques y eltiempo de propagacion de la informacion.

La IA esta llamada a ser una gran revolucion tecnologi-ca a corto plazo, habida cuenta de que sus posibilidadespermiten cubrir una cantidad de casos de uso de negociopracticamente ilimitados. La ultima milla de esta revo-lucion se dara con la democratizacion de su acceso, cir-cunstancia en la que la DLT y el modelo de economıacolaborativa puede aportar enteros.

DRAFT

DAIN 4

II. DAIN

DAIN es una red nextgen no-permisionada para laprestacion de servicios descentralizados de inteligenciaartificial basada en DLT y fog computing.

DAIN esta disenada para crear, modelar, diferir, com-partir, utilizar y monetizar servicios end-to-end de formaindustrial bajo un modelo de economıa colaborativa entreempresas y particulares a traves del cual podra articular-se todo un ecosistema nuevo de modelos de negocio sinintermediarios.

DAIN compone un espacio seguro donde todos los ac-tores del ecosistema pueden poner sus recursos, trabajosy conocimientos a disposicion de los demas. Su misiones la completa democratizacion del acceso a la IA, parapermitir que cualquier usuario pueda hacer uso de ellasin limitaciones por hardware, software, datos o cono-cimiento, permitiendo aprovechar las mejores solucionesdel mercado al menor coste posible y acelerar el time-to-market de nuevos desarrollos.

DAIN, ademas, esta disenada para el desarrollo de nue-vos modelos de negocio y de relacion entre clientes y em-presas permitiendo la creacion de nuevos flujos de ingre-sos por medio de la infraestructura y la explotacion delos datos.

A. Un cerebro en la nube

DAIN puede compararse con un enorme cerebro. Cadausuario podrıa ensenarle sus propias tareas; luego, otrousuario o el mismo, podrıa pedirle al cerebro que las eje-cutara. Este cerebro recordarıa todas las tareas que al-guna vez le fueron ensenadas. Podrıa perfeccionar, si asıle ensenan, tareas que ya hubiera aprendido y serıa ca-paz de realizar tantas tareas al mismo tiempo como sutamano le permitiera. Por supuesto, consumirıa energıapor el esfuerzo invertido en todo ello.

El alimento del cerebro es la recompensa economicadestinada a costear la computacion empleada. Dicha re-compensa podrıa, de facto, provenir de la propia riquezagenerada por la actividad del cerebro y serıa destinada alos propietarios del hardware que lo componen.

De este modo, los usuarios interaccionan de dos mane-ras fundamentales, ya sea aportando capacidad compu-tacional o utilizandola para la resolucion de problemas.

B. Capacidades

Las capacidades que la red podra disponer son:

Transaccion: Intercambio en tokens entre usuarios.Las transacciones son la base indispensable parasostener una economıa nativa en la red, con la queproporcionar el intercambio de bienes y serviciosde forma confiable. Las transacciones sirven para

mantener el sistema de incentivos y realizar el pagode los servicios.

Solicitud : Peticion de resolucion de un problemacon un coste computacional asociado que debe re-solver la red externalizando su ejecucion medianteuno de los servicios disponibles.

C. Base tecnologica

DAIN define una arquitectura nueva e introduce meca-nismos de consenso propios. Este modelo se basa en tresredes virtuales:

Cortex : Siguiendo la analogıa del cerebro, Cortexes la parte encargada del razonamiento. Su labor esla ejecucion y el aprendizaje de las tareas.

Gnosis: Es la red que preserva el sistema de conta-bilidad distribuida de DAIN, Knot. Se encargarıade las funciones relacionadas con la memoria.

Sense: Actua como los sentidos, encargandose degestionar las interacciones con elementos externosy preparar la informacion para ser procesada y me-morizada.

D. Usuarios

DAIN gestiona dos tipos de usuarios, los Clientes y losProveedores.

Los Clientes realizan solicitudes en la red. Son usua-rios que buscan una solucion a un problema resolu-ble con IA y necesitan mas capacidad computacio-nal que la disponible en sus equipos.

Los Proveedores son aquellos usuarios que par-ticipan en la red poniendo a disposicion de losclientes la potencia computacional de sus dispo-sitivos/equipos para atender las solicitudes de losClientes. Buscan vender el poder computacional desus equipos y dispositivos.

E. Experiencia de uso

Ambos, Clientes y Proveedores, seran identificados enla red mediante el sistema de clave asimetrica (clavepublica y privada) comunmente utilizado en las cadenasde bloques. Ambas claves seran utilizadas para firmary cifrar la informacion, permitiendo establecer mecanis-mos de privacidad y autenticidad. Dependiendo del tipode usuario, la experiencia ofrecida sera diferente.

DRAFT

DAIN 5

1. Experiencia de los Clientes

Los Clientes podran conectarse a una interfaz identi-ficandose con su clave privada y publica, para optar adiferentes servicios:

Crear un modelo de IA: La interfaz determinarala intencionalidad y las necesidades del clientepara prepolular un formulario. De esta formase ayudara a clientes no expertos a gestionar susolicitud. En este formulario se recogeran de formaguiada los detalles sobre el modelo que el clientenecesita, permitiendole modificar cualquier cambioy ofreciendo ciertas garantıas conforme a que loscriterios de aceptacion establecidos sean los masefectivos para que el sistema de IA creado por lared satisfaga las necesidades expresadas.

Un ejemplo de esto serıa un Cliente que necesitaun sistema de deteccion de gatos en imagen. La in-terfaz le hara un cuestionario simple y muy guiadopara identificar que es lo que necesita dentro de lascapacidades de la red provistas, identificando quela mejor manera de proceder es una red neuronalprofunda. Se le pedira indicar los criterios de acep-tacion del modelo (tasa de aciertos, tasa de fallos,tiempo de respuesta, etc), que suba los set de datoscon los que la red trabajara (Imagenes 4K dondeapareceran gatos, e imagenes 4K donde no apare-ceran). Por ultimo, el Cliente indicara cuanto estadispuesto a pagar por el modelo, si bien la red lahara una sugerencia de acuerdo a lo razonable. ElCliente tambien indicara un buzon, por ejemplo unemail, donde se le notificara el resultado de su so-licitud cuando haya sido completada. Como pasofinal, se recopilaran todos los datos en un formula-rio en el que el cliente debera dar su Ok, momentoen el cual la solicitud se enviara a la red.Notese que para este proceso, el Cliente no ha teni-do que descargarse ningun SDK, ni librerıa de ter-cero ni tener conocimiento de como crear una IA,solamente interactuar con una interfaz guiada queva recabando los requisitos del cliente y solicitandolos datos que necesita para atenderlos.

Acceder a un Marketplace con modelos previa-mente creados, donde el cliente podra comprobarla forma de interactuar con ellos y los criterios deaceptacion bajo los cuales fueron creados. Ademasel usuario tendra certeza absoluta de que hacen loque dicen, pues todos los nodos habran certificadola solucion.

Por ejemplo, supongamos el caso de que otro Clien-te diferente al del ejemplo del punto anterior necesi-ta identificar gatos en un streaming de vıdeo. Paraello acude al Marketplace y utilizando un buscadorencuentra un modelo que se ajusta a sus necesi-

dades. En ese modelo se especificara: la algoritmiadel modelo (redes neuronales profundas), lo que de-bera pagar por usarlo (500 tokens por UMV/sg),el formato de datos aceptados (imagenes PNG),como eran los datos de entrenamiento y validacion(5000/7000 imagenes respectivamente), cual era elcriterio de aceptacion (sensitividad = 0.9 y sensi-bilidad = 0.95, etc).

Seleccionar uno de los modelos previamente crea-dos y ejecutarlo, inclusive, de ser necesario, sobregrandes volumenes de datos, aprovechando unpotencial computacional superior al de sus propiosrecursos.

Siguiendo el caso anterior, el cliente aceptarıa elservicio de ejecucion del modelo, indicando el SLAdel mismo. Digamos que es necesario que tenga larespuesta en tiempo real y ası lo indica en el SLA.La red estimara cuanto supondra el coste del servi-cio total por segundo y validara si cumple los cri-terios del cliente. Al aceptarlo, se abrira una co-nexion cliente-servidor entre la red y el cliente, atraves de la cual conectara el streaming de video yobtendra la respuesta en tiempo real.

Realizar las funciones de un cartera con capacidadpara gestionar transacciones en la red para realizarpagos o cobros.

Gestionar las polıticas economicas del cliente, quegarantizan que cualquier actividad que realice enla red, se realiza de acuerdo a su conveniencia ycriterio.

2. Experiencia de los Proveedores

Los Proveedores requeriran instalar un software enaquellas maquinas que quieran utilizar para participaren la red. Este software creara un nodo en la red P2Pde DAIN permitiendole comunicarse con otros actores dela red mediante el protocolo abierto de DAIN. En esemomento parte de los recursos y poder computacionalde la maquina en la que ha instalado el software podraser puesto a disposicion de un tercero para la resolucionde un problema. A cambio, el propietario de la maqui-na sera recompensado economicamente, depositando alfinal de cada operacion en la que la maquina ha parti-cipado el pago correspondiente por el servicio prestado.Este software pedira al propietario que identifique:

Sus polıticas economicas: para garantizan que cual-quier actividad que realice la maquina en la red sehace de acuerdo a su conveniencia y criterio.

Sus polıticas de uso: condiciones en las cuales seinstanciara un nodo en la red: horarios ası comocondiciones del dispositivo como la carga o la co-nectividad a la red.

DRAFT

DAIN 6

La cantidad de poder computacional que quiere de-dicar de ese dispositivo en base a las posibilidadesdel equipo identificadas mediante la ejecucion pre-via de un benchmark y proceso de certificacion ba-sado en pruebas de capacidad.

La direccion contra la que quiere que se ejecutenlos pagos en el token nativo de la red.

Pongamos por ejemplo un particular que ha hechouna inversion de 800 euros en un nuevo telefonomovil. Habida cuenta del gasto, decide que una bue-na forma de invertir es vender su poder compu-tacional en la Red DAIN cuando no lo usa. Asıpues, configura una App para que levante automati-camente un nodo en la red prestando el 80 % del po-der computacional de su movil por la noche, cuandoel dispositivo se encuentra conectado a la red wifiy a la red electrica. Al cabo de un tiempo, los in-gresos generados por la actividad del dispositivo enla red, han amortizado el gasto y le han generadobeneficios.

DRAFT

DAIN 7

III. ECONOMIA DAIN

A. Economıa Colaborativa

DAIN establece un modelo de economıa colaborativapor medio del intercambio de tokens nativos de la red.Todo intercambio se hace respetando un set de polıti-cas que velan por el acuerdo economico consensuado porambas partes resultado de la actividad que les ocupa:

Proveedores: Los Clientes pagan a los Proveedorescuando alguna de sus maquinas ha participado exi-tosamente en la creacion, re-entreno o ejecucion deun modelo solicitado por el Cliente. Los Clientesdeterminan el coste por el cual estan dispuestos apagar por tal servicio. Con esta informacion, losProveedores puede aceptar o rechazar el trabajosolicitado. Este modelo de pagos participa en unmercado abierto gobernado por la ley de la oferta yla demanda y en definitiva propiciara el crecimien-to organico de la red atrayendo nuevos proveedoresa medida que crezca la demanda.

Clientes: Al igual que los nodos obtienen un be-neficio por poner a disposicion de los Clientes supoder computacional, los Clientes puede obtenerun beneficio de la inversion que han realizado en lacreacion de un modelo de inteligencia artificial. Yaque cuando un Cliente solicita la ejecucion de unmodelo previamente creado por otro Cliente debenpagar al Cliente propietario del modelo en conceptode royalty.

Este modelo de relacion permite que existan diferentesestrategias de participacion entre Clientes y Proveedoresa traves de la especializacion.

Clientes Productores: Habra Clientes que vean unmodelo de negocio en la creacion y externalizacionde nuevos modelos. Estas empresas podran centrar-se en la refinerıa de datos democratizando el acce-so a la IA y acelerando su desarrollo mediante laoferta de modelos competitivos en la resolucion deproblematicas concretas a disposicion de la comu-nidad.

Clientes Consumidores: Habra Clientes que bus-quen acelerar el time-to-market de productos apa-lancandose en los servicios de IA publicados porotros y pagando por un coste competitivo por in-fraestructura. Estas empresas podran captar nue-vos tokens para realizar su actividad en la red,comprandoselo a Proveedores Particulares y a otrosClientes a traves de servicios customizados. Pro-veedores: Si bien la tecnologıa esta disenada pa-ra utilizar el poder computacional no aprovechadode equipamiento de toda ındole (FPGAs, Mobiles,Ordenadores Personales, CPDs, etc), los proveedo-res podrıan llegar a especializarse y profesionalizar-se en este tipo de servicio de infraestructura si la

demanda de solicitudes rebasa la oferta de podercomputacional existente en la propia economıa dela red.

El objetivo final es que cualquier equipo pueda trabajarcolaborativamente en la resolucion de los problemas yobtener un beneficio economico de ello distribuyendo lariqueza generada por los sistemas de inteligencia artificialentre los miembros de la red.

Figura 1. Dain Ecosystem

B. Open Economy

La arquitectura de DAIN esta pensada para que cual-quier tipo de dispositivo que cumpla unos requerimientosmınimos definidos para ser compatibles con dispositivosde bajos recursos pueda participar.

Ademas, las transacciones entre nodos honestos de lared, estan libres de comisiones y/o pruebas de capacidad,permitiendo que cualquier dispositivo pueda por sı mismoparticipar en la economıa de la red.

Cabe destacar en ultimo lugar, que DAIN es una redtransfronteriza. Este diseno permite eliminar las barrerasde entrada comunes en redes DLT para dispositivos yusuarios de cualquier ındole y localidad, siempre que suactividad sea honesta, pueda participar.

C. Distribucion de la Riqueza

En los planteamientos habituales la actividad de los ac-tores esta vinculada a la recompensa obtenida, provocan-do que aquellos actores con mayor capacidad para estaractivos acumulen progresivamente mayor riqueza. Estadinamica habitual se describe como un proceso retroali-mentado que lleva a la creacion de actores privilegiadosque acaban centralizando las decisiones de la red.

Esta dinamica es analoga a la que puede darse en unmodelo economico capitalista puramente liberal capaz de

DRAFT

DAIN 8

incentivar la aparicion de oligopolios y monopolios conpoder para desplazar con practicas abusivas a los demasactores del mercado. Para garantizar la supervivencia dela red es necesario asegurar que todos los actores que par-ticipan en ella encuentran su actividad rentable de for-ma independiente a sus caracterısticas particulares y queninguno de dichos actores acapara y centraliza la riquezagenerada por poseer algunas caracterısticas privilegiadaspor el consenso respecto la norma.

Esta es tambien una condicion importante para atraerel interes de nuevos participantes que incrementen el po-der computacional disponible en red y en consecuenciasu capacidad de crear riqueza por sı mismos. Y vicever-sa, es tambien una condicion obligatoria para combatir elabandono por la perdida de la rentabilidad de la actividadde aquellos participantes que hubieran logrado fidelizarseal sistema, ası como la correspondiente degradacion delservicio que ello conlleva.

Los protocolos de DAIN implementan reglas disenadaspara que los nodos de la red trabajen en un escenariode colaboracion premiando la creacion de asociacionesde nodos de caracterısticas heterogeneas que, bajo crite-rios que fomentan el reparto equitativo de los beneficiosgenerados a nivel de la red, velan por una distribucionhomogenea de la riqueza generada por la actividad desus participantes.

En este sentido, podrıa decirse que los protocolos deDAIN implementa leyes que combaten la creacion de mo-nopolios y oligopolios, sin desincentivar su implicacion enla red; esto es, permitiendo que los participantes que mascontribuyan obtengan un beneficio progresivo de ello, pe-ro sin que esto provoque la centralizacion de la red o unadegradacion de los beneficios obtenidos por los demas no-dos.

D. Token con Valor de Respaldo

En DAIN el valor del token esta vinculado a la capa-cidad computacional disponible en la red. De tal forma,que una mayor participacion de dispositivos en la redbeneficia a los portadores de tokens al permitirles dispo-ner de mayor capacidad computacional por token y porconsiguiente, mayor capacidad para solicitar trabajos.

E. Economıa Deflacionaria

Todo trabajo solicitado en DAIN conlleva la quemade una comision: tokens que son eliminados de la circu-lacion en la red, haciendo que el numero del circulantetotal se reduzcan con el paso del tiempo. Esta reduccionlimitara progresivamente la accesibilidad al token, provo-cando que su valor sea tambien incremental con el pasodel tiempo.

DRAFT

DAIN 9

IV. BASE TEORICA

A. Enfoque

A continuacion se expone el enfoque aplicado a la DLTno permisionada para integrar el gen de la computaciondistribuida en el consenso y adaptar la red a la prestacionde servicios certificables.

− Premisa 1: Vincular y encargar los servicios a con-juntos de nodos especıficos para implementar tecni-cas de IAM (Identity and Access Management) enredes no-permisionadas con las que conocer a losnodos y garantizar la honestidad de su actividad.

− Premisa 2: Disenar reglas de consenso con los quedistribuir el trabajo entre los nodos permitiendo laproduccion simultanea de bloques independientes.Esta condicion es indispensable para implementarun DAG. Un DAG aumenta en uno el numero dedimensiones en que una cadena puede crecer pro-porcionando a la red importantes cualidades quepermiten al sistema adaptarse a la demanda y com-batir la congestion:

• Producir bloques validos de forma asıncrona,lo que implica que el trabajo producido puedeacumularse y no desperdiciarse.

• Poder ajustar dinamicamente la cantidad debloques producidos por unidad de tiempo, loque permitira crear reglas con las que ajustarla transaccionalidad de la red en funcion dela demanda de forma tal que se respete el es-fuerzo de los nodos en tareas de validacion yse adapte la ocupacion y recursos de la red alas necesidades concretas del momento.

• Poder confirmar bloques de forma asıncrona,permitiendo planificar el esfuerzo dedicado ala certificacion de la informacion almacenadaen los bloques en el tiempo y gestionar la con-gestion de la red.

− Premisa 3: Ofrecer tecnicas que permitan controlarel tiempo de propagacion de la informacion y medirel sincronismo de la red independientemente de sutamano y del trabajo solicitado. El tiempo que lelleva a la informacion en propagarse por la red paraalcanzar una mayorıa es el mayor limitante a la ho-ra de implementar sistemas de contabilidad distri-buidos. Debe optimizarse en terminos de tiemposmedios para poder ofrecer una transaccionalidadoptimizada a los recursos de la red pero tambienen terminos de variabilidad para garantizar que to-dos los nodos disponen de la misma informacion enel mismo instante de tiempo de forma que puedanalcanzar consensos mayoritarios de la manera massıncrona posible.

− Premisa 4: Estandarizar los recursos hardware dela red mediante la virtualizacion y aplicar roles enfuncion de su conveniencia, para resolver los pro-blemas de la identificacion de recursos, distribuirla participacion en la red, garantizar la descentra-lizacion y la heterogeneidad del hardware y podermodelar a la red como un todo en la aplicacion detecnicas de anti-spam que respeten la participacionde todos los nodos por igual.

B. Proposito

1. Demanda - Variedad de problemas

En DAIN cada Cliente puede decidir por medio de lassolicitudes cual es el problema que quiere que la red re-suelva de entre una Suite de opciones, rechazando ejercercualquier clase de control sobre su dificultad. Como be-neficio extra, la resolucion de dicha problematica puedeaportarle alguna clase de valor al Cliente.

Por contra, DAIN debe hacer uso de dos definiciones:

− Suite: Definir el conjunto de problemas compu-tacionales que la red puede resolver automatica-mente y certificar funcionalmente con un problemade decision. Estos problemas deben cumplir una se-rie de caracterısticas comunes y, en definitiva, limi-ta las opciones a un set finito de algoritmias se-leccionables, aunque evidentemente el numero deproblemas a resolver a traves de estas algoritmiases infinito.

− Skill : Modelo resultante de la actividad de la redresultado de atender una solicitud y que cumpledeterminados criterios de diseno especificados enella.

2. Servicio - Problemas independientes

Asociar biyectivamente la demanda a la resolucion deproblemas especıficos e independientes a un grupo de no-dos, permite que:

Todos los grupos de nodos puedan trabajar a lavez resolviendo cada uno un problema asignado detal manera que cada uno pueda aportar un valordiferente a multiples usuarios de forma simultanea.

Se pueda crear una identidad certificada y hones-ta en la red vinculada al problema. Dicha identi-dad estarıa autorizada para publicar contenido, es-to es, producir bloques con informacion sobre losproblemas propuestos y las transacciones a trami-tar. Dicha identidad se certificarıa mediante proto-colos que permitieran conocer a los nodos que haytras ella y ofrecer ciertas garantıas sobre su hones-tidad de acuerdo a la Premisa 1.

DRAFT

DAIN 10

Repartir el trabajo entre los nodos conocidos, paraque los bloques tambien sean independientes y pue-dan producirse de forma simultanea, de acuerdo ala Premisa 2.

Usar tecnicas que permitan demostrar consensos in-ternos con los que bloquear las practicas maliciosas.

Con esta arquitectura, la actividad de la red estarıasujeta a la demanda de soluciones, las transacciones ser-virıan para tokenizar la participacion de cada nodo en laresolucion de los problemas propuestos.

Es necesario, por tanto, introducir mecanismos que lepermita a la red soportar transacciones en los bloquesgarantizando que sigan siendo independientes conformela Premisa 2.

3. Sincronismo - Confianza en ecosistemas abiertos

En una Blockchain convencional la forma de controlarque el bloque es confiable equivale a resolver el proble-ma de los generales bizantinos mediante un sistema devotacion. Estas votaciones se miden en terminos de con-firmaciones a traves de dos formas:

Confirmacion simple: Cuando un bloque es referen-ciado e incluido en la cadena.

Acumulacion: multiples confirmaciones encadena-das crean conjuntos apilados de nuevos bloques ensecuencia que sepultan el bloque a confirmar. Elbloque referenciado es incluido en cada una de lascertificaciones sucesivas que se realizan sobre losbloques predecesores, permitiendo que la acumula-cion de confirmaciones actue como un indicador quegarantiza la ausencia de conflictos con la informa-cion y la confianza depositada por la red en que elbloque no ha sido producido de forma deshonesta.

Con este mecanismo es posible lidiar con las colisionesy bifurcaciones, las cuales se pueden dar en dos posiblesescenarios condicionando el resultado del consenso:

Que efectivamente haya varias versiones incompati-bles de la cadena pero que el nodo emisor solamentetenga en su conocimiento una version de la misma.El riesgo de este escenario es que aumentan las pro-babilidades de que se forme una bifurcacion, ya queno dispone de conocimiento para saber que puedeestar construyendo la cadena sobre una version es-puria. Mientras que las otras versiones disponiblesno se compartan con el nodo, todo el trabajo reali-zado es susceptible de ser desechado.

Que el nodo tenga en conocimiento las multiplesversiones de la cadena. En este caso, puede aplicarun criterio consensuado para determinar cual detodas las versiones es la valida. En este caso, el fa-llo del consenso se puede adjudicar a una actividad

malintencionada que aprovecha alguna vulnerabili-dad del algoritmo de consenso.

En el caso de Blockchain convencional, una situacion uotra se produce dependiendo de la velocidad con se trans-mite cada bloque y la eficacia del criterio de consenso dela confirmacion.

DAIN propone mecanismos basados en la dispersionque permiten a los nodos tener una vision global del es-tado de la red en cada momento, medir el sincronismo delos nodos y controlar la velocidad de propagacion de lainformacion, dando soporte a la Premisa 2..

4. Certificacion - Confianza en ecosistemas abiertos

El proceso de construccion de una cadena de bloquesmediante las tecnicas convencionales podıa describirse entres pasos secuenciales referenciados con la nomenclaturavalidacion, confirmacion y certificacion.

La validacion es la que etapa que se da, cuando cadanodo de la red, de forma independiente recibe un blo-que recientemente publicado y debe comprobar el cum-plimiento de una serie de reglas para darlo por valido yhacerlo visible a los demas. Estas reglas son generalmen-te medidas de anti-spam y solo en caso de cumplirse, elbloque podra ser posteriormente confirmado.

La confirmacion se da cuando un nodo productor debloques valida el contenido de un bloque anterior parapoder considerarlo apto e incluirlo como antecesor delbloque que esta por emitir.

Notese que la validacion debe realizarse por todos losnodos de la red y de forma inmediata en cuanto se re-cibe un bloque, mientras que la confirmacion se resuelvebajo demanda por el nodo que va a producir el siguientebloque.

El encadenamiento llevado a cabo en la confirmacionimplica que el contenido sera incorporado en el DAG deforma inmutable, siendo preciso, por tanto, introducir ga-rantıas sobre la veracidad y honestidad de la informacionconfirmada en algun momento previo.

La certificacion es el paso responsable de hacer esacomprobacion: validar que dicho contenido es fiable ytiene una connotacion mucho mas funcional en cuantoal proposito mismo de la red.

Tradicionalmente el proceso de certificacion era asu-mido en uno de los anteriores pasos: validacion o con-firmacion. No obstante, las nuevas arquitecturas y nue-vos campos de aplicacion de las cadenas de bloques, nosobligan a contemplar este paso como uno independientey poner enfasis en las implicaciones de cada una de esasestrategias.

La certificacion puede abordarse junto a al validacionhaciendo que toda la red compruebe esa informacion. Sidicha comprobacion es costosa en terminos de compu-tacion, esta estrategia contraera una merma de la eficien-cia del proceso. En redes de criptomonedas, por ejemplo,la certificacion valida que la cuenta se mantiene con saldo

DRAFT

DAIN 11

positivo tras procesar el apunte contable evitando incu-rrir en una situacion de doble gasto.

Dado que un DAG permite la generacion de bloques deforma simultanea, es difıcil predecir la cantidad de traba-jo pendiente de certificacion que puede llegar a registrarseen la red en un momento. Por estos motivos, si se optapor aplicar la certificacion en el paso de la validacion,puede desencadenarse una situacion de congestion.

Resolver la certificacion como un paso incluido en laconfirmacion, proporciona ventajas estrategicas:

− La certificacion podrıa realizarse como un procesono secuencial y asıncrono, permitiendo que el traba-jo se acumulara para poder resolverse mas adelantesin perder la informacion.

− En segundo lugar, dado que un DAG es capaz desoportar multiples confirmaciones directas (referen-cias directas de un bloque a otro o varios) tambienpodrıa realizar varias certificaciones simultanea-mente.

Ambas propiedades permiten a la red planificar unaestrategia para asumir el trabajo de certificacion de cadabloque segun la capacidad de la red en cada momentocumpliendo con la Premisa 2.

De igual manera, el proceso de certificacion dependedel tipo de informacion que va a almacenarse en la cade-na. En los casos de uso de las criptomonedas, este procesoincluıa exclusivamente la comprobacion de firmas digita-les vinculadas a billeteras. Con la aparicion de otro tipode informacion, como por ejemplo los SmartContract, es-ta definicion ha dejado de ser valida.

De acuerdo, con esto DAIN debera incluir sus propiosprocesos en base al contenido manejado:

− Proceso de Certificacion de Modelos: Estableceruna forma desinteresada de verificar si los proble-mas indicados en la Suite se han resuelto o nocon las prestaciones indicadas. Para ello se intro-ducen los conceptos de Criterios de Aceptacion yAcuerdo de Nivel de Servicio (Service Level Agree-ment, SLA) y la Prueba util de Trabajo Objetivo(PoTW).

− Proceso de Certificacion de Transacciones: Esta-blecer una forma desinteresada de verificar si lastransacciones se confirman sin conflictos. Esto es,situaciones de doble gasto o saldos negativos.

5. Arquitectura y Topologıa - Cimientos basicos

La arquitectura de la red debe estar disenada para ga-rantizar el cumplimiento de la Premisa 4.

Especıficamente, la topologıa de la red debe disponerlas capacidades necesarias para proporcionar los meca-nismos responsables de garantizar la Premisa 3.

De forma mas general, tanto topologıa como arquitec-tura deben disponer las bases para la implementacion del

resto de mecanicas, tecnicas y metodos que sirvan paragarantizar el resto de premisas.

6. Consenso - Respeto a reglas universales

El consenso se entiende como un conjunto de reglasuniversales que deben respetarse. Estas reglas pueden di-senarse para velar por una u otra caracterıstica de la red.

Tradicionalmente, en Blockchain, el consenso resuelveun problema de sincronismo. En DAIN, esta vision se en-riquece un poco mas para cubrir un espectro mas ampliode necesidades con las que combatir los problemas vistospor la tecnologıa y sus alternativas.

La universalidad es una propiedad que deben cumplirlas reglas de consenso. Esta se da cuando cada nodo dela red puede inferir dichas reglas independientemente porsı mismo. Las reglas gobiernan el comportamiento de losnodos, haciendo que cada nodo de forma individual seacapaz de tomar exactamente las mismas decisiones quesus pares en cada momento.

Si dichas reglas son estaticas, bastara con ser imple-mentadas por diseno; si por contra deben adaptarse a lascircunstancia de la red, deberan hacerlo en funcion deinformacion que deba estar presente sin ambiguedad encualquiera de los nodos sobre el propio estado de la red.

Habitualmente, las reglas deben disenarse para poderfuncionar en cualquier escenario, lo que supone que gene-ralmente las reglas del consenso deberan ser dinamicas:capaces de adaptar inteligentemente el comportamientoindividual de los nodos a las circunstancias globales pre-sentes.

Todas las reglas de consenso estan disenadas para ga-rantizar el cumplimiento de las premisas especificadas porel enfoque de DAIN.

DRAFT

DAIN 12

V. ARQUITECTURA DE DAIN

A. Principios de Arquitectura

Los principios de la arquitectura de DAIN pueden re-sumirse en los siguientes puntos:

Estandarizacion del hardware de la red para controlinteligente de la congestion de acuerdo a la Premisa4.

Especializacion de los nodos y sub-redes para adap-tar la participacion de los dispositivos en funcion desus capacidades y velar por el fair-play. Conformea la Premisa 4.

Disponer las bases para el empleo de la compu-tacion distribuida y la colaboracion como gen delconsenso para atacar y resolver los problemas dehonestidad, escalabilidad y centralizacion segun losdictados de las Premisas 1, 2 y 3.

B. Nubes de Peers

Para que una red P2P pueda ser considerada una Nu-be de Peers, los nodos de la red deben ser capaces deagruparse o fragmentarse formando maquinas virtualesindependientes con un poder computacional determina-do bajo demanda, entendiendo el poder computacionalcomo una serie de prestaciones hardware. En esta lınea,una Nubes de Peers discretamente virtualizables puedeasignar poder computacional de forma discreta; en pa-quetes irreducibles de recursos computacional.

Una red Blockchain basada en esta arquitectura de-berıa crear una capa intermedia de recursos encapsula-dos de dedicacion completa con las que definir las cua-lidades computacionales y de memoria de cada una delas maquinas virtuales comunes en toda la red, propor-cionando una unidad mınima de medida en terminos depoder computacional. De esta forma, cada una de esasmaquinas virtuales podrıa dimensionar su capacidad deforma discreta, de una manera que permitiera al resto denodos establecer un consenso sobre la forma en que seemplean y orquestan dichos recursos.

De acuerdo a esto, se formulan las siguientes definicio-nes:

Nodo: se refiere a la maquina fısica que instanciael punto de interseccion o union en que confluyenlas conexiones dentro de la red P2P. Notese quepodrıa tratarse de la maquina fısica en sı misma oa su vez de maquinas virtuales que permitieran laejecucion de un hipervisor de tipo 2 (hosted), quese ejecutarıa en el contexto del sistema operativocompleto de la maquina.

Celula de Recursos (Resorces Cell, RC): Define lacantidad de recursos mınimos que un nodo puede

puede poner a disposicion de la red y, por extension,delimita el nivel mınimo de hardware que se requie-re de un nodo para participar en ella. De acuerdoa esto, un nodo de la red, dependiendo de su capa-cidad de hardware, podra instanciar mas o menosRCs. Con este mecanismo todos los nodos tendrandiscretizada su capacidad en terminos de RCs.

Unidad de Procesamiento Dinamica (Dynamic Pro-cess Unit, DPU) Es la maquina virtual resultantede agrupar varias Celulas de Recursos. La capaci-dad computacional de la maquina se mide en termi-nos de niveles o (Tier). Esto es, una DPU compues-ta por dos RCs sera una DPU Tier 2 y ası sucesi-vamente.

Unidad de Servicio (Service Unit, SU): Las maqui-nas virtuales pueden si es preciso trabajar en con-junto unas con otras agrupandose en una estructurade orden mayor denominada unidad de servicio.LaSU es responsable de atender la resolucion de unproblema computacional concreto. Una SU podrıaconstruirse de diferentes formas dependiendo delcontexto. Podrıa emplearse tecnicas computaciona-les basadas en orquestacion como la clusterizaciono grid.

Proveedor: Este usuario es el propietario de los dis-positivos que instancian los nodos en la red y, porextension, responsables del trabajo de todas lasDPUs creadas por dichos nodos en propiedad. To-das las DPUs en sus nodos estan bajo su direcciony actuan en la red en representacion suya.

Figura 2. Capas de una Nube de Peers

1. Tipologıas de Celdas de Recursos

Pueden existir diferentes tipos de RC en la red. Perocada una de ellas tiene unas caracterısticas especıficas en

DRAFT

DAIN 13

terminos de capacidad de memoria de almacenamiento dedatos volatiles (DRAM, SRAM, RAM...), capacidad dememoria de almacenamiento de datos persistentes (HDD,SDD..) y numero de operaciones en coma flotante porsegundo o FLOPs con independencia de los cores o laarquitectura de procesador.

Ası pues en DAIN se definen tres tipos de RC:

Computational Resource Cell (CRC): Son celulasde recursos intensivas en capacidad de computo me-dida en FLOPS.

Storage Resource Cell (SRC): Son celulas de recur-sos intensivas en capacidad de almacenamiento dedatos en disco medidas en Mbytes.

Dynamic Resource Cell (DRC): Son celulas de re-cursos intensivas en capacidad de almacenamientode datos volatiles medidas en Mbytes.

Cuando un dispositivo instancia un nodo, unas prue-bas de capacidad determinan sus caracterısticas en es-tos terminos. Ası pues, en funcion de dicha capacidad, eldispositivo podra instanciar diferentes configuraciones deagrupaciones de RCs. La eleccion del nodo de que RCsseran instanciadas definiran el tipo de nodo que es y susfunciones dentro de la red.

2. Propiedades de las Nubes de Peers

Notese que desde el punto de vista de las necesidadesde la tecnologıa Blockchain, las Nubes de Peers propor-cionan una cualidad especial a estas redes:

Control: esta arquitectura facilitarıa enormementela identificacion, monitorizacion, dimensionamientoy la portabilidad de los recursos computacionalesmediante la certificacion de las pruebas de capa-cidad (Proof-of-Work, Proof-of-Capacity, Proof-of-Bandwidth, etc)

Resiliencia ante la congestion: El dimensionado enrecursos computacionales de las DPUs permiten es-tablecer criterios estandard con los que es posiblepredecir la capacidad maxima de la red y estable-cer reglas con las que lidiar con la congestion anivel de red. De esta manera la capacidad de la redpuede establecerse en funcion del hardware mıni-mo considerado capaz de participar, aumentando odisminuyendo esa capacidad en funcion de las ne-cesidades de la red, las competencias y los roles delos nodos, y de las capacidades del hardware dispo-nibles en el mercado. Este es el principal limitanteque se encuentra no solo detras de las cadenas debloques convencionales, sino tambien de los DAGs.

Especializacion: Utilizando tipologıas de RCs, lasDPUs de una nube de peers pueden especializarsey dimensionarse de acuerdo a unos roles concretosdando a lugar a tipologıas de DPUs.

Adaptabilidad: la cantidad y la tipologıa de DPUsque puede instanciar un nodo pueden ajustarse pa-ra encajar con las caracterısticas tecnicas del hard-ware subyacente del nodo para hacer que dispositi-vos o equipos de diversa naturaleza pueda partici-par en la red.

Segmentacion: Las DPUs de una nube de peers pue-den segregarse para formar subredes especializadas,abstrayendo el trabajo de las mismas al hardwaresubyacente.

C. Arquitectura de Capas

Basandonos en una arquitectura de nube de peers, laarquitectura de DAIN puede describirse con un modelode capas:

− Capa virtual : Conjunto de redes virtuales especia-lizadas formadas por DPUs de igual tipologıa.

− Capa fısica: Red P2P no estructurada cuyos nodosson equipos o dispositivos cada uno de los cualesinstancian un conjunto de DPUs.

Figura 3. Virtual Layer

D. Capa Virtual

DAIN es una red P2P compuesta por tres tipos desubredes interconectadas, participadas por los diferentestipos de Unidades de Procesamiento.

1. Tipologıas de DPUs

En DAIN se definen diferentes DPUs basicas con rolesdistintos. Cada una de estas DPUs dependiendo de sutipologıa podran tener un dimensionamiento u otro, conbase a garantizar el cumplimiento de sus competencias:

DRAFT

DAIN 14

DPUs Manager. Se encargan de aplicar medidas deseguridad y gestion para la correcta comunicacioncon el exterior, siendo responsable de la calidad,disponibilidad, veracidad y manejo de los datos queson proporcionados a la red. Deben implementarcapacidades de monitorizacion, notificacion, conec-tividad y almacenamiento. Estan compuestas poruna o varias SRC, pudiendo medirse en varios ni-veles de Tier.

DPUs Worker. Estos nodos estan disenados paraincorporar capacidad computacional a la red pormedio de cualquier dispositivo o equipo. Su fun-cion es la de operar el modelado y la ejecucion desoluciones de inteligencia artificial mediante meca-nismos de computacion distribuida. Por estas cau-sas son maquinas intensivas en CPU. Estan com-puestas por una o varias CRC, pudiendo medirseen varios niveles de Tier.

DPUs Validator. Su mision es garantizar el correc-to funcionamiento de la red. Dedican sus recursoscomputacionales a la preservacion del DAG y lasvalidaciones necesarias para implementar las tecni-cas de consenso. Por estos motivos estas maqui-nas son intensivas en memoria RAM y HDD. Estancompuestas por una DRC y, por tanto, son por de-fecto Tier 1.

Este modelo de dimensionamiento, permite que equi-pos de gran capacidad puedan emular las cualidades dedispositivos de capacidades inferiores, permitiendo esta-blecer una cuota mınima de recursos y por extension, unatipologıa mınima de dispositivos que podran participaren la red.

Figura 4. DPUs

2. Tipologıa de Subredes

Estas son redes virtuales que se forman interconectan-do Unidades de Procesamiento de igual tipologıa.

Sense: Esta compuesta por todas las DPUs Mana-ger. Esta red actua como una red perimetral o zonadesmilitarizada responsable de gestionar la cone-xion con el exterior. A alto nivel funcional se suscompetencias son:

− Controla la interconexion entre la red DAINy otros sistemas de almacenamiento de datosde terceros, como podrıan ser Google Drive,Dropbox, OneDrive...

− Dispone de un sistema de almacenamientode ficheros distribuido basado en DistributedHash Table (DHT).

− Establecer la interfaz con el usuario para lagestion de solicitudes: cifra la informacion yvalida que las solicitudes cumplen con una se-rie de criterios de diseno y se encarga de ha-cerlas publicas para el resto de la red cuandoestas cumplen los requerimientos.

Cortex : Esta compuesta por todas las DPUs Wor-ker de la red. Encapsula el poder computacionaldisponible en la red con lo que:

− Dispone los servicios computacionales paraatender las solicitudes y darles respuesta.

Gnosis: Esta formada por todas las DPUs Valida-tor. Esta red y solo esta red almacena el DAG. A ni-vel operativo, sus funciones estan enfocadas en pro-porcionar el descubrimiento de bloques en el DAGpara darles visibilidad en la red Cortex con los quedisponer el consenso, articular los mecanismos devalidacion y dar trazabilidad a toda la actividadde la red. Sobre estas capacidades la red es puedecubrir las siguientes funciones:

− La exploracion de las Skills facturados, parapoder ser presentados en un marketplace des-centralizado.

− Llevar la contabilidad de los pagos por los ser-vicios solicitados y las transacciones realiza-das.

− La publicacion de nuevas Skills y el seguimien-to de los servicios en curso.

Los detalles del funcionamiento de estas redes seranexplicados con mas detalle en los siguientes apartados.

E. Capa Fısica

Las redes virtuales de la capa virtual se soportan bajouna red P2P implementado por equipos y dispositivos

DRAFT

DAIN 15

Figura 5. Red de Nodos en DAIN

fısicos sobre la que discurre el trafico real de datos.

1. Nodos

A conveniencia de las capacidades computacionales quedefinen su tipologıa, cada dispositivo podra instanciar unclase de nodo u otro.

Las diferencias entre los distintas clases de nodos se es-tablece por la composicion de Unidades de Procesamientoque lo forman:

Nodo A -Manager. Estan compuestos exclusiva-mente por DPUs Manager. Igualmente, pueden in-corporar equipos sin limitacion en el dimensiona-miento de su capacidad computacional o almace-namiento para esta labor.

Nodo B - Worker. Estos nodos estan formados ex-clusivamente por DPUs Worker. Su funcion es laaportacion de poder computacional. Estas DPUs,no tienen visibilidad del DAG, al no tener conecti-vidad directa con una DPU Validator. Por lo quetiene ciertas capacidades limitadas a la hora de par-ticipar en los mecanismos de consenso de la red.Estos nodos estan disenados para dispositivos conpoca capacidad de almacenamiento pero con capa-cidad computacional disponible, como podrıa ser elcaso de los dispositivos moviles o sistemas dedica-dos, siendo aptos para ser reclutados por su podercomputacional para la resolucion de problemas.

Nodo C - Full. Estos son los nodos convencionalesde la Red P2P y cubren la funcionalidad al com-pleto de la Red. Estan pensados para ordenado-res de sobremesa o servidores dedicados, equiposde proposito generalista con holgadas capacidadescomputacionales y de almacenamiento. Todos los

nodos Full deben estar formados por los siguientestipos de DPUs en las siguientes cantidades indica-das:

− Una unica DPU Validator.

− Una unica DPU Manager.

− Multiples unidades DPU Workers. Sin limita-ciones o imposiciones a la cantidad de DPUsaportadas dentro de las posibilidades de cadadispositivo. Las DPUs Workers de estos nodos,tienen conectividad directa con las DPUs Va-lidator y las DPUs Manager en el mismo nodo,y por tanto, visibilidad directa de los datos yla cadena. Por estas cualidades, los Workersde nodos Full tienen un desempeno completoen los mecanismos de consenso.

Nodo D - Masternode. Este nodo guarda una copiaexacta de toda la historia de los bloques correcta-mente confirmados en el DAG. Permiten que lasDPUs Validators de los nodos Full no tengan ne-cesariamente que almacenar toda la cadena, sinosolamente aquellos bloques mas relevantes y/o re-cientes para su actividad.

Figura 6. Red de Nodos en DAIN

2. Tipologıa de Redes

− Fognet : Red P2P no estructurada compuesta porlos nodos de tipo A, B y C.

− Backbone: Un red fısica P2P en forma de estrellacompuesta por todos los nodos especializados mas-ternodes que actuan a modo de supernodos. Back-bone esta conectada a la Fognet y puede ser al-canzada a traves de ella. No obstante, el traficocanalizado dentro de Backbone solo puede provenir

DRAFT

DAIN 16

Masternodos: es restringido y especıfico para tareasconcretas.

Figura 7. Capa Fısica

DRAFT

DAIN 17

VI. TOPOLOGIA DE RED

A. Principios Topologicos de Red

La DLT tiene ademas otros retos que enfrentar desdeel punto de vista de topologıa de red P2P:

− Refuerzo de la escritura: En sus orıgenes la redesP2P fueron principalmente empleadas como siste-mas para compartir y distribuir ficheros, en los quelos procesos de lectura basados en la busqueda re-sultaban mas intensivos que los de escritura. Poreste motivo las redes P2P han evolucionado parafavorecer los procesos de lectura en detrimento delos de escritura.

En DLT, sin embargo, cambian las tornas. La lectu-ra esta generalmente cubierta al forzar a que todoslos nodos compartan la misma informacion permi-tiendo que los datos esten accesibles desde cualquierpunto de la red. Sin embargo, como ya se argu-mento, los algoritmos de consenso se ven limitadospor la eficacia y rapidez con que se transmiten loscambios. Es por estas causas que en estas redes re-sulte necesario favorecer los procesos de escritura.

− Seguridad Una debilidad potencial de las redes des-centralizadas P2P es que su flexibilidad puede lle-var a topologıas de red fragiles o ineficientes, parti-cularmente si estan sujetas a ataques por parte deun adversario que puede manipular las conexiones.Es preciso establecer mecanismos que garanticen lahonesta conexion de los nodos.

− Escalabilidad La red solo puede ser realmente esca-lable si los nodos se instancian sin mas conexionesque las necesarias. Las redes altamente conectadasestan exentas de muchos problemas relacionadoscon la escritura, pero en redes no permisionadas,participadas por dispositivos de una amplia diver-sidad de caracterısticas y con capacidad de crecersin lımites tal estrategia puede volverse contrapro-ducente desde el punto de vista de recursos, memo-ria y ancho de banda. Es por ello que las redes P2Pno estructuradas sean mas convenientes en estoscasos.

− Localidad Poder identificar y certificar la ubicacionde los nodos en la red abre la posibilidad de imple-mentar mecanismos con los que medir y reforzar elsincronismo de la red.

− Homogeneidad Al mismo tiempo, es necesario quelas competencias de los nodos se distribuyan ho-mogeneamente en la red para garantizar que eltrafico se distribuye tambien homogeneamente y noexiste ningun punto de conflicto que pueda provo-car la congestion.

B. Backbone

Backbone es una red en estrella formada por los Mas-ternodos de la red. Backbone permite orquestar la or-ganizacion topologica de Fognet segun la convenienciade una serie de reglas que permiten lograr los principiostopologicos de la red y certificar las capacidades de losnodos.

La forma de abordar el problema es controlar la ma-nera en que se gestiona el alta y la baja de los nodos deFognet, facilitando que las conexiones que establecen consus peers sean las mas idoneas para la red en su conjuntoque para el nodo en sı.

1. Alta de Nodos

Dependiendo de su tipologıa de nodo, cada nodo podraestablecer una cantidad mınima y maxima de conexiones.Cuando un nuevo nodo trata de conectarse a la red, secomunica con sus pares mas cercanos e identifica que co-nexiones permanentes pueden establecer de forma queestas sean idoneas para la red y permitan identificar ymedir la dispersion de colectivos de nodos.

El alta de un nodo en la red se realiza por medio de unsistema de afiliaciones que dan idea a los demas nodos deen que parte de la red se encuentra. Este sistema de afilia-ciones se realiza por medio de regiones de influencia comosi de un sistema federado basado en distritos se trataragobernadas por un supernodo. Cuando un nuevo nodose instancia, trata de afiliarse a una de estas areas pa-ra lo cual necesita la cooperacion del supernodo a cargo.En este sentido, afiliacion no significa conexion directa,mas bien entrana una relacion de localidad directa conlos peers con los que el nodo ha establecido conexion enla red fısica.

Para que esta afiliacion sea realmente representativa dela ubicacion del nodo en la red, las conexiones estableci-das por el nodo deben satisfacer una serie de condiciones:

Cada vez que el nodo se conecta a un grupo de se-mejantes, se calcula el camino de coste mınimo en-tre el nodo y cada uno de los supernodos. De estaforma, el nodo debera afiliarse al supernodos cuyadistancia mınima medida a traves de una funcionde costes sea la mas baja de todas las posibles. Es-ta funcion de costes entrana un Proof-of-Bandwidthque mide la calidad de la conexion − Una pruebade ancho de banda consiste en la resolucion de unaecuacion matematica simple que debe poder resol-verse instantaneamente−. La prueba determina lavalidez de la conexion dependiendo del tiempo queel supernodo debe esperar para recibir la respuestaası como el numero de saltos sobre la red que di-cho mensaje ha dado para alcanzar el destino. Ladificultad de la prueba dependera de la cantidad desupernodos disponibles en la red.

DRAFT

DAIN 18

La idoneidad de dicha afiliacion tambien podra me-dirse ası como la posibilidad de evaluar si existeun supernodos mas conveniente para afiliarse. Encaso de existir una afiliacion mas conveniente, elnodo debe reestructurar sus conexiones hasta en-contrar la configuracion que de lugar a dicha afilia-cion. De esta manera se hacen cumplir los principiostopologicos de escalabilidad y homogeneidad sobreredes P2P fısicas.

Para medir la idoneidad de la afiliacion, los supernodosllevan la cuenta del numero y tipologıas de nodos afilia-dos por sı mismo y por el resto de supernodos, de talforma que cuando un nuevo nodo se instancia y trata deafiliarse, estos pueden sugerir que supernodos es el masconveniente.

2. Beacon - Certificacion y Localidad en la red

Identificado el supernodo al que el nodo debe afiliarse,el supernodo facilita un beacon a su nuevo afiliado: uncodigo unico y personal para ese nodo que le permitedemostrar al resto de la red su afiliacion.

El beacon es proporcionado por Backbone solo cuandoel nodo supera un conjunto de pruebas impuestas quepermiten certificar sus capacidad y ubicacion en la red.

El beacon ofrecido tiene una duracion finita, por lo quedebe renovarse cada cierto tiempo.

Cuando un nodo envıa informacion, se incorpora uncontador que va incrementandose con cada salto en lared. Juntos, contador y beacon, componen un sistemaque permite triangular la posicion relativa del nodo en lared con respecto otro.

El beacon tambien permite a los nodos verificar queel nodo se encuentra en la posicion indicada, ya que lospeers solo propagaran los mensajes que tengan un beaconadjunto a un peer conocido. Este sistema evita que unnodo pueda reubicarse en una posicion sin una previavalidacion con Backbone.

3. Consideraciones

Este mecanismos en su conjunto, forzara a que los nue-vos nodos vayan conectandose a la red solo en los lugaresque resulten de interes. La red entera crecera en torno alos supernodos que actuaran como centros de gravedadequidistantes capaces de atraer uniformemente la parti-cipacion de los dispositivos a la red.

Igualmente, son necesarias dos observaciones sobre estemodelo:

− La granularidad y precision de este mecanismos de-pendera del numero de supernodos que haya en lared.

− Como se vera mas adelante, Backbone permite quela red pueda aplicar mecanismos de propagacion

para reforzar la escritura y hacer la red mas efi-ciente. Al tiempo, garantizar que esta pueda cre-cer homogeneamente como metodo para combatirla congestion sin que ello suponga un problema deescalabilidad.

C. Fognet

Es la red estructurada formada por todos los disposi-tivos y equipamientos que componen la red.

1. IoT Ready

DAIN esta pensada para ser utilizada en el mundo IoT.La inexistencia por defecto de pruebas de capacidad ocomisiones para la publicacion autonoma de transaccio-nes en la red por parte de nodos honesto, no imponelımites en la capacidad computacional de dichos nodospermitiendo que cualquier tipologıa de hardware puedaparticipan en ella.

2. Next-Gen Mobile y 5G Ready

DAIN esta especialmente disenada para el mundo dela telefonıa movil y aspira a aprovechar las potencialesaplicaciones de la tecnologıa 5G.

Para 2021, existira en la poblacion mundial mas perso-nas con telefonos moviles (5,5 mil millones) que cuentasbancarias (5,4 mil millones), agua corriente (5,3 mil mi-llones) y telefonos fijos (2,9 mil millones), segun el 11o

Indice Cisco Visual Networking (VNI) sobre el trafico dedatos moviles de 2016 a 2021.

El 70 % de la poblacion mundial tendra un telefono“inteligente” en 2020 y dentro de cinco anos el 80 % deltrafico movil procedera de esos dispositivos, sobre todode zonas como Estados Unidos y Europa, segun el ultimoinforme de movilidad de Ericsson.

Segun este documento, el aumento continuado delnumero de telefonos “inteligentes” coincide con un cre-cimiento acelerado en el uso de datos. De acuerdo a suscifras, en 2020 el trafico de datos moviles se multiplicarapor diez y el 80 % del mismo se generara a traves detelefonos “inteligentes”.

Tengase en cuenta la siguiente reflexion. Los prime-ros hombres que pisaron la luna utilizaron equipos conun poder computacional infinitamente inferior al actual-mente disponible en cualquier smartphone convencional.Y no obstante, la mayor parte del tiempo dicho poder esdesaprovechado. Ningun movil hasta la fecha ha llevado,que se sepa, a ningun hombre fuera de la Tierra.

A diferencia de otros dispositivos, un smartphone sue-le estar encendido 24 horas al dıa, pues se encuentra adisposicion total de su usuario y a pesar de ello, en lamayorıa de los casos toda esa potencia solo se empleaen la resolucion de una necesidad puntual y personal (de

DRAFT

DAIN 19

una complejidad muy inferior a la de llevarle a la Luna).Habrıa quienes pudieran pensar que el aprovechamientolatente de los recursos de un dispositivo movil bajo unmodelo de economıa colaborativa no podrıa funcionar arazon de los costes en baterıa y problemas de conecti-vidad asociados. Pero no hay que olvidar DAIN puedetrabajar bajo polıticas de uso y que otras importantestecnologıas como el 5G estan por llegar.

Estas polıticas permitirıan, por poner un ejemplo ilus-trativo de su utilidad, activar los nodos de DAIN en eltelefono por la noche, cuando una mayorıa de gente seva a dormir dejando el movil encendido junto la mesillade noche. En dichas circunstancias, es habitual que losdispositivos se encuentran en desuso, conectados a la redelectrica y con una conexion estable a Internet.

Dado que estas condiciones se dan de forma generalis-ta en todo el globo, podrıa decirse que solo teniendo encuenta esta situacion, existe en cualquier momento y lu-gar, una masa crıtica de dispositivos en buenas condicio-nes de uso cuyo poder computacional podrıa ser utilizadopor un tercero.

Bitcoin mostro el camino para hacer esto cuando evi-dencio el enorme potencial computacional que puede serdespertado mediante la implementacion de un correctosistema de incentivos en una red abierta. Bitcoin ademasrevelo los escollos que deberıan ser salvados por aquellosque quisieran embarcarse en un reto tan ambicioso. Y esque a pesar de que en sus orıgenes Bitcoin fue pensadacomo una red abierta que poder ser participada por cual-quiera, sus pretensiones fueron frustradas por la imple-mentacion de algoritmos que propiciaban la centraliza-cion en la red y que acabaron por convertir la minerıa enuna actividad de nicho. Un enfoque mas descentralizadobasado en la colaboracion y que vele por la satisfactoriaparticipacion de todos los usuarios de la red, puede servirde reclamo para atraer este enorme poder computacionallatente en los dispositivos convencionales.

La arquitectura nobel de DAIN tiene en cuenta estasconsideraciones y esta disenada para hacer lucrativa laactividad de todo dispositivo que participe en ella.

DRAFT

DAIN 20

VII. NOESIS - DLT DE DAIN

Noesis es un sistema hibrido que combina las capaci-dades de una cadena y un DAG. Noesis se compone dedos partes:

Mainnet: Una cadena de bloques que actua comoun sistema descentralizado de medicion del paso deltiempo por medio del registro ordenado de eventos.

Strandned: un DAG escalable que almacena tran-sacciones con la capacidad de adaptarse dinamica-mente a la demanda.

Figura 8. Red de Nodos en DAIN

A. Mainnet

Mainnet es formada en todo momento por dos ISUs.Estas dos ISUs tienen la mision de publicar una cantidadfinita de eventos ocurridos descentralizadamente en la redbajo un formato de bloque.

Estas dos ISUs no son siempre las mismas, aunque sonescogidas mediante el proceso normal de formacion deSU llevado a cabo por el Proceso de Contratacion. Esteproceso sera descripto mas adelante.

La identidad de los nodos que forman estas ISUs no essiempre la misma; las ISUs formadas tienen un tamanoproporcional al tamano del conjunto de la red y son esco-gidas periodicamente por un proceso reiterativo que haceque los nodos que las componen vayan rotando por todala red dando a lugar multiples permutaciones posibles denodos.

Las ISUs tampoco tienen control sobre su propio tiem-po de vida; este es finito y acaba cuando las dos ISUshan producido una cantidad determinada de bloques.

Este sistema compuesto por dos ISUs que cıclicamentese confirman se denomina Hemisphere.

Mainnet actua como una senal coordinadora que per-mite a todos los nodos de la red orquestrar el consensode forma organizada y sin centro. Es por ello que todos

los bloques publicados por estas dos ISUs son BloquesOrquestadores. Sin embargo, ninguno de estos bloques sealmacena de forma persistente; en vez de eso, son almace-nados en una cola FIFO que registra los nuevos bloques,conserva los ultimos bloques mas relevantes, y descartalos ultimos.

1. Publicacion de Eventos y Disparador

La publicacion de los eventos no conflictivos permitehacer dichos eventos oficiales al resto de la red para asıofrecer un consenso sobre cuando desencadenar descen-tralizadamente procesos asociados a ellos de forma sin-cronizada.

Ası por ejemplo, la red no hace oficial el tratamientode una solicitud hasta que esta es incorporada a Main-net. En dicho momento, la informacion sobre la solicituddebe estar accesible en todos los nodos, permitiendolespoder activar de forma relativamente sıncrona el procesoencargado de formar la SU que se encargara de la peti-cion.

Estos bloques llevan la contabilidad de las demas SUsautorizadas y los trabajos disponibles. De igual manera,Mainnet hace las labores de coordinador descentraliza-do, indicando en cada lapso, el bloque mas confiable delDAG.

2. Reloj Descentralizado

Uno de los problemas mas difıciles en los sistemas dis-tribuidos es el acuerdo sobre el tiempo. Este problemaes aun mas difıcil en sistemas adversos como blockchain.Los nodos en la red no pueden confiar en una fuente detiempo externa o en cualquier marca de tiempo que apa-rezca en un mensaje.

Hashgraph, por ejemplo, resuelve este problema conuna marca de tiempo ”media”. Cada mensaje publicadoen la red esta firmado y marcado con una marca de tiem-po por una mayorıa de la red. La marca de tiempo mediapara el mensaje es lo que Hashgraph llama ordenamien-to ”justo”. Cada mensaje tiene que viajar a la mayorıade los nodos del sistema y una vez que que el mensajerecopila suficientes firmas, puede propagarse a toda lared.

Los bloques publicados por las SU de Hemisphere seconfirman secuencialmente en tandem, los unos a losotros, a una velocidad constante. De esta forma, los blo-ques de Mainet actua como un heartbeat en Strandnet.

Todos los bloques de Mainnet poseen un numero se-cuencial. Este numero sirve para referenciar el momentoexacto de la secuencia en la que se producen eventos enla red y poder hacer medidas relativas del paso del tiem-po contabilizando los bloques producidos por medio desu numero de secuencia.

DRAFT

DAIN 21

3. Coordinador

Un coordinador se encarga de evitar ataques al DAGy forzar su convergencia emitiendo las llamadas ”Miles-tones”. Mientras el Coordinador este activado, los nodosde la red unicamente validaran aquellas transacciones quehayan sido referenciadas previamente por estos ”Milesto-nes”.

Mainnet tienen la funcion de actuar como unidad coor-dinadora de Strandnet marcando el paso de la direccionprincipal que tomara el DAG, referenciando en sus pro-pios bloques, el bloque de Strandnet que actuara Miles-tone en cada momento.

De esta manera, existe la obligacion por diseno de quea todas las SU que vayan a publicar un proximo bloque enel DAG deban confirmar el bloque senalado pro Mainnetpara darse con validos. Este simple sistema descentrali-zado, se obliga a que el DAG converja obligatoriamenteen el sistema.

4. Seguridad

Es importante que no puedan crearse bifurcaciones dela cadena y que este sistema de contabilidad sea especial-mente robusto.

Si una de las dos ISUs es deshonesta, podrıa tratarde provocar una bifurcacion o bien no producir un blo-que con proposito de detiener el sistema. Ambas circuns-tancias son detectables en Mainnet y permiten a la ISUconfirmante invocar un reemplazo de las ISUs activas.

Si las dos ISUs son deshonesta, podrıan tratar de crearuna cadena alternativa, donde las marcas de tiempo nosiguieran el ritmo delimitado por el sistema.

Para evitar que nadie pueda crear una version alter-nativa del paso del tiempo, cada bloque publicado enMainnet incluye un resumen del Arbol de Merkle con elhash de todos los bloques producidos en Strannet duran-te el bloque anterior. Con este sistema retro alimentado,se fuerza a que Mainnet dependa tambien del resto de losnodos activos de la red.

B. Strandned

En ciencias de la computacion y matematicas un gra-fo acıclico dirigido o DAG (del ingles Directed AcyclicGraph), es un grafo dirigido que no tiene ciclos; esto sig-nifica que para cada vertice v, no hay un camino directoque empiece y termine en v.

Los problemas de encontrar rutas mas cortas y cami-nos mas largos se pueden resolver en DAG en tiempolineal, en contraste con los graficos arbitrarios para losque los algoritmos de ruta mas cortos son mas lentos ylos problemas de ruta mas largos son NP-hard.

Un DAG ademas goza de la propiedad matematica dereduccion transitiva, que permite generar versiones re-duccionistas del grafo eliminando la redundancia de la

informacion cuando esta estuviese ya complemente con-firmada.

Figura 9. DAG

1. DAG sıncrono

Un DAG permite que los bloques puedan producirse deforma simultanea e independiente lo que permite lidiarcon la colision y la bifurcacion, haciendo que el trabajode certificacion pueda acumularse para poder resolver-se de forma asıncronamente. Esta caracterıstica suponeun valor diferencial con respecto las cadenas de bloquesconvencionales, donde en tales circunstancias el trabajose pierde.

No obstante, esta cualidad no significa que la red estelibre de congestion; especialmente si la informacion debeser publica y por tanto estar disponible sıncronamente entodos los nodos de la red, como es el caso de Dain.

Algunas redes como IOTA, se enfocan en esta propues-ta: que cada nodo de la red pueda tener una versionpropia del DAG y recibir la informacion que se publi-ca de forma asıncrona entre nodos. Con ello, la red nose congestiona y puede hacerse, en la teorıa, infinitamen-te escalable, ademas de permitir transacciones offline. Noobstante, esta propuesta, sin duda muy atractiva, no estaexenta de problemas. Al tener cada nodo una posible ver-sion diferente de cuales son los tips (transacciones sinconfirmacion) y el estado del DAG, pueden darse situa-ciones de doble gasto que solo se resuelven a lo largodel tiempo y de forma eurıstica. En segundo lugar, hacevulnerable a la red a un ataque con una cadena parasi-ta. Y por ultimo, al poder aparecer nuevos bloques encualquier punto del DAG que lo eviten converger en unaversion unica, presenta la vulnerabilidad de una posiblebifurcacion −dos o mas versiones antagonicas del DAGcompitiendo entre sı−. Algunas de estas circunstanciasson consideradas una falla crıtica en un sistema basadoen la confianza. Para solventar este problema, en IOTAse empleo una autoridad central denominada coordinadorque marcaba el estado actual de la red y corregıa posiblesdesviaciones.

La alternativa realmente descentralizada es hacer quetodos los nodos tengan la misma version del estado dela cadena en todo momento, para lo cual es necesario es-tablecer una tasa de produccion de bloques estable que

DRAFT

DAIN 22

respete la velocidad a la que los nodos pueden recibir yprocesar la informacion. Como en las cadenas convencio-nales, controlar esa tasa es el corazon del consenso. Paraello es necesario controlar el grado de trabajo producidoen la red en tareas de validacion y por extension el gradode congestion respetando la participacion de la mayorıa(si no todos) los nodos. De lo contrario, los dispositivosparticipantes se volvera inoperativos y se desconectarande la red, de igual forma a cuando se aplica un ataqueDDOS.

La inoperatividad de los nodos tiene una clara reper-cusion sobre la calidad y el acceso al servicio pero tam-bien sobre la propia satisfaccion de los propietarios delos nodos, el funcionamiento del sistema de incentivos yel atractivo de la red para propiciar la participacion delnuevo hardware. En determinadas circunstancias puedeincluso suponer la supervivencia de la red.

Es por esto que el algoritmo de consenso debe imple-mentar las pruebas y las tecnicas de validacion, no solocon proposito de proteger la red de ataques de acuerdoal anti-spam externo o interno, sino tambien en funcionde si los dispositivos que forman la red son capaces deasumir el trabajo que se esta produciendo.

Una arquitectura de nube de peers discreta puedepresentar una ventaja frente otras redes que no tienenen cuenta el hardware que participa. Las capacidadescomputacionales estandar de las DPUs (concretamentelas de Gnosis) que forman la red establecen un valor cla-ro sobre cual es esa capacidad maxima. Estandarizar estevalor para todo nodo participante permite hacer algo quede otra forma es muy difıcil: modelar el comportamientode toda la red como un solo nodo y evitar el enorme retono resuelto de caracterizar una red formada por hardwareinfinitamente heterogeneo.

Esta propiedad permite a su vez que el algoritmo deconsenso pueda establecer claramente cuales son los lımi-tes de la tasa de creacion de bloques maximo asumible yası evitar la congestion.

Para establecer una tasa de creacion de bloques es-table, las tecnicas de consenso no solo deben ser capa-ces de funcionar ante un escenario estatico: deben poderadaptarse a las circunstancias de la red en terminos dela demanda y el crecimiento conforme el sistema puedarealmente escalar.

Cabe decir, que diferencia de otras redes basadas enDAG, Strandnet no es asıncrono. Todos los bloques pro-ducidos por los productores de bloques son conocidos portodos los nodos validadores en el momento mismo de supublicacion. Esta alternativa permite que:

Las transacciones sean confirmadas en un periodode tiempo altamente convergente.

No se puedan realizar ataques de cadena parasita.

No puedan convivir en ningun momento transaccio-nes que pudieran incurrir en una situacion de doblegasto.

DRAFT

DAIN 23

VIII. PROTOCOLO DE DAIN

Como la gran mayorıa de las cadena de Bloques, DAINpuede describirse como un protocolo, una serie de pasosorganizados regidos por un grupo de reglas capaces dedar respuesta a una necesidad basandose en las carac-terısticas de la tecnologıa sobre la que se soporta.

A. Overview Funcional

DAIN despliega un conjunto de Mecanismos actuantesen cada uno de las etapas del ciclo de vida de la solicitudque gobiernan el funcionamiento de las redes y subredesy su interaccion para el cumplimiento de las Premisas 1,2 y 3 por medio de las siguientes formas:

Orquestar la actividad de la red, resolviendo pro-blematicas concretas relativas al ciclo de vida de lasolicitud.

Establecer determinadas Propiedades asociadas alservicio. Los valores admisibles en la red de estaspropiedades estan restringidos por condiciones uni-versales denominadas Clausulas. Las Clausulas soncondiciones dinamicas que se ajustan a las circuns-tancias de la red. El conjunto de todas las condicio-nes esta recogido en una entidad logica denominadaContrato que gobierna el consenso fijando el valorde las clausulas en base a un conjunto de reglas,algoritmos y modelos establecidos por diseno.

Proporcionar pruebas y realizan validaciones quepermiten la certificacion mancomunada sobre elcumplimiento de las Clausulas durante todo el ciclode vida de un Servicio.

Identificar infracciones y aplicar las penalizacionesa los infractores.

Las Clausulas del Contrato establecen las normas deconsenso; reglas bajo las cuales deben funcionar los servi-cios. Todas las Clausulas estan disenadas para velar porel buen funcionamiento de la red permitiendo que estapresente unas caracterısticas determinadas.

El siguiente diagrama muestra la manera en que redesy mecanismos actuan en funcion del ciclo de vida de unasolicitud:

B. Interaccion entre Subredes

Sense interactua con los usuarios determinando quesolicitudes son validas para poder ser emitidas a lared y, por tanto, ser atendidas.

Cortex recibe solicitudes, las trata y genera blo-ques con informacion relativa al servicio que esta

prestando. Durante este proceso se encarga adjun-tar y entregar las pruebas que demuestran el cum-plimiento del Contrato. Cada vez que Cortex debeproducir un bloque consulta con Gnosis y escogeaquellos bloques que debe confirmar y certificar.Haciendo una analogıa, Cortex define la red de mi-neros al estilo PoW o la red forjadores al estilo PoS.Los nodos de Cortex, en este sentido, no son mi-neros ni forjadores, son constructores. Los bloquesse construyen con una finalidad especıfica crean-do Productos y siguiendo unos planos definidos porunas reglas recogidas en un Contrato.

Gnosis recibe los bloques creados por Cortex, cer-tifica la validez de las pruebas entregadas y realizavalidaciones sobre aquellos aspectos en que no sepueden aplicar pruebas bloqueando las actividadesque no respetan el Contrato. En caso de que el blo-que sea valido lo almacena en memoria dinamica,lo comparte con sus semejantes y lo hace visiblea Cortex permitiendo que sea confirmado. Cuandoel bloque finalmente se confirma, se almacena deforma indeleble en memoria de disco.

Las tres redes disponen de sus medios para penalizara los nodos implicados en infracciones.

Figura 10. Subnets - Functional Overview

Dependiendo de la etapa del ciclo de vida del bloqueestara activo uno u otro mecanismo.

C. DAIN Lifecycle

1. Resquest Lifecycle

La interaccion de un cliente con la red DAIN compren-de las siguientes etapas:

Solicitud: Peticion de resolucion de un problema decomputacion.

Admision: Determinar si la solicitud es valida ypuede ser emitida a la red para ser tramitada.

DRAFT

DAIN 24

Servicio: La solicitud es tratada, produciendo elresultado solicitado. Este proceso puede describir-se en etapas intermedias detalladas en el siguientesubapartado.

Figura 11. Lifecycle

2. Service Lifecycle

Todo servicio puede describirse como un proceso se-cuencial determinado por las siguientes etapas:

Concurso: Fase de negociacion que elabora las pro-puestas sobre que maquinas se encargaran de tratarla solicitud en base a los intereses de los proveedoresy la red.

Contratacion: Eleccion de la propuesta que se en-cargara de atender la solicitud.

Ejecucion: Se inicia una secuencia cıclica de dura-cion indefinida de produccion de bloques con infor-macion referente al servicio prestado cuyos pasosintermedios se describen en el apartado siguiente.

Finalizacion: Se produce un evento que determinael fin del servicio cuyas caracterısticas dependen dela naturaleza del propio servicio. Toda la informa-cion relativa a la actividad del servicio junto con laresolucion de la solicitud se encontrara validada enel DAG por medio de los bloques generados durantela ejecucion.

3. Block Lifecycle

Conforme ser mas exhaustivos y presentar las ventajasde la arquitectura propuesta y los mecanismos que conesta pueden implementarse en terminos de proteccion an-te ataques, escalabilidad, descentralizacion, capacidad deadaptacion a la demanda, gobierno y control de la con-gestion, este proceso se redefine como una extension delos pasos anteriormente descritos:

Onboarding: Se incluyen las transacciones asocia-das al servicio al bloque se esta produciendo de talforma que sea independiente de cualquier otro quepudiera estar siendo producido en el mismo instan-te.

Produccion: Empaquetamiento de informacion re-levante en un bloque sobre el servicio con intencionde ser publicada en el resto de la red y ser registra-da indeleblemente en el DAG. Incluye la aportacionde pruebas sobre la identidad de los nodos respon-sables y su consenso.

Propagacion: Proceso a traves del cual el bloqueviaja a traves por la red alcanzando la totalidadde los nodos para que dicha informacion pueda sertomada en cuenta y provocar un cambio de estadoen el DAG.

Validacion: Comprobacion del cumplimiento de unaserie de polıticas y reglas que velan por la protec-cion ante ataques, la descongestion, la descentrali-zacion, la escalabilidad y el gobierno de la red y quepermiten considerar que la actividad que produjoel bloque es apta para para producir un cambio deestado en el DAG.

Certificacion: Comprobacion que valida que la in-formacion contenida en el bloque es veraz y cumplecon una serie de criterios previamente establecidosque satisfacen las necesidades de los clientes.

Confirmacion: Evaluacion de la confianza deposita-da en los bloques previamente validados para poderdeterminar su validez para ser consultados y alma-cenados indeleble en el DAG.

D. Mecanismos de DAIN

1. IAM y honestidad - Concurso y Contratacion

En estas etapas se establecen las garantıas para la Pre-misa 1 :

Determinar que la formacion de la SU respeta elContrato y se realiza mediante la asignacion ho-nesta y desinteresada de roles. En caso afirmativo,este proceso de IAM proporciona a la SU una iden-tidad unica valida con la que interactuar en la redde forma autorizada. Esto se consigue a traves delProceso de Contratacion (RP).

Determinar que la informacion generada por la SUque se va a publicar en la red es confiable. Esto sig-nifica que la informacion proviene de esa maquinay no otra y que ademas se publica a convenienciade todas las DPUs que forman la SU mediante unconsenso interno mancomunado y unanime. Esto

DRAFT

DAIN 25

se consigue a traves de la Validacion Multi-firma(MsV).

2. Adaptabilidad - Produccion y Validacion

En estas etapas se establecen las garantıas para la Pre-misa 2 :

Permitir que los bloques dispongan transaccionesmanteniendose independientes unos de otros parapoder implementar un DAG capaz de resolver con-firmaciones de forma asıncrona y ası acumular eltrabajo pendiente para adaptarse a la demanda atraves del Metodo de Embarque (OM).

Determinar que la informacion publicada por la SUrespeta ciertas reglas de anti-spam que velan por ladescongestion de la red independientemente de lademanda. Esto se consigue a traves de la ValidacionEncadenada (CV).

3. Sincronismo - Propagacion y Confirmacion

En estas etapas se establecen las garantıas para la Pre-misa 3.

Todo bloque se emite simultaneamente en todas lasDPUs que componen la SU. Como cada DPU pue-de ser parte de un nodo diferente con una ubicaciontopologica distinta, la emision se produce desde di-ferentes partes topologicamente equidistantes de lared minimizando el recorrido que dicho bloque deberealizar para alcanzar la totalidad de la red inde-pendientemente de su tamano. Con esta tecnica seiguala y fija el tiempo de propagacion en la red,controlando el grado de incertidumbre que pudie-ran tener los nodos sobre el estado actual de lacadena. Se denomina a esta forma de propagar losbloques Fractal Propagacion Multi-Cast (McP).

Al disponerse en diferentes ubicaciones de la redP2P, cada DPU de una misma SU podrıa tenerversiones diferentes de la cadena. De esta mane-ra es posible poner en comun todo el conocimientoque hay sobre la cadena disponible en las DPUs dela SU, para tomar una decision consensuada sobrecual es su ultimo estado estable y determinar quebloque se debe confirmar. Este sistema de pues-ta en comun sirve para medir el sincronismo en lapropagacion de los bloque determinando si dichosbloques han sido realmente publicados y han al-canzado la mayorıa de la red independientementede su tamano, permitiendo construir el DAG desdesu ultima version estable registrada y asumida co-mo valida y evitando de este modo la posible com-petencia por diferentes versiones antagonicas delDAG. A este mecanismo se le denomina Confir-macion Confiable Consensuada (CCC).

DRAFT

DAIN 26

IX. SENSE

La subred Sense se define con tres objetivos principales:

A la hora de aplicar el modelado de soluciones deinteligencia artificial, existe la maxima no escrita enel sector de que los datos deben estar lo mas cercaposible del computo. La red Sense tiene el objetivode facilitar tal circunstancia.

Otro de los objetivos principales de la red, es elde garantizar que las solicitudes cumplen una se-rie de caracterısticas que permitan hacer coincidirlo mejor posible las capacidades de la red con losintereses reales de los usuarios, permitiendo que es-tos, no necesariamente deban tener conocimientoexperto para poder aprovechar las capacidades dela red.

La red Sense debe monitorizar los eventos mastranscendentales de la red para poder notificar dedichos eventos a los actores interesados conformeque todos los participantes de la red sin visibilidaddel DAG, proveedores y clientes, esten capacitadospara actuar en consecuencia.

Por ultimo, la red Sense sirve como una red perime-tral que permite aislar el funcionamiento de Daindel exterior, para garantizar que ninguna interac-cion pueda poner en riesgo la red.

A. Gestion de las Solicitudes

Sense interactua con el Cliente para guiarle a la horade conformar una solicitud, de tal forma que pueda iden-tificarse correctamente los recursos que haran falta paraatender la solicitud y ofrecer garantıas de que dichos re-cursos son los necesarios y no otros. En otras palabras,Sense actua de interprete de las necesidades del clientepara trasladarlas a requerimientos tecnicos que Cortexpueda entender.

En base a dichos recursos, la red podra solicitar correc-ciones para que la solicitud sea admitida. Por ejemplo:

− Si para la solicitud el set de datos empleados es de-masiado grande o demasiado pequena, la solicitudpodra ser rechazada.

− Si el modelo de datos empleado no cubre las nece-sidades de la solicitud.

− Si los criterios de aceptacion solicitado no podranser alcanzados por ser demasiado restrictivos.

Con este tipo de practicas, sera posible tambien blo-quear aquellas solicitudes que pudiesen poner en riesgola red.

B. Transacciones a coste base cero

En DAIN no hay minerıa, todos los tokens que pu-dieran circular en la red son dispuestos desde su primerbloque. El beneficio de la actividad de los nodos en lared se debe al comercio entre los distintos usuarios en laprestacion de un servicio de caracter computacional. Portanto, por defecto, todas las transacciones estan libres decomision.

Para resolver posibles ataques de denegacion de ser-vicio, DAIN valora la reputacion de las billeteras quepublican transacciones empleando algoritmos de Inteli-gencia artificial que tiene en cuenta la frecuencia y losflujos recurrentes de dinero en su historico.

Dicho algoritmo arroja un scoring de reputacion quees utilizado por un sistema de anti-spam incremental portramos cuyo proposito es impone pruebas de trabajo y co-misiones a las transacciones sospechosas para ser admiti-das a tramite. Este mecanismo permite detener las practi-cas maliciosas e imponer trabas a la actividad economicade aquellos actores que resulten perjudiciales para el sis-tema.

C. AI for AI

A la hora de gestionar las solicitudes, Sense analiza losdatos y sugiere un pipeline de modelos candidatos parti-cularizados para el problema que se pretende resolver.

− Para lograrlo, Sense primero pre-procesa los da-tos proporcionados buscando correlaciones entreellos que identifiquen datos intrascendentales, erro-res de formato y lagunas de informacion que per-mitan limpiarlos y prepararlos garantizando ciertosestandares de calidad.

− Tras esto, Sense analiza los datos pre-procesadosteniendo en cuenta el objetivo marcado por el so-licitante. En funcion de las caracterısticas solicita-das, DAIN identifica los modelos mas adecuados yconvenientes y genera una propuesta que se le pre-senta al usuario.

− Seleccionado uno de dichos modelos, Sense identifi-ca los parametros caracterısticos del algoritmo masadecuados, indicando un punto de partida conve-niente que la red DAIN podra utilizar para acelerarel modelado y reforzar la busqueda de solucionesque cumplan los criterios de aceptacion impuestos.

D. Seguimiento de las Solicitudes

Sense dispondra de mecanismos para monitorizar elciclo de vida de la solicitud con la que notificar a losclientes de circunstancias que les atanen.

DRAFT

DAIN 27

− Monitorizar el tiempo de vida de las solicitudes pa-ra darlas por rechazadas en el sistema al no encon-trar Proveedores interesados.

− Notifican a los clientes de la evolucion sobre el es-tado de su servicio.

− Notifican a los clientes de posibles cambios produ-cidos en la red que pudieran ser de su interes.

E. Memoria sensorial

Sense implementa un sistema de ficheros distribuidos(DFS) basado en Distributed Hash Table (DHT) don-de todo los datos almacenados son encriptados mediantetecnicas de cifrado homomorfico.

Este sistema de ficheros distribuidos puede alimentarsede fuentes externas de datos integrandose con los mayo-res proveedores de sistemas de almacenamiento de datosy Marketplace de datos. Igualmente, permite que los sis-temas informacionales de las empresas puedan conectarsea Sense.

Cuando la solicitud se considera valida, Sense accedeal sistema externo de datos, los descarga, aplica una nor-malizacion universal, los cifra y los sube a la red. Sense seencarga de trocear los campos de datos y repartirlos en-tre los nodos, de tal forma que ningun nodo por sı mismodisponga una vision completa de los mismos. Al tiempo,implementa los mecanismos para que solo los nodos auto-rizados por la red, puedan realizar operaciones de lecturasobre ellos.

Cuando una SU se forma para atender un Solicitud,Sense le facilita los datos asociados. Igualmente, cuandodicho servicio debe certificarse, si para ello son precisoslos datos, la SU certificadora podra solicitarselos a Sense.Una vez confirmado el trabajo, los datos referentes alservicio son eliminados de forma persistente.

Sense, ademas, introduce una marca hash en los datospara garantizar que tanto en la produccion como en lacertificacion, fueron empleados los mismos datos, evitan-do ası que en caso de que el modelo no pueda certificarse,los nodos validadores tengan la prueba de que los datosque se usaron son correctos y completos.

X. CORTEX

Cortex es la subred de Dain responsable de la presta-cion de servicios. A nivel tecnico, implica toda actividadde la red intensiva en el empleo de poder computacio-nal: la produccion, la certificacion y la confirmacion debloques.

Cortex es la unica subnet capaz de formar Unidadesde Servicio. Es preciso tomar en consideracion algunosaspectos importantes sobre esto:

Su actividad podra esta enfocada en la resolucionde un problema presentado en una solicitud, pu-

diendo por tanto, definirse la actividad de la SUpara tratar el problema como Servicio.

El resultado del esfuerzo de una SU son bloquesa anadir en Knot. Denominemos a partir de estemomento al bloque formado por una SU propor-cionando un Servicio en respuesta a una Solicitudcomo Bloque de Unidad de Servicio.

Una SU esta identificada en la red y a lo largo desu vida util podra publicar varios Bloques, bajo unconjunto de condiciones.

A. Cualidades de una SU

Esta arquitectura presenta ciertas de las caracterısti-cas necesarias para componer un sistema de computacionverdaderamente distribuido:

Bajo demanda: pueden ser dimensionadas ad-hocpara la resolucion de un problema concreto.

Elasticidad: la capacidad computacional de la SUpuede crecer o disminuir dinamicamente depen-diendo de la carga de trabajo.

Alta disponibilidad: no importan las maquinas quepor debajo esta trabajando en la SU. Las DPUs quelo componen pueden rotar, entrando y saliendo dela SU permitiendo ası que la resolucion de proble-mas de larga duracion no queden interrumpidos odesatendidos porque una o varias de las DPUs noesten disponibles.

B. Beneficios de Cortex

Este modelo, responderıa a algunas de las necesidadesbasicas de Blockchain:

En Blockchain convencionales, ya sea por medio dealgoritmos basados en turnos o en competicion, unsolo nodo al final es quien realiza el trabajo, limi-tando la capacidad de la red a la capacidad delnodo. Esto no resulta un problema real en Block-chain privadas, al poder ser participadas por nodosque operan en un Cloud, pudiendo de este nododimensionar sus capacidades bajo demanda. Peroesta tecnologıa Cloud o su capacidad, no siempreesta al alcance de los usuarios de una Blockchainpublica. Ademas la introduccion de un Cloud im-plica el pago y la gestion de un intermediario encar-gado de la resolucion del servicio, que al respectode la tecnologıa Blockchain resulta un contrasen-tido. por contra, trasladar las competencias de unnodo a una SU, una Blockchain abierta se podrıanobtener beneficios semejantes, sin ceder por ello elcontrol de la red a un tercero.

DRAFT

DAIN 28

Este mecanismo, permite ademas la resolucion si-multanea de problemas y la generacion simultaneade bloques. Pudiendo convivir tanto con una cade-na convencional como con un DAG.

Tiene sentido formar una red Cortex cuando los no-dos de la red quieren o deben cooperar en la resolu-cion de un problema aportando poder computacio-nal y distribuyendo la ejecucion. No son aplicablesen entornos donde los nodos deben competir.

Cortex es una red descentralizada pero, por contra,tambien distribuida, ya que el trabajo a realizar sereparte entre los nodos. Para poder realizar estaimplementacion, es necesario incorporar un nuevotipo de algoritmo de consenso para repartir los ro-les que serviran para organizar la forma en que sedistribuye el trabajo, habida cuenta de que ningunode los nodos presentes se conoce entre ellos y quetodos ellos compiten por tomar posesion de dichosroles.

C. Bloques de Unidad de Servicio

La actividad de una SU debe producir la emision debloques. A este respecto, es necesario senalar algunos as-pectos:

En estos bloques, la SU debe incluir las conclusio-nes y el resultado de su trabajo, de tal forma queeste quede validado, confirmado e inmutable en unacadena, permitiendo que sea consultable por cual-quiera.

Sirven para senalizar el estado de un servicio y suciclo de vida por medio de Metadata.

Figurar otro tipo de informacion de relevancia parala red y los usuarios, como por ejemplo Transaccio-nes.

Se presenta el resultado final del trabajo solicitadoen forma de Skills. El concreto de los bloques de-pendera del tipo de servicios para los cuales la redCortex se haya implementado.

El trabajo realizado podrıa entregarse en uno o va-rios bloques, permitiendo en este segundo caso im-plementar un sistema de paginacion que respetaralas capacidades de la red.

1. Tipologıa de Bloques

Puede hacerse una diferenciacion entre los diferentesbloques en base a la tipologıa de SU que lo emitio y almomento en que el bloque se emitio por la SU:

Bloque Orquestador : Es un bloque publicado querecoge diferentes eventos ocurridos descentralizada-mente en la red y que sirven de disparador para laejecucion de procesos un internos. La finalidad deestos bloques sera mas detallada durante la expli-cacion del sistema de contabilidad distribuida deDAIN, Noesis.

Bloque Transaccional : Bloques consecutivos queconstruye y publica la SU con transacciones soli-citadas a la red.

Bloque de Servicio: Es el ultimo de los bloques queconstruye y publica la SU. Con este bloque, se dapor finalizado el servicio, deshaciendo la SU e im-pidiendo que cualquier otro bloque relacionado conel servicio sea aceptado en la red.

D. Tipologıa de Service Unit

La arquitectura propuesta consta de dos tipo de SUs:

Internal Service Units: Son ISU que se creanautonomamente a causa de un evento interno dis-parador.

Common Service Unit : Existen tantas CSU en lared como solicitudes en curso se esten tramitandoen ese momento. Las CSU se crean bajo demandade los usuarios y se disgregan cuando su labor afinalizado.

E. Roles de las DPU en una SU

Durante la formacion de una SU, las DPUs puede asu-mir diferentes tipos de roles:

Master: serıa la DPU responsable de formar la SU,escogiendo las DPUs que lo formaran y ofreciendogarantıas de que todas realizaran su labor.

Slaves: serıan todas las DPUs que trabajan bajo ladireccion del Master.

Delegate: DPUs contratadas por el Master que noapoyan en la resolucion de problemas pero que co-laboran en la propagacion de la informacion.

Back-Up: todas las DPUs que podran ser convoca-das por el Master para suplir a una DPU Slave.

Supervisor: son DPUs especializadas que monito-rizan el comportamiento del Master y los Slaves,para detectar funcionamientos anomalos que vayanen contra del Contrato.

Estos roles son escogidos de acuerdo a la Teorıa deJuegos, permitiendo establecer dinamicas que permitandetectar y penalizar actividades maliciosas y disponer demecanismos de contingencia y recuperacion.

DRAFT

DAIN 29

F. Proceso de Contratacion (RP)

El Proceso de Contratacion es un proceso de negocia-cion en que las DPUs de Cortex compiten por determinarque maquinas formaran la SU responsables de encargarsede un servicio y atender una solicitud.

Cuando tal evento ocurre, las DPUs de Cortex em-piezan a negociar entre ellas sus papeles estableciendoasociaciones para formar una propuesta que satisface loscriterios recogidos en el Contrato. La satisfaccion de di-chos criterios es validada por Gnosis, permitiendo queuna sola propuesta y por extension un grupo de DPUs,de entre todas las que puedan estar proponiendose seconsidere legıtima para encargarse de la solicitud.

Figura 12. Service Unit

Ya sea a traves de un evento interno o externo, cuandose determina la necesidad de formar una SU se ejecu-ta el Proceso de Contratacion (RP). Este proceso es unalgoritmo que se divide en diferentes etapas:

1. Concurso: Se identifican al conjunto de DPUs queseran seleccionadas para actuar de candidatas deMaster en la SU y que deberan competir en la tareade formar la propuesta mas conveniente.

2. Negociacion: Cada candidato escogido recaba re-cursos por la red para formar de la propuesta.

3. Presentacion: las propuestas se publican y son valo-radas en funcion de sus caracterısticas. Esta valora-cion tiene encuentra las necesidades de la tarea quedebera cubrir la SU resultante y las necesidades dela propia red.

4. Contratacion: La propuesta con la puntuacion masalta es admitida y autorizada, conformando suidentidad oficialmente en la red como SU resultan-te.

1. Concurso

La DPU Master tiene un papel relevante en el funcio-namiento de la red ya que es quien realmente orquesta

las decisiones que se toman dentro de una SU, siempre ycuando no encuentre oposicion del resto las DPUs que laforman por considerar sus decisiones maliciosas.

Es competencia del Master ejecutar y validar el cum-plimiento de las condiciones del Contrato en la formaciony vida de la SU, motivo por el cual debe ser un nodo deconfianza.

Una forma de ganarse la confianza de la red es demos-trar la implicacion del nodo en su buen funcionamiento.Esta es la base sobre la que funcionan varios algoritmosde consenso como es el caso de PoS y sus derivadas: favo-rece aquellos nodos que poseen mas tokens al considerarque esta es una buena medida del interes del nodo porun futuro provechoso del sistema.

Figura 13. Concurso

La eleccion de los Master se realiza a traves de unalgoritmo que comparte bases con Proof-of-Stake. Estealgoritmo denominado Colaborative-Proof-of-Stake.

Al igual que PoS, CPoS compone un listado de nodosque voluntariamente se dan de alta en un listado, de-nominado Master Stack, haciendo un deposito de tokensprevio.

Este valor es especialmente determinante, pues impli-can contraer un compromiso con el rol adquirido. Los to-kens aportados quedaran atrapados en la billetera en con-cepto de fianza hasta la finalizacion del trabajo. De estamanera, cualquier tipo de infraccion o actividad desho-nesta podra penalizarse haciendo que no resulte rentablepara la DPU que lo lleve a cabo y actuando como medidadisuasoria para todo nodo que quisiera plantearselo.

Mientras que PoS, utiliza un algoritmo distribuido queescoge de forma aleatoria un nodo del listado basandoseen el stake aportado por los nodos del listado, en CPoSson escogidos varios nodos a la vez.

Los nodos escogidos, denominados candidatos, en vezde ganar el derecho de producir el siguiente bloque comoocurre en PoS, se les impone la tarea de competir en latarea de conformar la propuesta de SU mas conveniente.Para esta tarea, el numero de candidatos escogidos de-pende de la actividad especifica para la cual se dedicara

DRAFT

DAIN 30

la SU resultante del proceso.

2. Negociacion

El modelo de relacion entre los usuarios de la red, estagobernado por un set de polıticas programables.

Las Polıticas del Cliente para dicha solicitud vienenadjuntas a la propia solicitud desde el momento en quese hacen publicas en la red. Por contra, cada nodo dela red, tiene en su conocimiento el Set de Polıticas deProveedor.

Estas polıticas permiten que los nodos puedan unirse aconveniencia en la prestacion de los servicios solicitadosaportando cierto grado de flexibilidad en cuanto a comose desea que sea la participacion en la red de cada unode los usuarios.

Figura 14. Negociacion

Cuando un nodo escogido como candidato entra en lafase de negociacion, lanza mensajes a los demas nodosde la red, solicitando su colaboracion. Siempre que unanueva peticion de colaboracion alcanza un nodo, ambaspolıticas, (la del cliente y el proveedor) se cruzan. Si elcruce es positivo, al cumplirse los requerimientos de am-bos, el nodo lanzara un mensaje asertivo al Candidato.En dicho mensaje, se incluiran las DPUs disponibles endicho nodo y las DPUs ociosas en ese momento para eltratamiento de la solicitud.

Por toda la red estos mensajes se propagaran, permi-tiendo que todos los nodos interesados en el problemapuedan conocerse. Ası, a medida que la candidata for-ma la lista de DPU, va escogiendo DPUs para formar unconjunto de Slaves con el que constituir una propuesta deSU tal que se ajuste a las condiciones del Contrato.

Una vez el candidato ha escogido a los recursos intere-sados para disponer de una propuesta valida, ejecuta unalgoritmo distribuido generador de claves (DKG) para lacomparticion de secretos verificable basado en esquemade criptografıa t-umbral con cada DPU Slave escogida enla propuesta.

En este tipo de criptografıa es preciso la colaboracionde un conjunto de t miembros de un colectivo de m pa-ra poder aplicar la funcionalidad criptografica (firma ocifrado). Como resultado de este metodo criptografico,se dispondran de m claves privadas generadas de formadistribuida, en propiedad de un colectivo de m DPUsinteresadas en el problema, de entre las cuales t de ellasseran escogidas por el Master para formar la SU legitima.

En este caso los m miembros escogidos sera las DPUsSlaves. Estas DPU tendran un papel activo siguiendo ladireccion del Master en la resolucion del problema.

Las m − t DPUs restante son las denominadas DPUsBack-up de la SU. Estas DPUs podran ser convocadaspor el Master para participar como Slaves en caso deque fuera necesario reemplazar a las DPUs Slaves quequedaran indispuestas durante la ejecucion o aumentarla capacidad de computo.

Notese que cuanto mas grande sea el conjunto de DPUsBack-Ups, mas versatil sera la SU formada pero tambienmas insegura ya que podrıan colaborar para formar uncolectivo de tamano t con el que apropiarse de la iden-tidad de la SU legıtima. Para garantizar las medidas deseguridad, el numero de DPUs que trabajan en la SUdeben ser una mayorıa respecto las Back-up. Esto es:2t > m ≥ t.

Como resultado, se genera una clave publica que iden-tifica a la SU resultante y multiples claves privadas. CadaDPU participante tendra una, y solo una, clave privada,desconociendo las demas.

3. Presentacion

Una vez que el candidato ha conseguido reunir un con-junto concreto de recursos, comparte con el resto de lared su Propuesta de SU.

La Propuesta es un mensaje que incluye la clave queactuara como identificador de la SU en la red resultadode aplicar y la identidad de las DPUs que actuaran en laSU y los roles asignados a cada una de ellas, ası como lascondiciones economicas pactadas. Sobre el conjunto deesta eleccion se pueden medir una serie de propiedadesdel servicio que determinaran la calidad de Propuesta.

La validez de dichos atributos son aportados por mediode una Proof-of-Handshake, (PoH), un algoritmo distri-buido para cuya ejecucion se implica la participacion decada una de las DPUs relacionadas en la propuesta deSU. Este algoritmo, que sera explicado mas adelante, sebasa en la combinacion de las capacidades de la firmabajo esquema de criptografica t-umbral y la PropagacionFractal Multicast.

Algunas de estas atributos son:

− Stake (St): La cantidad de tokens aportados a lacuenta de deposito por el candidato.

− Colaborative Stake (Cs): La cantidad de tokens dis-ponibles en el conjunto de todas las cuentas a lasque rendira beneficio la actividad de la SU.

DRAFT

DAIN 31

− Descentralization (De): Cuantos Proveedores for-man la SU.

− Reputation (Rt): Cual es la reputacion de las bille-teras a las que rinde trabajo las maquinas.

− Dispersion (Di): Como es la dispersion de las DPUsque forman la SU en la red P2P.

− Size (Si): Cuantas son las DPUs que forman la SUcomo mınimo.

− Resilience Availability (Ra): Proporcion de DPUsBack-up que deben forma la SU.

Los candidatos pueden presentar sus propuestas endeterminadas circunstancias disenadas para que ninguncandidato tome ventaja de la propuesta de los demas.Cuando todos los candidatos han presentado sus propues-tas, la fase se termina y da a lugar a la contratacion.

Figura 15. Propuesta

4. Contratacion

El valor objetivo que deben tomar los atributos de laspropuestas son establecidos por las Clausulas del Con-trato y disenados para velar por el buen comportamientode la red y del sistema.

La calidad de la propuesta se calcula con una funcionde pesos inspirada en el Proof-of-Weight, que pondera lasdistancias en valores absolutos de las propiedades de laSU con estos valores objetivo.

Esta valoracion cualitativa se realiza de forma cuan-titativa por medio del scoring que arroja el algoritmo,denominado suitability scoring.

De esta manera, un encaje perfecto de dichas propie-dades con los establecidos por las clausulas obtendrıa elvalor maximo. Las clausulas del contrato establecen unservicio objetivo, pero tambien permite que, en caso deno existir, pueda ofrecerse el mejor servicio posible demanera adaptativa a las capacidades actuales de la red.

Como conclusion, la propuesta que alcanza el mayorscoring resulta en la SU resultante y el candidato enMaster de la misma. La SU se declara oficialmente enla red, autorizandola a la publicacion de bloques. Esta

SU permanecera activa el tiempo necesario conforme lascondiciones de la tarea asociadada.

La identidad de la SU en la red en su conjunto se re-suelve a traves de la clave publica obtenida de aplicar unesquema de criptografıa t-umbral. En adelante, cualquierinteraccion que la SU realice con el resto de la red, debevenir acompanada de la firma criptografica para poderser admitida a tramite.

5. Incentivos

Siempre sera preciso que exista un mecanismo que in-centive que las DPUs quieran asumir el rol de Master,de lo contrario no serıa provechoso para ellas. La formamas eficiente de hacer esto es ofrecer al Master una partemayoritaria de la recompensa/comision/facturacion aso-ciada al trabajo. Las formulas a aplicar aquı son infinitas.

6. Supervisor

Cuando hablamos de una SU resolviendo un problematodo los implicados trabajan con un interes comun, nocompiten, pudiendo esto servir como pretexto para abo-lir cualquier medida de seguridad o validacion; ignoran-do e incluso siendo complice de ciertos comportamientosventajistas que atentan contra las polıticas de la red. Espor esto que existe el rol del supervisor: basa su com-portamiento en el Dilema del prisionero y su mision esverificar que se cumple el contrato y denunciar aquellosnodos que pudieran incurrir en malas practicas pudiendoobtener un beneficio de ello.

Esto hace de la labor del supervisor tan importantecomo la del Master, pero a diferencia de esta, puede serdesempenada por mas de una DPU de la SU.

Entre las competencias de un SU Supervisor esta lalabor de vigilar el comportamiento de otras DPUs y ga-rantizar que cada una cumple su rol legıtimamente:

Validar el comportamiento de otras Supervisoras,pues no hay que olvidar que estos podrıan ser tam-bien complices de las malas practicas.

El valor exacto de DPUs Back-Up que puede uti-lizar la red podra ser configurable por Contrato.Siendo una de las labores de las DPUs Superviso-ras garantizar que existe ese numero de Back-ups yno otro.

Garantizan que son las DPUs Slaves anunciadas enla Propuesta quienes trabajan en la SU y no DPUsBack-up realizando una suplantacion de identidada conveniencia del Master.

Deben garantizar que cualquier sustitucion o reclu-tamiento de DPUs Slaves propuesta por el Masteresta justificada. Por ejemplo, la desconexion o

DRAFT

DAIN 32

abandono inesperada de DPUs o la necesidad deun mayor poder computacional.

Son responsables de tomar el rol de Master si estequeda indispuesto, conforme el orden indicado enla Propuesta.

Por estos motivos, el numero de DPUs Supervisoras enuna SU dependa del tamano de la SU y del numero deBack-Ups aplicables.

Para mitigar ese riesgo, otras medidas deberan estarrecogidas en el Contrato. Por ejemplo, que la SU esteformada por DPUs de varios Proveedores y que a la horade repartir los roles, cada rol recaiga en un Proveedoresdiferente.

Para garantizar que este rol no se escoge a convenien-cia, las DPUs que actuaran de Supervisoras seran esco-gidas como aquellas que quedaron en puestos inmediata-mente inferiores en la resolucion del algoritmo de contra-tacion.

Este mecanismos, junto los mecanismos anteriormentedescritos, hace que las SU sean extremadamente confia-bles en terminos de honestidad. Recuerdese que una SUdebe ser por completo honesta o deshonesta para poderfirmar los bloques. Ası pues, una SU completamente des-honesta solo podra formarse escogiendo los nodos quelo forman a conveniencia. Introduciendo un componen-te aleatorio en la SU, el cual no comparte intereses encomun con el resto de la SU y que es escogido a travesde criterios que refuerzan tener un interes a priori por elbuen funcionamiento de la red, se evita que la SUs puedanproducir bloques con un comportamiento malicioso y seofrecen garantıas sobre el lıcito comportamiento internode la SU, como podrıan ser casos como Sybil Atacks.

7. Infracciones

Detectada una mala practica que contravenga algunade las clausulas del contrato, esta podra ser expuesta a lared de una forma demostrable. En caso de que la red depor demostrada una mala practica, podra replantearsela estructura de la SU, con la cual seguir ofreciendo elservicio, y en base a la gravedad del comportamiento,aplicarse las siguientes medidas punitivas de forma noexcluyente a las maquinas infractoras:

Corrigiendo la participacion en la SU:

− Si la DPU es el Master, le podra ser arreba-tado ese papel, haciendo que pierda la recom-pensa/comision/facturacion asociada a su rol.

− Podra expulsarse y/o reemplazarse por unBack-UP a la DPU de la SU, haciendo quesu propietario pierda su parte correspondien-te de la recompensa/comision/facturacion porsu participacion.

− Podra expulsarse a todas las DPUs delProveedor de la SU, haciendo que elProveedor pierda toda posible recompen-sa/comision/facturacion.

Actuando sobre el capital de tokens invertido: seretirara una parte o la totalidad de los tokens apor-tados como fondos durante la fase de puja.

La aplicacion de estas medidas punitivas, disuade aaquellos Proveedores con predisposicion a incumplir lascondiciones del contrato; garantizando la salud del interescomun de las DPUs y de la red.

Este mecanismo se activa, cuando la red detecta unbloqueo en la produccion de los bloques. Recuerdese queun bloque es la situacion que se da cuando existe algunadesavenencia en la informacion que la SU desea publicary se debe por tanto o bien a que un nodo es honesto enuna SU mayoritariamente deshonesta o viceversa.

8. Versatilidad Computacional

Este mecanismo ademas permite implementar unatecnica especıfica para garantizar la versatilidad compu-tacional.

El funcionamiento se describe como sigue:

1. Durante la ejecucion de un servicio, el Master de laSU o un Supervisor puede identificar que se debemodificar la estructura de la SU.

2. Se consensua el cambio que debe realizarse con to-das las DPUs que forman la SU. En caso de quedicho cambio implique el reemplazo de DPUs o laadhesion/renuncia a otras SUs, el Master formarauna nueva propuesta con ellas.

3. La propuesta se incorpora al proximo bloque. Comoresultado, se producira una nueva clave publicas yclave privadas.

4. Gnosis validara la propuesta incluida en el bloque.Esta validacion implica que el suitability scoring al-canzado no pueda ser inferior al de la SU actual.

5. En caso de ser considerarla valida, realizara el co-rrespondiente reemplazo en Mainnet y la SU podracomenzar a utilizar su nueva configuracion.

G. Distributed Artificial Intelligence Computing

1. Inteligencia Artificial Encriptada

Todos los datos y modelos de la red estan protegidospor mecanismos de encriptado basados en homomorfismoque garantizan la confidencialidad de ambos aun a pesarde estar compartidas por un conjunto o la totalidad delos nodos de la red.

DRAFT

DAIN 33

Esta tecnologıa permite la ejecucion confidencial delcodigo, al permitir que modelos sean parametrizados enbase a datos encriptados sin que ninguno de las maquinasimplicadas en la ejecucion, pueda identificar o entenderla finalidad o naturaleza de los datos y el modelo.

2. Computer Scheme

Una vez se ha constituido una SU, el Masternode or-ganiza las DPUs creando una estructura de red con unajerarquıa de dos niveles:

FTU - Fine Tuning Unit: son grupos de DPUs cu-ya labor es la rapida convergencia de soluciones degrano fino. Estas estructuras tiene su propia topo-logıa interna.

Knot: Las DPUs o FTUs son interconectadas for-mando una estructura topologica correspondientea la teorıa de nudos.

Ambas estructuras se forman teniendo en cuenta el di-mensionamiento de la SU.

3. Fine Tunning Computing

Dentro de una FTU, cada DPU entrena parcialmenteun modelo con un conjunto de datos que ha descargado.Como cada DPU tiene una capacidad proporcional entresu capacidad de computo y el numero de datos a procesar,este trabajo dura lo mismo independientemente de cadaDPU.

Al final de cada ronda, DPUs ponen en comun los hy-perparametros obtenidos de sus respectivos modelos. Losentrenamientos parciales son, entonces y a traves de unproceso, combinados para obtener unos nuevos hyperpa-rametros que representan el entrenamiento resultante dela agregacion de todos los entrenamientos parciales.

Este sistema, permite converger muy rapidamente losmınimos de una funcion de evaluacion, pero no esta exen-ta del estancamiento sobre mınimos locales.

Para la busqueda de soluciones globales, esta tecnicase combina con el Knot Computing.

4. Knot and Cycloid Computing

La estructura mas simple que puede utilizarse paracomponer una estructura de nudo es un anillo en quetodas las DPUs que lo conforman tienen en mismo Tiero dimensionamiento.

Esta estructura puede entrelazarse creando formacio-nes topologicas mas complejas a medida que en la SUfiguran una coleccion mas heterogenea de DPUs en termi-nos de capacidad. El ejemplo representativo siguientemas sencillo serıa una estructura topologica en ocho, enla que el punto de cruce figura una DPU con el doble

de capacidad que el resto. Por ejemplo, en una SU don-de todas las DPUs son de Tier 1, en el punto de crucefigurarıa una DPU de Tier 2.

Esta estructura corresponde a una formacion de grafodirigido. Esto es, a lo largo de la formacion las comu-nicaciones son unidireccionales. Cada nodo debera teneruna coleccion par de conexiones formando un flujo cons-tante: de forma fija, envıa informacion a una mitad desus nodos adyacentes y recibe informacion de los demas,creando un bucle infinito que transcurre por todos losnodos que conforma la estructura.

En estas estructura, los puntos donde existe un nudo:

1. La cantidad de trafico del nodo sera multiplo dela cantidad mınima discurrida entre dos DPUs demenor Tier en funcion del numero de cruces pro-ducidos.

2. El Tier del nodo sera multiplo del Tier mınimo pre-sente en la formacion en funcion del numero de cru-ces producidos.

Multiples estructuras pueden crearse siguiendo lateorıa de nudos, no obstante, la estructura mas adecuadadependera del dimensionamiento concreto de las DPUsque forman la SU. El beneficio principal de este mode-lo es que permite la participacion eficiente de cualquiertipo de nodo sin que sus capacidades computacionalessupongan una limitacion. Ası dispositivos con poco po-der computacional o pocos recursos de memoria, puedencontribuir junto con otros de caracterısticas diferentes enla busqueda de soluciones.

Figura 16. knot Computing

Una vez que la estructura topologica de la SU es for-mada, cada DPUs descarga de Sense un subset aleatoriode los datos necesarios para el procesamiento. Este sub-set, contara con tantos registros como lo permita el Tierde cada nodo. A ser posibles, estos datos deben ser lo su-ficientemente representativos del espacio muestral sobreel que se esta trabajando.

Terminada la carga se arranca un proceso de Round-Robin. Cada DPU parametriza un modelo con los datosdescargados invirtiendo sus propios recursos computacio-nales de forma independiente. Gracias a la Arquitecturade Nube de Peers, cada nodo, contara con respecto losdemas con una cantidad de datos proporcional multiplode su Tier, pero tambien una capacidad de computo pro-porcional, de tal forma, que el sistema presenta un com-portamiento sıncrono en el que cada nodo tarda lo mismo

DRAFT

DAIN 34

Figura 17. Cycloid Computing

a la hora de procesar los datos para entrenar o parame-trizar un modelo interno.

Terminado el trabajo de procesamiento de los datos, loshyperparametros de los modelos producidos rotan entrelos nodos siguiendo el flujo definido por el nudo. Esto es,cada nodo comparte con sus adyacente de salida los hy-perparametros del modelo en el que estaban trabajando yrecibe hypermarametros nuevos de sus pares de entrada.

Figura 18. Cycloid Computing

Esta informacion se comparte en un salto de dos po-siciones en el orden establecido por el flujo. Este meca-nismo permite a cada nodo individual comprobar si loshyperparametros del modelo y su performance han me-jorado por el trabajo de su nodos antecesor con respectoel ciclo anterior. Esta comprobacion permite probar queel nodo esta realizando un esfuerzo computacional paracontribuir en la solucion del problema.

Una vez han rotado los modelos, el proceso se vuelvea iterar en bucle tantos ciclos como sean necesarios. Coneste modelo en cada nueva iteracion del ciclo, cada unode los modelos circulantes en la red es entrenado parcial-mente sobre un nuevo set de datos.

Con este comportamiento, en todo momento existiranen la SU tantos datos como la capacidad de almacena-miento posean todos los nodos en conjunto. Habida cuen-ta de que los datos son escogidos por lotes de forma alea-toria sobre un conjunto mayor, es probable que parte delos datos estuvieran replicados, pero aun ası, si el con-junto mayor del set de datos manejado es superior a lacapacidad de la SU, lo mas probable es que dichos nocompleten ni representen el set en su conjunto. Ademas,

una vez se han completado ciclos suficientes como paraque los modelos hayan circulado por toda la estructura denudo, todo los modelos circulantes en la solucion habransido entrenados parcialmente con los mismos datos de en-trenamiento provocando una conducta endogamica en lapoblacion de los modelos existentes.

Para evitar esto, en cada uno de los ciclos, el Masterde la SU escoge a uno de los nodos, obligando a que estenodo descargue un nuevo set de datos del conjunto to-tal. El Master puede aplicar varias tecnicas para escogera este nodo, ya sea de forma aleatorio o un sistema deturnos basado en una ruleta.

Figura 19. Cycloid Computing

Como resultado final, existira en la red una poblacionde modelos diferentes en todo momento. Y en cada ciclo,los modelos deberan converger en una o varias solucionesfinales dependiendo de la cantidad de mınimos localesaptos que la funcion de evaluacion contenga.

Para acelerar este proceso y encontrar una solucion quepermita localizar el mınimo absoluto de la funcion de eva-luacion del modelo, cada ciertos ciclos, todos los nodoscomparten con el Master nodo los hyperparametros en-contrados para desencadenar un proceso de hibridacionbasado en la computacion evolutiva.

5. Scalable Paralell and Distributed EvolutionaryComputing

DAIN permite paralelizar la busqueda de soluciones aproblemas de Inteligencia artificial sin limitaciones teori-cas, mediante la utilizacion de algoritmos evolutivos. Es-tos algoritmos basan en la gestion de poblaciones de indi-viduos de tamano indefinido que trabajan independien-temente en el problema compartiendo entre sı solucionesparciales.

La utilidad de esta tecnica se evidencia especialmenteen el caso de problemas de aprendizaje maquina y masconcretamente en redes neuronales, donde:

El espacio de busqueda puede ser muy grande ymultimodal. Diferentes soluciones son capaces delograr la misma performance.

DRAFT

DAIN 35

A medida que crece la cantidad de ejemplos, y au-menta la complejidad de la topologıa, el espacio debusqueda se vuelve cada vez mas complejo, y lafuncion de error contiene cada vez mas mınimos lo-cales. Los algoritmos geneticos presentan una altaeficiencia en espacios de busqueda grandes y com-plejos, pudiendo encontrar soluciones proximas almınimo global.

Otra importante razon para implementar los algo-ritmos geneticos como metodo alternativo de entre-namiento de redes neuronales es su generalidad. Elalgoritmo genetico requiere muy poca informacionacerca de la estructura del problema y por lo tantopuede ser utilizado para entrenar diferentes varie-dades de redes neuronales, como redes recurrentes,redes con funciones de activacion discontinuas, etc.

El proceso evolutivo es un proceso continuo. Los al-goritmos evolutivos trabajan en paralelo sobre unapoblacion de posibles soluciones, reduciendose lasposibilidades de que el proceso se detenga en unmınimo local suboptimo.

Figura 20. Evolutionary Computing

6. Useful-Proof-of-Targeted-Work

La tecnologıa DAIN permite la externalizacion de tra-bajos para el modelado y la ejecucion de inteligencia ar-tificial a traves de los datos. La descripcion de dichostrabajos se podra encargar en terminos de lenguaje denegocio y validarse bajo unos criterios de aceptacion yniveles de servicio (SLA) previamente acordados.

Para lograr una correcta ejecucion del servicio, DAINimplementa un algoritmo de prueba de trabajo util deno-minado Useful-Proof-of-Targeted-Work (uPoTW) comomedio para certificar en entornos no seguros y descentra-lizados, mediante criterios cuantitativos, que el esfuer-zo empleado realmente resuelve la necesidad solicitada y

que, por tanto, es apto de ser justamente recompensadoacorde a su dimension y los acuerdos alcanzados.

Cada vez que una SU encargada de un trabajo publicaun bloque, adjunta la solucion actual del trabajo en queesta trabajando indicando el performance obtenido.

Figura 21. uPoTW

uPoTW permite certificar funcionalmente todas las al-goritmias disponibles en la Suite de DAIN. Esta valida-cion es llevada a cabo durante la fase de certificacion porotras SUs en funcionamiento que representan una parteimparcial y proporcional de la red, intentando incurrir enposibles conflictos de interes. El trabajo entregado soloes tenido en cuenta cuando se alcanza las certificacionessuficientes que permiten garantizar que es confiable y seadapta a los criterios de validacion fijados por el usuario.

Este mecanismo de certificacion del trabajo permite alos demas nodos:

Comprobar el modelo y validar que el performancees correcto. Igualmente pueden validar que existeun incremento regular del performance alcanzadode forma que se ratifique el empleo legitimo de losrecursos de la SU. Este metodo permite combatirescenarios de Sybil Attack y Denegacion de Servi-cio, al permitir certificar que una maquina existerealmente detras de dicha actividad.

Comprobar a traves de entregas de soluciones par-ciales del trabajo la actividad de la SU y permitira los usuarios conocer el estado de sus solicitudes ysu evolucion.

Validar mediante criterios cuantitativos que el es-fuerzo empleado cumple los criterios de aceptaciony por tanto realmente resuelve la necesidad solicita-da, permitiendole a la SU poder ser recompensadaacorde a su dimension de su trabajo y los pactospreviamente alcanzados.

Inclusive cuando dicho trabajo presentado no cum-ple los criterios cuantitativos de aceptacion reque-ridos por el usuario por ser estos inalcanzables enterminos matematicos o computacionales, DAINimplementa un sistema de facturacion por proximi-dad que permite que el usuario pueda aprovechar la

DRAFT

DAIN 36

mejor version obtenida del trabajo solicitado y quelos nodos reciban una recompensa por el esfuerzo.

De igual manera uPoTW permite a Strandnet tomaruna decision sobre si dicho trabajo debe ser almacenadopersistentemente como una nueva Skill. Las skills repre-sentan las capacidades aprendidas por la red DAIN queposteriormente podran ejecutarse de forma nativa por losusuarios del ecosistema.

H. Validacion Multi-firma (MsV)

Una vez formado el bloque e identificados los bloques aconfirmar, el bloque es firmado por todas y cada una delas DPUs que formaron la SU a modo de consentimien-to implıcito sobre la informacion dispuesta y la activi-dad producida para generarla empleando la clave privadade criptografıa t-umbral obtenida durante el Proceso deContratacion.

1. Consenso Unanime Distribuido

La criptografıa t-umbral establece que es preciso usartodas las claves privadas de las DPUs de la SU para rea-lizar la firma del bloque. De esta manera, si una DPUdel conjunto quiere mostrar su desacuerdo sobre la infor-macion contenida en el bloque o la manera de producirlo,puede negarse a firmar produciendo una situacion de blo-queo.

Este es un mecanismo de consenso interno de la SUque vela por la unanimidad del voto, con ciertas implica-ciones:

− En una SU mayoritariamente deshonesta, una solaDPU honesta bastarıa para bloquear la actividadde toda la SU.

− Y viceversa: una sola DPU deshonesta, bastarıa pa-ra bloquear la actividad de una SU mayoritaria-mente honesta.

En definitiva, implica que el producto de la actividadde una SU es enviado o bien por una SU compuesta alcompleto por DPUs honestas o bien deshonestas.

Puesto que el Proceso de Contratacion favorece a lasSU que cumplan una serie de normas por considerarlashonestas en un proceso de competicion, es extremada-mente difıcil que una SU pueda formarse con una natu-raleza unanimemente deshonesta.

Y aun si tal caso se diera, la heterogeneidad de losnodos implicados en una SU impone trabas a la existenciade una previa coordinacion manifiesta entre los nodoscapaz de orquestar un ataque. En lo que se refiere, losataques basados en el animo de lucro, a menudo se basanen conductas egoıstas, que van en contra de los interesesdel conjunto, imponiendo limitaciones al consenso aunincluso entre nodos deshonestos.

En este sentido, la firma actua como una prueba deconformidad que demuestra la complicidad de las DPUsde una SU en el caso de ser detectada alguna infraccionpermitiendo aplicar medidas punitivas a todas las DPUsconforme la correspondiente infraccion. De esta manera,el mecanismo sirve para desincentivar que DPUs desho-nestas decidan colaborar con este tipo de practicas.

2. Repudia

Cuando una SU queda bloqueada, existe una combina-cion de nodos honestos y deshonestos en desacuerdo porla informacion o la ejecucion del servicio. Cuando dichacircunstancia se da, las DPUs pueden recurrir a la media-cion de las DPUs Supervisoras, quien en primera instan-cia trataran de resolver el conflicto mediante la aporta-cion de pruebas que permitan identificar las actividadesmaliciosas y discordancias ası como sus responsables. Siaun con las pruebas no se resuelve el desacuerdo, la DPUSupervisora, podra aplicar una reestructuracion de la SUpara repudiar DPUs de la SU y aplicar penalizaciones.

I. Quorum Confirmation (QC)

Una vez compuesta la informacion que la SU debe pu-blicar en forma de bloque, debe pasar a realizar la con-firmacion de bloques previamente publicados y validadosen la red.

Este proceso equivale a escoger que bloques facturadospor otras SU actuaran de predecesores del nuevo bloquea publicar.

La confirmacion directa de los bloques es un procesocolaborativo. Gracias a un DAG, un mismo bloque puedeser confirmado por una o varias SUs, o en otras palabras,un mismo bloque puede actuar de bloque predecesor devarios bloques sucesivos, siempre y cuando las SUs dedichos bloques escogieran el mismo bloque predecesor aconfirmar. De igual manera, una misma maquina podrıaconfirmar mas de un bloque.

1. Relacion entre SU y Confianza

Considerar el tamano de la SU como un indicador dela confianza tiene su base en el proceso de produccion:RP impone complejas trabajas a la creacion de SUs aconveniencia y MsV garantiza que solo una DPU honestadentro de la SU es necesaria para que la SU emita unbloque con informacion honesta. De aquı se desprendendos conclusiones importantes:

− Puede emplearse el numero de DPUs de la SU quefabrico un bloque como un indicador de la confian-za merecedora del propio bloque. Por ejemplo, unbloque producido por una SU formada por muchasDPUs sera mas confiable que uno producido porpocas.

DRAFT

DAIN 37

− Puede usarse el numero de DPUs de la SU confir-madora como un indicativo de la confianza de laconfirmacion que realiza. Por ejemplo, un bloqueconfirmado por una SU formada por muchas DPUssera mas confiable que uno confirmado por pocas.

2. Peso de Confirmacion Acumulativa

La confirmacion de los bloques es un valor indicativode la cantidad de veces que el Proceso de Certificacionse ejecuto sin conflictos sobre ese bloque y la reputacionde las maquinas que lo hicieron; y, por consiguiente delgrado de confianza de la red depositada en dicho bloque.

El peso de la confirmacion alcanzado por un bloque es,en otras palabras, la suma de todas las DPUs que par-ticiparon en cualquier camino que llega hasta el bloquedesde cualquier de los vertices sin confirmar del DAGsumado al numero de DPUs de la SU que formaron elbloque.

Segun esto, puede establecerse una relacion inversa-mente proporcional entre el numero de maquinas nece-sarias para la confirmacion del bloque y el numero demaquinas que produjeron el bloque, de forma que la sumade ambas DPUs (cantidad de DPUs del bloque fabricadoa confirmar y cantidad de DPUs de las SUs confirman-tes) debe alcanzar un umbral que equilibre la confianzagenerada en la produccion y la confirmacion del bloque.Ası, el bloque producido por una SU pequena precisarade mas confirmaciones que el de una SU grande.

Pero para que un bloque sea completamente confirma-do no bastan las confirmaciones alcanzadas; el verdaderoindicativo debe ser que las confirmaciones acumuladasque cada uno de los bloques publicados crece a la mis-ma velocidad que los demas hasta alcanzar una cantidadde confirmaciones determinadas. De lo contrario, si unode los bloques fuera, por ejemplo, deshonesto, podrıa irconfirmandose asıncronamente por maquinas adversariasa la red hasta alcanzar el umbral de confirmacion desea-do.

Por tanto, cada bloque del DAG esta asociado a lossiguientes valores:

− Confirmaciones acumuladas (AC): de confirmacio-nes acumuladas de DPUs confirmantes que un blo-que producido por la SU.

− Confirmation Rate (CR): Es el ratio de confirma-ciones acumuladas de DPUs confirmantes que unbloque producido por la SU en un instante de tiem-po a acumulado con respecto los demas bloquesproducidos en el mismo intervalo de tiempo.

− Confirmation Quality (CQ): Se obtiene como pro-ducto de AC y RC.

Confirmation Quality (CQ) es un valor indicativo delestado actual de la confianza que la red tiene en ese blo-que y que sera utilizado para comparar con dos valorespara establecer su estado concreto dentro del DAG.

− Deprecation Threshold (DT): Si el valor alcanzadopor QT es inferior a esta cota, se considera que elbloque puede ser deshonesto y se retira del DAG,junto con todos los bloques que lo han confirmado.

− Confirmation Threshold (CT): SI el valor alcanza-do pro QT es superior a este umbral, el bloque seconsidera confiable y se almacena persistentemen-te. En lo sucesivo, no sera necesario certificar lainformacion contenida en dicho bloque.

Cabe decir, que estos umbrales podran ser diferentesdependiendo del tipo de bloque que deba confirmarse. Asıpues, un Bloque de Servicio tendra distintos umbrales queun Bloque de Transacciones.

3. Convergencia y Capacidad de Certificacion

Dado que Dain implementa la Certificacion de los blo-ques en el paso de la confirmacion, la eleccion de los blo-ques a confirmar implica tambien ejecutar el proceso decertificacion de los bloques escogidos.

Teniendo en cuenta que una SU tendra capacidad decomputo en funcion de su tamano, puede establecerseuna cantidad mınima de bloques que la SU debe confir-mar en funcion de su tamano, dando a lugar la siguientepropiedad del Servicio:

− Certification Capacity (CE): La cantidad de blo-ques que debe confirmar directamente la SU.

CE establece una cota inferior al numero mınimo debloques sin confirmacion previa que deben confirmarseen un momento dado. Esta cota es, sin embargo corregi-da por el numero de bloques pendientes de confirmaciondirecta en el DAG. Digamos pues que una SU tiene unaCE de 3, lo que significa que por su tamano debera con-firmar al menos 3 bloques. Podrıa ser no obstante que enel intervalo anterior de tiempo solo existiera 1 solo bloquesin confirmacion previa.

Establecer el valor de CE permitira controlar la con-vergencia del DAG. Cuando mayor sea el valor de Ceestablecido en la red, mas bloques deberan ser confir-mados directamente por cada SU obligando a que si seproduce un pico de congestion este pueda ser asumidoconservando la convergencia del grafo.

4. Algoritmo de Seleccion de Bloques

Puesto que a la hora de realizar la confirmacionpodrıan existir varios bloques pendientes de confirmar,deben establecerse unas reglas de prioridad que obliguena la SU escoger los bloques de la forma mas conveniente.

Estas reglas deben estar disenadas para tomar en con-sideracion los siguientes puntos:

− El bloque senalado por Mainnet como milestone delDAG debe ser obligatoriamente incluido.

DRAFT

DAIN 38

− La relacion directamente proporcional establecidaentre confianza y tamano de una SU, indica queuna SU con muchas DPUs tendra un mayor po-der de confirmacion que una SU con pocas. Porotro lado, una SU pequena necesitara de mas DPUsconfirmantes para ser considerada confirmada en elmismo tiempo que las demas.

Para minimizar el retrabajo de Certificacion y ela-borar el DAG de la forma menos redundante, cuan-do exista mas de un bloque pendiente de confirma-cion, las SUs deben escoger los bloques maximizan-do la diferencia en valores absolutos entre la canti-dad de DPUs participantes de la SU y el peso deconfirmacion acumulado por una SU.

Con esta formula la SU prioriza los bloques. Despues,debe destinar parte de su Certification Capacity (CE) acada bloque escogido hasta cubrirla por completo. Losbloques pendientes de confirmacion que no pudieran serescogidos permaneceran pendientes de confirmacion has-ta que otra SU los priorice.

Ası una SU grande podra confirmar de golpe tantosbloques de SU pequenas como pueda, mientras que unaSU pequena confirmara bloques de SU grandes, minimi-zando el trabajo de certificacion en la red y construyendoel DAG con la menor redundancia posible.

5. Fork Resistance

A la hora de escoger los bloques pendientes de con-firmar para aplicar el algoritmos de ordenacion hay quetener en cuenta un par de aspectos importantes.

En primer lugar, las SU estan formadas por DPUs detipo Worker que no almacenan el DAG, por tanto, por sımismas son incapaces de conocer los bloques pendientesde confirmacion. Para poder acceder a esta informacion,las DPUs Worker de los nodos Full resuelven una consultacontra las DPUs Validator del propio nodo y rescatan lainformacion de los ultimos bloques y sus antecedentes.

En segundo lugar hay que tener en cuenta que la SUesta formada por multiples DPUs pertenecientes a diver-sos nodos de la red P2P. Por lo tanto, podrıa darse elcaso de que diferentes nodos de la red tuvieran diferentesversiones sobre los bloques pendientes de confirmar.

La Propagacion Fractal Multicast, el Proceso de Con-tratacion, la Validacion Multifirma garantizan que si elbloque se creo de forma legıtima, deberıa figurar en to-dos los nodos a la hora de tomar la decision. Si un bloqueno figurara en todos los nodos de la SU, podrıa habersecreado de forma ilıcita y clandestina por una parte mi-noritaria y/o parasita de la red o bien podrıa no haberalcanzado la totalidad de la red.

Por este motivo, toda la informacion de cada DPU deun nodo full de la DPU se pone en comun. Solamenteaquellos bloques que aparezcan pendientes de confirma-cion con unanimidad podran ser escogidos por el algorit-mo de ordenacion.

Figura 22. QUorum Confirmation

De esta manera, QC es tanto un mecanismo de seguri-dad como un termometro del sincronismo de la red. Unbloque solo se confirma, si hay cierto grado de certeza deque ya esta disponible en la mayorıa de la red y de quese ha creado publicamente siguiendo todos los procesosy mecanismos previos de Knot.

J. Propagacion Fractal Multicast (McP)

Una vez creado el bloque, este es emitido por cada unode los nodos participantes de la SU.

Cada DPU tendra conexiones diferentes con los nodosde la red fısica ocupando topologicamente hablando luga-res diferentes en la red, y por consiguiente, la informacionemitida trazara rutas distintas en funcion del nodo.

Este mecanismo permite implementar dos modos depropagacion de la informacion.

1. Bloque Multicast

El bloque es emitido por todas las DPUs de la SU. Alnodo receptor, le bastara con aceptar el primer bloque enllegar.

A este respecto, si la SU esta bien distribuida topologi-camente:

En promedio el bloque llegara antes a cada nodode la red, al acortar la distancias mınimas entrecada nodo emisor y nodo receptor. Lo que implicarareducir la esperanza de recibir el bloque y por tantola ventana de colision.

2. Paquete Multi-firma

El bloque es troceado y cada trozo es repartido entrelas diferentes DPUs de la SU. Luego, cada trozo es fir-mado independientemente y emitido a la red por cadaDPU. Al nodo receptor, debe esperar a recibir todos lospaquetes para poder armar de nuevo la informacion.

A este respecto, si la SU esta bien distribuida topologi-camente:

DRAFT

DAIN 39

Figura 23. Penetracion en red con Propagacion Convencio-nal(izquierda) vs. Propagacion con Validacion Multi-firma(derecha)

En promedio el bloque tardara mas en llegar a ca-da nodo, al tener que esperar a recibir el ultimopaquete siendo el camino mas largo recorrido el li-mitante.

La ventaja de este mecanismo, con respecto el bloque,es que permite certificar la procedencia de cada una de lasDPUs de una SU cuando aun no ha podido ser certificada.

3. Pseudo-atomicidad

En ambos casos, este metodo supone reducir la va-rianza del tiempo con que se recibe la informacion. Estoimplica que el instante de tiempo con que este evento seproduce es semejante para todos los nodos permitiendoque el evento se registre con mayor sincronismo en la red.

Desde un punto de vista funcional, el sincronismo tie-ne incalculables ventajas, pero la mas importante es quesiempre que un nodo tome una decision sobre el DAGtendra mayor certeza de que sera la misma decision quetomen el resto de nodos.

A este efecto podemos denominarlo pseudo-atomicidady podrıa provocarse parametrizando las siguientes pro-piedades de una SU:

− Dispersion (Di): Determina la distancia mınimapromedio entre las DPUs de una SU.

− Render (Rd): Cuantas son las DPUs Delegate queforman la SU.

Empleando estas capacidades se puede reducir el um-bral de incertidumbre que existe en la red a causa deltiempo de propagacion implıcito cuando se produce uncambio.

4. Sincronismo y Escalabilidad

La dispersion es un concepto relativo a la escala. Esdecir, un contenido se considera disperso en relacion alcontinente.

Introducir medidas de dispersion en las SUs para con-siderarlas validas equivale a establecer criterios que per-miten gobernar la escalabilidad de la red. Siempre que

el patron de dispersion se conserve, se obtiene un mismobeneficio sin importa el tamano del continente.

En esta analogıa, el continente es la totalidad de lared, el contenido es la propia SU. Una SU correctamentedispersa y lo suficientemente densa, garantiza un tiempode propagacion estable con independencia del tamano dela red. Un tiempo de propagacion estable, permite garan-tizar el sincronismo y por consiguiente que el consenso semantiene estable.

5. Beacons de Backbone

La Propagacion Fractal Multicast es una tecnica nove-dosa que favorece la escritura sobre redes P2P abiertasno permisionadas y no estructuradas.

Podrıa pensarse que para implementar esta tecnica, espreciso identificar la ubicacion exacta de cada nodo den-tro de la red, conforme disponer los mecanismos necesa-rios para validar la formacion de SUs lo suficientementedispersas, pero bastarıa con saber que la distancia entrelos nodos participantes cumple una serie de caracterısti-cas que permiten medir su dispersion. Este planteamientoevita tener que conocer la ubicacion exacta de los nodos,lo que en su modelo mas simplista nos llevarıa de nuevoa una red hiperconectada.

Con este proposito, los beacons facilitados durante elalta de los nodos en la Backbone y el numero de saltos(hops) que un mensaje da en la red hasta alcanzar su des-tino sirve de prueba necesaria para conocer la ubicacionestimada de un nodo en la red.

6. Proof-of-Handshake (PoH)

PoH es la prueba que acompana los mensajes en elproceso de contratacion en la etapa de concurso para de-mostrar la veracidad de las propuestas.

PoH se basa en el uso de un algoritmo de creacion declaves distribuido bajo esquema de criptografıa t-umbralpara componer la identidad de la SU. Con las claves ge-neradas se firma un paquete multi-firma que incorpora elbeacon de afiliacion de cada DPU incorporada.

Con este sistema, cada nodo de Gnosis puede validarla procedencia de cada DPU de una SU, confirmar suparticipacion y conformidad en la formacion de la SU yvalidar la dispersion de la SU formada.

XI. GNOSIS

Gnosis es una subred virtual cuyas competencias prin-cipales pueden reducirse a tres:

Ejecutar los mecanismos de validacion basados entecnicas de anti-spam que garantizan el consenso yla escalabilidad del sistema.

DRAFT

DAIN 40

Gestiona Noesis actuando como sistema de almace-namiento y registro de bloques capaz de garantizarla inmutabilidad y confianza.

A. Gestion de Mainnet

Gnosis valida los bloques producidos en Mainnet paragarantizar que ninguna de las SUs de Hemisphere estanproduciendo bloques conflictivos que de forma malinten-cionada que pudieran tratar de desestabilizar el reloj des-centralizado de la red.

Una forma de tratar hacer esto serıan publicando even-tos ya publicados o creando multiples bloques para pro-vocar una bifurcacion.

En tal caso, Gnosis dispara el evento interno para sus-tituir a las SUs formadas por dos nuevas y continuar lacadena desde el punto conflictivo.

1. Admision de Servicios

Una de las principales tareas de Mainnet en la publi-cacion de eventos es la admision de los servicios. Una vezuna nueva peticion ha sido solicitada, Mainnet la publicaen su cadena y desencadena el Proceso de Contratacion.

B. Gestion de Strandnet

Gnosis dispone de varios mecanismos para gestionar yconformar Strandnet.

1. Metodo de Embarque (OM)

A diferencia de una cadena, un DAG permite resol-ver situaciones de colision y bifurcacion siempre y cuan-do la informacion de los bloques sea independiente.8 ElMetodo de Embarque es un algoritmo de clusterizaciondinamica que asigna a cada Cuenta Origen presente enlas transacciones pendientes de la Mempool una y solouna SU activa de forma universal en toda la red parapermitir que los bloques producidos en Strandnet seanindependientes.

Asignar todas las transacciones de cada cuenta unıvo-camente a una SU al tiempo que se permite que las tran-sacciones sean publicas permite que los bloques produ-cidos por las SU activas sean independientes y puedanproducirse simultaneamente sin incurrir en una situacionde doble gasto. La independencia de los bloques es unrequisito obligatorio para que la red pueda implementarun DAG como mecanismo de almacenamiento y, por ex-tension, de aplicar sus propiedades.

El contradominio de este algoritmo esta definido por elRecuento de Servicios que determina el listado de todaslas SU activas en cada momento, mientras que el dominio

serıa todas las cuentas con transacciones pendientes devalidar en la MemPool.

Esta funcion tomarıa informacion inmutable y por tan-to conocida por todos los nodos de la red para poder es-tablecer un consenso universal e invariante sobre que SUes la asignada a la cuenta y por extension a sus transac-ciones salientes.

2. Congestion de Strandnet

Strandnet gobernado por unas serie de reglas que lepermiten crecer elasticamente tanto horizontal como ver-ticalmente:

El crecimiento horizontal sıncrono, permite la acu-mulacion de confirmaciones en una direccion to-pologica unica con la que ofrecer garantıas sobrela confianza depositada en los bloques y validarque no incurren en ningun conflicto. De acuerdocon los postulados de la Premisa 2, estas laboresde confirmacion pueden realizarse asıncronamente,permitiendo que la red planifique el esfuerzo en eltiempo para resolver la confirmacion en el momentomas idoneo.

El crecimiento vertical, se produce de forma pun-tual cuando varios bloques producidos colisionan(en numero de secuencia) por un aumento de SUsactivas en la red. Este aumento, permite aumentarla transaccionalidad, de tal forma que nuevas ISUspueden ser invocadas para descargar la carga detransacciones pendientes en un momento dado. Laacumulacion puntual de bloques por un crecimientovertical del DAG, producen nudos conflictivos, quepueden resolverse de forma asıncrona y distribui-damente sin comprometer la direccion topologicaunica del grafo.

3. Validacion Encadenada (CV)

Para controlar la congestion es necesario imponer quelos bloques se generen con una frecuencia que oscilara entorno a un punto de equilibrio constante independiente-mente del numero de SU que hubiera activas que permi-tiera tener a la red una tasa de procesamiento de tran-sacciones optimas.

De igual manera, existe una tasa maxima de bloquesque la red es capaz de procesar para poder garantizarel tiempo necesario en las tareas de validacion. Este va-lor inferior es necesario para garantizar la supervivenciade los nodos con menor capacidad de procesamiento. Noobstante, habida cuenta de que la arquitectura de Nubede Peers de Dain permite establecer una capacidad mıni-ma del nodo para poder participar en tareas especıficas,estos valores pueden ser estimados matematicamente ycomprobados de forma heurıstica.

DRAFT

DAIN 41

Igualmente la Noesis permite monitorizar en todo mo-mento la tasa en la que estos bloques se estan produ-ciendo tanto a nivel individual de la SU como a nivel glo-bal, permitiendo establecer reglas de validacion disenadaspara ajustar dinamicamente el tiempo de produccion debloques de cada Su individual de forma que se garanticeese punto de equilibro de produccion de bloques globalestable.

De acuerdo con esto, el servicio debe presentar la si-guiente propiedad:

− Minimal Service Event (MSE): Es el numero mıni-mo de bloques publicados por Mainnet que deberespetar cada SU de la red entre bloque y bloque.

− Targeted Service Event (TSE): Es el numero de blo-ques publicados por Mainnet que debe conveniente-mente debe respetar cada SU de la red entre bloquey bloque para garantizar una tasa de procesamientode transacciones optima que se adapte a la conges-tion del Mempool de la red.

La Validacion Encadena es el mecanismo de verifica-cion que asegurar que los bloques producidos por la SUse han generado respetando este valor de TSE.

Por los motivos descritos, el valor fijado para TSE nun-ca podra ser inferior a MSE.

Para ello, cada bloque producido por una SU enStrandnet debe referenciar el numero de secuencia delultimo bloque producido en Mainnet. Esto permite ga-rantizar que dicho bloque se produjo de forma sıncronaen la red.

Para ello Mainnet lleva el recuento de todos los ser-vicios activos. De esta forma solo las SUs que formanparte del registro pueden publicar. Mainet tambien llevala contabilidad del numero de secuencia de cada SU, deesta forma los nodos validadores pueden comprobar facil-mente si el numero de eventos entre un nuevo bloque deuna SU y el anterior ha respetado la cantidad de eventosimpuesta por TSE.

4. Modelado de la Produccion

Desde el punto de vista del modelado de la produccionde bloques, la produccion de bloques de cada SU puededefinirse como un Proceso de Poison independiente cuyatasa tiene una cota inferior de valor MSE. Matematica-mente hablando, se cumple la propiedad de que la sumade varios Procesos de Poison dan lugar a su vez a unProceso de Poison cuya tasa es resultado de la suma detodos los procesos agregados. Esta aproximacion, seguirıarespetando el modelo de produccion de bloques que per-mite estimar y controlar la probabilidad de colision enentornos de produccion simultanea de bloques.

En DAIN este proceso de Poison se da, pero no atravesde medidas de tiempo sino atraves del reloj descentrali-zado basado en eventos que proporciona Mainnet.

Figura 24. Proceso de Poisson en PoT

En conclusion, la produccion global serıa el Proceso dePoison resultante de sumar todos los Procesos de Poisonde las SU activas, y el tiempo promedio entre bloques detoda la red serıa proporcional a la fraccion entre TSE yel numero de SU activas en ese momento.

De esta manera, reajustar el tiempo concreto de crea-cion de bloques supondrıa ajustar el valor asignado aTSE en funcion del numero de SU activas que hay encada momento.

5. Ordenamiento Topologico

Cada DAG tiene un orden topologico: un ordenamien-to de los vertices tal que el punto inicial de cada aristaocurre antes en el orden que el punto final de la arista. Laexistencia de dicho orden se puede utilizar para caracte-rizar el DAG. Existen multiples posibles configuraciones:

Un DAG tiene un orden topologico unico si y solosi tiene una ruta dirigida que contiene todos losvertices, en cuyo caso el orden es el mismo que elorden en que aparecen los vertices en la ruta. Estees el caso de una cadena.

Un multitree (tambien llamado grafico fuertementeambiguo o manglar) es un grafico dirigido en el quehay como maximo un camino dirigido (en cualquierdireccion) entre dos vertices; de manera equivalen-te, es un DAG en el que, para cada vertice v, elsubgrafo alcanzable desde v forma un arbol.

Un polytree es un grafico dirigido formado por laorientacion de los bordes de un arbol libre. Cadapolytree es un DAG. En particular, esto es ciertode las arborescencias formadas al dirigir todos losbordes hacia afuera desde las raıces de un arbol.

El ordenamiento topologico de un DAG tiene impor-tantes implicaciones tecnicas, aunque pueden resumirseprincipalmente en tres:

Redundancia: la redundancia de caminos en unDAG supone un coste innecesario de recursos

DRAFT

DAIN 42

computacionales dedicados al almacenamiento deinformacion. Las relaciones entre las aristas y losvertices sera informacion almacenada de forma in-mutable por medio de tecnicas criptograficas.

Eficiencia: La forma de establecer las aristas y losvertices tiene un alto impacto en terminos de tiem-po y recursos computacionales que deben invertirlos algoritmos relacionados con el calculo de pesosy caminos mınimos.

Carga de trabajo acumulado: Los cantidad de verti-ces no referenciados por orden topologico indica lacantidad de bloques pendientes de confirmacion.Cuantos mas bloques se produzcan pendientes deconfirmacion, las labores de certificacion y confir-macion se realizaran con una mayor frecuencia.

Convergencia: Es necesario que el DAG se conver-gente, de lo contrario podrıan existir multiples ca-minos con informacion diferente y, si el consenso lopermite, informacion contradictoria.

Como puede comprobarse, una cadena es de hecho unDAG con un ordenamiento topologico especıfico. En estesentido, la cadena es, de hecho, el ordenamiento topologi-co mas eficiente. Estas causas ponen de manifiesto la ne-cesidad de implementar tecnicas que gobiernen el DAGpara definir la forma topologica con que este evolucio-nara de tal manera que minimicen el impacto de estasimplicaciones.

6. Estado de Equilibro de Strandnet

En funcion del numero de SU activas y del compor-tamiento particular de las SU produciendo bloques, elDAG ira construyendose segun alguno de los siguientesescenarios:

Normalidad: las SUs estaran totalmente desincroni-zadas. En este caso, harıa que el DAG se asemejaralo maximo posible a una cadena, permitiendo quelos bloques fueran llegando de uno en uno.

Alta demanda: La alta demanda harıa que la tasade bloques subiera, provocando con mayor frecuen-cia situaciones de colision y el comportamiento decadena se convertirıa en un comportamiento de ma-lla convergente.

Congestion: Si la creacion de bloques es extremada-mente alta, el DAG se comportarıa como una mallano convergente.

Este mecanismo hibrido entre un DAG y una cadenaconvencional, permite que la red tenga capacidad sufi-ciente para estresarse en funcion de la demanda. CV per-mite establecer control sobre los tres escenarios: el au-mento sorpresivo de la demanda se gestiona permitiendo

que la cadena pueda crecer verticalmente, luego la situa-cion se reconduce a un punto de equilibro modificando elvalor fijado para TSE.

En cualquiera de los escenarios, CV garantiza que Gno-sis tiene capacidad suficiente para tratar todos los blo-ques, por medio del umbral MSE. Si dicha capacidadfuera rebasada, el mecanismo de consenso de la red re-formularıa inmediatamente las condiciones con que la redse comporta, ajustando TSE y devolviendo la red a la si-tuacion de normalidad.

7. Validaciones de Strandnet

El consenso se basa en el respeto por una reglas univer-sales que modelan el comportamiento de la red en su con-junto como un fenomeno emergente del comportamientoindividual de cada nodo.

El consenso implica por tanto que deben implementar-se tecnicas que permitan certificar el respeto por dichasreglas, repudiando aquellas actividades consideradas des-honestas. Dain responde a esta necesidad por medio dedos vıas:

Por el lado emisor: Proporcionando pruebas (de-mostraciones) del cumplimiento de dichas reglas.Este es el procedimiento habitual implementado enredes Blockchain. En este caso, la parte que soli-cita la atencion hace un esfuerzo mayoritario en elconsenso.

Por el lado receptor: Cuando no existe forma deaportar pruebas, se aplican validaciones que per-mitan identificar su incumplimiento. Este tipo dereglas suelen aplicarse en sistemas de proposito ge-neralista. En este caso, la parte prestadora de laatencion hace la parte mayoritaria del trabajo enel consenso habida cuenta de que implica procesosbasados en la investigacion que se ejecutan en latotalidad de la red.

Tanto pruebas como validaciones son mecanismos he-redados del mundo del anti-spam: permiten esclarecer sihay que atender una peticion en base a sus intenciones.En el consenso, esas intenciones hacen referencia al res-peto por las reglas.

Habida cuenta de que la parte prestadora podrıa ofre-cer su atencion a multiples partes solicitantes, dependien-do de la carga de trabajo implıcita en la validacion, em-plear validaciones pueden resultar inconveniente ya quepueden provocar la congestion. En los mecanismos deanti-spam, este es el dilema del verificador : Los propiosmecanismos desplegados para evitar un ataque DoS oDDoS provocan a su vez el efecto que tratan de evitar.Estos casos, se resuelven utilizando pruebas.

No obstante, es posible que en funcion de las carac-terısticas que se pretendan demostrar, no exista ningunmecanismo ideado basado en pruebas; sobre todo, a me-dida que los sistemas se vuelven cada vez mas sofisticados

DRAFT

DAIN 43

y rigurosos con sus medidas de seguridad resulta cada vezmas inevitable introducir validaciones.

Una tecnica de consenso podrıa incluso tener su cargade trabajo repartida entre ambos lados, pruebas y vali-daciones.

En Dain se aplican diversas de estas tecnicas utilizandouna estrategia basada en prioridades: un modelo basadoen multiples tecnicas (pruebas y validaciones) en casca-da que en su conjunto balancean y minimizan el traba-jo total del consenso, pudiendo alcanzar altos niveles deseguridad y lograr una gestion eficiente de los recursoscomputacionales.

Concretamente, las validaciones llevadas a cabo son:

Validacion Multifirma: se comprueba que el pro-ductor del bloque ha sido previamente autorizadoy es una SU activa. Esta comprobacion se hace pormedio de la firma realizada con la clave publica re-sultante del algoritmo DKG durante la formacionde la SU. Esta firma ademas actua como certifica-do de la conveniencia y la satisfaccion de las DPUsde la SU con la actividad realizada y su supuestaconfianza en el respeto de la reglas de la red paracon la informacion publicada en el bloque.

Validacion Encadena: se comprueba el respeto alvalor TSE.

Onboarding: se comprueban que las transaccionesdel bloque le corresponden a dicha SU.

En caso de que posteriormente se identifique alguna in-fraccion, los nodos seran declarados deshonestos y trans-feridos a la lista negra.

Figura 25. Validacion de Bloques

8. Snapshoting

Una tecnica que se aborda para lidiar con los proble-mas de la redundancia y la eficiencia es el snapshoting.El Snapshoting permite aplica la propiedad de reducciontransitiva para crear una version simplificada del grafoque contiene el resumen de toda la informacion produci-da dando a lugar un nuevo bloque genesis sobre el que sevolvera a seguir construyendo el DAG.

En Dain, el Snapshoting es realizado por Backbone,permitiendo que la red Gnosis se libere del historico alcompleto del DAG y descargar ası su memoria, permi-tiendo que dispositivos especializados con alta capacidadde almacenamiento conserven el historico.

El Snapshoting es un proceso consensuado entre todoslos dispositivos de la red, el nuevo bloque genesis podraser calculado igualmente por cada uno de los nodos dela red Gnosis para confirmar que el nuevo bloque gene-sis publicado por Backbone realmente almacena toda lainformacion y es por tanto confiable.

El Snapshoting puede aplicarse mediante la busquedadel Diagrama de Hasse del DAG. Los diagramas de Has-se llevan el nombre de Helmut Hasse (1898-1979); segunGarrett Birkhoff (1948), son llamados ası por el uso efec-tivo que Hasse hizo de ellos. Sin embargo, Hasse no fueel primero en usar estos diagramas.

En matematicas, un diagrama de Hasse es una repre-sentacion grafica simplificada de un conjunto finito par-cialmente ordenado de tal forma que se elimina la infor-macion redundante. Para ello se dibuja una arista ascen-dente entre dos elementos solo si uno sigue a otro sinhaber otros elementos intermedios.

En un diagrama de Hasse se elimina la necesidad derepresentar:

Ciclos de un elemento, puesto que se entiende queuna relacion de orden parcial es reflexiva.

Aristas que se deducen de la transitividad de larelacion.

Un diagrama de Hasse puede verse tambien como unDAG tras haber aplicado la reduccion transitiva. En elcaso de DAIN, este modelo proporciona ciertas ventajas:

Reduce al maximo la redundancia de caminos parallegar a los bloques, permitiendo introducir algorit-mos mas simples y rapidos para recorrer el grafo.

Introduce la mayor cantidad posible de bloques encada camino. Simplificando la forma de medir laconfianza acumulada de cada bloque mediante pro-blema de flujo de coste mınimo.

Elimina la redundancia de la informacion, haciendoque el almacenamiento de la informacion sea lo maseficiente posible.

C. Honestidad de la red

Gnosis tambien se encarga de aplicar las tecnicas quepermite validar las pruebas del cumplimiento de los me-canismos de consenso que velan por el correcto funciona-miento de la red.

Esto permite a Gnosis identificar a aquellos nodos,DPUs y Proveedores infractores con los que formar listasnegras de nodos.

DRAFT

DAIN 44

Los nodos y proveedores con actividad infractora sonidentificados durante los procesos de validacion.

Dado que la infraccion es un fenomeno de red que debedarse en cada uno de los nodos Gnosis este proceso debedarse de manera global en la red. Si el nodo/proveedorse identifica como infractor por una denuncia falsa, dichadenuncia provendra de un nodo deshonesto y por tantosera un fenomeno local.

Para controlar esta situacion, cada vez que una DPUValidator de Gnosis identifica a un grupo de infractores,emite un bloque local con sus identidades y la posiblepenalizacion economica asociada. Si este bloque se con-firma, significara que fue emitido de forma dispersa pormultiples nodos de Gnosis y por tanto podra considerarseun fenomeno de red y no local.

Si tal cosa ocurre, las identidades del bloque pasan aformar parte de la lista negra. Las intervenciones de cadaDPUs/proveedor seran cotejadas con esta lista. En casode estar presente, la actividad del nodo/proveedor serabloqueada.

La duracion de la presencia del nodo en la lista de-pendera de la gravedad de la infraccion. Como la identi-dad del infractor estara en un bloque almacenado en lacadena, existira informacion de contexto que podra serempleada para borrar al infractor de la lista si se dandeterminadas circunstancias.

DRAFT

DAIN 45

XII. KNOT CONSENSUS

El consenso en Knot es un conjunto de pruebas y vali-daciones en cascada que permite la certificacion manco-munada sobre el cumplimiento de una serie de condicio-nes universales recogidas la entidad logica denominadaContrato que permiten la creacion del DAG con las cua-lidades mencionadas y un comportamiento controlado dela red.

Los mecanismos permiten filtrar e identificar aquellaspracticas y actividades que violan el cumplimiento delcontrato para ası poder ser rechazadas y penalizadas.

A. Bases del Consenso

1. Objetivo

Un algoritmo de consenso debe contemplar el funcio-namiento de toda la red como un sistema unico siendocapaz de ofrecer:

1. Sincronismo: Propiciar el tiempo entre bloques evi-tando el solapamiento con el tiempo de propagacionpara garantizar el sincronismo de la informacion enla red haciendola disponible entre los nodos parafacilitar que su toma de decisiones independienteeste alineada y sea en comun con el conjunto.

2. Descongestion: Preservar la funcionalidad de la redadaptando la carga de trabajo a las capacidadescomputacionales de los dispositivos que la compo-nen.

3. Proteccion: Proteger la red de ataques dirigidos conmecanismos evitando la propagacion de informa-cion irrelevante o maliciosa y garantizar que la in-formacion honesta no ha sido alterada mientras sepropaga por la red desde su punto de origen.

4. Adaptabilidad : Adaptar estos mecanismos a las cir-cunstancias actuales de la red para permitir queesta escale y se adapte a la demanda.

B. Contrato

El Contrato es una entidad logica que reune una seriede condiciones universales y comprobables, una normasbasicas de consenso que actuan como la constitucion de lared. Dicha constitucion esta disenada para proporcionara la red ciertas cualidades.

1. Clausulas

El contrato esta compuesto por multiples clausulas.Cada clausula recoge una condicion que establece como

debe prestarse el servicio para velar por una o varias ca-racterısticas del consenso.

Desde un punto de vista tecnico, una clausula es elumbral que debe cumplir una determinada Propiedad delservicio para considerarse la informacion producida comovalida.

Las propiedades de los servicios son manejadas porlos mecanismos descritos en el ciclo de vida de la SU:El Proceso de Contratacion, el sistema de anti-spam detransacciones, el Mecanismo de Onboarding, la valida-cion Encadenada, la Validacion Multifirma y el QuorumConfirmation. Estos mismos mecanismos son los respon-sables de validar y forzar que las Propiedad se cinen a losvalores determinados por las clausulas.

Las propiedades son valores cuantitativos que refle-jan una realidad sobre el servicio. A veces, las propieda-des pueden extraerse de un valor exacto conocido, comopodrıa ser la cantidad de DPUs que forma una SU. Otraveces deben estimarse con una funcion, como por ejemplola dispersion de una SU.

Las clausulas son valores cuantitativos que se calculana traves de modelos basados en funciones matematicas yalgoritmos para reflejar el valor deseado que deben tomarlas propiedades en funcion de la solicitud que atiendeel servicio y del estado de la red. A estos modelos losdenominamos Modelos de Gobierno.

Los modelos de gobierno establecen el valor de las clau-sulas para garantizar el cumplimiento de una serie de cri-terios. Los criterios velan por proporcionar a la red unconjunto de caracterısticas como, por ejemplo, la escala-bilidad, la descentralizacion, etc.

Por poner un ejemplo de lo expuesto y facilitar su com-prension: el contrato contara con un modelo que estaradisenado para cubrir un criterio de escalabilidad que es-tablecera el valor aceptable (clausula) que debe tomar elnumero de DPUs que forma una SU (propiedad) duranteel Proceso de Contratacion.

En cualquiera caso, una clausula establece un conveniouniversal sobre el valor que debe tomar la propiedad paraconsiderarse valido en la red.

2. Modelos de Gobierno

Los modelos de gobierno estan parametrizados por va-riables internas que representan el estado de Strandnet yse van ajustando dinamicamente a las circunstancias delsistema para poder autoregular las clausulas, adaptar elcomportamiento de la red y reaccionar ante condicionan-tes externos.

Haciendo una analogıa con un sistema conocido: Bit-coin aumenta la dificultad de la prueba de trabajo cuandodetermina que el tiempo entre bloques ha traspasado unumbral superior. Para Bitcoin, esta circunstancia signi-fica que la cadena esta creciendo a un ritmo superior alestablecido por diseno ya sea por la participacion de nue-vos mineros o la mejora del hardware de los ya existentes,y por tanto, debe volver a regularse.

DRAFT

DAIN 46

Estas variables internas se calculan a partir de informa-cion disponible en el DAG en una ventana de observacion,lo suficientemente amplia para considerar la informacionrepresentativa del estado del DAG. Algunos ejemplos deestas variables internas podrıan ser:

− Numero de SU activas.

− Numero de Proveedores activos.

− Numero de masternodes activos.

− Numero de DPUs Validator activas.

− Numero de DPUs Workers activas.

− Tiempo efectivo de creacion entre bloques.

− Tiempo estimado de propagacion de bloques.

− Probabilidad de colision efectiva.

El input de los modelos de gobierno, a su vez, sonlas propias solicitudes, de tal forma que tambien pue-den adaptarse a las necesidades y caracterısticas de cadasolicitud.

Siguiendo el ejemplo anterior, para una solicitud con-creta en una situacion concreta de la red, existira unmodelo de gobierno en el contrato que determine comoclausula la cantidad de DPUs mınimas que son necesariaspara formar la SU responsable de atender la solicitud. Pe-ro dicha cantidad podra ser distinta con otra solicitud, opara la misma solicitud si las condiciones de la red, comopor ejemplo numero de DPUs disponibles, cambia.

3. Condiciones Maestras

La actualizacion de las variables internas del mode-lo de gobierno se produce cuando determinados eventosuniversales y de relevancia para la red se producen. Estascondiciones se denominan Condiciones Maestras.

Cada clausula del contrato podrıa tener su propia con-dicion maestra.

Algunos ejemplos de condiciones maestras podrıan ser:

− Numero de bloques colisionados.

− Una cantidad concreta de bloques validados en se-cuencia.

− Una cantidad concreta de bloques confirmados ensecuencia.

− Una cantidad concreta de tokens transferido

− Alta o Baja de un Masternode en la red.

La funcion que controla el aumento o la reduccion dela dificultad en Bitcoin es en verdad un convenio al quetodos los nodos de la red estan sujetos. Cada nodo dela red conoce estas condiciones ya que son definidas por

diseno. Cada nodo de la red puede calcular por su cuentael valor actual de estas variables y determinar el momentoen que deben actualizarlas dado que dicha circunstanciapuede extraerse de eventos producidos en la cadena.

En el caso de Bitcoin, la reevaluacion de la dificultad dela prueba de trabajo, se lleva a cabo siempre que la redproduce una cantidad determinada de bloques nuevos.En Knot esta serıa la Condicion Maestra.

Es importante escoger correctamente cual debe ser esacondicion en funcion de la criticidad de lo que debe re-gularse y el grado de adaptabilidad que precisa.

Por ejemplo, un hardfork de Bitcoin produjo una mi-gracion masiva de mineros. Habida cuenta de que la difi-cultad solo se recalcula alcanzada una cantidad determi-nada de bloques, al producirse la fuga, la dificultad de laprueba de trabajo no bajo. En las nuevas circunstancias,no obstante, existıa solo una parte del poder computacio-nal anterior, derivando en un aumento significativo deltiempo que le tomaba a la red crear un nuevo bloque.Este cambio tuvo graves consecuencias sobre la capaci-dad transaccional de la red, que no era capaz de ajustarsea la demanda y, por momentos, se voy expuesta a la con-gestion.

Hasta que Bitcoin no fue capaz de producir la cantidadde bloques restantes para alcanzar la condicion maestra,este ajuste no se produjo. Esta circunstancia, se alargomucho en el tiempo, habida cuenta del tiempo efectivoque ahora le tomaban a los mineros restantes producirlos nuevos bloques.

Siguiendo la analogıa con PoW, para Knot la dificultaddel puzzle computacional serıa la propiedad; la funcionque determina la dificultad en funcion del tiempo entrebloques medido es el modelo de gobierno; el valor resul-tante admisible para la red de dicha dificultad serıa unaclausula. La prueba de trabajo, serıa el mecanismo delprotocolo Bitcoin implicado en los procesos de produc-cion y validacion del ciclo de vida del bloque. Y el numerode nuevos bloques producidos, la condicion maestra.

En Knot, no obstante, hay diferencias. En primer lu-gar existen varios mecanismos disenados para velar por elconsenso. No existe una, sino un conjunto de clausulas.Cada clausula esta gobernada por uno o varios mode-los. Todas las clausulas compondrıan el contrato y todasestarıan asociadas a una solicitud.

XIII. CRITERIOS DE KNOT

1. Gobierno: Permitir controlar la evolucion deStrandnet para garantizar su convergencia.

2. Congestion: Garantizar la descongestion de la redy la supervivencia de todos los dispositivos.

3. Eficiencia: Emplear los recursos computacionalesadecuandolos lo maximo posible a la demanda desoluciones y las capacidades puntuales de la red.

DRAFT

DAIN 47

4. Descentralizacion: Garantizar el fair-play del sis-tema de incentivos para que todos los nodos de lared puedan sacar provecho del sistema y quieranperpetuar su participacion en la red. Garantizarque todos los nodos estan conforme con la formaen que se reparten los beneficios en funcion de suactividad.

5. Capacidad: Ser capaz de adaptar las capacidadesde la red a la demanda solicitada sin que eso su-ponga un deterioro del servicio.

6. Escalabilidad: Garantizar la escalabilidad de to-da la red permitiendo que un aumento de nodosrevierta en un mejor funcionamiento y no al con-trario.

7. Seguridad: Garantizar que los actores de la redgozan de la reputacion suficiente para considerarlosconfiables.

A. Modelo de Costes

La capacidad de la red entregada a disposicion de cadauna de las solicitudes podra ser ajustada en funcion dela dificultad de cada problema mediante el dimensiona-miento de las SUs.

Con este proposito, el contrato define la siguientes clau-sulas:

− Size (Si): Cuantas son las DPUs que forman la SUcomo mınimo.

− Resilience Availability (RA): Proporcion de DPUsBack-up que deben forma la SU.

− Supervision Range (SR): Numero de DPU Super-visor que deben formar la SU.

El valor de estas clausulas podra ser fijado conformediferentes motivos:

Problemas N :

Estimanda la dificultad de cada problema es posi-ble valorar cual es la capacidad necesaria de la SUasignada para el tiempo de resolucion del problematienda a un valor conocido. Ese valor, podrıa impo-nerlo el propio cliente como un SLA o bien atendera las necesidades de la red.

Determinar exactamente cual es el poder compu-tacional idoneo a destinar a cada problema, permi-tira tener la solucion lo mas pronto posible aprove-chando al maximo los recursos y dimensionando lacapacidad de la red, siempre y cuando se conozcala cantidad de operaciones que son necesarias paradarle una solucion al problema.

Por ejemplo, resolver computacionalmente la eje-cucion de una red neuronal de pocas capas, podrıa

ser un problema resoluble de forma casi inmediata.La SU sobredimensionada en capacidad encarga-da del problema deberıa esperar el tiempo restanteque le queda desde que resolvio el problema pa-ra alcanzar TSE y poder emitir el bloque con lafacturacion del problema. Lo mismo ocurrirıa conel problema opuesto. Resolver con un numero decapas muy grande con una SU infradimensionada,obligarıa a esperar un tiempo muy superior a TSEpara poder contar la solucion al problema.

Problemas NP :

Cuando tener la solucion al problema antes de TSEno sea una necesidad o no sea posible estimar lacantidad exacta de operaciones necesarias para en-contrar la solucion, controlar la capacidad de cadaproblema permitira distribuir el trabajo correcta-mente en funcion de la demanda y la disponibilidaddel sistema, de forma que ninguna parte de la redeste ociosa en ningun momento siempre que hayademanda.

La factorizacion en numeros primos es un problemacuya algoritmia emplea la comprobacion del Test dePrimalidad en un numero de pasos indeterminado.No puede saberse el tiempo que tardarıa el proble-ma en resolver, aunque existe una alta probabili-dad de que finalice en tiempo polinomial siemprey cuando haya suficientes numeros primos y estosesten distribuidos de forma mas o menos unifor-me. En este escenario, no hay un criterio claro quepermita aventurar con exactitud que poder compu-tacional es adecuado para resolver el problema enTSE. Es mas necesario, por tanto, asegurar que elproblema se atiende de tal forma que en algun mo-mento se le encuentre una solucion sin destinar aello una ocupacion de la red tal que accidentalmen-te se incurra en una denegacion de servicio a otrosproblemas.

Puede darse el caso incluso, de que interese ofre-cerle al cliente la posibilidad de decidir por sı mis-mo cuanta capacidad computacional quiere, espe-cificandolo en la solicitud.

El Modelo de Coste es una forma de medir la difi-cultad de los problemas propuestos. El Modelo de Cos-te utiliza fundamentos de la teorıa de la complejidadcomputacional? para determinar el coste computacionaltotal en medidas de complejidad operacional (numero deoperaciones), complejidad temporal (tiempo) y comple-jidad espacial (memoria) que requiere cada solicitud deservicio en la red.

Con este resultado, puede establecerse el numero deCelulas de Recursos optimos para cada cosa. Al mismotiempo, fijado el valor basal de la celula de recursos, elModelo de Coste permite servir de estandar en la red conel que medir el coste en tokens del trabajo realizado.

Dependiendo del tipo de Problema de la Suite (NP oP), el Modelo de Coste podra estimar:

DRAFT

DAIN 48

NP: Coste Medio de una Iteracion. El numero me-dio previsible de Iteraciones (si puede).

P: Coste de la Ejecucion Integral.

B. Modelo de Descentralizacion

Las clausulas que permiten velar por la descentraliza-cion de la red y el fair-play del modelo de incentivos son:

− Descentralization (De): Cuantos Proveedores for-man la SU.

El criterio de Descentralizacion esta dirigido por el Pro-ceso de Contratacion, el cual garantizando el valor de Dede la SU formada, repercuten en la distribucion del tra-bajo y la forma de incentivar la participacion de nuevosdispositivos. A este respecto, el proceso de Contrataciontiene en cuenta que:

− En funcion de la demanda y la ocupacion de la red,las DPUs ociosas y disponibles, no siempre seranlas mismas. Por tanto, hasta las DPUs con pocostokens tendran oportunidad de figurar como Mas-ters. Al introducir esta aleatoriedad implıcita basa-da en la ocupacion de la red y la propia demanda,se combate la centralizacion y se evita constituir unpatron de comportamiento que pudiera ser aprove-chado para llevar a cabo un ataque.

− Proveedores con varias RCs seran favorecidos alotorgarles mas probabilidades de participar en unservicio permitiendo potenciar la aportacion de po-der computacional a la red. Pero este factor de cen-tralizacion se neutraliza combatiendo la discrimina-cion de los proveedores menos participativos graciasa esta clausula.

El modelo de descentralizacion es la funcion matemati-ca que asigna la clausula De en busca de una situacionde compromiso entre la descentralizacion de la red y larigurosidad en el numero de Proveedores admisibles enuna SU en funcion de las posibilidades de la red (canti-dad de RCs disponibles en la red) y de las necesidades dela solicitud (cantidad de RCs que deben forman la SU).

C. Modelo de Convergencia

El modelo de Convergencia establece cuantas confir-maciones son necesarias para que un bloque sea conside-rado confirmado en la red. Este mecanismo da idea de laversatilidad que tienen las SUs para escoger bloques pen-dientes de confirmar, la convergencia del grafo y el gradode confianza alcanzado por el bloque para asumir que lared esta preparada para ser notificado como resuelto.

− Confirmation Threshold (CT): Cantidad acumula-da de DPUs confirmantes relativas a la tasa de con-firmacion necesarias para confirmar el bloque.

El modelo de construccion es la funcion matematicaque determina el umbral que un bloque debe alcanzar deconfirmaciones relativas a su posicion en el grafo, ya seadirectas o acumuladas en funcion del numero de DPUsque formaba la SU que lo fabrico y el tipo de bloquepublicado.

D. Modelo de Congestion

A la hora de tener en cuenta las confirmaciones, laProbabilidad de Colision toma especial relevancia: Indicala frecuencia con que dos o mas bloques aparecen con elmismo numero de secuencia.

En este sentido, si ademas dichos bloques son confir-mantes de los mismos bloques, la Probabilidad de Co-lision tambien da idea del grado de retrabajo de certi-ficacion innecesario que podrıa haberse realizado. Peromas importante aun, la Probabilidad de Colision indicala probabilidad de que exista mas de un bloque pendientede confirmacion, por lo que tambien da idea de la canti-dad de trabajo pendiente de certificacion que se acumulaen la red.

En un DAG un bloque nuevo es, en realidad, un bloquevalido apilado en una cola de confirmaciones pendientes.Cuando una colision se produce, esa cola crece sorpresi-vamente. La capacidad de esa cola, se mide en funcion dela capacidad de la red e impacta en la cantidad de tra-bajo asumible por unidad de tiempo para confirmar y, loque es mas importante, certificar bloques si es que dichopaso se realiza en la confirmacion como es el caso quenos ocupa. Habida cuenta de que la certificacion puedeser un proceso intensivo en recursos, sobrepasar la capa-cidad de la cola, supondrıa acumular el trabajo pendienteen la red, congestionarla y desestabilizarla finalmente pordesbordamiento.

Strandnet debe ser capaz de ajustarse a la demandade confirmaciones pendientes garantizando que no se des-bordan los recursos disponibles en el sistema. Por tanto,en funcion de la probabilidad de colision presente en lared, se establece el valor:

− Certification Capacity (Ce): Cantidad de bloquesque debe certificar la SU.

El cual permite estimar la cantidad de trabajo que ca-da SU debe destinar en la certificacion de los bloquesproducidos, para determinar la velocidad con que la redpueda ir resolviendo estas labores asıncronamente y nose sature.

E. Modelo de Capacidad

La capacidad de la red se regula para permitir que elconsenso en la red permanezca invariante a pesar de laocupacion y la demanda de las soluciones y transaccio-nes. La forma de lograr esto se hace en funcion de lasclausulas:

DRAFT

DAIN 49

− Minimal Service Event (MSE): Mınima cantidad debloques publicados por Mainnet que debe respetarla SU en la publicacion de sus propios bloques.

El modelo de capacidad fija el valor para MSE vigenteen la red en funcion de las SU activas, de tal forma que seaporten garantıas de que el tiempo entre bloques globalsea estable.

El tiempo entre bloques es el valor que guarda relacioncon la Probabilidad de Colision y la fercuencia con quedeben resolverse tareas de validacion. MSE por tanto,establecer control sobre el garantizar el consenso, ya queasegura que el conjunto de toda la red esta sincronizada ytiene al mismo tiempo la misma informacion para tomarlas mismas decisiones.

El estudio detallado de todas estas circunstancias de-be servir para establecer una Probabilidad de Colisionaceptable en la red que sirva como criterio de diseno.

El valor por diseno fijado de tiempo entre bloques esun valor establecido por el Modelo de Capacidad. Estemodelo permite responder a la pregunta de cuanta cargade trabajo es capaz de soportar la red en funcion de lascaracterısticas tecnicas de las DPUs Validadoras.

F. Modelo de Escalabilidad

La escalabilidad es la cualidad de que la red puedacomportarse de la misma manera independientemente desus dimensiones. Para hacer esto, es necesario propor-cionar un comportamiento patron que se presente en lared independientemente de su tamano. Por hacer unaanalogıa, la red debe comportarse como un fractal: inde-pendientemente de si aumentamos o reducimos el foco,existe un comportamiento replicado.

La forma de lograr esto es mediante la propagacionmulticast que se parametriza en la red mediante las si-guientes clausulas:

− Dispersion (Di): Como es la dispersion de las DPUsque forman la SU en la red P2P.

− Render (Rd): Cuantas son las DPUs Delegate queforman la SU como mınimo.

El objetivo de la propagacion fractal multicast es ga-rantizar que el tiempo de propagacion de los bloque paraalcanzar la completitud de la red se mantiene constantey controlado independientemente del tamano de la red.Junto con el tiempo de creacion de bloques constante,esta cualidad permitira mantener constante la Probabi-lidad de Colision.

El modelo de dispersion es un modelo basado en elcalculo de distancias mınimas que permite medir cual esla dispersion de una SU dentro de topologıa de red actualy ası como determinar cual es la dispersion necesaria paragarantizar el tiempo de propagacion constante.

Este modelo impone condiciones a la ubicacion de losnodos escogidos para formar la SU. Igualmente, el mo-delo de dispersion puede establecer condiciones sobre el

numero de DPUs Delegates que deben formar la SU. Deesta forma, cualquier aumento o descenso sobre el numerode nodos podrıa gestionarse aumentando o disminuyendoel numero de estas DPUs.

El valor aceptado en la red como tiempo de propaga-cion dependera de la probabilidad de colision establecidapor diseno y el tiempo de creacion entre bloques cuyo va-lor viene restringido por la capacidad computacional delos dispositivos.

El modelo de dispersion puede calcular el valor efec-tivo del tiempo de propagacion a traves de la Probabili-dad de Colision, el cual puede calcularse a traves de losnumeros de secuencia de los bloques. Habida cuenta deque esta Probabilidad de Colision teorica estable puedeestablecerse para un valor concreto de TSE, siempre ycuando existan las mismas SUs activas, las desviacionessobre dicho valor teorico pueden adjudicarse al incremen-to o decremento del tamano de la red y por extension deltiempo de propagacion.

Con esta informacion, el Modelo de Dispersion puededeterminar la desviacion producida sobre el valor deseadopara el tiempo de propagacion y aplicar las correccionesnecesarias, aumentando o disminuyendo los valores aptospara Di y Rd.

G. Modelo de Reputacion

El modelo de reputacion fija el valor:

− Reputation (Rt): Estimar cuantitativamente cuales la honestidad de la actividad de una cuenta, ypor extension de un nodo que rinda rendimientos auna cuenta, basandose en las transacciones y com-portamientos previamente registrados.

Para ellos, el modelo analiza los flujos circulantes detokens y arroja una medida de riesgo que permite pun-tuar a los nodos y las cuentas. El modelo de reputaciones un sistema que permite a la red protegerse de actoresadversos.

Es utilizado tanto por el Proceso de Reclutamiento co-mo por el mecanismo de anti-spam de transacciones, paraidentificar que actividades y actores pueden ser malicio-sos.

DRAFT

DAIN 50

XIV. SEGURIDAD

Con estas tecnicas, Knot tambien logra establecer unconsenso entre todos los nodos de la red sobre la actividadde la SU.

Existen formas para eludir el proceso de certificacion,permitiendo que se confirme un bloque deshonesto debi-do a la actividad coordinada de un grupo de maquinasmaliciosas con un ataque estadıstico. En PoW estos esce-narios se producirıan con un ataque 51 % ; en PoS cuandolos nodos se coordinan siguiendo la teorıa de Nothing atStake. En un DAG, este escenario podrıa darse mediantecadenas parasitas.

Para lidiar con estas practicas sera igualmente necesa-rio garantizar que el proceso de confirmacion se realiza deforma segura y confiable y ası evitar a toda costa la pro-duccion de cadenas parasitas o ataques 51 %, respetandolos principios expuestos en la Premisa 1.

A. Ataque Sybil - Dimensionamiento de las DPUs

Una DPU sobredimensionada no gana beneficios extraspor disponer mas recursos en la SU. Al considerar suspares que dicha maquina aporta el mismo poder compu-tacional que el resto, solo le corresponde la parte propor-cional y solo firmaran el bloque en dichas circunstancias.

Una DPU sobredimensionada con proposito de ser maseficiente aportando Proof-of-Weight para ser mas exitosacuando competir como Master durante la etapa de con-curso de RP, no obtendrıa un beneficio significativo, yaque el factor determinante de la prueba es el scoring dela candidatura y la propuesta.

Igualmente, una DPU infradimensionada se expone aser expulsada de la SU al no ser capaz de dar respuesta ala ejecucion de codigo en las mismas condiciones que lasdemas.

B. Ataque Sybil - SU deshonestas

MsV garantiza que solo SUs integralmente honestas odeshonestas puedan ser validadas.

Por tal motivo, un atacante deberıa vulnerar el proce-so de contratacion y formar de base una SU deshonesta,para lo cual deberıa tener en consideracion multiples as-pectos:

En primer lugar, la SU deberıa resolver la fase de con-curso y contratacion con una propuesta valida que re-solviera el Proof-of-Handsake y Proof-of-Weight exitosa-mente, para lo cual deberıa:

Utilizar multiples dispositivos con una ubicacion es-pecıfica en la topologıa de red resolviendo correcta-mente para ello el alta de los nodos. Concretamenteel numero de dispositivos dependera del grado dedispersion requerida a la SU.

La alternativa a lo anterior, supondrıa tener unamaquina capaz de simular diferentes nodos de la redP2P, lo cual entranarıa la cooperacion de todos losmasternodos o la vulneracion del proceso de alta.

Uso de multiples cuentas asociadas a estos disposi-tivos con todo ello ofrecer la propuesta mas idoneaen terminos de descentralizacion.

Disponer la mayor cantidad de stake frente pro-puestas homologas.

Ademas, deberıa replicar este proceso varias veces(una por cada rol Supervisor disponible) y ası ocu-par simultaneamente posiciones inferiores en la re-solucion del concurso.

Todas estas condiciones, tanto por su complejidad co-mo por el coste en recursos hace de la formacion de unaSU una circunstancia altamente improbable.

El beneficio de hacerlo, ademas, no compensarıa al ata-cante, dado que su trabajo no supondrıa una mayor par-ticipacion en el DAG:

Los bloques que dicha SU fabricase deberıan pro-ducirse al mismo ritmo que el resto de SU de lared para ser consideradas validas, impidiendo quese acumulen confirmaciones que vulneren la resolu-cion del problema de los generales bizantinos.

Los productos fabricados y las transacciones incor-poradas, igualmente, deberıan ser expuestos al pro-ceso de certificacion por otros nodos.

Por ultimo, el mecanismo de embarque, imposibili-tarıa que la SU pudiera escoger transacciones queincorporar al DAG a conveniencia.

Por contra, si se identifican posibles irregularidades, ta-les faltas podrıan ser detectadas por Gnosis: desembocan-do en la aplicacion de penalizaciones y la incorporacionde los infractores en una Lista Negra que les impedirarealizar cualquier actividad en la que participen.

C. Ataque 51 %

Para que en el DAG se pudieran confirmar y fabricarbloques deshonestos, se deberıa poseer la mayorıa de lasSUs activas en la red.

Habida cuenta de la dificultad de crear una SU des-honesta a conveniencia, para provocar esta circunstanciahabrıa que realizar un enorme esfuerzo de alta comple-jidad cuya dificultad aumenta de forma exponencial enfuncion del numero de servicios en curso.

D. Doble gasto

Cuando una transaccion llega a la red, se propaga porGnosis haciendola publica. En ese momento la transac-cion pasa a ser parte de la Mempool de la red y se asociaa una SU por el Metodo de Embarque.

DRAFT

DAIN 51

El Metodo de Embarque garantiza que todas las tran-sacciones de un mismo cliente esten asociadas a la mismaSU, por lo que no puede existir competencia entre blo-ques por el mismo origen de fondos.

Durante su actividad, una SU produce bloques inclu-yendo dichas transacciones, previa certificacion de queninguna transaccion sobrepasa la capacidad de tokensdisponibles en la cuenta. De esta forma, las transaccionesde una cuenta siempre se procesaran secuencialmente y,hasta este punto, es la SU quien garantiza que no puedaejecutarse un doble gasto.

Gnosis recibe dichos bloques y marca las transaccionescomo validadas en su Mempool. Ningun bloque con tran-sacciones asociadas a otra SU asociada sera aceptado. Sihasta ese momento, la misma SU publica alguna transac-cion de iguales caracterısticas, esta se bloquea por estarmarcada en dicha memoria.

Una vez validado el bloque, este estara disponible pa-ra ser confirmado por una o varias SUs. Durante esteproceso, las SU confirmantes certifican de nuevo que lastransacciones incluidas no incurren en una situacion dedoble gasto, ni se sobrepasa el saldo de la billetera. ENcaso afirmativo, el bloque se confirma y la transaccion seborra de la Mempool.

En momento posteriores, ninguna de las transaccionesya procesadas podra volver a publicarse de nuevo, ya queal no existir en la Mempool, el bloque que la contenga,no sera validado.

Existe, en verdad, una situacion especial en que variasSUs pueden competir por la misma billetera: Cuando unaSU se crea emitiendo bloque de inicio de servicio con unapropuesta o termina emitiendo un bloque de fin de ser-vicio. Cuando cualquiera de estas dos situaciones se da,las transacciones pendientes de procesar de la SU serantransferidas a otra SU al reactivarse el Metodo de Em-barque. Para evitar que en el sorpaso existan bloques deambas SU con transacciones pendientes de confirmacioncon el mismo origen de los fondos, pudiendo incurrir enuna situacion de doble gasto, el traspaso de transferen-cias no se hace efectivo hasta que el bloque de Inicio oFin de Servicio sea confirmado. Ademas ninguno de estosbloques podran incluir transacciones publicas.

E. Ataque DDoS

Toda solicitud tiene asociado un coste de entrada quecubre las molestias de ejecutar el Proceso de Contrata-cion. Ademas, toda solicitud lleva asociada la reserva deun conjunto de recursos en la red. Una vez son contrata-dos la totalidad de esos recursos y la red en su conjuntotrabaja al 100 % de su capacidad, no seran admisiblesnuevas solicitudes.

RP es el mecanismo responsable de ello. Equivale aun mecanismo de registro y login. Cuando llega una so-licitud entrante, la SU candidata realiza un proceso deregistro en Gnosis que se paga con tokens. La validez dela identidad de dicho registro es confirmado o rechazado

por Gnosis a conveniencia del cumplimiento del Contra-to. Si la SU logra registrarse con exito, proporciona unmecanismo de identificacion basado en claves publicas yprivadas, que la SU debe emplear para interactuar conGnosis de forma securizada.

Todas las SU que logran registrarse conforman una lis-ta blanca de equipos autorizados para interactuar conGnosis en la publicacion de bloques. De tal forma quecompone un sistema de proteccion frente ataques DDoS.

Por estas causas, un ataque DDoS llevado a cabo consolicitudes supondrıa un coste elevado para el atacante,proporcional a la ocupacion que tal ataque supusiese parala red.

F. Cadena Parasita

DAIN no permite operaciones offline y su mecanismoQC implica que solo bloques presentes en todas las ver-siones de que los nodos tienen del DAG puedan confir-marse, extendiendose esta validacion a todos los bloquespredecesores del bloque a confirmar y, por consiguiente,obligando a que toda la informacion debe ser publica.

Esto significa que un bloque no puede confirmarse deforma clandestina por un subconjunto de nodos desho-nestos. Ya que el camino en el DAG que contenga esebloque jamas sera confirmado por el resto de la red, rein-corporandola al DAG principal y a la memoria del restode los nodos.

Tal cadena solo podra ser perpetuada por una SU for-mada por el conjunto de nodos deshonestos y como sevio, formar una SU de estas caracterısticas resultarıa ex-tremadamente complicado.

G. Competencia Desleal

La fase de contratacion del Proceso de Contratacionno permite la competencia entre nodos por una mismasolicitud, por lo que si un nodo malicioso quisiera re-solver por sı mismo una solicitud o realizar un ataque deman-in-the-middle para suplantar la identidad de una SUlegıtima obviando el resultado del algoritmo, este serıaidentificado al no disponer de la(s) clave(s) privada(s)que coinciden con la clave publica proporcionada y portanto, la resolucion de la solicitud serıa descartada al nopoder resolver MsV.

H. Corrupcion de la SU

Para que en una SU se pueda realizar un ataque desuplantacion de identidad, todas las DPUs Back-Up de-ben estar aliadas y tener la capacidad de convencer a unsubconjunto de las DPUs Slaves de la SU para amoti-narse y unirse para formar otra SU distinta a la que seencuentran con la misma clave publica.

DRAFT

DAIN 52

Por otro lado, la formacion de una nueva SU implicarıatambien atraer a la SU ilegıtima a las DPUs Supervisoras,quienes, de partida, obtendrıan un beneficio denunciandodicha actividad.

Eso supondrıa que todas las DPUs Back-Up deben serdeshonestas y ademas tener la capacidad de convencer aotras DPUs de volverse deshonestas sin obtener ningunbeneficio adicional de ello.

Habida cuenta de que las DPUs durante RP no se es-cogen a conveniencia, las probabilidades de que un grupotan heterogeneo de nodos sean a priori deshonestos esmuy baja. Y en caso de que se diera tal circunstancia,serıa preciso un alto coste en tokens para convencer a lasrestante.

Aun cuando se produjera, solo una SU podrıa resul-tar vencedora, ya que de estar ambas SU produciendobloques simultaneamente, no respetan MST (por la par-ticipacion de DPUs en ambas SUs) produciendose unainfraccion en CV.

I. Man-in-the-Middle

Aunque un bloque llegue a un nodo malicioso y aunqueel nodo disponga de una de las claves por participar dealguna forma en la SU con una o varias DPUs, no podraarticular un ataque de suplantacion de la identidad de laSU para quedarse con la facturacion, ya que no dispondrade todas las claves necesarias para firmar. Esto introduceun mecanismo de defensa ante ataques de man-in-the-middle.

Aun si un nodo decidiese modificar la informacion deun bloque ya validado vulnerando de alguna forma la fir-ma, dicho bloque no sera confirmado, ya que las SU no loreconoceran al ejecutar QC pues este no estara presenteen la totalidad de las DPUs que componen la SU.

DRAFT

DAIN 53

XV. GLOSARIO

RC - Resource Cell

CRC - Computational Resource Cell

SRC - Storage Resource Cell

DRC - Dynamic Resource Cell

RC - Resource Cell

DPU - Dynamic Process Unit

SU - Service Unit

DLT - Distributed Ledger Technology

DHT - Distributed Hash Table

RP - Recruitment Process

MsV - Multi-Signature Validation

OM - On-boarding Method

CV - Chainned Validation

McP - Fractal Multi-Cast Propagation

QC - Quorum Confirmation

DRAFT

DAIN 54

XVI. LEGAL DISCLAIMER

Cualquier comprador de los productos o servicios deDainware reconoce expresamente los conocimientos tecni-cos y incertidumbres del mercado que son inherentes acualquier proyecto de desarrollo de negocios como se pre-senta en este White Paper (vea a continuacion los facto-res de riesgo) y que, por lo tanto, este proyecto puedeno llegar a cubrir todas las expectativas expresadas enel. En tal caso, el comprador reconoce expresamente yacepta que no tendra derecho a demandar o interponerninguna accion legal directa o indirecta ante los tribuna-les, la organos de arbitraje o cualquier otro organo alter-nativo de solucion de controversias, ya sea en Espana oen el extranjero, en contra de la companıa, sus directo-res, accionistas, empleados o subcontratistas en caso deincumplimiento del performance, no desarrollo o no im-plementacion del proyecto, incluso en los casos en que suNegocio haya perdido valor.

Ademas, Dainware no se hace responsable de ningunode los siguientes:

(i) uso de servicios que no cumplan con los terminosaplicables;

(ii) incumplimiento, falla, mal funcionamiento o fal-ta de disponibilidad de los servicios debido a untercero, el comprador, un producto de terceros, oel incumplimiento del comprador de sus obligacio-nes;

(iii) danos indirectos tales como perdida o pertur-bacion comercial, perdida de ordenes, perdida ope-rativa, infraccion de la marca, perdida de benefi-cios o clientes (por ejemplo, divulgacion indebidade informacion confidencial). informacion relativaa dichos clientes debido a la falla o piraterıa dela Plataforma, procedimientos de terceros contra elcliente, etc.);

(iv) perdida, divulgacion o uso ilegal o fraudulen-to de las firmas de los usuarios por parte de loscompradores o terceros;

(v) suspension del acceso o suspension temporal opermanente de los servicios (en particular, que sur-ja de una solicitud emitida por una autoridad ad-ministrativa o judicial apropiada, o una notificacionrecibida de un tercero);

(vi) perdida, alteracion o destruccion de todo o par-te del contenido (informacion, datos, aplicaciones,archivos) u otros elementos) alojados en la infra-estructura, en la medida en que Dainware no esresponsable de administrar la continuidad de lasactividades de los compradores, y las copias de se-guridad de datos en particular;

(vii) desajuste entre los servicios y las necesidadesdel comprador (en particular, con respecto a la sen-sibilidad de los datos relevantes);

(viii) incidentes de seguridad relacionados con eluso de Internet, relacionados en particular con laperdida, alteracion, destruccion, divulgacion o ac-ceso no autorizado a los datos o detalles del com-prador en oa traves de Internet; y

(ix) danos a los sistemas, aplicaciones y otros ele-mentos instalados por el comprador en la infraes-tructura.

DRAFT

DAIN 55

REFERENCIAS