Blockchain versus Distributed Ledger Technologies (DLT’s): deel 2

blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogEnterprise Blockchain

Blockchain versus Distributed Ledger Technologies (DLT’s): deel 2

Een vergelijkende analyse van de architecturen en de bestuurlijke dynamiek van Ethereum, Hyperledger Fabric en R3 Corda. Door ConsenSys23 mei 2018Geplaatst op 23 mei 2018

blockchain dlt 2 held

Dit is deel 2 van een tweedelige vergelijkende analyse van Ethereum, Hyperledger Fabric en R3 Corda. Lees deel 1 van Blockchain versus DLT’s. 

Blockchain versus gedistribueerde Ledger-technologieplatforms

Erkend moet worden dat als databasecoördinatie en efficiëntere toewijzing van code de gewenste functionaliteit van een systeem is, blockchain niet noodzakelijk de oplossing hoeft te zijn waarnaar een organisatie op zoek is. Distributed ledger technology (DLT) -systemen zoals Hyperledger Fabric of R3 Corda zijn in staat tot vergelijkbare functionaliteiten als blockchain-systemen, maar er moet rekening mee worden gehouden dat blockchains een aparte subset zijn van gedistribueerde grootboeken die extra functionaliteit hebben die verder gaat dan codecoördinatie. Blockchains zijn in staat tot functies die gedistribueerde grootboeken niet zijn in termen van instantiatie van digitale waarde op basis van de samenstelling van het systeem.

In dit document worden architectonische overwegingen onderzocht die de aspecten identificeren die bijdragen aan blockchain-functionaliteit. Een onderzoek zou zijn dat er misschien een afweging is tussen wat blockchains kunnen bereiken en wat DLT’s bieden. DLT was bedoeld voor transactieverwerking in een gedeelde vertrouwde omgeving, terwijl echte blockchains waren ontworpen om de behoefte aan een vertrouwde setup op te offeren om een ​​hoge betrouwbaarheid en onveranderlijkheid van accounts te bereiken. Aspecten van hoge betrouwbaarheid en onveranderlijkheid zijn een integraal onderdeel van het succes van het correct digitaliseren van activa. De analyse van dit document zal architecturale componenten over bedrijfsprocessen heen leggen om deze technologische nuances op verschillende platforms verder te verduidelijken.

Figuur 1 Het is belangrijk om onderscheid te maken tussen technologiestacks en hoe deze zich verhouden in termen van functionaliteit en use cases. Hoewel gedistribueerde grootboektechnologie sterk werd beïnvloed door blockchain-technologie, moeten we onderscheid maken tussen architectonische overwegingen van de technologieplatforms.Het is belangrijk om onderscheid te maken tussen technologiestacks en hoe deze zich verhouden in termen van functionaliteit en use cases. Hoewel gedistribueerde grootboektechnologie sterk werd beïnvloed door blockchain-technologie, moeten we onderscheid maken tussen architectonische overwegingen van de technologieplatforms.

Er zullen vergelijkingen worden gemaakt op basis van een aantal belangrijke onderscheidende kenmerken die binnen de softwareplatforms bestaan. De belangrijkste gebieden die in dit document zullen worden onderzocht, zijn onder meer:

  • Staat: De status verwijst naar de belangrijkste logische eenheid waaruit code kan bestaan ​​om de weergave van informatie in een computeromgeving te vergemakkelijken. Hoewel state verschillende betekenissen kan hebben in verschillende contexten, bestaat het gebruik van state binnen de blockchain en gedistribueerde grootboekomgeving uit de huidige configuratie van het ontologische kenmerk van een datastructuur.
  • Transacties: Binnen een blockchain-omgeving worden transacties beschouwd als de computationele gebeurtenissen die kunnen leiden tot het genereren van toestand- of toestandovergangen die plaatsvinden binnen het ontwikkelingsecosysteem. Transacties kunnen contracten initiëren of een beroep doen op reeds bestaande contracten.
  • Slimme contracten: Bij het beoordelen van een blockchain-platform vanuit een architectonisch perspectief, is het belangrijk om de structuur van de slimme contractcode te bepalen en hoe deze functioneert in relatie tot de daadwerkelijke blockchain-netwerktopologie. Slimme contracten worden beschouwd als de individuele code-eenheden die acties uitvoeren binnen het platformecosysteem.

De volgende tabel geeft een kort overzicht van de belangrijkste verschillen tussen de verschillende technologische kenmerken van de respectievelijke platforms.

platformfunctiesEen overzicht van de technologische kenmerken van Ethereum, Hyperledger Fabric en R3 Corda.

Ik zeg

Ethereum

Als een ecosysteem met gedeelde gedistribueerde configuraties, instantieert Ethereum het concept van ‘Staat’ via een configuratie van objecten die ‘Accounts’ worden genoemd. Er zijn twee soorten accounts in Ethereum:

  • Contractaccounts – accounts beheerd door contractcode
  • Externe accounts – accounts die worden beheerd door een privésleutel

Ethereum gebruikt het concept van World State, dat een afbeelding is van accountadressen en accountstatussen. De State_Root is een Patricia Merkle Tree-root van de samenvoeging van accounts in het systeem. En binnen de accounts zijn de contractstatussen ook georganiseerd in deze Patricia Merkle Tree-datastructuur. De root-hash van de staat kan worden gebruikt om de identiteit van de gegevens in de merkle-boom te beveiligen, waardoor replicatie door het hele netwerk mogelijk is, wat uiteindelijk resulteert in de theoretische onveranderlijkheid van het systeem.

Echte blockchains onderscheiden zich van DLT op basis van hun afhankelijkheid van deze Patricia Merkle Tree-datastructuur en hun orkestratie tussen blokken die wordt gebruikt om de toestand van het systeem te instantiëren.Dit concept is een integraal onderdeel van de validiteit en betrouwbaarheid van een blockchain-systeemarchitectuurEchte blockchains onderscheiden zich van DLT op basis van hun afhankelijkheid van deze Patricia Merkle Tree-datastructuur en hun orkestratie tussen blokken, die wordt gebruikt om de toestand van het systeem te instantiëren. Dit concept is een integraal onderdeel van de gegevensintegriteit, validiteit en betrouwbaarheid van een blockchain-systeemarchitectuur.

Commentaar

De functionaliteit die de Ethereum World State creëert, is een betrouwbaar systeem dat de instantiatie van waarde in een digitaal formaat mogelijk maakt. Bronnen van digitale representatiewaarde die eigen is aan de tokeneconomie kunnen worden afgeleid uit de samenstelling van accounts en subgegevensstructuren van Ethereum; op dezelfde manier waarop logische poorten functionele algoritmen in traditionele engineering kunnen instantiëren.

Platformen die zijn afgeleid van Ethereum, waaronder Ethereum-clients en privé-implementaties, kunnen profiteren van deze instantiatie van waarde door overtuigingen van deze normen met betrekking tot het behoud van de staat en logische implementatie. Platformen die een van deze op logische waarde gebaseerde functionaliteiten niet instantiëren, zullen het creëren van echte gedecentraliseerde digitale activawaarden niet kunnen vergemakkelijken.

Hyperledger-stof

In Hyperledger Fabric wordt de status behouden in een databasestructuur met een afhankelijkheid van sleutel / waarde-archieven voor de status. Door de interactie tussen Chaincode-programma’s en hoe ze in de platformtopologie zijn geïnstalleerd, kunnen opdrachten en acties in het systeem worden uitgegeven. Deze acties resulteren in updates van de datastores, aangezien transacties resulteren in updates van de staat die bekend staat als het grootboek. Het grootboek is geformuleerd als een gedeelde gedistribueerde database die gebruikers superieure toegang biedt tot informatie en transacties die plaatsvinden binnen de gedistribueerde computeromgeving. State is genest in de database-omgeving via traditionele softwareontwikkelingstools:

  • LevelDB maakt een sleutel / waarde-database aan
  • CouchDB zou de Document JSON-database bevatten

stof architectuurIn de Fabric-architectuur kan het databaseformaat van hoe alle processen zijn georganiseerd de transactieverwerking verhogen en de rekenefficiëntie in het ecosysteem maximaliseren.

In de State Database worden de laatste versiewaarden voor sleutels in het kettingtransactielogboek opgeslagen als sleutel / waarde-paren. Sleutelwaarden die bekend staan ​​als de wereldstaat worden geïndexeerd voor een weergave in de transactielogboeken die binnen de kanaalarchitectuur bestaan. CouchDB fungeert als een apart databaseproces dat updates ontvangt van de chaincode API’s.

Commentaar

Hyperledger Fabric heeft een proces gecreëerd dat de belangrijkste principes van een blockchain-systeem overtreft in ruil voor het bereiken van statusovergangen met een hoge doorvoer. Door het gebruik van de huidige architectuur kunnen toestanden gemakkelijker worden gewijzigd en gemanifesteerd binnen een traditioneel softwareschema, wat resulteert in lees- / schrijftoegang. Hoewel de statusindeling binnen de Fabric-omgeving efficiënt is, ontbreekt het aan de mogelijkheid om waarde te instantiëren in een openbaar gedecentraliseerd ecosysteem, op dezelfde manier als een echte blockchain zoals Ethereum of Bitcoin zou kunnen doen. De verplaatsing van gegevens in de softwareomgeving van Fabric is een indicatie van waartoe een gedistribueerde database in staat is. De creatie van digitale activa binnen Fabric zou in wezen digitale informatie zijn die is opgeslagen in een database die wordt beheerd door de controlerende partijen of groepen binnen een consortium zonder zich te houden aan de economische structuur van de digitale goederen..

R3 Corda

In R3 Corda is State gebaseerd op sequencing en versiebeheer van verschillende datasets binnen de platformarchitectuur. In het systeem onderhoudt het netwerk een kluis, een database die de historische toestanden opslaat die binnen het systeem worden bijgehouden. In Corda wordt onder status verstaan ​​ondoorzichtige gegevens die vergelijkbaar zijn met een schijfbestand dat niet noodzakelijkerwijs is bijgewerkt, maar eerder wordt gebruikt om nieuwe opvolgers te genereren. Dit systeem fungeert als een reeks gewijzigde en opnieuw opgedoken statusupdates binnen een omgeving die wordt beheerd en gedeeld door de gebruikers.

Figuur 5 Het grootboek wordt beschouwd als de verzameling van alle huidige staten die zijn geactiveerd. subsecties van het platform in tegenstelling tot de kern Terwijl staten fungeren als instanties van klassen die in de kluis zijn opgeslagen, bieden de volgorde en versiebeheer van de gegevens een haalbare manier om de gegevens op te slaanHet grootboek wordt beschouwd als de verzameling van alle huidige staten die zijn geactiveerd. Dit leent van het bitcoin UTXO-model, maar implementeert niet dezelfde statusbehoudende kenmerken van Patricia Merkle Trees die bestaan ​​in blockchain-technologie, maar gebruikt eerder een deel van de technologie in subsecties van het platform in tegenstelling tot de kern. Hoewel staten fungeren als instanties van klassen die in de kluis zijn opgeslagen, bieden de volgorde en versiebeheer van de gegevens een haalbare manier om de gegevens op te slaan.

In Corda worden staten beschouwd als klassen waarin gegevens worden opgeslagen. Klassen zijn implementaties van de “ContractState” -interface die fungeert als de interoperabiliteitslaag binnen het platform. De bepaalde gegevensvelden in de staat kunnen zijn:

  • Uitgifte
  • Eigenaar
  • faceValue en Amount>
  • vervaldatum

Het formaat van dit ontwerp was om het toevoegen van gegevens in een reeks gebeurtenissen mogelijk te maken, waardoor het mogelijk werd om de herkomst te volgen van waar de gegevens vandaan komen in de gecontroleerde omgeving. Herkomst wordt gecontroleerd door de leden van het consortium die bepaalde toegangscontroles hebben tot het softwareplatform. Met behulp van deze opzet kunnen banken en financiële instellingen de efficiëntie maximaliseren in termen van het verwerken van informatie in een gedeeld grootboekecosysteem. Gegevens kunnen beter tussen organisaties worden verplaatst en verwerkt, terwijl de behoefte aan substantieel vertrouwen tussen niet-vertrouwde tegenpartijen wordt verminderd.

Commentaar

Deze architectonische opzet is op dezelfde manier in staat om gedeelde gegevens te verwerken in een semi-vertrouwde omgeving waar tegenpartijen elkaar niet volledig hoeven te vertrouwen. Gegevens kunnen met succes worden verwerkt en toegevoegd aan wat Corda als status beschouwt, hoewel het platform de componenten mist van een blockchain-systeem die ondubbelzinnige waarde kunnen onthullen. In Corda is staat geen logische constructie, maar eerder stukjes informatie die in een databaseachtig grootboek worden toegevoegd. Hoewel activa kunnen worden gedigitaliseerd en opgeslagen binnen het formaat van de gebruikte en niet-bestede staat, zullen de activa geen afzonderlijke waarde-eenheden kunnen zijn, vergelijkbaar met hoe Bitcoin, Ethereum en de tokeneconomie nieuwe markten creëren, hoewel de banksoftware een goede vertrouwde kan zijn. installatie die kan helpen fungeren als een attest-hub voor veilige niet-openbare informatie, vergelijkbaar met hoe het banksysteem momenteel werkt.

II. Transacties

Ethereum is een op transacties gebaseerd machine-ecosysteem waarin de globale status van transacties binnen de blokken wordt opgeslagen. Wanneer transacties plaatsvinden, resulteren toestandsovergangen in nieuwe toestanden van het systeem. Dit proces offert de snelheid van de snelle verwerking van databasetransacties op voor de integriteit van een systeem dat zowel de staat symboliseert als de transactie die tot die toestand heeft geleid binnen de datastructuurconfiguratie van de blockchain Patricia Merkle Tree.

Figuur 6 Binnen deze architectuur worden de staat samen met de transacties die tot toestandsovergangen leiden bewaard in een softwareparadigma dat Patricia Merkle Trees gebruikt om gegevens te vergrendelen in een historische realiteit die binnen de blokken wordt gerealiseerdBinnen deze architectuur wordt de toestand samen met de transacties die tot toestandsovergangen leiden bewaard in een softwareparadigma dat Patricia Merkle Trees gebruikt om gegevens te vergrendelen in een historische realiteit die binnen de blokken wordt gerealiseerd.

Er zijn twee soorten transacties:

  • Berichtoproepen
  • Contract creaties.

Transacties omvatten een intern mechanisme van waardeoverdracht. Waardeoverdracht binnen contractrekeningen leidt tot statuswijzigingen. Omdat het systeem is gebaseerd op de overdracht van waarde tussen slimme contracten die bestaan ​​tussen transactie-uitvoeringsgebeurtenissen, kunnen de verschillende gecompartimenteerde staten worden gebruikt om high-fidelity bedrijfslogica en overeenkomsten te instantiëren.

Commentaar

Het belangrijkste onderscheidende kenmerk van Ethereum is dat transacties worden gebruikt als de individuele proceseenheden binnen de Ethereum blockchain-omgeving, en door deze configuratie een permanent register bijhouden van transactiestaten binnen het systeem. Ethereum is in staat om zowel traditionele gedistribueerde grootboekdatabase-gerelateerde technologische mogelijkheden als het gewenste vertrouwen te koppelen aan digitale waarde. Technologieën die zijn afgeleid van de Ethereum-blockchain, kunnen transacties en bedrijfslogica groeperen in blokken van een blockchain. Zakelijke functionaliteit die van deze opzet is afgeleid, omvat:

  • Echte digitale economie
  • Digitale goederen en activa gecontroleerd door economische prikkels in tegenstelling tot organisatorische / monopolistische prikkels
  • Interactie-interface tussen particuliere instellingen en de publieke digitale economie

De architectuur van Ethereum stelt aangesloten platforms in staat om crypto-economische stimuleringslagen in het systeem te instantiëren. Dit betekent dat verschillende stimulatielagen en mechanismeontwerpen kunnen worden gecreëerd om het algehele netwerk te beveiligen, in plaats van te vertrouwen op centraal gecontroleerde diensten die worden geleverd door traditionele softwareontwerpen. Deze crypto-economische stimuleringslaag kan worden toegepast op zowel de digitale goedereneconomie als de interfacelaag tussen private en publieke versies van een blockchain-platform..

Hyperledger-stof

Alle transacties worden uitgevoerd binnen de Fabric-meerkanaalsarchitectuur om een ​​hoge transactiedoorvoer binnen de vertrouwde omgeving te garanderen. Transacties worden toegevoegd aan een gedeeld grootboek dat bestaat binnen de runtime-omgeving. Met deze architectuur biedt Fabric lees- / schrijftoegang en toegankelijkheid tot hun softwareomgeving, waardoor mainframe-achtige functionaliteit en bruikbaarheid mogelijk is. Het is bekend dat SQL-databases verschillende ordes van grootte beter presteren dan welke blockchain dan ook die momenteel beschikbaar is, en de configuratie van Fabric leent veel van paradigma’s die worden gebruikt in traditionele databasetools, waardoor de superieure transactiedoorvoer mogelijk is..

Er zijn twee soorten transacties:

  • Transacties implementeren – nieuwe kettingcode maken. Installeert kettingcode in de softwareontwikkelingsomgeving
  • Roep transacties aan – roept eerder gemaakte kettingcode en de bijbehorende functies op. Als dit met succes is uitgevoerd, vervult de kettingcode een functie en brengt hij wijzigingen in de toestand aan
  • Het aanroepen van functies resulteert in ‘get’ of ‘set’ transacties

Om de efficiënte gegevensverwerking en superieure snelheden te maximaliseren, worden individuele transacties AKA-blobs in batches uitgevoerd door een Apache Kafka-bestelservice en als “blokken” uitgevoerd via een bezorggebeurtenis. De transacties (blobs) worden besteld door de Apache Kafka Ordering Service en toegevoegd aan de Kafka-partities. Dit betekent dat de Fabric-architectuur de integriteit en gegevensgetrouwheid van een echt blockchain-systeem opoffert om snellere transactieverwerking en doorvoer te verkrijgen binnen een vertrouwde datastreamomgeving, zoals blijkt uit het gebruik van de Apache Kafka-bestelservice..

Figuur 7 Zoals kan worden beoordeeld op basis van Fabric-documentatie worden de bestelde transacties direct toegevoegd aan de partities die zijn aangesloten bij de Kafka-onderwerpen Dit resulteert in transacties met hoge doorvoer die plaatsvinden in een vertrouwde datastreamomgeving Bron Apache KafkaZoals kan worden beoordeeld uit Fabric-documentatie, worden de bestelde transacties rechtstreeks toegevoegd aan de partities die zijn aangesloten bij de Kafka-onderwerpen. Dit resulteert in transacties met een hoge doorvoersnelheid die plaatsvinden in een vertrouwde datastreamomgeving. (Bron: Apache Kafka)

Commentaar

Hoewel het systeem blockchain-achtige terminologie gebruikt, is dit geen blockchain in de traditionele zin, in die zin dat er geen behoud is van staats- en complementaire transacties in een Patricia Merkle Tree-datastructuur. Hyperledger Fabric is een DLT, geen blockchain. De architectuur van Fabric is ontworpen voor superieure transactieverwerking, zoals blijkt uit het toevoegen van gegevensblobs aan de Kafka-bestelservice voor gegevensstreaming. Omdat dit wordt bereikt in een vertrouwde omgeving, kunnen executies vrij in het systeem plaatsvinden. Het gebruik van deze configuratie in een waardeoverdrachtsysteem zou niet ideaal zijn, aangezien alle vertrouwen rechtstreeks zou moeten worden toegeschreven aan één softwarearchitectuur van één enkele entiteit, in tegenstelling tot een gedeeld ecosysteem of protocol. Zoals te zien is in de technische documenten, heeft Fabric architectonisch afstand gedaan van de gegevensintegriteit en beveiliging die wordt bereikt in blockchain-platforms om een ​​superieure verwerking tussen de transactiecomponenten te verkrijgen.

R3 Corda

In R3 Corda worden transacties beschouwd als voorstellen om de databank Vault bij te werken, ook wel het grootboek genoemd. Transacties moeten worden uitgevoerd in een omgeving waar notarissen kunnen valideren dat ze niet dubbel zijn uitgegeven en dat ze zijn ondertekend door de nodige partijen. Dit is vergelijkbaar met het concept dat wordt gebruikt in het bitcoin-ecosysteem, hoewel het voorkomen van dubbele uitgaven wordt vergemakkelijkt door een vertrouwd systeem.

Er zijn twee basistypen transacties:

  • Notariswisseltransacties – deze worden uitgevoerd om door notarissen in het systeem te bladeren. Notarissen voorkomen dubbele uitgaven en kunnen transacties valideren
  • Zorg voor een uniciteitsconsensus
  • Algemene transacties – gebruikt voor al het andere

eindtoestand

Transacties zijn voorgestelde updates van de toestand van de databaseomgeving waarvoor handtekeningen van andere partijen binnen het systeem moeten worden gevalideerd. Om een ​​transactie geldig te laten zijn, moet deze:

  1. Laat u ondertekenen door de betrokken partijen
  2. Laat u valideren door de contractcode die de transactie bepaalt

client architectuur

Door het gebruik van het UTXO-achtige model in een gedeelde databaseomgeving kan het Corda-platform zowel de toestand als de overgangen controleren. Het gebruik van de notaris en verschillende interacties tussen Flows en Cordapps in de netwerkconfiguratie laten een gedeelde gedistribueerde omgeving zien waarin de staat wordt bewaard in een gegevensformaat dat integraal deel uitmaakt van de systeemarchitectuur. Het gebruik van transacties om door de instantiatie van toestanden binnen de op knooppunten gebaseerde omgeving tussen stromen te navigeren, evenals de Cordapps die in knooppunten worden geprogrammeerd, duidt op een haalbare manier om statuswijzigingen in een grootboek uit te voeren.

Commentaar

Voor de vorming van digitale activa zijn gebruikers en tegenpartijen afhankelijk van het vertrouwen van het algehele Corda-platform. Hoewel het fungeert als een sterk vertrouwd gedeeld gedistribueerd grootboeksysteem voor het bewaren van gevoelige financiële gegevens, handelt het in overeenstemming met verschillende standaarden die bestaan ​​in het bankecosysteem. Het platform biedt:

  • Superieure opslag van niet-openbare financiële gegevens
  • Vertrouwde setup voor niet-vertrouwende financiële instellingen
  • Geavanceerde bewaking van zakelijke interacties

De architecturale diagrammen met stromen en runtime-omgevingen tussen knooppunten laten zien dat Corda is ontworpen om de toegang tussen de vertrouwde leden van het consortiumplatform te verdelen. Hoewel R3 Corda in staat is tot bepaalde aspecten van bruikbaarheid, ontbreekt het aan functionaliteit die inherent is aan het feit dat het een universeel substraat is voor economische, sociale en politieke waardeoverdracht, vanwege het ontbreken van een crypto-economische stimuleringslaag en een openbare omgeving voor digitale activa. Omdat het systeem gesloten is, mist het de nodige rails en technologische eigenschappen om een ​​door economische prikkels aangedreven ecosysteem op te bouwen. R3 Corda wordt hoogstwaarschijnlijk het best gebruikt voor bepaalde facetten van traditionele bankinfrastructuur, maar niet voor het creëren van digitale activa.

III. Slimme contracten

Ethereum

In Ethereum worden slimme contracten geschreven in programmeertalen op hoog niveau zoals solidity, LLL of Viper en gecompileerd in EVM-bytecode, waardoor binaire bestanden kunnen worden uitgevoerd door de Ethereum Virtual Machine (EVM). Knooppunten in het Ethereum-netwerk hebben hun eigen EVM-implementatie die fungeert als een runtime-omgeving voor slimme contracten in het Ethereum-ecosysteem. Staat en transacties die leiden tot staatsovergangen worden door replicatie door de EVM in de wereldstaat van de Ethereum-blockchain gesymboliseerd, wat resulteert in een systeem dat onvergankelijk vertrouwen kan implementeren op een reeks spectrums.

EVM 1

De EVM fungeert als een runtime-omgeving om recursief statusovergangen uit te voeren om de systeemstatus en de machinetoestand te berekenen terwijl deze door de transacties loopt.

  • Systeemstatus = Ethereum globale staat
  • Machinestatus = bedrijfslogica van contractaccounts & code gerepliceerd in EVM-runtime

Omdat alle slimme contractcode wordt gerepliceerd door alle knooppunten in de EVM, kunnen Ethereum-blockchain en gerelateerde instantiaties de geldigheid van de code behouden om de consistentie van de contracten te garanderen. Consistentie van de contracten draagt ​​bij aan de praktische onveranderlijkheid van de Ethereum-blockchain en zijn gelieerde klanten en implementaties. Slimme contracten op Ethereum binden het hele ecosysteem samen door middel van instantiërende transacties die uiteindelijk resulteren in overgangen naar nieuwe staten binnen de algehele virtuele machine-omgeving.

Commentaar

Omdat implementaties van de EVM zich strikt houden aan de specificaties zoals aangegeven in het Ethereum Yellow Paper, zijn verschillende instantiaties van Ethereum (openbaar, privé en consortium) in staat tot interoperabiliteit, zoals bepaald op basis van de gemeenschappelijke compilatie van talen op hoog niveau – in de vorm van slimme contracten – in Ethereum bytecode door de EVM. Vanuit deze dispositie van Ethereum is het in staat om te fungeren als de tussenlaag tussen verschillende facetten van grote institutionele private datafaciliteiten en de publieke digitale goedereneconomie die momenteel in ontwikkeling is en tot bloei komt door de recente creatie van de symbolische economie..

Door deze functionaliteit tussen Ethereum-ketens toe te staan, kunnen complete interoperabele systemen worden gebouwd die economische finaliteit tussen systemen voor gegevenscoördinatie en -verwerking in particuliere Ethereum-platforms toewijzen aan digitale goederen in de openbare keten. Slimme contracten op Ethereum bevatten programmeerbare logica binnen deze systemen en stellen ontwikkelaars in staat om te communiceren met de Ethereum Virtual Machine door middel van transacties die nieuwe toestandsomgevingen creëren binnen de technologische infrastructuur. Naarmate zich alomvattende use-cases ontwikkelen binnen interoperabele openbare keten, privéketen en consortiumketenomgevingen, zullen de slimme contracten die in Ethereum worden gebruikt, de systemen kunnen verbinden onder een gemeenschappelijke logische interface.

Hyperledger-stof

Chaincode is niet per se een slim contract dat wordt geïmplementeerd in een accountgebaseerde blockchain, maar eerder een programma dat wordt geïnstalleerd en dat vervolgens een interface implementeert via een API. De API-interface vereist de op code gebaseerde instructies om de bedrijfslogica en -functionaliteit door het hele systeem te sturen, vergelijkbaar met een traditionele softwareontwikkelingsomgeving. Methoden die zijn aangesloten bij de API zijn onder meer:

  • Initiëren – starten van applicatiestatussen
  • Aanroepen – transactievoorstellen verwerken

Chaincode moet interfaces van de API implementeren:

  • Kettingcode-interface
  • ChaincodeStubInterface

In Hyperledger Fabric wordt kettingcode uitgevoerd in beveiligde Docker-containers, waar deze wordt geïsoleerd van processen die worden uitgevoerd door de goedkeurende peer. De code wordt normaal gesproken geschreven in Go of Node.js, waardoor interactie mogelijk is die de bedrijfslogica afhandelt. Een nuance om in gedachten te houden is dat de Fabric-kettingcode niet wordt gerepliceerd door de knooppunten binnen het ecosysteem op dezelfde manier als wordt verwacht van een echte blockchain-architectuur.

Chaincode wordt in eerste instantie geïnstalleerd op peers en vervolgens geïnstantieerd in kanalen. De processtroom wordt gedetailleerd in de volgende diagrammen:

Tijdens de Chaincode-processtroom vinden er verschillende interacties plaats met System Chaincode die wordt uitgevoerd binnen een uitvoerbaar peer-proces versus een geïsoleerde container.Dit wordt gebruikt om systeemgedrag te implementeren zonder goedkeuringsbeleid of levenscyclusprocessen.System Chaincode doorloopt niet de codelevenscyclus van normale ChaincodeTijdens de Chaincode-processtroom vinden verschillende interacties plaats met System Chaincode, dat wordt uitgevoerd binnen een uitvoerbaar peer-proces versus een geïsoleerde container. Dit wordt gebruikt om systeemgedrag te implementeren zonder goedkeuringsbeleid of levenscyclusprocessen. System Chaincode doorloopt niet de codelevenscyclus van normale Chaincode. Twee functies van de Shim API van de chaincode-interface worden geïmplementeerd De code wordt gecompileerd en onderhouden door de peer Chaincode is niet gelieerd aan kanalen of bestellers totdat de ontwikkelaar heeft vastgesteld dat ze het programma verder willen installerenTwee functies van de Shim API van de chaincode-interface worden geïmplementeerd. De code wordt samengesteld en onderhouden door de peer. Chaincode is niet gelieerd aan kanalen of bestellers totdat de ontwikkelaar heeft vastgesteld dat ze het programma verder willen installeren.

Chaincode kan worden geconfigureerd om activa te creëren die uiteindelijk fungeren als sleutel-waardeparen die worden opgeslagen in de grootboekdatabase. De workflow van het verzenden van initiatiecommando’s en het oproepen van de transacties wordt gedetailleerd in het bovenstaande diagram in termen van hoe commando’s door het systeem worden verplaatst. De bedrijfslogica is gecodeerd binnen de regels van het netwerk en wordt aangeroepen via client-side applicaties. Het type codecoördinatie en -interactie is zeer kenmerkend voor traditionele softwareontwikkeling door de afhankelijkheid van traditionele functies en initiatie-interfaces.

Commentaar

De verplaatsing van Chaincode door deze netwerkconfiguratie zorgt voor een gestroomlijnde organisatie van het systeem. De softwarearchitectuur is klaar om te fungeren als een zeer efficiënte commando- en controlestructuur in termen van het distribueren van gegevens en het organiseren van de softwareontwikkelingsomgeving voor bepaalde gebruiksscenario’s van ondernemingen. Zoals kan worden opgemaakt uit het pakket, de installatie, het instantiëren en de upgrade-instellingen, is deze architectuur ontworpen om de nodige touchpoints te optimaliseren die nodig zijn om code te verwerken. De benodigde API-interfaces wanneer transacties worden verwerkt, doen sterk denken aan traditioneel softwareontwerp. Aandachtspunten:

  • Monolithische architectuur voor maximale controle
  • Beveiligde zakelijke interactie tussen tegenpartijen
  • Centraal gecoördineerde verwerking voor transactiedoorvoer

Chaincode is meer een systeem van commando’s dan een slimme contracttaal die wordt gerepliceerd door een blockchain. Omdat het Hyperledger Fabric-ecosysteem een ​​levendige reeks sterke kenmerken heeft in termen van functionaliteit en ontwerp als een gedistribueerd grootboek, mist het systeem in feite de inherente kwaliteiten van een echt blockchain-systeem. Als een hulpmiddel dat kan worden gebruikt voor integratie met legacy-infrastructuur en paradigma’s, is Fabric effectief omdat het voldoet aan reeds bestaande softwarestandaarden, zoals kan worden afgeleid uit het architecturale ontwerp zoals hierboven beschreven.

Waar Fabric aan functionaliteit wint in termen van zijn systeem dat enigszins symbolisch is voor systemen die zijn ontworpen rond grote mainframes en datacenters, verliest het in andere aspecten in termen van gedistribueerde verbinding met economische rekenfactoren die toegankelijk zijn in een inherent gedecentraliseerde digitale token-economie . Als Fabric zou worden geïntegreerd in een echte blockchain-omgeving, zou het goed passen als een veilige gedistribueerde databaseomgeving die informatie valideert voorafgaand aan interactie met een openbaar blockchain-ecosysteem.

R3 Corda

In Corda worden slimme contracten beschouwd als klassen die de contractinterface implementeren. Slimme contracten zijn geschreven in Java / Kotlin en worden gecompileerd via de Java Virtual Machine (JVM), de computer waarop de code wordt uitgevoerd. De belangrijkste functie die in de contracten wordt gebruikt, is de functie “verifiëren”.

Code wordt uitgevoerd op de JVM waar transacties worden verwerkt via het notariële systeem, en de bedrijfslogica is beperkt binnen Flows die het bedrijfsproces tussen verschillende tegenpartijen kan huisvesten en isoleren.

staat object

Slimme contractcomponenten:

  • Uitvoerbare code
  • Valideert wijzigingen in transacties
  • Staat Objecten
  • Gegevens in het grootboek
  • Huidige staat van een contract
  • Gebruikt input en output van transacties
  • Commando’s
  • Aanvullende gegevens
  • Wordt gebruikt om uitvoerbare contractcode te instrueren

Java- en Kotlin-code worden via de JVM in identieke bytecode gecompileerd. Commando’s geven aanvullende gegevens die niet in de staat bestaan, door in de contractcode. Commando’s fungeren als datastructuren met aangehechte openbare sleutels die worden gebruikt om transacties te ondertekenen, hoewel het moet worden erkend dat contracten niet rechtstreeks werken met de digitale handtekeningen. Contracten binnen deze omgeving worden door het hele systeem gerepliceerd in de context van hoe Flows bereid is te coördineren tussen vertrouwde partijen.

Commentaar

De contractcode past bij de behoeften van use cases binnen de Corda-omgeving en is in staat om de noodzakelijke functies van transactiedoorvoer te vervullen. Beperkingen zijn onder meer de interoperabiliteit met andere ecosystemen. Om systemen te laten samenwerken met Corda, zouden ze het Corda-contractcodekader moeten gebruiken dat is ontworpen rond de gesloten DLT. In tegenstelling tot een echt blockchain-platform zoals Ethereum dat kan fungeren als de interoperabiliteitslaag tussen economische processen en functies tussen private instantiaties en publieke instantiaties, beperkt Corda zichzelf door meer gefocust te zijn op processen binnen een gesloten systeem. Het gebruik van de JVM is innovatief, hoewel de instantie geïsoleerd is binnen het Corda-ecosysteem. In dit scenario verkrijgt Corda transactieverwerking in een beveiligde omgeving terwijl het de mogelijkheid opoffert om samen te werken en te coördineren tussen verschillende blockchain-omgevingen, zoals een interoperabel systeem zou kunnen doen.

IV. Conclusie en beoordeling

Op basis van onze analyse zijn de belangrijkste onderscheidende factoren die Ethereum kan implementeren naast wat in staat is tot DLT:

  • Digitale activa of symbolische economie
  • Crypto-economische stimuleringslagen in het protocol
  • Interoperabiliteit tussen consortium en openbare blockchains

Hoewel DLT’s zoals R3 Corda en Hyperledger Fabric functionaliteit kunnen bereiken in het gedeelde databasebeheer en de levenscyclus van transactieverwerking, is het niet gegarandeerd dat ze in staat zullen zijn om de belangrijkste functionaliteiten te bereiken zoals hierboven beschreven. Deze platforms zijn niet gebrekkig, maar eerder beperkt in hun architecturale configuratie om enkele van de pure use-cases te tonen die alleen echte blockchains kunnen beweren.

Blockchain-technologieën zijn ontworpen om het vertrouwen dat erin is ontstaan ​​te koppelen aan de tastbare waarde die uit dat vertrouwen wordt gecreëerd. Alleen via een echt platform dat is opgebouwd uit de basisprincipes van een blockchain, kunnen sociale, politieke en economische systemen fundamenteel worden ingewijd binnen de infrastructuur van een softwareprotocol. Hoewel DLT-gerichte databasebeheerplatforms kunnen integreren en samenwerken met een blockchain-platform, moeten de rails waarop waardeoverdracht en coördinatie van dit vertrouwen worden gebouwd, een blockchain zijn die de kernprincipes van vertrouwen, onveranderlijkheid, integriteit en informatiewaarheid belichaamt..

Wat deze analyse onthult, is niet dat bepaalde systemen beter zijn dan andere, maar dat ze in verschillende hoedanigheden bruikbaar zijn. Het vermogen van DLT-platforms om te fungeren als gedistribueerde privé-databases met hoge transactiedoorvoer en functionaliteit, stelt hen in staat om te fungeren als vertrouwde systemen die kunnen samenwerken binnen een blockchain-platform wanneer bepaalde facetten van privé-informatie nodig zijn voor beoordeling, zoals bank- / financiële gegevens of gevoelige informatie met betrekking tot de interne werking van een particuliere instelling die niet aan het publiek mag worden onthuld. De verschillende bedrijfsmodellen voor het gebruik van deze bronnen van privégegevens die zijn aangesloten bij DLT zijn nog in ontwikkeling en moeten worden herhaald met blockchain-interfaces in gedachten, aangezien een gedecentraliseerd digitaal waardesysteem nodig is voor sommige interacties tussen blockchains en DLT’s..

Maak contact met onze blockchain-experts

Ons wereldwijde Solutions-team biedt blockchain-training, strategisch advies, implementatiediensten en samenwerkingsmogelijkheden. Neem contact met ons op Nieuwsbrief Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.Volledige gids voor Blockchain-bedrijfsnetwerkenGids

Volledige gids voor Blockchain-bedrijfsnetwerken

Inleiding tot tokenisatieWebinar

Inleiding tot tokenisatie

De toekomst van digitale activa en defiWebinar

De toekomst van financiën: digitale activa en deFi

Wat is Enterprise EthereumWebinar

Wat is Enterprise Ethereum?

Centrale banken en de toekomst van geldWit papier

Centrale banken en de toekomst van geld

Komgo Blockchain voor Commodity Trade FinanceCase Stud

Komgo: Blockchain voor Commodity Trade Finance

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map