Suscríbete a DeepL Pro para poder editar este documento.

Entra en www.DeepL.com/pro para más información.

ChainLink
Una red descentralizada de Oracle

Steve Ellis, Ari Juels†, y Sergey Nazarov

4 de septiembre de 2017 (v1.0)

Resumen
Los contratos inteligentes están a punto de revolucionar muchas
industrias al reemplazar la necesidad de acuerdos legales tradicionales y
acuerdos digitales centralmente automatizados. Tanto la verificación del
rendimiento como la ejecución dependen de acciones manuales de una de
las partes contratantes, o de un sistema automatizado que programa- mente
recupera y actualiza los cambios relevantes. Lamentablemente, debido a
sus protocolos de consenso subyacentes, las cadenas de bloqueo en las
que se ejecutan los contratos inteligentes no pueden soportar la
comunicación nativa con los sistemas externos.
Hoy en día, la solución a este problema es introducir una nueva
funcionalidad, llamada oráculo, que proporciona conectividad con el mundo
exterior. Los oráculos existentes son servicios centralizados. Cualquier
contrato inteligente que utilice esos servicios tiene un único punto de falla, lo
que lo hace no más seguro que un acuerdo digital tradicional y centralizado.
En este documento presentamos ChainLink, una red descentralizada de
oráculos. Describimos los componentes de la cadena que ChainLink
proporciona para los contratos para obtener la conectividad externa, y el
software que alimenta los nodos de la red. Presentamos tanto un sistema
simple de agregación de datos de contratos en cadena, como un mecanismo
de consenso fuera de la cadena más eficiente. También describimos los
servicios de apoyo de supervisión de la reputación y la seguridad de
ChainLink que ayudan a los usuarios a hacer una selección informada de
proveedores y a lograr un servicio robusto incluso en condiciones
agresivamente adversas. Por último, caracterizamos las propiedades de un
oráculo ideal como guía para nuestra estrategia de seguridad, y presentamos
posibles mejoras futuras, incluyendo la programación de oráculos con
muchas características, las modificaciones de la infraestructura de la fuente
1
de datos y la ejecución de contratos inteligentes confidenciales.

2
Contenido
1 Introducción 3
2 Visión general de la arquitectura 4
2.1 La arquitectura de la cadena......................................... .5
2.2 Arquitectura fuera de la cadena........................................... .6

3 Seguridad de Oracle 7

4 Enfoque de descentralización de ChainLink 11

4.1 Distribuir las fuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
4.2 Distribuyendo oráculos . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

5 Servicios de seguridad de ChainLink 16

5.1 Sistema de validación............................................... .16
5.2 Sistema de reputación............................................... .17
Servicio de5.3 Certificación ..................... .19
.....
Servicio de5.4 Contratos de Actualización . . . . . . . . . . .20
.............
5.5 El uso de fichas de enlace............................................ .21

6 Estrategia técnica a largo plazo 21

6.1 Confidencialidad ............................. .21
6.2 Cambios en la infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . .25
6.3 Computación fuera de la .26
cadena.....................................................................................................
7 Soluciones existentes de Oracle 26

8 Conclusión 27

A Agregación fuera de la cadena 33

A.1 Protocolo OCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
A.2 Esbozos de prueba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
A.3 Discusión..................................................... .37

B Supuestos de confianza del SGX 38

3
1 Introducción
Los contratos inteligentes son aplicaciones que se ejecutan en una infraestructura
descentralizada, como una cadena de bloques. Son a prueba de manipulaciones,
en el sentido de que ninguna parte (ni siquiera su creador) puede alterar su
código o interferir con su ejecución. Históricamente, los contratos incorporados
en el código se han ejecutado de manera centralizada, lo que los deja sujetos a la
alteración, terminación e incluso eliminación por una parte privilegiada. En
cambio, las garantías de ejecución de los contratos inteligentes, que obligan a
todas las partes en un acuerdo tal como está escrito, crean un nuevo y poderoso
tipo de relación de confianza que no se basa en la confianza en una sola parte. Al
ser autoverificables y autoejecutables (es decir, a prueba de manipulaciones,
como se ha explicado anteriormente), los contratos inteligentes ofrecen así un
vehículo superior para la realización y administración de acuerdos digitales.
Sin embargo, el nuevo y poderoso modelo de confianza que encarnan los
contratos inteligentes introduce un nuevo desafío técnico: la conectividad. La gran
mayoría de las interesantes[27]1 aplicaciones de los contratos inteligentes se
basan en datos sobre el mundo real que provienen de recursos clave,
específicamente los feeds de datos y los APIs, que son externos a la cadena de
bloqueo. Debido a la mecánica de los mecanismos de consenso que sustentan las
cadenas de bloques, una cadena de bloques no puede obtener directamente esos
datos críticos.
Proponemos una solución al problema de la conectividad del contrato
inteligente en forma de ChainLink, una red oráculo segura. Lo que diferencia a
ChainLink de otras soluciones de oráculo es su capacidad para funcionar como
una red totalmente descentralizada. Este enfoque descentralizado limita la
confianza en una sola parte, lo que permite que la calidad a prueba de
manipulaciones valorada en los contratos inteligentes se extienda a la operación de
extremo a extremo entre los contratos inteligentes y las API en las que confían. La
sensibilización externa de los contratos inteligentes, es decir, su capacidad de
interactuar con los recursos fuera de la cadena, es necesaria para que sustituyan a
los acuerdos digitales que se utilizan hoy en día.
Hoy en día, la mayor parte de los acuerdos contractuales tradicionales que se
han automatizado digitalmente utilizan datos externos para probar el
cumplimiento de los contratos, y requieren que los resultados de los datos se
trasladen a sistemas externos. Cuando los contratos inteligentes sustituyan a
estos mecanismos contractuales más antiguos, requerirán versiones de alta
seguridad de los mismos tipos de entradas y salidas de datos. Entre los ejemplos de
posibles contratos inteligentes de próxima generación y sus requisitos de datos
cabe citar:

4
 Los contratos de valores inteligentes como los bonos, los derivados de los tipos de
- interés y muchos otros requerirán el acceso a las API que informan sobre los
• precios de mercado y los datos de referencia del mercado, por ejemplo, los
tipos de interés.
1
El principal uso de los contratos inteligentes en el Etéreo hoy en día es la gestión de fichas, que son
una funcionalidad común en la mayoría de las redes de contratos inteligentes. Creemos que el actual
enfoque en los tokens, excluyendo muchas otras posibles aplicaciones, se debe a la falta de servicios de
oráculo adecuados, situación que ChainLink pretende remediar específicamente.

5
 - Los contratos de seguros inteligentes necesitarán datos sobre los datos de IO
• relacionados con el evento asegurable en cuestión, por ejemplo: ¿estaba la
puerta magnética del almacén cerrada en el momento del incumplimiento,
estaba el firewall de la compañía en línea, o el vuelo para el que tenía seguro
llegó a tiempo?

- Los contratos inteligentes de financiación del comercio necesitarán datos del GPS
• sobre los envíos, datos de los sistemas de planificación de recursos
empresariales de la cadena de suministro y datos de aduana sobre las
mercancías que se envíen para confirmar el cumplimiento de las
obligaciones contractuales.

Otro problema común a estos ejemplos es la incapacidad de los contratos

inteligentes de producir datos en sistemas fuera de la cadena. Esa salida suele
adoptar la forma de un mensaje de pago encaminado a la infraestructura
centralizada tradicional en la que los usuarios ya tienen cuentas, por ejemplo,
para pagos bancarios, PayPal y otras redes de pago. La capacidad de ChainLink
para enviar datos de forma segura a las API y a diversos sistemas heredados en
nombre de un contrato inteligente permite la creación de contratos a prueba de
manipulaciones con conocimiento de causa.

Hoja de ruta del Libro Blanco

En este informe*, revisamos la arquitectura de ChainLink (Sección 2). Luego
explicamos cómo definimos la seguridad de los oráculos (Sección 3). Describimos
el enfoque de ChainLink para la descentralización/distribución de oráculos y
fuentes de datos (Sección 4), y seguimos con una discusión de los cuatro servicios
de seguridad propuestos por ChainLink, así como el papel que juegan los tokens
de LINK (Sección 5). A continuación, describimos una estrategia de desarrollo a
largo plazo propuesta, que incluye una mejor protección de la confidencialidad, el
uso de hardware de confianza, cambios en la infraestructura y la programabilidad
general de los oráculos (Sección 6). Repasamos brevemente los diseños alternativos
de oráculos (Sección 7), y concluimos con una breve discusión de los principios
de diseño y la filosofía que guían el desarrollo de ChainLink (Sección 8).

2 Visión general de la arquitectura

El objetivo funcional principal de ChainLink es unir dos entornos: dentro y fuera de la
cadena. A continuación describimos la arquitectura de cada componente de
ChainLink. ChainLink se construirá inicialmente sobre Ethereum [16], [35], pero
pretendemos que sea compatible con todas las principales redes de contratos
6
inteligentes tanto para las interacciones fuera de la cadena como para las
interacciones entre cadenas. Tanto en su versión dentro como fuera de la cadena,
ChainLink ha sido diseñado con la modularidad en mente. Cada pieza del sistema
ChainLink es actualizable, de modo que los diferentes componentes pueden ser
reemplazados a medida que surjan mejores técnicas e implementaciones
competitivas.

7
2.1 Arquitectura en cadena
Como servicio de oráculo, los nodos ChainLink devuelven las respuestas a las
solicitudes o consultas de datos realizadas por o en nombre de un contrato de
usuario, a las que nos referimos como contratos de solicitud y que denotan el USER-
SC. La interfaz en cadena de ChainLink para solicitar contratos es en sí misma un
contrato en cadena que denominamos CHAINLINK-SC.
Detrás de CHAINLINK-SC, ChainLink tiene un componente en cadena que consiste
en tres contratos principales: un contrato de reputación, un contrato de coincidencia de
pedidos y un contrato de agregación. El contrato de reputación hace un seguimiento del
rendimiento del proveedor de servicios de oracle
métricas. El contrato inteligente de ajuste de pedidos toma un acuerdo de nivel de
servicio propuesto, registra los parámetros del SLA y recoge las ofertas de los
proveedores del oráculo. Luego selecciona las ofertas usando el contrato de
reputación y finaliza el SLA de oracle. El contrato de agregación recoge las
respuestas de los proveedores de oráculos y calcula el resultado colectivo final de
la consulta ChainLink. También alimenta la métrica del proveedor del oráculo en
el contrato de reputación. Los contratos ChainLink están diseñados de manera
modular, lo que permite que sean configurados o reemplazados por los usuarios
según sea necesario. El flujo de trabajo en la cadena tiene tres pasos: 1) selección
del oráculo, 2) reporte de datos, 3) agregación de resultados.

Selección de Oracle Un comprador de servicios de oráculo especifica los requisitos

que conforman una propuesta de acuerdo de nivel de servicio (SLA). La propuesta
de SLA incluye detalles como los parámetros de consulta y el número de oráculos
que necesita el comprador. Además, el comprador especifica la reputación y los
contratos de agregación que se utilizarán para el resto del acuerdo.
Utilizando la reputación que se mantiene en la cadena, junto con un conjunto
más sólido de datos recogidos de los registros de contratos anteriores, los
compradores pueden clasificar, filtrar y seleccionar oráculos manualmente a
través de servicios de listado fuera de la cadena. Nuestra intención es que
ChainLink mantenga uno de esos servicios de listado, recogiendo todos los
registros relacionados con ChainLink y verificando los binarios de los contratos
de oráculos listados. Detallamos más el servicio de listado y los sistemas de
reputación en la Sección 5. Los datos utilizados para generar los listados serán
extraídos de la cadena de bloques, permitiendo la construcción de servicios
alternativos de listado de oráculos. Los compradores presentarán propuestas de
SLA a los oráculos fuera de la cadena, y llegarán a un acuerdo antes de finalizar el
SLA en la cadena.
La comparación manual no es posible para todas las situaciones. Por ejemplo,
un contrato puede necesitar solicitar servicios de oráculo dinámicamente en
respuesta a su carga. Las soluciones automatizadas resuelven este problema y
mejoran la usabilidad. Por estas razones, ChainLink también propone la
8
equiparación automatizada de oráculos mediante el uso de contratos de
equiparación de pedidos.
Una vez que el comprador haya especificado su propuesta de SLA, en lugar de
ponerse en contacto directamente con los ora- clones, someterá el SLA a un
contrato de ajuste de pedidos. La presentación de la propuesta al contrato de
coincidencia de órdenes desencadena un registro que los proveedores de oráculos
pueden

9
monitorear y filtrar en base a sus capacidades y objetivos de servicio. Los nodos
de ChainLink eligen entonces si licitan o no la propuesta, y el contrato sólo acepta
ofertas de los nodos que cumplen los requisitos del SLA. Cuando un proveedor de
servicios de oráculo licita un contrato, se compromete a ello, específicamente
adjuntando el importe de la pena que se perdería debido a su mal
comportamiento, tal como se define en el SLA.
Las ofertas son aceptadas por la totalidad de la ventana de licitación. Una vez
que el SLA ha recibido suficientes ofertas calificadas y la ventana de licitación ha
terminado, se selecciona el número de oráculos solicitado del conjunto de
ofertas. Los pagos de penalizaciones que se ofrecieron durante el proceso de
licitación se devuelven a los oráculos que no fueron seleccionados, y se crea un
registro de SLA finalizado. Cuando el SLA finalizado se registra, se activa un
registro que notifica a los oráculos seleccionados. A continuación, los oráculos
realizan la asignación detallada por el SLA.

Reporte de datos Una vez creado el nuevo registro del oráculo, los oráculos fuera
de la cadena ejecutan el acuerdo e informan de nuevo en la cadena. Para más
detalles sobre las interacciones fuera de la cadena, ver las secciones 2.2 y 4.

Agregación de resultados Una vez que los oráculos hayan revelado sus resultados
al con- tracto oráculo, sus resultados serán alimentados al contrato de
agregación. El contrato de agregación cuenta los resultados colectivos y calcula
una respuesta ponderada. La validez de cada respuesta del oráculo se comunica
entonces al contrato de reputación. Finalmente, la respuesta ponderada se
devuelve a la función de contrato especificada en USER-SC.
La detección de valores alejados o incorrectos es un problema específico de
cada tipo de alimentación y aplicación de datos. Por ejemplo, la detección y el
rechazo de las respuestas periféricas antes del promedio pueden ser necesarios
para los datos numéricos pero no para los booleanos. Por esta razón, no habrá un
contrato de agregación específico, sino una dirección de contrato configurable
que sea especificada por el comprador. ChainLink incluirá un conjunto estándar
de contratos de agregación, pero también se podrán especificar contratos
personalizados, siempre que se ajusten a la interfaz de cálculo estándar.

2.2 Arquitectura fuera de la cadena

Fuera de la cadena, ChainLink consiste inicialmente en una red de nodos
oráculos conectados a la red Ethereum, y pretendemos que apoye a todas las
principales redes de contratos inteligentes. Estos nodos recogen de forma
independiente las respuestas a las solicitudes de fuera de la cadena. Como
explicamos a continuación, sus respuestas individuales se agregan a través de uno
10
de varios mecanismos de consenso posibles en una respuesta global que se
devuelve a un solicitante de contrato USER-SC. Los nodos de ChainLink se
alimentan de la implementación del núcleo estándar de código abierto que maneja
las interacciones estándar de la cadena de bloqueo, la programación y la conexión con
los recursos externos comunes. Los operadores de los nodos pueden elegir añadir
software

11
extensiones, conocidas como adaptadores externos, que permiten a los
operadores ofrecer servicios adicionales especializados fuera de la cadena. Los
nodos ChainLink ya se han desplegado a lo largo de las cadenas de bloqueo
públicas y las redes privadas en el ámbito empresarial; la motivación de la red
ChainLink es permitir que los nodos funcionen de manera descentralizada.

ChainLink Core. El software del nodo central es responsable de la interfaz con la

cadena de bloques, la programación y el equilibrio del trabajo a través de sus
diversos servicios externos. El trabajo realizado por los nodos ChainLink se
formatea como asignaciones. Cada asignación es un conjunto de especificaciones
de trabajo más pequeñas, conocidas como subtareas, que se procesan como un
pipeline. Cada subtarea tiene una operación específica que realiza, antes de pasar
su resultado a la siguiente subtarea, y finalmente llegar a un resultado final. El
software de nodos de ChainLink viene con algunas subtareas incorporadas,
incluyendo peticiones HTTP, análisis sintáctico JSON y conversión a varios
formatos de cadenas de bloques.

Adaptadores externos. Más allá de los tipos de subtareas incorporadas, las

subtareas personalizadas pueden ser definidas creando adaptadores. Los
adaptadores son servicios externos con un mínimo de REST API. Al modelar los
adaptadores de una manera orientada al servicio, los programas en cualquier
lenguaje de programación ming pueden ser fácilmente implementados
simplemente añadiendo una pequeña API intermedia delante del programa. Del
mismo modo, la interacción con APIs complicadas de varios pasos puede
simplificarse a subtareas individuales con parámetros.

Esquemas de subtareas. Anticipamos que muchos adaptadores serán de fuente

abierta, para que los servicios puedan ser auditados y administrados por varios
miembros de la comunidad. Dado que muchos tipos diferentes de adaptadores
están siendo desarrollados por muchos desarrolladores diferentes, es esencial
asegurar la compatibilidad entre los adaptadores.
Actualmente ChainLink funciona con un sistema de esquema basado en el
JSON Schema [36], para especificar qué entradas necesita cada adaptador y cómo
deben ser formateadas. Sim- larmente, los adaptadores especifican un esquema
de salida para describir el formato de la salida de cada subtarea.

3 Seguridad de Oracle
Para explicar la arquitectura de seguridad de ChainLink, primero debemos
explicar por qué la curiosidad es importante y lo que significa.
12
¿Por qué los oráculos deben ser seguros? Volviendo a nuestros simples ejemplos en
la sección 1, si un contrato de seguridad inteligente recibe una alimentación de
datos falsos, puede pagar a la parte incorrecta, si las alimentaciones de datos del
contrato inteligente pueden ser manipuladas por la parte asegurada

13
Figura 1: Flujo de trabajo de ChainLink: 1) El USER-SC hace una solicitud en la
cadena; 2) El CHAINLINK-SC registra un evento para los oráculos; 3) El núcleo de
ChainLink recoge el evento y enruta la asignación a un adaptador; 4) El adaptador
ChainLink realiza una solicitud a una API externa; 5) El adaptador ChainLink procesa
la respuesta y la devuelve al núcleo; 6) El núcleo de ChainLink reporta los datos al
CHAINLINK-SC; 7) El CHAINLINK-SC agrega las respuestas y las devuelve como una sola
respuesta al USER-SC.

puede haber fraude al seguro, y si los datos del GPS dados a un contrato de
financiación comercial pueden ser modificados después de que salga del
proveedor de datos, el pago puede ser liberado para las mercancías que no han
llegado.
En términos más generales, una cadena de bloques que funciona bien, con su
libro de contabilidad o su tablón de anuncios, ofrece propiedades de seguridad
muy fuertes. Los usuarios confían en la cadena de bloqueo como una
funcionalidad que valida correctamente las transacciones y evita que los datos
sean alterados. La tratan en efecto como un tercero de confianza (un concepto
que discutiremos en detalle más adelante). Un servicio de oráculo de apoyo debe
ofrecer un nivel de seguridad acorde con el de la cadena de bloques que soporta.
Por lo tanto, un oráculo también debe servir a los usuarios como un tercero de
confianza efectivo, proporcionando respuestas correctas y oportunas con una
probabilidad muy alta. La seguridad de cualquier sistema es tan fuerte como su
eslabón más débil, por lo que se requiere un oráculo altamente confiable para
preservar la confiabilidad de una cadena de bloques bien diseñada.

Definiendo la seguridad del oráculo: Una vista ideal. Para poder razonar sobre la
seguridad del oráculo, primero debemos definirla. Una forma instructiva y de
principios para razonar sobre la seguridad del oráculo proviene del siguiente
experimento de pensamiento. Imagina que un tercero de confianza (TTP) -una
entidad o funcionalidad ideal que siempre lleva a cabo las instrucciones fielmente
al pie de la letra- se encargara de ejecutar un oráculo. Denominaremos a este
oráculo por ORACLE (usando todas las mayúsculas en general para denotar una
entidad en la que los usuarios confían plenamente), y supongamos que el TTP
14
 obtiene datos de una fuente de datos perfectamente fiable Src. Dado este servicio
mágico de ORACLE, ¿qué instrucciones le pediríamos que llevara a cabo? Para
lograr la propiedad de integridad, también conocida como el propulsor de
autenticidad-
En el caso de la compañía de seguros, simplemente le pediríamos a ORACLE que realizara los
siguientes pasos:

15
Figura 2: El comportamiento de un oráculo ideal ORÁCULO se define por pasos: 1)
Aceptar la solicitud; 2) Obtener datos; 3) Devolver los datos. Además, para proteger la
confidencialidad de una solicitud, al desencriptarla, ORÁCULO nunca utiliza o revela los
datos que contiene, excepto para consultar Src.

1. Acepte la solicitud: Ingerir de un contrato inteligente USUARIO-SC una solicitud

Req = (Src, τ, q) que especifica una fuente de datos de destino Src, un tiempo
o rango de tiempos τ , y una consulta q;
2. Obtener datos: Envíe la consulta q a Src a tiempo τ ;
3. Devuelve los datos: Al recibir la respuesta a, devolver a al contrato inteligente.

Estas sencillas instrucciones, correctamente llevadas a cabo, definen una

fuerte, significativa, pero simple noción de seguridad. Intuitivamente, dictan que
ORÁCULO actúa como un confiable
puente entre Src y USER-SC. 2 Por ejemplo, si Src es https://www.FountOfKnowledge.com,
τ es a las 4 p.m., y q = "precio del teletipo INTC", la integridad de ORACLE garantiza
que proporcionará al USUARIO-SC exactamente el precio del INTC tal y como se ha
consultado a las 4 p.m. en https://www.FountOfKnowledge.com
La confidencialidad es otra propiedad deseable para los oráculos. Como USER-SC
envía Req a ORACLE en el claro de la cadena de bloques, Req es público. Hay
muchas situaciones en las que la Req es sensible y su publicación podría ser
perjudicial. Si el USER-SC es un contrato de seguro de vuelo, por ejemplo, y envía a
ORACLE una solicitud de información sobre el vuelo de un usuario en particular (q
= "Ether Air Flight 338"), el resultado sería que los planes de vuelo de un usuario se
revelan a todo el mundo. Si USER-SC es un contrato para
2Por supuesto, muchos detalles se omiten aquí. ORACLE debe comunicarse con el USUARIO-SC y con

el Src de origen a través de canales seguros, es decir, a prueba de manipulaciones. (Si Src es un servidor
web, se requiere TLS. Para comunicarse con el USUARIO-SC, ORACLE debe asegurarse de raspar la cadena
de bloqueo correcta y firmar digitalmente la A apropiadamente).

16
comercio financiero, Req podría filtrar información sobre las operaciones y la
cartera de un usuario. Hay muchos otros ejemplos, por supuesto.
Para proteger la confidencialidad de la Req, podemos exigir que los datos de la
Req sean encriptados bajo una (clave pública) perteneciente a ORACLE.
Continuando con la naturaleza TTP de ORACLE, podríamos entonces simplemente
darle a ORACLE la restricción del flujo de información:

Al desencriptar la Req, nunca revele o use datos en la Req excepto para consultar el Src.
Hay otras propiedades importantes del oráculo, como la disponibilidad, la
última de la clásica tríada CIA (Confidencialidad-Integridad-Disponibilidad). Un
servicio verdaderamente ideal O-ACLE, por supuesto, nunca se vendría abajo. La
disponibilidad también abarca propiedades más sutiles como la resistencia a la
censura: Un ORÁCULO honesto no seleccionará contratos inteligentes parciales y
negará sus peticiones.
El concepto de tercero de confianza es similar a la noción de una función
ideal- alidad [7] utilizada para probar la seguridad de los protocolos
criptográficos en ciertos modelos. También podemos modelar una cadena de
bloques en términos similares, conceptualizándola en términos de un TTP que
mantiene un tablero de anuncios ideal. Sus instrucciones son aceptar las
transacciones, validarlas, serializarlas y mantenerlas permanentemente en el
tablón de anuncios, una estructura de datos de sólo apéndice.

Por qué el oráculo ideal (ORÁCULO) es difícil de conseguir. No existe, por supuesto,
una fuente de datos perfectamente fiable, Src. Los datos pueden ser corrompidos
benigna o maliciosamente debido a sitios web defectuosos, proveedores de
servicios tramposos o errores honestos.
Si Src no es confiable, entonces incluso si ORACLE opera exactamente como un
TTP como en la estructura anterior, todavía no cumple completamente con la
noción de seguridad que queremos. Dada una fuente defectuosa Src, la propiedad de
integridad definida arriba ya no significa que un oráculo
La respuesta A es correcta. Si el precio real de Intel es de 40 dólares y
https://www.FountOfKnowledge.com lo informa erróneamente como 50 dólares, por
ejemplo, entonces ORACLE enviará el valor incorrecto a = 50 dólares
a USER-SC. Este problema es inevitable cuando se utiliza una sola fuente Src.
ORACLE simplemente no tiene forma de saber si las respuestas que el Src
proporciona a sus consultas son correctas. Un problema mayor, por supuesto, es
el hecho de que nuestro TTP para ORACLE es sólo una abstracción. Ningún
proveedor de servicios es incondicionalmente confiable. Incluso el mejor
intencionado
puede ser de buggy o hackeado. Por lo tanto, no hay manera de que un usuario o
un contrato inteligente tenga la absoluta seguridad de que un servicio ORACLE
llevará a cabo sus instrucciones fielmente.
ChainLink razona sobre sus protocolos de seguridad en términos de esta

17
funcionalidad ideal ORACLE. Nuestro objetivo en ChainLink es conseguir un
sistema en el mundo real con propiedades lo más cercanas posibles a las de ORACLE
bajo supuestos de confianza realistas. Ahora explicamos cómo.
Para simplificar lo que sigue, ahora denotamos por CHAINLINK-SC el conjunto
completo de contratos de ChainLink, es decir, su completa funcionalidad en
cadena (no sólo su interfaz

18
a la solicitud de contratos). De este modo, abstrajimos los múltiples contratos
individuales que se utilizan realmente en la arquitectura del sistema.

4 Enfoque de descentralización de ChainLink

Proponemos tres enfoques básicos complementarios para asegurarnos contra los nodos
defectuosos:
1) Distribución de las fuentes de datos; 2) Distribución de los oráculos; y 3)
Utilización de equipo informático de confianza. En esta sección se examinan los
dos primeros enfoques, que entrañan la descentralización. En la sección 6 se analiza
nuestra estrategia a largo plazo para el equipo informático de confianza, un
enfoque diferente y complementario.

4.1 Distribuir las fuentes

Una forma sencilla de tratar con un Src de una sola fuente defectuosa es obtener
datos de múltiples fuentes, es decir, distribuir la fuente de datos. Un ORÁCULO
fiable puede consultar una colección de fuentes Src1, Src2, . . . , Srck, obtener
respuestas a1, a2, . . . , ak, y agregarlas en una sola respuesta A = agg(a1, a2, . . . ,
ak). ORACLE puede hacer esto de varias maneras. Una, por ejemplo, es la votación
por mayoría. Si una mayoría de fuentes devuelve el valor idéntico a, la función agg
devuelve a; de lo contrario, devuelve un error. En este caso, siempre que una
mayoría (> k/2) de fuentes funcione correctamente, ORACLE siempre devolverá un
valor correcto a.
Muchas funciones alternativas pueden garantizar la solidez frente a datos
erróneos o manejar las fluctuaciones de los valores de los datos a lo largo del
tiempo (por ejemplo, los precios de las acciones). Por ejemplo, agg podría
descartar los valores atípicos (por ejemplo, los valores más grandes y más
pequeños ai) y producir la media de los restantes.
Por supuesto, las fallas pueden correlacionarse entre las fuentes de datos de
manera que se debiliten las garantías que ofrece la agregación. Si el sitio Src1 =
EchoEcho.com obtiene sus datos de Src2 = TheHorsesMouth.com, un error en Src2
siempre implicará un error en Src1. También pueden ocurrir correlaciones más
sutiles entre las fuentes de datos. Chainlink también propone que se investigue la
independencia de las fuentes de datos de forma fácilmente digerible para que los
oráculos y los usuarios puedan evitar correlaciones no deseadas.

4.2 Distribuir oráculos

Así como las fuentes pueden ser distribuidas, nuestro servicio ideal, ORACLE,
puede ser aproximado como un sistema distribuido. Es decir, en lugar de un
único nodo oráculo monolítico O, podemos tener una colección{}de n diferentes
19
nodos oráculos O1,O 2, ... O n... Cada oráculo Oi se pone en contacto con su propio
conjunto de fuentes de datos que pueden o no pueden

20
Figura 3: Las solicitudes se distribuyen en ambos oráculos y fuentes de datos. Esta
figura muestra un ejemplo de esa distribución en dos niveles.

se superponen con los de otros oráculos. Oi agrega las respuestas de sus fuentes
de datos y produce su propia respuesta distinta Ai a una consulta Req.
Algunos de estos oráculos pueden ser defectuosos. Así que claramente el
conjunto de todas las respuestas de los oráculos A1, A2, . . . ...A, deberá ser agregada
de manera confiable en un único valor iterativo de autor A. Pero dada la
posibilidad de oráculos defectuosos, ¿dónde y cómo ocurrirá esta agregación en
ChainLink?

Solución inicial: Agregación en el contrato. Nuestra solución inicial propuesta en

ChainLink será una simple llamada agregación dentro del contrato. CHAINLINK-SC-
que, de nuevo, denota la parte en cadena de ChainLink- agregará por sí misma las
respuestas del oráculo. (Alternativamente, CHAINLINK-SC puede llamar a otro
contrato de agregación, pero por simplicidad conceptual asumimos que los dos
componentes forman un solo contrato). En otras palabras, CHAINLINK-SC calculará
A = Agg(A1, A2, . . . , An) para alguna función Agg (similar a agg, como se describe
arriba), y enviará el resultado A al USUARIO-SC.
Este enfoque es práctico para la pequeña n, y tiene varios beneficios distintos:

- Simplicidad conceptual: A pesar de que el oráculo está distribuido, una sola

• entidad, CHAINLINK-SC, realiza la agregación ejecutando Agg.
- Confianza: Como el código de CHAINLINK-SC puede ser inspeccionado
• públicamente, su comportamiento correcto puede ser verificado.
(CHAINLINK-SC será una pieza de código relativamente pequeña y simple.)
Además, la ejecución de CHAINLINK-SC es totalmente visible en

21
 cadena. Así, los usuarios, es decir, los creadores de USER-SC, pueden lograr
un alto grado de confianza en CHAINLINK-SC.

- Flexibilidad: CHAINLINK-SC puede implementar la mayoría de las funciones de

• agregación deseadas
Agg - la función de la mayoría, el promedio, etc.

Por simple que sea, este enfoque presenta un novedoso e interesante desafío
técnico, a saber, el problema de la carga gratuita. Un oráculo tramposo Oz puede
observar la respuesta Ai de otro oráculo Oi y copiarla. De esta manera, el oráculo
Oz evita el gasto de consultar las fuentes de datos, que pueden cobrar por cada
consulta. La carga gratuita debilita la seguridad al socavar la diversidad de las
consultas de las fuentes de datos y también desincentiva a los oráculos a
responder rápidamente: Responder lentamente y el "freeloading" es una
estrategia más barata.
Sugerimos una solución bien conocida a este problema, a saber, el uso de un
esquema de compromiso/revelación. En una primera ronda, los oráculos envían
compromisos criptográficos CHAINLINK-SC a sus respuestas. Después de que
CHAINLINK-SC ha recibido un quórum de respuestas, inicia una segunda ronda en
la que los oráculos revelan sus respuestas.
El algoritmo 1 muestra un simple protocolo secuencial que garantiza la
disponibilidad dada 3f + 1 nodos. Utiliza un esquema de compromiso/revelación
para prevenir la carga gratuita. Las respuestas de los oráculos se descomprimen y,
por lo tanto, se exponen a un posible aprovechador sólo después de que se hayan
hecho todos los compromisos, excluyendo así al aprovechador de copiar las
respuestas de otros oráculos.
Los protocolos de la cadena pueden aprovechar los tiempos de bloqueo para
soportar los desvíos de los protocolos sincrónicos. En ChainLink, sin embargo, los
nodos oráculos obtienen datos de fuentes que pueden tener tiempos de respuesta
muy variables, y los tiempos de descompromiso de los nodos pueden variar
debido, por ejemplo, al uso de diferentes precios del gas en el Etéreo. Por lo
tanto, para asegurar la respuesta más rápida posible del protocolo, Alg. 1 está
diseñado como un protocolo asíncrono.
Aquí, Commitr(A) denota un compromiso de valor A con el testigo r, mientras que SID
denota el conjunto de identificaciones de sesión válidas. El protocolo asume
canales autentificados entre todos los jugadores.
Es fácil ver a ese Alg. 1 terminará con éxito. Dados 3f + 1 nodos en total, a lo
sumo f son defectuosos, así que al menos 2f + 1 enviará compromisos en el paso
4. De esos compromisos, a lo sumo f provienen de nodos defectuosos, así que al
menos f + 1 provienen de nodos honestos. Todos esos compromisos serán
eventualmente liberados.
Además, es fácil ver que A será correcto en Alg.1. De las
22
descompromisos de f + 1 en el valor único A, al menos uno tiene que provenir de
un nodo honesto. La agregación en el contrato a través de Alg. 1 será el enfoque
principal apoyado por Chain- Link a corto plazo. La implementación inicial
propuesta implicará una variante del algoritmo más sofisticada y concurrente.
Nuestra propuesta a largo plazo se refleja
en el protocolo bastante más complicado OCA (Off-Chain Aggregation)
especificado en los Algoritmos 2 y 3 del Apéndice A. OCA es un protocolo de
agregación fuera de la cadena que

23
Algoritmo 1 InChainAgg({Oi}n )i=(código para CHAINLINK-SC)
1
1: Espere hasta que se reciba la solicitud de USER-SC.
2: sid$←SID
3: Emisión (petición, sid).
4: Espere hasta que el conjunto C de 2f + 1 mensajes (commit, ci = Commitri (Ai), sid) de
distinto
Oi son recibidos.
5: Emisión (comprometida, sid).
6: Espere hasta que el conjunto D de f + 1 distinto de descompromisos válidos
(decommit, (ri, Ai), sid)
se reciben donde, para algunos A, todo Ai = A.
7: Enviar (Respuesta, A, sid) a USER-SC.

minimiza los costos de transacción en la cadena. Ese protocolo también incluye el

pago a los nodos oráculos y asegura contra los pagos a los gorrones.

Estrategia de mediano plazo: Agregación fuera de la cadena. La agregación dentro de

la cadena tiene una desventaja clave: El costo. Incurre en el costo de transmitir y
procesar en la cadena O(n) mensajes de oráculo (compromete y revela para A1, A2, .
. . , An). En las cadenas de bloques permitidas, esta sobrecarga puede ser aceptable.
En las cadenas de bloqueos permitidas con tarifas de transacción en cadena como
Ethereum, si n es grande, los costos pueden ser prohibitivos. Un enfoque más
rentable es agregar las respuestas del oráculo fuera de la cadena y transmitir un solo
mensaje a CHAINLINK-SC A. Proponemos el despliegue de este enfoque, llamado
agregación fuera de la cadena, a mediano y largo plazo.
El problema de lograr un valor de consenso A frente a nodos potencialmente
defectuosos es muy parecido al problema de consenso que sustenta las propias
cadenas de bloques. Dado un conjunto predeterminado de oráculos, se podría
considerar la posibilidad de utilizar un algoritmo de consenso bizantino clásico de
tolerancia a las fallas (BFT) para calcular A. Los protocolos clásicos de BFT, sin
embargo, tienen por objeto garantizar que al final de una invocación de protocolo,
todos los nodos honestos almacenen el mismo valor, por ejemplo, en una cadena
de bloques, que todos los nodos almacenen el mismo bloque nuevo. En nuestra
configuración de oráculo, el objetivo es ligeramente diferente. Queremos
asegurarnos de que CHAINLINK-SC (y luego USER-SC) obtenga la respuesta agregada
A = Agg(A1, A2, . . . , An) sin participar en el protocolo de consenso y sin necesidad de recibir
respuestas de múltiples oráculos. Además, el problema de la carga gratuita todavía
tiene que ser abordado.
El sistema ChainLink propone el uso de un protocolo simple que implica la
utilización de firmas de trinquete. Esas firmas pueden realizarse utilizando
24
cualquiera de una serie de esquemas de firma, pero son especialmente sencillas
de implementar utilizando firmas Schnorr [4]. En este enfoque, los oráculos
tienen una clave pública colectiva pk y una clave privada correspondiente sk que se
comparte entre O1,O 2, . O n de una manera (t, n) de umbral [3]. Tal compartición
significa que cada nodo Oi tiene un par de claves privadas/públicas distintas (ski,
pki). Oi puede

25
 Figura 4: Sigsk[A] puede ser alcanzado por cualquier n/2+1 de los oráculos.
generar una firma parcial σi = Sigski [Ai] que puede ser verificada con respecto a pki.
La característica fundamental de esta configuración es que las firmas parciales
en el mismo valor A pueden agregarse a través de cualquier conjunto de oráculos t
para producir una única firma colectiva válida
− Σ = Sigsk[A] en una respuesta A. Sin
embargo, ningún conjunto de oráculos t 1 puede producir una firma válida en
ningún valor. Así pues, la firma única Σ encarna implícitamente la
firmas de por lo menos t oráculos.
Las firmas de los umbrales pueden realizarse ingenuamente dejando que Σ
consista explícitamente en un conjunto de firmas t válidas e independientes de los
nodos individuales. Las firmas de umbral tienen propiedades de seguridad
similares a este enfoque ingenuo. Pero proporcionan una mejora significativa en
el rendimiento de la cadena: Reducen el tamaño y el costo de la verificación de Σ
por un factor de t.
Con esta configuración, parece que los oráculos pueden generar y emitir
firmas parciales hasta que dichas firmas parciales permitan el cálculo de Σ. De
nuevo, sin embargo, surge el problema de la carga gratuita. Por lo tanto, debemos
asegurarnos de que los oráculos obtengan realmente datos de sus fuentes
designadas, en lugar de engañar y copiar a Ai de
otro oráculo. Nuestra solución implica un mecanismo financiero: Una entidad PROVEEDORA
(realizable como un contrato inteligente) recompensa sólo a los oráculos que han
obtenido datos originales por sus firmas parciales.
En un entorno distribuido, determinar qué oráculos cumplen los requisitos
para recibir el pago resulta difícil. Los oráculos pueden intercomunicarse fuera de
la cadena y ya no tenemos una entidad autoritaria de pecado (CHAINLINK-SC) que
26
reciba respuestas y por lo tanto no son...

27
capaz de identificar a los beneficiarios elegibles directamente entre los oráculos
participantes. En consecuencia, el PROVEEDOR debe obtener pruebas de mal
comportamiento de los propios oráculos, algunas de las cuales pueden ser poco
fiables. Proponemos el uso de mecanismos de consenso en nuestra solución para
ChainLink para asegurar que PROVEEDOR no pague a los oráculos que se cargan
gratis.
El sistema de agregación fuera de la cadena que proponemos para ChainLink,
con los bocetos de prueba de seguridad que lo acompañan, puede encontrarse en
el Apéndice A. Utiliza un protocolo distribuido basado en firmas de umbral que
proporciona resistencia a la carga por oráculos f < n/3. Creemos que la resistencia
a la carga gratuita es un nuevo e interesante problema técnico.

5 Servicios de seguridad de ChainLink

Gracias a los protocolos que acabamos de describir en el apartado anterior,
ChainLink se propone asegurar la disponibilidad y la corrección frente a oráculos
hasta f defectuosos. Además, el hardware de confianza, como se discute en la
sección 6, está siendo considerado activamente como un enfoque seguro para
protegerse de oráculos corruptos que proporcionan respuestas incorrectas. El
hardware de confianza, sin embargo, puede no proporcionar una protección definitiva
por tres razones. En primer lugar, no se desplegará en las versiones iniciales de la
red ChainLink. En segundo lugar, es posible que algunos usuarios no confíen en el
equipo informático de confianza (véase el apéndice B para más información). Por
último, el hardware de confianza no puede proteger contra el tiempo de
inactividad de los nodos, sólo contra el mal comportamiento de los nodos. Por lo
tanto, los usuarios desearán asegurarse de que pueden elegir los oráculos más
fiables y minimizar la probabilidad de que el USER-SC confíe en > f oráculos
defectuosos. Para ello, proponemos el uso de cuatro servicios de seguridad clave:
un Sistema de Validación,
un sistema de reputación, un servicio de certificación y un servicio de actualización de
contratos. Todos estos servicios pueden ser dirigidos inicialmente por una empresa o
grupo interesado en el lanzamiento de la red ChainLink, pero están diseñados para
funcionar estrictamente de acuerdo con la filosofía de diseño descentralizado de
ChainLink. Los servicios de seguridad propuestos por ChainLink no pueden
bloquear la participación de los nodos de oráculo ni alterar las respuestas de los
oráculos. Los tres primeros servicios sólo proporcionan calificaciones u
orientación a los usuarios, mientras que el servicio de actualización de contratos
es totalmente opcional para los usuarios. Además, estos servicios están diseñados
para apoyar a los proveedores independientes, cuya participación debería
fomentarse de modo que los usuarios dispongan eventualmente de múltiples
servicios de seguridad entre los que elegir.
28
5.1 Sistema de validación
El Sistema de Validación de ChainLink monitoriza el comportamiento de los
oráculos de la cadena, proporcionando una métrica objetiva de rendimiento que
puede guiar al usuario en la selección de los oráculos. Buscará monitorear los
oráculos para:

29
 - Disponibilidad: El Sistema de Validación debe registrar los fallos de un
• oráculo para poder responder oportunamente a las consultas. Recopilará
estadísticas de tiempo de funcionamiento continuo.

- Corrección: El sistema de validación debería registrar las respuestas

• aparentemente erróneas de un oráculo, medidas por las desviaciones de las
respuestas proporcionadas por los pares. 3

En nuestro sistema inicial de agregación en cadena en ChainLink, tal

monitoreo es sencillo, ya que toda la actividad del oráculo es visible para
CHAINLINK-SC.
Recordemos, sin embargo, que en el sistema de agregación fuera de la cadena
previsto para ChainLink, son los propios oráculos los que realizan la agregación.
En consecuencia, CHAINLINK-SC no tiene visibilidad directa de las respuestas de los
oráculos y no puede monitorear por sí mismo la disponibilidad-
la habilidad y la corrección.
Afortunadamente, los oráculos firman digitalmente sus respuestas, y así, como
efecto secundario, gen- erate evidencia no repudiable de sus respuestas. Por lo tanto,
nuestro enfoque propuesto será realizar el servicio de validación como un contrato
inteligente que recompensaría a los oráculos por presentar pruebas de respuestas
desviadas. En otras palabras, se incentivaría a los oráculos a informar sobre
comportamientos aparentemente erróneos.
La disponibilidad es algo más difícil de vigilar, ya que los oráculos, por
supuesto, no señalan su falta de respuesta. En cambio, una propuesta de mejora del
protocolo requeriría que los oráculos firmaran digitalmente atestados del conjunto
de respuestas que han recibido de otros oráculos. El contrato de validación
aceptaría entonces (y de nuevo recompensaría) la presentación de conjuntos de
atestados que demuestren la falta de respuesta constante de un oráculo de
formación inferior a sus pares.
En ambos casos, la disponibilidad y la exactitud de las estadísticas de los
oráculos serán visibles en la cadena. Los usuarios / desarrolladores podrán así
verlas en tiempo real a través de un front end apropiado, como un Dapp en
Ethereum o una aplicación equivalente para una cadena de bloqueo permitida.

5.2 Sistema de reputación

El Sistema de Reputación propuesto para ChainLink registraría y publicaría las
calificaciones de los usuarios de los proveedores y nodos del oráculo, ofreciendo un
medio para que los usuarios evalúen el desempeño del oráculo de manera holística. Es
probable que los informes del Sistema de Validación sean un factor importante
para determinar la reputación de los oráculos y para que éstos tengan una base
firme de confianza. Sin embargo, factores más allá de la historia de la cadena pueden

30
proporcionar información esencial sobre el nodo del oráculo
3"Desviación" debe definirse de manera específica para cada dato. Para respuestas booleanas simples -

por ejemplo, si un vuelo llegó a tiempo- la desviación significa simplemente una respuesta opuesta a la de
la mayoría. Para, digamos, la temperatura de una ciudad, que puede variar legítimamente a través de los
sensores y fuentes, la desviación puede significar una desviación numérica significativa. Por supuesto, por
varias razones, por ejemplo, sen- sores rotos, incluso un oráculo que funcione bien puede desviarse de la
respuesta de la mayoría en alguna fracción del tiempo.

31
perfiles de seguridad. Estos pueden incluir la familiaridad de los usuarios con las
marcas de los oráculos, las entidades operativas y las arquitecturas. Prevemos que
el Sistema de Reputación de ChainLink incluya un componente básico en la
cadena donde las calificaciones de los usuarios estén disponibles para que otros
contratos inteligentes los consulten. Además, la métrica de la reputación debería
ser fácilmente accesible fuera de la cadena donde se puedan procesar
eficientemente grandes cantidades de datos y ponderarlos de manera más
flexible.
Para un operador de oráculo determinado, el Sistema de Reputación se
propone inicialmente como soporte de las siguientes métricas, tanto en la
granularidad de los tipos de asignación específicos (véase la Sección 2), como en
general para todos los tipos soportados por un nodo:

- Número total de solicitudes asignadas: El número total de solicitudes pasadas

• que un oráculo ha aceptado, tanto las cumplidas como las no cumplidas.

- Número total de solicitudes completadas: El número total de peticiones pasadas

• que un oráculo ha cumplido. Esto puede promediarse sobre el número de
peticiones asignadas para calcular la tasa de finalización.

- Número total de solicitudes aceptadas: El número total de solicitudes que se han

• considerado aceptables al calcular los contratos en comparación con las
respuestas de los pares. Esto puede promediarse sobre el total de solicitudes
asignadas o el total de solicitudes completadas para obtener una idea de las
tasas de exactitud.

- Tiempo medio de respuesta: Si bien puede ser necesario dar tiempo a las
• respuestas de los oráculos para su confirmación, la puntualidad de sus
respuestas será útil para determinar la puntualidad futura. El tiempo medio
de respuesta se calcula sobre la base de las solicitudes completadas.

- El monto de las multas: Si las multas se fijaran para asegurar el desempeño del
• operador de un nodo, el resultado sería una medición financiera del
compromiso de un proveedor de oráculos de no participar en un ataque de
"estafa de salida", en el que el proveedor se lleva el dinero de los usuarios y
no presta servicios. Esta métrica implicaría una dimensión tanto temporal
como financiera.

Los servicios de alta reputación están fuertemente incentivados en cualquier

mercado para que se comporten correctamente y aseguren una alta disponibilidad
y rendimiento. La retroalimentación negativa de los usuarios supondrá un riesgo
significativo para el valor de la marca, al igual que las penalizaciones asociadas al
mal comportamiento. En consecuencia, prevemos un círculo virtuoso en el que los
32
oráculos que funcionan bien desvelan la buena reputación y la buena reputación
dan lugar a incentivos para un alto rendimiento continuado.

33
5.3 Servicio de certificación
Mientras que nuestros sistemas de validación y reputación tienen como objetivo
abordar una amplia gama de comportamientos defectuosos de los oráculos y se
propone como una forma de asegurar la integridad del sistema en la gran mayoría
de los casos, ChainLink también puede incluir un mecanismo adicional llamado
Servicio de Certificación. Su objetivo es prevenir y/o remediar eventos raros pero
catastróficos, específicamente el engaño en bloque en forma de Sybil y los ataques
espejo, que ahora explicamos.

Sybil y los ataques de espejo. Tanto nuestros proto- cols de agregación simple
como en contrato buscan prevenir la libre carga en el sentido de que los nodos
deshonestos copien las respuestas de los nodos honestos. Pero ninguno de los dos
protege contra los ataques de Sybil [9]. Tales ataques implican un ad- versary que
controla múltiples oráculos ostensiblemente independientes. Este adversario
puede intentar dominar el conjunto de oráculos, haciendo que más de f
oráculos participen en el protocolo de agregación y proporcionen datos
falsos en momentos estratégicos, por ejemplo, para influir en grandes
transacciones en contratos de alto valor. Los quórumes de oráculos tramposos
también pueden surgir no sólo bajo el control de un solo adversario, sino también
mediante la colusión entre múltiples adversarios. Los ataques o fallos que
implican > oráculos son especialmente perniciosos en el sentido de que son
indetectables sólo por el comportamiento en cadena.
Además, para reducir los costos operacionales, un atacante de Sybil puede
adoptar un comportamiento llamado mirroring, en el que hace que los oráculos
envíen respuestas individuales basadas en datos obtenidos de una sola consulta de
fuente de datos. En otras palabras, los oráculos que se comportan mal pueden
compartir datos fuera de la cadena pero pretenden obtener datos de forma
independiente. El espejamiento beneficia a un adversario independientemente de
si decide o no enviar datos falsos. Supone una amenaza de seguridad mucho
menos grave que la falsificación de datos, pero degrada ligeramente la seguridad
en el sentido de que elimina la corrección de errores resultante de las consultas
diversificadas contra una fuente determinada Src. Por ejemplo, si
https://www.datasource.com emite datos erróneos debido, por ejemplo, a un error
desencadenado esporádicamente, varias consultas pueden obtener un resultado
mayoritario correcto.
Los ataques de Sybil que resultan en datos falsos, espejismos y colusión en
general pueden ser eliminados mediante el uso de hardware de confianza en
nuestra estrategia a largo plazo (véase la Sección 6).

Diseño del Servicio de Certificación. El Servicio de Certificación ChainLink trataría

34
de proporcionar una garantía general de integridad y disponibilidad, detectando y
ayudando a evitar el espejamiento y la colusión de quórums de oráculos a corto y
medio plazo. El Servicio de Certificación emitiría avales de proveedores de oráculos de
alta calidad. Volvemos a insistir, como ya se ha señalado, en que el servicio sólo
calificará a los proveedores en beneficio de los usuarios. No tiene por objeto
dictar la participación o no participación de los nodos del oráculo en el sistema.
El Servicio de Certificación apoya los avales basados en varias características del
despliegue y comportamiento del oráculo. Supervisaría las estadísticas del
Sistema de Validación

35
en los oráculos y realizar una verificación puntual post-hoc de las respuestas en la
cadena, especialmente para las transacciones de alto valor, comparándolas con las
respuestas obtenidas directamente de las fuentes de datos representativas. Con
una demanda suficiente de los datos de un proveedor de oráculos, esperamos que
haya suficiente incentivo económico para justificar las auditorías fuera de la
cadena de los proveedores de oráculos, confirmando el cumplimiento de las
normas de seguridad pertinentes, como los controles pertinentes en la Matriz de
controles en la nube de la Cloud Security Alliance (CSA) [26], así como
proporcionar información de seguridad útil para que lleven a cabo auditorías
adecuadas de la fuente y el código de bytes de los oráculos para sus contratos
inteligentes.
Además de la métrica de la reputación, los sistemas automatizados en cadena
y los sistemas automatizados fuera de la cadena para la detección de fraudes, el
Servicio de Certificación está previsto como un medio para identificar los ataques
a Sybil y otros actos ilícitos que los sistemas automatizados en cadena no pueden
identificar. Por ejemplo, si todos los nodos están de acuerdo en que la luna está
hecha de queso verde, ellos
puede causar que el USER-SC ingiera este hecho falso. COMPONENTES DE LA LUNA = {QUESO
VERDE}
se registrarán en la cadena de bloques, sin embargo, y se podrán ver en una revisión post-
hoc.

5.4 Servicio de Contratación de Nivel Superior

Como han demostrado los recientes hackers de contratos inteligentes, la
codificación de contratos inteligentes a prueba de balas es un ejercicio
extremadamente difícil [1], [20], [22]. E incluso si un contrato inteligente ha sido
programado correctamente, los cambios ambientales o los errores pueden
resultar en vulnerabilidades, por ejemplo, [2].
Por esta razón, proponemos un Servicio de Contratación de Niveles. Hacemos
hincapié en que el uso de este servicio es totalmente opcional y en control de los
usuarios.
A corto plazo, si se descubren vulnerabilidades, el Servicio de Actualización de
Contratos simplemente pondría a disposición de ChainLink un nuevo conjunto de
contratos de oráculo de apoyo. Los contratos inteligentes de solicitud recién
creados podrán entonces migrar al nuevo conjunto de contratos de oracle.
Sin embargo, desafortunadamente, los existentes se quedarían con el viejo y
potencialmente vulnerable conjunto. Por lo tanto, a largo plazo, CHAINLINK-SC
apoyaría una bandera (MIGFLAG) en las llamadas de oráculo de los contratos de
solicitud que indican si una llamada debe o no ser desviada a un nuevo
CHAINLINK-SC en caso de que esté disponible. Establecido por defecto (es decir, si
falta el indicador) en falso, el MIGFLAG permitiría que los contratos solicitantes se
36
beneficiaran de un reenvío automático y, por tanto, de la migración a la nueva
versión del CHAINLINK-SC. Para activar el reenvío, un usuario hará que su contrato
solicitante emita solicitudes de ChainLink con MIGFLAG = true. (Los usuarios
pueden diseñar sus contratos inteligentes de forma que cambien este indicador al
recibir una instrucción para hacerlo
en la cadena de un administrador de contratos autorizado).
La migración de los usuarios a los nuevos contratos de oráculo funciona como
una especie de "escotilla de escape", algo por lo que abogaron durante mucho
tiempo los investigadores de cadenas de bloqueo (véase, por ejemplo, [23) como
mecanismo para arreglar los errores y remediar los hackeos sin recurrir a
enfoques tan engorrosos como

37
whitehat hacking [1] o tenedores duros. La migración a los contratos actualizados
será visible en la cadena de bloqueo, y estará disponible para ser auditada por los
usuarios para que la revisen antes de actualizarla.
No obstante, reconocemos que algunos usuarios no se sentirán cómodos con
un grupo que controle una escotilla de escape en forma de migración/envío. La
migración forzada podría facultar al controlador del contrato de migración, o a un
hacker que com- promete credenciales relevantes, a emprender actividades
maliciosas, como cambiar las respuestas de los oráculos. Es por esta razón que los
contratos solicitantes tienen el control total de la característica de for- warding y
por lo tanto pueden optar por no activar la trampilla de escape. Además, de
conformidad con el enfoque de ChainLink sobre la descentralización, esperamos
que los proveedores
ser capaz de soportar múltiples versiones de CHAINLINK-SC desarrolladas por la comunidad.

5.5 Uso de fichas de enlace

La red ChainLink utiliza el token LINK** para pagar a los operadores del Nodo
ChainLink por la recuperación de los datos de los alimentadores de datos fuera de
la cadena, el formateo de los datos en formatos legibles para la cadena de bloques,
el cálculo fuera de la cadena y las garantías de tiempo de actividad que
proporcionan como operadores. Para que un contrato inteligente en redes como
Ethereum utilice un nodo ChainLink, tendrán que pagar al operador del nodo
ChainLink que hayan elegido utilizando tokens de LINK, y los precios serán
fijados por el operador del nodo en función de la demanda del recurso fuera de la
cadena que su ChainLink proporciona, y el suministro de otros recursos
similares. El LINK to - ken es un token ERC20, con la funcionalidad adicional
ERC223 de "transferencia y llamada" de transferencia(dirección,uint256,bytes),
que permite que los tokens sean recibidos y procesados por contratos dentro de
una sola transacción.

6 Estrategia técnica a largo plazo

La estrategia técnica a largo plazo para ChainLink propuesta en este libro blanco
incluye tres direcciones clave: Confidencialidad de Oracle, cambios en la
infraestructura, y comunicación fuera de la cadena.

6.1 Confidencialidad
Una red de oráculos distribuidos tiene como objetivo ofrecer un alto grado de
protección contra oráculos defectuosos. En la mayoría de los escenarios de

38
despliegue, busca lograr una respuesta correcta frente a las fallas f bizantinas
(para f < n/2 en nuestro simple protocolo de agregación). El hardware de
confianza puede ofrecer mucho más y se propone como un mejor enfoque para
asegurar la red ChainLink. El hardware de confianza es la piedra angular del
oráculo del Town Crier (TC) [24], que actualmente está operando en la red
principal Ethereum [33] y cuyos creadores se asociaron con SmartContract en el
lanzamiento del TC.

39
 Ciertas formas de hardware de confianza, más notablemente el reciente
conjunto de extensiones de arquitectura de conjuntos de instrucciones de Intel
Software Guard eXtensions (SGX) [12]-[15], [18], buscan proporcionar un
poderoso complemento a las formas distribuidas de confianza. Brevemente, SGX
permite que una aplicación se ejecute en un entorno llamado enclave que reclama
dos propiedades de seguridad críticas. En primer lugar, los enclaves protegen la
integridad de la aplicación, es decir, su flujo de datos, código y control, contra la
subversión de otros procesos. En segundo lugar, un enclave protege la
confidencialidad de una aplicación, lo que significa que sus datos, código y estado
de ejecución son opacos para otros procesos. El SGX trata de proteger las
aplicaciones enclavijadas incluso contra un sistema operativo malicioso, y por lo
tanto contra el administrador del host en el que se está ejecutando una aplicación.
Si bien existen desde hace algún tiempo formas alternativas de hardware de
confianza, como ARM TrustZone, el SGX proporciona una característica clave
adicional que falta en estas tecnologías. Permite que una plataforma genere un
certificado de ejecución de una aplicación particular (identificada por una
construcción de su estado de hachís). Este atestado puede verificarse a distancia y
permite que una instancia específica de la aplicación se vincule a una clave
pública y establezca así canales autenticados y confidenciales con otras partes. La
ejecución de un oráculo en un enclave y la distribución de los atestados pueden
ofrecer una garantía muy sólida de que el oráculo está ejecutando una aplicación
concreta, concretamente una creada o respaldada por los desarrolladores del
ecosistema ChainLink. Además, un oráculo que se ejecuta en un enclave que
puede conectarse a una fuente de datos mediante HTTPS puede proporcionar
una fuerte garantía de que los datos que recupera no han sido manipulados. (Ver
[24], [33] para más detalles.) Estas propiedades ayudan mucho a proteger contra
mal comportamiento del oráculo en el sentido de corrupción de datos, ataques de Sybil, etc.
Sin embargo, una oportunidad aún mayor reside en la capacidad de los
equipos de confianza para proporcionar una fuerte confidencialidad. La
necesidad de confidencialidad es en general uno de los principales obstáculos
para bloquear el despliegue de la cadena. Los oráculos que preservan la
confidencialidad pueden ser fundamentales para resolver el problema.

Por qué los oráculos distribuidos no aseguran la confidencialidad. La confidencialidad

es divertida... es fundamentalmente difícil de lograr en cualquier sistema de
oráculo. Si un oráculo tiene un frontal de cadena de bloqueo como un contrato
inteligente, entonces cualquier consulta al oráculo será visible públicamente. Las
consultas pueden ser encriptadas en cadena y desencriptadas por el servicio del
oráculo, pero entonces el propio servicio del oráculo las verá. Incluso
herramientas de gran peso como la computación segura multiparte, que permite la
computación sobre datos cifrados, no pueden resolver este problema dada la
40
infraestructura existente. En algún momento un servidor necesita enviar una
consulta a un servidor de origen de datos de destino. Por lo tanto, debe ver la
consulta, independientemente de la confidencialidad de la que haya disfrutado
anteriormente. También verá la respuesta a la consulta.

41
Oráculos que preservan la confidencialidad a través del SGX. Un oráculo que utiliza
SGX puede ingerir y procesar datos dentro de un enclave, en esencia actuando
como un TTP de confianza por su integridad y confidencialidad. Para empezar, tal
oráculo puede descifrar las consultas dentro de su enclave. Luego puede
procesarlos sin exponerlos a ningún otro proceso (o a ningún ser humano). El
enclave también puede procesar los datos de las fuentes de forma confidencial y
puede gestionar de forma segura información sensible como las credenciales de
los usuarios, una capacidad muy poderosa, como ilustramos a continuación.
El sistema de Town Crier soporta consultas confidenciales de datos de vuelo.
La información de vuelo puede ser pasada a un contrato inteligente de TC
encriptado bajo la clave pública del servicio de TC. TC descifra la consulta y luego
contacta con una fuente de datos (por ejemplo, flightaware.com) a través de
HTTPS. Devuelve al contrato inteligente de consulta una simple respuesta de
sí/no a la pregunta "¿Se ha retrasado este vuelo?" y no expone ninguna otra
información en cadena.
Una capacidad de CT aún más interesante es su soporte para el comercio en la
plataforma de juegos Steam. TC puede ingerir de forma segura credenciales de
usuario (contraseñas) para comprobar que la propiedad del juego ha sido
transferida de un comprador a un vendedor. De este modo, puede crear un
mercado seguro que de otro modo sería inalcanzable, con intercambios justos y
de alta seguridad de criptografía por bienes digitales. (En cambio, un simple
oráculo distribuido no podría gestionar de forma segura las contraseñas de los
usuarios en su nombre).
La CT también puede realizar una agregación fiable fuera de la cadena de
datos de múltiples fuentes, así como un cálculo fiable sobre datos de múltiples
fuentes (por ejemplo, promedios) y una consulta interactiva de las fuentes de
datos (por ejemplo, búsqueda en la base de datos de una fuente en respuesta a la
respuesta de otra).
El hardware de confianza ofrece un nuevo y excitante enfoque para el uso escalable de las
cadenas de bloques [24], [29], en el que grandes porciones de la infraestructura de las
cadenas de bloques, incluyendo contratos inteligentes, se ejecutan en enclaves. Tal
arquitectura combinaría los beneficios de transparencia de las cadenas de bloques con las
propiedades de confidencialidad de la ejecución fuera de la cadena y el hardware de
confianza. Si bien se han sugerido ideas similares utilizando otras técnicas, como
zk-SNARKs [21], el hardware de confianza es mucho más práctico (y menos
complicado). Nuestra actual agenda de investigación incluye esta visión
expansiva, con los oráculos como servicio catalizador.
Discutimos brevemente el tema de Intel como una raíz de confianza en el Apéndice B.

Definiendo la seguridad dada al SGX. Es posible, dado el uso de hardware de

confianza, definir la corrección del oráculo de manera más formal, empezando
42
FR
por el formalismo para el SGX de Intel propuesto en [32]. Este formalismo
permite que el SGX sea tratado como una funcionalidad global de composición
universal (UC) [6] sgx(Σsgx)[progencl, ]. Aquí, y en lo que sigue,
Σ denota un esquema de firma con funciones de firma y verificación Σ. Firmar y
Σ. Verifique. Una instancia de Fsgx(Σsgx)[progencl, R] es parametrizada por una firma de
grupo

43
esquema Σsgx. El argumento progencl denota el programa que se ejecuta en un
enclave, es decir, el entorno protegido porRel hardware. denota el código no fiable
que se ejecuta en un host SGX, es decir, el software que llama a la aplicación que
se ejecuta en el enclave.
La figura 5 (tomada de [24]) muestra el funcionamiento de la funcionalidad
Fsgx. Al ser inicializado, se ejecuta outp := progencl. Inicializar(), generando y
atestiguando el código de progencl y outp. Un atestado σatt es una declaración
firmada digitalmente por la plataforma de que progencl se está ejecutando en un
enclave y ha dado salida a outp. En el uso típico, progencl. Initalize() produce una
clave pública específica para la instancia que puede utilizarse para crear un canal
seguro hacia la instancia de la aplicación. Tras una llamada de reanudación con
(id, params), Fsgx continúa la ejecución y da salida al resultado de progencl.
Resume(id, params), donde id denota un identificador de sesión y params denota
parámetros de entrada a progencl.

Fsgx[progencl, R]: abstracción para SGX

Hardcoded: sksgx (clave privada para Σsgx)
Supongamos que: el progenitor tiene puntos de entrada
Iniciar y reanudar
Al recibir (init) de R:
Iniciar:
Let outp := progencl. Initalize()
σatt := Σsgx. Signo(sksgx, (progencl,
outp))
Salida (outp, σatt)
Reanudar
: recibir (curriculum vitae, id, params)
Al
deLet
R: outp := progencl. Resume(id, params)
Salida de salida

Figura 5: Abstracción formal para la ejecución del SGX capturando un subconjunto de

características del SGX..

Dado el formalismo de la figura 5, es posible definir con precisión la

integridad de un oráculo. La definición 1 lo hace en una ligera generalización de la
definición dada en [24] que llamamos Autenticidad del Oráculo.
Definición 1 (Autenticidad del Oráculo). Decimos que un oráculo O ejecutando el
programa progencl
F usando sgx y la clave de instancia de salida pkO satisface la
Autenticidad del Oráculo si, para cualquier adversario de tiempo polinómico que
pueda interactuar arbitrariamente con FAsgx, no puede hacer que un verificador honesto
acepte (pkO, σatt, params := (url, , T ), data, σ) donde data no es el contenido de url con
la clave pública en el tiempo T (progencl. Reanudar(id, params) en

44
nuestro modelo). Más formalmente, para cualquier adversario probable de tiempo polinomial A,

(pk. O , σatt, id, params, data, σ) ← AFsgx ( 1λ) : Σ

Pr . Σsgx.
Σ Verify(pksgx, σatt, (progencl, pkO ∧
)) = 1
Σ. Verify(pkO, σ, (id, params, data)) = 1 ∧
datos ƒ= progencl. Curriculum Vitae(id, params)
≤ negl(λ),
para el parámetro de seguridad λ.

6.2 Cambios en la infraestructura

Muchos de los desafíos en la construcción de oráculos seguros surgen del hecho
de que las fuentes de datos existentes no firman digitalmente los datos que sirven. Si
lo hicieran, entonces no sería necesario confiar en los oráculos para que se
abstuvieran de manipular los datos. HTTPS, el protocolo para comunicaciones
seguras en la web, no permite la firma de datos. Sin embargo, tiene una
infraestructura de clave pública (PKI) subyacente que requiere que los servidores
posean certificados que, en principio, podrían apoyar la firma de datos.
Esta observación es la base de TLS-N, una extensión de TLS, que permite a los
servidores HTTPS firmar partes de sus sesiones con clientes. La naturaleza
selectiva de la firma proporciona otras características agradables, como la
capacidad de los clientes de excluir de las transcripciones firmadas y proteger así la
confidencialidad de las credenciales (por ejemplo, las contraseñas) que utilizan para
conectarse a los servidores.
Creemos que los cambios en la infraestructura como el TLS-N son enfoques
prometedores para apoyar la seguridad de los oráculos. Sin embargo, es probable
que tengan que ser utilizados en conjunto con otras tecnologías como SGX,
debido a las siguientes limitaciones:
1. Modificaciones de la infraestructura: Lamentablemente, hasta que y a menos que
el TLS-N se convierta en una norma, las fuentes de datos deben desplegarlo
expresamente para que los clientes se beneficien. Es probable que pocas
fuentes de datos lo hagan en un futuro próximo.
2. Agregación y cálculo: El TLS-N no puede admitir la agregación u otras formas
de cálculo fiables sobre los datos de las fuentes de datos, por lo que seguirá
siendo necesario algún mecanismo de confianza para realizar estas tareas.
3. El costo: La verificación de los datos firmados por el TLS-N tiene un costo
relativamente alto en la cadena, comparado con la simple verificación de la
firma.

45
4. Confidencialidad: El TLS-N no puede admitir la gestión confidencial fuera de
banda de las credenciales o consultas de los usuarios, sino que exige que los
usuarios consulten ellos mismos una fuente de datos con este fin. Por ejemplo,
la información confidencial sobre los vuelos no puede almacenarse en un
contrato inteligente para una posterior consulta automática confidencial de
un sitio web.

46
6.3 Computación fuera de la cadena
Algunos usos intrigantes de los oráculos, como el uso de API dependientes de
credenciales, requieren que un oráculo haga mucho más que transmitir datos.
Puede que tenga que gestionar credenciales, entrar en cuentas para raspar datos,
y así sucesivamente. De hecho, si se cuenta con oráculos verdaderamente
confiables y confidenciales, algo que los sistemas respaldados por SGX à la Town
Crier y técnicas como las pruebas de conocimiento cero [21] pueden ayudar a
lograr, la frontera entre oráculos y contratos inteligentes puede hacerse fluida.
ChainLink ya soporta un lenguaje basado en regex para las consultas que
permite a los usuarios especificar con flexibilidad el procesamiento de los datos
fuera de la cadena. Nuestra estrategia a largo plazo, sin embargo, busca crear un
mundo donde los oráculos sean un recurso de computación clave fuera de la
cadena utilizado
por la mayoría de los contratos inteligentes. Creemos que esto será posible
construyendo un modelo de computación fuera de la cadena totalmente general y
privado dentro de los oráculos cuyos resultados son consumidos por los contratos
inteligentes. Si esto se puede lograr con una fuerte seguridad, como creemos que
puede, empujar la lógica de cálculo costosa y sensible dentro de los oráculos
resultará en
mejor confidencialidad, menores costos de ejecución de contratos y arquitecturas más flexibles.

7 Soluciones existentes de Oracle

ChainLink está diseñado para llenar una necesidad generalizada de nueva
tecnología de oráculos en sistemas de contratos inteligentes.
Desafortunadamente, hoy en día hay un suministro muy limitado de sistemas de
oráculo altamente seguros y flexibles. Creemos que esta falta de oráculos fiables es
un gran impedimento para la evolución de los contratos inteligentes.
La opción más utilizada para los servicios de oráculo hoy en día son los
proveedores centralizados de oráculo. Este enfoque es problemático, ya que crea
un punto de control centralizado y, por lo tanto, no cumple con los altos
estándares de resistencia a la manipulación que requieren los contratos
inteligentes sin confianza. Algunos de esos sistemas, por ejemplo, [31], tratan de
remediar este problema recurriendo a la notarización, para "probar" el
comportamiento correcto. Este uso de los servicios de notarización es
preocupante en vista de los problemas documentados de estos servicios [37], y el
hecho de que sus atestados no pueden ser verificados de manera factible en la
cadena, lo que da lugar a una necesidad (potencialmente recursiva) de una mayor
verificación.
Otro enfoque para proporcionar datos fiables sobre el oráculo es confiar en la
47
introducción manual de datos no estructurados por parte de los humanos. Estos
"oráculos de entrada manual" se proponen comúnmente para su uso en los
mercados de predicción [17], [25], [28]. Al crear apuestas financieras apropiadas y
asumir jugadores económicamente racionales con incentivos financieros limitados
para hacer trampas, estos oráculos proporcionan una alta seguridad de respuestas
correctas de origen colectivo. Este enfoque es descentralizado y flexible. Dado que los
oráculos de entrada manual obtienen sus respuestas de los seres humanos, pueden
responder a preguntas para las que es difícil encontrar datos estructurados o que
son difíciles de extraer de manera fiable, por ejemplo, requieren un
procesamiento del lenguaje natural

48
de las noticias. Sin embargo, lamentablemente, debido a que la cognición humana
es costosa y lenta, los oráculos de entrada manual requieren muchos recursos, no
son en tiempo real, y sólo pueden manejar un conjunto limitado de preguntas en
un momento dado. Creemos que ChainLink también podría ser muy útil para
resolver rápida y automáticamente contratos de mercado de predicción que
pueden resolverse con datos estructurados.
Un último enfoque es cambiar la forma de los datos en la fuente. Si una fuente
de datos firmara digitalmente los datos que proporciona, entonces el servidor de
retransmisión no necesitaría ser de confianza. El USER-SC podría simplemente
comprobar las firmas de los datos que recibe. Un excelente, general
Este tipo de enfoque es el que proporciona el TLS-N, como se ha mencionado
anteriormente. Lamentablemente, como ya se ha mencionado, el TLS-N requiere
cambios en la infraestructura existente.

8 Conclusión
Hemos introducido ChainLink, una red descentralizada de oráculos para que los
contratos inteligentes interactúen de forma segura con los recursos externos a la
cadena de bloques. Hemos esbozado la arquitectura de ChainLink, describiendo
tanto los componentes dentro como fuera de la cadena. Después de definir la
seguridad en el contexto de los oráculos, hemos descrito el enfoque multicapa de
ChainLink para la descentralización. Propusimos un protocolo novedoso con
nuevas características, como la protección contra la carga gratuita (con protocolos
adicionales y bocetos a prueba de seguridad en el apéndice del documento).
También expusimos una hoja de ruta sobre la forma en que ChainLink puede
aprovechar los avances tecnológicos y de infraestructura, como el hardware de
confianza y la firma digital de los datos por las fuentes. Por último, tras examinar
las soluciones de oráculo existentes y sus deficiencias, hemos expuesto la
necesidad actual de un sistema como ChainLink.

Principios de diseño. A medida que continuemos nuestro trabajo en ChainLink,

buscaremos priorizar los siguientes valores fundamentales:

- Descentralización para sistemas seguros y abiertos. La descentralización no sólo es

• la base de las propiedades a prueba de manipulaciones de las cadenas de
bloques, sino la base de su naturaleza sin permiso. Al continuar
construyendo sistemas descentralizados, pretendemos permitir un desarrollo
sin permiso dentro del ecosistema. Creemos que la descentralización es un
componente crucial para un ecosistema próspero a nivel mundial con
sostenibilidad a largo plazo.

- Modularidad para un diseño de sistema simple y flexible. Apreciamos la filosofía

• 49
de construir pequeñas herramientas que hacen una cosa bien. Los
componentes sencillos pueden ser fácilmente razonados y por lo tanto
combinados de forma segura en sistemas más grandes. Creemos que la
modularidad no sólo permite sistemas actualizables, sino que facilita la
descentralización. Dondequiera que las piezas clave de ChainLink dependan
o sean gestionadas por también

50
 pocas partes, trataremos de diseñar un ecosistema que permita utilizar
implementaciones que compitan entre sí.

- Código abierto para sistemas seguros y extensibles. ChainLink es posible gracias

• a que está en los hombros de muchos proyectos de código abierto.
Valoramos la comunidad y seguiremos contribuyendo desarrollando
ChainLink de forma abierta. Planeamos comprometernos continuamente
con los desarrolladores, académicos y expertos en seguridad para la revisión
de los pares. Fomentamos las pruebas, auditorías y pruebas formales de
seguridad, todo ello con el objetivo de crear una plataforma cuya robustez y
seguridad pueda apoyar futuras innovaciones.

Con estos principios en mente, esperamos extender el alcance y el impacto de las

cadenas de bloques y los contratos inteligentes haciendo de los oráculos una
piedra angular segura del ecosistema.

Referencias
[1] Paridad. El hacking de Multi-sig: Una autopsia. https://blog.ethcore.io/the-
multi- sig-hack-a-postmortem/. 20 de julio de 2017.
[2]Gun Sirer. Ataques de repetición de cadena cruzada. Hacking, Blog distribuido.
17 de julio de 2016. [3] Adi Shamir. "Cómo compartir un secreto".
En:Comunicaciones de la ACM 22.11
(1979), págs. 612 y 613.
[4] Claus-Peter Schnorr. "Generación eficiente de firmas por medio de tarjetas
inteligentes". En:Journal of cryptology 4.3 (1991), pp. 161-174.
[5] Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk y otros: "Secure
distributed key generation for discrete-log based cryptosystems". En:
Eurocrypt. Vol. 99. Springer. 1999, págs. 295 y 310.
[6]R. Canetti. "Seguridad de composición universal": Un nuevo paradigma para
los protocolos criptográficos". En: FOCS. 2001.
[7] Ran Canetti. "Seguridad compuesta universalmente: Un nuevo paradigma
para los protocolos criptográficos". En: Foundations of Computer Science, 2001.
Actas. 42º Simposio del IEEE sobre. IEEE. 2001, págs. 136-145.
[8] Douglas R. Stinson y Reto Strobl. "Signo de Schnorr distribuido de forma
segura y un esquema de umbral de (t, n) para los certificados implícitos".
En: ACISP. Vol. 1. Springer. 2001, págs. 417 a 434.
[9] John R. Douceur. "El ataque de la sibila". En: Taller Internacional sobre Sistemas
de Peer-to-peer. Springer. 2002, págs. 251 a 260.

51
[10] Aniket Kate e Ian Goldberg. "Generación de claves distribuidas para Internet".
Dentro: Distributed Computing Systems, 2009. ICDCS'09. 29th IEEE International
Conference on. IEEE. 2009, págs. 119-128.
[11] Claudio Orlandi. "¿Es buena la computación multipartidaria en la práctica?"
Dentro: Acústica, Procesamiento de Voz y Señal (ICASSP), 2011 IEEE International
Con- ferencia en. IEEE. 2011, págs. 5848-5851.
[12] Ittai Anati, Shay Gueron, Simon Johnson y otros: "Tecnología innovadora
para la certificación y el sellado basados en la CPU". En: Actas del 2º Taller
Internacional sobre Hardware y Soporte Arquitectónico para la Seguridad y la
Privacidad. Vol. 13. 2013. URL: https : / / software . intel . com / es - us / articles /
innovative- technology for- cpu- based- attestation- and- sealing (vis- ited on
05/23/2016).
[13] Matthew Hoekstra, Reshma Lal, Pradeep Pappachan y otros, "Using
Innovative Instructions to Create Trustworthy Software Solutions". En:
Proceedings of the 2Nd International Workshop on Hardware and Architectural
Support for Se- curity and Privacy. HASP '13. Tel-Aviv, Israel: ACM, 2013, 11:1-
11:1. ISBN: 978-1-4503-2118-1. DOI: 10.1145/2487726.2488370. URL:
http://doi.acm. org/10.1145/2487726.2488370.
[14] Frank McKeen, Ilya Alexandrovich, Alex Berenzon y otros. "Instrucciones
innovadoras y modelo de software para ejecución aislada". Dentro: Actas del
2º Taller Internacional de Hardware y Soporte Arquitectónico para la Seguridad y la
Privacidad. 2013, p. 10. URL: http://css.csail.mit.edu/6.858/2015/
readings/intel-sgx.pdf (visitado el 23/05/2016).
[15] Inteligencia. Referencia de programación de las extensiones de la protección de
software de Intel. 2014. (Visitado el 23/05/2016).
[16] Gavin Wood. "Etéreo": Un libro de transacciones descentralizado y seguro".
Dentro: Libro amarillo del Proyecto Etéreo (2014).
[17] Jack Peterson y Joseph Krug. "Augur: una plataforma descentralizada y de
código abierto para los mercados de predicción". En: arXiv preprint
arXiv:1501.01042 (2015).
[18] Victor Costan y Srinivas Devadas. "Intel SGX Explicado". En: Archivo ePrint de
Criptología (2016). URL: https : / / eprint . iacr . org / 2016 / 086 . pdf (visitado el
24/05/2016).
[19] Victor Costan, Ilia A Lebedev y Srinivas Devadas. "Sanctum: Mínimas
extensiones de hardware para un fuerte aislamiento del software". Dentro:
USENIX Security Sympo- sium. 2016, pp. 857-874.

52
[20] Kevin Delmolino, Mitchell Arnett, Ahmed Kosba y otros. "Paso a paso hacia la
creación de un contrato seguro e inteligente: Lecciones y conocimientos de
un laboratorio de criptografía". En: Conferencia Internacional sobre Criptografía
Financiera y Seguridad de Datos. Springer. 2016, págs. 79 a 94.
[21] Ahmed Kosba, Andrew Miller, Elaine Shi y otros. "Hawk": El modelo de
cadena de bloques de criptografía y contratos inteligentes de preservación
de la privacidad". En: S&P'16. IEEE. 2016.
[22] Loi Luu, Duc-Hiep Chu, Hrishi Olickel y otros. "Haciendo más inteligentes los contratos
inteligentes".
Dentro: Actas de la Conferencia ACM SIGSAC 2016 sobre Seguridad Informática y
Comunicaciones. ACM. 2016, pp. 254-269.
[23] Bill Marino y Ari Juels. "Establecer estándares para alterar y deshacer
contratos inteligentes". En: Simposio internacional sobre reglas y lenguajes de
marcado de reglas para la web semántica. Springer. 2016, pp. 151-166.
[24] Fan Zhang, Ethan Cecchetti, Kyle Croman, y otros. "Town Crier": Una fuente
de datos autenticada para contratos inteligentes". En: Actas de la Conferencia
ACM SIGSAC 2016 sobre Seguridad Informática y de las Comunicaciones. ACM.
2016, págs. 270 a 282.
[25] Página del proyecto Augur. https://augur.net. 2017.
[26] Matriz de control de nubes de CSA. URL:
https://cloudsecurityalliance.org/group/cloud- controls-matrix. 2017.
[27] Mark Flood y Oliver Goodenough. Contrato como autómata: La representación
computacional de los acuerdos financieros. https://www.financialresearch. gov/
workinging- papers/ files/ OFRwp- 2015 - 04 _ Contrato como autómata: La
representación computacional de los acuerdos financieros. pdf. Of-
de Investigación Financiera, 2017.
[28] Página del proyecto Gnosis. https://gnosis.pm. 2017.
[29] Hyperledger Sawtooth. https://intelledger.github.io/introduction.html. 2017.
[30] Abhiram Kothapalli, Andrew Miller y Nikita Borisov. "SmartCast": Una
In-
Protocolo de Consenso Compatible Censual Usando Contratos Inteligentes".
En: Criptografía Financiera y Seguridad de Datos (FC). 2017.
[31] Página del proyecto Oraclize. http://www.oraclize.it. 2017.
[32] Rafael Pass, Elaine Shi y Florian Tramer. "Abstracciones formales para
procesadores seguros de ejecución certificada". En: Eurocrypt. Springer.
2017, pp. 260-289.
[33] Servicio Ethereum de Town Crier. http://www.town-crier.org/. 2017.

53
[34] Florian Tramer, Fan Zhang, Huang Lin y otros. "Pruebas de vidrio sellado:
Usando enclaves trans- parentales para probar y vender el conocimiento".
En: Seguridad y Privacidad (Eu- roS&amp;P), 2017 IEEE European Symposium on.
IEEE. 2017, págs. 19 a 34.
[35] Vitalik Buterin et al. Ethereum white paper. https://github.com/ethereum/
wiki/wiki/White-Paper.
[36] JSON Schema. http://json-schema.org/.
[37] Hubert Ritzdorf, Karl Wüst, Arthur Gervais, et al. TLS-N: No repudio sobre el
TLS que permite la firma de contenido ubicuo para la desintermediación. Informe
ePrint del IACR 2017/578. URL: https://eprint.iacr.org/2017/578.

54
Divulgaciones
† Ari Juels es un miembro de la facultad del Instituto Jacobs en Cornell Tech. Es
co-autor de este trabajo en su calidad de asesor de SmartContract ChainLink Ltd.,
en el que tiene un interés financiero.

* Este documento es proporcionado por SmartContract ChainLink, Ltd. ("SCCL"),

una corporación de las Islas Vírgenes Británicas, en apoyo de la Plataforma
ChainLink. Secure Asset Exchange, Inc. ("SAE") dba SmartContract.com, está
proporcionando apoyo administrativo, técnico y de otro tipo a SCCL, incluyendo
el apoyo a la venta del Token LINK de SCCL, y está recibiendo compensación de
SCCL. Las estructuras tecnológicas, sociales y comerciales que utilizan la
tecnología de las cadenas de bloques están en continuo desarrollo y evolucionarán
en el futuro previsible. Por consiguiente, los planes, estrategias y des-colas de
implementación descritos en este libro blanco probablemente evolucionarán
también y, por lo tanto, puede que nunca sean adoptados. El SCCL y el SAE se
reservan todos los derechos de desarrollar o perseguir planes, estrategias o
detalles de implementación adicionales o al-ternativos asociados con la
Plataforma ChainLink.

** Las fichas LINK están siendo vendidas por SCCL de acuerdo con los términos y
condiciones de las condiciones de venta de fichas disponibles en
https://link.smartcontract.com/terms. Para más detalles, revise los términos. Las
Fichas LINK no son valores, inversiones o divisas, y no se venden o comercializan
como tales. Además: participar en la venta implica riesgos tecnológicos y
sistémicos significativos; la venta no está abierta a personas que residan o sean
ciudadanos de los Estados Unidos o el Canadá. El período de venta, la duración,
el precio y otras disposiciones pueden cambiar, como se indica en las condiciones
de la venta simbólica. La venta de fichas LINK To - ken implica riesgos conocidos
y desconocidos, incertidumbres y otros factores que pueden hacer que la
funcionalidad, utilidad o niveles de uso reales de las fichas LINK sean
materialmente diferentes de cualquier resultado, uso, funcionalidad o utilidad
futuros proyectados, expresados o implícitos por SCCL en los términos.

55
A Agregación fuera de la cadena
Para asegurar tanto respuestas válidas y firmadas como para evitar la carga
excesiva, nuestro protocolo de agregación fuera de la cadena, discutido en la
sección 4.2, se basará en un simple protocolo distribuido basado en firmas de
umbral [8]. El beneficio de este enfoque es que para una consulta dada, una sola
firma puede ser generada fuera de la cadena por una colección de n nodos
oráculos. Como resultado, sólo es necesario manejar un único mensaje
autenticado dentro de la cadena, en lugar de los mensajes O(n) de los distintos
nodos oráculos. Este enfoque reduce en gran medida los costos en comparación
con los del Algoritmo 1. La idea puede ampliarse aún más, como en [30], para
agregar las respuestas a múltiples consultas dentro de una sola firma de umbral,
una idea que no exploramos aquí pero que podemos considerar en nuestra
arquitectura.
Supongamos que f < n/3 oráculos son defectuosos y t = f + 1. Los nodos
defectuosos pueden tratar de realizar una carga gratuita y/o cualquier otro
comportamiento deshonesto, como firmar respuestas inválidas.
Nuestro protocolo completo para la agregación fuera de la cadena consiste en
un par de algoritmos OCA = (DistOracle, RewardOracles) para calcular una firma
Sigsk[A] en el valor A = Agg(A1, A2, . . . , An), para la función mayoritaria Agg. Una
versión simplificada, de una sola ronda
de estos protocolos se muestra respectivamente en los algoritmos 2 y 3. El
primero es ejecutado por los oráculos participantes, mientras que el segundo es
ejecutado por una entidad PROVEEDOR que puede, como se ha mencionado
anteriormente, tomar la forma de un contrato inteligente.
Antes de presentar la OCA, damos algunos antecedentes básicos sobre las firmas
de Schnorr y el esquema de umbral para computarlas que se da en [8].

Firmas de Schnorr. El esquema de firmas Schnorr hace uso de un grupo G de

primer orden p con generador g para el que se presume que el problema de
registro discreto es difícil. El par de claves de un usuario toma la forma (sk, pk) = (x,
y = gx) para x $ Z×p , donde Z×p = Zp 0. Sin pérdida de generalidad,← denotaremos
− de grupo de forma multiplicativa. Las firmas de Schnorr pueden ser
operaciones
calculadas sobre grupos de curvas elípticas, y de hecho típicamente
están en las modernas implementaciones de criptografía. La figura 6 muestra el esquema de la
firma Schnorr.

Esquema de firma de Threshold Schnorr. Hacemos uso del esquema de firma de

umbral de [8]. Este esquema genera un par de claves públicas y privadas globales
(sk, pk). Permite la generación del umbral de una firma completa Sigsk[m] para un
mensaje deseado m.
En el protocolo inicial de generación de claves, a cada jugador se le asigna un reparto de
claves xi = ski.
Esta configuración es una operación de una sola vez y se puede hacer utilizando
56
un protocolo de generación de claves distribuidas, por ejemplo, [5] o, para una
configuración asíncrona, [10.
Para generar una firma, los jugadores (oráculos en nuestro entorno) primero
realizan un protocolo de generación de claves distribuidas, como para la
generación de claves compartidas en la configuración. El resultado de este
protocolo es una clave secreta efímera global e. Cada jugador (Oi) recibe una parte
(secreta) ei de e.

57
 Firma de Schnorr: Entrada del firmante (m, sk = x); Entrada del
verificador pk = y
Firma Verifica
nte
r ←$ Zxp dor
e← r
cg = H(m ||e)
s = cx + e
(e,s),m
-−−
→ c = H(m ||e)
?
gs = ryc

Figura 6: Esquema de la firma de Schnorr.

Una firma parcial de Oi dada clave efímera e toma la forma σ(e)i = cxi + ei,
donde c = H(m e),
| como en la firma completa. Para cada jugador Oi existe también
| (σi; (pk, e)) que verifica su firma parcial. Nos referimos a una
una función validi
firma parcial como válida para Oi si verifica correctamente bajo validi.
Hemos modificado algo la notación y condensado en gran medida el esquema
de nuestra exposición aquí. Remitimos al lector a [8] para más detalles.

A.1 Protocolo OCA

Ahora presentamos los algoritmos DistOracle y RewardOracles que componen OCA.
Estos se especifican a continuación en los algoritmos 2 y 3. Usando la notación
condensada (en lugar de incluir testigos explícitamente, como en el Algoritmo 1)
dejamos que Commit denote una función de compromiso.
Tengan en cuenta que todos los jugadores pueden ver los mensajes recibidos
por CHAINLINK-SC, ya que está en cadena. Que Σ∗ sea la primera firma válida Σ
enviada a CHAINLINK-SC. En Alg. 3, dejamos que PS∗ denote un conjunto de
descompromisos recibidos por PROVEEDOR cuyas firmas parciales ceden Σ∗. (PS∗ podría
provenir del oráculo que envió Σ∗, pero no es necesario. Cualquier oráculo con una
firma parcial en PS∗ está incentivado a enviar PS ∗ . )

58
Algoritmo 2 DistOracle(f, n, i, ski = xi, pk, Src) (código para Oi)

Generar conjuntamente una llave efímera:

1: Ejecutar el protocolo de generación de claves distribuidas y

recibir (ei, e). Obtener datos:

2: Obtener Ai de Src.
Genera una firma parcial:
3: Calcular σ(e)i (= cxi + ei, para c = H(m|| e), donde m = Ai).
Comienza la ronda:
.Σ e), Ai); i .
4: Compromiso de emisión commi = Compromiso(σ( i
5: Esperar hasta que se reciba un conjunto de compromisos válidos de los distintos oráculos.
6: Envíe lai C a
PROVEEDOR.
Prepara la ronda:
7: Emisión preparada.
8: Espere hasta que se reciban los distintos mensajes preparados.
Revelar / descomprimir la ronda:

9: Liberación de la emisión de (σ(e), Ai)

i para commi.
10: Espere hasta que se reciba un conjunto de PS de ≥ t
descompromisos válidos. Cálculo completo de la firma:
11: si CHAINLINK-SC no ha recibido todavía una Σ válida, entonces
12:Agregar firmas parciales en PS en Σ = Sigsk[A]. 13:Enviar Σ a
CHAINLINK-SC.
14:Envía la PS al PROVEEDOR.
15: terminar si

59
Algoritmo 3 RewardOracles (código para PROVEEDOR)
1: Esperar hasta el C−set de n f conjuntos de compromisos (Ci ) de oráculos
distintos y se recibe PS∗.
2: por cada oráculo Oj do
3: si σj ∈CP S ∗ y > 2f se establece en incluir compromisos con σj de Oj y luego
4:Envía $recompensa a Oj.
5:Finalizar si
6: fin para

A.2 Los bocetos de prueba

Ofrecemos bocetos de prueba de las propiedades clave de la OCA. Demostramos
que asumiendo como mucho los nodos defectuosos, el protocolo siempre
genera una firma válida en una respuesta correcta, y nunca recompensa a los
nodos de oráculo que se cargan libremente.
Reclamación 2. El protocolo OCA nunca recompensará a un nodo de carga gratuita.
Prueba. Supongamos que Oz se está aprovechando. Entonces puede emitir una
comunicación válida sólo después del tiempo τ , el momento en que el primer Oi
honesto se descompone en el −−paso 9 del Alg. 2. Oi ha recibido n f mensajes
preparados de los cuales al menos n 2f vienen de nodos honestos.
− Dejemos que Oj
indique uno de estos nodos honestos al menos n 2f. Oj ya no aceptará
compromisos después de enviar un mensaje preparado, por lo que el conjunto Cj
de cualquier nodo honesto Oj ya no cambiará después del tiempo τ , y por lo tanto
Cj ex- cluye un compromiso con una firma parcial correcta σz de Oz. Por lo tanto, a
− −C
lo sumo n (n 2f ) = 2f se establece en Alg. 3 incluirá a Oz. Por lo tanto, Oz no
recibirá una recompensa.
Desafortunadamente, la OCA no puede asegurar que se pague a los nodos no
recargables. Un adversario tramposo puede, después de recibir una liberación,
apurar a los nodos honestos en el paso 13 del Alg. 2 generando sus propias firmas
parciales e incluyendo sólo la firma parcial de un nodo honrado en la generación
de Σ. El compromiso de ese nodo − honesto puede no haber sido incluido entre los n
f recogidos por ningún nodo. Podría haber llegado después.
Reclamación 3. OCA siempre resultará en una firma válida Σ = Sigsk[A] que
eventualmente se enviará a CHAINLINK-SC.
Prueba. Hay n nodos honestos,
−≥ y f < n/3, así que hay > 2f f +1 nodos
honestos, y por lo tanto al menos t nodos honestos. Así que el paso 1 del Alg. 2
se completará con éxito.
Del mismo modo, ya que−hay n nodos honestos, cada oráculo eventualmente
completará el paso 7 del Alg. 2, enviando un mensaje preparado. Los nodos
honestos eventualmente
60
recibirá al menos−mensajes preparados de nf y se descomprometerá, permitiendo
que el paso 13 sea completado por algún nodo honesto.
Reclamación 4. Cualquier firma válida Sigsk[A] recibida por CHAINLINK-SC en oca será en
un valor válido A.
Prueba. Es fácil ver que una firma válida Sigsk[A] incluye un valor correcto
A. Como t firmas parciales son necesarias para calcular el Sigsk[A], y a lo sumo f < t nodos
son defectuosos, al menos una firma parcial en A fue proporcionada por un nodo honesto y
por lo que debe ser correcto.

A.3 Discusión
OCA presenta algunos desafíos de diseño que discutimos brevemente aquí.

Pago por nodos honestos. Desafortunadamente, mientras que penaliza a los

gorrones con la falta de pago, la OCA no puede garantizar a la inversa que se
pague a los nodos honestos. De hecho, incluso en el caso benigno de que ningún
nodo sea defectuoso, el pedido de mensajes desafortunados puede dar lugar a que
los nodos honestos que han contribuido con firmas parciales a Σ no reciban el
pago.
Este problema podría abordarse en parte haciendo que el Alg. 2 esté
sincronizado. Específicamente, los pasos de "espera" podrían requerir que los
nodos esperen un período de tiempo ∆ tal que se garantice la recepción de
mensajes de nodos honestos. En este caso, todos los nodos con firmas parciales
incorporadas en Σ tendrían el pago garantizado. Los efectos secundarios, sin
embargo, serían una ejecución más lenta y el desafío de configurar ∆
correctamente.
El problema de diseñar un protocolo asíncrono con fuertes garantías de pago
es un problema de investigación abierto que estamos explorando actualmente.

Mensajes redundantes. OCA tiene como objetivo minimizar la comunicación en

cadena y el ide-ally implica un solo mensaje en cadena, a saber, una respuesta
firmada Σ, del conjunto de oráculos participantes. Sin embargo, en la práctica,
debido a que una firma Σ no enviará inmediatamente a la cadena de bloqueo,
varios oráculos podrían enviar independientemente respuestas firmadas a la cadena
de bloqueo. La mejor manera de limitar esos mensajes redundantes es que los
oráculos vigilen no sólo la cadena de bloques, sino también el mempool, es decir,
los mensajes pendientes.

Gestión de llaves. Por supuesto, como suele ser el caso, la gestión de claves es un
gran desafío en los protocolos de este tipo. La distribución de las acciones de sk
61
puede realizarse de forma distribuida [5] y se pueden hacer actualizaciones para
acomodar nuevos nodos y eliminar los nodos salientes, así como para
proporcionar una seguridad proactiva, es decir, una resistencia continua contra el
compromiso de las claves de los nodos. Además, los nodos pueden organizarse

62
en distintas camarillas para limitar el tamaño de n. Proponemos que ChainLink
emplee estas técnicas para asegurar un oráculo distribuido flexible, sensible y
seguro.

B Supuestos de confianza del SGX

En el papel de Intel de proporcionar una mayor garantía de corrección, el SGX
mejora pero no suplanta otras protecciones de integridad en ChainLink. En otras
palabras, el uso del SGX hace que el sistema sea estrictamente más fuerte.
Confiar en SGX para la confidencialidad requiere confiar en Intel, pero esta
confianza está circunscrita. Asumiendo que Intel no tiene una puerta trasera en
sus CPU que permita la fuga de datos de enclave, no tiene un medio para
inspeccionar el estado de enclave. (Una puerta trasera de este tipo es posible,
pero requeriría la presencia de pruebas físicas en la máquina de cada usuario y
supondría un grave riesgo para la reputación).
Intel o un adversario que corrompa los procesos de fabricación de Intel podría
en prin- cipio falsificar las claves de certificación (claves de plataforma EPID). Tal
adversario podría generar claves EPID que no están integradas en servidores
habilitados para SGX, sino que permiten que los certificados se generen en una
plataforma no SGX. En efecto, este adversario podría crear servidores falsos que
generen atestados SGX de apariencia válida, pero que no ofrezcan protección
para el código enclavijado. Si hubiera más de estos nodos, por supuesto, el
adversario podría corromper las respuestas de los oráculos. Más problemático
aún, tales nodos expondrían al adversario los datos sensibles manejados por los
nodos del oráculo. La capacidad de fallar...
Sin embargo, clasificar las claves EPID no implica la capacidad de corromper el SGX
existente y válido.
casos.
También es importante reconocer que, por supuesto, hoy en día, nos guste o
no, la confianza en Intel es ineludible. La CPU de la máquina en la que está
leyendo este documento es testigo de este hecho, o, si no, la CPU del servidor
desde el que ha descargado este documento.
Por supuesto, sería preferible hacer uso de hardware de confianza de varios
proveedores, y es de esperar que otros creen capacidades equivalentes. Las
nuevas arquitecturas abiertas para el hardware de confianza, y las formas de
debilitar las suposiciones de confianza requeridas de dicho hardware, son áreas
activas de investigación, por ejemplo, [19], [34]. Sin embargo, la capacidad de
diversificación entre proveedores o arquitecturas per se no garantizaría la
confidencialidad de los datos.
También estamos interesados en la investigación de técnicas para asegurar la
63
confidencialidad en las redes distribuidas mediante el uso de tráfico de cobertura.

64