Hva skal vi bygge en blokkjede?

Hele menneskehetens historie er en kontinuerlig prosess med å kvitte seg med lenker og skape nye, enda sterkere. (Anonym forfatter)

Ved å analysere en rekke blokkjedeprosjekter (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin, etc.), forstår jeg at fra et teknisk synspunkt er de alle bygget på de samme prinsippene. Blokkjeder minner om hus, som til tross for all variasjon av design, innredning og formål, har et fundament, vegger, tak, vinduer, dører som er knyttet til hverandre på bestemte måter. Og hvis du forstår de grunnleggende prinsippene for bygningsdesign og kjenner egenskapene til materialene som brukes, kan du bestemme formålet med et bestemt hus. For tiden har det oppstått en situasjon med blockchain som alle har hørt om, men få mennesker forstår arkitekturen og prinsippene for drift. Derfor er det en misforståelse av hvorfor og hvordan det er fornuftig å bruke blockchain-teknologier.

I denne artikkelen vil vi analysere egenskapene og prinsippene som er felles for alle blokkjeder. Deretter, la oss se på problemene som kan løses ved hjelp av blokkjeden og for å forsterke materialet, la oss bygge en liten, men ekte blokkjede på vår virtuelle side!

Så la oss huske hvilke problemer blockchain opprinnelig løste.

Jeg er sikker på at mange vil si om en distribuert, desentralisert, offentlig og uforanderlig database. Men hvorfor var alt dette nødvendig?

Jeg foretrekker å begynne å studere hvilken som helst teknologi ved å lese standardene, siden alle artikler og bøker om emnet som studeres er basert på dem. Men det er for øyeblikket ingen blokkjedestandarder; ISO har bare opprettet komiteer for deres utvikling. Foreløpig har hvert offentlig blokkjedeprosjekt sitt eget White paper-dokument, som i hovedsak er en teknisk spesifikasjon. Det første offentlig kjente blokkjedeprosjektet er Bitcoin-nettverket. Gå til den offisielle nettsiden til nettverket og utseende hvor det hele begynte.

Blockchain Challenge

Så, oppgaven som blockchain løste i Bitcoin-pionernettverket er å utføre en klarert overføring av eierskap til digitale eiendeler (aktiva) i et ikke-klarert miljø uten mellomledd. For eksempel, i Bitcoin-nettverket er en digital eiendel bitcoin digitale mynter. Og alle tekniske løsninger av Bitcoin og andre blokkjeder handler om å løse dette problemet.

Problemer som blockchain løser

Anta at en viss finansorganisasjon sier at den har bygget et nettverk rundt om i verden ved hjelp av hvilket det er mulig å overføre penger til enhver person. Vil du tro henne? Hvis denne organisasjonen er Visa eller MasterCard, vil du sannsynligvis tro det, men hvis, relativt sett, AnonymousWorldMoney, vil du sannsynligvis ikke gjøre det. Hvorfor? Men fordi vi vet godt hvordan distribuerte systemer lages av private selskaper, til hvilke formål, og hva dette kan føre til. La oss se nærmere på problemene med slike systemer og hvordan de kan løses ved hjelp av blockchain-teknologier.

La oss si at i den betingede AnonymousWorldMoney er det servere med databaser, og det er bra om det er flere av dem i forskjellige datasentre. Når avsender overfører penger, registreres en transaksjon som replikeres til alle servere, og pengene kommer frem til mottakeren.

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

1. Problemet med å identifisere deltakere på den ene siden og behovet for anonymitet av transaksjoner på den andre. De. du må overføre penger til en bestemt mottaker og på en slik måte at ingen vet om denne transaksjonen bortsett fra deltakerne i transaksjonen. Banker har kontonummer og bankkort knyttet til en bestemt person eller juridisk enhet, og bankhemmeligheter beskytter transaksjonsinformasjon. Og hvem garanterer at de betingede AnonymousWorldMoney ikke bruker personopplysninger og transaksjonsinformasjon til egne formål?
2. Hvordan sikre at mottakeren mottok nøyaktig beløpet som ble overført til ham? Relativt sett overførte avsenderen $100, og mottakeren mottok $10. Avsenderen kommer til AnonymousWorldMoney-kontoret med kvitteringen sin, og ekspeditøren viser sin versjon, hvor det står skrevet at avsenderen har overført kun $10.
3. Problemet med et upålitelig miljø, for eksempel en svindel som kalles dobbeltbruk. En skruppelløs deltaker kan bruke saldoen flere ganger til betalingen er replikert til alle servere. CAP-teorem, selvfølgelig, ingen kansellerte, og enighet vil til slutt oppnås, men noen vil ikke motta penger for tjenester eller varer levert. Derfor, hvis det ikke er fullstendig tillit til betalingsorganisasjonen eller deltakere i transaksjoner, er det nødvendig å bygge et nettverk basert ikke på tillit, men på kryptografi.
4. Betingede AnonymousWorldMoney har et begrenset antall servere som kan bli utilgjengelige utilsiktet eller på grunn av ondsinnet hensikt.
5. AnonymousWorldMoney vil ta sin egen konkrete provisjon.
6. Mulighet for kontroll. Under driften av Bitcoin viste det seg at folk ikke bare ønsker å overføre mynter til hverandre, men også å sjekke ulike forhold for transaksjonen, programmere arbeidsscenarier, automatisk utføre handlinger avhengig av forholdene, etc.

Hvordan blockchain løser disse problemene

1. Identifikasjon av deltakere utføres ved hjelp av et par nøkler: private og offentlige, og den digitale signaturalgoritmen identifiserer avsender og mottaker unikt, og etterlater identiteten deres anonym.
2. Transaksjoner samles i blokker, hashen til blokken beregnes og skrives inn i neste blokk. Denne sekvensen med opptak av hashes i blokker gir blokkjedeteknologien navnet sitt, og den gjør det også umulig å umerkelig endre/slette blokker eller individuelle transaksjoner fra blokker. Dermed, hvis en transaksjon er inkludert i blokkjeden, kan du være sikker på at dataene forblir uendret.
3. Dobbeltbrukssvindel forhindres ved å oppnå en nettverkskonsensus om hvilke data som skal anses som gyldige og hvilke som skal forkastes. I Bitcoin-nettverket oppnås konsensus ved bevis på arbeid (PoW).
4. Påliteligheten til nettverket oppnås ved at blokkjeden er offentlig, der hver deltaker kan kjøre sin egen node, motta en komplett kopi av blokkjeden og dessuten uavhengig begynne å kontrollere transaksjoner for korrekthet. Det skal bemerkes at moderne blokkjeder gjør det mulig å bygge ikke bare offentlige (åpne), men også private (lukkede) blokkjeder, samt bruk av kombinerte ordninger.
5. Blokkjeden blir ikke helt kvitt provisjoner, fordi... du må betale folkene som støtter nettverket, men i blokkjeden er behovet for provisjon bevist så overbevisende at det ikke er noen tvil om nødvendigheten.
6. Moderne blokkjeder har muligheten til å implementere forretningslogikk, som i blokkjeden kalles Smart Contracts. Logikken til smarte kontrakter er implementert på forskjellige høynivåspråk.

Deretter vil vi vurdere disse løsningene mer detaljert.

Blockchain-arkitektur

Blockchain-komponenter

Hver deltaker kan starte sin egen node med en full kopi av blokkjeden (full node). Fulle noder som kan registrere transaksjoner på blokkjeden kalles konsensus noder (vitne) eller gruvearbeidere (gruvearbeider). Fulle noder som kun kontrollerer transaksjonens korrekthet kalles opp revisjonsnoder (revidere). Lette kunder (lette klienter) lagrer ikke fullstendige kopier av blokkjeden, men samhandler med nettverket ved hjelp av fulle noder.
De fleste brukere bruker lette klienter eller nettlommebøker for å utføre transaksjoner. Alle noder er koblet til hverandre. Med dette settet med elementer blir nettverksarkitekturen mer stabil:

Transaksjonens livssyklus

La oss se på transaksjonens livssyklus og dele den ned del for del:

Blockchain-teknologier

La oss dvele mer detaljert på tekniske løsninger og deres forbindelser med hverandre.

identifikasjon

Hver blokkjedetransaksjon må signeres digitalt. Derfor, for å fullføre en transaksjon, må hver deltaker ha et nøkkelpar: privat / offentlig. Noen ganger kalles et par nøkler en lommebok, fordi nøklene er unikt knyttet til deltakerens unike digitale adresse og saldo. I virkeligheten er nøkler og adresser bare rekker av tall i forskjellige tallsystemer. Eksempler på nøkler og lommebokadresser:

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

For å lage en digital signatur i blokkjeder brukes en algoritme basert på elliptiske kurver: Elliptic Curve Digital Signature Algorithm (ECDSA). For at det skal fungere, tas den private nøkkelen (256-bit nummer) vanligvis tilfeldig. Antall nøkkelalternativer er 2 i kraft av 256, så vi kan snakke om den praktiske umuligheten av å matche verdiene til private nøkler.

Deretter hentes den offentlige nøkkelen fra den private ved å multiplisere verdien med koordinatene til et punkt som ligger på den elliptiske kurven, noe som resulterer i koordinatene til et nytt punkt på samme kurve. Denne handlingen sikrer at du får et nøkkelpar som er egnet for digital signering av transaksjoner. Til slutt er lommebokadressen unikt utledet fra den offentlige nøkkelen.

Det er mange artikler med detaljer om kryptografien som brukes i blockchain, for eksempel: Bitcoin i et nøtteskall – Kryptografi

Den private nøkkelen må være strengt konfidensiell og oppbevares sikkert. Den offentlige nøkkelen er kjent for alle. Hvis den private nøkkelen går tapt, kan ikke tilgangen til eiendelen (mynter) gjenopprettes og pengene vil gå tapt for alltid. Derfor er oppgaven med å sikkert lagre private nøkler ekstremt relevant, fordi Dette er ikke en bank hvor du alltid kan komme med passet ditt og gjenopprette kontoen din. Det er en hel industri for produksjon av såkalte kalde krypto-lommebøker, som ligner på flash-stasjoner:

eller du kan bruke mer pålitelige metoder, for eksempel å stemple verdien av den private nøkkelen på tokens:

Transaksjonen

Flere detaljer om transaksjonsstrukturen finner du i artikkelen Bitcoin i et nøtteskall – Transaksjon. Det er viktig for oss å forstå at hver transaksjon har minst følgende data:

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

Deretter signeres transaksjonen med en privat nøkkel og sendes ut (se detaljer om driften av protokollen Bitcoin i et nøtteskall-protokoll) til alle noder i blokkjeden som sjekker transaksjoner for gyldighet. Algoritmen for transaksjonsbekreftelse er ikke-triviell og inkluderer to dusin trinn.

Transaksjonsblokker

Etter å ha kontrollert gyldigheten av transaksjoner, danner noder blokker fra dem. I tillegg til transaksjoner skrives hashen til forrige blokk og et tall (ikke-teller) inn i blokken, og hashen til gjeldende blokk beregnes ved hjelp av SHA-256-algoritmen. Hashen må ha etablerte kompleksitetsforhold. For eksempel, i Bitcoin-nettverket, endres vanskelighetsgraden til hashen automatisk hver 2. uke avhengig av kraften til nettverket, slik at en blokk genereres omtrent en gang hvert 10. minutt. Kompleksiteten bestemmes av følgende betingelse: hashen som er funnet må være mindre enn et forhåndsbestemt tall. Hvis denne betingelsen ikke er oppfylt, legges 1 til Nonce, og arbeidet med å beregne hashen gjentas. For å velge en hash, brukes Nonce-feltet, fordi Dette er de eneste dataene i blokken som kan endres, resten må forbli uendret. En gyldig hash må ha et visst antall innledende nuller, for eksempel en av de virkelige hashen:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Vellykket å finne en hash er bevis på utført arbeid (Proof-of-Work, PoW) for Bitcoin- eller Ethereum-nettverkene. Prosessen med å finne hasj kalles gruvedrift, på samme måte som gullgruvedrift. Navnet definerer ganske nøyaktig essensen av prosessen, fordi det er et enkelt søk av alternativer, og hvis noen finner en passende hash, så er dette virkelig flaks. Det er som å finne en ekte gullklump i tonnevis med gråstein. Blokkbelønningen er nå 12.5 BTC, og hvis du multipliserer den med gjeldende Bitcoin-kurs på $3900, får du mer enn et kilo rent gull. Det er noe å kjempe for!

Etter å ha funnet en hash, blir blokken og den funnet hashen skrevet til blokkjeden som neste blokk. Flere detaljer om strukturen til blokker finner du i artikkelen Bitcoin i et nøtteskall - Blockchain, og nedenfor er et forenklet diagram:

Blokkjeden starter med en blokk som ennå ikke har hashen til forrige blokk. Det er bare én slik blokk i blokkjeden og har sitt eget navn Genesis block. De resterende blokkene har samme struktur og skiller seg bare i antall transaksjoner. Ekte transaksjoner og blokker som for øyeblikket opprettes i Bitcoin eller Ethereum kan sees i Blokker Explorer.

Størrelsen på blokker i Bitcoin er begrenset til 1MB og med en minimumsmengde informasjon i en transaksjon på ca. 200 byte, kan maksimalt antall transaksjoner i en blokk være ca. 6000. Herfra følger forresten ytelsen til Bitcoin, som alle ler av: en blokk genereres omtrent en gang hvert 10. minutt * 60 sekunder = 600 sekunder, noe som gir en formell ytelse på ca 10 TPS. Selv om dette faktisk ikke er produktivitet, men en bevisst implementert arbeidsalgoritme. I Ethereum, for konkurranse, gjorde de ganske enkelt blokkgenereringstiden til 15 sekunder. og produktiviteten steg formelt. Derfor, i blokkjeder som bruker PoW som konsensus, gir det ingen mening å sammenligne ytelse i det hele tatt, fordi det avhenger direkte av kompleksiteten til hurtigbufferberegningen, som kan tilordnes en hvilken som helst verdi.

Gafler

Hva skjer hvis for eksempel flere noder fant hasher som oppfyller kompleksitetsbetingelsene, men som er forskjellige i verdi (med andre ord kom de til ulik konsensus) og skrev blokker til blokkjeden? La oss se hvordan blockchain beskytter mot denne situasjonen. I dette tilfellet oppstår en såkalt gaffel, og blokkjeden har to versjoner av kjeden:

Hva skjer etterpå? Deretter begynner en del av nettverket å jobbe på blokk N+2 fra en kjede, og en del fra en annen:

En av disse blokkene vil bli funnet tidligere og sendt til blokkjeden, og deretter, i henhold til reglene, må blokkjeden bytte til en lengre kjede og kansellere alle transaksjoner fra den alternative blokken:

Samtidig kan det oppstå en situasjon når en deltakers transaksjon kun var i en av gaffelblokkene, som ble kansellert. Derfor, for å være sikker på at ønsket transaksjon er registrert i blokkjeden, er det en generell anbefaling – før du stoler på transaksjonen, bør du vente til de neste blokkene legges til blokkjeden. Anbefalinger for hvor mange blokker som skal vente på ulike blokkjeder varierer. For eksempel, for Bitcoin-nettverket er minimum 2 blokker, maksimum er 6.

Det samme bildet med blokkgafler vil bli observert under det såkalte 51%-angrepet - dette er når en gruppe gruvearbeidere prøver å vokse en alternativ blokkkjede, og prøver å kansellere kjeden med sine uredelige transaksjoner. Selv om det for tiden, i stedet for svindel, er mer lønnsomt å bruke kraften din på ærlig gruvedrift.

Konsensus

For å registrere en blokk på blokkjeden, må nettverket nå en konsensus. La oss huske oppgaven med å oppnå konsensus i datakommunikasjonsnettverk. Problemstillingen er formulert som oppgaven til de bysantinske generalene BFT (Bysantinsk feiltoleranse). Utelater den pittoreske beskrivelsen av problemene til den bysantinske hæren, kan problemet formuleres som følger: hvordan kan nettverksnoder komme til et felles resultat hvis noen nettverksnoder bevisst kan forvrenge dem. Eksisterende algoritmer for å løse BFT-problemet viser at nettverket kan fungere korrekt dersom det er mindre enn 1/3 svindlere. Hvorfor har ikke BFT-konsensus blitt brukt på Bitcoin-nettverket? Hvorfor var det nødvendig å bruke PoW? Det er flere grunner:

• BFT fungerer bra med et lite fast sett med noder, men i en offentlig blokkjede er antallet noder uforutsigbart og dessuten kan noder slås på og av tilfeldig.
• Det er nødvendig å motivere folk til å lansere blockchain-noder. For å gjøre dette må folk belønnes. I BFT er det formelt sett ingenting å motta belønning for, men hva belønningen er for i PoW er klart for alle på et intuitivt nivå: for elektrisiteten som forbrukes av prosessoren i ferd med å finne blokkhashen.

I tillegg til PoW er det flere andre konsensus som brukes i moderne blokkjeder, for eksempel:

• PoS (Proof-of-Stake) - på blokkjeden Hyperledger
• DPoS (Delegated Proof-of-Stake) - på blokkjeden BitShares
• Modifikasjoner av BFT: SBFT (Forenklet BFT) og PBFT (Praktisk BFT), for eksempel i blokkjede Exonum

La oss dvele litt ved PoS-konsensus, fordi... Det er PoS og dets varianter som er mest utbredt i private blokkjeder. Hvorfor privat? På den ene siden er egenskapene til PoS bedre sammenlignet med PoW, fordi For å oppnå konsensus trengs mindre dataressurser, noe som betyr at hastigheten på å skrive data til blokkjeden øker. Men på den annen side har PoS flere muligheter for svindel, så for å nøytralisere dette må alle deltakerne i blokkjeden være kjent.

PoS-konsensus er basert på valg av en node som kan skrive en blokk med transaksjoner til blokkjeden avhengig av mengden midler på kontoen, eller rettere sagt, ikke på kontoen, men i sikkerheten, dvs. Jo mer midler du har som sikkerhet, jo mer sannsynlig vil nettverket velge noden din for å skrive en blokk. Depositumet vil ikke bli returnert hvis blokkeringen er ugyldig. Dette gir beskyttelse mot svindel. Det er følgende varianter av PoS:

• Den delegerte PoS (DPoS) konsensus deler deltakerne inn i "velgere" og "validatorer". Myntinnehavere (stemmeberettigede deltakere) delegerer sin makt til å verifisere og registrere transaksjoner på blokkjeden til andre deltakere. Dermed gjør validatorer alt beregningsarbeidet og mottar en belønning for det, og tilstedeværelsen av stemmedeltakere garanterer ærligheten til validatorene, fordi de kan endres når som helst.
• LPoS (Leased Proof-of-Stake)-konsensus lar deg leie ut midlene dine til andre noder slik at de har en bedre sjanse til å validere blokker. At. Du kan motta en provisjon for transaksjoner uten å delta i selve transaksjonsbekreftelsen og blokkutvinningen.

Det er en rekke andre konsensuser som ennå ikke er mye brukt, jeg vil bare liste dem her for informasjon, og en oversikt over selve konsensusalgoritmene finner du for eksempel i artikkelen: Konsensusalgoritmer i Blockchain.

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

Pålitelighet og distribusjonsmodeller av blokkjeder

Offentlig blokkjede

Stabilitet offentlig eller et annet navn Tillatelsesløs blokkjede Dette oppnås ved å la hvem som helst koble til og se informasjon eller til og med koble til sin egen node, og tillit er bygget på PoW-konsensus.

Privat blokkjede

Privat eller Private Permissioned blockchain. I disse blokkjedene er det kun en bestemt gruppe deltakere (organisasjoner eller personer) som har tilgang til informasjon. Slike blokkjeder er bygget av organisasjoner med mål om å øke den totale fordelen eller effektiviteten. Deres pålitelighet er sikret av deltakernes felles mål og PoS- og BFT-konsensusalgoritmene.

Blockchain-konsortium

Det Consortium eller Offentlig godkjent blokkjede. Dette er blokkjeder som alle kan koble seg til for å se, men en deltaker kan legge til informasjon eller koble til noden sin kun med tillatelse fra andre deltakere. Slike blokkjeder bygges av organisasjoner for å øke tilliten fra kunder eller forbrukere av produkter eller samfunnet som helhet. Her oppnås også pålitelighet ved tilstedeværelse av tillit mellom deltakere og de samme PoS- og BFT-konsensusalgoritmene.

Smarte kontrakter

Blokkjeder implementert etter Bitcoin har i en eller annen grad lagt til muligheten til å utføre smarte kontrakter. I hovedsak er en smart kontrakt en transaksjon der programkoden plasseres for utførelse. Smarte kontrakter på Ethereum-nettverket utføres i EVM (Ethereum Virtual Machine). For å begynne å utføre en smart kontrakt, må den eksplisitt lanseres av en annen transaksjon, eller forutsetningene for utførelse må være oppfylt. Resultatene av utførelsen av den smarte kontrakten vil også bli registrert i blokkjeden. Å motta data fra utenfor blokkjeden er mulig, men ekstremt begrenset.

Hvilken forretningslogikk kan implementeres ved hjelp av en smart kontrakt? Faktisk er det ikke mye, for eksempel å sjekke forhold ved hjelp av data fra blokkjeden, endre eiere av digitale eiendeler avhengig av disse forholdene, registrere data i en permanent lagring i blokkjeden. Logikken er implementert i et spesielt høynivåspråk Solidity.

Et klassisk eksempel på funksjonalitet som implementeres ved hjelp av smarte kontrakter er utstedelse av tokens for ICO-er. For eksempel implementerte jeg en smart kontrakt for å utstede beskjedne 500 000 000 AlexToken. Av lenke i Etherscan er

kildekoden til den smarte kontrakten på Solidity-språket

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

og den binære representasjonen slik nettverket ser den

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Flere detaljer om smarte kontrakter finner du i artikkelen: Hva er smarte kontrakter i Ethereum.

Konklusjon

Vi har listet opp teknologiene som moderne blokkjeder er bygget på og hvordan de er koblet til hverandre. La oss nå formulere hvilke problemer som kan løses ved hjelp av blockchain, og hvilke løsninger som i beste fall vil være ineffektive. Så bruk av blockchain er ikke nødvendig hvis:

• Transaksjoner utføres i et pålitelig miljø;
• Tilstedeværelsen av en kommisjon av mellommenn forverrer ikke deltakernes liv;
• Deltakerne har ikke eiendom som kan representeres som digitale eiendeler;
• Det er ingen distribusjon i digitale eiendeler, dvs. verdien eies eller leveres av kun én deltaker.

Hva vil fremtiden bringe for blockchain? Nå kan vi bare spekulere på mulige måter for utvikling av blockchain-teknologier:

• Blockchain vil bli den samme vanlige databaseteknologien som for eksempel SQL eller NoSQL for å løse dens spesifikke problemområde;
• Blockchain vil bli en utbredt protokoll, slik HTTP er for Internett;
• Blockchain vil bli grunnlaget for et nytt finansielt og politisk system på planeten!

I neste del skal vi se på hvilke blokkjeder som eksisterer i dag og hvorfor de brukes i ulike bransjer.

Dette er bare begynnelsen!

Kilde: www.habr.com