Chainlink: 分散型 Oracle ネットワーク

Resumen

En este documento técnico, articulamos una visión para la evolución de Chainlink más allá de su concepción inicial en el documento técnico original Chainlink. prevemos un papel cada vez más amplio para las redes oracle, en el que complementan y mejoran las blockchain existentes y nuevas al proporcionar servicios rápidos, confiables y conectividad universal que preserva la confidencialidad y computación fuera de cadena para smart contracts. La base de nuestro plan es lo que llamamos Redes Oracle Descentralizadas, o DONs para abreviar. Un DON es una red mantenida por un comité de Chainlink nodos. Admite cualquiera de una gama ilimitada de funciones oracle elegidas para despliegue por parte del comité. Un DON actúa así como una poderosa capa de abstracción, ofreciendo interfaces para smart contracts a amplios recursos fuera de la cadena y altamente Recursos informáticos fuera de cadena eficientes pero descentralizados dentro del propio DON. Con DONs como trampolín, Chainlink planea centrarse en avances en siete áreas clave: • smart contracts híbridos: ofrece un marco general potente para aumentar las capacidades smart contract existentes mediante la composición segura en cadena. y recursos informáticos fuera de cadena en lo que llamamos smart contracts híbridos. • Abstraer la complejidad: presentar a los desarrolladores y usuarios soluciones sencillas. La funcionalidad elimina la necesidad de estar familiarizado con complejos subyacentes. protocolos y límites del sistema. • Escalado: garantizar que los servicios oracle alcancen las latencias y rendimientos que exigen los sistemas descentralizados de alto rendimiento. • Confidencialidad: Habilitar sistemas de próxima generación que combinen blockchains' Transparencia innata con nuevas y sólidas protecciones de confidencialidad para datos sensibles. datos. • Orden justo para las transacciones: respaldar la secuenciación de transacciones de maneras que sean justos para los usuarios finales y eviten ataques frontales y de otro tipo por parte de bots y mineros explotadores. • Minimización de la confianza: crear una capa de soporte altamente confiable para smart contracts y otros sistemas dependientes de oracle mediante descentralización, fuerte anclaje en blockchains de alta seguridad, criptográfico técnicas y garantías criptoeconómicas. • Seguridad (criptoeconómica) basada en incentivos: diseñar rigurosamente e implementar mecanismos robustos que garanticen que los nodos en DONs tengan fuertes incentivos económicos para comportarse de manera confiable y correcta, incluso frente a adversarios con buenos recursos. Presentamos innovaciones preliminares y en curso por parte de la comunidad Chainlink en cada una de estas áreas, proporcionando una imagen de la ampliación y cada vez mayor potentes capacidades planificadas para la red Chainlink.

Introducción

Los oracles de blockchain a menudo se consideran hoy en día servicios descentralizados con un objetivo: para reenviar datos de recursos fuera de la cadena a blockchains. Aunque es un paso corto, desde reenviar datos hasta calcularlos, almacenarlos o transmitirlos bidireccionalmente. Esta observación justifica una noción mucho más amplia de la funcionalidad de oracles. Así también hacer los crecientes requisitos de servicio de smart contracts y cada vez más multifacéticos tecnologías que dependen de redes oracle. En resumen, un oracle puede y necesitará Ser una interfaz de propósito general, bidireccional y habilitada para computación entre sistemas dentro y fuera de la cadena. El papel de los oráculos en el ecosistema blockchain es mejorar el rendimiento, la funcionalidad y la interoperabilidad de smart contracts para que puedan traer nuevos modelos de confianza y transparencia a una multiplicidad de industrias. Esta transformación se producirá mediante el uso ampliado de smart contracts híbridos, que fusionan Las propiedades especiales de blockchains con las capacidades únicas de los sistemas fuera de cadena como oracle redes y, por lo tanto, lograr un alcance y poder mucho mayores que los sistemas en cadena en forma aislada. En este documento técnico, articulamos una visión de lo que llamamos Chainlink 2.0, una evolución de Chainlink más allá de su concepción inicial en el documento técnico original Chainlink [98]. Prevemos un papel cada vez más expansivo para las redes oracle, en el que Complementan y mejoran los blockchain existentes y nuevos al proporcionar conectividad y computación universales rápidas, confiables y que preservan la confidencialidad para híbridos. smart contracts. Creemos que las redes oracle incluso evolucionarán hasta convertirse en servicios públicos. para exportar datos de alta integridad de grado blockchain a sistemas más allá del blockchain ecosistema. Hoy en día, Chainlink nodos administrados por un conjunto diverso de entidades se unen en oracle redes para transmitir datos a smart contracts en lo que se conoce como informes. Podemos ver tales oracle nodos como un comité similar al de un consenso clásico blockchain [72], pero con el objetivo de admitir blockchains existentes, en lugar de proporcionar una funcionalidad independiente. Con funciones aleatorias verificables (VRF) e informes fuera de cadena (OCR), Chainlink ya está evolucionando hacia un marco e infraestructura de propósito general para proporcionar los recursos computacionales que los smart contracts requieren para funcionalidad avanzada. La base de nuestro plan para Chainlink 2.0 es lo que llamamos Oracle descentralizado. Redes, o DONs para abreviar. Desde que introdujimos el término “red oracle” en el documento técnico original Chainlink [98], oracles han desarrollado funcionalidades cada vez más ricas y amplitud de aplicación. En este artículo ofrecemos una nueva definición del término según a nuestra visión futura para el ecosistema Chainlink. En esta vista, un DON es una red mantenido por un comité de Chainlink nodos. Basado en un protocolo de consenso, admite cualquiera de una gama ilimitada de funciones oracle elegidas para su implementación por parte del comité. Por lo tanto, un DON actúa como una capa de abstracción blockchain, proporcionando interfaces a recursos fuera de la cadena tanto para smart contracts como para otros sistemas. También proporciona acceso a recursos informáticos fuera de la cadena altamente eficientes pero descentralizados. En general, a DON admite operaciones en una cadena principal. Su objetivo es permitir un acceso seguro y flexible.híbridos smart contracts, que combinan el cálculo dentro y fuera de la cadena con conexión con recursos externos. Destacamos que incluso con el uso de comités en DONs, el propio Chainlink permanece inherentemente sin permiso. DONs actúan como base de un sistema sin permiso marco en el que los nodos pueden unirse para implementar redes personalizadas oracle con sus propios regímenes para la inclusión de nodos, que pueden tener permiso o no. Con DONs como base, planeamos centrarnos en Chainlink 2.0 en avances en siete áreas clave: smart contracts híbridos, abstracción de la complejidad, escalamiento, confidencialidad, orden justo para las transacciones, minimización de la confianza y seguridad (criptoeconómica) basada en incentivos. En la introducción de este artículo, presentamos una descripción general de la descentralización. Oracle Networks en la Sección 1.1 y luego nuestras siete áreas clave de innovación en la Sección 1.2. Describimos la organización del resto de este artículo en la Sección 1.3. 1.1 Redes Oracle descentralizadas Las redes descentralizadas de Oracle están diseñadas para mejorar y ampliar las capacidades de smart contracts en un objetivo blockchain o cadena principal a través de funciones que son no disponible de forma nativa. Lo hacen proporcionando los tres recursos básicos que se encuentran en Sistemas informáticos: redes, almacenamiento y computación. Un DON tiene como objetivo ofrecer estos recursos con fuertes propiedades de confidencialidad, integridad y disponibilidad,1 como así como la rendición de cuentas. Los DONs están formados por comités de nodos oracle que cooperan para cumplir un objetivo específico. trabajo o elegir establecer una relación duradera para proporcionar servicios persistentes a los clientes. Los DONs están diseñados de forma independiente de blockchain. Prometen servir como una herramienta poderosa y flexible para que los desarrolladores de aplicaciones creen soporte fuera de la cadena para sus smart contracts en cualquier cadena principal compatible. Dos tipos de funcionalidades realizan las capacidades de un DON: ejecutables y adaptadores. Los ejecutables son programas que se ejecutan de forma continua y descentralizada en el DON. Si bien no almacenan directamente activos de la cadena principal, tienen importantes beneficios, incluido un alto rendimiento y la capacidad de realizar operaciones confidenciales. cálculo. Los ejecutables se ejecutan de forma autónoma en un DON y realizan funciones deterministas. operaciones. Trabajan de la mano con adaptadores que vinculan el DON a recursos externos y puede ser llamado mediante ejecutables. Los adaptadores, tal como los imaginamos para DONs, son una generalización de los adaptadores externos en Chainlink hoy. Mientras que los adaptadores existentes normalmente solo recuperan datos de fuentes de datos, los adaptadores pueden funcionar bidireccionalmente; en DONs, también pueden aprovechar el cálculo conjunto de DON nodos para lograr características adicionales, como el cifrado de informes para preservar la privacidad del consumo por parte de un ejecutable. Para dar una idea del funcionamiento básico de un DON, la Fig. 1 muestra conceptualmente cómo DON podría usarse para enviar informes a blockchain y así lograr la funcionalidad tradicional y existente de oracle. DONs puede proporcionar muchas características adicionales, sin embargo, más allá 1La “tríada de la CIA” de la seguridad de la información [123, p. 26, §2.3.5].Redes existentes de Chainlink. Por ejemplo, dentro de la estructura general de la Fig. 1, el ejecutable podría registrar datos de precios de activos obtenidos en el DON, utilizando dichos datos para calcular, por ejemplo, un promedio final para sus informes. Figura 1: Figura conceptual que muestra como ejemplo cómo una red Oracle descentralizada puede realizar la funcionalidad básica oracle, es decir, transmitir datos fuera de la cadena a un contrato. un El ejecutable utiliza adaptadores para obtener datos fuera de la cadena, sobre los cuales calcula y envía la salida. a través de otro adaptador a un objetivo blockchain. (Los adaptadores se inician mediante código en el DON, representado por pequeños cuadros azules; Las flechas muestran la dirección del flujo de datos para este ejemplo particular.) El ejecutable también puede leer y escribir en el DON local almacenamiento para mantener el estado y/o comunicarse con otros ejecutables. Las redes flexibles, la computación y el almacenamiento en DONs, todos representados aquí, permiten una gran cantidad de funciones novedosas. aplicaciones. Un beneficio importante de DONs es su capacidad para iniciar nuevos servicios blockchain. DONs son un vehículo mediante el cual las redes oracle existentes pueden implementar rápidamente aplicaciones de servicio eso hoy requeriría la creación de redes especialmente diseñadas. Damos una serie de ejemplos de tales aplicaciones en la Sección 4. En la Sección 3, proporcionamos más detalles sobre DONs, describiendo sus capacidades en términos de la interfaz que presentan a los desarrolladores y usuarios. 1.2 Siete objetivos clave de diseño Aquí revisamos brevemente los siete enfoques clave enumerados anteriormente para la evolución de Chainlink, a saber:Híbridos smart contracts: Central para nuestra visión de Chainlink es la idea de seguridad combinando componentes dentro y fuera de la cadena en smart contracts. Nos referimos a los contratos hacer realidad esta idea como smart contracts híbridos o contratos híbridos.2 Las cadenas de bloques son y seguirán desempeñando dos funciones fundamentales en el servicio descentralizado. Ecosistemas: ambos son los lugares donde se representa la propiedad de las criptomonedas. y anclajes sólidos para servicios descentralizados. Por lo tanto, los contratos inteligentes deben representarse o ejecutarse en la cadena, pero sus capacidades en la cadena son muy limitadas. puramente El código de contrato en cadena es lento, costoso e insular, incapaz de beneficiarse del mundo real. datos y una variedad de funcionalidades que son inherentemente inalcanzables en la cadena, incluidas varias formas de cálculo confidencial, generación de (pseudo)aleatoriedad segura contra manipulación minera / validator, etc. Para que smart contracts alcancen su máximo potencial, se requieren smart contracts estar diseñado con dos partes: una parte en cadena (que normalmente denotamos por SC) y una parte fuera de la cadena, un ejecutable que se ejecuta en un DON (que normalmente denotamos por ejecutivo). El objetivo es lograr una composición segura de la funcionalidad en cadena con la multiplicidad de servicios fuera de la cadena que los DONs pretenden proporcionar. Juntas, las dos partes conformar un contrato híbrido. Presentamos la idea conceptualmente en la Fig. 2. Ya hoy, Chainlink servicios3, como fuentes de datos y VRF, permiten mejoras que de otro modo serían inalcanzables. smart contract aplicaciones, que van desde DeFi hasta NFTs generadas de manera justa y seguros descentralizados, como primeros pasos hacia un marco más general. Como servicios Chainlink expandirse y crecer en rendimiento de acuerdo con nuestra visión en este documento técnico, también aumentará la potencia de los sistemas smart contract en todos los blockchain. Se puede considerar que nuestros otros seis enfoques clave en este documento técnico actúan en el servicio. del primero, general, de contratos híbridos. Estos enfoques implican eliminar lo visible. complejidad de los contratos híbridos, creando servicios adicionales fuera de la cadena que permiten construcción de contratos híbridos cada vez más capaces y, en el caso de la minimización de la confianza, reforzar las propiedades de seguridad logradas por los contratos híbridos. dejamos la idea de contratos híbridos implícitos en gran parte del documento, pero cualquier combinación de La lógica MAINCHAIN con DON puede verse como un contrato híbrido. Abstrayendo la complejidad: Los DONs están diseñados para hacer uso de sistemas descentralizados. sistemas fáciles para desarrolladores y usuarios al abstraer la maquinaria a menudo compleja detrás de la potente y flexible gama de servicios de DONs. Servicios Chainlink existentes Ya tienes esta característica. Por ejemplo, las fuentes de datos en Chainlink hoy presentan interfaces en cadena que no requieren que los desarrolladores se preocupen por los detalles a nivel de protocolo, como los medios por los cuales OCR impone informes de consenso entre un 2La idea de composición de contratos dentro y fuera de la cadena ha surgido previamente en varios formularios, por ejemplo, sistemas de capa 2, blockchains [80] basados en TEE, etc. Nuestro objetivo es respaldar y generalizar estos enfoques y garantizar que puedan abarcar el acceso a datos fuera de la cadena y otros oracle clave servicios. Los servicios 3Chainlink comprenden una variedad de servicios y funcionalidades descentralizados disponibles a través de la red. Los ofrecen numerosos operadores de nodos compuestos en varias redes oracle en todo el ecosistema.Figura 2: Figura conceptual que representa la composición del contrato dentro y fuera de la cadena. un híbrido smart contract 3⃝consta de dos componentes complementarios: un en cadena componente SC 1⃝, residente en un blockchain, y un componente fuera de la cadena ejecutivo 2⃝que se ejecuta en un DON. El DON también sirve como puente entre los dos componentes. como conectar el contrato híbrido con recursos fuera de la cadena, como servicios web, otros blockchains, almacenamiento descentralizado, etc. conjunto descentralizado de nodos. DONs van un paso más allá en el sentido de que amplían la gama de servicios para los cuales Chainlink puede ofrecer a los desarrolladores una capa de abstracción con interfaces optimizadas que lo acompañan para servicios de alto nivel. Presentamos varios ejemplos de aplicaciones en la Sección 4 que destacan este enfoque. Imaginamos que las empresas, por ejemplo, utilicen DONs como una forma de middleware seguro para conectar sus sistemas heredados a blockchains. (Consulte la Sección 4.2.) Este uso de DON abstrae la complejidad de la dinámica general de blockchain (tarifas, reorganizaciones, etc.). También abstrae las características de blockchains específicos, lo que permite a las empresas conectar sus sistemas existentes a una gama cada vez más amplia de sistemas blockchain sin una necesidad de experiencia especializada en estos sistemas o, más generalmente, en el desarrollo de sistemas descentralizados. En última instancia, nuestra ambición es impulsar el grado de abstracción logrado por Chainlink hasta el punto de implementar lo que llamamos una metacapa descentralizada. tal capa abstraería la distinción dentro y fuera de la cadena para todas las clases de desarrolladores y usuarios de DApps, lo que permite la creación y el uso fluidos de servicios descentralizados.Para simplificar el proceso de desarrollo, los desarrolladores podrían especificar la funcionalidad DApp en la metacapa como una aplicación virtual en un modelo de máquina unificada. ellos podrían luego use un compilador de metacapa descentralizado para crear una instancia de la DApp automáticamente como un conjunto de funcionalidades descentralizadas interoperativas que abarcan blockchains, DONs y servicios externos. (Uno de estos servicios externos podría ser un sistema empresarial, lo que haría que la metacapa fuera útil para aplicaciones que involucran sistemas empresariales heredados). La compilación es similar a cómo los compiladores y kits de desarrollo de software (SDK) modernos Apoyar a los programadores generalistas en el uso de todo el potencial del hardware heterogéneo. arquitecturas que constan de una CPU de uso general y hardware especializado como GPU, aceleradores de aprendizaje automático o enclaves confiables. La figura 3 presenta esta idea a nivel conceptual. Los smart contract híbridos son un primer paso en el camino hacia esta visión y hacia un concepto que llamamos metacontratos. Los metacontratos son aplicaciones codificadas de forma descentralizada. metacapa e implícitamente abarca la lógica dentro de la cadena (smart contracts), así como el cálculo y la conectividad fuera de la cadena entre varios blockchains y fuera de la cadena existentes. servicios. Dada la necesidad de compatibilidad con lenguajes y compiladores, nuevos modelos de seguridad y armonización conceptual y técnica de tecnologías dispares, sin embargo, la realización de una verdadera metacapa descentralizada es un objetivo ambicioso al que aspiramos a largo plazo. horizonte temporal. No obstante, es un modelo ideal útil a tener en cuenta al leer. este documento, que no se detalla aquí, pero es algo en lo que planeamos centrarnos en nuestro trabajo futuro sobre Chainlink. Escalado: Un objetivo de importancia preeminente en nuestros diseños en evolución es permitir que Chainlink red para satisfacer las crecientes necesidades de escala del ecosistema blockchain. Dado que la congestión de la red se está convirtiendo en un problema recurrente en los sistemas sin permiso existentes. blockchains [86], se están utilizando diseños nuevos y de mayor rendimiento blockchain, por ejemplo, [103, 120, 203], así como tecnologías de escalado de capa 2 complementarias, por ejemplo, [5, 12, 121, 141, 169, 186, 187]. Los servicios de Oracle deben lograr latencias y rendimientos que satisfacen las demandas de rendimiento de estos sistemas y al mismo tiempo minimizan las tarifas en cadena (por ejemplo, los costos del gas) tanto para los operadores contratados como para los usuarios comunes. Con DONs, Chainlink La funcionalidad pretende ir más allá y ofrecer un rendimiento lo suficientemente alto para sistemas puramente basados en web. Los DONs obtienen gran parte de su ganancia de rendimiento del uso de protocolos de consenso rápidos, basados en comités o sin permiso, que combinan con los blockchains. ellos apoyan. Esperamos que muchos DONs con diferentes configuraciones se ejecuten en paralelo; Diferentes DApps y usuarios pueden navegar por las compensaciones en las opciones de consenso subyacentes. según los requisitos de su aplicación. DONs pueden verse en efecto como tecnologías de capa 2. Esperamos que entre otros servicios, DONs respaldarán el Transaction Execution Framework (TEF), que facilita la integración eficiente de DONs y, por lo tanto, oracles con otros de alto rendimiento sistemas de capa 2, por ejemplo, rollups, sistemas que agrupan transacciones fuera de la cadena para lograr mejoras de rendimiento. Introducimos el TEF en la Sección 6.

Figura 3: Figura conceptual que muestra la realización ideal de una metacapa descentralizada. Para facilidad de desarrollo, un desarrollador especifica una DApp, resaltada en rosa, como una Aplicación en un modelo de máquina unificado. Un compilador de metacapa descentralizado genera automáticamente las funcionalidades de interoperabilidad correspondientes: smart contracts (denotado por SC), lógica (indicada por exec) en DONs, adaptadores que se conectan a servicios externos de destino, etc., como se indica resaltado en amarillo. La figura 4 muestra conceptualmente cómo los DON mejoran el escalado de blockchain (smart contract). concentrando el procesamiento de transacciones y oracle-informes fuera de la cadena, en lugar de en cadena. Este cambio en el lugar principal de cálculo reduce la latencia de las transacciones y tarifas al tiempo que aumenta el rendimiento de las transacciones. Confidencialidad: Las cadenas de bloques brindan una transparencia sin precedentes para los smart contracts y las aplicaciones que realizan. Pero existe una tensión básica entre transparencia y confidencialidad. Hoy, por ejemplo, las transacciones de intercambio descentralizadas de los usuariosFigura 4: Figura conceptual que muestra cómo las redes Oracle descentralizadas mejoran la escalado de smart contracts habilitados para blockchain. Figura A ⃝muestra un oracle convencional arquitectura. Las transacciones se envían directamente al blockchain, al igual que los informes oracle. Por tanto, el blockchain, resaltado en amarillo, es el lugar principal para el procesamiento de transacciones. La Figura B⃝ muestra el uso de DON para respaldar contratos en blockchain. Un DON El ejecutable procesa transacciones junto con datos de sistemas externos y los reenvía. resultados (por ejemplo, transacciones agrupadas o cambios en el estado del contrato resultantes de los efectos de las transacciones) al blockchain. El DON, resaltado en amarillo, es, por tanto, el principal lugar para el procesamiento de transacciones. las acciones se registran en la cadena, lo que facilita el seguimiento del comportamiento del intercambio, pero también hacer públicamente visibles las transacciones financieras de los usuarios. De manera similar, los datos transmitidos a dispositivos inteligentes los contratos permanecen en cadena. Esto hace que dichos datos sean convenientemente auditables, pero actúa como un desincentivo para los proveedores de datos que deseen proporcionar a smart contracts datos confidenciales o datos de propiedad. Creemos que las redes oracle desempeñarán un papel fundamental a la hora de catalizar la próxima generación. sistemas que combinan la transparencia innata de blockchains con nuevas protecciones de confidencialidad. En este artículo, mostramos cómo lo harán utilizando tres enfoques principales: • Adaptadores que preservan la confidencialidad: dos tecnologías con implementación planificada en las redes de Chainlink, DECO [234] y Town Crier [233], habilite los nodos oracle para recuperar datos de sistemas fuera de la cadena de manera que protejan la privacidad y los datos del usuario confidencialidad. Desempeñarán un papel clave en el diseño de adaptadores para DONs. (Consulte la Sección 3.6.2 para obtener detalles sobre estas dos tecnologías). • Cálculo confidencial: los DONs pueden simplemente ocultar sus cálculos a los blockchains que confían. Utilizando computación segura de múltiples partes y/o entornos de ejecución confiables, también es posible una mayor confidencialidad en la que DON nodos computan sobre datos sobre los cuales ellos mismos no tienen visibilidad.

• Compatibilidad con sistemas confidenciales de capa 2: el TEF está diseñado para admitir una variedad de sistemas de capa 2, muchos de los cuales utilizan pruebas de conocimiento cero para proporcionar diversas formas de confidencialidad de las transacciones. Analizamos estos enfoques en la Sección 3 (con detalles adicionales en la Sección 6, Apéndice B.1 y Apéndice B.2). La figura 5 presenta una vista conceptual de cómo los datos confidenciales podrían fluir desde fuentes externas a un smart contract mediante adaptadores que preservan la confidencialidad y Cálculo confidencial en un DON. Figura 5: Diagrama conceptual de operaciones de preservación de la confidencialidad en un DON en datos confidenciales (resaltados en amarillo). Datos de origen confidenciales (círculos negros) en la web Los servidores se extraen al DON mediante adaptadores que preservan la confidencialidad (líneas azules con doble flecha). El DON recibe datos derivados (círculos huecos) de estos adaptadores: el resultado de aplicar una función o, por ejemplo, compartir secretos, a la fuente sensible datos. Un ejecutable en DON puede aplicar cálculos confidenciales a datos derivados para construir un informe (doble círculo), que envía a través de un adaptador al blockchain. Creemos que las herramientas poderosas para el manejo de datos confidenciales abrirán todo un gama de aplicaciones. Entre ellos se encuentran las finanzas privadas descentralizadas (y centralizadas), la identidad descentralizada, los préstamos en cadena basados en crédito y sistemas más eficientes y eficientes. protocolos de acreditación y conocimiento del cliente fáciles de usar, como analizamos en la Sección 4. Equidad de orden para transacciones: Los diseños blockchain de hoy tienen un poco de suciedad. Secreto a voces: Están efímeramente centralizados. Los mineros y validators pueden ordenar trans-acciones como ellos elijan. El orden de las transacciones también puede ser manipulado por los usuarios como en función de las tarifas de red que pagan (por ejemplo, precios del gas en Ethereum) y en algunos casos medida aprovechando las rápidas conexiones de red. Tal manipulación puede, por Por ejemplo, tomar la forma de front-running, en el que un actor estratégico como un minero observa la transacción de un usuario e inserta su propia transacción de explotación en una anterior posición en el mismo bloque, robando efectivamente dinero del usuario aprovechando el conocimiento avanzado de la transacción del usuario. Por ejemplo, un bot puede realizar una orden de compra. antes que el de un usuario. Entonces puede aprovechar el aumento del precio de los activos inducido por la comercio del usuario. Algunos bots atacan al frente y perjudican a los usuarios normales, de forma análoga a la alta frecuencia. comercio en Wall Street—ya prevalece y está bien documentado [90], como están relacionados ataques como [159] en ejecución invertida y transacciones automatizadas que imitan [195]. Incluso han surgido recientemente propuestas para sistematizar la explotación de pedidos por parte de los mineros [110]. Las tecnologías de capa 2 como rollups no resuelven el problema, sino que simplemente recentralizan ordenando, poniéndolo en manos de la entidad que crea un rollup. Uno de nuestros objetivos es introducir en Chainlink un servicio llamado Fair Sequencing. Servicios (FSS) [137]. FSS ayuda a los diseñadores smart contract a garantizar pedidos justos para sus transacciones y evitar ataques frontales, posteriores y relacionados a las transacciones de los usuarios, así como otros tipos de transacciones, como la transmisión de informes oracle. FSS permite a DON implementar ideas como la noción rigurosa y temporal de equidad de orden introducida en [144]. Como beneficio incidental, FSS también puede reducir la red de los usuarios. tarifas (por ejemplo, costos de gasolina). Brevemente, en FSS, las transacciones pasan a través de DON, en lugar de propagarse directamente a un destino smart contract. El DON ordena las transacciones y luego las reenvía ellos al contrato. Figura 6: Ejemplo de cómo FSS es benéfico. Figura A ⃝muestra cómo un minero, explotando su poder centralizado para ordenar transacciones, puede intercambiar un par de transacciones: transacción 1⃝ llega antes de 2⃝, pero el minero lo secuencia después de 2⃝. Por el contrario, la Fig. B⃝muestra cómo un DON descentraliza el proceso de pedido entre DON nodos. Si hay quórum de los nodos honestos reciben 1⃝antes de 2⃝, el FSS hace que 1⃝ aparezca antes de 2⃝ en la cadena— evitando el reordenamiento de los mineros adjuntando números de secuencia exigibles por contrato. La Fig. 6 compara la minería estándar con FSS. Muestra cómo en la minería estándar,El proceso de pedido de transacciones está centralizado con el minero y, por lo tanto, sujeto a Manipulación, como reordenar un par de transacciones con respecto a su llegada. veces. Por el contrario, en FSS, el proceso está descentralizado entre DON nodos. Suponiendo Con un quórum de nodos honestos, FSS ayuda a hacer cumplir políticas como el ordenamiento temporal de transacciones, reduciendo las oportunidades de manipulación por parte de mineros y otras entidades. Además, dado que los usuarios no necesitan competir por pedidos preferenciales basados en el precio del gas, pueden pagar precios de gasolina relativamente bajos (mientras que las transacciones del DON se pueden agrupar para ahorrar gasolina). Minimización de confianza: Nuestro objetivo general en el diseño de DONs es facilitar un sistema altamente capa confiable de soporte para smart contracts y otros sistemas oracle dependientes mediante descentralización, herramientas criptográficas y garantías criptoeconómicas. Un DON en sí está descentralizado y los usuarios pueden elegir entre cualquier DON disponible que admite la cadena principal en la que desean operar o generar DONs adicionales con comités de nodos en los que confían. Sin embargo, para algunas aplicaciones, particularmente smart contracts, los usuarios Chainlink pueden favorecer un modelo de confianza que trate la cadena principal respaldada por un DON como más confiable que el DON mismo. Para dichos usuarios, ya tenemos o planeamos incorporar al arquitectura de la red Chainlink una serie de mecanismos que permiten contratos en una cadena principal para fortalecer las garantías de seguridad proporcionadas por DONs, mientras que en el Al mismo tiempo, también se aplican protecciones contra la posibilidad de fuentes de datos corruptas. como los servidores web de los que el DON obtiene datos. Describimos estos mecanismos en la Sección 7. Se dividen en cinco títulos principales: • Autenticación de origen de datos: herramientas que permiten a los proveedores de datos firmar digitalmente sus datos y con ello fortalecer la cadena de custodia entre el origen y el contrato de confianza. • DON informes minoritarios: indicadores emitidos por un subconjunto minoritario de DON nodos que observa mala conducta mayoritaria en el DON. • Barandillas: Lógica en una cadena principal que detecta condiciones anómalas y pausas o detiene la ejecución del contrato (o invoca otras soluciones). • Gobernanza que minimiza la confianza: uso de actualizaciones de publicación gradual para facilitar la inspección comunitaria, así como intervenciones de emergencia descentralizadas para una rápida respuesta a fallas del sistema. • Autenticación de entidades descentralizadas: uso de infraestructura de clave pública (PKI) para identificar entidades en la red Chainlink. La figura 7 presenta un esquema conceptual de nuestros objetivos de minimización de confianza. Seguridad basada en incentivos (criptoeconómica): La descentralización de la generación de informes entre oracle nodos ayuda a garantizar la seguridad incluso cuando algunos nodos están dañados.

Figura 7: Representación conceptual del objetivo de minimización de confianza de Chainlink, que es minimizar la necesidad de los usuarios de un comportamiento correcto del DON y fuentes de datos como la web servidores. Las luces amarillas en la figura indican loci de minimización de confianza: DON y conjuntos individuales o minoritarios de servidores web. Los puntos destacados en rosa indican los componentes del sistema. que son altamente confiables por supuesto: contratos en el blockchain y una mayoría de servidores web, es decir, servidores web en conjunto. Sin embargo, es igualmente importante garantizar que los nodos tengan un incentivo financiero para comportarse correctamente. Replantear, es decir, exigir a los nodos que proporcionen depósitos de LINK y recortar (confiscar) estos depósitos en caso de mala conducta, jugará un papel clave en Chainlink. Es un diseño de incentivo importante que ya se utiliza en varios blockchains, por ejemplo, [81, 103, 120, 204]. Sin embargo, apostar en Chainlink se ve muy diferente a staking en modo independiente. blockchains. Apostar por blockchains tiene como objetivo evitar ataques al consenso. tiene un Objetivo diferente en Chainlink: garantizar la entrega oportuna de informes oracle correctos. Un sistema staking bien diseñado para una red oracle debería generar ataques como el soborno. no rentable para un adversario, incluso cuando el objetivo es un smart contract con alta valor monetario. En este artículo, presentamos un enfoque general para staking en Chainlink con tres claves innovaciones:1. Un poderoso modelo adversarial que abarque ataques pasados por alto en las enfoques. Un ejemplo es lo que llamamos posible soborno. Esta es una forma de soborno que determina qué nodos reciben sobornos de forma condicional, por ejemplo, ofrece sobornos garantizados por adelantado a los nodos que un mecanismo staking selecciona en aleatorio para roles particulares (como desencadenar la adjudicación de informes). 2. Impacto superlineal staking, lo que significa informalmente que para tener éxito, un adversario debe tener un presupuesto de B$ mayor que los depósitos combinados de todos los oracle nodos. Más precisamente, queremos decir que en función de n, \(B(n) ≫\)dn en un red de n oracle nodos, cada uno con un monto de depósito fijo $d (más formalmente, \(B(n) is asymptotically larger in n than \)dn). La figura 8 ofrece una vista conceptual de esta propiedad. 3. El Marco de Incentivos Implícitos (IIF), un modelo de incentivos que hemos ideado para abarcar incentivos empíricamente mensurables más allá de los staking depositados explícitos fondos, incluidas las oportunidades de tarifas futuras de los nodos. El IIF amplía la noción de participación más allá de los depósitos de nodos explícitos. Figura 8: Diagrama conceptual que representa el escalado superlineal en Chainlink staking. el El soborno $B(n) requerido por un adversario crece más rápido en n que los depósitos combinados. $dn de todos los oracle nodos. Mostramos cómo el impacto IIF y el staking superlineal juntos inducen lo que llamamos un círculo virtuoso de seguridad económica para las redes oracle. Cuando entran nuevos usuarios

el sistema, aumentando las posibles ganancias futuras al ejecutar Chainlink nodos, el El costo marginal de la seguridad económica cae para los usuarios actuales y futuros. En un régimen de demanda elástica, este costo disminuido incentiva a usuarios adicionales a hacer uso de la red, perpetuando continuamente la adopción en un círculo virtuoso continuo. Nota: Si bien este documento técnico describe elementos importantes de nuestra visión para la evolución de Chainlink, es informal e incluye pocos detalles técnicos detallados. planeamos publicar documentos técnicos centrados en características y enfoques adicionales a medida que evolucionan. Además, es importante destacar que muchos elementos de la visión presentada aquí (mejoras de escala, tecnologías de confidencialidad, FSS, etc.) pueden y serán implementado en forma preliminar incluso antes de que los DONs avanzados se conviertan en una característica básica de Chainlink. 1.3 Organización de este documento Presentamos nuestro modelo de seguridad y notación en la Sección 2 y describimos el Descentralizado API de Oracle Network en la Sección 3. En la Sección 4, presentamos una serie de ejemplos de aplicaciones para las cuales DONs proporcionan una plataforma de implementación atractiva. Los lectores pueden Aprenda la mayoría de los conceptos clave del artículo leyendo hasta este punto. El resto del artículo contiene más detalles. Describimos la secuenciación justa Services (FSS) en la Sección 5 y el Marco de Ejecución de Transacciones (TEF) en la Sección 6. Describimos nuestro enfoque para la minimización de la confianza en la Sección 7. Consideramos algunos importantes requisitos de implementación DON, a saber, implementación incremental de funciones, membresía dinámica del libro mayor y responsabilidad en la Sección 8. Finalmente, en la Sección 9, brindamos una descripción general de nuestro enfoque en desarrollo para el diseño de incentivos. Concluimos en la Sección 10. Para ayudar a los lectores que tienen una familiaridad limitada con los conceptos de este documento, proporcione un glosario en el Apéndice A. Presentamos más detalles sobre la interfaz DON y funcionalidad en el Apéndice B y presentar algunos adaptadores de ejemplo en el Apéndice C. En el Apéndice D, describimos una primitiva criptográfica para fuentes de datos de confianza minimizada. autenticación denominada firmas funcionales e introducir una nueva variante denominada firmas funcionales discretizadas. Discutimos algunas consideraciones relacionadas con el comité. selección para DONs en el Apéndice F.

Modelo de seguridad y objetivos

Una red Oracle descentralizada es un sistema distribuido distinto que esperamos que inicialmente ser implementado típicamente, aunque no necesariamente, por un comité protocolo de consenso y ejecutado por un conjunto de nodos oracle. Un DON está diseñado principalmente para aumentar las capacidades de un smart contract en una cadena principal con informes oracle y otros servicios, pero puede proporcionar esos mismos servicios de soporte a otros sistemas que no sean blockchain y, por lo tanto, no necesita estar asociado con una cadena principal en particular.

Por lo tanto, el modelo y las propiedades que consideramos son en gran medida independientes del uso de las aplicaciones particulares de un DON. 2.1 Modelo arquitectónico actual Es importante recalcar que Chainlink hoy no es un servicio monolítico, sino más bien un marco sin permiso dentro del cual es posible lanzar distintos e independientes redes de oracle nodos [77]. Las redes tienen conjuntos heterogéneos de operadores de nodos y diseños. También pueden diferir en términos de los tipos de servicios que brindan, lo que puede incluir, por ejemplo, fuentes de datos, prueba de reservas, aleatoriedad verificable, etc. Otro Las diferencias pueden incluir el grado de descentralización, el tamaño de la red en términos de valor bloqueado que admite y varios parámetros de nivel de servicio, como la frecuencia de datos y precisión. El modelo sin permisos de Chainlink fomenta el crecimiento de un ecosistema en el que Los proveedores se especializan en los servicios que mejor pueden brindar a la comunidad. esto Es probable que un modelo genere menores costos para los usuarios y una mayor calidad de servicio que un modelo que requiere que todos los nodos y redes proporcionen una gama completa de servicios, un enfoque que fácilmente puede derivar en la adopción en todo el sistema de los servicios que representan los menos denominador común de los recursos disponibles para los nodos. A medida que Chainlink evoluciona hacia diseños basados en DON en Chainlink 2.0, continuamos apoyar el modelo de un marco abierto y sin permisos, teniendo en cuenta el objetivo de Proporcionar a los usuarios una gama de opciones de servicios que globalmente resulten en la mejor combinación. con requisitos de aplicación particulares. 2.2 Supuestos de consenso Usamos el término Red Oracle Descentralizada para abarcar la funcionalidad completa de el sistema oracle que describimos: tanto la estructura de datos que mantienen los nodos oracle como la API principal colocada encima. Usamos el término libro mayor (minúscula), denotado por L, para referirnos a los datos subyacentes. estructura mantenida por un DON y utilizada para respaldar los servicios particulares que proporciona. Hacemos hincapié en que nuestro marco DON no trata a L como un sistema independiente como a blockchain: Su propósito es soportar blockchains y otros sistemas. Las cadenas de bloques son, Por supuesto, es una manera de crear un libro de contabilidad confiable, pero hay otras. esperamos DONs en muchos casos para realizar sus libros de contabilidad subyacentes utilizando Byzantine Fault Tolerant (BFT), que son considerablemente anteriores a blockchains como Bitcoin [174]. Usamos Notación de tipo BFT y propiedades en todo el documento para mayor comodidad, aunque enfatice que DONs se pueden realizar utilizando protocolos de consenso sin permiso. Conceptualmente, un libro mayor L es un tablero de anuncios en el que los datos se ordenan linealmente. Generalmente consideramos que un libro mayor tiene algunas propiedades clave comúnmente atribuidas a blockchains [115]. Un libro mayor es: • Sólo anexar: Los datos, una vez agregados, no se pueden eliminar ni modificar.• Público: Cualquiera puede leer su contenido, que es consistente a lo largo del tiempo en el vista de todos los usuarios.4 • Disponible: escritores autorizados siempre pueden escribir en el libro mayor y leerlo por cualquier persona de manera oportuna. Son posibles propiedades alternativas en el libro mayor para un DON cuando se realizan mediante un comité. Por ejemplo, el acceso de escritura al libro mayor podría estar restringido a ciertos usuarios, como puede tener acceso de lectura para algunas aplicaciones, es decir, el libro mayor no necesita ser público como se define arriba. De manera similar, las reglas del libro mayor podrían permitir la modificación o redacción de datos. nosotros no Sin embargo, en este artículo se consideran explícitamente tales variantes. El diseño modular de DONs puede admitir cualquiera de una amplia variedad de BFT modernos. protocolos, por ejemplo, Hotstuff[231]. La elección exacta dependerá de supuestos de confianza y características de la red entre los oracle nodos. En principio, un DON podría alternativamente utilizar un blockchain sin permiso de alto rendimiento para su libro mayor en su función de soporte de un sistema igualmente escalable de capa 2 o blockchain. Asimismo, también es posible la hibridación: En principio, el DON podría estar compuesto por nodos que son validators en un sistema existente. blockchain, por ejemplo, en sistemas de prueba de participación en los que se seleccionan comités para ejecutar transacciones, por ejemplo, [8, 81, 120, 146, 204]. Este modo particular de operación requiere que Los nodos operan de manera de doble uso, es decir, operan como nodos blockchain y DON. nodos. (Ver la Sección 8.2 para una discusión de técnicas para asegurar la continuidad en el cambio comités y el Apéndice F para algunas advertencias sobre la selección aleatoria de comités.) En la práctica, en los algoritmos BFT modernos, los nodos firman digitalmente mensajes en el libro mayor. Por conveniencia, asumimos que L tiene una clave pública asociada pkL y que su contenido están firmados por la clave privada correspondiente. Esta notación general se aplica incluso cuando los datos en L se firman usando firmas de umbral.5 Las firmas de umbral son convenientes, ya que permiten una identidad persistente para un DON incluso con cambios de membresía en los nodos que lo ejecutan. (Ver Apéndice B.1.3.) Por lo tanto, asumimos que skL tiene un secreto compartido. en forma de umbral (k, n) para algún parámetro de seguridad k, por ejemplo, k = 2f + 1 y n = 3f + 1, donde f es el número de nodos potencialmente defectuosos. (Al elegir k en este De esta manera, nos aseguramos de que los nodos defectuosos no puedan aprender skL ni montar una denegación de servicio. ataque impidiendo su uso.) Un mensaje en L toma la forma M = (m, z), donde m es una cadena y z un mensaje único. número de índice secuencial. Cuando corresponda, escribimos mensajes en la forma m = ⟨Tipo de mensaje: carga útil⟩. El tipo de mensaje MessageType es azúcar sintáctico que indica la función de un mensaje en particular. 4En los casos en los que un blockchain sin carácter definitivo realiza un libro mayor, la inconsistencia generalmente se abstrae lejos ignorando los bloques insuficientemente profundos o “podando” [115]. 5En la práctica, algunas bases de código, por ejemplo, LibraBFT [205], una variante de Hotstuff, han adoptado actualmente firmas múltiples, en lugar de firmas de umbral, el intercambio ofrecía una complejidad de comunicación reducida para Ingeniería más sencilla. Con algún costo adicional, los nodos oracle pueden agregar firmas de umbral a los mensajes escritos para L incluso si el protocolo de consenso utilizado para L no los emplea.2.3 Notación Denotamos el conjunto de n oracle nodos que ejecutan el libro mayor como O = {Oi}n yo=1. tal Un conjunto de nodos a menudo se denomina comité. Por simplicidad, suponemos que el conjunto de oracles que implementa la funcionalidad DON, es decir, servicios encima de L, es idéntico a que manteniendo L, pero pueden ser distintos. Dejamos que pki denote la clave pública de jugador Oi, y esquiar la clave privada correspondiente. La mayoría de los algoritmos BFT requieren al menos n = 3f + 1 nodos, donde f es el número de nodos potencialmente defectuosos; Los nodos restantes son honestos, en el sentido de que siguen el protocolo exactamente como se especifica. Nos referimos al comité O como honesto si cumple con esto requisito, es decir, tiene más de 2/3 de fracción de nodos honestos. A menos que se haga lo contrario Dicho esto, asumimos que O es honesto (y un modelo estático de corrupción). Usamos pkO / skO indistintamente con pkL/skL, según el contexto. Sea σ = Sigpk[m] una firma en el mensaje m con respecto a pk, es decir, usando clave privada correspondiente sk. Dejemos que verificar(pk, σ, m) →{falso, verdadero} denote un algoritmo de verificación de firma correspondiente. (Dejamos la generación de claves implícita en todo el artículo). Usamos la notación S para indicar una fuente de datos y S para indicar el conjunto completo de nS fuentes en un contexto determinado. Denotamos por MAINCHAIN un contrato inteligente habilitado blockchain apoyado por un DON. Usamos el término contrato de confianza para denotar cualquier contrato en MAINCHAIN que se comunica con un DON, y usa la notación SC para denotar tal contrato. Generalmente asumimos que un DON admite una única cadena principal MAINCHAIN, aunque puede admitir varias cadenas de este tipo, como mostramos en los ejemplos de la Sección 4. DON puede y normalmente admitirá múltiples contratos dependientes de MAINCHAIN. (como Como se indicó anteriormente, un DON también puede admitir servicios que no sean blockchain). 2.4 Nota sobre los modelos de confianza Como se señaló anteriormente, los DONs pueden construirse sobre protocolos de consenso basados en comités, y nosotros Se espera que utilicen habitualmente dichos protocolos. Hay muchos argumentos sólidos que una de las dos alternativas, basada en comité o sin permiso blockchains, proporciona mayor seguridad que el otro. Es importante reconocer que la seguridad de las empresas basadas en comités versus las no autorizadas Los sistemas descentralizados son inconmensurables. Comprometer un PoW o un PoS blockchain vía ataque del 51% requiere que un adversario obtenga la mayoría de los recursos de manera efímera y potencialmente de forma anónima, por ejemplo alquilando hash energía en un sistema PoW. tal En la práctica, los ataques ya han afectado a varios blockchains [200, 34]. En contraste, comprometer un sistema basado en comités significa corromper un número umbral (normalmente un tercio) de sus nodos, donde los nodos pueden ser conocidos públicamente, tener buenos recursos, y entidades confiables. Por otro lado, los sistemas basados en comités (así como los sistemas “híbridos” sin permiso) sistemas que apoyan a los comités) pueden soportar más funcionalidades que las estrictamenteSistemas sin misión. Esto incluye la capacidad de mantener secretos persistentes, como Claves de firma y/o cifrado: una posibilidad en nuestros diseños. Destacamos que, en principio, los DONs pueden construirse sobre un comité o protocolo de consenso sin permiso y los implementadores DON pueden, en última instancia, optar por adoptar cualquiera de los dos enfoques. Reforzar los modelos de confianza: Una característica clave de Chainlink hoy es la capacidad de los usuarios de seleccionar nodos basándose en registros descentralizados de sus historiales de rendimiento, como se analizó en la Sección 3.6.4. El mecanismo staking y el marco de incentivos implícitos que presentamos en la Sección 9 juntos constituyen un diseño de mecanismo riguroso y de amplio alcance. marco que brindará a los usuarios una capacidad enormemente ampliada para medir la seguridad de DONs. Este mismo marco también hará posible que los propios DONs para hacer cumplir diversos requisitos de seguridad en los nodos participantes y garantizar el funcionamiento dentro de modelos de confianza sólidos. También es posible utilizar las herramientas descritas en este documento para DONs para hacer cumplir requisitos especiales del modelo de confianza, como el cumplimiento de requisitos reglamentarios. Para Por ejemplo, utilizando las técnicas analizadas en la Sección 4.3, los nodos pueden presentar evidencia de características del operador de nodo, por ejemplo, territorio de operación, que pueden usarse para ayudar hacer cumplir, por ejemplo, el artículo 3 del Reglamento General de Protección de Datos (GDPR) (“Ámbito Territorial”) [105]. De lo contrario, dicho cumplimiento puede ser difícil de lograr. reunirse en sistemas descentralizados [45]. Además, en la Sección 7 analizamos los planes para fortalecer la solidez de DONs a través de mecanismos de minimización de confianza en las principales cadenas que soportan.

Interfaz de red Oracle descentralizada y Ca-

pabilidades Aquí esbozamos brevemente las capacidades de DONs en términos del simple pero poderoso interfaz para la que están diseñados. Las aplicaciones en un DON se componen de ejecutables y adaptadores. Un ejecutable es un programa cuya lógica central es un programa determinista, análogo a un smart contract. Un ejecutable también tiene varios iniciadores que lo acompañan, programas que llaman a la entrada puntos en la lógica del ejecutable cuando ocurren eventos predeterminados, por ejemplo, en ciertos momentos (como un trabajo cron), cuando un precio cruza un umbral, etc., muy parecido a Keepers (consulte la Sección 3.6.3). Los adaptadores proporcionan interfaces a recursos fuera de la cadena y pueden ser llamados por ya sea los iniciadores o la lógica central en los ejecutables. Como su comportamiento puede depender de eso de recursos externos, los iniciadores y adaptadores pueden comportarse de forma no determinista. Describimos la interfaz de desarrollador DON y el funcionamiento de los ejecutables y adaptadores en términos de los tres recursos que normalmente se utilizan para caracterizar los sistemas informáticos: redes, computación y almacenamiento. Damos una breve descripción de cada uno de estos recursos a continuación y proporcione más detalles en el Apéndice B.

3.1 Redes Los adaptadores son interfaces a través de las cuales los ejecutables que se ejecutan en un DON pueden enviar y recibir datos de sistemas fuera de DON. Los adaptadores pueden verse como una generalización de los adaptadores utilizados en Chainlink hoy [20]. Los adaptadores pueden ser bidireccionales, es decir, no puede simplemente extraer, sino enviar datos desde un DON a un servidor web. También pueden aprovechar protocolos distribuidos, así como funcionalidad criptográfica, como seguridad multipartita cálculo. Figura 9: Adaptadores que conectan un DON, denominado DON1, con una variedad de recursos diferentes, incluido otro DON, denominado DON2, un blockchain (cadena principal) y su mempool, almacenamiento externo, un servidor web y dispositivos IoT (a través de un servidor web). Se muestran ejemplos de recursos externos para los que se pueden crear adaptadores. en la Fig. 9. Incluyen: • Blockchains: un adaptador puede definir cómo enviar transacciones a un blockchain y cómo leer bloques, transacciones individuales u otro estado del mismo. un adaptador También se puede definir para un mempool de blockchain. (Ver Sección 3.5.) • Servidores web: los adaptadores pueden definir API a través de las cuales se pueden recuperar datos. desde servidores web, incluidos sistemas heredados que no están especialmente adaptados para interactuando con DONs. Dichos adaptadores también pueden incluir API para enviar datos a dichos servidores. Los servidores web a los que se conecta un DON pueden servir como puertas de enlace a recursos adicionales, como dispositivos de Internet de las cosas (IoT).• Almacenamiento externo: un adaptador puede definir métodos para leer y escribir en el almacenamiento. servicios fuera del DON, como un sistema de archivos descentralizado [40, 188] o nube almacenamiento. • Otros DONs: los adaptadores pueden recuperar y transmitir datos entre DONs. Esperamos que las implementaciones iniciales de DON incluyan un conjunto de componentes básicos adaptadores para recursos externos de uso común y permitirá además DON-específicos Los adaptadores serán publicados por DON nodos. Mientras los desarrolladores smart contract escriben adaptadores hoy, esperamos que construyan adaptadores aún más potentes utilizando este avanzado funcionalidad. Esperamos que, en última instancia, los usuarios puedan crear nuevos adaptadores en un manera sin permiso. Algunos adaptadores deben construirse de manera que garanticen la persistencia y disponibilidad de recursos externos controlados por un DON. Por ejemplo, el almacenamiento en la nube puede requieren el mantenimiento de una cuenta de servicios en la nube. Además, un DON puede realizar gestión descentralizada de claves privadas en nombre de los usuarios (como en, por ejemplo, [160]) y/o ejecutables. En consecuencia, el DON es capaz de controlar recursos, como criptomonedas, que pueden usarse, por ejemplo, para enviar transacciones en un objetivo blockchain. Consulte el Apéndice B.1 para obtener más detalles sobre los adaptadores DON, así como el Apéndice C para algunos Adaptadores de ejemplo. 3.2 Computación Un ejecutable es la unidad básica de código en un DON. Un ejecutable es un par exec = (lógica, inicio). Aquí, la lógica es un programa determinista con un número de entradas designadas. puntos (logic1, logic2, . . . , logicℓ) e init es un conjunto de iniciadores correspondientes (init1, init2, . . . , inicio). Para garantizar la total auditabilidad del DON, la lógica de un ejecutable utiliza el libro mayor subyacente L para todas las entradas y salidas. Así, por ejemplo, cualquier adaptador Los datos que sirven como entrada para un ejecutable deben almacenarse primero en L. Iniciadores: Los iniciadores en Chainlink hoy provocan ejecuciones de trabajos dependientes de eventos en Chainlink nodos [21]. Los iniciadores en DONs funcionan de manera muy similar. Sin embargo, un iniciador DON está específicamente asociado con un ejecutable. Un iniciador puede depender en un evento o estado externo, en la hora actual o en un predicado en el estado DON. Al depender de los acontecimientos, los iniciadores pueden, por supuesto, comportarse de forma no determinista. (al igual que, por supuesto, los adaptadores). Un iniciador puede ejecutarse dentro de nodos DON individuales y por lo tanto no es necesario depender de un adaptador. (Consulte el Ejemplo 1 a continuación). Los iniciadores son una característica importante que distingue los ejecutables de los smart contracts. Debido a que un ejecutable puede ejecutarse en respuesta a un iniciador, puede operar efectivamente de forma autónoma, como por supuesto, por extensión, un contrato híbrido que incorpore el ejecutable. Una forma de iniciadores hoy en día son los Chainlink Keepers, que proporcionan transaccionesservicios de automatización, que desencadenan la ejecución de smart contract, como la liquidación de préstamos con garantía insuficiente y la ejecución de operaciones de órdenes limitadas, según informes oracle. Convenientemente, los iniciadores en DONs también pueden verse como una forma de especificar el acuerdos de servicio que se aplican a un ejecutable, ya que definen las circunstancias bajo que el DON debe llamarlo. El siguiente ejemplo ilustra cómo funcionan los iniciadores dentro de un ejecutable: Ejemplo 1 (alimentación de precios activada por desviación). Un smart contract SC puede requerir nueva datos de alimentación de precios (ver Sección 3.6.3) siempre que haya un cambio sustancial, por ejemplo, 1%, en el tipo de cambio entre un par de activos, por ejemplo, ETH-USD. Precio sensible a la volatilidad Los feeds son compatibles con Chainlink hoy, pero es instructivo ver cómo se pueden realizado en un DON mediante un ejecutable execfeed. El ejecutable execfeed mantiene el precio r ETH-USD más reciente en L, en el forma de una secuencia de ⟨NuevoPrecio: j, r⟩entradas, donde j es un índice incrementado con cada actualización de precios. Un iniciador init1 hace que cada nodo Oi monitoree el precio actual de ETH-USD durante desviaciones de al menos el 1% del precio r almacenado más recientemente con índice j. sobre detección de tal desviación, Oi escribe su vista actual ri del nuevo precio en L usando una entrada del formulario ⟨PriceView: i, j + 1, ri⟩. Un segundo iniciador init2 se activa cuando al menos k entradas de PriceView con nuevo precio Los valores para el índice j + 1 creados por distintos nodos se han acumulado en L. Entonces, init2 invoca una lógica de punto de entrada2 para calcular la mediana ρ de los primeros k valores nuevos y válidos de vista de precios y escribe un valor nuevo ⟨NuevoPrecio: j + 1, ρ⟩to L. (Operacionalmente, nodos pueden turnarse como escritores designados.) Un tercer iniciador init3 busca entradas de NewPrice en L. Cada vez que aparece un nuevo informe ⟨NewPrice: j, r⟩ aparece allí, invoca una lógica de punto de entrada3 que empuja (j, r) a SC usando un adaptador. Como hemos señalado, un ejecutable es similar en sus capacidades a un smart contract. Sin embargo, aparte de su mayor rendimiento, se diferencia de un contrato típico de cadena principal. de dos maneras esenciales: 1. Confidencialidad: un ejecutable puede realizar cálculos confidenciales, es decir, un programa secreto puede procesar entradas de texto sin cifrar o un programa publicado puede procesar datos de entrada secretos, o una combinación de ambos. En un modelo simple, los datos secretos pueden ser accedido por DON nodos, que ocultan resultados intermedios y revelan solo valores procesados y desinfectados a MAINCHAIN. También es posible ocultar datos confidenciales de los propios DON: los DON están destinados a respaldar enfoques como como computación multipartita, por ejemplo, [42, 157], y entornos de ejecución confiables (TEE) [84, 133, 152, 229] para este propósito.6 6Por extensión, también es posible mantener los ejecutables en secreto con respecto a los nodos DON. aunque esto sólo es práctico hoy en día para ejecutables no triviales que utilizan TEE.2. Función de soporte: un ejecutable está destinado a admitir smart contracts en un servidor principal. cadena, en lugar de reemplazarlos. Un ejecutable tiene varias limitaciones que un smart contract no: (a) Modelo de confianza: un ejecutable opera dentro del modelo de confianza definido por el DON: Su correcta ejecución depende del comportamiento honesto de O. (Un punto principal cadena puede, sin embargo, proporcionar algunas barreras contra DON malas prácticas, como discutido en la Sección 7.3.) (b) Acceso a activos: un DON puede controlar una cuenta en un blockchain y, por lo tanto, controlar los activos en él a través de un adaptador. Pero un DON no puede tener autoridad representan activos creados en una cadena principal, por ejemplo, Ether o ERC20 tokens, ya que su cadena nativa mantiene el registro autorizado de su propiedad. (c) Ciclo de vida: DONs pueden dejarse de lado intencionalmente con una vida útil limitada, ya que definido por acuerdos de nivel de servicio en cadena entre DONs y los propietarios de contratos de confianza. Las cadenas de bloques, por el contrario, están destinadas a funcionar como sistemas de archivos permanentes. Consulte el Apéndice B.2 para obtener más detalles sobre el cálculo DON. 3.3 Almacenamiento Como sistema basado en comités, un DON puede almacenar cantidades moderadas de datos de forma persistente en L a un costo mucho menor que un blockchain sin permiso. Además, a través de adaptadores, DONs pueden hacer referencia a sistemas descentralizados externos para almacenamiento de datos, por ejemplo, Filecoin [85], y de ese modo puede conectar dichos sistemas a smart contracts. Esta opción es particularmente atractivo para los datos masivos como medio para abordar el problema generalizado de la "inflación" en blockchain sistemas. Por lo tanto, los DONs pueden almacenar datos local o externamente para utilizarlos en sus servicios específicamente admitidos. Un DON también puede hacer uso de dichos datos de forma confidencial, informática sobre datos que: (1) se comparten en secreto entre DON nodos o se cifran bajo una clave administrada por DON nodos de manera adecuada para un cálculo multipartito seguro o cifrado parcial o totalmente homomórfico; o (2) protegido mediante una ejecución confiable ambiente. Esperamos que DONs adopte un modelo simple de administración de memoria común a Sistemas de contrato inteligente: un ejecutable solo puede escribir en su propia memoria. Ejecutables Sin embargo, puede leer de la memoria de otros ejecutables. Consulte el Apéndice B.3 para obtener más detalles sobre el almacenamiento de DON. 3.4 Marco de ejecución de transacciones (TEF) Los DONs están destinados a respaldar contratos en una cadena principal MAINCHAIN (o en múltiples cadenas principales). El Marco de Ejecución de Transacciones (TEF), discutido en detalleen la Sección 6, es un enfoque de propósito general para la ejecución eficiente de un contrato SC en MAINCHAIN y un DON. El TEF está destinado a soportar FSS y capa 2. tecnologías—simultáneamente, si así lo desea. De hecho, es probable que sirva como vehículo principal para el uso de FSS (y por esa razón, no analizamos más FSS en esta sección). Brevemente, en TEF un contrato objetivo original SC diseñado o desarrollado para MAINCHAIN se refactoriza en un contrato híbrido. Esta refactorización produce los dos interoperativos Partes del contrato híbrido: un contrato MAINCHAIN SCa al que nos referimos para mayor claridad. en el contexto de los TEF como contrato ancla y ejecutivos ejecutables en un DON. el El contrato SCa custodia los activos de los usuarios, ejecuta transiciones de estado autorizadas y también proporciona barandillas (consulte la Sección 7.3) contra fallas en el DON. Los ejecutivos ejecutables secuencia transacciones y proporciona datos oracle asociados para ellas. Puede agruparse transacciones para SCa de varias maneras, por ejemplo, utilizando pruebas basadas en validez o rollups optimistas, ejecución confidencial por parte del DON, etc. Esperamos desarrollar herramientas que faciliten a los desarrolladores la partición de un contrato. SC escrito en un lenguaje de alto nivel en piezas de lógica MAINCHAIN y DON, SCa y ejecutivos respectivamente, que componen de forma segura y eficiente. Uso de TEF para integrar esquemas de transacciones de alto rendimiento con sistemas de alto rendimiento oracles es parte integral de nuestro enfoque de escalamiento oracle. 3.5 Servicios de Mempool Una característica importante de la capa de aplicación que pretendemos implementar en DONs como soporte de FSS y TEF son Mempool Services (MS). MS puede verse como un adaptador, pero uno con soporte de primera clase. MS proporciona soporte para el procesamiento de transacciones compatibles con legados. En este uso, MS ingiere del mempool de una cadena principal aquellas transacciones destinadas a un contrato objetivo SC en CADENA PRINCIPAL. Luego, MS pasa estas transacciones a un ejecutable en el DON, donde se procesan de la forma deseada. Los datos de MS pueden ser utilizados por DON para componer transacciones que luego se pueden pasar directamente a SC desde el DON o a otro contrato que llama SC. Por ejemplo, el DON puede reenviar transacciones recolectado a través de MS, o puede usar datos de MS para establecer los precios del gas para las transacciones que envía a CADENA PRINCIPAL. Debido a que monitorea el mempool, MS puede obtener transacciones de los usuarios que interactúan directamente con SC. De esta manera los usuarios podrán continuar generando sus transacciones usando software heredado, es decir, aplicaciones que desconocen la existencia de MS y configuraciones de MS. contratos. (En este caso, se debe cambiar SC para ignorar las transacciones originales y aceptar sólo aquellos procesados por el MS, para evitar el doble procesamiento.) Para su uso con un SC de contrato objetivo, MS puede usarse con FSS y/o TEF.3.6 Pasos a seguir: capacidades Chainlink existentes 3.6.1 Informes fuera de cadena (OCR) Los informes fuera de la cadena (OCR) [60] son un mecanismo en Chainlink para la agregación y transmisión de informes oracle a un SC de contrato de confianza. Implementado recientemente por el precio Chainlink redes de alimentación, representa un primer paso en el camino hacia DONs completos. En esencia, OCR es un protocolo BFT diseñado para funcionar de forma parcialmente sincrónica. red. Garantiza vivacidad y corrección en presencia de f < n/3 arbitrariamente nodos defectuosos, lo que garantiza las propiedades de la transmisión confiable bizantina, pero no es un protocolo de consenso completo BFT. Los nodos no mantienen registros de mensajes que sean consistente en el sentido de representar un libro mayor que es idéntico en todas sus vistas, y el líder del protocolo puede equivocarse sin violar la seguridad. Actualmente, el OCR está diseñado para un tipo de mensaje particular: agregación medianizada de (al menos 2f +1) valores informados por los nodos participantes. Proporciona una garantía clave sobre los informes que genera para SC, llamados informes atestiguados: El valor mediano en un informe atestiguado El informe es igual o se encuentra entre los valores informados por dos nodos honestos. Esta propiedad es la condición clave de seguridad para OCR. El líder puede tener alguna influencia en la mediana. valor en un informe certificado, pero sólo sujeto a esta condición de exactitud. OCR puede extenderse a tipos de mensajes que agregan valores de diferentes maneras. Si bien los objetivos actuales de vida y corrección de la red Chainlink no requieren Para que OCR sea un protocolo de consenso completo, requieren que OCR proporcione algunas formas adicionales de funcionalidad que no están presentes en los protocolos BFT convencionales, en particular: 1. Difusión de informes fuera de cadena de todo o nada: el OCR garantiza que un informe verificado se pone rápidamente a disposición de todos los nodos honestos o de ninguno de ellos. Esto es una justicia propiedad que ayuda a garantizar que los nodos honestos tengan la oportunidad de participar en transmisión de informe certificada. 2. Transmisión confiable: OCR garantiza, incluso en presencia de errores o maliciosos nodos, que todos los informes y mensajes de OCR se transmiten al SC dentro de un cierto, intervalo de tiempo predefinido. Esta es una propiedad de vida. 3. Minimización de la confianza basada en contratos: SC filtra informes generados por OCR potencialmente erróneos, por ejemplo, si sus valores informados se desvían significativamente de otros. los recibidos recientemente. Esta es una forma de aplicación de la corrección extraprotocolo. Estas tres propiedades desempeñarán un papel natural en DONs. La transmisión de todo o nada fuera de la cadena (DON) es un componente importante para las garantías criptoeconómicas en torno a una transmisión confiable, que a su vez es una propiedad esencial del adaptador. confianza La minimización en SC es un tipo de barandilla, como se analiza en la Sección 7.3. OCR también proporciona una base para la implementación operativa y el refinamiento de los protocolos BFT en las redes oracle de Chainlink y, por lo tanto, como se señaló anteriormente, un camino hacia la implementación completa. funcionalidad de DONs.3.6.2 DECO y Pregonero DECO [234] y Town Pregonero [233] son un par de tecnologías relacionadas que actualmente se están desarrollado en redes Chainlink. La mayoría de los servidores web actuales permiten a los usuarios conectarse a través de un canal seguro utilizando un protocolo. llamado Seguridad de la capa de transporte (TLS) [94]. (HTTPS indica una variante de HTTP que está habilitado con TLS, es decir, las URL con el prefijo “https” indican el uso de TLS por motivos de seguridad). Sin embargo, la mayoría de los servidores habilitados para TLS tienen una limitación notable: no firman digitalmente. datos. En consecuencia, un usuario o Prover no puede presentar los datos que recibe de un servidor. a un tercero o Verificador, como oracle o smart contract, de una manera que garantice la autenticidad de los datos. Incluso si un servidor firmara datos digitalmente, seguiría existiendo un problema de confidencialidad. Un Prover puede desear redactar o modificar datos confidenciales antes de presentarlos a un Verificador. Sin embargo, las firmas digitales están diseñadas específicamente para invalidar datos modificados. De este modo impiden que un demostrador realice modificaciones que preserven la confidencialidad. a los datos. (Consulte la Sección 7.1 para obtener más información). DECO y Town Crier están diseñados para permitir que un probador obtenga datos de una red servidor y presentarlo a un Verificador de una manera que garantice su integridad y confidencialidad. Los dos sistemas preservan la integridad en el sentido de que garantizan que los datos presentados por El Prover to the Verifier se origina auténticamente en el servidor de destino. ellos apoyan confidencialidad en el sentido de permitir al Prover redactar o modificar datos (mientras aún preservar la integridad). Una característica clave de ambos sistemas es que no requieren ninguna modificación en un servidor web de destino. Pueden operar con cualquier servidor habilitado para TLS existente. De hecho, son transparentes para el servidor: Desde el punto de vista del servidor, el Probador es estableciendo una conexión ordinaria. Los dos sistemas tienen objetivos similares, pero difieren en sus modelos de confianza e implementaciones, como ahora explicamos brevemente. DECO hace uso fundamental de protocolos criptográficos para lograr su integridad y propiedades de confidencialidad. Mientras establece una sesión con un servidor de destino utilizando DECO, el Prover participa al mismo tiempo en un protocolo interactivo con el Verificador. Este protocolo permite al probador demostrarle al verificador que ha recibido un dato determinado D del servidor durante su sesión actual. El probador puede alternativamente presentar al verificador una prueba de conocimiento cero de alguna propiedad de D y por lo tanto no revelar D directamente. En un uso típico de DECO, un usuario o un solo nodo puede exportar datos D desde un privado sesión con un servidor web a todos los nodos en un DON. Como resultado, el DON completo puede dar fe de la autenticidad de D (o de un hecho derivado de D mediante una prueba de conocimiento cero). Además de las aplicaciones de ejemplo que se dan más adelante en este documento, esta capacidad se puede utilizado para amplificar el acceso de alta integridad a una fuente de datos por parte de un DON. Incluso si solo hay un nodo tiene acceso directo a una fuente de datos, debido, por ejemplo, a un acuerdo exclusivo con un proveedor de datos: sigue siendo posible que todo el DON dé fe de la exactitud deinformes emitidos por ese nodo. Town Crier se basa en el uso de un entorno de ejecución confiable (TEE) como Intel SGX. Brevemente, un TEE funciona como una especie de caja negra que ejecuta aplicaciones en un de forma confidencial y a prueba de manipulaciones. En principio, incluso el propietario del host en el que el TEE en ejecución no puede (de manera indetectable) alterar una aplicación protegida por TEE ni ver el estado de la aplicación, que puede incluir datos secretos. Town Crier puede lograr todas las funciones de DECO y más. DECO obliga al Prover a interactuar con un único Verificador. Por el contrario, Town Crier permite un Prover para generar una prueba verificable públicamente sobre los datos D obtenidos de un servidor de destino, es decir, una prueba que cualquiera, incluso un smart contract, puede verificar directamente. El pregonero puede también ingiere y utiliza secretos de forma segura (por ejemplo, credenciales de usuario). La principal limitación de Town Crier es su dependencia de TEE. Los TEE de producción tienen Recientemente se ha demostrado que tiene una serie de vulnerabilidades graves, aunque la tecnología está en su infancia y sin duda madurará. Consulte los Apéndices B.2.1 y B.2.2 para discusión adicional sobre los TEE. Para ver algunos ejemplos de aplicaciones de DECO y Town Crier, consulte las Secciones 4.3, 4.5. y 9.4.3 y Apéndice C.1. 3.6.3 Servicios existentes en cadena Chainlink Las redes Chainlink oracle proporcionan una serie de servicios principales en una multiplicidad de blockchains y otros sistemas descentralizados en la actualidad. Mayor evolución como se describe en este documento técnico dotará a estos servicios existentes de capacidades adicionales y alcance. Tres ejemplos son: Fuentes de datos: Hoy en día, la mayoría de los usuarios de Chainlink que dependen de smart contracts hacen uso de fuentes de datos. Estos son informes sobre el valor actual de datos clave según a fuentes autorizadas fuera de la cadena. Por ejemplo, los feeds de precios son feeds que informan de los precios. de activos (criptomonedas, materias primas, divisas, índices, acciones, etc.) según intercambios o servicios de agregación de datos. Hoy en día, estos feeds ya ayudan a asegurar miles de millones de dólares en valor en cadena a través de su uso en sistemas DeFi como Aave [147] y Síntesis [208]. Otros ejemplos de fuentes de datos Chainlink incluyen datos meteorológicos para seguro de cultivos paramétrico [75] y datos electorales [93], entre muchos otros. La implementación de DONs y otras tecnologías descritas en este documento mejorará el suministro de fuentes de datos en las redes Chainlink de muchas maneras, incluyendo: • Escalamiento: OCR y posteriormente DONs tienen como objetivo permitir que los servicios Chainlink escale dramáticamente en los muchos blockchains que apoyan. Por ejemplo, esperamos que DONs ayudarán a aumentar la cantidad de fuentes de datos proporcionadas por los nodos que utilizan Chainlink de 100 a 1000 y más. Esta escala ayudará al Chainlink El ecosistema logra su objetivo de proporcionar datos relevantes para smart contracts de manera integral y satisfacer y anticipar las necesidades existentes y futuras.• Seguridad mejorada: al almacenar informes intermedios, DONs conservarán los registros de comportamientos de nodos para monitoreo y medición de alta fidelidad de su desempeño y precisión, lo que permite una sólida base empírica de los sistemas de reputación para Chainlink nodos. FSS y TEF permitirán incorporar feeds de precios con datos de transacciones de manera flexible que eviten ataques como el front-running. (Explícito) staking reforzará la protección criptoeconómica existente de la seguridad de fuentes de datos. • Agilidad de alimentación: como sistemas blockchain independientes (de hecho, en términos más generales, sistemas independientes del consumidor), los DON pueden facilitar el suministro de fuentes de datos a una multiplicidad de sistemas confiados. Un solo DON puede enviar un feed determinado simultáneamente a un conjunto de diferentes blockchains, eliminando la necesidad de redes oracle por cadena y permitiendo una rápida implementación de feeds existentes en nuevos blockchains y de adicionales feeds a través de blockchains actualmente atendidos. • Confidencialidad: la capacidad de realizar cálculos generalizados en un DON permite que los cálculos de datos confidenciales se realicen fuera de la cadena, evitando la cadena. exposición. Además, utilizando DECO o Town Pregonero, es posible lograr confidencialidad aún mayor, lo que permite la generación de informes basados en datos que no son expuesto incluso a DON nodos. Consulte la Sección 4.3 y la Sección 4.5 para ver ejemplos. Funciones aleatorias verificables (VRF): Varios tipos de DApps requieren una fuente de aleatoriedad verificablemente correcta para permitir la verificación de su propio funcionamiento justo. Los tokens no fungibles (NFTs) son un ejemplo. La rareza de las características NFT en Aavegotchi [23] y Axie Infinity [35] está determinada por Chainlink VRF, al igual que la distribución. de NFTs mediante sorteos basados en boletos en Tarjetas Ether [102]; la gran variedad de DApps de juegos cuyos resultados son aleatorios; e instrumentos financieros no convencionales, por ejemplo, juegos de ahorro sin pérdidas como PoolTogether [89], que asignan fondos a ganadores al azar. Otras aplicaciones blockchain y no blockchain también requieren seguridad fuentes de aleatoriedad, incluida la selección de comités del sistema descentralizado y la ejecución de loterías. Si bien el bloque hashes puede servir como una fuente de aleatoriedad impredecible, son vulnerables a la manipulación por parte de mineros adversarios (y hasta cierto punto por parte de los usuarios que envían transacciones). Chainlink VRF [78] ofrece una alternativa considerablemente más segura. un oracle tiene un par de claves pública/privada asociado (sk, pk) cuya clave privada se mantiene fuera de la cadena y cuya clave pública pk se publica. Para generar un valor aleatorio, aplica sk a una semilla x impredecible proporcionada por un contrato de confianza (por ejemplo, un bloque hash y parámetros específicos de DApp) usando una función F, lo que produce y = Fsk(x) junto con un prueba de corrección. (Consulte [180] para conocer el VRF disponible en Chainlink). ¿Qué hace que un VRF verificable es el hecho de que conociendo pk, es posible comprobar la exactitud de la prueba y, por tanto, de y. En consecuencia, el valor y es impredecible para un adversario que no puede predecir x o aprender sk y que el servicio no puede manipular.Chainlink VRF puede verse como solo uno más de una familia de aplicaciones que implican la custodia de claves privadas fuera de la cadena. En términos más generales, los DON pueden ofrecer seguridad y almacenamiento descentralizado de claves individuales para aplicaciones y/o usuarios, y combinar esta capacidad con cálculo generalizado. El resultado es una multitud de aplicaciones, de que damos algunos ejemplos en este documento, incluida la gestión de claves para la Prueba de Reservas (ver Sección 4.1) y para las credenciales descentralizadas de los usuarios (y otras credenciales digitales). activos) (ver Sección 4.3). Guardianes: Chainlink Keepers [87] permiten a los desarrolladores escribir código para aplicaciones descentralizadas ejecución de trabajos fuera de la cadena, generalmente para desencadenar la ejecución de smart contracts confiables. Antes de la llegada de Keepers, era común que los desarrolladores operaran este tipo de operaciones fuera de la cadena. lógicas mismas, creando puntos centralizados de falla (así como un considerable esfuerzo de desarrollo duplicado). En cambio, Keepers proporciona un marco fácil de usar para subcontratación descentralizada de estas operaciones, lo que permite ciclos de desarrollo más cortos y Fuerte garantía de vida y otras propiedades de seguridad. Los guardianes pueden apoyar cualquier de una amplia variedad de objetivos desencadenantes, incluida la liquidación de préstamos dependiente del precio o ejecución de transacciones financieras, inicio de lanzamientos aéreos o pagos en función del tiempo en sistemas con recolección de rendimiento, etc. En el marco DON, los iniciadores pueden verse como una generalización de Keepers en varios sentidos. Los iniciadores pueden hacer uso de adaptadores y, por lo tanto, pueden aprovechar una Biblioteca modularizada de interfaces para sistemas dentro y fuera de la cadena, lo que permite una rápida desarrollo de funcionalidades seguras y sofisticadas. Los iniciadores inician el cálculo en ejecutables, que a su vez ofrecen la versatilidad total de DONs, permitiendo la amplia gama de servicios descentralizados que presentamos en este documento para aplicaciones dentro y fuera de la cadena. 3.6.4 Reputación del nodo/Historial de rendimiento El ecosistema Chainlink existente documenta de forma nativa los historiales de rendimiento de nodos contribuyentes en la cadena. Esta característica ha dado lugar a una colección de recursos orientados a la reputación que absorben, filtran y visualizan datos de rendimiento en individuos. operadores de nodos y fuentes de datos. Los usuarios pueden consultar estos recursos para informarse decisiones en la selección de nodos y para monitorear el funcionamiento de las redes existentes. Capacidades similares ayudarán a los usuarios a elegir DONs. Por ejemplo, los mercados actuales sin permiso, como market.link, permiten nodos operadores para enumerar sus servicios oracle y dar fe de sus identidades fuera de la cadena a través de servicios como Keybase [4], que vinculan el perfil de un nodo en Chainlink a su los nombres de dominio existentes y las cuentas de redes sociales del propietario. Además, el rendimiento herramientas de análisis, como las disponibles en market.link y reputación.link, permiten los usuarios ver estadísticas sobre el rendimiento histórico de nodos individuales, incluido su Latencia promedio de respuesta, la desviación de los valores en sus informes de los valores de consenso. transmitidos en cadena, ingresos generados, empleos cumplidos y más. Estas herramientas de análisis también permitir a los usuarios rastrear la adopción de varias redes oracle por parte de otros usuarios, una forma derespaldo implícito de los nodos que aseguran dichas redes. El resultado es una “red de confianza” en la que, mediante el uso de nodos particulares, las aplicaciones descentralizadas de alto valor crean una señal de su confianza en esos nodos que otros usuarios pueden observar y tener en cuenta en sus propias decisiones de selección de nodos. Con DONs (e inicialmente con OCR) se produce un cambio en el procesamiento de transacciones y actividad contractual más generalmente fuera de la cadena. Un modelo descentralizado para el nodo de grabación. el rendimiento sigue siendo posible dentro del propio DON. De hecho, el alto rendimiento y la capacidad de datos de DONs hacen posible construir registros en un formato detallado manera y también para realizar cálculos descentralizados en estos registros, generando resúmenes confiables que pueden ser consumidos por los servicios de reputación y verificados en CADENA PRINCIPAL. Si bien es posible que, en principio, un DON tergiverse el comportamiento de los nodos constituyentes si una gran fracción de los nodos está corrupta, observamos que el colectivo El rendimiento de un DON en la entrega de datos en cadena es visible en MAINCHAIN y por lo tanto no puede ser tergiversado. Además, planeamos explorar mecanismos que incentivar informes internos precisos sobre el comportamiento de los nodos en un DON. Por ejemplo, al informar el subconjunto de nodos de alto rendimiento que devuelven más rápidamente datos que contribuyen a un informe transmitido en cadena, un DON crea un incentivo para que los nodos contesten errores incorrectos informes: Incluir incorrectamente nodos en este subconjunto significa excluir nodos incorrectamente que deberían haberse incluido y, por tanto, sancionarlos inválidamente. Las fallas repetidas en los informes por parte de un DON también crearían un incentivo para que los nodos honestos abandonen el DON. Compilación descentralizada de historiales de desempeño precisos y el consiguiente capacidad de los usuarios para identificar nodos de alto rendimiento y de los operadores de nodos para construir las reputaciones son características distintivas importantes del ecosistema Chainlink. nosotros mostraremos en la Sección 9 cómo podemos razonar sobre ellos como pieza clave de un análisis riguroso y visión amplia de la seguridad económica proporcionada por DONs.

Servicios descentralizados habilitados por descentralizados

Redes Oracle Para ilustrar la versatilidad de los DONs y cómo permiten una gran cantidad de nuevos servicios, En esta sección presentamos cinco ejemplos de aplicaciones basadas en DON y describimos las contratos híbridos que los realizan: (1) Prueba de Reservas, una forma de servicio entre cadenas; (2) Interconectar con sistemas empresariales/heredados, es decir, crear una interfaz basada en middleware. capa de abstracción que facilita el desarrollo de aplicaciones blockchain con un mínimo blockchain-código o experiencia específica; (3) Identidad descentralizada, herramientas que permiten a los usuarios obtener y gestionar sus propios documentos de identidad y credenciales; (4) Canales prioritarios, un servicio que garantiza la inclusión oportuna de transacciones de infraestructura crítica (por ejemplo, oracle informes) en un blockchain; y (5) DeFi que preserva la confidencialidad, es decir, smart contracts que ocultan los datos sensibles de las partes participantes. aquí nosotros

use SC para indicar la parte MAINCHAIN de un contrato híbrido y describa el DON componente por separado o en términos de un ejecutable exec. 4.1 Prueba de Reservas Para muchas aplicaciones, es útil transmitir el estado entre blockchains. un Una aplicación popular de este tipo de servicios es el empaquetado de criptomonedas. monedas envueltas como como WBTC [15] se están convirtiendo en un activo popular en las finanzas descentralizadas (DeFi). ellos implica depositar el activo de respaldo "envuelto" en su fuente blockchain MAINCHAIN(1) y crear un token correspondiente en un destino diferente blockchain MAINCHAIN(2). Por ejemplo, WBTC es un ERC20 token en el Ethereum blockchain que corresponde a BTC en el Bitcoin blockchain. Debido a que los contratos en MAINCHAIN(2) no tienen visibilidad directa en MAINCHAIN(1), deben confiar explícita o implícitamente en un oracle para informar sobre los depósitos del envuelto activo en un smart contract, produciendo lo que a veces se llama una Prueba de Reservas. en WBTC [15], por ejemplo, el custodio BitGo posee BTC y emite WBTC, con el Red Chainlink que proporciona Pruebas de Reserva [76]. Un DON puede proporcionar por sí mismo una Prueba de reservas. Sin embargo, con un DON es posible para ir más lejos. Un DON puede gestionar secretos y, mediante el uso de adaptadores adecuados, puede realizar transacciones en cualquier blockchain que desee. En consecuencia, es posible que el DON actúe como uno entre varios custodios, o incluso como un custodio único y descentralizado, para un activo envuelto. De este modo, DONs puede servir como plataforma para mejorar la seguridad de servicios existentes que utilizan Pruebas de Reservas. Por ejemplo, supongamos que MAINCHAIN(1) es Bitcoin y MAINCHAIN(2) es Ethereum. En MAINCHAIN(2), un contrato SC emite tokens que representan BTC envueltos. El DON controla una dirección BTC (1) DON. Entonces, para empaquetar BTC, un usuario U envía X BTC desde dirección(1) Ud. a dirección(1) DON junto con una dirección MAINCHAIN(2) (2) Ud. Los monitores DON dirección(1) DON a través de un adaptador a MAINCHAIN(1). Al observar el depósito de U, con una confirmación con una probabilidad suficientemente alta, envía un mensaje a SC a través de un adaptador para CADENA PRINCIPAL(2). Este mensaje indica al SC que acuñe X tokens para addr(2) Ud. Para que U libere X tokens, sucede lo contrario. En CADENA PRINCIPAL (1), sin embargo, dirección(1) DON envía X BTC a la dirección(1) U (o a otra dirección, si así lo solicita el usuario). Estos protocolos se pueden adaptar, por supuesto, para trabajar con intercambios, en lugar de hacerlo directamente. con los usuarios. 4.2 Interfaz con sistemas empresariales/heredados DONs pueden servir como puentes entre blockchains, como en el ejemplo de Prueba de Reservas, pero otro objetivo es que actúen como puentes bidireccionales entre blockchains y sistemas heredados [176] o blockchain sistemas similares, como el banco central monedas digitales [30]. Las empresas enfrentan una serie de desafíos al conectar sus sistemas existentes y procesos a sistemas descentralizados, incluyendo:• Agilidad de Blockchain: los sistemas Blockchain cambian rápidamente. Una empresa puede enfrentar la rápida aparición o el aumento de popularidad de blockchains en los que contrapartes desean realizar transacciones, pero para las cuales la empresa no tiene apoyo en su infraestructura existente. En general, el dinamismo de blockchains hace A las empresas individuales les resulta difícil mantenerse al tanto del ecosistema completo. • Recursos de desarrollo específicos de blockchain: para muchas organizaciones, contratar o incubar experiencia blockchain de vanguardia es difícil, particularmente en vista de la El desafío de la agilidad. • Gestión de claves privadas: la gestión de claves privadas para blockchains o criptomonedas requiere experiencia operativa distinta de la de la ciberseguridad tradicional. prácticas y no están disponibles para muchas empresas. • Confidencialidad: las empresas temen exponer sus datos confidenciales y de propiedad exclusiva. datos en cadena. Para abordar las primeras tres de estas dificultades, los desarrolladores pueden simplemente usar un DON como una capa de middleware segura para permitir que los sistemas empresariales lean o escriban blockchains. El DON puede abstraer consideraciones técnicas detalladas como dinámica del gas, reorganización de la cadena, etc., tanto para desarrolladores como para usuarios. Por Al presentar una interfaz blockchain optimizada para sistemas empresariales, un DON puede así Simplifique considerablemente el desarrollo de aplicaciones empresariales compatibles con blockchain, eliminando la carga de las empresas de adquirir o incubar recursos de desarrollo específicos de blockchain. Este uso de DONs es especialmente atractivo porque permite a los desarrolladores empresariales cree aplicaciones de contratos inteligentes que sean en gran medida blockchain independientes. Como resultado, el Cuanto mayor sea el conjunto de blockchains para los cuales se instrumenta un DON para actuar como middleware, el mayor será el conjunto de blockchains a los que los usuarios empresariales pueden acceder fácilmente. Desarrolladores Puede portar aplicaciones de blockchains existentes a otras nuevas con una modificación mínima. a sus aplicaciones desarrolladas internamente. Para abordar el problema adicional de la confidencialidad, los desarrolladores pueden apelar a la herramientas que presentamos en este documento y que esperamos implementar para respaldar las aplicaciones DON. Estos incluyen la Sección 3.6.2 de DECO y Town Pregonero, así como las disposiciones para preservar la confidencialidad. Las modificaciones de API se analizan en la Sección 7.1.2 y una serie de enfoques específicos de la aplicación se tratan en el resto de esta sección. Estos sistemas DON pueden proporcionar certificaciones en cadena de alta integridad sobre el estado del sistema empresarial sin revelar datos de origen empresarial confidenciales en cadena. 4.3 Identidad descentralizada Identidad descentralizada es un término general para la noción de que los usuarios deberían poder obtener y gestionar sus propias credenciales, en lugar de depender de terceros para hacerlo entonces. Las credenciales descentralizadas son testimonios de atributos o afirmaciones del titular,que a menudo se denominan reclamaciones. Las credenciales están firmadas digitalmente por entidades, a menudo llamadas emisores, que pueden asociar con autoridad reclamaciones con los usuarios. En la mayoría de los esquemas propuestos, Los reclamos están asociados con un Identificador descentralizado (DID), un identificador universal para un usuario determinado. Las credenciales están vinculadas a una clave pública cuya clave privada posee el usuario. De este modo, el usuario puede demostrar la posesión de un crédito utilizando su clave privada. Por muy visionaria que sea la identidad descentralizada, los esquemas existentes y propuestos, por ejemplo, [14, 92, 129, 216], tienen tres limitaciones graves: • Falta de compatibilidad heredada: los sistemas de identidad descentralizados existentes dependen de una comunidad de autoridades, llamadas emisores, para producir credenciales DID. porque Los servicios web existentes generalmente no firman datos digitalmente, se deben lanzar emisores. como sistemas de propósito especial. Porque no hay ningún incentivo para hacer esto sin una ecosistema de identidad descentralizada, se produce el problema del huevo y la gallina. en otros En otras palabras, no está claro cómo poner en marcha un ecosistema de emisores. • Gestión de claves inviable: los sistemas de identidad descentralizados requieren que los usuarios gestionar claves privadas, algo que ha demostrado la experiencia con las criptomonedas una carga inviable. Se estima que unos 4.000.000 Bitcoin han sido perdido para siempre debido a fallas en la administración de claves [194], y muchos usuarios almacenan sus criptoactivos con intercambios [193], socavando así la descentralización. • Falta de resistencia de Sybil para preservar la privacidad: un requisito de seguridad básico de las aplicaciones, como la votación, la asignación justa de tokens durante las ventas de token, etc., es que los usuarios no podrán afirmar múltiples identidades. Las propuestas de identidad descentralizadas existentes requieren que los usuarios revelen sus identidades del mundo real para lograr tal resistencia de Sybil, socavando así importantes garantías de privacidad. Es posible abordar estos problemas utilizando una combinación de un comité de nodos. realizar cálculos distribuidos dentro de un DON y el uso de herramientas como DECO o Pregonero, como se muestra en un sistema llamado CanDID [160]. DECO o Town Crier pueden, por diseño, convertir los servicios web existentes sin modificaciones en emisores de credenciales que preservan la confidencialidad. Permiten que un DON exporte datos relevantes datos para este fin en una credencial y al mismo tiempo oculta datos confidenciales que no deben aparecer en la credencial. Además, para facilitar la recuperación de claves para los usuarios, abordando así la gestión de claves. problema, un DON puede permitir a los usuarios almacenar claves privadas en forma secreta compartida. Los usuarios pueden recuperar sus claves demostrando a los nodos en DON; de manera similar, usando Town Crier o DECO: la capacidad de iniciar sesión en cuentas con un conjunto de proveedores web predeterminados (por ejemplo, Twitter, Google, Facebook). El beneficio de utilizar Town Pregonero o DECO, en lugar de OAUTH, es privacidad del usuario. Esas dos herramientas permiten al usuario evitar revelar al DON un identificador de proveedor web, del cual a menudo se pueden derivar identidades del mundo real. Finalmente, para proporcionar resistencia a Sybil, como se muestra en [160], es posible que un DON realizar una transformación que preserve la privacidad de identificadores únicos del mundo real para los usuarios (por ejemplo, números de seguro social (SSN)) en identificadores en cadena al registrarse el usuario.De este modo, el sistema puede detectar registros duplicados sin datos sensibles como Los SSN se revelan a nodos DON individuales.7 Un DON puede proporcionar cualquiera de estos servicios en nombre de una identidad descentralizada externa. sistemas en blockchains sin permiso o con permiso, por ejemplo, instancias de Hyperledger Indiana [129]. Aplicación de ejemplo: KYC: La identidad descentralizada es prometedora como medio para agilizar los requisitos para aplicaciones financieras en blockchains mientras se mejora el usuario privacidad. Dos desafíos que puede ayudar a abordar son las obligaciones de acreditación y cumplimiento bajo las regulaciones contra el lavado de dinero/conozca a su cliente (AML/KYC). Las regulaciones ALD en muchos países requieren que las instituciones financieras (y otras empresas) establezcan y verifiquen las identidades de las personas y empresas con las que realizan transacciones. KYC forma un componente del sistema de una institución financiera. una política ALD más amplia, que normalmente también implica monitorear el comportamiento de los usuarios y observar los flujos de fondos, entre otras cosas. KYC generalmente implica la presentación por parte del usuario de credenciales de identidad de alguna forma (por ejemplo, entrada en un formulario web en línea, sosteniendo un documento de identidad frente a la cara del usuario en una sesión de vídeo, etc.). Creación y presentación segura de credenciales descentralizadas En principio, podría ser una alternativa beneficiosa en varios aspectos, a saber: (1) Hacer el proceso KYC sea más eficiente para los usuarios y las instituciones financieras, porque una vez Una vez obtenida la credencial, ésta podría presentarse sin problemas ante cualquier institución financiera; (2) Reducir el fraude al reducir las oportunidades de robo de identidad mediante compromisos de información de identificación personal (PII) y suplantación de identidad durante la verificación por video; y (3) Reducir el riesgo de que la PII se vea comprometida en las instituciones financieras, ya que los usuarios retienen el control de sus propios datos. Dadas las sanciones multimillonarias que pagan las instituciones financieras por incumplimiento de las normas ALD y las muchas instituciones financieras que gastan millones de dólares anualmente en KYC, las mejoras podrían generar ahorros considerables para las instituciones financieras. y, por extensión, para los consumidores [196]. Si bien el sector financiero tradicional es lento para adoptar nuevas herramientas de cumplimiento, DeFi los sistemas lo adoptan cada vez más [43]. Aplicación de ejemplo: Préstamos con garantía insuficiente: La mayoría de las aplicaciones DeFi que Los préstamos de apoyo hoy en día sólo originan préstamos totalmente garantizados. Estos son préstamos hechos a los prestatarios que depositan activos en criptomonedas de valor superior al de los préstamos. Recientemente ha surgido interés en lo que la comunidad DeFi generalmente denomina préstamos con garantía insuficiente. Se trata, por el contrario, de préstamos para los cuales la garantía correspondiente tiene un valor inferior al del principal del préstamo. Préstamos con garantía insuficiente Se parecen a los préstamos que suelen otorgar las instituciones financieras tradicionales. En lugar de confiar sobre la garantía depositada como garantía del pago del préstamo, en lugar de ello basan los préstamos decisiones sobre el historial crediticio de los prestatarios. 7Esta transformación se basa en una función pseudoaleatoria distribuida (PRF).Los préstamos con garantía insuficiente constituyen una parte incipiente pero en crecimiento del mercado de préstamos DeFi. Se basan en mecanismos como los empleados por las instituciones financieras tradicionales. instituciones, como contratos legales [91]. Un requisito imprescindible para su crecimiento. será la capacidad de proporcionar datos sobre la solvencia crediticia del usuario, un factor clave en las decisiones crediticias convencionales, a los sistemas DeFi de una manera que proporcione una sólida integridad, es decir, garantía de datos correctos. Un sistema de identidad descentralizado habilitado para DON permitiría a los posibles prestatarios generar credenciales de alta seguridad que acrediten su solvencia y al mismo tiempo preservar la confidencialidad de la información sensible. Específicamente, los prestatarios pueden generar estos credenciales basadas en registros de fuentes autorizadas en línea, al tiempo que se expone solo la datos atestiguados por el DON, sin exponer otros datos potencialmente sensibles. Para Por ejemplo, un prestatario puede generar una credencial que indique que su puntaje crediticio con una conjunto de agencias de crédito excede un umbral particular (por ejemplo, 750), sin revelar su puntuación precisa o cualquier otro dato en sus registros. Además, si lo desea, dichas credenciales se pueden generar de forma anónima, es decir, el nombre del usuario puede ser tratado como dato sensible y no está expuesto a oracle nodos o en su credencial descentralizada. la credencial En sí mismo se puede utilizar en cadena o fuera de cadena, según la aplicación. En resumen, un prestatario puede proporcionar información esencial a los prestamistas sobre su crédito. historias con gran integridad y sin riesgo de exposición de información innecesaria y sensible. datos. Un prestatario también puede proporcionar una variedad de otras credenciales que preservan la confidencialidad. útil para tomar decisiones crediticias. Por ejemplo, las credenciales pueden dar fe de la identidad de un prestatario. posesión de activos (fuera de la cadena), como mostramos en nuestro siguiente ejemplo. Ejemplo de aplicación: Acreditación: Muchas jurisdicciones limitan la clase de inversor a la que se pueden vender valores no registrados. Por ejemplo, en EE.UU., la SEC La Regulación D estipula que para ser acreditado para tales oportunidades de inversión, un El individuo debe poseer un patrimonio neto de 1 millón de dólares, cumplir con ciertos requisitos de ingresos mínimos o tener ciertas calificaciones profesionales [209, 210]. Acreditación actual Los procesos son engorrosos e ineficientes y a menudo requieren una carta de certificación de un contador, o evidencia similar. Un sistema de identidad descentralizado permitiría a los usuarios generar credenciales desde cuentas de servicios financieros en línea existentes que demuestren el cumplimiento de la acreditación regulaciones, facilitando un proceso KYC más eficiente y que preserva la privacidad. el Además, las propiedades de DECO y Town Crier que preservan la privacidad permitirían que estos Las credenciales se generarán con una sólida garantía de integridad sin revelar directamente detalles del estado financiero de un usuario. Por ejemplo, un usuario podría generar una credencial demostrar que tiene un patrimonio neto de al menos $ 1 millón sin revelar ningún dato adicional información sobre su situación financiera. 4.4 Canales Prioritarios Los canales prioritarios son un servicio nuevo y útil que es fácil de crear utilizando DON. Su

El objetivo es entregar transacciones seleccionadas y de alta prioridad de manera oportuna en MAINCHAIN. durante periodos de congestión de la red. Los canales prioritarios pueden verse como una forma de contrato de futuros en espacio de bloques y, por lo tanto, como criptomercancía, término acuñado como parte del Proyecto Chicago [61, 136]. Los canales prioritarios están destinados específicamente a que los mineros habiliten servicios de infraestructura, como oracles, funciones de gobernanza para contratos, etc., no para actividades ordinarias a nivel de usuario, como transacciones financieras. De hecho, tal como se diseñó aquí, una prioridad El canal implementado por menos del 100% del poder minero en la red solo puede Proporcionan límites flexibles en los plazos de entrega, lo que impide su uso para productos que dependen en gran medida de la velocidad. objetivos como correr al frente. Figura 10: Un canal prioritario es una garantía de un minero M o, más generalmente, una conjunto de mineros M: a un usuario U que su transacción τ se extraerá dentro de D bloques de inclusión en el mempool. Un contrato SC puede utilizar el monitoreo DON para hacer cumplir la Condiciones de servicio del canal. Un canal prioritario toma la forma de un acuerdo entre un minero o un conjunto de mineros. (o pools de minería) M que proporciona el canal y un usuario U que paga una tarifa por el acceso. M acepta que cuando U envía una transacción τ al mempool (con cualquier precio del gas,pero un límite de gas previamente acordado), M lo pondrá en cadena dentro de los siguientes bloques D.8 La idea se representa esquemáticamente en la Fig. 10. Descripción del contrato de canal prioritario: Un canal prioritario puede realizarse como un híbrido smart contract aproximadamente de la siguiente manera. Dejamos que SC denote la lógica en MAINCHAIN y eso en el DON por ejecutivo. SC acepta un depósito/participación \(d from M and an advance payment \)p de U. A DON el ejecutable ejecutivo monitorea el mempool y se activa al realizar una transacción por U. Envía un mensaje de éxito a SC si U envía una transacción que M extrae en de manera oportuna y un mensaje de falla en caso de falla del servicio. SC envía el pago $p a M dado un mensaje de éxito y envía todos los fondos restantes, incluyendo $d, a U si recibe un mensaje de error. Tras una terminación exitosa, libera el depósito $d a M. Por supuesto, el minero M puede proporcionar canales prioritarios simultáneamente a múltiples usuarios y puede abrir un canal prioritario con U para una cantidad de mensajes previamente acordada. 4.5 Preservación de la confidencialidad DeFi / Mixicles Hoy en día, las DeFi aplicaciones [1] brindan poca o ninguna confidencialidad a los usuarios: todas las transacciones son visibles en la cadena. Varios enfoques basados en conocimiento cero, por ejemplo, [149, 217], puede proporcionar privacidad en las transacciones, y el TEF es lo suficientemente general como para respaldarlas. pero Estos enfoques no son exhaustivos y, por ejemplo, normalmente no ocultan la activo en el que se basa una transacción. El amplio conjunto de herramientas computacionales que finalmente pretendemos respaldar en DONs Permitir la privacidad de varias maneras diferentes que pueden cerrar esas brechas, ayudando a complementar las garantías de privacidad de otros sistemas. Por ejemplo, Mixicles, un instrumento DeFi que preserva la confidencialidad propuesto por los investigadores de los laboratorios Chainlink [135], puede ocultar el tipo de activo que respalda un instrumento financiero y encaja de forma muy natural en el DON marco. Los mixicles se explican más fácilmente en términos de su uso para realizar un sistema binario simple. opción. Una opción binaria es un instrumento financiero en el que dos usuarios, que veremos consulte aquí para mayor coherencia con [135] como jugadores, apueste en un evento con dos posibles resultados, por ejemplo, si un activo excede o no un precio objetivo en un momento predeterminado. El siguiente ejemplo ilustra la idea. Ejemplo 2. Alice y Bob son partes de una opción binaria basada en el valor de un activo llamado Carol's Bubble Token (CBT). Alice apuesta a que la TCC tendrá un precio de mercado de al menos al menos 250 USD en el momento T = mediodía del 21 de junio de 2025; Bob apuesta lo contrario. cada jugador deposita 100 ETH antes de una fecha límite preestablecida. El jugador con la posición ganadora. recibe 200 ETH (es decir, gana 100 ETH). Por supuesto, 8D debe ser lo suficientemente grande como para garantizar que M pueda cumplir con una alta probabilidad. Para Por ejemplo, si M controla el 20% de la potencia minera en la red, podría elegir D = 100, asegurando una probabilidad de falla de ≈2 × 10−10, es decir, menos de uno entre mil millones.Dada una red O Chainlink oracle existente, es fácil implementar una red inteligente contrato SC que realiza el acuerdo del Ejemplo 2. Cada uno de los dos jugadores deposita 100 ETH en SC. En algún momento después de T, se envía una consulta q a O solicitando el precio r de CBT en el momento T. O envía un informe r de este precio a SC. SC luego envía dinero a Alice si r ≥250 y Bob si no. Este enfoque, sin embargo, revela r en la cadena, lo que facilita para que un observador deduzca el activo subyacente de la opción binaria. En la terminología de Mixicles, es útil pensar conceptualmente en el resultado. de SC en términos de un Switch que transmite un valor binario calculado como predicado interruptor(r). En nuestro ejemplo, switch(r) = 0 si r ≥250; dado este resultado, Alice gana. De lo contrario, switch(r) = 1 y Bob gana. Un DON puede realizar un Mixicle básico como un contrato híbrido ejecutando un ejecutable exec que calcula el switch(r) y lo reporta en cadena al SC. Mostramos esta construcción. en la figura 11. Figura 11: Diagrama de Mixicle básico en el ejemplo 2. Para proporcionar secreto en cadena para informe r, y por lo tanto el activo subyacente de la opción binaria, el oracle envía al contrato SC a través del interruptor solo el interruptor de valor binario (r). Especificamos un adaptador ConfSwitch en el Apéndice C.3 que facilita lograr esto. objetivo en un DON. La idea básica detrás de ConfSwitch es bastante simple. en lugar de informar el valor r, ConfSwitch informa solo el valor del interruptor binario switch(r). SC puede ser diseñado para realizar un pago correcto basándose únicamente en switch(r) y switch(r) por sí solo no revela información sobre el activo subyacente (CBT en nuestro ejemplo). Además, Al colocar un texto cifrado en (q, r) en el libro de contabilidad cifrado bajo pkaud, la clave pública de Como auditor, el adaptador ConfSwitch crea un registro de auditoría que preserva la confidencialidad. El Mixicle básico que hemos elegido para describir aquí por simplicidad oculta sólo el activo y apuesta detrás de la opción binaria en nuestro ejemplo. Una lata Mixicle [135] en toda regla Proporcionar dos formas de confidencialidad. Oculta a los observadores: (1) ¿Qué evento ocurrió? Los jugadores apuestan a (es decir, q y r), pero también (2) qué jugador ganó la apuesta. Dado que los Mixicles se ejecutan en MAINCHAIN, cualquiera de los jugadores necesitaría transmitir cambie(r) de DON a MAINCHAIN, o se podría crear un ejecutable que

se activa en la salida de ConfSwitch y llama a otro adaptador para enviar el interruptor (r) a CADENA PRINCIPAL. También vale la pena considerar un tercer tipo sutil de confidencialidad. En una implementación básica de ConfSwitch, O ejecuta el adaptador en el DON y, por lo tanto, aprende el activo (CBT en nuestro ejemplo) y, por tanto, la naturaleza de la opción binaria. Como se discutió Sin embargo, en el Apéndice C.3 también es posible utilizar DECO o Town Crier para ocultar incluso esta información de O. En este caso, el O no aprende más información que un observador público de SC. Para obtener más detalles sobre Mixicles, remitimos a los lectores a [135].

Servicios de secuenciación justa

Un servicio importante que esperamos que ofrezcan los DON y que aproveche sus capacidades de red, computación y almacenamiento se llama Fair Sequencing Services (FSS). Aunque FSS puede verse simplemente como una aplicación realizada dentro del marco DON, lo destacamos como un servicio que creemos tendrá una gran demanda en todo el mundo. blockchains, y que esperamos que la red Chainlink apoye activamente. Cuando se ejecuta en redes públicas blockchain, muchas de las aplicaciones DeFi actuales revelar información que los usuarios pueden explotar en su propio beneficio, de forma análoga a el tipo de filtraciones internas y oportunidades de manipulación que son omnipresentes en los mercados existentes. mercados [64, 155]. En cambio, FSS allana el camino hacia un ecosistema DeFi justo. FSS ayuda a los desarrolladores a crear DeFi contratos que estén protegidos contra la manipulación del mercado resultante de la fuga de información. Dados los problemas que destacamos a continuación, FSS es especialmente atractivo para servicios de capa 2 y encaja dentro del marco para dichos servicios que analizamos en la Sección 6. El desafío: En los sistemas sin permiso existentes, las transacciones se ordenan completamente a discreción de los mineros. En redes autorizadas, los nodos validator pueden ejercer el mismo poder. Esta es una forma de centralización efímera en gran medida no reconocida en sistemas que de otro modo estarían descentralizados. Un minero puede censurar (temporalmente) transacciones para su propio beneficio [171] o reordenarlos para maximizar su propia ganancia, una noción llamada valor extraíble minero (MEV) [90]. El término MEV es ligeramente engañoso: no se refiere solo para valorar lo que los mineros pueden capturar: algunos MEV pueden ser capturados por usuarios comunes. Sin embargo, debido a que los mineros tienen más poder que los usuarios comunes, MEV representa un límite superior en la cantidad de valor que cualquier entidad puede obtener a través de una reordenación adversa. e inserción de transacciones complementarias. Incluso cuando los mineros ordenan transacciones simplemente basado en tarifas (gas), sin manipulación, los propios usuarios pueden manipular los precios del gas para favorecer sus transacciones sobre aquellas de menos sofisticación. Daian et al. [90] documenta y cuantifica las formas en que los bots (no los mineros) toman ventaja de la dinámica del gas de una manera que perjudica a los usuarios de los sistemas DeFi actuales y cómo MEV incluso amenaza la estabilidad de la capa de consenso subyacente en un blockchain. Otros ejemplos de manipulación de órdenes de transacción surgen regularmente, por ejemplo, [50, 154].Los nuevos métodos de procesamiento de transacciones como rollups son un enfoque muy prometedor a los problemas de escala de los blockchains de alto rendimiento. Sin embargo, no abordan El problema del MEV. En lugar de ello, lo transfieren a la entidad que genera el rollup. eso entidad, ya sea el operador de un smart contract o un usuario que proporciona un (zk-)rollup con una prueba de validez, tiene la facultad de ordenar e insertar transacciones. En otras palabras, rollups intercambie MEV por REV: valor acumulable-extraíble. MEV afecta las próximas transacciones que se han enviado al mempool pero aún no están comprometidos en cadena. La información sobre dichas transacciones es ampliamente disponible en la red. Los mineros, validators y los participantes comunes de la red pueden por lo tanto, explotar este conocimiento y crear transacciones dependientes. Además, los mineros y validators pueden influir en el orden de las transacciones que realizan. ellos mismos y explotar esto en su beneficio. El problema de la influencia indebida de los líderes en la ordenación de transacciones por consenso Los protocolos se conocen en la literatura desde la década de 1990 [71, 190], pero no Hasta ahora se han implementado soluciones en la práctica [97]. La razón principal es que las soluciones propuestas (al menos hasta hace muy poco) no pueden integrarse fácilmente con las políticas públicas. blockchains, ya que dependen de que el contenido de las transacciones permanezca secreto hasta después su orden ha sido determinado. Descripción general de los servicios de secuenciación justa (FSS): DONs proporcionará herramientas para descentralizar el pedido de transacciones e implementarlo de acuerdo con una política especificada por un proveedor de confianza. creador del contrato, idealmente uno que sea justo y que no beneficie a los actores que deseen manipular el orden de las transacciones. En conjunto, estas herramientas constituyen FSS. FSS incluye tres componentes. El primero es el seguimiento de las transacciones. En SFS, oracle nodos en O monitorean el mempool de MAINCHAIN y (si lo desea) permiten Envío fuera de la cadena de transacciones a través de un canal especializado. El segundo es la secuenciación de las transacciones. Los nodos en O ordenan transacciones para un contrato de confianza. de acuerdo con una política definida para ese contrato. El tercero es la publicación de transacciones. Después de ordenar las transacciones, los nodos en O envían conjuntamente las transacciones al cadena principal. Los beneficios potenciales de FSS incluyen: • Equidad en los pedidos: FSS incluye herramientas para ayudar a los desarrolladores a garantizar que las transacciones Los insumos a un contrato en particular se ordenan de manera que no proporcionen una relación injusta. ventaja para los usuarios con buenos recursos y/o con conocimientos técnicos. Políticas de pedidos se puede especificar para este propósito. • Reducción o eliminación de fugas de información: al garantizar que los participantes de la red no puedan explotar el conocimiento sobre las próximas transacciones, FSS puede reducir o eliminar ataques como el front-running que se basan en la información disponible en la red antes de que se confirmen las transacciones. Prevenir la explotación de tales La fuga garantiza que las transacciones contradictorias que dependen de los pendientes originales las transacciones no pueden ingresar al libro mayor antes de que se confirmen las transacciones originales.• Costo de transacción reducido: al eliminar la necesidad de los jugadores de acelerar el envío sus transacciones a un smart contract, FSS puede reducir en gran medida el costo del procesamiento de transacciones. • Orden de prioridad: FSS puede dar automáticamente prioridad especial a las transacciones críticas ordenar. Por ejemplo, para evitar ataques frontales contra oracle informes, por ejemplo, [79], FSS puede insertar un informe oracle en un flujo de transacciones retroactivamente. Un objetivo general del FSS en DONs es capacitar a los creadores de DeFi para que realicen actividades justas. Sistemas financieros, es decir, sistemas que no benefician a usuarios particulares (o mineros). sobre otros sobre la base de la velocidad, el conocimiento interno o la capacidad para realizar tareas técnicas. manipulación. Si bien es difícil alcanzar una noción clara y general de justicia, y la justicia perfecta en cualquier sentido razonable es inalcanzable, FSS tiene como objetivo proporcionar a los desarrolladores una poderosa conjunto de herramientas para que puedan aplicar políticas que ayuden a cumplir sus objetivos de diseño para DeFi. Observamos que si bien el objetivo principal de FSS es actuar como un servicio de secuenciación justo para la CADENA PRINCIPAL a la que se dirige DON, algunos de los mismos deseos de equidad que FSS Las garantías también pueden ser apropiadas para protocolos (descentralizados) que se ejecutan entre DON fiestas. Por tanto, el SFS puede verse de manera más amplia como un servicio proporcionado por un subconjunto de DON nodos para secuenciar de manera justa no solo las transacciones enviadas por los usuarios de MAINCHAIN pero también transacciones (es decir, mensajes) compartidas entre otros DON nodos. En esta sección, Nos centraremos principalmente en el objetivo de secuenciar las transacciones de CADENA PRINCIPAL. Organización de la sección: en la Sección 5.1, describimos dos aplicaciones de alto nivel que motivan el diseño de FSS: evitar la ejecución frontal de informes oracle y evitar ejecución anticipada de las transacciones de los usuarios. Luego proporcionamos más detalles sobre el diseño de FSS. en la Sección 5.2. La sección 5.3 describe ejemplos de garantías y medios de ordenamiento justo. para lograrlos. Finalmente, la Sección 5.4 y la Sección 5.5 analizan las amenazas a nivel de red a tales políticas y medios para abordarlas, respectivamente, para la inundación de la red y Sybil ataques. 5.1 El problema de la vanguardia Para explicar los objetivos y el diseño de FSS, describimos dos formas generales de ejecución anticipada. ataques y las limitaciones de las soluciones existentes. Ir al frente ejemplifica una clase de ataques de orden de transacciones: Hay una serie de ataques relacionados, como backrunning y sándwiching (front-running más back-running) [237] que no cubrimos aquí, pero que FSS también ayuda a abordar. 5.1.1 Ejecución frontal de Oracle En su función tradicional de proporcionar datos fuera de la cadena a aplicaciones blockchain, oracles convertirse en un objetivo natural para los ataques frontales.Considere el patrón de diseño común de usar un oracle para suministrar varios precios a un intercambio en cadena: periódicamente (digamos cada hora), el oracle recopila datos de precios para diferentes activos y los envía a un contrato de intercambio. Estas transacciones de datos de precios presentan oportunidades obvias de arbitraje: por ejemplo, si el informe más reciente oracle enumera un precio mucho más alto por algún activo, un adversario podría adelantar el informe oracle para comprar activos y revenderlos inmediatamente una vez que se procese el informe de oracle. Topes de velocidad y precios retroactivos: Una solución natural al problema de ejecución anticipada de oracle es dar a los informes oracle una prioridad especial sobre otras transacciones. Para Por ejemplo, se podrían enviar informes oracle con tarifas elevadas para animar a los mineros a procesar ellos primero. Pero esto no impedirá que se avance si las oportunidades de arbitraje son altas, ni puede impedir el arbitraje por parte de los propios mineros. Por lo tanto, algunos intercambios han recurrido a implementar "reductores de velocidad" más pesados, como poner en cola las transacciones de los usuarios durante varios bloques antes de procesarlas. ellos, o ajustar los precios retroactivamente cuando llegue un nuevo informe oracle. Las desventajas de estas soluciones son que añaden complejidad a la implementación del intercambio, aumentan los requisitos de almacenamiento y, por tanto, los costos de transacción, y alteran la experiencia del usuario, ya que los intercambios de activos sólo se confirman después de un período de tiempo significativo. Llevando a cuestas: Antes de pasar a FSS, analizaremos el transporte a cuestas, una solución bastante simple y solución elegante al oracle problema de ejecución frontal. No es aplicable a la dirección Sin embargo, está a la cabeza en otros escenarios. En resumen, en lugar de enviar informes periódicamente al contrato en cadena, oracles publicar informes firmados que los usuarios adjuntan a sus transacciones al comprar o vender activos en cadena. Luego, el intercambio simplemente verifica que el informe sea válido y esté actualizado. (por ejemplo, oracle puede firmar una variedad de bloques para los cuales el informe es válido) y extrae el precio relevante se alimenta de él. Este enfoque simple tiene una serie de ventajas sobre el "bajón de velocidad" anterior. enfoque: (1) El contrato de intercambio no necesita mantener el estado de los precios, lo que debería conducir a menores costos de transacción; (2) Como los informes oracle se publican en cadena según sea necesario, los oracle pueden generar actualizaciones más frecuentes (por ejemplo, cada minuto), lo que minimizar las oportunidades de arbitraje al adelantar un informe9; (3) Las transacciones pueden validarse inmediatamente, ya que siempre incluyen un feed de precios actualizado. Sin embargo, el enfoque no es perfecto. En primer lugar, esta solución de aprovechamiento pone al responsabilidad de los usuarios del intercambio de obtener informes oracle actualizados y adjuntarlos a sus transacciones. En segundo lugar, si bien llevar a cuestas minimiza las oportunidades de arbitraje, no puede prevenirlos por completo sin afectar la vida del contrato en cadena. De hecho, si un El informe oracle es válido hasta algún bloque número n, luego se envía una transacción al bloque n + 1 requeriría un nuevo informe válido. Debido a retrasos inherentes en la propagación de informes de oracles a los usuarios, el nuevo informe que es válido para el bloque n + 1 tendría 9El arbitraje sólo vale la pena si la diferencia explotable en los precios de los activos excede la diferencia superflua. tarifas requeridas para comprar y vender los activos, por ejemplo, los cobrados por los mineros y el intercambio.ser publicitado algún período antes de que se extraiga el bloque n + 1, digamos en el bloque n −k, por lo tanto creando una secuencia de k bloques donde existe una oportunidad de arbitraje de corta duración. nosotros Ahora describa cómo FSS sortea estas limitaciones. Priorizar informes oracle con FSS: FSS puede abordar el oracle de ejecución frontal problema basándose en la solución anterior, pero impulsando la solución adicional trabajo de aumentar las transacciones con oracle informes a la Red Oracle Descentralizada. En un nivel alto, los oracle nodos recopilan transacciones destinadas a un intercambio en cadena, acuerde un feed de precios en tiempo real y publique el feed de precios junto con las transacciones recopiladas en el contrato de la cadena principal. Conceptualmente, se puede pensar en este enfoque como una "procesamiento por lotes de transacciones con datos aumentados", donde oracle garantiza que una información actualizada El feed de precios siempre se agrega a las transacciones. Las soluciones FSS se pueden implementar de forma transparente para los usuarios del intercambio y con cambios mínimos en la lógica del contrato, como describimos con más detalle en la Sección 5.2. asegurando que los informes oracle nuevos siempre tengan prioridad sobre las transacciones de los usuarios es solo un ejemplo de una política de pedidos que FSS pueda adoptar y hacer cumplir. Políticas de FSS para garantizar el orden. equidad se describen de manera más general en la Sección 5.3. 5.1.2 Transacciones de usuario de primera ejecución Ahora pasamos a ejecutar aplicaciones genéricas, donde el método de defensa anterior no funciona. El problema se puede captar en términos generales mediante el siguiente escenario: Un adversario ve alguna transacción de usuario tx1 enviada a la red P2P y la inyecta su propia transacción adversaria tx2, de modo que tx2 se procese antes que tx1 (por ejemplo, pagando una tarifa de transacción más alta). Por ejemplo, este tipo de adelantamiento es común entre bots que explotan oportunidades de arbitraje en DeFi sistemas [90] y ha afectado a los usuarios de varias aplicaciones descentralizadas [101]. Imponer un orden justo entre las transacciones. procesado en el blockchain soluciona este problema. Más fundamentalmente, ver los detalles de tx1 a veces ni siquiera es necesario y El conocimiento de su mera existencia puede permitir a un adversario adelantar a tx1 a través de su poseer tx2 y defraudar al usuario inocente que creó tx1. Por ejemplo, el usuario podría ser conocido por negociar un activo particular en momentos regulares. Prevenir este tipo de ataques requiere mitigaciones que también evitan la fuga de metadatos [62]. Algunas soluciones para este problema. existen, pero introducen retrasos y problemas de usabilidad. Del pedido de red al pedido finalizado con FSS: Oportunidades para liderar surgen porque los sistemas existentes no tienen mecanismos para garantizar que el orden en el que Las transacciones que aparecen en la cadena respetan el orden de los eventos y el flujo de información. fuera de la red. Esto representa un problema que surge de deficiencias en la implementación de aplicaciones (por ejemplo, plataformas comerciales) en un blockchain. Lo ideal sería asegúrese de que las transacciones se confirmen en el blockchain en el mismo orden en que fueron creado y enviado a la red P2P de blockchain. Pero desde la red blockchain

se distribuye, no se puede capturar tal orden. Por lo tanto, FSS introduce mecanismos para salvaguardar contra violaciones de la equidad, que surgen sólo debido a la distribución naturaleza de la red blockchain. 5.2 Detalles del FSS Figura 12: Mempool de orden justa con dos rutas de transacción diferentes: directo y basado en mempool. La Fig. 12 muestra un esquema general del FSS. Para garantizar la equidad, el DON que proporciona el FSS debe interferir con el flujo de transacciones cuando ingresan a MAINCHAIN. Es posible que sean necesarios ajustes a los clientes, a smart contracts en MAINCHAIN ​​o a ambos. En un nivel alto, el procesamiento de transacciones por parte del FSS se puede descomponer en tres fases, que se describen a continuación: (1) Monitoreo de transacciones; (2) Secuenciación de transacciones; y (3) Contabilización de transacciones. Dependiendo del método de pedido utilizado para la secuenciación de transacciones, se necesitan pasos de protocolo adicionales, como se describe en la siguiente sección. 5.2.1 Procesamiento de transacciones Monitoreo de transacciones: Visualizamos dos enfoques diferentes para que FSS monitoree Transacciones de usuario destinadas a un smart contract específico, directas y basadas en mempool: • Directo: el enfoque directo es conceptualmente el más simple, pero requiere cambios en clientes usuarios para que las transacciones se envíen directamente al Oracle DescentralizadoNodos de la red, en lugar de a los nodos de la cadena principal. El DON recoge transacciones de usuario destinadas a un smart contract SC específico y las ordena en función sobre alguna política de pedidos. El DON luego envía las transacciones ordenadas al smart contract en la cadena principal. Algunos mecanismos de pedido también requieren el enfoque directo porque el usuario que crea una transacción debe criptográficamente protéjalo antes de enviarlo a FSS. • Basado en Mempool: para facilitar la integración de FSS con clientes heredados, el DON puede utilizar Mempool Services (MS) para monitorear el mempool de la cadena principal y recopilar transacciones. Es probable que la transmisión directa sea la implementación preferida para muchos contratos, y creemos que debería ser bastante práctico en muchos casos. Discutimos brevemente cómo las DApps existentes podrían modificarse mínimamente para admitir transmisión directa preservando una buena experiencia de usuario. Describimos enfoques usando Ethereum y MetaMask [6] ya que estas son las opciones más populares hoy en día, pero Las técnicas mencionadas deberían extenderse a otras cadenas y billeteras. Un Ethereum reciente Propuesta de mejora, “EIP-3085: Monedero agrega Ethereum método RPC de cadena” [100], facilitará la orientación de cadenas Ethereum personalizadas (utilizando un ID de CADENA diferente al el de MAINCHAIN para evitar ataques de repetición) de MetaMask y otras billeteras basadas en navegador. Después de la implementación de esta propuesta, una DApp que busca utilizar un DON simplemente agregaría una llamada de método único a su interfaz para poder transmitir directamente transacciones a cualquier DON que exponga una API compatible con Ethereum. Mientras tanto, “EIP-712: Ethereum datos estructurados escritos hashing y firma” [49] proporciona una explicación ligeramente alternativa más complicada pero ya ampliamente implementada, donde un usuario de DApp puede usar MetaMask para firmar datos estructurados especificando una transacción DON. La DApp puede enviar Estos datos estructurados firmados al DON. Por último, observamos que también son posibles enfoques híbridos. Por ejemplo, legado los clientes pueden continuar enviando transacciones al mempool de la cadena principal, pero es crítico Las transacciones (por ejemplo, informes oracle) se envían a los nodos DON directamente (en particular, el conjunto de nodos que proporcionan oracle informes, como actualizaciones de precios y el conjunto de nodos proporcionar FSS puede superponerse o ser idéntico). Secuenciación de transacciones: El objetivo principal de FSS es garantizar que las transacciones de los usuarios se ordenen de acuerdo con una política predefinida. La naturaleza de esta política dependen de las necesidades de la aplicación y de los tipos de órdenes de transacciones injustas que pretende prevenir. Dado que FSS en el DON es capaz de procesar datos y mantener el estado local, pueden imponer una política de secuenciación arbitraria basada en la información que se disponible en el oracles. Las políticas de pedidos particulares y su implementación se analizan posteriormente en la Sección 5.3.Publicación de transacciones: Después de recopilar y ordenar las transacciones de los usuarios, recibidas directamente de los usuarios o recopiladas del mempool, DON envía estas transacciones a la cadena principal. Como tal, las interacciones de DON con la cadena principal permanecen sujeto a órdenes de transacciones (potencialmente injustas) regidas por los mineros de la cadena principal. Para aprovechar los beneficios de los pedidos de transacciones descentralizados, el objetivo inteligente Por lo tanto, el contrato SC debe diseñarse para tratar al DON como un ciudadano de “primera clase”. nosotros distinguir dos enfoques: • Contratos solo DON: la opción de diseño más simple es tener la cadena principal inteligente El contrato SC solo acepta transacciones que hayan sido procesadas por el DON. esto garantiza que smart contract procese las transacciones en el orden propuesto por el DON, pero de facto restringe el smart contract a operar en un sistema basado en comités (es decir, el comité DON ahora tiene poder continuo para determinar el ordenación e inclusión de transacciones). • Contratos de clase dual: un diseño preferido y más granular tiene la cadena principal inteligente contrato SC acepta transacciones originadas tanto del DON como del legado usuarios,10 pero coloca “obstáculos” tradicionales en las transacciones que no fueron procesadas por el DON. Por ejemplo, las transacciones del DON pueden procesarse inmediatamente, mientras que las transacciones heredadas quedan "almacenadas" por el smart contract para un periodo de tiempo fijo. Otros mecanismos estándar para evitar el avance como esquemas de confirmación-revelación o VDF [53] también podrían aplicarse a legados transacciones. Esto garantiza que las transacciones ordenadas DON se procesen en la orden acordada, sin otorgar al DON el poder no deseado de censurar transacciones. Como la imposición de pedidos de transacciones por parte de FSS requiere que las transacciones se agreguen "fuera de la cadena", esta solución se combina naturalmente con otras técnicas de agregación que apuntan a reducir los costos de procesamiento en la cadena. Por ejemplo, después de recolectar y ordenar transacciones, el DON puede enviar estas transacciones a la cadena principal como "transacción por lotes" única (por ejemplo, una rollup), reduciendo así la transacción agregada tarifa. Hacer cumplir el orden de transacción: Ya sea en un diseño de clase dual o solo DON, la cadena principal smart contract SC y DON deben diseñarse conjuntamente para garantizar que se mantenga el orden de transacciones de DON. Aquí también imaginamos diferentes opciones de diseño: • Números de secuencia: DON puede agregar un número de secuencia a cada transacción y enviar estas transacciones al mempool de la cadena principal. el principal 10Si el monitoreo de transacciones de DON se basa en el mempool, las transacciones heredadas deben distinguirse de las transacciones de DON para que no sean recopiladas por DON, por ejemplo, a través de una etiqueta especial. incorporado en la transacción o especificando un precio de gas particular, p.e. DON las transacciones tienen gas precios por debajo de un determinado umbral.cadena smart contract SC ignora las transacciones que llegan "fuera de secuencia". nosotros tenga en cuenta que en esta configuración, los mineros de la cadena principal pueden decidir ignorar los DON ordenación de transacciones, provocando así que las transacciones fallen. Es posible mantener el estado (caro) para que SC aplique el orden correcto de las transacciones, de alguna manera De manera análoga a cómo TCP almacena en búfer los paquetes desordenados hasta que se recuperan los paquetes faltantes. recibido. • Transacción nonces: Para muchas blockchains, y en particular para Ethereum, la El enfoque de numeración secuencial anterior puede aprovechar la transacción integrada nonces para hacer cumplir que la cadena principal smart contract SC procese las transacciones en secuencia. Aquí, los nodos DON envían transacciones a la cadena principal a través de una única cuenta de cadena principal, protegida con una clave compartida entre los nodos DON. la cuenta La transacción nonce garantiza que las transacciones se extraigan y procesen en el orden correcto. • Transacciones agregadas: el DON puede agregar múltiples transacciones en un rollup (o en un paquete similar a rollup). La cadena principal smart contract debe ser diseñado para manejar tales transacciones agregadas. • Transacciones agregadas con un proxy de la cadena principal: aquí, el DON agrupa de manera similar las transacciones en una “metatransacción” para la cadena principal, pero se basa en un proxy personalizado smart contract para descomprimir las transacciones y transmitirlas al contrato objetivo SC. Esta técnica puede resultar útil para la compatibilidad heredada. Las metatransacciones actúan como rollups pero se diferencian en que consisten en un lista de transacciones publicadas una vez en la cadena principal. El último diseño tiene la ventaja de soportar sin problemas las transacciones de los usuarios que ellos mismos están representados a través de un contrato de cadena principal antes de alcanzar el objetivo de DON contrato SC. Por ejemplo, considere un usuario que envía una transacción a alguna billetera. contrato, que a su vez envía una transacción interna a SC. Asignar una secuencia número para tal transacción sería complicado, a menos que el contrato de billetera del usuario sea especialmente diseñado para reenviar el número de secuencia con cada transacción interna a SC. De manera similar, dichas transacciones internas no se pueden agregar fácilmente en una metatransacción que se envíe directamente a SC. Discutimos otras consideraciones de diseño para dichas transacciones representadas a continuación. 5.2.2 Atomicidad de las transacciones Hasta ahora nuestra discusión ha asumido implícitamente que las transacciones interactúan con un solo en cadena smart contract (por ejemplo, un usuario envía una solicitud de compra a un intercambio). Sin embargo, en En sistemas como Ethereum, una sola transacción puede constar de múltiples transacciones internas, por ejemplo, una smart contract que llama a una función en otro contrato. A continuación, nosotros describir dos estrategias de alto nivel para secuenciar transacciones de "contratos múltiples", mientras preservar la atomicidad de la transacción (es decir, la secuencia de acciones prescritas por las transacciones se ejecutan todas en el orden correcto, o no se ejecutan en absoluto).Fuerte atomicidad: La solución más sencilla es aplicar FSS, como se describe anteriormente, directamente a transacciones completas de "contratos múltiples". Es decir, los usuarios envían sus transacciones en la red y FSS monitorea, secuencia y publica estas transacciones en el cadena principal. Este enfoque es técnicamente simple, pero tiene una limitación potencial: si un usuario La transacción interactúa con dos contratos SC1 y SC2 que ambos quieren aprovechar la equidad. servicios de secuenciación, entonces la política de secuenciación de estos dos contratos debe ser coherente. Es decir, dadas dos transacciones diferentes tx1 y tx2 con las que cada una interactúa tanto SC1 como SC2, no debe darse el caso de que la política de SC1 ordene tx1 antes que tx2 mientras que la política de SC2 prescribe el orden opuesto. Para la gran mayoría de escenarios de interés, prevemos que las políticas de secuenciación adoptadas por diferentes contratos serán consistentes. Por ejemplo, tanto SC1 como SC2 es posible que desee que las transacciones se ordenen según su hora aproximada de llegada al mempool, y SC1 puede además querer que ciertos informes oracle se entreguen siempre primero. como el Las últimas transacciones de informes oracle no interactúan con SC2, las políticas son consistentes. Atomicidad débil: En toda su generalidad, FSS podría aplicarse a nivel de individuo transacciones internas. Considere transacciones de la forma tx = { ˜txpre, ˜txSC, ˜txpost}, que consisten en algunos transacción(es) ˜txpre, lo que resulta en una transacción interna ˜txSC a SC, que a su vez emite transacciones internas ˜txpost. La política de secuenciación de SC podría determinar cómo la transacción interna ˜txSC debe ordenarse con respecto a otras transacciones enviadas a SC, pero deja abierto el orden de secuenciación para ˜txpre y ˜txpost. Dadas las características intrínsecas del procesamiento de transacciones en sistemas como Ethereum, desarrollar un servicio de secuenciación dirigido a transacciones internas específicas no es sencillo. Con un contrato SC especialmente diseñado, esto puede realizarse de la siguiente manera: 1. La transacción tx se envía a la red y se extrae (sin ninguna secuenciación). realizado por FSS). El ˜txpre inicial se ejecuta y llama a ˜txSC. 2. SC no ejecuta ˜txSC y regresa. 3. FSS monitorea las transacciones internas a SC, las secuencia y las publica a SC (es decir, enviando transacciones ˜txSC directamente a SC). 4. SC procesa las transacciones ˜txSC recibidas del FSS y emite transacciones internas ˜txpost que resultan de ˜txSC. Con este enfoque, las transacciones no se ejecutan de forma totalmente atómica (es decir, el original la transacción tx se divide en múltiples transacciones en cadena), pero el orden de Se conservan las transacciones internas. Esta solución implica una serie de limitaciones de diseño. Por ejemplo, ˜txpre no puede supongamos que se ejecutarán ˜txSC y ˜txpost. Además, el SC debe diseñarse de manera que ejecutar transacciones ˜txSC y ˜txpost en nombre de un determinado usuario, aunque fueranenviado por FSS. Por estas razones, la solución más generalizada de “Atomicidad fuerte” Lo anterior probablemente sea preferible en la práctica. Para respetar dependencias más complejas, que involucran múltiples transacciones y sus respectivas transacciones internas, el programador de transacciones de FSS puede contener Funciones elaboradas que se asemejan a las que se encuentran en los administradores de transacciones de los sistemas relacionales. gestores de bases de datos. 5.3 Secuenciación justa de transacciones Aquí analizamos dos nociones de equidad para la secuenciación de transacciones y las implementaciones correspondientes, que pueden ser realizadas por FSS: equidad de orden basada en una política impuesto por FSS y preservación segura de la causalidad, lo que requiere métodos criptográficos adicionales en FSS. Orden-justicia: La equidad del orden es una noción de equidad temporal en los protocolos de consenso que fue introducido formalmente por primera vez por Kelkar et al. [144]. Kelkar et al. objetivo lograr una forma de política natural en la que las transacciones sean ordenados en función del momento en que fueron recibidos por primera vez por DON (o la red P2P, en el caso de un FSS basado en mempool). Sin embargo, en un sistema descentralizado, diferentes Los nodos pueden ver que las transacciones llegan en un orden diferente. Establecer un orden total en todas las transacciones es el problema resuelto por el protocolo de consenso subyacente CADENA PRINCIPAL. Kelkar et al. [144] por lo tanto introduce una noción más débil que puede ser logrado con la ayuda de una red Oracle descentralizada, llamada "equidad de orden de bloque". Agrupa las transacciones que el DON ha recibido durante un intervalo de tiempo en un “bloque” e inserta todas las transacciones del bloque simultáneamente y en la misma posición (es decir, altura) en CADENA PRINCIPAL. Por lo tanto, están ordenados juntos y deben ser ejecutables. en paralelo, sin crear conflictos entre ellos. En términos generales, orderfairness establece que si una gran fracción de nodos ve la transacción τ1 antes de τ2, entonces τ1 se secuenciará antes o en el mismo bloque que τ2. Al imponer una medida tan grosera granularidad en el orden de transacción, las oportunidades de ataques frontales y otros ataques relacionados con el pedido se reducen considerablemente. Kelkar et al. proponer una familia de protocolos llamada Aequitas [144], que abordan Diferentes modelos de implementación, incluidas configuraciones de red síncronas, parcialmente síncronas y asíncronas. Los protocolos de Aequitas imponen una sobrecarga de comunicación significativa en relación con el consenso básico BFT y, por lo tanto, no son ideales para uso práctico. Sin embargo, creemos que surgirán variantes prácticas de Aequitas que podrán utilizarse para secuenciación de transacciones en FSS y otras aplicaciones. Algunos esquemas relacionados tienen Ya se han propuesto que tienen menos formalismo y propiedades más débiles. por ejemplo, [36, 151, 236], pero mejor rendimiento práctico. Estos esquemas pueden ser apoyados en FSS también. También vale la pena señalar que el término "imparcialidad" aparece en otras partes del blockchain literatura con un significado diferente, a saber, equidad en el sentido de oportunidad paramineros proporcionales a sus recursos comprometidos [106, 181] o para validators en términos de igualdad de oportunidades [153]. Preservación segura de la causalidad: El enfoque más conocido para prevenir el avance y otras violaciones de orden en plataformas distribuidas se basa en criptografía. técnicas. Su característica común es ocultar los datos de la transacción, esperando hasta que Se ha establecido el orden en la capa de consenso y revelar los datos de la transacción. posteriormente para su procesamiento. Esto preserva el orden causal entre las transacciones que se realizan. ejecutado por el blockchain. Las nociones de seguridad y protocolos criptográficos relevantes. se han desarrollado considerablemente antes de la llegada de blockchains [71, 190]. Las condiciones de seguridad de “causalidad de entrada” [190] y “preservación segura de la causalidad” [71, 97] requieren formalmente que no se conozca ninguna información sobre una transacción. antes de que se haya determinado la posición de esta transacción en el orden global. Un adversario no debe poder inferir ninguna información hasta ese momento, de forma criptográfica. sentido fuerte. Se pueden distinguir cuatro técnicas criptográficas para preservar la causalidad: • Protocolos de confirmación-revelación [29, 142, 145]: en lugar de anunciar una transacción en claro, solo se transmite un compromiso criptográfico con la transacción. Después de que se hayan ordenado todas las transacciones comprometidas pero ocultas (a principios de blockchain sistemas en MAINCHAIN, pero aquí por FSS), el remitente debe abrir el compromiso y revelar los datos de la transacción dentro de un intervalo de tiempo predeterminado. Luego, la red verifica que la apertura satisface el compromiso anterior. el Los orígenes de este método datan de antes de la llegada de blockchains. Aunque es particularmente simple, el enfoque presenta desventajas considerables y no es fácil de emplear por dos razones. Primero, dado que sólo el compromiso existe a nivel del protocolo de pedido, la semántica de la transacción no se puede validar durante el consenso. Un viaje adicional de ida y vuelta al cliente. es necesario. Pero lo más grave es la posibilidad de que no se pueda abrir ninguna apertura. llegar alguna vez, lo que podría equivaler a un ataque de denegación de servicio. Además, Es difícil determinar si la apertura es válida de forma consistente y distribuida. manera porque todos los participantes deben ponerse de acuerdo sobre si la apertura llegó en tiempo. • Protocolos de confirmación-revelación con recuperación retrasada [145]: un desafío con el El enfoque de compromiso-revelación es que un cliente puede comprometerse con una transacción de manera especulativa y revelarla más tarde sólo si las transacciones posteriores la hacen rentable. un Una variante reciente del enfoque de compromiso-revelación mejora la resiliencia contra este tipo de mala conducta. En particular, el protocolo TEX [145] aborda este problema. utilizando un enfoque inteligente en el que las transacciones cifradas incluyen una clave de descifrado obtenible calculando una función de retardo verificable (VDF) [53, 221]. si un cliente no logra descifrar su transacción de manera oportuna, otros en el sistema la descifrarán en su nombre resolviendo un rompecabezas criptográfico moderadamente difícil.• Cifrado de umbral [71, 190]: este método aprovecha lo que DON puede realizar operaciones criptográficas de umbral. Supongamos que FSS mantiene un cifrado público key pkO y los oracles comparten la clave privada correspondiente entre ellos. Luego, los clientes cifran las transacciones bajo pkO y las envían al FSS. Órdenes FSS transacciones en el DON, luego las descifra y finalmente las inyecta en CADENA PRINCIPAL en el orden fijo. Por lo tanto, el cifrado garantiza que el pedido sea no se basa en el contenido de la transacción, sino en que los datos en sí están disponibles cuando necesario. Este método fue propuesto originalmente por Reiter y Birman [190] y luego perfeccionado por Cachin et al. [71], donde se integró con un consenso autorizado protocolo. Un trabajo más reciente ha explorado el uso de la criptografía de umbral como Mecanismo de nivel de consenso para mensajes genéricos [33, 97] y para cálculos generales con datos compartidos [41]. En comparación con los protocolos de confirmación y revelación, el cifrado de umbral evita ataques simples de denegación de servicio (aunque se requiere cuidado dado el costo computacional del descifrado). Permite que el DON avance de forma autónoma, a su propia velocidad y sin esperando más acciones del cliente. Las transacciones pueden validarse inmediatamente después de haber sido descifradas. Además, los clientes cifran todas las transacciones con una clave para el DON y el patrón de comunicación sigue siendo el mismo que con otros transacciones. Gestionar la clave de umbral de forma segura y con cambios de nodos en O, sin embargo, puede plantear dificultades adicionales. • Compromiso de compartir secretos [97]: en lugar de cifrar los datos de la transacción en una clave en poder de DON, el cliente también puede compartirla en secreto para los nodos en O. Utilizando un esquema de intercambio de secretos híbrido y computacionalmente seguro, la transacción se cifra primero utilizando un cifrado simétrico con una clave aleatoria. Solo se comparte la clave simétrica correspondiente y el texto cifrado se envía al DON. El cliente debe enviar una clave compartida a cada nodo en O mediante un mensaje cifrado por separado. Los pasos restantes del protocolo son los mismos que con el umbral. cifrado, excepto que los datos de la transacción se descifran con el código simétrico algoritmo después de reconstruir la clave por transacción a partir de sus acciones. Este método no requiere la configuración ni la gestión de un criptosistema de clave pública. asociado con el DON. Sin embargo, los clientes deben ser conscientes de los nodos en O y comunicarse en un contexto seguro con cada uno de ellos, lo que los sitúa carga adicional para los clientes. Aunque los métodos criptográficos ofrecen una protección completa contra la información Al filtrarse de las transacciones enviadas a la red, no ocultan metadatos. Para Por ejemplo, una dirección IP o una dirección Ethereum del remitente aún podría ser utilizada por un adversario para realizar ataques frontales y de otro tipo. Varias mejoras de la privacidad técnicas implementadas en la capa de red, por ejemplo, [52, 95, 107], o la capa de transacción, por ejemplo, [13, 65], sería necesario para lograr este objetivo. El impacto de una pieza en particular. de metadatos, es decir, a qué contrato se envía una transacción, puede ocultarse (parcialmente)mediante la multiplexación de muchos contratos en el mismo DON. Ocultamiento criptográfico de transacciones per se tampoco impide la priorización de transacciones por parte de personas corruptas DON nodos en connivencia con remitentes de transacciones. La causalidad segura garantizada por los protocolos criptográficos complementa las garantías de equidad de orden para cualquier póliza, y tenemos la intención de explorar una combinación de las dos. métodos, cuando esto sea posible. Si un adversario no puede obtener una ventaja significativa Al observar los metadatos, los protocolos seguros de preservación de la causalidad podrían usarse junto con también un enfoque de ordenación ingenuo. Por ejemplo, los nodos oracle pueden escribir transacciones a L tan pronto como los reciban, sin duplicación. Las transacciones entonces serían ordenados según su aparición en L y posteriormente descifrados. También planeamos considerar el uso de TEE como una forma de ayudar a hacer cumplir los pedidos justos; para Por ejemplo, se puede considerar que Tesseract [44] logra una forma de ordenamiento causal, pero uno fortalecido por la capacidad del TEE para procesar transacciones en forma explícita mientras conservando su confidencialidad. 5.4 Consideraciones de la capa de red Hasta ahora, nuestra descripción del FSS se ha centrado principalmente en el problema de hacer cumplir que el El orden final de las transacciones coincide con el orden observado en la red. De ahora en adelante, Consideramos cuestiones de equidad que podrían surgir en la propia capa de red. Los comerciantes de alta frecuencia en los mercados electrónicos convencionales invierten considerables recursos para obtener una velocidad de red superior [64], y los comerciantes en intercambios de criptomonedas exhiben un comportamiento similar [90]. La velocidad de la red confiere una ventaja tanto en observar las transacciones de otras partes y presentar transacciones competitivas. Un remedio implementado en la práctica y popularizado en el libro Flash Boys [155] es el “bache de velocidad” introducido inicialmente en el intercambio IEX [128] y posteriormente en otros intercambia [179] (con resultados mixtos [19]). Este mecanismo impone un retraso (350 microsegundos en IEX) en el acceso al mercado, con el objetivo de neutralizar las ventajas en velocidad. Evidencia empírica, p.e. [128], respalda su eficacia para disminuir ciertas operaciones costes para los inversores ordinarios. FSS se puede utilizar simplemente para implementar un sistema asimétrico. obstáculo: uno que retrasa las transacciones entrantes. Budish, Cramton y Shim [64] sostienen que la explotación de las ventajas de la velocidad es ineludible en los mercados de tiempo continuo, y abogan por una solución estructural en el en forma de mercados basados en subastas por lotes. Pero este enfoque no ha arraigado ampliamente en las plataformas comerciales existentes. Los sistemas comerciales convencionales están centralizados y normalmente reciben transacciones a través de una única conexión de red. En un sistema descentralizado, por el contrario, es posible observar la propagación de transacciones desde múltiples puntos de vista. En consecuencia, es posible observar comportamientos como la inundación de la red en una red P2P. pretendemos Explorar enfoques de capa de red para FSS que ayuden a los desarrolladores a especificar políticas. prohibir tales comportamientos indeseables en la red.5.5 Políticas de equidad a nivel de entidad La equidad del orden y la causalidad segura tienen como objetivo hacer cumplir un orden en las transacciones que respeta el momento en que fueron creados y enviados por primera vez a la red. Una limitación de esta noción de justicia es que no previene ataques en los que un adversario obtiene una ventaja al inundar un sistema con muchas transacciones, una estrategia observada en la naturaleza como una forma de realizar transacciones efectivas en token ventas [159] y para crear congestión que resulte en la liquidación de posiciones de deuda garantizada (CDP) [48]. En otras palabras, la equidad en el orden impone justicia con respecto a las transacciones, no a los jugadores. Como se muestra en el sistema CanDID [160], es posible utilizar herramientas oracle como DECO o Town Pregonero en conjunto con un comité de nodos (como un DON) para lograr diversas formas de resistencia a Sybil al tiempo que protege la privacidad. Los usuarios pueden registrar identidades. y proporcionar evidencia de su singularidad sin revelar las identidades mismas. Las credenciales resistentes a Sybil ofrecen un posible enfoque para enriquecer el ordenamiento de transacciones políticas de una manera que limitaría las oportunidades de ataques por inundaciones. Por ejemplo, un La venta token podría permitir solo una transacción por usuario registrado, donde el registro requiere una prueba de unicidad de un identificador nacional, como un número de seguro social. Este enfoque no es infalible, pero puede resultar una política útil para mitigar los ataques de inundación de transacciones.

El marco de ejecución de transacciones DON

(DON-TEF) DONs proporcionará oracle y soporte de recursos descentralizados para soluciones de capa 2 dentro lo que llamamos Marco de ejecución de transacciones de red descentralizada de Oracle (DONTEF) o TEF para abreviar. Hoy en día, la frecuencia de las actualizaciones de los contratos DeFi está limitada por las latencias de la cadena principal, por ejemplo, el intervalo de bloque promedio de 10 a 15 segundos en Ethereum [104], así como el costo de impulsar grandes cantidades de datos en cadena y un rendimiento computacional/de transmisión limitado: enfoques de escalamiento motivadores como la fragmentación [148, 158, 232] y la ejecución de capa 2 [5, 12, 121, 141, 169, 186, 187]. Incluso blockchains con tiempos de transacción mucho más rápidos, por ejemplo, [120], han propuesto estrategias de escalamiento que involucran cálculo fuera de la cadena [168]. TEF está destinado a actuar como un recurso de capa 2 para cualquiera de dichos sistemas de capa 1/CADENA PRINCIPAL. Usando TEF, DONs pueden admitir actualizaciones más rápidas en un contrato MAINCHAIN mientras conservar las garantías de confianza clave proporcionadas por la cadena principal. TEF puede apoyar cualquiera de una serie de técnicas y paradigmas de ejecución de capa 2, incluidos rollups,11 rollups optimistas, Validium, etc., así como un modelo de confianza de umbral en el que DON Los nodos ejecutan transacciones. El TEF es complementario del FSS y está destinado a apoyarlo. En otras palabras, cualquier La aplicación que se ejecuta en TEF puede utilizar FSS. 11A menudo llamados “zk-rollups”, un nombre inapropiado, ya que no necesariamente necesitan pruebas de conocimiento cero.

6.1 Descripción general de TEF El TEF es un patrón de diseño para la construcción y ejecución de un híbrido de alto rendimiento. smart contractSC. De acuerdo con la idea principal detrás de los smart contracts híbridos, TEF implica un descomposición de SC en dos partes: (1) Lo que llamamos en el contexto TEF un ancla contrato SCa en MAINCHAIN y (2) DON lógica ejecutable que llamamos ejecutable TEF. Usamos SC aquí para denotar el contrato lógico implementado por la combinación de SCa y ejecutar. (Como se señaló anteriormente, esperamos desarrollar herramientas de compilación para descomponer un contrato SC automáticamente en estos componentes.) El ejecutable TEF exect es el motor que procesa las transacciones de los usuarios en SC. eso se puede ejecutar de manera eficiente, ya que se ejecuta en DON. Tiene varias funciones: • Ingestión de transacciones: exect recibe o recupera las transacciones de los usuarios. puede hacerlo directamente, es decir, a través del envío de transacciones en DON, o a través de MAINCHAIN mempool usando MS. • Ejecución rápida de transacciones: exect procesa transacciones que involucran activos dentro SC. Lo hace localmente, es decir, en el DON. • Acceso rápido y de bajo costo a oracle/adaptador: exect tiene acceso nativo a los informes oracle y otros datos del adaptador que conducen a, por ejemplo, activos más rápidos, más baratos y más precisos. fijación de precios que la ejecución MAINCHAIN. Además, el acceso fuera de la cadena oracle reduce el costo operativo del oracle, por lo tanto, el costo de uso del sistema, al evitar costoso almacenamiento en cadena. • Sincronización: exect envía periódicamente actualizaciones de DON a MAINCHAIN, actualizando SCa. El contrato ancla es la parte frontal de MAINCHAIN ​​de SC. Como componente de mayor confianza de SC, cumple varios propósitos: • Custodia de activos: los fondos de los usuarios se depositan, mantienen y retiran de SCa. • Verificación de sincronización: SCa puede verificar la exactitud de las actualizaciones de estado cuando se ejecutan. sincroniza, por ejemplo, SNARK adjuntos a rollups. • Barandillas: SCa puede incluir disposiciones para proteger contra la corrupción o fallas. en ejecutivo. (Consulte la Sección 7 para obtener más detalles). En TEF, los fondos de los usuarios están custodiados en MAINCHAIN, lo que significa que el DON en sí mismo no tiene custodia. Dependiendo de la elección del mecanismo de sincronización (ver más abajo), los usuarios pueden necesitar confiar en DON solo para obtener informes oracle precisos y sincronización oportuna con MAINCHAIN. El modelo de confianza resultante es muy similar al de los DEX basados en libros de pedidos, por ejemplo, [2], que hoy en día generalmente incluyen un componente fuera de la cadena para igualar órdenes y un componente dentro de la cadena para compensación y liquidación.Para utilizar el vocabulario de los sistemas de pago, se puede pensar en exect como el componente SCa es responsable de la compensación, mientras que SCa se encarga de la liquidación. Consulte la Fig. 13 para ver un esquema. representación de TEF. Figura 13: Esquema de TEF. En este ejemplo, las transacciones pasan a través del mempool. de MAINCHAIN vía MS al DON. Beneficios de TEF: TEF conlleva tres beneficios principales: • Alto rendimiento: SC hereda el rendimiento mucho mayor de DON que MAINCHAIN tanto para transacciones como para informes oracle. Además, exect puede procesar transacciones más rápido y responder a oracle informes de manera más oportuna que una implementación solo en MAINCHAIN. • Tarifas más bajas: el proceso de sincronización es menos urgente que el procesamiento de transacciones, y las transacciones se pueden enviar desde DON a MAINCHAIN ​​en lotes. En consecuencia, las tarifas por transacción en cadena (por ejemplo, costos de gas) con este enfoque son mucho más bajas que las de un contrato que se ejecuta solo en MAINCHAIN. • Confidencialidad: Los mecanismos de confidencialidad del DON se pueden llevar a insistir en SC.

Limitaciones del TEF: Una limitación de TEF es que no admite transferencia instantánea. retiros, ya que ocurren solo en MAINCHAIN: Al enviar una solicitud de retiro a SCa, es posible que un usuario deba esperar a que exect realice una actualización de estado que incluya el transacción de retiro antes de que pueda ser aprobada. Discutimos algunos remedios parciales, sin embargo, en la Sección 6.2. Otra limitación de TEF es que no admite la composición atómica de DeFi contratos en MAINCHAIN, específicamente la capacidad de enrutar activos a través de múltiples DeFi contratos en una sola transacción. Sin embargo, el TEF puede respaldar dicha atomicidad entre DeFi contratos que se ejecutan en el mismo DON. También analizamos algunas formas de abordar este problema. problema en la Sección 6.2. 6.2 Enrutamiento de transacciones Los usuarios pueden enviar las transacciones para SC directamente al DON o pueden enrutarse a través de el mempool en MAINCHAIN (a través de FSS). Hay cuatro tipos distintos de transacciones, cada uno de los cuales requiere un manejo diferente: Transacciones dentro del contrato: Debido a que evita las complicaciones de la dinámica del gas, TEF proporciona a SC más flexibilidad en el manejo de transacciones de lo que sería disponible en un contrato de capa 1. Por ejemplo, mientras una transacción de mempool en Ethereum puede ser sobrescrito por una nueva transacción con un precio de gas más alto, SC puede tratar una transacción que opera en activos dentro de SC como autorizada tan pronto como se vuelve visible en el grupo de memoria. En consecuencia, SC no necesita esperar a que se confirme una transacción. dentro de un bloque, lo que resulta en una latencia considerablemente reducida. Proxy: Un usuario puede desear enviar una transacción τ a SC a través de un contrato de billetera o otro contrato en MAINCHAIN. Es posible que DON simule la ejecución de τ en MAINCHAIN para determinar si da como resultado una transacción de seguimiento a SC. Si es así, τ puede secuenciarse con otras transacciones para SC que lo hagan. Hay algunos posibilidades sobre cómo DON identifica tales transacciones: (1) El DON puede simular todas las transacciones en el mempool (un enfoque costoso); (2) Ciertos contratos o los tipos de contratos, por ejemplo, billeteras, pueden enumerarse para su seguimiento mediante el DON; o (3) los usuarios pueden anotar transacciones para la inspección DON. Las cosas se vuelven más complicadas cuando una sola transacción interactúa con dos contratos, SC1 y SC2, los cuales utilizan Fair Sequencing Services y tienen políticas de pedidos incompatibles. El DON podría, por ejemplo, secuenciar τ en el último momento que sea compatible con ambos. Depósitos: Una transacción que deposita un activo MAINCHAIN en SC debe confirmarse en un bloque antes de que SC pueda considerarla válida. Cuando detecta la extracción de un transacción que envía activos (por ejemplo, Ether) a SCa, exect puede confirmar instantáneamente ladepósito. Por ejemplo, puede aplicar un precio actual informado oracle en el DON al activo. Retiros: Como se señaló anteriormente, una limitación de TEF es que los retiros no siempre se pueden ejecutar instantáneamente. En un modelo de ejecución de tipo rollup, el retiro La solicitud debe secuenciarse con otras transacciones, es decir, acumularse, para poder realizarse de forma segura. procesado. Sin embargo, existen algunas soluciones parciales a esta limitación. Si DON puede calcular rápidamente una prueba de validez rollup hasta la transacción de retiro, entonces observar la transacción τ de un usuario en el mempool exect puede enviar una transacción de actualización de estado τ ′ por τ a un precio de gas más alto, una especie de avance benéfico. Siempre que τ no se extraiga antes de que τ ′ llegue al mempool, τ ′ precederá a τ y τ efectuará un retiro aprobado. En una variante de TEF donde se confía en DON para calcular las actualizaciones de estado (consulte la variante de firma de umbral a continuación), el DON puede alternativamente determinar fuera de la cadena si τ debería aprobarse dado el estado de SC al momento de su ejecución. El DON luego puede enviar una transacción τ ′ que aprueba el retiro τ, sin efectuar un pago completo actualización del estado. Si este enfoque no es posible, o en los casos en los que no tiene éxito, una iniciativa iniciada por DON La transacción τ ′ puede enviar fondos al usuario en respuesta a τ para que el usuario no necesite iniciar una transacción adicional. 6.3 Sincronización El ejecutable TEF envía periódicamente actualizaciones de DON a MAINCHAIN, actualizar el estado de SCa en un proceso al que nos referimos como sincronización. Se puede pensar en sincronizar como propagación de transacciones de capa 2 a capa 1, por lo que TEF puede recurrir a cualquiera de un número de técnicas existentes para este propósito, incluyendo rollups [5, 12, 16, 69], optimista rollups [10, 11, 141], Validium [201] o firma de umbral básico, por ejemplo, umbral BLS, Schnorr o ECDSA [24, 54, 116, 202]. En principio, entornos de ejecución confiables También puede dar fe de la corrección de los cambios de estado, ofreciendo una visión mucho más eficaz. alternativa a rollups, pero con un modelo de confianza dependiente del hardware. (Ver, por ejemplo, [80].) A continuación comparamos estas opciones de sincronización con respecto a tres propiedades clave en TEF: • Disponibilidad de datos: ¿Dónde se almacena el estado de SC? Al menos tres opciones son disponible en TEF: en MAINCHAIN, en un DON o mediante algún almacenamiento de terceros proveedores como IPFS. Logran diferentes garantías de seguridad, disponibilidad niveles y perfiles de desempeño. Brevemente, almacenar el estado en MAINCHAIN permite auditabilidad en cadena y elimina la dependencia de cualquier parte para la disponibilidad del estado; por otro lado, almacenar el estado fuera de la cadena puede reducir el costo de almacenamiento y mejorar rendimiento, a costa de confiar en los proveedores de almacenamiento (DON o terceros) para disponibilidad de datos. Por supuesto, los modelos flexibles que combinan estas opciones también son posible. Indicamos la forma requerida de disponibilidad de datos en la Tabla 1.• Garantías de corrección: ¿Cómo comprueba SCa la corrección de las actualizaciones? empujado por ejecutivo? Esto afecta la carga computacional en exect y SCa y la latencia de sincronización (ver más abajo). • Latencia: La latencia de sincronización tiene tres factores que contribuyen: (1) El tiempo necesario para ejecutar generar una transacción de sincronización τsync; (2) El tiempo necesario para τsync por confirmar en MAINCHAIN; y (3) El tiempo para que τsync surta efecto en SCa. En TEF, la latencia es particularmente importante para los retiros (pero menos para transacciones dentro del contrato) porque los retiros necesariamente requieren (al menos parcial) sincronización de estado. Sincronización opciones Datos disponibilidad Corrección garantías Latencia Resumen [5, 12, 16, 69] En cadena Pruebas de validez Tiempo necesario para generar pruebas de validez (por ejemplo, actas en los sistemas actuales) Validez [201] Fuera de cadena Pruebas de validez Igual que arriba Optimista rollup [10, 11, 141] En cadena Pruebas de fraude Duración del desafío período (por ejemplo, dias o semanas) Firma de umbral [24, 54, 116, 202] Flexibles Firmas de umbral por DON Instantáneo Entornos de ejecución confiables [80] Flexibles Basado en hardware atestados Instantáneo Tabla 1: Varias opciones de sincronización en TEF y sus propiedades. La Tabla 1 resume estas propiedades en las cinco opciones principales de sincronización en TEF. (Nota que no pretendemos comparar estas tecnologías como escalamiento de capa 2 independiente soluciones. Para ello remitimos a los lectores, por ejemplo, a [121]). Ahora analizamos cada opción de sincronización. Acumulados: Un rollup [69] es un protocolo en el que la transición de estado efectuada por un El lote de transacciones se calcula fuera de la cadena. Luego el cambio de estado se propaga en CADENA PRINCIPAL. Para implementar rollups, el ancla smart contract SCa almacena una representación compacta Rstate (por ejemplo, una raíz de Merkle) del estado real. Para sincronizar, ejecutar envía τsync = (T,R′ estado) a SCa donde T es el conjunto de las transacciones que procesó desde la últimasincronización y R′ state es la representación compacta del nuevo estado calculado aplicando transacciones en T al estado anterior Rstate. Hay dos variantes populares que difieren en cómo SCa verifica las actualizaciones de estado en τsync. El primero, (zk-)rollups, adjunta un argumento sucinto de corrección, a veces llamado una prueba de validez, para la transición Rstate →R′ estado. Para implementar esta variante, ejecute calcula y envía la prueba de validez (por ejemplo, una prueba zk-SNARK) junto con τsync, demostrando que R′ El estado es el resultado de aplicar T al estado actual de SCa. el ancla El contrato acepta la actualización del estado sólo después de haber verificado la prueba. Los rollup optimistas no incluyen argumentos de corrección, pero tienen staking y cuestionar los procedimientos que facilitan la verificación distribuida de las transiciones estatales. Para esto Variante rollup, SCa acepta tentativamente τsync asumiendo que es correcto (de ahí el optimismo) pero τsync no entra en vigor hasta después de un período de desafío, durante el cual cualquier parte El monitoreo de MAINCHAIN puede identificar actualizaciones de estado erróneas e informar a SCa que tome acciones necesarias (por ejemplo, revertir el estado e infligir una penalización a la ejecución). Ambas variantes rollup logran disponibilidad de datos en cadena, a medida que se publican las transacciones en cadena, a partir del cual se puede construir el estado completo. La latencia de zk-rollups es dominado por el tiempo necesario para generar pruebas de validez, que normalmente depende del tiempo orden de minutos en los sistemas existentes [16] y probablemente verá mejoras con el tiempo. Los rollup optimistas, por otro lado, tienen una latencia más alta (por ejemplo, días o semanas). porque el período de impugnación debe ser lo suficientemente largo para que funcionen las pruebas de fraude. el La implicación de una confirmación lenta es sutil y a veces específica del esquema, de modo que un análisis exhaustivo está fuera de alcance. Por ejemplo, ciertos planes consideran el pago transacciones como “finales sin confianza” [109] antes de que se confirme la actualización del estado, ya que un Un usuario normal podría verificar un rollup mucho más rápido que MAINCHAIN. Validio: Validium es una forma de (zk-)rollup que hace que los datos estén disponibles solo fuera de la cadena. y no mantiene todos los datos en MAINCHAIN. Específicamente, exect envía sólo el nuevo estado y la prueba pero no las transacciones a SCa. Con sincronización estilo Validium, ejecute y el DON que lo ejecuta son los únicos que almacenan el estado completo y que ejecutan transacciones. Al igual que con zk-rollups, la latencia de sincronización está dominada por la validez. tiempo de generación de pruebas. Sin embargo, a diferencia de zk-rollups, la sincronización del estilo Validium reduce el costo de almacenamiento y aumenta el rendimiento. Firma de umbral por DON: Asumir un umbral de DON nodos es honesto, un La opción de sincronización simple y rápida es hacer que DON nodos firmen colectivamente el nuevo estado. Este enfoque puede respaldar la disponibilidad de datos tanto dentro como fuera de la cadena. Tenga en cuenta que si Los usuarios confían en DON para las actualizaciones de oracle, no necesitan confiar más en él para aceptar actualizaciones de estado, ya que ya se encuentran en un modelo de confianza de umbral. Otro beneficio de El umbral de firma es de baja latencia. Soporte para nuevos formatos de firma de transacciones como propuesto en EIP-2938 [70] y conocido como abstracción de cuenta haría que el umbral firmar considerablemente más fácil de implementar, ya que eliminaría la necesidad de establecer un umbral ECDSA, que implica protocolos considerablemente más complejos (p. ej., [116, 117, 118])que alternativas como el umbral de firmas Schnorr [202] o BLS [55]. Entornos de ejecución confiables (TEE): Los TEE son entornos de ejecución aislados (generalmente realizados mediante hardware) que tienen como objetivo proporcionar protecciones de seguridad sólidas. para programas que se ejecutan en su interior. Algunos TEE (por ejemplo, Intel SGX [84]) pueden producir pruebas, conocidos como atestados, que una salida es calculada correctamente por un programa específico para una entrada particular12. Se puede implementar una variante de sincronización TEF basada en TEE mediante reemplazar pruebas en (zk-)rollups o Validium con certificaciones TEE usando técnicas de [80]. En comparación con las pruebas de conocimiento cero utilizadas en rollups y Validium, los TEE son mucho más más rendimiento. En comparación con la firma de umbral, los TEE eliminan la complejidad de generar firmas ECDSA de umbral ya que, en principio, solo es necesario que haya un TEE involucrados. Sin embargo, el uso de TEE introduce suposiciones de confianza adicionales dependientes del hardware. También se pueden combinar TEE con firma de umbral para crear resiliencia. contra el compromiso de una fracción de los casos de TEE, aunque esta medida de protección reintroduce la complejidad de generar firmas ECDSA de umbral. Flexibilidad adicional: Estas opciones de sincronización se pueden perfeccionar para proporcionar más flexibilidad de las siguientes maneras. • Activación flexible: la aplicación TEF puede determinar las condiciones bajo las cuales se activa la sincronización. Por ejemplo, la sincronización puede realizarse por lotes, por ejemplo, después de cada N transacciones, basadas en el tiempo, por ejemplo, cada 10 bloques, o basadas en eventos, por ejemplo, ocurren siempre que los precios objetivo de los activos se muevan significativamente. • Sincronización parcial: es posible y en algunos casos deseable (por ejemplo, con rollups, La sincronización parcial puede reducir la latencia) para proporcionar una sincronización rápida de pequeños cantidades de estado, realizando una sincronización completa quizás solo periódicamente. Por ejemplo, exect puede aprobar una solicitud de retiro actualizando el saldo de un usuario en SCa sin actualizar de otro modo el estado de MAINCHAIN. 6.4 Reorganizaciones Reorganizaciones de blockchain resultantes de la inestabilidad de la red o incluso de ataques del 51% puede representar una amenaza para la integridad de una cadena principal. En la práctica, los adversarios han utilizado organizar ataques de doble gasto [34]. Si bien estos ataques a las principales cadenas son Aunque son difíciles de montar, siguen siendo factibles para algunas cadenas [88]. Debido a que opera independientemente de MAINCHAIN, un DON ofrece la interesante posibilidad de observar y proporcionar algunas protecciones contra reorganizaciones asociadas con ataques. Por ejemplo, un DON puede informar a un SC de contrato dependiente en MAINCHAIN ​​la existencia de una bifurcación competidora de cierta longitud umbral τ. El DON también puede 12En el Apéndice B.2.1 se pueden encontrar detalles complementarios. No son necesarios para la comprensión.

proporcionar pruebas, ya sea en un entorno PoW o PoS, de la existencia de dicha bifurcación. el El contrato SC puede implementar acciones defensivas adecuadas, como suspender la ejecución de transacciones adicionales por un período de tiempo (por ejemplo, para permitir que los intercambios incluyan en la lista negra los gastos dobles). activos). Tenga en cuenta que, si bien un adversario que realiza un ataque del 51% puede intentar censurar informes de un DON, una contramedida en SC es requerir informes periódicos del DON para procesar transacciones (es decir, un latido) o para requerir un nuevo informe para validar una transacción de alto valor. Si bien estas alertas de bifurcación son, en principio, un servicio general, el DON puede proporcionar Para cualquiera de una serie de propósitos, nuestro plan es incorporarlos al TEF.

Minimización de confianza

Como sistema descentralizado con participación de un conjunto heterogéneo de entidades, el La red Chainlink proporciona una sólida protección contra fallas tanto en la vida (disponibilidad) como en la seguridad (integridad del informe). La mayoría de los sistemas descentralizados, sin embargo, varían en el grado en que sus componentes constitutivos están ellos mismos descentralizados. esto Esto es cierto incluso para sistemas grandes, donde la descentralización limitada entre los mineros [32] y intermediarios [51] ha estado presente durante mucho tiempo. El objetivo de cualquier esfuerzo de descentralización es minimizar la confianza: buscamos reducir la efectos adversos de la corrupción sistémica o falla dentro de la red Chainlink, incluso eso debido a un DON malicioso. Nuestro principio rector es el Principio de Mínimo Privilegio [197]. Los componentes del sistema y los actores dentro del sistema deben tener privilegios estrictamente limitados. para permitir únicamente el cumplimiento exitoso de sus roles asignados. Aquí presentamos varios mecanismos concretos para que Chainlink los adopte en su impulso. hacia una minimización cada vez mayor de la confianza. Caracterizamos estos mecanismos en términos de los loci, es decir, los componentes del sistema, en los que están arraigados, como se muestra en la Fig. 14. abordar cada locus en una subsección respectiva. 7.1 Autenticación de fuente de datos Los modelos operativos actuales para oracles están limitados por el hecho de que pocas fuentes de datos firman digitalmente los datos que omiten, en gran parte porque TLS no firma de forma nativa datos. TLS hace uso de firmas digitales en su protocolo de “apretón de manos” (para establecer una clave compartida entre un servidor y un cliente). Por lo tanto, los servidores habilitados para HTTPS tienen certificados sobre claves públicas que en principio pueden servir para firmar datos, pero generalmente no utilizan estos certificados para respaldar la firma de datos. En consecuencia, la seguridad de un DON, como en las redes oracle actuales, se basa en nodos oracle que transmiten fielmente datos desde un fuente a un contrato. Un componente importante a largo plazo de nuestra visión para la minimización de la confianza en Chainlink implica una autenticación más sólida de la fuente de datos mediante el soporte de herramientas y estándares para la firma de datos. La firma de datos puede ayudar a hacer cumplir las garantías de integridad de un extremo a otro. En principio, si un contrato acepta como entrada un dato D firmado directamente por un

Figura 14: Loci de los mecanismos de minimización de confianza discutidos en esta sección. 1⃝Datos Las fuentes proporcionan datos al 2⃝DON, que transmite una función de los datos a un dependiente. 3⃝smart contract. Además, la red DON o oracle incluye 4⃝nodos gestión de smart contracts en MAINCHAIN para, por ejemplo, nodos de compensación, guardia rieles, etc. fuente, entonces la red oracle no puede alterar D. Varios elementos alentadores Han surgido esfuerzos para permitir dicha firma de datos, incluido OpenID Connect, que está diseñado principalmente para la autenticación de usuarios [9], TLS-N, un proyecto académico que tiene como objetivo ampliar TLS [191] reutilizando certificados TLS y Extensiones de evidencia TLS [63]. Si bien OpenID Connect ha experimentado cierta adopción, TLS Evidence Extensions y TLS-N aún no han sido adoptados. Otra posible vía de autenticación de fuentes de datos es utilizar las propias herramientas de los editores. Intercambios HTTP firmados (SXG) [230], que pueden almacenar en caché en redes de entrega de contenido como parte del protocolo Accelerated Mobile Pages (AMP) [225]. El navegador móvil Chrome muestra el contenido de los SXG almacenados en caché de AMP como si fueran servidos desde los propios dominios de red de sus editores en lugar del dominio del servidor de caché. Este incentivo de marca, junto con la relativa facilidad para habilitarlo mediante servicios como Real URL [83] de CloudFlare y amppackager [124] de Google, puede conducir a una adopción generalizada de SXG en contenido de noticias almacenado en caché, lo que permitiría una solución simple y resistente a manipulaciones. manera para que Chainlink oracles se activen en eventos de interés periodístico reportados en SXG válidos. Si bien los SXG almacenados en caché de AMP de los editores de noticias no serían útiles para aplicaciones como informes sobre datos comerciales, podrían ser una fuente segura de información personalizada contratos relacionados con eventos del mundo real como condiciones climáticas extremas o resultados electorales. Creemos que una implementación simple, herramientas maduras y flexibilidad serán vitales para acelerar la firma de fuentes de datos. Permitir que los proveedores de datos utilicen Chainlink nodos como una interfaz API autenticada parece un enfoque prometedor. Pretendemos crear unaopción para que los nodos funcionen en este modo, con o sin participación en la red como un oracle en toda regla. Nos referimos a esta capacidad como origen de datos autenticados. (ADO). Al utilizar nodos Chainlink con ADO, las fuentes de datos podrán beneficiarse a partir de la experiencia y las herramientas desarrolladas por la comunidad Chainlink para agregar contenido digital capacidades de firma a su conjunto existente de API fuera de la cadena. ¿Deberían optar por correr? sus nodos como oracles, también pueden abrir nuevas fuentes de ingresos potenciales bajo el mismo modelo que los proveedores de datos existentes, por ejemplo, Kraken [28], Kaiko [140] y otros, que ejecutan Chainlink nodos para vender datos API en cadena. 7.1.1 Las limitaciones del origen de datos autenticados La firma digital mediante fuentes de datos, si bien puede ayudar a fortalecer la autenticación, no es suficiente per se para lograr todos los objetivos operativos o de seguridad natural de un oracle red. Para empezar, un determinado dato D aún debe transmitirse de manera sólida y oportuna. desde una fuente de datos hasta smart contract u otro consumidor de datos. Es decir, incluso en un entorno ideal en el que todos los datos se firman mediante claves preprogramadas en dependientes contratos, aún se necesitaría un DON para comunicar los datos de manera confiable desde las fuentes a los contratos. Además, hay una serie de casos en los que los contratos u otros datos oracle Los consumidores quieren acceso a la salida autenticada de varias funciones calculadas sobre datos de origen por dos razones principales: • Confidencialidad: una API de fuente de datos puede proporcionar datos confidenciales o de propiedad exclusiva. que debe redactarse o desinfectarse antes de que se haga visible públicamente en la cadena. Sin embargo, cualquier modificación de los datos firmados invalidaba la firma. pon otro De esta manera, el ADO ingenuo y la desinfección de datos son incompatibles. Mostramos en el ejemplo 3. cómo se pueden conciliar ambos mediante una forma mejorada de ADO. • Fallos en las fuentes de datos: tanto los errores como las fallas pueden afectar las fuentes de datos, y las firmas digitales no abordan ninguno de los problemas. Desde sus inicios [98], Chainlink ha Ya se incluye un mecanismo para remediar tales fallas: la redundancia. Los informes emitidos por las redes oracle normalmente representan los datos combinados de múltiples fuentes. Ahora analizamos los esquemas que estamos explorando en el entorno ADO para mejorar la confidencialidad de los datos de origen y combinar datos de múltiples fuentes de forma segura. 7.1.2 Confidencialidad Es posible que las fuentes de datos no anticipen ni pongan a disposición toda la gama de API deseadas. por los usuarios. Específicamente, los usuarios pueden desear acceder a datos preprocesados para ayudar a garantizar confidencialidad. El siguiente ejemplo ilustra el problema.Ejemplo 3. Alice desea obtener una credencial de identidad descentralizada (DID) que indique que tiene más de 18 años (y por lo tanto puede, por ejemplo, solicitar un préstamo). hacer por lo tanto, debe demostrar este hecho sobre su edad ante un emisor de credenciales DID. Alice espera utilizar datos del Departamento de Vehículos Motorizados (DMV) de su estado. sitio web para tal fin. El DMV tiene un registro de su fecha de nacimiento y emitirá un Certificado A firmado digitalmente en el mismo de la siguiente forma: A = {Nombre: Alice, DoB: 16/02/1999}. En este ejemplo, la atestación A puede ser suficiente para que Alice le demuestre al DID emisor de la credencial que tiene más de 18 años. Pero filtra innecesariamente información confidencial: Alice DoB exacto. Idealmente, lo que Alice quisiera del DMV es una firma en un afirmación simple A′ de que “Alice tiene más de 18 años”. En otras palabras, ella quiere el salida de una función G en su fecha de nacimiento X, donde (informalmente), A′ = G(X) = Verdadero si FechaActual −X ≥18 años; de lo contrario, G(X) = Falso. Para generalizar, a Alice le gustaría poder solicitar a la fuente de datos un documento firmado. atestación A′ de la forma: A′ = {Nombre: Alice, Función:G(X), Resultado: Verdadero}, donde G(X) denota una especificación de una función G y su(s) entrada(s) X. Prevemos que un usuario debería poder proporcionar un G(X) deseado como entrada con su solicitud de un certificación correspondiente A′. Tenga en cuenta que la certificación A′ de la fuente de datos debe incluir la especificación G(X) para asegúrese de que A′ se interprete correctamente. En el ejemplo anterior, G(X) define el significado del valor booleano en A′ y por lo tanto True significa el sujeto de la atestación es mayor de 18 años. Nos referimos a consultas flexibles en las que un usuario puede especificar G(X) como consultas funcionales. Para admitir casos de uso como el del Ejemplo 3, así como aquellos que involucran consultas directamente de los contratos, pretendemos incluir soporte para consultas funcionales que involucren funciones simples G como parte de ADO. 7.1.3 Combinando datos de origen Para reducir los costos en cadena, los contratos generalmente están diseñados para consumir datos combinados. de múltiples fuentes, como se ilustra en el siguiente ejemplo. Ejemplo 4 (Datos de precios de medianización). Para proporcionar un indicador de precios, es decir, el valor de uno activo (por ejemplo, ETH) con respecto a otro (por ejemplo, USD), una red oracle generalmente Obtener precios actuales de varias fuentes, como bolsas. La red oracle normalmente envía a un contrato dependiente SC la mediana de estos valores. En un entorno con firma de datos, se obtiene una red oracle que funciona correctamente de fuentes de datos S = {S1, . . . , SnS} una secuencia de valores V = {v1, v2, . . . , vnS} de nS fuentes acompañadas de firmas específicas de la fuente Σ = {σ1, σ2, . . . , σnS}. sobre Al verificar las firmas, transmite el precio v = mediana(V ) a SC.Desafortunadamente, no existe una forma sencilla para que una red oracle transmita la mediana valor v en el ejemplo 4 a SC junto con una prueba sucinta σ∗ de que v se calculó correctamente sobre entradas firmadas. Un enfoque ingenuo sería codificar en SC las claves públicas de todas las fuentes de datos nS. La red oracle luego transmitiría (V, Σ) y permitiría a SC calcular la mediana de V. Sin embargo, esto daría como resultado una prueba σ de tamaño O(nS), es decir, σ∗ no sería sucinta. También generaría altos costos de gas para SC, que necesitaría verificar todas las firmas en Σ. El uso de SNARK, por el contrario, permite una prueba sucinta de valores fuente autenticados correctamente combinados. Puede que sea viable en la práctica, pero impone unas exigencias bastante altas. costos computacionales en el probador y costos de gas algo altos en la cadena. uso de Town Crier también es una posibilidad, pero requiere el uso de TEE, lo que no se adapta a todos Modelos de confianza de los usuarios. Un concepto útil para enmarcar soluciones al problema general de firmar datos combinados de fuentes es una herramienta criptográfica conocida como firmas funcionales [59, 132]. En resumen, las firmas funcionales permiten al firmante delegar la capacidad de firma, de modo que el delegado sólo puede firmar mensajes en el rango de una función F elegida por el firmante. En el Apéndice D mostramos cómo esta restricción funcional puede servir para limitar el rango de valores de informe emitidos por un DON en función de los valores firmados por las fuentes de datos. También presentamos una nueva primitiva, llamada firma funcional discretizada, que incluye un requisito relajado de precisión, pero que potencialmente tiene mucho más rendimiento. que enfoques como los SNARK. El problema de combinar fuentes de datos de una manera que incluya la autenticación de la fuente de resultados también se aplica a los agregadores de datos, por ejemplo, CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, etc., que obtienen datos de una multiplicidad de intercambios, que ponderación en función de volúmenes, utilizando metodologías que en algunos casos hacen públicas y en otros casos son propietarios. Un agregador que desea publicar un valor con La autenticación de origen enfrenta el mismo desafío que una colección de nodos que se agregan. datos de origen. 7.1.4 Procesamiento de datos fuente Es probable que los smart contracts sofisticados dependan de estadísticas agregadas personalizadas durante fuentes de datos primarias, como la volatilidad en el historial de precios reciente de muchos activos, o textos y fotografías de noticias sobre hechos relevantes. Debido a que la computación y el ancho de banda son relativamente baratos en un DON, estas estadísticas: Incluso los modelos complejos de aprendizaje automático con muchas entradas se pueden procesar de forma económica, siempre que cualquier valor de salida destinado a un blockchain sea lo suficientemente conciso. Para trabajos computacionalmente intensivos donde DON los participantes pueden tener diferentes opiniones sobre entradas complejas, es posible que se requieran rondas adicionales de comunicación entre los DON participantes para establecer un consenso sobre las entradas antes de calcular el resultado. Siempre que el valor final esté completamente determinado por las entradas, una vez que se establece el consenso sobre las entradas, cada participante puede simplemente calcular el valor y transmitirlo al otro.participantes con su firma parcial, o enviarla a un agregador. 7.2 DON Minimización de confianza Visualizamos dos formas principales de minimizar la confianza depositada en los componentes del DON: clientes de conmutación por error e informes de minorías. 7.2.1 Clientes de conmutación por error Los modelos contradictorios en la literatura sobre criptografía y sistemas distribuidos generalmente considerar un adversario capaz de corromper (es decir, comprometer) un subconjunto de nodos, por ejemplo, menos de un tercio para muchos protocolos BFT. Se observa comúnmente, sin embargo, que si todos los nodos ejecutan software idéntico, un adversario que identifique un exploit fatal podría en principio comprometer todos los nodos más o menos simultáneamente. Esta configuración es a menudo denominado monocultivo de software [47]. Se han presentado varias propuestas para diversificar automáticamente el software y las configuraciones de software para abordar el problema, por ejemplo, [47, 113]. Como se indica en [47], sin embargo, la diversidad de software es una cuestión compleja y requiere una consideración cuidadosa. La diversificación del software, por ejemplo, puede resultar en peor seguridad que un monocultivo si aumenta la superficie de ataque de un sistema y, por lo tanto, sus posibles vectores de ataque por encima de los beneficios de seguridad que ofrece. Creemos que el soporte para clientes de conmutación por error sólidos, es decir, clientes a los que nodos puede cambiar ante un evento catastrófico, es una forma especialmente atractiva de diversificación del software. Los clientes de conmutación por error no aumentan el número de vectores potenciales de ataque, ya que no se implementan como software principal. Ofrecen beneficios claros, sin embargo, como segunda línea de defensa. Tenemos la intención de admitir clientes de conmutación por error en DONs como un medio clave para reducir su dependencia de seguridad de un solo cliente. Chainlink ya cuenta con un sólido sistema de clientes de conmutación por error. Nuestro enfoque Implica mantener versiones de clientes anteriores y probadas en batalla. Hoy, por ejemplo, Chainlink nodos con informes fuera de cadena (OCR) como cliente principal incluyen soporte para el sistema FluxMonitor anterior de Chainlink si es necesario. Habiendo estado en uso durante algunos Al mismo tiempo, FluxMonitor ha recibido auditorías de seguridad y pruebas de campo. Proporciona lo mismo funcionalidad como OCR, solo que a un costo mayor, un costo que solo se incurre según sea necesario. 7.2.2 Informes de minorías Dado un conjunto minoritario suficientemente grande de Ominoría (una fracción de nodos honestos que observan actos ilícitos por parte de la mayoría), puede ser útil para ellos generar una minoría. informe. Este es un informe o indicador paralelo, transmitido a un contrato SC dependiente en la cadena. por Ominoría. SC puede hacer uso de esta bandera de acuerdo con su propia política específica del contrato. Por ejemplo, para un contrato en el que la seguridad es más importante que la vivacidad o la capacidad de respuesta, un informe minoritario podría hacer que el contrato solicite informes complementarios. desde otro DON, o active un disyuntor (consulte la siguiente sección).Los informes de las minorías pueden desempeñar un papel importante incluso cuando la mayoría es honesta, porque cualquier esquema de agregación de informes, incluso si utiliza firmas funcionales, debe operar de manera umbral, para garantizar la resiliencia contra oracle o fallas de datos. en En otras palabras, debe ser posible producir un informe válido basado en los datos aportados por kS < nS oracles, para algún umbral kS. Esto significa que un DON corrupto tiene alguna latitud en la manipulación de los valores del informe seleccionando sus valores kS preferidos entre los nS informado en V por el conjunto completo de oracles, incluso si todas las fuentes son honestas. Por ejemplo, supongamos que nS = 10 y kS = 7 en un sistema que utiliza un funcional firma para autenticar el cálculo de la mediana sobre V para el precio en USD de ETH. Supongamos que cinco fuentes informan un precio de \(500, while the other five report \)1000. Luego, al medianar los 7 informes más bajos, el DON puede generar un valor válido v = $500, y al medianar el más alto, puede generar v = $1000. Al mejorar el protocolo DON para que todos los nodos sepan qué datos se disponibles, y qué datos se utilizaron para construir un informe, los nodos podrían detectar y marcar tendencias estadísticamente significativas a favorecer un conjunto de informes sobre otro, y producir como resultado un informe minoritario. 7.3 Barandillas Nuestro modelo de confianza para DONs trata a MAINCHAIN como una cadena de mayor seguridad y mayores privilegios. sistema que DONs. (Aunque este modelo de confianza puede no ser siempre cierto, es más fácil para adaptar el mecanismo resultante a situaciones en las que DON es la seguridad más alta plataforma que viceversa.) Por lo tanto, una estrategia natural de minimización de la confianza implica la implementación de mecanismos de monitoreo y seguridad en smart contracts, ya sea en una interfaz MAINCHAIN para un DON o directamente en un SC de contrato dependiente. Nos referimos a estos mecanismos como barandillas y enumeramos aquí algunas de las más importantes: • Disyuntores: el SC puede pausar o detener las actualizaciones de estado en función de las características de las actualizaciones de estado mismas (por ejemplo, gran variación entre secuencias). informes) o basados en otros insumos. Por ejemplo, un disyuntor podría dispararse en casos en los que los informes oracle varían de manera inverosímil con el tiempo. Un disyuntor podría también se verán afectados por un informe minoritario. Por lo tanto, los disyuntores pueden evitar que DONs de hacer informes tremendamente erróneos. Los disyuntores pueden dar tiempo para considerar intervenciones adicionales o ejercitado. Una de esas intervenciones son las trampillas de escape. • Trampillas de escape: en circunstancias adversas, identificadas por un conjunto de custodios, titulares de la comunidad token u otros órganos de fideicomisarios, un contrato puede invocar una instalación de emergencia a veces llamada trampilla de escape [163]. Una trampilla de escape hace que SC se cierre de alguna manera y/o termina pendiente y posiblemente transacciones futuras. Por ejemplo, puede devolver fondos custodiados a los usuarios [17]),puede rescindir los términos del contrato [162], o puede cancelar transacciones pendientes y/o futuras [173]. Las trampillas de escape se pueden implementar en cualquier tipo de contrato, no solo uno que se basa en un DON, pero son de interés como un potencial amortiguador contra DON mala conducta. • Conmutación por error: en sistemas donde SC depende del DON para servicios esenciales, es posible que SC proporcione mecanismos de conmutación por error que garanticen la continuidad del servicio incluso en el caso de DON falla o mala conducta. Por ejemplo, en el TEF (Sección 6), El contrato ancla SCa puede proporcionar interfaces duales donde tanto en cadena como Las interfaces de ejecución fuera de la cadena son compatibles con ciertas operaciones críticas (p. ej., retiro), o para transacciones ordinarias, con un retraso adecuado para evitar el avance de DON transacciones. En los casos en que las fuentes de datos firmen datos, los usuarios podrían también proporcionar informes a SCa cuando el DON no lo haga. Pruebas de fraude, como se propone para diversas formas de rollup optimista (consulte la Sección 6.3), son similares en sabor y complementarios a los mecanismos que enumeramos anteriormente. ellos también proporciona una forma de monitoreo en cadena y protección contra posibles fallas en componentes del sistema fuera de cadena. 7.4 Gobernanza minimizada en la confianza Como todos los sistemas descentralizados, la red Chainlink requiere mecanismos de gobernanza para ajustar parámetros en el tiempo, responder a emergencias y guiar su evolución. Algunos de estos mecanismos residen actualmente en MAINCHAIN y pueden continuar hágalo incluso con la implementación de DONs. Un ejemplo es el mecanismo de pago. para oracle proveedores de nodos (DON nodos). DON contratos front-end en MAINCHAIN contener mecanismos adicionales, como barandillas, que pueden estar sujetos a revisiones periódicas. modificación. Prevemos dos clases de mecanismos de gobernanza: evolutivos y de emergencia. Gobernanza evolutiva: Muchas modificaciones al ecosistema Chainlink son de manera que su implementación no sea un asunto de urgencia: Mejoras en el desempeño, mejoras de funciones, actualizaciones de seguridad (no urgentes), etc. A medida que Chainlink avanza progresivamente hacia aún más participantes en su gobernanza, esperamos que muchos o la mayoría de estos cambios deben ser ratificados por la comunidad de un DON específico afectado por esos cambios. Mientras tanto, y tal vez en última instancia como un mecanismo paralelo, creemos que una noción de privilegio temporal mínimo puede ser un medio útil para implementar una gobernanza evolutiva. Muy simple, la idea es que los cambios se implementen gradualmente, asegurando a la comunidad la oportunidad de responderles. Por ejemplo, la migración a un nuevo El contrato MAINCHAIN se puede restringir para que el nuevo contrato deba implementarse al menos treinta días antes de la activación.Gobernanza de emergencia: Vulnerabilidades explotables o explotadas en MAINCHAIN Los contratos u otras formas de vida o fallas de seguridad pueden requerir una intervención inmediata para prevenir resultados catastróficos. Nuestra intención es apoyar una multifirma mecanismo de intervención en el que, para garantizar contra malas prácticas por parte de cualquier organización, los firmantes estarán dispersos entre las organizaciones. Garantizar la disponibilidad constante de firmantes y acceso oportuno a las cadenas de mando apropiadas para la autorización de emergencias. Los cambios requerirán claramente una cuidadosa planificación operativa y revisiones periódicas. estos Los desafíos son similares a los involucrados en probar otras respuestas a incidentes de ciberseguridad. capacidades [134], con una necesidad similar de combatir problemas comunes como la disminución de la vigilancia [223]. La gobernanza de DONs difiere de la de muchos sistemas descentralizados en su grado potencial de heterogeneidad. Cada DON puede tener distintas fuentes de datos, ejecutables, requisitos de nivel de servicio como tiempo de actividad y usuarios. La red Chainlink Los mecanismos de gobernanza deben ser lo suficientemente flexibles para dar cabida a tales variaciones en objetivos y parámetros operativos. Estamos explorando activamente ideas de diseño y planeamos publicar investigaciones sobre este tema en el futuro. 7.5 Infraestructura de clave pública Con la descentralización progresiva surgirá la necesidad de una identificación sólida de participantes de la red, incluidos los nodos DON. En particular, Chainlink requiere una fuerte Infraestructura de clave pública (PKI). Una PKI es un sistema que vincula claves a identidades. Para Por ejemplo, una PKI sustenta el sistema de conexiones seguras (TLS) de Internet: cuando se conecta a un sitio web a través de HTTPS (por ejemplo, https://www.chainlinklabs.com) y un aparece un candado en su navegador, eso significa que la clave pública del propietario del dominio ha sido estado vinculado a ese propietario por una autoridad, específicamente, a través de una firma digital en el llamado certificado. Un sistema jerárquico de autoridades certificadoras (CA), cuyas autoridades raíz de nivel superior están integradas en los navegadores más populares, ayuda a garantizar que los certificados se emiten únicamente a los propietarios legítimos de los dominios. Esperamos que Chainlink eventualmente haga uso de servicios de nombres descentralizados, Inicialmente el Ethereum Name Service (ENS) [22], como base de nuestra PKI. como Como sugiere su nombre, ENS es análogo a DNS, el sistema de nombres de dominio que asigna (legibles por humanos) a direcciones IP en Internet. Sin embargo, ENS asigna nombres Ethereum legibles por humanos a direcciones blockchain. Porque ENS opera en el Ethereum blockchain, salvo compromiso clave, manipulación de su El espacio de nombres es, en principio, tan difícil como alterar el contrato que lo administra. y/o el blockchain subyacente. (DNS, por el contrario, históricamente ha sido vulnerable hasta suplantación de identidad, secuestro y otros ataques). Hemos registrado data.eth con ENS en la red principal Ethereum y tenemos la intención de establecerlo como un espacio de nombres raíz bajo el cual las identidades de los servicios de datos oracle y residen otras Chainlink entidades de red. Los dominios en ENS son jerárquicos, lo que significa que cada dominio puede contener referencias. a otros nombres bajo él. Los subdominios en ENS pueden servir como una forma de organizar ydelegar confianza. La función principal de data.eth será servir como un servicio de directorio en cadena para fuentes de datos. Tradicionalmente, los desarrolladores y usuarios de oracles han utilizado fuentes fuera de la cadena (por ejemplo, sitios web como docs.chain.link o data.chain.link, o redes sociales como Twitter) para publicar y obtener oracle direcciones de alimentación de datos (como el precio ETH-USD alimento). Con un espacio de nombres raíz altamente confiable como data.eth, es posible establecer una asignación de eth-usd.data.eth a, por ejemplo, la dirección smart contract de un agregador de red en cadena oracle para el precio de ETH-USD. esto seria crear un camino seguro para que cualquiera pueda referirse al blockchain como la fuente de la verdad para esa fuente de datos de ese par precio/nombre (ETH-USD). En consecuencia, tal uso de ENS obtiene dos beneficios que no están disponibles en las fuentes de datos fuera de la cadena: • Seguridad sólida: todos los cambios y actualizaciones del dominio se registran de forma inmutable y protegido criptográficamente, a diferencia de las direcciones de texto en un sitio web, que no disfrutar de ninguna de estas dos propiedades de seguridad. • Propagación automatizada en cadena: las actualizaciones de la dirección subyacente del smart contract de una fuente de datos pueden activar notificaciones que se propagan a las direcciones inteligentes dependientes. contratos y puede, por ejemplo, actualizar automáticamente los contratos dependientes con las nuevas direcciones.13 Sin embargo, los espacios de nombres como ENS no validan automáticamente la propiedad legítima. de nombres afirmados. Así, por ejemplo, si el espacio de nombres incluye la entrada ⟨“Acme Oracle Node Co.”, dirección⟩, entonces el usuario obtiene la seguridad de que la dirección pertenece al reclamante del nombre Acme Oracle Node Co. Sin mecanismos adicionales en torno a la administración del espacio de nombres, sin embargo, no obtiene seguridad de que el nombre pertenezca a una entidad legítimamente llamado Acme Oracle Node Co. en un sentido significativo del mundo real. Nuestro enfoque para la validación de nombres, es decir, garantizar su propiedad por parte de entidades correspondientes y legítimas del mundo real, se basa en varios componentes. Hoy, Chainlink Laboratorios actúa efectivamente como una CA para la red Chainlink. Mientras que Chainlink Labs continuará Para validar nombres, nuestra PKI evolucionará hacia un modelo más descentralizado de dos maneras: • Modelo de red de confianza: la contraparte descentralizada de una PKI jerárquica a menudo se denomina red de confianza.14 Se han propuesto variantes desde la década de 1990, por ejemplo, [98], y varios investigadores han observado que los blockchain pueden facilitar el uso de la idea, por ejemplo, [227] al registrar certificados en un formato globalmente consistente. libro mayor. Estamos explorando variantes de este modelo para validar las identidades de entidades. en la red Chainlink de forma más descentralizada. 13Un contrato dependiente puede incluir opcionalmente un retraso predeterminado para permitir la inspección manual e intervención de administradores de contratos dependientes. 14Término acuñado por Phil Zimmermann para PGP [238].• Vinculación con datos de validación: hoy en día, una cantidad sustancial de oracle datos de rendimiento del nodo son visibles en la cadena y, por lo tanto, están vinculados archivadamente a las direcciones de los nodos. Se puede considerar que dichos datos enriquecen una identidad en la PKI al proporcionar evidencia histórica de su participación (confiable) en la red. Además, herramientas para identidad descentralizada basada en DECO y Town Crier [160] habilitar nodos para acumular credenciales derivadas de datos del mundo real. Como sólo un ejemplo, un El operador del nodo puede adjuntar una credencial a su identidad PKI que demuestre la posesión. de una calificación de Dun y Bradstreet. Estas formas complementarias de validación pueden Complemente staking para crear garantías de seguridad de la red. Se puede considerar que un nodo oracle con una identidad establecida en el mundo real tiene interés en un sistema derivado de su reputación. (Consulte la Sección 4.3 y la Sección 9.6.3.) Un requisito final para la PKI Chainlink es el arranque seguro, es decir, publicar el nombre raíz de la red Chainlink, actualmente data.eth (de manera análoga al cableado de dominios de nivel superior en los navegadores). En otras palabras, ¿cómo funcionan los usuarios Chainlink? determinar que data.eth es de hecho el dominio de nivel superior asociado con Chainlink proyecto? La solución a este problema para la red Chainlink es múltiple y puede implicar: • Agregar un registro TXT [224] a nuestro registro de dominio para chain.link que especifica data.eth como dominio raíz para el ecosistema Chainlink. (Por lo tanto, Chainlink aprovecha implícitamente la PKI para dominios de Internet para validar su dominio ENS raíz). • Enlace a data.eth desde el sitio web existente de Chainlink, por ejemplo, desde https://docs.chain.link. (Otro uso implícito de la PKI para dominios de Internet). • Dar a conocer el uso de data.eth a través de varios documentos, incluido este documento técnico. • Publicar data.eth públicamente en nuestros canales de redes sociales, como Twitter, y el blog Chainlink [18]. • Colocar una gran cantidad de LINK bajo el control de la misma dirección del registrante como datos.eth.

DON Consideraciones de implementación

Si bien no forma parte de nuestro diseño principal, existen varias consideraciones técnicas importantes. en la realización de DONs que merecen tratamiento aquí.

8.1 Enfoque de implementación Este documento presenta una visión ambiciosa de la funcionalidad avanzada Chainlink cuya Su realización requerirá soluciones a muchos desafíos a lo largo del camino. Este documento técnico identifica algunos desafíos, pero seguramente surgirán otros imprevistos. Planeamos implementar elementos de esta visión de manera incremental a lo largo de un período de tiempo prolongado. Nuestra expectativa es que DONs se lance inicialmente con soporte para componentes prediseñados específicos creados en colaboración por equipos dentro del Chainlink comunidad. La intención es que usos más amplios de DONs, por ejemplo, la capacidad de lanzar ejecutables arbitrarios, recibirá soporte más adelante. Una razón para tal precaución es que la composición de smart contracts puede tener efectos secundarios complejos, no deseados y peligrosos, como lo han demostrado los recientes ataques basados en préstamos rápidos. por ejemplo, se muestra [127, 189]. De manera similar, la composición de smart contracts, adaptadores y Los ejecutables requerirán extremo cuidado. En nuestra implementación inicial de DONs, planeamos incluir solo un conjunto prediseñado de adaptadores y ejecutables con plantillas. Esto permitirá estudiar la seguridad composicional. de estas funcionalidades utilizando métodos formales [46, 170] y otros enfoques. lo hará también simplifica la fijación de precios: los precios de funcionalidad pueden ser establecidos por DON nodos según la funcionalidad, en lugar de mediante medición generalizada, un enfoque adoptado en, por ejemplo, [156]. También esperamos que la comunidad Chainlink participe en la creación. de plantillas adicionales, combinando varios adaptadores y ejecutables en cada vez más Servicios descentralizados útiles que pueden ser ejecutados por cientos, si no miles, de personas individuales. DONs. Además, este enfoque puede ayudar a prevenir la inflación estatal, es decir, la necesidad de DON nodos para retener una cantidad inviable de estado en la memoria de trabajo. Este problema es que ya están surgiendo en blockchains sin permiso, motivando enfoques como "apátridas clientes” (ver, por ejemplo, [206]). Puede ser más agudo en sistemas de mayor rendimiento, lo que motiva un enfoque en el que DON implementa solo ejecutables de tamaño optimizado. A medida que los DON evolucionan y maduran e incluyen barreras de seguridad sólidas, como se analiza en la Sección 7, mecanismos de seguridad criptoeconómicos y basados en la reputación, como se analiza en la Sección 9, y otras características que brindan un alto grado de seguridad para los usuarios de DON, nosotros También esperamos desarrollar un marco y herramientas para facilitar un lanzamiento y uso más amplio de DONs por la comunidad. Idealmente, estas herramientas permitirán una colección de operadores de nodos. unirse como una red oracle y lanzar sus propios DONs en una red sin permiso o de autoservicio, es decir, que pueden hacerlo unilateralmente. 8.2 Membresía dinámica DON El conjunto de nodos que ejecutan un DON determinado puede cambiar con el tiempo. Hay dos enfoques a la gestión de claves para skL dada la membresía dinámica en O. El primero es actualizar las acciones de skL en poder de los nodos ante cambios en la membresía, manteniendo pkL sin cambios. Este enfoque, explorado en [41, 161, 198], tiene el mérito de no exigir que las partes que confían actualicen pkL.La técnica clásica de compartir acciones, introducida en [122], proporciona una forma sencilla y eficiente de realizar dichas actualizaciones de recursos compartidos. Permite transferir un secreto. entre un conjunto de nodos O(1) y un segundo, posiblemente intersectando uno O(2). en esto enfoque, cada nodo O (1) yo realiza un intercambio secreto (k(2), n(2)) de su parte secreta a través nodos en O(2) para n(2) = |O(2)| y el umbral deseado (posiblemente nuevo) k(2). Varios esquemas de intercambio de secretos verificables (VSS) [108] pueden brindar seguridad contra un adversario que corrompe activamente los nodos, es decir, introduce un comportamiento malicioso en el protocolo. Las técnicas en [161] tienen como objetivo hacerlo mientras reducen la complejidad de la comunicación y brindan resiliencia contra fallas en los supuestos de dureza criptográfica. Un segundo enfoque consiste en actualizar la clave del libro mayor pkL. Esto tiene el beneficio de avanzar seguridad: El compromiso de las acciones antiguas de pkL (es decir, los antiguos nodos del comité) no resultará en compromiso de la clave actual. Sin embargo, las actualizaciones de pkL conllevan dos inconvenientes: (1) Los datos cifrados bajo pkL deben volver a cifrarse durante una actualización de clave y (2) Las actualizaciones clave deben propagarse a las partes que confían. Tenemos la intención de explorar ambos enfoques, así como las hibridaciones de los dos. 8.3 DON Responsabilidad Al igual que con las redes Chainlink oracle existentes, las DON incluirán mecanismos de responsabilidad, es decir, registrar, monitorear y hacer cumplir el comportamiento correcto de los nodos. DONs tendrán capacidad de datos mucho más sustancial que muchos blockchains sin permiso existentes, particularmente dada su capacidad para conectarse a almacenamiento descentralizado externo. En consecuencia, podrán registrar el historial de rendimiento de los nodos en detalle, lo que permitirá mecanismos de rendición de cuentas más detallados. Por ejemplo, el cálculo fuera de cadena de Los precios de los activos pueden involucrar insumos que se descartan antes de enviar un resultado mediano. cadena. En un DON se podrían registrar estos resultados intermedios. Por lo tanto, el mal comportamiento o las fallas de rendimiento de nodos individuales en un DON se pueden remediar o penalizar en el DON de forma detallada. También hemos discutido enfoques para construir barandillas en la Sección 7.3 que abordan el impacto específico del contrato de las fallas sistémicas. Sin embargo, también es importante contar con mecanismos de seguridad para los propios DONs, es decir, protecciones contra fallas sistémicas y potencialmente catastróficas DON, específicamente errores de bifurcación/equívoco y acuerdos de nivel de servicio (SLA), como ahora explicamos. Bifurcación/equívoco: Dados suficientes nodos defectuosos, un DON puede bifurcarse o equívoco, produciendo dos bloques o secuencias de bloques distintos e inconsistentes en L. Sin embargo, debido a que un DON firma digitalmente el contenido de L, es posible aprovechar un cadena principal MAINCHAIN para prevenir y/o penalizar la equivocación. El DON puede verificar periódicamente el estado de L en un contrato de auditoría en MAINCHAIN. Si su estado futuro se desvía de un estado de control, un usuario/auditor puede presentar pruebas de esta mala conducta al contrato de auditoría. Dicha prueba se puede utilizar para generar una alerta. o penalizar DON nodos mediante reducción en el contrato. Este último enfoque introduce un problema de diseño de incentivos similar al de feeds específicos oracle, y puede basarse en nuestro trabajo descrito en la Sección 9.Hacer cumplir los acuerdos de nivel de servicio: Si bien los DONs no necesariamente están destinados a funcionan indefinidamente, es importante que cumplan con los acuerdos de nivel de servicio (SLA) con sus usuarios. La aplicación básica de SLA es posible en una cadena principal. Por ejemplo, Los nodos DON podrían comprometerse a mantener el DON hasta una fecha determinada, o a proporcionar un aviso previo de la terminación del servicio (por ejemplo, un aviso de tres meses). un contrato sobre MAINCHAIN puede proporcionar cumplimiento básico de SLA criptoeconómico. Por ejemplo, el contrato SLA puede recortar DON fondos depositados si los puntos de control son no se proporciona en los intervalos requeridos. Un usuario puede depositar fondos y desafiar el DON para demostrar que un punto de control representa correctamente una secuencia de bloques válidos (de una manera análogo a, p.e. [141]). Por supuesto, la producción en bloque no equivale a la transacción. procesamiento, pero el contrato SLA también puede servir para hacer cumplir este último. Por ejemplo, en En la versión heredada de FSS compatible con la cual las transacciones se obtienen del mempool (consulte la Sección 5.2), las transacciones finalmente se extraen y se colocan en la cadena. un usuario puede probar DON mala conducta proporcionando al contrato SLA una transacción que fue minado pero no fue transmitido por DON para su procesamiento por el contrato de destino dentro del intervalo de tiempo apropiado.15 También es posible probar la existencia de SLA más detallados y penalizarlos. fallas, incluidos errores en el cálculo utilizando ejecutables (a través de, por ejemplo, los mecanismos para demostrar transacciones de estado fuera de la cadena correctas descritas en la Sección 6.3) o no ejecutar ejecutables basados en iniciadores visibles en un DON, falla al transmitir datos en el DON a MAINCHAIN de manera oportuna, etc.

Economía y criptoeconomía

Para que la red Chainlink logre una seguridad sólida dentro de un modelo de confianza descentralizado, Es esencial que los nodos exhiban colectivamente un comportamiento correcto, lo que significa que se adhieren. la mayoría de las veces exactamente a los protocolos DON. En esta sección, analizamos enfoques para ayudar a imponer dicho comportamiento mediante incentivos económicos, también conocidos como criptoeconómicos. incentivos. Estos incentivos se dividen en dos categorías: explícitos e implícitos, realizados respectivamente a través de staking y oportunidad de pago futuro (FFO). Replanteo: Apostar en Chainlink, como en otros sistemas blockchain, involucra a los participantes de la red, es decir, oracle nodos, que depositan fondos bloqueados en forma de ENLACE tokens. estos Los fondos, a los que también nos referimos como participación o participación explícita, son un incentivo explícito. ellos están sujetos a confiscación en caso de falla o mala conducta del nodo. En el contexto blockchain, Este procedimiento a menudo se llama corte. Sin embargo, el replanteo de oracle nodos en Chainlink difiere fundamentalmente de staking por validators en blockchains sin permiso. Los validadores pueden comportarse mal al ordenar transacciones de manera ambigua o contradictoria. El protocolo de consenso subyacente en un 15Dado que los usuarios pueden reemplazar transacciones en el mempool, se requiere cuidado para garantizar una correspondencia correcta entre las transacciones extraídas y las enviadas DON.Sin embargo, blockchain sin permiso utiliza reglas estrictas y rápidas de validación de bloques y primitivas criptográficas para evitar que validators generen bloques no válidos. En contraste, Las protecciones programáticas no pueden evitar que una red engañosa oracle genere informes inválidos. La razón es una diferencia clave entre los dos tipos de sistema: la validación de transacciones en blockchains es una propiedad de coherencia interna, mientras que la corrección de oracle informes sobre un blockchain es una propiedad de datos externos, es decir, fuera de la cadena. Hemos diseñado un mecanismo preliminar staking para la red Chainlink basado en un protocolo interactivo entre oracle nodos que pueden hacer uso de datos externos. esto mecanismo crea incentivos financieros para el comportamiento correcto utilizando recompensas explícitas y sanciones (corte). Como el mecanismo es económico, está diseñado para evitar que los nodos corrupción por parte de un adversario que utiliza recursos financieros para corromper nodos mediante soborno. (Tal adversario es muy general y se extiende, por ejemplo, a nodos que cooperan para extraer valor de su mala conducta colectiva.) El mecanismo Chainlink staking que hemos diseñado tiene algunas potentes y novedosas características.16 La característica principal es el impacto superlineal staking (específicamente, cuadrático). Un adversario debe tener recursos considerablemente superiores a los fondos depositados de los nodos en para subvertir el mecanismo. Nuestro mecanismo staking proporciona además protección contra un adversario más fuerte que el considerado anteriormente en sistemas similares, a saber un adversario que puede crear sobornos condicionando el comportamiento futuro de los nodos. Además, analizamos cómo Chainlink herramientas como DECO pueden ayudar a fortalecer nuestra staking mecanismo al facilitar la adjudicación correcta en el caso de un comportamiento defectuoso del nodo. Oportunidad de pago futuro (FFO): blockchains sin permiso, tanto del PoW y variedad de PoS: hoy dependen fundamentalmente de lo que llamamos incentivos implícitos. Estos son incentivos económicos para el comportamiento honesto que no derivan de recompensas explícitas, sino de la propia participación en la plataforma. Por ejemplo, la comunidad minera Bitcoin está incentivada a no montar un ataque del 51% por el riesgo de socavar la confianza en Bitcoin, deprimiendo su valor y, en consecuencia, erosionando el valor de su colectivo. inversiones de capital en infraestructura minera [150]. La red Chainlink se beneficia de un incentivo implícito similar al que nos referimos como oportunidad de pago futuro (FFO). Nodos de Oracle con sólidos historiales de rendimiento o las reputaciones atraen tarifas de los usuarios. El mal comportamiento de un nodo oracle pone en peligro el futuro pagos de tarifas y, por lo tanto, penaliza al nodo con un costo de oportunidad en términos de potencial Ingresos obtenidos a través de la participación en la red. Por analogía con la apuesta explícita, El FFO puede verse como una forma de participación implícita, un incentivo para un comportamiento honesto que deriva del beneficio compartido de mantener la confianza en la plataforma en la que El negocio de los operadores de nodos depende, es decir, el desempeño positivo y la reputación del red. Este incentivo es inherente pero no se expresa explícitamente en la red Chainlink protocolos. En Bitcoin, manteniendo el valor de las operaciones mineras como se mencionó anteriormente 16El mecanismo staking que describimos aquí actualmente solo tiene como objetivo exigir la entrega de informes correctos. por redes oracle. Esperamos que en trabajos futuros se amplíe para garantizar la correcta ejecución de los muchos otras funcionalidades que proporcionará DONs.De manera similar, puede verse como una forma de participación implícita. Destacamos que FFO ya existe en Chainlink y ayuda a proteger la red. hoy. Nuestra principal contribución en el desarrollo posterior de Chainlink será un enfoque basado en principios y empíricamente para evaluar incentivos implícitos como el FFO a través de lo que llamamos el Marco de Incentivos Implícitos (MII). Para estimar cantidades como la futura oportunidad de pago de los nodos, el IIF aprovechará continuamente la experiencia integral datos de rendimiento y pago recopilados por la red Chainlink. Tales estimaciones permitirá la parametrización basada en IIF de los sistemas staking que refleja los incentivos de los nodos con mayor precisión que los modelos heurísticos y/o estáticos actuales. Para resumir, entonces, los dos principales incentivos económicos para el nodo oracle correcto El comportamiento en la red Chainlink en desarrollo será: • Stake (participación depositada) oh Incentivo explícito • Oportunidad de pago futuro (FFO) oh Incentivo implícito Estas dos formas de incentivo son complementarias. Los nodos de Oracle pueden simultáneamente participar en el protocolo Chainlink staking, disfrutar de un flujo de ingresos continuo de usuarios y beneficiarnos colectivamente de su buen comportamiento continuo. Así, ambos incentivos contribuir a la seguridad criptoeconómica proporcionada por una red oracle. Además, Los dos incentivos pueden reforzarse y/o intercambiarse entre sí. Por ejemplo, un nuevo operador oracle sin un historial de rendimiento y un flujo de ingresos puede apostar una gran cantidad de LINK como garantía de comportamiento honesto, atrayendo así a los usuarios y honorarios. Por el contrario, un operador oracle establecido con una larga y relativamente libre de fallas El historial de rendimiento puede cobrar tarifas sustanciales a una gran base de usuarios y, por lo tanto, depender más fuertemente en su FFO como una forma de incentivo implícito. En general, el enfoque que consideramos aquí apunta a una cantidad determinada de oracle-red recurso para crear los mayores incentivos económicos posibles en Chainlink para fines racionales agentes (es decir, nodos que maximizan su utilidad financiera) se comporten con honestidad. pon otro De esta manera, el objetivo es maximizar los recursos financieros necesarios para que un adversario ataque. la red con éxito. Al formular un protocolo staking con matemáticamente bien seguridad económica definida y también utilizando el IIF, nuestro objetivo es medir la fuerza de Los incentivos de Chainlink con la mayor precisión posible. Los creadores de contratos de confianza entonces podrá determinar con gran confianza si una red oracle cumple sus niveles requeridos de seguridad criptoeconómica. El círculo virtuoso de la seguridad económica: Los incentivos que analizamos en esta sección, staking y FFO, tienen un impacto más allá de su refuerzo de la seguridad de DONs. Prometen inducir lo que llamamos un círculo virtuoso de seguridad económica. El impacto superlineal staking (y otras economías de escala) dan como resultado menores niveles operativos. costo a medida que crece la seguridad de DON. El menor costo atrae usuarios adicionales al DON,impulsar el pago de tasas. El aumento de los pagos de tasas sigue incentivando el crecimiento de la red, que perpetúa el círculo virtuoso. Creemos que el círculo virtuoso de la seguridad económica es sólo un ejemplo de una economía de escala y efecto de red, entre otros que analizamos más adelante en esta sección. Organización de la sección: El replanteo presenta desafíos técnicos y conceptuales notables para para el cual hemos diseñado un mecanismo con características novedosas. Por lo tanto, apostar será nuestro enfoque principal en esta sección. Ofrecemos una descripción general del enfoque staking que presentamos en este documento en la Sección 9.1, seguido de una discusión detallada en las Secciones 9.2 a 9.5. Presentamos el IFF en la Sección 9.6. Presentamos una vista resumida de los incentivos de la red Chainlink en la Sección 9.7. En la Sección 9.8, analizamos el círculo virtuoso de seguridad económica que nuestro enfoque propuesto staking puede aportar a las redes oracle. Finalmente, describimos brevemente otros potenciales efectos que impulsan el crecimiento de la red Chainlink en la Sección 9.9. 9.1 Resumen de apuestas El diseño del mecanismo staking que presentamos aquí, como se señaló anteriormente, implica un protocolo interactivo entre los nodos oracle que permite la resolución de inconsistencias en el presentación de informes de datos externos. La apuesta tiene como objetivo garantizar un comportamiento honesto de los nodos oracle racionales. Por lo tanto, podemos modelar un adversario que ataca un protocolo staking como un Sobornador: La estrategia del adversario es corromper oracle nodos utilizando incentivos financieros. El adversario puede obtener recursos financieros prospectivamente de la manipulación exitosa con un informe oracle, por ejemplo, ofrecer compartir las ganancias resultantes con nodos corruptos. En el diseño de nuestro mecanismo staking apuntamos simultáneamente a dos objetivos ambiciosos: 1. Resistir a un adversario poderoso: el mecanismo staking está diseñado para proteger oracle redes contra una amplia clase de adversarios que son capaces de realizar ataques complejos, Estrategias de soborno condicional, incluido el soborno potencial, que ofrece sobornos. a oracles cuyas identidades se determinan después del hecho (por ejemplo, ofrece sobornos a oracles seleccionados aleatoriamente para alertas de alta prioridad). Mientras que otros diseños oracle han considerado un conjunto limitado de ataques sin las capacidades completas de una estrategia realista. adversario, hasta donde sabemos, el mecanismo adversarial que introducimos Aquí está el primero que aborda explícitamente un amplio conjunto de estrategias de soborno y muestra resistencia en este modelo. Nuestro modelo supone que los nodos además del atacante son económicamente racional (a diferencia de honesto), y asumimos la existencia de un fuente de verdad que es prohibitivamente costosa para el uso típico pero que está disponible en caso de desacuerdo (que se analiza más adelante). 2. Lograr un impacto staking superlineal: Nuestro objetivo es garantizar que una red oracle compuesta por agentes racionales informe Sinceramente, incluso en presencia de un atacante con un presupuesto superlineal.en la participación total depositada por toda la red. En los sistemas staking existentes, si cada uno de los n nodos apuesta $d, un atacante puede emitir un soborno creíble que solicita que los nodos se comporten de manera deshonesta a cambio de un pago de poco más de \(d to each node, using a total budget of about \)dn. Este ya es un listón muy alto el atacante debe tener un presupuesto líquido del orden de los depósitos combinados de todos los interesados en la red. Nuestro objetivo es un grado aún mayor de seguridad económica que este obstáculo ya importante. Nuestro objetivo es diseñar el primer sistema staking que puede lograr seguridad para un atacante general con un presupuesto superlineal en n. Si bien las consideraciones prácticas pueden lograr un impacto menor, como veremos a continuación, nuestro diseño preliminar logra un requisito presupuestario contradictorio mayor que $dn2/2, es decir, escalar cuadráticamente en n, lo que hace que el soborno sea en gran medida poco práctico incluso cuando los nodos apuestan solo cantidades moderadas. Alcanzar estos dos objetivos requiere una combinación innovadora de diseño de incentivos. y criptografía. Ideas clave: Nuestro enfoque staking depende de una idea que llamamos prioridad de vigilancia. Un informe generado por una red Chainlink oracle y enviado a un contrato de confianza (por ejemplo, sobre el precio de un activo) se agrega a partir de informes individuales aportados por los nodos participantes (por ejemplo, tomando la mediana). Normalmente, un acuerdo de nivel de servicio (SLA) especifica límites aceptables de desviación para los informes, es decir, hasta qué punto el informe de un nodo puede desviarse del informe agregado y hasta qué punto se debe permitir que el agregado desviarse del valor real para ser considerado correcto. En nuestro sistema staking, para una ronda de informes determinada, cada nodo oracle puede actuar como un organismo de control para generar una alerta si cree que el informe agregado es incorrecto. en cada ronda de informes, a cada nodo oracle se le asigna una prioridad pública que determina la orden en que se procesará su alerta (si corresponde). Nuestro mecanismo apunta a la recompensa. concentración, lo que significa que el perro guardián con mayor prioridad para generar una alerta gana el La recompensa completa se obtiene al confiscar los depósitos de los nodos defectuosos. Nuestros diseños de sistema staking involucran dos niveles: el primero, el nivel predeterminado, y el segundo, nivel de respaldo. El primer nivel es la propia red oracle, un conjunto de n nodos. (Para simplificar, asumimos que n es impar.) Si la mayoría de los nodos informan valores incorrectos, un perro guardián en el El primer nivel está fuertemente incentivado a generar una alerta. Si se genera una alerta, el informe La decisión de la red luego se escala a un segundo nivel: un sistema de alto costo y máxima confiabilidad que el usuario puede especificar en el acuerdo de nivel de servicio de la red. Este podría ser un sistema que, por ejemplo, esté compuesto sólo por nodos con fuertes puntuaciones de confiabilidad histórica, o una que tenga un orden de magnitud más oracles que el primer nivel. Además, como se analiza en la Sección 9.4.3, DECO o Town Pregonero pueden servir como herramientas poderosas para ayudar a garantizar una adjudicación eficiente y concluyente en el segundo nivel. Por simplicidad, asumimos que este sistema de segundo nivel llega a un informe correcto. valor. Si bien puede parecer atractivo confiar simplemente en el segundo nivel para generar todos los informes, El beneficio de nuestro diseño es que logra consistentemente las propiedades de seguridad delsistema de segundo piso pagando sólo el costo operativo, en el caso típico, del sistema de primer nivel. La prioridad de vigilancia da como resultado un impacto superlineal staking de la siguiente manera: si el La red de primer nivel oracle genera un resultado incorrecto y varios nodos de vigilancia alerta, el mecanismo de incentivo staking recompensa al organismo de control de mayor prioridad con más de $dn/2 extraídos de los depósitos de los (mayoría) nodos que se comportan mal. el la recompensa total se concentra así en manos de este único perro guardián, que por lo tanto determina el mínimo que un adversario debe prometer a un potencial organismo de control para incentivarlo a no alertar. Dado que nuestro mecanismo garantiza que cada oracle obtenga el oportunidad de actuar como perro guardián si los perros guardianes de mayor prioridad han aceptado sus sobornos (y decidió no alertar), el adversario debe, por lo tanto, ofrecer un soborno de más de $dn/2 a cada nodo para evitar que se genere alguna alerta. Como hay n nodos, el El presupuesto requerido por el adversario para un soborno exitoso asciende a más de $dn2/2, lo que es cuadrático en el número n de nodos de la red. 9.2 Antecedentes Nuestro enfoque para staking se basa en investigaciones en los campos de la teoría y el mecanismo de juegos. diseño (MD) (para obtener una referencia de un libro de texto, consulte [177]). La teoría de juegos es matemáticamente estudio formalizado de interacción estratégica. En este contexto, un juego es un modelo de tal una interacción, típicamente en el mundo real, que codifica conjuntos de acciones disponibles para participantes en el juego, conocidos como jugadores. Un juego también especifica los pagos obtenidos. por los jugadores individuales: recompensas que dependen de las acciones elegidas por un jugador y de la acciones de los demás jugadores. Quizás el ejemplo más conocido de un juego estudiado en el juego. La teoría es el dilema del prisionero [178]. Los teóricos de juegos generalmente intentan comprender el equilibrio o equilibrios (si los hay) representados en un juego dado. Un equilibrio es un conjunto de estrategias (una para cada jugador) tal que ningún jugador pueda obtener una mayor obtener ganancias al desviarse unilateralmente de su estrategia. Mientras tanto, el diseño de mecanismos es la ciencia de diseñar incentivos tales que el El equilibrio de una interacción (y su juego asociado) tiene alguna propiedad deseable. La MD puede verse como lo contrario de la teoría de juegos: la cuestión canónica en el juego La teoría es: "dados los incentivos y el modelo, ¿cuál será el equilibrio?" En MD, el La pregunta más bien es: “¿qué incentivos darán como resultado un juego con un equilibrio deseable?” Un objetivo típico de un diseñador de mecanismos es crear un mecanismo "compatible con incentivos", lo que significa que los participantes en el mecanismo (por ejemplo, una subasta u otra información sistema de obtención de información [228]) están incentivados a informar la verdad sobre algún asunto (por ejemplo, cómo cuánto valoran un artículo en particular). La subasta de Vickrey (segundo precio) es quizás la mecanismo compatible con incentivos más conocido, en el que los participantes presentan ofertas selladas por un artículo y el mejor postor gana el artículo pero paga el segundo precio más alto [214]. La criptoeconomía es una forma de MD de dominio específico que aprovecha la criptografía. técnicas para crear equilibrios deseables dentro de los sistemas descentralizados. El soborno y la colusión crean desafíos importantes en todo el campo del MD. Casi todos los mecanismos se rompen en presencia de colusión, definida como contratos secundarios entreentre las partes que participan en un mecanismo [125, 130]. El soborno, en el que una parte externa introduce incentivos novedosos en el juego, presenta un problema aún más difícil. que la colusión; La colusión puede verse como un caso especial de soborno entre jugadores. participantes. Los sistemas blockchain a menudo pueden conceptualizarse como juegos con recompensas monetarias (basadas en criptomonedas). Un ejemplo sencillo es la minería de prueba de trabajo: los mineros tienen un espacio de acción en el que pueden elegir la hashrate con la que minar bloques. El beneficio de la minería es una recompensa negativa garantizada (coste de la electricidad y el equipo) más un factor estocástico. recompensa positiva (subsidio minero) que depende del número de otros mineros activos [106, 172] y tarifas de transacción. Los oracle de colaboración colectiva como SchellingCoin [68] son otro ejemplo: el espacio de acción es el conjunto de posibles informes que un oracle puede enviar, mientras el pago es la recompensa especificada por el mecanismo oracle, por ejemplo, el pago podría depender sobre qué tan cerca está el informe de oracle de la mediana de los otros informes [26, 68, 119, 185]. Los juegos blockchain ofrecen grandes oportunidades para ataques de colusión y soborno; de hecho, smart contracts pueden incluso facilitar tales ataques [96, 165]. Quizás el más conocido El ataque de soborno a oracles de colaboración colectiva es el ataque p-plus-épsilon [67]. este ataque surge en el contexto de un mecanismo similar a SchellingCoin en el que los jugadores envían informes con valores booleanos (es decir, falsos o verdaderos) y son recompensados con p si están de acuerdo con el presentación mayoritaria. En un ataque p-plus-épsilon, el atacante promete de manera creíble: por ejemplo, pagar a los usuarios $p + ϵ por votar en falso si y sólo si la presentación mayoritaria es verdadera. El resultado es un equilibrio, en el que todos los jugadores están incentivados a reportar información falsa. independientemente de lo que hagan otros jugadores; en consecuencia, el sobornador puede inducir a los nodos a través del soborno prometido para informar cosas falsas sin pagar realmente el soborno (!). Sin embargo, la exploración de otras estrategias de soborno en el contexto de los oracles (y particularmente de los oracles que no son de colaboración abierta) se ha limitado a estrategias adversas bastante débiles. modelos. Por ejemplo, en el entorno de PoW, los investigadores han estudiado sobornos, es decir, sobornos que se pagan sólo si un mensaje objetivo se censura con éxito y no aparecen en un bloque, independientemente de la acción de un minero individual [96, 165]. en el caso de oracles, sin embargo, aparte del ataque p-plus-épsilon, solo conocemos el trabajo en modelo estrictamente limitado de soborno en el que el sobornador envía un soborno condicionado a una de la acción individual del jugador, no del resultado resultante. Aquí esbozamos diseños de mecanismos de obtención de información que siguen siendo incentivos. compatible incluso en un modelo adversarial fuerte, como se describe en la siguiente subsección. 9.3 Supuestos de modelado En esta subsección, explicamos cómo modelamos el comportamiento y las capacidades de los jugadores en nuestro sistema, específicamente nodos oracle de primer nivel, nodos en el segundo nivel (adjudicación) capa y adversarios.9.3.1 Modelo de incentivos de primer nivel: actores racionales Muchos sistemas blockchain dependen de la seguridad en el supuesto de una cierta cantidad de honestidad. nodos participantes. Los nodos se definen como honestos si siguen el protocolo incluso cuando no sea de su interés financiero hacerlo. Los sistemas de prueba de trabajo generalmente requieren la mayor parte del poder hash para ser honestos, los sistemas de prueba de participación generalmente requieren 2/3 o más de toda la participación participante para ser honestos, e incluso los sistemas de capa 2 como Arbitrum [141] requiere al menos un único participante honesto. Al modelar nuestro mecanismo staking, hacemos una suposición mucho más débil. (ser Los supuestos claros y más débiles significan propiedades de seguridad más fuertes y, por lo tanto, son preferibles.) Suponemos que el adversario ha corrompido, es decir, controla, algunos (minoría) fracción de nodos oracle de primer nivel. Modelamos los nodos restantes no como agentes honestos, sino como maximizadores racionales de la utilidad esperada. Estos nodos actúan enteramente de acuerdo con incentivos financieros interesados, eligiendo acciones que resultan en un beneficio financiero esperado. ganancia. Por ejemplo, si a un nodo se le ofrece un soborno mayor que la recompensa resultante de comportamiento honesto, aceptará el soborno. Nota sobre los nodos adversarios: De acuerdo con el modelo de confianza común para En sistemas descentralizados, asumimos que todos los nodos son racionales, es decir, buscan maximizar ingresos netos, en lugar de estar controlados por un adversario malicioso. Nuestras afirmaciones, sin embargo: impacto específicamente superlineal o cuadrático staking: se mantiene asintóticamente proporcionado que el conjunto de nodos controlados adversariamente es como máximo (1/2 −c)n, para algunos positivos constante c. 9.3.2 Modelo de adjudicación de segundo nivel: corrección por suposición Recuerde que una característica crítica de nuestro mecanismo staking que ayuda a lograr la seguridad contra los nodos racionales es su sistema de segundo nivel. En nuestro mecanismo staking propuesto, cualquier oracle puede generar una alerta indicando que cree que el resultado del mecanismo es incorrecto. Una alerta genera un nivel de confianza alto. Sistema de segundo nivel que activa y reporta el resultado correcto. Por lo tanto, un modelo clave El requisito para nuestro enfoque es la adjudicación correcta, es decir, la presentación de informes correctos por parte del sistema de segundo nivel. Nuestro modelo staking supone un sistema de segundo nivel que actúa como una fuente de verdad incorruptible y máximamente confiable. Es probable que un sistema de este tipo sea caro y lento y, por tanto, inadecuado para su uso en el caso típico. Sin embargo, en el caso de equilibrio, es decir, cuando Si el sistema de primer nivel funciona correctamente, no se invocará el sistema de segundo nivel. En cambio, su existencia aumenta la seguridad de todo el sistema oracle al proporcionar una respaldo de alta seguridad. El uso de un nivel de adjudicación de alto costo y alta confianza se asemeja al proceso de apelación. en el corazón de la mayoría de los sistemas judiciales. También ya es común en el diseño de oracle sistemas, por ejemplo, [119, 185]. Discutimos brevemente los enfoques para la realización del segundo nivel. en nuestro mecanismo en la Sección 9.4.3.Nuestro protocolo staking utiliza la supuesta adjudicación correcta del sistema de segundo nivel como una amenaza creíble para imponer informes correctos por parte de los nodos oracle. el protocolo confisca parte o la totalidad de la participación de oracle nodos que generan informes identificados por el sistema de segundo nivel es incorrecto. De este modo se disuade a los nodos de Oracle de comportarse mal por la sanción económica resultante. Este enfoque es similar en sabor al utilizado en rollups optimistas, por ejemplo, [141, 10]. 9.3.3 Modelo adversario Nuestro mecanismo staking está diseñado para obtener información veraz y al mismo tiempo lograr seguridad contra una clase amplia y bien definida de adversarios. Mejora trabajos anteriores, que omiten un modelo adversarial explícito o se centran en subclases estrechas de adversarios, por ejemplo, el adversario p-plus-épsilon discutido anteriormente. Nuestro objetivo es diseñar un staking mecanismo con seguridad formalmente probada contra todo el espectro de adversarios probables que se encontrarán en la práctica. Modelamos a nuestro adversario con un presupuesto fijo (parametrizable), denotado por $B. El adversario puede comunicarse individual y confidencialmente con cada oracle en la red, y puede ofrecer en secreto a cualquier individuo oracle el pago garantizado de un soborno depende de los resultados públicamente observables del mecanismo. Resultados determinantes Los sobornos pueden incluir, por ejemplo, el valor informado por el oracle, cualquier mensaje público enviado por cualquier oracle al mecanismo (por ejemplo, una alerta), los valores informados por otros oracles y el valor generado por el mecanismo. Ningún mecanismo puede proteger contra un atacante con capacidades ilimitadas. Por lo tanto, consideramos que algunos comportamientos son poco realistas o están fuera de alcance. Asumimos que nuestro atacante no puede romper las primitivas criptográficas estándar y, como se señaló anteriormente, tiene un valor fijo (si potencialmente grande) presupuesto $B. Suponemos además que el adversario no controla comunicación en la red oracle, específicamente que no puede retrasar sustancialmente tráfico entre nodos de primer y/o segundo nivel. (Que el adversario pueda observar dicha comunicación depende del mecanismo particular, como explicamos a continuación). Sin embargo, de manera informal, como se señaló anteriormente, asumimos que el adversario puede: (1) Corromper una fracción de oracle nodos ((1/2 −c)-fracción para alguna constante c), es decir, control total ellos, y (2) Ofrecer sobornos a cualquier nodo deseado, con pago garantizado supeditado en los resultados especificados por el adversario, como se describió anteriormente. Si bien no ofrecemos un modelo formal o una taxonomía completa de la capacidad total del adversario gama de capacidades de soborno en este documento técnico, a continuación se muestran ejemplos de los tipos de sobornadores abarcados por nuestro modelo. Para simplificar, asumimos que oracles emiten valores booleanos. informes cuyo valor correcto (w.l.o.g.) es verdadero, y que un resultado final se calcula como un agregado de estos informes para ser utilizado por un consumidor smart contract. El sobornador El objetivo es que el resultado final sea incorrecto, es decir, falso. • Sobornador incondicional: El sobornador ofrece un soborno de $b a cualquier oracle que informe algo falso. • Sobornador probabilístico: El sobornador ofrece un soborno de $b con cierta probabilidad q a cualquier oracle que informa falso.• soborno condicionado por resultados falsos: el sobornador ofrece un soborno de $b a cualquier oracle que informe algo falso, siempre que el resultado final sea falso. • Sobornador sin alerta condicionada: el sobornador ofrece un soborno de $b a cualquier oracle que informe falso siempre que no se genere ninguna alerta. • Sobornador p-plus-epsilon: El sobornador ofrece un soborno de $b a cualquier oracle que reporte datos falsos como siempre y cuando la mayoría de oracles no reporten datos falsos. • Sobornador potencial: el sobornador ofrece un soborno de miles de dólares por adelantado al oracle seleccionado. para un rol aleatorio e informes falsos. En nuestro protocolo staking propuesto, todos Los nodos actúan como posibles perros guardianes y podemos demostrar que la aleatorización de las prioridades del organismo de control no se presta a posibles sobornos. Muchos sistemas de prueba de trabajo, proof-of-stake y autorizados son susceptibles a posibles soborno, sin embargo, lo que demuestra la importancia de considerarlo en nuestro conflicto modelo y garantizar que nuestros protocolos staking sean resistentes a él. Ver Apéndice E para más detalles. 9.3.4 ¿Cuánta seguridad criptoeconómica es suficiente? Un adversario racional sólo gastará dinero para atacar un sistema si puede obtener un beneficio. mayor que su gasto. Así, para nuestro modelo adversarial y propuesto staking mecanismo, $B puede verse como una medida del beneficio potencial que un adversario puede obtener para extraer de smart contracts confiables corrompiendo una red oracle y provocando que para generar un informe o conjunto de informes incorrectos. Al decidir si una red oracle ofrece un grado suficiente de seguridad criptoeconómica para sus propósitos, un usuario debe evaluar la red desde esta perspectiva. Para adversarios plausibles en escenarios prácticos, esperamos que $B sea generalmente sustancialmente menor que los activos totales en smart contracts confiables. En la mayoría de los casos, Es inviable que un adversario extraiga estos activos en su totalidad. 9.4 Mecanismo de replanteo: boceto Aquí presentamos las ideas principales y la estructura general del mecanismo staking que están considerando actualmente. Para facilitar la presentación, describimos un método simple pero lento. protocolo (múltiples rondas) en esta subsección. Sin embargo, observamos que este esquema es bastante práctico. Dadas las garantías económicas proporcionadas por el mecanismo, es decir, la penalización y el consiguiente incentivo contra los nodos defectuosos, muchos usuarios pueden estar dispuestos a aceptar informes con optimismo. En otras palabras, dichos usuarios pueden aceptar informes antes de posible adjudicación por parte del segundo nivel. Los usuarios que no estén dispuestos a aceptar informes con optimismo pueden optar por esperar hasta que el protocolo la ejecución termina, es decir, hasta que se produzca cualquier posible escalada al segundo nivel. esto, sin embargo, puede ralentizar sustancialmente el tiempo de confirmación de los informes. Por lo tanto, brevementeFigura 15: Esquema del esquema staking con alertas. En este ejemplo, 1⃝una mayoría de nodos están corruptos/sobornados y emiten un valor incorrecto ˜r, en lugar del correcto valor del informe r. El nodo de vigilancia 2⃝ envía una alerta al comité de segundo nivel, que 3⃝determina y emite el valor de informe correcto r, lo que resulta en nodos corruptos perdiendo sus depósitos, cada $d al nodo de vigilancia 4⃝. Describe algunas optimizaciones que resultan en una ronda más rápida (de una sola ronda), aunque algo más. diseño complejo en la Sección 9.5. Recuerde que el primer nivel de nuestro mecanismo staking consta del oracle básico. red misma. La estructura principal de nuestro mecanismo, como se describe anteriormente, es que en cada ronda, cada nodo puede actuar como un "perro guardián" con cierta prioridad y, por lo tanto, tiene la capacidad de generar una alerta si el mecanismo llega a una salida incorrecta ˜r, en lugar de una correcta uno r. Esta alerta provoca una resolución de segundo nivel, que asumimos llega a una resolución correcta. informe. Los nodos con informes incorrectos son castigados, en el sentido de que sus apuestas son recortado y entregado a los perros guardianes. Esta estructura básica es común en los sistemas oracle, como en, por ejemplo, [119, 185]. La innovación clave en nuestro diseño, mencionada brevemente anteriormente, es que cada nodo está Se le asignó una clara prioridad en el ordenamiento de los posibles perros guardianes. Es decir, perros guardianes. se les dan oportunidades para alertar en secuencia prioritaria. Recuerde que si un nodo tiene la máxima prioridad para generar una alerta, recibe el depósito recortado $d por cada mal comportamiento nodo, para un total de más de \(dn/2 = \)d × n/2, ya que un informe incorrecto implica un mayoría de nodos defectuosos. En consecuencia, el adversario debe pagar al menos esta recompensa a sobornar a un nodo arbitrario. Así, para sobornar a la mayoría de los nodos, el adversario debe pagar una Un gran soborno a la mayoría de los nodos, es decir, estrictamente más de $dn2/2. Mostramos esquemáticamente cómo funciona la escalada de alertas y vigilancia en la Fig. 15.9.4.1 Más detalles del mecanismo El sistema resistente al soborno que describimos ahora con más detalle es un bosquejo simplificado de la construcción de dos niveles que pretendemos construir. La mayor parte de nuestra atención se centrará en describir la red de primer nivel (en adelante simplemente “red” cuando se desprenda del contexto) junto con con su mecanismo de incentivos y el procedimiento de escalada al segundo nivel. Considere una red Chainlink compuesta por n oracle nodos que son responsables de regularmente (por ejemplo, una vez por minuto) informando un valor booleano (por ejemplo, si el mercado la capitalización de BTC supera la de ETH). Como parte del mecanismo staking, los nodos debe proporcionar dos depósitos: un depósito $d sujeto a recortes en caso de desacuerdo con la mayoría y un depósito de vigilancia $dw sujeto a recortes en caso de fallo escalada. Suponemos que los nodos no pueden copiar los envíos de otros nodos, por ejemplo, a través de un esquema de compromiso-revelación como se analiza en la Sección 5.3. En cada ronda, los nodos primero comprometerse con su informe, y una vez que todos los nodos se hayan comprometido (o haya expirado un tiempo de espera), Los nodos revelan sus informes. Para cada informe que se genera, a cada nodo también se le asigna una prioridad de vigilancia entre 1 yn elegida al azar, siendo 1 la máxima prioridad. Esta prioridad permite a la concentración de recompensa en manos de un perro guardián. Después de que todos los informes sean públicos, sobreviene una fase de alerta. Durante una secuencia de n rondas (síncronas), el nodo con La prioridad i tiene la oportunidad de alertar en la ronda i. Consideremos los posibles resultados del mecanismo después de que los nodos hayan revelado sus informes. Suponiendo nuevamente un informe binario, supongamos que el valor correcto es verdadero y el incorrecto es falso. Supongamos también que el mecanismo de primer nivel genera la Valor mayoritario producido por los nodos como informe final r. Hay tres resultados posibles en el mecanismo: • Acuerdo completo: en el mejor de los casos, los nodos están en completo acuerdo: todos los nodos están disponibles y han proporcionado un informe oportuno del mismo valor r (ya sea verdadero o falso). En este caso, la red sólo necesita reenviar r a los contratos de confianza. y recompensar cada nodo con un pago fijo por ronda $p, que es mucho menor que $d. • Acuerdo parcial: es posible que algunos nodos estén fuera de línea o haya desacuerdo sobre qué valor es correcto, pero la mayoría de los nodos informan que son verdaderos y solo un Los informes minoritarios son falsos. Este caso también es sencillo. El valor mayoritario (verdadero) se calcula, lo que da como resultado un informe correcto r. Todos los nodos que informaron r son recompensados con $p mientras los oracles que reportaron incorrectamente tengan sus depósitos reducido modestamente, por ejemplo, en 10 peniques. • Alerta: En caso de que un organismo de control crea que la salida de la red es incorrecta, activa públicamente una alerta, escalando el mecanismo a la red de segundo nivel. Hay entonces dos resultados posibles: – Alerta correcta: si la red de segundo nivel confirma que la salida delFigura 16: Ampliación del costo del soborno mediante recompensas de alerta concentradas. un soborno El adversario debe sobornar a cada nodo con más recompensa que la que podría obtener alertando. (se muestra como una barra roja). Si se comparten las recompensas de alerta, entonces esta recompensa puede ser relativamente pequeño. Las recompensas de alerta concentradas aumentan la recompensa que cualquier nodo puede recibir. obtener (barra roja alta). En consecuencia, el pago total por parte del adversario por un soborno viable (regiones grises) es mucho mayor con recompensas de alerta concentradas que compartidas. La red de primer nivel era incorrecta, el nodo de vigilancia que alerta recibe una recompensa. que consiste en todos los depósitos recortados y, por lo tanto, más de $dn/2. – Alerta defectuosa: si los oracle de segundo y primer nivel están de acuerdo, se realiza la escalada. se considera defectuoso y el nodo de alerta pierde su depósito de $dw. En caso de aceptación optimista de los informes, las alertas de vigilancia no causan cualquier cambio en la ejecución de los contratos de confianza. Para contratos diseñados para esperar posible arbitraje por parte del comité de segundo nivel, las alertas del organismo de control retrasan pero no congelar la ejecución del contrato. También es posible que los contratos designen un conmutación por error DON para períodos de adjudicación. 9.4.2 Impacto de apuesta cuadrático La capacidad de cada nodo de actuar como guardián, combinada con una estricta prioridad de nodo. Garantizar recompensas concentradas permite que el mecanismo alcance staking cuadrático. impacto para cada tipo de atacante que soborna descrito en la Sección 9.3.3. Recuerde que esto significa específicamente en nuestro entorno que, para una red con n nodos cada uno con depósito $d, un sobornador exitoso (de cualquiera de los tipos anteriores) debe tener un presupuesto mayor que $dn2/2. Para ser precisos, el sobornador debe corromper al menos (n+1)/2 nodos, ya que el sobornador debe corromper una mayoría de n nodos (para n impares, por supuesto). Por lo tanto, un perro guardián debe gane una recompensa de $d(n + 1)/2. En consecuencia, el sobornador debe pagar esta cantidad a cadanodo para garantizar que ninguno actúe como perro guardián. Estamos trabajando para demostrar formalmente que si el sobornador tiene un presupuesto de como máximo $d(n2 + n)/2, entonces el equilibrio perfecto en subjuegos del juego entre los sobornadores y los oracles; en otras palabras, el equilibrio en cualquier momento durante el desarrollo del juego—es para el sobornador no emitir el soborno y para cada oracle para informar sus verdaderos valores con honestidad. Hemos explicado anteriormente cómo es posible que un sobornador exitoso requiera una presupuesto significativamente mayor que el de la suma de los depósitos de los nodos. Para ilustrar esto Como resultado intuitivo, la Fig. 16 muestra gráficamente el impacto de las recompensas de alerta concentradas. Como vemos allí, si la recompensa por alertar al organismo de control (es decir, los depósitos de los sobornados) nodos que informan falsos): se dividieron entre todas las alertas potenciales, la cantidad total que cualquier nodo de alerta individual podría esperar sería relativamente pequeño, del orden de $d. Un sobornador, sabiendo que era improbable un pago superior a $d, podría utilizar un soborno condicional de resultado falso para sobornar a cada uno de los n nodos con un poco más de $d + ϵ. Contraintuitivamente, la Fig. 16 muestra que un sistema que distribuye una recompensa ampliamente entre los nodos que señalan una alerta es mucho más débil que uno que concentra la recompensa en las manos de un solo perro guardián. Parámetros de ejemplo: Considere una red (de primer nivel) con n = 100 nodos, cada uno depositando \(d = \)20K. Esta red tendría un total de $2 millones depositados pero Estar protegido contra un soborno con presupuesto \(100M = \)dn2/2. Aumentando el número de oracles es más efectivo que aumentar $d, por supuesto, y puede tener un efecto dramático: una red con n = 300 nodos y depósitos \(d = \)20K estaría protegida contra un Sobornador con presupuesto de hasta 900 millones de dólares. Tenga en cuenta que un sistema staking puede en muchos casos proteger smart contracts que representan más valor que el nivel ofrecido de protección contra el soborno. Esto se debe a que un adversario atacar estos contratos no puede extraer el valor total en muchos casos. Por ejemplo, un Un contrato impulsado por Chainlink que garantiza un valor de mil millones de dólares solo puede requerir una garantía contra una sobornador con 100 millones de dólares en recursos porque tal adversario puede extraer una ganancia de sólo el 10% del valor del contrato. Nota: La idea de que el valor de una red puede crecer cuadráticamente se expresa en la conocida Ley de Metcalfe [167, 235], que establece que el valor de una red crece cuadráticamente en el número de entidades conectadas. La ley de Metcalfe, sin embargo, surge del crecimiento en el número de posibles conexiones de red por pares, un fenómeno diferente al impacto cuadrático subyacente staking en nuestro incentivo mecanismo. 9.4.3 Realización del Segundo Nivel Dos características operativas facilitan la realización de un segundo nivel de alta confiabilidad: (1) La adjudicación de segundo nivel debería ser un evento poco común en las redes oracle y, por lo tanto, puede ser significativamente más costoso que el funcionamiento normal del primer nivel y (2) Suponiendoinformes aceptados con optimismo—o contratos cuya ejecución puede esperar a un arbitraje— el segundo nivel no necesita ejecutarse en tiempo real. Estas características dan como resultado una gama de Opciones de configuración para el segundo nivel para cumplir con los requisitos de DONs particulares. Como enfoque de ejemplo, un comité de segundo nivel puede estar formado por nodos seleccionados por un DON (es decir, primer nivel) de los nodos más confiables y con más años de servicio en el Chainlink red. Además de una considerable experiencia operativa relevante, los operadores de tales nodos tienen un incentivo implícito considerable en FFO que motiva un deseo para garantizar que la red Chainlink siga siendo altamente confiable. También lo han hecho públicamente historiales de rendimiento disponibles que brindan transparencia sobre su confiabilidad. Vale la pena señalar que los nodos de segundo nivel no necesitan ser participantes en la red de primer nivel, y puede adjudicar fallas en múltiples redes de primer nivel. Los nodos en un DON determinado pueden predesignar y comprometerse públicamente con un conjunto de n′ tales nodos que constituyen el comité de segundo nivel para ese DON. Además, DON los nodos publican un parámetro k′ ≤n′ que determina el número de votos de segundo nivel requerido para penalizar un nodo de primer nivel. Cuando se genera una alerta para un informe determinado, Los miembros del segundo nivel votan sobre la exactitud de los valores proporcionados por cada uno. de los nodos de primer nivel. Cualquier nodo de primer nivel que reciba k′ votos negativos pierde su depósitos al nodo de vigilancia. Debido a la rareza de la adjudicación y la oportunidad de ejecución por tiempo prolongado Como se señaló anteriormente, a diferencia del primer nivel, los nodos del segundo nivel pueden: 1. Recibir una remuneración elevada por realizar la adjudicación. 2. Aprovechar fuentes de datos adicionales, incluso más allá del conjunto diverso utilizado por el primero. 3. Depender de la inspección e intervención manual y/o experta, por ejemplo, para identificar y conciliar errores en los datos de origen y distinguir entre un nodo honesto que transmite datos defectuosos y un nodo que se comporta mal. Hacemos hincapié en que el enfoque que acabamos de describir para la selección de nodos de segundo nivel y la política que rige la adjudicación representa sólo un punto dentro de un gran Espacio de diseño de posibles realizaciones del segundo nivel. Nuestro mecanismo de incentivos ofrece Completa flexibilidad en cuanto a cómo se realiza el segundo nivel. Los DON individuales pueden así constituir y fijar reglas para sus segundos niveles que cumplan con los requisitos particulares y expectativas de los nodos y usuarios participantes. DECO y Town Pregonero como herramientas de adjudicación: Es imprescindible para la segunda división. en nuestro mecanismo para poder distinguir entre nodos adversarios de primer nivel que producir intencionalmente informes incorrectos y nodos honestos de primer nivel que sin querer transmitir datos que son incorrectos en la fuente. Sólo entonces podrá el segundo nivel implementar Recortar para desincentivar las trampas, el objetivo de nuestro mecanismo. DECO y Pregonero son herramientas poderosas que pueden permitir que los nodos de segundo nivel hagan esta distinción crítica confiablemente.En algunos casos, los nodos de segundo nivel pueden consultar directamente la fuente de datos utilizada. por un nodo de primer nivel o utilice la Sección 7.1 de ADO para comprobar si se ha recibido un informe incorrecto. resultado de una fuente de datos defectuosa. En otros casos, sin embargo, los nodos de segundo nivel pueden carecer acceso directo a la fuente de datos de un nodo de primer nivel. En tales casos, una adjudicación correcta parecen inviables o requieren confiar en un juicio subjetivo. Anterior oracle Los sistemas de disputas se han basado en rondas de votación cada vez más ineficientes para abordar tales cuestiones. desafíos. Sin embargo, al utilizar DECO o Town Crier, un nodo de primer nivel puede demostrar un comportamiento correcto. a nodos de segundo nivel. (Consulte la Sección 3.6.2 para obtener detalles sobre los dos sistemas). Específicamente, si el nodo de segundo nivel identifica un nodo de primer nivel que ha generado un valor de informe defectuoso ˜r, El nodo de primer nivel puede usar DECO o Town Crier para generar evidencia a prueba de manipulaciones para nodos de segundo nivel que están transmitiendo correctamente desde una fuente (habilitada para TLS) reconocido como autorizado por el DON. Fundamentalmente, el nodo de primer nivel puede hacer esto. sin nodos de segundo nivel que requieran acceso directo a la fuente de datos.17 En consecuencia, La adjudicación correcta es factible en Chainlink para cualquier fuente de datos deseada. 9.4.4 Informes erróneos de seguros La fuerte resistencia al soborno lograda por nuestro mecanismo staking se basa fundamentalmente sobre los recortes de fondos que se conceden a los alertadores. Sin una recompensa monetaria, los alertadores no tienen ningún incentivo directo para rechazar los sobornos. Como resultado, sin embargo, los fondos recortados no son disponible para compensar a los usuarios perjudicados por informes incorrectos, por ejemplo, usuarios que pierden dinero cuando se transmiten datos de precios incorrectos a smart contract. Por supuesto, los informes incorrectos no suponen un problema si los informes son aceptados por un contrato sólo después de una posible adjudicación, es decir, una acción por parte del segundo nivel. Como se explica Sin embargo, para lograr el mejor desempeño posible, los contratos pueden basarse en son optimistas sobre el mecanismo para hacer cumplir la presentación de informes correctos, lo que significa que aceptan informes antes de una posible adjudicación de segundo nivel. De hecho, un comportamiento tan optimista es seguro en nuestro modelo asumiendo adversarios racionales cuyos presupuestos no excedan el staking impacto del mecanismo. Usuarios preocupados por el improbable caso de una falla del mecanismo resultante de, por ejemplo, los adversarios con recursos financieros abrumadores pueden desear emplear una capa adicional de seguridad económica en forma de seguros contra declaraciones erróneas. sabemos de Múltiples aseguradoras ya tienen la intención de ofrecer pólizas de este tipo respaldadas por contratos inteligentes. para protocolos seguros Chainlink en un futuro próximo, incluso a través de mecanismos innovadores como DAOs, por ejemplo, [7]. La existencia de un historial de rendimiento para Chainlink Los nodos y otros datos sobre los nodos, como los montos de su participación, proporcionan una base excepcionalmente sólida para las evaluaciones actuariales del riesgo, lo que permite fijar el precio de las políticas. de maneras que sean económicas para los asegurados pero sostenibles para las aseguradoras. 17Con Town Crier, también es posible que los nodos de primer nivel generen certificaciones localmente de corrección de los informes que generan y proporcionan estas certificaciones a los nodos de segundo nivel en un según sea necesario.Las formas básicas de seguros contra declaraciones erróneas se pueden implementar de manera confiable y manera eficiente usando smart contracts. Como ejemplo sencillo, un seguro paramétrico contrato SCins puede compensar a los asegurados automáticamente si nuestro mecanismo de incentivos El segundo nivel identifica un error en un informe generado en el primer nivel. Un usuario U que desea adquirir una póliza de seguro, por ejemplo, el creador de un objetivo. contrato SC, puede presentar una solicitud a una aseguradora descentralizada por un monto de póliza Millones de dólares en el contrato. Al aprobar U, el asegurador puede establecer un período continuo (por ejemplo, mensual) prima de $P en SCins. Mientras U paga la prima, su póliza permanece activa. Si ocurre una falla en el reporte en SC, el resultado será la emisión de un par (r1, r2) de informes contradictorios para SC, donde r1 está firmado por el primer nivel de nuestro mecanismo y r2, el informe corregido correspondiente, está firmado por el segundo nivel. Si la U proporciona tal par válido (r1, r2) a SCins, el contrato le paga automáticamente $M, siempre que sus pagos de primas están al día. 9.5 Variante de una sola ronda El protocolo descrito en la subsección anterior requiere que el comité de segundo nivel espere n rondas para determinar si un organismo de control ha emitido una alerta. esto El requisito se mantiene incluso en el caso optimista, es decir, cuando el primer nivel está funcionando. correctamente. Para los usuarios que no estén dispuestos a aceptar informes de manera optimista, es decir, antes de posibles adjudicación, el retraso asociado con ese enfoque sería inviable. Por esta razón, también estamos explorando protocolos alternativos que requieren solo un redondo. En este enfoque, todos los nodos oracle envían bits secretos que indican si desean dar una alerta. El comité de segundo nivel luego verifica estos valores en orden de prioridad. Para proporcionar un esbozo aproximado, dicho esquema podría implicar lo siguiente pasos: 1. Envío de bits de vigilancia: cada nodo secreto de Oi comparte un valor de vigilancia de un bit wi ∈{sin alerta, alerta} entre los nodos del segundo nivel para cada informe que genera. 2. Consejos anónimos: cualquier nodo oracle puede enviar un consejo anónimo α al comité de segundo nivel en la misma ronda en la que se envían los bits de vigilancia. Este consejo α es un mensaje que indica que se ha generado una alerta para el informe actual. 3. Comprobación de bits de vigilancia: el comité de segundo nivel revela la vigilancia de los nodos oracle bits en orden de prioridad. Tenga en cuenta que los nodos no deben enviar bits de vigilancia de alerta cuando no alertan: de lo contrario, el análisis de tráfico revela los bits de todos los nodos. El protocolo sí revela la no alerta bits de vigilancia de nodos con mayor prioridad que el perro guardián de alerta de mayor prioridad. Observe que lo que se revela es idéntico al de nuestro protocolo de n rondas. Las recompensas también se distribuyen de manera idéntica a ese esquema, es decir, el primer perro guardián identificado recibe los depósitos recortados de los nodos que han enviado informes incorrectos.El uso de sugerencias anónimas permite que el comité de segundo nivel permanezca no interactivo en los casos en los que no se ha generado ninguna alerta, lo que reduce la complejidad de la comunicación. en el caso común. Tenga en cuenta que cualquier organismo de control que genere una alerta tiene un incentivo económico para enviar una denuncia anónima: si no se envía ninguna denuncia, no se paga ninguna recompensa a ningún nodo. Para garantizar que el remitente Oi de un aviso anónimo α no pueda ser identificado por el adversario basado en datos de la red, el aviso anónimo se puede enviar a través de un anónimo canal, por ejemplo, a través de Tor o, más prácticamente, mediante proxy a través de un proveedor de servicios en la nube. a autenticar que la punta se origina en O, Oi puede firmar α usando una firma de anillo [39, 192]. Alternativamente, para evitar ataques de denegación de servicio no atribuibles contra el comité de segundo nivel por parte de un nodo oracle malicioso, α puede ser una credencial anónima con anonimato revocable [73]. Este protocolo, si bien es prácticamente realizable, tiene una ingeniería algo pesada. requisitos (que estamos explorando formas de reducir). Los nodos de primer nivel, por ejemplo, debe comunicarse directamente con nodos de segundo nivel, lo que requiere el mantenimiento de un directorio. La necesidad de canales anónimos y firmas de anillo se suma a la ingeniería. complejidad del esquema. Finalmente, existe un requisito especial de confianza que se analiza brevemente en la nota a continuación. Por lo tanto, también estamos explorando esquemas más simples que aún logran impacto superlineal staking, pero quizás menos que cuadrático, en el que un sobornador necesita asintóticamente recursos de al menos $n log n, por ejemplo. Algunos de los esquemas bajo consideración implica la selección aleatoria de un subconjunto estricto de nodos para actuar como perros guardianes, en cuyo caso el posible soborno se convierte en un ataque especialmente poderoso. Observación: La seguridad de este mecanismo staking de una sola ronda requiere que no se pueda explotar. canales entre oracle y nodos de segundo nivel: un requisito estándar en sistemas resistentes a la coerción, por ejemplo, votación [82, 138], y razonable en la práctica. Sin embargo, además, un nodo Oi que busque cooperar con un sobornador puede construir sus acciones secretas de tal manera que muestre al sobornador que ha codificado un determinado valor. Por ejemplo, si Oi no sabe qué nodos controla el sobornador, entonces Oi puede enviar acciones con valor 0 a todos los miembros del comité. El sobornador puede entonces verificar la situación de Oi. cumplimiento probabilísticamente. Para evitar este problema en cualquier protocolo de ronda única, requieren que Oi conozca la identidad de al menos un nodo honesto de segundo nivel. Con un protocolo interactivo en el que cada nodo de segundo nivel agrega una aleatorización factor a las acciones, lo mejor que puede hacer el sobornador es obligar a Oi a seleccionar un bit de perro guardián. 9.6 Marco de incentivos implícitos (IIF) FFO es una forma de incentivo implícito para el comportamiento correcto en la red Chainlink. eso funciona como participación explícita, es decir, depósitos, en el sentido de que ayuda a hacer cumplir la seguridad económica para la red. En otras palabras, el FFO debería incluirse como parte del depósito (efectivo) $d de un nodo en la red.La pregunta es: ¿Cómo medimos el FFO y otras formas de incentivos implícitos? dentro de la red Chainlink? El Marco de Incentivos Implícitos (MII) es un conjunto de principios y técnicas que pretendemos desarrollar con este fin. Sistemas de cadena de bloques proporcionan muchas formas de transparencia sin precedentes y los registros de alta confianza de los nodos El desempeño que crean son un trampolín para nuestra visión de cómo funcionará el IIF. Aquí esbozamos muy brevemente ideas sobre elementos clave del MII. El IIF en sí consistirá en un conjunto de factores que identificamos como importantes al evaluar incentivos implícitos, junto con mecanismos para publicar datos relevantes en una forma de alta seguridad para su consumo por algoritmos analíticos. Diferentes usuarios Chainlink pueden desean utilizar el IIF de diferentes maneras, por ejemplo, dando diferente ponderación a diferentes factores. Esperamos que surjan servicios de análisis en la comunidad que ayuden a los usuarios a aplicar el IIF. de acuerdo con sus preferencias individuales de evaluación de riesgos, y nuestro objetivo es facilitar dichos servicios garantizando su acceso a datos de respaldo oportunos y de alta seguridad, como analizamos a continuación (Sección 9.6.4). 9.6.1 Oportunidad de tarifa futura Los nodos participan en el ecosistema Chainlink para ganar una parte de las tarifas que las redes pagan por cualquiera de los diversos servicios que hemos descrito en este documento, desde Los datos ordinarios se alimentan de servicios avanzados como identidad descentralizada, secuenciación justa, y preservación de la confidencialidad DeFi. Las tarifas en la red Chainlink respaldan los costos de los operadores de nodos para, por ejemplo, ejecutar servidores, adquirir las licencias de datos necesarias y mantener un personal global para garantizar un alto tiempo de actividad. FFO denota las tarifas de servicio, netas de gastos, que un nodo puede ganar en el futuro, o perder si demuestra un comportamiento defectuoso. FFO es una forma de participación que ayuda a proteger la red. Una característica útil de FFO es el hecho de que los datos dentro de la cadena (complementados con datos fuera de la cadena) datos) establecen un registro de alta confianza del historial de un nodo, lo que permite el cálculo de FFO de manera transparente y empíricamente impulsada. Una medida simple de primer orden de FFO puede derivarse del ingreso neto promedio de una nodo durante un período de tiempo (es decir, ingresos brutos menos gastos operativos). FFO puede luego calcularse como, por ejemplo, el valor presente neto [114] de los ingresos netos futuros acumulados, en otras palabras, el valor descontado en el tiempo de todas las ganancias futuras. Sin embargo, los ingresos del nodo pueden ser volátiles, como se muestra, por ejemplo, en la Fig. 17. Más importante aún, es posible que los ingresos del nodo no sigan una distribución estacionaria. con el tiempo. En consecuencia, otros factores que planeamos explorar al estimar el FFO incluyen: • Historial de desempeño: el historial de desempeño de un operador, incluida la exactitud y puntualidad de sus informes, así como su tiempo de actividad, proporciona una base objetiva. piedra de toque para que los usuarios evalúen su confiabilidad. Por lo tanto, el historial de rendimiento proporcionar un factor crítico en la selección de los usuarios de oracle nodos (o, con la llegada de DONs, su selección de DONs). Es probable que un historial de desempeño sólido se correlacionan con altos ingresos continuos.18 18Una cuestión de investigación importante que pretendemos abordar es la detección de volúmenes de servicios falsificados.Figura 17: Ingresos obtenidos por Chainlink nodos en una única fuente de datos (ETH-USD) durante una semana representativa en marzo de 2021. • Acceso a datos: si bien oracles pueden obtener muchas formas de datos de API abiertas, Ciertas formas de datos o ciertas fuentes de alta calidad pueden estar disponibles sólo en un mediante suscripción o mediante acuerdos contractuales. Acceso privilegiado a determinados Las fuentes de datos pueden desempeñar un papel en la creación de un flujo de ingresos estable. • Participación de DON: Con la llegada de DONs, vendrán comunidades de nodos. juntos para proporcionar servicios particulares. Esperamos que muchos DONs incluyan operadores de forma selectiva, estableciendo la participación en DONs acreditados como Posición privilegiada en el mercado que ayuda a garantizar una fuente constante de ingresos. • Actividad multiplataforma: algunos operadores de nodos pueden tener presencias bien establecidas y registros de desempeño en otros contextos, por ejemplo, como PoS validators o proveedores de datos en contextos distintos de blockchain. Su desempeño en estos otros sistemas (cuando los datos sobre ellos están disponibles en una forma confiable) puede informar la evaluación. de su historial de desempeño. Del mismo modo, comportamiento defectuoso en la red Chainlink puede poner en peligro los ingresos en estos otros sistemas al ahuyentar a los usuarios, es decir, FFO puede extenderse a través de plataformas. 9.6.2 FFO especulativo Los operadores de nodos participan en la red Chainlink no solo para generar ingresos de operaciones, sino crear y posicionarse para aprovechar nuevas oportunidades para ejecutar puestos de trabajo. En otras palabras, el gasto de oracle nodos en la red también se una declaración positiva sobre el futuro de DeFi y otras aplicaciones de contratos inteligentes dominios, así como aplicaciones emergentes no blockchain de redes oracle. Los operadores de nodos hoy ganan las tarifas disponibles en las redes Chainlink existentes y simultáneamente Son vagamente análogas a las reseñas falsas en sitios de Internet, excepto que el problema es más fácil en el oracle porque tenemos un registro definitivo de si los bienes, es decir, los informes, fueron ordenados y entregados, a diferencia de, por ejemplo, productos físicos pedidos en tiendas en línea. Dicho de otra manera, en el oracle En esta configuración, el rendimiento se puede validar, incluso si la veracidad del cliente no.construir una reputación, un historial de desempeño y experiencia operativa que posicionarán ellos ventajosamente para ganar tarifas disponibles en redes futuras (contingentes, por supuesto, sobre comportamiento honesto). Los nodos que operan en el ecosistema Chainlink hoy en este sentido tienen una ventaja sobre los recién llegados al ganar las tarifas adicionales Chainlink los servicios estén disponibles. Esta ventaja se aplica a nuevos operadores, así como a empresas de tecnología con reputación establecida; por ejemplo, T-Systems, un tradicional proveedor de tecnología (subsidiaria de Deutsche Telekom) y Kraken, una gran centralizada intercambio, han establecido presencias tempranas en el ecosistema Chainlink [28, 143]. Dicha participación de oracle nodos en oportunidades futuras puede considerarse en sí misma. como una especie de FFO especulativo y, por lo tanto, constituye una forma de participación en el Chainlink red. 9.6.3 Reputación externa El IIF tal como lo hemos descrito puede operar en una red con usuarios estrictamente seudónimos. operadores, es decir, sin divulgación de las personas o entidades del mundo real involucradas. Sin embargo, un factor potencialmente importante para la selección de proveedores por parte del usuario es el reputación. Por reputación externa nos referimos a la percepción de confiabilidad asociada a identidades del mundo real, más que a seudónimos. Riesgo reputacional asociado a Las identidades del mundo real pueden verse como una forma de incentivo implícito. Vemos la reputación a través de la lente del IIF, es decir, en un sentido criptoeconómico, como un medio para establecer actividad multiplataforma que puede incorporarse a las estimaciones de FFO. El beneficio de utilizar la reputación externa como factor en las estimaciones de FFO, en contraposición al vínculo seudónimo, es que la reputación externa vincula el desempeño no sólo a un de las actividades actuales del operador, sino también de las futuras. Si, por ejemplo, una mala reputación se atribuye a una persona individual, puede manchar las futuras empresas de esa persona. Dicho de otra manera, la reputación externa puede captar una franja más amplia de FFO que los seudónimos. registros de desempeño, como el impacto de la mala conducta asociada a una persona o establecimiento Es más difícil escapar de una empresa que de la asociada a una operación seudónima. Chainlink es compatible con tecnologías de identidad descentralizadas (Sección 4.3) que puede brindar apoyo para el uso de la reputación externa en el IIF. Tales tecnologías puede validar y, por lo tanto, ayudar a garantizar la veracidad de las declaraciones del mundo real afirmadas por los operadores. identidades.19 9.6.4 Abrir análisis IIF El IIF, como hemos señalado, tiene como objetivo proporcionar datos y herramientas confiables de fuente abierta para análisis de incentivos implícitos. El objetivo es permitir que los proveedores dentro de la comunidad desarrollar análisis adaptados a las necesidades de evaluación de riesgos de diferentes partes del Chainlink base de usuarios. 19Las credenciales de identidad descentralizadas también pueden, cuando se desee, embellecer los seudónimos con credenciales validadas. información complementaria. Por ejemplo, un operador de nodo podría, en principio, utilizar dichas credenciales para demostrar que es una empresa Fortune 500, sin revelar cuál.Una cantidad considerable de datos históricos sobre los ingresos y el rendimiento de los nodos. reside en la cadena en una forma inmutable y de alta confianza. Nuestro objetivo, sin embargo, es proporcionar la datos más completos posibles, incluidos datos sobre comportamientos que sólo son visibles cadena, como informes fuera de cadena (OCR) o actividad DON. Estos datos pueden potencialmente ser voluminoso. La mejor manera de almacenarlo y asegurar su integridad, es decir, protegerlo de Creemos que la manipulación se realizará con la ayuda de DONs, utilizando técnicas discutidas en la Sección 3.3. Algunos incentivos se prestan a formas directas de medición, como staking depósitos y FFO básico. Otros, como el FFO especulativo y la reputación, son más difíciles de evaluar. medir de manera objetiva, pero creemos que las formas de datos de respaldo, incluidas crecimiento histórico del ecosistema Chainlink, métricas de reputación en redes sociales, etc., puede admitir modelos de análisis IIF incluso para estos elementos más difíciles de cuantificar. Podemos imaginar que los DON dedicados surgen específicamente para monitorear, validar y registrar datos relacionados con registros de rendimiento fuera de la cadena de nodos, así como otros datos utilizados en el IIF, como información de identidad validada. Estos DON pueden proporcionar datos IIF uniformes y de alta confianza para cualquier proveedor de análisis que preste servicio a la comunidad Chainlink. También proporcionarán un disco de oro que haga realidad las afirmaciones de los proveedores de análisis. verificable independientemente por la comunidad. 9.7 Poniéndolo todo junto: incentivos para operadores de nodos Sintetizando nuestras discusiones anteriores sobre incentivos explícitos e implícitos para los operadores de nodos proporciona una visión holística de las formas en que los operadores de nodos participan y se benefician de la red Chainlink. Como guía conceptual, podemos expresar los activos totales en juego mediante un Chainlink determinado. operador de nodo $S en una forma aproximada y estilizada como: \(S ≈\)D + \(F + \)FS + $R, donde: • $D es la suma de todas las participaciones depositadas explícitamente en todas las redes en las que el operador participa; • $F es el valor presente neto del agregado de todos los FFO en todas las redes en en el que participa el operador; • $FS es el valor actual neto del FFO especulativo del operador; y • $R es el patrimonio reputacional del operador fuera del ecosistema Chainlink que podría estar en peligro por un mal comportamiento identificado en sus nodos oracle. Si bien es en gran medida conceptual, esta igualdad aproximada muestra de manera útil que existe una multiplicidad de factores económicos que favorecen el rendimiento de alta confiabilidad de los Chainlink nodos. Todos estos factores, además de $D, están presentes en las redes Chainlink actuales.9.8 El círculo virtuoso de la seguridad económica La combinación del impacto superlineal staking con la representación de los pagos de tarifas como oportunidad de pago futura (FFO) en el IIF puede conducir a lo que llamamos el círculo virtuoso de seguridad económica en una red oracle. Esto puede verse como una especie de economía. de escala. A medida que aumenta la cantidad total asegurada por una red particular, la cantidad de La participación adicional que se necesita para agregar una cantidad fija de seguridad económica disminuye al igual que lo hace el coste medio por usuario. Por lo tanto, es más barato, en términos de tarifas, que un usuario se una una red ya existente que lograr el mismo aumento en la rentabilidad económica de la red. seguridad mediante la creación de una nueva red. Es importante destacar que la incorporación de cada nuevo usuario reduce el costo del servicio para todos los usuarios anteriores de esa red. Dada una estructura de tarifas particular (por ejemplo, una tasa de rendimiento particular sobre el monto apostado), Si las tarifas totales ganadas por una red aumentan, esto incentiva el flujo de participación en la red para asegurarla a una tasa más alta. Específicamente, si la apuesta total un nodo individual puede contener en el sistema, cuando se realicen nuevos pagos de tarifas ingresa al sistema, aumentando su FFO, el número de nodos n aumentará. Gracias a la impacto superlineal staking de nuestro diseño de sistema de incentivos, la seguridad económica de el sistema crecerá más rápido que n, por ejemplo, como n2 en el mecanismo que esbozamos en la sección 9.4. Como resultado, el costo promedio de la seguridad económica (es decir, la cantidad de participación que contribuye) un dólar de seguridad económica—caerá. Por tanto, la red puede cobrar a sus usuarios. tarifas más bajas. Suponiendo que la demanda de servicios oracle es elástica (ver, por ejemplo, [31] para una breve explicación), la demanda aumentará, generando tarifas adicionales y FFO. Ilustramos este punto con el siguiente ejemplo. Ejemplo 5. Desde la seguridad económica de una red oracle con nuestro incentivo esquema es \(dn2 for stake \)dn, la seguridad económica aportada por un dólar de participación es n y, por lo tanto, el costo promedio por dólar de la seguridad económica, es decir, la cantidad de participación contribuir a un dólar de seguridad económica es 1/n. Considere una red en la que los incentivos económicos consisten enteramente en FFO, limitados en \(d ≤\)10K por nodo. Supongamos que la red tiene n = 3 nodos. Entonces el costo promedio por dólar de seguridad económica es de aproximadamente 0,33 dólares. Supongamos que el FFO total de la red supera \(30K (e.g., to \)31K). dado el límite de FFO por nodo, la red crece a (al menos) n = 4. Ahora el costo promedio por dólar de seguridad económica cae a alrededor de 0,25 dólares. Ilustramos esquemáticamente el ciclo virtuoso completo de la seguridad económica en las redes oracle en la Fig. 18. Destacamos que el círculo virtuoso de la seguridad económica se deriva del efecto de usuarios que ponen en común sus tarifas. Es su FFO colectivo el que trabaja a favor de grandes tamaños de red y, por tanto, una mayor seguridad colectiva. También observamos que el círculo virtuoso de seguridad económica favorece que DONs alcancen la sostenibilidad financiera. una vez creados, los DONs que abordan las necesidades del usuario deben crecer hasta y más allá del punto en el que Los ingresos por tarifas superan los costos operativos para oracle nodos.

Figura 18: Esquema del círculo virtuoso de Chainlink staking. Un aumento en la tarifa de usuario pagos a una red oracle 1⃝hace que crezca, lo que lleva al crecimiento de su economía seguridad 2⃝. Este crecimiento superlineal logra economías de escala en redes Chainlink 3⃝. Específicamente, significa una reducción en el costo promedio de la seguridad económica, es decir, la seguridad económica por dólar que surge del pago de tarifas u otras fuentes de participación aumenta. Los costos más bajos, transferidos a los usuarios, estimulan una mayor demanda de oracle servicios 4⃝. 9.9 Factores adicionales que impulsan el crecimiento de la red A medida que el ecosistema Chainlink continúa expandiéndose, creemos que su atractivo para los usuarios y su importancia como infraestructura para la economía blockchain se acelerará. El valor proporcionado por las redes oracle es superlineal, lo que significa que crece más rápidoque el tamaño de las propias redes. Este crecimiento en valor se deriva tanto de economías de escala (mayor eficiencia de costos por usuario a medida que aumentan los volúmenes de servicios) y Efectos de red: un aumento de la utilidad de la red a medida que los usuarios adoptan DONs más ampliamente. A medida que los smart contract__ existentes continúan viendo más valor asegurado y completamente nuevo smart contract aplicaciones son posibles gracias a servicios más descentralizados, el total El uso y las tarifas agregadas pagadas a DONs deberían aumentar. Conjuntos crecientes de tarifas en a su vez traducirse en medios e incentivos para crear servicios aún más descentralizados, resultando en un círculo virtuoso. Este círculo virtuoso resuelve el problema crítico del huevo y la gallina. Problema en el ecosistema híbrido smart contract: características innovadoras smart contract a menudo requieren servicios descentralizados que aún no existen (por ejemplo, nuevos mercados DeFi a menudo requieren nuevas fuentes de datos) pero necesitan suficiente demanda económica para existir. La combinación de tarifas por parte de varios smart contracts para DONs existentes señalará la demanda de servicios descentralizados adicionales de una base de usuarios en crecimiento, dando lugar a su creación por DONs y una habilitación continua de smart contracts híbridos nuevos y variados. En resumen, creemos que el crecimiento de la seguridad de la red impulsado por principios virtuosos ciclos en el mecanismo Chainlink staking ejemplifica patrones más amplios de crecimiento que la red Chainlink puede ayudar a generar una economía en cadena para descentralizados servicios.

Conclusión

En este artículo, hemos expuesto una visión para la evolución de Chainlink. El tema principal En esta visión está la capacidad de las redes oracle para proporcionar una gama mucho más amplia de servicios para smart contracts que la mera entrega de datos. Utilizando DONs como base para los servicios descentralizados del futuro, Chainlink tendrá como objetivo proporcionar una funcionalidad oracle eficaz y de confidencialidad mejorada. Sus redes oracle ofrecerán una fuerte minimización de la confianza. a través de una combinación de mecanismos criptoeconómicos basados en principios como staking y barandillas cuidadosamente concebidas y aplicación del nivel de servicio en cadenas principales dependientes. DONs también ayudará a los sistemas de capa 2 a aplicar políticas de pedidos flexibles y justas en las transacciones, así como a reducir los costos de gas para las transacciones enrutadas por mempool. En conjunto, Todas estas capacidades conducen en la dirección de una tecnología híbrida inteligente, segura y ricamente funcional. contratos. La flexibilidad de DONs mejorará los servicios Chainlink existentes y dará lugar a muchas funciones y aplicaciones smart contract adicionales. Entre estos se encuentran conexión a una amplia variedad de sistemas fuera de la cadena, creación de identidad descentralizada desde datos existentes, canales prioritarios para ayudar a garantizar la entrega oportuna de infraestructura crítica transacciones e instrumentos DeFi que preservan la confidencialidad. La visión que hemos expuesto aquí es ambiciosa. En el corto plazo buscamos potenciar contratos híbridos para lograr objetivos más allá del alcance de smart contracts hoy, mientras A largo plazo, nuestro objetivo es realizar una metacapa descentralizada. Felizmente podemos dibujar sobre nuevas herramientas e ideas, que van desde algoritmos de consenso hasta pruebas de conocimiento cero sistemas—que la comunidad está desarrollando como fruto de una investigación en rápida evolución.

De manera similar, esperamos priorizar la implementación de las ideas contenidas en este documento en respuesta a las necesidades de la comunidad de usuarios de Chainlink. Esperamos con ansias la siguiente etapa. en nuestra búsqueda para empoderar a smart contracts a través de la conectividad universal y establecer tecnologías descentralizadas como columna vertebral de la próxima generación de finanzas del mundo y sistemas legales. Agradecimientos Gracias a Julian Alterini y Shawn Lee por representar las figuras en este artículo.