Hilo técnico de Solana y otras cadenas. Nuestras aplicaciones, bots y trucos.

ruber et impius

ausführbarer Makaken
Desde
11 Abr 2020
Mensajes
5.926
Reputación
13.841
Sandbox : GitHub - burbubots/docker-cakebots: Docker compose for burbubots/cakebots

Código : GitHub - burbubots/cakebots

Todas nuestras tras*acciones de cryptos acaban registradas en la blockchain correspondiente. Saber como rastrear tras*acciones, entenderlas y saber como distinguir el oro de la purria es la base del entendimiento suficiente del mercado y es el punto de partida para o bien identificar las oportunidades o bien evitar errores que muchas veces provienen de la imposibilidad de manejar tantísima información a golpe de click.

Este hilo trata de cómo obtener información directamente de la blockchain que elijamos (de momento, Solana) y de cómo interpretarla o cuales son las opciones de interpretación. También es un hilo tutorial para que otros eviten errores de bulto por falta de conocimiento sobre los productos que se ofrecen basados en las cryptos.

Se parte de una base de datos relacional conjunta en donde se registrarán ordenadamente los datos y, a partir de ella, con diferentes plataformas (CakePHP en mi caso) desarrollar conjuntamente esa base de datos y los algoritmos necesarios para llenar esa estructura y obtener algo útil de ella.

Esta base de datos ha sido desarrollada en los últimos meses por mí y creo que contiene las tablas necesarias para empezar a registrar tras*acciones, analizarlas y valorarlas. Seguro que no es perfecta, pero es mejor que partir de cero y, por supuesto, si hay que reconstruirla entera, se haría, porque la intención es trabajar en equipo.

Definiciones (donde pone "Solana", podeis poner otra red):

Account - Cuenta Principal : Es la cuenta en Solana, la tuya o la de terceros sobre la que se esté trabajando en ese momento. No puede ser la cuenta de un programa, ni la de un token, ni la de un token asociado, sino que se referira a una cuenta de operación principal en Solana, la cuenta que firma las tras*acciones.

Account - Cuenta Externa: Es igual que la anterior, pero no es la cuenta con la que estamos trabajando, sino otra de otros agentes que estén interviniendo en una tras*acción con la cuenta principal que estemos tratando.

Account- Token/Program/Associated : Son otro tipo de cuentas.

tras*action / tras*acción : Es un registro de tras*acción e internamente tiene instrucciones.

Instruction / Instrucción : Es un componente de una tras*acción, siempre asociado a un programa. Puede tener instrucciones internas.

Interna : Instrucción interna a otra instrucción de programa, está asociado a un programa.

Program: Smart-contract, es una aplicación que se ejecuta en la blockchain.

Cuenta (en el contexto de tras*acción): son las cuentas principal, externas, token, token asociado todas en general antes de su clasificación en el análisis.

Análisis: Procedimiento de despiece de una tras*acción para identificar qué hace y que inputs/outputs produce.

Input/Output : Saldo de una cuenta principal o externa, antes y después de la tras*acción, no se contemplan los saldos intermedios, por su complejidad.


La base de datos:
(NOTA: Si, es compleja, pero es la manera de obtenerlo todo a traves de la petición de todas las tras*acciones de una cuenta)
1635262805761.png

Para que no sea dificil de tragar, lo desarrollaré por fases, en plan tutorial, empezando por cómo crear la cuenta (objeto Tradeaccount) y como requerir a la blockchain que nos rellene las cuentas asociadas (objetos Tradeasociados/Tradecoins), de manera que siempre sepamos qué tokens y saldos tenemos y por cuánto valor en USD tenemos sin tener que abrir nuestra wallet. Puede, lógicamente, también analizar cuentas que no sean nuestras, a ver qué cositas tienen.

Se irán posteriormente añadiendo otras funcionalidades en diferentes fases del tutorial, hasta completar la estructura entera de la base de datos, incorporando cuantas observaciones aporten otros foreros.

La forma de presentar el tutorial es con git y docker. Se explicará paso a paso.

Un container docker también puede ejecutarse en dispositivos NAS como Synology o Terramaster, por si en un futuro necesitamos que rule 24/7 sin tener que tener un ordenador dedicado.

Docker puede ejecutarse en sistemas Windows también, detalle en el que no entraré.

Con docker y docker-compose se crearía un container on-the-fly tras descargarse por GIT el guión y tras un proceso de instalación automatizada de los paquetes Debian (apt-get) del container y también de los paquetes correspondientes a PHP (composer) y quedaría un sistema completo MVC CakePHP 4.0 listo para operar, siempre actualizado, sin tener que pilotar de Linux, de apt-get o de composer, con sus herramientas de debug y con el tuto cargado operando en una máquina virtual, en un sandbox, con las orejas en el puerto 8800, listo para trastear en http://localhost:8800 .

También se subirá a algún sitio el container docker entero, de manera que los que no puedan crearlo con docker-compose (quizás los ventanitas) lo puedan utilizar.

Junto con el entorno web CakePHP se incluirá la aplicación web Adminer para manejar cómodamente la base de datos y la aplicación web ICEcoder como editor online, por si se instala en un sistema remoto. Se pueden incluir otras aplicaciones que funcionen sobre Apache.

Mientras preparo todo esto sin liarme demasiado podemos discutir en este hilo cualquier aspecto técnico o cómo los interesados quieren que llevemos todo ésto. No tengo ninguna experiencia en trabajo en equipo con software, así que se agradece cualquier aportación.
 
Última edición:
muy interesante, tienes mi apoyo jovenlandesal.

Dos preguntas:
  • porque no usas TheGrap (The Graph) para hacer queries mas estructuradas probablemente de la misma manera independientemente de la blockchain usada?
  • Pero porque usar solana?, mira que estoy largo, pero me da mala sensación aunque reconozco no tengo ni fruta idea
 
muy interesante, tienes mi apoyo jovenlandesal.

Dos preguntas:
  • porque no usas TheGrap (The Graph) para hacer queries mas estructuradas probablemente de la misma manera independientemente de la blockchain usada?
  • Pero porque usar solana?, mira que estoy largo, pero me da mala sensación aunque reconozco no tengo ni fruta idea
Tendría que mirarlo, pero de momento no veo a Solana ahí como subgraph... Habrá que mantenerlo vigilado por si la suman.

La reutilización de código para adaptarlo a diferentes cadenas lo pienso solucionar con clases abstractas. No creo que más allá de que todos tienen tras*acciones, tokens y cuentas se pueda avanzar mucho más, y cada cadena es diferente. Creo que para lograr sincretismo o para hacer un código más bonito pudiera ser, pero creo que al final trabajas el doble que si, simplemente, las cadenas las mantienes separadas en aquello que difieran.

Uso solana, porque ya he trabajado con Ethereum, le tengo tirria, al sistema y a sus comisiones. Quería empezar desde cero.
 
Tendría que mirarlo, pero de momento no veo a Solana ahí como subgraph... Habrá que mantenerlo vigilado por si la suman.

La reutilización de código para adaptarlo a diferentes cadenas lo pienso solucionar con clases abstractas. No creo que más allá de que todos tienen tras*acciones, tokens y cuentas se pueda avanzar mucho más, y cada cadena es diferente. Creo que para lograr sincretismo o para hacer un código más bonito pudiera ser, pero creo que al final trabajas el doble que si, simplemente, las cadenas las mantienes separadas en aquello que difieran.

Uso solana, porque ya he trabajado con Ethereum, le tengo tirria, al sistema y a sus comisiones. Quería empezar desde cero.

OK, mediante programación (clases abstractas) vas a resolver tener una interfaz "genérica" y reutilizable para otras blockchains. Además usar TheGraph implicaría costes en comisiones, que te ahorras.

La única ventaja de usar TheGraph está en que estaría todo mas "descentralizado" siguiendo la filosofia blockchain de no depender de una persona (tu). Pero en este caso entiendo es una aplicación personal.

Vas a poner el código en gitlab o github?
 
OK, mediante programación (clases abstractas) vas a resolver tener una interfaz "genérica" y reutilizable para otras blockchains. Además usar TheGraph implicaría costes en comisiones, que te ahorras.

La única ventaja de usar TheGraph está en que estaría todo mas "descentralizado" siguiendo la filosofia blockchain de no depender de una persona (tu). Pero en este caso entiendo es una aplicación personal.

Vas a poner el código en gitlab o github?
En Github. Un proyecto para la instalación de docker y otro para el código.
 
Instalación de entorno sandbox. GitHub - burbubots/docker-cakebots: Docker compose for burbubots/cakebots

¿Esto qué es? Se trata de que nadie tenga que instalar PHP, ni una base de datos, ni un servidor Apache, ni el framework, ni ponerlo todo configurado correctamente antes de poder experimentar la aplicación o meterle la zarpa al código.

Esto se consigue con contenedores. Un contenedor docker configurado como servidor web funciona en modo 'sandbox', es decir, que tiene un puerto donde excucha y, si quieres, puede tener algunas carpetas compartidas, pero no interactúa para nada con otras cosas que puedas tener.

Los contenedores que he diseñado se basan en otros dos, uno con el server Apache y otro con una base de datos MariaDB(MySQL). Puede haber más, que crearé a petición. Puede haber uno que sea, por ejemplo, un server Tomcat para Java J2EE, porque te mole un framework de ese lenguaje (como ZK, por ejemplo) y usaría la misma base de datos.

Para instalar el entorno hay que instalar Docker. En sistemas Linux o Mac es muy sencillo, pero en sistemas Windows puede ser un poco complicado. No me importa echarle un rato si os decidís por windows, yo ya lo hice en una ocasión.

Una vez instalados docker y docker-compose, hay que descargarse el paquete vía web o con git. Hay más información (en inglés) en la página del paquete, que es GitHub - burbubots/docker-cakebots: Docker compose for burbubots/cakebots . simplemente se ejecuta ./crear_docker y lo que sucede de forma automatizada es:

- Se sigue el guión docker-compose.yml con dos guiones más, uno para cada container.

- Se descarga la imagen para el server de base de datos y se rellena con las tablas del proyecto.

- Se descarga la imagen para el server apache, instala otras aplicaciones y librerias de Debian, instala el paquete burbubots/cakebots y se configura para otras dos aplicaciones que también se han instalado.

- Por último, copia el proyecto burbubots/cakebots en una carpeta compartida entre el contenedor y nuestro sistema.

Las rutas para entrar a la aplicación, la aplicación de la base de datos y el editor online están en la página antes citada ( GitHub - burbubots/docker-cakebots: Docker compose for burbubots/cakebots ). digamos que esta es la página del paquete con entorno sandbox. El código está en GitHub - burbubots/cakebots.

Antes de hablar de lo que hace ahora la aplicación y de lo que podría empezar a mejorarse, prefiero esperar a ver si hay algún problema que surja con la instalación del entorno.
 
Actualizo.

La versión actual es la 1.0.1.
Parte de una vista en la que podemos poner las cuentas Solana que queramos analizar.
tradeaccounts.png
Eso son cuentas a la que seguiremos los pasos (o nuestras propias cuentas).
En esta ventana podemos pulsar para crear nueva cuenta a seguir, en el botón rojo.
Nos saldría esta nueva vista:
nueva_cuenta.png
Podemos nombrar la cuenta para poderla recordar mejor, en este caso 'chuchocoiner', poner una nota y, por supuesto, es imprescindible poner la ristra alfanumérica que indentifica a la cuenta, en la casilla 'Account'.
Damos a 'Submit' (siempre dejo para el final españolizar las vistas) y volveríamos a la ventana anterior.

Si pulsamos 'Ver coins' para la cuenta que nos interesa, nos aparecería ésto:

detalle_cuenta.png
Los 83 tokens del dueño de la cuenta aparecen aquí, tras descargarse de la red, paginados. Los logos y los nombres se identifican automáticamente a partir de una lista de tokens conocidos que se actualiza en github por parte del Solana Team, aunque yo la lista la he metido a pata, por no complicar mucho la aplicación. Conforme se actualice la aplicación, actualizaré también esta lista.

Algunos tokens no hay manera de saber qué son, quizás porque son shitcoins de muy putrefacto pelaje.

El siguiente paso es que se descargue de Coingecko el valor en USD de cada token, lo multiplique por los que tiene y luego, al final de ese proceso, hacer la gran suma. Tiene complicación ser fino con la suma total por el tema de stakes/delegates, que ocultan la cantidad real de tokens que se poseen. Para esto quizás habrá que investigar muy a fondo.

Para la descarga de tanta info desde Coingecko voy a introducir ajax, para que estas descargas, que son muy numerosas, se hagan asíncronamente.
Se rellenarán los incrementos en su escala temporal, las capitalizaciones, el precio en USD, etc..

Cuando acabe con ello, introduciré otras cadenas, empezando con Ethereum.

Por supuesto, como esta aplicación es un CRUD, hay muchas ventanas que he omitido mostrar, pero que los que estén acostumbrados a programar MVC intuyen, como create/add, view, index, update, delete.
 
A ver si puedes ayudar :

1 .Alguien sabe cómo sacar un address market de Dexlab para ponerlo en SOLA o en cualquier otro Dex?

2 .¿Sabes si hay alguna APi Para sacar los precios de los DEX de solana?
Parece que usa Serum:
dexlab.png
Filtra siempre por XHR. Sueles encontrar peticiones asíncronas a servidores con API.
Parece que usa peticiones REST json a una cosa llamada solana-api projectserum.

Échale un ojo a:

Si sacas algo, me cuentas o si te atascas. A mí también me interesa.
 
Parece que es ésto:

Tienes que construir una petición json y luego procesar el resultado.
Tienes un ejemplo de trato con API-json en mi proyecto cakebots, src/controller/TradeasociadosController.php
 
Pues todo muy interesante, lástima que yo no tengo ni papa de esto.
Pero es como Sonar tracker de Solana
Pues sí. Buen enlace.
Me dice que vuelva dentro de 12 horas, que no me puede dar más info, pero la demo pinta bien.

Esa es la idea, poder rastrear rentabilidades, pero no a través de algo interactivo como una dapp y metiendo carteras una a una, sino de forma programática.
Imagina que pudiésemos identificar a los owners de muchas carteras que invierten y desinvierten varias decenas de miles de USD.
Tras identificarlos, podríamos saber sus 'movimeintos migratorios' y por donde va a soplar el aire. Lo que hagan cientos de carteras acondroplásicas o como oscile una cotización es EMHO mucho menos valioso que hacer taxonomía de inversores a partir de la historia de sus tras*acciones.
 
Parece que es ésto:

Tienes que construir una petición json y luego procesar el resultado.
Tienes un ejemplo de trato con API-json en mi proyecto cakebots, src/controller/TradeasociadosController.php

Gracias ,con esto creo que me sirve para empezar ; estoy haciendo un bot para leer . Pero ya te digo que en la actualidad por rapidez se usa "mempool sniping"
 
Gracias ,con esto creo que me sirve para empezar ; estoy haciendo un bot para leer . Pero ya te digo que en la actualidad por rapidez se usa "mempool sniping"
Alguna vez lo he pensado. Rastrear las tras*acciones que están pendientes en la mempool dan una ventaja temporal, pero si no puedes predecir qué va a ocurrir cuando las tras*acciones se confirmen al final es una actividad de prueba-error que puede ser muy cara.
 
Volver