Búsqueda automática de contratos Ethereum en tiempo real

BÚSQUEDA AUTOMÁTICA DE CONTRATOS ETHEREUM EN TIEMPO REAL REAL-TIME SEARCH OF ETHEREUM CONTRACTS T RABAJO FIN DE GRADO CURSO 2023-2024 AUTOR MANUEL DAVID PÉREZ BELIZÓN DIRECTORES PABLO GORDILLO ALGUACIL Y JESÚS CORREAS FERNÁNDEZ GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID BÚSQUEDA AUTOMÁTICA DE CONTRATOS ETHEREUM EN TIEMPO REAL REAL-TIME SEARCH OF ETHEREUM CONTRACTS TRABAJO DE FIN DE GRADO EN INGENIERÍA INFORMÁTICA AUTOR MANUEL DAVID PÉREZ BELIZÓN DIRECTOR PABLO GORDILLO ALGUACIL Y JESÚS CORREAS FERNÁNDEZ CONVOCATORIA: JUNIO 2024 GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID 27 DE MAYO DE 2024 III DEDICATORIA A mis padres que han sufrido conmigo y me han apoyado durante toda mi etapa universitaria, a mi hermano Rafa, que para mí es un modelo a seguir que siempre está ahí para echarme un cable si lo necesito, a mis lalos que espero que se sientan muy orgullos de mí y a todos mis amigos que han tenido que aguantar mis mejores y peores etapas estos años. Gracias a todos. V AGRADECIMIENTOS Gracias a todas aquellas personas que me han acompañado durante todo este tiempo y me han hecho ser quien soy. Gracias a Jesús y a Pablo, los directores de este trabajo, que me han guiado y ayudado siempre que lo he necesitado. VII RESUMEN Búsqueda automática de contratos Ethereum en tiempo real En la red principal de Ethereum se despliegan continuamente nuevos contratos y su código binario está disponible públicamente, lo que proporciona una enorme colección de código real de aplicaciones reales que se puede utilizar para realizar investigaciones sobre ellos. En la red de Ethereum se almacena el código compilado del contrato, aunque en algunos casos los desarrolladores de contratos publican el código fuente en repositorios públicos, como por ejemplo Etherscan. Para realizar investigaciones sobre esta base de código, resulta de gran interés poder disponer de una herramienta que pueda cargar contratos inteligentes que estén verificados en la red de Ethereum para así buscar aquellos que cumplan condiciones de selección complejas, como, por ejemplo: tipo de licencia del código, versión del compilador, optimizaciones, así como otras condiciones complejas. En este trabajo se introducen los conceptos fundamentales de la tecnología de cadena de bloques, se describen las principales características de Ethereum, se revisa la exploración de datos en Ethereum junto a los repositorios públicos más relevantes que almacenan código fuente de contratos inteligentes desplegados en Ethereum, y se desarrolla un prototipo de aplicación para la descarga, búsqueda y compilación de contratos inteligentes de acuerdo con diversas condiciones de selección. Palabras clave Cadena de bloques, Ethereum, Etherscan, aplicación web, aplicación de consola, contratos inteligentes. 15 Capítulo 1 - Introducción 1.1 Motivación En la cadena de bloques de Ethereum cada transacción que modifique el estado de la cadena requiere una comisión, ya sea al interactuar con una función de un contrato inteligente o al enviar una criptomoneda. Actualmente en la red de Ethereum se realizan en torno a 1 millón de transacciones diarias1, con una comisión media de entre 3 y 30 dólares en el último año dependiendo de la congestión de la red2. Esto implica que, en un entorno de alta congestión se podrían gastar en torno a 30 millones de dólares en comisiones de red. Una gran parte de todas estas comisiones vienen de la interacción con contratos inteligentes. Un contrato inteligente es un programa que se almacena en la cadena de bloques y que se ejecuta gracias a una máquina virtual integrada en cada nodo de la red. El coste de las comisiones al interactuar con contratos inteligentes viene dado por la cantidad de instrucciones que haga falta ejecutar. Con este propósito, se han desarrollan nuevas técnicas de optimización por parte de la comunidad científica en los últimos años. Fundamentalmente por la disponibilidad de grandes conjuntos de programas reales sobre los que se pueden realizar estudios experimentales. La cadena de bloques de Ethereum es especialmente interesante, pues toda la información de las transacciones realizadas está disponible públicamente. Sin embargo, aunque el código compilado de los contratos inteligentes desplegados es público, el código fuente no tiene por qué serlo. Algunos 1 https://etherscan.io/chart/tx 2 https://etherscan.io/chart/avg-txfee-usd 16 desarrolladores publican el código fuente de sus contratos en algunos repositorios públicos, como por ejemplo Etherscan [1], pero no es posible hacer búsquedas con condiciones complejas de selección de contratos. Otro campo relacionado con la investigación en Ethereum es el de la seguridad, ya que al tratar de un entorno descentralizado no hay responsables a los que acudir en casos de brechas de seguridad y resulta de gran importancia tratar de asegurar en la mayor medida de lo posible la seguridad de un contrato inteligente. Por ello, también en esta área resulta fundamental contar con grandes conjuntos de programas reales para poder desarrollar nuevas técnicas que garanticen la seguridad de los contratos. Por todo ello, la principal motivación de este proyecto es crear una herramienta que sirva de utilidad a estos investigadores, una herramienta que les permita recopilar y buscar contratos que cumplan condiciones complejas sobre diversas características y recuperar su código fuente. 1.2 Objetivos El objetivo de este Trabajo de Fin de Grado es la implementación de un sistema que permita cargar contratos desplegados en la red principal de Ethereum, almacenarlos, buscar aquellos que cumplan con ciertos criterios de búsqueda complejos, recuperar su código fuente y las opciones de compilación que fueron utilizadas y poder compilarlos con los mismos parámetros o con otros. De manera más específica, este proyecto tiene el fin de diseñar e implementar dos aplicaciones, una aplicación de consola y una aplicación web y que ambas permitan al usuario:  Buscar direcciones de contratos desplegados en la red principal según criterios de búsqueda específicos. 17  Descargar contratos verificados para almacenar su código fuente y opciones de compilación.  Consultar todos los contratos previamente cargados y recuperar los contratos según criterios de búsqueda específicos.  Compilar contratos inteligentes para obtener sus códigos compilados. 1.3 Plan de trabajo Para conseguir los objetivos se ha elaborado un plan de trabajo con reuniones semanales con los directores del proyecto para exponer ideas y herramientas que se pudiesen ser de utilidad. En el inicio de este trabajo se plantearon dos alternativas. Por una parte, se planteó la instalación de un nodo cliente de la red de Ethereum para obtener directamente la información en tiempo real de la cadena de bloques de Ethereum. Por otra parte, se planteó la utilización de servicios disponibles de consulta de Ethereum en tiempo real y repositorios públicos de código fuente de contratos. La instalación de un nodo cliente plantea diversos inconvenientes, fundamentalmente la gran cantidad de contratos que se suben diariamente que se traduce en una cantidad abrumadora de datos, así como la necesidad de tener un hardware con unos requisitos mínimos junto con un software cliente ejecutándose continuamente. Por estos motivos se descartó la instalación de un nodo cliente para centrarse en repositorios públicos de contratos. Se realizó una investigación para poder entender y descubrir herramientas que fuesen de potencial ayuda. Las principales herramientas estudiadas son Etherscan [1], Bloxy [2] y Bitquery [3]. 18 El desarrollo de las aplicaciones se ha llevado a cabo de manera secuencial, primero centrando el foco en la funcionalidad y luego aportando una interfaz gráfica adaptada a dicha funcionalidad. La funcionalidad se ha ido extendiendo y cambiando acorde a los directores de este trabajo ya que aparte de directores ellos también realizan un trabajo de investigación en la materia. 19 Capítulo 2 - Tecnología blockchain y Smart contracts La tecnología de cadena de bloques o tecnología blockchain fue por primera vez conceptualizada por Satoshi Nakamoto en su artículo llamado “Bitcoin: A Peer-to-Peer Electronic Cash System” [4]. Poco después en 2009 Bitcoin fue creado, siendo esta la primera cadena de bloques en funcionamiento con a día de hoy gran aceptación. Satoshi Nakamoto creó un sistema en el que los usuarios pueden enviar y recibir transacciones de la criptomoneda Bitcoin basado en criptografía y no en confianza, lo que hace posible que funcione sin ningún banco o tercero que gestione cada movimiento financiero. Permite que los pagos en línea se envíen directamente de una parte a otra sin pasar por ninguna institución financiera. No fue hasta 2015 con la creación de la cadena de bloques de Ethereum, junto con la criptomoneda Ether(ETH), que las posibilidades y aplicaciones de la tecnología se multiplicaron. Esto fue gracias a la implementación de una máquina virtual capaz de ejecutar una serie de instrucciones para realizar un amplio conjunto de operaciones, la Ethereum Virtual Machine (EVM), que dota a la cadena de bloques de Ethereum con la capacidad de construir smart contracts o contratos inteligentes y aplicaciones descentralizadas dentro de la propia cadena de bloques a través de lenguajes de programación como Solidity. [5] La EVM se ejecuta como una máquina de pila, con una profundidad de 1024 ítems. Cada ítem es una palabra de 256 bits, que se selecciona para utilizar fácilmente con la criptografía de 256 bits. Además, la EVM tiene varias regiones en las que almacena datos: 20  Región memory: esta es una región volátil de memoria, usada para almacenar información de manera temporal para su uso en ejecución.  Región storage: esta es una región persistente de memoria y cada vez que se actualiza se debe actualizar el estado de toda la cadena de bloques. Se puede encontrar una especificación formal con todo detalle sobre la EVM en su “yellowpaper” [6]. Los contratos inteligentes son programas que se almacenan y ejecutan dentro de la cadena de bloques, pero además son un tipo de cuenta de Ethereum esto quiere decir que poseen un saldo y pueden recibir transacciones. Los contratos inteligentes funcionan de manera autónoma conforme a como están programados, de forma que otros contratos y usuarios pueden interactuar con ellos utilizando las funciones definidas dentro del contrato inteligente. Y es que, al contrario que Bitcoin, que solo tiene transacciones para el envío de su criptomoneda, Ethereum además tiene transacciones para desplegar contratos inteligentes y transacciones para interactuar con contratos inteligentes. Estas transacciones requieren una tarifa y deben incluirse en un bloque válido. De igual manera a otros bloques de cadenas, un bloque en Ethereum es una lista de transacciones, estas pueden ser llamadas para interactuar con contratos, que está encadenado al bloque anterior mediante un hash obtenido de los datos de ese bloque, de aquí el concepto de cadena de bloques. 21 El proceso de verificación de bloques se realiza a través de un mecanismo de consenso, una serie de reglas que rigen la manera en que los nodos de la red llegan a un acuerdo sobre el estado de la cadena de bloques y la validez de las transacciones. El mecanismo de consenso más utilizado en las distintas cadenas de bloques se basa en una “prueba de trabajo”. En Ethereum este método se ha usado hasta el 15 de septiembre de 2022, tras este día Ethereum pasó a utilizar un mecanismo de consenso basado en “prueba de participación”. Este proceso se denominó “The merge” [7]. Ambas tienen la misma finalidad la de ayudar a alcanzar el consenso en la cadena de bloques de forma segura, pero con diferencias notables, la Prueba de Trabajo se basa en una competición entre los nodos validadores, llamados mineros, estos tratan de resolver problemas que requieren una carga computacional muy elevada y el que primero resuelva el problema consigue una recompensa. Para la red, la cadena más larga es la válida ya que es la que más carga computacional había necesitado para crearla. Este es un mecanismo muy eficaz para resistir a los denominados ataques Sybil de los que se hablarán un poco más adelante. El mecanismo de Prueba de Participación ya no utiliza mineros para validar bloques, ahora los nodos validadores son aquellos que tienen una participación económica en Ethereum. Para poder participar como validador, un nodo tiene que depositar 32 ETH en un contrato inteligente, entonces este se convierte en un validador y en responsable de verificar y propagar bloques. El mecanismo de consenso es el encargado de evitar la infiltración de nodos maliciosos en la red. Todos los nodos verifican el comportamiento de los demás. Si se detecta una acción maliciosa en contra de la red por parte de un nodo validador, es 22 expulsado y perdera sus 32 ETH depositados, equivalentes en el momento de escribir este documento a aproximadamente 110000 euros. Un ataque Sybil [8] es aquel en el que un nodo o grupo de nodos se hace pasar por una cantidad masiva de nodos para poder ganar influencia en las decisiones de la red. Por ejemplo, si un nodo pudiese él solo ampliar la cadena, podría crear nuevos bloques maliciosos que tengan transacciones falsas. Para que este tipo de ataque pueda darse en una cadena de bloques que utilice Prueba de Trabajo, se debería de tener más del 51 % de toda la capacidad de cómputo de la red para poder imponer un bloque fraudulente a todos los demás nodos. Esa cantidad de trabajo requiere una gran cantidad de energía de computación y la energía gastada podría incluso haber superado los beneficios obtenidos en un ataque. Algo muy similar pasa con la Prueba de Participación, donde el usuario malvado tendría que depositar y exponer el 51% del total de Ether depositado, el equivalente a una verdadera fortuna. Además de Bitcoin y Ethereum existen otras muchas otras cadenas de bloques. A día de hoy hay cientos de cadenas de bloques públicas, algunas como la cadena de bloques de Bitcoin, no Turing completas, y otras como la cadena de bloques de Ethereum, Turing completas. Sin entrar demasiado en detalle, la cadena de bloques de Ethereum es Turing completa ya que la EVM es una máquina virtual Turing completa, es decir, puede realizar cualquier computación pues permite ejecutar contratos inteligentes que contienen bucles y condicionales. Aunque normalmente se define de esta manera, realmente la EVM no es del todo Turing completa, es cuasi-Turing completa, esto se debe a que 23 la computación que está máquina virtual puede realizar está limitada por un parámetro de la máquina virtual llamado gas. El gas se puede entender como una comisión que el usuario tiene que pagar para para que los validadores de la red ejecuten las instrucciones de la EVM que forman el código del contrato. Esta comisión sirve principalmente para añadir seguridad a la red, ya que al tener que pagar una comisión por cada transacción se evitan posibles ataques de denegación de servicios basados en la ejecución de bucles infinitos y posibles ataques para saturar la red con cantidades masivas de información inútil. 2.1 Principales problemas de Ethereum Definitivamente el sistema de Ethereum ha supuesto una revolución dentro de la tecnología de cadena de bloques, esto ha supuesto un gran auge en la popularidad y usa de la cadena de bloques de Ethereum. Sin embargo, todo el éxito que ha tenido también ha traído una serie de problemas que afectan a las cadenas de bloques que usan este sistema, especialmente la red principal de Ethereum. El problema principal desde el punto de vista del usuario es que el gas que se tiene que pagar por cada transacción puede ser bastante elevado. En la figura 2-1 se puede apreciar un gráfico con el coste promedio de transacción en el último año, que alcanzó el 5 de marzo de 2024 un coste de casi 30$. 24 Figura 2-1. Coste promedio de transacción. 3 Hay que tener en cuenta que este es el coste promedio, si la transacción requiere un esfuerzo computacional superior al promedio este precio podría ser muy superior. El segundo gran problema que presenta la cadena de bloques de Ethereum es su problema de escalabilidad. Este problema tiene dos aspectos principales: el tamaño de la cadena de bloques y la congestión de la red. El problema del tamaño de la cadena de bloques de Ethereum surge ya que la red está en constante crecimiento. El problema con una cadena de bloques muy grande es el riesgo de centralización ya que llegados a un tamaño muy grande los usuarios regulares dejarían de validar y solo validarían unos pocos nodos empresariales. 3 https://etherscan.io/chart/avg-txfee-usd 31 Figura 3-1. Verificación de contratos 7 . Esto realmente es un resumen simplificado del proceso de verificación de contratos, este proceso al completo puede llegar a ser bastante tedioso, por suerte existen herramientas que lo realizan. Sourcify [11] es un ejemplo de herramienta para verificación de contratos. Etherscan [1] es un explorador de bloques que a su vez ofrece una herramienta para verificación de contratos, además de permitir al usuario la descarga de las direcciones de los últimos 5000 contratos verificados. Aunque Etherscan sea una herramienta de análisis realmente poderosa y útil para la cadena de bloques de Ethereum, cuando se trata de analizar una cantidad masiva de contratos es muy ineficiente, no tiene ningún sistema que permita, por ejemplo, filtrar los contratos cuyo creador sea una dirección o los contratos compilados en una versión concreta. Esto ralentiza muchísimo el trabajo de un investigador, y es por eso que surge la necesidad de la aplicación desarrollada en este proyecto. Esta aplicación trata de aportar facilidad para aquellos 7 https://ethereum.org/es/developers/docs/smart-contracts/verifying/ 32 usuarios que quieran almacenar y buscar contratos que cumplan ciertos criterios e incluso compilarlos con la versión del compilador deseada. 3.1 Etherscan Etherscan es un explorador de bloques de Ethereum, es decir, permite de manera relativamente sencilla explorar toda la cadena de bloques de Ethereum, desde ver cada bloque con todas sus transacciones hasta ver direcciones de usuario o de contratos. Además, Etherscan actúa como un repositorio de contratos verificados, de hecho, el propio proceso de verificación se puede realizar desde Etherscan. Aun así, la mayoría de los contratos inteligentes que se despliegan en Ethereum, no son verificados o bien porque no interesa compartir el código fuente o porque directamente no es necesario verificar un contrato para poder interaccionar con él. Como se puede ver en las figuras 3-2 y 3-3, el porcentaje de contratos verificados es muy pequeño: más del 90% de contratos desplegados no están verificados. 33 Figura 3-2. Contratos verificados diariamente 8 Figura 3-3. Contratos desplegados diariamente 9 Etherscan ha resultado ser de gran utilidad por su API de uso gratuito, aunque limitado, la cual permite de forma sencilla descargar el código fuente y los parámetros de compilación asociados a la dirección de un contrato inteligente. [12] 8 https://etherscan.io/chart/verified-contracts 9 https://etherscan.io/chart/deployed-contracts 34 3.2 Otros repositorios Para este proyecto se ha tratado de encontrar otros repositorios de contratos verificados, aunque ninguno ha sido de tanta utilidad como Etherscan. Bloxy [2] es una herramienta de análisis de cadena de bloques que parece tener una API muy completa. Aunque por desgracia dada la alta demanda, esta herramienta suspendió nuevos registros. Bitquery [3] es una plataforma con gran cantidad de herramientas en diversas cadenas de bloques, algunas prometedoras sobre todo una herramienta para realizar consultas realmente complejas dentro de la cadena de bloques. El inconveniente principal con esta herramienta es su sistema de uso. Funciona con un sistema de puntos y en la versión gratuita esos puntos se traducen en no más de 10 consultas complejas al mes. Por último, Bigquery [13] es una herramienta de Google Cloud que permite realizar consultas en sus diferentes bases de datos. Se encontró una base de datos sobre Ethereum que se actualiza en tiempo real, en la figura 3-4 se muestra el diseño de esta base de datos. El problema con esta herramienta es que no almacena los códigos fuente. Por este motivo, en este trabajo se va a integrar Bigquery y su API junto con Etherscan y su API, lo que daría una herramienta capaz de descargar fuentes y hacer consultas complejas en una base de datos que se actualiza en tiempo real. 35 Figura 3-4. Diseño de la base de datos de Bigquery.10 10 https://medium.com/google-cloud/full-relational-diagram-for-ethereum-public-dataon-google-bigquery-2825fdf0fb0b 37 Capítulo 4 - Diseño de la aplicación En este capítulo se describe la arquitectura de la aplicación y los diseños de cada una de las partes que la integran. 4.1 Arquitectura de la aplicación La arquitectura de esta aplicación se puede dividir en distintos módulos o sistemas que se comunican entre ellos creando la aplicación en sí como se muestra en la figura 4-1. Figura 4-1. Arquitectura de la aplicación 38 El módulo de carga de direcciones hace uso de los anteriormente explicados repositorios de contratos inteligentes como Etherscan, que a través del usuario alimentan con direcciones de contratos a la aplicación. Mediante dos llamadas a la API proporcionada por Etherscan y un conjunto de direcciones de contratos, se obtiene el código fuente de los contratos inteligentes que estén verificados y los parámetros de compilación. Este módulo además es el encargado de generar y poblar las tablas de la base de datos MySQL según el repositorio fuente del que proceden las direcciones que el usuario carga, guardando los siguientes parámetros de compilación:  SourceCode: el código fuente del contrato.  CompilerVersion: la versión del compilador que se usó para compilar el contrato.  OptimizationUsed: parámetro usado a la hora de la compilación.  Runs: parámetro usado a la hora de la compilación.  EVMVersion: la versión de la EVM.  LicenseType: el tipo de licencia que tiene el contrato. Por último, se genera el archivo CSV en local, en el directorio csv_out, que almacena la misma información guardada en la tabla de la base de datos. El módulo de consultas está integrado principalmente por una base de datos MySQL que nos permite hacer consultas de todos los contratos guardados en ella. Además de esta base de datos la aplicación cuenta con una conexión al servicio de Bigquery, sobre el que se pueden realizar consultas directamente a su repositorio. Tras ejecutar la consulta sobre la base de datos 39 local o sobre el repositorio de Bigquery, guarda los resultados en un fichero csv en el directorio local consultas_out. Por último, está el módulo de compilación de contratos, que permite al usuario proporcionar el código fuente de un contrato y la versión del compilador deseada para compilarlo. La compilación del contrato se hace gracias a dos comandos que se ejecutan tras saber la versión del compilador: solc-select use versión --always-install solc -o compilados/contrato --bin –asm --opcodes --overwrite ruta El primer comando utiliza el módulo de solc-select para cambiar la versión local del compilador de Solidity a la versión indicada por el usuario, gracias a la opción --always-install si el usuario no tiene instalada la versión indicada del compilador, se le instalará. El segundo comando compila el código fuente ubicado en la ruta indicada por el usuario y los siguientes archivos de salida en la el directorio compilados:  Archivos binarios .bin del contrato en hexadecimal.  Archivos con el código en ensamblador del contrato.  Archivos con los opcodes del contrato. 40 4.2 Diseño de datos En esta sección se describen los componentes de almacenamiento de los datos usados en la aplicación. En la primera subsección se explica qué se guarda en la base de datos local, en la segunda subsección se explica qué datos se usan como entrada para la aplicación y en la última qué datos se guardan en los archivos locales. 4.2.1 Diseño de la base de datos Hay que destacar que las tablas de la base de datos no tienen relación entre sí. Hay dos tipos de tablas en la base de datos: las tablas de contratos y la tabla de consultas. Las tablas de contratos siempre tienen los siguientes campos que son obligatorios:  compilerversion: versión con la que se compiló el contrato.  optimization: parámetro de compilación.  runs: parámetro de compilación.  evmversion: versión de la Ethereum Virtual Machine.  licensetype: tipo de licencia usada en la compilación.  fuente: procedencia del contrato.  contractcreator: dirección creadora del contrato.  ruta: ruta en la que se almacena el código fuente del contrato.  address: dirección del contrato. 47 archivo. Este formato representará las columnas de la tabla en la base de datos. El único campo obligatorio en el formato es el de “address”. A continuación, se muestra un ejemplo de uso solo en el que solo se mostrarán las pantallas ya que tanto el CSV de entrada como la carpeta donde se guardan el código fuente sería igual. Suponiendo un CSV muy similar al anterior, “contratos_verificados2” proveniente de Bigquery y con dos campos diferentes, “Bloque” y “Time”, el usuario introduce la fuente con los campos adicionales y el formato del CSV. Figura 4-10.Carga de direcciones de otras fuentes sin CSV. Figura 4-11. Carga de direcciones de otras fuentes con CSV. 48 Como se ha mencionado anteriormente los archivos de código fuente descargados se guardan igual que antes, pero aquí cabe destacar que se crea una nueva tabla en la base de datos del usuario con el nombre “contracts_bigquerybloquetime” y con dos columnas diferentes dadas en el formato del CSV. 4.4.1.5 Página de búsqueda Esta página permite al usuario realizar consultas a su base de datos local, al repositorio de Bigquery o realizar consultas anteriormente realizadas. Esta página tiene tres menús expandibles con diferentes opciones: el primero contiene las columnas a las que el usuario puede realizar la consulta, la segunda contiene las todas las tablas que hay en la base de datos y la tercera contiene las consultas anteriores junto a dos opciones para crear una consulta propia y hacer una consulta a Bigquery, respectivamente. Si la opción seleccionada es la de consulta propia, figura 4-12, el usuario tiene que indicar un nombre de consulta y la propia consulta SQL. Si la opción es consultas anteriores, figura 4-13, se muestra otra lista desplegable que contiene las consultas anteriormente realizadas, las que se guardan en la tabla consultas de la base de datos. Por último, si se selecciona Bigquery, figura 4-14, el usuario debe proveer un token de Bigquery necesario para usar la API de Bigquey. Figura 4-12. Página de búsqueda, consulta propia. 49 Figura 4-13. Página de búsqueda, consultas anteriores. Figura 4-14. Página de búsqueda. Para detallar bien esta funcionalidad se mostrarán varios ejemplos de uso. En el primer ejemplo de uso, el usuario trata de hacer una consulta ya hecha, para ello indica la columna, la tabla, la consulta y la condición como se muestra en la figura 4-15. También puede ver su consulta antes de ejecutarla para ver si es correcta. Figura 4-15. Pantalla de consulta. 50 Una vez se ejecuta la consulta, si se ejecuta con éxito, se genera el archivo CSV correspondiente y se puede previsualizar en la propia pantalla como se muestra en la figura 4-16. Además de un mensaje donde se indica que el CSV se guarda en la carpeta “consultas_out” con el nombre proporcionado a la consulta y la fecha de la consulta. Figura 4-16. Resultado de la consulta. Para el segundo ejemplo de uso, el usuario quiere ejecutar una consulta que ya ha realizado en el pasado, en la tabla de consultas elige la opción de “Consultas anteriores” y si quiere la modifica como se muestra en la figura 4-17. El resultado se muestra igual que en el ejemplo de uso anterior. Figura 4-17. Consultas anteriores. 51 En el último caso de ejemplo el usuario quiere realizar una consulta a través de Bigquery. Para ello en la tabla de consultas selecciona la opción de Bigquery, el usuario debe proporcionar un token de Bigquery, la consulta a realizar y un nombre para ella. En la figura 4-18, una vez seleccionada la opción de Bigquery, se ve el input que permite al usuario subir el token de Bigquery, más abajo el campo azul para darle un nombre a la consulta, la consulta en un componente modificables y por último el botón para ejecutar la consulta. Figura 4-18. Pantalla consulta de Bigquery. Para construir una consulta de Bigquery el usuario debe utilizar el diseño proporcionado en la figura 3-4, las tablas más interesantes son:  Contracts: que recoge información de contratos como direcciones, código compilado o el número de bloque en el que se desplegó. 52  Transactions: que recoge información de transacciones como el gas usado en la transacción, el hash de la transacción o el número de bloque al que pertenece.  Blocks: que recoge información de los bloques como su hash o el hash del bloque anterior, la fecha en la que se añadió a la cadena de bloques o la cantidad de transacciones que tiene. 4.4.1.6 Página de compilar Esta página permite al usuario subir un archivo .sol que debe contener el código fuente de un contrato, en la figura 4-19 se puede ver la pantalla sin el archivo seleccionado. Una vez seleccionado se visualiza en un componente modificable, es decir, que el contrato se puede modificar antes de compilarlo. La aplicación extrae automáticamente las directivas pragma del contrato para que el usuario pueda seleccionar la versión del compilador que se va a utilizar. El usuario también puede elegir una versión del compilador específica. En la figura 4-20 se puede ver la pantalla una vez se selecciona el archivo, en ella aparecen las directivas pragma extraídas del contrato y el componente modificable con el código fuente del contrato. Figura 4-19. Página de compilar contratos sin archivo seleccionado. 53 Figura 4-20. Página de compilar contratos con archivo seleccionado. 4.4.2 Diseño de la aplicación de consola La aplicación de consola fue pensada para un usuario más experto ya que es sacrifica el aspecto visual que es más descriptivo a cambio de un posible uso de la herramienta de manera más eficaz. Esta aplicación fue diseñada con un menú principal que permite al usuario elegir la funcionalidad deseada y se comunica con él pidiendo el input necesario como rutas a un archivo o la consulta SQL específica. El menú principal tiene seis opciones como se muestra en la figura 4-21, el usuario introduce el número asociado a la función que quiere usar. 54 Figura 4-21. Menú consola. La primera opción crea la base de datos MySQL. La segunda opción carga direcciones que vienen de Etherscan, también descarga los archivos de código fuente de las direcciones cargadas y guarda toda la información en la tabla contracts. Por lo que el usuario debe proporcionar un CSV que tenga el formato de Etherscan. El usuario también debe especificar el repositorio fuente del que vienen las direcciones y si el CSV proporcionado está preprocesado o no como se muestra en la figura 4-22. Figura 4-22. Opción carga CSV de Etherscan. La tercera opción permite al usuario cargar direcciones igual que con la segunda opción con la diferencia de que el CSV proporcionado ya no tiene que seguir el formato de Etherscan como se muestra en la figura 4-23. Además, ya no se almacena la información en la tabla contracts sino que se guardan en una tabla que representa ese mismo formato, esta tabla se crea con el nombre 55 del repositorio fuente concatenado con contracts_, por ejemplo, si el repositorio del que vienen las direcciones es Bitquery la tabla se llamará contracts_bitquery. Figura 4-23. Opción carga CSV de otras fuentes. La cuarta opción es la encargada de realizar consultas en la base de datos donde el usuario puede elegir entre una serie de consultas ya hechas en las que tiene que indicar los campos que faltan como las columnas o el nombre de la tabla como se muestra en la figura 4-24. El usuario también puede proporcionar su propia consulta SQL. 56 Figura 4-24. Opción consulta. La quinta opción se encarga de compilar un contrato inteligente, el usuario tiene que introducir la ruta donde tiene el código fuente del contrato inteligente y tiene que introducir la versión del compilador como se muestra en la figura 4-25. Figura 4-25. Opción compilar. La última opción simplemente termina la ejecución de la aplicación. El desarrollo de esta aplicación se realizó en paralelo junto con la aplicación web ya que al final la funcionalidad es prácticamente la misma. 63 algún servicio de pago para la descarga de direcciones y códigos fuente de contratos. Tanto Etherscan como Bigquery tienen versiones de pago con menos limitaciones y más funcionalidades.  Otro aspecto a mejorar sería el de migrar ambas aplicaciones a un servidor para no tener que ejecutarlas en local. Este trabajo se ha centrado en implementar la funcionalidad de la aplicación, pero se puede adaptar sin grandes cambios para instalarla en un servidor. Para hacer dicha adaptación podría ser necesario añadir un módulo de control de acceso de usuarios.  Siguiendo una de las propiedades más importantes del paradigma de las cadenas de bloques, la descentralización, un trabajo a futuro podría ser el de adaptar las aplicaciones a un sistema de archivos descentralizado como IPFS [26]. A partir de aquí las sugerencias de extensión del trabajo deberían surgir del propio uso de más clientes junto con el propio avance de la tecnología. Es algo indiscutible que el ecosistema de criptomonedas está en auge, cada día hay más conocedores de este ecosistema y usuarios que quieren formar parte de este ecosistema, pero también es verdad que las barreras de entrada son grandes para los usuarios. Por este motivo es importante contribuir a una constante mejora de esta tecnología, y para ello es necesario la utilización de herramientas como la desarrollada en este Trabajo de Fin de Grado. 65 Introduction Motivation Within the Ethereum blockchain, every transaction that modifies the blockchain state requires a fee, whether it interacts with a smart contract function or when sending a cryptocurrency. Currently, about 1 million11 transactions are executed within the Ethereum network daily, with a fee between 3 and 30 dollars during the last year, depending on the network congestion12. A big part of all these fees comes from the interactions with smart contracts. A smart contract is a program stored in the blockchain and is executed thanks to a virtual machine integrated within each node of the network. The cost of these fees when interacting with smart contracts comes from the amount of instructions needed to be executed. With this goal in mind, new optimization techniques have been developed by the scientific community in the past years. This was fundamentally possible due to the availability of large sets of programs that can be used to carry out experimental studies. The Ethereum blockchain is especially interesting as all the information on the transactions executed is available to the public. On the other hand, even though the compiled code of the deployed smart contracts is public, the source code does not necessarily have to be so. Some developers publish the source code of their contracts in certain public 11 https://etherscan.io/chart/tx 12 https://etherscan.io/chart/avg-txfee-usd 66 repositories such as Etherscan [1], but it is not possible to do searches with complex select conditions for contracts. Another field related to research on Ethereum is security, as when working with a decentralized environment there are not any responsible parties to go to when security breaches occur. As such, it is of extreme importance to try to ensure the security of smart contracts as much as possible. Consequently, it is also fundamental to have large sets of real programs to develop new techniques that guarantee the security of the smart contracts. Therefore, the main motivation behind this project is to create a tool that is useful for said researchers, a tool that allows them to gather and search contracts that match the complex requirements of different characteristics and retrieve their source code. Goals The objective of this thesis is the implementation of a system that allows loading deployed contracts displayed on the Ethereum main net, storing them, searching those that meet specific complex requirements, retrieving their source code and compilation options that were used, and compiling them with the same or different parameters. More specifically, this project aims to design and implement two applications, a console and a web application that allow the user to:  Search contract addresses deployed on the Ethereum main net according to specific search criteria.  Download verified contracts to store their source code and compilation options. 67  Query all the previously loaded contracts and retrieve their contracts according to specific search criteria.  Compile smart contacts to obtain their compiled bytecode. Work plan To achieve the objectives, a work plan, consisting of weekly meetings with the project leaders to present ideas and tools that might be useful, has been developed. At the start of this thesis, two alternatives were proposed. On one hand, the installation of an Ethereum client node was suggested to directly obtain the information of the Ethereum blockchain in real-time. On the other hand, using the available real-time Ethereum searching services and public source code repositories of contracts was considered. The installation of a client node presents various drawbacks, the main one being that the large quantity of smart contracts that are uploaded daily translates into an overwhelming amount of data, as well as the need to have hardware with specific requirements and client software constantly being executed. Because of this, the idea of the installation of a client node was discarded to focus on the public source code repositories of contracts approach. An investigation was carried out to understand and discover tools that could help. The main tools studied are Etherscan [1], Bloxy [2] and Bitquery [3]. 68 The development of the applications has been carried out sequentially, firstly focusing on functionality and then providing a graphic interface to said functionality. The functionality has been expanding and changing according to the directors of this thesis as a part of being the directors, they are also doing a research project on the matter. 69 Conclusions and future work The main goal of this thesis comes from the need for a tool that allows one to download the source code of smart contracts that match complex selection criteria to research the smart contracts deployed on the Ethereum main net. More specifically, two applications have been developed, a console one and one with a web user interface that allows for searching the addresses of deployed contracts using complex searches in Biquery as well as downloading the source code of verified contracts in the repository given by Etherscan. Furthermore, these applications allow to do queries about smart contracts according to complex and specific search criteria. All the queries done until now can be stored in the local database, making it possible to repeat them on other smart contracts. Lastly, it allows the compilation of downloaded contracts with different compilation configurations. These applications have been developed and implemented following the specifications given by the thesis directors. Both the web application and the console application have been implemented with all the planned functionality and therefore can be said that the objectives of this thesis have been met. Even though the objectives of the thesis have been completed, there still is a lot of work that can be put into this project to make it better:  An aspect that was studied and can be improved was the automatization of the loading of addresses from Etherscan, an improvement that had to be discarded due to the existence of a captcha that requires a manual download. The possibility of using paid services for the download of addresses and contract source codes can be explored. Both Etherscan and Bigquery have paid versions with fewer limitations and more functionalities. 70  Another aspect to improve would be to migrate both applications to a server to avoid executing them locally. This project has focused in implementing the functionality of the application but can be adapted to install it on a server without needing major changes. To do said adaptation, it could be necessary to add a module to control user access.  Following one of the most important properties of the paradigm of blockchain, decentralization, a future project could be to adapt the applications to a decentralized archive system like IPFS [24]. From here on, the suggestions for the expansion of the thesis should come from the use of the clients and the advancements of the technology itself. It is indisputable that the cryptocurrency ecosystem is booming, every day more and more connoisseurs of the ecosystem and users want to be a part of it, but it is also true that there are high entry barriers for them. Because of this, it is important to contribute to a constant improvement of this technology and for that, the utilization of tools like the one developed in this thesis is essential. 71 Bibliografía [1] Etherscan, Explorador de bloques de Ethereum, «https://etherscan.io/». [2] Bloxy, «https://bloxy.info/». [3] Bitquery, «https://bitquery.io/». [4] S. Nakamoto, «https://bitcoin.org/bitcoin.pdf,» Bitcoin: A Peer-toPeer Electronic Cash System, 2008. [5] Solidity, «https://soliditylang.org/». [6] Ethereum Yellow Paper, «https://ethereum.github.io/yellowpaper/paper.pdf». [7] Ethereum foundation, «https://ethereum.org/es/roadmap/merge/,» La fusión, The merge.. [8] Ataque Sybil, «https://en.wikipedia.org/wiki/Sybil_attack». [9] Ethereum.org, «https://ethereum.org/es/developers/docs/evm/,» Máquina virtual de Ethereum. [10] GETH, «https://geth.ethereum.org/». [11] Sourcify, «https://sourcify.dev/#/verifier,» Herramienta web de verificación de contratos. [12] EtherscanAPI, «https://docs.etherscan.io/apiendpoints/contracts,» 72 Etherscan API contracts endpoint. [13] Bigquery, «https://cloud.google.com/bigquery?hl=es». [14] Etherscan CSV 5000 contratos verificados, «https://etherscan.io/exportData?type=open-source-contract-codes». [15] Figma, «https://www.figma.com/». [16] Node.js, «https://nodejs.org/en». [17] Next.js, «https://nextjs.org/». [18] Python, «https://www.python.org/». [19] MySQL, «https://www.mysql.com/». [20] Yarn, «https://yarnpkg.com/». [21] TailwindCSS, «https://tailwindcss.com/». [22] Solc-select, «https://github.com/crytic/solc-select». [23] Solc, «https://binaries.soliditylang.org/». [24] Flask, «https://flask.palletsprojects.com/en/3.0.x/». [25] Typescript, «https://www.typescriptlang.org/». [26] IPFS, «https://ipfs.tech/,» Sistema de archivos descentralizados.