Imaginemos esta situación: he abierto una vault colateralizando ETH. Luego, a través de ciertos procedimientos maliciosos, logro establecer en los Oracles una lectura errónea del precio del ETH, indicándoles que el mismo ha subido 1000% su cotización. Esto generaría que la cantidad de DAI posible de acuñar a cambio del colateral que he dejado a cambio, se elevase muchísimo. Desde ya, podría acuñar ese DAI, hacerme con él y, de esa manera, haber "estafado" al sistema.

O por el contrario: Imaginemos que, del mismo modo, introduzco una lectura fraudulenta que señala que el precio del ETH se ha derrumbado hasta valer casi nada. Esto provocaría que el ratio de colateralización de miles de vaults disminuyera y se perforasen los Precios de Liquidación, lo cual generaría una liquidación masiva de vaults y profundas alteraciones en todo el sistema.

Estos dos ejemplos sencillos pueden servirnos para entender la delicadeza e importancia que tienen los Oracles dentro del buen funcionamiento del protocolo.

¿Y cuáles son esas medidas de seguridad?

Aquí la cosa puede ponerse complicada, pero intentaremos mantenerla simple:

¿Recuerdas los Feeds? Estos se encargan, individualmente, de utilizar una herramienta llamada Setzer, que les permite obtener el precio mediano de X activo de un conjunto de exchanges. Luego, esta información es subida a una red segura (conocida como Secure Scuttlebutt Network), y desde allí es enviada a una herramienta conocida como Medianizer, la cual se encarga de recibir todos los precios medios, procesarlos, y ofrecer el precio medio de todo el conjunto de precios medios. Este precio es el que se subirá al Oracle Security Module, que es, en definitiva, el sitio del cual sale el precio final que el sistema utilizará para calcular todos sus parámetros.

Ahora contestemos la pregunta...

1- El sistema es seguro ya que se basa en el precio medio, y no en el promedio. Esta diferencia es importante y podemos entenderla con un ejemplo claro:
Supongamos que queremos saber el valor promedio de una cena en Kamchatka, y recolectamos los siguientes precios: $10, $20, $30, $40, $1000. Lo que debemos hacer es sumar todos los valores y dividirlos por la cantidad de valores, lo cual nos indicaría un precio promedio de $220. Ahora, supongamos que queremos saber el valor medio de una cena en Kamchatka y recolectamos los mismos precios. Pues bien: el valor medio sera aquel que, justamente, esté en el medio; a su izquierda quedarán los precios menores, ya su derecha los mayores. En este caso, el precio medio será $30. Lo cual es, en la realidad, mucho más representativo que el precio promedio, que puede deformar mucho la percepción si es inusualmente alto.
Esto significa que si alguien intenta realizar un ataque malicioso, no le bastará con alterar dramáticamente uno de los precios del activo (recuerda que se calculan muchos precios de un activo encontrados en distintos exchanges) para, de esa forma, alterar todos los demás valores. Por el contrario, si quiere lograr esto, tiene que poder modificar fraudulentamente todos los valores que se encuentren a la derecha o a la izquierda del valor medio, lo cual es mucho más complicado.

2- El sistema es seguro, además, porque —como hemos visto— los Feeds individuales son anónimos; utilizan seudónimos y no se conocen entre sí. Esto evita posibles arreglos maliciosos entre ellos, chantajes, extorsiones y demás. En cuanto a la Organizaciones, estas son públicas ya que son mucho más difíciles es de corromper, dado que son compuestas por muchos miembros.

3- El sistema tampoco puede ser víctima de un ataque Sybil en el cual, por ejemplo, se creasen muchos Feeds maliciosos. Esto es así ya que el proceso para convertirse en Feed no es ni sencillo ni automático y, de hecho, debe ser aprobado por los holders de MKR.

4- Por último, el Oracle Security Module (o Módulo de Seguridad del Oráculo) que se encarga de ofrecer el precio de referencia final sobre el cual se construyen todos los parámetros, ofrece este dato con un delay ---cuya duración puede ser modificada---, lo cual permite verificar dichos datos y prevenirse en caso de ser necesario sobre toda potencial amenaza.

En definitiva, gran parte de lo que hace que el sistema sea seguro, puede resumirse en una palabra a la cual ya debemos estar acostumbrados: descentralización. Es esta descentralización entre actores y entre mecanismos la que le da tal nivel de articulación y flexibilidad a todo el proceso, que termina blindándolo contra posibles ataques.