🥇Hva koster det oss å bygge blokkjede?

Heile historia menneskeheten er ein kontinuerleg frigjering frå lenkene og skapinga av nye, endå sterkare. (Anonym forfattar)

Når eg analyserer talrike blockchain-prosjekt (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin og fleire), forstår eg at dei alle er bygde på dei same prinsippa frå ein teknisk synsvinkel. Blockchains liknar hus, der det til tross for eit mangfald av konstruksjonar, dekor og føremål finst fundament, vegar, tak, vindauge, dører som er knytt saman på bestemte måtar. Og om ein forstår dei grunnleggjande prinsippa for bygningar, og kjenner eigenskapane til materiala som blir brukte, kan ein avgjere målet med det spesifikke huset. I dag er det slik med blockchain at alle har høyrt om det, men få forstår arkitekturen og prinsippa bak. Derfor oppstår det misforståingar om kvifor og korleis det er meningsfullt å bruke blockchain-teknologi.

I denne artikkelen skal vi gå gjennom eigenskapane og prinsippa som er felles for alle blockchains. Deretter ser vi på oppgåvene som kan løysast med hjelp av blockchain, og for å forsteke materialet skal vi bygge ein liten, men ekte blockchain på vår eigen virtuelle tomt!

Så, la oss minnast hvilke problem blockchain først løyste.

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

Eg føretrekker å starte studiet av ein teknologi med å lese standardar, sidan det er på dei som alle artiklar og bøker om emnet er baserte. Men blockchain-standardar eksisterer for tida ikkje, det er berre komitéar for å utvikle dei. For tida har kvart offentleg blockchain-prosjekt sitt eige dokument White paper, som i prinsippet er ei teknisk spesifikasjon. Det første velkjente blockchain-prosjektet er Bitcoin-nettverket. La oss gå til den offisielle nettsida for nettverket og sjå korleis alt byrja.

Oppgåva til blockchain

Så, oppgåva som blockchain løyste i pioner-nettverket Bitcoin, er å gjere ei påliteleg overføring av eigarskap over digitale aktiv til ein udifferensiert miljø utan mellomhandlar. For eksempel er det digitale aktivet i Bitcoin-nettverket digitale myntar bitcoin. Og alle tekniske løysingar i Bitcoin og andre blockchains handlar om å løyse denne oppgåva.

Problema som blockchain løser

La oss si at en finansinstitusjon hevder å ha bygget et nettverk over hele verden som gjør det mulig å sende penger til hvem som helst. Vil du stole på det? Hvis dette er Visa eller MasterCard, vil du sannsynligvis stole på dem, men hvis det er hypotetiske AnonymousWorldMoney, ville du kanskje ikke gjøre det. Hvorfor? Fordi vi vet godt hvordan distribuerte systemer lages 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 blokkjede-teknologi.

La oss anta at det finnes servere med databaser i hypotetiske AnonymousWorldMoney, og det er bra hvis de er plassert i flere datasentre. Når en avsender sender penger, registreres en transaksjon som replikeres på alle serverne, og pengene når frem til mottakeren.

I en ideell verden fungerer denne modellen utmerket, men i vår virkelighet oppstår følgende problemer:

Problemet med å identifisere deltakerne på den ene siden og behovet for anonymitet i transaksjoner på den andre. Det vil si at man må sende penger til en spesifikk mottaker uten at noen unntatt deltakerne i avtalen vet om transaksjonen. Banker har kontonumre og bankkort knyttet til en spesifikk fysisk eller juridisk person, og bankhemmelighet beskytter informasjon om transaksjoner. Men hvem garanterer at hypotetiske AnonymousWorldMoney ikke bruker persondata og informasjon om transaksjoner til sine egne formål?
Hvordan kan man være sikker på at mottakeren har mottatt akkurat det beløpet som ble sendt? Si at avsenderen sendte $100, men mottakeren fikk $10. Avsenderen kommer til kontoret til AnonymousWorldMoney med sin kvittering, men skrankepersonalet viser sin versjon der det står at avsenderen bare sendte $10.
Problemet med en ikke-pålitelig miljø, for eksempel svindel kjent som double-spending. En uærlig deltaker kan bruke sin saldo flere ganger før betalingen er replikert på alle servere. CAP-teoremet, er selvfølgelig fortsatt gyldig, og konsistens vil til slutt bli oppnådd, men noen vil ikke motta betaling for de tjenester eller varer de har levert. Derfor, hvis det ikke er full tillit til betalingsorganisasjonen eller deltakerne i transaksjonen, må man bygge et nettverk basert ikke på tillit, men på kryptografi.
Den betingede AnonymousWorldMoney har et begrænset antal servere, som kan blive utilgængelige enten utilsigtet eller med ond hensigt.
AnonymousWorldMoney vil tage sin målbare provision.
Muligheden for kontrol. Det er blevet klart under brugen af Bitcoin, at folk ønsker ikke kun at overføre mønter til hinanden, men også at kontrollere forskellige betingelser for transaktionen, programmere arbejdsscenarier og automatisk udføre handlinger baseret på betingelser, osv.

Hvordan blockchain løser disse problemer

Identifikation af deltagerne foregår ved hjælp af et par nøgler: en privat og en offentlig, og algoritmen for digital underskrift identificerer utvetydigt afsenderen og modtageren, mens deres identiteter forbliver anonyme.
Transaktioner samles i blokke, en hash af blokken beregnes, og den skrives ind i den næste blok. Denne sekvens af hashing i blokke gav teknologiens navn blockchain, og det gør det umuligt at ændre eller slette blokke eller enkeltstående transaktioner uden at blive opdaget. Således, hvis en transaktion er blevet inkluderet i blockchain, kan man være sikker på, at dens data forbliver uændrede.
Duplicitet i forbruget forhindres ved at opnå konsensus i netværket om, hvilke data der skal betragtes som gyldige, og hvilke der skal afvises. I Bitcoin-netværket opnås konsensus gennem proof of work (PoW).
Netværkets pålidelighed opnås ved, at blockchain er offentlig, hvor hver deltager kan køre sin egen node, få en fuld kopi af blockchain og endda begynde at kontrollere transaktioner for korrekthed selv. Det skal bemærkes, at moderne blockchains tillader bygning af både offentlige (åbne) og private (lukkede) blockchains, samt brug af kombinerede ordninger.
Det er umuligt at slippe helt for gebyrer i blockchain, da det er nødvendigt at betale folk, der understøtter netværket, men nødvendigheden af gebyrer i blockchain bevises så overbevisende, at der ikke er nogen tvivl om deres nødvendighed.
Moderne blockchains har mulighed for at implementere forretningslogik, som i blockchain kaldes Smart Contracts. Logikken for smart contracts implementeres på forskellige høj-niveau programmeringssprog.

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

Blockchain-arkitektur

Bestanddele af 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 konsensusnoder (witness) eller minere (miner). Fullstendige noder som bare verifiserer transaksjoners korrekthet kalles revisjonsnoder (audit). Lette klienter (light clients) lagrer ikke komplette kopier av blokkjeden, men interagerer med nettverket ved å bruke fullstendige noder.
De fleste brukere bruker faktisk lette klienter eller nett-lommebøker for å gjennomføre transaksjoner. Alle noder er koblet sammen. Med et slikt sett av elementer blir nettverksarkitekturen mer robust:

Livssyklus for transaksjonen

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

Blokkjede-teknologier

La oss se nærmere på de tekniske løsningene og deres relasjoner til hverandre.

Identifikasjon

Hver blokkjede-transaksjon må være signert med en digital signatur. Derfor må hver deltaker ha et nøkkelpar for å gjennomføre en transaksjon: privat / offentlig. Noen ganger kalles nøkkelparet en lommebok (wallet), da nøklene er entydig knyttet til en unik digital adresse og saldoen til deltakeren. I virkeligheten er nøkler og adresser bare strenger med tall i forskjellige tallsystemer. Eksempler på nøkler og adresse til lommebok:

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, blir vanligvis den private nøkkelen (256-bit tall) valgt tilfeldig. Antall muligheter for nøkler er 2 opphøyet til 256, derfor kan vi snakke om den praktiske umuligheten av samsvar mellom verdiene til private nøkler.

Deretter genereres den offentlige nøkkelen fra den private nøkkelen ved å multiplisere dens verdi med koordinatene til et punkt som ligger på den elliptiske kurven, noe som resulterer i koordinatene til et nytt punkt på den samme kurven. Denne handlingen garanterer at vi får et nøkkelpar som er egnet for digitale signaturer av transaksjoner. Til slutt kan adressen til lommeboken entydig beregnes fra den offentlige nøkkelen.

Det finnes mange artikler som forklarer kryptografien som brukes i blokkjeder, for eksempel: Bitcoin i et nøtteskall — Kryptografi

Den private nøkkelen må være strengt hemmelig og oppbevares sikkert. Den offentlige nøkkelen er kjent for alle. Hvis den private nøkkelen mistes, kan tilgangen til eiendelen (myntene) ikke gjenopprettes, og pengene vil være tapt for alltid. Derfor er det svært viktig å lagre private nøkler sikkert, fordi dette ikke er en bank hvor man alltid kan gå med pass for å gjenopprette kontoen. Det finnes en hel industri som produserer såkalte kalde kryptovaluta-lommebøker, som ligner på USB-minnepinner:

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

Transaksjoner

Mer om transaksjonsstrukturen kan ses i artikkelen Bitcoin i et nøtteskall — Transaksjon. Det er viktig for oss å forstå at hver transaksjon har minst følgende data:

Fra: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - digital adresse til avsender
Til: 0x367adb7894334678b90a fe7882a5b06f7fbc783a - digital adresse til mottaker
Verdi: 0.0001 - transaksjonsbeløp
Transaksjonshash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - transaksjonshash

Deretter signeres transaksjonen med den private nøkkelen og sendes (se detaljer om hvordan protokollen fungerer Bitcoin i et nøtteskall - Protokoll) til alle noder i blokkjeden, som verifiserer transaksjonene for gyldighet. Algoritmen for verifisering av transaksjonen er ikke-triviell og inkluderer to dusin trinn.

Transaksjonsblokker

Etter å ha sjekket gyldigheten av transaksjonene, danner nodene blokker ut fra dem. I tillegg til transaksjoner lagres hashen fra forrige blokk, et tall (noncen), og den nåværende blokkens hash beregnes ved hjelp av SHA-256-algoritmen. Hashet må oppfylle bestemte vanskelighetsbetingelser. For eksempel endres hashvanskeligheten automatisk hvert andre uke i Bitcoin-nettverket avhengig av nettverkskapasiteten, slik at blokker genereres omtrent hvert tiende minutt. Vanskelighetsgraden bestemmes av følgende betingelse: den funne hashen må være mindre enn et på forhånd angitt tall. Hvis dette ikke er tilfelle, legges det til 1 til Nonce, og arbeidet med beregningen av hashen gjentas. For å finne hashen brukes Nonce-feltet, ettersom det er de eneste dataene i blokken som kan endres, mens de andre må forbli uendret. Den korrekte hashen må ha et bestemt antall nuller i starten, for eksempel en av de virkelige hashen:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Den vellykkede oppdagelsen av en hash er beviset på det utførte arbeidet (Proof-of-Work, PoW) for Bitcoin- eller Ethereum-nettverk. Prosessen med å finne hasher kalles mining, på samme måte som utvinning av gull. Navnet beskriver prosessen ganske presist, ettersom det handler om en enkel prøving av alternativer, og hvis noen finner en passende hash, er det virkelig flaks. Det er som å finne en ekte gullklump i tonn med avfall. Belønningen for hver blokk er nå 12,5 BTC, og hvis man multipliserer det med den nåværende prisen på bitcoin, $3900, får man mer enn ett kilo rent gull. Det er noe å kjempe for!

Etter at hashen er funnet, blir blokken og den funnet hashen registrert i blokkjedens neste blokk. Mer om blokkstrukturen kan sees i artikkelen Bitcoin i et nøtteskall - Blokkjede, og nedenfor er en forenklet skjema:

En blokkjedes start er en blokk som ikke har en hash fra den forrige blokken. Denne blokken er unik i blokkjeden og har sitt eget navn, Genesis block. De øvrige blokkene har samme struktur og skiller seg kun ved antallet transaksjoner. Virkelige transaksjoner og blokker som opprettes for øyeblikket i Bitcoin eller Ethereum kan sees i Block Explorer.

Størrelsen på blokkene i Bitcoin er begrenset til 1 MB, og med et minimum av informasjon i en transaksjon på omtrent 200 byte, kan det maksimalt være omtrent 6000 transaksjoner i en blokk. Derav, forresten, kommer også ytelsen til Bitcoin, som mange ler av: en blokk genereres omtrent hvert 10. minutt * 60 sek = 600 sekunder, som gir en formell ytelse på omtrent 10 TPS. Selv om dette i realiteten ikke er ytelse, men en bevisst implementert arbeidsalgoritme. I Ethereum, for å konkurrere, ble blokkegenereringstiden satt til 15 sekunder, og den formelle ytelsen steg. Derfor gir det ingen mening å sammenligne ytelse i blokkjeder som bruker PoW som konsensus, ettersom det avhenger direkte av kompleksiteten av beregningen av hashen, som kan settes til hva som helst.

Forks

Hva skjer hvis flere noder finner hasher som oppfyller vanskelighetskravene, men har forskjellige verdier (med andre ord, de når forskjellige konsensus) og registrerer blokker i blokkjedene? La oss se på hvordan blokkjedene beskytter seg mot denne situasjonen. I dette tilfellet skjer det som kalles en fork, og blokkjedene har to versjoner av kjeden:

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

En av disse blokkene vil bli funnet tidligere og sendt til blokkjedene, og ifølge reglene må blokkjedene bytte til den lengre kjeden og omgjøre alle transaksjoner fra den alternative blokken:

Det kan oppstå en situasjon der en deltakers transaksjon kun var i én av blokkene i forken, som ble omgjort. Derfor, for å være sikker på at den nødvendige transaksjonen er blitt registrert i blokkjedene, er det en generell anbefaling - før man stoler på transaksjonen, bør man vente til flere blokker er lagt til blokkjedene. Anbefalingene for hvor mange blokker man skal vente varierer for ulike blokkjeder. For eksempel, for Bitcoin-nettverket er minimum to blokker og maksimum seks.

Det samme gjelder når det kommer til forker av blokker under det som kalles en 51%-angrep - det er når en gruppe minearbeidere prøver å utvikle en alternativ blokkjedekjede for å omgjøre kjeden med sine svindeltransaksjoner. Selv om det i dag, i stedet for svindel, er mer lønnsomt å bruke ressursene til ærlig mining.

Konsensus

For å registrere en blokk i blokkjedene må nettverket komme til en konsensus. La oss huske oppgaven med å oppnå konsensus i datanettverk. Problemet formuleres som oppgaven med de byzantinske generalene BFT (Byzantisk feiltoleranse). Uten å gå inn på den fargerike beskrivelsen av problemene til den byzantinske hæren, kan oppgaven formuleres slik: hvordan noder i nettverket kan komme til et felles resultat når deler av nettverket bevisst kan forvrenge dem. Eksisterende algoritmer for å løse BFT-oppgaven viser at nettverket kan fungere korrekt hvis svindlerne er færre 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, fastsettet sett av noder, mens i en offentlig blokkjede er antallet noder uforutsigbart, og i tillegg kan noder starte og stoppe tilfeldig.
Det er nødvendig å motivere folk til å kjøre blokkjedenoder. For dette må folk motta belønning. I BFT er det formelt ingenting å få belønning for, men hva som gir belønning i PoW er intuitivt forståelig for alle: for strømmen som forbrukes av prosessoren i prosessen med å finne hash av blokken.

I tillegg til PoW finnes det flere konsensusmekanismer som brukes i moderne blokkjeder, for eksempel:

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

La oss stoppe litt ved PoS-konsensus, siden det er PoS og dets varianter som har fått mest utbredelse i private blokkjeder. Hvorfor nettopp i private? På den ene siden har PoS bedre egenskaper sammenlignet med PoW, da det kreves færre beregningsressurser for å oppnå konsensus, noe som øker hastigheten på datainnsamlingen i blokkjeden. Men på den andre siden gir PoS flere muligheter for svindel, så for å nøytralisere dette må alle deltakere i blokkjeden være kjente.

PoS-konsensus er basert på valget av en node som kan skrive en blokk med transaksjoner til blokkjeden, avhengig av hvor mye midler som er på konto, eller rettere sagt, ikke på konto, men som sikkerhet. Det vil si, jo mer midler du har i sikkerhet, jo større er sannsynligheten for at nettverket velger din node for å skrive blokken. Sikkerheten returneres ikke hvis blokken viser seg å være ugyldig. Dermed er svindelbeskyttelse implementert. Det finnes følgende varianter av PoS:

Delegated PoS (DPoS) konsensus deler deltakerne inn i "stemmegivende" og "validerende". Myntinnehavere (stemmegivende deltakere) delegerer sin rett til å verifisere og skrive transaksjoner til blokkjeden til andre deltakere. Slik utfører valideringsdeltakere alt beregningsarbeid og mottar belønning for det, mens tilstedeværelsen av stemmegivende deltakere garanterer ærligheten til validererne, ettersom de når som helst kan byttes ut.
LPoS-konsensus (Leased Proof-of-Stake) lar deg leie ut midlene dine til andre noder, slik at de har større sjanser for å verifisere blokker. Dermed kan du motta gebyrer for transaksjoner uten å delta i selve verifiseringen av transaksjoner og blokkproduksjon.

Det finnes flere konsensusmetoder som ennå ikke har blitt allment utbredt, her er bare en liste for informasjon, en oversikt over konsensusalgoritmene kan sees, for eksempel i artikkelen: Konsensusalgoritmer i Blokkjeden.

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ålitelige og modeller for distribusjon av blokkjeder

Offentlig blokkjede

Motstandsdyktighet Public eller et annet navn Permissionless blockchain opprettes ved at alle kan koble til og se informasjonen, eller til og med koble til sin egen node, mens tillit bygges på 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 hensikten å øke den samlede nytten eller effektiviteten. Påliteligheten oppnås gjennom felles mål for deltakerne og algoritmer for konsensus som PoS og BFT.

Blokkjede-konsortium

Det finnes Consortium eller Public Permissioned blockchain. Dette er blokkjeder som alle kan koble til for å se, men å legge til informasjon eller koble til sin egen node kan deltakeren kun gjøre med tillatelse fra andre deltakere. Slike blokkjeder bygges av organisasjoner for å øke tilliten fra kundene eller forbrukerne av produktene eller samfunnet generelt. Her oppnås pålitelighet også ved tilstedeværelse av tillit mellom deltakerne samt de samme konsensusalgoritmene som PoS og BFT.

Smart Contracts

I blokkjeder implementert etter Bitcoin er det lagt til muligheter for å utføre smarte kontrakter i variabel grad. En smart kontrakt er i hovedsak en transaksjon hvor programkode for utførelse er lagt inn. Smarte kontrakter i Ethereum-nettverket kjøres i EVM (Ethereum Virtual Machine). For å begynne å utføre en smart kontrakt må den tydelig startes av en annen transaksjon, eller forutsetningene for utføring må oppfylles. Resultatet av utførelsen av den smarte kontrakten vil også bli registrert i blokkjeden. Å hente data utenfor blokkjeden er mulig, men er ekstremt begrenset.

Hvilken forretningslogikk kan implementeres ved hjelp av smarte kontrakter? Faktisk er det ikke så mye, for eksempel sjekk av betingelser basert på data fra blokkjeden, endring av eierskap for digitale aktiva avhengig av disse betingelsene, og lagring av data i permanent lagring innen blokkjeden. Logikken implementeres på et spesielt høynivå språk kalt Solidity.

Et klassisk eksempel på funksjonalitet som implementeres med smarte kontrakter er utstedelse av tokens for å gjennomføre ICO. For eksempel har jeg implementert en smart kontrakt for å utstede beskjedne 500 000 000 AlexToken. Ved lenken i Etherscan festet

kildekoden til smartkontrakten på språket 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 binærrepresentasjonen, som nettverket ser den

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

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

Konklusjon

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

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

Hvilken fremtid venter blokkjede? Nå kan man bare anta mulige utviklingsveier for blokkjede-teknologier:

Blokkjede vil bli en like vanlig database-teknologi som for eksempel SQL eller NoSQL for å løse sitt bestemte sett av oppgaver;
Blokkjede vil bli et utbredt protokoll, som HTTP for Internett;
Blokkjede vil bli grunnlag for et nytt finansielt og politisk system på planeten!

I neste del vil vi se på hvilke blokkjeder som eksisterer nå og hvordan de blir anvendt i ulike industrier.

Dette er bare begynnelsen!

Kilde: habr.com