Originalmente planeamos escribir artículos al menos una vez a la semana. Sin embargo, el aumento repentino en la solicitud de lanzamiento aéreo, las actualizaciones de la interfaz de usuario del sitio web y la auditoría de la compañía rompieron nuestro plan. Lamento haberte hecho esperar. Comenzamos a escribir esta serie nuevamente.
Puede visitar nuestro nuevo sitio web aquí: https://authpaper.io
De ahora en adelante, seguiremos publicando artículos cada semana. Sin embargo, el artículo puede no estar solo relacionado con un contrato inteligente. Podemos incluir otros artículos como tutoriales sobre airdrop y recompensas, e información de la compañía.
Sigamos el viaje. Para aquellos que deseen ver el contrato completo, puede encontrarlo aquí:
https://github.com/SolonAuthpaper/AUPC_sales_contract
En el último artículo, hemos hablado sobre la función predeterminada, que se ejecuta cada vez que alguien envía ETH al contrato. Al recibir el ETH, el contrato verifica si almacena el número de referencias que ya se encuentran en el diccionario de niveles guardados. En caso afirmativo, el contrato calculará el descuento para distribuir el AUPC a los compradores y los premios de comercialización a los referentes.
Si no, necesitaremos consultar los niveles de referencia y la información de referencia del comprador desde nuestro sitio web. Usamos oraclize API para hacerlo.
Oraclize API (ahora llamada Provable, https://provable.xyz/) es el servicio líder de Oracle para contratos inteligentes y aplicaciones , que atiende miles de solicitudes todos los días en plataformas como Ethereum, Rootstock, R3 Corda, Hyperledger Fabric y EOS.
La solución desarrollada por Oraclize es, en cambio, demostrar que los datos obtenidos de la fuente de datos original son genuinos y sin restricciones. Esto se logra al acompañar los datos devueltos junto con un documento llamado prueba de autenticidad. Las pruebas de autenticidad pueden basarse en diferentes tecnologías, como máquinas virtuales auditables y entornos de ejecución de confianza.
(Copia de https://docs.oraclize.it/)
En otras palabras, este es un servicio para un contrato inteligente para leer datos web.
Una vez que se realiza una consulta dentro del contrato inteligente, enviará la información y algo de gas al contrato inteligente de Oraclize. Una vez que se consultan los datos, llamará a la función de devolución de llamada del contrato inteligente original para devolver los datos (en cadena). Los datos se consultan asimétricamente.
Para implementar, puede ser tan simple como esto.
La importación de línea … incluye el código del contrato de oraclize para que el contrato pueda usar la función oraclize. Cuando se necesita consultar un dato, se llama a oraclize_query ().
La primera entrada es el tipo de fuente de datos. En la mayoría de los casos es "URL", lo que significa que está leyendo datos de una página web o API HTTP. Para otros tipos de fuente, puede leer https://docs.oraclize.it/#general-concepts-data-source-types
La segunda entrada es la url para consultar. Además de obtener el texto y manejar el formato de datos en la función de devolución de llamada, oraclize API también admite el análisis de datos JSON, XML, HTML y binarios. Si los datos a consultar están en formato JSON (por ejemplo, {“resultado” => ”{” tt ”=> ” 0 ”},” estado ”=>” éxito ”}), y el contrato solo necesita parte de los datos (por ejemplo, solo el 0 en resultado => tt), la segunda entrada se puede escribir como json (https://api.kraken.com/0/public/Ticker?pair=ETHUSD) .result.tt) que solo los datos en cuestión se devuelven al contrato. Reduce la complejidad del código, pero aumenta el costo de gas de realizar la consulta.
La tercera entrada es opcional, que es el límite de gas para realizar la llamada. Por defecto, es 200,000 y es suficiente para la mayoría de los casos. Si la función de devolución de llamada requiere muchos trabajos, como en nuestro caso, es necesario establecer un límite de gas más alto o la llamada fallará. Establecer el límite de gas correcto es difícil, pero importante. Si el límite de gas es demasiado bajo, la consulta fallará ya que la función de devolución de llamada no se puede ejecutar por completo. Si el límite de gas es demasiado alto, el gas restante irá a oraclizar y no se reembolsará.
En nuestro contrato, lo establecemos en 600,000, o 0.01205968011458582 éter. Es porque descubrimos que nuestra función de devolución de llamada requiere una tarifa de transacción de hasta 0.011. Establecer el límite de gas por debajo de 0.012 éter no es factible. Por otro lado, significa que con una compra mínima de 0.1 ETH, y hasta el 15% del ETH recibido para ser distribuido como recompensa de referencia de marketing, se puede llamar a 6 consultas como máximo. Limitamos el número de consultas a 5.
La función devolverá un bytes32 queryId, que se utiliza para identificar los datos de la consulta en la función de devolución de llamada. Como la llamada se realiza de forma asimétrica, es bueno definir un diccionario utilizando el queryId como índice para almacenar los datos necesarios cuando se llama a la función de devolución de llamada.
La primera entrada de la función de devolución de llamada es el queryId tal como se recibió al llamar a la consulta. La segunda entrada es el resultado en cadena.
En la función de devolución de llamada, la primera línea es verificar si los datos provienen de Oraclize. Es necesario ya que todos pueden llamar a la función de devolución de llamada. La comprobación evita que otros ingresen datos de phishing en el contrato inteligente. También se recomienda consultar los datos HTTPS para evitar el phishing HTTP.
Agregamos la línea delete oraclizeCallbacks (myid) al final de la función. Es para evitar múltiples llamadas de la misma devolución de llamada y evitar el envío de tokens varias veces. Pero no es necesario.
Ahora pasa a la función de devolución de llamada del contrato de venta de tokens.
Necesitamos mantener la dirección de compra y la cantidad de ETH enviada para calcular los tokens para distribuir. También hay dos tipos de consultas, una es obtener el número de niveles de referencia para calcular el descuento, otra es obtener la referencia de la dirección en cuestión. Por lo tanto, también definimos una enumeración para distinguir las dos consultas y definir una estructura de recompensa Node para evitar que todos los datos necesarios para pasar hagan la consulta a la función de devolución de llamada.
Después de realizar la consulta y se llama a la función de devolución de llamada, el contrato inteligente lee los datos necesarios del diccionario oraclizeCallbacks. Si se trata de obtener los niveles (la consulta realizada desde la función predeterminada), el resultado consultado se analiza en un número entero, se almacena en el que no es necesario volver a consultar en las próximas 24 horas y se pasa a la función de compra AUPC para calcular el descuento y distribuir las fichas
La función buyAUPC también puede crear una consulta web para encontrar el referente de la dirección actual. En este caso, la dirección que paga el ETH por el token (baseAddress), el último referente encontrado (lastParent) y los niveles del referente desde baseAddress se mantienen dentro del recompensaNode. Cuando se devuelven dichas consultas, la función de devolución de llamada analizará el resultado en una dirección, se almacenará y pasará a sendUpline para distribuir la recompensa de marketing al referente.
Esta es toda la información sobre la parte de nuestro contrato inteligente de venta de tokens. Para obtener más detalles sobre Oraclize, lea sus documentos de soporte (especialmente la parte de precios): https://docs.oraclize.it/
En el próximo artículo, hablaremos sobre la última parte del viaje de distribución de tokens, las funciones de compra AUPC y sendUpline.
){kind=link}