Hva skal vi bygge blockchain for?

Heile historia menneskeheita er ei kontinuerleg frigjering frå lenkjer og skaping av nye, enno strengare. (Anonym forfattar)

Når eg analyserer talrike blockchain-prosjekt (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin osv.), forstår eg at dei alle er bygd på same tekniske prinsipp. Blockchains minner om hus, som, til tross for sin variasjon i struktur, dekor og funksjon, har fundament, vegger, tak, vindauga og dører som er knytte til kvarandre på bestemte måtar. Og dersom ein forstår dei grunnleggjande prinsippa for bygging av bygningar og kjenner eigenskapane til dei bruke materiala, kan ein bestemme den spesifikke bruken av eit hus. For tida er situasjonen med blockchain slik at alle har høyrt om det, men få forstår arkitekturen og prinsippa for drift. Derfor oppstår det misforståingar om kvifor og korleis det gir meining å bruke blockchain-teknologi.

I denne artikkelen vil vi gå gjennom dei felles eigenskapane og prinsippa for alle blockchains. Deretter vil vi sjå på oppgåvene som kan løysast med blockchain og for å forsterke materialet, vil vi bygge ein liten, men ekte blockchain på vår eigen virtuelle tomt!

Så, la oss minna oss om kva problem blockchain opprinneleg løyste.

Eg er sikker på at mange vil nevna den distribuerte, desentraliserte, offentlege og uforanderlege databasen. Men kvifor var alt dette nødvendig?

Eg føretrekk å begynne å studere kvar teknologi ved å lese standardar, ettersom det er desse som ligg til grunn for alle artiklar og bøker om emnet. Men det eksisterer for tida ingen standardar for blockchain, i ISO er det berre oppretta komitear for deira utvikling. For tida har kvar offentleg blockchain-prosjekt sitt eige dokument White paper, som i realiteten er eit teknisk krav. Det første kjente blockchain-prosjektet er nettverket Bitcoin. La oss gå til den offisielle nettsida til nettverket og sjå korleis alt byrja.

Oppgåva til blockchain

Så, oppgåva som blockchain løste i pionernettverket Bitcoin, er ei trygg overføring av eigarskap av digitale aktiva (assets) i ein tillitslaus omgivnad utan mellomledd. For eksempel, i Bitcoin-nettverket er den digitale eigendomen bitcoin-mynt. Og alle tekniske løysingar i Bitcoin og andre blockchains dreier seg om å løysa denne oppgåva.

Problema som blockchain løser

La oss si at en finansorganisasjon sier at de har bygget et nettverk over hele verden som gjør det mulig å sende penger til enhver person. Ville du trodd dem? Hvis denne organisasjonen var Visa eller MasterCard, ville du sannsynligvis gjort det, men hvis det var, for eksempel, AnonymousWorldMoney, ville du neppe gjort det. Hvorfor? Fordi vi vet godt hvordan distribuerte systemer utvikles av private selskaper, med hvilke mål, og hva dette kan føre til. La oss se nærmere på problemene med slike systemer og hvordan de kan løses ved hjelp av blokkjedeteknologier.

La oss anta at det i den hypotetiske AnonymousWorldMoney finnes servere med databaser, og det er bra hvis det finnes flere av dem i forskjellige datasentre. Når avsenderen sender penger, registreres en transaksjon som blir replikert til alle servere, og pengene når mottakeren.

I en perfekt verden fungerer slik en ordning utmerket, men i vår oppstår følgende problemer:

1. Problemet med identifisering av deltakerne på den ene siden, og behovet for anonymitet i transaksjoner på den andre. Det vil si at man må sende penger til en bestemt mottaker, og at ingen andre enn deltakerne i avtalen vet om transaksjonen. Banker har kontonumre og bankkort knyttet til en bestemt fysisk eller juridisk person, mens bankhemmeligheten beskytter informasjon om transaksjoner. Men hvem garanterer at den hypotetiske AnonymousWorldMoney ikke bruker personopplysninger og informasjon om transaksjoner til egne formål?
2. Hvordan kan man være sikker på at mottakeren faktisk har mottatt akkurat det beløpet som ble sendt? Anta at avsenderen sendte $100, men mottakeren fikk $10. Avsenderen kommer til kontoret til AnonymousWorldMoney med kvitteringen sin, men skrankepersonalet viser sin versjon, der det står at avsenderen bare sendte $10.
3. Problemet med et ustabilt miljø, for eksempel svindel kalt double-spending. En illojal deltaker kan bruke sin saldo flere ganger før betalingen er replikert til alle servere. CAP-teoremet, ingen har avskaffet det, og konsistens vil til slutt bli oppnådd, men noen vil ikke motta penger for utførte tjenester eller varer. Derfor, hvis det ikke finnes full tillit til betalingsorganisasjonen eller deltakerne i transaksjonene, må man bygge et nettverk basert ikke på tillit, men på kryptografi.
4. Den betingede AnonymousWorldMoney har et begrænset antal servere, som kan blive utilgængelige både utilsigtet eller med ond vilje.
5. AnonymousWorldMoney vil tage en mærkbar kommission.
6. Mulighed for styring. Under brugen af Bitcoin viste det sig, at folk ikke kun ønsker at overføre mønter til hinanden, men også at kontrollere forskellige betingelser for gennemførelse af transaktioner, programmere arbejdsforløb, automatisk udføre handlinger afhængigt af betingelser osv.

Hvordan blockchain løser disse problemer

1. Identifikationen af deltagerne sker ved hjælp af et nøglepar: en privat og en offentlig, og algoritmen for digital signatur identificerer entydigt afsender og modtager, mens deres identiteter forbliver anonyme.
2. Transaktioner samles i blokke, en hash for blokken beregnes, som skrives ind i den næste blok. Denne rækkefølge af optagelse af hashes i blokke har givet navn til teknologien blockchain, og den gør det umuligt at ændre / slette blokke eller enkelte transaktioner fra blokke uden at blive opdaget. Således, hvis en transaktion er kommet ind i blockchain, kan man være sikker på, at dens data forbliver uændrede.
3. Bedrageri ved double-spending forhindres ved at nå 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).
4. Pålideligheden af netværkets funktion opnås fordi blockchain er offentlig, hvor hver deltager kan starte sin egen node, få en fuld kopi af blockchain og endda selv begynde at kontrollere transaktioner for korrekthed. Det bør bemærkes, at moderne blockchains tillader at bygge både offentlige (åbne) og private (lukkede) blockchains samt at bruge kombinerede ordninger.
5. Man kan ikke helt undgå kommissionen i blockchain, da man skal betale folk, der understøtter netværket, men i blockchain er behovet for kommission så overbevisende, at der ikke er nogen tvivl om dens nødvendighed.
6. Moderne blockchains har mulighed for at implementere forretningslogik, som i blockchain kaldes Smart Contracts. Logikken i smarte kontrakter implementeres på forskellige højniveau sprog.

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

Arkitekturen af blockchain

Komponenterne i blockchain

Hver deltaker kan starte sin egen node med en full kopi av blokkjeden (full node). Fullstendige noder som kan skrive transaksjoner til blokkjeden, kalles konsensus-noder (witness) eller gruvearbeidere (miner). Fullstendige noder som bare verifiserer korrektheten av transaksjoner kalles revisjonsnoder (audit). Lette klienter (light clients) lagrer ikke fullstendige kopier av blokkjeden, men interagerer med nettverket ved å bruke fullstendige noder.
De fleste brukere benytter nettopp lette klienter eller web-lommebøker for å gjennomføre transaksjoner. Alle noder er koblet sammen. Med denne kombinasjonen blir nettverksarkitekturen mer robust:

Livssyklusen til en transaksjon

La oss se nærmere på livssyklusen til en transaksjon og dele den opp i deler:

Blokkjede-teknologier

La oss gå dypere inn på de tekniske løsningene og deres sammenhenger.

Identifikasjon

Hver blokkjede-transaksjon må signeres med en digital signatur. Derfor må hver deltaker ha et nøkkelpar for å gjennomføre en transaksjon: privat / offentlig. Noen ganger blir nøkkelparet omtalt som lommebok (wallet), ettersom nøklene er entydig knyttet til en unik digital adresse og saldo. I virkeligheten er nøkler og adresser bare strenger med tall i forskjellige tallsystemer. Eksempler på nøkler og lommeboksadresse:

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

For å lage en digital signatur i blokkjeder brukes en algoritme basert på elliptiske kurver: Elliptic Curve Digital Signature Algorithm (ECDSA). For at den skal fungere, genereres den private nøkkelen (et 256-bits tall) vanligvis tilfeldig. Antallet mulige nøkler er 2 opphøyd i 256, så det er praktisk talt umulig at to private nøkler kan være like.

Deretter får man den offentlige nøkkelen fra den private ved å multiplisere dens verdi med koordinatene til et punkt som ligger på den elliptiske kurven, som resulterer i koordinatene til et nytt punkt på den samme kurven. Denne prosessen garanterer at man får et nøkkelpar som er egnet for digitale signaturer av transaksjoner. Til slutt beregnes lommeboksadressen tydelig fra den offentlige nøkkelen.

Det finnes mange artikler som går i detalj om kryptografien som brukes i blokkjeder, for eksempel: Bitcoin in a nutshell — Kryptografi

Den private nøkkelen må være strengt hemmelig og oppbevares trygt. Den offentlige nøkkelen er kjent for alle. Hvis den private nøkkelen mistes, er det umulig å gjenopprette tilgangen til eiendelen (myntene), og pengene vil gå tapt for alltid. Derfor er det ekstremt viktig å lagre private nøkler på en sikker måte, ettersom dette ikke er en bank hvor man alltid kan komme med passet og gjenopprette kontoen. Det finnes en hel industri dedikert til produksjon av såkalte kalde kryptovaluta-lommebøker, lik flash-minne:

eller man kan bruke mer sikre metoder, som for eksempel å prege verdien av den private nøkkelen på brikker:

Transaksjoner

For mer informasjon om transaksjonsstrukturen kan man se artikkelen Bitcoin på en enkel måte — Transaksjon. Det er viktig for oss å forstå at hver transaksjon har minst følgende data:

Fra: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - digital adresse til avsender
Til: 0x367adb7894334678b90аfe7882a5b06f7fbc783a - digital adresse til mottaker
Verdi: 0.0001 - beløp for transaksjonen
Transaksjons-hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - hash for transaksjonen

Deretter signeres transaksjonen med den private nøkkelen og sendes (se detaljer om protokollen Bitcoin på en enkel måte - Protokoll) til alle noder i blokkjedene, som kontrollerer transaksjonene for gyldighet. Algoritmen for å verifisere transaksjonen er ikke triviel og inkluderer to dusin trinn.

Transaksjonsblokker

Når gyldigheten av transaksjonene er bekreftet, danner nodene blokker av dem. I tillegg til transaksjoner, lagres hash for den forrige blokken, et tall (Nonce-teller), og hash for den nåværende blokken beregnes ved hjelp av SHA-256-algoritmen. Hashen må oppfylle bestemte vanskelighetskrav. For eksempel justeres vanskeligheten for hash i Bitcoin-nettverket automatisk hver annen uke, avhengig av nettverkskraft, slik at en blokk genereres omtrent hvert tiende minutt. Vanskeligheten defineres av følgende betingelse: den funne hash må være mindre enn et forhåndsbestemt tall. Hvis betingelsen ikke er oppfylt, økes Nonce med 1, og arbeidet med å beregne hash gjentas. For å finne hash brukes Nonce-feltet, ettersom dette er de eneste dataene i blokken som kan endres, mens de øvrige må forbli uendret. Den korrekte hash må ha et bestemt antall nuller i starten, for eksempel en av de faktiske hashene:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

En vellykket hashing av et hash er et bevis på utført arbeid (Proof-of-Work, PoW) for Bitcoin- eller Ethereum-nettverkene. Prosessen med å finne hasher kalles mining, i likhet med gullgraving. Navnet beskriver prosessen ganske presist, da det innebærer en enkel prøve- og feilemetode, og hvis noen finner en passende hash, er det virkelig hell. Det er som å finne et ekte gullklump i tonn med grus. Belønningen for en blokk er nå 12,5 BTC, og hvis vi ganger det med den nåværende prisen på Bitcoin som er $3900, så tilsvarer det mer enn ett kilo rent gull. Det er noe å kjempe for!

Etter en vellykket hashing blir blokken og den funnet hashen registrert i blockchain som den neste blokken. Du kan lese mer om blokkstrukturen i artikkelen Bitcoin i et nøtteskall - Blockchain, og nedenfor viser jeg en forenklet diagram:

Blockchain starter med en blokk som ikke har en hash for den forrige blokken. En slik blokk er den eneste i blockchain og har sitt eget navn, Genesis block. De andre blokkene har samme struktur, men skiller seg bare i antallet transaksjoner. Faktiske transaksjoner og blokkene som opprettes nå i Bitcoin eller Ethereum kan ses i Block Explorer.

Størrelsen på blokkene i Bitcoin er begrenset til 1 MB, og med minimum informasjonsinnhold i en transaksjon på omtrent 200 byte, kan det maks være rundt 6000 transaksjoner i en blokk. Her kommer egentlig Bitcoin sin ytelse fra, som folk ler av: en blokk genereres omtrent hvert 10. minutt * 60 sek = 600 sek, noe som gir en formell ytelse på omtrent 10 TPS. Selv om dette, faktisk, ikke er ytelse, men en bevisst implementert arbeidsalgoritme. I Ethereum ble blokkgenereringstiden for å konkurrere bare satt til 15 sek, og den formelle ytelsen steg. Derfor er det meningsløst å sammenligne ytelsen i blokkene som bruker PoW som konsensus, da den klart avhenger av vanskelighetsgraden til beregningen av hashen, som kan settes til hva som helst.

Forks

Hva skjer hvis flere noder finner hasher som tilfredsstiller vanskelighetskravene, men som er forskjellige i verdi (med andre ord, de kommer til forskjellige konsensus), og blokker blir skrevet til blokkjeden? La oss se hvordan blokkjeden beskytter seg mot denne situasjonen. I så fall skjer det som kalles en fork, og blokkjeden har to versjoner av kjeden:

Hva skjer videre? Deretter begynner en del av nettverket å arbeide med blokken N+2 fra én kjede, mens en annen del arbeider fra den andre:

En av disse blokkene vil bli funnet tidligere og sendt til blokkjeden, og da må blokkjeden bytte til den lengre kjeden og annullere alle transaksjoner fra den alternative blokken:

I dette tilfellet kan det oppstå en situasjon der en deltakertransaksjon bare befant seg i én av blokkene i forken, som ble annullert. Derfor, for å være sikker på at den ønskede transaksjonen ble registrert i blokkjeden, er det en generell anbefaling — før man stoler på transaksjonen, bør man vente til flere blokker blir lagt til blokkjeden. Anbefalingen om hvor mange blokker man bør vente på varierer for forskjellige blokkjeder. For eksempel, for Bitcoin-nettverket er minimum 2 blokker, maksimum 6.

Det samme vil skje med blokkforking under det såkalte 51%-angrepet — når en gruppe gruvearbeidere prøver å utvikle en alternativ blokkjedekjede for å oppnå annullering av kjeden med sine svindeltransaksjoner. Selv om det for tiden er mer lønnsomt å bruke sine ressurser på ærlig graving enn svindel.

Konsensus

For å registrere en blokk i blokkjeden må nettverket oppnå konsensus. La oss huske oppgaven med å oppnå konsensus i datanettverk. Problemet formuleres som oppgaven til de bysantinske generalene BFT (Byzantine fault tolerance). For å overspille den maleriske beskrivelsen av problemer med den bysantinske hæren, kan oppgaven formuleres slik: hvordan kan nettverksnodene komme til et felles resultat når en del av nodene kan bevisst forvrenge dem? Eksisterende algoritmer for å løse BFT-oppgaven viser at nettverket kan fungere riktig hvis svindlere er mindre enn 1/3. Hvorfor ble ikke BFT-konsensus brukt i Bitcoin-nettverket? Hvorfor måtte man bruke PoW? Det er flere grunner:

• BFT fungerer godt med et lite, fast sett av noder, mens antallet noder i en offentlig blokk-kjede er uforutsigbart, og i tillegg kan noder bli slått av og på tilfeldig.
• Det er nødvendig å motivere folk til å kjøre blokk-kjedenoder. For dette må folk få belønning. I BFT er det ikke noe formelt å motta belønning for, men det er klart for alle på et intuitivt nivå hva folk får belønning for i PoW: for strømmen som forbrukes av prosessoren i prosessen med å finne blokkens hash.

I tillegg til PoW finnes det flere konsensusmetoder som brukes i moderne blokk-kjeder, for eksempel:

• PoS (Proof-of-Stake) — i blokk-kjeden Hyperledger
• DPoS (Delegated Proof-of-Stake) — i blokk-kjeden BitShares
• Modifikasjoner av BFT: SBFT (Simplified BFT) og PBFT (Practical BFT), for eksempel i blokk-kjeden Exonum

La oss se litt nærmere på konsensusmetoden PoS, ettersom PoS og dens varianter har fått størst utbredelse i private blokk-kjeder. Hvorfor nettopp i private? På den ene siden er egenskapene til PoS bedre sammenlignet med PoW, ettersom færre beregningsressurser er nødvendige for å oppnå konsensus, noe som betyr at hastigheten på dataskriving til blokk-kjeden øker. Men på den annen side gir PoS flere muligheter for svindel, derfor må alle deltakerne i blokk-kjeden være kjent for å nøytralisere dette.

PoS-konsensus er basert på valget av en node som kan skrive en blokk med transaksjoner til blokk-kjeden avhengig av mengden midler på kontoen, mer presist, ikke på kontoen, men i garanti. Det vil si, jo flere midler du har i garanti, desto større er sannsynligheten for at nettverket velger din node for å skrive blokken. Garantien returneres ikke hvis blokken viser seg å være ugyldig. På denne måten er beskyttelse mot svindel implementert. Det er følgende variasjoner av PoS:

• Delegated PoS (DPoS) konsensus deler deltakerne i «stemmekandidater» og «validere». Innehavere av mynter (stemmedeltakere) delegerer sin rett til å verifisere og skrive transaksjoner til blokk-kjeden til andre deltakere. Dermed utfører validatører alt beregningsarbeid og får belønning for dette, mens stemmedeltakerne sikrer ærlighet fra validatørene, ettersom de kan byttes ut når som helst.
• LPoS (Leased Proof-of-Stake) konsensus gir deg muligheten til å leie ut midlene dine til andre noder, slik at de får bedre sjanser til å verifisere blokker. Slik kan du motta avgift for transaksjoner uten å delta i selve verifiseringen av transaksjonene og gruvedrift av blokker.

Det finnes en rekke andre konsensusmetoder som ennå ikke har fått bred spredning, her er bare en liste til informasjon, mens en oversikt over selve konsensusalgoritmene kan bli funnet, for eksempel i artikkelen: 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-Importans)

Pålitelige og modeller for distribusjon av blokkjeder

Offentlig blokkjede

Motstandskraft Public eller et annet navn Permissionless blockchain oppstår ved at hvem som helst kan koble til og se informasjonen eller til og med koble til sin egen node, og tillit bygges gjennom PoW-konsensus.

Privat blokkjede

Privat eller Private Permissioned blockchain. I disse blokkjeden har bare en bestemt gruppe deltakere (organisasjoner eller personer) tilgang til informasjonen. Slike blokkjeder bygges av organisasjoner med mål om å øke den samlede nytten eller effektiviteten. Påliteligheten deres sikres av felles mål blant deltakerne og konsensusalgoritmene PoS og BFT.

Blockchain-konsortium

Det finnes Consortium eller Public Permissioned blockchain. Dette er blokkjeder som enhver kan koble til for å se, men for å legge til informasjon eller koble til sin egen node må deltakeren ha tillatelse fra andre deltakere. Slike blokkjeder bygges av organisasjoner med mål om å øke tilliten hos kunder eller produsenter eller samfunnet generelt. Her oppnås pålitelighet også gjennom tilstedeværelse av tillit mellom deltakerne og de samme konsensusalgoritmene PoS og BFT.

Smart Contracts

I blokkjeder som ble implementert etter Bitcoin, har muligheten for å utføre smarte kontrakter blitt lagt til i varierende grad. I hovedsak er en smart kontrakt en transaksjon som inneholder programkode for utførelse. Smarte kontrakter i Ethereum-nettverket kjøres i EVM (Ethereum Virtual Machine). For å starte utførelsen av en smart kontrakt må den eksplisitt aktiveres av en annen transaksjon, eller betingelsene for utførelsen må være oppfylt. Resultatene av utførelsen av den smarte kontrakten blir også lagret i blokkjeden. Henting av data fra utenfor blokkjeden er mulig, men svært begrenset.

Hvilken forretningslogikk kan implementeres med en smartkontrakt? Egentlig ikke så mye, for eksempel sjekke betingelser basert på data fra blokkjeden, endre eierskap av digitale aktiva avhengig av disse betingelsene, og registrere data i permanent lagring innenfor blokkjeden. Logikken implementeres på et spesielt høynivåspråk kalt Solidity.

Et klassisk eksempel på funksjonalitet som implementeres ved hjelp av smartkontrakter, er utstedelse av tokens for å gjennomføre ICO. For eksempel har jeg implementert en smartkontrakt for å utstede beskjedne 500 000 000 AlexToken. Ved lenken i Etherscan festet

kildekoden til smartkontrakten 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 representasjonen slik nettverket ser den

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Mer informasjon om smartkontrakter finner du i artikkelen: Hva er smartkontrakter i Ethereum.

Konklusjon

Vi har listet opp teknologiene som moderne blokker er bygget på og hvordan de henger sammen. Nå la oss formulere hvilke oppgaver som kan løses med blockchain, og hvilke løsninger som i beste fall vil være ineffektive. Så, bruken av blockchain er ikke nødvendig hvis:

• Transaksjoner skjer i et tillitsfullt miljø;
• Forekomsten av mellommannsgebyrer forverrer ikke livene til deltakerne;
• Deltakerne har ikke eiendom som kan representeres som digitale aktiva;
• Det er ingen desentralisering i digitale eiendeler, det vil si at verdien eies eller leveres av bare én deltaker.

Hvilken fremtid venter blockchain? Nå kan vi bare anta mulige utviklingsveier for blockchain-teknologiene:

• Blockchain vil bli en like vanlig databaserteknologi som for eksempel SQL eller NoSQL for å løse sitt bestemte sett med oppgaver;
• Blockchain vil bli en utbredt protokoll, som HTTP for Internett;
• Blockchain vil bli grunnlaget for et nytt finansielt og politisk system på planeten!

I neste del skal vi se på hvilke blockchain-er som eksisterer nå og hvordan de brukes i ulike industrier.

Dette er bare begynnelsen!

Kilde: habr.com