Ús de Blockchain i Smart Contracts en els protocols d'intercanvi equitatiu

T reba ll F i de G rau

ENGINYERIA TÈCNICA EN TELECOMUNICACIONS, ESPECIALITAT TELEMÀTICA

Ús de Blockchain i Smart Contracts en els protocols d’intercanvi equitatiu

JUAN CARLOS HORNOS DÍAZ

Tutors

Maria Magdalena Payeras Capellà Macià Mut Puigserver

Escola Politècnica Superior

Universitat de les Illes Balears

S ^UMARI

Sumari i

Índex de figures iii

Índex de taules v

Acrònims vii

Resum ix

1 Introducció 1

1.1 Objectius . . . 2

2 Estat de l’art dels protocols de pagament per rebut 5 2.1 Estudi d’intercanvis equitatius . . . 5

2.1.1 Protocols de pagament per rebut . . . 6

3 Origens d’Ethereum 9 3.1 Bitcoin . . . 9

3.2 Blockchain . . . 10

3.3 Ethereum . . . 11

3.3.1 Comptes d’Ethereum. . . 11

3.3.2 Transaccions . . . 12

4 Eines, metodologia i entorn 15 4.1 Creació de la DApp . . . 15

4.2 MetaMask . . . 17

4.2.1 Instal·lació . . . 17

4.2.2 Comptes necessaris en MetaMask . . . 20

4.2.3 Obtenció d’ethers . . . 20

4.3 Execució de la DAPP . . . 21

4.4 Solidity i Web3 . . . 22

4.4.1 Signar un missatge amb Web3 i verificar-lo amb Solidity . . . . 22

5 Protocol de pagament equitatiu amb timeout fix 25 5.1 Disseny . . . 25

5.1.1 Definició del protocol . . . 25

5.1.2 Funcionalitats del contracte . . . 26

ii SUMARI

5.2 Implementació . . . 28

5.2.1 Codi del contracte intel·ligent . . . 28

5.2.2 Desplegament del contracte a la Blockchain . . . 30

5.2.3 Exemple de creació del contracte en la web . . . 32

5.2.4 Exemple de cancel·lar . . . 34

5.2.5 Exemple de finalitzar . . . 37

5.3 Propietats del protocol . . . 41

5.4 Casos . . . 41

6 Protocol de pagament equitatiu basat en signatures Blockchain 45 6.1 Disseny . . . 45

6.1.1 Definició del protocol . . . 45

6.1.2 Funcionalitats del contracte . . . 46

6.2 Implementació . . . 47

6.2.1 Codi del contracte intel·ligent . . . 47

6.2.2 Desplegament del contracte a la Blockchain . . . 49

6.2.3 Exemple de creació del contracte en la web . . . 49

6.2.4 Exemple de cancel·lar . . . 51

6.2.5 Exemple de finalitzar . . . 54

6.3 Propietats del protocol . . . 57

6.4 Casos . . . 58

7 Avaluació de resultats 61 7.1 Anàlisis de rendiment . . . 61

7.1.1 Consum de gas . . . 61

7.1.2 Temps en finalitzar . . . 62

7.2 Comparació de propietats . . . 64

8 Conclusions 65 8.1 Millores en ambdós protocols . . . 66

A Annexos 67 A.1 Annex I: Codi font . . . 67

Bibliografia 69

Í NDEX DE FIGURES

4.1 Estructura de carpetes de la DApp . . . 16

4.2 Incloure MetaMask al navegador . . . 17

4.3 Crear cartera a MetaMask . . . 18

4.4 Password per a la nostra wallet . . . 18

4.5 Clau de recuperació en cas de pèrdua . . . 19

4.6 Selecció de xarxa . . . 19

4.7 Diferents comptes a MetaMask . . . 20

4.8 Publicar adreça a Google+ . . . 21

4.9 Sol·licitud d’Ethers . . . 21

4.10 Execució de la DApp . . . 22

4.11 Web de la DApp (localhost:3000) . . . 22

5.1 Diagrama de funcionalitats i transició d’estats . . . 27

5.2 Interfície d’usuari de la DAPP . . . 30

5.3 Desplegament amb web3 . . . 31

5.4 Completar formulari previ a la creació . . . 32

5.5 Desplegament del contracte iniciat . . . 32

5.6 Transacció de creació de contracte . . . 33

5.7 Alerta contracte creat . . . 34

5.8 Interfície web una vegada creat el contracte . . . 34

5.9 Activació botó Cancel quan expira el timeout . . . 35

5.10 Codi Web3 per cancel·lar . . . 35

5.11 Confirmació de la transacció a MetaMask . . . 36

5.12 Alerta de cancel·lació realitzada . . . 37

5.13 Comprador i venedor no coincideixen en el preu . . . 37

5.14 Codi Javascript i Web3 per finalitzar . . . 38

5.15 Format del missatge que ha de signar el venedor . . . 38

5.16 MetaMask demanant al venedor si vol signar . . . 39

5.17 Alerta signatura realitzada . . . 39

5.18 MetaMask demanant confirmació de finalització . . . 40

5.19 Alerta indicant la finalització del pagament . . . 40

5.20 Cas 1 . . . 42

5.21 Cas 2 . . . 42

5.22 Cas 3 . . . 43

5.23 Cas 4 . . . 43

6.1 Completar formulari previ a la creació . . . 50

iv Índex de figures

6.2 Desplegament del contracte iniciat . . . 50

6.3 Transacció de creació de contracte . . . 51

6.4 Alerta contracte creat . . . 51

6.5 Interfície web una vegada creat el contracte . . . 52

6.6 Confirmació de la transacció a MetaMask . . . 52

6.7 Alerta cancel·lació en procés . . . 53

6.8 Alerta cancel·lació realitzada . . . 53

6.9 Codi Web3 per controlar la confirmació d’una transacció . . . 53

6.10 Comprador i venedor no coincideixen en el preu . . . 54

6.11 MetaMask demanant al venedor si vol signar . . . 55

6.12 Alerta signatura realitzada . . . 55

6.13 MetaMask demanant confirmació de finalització . . . 56

6.14 Alerta indicant la finalització del pagament . . . 56

6.15 Alerta indicant la confirmació de la transacció . . . 57

6.16 Publicació del rebut a la web . . . 57

6.17 Cas 1 . . . 58

6.18 Cas 2 . . . 59

6.19 Cas 3 . . . 59

6.20 Cas 4 . . . 60

7.1 Informació de la transacció en https://rinkeby.etherscan.io/ . . . 62

7.2 La transacció s’està minant . . . 63

7.3 MetaMask indicant que la funció s’ha minat . . . 63

7.4 MetaMask indicant que el contracte s’ha desplegat . . . 63

Í NDEX DE TAULES

7.1 Consum de gas (unitats de gas) . . . 62 7.2 Duracions (segons) . . . 64 7.3 Comparació de propietats . . . 64

A ^CRÒNIMS

DApp Descentralized Application URL Uniform Resource Locator ABI Application Binary Interface

ECDSA Elliptic Curve Digital Signature Algorithm TTP Trusted Third Party

EVM Ethereum Virtual Machine P2P Peer To Peer

R ^ESUM

En aquest projecte s’implementaran dues Descentralized Application (DApp) per a dos protocols de pagament per rebut. Aquestes DApps es desplegaran sobre la xarxa Rinkeby(xarxa de provaEthereum) amb els seus respectiusSmart Contractsque contro- laran el pagament de forma automatitzada.

El primer protocol exposat al capìtol 5 es basa en dates límit. És a dir, l’usuari po- drà resoldre el pagament dins d’una finestra de temps. Es podrà veure que la signatura del venedor no necessita ser validada a laBlockchain, per tant, si no es gestiona el timeout de forma correcta el comprador podrà fer un mal ús del protocol per intentar obtenir aquesta signatura (rebut de la compra) i fer una cancel·lació abans d’efectuar-se el pagament. Per altra banda el segon protocol exposat al capítol 6 no disposa d’aquesta finestra de temps, els usuaris podran resoldre en qualsevol moment. Aquest protocol si és efectiu ja que la signatura (rebut) del venedor només serà vàlida si es confirma a la Blockchain, per tant, sempre es complirà l’atomicitat en aquest protocol.

D’aquesta forma es complirà l’objectiu d’aquest projecte, avaluarEthereum, una plata- forma descentralitzada per al desplegament de contractes intel·ligents sobre laBlockc- hain. Els passos seguits per a la construcció dels contractes es detallaran en aquest document, així com també els resultats de l’avaluació de tots dos.

C

1

I ^NTRODUCCIÓ

Molts dels serveis que fem servir diàriament a Internet requereixen que l’usuari es connecti a un servidor per accedir a una aplicació en concret. Per exemple, per accedir a pàgines comGoogleo Facebook cal passar per algun dels servidors on estan allotjats.

Això suposa que moltes de les aplicacions i serveis online que fem servir cada dia estan centralitzats.

L’organització de la xarxa segons aquesta estructura comporta diversos problemes.

El primer problema és el de la seguretat, si un servidor pateix un atac, generalment sol posar en perill a tots els seus usuaris. El segon problema és el de la confiança, els usuaris no saben què passa darrere de l’aplicació un cop han enviat les seves peticions.

En una societat on cada vegada es confia informació més sensible a aquests sistemes, aquests problemes poden suposar grans pèrdues als usuaris.

Amb la creació deBitcoin, va sorgir la tecnologia de la cadena de blocs (blockchain) que permetia als usuaris arribar a un consens de manera distribuïda i segura sense necessi- tat d’un servidor central. Anys després, Ethereum va saber aprofitar aquesta tecnologia amb un llenguatge de programació integrat del tipus Turing-complet, que permet que qualsevol pugui escriure contractes intel·ligents i aplicacions descentralitzades. Això vol dir que Ethereum té una base més àmplia sobre la qual construir i un mercat més ampli que cobrir. No està limitat a ser un llibre de transferència de valors com Bitcoin. En aquest document s’implementaran dosSmart Contractso contractes intel·ligents sobre la plataforma Ethereum. Fins ara els contractes han estat documents verbals o cars documents escrits, subjectes a les lleis i jurisdiccions territorials, i de vegades requerint de notaris, és a dir, més costos i temps. En canvi un contracte intel·ligent és capaç d’executar-se i fer-se complir per si mateix, de manera autònoma i automàtica, sense intermediaris ni mediadors. Són codis informàtics escrits amb llenguatges de programació, sent els termes del contracte pures sentències i ordres en el codi que el formen. A més tenen validesa sense dependre d’autoritats gràcies a la seva natura-

1. INTRODUCCIÓ

lesa: és un codi visible per tots i que no es pot canviar a l’existir sobre la tecnologia blockchain, la qual li dóna aquest caràcter descentralitzat, immutable i transparent.

1.1 Objectius

En aquest projecte s’implementaran dos protocols de pagament per rebut. Aquests protocols s’utilitzen en compres a Internet on el producte és un bé tangible i no es pot entregar electrònicament. Llavors en aquests escenaris, per aconseguir l’equitat de la compra és necessària la intervenció d’un rebut que consistirà en un compromís per part del venedor on es reflecteix l’evidència del pagament i la descripció del bé que serà transferit a través d’un enviament físic. S’implementaran utilitzant la tecnologia Ethe- reum que ens permetrà desenvoluparSmart Contracts. Aquets contractes intel·ligents controlaran el procés de la compra de forma automatitzada. A més s’implementaran les DApps respectives a cadascun dels dos protocols a implementar, que permetran als usuaris involucrats en la compra, interactuar amb aquests contractes.

Per tant, els objectius del projecte són els següents:

• Valorar la situació actual dels protocols d’intercanvi equitatiu en pagaments per rebut.

• Realitzar un previ estudi al funcionament de Blockchain, i més concretament, d’

Ethereum.

• Conèixer i analitzar el funcionament dels Smart Contracts.

• Fer un estudi del llenguatgeSolidityamb el que s’implementaran els contractes.

• Implementar els dos contractes de pagament per rebut.

• Fer un estudi de la llibreriaWeb3que ens permetrà interactuar des del web amb els contractes.

• Implementar les respectives DApps.

• Avaluar els protocols implementats. Tant la seva eficiència com la seva seguretat.

En aquest document, es veurà com s’acompleixen aquests objectius entre els dife- rents capítols d’aquest document. En el capítol [2] es farà un estudi dels protocols d’intercanvis equitatius, fent èmfasis en aquells de pagament per rebut que són els que s’implementaran en aquest document. Seguidament al capítol [3] s’explicarà com va sorgir Ethereum, la cadena de blocs i les seves característiques que permetran la

teòrics, al capítol [4] s’explicaran els passos a seguir i eines a utilitzar per a la creació de la DApps. Sabent les eines i metodologia a utilitzar, als capítols [5] i [6] es definiran els dos protocols, es veuran les seves implementacions i diferents casos o situacions que podrien succeir en cadascun d’ells. Al capítol [7] s’avaluaran ambdós protocols, fent referència al consum de gas, temps en finalitzar i una comparació de les propietats que satisfan. Finalment al capítol [8] es veurà si s’han aconseguit complir els objectius del projecte. A més es definiran una sèrie de millores que es podrien realitzar en un futur.

C

2

E ^{STAT DE L} ’ ART DELS PROTOCOLS DE PAGAMENT PER REBUT

El creixement del comerç electrònic ha revolucionat la forma de dur a terme les transac- cions comercials, sobretot des del moment en que totes les accions involucrades en aquestes transaccions es poden realitzar telemàticament. Moltes d’aquestes transacci- ons requereixen un intercanvi de valors entre diferents usuaris. És per això que des de l’àmbit acadèmic han sorgit una sèrie de protocols per intentar que aquests intercanvis entre dos o més usuaris es realitzin de forma equitativa.

2.1 Estudi d’intercanvis equitatius

Avui dia, hi ha una gran varietat de serveis electrònics com la signatura electrònica de contractes, el correu electrònic certificat i el pagament a canvi d’un rebut, que requerei- xen d’un intercanvi entre dos o més usuaris. Aquest intercanvi s’ha de realitzar de forma atòmica, és a dir, no ha de ser possible que en l’intercanvi un dels usuaris es quedi sense la l’element que li correspon mentre que l’altre usuari (o altres usuaris) si que obtingui el seu element. Els protocols d’intercanvi equitatiu de valors proporcionen equitat en l’intercanvi, per tant, o tots els usuaris rebran la seva part dels elements a intercanviar o cap dels usuaris rebrà cap.

M.Payeras enProtocols de comerç electrònic: Pagament anònim i intercanvi equita- tiu[1] fa una classificació d’aquests protocols en funció de la presència o absència de Trusted Third Party (TTP) durant l’execució del protocol.

Protocols per a l’intercanvi equitatiu sense TTP

Aquests protocols també coneguts comautocontinguts, no necessiten la intervenció d’una TTP ja que garanteixen la seguretat de l’intercanvi per si mateixos. El fet de no requerir de TTP és una característica desitjable per als protocols d’intercanvi equitatiu,

2. ESTAT DE L’ART DELS PROTOCOLS DE PAGAMENT PER REBUT

encara que en alguns escenaris presenten una sèrie d’inconvenients que afecten a l’eficiència del protocol. Això és degut a que aquests protocols requereixen un gran nombre d’interaccions entre els usuaris i una complexitat de càlcul elevada.

En protocols basats en l’intercanvi gradual fins aconseguir completar el missatge i amb un escenari on hi ha molta diferència de potència de càlcul entre els dos usuaris, podria donar-se la no equitat en l’intercanvi ja que l’usuari amb més potència podria decidir avortar el protocol abans de que l’intercanvi s’hagi completat ja que amb la seva potència té capacitat per completar el missatge de l’altre amb unes poques mostres de l’intercanvi gradual (l’altre no té capacitat per fer això). Aquest problema es pot resoldre amb protocols probabilístics on l’equitat es garanteix amb una probabilitat donada (sol ser alta). Amb aquests protocols no faria falta que la potència de càlcul dels usuaris sigui similar, però es requereix un major nombre d’interaccions entre els usuaris per a que puguin completar els respectius missatges.

Protocols per a l’intercanvi equitatiu amb TTP

Entre els protocols que requereixen TTP es poden distingir els arbitrats i els optimistes:

• Arbitrats: En aquests protocols la TTP participarà en totes les execucions del pro- tocol per tal de garantir la seguretat en l’intercanvi. Degut a la contínua presència d’aquesta TTP durant l’intercanvi, aquests protocols presenten uns inconveni- ents com són el cost que representa per als usuaris el servei donat per la TTP, la possible congestió en la comunicació entre els múltiples usuaris i la TTP i el retard addicional provocat per les comunicacions entre l’usuari i la TTP en cada execució del protocol.

• Optimistes: Per evitar aquests inconvenients dels protocolsarbitrats, apareixen els protocolsoptimisteson la TTP es limita a participar en casos d’excepció. En el cas en que el protocol no finalitzi correctament o qualque usuari indiqui el mal ús del protocol de l’altre usuari, s’activarà un subprotocol on es presentaran unes proves per sol·licitar la intervenció de la TTP. En funció de les proves presentades, la TTP podrà emetre missatges o prendre decisions que garanteixin l’equitat de l’intercanvi.

2.1.1 Protocols de pagament per rebut

Com s’ha dit a laIntroducció1, els protocols que es definiran en aquest document són protocols de pagament per rebut. Per tant, en aquesta secció es donarà una visió d’aquests protocols de pagament per rebut.

Els protocols de pagament per rebut s’utilitzen en compres on el producte a inter- canviar no es pot servir electrònicament, és a dir, es requereix un enviament físic. Per tant l’intercanvi en aquest cas és entre el pagament, que es pot efectuar mitjançant criptomonedes (els protocols que es definiran en aquest document utilitzaranethers) i

l’evidència del pagament i la descripció del bé que serà transferit a través d’un envia- ment físic. Aquest rebut serà utilitzat com a prova de la conclusió de la compra en cas de disputa.

Una de les característiques que han de tenir aquests protocols és aconseguir que la compra sigui certificada per les dues parts i que l’intercanvi sigui atòmic. És interessant que l’intercanvi que representa la compra del producte sigui anònim, almenys per a l’usuari que realitza el pagament. Una altra característica que han de tenir aquests protocols és la possibilitat de resoldre l’intercanvi sense la necessitat d’una TTP. A més, aquests protocols han de ser flexibles, és a dir, ha de ser utilitzable amb diferents siste- mes de pagament. Finalment, com a darrera característica, el protocol ha de permetre finalitzar i cancel·lar l’intercanvi.

Tal i com s’explica enProtocols de comerç electrònic: Pagament anònim i intercan- vi equitatiu[1], avui dia hi ha una sèrie de protocols de pagament per rebut i també es poden classificar en funció de la participació de la TTP. Per exemple hi ha solucions sense la participació de la TTP que no ofereixen atomicitat però si donen certa protec- ció als compradors. Altres solucions amb TTP ofereixen entrega certificada unilateral i equitat en el pagament. D’altra banda hi ha solucions poc eficients però que ofereixen al comprador abans de realitzar el pagament, validar els elements que adquirirà.

En aquest document s’implementaran dos protocols de pagament per rebut, proposats al documentTowards Fairness of Cryptocurrency Payments[2] i que s’avaluaran amb els requeriments que N.Asokan enFairness in Electronic Commerce[3] defineix que han de tenir els protocols per a pagaments equitatius. Aquests requeriments són els següents:

• Efectivitat: Si ambdós usuaris es comporten correctament, l’intercanvi s’efectua- rà.

• Equitat: Hi pot haver equitat forta si en el moment de la finalització del protocol, els dos usuaris obtenen el que volen, o cap d’ells ho fa. O equitat feble si en situacions on un dels usuaris no rebi la seva part, pugui ser demostrable a una TTP.

• Timeliness: Hi pot havertimelinessfort si els usuaris poden resoldre en qualsevol moment, otimelinessfeble si els usuaris estan limitats o depenen d’un altre usuari per resoldre.

• No invasivitat: El protocol no imposa la forma o validació dels elements a inter- canviar.

• Duració de la transacció: El temps necessari per a l’intercanvi ha de ser curt.

2. ESTAT DE L’ART DELS PROTOCOLS DE PAGAMENT PER REBUT

De les explicacions anteriors s’extreu que un protocol d’intercanvi equitatiu és aquell on l’intercanvi ofereix la característica d’atomicitat. És a dir, o cadascun dels usuaris in- volucrats en l’intercanvi reben el seu element corresponent sense cap tipus d’avantatge damunt els altres usuaris, o per contra cap dels usuraris rebrà cap element. En el cas dels protocols de pagament per rebut, aquesta atomicitat s’aconseguirà si el pagament es realitza només si el comprador obté un rebut que confirma que rebrà el producte. El venedor rebrà el pagament i el comprador el rebut, sense cap tipus d’avantatge entre ambdós com per exemple el comprador obtenir el rebut i poder intentar que se li retorni el pagament (aquest cas es podrà donar en el protocol implementat en el capítol 5).

C

3

O ^{RIGENS D} ’E ^THEREUM

L’any 2009, Satoshi Nakamoto va publicar la primera versió de Bitcoin (es va implemen- tar per primera vegada una moneda descentralitzada) [4]. Aquesta moneda tenia com a objectiu crear un sistema de pagaments electrònics completament descentralitzat, emprant proves criptogràfiques mitjançant un sistema deproof of worko prova de treball. Aquest mecanisme criptogràfic resol dos problemes. Primer, ofereix una forma efectiva d’arribar a un consens entre tots els nodes de la xarxa sobre l’estat de la mateixa.

Segon, ofereix la possibilitat de que qualsevol persona pugui unir-se a la xarxa de nodes, resolent la centralització del control de la xarxa.

3.1 Bitcoin

Bitcoinés una moneda virtual que es basa en un sistema de transaccions on hi ha un "estat", que consisteix en l’estatus de totes les transaccions dels propietaris de les monedes. D’aquesta manera, la possessió debitcoinsno implica tenir una moneda virtual, sinó l’existència d’un llistat de transaccions en la que l’última persona registrada en la transacció és el beneficiari.

Per a que tot això funcioni es va crear un sistema conegut comBlockchaino cadena de blocs, un registre públic i accessible per tots els nodes de la xarxa on s’emmagatzema l’historial de totes les transaccions. D’aquesta manera es fa pràcticament impossible falsejar una transacció, ja que si algú intenta enganyar a un node per fer creure al sistema que té més diners dels que realment posseeix, en sincronitzar la informació de la transacció, aquesta seria visible per la resta de la xarxa i rebutjada automàticament en no poder demostrar la possessió d’aquestsbitcoins.

3. ORIGENS D’ETHEREUM

3.2 Blockchain

La cadena de blocs és un tipus de base de dades distribuïda que emmagatzema la informació en forma de blocs. Cada bloc guarda informació sobre les transaccions realitzades, el temps en què el bloc va ser afegit a la cadena, ihashdel bloc anterior.

D’aquesta manera, la validesa de les transaccions futures pot ser verificada consultant l’últim estat de la direcció d’enviament.

La inclusió del proper bloc de la cadena es realitza mitjançant un sistema de pro- va de treball conegut comminar. La mineria permet als nodes de la xarxa arribar a un consens de forma distribuïda. Els diferents nodes de la xarxa competeixen mitjançant potència de càlcul computacional per resoldre un problema matemàtic. El node que resulti guanyador és l’encarregat de formar el següent bloc amb les transaccions pen- dents de verificar i afegir-lo a la cadena. Aquest sistema també permet l’emissió de noves monedes mitjançant la generació delcoinbasede cada bloc, una petita quantitat de moneda que va a parar al generador del bloc juntament amb la comissió pagada pels usuaris les transaccions dels quals han estat incloses en aquest bloc minat.

Des de l’aparició deBitcoinhan anat sorgint noves monedes que es basen en la ma- teixa tecnologia de cadena de blocs. La principal innovació que han aportat aquestes monedes són diferents mètodes de proves de consens:

• Proof of work: Requereix la resolució de problemes matemàtics mitjançant força bruta. S’empren problemes difícils de computar però fàcils de verificar per com- provar que qui obté la solució ha realitzat una quantitat significativa de treball computacional. Algunes monedes que empren aquest sistema però amb dife- rents algoritmes de minat sónBitcoin,LitecoinoPrimecoin.Ethereumen els seus inicis utilitzava aquest mètode.

• Proof of stake: En aquest cas l’encarregat de crear el següent bloc de la cadena ve determinat per una probabilitat relacionada amb el nombre de monedes que es posseeix. D’aquesta manera, els que més tenen generen una major quantitat de monedes. Alguns que fan servirProof of StakesónNXToPeercoin. És habitual queProof of stake s’usi al costat deProof of workper a crear algoritmes més segurs i amb menor consum de recursos.FaircoinoEthereumsón exemples de l’ús d’algoritmes híbrids.

• Proof of resources: Les noves monedes generades es reparteixen en funció de la seva contribució cap a la xarxa. Un exemple d’aquesta implementació ésSafecoin, on els usuaris minen monedes en funció de la seva aportació en forma d’ample de banda o espai en disc a la xarxa amb l’objectiu de descentralitzar Internet.

• Proof of burn: Les noves monedes es generen mitjançant l’eliminació d’una al- tra moneda anterior. Per a això, els usuaris han de provar aquesta eliminació mitjançant l’enviament d’una transacció a una direcció sense retorn. Una de les monedes que empra aquest sistema ésCounterparty.

3.3 Ethereum

Ethereumés un protocol, una plataforma, un llenguatge de programació i una cripto- moneda (ether) que neix inspirat de molts dels conceptes deBitcoin‘que abans hem esmentat’ amb l’objectiu de permetre la creació d’aplicacions descentralitzades que s’executen sobre la tecnologiaBlockchainper aconseguir una xarxa d’ordinadors pro- gramables a tot el món al que qualsevol persona pot pujar i executar programes sota unes sòlides regles de consens compartides.

Milers d’ordinadors a tot el món connectats a través d’Internet. Tots aquests ordinadors tenen instal·lat el mateix programa informàtic Ethereum Virtual Machine (EVM), que permet que tots aquests ordinadors estiguin connectats entre si formant una xarxa d’iguals o Peer To Peer (P2P). Aquest programa és el que marca les regles sobre com aquesta xarxa d’ordinadors ha de funcionar conjuntament: com han de comunicar-se entre ells, com han d’emmagatzemar dades, i aquest programa els permet comportar-se com si tots aquests ordinadors junts fossin un sol ordinador.

El funcionament intern és molt semblant al de Bitcoin, amb la seva pròpia cripto- moneda anomenadaether.Etherés el combustible que impulsa aquesta plataforma d’aplicacions distribuïdes. És una criptomoneda utilitzada pels clients de la plataforma Ethereumper realitzar pagaments a altres persones o a màquines que executen opera- cions sol·licitades. És a dir, l’etherés l’incentiu que assegura que els desenvolupadors escriguin aplicacions de qualitat (la codificació innecessària costa més) i que la xarxa romangui saludable (la gent és recompensada pels recursos aportats). A més, per tal d’evitar bucles infinits accidentals, hostils, o un altre malbaratament computacional en el codi, cada transacció és obligada a establir un límit al nombre de passos computacio- nals d’execució de codi que ella pot utilitzar. La unitat fonamental de computació és gas. És a dir, els clients d’Ethereumque realitzin qualsevol transacció hauran de pagar per a la realització d’aquesta amb la intenció d’obligar a un atacant a pagar propor- cionalment per cada recurs que consumeix, incloent computació, ample de banda i emmagatzematge.

Per a la creació d’aplicacions primer s’escriu un contracte (Smart Contract) mitjançant codi (Solidity) i es puja a la cadena de blocs mitjançant una transacció. Un cop a la cadena de blocs, el contracte té una direcció des de la qual es pot interactuar amb ell.

Ethereumté el seu propi llenguatge de programació amb el qual desenvolupar aplica- cions que en un futur podran abastar molts d’àmbits. Totes aquestes aplicacions són distribuïdes, la qual cosa implica que qualsevol persona pot crear un contracte enEthe- reumsense necessitat d’un servidor centralitzat i amb la capacitat de poder executar tot tipus de programes amb una determinada lògica ja que el llenguatge d’Ethereumés Turing complet.

3.3.1 Comptes d’Ethereum

La forma d’identificar-se en la xarxa deEthereumés mitjançant l’ús de comptes. Un compte és una adreça des d’on l’usuari pot interactuar amb la resta de la xarxa. Una adreça d’Ethereumpot identificar a un usuari de la xarxa o a un contracte emmagatze-

3. ORIGENS D’ETHEREUM

mat en la cadena de blocs:

• Usuaris: Són totes les persones que vulguin interactuar amb la xarxa d’Ethereum.

Disposen de la seva adreça i un balanç amb el saldo disponible en el seu comp- te.Ethereumutilitza la criptogreafia Elliptic Curve Digital Signature Algorithm (ECDSA) que ens permetrà obtenir una clau pública a partir d’una clau privada.

Amb les dues claus ja podrem signar transaccions i verificar després les signatu- res.

Per una adreçaEthereumexisteixen gran varietat de moneders owalletscom MetaMask, que gestionaran aquestes claus. Les adreces del moneder són les claus públiques. Pot conèixer-les qualsevol ja que només serveixen per a rebre transac- cions. Aquesta clau pública o direcció s’ha creat a partir d’una clau privada. La clau privada del transmissor s’utilitza per signar la transacció. La clau privada del receptor assegura que aquesta direcció (clau pública) li pertany i per tant podrà confirmar que és el destinatari de la transacció.

• Contractes: Un contracte enEthereumtambé s’identifica per la seva direcció i aquest conté el codi del contracte, un balanç amb el saldo disponible i la seva pròpia memòria on emmagatzemar informació. Cada vegada que un contracte rep un missatge en forma de transacció, s’executa el seu codi permetent la lectura i modificació de la seva memòria interna.

D’aquesta manera s’aconsegueix que usuaris i contractes es comportin d’una ma- nera indistingible a la xarxa d’Ethereum. Perquè hi hagi comunicació entre comptes existeixen les transaccions.

3.3.2 Transaccions

Una transacció enEthereumés una forma de comunicació entre dos comptes. Aquesta comunicació és simplement un paquet de dades que s’envia d’un lloc a un altre mit- jançant el pagament d’una petita comissió. El pagament d’aquestes transaccions es fa a través de la pròpia moneda d’Ethereumanomenadaether, la qual es pot aconseguir minant a la xarxa.

Una transacció conté:

• El receptor del missatge.

• Una firma identificant el compte que envia la transacció.

• La quantitat d’etherque s’envia.

• Un camp de dades opcionals (que es faran servir per interactuar amb els contrac- tes).

• Un valor anomenat STARGAS que representa el màxim de passos computacionals que la transacció pot realitzar.

• Un valor anomenat GASPRICE que indica el preu que ha de pagar l’ emissor per poder realitzar la transacció.

D’aquesta manera s’aconsegueix que si un usuari vol utilitzar la xarxaEthereumper pujar contractes a la cadena de blocs o realitzar transaccions, ha d’aconseguirether, per exemple minant ( 5ethersón creats per cada bloc cada 15-17 segons per als miners dels blocs), el que contribueix al funcionament de tota la xarxa. De manera que elsetherno neixen amb l’objectiu d’esdevenir una criptomoneda, sinó més aviat amb l’objectiu de facilitar les transaccions a la xarxaEthereum. Elsethertenen dues funcions principals dins de la xarxa:

• Com que les aplicacions han de pagaretherper cada operació que executen, prevé que la xarxa s’ompli de programes fora de control o maliciosos.

• A més, elsetherserveixen per incentivar econòmicament als miners que contri- bueixen amb els seus recursos a la xarxa descentralitzada.

C

4

E ^INES , METODOLOGIA I ENTORN

En aquest capítol es descriuran les eines que necessitarem per a dur a terme la imple- mentació d’ambdósSmart Contracts, la preparació de l’entorn i com desplegarem els contractes a laBlockchain.

4.1 Creació de la DApp

Per a la creació de la DAPP s’utilitzarà la plataforma Meteor [5].Meteorés un entorn de treball per a aplicacions web de codi obert basat enJavaScriptdissenyat amb la tecnologia Node.js.

Primer de tot s’haurà d’instal·lar Meteor, en el meu cas la instal·lació és sobre un dispo- sitiu MacOS (La instal·lació en altres dispositius es podrà trobar en la referència [6]).

En el cas d’un dispositiuMacOS, la instal·lació es fa per consola, aplicant la següent comanda:

$ curl https://install.meteor.com/ | sh Després de la instal·lació es procedirà a crear la DApp:

$ meteor create myDapp

$ cd myDapp

D’aquesta forma es crearà al nostre equip una carpeta (anomenada myDApp) amb la següent estructura:

4. EINES,METODOLOGIA I ENTORN

Figura 4.1: Estructura de carpetes de la DApp

Llavors per al desenvolupament del codi de l’aplicació és necessari afegir a la DApp el paquet de web3.js que permetrà interactuar amb qualsevol node d’Ethereum. Més endavant s’explicarà com connectar-se a un node s’Ethereummitjançant el proveidor de l’obejte web3 utilitzat dins del codi, en aquest cas és un node que proporcina el plugin del navegador MetaMask. Amb la següent comanda s’afegirà aquesta llibreria a la DApp de meteor:

$ meteor add ethereum:web3

A la carpeta anomenada ’client’, Meteor facilita les plantilles .html (definirem el contin- gut de la web), .css (aplicarem estil a la web) i .js (s’ha d’aplicarjavascriptiweb3per interactuar amb el nodeEthereum) que podran ser editats per realitzar la nostra DAPP.

Per editar aquestes plantilles en aquest cas s’ha utilitzat l’editor de textosAtom[7].

Seguidament hem de connectar la nostra DAPP al nodeEthereum. Ho aconseguirem gràcies al següent codi que haurem de situar a l’inici de la plantilla .js:

if(typeof web3 !== ’undefined’){

web3 = new Web3(web3.currentProvider);

}else{

web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

};

Com que s’ha utilitzat l’extensió de ChromeMetaMask, el proveïdor és injectat auto- màticament. Per tant, mai entrarà dins delelse. Aquestelse, en el cas de no utilitzar MetaMask, permetrà triar un altre proveïdor com per exemple un node de xarxaEt-

proporcionat per Infura [8], que és un clúster de nodesEthereumque permet als usuaris executar la seva aplicació sense requerir-los que configurin el seu propi node o cartera d’Ethereum.

4.2 MetaMask

Per connectar la DAPP a un nodeEthereum, s’ha utilitzatMetaMask[9].MetaMaskés un plugin que fa de pont entre diverses DApps i el navegador Chrome sense compro- metre la seguretat, usant diversos comptes i sense necessitat d’usar un nodeEthereum complet.

MetaMaskintenta apropar encara més lesBlockchaina l’usuari a través d’una mena d’intèrpret de DApps que funciona com una extensió del navegador, permet accedir a serveis, signar transaccionsBlockchain, administrartokens, administrar diversos mone- ders, tot en una interfície amigable i segura. La idea és integrar tots els serveis, incloent aquells d’Ethereum, al navegador.

4.2.1 Instal·lació

Per instal·larMetaMasken la Web Store de Chrome s’ha de polsar el botó d’afegir tal i com mostra la Figura 3.2.

Figura 4.2: Incloure MetaMask al navegador

Una vegada s’hagi instal·lat, apareixerà la petita icona de la guineu taronja a la cantona- da superior dreta del navegador. S’ha de clicar sobre ella, acceptar les seves polítiques i passar a la creació de la nostra cartera. LaFigura4.3 mostra la primera pàgina quan

4. EINES,METODOLOGIA I ENTORN

obrim per primera vegada MetaMask. Ens permet creat nous comptes o utilitzar comp- tes anteriors.

Figura 4.3: Crear cartera a MetaMask

Polsant el botóCREATE NEW VAULT, MetaMask farà introduir una contrasenya tal i com es mostra a laFigura4.4.

Figura 4.4: Password per a la nostra wallet

12 paraules. Sense elles, serà impossible recuperar la cartera en cas de pèrdua, junta- ment amb elsethersque conté.

Figura 4.5: Clau de recuperació en cas de pèrdua

Finalment s’indicarà en quina xarxa es vol treballar. En aquest cas la xarxa de prova Rinkeby. En aquesta xarxa podrem realitzar qualsevol tipus de transaccions en laBlockc- hainsense cap tipus de cost real.

Figura 4.6: Selecció de xarxa

4. EINES,METODOLOGIA I ENTORN

4.2.2 Comptes necessaris en MetaMask

En els dos protocols que en pròxims capítols s’explicaran, es necessita la creació de dos wallets Ethereum. Es necessita una wallet per al comprador i una altra per al venedor.

MetaMaskpermet crear diversos comptes independents que podran interactuar amb la DApp.

Figura 4.7: Diferents comptes a MetaMask

4.2.3 Obtenció d’ethers

Com ja s’ha dit en capítols anteriors, per fer moviments dins la xarxa d’Ethereum es necessiten ethers. En aquesta secció s’explicarà com obtenir aquets ethers (sense cap tipus de cost real, ja que es treballarà sobre una xarxa ’testnet’).

Si s’ha d’utilitzar la xarxa real d’Ethereum hi ha vàries formes d’obtenir aquesta criptomoneda. Comprar criptomonedes o bitcoins en una casa de canvi és, amb diferència, la forma més senzilla d’obtenir criptomonedes o bitcoins. Algunes de les cases de canvi més reconegudes, en aquest moment, per obtenirethersón Bitstamp.net, Kraken.com, Coinbase.com o Xapo.com. Per altra banda, Algunes empreses paguen als seus empleats amb moneda digital. Coinbase és un exemple i també altres startups com Buffer. Per últim com s’ha dit en capítols anteriors, minar es una altra alternativa d’obtenirether.

En aquest document s’explicarà amb detall com obtenir ether per a la xarxa de prova que s’utilitzarà (Rinkeby). El primer pas es tenir un compte Google+, i realitzar una publicació de l’adreça on volem rebre els ethers (Aquesta adreça la proporciona

Figura 4.8: Publicar adreça a Google+

Una vegada s’ha publicat l’adreça, s’ha de copiar la Uniform Resource Loca- tor (URL) d’aquesta publicació i afegir aquest copiat en el input text de la pàgina

“https://faucet.rinkeby.io”. Aquesta pàgina dóna diferents opcions per obtenir ethers.

Depenent de la quantitat d’ethers demanats, s’haurà d’esperar més o menys temps per poder tornar a demanar més ethers (Figura 3.9). Es triarà una de les 3 opcions i en un cert temps es rebran el ethers.

Figura 4.9: Sol·licitud d’Ethers

4.3 Execució de la DAPP

Una vegada finalitzats els pasos anteriors, s’haurà d’executar la DAPP gràcies a meteor, executant la següent comanda en el terminal:

$ meteor

Meteor començarà a carregar tots el paquets, llibreries i plantilles (.html, .css, .js), comprovarà que no hi ha errors de programació. Com es pot observar a laFigura4.10, la DApp s’ha executat satisfactòriament, el servidor local està activat i la web de la DAPP serà accessible des de la URL “http://localhost:3000/” i en laFigura4.11 es pot veure la interfície.

4. EINES,METODOLOGIA I ENTORN

Figura 4.10: Execució de la DApp

Figura 4.11: Web de la DApp (localhost:3000)

4.4 Solidity i Web3

En aquesta secció veurem algunes funcions Solidity i Web3 que s’utilitzaran per a la implementació dels dos protocols de pagament per rebut. Per una part Solidity [10]

és un llenguatge de programació d’alt nivell (Turing complet) la síntesi del qual és similar a un altre dels llenguatges de programació més usats avui en dia: Javascript.

Aquest llenguatge està dissenyat i compilat en codi de bytes (bytecode) per crear i desenvolupar contractes intel·ligents que s’executin en la EVM. Per altra banda Web3 [11], és el llenguatge que permet la interacció entre la xarxa Ethereum i l’aplicació web.

4.4.1 Signar un missatge amb Web3 i verificar-lo amb Solidity

Com ja s’ha dit, els dos protocols que s’implementaran són protocols de pagament per rebut. Per tant, per realitzar aquest rebut es necessita realitzar una signatura. Aquesta

Primer s’ha de tenir clar què s’ha de signar. En els dos protocols que s’implementaran, la signatura es realitzarà sobre elhashd’un missatge que envia el comprador al venedor.

Aquesthashes realitza amb el següent codi Web3:

var messageToSign = ’missatge enviat pel comprador’;

hash = web3.sha3(messageToSign);

Una vegada tenim aquesthash, es procedirà a la realització de la signatura. Amb la següent funció Web3 es farà que MetaMask demani a l’usuari (venedor) si vol realitzar aquesta signatura amb la seva clau privada.

web3.eth.sign(web3.eth.accounts[0], hash, function(err, res){

if(typeof res!==’undefined’){

signature=res;

alert(’Message signed by the seller. ’);

}else{

alert(’Error signing the message. ’+err);

} });

La funcióweb3.eth.sign(adreça del signat, missatge que es vol signar requereix per paràmetre l’adreça del signant (s’indicarà l’adreça de MetaMask del venedor) i el missatge que es vol signar. A l’executar-se aquesta funció MetaMask demanarà al venedor si vol signar amb la seva clau privada. Quan el venedor accepti signar, si no hi ha errors, la funcióweb3.eth.sign()retornarà la signatura.

A continuació aquesta signatura s’ha de verificar a la blockchain. Per realitzar aquesta verificació, Solidity disposa de la funcióecrecover(). La idea d’ecrecover()és que es pot calcular la clau pública corresponent a la clau privada que es va utilitzar per crear una signatura ECDSA. Aquesta funció demana per paràmetres el missatge abans de ser signat i uns valors extrets de la signatura (s’explicarà amb més detall a la secció 5.2.5). Una vegada executada si la verificació de la signatura és correcta retornarà l’adreça del signant, en cas contrari retorna un “0”.

C

5

P ROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

En els dos capítols següents es veurà el disseny, implementació i un conjunt de proves dels dos contractes intel·ligents realitzats. Com s’ha dit en la secció 2.1.1 d’aquest document, aquests contractes plasmen un pagament per rebut equitatiu, on es disposarà com a entitats un comprador i un venedor (Figura4.7).

5.1 Disseny

En aquesta secció es definirà el protocol a plasmar en l’Smart Contract implementat i els diferents casos d’ús que podrà tenir el contracte intel·ligent.

5.1.1 Definició del protocol

Aquest primer contracte es basa en l’ús de dates límit per assegurar l’equitat. Amb aquest contracte veurem com aquest temps fix pot afectar negativament les garanties d’equitat i inclús possiblement la seguretat general del procés si no s’ajusten correc- tament els paràmetres. És un protocol basat en el protocol de Heilman [12], on el comprador vol canviar de forma justa un pagament amb criptomoneda per un rebut del producte ofert pel venedor.

En aquest protocol, primer el comprador genera una transacció que li permet pagar una quantitat predefinida al venedor, amb la condició de que el venedor haurà de publicar una signatura vàlida (rebut), dins d’un temps determinat.

Després d’aquest temps, el comprador podrà cancel·lar el pagament amb una transacció (sempre i quan el venedor no hagi resolt el procés abans). En el cas que el venedor no hagi realitzat la transacció de publicar el rebut, les criptomonedes serien retornades al comprador.

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

Amb l’algoritme mostrat més avall, el protocol es definirà amb més claredat.

Com es pot observar, per realitzar l’intercanvi, primer el comprador ha d’enviar un missatge (m) generat amb característiques pròpies de l’intercanvi i el pagament.

El pagament quedarà emmagatzemat en un contracte intel·ligent desplegat en la blockchain i el missatge s’enviarà al venedor.

Si el timeout no ha expirat, el venedor podrà resoldre l’intercanvi (en aquest temps només podrà intervenir el venedor). Si vol resoldre l’intercanvi, és a dir, si està conforme amb l’oferta del comprador (ethersque pagarà el venedor), haurà de signar el missatge que li havia enviat el comprador abans de que expiri el timeout. Just en aquest moment aquesta signatura es dóna per vàlida, és a dir, no és necessària la seva confirmació a la blockchain. En canvi si el timeout ha expirat i l’intercanvi encara no s’ha resolt, el comprador podrà realitzar la cancel·lació.

En quant al pagament (emmagatzemat en al contracte), com es pot veure a l’algoritme, serà enviat a l’adreça del venedor o comprador depenent de quina transacció (finalització del venedor o cancel·lació del comprador) quedi confirmada primer a la blockchain (quedarà millor reflexat en els casos que podrien succeir en aquest protocol mostrats a la secció 5.4 d’aquest document).

C ompr ad or→C ont r ac t e:pag ament C ompr ad or→V ened or:m

iftimeout no ha expirat && intercanvi no resolt then Venedor pot finalitzar

V ened or→C ompr ad or :Si g n(m) //SIGNATURA VÀLIDA else

iftimeout ha expirat && intercanvi no resoltthen Comprador pot cancel·lar

end if end if

iftransacció de finalització es confirma en la blockchain abansthen C ont r ac t e→V ened or:pag ament

else

iftransacció de cancel·lació es confirma en la blockchain abansthen C ont r ac t e→C ompr ad or :pag ament

end if end if

5.1.2 Funcionalitats del contracte

A continuació es defineixen les funcionalitats que el contracte intel·ligent a implemen- tar hauria de satisfer i els actors que les podran realitzar:

• Creació del contracte

Aquesta transacció la realitzarà el comprador. La realitzarà des de la web d’usuari (desplegament del contracte amb web3). Al crear el contracte haurà d’especificar la direcció del venedor (adreça que assigna MetaMask al venedor), la finestra de

que està dispost a pagar pel producte. Amb aquesta recopilació de paràmetres, s’originarà un missatge, el qual haurà de signar el venedor quan vulgui finalitzar.

• Finalitzar el procés de compra

Aquesta transacció la realitzarà el venedor, sempre i quan la realitzi dins de la finestra de temps establerta. Amb aquesta transacció, el venedor haurà de signar el missatge del comprador i la Blockchain haurà de verificar si aquesta signatura és vàlida. Quan el venedor realitza aquesta transacció, la signatura (rebut) serà publicada en la web de la DApp i es considerarà una signatura vàlida sense esperar a que aquesta transacció sigui confirmada a la Blockchain. Si es dóna per bona aquesta signatura, el pagament serà enviat a l’adreça del venedor.

• Cancel·lar el procés de compra

Aquesta transacció la podrà realitzar el comprador una vegada hagi finalitzat el timeout. Si ha passat aquest temps i el venedor no ha finalitzat, el contracte intel·ligent retornarà el pagament a l’adreça del comprador.

Figura 5.1: Diagrama de funcionalitats i transició d’estats

Com podem observar a laFigura5.1, una vegada creat el contracte només pot passar a un estat cancel·lat o finalitzat.

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

5.2 Implementació

En aquest apartat es definirà com s’ha implementat tant el contracte intel·ligent, com la part web on l’usuari podrà interactuar amb aquest contracte.

5.2.1 Codi del contracte intel·ligent

pragma solidity ^0.4.18;

contract PayFairFixedTimeout { address comprador;

address vendedor;

address a;

uint timeout;

bool finish;

uint precioComprador;

uint precioVendedor;

function PayFairFixedTimeout(address _vendedor, uint duracion) public payable{

comprador = msg.sender;

vendedor = _vendedor;

finish=false;

timeout = now + duracion;

precioComprador = msg.value;

}

function Timeout() public {

require(msg.sender == comprador && now >= timeout &&

finish==false);

finish = true;

selfdestruct(comprador);

}

function finished(uint _precioVendedor,bytes32 hash, uint8 v, bytes32 r, bytes32 s) public {

precioVendedor=_precioVendedor;

a=ecrecover(hash, v, r, s);

require(msg.sender==vendedor && now < timeout &&

precioVendedor==precioComprador && a==vendedor &&

finish==false);

finish=true;

selfdestruct(vendedor);

} }

atributs del contracte, el constructor i dues funcions que s’expliquen a continuació. Per començar, apareixen els atributs del contracte que permetran el bon comportament del procés. Aquests atributs s’aniran modificant durant el transcurs del contracte.

El contracte guardarà les adreces del comprador i venedor. L’atributaés una adreça que s’obté a partir d’una verificació de firma. El contracte també guardarà el temps en el qual el venedor podrà resoldre. Apareix un booleà que permetrà al contracte saber quan el pagament s’ha resolt. Per últim el preu que està dispost a pagar el comprador pel producte, i el preu que vol rebre el venedor (han de coincidir).

address comprador;

address vendedor;

address a;

uint timeout;

bool finish;

uint precioComprador;

uint precioVendedor;

A continuació, apareix el constructor del contracte. La creació del contracte l’ha de realitzar el comprador pel correcte funcionament del pagament.

En aquest constructor es defineixen la majoria dels atributs anomenats abans. Quan el comprador generi aquesta transacció haurà d’indicar l’adreça del venedor i el timeout.

Llavors per omplir els altres atributs, el contracte agafarà l’adreça del qui genera la transacció per definir l’adreça del comprador. El booleà finish es defineix comfalse, el ti- meout es defineix com el temps en el que es genera el contracte més la duració indicada pel comprador. Finalment aquest constructor té la propietatpayable, per tant el valor en ethers que indiqui el comprador quan generi el contracte, aquests ethers es queden emmagatzemats en el contracte. El contracte definirà l’atributprecioCompradoramb aquest valor d’ethers.

function PayFairFixedTimeout(address _vendedor, uint duracion) public payable{

comprador = msg.sender;

vendedor = _vendedor;

finish=false;

timeout = now + duracion;

precioComprador = msg.value;

}

A continuació el contracte disposa de la funcióTimeouton el comprador podrà can- cel·lar el pagament. Per poder realitzar aquesta funció, es requereix que l’adreça que executi aquesta funció sigui la del comprador, s’ha d’haver superat el timeout i el paga- ment no ha d’estar resolt (finish==false).

Si aquesta funció s’executa amb èxit, amb la comandaselfdestruct(comprador);, els ethersemmagatzemats en el contracte s’enviaran a l’adreça del comprador i el contracte es destruirà.

function Timeout() public {

require(msg.sender == comprador && now >= timeout &&

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

finish==false);

finish = true;

selfdestruct(comprador);

}

Finalment el contracte disposa de la funciófinishedon el venedor podrà resoldre el pagament. Aquesta funció requereix indicar per paràmetre el ethers que vol rebre el venedor en el pagament i uns sèrie de paràmetres per realitzar la verificació de la signatura del venedor (explicació al subapartat 4.2.1 Signatura del venedor).

Per poder executar aquesta funció, la transacció l’ha de realitzar l’adreça del venedor, no ha d’haver expirat el timeout, el venedor i comprador han de coincidir en el cost del pagament, la verificació de la signatura del venedor ha de ser correcta i el pagament no ha d’estar resolt.

Si aquesta funció es resol amb èxit, els ethers emmagatzemats en el contracte s’enviaran automàticament a l’adreça del venedor i el contracte es destruirà.

function finished(uint _precioVendedor,bytes32 hash, uint8 v, bytes32 r, bytes32 s) public {

precioVendedor=_precioVendedor;

a=ecrecover(hash, v, r, s);

require(msg.sender==vendedor && now < timeout &&

precioVendedor==precioComprador && a==vendedor &&

finish==false);

finish=true;

selfdestruct(vendedor);

}

5.2.2 Desplegament del contracte a la Blockchain

En aquest subapartat s’explicarà com el comprador des de la web podrà crear i desplegar el contracte a la Blockchain. El comprador quan accedeixi a la web de la DAPP veurà la interfície de laFigura5.2:

Figura 5.2: Interfície d’usuari de la DAPP

L’usuari per crear el contracte haurà d’indicar una sèrie de valors com s’observa a la

direcció del venedor, el timeout i la quantitat d’ethers. Per l’altra part haurà d’indicar la data del moment en que crea el contracte (la data és un dels valors que conté el missatge que el venedor ha de signar).

Quan l’usuari cliqui sobre el botóCreate contract, el desplegament del contracte es realitzarà gràcies a la programació web3 tal i com mostra el codi de la Figura5.3:

Amb aquest codi (Javascript i Web3), primer es crea l’objecte contracte amb l’ajuda de

Figura 5.3: Desplegament amb web3

l’Application Binary Interface (ABI) (generat a la pàginahttps://remix.ethereum.org/) que és un array que descriu les funcions del contracte:

var MyContract = web3.eth.contract(abi);

Seguidament s’utilitza aquest objecte contracte amb la funció.new()per fer el desple- gament a la Blockchain. En aquesta funció de desplegament, s’han d’indicar els parà- metres que necessita el constructor del contracte. En aquest contracte el constructor requereix l’adreça del venedor i el timeout. A més en aquesta funció s’ha d’especificar l’adreça del qui està desplegant el contracte (adreça del comprador), l’argumentdata que s’obté també des de la pàginahttps://remix.ethereum.org/, el gas i els ethers que quedaran emmagatzemats en el contracte a l’argumentvalue. La següent funció si s’executa amb èxit retorna l’adreça del contracte desplegat:

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

contract.new(arg1, arg2, {

from: web3.eth.accounts[0], data: code,

gas: ’4700000’, value: _buyerPrice }

5.2.3 Exemple de creació del contracte en la web

Primer de tot el comprador haurà de completar el formulari de creació de contracte.

Especificarà la direcció del venedor, el timeout en segons, la data i la quantitat d’ethers.

Una vegada completat el formulari, ha de fer clic sobre el botóCreate contract. A la Figura5.4, es pot observar com en el primer input del formulari s’ha indicat l’adreça del venedor, després s’han indicat uns 200000 segons de timeout (és a dir, el venedor tindrà una finestra de de temps de 55 hores per poder resoldre l’intercanvi, s’aconsella donar prou temps al venedor per tal d’evitar un dels casos problemàtics explicat a la secció 5.4), la data i 1etherque és lo que està disposat a pagar el comprador pel producte, i que quedarà emmagatzemant en el contracte.

Figura 5.4: Completar formulari previ a la creació

Quan el comprador cliqui el botó, apareixerà una alerta al navegador dient que el desplegament del contracte ha iniciat i podria trigar uns minuts, tal i com mostra la Figura5.5.

Figura 5.5: Desplegament del contracte iniciat

Seguidament MetaMask demanarà al comprador si vol confirmar la transacció per desplegar el contracte. Com es pot observar a laFigura5.6, la transacció conté tots els arguments que el comprador havia especificat prèviament. A dalt s’indica que la transacció l’està realitzant el compte de MetaMask del comprador. Apareix la seva adreça i elsethersque conté aquest compte. A més s’indica que amb aquesta transacció el comprador desplegarà un nou contracte a la blockchain. En mig s’observa el camp amountque concorda amb elsethersque havia especificat en la web el comprador, el camp Gas Limit indica el valor màxim de Gas que una transacció pot arribar a consumir per ser vàlida. És un valor elevat ja que el desplegament d’un contracte té un major cost computacional. El campGas Priceindica el preu delgas(1GWEI = 0,000000001 Ether), que farà que augmenti la comissió (campMax Transaction fee, que s’obté de la estimació de gas necessari per a la realització de la transacció multiplicat pelGas Price) que es durà el miner d’aquesta transacció. Si s’incrementa aquest valor, incrementarà la comissió, per exemple a laFigura5.6 la comissió és de 0.0047ethers amb unGas Priced’1 GWEI. Si s’incrementa aquestGas Pricea 20 GWEI la comissió incrementaria en un valor de 0.094ethers. Per tant, una comissió major incentiva als miners a processar la nostra transacció abans que altres que estaven en cua. Finalment el campMax Totalindica el cost total de la transacció (Amount+Max Transaction fee).

Figura 5.6: Transacció de creació de contracte

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

Una vegada el comprador accepti continuar amb el procés de desplegament fent clic sobreSUBMIT, la web quedarà carregant esperant al correcte desplegament del contracte a la Blockchain.

Finalment com s’ha dit anteriorment, quan la funció .new() retorni l’adreça del contracte, voldrà dir que el contracte s’ha desplegat de forma correcta. Apareixerà al navegador una alerta indicant la finalització del desplegament i l’adreça assignada al contracte (0x5ebE14EB328B4f6eAb28593748D41aBDcbC15C85) tal i com mostra la Figura5.7.

Figura 5.7: Alerta contracte creat

5.2.4 Exemple de cancel·lar

A continuació s’explicarà com executar una funció del contracte amb web3 i es mostrarà un exemple de la cancel·lació del pagament per part del comprador.

Una vegada que el comprador ha desplegat el contracte, no podrà cancel·lar fins que expiri el timeout tal i com queda reflexat a laFigura5.8.

Figura 5.8: Interfície web una vegada creat el contracte

Quan el timeout hagi expirat, amb javascript s’activarà el botó de cancel·lar i el comprador podrà executar la funció cancel·lar del contracte (com s’observa a laFigura

Figura 5.9: Activació botó Cancel quan expira el timeout

Quan el comprador pugui cancel·lar el pagament, haurà de fer clic sobre el bo- tó Cancel. En aquest moment a través de Web3 executarem la funcióTimeoutdel contracte intel·ligent:

Figura 5.10: Codi Web3 per cancel·lar

Com es pot veure a laFigura5.10, per cridar a una funció del contracte intel·ligent ja desplegat, s’ha de crear l’objecte del contracte desplegat. Això es realitza amb la següent comanda i gràcies a l’adreça del contracte desplegat que es va obtenir prèviament (l’adreça del contracte desplegat es guardarà en la variableaddressen el javascript):

MyContract=web3.eth.contract(abi).at(address)

Una vegada tenim l’objecte del contracte desplegat, cridarem a la funció del contracte intel·lgentTimeoutde la següent forma:

MyContract.Timeout(function(err, result){

if(typeof result!==’undefined’){

alert(’Operation cancelled. ’+result);

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

}else{

alert(’Error cancelling the purchase. ’+err);

} });

S’obrirà l’extensió MetaMask per confirmar si el comprador vol re- alitzar aquesta transacció d’una funció del contracte amb l’adreça

“0x5ebE14EB328B4f6eAb28593748D41aBDcbC15C85”, per tant s’està fent refe- rència al contracte prèviament desplegat.

A laFigura5.11, s’observa com MetaMask vol confirmar aquesta transacció. A dalt s’observa que l’adreça del comprador és la que vol executar aquesta transacció, els ethers que disposa i a més es vol executar una funció del contracte amb l’adreça

“0x5ebE14EB328B4f6eAb28593748D41aBDcbC15C85". A diferència de la transacció del desplegament, en aquest cas el campAmountés 0 ja que en aquesta transacció no es vol fer un intercanvi de monedes, simplement s’està executant una funció del contracte.

El campGas Limiten aquest cas és molt menor ja que el cost computacional és menor que en el desplegament. ElGas Priceés el mateix, però com aquesta transacció té un cost computacional molt menor (menor gas per validar la transacció), el campMax Transaction Feetambé és menor. D’aquesta manera elMax Totalserà el valor de la comissió (Max Transaction Fee).

Figura 5.11: Confirmació de la transacció a MetaMask

Si la transacció s’executa sense problemes apareixerà una alerta indicant al comprador que la cancel·lació s’ha dut a terme (a més apareix el hash de la transacció):

Figura 5.12: Alerta de cancel·lació realitzada

5.2.5 Exemple de finalitzar

A continuació en aquest subapartat es veurà com el venedor pot resoldre el pagament des de la web i la part de programació web3 per realitzar la signatura (rebut per al comprador). A la secció 4.4.1 d’aquest document queden descrites les funcions Web3 i Solidity que s’empraran per a la signatura i verificació de la mateixa.

Una vegada creat el contracte, com ja s’ha dit, el venedor tindrà un cert temps per resoldre el pagament, com s’observa a laFigura5.8 (el venedor pot resoldre durant aquest temps i el comprador no pot cancel·lar fins que expiri el timeout).

El venedor haurà d’indicar el preu que vol cobrar i ha de coincidir amb els ethers que està disposat a pagar el comprador (amb javascript la web no deixarà finalitzar fins que aquest preu coincideixi amb els ethers que vol pagar el comprador).

Figura 5.13: Comprador i venedor no coincideixen en el preu

Si aquest preu coincideix, el venedor podrà finalitzar el pagament. Fent clic sobre el botóFinished, s’estarà executant el següent codi:

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

Figura 5.14: Codi Javascript i Web3 per finalitzar

Com es pot veure en el codi de la Figura 5.14, si coincideixen els preus del ve- nedor i comprador, el venedor haurà de signar el missatge. Aquest missatge s’origina amb dades proporcionades pel comprador com l’adreça del venedor, la data de creació del contracte i els ethers per al pagament. El campOrderés l’identificador de la compra i per aconseguir que aquest nombre sigui sempre diferent, se li assigna l’adreça del contracte.

Figura 5.15: Format del missatge que ha de signar el venedor

Aquest missatge l’ha de signar el venedor i serà el rebut pel comprador. Una vegada rebi aquest rebut té totes les garanties per rebre el producte.

Per signar un missatge amb Web3 s’utilitza la següent funció que requereix passar per paràmetre l’adreça del venedor i el missatge que volem signar. El missatge que es signarà serà el hash del missatge mostrat a laFigura5.15:

var messageToSign=’Order: ’+ address +’\n\nDate: ’+ date +

’\n\nBuyer address: ’

+_comprador+’\n\nSeller address: ’ +_vendedor+’\n\nCost (ethers): ’

hash = web3.sha3(messageToSign); //hash del missatge

web3.eth.sign(web3.eth.accounts[0], hash, function(err, res){

console.log(err,res);

});

Aquesta funció farà que MetaMask demani al venedor si vol signar amb la seva clau privada tal i com mostra laFigura5.16. En aquesta figura es pot observar que la signa- tura la realitzarà el compte del venedor, s’indica la seva adreça, elsethersque conté i el missatge que es signarà (en aquest cas és elhashdel missatge prèviament enviat pel comprador).

Figura 5.16: MetaMask demanant al venedor si vol signar

Quan el venedor polsi el botóSign, es generarà una signatura gràcies a l’algoritme ECDSA, algoritme que utilitza Ethereum per validar l’origen d’un missatge. Seguida- ment a la web apareixerà una alerta indicant que el missatge s’ha signat correctament:

Figura 5.17: Alerta signatura realitzada

Una vegada s’ha realitzat la signatura, només queda verificar aquesta signatura a la Blockchain per finalitzar el pagament. Per fer aquesta validació, s’ha de cridar a la funció finisheddel contracte intel·ligent que com s’ha dit abans, conté la funcióecrecover():

a=ecrecover(hash, v, r, s);

5. PROTOCOL DE PAGAMENT EQUITATIU AMB TIMEOUT FIX

Aquesta funció, com s’ha dit a la secció 4.4.1 d’aquest document, requereix com a paràmetres el missatge sense signar (hash del missatge de laFigura5.15) i els valors v,r isque s’extreuen de la signatura. La signatura està formada per 3 variables:v, r,s. Ethereum empra la criptografia de la corba el·líptica i aquestes variables són simplement part de les matemàtiques subjacents. Per extreure els valorsv,risde la signatura, s’utilitza el següent codi Web3:

r = ’0x’ + signature.slice(2, 66);

s = ’0x’ + signature.slice(66, 130);

v = ’0x’ + signature.slice(130, 132);

És a dir,restà format pels primers 32 bytes de la signatura,ssón els següents 32 bytes i vés l’últim byte. Amb aquests valors obtinguts, es podrà cridar a la funcióFinisheddel contracte intel·ligent. MetaMask demanarà al venedor si vol confirmar la transacció:

Figura 5.18: MetaMask demanant confirmació de finalització

Quan el venedor faci clic sobre el botóSubmit, és realitzarà aquesta transacció en la Blockchain. A la web apareixerà una alerta indicant que s’ha realitzat la transacció i que s’enviaran elsethersa l’adreça del venedor:

Figura 5.19: Alerta indicant la finalització del pagament

Amb aquesta transacció el contracte intel·ligent validarà si la signatura (rebut) ha estat realitazda pel venedor realment. Per tant, si aquesta validació és correcta, la funció ecrecover()retornarà l’adreça del venedor (retorna ’0’ en cas contrari) i per tant es