NyheterUtvecklareFöretagBlockchain förklaradeHändelser och konferenserPressNyhetsbrev

Prenumerera på vårt nyhetsbrev.

E-postadress

Vi respekterar din integritet

HomeBlogEnterprise Blockchain

Blockchain vs Distributed Ledger Technologies (DLT): Del 2

En jämförande analys av arkitekturerna och styrdynamiken för Ethereum, Hyperledger Fabric och R3 Corda. av ConsenSys 23 maj 2018 Publicerad 23 maj 2018

Detta är del 2 av en tvådelad jämförande analys av Ethereum, Hyperledger Fabric och R3 Corda. Läs del 1 av Blockchain vs. DLT. 

Blockchain vs Distribuerad Ledger-teknikplattformar

Det bör erkännas att om databaskoordinering och effektivare allokering av kod är den önskade funktionaliteten i ett system, så kan blockchain inte nödvändigtvis vara den lösning som en organisation letar efter. Distribuerad ledteknik (DLT) -system som Hyperledger Fabric eller R3 Corda kan ha liknande funktioner som blockchain-system, men det bör tas i beaktande att blockchains är en separat delmängd av distribuerade reskontrar som har ytterligare funktioner utöver kodkoordinering. Blockkedjor har funktioner som distribuerade huvudböcker inte är i termer av instantiering av digitalt värde baserat på systemets sammansättning.

I detta dokument kommer arkitektoniska överväganden att undersökas som identifierar de aspekter som bidrar till blockchain-funktionalitet. En undersökning skulle vara att det kanske finns en avvägning mellan vad blockkedjor kan åstadkomma och vad DLT erbjuder. DLT var avsedd för transaktionsbehandling i en delad betrodd miljö medan riktiga blockkedjor var utformade för att offra behovet av en betrodd installation för att uppnå hög trohet och oföränderlighet hos konton. Aspekter av hög trohet och oföränderlighet är integrerade för att digitalisera tillgångar på rätt sätt. Analysen från detta dokument kommer att täcka arkitektoniska komponenter över affärsprocesser för att ytterligare belysa dessa tekniska nyanser över plattformar.

Det är viktigt att göra skillnader mellan teknikstaplar och hur de jämför med avseende på funktionalitet och användningsfall. Medan distribuerad huvudboksteknik var starkt påverkad av blockchain-teknik, bör vi skilja på arkitektoniska överväganden av teknikplattformarna.

Jämförelser kommer att göras baserat på flera viktiga kännetecken som finns inom programvaruplattformarna. De viktigaste områdena som kommer att utforskas i detta dokument inkluderar:

• stat: Staten hänvisar till den huvudenhet för logik som koden kan bestå av för att underlätta representationen av information i en datormiljö. Även om tillstånd kan ha olika betydelser i olika sammanhang, består användningen av tillstånd inom blockchain och distribuerad huvudmiljö av den nuvarande konfigurationen av en datastrukturs ontologiska egenskaper.
• Transaktioner: Inom en blockchain-miljö betraktas transaktioner som beräkningshändelser som kan leda till generering av tillstånds- eller tillståndsövergångar som sker inom utvecklingsekosystemet. Transaktioner kan antingen initiera kontrakt eller anropa befintliga kontrakt.
• Smarta kontrakt: Vid bedömningen av en blockchain-plattform ur ett arkitektoniskt perspektiv är det viktigt att bestämma strukturen för den smarta kontraktskoden och hur den fungerar i förhållande till den faktiska blockchain-nätverkstopologin. Smarta kontrakt betraktas som de enskilda kodenheterna som utför åtgärder inom plattformens ekosystem.

Följande tabell visar en kort översikt över de viktigaste skillnaderna mellan de olika tekniska egenskaperna på respektive plattform.

En översikt över de tekniska funktionerna i Ethereum, Hyperledger Fabric och R3 Corda.

Jag påstår

Ethereum

Som ett ekosystem med delade distribuerade konfigurationer initierar Ethereum begreppet “State” via en konfiguration av objekt som heter “Accounts”. Det finns två typer av konton i Ethereum:

• Kontraktskonton – konton som kontrolleras av kontraktskoden
• Externt ägda konton – konton som styrs av en privat nyckel

Ethereum använder begreppet världsstat som är en kartläggning av kontoadresser och kontotillstånd. State_Root är en Patricia Merkle Tree-rot för sammanslagningen av konton i systemet. Och inom räkenskaperna är kontraktsstaterna också organiserade i denna Patricia Merkle Tree-datastruktur. Statens root-hash kan användas för att säkra identiteten på data i merkle-trädet vilket möjliggör replikering i hela nätverket vilket i slutändan resulterar i systemets teoretiska oföränderlighet.

Sanna blockkedjor skiljer sig från DLT baserat på deras beroende av denna Patricia Merkle Tree-datastruktur och deras orkestrering mellan block, som används för att instantiera systemets tillstånd. Detta koncept är en integrerad del av dataintegriteten, giltigheten och trohet hos en blockkedjan systemarkitektur.

Kommentar

Funktionaliteten som Ethereum World State skapar är ett pålitligt system som möjliggör instantiering av värde i ett digitalt format. Källor till digital representationsvärde som är infödd i token-ekonomin kan härledas från sammansättningen av konton och underdatastrukturerna i Ethereum; på samma sätt som logiska grindar kan starta funktionella algoritmer inom traditionell teknik.

Plattformar som härrör från Ethereum, inklusive Ethereum-klienter och privata implementeringar, kan dra nytta av denna instansering av värde genom övertygelser om dessa standarder när det gäller tillståndsbevarande och logisk implementering. Plattformar som inte instanserar någon av dessa logiska värdebaserade funktioner kommer inte att kunna underlätta skapandet av riktiga decentraliserade digitala tillgångsvärden.

Hyperledger tyg

I Hyperledger Fabric bevaras tillståndet i en databasstruktur med beroende av nyckel- / värdelager för staten. Samspelet mellan Chaincode-program och hur de installeras i plattformstopologin gör det möjligt att utföra kommandon och åtgärder i systemet. Dessa åtgärder resulterar i uppdateringar av datalagren eftersom transaktioner resulterar i uppdateringar till det tillstånd som kallas huvudboken. Bokboken är formulerad som en delad distribuerad databas som ger användarna överlägsen tillgång till information och transaktioner som sker inom den distribuerade datormiljön. Staten är kapslad i databasmiljön via traditionella programvaruutvecklingsverktyg:

• LevelDB skapar en nyckel / värdedatabas
• CouchDB skulle innehålla Document JSON-databasen

I Fabric-arkitekturen kan databasformatet för hur alla processer är organiserade öka transaktionsbearbetningen och maximera beräkningseffektiviteten i ekosystemet.

I den statliga databasen lagras de senaste versionsvärdena för nycklar i kedjetransaktionsloggen som nyckel / värdepar. Nyckelvärden som kallas världsstaten indexeras för en vy i transaktionsloggarna som finns i kanalarkitekturen. CouchDB fungerar som en separat databasprocess som tar emot uppdateringar från kedjekod-API: er.

Kommentar

Hyperledger Fabric har skapat en process som ersätter viktiga principer i ett blockchain-system i utbyte mot att uppnå övergångar med hög kapacitet. Användningen av den nuvarande arkitekturen gör att tillstånd lättare kan modifieras och manifesteras i ett traditionellt programvaruschema, vilket resulterar i läs- / skrivåtkomst. Även om tillståndsarrangemanget i tygmiljön är effektivt, saknar det förmågan att skapa ett värde i ett offentligt decentraliserat ekosystem, på samma sätt som en riktig blockchain som Ethereum eller Bitcoin skulle kunna göra. Förflyttningen av data i mjukvarumiljön för Fabric är ett tecken på vad en distribuerad databas kan. Skapandet av digitala tillgångar inom Fabric skulle i huvudsak vara digital information lagrad i en databas som styrs av de kontrollerande parterna eller grupperna inom ett konsortium utan att följa den ekonomiska varans ekonomiska struktur..

R3 Corda

I R3 Corda är State baserad på sekvensering och versionering av olika datamängder inom plattformsarkitekturen. I systemet underhåller nätverket ett valv, som är en databas som lagrar de historiska tillstånd som spåras inom systemet. I Corda anses tillståndet innehålla ogenomskinlig data som kan jämföras med en diskfil som inte nödvändigtvis uppdateras, men snarare används för att generera nya efterföljare. Detta system fungerar som en serie modifierade och återupplysta tillståndsuppdateringar i en miljö som styrs och delas av användarna.

Bokboken betraktas som en uppsättning av alla aktuella tillstånd som är aktiverade. Detta lånar från bitcoin UTXO-modellen men implementerar inte samma tillståndsbevarande egenskaper hos Patricia Merkle Trees som finns i blockchain-teknik, men använder snarare en del av tekniken i underavsnitt av plattformen i motsats till kärnan. Medan stater fungerar som förekomster av klasser som är lagrade i valvet, ger sekvensering och versionering av data ett livskraftigt sätt att lagra data.

I Corda betraktas stater som klasser som lagrar data. Klasser är implementeringar av “ContractState” -gränssnittet som fungerar som interoperabilitetsskiktet inom plattformen. Vissa “statliga” datafält kan innehålla:

• Utfärdande
• Ägare
• faceValue och Belopp>
• förfallodatum

Formatet för denna design var att tillåta tillägg av data i en kedja av händelser som gör det möjligt att spåra härkomst från var data kommer ifrån i den kontrollerade miljön. Proveniens styrs av medlemmarna i konsortiet som har vissa åtkomstkontroller till programvaruplattformen. Med hjälp av denna inställning kommer banker och finansinstitut att kunna maximera effektiviteten när det gäller bearbetning av information i ett delat resursekosystem. Uppgifter kan flyttas och bearbetas bättre mellan organisationer samtidigt som behovet av stort förtroende mellan icke betrodda motparter minskas.

Kommentar

Den här arkitektoniska inställningen kan också behandla delad data i en semi-betrodd miljö där motparterna inte behöver lita på varandra helt. Data kan framgångsrikt bearbetas och läggas till i vad Corda anser vara tillstånd, även om plattformen saknar komponenter i ett blockchain-system som kan avslöja entydigt värde. I Corda är tillståndet inte en logisk konstruktion, men snarare bitar av information bifogad i en databasliknande huvudbok. Medan tillgångar kan digitaliseras och lagras i använt och outnyttjat tillståndsformat, kommer tillgångarna inte att kunna vara distinkta värdenheter som liknar hur Bitcoin, Ethereum och token-ekonomin skapar nya marknader, även om bankprogramvaran kan vara en bra betrodda installation som kan hjälpa till att fungera som ett intyg för säker icke-offentlig information, liknande det som banksystemet för närvarande fungerar idag.

II. Transaktioner

Ethereum är ett transaktionsbaserat maskinekosystem där det globala tillståndet för transaktioner lagras i blocken. När transaktioner sker resulterar tillståndsövergångar i nya tillstånd i systemet. Denna process offrar hastigheten för snabb databastransaktionsbehandling för integriteten hos ett system som symboliserar staten såväl som den transaktion som ledde till det tillståndet inom blockchain Patricia Merkle Tree datastrukturkonfiguration.

Inom denna arkitektur bevaras tillstånd tillsammans med transaktionerna som leder till tillståndsövergångar i ett programvaruparadigm som använder Patricia Merkle Trees för att låsa data i en historisk verklighet som realiseras inom blocken.

Det finns två typer av transaktioner:

• Meddelande samtal
• Kontraktsskapande.

Transaktioner inkluderar en intern mekanism för värdeöverföring. Värdeöverföring på kontraktskonton resulterar i tillståndsförändringar. Eftersom systemet bygger på överföring av värde mellan smarta kontrakt som existerar mellan transaktionshändelser, kan de olika indelade tillstånden användas för att skapa en högkvalitativ affärslogik och avtal.

Kommentar

Det viktigaste kännetecknet för Ethereum är att transaktioner används som de enskilda processenheterna inom Ethereum blockchain-miljön, och genom denna konfiguration håller du ett permanent register över transaktionstillstånd i systemet. Ethereum kan både traditionell distribuerad databasrelaterad teknisk kapacitet samt koppla önskat förtroende med digitalt värde. Teknik som härrör från Ethereum blockchain kan gruppera transaktioner och affärslogik i block i en blockchain. Affärsfunktionalitet som härrör från denna inställning inkluderar:

• Sann digital ekonomi
• Digitala varor och tillgångar som styrs av ekonomiska incitament i motsats till organisatoriska / monopolistiska incitament
• Interaktionsgränssnitt mellan privata institutioner och den offentliga digitala ekonomin

Ethereums arkitektur tillåter anslutna plattformar att kunna starta kryptoekonomiska incitamentskikt i systemet. Detta innebär att olika incitamentskikt och mekanismdesigner kan skapas för att säkra det totala nätverket, kontra ett beroende av centralt styrda tjänster som tillhandahålls av traditionell programvarudesign. Detta kryptoekonomiska incitamentskikt kan tillämpas på både den digitala varuekonomin såväl som gränssnittsskiktet mellan privata och offentliga versioner av en blockchain-plattform.

Hyperledger tyg

Alla transaktioner utförs inom Fabric-flerkanalarkitekturen för att säkerställa hög transaktionskapacitet inom den pålitliga miljön. Transaktioner läggs till i en delad huvudbok som finns i runtime-miljön. Med den här arkitekturen tillåter Fabric läs- / skrivåtkomst och tillgänglighet till sin mjukvarumiljö, vilket möjliggör mainframe-liknande funktionalitet och användbarhet. Det är känt att SQL-databaser är flera storleksordningar mer effektiva än någon blockchain som för närvarande är tillgänglig, och konfigurationen av Fabric lånar mycket från paradigmer som används i traditionella databasverktyg som möjliggör den överlägsna transaktionskapaciteten.

Det finns två typer av transaktioner:

• Distribuera transaktioner – skapa ny kedjekod. Installerar kedjekod i mjukvaruutvecklingsmiljön
• Påkalla transaktioner – åberopar tidigare skapad kedjekod och motsvarande funktioner. När detta har genomförts framgångsrikt uppfyller kedjekoden en funktion och inför ändringar i tillståndet
• Anropa funktioner resulterar i “get” eller “set” transaktioner

För att maximera effektiv databehandling och överlägsen hastighet, satsas enskilda transaktioner av AKA-blobs av en Apache Kafka Ordering Service och skickas ut som “block” genom en leveranshändelse. Transaktionerna (blobs) beställs av Apache Kafka Ordering Service och bifogas Kafka-partitionerna. Vad detta betyder är att Fabric-arkitekturen offrar integriteten och datalitenheten för ett äkta blockchain-system för att få snabbare transaktionsbehandling och genomströmning i en betrodd datastreamingsmiljö, vilket framgår av användningen av Apache Kafka Ordering Service.

Som kan bedömas från Fabric-dokumentation bifogas de beställda transaktionerna direkt till de partitioner som är anslutna till Kafka Topics. Detta resulterar i transaktioner med hög kapacitet som sker i en betrodd datastreamingsmiljö. (Källa: Apache Kafka)

Kommentar

Även om systemet använder blockchain-esque terminologi, är detta inte en blockchain i traditionell mening, eftersom det inte finns någon bevarande av statliga och kompletterande transaktioner i en Patricia Merkle Tree datastruktur. Hyperledger Fabric är en DLT, inte en blockchain. Arkitekturen för Fabric var utformad för överlägsen transaktionsbehandling, vilket framgår av tillägget av datablobar i Kafka beställningstjänst för datastreaming. Eftersom detta uppnås i en pålitlig miljö kan avrättningar fritt inträffa i systemet. Användningen av denna konfiguration i ett värdeöverföringssystem skulle inte vara perfekt, med tanke på att allt förtroende skulle behöva tillskrivas en programvaruarkitektur från en enda enhet i motsats till ett delat ekosystem eller protokoll. Som framgår av de tekniska dokumenten har Fabric arkitektoniskt avstått från dataintegritet och säkerhet uppnådd i blockchain-plattformar för att få överlägsen bearbetning mellan transaktionskomponenterna.

R3 Corda

I R3 Corda betraktas transaktioner som förslag för att uppdatera databasvalvet, som kan kallas huvudboken. Transaktioner måste utföras i en miljö där notarier kan bekräfta att de inte används dubbelt och att de är undertecknade av nödvändiga parter. Detta liknar konceptet som används i bitcoin-ekosystemet, även om undvikandet av dubbla utgifter underlättas av ett pålitligt system.

Det finns två grundläggande typer av transaktioner:

• Transaktioner med notariusförändringar – dessa utförs för att bläddra igenom notarier i systemet. Notarer förhindrar dubbla utgifter och kan validera transaktioner
• Ge unika konsensus
• Allmänna transaktioner – används för allt annat

Transaktioner föreslås uppdateringar av databasmiljöns tillstånd som kräver att signaturer valideras från andra parter inom systemet. För att en transaktion ska vara giltig måste den:

1. Bli undertecknad av berörda parter
2. Bli validerad av kontraktskoden som bestämmer transaktionen

Användningen av den UTXO-liknande modellen i en delad databasmiljö gör att Corda-plattformen kan kontrollera tillståndet såväl som övergångarna. Användning av Notarius och olika interaktioner mellan Flöden och Cordapps i nätverkskonfigurationen visar en delad distribuerad miljö där tillståndet bevaras i ett dataformat integrerat med systemarkitekturen. Användningen av transaktioner för att navigera i instantiering av tillstånd inom den nodbaserade miljön mellan Flöden såväl som de Cordapps som programmeras i noder, indikerar ett livskraftigt sätt att utföra tillståndsförändringar till en storbok.

Kommentar

För bildandet av digitala tillgångar beror användare och motparter på förtroendet hos den övergripande Corda-plattformen. Samtidigt som det fungerar som ett starkt pålitligt delat distribuerat huvudbanksystem för att hålla känsliga finansiella data, fungerar systemet i enlighet med olika standarder som finns i bankens ekosystem. Plattformen tillhandahåller:

• Överlägsen lagring av icke-offentliga finansiella data
• Betrodda inställningar för icke-förtroende finansiella institutioner
• Avancerad valv av affärsinteraktioner

De arkitektoniska diagrammen som involverar flöden och runtime-miljöer mellan noder visar att Corda var utformad för att partitionera åtkomst mellan de betrodda medlemmarna av sin konsortieplattform. R3 Corda är kapabel till vissa aspekter av användbarhet, men saknar funktionalitet som är inbyggt i att vara ett universellt substrat för ekonomisk, social och politisk värdeöverföring på grund av brist på ett kryptoekonomiskt incitamentskikt samt en offentlig digital tillgångsmiljö. Eftersom systemet är stängt saknar det nödvändiga räls och tekniska egenskaper för att bygga ett ekonomiskt incitamentdrivet ekosystem runt. R3 Corda används sannolikt bäst för vissa aspekter av traditionell bankinfrastruktur, men inte skapande av digitala tillgångar.

III. Smarta kontrakt

Ethereum

I Ethereum skrivs smarta kontrakt på programmeringsspråk på hög nivå som soliditet, LLL eller Viper och sammanställs till EVM-bytecode, vilket gör att binärer kan köras av Ethereum Virtual Machine (EVM). Noder i Ethereum-nätverket kör sin egen EVM-implementering som fungerar som en runtime-miljö för smarta kontrakt i Ethereums ekosystem. Tillstånd och transaktioner som leder till statliga övergångar emblemiseras i Ethereums blockkedjans världstillstånd genom replikering av EVM, vilket resulterar i ett system som kan implementera oförstörbart förtroende på en rad spektrum.

EVM fungerar som en runtime-miljö för att rekursivt utföra tillståndsövergångar för att beräkna systemtillståndet och maskintillståndet när det går igenom transaktionerna..

• Systemtillstånd = Ethereums globala tillstånd
• Maskintillstånd = affärslogik för kontraktskonton & kod replikerad i EVM-körning

Eftersom all smart kontraktskod replikeras av alla noder i EVM, kan Ethereum blockchain och relaterade instanser behålla giltigheten för koden för att säkerställa enhetligheten i kontrakten. Överensstämmelsen i kontrakten bidrar till den praktiska oföränderligheten för Ethereum blockchain och dess anslutna kunder och implementeringar. Smarta kontrakt på Ethereum binder samman hela ekosystemet genom att initiera transaktioner som så småningom resulterar i övergångar till nya stater inom den totala virtuella maskinmiljön.

Kommentar

Eftersom implementeringar av EVM följer strikt specifikationerna som anges i Ethereum Yellow Paper, kan olika instanser av Ethereum (offentliga, privata och konsortier) interoperabilitet som bestäms av den gemensamma sammanställningen av språk på hög nivå – i form av smart kontrakt – till Ethereum bytecode av EVM. Från denna disposition av Ethereum kan den fungera som mellanlagret mellan olika aspekter av stora institutionella privata datafaciliteter och den offentliga digitala varuekonomin som för närvarande utvecklas och kommer att realiseras från den nyligen skapade tokenekonomin.

Genom att tillåta denna funktion mellan Ethereum-kedjor kan hela driftskompatibla system byggas som fördelar ekonomisk slutgiltighet mellan system för datakoordinering och -behandling i privata Ethereum-plattformar till digitala varor i den offentliga kedjan. Smarta kontrakt på Ethereum inkapslar programmerbar logik inom dessa system och gör det möjligt för utvecklare att interagera med Ethereum Virtual Machine genom transaktioner som skapar nya tillståndsmiljöer inom den tekniska infrastrukturen. Eftersom omfattande användningsfall utvecklas inom interoperabla miljöer för offentlig kedja, privat kedja och konsortiekedja kommer de smarta kontrakten som används i Ethereum att kunna binda samman systemen under ett gemensamt logiskt gränssnitt.

Hyperledger tyg

Chaincode är inte nödvändigtvis ett smart kontrakt som distribueras i en kontobaserad blockchain, utan snarare ett program som installeras och som sedan implementerar ett gränssnitt via ett API. API-gränssnittet kräver kodbaserade instruktioner för att rikta affärslogik och funktionalitet i hela systemet, liknande en traditionell mjukvaruutvecklingsmiljö. Metoder kopplade till API: n inkluderar:

• Init – initiering av ansökningstillstånd
• Åberopa – bearbetar transaktionsförslag

Kedjekod måste implementera gränssnitt från API: t:

• Kedjekodsgränssnitt
• ChaincodeStubInterface

I Hyperledger Fabric körs kedjekod i säkrade Docker-behållare, där den isoleras från processer som körs av den godkännande kollegan. Koden skrivs normalt i Go eller Node.js, vilket möjliggör interaktion som hanterar affärslogiken. En nyans att tänka på är att Fabric-kedjekoden inte replikeras av noder inom ekosystemet på samma sätt som det förväntas av en riktig blockchain-arkitektur.

Kedjekod installeras ursprungligen på Peers och instaliseras sedan till kanaler. Processflödet beskrivs i följande diagram:

Under hela Chaincode-processflödet sker olika interaktioner med System Chaincode, som körs i en körbar peer-process kontra en isolerad behållare. Detta används för att implementera systembeteenden utan godkännandepolicyer eller livscykelprocesser. Systemkedjekod går inte igenom kodens livscykel för normal kedjekod. Två funktioner från Shim API för kedjekodsgränssnittet implementeras. Koden sammanställs och underhålls av kollegan. Chaincode är inte anslutet till kanaler eller beställningar förrän utvecklaren bestämmer att de vill installera programmet ytterligare.

Kedjekod kan konfigureras för att skapa tillgångar som i slutändan fungerar som nyckel-värdepar som lagras i storleksdatabasen. Arbetsflödet för att skicka initieringskommandon och åberopa transaktionerna beskrivs i ovanstående diagram när det gäller hur kommandon flyttas genom systemet. Affärslogiken är kodad inom nätverkets regler och åberopas via applikationer på klientsidan. Typen av kodkoordinering och interaktion är mycket indikativ för traditionell mjukvaruutveckling genom beroende av traditionella funktioner och initieringsgränssnitt.

Kommentar

Förflyttningen av Chaincode genom denna nätverkskonfiguration möjliggör en strömlinjeformad organisation av systemet. Programvaruarkitekturen är grundad för att fungera som en mycket effektiv kommando- och kontrollstruktur när det gäller att distribuera data och organisera mjukvaruutvecklingsmiljön för vissa företagsanvändningsfall. Som kan urskiljas från paketet, installera, starta och uppgradera installationen, var denna arkitektur utformad för att optimera de nödvändiga beröringspunkter som krävs för att bearbeta kod. De nödvändiga API-gränssnitten när transaktioner behandlas påminner mycket om traditionell programvarudesign. Anmärkningsområden:

• Monolitisk arkitektur för maximal kontroll
• Säker affärsinteraktion mellan motparter
• Centralt samordnad bearbetning för transaktionens genomströmning

Chaincode är mer ett system av kommandon än det är ett smart kontraktspråk som replikeras av en blockchain. Eftersom Hyperledger Fabric-ekosystemet har en livlig uppsättning starka egenskaper när det gäller funktionalitet och design som en distribuerad huvudbok saknar systemet faktiskt de inneboende egenskaperna hos ett äkta blockchain-system. Som ett verktyg som är användbart för integrering med äldre infrastruktur och paradigmer är Fabric effektivt på grund av att det följer befintliga mjukvarustandarder, vilket kan dras av den arkitektoniska designen som beskrivs ovan.

Där Fabric vinner i funktionalitet i termer av sitt system som är något symboliskt för system utformade runt stora mainframes och datacenter, förlorar det i andra aspekter när det gäller distribuerad anslutning till ekonomiska beräkningsfaktorer som kan nås i en inneboende decentraliserad digital tokenekonomi . Om Fabric skulle integreras i en riktig blockchain-miljö, skulle den passa bra som en säker distribuerad databasmiljö som validerar information innan interaktion med ett offentligt blockchain-ekosystem.

R3 Corda

I Corda betraktas smarta kontrakt som klasser som implementerar kontraktgränssnittet. Smarta kontrakt skrivs i Java / Kotlin och sammanställs via Java Virtual Machine (JVM), som är den datormaskin som koden körs inom. Huvudfunktionen som används i kontrakten är “verifiera” -funktionen.

Koden körs på JVM där transaktioner behandlas via notariseringssystemet och affärslogiken är begränsad inom Flöden som kan hysa och isolera affärsprocessen mellan olika motparter.

Smarta kontraktskomponenter:

• Körbar kod
• Validerar förändringar i transaktioner
• Statliga objekt
• Uppgifter om bokföringen
• Kontraktets nuvarande tillstånd
• Använder in- och utdata från transaktioner
• Kommandon
• Ytterligare uppgifter
• Används för att instruera körbar kontraktskod

Java och Kotlin-kod sammanställs till identisk bytkod via JVM. Kommandon skickar ytterligare data som inte finns i staten till kontraktskoden. Kommandon fungerar som datastrukturer med bifogade offentliga nycklar som används för att signera transaktioner, men det bör erkännas att kontrakt inte fungerar direkt med de digitala signaturerna. Kontrakt inom denna miljö replikeras i hela systemet i samband med hur Flöden är villiga att samordna mellan betrodda parter.

Kommentar

Kontraktskoden passar behoven för användningsfall inom Corda-miljön och kan utföra de nödvändiga funktionerna för transaktionsgenomströmning. Begränsningar inkluderar interoperabilitet med andra ekosystem. För att system ska kunna samarbeta med Corda, skulle de behöva använda Corda-avtalets kodram som är utformad kring den stängda DLT. Till skillnad från en riktig blockchain-plattform som Ethereum som kan fungera som interoperabilitetsskiktet mellan ekonomiska processer och funktioner mellan privata instanser och offentliga instanser, begränsar Corda sig genom att vara mer fokuserad på processer i ett slutet system. Användningen av JVM är innovativ men förekomsten är isolerad i Corda-ekosystemet. I det här scenariot får Corda transaktionsbehandling i en säker miljö samtidigt som man offrar förmågan att interoperera och samordna mellan olika blockchain-miljöer som ett interoperabelt system skulle kunna göra.

IV. Slutsats och bedömning

Baserat på vår analys är de viktigaste särskiljande faktorerna som Ethereum kan implementera utöver vad som kan DLT:

• Digital ekonomi eller symbolisk ekonomi
• Kryptoekonomiska incitamentskikt i protokollet
• Interoperabilitet mellan konsortiet och offentliga blockchains

Även om DLT: s som R3 Corda och Hyperledger Fabric kan uppnå funktionalitet i den delade databashanterings- och transaktionsbehandlingslivscykeln, är det inte garanterat att de kommer att kunna uppnå de viktigaste funktionerna som beskrivs ovan. Dessa plattformar är inte bristfälliga, utan snarare begränsade i sin arkitektoniska konfiguration för att visa några av de rena användningsfall som endast sanna blockkedjor kan hävda.

Blockchain-teknologier är utformade för att koppla det förtroende som skapas inom dem tillsammans med det konkreta värde som skapas av det förtroendet. Endast genom en verklig plattform byggd från kärnfundamenten i en blockchain kommer sociala, politiska och ekonomiska system att kunna grundläggas helgas inom ett mjukvaruprotokolls infrastruktur. Medan DLT-fokuserade databashanteringsplattformar kan integreras och samverka med en blockchain-plattform, måste rälsen som värdeöverföringar och samordning av detta förtroende byggas vara en blockchain som förkroppsligar grundläggande principer för tillit, oföränderlighet, integritet och informationstrohet.

Vad denna analys avslöjar är inte att vissa system är bättre än andra, utan snarare de är användbara i olika kapaciteter. DLT-plattformars förmåga att fungera som privata distribuerade databaser med hög transaktionsgenomströmning och funktionalitet, låta dem fungera som pålitliga system som kan samarbeta inom en blockchain-plattform när vissa aspekter av privat information är nödvändiga för bedömning, såsom bank / finansiell information eller känslig information som hänför sig till den inre verksamheten hos en privat institution som inte bör avslöjas för allmänheten. De olika affärsmodellerna för hur man använder dessa källor för privata data kopplade till DLT är fortfarande under utveckling och bör upprepas med blockchain-gränssnitt i åtanke eftersom ett decentraliserat digitalt värdesystem är nödvändigt för några av interaktionerna mellan blockkedjor och DLT: er.

Anslut till våra blockchain-experter

Vårt globala lösningsgrupp erbjuder blockchain-utbildning, strategisk rådgivning, implementeringstjänster och möjligheter till partnerskap. Kontakta oss Nyhetsbrev Prenumerera på vårt nyhetsbrev för de senaste Ethereum-nyheterna, företagslösningar, utvecklarresurser och mer. E-postadress Exklusivt innehållGuide

Komplett guide till blockchain-affärsnätverk

Webinar

Introduktion till tokenisering

Webinar

Framtiden för ekonomi: digitala tillgångar och deFi

Webinar

Vad är Enterprise Ethereum?

Vitt papper

Centralbanker och pengarnas framtid

Case Stud

Komgo: Blockchain för handelsfinansiering av råvaror

Mike Owergreen Administrator

Sorry! The Author has not filled his profile.

follow me