Smarte kontraktplatforme [En dybdykundersøgelse]

I denne vejledning skal vi gennemgå nogle smarte kontraktplatforme derude og se, hvad der adskiller dem. Nogle af dem arbejder allerede, mens andre er under udvikling.

Vi lever i den smarte kontrakts æra. Mens Bitcoin måske har vist os, at et betalingssystem kan eksistere i en decentral peer-to-peer-atmosfære. Imidlertid var det med Ethereums fremkomst, at flodportene åbnede sig rigtigt. Ethereum indvarslede den anden generations blockchain æra, og folk så endelig det sande potentiale for Dapps og Smart Contracts.

Et dybere kig på forskellige smarte kontraktplatforme

Før vi dog gør det, lad os stille os et spørgsmål.

Hvad er smarte kontrakter?

Smarte kontrakter er automatiserede kontrakter. De udfører selvudførelse med specifikke instruktioner skrevet på dens kode, som bliver udført, når visse betingelser er lavet.

Et dybere kig på forskellige smarte kontraktplatforme

Du kan lære mere om smarte kontrakter i vores dybdegående vejledning her.

Så hvad er de ønskelige egenskaber, vi ønsker i vores smarte kontrakt?

Alt, der kører på en blockchain, skal være uforanderligt og skal have evnen til at løbe gennem flere noder uden at gå på kompromis med dets integritet. Som et resultat heraf skal smart kontraktfunktionalitet være tre ting:

  • Deterministisk.
  • Kan afsluttes.
  • Isoleret.

Funktion nr. 1: Deterministisk

Et program er deterministisk, hvis det giver den samme output til en given input hver eneste gang. For eksempel. Hvis 3 + 1 = 4, så vil 3 + 1 ALTID være 4 (forudsat at den samme base). Så når et program giver det samme output til det samme sæt input i forskellige computere, kaldes programmet deterministisk.

Der er forskellige øjeblikke, hvor et program kan handle på en ikke-deterministisk måde:

  • Opkald til ikke-deterministiske systemfunktioner: Når en programmør kalder en ikke-deterministisk funktion i deres program.

  • Ikke-deterministiske dataressourcer: Hvis et program erhverver data under løbetiden, og den datakilden er ikke-deterministisk, bliver programmet ikke-deterministisk. For eksempel. Antag et program, der erhverver de 10 bedste Google-søgninger i en bestemt forespørgsel. Listen kan blive ved med at ændre sig.

  • Dynamiske opkald: Når et program kalder det andet program kaldes det dynamisk opkald. Da opkaldsmålet kun bestemmes under udførelse, er det ikke-deterministisk.

Funktion nr. 2: Kan afsluttes

I matematisk logik har vi en fejl kaldet “halting problem”. Dybest set siger det, at der er manglende evne til at vide, om et givet program kan udføre dets funktion inden for en frist. I 1936 udledte Alan Turing ved hjælp af Cantors diagonale problem, at der ikke er nogen måde at vide, om et givet program kan afslutte inden for en tidsfrist eller ej.

Dette er naturligvis et problem med smarte kontrakter, fordi kontrakter pr. Definition skal kunne opsiges inden for en given tidsfrist. Der er nogle foranstaltninger truffet for at sikre, at der er en måde at eksternt “dræbe” kontrakten på og ikke indgå i en endeløs løkke, der dræner ressourcer:

  • Turing ufuldstændighed: En Turing ufuldstændig blockchain har begrænset funktionalitet og er ikke i stand til at foretage spring og / eller løkker. Derfor kan de ikke komme ind i en endeløs løkke.

  • Trin og gebyrmåler: Et program kan simpelthen holde styr på antallet af “trin”, det har taget, dvs. antallet af instruktioner, det har udført, og derefter afsluttes, når et bestemt trinantal er udført. En anden metode er gebyrmåleren. Her udføres kontrakterne med et forudbetalt gebyr. Hver udførelse af instruktioner kræver et bestemt gebyr. Hvis det brugte gebyr overstiger det forudbetalte gebyr, opsiges kontrakten.

  • Timer: Her opbevares en forudbestemt timer. Hvis kontraktens udførelse overskrider fristen, afbrydes den eksternt.

Funktion nr. 3: Isoleret

I en blockchain kan alle og enhver uploade en smart kontrakt. Imidlertid kan kontrakterne bevidst og ubevidst indeholde virus og bugs på grund af dette.

Hvis kontrakten ikke er isoleret, kan dette hæmme hele systemet. Derfor er det afgørende, at en kontrakt holdes isoleret i en sandkasse for at redde hele økosystemet fra eventuelle negative virkninger.

Nu hvor vi har set disse funktioner, er det vigtigt at vide, hvordan de udføres. Normalt køres de smarte kontrakter ved hjælp af et af de to systemer:

  • Virtuelle maskiner: Ethereum og Neo bruger dette
  • Docker: Stof bruger dette.

Lad os sammenligne disse to og afgøre, hvad der skaber et bedre økosystem. For enkelheds skyld skal vi sammenligne Ethereum (Virtual Machine) med Fabric (Docker).

Et dybere kig på forskellige smarte kontraktplatforme

Så som det kan ses, giver virtuelle maskiner bedre deterministiske, terminable og isolerede omgivelser for smarte kontrakter.

Ok, så nu ved vi, hvad smarte kontrakter er, og det faktum, at virtuelle maskiner er bedre platforme til smarte kontrakter. Lad os se på, hvad Dapps kræver for at køre effektivt.

Hvad kræver Dapps??

Eller for at indramme det mere specifikt, hvad kræver en DAPP for at få succes og et hit hos det almindelige publikum? Hvad er dens absolutte minimumskrav?

Support til millioner af brugere

Det skal være skalerbart nok til, at millioner af brugere kan bruge det. Dette gælder især for DAPP’er, der leder efter almindelig accept.

Gratis brug

Platformen skal gøre det muligt for devs at oprette Dapps, der er gratis at bruge til deres brugere. Ingen brugere skal betale platformen for at få fordelene ved en Dapp.

Let opgraderbar

Platformen skal give udviklerne frihed til at opgradere Dapp, når og når de vil. Også, hvis en eller anden fejl påvirker Dapp, skal devs være i stand til at rette DAPP uden at påvirke platformen.

Lav latenstid

En DAPP skal køre så jævnt som muligt og med den lavest mulige ventetid.

Parallel ydeevne

En platform skal tillade, at deres Dapps behandles parallelt for at distribuere arbejdsbyrden og spare tid.

Sekventiel præstation

Dog skal ikke alle funktionerne på en blockchain gøres på den måde. Tænk på selve transaktionens udførelse. Flere transaktioner kan ikke udføres parallelt; det skal gøres en ad gangen for at undgå fejl som dobbeltforbrug.

Så hvad er de platforme, der er tilgængelige for os, når det kommer til DAPP-oprettelse?

BitShares og Graphene har god kapacitet, men er bestemt ikke smarte kontrakter egnede.

Ethereum er klart det mest oplagte valg på markedet. Det har fantastiske smarte kontraktegenskaber, men den lave transaktionshastighed er et stort problem. Plus, gasprisen kan også være problematisk.

Ok, så nu, hvor vi ved, hvad Dapps kræver, lad os gennemgå nogle smarte kontraktplatforme.

Vi vil se på:

  • Ethereum

  • EOS

  • Fantastisk

  • Cardano

  • Neo

  • Hyperledger stof

Et dybere kig på forskellige smarte kontraktplatforme

Ethereum

Først og fremmest har vi Ethereum, den der startede det hele.

Sådan definerer Ethereums websted det:

“Ethereum er en decentral platform, der kører smarte kontrakter: applikationer, der kører nøjagtigt som programmeret uden mulighed for nedetid, censur, svindel eller tredje part interferens. Disse apps kører på en specialbygget blockchain, en enormt kraftig delt global infrastruktur, der kan flytte værdi rundt og repræsentere ejerskabet af ejendom. ”

Men i enklere termer planlægger Ethereum at være fremtidens ultimative softwareplatform. Hvis fremtiden er decentraliseret, og Dapps bliver almindelige, skal Ethereum være fronten og midten af ​​den.

Ethereum Virtual Machine eller EVM er den virtuelle maskine, hvor alle smarte kontrakter fungerer i Ethereum. Det er en enkel, men kraftfuld Turing Complete 256-bit virtuel maskine. Turing Complete betyder, at i betragtning af ressourcerne og hukommelsen kan ethvert program, der udføres i EVM, løse ethvert problem.

For at kode smarte kontrakter i EVM skal man lære programmeringssproget Solidity.

Soliditet er et målrettet slanket, løst skrevet sprog med en syntaks, der ligner ECMAScript (Javascript). Der er nogle vigtige punkter, der skal huskes fra Ethereum Design Rationale-dokumentet, nemlig at vi arbejder inden for en stack-and-memory-model med en 32-byte instruktionsordstørrelse, EVM (Ethereum Virtual Machine) giver os adgang til programmet “ stak ”som er som et registerrum, hvor vi også kan holde hukommelsesadresser for at gøre Program Counter-loop / spring (til sekventiel programstyring), en udvidelig midlertidig“ hukommelse ”og en mere permanent“ lagring ”, som faktisk er skrevet i den permanente blockchain, og vigtigst af alt kræver EVM total determinisme inden for de smarte kontrakter.

Så før vi fortsætter, skal vi se på et grundlæggende eksempel på soliditetskontrakt. (Koder blev taget fra github).

Lad os køre en enkel mens sløjfe i soliditet:

kontrakt BasicIterator

{

adresse skaberen; // reserver en "adresse"-skriv stedet

uint8 [10] heltal; // reserver et stykke lagerplads til 10 8-bit usignerede heltal i en matrix

funktion BasicIterator ()

{

skaber = msg.sender;

uint8 x = 0;

// Afsnit 1: Tildeling af værdier

mens (x < heltal.længde) {

heltal [x] = x;

x ++;

}}

funktion getSum () konstant returnerer (uint) {

uint8 sum = 0;

uint8 x = 0;

// Afsnit 2: Tilføjelse af heltal i en matrix.

mens (x < heltal.længde) {

sum = sum + heltal [x];

x ++;

}

returbeløb

}

// Afsnit 3: At dræbe kontrakten

funktion dræb ()

{

hvis (msg.sender == skaber)

{

selvmord (skaberen);

}

}

}

Så lad os analysere koden. For at gøre det lettere at forstå har vi opdelt koden i 3 sektioner.

Afsnit 1: Tildeling af værdier

I det første trin udfylder vi en matrix kaldet “heltal”, der optager 10 8-bit usignerede heltal. Den måde, vi gør det på, er via en while-loop. Lad os se på, hvad der sker inden for mens løkken.

mens (x < heltal.længde) {

heltal [x] = x;

x ++;

}

Husk, vi har allerede tildelt en værdi på “0” til heltalet x. Mens loop går fra 0 til heltal. Længde. Integers.length er en funktion, der returnerer arrayets maksimale kapacitet. Så hvis vi besluttede, at en matrix vil have 10 heltal, returnerer arrayname.length en værdi på 10. I sløjfen ovenfor går x-værdien fra 0 – 9 (<10) og tildeler også selve værdien til arrayet med heltal. Så i slutningen af ​​sløjfen vil heltal have følgende værdi:

0,1,2,3,4,5,6,7,8,9.

Afsnit 2: Tilføjelse af matrixindholdet

Inde i getSum () -funktionen skal vi tilføje indholdet af selve arrayet. Den måde, hvorpå vi skal gøre det, er ved at gentage den samme while-loop som ovenfor og bruge variablen “sum” til at tilføje indholdet af arrayet.

Afsnit 3: At dræbe kontrakten

Denne funktion dræber kontrakten og sender de resterende midler i kontrakten tilbage til kontraktopretteren.

Hvad er gas?

“Gas” er livsnerven i Ethereum-økosystemet, der er ingen anden måde at sætte det på. Gas er en enhed, der måler den mængde beregningsindsats, det vil tage for at udføre bestemte operationer.

Hver eneste operation, der deltager i Ethereum, det være sig en simpel transaktion eller en smart kontrakt eller endda en ICO tager en vis mængde gas. Gas er det, der bruges til at beregne antallet af gebyrer, der skal betales til netværket for at udføre en operation.

Når nogen indsender en smart kontrakt, har den en forudbestemt gasværdi. Når kontrakten udføres, kræver hvert eneste trin i kontrakten en vis mængde gas at udføre.

Dette kan føre til to scenarier:

  1. Den krævede gas er mere end den indstillede grænse. Hvis det er tilfældet, vendes kontrakttilstanden tilbage til sin oprindelige tilstand, og al gassen er brugt op.

        2. Den krævede gas er mindre end den indstillede grænse. Hvis det er tilfældet, så er kontrakten afsluttet, og den resterende gas overgives til kontraktsætteren.

Mens Ethereum måske har banet vejen for smarte kontrakter. Det står over for nogle skalerbarhedsproblemer. Innovationer som plasma, raiden, sharding osv. Kan dog løse dette problem.

EOS

Et dybere kig på forskellige smarte kontraktplatforme

EOS sigter mod at blive et decentraliseret operativsystem, der kan understøtte decentraliserede applikationer i industriel skala.

Det lyder ret forbløffende, men hvad der virkelig har fanget offentlighedens fantasi er følgende to påstande:

  • De planlægger at fjerne transaktionsgebyrer fuldstændigt.

  • De hævder at have evnen til at gennemføre millioner af transaktioner pr. Sekund.

Disse to funktioner er grundene til, at Dapp-udviklere er fascineret af EOS. Lad os se på, hvordan EOS opnår begge disse ting.

Fjernelse af gebyrer

EOS arbejder på en ejerskabsmodel, hvor brugerne ejer og har ret til at bruge ressourcer, der er proportionale med deres andel, snarere end at skulle betale for hver transaktion. Så hvis du har N-tokens af EOS, har du ret til N * k-transaktioner. Dette eliminerer i det væsentlige transaktionsgebyrer.

Omkostningerne ved at køre og hoste applikationer på Ethereum kan være høje for en udvikler, der ønsker at teste deres applikation på blockchain. Gasprisen, der er involveret i de tidlige stadier af udviklingen, kan være tilstrækkelig til at slukke for nye udviklere.

Den grundlæggende forskel mellem den måde, Ethereum og EOS fungerer på, er, at mens Ethereum udlejer deres beregningskraft til udviklerne, giver EOS ejerskab af deres ressourcer. Så hvis du ejer 1/1000 af aktien i EOS, vil du faktisk have ejerskab af 1/1000 af den samlede beregningskraft og ressourcer i EOS.

Som ico-anmeldelser siger i deres artikel:

“EOS’s ejerskabsmodel giver DAPP-udviklere forudsigelige hostingomkostninger, der kun kræver, at de opretholder en bestemt procentdel eller et niveau af indsats, og gør det muligt at oprette freemium-applikationer. Da EOS-token-indehavere endvidere vil være i stand til at leje / delegere deres andel af ressourcer til andre udviklere, binder ejerskabsmodellen værdien af ​​EOS-tokens til udbud og efterspørgsel efter båndbredde og opbevaring. ”

Øget skalerbarhed

EOS får sin skalerbarhed fra sin DPOS-konsensusmekanisme. DPOS står for delegeret bevis for indsats, og sådan fungerer det:

For det første kan enhver, der har tokens på en blockchain integreret i EOS-softwaren, vælge blokproducenterne gennem et kontinuerligt godkendelsessystem. Enhver kan deltage i blokproducentvalget, og de får mulighed for at producere blokke proportionalt med de samlede stemmer, de modtager i forhold til alle andre producenter.

Hvordan virker det?

  • Blokke produceres i runder af 21.

  • I starten af ​​hver runde vælges 21 blokproducenter. Top 20 vælges automatisk, mens den 21. vælges proportionalt med antallet af deres stemmer i forhold til de andre producenter.

  • Producenterne blandes derefter rundt ved hjælp af et pseudorandom-nummer, der stammer fra blokeringstiden. Dette gøres for at sikre, at balancen mellem forbindelser til alle andre producenter opretholdes.

  • For at sikre, at regelmæssig blokproduktion opretholdes, og at bloktiden holdes på 3 sekunder, straffes producenter for ikke at deltage ved at blive fjernet fra overvejelse. En producent skal producere mindst en blok hver 24. time for at være i betragtning.

Da der er så få mennesker involveret i konsensus, er det hurtigere og mere centraliseret end Ethereum og Bitcoin, der bruger hele netværket til konsensus.

WASM-sproget

EOS bruger WebAssembly aka WASM programmeringssprog. Årsagen til, at de bruger det, er på grund af dets følgende egenskaber (taget fra webassembly.org):

  • Hastighed og effektivitet: WebAssembly udføres ved normal hastighed ved at udnytte de almindelige hardwarefunktioner, der er tilgængelige på en bred vifte af platforme.

  • Åben og debuggable: Det er designet til at være pænt trykt i et tekstformat til debugging, test, eksperimenter, optimering, læring, undervisning og skrivning af programmer i hånden.

  • Sikker: WebAssembly beskriver et hukommelsessikkert, sandboxed-eksekveringsmiljø, der endda kan implementeres i eksisterende virtuelle JavaScript-maskiner.

EOS er den perfekte platform til at oprette Dapps i industriel skala. Lad os forestille os, at du opretter en decentral Twitter. Hvis du oprettede det på Ethereum, ville brugeren skulle bruge noget gas, mens han udførte hvert eneste trin i en tweet.

Hvis du gjorde det samme i EOS, behøver brugerne ikke bruge gas, fordi transaktionsgebyrer er 0! Da EOS ikke er så decentraliseret som Ethereum, kan Dapps, der kræver høje grader af censurmodstand, muligvis ikke være en god pasform til det.

Fantastisk

Et dybere kig på forskellige smarte kontraktplatformeStellar er hjernebarnet til Jed McCaleb, og Joyce Kim blev dannet tilbage i 2014, da det blev forked fra Ripple-protokollen. Stellar, ifølge deres hjemmeside,

“Er en platform, der forbinder banker, betalingssystemer og mennesker. Integrer for at flytte penge hurtigt, pålideligt og næsten uden omkostninger ”.

Ved hjælp af Stellar kan man flytte penge på tværs af grænser hurtigt, pålideligt og for brøkdele af en krone.

I modsætning til Ethereum er Stellar Smart Contracts (SSC) ikke Turing komplet. Følgende tabel giver dig en god idé om forskellene mellem Stellar- og Ethereum-smarte kontrakter:

Et dybere kig på forskellige smarte kontraktplatforme

Billedkredit: Hackernoon

Nogle statistikker kan dukke op med det samme.

Mest bemærkelsesværdigt er bekræftelsestiden på 5 sekunder og det faktum, at en enkelt transaktion på Stellar-netværket kun koster ~ $ 0.0000002!

$ stellarNetwork->buildTransaction ($ customerKeypair)

->addCreateAccountOp ($ escrowKeypair, 100.00006) // 100 XLM efter installationsgebyrer + overførselstransaktion

->indsend ($ customerKeypair);

}

Print "Oprettet spærret konto: " . $ escrowKeypair->getPublicKey (). PHP_EOL;

/ *

* For at gøre dette til en spærret konto skal vi bevise det for arbejdstageren

* ingen er i stand til at trække midler ud af det, mens arbejdstageren søger efter

* en forfængelighed adresse.

*

* Dette opnås ved:

* – At gøre arbejdstageren og kundens underskrivere af samme vægt (1)

* – Kræver begge underskrivere at aftale enhver transaktion (tærskler er sat til 2)

*

* Vi skal dog også håndtere sagen, hvor ingen arbejdstagere tager jobbet, og vi

* har brug for at genvinde kontoen. Dette kan gøres ved at tilføje en forhåndsgodkendt fletning

* transaktion, der ikke er gyldig før 30 dage fra nu.

*

* Dette gør det muligt for arbejdstageren at vide, at midlerne garanteres at være tilgængelige

* i 30 dage.

* /

// Indlæs spærringskontoen

$ konto = $ stellarNetwork->getAccount ($ escrowKeypair);

// Forudberegn nogle sekvensnumre, da de er nødvendige for transaktioner

$ startingSequenceNumber = $ konto->getSequence ();

// Spor, hvor mange transaktioner der er nødvendige for at oprette en escrow-konto

// Vi har brug for dette, så vi korrekt kan beregne "genvinde konto" sekvensnummer

$ numSetupTransactions = 5;

$ reclaimAccountOrPaySeqNum = $ startingSequenceNumber + $ numSetupTransactions + 1;

// Opdater kontoen med en dataværdi, der angiver, hvilken forfængelighedsadresse der skal søges efter

Print "Tilføjelse af dataindtastning for at anmode om en forfængelighedsadresse…";

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->setAccountData (‘anmodning: generereVanityAddress’, ‘G * ZULU’)

->indsend ($ escrowKeypair);

Print "FÆRDIG" . PHP_EOL;

// Fallback-transaktion: Gendan spærringskontoen, hvis ingen medarbejdere genererer

// forfængelighed adresse om 30 dage

$ reclaimTx = $ stellarNetwork->buildTransaction ($ escrowKeypair)

->setSequenceNumber (nyt BigInteger ($ reclaimAccountOrPaySeqNum))

// todo: unkommentere dette i en reel implementering

//->setLowerTimebound (ny \ DateTime (‘+ 30 dage’))

->setAccountData (‘anmodning: generereVanityAddress’)

->addMergeOperation ($ customerKeypair)

->getTransactionEnvelope ();

// Tilføj hash på $ reclaimTx som underskriver på kontoen

// Se: https://www.stellar.org/developers/guides/concepts/multi-sig.html#pre-authorized-transaction

$ txHashSigner = ny underskriver (

SignerKey :: fromPreauthorizedHash ($ reclaimTx->getHash ()),

2 // vægt skal være tilstrækkelig, så ingen andre underskrivere er nødvendige

);

$ addReclaimTxSignerOp = ny SetOptionsOp ();

$ addReclaimTxSignerOp->updateSigner ($ txHashSigner);

Print "Tilføjelse af præautoriseret tilbagekøbstransaktion som underskriver… ";

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ addReclaimTxSignerOp)

->indsend ($ escrowKeypair);

Print "FÆRDIG" . PHP_EOL;

Print "Tilføjet pre-auth reclaim-transaktion gyldig ved sekvensen " . $ reclaimAccountOrPaySeqNum. PHP_EOL;

Print "For at genvinde escrow-kontoen skal du køre 90-reclaim-escrow.php" . PHP_EOL;

// Tilføj arbejdskonto som underskriver af vægt 1

$ workerSigner = ny underskriver (

SignerKey :: fromKeypair ($ workerKeypair),

1 // kræver en anden underskriver

);

$ addSignerOp = ny SetOptionsOp ();

$ addSignerOp->updateSigner ($ workerSigner);

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ addSignerOp)

->indsend ($ escrowKeypair);

// Tilføj kundekonto som anden underskriver af vægt 1

$ workerSigner = ny underskriver (

SignerKey :: fromKeypair ($ customerKeypair),

1 // kræver en anden underskriver

);

$ addSignerOp = ny SetOptionsOp ();

$ addSignerOp->updateSigner ($ workerSigner);

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ addSignerOp)

->indsend ($ escrowKeypair);

// Forøg tærsklerne, og indstil hovedvægt til 0

// Alle operationer kræver nu en tærskel på 2

$ thresholdsOp = ny SetOptionsOp ();

$ tærsklerOp->setLowThreshold (2);

$ tærsklerOp->setMediumThreshold (2);

$ tærsklerOp->sætHøjTærskel (2);

$ tærsklerOp->setMasterWeight (0);

$ stellarNetwork->buildTransaction ($ escrowKeypair)

->addOperation ($ thresholdsOp)

->indsend ($ escrowKeypair);

udskriv PHP_EOL;

Print "Konfiguration af spærret konto er afsluttet" . PHP_EOL;

Cardano

Et dybere kig på forskellige smarte kontraktplatforme

Et af de mest interessante projekter, der er kommet ud, er Cardano. I lighed med Ethereum er Cardano en smart kontraktplatform, men Cardano tilbyder skalerbarhed og sikkerhed gennem lagdelt arkitektur. Cardanos tilgang er unik i selve rummet, da den er bygget på videnskabelig filosofi og peer-reviewed akademisk forskning

Cardano sigter mod at øge skalerbarheden via deres Ouroboros proof of stake konsensusmekanisme. For at kode smarte kontrakter i Cardano skal du bruge Plutus, som er baseret på Haskell, det sprog, der bruges til at kode Cardano.

Mens C ++ og de fleste traditionelle sprog er imperative programmeringssprog, er Plutus og Haskell funktionelle programmeringssprog.

Så hvordan fungerer funktionel programmering?

Antag at der er en funktion f (x), som vi vil bruge til at beregne en funktion g (x), og så vil vi bruge den til at arbejde med en funktion h (x). I stedet for at løse alle disse i en rækkefølge kan vi simpelthen klubbe dem alle sammen i en enkelt funktion som denne:

h (g (f (x)))

Dette gør den funktionelle tilgang lettere at resonnere matematisk. Derfor skal funktionelle programmer være en mere sikker tilgang til oprettelse af smarte kontrakter. Dette hjælper også med enklere formel verifikation, hvilket stort set betyder, at det er lettere at matematisk bevise, hvad et program gør, og hvordan det fungerer. Dette giver Cardano ejendommen “High Assurance Code”.

Lad os tage et virkeligt eksempel på dette og se, hvorfor det kan blive ekstremt kritisk og endda livreddende under visse forhold.

Antag, vi koder et program, der styrer lufttrafik.

Som du kan forestille dig, kræver kodning af et sådant system en høj grad af præcision og nøjagtighed. Vi kan ikke bare blindt kode noget og håbe det bedste, når folks liv er i fare. I situationer som disse har vi brug for en kode, der kan bevises at fungere i en høj grad af matematisk sikkerhed.

Det er netop derfor, den funktionelle tilgang er så ønskelig.

Og det er præcis, hvad Cardano bruger Haskell til at kode deres økosystem og Plutus til deres smarte kontrakter. Både Haskell og Plutus er funktionelle sprog.

Den følgende tabel sammenligner den imperative tilgang med den funktionelle tilgang.

Et dybere kig på forskellige smarte kontraktplatforme

Billedkredit: Docs.Microsoft.com

Så lad os se på fordelene ved den funktionelle tilgang:

  • Hjælper med at skabe høj sikkerhedskode, fordi det er lettere at matematisk bevise, hvordan koden skal opføre sig.

  • Øger læsbarheden og vedligeholdelsesevnen, fordi hver funktion er designet til at udføre en bestemt opgave. Funktionerne er også statsuafhængige.

  • Koden er lettere at bryde, og eventuelle ændringer i koden er enklere at implementere. Dette gør gentagelsesudvikling lettere.

  • De enkelte funktioner kan let isoleres, hvilket gør dem lettere at teste og fejle.

Neo

Et dybere kig på forskellige smarte kontraktplatforme

Neo, tidligere kendt som Antshares, er ofte kendt som “Kinas Ethereum”.

Ifølge deres hjemmeside er Neo et “non-profit community-baseret blockchain-projekt, der bruger blockchain-teknologi og digital identitet til at digitalisere aktiver, til at automatisere styringen af ​​digitale aktiver ved hjælp af smarte kontrakter og til at realisere en” smart økonomi “med en distribueret netværk. ”

Neos hovedmål er at være det distribuerede netværk til “smart økonomi”. Som deres hjemmeside siger:

Digitale aktiver + Digital identitet + Smart kontrakt = Smart økonomi.

Neo blev udviklet af Shanghai-baserede blockchain R&D firma “OnChain”. Onchain blev grundlagt af CEO Da Hongfei og CTO Erik Zhang. Forskning på Neo startede omkring 2014. I 2016 blev Onchain noteret i Top 50 Fintech Company i Kina af KPMG.

Neo ønskede at oprette en smart kontraktplatform, der har alle fordelene ved en Ethereum Virtual Machine uden at lamme deres udviklere med sprogbarrierer. I ethereum skal du lære soliditet til at kode smarte kontrakter, mens du i Neo kan endda bruge Javascript til at kode smarte kontrakter.

Neo Smart Contract 2.0

Neos intelligente kontrakt system, altså The Smart Contract 2.0, består af tre dele:

  • NeoVM.
  • InteropService
  • DevPack

NeoVm

Dette er en billedlig gengivelse af Neo Virtual Machine:

Et dybere kig på forskellige smarte kontraktplatforme

Billedkredit: Neo Whitepaper

Som Neo Whitepaper siger, er NeoVM eller Neo Virtual Machine en letvægts, almindelig VM, hvis arkitektur ligner JVM og .NET Runtime. Det svarer til en virtuel CPU, der læser og udfører instruktioner i kontrakten i rækkefølge, udfører proceskontrol baseret på funktionaliteten af ​​instruktionshandlingerne, logiske operationer og så videre. Det er alsidigt med en god opstartshastighed, hvilket gør det til et godt miljø at køre smarte kontrakter.

InteropService

InteropService øger anvendelsen af ​​smarte kontrakter. Det giver kontrakterne adgang til data uden for NeoVM uden at gå på kompromis med systemets samlede stabilitet og effektivitet.

I øjeblikket leverer det interoperable servicelag nogle API’er til at få adgang til kædekædedataene fra den smarte kontrakt. De data, den kan få adgang til, er:

  • Bloker information.
  • Transaktionsoplysninger
  • Kontraktoplysninger.
  • Oplysninger om aktiver

….blandt andre.

Det giver også lagerplads til smarte kontrakter.

DevPack

DevPack inkluderer sprogkompilatoren på højt niveau og IDE-pluginnet. Da NeoVM-arkitekturen ligner temmelig JVM og .NET Runtime, gør det det muligt at kode kontrakter på andre sprog. Som du kan forestille dig, reducerede dette udviklernes tid til at lære at oprette smarte kontrakter betydeligt.

Hyperledger stof

Et dybere kig på forskellige smarte kontraktplatforme

Ifølge deres hjemmeside “Hyperledger er en open source-samarbejdsindsats skabt for at fremme blockchain-teknologier på tværs af brancher. Det er et globalt samarbejde, hostet af Linux Foundation, herunder ledere inden for finans, bank, tingenes internet, forsyningskæder, produktion og teknologi. ”

Måske er det mest interessante projekt i Hyperledger-familien IBMs Fabric. Snarere end en enkelt blockchain Fabric er en base for udvikling af blockchain-baserede løsninger med en modulær arkitektur.

Med Fabric kan forskellige komponenter i Blockchains, som konsensus og medlemskabstjenester, blive plug-and-play. Fabric er designet til at give en ramme, hvormed virksomheder kan sammensætte deres eget, individuelle blockchain-netværk, der hurtigt kan skaleres til mere end 1.000 transaktioner pr. Sekund.

Et dybere kig på forskellige smarte kontraktplatforme

Hvad er Fabric og hvordan fungerer det? Rammen er implementeret i Go. Det er lavet til aktivering af konsortiumblokchains med forskellige tilladelsesgrader. Fabric er stærkt afhængig af et smart kontraktsystem kaldet Chaincode, som hver peer af netværkene kører i Docker-containere.

For at kunne skrive kædekode skal man være fortrolig med fire funktioner:

  • PutState: Opret nyt aktiv eller opdater et eksisterende.

  • GetState: Hent aktiv.

  • GetHistoryForKey: Hent historik for ændringer.

  • DelState: ‘Slet’ aktiv.

Følgende er et eksempel på en kædekode:

// Definer Smart Contract-strukturen

skriv SmartContract-struktur {}

// Definer bilstrukturen med 4 egenskaber.

skriv bilkonstruktion {

Lav streng `json:"lave"`

Modelstreng `json:"model"`

Farvestreng `json:"farve"`

Ejerstreng `json:"ejer"`

}

/ *

* Invoke-metoden kaldes som et resultat af en applikationsanmodning om at køre Smart Contract "fabcar"

* Det opkaldende applikationsprogram har også specificeret den bestemte smarte kontraktfunktion, der skal kaldes med argumenter

* /

func (s * SmartContract) Invoke (APIstub shim.ChaincodeStubInterface) sc.Response {

// Hent den anmodede Smart Contract-funktion og argumenter

funktion, args: = APIstub.GetFunctionAndParameters ()

// Rute til den relevante handlerfunktion for at interagere korrekt med hovedbogen

hvis funktion == "initLedger" {

returner s.initLedger (APIstub)

} ellers hvis funktion == "createCar" {

returner s.createCar (APIstub, args)

}

return shim.Error ("Ugyldigt Smart Contract-funktionsnavn.")

}

func (s * SmartContract) initLedger (APIstub shim.ChaincodeStubInterface) sc.Response {

return shim.Success ([] byte ("Ledger kører nu, succes!"))

}

// Tilføj ny bil til databasen med opnåede argumenter

func (s * SmartContract) createCar (APIstub shim.ChaincodeStubInterface, args [] string) sc.Response {

hvis len (args)! = 5 {

return shim.Error ("Forkert antal argumenter. Forventer 5")

}

var car = Car {Make: args [1], Model: args [2], Color: args [3], Ejer: args [4]}

carAsBytes, _: = json.Marshal (bil)

APIstub.PutState (args [0], carAsBytes)

return shim.Success (nul)

}

funk main () {

// Opret en ny Smart kontrakt

err: = shim.Start (ny (SmartContract))

hvis fejlagtigt! = nul {

fmt.Printf ("Fejl ved oprettelse af ny Smart kontrakt:% s", fejle)

}

}

Konklusion

Så der har du det. Nogle af de smarte kontraktplatforme og de forskellige egenskaber, der gør dem unikke. Der er ingen ”one-size-fits-all”, i det mindste i øjeblikket. Du bliver nødt til at vælge den platform, der bedst passer til de funktioner, der kræves til din Dapp.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me