🥇Mis on plokiahela ehitamine?

Kogu inimkonna ajalugu on pidev ahelatest vabastamine ja uute, veel tugevamate loomine. (Anonüümne autor)

Analüüsides arvukaid blockchain projekte (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin jne), mõistan, et tehniliselt on kõik need üles ehitatud samadele põhimõtetele. Blockchainid sarnanevad hoonetele, millel, vaatamata erinevatele konstruktsioonidele, dekoratsioonidele ja otstarvetel, on olemas vundament, seinad, katus, aknad, uksed, mis on omavahel ühendatud teatud viisidel. Kui mõista hoonete projekteerimise põhialuseid ja teada kasutatavatele materjalidele omaseid omadusi, saab määrata konkreetse hoone sihtotstarbe. Praegu on blockchaini osas tekkinud olukord, et kõik on sellest kuulnud, kuid vähesed mõistavad selle arhitektuuri ja tööpõhimõtteid. Seetõttu tekib arusaamatus, milleks ja kuidas on mõistlik kasutada blockchaini tehnoloogiaid.

Selles artiklis käsitleme kõiki blockchainidele ühiseid omadusi ja põhimõtteid. Seejärel vaatame, milliseid ülesandeid saab lahendada blockchaini abil ja materjali kinnitamiseks ehitame oma virtuaalses krundis väikese, kuid tõelise blockchaini!

Nii et, meenutame, milliseid probleeme plokiahel algusest peale lahendas.

Olen kindel, et paljud ütlevad, et see on jaotatud, detsentraliseeritud, avalik ja muutumatu andmebaas. Aga miks seda kõike vaja oli?

Ma eelistan alustada iga tehnoloogia uurimist standardite lugemisest, kuna need on baasiks kõikidele artiklitele ja raamatutele uuritaval teemal. Kuid plokiahela standardid puuduvad praegu, ISO-s on loodud ainult komiteed nende arendamiseks. Praeguseks igas avalikus plokiahela projektis on oma dokument White paper, mis põhimõtteliselt on tehniline ülesanne. Esimene tuntud plokiahela projekt on Bitcoin. Läheme ametlikule lehele ja vaatame milles kõik algas.

Plokiahela ülesanne

Nii et ülesanne, mille plokiahel lahendas pioneervõrgus Bitcoin — on usaldusväärse omandiülekande teostamine digitaalses keskkonnas ilma vahendajateta. Näiteks Bitcoinis on digitaalsed varad — need on digitaalsed bitcoin-mündid. Ja kõik tehnilised lahendused, mis on seotud Bitcoiniga ja teiste plokiahela projektidega, taanduvad sellele ülesandele.

Probleemid, mida plokiahel lahendab

Kujutage ette, et mingi finantsorganisatsioon väidab, et on loonud ülemaailmse võrgustiku, millega saab raha edastada igale inimesele. Kas usuksite seda? Kui see oleks Visa või MasterCard, tõenäoliselt usuksite, aga kui see oleks näiteks AnonymousWorldMoney, siis ilmselt mitte. Miks? Sest me teame, kuidas erasektoris jaotatud süsteeme luuakse, milliste eesmärkidega ning kuhu see kõik viia võib. Uurime lähemalt selliste süsteemide probleeme ja kuidas neid saab lahendada plokiahela tehnoloogiate abil.

Oletame, et AnonymousWorldMoney's on serverid andmebaasidega, ja oleks hea, kui neid oleks mitu erinevates andmekeskustes. Kui saatja edastab raha, registreeritakse tehing, mis replikeeritakse kõikidele serveritele, ja raha jõuab saajani.

Ideaalmaailmas töötab selline skeem suurepäraselt, kuid meie maailmas esinevad järgmised probleemid:

Osalejate tuvastamise probleem ühelt poolt ning tehingute anonüümsuse vajadus teiselt poolt. Seega tuleb raha üle kanda konkreetsele saajale nii, et selle tehingu kohta ei teaks keegi muud, kui tehingu osalised. Pangad omavad kontonumbrid ja pangakaardid, mis on seotud konkreetse füüsilise või juriidilise isikuga, ning pangasaladus kaitseb tehingute kohta käivat teavet. Kes aga garanteerib, et tingimuslik AnonymousWorldMoney ei kasuta isikuandmeid ja tehingute teavet oma huvides?
Kuidas veenduda, et saaja sai just selle summa, mille talle üle kanti? Tinglikult öeldes, saatis saatja $100, kuid saaja sai $10. Saatja tuleb AnonymousWorldMoney kontorisse oma kviitungiga, kuid ametnik näitab oma versiooni, kus on kirjas, et saatja saatis ainult $10.
Probleem usaldusväärse keskkonna puudumisega, näiteks petmine, mida nimetatakse double-spendingiks. Ebamugav osaline võib oma saldot mitu korda kulutada, enne kui makse on replikatsioonitud kõigile serveritele. CAP teoreem, muidugi, keegi ei tühista ja lõpuks saavutatakse ühtsus, kuid keegi ei saa tasu osutatud teenuste või kaupade eest. Seetõttu, kui ei olda täielikult usaldusväärne makseorganisatsiooni või tehingu osalejate suhtes, tuleb luua võrk, mis põhineb mitte usaldusel, vaid krüptograafial.
Tinglik AnonymousWorldMoney’l on piiratud arv servereid, mis võivad muutuda kättesaamatuks kas tahtmatult või pahatahtlikult.
AnonymousWorldMoney võtab oma märkimisväärse tasu.
Halduse võimalused. Bitcoin'i kasutamise käigus selgus, et inimesed tahavad mitte ainult münte üksteisele edastada, vaid ka kontrollida erinevaid tehingu tingimusi, programeerida tööstsenaariume, automaatselt teostada toiminguid vastavalt tingimustele jne.

Kuidas plokiahel need probleemid lahendab

Osalejate identifitseerimine toimub privaat- ja avaliku võtme abil ning digitaalse allkirja algoritm tuvastab saatja ja saaja ühemõtteliselt, jättes nende isikud anonüümseks.
Tehingud kogutakse blokkidesse, bloki hash arvutatakse ja see kirjutatakse järgmisse blokki. Selline hashide järjestikune salvestamine blokki andis nime tehnoloogiale blockchain ning see takistab blokeerimist või üksikute tehingute eemaldamist märkamatult. Seega, kui tehing siseneb plokiahelasse, võib olla kindel, et selle andmed jäävad muutumatuks.
Double-spending pettust takistatakse saavutades konsensust võrgus, milliseid andmeid pidada õigeteks ja milliseid kõrvaldada. Bitcoin võrgus saavutatakse konsensus töö tõestamise (PoW) kaudu.
Võrgu usaldusväärne toimimine saavutatakse plokiahela avalikkuse kaudu, kus iga liige saab käivitada oma sõlme, saada täismahuliselt plokiahela koopia ja, mis veelgi enam, iseseisvalt alustada tehingute õigsuse kontrollimist. Tuleb märkida, et kaasaegsed plokiahelad võimaldavad luua mitte ainult avalikke (avatud) plokiahelasid, vaid ka privaatseid (suleeritud) plokiahelasid ning kasutada ka kombineeritud skeeme.
Blockchaine ei saa täielikult lahti komisjonitasudest, sest võrgu toetamiseks tuleb maksta inimestele, kuid blockchainis on komisjonitasude vajadust tõendatud nii veenvalt, et selles osas ei ole kahtlust.
Kaasaegsed blockchainid suudavad rakendada äri loogikat, mida nimetatakse Smart Contracts. Smart lepingute loogika teostatakse erinevates kõrgetasemelistes programmeerimiskeeltes.

Külastame neid lahendusi põhjalikumalt.

Blockchaini arhitektuur

Blockchaini komponendid

Iga osaleja saab käivitada oma sõlme koos täiskopeeritud blockchainiga (full node). Täisknodid, mis saavad salvestada tehinguid blockchainis, nimetatakse konsensuse sõlmedeks (witness) või kaevuriteks (miner). Täisknodid, mis kontrollivad ainult tehingute õigsust, nimetatakse auditi sõlmedeks (audit). Kerged kliendid (light clients) ei salvesta täiskopeeringut blockchainist, vaid suhtlevad võrguga, kasutades täisknodeid.
Enamik kasutajaid tehingute sooritamiseks kasutab just kergeid kliente või veebikingaid. Kõik sõlmed on omavahel ühendatud. Sellise elementide komplekti puhul muutub võrgu arhitektuur stabiilsemaks:

Tehingu elutsükkel

Vaatame, kuidas tehingu elutsükkel toimib ja analüüsime seda osade kaupa:

Plokiahela tehnoloogiad

Räägime lähemalt tehnilistest lahendustest ja nendevahelistest seostest.

Identifitseerimine

Iga plokiahela tehing peab olema allkirjastatud digitaalse allkirjaga. Seega peab iga osaleja tehingu sooritamiseks omama võtmepaari: privaatne / avalik. Mõnikord nimetatakse võtmepaari rahakotiks (wallet), kuna võtmed on otseselt seotud ainulaadse digitaalse aadressi ja osaleja saldoga. Tegelikult on võtmed ja aadressid lihtsalt numbrite read erinevates arvutussüsteemides. Näited võtmetest ja rahakoti aadressist:

Privaatne võti: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Avalik võti: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Aadress: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

Digitaalse allkirja loomiseks plokiahelates kasutatakse algoritmi, mis põhineb elliptilistel kääridel: Elliptic Curve Digital Signature Algorithm (ECDSA). Selle toimimiseks valitakse privaatne võti (256-bitine number) tavaliselt juhuslikult. Võtmete variatsioone on 2 astmes 256, seega võib rääkida praktilise võimatuse kohta privaatsete võtmete väärtuste kokkulangemisest.

Seejärel saadakse avalik võti privaatvõtme väärtuse korrutamisel kõveral asuva punkti koordinaatidega, mistõttu saadakse uue punkti koordinaadid sama kõvera peal. See toiming tagab sobiva võtmepaari, mida saab kasutada tehingute digitaalsete allkirjade jaoks. Lõpuks arvutatakse rahakoti aadress avaliku võtme põhjal üheselt.

On palju artikleid, kus käsitletakse blokeeringute juures kasutatavat krüptograafiat, näiteks: Bitcoin lühidalt — Krüptograafia

Privaatvõti peab olema rangelt saladuses ja seda tuleb hoida turvaliselt. Avalik võti on kõigile teada. Kui privaatvõti kaob, ei saa juurde pääseda varale (müntidele) ja raha kaob igaveseks. Seetõttu on privaatvõtmete usaldusväärne hoidmine äärmiselt oluline, kuna tegemist ei ole pangaga, kuhu võiks alati minna isikut tõendava dokumendiga ja konto taastada. Eksisteerib terve tööstusharu, mis toodab nn külmkryptokotte, mis näevad välja nagu mälupulgad:

või võib kasutada usaldusväärsemaid viise, näiteks graveerida privaatvõtme väärtus žetoonidele:

Tehingud

Lisainfot tehingu struktuuri kohta leiate artiklist Bitcoin lühidalt — Tehing. Meie jaoks on oluline mõista, et igal tehingul on vähemalt järgmised andmed:

Küljest: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - saatja digitaalne aadress
Saaja: 0x367adb7894334678b90a‌fe7882a5b06f7fbc783a - vastuvõtja digitaalne aadress
Summa: 0.0001 - tehingu summa
Tehingu hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - tehingu hash

Seejärel allkirjastatakse tehing privaatvõtmega ja saadetakse (vt üksikasju protokolli töö kohta Bitcoin lühidalt - Protokoll) kõigile plokiahela sõlmedele, mis kontrollivad tehingute kehtivust. Tehingu kontrollimise algoritm ei ole triviaalne ja sisaldab kaks tosinat sammu.

Tehinguplokid

Kontrollides tehingute kehtivust, moodustavad sõlmed neist plokid. Lisaks tehingutele salvestatakse plokki eelmise ploki hash, number (Nonce loenduri väärtus), ning arvutatakse praeguse ploki hash SHA-256 algoritmi alusel. Hash peab vastama kindlatele raskusastme nõuetele. Näiteks Bitcoin võrgus muutub hash'i raskus automaatselt iga kahe nädala järel sõltuvalt võrgu tootlikkusest, et plokk genereeritaks ligikaudu iga 10 minuti järel. Raskus määratakse järgmise tingimuse järgi: leitud hash peab olema väiksem kui eelnevalt määratud number. Kui seda tingimust ei täideta, lisatakse Nonce'le 1 ja hash'i arvutamise töö kordub. Hash'i leidmiseks kasutatakse Nonce'i välja, kuna need on ainsad andmed plokis, mida saab muuta, kõik ülejäänud peavad jääma muutumatuks. Õige hash peab olema alguses kindel arv nullesid, näiteks üks reaalsest hash'ist:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Hashi leidmine on tõestus tehtud töö kohta (Proof-of-Work, PoW) Bitcoin või Ethereum võrkudes. Hashide leidmise protsessi nimetatakse ka kaevandamiseks (mining), sarnaselt kullakaevandamisele. Nimi kirjeldab protsessi täpselt, kuna see hõlmab lihtsalt erinevate variantide proovima ja kui keegi leiab sobiva hash'i, siis on see tõepoolest õnn. See on nagu leida tõeline kuldse nuggete tonnide tühjast kividest. Bloki preemia on praegu 12.5 BTC ja kui korrutada see Bitcoini hetkehinnaga $3900, siis see teeb rohkem kui kilo puhast kulda. See on millegi nimel võitlemine!

Pärast hash'i eduka leidmise protsessi, block ja leitud hash kantakse blockchain'i järgmise bloki alla. Üksikasju plokkide struktuuri kohta saab vaadata artiklis Bitcoin lühidalt - Blockchain, ja allpool toome lihtsustatud skeemi:

Blockhain algab plokist, millel ei ole veel eelneva ploki hashi. Selline plokk blockchainis on ainus ja kannab nime Genesis block. Ülejäänud plokkidel on sama struktuur, kuid need erinevad ainult tehingute arvust. Reaalseid tehinguid ja plokke, mis praegu luuakse Bitcoinis või Ethereumis, saab vaadata Block Explorer.

Bitcoinis on plokkide suurus piiratud 1 MB, ja arvestades, et tehingu põhiteave on umbes 200 baiti, võib plokis olla maksimaalselt umbes 6000 tehingut. Seetõttu tuleneb ka Bitcoin'i tootlikkus, mille üle kõik naeravad: plokk genereeritakse umbes iga 10 minuti järel = 600 sekundi jooksul, mis annab formaalse tootlikkuse umbes 10 TPS. Kuigi tegelikult pole see tootlikkus, vaid teadlikult rakendatud tööalgoritm. Ethereumis konkurentsi saavutamiseks vähendati ploki genereerimise aega 15 sekundini, ja tootlikkus tõusis formaalselt. Seega on Proof of Work konsensusmehhanismi kasutavates blockchainides tootlikkuse võrdlemine mõttetu, kuna see sõltub otseselt hashi arvutamise keerukusest, millele võib määrata mistahes taseme.

Forks

Kuid mis juhtub, kui näiteks mitu sõlme leiavad hashid, mis vastavad keerukuse tingimustele, kuid on väärtuselt erinevad (teisisõnu, jõuavad erinevatesse konsensustesse) ja salvestavad plokid plokiahelasse? Vaatame, kuidas plokiahel kaitseb end selle olukorra eest. Sel juhul toimub nn hargnemine ('fork') ja plokiahelal on kaks versiooni ahelast:

Mis juhtub seejärel? Seejärel hakkab osa võrgust töötama plokil N+2 ühelt ahelalt ja osa teiselt:

Mõni neist plokkidest leitakse varem ja saadetakse plokiahelasse ning siis peab plokiahel reeglite kohaselt lülituma pikema ahela peale ja tühistama kõik teise ploki tehingud:

Sellega võib juhtuda olukord, kus osaleja tehing oli ainult ühes forki plokis, misjärel see tühistati. Seetõttu, et olla kindel, et vajalik tehing on kantud plokiahelasse, on üldine soovitus — enne tehingule usaldamist oodata, kuni järgmised paar plokki on plokiahelasse lisatud. Eri plokiahelate puhul erinevad soovitused, kui palju plokke oodata. Näiteks Bitcoin võrgu jaoks on minimaalne ooteaeg 2 plokki ja maksimaalne 6.

Sarnane olukord blokeerimise forgi puhul ilmneb ka nn 51% rünnaku korral — see on siis, kui grupi kaevandajad püüavad luua alternatiivset plokiahelat, püüdes tühistada ahelat koos oma petlike tehingutega. Kuigi praegu on ausate kaevandamiste tegemine kasulikum kui petmine.

Konsensus

Ploki lisamiseks plokiahelasse peab võrk jõudma konsensusele. Vaatame tagasi, et meenutada konsensuse saavutamise ülesannet arvutivõrkudes. Probleem formuleeritakse kui visantiinide kindralite BFT probleem (Byzantine fault tolerance). Jätkates Byzantsi armee probleemide kirjelduse vältimist, saab ülesande sõnastada järgmiselt: kuidas tul network jõuda ühise tulemuse, kui osa võrgu sõlmedest võivad neid tahtlikult moonutada. Olemasolevad BFT probleemide lahendamise algoritmid näitavad, et võrk saab õigesti toimida, kui pettureid on vähem kui 1/3. Miks Bitcoinis ei rakendatud BFT konsensust? Miks oli vaja kasutada PoW? On mitmeid põhjusi:

BFT töötab hästi väikese fikseeritud sõlmede kogumiga, kuid avalikus plokiahelas on sõlmede arv ettearvamatu ja pealegi võivad sõlmed vabalt sisse ja välja lülituda.
Inimesi on vaja motiveerida plokiahela sõlmi käivitama. Selleks peavad inimesed saama tasu. BFT-s pole ametlikult mille eest tasu saada, kuid PoW-s on kõigile arusaadav, mille eest tasu makstakse: protsessori poolt tarbitud elektri eest ploki hashimise protsessi käigus.

Peale PoW on veel mitmeid konsensusmehhanisme, mida kasutatakse kaasaegsetes plokiahelates, näiteks:

PoS (Proof-of-Stake) — plokiahelas Hyperledger
DPoS (Delegated Proof-of-Stake) — plokiahelas BitShares
BFT modifikatsioonid: SBFT (lihtsustatud BFT) ja PBFT (praktiline BFT), näiteks plokiahelas Exonum

Vaatame natuke PoS konsensust, kuna just PoS ja selle variandid on saanud kõige laiemat levikut erasüsteemides. Miks just era süsteemides? Ühest küljest on PoS omadused parem kui PoW omadused, kuna konsensuse saavutamiseks on vaja vähem arvutusvõimsust ja see suurendab andmete salvestamise kiirus plokiahelasse. Teisalt annab PoS rohkem võimalusi petmiseks, seega peavad kõik plokiahela osalised olema tuntud, et seda neutraliseerida.

PoS konsensus põhineb sõlme valimisel, mis saab salvestada plokk koos tehingutega plokiahelasse, sõltuvalt kontole kantud vahendite arvust, täpsemalt, mitte kontole, vaid tagatisena. See tähendab, et mida rohkem sul on tagatist, seda tõenäolisemalt valib võrk sinu sõlme ploki salvestamiseks. Tagatis ei naasta, kui plokk osutub kehtetuks. Nii on saavutatud kriminaalsuse kaitse. PoS-il on järgmised variatsioonid:

Delegated PoS (DPoS) konsensus jagab osalejad "hääletajate" ja "validatsioonide" vahel. Münte omavad inimesed (hääletajad) delegeerivad oma õiguse teisten osalejate kaudu tehingute kontrollimiseks ja plokiahelasse salvestamiseks. Nii saavad valideerijad teha kogu arvutusööt ja teenida selle eest tasu, samas kui hääletajate olemasolu tagab valideerijate aususe, kuna neid saab igal ajal vahetada.
LPoS (Leased Proof-of-Stake) konsensus võimaldab anda oma varasid rendile teiste sõlmedele, et neil oleks suurem võimalus plokkide kontrollimisel. Nii on võimalik teenida tehingute komisjonitasu, osalemata samal ajal tehingute kontrollimises ja plokkide kaevandamises.

On ka mitmeid teisi konsensusmudeleid, mis ei ole veel laialdaselt kasutusele võetud; loetlen neid siinkohal teabe jaoks, ning konsensusalgoritmide ülevaate saab näiteks lugeda artiklist: Konsensuse algoritmid plokiahelas.

PoET (Proof-of-Elapsed Time)
PoC (Proof-of-Capacity)
PoB (Proof-of-Burn)
PoWeight (Proof-of-Weight)
PoA (Proof-of-Activity) — PoW + PoS
PoI (Proof-of-Importance)

Usaldusväärsus ja plokiahelate juurutamise mudelid

Avalik plokiahel

Stabiilsus Avalik või muu nimi Ruletita plokiahel see, et igaüks saab liituda ja teavet vaadata või isegi enda sõlme ühendada, ja usaldus põhineb PoW konsensusel.

Privaatne plokiahel

Privaatne või Privaatne lubatud plokiahel. Nendes plokiahelates on juurdepääs teabele ainult teatud osalejate grupil (organisatsioonid või inimesed). Selliseid plokiahelate loomise eesmärk on suurendada osalejate üldist kasu või efektiivsust. Nende usaldusväärsus tagatakse osalejate ühiste eesmärkide ja PoS ja BFT konsensusalgoritmide kaudu.

Plokiahela konsortsium

On olemas Konsortsium või Avalik lubatud plokiahel. Need on plokiahelad, kuhu igaühel on juurdepääs vaatamiseks, kuid teabe lisamiseks või sõlme ühendamiseks peab osaleja saama teiste osalejate loal. Selliseid plokiahelate loomise eesmärk on tõsta usaldust klientide või tootjate või ühiskonna üldiselt. Siin saavutatakse usaldusväärsus samuti osalejate vahelise usalduse kohaloleku ja sama PoS ja BFT konsensusalgoritmidega.

Nutilepingud

Bitcoin'ist lähtunud plokiahelad sisaldavad teatud määral nutilepingute täitmise võimalust. Nutileping on tegelikult tehing, kuhu on sisse kirjutatud programmikood täitmiseks. Ethereum'i võrgus täidetakse nutilepingud EVM-is (Ethereum Virtual Machine). Nutilepingu täitmiseks tuleb see käivitada selgelt teise tehinguga või peavad olema täidetud eeltingimused. Nutilepingu täitmise tulemused salvestatakse samuti plokiahelasse. Andmete hankimine plokiahelast on võimalik, kuid äärmiselt piiratud.

Millist äriloogikat saab nutilepingu abil rakendada? Tegelikult mitte nii palju, näiteks tingimuste kontrollimine plokiahela andmete põhjal, digitaalsete varade omanike muutmine nende tingimuste järgi, andmete salvestamine plokiahela püsivasse mälu. Loogika rakendatakse spetsiaalses kõrgtaseme keeles Solidity.

Klassikaliseks näiteks funktsionaalsusest, mida rakendatakse nutilepingute abil, on tokenite väljastamine ICO-de läbiviimiseks. Näiteks olen ma loonud nutilepingu tagasihoidlikuks 500 000 000 AlexToken'i väljastamiseks. Etherscan'i lingil asub

Smart-kontakti lähtekood Solidity keeles

pragma solidity ^0.4.23;

library SafeMath {
    /**
     * @dev Multiplies two numbers, throws on overflow.
     **/
    function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
        if (a == 0) {
            return 0;
        }
        c = a * b;
        assert(c / a == b);
        return c;
    }
    
    /**
     * @dev Integer division of two numbers, truncating the quotient.
     **/
    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        // assert(b > 0); // Solidity automatically throws when dividing by 0
/**
 * @title SafeMath
 * @dev Math operations with safety checks that throw on error
 */
        // uint256 c = a / b;
        // assert(a == b * c + a % b); // There is no case in which this doesn't hold
        return a / b;
    }
    
    /**
     * @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
     **/
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        assert(b <= a);
        return a - b;
    }
    
    /**
     * @dev Adds two numbers, throws on overflow.
     **/
    function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
        c = a + b;
        assert(c >= a);
        return c;
    }
}

/**
 * @title Ownable
 * @dev The Ownable contract has an owner address, and provides basic authorization control
 * functions, this simplifies the implementation of "user permissions".
 **/
 
contract Ownable {
    address public owner;
    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    /**
     * @dev The Ownable constructor sets the original `owner` of the contract to the sender account.
     **/
   constructor() public {
      owner = msg.sender;
    }
    
    /**
     * @dev Throws if called by any account other than the owner.
     **/
    modifier onlyOwner() {
      require(msg.sender == owner);
      _;
    }
    
    /**
     * @dev Allows the current owner to transfer control of the contract to a newOwner.
     * @param newOwner The address to transfer ownership to.
     **/
    function transferOwnership(address newOwner) public onlyOwner {
      require(newOwner != address(0));
      emit OwnershipTransferred(owner, newOwner);
      owner = newOwner;
    }
}

/**
 * @title ERC20Basic interface
 * @dev Basic ERC20 interface
 **/
contract ERC20Basic {
    function totalSupply() public view returns (uint256);
    function balanceOf(address who) public view returns (uint256);
    function transfer(address to, uint256 value) public returns (bool);
    event Transfer(address indexed from, address indexed to, uint256 value);
}

/**
 * @title ERC20 interface
 * @dev see https://github.com/ethereum/EIPs/issues/20
 **/
contract ERC20 is ERC20Basic {
    function allowance(address owner, address spender) public view returns (uint256);
    function transferFrom(address from, address to, uint256 value) public returns (bool);
    function approve(address spender, uint256 value) public returns (bool);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @title Basic token
 * @dev Basic version of StandardToken, with no allowances.
 **/
contract BasicToken is ERC20Basic {
    using SafeMath for uint256;
    mapping(address => uint256) balances;
    uint256 totalSupply_;
    
    /**
     * @dev total number of tokens in existence
     **/
    function totalSupply() public view returns (uint256) {
        return totalSupply_;
    }
    
    /**
     * @dev transfer token for a specified address
     * @param _to The address to transfer to.
     * @param _value The amount to be transferred.
     **/
    function transfer(address _to, uint256 _value) public returns (bool) {
        require(_to != address(0));
        require(_value <= balances[msg.sender]);
        
        balances[msg.sender] = balances[msg.sender].sub(_value);
        balances[_to] = balances[_to].add(_value);
        emit Transfer(msg.sender, _to, _value);
        return true;
    }
    
    /**
     * @dev Gets the balance of the specified address.
     * @param _owner The address to query the the balance of.
     * @return An uint256 representing the amount owned by the passed address.
     **/
    function balanceOf(address _owner) public view returns (uint256) {
        return balances[_owner];
    }
}

contract StandardToken is ERC20, BasicToken {
    mapping (address => mapping (address => uint256)) internal allowed;
    /**
     * @dev Transfer tokens from one address to another
     * @param _from address The address which you want to send tokens from
     * @param _to address The address which you want to transfer to
     * @param _value uint256 the amount of tokens to be transferred
     **/
    function transferFrom(address _from, address _to, uint256 _value) public returns (bool) {
        require(_to != address(0));
        require(_value <= balances[_from]);
        require(_value <= allowed[_from][msg.sender]);
    
        balances[_from] = balances[_from].sub(_value);
        balances[_to] = balances[_to].add(_value);
        allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value);
        
        emit Transfer(_from, _to, _value);
        return true;
    }
    
    /**
     * @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
     *
     * Beware that changing an allowance with this method brings the risk that someone may use both the old
     * and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
     * race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     * @param _spender The address which will spend the funds.
     * @param _value The amount of tokens to be spent.
     **/
    function approve(address _spender, uint256 _value) public returns (bool) {
        allowed[msg.sender][_spender] = _value;
        emit Approval(msg.sender, _spender, _value);
        return true;
    }
    
    /**
     * @dev Function to check the amount of tokens that an owner allowed to a spender.
     * @param _owner address The address which owns the funds.
     * @param _spender address The address which will spend the funds.
     * @return A uint256 specifying the amount of tokens still available for the spender.
     **/
    function allowance(address _owner, address _spender) public view returns (uint256) {
        return allowed[_owner][_spender];
    }
    
    /**
     * @dev Increase the amount of tokens that an owner allowed to a spender.
     *
     * approve should be called when allowed[_spender] == 0. To increment
     * allowed value is better to use this function to avoid 2 calls (and wait until
     * the first transaction is mined)
     * From MonolithDAO Token.sol
     * @param _spender The address which will spend the funds.
     * @param _addedValue The amount of tokens to increase the allowance by.
     **/
    function increaseApproval(address _spender, uint _addedValue) public returns (bool) {
        allowed[msg.sender][_spender] = allowed[msg.sender][_spender].add(_addedValue);
        emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
        return true;
    }
    
    /**
     * @dev Decrease the amount of tokens that an owner allowed to a spender.
     *
     * approve should be called when allowed[_spender] == 0. To decrement
     * allowed value is better to use this function to avoid 2 calls (and wait until
     * the first transaction is mined)
     * From MonolithDAO Token.sol
     * @param _spender The address which will spend the funds.
     * @param _subtractedValue The amount of tokens to decrease the allowance by.
     **/
    function decreaseApproval(address _spender, uint _subtractedValue) public returns (bool) {
        uint oldValue = allowed[msg.sender][_spender];
        if (_subtractedValue > oldValue) {
            allowed[msg.sender][_spender] = 0;
        } else {
            allowed[msg.sender][_spender] = oldValue.sub(_subtractedValue);
        }
        emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
        return true;
    }
}

/**
 * @title Configurable
 * @dev Configurable varriables of the contract
 **/
contract Configurable {
    uint256 public constant cap = 1000000000*10**18;
    uint256 public constant basePrice = 100*10**18; // tokens per 1 ether
    uint256 public tokensSold = 0;
    
    uint256 public constant tokenReserve = 500000000*10**18;
    uint256 public remainingTokens = 0;
}

/**
 * @title CrowdsaleToken 
 * @dev Contract to preform crowd sale with token
 **/
contract CrowdsaleToken is StandardToken, Configurable, Ownable {
    /**
     * @dev enum of current crowd sale state
     **/
     enum Stages {
        none,
        icoStart, 
        icoEnd
    }
    
    Stages currentStage;
    /**
     * @dev constructor of CrowdsaleToken
     **/
    constructor() public {
        currentStage = Stages.none;
        balances[owner] = balances[owner].add(tokenReserve);
        totalSupply_ = totalSupply_.add(tokenReserve);
        remainingTokens = cap;
        emit Transfer(address(this), owner, tokenReserve);
    }
    
    /**
     * @dev fallback function to send ether to for Crowd sale
     **/
    function () public payable {
        require(currentStage == Stages.icoStart);
        require(msg.value > 0);
        require(remainingTokens > 0);
        
        uint256 weiAmount = msg.value; // Calculate tokens to sell
        uint256 tokens = weiAmount.mul(basePrice).div(1 ether);
        uint256 returnWei = 0;
        
        if(tokensSold.add(tokens) > cap){
            uint256 newTokens = cap.sub(tokensSold);
            uint256 newWei = newTokens.div(basePrice).mul(1 ether);
            returnWei = weiAmount.sub(newWei);
            weiAmount = newWei;
            tokens = newTokens;
        }
        
        tokensSold = tokensSold.add(tokens); // Increment raised amount
        remainingTokens = cap.sub(tokensSold);
        if(returnWei > 0){
            msg.sender.transfer(returnWei);
            emit Transfer(address(this), msg.sender, returnWei);
        }
        
        balances[msg.sender] = balances[msg.sender].add(tokens);
        emit Transfer(address(this), msg.sender, tokens);
        totalSupply_ = totalSupply_.add(tokens);
        owner.transfer(weiAmount);// Send money to owner
    }
    

    /**
     * @dev startIco starts the public ICO
     **/
    function startIco() public onlyOwner {
        require(currentStage != Stages.icoEnd);
        currentStage = Stages.icoStart;
    }
    

    /**
     * @dev endIco closes down the ICO 
     **/
    function endIco() internal {
        currentStage = Stages.icoEnd;
        // Transfer any remaining tokens
        if(remainingTokens > 0)
            balances[owner] = balances[owner].add(remainingTokens);
        // transfer any remaining ETH balance in the contract to the owner
        owner.transfer(address(this).balance); 
    }

    /**
     * @dev finalizeIco closes down the ICO and sets needed varriables
     **/
    function finalizeIco() public onlyOwner {
        require(currentStage != Stages.icoEnd);
        endIco();
    }
    
}
 
/**
 * @title LavevelToken 
 * @dev Contract to create the Lavevel Token
 **/
contract AlexToken is CrowdsaleToken {
    string public constant name = "AlexToken";
    string public constant symbol = "ALT";
    uint32 public constant decimals = 18;
}

ja binaarne esitus, nagu seda võrk näeb

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Lisateavet nutilepingute kohta leiate artiklist: Mis on nutilepingud Ethereumis.

Kokkuvõte

Oleme loetlenud tehnoloogiad, millele kaasaegsed plokiahelad tuginemas, ja kuidas need omavahel seotud on. Nüüd määratleme, milliseid probleeme saab lahendada plokiahela abil ning milliste lahenduste puhul on see halvemal juhul ebaefektiivne. Nii et plokiahela kasutamine pole vajalik, kui:

Tehingud toimuvad usaldusväärses keskkonnas;
Vaheõpikute tasud ei halvendavad osaliste elu;
Osalistel puudub omand, mida on võimalik esindada digitaalselt;
Digitaalsetes varades ei ole jaotust, st väärtust omab või tarnib vaid üks osaline.

Milline tulevik ootab plokiahelat? Praegu on võimalik vaid oletada võimalikke arenguteid plokiahela tehnoloogiatele:

Plokiahel muutub sama tavaliseks andmebaasitehnoloogiaks nagu SQL või NoSQL, et lahendada oma spetsiifilisi ülesandeid;
Plokiahel saab laialdaselt tuntud protokolliks, nagu HTTP Internetis;
Plokiahel tuleb uue finants- ja poliitsüsteemi aluseks meie planeedil!

Järgmisel osal vaatleme, millised plokiahelad praegu eksisteerivad ja kuidas neid rakendatakse erinevates tööstusharudes.

See on alles algus!

Allikas: habr.com