Recompensas en Blockchain: dinero, reputación y agradecimiento para revisores

Recompensas en Blockchain: dinero, reputaci´on y agradecimiento para revisores Blockchain Rewards: Money, Badges and Reputation for peer reviewers TRABAJO FIN DE GRADO GRADO EN INGENIER´ IA DE SOFTWARE CURSO 2020–2021 Pablo Agudo Brun Daniel Fidalgo Panera Directores Samer Hassan Collado ´ Ambar Tenorio Forn´es Departamento de Ingenier´ıa del Software e Inteligencia Artificial Facultad de Inform´atica Universidad Complutense de Madrid Madrid, Junio de 2021 Agradecimientos Queremos agradecer a los directores del proyecto Samer Hassan Collado y´ Ambar Tenorio Forn´es su ayuda y apoyo durante el proceso de desarrollo de este proyecto. Y tambi´en a todos los desarrolladores de Software Libre y C´odigo Abierto ya que sin su trabajo este proyecto no hubiera sido posible. Pablo Agudo Brun Lo imposible es el fantasma de los t´ımidos y el refugio de los cobardes. Estas l´ıneas son de las m´as importantes de mi vida y por fin lleg´o el momento de escribirlas. Quiero empezar agradeciendo a la universidad Complutense de Madrid y a los profesores que me han formado estos duros pero inolvidables a˜nos. Ahora me gustar´ıa continuar dicendo lo mucho que he crecido gracias a la educaci´on que mis padres me han impartido. Los valores de esfuerzo, sufrimiento y superaci´on que tengo son gracias a ellos. Gracias tambi´en a mi compa˜nera de vida que desde hace tantos a˜nos me apoya, y sin duda es para mi un pilar fundamental. Gracias abuelos porque s´e y me hac´eis saber lo mucho que significa para vosotros que haya conseguido esto. Por ´ultimo y con especial cari˜no, gracias abuela Mar´ıa, t’estime. No me olvido de mis compa˜neros y amigos de la universidad, han sido toda una motivaci´on, y sobre todo gracias a mi m´as que compa˜nero, mi amigo Daniel que me acompa˜na haciendo este trabajo. ¡Lo conseguimos!. 1 Daniel Fidalgo Panera Llevamos un mundo nuevo en nuestros corazones. Quiero agradecer a todas las personas que me han apoyado durante esta etapa, sobre todo a mi familia, en especial a mi madre y a mi hermana, por todo el apoyo recibido, y a mi pareja, por estar siempre ah´ı cuando m´as la he necesitado. Tambi´en a mis amigos, sin los cuales el mundo ser´ıa much´ısimo m´as aburrido. Este TFG se ha realizado durante una pandemia y bajo unas condiciones que distan mucho de las ideales, y en las que se han ido personas a las que amamos, a´un as´ı hemos peleado y estoy orgulloso de lo que hemos conseguido. Durante mi estancia en la universidad he ampliado mis horizontes, as´ı como mi conocimiento, y he tenido la oportunidad de crecer como persona. Este proyecto no hubiera sido posible sin la constancia y el trabajo de mi compa˜nero de carrera y de TFG, gracias Pablo. 2 Resumen Hoy en d´ıa para publicar un art´ıculo acad´emico es necesario seguir una serie de tr´amites. Uno de estos es la revisi´on del art´ıculo. Las personas encargadas de esta tarea no reciben ning´un tipo de visibilidad ni compensaci´on por el trabajo realizado. Para corregir esta situaci´on, en este proyecto, se ha implementado un sistema de recompensas descentralizado, utilizando blockchain para recompensar a los revisores de art´ıculos de investigaci´on. Estas recompensas se dan en forma de transferencia de criptomonedas ETH, en forma de reputaci´on o como premios digitales no transferibles basados en NFTs (Non-fungible tokens). Al utilizar la blockchain de Ethereum nos aprovechamos de su ecosistema para desarrollar una plataforma descentralizada, transparente y sin intermediarios. El sistema engloba una web desarrollada con HTML, CSS, JavaScript y el framework React, y a esta web se conecta una serie de Smart Contracts desarrollados sobre la red de Ethereum con Solidity. Para la realizaci´on de este proyecto ha sido necesario llevar a cabo experimentaciones sobre el desarrollo de un Smart Contract, la implementaci´on y modificaci´on de tokens en Ethereum, el despliegue en una blockchain y el coste que supondr´ıa interactuar con el Smart Contract. Como trabajo futuro, se ha considerado principalmente a˜nadir soporte para poder subir los art´ıculos a la aplicaci´on mediante IPFS, desplegar los Smart Contracts en la red de Ethereum, implementar pruebas en el front-end mediante Selenium o Cypress y desplegar la aplicaci´on en un servidor. Palabras clave: Blockchain, Smart contract, Ethereum, ERC20, ERC721, NFTs. 3 Abstract Nowadays, in order to publish an academic article, it is necessary to follow a series of steps. One of these is the review of the article. The people in charge of this task do not receive any kind of visibility or compensation for the work done. To correct this situation, in this project, a decentralized reward system has been implemented, using blockchain to reward reviewers of research articles. These rewards are given in the form of ETH cryptocurrency transfer, in the form of reputation or as non-transferable digital rewards based on NFTs (non-fungible tokens). Using Ethereum’s blockchain we take advantage of its ecosystem to develop a decentralized, transparent and unmediated platform. The system encompasses a website developed with HTML, CSS, JavaScript and the React framework, and to this website is connected a series of Smart Contracts developed over the Ethereum network with Solidity. For the realization of this project it has been necessary to carry out experiments on the development of a Smart Contract, the implementation and modification of tokens in Ethereum, the deployment on a blockchain and the cost of interacting with the Smart Contract. As future work, we have mainly considered adding support to be able to upload items to the application via IPFS, deploy Smart Contracts on the Ethereum network, implement front-end testing via Selenium or Cypress and deploy the application on a server. Key words: Blockchain, Smart contract, Ethereum, ERC20, ERC721, NFTs. 4 ´ Indice General Agradecimientos 1 Resumen 3 Abstract 4 1. Introducci´on 11 1.1. Motivaci´on............................. 11 1.2. Objeto de la Investigaci´on . . . . . . . . . . . . . . . . . . . . 12 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . 12 1.4. Repositorio ............................ 13 2. Introduction 14 2.1. Motivation............................. 14 2.2. Object of the Investigation . . . . . . . . . . . . . . . . . . . . 15 2.3. ProyectScructure......................... 15 2.4. Repository............................. 16 3. Estado del arte 17 5 3.1. Estadodelarte .......................... 17 3.2. Contexto Tecnol´ogico . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.1. Blockchain......................... 20 3.2.2. Smart Contracts . . . . . . . . . . . . . . . . . . . . . 21 3.2.3. Blockchain 1.0 . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.4. Blockchain 2.0 . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.5. Blockchain 3.0 y futuro . . . . . . . . . . . . . . . . . . 23 4. Metodolog´ıas y tecnolog´ıas 26 4.1. Metodolog´ıas ........................... 26 4.1.1. Scrumban ......................... 26 4.2. Herramientas ........................... 28 4.2.1. Solidity .......................... 28 4.2.2. Truffle........................... 29 4.2.3. RemixIDE ........................ 30 4.2.4. Web3............................ 30 4.2.5. Metamask......................... 31 4.2.6. React ........................... 31 5. Desarrollo 32 5.1. Implementaci´on.......................... 32 5.2. Mockups.............................. 33 5.3. MVP................................ 36 5.4. Release............................... 39 6 6. Resultados 41 6.1. MVP................................ 43 6.2. Release............................... 44 7. Experimentaci´on 47 7.1. GasenEthereum......................... 47 7.2. Despliegue de un Smart Contract . . . . . . . . . . . . . . . . 51 7.2.1. Coste de interactuar con los Smart Contracts desarrollados ........................... 53 7.3. Bloxberg.............................. 54 8. Aportaciones Individuales 56 8.1. Pablo Agudo Brun . . . . . . . . . . . . . . . . . . . . . . . . 56 8.2. Daniel Fidalgo Panera . . . . . . . . . . . . . . . . . . . . . . 58 8.3. Otras aportaciones . . . . . . . . . . . . . . . . . . . . . . . . 60 9. Conclusiones y Trabajo Futuro 61 9.1. Conclusiones............................ 61 9.2. TrabajoFuturo .......................... 62 10.Conclusions and Future Work 64 10.1.Conclusions ............................ 64 10.2.FutureWork............................ 65 Bibliografia 66 7 ´ Indice de Figuras 3.1. Principia comparation table [3] . . . . . . . . . . . . . . . . . 18 3.2. Scienceroot comparation table [6] . . . . . . . . . . . . . . . . 19 3.3. Decentralized Science [7] . . . . . . . . . . . . . . . . . . . . . 19 3.4. State Transition [13] . . . . . . . . . . . . . . . . . . . . . . . 20 3.5. Bitcoin Flow [17] . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.6. Layer 2 Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . 23 3.7. Scalability Trilema . . . . . . . . . . . . . . . . . . . . . . . . 24 3.8. Layer2Scaling .......................... 25 4.1. Github Actions workflow . . . . . . . . . . . . . . . . . . . . . 27 4.2. Solidity .............................. 28 4.3. Truffle ............................... 29 4.4. Remix ............................... 30 5.1. MockupHome........................... 34 5.2. MockupPaper........................... 35 5.3. Mockup Reviewers . . . . . . . . . . . . . . . . . . . . . . . . 36 5.4. MVP................................ 36 8 2.2. Object of the Investigation The aim of this project is to offer an Ethereum-based alternative to the current review process, in the most decentralised and transparent way possible. By generating a reputation system which allows these reviewers to be rewarded, thanked and donated for each review they perform, thus rewarding their work. At the same time abstracting the complexity of the underlying implementation so that anyone with no knowledge of blockchain can use the application. 2.3. Proyect Scructure This proyect is made up of a total of nine chapters, the content of each one is briefly defined below: Chapter 1. The motivation of the project and the object of the research are defined. Chapter 2. English translation of Chapter 1. Chapter 3. Presents the technological context and the state of the art. Chapter 4. Covers development methodologies and tools used in the project. Chapter 5. It describes how the final results of the project have been obtained. Chapter 6. The different experiments and studies related to the generation and deployment of Smart Contracts are discussed. Chapter 7. The individual contributions of each team member are indicated. Chapter 8. The conclusions of the work carried out and future lines of research are shown. Chapter 9. English translation of Chapter 8. 15 2.4. Repository The project code is Free Software and it is publicly available on Github, https://github.com/DecentralizedScience/Rewards. 16 Cap´ıtulo 3 Estado del arte 3.1. Estado del arte Es dif´ıcil encontrar plataformas descentralizadas para la gesti´on del proceso de revisi´on de art´ıculos cient´ıficos, ya que las revistas en las que se suelen publicar se oponen firmemente a cualquier cambio que vea amenazado su f´erreo control. A´un as´ı lentamente la situaci´on ha ido cambiando y hay algunas portales como eLife, F1000Research, Royal Society Open Science, que han empezado a hacer este proceso m´as transparente, aunque el objetivo final de los autores es que se publiquen las revisiones junto con el art´ıculo publicado [1]. Cabe destacar la plataforma Publons [2], donde se recogen m´etricas de autores y revisores para potenciar y reconocer el trabajo de los mismos. Frente a las plataformas centralizadas hay alternativas, entre las que destacan: Principia [3] es un framewrok que intenta solucionar esta situaci´on creando un mercado para autores y revisores, donde estos ´ultimos se vean recompensados seg´un la calidad de su trabajo, para ello proponen un sistema de reputaci´on que no dependa de terceras partes. En esta plataforma los autores hacen pujas para obtener revisiones [4]. 17 Figura 3.1: Principia comparation table [3] ScienceRoot es otra plataforma muy similar a Principia donde los usurarios tambi´en pueden recompensar y en cierto modo ser patrones de los investigadores. ScienceRoot propone una nueva forma de realizar el proceso de investigaci´on y revisi´on, donde cada paso est´a registrado y es reproducible por otros investigadores. As´ı mismo, se podr´ıa almacenar los datos, public´andolos cuando los autores crean conveniente, parecido a como plataformas de control de versiones como GitHub o Gitlab funcionan. Adem´as proponen la creaci´on de un token llamado Science Token(ST) que servir´ıa para sufragar en incentivar las interacciones dentro de la plataforma [5]. 18 Figura 3.2: Scienceroot comparation table [6] Decentralized Science [7] busca ofrecer un repositorio p´ublico de revisiones abiertas [8] y una red de reputaci´on para revisores. En esta plataforma los revisores obtendr´ıan recompensas y reconocimiento por su labor, y los autores podr´ıan encontrar los mejores revisores dependiendo de su reputaci´on [9, 10]. Figura 3.3: Decentralized Science [7] 19 3.2. Contexto Tecnol´ogico 3.2.1. Blockchain Satoshi Nakamoto revolucion´o internet cuando public´o en 2008 un art´ıculo titulado “Bitcoin: A Peer-to-Peer Electronic Cash System” [11], en ´el detalla un nuevo sistema para procesar transacciones financieras sin depender de una autoridad central. Este sistema se basa en una red p2p utilizando Proof of Work para recoger todas las transacciones que se realizan en un registro p´ublico. Este registro se llama Blockchain o cadena de bloques, y al estar replicado en todos los nodos est´a descentralizado y adem´as es resistente a bloqueos y censura, ya que mientras exista al menos un nodo el sistema sigue funcionando. Proof of Work es un sistema de consenso que se basa en la obtenci´on de un hash que comience con un n´umero determinado de ceros, la obtenci´on del hash es una tarea muy intensa que requiere mucha potencia de c´alculo, por lo que hay personas (los mineros) que tienen hardware dedicado a esta tarea. Obtienen beneficio a trav´es de las comisiones de las transacciones y de nuevos bitcoins generados en cada bloque. El n´umero de ceros aumenta progresivamente seg´un aumenta la capacidad de minado global (Hashrate) para mantener una generaci´on de bloques constante. Los bloques son inmutables y su estructura se basa en ´arboles de Merkle, donde cada bloque contiene el hash del anterior, y al igual que en Git [12], al modificar un bloque se alteran todos los posteriores, lo que otorga resistencia a la modificaci´on por actores con malas intenciones. La convenci´on establecida es que la cadena m´as larga es la v´alida. En la siguiente imagen se puede ver como una transacci´on modifica el estado anterior de la blockchain para generar un estado nuevo. Figura 3.4: State Transition [13] 20 3.2.2. Smart Contracts Los Smart Contracts o Contratos Inteligentes [14] son un conjunto de instrucciones software que implementan de forma digital las reglas y acciones de un contrato o acuerdo entre dos o m´as partes. Las m´aquinas expendedoras son el primer ejemplo, ya que permiten adquirir un bien o servicio sin mediaci´on de intermediarios. El contrato inteligente fue propuesto por primera vez por el cript´ografo Nick Szabo en 1994, s´olo cinco a˜nos despu´es de la creaci´on de la World Wide Web. Seg´un la definici´on de Szabo [15], cuando se activa una condici´on preprogramada, el contrato inteligente ejecutar´a las condiciones contractuales correspondientes. La tecnolog´ıa Blockchain nos proporciona un sistema descentralizado, resistente a la manipulaci´on y altamente fiable en el que los contratos inteligentes son muy ´utiles. 3.2.3. Blockchain 1.0 Partiendo de Bitcoin, la tecnolog´ıa blockchain se aplicaba inicialmente a criptomonedas, facilitando formas de pago an´onimas, seguras y descentralizadas. Las criptomonedas se popularizaron con Bitcoin pero se basan en el antecedente de Ecash creado por David Chaum en 1983 [16], que utilizaba firmas digitales ciegas para garantizar la seguridad de las transacciones 21 Figura 3.5: Bitcoin Flow [17] 3.2.4. Blockchain 2.0 Ethereum lider´o una revoluci´on en la tecnolog´ıa Blockchain en forma de Smart Contracts. Ethereum fue concebido por Vitalik Buterin en 2013 y fue lanzado en 2015 despu´es de una campa˜na de crowdfunding el a˜no anterior. Gavin Wood escribi´o el Yellow Paper [18] de Ethereum donde se detalla como funciona la M´aquina Virtual [19], sobre la que se ejecuta el c´odigo de los Smart Contracts. Estos Contratos inteligentes permiten crear Organizaciones Descentralizadas Aut´onomas o DAOs [20, 21], estas organizaciones funcionan de forma totalmente descentralizada sobre la red de Ethereum sin estar influidas por un poder centralizado, y donde las reglas se definen en los propios contratos. Un ejemplo de este tipo de organizaciones lo encontramos en MakerDAO, compuesta por los propietarios del token MKR(Un token es “una unidad de valor que una organizaci´on crea para gobernar su modelo de negocio y dar m´as poder a sus usuarios para interactuar con sus productos, al tiempo que facilita la distribuci´on y reparto de beneficios entre todos sus accionistas”. Extra´ıdo del libro ”The business blockchain”[22]), donde ellos mismos pueden votar propuestas para cambiar las reglas por las cuales se regula DAI [23], una moneda estable vinculada al precio del D´olar Estadounidense. 22 3.2.5. Blockchain 3.0 y futuro Figura 3.6: Layer 2 Ecosystem Despu´es de el nacimiento de Ethereum han surgido nuevas plataformas[24] que utilizan todo el potencial blockchain, en 2014 Neo [25] fue fundada por Da HongFei y Erik Zhang, adem´as de ofrecer una plataforma para la ejecuci´on de contratos inteligentes, dispone de un sistema de gesti´on de identidades digitales basadas en el est´andar X.509 [26]. Posteriormente ha habido una explosi´on de plataformas descentralizadas, desde IOTA, una cryptomoneda que no est´a basada en blockchain sino que utiliza Tangle [27], un gr´afico ac´ıclico dirigido (DAG) para almacenar las transacciones. IOTA se utiliza para desarrollar en el ecosistema de internet de las cosas(IoT) sin necesidad de comisiones ni mineros, ya que cuando ejecutas una transacci´on validas otras dos, por que escala bien. El problema de escalabilidad dentro de blockhain, y sobre todo en Ethereum, es uno de los mas importantes y complejos. El trilema de la escalabilidad nos da a elegir dos opciones entre seguridad, descentralizaci´on y escalabilidad, siempre en detrimento de la opci´on no elegida. 23 Figura 3.7: Scalability Trilema Plasma es una soluci´on de escalado de capa 2, como los rollups [28, 29], que fue propuesta originalmente por Joseph Poon y Vitalik Buterin en Plasma: Scalable Autonomous Smart Contracts. [30] Es un marco de trabajo para construir aplicaciones escalables utilizado por plataformas como Polygon(Matic) [31]. La capa 2 se basa en utilizar ´arboles de Merkle para poder crear un n´umero ilimitado de cadenas hijas asociadas a la red principal, en la cual se pueden ejecutar transaciones y Smart Contracts sin congestionar la red principal [32]. 24 4.2.5. Metamask Metamask es una extensi´on para el navegador que funciona como cartera de criptomonedas y permite a los usuarios interactuar con aplicaciones que utilizan blockchain de forma sencilla [45]. 4.2.6. React React es una biblioteca de JavaScript para crear interfaces de usuario con el fin de desarrollar SPAs. Es declarativo, lo que permite que usando React que sea m´as sencillo crear interfaces interactivas. Est´a basado en componentes encapsulados, donde cada uno de estos componentes gestiona su propio estado. Por otro lado con la composici´on de estas componentes se pueden llegar a generar interfaces de usuario complejas. Junto con React [46] se ha usado el framework Ant Design [47] para la creaci´on de las interfaces de usuario. Ant Design es un marco de desarrollo que ayuda a crear dise˜nos bonitos y con capacidad de respuesta utilizando un HTML amigable. Para la gesti´on del estado se ha utilizado Drizzle, un herramienta basada en el store de Redux [48] para manejar los datos del contrato y su interacci´on desde el front-end. 31 Cap´ıtulo 5 Desarrollo En este cap´ıtulo se aborda el proceso de desarrollo que se ha seguido durante la realizaci´on de este proyecto. 5.1. Implementaci´on Hay dos partes bien diferenciadas en el trabajo realizado, por una parte est´an los contratos inteligentes donde se encuentra el grueso de la funcionalidad y por otra parte el front-end que se conecta a la blockchain para interactuar con los contratos. Dentro de la metodolog´ıa Scrumban fijamos las tareas a realizar en un tablero de Kanban en Trello. Despu´es de estimar la cantidad de trabajo que supone cada historia de usuario y de dividir las historias de usuario en tareas, se recogieron todas ellas en el tablero de Trello ordenadas por prioridad. En esta herramienta el equipo llev´o el seguimiento del trabajo realizado y control´o el estado en el que se encontraba cada tarea. Una vez creado el Backlog se ordenaron las tareas por prioridad y se seleccionaron las m´as importantes para crear el Producto M´ınimo Viable (MVP). Para posteriormente iterar e ir a˜nadiendo funcionalidad hasta llegar al producto completo. El comienzo del proyecto vino marcado por un periodo de investigaci´on y estudio, donde las tareas que se abordaron fueron de investigaci´on sobre las diferentes tecnolog´ıas usadas en el desarrollo del proyecto. En el apar32 tado de Smart Contract, se realizaron una serie de tutoriales introductorios a Solidity, lenguaje de programaci´on usado para escribir Smart Contracts, adem´as de Mocha y Chai para el testeo de las funcionalidades implementadas. Respecto a las tareas de React se realizaron tutoriales introductorios de React y otras librer´ıas relacionadas con el front-end de la aplicaci´on, como Redux para la gesti´on del flujo de la informaci´on, React Router para la gesti´on de rutas y Ant Design para la generaci´on de la interfaz de usuario dentro de la aplicaci´on. Para la generaci´on de la interfaz gr´afica el equipo cre´o una serie de mockups de la aplicaci´on con la herramienta online Figma [49]. Estos mockups han sufrido cambios debido al feedback recibido en el marco de la metodolog´ıa Scrum, donde hemos tratado cada reuni´on con los directores como una demo, con la posterior realizaci´on de reuniones de retrospectiva. Dentro de la investigaci´on sobre las herramientas a utilizar y el ecosistema blockchain el equipo acudi´o a un meetup “Tips de prototipado r´apido de Dapps con Ethereum y React” donde se repasaron mediante un enfoque pr´actico, flujos de trabajo habituales y de competencia profesional dirigidos al prototipado r´apido de Dapps utilizando las tecnolog´ıas de Ethereum, Javascript React, as´ı como servicios y librer´ıas asociados [50]. 5.2. Mockups En este apartado se muestran los mockups generados los cuales sirvieron durante el desarrollo de la aplicaci´on para implementar la interfaz gr´afica de usuario. Todas las vistas contienen un espacio com´un de navegaci´on que permite al usuario moverse entre las diferentes partes de la aplicaci´on. Otra caracter´ıstica com´un que contienen todas las vistas es la cuenta asociada con la que se operar´a dentro de la aplicaci´on. Estos elementos se pueden observar en todos los mockups que se muestran a continuaci´on. El mockup de la pantalla de inicio incluye un formulario en la parte superior de la pantalla el cual permite crear un nuevo art´ıculo. A continuaci´on de este formulario se presentan en forma de cajas un listado de todos los art´ıculos existentes con un encabezado que contiene el t´ıtulo y el autor del art´ıculo, y un cuerpo con una pre visualizaci´on de este art´ıculo. A trav´es de un bot´on se puede acceder a la vista del art´ıculo en detalle. 33 Figura 5.1: Mockup Home Al abrir uno de los art´ıculos de la pantalla de inicio se accede a la vista en detalle de este art´ıculo. Para la creaci´on de esta pantalla se utiliz´o el siguiente mockup como base en el cual se muestra en el apartado izquierdo de la pantalla el contenido del art´ıculo con el t´ıtulo y e autor en la parte superior. Por otro lado en la parte derecha de la pantalla se muestra un listado de los revisores de este art´ıculo. Por cada revisor se muestran tres botones, uno para enviar una propina, otro para dar reputaci´on y el ´ultimo para dar un trofeo o premio. 34 Figura 5.2: Mockup Paper El ´ultimo mockup sirvi´o para establecer un concepto de c´omo se mostrar´ıa la vista de revisores. Esta vista se compondr´ıa por una tabla donde se mostrar´ıan todos los revisores con una serie de datos por cada uno de ellos. 35 Figura 5.3: Mockup Reviewers 5.3. MVP Durante la creaci´on del MVP de la aplicaci´on el equipo implement´o el siguiente conjunto de tareas. Figura 5.4: MVP Para realizar estas tareas se empez´o con la generaci´on y pruebas del Smart Contract de Rewards. Este Smart Contract, en una primera versi´on, permit´ıa 36 enviar una propina de 1 ETH a un revisor. Para completar la generaci´on del MVP tambi´en fue necesario implementar parte de la interfaz gr´afica de la aplicaci´on. Para comprobar el correcto funcionamiento de la aplicaci´on en este punto, era necesario realizar una transacci´on. Para ello se lanzaba la aplicaci´on y la blockchain de Ganache en local y se pulsaba sobre el bot´on de enviar propina para iniciar la transacci´on. En la siguiente imagen se pude ver la interfaz de Ganache, que ejecuta una blockchain en local. Se lanza con 10 cuentas por defecto con 100 ETH cada una, para poder hacer pruebas o desplegar contratos. Figura 5.5: Ganache Una vez pulsado el bot´on se abre desde el navegador la cartera de Metamask, cuya configuraci´on se hab´ıa hecho previamente. En este paso el usuario autoriza que se ejecute la transacci´on que mover´a 1 ETH de su cartera, a la cartera del revisor. 37 Figura 5.6: Metamask Transaction Al finalizar la transacci´on se pod´ıa comprobar desde la blockchain de Ganache c´omo se hab´ıa generado un movimiento de ETH entre diferentes cuentas. Figura 5.7: Ganache Transactions 38 5.4. Release Una vez generado el MVP de la aplicaci´on el siguiente hito del equipo fue la investigaci´on sobre tokens de Ethereum. Antes de proseguir definir que los ERC en Ethereum son documentos t´ecnicos utilizados por los desarrolladores de contratos inteligentes en Ethereum. Definen un conjunto de reglas necesarias para implementar tokens para el ecosistema Ethereum. Estos documentos suelen ser creados por desarrolladores e incluyen informaci´on sobre especificaciones de protocolo y descripciones de contratos. Antes de convertirse en un est´andar, un ERC debe ser revisado, comentado y aceptado por la comunidad a trav´es de un EIP (propuesta de mejora de Ethereum) [51]. Se pueden consultar los ERCs existentes en https://eips.ethereum.org/erc. Siguiendo con el desarrollo, los tokens a investigar fueron el ERC20 [52] y el ERC721 [53]. Para esta tarea el equipo comenz´o con el estudio de la librer´ıa de Smart Contracts de OpenZeppelin [54], la cual inclu´ıa una documentaci´on muy completa e implementaciones sobre los ERCs a investigar. OpenZeppelin es un proyecto en el que se han desarrollado diversas herramientas para facilitar el uso de aplicaciones descentralizadas y la creaci´on de Smart Contracts. Siguiendo con los tokens, el equipo decidi´o utilizar el est´andar ERC20 para la implementaci´on del sistema de reputaci´on. Por otro lado despu´es de realizar la investigaci´on del token ERC721 el equipo eligi´o este para usarlo en el sistema de recompensas ya que este token ten´ıa como caracter´ıstica ser no fungible, es decir, que cada token era ´unico y por ende las recompensas otorgadas tambi´en. Despu´es de la investigaci´on sobre los tokens, se realizaron una serie de modificaciones sobre las implementaciones de los est´andares de OpenZeppelin para adaptarlos a las necesidades del proyecto. Las modificaciones realizadas en los tokens ERC20 y ERC721 fueron hacer de estos tokens no transferibles, ya que en los sistemas de reputaci´on y recompensas que se quer´ıan implementar en el proyecto no se permite hacer transferible la reputaci´on o las recompensas que un revisor pudiera obtener. Estas modificaciones podr´ıan presentarse como nuevos ERCs y formalizarlos en est´andares. Adem´as para el ERC20 se suprimieron los decimales, ya que la reputaci´on es indivisible, tambi´en se modific´o el suministro de tokens para que sea infinito. En el ERC721 se eliminaron dependencias de IERC721Receiver, IERC721Metadata, IERC721Enumerable y ERC165, ya que no eran necesarias para nuestra implementaci´on, y se modific´o el identificador para que sea un hash formado por el usurario que da la recompensa, el revisor que 39 la recibe, el tipo de recompensa, y el art´ıculo al cual pertenece la revisi´on. De esta forma nos aseguramos que las recompensas sean ´unicas y no puedan duplicarse. Al realizar las modificaciones se decidi´o nombrar los contratos de ERC20 como ReputationToken y de ERC721 como AwardsToken. Con estas modificaciones se consiguieron implementar los sistemas de reputaci´on y recompensas acordes a las especificaciones que se marcaron en el proyecto. Para comprobar el correcto funcionamiento de las implementaciones realizadas se utiliz´o el IDE de Remix el cual contiene una funci´on de depuraci´on para los Smart Contracts. El desarrollo de las modificaciones sobre los tokens anteriores se vio facilitado y acelerado gracias al uso de Integraci´on Continua por la detecci´on temprana de errores. Durante todo el periodo de desarrollo del proyecto, el equipo fue recopilando documentaci´on la cual se us´o posteriormente para la generaci´on de esta memoria. En la generaci´on de la documentaci´on, el equipo determin´o que a medida que se fuera desarrollando esta documentaci´on se fuera revisando y actualizando. Esto se hizo con la finalidad de mejorar posteriormente los distintos apartados de la memoria y corregir posibles erratas que fueran surgiendo. 40 Cap´ıtulo 7 Experimentaci´on En este apartado se tratar´an los diferentes experimentos y estudios relacionados los Smart Contracts desarrollados donde se analiza el impacto econ´omico de la utilizaci´on de Ethereum, a trav´es del c´alculo de costes en Gas y del despliegue de los mismos en una red de prueba. 7.1. Gas en Ethereum Para entender el Gas en Ethereum es necesario hablar previamente de las transacciones. Una transacci´on de Ethereum se puede definir como la ejecuci´on de una instrucci´on, como podr´ıa ser transferir Ethereum de una cuenta a otra. Una transacci´on requiere una tarifa y a su vez se deben minar para validarlas. En este punto es donde interviene el Gas. El Gas es la unidad que mide la cantidad de esfuerzo computacional requerido para ejecutar operaciones espec´ıficas en la red de Ethereum. Es una referencia al c´alculo requerido para procesar la transacci´on por parte de un minero, o dicho de otra manera, es el precio que los usuarios deben pagar por este c´alculo. Las tarifas de gas se pagan en ETH, que es la moneda nativa de Ethereum. Los precios del gas se indican en Gwei y la equivalencia es 1 Gwei igual a 0,000000001 Ether [57]. El gas en Ethereum se puede dividir en tres conceptos: el costo en unidades de gas, el precio del gas y el l´ımite de gas [58]. 47 El costo de gas se entiende como las unidades de gas que son necesarias para hacer cada operaci´on y ya est´an definidos en la documentaci´on de Ethereum. El precio del gas, ya explicado anteriormente y sobre el que se puede pagar un mayor o menor precio de gas por transacci´on para obtener as´ı prioridad y ser procesada antes por los mineros. El l´ımite de gas es la cantidad m´axima de gas que se est´a dispuesto a pagar para realizar una transacci´on. Esta cantidad suele y debe ser mayor que la cantidad real de gas que requiere una cierta transacci´on ya que en caso contrario la transacci´on fallar´a debido a un l´ımite de gas demasiado bajo y la transacci´on quedar´a en un estado bloqueado. Para establecer el l´ımite de gas necesario Ether Gas Station [59] recomienda establecer este l´ımite en 21000 aunque no existe un l´ımite fijo preestablecido. Con los factores explicados anteriormente se puede concluir que la existencia del gas en Ethereum tiene los siguientes usos. Se incentiva a que los mineros inviertan su tiempo y energ´ıa en la ejecuci´on de transacciones a cambio del pago de unas tasas de gas. Ayudan a mantener la seguridad la red de Ethereum. Por cada transacci´on se necesita una tarifa, esto evita el posible spam a la red. Resuelve el problema del halting problem [60] gracias al l´ımite de gas. El halting problem o problema de la detenci´on consiste de manera resumida en saber si un programa arbitrario con una entrada establecida se ejecutar´a y terminar´a o si continuar´a funcionando para siempre. En Ethereum este problema no es replicable ya que en una transacci´on con c´odigo malicioso o incorrecta el gas se acabar´a agotando y la ejecuci´on finalizar´a. Para calcular el coste de una transacci´on en el Smart contract se us´o la calculadora de ETH Gas Station [59]. Los datos que se aportaron fueron el uso de gas que se requiere en una transacci´on, que a d´ıa de hoy es de 60000, el l´ımite del gas establecido en 21000 por defecto en Ether Gas Station y el precio del Gas. Para este ´ultimo dato se opt´o por elegir el precio medio del Gas que a d´ıa de hoy equivale a 94 Gwei. Los datos resultados fueron los siguientes. 48 % of last 200 blocks accepting this gas price 93.8271604938 Transactions At or Above in Current Txpool 166 Mean Time to Confirm (Blocks) 2 Mean Time to Confirm (Seconds) 33 Transaction fee (ETH) 0.00564 Transaction fee ($)19.1478$ Cuadro 7.1: Transaction cost De estos resultados se pudo observar que el precio de las tarifas de transacci´on de son bastante elevadas. Para estudiar el precio de las tarifas de transacci´on se acudi´o a blockchair.com de donde se extrajo la siguiente gr´afica que representa la evoluci´on que han tenido en el tiempo las tarifas de Ethereum. Figura 7.1: Average transaction fee (USD) Como se puede observar, las tasas por transacci´on en Ethereum se han disparado a principios de este a˜no 2021. Para entender este crecimiento se debe retroceder hasta 2017 donde hubo un gran auge de ICO (Initial Coin Offering), debido a la gran cantidad de tokens que se crearon en la cadena de bloques de Ethereum. Estos tokens fueron posteriormente vendidos a trav´es 49 de sitios web centralizados. A partir de entonces, durante los siguientes a˜nos el espacio ICO se fue regulando, lo que provoc´o que los nuevos intercambios pasaran por procedimientos KYC (Know Your Customer) cada vez m´as engorrosos. Esta situaci´on provoc´o la aparici´on de una soluci´on en forma de intercambios descentralizados (DEX), donde cualquier individuo ser´ıa capaz de realizar intercambios sin la necesidad de pasar por un proceso de verificaci´on. Un DEX o un intercambio descentralizado, consiste en una plataforma de intercambio de activos digitales. En un DEX se hace uso del principio de descentralizaci´on, lo que quiere decir que no es necesaria la participaci´on de una entidad central para realizar este intercambio. Esto permite el comercio peer-to-peer o entre pares y soluciona el problema de que una entidad central pueda manipular los precios o que se realicen operaciones fraudulentas [61]. Con la aparici´on de DeFi o Finanzas Descentralizadas el volumen de intercambios descentralizados aument´o dr´asticamente pasando de 540.026.286$ en 2017 a 426.503.124.056$en 2021. Para la obtenci´on de estos datos se utiliz´o la p´agina duneanalytics.com, que sirve para realizar an´alisis sobre datos de la blockchain de Ethereum. En esta p´agina se lanz´o la siguiente consulta, que pide los datos sobre el volumen de intercambio en DEXes o Plataformas de Intercambio Descentralizadas en los ´ultimos 5 a˜nos. SELECT date_trunc('year', block_time), SUM (usd_amount) AS usd_volume FROM dex.trades t WHERE block_time >= date_trunc('year', now()) -interval '5 years' GROUP BY 1; El resultado de la consulta se puede observar en esta gr´afica. 50 Figura 7.2: Trading volume in the last 5 years Como vemos, todos estos factores, junto con la volatilidad del precio de los tokens, han contribuido a que el coste econ´omico de desplegar contratos e interactuar con la blockchain sean procesos caros y de coste impredecible. Para evitar estos altos costes transaccionales existen varias alternativas. Se podr´ıa utilizar la blockchain de Bloxberg, que se caracteriza por proporcionar a los cient´ıficos servicios descentralizados para sus investigaciones, y al utilizar el Faucet se podr´ıa afrontar el pago de las transacciones. Un Faucet es una web donde puedes obtener generalmente peque˜nas cantidades de una criptomoneda de forma gratuita. Se analizar´a en el apartado 6.3. Por otro lado, se podr´ıan utilizar plataformas basadas en la capa 2 como Polygon, las parachains de Polkadot o directamente Ethereum 2.0, con el objetivo de que las interacciones con la blockchain sean m´as econ´omicas. Estas formas de escalado se detallan en el apartado 3.1.5. 7.2. Despliegue de un Smart Contract Una vez que el Smart Contract fue generado se despleg´o en la red local de Ethereum. Para hacer el despliegue fue necesario previamente generar los archivos de configuraci´on 1 initial migrations.js y2 deploy contracts.js que nos sirvieron para hacer el despliegue de los Smart contracts. El archivo 1 initial migrations.js es requerido por Truffle para realizar una primera migraci´on del contrato Migrations.sol, definido ya por Truffle, y el cual se usa para mantener un registro de las migraciones que se han realizado en la red. En el archivo 2 deploy contracts.js, se especifican todos los Smart Contracts a desplegar. Desde una terminal se compilaron los Smart Contracts con el comando truffle compile el cual gener´o los artefactos en formato JSON de los Smart Contracts dentro del proyecto. Dentro de este paso es importante la configuraci´on de la versi´on de solc en el archivo truffle-config.js. Para este proyecto se us´o la versi´on 0.8.1 de solc. Y tambi´en es necesario seleccionar la red, se ha usado Ganache pero tambi´en se puede levantar una blockchain con truffle develop. Tras compilar los Smart Contracts se pas´o a ejecutar la migraci´on con el comando truffle migrate. Para realizar la migraci´on se conecta a la blockchain local de Ganache. 51 Existe una migraci´on inicial requerida por Truffle para habilitar la funcionalidad de migraciones. El resultado de la migraci´on de los Smart Contracts queda reflejado en la siguiente imagen. Figura 7.3: Smart Contracts migration Como se puede observar en la imagen, todo despliegue conlleva un coste de ETH ya que existe un c´alculo computacional que debe de ser cubierto. El 52 coste final del despliegue es de 0.09677932 ETH, lo que equivale a 213.3465€. Este coste contiene el ETH que fue necesario para el despliegue de todos los Smart Contract, incluyendo todas las migraciones. 7.2.1. Coste de interactuar con los Smart Contracts desarrollados En esta secci´on se analizan los costes de interactuar con la funcionalidad que se ha desarrollado dentro de los Smart Contracts y lo que tendr´ıa que pagar un usuario. En el Yellow Paper, Gavin Wood detalla la tabla de tarifas. Dentro de esta tabla nos centramos en Gtransaction,Gtxdatanonzero,Gtxdatazero. 53 Figura 7.4: Costs table Vemos que: 21000 gas se paga por cada transacci´on. 68 gas se paga por cada byte distinto de cero de datos o c´odigo por cada transacci´on. 4 gas se paga por cada byte igual a cero de datos o c´odigo por cada transacci´on. Tras el despliegue de los Smart Contracts se us´o la aplicaci´on de Remix para interactuar con ellos y analizamos los costes que tendr´ıan las diversas operaciones que los componen. El resultado de estos costes se muestra en la siguiente tabla. Operation Transaction cost Execution cost gas euros gas euros Create Paper 111142 0,2189 88974 0.2272 Add Reviewer with a Review 163064 0.4164 139168 0.3554 Give Reputation 163064 0.4164 139168 0.3554 Undo Give Reputation 26701 0.0682 30593 0.0781 Send Tip to Reviewer 34764 0.0888 11956 0.0305 Give Award 183544 0.4687 160544 0.4099 Cuadro 7.2: Operations costs 7.3. Bloxberg Para el despliegue del Smart Contract se hizo una investigaci´on sobre la blockchain global de Bloxberg. Esta cadena de bloques se caracteriza por ser segura y estar creada por un consorcio de organizaciones dedicadas a la investigaci´on cient´ıfica. Bloxberg pretende promover la primera red cient´ıfica descentralizada para proporcionar a los cient´ıficos servicios descentralizados de manera global. Tambi´en pretende fomentar la colaboraci´on entre la comunidad cient´ıfica mundial ofreciendo a los investigadores un servicio robusto y aut´onomo [62]. 54 Las principales caracter´ısticas por las que el equipo decidi´o hacer una investigaci´on sobre Bloxberg fueron: La certificaci´on de datos de investigaci´on permite que los investigadores aprovechen la cadena de bloques de Bloxberg para crear una huella del trabajo sobre la investigaci´on realizada. Tambi´en permite generar un certificado que demuestra cu´ando se realizaron la carga de los datos en un momento determinado. Estos datos no tienen por que hacerse p´ublicos. El grifo de Bloxberg proporciona bergs (la moneda de Bloxberg) entre aquellas entidades que quieran construir en Bloxberg o utilizar funcionalidades de las aplicaciones. Estos tokens sirven para sufragar los despliegues de Smart Contracts o para interactiar con las aplicaciones ya desplegadas. Tras esta investigaci´on se vio como una posibilidad el despliegue de los Smart Contracts dentro de la blockchain de Bloxberg. Al estar realizando un proyecto de investigaci´on se podr´ıan usar los recursos que se pon´ıan a nuestra disposici´on. Con estos recursos el equipo ser´ıa capaz de registrar mediante una huella temporal el trabajo de investigaci´on realizado y hacer pruebas sin limitaciones gracias al grifo de begs que proporcionan los miembros del consorcio y as´ı solventar el costo de las transacciones que se mencionan en los apartados anteriores. 55 Cap´ıtulo 8 Aportaciones Individuales Las aportaciones individuales son iguales a grandes rasgos ya que hemos trabajado siempre de forma conjunta y por igual en todas las partes del producto, incluida esta memoria. 8.1. Pablo Agudo Brun En el desarrollo de este proyecto he realizado las siguientes aportaciones: Investigaci´on sobre los fundamentos de Blockchain Asistencia al meetup “Tips de prototipado r´apido de Dapps con Ethereum y React” donde se repasaron mediante un enfoque pr´actico, flujos de trabajo habituales y de competencia profesional dirigidos al prototipado r´apido de Dapps utilizando las tecnolog´ıas de Ethereum, Javascript React, as´ı como servicios y librer´ıas asociados Investigaci´on sobre Truffle, Ganache y Drizzle as´ı como la realizaci´on de los tutoriales oficiales. Realizaci´on del mapa de historias de usuario. Aprendizaje de Javascript. Aprendizaje de React para construir la interfaz de usuario. 56 Optimizar los Smart Contracts aprovechando las funcionalidades de Solidity para reducir el uso de Gas. Desplegar los contratos en la red principal de Ethereum. Desplegar el front-end en un servidor para poder acceder a la aplicaci´on desde cualquier lugar o dispositivo. A˜nadir funcionalidad para soportar m´ultiples revisiones por cada revisor. Implementar test automatizados de interfaz en el front-end con Selenium o Cypress. 63 Cap´ıtulo 10 Conclusions and Future Work 10.1. Conclusions At this point we can look back and say that the objectives set in the development of the project have been met, in addition to those that were added along the way. The objective of this proyect was to explore decentralized alternatives for managing reviewer rewards. We believe that we have made good progress exploring the options offered by blockchain technology and we hope that it can serve as a reference for related research or as a basis for future projects, since in a way, this is what free software is all about. In this project we have done an intense work of experimentation regarding the world surrounding Smart Contracts. During this process we have learned a lot, we have digested huge amounts of documentation and we have iterated on numerous errors. In this work we have been able to learn how Smart contracts are deployed, how the concept of Gas works in Ethereum and how the blokchain is executed at a low level. We have also investigated the potential deployment on Bloxberg. All this work has given us new insights into this world. After these experimentations, we have learned the following: about Gas pricing, the role of scaling alternatives within Ethereum, although the biggest hope for decongestion is Ethereum 2.0. There is benefit in using Bloxberg, although it is not a very popular platform, and we concluded that optimization during the design and development of Smart Contracts is a key part to reduce the cost of deployment. 64 About the technologies used we can say that they show great potential. We believe that Ethereum will continue to grow and that more projects will make use of this platform in the future. In the case of Solidity, being in a beta phase forced us to make several iterations during the development of Smart Contracts as we increased the version of the compiler used. Regarding React as a framework to build the user interface, we can say that it is a robust system, with a more intuitive learning process that has allowed us to create declarative interfaces dynamically. Thanks to its component system we have been able to encapsulate the different functionalities implemented. We also highlight the libraries that have facilitated the development of the application, as is the case of drizzle. 10.2. Future Work Add support for uploading and storing articles directly in the application using IPFS, due to the cost of storage on the blockchain is neither feasible nor scalable because it is prohibitively expensive. Integrate the application with an identity provider so that reviewers can import their data and history more easily. Add a filtering system in the reviewers table to allow searches based on certain parameters. Add filtering system in the article view to allow searches based on parameters. Optimize Smart Contracts taking advantage of Solidity functionalities to reduce Gas usage. Deploy contracts on the Ethereum mainnet. Deploy the front-end on a server to be able to access the application from any location or device. Add functionality to support multiple reviews per reviewer. Implement automated front-end interface testing with Selenium or Cypress. 65 Bibliografia [1] Jessica K Polka y col. Publish peer reviews. 2018. [2] Publons.url:https://publons.com/about/mission. [3] Principia Network.url:http://www.principia.network. [4] Andrea Mambrini y col. “PRINCIPIA: a Decentralized Peer-Review Ecosystem”. En: arXiv preprint arXiv:2008.09011 (2020). [5] Vlad G¨unther y Alexandru Chirita. “Scienceroot”. En: (2018). url: https://www.scienceroot.com/wpcontent/uploads/2020/11/ whitepaper.pdf. [6] Scienceroot.url:https://www.scienceroot.com. [7] Decentralized Science.url:decentralized.science. [8] Tony Ross-Hellauer. “What is open peer review? A systematic review”. En: F1000Research 6 (2017). [9] Ambar Tenorio Forn´es y col. “A decentralized publication system for open science using blockchain and ipfs”. En: (2018). [10] Ambar Tenorio-Forn´es y col. “Towards a decentralized process for scientific publication and peer review using blockchain and IPFS”. En: Proceedings of the 52nd Hawaii International Conference on System Sciences. 2019. [11] Satoshi Nakamoto. “Bitcoin: A Peer-to-Peer Electronic Cash System”. En: (2008). url:www.bitcoin.org. [12] url:https://mirrors.edge.kernel.org/pub/software/scm/git/ docs/user-manual.html#trust. [13] Vitalik Buterin. “Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform”. En: (2013). url:ethereum.org/ whitepaper. 66 [14] Alexander Savelyev. “Contract Law 2.0: ((Smart)) Contracts As the Beginning of the End of Classic Contract Law”. En: (2016). [15] Nick Szabo. “Formalizing and Securing Relationships on Public Networks”. En: First Monday 2 (1997). url:https://firstmonday.org/ ojs/index.php/fm/article/view/548. [16] David Chaum. “Blind Signatures for Untraceable Payments”. En: (1983). [17] BTC Flow.url:https://www.bitpanda.com/academy/es/lecciones/ que-es-la-mineria-de-bitcoin-y-como-funciona-la-mineria. [18] Gavin Wood y col. “Ethereum: A secure decentralised generalised transaction ledger”. En: Ethereum project yellow paper (2014). [19] EVM.url:https://ethereum.org/en/developers/docs/evm. [20] Christoph Jentzsch. “Decentralized autonomous organization to automate governance”. En: White paper, November (2016). [21] Youssef El Faqir, Javier Arroyo y Samer Hassan. “An overview of decentralized autonomous organizations on the blockchain”. En: Proceedings of the 16th International Symposium on Open Collaboration. 2020, p´ags. 1-8. [22] William Mougayar. The business blockchain: promise, practice, and application of the next Internet technology. John Wiley & Sons, 2016. [23] Maker Team. “The dai stablecoin system”. En: URl: https://makerdao. com/whitepaper/DaiDec17WP. pdf (2017). [24] Damiano Di Francesco Maesa y Paolo Mori. “Blockchain 3.0 applications survey”. En: Journal of Parallel and Distributed Computing 138 (2020), p´ags. 99-114. [25] “Neo: A distributed network for the Smart Economy”. En: (2014). url: docs.neo.org/docs/en-us/basic/whitepaper.html. [26] Sharon Boeyen y col. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 5280. 2008. url:https://rfc-editor.org/rfc/rfc5280.txt. [27] Serguei Popov. “The tangle”. En: White paper 1 (2018), p´ag. 3. [28] ZK-Rollups.url:https://docs.ethhub.io/ethereumroadmap/ layer-2-scaling/zk-rollups. [29] Optimistic Rollups.url:https : / / docs . ethhub . io / ethereum - roadmap/layer-2-scaling/optimistic_rollups. [30] Joseph Poon y Vitalik Buterin. “Plasma: Scalable autonomous smart contracts”. En: White paper (2017), p´ags. 1-47. 67 [31] Sandeep Nailwal y Milhailo Bjelic Jaynti Kanani Anurag Arjun. “Polygon. Ethereum’s Internet of Blockchains”. En: (febrero de 2021). url: https://polygon.technology/lightpaper-polygon.pdf. [32] Layer 2 Scaling.url:https://docs.ethhub.io/ethereum-roadmap/ layer-2-scaling/plasma. [33] Ethan Buchman Jae Kwon. “Cosmos: A Network of Distributed Ledgers”. En: (2016). url:https://github.com/cosmos/cosmos/blob/ master/WHITEPAPER.md. [34] Cardano.url:https://cardano.org. [35] Gavin Wood. “Polkadot: Vision for a heterogeneous multi-chain framework”. En: White Paper (2016). [36] Webassembly.url:webassembly.org. [37] Substrate.url:substrate.io. [38] Ajay Reddy. The Scrumban [r] evolution: getting the most out of Agile, Scrum, and lean Kanban. Addison-Wesley Professional, 2015. [39] Martin Fowler, Jim Highsmith y col. “The agile manifesto”. En: Software Development 9.8 (2001), p´ags. 28-35. [40] Smart Contract.url:https://www.ibm.com/topics/smart-contracts. [41] Mocha.url:mochajs.org. [42] Chai.url:chaijs.com. [43] Truffle Suite.url:https://www.trufflesuite.com/truffle. [44] Wei-Meng Lee. “Using the web3.js APIs”. En: Beginning Ethereum Smart Contracts Programming: With Examples in Python, Solidity, and JavaScript. Berkeley, CA: Apress, 2019, p´ags. 169-198. [45] Metamask.url:metamask.io. [46] React.url:https://es.reactjs.org/. [47] Ant Design.url:https://ant.design/. [48] Redux.url:https://es.redux.js.org/. [49] Figma.url:figma.com. [50] Jorge V. “Tips de prototipado r´apido de Dapps con Ethereum y React”. En: (15 de octubre de 2020). url:https://www.meetup.com/esES/Ethereum-Spain/events/273948330. [51] ERC.url:https://docs.ethhub.io/builtonethereum/erctoken-standards/what-are-erc-tokens/. 68 [52] Fabian Vogelsteller y Vitalik Buterin. “ERC-20 token standard”. En: Ethereum Foundation (Stiftung Ethereum), Zug, Switzerland (2015). [53] William Entriken y col. “Erc-721 non-fungible token standard”. En: Ethereum Foundation (2018). [54] OpenZeppelin.url:https://docs.openzeppelin.com/openzeppelin. [55] url:https://www.scrummanager.net/bok/index.php?title=Epic. [56] Dapp architecture.url:https://www.geeksforgeeks.org/creatingdapps-using-the-truffle-framework. [57] Kevin Ziechmann. “Gas and fees”. En: (30 de marzo de 2021). url: https://ethereum.org/en/developers/docs/gas. [58] Anil Donmez y Alexander Karaivanov. “Transaction Fee Economics in the Ethereum Blockchain”. En: (2021). [59] Eth Gas Station.url:https://ethgasstation.info. [60] Leslie Burkholder. “The halting problem”. En: ACM SIGACT News 18.3 (1987), p´ags. 48-60. [61] DEX.url:https : / / economia3 . com / que - es - dex - solucion - intercambio-descentralizado/. [62] Dr. Sandra Vengadasalam y James Lawton Friederike Kleinfercher. “Bloxberg. The Trusted Research Infrastructure”. En: (febrero de 2020). url:https : / / bloxberg . org / wp - content / uploads / 2020 / 02 / bloxberg_whitepaper_1.1.pdf. [63] Juan Benet. “Ipfs-content addressed, versioned, p2p file system”. En: arXiv preprint arXiv:1407.3561 (2014). 69