Escáner de bloques de bricolaje (Blockchain explorer): una pequeña teoría

En el último artículo analizamos las razones por las que podríamos necesitar nuestro propio explorador de bloques. Observo que esta lista está lejos de ser completa, pero asumiremos que lo hemos decidido: necesitamos nuestra propia fuente de datos sobre transacciones y sus conexiones con direcciones.

Intentemos determinar qué necesitamos para esto. Obviamente, primero necesitamos una copia de la cadena de bloques deseada, y esta copia debe permanecer actualizada (sincronizarse con la red correspondiente). Esto último sugiere que debemos implementar un protocolo completamente correspondiente (que obviamente será redundante y extremadamente costoso) o instalar el software correspondiente, lo cual es más racional. Para Ethereum será, por ejemplo, Geth (go-ethreum), bitcoind o btcd (implementación en golang) para Bitcoin, o cualquier software correspondiente. La condición principal es el acceso a la cadena de bloques completa (o a la parte que desea rastrear). 

Para mayor claridad, recordemos cómo se debe almacenar la información en la cadena de bloques. Bitcoin y sus descendientes (llamémoslos “clásicos”) utilizan el concepto UTXO (Unspent Transaction Output). El resultado de una transacción puede denominarse "Salida" y cada transacción, con una excepción, debe hacer referencia a una "Entrada". Por lo tanto, cada transacción contiene una dirección de remitente y una dirección de destinatario de una forma u otra (no entraremos en detalles ahora, el hecho mismo de la presencia de dicha información es suficiente). Un efecto secundario es que a partir de esta información también podemos construir un árbol de transacciones que nos permitirá rastrear cada Satoshi que pasa por la red. 

La red Ethereum maneja la información de forma un poco diferente. Como mencioné en el último artículo, el concepto de Ethereum es diferente y la información se almacena directamente sobre los saldos de direcciones. Sin embargo, la información sobre las transacciones todavía está en bloques y almacenada en la red. Por tanto, todavía es posible indexar transacciones y su relación con las direcciones. En este artículo, deliberadamente no abordaré los contratos inteligentes y las operaciones con tokens (ERC20/ERC721/ERC1155) ni las llamadas "Transacciones internas"; la consideración de este tema requiere un artículo aparte.

¿Qué no está disponible para nosotros? Las cadenas de bloques que utilizan algoritmos de “prueba de conocimiento cero”, como Monero y ZCash, no pueden indexarse ​​de esta manera, como sugiere su diseño. 

Entonces el proceso será directo y sencillo, aunque llevará mucho tiempo y en cuanto a la cantidad de espacio en disco que necesitarás.. 

Paso uno: solicitamos el bloque inicial vía RPC (la implementación depende de la red específica) y, revisando las transacciones una por una, las decodificamos y seleccionamos la información que queremos indexar. Probablemente nos interese el hash de la transacción, las direcciones utilizadas, la dirección de la transacción, la hora y el número de bloque. La lista completa depende de tus tareas y de los recursos disponibles (principalmente el cuello de botella será el espacio en disco).

A continuación, guardamos la información que nos interesa en alguna versión de la base de datos, tomamos el siguiente bloque y repetimos los pasos descritos. No muy elegante, pero lamentablemente no existe otra receta. 

Y surge una pregunta lógica: ¿por qué los propios desarrolladores de blockchain no brindan acceso a información tan obviamente útil? ¿Qué le impide guardar e indexar inmediatamente dichos datos al sincronizar con la red? 

La respuesta se superpondrá con la explicación de por qué el espacio en disco será un cuello de botella. 

Primero, un pequeño ejemplo. Quienes han desplegado un nodo para Ethereum saben que existen varias opciones de sincronización Geth. En la documentación, la sección “Modos de sincronización” menciona nodos completos y nodos ligeros. Estos últimos no nos interesan, pero los nodos completos, a su vez, se dividen condicionalmente en Snap, Full y Archive. Y aquí es donde la cosa se pone interesante, sobre todo si te fijas bien en la ilustración para ver cuál de ellos es cuál. El nodo Snap almacena información detallada sobre los últimos 128 bloques y un par de puntos de control en un pasado relativamente reciente. El nodo Completo, como se desprende de la ilustración, almacena puntos de control con una cierta frecuencia casi hasta el "principio de los tiempos". El archivo ya almacena información completa sobre toda la existencia de Ethereum. Si establece un objetivo y descubre cuántos datos almacena un nodo completo, resulta que es aproximadamente 1 Tb (en el momento de escribir este artículo). No entraremos en los mecanismos de “reorganización de la red” y otros trucos. Estamos interesados ​​en otra cosa: la cantidad de datos almacenados por el nodo Archivo ya es de unos 16 Tb(!). ¿Resulta que más del 90% de la información sobre blockchain no está disponible para nosotros?

Si ejecutas un experimento simple, muchas cosas encajan. 

Utilicemos el servicio etherscan..io y busque una transacción aleatoria “desde el principio de los tiempos”, por ejemplo 0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba(durante aproximadamente agosto de 2015) e intente obtener información al respecto utilizando la consola del Geth, sincronizado en modo completo. Podemos obtener esta información, ¿verdad? 

¡Bienvenido a la consola Geth JavaScript!

instancia: Geth/v1.12.0-stable-e501b3b0/linux-amd64/go1.20.3
en el bloque: 19122581 (martes 30 de enero de 2024 23:24:11 GMT+0000 (UTC))
 directorio de datos: /home/eth/ethereum
 módulos: admin:1.0 depuración:1.0 eth:1.0 minero:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

Para salir, presione ctrl-d o escriba salir
> eth.getTransaction("0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba")

nulo

Um... Entonces, ¿no hay información sobre la transacción? Realmente no... Intentemos ver el contenido del bloque en el que se encuentra la transacción deseada, ya que conocemos el número de bloque:

> eth.getBlockByNumber(122546)
{
...
   hash: "0xc58aa38cf7df6050d3be43f1557d61e3a28e3f34d7818b1644e6a9972003e80a",
...
   número: "0x1deb2",
...
   transacciones: ["0x7d7062d6f865931e0bbbccea46551a73d5d58a6ef618d5592c35b5256a65e9ba"],
...
}

¡Así que aquí está ella, en su lugar! Si ejecutamos eth.getBlockByNumber(122546, true) (un parámetro adicional que indica una solicitud para mostrar toda la información sobre las transacciones en el bloque), recibiremos el contenido de la transacción y, por ejemplo, descubriremos que el remitente era la dirección 0x5685620dce626248ccb7121e87fbc098fd5310bd y el destinatario 0x9b0a028eafdecde3afc0fd00b7937098388b7c8a, así como toda la información relacionada. ¿Por qué no podemos obtener esta información preguntándola directamente?

Sin entrar en detalles técnicos, solo el nodo de archivo indexa completamente toda la cadena de bloques y todas las conexiones entre bloques, transacciones y direcciones. Y el “peso” de estos índices es precisamente el de que les faltan 15 terabytes de información. 

Esto nos da una idea de para qué volúmenes de datos debemos prepararnos. Sin embargo, no es en absoluto necesario que sus tareas específicas requieran una indexación tan detallada; es muy posible que su base de datos sea algo más compacta. 

En cuanto a bitcoin, existen mecanismos similares, pero el volumen de datos es incomparablemente menor. En el momento de escribir este artículo, el volumen de la cadena de bloques de Bitcoin es de unos ridículos 545 Gb, por lo que habrá muchos menos problemas con ella...

En conclusión, unas palabras sobre cómo acelerar el proceso de indexación. No es en absoluto necesario procesar todas las solicitudes contactando al cliente de la red correspondiente. La mayoría de las veces, el software para trabajar con blockchain es abierto y los formatos de bases de datos están bastante estandarizados. Puede que valga la pena considerar la opción de trabajar directamente con un nodo ya sincronizado depositado en el disco, y solo entonces sincronizar nuevos bloques. 

En el próximo artículo intentaremos montar una implementación mínima a partir de las herramientas disponibles para preparar una base de datos de búsqueda de direcciones para diferentes blockchains.