🥇Hvad koster det os at bygge blockchain?

Hele menneskehedens historie er en kontinuerlig befrielse fra lænker og skabelse af nye, endnu stærkere. (Anonym forfatter)

Når jeg analyserer de mange blockchain-projekter (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin osv.), forstår jeg, at de teknisk set alle er bygget på de samme principper. Blockchains minder om huse, hvor der på trods af det store udvalg af konstruktioner, dekorationer og anvendelser altid er fundament, vægge, tag, vinduer og døre, der er forbundet med hinanden på bestemte måder. Og hvis man forstår de grundlæggende principper for bygningsdesign og kender materialernes egenskaber, kan man bestemme det specifikke formål for et bestemt hus. I øjeblikket er situationen med blockchain sådan, at alle har hørt om det, men få forstår arkitekturen og arbejdets principper. Derfor opstår der misforståelser omkring, hvad og hvordan det giver mening at bruge blockchain-teknologier.

I denne artikel vil vi se på de egenskaber og principper, der er fælles for alle blockchains. Derefter ser vi på de opgaver, som kan løses med blockchain, og for at forstærke materialet vil vi bygge en lille, men ægte blockchain på vores virtuelle grund!

Lad os så huske, hvilke problemer blockchain oprindeligt løste.

Jeg er sikker på, at mange vil nævne den distribuerede, decentrale, offentlige og uforanderlige database. Men hvorfor var det hele nødvendigt?

Jeg foretrækker at begynde at lære enhver teknologi ved at læse standarder, da alle artikler og bøger om det undersøgte emne er baseret på dem. Men der findes i øjeblikket ingen blockchain-standarder, kun udvalg for deres udvikling. I øjeblikket har hvert offentligt blockchain-projekt sit eget dokument kaldet White Paper, som i princippet fungerer som en teknisk specifikation. Det første kendte blockchain-projekt er Bitcoin-netværket. Lad os gå til Bitcoin-netværkets officielle hjemmeside og se hvordan det hele begyndte.

Blockchainens opgave

Så opgaven, som blockchain løste i det pionerede Bitcoin-netværk, er at muliggøre en pålidelig overførsel af ejerskab af digitale aktiver (assets) i et utroværdigt miljø uden mæglere. For eksempel er det digitale aktiv i Bitcoin-netværket digitale mønter bitcoin. Og alle de tekniske løsninger i Bitcoin og andre blockchains handler grundlæggende om at løse denne opgave.

Problemer, som blockchain løser

Lad os antage, at en finansiel organisation siger, at den har bygget et netværk over hele verden, som gør det muligt at overføre penge til enhver person. Ville du tro på det? Hvis denne organisation var Visa eller MasterCard, ville du sandsynligvis tro på det, men hvis det, som eksempel, var AnonymousWorldMoney, ville du næppe gøre det. Hvorfor? Fordi vi godt ved, hvordan distribuerede systemer udvikles af private virksomheder, med hvilke mål, og hvad det kan føre til. Lad os se nærmere på problemerne i sådanne systemer, og hvordan de kan løses ved hjælp af blockchain-teknologier.

Antag, at der i den hypotetiske AnonymousWorldMoney står servere med databaser, og det ville være godt, hvis der var flere af dem i forskellige datacentre. Når en afsender sender penge, registreres transaktionen, som replikeres på alle servere, og pengene når frem til modtageren.

I en ideel verden fungerer sådanne ordninger perfekt, men i vores opstår følgende problemer:

Problemet med at identificere deltagerne på den ene side og behovet for anonymitet ved transaktioner på den anden. Det vil sige, at pengene skal overføres til en bestemt modtager, og at ingen kender til denne transaktion, undtagen deltagerne i handlen. Banker har kontonumre og kreditkort knyttet til en bestemt fysisk eller juridisk person, og bankhemmelighed beskytter oplysningerne om transaktionerne. Men hvem garanterer, at den hypotetiske AnonymousWorldMoney ikke bruger personlige oplysninger og informationer om transaktionerne til egne formål?
Hvordan kan man sikre sig, at modtageren har modtaget det præcise beløb, der er sendt? Lad os sige, at afsenderen overførte $100, men modtageren fik kun $10. Afsenderen kommer til kontoret hos AnonymousWorldMoney med sin kvittering, mens skrankepersonalet viser sin version, hvor det står, at afsenderen kun overførte $10.
Problemet med et mistrustende miljø, for eksempel svindel kendt som double-spending. En uærlig deltager kan bruge sin saldo flere gange, indtil betalingen er blevet replikeret på alle servere. CAP-teoremet, selvfølgelig er ingen blevet ophævet, og konsistens vil til sidst blive opnået, men nogen vil ikke modtage penge for leverede tjenester eller varer. Derfor, hvis der ikke er fuld tillid til betalingsorganisationen eller deltagerne i aftalerne, skal netværket bygges på noget andet end tillid, nemlig kryptografi.
Den betingede AnonymousWorldMoney har et begrænset antal servere, der kan blive utilgængelige enten utilsigtet eller med ond hensigt.
AnonymousWorldMoney vil tage sin mærkbare provision.
Mulighed for styring. Under brugen af Bitcoin blev det klart, at folk ønskede ikke kun at overføre mønter til hinanden, men også at kontrollere forskellige betingelser for transaktionen, programmere arbejdsscenarier, automatisk udføre handlinger afhængigt af betingelser osv.

Hvordan blockchain løser disse problemer

Identifikationen af deltagerne sker ved hjælp af et nøglepar: en privat og en offentlig, og algoritmen for digital signatur identificerer entydigt afsenderen og modtageren, samtidig med at deres identiteter forbliver anonyme.
Transaktioner samles i blokke, en hash af blokken beregnes og skrives ind i den næste blok. Denne sekvens af registrering af hasher i blokke gav teknologiens navn 'blockchain', og det gør det umuligt at ændre / slette blokke eller enkelte transaktioner fra blokke ubemærket. Dermed, hvis en transaktion er kommet ind i blockchain, kan man være sikker på, at dens data forbliver uændrede.
Double-spending svindel forhindres ved at opnå konsensus i netværket om, hvilke data der skal betragtes som gyldige, og hvilke der skal kasseres. I Bitcoin-netværket opnås konsensus gennem proof-of-work (PoW).
Sikkerheden i netværkets funktion opnås ved, at blockchain er offentligt, hvor hver deltager kan køre sin egen node, få en fuld kopi af blockchain og desuden selv begynde at kontrollere transaktioner for korrekthed. Det er værd at bemærke, at moderne blockchains giver mulighed for at opbygge ikke kun offentlige (åbne), men også private (lukkede) blockchains samt bruge kombinerede ordninger.
Det er umuligt at helt fjerne provisionen i blockchainen, da man skal betale menneskene, der opretholder netværket, men i blockchainen beviser nødvendigheden af provision så overbevisende, at der ikke er nogen tvivl om dens nødvendighed.
Moderne blockchains har muligheden for at implementere forretningslogik, som i blockchain kaldes Smart Contracts. Logikken i smarte kontrakter implementeres på forskellige højniveau-sprog.

Lad os se på disse løsninger nærmere.

Blockchain-arkitektur

Bestanddele af blockchain

Hver deltager kan starte sin node med en fuld kopi af blockchainen (full node). Fuld noder, som kan skrive transaktioner til blockchainen, kaldes konsensusnoder (witness) eller minearbejdere (miner). Fuld noder, som blot kontrollerer korrektheden af transaktioner, kaldes revisionsnoder (audit). Lettere klienter (light clients) gemmer ikke fulde kopier af blockchainen, men interagerer med netværket ved at bruge fulde noder.
De fleste brugere til transaktioner bruger netop lettere klienter eller web-wallets. Alle noder er forbundet med hinanden. Med dette sæt af elementer bliver netværkets arkitektur mere robust:

Transaktionslivscyklus

Lad os se på transaktionslivscyklussen og nedbryde den i dele:

Blockchain-teknologier

Lad os se nærmere på de tekniske løsninger og deres forbindelser med hinanden.

Identifikation

Hver blockchain-transaktion skal være underskrevet med en digital signatur. Derfor skal hver deltager have et nøglepar for at foretage en transaktion: privat / offentlig. Nogle gange kaldes nøgleparret en wallet, da nøglerne entydigt er knyttet til en unik digital adresse og en deltagerbalance. I virkeligheden er nøgler og adresser blot strenge af cifre i forskellige talsystemer. Eksempler på nøgler og wallet-adresser:

Privat nøgle: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Offentlig nøgle: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Adresse: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

For at oprette en digital signatur i blockchainer anvendes en algoritme baseret på elliptiske kurver: Elliptic Curve Digital Signature Algorithm (ECDSA). For at fungere vælges den private nøgle (et 256-bit tal) normalt tilfældigt. Antallet af mulige nøgler er 2 til 256, så man kan tale om den praktiske umulighed af at få overlappende værdier af private nøgler.

Dernæst udledes den offentlige nøgle fra den private ved at multiplicere dens værdi med koordinaterne for et punkt, der ligger på den elliptiske kurve, hvilket resulterer i koordinaterne for et nyt punkt på samme kurve. Denne handling garanterer, at der opnås et nøglepar, der er egnet til digitale signaturer af transaktioner. Og endelig beregnes wallet-adressen entydigt ud fra den offentlige nøgle.

Der er mange artikler med detaljer om kryptografi, der anvendes i blockchain, for eksempel: Bitcoin in a nutshell — Kryptografi

Den private nøgle skal holdes strengt hemmelig og opbevares sikkert. Den offentlige nøgle er kendt af alle. Hvis den private nøgle går tabt, kan adgangen til aktivet (mønterne) ikke genoprettes, og pengene vil være tabt for altid. Derfor er opgaven med at opbevare private nøgler pålideligt ekstremt aktuel, da det ikke er en bank, hvor man altid kan komme med sit pas og genoprette kontoen. Der findes en hel industri, der producerer såkaldte kolde kryptovaluta-tegnebøger, der ligner USB-nøgler:

eller man kan bruge mere pålidelige metoder, som for eksempel at præge værdien af den private nøgle på tokens:

Transaktioner

Du kan læse mere om transaktionsstrukturen i artiklen Bitcoin i en nøddeskal — Transaktion. Det er vigtigt for os at forstå, at hver transaktion har mindst følgende data:

Fra: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - den digitale adresse for afsenderen
Til: 0x367adb7894334678b90aFe7882a5b06f7fbc783a - den digitale adresse for modtageren
Værdi: 0.0001 - transaktionsbeløbet
Transaktionshash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - hash for transaktionen

Derefter underskrives transaktionen med den private nøgle og sendes (se detaljer om protokollens arbejde Bitcoin i en nøddeskal - Protokol) til alle noder i blockchainen, som verificerer transaktioner for gyldighed. Algoritmen til at kontrollere transaktionen er ikke trivial og inkluderer to dusin trin.

Transaktionsblokke

Efter at have verificeret gyldigheden af transaktionerne, danner noderne dem til blokke. Udover transaktioner inkluderer blokken hash af den foregående blok, et tal (Nonce tæller), og hash af den aktuelle blok beregnes ved hjælp af SHA-256 algoritmen. Hashen skal opfylde visse sværhedsforhold. For eksempel ændres hashens sværhedsgrad automatisk hver 2. uge afhængigt af netværkets kapacitet, så blokken genereres omtrent hvert 10. minut. Sværhedsgraden bestemmes af følgende betingelse: den fundne hash skal være mindre end et forudbestemt tal. Hvis denne betingelse ikke er opfyldt, tilføjes 1 til Nonce, og arbejdet med at beregne hash'en gentages. For at finde hash'en anvendes Nonce-feltet, da det er de eneste data i blokken, der kan ændres, mens resten skal forblive uændret. Den korrekte hash skal have et bestemt antal nuller i starten, for eksempel en af de reelle hashes:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Sikre beregning af en hash er beviset for det udførte arbejde (Proof-of-Work, PoW) for Bitcoin- eller Ethereum-netværk. Processen med at finde hashes kaldes minedrift (mining), hvilket kan sammenlignes med guldgruvdrift. Navnet beskriver ret præcist essensen af processen, da det handler om simpel prøvning af muligheder, og hvis nogen finder en passende hash, er det virkelig held. Det er som at finde en ægte guldklump blandt tonner af ubrugelig klippe. Belønningen for en blok er i øjeblikket 12,5 BTC, hvilket ved den aktuelle kurs på Bitcoin til $3900 svarer til mere end et kilogram rent guld. Der er noget at kæmpe for!

Efter en vellykket beregning af en hash, bliver blokken og den fandne hash optaget i blockchain ved hjælp af næste blok. Du kan læse mere om strukturene af blokkene i artiklen Bitcoin i en nøddeskal - Blockchain, og nedenfor vil jeg vise et forenklet diagram:

Blockchain starter med en blok, der endnu ikke har en hash for den forrige blok. Sådan en blok i blockchainen er unik og kaldes Genesis block. De øvrige blokke har en ensartet struktur, og de adskiller sig kun i antallet af transaktioner. Du kan se de aktuelle transaktioner og blokke der skabes i Bitcoin eller Ethereum i Block Explorer.

Størrelsen på blokke i Bitcoin er begrænset til 1 MB, og med et minimum af information i en transaktion på omkring 200 bytes kan der maksimalt være omkring 6000 transaktioner i en blok. Heraf følger faktisk Bitcoins ydelse, som alle griner af: en blok genereres cirka hvert 10. minut * 60 sek = 600 sek, hvilket giver en formel ydelse på omkring 10 TPS. Selvom det i virkeligheden ikke er ydelse, men en bevidst implementeret arbejdsgang. I Ethereum, for at konkurrere, har de simpelthen sat blokgenereringstiden til 15 sek., hvilket formelt satte ydelsen i vejret. Derfor er det overhovedet meningsløst at sammenligne ydelsen i blockchains, der bruger PoW som konsensus, da den direkte afhænger af kompleksiteten af hash-beregningen, som kan indstilles til enhver værdi.

Forks

Hvad sker der, hvis flere noder finder hashes, der opfylder sværhedsforholdene, men har forskellige værdier (med andre ord, hvis de når forskellige konsensus), og indspiller blokke i blockchainen? Lad os se på, hvordan blockchainen beskytter sig mod denne situation. I dette tilfælde opstår der en såkaldt fork, og blockchainen har to versioner af kæden:

Hvad sker der derefter? Derefter begynder en del af netværket at arbejde på blok N+2 fra den ene kæde, mens en anden del arbejder på den anden:

En af disse blokke vil blive fundet først og sendt til blockchainen, og ifølge reglerne skal blockchainen skifte til den længere kæde og annullere alle transaktioner fra den alternative blok:

I denne forbindelse kan der opstå en situation, hvor en deltageres transaktion var kun i en af blokken i fork'en, som blev annulleret. Derfor, for at være sikker på, at den ønskede transaktion er blevet indspillet i blockchainen, er der en generel anbefaling — før man stoler på transaktionen, bør man vente på, at de næste par blokke bliver tilføjet til blockchainen. Anbefalingerne for, hvor mange blokke man skal vente på for forskellige blockchains, varierer. For eksempel kræver Bitcoin-netværket minimum 2 blokke og maksimum 6.

Det samme billede med blokke fork vil også ses ved den såkaldte 51%-angreb — hvor en gruppe minearbejdere forsøger at opbygge en alternativ blok kæde for at nå annullering af kæden med deres svigagtige transaktioner. Selvom det i øjeblikket er mere rentabelt at bruge sin kraft på ærlig mining frem for svindel.

Konsensus

For at indspille en blok i blockchainen skal netværket nå til enighed. Lad os huske opgaven med at nå konsensus i computersystemer. Problemet formuleres som opgaven med de byzantinske generaler BFT (Byzantine fault tolerance). Uden at gå ind i den maleriske beskrivelse af de byzantinske hærers problemer, kan opgaven formuleres således: hvordan kan noderne i netværket nå et samlet resultat, hvis en del af noderne bevidst kan fordreje det. De eksisterende algoritmer til løsning af BFT-problemet viser, at netværket kan fungere korrekt, hvis svindlere udgør mindre end 1/3. Hvorfor blev BFT-konsensus ikke brugt i Bitcoin-netværket? Hvorfor var det nødvendigt at bruge PoW? Der er flere grunde:

BFT fungerer godt med et lille, fast antal noder, mens antallet af noder i en offentlig blokchain er uforudsigeligt, og desuden kan noder tilkobles og frakobles vilkårligt.
Det er nødvendigt at motivere folk til at køre blockchain-noder. For at dette kan lade sig gøre, skal folk modtage belønninger. I BFT er der formelt ikke noget at opnå belønning for, mens alle intuitivt forstår, hvad belønningen i PoW er for: for elektriciteten brugt af processoren i jagten på blokhash.

Udover PoW findes der flere andre konsensusmetoder, der bruges i moderne blockchains, for eksempel:

PoS (Proof-of-Stake) — i blockchain Hyperledger
DPoS (Delegated Proof-of-Stake) — i blockchain BitShares
Modifikationer af BFT: SBFT (Simplified BFT) og PBFT (Practical BFT), for eksempel i blockchain Exonum

Lad os se nærmere på PoS-konsensus, da det netop er PoS og dets varianter, der har fået størst udbredelse i private blockchains. Hvorfor netop i private? På den ene side er PoS' karakteristika bedre sammenlignet med PoW, da der kræves færre beregningsressourcer for at nå konsensus, hvilket betyder, at hastigheden for dataregistrering i blockchainen øges. Men på den anden side giver PoS flere muligheder for svindel, så for at neutralisere dette skal alle deltagere i blockchainen være kendte.

PoS-konsensus er baseret på valget af en node, der kan registrere en blok med transaktioner i blockchainen afhængigt af mængden af midler på kontoen, nærmere bestemt ikke på kontoen, men i sikkerhedsstillelse. Det vil sige, jo flere midler du har i sikkerhedsstillelse, jo større sandsynlighed er der for, at netværket vælger din node til at registrere blokken. Sikkerhedsstillelsen returneres ikke, hvis blokken viser sig at være ugyldig. På denne måde er der indført en beskyttelse mod svindel. Der findes følgende varianter af PoS:

Konsensus Delegated PoS (DPoS) opdeler deltagerne i 'stemmeskærere' og 'validatører'. Myntholdere (stemmeskærende deltagere) delegerer deres ret til at verificere og registrere transaktioner i blockchainen til andre deltagere. På denne måde udfører validatører alt det beregningsmæssige arbejde og modtager belønning for det, og tilstedeværelsen af stemmeskærende deltagere garanterer validatorernes ærlighed, da de kan skiftes ud når som helst.
LPoS (Leased Proof-of-Stake) konsensus gør det muligt at leje sine midler ud til andre noder, så de har større chance for at verificere blokke. På den måde kan man modtage gebyrer for transaktioner, uden selv at deltage i verificeringen af transaktioner og minedrift af blokke.

Der findes også en række andre konsensusmodeller, som endnu ikke har fået bred udbredelse; jeg vil blot nævne dem for informationens skyld, og et overblik over selve konsensusalgoritmerne kan ses i f.eks. artiklen: Konsensusalgoritmer i blockchain.

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)

Pålidelighed og modeller for implementering af blockchains

Offentlig blockchain

Holdbarhed Public eller et andet navn Permissionless blockchain opnås ved at enhver kan tilslutte sig og se oplysninger eller endda tilslutte sin egen node, og tillid bygges på PoW konsensus.

Privat blockchain

Privat eller Private Permissioned blockchain. I disse blockchains har kun en bestemt gruppe deltagere (organisationer eller personer) adgang til informationen. Disse blockchains etableres af organisationer med det formål at øge den samlede fordel eller effektivitet. Deres pålidelighed sikres gennem deltagernes fælles mål og PoS samt BFT konsensusalgoritmer.

Blockchain-konsortium

Der findes Consortium eller Public Permissioned blockchain. Dette er blockchains, der kan tilsluttes for at se, men at tilføje information eller tilslutte sin egen node kan en deltager kun gøre med tilladelse fra andre deltagere. Disse blockchains designes af organisationer med det formål at øge tilliden fra kunderne eller forbrugerne af produkter eller samfundet som helhed. Her sikres pålideligheden også gennem eksisterende tillid mellem deltagerne og de samme PoS og BFT konsensusalgoritmer.

Smart Contracts

I blockchains, der er implementeret efter Bitcoin, er muligheden for at udføre smarte kontrakter blevet tilføjet i en eller anden grad. I bund og grund er en smart kontrakt en transaktion, der indeholder programkode til udførelse. Smarte kontrakter i Ethereum-netværket udføres i EVM (Ethereum Virtual Machine). For at starte udførelsen af en smart kontrakt skal den explicit aktiveres af en anden transaktion, eller der skal opfyldes forudsætninger for udførelsen. Resultaterne af en smart kontrakts udførelse vil også blive optaget i blockchainen. At hente data udefra blockchainen er muligt, men stærkt begrænset.

Hvilken forretningslogik kan implementeres ved hjælp af en smart kontrakt? Faktisk er der ikke så meget, f.eks. kontrol af betingelser baseret på data fra blockchain, ændring af ejerskab af digitale aktiver afhængigt af disse betingelser, registrering af data i permanent lagring inden for blockchain. Logikken implementeres på et særligt høj-niveau sprog, Solidity.

Et klassisk eksempel på funktionalitet, der implementeres ved hjælp af smart kontrakter, er udstedelse af tokens til gennemførelse af ICO. For eksempel har jeg implementeret en smart kontrakt til udstedelse af beskedne 500.000.000 AlexToken. Gennem linken i Etherscan er

den originale kode af smart kontrakten skrevet i 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;
}

og den binære repræsentation, som netværket ser det

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Du kan finde flere oplysninger om smarte kontrakter i artiklen: Hvad er smarte kontrakter i Ethereum.

Konklusion

Vi har opregnet teknologierne, som moderne blockchain er bygget på, og hvordan de er relateret til hinanden. Lad os nu formulere, hvilke opgaver der kan løses ved hjælp af blockchain, og hvilke løsninger der i bedste fald vil være ineffektive. Så, brugen af blockchain er ikke nødvendigt, hvis:

Transaktioner foregår i et betroet miljø;
Tilstanden med mellemmænds gebyrer forringer ikke deltagernes liv;
Deltagerne har ikke ejendom, der kan repræsenteres som digitale aktiver;
Der er ingen distribution af digitale aktiver, dvs. værdien ejes eller leveres kun af én deltager.

Hvilken fremtid venter blockchain? Lige nu kan vi kun gætte mulige udviklingsveje for blockchain-teknologier:

Blockchain vil blive en almindelig database teknologi, ligesom SQL eller NoSQL for at løse et bestemt sæt opgaver;
Blockchain vil blive en udbredt protokol, ligesom HTTP for internettet;
Blockchain vil blive grundlaget for et nyt finansielt og politisk system på planeten!

I den næste del vil vi se på, hvilke blockchains der findes i øjeblikket, og hvordan de anvendes i forskellige industrier.

Dette er kun begyndelsen!

Kilde: habr.com