NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPressNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HomeBlogEnterprise Blockchain

Blockchain vs Distributed Ledger Technologies (DLTs): Del 2

En komparativ analyse av arkitekturen og styringsdynamikken til Ethereum, Hyperledger Fabric og R3 Corda. av ConsenSys 23. mai 2018 Publisert 23. mai 2018

Dette er del 2 av en todelt komparativ analyse av Ethereum, Hyperledger Fabric og R3 Corda. Les del 1 av Blockchain vs. DLT. 

Blockchain vs Distribuerte Ledger-teknologiplattformer

Det skal erkjennes at hvis databasekoordinering og mer effektiv tildeling av kode er ønsket funksjonalitet i et system, så er det ikke nødvendigvis at blockchain nødvendigvis er løsningen som en organisasjon leter etter. Distribuerte lederteknologi (DLT) -systemer som Hyperledger Fabric eller R3 Corda kan ha lignende funksjoner som blockchain-systemer, men det bør tas i betraktning at blockchains er en egen delmengde av distribuerte reskontorer som har ekstra funksjonalitet utover kodekoordinering. Blokkjeder er i stand til funksjoner som distribuerte hovedbøker ikke er i form av instantiering av digital verdi basert på sammensetningen av systemet.

I dette dokumentet vil arkitektoniske hensyn bli utforsket som identifiserer aspektene som bidrar til blockchain-funksjonalitet. En undersøkelse vil være at det kanskje er en avveining mellom hva blockchains er i stand til og hva DLT’s gir. DLT var ment for transaksjonsbehandling i et delt pålitelig miljø, mens ekte blokkjeder var designet for å ofre behovet for et klarert oppsett for å oppnå høy troskap og uforanderlighet av kontoer. Aspekter av høy trofasthet og uforanderlighet er integrerte for suksessen med å digitalisere eiendeler på riktig måte. Analysen fra dette dokumentet vil legge over arkitektoniske komponenter på tvers av forretningsprosesser for å ytterligere belyse disse teknologiske nyansene på tvers av plattformer.

Det er viktig å skille mellom teknologibunker og hvordan de sammenlignes når det gjelder funksjonalitet og brukssaker. Mens distribuert hovedboksteknologi var sterkt påvirket av blockchain-teknologi, bør vi skille arkitektoniske hensyn til teknologiplattformene.

Sammenligninger vil bli gjort basert på flere viktige kjennetegn som finnes i programvareplattformene. Hovedområdene som vil bli utforsket i dette dokumentet inkluderer:

• Stat: Staten refererer til hovedenheten for logikk som kode kan bestå av for å lette representasjonen av informasjon i et datamiljø. Selv om tilstand kan ha forskjellige betydninger i forskjellige sammenhenger, består bruk av tilstand i blockchain og distribuert hovedboksmiljø av den nåværende konfigurasjonen av en datastrukturs ontologiske karakteristikk.
• Transaksjoner: I et blockchain-miljø betraktes transaksjoner som beregningshendelser som kan føre til generering av tilstands- eller tilstandsoverganger som skjer i utviklingsøkosystemet. Transaksjoner kan enten starte kontrakter eller påkalle eksisterende kontrakter.
• Smarte kontrakter: Ved å vurdere en blockchain-plattform fra et arkitektonisk perspektiv, er det viktig å bestemme strukturen til den smarte kontraktskoden og hvordan den fungerer i forhold til den faktiske blockchain-nettverkstopologien. Smarte kontrakter regnes som de enkelte enhetene kode som utfører handlinger i plattformens økosystem.

Tabellen nedenfor viser en kort oversikt over de viktigste forskjellene mellom de forskjellige teknologiske funksjonene til de respektive plattformene.

En oversikt over de teknologiske egenskapene til Ethereum, Hyperledger Fabric og R3 Corda.

I. Stat

Ethereum

Som et økosystem med delte distribuerte konfigurasjoner, instanserer Ethereum konseptet “State” via en konfigurasjon av objekter kalt “Accounts”. Det er to typer kontoer i Ethereum:

• Kontraktskontoer – kontoer kontrollert av kontraktskode
• Eksternt eide kontoer – kontoer som styres av en privat nøkkel

Ethereum bruker begrepet verdensstat som er en kartlegging av kontoadresser og kontotilstander. State_Root er en Patricia Merkle Tree-rot for sammenslåingen av kontoer i systemet. Og innenfor regnskapet er kontraktsstatene også organisert i denne Patricia Merkle Tree-datastrukturen. Rotens hash av staten kan brukes til å sikre identiteten til dataene i merkle-treet som tillater replikering i hele nettverket, noe som til slutt resulterer i systemets teoretiske uforanderlighet..

Ekte blokkeringer skiller seg fra DLT basert på deres avhengighet av denne Patricia Merkle Tree-datastrukturen og deres orkestrering mellom blokker, som brukes til å øyeblikkeliggjøre systemets tilstand. Dette konseptet er integrert i dataintegriteten, gyldigheten og troskapen til en blockchain-systemarkitektur.

Kommentar

Funksjonaliteten som Ethereum World State skaper er et tillitsløst system som tillater instantiering av verdi i et digitalt format. Kilder til digital representasjonsverdi som er innfødt i tokenøkonomien, kan hentes fra sammensetningen av kontoer og underdatastrukturer til Ethereum; på samme måte som logiske porter er i stand til å sette i gang funksjonelle algoritmer i tradisjonell engineering.

Plattformer avledet av Ethereum, inkludert Ethereum-klienter og private implementeringer, kan dra nytte av denne økningen av verdi ved overbevisning om disse standardene med hensyn til statlig bevaring og implementering av logikk. Plattformer som ikke klarer å sette i gang en av disse logiske verdibaserte funksjonene, vil ikke kunne legge til rette for å skape sanne desentraliserte digitale aktivaverdier.

Hyperledger stoff

I Hyperledger Fabric bevares tilstanden i en databasestruktur med avhengighet av nøkkel- / verdilagre for staten. Samspillet mellom Chaincode-programmer og hvordan de installeres i plattformstopologien, gjør det mulig å utstede kommandoer og handlinger i systemet. Disse handlingene resulterer i oppdateringer til datalagrene ettersom transaksjoner resulterer i oppdateringer til staten som er kjent som hovedboken. Hovedboka er formulert som en delt distribuert database som gir brukerne overlegen tilgang til informasjon og transaksjoner som skjer i det distribuerte databehandlingsmiljøet. Staten er nestet i databasemiljøet via tradisjonelle programvareutviklingsverktøy:

• LevelDB oppretter en nøkkel- / verdidatabase
• CouchDB vil ha Document JSON-databasen

I stoffarkitekturen kan databaseformatet for hvordan alle prosessene er organisert øke transaksjonsbehandlingen og maksimere beregningseffektiviteten i økosystemet.

I tilstandsdatabasen lagres de siste versjonsverdiene for nøkler i kjedetransaksjonsloggen som nøkkel / verdipar. Nøkkelverdier kjent som verdensstaten indekseres for å se på transaksjonsloggene som finnes i kanalarkitekturen. CouchDB fungerer som en egen databaseprosess som mottar oppdateringer fra kjedekode-API-ene.

Kommentar

Hyperledger Fabric har opprettet en prosess som erstatter nøkkelprinsippene i et blockchain-system i bytte for å oppnå overganger med høy gjennomstrømningstilstand. Bruken av den nåværende arkitekturen gjør det mulig for stater å modifisere og manifestere seg i et tradisjonelt programvareskjema, noe som resulterer i lese- / skrivetilgang. Selv om ordningen av tilstand i stoffmiljøet er effektiv, mangler den muligheten til å sette pris på et offentlig desentralisert økosystem, på samme måte som en ekte blockchain som Ethereum eller Bitcoin ville være i stand til å gjøre. Bevegelsen av data i programvaremiljøet til Fabric er en indikasjon på hva en distribuert database er i stand til. Opprettelsen av digitale eiendeler i Fabric vil i det vesentlige være digital informasjon lagret i en database som kontrolleres av de kontrollerende partene eller gruppene i et konsortium uten å følge den økonomiske strukturen til de digitale varene..

R3 Corda

I R3 Corda er State basert på sekvensering og versjonering av forskjellige datasett innen plattformarkitekturen. I systemet opprettholder nettverket et hvelv, som er en database som lagrer de historiske tilstandene som spores i systemet. I Corda anses staten å omfatte ugjennomsiktige data som kan sammenlignes med en diskfil som ikke nødvendigvis er oppdatert, men heller brukt til å generere nye etterfølgere. Dette systemet fungerer som en serie med modifiserte og overflatebehandlede tilstandsoppdateringer i et miljø som kontrolleres og deles av brukerne.

Hovedbok betraktes som settet med alle gjeldende tilstander som er aktivert. Dette låner fra bitcoin UTXO-modellen, men implementerer ikke de samme tilstandsbevarende egenskapene til Patricia Merkle Trees som eksisterer i blockchain-teknologi, men bruker heller noe av teknologien i underdeler av plattformen i motsetning til kjernen. Mens stater fungerer som forekomster av klasser som er lagret i hvelvet, gir sekvensering og versjonering av dataene en levedyktig måte å lagre dataene på..

I Corda regnes stater som klasser som lagrer data. Klasser er implementeringer av “ContractState” -grensesnittet som fungerer som interoperabilitetslag i plattformen. Visse “statlige” datafelter kan omfatte:

• Utstedelse
• Eieren
• faceValue og Amount>
• forfallsdato

Formatet på dette designet var å tillate vedlegg av data i en kjede av hendelser, slik at muligheten til å spore herkomst til hvor data kommer fra i det kontrollerte miljøet. Herkomst styres av medlemmene i konsortiet som har visse tilgangskontroller til programvareplattformen. Ved å bruke dette oppsettet vil banker og finansinstitusjoner kunne maksimere effektiviteten når det gjelder behandling av informasjon i et delt resursøkosystem. Data kan bedre flyttes og behandles mellom organisasjoner, samtidig som behovet for betydelig tillit mellom upålitelige motparter reduseres.

Kommentar

Dette arkitektoniske oppsettet er på samme måte i stand til å behandle delte data i et semi-pålitelig miljø der motparter ikke trenger å stole fullt på hverandre. Data kan behandles og legges til i det Corda anser som tilstand, selv om plattformen mangler komponenter i et blockchain-system som kan avsløre entydig verdi. I Corda er tilstand ikke en logisk konstruksjon, men heller deler av informasjon lagt til en databaselignende hovedbok. Selv om eiendeler kan digitaliseres og lagres i det brukte og ubrukte tilstandsformatet, vil eiendelene ikke være i stand til å være forskjellige verdienheter som ligner på hvordan Bitcoin, Ethereum og tokenøkonomien skaper nye markeder, selv om bankprogramvaren kan være en god klarert. oppsett som kan bidra til å fungere som et attestasjonsknutepunkt for sikker ikke-offentlig informasjon, i likhet med hvordan banksystemet for tiden fungerer i dag.

II. Transaksjoner

Ethereum er et transaksjonsbasert maskinøkosystem der den globale statusen for transaksjoner lagres i blokkene. Når transaksjoner skjer, resulterer statlige overganger i nye tilstander i systemet. Denne prosessen ofrer hastigheten på rask databasetransaksjonsbehandling for integriteten til et system som symboliserer staten så vel som transaksjonen som førte til den tilstanden i blockchain Patricia Merkle Tree datastrukturkonfigurasjon.

Innenfor denne arkitekturen er tilstand sammen med transaksjonene som fører til statsoverganger bevart i et programvareparadigme som bruker Patricia Merkle Trees for å låse data inn i en historisk virkelighet som blir realisert innenfor blokkene.

Det er to typer transaksjoner:

• Melding samtaler
• Kontraktskreasjoner.

Transaksjoner inkluderer en intern mekanisme for verdioverføring. Verdioverføring på kontraktskontoer fører til endringer i staten. Fordi systemet er basert på overføring av verdi mellom smarte kontrakter som eksisterer mellom hendelser i utførelse av transaksjoner, kan de forskjellige delte tilstandene brukes til å sette i gang høy troverdighetslogikk og avtaler.

Kommentar

Det viktigste kjennetegnet ved Ethereum er at transaksjoner brukes som de enkelte prosessenhetene i Ethereum blockchain-miljøet, og gjennom denne konfigurasjonen holder du en permanent oversikt over transaksjonstilstander i systemet. Ethereum er i stand til både tradisjonelle distribuerte hovedbokdatabaserelaterte teknologiske evner, samt å koble ønsket tillit med digital verdi. Teknologier avledet av Ethereum blockchain er i stand til å gruppere transaksjoner og forretningslogikk i blokker i en blockchain. Forretningsfunksjonalitet hentet fra dette oppsettet inkluderer:

• Ekte digital økonomi
• Digitale varer og eiendeler kontrollert av økonomiske insentiver i motsetning til organisatoriske / monopolistiske insentiver
• Samhandlingsgrensesnitt mellom private institusjoner og den offentlige digitale økonomien

Arkitekturen til Ethereum gjør det mulig for tilknyttede plattformer å kunne sette i gang kryptoøkonomiske insentivlag i systemet. Dette betyr at forskjellige insentivlag og mekanismedesign kan opprettes for å sikre det generelle nettverket, i motsetning til avhengighet av sentralt kontrollerte tjenester levert av tradisjonell programvaredesign. Dette kryptoøkonomiske insentivlaget kan brukes på både den digitale vareøkonomien så vel som grensesnittlaget mellom private og offentlige versjoner av en blockchain-plattform..

Hyperledger stoff

Alle transaksjoner utføres innenfor Fabric flerkanalsarkitektur for å sikre høy transaksjonsgjennomstrømning i det pålitelige miljøet. Transaksjoner legges til en delt hovedbok som eksisterer i kjøretidsmiljøet. Med denne arkitekturen tillater Fabric lese- / skrivetilgang og tilpasning til deres programvaremiljø, slik at mainframe-lignende funksjonalitet og brukervennlighet er mulig. Det er kjent at SQL-databaser er flere størrelsesordener mer effektive enn noen blokkjede som er tilgjengelig for øyeblikket, og konfigurasjonen av Fabric låner mye fra paradigmer som brukes i tradisjonelle databaseverktøy som muliggjør overlegen transaksjonsgjennomstrømning.

Det er to typer transaksjoner:

• Distribuere transaksjoner – opprett ny kjedekode. Installer kjedekoden i programvareutviklingsmiljøet
• Påkalle transaksjoner – påkaller tidligere opprettet kjettingkode og tilhørende funksjoner. Når dette er vellykket utført, oppfyller kjedekoden en funksjon og introduserer endringer i tilstanden
• Påkalle funksjoner resulterer i ‘få’ eller ‘angi’ transaksjoner

For å maksimere effektiv databehandling og overlegne hastigheter blir individuelle transaksjoner AKA-blobs batches av en Apache Kafka bestillingstjeneste og utgitt som “blokker” gjennom en leveringshendelse. Transaksjonene (blobs) blir bestilt av Apache Kafka Ordering Service og vedlagt Kafka-partisjonene. Hva dette betyr er at Fabric-arkitekturen ofrer integriteten og datatroden til et ekte blockchain-system for å oppnå raskere transaksjonsbehandling og gjennomstrømning i et pålitelig datastreamingsmiljø som fremgår av bruken av Apache Kafka Ordering Service.

Som det kan vurderes fra stoffdokumentasjon, legges de bestilte transaksjonene direkte til partisjonene tilknyttet Kafka-emnene. Dette resulterer i transaksjoner med høy gjennomstrømning som skjer i et klarert datastreamingsmiljø. (Kilde: Apache Kafka)

Kommentar

Selv om systemet benytter seg av blockchain-aktig terminologi, er dette ikke en blockchain i tradisjonell forstand, ved at det ikke er noen bevaring av statlige og komplementære transaksjoner i en Patricia Merkle Tree-datastruktur. Hyperledger Fabric er en DLT, ikke en blockchain. Arkitekturen til Fabric ble designet for overlegen transaksjonsbehandling, slik det fremgår av tilføyelsen av datablobs i Kafka-datastreaming-bestillingstjenesten. Fordi dette oppnås i et pålitelig miljø, kan henrettelser fritt forekomme i systemet. Bruken av denne konfigurasjonen i et verdioverføringssystem ville ikke være ideell, med tanke på at all tillit må tilskrives direkte en programvarearkitektur fra en enkelt enhet i motsetning til et delt økosystem eller en protokoll. Som det fremgår av de tekniske dokumentene, har Fabric arkitektonisk avvist dataintegritet og sikkerhet oppnådd i blockchain-plattformer for å få overlegen behandling mellom transaksjonskomponentene.

R3 Corda

I R3 Corda betraktes transaksjoner som forslag til oppdatering av databasen Vault, som kan refereres til som reskontro. Transaksjoner må utføres i et miljø der notarius kan validere at de ikke er dobbelt brukt, og at de er signert av nødvendige parter. Dette ligner konseptet som brukes i bitcoin-økosystemet, selv om det er mulig å unngå dobbeltbruk av et pålitelig system.

Det er to grunnleggende typer transaksjoner:

• Notary-change transaksjoner – disse utføres for å sykle gjennom notarer i systemet. Notarius vil forhindre dobbeltbruk og kan validere transaksjoner
• Gi enighet om unikhet
• Generelle transaksjoner – brukes til alt annet

Transaksjoner er foreslåtte oppdateringer til tilstanden til databasemiljøet som krever at signaturer valideres fra andre parter i systemet. For at en transaksjon skal være gyldig, må den:

1. Bli signert av de involverte partene
2. Bli validert av kontraktskoden som bestemmer transaksjonen

Bruk av den UTXO-lignende modellen i et delt databasemiljø gjør det mulig for Corda-plattformen å kontrollere tilstanden så vel som overgangene. Bruk av Notarius og ulike interaksjoner mellom Flows og Cordapps i nettverkskonfigurasjonen viser et delt distribuert miljø der tilstanden er bevart i et dataformat integrert i systemarkitekturen. Bruken av transaksjoner for å navigere i instantiering av tilstander i det nodebaserte miljøet mellom strømninger så vel som Cordapps som blir programmert i noder, indikerer et levedyktig middel for å utføre tilstandsendringer i en hovedbok.

Kommentar

For dannelsen av digitale eiendeler, avhenger brukere og motparter av tilliten til den samlede Corda-plattformen. Mens det fungerer som et sterkt pålitelig delt distribuert hovedbokssystem for å holde sensitive økonomiske data, fungerer systemet i samsvar med ulike standarder som finnes i bankøkosystemet. Plattformen gir:

• Overlegen lagring av ikke-offentlige økonomiske data
• Klarert oppsett for ikke-tillitsfulle finansinstitusjoner
• Avansert hvelving av forretningsinteraksjoner

Arkitektoniske diagrammer som involverer strømmer og kjøretidsmiljøer mellom noder viser at Corda ble designet for å partisjonere tilgang mellom de pålitelige medlemmene av konsortieplattformen. Selv om det er i stand til visse aspekter av brukervennlighet, mangler R3 Corda funksjonalitet som ligger i å være et universelt underlag for økonomisk, sosial og politisk verdioverføring, på grunn av mangel på et kryptoøkonomisk incentivlag samt et offentlig digitalt aktivumiljø. Fordi systemet er lukket, mangler det nødvendige skinner og teknologiske egenskaper for å bygge et økonomisk insentivdrevet økosystem rundt. R3 Corda er mest sannsynlig best brukt for visse fasetter av tradisjonell bankinfrastruktur, men ikke oppretting av digital eiendel.

III. Smarte kontrakter

Ethereum

I Ethereum skrives smarte kontrakter på høyt nivå programmeringsspråk som soliditet, LLL eller Viper og kompileres til EVM-bytekode, slik at binærfiler kan utføres av Ethereum Virtual Machine (EVM). Noder i Ethereum-nettverket kjører sin egen EVM-implementering som fungerer som et kjøretidsmiljø for smarte kontrakter i Ethereum-økosystemet. Stat og transaksjoner som fører til statlige overganger er emblemisert i Ethereum-blockchainens verdensstat gjennom replikering av EVM, noe som resulterer i et system som kan implementere uforgjengelig tillit på en rekke spektrum.

EVM fungerer som et kjøretidsmiljø for å rekursivt utføre tilstandsoverganger for å beregne systemtilstanden og maskintilstanden når den løper gjennom transaksjonene.

• Systemtilstand = Ethereum global tilstand
• Maskinstatus = forretningslogikk for kontraktskontoer & koden replikert i løpet av EVM-kjøretiden

Ettersom all smart kontraktkode replikeres av alle noder i EVM, er Ethereum blockchain og relaterte instantiations i stand til å bevare gyldigheten av koden for å sikre konsistensen av kontraktene. Konsistensen av kontraktene bidrar til den praktiske uforanderligheten til Ethereum blockchain og dets tilknyttede kunder og implementeringer. Smarte kontrakter på Ethereum binder hele økosystemet sammen gjennom øyeblikkelige transaksjoner som til slutt resulterer i overganger til nye stater i det generelle virtuelle maskinmiljøet.

Kommentar

Fordi implementeringer av EVM overholder spesifikasjonene som angitt i Ethereum Yellow Paper, er forskjellige instantiasjoner av Ethereum (offentlig, privat og konsortium) i stand til interoperabilitet som bestemt fra den vanlige samlingen av språk på høyt nivå – i form av smart kontrakter – inn i Ethereum bytecode av EVM. Fra denne disposisjonen til Ethereum er den i stand til å fungere som det mellomliggende laget mellom forskjellige fasetter av store institusjonelle private datafasiliteter og den offentlige digitale vareøkonomien som for tiden utvikler seg og kommer til å bli oppfylt av den nylige etableringen av tokenøkonomien..

Ved å tillate denne funksjonaliteten mellom Ethereum-kjeder, kan hele interoperable systemer bygges som tildeler økonomisk finalitet mellom systemer for datakoordinering og -behandling i private Ethereum-plattformer til digitale varer i den offentlige kjeden. Smarte kontrakter på Ethereum inkapsler programmerbar logikk i disse systemene og lar utviklere samhandle med Ethereum Virtual Machine gjennom transaksjoner som skaper nye statsmiljøer innenfor den teknologiske infrastrukturen. Ettersom omfattende brukstilfeller utvikler seg i interoperable offentlige kjede-, private kjede- og konsortiekjedemiljøer, vil smarte kontrakter som brukes i Ethereum være i stand til å binde systemene sammen under et felles logisk grensesnitt.

Hyperledger stoff

Chaincode er ikke nødvendigvis en smart kontrakt distribuert i en kontobasert blockchain, men snarere et program som er installert og som deretter implementerer et grensesnitt gjennom et API. API-grensesnittet krever kodebaserte instruksjoner for å lede forretningslogikk og funksjonalitet i hele systemet, i likhet med et tradisjonelt programvareutviklingsmiljø. Metoder tilknyttet API inkluderer:

• Innledende – initiering av søknadsstatus
• Påkalle – behandler transaksjonsforslag

Chaincode må implementere grensesnitt fra API:

• Chaincode-grensesnitt
• ChaincodeStubInterface

I Hyperledger Fabric kjøres kjettingkoden i sikre Docker-containere, der den er isolert fra prosesser utført av den godkjente kollegaen. Koden er vanligvis skrevet i Go eller Node.js, slik at interaksjon som håndterer forretningslogikken. En nyanse å huske på er at stoffkjedekoden ikke replikeres av nodene i økosystemet på samme måte som det forventes av en ekte blockchain-arkitektur.

Chaincode ble opprinnelig installert på Peers og deretter instantiert i kanaler. Prosessflyten er detaljert i følgende diagrammer:

Gjennom kjedekodeprosessflyten oppstår ulike interaksjoner med systemkjedekode, som kjører i en kjørbar peer-prosess versus en isolert beholder. Dette brukes til å implementere systematferd uten godkjenningspolicyer eller livssyklusprosesser. Systemkjedekoden går ikke gjennom kodenes livssyklus til vanlig kjedekode. To funksjoner fra Shim API i kjedekodegrensesnittet blir implementert. Koden blir samlet og vedlikeholdt av jevnaldrende. Chaincode er ikke tilknyttet kanaler eller bestillere før utvikleren bestemmer at de ønsker å installere programmet videre.

Chaincode kan konfigureres til å opprette eiendeler som til slutt fungerer som nøkkelverdipar som er lagret i reskontradatabasen. Arbeidsflyten for å sende startkommandoer og påkalle transaksjonene er beskrevet i diagrammet ovenfor når det gjelder hvordan kommandoer flyttes gjennom systemet. Virksomhetslogikken er kodet innenfor reglene i nettverket og påkalt via applikasjoner på klientsiden. Kodekoordinering og interaksjon er veldig indikativ for tradisjonell programvareutvikling gjennom avhengighet av tradisjonelle funksjoner og initieringsgrensesnitt.

Kommentar

Bevegelsen av Chaincode gjennom denne nettverkskonfigurasjonen muliggjør en strømlinjeformet organisering av systemet. Programvarearkitekturen er primert for å fungere som en veldig effektiv kommando- og kontrollstruktur når det gjelder distribusjon av data og organisering av programvareutviklingsmiljøet for visse virksomhetsbruk. Som det kan sees fra pakken, installere, sette i gang og oppgradere, var denne arkitekturen designet for å optimalisere de nødvendige berøringspunktene som kreves for å behandle koden. De nødvendige API-grensesnittene når transaksjoner blir behandlet, minner sterkt om tradisjonell programvaredesign. Merknader:

• Monolitisk arkitektur for maksimal kontroll
• Sikret forretningsinteraksjon mellom motparter
• Sentralt koordinert behandling for gjennomføring av transaksjoner

Chaincode er mer et system med kommandoer enn det er et smart kontraktspråk som blir replikert av en blockchain. Siden Hyperledger Fabric-økosystemet har et levende sett med sterke egenskaper når det gjelder funksjonalitet og design som en distribuert hovedbok, mangler systemet faktisk de iboende egenskapene til et ekte blockchain-system. Som et verktøy som er brukbart for integrering med eldre infrastruktur og paradigmer, er Fabric effektiv på grunn av sin overholdelse av eksisterende programvarestandarder, som kan trekkes fra den arkitektoniske utformingen som beskrevet ovenfor.

Hvor Fabric får funksjonalitet når det gjelder systemet som er noe symbolsk for systemer designet rundt store hovedrammer og datasentre, taper det i andre aspekter når det gjelder distribuert forbindelse til økonomiske beregningsfaktorer som kan nås i en iboende desentralisert digital token-økonomi . Hvis Fabric skulle integreres i et ekte blockchain-miljø, ville det passe godt som et sikkert distribuert databasemiljø som validerer informasjon før interaksjon med et offentlig blockchain-økosystem.

R3 Corda

I Corda betraktes smarte kontrakter som klasser som implementerer kontraktgrensesnittet. Smarte kontrakter er skrevet i Java / Kotlin og blir samlet gjennom Java Virtual Machine (JVM), som er datamaskinen som koden kjøres innenfor. Hovedfunksjonen som brukes i kontraktene er “verifiser” -funksjonen.

Koden kjører på JVM der transaksjoner behandles gjennom notariseringssystemet, og forretningslogikken er begrenset innenfor strømmer som kan huse og isolere forretningsprosessen mellom forskjellige motparter.

Smart kontrakt komponenter:

• Kjørbar kode
• Validerer endringer i transaksjoner
• Statlige gjenstander
• Data som holdes på hovedboken
• Kontrakts gjeldende tilstand
• Bruker input og output av transaksjoner
• Kommandoer
• Tilleggsdata
• Brukes til å instruere kjørbar kontraktskode

Java og Kotlin-koden blir samlet ned til identisk bykode via JVM. Kommandoer sender tilleggsdata som ikke eksisterer i staten til kontraktskoden. Kommandoer fungerer som datastrukturer med vedlagte offentlige nøkler som brukes til å signere transaksjoner, men det bør erkjennes at kontrakter ikke fungerer direkte med de digitale signaturene. Kontrakter i dette miljøet replikeres gjennom hele systemet i sammenheng med hvordan Flows er villige til å koordinere mellom pålitelige parter.

Kommentar

Kontraktskoden passer behovene til brukstilfeller i Corda-miljøet, og er i stand til å utføre de nødvendige funksjonene for gjennomføring av transaksjoner. Begrensninger inkluderer interoperabilitet med andre økosystemer. For at systemene skal kunne samarbeide med Corda, må de bruke Corda-kontraktkoderammeverket designet rundt den lukkede DLT. I motsetning til en ekte blockchain-plattform som Ethereum som kan fungere som interoperabilitetslaget mellom økonomiske prosesser og funksjoner mellom private instantiations og offentlige instantiations, begrenser Corda seg ved å være mer fokusert på prosesser i et lukket system. Bruken av JVM er nyskapende, selv om forekomsten er isolert i Corda-økosystemet. I dette scenariet får Corda transaksjonsbehandling i et sikret miljø mens det ofrer muligheten til å samhandle og koordinere mellom forskjellige blockchain-miljøer som et interoperabelt system ville være i stand til å gjøre.

IV. Konklusjon og vurdering

Basert på analysen vår er de viktigste skillefaktorene som Ethereum er i stand til å implementere utover det som er i stand til DLT:

• Digital eiendel eller symboløkonomi
• Kryptoøkonomiske insentivlag i protokollen
• Interoperabilitet mellom konsortium og offentlige blokkjeder

Mens DLT-er som R3 Corda og Hyperledger Fabric er i stand til å oppnå funksjonalitet i den delte databaseadministrasjonen og transaksjonsbehandlings-livssyklusen, er det ikke garantert at de vil kunne oppnå nøkkelfunksjonalitetene som beskrevet ovenfor. Disse plattformene er ikke feil, men heller begrenset i sin arkitektoniske konfigurasjon for å vise noen av de rene brukssakene som bare ekte blokkjeder er i stand til å hevde.

Blockchain-teknologier er designet for å koble den tilliten som er instansert i dem, sammen med den konkrete verdien som skapes fra den tilliten. Bare gjennom en ekte plattform bygget fra kjernen til en blockchain, vil sosiale, politiske og økonomiske systemer kunne bli grunnlagt viet innenfor infrastrukturen til en programvareprotokoll. Mens DLT-fokuserte databaseadministrasjonsplattformer kan integreres og samhandle med en blockchain-plattform, må skinnene som verdioverføring og koordinering av denne tilliten vil bygges, være en blockchain som legemliggjør kjerneprinsippene med tillit, uforanderlighet, integritet og informasjonstro..

Hva denne analysen avslører, er ikke at visse systemer er bedre enn andre, men de er heller nyttige i forskjellige kapasiteter. DLT-plattformers evne til å fungere som private distribuerte databaser med høy transaksjonsgjennomstrømning og funksjonalitet, tillate dem å fungere som pålitelige systemer som kan samhandle innenfor en blockchain-plattform når visse aspekter av privat informasjon er nødvendige for vurdering, for eksempel bank / finansiell sensitiv informasjon om den indre virksomheten til en privat institusjon som ikke skal avsløres for publikum. De forskjellige forretningsmodellene for hvordan du bruker disse kildene til private data tilknyttet DLT, er fremdeles under utvikling, og det bør tas i betraktning med tanke på blockchain-grensesnitt, da et desentralisert digitalt verdisystem er nødvendig for noen av interaksjonene mellom blockchains og DLTs.

Ta kontakt med våre blockchain-eksperter

Vårt globale løsningsteam tilbyr blockchain-opplæring, strategisk rådgivning, implementeringstjenester og partnerskapsmuligheter. Kontakt oss Nyhetsbrev Abonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser med mer. E-postadresse Eksklusivt innholdGuide

Komplett guide til Blockchain Business Networks

Webinar

Introduksjon til tokenisering

Webinar

Fremtidens økonomi: digitale eiendeler og deFi

Webinar

Hva er Enterprise Ethereum?

Hvitt papir

Sentralbanker og pengens fremtid

Case Stud

Komgo: Blockchain for handelsvareøkonomi

Mike Owergreen Administrator

Sorry! The Author has not filled his profile.

follow me