Visas cilvēces vēsture ir nepārtraukts atbrīvošanās process no saitēm un jaunu, vēl izturīgāku saišu radīšana. (Anonīms autors)
Analizējot daudzas blockchain projektus (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin utt.), es saprotu, ka tehniskā ziņā tie visi būvēti pēc līdzīgiem principiem. Blockchain atgādina mājas, kurām, neskatoties uz dažādām konstrukcijām, dekoru un nolūkiem, ir pamats, sienas, jumts, logi un durvis, kas saistīti noteiktos veidos. Ja saproti būvniecības pamatprincipus un zini izmantoto materiālu īpašības, vari noteikt konkrētā mājas mērķi. Pašlaik ar blockchain ir tā, ka visi par to ir dzirdējuši, bet maz kas saprot arhitektūru un darbības principus. Tas rada neskaidrības par to, kāpēc un kā ir jēga izmantot blockchain tehnoloģijas.
Šajā rakstā mēs apskatīsim visiem blockchain kopīgās īpašības un principus. Pēc tam aplūkosim problēmas, kuras var risināt, izmantojot blockchain, un, lai nostiprinātu materiālu, uzbūvēsim mazu, bet īstu blockchain savā virtuālajā vietnē!
Tātad, atcerēsimies, kuras problēmas sākotnēji atrisināja blockchain.
Es esmu pārliecināts, ka daudzi teiks par sadalītu, decentralizētu, publisku un nemainīgu datu bāzi. Bet kāpēc tas viss bija nepieciešams?
Es dodu priekšroku sākt jebkuras tehnoloģijas apguvi ar standartu izpēti, jo tieši uz tiem balstās visi raksti un grāmatas, kas saistītas ar pētāmo tēmu. Taču blockchain standartu pašlaik nav, ISO ir izveidoti tikai to izstrādei. Šobrīd katram publiskajam blockchain projektam ir savs White paper dokuments, kas būtībā ir tehniskais uzdevums. Pirmais publiski pazīstamais blockchain projekts ir Bitcoin tīkls. Aiziet uz oficiālo tīkla vietni un kā viss sākās.
Blockchain uzdevums
Tātad, uzdevums, ko blockchain atrisināja Bitcoin pioniera tīklā — tas ir uzticamas īpašumtiesību nodošanas veikšana uz digitāliem aktīviem nedrošā vidē bez starpniekiem. Piemēram, Bitcoin tīklā digitālais aktīvs ir digitālās monētas bitcoin. Un visi tehniskie risinājumi Bitcoin un citu blockchain ir saistīti ar šī uzdevuma risināšanu.
Problēmas, kuras risina blockchain
Iedomājieties, ka kāda finanšu iestāde apgalvo, ka ir izveidojusi tīklu visā pasaulē, ar kuru var pārskaitīt naudu ikvienam. Vai jūs tam noticētu? Ja šī organizācija ir Visa vai MasterCard, visticamāk, jūs noticētu, bet, ja teiksim, AnonymousWorldMoney, iespējams, nē. Kāpēc tā? Tāpēc, ka mēs ļoti labi zinām, kā privātās kompānijas izveido izsistītās sistēmas, ar kādiem mērķiem un uz ko tas var novest. Apskatīsim tuvāk šādu sistēmu problēmas un to, kā tās var risināt, izmantojot blokķēdes tehnoloģijas.
Pieņemsim, ka hipotētiskajā AnonymousWorldMoney ir serveri ar datu bāzēm, un, ja to ir vairāki dažādos datu centros, tas ir labi. Kad sūtītājs pārskaita naudu, tiek reģistrēta transakcija, kas tiek replicēta uz visiem serveriem, un nauda nonāk pie saņēmēja.
Ideālā pasaulē šāds shēma lieliski darbojas, bet mūsu pasaulē rodas šādas problēmas:
- Problēma ir identitātes noteikšana dalībniekiem no vienas puses un nepieciešamība pēc darījumu anonimitātes no otras. Tas ir, nauda jāaizsūta konkrētam saņēmējam un tā, lai par šo transakciju neviens neuzzinātu, izņemot darījuma dalībniekus. Bankām ir kontu un kredītkaršu numuri, kas ir saistīti ar konkrētu fizisku vai juridisku personu, un bankas noslēpums aizsargā informāciju par darījumiem. Bet kas garantē, ka hipotētiskā AnonymousWorldMoney neizmanto personas datus un informāciju par darījumiem savām vajadzībām?
- Kā pārliecināties, ka saņēmējs ir saņēmis tieši to summu, kuru viņam nosūtīja? Pieņemsim, sūtītājs pārskaitīja $100, bet saņēmējs saņēma $10. Sūtītājs dodas uz AnonymousWorldMoney biroju ar savu kvīti, bet klients rāda savu versiju, kur ir ierakstīts, ka sūtītājs ir pārsūtījis tikai $10.
- Problēma ir nedrošā vidē, piemēram, krāpniecība, ko sauc par double-spending. Negodīgs dalībnieks var iztērēt savu bilanci vairākkārt, kamēr maksājums netiek replicēts uz visiem serveriem. , protams, neviens nav atcēlis, un saskaņotība beigās tiks panākta, bet kāds neiegūs naudu par sniegtajiem pakalpojumiem vai precēm. Tāpēc, ja nav pilnīgas uzticības maksājumu organizācijai vai darījumu dalībniekiem, ir jāveido tīkls, kas balstās nevis uz uzticību, bet gan uz kriptogrāfiju.
- Nosacījuma AnonymousWorldMoney ir ierobežots skaits serveru, kas var kļūt nepieejami neapzināti vai ļaunprātīgi.
- AnonymousWorldMoney iekasēs savu taustāmo komisiju.
- Iespējas pārvaldīšana. Bitcoin lietošanas procesā tika atklāts, ka cilvēki vēlas ne tikai nosūtīt monētas cits citam, bet arī pārbaudīt dažādus darījumu izpildes nosacījumus, programmēt darbības scenārijus, automātiski veikt darbības atkarībā no nosacījumiem utt.
Kā blokķēde risina šīs problēmas
- Dalībnieku identifikācija notiek, izmantojot atslēgu pāri: privātā un publiskā, un digitālās paraksta algoritms nepārprotami identificē sūtītāju un saņēmēju, atstājot viņu identitātes anonīmas.
- Darījumi tiek apkopoti blokos, blokam tiek aprēķināts hash, kas tiek ierakstīts nākamajā blokā. Šāda hash ierakstu secība blokos deva nosaukumu tehnoloģijai blockchain, un tieši tā padara neiespējamu nemanāmu blokku vai atsevišķu darījumu no blokiem izmaiņas / dzēšanu. Tādējādi, ja darījums ir iekļauts blokķēdē, var būt droši, ka tā dati paliks nemainīgi.
- Double-spending krāpšana tiek novērsta, panākot konsensu tīklā par to, kādi dati tiek uzskatīti par pareiziem un kādi ir jāizmet. Bitcoin tīklā konsenss tiek sasniegts ar darba pierādījuma PoW (Proof-of-Work) palīdzību.
- Tīkla darbības drošība tiek nodrošināta ar to, ka blokķēde ir publiska, kur katrs dalībnieks var palaižot savu mezglu, iegūt pilnu blokķēdes kopiju un, turklāt, pats sākt pārbaudīt darījumus uz pareizību. Jāatzīmē, ka mūsdienu blokķēdes ļauj veidot ne tikai publiskas (atvērtas), bet arī privātas (slēgtas) blokķēdes, kā arī izmantot kombinētas shēmas.
- Pilnībā atbrīvoties no komisijas blokķēdē nav iespējams, jo ir jāmaksā cilvēkiem, kas uztur tīklu, taču blokķēdē komisijas nepieciešamība tiek pierādīta tik pārliecinoši, ka nepaliek šaubu par tās nepieciešamību.
- Mūsdienu blokķēdes spēj īstenot biznesa loģiku, kas blokķēdē tiek saukta par Viedajiem Līgumiem. Viedo līgumu loģika tiek īstenota dažādās augstā līmeņa valodās.
Tālāk aplūkosim šos risinājumus sīkāk.
Blokķēdes arhitektūra
Blokķēdes sastāvdaļas
Katrs dalībnieks var palaist savu mezglu ar pilnu blokķēdes kopiju (full node). Pilnie mezgli, kas var ierakstīt transakcijas blokķēdē, tiek dēvēti par saskaņas mezgliem (witness) vai ieguvējiem (miner). Pilnie mezgli, kas tikai pārbauda transakciju pareizību, tiek saukti par audita mezgliem (audit). Gaisīgajiem klientiem (light clients) nav pilnu blokķēdes kopiju, bet tie mijiedarbojas ar tīklu, izmantojot pilnus mezglus.
Lielākā daļa lietotāju, veicot transakcijas, izmanto tieši gaisīgos klientus vai web makus. Visi mezgli ir savienoti savā starpā. Šādā elementu komplektā tīkla arhitektūra kļūst izturīgāka:
Transakcijas dzīves cikls
Apskatīsim transakcijas dzīves ciklu un sadalīsim to pa daļām:
Blokķēdes tehnoloģijas
Iedziļināsimies tehniskajās risinājumos un to savstarpējās attiecībās.
Identifikācija
Katram blokķēdes transakcijai jābūt parakstītai ar digitālo parakstu. Tāpēc katram dalībniekam, lai veiktu transakciju, jābūt atslēgu pārim: private / public. Dažreiz atslēgu pāri sauc par maku (wallet), jo atslēgas ir tieši saistītas ar unikālu digitālo adresi un dalībnieka bilanci. Patiesībā atslēgas un adreses ir vienkārši ciparu virknes dažādās skaitļu sistēmās. Atslēgu un maka adreses piemēri:
Privātā atslēga: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Publiskā atslēga: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Adrese: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27VLai izveidotu digitālo parakstu blokķēdēs, tiek izmantots algoritms, kas balstās uz eliptiskām līknēm: Elliptic Curve Digital Signature Algorithm (ECDSA). Tā darbībai privātā atslēga (256 bitu skaitlis) parasti tiek ņemta izlases veidā. Iespēju kombināciju skaits ir 2 pakāpē 256, tāpēc var teikt, ka praktiski nav iespējams, ka privāto atslēgu vērtības sakristu.
Tālāk publiskā atslēga tiek iegūta no privātās, reizējot tās vērtību ar punktu koordinātēm, kas atrodas uz eliptiskās līknes, tādējādi iegūstot jaunās punkta koordinātas uz tās pašas līknes. Šī darbība garantē atslēgu pāra saņemšanu, kas ir derīgas transakciju digitālajiem parakstiem. Un visbeidzot, maka adrese tiek precīzi aprēķināta no publiskās atslēgas.
Ir daudz rakstu par kriptogrāfiju, kas tiek izmantota blokķēdē, piemēram:
Privātais taustiņš jāuzglabā stingri noslēpumā un droši. Publiskais taustiņš ir zināms visiem. Izdodot privāto taustiņu, piekļuve aktīvam (monētām) nav atjaunojama, un nauda tiks zaudēta uz visiem laikiem. Tāpēc droša privāto taustiņu glabāšana ir ārkārtīgi svarīga, jo tas nav bankas konts, uz kuru vienmēr var doties ar pasi un atjaunot kontu. Ir vesela industrija, kas ražo tā sauktos aukstos kriptovalūtu makus, kas izskatās līdzīgi USB atmiņām:
vai var izmantot drošākus veidus, piemēram, iegravēt privātā taustiņa vērtību uz žetoniem:
Transakcijas
Sīkāk par transakciju struktūru var skatīt rakstā . Mums ir būtiski saprast, ka katrai transakcijai ir vismaz šādi dati:
No: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - sūtītāja digitālā adrese
Uz: 0x367adb7894334678b90аfe7882a5b06f7fbc783a - saņēmēja digitālā adrese
Vērtība: 0.0001 - transakcijas summa
Transakcijas hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - transakcijas hashTālāk transakcija tiek parakstīta ar privāto taustiņu un izsūtīta (sk. detalizēto informāciju par protokola darbību ) visiem mezgliem blokķēdē, kas pārbauda transakciju derīgumu. Transakciju pārbaudes algoritms nav vienkāršs un ietver .
Transakciju bloki
Pārbaudot transakciju derīgumu, mezgli veido blokus no tām. Papildus transakcijām blokā tiek ierakstīts iepriekšējā bloka hash, skaitlis (Nonce skaitītājs), un tiek aprēķināts pašreizējā bloka hash, izmantojot SHA-256 algoritmu. Hasham jāatbilst noteiktajiem sarežģītības nosacījumiem. Piemēram, Bitcoin tīklā hash sarežģītība automātiski mainās reizi divās nedēļās, atkarībā no tīkla jaudas, tā, lai bloks tiktu ģenerēts aptuveni reizi 10 minūtēs. Sarežģītība noteikta pēc šī nosacījuma: atrastajam hash jābūt mazākam par iepriekš noteiktu skaitli. Ja šis nosacījums nav izpildīts, tad Nonce tiek palielināts par 1, un hash aprēķināšana tiek atkārtota. Lai atrastu hash, tiek izmantots Nonce lauks, jo tas ir vienīgais dati blokā, ko var mainīt, visi pārējie jāatstāj nemainīgi. Pareizajam hash jābūt ar noteiktu skaitu nullēm sākumā, piemēram, viens no reālajiem hashiem:
000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91Veiksmīgs hash atrašana ir pierādījums paveiktajam darbam (Proof-of-Work, PoW) Bitcoin un Ethereum tīkliem. Hashu atrašanas process tiek dēvēts par ieguvi (mining), līdzīgi kā zelta ieguve. Nosaukums diezgan precīzi nosaka procesa būtību, jo tiek veikta vienkārša variantu pārbaude, un, ja kāds ir atradis piemērotu hash, tas patiešām ir veiksme. Tas ir kā atrast īstu zelta īpatni tonnās nelaidīgas akmens. Atlīdzība par bloku šobrīd sastāda 12.5 BTC, un, ja to reizina ar pašreizējo bitcoin kursu $3900, tas pārveidojas par vairāk nekā kilogramu tīra zelta. Ir par ko cīnīties!
Pēc veiksmīgas hash atrašanas bloks un pats atrastais hash tiek ierakstīts blokķēdē kā nākamais bloks. Vairāk par bloku struktūru varat apskatīt rakstā , un zemāk ir sniegta vienkāršota shēma:
Blokķēde sākas ar bloku, kuram vēl nav iepriekšējā bloka hash. Šāds bloks blokķēdē ir viens un tam ir īpašs nosaukums - Genesis block. Pārējiem blokiem ir vienāda struktūra, un tie atšķiras tikai ar transakciju skaitu. Reālās transakcijas un blokos, kas veidojas pašlaik Bitcoin vai Ethereum, var apskatīt .
Bitcoin bloku izmērs ir ierobežots līdz 1 MB, un ar minimālo informācijas apjomu transakcijā, kas ir aptuveni 200 baiti, maksimāli blokā var būt apmēram 6000 transakciju. Tieši no tā arī izriet Bitcoin veiktspēja, par kuru visi smejas: bloks tiek ģenerēts aptuveni reizi 10 minūtēs * 60 sek = 600 sek, kas dod formālu veiktspēju aptuveni 10 TPS. Lai gan patiesībā – tas nav veiktspēja, bet apzināti realizēts darba algoritms. Ethereum konkurencei vienkārši samazināja bloka ģenerācijas laiku līdz 15 sekundēm, un veiktspēja formāli pieauga. Tāpēc PoW izmantojošo blokķēžu veiktspēju ir pilnīgi bezjēdzīgi salīdzināt, jo tā tieši atkarīga no keša aprēķināšanas grūtībām, kuras var noteikt jebkādas.
Forki
Un, ko darīt, ja, piemēram, vairāki mezgli ir atraduši hešus, kas atbilst sarežģītības nosacījumiem, bet ir atšķirīgi pēc vērtības (citiem vārdiem sakot, ir nonākuši pie atšķirīgiem konsensusiem) un ierakstījuši blokos blockchain? Apskatīsim, kā blockchain aizsargājas pret šo situāciju. Šajā gadījumā notiek tā sauktais forks (‘dakša’), un blockchain ir divas ķēdes versijas:
Kas notiek tālāk? Tālāk daļa tīkla sāk strādāt pie bloka N+2 no vienas ķēdes, bet daļa no otras:
Kāds no šiem blokiem tiks atrasts ātrāk un nosūtīts uz blockchain, un tad pēc noteikumiem blockchain vajadzēs pārslēgties uz garāko ķēdi un atcelt visas transakcijas no alternatīvā bloka:
Šajā gadījumā var rasties situācija, kad dalībnieka transakcija bija tikai vienā no forka blokiem, kas tika atcelts. Tādēļ, lai pārliecinātos, ka nepieciešamā transakcija ir ierakstīta blockchain, ir vispārēja rekomendācija — pirms uzticība transakcijai jāpagaida, līdz nākamie vairāki bloki tiek pievienoti blockchain. Ieteikumi par to, cik blokus gaidīt dažādiem blockchain ir atšķirīgi. Piemēram, Bitcoin tīklā minimums ir 2 bloki, maksimums 6.
Līdzīga aina ar forku blokiem būs novērojama arī tā sauktajā 51% uzbrukumā — tas ir tad, kad grupas ieguvēji cenšas izveidot alternatīvu bloku ķēdi, centšoties atcelt ķēdi ar savām krāpnieciskajām transakcijām. Lai gan pašlaik, vietā krāpniecības, ir izdevīgāk tērēt savus resursus godīgam ieguvumam.
Konsensus
Lai ierakstītu bloku blockchain, tīklam jānonāk pie konsensusa. Atcerēsimies uzdevumu, kas saistīts ar konsensusa sasniegšanu datoru sakaru tīklos. Problēma formulēta kā bizantiešu ģenerāļu BFT (). Atmetot glezniecisko aprakstu par bizantiešu armijas problēmām, uzdevumu var formulēt šādi: kā tīkla mezgli var nonākt pie kopīga rezultāta, ja daļa no tīkla mezgliem var apzināti tos sagrozīt. Esošie BFT uzdevumu risinājumu algoritmi parāda, ka tīkls var darboties pareizi, ja krāpnieku ir mazāk par 1/3. Kāpēc Bitcoin tīklā netika izmantots BFT konsensus? Kāpēc bija nepieciešams izmantot PoW? Ir vairāki iemesli:
- BFT labi darbojas ar nelielu fiksētu mezglu komplektu, bet publiskajā blokķēdē mezglu skaits ir neparedzams un, turklāt, mezgli var brīvi ieslēgties un izslēgties.
- Ir nepieciešams motivēt cilvēkus palaist blokķēdes mezglus. Tam cilvēkiem jāsaņem atlīdzība. BFT gadījumā formāli nav par ko saņemt atlīdzību, bet par ko tiek piešķirta atlīdzība PoW visiem ir skaidrs intuitīvi: par elektroenerģiju, ko patērē procesors, šķērsojot bloka hash.
Papildus PoW ir vairāki konsensusi, kas tiek izmantoti mūsdienu blokķēdēs, piemēram:
- PoS (Proof-of-Stake) – blokķēdē
- DPoS (Delegated Proof-of-Stake) – blokķēdē
- BFT modifikācijas: SBFT (Simplified BFT) un PBFT (Practical BFT), piemēram, blokķēdē
Paceļam nedaudz jautājumu par PoS konsensu, jo tieši PoS un tā varianti ir guvuši vislielāko izplatību privātajās blokķēdēs. Kāpēc tieši privātajās? No vienas puses, PoS īpašības ir labākas salīdzinājumā ar PoW, jo konsensa sasniegšanai ir nepieciešami mazāki skaitļošanas resursi, līdz ar to palielinās datu rakstīšanas ātrums blokķēdē. Bet, no otras puses, PoS ir lielākas iespējas krāpniecībai, tādēļ, lai to neitralizētu, visiem blokķēdes dalībniekiem jābūt zināmiem.
PoS konsenss balstās uz mezgla izvēli, kurš var ierakstīt bloku ar darījumiem blokķēdē atkarībā no līdzekļu skaita kontā, precīzāk, nevis kontā, bet nodrošinājumā. T.i., jo vairāk līdzekļu tev ir nodrošinājumā, jo lielākas iespējas tīkls izvēlēs tieši tavu mezglu bloka rakstīšanai. Nodrošinājums netiks atgriezts, ja bloks izrādīsies nederīgs. Tādējādi tiek ieviesta aizsardzība pret krāpniecību. Ir šādas PoS variācijas:
- Delegated PoS (DPoS) konsenss dalībniekus sadala «balsojošajos» un «validējošajos». Monētu turētāji (balsojošie dalībnieki) deleģē savu tiesību pārbaudīt un ierakstīt darījumus blokķēdē citiem dalībniekiem. Tādējādi validatori veic visu skaitļošanas darbu un saņem par to atlīdzību, bet balsojošo dalībnieku klātbūtne garantē validatoru godīgumu, jo tos var nomainīt jebkurā brīdī.
- LPoS (Leased Proof-of-Stake) konsenss ļauj nodot savus līdzekļus īres citām mezglām, lai tiem būtu lielākas iespējas pārbaudīt blokus. Tādējādi iespējams saņemt komisiju par darījumiem, tajā pašā laikā nepiedaloties pašu darījumu pārbaudē un blokķēdes ieguvē.
Pastāv vēl vairāki konsensusi, kuri vēl nav guvuši plašu izplatību, šeit vienkārši uzskaitīšu informācijai, bet pašu konsensusa algoritmu pārskatu var aplūkot, piemēram, rakstā: .
- 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)
Uzticamība un blokķēžu izvietošanas modeļi
Publiskais blokķēde
Noturība Public vai cits nosaukums Atļautajai blokķēdei tiek panākta ar to, ka ikviens var pieslēgties un apskatīt informāciju vai pat pieslēgt savu mezglu, un uzticība tiek balstīta uz PoW konsensusu.
Privāts blokķēde
Privāts vai Privāta atļauta blokķēde. Šādās blokķēdēs piekļuve informācijai ir tikai noteiktai dalībnieku grupai (organizācijām vai cilvēkiem). Šādas blokķēdes veido organizācijas, lai palielinātu kopējo labumu vai efektivitāti. To uzticamību nodrošina kopējie dalībnieku mērķi un PoS un BFT konsensusa algoritmi.
Blokķēdes konsorcijs
Pastāv Konsorcijs vai Publiskā atļautā blokķēde. Tās ir blokķēdes, kurām ikviens var piekļūt informācijas apskatei, bet pievienot informāciju vai savienot savu mezglu dalībnieks var tikai ar citu dalībnieku atļauju. Šādas blokķēdes veido organizācijas, lai palielinātu uzticību no pasūtītājiem vai patērētājiem vai sabiedrības kopumā. Šeit uzticamību arī nodrošina klātbūtne un uzticība starp dalībniekiem, kā arī tie paši PoS un BFT konsensusa algoritmi.
Viedie līgumi
Blokķēdēs, kas izveidotas pēc Bitcoin, ir iekļauta iespēja izpildīt viedos līgumus. Patiesībā vieds līgums ir darījums, kurā ir iekļauts programmēšanas kods izpildei. Viedie līgumi Ethereum tīklā tiek izpildīti EVM (Ethereum Virtual Machine). Lai sāktu viedā līguma izpildi, to jāpalaiž ar citu darījumu, vai arī ir jāizpildās priekšnoteikumiem. Viedā līguma izpildes rezultāti arī tiks ierakstīti blokķēdē. Datu iegūšana no ārpuses ir iespējama, bet ļoti ierobežota.
Kādu biznesa loģiku var īstenot, izmantojot viedos līgumus? Patiesībā tas nav tik daudz, piemēram, nosacījumu pārbaude, balstoties uz datiem no blokķēdes, digitālo aktīvu īpašnieku maiņa atbilstoši šiem nosacījumiem, datu ierakstīšana pastāvīgajā krātuvē iekš blokķēdes. Loģika tiek īstenota, izmantojot speciālu augsta līmeņa valodu Solidity.
Klasisks piemērs funkcionalitātei, ko īsteno, izmantojot viedos līgumus, ir tokenu izdošana ICO rīkošanai. Piemēram, esmu īstenojis viedo līgumu, lai izdotu pieticīgu 500 000 000 AlexToken. Saskaņā ar atrodas
viedo līgumu avota kods valodā Solidity
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;
}un binārais attēlojums, kā to redz tīkls
60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029Vairāk informācijas par viedajiem līgumiem varat uzzināt rakstā: .
Secinājums
Mēs esam uzskaitījuši tehnoloģijas, uz kurām balstās mūsdienu blokķēdes, un kā tās ir savstarpēji saistītas. Tagad formulēsim, kādas problēmas var risināt ar blokķēdi, un kuru risinājumi vislabākajā gadījumā būs neefektīvi. Tātad, blokķēdes izmantošana nav obligāta, ja:
- Transakcijas notiek uzticības vidē;
- Starppersonu komisijas nepasliktina dalībnieku dzīvi;
- Dalībniekiem nav īpašuma, ko varētu attēlot kā digitālos aktīvus;
- Nav digitalizētu aktīvu sadalījuma, t.i., vērtību pieder vai piegādā tikai viens dalībnieks.
Kā nākotne izskatīsies blokķēdēm? Pašlaik varam tikai pieļaut iespējamās blokķēdes tehnoloģiju attīstības virzienus:
- Blokķēde kļūs par tikpat ierastu datu bāzu tehnoloģiju kā, piemēram, SQL vai NoSQL, lai risinātu konkrētu uzdevumu loku;
- Blokķēde kļūs plaši izplatīts protokols, kā HTTP Internetam;
- Blokķēde kļūs par jaunas finanšu un politiskās sistēmas pamatu uz planētas!
Nākamajā daļā mēs apskatīsim, kādi blokķēdes šobrīd pastāv un kādā veidā tās tiek izmantotas dažādās nozarēs.
Tas ir tikai sākums!
Avots: habr.com
