Hvad skal vi bygge en blockchain?

Hele menneskehedens historie er en kontinuerlig proces med at slippe af med kæder og skabe nye, endnu stærkere. (Anonym forfatter)

Ved at analysere adskillige blockchain-projekter (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin osv.), forstår jeg, at fra et teknisk synspunkt er de alle bygget på de samme principper. Blockchains minder om huse, som på trods af al variation af design, indretning og formål har et fundament, vægge, tag, vinduer, døre, der er forbundet med hinanden på bestemte måder. Og hvis du forstår de grundlæggende principper for bygningsdesign og kender egenskaberne af de anvendte materialer, så kan du bestemme formålet med et bestemt hus. I øjeblikket er der opstået en situation med blockchain, som alle har hørt om det, men få mennesker forstår arkitekturen og principperne for driften. Derfor er der en misforståelse af, hvorfor og hvordan det giver mening at bruge blockchain-teknologier.

I denne artikel vil vi analysere de egenskaber og principper, der er fælles for alle blockchains. Lad os derefter se på de problemer, der kan løses ved hjælp af blockchain, og for at forstærke materialet, lad os bygge en lille, men ægte blockchain på vores virtuelle websted!

Så lad os huske, hvilke problemer blockchain oprindeligt løste.

Jeg er sikker på, at mange vil sige om en distribueret, decentraliseret, offentlig og uforanderlig database. Men hvorfor var alt dette nødvendigt?

Jeg foretrækker at begynde at studere enhver teknologi ved at læse standarderne, da alle artikler og bøger om det emne, der undersøges, er baseret på dem. Men der er i øjeblikket ingen blockchain-standarder; ISO har kun skabt udvalg for deres udvikling. I øjeblikket har hvert offentligt blockchain-projekt sit eget hvidbogsdokument, som i det væsentlige er en teknisk specifikation. Det første offentligt kendte blockchain-projekt er Bitcoin-netværket. Gå til netværkets officielle hjemmeside og se hvor det hele begyndte.

Blockchain udfordring

Så opgaven, som blockchain løste i Bitcoin-pionernetværket, er at udføre en betroet overførsel af ejerskab af digitale aktiver (aktiver) i et ikke-betroet miljø uden mellemmænd. For eksempel i Bitcoin-netværket er et digitalt aktiv bitcoin digitale mønter. Og alle tekniske løsninger af Bitcoin og andre blockchains handler om at løse dette problem.

Problemer, som blockchain løser

Antag, at en bestemt finansiel organisation siger, at den har opbygget et netværk rundt om i verden, ved hjælp af hvilket det er muligt at overføre penge til enhver person. Vil du tro hende? Hvis denne organisation er Visa eller MasterCard, vil du højst sandsynligt tro det, men hvis, relativt set, AnonymousWorldMoney, vil du sandsynligvis ikke. Hvorfor? Men fordi vi godt ved, hvordan distribuerede systemer laves af private virksomheder, til hvilke formål, og hvad det kan føre til. Lad os se nærmere på problemerne med sådanne systemer, og hvordan de kan løses ved hjælp af blockchain-teknologier.

Lad os sige, at der i de betingede AnonymousWorldMoney er servere med databaser, og det er godt, hvis der er flere af dem i forskellige datacentre. Når afsenderen overfører penge, registreres en transaktion, som replikeres til alle servere, og pengene kommer frem til modtageren.

I en ideel verden fungerer denne ordning godt, men i vores opstår følgende problemer:

1. Problemet med at identificere deltagere på den ene side og behovet for anonymitet af transaktioner på den anden side. De der. du skal overføre penge til en bestemt modtager og på en sådan måde, at ingen kender til denne transaktion undtagen deltagerne i transaktionen. Banker har kontonumre og bankkort knyttet til en bestemt person eller juridisk enhed, og bankhemmeligheden beskytter transaktionsoplysninger. Og hvem garanterer, at de betingede AnonymousWorldMoney ikke bruger personlige data og transaktionsoplysninger til sine egne formål?
2. Hvordan sikrer man sig, at modtageren modtog præcis det beløb, der blev overført til ham? Relativt set overførte afsenderen $100, og modtageren modtog $10. Afsenderen kommer til AnonymousWorldMoney-kontoret med sin kvittering, og ekspedienten viser sin version, hvor det står skrevet, at afsenderen kun har overført $10.
3. Problemet med et miljø, der ikke er tillid til, for eksempel en fidus kaldet dobbeltudgifter. En skruppelløs deltager kan bruge sin saldo flere gange, indtil betalingen er replikeret til alle servere. CAP-sætning, selvfølgelig, ingen annulleret, og enighed vil i sidste ende blive opnået, men nogen vil ikke modtage penge for tjenester eller leverede varer. Derfor, hvis der ikke er fuldstændig tillid til betalingsorganisationen eller deltagere i transaktioner, så er det nødvendigt at bygge et netværk baseret ikke på tillid, men på kryptografi.
4. Betingede AnonymousWorldMoney har et begrænset antal servere, der kan blive utilgængelige utilsigtet eller på grund af ondsindet hensigt.
5. AnonymousWorldMoney vil tage sin egen håndgribelige provision.
6. Mulighed for kontrol. Under driften af ​​Bitcoin viste det sig, at folk ikke kun ønsker at overføre mønter til hinanden, men også at kontrollere forskellige betingelser for transaktionen, programmere arbejdsscenarier, automatisk udføre handlinger afhængigt af betingelserne osv.

Hvordan blockchain løser disse problemer

1. Identifikation af deltagere udføres ved hjælp af et par nøgler: private og offentlige, og den digitale signaturalgoritme identificerer entydigt afsender og modtager og efterlader deres identitet anonyme.
2. Transaktioner samles i blokke, blokkens hash beregnes og skrives ind i næste blok. Denne sekvens af optagelse af hashes i blokke giver blockchain-teknologien sit navn, og den gør det også umuligt umærkeligt at ændre/slette blokke eller individuelle transaktioner fra blokke. Hvis en transaktion er inkluderet i blockchainen, kan du således være sikker på, at dens data forbliver uændret.
3. Svindel med dobbeltforbrug forhindres ved at opnå en netværkskonsensus om, hvilke data der skal anses for gyldige, og hvilke der skal kasseres. I Bitcoin-netværket opnås konsensus ved proof of work (PoW).
4. Netværkets pålidelighed opnås ved, at blockchain er offentlig, hvor hver deltager kan køre deres egen node, modtage en komplet kopi af blockchain og desuden selvstændigt begynde at kontrollere transaktioner for rigtighed. Det skal bemærkes, at moderne blockchains gør det muligt at bygge ikke kun offentlige (åbne), men også private (lukkede) blockchains samt brugen af ​​kombinerede ordninger.
5. Blockchain slipper ikke helt for provisioner, fordi... du skal betale de mennesker, der støtter netværket, men i blockchain er behovet for en kommission bevist så overbevisende, at der ikke er nogen tvivl om nødvendigheden.
6. Moderne blockchains har mulighed for at implementere forretningslogik, som i blockchainen kaldes Smart Contracts. Logikken i smarte kontrakter er implementeret i forskellige sprog på højt niveau.

Dernæst vil vi overveje disse løsninger mere detaljeret.

Blockchain arkitektur

Blockchain-komponenter

Hver deltager kan starte deres egen node med en fuld kopi af blockchain (fuld node). Fuld noder, der kan registrere transaktioner på blockchain, kaldes konsensus noder (vidne) eller minearbejdere (minearbejder). Fuld noder, der kun kontrollerer transaktionernes rigtighed kaldes revisionsknudepunkter (revidere). Lette kunder (lette klienter) gemmer ikke fulde kopier af blockchain, men interagerer med netværket ved hjælp af fulde noder.
De fleste brugere bruger lette klienter eller web-wallets til at foretage transaktioner. Alle noder er forbundet med hinanden. Med dette sæt af elementer bliver netværksarkitekturen mere stabil:

Transaktionens livscyklus

Lad os se på transaktionens livscyklus og opdele den stykke for stykke:

Blockchain-teknologier

Lad os dvæle mere detaljeret ved tekniske løsninger og deres forbindelser med hinanden.

identifikation

Hver blockchain-transaktion skal signeres digitalt. For at gennemføre en transaktion skal hver deltager derfor have et nøglepar: privat / offentligt. Nogle gange kaldes et par nøgler for en pung, fordi nøglerne er unikt forbundet med deltagerens unikke digitale adresse og balance. I virkeligheden er nøgler og adresser blot rækker af tal i forskellige talsystemer. Eksempler på nøgler og tegnebogsadresser:

Private key: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Public key: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Address: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

For at skabe en digital signatur i blockchains bruges en algoritme baseret på elliptiske kurver: Elliptic Curve Digital Signature Algorithm (ECDSA). For at det skal virke, tages den private nøgle (256-bit nummer) normalt tilfældigt. Antallet af nøglemuligheder er 2 til 256, så vi kan tale om den praktiske umulighed af at matche værdierne af private nøgler.

Dernæst opnås den offentlige nøgle fra den private ved at gange dens værdi med koordinaterne for et punkt placeret på den elliptiske kurve, hvilket resulterer i koordinaterne for et nyt punkt på den samme kurve. Denne handling sikrer, at du får et nøglepar, der er egnet til digital signering af transaktioner. Endelig er tegnebogens adresse entydigt afledt af den offentlige nøgle.

Der er mange artikler med detaljer om den kryptografi, der bruges i blockchain, for eksempel: Bitcoin i en nøddeskal – Kryptografi

Den private nøgle skal være strengt fortrolig og opbevares sikkert. Den offentlige nøgle er kendt af alle. Hvis den private nøgle går tabt, kan adgangen til aktivet (mønter) ikke genoprettes, og pengene vil være tabt for altid. Derfor er opgaven med sikker opbevaring af private nøgler yderst relevant, pga Dette er ikke en bank, hvor du altid kan komme med dit pas og gendanne din konto. Der er en hel industri for produktion af såkaldte kolde krypto-punge, der ligner flashdrev:

eller du kan bruge mere pålidelige metoder, for eksempel at stemple værdien af ​​den private nøgle på tokens:

Transaktion

Flere detaljer om transaktionsstrukturen kan findes i artiklen Bitcoin i en nøddeskal – Transaktion. Det er vigtigt for os at forstå, at hver transaktion har mindst følgende data:

From: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - цифровой адрес отправителя
To: 0x367adb7894334678b90аfe7882a5b06f7fbc783a - цифровой адрес получателя
Value: 0.0001 - сумма транзакции
Transaction Hash: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - хэш транзакции

Derefter signeres transaktionen med en privat nøgle og sendes ud (se detaljer om protokollens funktion Bitcoin i en nøddeskal-protokol) til alle noder i blockchain, der kontrollerer transaktioner for gyldighed. Transaktionsbekræftelsesalgoritmen er ikke-triviel og inkluderer to dusin trin.

Transaktionsblokke

Efter at have kontrolleret gyldigheden af ​​transaktioner danner noder blokke fra dem. Ud over transaktioner skrives hashen af ​​den foregående blok og et tal (Nonce counter) ind i blokken, og hashen for den aktuelle blok beregnes ved hjælp af SHA-256 algoritmen. Hashen skal have etableret kompleksitetsbetingelser. For eksempel i Bitcoin-netværket ændres hashens sværhedsgrad automatisk hver 2. uge afhængigt af netværkets styrke, så der genereres en blokering cirka en gang hvert 10. minut. Kompleksiteten bestemmes af følgende betingelse: den fundne hash skal være mindre end et forudbestemt tal. Hvis denne betingelse ikke er opfyldt, tilføjes 1 til Nonce, og arbejdet med at beregne hashen gentages. For at vælge en hash bruges feltet Nonce, fordi Dette er de eneste data i blokken, der kan ændres; resten skal forblive uændret. En gyldig hash skal have et vist antal foranstillede nuller, såsom en af ​​de rigtige hashes:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

At finde en hash er et bevis på det udførte arbejde (Proof-of-Work, PoW) for Bitcoin- eller Ethereum-netværkene. Processen med at finde hash kaldes minedrift, svarende til guldminedrift. Navnet definerer ganske præcist essensen af ​​processen, fordi der er en simpel søgning af muligheder, og hvis nogen finder en passende hash, så er dette virkelig held. Det er som at finde en rigtig guldklump i tonsvis af gråsten. Blokbelønningen er nu 12.5 BTC, og hvis du multiplicerer den med den nuværende Bitcoin-kurs på $3900, får du mere end et kilogram rent guld. Der er noget at kæmpe for!

Efter at have fundet en hash, bliver blokken og selve den fundne hash skrevet til blockchain som den næste blok. Flere detaljer om strukturen af ​​blokke kan findes i artiklen Bitcoin i en nøddeskal - Blockchain, og nedenfor er et forenklet diagram:

Blockchain starter med en blok, der endnu ikke har hashen fra den forrige blok. Der er kun én sådan blok i blockchain og har sit eget navn Genesis block. De resterende blokke har samme struktur og adskiller sig kun i antallet af transaktioner. Reelle transaktioner og blokke, der i øjeblikket oprettes i Bitcoin eller Ethereum, kan ses i Block Explorer.

Størrelsen af ​​blokke i Bitcoin er begrænset til 1MB og med en minimumsmængde af information i en transaktion på omkring 200 bytes, kan det maksimale antal transaktioner i en blok være omkring 6000. Herfra følger i øvrigt Bitcoins ydeevne, som alle griner af: der genereres en blok cirka en gang hvert 10. minut * 60 sekunder = 600 sekunder, hvilket giver en formel performance på omkring 10 TPS. Selvom det faktisk ikke er produktivitet, men en bevidst implementeret arbejdsalgoritme. I Ethereum, for konkurrence, gjorde de simpelthen blokgenereringstiden til 15 sekunder. og produktiviteten steg formelt. Derfor giver det ingen mening i blockchains, der bruger PoW som konsensus, overhovedet at sammenligne ydeevne, fordi det afhænger direkte af kompleksiteten af ​​cacheberegningen, som kan tildeles enhver værdi.

Forgafler

Hvad sker der, hvis f.eks. flere noder fandt hashes, der opfylder kompleksitetsbetingelserne, men er forskellige i værdi (med andre ord kom de til forskellig konsensus) og skrev blokke til blockchainen? Lad os se, hvordan blockchain beskytter mod denne situation. I dette tilfælde opstår der en såkaldt gaffel, og blockchainen har to versioner af kæden:

Hvad sker der nu? Dernæst begynder en del af netværket at arbejde på blok N+2 fra en kæde og en del fra en anden:

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

Samtidig kan der opstå en situation, hvor en deltagers transaktion kun var i en af ​​gaffelblokkene, som blev annulleret. For at være sikker på, at den ønskede transaktion er registreret i blockchainen, er der derfor en generel anbefaling – før du stoler på transaktionen, bør du vente til de næste par blokke er tilføjet blockchainen. Anbefalinger for, hvor mange blokke der skal vente på forskellige blockchains varierer. For eksempel, for Bitcoin-netværket er minimum 2 blokke, maksimum er 6.

Det samme billede med blokgafler vil blive observeret under det såkaldte 51%-angreb - det er, når en gruppe minearbejdere forsøger at udvikle en alternativ blokkæde, der søger at annullere kæden med deres svigagtige transaktioner. Selvom det på nuværende tidspunkt i stedet for svindel er mere rentabelt at bruge din magt på ærlig minedrift.

Konsensus

For at optage en blok på blockchain skal netværket nå til enighed. Lad os huske opgaven med at opnå konsensus i computerkommunikationsnetværk. Problemstillingen er formuleret som opgaven for de byzantinske generaler BFT (Byzantinsk fejltolerance). Hvis man udelader den maleriske beskrivelse af den byzantinske hærs problemer, kan problemet formuleres som følger: hvordan kan netværksknuder komme til et fælles resultat, hvis nogle netværksknuder bevidst kan forvrænge dem. Eksisterende algoritmer til at løse BFT-problemet viser, at netværket kan fungere korrekt, hvis der er mindre end 1/3 af svindlerne. Hvorfor er BFT-konsensus ikke blevet anvendt på Bitcoin-netværket? Hvorfor var det nødvendigt at bruge PoW? Der er flere grunde:

• BFT fungerer godt med et lille fast sæt af noder, men i en offentlig blockchain er antallet af noder uforudsigeligt, og desuden kan noder tændes og slukkes tilfældigt.
• Det er nødvendigt at motivere folk til at lancere blockchain noder. For at gøre dette skal folk belønnes. I BFT er der formelt ikke noget at modtage en belønning for, men hvad belønningen er for i PoW er klart for enhver på et intuitivt niveau: for den elektricitet, som processoren bruger i processen med at finde blokhashen.

Ud over PoW er der flere andre konsensus, der bruges i moderne blockchains, for eksempel:

• PoS (Proof-of-Stake) - på blockchain Hyperledger
• DPoS (Delegated Proof-of-Stake) - på blockchain BitShares
• Ændringer af BFT: SBFT (Simplified BFT) og PBFT (Praktisk BFT), for eksempel i blockchain Exonum

Lad os dvæle lidt ved PoS-konsensus, fordi... Det er PoS og dets varianter, der er mest udbredt i private blockchains. Hvorfor privat? På den ene side er egenskaberne ved PoS bedre sammenlignet med PoW, fordi For at opnå konsensus er der behov for færre computerressourcer, hvilket betyder, at hastigheden på at skrive data til blockchain stiger. Men på den anden side har PoS flere muligheder for svindel, så for at neutralisere dette, skal alle deltagere i blockchainen kendes.

PoS-konsensus er baseret på valget af en node, der kan skrive en blok med transaktioner til blockchain afhængigt af mængden af ​​midler på kontoen, eller rettere sagt, ikke på kontoen, men i sikkerhedsstillelsen, dvs. Jo flere midler du har som sikkerhed, jo mere sandsynligt vil netværket vælge din node til at skrive en blokering. Depositummet returneres ikke, hvis spærringen er ugyldig. Dette giver beskyttelse mod svindel. Der er følgende variationer af PoS:

• Den Delegerede PoS (DPoS) konsensus opdeler deltagerne i "vælgere" og "validatorer". Møntindehavere (deltagere med stemmeret) delegerer deres beføjelser til at verificere og registrere transaktioner på blockchain til andre deltagere. Validatorer udfører således alt beregningsarbejdet og modtager en belønning for det, og tilstedeværelsen af ​​stemmedeltagere garanterer validatorernes ærlighed, fordi de kan ændres til enhver tid.
• LPoS (Leased Proof-of-Stake) konsensus giver dig mulighed for at lease dine midler til andre noder, så de har en bedre chance for at validere blokke. At. Du kan modtage en provision for transaktioner uden at deltage i selve transaktionsbekræftelsen og blokere mining.

Der er en række andre konsensuser, som endnu ikke er udbredt, jeg vil blot liste dem her for information, og en oversigt over selve konsensusalgoritmerne kan f.eks. findes i artiklen: Konsensusalgoritmer i Blockchain.

• PoET (Proof-of-Elapsed Time)
• PoC (Proof-of-Capacity)
• PoB (Proof-of-Brænd)
• PoWeight (Proof-of-Weight)
• PoA (Proof-of-Activity) – PoW + PoS
• PoI (Proof-of-Importans)

Pålidelighed og implementeringsmodeller af blockchains

Offentlig blockchain

stabilitet offentlige eller et andet navn Tilladelsesfri blockchain Dette opnås ved at give enhver mulighed for at forbinde og se information eller endda forbinde deres egen node, og tillid er bygget på PoW-konsensus.

Privat blockchain

Privat eller Privat tilladt blockchain. I disse blockchains har kun en bestemt gruppe deltagere (organisationer eller personer) adgang til information. Sådanne blockchains er bygget af organisationer med det mål at øge den samlede fordel eller effektivitet. Deres pålidelighed er sikret af deltagernes fælles mål og PoS- og BFT-konsensusalgoritmerne.

Blockchain konsortium

der Consortium eller Offentligt godkendt blockchain. Disse er blockchains, som alle kan oprette forbindelse til for at se, men en deltager kan kun tilføje information eller forbinde sin node med tilladelse fra andre deltagere. Sådanne blockchains er bygget af organisationer for at øge tilliden hos kunder eller forbrugere af produkter eller samfundet som helhed. Her opnås pålidelighed også ved tilstedeværelsen af ​​tillid mellem deltagere og de samme PoS- og BFT-konsensusalgoritmer.

Smarte kontrakter

Blockchains implementeret efter Bitcoin har i en eller anden grad tilføjet muligheden for at udføre smarte kontrakter. Grundlæggende er en smart kontrakt en transaktion, hvor programkoden placeres til udførelse. Smarte kontrakter på Ethereum-netværket udføres i EVM (Ethereum Virtual Machine). For at begynde at eksekvere en smart kontrakt skal den eksplicit lanceres af en anden transaktion, eller forudsætningerne for eksekvering skal være opfyldt. Resultaterne af udførelsen af ​​den smarte kontrakt vil også blive registreret i blockchain. Modtagelse af data uden for blockchain er muligt, men ekstremt begrænset.

Hvilken forretningslogik kan implementeres ved hjælp af en smart kontrakt? Faktisk er der ikke meget, for eksempel kontrol af forhold ved hjælp af data fra blockchain, ændring af ejere af digitale aktiver afhængigt af disse forhold, registrering af data i et permanent lager i blockchain. Logikken er implementeret i et særligt højniveau sprog Solidity.

Et klassisk eksempel på funktionalitet, der er implementeret ved hjælp af smarte kontrakter, er udstedelse af tokens til ICO'er. For eksempel implementerede jeg en smart kontrakt for at udstede beskedne 500 AlexToken. Ved link i Etherscan er

kildekoden til den smarte kontrakt på Solidity-sproget

pragma solidity ^0.4.23;
library SafeMath {
/**
* @dev Multiplies two numbers, throws on overflow.
**/
function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
if (a == 0) {
return 0;
}
c = a * b;
assert(c / a == b);
return c;
}
/**
* @dev Integer division of two numbers, truncating the quotient.
**/
function div(uint256 a, uint256 b) internal pure returns (uint256) {
// assert(b > 0); // Solidity automatically throws when dividing by 0
/**
* @title SafeMath
* @dev Math operations with safety checks that throw on error
*/
// uint256 c = a / b;
// assert(a == b * c + a % b); // There is no case in which this doesn't hold
return a / b;
}
/**
* @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
**/
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
assert(b <= a);
return a - b;
}
/**
* @dev Adds two numbers, throws on overflow.
**/
function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
c = a + b;
assert(c >= a);
return c;
}
}
/**
* @title Ownable
* @dev The Ownable contract has an owner address, and provides basic authorization control
* functions, this simplifies the implementation of "user permissions".
**/
contract Ownable {
address public owner;
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
/**
* @dev The Ownable constructor sets the original `owner` of the contract to the sender account.
**/
constructor() public {
owner = msg.sender;
}
/**
* @dev Throws if called by any account other than the owner.
**/
modifier onlyOwner() {
require(msg.sender == owner);
_;
}
/**
* @dev Allows the current owner to transfer control of the contract to a newOwner.
* @param newOwner The address to transfer ownership to.
**/
function transferOwnership(address newOwner) public onlyOwner {
require(newOwner != address(0));
emit OwnershipTransferred(owner, newOwner);
owner = newOwner;
}
}
/**
* @title ERC20Basic interface
* @dev Basic ERC20 interface
**/
contract ERC20Basic {
function totalSupply() public view returns (uint256);
function balanceOf(address who) public view returns (uint256);
function transfer(address to, uint256 value) public returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
}
/**
* @title ERC20 interface
* @dev see https://github.com/ethereum/EIPs/issues/20
**/
contract ERC20 is ERC20Basic {
function allowance(address owner, address spender) public view returns (uint256);
function transferFrom(address from, address to, uint256 value) public returns (bool);
function approve(address spender, uint256 value) public returns (bool);
event Approval(address indexed owner, address indexed spender, uint256 value);
}
/**
* @title Basic token
* @dev Basic version of StandardToken, with no allowances.
**/
contract BasicToken is ERC20Basic {
using SafeMath for uint256;
mapping(address => uint256) balances;
uint256 totalSupply_;
/**
* @dev total number of tokens in existence
**/
function totalSupply() public view returns (uint256) {
return totalSupply_;
}
/**
* @dev transfer token for a specified address
* @param _to The address to transfer to.
* @param _value The amount to be transferred.
**/
function transfer(address _to, uint256 _value) public returns (bool) {
require(_to != address(0));
require(_value <= balances[msg.sender]);
balances[msg.sender] = balances[msg.sender].sub(_value);
balances[_to] = balances[_to].add(_value);
emit Transfer(msg.sender, _to, _value);
return true;
}
/**
* @dev Gets the balance of the specified address.
* @param _owner The address to query the the balance of.
* @return An uint256 representing the amount owned by the passed address.
**/
function balanceOf(address _owner) public view returns (uint256) {
return balances[_owner];
}
}
contract StandardToken is ERC20, BasicToken {
mapping (address => mapping (address => uint256)) internal allowed;
/**
* @dev Transfer tokens from one address to another
* @param _from address The address which you want to send tokens from
* @param _to address The address which you want to transfer to
* @param _value uint256 the amount of tokens to be transferred
**/
function transferFrom(address _from, address _to, uint256 _value) public returns (bool) {
require(_to != address(0));
require(_value <= balances[_from]);
require(_value <= allowed[_from][msg.sender]);
balances[_from] = balances[_from].sub(_value);
balances[_to] = balances[_to].add(_value);
allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value);
emit Transfer(_from, _to, _value);
return true;
}
/**
* @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
*
* Beware that changing an allowance with this method brings the risk that someone may use both the old
* and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
* race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
* @param _spender The address which will spend the funds.
* @param _value The amount of tokens to be spent.
**/
function approve(address _spender, uint256 _value) public returns (bool) {
allowed[msg.sender][_spender] = _value;
emit Approval(msg.sender, _spender, _value);
return true;
}
/**
* @dev Function to check the amount of tokens that an owner allowed to a spender.
* @param _owner address The address which owns the funds.
* @param _spender address The address which will spend the funds.
* @return A uint256 specifying the amount of tokens still available for the spender.
**/
function allowance(address _owner, address _spender) public view returns (uint256) {
return allowed[_owner][_spender];
}
/**
* @dev Increase the amount of tokens that an owner allowed to a spender.
*
* approve should be called when allowed[_spender] == 0. To increment
* allowed value is better to use this function to avoid 2 calls (and wait until
* the first transaction is mined)
* From MonolithDAO Token.sol
* @param _spender The address which will spend the funds.
* @param _addedValue The amount of tokens to increase the allowance by.
**/
function increaseApproval(address _spender, uint _addedValue) public returns (bool) {
allowed[msg.sender][_spender] = allowed[msg.sender][_spender].add(_addedValue);
emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
return true;
}
/**
* @dev Decrease the amount of tokens that an owner allowed to a spender.
*
* approve should be called when allowed[_spender] == 0. To decrement
* allowed value is better to use this function to avoid 2 calls (and wait until
* the first transaction is mined)
* From MonolithDAO Token.sol
* @param _spender The address which will spend the funds.
* @param _subtractedValue The amount of tokens to decrease the allowance by.
**/
function decreaseApproval(address _spender, uint _subtractedValue) public returns (bool) {
uint oldValue = allowed[msg.sender][_spender];
if (_subtractedValue > oldValue) {
allowed[msg.sender][_spender] = 0;
} else {
allowed[msg.sender][_spender] = oldValue.sub(_subtractedValue);
}
emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
return true;
}
}
/**
* @title Configurable
* @dev Configurable varriables of the contract
**/
contract Configurable {
uint256 public constant cap = 1000000000*10**18;
uint256 public constant basePrice = 100*10**18; // tokens per 1 ether
uint256 public tokensSold = 0;
uint256 public constant tokenReserve = 500000000*10**18;
uint256 public remainingTokens = 0;
}
/**
* @title CrowdsaleToken 
* @dev Contract to preform crowd sale with token
**/
contract CrowdsaleToken is StandardToken, Configurable, Ownable {
/**
* @dev enum of current crowd sale state
**/
enum Stages {
none,
icoStart, 
icoEnd
}
Stages currentStage;
/**
* @dev constructor of CrowdsaleToken
**/
constructor() public {
currentStage = Stages.none;
balances[owner] = balances[owner].add(tokenReserve);
totalSupply_ = totalSupply_.add(tokenReserve);
remainingTokens = cap;
emit Transfer(address(this), owner, tokenReserve);
}
/**
* @dev fallback function to send ether to for Crowd sale
**/
function () public payable {
require(currentStage == Stages.icoStart);
require(msg.value > 0);
require(remainingTokens > 0);
uint256 weiAmount = msg.value; // Calculate tokens to sell
uint256 tokens = weiAmount.mul(basePrice).div(1 ether);
uint256 returnWei = 0;
if(tokensSold.add(tokens) > cap){
uint256 newTokens = cap.sub(tokensSold);
uint256 newWei = newTokens.div(basePrice).mul(1 ether);
returnWei = weiAmount.sub(newWei);
weiAmount = newWei;
tokens = newTokens;
}
tokensSold = tokensSold.add(tokens); // Increment raised amount
remainingTokens = cap.sub(tokensSold);
if(returnWei > 0){
msg.sender.transfer(returnWei);
emit Transfer(address(this), msg.sender, returnWei);
}
balances[msg.sender] = balances[msg.sender].add(tokens);
emit Transfer(address(this), msg.sender, tokens);
totalSupply_ = totalSupply_.add(tokens);
owner.transfer(weiAmount);// Send money to owner
}
/**
* @dev startIco starts the public ICO
**/
function startIco() public onlyOwner {
require(currentStage != Stages.icoEnd);
currentStage = Stages.icoStart;
}
/**
* @dev endIco closes down the ICO 
**/
function endIco() internal {
currentStage = Stages.icoEnd;
// Transfer any remaining tokens
if(remainingTokens > 0)
balances[owner] = balances[owner].add(remainingTokens);
// transfer any remaining ETH balance in the contract to the owner
owner.transfer(address(this).balance); 
}
/**
* @dev finalizeIco closes down the ICO and sets needed varriables
**/
function finalizeIco() public onlyOwner {
require(currentStage != Stages.icoEnd);
endIco();
}
}
/**
* @title LavevelToken 
* @dev Contract to create the Lavevel Token
**/
contract AlexToken is CrowdsaleToken {
string public constant name = "AlexToken";
string public constant symbol = "ALT";
uint32 public constant decimals = 18;
}

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

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Flere detaljer om smarte kontrakter kan findes i artiklen: Hvad er smarte kontrakter i Ethereum.

Konklusion

Vi har listet de teknologier, som moderne blockchains er bygget på, og hvordan de er forbundet med hinanden. Lad os nu formulere, hvilke problemer der kan løses ved hjælp af blockchain, og hvilke løsninger der i bedste fald vil være ineffektive. Så det er ikke nødvendigt at bruge blockchain, hvis:

• Transaktioner udføres i et betroet miljø;
• Tilstedeværelsen af ​​en kommission af formidlere forværrer ikke deltagernes liv;
• Deltagerne har ikke ejendom, der kan repræsenteres som digitale aktiver;
• Der er ingen distribution i digitale aktiver, dvs. værdien ejes eller leveres af kun én deltager.

Hvad bringer fremtiden for blockchain? Nu kan vi kun spekulere på mulige måder til udvikling af blockchain-teknologier:

• Blockchain bliver den samme gængse databaseteknologi som for eksempel SQL eller NoSQL til løsning af dens specifikke række af problemer;
• Blockchain vil blive en udbredt protokol, ligesom HTTP er for internettet;
• Blockchain vil blive grundlaget for et nyt finansielt og politisk system på planeten!

I næste del vil vi se på, hvilke blockchains der findes i øjeblikket, og hvorfor de bruges i forskellige brancher.

Dette er blot begyndelsen!

Kilde: www.habr.com