Vad kostar det att bygga en blockchain?

Hela mänsklighetens historia är en oavbruten befrielse från kedjor och skapandet av nya, ännu starkare. (Anonym författare)

När jag analyserar ett antal blockchain-projekt (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin osv.) inser jag att de alla tekniskt sett bygger på samma principer. Blockkedjor liknar hus, där det finns en grund, väggar, tak, fönster och dörrar, som är kopplade till varandra på specifika sätt, trots alla olika konstruktioner, dekorer och funktioner. Om man förstår de grundläggande designprinciperna för byggnader och känner till egenskaperna hos de använda materialen, kan man avgöra det specifika syftet med ett hus. För närvarande finns det en situation med blockchain där alla har hört talas om det, men få förstår arkitekturen och principerna för dess funktion. Därför uppstår det oklarheter kring varför och hur det är meningsfullt att använda blockchain-teknologier.

I den här artikeln kommer vi att diskutera de gemensamma egenskaperna och principerna för alla blockkedjor. Sedan kommer vi att titta på de uppgifter som kan lösas med hjälp av blockchain, och för att befästa materialet kommer vi att bygga en liten, men verklig blockkedja på vår virtuella tomt!

Så, låt oss komma ihåg vilka problem blockchain ursprungligen löste.

Jag är säker på att många kommer att nämna en distribuerad, decentraliserad, offentlig och oförändrad databas. Men varför var allt detta nödvändigt?

Jag föredrar att börja studera en teknik genom att läsa standarder, eftersom alla artiklar och böcker om det aktuella ämnet grundas på dem. Men det finns för närvarande inga standarder för blockchain, endast kommittéer för deras utveckling. För närvarande har varje offentligt blockchain-projekt sitt eget dokument White paper, som i själva verket fungerar som en teknisk specifikation. Det första allmänt kända blockchain-projektet är nätverket Bitcoin. Vi går till den officiella webbplatsen för nätverket och ser hur allt började.

Blockchainens uppgift

Så, uppgiften som blockchain löser i det banbrytande Bitcoin-nätverket är att möjliggöra en pålitlig överföring av äganderätt över digitala tillgångar i en icke-pålitlig miljö utan mellanhänder. Till exempel, i Bitcoin-nätverket är den digitala tillgången bitcoin-mynt. Alla tekniska lösningar för Bitcoin och andra blockkedjor handlar om att lösa denna uppgift.

Problemen som blockchain löser

Anta en finansiell organisation hävdar att den har byggt ett nätverk över hela världen för att kunna överföra pengar till vem som helst. Skulle du lita på den? Om denna organisation är Visa eller MasterCard, är det troligt att du skulle göra det, men om det är något som AnonymousWorldMoney, kanske inte. Varför? Därför att vi vet hur distribuerade system skapas av privata företag, med vilka syften, och vilka konsekvenser det kan få. Låt oss titta närmare på problemen med sådana system och hur de kan lösas med hjälp av blockchain-teknologi.

Anta att det i AnonymousWorldMoney finns servrar med databaser, och det är bra om det finns flera på olika datacenter. När avsändaren överför pengar registreras en transaktion som replikerar på alla servrar, och pengarna kommer fram till mottagaren.

I en perfekt värld fungerar en sådan modell utmärkt, men i vår verklighet uppstår följande problem:

1. Problemet med att identifiera deltagare å ena sidan och behovet av anonymitet i transaktioner å andra sidan. Det vill säga, man måste överföra pengar till en specifik mottagare och se till att ingen, förutom parterna i affären, känner till transaktionen. Banker har kontonummer och bankkort kopplade till en specifik fysisk eller juridisk person, och banksekretessen skyddar information om transaktioner. Men vem garanterar att AnonymousWorldMoney inte använder personliga uppgifter och transaktionsinformation för sina egna syften?
2. Hur kan man vara säker på att mottagaren faktiskt har fått den summa som överförts? Låt oss säga att avsändaren skickade $100, men mottagaren fick bara $10. Avsändaren går till kontoret för AnonymousWorldMoney med sin kvitto, men expediten visar sin version där det står att avsändaren bara överförde $10.
3. Problemet med en brist på förtroende, till exempel bedrägeri som kallas double-spending. En illojal deltagare kan spendera sin saldo flera gånger innan betalningen har replikerats på alla servrar. CAP-teoremet, självklart, gäller fortfarande, och konsistens kommer slutligen att uppnås, men någon kommer inte att få pengar för de utförda tjänsterna eller varorna. Därför, om det inte finns något fullständigt förtroende för betalningsorganisationen eller deltagarna i affären, måste man bygga ett nätverk baserat på kryptografi snarare än på förtroende.
4. Det villkorliga AnonymousWorldMoney har ett begränsat antal servrar som kan bli otillgängliga av misstag eller av illvilliga avsikter.
5. AnonymousWorldMoney kommer att ta ut sin påtagliga provision.
6. Möjlighet till styrning. Under användningen av Bitcoin har det visat sig att människor inte bara vill överföra mynt till varandra, utan även kontrollera olika villkor för transaktioner, programmera arbetsflöden och automatiskt utföra åtgärder beroende på villkor osv.

Hur blockkedjan löser dessa problem

1. Identifiering av deltagare sker genom ett par nycklar: en privat och en öppen, och algoritmen för digital signatur identifierar entydigt avsändare och mottagare, vilket bevarar deras anonymitet.
2. Transaktioner samlas i block, en hash av blocket beräknas och skrivs ned i nästa block. Denna sekvens av att skriva hashar i block gav namn åt teknologin blockchain och gör det omöjligt att diskret ändra / ta bort block eller enskilda transaktioner från block. Om en transaktion har hamnat i blockkedjan kan man vara säker på att dess data förblir oförändrad.
3. Double-spending-bedrägeri förhindras genom att nå konsensus i nätverket om vilka data som ska anses som giltiga och vilka som ska avvisas. I Bitcoin-nätverket uppnås konsensus genom Proof-of-Work (PoW).
4. Tillförlitligheten i nätverkets funktion uppnås genom att blockkedjan är offentlig, där varje deltagare kan köra sin nod, få en fullständig kopia av blockkedjan och dessutom självständigt börja kontrollera transaktioner på korrekthet. Det bör noteras att moderna blockkedjor tillåter att bygga både offentliga (öppna) och privata (stängda) blockkedjor, samt använda kombinerade arrangemang.
5. Man kan inte fullt ut undgå avgifter i blockkedjan eftersom man måste betala människorna som stödjer nätverket, men behovet av avgifter bevisas så övertygande i blockkedjan att det inte finns några tvivel om dess nödvändighet.
6. Moderna blockkedjor har möjlighet att implementera affärslogik, som i blockkedjan kallas Smart Contracts. Logiken för smarta kontrakt implementeras på olika högre programspråk.

Låt oss titta närmare på dessa lösningar.

Blockkedjans arkitektur

Beståndsdelar av blockkedjan

Varje deltagare kan köra sin nod med en fullständig kopia av blockchainen (full node). Fulla noder som kan registrera transaktioner i blockchainen kallas konsensus noder (witness) eller miners (miner). Fulla noder som bara kontrollerar transaktionernas korrekthet kallas granskningsnoder (audit). Lätta klienter (light clients) lagrar inte fullständiga kopior av blockchainen utan interagerar med nätverket genom att använda fulla noder.
De flesta användare för att genomföra transaktioner använder just lätta klienter eller webplånböcker. Alla noder är kopplade till varandra. Med en sådan uppsättning element blir nätverksarkitekturen mer robust:

Transaktionens livscykel

Låt oss titta på livscykeln för en transaktion och bryta ner den i delar:

Blockchain-teknologier

Låt oss gå djupare in på tekniska lösningar och deras relationer till varandra.

Identifiering

Varje blockchain-transaktion måste signeras med en digital signatur. Därför måste varje deltagare ha ett nyckelpar för att genomföra en transaktion: privat / offentlig. Ibland kallas nyckelparet en plånbok (wallet), eftersom nycklarna är entydigt kopplade till en unik digital adress och deltagarens saldo. I praktiken är nycklar och adresser bara strängar av siffror i olika talsystem. Exempel på nycklar och plånboksadress:

Privat nyckel: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Offentlig nyckel: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Adress: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

För att skapa en digital signatur i blockchain används en algoritm baserad på elliptiska kurvor: Elliptic Curve Digital Signature Algorithm (ECDSA). För dess funktion används vanligtvis den privata nyckeln (ett 256-bitars tal) som tas slumpmässigt. Antalet möjliga nycklar är 2 upphöjt till 256, så man kan tala om praktiskt taget omöjlighet till kollisioner av värden på privata nycklar.

Därefter erhålls den offentliga nyckeln från den privata genom att multiplicera dess värde med koordinaterna för en punkt som ligger på den elliptiska kurvan, vilket resulterar i koordinaterna för en ny punkt på samma kurva. Denna åtgärd garanterar att man får ett nyckelpar som är lämpligt för digital signering av transaktioner. Och slutligen beräknas plånboksadressen entydigt från den offentliga nyckeln.

Det finns många artiklar med detaljer om kryptografi som används i blockchain, till exempel: Bitcoin in a nutshell — Kryptografi

Den privata nyckeln måste hållas strikt hemlig och förvaras säkert. Den offentliga nyckeln är känd för alla. Vid förlust av den privata nyckeln går det inte att återfå tillgången (valutan) och pengarna kommer att gå förlorade för alltid. Därför är uppgiften att på ett pålitligt sätt lagra de privata nycklarna mycket aktuell, eftersom det inte är en bank där man alltid kan gå med sitt ID och återfå sitt konto. Det finns en hel industri som tillverkar så kallade kalla kryptovaluta-plånböcker som liknar USB-minnen:

eller så kan man använda mer pålitliga metoder, som exempelvis att ingraverad värdet av den privata nyckeln på token:

Transaktioner

Mer om transaktionsstrukturen kan man läsa i artikeln Bitcoin i ett nötskal — Transaktion. Det är viktigt att förstå att varje transaktion har åtminstone följande data:

Från: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - avsändarens digitala adress
Till: 0x367adb7894334678b90aFe7882a5b06f7fbc783a - mottagarens digitala adress
Värde: 0.0001 - transaktionsbelopp
Transaktionshash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - transaktionshash

Därefter signeras transaktionen med den privata nyckeln och skickas till (se detaljer om protokollets funktion Bitcoin i ett nötskal - Protokoll) alla noder i blockchainen som kontrollerar transaktioner på deras giltighet. Algoritmen för att verifiera transaktionen är inte trivial och inkluderar ett tiotal steg.

Transaktionsblock

Efter att ha verifierat transaktionernas giltighet skapar noderna block av dem. Förutom transaktioner registreras även hash av det föregående blocket, ett nummer (nonce-räknare) och hash av det aktuella blocket beräknas enligt SHA-256-algoritmen. Hashen måste uppfylla vissa svårighetsvillkor. Till exempel justeras hashens svårighet automatiskt varannan vecka i Bitcoin-nätverket beroende på nätverkets kraft så att ett block genereras ungefär var tionde minut. Svårighetsgraden definieras av följande villkor: den funna hash måste vara mindre än ett förutbestämt nummer. Om detta villkor inte är uppfyllt läggs 1 till nonce, och arbetet med att beräkna hash upprepas. För att hitta hash används nonce-fältet, eftersom det är de enda data i blocket som kan ändras, medan övriga måste förbli oförändrade. Den korrekta hashen måste ha ett visst antal nollor i början, till exempel en av de verkliga hasharna:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Ett framgångsrikt hashande är beviset på det arbete som utförts (Proof-of-Work, PoW) för Bitcoin- eller Ethereum-nätverk. Processen för att hitta hashes kallas mining, i likhet med guldutvinning. Namnet beskriver ganska exakt essensen av processen, eftersom det handlar om en enkel bris av alternativ, och om någon finner en lämplig hash är det verkligen en tur. Det är som att hitta en verklig guldklimp i ton av grus. Belöningen för en block är nu 12,5 BTC och om man multiplicerar det med det aktuella bitcoinpriset på $3900, så blir det mer än ett kilogram rent guld. Det finns något att kämpa för!

Efter att en hash har hittats sparas blocket och den funna hashen i blockkedjan med nästa block. För mer information om strukturen av blocken kan du kolla in artikeln Bitcoin i ett nötskal - Blockchain, och nedan kommer jag att visa ett förenklat schema:

Blockkedjan börjar med ett block som ännu inte har en hash av föregående block. Ett sådant block is ensamt i blockkedjan och har ett eget namn, Genesis block. De övriga blocken har samma struktur och skiljer sig endast åt i antal transaktioner. Riktiga transaktioner och block som för närvarande skapas i Bitcoin eller Ethereum kan ses i Block Explorer.

Blockstorleken i Bitcoin är begränsad till 1 Mb och med en minimal mängd information i en transaktion på cirka 200 bytes kan det maximalt finnas cirka 6000 transaktioner i ett block. Detta förklarar för övrigt varför många skrattar åt Bitcoins prestanda: ett block genereras ungefär var 10:e minut * 60 sek = 600 sekunder, vilket ger en formell kapacitet på cirka 10 TPS. Men egentligen är detta inte prestanda, utan en medvetet implementerad arbetsalgoritm. För att konkurrera har Ethereum helt enkelt gjort blockgenereringstiden 15 sekunder., vilket formellt ökar prestandan. Därför är det överhuvudtaget meningslöst att jämföra prestanda i blockkedjor som använder PoW som konsensus, eftersom det direkt beror på svårighetsgraden av hashberäkning, som kan sättas till valfritt värde.

Forks

Vad händer om, till exempel, flera noder hittar hashvärden som uppfyller svårighetsvillkoren, men har olika värden (med andra ord, de kommer fram till olika konsensus och registrerar block i blockkedjan)? Låt oss se hur blockkedjan skyddar sig mot denna situation. I detta fall uppstår så kallad fork ('gaffel'), och blockkedjan har två versioner av kedjan:

Vad händer sedan? Därefter börjar en del av nätverket arbeta med block N+2 från en kedja, och en del från en annan:

Något av dessa block kommer att hittas tidigare och skickas till blockkedjan, och då måste blockkedjan enligt reglerna växla till den längre kedjan och avbryta alla transaktioner från det alternativa blocket:

Det kan ske en situation där en deltagares transaktion fanns endast i ett av blocken i forks, som sedan blev avbrutet. Därför, för att vara säker på att den nödvändiga transaktionen har registrerats i blockkedjan, finns det en allmän rekommendation — innan man litar på en transaktion bör man vänta tills några följande block har lagts till i blockkedjan. Rekommendationerna för hur många block man bör vänta varierar för olika blockkedjor. Till exempel, för Bitcoin-nätverket är minimum 2 block, maximum 6.

Samma bild med blockforkar kommer att observeras vid den så kallade 51%-attaken — det är när en grupp minerare försöker växa en alternativ kedja av block, och sträva efter att avbryta kedjan med sina bedrägliga transaktioner. Även om det för närvarande, istället för bedrägeri, är lönsammare att använda sina resurser för ärlig mining.

Konsensus

För att registrera ett block i blockkedjan måste nätverket komma till konsensus. Låt oss återkalla uppgiften att uppnå konsensus i datorsystem och nätverk. Problemet formuleras som en byzantinsk generals BFT-uppgift (Byzantine fault tolerance). Utan att gå in på den färgstarka beskrivningen av problemen med den byzantinska armén kan uppgiften formuleras så här: hur kan noder i nätverket komma fram till ett gemensamt resultat om en del av noderna medvetet kan förvränga dem? De befintliga algoritmerna för att lösa BFT-uppgiften visar att nätverket kan fungera korrekt om bedragarna är mindre än 1/3. Varför tillämpades inte BFT-konsensus i Bitcoin-nätverket? Varför var det nödvändigt att använda PoW? Det finns flera skäl:

• BFT fungerar bra med en liten fast uppsättning noder, men i en offentlig blockchain är antalet noder oförutsägbart och dessutom kan noder slås på och av godtyckligt.
• Det är nödvändigt att motivera människor att köra blockchain-noder. För detta måste människor få belöningar. I BFT finns det formellt inget som man får belöning för, men i PoW är det uppenbart på ett intuitivt plan vad belöningen är för: den elektricitet som processorn förbrukar i jakten på blockets hash.

Förutom PoW finns det flera andra konsensusmekanismer som används i moderna blockchains, till exempel:

• PoS (Proof-of-Stake) — i blockchain Hyperledger
• DPoS (Delegated Proof-of-Stake) — i blockchain BitShares
• Modifieringar av BFT: SBFT (Simplified BFT) och PBFT (Practical BFT), till exempel i blockchain Exonum

Låt oss stanna upp vid PoS-konsensus, eftersom just PoS och dess varianter har fått störst spridning i privata blockchains. Varför just i privata? Å ena sidan är egenskaperna hos PoS bättre jämfört med PoW, eftersom mindre datorkraft krävs för att uppnå konsensus, vilket ökar hastigheten på dataskrivning i blockchain. Men å andra sidan finns det fler möjligheter till bedrägeri i PoS, så för att neutralisera detta måste alla deltagare i blockchain vara kända.

PoS-konsensus är baserat på valet av en nod som kan skriva ett block med transaktioner i blockchain beroende på mängden medel på kontot, snarare, inte på kontot, utan i säkerhet. Det vill säga ju fler medel du har i säkerhet, desto mer sannolikt är det att nätverket väljer din nod för att skriva blocket. Säkerheten återbetalas inte om blocket visar sig vara ogiltigt. På så sätt implementeras skydd mot bedrägeri. Det finns följande variationer av PoS:

• Delegated PoS (DPoS) konsensus delar upp deltagarna i "röstande" och "validerande". Innehavare av mynt (röstande deltagare) delegerar sin rätt att kontrollera och skriva transaktioner i blockchain till andra deltagare. Således utför validerarna allt beräkningsarbete och får betalt för det, medan närvaron av röstande deltagare garanterar validerarnas ärlighet, eftersom de kan bytas ut när som helst.
• LPoS (Leased Proof-of-Stake) konsensus gör att du kan hyra ut dina medel till andra noder, vilket ökar deras chans att verifiera block. På så sätt kan du tjäna provision för transaktioner utan att delta i själva verifieringen av transaktioner och blockmining.

Det finns flera andra konsensusmetoder som ännu inte har fått något brett genomslag, jag nämner dem här för information, och en översikt över själva konsensusalgoritmer kan ses, till exempel i artikeln: Konsensusalgoritmer i Blockchain.

• PoET (Proof-of-Elapsed Time)
• PoC (Proof-of-Capacity)
• PoB (Proof-of-Burn)
• PoWeight (Proof-of-Weight)
• PoA (Proof-of-Activity) — PoW + PoS
• PoI (Proof-of-Importance)

Tillförlitlighet och modeller för blockchain-distribution

Offentlig blockchain

Beständighet Public eller ett annat namn Permissionless blockchain nått genom att vem som helst kan ansluta och se information eller till och med koppla sin egen nod, medan tillit byggs på PoW-konsensus.

Privat blockchain

Private eller Private Permissioned blockchain. I dessa blockkedjor har endast en särskild grupp deltagare (organisationer eller individer) tillgång till informationen. Sådana blockkedjor byggs av organisationer för att öka den totala nyttan eller effektiviteten. Deras tillförlitlighet säkerställs av gemensamma mål för deltagarna och konsensusalgoritmerna PoS och BFT.

Blockchain-konsortium

Det finns Consortium eller Public Permissioned blockchain. Det är sådana blockkedjor som vem som helst kan ansluta sig till för att se, men att lägga till information eller koppla sin nod kan deltagare endast göra med tillstånd från andra deltagare. Sådana blockkedjor byggs av organisationer för att öka tilliten från kunder eller konsumenter av produkter eller samhället i stort. Här säkerställs tillförlitligheten också genom förekomsten av förtroende mellan deltagarna och samma konsensusalgoritmer som PoS och BFT.

Smart Contracts

I blockkedjor som implementerades efter Bitcoin har möjligheten att utföra smarta kontrakt lagts till i olika grad. I sin kärna är ett smart kontrakt en transaktion där programkod för utförande är inkluderad. Smarta kontrakt i Ethereum-nätverket körs i EVM (Ethereum Virtual Machine). För att ett smart kontrakt ska börja utföras måste det i tydligt startas av en annan transaktion, eller så måste vissa förutsättningar uppfyllas för att det ska kunna genomföras. Resultaten av ett smart kontrakts utförande registreras också i blockkedjan. Att hämta data utanför blockkedjan är möjligt, men mycket begränsat.

Vilken affärslogik kan implementeras med hjälp av smarta kontrakt? Egentligen inte så mycket, till exempel kontroll av villkor baserat på data från blockkedjan, ändring av ägare av digitala tillgångar beroende på dessa villkor, samt registrering av data i en permanent lagring inom blockkedjan. Logiken implementeras på ett speciellt högnivå-språk, Solidity.

Ett klassiskt exempel på funktionalitet som implementeras med hjälp av smarta kontrakt är utfärdandet av tokens för att genomföra ICO. Till exempel har jag implementerat ett smart kontrakt för att utfärda blygsamma 500 000 000 AlexToken. Genom länken i Etherscan en grupp patent som inkluderar några av de tidigaste omnämnandena av teknologier för att skapa dynamiskt webbinnehåll, som föregick introduktionen av system som ASP från Microsoft, JSP från Sun/Oracle och PHP. En annan betydande bidrag är

källkoden för smarta kontraktet 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;
}

och det binära representationssättet som nätverket ser det

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Mer information om smarta kontrakt kan du hitta i artikeln: Vad är smarta kontrakt i Ethereum.

Slutsats

Vi har listat de teknologier som moderna blockkedjor bygger på och hur de hänger ihop. Låt oss nu formulera vilka problem som kan lösas med hjälp av blockkedjan, och vilka det i bästa fall skulle vara ineffektivt att lösa. Så, användningen av blockkedjan är inte nödvändig om:

• Transaktioner genomförs i en betrodd miljö;
• Närvaron av kommission från mellanhänder försämrar inte livet för deltagarna;
• Deltagarna har ingen egendom som kan representeras som digitala tillgångar;
• Det finns ingen fördelning av digitala tillgångar, det vill säga värdet ägs eller tillhandahålls endast av en deltagare.

Vilken framtid väntar blockkedjan? Just nu kan vi endast spekulera om de möjliga utvecklingsvägarna för blockkedjeteknologier:

• Blockkedjan kommer att bli en lika vanlig databas som till exempel SQL eller NoSQL för att lösa sina specifika problem;
• Blockkedjan kommer att bli en allmänt spridd protokoll, likt HTTP för Internet;
• Blockkedjan kommer att vara grunden för ett nytt finansiellt och politiskt system på planeten!

I nästa del kommer vi att titta på vilka blockkedjor som finns just nu och hur de används inom olika industrier.

Detta är bara början!

Källa: habr.com