🥇Miért ne építhetnénk blokkláncot?

Az emberiség története folyamatosan a láncoktól való megszabadulás és új, még erősebb láncok létrehozása. (A névtelen szerző)

A számos blockchain projekt (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin stb.) elemzése közben értem, hogy technikai szempontból mindegyik azonos elvek szerint épül fel. A blokkláncok olyanok, mint a házak, amelyek szerkezetileg, dekorációjukban és funkcióikban változatosak, mégis van alap, falak, tető, ablakok és ajtók, amelyek bizonyos módon kapcsolódnak egymáshoz. Ha megértjük az épületek tervezésének alapelveit és ismerjük az alkalmazott anyagok tulajdonságait, akkor meghatározhatjuk egy adott ház célját. Jelenleg a blokklánc körüli helyzet az, hogy mindenki hallott róla, de kevesen értik az architektúráját és működési elveit. Ezért félreértések merülnek fel arról, hogy miért és hogyan van értelme a blokklánc technológiák használatának.

Ebben a cikkben megvizsgáljuk a blokkláncok számára közös tulajdonságokat és elveket. Ezt követően megnézzük a blokklánc segítségével megoldható feladatokat, és az anyag megerősítése érdekében felépítünk egy kis, de valódi blokkláncot a virtuális telkünkön!

Tehát, emlékezzünk vissza, hogy milyen problémákat oldott meg eredetileg a blokklánc.

Biztos vagyok benne, hogy sokan mondanák, hogy egy elosztott, decentralizált, nyilvános és megváltoztathatatlan adatbázis. De mire volt szükség mindezért?

Én általában a bármilyen technológia tanulmányozását a szabványok olvasásával kezdem, mivel ezek képezik az alapját az összes cikknek és könyvnek a vizsgált témában. De a blokkláncra vonatkozó szabványok jelenleg hiányoznak, az ISO-ban csak bizottságokat hoztak létre a kidolgozásukra. Jelenleg minden nyilvános blokklánc projekt rendelkezik saját White Paper dokumentumával, amely lényegében egy műszaki feladat. Az első közismert blokklánc projekt a Bitcoin hálózat. Lépjünk be a hálózat hivatalos weboldalára és nézzük meg honnan indult minden.

A blokklánc feladata

Tehát a feladat, amelyet a blokklánc megoldott a Bitcoin úttörő hálózatában — az digitális eszközök (assets) megbízható átruházásának lebonyolítása bizalmatlan környezetben közvetítők nélkül. Például a Bitcoin hálózatban a digitális eszköz a bitcoin digitális érme. A Bitcoin és más blokkláncok technikai megoldásai ennek a feladatnak a megoldására összpontosulnak.

A blokklánc által megoldott problémák

Tegyük fel, hogy egy pénzügyi szervezet azt állítja, hogy világszerte kiépített egy hálózatot, amellyel pénzt küldhetünk bárkinek. Képzeld el, hogy egy ilyen szervezet a Visa vagy a MasterCard, valószínűleg elhiszed. De ha például az AnonymousWorldMoney, lehet, hogy nem. Miért? Mert pontosan tudjuk, hogyan működnek a decentralizált rendszerek magáncégeknél, milyen célok vezérlik őket, és hová vezethet ez. Nézzük meg közelebbről ezeknek a rendszereknek a problémáit, és hogyan lehet ezeket megoldani a blokklánc technológia alkalmazásával.

Tegyük fel, hogy az AnonymousWorldMoney-nál szerverek találhatók adatbázisokkal, és jó, ha ezekből több is van különböző adatközpontokban. Amikor a küldő pénzt utal, akkor regisztrálódik egy tranzakció, amely minden szerveren replikálódik, és a pénz eljut a címzetthez.

Ideális világban ez a rendszer tökéletesen működik, de a miénkben a következő problémák merülnek fel:

A résztvevők azonosításának problémája az egyik oldalon, és a tranzakciók anonimitásának szükségessége a másikon. Vagyis pénzt kell átutalni egy konkrét címzettnek, úgy, hogy erről a tranzakcióról senki ne tudjon, csak a résztvevők. A bankok rendelkeznek számlaszámokkal és bankkártyákkal, amelyek konkrét fizikai vagy jogi személyhez kötődnek, míg a banktitok védi a tranzakciók információját. De ki garantálja, hogy az AnonymousWorldMoney nem használja fel a személyes adatokat és a tranzakciókról szóló információkat saját céljaira?
Hogyan lehet biztosítani, hogy a címzett pontosan azt az összeget kapja meg, amit utaltak? Például a küldő átutal $100-t, de a címzett csak $10-t kap. A küldő bemegy az AnonymousWorldMoney irodájába a nyugtatával, de az ügyintéző megmutatja a saját verzióját, amelyen az áll, hogy a küldő csak $10-t utalt.
A bizalmatlan környezet problémája, például a double-spending jelensége. Egy tisztességtelen résztvevő többször is elköltheti a maradványait, amíg a tranzakció nem replikálódik az összes szerveren. A CAP-tételt, persze, senki sem vonja vissza, és a konzisztencia végülre elérhető lesz, de valaki nem kapja meg a pénzt a nyújtott szolgáltatásokért vagy árukért. Ezért, ha nincs teljes bizalom a fizetési szervezet vagy a tranzakciók résztvevői iránt, olyan hálózatot kell építeni, amely nem a bizalomra, hanem a kriptográfiára épít.
Az AnonymousWorldMoney feltételezett rendszerének véges számú szervere van, amelyek véletlenül vagy rossz szándékkal elérhetetlenné válhatnak.
Az AnonymousWorldMoney érezhető jutalékot fog szedni.
A kezelés lehetősége. A Bitcoin használata során kiderült, hogy az emberek nemcsak arra vágynak, hogy érméket utaljanak egymásnak, hanem különféle tranzakciós feltételek ellenőrzésére, működési forgatókönyvek programozására, automatikus tevékenységek végrehajtására az előírások alapján stb.

Hogyan oldja meg a blokklánc ezeket a problémákat

A résztvevők azonosítása egy privát és egy nyilvános kulcs párjával történik, a digitális aláírás algoritmus pedig egyértelműen azonosítja a feladót és a címzettet, megőrizve anonimitásukat.
A tranzakciók blokkokba gyűjtődnek, kiszámítják a blokk hashét, amely a következő blokkba kerül. Az ilyen hash-ek blokkokba írásának folyamata adta a blokklánc technológia nevét, és ez akadályozza meg a blokkok vagy egyes tranzakciók észrevétlen megváltoztatását/törlését. Így, ha egy tranzakció bekerült a blokkláncba, biztosak lehetünk abban, hogy annak adatai változatlanok maradnak.
A double-spending csalás megakadályozása a hálózat konszenzusának elérésével történik, hogy mely adatokat tekintünk helyesnek és melyeket utasítunk el. A Bitcoin hálózatban a konszenzus elérése a PoW (Proof-of-Work) teljesítménye által történik.
A hálózat működésének megbízhatóságát az biztosítja, hogy a blokklánc nyilvános, ahol minden résztvevő elindíthatja a saját nodját, megkaphatja a blokklánc teljes másolatát, és ami fontosabb, önállóan ellenőrizheti a tranzakciók helyességét. Meg kell említeni, hogy a modern blokkláncok lehetőséget adnak nemcsak nyilvános (nyitott), hanem privát (zárt) blokkláncok létrehozására is, valamint kombinált rendszerek használatára.
A blokkláncon a díjak teljes mértékben nem szüntethetők meg, mivel fizetni kell a hálózatot fenntartó embereknek, de a blokkláncban a jutalék szükségessége annyira meggyőzően bizonyítható, hogy nincs kétség a fontosságában.
A modern blokkláncok képesek üzleti logikát megvalósítani, amelyet a blokkláncban Smart Contracts -nak neveznek. A smart contractok logikáját különböző magas szintű nyelveken valósítják meg.

Most részletesebben megvizsgáljuk ezeket a megoldásokat.

A blokklánc architektúrája

A blokklánc összetevői

Minden résztvevő indíthat egy saját nodot a blokklánc teljes másolatával (full node). Azokat a teljes node-okat, amelyek tranzakciókat tudnak rögzíteni a blokkláncon, konszenzus node-oknak (witness) vagy bányászoknak (miner) nevezik. Azokat a teljes node-okat, amelyek csak a tranzakciók helyességét ellenőrzik, audit node-oknak (audit). Könnyű kliensek (light clients) nem tárolnak teljes másolatokat a blokkláncról, hanem a hálózattal lépnek kapcsolatba a teljes node-okat használva.
A legtöbb felhasználó tranzakciók végrehajtásához éppen ezért könnyű klienseket vagy web pénztárcákat használ. Minden node összekapcsolódik egymással. Ezzel a felépítéssel a hálózat architektúrája ellenállóbbá válik:

A tranzakció életciklusa

Nézzük meg a tranzakció életciklusát, és bontsuk le részekre:

A blokklánc technológiák

Térjünk ki részletesebben a technikai megoldásokra és azok kapcsolataira.

Azonosítás

Minden blokklánc tranzakciónak digitális aláírással kell rendelkeznie. Ezért a tranzakció végrehajtásához minden résztvevőnek rendelkeznie kell egy kulcspárral: privát / nyilvános. Néha a kulcspárt pénztárcának (wallet) nevezik, mert a kulcsok egyértelműen kapcsolódnak egy egyedi digitális címhez és a résztvevő egyenlegéhez. A valóságban a kulcsok és címek csak számokból álló karakterláncok különböző számrendszerekben. Példák kulcsokra és a pénztárca címére:

Privát kulcs: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Nyilvános kulcs: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Cím: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

Digitális aláírás létrehozásához a blokkláncokban ellipszis görbén alapuló algoritmust használnak: Elliptic Curve Digital Signature Algorithm (ECDSA). A működéséhez a privát kulcs (256 bites szám) általában véletlenszerűen kerül kiválasztásra. A kulcsvariációk száma 2 a 256. hatványon, így gyakorlatilag lehetetlen, hogy privát kulcsok értékei egybeessenek.

A nyilvános kulcs a privát kulcs értékének multiplikációja nyerhető ki az ellipszis görbe egy pontjának koordinátáival, így egy új pont koordinátáit kapjuk meg ugyanazon a görbén. Ez a lépés garantálja egy kulcspár megszerzését, amely alkalmas a tranzakciók digitális aláírására. Végül pedig a pénztárca címe egyértelműen kiszámítható a nyilvános kulcsból.

Sok cikk található a blokkláncban használt kriptográfiáról, például: Bitcoin dióhéjban — Kriptográfia

A privát kulcsnak szigorúan titkosnak kell lennie, és biztonságban kell tárolni. A nyilvános kulcs mindenki számára ismert. Ha a privát kulcsot elveszítik, a hozzáférést az eszközhöz (érmékhez) lehetetlen visszaállítani, és a pénz véglegesen elveszik. Ezért a privát kulcsok megbízható tárolásának feladata rendkívül fontos, mivel ez nem egy bank, ahová mindig el lehet menni személyazonosság igazolásával, és helyreállítani a számlát. Létrejött egy egész iparág a úgynevezett hideg kriptotárcák gyártására, amelyek flash meghajtókra hasonlítanak:

vagy megbízhatóbb módszereket is használhatunk, például a privát kulcs értékének szilárd anyagon való megverését:

Tranzakciók

A tranzakciós struktúrával kapcsolatos további részletek a cikkben találhatók A Bitcoin lényege — Tranzakció. Fontos megértenünk, hogy minden tranzakciónak legalább a következő adatai vannak:

From: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - a küldő digitális címe
To: 0x367adb7894334678b90aFe7882a5b06f7fbc783a - a fogadó digitális címe
Value: 0.0001 - a tranzakció összege
Transaction Hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - a tranzakció hash-e

Ezután a tranzakciót a privát kulccsal aláírják, és eljuttatják (lásd a protokoll működésének részleteit A Bitcoin lényege - Protokoll) minden csomópontnak a blokkláncon, amelyek ellenőrzik a tranzakciók érvényességét. A tranzakciók ellenőrzési algoritmusa nem triviális, és magában foglalja húsz lépést.

A tranzakciók blokkjai

A tranzakciók érvényességének ellenőrzése után a csomópontok blokkokká formálják őket. A tranzakciók mellett a blokkba bejegyzik az előző blokk hashét, egy számot (nonce számláló), és a jelenlegi blokk hashét a SHA-256 algoritmus szerint számítják ki. A hashnek ki kell elégítenie a nehézségi feltételeknek. Például a Bitcoin hálózatában a hash nehézsége automatikusan változik kéthetenként, a hálózat teljesítményétől függően, úgy, hogy a blokk körülbelül 10 percenként generálódjon. A nehézséget a következő feltétel határozza meg: a talált hashnak kisebbnek kell lennie, mint egy előre meghatározott szám. Ha ez a feltétel nem teljesül, akkor a Nonce-hoz 1-et adnak, és a hash kiszámításához szükséges munka megismétlődik. A hash megtalálásához a Nonce mezőt használják, mivel ezek az egyetlen megváltoztatható adatok a blokkban, míg a többi adatnak változatlanul kell maradnia. A helyes hashnak meghatározott számú nullával kell kezdődnie, például az egyik valós hash:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

A hash found successfully serves as proof of work (Proof-of-Work, PoW) for Bitcoin or Ethereum networks. The process of finding hashes is called mining, likened to gold mining. The name accurately reflects the essence of the process, as it involves a simple trial-and-error approach, and if someone finds a suitable hash, it is indeed a stroke of luck. It's like finding a real gold nugget in tons of barren rock. The reward for a block is currently 12.5 BTC, and if multiplied by the current Bitcoin rate of $3900, it amounts to over a kilogram of pure gold. There's something to fight for!

After successfully finding the hash, the block and the hash itself are recorded in the blockchain as the next block. For more details on the structure of blocks, you can refer to the article Bitcoin in a nutshell - Blockchain, and below I provide a simplified diagram:

The blockchain starts with a block that does not yet have the hash of the previous block. This block in the blockchain is unique and is called the Genesis block. The other blocks have the same structure and differ only in the number of transactions. You can view actual transactions and blocks currently being created in Bitcoin or Ethereum at Block Explorer.

The size of blocks in Bitcoin is limited to 1MB and with a minimum transaction size of about 200 bytes, a block can contain around 6000 transactions at most. This, by the way, explains the performance of Bitcoin, which everyone laughs at: a block is generated approximately every 10 minutes * 60 seconds = 600 seconds, which provides a formal performance of about 10 TPS. However, in reality, this is not performance, but a deliberately implemented working algorithm. To compete, Ethereum simply reduced the block generation time to 15 seconds, and performance formally soared. Therefore, in blockchains using PoW as consensus, it makes no sense to compare performance at all, as it directly depends on the complexity of computing the cache, which can be set to any level.

Forks

Mi történik, ha például több csomópont talál olyan hashokat, amelyek megfelelnek a nehézségi feltételeknek, de értékük eltérő (más szóval, különböző konszenzusra jutnak), és blokkokat írnak a blokkláncra? Nézzük meg, hogyan védi meg a blokklánc magát ebben a helyzetben. Ilyenkor úgynevezett fork ('villa') történik, és a blokkláncnak két verziója lesz a láncnak:

Mi történik ezután? Ezután a hálózat egy része az egyik lánc N+2 blokkján kezd dolgozni, míg a másik része a másikon:

Ezek közül valamelyik blokk korábban megtalálható és elküldhető a blokkláncra, és ekkor a szabályok szerint a blokkláncnak át kell váltania a hosszabb láncra, és törölnie kell az alternatív blokk tranzakcióit:

Előfordulhat, hogy egy résztvevő tranzakciója csak az egyik fork blokkban volt, amelyet töröltek. Ezért, hogy biztosak legyünk abban, hogy a szükséges tranzakció rögzítve lett a blokkláncon, van egy általános ajánlás – mielőtt megbízunk egy tranzakcióban, várjunk, míg a következő néhány blokk hozzáadásra kerül a blokklánchoz. Az ajánlások, hogy hány blokkot érdemes várni a különböző blokkláncoknál, eltérőek. Például a Bitcoin hálózat számára a minimum 2 blokk, a maximum pedig 6.

Ugyanez a helyzet a blokkok forkjával lesz megfigyelhető a úgynevezett 51%-os támadás során is – amikor egy csoport bányász megpróbál alternatív blokklánccal létrehozni egy láncot, hogy törölje a láncot a csaló tranzakcióival. Bár jelenleg a csalás helyett ésszerűbb a teljesítményüket tisztességes bányászatra költeni.

Konszenzus

Ahhoz, hogy egy blokk a blokkláncra kerülhessen, a hálózatnak konszenzusra kell jutnia. Emlékezzünk vissza a konszenzus elérése a számítógépes kommunikációs hálózatokban. A probléma úgy fogalmazható meg, mint a bizánci tábornokok BFT (Byzantine fault tolerance). A bizánci hadsereg problémáinak festői leírását mellőzve a feladat úgy fogalmazható meg: hogyan érhetnek el a hálózat csomópontjai közös eredményt, ha a hálózat egyes csomópontjai szándékosan torzítják azokat. A meglévő BFT problémamegoldó algoritmusok azt mutatják, hogy a hálózat helyesen működhet, ha a csalók kevesebb mint 1/3-át teszik ki. Miért nem alkalmazták a Bitcoin hálózatában a BFT konszenzust? Miért volt szükség a PoW használatára? Számos oka van:

A BFT jól működik egy kis rögzített csomópontkészlettel, de a nyilvános blokklánc esetében a csomópontok száma kiszámíthatatlan, sőt, a csomópontok véletlenszerűen be- és kikapcsolódhatnak.
Motiválni kell az embereket a blokklánc csomópontok indítására. Ehhez az embereknek jutalmat kell kapniuk. A BFT esetében formálisan nincs értelme a jutalomnak, míg a PoW esetében mindannyian intuitívan megértjük, hogy miért kapják a jutalmat: az elektromosságért, amelyet a processzor a blokk hash-nak megtalálása során használ.

A PoW mellett még több konszenzus létezik, amelyeket a modern blokkláncokban használnak, például:

PoS (Proof-of-Stake) — a blokkláncban Hyperledger
DPoS (Delegált Proof-of-Stake) — a blokkláncban BitShares
A BFT módosításai: SBFT (Egyszerűsített BFT) és PBFT (Gyakorlati BFT), például a blokkláncban Exonum

Kicsit álljunk meg a PoS konszenzusnál, mivel a PoS és annak változatai a legelterjedtebbek a privát blokkláncokban. Miért pont a privátok? Egyrészt a PoS jellemzői jobbak a PoW-hoz képest, mivel a konszenzus eléréséhez kevesebb számítási erőforrás szükséges, így növekszik az adatblokkok blokkláncba írásának sebessége. Másrészt azonban a PoS-ben több csalási lehetőség is van, ezért ennek semlegesítésére minden blokklánc résztvevőjének ismertnek kell lennie.

A PoS konszenzus azon alapul, hogy megválasszunk egy csomópontot, amely tranzakciós blokkokat írhat a blokkláncba a számlán levő források mennyisége alapján, pontosabban nem a számlán, hanem letétbe helyezve. Tehát minél több forrásod van letétbe helyezve, annál nagyobb valószínűséggel választja a hálózat a te csomópontodat a blokk írására. A letét nem térül vissza, ha a blokk érvénytelennek bizonyul. Ily módon valósul meg a csalás elleni védelem. A PoS következő variációi léteznek:

A Delegált PoS (DPoS) konszenzus a résztvevőket «szavazókra» és «érvényesítőkre» osztja. A coin-tulajdonosok (szavazó résztvevők) delegálják a jogukat, hogy tranzakciókat ellenőrizzenek és írjanak a blokkláncba más résztvevőknek. Ily módon az érvényesítők végzik el az összes számítási munkát, és ezért jutalmat kapnak, míg a szavazó résztvevők jelenléte biztosítja az érvényesítők tisztességét, mivel bármikor leválthatók.
A LPoS (Leased Proof-of-Stake) konszenzus lehetővé teszi, hogy pénzeszközeinket más csomópontok bérbe adjuk, hogy azok nagyobb eséllyel ellenőrizhessék a blokkokat. Így tranzakciós díjat kaphatunk anélkül, hogy magában a tranzakciók ellenőrzésében vagy a blokkok bányászásában részt vennénk.

Számos más konszenzus létezik, amelyek még nem terjedtek el széles körben, itt csak felsorolom tájékoztatásul, a konszenzus algoritmusok áttekintését pedig például a következő cikkben találhatja: Konszenzus Algoritmusok a Blokkláncon.

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)

A blokkláncok megbízhatósága és telepítési modellek

Nyilvános blokklánc

Stabilitás Public vagy más néven Engedélyezés nélküli blokklánc elérhető azzal, hogy bárki csatlakozhat és megtekintheti az információt, vagy akár csatlakoztathatja a saját csomópontját, a bizalom pedig a PoW konszenzusra épül.

Privát blokklánc

Private vagy Privát Engedélyezett blokklánc. Ezekben a blokkláncokban csak egy meghatározott résztvevői csoport (szervezetek vagy emberek) férhet hozzá az információkhoz. Az ilyen blokkláncokat szervezetek építik a közös haszon vagy hatékonyság növelése céljából. Megbízhatóságukat a résztvevők közös céljai és a PoS és BFT konszenzus algoritmusok biztosítják.

Blokklánc konzorcium

engedélyezett helyi hálózati tartományok. Consortium vagy Nyilvános Engedélyezett blokklánc. Ezek a blokkláncok nyilvánosan megtekinthetőek, de az információ hozzáadásához vagy saját csomópont csatlakoztatásához a résztvevőnek más résztvevők engedélyére van szüksége. Az ilyen blokkláncokat szervezetek építik a megrendelők vagy a termék fogyasztói, vagy a társadalom egészének bizalmának növelése érdekében. Itt a megbízhatóság a résztvevők közötti bizalom meglétével és a PoS és BFT konszenzus algoritmusokkal érhető el.

Okos szerződések

A Bitcoin után létrehozott blokkláncokba valamilyen mértékben integrálták az okos szerződések végrehajtásának lehetőségét. Az okos szerződés lényegében egy tranzakció, amely programozási kódot tartalmaz a végrehajtáshoz. Az Ethereum hálózatban az okos szerződéseket az EVM (Ethereum Virtual Machine) hajtja végre. Az okos szerződés végrehajtásához egy másik tranzakcióval szükséges kifejezetten elindítani, vagy meg kell valósulnia a végrehajtáshoz szükséges feltételeknek. Az okos szerződés végrehajtásának eredményei szintén bejegyzésre kerülnek a blokkláncba. Az adatokat a blokkláncból kívülről az információk rendkívül korlátozottan érhetők el.

Milyen üzleti logikát lehet megvalósítani okos szerződések segítségével? Valójában nem túl sokat, például feltételek ellenőrzése a blokklánc adatai alapján, digitális eszközök tulajdonosainak megváltoztatása ezeknek a feltételeknek megfelelően, adatok rögzítése a blokklánc állandó tárolójába. A logika egy speciális, magas szintű Solidity nyelven valósul meg.

A klasszikus példa a funkcionalitásra, amelyet okos szerződések segítségével valósítanak meg – tokenek kibocsátása ICO lebonyolításához. Például készítettem egy okos szerződést 500 000 000 AlexToken kibocsátására. link az Etherscan-en van

az okos szerződés forráskódja Solidity nyelven

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;
}

és a bináris reprezentáció, ahogyan a hálózat látja.

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

További részletek a smart szerződésekről az alábbi cikkben találhatóak: Mi az a smart szerződés az Ethereum-on?.

Zárás

Összegyűjtöttük a modern blokkláncok alapjául szolgáló technológiákat és azok kölcsönhatásait. Most nézzük meg, milyen problémákat lehet megoldani a blokklánc segítségével, és melyek azok, amelyek esetében az alkalmazásuk legfeljebb nem hatékony. Tehát a blokklánc használata nem szükséges, ha:

A tranzakciók bizalmi környezetben zajlanak;
A közvetítők díjai nem rontják az résztvevők életminőségét;
A résztvevőknek nincs olyan tulajdonuk, amit digitális eszközök formájában lehetne megjeleníteni;
Nincs decentralizáció a digitális eszközökben, tehát az értéket csak egy résztvevő birtokolja vagy biztosítja.

Milyen jövő vár a blokkláncra? Jelenleg csak feltételezni lehet a blokklánc technológiák lehetséges fejlődési irányait:

A blokklánc olyan elterjedtté válik, mint a SQL vagy a NoSQL adatbázistechnológia, a maga meghatározott feladatai megoldására;
A blokklánc széles körben elterjedt protokollá válik, mint az HTTP az internet számára;
A blokklánc lesz az alapja a bolygó új pénzügyi és politikai rendszerének!

A következő részben megnézzük, hogy jelenleg milyen blokkláncok léteznek és milyen iparágakban alkalmazzák őket.

Ez csak a kezdet!

Forrás: habr.com