El modelo de que los contratos solo pueden aceptar y procesar datos, en lugar de poder recuperarlos también de Internet, parece limitante (aunque no, es menos directo). Si una preocupación es que los datos o Internet no son confiables, ¿no podría programarse un contrato para manejar esos casos?
¿Existen limitaciones técnicas fundamentales que llevaron a que los contratos de Ethereum no pudieran "acceder a Internet" directamente?
La cadena de bloques de Ethereum fue diseñada para ser completamente determinista. Esto significa que si tomo todo el historial de la red y luego lo reproduzco en mi computadora, siempre debería terminar con el estado correcto.
Dado que Internet no es determinista y cambia con el tiempo, cada vez que reproducía todas las transacciones en la red, recibía una respuesta diferente.
El determinismo es importante para que los nodos puedan llegar a un consenso. Si hubiera un contrato que requiriera la cantidad de votos a favor en esta pregunta, el valor podría diferir de vez en cuando o incluso de un lugar a otro, lo que provocaría que los nodos en el futuro o sin acceso a este sitio lleguen a conclusiones diferentes sobre el estado de la red. , rompiendo así el consenso.
Al exigir que cada entrada de datos se inicie a través de una transacción externa, podemos estar seguros de que la propia cadena de bloques contiene toda la información necesaria para verificarse a sí misma. Este proceso de recopilar datos fuera de la cadena y luego pegarlos en la cadena de bloques se conoce como trabajar con un oráculo .
Hay varios servicios de Oracle que permiten que un contrato inteligente parezca que está haciendo una llamada a la API; sin embargo, Oracle en realidad está haciendo las llamadas a la API fuera de la cadena y publicando el resultado en la cadena para que los utilicen los contratos inteligentes. Algunos de estos incluyen Chainlink , Provable , BandChain y Tellor .
De hecho, puede obtener datos de Internet . Solo necesitas a alguien que se lo entregue a tu contrato. ¿Cómo puedes confiar en esa persona? Usa algo como Demostrable. https://probable.xyz Esta es una idea que utiliza TLS Notary para garantizar que la respuesta sea auténtica desde el servidor web.
Lo encontré porque originalmente estaba pensando en hacer lo mismo con TLS Notary. Le envié un mensaje a Vitalik en reddit el 22 de agosto de 2015 al respecto. Él dijo esto:
Usar contratos de ethereum para verificar sesiones HTTPS es teóricamente una buena idea; mi principal preocupación es que el EVM en este momento puede ser demasiado lento para implementarlo. Si quiere intentarlo, siéntase libre de investigar y ver exactamente cuánto trabajo le llevaría hacerlo; tal vez sea posible dentro de los 3 m de gas y me encantaría ver los resultados yo mismo.
Estoy emocionado de que alguien haya tenido la misma idea que yo y ya la haya convertido en una cosa. ¡Ojalá todo el desarrollo fuera tan fácil!
Creo que esto fue diseñado como una característica para minimizar la carga en la red y reducir los recursos. Hay varias soluciones si desea "llamar a API en un contrato":
http://www.ethereum-alarm-clock.com/
Fuente: https://forum.ethereum.org/discussion/3571/ethereum-alarm-clock-call-scheduling-for-contracts
pipermerriam Publicaciones: 10Miembro ✭ Septiembre de 2015 en Discusión general del proyecto (no técnica) Me enorgullece anunciar el lanzamiento del servicio Ethereum Alarm Clock.
http://www.ethereum-alarm-clock.com/
El servicio de alarma facilita la programación de llamadas de función de contrato para un número de bloque específico en el futuro. La versión actual debe considerarse software alfa.
Programe llamadas de función de contrato para que se ejecuten en un bloque específico en el futuro. Sin esperanzas. No se otorgan API administrativas ni acceso especial a nadie, incluyéndome a mí. Código fuente verificable publicado. Mucha documentación con ejemplos. Estoy muy interesado en escuchar los comentarios de la gente. No dude en enviarme un mensaje a pipermerriam en gitter.
Tomas Bertani
tjaden hess