FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS URYCHLENÍ TĚŽBY BITCOINŮ DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR Bc. JAN NOVOTNÝ BRNO 2014

2 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS URYCHLENÍ TĚŽBY BITCOINŮ BITCOING MINING ACCELERATION DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR Bc. JAN NOVOTNÝ Ing. MICHAL KAJAN BRNO 2014

3 Abstrakt Tato diplomová práce se zabývá virtuální měnou zvanou Bitcoin. Popisuje fungování měny z technického hlediska, především provádění transakcí, způsob jejich potvrzování a zajištění integrity pomocí kryptografických funkcí. Dále je popsán princip vytváření Bitcoinů - takzvaná těžba, konkrétně metoda těžby zvaná těžařské uskupení. V práci jsou dále popsány používané komunikační protokoly a návrh architektury pro urychlení těžby Bitcoinů. Nakonec jsou uvedeny provedené testy implementované architektury, jejich vyhodnocení a návrhy na případné pokračování práce. Abstract This master s thesis deals with virtual currency called Bitcoin. It describes the functioning of the currency of technical perspective especially the implementation of the transaction, the way of its validation and ensuring the integrity by using cryptographic functions. Furthermore, it describes the principle of the Bitcoin creation, particularly mining method called pooled mining. The thesis also describes the communication protocols and design of architecture to acceleration of the bitcoin mining. Finally, there are described tests, assessment and proposals for the continuation of work. Klíčová slova Bitcoin, transakce, bloky, hashovací funkce, těžařské uskupení, urychlení těžby, json-rpc, getblocktemplate, stratum, rychlost hashování, alternativní algoritmy Keywords Bitcoin, transaction, blocks, hash function, pooled mining, mining acceleration, json-rpc, getblocktemplate, stratum, hash rate, alternative algorithms Citace Jan Novotný: Urychlení těžby Bitcoinů, diplomová práce, Brno, FIT VUT v Brně, 2014

4 Urychlení těžby Bitcoinů Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením pana Ing. Michala Kajana. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal Jan Novotný 19. května 2014 Poděkování Chtěl bych poděkovat svému vedoucímu panu Ing. Michalu Kajanovi, za jeho vůli a ochotu diskutovat se mnou všechny problémy, na které jsem při vypracovávání narazil. c Jan Novotný, Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

5 Obsah 1 Úvod 3 2 Bitcoin Hashovací funkce SHA Adresy pro platby Transakce Double-spending Typy transakcí Bloky Merkle tree Časové razítko Síťový čas Aktuální cíl Obtížnost Výpočet hashe hlavičky bloku Řetězec bloků Ověření transakce Těžba Těžařské uskupení Alternativní těžební algoritmy Scrypt Scrypt-A.-Nfactor X SHA-3 (Keccak) Protokoly Protokol JSON-RPC Žádost (Request) Odpověď (Response) Oznámení (Notification) Protokol Getblocktemplate Specifikace protokolu Protokol Stratum Specifikace protokolu Vytvoření hlavičky bloku

6 5 Architektura systému Klient pro komunikaci s pool serverem Komunikace s FPGA Komunikace s pool serverem Implementace Popis programu Architektura pro urychlení těžby Návrh sekvenční architektury Implementace sekvenční architektury Návrh paralelní architektury Implementace paralelní architektury Dosažené výsledky Použité FPGA zařízení FITkit Minerva kit Sekvenční řešení Syntéza Rychlost sekvenčního řešení Testování Paralelní řešení Syntéza Rychlost paralelního řešení Porovnání alternativních algoritmů Porovnání rychlosti Závěr 50 A Obsah CD 54 B Adresářová struktura klienta 55 C Adresářová struktura architektury 56 2

7 Kapitola 1 Úvod Bitcoin je mezinárodní digitální měna, kterou lze platit prostřednictvím decentralizované peer-to-peer (P2P)1 sítě nazývané Bitcoin síť [1]. Síť byla vytvořena v roce 2009 člověkem vystupujícím pod pseudonymem Satoshi Nakamoto. Hlavní výhodou Bitcoinu oproti jiným běžným měnám je decentralizace celého systému, tedy že nemá žádnou centrální autoritu (např. Česká národní banka), která by Bitcoiny spravovala. K zabezpečení sítě je využita kryptografie, která zajišťuje integritu a mimo jiné zabraňuje opakovanému použití již utracených Bitcoinů. Běžná měna, česká koruna nebo euro, je spravována centrální autoritou, která peníze vydává. V případě Bitcoinů se jedná o zcela odlišný princip, kdy jsou Bitcoiny generovány procesem nazvaným těžba (angl. mining). Těžba je proces, při kterém se řeší složitý matematický problém, a který se používá k potvrzení uskutečněných transakcí. Pokud dojde k nalezení řešení, je vygenerována odměna v předem daném množství Bitcoinů (nyní 25 BTC). Odměna pak náleží uživateli (tzv. těžaři), kterému se podařilo nalézt řešení. Těžba Bitcoinů je časově a výpočetně náročný proces, který na běžném procesoru může trvat i několik let. Proto se postupem času začaly pro zrychlení těžby využívat grafické karty, FPGA čipy a specializované procesory typu ASIC 2, které časovou a výpočetní náročnost výrazně snížily. Pro poslední dvě zmíněné zařízení existuje několik komerčních řešení pro urychlení těžby, ale doposud chybí volně dostupné řešení (tzv. open source). Cílem této práce je tedy navrhnout a implementovat volně dostupné řešení pro urychlení težby Bitcoinů. Práce je dále členěna následovně. Druhá kapitola blíže popisuje fungování měny Bitcoin z technického hlediska, především provádění transakcí, způsob jejich potvrzování a zajištění integrity pomocí kryptografických funkcí. Dále popisuje způsob generování Bitcoinů s bližším zaměřením na distribuovanou těžbu formou těžařského uskupení. Třetí kapitola se zabývá používanými komunikačními protokoly v Bitcoin síti. Následující čtvrtá kapitola popisuje návrh architektury systému pro urychlení těžby Bitcoinů. Pátá kapitola diskutuje provedené testy, vyhodnocení výsledků a další možné využití navržené architektury. Závěrečná kapitola diskutuje cíle diplomové práce a možnosti dalšího rozšíření. 1 Tyto sítě nemají žádný centrální server, komunikace probíhá na principu rovný s rovným. 2 Jedná se o integrovaný obvod navržený a vyrobený pro určitou specifickou aplikaci. 3

8 Kapitola 2 Bitcoin Bitcoin je mezinárodní digitální měna. Platby probíhájí prostřednictvím decentralizované peer-to-peer sítě nazývané Bitcoin síť [1, 2], která byla vytvořena v roce 2009 člověkem vystupujícím pod pseudonymem Satoshi Nakamoto. Satoshi nikdy nezveřejnil svou pravou totožnost a po větším rozšíření Bitcoinu se úplně odmlčel. Hlavní výhodou Bitcoinu oproti jiným běžným měnám, je decentralizace celého systému, tedy že nemá žádnou centrální autoritu (např. Česká národní banka), která by Bitcoiny spravovala. Díky tomu není možné měnu padělat, znehodnocovat její hodnotu nebo způsobovat inflaci. Bitcoin je deflační měna, to znamená, že do oběhu bude uvolněno konečné množství peněz, které je předem známé (cca 21 milionů jednotek) a samotné uvolňování peněz je definováno matematickými zákony. Není tedy možné vyvolat umělou inflaci vytvořením většího množství Bitcoinů. Samotné placení, neboli převádění Bitcoinů, se provádí pomocí takzvaných transakcí, které budou dále blíže popsány v sekci 2.3. Zkratka pro Bitcoin je BTC a jeden Bitcoin lze rozdělit až na osm desetinných míst (0, BTC), které se nazývají Satoshi (1 BTC = 10 8 Satoshi). Jednalo se o nejmenší, dále již nedělitelnou jednotku, ale již existuje mechanizmus, který umožňuje rozšířit dělitelnost na ještě menší jednotky [3]. V Bitcoin síti existují dva druhy uživatelů a to koncoví uživatelé a takzvaní těžaři. Koncoví uživatelé si mezi sebou posílají peníze (provádějí transakce). Uživatelé si udržují distribuovanou databázi všech proběhlých transakcí, takzvaný řetězec bloků (angl. block chain) Každý koncový uživatel musí vlastnit alespoň jednu elektronickou peněženku, která se nazývá Bitcoin adresa. Bitcoin adresa slouží jako adresa pro platby a disponuje soukromým a veřejným klíčem (viz sekce 2.2). Pro provedení platby uživatel vytvoří transakci, podepíše ji soukromým klíčem a informuje ostatní uživatele (obdoba všesměrového vysílání, angl. broadcast). Následuje potvrzení transakce, které bude popsáno dále v sekci Těžaři potvrzují transakce a zabezpečují důvěryhodnost sítě výpočetní silou. Za potvrzení bloku získá těžař odměnu (viz sekce 2.4), která je v této době 25 BTC (každé čtyři roky dochází ke snížení odměny o polovinu) a dále poplatky za potvrzení transakcí. Poplatky za transakce jsou dobrovolné a záleží pouze na uživateli, zda je do transakce zahrne. Lze ovšem očekávat, že vlivem snižující se odměny za potvrzení transakce se v budoucnu poplatky stanou nutností. Problematika transakcí a jejich potvrzování bude vysvětlena dále v sekcích 2.3 a

9 2.1 Hashovací funkce Hashovací funkce je jednocestná matematická funkce, která ze vstupních dat libovolné délky vytvoří výstup o dané délce dat, kde délka výstupních dat je určena danou hashovací funkcí [4]. Výstup hashovací fuknce se nazývá hash. Hashovací funkce F musí splňovat následující požadavky: 1. Je aplikovatelná na argument libovolné délky. 2. Její výstupní hodnota má konstantní délku. 3. Odolnost proti získání předlohy (first preimage resistance) - pro dané y není možné nalézt takové x, aby platilo F (x) = y. Jinými slovy, k danému výstupu y nelze zjistit co bylo vstupem funkce F. 4. Odolnost proti získání jiné předlohy (second preimage resistance) - pro dané x není možné nalézt takové y, aby platilo x <> y a zároveň F (x) = F (y). Jinak řečeno, k danému vstupu x nelze najít jiný vstup y, který je odlišný od x a zárověň funkce F produkuje stejný výstup pro oba tyto vstupy. 5. Odolnost proti nalezení kolize (collision resistance) - nelze nalézt libovolné x a y, kde x <> y tak, aby platilo F (x) = F (y). Jinými slovy, nelze nalézt dva libovolné vstupy, které jsou od sebe navzájem různé, a které by produkovaly stejný hash SHA-256 SHA (Secure Hash Algorithm) je hashovací funkce [5], kterou navrhla americká Národní bezpečnostní agentura (NSA). V roce 1993 byla vydána americkým Národním institutem pro standardy (NIST) první verze označovaná jako SHA-0, po které následovala verze SHA- 1 a SHA-2. Verze SHA-2 obsahuje čtyři hashovací funkce a to SHA-224, SHA-256, SHA-384 a SHA-512, kde čísla za pomlčkou značí velikost výsledného hashe v bitech. Pro těžbu Bitcoinů se používá hashovací funkce SHA-256, která produkuje 256-bitový hash z libovolně velkých vstupních dat. Algoritmus hashovací funkce SHA-256 provádí následující kroky: 1. Provede se zarovnání vstupních dat na velikost odpovídající násobku 512 bitů, kdy první bit za daty se nastaví na hodnotu jedna. Následuje daný počet nulových bitů do počtu 512, kdy posledních 64 bitů udává velikost vstupních dat. Například zarovnaný vstup obsahující řetězec abc v šestnáctkové soustavě vypadá následovně: První trojice bajtů odpovídá řetězci abc následuje bajt jehož první bit je nastaven na hodnotu jedna ( = ). Následuje zarovnání na 512 bitů, kde poslední hodnota (18) značí velikost vstupních dat tedy 3*8 = = Zarovnaná vstupní data jsou rozdělena do N 512-bitových bloků. 3. Provede se výpočet hashe [5]. 5

10 Příklad výsledného hashe (v hexadecimálním tvaru), vytvořeného pomocí hashovací funkce SHA-256, pro vstupní data abc vypadá následovně: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad SHA-256 se vyznačuje takzvaným lavinovým efektem [6]. Tento efekt způsobuje, že i ta nejmenší změna vstupních dat vyvolá velkou změnu výstupních dat. Následující tabulka 2.1 zobrazuje změnu výstupních dat při změně jednoho znaku ve vstupních datech. vstupní data The quick brown fox jumps over the lazy dog The quick brown fox jumps over the lazy cog výstupní data (hash) d7a8fbb307d ca9abcb0082e4f8d5651e46d3cdb762d0 2d0bf37c9e592 ef537f25c895bfa a9b63d97aa631564d5d789c2b c8635fb6c Tabulka 2.1: Příklad změny hashe při změně jednoho znaku na vstupu. 2.2 Adresy pro platby Adresa pro platby, takzvaná Bitcoin adresa, je řetězec alfanumerických znaků o délce většinou 33 nebo 34 znaků (např. 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM). Vzhledem k riziku možných překlepů neobsahuje znaky 0,O,l,I díky jejich podobnosti. Na tyto adresy si uživatelé zasílají Bitcoiny. Každý uživatel si může vygenerovat libovolný počet adres. Vzhledem k anonymitě se doporučuje pro každý příjem vytvořit novou adresu. Vytvoření adresy probíhá následovně: 1. Pomocí kryptografického algoritmu ECDSA se vygeneruje dvojice soukromý a veřejný klíč [7]. 2. Vezme se veřejný klíč a zahashuje se pomocí hashovacího algoritmu SHA-256 [5]. 3. Výsledek z druhého kroku se zahashuje pomocí algoritmu RIPEMD-160 [8]. 4. Začátek výsledného hashe z třetího kroku se doplní o bajt, který reprezentuje verzi (angl. version bajt), který je pro standardní Bitcoin sítě 0x Dále se dvakrát zahashuje výsledek z předchozího kroku pomocí SHA Jako kontrolní součet se použíjí první čtyři bajty z dvojnásobného hashe vytvořeného v předchozím kroku. 7. Kontrolní součet z kroku šest se připojí na konec výsledku z kroku čtyři a vytvoří se tak 25 bajtová bitcoin adresa. 8. Výsledná 25 bajtová bitcoin adresa se zkonvertuje na alfanumerický řetězec v kódování Base58Check [9]. Bitcoin adresa je tedy ve skutečnosti 160 bitový hash veřejného klíče vygenerovaného pomocí kryptografického algoritmu ECDSA (soukromý klíč slouží na podepisování transakcí, viz 2.3). Kontrolní součet obsahuje Bitcoin adresu z toho důvodu, aby se zabránilo neúmyslnému zaslání Bitcoinů na chybně zapsanou adresu. 6

11 2.3 Transakce Jak již bylo uvedeno výše, pomocí transakcí probíhá zasílání Bitcoinů mezi uživateli. Transakce je podepsaná část dat, která obsahuje seznam vstupů a výstupů a několik dalších položek, které jsou obsaženy v tabulce 2.2 a kde je popsán jejich význam a velikost [10]. pole popis velikost [B] version no verze formátu dat transakce, aktuálně se nastavuje na 1 4 in-counter celé kladné číslo udávající počet vstupů transakce 1-9 list of inputs seznam vstupů transakce různé out-counter celé kladné číslo udávající počet výstupů transakce 1-9 list of outputs seznam výstupů transakce různé lock time udává číslo bloku nebo časové razítko uzamčení transakce 4 Tabulka 2.2: Obsah transakce. Vstupní a výstupní části transakce obsahují další pole, která budou popsána níže. Vstupní část transakce obsahuje následující pole: Previous tx je hash předcházející transakce. Index je číslo označující specifický výstup v předcházející transakci. ScriptSig obsahuje dvě položky. První z nich je podpis transakce vytvořený odesílatelem. Druhá položka je veřejný klíč příjemce. Odesílatel uvedením veřejného klíče příjemce udává, kdo může s transakcí dále manipulovat a komu patří v ní obsažené Bitcoiny. Výstupní část transakce obsahuje následující pole: Value udává počet zasílaných Bitcoinů v jednotkách Satoshi (1 BTC = 10 8 Satoshi). ScriptPubKey společně s položkou scriptsig slouží k prokázání vlastnictví Bitcoinů. Položka obsahuje Bitcoin adresu příjemce a dále operace pro skriptovací jazyk udávající jakým způsobem bude s transakcí nakládáno, viz Tabulka 2.3 zobrazuje příklad transakce s jedním vstupem a jedním výstupem. V této transakci je zasláno 50 BTC z předchozí transakce f5d8... z výstupu 0 na Bitcoin adresu , která je v tomto případě v hexadecimálním formátu a ne v běžném formátu base58. input previous tx f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd0 index 0 scriptsig e21798a42fae0e854281abd38bacd1aeed3ee db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7 output value scriptpubkey OP DUP OP HASH fa9bd789a2fcd52d2c580b65d35549d OP EQUALVERIFY OP CHECKSIG Tabulka 2.3: Příklad transakce. 7

12 Samotné vytvoření transakce probíhá následovně: 1. Vytvoří se hash, pomocí kryptografického algoritmu SHA-256, veřejného klíče příjemce a hodnoty hashe předchozí transakce (transakce, se kterou má odesílatel právo manipulovat). 2. Takto vzniklý hash se podepíše soukromým klíčem odesílatele pomocí kryptografického algoritmu ECDSA. 3. Tento podepsaný hash a veřejný klíč příjemce se uloží do položky skriptsig nově vzniklé transakce. Nakonec se nově vzniklá transakce pomocí všesměrového vysílání odešle všem uživatelům v Bitcoin síti. Ostatní uživatelé v síti si mohou pomocí veřejného klíče odesílatele ověřit podepsaný hash transakce. Takto je možné ověřit, že se jedná o transakci vytvořenou skutečným uživatelem. Veřejný klíč příjemce, obsažený v transakci udává, že s ní může příjemce manipulovat. Transakce ovšem ještě není potvrzená, to bude popsáno v sekci 2.4. Na obrázku 2.2 jsou zobrazeny tři transakce vždy s jedním vstupem a jedním výstupem a princip jejich vytváření. Jak již bylo zmíněno výše, transakce mohou obsahovat i více vstupů a výstupů. Množství vstupů lze ovlivnit uvedením více předchozích transakcí, respektive uvedením více výstupů z jedné nebo více předchozích transakcí a množství výstupů lze ovlivnit uvedením více veřejných klíčů příjemců. Většinou se využívá transakce s jedním vstupem a dvěma výstupy, kde jeden výstup se použije pro zaslání Bitcoinů příjemci a druhý výstup se použije pro vrácení zbytku Bitcoinů odesílateli (viz obrázek 2.1). Pokud je suma výstupních Bitcoinů menší než suma vstupních Bitcoinů, tak se rozdíl použije jako transakční poplatek. Dále také lze díky více vstupům a výstupům zasílat libovolné množství Bitcoinů. Pokud by transakce obsahovala pouze jeden vstup a jeden výstup, pak by bylo možné přijatou transakci pouze opět zaslat jinému uživateli bez možnosti ovlivnit v ní obsažené množství Bitcoinů. 3,14 BTC 3,0 BTC Odesílatel Transakce Příjemce 0,14 BTC Obrázek 2.1: Ukázka zaslání tří Bitcoinů příjemci. Zbytek je navrácen zpět odesílateli. 8

13 Transakce Transakce Transakce Veřejný klíč Veřejný klíč Veřejný klíč uživatele B uživatele C uživatele D Hash Hash Hash ověření ověření Podpis Podpis Podpis uživatele A uživatele B uživatele C podepsání podepsání Soukromý klíč Soukromý klíč Soukromý klíč uživatele B uživatele C uživatele D Obrázek 2.2: Ukázka tří na sebe navazujících transakcí Double-spending Double-spending je problém dvojího zaslání transakce, který by mohl nastat tak, že po odeslání transakce by došlo k vložení jiného veřejného klíče příjemce do transakce. Následně by se veřejný klíč zahashoval s původní předchozí transakcí, podepsal a odeslal všem uživatelům v síti. Kdokoli by takto mohl nekontrolovatelně množit Bitcoiny. Tento problém se řeší tím způsobem, že všichni uživatelé Bitcoin sítě si udržují kompletní databázi všech provedených transakcí - takzvaný řetězec bloků (viz 2.4.7). Pokud se tedy někdo pokusí utratit již utracené Bitcoiny, všichni uživatelé sítě o tom budou vědět Typy transakcí Pro prokazování vlastnictví Bitcoinů se využívá skriptovací jazyk [11], který je založen na použití zásobníkové datové struktury. Do zásobníku se vloží položky skriptsig a script- PubKey z transakce, u které chceme ověřit vlastnictví. Vlastnictví je ověřené, pokud je hodnota na vrcholu zásobníku rovna true (true = 1). Skriptovací jazyk podporuje různě složité podmínky a lze tak vytvořit různé typy transakcí. Momentálně se však používají tři základní typy následujících transakcí [10]: Převod Bitcoinů na Bitcoin adresu Jak již napovídá název, tento typ transakce se využívá pro převedení Bitcoinů na jinou Bitcoin adresu. Pro odeslání takové transakce je nutné doplnit do polí scriptpubkey a scriptsig následující informace: 9

14 scriptpubkey: OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG scriptsig: <sig> <pubkey> Pole scriptsig v tomto případě obsahuje dvě položky. První z nich je podpis transakce vytvořený odesílatelem <sig>. Druhá položka je veřejný klíč příjemce <pubkey>. Pole scriptpubkey obsahuje několik položek udávajících ověřovací operace pro skriptovací jazyk a také Bitcoin adresu <pubkeyhash>, na kterou jsou Bitcoiny zaslány. Ověření vlastnictví je znázorněno v následující tabulce: krok zásobník skript (vrchol vpravo) 1. prázdný <sig><pubkey> OP DUP OP HASH160 <pubkeyhash> OP EQUALVERIFY OP CHECKSIG 2. <sig><pubkey> OP DUP OP HASH160 <pubkeyhash> OP EQUALVERIFY OP CHECKSIG 3. <sig><pubkey><pubkey> OP HASH160 <pubkeyhash> OP EQUALVERIFY OP CHECKSIG 4. <sig><pubkey><pubhasha> <pubkeyhash> OP EQUALVERIFY OP CHECKSIG 5. <sig><pubkey><pubhasha> OP EQUALVERIFY OP CHECKSIG <pubkeyhash> 6. <sig><pubkey> OP CHECKSIG 7. true nebo false prázdný Tabulka 2.4: Ověření skriptu pro převod Bitcoinů na Bitcoin adresu. Tabulka 2.4 udává způsob prokázání vlastnictví Bitcoinů obsažených v transakci vyhodnocením skriptu pomocí zásobníkové datové struktury. Význam jednotlivých kroků je následující: 1. Pole scriptsig a scriptpubkey se spojí. 2. Položky sig a pubkey se vloží na zásobník. 3. Vrchní položka pubkey se zduplikuje. 4. Vypočítá se 160 bitový hash vrchní položky (hash(pubkey) = pubhasha). 5. Na zásobník se vloží pubkeyhash (160 bitový hash veřejného klíče). 6. Porovnají se první dvě položky na zásobníku (pubhasha == pubkeyhash). 7. Dojde k ověření podpisu a na zásobník je uložen výsledek skriptu true nebo false. Převod Bitcoinů na IP adresu Tento typ transakcí je podporován už jen pouze některými staršími Bitcoin klienty. Odesílatel se prostřednictvím Bitcoin klienta připojí ke klientovi příjemce na zadané IP adrese a získá od příjemce jeho veřejný klíč. Odesílatel do transakce, konrétně do položky scriptpubkey, vloží veřejný klíč příjemce. Příjemce prokáže vlastnictví Bitcoinů vytvořením platného digitálního podpisu k danému veřejnému klíči. 10

15 scriptpubkey: <pubkey> OP_CHECKSIG scriptsig: <sig> Následující tabulka 2.5 udává způsob prokázání vlastnictví Bitcoinů na základě vyhodnocení skriptu: krok zásobník skript (vrchol vpravo) 1. prázdný <sig><pubkey> OP CHECKSIG 2. <sig><pubkey> OP CHECKSIG 3. true nebo false prázdný Tabulka 2.5: Ověření skriptu pro převod Bitcoinů na IP adresu. 1. Pole scriptsig a scriptpubkey se spojí. 2. Položky sig a pubkey se vloží na zásobník. 3. Dojde k ověření podpisu a na zásobník je uložen výsledek skriptu true nebo false. Coinbase transakce Coinbase transakce nebo-li odměnu generující transakce je obsažena v každém bloku (viz sekce 2.4). Tato transakce slouží k odměnění těžaře, který blok vytvořil. Transakce má jeden vstup a místo položky scriptsig obsahuje položku coinbase. Není definováno, co má položka coinbase obsahovat, ale většinou obsahuje informace o obtížnosti generování. Výstupní část transakce může v scriptpubkey obsahovat libovolné pravidlo, nejčastěji se však používá pravidlo podobné pravidlu používanému při převodu Bitcoinů na IP adresu. Příklad coinbase transakce zobrazuje tabulka 2.6. input previous tx f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd0 index 0 coinbase e21798a42fae output value scriptpubkey fa9bd789a2fcd52d2c580b65d35549d OP CHECKSIG 2.4 Bloky Tabulka 2.6: Příklad coinbase transakce. Po vytvoření transakce uživatelem je transakce rozeslána pomocí všesměrového vysílání po celé Bitcoin síti a je třeba ji potvrdit. Takto rozeslané transakce zaznamenávají těžaři a vkládají je do takzvaných bloků. Blok je tedy soubor obsahující transakce a další údaje [12]. Transakci lze vložit do bloku pouze pokud je platná a ještě se nenachází v řetězci bloků. Transakce se stane ověřenou po jejím vložení do řetězce bloků (viz sekce 2.4.8). Tabulka 2.7 zobrazuje jednotlivé položky obsažené v těle bloku. Každý blok obsahuje velikost bloku, hlavičku bloku, počet obsažených transakcí a transakce samotné (viz tabulka 2.8). 11

16 pole popis velikost [B] magic no vždy se nastavuje na 0xD9B4BEF9 4 blocksize udává velikost bloku 4 blockheader obsahuje šest položek hlavičky viz tabulka transaction counter celé kladné číslo udávající počet transakcí 1-9 transactions obsahuje neprázdný seznam transakcí různé Tabulka 2.7: Obsah bloku. Hlavička bloku obsahuje šest položek, které jsou zobrazené v tabulce 2.8. Jednou z položek je 256-bitový hash hlavičky předchozího bloku. Tento hash slouží pro zřetězení bloků v řetězci bloků. Další položkou je 256-bitový hash kořene Merkle stromu (viz sekce 2.4.1). Položka time obsahuje aktuální čas vytvoření bloku a je blíže popsána v sekci Význam dalších položek bits a nonce je vysvětlen v sekcích a pole popis velikost [B] version číslo verze bloku 4 hashprevblock 256-bitový hash hlavičky předchozího bloku 32 hashmerkleroot 256-bitový hash kořene Merkle stromu 32 time aktuální časové razítko 4 bits aktuální cíl (target) 256-bitové číslo 4 nonce 32-bitové číslo (bude popsáno dále) 4 Tabulka 2.8: Obsah hlavičky bloku Merkle tree Jedná se o datovou strukturu umožňující efektivní a bezpečné ověření obsahu rozsáhlých datových struktur, ve které každý nelistový uzel obsahuje hash svých synovských uzlů [13]. Samotné listové uzly pak mohou obsahovat rozsáhlé datové struktury, v tomto případě transakce. Příklad Merkle stromu je zobrazen na obrázku 2.3. Obrázek 2.3: Merkle strom [14]. Jako hashovací funkce je zde použita funkce SHA-256. Vytvoření Merkle stromu probíhá následnovně: 12

17 1. Jednotlivé transakce se dvakrát zahashují (SHA-256(SHA-256(transakce))). Vzniknou tak hashe jednotlivých transakcí. V případě, že by strom obsahoval lichý počet takto vzniklých hashů, je nutné poslední z nich duplikovat, viz obrázek Každé dva vzniklé hashe z předchozího kroku jsou žřetězeny a znovu dvakrát zahasovány, čímž vzniknou další hashe. Opakováním tohoto kroku se tak vytváří strom na jehož konci vznikne poslední kořenový hash, který se použije pro zahrnutí do hlavičky bloku. Obrázek 2.4: Příklad vytvoření Merkle stromu [14] Časové razítko Každý blok obsahuje 4-bajtové unixové časové razítko, které je reprezentováno jako bezznaménkové celé číslo. Je tak vyřešen problém roku 2038 [15] jeho zpožděním o 68 let. Časové razítko se využívá při ověření platnosti bloku a zamezuje tak modifikaci řetězce bloků. Dále slouží jako zdroj náhodnosti pro výpočet hashe hlavičky bloku Časová značka je považována za platnou, pokud je větší než medián časových značek posledních 11 bloků a zárověň je menší než aktuální síťový čas + 2 hodiny (síťový čas je popsán v sekci 2.4.3). Časová značka tedy může udávát čas maximálně dvě hodiny do budoucnosti Síťový čas Síťový čas je medián časových značek získaných od uzlů připojených do Bitcoin sítě. Po vytvoření spojení získá uzel od ostatních připojených uzlů aktuální časová razítka. Od jednotlivých časových razítek odečte svůj aktuální čas a vypočítané rozdíly si uloží. Ze všech uložených rozdílů vypočítá medián a přičte ho k aktuálnímu času. Pokud je výsledný čas větší než aktuální čas + 70 minut, pak se jako síťový čas nastaví aktuální čas. V opačném případě se jako síťový čas nastaví medián všech časových značek od připojených uzlů Aktuální cíl Pole bits je 256-bitová hodnota, sdílená všemi uživateli v Bitcoin síti, nazývaná jako aktuální cíl (angl. target) [16]. Aktuální cíl určuje maximální přípustnou hodnotu hashe hlavičky 13

18 bloku. Čím nižší je aktuální cílová hodnota, tím těžší je vytvořit nový blok. Aktuální cílová hodnota závisí na aktuální výpočetní síle těžařů a k její aktualizaci dochází pravidelně po vytvoření 2016 bloků (cca 14 dní) tak, aby se průměrně za deset minut vytvořil jeden blok Obtížnost Obtížnost udává, jak složité je vytvořit nový blok v porovnání s nejjednodušším případem [17]. Obtížnost se vypočítá následujícím způsobem: obtiznost = maximalni hodnota cile / aktualni hodnota cile Hodnota obtížnosti se tedy mění se změnou hodnoty aktuálního cíle Výpočet hashe hlavičky bloku Pro výpočet hashe hlavičky bloku jsou důležitá dvě pole a to pole bits (aktuální cíl) a nonce. Pole nonce je 32-bitové číslo a slouží jako zdroj náhodnosti (společně s časovým razítkem) při výpočtu hashe. Samotný hash hlavičky bloku se vypočítá jako dvojnásobný hash hlavičky bloku vytvořený pomocí hashovací funkce SHA-256 následovně: hash = SHA-256(SHA-256(hlavička bloku)) Výpočet hashe hlavičky bloku se dále využívá při takzvané těžbě bitcoinů (angl. mining), která bude vysvětlena v sekci Řetězec bloků Řetězec bloků (angl. block chain) je distribuovaná databáze všech transakcí [18]. Jedná se o řetězec na sebe navazujících bloků, kde každý blok obsahuje hash hlavičky předchozího bloku a díky tomu tvoří řetězec (viz obrázek 2.5). Počáteční blok, který byl vytvořen jako první, se nazývá genesis blok. Je nutné, aby na sebe bloky navazovaly podle času vytvoření, jinak by nebylo možné správně určit odkaz na předcházející blok. Těžaři navazují nové bloky vždy na konec nejdelší větve řetězce bloků. Na obrázku 2.6 je vidět větvení řetězce bloků, které je způsobené tím, že se dvěma těžařům podařilo vytvořit blok přibližně ve stejný čas. Za platnou větev se prohlásí ta větev, která se dříve prodlouží. Bloky ve vedlejší větvi se označují jako osiřelé bloky. Transakce obsažené v osiřelých blocích, pak ztrácí svoje ověření a je třeba je znovu zahrnout do nového bloku (toto neplatí pro transakci generující odměnu). Délka řetězce bloků se určuje podle složitosti jednotlivých bloků ne podle jejich počtu. Zabrání se tak, aby někdo vytvořil několik bloků s nízkou složitostí a změnil tak hlavní větev řetězce bloků. 14

19 Obrázek 2.5: Obsah a návaznost jednotlivých bloků [14]. Obrázek 2.6: Řetězec bloků (angl. block chain) [14] Ověření transakce Každý nový blok obsahuje odkaz (hash hlavičky) na předcházející blok a tím potvrzuje transakce zahrnuté ve všech předcházejících blocích [19]. Pokud tedy vytvoříme transakci, je její ověřenost nula. Zahrnutím transakce do nového bloku v řetězci bloků se její ověřenost změní na jedna. Každý další nový blok zahrnutý v řetězci bloků zvýší ověřenost této transakce o jedna. Aby se transakce stala ověřenou, je třeba dosáhnout ověřenosti šest. Tedy navázat na blok, ve kterém je transakce obsažena, dalších pět bloků. 2.5 Těžba Těžbou (angl. mining) se nazývá proces vytváření bloků, při kterém těžaři hledají odpovídající hash hlavičky bloku daného aktuální složitostí a po jeho nalezení získávají odměnu (aktuálně 25 BTC) [20]. Proces těžby probíhá následujícím způsobem: 1. Výpočítá se hash hlavičky bloku, kde hodnota nonce je, při prvním pokusu výpočtu hashe hlavičky bloku, rovna nule. 2. Pokud je výsledná hodnota hashe menší než aktuální cíl, podařilo se nalézt odpovídající hash hlavičky bloku. Pokud hodnota hashe není menší než aktuální cílová hodnota, zvýší se hodnota nonce o jedna a provede se nový výpočet hashe hlavičky bloku. Takto probíhá výpočet až do doby, kdy se podaří nalézt hash s odpovídající složitostí nebo dojde k nalezení hashe jiným těžařem. 3. Po úspěšném nalezení hashe hlavičky bloku, oznámí těžař ostatním těžařům, že našel odpovídající hash. Ostatní těžaři tedy ukončí aktuální hledání hashe a začnou s novým 15

20 hledáním hashe, do kterého zahrnou nové transakce, které se ještě nenachází v žádném z vytvořených bloků. Pro hledání odpovídajícího hashe hlavičky bloku se zpočátku používaly běžné procesory. Nalezení odpovídajícího hashe je ale velice časově a výpočetně náročný proces, a proto se pro těžbu začaly využívat grafické karty, následovalo využití FPGA čipů [21] a nakonec specializovaných procesorů typu ASIC [22]. Následující tabulka 2.9 zobrazuje příklady jednotlivých zařízení, jejich průměrnou rychlost a maximální dobu potřebnou pro nalezení hashe. typ zařízení rychlost [MHash/s] max. čas potřebný pro nalezení hashe CPU - Core i dnů GPU - GTX dnů FPGA - X6500 FPGA Miner dnů ASIC - KnC Jupiter dnů Tabulka 2.9: Ukázka rychlosti jednotlivých zařízení. Z tabulky 2.9 lze zjistit, že jedinému těžaři by s pouhým CPU nebo GPU trvalo roky nalézt odpovídající hash. Proto se využívá distribuovaná metoda těžby (angl. pooled mining), která je popsaná níže Těžařské uskupení Těžařské uskupení (angl. pooled mining) je distribuovaná metoda těžení bitcoinů, kdy se hledání jednoho hashe hlavičky bloku rozdělí mezi více těžařů [23]. Ti tak spolupracují na nalezení hashe a jsou odměňováni za odvedenou práci. Pool server (server, který provozuje těžařské uskupení) přiděluje těžařům práci s menší složitostí než je aktuální složitost v Bitcoin síti. Tím, že těžaři hledají hash s nižší složitostí než je ve skutečnosti potřeba, dochází k odmítnutí většiny nalezených řešení. Někdy ale nalezené řešení odpovídá aktuální složitosti v Bitcoin síti a podaří se tak získat odměnu. Existuje několik možností, jakým způsobem lze rozdělit odměnu mezi těžaře, nejčastěji se však používá proporciální odměňování, kdy jsou těžaři odměňováni za počet odevzdaných řešení (nalezených hashů). Nejvýznamnější těžební servery a jejich podíl na celkové těžbě Bitcoinů zobrazuje obrázek 2.7. Tabulka 2.10 zobrazuje několik nejpoužívanějších těžebních klientů a protokoly, které podporují. 16

21 Obrázek 2.7: Jednotlivé těžební servery a jejich podíl na celkové těžbě [24]. klient podpora jednotlivých protokolů getwork getblocktemplate stratum BFG ano ano ano BitMinter ano ne ne BTCMiner ano ne ne cgminer ano ano ano Diablo ano ne ne EasyMiner ano ne ne gminor ano ne ne GroupFabric ano ne ano MPBM ano ne ano OSFPGABM ano ne ne Phoenix ano ne ne poclbm ano ne ano Ufasoft ano ano ano Tabulka 2.10: Přehled těžebních klientů a podporovaných protokolů. 17

22 Kapitola 3 Alternativní těžební algoritmy V této kapitole jsou popsány algoritmy pro těžbu alternativních digitálních měn. Jedná se o alternativní algoritmy k algoritmu SHA-256, který se používá při těžbě Bitcoinů. 3.1 Scrypt Scrypt je funkce pro derivaci klíče [25]. Jedná se o výpočetně velice náročný algoritmus, který ze zadaného hesla vytvoří šifrovací klíč. Algoritmus Scrypt je navržen tak, aby měl velké paměťové nároky, respektive vyžadoval spoustu náhodných přístupů do paměti a znemožnil tak útok hrubou silou. Pro těžbu digitálních měn se algoritmus začal používat z důvodu čím dál většího využívání těžby na zařízeních ASIC, čímž došlo k znehodnocení těžby na běžných procesorech. Vzhledem ke své paměťově náročnosti se algoritmus Scrypt v hardwaru (ASIC) nepoužívá díky velké ceně pamětí. Algoritmus tak umožnil znovu využít běžné procesory a později i grafické karty k těžbě alternativních měn jako například Litecoin [26], Novacoin [27] nebo FeatherCoin [28]. Nicméně dnes se již začínají objevovat první ASIC řešení implementující Scrypt algoritmus. 3.2 Scrypt-A.-Nfactor Scrypt-A.-Nfactor (Scrypt Adaptive N-factor) je upravená verze algoritmu Scrypt. Vznikl jako rekce na implementaci Scrypt algoritmu v zařízeních ASIC [29]. Původní Scrypt algoritmus používá pro svou funkci určité množství paměti N. Každá alternativní měna používající algoritmus Scrypt využívá pevně dané množství paměti N pro běh algoritmu. Tento fakt využívá Scrypt-A.-Nfactor tím způsobem, že v průběhu času se mění používané množství paměti N. Lze takto eliminovat ASIC zařízení, které budou implementována na pevnou velikost paměti a po její změně se stanou nefunkčními, protože už nebudou správně implementovat algoritmus s novými parametry. Tento nový algoritmus využívají například digitální měny Execoin [30], Vertcoin [31] nebo GPU Coin [32]. 3.3 X11 Algoritmus X11 vznikl jako alternativa k algoritmu Scrypt-A.-Nfactor a pro svou funkci využívá jedenáct již existujících vysoce výkonných hashovacích funkcí, které jsou zřetězeny za sebou jmenovitě blake, bmw, groestl, jh, keccak, skein, luffa, cubehash, shavite, simd a echo [33]. Důvodem proč byl algoritmus vytvořen, je ochrana těžařů, kteří využívají 18

23 grafické karty, před CPU botnety, které pro těžbu využívají velké množství procesorů, a před ASIC řešeními. Vzhledem k tomu, že algoritmus používá jedenáct různých hashovacích funkcí, je nepravděpodobné, aby se v nejbližší době objevilo řešení implementované na ASIC zařízení, díky vysokým nákladům na jeho výrobu. Tento algoritmus využívá například digitální měna Hirocoin [34] nebo Lime Coin [35]. 3.4 SHA-3 (Keccak) SHA-3 (původní název Keccak) je kryptografická hashovací funkce, která byla určena jako nástupce starších hashovacích funkcí SHA-1 a SHA-2 [36]. Hashovací funkce SHA-3 dosahuje vyšších rychlostí při implementaci v hardwaru a je bezpěčnější než její předchůdci. Z hlediska využití hashovací funkce SHA-3 při těžbě digitálních měn, byl tento algoritmus nasazen proto, aby odstranil rychlostní rozdíly při těžbě na grafických kartách NVidia a grafických kartách AMD. Tento hashovací algoritmus využívají například digitální měny Maxcoin [37], Slothcoin [38] nebo Copper Lark [39]. 19

24 Kapitola 4 Protokoly Pro komunikaci mezi klientem a pool serverem existuje několik protokolů, z nichž nejpoužívanější jsou dva z nich a to konkrétně protokol Getblocktemplate a protokol Stratum. Oba protokoly pracují na principu dotaz-odpověď (angl. request-response) a využívají k tomu technologii volání vzdálených procedur používající v tomto případě protokol JSON-RPC [40]. 4.1 Protokol JSON-RPC Protokol JSON-RPC se používá pro volání vzdálených procedur a využívá k tomu kódování JSON. Jedná se o velmi jednoduchý protokol založený na principu dotaz-odpověď, kdy je mezi dvěma uzly vytvořeno spojení. Během tohoto spojení může uzel vyvolat metodu (proceduru) poskytovanou druhým uzlem (obvykle se používá architektura klient-server). Protokol definuje pouze několik datových typů a příkazů. Z jednoduchých datových typů jsou k dispozici pouze řetězce, čísla, pravdivostní hodnoty a hodnota null. Ze strukturovaných datových typů jsou to objekty a pole Žádost (Request) Pro zavolání vzdálené procedury zašle klient žádost. Žádost obsahuje následující tři položky: method - řetězec obsahující jméno volané procedury (metody), params - pole objektů obsahující parametry volané procedury, id - identifikátor žádosti libovolného typu. Identifikátor slouží pro správné spojení žádosti s odpovědí v případě zaslání více zádostí. Příklad žádosti protokolu JSON-RPC: { "method": "echo", "params": ["Hello JSON-RPC"], "id": 1 } 20

25 4.1.2 Odpověď (Response) Odpověď zaslaná po přijetí žádosti a následném provedení procedury. Odpověď obsahuje následující tři položky: result - objekt vrácený volanou procedurou (výsledek). V případě, že dojde k chybě při volání procedury, vrací se hodnota null, error - objekt udávající bližší popis chyby v případě, že dojde k chybě při volání procedury, v opačném případě je nastaven na null, id - identifikátor odpovědi libovolného typu. Identifikátor musí být stejný, jako byl identifikátor příslušné žádosti. Příklad odpovědi protokolu JSON-RPC: { "result": "Hello JSON-RPC", "error": null, "id": 1 } Oznámení (Notification) Oznámení je speciální případ žádosti, na kterou ovšem není zaslána odpověď. Oznámení obsahuje stejné položky jako žádost pouze s tím rozdílem, že položka id musí být nastavena na null. 4.2 Protokol Getblocktemplate Jedná se o decentralizovaný protokol pro těžbu v těžarském uskupení (v poolu) vyvinutý bitcoin komunitou [41]. Decentralizace spočívá v ponechání vytváření bloku na klientovi. V dřívějším protokolu označovaném jako getwork předal pool server klientovi již vytvořený blok a klient pouze počítal správnou hodnotu nonce a neměl možnost ovlivnit, jaké transakce budou v bloku zahrnuty. V protokolu Getblocktemplate pool server pouze předá klientovi potřebné hodnoty pro vytvoření bloku a přenechá tvorbu bloku a jeho výpočet na klientovi. Klient tak může ovlivnit, jaké transakce do bloku zahrne a jaké nikoliv. Přenecháním vytváření bloků na straně klienta došlo i k výraznému zrychlení komunikace (cca 1000 GHash/s a více). Starší protokol getwork dosahoval rychlosti maximálně cca 4 GHash/s. Protokol Getblocktemplate byl navržen tak, aby byl flexibilní a v případě potřeby bylo možné jeho jednoduché rozšíření o další funkce Specifikace protokolu Pro zahájení těžby pošle klient inicializační žádost s názvem getblocktemplate [42]. Odesláním této žádosti klient žádá o zaslání údajů potřebných k vytvoření bloku. Parametry žádosti jsou uvedeny v tabulce

26 parametr povinné typ popis capabilities ne pole řetězců obsahuje možnosti, které klient podporuje: longpoll, coinbasetxn, coinbasevalue, proposal, serverlist, workid mode ne řetězec nastavuje se na template nebo neuvádí Tabulka 4.1: Parametry žádosti getblocktemplate. Příklad tvaru žádosti getblocktemplate: { "id": 0, "method": "getblocktemplate", "params": [\{"capabilities": ["coinbasetxn","workid","coinbase/append"]\}] } Po zaslání žádosti getblocktemplate zašle pool server odpověď, která obsahuje údaje potřebné k zahájení těžby. Parametry odpovědi jsou uvedeny v tabulce 4.2. parametr povinné typ popis bits ano řetězec aktuální obtížnost v hexadecimálním formátu curtime ano číslo aktuální časové razítko serveru height ano číslo číslo udávající velikost bloku previousblockhash ano řetězec hash hlavičky předchozího bloku v hexadecimálním formátu (big-endian) sigoplimit ne číslo maximální možný počet operací pro ověření vlastnictví transakce pomocí skriptu sizelimit ne číslo maximální možná velikost bloku v bajtech transactions ano pole objektů neprázdné pole objektů obsahujících informace o jednotlivých transakcích version ano číslo číslo verze bloku coinbaseaux ne objekt údaje, které by měly být obsaženy v položce scriptsig coinbase transakce coinbasetxn ne objekt transakce sloužící k zaslání odměny coinbasevalue ne číslo informace o odměně workid ne řetězec řetězec sloužící k identifikaci odevzdané práce při jejím následném potvrzení expires ano číslo udává dobu platnosti zadané práce (v sekundách) target ano řetězec aktuální cíl v hexadecimálním formátu (big-endian) Tabulka 4.2: Parametry odpovědi na žádost getblocktemplate. 22

27 Příklad odpovědi na žádost getblocktemplate: { "error": null, "result": { "coinbasetxn": { "data": " ffffffff d0f00456c dc66 085fffffffff02fff1052a a9144ebeb1cd26d d60d3e0ed7d0da248fb88ac a9147c866aee1fa2 f3b3d5effad576df3dbf1f ac "}, "previousblockhash": " d424dec1c660a68456b8271d09628a80cc62583e 5904f5894a2483c", "transactions": [], "expires": 120, "target": "000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff", "longpollid": "some gibberish", "height": 23957, "version": 2, "curtime": , "mutable": ["coinbase/append"], "bits": "ffff001d"}, "id": 0 } Po nalezení bloku, odešle klient žádost submitblock o jeho potvrzení. Parametry žádosti jsou zobrazeny v tabulce 4.3. parametr povinné typ popis - ano řetězec blok v hexadecimálním formátu workid ne řetězec řetězec sloužící k identifikaci odevzdané práce Tabulka 4.3: Parametry žádosti submitblock. Příklad žádosti submitblock: { "id": 0, "method": "submitblock", "params": [" c48a294584f90e58325c60ca82896d071826b45680a661cec4d42 4d de6433d46c0c7f50d84a05aec77be cdd47f77e344b6f5 0c84380fddba66dc47501d00ffff ffffffff d0f00456c dc66085fffffffff02fff1052a a9144ebeb1cd26d d60d3e0ed7d0da248fb88ac a9147c866aee1fa2f3b3d5effad576df3dbf1f ac "] } 23

28 4.3 Protokol Stratum Protokol Stratum je nový protokol (vytvořen v roce 2012), který nahradil zastaralý protokol getwork [43, 44]. Protokol výrazně redukuje množství komunikace s pool serverem, díky čemuž dochází k výraznému snížení zatížení pool serveru. Zásadní výhodou protokolu je rozdělování práce určené jednotlivým těžařům serverem. Těžaři je umožněno inkrementovat hodnotu extranonce2 v coinbase transakci a vytvářet merkle root hash pro hlavičku bloku (extranonce2 je další, v pořadí již třetí, položka náhodnosti společně s nonce a časovým razítkem - ntime). Těžař si tak může sám plynule vytvářet novou práci bez toho, aniž by musel kontaktovat pool server a provádí přidělenou práci, dokud mu pool server nezašle novou práci. Protokol využívá jedno asynchronní spojení s pool serverem na místo opětovného otevírání a zavírání nového HTTP spojení pro každou komunikaci Specifikace protokolu Pro zahájení těžby pošle klient inicializační žádost s názvem mining.subscribe. Žádost neobsahuje žádné parametry pouze název procedury a identifikátor žádosti. Příklad žádosti mining.subscribe: { "id": 1, "method": "mining.subscribe", "params": [] }\n Po zaslání žádosti mining.subscribe zašle pool server odpověď, která obsahuje parametry a údaje uvedené v tabulce 4.4. parametr mining.set difficulty mining.notify extranonce1 extranonce2 size popis signalizuje těžaři, že se změnila obtížnost a udává hodnotu nové obtížnosti udává unikátní řetězec použitý pro komunikaci data potřebná pro sestavení coinbase transakce data potřebná pro sestavení coinbase transakce Tabulka 4.4: Parametry odpovědi na žádost mining.subsribe. Příklad odpovědi na žádost mining.subscribe: { "id": 1, "result": [[["mining.set_difficulty", "b4b6693b72a50c7116db18d6497cac52"], ["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"]], " ", 4], "error": null }\n Následuje autorizace těžaře prostřednictvím zaslání žádosti mining.authorize. Žádost umožňuje autorizovat libovolný počet těžařů během již vytvořeného spojení. Žádost obsahuje pouze dva parametry. Prvním z nich je přihlašovací jméno těžaře a druhým je heslo 24

29 (heslo může být prázdné v případě, že pool server heslo nevyžaduje). Příklad žádosti mining.authorize: { "id": 2, "method": "mining.authorize", "params": ["slush.miner1", "password"] }\n Pool server odpoví na žádost o autorizaci tak, že nastaví parametr result na true v případě, že autorizace proběhla v pořádku. V opačném případě nastaví parametr result na false. Příklad odpovědi na žádost mining.authorize: { "id": 2, "result": true, "error": null }\n Po úspěšné autorizaci zašle pool server klientovi oznámení mining.notification, které obsahuje údaje potřebné pro zahájení těžby. Oznámení obsahuje následující parametry uvedené v tabulce 4.5. parametr job id prevhash coinb1 coinb2 merkle branch version nbits ntime clean jobs popis Identifikátor prováděné práce, který se používá při žádosti o její potvrzení hash hlavičky předchozího bloku inicializační část coinbase transakce koncová část coinbase transakce seznam hashů, který se použije pro výpočet kořenového hashe merkle stromu číslo verze bloku aktuální cíl (target) aktuální časové razítko pokud je nastaven na true indikuje pool server, že prováděná práce již není aktuální. Těžař ukončí právě prováděnou práci a začne pracovat na nové. Tabulka 4.5: Oznámení mining.notification. Příklad oznámení nové práce mining.notification: { "id": null, "method": "mining.notify", "params": ["bf", "4d16b6f85af6e2198f44ae2a6de67f78487ae5611b77c6c0440b921e

30 }\n 00", " ffffffff f f04b8864e5008", "072f736c f f2052a a914d23fcdf86f7e 756a64a7a9688ef ed988ac ", [], " ", "1c2ac4af", "504e86b9", false], Po provedení práce zašle těžař pool serveru žádost o její potvrzení mining.submit. Žádost obsahuje následující parametry uvedené v tabulce 4.6. parametr worker name job id extranonce2 ntime nonce popis přihlašovací jméno těžaře (klienta) identifikátor prováděné práce zaslaný v oznámení mining.notification hodnota vygenerovaná těžařem o velikosti extrononce2 size použitá pro sestavení coinbase transakce aktuální časové razítko hodnota zjištěná vykonanou prací Tabulka 4.6: Parametry žádosti mining.submit. Příklad žádosti o potvrzení práce mining.submit: { "id": 4, "method": "mining.submit", "params": ["slush.miner1", "bf", " ", "504e86ed", "b2957c02"] }\n Pool server zašle na žádost mining.submit odpověď, která obsahuje výsledek true v případě, že byla vykonaná práce potvrzena pool serverem. V opačném případě obsahuje výsledek hodnotu false. Příklad odpovědi na žádost mining.submit: { "id": 4, "error": null, "result": true }\n Pool server může v průběhu těžby klientovi zaslat žádost o změnu obtížnosti s názvem mining.set difficulty. Jako implicitní obtížnost se používá hodnota: 26

31 0x ffff Hodnota je uvedena v šestnáctkové soustavě ve formátu Big-Endian. V žádosti o změnu obtížnosti server zasílá celočíselný parametr, kterým se má implicitní obtížnost podělit, čímž vznikne nová obtížnost, která bude aplikována na každou následující těžbu. Příklad žádosti o změnu obtížnosti mining.set difficulty: { "id": null, "method": "mining.set_difficulty", "params": [2] }\n V tomto příkladu zasílá pool server žádost o změnu obtížnosti s parametrem 2. Po podělení defaultní obtížnosti parametrem 2 vznikne nová obtížnost: 0x fff Vytvoření hlavičky bloku Potom co proběhne komunikace mezi klientem a pool serverem, je třeba ze zaslaných dat sestavit hlavičku bloku, aby mohl těžař zahájit těžbu hledáním odpovídajícího hashe bloku. Proto je třeba nejprve vytvořit coinbase transakci, dále vytvořit kořen merkle stromu a sestavit hlavičku bloku. Vytvoření coinbase transakce Coinbase transakce se vytváří z polí, která těžaři v komunikaci zašle pool server konkrétně z coinb1, extranonce1, extranonce2 size a coinb2. Vytvoření coinbase transakce probíhá následovně: 1. Vygeneruje se (nebo zvolí) nová položka extranonce2 o velikosti, kterou udává pole extranonce2 size v bajtech (např. pokud bude extranonce2 size = 4, pak extranonce2 musí být čtyřbajtová hodnota např. 0xff02a301). 2. Provede se následující konkatenace: str = coinb1 + extranonce1 + extranonce2 + coinb2 3. Nakonec se na nově vzniklý řetězec str aplikuje dvakrát hashovací funkce SHA-256: coinbase = SHA-256(SHA-256(str)) Vytvoření kořene merkle stromu Vytvoření kořene merkle stromu probíhá pomocí následujícího algoritmu: merkle_root = coinbase for item in merkle_branch: merkle_root = SHA-256(SHA-256(merkle_root + item)) merkle_root = reverse_byte_order(merkle_root) 27

32 1. V prvním kroku se do kořene stromu uloží hash coinbase transakce vytvořené v předchozím kroku. 2. Dále se postupně prochází seznam hashů zaslaných od pool serveru, kdy se ke kořenu stromu připojí jeden hash ze seznamu. Vzniklá položka se dvakrát zahashuje pomocí hashovacího algoritmu SHA-256 a výsledek se uloží jako kořen merkle stromu. Krok 2 se takto opakuje dokud se neprojde celý seznam. 3. V posledním kroku se prohodí pořadí jednotlivých bajtů. Sestavení hlavičky bloku Sestavení hlavičky bloku se provede konkatenací jednotlivých položek hlavičky následovně: version + prevhash + merkle_root + ntime + nbits Význam prvních pěti položek byl popsán výše. Následující čtveřice bajtů reprezentuje položku nonce. Zbývající bajty reprezentují zarovnání používané v hashovací funkci SHA- 256, které je po čtveřicích bajtů zapsáno v obráceném pořadí. Nyní má těžař k dispozici všechna data pro zahájení těžby. 28

33 Kapitola 5 Architektura systému Jak již bylo zmíněno výše, proces těžby Bitcoinů je velice časově a výpočetně náročný. Komunita těžařů se proto snaží tento proces urychlit a zvýšit tak pravděpodobnost získání odměny. V této kapitole bude popsána architektura systému pro urychlení těžby Bitcoinů a dále budou blíže popsány její jednotlivé části. Základem architektury je softwarový klient, který komunikuje s pool serverem prostřednictvím komunikačního protokolu (Getblocktemplate, Stratum). Jako komunikační protokol mezi klientem a pool serverem byl zvolen, vzhledem k jednoduchosti a rychlosti, Stratum protokol. Klient získává od pool serveru práci (data potřebná pro sestavení hlavičky bloku) a předává ji koncovému zařízení, které přidělenou práci provádí (hledá hash odpovídající složitosti). Koncovým zařízením můžeme rozumět například procesor, grafickou kartu, FPGA čip případně integrovaný obvod ASIC. Pro popisovanou architekturu byl koncovým zařízením zvolen FPGA čip z důvodu zaměření této práce především na FPGA čipy a dostupnosti těchto zařízení. FPGA čip, prostřednictvím sériové linky RS-232 [45], komunikuje s klientem. Při úspěšném nalezení hashe je výsledek odeslán klientovi, který nalezený hash zašle pool serveru. Pool server nalezený hash schválí, případně zamítne a zašle klientovi novou práci. Celá architektura je zobrazena na obrázku 5.1. Obrázek 5.1: Architektura systému. 5.1 Klient pro komunikaci s pool serverem Softwarový klient tvoří prostředníka v komunikaci mezi pool serverem a FPGA čipem. Klient komunikuje s pool serverem prostřednictvím protokolu Stratum, který byl popsán výše a přes sériovou linku RS-232 s FPGA čipem. Komunikace mezi klientem a FPGA 29

34 čipem bude popsána níže Komunikace s FPGA Jedná se o jednoduchou komunikaci s FPGA čipem prostřednictvím sériové linky RS-232. Komunikace je znázorněna konečným automatem na obrázku 5.2, kde počáteční stav S1 reprezentuje klienta, který zahajuje komunikaci a stav S2 reprezentuje FPGA čip. Oba dva stavy jsou koncové z těchto důvodů: První možný způsob komunikace je následující. Klient zahájí komunikaci zasláním dat (data) FPGA čipu. FPGA čip v případě nalezení hashe zašle výsledek (result) zpět klientovi. V případě, že FPGA čip projde celý možný prostor řešení, zašle klientovi zprávu konec (end) a proces na FPGA čipu je ukončen. Komunikace končí ve stavu S1. Ve druhém případě komunikace klient zahájí komunikaci zasláním dat (data) FPGA čipu. FPGA čip pracuje na nalezení hashe. V případě, že klient obdrží od serveru novou práci, dojde k ukončení procesu na FPGA čipu přijetím zprávy stop od klienta. Celá komunikace je pak ukončena (ve stavu S2) nebo se začíná znovu s řešením nové práce. stop S1 data result S2 end Obrázek 5.2: Konečný automat zobrazující komunikaci mezi klientem a FPGA čipem. Popis jednotlivých položek zasílaných v komunikaci mezi klientem a FPGA čipem (všechny položky jsou reprezentovány v šestnáctkové soustavě): data - Reprezentují práci přijatou od pool serveru upravenou klientem. Data obsahují 108 bajtovou zprávu tvořenou položkami hlavičky bloku a aktuální obtížností v následujícím pořadí: version (4B), prevhash (32B), merkle root (32B), ntime (4B), nbits (4B) a aktuální obtížnost (32B). Položka nonce je přidána až v samotném procesu na FPGA čipu. result - Obsahuje nalezené řešení o velikosti osmi bajtů obsahující dvě pole v následujícím pořadí: nonce (4B) a ntime (4B). stop - Obsahuje 4-bajtový řetězec stop (73746f70 v šestnáctkové soustavě). end - Obsahuje 3-bajtový řetězec end (656e64 v šestnáctkové soustavě). 30

35 5.1.2 Komunikace s pool serverem Samotný klient pro komunikaci s pool serverem implementuje konečný automat znázorněný na obrázku 5.3. mining.subscribe mining.authorize S1 S2 S3 error error mining.notif y work S5 mining.submit request work S4 mining.notif y Obrázek 5.3: Konečný automat znázorňující komunikaci klienta s pool serverem. Význam jednotlivých stavů a přechodů je následující: S1 - Jedná se o počáteční stav, ve kterém se klient nachází po svém spuštění. Klient ihned odešle žádost mining.subscribe pool serveru a přejde do stavu S2, ve kterém čeká na odpověď. S2 - V tomto stavu klient očekává odpověď od pool serveru na žádost mining.subscribe. V případě, že dojde k chybě (error) přejde klient zpět do počátečního stavu S1. V opačném případě jsou klientovi zaslány údaje potřebné pro sestavení coinbase transakce a klient přejde do stavu S3 zasláním autorizačních údajů pomocí žádosti mining.authorize. S3 - Ve stavu S3 klient čeká na odpověď od pool serveru na žádost mining.authorize. Pokud byly zadané autorizační údaje chybné (error) nebo se autorizace z nějakého důvodu nezdařila, přejde klient zpět do počátečního stavu S1. V případě, že autorizace proběhla v pořádku, je pool serveru zaslána žádost mining.notify a klient přejde do stavu S4. S4 - V tomto stavu očekává klient zaslání dat (work) pro vykonání práce od pool serveru. V případě zaslání dat přejde klient do stavu S5, v opačném případě klient čeká na zaslání dat od pool serveru. S5 - Ve stavu S5 komunikuje klient s FPGA zařízením, kterému předává data zaslaná od pool serveru (viz komunikace s FPGA výše). V případě obdržení řešení od 31

36 FPGA zařízení zašle klient pool serveru žádost o potvrzení práce mining.submit. Pokud je práce pool serverem potvrzena, přejde klient přechodem request work do stavu S4, ve kterém očekává zaslání nové práce od pool serveru. V případě, že práce potvrzena není, klient zůstává ve stavu S5 a čeká na obdržení nového řešení od FPGA zařízení Implementace Klient je implementován pomocí objektově orientovaného programovacího jazyku Java. Z důvodu současné komunikace klienta s pool serverem a FPGA zařízením pracuje klient s více vlákny řízení, kde je nutné řešit synchronizaci předávaných dat mezi jednotlivými vlákny. Funkcionalitu programu zajišťují třídy, které jsou zobrazené v diagramu tříd na obrázku 5.4. Obrázek 5.4: Diagram tříd. Význam a funkce jednotlivých tříd programu je následující: Main - Představuje hlavní třídu programu, ve které je implementované uživatelské rozhraní klienta. Třída dále obsahuje dvě funkce pro zjištění informací o dostupných sériových portech. 32

37 ThreadReader - Tato třída rozšiřuje třídu Thread a reprezentuje tak jedno z vláken řízení, ve kterém je implementován již popsaný konečný automat pro komunikaci s pool serverem. Třída dále využívá třídy JSONParser a Comunicator. JSONParser - Metody této třídy slouží převážně pro zpracování odpovědí od pool serveru. Z odpovědí jsou získávána data, která jsou dále zpracována tak, aby mohla být předána třídě, která komunikuje s FPGA zařízením. Pro zpracování dat se používá několik metod, které využívají třídu SHA256. SHA256 - Třída obsahuje metody pro vytvoření dvojitého hashe pomocí hashovací funkce SHA-256. Dále obsahuje metodu pro vytvoření hashe kořene merkle stromu. Comunicator - Tato třída slouží pro komunikaci s FPGA zařízením. Obsahuje metody pro vytvoření a ukončení spojení s FPGA zařízením prostřednictvím daného sériového portu. V případě vytvoření spojení inicializuje třídy SerialWriter a SerialReader a po ukončení komunikace zajišťujě uvolnění všech použitých zdrojů. Třída odchytává požadavky na čtení dat ze sériové linky a předává je třídě SerialReader. SerialWriter - Slouží pro zasílání dat přes sériovou linku FPGA zařízení. Třída rozšiřuje třídu Thread a jedná se tak o další vlákno řízení, které předává data FPGA zařízení nezávisle na souběžné komunikaci s pool serverem. SerialReader - Implementuje metodu pro čtení dat ze sériové linky. V případě požadavku na čtení ze sériové linky je tato funkce volána nadřazenou třídou Comunicator. Přečtená data jsou dálé předána vláknu ThreadReader Popis programu Po spuštění programu se zobrazí jednoduché uživatelské rozhraní, které je zobrazeno na obrázku 5.5. Uživatelské rozhraní je rozdělené na tři části: Server settings - Je část obsahující čtyři vstupní pole pro vložení údajů potřebných pro spojení s pool serverem. Login - Uživatelské jméno těžaře, kterým se identifikuje pool serveru. Password - Heslo těžaře. Server - Doménové jméno pool serveru, se kterým se má navázat spojení. Port - Číslo portu pool serveru. COM port settings - Tato část slouží pro zvolení příslušného sériového portu, na kterém je připojeno FPGA zařízení. Dále k nastavení parametrů vybrané sériové linky. Serial Port - Slouží ke zvolení sériového portu, na kterém se bude komunikovat s FPGA zařízením. Pro aktualizaci seznamu dostupných sériových portů lze použít tlačítko. Baudrate - Udává rychlost přenášených dat po sériové lince. Lze vybrat ze sedmi předdefinovaných základních rychlostí ( bit/s, bit/s, bit/s, bit/s, 9600 bit/s, 4800 bit/s a 2400 bit/s). Data bits - Toto výběrové pole udává kolik z přenášených bitů bude obsahovat data. Je možné vybrat ze čtyř možností (5, 6, 7 nebo 8 bitů). 33

38 Parity - Toto pole udává způsob kontroly chyb v přenášených datech. Lze vybrat z pěti možností parity a to z žádné (none), liché (odd), sudé (even), z parity nastavené vždy na hodnotu logické jedničky (mark) a z parity nastavené vždy na hodnotu logické nuly (space). Stop bits - Udává počet bitů signalizujících konec přenášených dat. Na výběr jsou tři možnosti (1, 1,5 nebo 2 bity). Flow control - Lze zvolit typ kontroly toku dat z pěti různých možností, kde defaultní hodnota je none. Dále je pak možné vybrat z RTSCTS IN, RT- SCTS OUT, XONXOFF IN a XONXOFF OUT. Status - Slouží k informování těžaře. Informuje o jednotlivých akcích jako je například spojení se serverem, příhlášení, získání nové práce a nebo potvrzení nalezeného řešení. Obrázek 5.5: Uživatelské rozhraní klienta. Program se ovládá pomocí dvou tlačítek Start a Stop. Po vyplnění všech potřebných údajů, lze zahájit těžbu stisknutím tlačítka Start, kdy dojde ke spojení s pool serverem a předání dat FPGA zažízení. V případě chyby je těžař informován chybovou zprávou a program je zastaven. Pro ukončení těžby stačí stisknout tlačítko Stop. 5.2 Architektura pro urychlení těžby Jak již bylo uvedeno výše, samotná těžba Bitcoinů je časově a výpočetně velice náročná. Proto byla navržena architektura, která má za cíl těžbu Bitcoinů urychlit. Architektura je implementována v programovacím jazyce VHDL, který slouží pro popis hardwaru, a je 34