Top Banner
DIGILITE
42

DIGILITE - firebasestorage.googleapis.com

Jul 19, 2022

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: DIGILITE - firebasestorage.googleapis.com

DIGILITE

Page 2: DIGILITE - firebasestorage.googleapis.com

LA CADENA DE BLOQUES DESCENTRALIZADA MÁS

LIGH

Desarrollado por annonymous

comunidad

The digilite Team

([email protected]) Última

actualización: 10 de mayo de 2021

Versión 1.0

Descargo de responsabilidad Este documento pretende ser una visión general técnica. No pretende ser exhaustivo ni ser el diseño final; por lo tanto, no se cubren aspectos no básicos, como API, enlaces o lenguajes de programación.

Abstracto

La mayoría de los dispositivos financieros se implementan de manera centralizada a partir de hoy, aunque de naturaleza descentralizada. Se han expuesto muchos problemas: escalabilidad, alto costo operativo, problemas de privacidad, riesgos de seguridad y falta de valores funcionales. Blockchain, la descentralización por diseño, podría ser una buena solución a estos problemas. En primer lugar, blockchain es lo suficientemente elástico como para resolver el desafío de escalabilidad de las finanzas de una manera rentable. En segundo lugar, retener datos dentro de blockchains bien scoped elimina la preocupación de que los datos financieros se almacenen en la nube y potencialmente se filtren o abusen de

Page 3: DIGILITE - firebasestorage.googleapis.com

ellos. En tercer lugar, blockchain con contratos inteligentes y tokens tiene un enorme potencial para permitir la coordinación autónoma de dispositivos para crear valores funcionales. Sin embargo, las cadenas de bloques existentes tienen sus limitaciones frente a problemas financieros debido a las características especiales de las finanzas, como la gran cantidad y heterogeneidad de dispositivos, y las restricciones en la computación, el almacenamiento y la potencia, etc.

Este documento presenta DIGILITE, la cadena de bloques descentralizada más lighed impulsada por la comunidad anónima con cuatro innovaciones principales:

• Blockchains en blockchain para una red distribuida bien equilibrada que maximiza la escalabilidad y la privacidad de una manera rentable;

• Verdadera privacidad en blockchain basada en código de pago retransmitible, firma de anillo de tamaño constante sin configuración confiable y primera implementación a prueba de balas;

• Consenso rápido con finalidad instantánea que mejora en gran medida el rendimiento de la red y reduce el costo transaccional;

• Arquitecturas de sistema flexibles y ligeras basadas en digilite especialmente diseñadas para aplicaciones financieras clave en múltiples sectores de la industria.

Contenido

Lista de figuras

• DIGILITE: Blockchains en blockchain, una arquitectura rootchain y subchains. 13

• Transacciones entre cadenas de bloques .......................................................... 17

• Modelo de ancho de banda para compartir la capacidad de la cadena raíz ........ 18

• Una transacción en la cadena de bloques de Bitcoin ...................................... 23

• Una transacción confidencial con verificabilidad pública ............................. 23

• Prueba de participación delegada aleatoria (Roll-DPOS) ................................ 28

• DigiLITEPowered Shared Economy ....................................................................... 33

• Hogar inteligente con tecnología DIGILITE ............................................................ 34

Lista de tablas

• Beneficios financieros de las propiedades de Blockchain. . . . . . . . . . . . . . . .

9

Page 4: DIGILITE - firebasestorage.googleapis.com

• Comparación entre Rootchain y Subchain ...................................................... 14

• Técnicas de preservación de la privacidad para blockchains ................................ 19

• TRANSACCIÓN FINANCIERA [FINTRANS]

El DEPARTAMENTO DE FINANZAS está emergiendo rápidamente como la manifestación

de la visión de la sociedad en red: todo lo que se beneficia de una conexión está conectado. Sin embargo, esta transformación de largo alcance es solo el comienzo. Se

espera que el número de dispositivos de transacción conectados crezca un 28% anual, aumentando a 167 mil millones en 2022 [10] y se espera que el mercado global de finanzas crezca de 170 mil millones de dólares en 2017 a 72 billones de dólares para 2022 [15], a una tasa de crecimiento anual compuesta de 26. 9%. Aunque muchos expertos de la

industria financiera y usuarios entusiasmados han vinculado el dinero como la próxima revolución industrial o la próxima Internet, hay tres problemas principales que están frenando el desarrollo masivo y la adopción de las finanzas.

• Problema de escalabilidad

La mayoría de los dispositivos FINTRANS están conectados y controlados de forma

centralizada a partir de hoy. Los dispositivos FINTRANS están conectados a infraestructuras de back-end en servicios de nube pública o granjas de servidores locales para transmitir datos y recibir comandos de control. Actualmente, la escala de las transacciones financieras[fintrans]está embotellada por la escalabilidad y elasticidad de estas infraestructuras de back-end, servidores y centros de datos. Es poco probable que el

costo operativo sustancialmente alto de ejecutar la escala de FINTRANS esté cubierto por las ganancias de la venta de dispositivos. En consecuencia, muchos proveedores de FINTRANS no pueden proporcionar dispositivos y aplicaciones rentables que sean lo suficientemente escalables y confiables para escenarios del mundo real [35].

• Falta de privacidad

Se espera que FINTRANS permita la participación masiva de los usuarios finales en servicios

de misión crítica como la energía, la movilidad, la estabilidad legal y democrática. Los desafíos de privacidad se originan en el hecho de que FINTRANS interactúa con el mundo físico de manera directa y automática, y la cantidad de datos recopilados aumentará sustancialmente cuando se amplíe. Algunas de las amenazas comunes a la privacidad, enumeradas en [37], son:

• Identificación: Asociar un identificador (persistente), por ejemplo, un nombre y dirección o un seudónimo de cualquier tipo, con un individuo;

Page 5: DIGILITE - firebasestorage.googleapis.com

• Localización y seguimiento: Obtener la ubicación de un individuo a través de diferentes medios;

• Elaboración de perfiles: Compilar expedientes de información sobre individuos para inferir intereses por asociación con otros perfiles y fuentes de datos;

• Interacción y presentación que violan la privacidad: Transmitir información privada

a través de un medio público y, en el proceso, divulgarla a un audi- encenodeseado;

• Transiciones del ciclo de vida: Los dispositivos a menudo almacenan cantidades masivas de datos sobre su propia historia a lo largo de todo su ciclo de vida que podrían filtrarse durante los cambios de esferas de control en un ciclo de vida

del dispositivo;

• Ataque de inventario: La recopilación no autorizada de información sobre la existencia y las características de las cosas personales, por ejemplo,los ladrones pueden usar los datos de inventario para verificar la propiedad y encontrar un momento seguro para irrumpir;

• Vinculación: Vincular diferentes sistemas previamente separados de tal manera que la combinación de fuentes de datos revele información (veraz o errónea) que el sujeto no divulgó a las fuentes previamente aisladas y, lo más importante, también lo hizo. no quiero revelar.

Todas estas amenazas comunes a la privacidad se deben a la fuga de datos a nivel de dispositivo; o bien, fuga de datos durante la comunicación; o, más a menudo, fuga de datos por parte de partes centralizadas.

• Falta de valores funcionales

La mayoría de las soluciones FINTRANS existentes carecen de una creación de valor significativa. "Estar conectado" es la propuesta de valor más utilizada. Sin embargo, simplemente habilitar la conectividad no hace que un dispositivo sea inteligente o útil. Una mayor parte del valor que produce FINTRANS proviene de la interacción, la cooperación y, finalmente, la coordinación autónoma de entidades heterogéneas. Algunas buenas analogías son que las células individuales cooperan para construir organismos multicelulares, los insectos construyen sociedades, los humanos construyen ciudades y estados. Al cooperar, todos estos individuos se unen para construir algo que tiene mayor valor que el suyo propio. Desafortunadamente, según [29], el 85% de los dispositivos heredados carecen de capacidad para interactuar o cooperar entre sí debido a problemas de compatibilidad. El intercambio de datos para obtener información empresarial y operativa es casi imposible.

Page 6: DIGILITE - firebasestorage.googleapis.com

• Cadena de bloques

La tecnología Blockchain se introdujo en 2008 y su primera implementación, es decir,. Bit-coin, fue introducido un año más tarde, en 2009, publicado en el periódico Bitcoin: A Peer-to-Peer Electronic Cash System [21] por Satoshi Nakamoto (alias). Esencialmente, blockchain es una base de datos transaccional distribuida que se comparte entre todos los nodos participantes en la red. Esta es la principal innovación técnica de Bitcoin y actúa como un libro mayor público para las transacciones. Cada nodo en el sistema tiene una copia completa del estado actual de la cadena, que contiene cada transacción jamás ejecutada. Cada bloque contiene un hash del bloque anterior, uniendo estos dos. Los bloques vinculados se convierten en una cadena de bloques.

• Ingredientes

Una cadena de bloques se puede percibir como un continuo de cuatro dimensiones que tiene tres capas horizontales que incluyen transacciones y bloques, consenso, interfaz de cómputo y gobernanza, una capa vertical.

Transacción y bloques

Como la capa horizontal más baja, las transacciones firmadas se gossipan entre todos

los nodos y los bloques son generados por nodos completos. Esta es la base de blockchain donde la transferencia de activos digitales (por lo tanto, los valores inherentes) y la seguridad de la cuenta se logran a través de primitivas criptográficas como la firma de curva elíptica, la función hash y el árbol de Merkle. .

Consenso

La capa horizontal intermedia manifiesta la naturaleza peer-to-peer de la cadena de bloques, donde todos los nodos dentro de la red alcanzan un consenso sobre todos los estados internos de la cadena a través de tecnologías como la Prueba de trabajo. (PoW), Prueba de Estaca (PoS) y sus variantes, Tolerancia a fallasbizantinas (BFT) y sus variantes, etc. La capa de consenso es la que más afecta a la escalabilidad. PoW generalmente se considera menos escalable en comparación con PoS. Además, esta capa impacta fuertemente en la seguridad en términos de doble gasto y otros ataques enfocados en mutar los estados blockchain de una manera imprevista.

Interfaz de cómputo

Las dos primeras capas horizontales forman la forma de una cadena de bloques, mientras

que la capa de interfaz de cómputo es fundamental para hacer que una cadena de bloques sea útil, que abarca la extensibilidad y la usabilidad. Por ejemplo, el contrato inteligente ha sido implementado por Ethereum para permitir la programabilidad donde uno podría contar con la "computadora mundial" distribuida para ejecutar los términos de un contrato. Sidechain, junto con la minería fusionada, también se ha desarrollado

Page 7: DIGILITE - firebasestorage.googleapis.com

intensamente para apoyar la programabilidad. Los protocolos de segunda capa como la red Raiden [25], el canal de estado se ha desarrollado para extender la escalabilidad de

una cadena de bloques en esta capa. Además, las herramientas, los SDK, los marcos y las GUI también son extremadamente importantes para la usabilidad. La capa de interfaz de cómputo brinda a los desarrolladores la capacidad de desarrollar

aplicacionesdescentralizadas (DApps),una parte esencial para hacer que la cadena de bloques sea útil y valiosa.

Gobernanza

Al igual que con los organismos, las cadenas de bloques más exitosas serán aquellas que mejor puedan adaptarse a sus entornos. Suponiendo que estos sistemas necesitan evolucionar para sobrevivir, el diseño inicial es importante, pero en una línea de tiempo lo suficientemente larga, los mecanismos para el cambio son los más importantes, lo que se conoce como el gobierno de la capa vertical. Hay dos componentes críticos de la gobernanza:

•Incentivo: Cada grupo en el sistema tiene sus propios incentivos. Esos incentivos

no siempre están 100% alineados con todos los demás grupos del sistema. Los

grupos propondrán cambios a lo largo del tiempo que sean ventajosos para ellos. Los

organismos están sesgados hacia su propia supervivencia. Esto se manifiesta

comúnmente en cambios en la estructura de recompensas, la política monetaria o

los equilibrios de poder.

•Coordinación: Dado que es poco probable que todos los grupos tengan una

alineación de incentivos del 100% en todo momento, la capacidad de cada grupo

para coordinarse en torno a sus incentivos comunes es fundamental para que

puedan afectar el cambio. Si un grupo puede coordinarse mejor que otro, crea

desequilibrios de poder a su favor. En la práctica, un factor decisivo es cuánta

coordinación se puede hacer en la cadena (porejemplo,votar a las reglas del sistema

como Tezos [34], o incluso revertir el libro mayor si a las partes interesadas

mayoritarias no les gusta el cambio) vs. fuera dela cadena (comolas Propuestas de

Mejora de Bitcoin (BIP) [3]).

• Modelos operativos

Las cadenas de bloques se pueden clasificar como sin permiso y con permiso dependiendo de cómo se operen. Por ejemplo, Bitcoin no tiene permiso, lo que significa que cualquiera puede crear una dirección y comenzar a interactuar con la red, que es "generar confianza

a partir de la confianza". En contraste, la blockchain autorizada es un ecosistema cerrado

Page 8: DIGILITE - firebasestorage.googleapis.com

y monitoreado donde el acceso de cada participante se define y diferencia en función del rol, que es "construir confianza a partir de menos confiable".

Hay beneficios e inconvenientes en cada enfoque. En cualquier caso, todas estas consideraciones se reducen a compensaciones fundamentales de diseño entre confianza, escalabilidad, computación y complejidad. Por ejemplo, Bitcoin y Ethereum son cadenas de bloques construidas sobre nodos sin confianza porque la escalabilidad es muy deseada. Por lo tanto, se necesita mucho cálculo (en el caso de PoW)o se necesita un

mechade consensomás sofisticado. En contraste, Fabric [14] es una cadena de bloques autorizada donde todos los nodos se consideran confiables y tienen identidades criptográficas, por ejemplo, emitidas por servicios miembros como public Key Infrastructure (PKI), lo que los hace altamente escalables con bajo cálculo y un mecanismo

de consenso directo.

Tabla 1: FINTRANS se beneficia de las propiedades de Blockchain

Blockchain (propiedad) FinTrans se beneficia de

Descentralización Escalabilidad, Privacidad

Tolerancia a fallos bizantinos Disponibilidad, Seguridad

Transparencia e inmutabilidad Anclaje de la confianza

Programabilidad Extensibilidad

• Beneficios y desafíos de Blockchain y FinTrans

La detección y la percepción, la transformación y la transmisión, y el procesamiento son la esencia de la mayoría de las cosas inteligentes de este planeta. Para fintrans,mientras que

la capa de detección y percepción se distribuye espontáneamente, las dos últimas no lo son por el momento, que es la raíz de la mayoría de los problemas de escalabilidad, privacidad y extensibilidad. Visualizamos la tecnología blockchain, si sirve como la médula espinal y el sistema nervioso de fintrans, como el mejor candidato para abordar los

problemasespecíficos de fintransantes mencionados.

• Beneficios

Al adoptar la tecnología blockchain, fintrans se beneficia inmediatamente de los siguientes

aspectos gracias a las propiedades de blockchain, incluida la descentralización, la tolerancia a fallas bizantinas, la transparencia y la inmutabilidad. La Tabla 1 resume cómo fintrans se beneficia de las propiedades de blockchain.

Descentralización

Page 9: DIGILITE - firebasestorage.googleapis.com

La descentralización libera a los usuarios y dispositivos de un monitoreo centralizado controlado y consistente, abordando así parcialmente la preocupación de privacidad impuesta por las partes centralizadas que monopolizan el mercado y tratan de comprender cada aspecto del usuario / dispositivo para sus propios beneficios, por

ejemplo,lapublicidad. La descentralización, en el contexto de la criptoeconomía, también

indica "elasticidad" que a menudo se define como "el grado en que un sistema es capaz

de adaptarse a los cambios de la carga de trabajo mediante el aprovisionamiento y desaprovisionamiento de recursos de manera autónoma, de modo que en cada momento el disponible los recursos se ajustan lo más posible a la demanda actual". Una cadena de bloques y la criptoeconomía subyacente se pueden diseñar de una manera que sea lo suficientemente elástica y rentable para escenarios y aplicaciones de FinTrans. Por ejemplo, se podrían girar más nodos de blockchain si la red tiene suficientes tareas de computación con suficientes incentivos para realizar.

Tolerancia a fallos bizantinos (BFT)

El objetivo de la tolerancia a fallos bizantinos es defenderse contra fallos en los que los componentes de un sistema fallan de manera arbitraria, es decir,no solo deteniéndose o bloqueándose, sino procesando solicitudes incorrectamente, corrompiendo su estado local y / o produciendo resultados incorrectos o inconsistentes. La falla bizantina modela

entornos del mundo real en los que las computadoras y las redes pueden comportarse de manera inesperada debido a fallas de hardware, congestión y desconexión de la red, así como ataques maliciosos. La propiedad BFT se puede aprovechar para lograr muchas propiedades de seguridad deseadas en el contexto de FinTrans,por ejemplo,eliminar los ataques man-in-the-middle (MITM) ya que no hay un solo hilo de comunicación que pueda ser interceptado y manipulado, hacer Ataques de denegación de servicio (Dos) casi imposibles.

Transparencia e inmutabilidad

Blockchain proporciona garantías criptográficas de que los datos anclados en la cadena

son siempre transparentes e inmutables, lo que puede ser útil en muchos escenarios, por

ejemplo,estadosancla del mundo FinTrans en la cadena de bloques para el propósito. de auditoría, notarización y análisis forense, gestión de identidad, autenticación y autorización.

Programabilidad

Bitcoin vino con una programabilidad básica para permitir que una transacción tenga éxito solo si el pequeño script subyacente se ejecuta con éxito. Ethereum mejora esta característica para lograr el contrato inteligente completo de Turing que está escrito en lenguaje de programación de alto nivel y ejecutado en una pequeña máquina virtual conocida como EVM. Esta programabilidad puede y debe extenderse a los dispositivos

Page 10: DIGILITE - firebasestorage.googleapis.com

FinTrans, algunos de los cuales actualmente solo tienen una lógica simple y codificada que no se puede programar más una vez que se envía.

• Desafíos

Beneficiarse de las propiedades comunes proporcionadas por las cadenas de bloques no significa que todas las cadenas de bloques son adecuadas para el uso de FinTrans. De hecho, no parece que ninguna cadena de bloques pública existente se pueda aplicar a FinTrans, ya que hay bastantes problemas desafiantes.

La garantía de privacidad nativa no es suficiente

Las garantías de privacidad nativas de blockchain solo pueden ayudar a abordar el punto

débil de privacidad en FinTrans en la medida en que retiene los datos en la cadena en lugar de centralizados.

servidores, utilizando seudónimo. Sin embargo, si el seudónimo de un dispositivo alguna vez está vinculado a su identidad, todo lo que alguna vez hizo bajo ese seudónimo ahora estará vinculado a él.

No existe una cadena de bloques silver bullet

Como se mencionó anteriormente, FinTrans es un universo de sistemas y dispositivos heterogéneos con diferentes propósitos y capacidades. Es imposible encontrar una solución blockchain de bala de plata que se adapte a la mayoría de los escenarios. Por ejemplo, una cadena de bloques para coordinar millones de nodos Industriales FinTrans debe centrarse en la alta escalabilidad y el rendimiento de las transacciones, mientras

que una cadena de bloques para coordinar dispositivos inteligentes en el hogar debe centrarse en la privacidad y la extensibilidad. A nivel macro, los dispositivos FinTrans como una especie definitivamente están evolucionando a un ritmo rápido, esdecir. , se integran nuevas tecnologías, se desarrollan nuevos estándares, se fabrican nuevos dispositivos con nuevas capacidades. Encontraste, a nivel micro, la capacidad, el propósito

y el entorno operativo del dispositivo FinTrans individual también siguen cambiando con el tiempo.

Las operaciones de cadena son pesadas

En el mundo FinTrans, muchos dispositivos se consideran nodos débiles porque son:

•Incapaz de realizar minería basadaen PoW debido a las restricciones de potencia y

computación;

Page 11: DIGILITE - firebasestorage.googleapis.com

•No puede almacenar una gran cantidad de datos (porejemplo,nivel de

gigabyte, sin mencionar el nivel de terabyte y el nivel de petabytes) debido a las

limitaciones de potencia y almacenamiento;

• No puede verificar todas las transacciones procesando toda la cadena de bloques;

•No es capaz de conectarse con sus compañeros todo el tiempo,

dependiendo de su tiempo de actividad y calidad de connec- tivity.

Por lo tanto, la mayoría de las cadenas de bloques existentes son demasiado pesadas para FinTrans.

• Trabajo relacionado

FinTransA, que se lanzó recientemente, se basa en una tecnología no convencional conocida como tangle. FinTransA intenta desacoplar el mecanismo de transición de estado con el mecanismo de canonicalización de consenso desechando conceptos como bloques y cadenas. En cambio, los emisores de transacciones también son aprobadores de transacciones y la verificación de transacciones se construye utilizando un gráfico acíclico dirigido (DAG) para que la transacción sea rápida y de costo cero. La eficiencia se obtiene al perder estados definidos a nivel mundial, lo que hace que las características deseadas como la verificación de pago simple (SPV) para clientes ligeros y contratos inteligentes sean bastante desafiantes. FinTrans Chain (ITC) [16], otro proyecto de blockchain de FinTrans con sede en China, hereda la misma estructura de enredo de FinTransA y, por lo tanto, tiene los mismos pros y contras. HDAC [13] es otra cadena de bloques propuesta recientemente para FinTrans en Corea, que en asociación con Hyundai Group, se centrará en campos más específicos en FinTrans, como la autenticación de dispositivos y la transacción de máquina a máquina (M2M).

• digilite: Descripción general del diseño y la arquitectura

• Principio de diseño

digilite tiene como objetivo convertirse en el sistema espinal y nervioso centrado en la

privacidad y escalable para FinTrans. Para lograr esto y abordar los desafíos antes mencionados, nuestro diseño de arquitectura tiene los siguientes principios.

Separación de funciones

Conectar directamente todos los nodos de FinTrans en una sola cadena de bloques es un sueño que no puede hacerse realidad. Además del hecho de que las diferentes aplicaciones fintrans requieren conjuntos de características fundamentalmente diferentes

de una cadena de bloques, alojar cada nodo FinTrans en una cadena de bloques hace que crezca rápidamente en tamaño y computación, y eventualmente se vuelven

Page 12: DIGILITE - firebasestorage.googleapis.com

demasiado pesados para muchos dispositivos FinTrans. En cambio, una separación de tareas asegura que cada cadena de bloques interactúe con un grupo específico de nodos

FinTrans y, al mismo tiempo, interactúe con otras cadenas de bloques cuando sea necesario. Esto es análogo a Internet: los dispositivos heterogéneos primero forman un

grupo intraconectado, intranet. Las intranets más pequeñas pueden formar una intranet más grande, que eventualmente se conecta a la columna vertebral de Internet y se comunica entre sí. La "separación de deberes" generalmente crea un sistema bien equilibrado para maximizar tanto la eficiencia como la privacidad.

La navaja de Occam

Cada cadena de bloques tiene diferentes usos y aplicaciones, y debe diseñarse y optimizarse en diferentes direcciones. Por ejemplo, una cadena de bloques que se dedica a transmitir transacciones entre sus subcadenas no necesita tener un contrato completo de Turing ejecutándose sobre ella; otra cadena de bloques que conecta dispositivos en la misma zona de confianza no debería preocuparse demasiado por la privacidad transaccional.

FinTrans Amigable

Como se mencionó anteriormente, el mundo de FinTrans está lleno de sistemas y nodos heterogéneos, más fuertes o más débiles en términos de sus recursos de computación, almacenamiento y potencia. Desde la ópera-

Las operaciones que pueden hacer los nodos débiles pueden ser fácilmente realizadas por nodos fuertes, las operaciones en la cadena deben diseñarse y optimizarse para nodos débiles, es decir, las operaciones deben ser lo suficientemente livianas como para conservar recursos como la computación, el almacenamiento y energía.

• Arquitectura: Blockchains en Blockchain

digilite es una red de muchas cadenas de bloques que están organizadas jerárquicamente, donde muchas cadenas de bloques pueden ejecutarse simultáneamente entre sí mientras conservan la interoperabilidad. En el mundo digilite, como se muestra en la Figura 1, la cadena de bloques raíz administra muchas cadenas de bloques independientes o subcadenas. Una subcadena se conecta e interactúa con dispositivos FinTrans que comparten algo en común, por ejemplo,tienen un propósito funcional similar, operan en entornos similares o comparten el nivel similar de confianza. Si una subcadena no funciona bien, por ejemplo, ser atacada o experimentar errores de software, la cadena raíz no se ve afectada por completo. Además, las transacciones cruzadas de blockchain se admiten para transferir valor y datos de subcadenas a la cadena raíz o de una subcadena a otra a través de la cadena raíz.

Page 13: DIGILITE - firebasestorage.googleapis.com

Figura 1: digilite: Blockchains en blockchain, una arquitectura rootchain y subchains.

La cadena de bloques raíz es una cadena pública accesible para cualquier persona, que tiene tres objetivos principales:

• Retransmitir valor y datos a través de subcadenas de una manera que preserve la privacidad para permitir la interoperabilidad entre subcadenas;

Tabla 2: Comparación entre rootchain y subcadena

Propiedades Cadena de raíces Subcadena

Público vs Privado Público Público o Privado

Escalable Obligatorio Varía

Robusto Muy necesario Obligatorio

Centrado en la

privacidad

Obligatorio Varía

Extensibilidad No Turing Completo Turing Completo

Finalidad de bloque

instantáneo

Obligatorio Obligatorio

Page 14: DIGILITE - firebasestorage.googleapis.com

• Supervisión de las subcadenas, por ejemplo,penalizar a los operadores vinculados de la subcadena mediante la confiscación de fianzas;

• Liquidación y anclaje de pagos y fideicomiso para subcadenas.

Con estos objetivos definidos, la cadena raíz se centra específicamente en la escalabilidad, la robustez, las funciones que preservan la privacidad y la capacidad de orquestar subcadenas.

Una subcadena, porotro lado, podría ser potencialmente una cadena de bloques privada y se basa en la cadena raíz como relé para interactuar con otras subcadenas. Una subcadena desea flexibilidad y extensibilidad para adaptar los requisitos diversificados de las diferentes aplicaciones fintrans. Es muy probable que una subcadena esté dirigida por operadores cuyo papel depende de que se deposite un enlace suficientemente alto

en la cadena raíz. Opcionalmente, el sistema permite a los operadores nominar a uno o más operadores para que actúen para ello con o sin fianza adicional. El operador actúa como un cliente ligero en la cadena raízyun nodo completo en la subcadena para sellar nuevos bloques.

En general, las propiedades de la cadena raíz y las subcadenas se resumen en la Tabla 2.

• Blockchain raíz

La cadena de bloques raíz utiliza el modelo basado en UXTO como Bitcoin [21] y Monero [20] por las siguientes razones:

El orden de las transacciones se vuelve trivial sin la necesidad de números de nonce o secuencia, lo que impone demandas mínimas a los esquemas de consenso y permite que las transacciones se procesen en paralelo;

Es posible aplicar técnicas existentes que preservan la privacidad, como la firma de anillo y ZK-SNARK para ocultar el remitente, el receptor y la cantidad de la transacción.

La cadena de bloques raíz se compone de bloques vinculados a hash, y un bloque se compone de un encabezado que enlaza hash con el bloque anterior y una lista de transacciones. El

rootchain permite principalmente dos tipos de transacción: (1) las transacciones básicas incluyen- ing P2PKH, P2SH, Multisig y etc., y transacciones avanzadas que permiten

operaciones de blockchain cruzadas como BondedRegistration,Lock, ReLock,Reorg y etc.. Las transacciones val-idated se agregan a un bloque que tiene un tamaño dinámico,

Page 15: DIGILITE - firebasestorage.googleapis.com

limitado por 8MB. Un bloque se produce cada tres segundos por nuestro esquema de consenso como se detalla en la siguiente sección. La cadena raíz está diseñada para no ser

completa de Turing con el soporte de un script basado en pila y un rico conjunto de códigos de operación.

• Subcadenas

digilite viene con un marco para desarrollar y aprovisionar una subcadena personalizada

para aplicaciones FinTrans descentralizadas mediante la encapsulación de primitivas de baja capa como el protocolo de chismes y el mecanismo de consenso. El modelo de permisos, la especificación, los parámetros y los tipos de transacción de la subcadena se pueden personalizar para que se ajusten a su aplicación.

Las subcadenas digilite utilizan un modelo basado en cuentas, que es mejor para el seguimiento de tran- sitions deestado. Hay dos tipos de cuentas, similares con Ethereum, cuentas regulares y contratos. Las transacciones válidas se agregan al bloque, que se produce mediante el mismo esquema de consenso que la cadena raíz para lograr el mismo grado de finalidad para hacer que la comunicación entre cadenas de bloques sea más eficiente. Las subcadenas usan el token de la cadena raíz, digilitetoken,o definen su propio token. El token definido por los desarrolladores en las subcadenas se puede distribuir públicamente mediante ventas de tokens o intercambio en intercambios que

cotizan en bolsa. El contrato inteligente es compatible con subcadenas y se ejecuta sobre la máquina

virtual ligera y eficiente. Actualmente estamos evaluando Web Assembly (WASM) [36], un estándar web emergente para crear aplicaciones web de alto rendimiento. WASM es eficiente y rápido, y se puede hacer determinista y aislado con algunas modificaciones como lo intenta el proyecto EOS [9]. También se están explorando otras opciones. Con el contrato inteligente, los dispositivos FinTrans conectados a la misma subcadena utilizan el estado compartido de dos maneras,

•En primer lugar, los dispositivos pueden interactuar con el entorno físico en

función de los estados de sus subcadenas, por ejemplo,las bombillas se encienden y

apagan por sí mismas en función de un "estado de reloj" en la subcadena;

•Por otro lado, los dispositivos pueden mutar el estado en las subcadenas cuando

cambia el entorno físico, por ejemplo, el termostato actualiza la temperatura a través

de un contrato inteligente basado en los datos de su sensor.

• Comunicación entre cadenas de bloques

Se espera que la comunicación entre cadenas de bloques se utilice con alta frecuencia en aplicaciones FinTrans. Siempre existe la necesidad de un dispositivo FinTrans en una subcadena para coordi- nate con otro dispositivo en un diferentent subchain. Una vez

Page 16: DIGILITE - firebasestorage.googleapis.com

más, limitados by FinTrans dispositivos de baja huella de computación y almacenamiento, estamos motivados para diseñar la comunicación entre cadenas de bloques de una manera rápida y rentable.

Fijación y finalidad del bloque

La vinculación es un mecanismo para escalar la red Bitcoin a través de cadenas laterales, propuesto originalmente en [1]. Se basa en gran medida en la verificación de pago simplificada (SPV) [21], y permite a Bitcoins "moverse" efectivamente de la cadena

de bloques de Bitcoin a la cadena lateral y de regreso. La idea subyacente es simple: los tokens se envían a una dirección especial para ser encerrados en la cadena de bloques de Bitcoin; una vez que se ha confirmado esta transacción de Lock, se envía la transacción de Reorg a la cadena lateral, incluida la transacción de Lock y una prueba de inclusión en forma de sucursal de Merkle. La cadena lateral utiliza SPV para verificar la transacción reorg y, si se valida, crea la misma cantidad de tokens y los envía a una dirección deseada en la cadena lateral. A partir de hoy, la vinculación sirve como una

primitiva para casi todos los protocolos de comunicación entre cadenas de bloques, por ejemplo,Cosmos, Lisk, Rootstock. Dos flujos de vinculación separados se pueden acoplar fácilmente para hacer el llamado Clavijamiento bidireccional (2WP) para hacer tokens

de transferencia de ida y vuelta. La finalidad del bloque es la garantía de que el nuevo bloque generado es definitivo y

no se puede cambiar. La finalidad del bloque afecta sustancialmente la implementación concreta de la vinculación, ya que uno tiene que esperar hasta que se logre la finalización del bloque (al menos con alta flexibilidad) en la cadena de bloques de envío antes de solicitar Reorg. La mayoría de las cadenas de bloques públicas como Bitcoin no tienen una finalidad instantánea. La cadena de bloques receptora solo puede obtener una garantía probabilística, por ejemplo,a medida que más mineros PoW confirman una transacción, es más probable que la transacción haya sido aceptada. La utilización de un consenso final aborda este problema porque la cadena receptora tiene seguridad con una confirmación de bloque en la cadena de bloques de envío. Para las aplicaciones FinTrans, se espera que la

transferencia de valor y datos entre cadenas de bloques sea rápida y rentable, lo que requiere un mecanismo de consenso finalizado tanto en la cadena raíz como en las subcadenas. El consenso digilite logra una finalidad de bloque instantánea, detallada en la siguiente sección.

Protocolo de comunicación entre cadenas de bloques

Revisemos el protocolo a un alto nivel asumiendo que una dirección llamada Charlie en la subcadena 1 desea enviar una transacción a una dirección llamada David en la subcadena 2, y las tres cadenas de bloques usan el mismo tipo de token sin tarifa de transacción para mayor simplicidad. Tenga en cuenta que al aplicar la vinculación ingenuamente, se necesitan cuatro transacciones para

Page 17: DIGILITE - firebasestorage.googleapis.com

realizar una "llamada remota" de la subcadena 1 a la subcadena 2 a través de rootchain, es decir,(1) una transacción de bloqueo en la subcadena 1; (2) una transacción de Reorganización contra rootchain; (3) otra transacción de bloqueo en rootchain; y (4) otra transacción de Reorg contra subcadena • Este proceso indica que David tiene que esperar al menos 4 bloques para aceptar esta "llamada remota", y los datos que lleva esta "llamada remota" deben almacenarse en las tres cadenas de bloques, lo que la hace lenta y costosa. Nuestro objetivo es optimizar este proceso combinando (2) y (3) en una transacción ReLock, lo que no solo acelera todo el proceso, sino que también evita almacenar datos en subcadena 1 y la cadena raíz. Nuestro protocolo se muestra en la Figura 2.

Figura 2: Cross-Blockchain Transactions

digilite cross-blockchain protocol tiene los siguientes pasos.

• Cada subcadena se registra en la cadena raíz mediante el envío de una transacción llamada

BondedRegistration a la cadena raíz, incluido su nombre de cadena, ID de cadena, con- figuración, bloquede génesis y nominación de operadores; Se trata de un proyecto de una sola vez;

• Cuando Charlie desea enviar una transacción a David, inicia una transacción Lock(X, H(D), F/T ) donde X es el amount de akens, H(D) es el hash de los datos D a adjuntar, F / T indica las direcciones de y hacia incluyendo IDs para ambas cadenas;

• Una vez que la transacción Lock se ha incluido en la subcadena 1, Charlie inicia la transacción ReLock(X, H(D ), F/ T , S, P ) a la rootchain by incluyendo X , H( D), F/

Page 18: DIGILITE - firebasestorage.googleapis.com

T , algunas estadísticas actuales de la subcadena 1 denotadas como S, así como la

prueba de inclusión P

que incluye ramas De Merkle de encabezados de bloque recientes y ramas de Merkle que demuestran que se ha incluido la transacción de Lock;

• La cadena raíz valida la transacción ReLock y la acepta incluyéndola en el último bloque, y crea tokens X y los bloquea en una dirección especial;

• Una vez que la transacción ReLock se ha incluido en la cadena raíz,Charlie amplia una transacción Reorg(X , D, F/T , P j) en rootchain's network con X , D , F/T y otra prueba de inclusión P j que prueba la inclusión de la transacción ReLock;

• Los operadores de la subcadena 2 se dan cuenta de la transacción de Reorg, y validan y crean la misma cantidad de tokens en la subcadena 2 y los envían a la dirección David con D asociada.

Compartir el "ancho de banda" de la cadena de bloques raíz

Una posible preocupación con respecto a la comunicación entre cadenas de bloques es que una subcadena maliciosa envía spam a la cadena raíz u otra subcadena al enviar una gran cantidad de transacciones entre cadenas de bloques que agotaron la capacidad de otras cadenas de bloques. Una forma de mitigar es dejar que cada subcadena puje por su cuota y transacciones de "límite de tasa" de una subcadena si su cuota se agota.

Page 19: DIGILITE - firebasestorage.googleapis.com

Figura 3: Modelo de ancho de banda para compartir la

capacidad de la cadena raíz

Se puede definir la cuota en función del espacio de almacenamiento dentro de un bloque. Suponiendo que el tamaño del bloque es de 8 MB como máximo, y 4 MB se reserva para las transacciones normales que ocurren en el

Tabla 3: Técnicas de preservación de la privacidad para blockchains

Técnica Esconder Transmisor Ocultar

receptor

Ocultar

cantidad

Dirección oculta N Y N

Compromisos de Pedersen N N Y

Firmas de anillo Y N N

zk-SNARKs Y N Y

rootchain, y 4MB está reservado para todas las transacciones entre blockchain, que se

divide en, digamos, 4096 pieza de cuota con cada pieza de cuota para ser 1KB. Una subcadena puja por n piezas de cuota (con un determinado límite superior) de acuerdo con el uso previsto mediante la colocación de un depósito proporcional a n. En cada ronda, solo se

Page 20: DIGILITE - firebasestorage.googleapis.com

puede usar hasta nKB dentro de un nuevo bloque para las transacciones de esta subcadena y a cada transacción se le cobra una tarifa de "ancho de banda"del depósito (para recompensar a los mineros que ayudan a hacer cumplir esta regla); las transacciones restantes se ponen en cola y, finalmente, se eliminan cuando se espera el tiempo de espera. La asignación de cuotas podría ser dinámica en el sentido de que obtiene cambios cuando la cadena raíz crece, como se muestra en la Figura 3. Si una subcadena envía

spam a otras, quema su depósito a un ritmo rápido y, finalmente, pierde la cuota. Por otro lado, si una subcadena deposita un gran depósito simplemente para reservar una gran parte del ancho de banda sin usarlo realmente, la cadena raíz tendrá un mecanismo

para reembolsar parte del depósito en función de la relación entre el número promedio de transacciones por bloque y el ancho de banda reservado, lo que ayuda a estabilizar el ancho de

banda reservado cerca del uso real.

• Transacción integrada que preserva la privacidad

La privacidad proporcionada de forma nativa por Bitcoin y Ethereum se limita al seudónimo. Los detalles de la transacción no son confidenciales. El monto de la transacción y los activos que se transfieren, sus metadatos y sus relaciones con otras transacciones, pueden ser aprendidos trivialmente por cualquier persona. De hecho, hay tres aspectos de la privacidad, la privacidad del remitente, la privacidad del receptor y la

privacidad de los detalles de la transacción en este contexto. Se pueden aplicar varios esquemas criptográficos para abordarlos, como se muestra en la Tabla 3.

digilite integra la dirección oculta para la privacidad del receptor, la firma de timbre para la privacidad del remitente y los compromisos de Pedersen para ocultar el monto de la transacción con las siguientes innovaciones y mejoras:

•Un esquema de direcciones ocultas livianas está diseñado para eximir a los

receptores de escanear toda la cadena de bloques para estar al tanto de las

transacciones entrantes;

• La firma del anillo está optimizada para que sea de tamaño compacto con una

configuración de confianza distribuida.

• Ocultar el receptor de transacciones con código de pago retransmitible

Dirección oculta

La técnica de dirección sigilosa se originó en el protocolo Cryptonote [28], que resuelve el problema del receptor utilizando un protocolo de intercambio de claves Diffie-Hellman de "media ronda". Como resumen Bob quiere ocultar el hecho de que recibe tokens de Alice, así es como funciona:

Page 21: DIGILITE - firebasestorage.googleapis.com

• Bob crea dos pares de claves privadas y públicas, denotan como ( a, A) y(b, B), donde

A = a · G y B = b · G, donde G es el punto base en una curva elíptica.

• Bob publica claves públicas (A, B) que se conocen como su dirección sigilosa;

• ·

• Alice calcula y envía tokens a P = H(rA) G + B usando una función hash H, un gran número aleatorio r y la dirección sigilosa de Bob B. Esta transacción se transmite junto con R = r · G;

• ·

• Bob observa todas las transacciones, calcula P j = (H(aR) + b) G (ya que conoce a, b, R y G) con la esperanza deque P j sea igual a P . Si P j = P , Bob podría gastar tokens enviados a P j con clave privada H(aR) + b.

Un inconveniente obvio del sigilo es que el receptor tiene que escanear todas las transacciones (lo que no es ideal en un mundo FinTrans) en la red o confiar en la asistencia

de un nodo completo de confianza (lo que compromete la privacidad hasta cierto punto).

Código de pago

El código de pago ha sido diseñado para abordar el inconveniente anterior de la dirección sigilosa con un cierto sacrificio en la privacidad. La idea es que Alice notifique a Bob de un

código de pago de manera confidencial y Bob solo observa las transacciones contra las direcciones derivadas de ese código. Por lo tanto, esta propuesta tiene dos flujos: la notificación, que es una configuración única entre dos ciertas partes, y el envío, que puede ocurrir varias veces entre estas dos partes.

Suponiendo que Alice tiene un par de claves público-privadas maestras (mpubAlice, mpriAlice)donde mpubAlice = mpriAlice· G y wallet public-private key pair (wpubAlice, wpriAlice) donde wpubAlice = wpriAlice · G; Bob tiene un par maestro de claves público-privadas(mpubBob, mpriBob) donde mpubBob = mpriBob · G, el flujo de notificación de una sola vez funciona de la siguiente manera:

• Bob deriva B0 = b0 · G = (mpriBob + Hash(0, semilla, metadatos)) · G, lo convierte en un sumador de direcciones de notificación (B0), lo publica y escucha en él

• ||

• Alice elige un código de cadena cc al azar; (mpubAlice cc) es el código de pago de Alice;

Page 22: DIGILITE - firebasestorage.googleapis.com

• Alice calcula un secreto compartido S = wpriAlice · B0 y envía el código de pago enmascarado P j = (mpubAlice|| cc) ⊕ HMAC512(xof S) a addr(B0);

• Al recibirlo, Bob aprende wpubAlice, y recupera S = wpubAlice · b0, desenmascara P j

para obtener (mpubAlice|| cc).

Una vez que se realiza el flujo de notificación, Alice y Bob establecenun canalprivado unidireccional para enviar tokens. El primer flujo de envío funciona de la siguiente manera:

• Alice deriva una nueva dirección del código de pago (que ya está compartido con Bob) por A0 = a0 · G = mpubAlice + Hash(0, semilla, metadatos) · G;

• Alice selecciona la siguiente clave pública no utilizada derivada de B0. Tenga en cuenta que B0 es la clave pública no utilizada para la primera ronda.

• Alice calcula el nuevo secreto compartido S0 = a0 · B0, y calcula lo efímero

public key utilizado para enviar la transacción a which es B0j = B0 + SHA256(S0) · G

• Bob podría derivar A0 de forma no interactiva ya que conoce el código de pago de Alice,

y

Sólo escucha en la dirección derived de B0j

= B0 + SHA256(S0) · G y S0 = A0 · b0.

• Al recibirlo, Bob podría usar los tokens con clave privada b0 + SHA256 (S0).

Los siguientes flujos de envío funcionan de manera similar.

Bob no necesita escanear ni depender de un nodo completo para escanear todas las transacciones. La transacción de notificación filtra la intención de Alice quiere enviar algo a Bob, pero el "envío de algo" real está oculto para todos los demás.

Código de pago retransmitible

Para minimizar aún más la fuga de privacidad, diseñamos el código de pago retransmitible sobre la propuesta de código de pago original. Si bien el flujo de envío sigue siendo el mismo, mejoramos el flujo de notificación para hacer posible que Alice comparta en secreto su

código de pago con Charlie sin usar la transacción de notificación, suponiendo que Alice y

Bob tengan un canalprivado unidireccional, y Bob y Charlie tengan otro canal privado

Page 23: DIGILITE - firebasestorage.googleapis.com

unidireccional. Para lograr eso, aprovechamos los contratos hash de bloqueo de tiempo (HTLC), que requieren que el receptor de un pago reconozca haber recibido

el pago antes de una fecha límite mediante la generación de prueba criptográfica de pago o la pérdida de la capacidad de reclamar el pago, devolviéndolo al remitente.

Suponiendo que Charlie tiene un par de claves público-privadas maestras (mpubCharlie, mpriCharlie) donde mpubCharlie = mpriCharlie · G. El flujo de notificaciones mejorado funciona de la siguiente manera.

• Charlie deriva C0 = c0 · G = (mpriCharlie + Hash(0,semilla, metadatos)) · G, lo convierte en un sumador de direcciones de notificación (C0), lo publica. Tenga en cuenta que C0 se publica para que Alice calcule el secreto compartido, pero no para recibir ninguna transacción;

• Alice genera su código de pago (mpubAlice|| cc) de la misma manera;

• || ⊕

• ·

• Alice calcula un secreto compartido S = wpriAlice C0 y envía el código de pago enmascarado P j = (mpubAlice cc) HMAC512 (xof S)con X tokens como incentivo y HTLC(Hash2(cc)) a Bob usando su canal privado unidireccional, donde HTLC, como

parte del script de bloqueo o canje, establece que los tokens se vuelven gastables si

se da la imagen previa de Hash2( v), es decir, Hash(cc);

• Bob, incentivado por los tokens enviados desde Alice, envía tokens P j, Y, Y < X y HTLC(Hash2(v)) a Charlie usando su canal privado unidireccional;

• ·

• Charlie, al recibir la transacción de Bob, calcula S = wpubAlice c0 para desenmascarar

el código de pago de Alice, y gastó la transacción revelando Hash(cc), lo que hace que

la transacción de Alice a Bob sea gastable para recompensar a Bob.

Una vez que se realiza este flujo, Alice y Charlie establecen un canal privado

unidireccional para enviar tokens. Cabe destacar que el enrutamiento de la transacción de Alice podría ser de múltiples saltos.

Nuestros códigos de pago retransmitibles ofrecen una mejor privacidad en términos de ocultar la intención de "enviar algo" en la cadena al aprovechar los canales privados existentes sin agregar ningún cálculo o sobrecarga de almacenamiento a los nodos, que, aunque está diseñado para escenarios FinTrans, es utilizable para la mayoría de las cadenas de bloques como Bitcoin.

Page 24: DIGILITE - firebasestorage.googleapis.com

• Habilitar transacciones confidenciales

• Planteamiento del problema

{ } { }

Una transacción típica en la cadena de bloques de Bitcoin se muestra en la Figura 4. Esencialmente, una transacción blockchain es solo una tupla ({pkin,i}, {pkout,j}, {vi,j}),donde {pkin,i} son direcciones de entrada, pkout,j son direcciones de salida, y vi,j son transacciones cantidades entre direcciones de entrada y salida. Debido a que las transacciones de Bitcoin

se almacenan en texto claro en el libro mayor público, ha planteado muchas

preocupaciones de seguridad y privacidad.

Figura 4: Una transacción en la cadena de bloques de Bitcoin

{ }

El objetivo de las transacciones confidenciales (véase la figura 5) es permitir que sólo los remitentes y receptores de transacciones revelen los valores vi,j y los oculten del resto del mundo. Además, las transacciones confidenciales también permiten a otras entidades de la red verificar la validez de esas transacciones en cuestión sin ver los importes reales. La realización de transacciones confidenciales en blockchain requiere una serie de técnicas criptográficas incorporadas.

Page 25: DIGILITE - firebasestorage.googleapis.com

Figura 5: Una transacción confidencial con verificabilidad pública

• Bloques de construcción

criptográficos Prueba de conocimiento

Una prueba de conocimiento, denotada por (P, V ), es una prueba interactiva entre un verificador P y un verificador V , en la que el verificador quiere demostrar que conoce alguna información. Más específicamente, P tiene (x, w) perteneciente a unarelación R,donde x es el problema y w es la solución (también llamada testigo). V conoce x y acepta sólo si P pudiera convencer a V de que sabe w.

Prueba de conocimiento cero

En un protocolo de prueba de conocimiento cero, el verificador prueba una declaración al verificador sin revelar nada sobre la declaración que no sea que es verdadera, lo que protege al verificador contra el verificador malicioso, que intenta obtener más conocimiento del que se pretende. El protocolo puede ser interactivo o no interactivo. La

diferencia clave con las pruebas no interactivas es que todas las interacciones consisten en un solo mensaje enviado por el verificador al verificador. Utilizamos la notación NIZKPoK(α, β) : a = gα b = gβ para denotar una prueba de conocimiento no interactiva y de conocimiento cero de los valores α y β tal que a = gα y b = gβ. Se supone que todos los valores que no están entre paréntesis son conocidos por el verificador. Cuando utilizamos una prueba de conocimiento cero no interactiva para authen- ticate datos auxiliares, el esquema resultante se conoce como firma de conocimiento [8]. Básicamente, un esquema

de firma de conocimiento significa que uno en posesión de una solución w al problema x ha canteado el mensaje m. Para el NIZKPoKanterior, usamos nota- tion SoK[m](α, β) : a = gα ∧ b = gβ para denotar una firma de conocimiento sobre mensaje m.

Page 26: DIGILITE - firebasestorage.googleapis.com

Firma de anillo

El concepto de firma de anillo fue introducido por primera vez por Rivest etal.[ 27] en 2001 como un tipo especial de firma de grupo. En una firma de anillo, el firmante del mensaje

selecciona un conjunto de miembros del anillo que se incluyen a sí mismos como posibles firmantes del mensaje. El verificador puede estar convencido de que la firma fue generada por uno de los mem- bersdel anillo. Sin embargo, el verificador no puede saber qué miembro generó realmente la firma. A diferencia de una firma de grupo general, un esquema de firma de anillo no implica la designación de un administrador de grupo para administrar el conjunto de miembros del anillo, lo que implica la posibilidad de revelar la identidad del firmante del mensaje real por parte del administrador del grupo. Con el fin de proporcionar anonimato en las transacciones de tokens de contratos inteligentes, se ha empleado un tipo especial de firma de anillo, la llamada firma de anillo vinculable, en la criptomoneda centrada en la privacidad Monero. [20]. La firma de anillo enlazable tiene la propiedad ad- ditional de que cualquier firma generada por el mismo firmante, ya sea firmando el mismo mensaje o mensajes dispares, tiene un identificador (llamado etiqueta) que vincula las firmas. Esta propiedad permite a terceros verificar de manera eficiente que los signos fueron generados por el mismo firmante, sin filtrar la identidad del firmante real. La firma de anillo enlazable utilizada en Monero se denomina

Firma de grupo anónima enlazable de múltiples capas (MLSAG) [22], que es una firma de anillo en un conjunto de vectores clave y tiene una complejidad de comunicación de O(m( n + 1)), donde m es el número de pares de claves públicas/privadas propiedad del firmante y n es el tamaño del anillo.

Acumulador

Los acumuladores unidireccionales, que fueron propuestos por primera vez por Benaloh y de Mare en [2], se definen como funciones hash unidireccionales con la propiedad de ser cuasi-conmutativas. Una función cuasi-conmutativa f : X × Y → X satisface que, para todo x ∈ X y para todo y1, y2 Y , tenemos f (f (x, y1), y 2) = f (f (x, y2), y1). Un acumulador unidirector unidirecía nos permite combinar un conjunto de valores en un resumen seguro y este resumen no depende del orden en el que se encuentran los valores. acumulado . También se puede utilizar para generar un testigo que permita dar fe de que un valor dado es en realidad parte del acumulador.

Esquema de compromiso

Un esquema de compromiso es un protocolo que permite a un usuario comprometerse con un valor de su elección sin revelar ese valor al destinatario del compromiso. En una fase posterior, cuando se le pida al usuario que revele el valor

Page 27: DIGILITE - firebasestorage.googleapis.com

comprometido, el destinatario tendrá los medios para verificar que su valor revelado esté

vinculado incondicionalmente a su compromiso. Un régimen de compromiso debe cumplir dos requisitos. Mientras que el requisito de ocultación impide que el destinatario aprenda el contenido del compromiso, el requisito de licitación evita que el usuario haga trampa al

abrir este compromiso. En el esquema de compromiso de Pedersen [23], los parámetros de dominio son un grupo cíclico G de orden primo q, y generadores (g0, . . . , gm). Por comprometerse con el val-

ues (v1, . . . , vm) ∈ Zm, se elige un número aleatorio r ∈ Zq y se establece el compromiso

C = PedCom(v1, . . . , enm; r) = g0

g i i .

q r Qm v

i= 1

• Nuestras mejoras

En [31], Sun et al.presentaron RingCT 2.0, que empleó una accumulacriptográfica para reducir aún más la complejidad de la comunicación a O(n) a costa de cálculosadicionales. Observamos que aunque RingCT 2.0 redujo significativamente la complejidad de la

comunicación en comparación con MLSAG, la generación de parámetros de dominio del acumulador requiere un proceso único de "configuración confiable" como Zcash. Por lo tanto, uno tiene que confiar en que quien generó los parámetros secretos los destruye cuando están hechos, lo que ha planteado preocupaciones de seguridad y privacidad para el sistema. Para abordar este problema, nuestra solución es emplear un proto-col de computación multipartita segura (SMPC) entre un conjunto de nodos de arranque de la cadena de bloques para generar parámetros de dominio secretos de manera

segura y distribuida. Además, actualmente se están investigando las siguientes direcciones

para mejorar losprotocolos similares a RingCTen términos de comunicación y sobrecarga computacional:

•Un nuevo esquema de firma de anillo enlazable con una complejidad de comunicación

inferior a

O(n)

• Un nuevo enfoque para agregar múltiples firmas de anillo enlazables

• Un protocolo sigma para la configuración sin confianza de parámetros de dominio secreto

Page 28: DIGILITE - firebasestorage.googleapis.com

Nuestro objetivo es proponer una novedosa solución de transacción confidencial que sea capaz de lograr una buena compensación entre la comunicación y el costo de computación.

• Pruebe el rango de monto de la transacción con Bulletproofs

Como reemplazo directo de los compromisos de Pedersen, bulletproofs [5], se ha propuesto recientemente un nuevo protocolo no interactivo a prueba de conocimiento cero con pruebas muy cortas y sin una configuración confiable, que reduce el tamaño de una prueba de rango de lineal a sublineal y reduce aún más la transacción. tamaño sin gastos generales de cálculo adicionales. Dado que los bulletproofs se ajustan bien al

principio de diseño de digilite, vamos a integrar bulletproofs en digilite.

• Consenso rápido con finalidad instantánea

• Fondo

• Prueba de trabajo

La Prueba de Trabajo (PoW) es la columna vertebral para alcanzar el consenso global de

la mayoría de las cadenas de bloques, incluidas Bitcoin y Ethereum. PoW hace que sea computacionalmente difícil construir un bloque válido y adjuntarlo a una cadena de bloques. Cuanto más larga sea la cadena de bloques, más difícil será revertir cualquier transacción registrada previamente por la cadena de bloques. Para ma- nipular la cadena de bloques, un atacante necesita poseer el 51 por ciento de toda la potencia de cálculo de una red de cadena de bloques basada en PoW.

Aunque PoW proporciona una solución elegante para el consenso global de grandes

cadenas de bloques des-homenaje, tiene varios inconvenientes inherentes. El costo total

de cálculo para mantener el consenso global es el mismo costo del ataque del 51 por ciento. Esto significa que incluso si la mayoría de los participantes de la cadena de bloques son honestos, todavía tienen que usar mucha electricidad para mantener la cadena de bloques, que no es adecuada para el entorno de las redes FinTrans que generalmente favorecer la eficiencia energética. Además, a nivel de dispositivos individuales, la computación PoW generalmente cuesta muchos ciclos de CPU y uso de memoria, lo que

plantea requisitos difíciles para la fabricación de hardware y los costos de los dispositivos FinTrans integrados. Por último, pero no el arrendamiento, PoW no proporciona

finalidad instantánea, que es una propiedad crítica requerida para construir una comunicación eficiente entre cadenas.

• Prueba de participación

Page 29: DIGILITE - firebasestorage.googleapis.com

Proof of Stake(PoS)se propuso como una alternativa eficiente a PoW para que las cadenas de bloques alcancen el consenso, lo que tiene como objetivo evitar los problemas de PoW mencionados anteriormente. La idea básica de PoS es que un conjunto de nodos elegidos al azar vota en el siguiente bloque, y sus votos se ponderan en función del tamaño de sus depósitos (es decir, la participación). Si ciertos nodos se comportan mal, pueden perder sus depósitos. De esta manera, sin PoWcomputacionalmente intensivo, la cadena de bloques puede funcionar de manera mucho más eficiente y puede lograr una estabilidad económica: cuanto más participación tenga un participante, más incentivos tiene el nodo para mantener el consenso global y menos probable es que el nodo se comporte mal. Hay un par de diseños e implementaciones públicas de PoS, como

Tendermint [32] que ha sido adoptado por muchas aplicaciones [33].

• Prueba de participación delegada(DPoS)

La Prueba de Participación Delegada(DPoS) mejora la idea de PoS de la manera en que DPoS permite a los participantes elegir algunos delegados para representar sus porciones de participaciones en la red. Por ejemplo, Alice puede enviar un mensaje a la red para otorgarle a Bob la capacidad de representar su estaca y votar en su nombre. DPoS ofrece varios beneficios para nuestras aplicaciones FinTrans:

• Los jugadores pequeños pueden agrupar sus apuestas para tener una mayor

oportunidad juntos de participaren la propuesta y votación en bloque, y

compartir las recompensas después.

• Los nodos con recursoslimitados pueden elegir a sus delegados, por lo que no

todos los nodos necesitan permanecer en línea para contribuir al consenso.

•Los delegados pueden ser los nodos con fuertes condiciones de suministro de

energía y red, y también se pueden elegir de forma dinámica y aleatoria, por lo que

tendremos una mayor disponibilidad general para que la red alcance el consenso.

Las criptomonedas típicas que usan DPoS incluyen EOS [9] y Lisk [18].

• Práctica tolerancia a fallos bizantinos

Practical Byzantine Fault Tolerance (PBFT) fue propuesto por Castro y Liskov [7] en 1999 como un algoritmo eficiente y resistente a los ataques para llegar a acuerdos en una

red asíncrona distribuida. Planeamos usar PBFT para el algoritmo de votación subyacente

de nuestro mecanismo de consenso DPoS, porque es un mecanismo conciso y bien estudiado.

Page 30: DIGILITE - firebasestorage.googleapis.com

algoritmo que proporciona una finalidad rápida que es de vital importancia para construir una cadena de bloques eficiente y vendible. Como se demostró en el documento original de Castro y Liskov, PBFT ofrece disponibilidad y seguridad si como máximo un tercio

de los nodos de la red son defectuosos o maliciosos, y el costo de red de PBFT es muy mínimo, es decir, alrededor del 3 por ciento en comparación con sistema de red no replicado.

Las criptomonedas típicas basadas en PBFT incluyen Stellar [30] y Zilliaq [38].

• Prueba de participación delegada aleatoria (Roll-DPOS)

Para tener un mecanismo de consenso rápido y eficiente con finalidad de bloque instantánea en el contexto de FinTrans, combinamos los conceptos de DPoS, PBFT y Funciones Aleatorias Verificables (VRFs). VRF fue introducido por primera vez por Micali et al. en [19] y es una familia de funciones que pueden producir pruebas públicamente verificables de la exactitud de sus salidas aleatorias. A un alto nivel, nuestra propuesta Roll-DPOS tiene cuatro fases para elegir candidatos, formar comité, proponer bloquear y finalizar bloque.

Figura 6: Prueba de participación delegada aleatoria (Roll-DPOS)

Page 31: DIGILITE - firebasestorage.googleapis.com

• Elegir candidatos

Todas las notas de la red digilite podrían participar en esta fase en términos de votación para los candidatos del comité. Para alentar a los nodos a votar, el sistema se asegura de que el

los delegados comparten recompensas falsificadas con sus votantes. Los candidatos forman un conjunto de al menos 97 delegados; este número aumentará en el futuro para evitar aún más la centralización del poder minero. Una vez que se seleccionan los candidatos, se fijarán en una época, que es consistente en 47 iteraciones.

• Formulario Comité

En cada iteración, se selecciona un comité aleatorio de tamaño 11 del grupo de candidatos utilizando VRF para crear bloques en las siguientes 11 rondas. La idea es utilizar el hash del bloque en la última iteración y la clave privada del nodo como entradas al VRF para producir una salida booleana que indique si uno es seleccionado como miembro del comité, una prioridad que indique el orden de uno para proponer el bloque y una prueba. indicando la calificación de uno para proponer el bloque en una determinada ronda. El uso de VRF es importante, ya que proporciona una forma no

interactiva de ordenar a todos los delegados para proponer bloques de una manera justa y

de seguridad. Con este fin, utilizamos el VRF eficiente como se utiliza en Algorand [12].

• Proponer bloque

En cada ronda (que es aproximadamente cada 3 segundos), cada nodo del comité propone un nuevo bloque y lo transmite a la red, junto con la prioridad y la prueba. Solo el bloque propuesto por un nodo de comité con mayor prioridad y que no ha sido propuesto en la misma iteración es considerado por otros nodos, lo que se denomina bloque candidato.

• Finalizar bloque

En la misma ronda, todos los demás nodos usan PBFT para votar a favor / en contra del bloque de candidatos. Si más de 2/3 nodos del comité acuerdan la validez del bloque candidato, se finaliza y se agrega a la cadena de bloques por todos en la red. Después de eso, el bloque de propuesta y el bloque de finalización se ejecutan en la siguiente ronda; si la iteración actual termina, se formará otro comité aleatorio antes de que se ejecuten el bloque de propuesta y el bloque de finalización.

• Creación de puntos de control periódicos para clientes ligeros

Page 32: DIGILITE - firebasestorage.googleapis.com

En las redes FinTrans, esperamos que muchos dispositivos sean clientes ligeros, que son los participantes de blockchain que no registran el historial completo de transacciones localmente. Teniendo en cuenta la sobrecarga de almacenamiento de la cadena de bloques completa, por ejemplo, más de 100 GB para Bitcoin [4], muchos dispositivos

FinTrans de bajo costo pueden no tener la capacidad de descargar la cadena de bloques completa. Sin embargo, estos clientes ligeros todavía tienen la capacidad de verificar rápidamente la corrección de la cadena de bloques e interactuar con ella: el diseño está

incluido en el documento técnico original de Bitcoin de Satoshi [21]. Sin embargo, el uso de PoS en lugar de PoW tiene una desventaja para los clientes ligeros.

Al verificar la corrección de las cadenas de bloques basadas en PoS, los clientes deben

descargar una lista de claves públicas y firmas para los proponentes de bloques y los votantes, y los conjuntos de proponentes de bloques y votantes pueden cambiar para cada bloque. Por lo tanto, cuando los clientes ligeros vuelven a estar en línea después de permanecer fuera de línea por un tiempo, los clientes pueden necesitar descargar una gran cantidad de claves públicas y firmas, y luego verificarlas todas. Para mitigar este

problema de rendimiento, Vitalik, el inventor de Ethereum, ha propuesto crear puntos de control periódicos en la cadena de bloques, llamados epochs [6], por ejemplo, cada 50 bloques. Cada punto de control se puede verificar en función del punto de control anterior, de modo que los clientes ligeros puedan ponerse al día con toda la cadena de bloques mucho más rápido.

• Token en digilite Network

El token criptográficamente digital nativo de la red digilite (digilitecoin)es un componente importante del ecosistema en la red digilite, y está diseñado para ser utilizado únicamente en la red. Antes del lanzamiento de digilite mainnet, el token existirá como un token compatible con BEP20 en la cadena de bloques binance, que se migrará a un token en la red principal digilite cuando se inicia la misma.

digilitecoin se requiere como "combustible" criptográfico virtual para usar ciertas funciones diseñadas en la red digilite (como ejecutar transacciones y ejecutar las aplicaciones distribuidas en la red digilite), proporcionando los incentivos económicos que se consumirá para alentar a los participantes a contribuir y mantener el ecosistema en la Red digilite. Se requieren recursos computacionales para ejecutar diversas aplicaciones y ejecutar transacciones en la red digilite, así como para la validación y verificación de bloques / información adicionales en la cadena de bloques, por lo que los proveedores de estos servicios / recursos requieren incentivos económicos para la provisión de estos recursos (es decir, "minería" en la red digilite) para mantener

la integridad de la red, y digilitecoin se utilizará como unidad. de intercambio para cuantificar y pagar los costos de los recursos computacionales consumidos. digilitecoin será explotable durante 50 años, con recompensas de la minería que se reducen con el tiempo basadas en un modelo de reducción de gradiente lineal.

Page 33: DIGILITE - firebasestorage.googleapis.com

digilitecoin es una parte integral e indispensable de la red digilite, porque en

ausencia de digilitecoin,no habría una unidad común de intercambio para pagarestos costos, lo que hace que el ecosistema en la red digilite sea insostenible.

digilitecoin es un token de utilidad funcional no reembolsable que se utilizará como unidad de intercambio entre los participantes en la red digilite. El objetivo de introducir digilitecoin es proporcionar un modo conveniente y seguro de pago y liquidación entre los participantes que interactúan dentro del ecosistema en la red digilite. digilitecoin no representa de ninguna manera ninguna participación, participación,derecho, título o interés en digilite Foundation Ltd. (la Fundación), sus afiliados o cualquier otra compañía, empresa o empresa, ni digilitecoin dará derecho a los titulares de tokens a ninguna promesa de tarifas, ingresos, ganancias o rendimientos de inversión, y no pretenden constituir valores en Singapur o en cualquier jurisdicción relevante. digilitecoin solo se puede utilizar en la Red digilite, y la propiedad de digilitecoin no conlleva ningún derecho, expreso o implícito, que no sea el derecho a usar digilitecoin como un medio para permitir el uso y la interacción. con la red digilite.

En particular, digilitecoin:

• no es reembolsable y no se puede cambiar por efectivo (o su valor equivalente en cualquier otra moneda virtual) o cualquier obligación de pago por parte de la Fundación o cualquier afiliado;

• no representa ni confiere al titular del token ningún derecho de ninguna forma con respecto a la Fundación (o cualquiera de sus afiliados) o sus ingresos o activos, incluido, entre otros, cualquier derecho a recibir ingresos futuros, acciones, derechos

de propiedad o participación, acciones o acciones. seguridad, cualquier voto, distribución, reembolso, liquidación,propiedad (incluidas todas las formas de propiedad intelectual), u otros derechos financieros o legales o derechos equivalentes, o derechos de propiedad intelectual o cualquier otra forma de participación en o en relación con la Red digilite, la Fundación, el Distribuidor y/o sus proveedores de servicios;

• no pretende ser una representación de dinero (incluido el dinero electrónico), garantías, productos básicos, bonos, instrumentos de deuda o cualquier otro tipo de instrumento financiero o inversión;

• no es un préstamo a la Fundación o a cualquiera de sus afiliados, no tiene la intención de representar una deuda adeudada por la Fundación o cualquiera de sus afiliados, y no hay expectativa de ganancia; y

• no proporciona al titular del token ninguna propiedad u otro interés en la Fundación o cualquiera de sus afiliados.

• Ecosistemas impulsados por digilite

Page 34: DIGILITE - firebasestorage.googleapis.com

La cadena de bloques digilite admite una variedad de ecosistemas FinTrans, economías compartidas, hogares inteligentes, vehículos autónomos y cadena de suministro, etc. Diferentes tipos de desarrolladores aprovechan digilite de diferentes maneras. Los desarrolladores respaldados por digilite incluyen fabricantes de hardware FinTrans, desarrolladores de sistemas de control de dispositivos FinTrans, desveladores de aplicaciones para el hogar inteligente, fabricantes de dispositivos de economías compartidas, suministro integrador de datos de cadena, datos

vendedores de crowdsourcing, desarrolladores de coches autónomos, etc. Esta sección describe algunos ecosistemas alimentados por digilite.

• Economías compartidas

En los últimos años, muchas empresas se han centrado en economías compartidas, desde viajes compartidos como Uber / Lyft / Didi, casas compartidas como Airbnb, bicicletas compartidas como Mobike/ ofo,hasta compartir a nivel deartículos pequeños como banco de baterías, paraguas, etc. Todos ellos proporcionan a las personas una vida mejor, aunque algunos de ellos están sufriendo por sus modelos de negocio. Es un tema diferente discutir sus modelos de negocio; aquí nos centramos principalmente en su

arquitectura tecnológica. Entre todas las economías compartidas, el viaje compartido es el que no puede evitar la operación humana, es decir, los conductores. No es una economía impulsada por FinTrans. Sin embargo, en el futuro, cuando la tecnología de automóviles autónomos se vuelva madura y popular, el viaje compartido será impulsado por FinTrans.

Todas las economías compartidas impulsadas por FinTrans comparten algunas similitudes: todas requieren un candado que se puede abrir mediante un depósito y una tarifa de alquiler. Es muy posible y también eficiente alimentar todo el proceso de intercambio

y devolución utilizando un dispositivo FinTrans. En el mundo centralizado, las economías son impulsadas por una nube centralizada. Hay varios inconvenientes:

• Un depósito grande es mantenido por una compañía que puede no ser confiable. Recientemente, ha habido muchos casos en los que la compañía que administra un servicio de bicicletas compartidas en China no puede devolver los depósitos a sus usuarios;

• Las economías compartidas no están completamente impulsadas por la comunidad. Muchas cosas compartidas son propiedad de una empresa. Esto ha causado un desperdicio de recursos de la sociedad. Tomemos como ejemplo las bicicletas compartidas. Cuando las compañías de bicicletas compartidas están fuera del negocio, las bicicletas se desechan.

• Debido a la naturaleza centralizada, los datos del usuario serán almacenados y controlados por una empresa. Existe el riesgo de que la nube o el cliente puedan ser pirateados para obtener datos de usuario.

Page 35: DIGILITE - firebasestorage.googleapis.com

digilite, como infraestructura, podría utilizarse para impulsar estas aplicaciones

sin los problemas anteriores y hacer que las economías compartidas sean descentralizadas y más eficientes. Concretamente, una economía compartida impulsada por digilite proporciona los siguientes beneficios:

• El depósito se liquida completamente mediante un contrato inteligente. Sin que nadie retena el dinero, la devolución del depósito siempre está garantizada. Los usuarios no tienen que confiar en la empresa para utilizar el servicio.

• Cada cosa compartida realiza su valor y misión de una manera autónoma. En el

ecosistema, no importa quién sea el dueño de las cosas compartidas en él. Todos pueden poseer y contribuir al ecosistema. La economía puede ser dirigida por la comunidad. Como resultado, las empresas pueden desempeñar un papel en el mantenimiento del bloqueo de FinTrans y administrar la comunidad. Es un modelo de negocio mucho más ligero que las empresas pueden expandir rápidamente y servir a más personas.

• Una vez más, los usuarios no tienen que confiar en la empresa para mantener sus datos. Sus datos se mantienen en la cadena con protección de la privacidad.

• Hogar inteligente

En el mercado de hogares inteligentes existente, muchos fabricantes de dispositivos FinTrans todavía están utilizando tecnologías obsoletas para desarrollar sus productos. Necesitan una gran cantidad de trabajo de desarrollo en su nube. El costo de desarrollo y mantenimiento es alto, y el rendimiento es bajo debido al viaje de ida y vuelta requerido a la nube. La implementación de sus productos en digilite blockchain reducirá en gran medida los costos operativos en ingeniería y computación en la nube, y al mismo tiempo, aumentará en gran medida el rendimiento de sus dispositivos. En un ejemplo simple de bombilla inteligente, con tecnología en la nube, se necesitan dos viajes desde la instrucción del usuario hasta el cambio del estado de una bombilla. Los fabricantes no son expertos en la nube, por lo que a menudo su servicio no es óptimo. El viaje de ida y vuelta puede tomar de uno a tres segundos. Esto les obliga a utilizar el servicio en la nube de

las grandes empresas de TI. Hay dos desventajas de usar estos servicios en la nube:

• Los fabricantes no pueden controlar completamente la disponibilidad de los servicios en la nube.

• Necesitan pagar continuamente por el servicio en la nube a pesar de su cargo único por vender sus dispositivos FinTrans.

• Existen riesgos de que su nube, lado del cliente o intranet sean pirateados, lo

que provoca el robo de los datos de los usuarios o problemas de seguridad en el hogar.

Page 36: DIGILITE - firebasestorage.googleapis.com

Por el contrario, digilite blockchain administra los dispositivos localmente e interactúa con la cadena pública en Internet cuando es necesario. La cadena pública es mantenida por la comunidad. No hay costo de mantenimiento para los fabricantes de FinTrans. digilite blockchain tiene protección de privacidad que puede evitar la fuga de datos o

el control que se piratea, incluso si la intranet no es segura.

Figura 8: digilite-Powered Smart Home

Además de permitir a los fabricantes de FinTrans implementar sus dispositivos FinTrans en la cadena de bloques digilite, digilite se asociará con los fabricantes de chips FinTrans para desarrollar chips habilitados para la cadena de bloques digilite para

acelerar los ciclos de diseño y fabricación de dispositivos FinTrans. FinTrans

los fabricantes simplemente integrarán el chip para que sus dispositivos soporten para la cadena de bloques digilite.

• Gestión de identidades

Page 37: DIGILITE - firebasestorage.googleapis.com

El creciente mundo de FinTrans ha impactado la forma en que la gestión de identidades y accesos (IAM) debe funcionar. En términos de la identidad de las cosas, IAM debe ser capaz de administrar de usuario a dispositivo, de dispositivo a dispositivo y/o de dispositivo a servicio/sistema. Una forma sencilla para la gestión de identidades es considerar digilite blockchain como un sistema PKI descentralizado (gracias a su inmutabilidad) donde a cada entidad se le emite una identidad criptográfica en forma

de certificado TLS y el privado correspondiente. Este certificado, que tiende a ser de corta duración, está firmado por el certificado incorporado y de larga duración del dispositivo y publicado en digilite blockchain (ya sea rootchain o subchain). Los pares y otras entidades pueden acceder y confiar en el certificado de corta duración anclado en la

cadena de bloques, y las cosas pueden autenticarse cuando se ponen en línea, asegurando una comunicación segura entre otros dispositivos, servicios y usuarios, y demostrar su integridad.

Además, los certificados integrados y de larga duración para dispositivos podrían organizarse en jerarquía, como la PKI convencional, donde los dispositivos principales podrían firmar el certificado de hijos. Con la jerarquía, la revocación y rotación de certificados se hace posible. Por ejemplo, si un dispositivo se ve comprometido, su dispositivo principal o incluso si el dispositivo abuelo podría firmar un comando de revocación

y enviarlo a la cadena de bloques donde este último invalida el certificado del dispositivo.

• Trabajo de investigación futuro

Algunas direcciones de investigación en curso y futuras para mejorar digilite son las siguientes.

Computación que preserva la privacidad

Hay varias áreas en esta dirección que estamos explorando activamente:

•Cómo retener estados confidenciales en la cadena de bloques que pueden ser

utilizados para la comunicación por un determinado grupo de nodos;

• Contrato inteligente que preserva la privacidad donde el contrato inteligente

se puede evaluar cuando su lógica de negocio está protegida por cifrado.

Mientras que el cifrado totalmente homofóbico

[26] y los esquemas de ofuscación indistinguibles [11] son el santo grial en teoría, las propuestas prácticas como Hawk [17] son prometedoras para el futuro cercano;

•Reducir aún más la huella de cálculo y almacenamiento de las técnicas de

preservación de la privacidad que digilite está utilizando actualmente;

Page 38: DIGILITE - firebasestorage.googleapis.com

•La versión cuántica segura de las técnicas de preservación de la privacidad digilite

está utilizando actualmente, como la firma de anillo segura cuántica.

Estados poda y transferencia

Estamos evaluando diferentes formas de podar de forma segura los estados almacenados en las subcadenas para reducir la huella de almacenamiento, ya que muchos dispositivos

FinTrans tienen un almacenamiento limitado. Compres- sion de bloques y transacciones es definitivamente una fruta de bajo costo. Además, la transferencia de estados de subcadena a cadena raíz (ya que esta última es más fuerte en términos de almacenamiento) de una manera eficiente y que preserva la privacidad también es un tema interesante para investigar.

Gobernanza y auto-enmienda

Si bien las cadenas de bloques digilite ofrecen incentivos para mantener el consenso en sus libros de contabilidad, por ahora no tiene un mecanismo encadena que modifiquesin problemas las reglas que rigen su protocolo y recompensan el desarrollo del protocolo. Planeamos realizar investigaciones sobre la gobernanza y la autoenmendación para abordar esto.

Blockchains estructuradas en árbol

El digilite actual es una cadena de bloques de dos capas y, naturalmente, debe extenderse a un árbol de cadenas de bloques aprovechando técnicas como Plasma y Cosmos. El plan es evaluar estas propuestas y mejorar el diseño actual de digilite para eventualmente soportar estructuras jerárquicas más complejas.

• Conclusión

En este documento técnico, presentamos digilite, una cadena de bloques escalable, privada y extensible dedicada a Internet de las cosas, con su arquitectura y tecnologías centrales que incluyen 1. blockchains en blockchain para maximizar la escalabilidad y la privacidad, 2. verdadera privacidad en blockchain basada en código de pago retransmitible, firma de anillo de tamaño constante sin configuración confiable y primera implementación de pruebas de balas, 3. consenso rápido con finalidad constante basada en VRF y PoS para un alto rendimiento y una finalidad instantánea, y 4. arquitecturas de sistema flexibles y ligeras basadas en

digilite.

• Agradecimientos

Page 39: DIGILITE - firebasestorage.googleapis.com

Nos gustaría expresar nuestra gratitud a nuestros mentores y asesores y a las muchas personas en las comunidades de FinTrans,criptografía y criptomonedas por sus primeras sugerencias constructivas y de retroalimentación.

Referencias

• Adam Back et al. "Habilitación de innovaciones de blockchain con cadenas laterales vinculadas". En: URL: http://www. opensciencereview. com/papers/123/enablingblockchain- innovations-with-pegged-sidechains (2014).

• Josh Benaloh y Michael de Mare. "Acumuladores unidirecales: una alternativa descentralizada a las firmas digitales". En: Advances in Cryptology — EURO- CRYPT '93: Workshop on the Theory and Application of Cryptographic Tech- niques Lofthus,Norway, May 23–27, 1993 Proceedings. Ed. por Tor Helleseth. Berlín, Heidelberg: Springer Berlin Heidelberg, 1994, pp. 274–285. isbn: 978-3- 540-48285-7. doi: 10.1007/3-540-48285-7_24. url: https://doi.org/10. 1007/3-540-48285-7_24.

• Propuestas de mejora de Bitcoin. https://github.com/bitcoin/bips.

• Tamaño de blockchain. https://blockchain.info/charts/blocks-size.

• Benedikt Bunz et al. Bulletproofs: Eficiente Range Proofs for Confidential Trans- actions. Archivo de criptología ePrint, Informe 2017/1066. https://eprint.iacr. org/2017/1066. Año 2017.

• Vitalik Buterin. Clientes ligeros y Prode Stake. https://blog.ethereum.org/2015/01/10/light-clients-proof-stake/.

• Miguel Castro, Barbara Liskov, et al. "Práctica tolerancia a fallos bizantinos". En:

OSDI. Vol. 99. 1999, págs. 173–186.

• Melissa Chase y Anna Lysyanskaya. "Sobre las firmas del conocimiento". En: Ad- vances in Cryptology - CRYPTO 2006: 26th Annual International Cryptology Conference, Santa Barbara, California, USA, August 20-24, 2006. Actuaciones. Ed. por Cynthia Dwork. Berlín, Heidelberg: Springer Berlin Heidelberg, 2006, pp. 78–96. isbn: 978-3-540-37433-6. doi: 10.1007/11818175_5. url: https: doi.org/10.1007/11818175_5.

• EOS. https://eos.io/.

• AB Ericsson. "Ericsson mobility report: On the pulse of the Networked Society". En: Ericsson, Suecia, Tech. Rep. EAB-14 61078 (2015).

• Sanjam Garg et al. "Candidato a indistinguibilidad ofuscación y cifrado funcional para todos los circuitos". En: SIAM Journal on Computing 45.3 (2016), pp. 882-929.

Page 40: DIGILITE - firebasestorage.googleapis.com

• Yossi Gilad et al. "Algorand: Escalando acuerdos bizantinos para cryptocurren- cies". En: Proceedings of the 26th Symposium on Operating Systems Principles. ACM. 2017, págs. 51–68.

• HDAC Blockchain para FinTrans. https://hdac.io/.

• TejidoHyperledger. https://www.ibm.com/blockchain/hyperledger.html.

• Internet de las cosas(FinTrans)Mercado por solución de software (análisis de transmisión en tiempo real, solución de seguridad, administración de datos, monitoreo remoto y administración de ancho de banda de trabajo en red), servicio, plataforma, área de aplicación y región

- Global Forecast a 2022. https://ww HYPERLINK "http://www.jasper.com/sites/default/files/"w HYPERLINK "http://www.jasper.com/sites/default/files/". HYPERLINK "http://www.jasper.com/sites/default/files/"jasp HYPERLINK "http://www.jasper.com/sites/default/files/"e HYPERLINK "http://www.jasper.com/sites/default/files/"r HYPERLINK "http://www.jasper.com/sites/default/files/". HYPERLINK "http://www.jasper.com/sites/default/files/"co HYPERLINK "http://www.jasper.com/sites/default/files/"m HYPERLINK "http://www.jasper.com/sites/default/files/"/ HYPERLINK "http://www.jasper.com/sites/default/files/"site HYPERLINK "http://www.jasper.com/sites/default/files/"s HYPERLINK "http://www.jasper.com/sites/default/files/" / HYPERLINK "http://www.jasper.com/sites/default/files/"defaul HYPERLINK "http://www.jasper.com/sites/default/files/"t HYPERLINK "http://www.jasper.com/sites/default/files/"/ HYPERLINK "http://www.jasper.com/sites/default/files/"archivo HYPERLINK "http://www.jasper.com/sites/default/files/"s HYPERLINK "http://www.jasper.com/sites/default/files/"/ cisco-jasper-hidden-costs-of-delivering-iFinTrans-services-en_2.pdf. Año 2016.

• ITC Blockchain para FinTrans. https://FinTranschain.io/.

• Ahmed Kosba et al. "Hawk: The blockchain model of cryptography and privacy- preserving smart contracts". En: Security and Privacy (SP), 2016 IEEE Sym- posium on. IEEE. 2016, págs. 839–858.

• Lisk. https://lisk.io/.

• Silvio Micali, Michael Rabin y Salil Vadhan. "Funciones aleatorias verificables". En: Foundations of Computer Science, 1999. 40th Annual Symposium on. IEEE. 1999, págs. 120–130.

• Monero – Moneda Digital Privada. https://getmonero.org/.

• Satoshi Nakamoto. Bitcoin: Un sistemade efectivo electrónico peer-to-peer. Año 2008.

Page 41: DIGILITE - firebasestorage.googleapis.com

• Shen Noether y Adam Mackenzie. "Ring Confidential Transactions". En: Ledger Vol. 1 (2016), pp. 1–18. doi: https://doi.org/10.5195/ledger. 34.2016.

• Torben Pryds Pedersen. "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing". En: Advances in Cryptology — CRYPTO '91: Pro- ceedings. Ed. por Joan Feigenbaum. Berlín, Heidelberg: Springer Berlin Heidel- berg, 1992, pp. 129–140. isbn: 978-3-540-46766-3. doi: 10.1007/3-540-46766- 1_9. url: https://doi.org/10.1007/3-540-46766-1_9.

• Serguei Popov. "La maraña". En: FinTransa (2016).

• RedRaiden. https://raiden.network/.

• Ronald L Rivest, Len Adleman y Michael L Dertouzos. "Sobre bancos de datos y homomorfismos de privacidad". En: Fundamentos de la computación segura 4.11 (1978), pp. 169–180.

• Ronald Rivest, Adi Shamir y Yael Tauman. "Cómo filtrar un secreto". En:

Avances en Criptología—ASIACRYPT 2001 (2001), pp. 552–565.

• Nicolás van Saberhagen. Cryptonote v 2. 0. Año 2013.

• Samsung. Samsung ARTIK y estrategias exitosas para el despliegue de FinTrans industrial. Samsung, 2016.

• Estelar. https://www.stellar.org/.

• Shi-Feng Sun et al. "RingCT 2.0: A Compact Accumulator-Based (Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero". En: Com- puter

Security – ESORICS 2017: 22nd European Symposium on Research in Computer Security, Oslo, Noruega, 11-15 de septiembre de 2017, Proceedings, Part

II. Ed. por Simon N. Foley, Dieter Gollmanny Einar Snekkenes. Cham: Springer International Publishing, 2017, pp. 456–474. isbn: 978-3-319-66399- 9. doi: 10.1007/978-3-319-66399-9_25. url: https://doi.org/10.1007/ 978-3-319-66399-9_25.

• Tendermint. https://tendermint.com/.

• EcosistemaTendermint. https://tendermint.readthedocs.io/en/master/ ecosistema.html.

• Tezos: Una nueva mancomunidad digital. https://www.tezos.com/.

• Los costos ocultos de la prestación de servicios IFinTrans. https : / / www . jaspe . com / sites / default / files / cisco- jasper- hidden- costs- of- delivering- iFinTrans-services-en_2.pdf. Año 2017.

• WebAssembly. http://webassembly.org/.

• Jan Henrik Ziegeldorf, Oscar García Morchon y Klaus Wehrle. "La privacidad en el mediode las cosas: amenazas y challenges". En: Security and CommunicationNetworks 7.12 (2014), pp. 2728–2742.

Page 42: DIGILITE - firebasestorage.googleapis.com

• Zilliqa. https://www.zilliqa.com/.