SCiBEth: notario virtual en la cadena de bloques Ethereum

Escuela de Ingeniería Informática de Segovia Grado en Ingeniería Informática de Servicios y Aplicaciones SCiBEth: Notario virtual en la cadena de bloques Ethereum Alumno: Luis Mateos Fernández Tutores: José Vicente Álvarez Bravo i Agradecimientos “A mis padres, a mis hermanos y a toda mi familia, gracias a quienes soy quien soy y hacia quienes sólo puedo expresar mi más sincero agradecimiento por apoyarme durante la etapa académica que hoy culmina, gracias a aquellos compañeros y amigos que me han apoyado y han confiado en mi y gracias a mi profesor que me ha apoyado en este proyecto personal en el cuál me embarque y hoy os puedo presentar. ” iii Índice general Índice de figuras IX Índice de tablas XIII 1. Introducción 3 1.1. Introducción...................................... 4 1.2. Motivación....................................... 5 1.3. Objetivosyalcance.................................. 5 1.4. Estructuradelproyecto................................ 7 2. Estado del arte 9 2.1. eBay.......................................... 10 2.2. Wallapop ....................................... 11 2.3. Vibbo ......................................... 12 2.4. Milanuncios ...................................... 13 2.5. Comparación del análisis con la propuesta . . . . . . . . . . . . . . . . . . . . . 14 3. Introducción a la tecnología de Blockchain y el origen de Ethereum 17 3.1. Conceptos más importantes sobre Blockchain . . . . . . . . . . . . . . . . . . . . 18 3.1.1. Arquitecturas Distribuidas . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2. Blockchain................................... 19 3.2. Criptomonedas .................................... 21 3.2.1. Moneda Descentralizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3. OrígenesdeEthereum ................................ 22 3.3.1. Bitcoin..................................... 22 3.3.2. Altcoins .................................... 23 3.3.3. Bitcoin2.0................................... 27 3.3.4. Dapps ..................................... 29 3.3.5. Ethereum ................................... 35 4. Metodología, Tecnología y Herramientas utilizada 39 4.1. Plandetrabajo.................................... 40 4.2. Tecnologíasutilizadas................................. 40 4.2.1. Ethereum ................................... 41 4.2.2. Ganache.................................... 41 4.2.3. Truffle..................................... 42 4.2.4. Solidity .................................... 42 v Índice general 4.2.5. Bootstrap ................................... 43 4.2.6. JavaScript................................... 43 4.2.7. IPFS...................................... 44 4.2.8. Otras...................................... 45 4.3. Herramientasutilizadas................................ 45 4.3.1. Herramientas de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.2. Herramientas para el desarrollo web . . . . . . . . . . . . . . . . . . . . . 47 5. Planificación y Presupuesto 51 5.1. Planificacióntemporal ................................ 52 5.2. Presupuestoeconómico................................ 53 5.2.1. Presupuesto Hardware y Software . . . . . . . . . . . . . . . . . . . . . . 53 5.2.2. RecursosHumanos .............................. 54 5.2.3. Método de puntos de función . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.4. MétododeCOCOMOII........................... 58 5.2.5. Comparativas de los presupuestos . . . . . . . . . . . . . . . . . . . . . . 61 5.3. Costerealdelproyecto................................ 62 6. Análisis 65 6.1. Actoresdelsistema.................................. 66 6.2. Requisitosdeusuario................................. 68 6.2.1. Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2.2. Especificación de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 72 6.3. Requisitos de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.3.1. Modelo conceptual de datos . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.3.2. Diccionariodedatos ............................. 86 7. Diseño 91 7.1. Arquitecturalógica.................................. 92 7.2. Arquitecturafísica .................................. 95 7.3. Flujodelaaplicación................................. 96 7.3.1. Diagramas de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 7.4. Diseñodelainterfaz ................................. 99 8. Implementación 111 8.1. Estructuradelproyecto................................113 8.2. Funcionamiento de la DAPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 9. Pruebas 117 9.1. Pruebasdecajablanca................................118 9.2. Pruebasdecajanegra ................................118 10.Manuales 125 10.1.Manualdeinstalación ................................126 10.2.Manualdeusuario ..................................127 10.2.1.Mapadenavegación .............................127 10.2.2. Uso de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 vi Índice general 11.Problemas, conclusiones y trabajos futuros 147 11.1.Problemassurgidos..................................148 11.2.Conclusiones......................................149 11.3.Trabajosfuturos....................................149 Webgrafía 151 vii Índice de tablas 6.21.EntidadIPFS..................................... 87 6.22.EntidadProductModel................................ 88 7.1. DiseñoinicioPC ...................................100 7.2. DiseñoinicioTablet..................................101 7.3. Diseño inicio Smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.4. DiseñomenúTablet..................................103 7.5. DiseñomenúSmartphone ..............................104 7.6. DiseñomenúTablet..................................105 7.7. Diseño pantalla detalle de un producto . . . . . . . . . . . . . . . . . . . . . . . 106 7.8. Diseño pantalla detalle de un producto en etapa de revelar . . . . . . . . . . . . 107 7.9. Diseño pantalla detalle de un producto en etapa de finalizar . . . . . . . . . . . 108 9.1. CP-01-Añadirproducto...............................119 9.2. CP-02 - Visualizar productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 9.3. CP-03 - Visualizar un producto . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 9.4. CP-04-Hacerunapuja ...............................120 9.5. CP-05-Hacerunacompra..............................120 9.6. CP-06-Revelarunapuja ..............................121 9.7. CP-07 - Finalizar subasta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 9.8. CP-08 - Enviar dinero al vendedor . . . . . . . . . . . . . . . . . . . . . . . . . . 121 9.9. CP-09 - Enviar dinero al comprador . . . . . . . . . . . . . . . . . . . . . . . . . 122 xiv Índice de tablas . 1 Índice de tablas 2 Capítulo 1 Introducción 3 Capítulo 1. Introducción En este capítulo se va a presentar una introducción y se expondrán las razones que han motivado la elección y realización del proyecto. 1.1. Introducción La creación de Internet ha transformado la vida para gran parte del mundo, permitiendo la reducción de costes en investigación gracias a la enorme cantidad de información gratuita que ofrece, facilitando la comunicación entre personas gracias al correo electrónico y las redes sociales y ofreciendo gran cantidad de posibilidad de entretenimiento para los usuarios. Pese a esta gran revolución, Internet presenta ciertas limitaciones. Muchos de los servicios que usamos a diario en Internet requieren que el usuario se conecte a un servidor para acceder a una aplicación en concreto. Por ejemplo, para acceder a páginas como Google o Facebook hay que pasar por alguno de los servidores en donde están alojados. Esto supone que muchas de las aplicaciones y servicios online que usamos cada día están centralizados. La organización de la red según esta estructura conlleva varios problemas. El primer problema es el de la seguridad, si un servidor sufre un ataque, generalmente suele poner en peligro a todos sus usuarios. El segundo problema es el de la confianza, los usuarios no saben qué ocurre detrás de la aplicación una vez ha mandado sus peticiones. En una sociedad donde cada vez se confía más información sensible a estos sistemas, estos problemas pueden suponer grandes pérdidas para los usuarios. Esta realidad ha forzado a que los usuarios que desean realizar transacciones por Internet necesiten de una tercera parte que garantice la seguridad de la transacción, siendo representado este rol normalmente por un banco. Estos sistemas que actúan como intermediarios almacenan la información de los usuarios, invadiendo así su privacidad y además suelen cobrar comisiones. De este contexto surgió la tecnología de la cadena de bloques o Blockchain, ya que permite que los usuarios lleguen a un consenso de manera distribuida y segura sin necesidad de un servidor central. Años después, Ethereum supo aprovechar esta tecnología para permitir el desarrollo de aplicaciones distribuidas a todo tipo de usuarios con conocimientos técnicos. Por lo tanto, podemos definir Blockchain como un tipo de base de datos distribuida que funciona como un libro de cuentas que va almacenando cualquier tipo de transacción realizada y que será verificada a través de consenso entre la mayoría de los participantes de la red. Es importante señalar que cuando hablamos de transacción no nos referimos a algo monetario, sino a un intercambio de información. Aunque existen muchas plataformas que trabajan dentro del paradigma Blockchain (Bitcoin, Eris, Ethereum, Hyperdeledger... .), nosotros hemos elegido Ethereum. Ethereum es una plataforma Blockchain, en la que aquellas aplicaciones basadas en transacciones pueden ser implementadas. Además, no sólo provee la metodología para realizar dichas aplicaciones, sino que también ofrece programas de desarrollo para que cualquier persona pueda llevarlas a cabo. Uno de los principales problemas a la hora de llevar a cabo una transacción es la desconfianza que puede surgir entre los usuarios implicados. Esta desconfianza se debe a muchos factores: desde una separación geográfica, cambio de moneda o incluso, situación financiera del país de alguno de los intervinientes. Ethereum nace para poner fin a estos problemas, creando un sistema de transacciones pseudo-anónimas, seguras y con un lenguaje completo, no ambiguo y accesible para cualquier persona. 4 1.2. Motivación Ethereum cuenta con su propia criptomoneda, el Ether. Este tipo de moneda, no se utilizada únicamente para realizar transacciones de valor monetario, sino que también es utilizada a la hora de desplegar contratos inteligentes. Está tecnología cuenta con una gran cantidad de aplicaciones, pero en este trabajo nos centraremos en su uso para la creación de dichos contratos inteligentes (smart contracts) y propiedades inteligentes (smart property) sobre la red de Blockchain, de tal forma que se encargue automáticamente de otorgar el cambio del bien en forma de propiedad inteligente según el dinero acordado en forma de criptomoneda, a través del contrato inteligente. En resumidas cuentas, se quiere conseguir que cuando el evento A suceda, entonces la consecuencia B se ponga en marcha de forma automática, sin requerir de ningún intermediario de confianza como podría ser una notaría, consiguiendo ahorrar tiempo y costes significativos. De esta forma queremos conseguir una mejor experiencia entre compradores y vendedores, consiguiendo una mayor seguridad, lo que implicará usuarios más contentos y la captación de nuevos clientes. 1.2. Motivación El propósito principal de este proyecto nace al tener conocimiento de está tecnología y ver su gran potencial. Por ello me decidí a intentar desarrollar una aplicación de compra/venta a través de subastas con un notario virtual, el smart contract, que será el encargado de cambiar la propiedad del producto y dar el dinero al vendedor una vez se cumpla lo acordado en el smart contract, ni antes ni después, y si alguno incumple algún punto, se podrá reembolsar el dinero. Esta plataforma de venta a través de pujas pretende ser innovadora a la hora de crear una relación entre vendedores y compradores más fiable, ya que el contrato es público y no se puede alterar una vez está registrado dentro del Blockchain de Ethereum. De está manera, cualquier persona puede poner productos a la venta y pujar por los productos que hay en venta y no sean suyos. Esta plataforma es de software libre, gratuita y carece de un servidor centralizado. 1.3. Objetivos y alcance El objetivo principal de este proyecto es el diseño e implementación de una DAPP o aplicación descentralizada, con la que se pueda interactuar a través de una aplicación web. Este objetivo tiene asociados los siguientes subobjetivos: 1. Aprender y experimentar lo que son las aplicaciones distribuidas y las criptomonedas usando lenguajes de programación especiales para ello, como es Solidity. 2. Promover una forma de compra/venta entre particulares de una forma innovadora y sin estructuras centralizadas. 3. Sentar las bases para una gran diversidad de trabajos futuros, ya que, es una tecnología innovadora y con mucho futuro en la que hay una gran cantidad de posibles aplicaciones. Esta aplicación podrá ser utilizada por cualquier usuario con unos conocimientos básicos sobre el manejo de Internet. Su navegación será sencilla e intuitiva gracias al diseño de una interfaz limpia y bien definida, diseñada para poder acceder a ella desde cualquier dispositivo. 5 Capítulo 1. Introducción La innovación más grande es que vamos a pasar de construir una APP que es lo que se conoce actualmente, a construir una DAPP. La diferencia más grande es que, una APP esta centralizada y dirigida por una empresa la cual tiene el control total de la aplicación y puede desaparecer, mientras que una DAPP esta descentralizada y el control le tienen los propios usuarios que usan la aplicación la cual nunca va a desaparecer y en la cual ellos son los dueños de su información. Más adelante se explicara con más detalle lo que es una DAPP. Al ser una DAPP y gracias al uso de Blockchain, los usuarios no tendrán que registrarse, ni ceder ningún dato significativo, por lo que no correrán peligro ninguno de sus datos y es uno de los principales atractivos de la aplicación. Pretende ser una aplicación que dote de confianza a los usuarios sin ser una aplicación centralizada, sino que sea una aplicación descentralizada de usuarios para usuarios integramente, creando un mercado de compra/venta entre profesionales y particulares. El modelo de negocio a seguir que se ha pensado, es una mezcla entre el modelo de negocio de Wallapop y el modelo de negocio de Ebay, intentando coger lo mejor de cada uno de ellos. La idea principal es centrarse en la expansión internacional y la captación de usuarios, sin un modelo de negocio los primeros 3 años. En esta primera etapa el único ingreso que vamos a tener va a ser el generado por ventas directas en las que no haya pujas o las ventas en las cuales nosotros actuemos como un árbitro más de la aplicación. En está fase la única comisión que hay por ventas es el 1% de la venta que va al árbitro, y el 99% restante al vendedor, en caso de una venta exitosa. Para poder ser un usuario de tipo árbitro y beneficiarte de este premio, tendrás que dejar 5 ETH a modo de fianza, esto hará que los usuarios quieran usar nuestra aplicación para vender y comprar gracias a la confianza que da y para ser árbitro y finalizar subastas y beneficiarte de la pequeña comisión que te llevas. En la segunda fase, una vez alcanzado una extensión y un número de usuarios activos atractivo en la aplicación, se abrirán las puertas a los anuncios de terceros para ganar algo más de dinero, pero sin ensuciar la web. En la tercera parte, de nuestro modelo de negocio añadirá una opción a la hora de añadir los productos para que puedan ser patrocinados y de está manera que salgan arriba, que se renueven cada x tiempo solos y que más gente los pueda ver, y se añadirá una opción para usuarios profesionales, los cuales podrán crear una especie de tienda en nuestra aplicación para vender. De esta manera mejoraríamos el modelo actual de negocio de Wallapop, el cual no dota de confianza una venta a no ser que la venta se haga en mano, así podríamos unir a personas de todo el mundo y no de una zona geográfica concreta solo. Del modelo de negocio de eBay nos hemos quedado con el modelo de subastas, aunque no es exactamente igual, ya que en nuestro caso se trata de una subasta a ciegas, es decir, tu lanzas una única puja que nadie va a conocer y el resto de usuarios igual, y una vez que acaba el tiempo de lanzar subastas se revelan las pujas que ha habido y la más alta es la ganadora y como premio el precio del producto será el valor de la segunda puja más alta. Las pujas tienen que estar comprendidas entre el precio de comprar ahora que ha definido el vendedor, que es el precio máximo del productos y la puja mínima. También del modelo de negocio de eBay hemos cogido la idea de crear negocios online para nuestra tercera parte de modelo de negocio, en la cual los usuarios podrán crear e-commerce sin la necesidad de tener una tienda física, ni un stock y lo más importante sin realizar una gran inversión. 6 1.4. Estructura del proyecto 1.4. Estructura del proyecto En este apartado se describen los diferentes capítulos de este documento. La memoria contará con 11 capítulos con sus respectivas secciones y un apartado de webgrafía. A continuación se realizará una breve descripción del contenido de cada uno de los apartados de la memoria. Capítulo 1 - Introducción: en este capítulo, se expondrá una pequeña introducción al proyecto seguido de las razones por las cuales se a elegido realizar el proyecto. Además se explicarán los objetivos que se desean cumplir junto al alcance del proyecto. Capítulo 2 - Estado del arte: aquí se pretende detallar un pequeño estudio realizado sobre aplicaciones similares a la propuesta. Para ello, en primer lugar, se describirán las aplicaciones estudiadas y finalmente, se realizará una comparación de las funcionalidades con la aplicación propuesta. Capítulo 3 - Introducción a la tecnología del Blockchain y el origen de Ethereum: en este tercer capítulo, haré una introducción a la tecnología que voy a utilizar, para comprender mejor los conceptos, junto con el origen de las criptomonedas y porque son interesantes, terminando con el origen de Ethereum. Capítulo 4 - Metodología y Tecnología utilizada: explicaré con detalles la metodología y el plan de trabajo utilizado para la organización y el desarrollo del proyecto, viendo una pequeña descripción de las tecnologías y las herramientas utilizadas. Capítulo 5 - Planificación y Presupuesto: en este capítulo, detallaré la planificación temporal llevada a cabo, junto a los distintos presupuesto de la aplicación, viendo con una comparativa de ellos, y por último, se expondrán los costes reales del proyecto. Capítulo 6 - Análisis: aquí se muestra el análisis previo a la implementación de la aplicación web. Capítulo 7 - Diseño: en el séptimo capítulo, se pretende exponer el trabajo de diseño previo realizado. Se tratará tanto la arquitectura lógica como la física, al igual que el diseño de algunas de las pantallas de la interfaz de usuario. Capítulo 8 - Implementación: en este capítulo, se procederá a la explicación del desarrollo llevado a cabo a lo largo del proyecto. Capítulo 9 - Pruebas: aquí se expondrán las pruebas realizadas sobre el resultado de la implementación del sistema. En primer lugar se verán las pruebas de caja blanca y a continuación, las pruebas de caja negra. Capítulo 10 - Manuales: en esté capítulo, se redacta el manual de instalación y el manual de usuario. Capítulo 11 - Problemas, conclusiones y trabajos futuros: se realiza una revisión del trabajo realizado, exponiendo en primer lugar los problemas encontrados, seguidos de las conclusiones y terminando con un apartado de trabajos futuros para mejorar el proyecto. Webgrafía: en este apartado se recogen todas las web a las que se ha hecho referencia o se ha consultado información para la realización del proyecto. 7 Capítulo 1. Introducción 8 Capítulo 2 Estado del arte 9 Capítulo 2. Estado del arte 16 Capítulo 3 Introducción a la tecnología de Blockchain y el origen de Ethereum 17 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum La Blockchain es una tecnología muy reciente que se empezó a popularizar a partir del año 2009 gracias a la aparición del Bitcoin. En esta sección se presentan los conceptos más importantes que se deben conocer y la evolución de esta tecnología. 3.1. Conceptos más importantes sobre Blockchain En está sección veremos como es la arquitectura Blockchain y terminaremos con una definición de Blockchain y sus tipos. 3.1.1. Arquitecturas Distribuidas Cuando hablamos de Ethereum o el Blockchain, una de los conceptos más interesantes es el relacionado con su arquitectura distribuida, ya que con ella, se elimina la centralización. Existen tres tipos importantes de estructuras: Estructura Centralizada: Toda la estructura está gestionada por un solo nodo y sus usuarios pertenecen a la misma comunidad. Se utiliza principalmente en servicios web, alojados en un servidor centralizado por el que tienen que pasar todas las personas que quieran acceder a ella (e.g. Facebook, Wikipedia, Github). Estructura Descentralizada: La infraestructura está dividida en varios nodos operativos que funcionan como su propia estructura centralizada, fragmentado el servidor central en pequeños servidores distribuidos. Cada uno de estos tiene su propio dueño y su comunidad. A pesar de esto, cualquier usuario de la estructura puede acceder a los datos de otros independientemente del nodo al que pertenezcan (e.g. GNU Social, Buddycloud, Diaspora). Estructura P2P (Peer to Peer): Es una estructura totalmente distribuida, particionando los trabajos y la información entre los usuarios de la red llamados “Peers”. Cada uno de estos tienen los mismos privilegios en la infraestructura. Cada usuario controla su aportación a la red distribuida y generalmente todos pertenecen a la misma comunidad ( e.g. BitTorrent, Twister, Bitcoin, Ethereum). 18 3.1. Conceptos más importantes sobre Blockchain Figura 3.1: Representación gráfica de las arquitecturas de red Uno de los ejemplos más importantes de una arquitectura distribuida (P2P) es el de Bitcoin, en el que todos los usuarios ven todas las transacciones y tienen los mismos derechos. Ethereum utiliza la arquitectura P2P, al igual que Bitcoin, consiguiendo así que todo el software desarrollado en este lenguaje sea totalmente libre y descentralizado, ya que todos los usuarios de la red tienen acceso a todos los contratos de la cadena de bloques y al código fuente de estos. 3.1.2. Blockchain Blockchain o la cadena de bloques es un tipo de base de datos descentralizada que almacena la información en forma de bloques, en cada bloque se guarda información sobre las transacciones realizadas, el tiempo en el que el bloque fue añadido a la cadena de bloques y el hash del bloque anterior. De esta forma conseguimos que la validez de las transacciones futuras pueda ser verificado consultando el último estado de la dirección de envío. 19 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum Figura 3.2: Representación de Blockchain [41] Un ejemplo de como funcionaría Blockchain sería la siguiente imagen: Figura 3.3: Funcionamiento de Blockchain [40] La inclusión del próximo bloque de la cadena se realiza mediante un sistema de prueba de trabajo, conocido como “minar ”. [7] La minería permite a los nodos de la red alcanzar un consenso de formar distribuida. Los diferentes nodos de la red compiten mediante potencia de cálculo computacional para resolver un problema matemático. El nodo que resulta ganador es el encargado de formar el siguiente bloque con las transacciones pendientes de verificar y de añadirlo a la cadena de bloques. Este sistema permite la creación de nueva moneda mediante la generación del coinbase [17] de cada bloque, una pequeña cantidad de moneda que va a parar al generador del bloque junto con la comisión pagada por los usuarios cuyas transacciones enviadas han sido influidas por él. 20 3.2. Criptomonedas Actualmente, la tecnología de Blockchain va madurando incrementalmente y con ella, las plataformas que la implementan. Hoy en día podemos clasificar las redes de Blockchain por sus generaciones, siguiendo la siguiente clasificación: Primera generación: se basa en la idea de realizar un sistema de registro compartido o un “ledger ”donde poder ver las transacciones. Segunda generación: se extiende la idea anterior donde las plataformas crean una red donde se puedan utilizar criptomonedas y donde se almacenan las relaciones del crédito y divisas definidas por los usuarios. Tercera generación: plataformas cuyo propósito principal es la creación de aplicaciones descentralizadas usando como tecnología subyacente las plataformas de segunda generación. [13] 3.2. Criptomonedas En está sección hablaremos del origen de las criptomonedas, ya que son las que dieron a conocer la tecnología Blockchain. 3.2.1. Moneda Descentralizada Todo empezó en la década de los 80 y los 90, que es cuando empiezan a aparecer las formas de pago descentralizadas como e-cash [2], en su mayoría dependen de una primitiva criptografía conocida como primitiva ciega de Chaum (Chaumian blinding). Esta ofrecía una moneda con un alto nivel de privacidad, pero que no llegaría a despegar debido a su dependencia de un intermediario centralizado. Fue entonces cuando empieza a surgir el concepto del “dinero electrónico ánonimo”. La primera mención del concepto que hoy conocemos como criptomoneda aparece en 1998 por Dai Wei, con su propuesta de dinero electrónico llamada B-money [5],por lo que se puede decir, que fue uno de los pioneros en la creación de una moneda electrónica descentralizada. Dai Wei proponía con B-money un “sistema de efectivo electrónico distribuido y anónimo”. Surge la idea de la creación de dinero mediante la resolución de puzles computacionales, así como el consenso descentralizado, pero la propuesta se mostró escasa en los detalles de cómo podría ser implementado éste consenso descentralizado en la práctica. En 2005, Hal Finney introdujo el concepto de “pruebas reutilizables de trabajo”, un sistema que utilizaba algunas ideas de B-money junto con los rompecabezas computacionalmente difíciles de romper de Adam Back de tipo Hashcash [3], para volver a crear un concepto de criptomoneda, pero que una vez más se quedaría escasa al apoyarse en el uso de informática de confianza en el backend. A partir de las ideas de Dai Wei han surgido otras propuestas como Bit gold [6] para mejorar la implementación de la criptomoneda haciendo uso de RPOW [43], una extensión del sistema de prueba de trabajo de Hashcash . Pero no fue hasta el año 2009 cuando se implantó por primera vez una moneda descentralizada, cuando Satoshi Nakamoto publicó la primera versión del Bitcoin [10]. Esta moneda tenía como primer objetivo crear un sistema de pagos electrónicos completamente descentralizado, 21 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum empleando las pruebas criptográficas en lugar de la confianza mediante un sistema proof of work o prueba de trabajo. Este mecanismo criptográfico resolvía dos problemas: Primero, proporciona un algoritmo de consenso simple y moderadamente eficaz, permitiendo que los nodos de la red, se pongan de acuerdo colectivamente, en un conjunto de actualizaciones perfectas del estado actual del libro contable de Bitcoin. Segundo,proporciona un mecanismo para permitir la entrada libre en el proceso de consenso, resolviendo el problema político de decidir quién va a influir en el consenso, y evitando al mismo tiempo los ataques de tipo Sybil. Lo hace mediante la sustitución de dos barreras: La barrera formal para participar, es decir, el requisito de estar registrado como una entidad única en una lista particular. La barrera económica, el peso de un solo nodo en el proceso de votación por consenso es directamente proporcional a la potencia de cálculo de la que el nodo dispone. Desde entonces, se ha propuesto un enfoque alternativo, llamado prueba de participación (proof of stake), en donde el peso de un nodo debe ser proporcional a su posesión de moneda y no a sus recursos computacionales; la discusión sobre los méritos relativos de los dos enfoques van más allá del alcance de este documento, pero cabe señalar que ambos pueden ser utilizados y servir como columna vertebral de una criptomoneda. [32] 3.3. Orígenes de Ethereum En esta sección veremos la historia y la evolución que se ha seguido y que ha dado lugar a Ethereum. 3.3.1. Bitcoin Bitcoin [9] es una moneda, como el Euro o el Dólar Estadounidense, que sirve para intercambiar bienes y servicios, sin embargo, esta es una divisa electrónica omoneda virtual, que presenta características novedosas y destaca por su eficiencia, seguridad y facilidad de intercambio. A diferencia de otras monedas, se trata de una moneda descentralizada, es decir, que nadie la controla, ya que, Bitcoin no tiene un emisor central como tienen el Euro o los dólares, sino que está criptomoneda es producida por personas y empresas de alrededor del mundo que dedican gran cantidad de recursos a la minería de bloques. El Bitcoin se basa en un sistema de transacciones peer to peer, en el que hay un estado, que representa el status de todas las transacciones de los dueños del dinero. Un ejemplo muy sencillo y fácil de entender es imaginarse Bitcoin como una gran pecera donde, desde fuera, puedes mover el pez que hay dentro si posees las claves necesarias para ello, pero nunca nadie podrá introducir o sacar más peces de dicha pecera, por lo que, será inalterable la cantidad total de peces de la pecera, pero si podrá cambiar la posesión de estos, quedando registrado en forma de transacciones dentro de los bloques. [23] 22 3.3. Orígenes de Ethereum Una vez visto el ejemplo, vemos que de está forma, la posesión de los Bitcoin no implica tener una moneda virtual, sino la existencia de un listado de transacciones en el cual, la ultima persona es el actual beneficiario. En la siguiente imagen se puede ver un ejemplo del funcionamiento de las transacciones en Bitcoin y cómo estas van cambiando su estado mediante las transferencias de Bitcoin. Figura 3.4: Funcionamiento de las transacciones en Bitcoin En el ejemplo podemos observar, que hay un “estado ”inicial (que consiste en el estado de la propiedad de todos los Bitcoin existentes) y una “función de transición de estado ”que toma un estado (inicial) y una transacción y emite un nuevo estado, que es el resultado. [32] El soporte de todo este proceso es el sistema Blockchain ocadena de bloques, en donde un registro público y accesible por todos los nodos de la red almacena el listado de todas las transacciones. Con ello se consigue que sea prácticamente imposible falsear una transacción, ya que, si alguien quiere engañar a un nodo para hacerle creer que tiene más dinero del que realmente posee, al sincronizarse la información que contiene dicha transacción, esta sería visible por el resto de nodos de la red y estos la rechazarían automáticamente al no poder demostrar la posesión de dicho dinero. 3.3.2. Altcoins Bitcoin es un proyecto de código abierto, y su código ha sido utilizado como la base para muchos otros proyectos de software. La forma más común de software generado a partir del código fuente de Bitcoin son monedas alternativas descentralizadas, que utilizan los mismos bloques de construcción básicos para implementar las monedas digitales, que se conocen como Altcoins. En Febrero de 2011 [11], con el aumento del valor de los Bitcoins, se tomo la decisión de crear una criptomoneda paralela con el objetivo de realizar pruebas sin poner en peligro la red de Bitcoin. Así surge Bitcoin Testnet [46], considerada la primera Altcoin. Bitcoin Testnet comparte las mismas características que Bitcoin, ya que, su objetivo es servir como una zona de pruebas. Actualmente estamos en la versión Testnet3. Más tarde, en Abril de 2011 se creó Namecoin [28], con el objetivo de crear un sistema DNS descentralizado que usase la base de datos de Bitcoin directamente. El registro sin censura alguna de dominios .bit es la principal función de Namecoin. Este es un funcionamiento similar a .com o .net pero es totalmente alternativo e independiente de la ICANN, el organismo que controla los nombres de dominio de nivel superior [36]. Poco después, en Octubre de ese mismo año, se creo Litecoin [8], que es una criptomoneda similar a Bitcoin pero con algunas características diferentes, como pueden ser, un mayor número 23 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum de unidades, menos tiempo entre cada bloque y un algoritmo diferente para alcanzar el consenso entre los nodos de la red. Desde entonces, han ido surgiendo nuevas criptomonedas, hasta llegar al número actual de 688 Altcoin [4]. La mayoría de estas criptomonedas son una copia de Bitcoin o Litecoin que han modificado alguna característica, como puede ser, el número de monedas en circulación o el tiempo que tarda en confirmarse una de las transacciones, pero hay algunas pocas que han innovado mediante la creación de nuevos algoritmos de minado y la inclusión de nuevas funcionalidades. Figura 3.5: Representación de criptomonedas existentes por su volumen [19] La idea principal que ha surgido con los Altcoins, han sido los diferentes métodos de alcanzar un consenso sobre el nodo siguiente en verificar la validez de las transacciones mediante la inclusión de este al Blockchain y la generación de criptomoneda. A continuación vamos a ver las diversas formas y conceptos de como se verifican las transacciones y se generan bloques. Proof of Work: Prueba de trabajo se define como una medida económica para evitar los ataques de denegación de servicio y otros abusos del servicio, como el correo no deseado en una red, requiriendo algún trabajo del solicitante del servicio, lo que generalmente significa tiempo de procesamiento en una computadora. Monedas como Bitcoin usan Prueba de trabajo. Puesto simplemente en términos de criptomoneda, esto significa que los nodos de red requieren cálculos para formar un libro mayor distribuido. Este proceso se llama minería. Un libro mayor distribuido, es un sistema descentralizado que puede acordar y realizar un seguimiento del monto correcto que tiene una billetera al proporcionar un historial de cada transacción. 24 3.3. Orígenes de Ethereum Debido a la naturaleza de cálculo extenuante de Prueba de trabajo, puede convertirse en un proceso costoso. [48] Proof of Stake: Proof of Stake es una alternativa a Prueba de trabajo,es un protocolo de consenso distribuido para redes distribuidas, que asegura una red de una criptomoneda, mediante la petición de pruebas de posesión de dichas monedas. Con PoS la probabilidad de encontrar un bloque de transacciones, y recibir el premio correspondiente, es directamente proporcional a la cantidad de monedas que uno tiene acumuladas (evitando así que la confianza venga dada por la cantidad de trabajo invertida). Se basan en la suposición de que quienes poseen más unidades de una moneda basada en PoS, están especialmente interesados en la supervivencia y el buen funcionamiento de la red que otorga valor a dichas monedas, y por tanto, son ellos los más indicados para cargar con la responsabilidad de proteger al sistema de posibles ataques. Es por eso que el protocolo los premia con una menor dificultad para encontrar bloques (es inversamente proporcional al número de monedas que demuestren poseer). •Selección de bloques aleatorizados: Nxt y Blackcoin usan aleatorización para predecir el siguiente creador de bloque. Lo hacen utilizando un algoritmo para buscar el valor de hash más bajo en combinación con el tamaño de la apuesta. Como todas las apuestas son públicas, los nodos pueden predecir qué apuesta creará el próximo bloque. •Selección de edad de monedas: La edad de la moneda se refiere a la edad de las entradas de la transacción. La edad de la moneda es igual a la cantidad de monedas enviadas por la edad promedio de estas monedas. La edad se mide en días. La edad se restablece a cero cada vez que se envía una moneda Y cada vez que una moneda proporciona una firma. La edad de la moneda se puede usar para calcular tarifas obligatorias, bloquear recompensas o corregir metas. Las monedas no gastadas deben esperar 30 días antes de que puedan comenzar a competir para generar el siguiente bloque. Monedas como Novacoin y Peercoin utilizan este método. La recompensa por replanteo provendrá de monedas nuevas generadas al inflar el suministro actual, llamado acuñación, o pueden provenir de tarifas de transacción recicladas, llamadas falsificación. Variaciones de Proof of Stake •Proof of Stake Anonymous (PoSA): Presentado por primera vez por Cloakcoin , las transacciones son encubiertas por otros usuarios que reciben una recompensa por ayudar a la anonimización de la transacción. Otros usuarios proporcionan entradas y salidas a la transacción y hacen imposible determinar la fuente y el destino de la transacción. •Delegated Proof of Stake (DPoS): Delegated Proof of Stake se vio por primera vez en Bitshares blockchain. La forma en que funciona es que los usuarios voten por “delegados”a quienes se les da el poder de obtener ganancias al ejecutar un nodo 25 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum Ambas son opciones que tienen sus riesgos, en el caso de los discos duros personales, estos pueden ser hackeados y los datos saldrían a la luz; en el caso de los servicios de la nube, nuestra cuenta puede ser hackeada también, si se hackea a la empresa que proporciona ese servicio, como ha ocurrido ya en incontables ocasiones.[30] Además, si esta empresa desaparece, nuestros datos también lo harán. Sin embargo, con las Dapps, el almacenar datos en una Blockchain hace que estos datos permanezcan inmutables, es decir, una vez que se registran esos datos ya no se pueden borrar. Figura 3.9: Funcionamiento de una Dapps [1] Los datos permanecen en la cadena de bloques de una forma encriptada, es decir, son ilegibles para cualquier persona excepto para sus propietarios. Además, el carácter distribuido de la cadena de bloques, hace que esos datos residan en cada ordenador de la red Ethereum, por lo que si desaparecieran de un ordenador, existen muchas otras copias de seguridad. Como único punto negativo observamos que almacenar una gran cantidad de datos en la cadena de bloques puede resultar bastante costoso y además aumenta de forma notable el tamaño de la misma, aunque ya se está trabajando para mejorarlo y encontrar soluciones escalables. Confianza: Cuando usamos una aplicación web, podemos ver el código que se ha usado a través de las herramientas de inspección del navegador. De esta forma, el usuario puede verlo desde el frontend. Sin embargo, la interacción del frontend con el backend es algo que no podemos ver a simple vista. Con las Dapps, los usuarios pueden estar tranquilos, ya que, pueden inspeccionar el código del contrato inteligente basado en Ethereum a través de su identificador. 32 3.3. Orígenes de Ethereum En la siguiente imagen vemos un contrato inteligente en la Blockchain Mainnet de Ethereum. Figura 3.10: Contrato inteligente en el Mainnet de Ethereum De esta manera se puede verificar el código fuente y ver si tiene fallos de escritura o seguridad, enviando correcciones para que no se puedan robar fondos o información depositada en la Dapps. Esto hace crecer el sentimiento de confianza y seguridad de los usuarios. Características de una Dapps Descentralización: Lo primero y más importante de todo, una Dapps tiene que ser descentralizada, es decir, tiene que funcionar de forma autónoma sin que ninguna entidad la controle, dejando todo el poder de decisión sobre la misma en su comunidad de usuarios. Código abierto (Open Source): una Dapp tiene que ser 100 % código abierto. Esto significa que el código fuente bajo el que está programada la Dapp está abierto a posibles modificaciones y mejoras por parte de los usuarios, todo lo contrario que la gran mayoría de aplicaciones que se utilizan hoy en día, en las que sólo los programadores dentro de la empresa pueden modificar y siempre bajo la supervisión de sus jefes. Esas mejoras propuestas por parte de la comunidad que usan la Dapp deben decidirse por consenso de la gran mayoría antes de hacerse efectivas. Blockchain: Los datos y registros del funcionamiento de la Dapp deben ser almacenados de forma criptográfica a través de un Blockchain público, para así añadir transparencia y seguridad como cualidades de la aplicación descentralizada. 33 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum Protocolo: Si la Dapp está basada en Blockchain, eso significa que la información de las operaciones realizadas dentro de la aplicación tiene que ser almacenadas en bloques y estos tienen que ser verificados. Esto se da de acuerdo con un protocolo que actúe como prueba de que esas verificaciones son llevadas a cabo. Este protocolo puede estar basado en el algoritmo PoW o en PoS, vistos anteriormente. Tipos de Dapps Para esta clasificación nos basaremos en base a si poseen su propia Blockchain o utilizan la Blockchain de otra Dapps. Aplicaciones descentralizadas de tipo I Estas son las que tendrían su propia Blockchain independiente. En este caso, y como hemos visto ya, Ethereum sería una de esas Dapps, aunque la más famosa dentro del mundo de las criptomonedas sea Bitcoin. Litecoin, Dash, Monero y muchas otras Altcoin también entrarían en esta clasificación. Aplicaciones descentralizadas de tipo II La característica principal de las Dapps de tipo II es que utilizan la Blockchain de una aplicación descentralizada de tipo I en vez de tener ellas una propia. Este tipo de Dapps son protocolos que funcionan ya sea con sus propios tokens o con los tokens de la Blockcahin en la que operan. Un ejemplo de este tipo de Dapps sería Omni Layer. Esta aplicación descentralizada está construida sobre la cadena de bloques de Bitcoin y es una plataforma que sirve para la creación y el comercio de activos digitales y criptomonedas. Al actuar sobre la cadena de bloques de Bitcoin, las transacciones de Omni son también transacciones de Bitcoin. Otro ejemplo sería Raiden Network [49], este basado en la cadena de bloques de Ethereum. Esta plataforma ofrece una solución de escalabilidad dentro de la red de Ethereum a la hora de permitir pagos casi instantáneos y de bajo coste. La idea principal de Raiden Network, es aprovechar una red de canales de pago que permitan transferir de forma segura el valor sin necesidad de implicar a la Blockchain de Ethereum en cada transferencia, lo cual multiplicaría su velocidad. Aplicaciones dencentralizadas de tipo III Por último, las Dapps de tipo III son las que utilizan el protocolo de una aplicación descentralizada de tipo II como las que acabamos de ver. Estas aplicaciones, también funcionan con sus propios tokens digitales o bien con los de las Dapps en las que se basan, al igual que pasaba en las Dapps de tipo II. Una Dapp de tipo III podría ser Safe Network [50], que utiliza el protocolo de Omni Layer para emitir su propia criptomoneda, el Safecoin, que a se vez puede utilizarse para adquirir almacenamiento distribuido de archivos, por ejemplo. 34 3.3. Orígenes de Ethereum 3.3.5. Ethereum Ethereum es una plataforma abierta de Blockchain que permite a cualquier persona crear y utilizar aplicaciones descentralizadas que funcionan con la tecnología Blockchain. Al igual que Bitcoin, nadie controla ni posee Ethereum, es un proyecto de código abierto construido por muchas personas en todo el mundo. Pero a diferencia del protocolo de Bitcoin, Ethereum fue diseñado para ser adaptable y flexible. Es fácil crear nuevas aplicaciones en la plataforma Ethereum, y con el lanzamiento de Homestead, ahora es seguro para cualquiera usar esas aplicaciones. [52] En 2014, los fundadores de Ethereum, Vitalik Buterin, Gavin Wood y Jeffrey Wilcke, comenzaron a trabajar en una cadena de bloques de próxima generación que tenía la ambición de implementar una plataforma de contratos inteligentes general, totalmente confiable. Ethereum incorpora muchas características y tecnologías que serán familiares para los usuarios de Bitcoin, a la vez que introduce muchas modificaciones e innovaciones propias. Mientras que la cadena de bloques de Bitcoin era puramente una lista de transacciones, la unidad básica de Ethereum es la cuenta . El Blockchain de Ethereum rastrea el estado de cada cuenta, y todas las transiciones de estado en la cadena de bloques de Ethereum son transferencias de valor e información entre cuentas. Ethereum usa su propia criptomoneda llamada “ether ”[24]. Para la creación de las aplicaciones descentralizadas lo primero que hay que hacer es escribir el contrato inteligente mediante el código y una vez esté escrito y probado, hay que subirlo a la cadena de bloques, donde el contrato inteligente tendrá una dirección única que le identifique desde la cual se puede interactuar con él. Los smart contracts son abstracciones de programación de alto nivel que se compilan en bytecode EVM y se implementan en el blockchain de Ethereum para su ejecución. Se pueden escribir en Solidity (una biblioteca de lenguajes con similitudes con C y JavaScript), Serpent (similar a Python), LLL (un lenguaje de bajo nivel tipo Lisp) y Mutan (basado en Go, pero obsoleto). También se está desarrollando un lenguaje orientado a la investigación llamado Viper (un lenguaje decidible derivado de Python). Cuentas Ethereum Como hemos dicho en el apartado anterior, la unidad básica de Ethereum es la cuenta. Hay dos tipos de cuentas: Cuentas de propiedad externa (EOA): controladas por claves privadas. Cuentas de contrato: controladas por su código de contrato y solo pueden ser “activadas ”por un EOA. Para la mayoría de los usuarios, la diferencia básica entre estos es que los usuarios humanos controlan los EOA, ya que pueden controlar las claves privadas que dan control sobre un EOA. Las cuentas de contrato, por otro lado, se rigen por su código interno. Si son “controlados ”por un usuario humano, es porque están programados para ser controlados por un EOA con una dirección determinada, que a su vez está controlada por quien tenga las claves privadas que controlan ese EOA. El término popular “contratos inteligentes ”se refiere al código en una cuenta de contrato: programas que se ejecutan cuando se envía una transacción a esa cuenta. Los usuarios pueden crear nuevos contratos implementando código en Blockchain. 35 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum Las cuentas de contrato solo realizan una operación cuando se lo indica un EOA. Por lo tanto, no es posible que una cuenta de contrato realice operaciones nativas, como la generación de números aleatorios o las llamadas API, solo puede hacer estas cosas si se lo solicita un EOA. Esto se debe a que Ethereum requiere que los nodos puedan ponerse de acuerdo sobre el resultado de la computación, lo que requiere una garantía de ejecución estrictamente determinista. De esta manera se consigue que usuarios y contratos se comporten de una manera indistinguible en la red de Ethereum. Para que exista comunicación entre cuentas existen las transacciones. Transacciones El término “transacción ”se utiliza en Ethereum para referirse al paquete de datos firmado que almacena un mensaje para ser enviado desde una cuenta de propiedad externa a otra cuenta en la cadena de bloques. Las transacciones contienen: El destinatario del mensaje. Una firma que identifica al remitente y prueba su intención de enviar el mensaje a través del Blockchain al destinatario. VALUE, es la cantidad de WEI (la unidad más pequeña de Ether) para transferir del remitente al destinatario. Un campo de datos opcional, que puede contener el mensaje enviado a un contrato. STARTGAS, es el valor que representa la cantidad máxima de pasos computacionales que la ejecución de la transacción puede tomar. GASPRICE, es el valor que representa la tarifa que el remitente está dispuesto a pagar por el gas. Una unidad de gas corresponde a la ejecución de una instrucción atómica, es decir, un paso computacional. De esta manera se consigue que si un usuario quiere usar la red Ethereum para subir contratos a la cadena de bloques, tiene que conseguir ether, por lo tanto tiene que minar, lo que contribuye al funcionamiento de toda la red. 36 3.3. Orígenes de Ethereum . 37 Capítulo 3. Introducción a la tecnología de Blockchain y el origen de Ethereum 38 Capítulo 4 Metodología, Tecnología y Herramientas utilizada 39 Capítulo 4. Metodología, Tecnología y Herramientas utilizada En este capítulo se va a presentar la metodología y el plan de trabajo elegido para llevar a cabo el proyecto. Y se dará una pequeña descripción de las tecnologías y herramientas empleadas para desarrollar la aplicación. 4.1. Plan de trabajo Debido a la novedad que supone el proyecto, se utilizará un modelo de desarrollo híbrido, ya que, vamos a combinar el modelo en cascada, añadiendo una parte de prototipado para poder hacer frente a la evolución que tiene esta tecnología. Para ello, seguiremos un conjunto de fases de manera secuencial, estableciendo en cada una de ellas un conjunto de metas, así como un conjunto de actividades, realizando una única iteración de cada una de ellas. Las fases llevadas a cabo han sido: Investigación: durante esta fase se obtendrá el contexto necesario sobre la tecnología y su lenguaje de programación para adentrarnos en esta nueva tecnología y conocer la forma de trabajar con ella. Análisis: durante esta fase se planteará como deben de funcionar las implementaciones, que actores van a actuar con la aplicación y qué resultados se deben obtener, así como los requisitos que se deben cumplir. Programación: en esta fase se inicia la implementación del código, empezando con pequeños programas para aprender como funciona internamente Ethereum. Una vez conocido el funcionamiento de la plataforma, se pasara a realizar el backend y una vez tengamos el backend se realizara el frontend. *Durante está fase nos hemos encontrado con pequeños problemas, ya que, el lenguaje de programación de los contratos inteligentes, Solidity, esta en constante desarrollo y había a veces que actualizaban partes y dejaba de funcionar nuestro proyecto. Para solucionarlo, se realizaron pequeños prototipos en ciclos cortos que se iban mejorando, así según evolucionaba Solidity, podíamos encontrar los fallos e ir consiguiendo el prototipo final. Pruebas: en esta fase se comprobará que los resultados obtenidos de las implementaciones realizadas son los esperados en el análisis y corroborar que la implementación y el funcionamiento se realiza de forma correcta. 4.2. Tecnologías utilizadas Debido a la naturaleza de la tecnología, se ha intentado realizar el proyecto bajo un enfoque de software libre, esto es debido, a que Ethereum es una plataforma para promover las aplicaciones distribuidas en Internet excluyendo servidores centralizados y que es de código abierto, lo más lógico es intentar que todo el software desarrollado sea libre. El proyecto se puede dividir en 2 partes, un contrato inteligente que funciona como backend y una interfaz web que funciona como frontend. Para el desarrollo del contrato se han utilizado las herramientas que nos facilita Ethereum (lenguaje de programación, tecnologías y aplicaciones). Y para la interfaz web se han utilizado tecnologías web del lado cliente (HTML, CSS, JavaScript y Bootstrap). La conexión entre 40 4.2. Tecnologías utilizadas el contrato inteligente y la interfaz web se realiza a través de una librería (Web3) que nos proporciona Ethereum. 4.2.1. Ethereum Lo que es Ethereum lo hemos visto en la sección anterior. Nosotros lo utilizaremos para desarrollar una aplicación descentralizada y segura de compra/venta de una forma sencilla. Se utiliza el Blockchain de Ethereum para que nuestro contrato sea distribuido por toda la red, para que cualquier persona que este en ella pueda interactuar con nuestro contrato. 4.2.2. Ganache Ganache es una cadena de bloques personal para el desarrollo de Ethereum que se puede usar para implementar contratos inteligentes, desarrollar sus aplicaciones descentralizadas y ejecutar pruebas. [54] Está disponible tanto como una aplicación de escritorio como en una herramienta de línea de comandos (anteriormente conocida como TestRPC). Figura 4.1: Funcionamiento de Ganache aplicación de escritorio [54] Podemos observar en la figura 3.1 que hay 4 pestañas disponibles: 1. La pestaña Accounts (Cuentas), muestra las cuentas generadas y sus saldos disponibles, por defecto es de 100 Ether. Es la página que sale por defecto. 2. La pestaña Blocks (Bloques), muestra cada bloque extraído de la cadena de bloques, junto con el gas utilizado y las transacciones. 3. La pestaña Transations (Transacciones), se enumeran todas las transacciones ejecutadas contra la cadena de bloques. 4. La pestaña Logs (Registros), muestra los registros para el servidor, útil para la depuración. 41 Capítulo 4. Metodología, Tecnología y Herramientas utilizada Ganache-cli nos proporciona 10 cuentas con 100 ETH en cada una de ellas para hacer pruebas e interactuar con ellas. En la figura 7.5 podemos ver Ganache-cli en funcionamiento. Figura 4.9: Captura de pantalla de Ganache-cli funcionando NPM NPM es el administrador de paquetes para JavaScript y el registro de software más grande del mundo. Utilizaremos npm en nuestro proyecto para instalar distintas bibliotecas que necesitaremos, administrar dependencias para nuestro proyecto, y con ello conseguir una reutilización de código y facilitarnos el trabajo. ethereumjs-util Utilizaremos la biblioteca de ethereumjs-util para generar el hash de nuestra oferta. ipfs-api Utilizaremos la biblioteca de ipfs-api para interactuar con IPFS a través de la interfaz. mongosee Utilizaremos mongosee, un popular controlador de JavaScript para interactuar con la base de datos MongoDB a través de la aplicación NodeJS. express Utilizaremos Expressjs, que es un framework web simple y minimalista para manejar solicitudes web. Usando Express, hacemos uso de nuestra API para hacer las funciones con muy pocas líneas de código. nodemon Uno de los problemas de utilizar NodeJS para desarrollar la aplicación, es que, debes reiniciar la aplicación si realizamos algún cambio, por ello se utiliza la biblioteca nodemon. Nodemon sirve para monitorear el contenido del archivo y reinicia el servicio cuando detecta que el archivo a sido modificado. 48 4.3. Herramientas utilizadas IPFS La definición la podemos encontrar en el apartado 3.2.7. IPFS en la página 29. Nosotros usaremos IPFS para añadir las imágenes y descripciones de los productos y almacenar su hash para así ahorrar espacio en el Blockchain y que salga más barato minar las transferencias que se vean comprometidas, como por ejemplo, añadir un producto. MongoDB MongoDB es una base de datos NoSQL orientada a documentos, que usaremos para almacenar los productos y hacer consultas sobre ellos, sin tener que recurrir a la Blockchain, lo que llevaría más carga de trabajo y más precio por transferencias. Sublime Text 3 Es una herramienta de edición de textos que sirve para el desarrollo de diferentes archivos (.js, .sol, .css, .html, etc). Y que se ha usado para ir desarrollando todo el proyecto. Figura 4.10: Captura de pantalla de Sublime Text 3 49 Capítulo 4. Metodología, Tecnología y Herramientas utilizada 50 Capítulo 5 Planificación y Presupuesto 51 Capítulo 5. Planificación y Presupuesto En este capítulo se va a presentar la planificación del proyecto. Se describirá la planificación temporal y la estimación presupuestaría sobre la cual se llevará a cabo el proyecto. 5.1. Planificación temporal Como hemos visto en el capítulo anterior, vamos a utilizar un modelo en cascada, con 4 fases (Investigación, Análisis, Programación y Pruebas). A continuación se mostrara la planificación temporal desglosada por fases, así como los días en los que se estima que comience y acabe cada fase. Sumando los días de la planificación, limitados por la fecha de inicio (27/02/2018) y el plazo límite para la convocatoria extraordinaria (16/07/2018) , se estima una duración de proyecto de 100 días contando que son 20 días al mes y 8 horas al día, es decir, a tiempo completo. Se ha obtenido el diagrama de Gantt para esta planificación temporal, con una fecha inicial de 27/02/2018 y fin del 16/07/2018. Figura 5.1: Tabla de la planificación temporal 52 5.2. Presupuesto económico Figura 5.2: Diagrama de Gantt para la planificación temporal 5.2. Presupuesto económico Para llevar a cabo el presupuesto representativo, primero se analizará la planificación temporal y se calcularán los costes en función de los tiempos previstos, posteriormente se utilizarán el método de puntos de función y de COCOMO II. Con ello pretendemos elegir la opción más realista y que mejor represente la relación entre la carga de trabajo realizada en el desarrollo del proyecto y el coste del trabajo. Lo primero que vamos a evaluar, es el coste de software y hardware necesario para llevar a cabo el proyecto. Posteriormente realizaremos un análisis de los costes del personal en función de los roles llevados a cabo. 5.2.1. Presupuesto Hardware y Software En la tabla siguiente, se muestran todos los componentes Hardware utilizados para la realización del proyecto, junto a ellos, se muestra el valor que representa el porcentaje del uso del componente frente a la estimación de la vida útil del mismo. Así conseguimos calcular el coste de uso del componente durante el periodo de duración. Elemento Coste Total Vida Útil Uso Coste Real Ordenador Portátil 600 e4 años 10,5% 63 e Segunda pantalla 150 e4 años 10,5% 15,75 e Conexión a Internet 35 e/mes 5 meses 100% 175 e Ratón USB 15 e2 años 21% 3,15 e Impresora 75 e4 años 10,5% 7,875 e Total 264,78 e Tabla 5.1: Presupuesto Hardware Ahora vamos a pasar a los costes relativos a los programas utilizados para la realización del proyecto, tanto, de la memoria como de la aplicación. Los valores se calcularán del mismo modo que los componentes hardware, es decir, evaluando su coste total en función del tiempo de uso de vida. Las herramientas software utilizadas se detallarán en el siguiente apartado. 53 Capítulo 5. Planificación y Presupuesto A continuación se puede observar la tabla con los costes de software: Elemento Coste Total Vida Útil Uso Coste Real Windows 10 135 e2 años 21% 28,35 e Sublime Text 3 0 e- - 0 e TeXstudio 0 e- - 0 e Startuml 0 e- - 0 e Remix 0 e- - 0 e NodeJS 0 e- - 0 e MongoDB 0 e- - 0 e Notepad++ 0 e- - 0 e IPFS 0 e- - 0 e Billetera Ethereum 0 e- - 0 e MetaMask 0 e- - 0 e Google Chrome 0 e- - 0 e Total 28,35 e Tabla 5.2: Presupuesto Software 5.2.2. Recursos Humanos Ahora que ya tenemos los presupuestos de costes de hardware y software, vamos a proceder a definir los costes de recursos humanos. Para este proyecto se han utilizado cuatro tipos de roles diferentes, el de investigador, el de analista de software, el de programador de aplicaciones web (frontend y backend) y el programador de contratos inteligentes con Solidity. En la siguiente tabla se puede observar el coste presupuestado en función del rol. Rol Salario Mensual Salario por horas Investigador 1.500 e/mes 9,4 e/hora Analista Software 2.000 e/mes 12,5 e/hora Programador de aplicaciones web 1.800 e/mes 11,25 e/hora Programador de Smart Contract 2.250 e/mes 15,63 e/mes Tabla 5.3: Salario por rol A continuación se muestra una tabla con el presupuesto en función a las horas trabajadas por el rol en la planificación inicial. Para calcular las horas se han asignado, al investigador la primera fase de investigación, al analista la fase de análisis y a los programadores la fases de programación y pruebas. El sueldo se calcula a partir del sueldo medio mensual de los roles, obteniendo el coste por hora y teniendo en cuenta que se trabaja 8 horas al día con 20 días laborables al mes. 54 5.2. Presupuesto económico Rol Salario mensual Salario/horas Horas Salario final Investigador 1.500 e/mes 9,4 e/hora 35 * 8 = 280 horas 2.632 e Analista Software 2.000 e/mes 12,5 e/hora 12 * 8 = 96 horas 1.200 e Programador aplicaciones web 1.800 e/mes 11,25 e/mes 53 * 8 = 424 horas 4.770 e Programador Smart Contract 2.250 e/mes 15,63 e/mes 53 * 8 = 424 horas 6.627,12 e Total 15.229,12 e Tabla 5.4: Costes de personal estimados Finalmente, el presupuesto total estimado será la suma de los presupuestos hardware, software y de recursos humanos, que podemos ver en la siguiente tabla: Presupuesto Euros Hardware 264,78 e Software 28,35 e Recursos Humanos 15.229,12 e Total 15.522,25 e Tabla 5.5: Presupuesto Final Estimado 5.2.3. Método de puntos de función Este método consiste en realizar una estimación del coste del proyecto software evaluando todas sus funciones, para obtener los puntos de función de cada una, en función a su complejidad, para implementarla. Para evaluar los puntos de función se han establecido los siguientes grupos: 1. Node entradas de usuario: es el equivalente al uso de formularios por parte del usuario. 2. Node salidas de usuario: es el equivalente a las funcionalidades que muestran datos al usuario. 3. Node peticiones externas: son las consultas que realiza la aplicación a la Blockchain. 4. Grupos lógicos internos: consultas a bases de datos internas. 5. Grupos lógicos externos: consultas a bases de datos externas. Una vez tenemos repartidos los componentes en grupos, haremos uso de la tabla que nos proporciona el método para asignar la complejidad adecuada a cada uno de ellos. 55 Capítulo 5. Planificación y Presupuesto Figura 5.3: Criterios para evaluar la complejidad de los elementos de cálculo Por lo que se nos generaría la siguiente tabla para nuestra aplicación: Grupo Componente Complejidad Entradas Añadir producto Media Hacer Puja Baja Comprar Producto Baja Finalizar Subasta Baja Revelar Pujas Baja Enviar Reembolso Baja Enviar Pago Baja Salidas Mostrar todos los productos Baja Mostrar un producto Media Mostrar una determinada categoria Baja Consultas Obtención de JSON Alta Grupos internos Base de datos MongoDB Media Grupos externos Consultas a la Blockchain Alta Escucha eventos Blockchain Alta Tabla 5.6: Complejidad de nuestros componentes Observando la tabla se muestra la complejidad de los elementos de la aplicación haciendo uso de la figura 4.3. 56 5.2. Presupuesto económico Ahora pasamos a calcular los puntos de función sin ajustar: Grupo Entradas Salidas Consultas G. Interno G. Externo Complejidad B M A B M A B M A B M A B M A Factor x3 x4 x6 x4 x5 x7 x7 x10 x15 x5 x7 x10 x3 x4 x6 Número 6 1 0 2 1 0 0 0 1 0 1 0 0 0 2 Total 18 4 0 8 5 0 0 0 15 0 7 0 0 0 12 = 69 Tabla 5.7: Puntos de función sin ajustar Una vez obtenidos los puntos de función sin ajustar, debemos llevar a cabo un ajuste con un coeficiente obtenido tras la asignación de un valor entero entre 0 y 5 a una serie de variables, en función de la complejidad de éstas: El 0 equivale a Sin influencia. El 1 equivale a Incidental. El 2 equivale a Moderado. El 3 equivale a Medio. El 4 equivale a Significativo. El 5 equivale a Esencial. Factor Valor 1. Comunicaciones de Datos 5 2. Procesamiento de Datos Distribuido 3 3. Rendimiento 3 4. Configuración Altamente Utilizada 2 5. Tasa de Transacciones 4 6. Entrada de datos en línea 3 7. Eficiencia del Usuario Final 3 8. Actualización en línea 5 9. Complejidad de Procesamiento 4 10. Reusabilidad 2 11. Facilidad de Instalación 1 12. Facilidad de Operación 4 13. Múltiples Localizaciones 1 14. Facilidad de Cambio 2 Factor de ajuste de valor 42 Tabla 5.8: Cálculo del coeficiente para el factor de ajuste Una vez tenemos el coeficiente para calcular el factor de ajuste, debemos utilizar la siguiente formula: 57 Capítulo 5. Planificación y Presupuesto 64 Capítulo 6 Análisis 65 Capítulo 6. Análisis En este capítulo, se muestra el análisis previo a la implementación del contrato inteligente y el desarrollo de la aplicación web. 6.1. Actores del sistema Un actor es una entidad externa al sistema que guarda una relación con éste y al cual le demanda una funcionalidad. Los actores además de a las personas, incluyen también a sistemas externos y elementos de carácter abstracto en el caso de tener alguna funcionalidad con el sistema que se describe. Durante el proceso de análisis se han identificado 7 tipos de actores distintos que interactuarán de alguna manera con la web o el contrato inteligente. 1. Dueño del contrato: es el actor que creara el contrato y lo implementara en la Blockchain para que la aplicación y el resto de usuarios puedan interactuar con el contrato y hará algunas veces de árbitro. 2. Vendedor: es el actor que añade productos a la tienda en forma de subasta y comprar ahora. 3. Comprador/Pujador: es el actor que compra o puja por un producto de la tienda. 4. Árbitro: es quien finaliza una subasta, en caso de compra directa el árbitro será el dueño del contrato, y en caso de disputa es el que tiene que intervenir. 5. Usuario general: es el que accede al sistema para ver información pero no esta registrado en MetaMask. 6. MetaMask: sistema externo encargado de gestionar la billetera de cada usuario en la Blockchain y que sirve para unir la aplicación web con la Blockchain. 7. Reloj del sistema: Es un actor ficticio. Representa un proceso del sistema que cuando llega a la fecha y hora de una subasta programada, lanza el evento correspondiente. A continuación se muestra la jerarquía de los actores, que indica la relación de herencia entre funcionalidades y actores. Los actores relacionados con flechas heredan las funcionalidades del actor al cual apuntan. 66 6.1. Actores del sistema Figura 6.1: Diagrama de la jerarquía de los actores del sistema 67 Capítulo 6. Análisis 6.2. Requisitos de usuario A continuación se muestran los requisitos de usuarios identificados para la plataforma: Identificador Descripción RU-01 El usuario general podrá visualizar la información de la tienda RU-02 El usuario general podrá visualizar un producto RU-03 El vendedor podrá añadir productos a la tienda RU-04 El comprador/pujador podrá comprar un producto RU-05 El comprador/pujador podrá pujar por un producto RU-06 El comprador/pujador podrá revelar una puja RU-07 El árbitro podrá finalizar una subasta RU-08 El vendedor podrá enviar una votación de reembolso RU-09 El vendedor podrá enviar una votación de pago RU-10 El comprador podrá enviar una petición de reembolso RU-11 El comprador podrá enviar una petición de pago RU-12 El árbitro podrá enviar una petición de reembolso RU-13 El árbitro podrá enviar una petición de pago RU-14 El usuario general podrá clasificar los productos sin finalizar por categorías RU-15 El usuario general podrá visualizar los productos en etapa de revelar RU-16 El usuario general podrá visualizar los productos en etapa de finalizar RU-17 Una vez finalizada la subasta, el usuario general no se podrán visualizar los productos vendidos en la página de inicio pero si por su id. Tabla 6.1: Requisitos de usuario del sistema 6.2.1. Diagramas de casos de uso En este apartado se recogen los diagramas que relacionan los distintos casos de uso, según los actores que los ejecutan o interactúan con ellos. Figura 6.2: Diagrama de casos de uso del usuario general En la figura 5.2 podemos observar el diagrama de casos de uso del usuario general, del cual partirán los demás actores del sistema. Como se observa, el usuario general puede ver los productos que hay subidos por los distintos vendedores y el estado en el que estos están (en venta, en etapa de revelar o finalizado), podrá también ver los productos de una determinada categoría nada más, también pueden ver un producto concreto accediendo a toda la información de este y también puede ver la información que proporciona la página en las distintas pestañas. 68 6.2. Requisitos de usuario Figura 6.3: Diagrama de casos de uso del vendedor El vendedor, que es un usuario registrado en MetaMask, podrá realizar, además de los que puede hacer el usuario general, añadir un producto a la tienda y desde el caso de uso de ver un producto podrá votar que se envié un reembolso de algún producto que el haya añadido con anterioridad al comprador y podrá votar también para solicitar el dinero de la venta para que se le pague. Figura 6.4: Diagrama de casos de uso del comprador/pujador 69 Capítulo 6. Análisis El comprador/subastador, es como el usuario anterior, un usuario registrado en MetaMask pero que ha comprado o hecho una puja por algún producto. Desde el caso de uso de ver un producto podrá comprar un producto que haya en la tienda bajo un precio fijado, si el producto está en venta, es decir, el tiempo que puso el vendedor para la venta no a acabado; hacer una puja por un producto que este en venta, es decir, que el tiempo de la venta no haya acabado; revelar una puja, en caso de haber hecho una puja y que la subasta este finalizada, para confirmarla y ver si es el ganador o no antes de un periodo de tiempo; podrá votar que se envié el dinero de algún producto que el haya comprado con anterioridad al vendedor y podrá votar también para solicitar el reembolso de la compra realizada. 70 6.2. Requisitos de usuario Figura 6.5: Diagrama de casos de uso del árbitro El árbitro podrá finalizar una subasta una vez está haya llegado al tiempo límite, podrá votar que se envié un reembolso al comprador en caso de una venta con disputas y podrá votar también para enviar el dinero al vendedor en caso de una venta con disputas. Figura 6.6: Diagrama de casos de uso del dueño del contrato El dueño del contrato actuara de árbitro en las ventas que no son a través de pujas, por lo que podrá votar que se envié un reembolso al comprador en caso de una venta con disputas y podrá votar también para enviar el dinero al vendedor en caso de una venta con disputas. 71 Capítulo 6. Análisis Figura 6.7: Diagrama de casos de uso del reloj El reloj del sistema podrá cambiar el estado de un producto cuando este llegue al límite de su período de venta y será el sistema de seguridad para permitir que se puedan realizar unas ciertas operaciones u otras. 6.2.2. Especificación de casos de uso En esta sección se recoge la especificación de todos los casos de uso indicados en los diagramas anteriores. Estará organizada por actores. Usuario general CU-01 Ver productos de la tienda Versión 1.0 Actor Principal Usuario general Actores Secundarios Disparador El usuario ingresa en el index de nuestra aplicación web Descripción Un usuario podrá ver los productos que están en la tienda a forma de cátalogo Precondiciones Secuencia normal 1. El usuario general ingresa con el navegador en nuestra web 2. El sistema muestra la página de inicio donde se encuentran los productos 2.1. Si el usuario general solicita un producto, se lanza el caso de uso CU-02: Ver información de un producto Postcondiciones 1. El sistema muestra los productos clasificados por el estado del tiempo de venta Excepciones Prioridad Alta Casos relacionados CU-02 Comentarios Tabla 6.2: CU-01 - Ver productos de la tienda 72 6.2. Requisitos de usuario CU-02 Ver información de un producto Versión 1.0 Actor Principal Usuario general Actores Secundarios Disparador El usuario indica que quiere visualizar un producto Descripción Un usuario podrá ver los datos de un producto. Precondiciones Secuencia normal 1. El usuario general solicita ver un producto 2. El sistema muestra la página del producto indicado Postcondiciones 1. El sistema muestra el producto solicitado Excepciones Prioridad Alta Casos relacionados CU-01 Comentarios Tabla 6.3: CU-02 - Ver información de un producto CU-03 Ver información de la tienda Versión 1.0 Actor Principal Usuario general Actores Secundarios Disparador El usuario indica que quiere visualizar la información de la tienda Descripción Un usuario podrá ver los datos de la tienda Precondiciones Secuencia normal 1. El usuario general solicita ver información de la tienda 2. El sistema muestra la página de la información de la tienda Postcondiciones 1. El sistema muestra la información de la tienda Excepciones Prioridad Baja Casos relacionados Comentarios Tabla 6.4: CU-03 - Ver información de la tienda 73 Capítulo 6. Análisis CU-11 Votar por enviar reembolso al comprador Versión 1.0 Actor Principal Usuario Registrado (Comprador/Pujador) Actores Secundarios Disparador El comprador/pujador indica que quiere recibir un reembolso por la compra Descripción El comprador/pujador podrá votar por recibir el reembolso por la compra Precondiciones 1. El usuario deberá estar registrado en MetaMask 2. El usuario deberá tener algo de ether para poder pagar la transferencia 3. El usuario debe haber accedido a la página de un producto CU-02 4. El producto tiene que estar en estado finalizado 5. El usuario debe haber ganado el producto Secuencia normal 1. El comprador/pujador indica que quiere un reembolso 2. MetaMask le pide que pague la transferencia para que sea minada 3. El sistema agrega el voto al reembolso Postcondiciones 1. El comprador/pujador vuelve a la página del producto Excepciones 4.1. El usuario no tiene dinero suficiente 4.1.1. El caso vuelve al paso 2 4.2. El usuario cancela el pago 4.2.1. El caso vuelve al paso 2 Prioridad Alta Casos relacionados CU-02 Comentarios Tabla 6.12: CU-11 - Votar por enviar reembolso al comprador 80 6.2. Requisitos de usuario CU-12 Votar por enviar dinero al vendedor Versión 1.0 Actor Principal Usuario Registrado (Comprador/Pujador) Actores Secundarios Disparador El comprador/pujador indica que quiere enviar el pago al vendedor Descripción El comprador/pujador podrá votar por enviar el dinero al vendedor Precondiciones 1. El usuario deberá estar registrado en MetaMask 2. El usuario deberá tener algo de ether para poder pagar la transferencia 3. El usuario debe haber accedido a la página de un producto CU-02 4. El producto tiene que estar en estado finalizado 5. El usuario debe haber ganado el producto Secuencia normal 1. El comprador/pujador indica que quiere enviar el dinero al vendedor 2. MetaMask le pide que pague la transferencia para que sea minada 3. El sistema agrega el voto al envió del pago de la compra Postcondiciones 1. El comprador/pujador vuelve a la página del producto Excepciones 4.1. El usuario no tiene dinero suficiente 4.1.1. El caso vuelve al paso 2 4.2. El usuario cancela el pago 4.2.1. El caso vuelve al paso 2 Prioridad Alta Casos relacionados CU-02 Comentarios Tabla 6.13: CU-12 - Votar por enviar dinero al vendedor 81 Capítulo 6. Análisis Árbitro Los casos de uso Votar por enviar reembolso al comprador (CU-14) y el de Votar por enviar dinero al vendedor (CU-15) son iguales a los casos de uso del vendedor CU-06 y CU-07 y del comprador CU-11 y CU-12, por lo que se opta por no especificarlos. CU-13 Finalizar subasta Versión 1.0 Actor Principal Usuario Registrado (Árbitro) Actores Secundarios Disparador El árbitro indica que quiere finalizar una subasta Descripción El árbitro podrá finalizar una subasta Precondiciones 1. El usuario deberá estar registrado en MetaMask 2. El usuario deberá tener algo de ether para poder pagar la transferencia 3. El usuario debe haber accedido a la página de un producto CU-02 4. El producto tiene que estar en estado revelar y haber pasado el tiempo estipulado para revelar la subasta Secuencia normal 1. El árbitro indica que quiere finalizar la subasta 2. MetaMask le pide que pague la transferencia para que sea minada 3. El sistema agrega el vendedor, el ganador de la subasta/compra y el árbitro que han intervenido Postcondiciones 1. El árbitro vuelve a la página del producto Excepciones 4.1. El usuario no tiene dinero suficiente 4.1.1. El caso vuelve al paso 2 4.2. El usuario cancela el pago 4.2.1. El caso vuelve al paso 2 Prioridad Alta Casos relacionados CU-02 Comentarios Tabla 6.14: CU-13 - Finalizar subasta Dueño del contrato Los casos de uso Votar por enviar dinero al comprador en una venta directa (CU-17) y el de Votar por enviar dinero al vendedor en una compra directa (CU-18) son iguales a los casos de uso del vendedor CU-06 y CU-07 y del comprador CU-11 y CU-12, por lo que se opta por no especificarlos. 82 6.2. Requisitos de usuario Reloj del sistema CU-19 Cambiar estado del producto Versión 1.0 Actor Principal Reloj del sistema Actores Secundarios Disparador El tiempo de subasta de un producto llega a su fin Descripción El reloj del sistema cambia el estado de un producto para que se muestre en el lugar apropiado en la aplicación Precondiciones 1. Tener al menos un producto en la web Secuencia normal 1. El reloj del sistema verifica la fecha de finalización del producto 2. El reloj del sistema actualiza el estado si fuera necesario Postcondiciones 1. El producto cambia de posición a la sección que le toque Excepciones Prioridad Alta Casos relacionados CU-02 Comentarios Tabla 6.15: CU-19 - Cambiar estado del producto CU-20 Cambiar funciones permitidas Versión 1.0 Actor Principal Reloj del sistema Actores Secundarios Disparador El tiempo de subasta de un producto llega a su fin Descripción El reloj del sistema cambia las funciones que se pueden realizar sobre un producto Precondiciones 1. Tener al menos un producto en la web Secuencia normal 1. El reloj del sistema verifica la fecha de finalización del producto 2. El reloj del sistema actualiza el estado si fuera necesario Postcondiciones 1. El producto cambia la información disponible en la vista del producto Excepciones Prioridad Alta Casos relacionados CU-02 Comentarios Tabla 6.16: CU-20 - Cambiar funciones permitidas 83 Capítulo 6. Análisis 6.3. Requisitos de información Los requisitos de información describen todos los aspectos relacionados con los datos creados, gestionados o emitidos por el sistema. Los requisitos de información se modelan a través del diagrama entidad-relación y se detallan mediante el diccionario de datos. Los requisitos de información obtenidos tras el análisis son: RI-01: El Blockchain almacenará los datos del producto. RI-02: El Blockchain almacenará los datos de las pujas. RI-03: El contrato de Fideicomiso almacenará el dinero antes de enviarlo. RI-04: IPFS almacenará los datos de las imágenes y de la descripción. RI-05: MongoDB almacenará los datos de los productos para mostrarlos cuando no haya conexión con la Blockchain a los usuarios generales. 6.3.1. Modelo conceptual de datos Para modelar la información con la que se trabajará, se hace un modelo de ER que va a ser representativo, ya que, no vamos a controlar todas las entidades que hay con nuestra aplicación. 84 6.3. Requisitos de información Figura 6.8: Diagrama Entidad-Relación 85 Capítulo 6. Análisis 6.3.2. Diccionario de datos En este punto se describirán las diferentes entidades almacenadas en la Blockchain y en la base de datos MongoDB: Blockchain Entidad Usuarios Representa a los usuarios que pueden hacer uso de la aplicación desde la cadena de bloques Nombre Descripción Tipo de dato Dominio idBlockchain Dirección que apunta a un usuario de Blockchain address Dirección Blockchain Ethereum Tabla 6.17: Entidad Usuarios Los usuarios deben estar registrados en el Blockchain y no se registraran en la aplicación. La aplicación solo guardará la dirección de Ethereum del usuario cuando pase a hacer uso de la aplicación que se guardará para saber que rol desempeña. Entidad Ofertas/Compras Representa a una oferta/compra que ha sido realizada Nombre Descripción Tipo de dato Dominio postor Dirección de la cuenta del usuario postor Address Dirección Blockchain Ethereum idProducto Identificador del producto en la tienda uint Número valor Valor de la puja enviada uint Número revelado Indica si una oferta a sido revelada o no bool Verdadero o Falso Tabla 6.18: Entidad Ofertas/Compras Las ofertas y las compras se realizan sobre los productos y puede que haya más de una oferta por producto de distintos usuarios, pero sí se realiza una compra se finaliza la subasta. 86 6.3. Requisitos de información Entidad Productos Representa a un producto en la tienda Nombre Descripción Tipo de dato Dominio id Id autoincremental único para cada producto uint Número nombre Nombre identificativo del producto string Cadena de caracteres categoria Nombre identificativo de la categoria string Cadena de caracteres imagenLink Link donde se encuentra la imagen string Cadena de caracteres descLink Link donde se encuentra la descripción string Cadena de caracteres horaInicioSubasta Número identificativo del inicio de la subasta uint Número horaFinSubasta Número identificativo del fin de la subasta uint Número precioDeSalida Número idincativo del precio inicial de la subasta uint Número precioComprarAhora Número idincativo del precio de comprar ahora uint Número mejorPostor Dirección identificativa del mejor postor address Dirección Blockchain Ethereum mejorApuesta Número idincativo de la mejor apuesta uint Número segundaMejorApuesta Número idincativo de la mejor apuesta uint Número ofertasTotales Número autoincremental de las ofertas realizadas al producto uint Número estado Indica el estado de venta de un producto enum - Enventa - Vendido - Sin vender condicion Indica el estado de procedencia de un producto enum - Nuevo - Usado comprado Indica el estado de compra de un producto bool Verdadero o falso ofertas Indica la oferta realizada por un postor mapping Oferta Tabla 6.19: Entidad Productos Los productos reciben ofertas de los usuarios y cuando finaliza se crea el fideicomiso con el vendedor, el comprador y el árbitro de un producto. Entidad Fideicomiso Representa el fideicomiso de un producto Nombre Descripción Tipo de dato Dominio productoId Identifica a un producto de la tienda uint Número comprador Identifica la dirección Blockchain del comprador address Dirección Blockchain Ethereum vendedor Identifica la dirección Blockchain del vendedor address Dirección Blockchain Ethereum arbitro Identifica la dirección Blockchain del árbitro address Dirección Blockchain Ethereum cantidad Indica la cantidad de dinero por la que se vendio el producto uint Número fondosDesembolsados Indica si se ha liberado el dinero del fideicomiso o no bool Verdadero o falso Tabla 6.20: Entidad Fideicomiso El fideicomiso es sobre un producto e indica quien vende y compra el producto y quien árbitra la oferta en caso de disputa. Es el encargado de almacenar el pago hasta que la compra haya finalizado correctamente. Entidad IPFS Representa el hash que se almacena en IPFS de los productos Nombre Descripción Tipo de dato Dominio imagen Dirección hash que apunta a la imagen en IPFS string Cadena de caracteres descripcion Dirección hash que apunta a la descripción en IPFS string Cadena de caracteres Tabla 6.21: Entidad IPFS El IPFS es el encargado de almacenar la imagen y la descripción del producto en la cadena de bloques, y guardar en nuestro contrato el hash donde se encuentra para poder recuperarlo y mostrarlo con posterioridad. 87 Capítulo 6. Análisis MongoDB Entidad ProductModel Representa el producto fuera de la Blockchain Nombre Descripción Tipo de dato Dominio idBlockchain Identifica el id del producto en la Blockchain Number Número nombre Indica el nombre del producto String Cadena de caracteres categoria Indica la categoría del producto String Cadena de caracteres ipfsImagenHash Identifica el hash del link de la imagen en el IPFS String Cadena de caracteres ipfsDescHash Identifica el hash del link de la descripción en el IPFS String Cadena de caracteres horaInicioSubasta Indica la fecha del inicio de la subasta Number Número horaFinSubasta Indica la fecha de finalización de la subasta Number Número precioDeSalida Indica el precio del inicio de la subasta Number Número precioComprarAhora Indica el valor del producto para comprar ahora Number Número condicion Indica el estado del producto Number Número estado Indica el estado de compra del producto Number Número Tabla 6.22: Entidad ProductModel Representa a los productos de la Blockchain para que los usuarios que no estén registrados en MetaMask puedan verlos a forma de catalogo. 88 6.3. Requisitos de información . 89 Capítulo 7. Diseño Figura 7.4: Arquitectura física de la aplicación 7.3. Flujo de la aplicación Para dar sentido a todos los componentes vistos en la arquitectura física, vamos a ver lo que sucede cuando un usuario quiere subir un producto a la tienda: 1. La interfaz web contendrá un formulario HTML donde el usuario ingrese los detalles del producto (nombre, precio de inicio, imagen, descripción, etc) y hace click en guardar. (1) 2. La interfaz web carga la imagen y la descripción del producto en el IPFS y recupera los enlaces de esos archivos cargados. (2) y (3) 3. La interfaz web invoca al contrato inteligente para almacenar la información del producto más los enlaces de IPFS en la cadena de bloques. Una vez se ha guardado con éxito el producto en la cadena de bloques, el contrato envía un evento. El evento contiene toda la información del producto. (4) y (5) 4. El servidor NodeJS está configurado para escuchar estos eventos y cuando un evento es enviado por el contrato, el servidor lee el contenido del evento e inserta el producto en la base de datos MongoDB. (6), (7) y (8) 96 7.3. Flujo de la aplicación Figura 7.5: Flujo de la aplicación para subir un producto 7.3.1. Diagramas de Secuencia En está parte se verán algunos diagramas de secuencia de la aplicación, con ellos se muestra la interacción entre los distintos objetos del sistema. 1. Añadir producto Figura 7.6: Diagrama de secuencia - Añadir Producto 97 Capítulo 7. Diseño 2. Realizar puja Figura 7.7: Diagrama de secuencia - Hacer puja 3. Comprar producto Figura 7.8: Diagrama de secuencia - Comprar producto 98 7.4. Diseño de la interfaz 7.4. Diseño de la interfaz El diseño de la interfaz para la aplicación web se ha realizado con el objetivo de lograr una navegabilidad sencilla e intuitiva. De este modo, los usuarios con menos conocimiento, podrán hacer uso de la aplicación sin ningún problema. El color que se ha elegido como tema de la aplicación web es blanco, ya que queremos dejar una interfaz lo más limpia posible para que se centre en la parte principal, los productos. En cuanto a la navegabilidad, se ha diseñado un menú con todas las funciones consideradas como principales, y de especial interés para los usuarios. Esté menú puede visualizarse en cualquier momento durante el uso de la aplicación web, ya que se encuentra en la parte superior de la pantalla. Se ha utilizado un diseño responsive (gracias a la utilización de Bootstrap), para que se pueda hacer a la web con cualquier dispositivo y que de esta forma se adapte perfectamente a nuestra pantalla. A continuación se desarrolla la explicación detallada de algunas de las pantallas que componen la aplicación con los distintos dispositivos (Smartphone, Tablet y PC). 99 Capítulo 7. Diseño Inicio desde PC Descripción Pantalla de inicio de la web. Activación Acceso al index de la web. Diseño Figura 7.9: Index de la aplicación web desde PC Eventos Acceso a todas las secciones disponibles en el menú. Acceso a cada uno de los productos de la web. Tabla 7.1: Diseño inicio PC 100 7.4. Diseño de la interfaz Inicio desde Tablet Descripción Pantalla de inicio de la web visto desde una tablet. Activación Acceso al index de la web desde tablet. Diseño Figura 7.10: Index de la aplicación web desde Tablet Eventos Acceso a todas las secciones disponibles en el menú. Acceso a cada uno de los productos de la web. Tabla 7.2: Diseño inicio Tablet 101 Capítulo 7. Diseño Inicio desde Smartphone Descripción Pantalla de inicio de la web visto desde un smartphone. Activación Acceso al index de la web desde smartphone. Diseño Figura 7.11: Index de la aplicación web desde Smartphone Eventos Acceso a todas las secciones disponibles en el menú. Acceso a cada uno de los productos de la web. Tabla 7.3: Diseño inicio Smartphone 102 7.4. Diseño de la interfaz Menú de inicio desde Tablet Descripción Menú desde la pantalla de inicio en una tablet Activación Al presionar en el icono de menú que aparece en la esquina superior derecha. Diseño Figura 7.12: Menú desde pantalla inicio tablet Eventos Acceso a todas las secciones disponibles en el menú. Acceso a cada uno de los productos de la web. Tabla 7.4: Diseño menú Tablet 103 Capítulo 7. Diseño Menú de inicio desde Smartphone Descripción Menú desde la pantalla de inicio en un smartphone Activación Al presionar en el icono de menú que aparece en la esquina superior derecha. Diseño Figura 7.13: Menú desde pantalla inicio smartphone Eventos Acceso a todas las secciones disponibles en el menú. Acceso a cada uno de los productos de la web. Tabla 7.5: Diseño menú Smartphone 104 7.4. Diseño de la interfaz Añadir producto desde Tablet Descripción Se muestra el formulario para agregar una producto a la tienda Activación Al presionar sobre la opción del menú: Añadir producto Diseño Figura 7.14: Pantalla añadir producto desde tablet Eventos Acceso a todas las secciones disponibles en el menú. Formulario para añadir un producto a la tienda. Tabla 7.6: Diseño menú Tablet 105 Capítulo 8. Implementación En este capítulo, se procede a explicar el desarrollo llevado a cabo a lo largo del proyecto. En primer lugar veremos la implementación de la aplicación desarrollada, mostrando su estructura y funcionamiento. 112 8.1. Estructura del proyecto 8.1. Estructura del proyecto En siguiente figura se detalla la estructura de la aplicación web. Figura 8.1: Estructura de la aplicación web Vamos a ver que contiene cada carpeta del proyecto: app: Este directorio contiene: 1. javascripts/app.js: archivo javascript con las funciones necesarios para comunicar nuestra pagina HTML con nuestro contrato haciendo uso de la librería web3. 2. stylesheets/app.css: estilos para nuestra página HTML 3. Los archivos HTML de nuestras páginas web. 113 Capítulo 8. Implementación build: Dentro de la carpeta build tenemos otra carpeta llamada contracts, la cual contiene cada uno de los contratos compilados generando todos los datos del contrato a un archivo .json, el cual se usara para migrar el contrato inteligente e interactuar con él. contracts: aquí estará el código fuente de nuestros smart contracts. migrations: En este directorio Truffle busca los scripts que utilizara para desplegar nuestros smart contracts a su posterior entorno de ejecución. Los scrips de despliegue están priorizados (fijados en el prefijo numérico de los archivos que hay dentro) y se ejecutaran en dicho orden. node modules: En está carpeta se encuentran los módulos de NodeJS que utilizamos. test: Como buen “framework ”de desarrollo, Truffle nos ha generado una serie tests unitarios para que podamos tener integración continua (CI) en nuestro proyecto. Para ello, Truffle utilizara el paquete Mocha de pruebas unitarias en NodeJS. package.json: Es el fichero que contiene cada uno de los framework de npm utilizados para el proyecto y que sirve para instalarlos, por ejemplo, mongoose. producto.js: Contiene el Schema que se va a seguir para guardar los productos en la base de datos de MongoDB. seed.js: Archivo de JavaScript que contiene un script para cargar productos en la cadena de bloques a modo de pruebas. Solo se utilizo para probar que se subían los productos antes de tener la parte frontend. server.js: Sirve para crear una aplicación ExpressJS y que comience a escuchar las solicitudes en el puerto 3000. truffle.js: Archivo de JavaScript que contiene la información de la red de Blockcahin a la que se va a migrar nuestra aplicación y nuestros contratos. webpack.config.js: Archivo de JavaScript que contiene los script de configuración de nuestro proyecto, como por ejemplo, las rutas que se van a seguir para ir a cada página web. 8.2. Funcionamiento de la DAPP En este apartado se van a describir las partes del código que han sido claves para el correcto funcionamiento de la aplicación. Lo dividiremos en dos apartados, lo perteneciente al Backend, en este caso, los contratos inteligentes; y lo perteneciente al cliente, en este caso las funciones JavaScript. Contratos inteligentes: En este caso nos encontramos con dos contratos inteligentes, NotarioVirtual.sol yFideicomiso.sol. En el primer contrato inteligente es el principal, en el se encuentran las funciones de añadir un producto a la tienda, obtener un producto, pujar, revelar las ofertas, información sobre la puja más alta, finalizar la subasta, comprar un producto y añadir una dirección de fideicomiso para un producto, después 114 8.2. Funcionamiento de la DAPP están las funciones que necesitan del contrato de fideicomiso, que son, información sobre el fideicomiso, liberar la cantidad al vendedor y reembolsar la cantidad al comprador. El contrato de fideicomiso, es el encargado de guardar el dinero para posteriormente liberarlo al vendedor o reembolsarselo al comprador. Funciones JavaScript: Las funciones de JavaScript son las que unen el contrato inteligente con el Frontend, sin ellas no podría haber sido posible la realización de la aplicación. Aquí podemos ver funciones como la de realizar la puja, revelar la puja, comprar ahora, finalizar la subasta, añadir un producto a la tienda, reembolsar el dinero al comprador, ver los detalles del producto, renderizar un producto a través de su id, guardar un producto en el Blockchain, guardar el hash correspondiente de IPFS, renderizar los productos, y alguna función más de menos importancia. Gracias al JavaScript y sus funciones también comprobamos el estado del producto para mostrar unos formularios u otros en cada pantalla de la aplicación. 115 Capítulo 8. Implementación 116 Capítulo 9 Pruebas 117 Capítulo 9. Pruebas En este capítulo se expondrán las pruebas realizadas sobre el resultado de la implementación del proyecto. En primer lugar se detallarán las pruebas de caja blanca, y para finalizar se analizarán las de caja negra. 9.1. Pruebas de caja blanca El objetivo de estas pruebas es la comprobación a bajo nivel del correcto funcionamiento de las operaciones desarrolladas en cada una de las aplicaciones. A continuación se muestra un listado de las pruebas llevadas a cabo: Control de acceso: se comprueba que las funcionalidades sobre el Blockchain y la base de datos no funcionen para aquellos usuarios que no hayan iniciado sesión en MetaMask. Validación de datos en el lado cliente: se comprueba que tras introducir los datos en los formularios, se controlase su formato y se denegase el envío si no se adaptaban al solicitado. Validación de datos en el lado servidor: una vez recibidos los datos, se comprueba su formato por si se habían modificado. Acceso a la base de datos: se comprueba la correcta conexión a la base de datos de la aplicación web, en todas aquellas operaciones de consulta, inserción y actualización. Funcionamiento de operaciones: se comprueba el funcionamiento de cada una de las operaciones. Se realiza mediante la carga de datos de prueba para trabajar con ellos, y posteriormente con datos reales de la plataforma. Datos JSON: se comprueba que el envío y recepción de los datos a través de JSON por el método GET funciona correctamente. Conexión con el Blockchain: se comprueba que la aplicación tiene comunicación con Blockchain y viceversa. Conexión con los Smart Contract: se comprueba que la aplicación tiene comunicación con los Smart Contract y que esta escucha los eventos que le manda el Smart Contract. 9.2. Pruebas de caja negra Estos test sirven para verificar la funcionalidad deseada de las aplicaciones desarrolladas, comprobando que se cumplen los requisitos modelados en la fase de análisis. 118 9.2. Pruebas de caja negra CP-01: Añadir producto Objetivo Comprobar que se puede añadir un nuevo producto a la tienda Preconsiciones Haber iniciado sesión en MetaMask y tener algo de Ether. Datos de entrada Nombre: Producto de prueba Descripción: Descripción de prueba Foto: producto.jpeg Categoría: Coches Precio de salida: 12 ETH Precio de comprar ahora: 30 ETH Condición: Nuevo Hora de inicio: 06/07/2018 18:00 Días para ejecutar la subasta: 1 Acción esperada Sale un mensaje de producto añadido correctamente. Se vuelve a la página del formulario con los datos vacíos. Secuencia 1. Completar campo nombre 2. Completar campo descripción 3. Subir la imagen del producto 4. Elegir una categoría 5. Completar campo precio de salida 6. Completar campo precio de comprar ahora 7. Elegir la condición del producto 8. Elegir la hora de inicio de la subasta 9. Elegir cuanto quieres que dure la venta 10. Pulsar sobre Agregar producto a la tienda Resultado Correcto Tabla 9.1: CP-01 - Añadir producto 119 Capítulo 9. Pruebas CP-02: Visualizar productos Objetivo Comprobar que el listado de los productos se carga bien Preconsiciones Datos de entrada Acción esperada Obtener un listado de todos los productos en venta Secuencia 1. Ir a la página de inicio (index.html) 2. Mostrar los productos 2.1. En caso de no haber productos, mostrar un mensaje diciendo que no se encontraron productos Resultado Correcto Tabla 9.2: CP-02 - Visualizar productos CP-03: Visualizar un producto Objetivo Comprobar que carga bien la información de un producto Preconsiciones Datos de entrada Acción esperada Visualizar un listado con toda la información del producto y las acciones que se pueden realizar Secuencia 1. Seleccionar un producto 2. Mostrar los detalles del producto y las acciones que se pueden realizar Resultado Correcto Tabla 9.3: CP-03 - Visualizar un producto CP-04: Hacer una puja Objetivo Comprobar que se realiza una puja por un producto de forma correcta Preconsiciones 1. Se debe haber accedido a la página del producto 2. El producto debe estar en venta y en tiempo de subasta Datos de entrada 1. Cantidad que puja: 10 ETH 2. Cantidad que envía: 10 ETH 3. Texto secreto: contraseña Acción esperada Realizar una puja por el producto deseado Secuencia 1. Completar el campo, Cantidad que puja y que sea superior al precio de inicio e inferior al de precio de compra 2. Completar el campo, Cantidad que envía 3. Escribir un texto secreto para cifrar la puja 4. Pulsar sobre Hacer puja Resultado Correcto Tabla 9.4: CP-04 - Hacer una puja CP-05: Hacer una compra Objetivo Comprobar que se realiza una compra por un producto de forma correcta Preconsiciones 1. Se debe haber accedido a la página del producto 2. El producto debe estar en venta y en tiempo de subasta Datos de entrada Acción esperada Realizar una compra por el producto deseado Secuencia 1. Pulsar sobre Comprar ahora Resultado Correcto Tabla 9.5: CP-05 - Hacer una compra 120 9.2. Pruebas de caja negra CP-06: Revelar una puja Objetivo Comprobar que se revelan las pujas de forma correcta Preconsiciones 1. Se debe haber accedido a la página del producto 2. Se debe haber realizado una puja 3. Debe haber finalizado el tiempo de subasta Datos de entrada 1. Cantidad de tu puja: 10 ETH 2. Texto secreto: contraseña Acción esperada Revelar una oferta realizada sobre un producto Secuencia 1. Completar el campo, Cantidad de tu puja 2. Completar el campo, Texto secreto 3. Pulsar sobre Revelar puja Resultado Correcto Tabla 9.6: CP-06 - Revelar una puja CP-07: Finalizar una subasta Objetivo Comprobar que se finaliza correctamente una subasta Preconsiciones 1. Se debe haber accedido a la página del producto 2. Debe haber finalizado el tiempo de subasta 3. Debe haber finalizado el tiempo de revelar subastas Datos de entrada Acción esperada Finalizar la subasta de un producto Secuencia 1. Pulsar sobre Fin de la subasta Resultado Correcto Tabla 9.7: CP-07 - Finalizar subasta CP-08: Enviar dinero al vendedor Objetivo Comprobar que se envía el dinero al vendedor correctamente Preconsiciones 1. Se debe haber accedido a la página del producto 2. Se debe haber ganado la subasta 2. Debe ser el árbitro, vendedor o comprador identificado Datos de entrada Acción esperada Votar por enviar el dinero al vendedor Secuencia 1. Pulsar sobre Enviar dinero al vendedor 2. En caso de ser 2/3 votos, se liberan los fondos al vendedor y la venta se da por concluida Resultado Correcto Tabla 9.8: CP-08 - Enviar dinero al vendedor 121 Capítulo 10. Manuales 10.2.2. Uso de la aplicación El desarrollo de la aplicación web se ha realizado tratando de crear una navegación sencilla con una interfaz limpia e intuitiva. Por está razón cualquier usuario con un conocimiento mínimo para manejar el ordenador, podrá utilizar nuestra Dapp sin problemas. En primer lugar se debe acceder a la url de la aplicación web desde un navegador en la dirección http://localhost:8081 actualmente. Para ello debe estar corriendo el proyecto en su PC. Se debe tener instalado MetaMask. En cuanto a la navegación dentro de la web, se navega desde el menú principal a las diferentes pantallas. A continuación se muestran las opciones de la navegación junto con las opciones que se pueden realizar: 128 10.2. Manual de usuario Index: Se muestran los productos dependiendo de la clasificación (En venta, en etapa de revelar y en etapa de finalizar). En está página también podemos mostrar solo los productos que están en venta de la categoría que seleccionemos. Figura 10.2: Captura de index PC Los productos en etapa de venta, son por los cuales se puede pujar o comprar ahora. Los productos que ya están en etapa de relevar, son aquellos cuya puja a terminado, bien porque ha terminado el tiempo de la subasta, o porque un usuario le ha comprado ahora, en está etapa hay un tiempo para revelar la puja que hiciste y declarar un ganador. La etapa de finalizar es la etapa en la que entra un producto cuando ya ha sido revelado el ganador y es cuando se pasa la etapa de enviar el dinero, bien al vendedor porque todo a ido correctamente o se le hace un reembolso al comprador, porque algo ha salido mal en la venta. 129 Capítulo 10. Manuales Añadir producto: Se muestra un formulario con la información que debes introducir para añadirlo a la tienda, si alguna parte del formulario está sin rellenar o mal rellenada como la fecha de inicio que quieres que empiece la puja de tu producto, no se añadirá a la tienda. Cuando el formulario sea enviado saldrán mensajes diciendo que el producto a sido enviado a la cadena de bloques y una vez confirmes la transacción saldrá un mensaje diciendo si la transacción a sido un éxito y se a agregado a la tienda o si por el contrario algo a salido mal. Figura 10.3: Captura de añadir producto desde iPad 130 10.2. Manual de usuario En la siguiente imagen podemos ver un formulario completo enviado y el mensaje que sale cuando se envía a la cadena de bloques antes de confirmar nuestra transferencia. Figura 10.4: Captura de añadir producto PC enviado formulario En la siguiente imagen se ve la transferencia que queremos realizar para añadir el producto a la cadena de bloques y a nuestra tienda. Figura 10.5: Captura de añadir producto PC - MetaMask 131 Capítulo 10. Manuales En la última imagen se muestra el mensaje de éxito al añadir nuestro producto a la tienda, a partir de ahora le podremos ver en la página de inicio y podremos acceder a él pinchando sobre él. Figura 10.6: Captura de añadir producto desde PC éxito 132 10.2. Manual de usuario Ver un producto: Para acceder a la información de un producto, hay que pinchar sobre él en la pantalla de Inicio. Así se mostrará la información de ese producto y sus funcionalidades (formularios), dependiendo de la etapa en la que esté: •En venta: En la etapa de venta, veremos información relevante sobre el producto, como el precio de salida, el estado en el que está (nuevo o usado), el tiempo que le queda para finalizar la puja, y dos formularios. El primer formulario es para realizar una puja sobre el producto siempre que sea por encima del precio de inicio y por debajo del precio de venta. El segundo formulario es el de comprar ahora, que simplemente será un botón, con el finalizará la subasta y tu serás el ganador del producto. Figura 10.7: Captura de detalles de un producto en etapa de venta 133 Capítulo 10. Manuales •En etapa de revelar: En la etapa de revelar se mostrará información sobre el producto, como el precio de inicio, el estado (nuevo o usado), etc. Se mostrará un formulario para revelar la puja, para revelar quien a sido el ganador de la subasta, si no se revela la puja no puede ser el ganador del producto. Para revelar la puja deberá introducir la cantidad de ETH que a pujado al igual que la palabra secreta que a elegido. Una vez reveladas las pujas y cuando acabe el tiempo de revelar, tendremos un ganador de la subasta y pasaremos a la siguiente etapa. Figura 10.8: Captura de detalles de un producto en etapa de revelar 134 10.2. Manual de usuario •En etapa de finalizar: Es la penúltima etapa por la que pasa un producto, en esta tiene que haber una tercera persona que actuará a modo de árbitro entre el comprador y el vendedor y se llevará el 1% de la transacción, esté árbitro sirve para que en caso de disputa entre el vendedor y el comprador decida si se reembolsa el dinero al comprador o se le envía al vendedor en la última etapa de enviar fondos. Figura 10.9: Captura de detalles de un producto en etapa de finalizar •En etapa de enviar fondos: En esta etapa 2 de las 3 personas tienen que votar si enviar el dinero al vendedor o al comprador, en caso de disputa intervendrá el árbitro de la puja. Una vez 2 de los 3 hayan votado una misma opción se liberarán los fondos y se dará por finalizada la subasta o venta del producto, dejando de aparecer en la página de inicio. Figura 10.10: Captura de detalles de un producto en etapa de enviar dinero 135 Capítulo 10. Manuales •Producto vendido: Una vez se han enviado los fondos, saldrá una pantalla con la información de la venta del producto y los usuarios que han intervenido en ella, para acceder a ella habrá que acceder poniendo el id del producto en la URL. (Más adelante habrá una opción para mostrarlo en tu cuenta, donde saldrán las ventas y las compras realizadas, pero que no se han incluido en está primera versión). Figura 10.11: Captura de detalles de un producto en etapa de finalizar Iniciar sesión en MetaMask: Se muestra como se debe iniciar sesión en la billetera que une el navegador con el Blockchain, para poder ser un usuario de la aplicación web, ya que si no estás registrado en el Blockchain no podrás hacer uso de la aplicación. Figura 10.12: Captura de inicio de sesión con MetaMask 136 10.2. Manual de usuario Importar cuenta en MetaMask: Se muestra como se debe importar una cuenta del Blockchain a la billetera de MetaMask. De esta forma podrás tener conectada tu billetera con el navegador web, para poder usar la aplicación web. Figura 10.13: Captura de importar cuenta en MetaMask Figura 10.14: Captura de importar cuenta en MetaMask 137