Aunque hay alguna literatura que menciona las posibilidades de los oráculos para suministrar datos externos a los contratos inteligentes en una cadena de bloques, soy un novato y me preguntaba si hay una implementación exitosa de esto.
Conozco servicios como Oraclize y Reality Keys que proporcionan datos del "mundo exterior".
¿Cuál es el servicio más desarrollado y documentado para oráculos?
¿En qué tipo de proyectos se están utilizando estos oráculos?
Hay una lista de Dapps que se desarrollaron con Oraclize y Ethereum. Pero, ¿cómo se usa exactamente un oráculo aquí?
Considere un escenario en el que un contrato inteligente de una cadena de bloques de Ethereum privada necesita leer/escribir datos en un servicio en la nube. ¿Puedo diseñar mi propio oráculo para hacer esto? En caso afirmativo, ¿dónde puedo obtener más información al respecto?
Los servicios de cadena de bloques se utilizan para lograr transacciones entre pares sin confianza y un almacenamiento distribuido seguro de estas transacciones. ¿No contradirá esto el concepto de los oráculos, porque estamos "confiando" en una sola fuente para nuestra información? ¿O hay alguna forma de implementar oráculos en un sistema basado en el consenso?
Proporcione cualquier fuente útil para comprender mejor los oráculos. Gracias por adelantado.
Marco de Oracle aquí :)
Creo que esta publicación de blogpor Thomas Bertani es una buena introducción a lo que son los oráculos y lo que pueden hacer. Como breve resumen, Oracle es un tercero que ofrece obtener los datos que necesita y que no puede obtener por sí mismo. Esto es exactamente para lo que se utiliza Oraclize en el ecosistema Ethereum. Los contratos inteligentes son ciegos al mundo exterior y, a menudo, es necesario proporcionarles datos para que hagan algo útil. Proporcionamos ese servicio y, al mismo tiempo, también podemos proporcionar una prueba criptográfica de nuestra honestidad, es decir, de proporcionarle datos inalterados de la fuente de datos. Aunque no es una solución perfecta, TlsNotary es un primer paso en la dirección correcta para eliminar la confianza en el servicio de Oracle y trasladarlo a actores mucho más grandes, como Amazon en este caso, que ejecuta los servidores notarizados, y a las fuentes de datos mismas.
Como mencionó Edgar, la capacidad de verificar directamente desde los contratos inteligentes de Ethereum una prueba criptográfica de la honestidad de Oracle antes de aceptar esos datos, será un gran paso adelante para los servicios de Oracle. Es una característica que debería llegar antes de fin de año, con la próxima bifurcación dura de Ethereum. En Oraclize, ahora estamos trabajando para expandir nuestras pruebas criptográficas más allá de TLSNotary y otros enfoques basados en software, y utilizaremos soluciones basadas en hardware en los próximos meses. A medida que los contratos crezcan en valor y la utilidad será cada vez más importante para proporcionar servicios de Oracle extremadamente robustos y resistentes a los ataques.
Para responder a sus otras preguntas, puede ver cómo se utilizan nuestros servicios en la lista de dApp que mencionó, al verificar su código de contrato inteligente en nuestro repositorio de GitHub . La mecánica básica es que nos conectamos a las API de esos servicios y usamos el método de devolución de llamada _callback para enviar los datos al contrato que lo solicita.
Oraclize también funciona con cadenas de bloques privadas. Si está interesado, debe contactarnos directamente y podemos discutir una integración. Si, en cambio, desea crear su propia solución de Oracle ad-hoc y simple, hay algunos recursos de código abierto aquí para comenzar.
Edmund Edgar de Reality Keys aquí. Un buen ejemplo de Reality Keys en uso es EtherOpt , que es un intercambio de opciones descentralizado. Puedes ver su código fuente aquí .
Tiene razón en que usar un oráculo requiere fundamentalmente algún tipo de confianza en el oráculo, y evitar este tipo de confianza es una de las principales razones para usar cadenas de bloques en primer lugar.
Esto implica la vulnerabilidad estándar "Los terceros de confianza son agujeros de seguridad": si Reality Keys es pirateado o sobornado con éxito, EtherOpt pagará a las personas equivocadas. La historia de las partes confiables en criptomonedas es que nuestros terceros confiables a menudo son pirateados (o "pirateados", es difícil de decir), por lo que no se trata de una preocupación puramente académica.
La mitigación obvia es combinar múltiples oráculos, ya que es menos probable que todos se vean comprometidos simultáneamente. Esto es muy valioso y reduce en gran medida el riesgo, aunque no tanto como podría parecer, porque el riesgo del oráculo está algo correlacionado; Por ejemplo, si hay un día cero grave en alguna parte central de la infraestructura gratuita como SSH, aumenta la posibilidad de que tanto Thomas como nosotros seamos pirateados simultáneamente. Además, si uno de sus oráculos se ve comprometido, eso aumenta el valor de un ataque exitoso a los restantes.
Un enfoque interesante en el que Thomas ha estado trabajando es usar la notarización TLS para probar criptográficamente que los datos que informa son los que se publicaron en el sitio HTTPS del que los obtuvo. En mi humilde opinión, esto es actualmente principalmente desarrollador pr0n en lugar de seguridad real, porque los contratos en realidad no pueden verificar la prueba, por lo que todo lo que hace es asegurarse de que ha sido comprometido, pero dado que los datos de Oracle son generalmente públicos y alguien generalmente tiene una participación en cada resultado y un incentivo para gritar asesinato azul si son robados, eso resuelve un problema que realmente nunca tuvimos, sin resolver el que tenemos: si lo piratean, pierde su dinero.
Se vuelve más interesante si y cuando Ethereum hace una bifurcación dura que permitirá que los contratos verifiquen las pruebas directamente; Sin embargo, incluso allí, lo que realmente está haciendo es mover el oráculo: no necesitaría confiar en mí o en Thomas para proporcionar los datos correctos, pero sí necesita confiar en el proveedor de datos original para proporcionar los datos correctos. La ventaja de esto sobre confiar en mí o en Thomas es que el proveedor de alimentación puede ser una empresa más grande con una marca que proteger. Sin embargo, aún existen riesgos serios, particularmente si el proveedor de datos realmente no tiene la intención de que se use de la forma en que lo estamos usando, en cuyo caso es posible que no lo asegure adecuadamente o simplemente retire las claves API de su contrato. necesita acceder a su feed...
galáhad