Análisis topológico de las matrices de ocurrencias en la red de Bitcoin

TRABAJO FIN DE GRADO An´alisis Topol´ogico de las Matrices de Ocurrencia en la Red de Bitcoin Realizado por Joan Villalonga ´ Alvaro Para la obtenci´on del t´ıtulo de Grado en Ingenier´ıa Inform´atica - Tecnolog´ıas Inform´aticas Dirigido por Roc´ıo Gonz´alez D´ıaz Nieves Atienza Mart´ınez Realizado en el departamento de Matem´atica Aplicada I Convocatoria de Julio, curso 2022/23 Agradecimientos En primer lugar, me gustar´ıa agradecerles a mi pareja y a mi hermana el apoyo incondicional que me han dado siempre, los empujoncitos cuando cre´ıa que no lo conseguir´ıa, y simplemente el haber estado ah´ı siempre que lo he necesitado. Son personas fundamentales para m´ı y espero seguir aprendiendo de ellas y creciendo a su lado. A mis padres, por buscar lo mejor para m´ı, y darme una vida lo m´as feliz y plena que han sabido y podido. Por su puesto, tiene que haber un hueco aqu´ı para mis tres compa˜neras de siempre Alicia, Celia y Paula, que hemos recorrido juntos el viaje por la universidad y que nos hemos apoyado siempre codo con codo. Les estar´e eternamente agradecido por todo lo que han hecho por m´ı, ya que creo que si no fuera por ellas, hoy puede que no estuviera en este punto de mi vida. Tambi´en quiero agradecerles a mis familiares y amigos todo su apoyo, ya que gracias a ellos hoy soy quien soy, mis t´ıas y mi abuela, las que siempre cuidaron de mi hermana y de m´ı cuando ´eramos peque˜nos. Y por supuesto a mis abuelos tanto a Pedro y Sisca como a mi abuela Manoli, por todo lo que he aprendido de ellos y darme tantos momentos bonitos. Por otro lado, quiero agradecer a mis tutoras, la constancia con la que me han ayudado a poder realizar este proyecto, as´ı como la forma de ense˜narme a investigar y priorizar mi aprendizaje. Para m´ı ha sido un gran placer trabajar con dos grandes matem´aticas como vosotras y simplemente deciros, que me alegro mucho de haberos elegido como tutoras para esta ´ultima etapa que culmina mi carrera universitaria. Ya para terminar, aunque pueda sonar algo egoc´entrico, me gustar´ıa agradecerme a m´ı mismo el haber llegado hasta aqu´ı, que me he demostrado que se puede contra todo pron´ostico. He trabajado mucho para llegar hasta aqu´ı y puesto que no solemos agradecernos las cosas a nosotros mismos, creo que aunque sea en ocasiones hay que hacerlo. Gracias a m´ı mismo por no rendirme, por haber aguantado esos d´ıas y d´ıas de estudio sin parar, por haber aguantado aquellos d´ıas de no parar y no parar pese a estar en medio de una pandemia y que el trabajo no dejara de aumentar, por haber perseguido el sue˜no de vivir en Francia un tiempo, y por no dejar de so˜nar (como dir´ıa Mar´ıa Pati˜no). i Resumen Tras el nacimiento de Bitcoin, se ha producido una profunda transformaci´on en los mercados digitales y la bolsa, dando lugar a conceptos completamente novedosos. Esto ha despertado un notable inter´es tanto por parte de empresas como de investigadores, quienes buscan comprender los fen´omenos resultantes de los acontecimientos en este mercado digital. Motivado por la propuesta de mis tutoras, no dud´e en adentrarme en este campo totalmente desconocido para m´ı. A pesar de la gran cantidad de informaci´on que hay disponible sobre esta criptomoneda, a´un existen aspectos del funcionamiento de Bitcoin y las criptomonedas en general que son poco conocidos. Este trabajo se divide en dos secciones principales. En la primera, se presentan los t´erminos esenciales sobre Bitcoin y Blockchain para comprender el contexto en el que se desenvuelve el proyecto. Para ello, principalmente se utilizar´an los art´ıculos “Blockchain: A Graph Primer”[3] y “Forecasting Bitcoin Price with Graph Chainlets”[1]. La segunda secci´on es m´as pr´actica, y tiene como objetivo obtener y estudiar matrices que reflejen las ocurrencias de los distintos tipos de transacciones realizadas. Gracias al an´alisis exhaustivo llevado a cabo en este proyecto sobre las matrices de ocurrencia antes mencionadas, hemos logrado obtener resultados innovadores en cuanto a la entrop´ıa persistente de las mismas. Hemos conseguido este avance al aplicar dos tipos distintos de filtraciones, permiti´endonos conocer en qu´e casos es ´util normalizar las matrices y en cuales no a la hora de estudiar la homolog´ıa persistente y entrop´ıa persistente. Link al repositorio: https://github.com/joavilalv/TFG Joan Villalonga Alvaro.git Palabras clave: Bitcoin, Blockchain, transacci´on, criptodivisa, grafo, chainlet, homolog´ıa persistente, entrop´ıa persistente. ii Abstract After the birth of Bitcoin, there has been a profound transformation in the digital markets and the stock market, giving rise to completely new concepts. This has aroused considerable interest from both companies and researchers, who seek to understand the phenomena resulting from events in this digital market. Motivated by the proposal of my tutors, I did not hesitate to enter this field totally unknown to me. Despite the large amount of information that is available about this cryptocurrency, there are still aspects of the operation of Bitcoin and cryptocurrencies in general that are little known. This work is divided into two main sections. In the first, the essential terms on Bitcoin and Blockchain are presented to understand the context in which the project is developed. For this, the articles “Blockchain: A Graph Primer”[3] and “Forecasting Bitcoin Price with Graph Chainlets”[1] will mainly be used. The second section is more practical, and its objective is to obtain and study matrices that reflect the occurrences of the different types of transactions carried out. Thanks to the comprehensive analysis carried out in this project on the aforementioned occurrence matrices, we have achieved innovative results regarding their persistent entropy. We have accomplished this breakthrough by applying two different types of filtrations, enabling us to understand when it is beneficial to normalize the matrices and when it is not, when studying persistent homology and persistent entropy. Link to the repository: https://github.com/joavilalv/TFG Joan Villalonga Alvaro.git Keywords: Bitcoin, Blockchain, transaction, cryptocurrency, graph, chainlet, persistent homology, persistent entropy. iii ´ Indice general 1. Introducci´on 1 2. Objetivos y metodolog´ıa 3 2.1. Introducci´on................................. 3 2.2. Objetivos .................................. 3 2.3. Metodolog´ıa................................. 3 2.4. Planificaci´on................................. 4 2.5. Presupuesto................................. 4 3. Blockchain: A Graph Primer 6 3.1. Blockchain.................................. 6 3.2. Bitcoin.................................... 7 3.3. Construyendo los bloques de Blockchain . . . . . . . . . . . . . . . . . 8 3.3.1. Direcciones ............................. 8 3.3.2. Transacci´on ............................. 8 3.3.3. Verificaci´on y confirmaci´on . . . . . . . . . . . . . . . . . . . . . 9 3.4. Ejemplo ................................... 12 3.5. Conclusi´on.................................. 13 4. Graph chainlets 14 4.1. Introducci´on a los chainlets . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Aplicaciones del estudio de Blockchain mediante chainlets . . . . . . . . 14 4.3. Metodolog´ıa................................. 15 4.3.1. GraphChainlets .......................... 16 4.3.2. Clustering Chainlets . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Herramientas de topolog´ıa utilizadas en este proyecto 18 5.1. Homolog´ıa persistente . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Diagrama de persistencia y barcodes . . . . . . . . . . . . . . . . . . . 18 5.3. Entrop´ıa persistente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Filtraci´on Vietoris-Rips . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. Filtraci´on Lower-Star . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Filtraci´on Upper-Star . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Herramientas de programaci´on y librer´ıas utilizadas 27 6.1. Introducci´on................................. 27 6.2. Python.................................... 27 6.3. Anaconda .................................. 27 6.4. Ripser, Scikit-tda y Persim . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Extracci´on de los datos 28 7.1. Introducci´on................................. 28 iv 7.2. Blockchain networks: Data structures of Bitcoin, Monero, Zcash, Ethereum,Ripple,andIota ........................... 28 7.2.1. Graph rules for UTXO Blockchains . . . . . . . . . . . . . . . . 29 7.3. Bitcoin Transaction Network . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.1. Archivos de input o entrada . . . . . . . . . . . . . . . . . . . . 30 7.3.2. Archivos de output o salida . . . . . . . . . . . . . . . . . . . . 31 8. Implementaci´on 32 8.1. Estructura del repositorio de Akcora . . . . . . . . . . . . . . . . . . . 32 8.2. Matrizdeocurrencia ............................ 32 8.3. Importaci´on de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.3.1. Normalizaci´on y representaci´on en imagen a escala de grises . . 34 8.4. Experimentaciones ............................. 35 8.4.1. Vietoris-Rips ............................ 35 8.4.2. Lower-Star.............................. 44 8.4.3. Upper-Star ............................. 46 8.4.4. Resultados te´oricos novedosos derivados del an´alisis realizado . . 50 9. Conclusiones y trabajo futuro 53 9.1. Conclusi´on sobre la investigaci´on realizada . . . . . . . . . . . . . . . . 53 9.1.1. Complejidad del proyecto . . . . . . . . . . . . . . . . . . . . . 53 9.1.2. Conclusiones obtenidas a partir del estudio realizado . . . . . . 54 9.2. Desv´ıos del planteamiento inicial . . . . . . . . . . . . . . . . . . . . . 55 9.3. Posibles mejoras para futuras investigaciones . . . . . . . . . . . . . . . 57 10.Bibliograf´ıa 58 v ´ Indice de figuras 1.1. Tiposderedes................................ 1 1.2. ReddeBitcoin ............................... 2 3.1. Blockchain.................................. 6 3.2. Proof-of-Work................................ 7 3.3. Tipos de transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Estructura de Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Ataquesdeeclipse ............................. 11 3.6. Ejemplo de Blockchain. Imagen extra´ıda de [9]. ............. 12 3.7. Ejemplo de Sybil Atack . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Representaci´on gr´afica de transacciones de la red Bitcoin . . . . . . . . 15 4.2. Tipos de chainlets. Merge (C3→1), Transition (C3→3), Split (C3→4). . . . 16 5.1. Ejemplodebarcode. ............................ 19 5.2. Ejemplo de diagrama de persistencia. . . . . . . . . . . . . . . . . . . . 19 5.3. Ejemplo de homolog´ıa persistente con Vietoris-Rips. . . . . . . . . . . . 21 5.4. Ejemplo de Lower-Star . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.5. Ejemplo de Lower-Star: Primera componente conexa . . . . . . . . . . 23 5.6. Ejemplo de Lower-Star: Dos primeras componentes conexas . . . . . . . 23 5.7. Ejemplo de Lower-Star: Una sola componente conexa . . . . . . . . . . 24 5.8. Barcodedelejemplo ............................ 24 5.9. Ejemplo de filtraci´on Lower-Star con la matriz cambiada de signo (que se corresponde con al filtraci´on Upper-Star). . . . . . . . . . . . . . . . 25 5.10. Primera componente conexa con Upper-Star . . . . . . . . . . . . . . . 25 5.11. Segunda componente conexa con Upper-Star . . . . . . . . . . . . . . . 26 5.12. Una sola componente conexa con Upper-Star . . . . . . . . . . . . . . . 26 5.13.BarcodeUpper-Star............................. 26 7.1. Ilustraci´on sobre transacciones con Bitcoin. . . . . . . . . . . . . . . . . 29 8.1. Matriz de ocurrencia del d´ıa 154 de 2016, correspondiente al 2 de junio de2016. ................................... 33 8.2. Representaci´on de entrop´ıa persistente con Vietoris-Rips. . . . . . . . . 37 8.3. D´ıas de entrop´ıa m´axima y m´ınima mediante Vietoris-Rips . . . . . . . 37 8.4. Matriz de entrop´ıa m´axima mediante Vietoris-Rips . . . . . . . . . . . 38 8.5. Matriz de entrop´ıa m´ınima mediante Vietoris-Rips . . . . . . . . . . . . 39 8.6. Gr´afica de entrop´ıa con Vietoris-Rips con las matrices normalizadas . . 40 8.7. Valores de entrop´ıa m´axima y m´ınima con Vietoris-Rips normalizando lamatriz................................... 40 8.8. Matriz de entrop´ıa m´axima con Vietoris-Rips normalizando la matriz . 41 8.9. Matriz de entrop´ıa m´ınima con Vietoris-Rips normalizando la matriz . 42 8.10. Gr´afica de entrop´ıa mediante el tercer experimento . . . . . . . . . . . 43 8.11. Matriz de entrop´ıa m´axima mediante el tercer experimento . . . . . . 43 vi 8.12. Matriz de entrop´ıa m´ınima mediante el tercer experimento . . . . . . . 44 8.13. Resultados de entrop´ıa mediante Lower-Star . . . . . . . . . . . . . . . 46 8.14. D´ıas de entrop´ıa m´axima y m´ınima mediante Lower-Star . . . . . . . . 46 8.15. Matriz de entrop´ıa m´axima mediante Lower-Star . . . . . . . . . . . . . 47 8.16. Matriz de entrop´ıa m´ınima mediante Lower-Star . . . . . . . . . . . . . 48 8.17. Resultados de entrop´ıa mediante Upper-Star . . . . . . . . . . . . . . . 48 8.18. D´ıas de entrop´ıa m´axima y m´ınima mediante Upper-Star . . . . . . . . 49 8.19. Matriz de entrop´ıa m´axima mediante Upper-Star . . . . . . . . . . . . 49 8.20. Matriz de entrop´ıa m´ınima mediante Upper-Star . . . . . . . . . . . . . 50 9.1. Engrosamiento de puntos con Vietoris-Rips . . . . . . . . . . . . . . . . 54 vii ´ Indice de extractos de c´odigo 8.1. Funci´on de lectura de datos de una matriz de ocurrencia . . . . . . . . 33 8.2. Funci´on para la normalizaci´on de los datos . . . . . . . . . . . . . . . . 34 8.3. Representaci´on de la imagen a escala de grises . . . . . . . . . . . . . . 34 8.4. Funci´on para calcular la entrop´ıa mediante Vietoris-Rips . . . . . . . . 35 8.5. C´alculo de entrop´ıas mediante Vietoris-Rips para todos los d´ıas de 2017 36 8.6. Representaci´on de entrop´ıas mediante Vietoris-Rips de 2017 . . . . . . 36 8.7. Matrices de entrop´ıa m´axima y m´ınima con Vietoris-Rips . . . . . . . . 36 8.8. Normalizaci´on de matrices . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.9. C´alculo de entrop´ıa mediante Lower-Star . . . . . . . . . . . . . . . . . 44 viii 3.2. Bitcoin Bitcoin es una moneda virtual dise˜nada de forma segura para utilizarse como forma de pago sin necesidad de intervenci´on por parte de una autoridad central [13]. Hasta la creaci´on de esta criptodivisa, en varias ocasiones, otras monedas cre´ıan haber conseguido crear un m´etodo de pago factible pero finalmente no era as´ı. Esto se deb´ıa a leyes y reglamentos que las obstaculizaban, pero sobre todo a deficiencias t´ecnicas. Sin embargo, los creadores de Bitcoin se sirvieron de los errores de sus predecesores para aprender y poder crear esta moneda digital. Otra opci´on distinta al modelo de Blockchain que se planteaba como alternativa a una autoridad central, era que todos los usuarios llevaran un registro de los saldos de todos los usuarios. El problema de esta idea era la velocidad y seguridad de transmisi´on de la informaci´on sobre las transacciones. Adem´as, si hubiera cualquier problema en las redes, usuarios malintencionados podr´ıan beneficiarse mintiendo sobre los saldos. Mientras que el problema de la autoridad central segu´ıa siendo un desaf´ıo en el campo de las monedas digitales, se encontr´o una soluci´on en el ´ambito no relacionado de la detecci´on de spam en los correos electr´onicos. Los proveedores de correo electr´onico se enfrentaban al problema de recibir un gran n´umero de correos electr´onicos no deseados, aunque estos pod´ıan ser analizados y etiquetados como spam, el proceso consum´ıa excesivos recursos del sistema. Para prevenir esto surgi´o HashCash, t´ecnica que propone un acuerdo entre los remitentes de correo electr´onico y los proveedores de este. Los remitentes de correo electr´onico deben hacer un c´alculo para cada uno y adjuntar una prueba del calculo a dicho correo. El c´alculo est´a dise˜nado para consumir mucho tiempo, mientras que la verificaci´on de la prueba es f´acil. El proveedor de correo electr´onico acepta aquellos que contengan pruebas v´alidas y descarta a todos los dem´as. Esta metodolog´ıa se llama Proof-of-Work. Aunque no evita que un remitente pueda crear un correo electr´onico no deseado, calcular su prueba y enviarlo hace que sea demasiado dif´ıcil enviar muchos correos de este tipo. Figura 3.2: Proof-of-Work Nakamoto utiliz´o esta idea para evitar que los mineros mintieran sobre los bloques a la hora de minarlos (puesto que se necesita gastar una cantidad considerable de energ´ıa para minar un bloque). Adem´as, cada bloque contiene el hash del bloque anterior formando una cadena inmutable, de forma que si esta cambiara, el hash de los bloques posteriores al modificado ser´ıa distinto. Esta disposici´on de los bloques dio nombre a este sistema: Blockchain (cadena de bloques). 7 3.3. Construyendo los bloques de Blockchain Una vez comprendidas las bases sobre Blockchain y Bitcoin, en esta secci´on se explicar´a c´omo funciona la Blockchain de Bitcoin, as´ı como la verificaci´on de las transacciones y el minado de los bloques. 3.3.1. Direcciones Una direcci´on Blockchain es una cadena ´unica de 26 a 35 caracteres creada a partir de claves p´ublicas generadas a partir del m´etodo de encriptaci´on Elliptic Curve Digital Signature Algorithm (ECDSA), que como bien indica su nombre, el algoritmo se basa en la estructura algebraica de curvas el´ıpticas sobre campos finitos. Este m´etodo de encriptaci´on consigue el mismo nivel de seguridad que otros con claves mayores, pero en este caso utilizando claves de menor tama˜no [12]. Bitcoin utiliza dos tipos de direcciones: Direcci´on de pago PubkeyHash que comienza con 1 como en: 1Pudc88gyFynBVZccRJeYyEV7ZnjfXnfKn. Direcci´on de pago ScriptHash que comienza con 3 como en : 3J4kn4QoYDj95S3fqajUzonFhLyjjfKjP3 El tipo de direcci´on mas utilizada o m´as com´un es PubkeyHash, que usa una sola clave privada para gastar los Bitcoins recibidos de una transacci´on. ScriptHash vino m´as tarde para permitir transacciones que necesitaran aprobaci´on de m´ultiples usuarios. Desde una perspectiva gr´afica, el tipo de direcci´on no cambia nada, ambos pueden usarse en transacciones como direcciones de entrada o de salida. La diferencia es que ScriptHash permite a varios usuarios participar en decisiones de gasto. El titular de la direcci´on puede administrar los activos (cantidad de la moneda) adquiridos por transacciones ya que s´olo ´el es conocedor de la clave privada asociada a la direcci´on. No podr´a iniciarse una transacci´on sin la direcci´on del destinatario y un c´odigo de verificaci´on de errores junto a la direcci´on (para evitar errores ortogr´aficos en la misma). 3.3.2. Transacci´on Una transacci´on es una trasferencia de activos entre direcciones. La tecnolog´ıa Bitcoin permite realizar transacciones de m´ultiples direcciones a m´ultiples direcciones, aunque en la pr´actica las direcciones de entrada suelen pertenecer al mismo usuario y las direcciones de salida a diferentes usuarios. Para cada transacci´on es imprescindible aportar tres datos: el o los ID de las transacciones anteriores que realiz´o la direcci´on o direcciones de entrada, el ´ındice de salida de la transacci´on previa y la cantidad a transferir. De esta forma, se firma la transferencia evitando que se altere la transacci´on, quedando reflejada la autorizaci´on del usuario para que la misma se lleve a cabo. 8 Cuando una transacci´on env´ıa activos a una direcci´on, la red desconoce la clave p´ublica de la direcci´on del receptor, s´olo se muestra cuando los activos recibidos se gastan en otra transacci´on. Conociendo su clave p´ublica cualquier usuario de la red podr´a hacer un hash de la misma para verificar que es igual al hash de la direcci´on, comprobando as´ı la legitimidad de sus transacciones. En la figura 3.3 podemos ver cuatro tipos de transacciones diferentes. Cada uno de los n´umeros naranjas representan transacciones, los rect´angulos verdes representan un Satoshi que es la unidad m´ınima de un Bitcoin (1 Bitcoin = 108Satoshi) y los c´ırculos representan los nodos de direcci´on. En la transacci´on 1 nos muestra una transacci´on 1/1 puesto que tiene una direcci´on de entrada y una direcci´on de salida. La transacci´on 2 es de tipo 2/2, la 3 es de tipo 1/2 y la 4 es de tipo 2/1. Cuando hay m´as de una entrada, realmente no se distingue de qu´e direcci´on viene qu´e cantidad del activo, por ejemplo en la transacci´on 2 no podemos saber si la cantidad de a6viene de a2o de a3. Figura 3.3: Tipos de transacciones En la pr´actica, no se indica una tarifa de transacci´on como tal, este monto se calcula como la resta entre la cantidad total enviada por todos los usuarios en dicha transacci´on y la cantidad total que se retira de esa misma transacci´on. La tasa se env´ıa a la direcci´on del minero que confirma la transacci´on (por ejemplo, en la figura 3.3 en la transacci´on 3, el rect´angulo naranja ser´ıa la tasa que se le paga al minero). Tambi´en puede darse el caso de realizar transacciones sin cargo, pero conforme mayor sea la tasa, m´as probable es que la transacci´on se confirme al ser m´as atractiva para los mineros que las elijen. Una direcci´on puede recibir transferencias de m´ultiples transacciones y los resultados de esta pueden gastarse por separado. Pero la comunidad de Bitcoins tiene establecida la regla de gastar todos los activos en una sola transacci´on. Por ejemplo, en la figura 3.3, la direcci´on a3gasta 1 Satoshi en cada transacci´on y esto es posible porque cada uno ven´ıa de una transacci´on diferente. En cambio, si nos fijamos en a5, recibe 2 Satoshi de la transacci´on 2, pero tiene que gastarlos en la transacci´on 3. Si s´olo env´ıa 1 Satoshi, la cantidad no gastada ser´a para el minero. En la pr´actica, si un usuario tiene que gastar una fracci´on del monto recibido, env´ıa el saldo restante a otra direcci´on suya, o bien crea una direcci´on nueva a la que env´ıa el dinero. 3.3.3. Verificaci´on y confirmaci´on Cuando hablamos de verificar el pago nos referimos a crear un mecanismo que confirme que la direcci´on emisora tiene saldo suficiente para realizar el pago y tambi´en corrobore que el due˜no de la direcci´on quiere gastar la cantidad indicada. Para ello, 9 el usuario presenta su clave p´ublica (demostrando as´ı que la direcci´on le pertenece) y firma con su clave privada que quiere transferir dicha cantidad. La transacci´on tambi´en almacena como entrada el n´umero de la transacci´on anterior de donde viene la cantidad (por ejemplo, en la figura 3.3), la transacci´on 8 almacena que su entrada proviene de la transacci´on 6. En el caso ideal, tan pronto como se gasta una cantidad de la moneda, todos ver´ıan la transacci´on y registrar´ıan los nuevos saldos. Si no fuera as´ı, el emisor de la transacci´on podr´ıa gastar unos mismos Bitcoins para m´ultiples transacciones (conocido como problema del doble gasto). Para solucionar este problema, Nakamoto propuso utilizar un libro contable p´ublico y distribuido que contuviera bloques con identificadores y marca de tiempo as´ı como las transacciones verificadas. Cada bloque lleva un hash sobre el bloque anterior, para facilitar el seguimiento de la cadena de bloques en el tiempo. Los bloques tienen algunas limitaciones como en el caso de las transferencias muy grandes ya que podr´ıan llegar a obstruir la red. Es por eso que en Bitcoin, el tama˜no de bloque est´a limitado a 1 MB. La creaci´on de bloques est´a limitada a un bloque cada diez minutos a trav´es del mecanismo antes explicado de Proof-of-Work. Esto se debe a que es muy dif´ıcil de crear cada bloque, pero f´acil de firmar una vez creado. Esta prueba de trabajo requiere encontrar un n´umero de 32 bits conocido como nonce mediante prueba y error. La dificultad se va regulando en funci´on del n´umero de mineros y la capacidad de los mismos de encontrar el valor del nonce correcto. Los usuarios que trabajan para encontrar bloques confirmados se denominan mineros. El minero recibe una lista de transacciones verificadas y las incluye en el bloque. Normalmente, se habr´an verificado aquellas cuya tasa sea mayor. Primero, se concatenan unos datos concretos de cada bloque, como el hash del bloque anterior y un hash correspondiente a cada una de las transacciones que pertenecen a este bloque. La prueba consiste en encontrar este n´umero nonce de tal forma que si hacemos el hash SHA-256 del bloque, el resultado comience por un n´umero determinado de ceros o de forma equivalente que sea menor que un n´umero fijado llamado hash target, entonces, se podr´a decir que se ha minado el bloque. Figura 3.4: Estructura de Blockchain Una vez se mina un bloque B, el minero lo env´ıa a sus vecinos en la red y espera a que se incluya el bloque a la cadena. Conforme la informaci´on de B se propaga en la red, los usuarios actualizan sus cadenas, y a˜naden a B como el ´ultimo bloque. En este punto, el resto de mineros deber´an detener sus c´alculos, cambiar el hash del bloque anterior con el de B y reanudar la miner´ıa. 10 Una vez entendido el funcionamiento de Blockchain, podemos plantearnos la siguiente pregunta. Si en el bloque necesitamos el hash del bloque anterior, ¿c´omo es el primer bloque de la cadena? Pues bien, este bloque se conoce como bloque G´enesis y fue extra´ıdo por Nakamoto. Otra duda que puede surgirnos es, ¿puede haber bifurcaciones en la cadena de bloques? La respuesta es que s´ı, los usuarios pueden ser notificados de dos bloques alternativos que se bifurcan de un bloque anterior, y los mineros deber´an elegir un bloque sobre el que construir y continuar la cadena. Y, ¿c´omo se soluciona esto? Pues la cadena de bloques acaba eligiendo como cadena principal a la que vuelva a minar bloques m´as r´apido. Es decir, que si por una rama, se vuelve a minar un bloque antes que en la otra, esta pasar´a a ser la cadena principal. Gracias a la prueba de trabajo, los desarrolladores de Bitcoin se aseguran de que si un usuario mal intencionado crea una bifurcaci´on para reemplazar la cadena de bloques principal deber´a extraer nuevos bloques m´as r´apido que todos los dem´as mineros de la red. Existe un tipo de ataques llamados ataques de eclipse, en el que a un usuario se le notifica una bifurcaci´on diferente a la de la cadena principal con fines de estafarle. Figura 3.5: Ataques de eclipse Pese a que las transacciones est´an protegidas por los mecanismos anteriormente explicados, hay usuarios maliciosos que han encontrado m´ultiples formas de estafar wallets y a usuarios. Aunque las transacciones son inmutables, los identificadores de las transacciones no lo son, por lo que se podr´ıan modificar. De forma que si un usuario abre un wallet, compra Bitcoins y los env´ıa a una direcci´on, tan pronto como la transacci´on se publica, el propio usuario podr´ıa modificar la identificaci´on y enviarla de nuevo a la red, y por tanto habr´ıa dos copias de esta transacci´on. Gracias a la estructura de la red, no deberemos preocuparnos por esto, puesto que al estar duplicada, los mineros rechazar´ıan la segunda transacci´on, ya que esos Bitcoins ya se han gastado. Adem´as de las tasas de transacci´on, Bitcoin crea una recompensa minera por cada bloque minado, esto se conoce como transacci´on de base de monedas y suele ser 11 la primera transacci´on en un bloque. Un ´ultimo aspecto que debe quedar bien claro, es que aunque una transacci´on se haya a˜nadido a un bloque, no es definitiva hasta que el bloque se haya minado y se confirme que este pertenece a la rama principal. Ya que puede ocurrir que el bloque se mine, pero el bloque quede hu´erfano porque se haya producido una bifurcaci´on y no se siga por la rama a la que pertenece. Es por ello que se recomienda esperar a que se hayan minado al menos 5 bloques despu´es de este dentro de la misma rama, para confirmar que la transacci´on se ha completado correctamente. 3.4. Ejemplo Para la mejor comprensi´on de c´omo funciona Blockchain, a continuaci´on presentaremos un ejemplo de forma que dicho funcionamiento quede claro. Vamos a suponer que tenemos un bloque al que le vamos a poner un´ındice n−1, un bloque ny finalmente un bloque n+ 1. Figura 3.6: Ejemplo de Blockchain. Imagen extra´ıda de [9]. Cada uno de estos bloques contiene sus transacciones verificadas (las cuales tienen cada una su ID que corresponde con el hash generado a partir de los inputs, outputs y cantidad de la moneda transferida de esa transacci´on), el nonce correspondiente al bloque una vez se haya minado y el hash del bloque anterior. Si observamos el bloque n, podemos ver que est´a formado por: el hash del bloque n−1, el conjunto de transacciones verificadas y el nonce de dicho bloque que en este caso es el n´umero 42. Si nos fijamos en el nonce del bloque n−1 es el 23 ya que si ciframos las transacciones de este bloque, junto con el resto de cabeceras, obtendremos un hash con 7 ceros ya que esta es la cantidad de ceros estipulada en este caso (00000003bcff293...). Este n´umero es el que hace que al cifrarlo todo mediante SHA-256, el hash de este (el bloque n), empiece por una cantidad concreta de ceros. De esta forma, si alg´un usuario mal intencionado quisiera modificar alguno de los bloques, por ejemplo, en este caso, el bloque n−1, el hash de los bloques nyn+1 ser´ıa totalmente diferente. Este tipo de ataque se llama Sybil Atack, y gracias a la prueba de esfuerzo, evitamos que pueda llegar a ser fruct´ıfero ya que el atacante necesitar´ıa 12 minar el bloque modificado y todos los siguientes a una velocidad mucho mayor que el resto de usuarios de la red de Blockchain, cosa que es pr´acticamente imposible. Figura 3.7: Ejemplo de Sybil Atack 3.5. Conclusi´on De esta secci´on podemos concluir que cada transacci´on tiene unos nodos de entrada (inputs) y unos nodos de salida (outputs). Adem´as, debe tenerse en cuenta que los inputs en realidad son nodos de salida de una transacci´on anterior. De esta forma, a la hora de verificar que el emisor de la transacci´on disponga de saldo suficiente, lo ´unico que tendr´a que hacer es comprobar las transacciones anteriores. Otro aspecto importante a tener en cuenta, es que aunque una transacci´on se haya a˜nadido a un bloque, no es definitiva hasta que se confirme que este bloque pertenece a la rama principal. Ya que puede ocurrir que el bloque se mine, pero quede hu´erfano porque se haya producido una bifurcaci´on y este bloque no pertenezca a la rama principal. Es por ello que se recomienda esperar a que se hayan minado al menos 5 bloques despu´es de este dentro de la misma rama, para confirmar que la transacci´on se ha completado correctamente. Un bloque est´a formado por el hash del bloque anterior, el conjunto de sus transacciones y un n´umero llamado nonce. Este n´umero es el resultado de una prueba de trabajo o Proof-of-Work que se deber´a llevar a cabo para minar el bloque. El minero habr´a minado el bloque cuando por fuerza bruta, es decir, probando, haya encontrado el n´umero nonce, tal que al obtener el hash (con codificaci´on SHA-256) este empiece por una cantidad determinada de ceros. Dicha prueba de trabajo se pide para que la red distribuida funcione correctamente y de forma segura. Una vez el minero haya minado el bloque, esta informaci´on se enviar´a al resto de usuarios de la red, para que est´en actualizados y si estaban tratando de minar el bloque, paren y comiencen con el siguiente. 13 4. Graph chainlets En este cap´ıtulo hablaremos sobre el art´ıculo Forecasting Bitcoin Price with Graph Chainlets [1], c´omo se modela en forma de grafo la blockchain de Bitcoin y qu´e son, c´omo se definen y para qu´e sirven los chainlets. 4.1. Introducci´on a los chainlets La criptomoneda Bitcoin ha provocado un gran inter´es gracias a su tecnolog´ıa de blockchain, esto se debe a que es bastante interesante el hecho de que todos los participantes tienen un libro contable, en el que pueden verificar todas las transacciones que se realizan con Bitcoin. Gracias a este libro contable distribuido tendremos la oportunidad de analizar el grafo de transacciones. Adem´as, este grafo puede utilizarse para otros ´ambitos, por ejemplo, estudiar si la estructura del grafo afecta al precio de una divisa como Bitcoin o cualquier otra. Por lo tanto, observando los subgrafos que se repiten con m´as o menos frecuencia de lo esperado, podemos saber la importancia que tienen dentro del grafo de transacciones. Tanto la b´usqueda de estos patrones como el estudio de los mismos en las redes financieras como la de Bitcoin, est´an a´un en proceso. Por ello, en los siguientes puntos se desarrollar´an t´ecnicas para entender correctamente c´omo se forma el grafo de transacciones, as´ı como, qu´e son los chainlet y su impacto en la predicci´on de precios. 4.2. Aplicaciones del estudio de Blockchain mediante chainlets Desde 2008 Bitcoin ha sido la aplicaci´on m´as directa, destacada y estudiada de Blockchain. Los primeros estudios estaban enfocados en analizar el grafo de transacciones en b´usqueda de actividades ilegales como el blanqueamiento de dinero o el chantaje con las diferentes monedas que hay. En otras ocasiones la red de Bitcoin tambi´en ha sido estudiada con otros prop´ositos. Por ejemplo, en 2016 tras el an´alisis de las centralidades en el art´ıculo Exploring the Bitcoin Network [7], los autores del art´ıculo Analyzing the Bitcoin Network: The First Four Years [17] descubrieron que en ese a˜no esta red pod´ıa considerarse una red sin escala, es decir, que un grupo de nodos est´an involucrados en un gran n´umero de transacciones, mientras que la gran mayor´ıa apenas lo est´an. Estos an´alisis se centraban en las caracter´ısticas globales del grafo, pero el an´alisis que se plantea en este art´ıculo pretende entender las estructuras topol´ogicas de Bitcoin y su papel en la determinaci´on de los precios de las monedas. 14 En general, los estudios m´as recientes muestran la utilidad de analizar el grafo de transacciones en b´usqueda de caracter´ısticas que ayuden a la predicci´on de precios. A veces, se analiza el coeficiente de agrupamiento (midiendo los nodos que tienden a crear grupos muy unidos caracterizados por una densidad relativamente alta de v´ınculos) y saldo promedio. Por otro lado, los chainlets ayudan a la puntualizaci´on de las caracter´ısticas globales antes mencionadas, calcul´andolas s´olo en ciertos subgrafos. 4.3. Metodolog´ıa En este art´ıculo [1], el grafo de Bitcoin tiene tres componentes principales: direcciones, transacciones y bloques. En la siguiente figura podemos observar la representaci´on de una red de este tipo para 4 transacciones y en las que se ven involucradas 13 direcciones. Figura 4.1: Representaci´on gr´afica de transacciones de la red Bitcoin En dicha representaci´on gr´afica, las direcciones est´an representadas por c´ırculos, las transacciones por rect´angulos y las flechas indican una transferencia de criptomonedas. Como observaci´on, a˜nadimos que las monedas en la direcci´on a6est´an sin gastar. En el art´ıculo se remarca que los datos que se manejan provienen del software oficial de Bitcoin (instalaron la wallet central de Bitcoin y esta descarg´o todo el historial de Bitcoin desde 2009 hasta 2018). Tras la obtenci´on de los datos analizaron la blockchain de Bitcoin y extrajeron los bloques, transacciones y direcciones. El grafo queda modelado como una red heterog´enea con dos tipos de nodos: transacciones y direcciones. Gracias a esto, podremos ver la red de Bitcoin representada como un grafo dirigido G= (V, E, B) donde Ves el conjunto de v´ertices, E⊆V×Ves el conjunto de aristas y B={direcci´on, transacci´on}que hace referencia al conjunto de los tipos de v´ertices. Para cada v´ertice u∈V, existe un tipo de v´ertice perteneciente a B, y se verifica que para cada par de v´ertices uyv, conectados por una arista e∈Eel tipo de v´ertice de u, siempre ser´a diferente al de v. Cada arista e∈E, representa una transacci´on de la moneda entre un nodo de direcci´on y un nodo de transacci´on. En este modelado de grafo, todas las transacciones tienen el mismo peso, eso quiere decir, que todos los tipos de nodos valen lo mismo (∥B∥= 1) y por lo tanto, no se tiene en cuenta la cantidad de moneda que se est´a transfiriendo. Este art´ıculo se centra en el caso en 15 el que cada nodo de direcci´on est´a vinculado a trav´es de un nodo de transacci´on a otro nodo de direcci´on. Existen tres reglas que dan forma al grafo de Bitcoin y son las siguientes: En una sola transacci´on pueden entrar monedas de dos direcciones diferentes (como en la transacci´on t4de la figura 4.1) En una transacci´on no se registra detalladamente las entradas y salidas, por ejemplo, en la salida en direcci´on a6puede venir de a1o de a2. Las monedas de transacciones con varias direcciones de entrada se pueden gastar por separado, pero las que salen de una transacci´on deben gastarse en una sola (podemos fusionar a1ya2, pero no podemos gastar a7en transacciones diferentes o transferir parte de las monedas que acaba de recibir y quedarse con el resto). Una peque˜na observaci´on, es que se desaconseja reutilizar nodos de direcci´on, ya que es f´acil y gratuitamente pueden crear nuevas pero a´un as´ı hay usuarios que las reutilizan. Los bloques aparecen por orden temporal, y cada transacci´on (incluyendo sus nodos de entrada y salida) queda representada por un subgrafo en la red de bitcoin, al que a partir de ahora nos referiremos como chainlet. 4.3.1. Graph Chainlets Los k-chainlets son estructuras que se utilizan para evaluar la estructura topol´ogica del grafo de Bitcoin (khace referencia al n´umero de nodos de transacci´on que van a estar incluidos en el chainlet, en este caso la kdentr´a como valor 1). Denotaremos las cadenas como Cx→ysiendo xel n´umero de entradas e yel n´umero de salidas. En el caso particular en el que tenemos un n´umero mayor de entradas que de salidas (es decir, x > y) lo llamaremos merge chainlets. Los otros dos casos que se pueden dar son que el n´umero de entradas sea igual al n´umero de salidas (x=y), llamado transition chainlets y por ´ultimo si el n´umero de entradas es menor que el n´umero de salidas (x<y) se llama split chainlets. Nos referiremos a estos tipos de chainlets como agregate chainlets a partir de ahora. Podemos ver en la siguiente figura unos ejemplos. Figura 4.2: Tipos de chainlets. Merge (C3→1), Transition (C3→3), Split (C3→4). 16 Figura 5.5: Ejemplo de Lower-Star: Primera componente conexa Figura 5.6: Ejemplo de Lower-Star: Dos primeras componentes conexas 23 Figura 5.7: Ejemplo de Lower-Star: Una sola componente conexa A partir de esta altura, por mucho que subamos en el eje z, tendremos una sola componente conexa, por lo que ya s´olo quedar´a viva una barra en el diagrama de persistencia representado en la figura 5.8. Figura 5.8: Barcode del ejemplo Gracias a esta filtraci´on, podremos obtener informaci´on sobre la entrop´ıa de los datos m´as bajos en el eje z. Aplicado al contexto de las matrices de ocurrencia de Bitcoin, esto nos permitir´a detectar los tipos de transacciones que menos se repiten en relaci´on a sus similares. 24 5.6. Filtraci´on Upper-Star Tras aplicar la filtraci´on Lower-Star, empezamos a pensar en que al igual que quer´ıamos informaci´on sobre la entrop´ıa en los puntos m´as bajos de cada matriz, no quer´ıamos perder informaci´on sobre los m´aximos/picos de cada una de ellas. Es por esto, que pensamos en cambiarle el signo a cada elemento de la matriz, de tal forma que esta vez los m´aximos, ser´ıan los elementos m´as cercanos al eje y por tanto de los que obtendr´ıamos informaci´on. Gracias a esto, las barras de persistencia se van a obtener en funci´on de los picos m´as altos (antes de cambiarle el signo a los elementos de la matriz). Para verlo m´as claramente, se continuar´a con el ejemplo anterior. En el siguiente gr´afico, se representan los elementos de la matriz una vez ya se les ha cambiado el signo (figura 5.9). Figura 5.9: Ejemplo de filtraci´on Lower-Star con la matriz cambiada de signo (que se corresponde con al filtraci´on Upper-Star). Esta vez, al ir haciendo cortes y observando las diferentes componentes conexas, lo primero con lo que nos toparemos ser´a con los puntos que antes eran m´as altos, en este caso, empezar´ıamos por el punto B (figura 5.10). Figura 5.10: Primera componente conexa con Upper-Star Continuando con los cortes que se realizan, obtendr´ıamos una segunda componente conexa formada por los puntos K, N, O, P, D(representada en naranja en la figura 5.11). 25 Figura 5.11: Segunda componente conexa con Upper-Star Tras realizar este tercer corte ya obtendr´ıamos una sola componente conexa, que permanecer´a en el tiempo, puesto que por mucho que se vaya subiendo, s´olo se a˜nadir´an nuevos puntos a la misma componente (figura 5.12). Figura 5.12: Una sola componente conexa con Upper-Star Gracias a esta filtraci´on podremos obtener informaci´on sobre lo heterog´eneos que son los puntos m´as altos, qued´andonos las barras representadas en la figura 5.13. Figura 5.13: Barcode Upper-Star Esto nos permitir´a estudiar los m´aximos de los que no recog´ıamos informaci´on mediante Lower-Star y ver c´omo de diferentes son esos puntos en relaci´on a sus vecinos de la malla. 26 6. Herramientas de programaci´on y librer´ıas utilizadas 6.1. Introducci´on En este cap´ıtulo se explicar´an las diferentes herramientas que se han utilizado en el proyecto y se detallar´a c´omo deben instalarse para mayor facilidad de uso de cara a futuras personas que vayan a hacer uso de este proyecto. 6.2. Python En este proyecto utilizaremos Python, un lenguaje de programaci´on de alto nivel, muy utilizado en diversos aspectos como desarrollo web, ciencia de datos, inteligencia artificial y mucho m´as. Para esta ocasi´on se ha utilizado la ´ultima versi´on disponible de Python, la 3.11 que puede descargarse desde la p´agina oficial de la que deberemos descargarnos la ver- si´on ejecutable seg´un las caracter´ısticas de nuestro equipo. Y simplemente seguiremos la instalaci´on con las opciones por defecto, teniendo en cuenta que debemos marcar la opci´on “Add python.exe to PATH” en la primera p´agina del instalador. 6.3. Anaconda Anaconda es una distribuci´on de Python que incluye una serie de paquetes realmente ´utiles para poder trabajar con datos, adem´as de incluir Jupyter Notebook, herramienta que nos permitir´a trabajar de forma m´as c´omoda. Lo instalaremos desde su web oficial, de acuerdo a la versi´on de Python que hayamos descargado. En este caso la instalaci´on ser´a sencilla, simplemente seguiremos la instalaci´on con las instrucciones por defecto. 6.4. Ripser, Scikit-tda y Persim Para el c´alculo de la homolog´ıa persistente y entrop´ıa persistente se necesita instalar las biblioteca de Python Ripser [20] y scikit-tda [19]. Tambi´en necesitaremos la biblioteca Persim, puesto que es una dependencia de Ripser. Para usarlas s´olo deberemos importar estas bibliotecas en nuestro proyecto una vez las hayamos instalado. La instalaci´on es muy simple, s´olo deberemos introducir los siguientes comandos en la consola de nuestro ordenador: pip install Cython pip install Ripser pip install scikit-tda 27 7. Extracci´on de los datos 7.1. Introducci´on Tras intentar ejecutar el c´odigo del trabajo predecesor de Fernando Claros [6] sin ´exito (por problemas en la instalaci´on de dependencias), contact´e con el autor de los art´ıculos sobre los que se basa este trabajo, Cuneyt Gurcan Akcora, puesto que tiene varios proyectos en GitHub en el que se descarga los datos de bitcoin y forma un grafo con ellos. Al presentarle nuestro proyecto y preguntarle que cu´al de ellos ser´ıa mejor utilizar, Akcora nos aconsej´o leernos los apartados del 3 al 3.5 del art´ıculo Blockchain networks: Data structures of Bitcoin, Monero, Zcash, Ethereum, Ripple, and Iota [10] por lo que vamos a proceder a continuaci´on a explicar dichos puntos del mismo. Finalmente los datos del repositorio antes comentado se han usado en este proyecto pero de forma indirecta, ya que descubrimos que en el repositorio principal del proyecto de Akcora [11] ya estaban implementadas las matrices de ocurrencia de los chainlets, y por tanto decidimos directamente trabajar con ellas, evitando as´ı tener que tratar el gran volumen de datos que supon´ıa, adem´as de requerir recursos que no disponemos (por potencia computacional). Igualmente, en este cap´ıtulo se proceder´a a explicar la estructura de estos datos dentro del repositorio, tras hablar sobre el art´ıculo aconsejado por el matem´atico. 7.2. Blockchain networks: Data structures of Bitcoin, Monero, Zcash, Ethereum, Ripple, and Iota En esta secci´on hablaremos sobre el art´ıculo recomendado por Akcora [10] centr´andonos en Bitcoin puesto que es la parte que m´as nos interesa del que finalmente s´olo utilizaremos los puntos 3 y 3.1 puesto que los puntos 3.2 y 3.3 eran modelos de grafos diferentes al que se pensaba usar en este trabajo (grafo de transacciones en el que no aparecen las direcciones y grafo de direcciones en el que no aparecen las transacciones). En el apartado 3.4 de [10], Akcora habla sobre monedas que no son Bitcoin y en el 3.5 explica los Chainlets, algo que ya hemos tratado en puntos anteriores. Para empezar, debemos entender que Bitcoin almacena los datos de bloques secuenciales en archivos blk*.dat. Cada uno de estos archivos contiene un n´umero diferente de bloques (puesto que el n´umero y tama˜no de las transacciones determinan en tama˜no del bloque). Para poder separar los diferentes bloques que se encuentren dentro de este, se a˜nade un byte m´agico en estos archivos, en el caso de Bitcoin se utiliza 0xD9B4BEF9. Como hemos comentado anteriormente a lo largo de este trabajo, cada bloque contiene un conjunto de transacciones, por las que los verificadores pueden o no llevarse una comisi´on, seg´un decidan los participantes de las transacciones. Adem´as de esta 28 comisi´on, el minero se lleva una recompensa por haber minado el bloque, pero, ¿de d´onde viene esta recompensa? Pues bien, al principio de cada bloque existe una transacci´on de base, aparte de las que se verifiquen de ese bloque, gracias a la cual, el minero recibir´a la recompensa por haber minado el bloque. Asimismo, si el minero intentara registrar una recompensa mayor a la establecida, la red rechazar´ıa el bloque autom´aticamente. Otro aspecto bastante peculiar sobre esta criptomoneda del que se habla en el art´ıculo [10], es que con estas transacciones, no podremos saber de forma directa la direcci´on del input de estas ni la cantidad que realmente se est´a gastando, sino que la ´unica informaci´on que tendremos es que tenemos como input el ´ındice de salida ide la transacci´on xtal y como puede verse en la siguiente figura 7.1 : Figura 7.1: Ilustraci´on sobre transacciones con Bitcoin. Tambi´en podemos observar que sabiendo que el output con ´ındice 0 de la transacci´on t1es 1B de satoshis, hay una diferencia de 5M de satoshis si sumamos la cantidad transferida a los outputs. Esto se debe a que, tal y como habl´abamos en el cap´ıtulo 4, los integrantes de una transacci´on deciden dar o no cierta cantidad de la moneda como concepto de tarifa de transacci´on. Normalmente, a mayor tarifa de transacci´on, mayor probabilidad tendr´a la misma de ser elegida para ser incluida en el bloque y verificada. En caso de que el minero modificara la transacci´on para tener una tarifa mayor, o se equivocara a la hora de seleccionar la direcci´on del input, la red rechazar´ıa el bloque. 7.2.1. Graph rules for UTXO Blockchains Una vez las transacciones realizadas quedan registradas en la Blockchain, se llevan a cabo de forma efectiva las transferencias de dinero. Una vez recibido el dinero, ya podremos gastarlo en otra transacci´on si disponemos de la clave privada correspondiente a la direcci´on desde la que vamos a enviarlo. En este proceso no encontramos con el t´ermino UTXO (Unspent Transaction Output), en espa˜nol significa Salida de Transacci´on no gastada. Este t´ermino, hace referencia a la salida de una transacci´on que a´un no ha sido gastada. Son estas direcciones las que nos permitir´an rastrear la cantidad de cada una de las direcciones que aparecen en la Blockchain. Esta mantiene un registro de direcciones, de tal forma que podremos asegurar la integridad de la red, verificando la validez de las transacciones. 29 Por ´ultimo, en [10], los autores nos presentan varias reglas sobre la red de Bitcoin que ya se han visto anteriormente 4, pero cabe destacar una de ellas. Una pr´actica recomendada por la red es esperar seis bloques minados tras recibir una cantidad de la moneda antes de gastarla (por las bifurcaciones que puedan producirse, tal y como se coment´o en el cap´ıtulo 3). Sin embargo, se observan casos en los que el output recibido se gasta incluso dentro del mismo bloque. 7.3. Bitcoin Transaction Network Una vez comentadas algunas peculiaridades m´as sobre Bitcoin, se explicar´a c´omo est´an estructurados los datos en el repositorio recomendado por este1.Gracias a dicho repositorio, es posible descargar los datos de las transacciones de los bloques 0 al bloque 737900, contenidos en un fichero .zip en el que se encuentran los datos por tramos de 73600 en 73600 bloques (hasta llegar al bloque 737900). Estos datos, est´an almacenados en dos tipos de archivos, los de input y los de output, es decir, unos tendr´an la informaci´on de las entradas de cada transacci´on, y otros tendr´an informaci´on sobre las salidas de cada transacci´on. Adem´as, en los ejemplos podremos darnos cuenta de una peque˜na particularidad, y es que la unidad monetaria en la que vienen representados los datos en Bitcoin es en Satoshis. 7.3.1. Archivos de input o entrada Los archivos de input nos permitir´an ver la informaci´on sobre las entradas de las transacciones con bitcoin que se realicen en un bloque determinado. En el conjunto de datos que ponen a nuestra disposici´on, los datos estar´an ya parseados gracias a la librer´ıa Bitcoin-ETL de Google [15] y quedan a nuestra disposici´on con la estructura que se presenta a continuaci´on: Nºde bloque Hash de la transacci´on Nºde inputs Part. i(direcci´on) Cantidad de iPart. i+ 1 (direcci´on) Cantidad de i+ 1 ... Cuadro 7.1: Tabla de formato de datos de bitcoin en cada bloque en los archivos input. En la tabla 7.2 podemos ver un ejemplo de c´omo aparecen los datos en estos archivos suponiendo que quisi´eramos modelar las transacciones que aparecen en la figura 4.1: BlockHeightOft1 HashOft1 2 a11∗108a21∗108 BlockHeightOft2 HashOft2 3 a32∗108a41∗108a51∗108 BlockHeightOft3 HashOft3 1 a70,8∗108 BlockHeightOft4 HashOft4 2 a11 0,3∗108a83,8∗108 Cuadro 7.2: Tabla de ejemplo de datos en archivos de input. 1Bitcoin Transaction Network Files https://chartalist.org/BitcoinData.html 30 7.3.2. Archivos de output o salida Estos archivos nos dar´an informaci´on sobre las salidas de las transacciones del bloque que hayamos elegido. Aqu´ı cabe destacar que puede darse el caso de que las direcciones de salida de una transacci´on, no sigan el est´andar por la librer´ıa que los parsea, y que aparecer´an con una estructura parecida a la siguiente: nonstandard98a1069f93253f2dcf24e989c69c53447fa0870c. Al igual que con los datos de entrada, los datos de salida tienen un formato espec´ıfico para que podamos tratarlos (podemos observarlo en la tabla 7.3). Nºde bloque Hash de la transacci´on Nºde outputs Part. i(direcci´on) Cant. que recibe iPart. i+ 1 (direcci´on) Cant. que recibe i+ 1 ... Cuadro 7.3: Tabla de formato de datos de bitcoin en cada bloque en los archivos output. Seguidamente, podemos ver a continuaci´on del ejemplo anterior, pero esta vez con los datos de salida. BlockHeightOft1 HashOft1 2 a6108a70,8∗108 BlockHeightOft2 HashOft2 1 a83,8∗108 BlockHeightOft3 HashOft3 3 a90,2∗108a10 0,2∗108a11 0,3∗108 BlockHeightOft4 HashOft4 2 a12 3,7∗108a13 0,3∗108 Cuadro 7.4: Tabla de ejemplo de datos en archivos de output. 31 8. Implementaci´on Aunque al comienzo de esta etapa del proyecto pretend´ıamos formar el grafo de transacciones, tras no conseguir utilizar el c´odigo del repositorio [11] de Akcora, nos decantamos por utilizar las matrices de ocurrencia por d´ıas que se encuentran ya en dicho repositorio formadas a partir de los datos explicados en el cap´ıtulo anterior. En este cap´ıtulo explicaremos c´omo est´an construidos los datos a partir de los cuales Akcora ha creado las matrices de ocurrencia con las que se van a trabajar, as´ı como el tratamiento que se le ha dado a las mismas en este proyecto y los experimentos que se han llevado a cabo. 8.1. Estructura del repositorio de Akcora El repositorio de Akcora Coinworks [11] es de donde se han obtenido los datos que se van a utilizar en este proyecto. El repositorio se divide en dos partes principales. En la primera parte se procesan ficheros con los datos de Bitcoin desde 2009 hasta 2018. Una vez procesados, Akcora pudo extraer ficheros con datos procesables m´as ´utiles, como por ejemplo, dos ficheros .rar. En el primero, podremos observar matrices de 20x20 que reflejan las ocurrencias de los chainlets(son con las que vamos a trabajar), y en el segundo, ficheros con matrices del mismo tama˜no en el que podremos observar la cantidad de la moneda que se mueve en los diferentes tipos de chainlets. La segunda parte de este proyecto, adem´as de procesar los datos, Akcora clasifica los datos de las transacciones por a˜nos y meses, y cada a˜no estar´a asociado con 12 archivos en relaci´on a las entradas de las transacciones y 12 archivos relacionados con las salidas de las transacciones (uno por cada mes del a˜no). 8.2. Matriz de ocurrencia Como se comenta en el apartado anterior, en el repositorio de Akcora [11], si nos dirigimos al apartado de “data” y dentro de este al archivo de “dailyOccmatrices2009- 2018.rar”, encontraremos las matrices de ocurrencia, cuya estructura est´a explicada en el cap´ıtulo 4. En este apartado aclararemos con un ejemplo real las partes de esta matriz. Gracias al estudio de las mismas, podremos realizar observaciones como el tipo de chainlets que m´as se repite (por ejemplo, en el caso de la figura 8.1, el que m´as se repite es C1→2). Otra cosa que tambi´en puede llamarnos la atenci´on, es que algunos de los elementos de la ´ultima fila y la ´ultima columna sean tan altos. Pero como explic´abamos en el cap´ıtulo 4, la ´ultima fila y la ´ultima columna representan el resto de chainlets que no caben en la muestra, es decir, representan la suma de todos los chainlets que se desbordan de la matriz. 32 Figura 8.5: Matriz de entrop´ıa m´ınima mediante Vietoris-Rips Segundo experimento Al no observar cambios significativos entre las matrices con entrop´ıa m´axima y m´ınima en Vietoris-Rips, nos dimos cuenta de que la matriz correspondiente a la entrop´ıa m´as baja ten´ıa barras muy largas y peque˜nas, lo que hac´ıa que la entrop´ıa resultara peque˜na tambi´en. Es por esto que decidimos realizar los mismos experimentos, pero normalizando la matriz con valores entre 0 y 1 para que las anomal´ıas fueran m´as evidentes. Para ello simplemente hemos tenido que normalizar cada matriz antes de pasarla a cada una de las filtraciones. Esto se ha hecho gracias a la siguiente funci´on: def normalizar ( matr ): maxim , minim = matr . max() , matr . min() res = [] for iin range (20): fila = [] for jin range (20): 39 elem = matr[i, j] nuevo_elem = (( elem - minim ) /( maxim - minim )) fila . append ( nuevo_elem ) res . append ( fila ) return np. array ( res) Extracto de c´odigo 8.8: Normalizaci´on de matrices Esta es muy similar a la que utilizamos para normalizar las matrices y poder representarlas mediante im´agenes, s´olo que no har´a falta que multipliquemos por 255. e=em −minim maxim −minim Gracias a esta normalizaci´on, hemos obtenido la gr´afica de la figura 8.6. Figura 8.6: Gr´afica de entrop´ıa con Vietoris-Rips con las matrices normalizadas Como puede observarse en las figuras 8.6,8.7,8.8 y8.9 mediante este experimento todas las entrop´ıas tienen unos valores muy cercanos al 5,9888, la raz´on se explicar´a en el siguiente cap´ıtulo. Figura 8.7: Valores de entrop´ıa m´axima y m´ınima con Vietoris-Rips normalizando la matriz 40 Figura 8.8: Matriz de entrop´ıa m´axima con Vietoris-Rips normalizando la matriz 41 Figura 8.9: Matriz de entrop´ıa m´ınima con Vietoris-Rips normalizando la matriz Tercer experimento Esta vez decidimos replicar el segundo experimento, pero esta vez multiplicando por una constante. Podr´ıamos preguntarnos entonces, qu´e diferencia habr´ıa entre esta normalizaci´on y en la que normaliz´abamos las matrices para representarlas en im´agenes a escala de grises. Pues bien, la diferencia es que en este caso no se van a perder los decimales, es decir, que no s´olo tendremos n´umeros enteros a la hora de calcular la homolog´ıa y entrop´ıa persistentes. Para poder llevar a cabo este experimento, simplemente hemos utilizado una funci´on similar a la anteriormente presentada “normalizar”pero multiplicando cada elemento por 1000. Gracias a este experimento hemos podido encontrar una diferencia m´as clara entre las matrices con mayor y menor entrop´ıa. Podremos observar estas matrices as´ı como sus entrop´ıas en las figuras 8.10,8.11 y8.12. 42 Figura 8.10: Gr´afica de entrop´ıa mediante el tercer experimento Figura 8.11: Matriz de entrop´ıa m´axima mediante el tercer experimento 43 Figura 8.12: Matriz de entrop´ıa m´ınima mediante el tercer experimento 8.4.2. Lower-Star En este apartado se explicar´an los diferentes experimentos que se han realizado utilizando la filtraci´on de Lower-Star. Primer experimento En el caso de los experimentos con Lower-Star, se ha tenido que realizar un peque˜no paso previo que consiste en elegir cu´antos puntos del diagrama de persistencia elegiremos para calcular la entrop´ıa. En Vietoris-Rips, no importaba el n´umero de puntos que se fueran a elegir puesto que coincide con el tama˜no de la matriz, sin embargo, Lower-Star puede crear un n´umero de barras diferentes para cada matriz (dependiendo de los cr´ateres o picos que se formen). Ya que para que la comparativa entre entrop´ıas tenga significado, ´estas deben calcularse sobre el mismo n´umero de barras Para que todas las entrop´ıas sean calculadas con la misma cantidad de barras, deberemos calcular cuantas nos quedan para cada una de las matrices, y saber cu´al es el n´umero m´as peque˜no de barras que obtenemos. Para ello, se aplica la filtraci´on Lower-Star para cada una de las matrices, buscando el m´ınimo n´umero de barras, una vez hecho esto, ya sabremos cuantas barras deberemos seleccionar de cada matriz. Seleccionaremos las barras que m´as largas (aquellas cuyo x−ysea mayor) puesto que estas barras son las que m´as informaci´on nos proporcionar´an, ya que representan componentes conexas que sobreviven m´as tiempo. Una vez hecho esto, ya podremos proceder a calcular la entrop´ıa persistente. carpeta = ’ Datos / dailyOccmatrices ’ mat2017 = [mat for mat in os . listdir ( carpeta ) if " occ2017 " in mat] dicc_entropia_lwrstar1 = {} minimo = float(’inf ’) for nombre_archivo in mat2017 : 44 if nombre_archivo . endswith ( ’. csv ’): matrix = lee_archivo_dev_matriz ( nombre_archivo ) diagrams = lower_star_img ( matrix ) if len( diagrams )<minimo : minimo=len(diagrams) minimo = minimo -1 for nombre_archivo in mat2017 : if nombre_archivo . endswith ( ’. csv ’): matrix = lee_archivo_dev_matriz ( nombre_archivo ) dgms_resultado = lower_star_img ( matrix ) dst_puntos = {} for punto in dgms_resultado: dst_puntos[tuple( punto )] = abs( punto [0] - punto [1]) puntos_mas_alejados = sorted( dst_puntos , key = dst_puntos . get , reverse = True ) [1: minimo +1] puntos_mas_alejados_para_entropia = [] for iin range (len(puntos_mas_alejados)): for jin range (len( dgms_resultado )): if puntos_mas_alejados [i ][0]== dgms_resultado [ j][0] and puntos_mas_alejados[i][1]== dgms_resultado [j ][1]: puntos_mas_alejados_para_entropia.append( dgms_resultado [j]) puntos_mas_alejados_para_entropia = np.array( puntos_mas_alejados_para_entropia) entropia = persim . persistent_entropy . persistent_entropy( puntos_mas_alejados_para_entropia , keep_inf = False , val_inf = None , normalize = False ) dicc_entropia_lwrstar1 [ nombre_archivo ] = entropia Extracto de c´odigo 8.9: C´alculo de entrop´ıa mediante Lower-Star Para ver los resultados representados, se utilizara un c´odigo similar al utilizado para representar los resultados de Vietoris-Rips. En este caso, podemos observar que la entrop´ıa se mueve en un rango mayor en comparaci´on con Vietoris-Rips. Esto se debe a que en Lower-Star, observamos sobre todo la heterogeneidad de los cr´ateres que se forman, es decir, de los puntos m´as bajos (como se observa en el ejemplo del cap´ıtulo 5). Esto hace que obtengamos un resultado diferente al obtenido gracias a la filtraci´on anterior. Para obtener las matrices correspondientes a los d´ıas de mayor y menor entrop´ıa mediante Lower-Star realizaremos los mismos pasos que con Vietoris-Rips, obteniendo los siguientes resultados: En la matriz correspondiente a la entrop´ıa m´axima se observa que hay menor cantidad de ceros que en la matriz correspondiente a la entrop´ıa m´ınima. Esta es la forma m´as clara en la que podemos verlo, pero realmente, la diferencia entre los elementos m´as bajos de la matriz ser´a mayor en la matriz cuya entrop´ıa corresponde a la m´axima. 45 Figura 8.13: Resultados de entrop´ıa mediante Lower-Star Figura 8.14: D´ıas de entrop´ıa m´axima y m´ınima mediante Lower-Star Segundo y tercer experimento Como en Vietoris-Rips, pensamos en normalizar los elementos de las matrices tal y como se realiza en el apartado anterior. Sin embargo, al observar los resultados normalizando las matrices y normalizando y multiplicando por una constante, obtuvimos los mismos resultados que en el primer experimento. 8.4.3. Upper-Star Como se comenta en el cap´ıtulo 5, ahora se proceder´a a realizar los mismos experimentos que en el apartado anterior, s´olo que esta vez, cambiaremos el signo a los elementos de cada matriz para estudiar la entrop´ıa persistente de los puntos m´aximos. Primer experimento Para este experimento, se ha utilizado el mismo c´odigo que en para Lower-Star, pero esta vez, se les pasa como par´ametro la matriz negativa, pero salvo por eso, el proceso es exactamente el mismo. Tras realizar este proceso, hemos obtenido la siguiente gr´afica en la que se representa la entrop´ıa de cada d´ıa calculada mediante Upper-Star: 46 Figura 8.15: Matriz de entrop´ıa m´axima mediante Lower-Star 47 Figura 8.16: Matriz de entrop´ıa m´ınima mediante Lower-Star Figura 8.17: Resultados de entrop´ıa mediante Upper-Star 48 o normalizar y multiplicar por una constante mediante las filtraciones Lower-Star y Upper-Star no habr´a diferencia con la entrop´ıa sin llevar a cabo este ´ultimo proceso. Aunque no sean aspectos que podamos relacionar con sucesos en la pr´actica de Bitcoin, son propiedades interesantes que ser ´utiles para trabajos futuros. Gracias a haber aplicado las filtraciones antes mencionadas en los diferentes experimentos, hemos conseguido encontrar dos resultados te´oricos novedosos. En primer lugar, hemos averiguado que al normalizar y aplicar la filtraci´on Vietoris Rips deberemos multiplicar por una constante en el proceso de normalizaci´on para que la diferencia entre las entrop´ıas de las matrices sea apreciable. Finalmente, hemos observado que al utilizar la filtraci´on Lower Star (y, por ende, Upper Star), hemos descubierto que no importa si normalizamos los datos, ya que obtenemos resultados id´enticos tanto si lo hacemos como si no. En conclusi´on, este estudio ha demostrado que la combinaci´on de la homolog´ıa persistente y entrop´ıa persistente son herramientas ´utiles para estudiar dichas matrices de ocurrencia aunque a´un no hayamos encontrado una aplicaci´on directa en la pr´actica. Este proyecto nos ha permitido cubrir una rama que hasta ahora no se hab´ıa investigado y a partir de ella han surgido otras que se comentar´an en la siguiente secci´on. Adem´as de las que se proponen, existen otras posibles investigaciones que permitir´an aplicar otras t´ecnicas topol´ogicas que nos den una visi´on diferente de las transacciones de Bitcoin. 9.2. Desv´ıos del planteamiento inicial Como bien se refleja en el cap´ıtulo 2, los objetivos en un principio fueron la creaci´on de un modelo de grafo concreto a partir de de las transacciones de Bitcoin para posteriormente buscar propiedades dentro de ´el, pero tras toparnos con la dificultad del tratamiento de los datos nos encontramos con la posibilidad de estudiar las matrices de ocurrencia de los chainlets ya formadas. Este desv´ıo ha provocado que las algunas de las tareas sean diferentes, por lo que se muestra a continuaci´on la lista de tareas que se han realizado finalmente: 1. Seguimiento y comunicaci´on con las tutoras del proyecto. 2. Lectura de los art´ıculos sobre los que basa en gran parte el proyecto. 3. Contacto con el autor principal de los art´ıculos en los que se basa el proyecto y asistencia al curso impartido por ´el. 4. Investigaci´on sobre Bitcoin, Blockchain y transacciones con criptomonedas. 5. Investigaci´on sobre c´omo obtener los datos. 6. Investigaci´on sobre las librer´ıas a usar para el tratamiento de los datos. 7. Extracci´on de los datos y comprensi´on de la estructura de los mismos 8. Investigaci´on sobre normalizaci´on de las matrices para transformarlas en im´agenes. 55 9. Investigaci´on sobre las posibles t´ecnicas de topolog´ıa a aplicar a dichas matrices y experimentaci´on con las mismas. 10. Analizar los resultados obtenidos. 11. Redacci´on de la memoria del proyecto. 12. Realizaci´on y preparaci´on de la presentaci´on del proyecto. Tarea Tarea(s) predecesora(s) Aproximaci´on en horas 1 - 15 2 1 10 3 - 10 4 - 20 5 - 20 6 - 20 7 2,4,5 35 8 6,7 35 9 8 40 10 9 45 11 2,10 40 12 11 10 Cuadro 9.1: Tabla de planificaci´on inicial modificada. Se preveen alrededor de 300 horas en total. Seguidamente, procedemos a presentar una tabla en la que se apreciar´an las horas previstas en comparaci´on con las horas que realmente se le han dedicado a cada tarea. Tarea Horas estimadas Horas reales Porcentaje de desviaci´on 1 15 19 26,67 % 2 10 13 30 % 3 10 7 -30 % 4 20 20 0 % 5 20 25 25 % 6 20 15 -25 % 7 35 35 0 % 8 35 20 -42,86 % 9 40 60 50 % 10 45 40 -11,11 % 11 40 50 25 % 12 10 10 0 % Cuadro 9.2: Tabla comparativa de c´omputo de horas. En la tabla anterior se puede observar que finalmente ha habido una redistribuci´on de las horas que se iban a dedicar inicialmente a las tareas del proyecto. Puede observarse que finalmente se han dedicado 314 horas a este proyecto que aunque son m´as de las inicialmente estipuladas, no sobrepasa demasiado las horas que se le iban a dedicar inicialmente. 56 Como ´ultima conclusi´on a˜nadir´ıa que las tareas de mayor complejidad han sido la extracci´on de datos hasta que se decidi´o utilizar las matrices y el desarrollo del c´odigo del proyecto as´ı como los experimentos que se han realizado. 9.3. Posibles mejoras para futuras investigaciones En este apartado se desarrollaran posibles mejoras o continuaciones para futuras investigaciones a partir de ideas que han surgido a lo largo de este proyecto. En primer lugar, una posible rama de investigaci´on que puede resultar interesante es el estudio de las matrices de cantidad del repositorio de Akcora [11] y propiedades topol´ogicas que pudieran observarse en ellas. Sobre todo, se aconseja el estudio de dichas matrices mediante la filtraci´on Vietoris-Rips, puesto que nos dimos cuenta de que no solo es importante el n´umero de transacciones de cada tipo sino tambi´en la cantidad total que transfieren. Se aconseja esta filtraci´on en concreto, puesto que puede ayudarnos a encontrar patrones o agrupaciones en las matrices de cantidad. En segundo lugar, otra investigaci´on posible podr´ıa ser el objetivo inicial de este proyecto, es decir, formar el grafo de transacciones que se propone en el cap´ıtulo 4si se dispone de suficientes recursos y conocimientos como para poder unificar los archivos que contienen la informaci´on de entradas y salidas de transacciones de Bitcoin. En el caso contrario, se podr´ıa intentar mantener un contacto m´as cont´ınuo con Akcora para formar el grafo a partir de su c´odigo y estudiarlo en busca de propiedades. Y para finalizar, se podr´ıa realizar un an´alisis de la eficiencia de los algoritmos de miner´ıa de Bitcoin, evaluando y comparando posibles implementaciones para determinar cual ofrece un mejor rendimiento. 57 10. Bibliograf´ıa [1] Cuneyt G. Akcora, Asim Kumer Dey, Yulia R. Gel, and Murat Kantarcioglu. Forecasting bitcoin price with graph chainlets, 2018. URL https://doi.org/10. 1007/978-3-319-93040-4 60. [2] Cuneyt G. Akcora, Yitao Li, Yulia R. Gel, and Murat Kantarcioglu. Topological data analysis for ransomware prediction on the bitcoin blockchain, 2020. URL https://par.nsf.gov/biblio/10189145. [3] Cuneyt Gurcan Akcora, Yulia R. Gel, and Murat Kantarcioglu. Blockchain: A graph primer, 2017. URL https://doi.org/10.48550/arXiv.1708.08749. [4] Cuneyt Gurcan Akcora, Nazmiye ceren Abay, Yulia R Gel, Murat Kantarcioglu, Umar Islambekov, Yahui Tian, and Bhavani M. Thuraisingham. Chainnet: Learning on blockchain graphs with topological features, 2019. URL https: //doi.org/10.1109/ICDM.2019.00105. [5] Rocio Gonzalez-Diaz Atienza, Nieves and Matteo Rucco. Persistent entropy for separating topological features from noise in vietoris-rips complexes, 2019. URL https://doi.org/10.48550/arXiv.1701.07857. [6] Fernando Claros Barrero. An´alisis y estudio del grafo de transacciones de bitcoin, 2022. URL https://idus.us.es/bitstream/handle/11441/137229/TFG Fernando Claros Barrero%20(1).pdf?sequence=1. [7] A. Baumann, B. Fabian, and M. Lischke. Exploring the bitcoin network, 2014. URL https://www.academia.edu/78913661/Exploring the Bitcoin Network. [8] Mart´ın Heredia Campos. Filtraciones en homolog´ıa persistente mediante estimadores kernel de densidad, 2018. URL https://ddd.uab.cat/pub/tfg/2018/ 196556/TFG Campos Heredia Martin H.pdf. [9] Dot CSV. Hoy s´ I vas a entender qu´ E es el blockchain - (bitcoin, cryptos, nfts y m´as). Youtube, 2021. URL https://www.youtube.com/watch?v=V9Kr2SujqHw. [10] Murat Kantarcioglu Cuneyt Gurcan Akcora, Yulia R. Gel. Blockchain networks: Data structures of bitcoin, monero, zcash, ethereum, ripple, and iota, 2021. URL https://doi.org/10.1002/widm.1436. [11] Nazmiye Ceren Abay Cuneyt Gurcan Akcora. Coinworks, 2021. URL https: //github.com/cakcora/CoinWorks.git. [12] Sofokles Dans. Criptografia bitcoin ¿qu´e es y como funciona?, 2018. URL https: //www.cafeconcriptos.com/criptografia-bitcoin/. [13] Jake Frankenfield. What is botcoin? how to mine, buy and use it, 2023. URL https://www.investopedia.com/terms/b/bitcoin.asp. 58 [14] Robert Ghrist. Barcodes: The persistent topology of data. BULLETIN (New Series) OF THE AMERICAN MATHEMATICAL SOCIETY, 45, 02 2008. doi: 10.1090/S0273-0979-07-01191-3. [15] Google. Bitcoin-etl library of google, 2022. URL https://github.com/ blockchain-etl/bitcoin-etl. [16] n.d. Web Jobted. Analista programador - salario., 2023. URL https://www. jobted.es/salario/analista-programador. [17] M. Lischke and B. Fabian. Analyzing the bitcoin network: The first four years, 2016. URL https://doi.org/10.3390/fi8010007. [18] Margaret Rouse. Computerweekly.es, 2015. URL https://www.computerweekly. com/es/definicion/Planificacion-de-proyectos. [19] Nathaniel Saul and Chris Tralie. Scikit-tda: Topological data analysis for python, 2019. URL https://doi.org/10.5281/zenodo.2533369. [20] Christopher Tralie, Nathaniel Saul, and Rann Bar-On. Ripser.py: A lean persistent homology library for python. The Journal of Open Source Software, 3(29):925, Sep 2018. doi: 10.21105/joss.00925. URL https://doi.org/10.21105/joss.00925. [21] Agencia Tributaria. Manual de actividades econ´omicas. obligaciones fiscales de empresarios y profesionales residentes en territorio espa˜nol, 2023. URL https: //sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/ manuales-practicos/folleto-actividades-economicas/ 3-impuesto-sobre-renta-personas-fisicas/3 5-estimacion-directa-simplificada/ 3 5 4-tabla-amortizacion-simplificada.html. 59