🥇Mida maksab meile plokiahela loomine?

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

Analüüsides mitmeid blockchain projekte (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin jne), mõistan, et tehniliselt on need kõik üles ehitatud sama põhimõtte alusel. Blockchaine võib võrrelda majadega, millel, vaatamata konstruktsioonide, dekoreerimise ja kasutuse erinevustele, on siiski olemas fundament, seinad, katus, aknad ja uksed, mis on omavahel teatud viisil seotud. Ja kui mõista hoonete projekteerimise põhiprintsiipe, teades kasutatavate materjalide omadusi, siis saab määrata konkreetse maja eesmärki. Praegu on blockchaini olukord selline, 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õttekas kasutada blockchaini tehnoloogiaid.

Käesolevas artiklis vaatleme kõiki blockchaine iseloomustavaid omadusi ja põhimõtteid. Seejärel vaatame ülesandeid, mida saab blockchaini abil lahendada, ning kinnitame materjali, ehitades oma virtuaalsel krundil väikese, kuid tõelise blockchaine!

Nii et tuletagem meelde, milliseid probleeme blockchain algselt lahendas.

Olen kindel, et paljud ütlevad, et tegemist on jagatud, detsentraliseeritud, avaliku ja muutumatute andmebaasiga. Kuid milleks seda kõike oli vaja?

Ma eelistan alustada uue tehnoloogia uurimist standardite lugemisega, kuna need on aluseks kõikidele artiklitele ja raamatutele uuritaval teemal. Kuid blockchaini standardid on praegu puudulikud, ISO-s on loodud ainult komiteed nende arendamiseks. Praegu on igas avalikus blockchain projektis oma dokument White paper, mis on sisuliselt tehniline ülesanne. Esimene tuntud blockchain projekt on Bitcoin. Minge ametlikule Bitcoin'i veebisaidile ja vaadake kust kõik pihta hakkas.

Blockchaini ülesanne

Nii et ülesanne, mille blockchain lahendas Bitcoin'i pioneerivõrgus, on usaldusväärse vara (assets) ülekandmise teostamine usaldamatutes keskkondades ilma vahendajateta. Näiteks on Bitcoin'i võrgus digitaalne vara – digitaalne bitcoin. Ja kõik tehnilised lahendused Bitcoin'is ja teistes blockchaineides põhinevad selle ülesande lahendamisel.

Probleemid, mida blockchain lahendab

Oletame, et mingi rahandusorganisatsioon ütleb, et on loonud ülemaailmse võrgu, mille kaudu saab raha edastada igale inimesele. Kas te usute? Kui see organisatsioon on Visa või MasterCard, siis tõenäoliselt usute, kuid kui see on näiteks AnonymousWorldMoney, siis tõenäoliselt ei usuks. Miks see nii on? Sest me teame väga hästi, kuidas eraettevõtted loovad ja haldavad jaotatud süsteeme, milliste eesmärkidega ja millised võivad olla tagajärjed. Vaatame lähemalt nende süsteemide probleeme ja kuidas neid saaks lahendada plokiahela tehnoloogiate abil.

Oletame, et aga AnonymousWorldMoney süsteemis on serverid andmebaasidega ning oleks hea, kui neid on mitu erinevates andmekeskustes. Kui saatja edastab raha, registreeritakse tehing, mis replitseeritakse kõigile serveritele, ja raha jõuab saajani.

Ideaalsetes tingimustes toimib selline skeem suurepäraselt, kuid meie tegelikus maailmas esinevad järgmised probleemid:

Osaliste identifitseerimise probleem ühest küljest ja tehingute anonüümsuse vajadus teisest küljest. See tähendab, et raha peab jõudma konkreetse saajani ning nii, et keegi tehingust peale osaliste ei teaks. Pangad omavad kontonumbreid ja pangakaarditõendeid, mis on seotud konkreetse füüsilise või juriidilise isikuga, ning pangasaladus kaitseb tehingute teavet. Kuid kes garanteerib, et hüpoteetiline AnonymousWorldMoney ei kasuta isikuandmeid ja tehingute teavet oma huvides?
Kuidas veenduda, et saaja sai täpselt selle summa, mille ta ära toimetati? Näiteks saatis saatja 100 dollarit, kuid saaja sai ainult 10 dollarit. Saatja tuleb AnonymousWorldMoney kontorisse oma kviitungiga, kuid ametnik näitab oma versiooni, kus on kirjas, et saatja saatis vaid 10 dollarit.
Usaldusväärsete keskkondade probleem, näiteks pettus nimelt double-spending. Ebaaus osaline võib oma saldot mitu korda kulutada, enne kui makse replitseeritakse kõigile serveritele. CAP teoreemi, loomulikult ei ole keegi tühistanud, ja lõpuks saavutatakse kooskõla, kuid keegi ei saa raha teenuste või kaupade eest. Seetõttu, kui makseorganisatsiooni või tehingu osaliste usaldusväärsuses ei ole täielikku usaldust, tuleb luua võrk, mis põhineb mitte usaldusel, vaid krüptograafial.
Konditsionaalne AnonymousWorldMoney omab lõplikku arvu servereid, mis võivad muutuda kättesaamatuks tahes tahtmata või pahatahtlikult.
AnonymousWorldMoney võtab oma märkimisväärse tasu.
Juhtimise võimalus. Bitcoin'i kasutamise käigus selgus, et inimesed soovivad mitte ainult omavahel münte üle kanda, vaid ka kontrollida erinevaid tehingu läbimise tingimusi, programmeerida tegevusstsenaariume, sooritada automaatseid toiminguid vastavalt tingimustele jne.

Kuidas plokiahel lahendab neid probleeme

Osalejate identifitseerimine toimub paari võtme kaudu: privaatse ja avaliku, ning digitaalallkirja algoritm tuvastab saatja ja saaja üheselt, jättes nende isikud anonüümsuseks.
Tehingud kogutakse blokkidesse, arvutatakse ploki hash, mis salvestatakse järgmisse bloki. Selline hashide järjestikune salvestamine blokkides andis plokiahela tehnoloogiale nime ja teeb võimatuks märkamatud muudatused / eemaldamised blokkides või üksikutes tehingutes. Seega, kui tehing on plokiahelas, võib olla kindel, et selle andmed jäävad muutumatuks.
Kahekorraline kulutamine (double-spending) ennetatakse, saavutades konsensuse võrgu sees, milliseid andmeid pidada õigeks ja milliseid tagasi lükata. Bitcoin'i võrgus saavutatakse konsensus töö tõestamise (PoW, Proof-of-Work) kaudu.
Võrgu töökindlus saavutatakse, kuna plokiahel on avalik, kus iga osaleja saab käivitada oma sõlme, saada täieõigusliku koopia plokiahelast ja veelgi enam, iseseisvalt kontrollida tehingute õigust.
Plokiahelas ei ole täielikult komisjonitasudest vabanemine võimalik, kuna tuleb maksta võrgusüsteemi toetavatele inimestele, kuid plokiahas on komisjonitasu vajadus tõestatud nii veenvalt, et kahtlusi selle vajalikkuses ei jää.
Kaasaegsetes plokiahelates on võimalik ellu viia äriloogikat, mida plokiahelas nimetatakse nutikateks lepinguteks (Smart Contracts). Nutikate lepingute loogika realiseeritakse erinevates kõrgema taseme keeltes.

Vaadakem neid lahendusi lähemalt.

Plokiahela arhitektuur

Plokiahela koostisosad

Iga osaleja saab käivitada oma sõlme, millel on täielik koopia plokiahelast (full node). Täielikud sõlmed, mis saavad kirjutada tehinguid plokiahelasse, nimetatakse konsensus sõlmedeks (witness) või kaevandajateks (miner). Täielikud sõlmed, mis ainult kontrollivad tehingute õigsust, nimetatakse audit sõlmedeks (audit). Kerged kliendid (light clients) ei hoia täielikke koopiaid plokiahelast, vaid suhtlevad võrguga, kasutades täielikke sõlmi.
Enamik kasutajatest kasutab tehingute tegemiseks just kergeid kliente või veebikotte. Kõik sõlmed on omavahel seotud. Sellise elementide komplekti korral muutub võrgu arhitektuur stabiilsemaks:

Tehingu elutsükkel

Vaatame tehingu elutsüklit ja jagame selle osadeks:

Plokiahela tehnoloogiad

Peatume lähemalt tehniliste lahenduste ja nendevaheliste suhete peal.

Identifitseerimine

Iga plokiahela tehing peab olema allkirjastatud digitaalse allkirjaga. Seetõttu peab igal osalejal olema tehingu tegemiseks võtmete paar: private / public. Mõnikord nimetatakse võtmete paari rahakotiks (wallet), kuna võtmed on selgelt seotud unikaalse digitaalse aadressi ja osaleja saldoga. Tegelikult on võtmed ja aadressid lihtsalt numbrilised stringid erinevates arvutussüsteemides. Näited võtmetest ja rahakoti aadressist:

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

Digitaalallkirja loomiseks plokiahelates kasutatakse algoritmi, mis põhineb elliptilistel kõveratel: Elliptic Curve Digital Signature Algorithm (ECDSA). Selle tööks valitakse tavaliselt privaatvõti (256-bitine number) juhuslikult. Võtmete variatsioonide arv on 2 astmes 256, seega võib rääkida praktilisest võimatuse kohta privaatvõtmete väärtuste kattumiseks.

Seejärel saadakse avalik võti privaatvõtme põhjal, korrutades selle väärtuse elliptilise kõvera punkti koordinaatidega, mille tulemusena saadakse uue punkti koordinaadid sellel samal kõveral. See toiming tagab võtme paari, mis sobib digitaalsete allkirjade jaoks tehingutes. Lõpuks arvutatakse rahakoti aadress ühemõtteliselt avalikust võtme põhjal.

Sellel teemal on palju artikleid krüptograafia üksikasjade kohta, mida plokiahelas kasutatakse, näiteks: Bitcoin lühiülevaates — Krüptograafia

Erakluslik võti peab olema rangelt saladuses ja turvaliselt hoitud. Avalik võti on kõigile teada. Privaatsusvõtme kadumise korral ei ole varale (müntidele) juurdepääsu taastamine võimalik ja raha kaob igaveseks. Seetõttu on privaatsusvõtmete usaldusväärne hoidmine äärmiselt oluline, kuna see ei ole pank, kuhu saab alati siseneda isikutunnistusega ja konto taastada. On olemas terve tööstus nn külmade krüptorahakottide tootmiseks, mis meenutavad mälupulkasid:

või võib kasutada usaldusväärsemaid meetodeid, näiteks graveerida privaatsusvõti žetoonidele:

Tehingud

Tehingu struktuuri kohta saab rohkem lugeda artiklist Bitcoin lühidalt — Tehing. Meile on oluline mõista, et igal tehingul on vähemalt järgmised andmed:

From: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - saatja digitaalne aadress
To: 0x367adb7894334678b90аfe7882a5b06f7fbc783a - saaja digitaalne aadress
Value: 0.0001 - tehingu summa
Transaction Hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - tehingu hash

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

Tehingublockid

Kontrollides tehingute kehtivust, koostavad sõlmed neist plokid. Lisaks tehingutele salvestatakse plokki eelmise ploki hash, number (Nonce loendaja) ning arvutatakse käesoleva ploki hash SHA-256 algoritmi järgi. Hash peab vastama kehtestatud raskusastme tingimustele. Näiteks Bitcoin võrku raskusaste muutub automaatselt iga kahe nädala järel vastavalt võrgumugavusele, et plokki genereerida umbes iga 10 minuti järel. Raskusaste määratakse järgmise tingimuse järgi: leitud hash peab olema väiksem etteantud arvust. Kui antud tingimus ei ole täidetud, lisatakse Nonce'ile 1 ja hash'i arvutamine kordub. Hash'i otsimiseks kasutatakse Nonce'i välja, kuna see on ainus ploki andmeväli, mida saab muuta, kõik teised peavad jääma muutumatuks. Õige hash peab omama teatud arvu nullide alguses, näiteks üks reaalne hash:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Hashi leidmine on tõestus tehtud töö (Proof-of-Work, PoW) Bitcoin või Ethereum võrkudes. Hashide leidmise protsessi nimetatakse ka kaevandamiseks (mining), just nagu kulda kaevandamisel. Nimi määratleb piisavalt täpselt protsessi olemuse, kuna toimub lihtne võimaluste proovimine, ja kui keegi leiab sobiva hash'i, siis see on tõesti õnn. See on nagu leida ehtne kullasüda tonnide tühi materjali seest. Bloki tasu on praegu 12.5 BTC ja kui korrutada see Bitcoin'i hetke hinnaga $3900, siis tähendab see rohkem kui kilogrammi puhtast kullast. On millegagi võidelda!

Pärast hash'i eduka leidmise korral salvestatakse blokk ja leitud hash järgnevasse blokki plokiahelasse. Täiendavat teavet plokkide struktuuri kohta saab lugeda artiklist Bitcoin kokkuvõtlikult - Plokiahel, ja allpool on toodud lihtsustatud skeem:

Plokiahel algab blokkist, millel pole veel eelmise bloki hash'i. Selline blokk plokiahelas on ainus ja sellel on oma nimi Genesis block. Ülejäänud plokkidel on sama struktuur, kuid need erinevad vaid tehingute arvu poolest. Reaalseid tehinguid ja plokke, mis praegu genereeritakse Bitcoin'is või Ethereum'is, saab vaadata Block Explorer.

Bitcoin'i plokkide suurus on piiratud 1 MB ja minimaalne teabe maht tehingus on umbes 200 byte'i, seega võib plokis olla maksimaalselt umbes 6000 tehingut. Sealt ka Bitcoin'i tootlikkus, mille üle kõik naeravad: blokk genereeritakse umbes 10 minuti * 60 sek = 600 sekundi järel, mis annab ametliku tootlikkuse umbes 10 TPS. Kuigi tegelikult ei ole see tootlikkus, vaid teadlikult rakendatud töö algoritm. Ethereum'is, et konkurentsis püsida, tehti ploki genereerimise aeg 15 sekundile ja tootlikkus tõusis ametlikult. Seetõttu on PoW-d kasutavates plokiahelates tootlikkuse võrdlemine praktiliselt mõttetu, kuna see sõltub otseselt hash'i arvutamise keerukusest, millele võib määrata igasuguse.

Forkid

Mis juhtub, kui mitmed sõlmed leiavad, et hashid vastavad keerukusnõuetele, kuid on erinevad (teisisõnu, jõuavad erinevatele konsensustele) ja salvestavad plokid plokiahelasse? Vaatame, kuidas plokiahel kaitseb end selle olukorra eest. Sel juhul tekib nii nimetatud fork ('haarak'), ja plokiahelal on kaks versiooni ahelast:

Mis juhtub edasi? Edasi läheb osa võrku tööle ploki N+2 ühe ahela jaoks ja osa teise jaoks:

Mõni neist plokkidest leitakse varem ja saadetakse plokiahelasse, siis peab plokiahel reeglite järgi vahetama pikema ahela poole ja tühistama kõik tehingud alternatiivses plokis:

Sellegipoolest võib tekkida olukord, kus osaleja tehing oli ainult ühes fork'i plokis, mis tühistati. Seetõttu, et olla kindel, et vajalik tehing on salvestatud plokiahelasse, on üldine soovitus — enne tehingule usaldamist oodake, kuni järgmised paar plokki lisatakse plokiahelasse. Soovitused, kui palju plokke erinevates plokiaheline ootama, varieeruvad. Näiteks Bitcoin võrgu puhul on minimaalne — 2 plokki, maksimaalne 6.

Sama pilt plokkide fork'ist täheldatakse ka nii nimetatud 51% rünnaku puhul — see on siis, kui kaevandajate grupp püüab kasvatada alternatiivset plokkide ahelat, saavutades tehingute tühistamise oma petlike tehingutega. Kuigi praegu on kasulikum kulutada oma ressursse ausale kaevandamisele, mitte pettusele.

Konsensus

Ploki salvestamiseks plokiahelasse peab võrk jõudma konsensusele. Tuletame meelde, et konsensuse saavutamise ülesanne arvutivõrkudes. Probleem formuleeritakse kui Bütsantsi kindralite BFT ülesanne (Bütsantsi vea taluvus). Jätame kõrvale maalilised kirjeldused Bütsantsi armee probleemidest, kuid ülesande saab formuleerida nii: kuidas jõuda võrgu sõlmedel ühisele tulemustele, kui osa sõlmedest võivad teadlikult neid moonutada. Olemasolevad BFT lahendamisalgoritmid näitavad, et võrk suudab õigesti funktsioneerida, kui petjaid on vähem kui 1/3. Miks ei olnud Bitcoin võrgus rakendatud BFT konsensust? Miks oli vaja kasutada PoW? On mitu põhjust:

BFT töötab hästi väikese kindla sõlmearvuga, aga avalikus plokiahelas on sõlmede arv ettearvamatu ning pealegi võivad sõlmed vabadelt sisse ja välja lülituda.
On vajalik motiveerida inimesi plokiahela sõlmi käivitama. Selleks peavad inimesed saama tasu. BFT puhul ei ole formaalselt millegi eest tasu saada, kuid PoW puhul on kõigile intuitiivselt arusaadav, et tasu makstakse elektri eest, mida protsessor kasutab ploki hashi leidmiseks.

Lisaks PoW-le 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 (Simplified BFT) ja PBFT (Practical BFT), näiteks plokiahelas Exonum

Veidi peatume PoS konsensusel, kuna just PoS ja selle variandid on saanud suurimat populaarsust erasektoris. Miks just erasektoris? Ühelt poolt on PoS omadused paremad võrreldes PoW-ga, kuna konsensuse saavutamiseks on vajalikud väiksemad arvutusressursid, mis omakorda kiirendab andmete salvestamist plokiahelasse. Teiselt poolt on PoS-s rohkem petmise võimalusi, seega, et seda neutraliseerida, peavad kõik plokiahela osalised olema tuntud.

PoS konsensus põhineb sõlme valikul, mis võib salvestada ploki tehingutega plokiahelasse sõltuvalt konto rahasummast, täpsemalt mitte kontol olevatest summadest, vaid pandiks antud summadest. St mida rohkem sul on pandiks antud, seda suurema tõenäosusega valib võrgustik sinu sõlme ploki salvestamiseks. Pandit ei tagastata, kui plokk osutub valeväidete plokiks. Nii on saavutatud kaitse pettuste eest. PoS-l on järgmist tüüpi variatsioonid:

Delegated PoS (DPoS) konsensus jagab osalejad 'hääletavatesse' ja 'tuvastavatesse'. Münthoidjad (hääletavad osalised) delegeerivad oma õiguse tehingute kontrollimiseks ja salvestamiseks plokiahelas teistele osalistele. Nii teevad valideerijad kogu arvutusliku töö ja saavad selle eest tasu, samas kui hääletavate osaliste olemasolu tagab valideerijate aususe, kuna neid on võimalik iga hetk muuta.
LPoS (Leased Proof-of-Stake) konsensus võimaldab teie vahendeid rendile anda teistele sõlmedele, et neil oleks suurem tõenäosus bloke kontrollimiseks. Nii saab teenida tehingutasusid, osalemata ise tehingute kontrollimises ja plokkide kaevandamises.

On olemas veel mitmeid konsensusi, mis pole veel laialdaselt levinud, siin lihtsalt loetlen need informatsiooni jaoks, ülevaate ise konsensusalgoritmidest saab vaadata näiteks artiklist: Konsensusalgoritmid 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-Importans)

Usaldusväärsus ja plokiahela rakendusskeemid

Avalik plokiahel

Püsivus Avalik või teine nimi Luba saama plokiahel saavutatakse sellega, et igaüks saab ühenduda ja vaadata teavet või isegi oma sõlme ühendada, ning usaldus põhineb PoW konsensusel.

Privaatne plokiahel

Privaatne või Privaatne luba saama plokiahel. Nendes plokiahelates on juurdepääs teabele ainult teatud grupil osalejatest (organisatsioonidest või inimestest). Selliseid plokiahelasid loovad organisatsioonid eesmärgiga suurendada üldist kasu või efektiivsust. Nende usaldusväärsus tagatakse osalejate ühiste eesmärkide ja konsensusalgoritmide PoS ja BFT abil.

Plokiahela konsortsium

On olemas Konsortsium või Avalik luba saama plokiahel. Need on plokiahelad, kuhu igaüks saab ühendada jälgimiseks, kuid teabe lisamine või oma sõlme ühendamine on osalejal võimalik ainult teiste osalejate loal. Selliseid plokiaheli ehitavad organisatsioonid, et suurendada usaldust klientide või toodete tarbijate või üldiselt ühiskonna seas. Siin saavutatakse usaldusväärsus samuti osalejate vahelise usalduse ja samade konsensusalgoritmidega PoS ning BFT.

Nutilepingud

Plokiahelates, mis on loodud pärast Bitcoini, on mingil määral lisatud nutilepingute täitmise võimalus. Sisuliselt on nutileping tehing, mis sisaldab programmi koodi täitmiseks. Ethereumis täidetakse nutilepingud EVM-is (Ethereum Virtual Machine). Nutilepingu täitmist tuleb algatada selgelt teise tehingu kaudu või peab olema täidetud eeltingimused. Nutilepingu täitmise tulemused salvestatakse samuti plokiahelasse. Andmete väljast plokiahelale saamine on võimalik, kuid äärmiselt piiratud.

Millist äri loogikat saab rakendada nutilepingute abil? Tegelikult ei ole seda nii palju, näiteks plokiahela andmete alusel tingimuste kontrollimine, digitaalsete varade omanike muutmine vastavalt nendele tingimustele, andmete salvestamine plokiahela püsivasse mällu. Loogika rakendamine toimub spetsiaalses kõrgema taseme keeles Solidity.

Klassikaline näide funktsionaalsusest, mis rakendatakse nutilepingute abil, on tokenite väljastamine ICO-de läbiviimiseks. Näiteks olen rakendanud nutilepingut tagasihoidlikuks 500 000 000 AlexTokeni väljastamiseks. link Etherscanis lemmikutes või

nutilepingute 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 näeb võrk

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Rohkem üksikasju nutilepingute kohta saab lugeda artiklist: Mis on nutilepingud Ethereumis.

Kokkuvõte

Oleme loetletud tehnoloogiad, millele kaasaegsed plokiahelad tuginevad, ja kuidas need omavahel seotud on. Nüüd formuleerime, milliseid probleeme saab plokiahela abil lahendada ja milliste osas on selle kasutamine parimal juhul ebaefektiivne. Nii et plokiahela kasutamine ei ole tingimata vajalik, kui:

Tehingud toimuvad usaldusväärses keskkonnas;
Vaheltöötajate tasu ei halva osalejate elu;
Osalejatel ei ole omandit, mida saaks esitada digitaalsete varade näol;
Digitaalsetes varades ei ole jaotatust, st väärtust omab või tarnib ainult üks osaleja.

Milline tulevik plokiahelat ootab? Praegu saab vaid oletada plokiahela tehnoloogiate võimalikke arenguteid:

Plokiahelast saab sama tavapärane andmebaasi tehnoloogia nagu SQL või NoSQL oma kindla ülesande lahendamiseks;
Plokiahelast saab laialt levinud protokoll, nagu HTTP Internetis;
Plokiahela alusel kujuneb suuremalt jaolt planeedi uus rahandus- ja poliitikasüsteem!

Järgmises osas vaatame, millised plokiahelad praegu eksisteerivad ja milleks neid erinevates tööstusharudes kasutatakse.

See on alles algus!

Allikas: habr.com