El principio básico de los robots on-chain: Tomemos a FriendTech como ejemplo

Prefacio

Friend.Tech es una plataforma social basada en contratos inteligentes, los usuarios deben conectar su propio Twitter para registrarse y “emitir” su propia clave, los usuarios con clave pueden ingresar a una sala similar al chat grupal para comunicarse con el propietario de la clave. Sigue siendo una plataforma social centralizada, pero se basa en contratos inteligentes en la cadena para implementar la lógica clave de compra y venta, y la función principal es una aplicación de mensajería instantánea basada en la página web. Y en el proceso de compraventa de llaves, el 10% del valor se dividirá en dos partes, una parte para el desarrollador Friend.Tech y la otra parte para el propietario de la habitación correspondiente. Luego, en el caso de que dicha clave pueda eludir el front-end para completar la compra y venta, naturalmente producirá robots en la cadena para jugar nuevo, comprar, vender y engañar. Entonces, ¿cómo se implementan?

Habla de golpear nuevos robots

Golpear nuevos robots puede tener beneficios considerables en la etapa inicial de Friend.Tech operación, porque en este momento, los robots francotiradores en la cadena no han evolucionado hasta cierto punto, y se pueden comprar después de un simple juicio de información y pueden tener altas expectativas de ganancias. Ahora, comience con la lógica de implementación de bots más simple y recorra paso a paso una lógica de bot compleja.

Por supuesto, antes de eso, necesitamos introducir **Event**, que es una abstracción de eventos de registro en EVM bajo el lenguaje de programación Solidity. Por lo general, se empareja con una instrucción emit para desencadenar un evento**. Correspondiente a los registros que son transacciones en el navegador de la cadena de bloques, como la siguiente transacción para comprar una clave, que desencadena un evento Trade que contiene una serie de información.

! [Fundamentos de los robots on-chain: FriendTech como ejemplo] (https://cdn-img.panewslab.com/panews/images/6yihX4ZR6n.png)

Duración del contrato

Los eventos son una parte importante de las DApps, a través de las Friend.Tech cuales pueden escuchar el cambio de estado del contrato, por ejemplo, también escucharán el contrato para ajustar una serie de datos en la base de datos, como el precio de visualización del front-end, la cantidad de tenencia, etc.

La idea más simple

Entonces, la lógica más simple de un nuevo robot es esta: escuchar los eventos del contrato de Friend.Tech, y cuando encuentre que un evento desencadenado por un intercambio cumple con las siguientes condiciones, llamar al contrato de Friend.Tech para seguir la compra

* El evento es compra (el valor de compra es verdadero)
* El comerciante y el propietario tienen la misma dirección (comerciante == sujeto)
* La transacción es la transacción que creó la sala (el suministro es 1)

La siguiente figura muestra el diagrama de flujo del proceso

! [Fundamentos de los robots on-chain: FriendTech como ejemplo] (https://cdn-img.panewslab.com/panews/images/cTUYN1J80k.png)

Bot mínimo

¿Contrato? ¡Atomicidad!

Hay ciertos problemas con un robot de este tipo:

1. No hay garantía de que el nuevo pueda comprar y, en segundo lugar, es imposible dar exactamente la cantidad de ETH que se puede comprar por la clave;
2. Tampoco es posible establecer un precio máximo, como cuántas llaves o cuánto precio se alcanza en el momento de la ejecución de la operación;
3. Fácil de ser francotirador, otros pueden realizar operaciones de compra a través de nuevas direcciones para atraer a dichos robots, con el fin de lograr el propósito de defraudar la tarifa de manejo y las ganancias de venta;

Primero considere resolver los problemas 1 y 2, una de las ventajas de EVM es que puede llamar atómicamente a otros contratos en un solo contrato, por lo que solo necesita implementar un contrato para realizar una compra y establecer una serie de condiciones, como el código de contrato de código abierto en Github [friendrekt] , puede establecer el precio máximo de compra, así como la cantidad.

Para la pregunta 3, la forma más fácil es usar la interfaz oficial para consultar, obtener la dirección correspondiente de la información de Twitter del usuario y luego consultar la cantidad de seguidores de Twitter y otra información para filtrar, y luego determinar si comprar, cuánto comprar y cuál es el precio máximo. En este punto, el flujo de operación del robot se convierte en el que se muestra en la siguiente figura.

! [Fundamentos de los robots on-chain: FriendTech como ejemplo] (https://cdn-img.panewslab.com/panews/images/16OzVP13Ts.png)

Introducción de los contratos daigou

Explosión tecnológica

Se puede ver que este proceso aumenta las solicitudes de información y las llamadas de contratos inteligentes, y el robot determina la activación de una nueva cuenta después de escuchar el evento del contrato, después de un simple juicio lógico, y luego usa la API para consultar la información relevante para filtrar, y finalmente usa el contrato inteligente implementado para completar la compra. Pero estos robots todavía tienen defectos:

1. Incapaz de juzgar la cuenta de Twitter de phishing, algunas cuentas tienen una gran cantidad de fanáticos, pero todos son fanáticos de zombis y no tienen ningún valor, y comprar tiene un gran riesgo;
2. El número de seguidores no es conveniente para juzgar si un usuario de Twitter es valioso, algunos fans de KOL tienen un número pequeño de fans, pero funcionarán, por lo que es fácil filtrar a estas personas;
3. Hay un cierto retraso en la API, esta interfaz solo se puede consultar dentro de un período de tiempo (60 segundos) después de que el usuario se activa, es fácil perder muchas direcciones y tener un retraso alto;

Una vez más, resuelva estos problemas uno por uno. Veamos primero la pregunta 3, gracias al recordatorio de 0xleo [¿cómo perdí 10,000 cuchillos en friend.tech - 0xleo?, descubrí que otra interfaz puede consultar la información de la dirección después de que el usuario se registre, luego puede monitorear esta interfaz de forma continua e incremental para encontrar la última identificación y obtener la información del registrante. Si se considera que el registrante es valioso, almacena la dirección en la caché (también se requiere una base de datos para garantizar la persistencia del reinicio) y la compra después de escuchar los eventos en cadena y acceder a la caché.

La segunda son las preguntas 1 y 2, ¿cómo juzgar si un usuario es valioso? Luego es necesario utilizar algunos sitios de puntuación KOL de Twitter de terceros para ayudar, el autor usa Twiiterscan para consultar en el proceso de exploración, porque la información de registro se puede obtener con anticipación, por lo que el tiempo dedicado a consultar Twiiterscan antes de la activación no tiene mucho impacto. Además, puede establecer manualmente la lista blanca y el precio de compra para completar la configuración de compra.

Por último, el flujo básico del bot que implementamos es el siguiente. Un “bot” adicional extrae la información más reciente de la API y la almacena en la base de datos y el caché después del juicio, mientras que el robot dedicado a la compra consulta la información del caché después de recibir el evento y realiza una compra después de golpear el caché. Este caché también puede almacenar información de la lista blanca, seleccionar algunos KOL valiosos y establecer el precio y la cantidad a comprar.

! [Fundamentos de los robots on-chain: FriendTech como ejemplo] (https://cdn-img.panewslab.com/panews/images/2G0v64Q8N0.png)

Seguimiento avanzado y análisis de influencia

Dado que el autor implementó este bot relativamente tarde, el beneficio no es muy objetivo. A finales de septiembre, comenzó a darse cuenta y optimizar, y alcanzó un máximo de ingresos de 1.2E alrededor del 3 de octubre, y las ganancias retrocedieron después de no hacer movimientos oportunos en esos días, y no hubo ganancias ni pérdidas después de agregar una serie de tarifas de manejo. Los bots de esta arquitectura pueden lograr una compra en el primer bloque después de que el registrante compre, y dado que no existe una operación tan tumultuosa como un escaneo de mempool en la base, la mayoría de las compras que siguen al mismo bloque son básicamente un juego loco: después de escuchar la compra, la compra se ejecuta hasta que se completa la compra, como otro robot visto en el proceso: .

Su estrategia es sencilla, basada en la arquitectura que describimos anteriormente, no almacena la base de datos, y comienza a comprar directamente hasta que se complete la compra. Después de optimizar hasta este punto, es un juego de lucha por la cantidad de dinero, y se puede jugar así si puede permitirse quemar gas, y la ganancia es particularmente considerable cuando la estrategia es correcta.

Conclusión

En el preámbulo también mencionamos la operación de compra y venta, fraude de tarifas, aquí hay una introducción casual:

1. La compra y venta es un robot de copia, el seguimiento a una dirección más rentable puede seguir su operación, el principio también es muy simple, filtre la dirección de escucha, si es la dirección de destino para seguir la operación;
2. Hay dos tipos de trampas en las tarifas (según lo observado por el autor durante el desarrollo), una se realiza mediante el uso de una cuenta de Twitter con una gran cantidad de seguidores, comprándola directamente y vendiéndola rápidamente para completar la cosecha. La otra es crear constantemente nuevas direcciones, transferir dinero, luego realizar una operación de compra y vender rápidamente. El segundo tipo está dirigido principalmente al bot lógico más simple, que también debería ser muy rentable en la etapa inicial.

Hasta ahora, hemos completado la introducción del principio del robot en cadena, la implementación específica implica que el código ya no se explica, los amigos que quieran entenderlo también pueden consultarlo [friendrekt] implementación.