Escáner de bloques de bricolaje (Blockchain explorer): ¿Por qué es necesario?

Al desarrollar una billetera criptográfica, encontrará una serie de problemas que no son obvios. No consideraremos ahora los problemas asociados con la generación de direcciones, la firma de transacciones y otras cuestiones que nos puedan venir a la mente primero.

Centrémonos en una tarea simple y trivial a primera vista: obtener una lista de transacciones asociadas con una dirección específica. A primera vista, esta simple solicitud no debería generar ninguna pregunta; después de todo, la cadena de bloques contiene una gran base de datos de transacciones, ¿verdad?

En realidad, no. Si Bitcoin y sus sucesores (Litecoin, DASH, Docgecoin, etc) son, por definición, un libro de transacciones, entonces Ethereum y sus derivados ya son libros de contabilidad, aunque también deberían almacenar transacciones, al menos en teoría. 

Pero lo interesante es que incluso para una dirección Bitcoin no podrás obtener una lista completa de las transacciones asociadas con una dirección específica utilizando medios estándar, solo las entradas (recibidas por la dirección de la transacción). Con Ethereum todo es aún más interesante. Geth (go-ethereum) no permite ningún medio regular para recibir transacciones. Si conoce el hash de la transacción (no hay problema, si no), entonces todo lo que puede averiguar sobre la dirección en la cadena de bloques es su saldo. 

Por supuesto, esto no será un gran problema si todas las direcciones son generadas por su aplicación y su backend ya está monitoreando el estado del mempool y escaneando todos los bloques nuevos en busca de las transacciones necesarias; probablemente anotará cuidadosamente todas las transacciones, las colocará en la base de datos y tendrá acceso a ellas en cualquier momento. En el caso de Etherem y otras cadenas de bloques donde se implementa un mecanismo de token similar al estándar ERC20, también recibirá todas las transacciones asociadas con llamadas de contratos inteligentes (por ejemplo, enviar o recibir tokens ERC20). Sin embargo, casi cualquier buena aplicación de billetera le permite importar claves y direcciones de acceso creadas en otro programa. Sí, puede utilizar el enfoque que adoptaron los creadores de Exodus: simplemente "barrer" todos los fondos desde la dirección importada a la especificada en la aplicación y luego considerar el problema cerrado. 

Pero ¿cómo funciona entonces la popular Metamask? ¿Cómo logra mostrar todas las transacciones incluso para direcciones importadas? 

En realidad, no utilizan ninguna magia especial. Para experimentar, intente agregar una nueva red a MetaMask y estudie detenidamente los campos que deben completarse... Entre los datos obvios, como la URL del punto de acceso, el ID de red, el nombre de la red y el símbolo de moneda, se le pedirá que complete un campo opcional: indique un enlace a blockexplorer. Toda la información se obtiene a través de API de servicios como infura.io y alchemy.com. Para Bitcoin, blockhain.com/blockhain.info proporciona una funcionalidad similar; una gran cantidad de redes están cubiertas por el servicio blockchair.

Resulta que para proporcionar información a nuestra aplicación, es suficiente conectarse a algún proveedor de este tipo y ¿está todo en la bolsa? Por un lado, sí. Sin embargo, esta solución no siempre estará exenta de inconvenientes y, en ocasiones, estos inconvenientes pueden ser críticos. Repasemos sólo los más obvios.

En primer lugar, puede olvidarse inmediatamente de la confidencialidad de las operaciones. Una gran empresa tendrá acceso a todos los datos de todos sus clientes y no se sabe con qué finalidad utilizará esos datos. Sería bueno si fuera solo una colección inofensiva de bigdata para análisis de mercado y obtención de información privilegiada al realizar transacciones. Pero en el futuro, dichos datos pueden pasar a ser propiedad de personas, por así decirlo, no del todo limpias. Por cierto, recientemente Alchemy anunció que registraría las IP desde las que se realizó la transacción. Si anunciaron oficialmente que recopilarán datos de ubicación ni siquiera de sus clientes, sino de los clientes de todos los servicios que utilizan su API, entonces podemos suponer que ya lo están haciendo activamente. 

El segundo aspecto, no menos problemático en el futuro, es que la dependencia del servicio de otra persona no puede garantizar que los términos del servicio no cambien. Por ejemplo, un servicio decidirá introducir una tarifa de suscripción a la API y el autor de cualquier aplicación, incluso gratuita, se verá obligado a pensar qué hacer al respecto. ¿Abandonar la solicitud? ¿Hacerlo pagado? Pero permítanme recordarles que una billetera criptográfica es un almacenamiento de criptomonedas y los usuarios de dicha aplicación pueden perder repentinamente el acceso a sus ahorros. Y las cantidades pueden ser significativas.

Esta lista puede continuar durante mucho tiempo, pero habrá una conclusión: en muchos casos es mucho más racional proporcionar su propio backend e implementar su propia infraestructura que le permitirá acceder a los datos necesarios.

Qué se necesita para esto y cómo implementarlo: lo veremos en el próximo artículo