blogul 1NewsDevelopersEnterpriseBlockchain Explained Evenimente și conferințe ApăsațiBuletine informative

Aboneaza-te la newsletter-ul nostru.

Adresa de email

Vă respectăm confidențialitatea

HomeBlogEnterprise Blockchain

Blockchain vs. Distributed Ledger Technologies (DLTs): Partea 2

O analiză comparativă a arhitecturilor și dinamicii de guvernare a Ethereum, Hyperledger Fabric și R3 Corda. De ConsenSys 23 mai 2018 Publicat pe 23 mai 2018

blockchain dlt 2 erou

Aceasta este partea 2 a unei analize comparative în două părți a Ethereum, Hyperledger Fabric și R3 Corda. Citiți partea 1 din Blockchain vs. DLT. 

Platforme tehnologice Blockchain vs. Distributed Ledger

Trebuie să se recunoască faptul că dacă coordonarea bazei de date și alocarea mai eficientă a codului sunt funcționalitatea dorită a unui sistem, atunci blockchain-ul poate să nu fie neapărat soluția pe care o organizație o caută. Sistemele de tehnologie de registru distribuite (DLT), cum ar fi Hyperledger Fabric sau R3 Corda, sunt capabile de funcționalități similare cu sistemele blockchain, dar ar trebui să se ia în considerare faptul că blockchain-urile sunt un subset separat de registre distribuite care au funcționalități suplimentare dincolo de coordonarea codului. Blockchain-urile sunt capabile de funcții pe care registrele distribuite nu sunt în termeni de instanțiere a valorii digitale bazate pe compoziția sistemului.

În acest document, vor fi explorate considerații arhitecturale care identifică aspectele care contribuie la funcționalitatea blockchain. O examinare ar fi că poate există un compromis între ceea ce blockchain-urile sunt capabile să realizeze și ceea ce furnizează DLT. DLT a fost destinat procesării tranzacțiilor într-un mediu de încredere partajat, în timp ce blockchain-urile adevărate au fost concepute pentru a sacrifica necesitatea unei configurări de încredere pentru a obține o fidelitate ridicată și imuabilitatea conturilor. Aspectele de înaltă fidelitate și imuabilitate sunt esențiale pentru succesul digitalizării corespunzătoare a activelor. Analiza din acest document va suprapune componentele arhitecturale de-a lungul proceselor de afaceri pentru a elucida în continuare aceste nuanțe tehnologice pe platforme.

Figura 1 Este important să se facă distincții între stivele de tehnologie și modul în care acestea se compară în ceea ce privește funcționalitatea și cazurile de utilizare.Este important să se facă distincții între stivele de tehnologie și modul în care acestea se compară în ceea ce privește funcționalitatea și cazurile de utilizare. În timp ce tehnologia contabilă distribuită a fost puternic influențată de tehnologia blockchain, ar trebui să distingem considerațiile arhitecturale ale platformelor tehnologice.

Comparațiile se vor face pe baza mai multor caracteristici cheie distincte care există în cadrul platformelor software. Principalele domenii care vor fi explorate în acest document includ:

  • Stat: Starea se referă la unitatea logică principală din care poate fi format codul, pentru a facilita reprezentarea informațiilor într-un mediu de calcul. În timp ce starea poate avea diverse semnificații în contexte diferite, utilizarea stării în cadrul blockchain-ului și al mediului contabil distribuit constă în configurația actuală a caracteristicii ontologice a unei structuri de date.
  • Tranzacții: Într-un mediu blockchain, tranzacțiile sunt considerate evenimentele de calcul care pot duce la generarea de tranziții de stat sau de stat care au loc în cadrul ecosistemului de dezvoltare. Tranzacțiile pot iniția contracte sau pot apela la contracte preexistente.
  • Contracte inteligente: În evaluarea unei platforme blockchain dintr-o perspectivă arhitecturală, este important să se determine structura codului de contract inteligent și modul în care acesta funcționează în raport cu topologia rețelei blockchain efective. Contractele inteligente sunt considerate unitățile individuale de cod care execută acțiuni în cadrul ecosistemului platformei.

Tabelul următor prezintă o scurtă prezentare generală a principalelor diferențe dintre diferitele caracteristici tehnologice ale platformelor respective.

caracteristicile platformeiO prezentare generală a caracteristicilor tehnologice ale Ethereum, Hyperledger Fabric și R3 Corda.

I. Statul

Ethereum

Fiind un ecosistem cu configurații distribuite partajate, Ethereum instanțiază conceptul de „stat” printr-o configurație de obiecte numită „Conturi”. Există două tipuri de conturi în Ethereum:

  • Conturi de contract – conturi controlate prin codul contractului
  • Conturi deținute extern – conturi controlate de o cheie privată

Ethereum folosește conceptul de stat mondial, care este o mapare a adreselor contului și a stărilor contului. State_Root este o rădăcină a lui Patricia Merkle Tree a fuziunii conturilor din sistem. Și în cadrul conturilor, statele contractuale sunt, de asemenea, organizate în această structură de date Patricia Merkle Tree. Hash-ul rădăcină al statului poate fi utilizat pentru a asigura identitatea datelor din arborele merkle permițând replicarea în întreaga rețea, ceea ce duce în cele din urmă la imuabilitatea teoretică a sistemului.

Adevăratele blockchain-uri se disting de DLT pe baza dependenței lor de această structură de date Patricia Merkle Tree și a orchestrării lor între blocuri, care este utilizată pentru a instanția starea sistemului Acest concept este parte integrantă a validității integrității datelor și a fidelității unei arhitecturi de sistem blockchain.Blockchain-urile adevărate se disting de DLT pe baza dependenței lor de această structură de date Patricia Merkle Tree și a orchestrării lor între blocuri, care este utilizată pentru a instanția starea sistemului. Acest concept face parte integrantă a datelor, validității și fidelității unei arhitecturi de sistem blockchain.

Comentariu

Funcționalitatea pe care Ethereum World State o creează este un sistem de încredere care permite instanțierea valorii într-un format digital. Surse de valoare reprezentativă digitală care sunt native economiei simbolice pot fi derivate din compoziția conturilor și structurilor de subdate ale Ethereum; în același mod în care porțile logice sunt capabile să instanțeze algoritmi funcționali în ingineria tradițională.

Platformele derivate din Ethereum, inclusiv clienții Ethereum și implementările private pot beneficia de această instanțare a valorii prin convingeri la aceste standarde în ceea ce privește conservarea stării și implementarea logică. Platformele care nu reușesc să instanțeze una dintre aceste funcționalități bazate pe valori logice nu vor putea facilita crearea unor adevărate valori descentralizate ale activelor digitale.

Tesatura Hyperledger

În Hyperledger Fabric, starea este păstrată într-o structură de bază de date, bazându-se pe stocurile de chei / valori pentru stat. Interacțiunea dintre programele Chaincode și modul în care acestea sunt instalate în topologia platformei permit emiterea comenzilor și acțiunilor în sistem. Aceste acțiuni au ca rezultat actualizări ale magazinelor de date, deoarece tranzacțiile au ca rezultat actualizări ale stării cunoscute sub numele de registru. Registrul este formulat ca o bază de date distribuită partajată care oferă utilizatorilor acces superior la informații și tranzacții care au loc în mediul de calcul distribuit. State este cuibărit în mediul bazei de date prin intermediul instrumentelor tradiționale de dezvoltare software:

  • LevelDB creează o bază de date cheie / valoare
  • CouchDB ar deține baza de date Document JSON

arhitectura țesăturilorÎn arhitectura Fabric, formatul bazei de date a modului în care sunt organizate toate procesele este capabil să mărească procesarea tranzacțiilor și să maximizeze eficiența computațională în ecosistem.

În baza de date de stat, cele mai recente valori ale versiunii pentru chei în jurnalul de tranzacții în lanț sunt stocate ca perechi cheie / valoare. Valorile cheie cunoscute sub numele de World State sunt indexate pentru o vizualizare în jurnalele de tranzacții care există în arhitectura canalului. CouchDB acționează ca un proces de bază de date separat care primește actualizări de la API-ul codului de cod.

Comentariu

Hyperledger Fabric a creat un proces care înlocuiește principiile cheie ale unui sistem blockchain în schimbul realizării unor tranziții de stare cu randament ridicat. Utilizarea arhitecturii actuale permite modificarea și manifestarea mai ușoară a stărilor într-o schemă software tradițională, rezultând accesul la citire / scriere. Deși aranjarea stării în mediul Fabric este eficientă, nu are capacitatea de a crea valoare într-un ecosistem public descentralizat, în același mod în care ar putea face un adevărat blockchain precum Ethereum sau Bitcoin. Mișcarea datelor în mediul software al Fabric este o indicație a capacității unei baze de date distribuite. Crearea de active digitale în cadrul Fabric ar fi în esență informații digitale stocate într-o bază de date care este controlată de părțile sau grupurile care controlează într-un consorțiu, fără a adera la structura economică a bunurilor digitale.

R3 Corda

În R3 Corda, State se bazează pe secvențierea și versionarea diferitelor seturi de date în cadrul arhitecturii platformei. În sistem, rețeaua menține un seif, care este o bază de date care stochează stările istorice care sunt urmărite în cadrul sistemului. În Corda, starea este considerată a include date opace care sunt comparabile cu un fișier de disc care nu este neapărat actualizat, deși este folosit mai degrabă pentru a genera noi succesori. Acest sistem acționează ca o serie de actualizări de stare modificate și reafăcute într-un mediu controlat și partajat de utilizatori.

Figura 5 Registrul este considerat ca ansamblul tuturor stărilor actuale care sunt activate. Acest lucru împrumută de la modelul bitcoin UTXO, deși nu implementează aceleași caracteristici de păstrare a copacilor Patricia Merkle care există în tehnologia blockchain, deși utilizează mai degrabă o parte din tehnologia în subsecțiuni ale platformei spre deosebire de nucleu În timp ce statele acționează ca instanțe ale claselor stocate în seif, secvențierea și versionarea datelor oferă un mijloc viabil de stocare a datelorRegistrul este considerat ca ansamblul tuturor stărilor actuale care sunt activate. Acest lucru împrumută de la modelul UTXO bitcoin, deși nu implementează aceeași stare de păstrare a caracteristicilor copacilor Patricia Merkle care există în tehnologia blockchain, deși utilizează mai degrabă o parte din tehnologie în subsecțiuni ale platformei, spre deosebire de nucleu. În timp ce stările acționează ca instanțe ale claselor stocate în seif, secvențierea și versionarea datelor oferă un mijloc viabil de stocare a datelor.

În Corda, statele sunt considerate clase care stochează date. Clasele sunt implementări ale interfeței „ContractState” care acționează ca strat de interoperabilitate în cadrul platformei. Anumite câmpuri de date „de stat” pot include:

  • Emitere
  • Proprietar
  • faceValue și Suma>
  • maturitateData

Formatul acestui design a fost să permită adăugarea datelor într-un lanț de evenimente, permițând posibilitatea de a urmări proveniența de unde provin datele în mediul controlat. Proveniența este controlată de membrii consorțiului care au anumite controale de acces la platforma software. Folosind această configurație, băncile și instituțiile financiare vor putea maximiza eficiența în ceea ce privește procesarea informațiilor într-un ecosistem de registru comun. Datele pot fi mai bine mutate și procesate între organizații, reducând în același timp nevoia de încredere substanțială între contrapartidele care nu au încredere.

Comentariu

Această configurație arhitecturală este capabilă în mod similar să proceseze date partajate într-un mediu semi-de încredere în care contrapartidele nu trebuie să aibă încredere deplină. Datele pot fi procesate și adăugate cu succes în ceea ce consideră stare Corda, deși platformei îi lipsesc componentele unui sistem blockchain care poate dezvălui o valoare fără echivoc. În Corda, starea nu este o construcție logică, deși mai degrabă bucăți de informații atașate într-un registru asemănător unei baze de date. În timp ce activele pot fi digitalizate și stocate în formatul de stat cheltuit și neutilizat, activele nu vor putea fi unități de valoare distincte, asemănătoare modului în care Bitcoin, Ethereum și economia token creează noi piețe, deși software-ul bancar ar putea fi un bun de încredere configurație care poate ajuta să acționeze ca un hub de atestare pentru informații nepublică sigure, similar cu modul în care sistemul bancar funcționează în prezent în prezent.

II. Tranzacții

Ethereum este un ecosistem de mașini bazat pe tranzacții în care starea globală a tranzacțiilor este stocată în blocuri. Când au loc tranzacții, tranzițiile de stare duc la noi stări ale sistemului. Acest proces sacrifică viteza procesării rapide a tranzacțiilor bazei de date pentru integritatea unui sistem care emblematizează starea, precum și tranzacția care a condus la starea respectivă în cadrul configurației structurii de date Patricia Merkle Tree..

Figura 6 În cadrul acestei arhitecturi starea împreună cu tranzacțiile care conduc la tranziții de stare sunt păstrate într-o paradigmă software care folosește Patricia Merkle Trees pentru a bloca datele într-o realitate istorică care se realizează în interiorul blocurilorÎn cadrul acestei arhitecturi, starea împreună cu tranzacțiile care conduc la tranziții de stare sunt păstrate într-o paradigmă software care folosește Patricia Merkle Trees pentru a bloca datele într-o realitate istorică care se realizează în interiorul blocurilor..

Există două tipuri de tranzacții:

  • Mesaj apeluri
  • Creații contractuale.

Tranzacțiile includ un mecanism intern de transfer de valoare. Transferul de valoare în conturile contractuale duce la schimbări de stare. Deoarece sistemul se bazează pe transferul de valoare între contractele inteligente care există între evenimente de execuție a tranzacțiilor, diferitele stări compartimentate pot fi utilizate pentru a instanția logica și acordurile de afaceri de înaltă fidelitate.

Comentariu

Caracteristica cheie distinctivă a Ethereum este că tranzacțiile sunt utilizate ca unități individuale de proces în mediul blockchain Ethereum și, prin această configurație, păstrează o evidență permanentă a stărilor tranzacționale din sistem. Ethereum este capabil atât de capabilitățile tehnologice tradiționale ale bazelor de date distribuite, cât și de a combina încrederea dorită cu valoarea digitală. Tehnologiile derivate din blockchain-ul Ethereum sunt capabile să grupeze tranzacțiile și logica de afaceri în blocuri ale unui blockchain. Funcționalitatea de afaceri derivată din această configurare include:

  • Adevarata economie digitala
  • Bunuri și active digitale controlate de stimulente economice spre deosebire de stimulente organizaționale / monopoliste
  • Interfață de interacțiune între instituțiile private și economia digitală publică

Arhitectura Ethereum permite platformelor afiliate să poată instanția straturi de stimulente cripto-economice în sistem. Aceasta înseamnă că pot fi create diferite straturi de stimulente și modele de mecanisme pentru a securiza rețeaua generală, comparativ cu dependența de servicii controlate central oferite de proiectele software tradiționale. Acest strat de stimulare cripto-economică poate fi aplicat atât economiei bunurilor digitale, cât și stratului de interfață între versiunile private și publice ale unei platforme blockchain.

Tesatura Hyperledger

Toate tranzacțiile sunt executate în cadrul arhitecturii multicanal Fabric pentru a asigura un randament ridicat al tranzacțiilor în mediul de încredere. Tranzacțiile sunt anexate la un registru partajat care există în mediul de rulare. Cu această arhitectură, Fabric permite accesul la citire / scriere și accesibilitatea la mediul lor software, permițând funcționalitatea și utilitatea de tip mainframe. Se știe că bazele de date SQL sunt mai multe ordine de mărime mai performante decât orice blockchain care este disponibil în prezent, iar configurația Fabric împrumută mult din paradigme utilizate în instrumentele tradiționale de baze de date, permițând o tranzacție superioară a tranzacției..

Există două tipuri de tranzacții:

  • Implementați tranzacții – creați un nou cod de lanț. Instalează codul de acces în mediul de dezvoltare software
  • Invocați tranzacții – invocă codul de cod creat anterior și funcțiile corespunzătoare. Când acest lucru este executat cu succes, codul de chainc îndeplinește o funcție și introduce modificări în stare
  • Funcțiile de invocare duc la tranzacții „obțineți” sau „setați”

Pentru a maximiza procesarea eficientă a datelor și viteze superioare, tranzacțiile individuale AKA blob-uri sunt grupate de către un serviciu de comandă Apache Kafka și trimise ca „blocuri” printr-un eveniment de livrare. Tranzacțiile (blob-uri) sunt comandate de Serviciul de comandă Apache Kafka și anexate la partițiile Kafka. Ceea ce înseamnă acest lucru este că arhitectura Fabric sacrifică integritatea și fidelitatea datelor unui sistem blockchain adevărat pentru a obține procesarea și transferul mai rapid al tranzacțiilor într-un mediu de streaming de date de încredere, după cum reiese din utilizarea serviciului de comandă Apache Kafka.

Figura 7 După cum se poate evalua din documentația Fabric, tranzacțiile comandate sunt atașate direct la partițiile afiliate la subiectele Kafka. Acest lucru duce la tranzacții cu randament ridicat care apar într-un mediu de flux de date de încredere Sursa Apache KafkaDupă cum se poate evalua din documentația Fabric, tranzacțiile comandate sunt anexate direct la partițiile afiliate la Subiectele Kafka. Acest lucru are ca rezultat tranzacții cu randament ridicat care apar într-un mediu de streaming de date de încredere. (Sursa: Apache Kafka)

Comentariu

Deși sistemul utilizează terminologia blockchain-esque, aceasta nu este un blockchain în sensul tradițional, în sensul că nu există păstrarea tranzacțiilor de stat și complementare într-o structură de date Patricia Merkle Tree. Hyperledger Fabric este un DLT, nu un blockchain. Arhitectura Fabric a fost concepută pentru o procesare superioară a tranzacțiilor, după cum se poate observa din adăugarea bloburilor de date în serviciul de comandă a fluxului de date Kafka. Deoarece acest lucru se realizează într-un mediu de încredere, execuțiile pot avea loc în mod liber în sistem. Utilizarea acestei configurații într-un sistem de transfer de valoare nu ar fi ideală, având în vedere că toată încrederea ar trebui atribuită direct unei arhitecturi software dintr-o singură entitate, spre deosebire de un ecosistem sau protocol comun. După cum se poate vedea din documentele tehnice, Fabric a renunțat din punct de vedere arhitectural la integritatea și securitatea datelor obținute în platformele blockchain pentru a obține o prelucrare superioară între componentele tranzacției.

R3 Corda

În R3 Corda, tranzacțiile sunt considerate propuneri de actualizare a bazei de date Vault, care poate fi denumită registru. Tranzacțiile trebuie executate într-un mediu în care notarii pot valida că nu sunt cheltuite dublu și că sunt semnate de părțile necesare. Acest lucru este similar cu conceptul utilizat în ecosistemul bitcoin, deși evitarea cheltuielilor duble este facilitată de un sistem de încredere.

Există două tipuri de bază de tranzacții:

  • Tranzacții de modificare notarială – acestea sunt executate pentru a parcurge notarii din sistem. Notarii vor preveni cheltuielile duble și pot valida tranzacțiile
  • Oferiți un consens unic
  • Tranzacții generale – utilizate pentru orice altceva

stare finală

Tranzacțiile sunt propuse actualizări ale stării mediului bazei de date care necesită validarea semnăturilor de la alte părți din sistem. Pentru ca o tranzacție să fie validă, aceasta trebuie:

  1. Să fie semnat de părțile implicate
  2. Obțineți validarea prin codul contractului care determină tranzacția

arhitectura clientului

Utilizarea modelului de tip UTXO într-un mediu de baze de date partajate permite platformei Corda să controleze starea, precum și tranzițiile. Utilizarea notarului și diferite interacțiuni între Fluxuri și Cordapps în configurația rețelei arată un mediu distribuit partajat în care starea este păstrată într-un format de date integrant arhitecturii sistemului. Utilizarea tranzacțiilor pentru a naviga instanțierea stărilor în mediul bazat pe noduri între fluxuri, precum și Cordapps care se programează în noduri, indică un mijloc viabil de a executa modificări de stare într-un registru.

Comentariu

Pentru formarea activelor digitale, utilizatorii și contrapartidele depind de încrederea platformei generale Corda. În timp ce acționează ca un sistem de contabilitate distribuit puternic de încredere pentru păstrarea datelor financiare sensibile, sistemul acționează în conformitate cu diferite standarde care există în ecosistemul bancar. Platforma oferă:

  • Stocare superioară a datelor financiare nepublicale
  • Configurare de încredere pentru instituții financiare care nu au încredere
  • Depozitarea avansată a interacțiunilor comerciale

Diagramele arhitecturale care implică fluxuri și medii de rulare între noduri arată că Corda a fost conceput pentru a partiționa accesul între membrii de încredere ai platformei consorțiului său. Deși este capabil de anumite aspecte ale utilizabilității, R3 Corda nu are funcționalități inerente în a fi un substrat universal pentru transferul de valoare economică, socială și politică, din cauza lipsei unui strat de stimulent cripto-economic, precum și a unui mediu public de active digitale. Deoarece sistemul este închis, îi lipsesc șinele și trăsăturile tehnologice necesare pentru construirea unui ecosistem stimulat de stimulente economice. R3 Corda este cel mai probabil cel mai bine utilizat pentru anumite fațete ale infrastructurii bancare tradiționale, deși nu pentru crearea de active digitale.

III. Contracte inteligente

Ethereum

În Ethereum, contractele inteligente sunt scrise în limbaje de programare la nivel înalt, cum ar fi soliditatea, LLL sau Viper și sunt compilate în bytecode EVM, permițând executarea binarelor de către Ethereum Virtual Machine (EVM). Nodurile din rețeaua Ethereum își rulează propria implementare EVM, care acționează ca un mediu de rulare pentru contractele inteligente din ecosistemul Ethereum. Statul și tranzacțiile care conduc la tranziții de stat sunt emblematizate în starea mondială a blockchain-ului Ethereum prin replicarea de către EVM, rezultând un sistem care poate implementa încredere incoruptibilă pe o serie de spectre.

EVM 1

EVM acționează ca un mediu de execuție pentru a executa recursiv tranziții de stare pentru a calcula starea sistemului și starea mașinii pe măsură ce parcurge tranzacțiile.

  • Starea sistemului = Starea globală Ethereum
  • Starea mașinii = logica de afaceri a conturilor contractuale & cod replicat în runtime EVM

Deoarece toate codurile de contract inteligente sunt reproduse de toate nodurile din EVM, blockchain-ul Ethereum și instanțierile aferente sunt capabile să păstreze valabilitatea codului pentru a asigura coerența contractelor. Coerența contractelor contribuie la imuabilitatea practică a blockchain-ului Ethereum și a clienților și implementărilor sale afiliate. Contractele inteligente pe Ethereum leagă întregul ecosistem prin instanțierea tranzacțiilor care duc în cele din urmă la tranziții către noi stări în mediul global al mașinilor virtuale.

Comentariu

Deoarece implementările EVM aderă strict la specificațiile descrise în Cartea Galbenă Ethereum, diferite instanțieri ale Ethereum (publice, private și consorțiale) sunt capabile de interoperabilitate, astfel cum se determină din compilarea comună a limbajelor de nivel înalt – sub formă de smart contracte – în bytecode Ethereum de către EVM. Din această dispoziție a Ethereum, este capabil să acționeze ca strat intermediar între diferitele fațete ale marilor facilități instituționale de date private și economia publică a bunurilor digitale care evoluează în prezent și se realizează de la crearea recentă a economiei simbolice..

Permițând această funcționalitate între lanțurile Ethereum, pot fi construite întregi sisteme interoperabile care alocă finalitatea economică între sistemele de coordonare și procesare a datelor în platformele private Ethereum bunurilor digitale din lanțul public. Contractele inteligente pe Ethereum încapsulează logica programabilă în cadrul acestor sisteme și le permite dezvoltatorilor să interacționeze cu mașina virtuală Ethereum prin tranzacții care creează noi medii de stare în cadrul infrastructurii tehnologice. Pe măsură ce se dezvoltă cazuri de utilizare cuprinzătoare în cadrul lanțului public interoperabil, al lanțului privat și al lanțului consorțiului, contractele inteligente utilizate în Ethereum vor putea lega sistemele împreună printr-o interfață logică comună..

Tesatura Hyperledger

Chaincode nu este neapărat un contract inteligent desfășurat într-un blockchain bazat pe cont, ci mai degrabă un program instalat și care ulterior implementează o interfață printr-un API. Interfața API necesită instrucțiuni bazate pe cod pentru a direcționa logica și funcționalitatea afacerii în întregul sistem, similar cu un mediu tradițional de dezvoltare software. Metodele afiliate API-ului includ:

  • Inițierea – inițierea stărilor de aplicare
  • Invocare – procesarea propunerilor de tranzacții

Chaincode trebuie să implementeze interfețe din API:

  • Interfață cod de cod
  • ChaincodeStubInterface

În țesătura Hyperledger, codul de cod este rulat în containere Docker securizate, unde este izolat de procesele executate de partenerul de aprobare. Codul este scris în mod normal în Go sau Node.js, permițând interacțiuni care gestionează logica de afaceri. O nuanță de reținut este că codul de legătură Fabric nu este reprodus de nodurile din ecosistem în același mod în care se așteaptă de la o adevărată arhitectură blockchain.

Chaincode este inițial instalat pe Peers, apoi este instanțiat în canale. Fluxul procesului este detaliat în următoarele diagrame:

De-a lungul fluxului procesului Chaincode apar diferite interacțiuni cu System Chaincode care rulează într-un proces peer executabil față de un container izolat Acesta este utilizat pentru a implementa comportamente de sistem fără politici de aprobare sau procese de ciclul de viață Chaincode-ul sistemului nu trece prin ciclul de viață al codului ChaincodeDe-a lungul fluxului procesului Chaincode, apar diferite interacțiuni cu System Chaincode, care rulează într-un proces peer executabil față de un container izolat. Acesta este utilizat pentru a implementa comportamente ale sistemului fără politici de aprobare sau procese de ciclul de viață. System Chaincode nu trece prin ciclul de viață al codului Chaincode normal. Două funcții din API-ul Shim al interfeței chaincode sunt implementate Codul este compilat și menținut de către partener Chaincode nu este afiliat cu canale sau comenzi până când dezvoltatorul decide că doresc să instaleze în continuare programulSunt implementate două funcții din API-ul Shim al interfeței codului de cod. Codul este compilat și întreținut de către partener. Chaincode nu este afiliat cu canale sau comenzi până când dezvoltatorul nu stabilește că doresc să instaleze în continuare programul.

Chaincode poate fi configurat pentru a crea active care acționează în cele din urmă ca perechi cheie-valoare care sunt stocate în baza de date a registrului. Fluxul de lucru pentru trimiterea comenzilor de inițiere și invocarea tranzacțiilor sunt detaliate în diagrama de mai sus în ceea ce privește modul în care comenzile sunt mutate prin sistem. Logica de afaceri este codificată în regulile rețelei și invocată prin intermediul aplicațiilor din partea clientului. Tipul de coordonare și interacțiune a codului este foarte indicativ al dezvoltării software-ului tradițional prin dependențele de funcțiile tradiționale și interfețele de inițiere.

Comentariu

Mișcarea Chaincode prin această configurație de rețea permite o organizare simplificată a sistemului. Arhitectura software este pregătită pentru a acționa ca o structură de comandă și control foarte eficientă în ceea ce privește distribuirea datelor și organizarea mediului de dezvoltare software pentru anumite cazuri de utilizare a întreprinderii. Așa cum se poate desprinde din pachet, instalare, instanțiere și actualizare, această arhitectură a fost concepută pentru a optimiza punctele de contact necesare pentru procesarea codului. Interfețele API necesare pe măsură ce tranzacțiile sunt procesate amintesc foarte mult de designul software tradițional. Domenii de notare:

  • Arhitectură monolitică pentru control maxim
  • Interacțiune comercială securizată între contrapartide
  • Procesare coordonată central pentru transferul tranzacțiilor

Chaincode este mai mult un sistem de comenzi decât un limbaj de contract inteligent care este reprodus de un blockchain. Deoarece ecosistemul Hyperledger Fabric are un set vibrant de caracteristici puternice în ceea ce privește funcționalitatea și designul ca un registru distribuit, sistemul nu are, de fapt, calitățile inerente ale unui adevărat sistem blockchain. Ca instrument care poate fi utilizat pentru integrarea cu infrastructura și paradigmele vechi, Fabric este eficient datorită aderării sale la standardele software preexistente, după cum se poate deduce din designul arhitectural descris mai sus.

În cazul în care Fabric câștigă în funcționalitate în ceea ce privește sistemul său, care este oarecum emblematic pentru sistemele proiectate în jurul centralelor mari și a centrelor de date, pierde în alte aspecte în ceea ce privește conexiunea distribuită la factorii economici de calcul, așa cum poate fi accesat într-o economie de token digital descentralizată . Dacă Fabric ar trebui să se integreze într-un mediu blockchain adevărat, s-ar potrivi bine ca un mediu de baze de date distribuite sigur care validează informațiile înainte de interacțiunea cu un ecosistem public blockchain.

R3 Corda

În Corda, contractele inteligente sunt considerate clase care implementează interfața Contract. Contractele inteligente sunt scrise în Java / Kotlin și sunt compilate prin intermediul mașinii virtuale Java (JVM), care este mașina de calcul în care este executat codul. Funcția principală utilizată în contracte este funcția de „verificare”.

Codul rulează pe JVM în care tranzacțiile sunt procesate prin sistemul de notarizare, iar logica de afaceri este restricționată în cadrul fluxurilor care pot adăposti și izola procesul de afaceri între diferite contrapartide.

obiect de stat

Componente de contract inteligente:

  • Cod executabil
  • Validează modificările tranzacțiilor
  • Obiecte de stat
  • Date păstrate pe contabil
  • Starea actuală a unui contract
  • Utilizează intrările și ieșirile tranzacțiilor
  • Comenzi
  • Date adiționale
  • Folosit pentru a instrui codul contractului executabil

Java și codul Kotlin sunt compilate în bytecode identic prin intermediul JVM. Comenzile transmit date suplimentare care nu există în stat în codul contractului. Comenzile acționează ca structuri de date cu chei publice atașate utilizate pentru semnarea tranzacțiilor, deși ar trebui să se recunoască faptul că contractele nu funcționează direct cu semnăturile digitale. Contractele din acest mediu sunt reproduse în întregul sistem în contextul în care Fluxurile sunt dispuse să se coordoneze între părțile de încredere.

Comentariu

Codul contractului se potrivește nevoilor de cazuri de utilizare din mediul Corda și este capabil să îndeplinească funcțiile necesare de transfer tranzacțional. Limitările includ interoperabilitatea cu alte ecosisteme. Pentru ca sistemele să interacționeze cu Corda, ar trebui să utilizeze cadrul de cod al contractului Corda conceput în jurul DLT închis. Spre deosebire de o adevărată platformă blockchain, cum ar fi Ethereum, care poate acționa ca strat de interoperabilitate între procesele economice și funcțiile dintre instanțierile private și instanțierile publice, Corda se limitează fiind concentrat mai mult asupra proceselor dintr-un sistem închis. Utilizarea JVM este inovatoare, deși instanța este izolată în ecosistemul Corda. În acest scenariu, Corda câștigă procesarea tranzacțiilor într-un mediu securizat, sacrificând în același timp capacitatea de a interopera și coordona între diferite medii blockchain, cum ar fi un sistem interoperabil..

IV. Concluzie și evaluare

Pe baza analizei noastre, principalii factori distinctivi pe care Ethereum îi poate pune în aplicare dincolo de ceea ce este capabil de DLT sunt:

  • Activ digital sau economie simbolică
  • Straturi de stimulente cripto-economice în protocol
  • Interoperabilitate între consorțiu și blockchain-uri publice

Deși DLT-urile precum R3 Corda și Hyperledger Fabric sunt capabile să obțină funcționalități în gestionarea bazei de date partajate și în ciclul de viață al procesării tranzacțiilor, nu este garantat că vor putea atinge funcționalitățile cheie descrise mai sus. Aceste platforme nu sunt defecte, ci sunt destul de limitate în configurația lor arhitecturală pentru a prezenta unele dintre cazurile de utilizare pură pe care doar blockchain-urile adevărate sunt capabile să le afirme.

Tehnologiile Blockchain sunt concepute pentru a cupla încrederea instanțiată în interiorul lor, alături de valoarea tangibilă creată din această încredere. Numai printr-o adevărată platformă construită din elementele fundamentale ale unui blockchain, sistemele sociale, politice și economice vor putea fi consacrate fundamental în cadrul infrastructurii unui protocol software. În timp ce platformele de gestionare a bazelor de date axate pe DLT se pot integra și interopera cu o platformă blockchain, șinele pe care se vor construi transferurile de valoare și coordonarea acestei încrederi, trebuie să fie un blockchain care să întruchipeze principiile de bază ale încrederii, imuabilității, integrității și fidelității informațiilor..

Ceea ce relevă această analiză nu este că anumite sisteme sunt mai bune decât altele, ci mai degrabă sunt utile în diferite capacități. Capacitatea platformelor DLT de a acționa ca baze de date private distribuite, cu o tranzacție și funcționalitate ridicate ale tranzacțiilor, le permite să acționeze ca sisteme de încredere care pot interoperă într-o platformă blockchain atunci când anumite fațete ale informațiilor private sunt necesare pentru evaluare, cum ar fi datele bancare / financiare informații sensibile referitoare la funcționarea interioară a unei instituții private care nu ar trebui dezvăluite publicului. Diferitele modele de afaceri pentru modul de utilizare a acestor surse de date private afiliate DLT sunt încă în curs de dezvoltare și ar trebui să fie repetate cu interfețele blockchain în minte, deoarece un sistem de valori digitale descentralizat este necesar pentru unele dintre interacțiunile dintre blockchain-uri și DLT-uri.

Conectați-vă cu experții noștri blockchain

Echipa noastră globală de soluții oferă instruire blockchain, consultanță strategică, servicii de implementare și oportunități de parteneriat. Contactați-ne Newsletter Abonați-vă la newsletter-ul nostru pentru cele mai recente știri Ethereum, soluții pentru întreprinderi, resurse pentru dezvoltatori și multe altele. Adresa de e-mail Conținut exclusivGhid complet pentru rețelele de afaceri BlockchainGhid

Ghid complet pentru rețelele de afaceri Blockchain

Introducere în tokenizareWebinar

Introducere în tokenizare

Viitorul activelor digitale și al DeFi-ului financiarWebinar

Viitorul finanțelor: active digitale și DeFi

Ce este Enterprise EthereumWebinar

Ce este Enterprise Ethereum?

Băncile centrale și viitorul banilorHartie alba

Băncile centrale și viitorul banilor

Blockchain Komgo pentru finanțarea comerțului cu mărfuriStudiu de caz

Komgo: Blockchain pentru finanțarea comerțului cu mărfuri

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