NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressButlletins informatius

Subscriu-te al nostre butlletí.

Correu electrònic

Respectem la vostra privadesa

IniciBlogEmpresa Blockchain

Blockchain vs. Distributed Ledger Technologies (DLTs): 2a part

Anàlisi comparativa de les arquitectures i dinàmiques de govern d’Ethereum, Hyperledger Fabric i R3 Corda. Per ConsenSys 23 de maig de 2018 Publicat el 23 de maig de 2018

Aquesta és la part 2 d’una anàlisi comparativa en dues parts d’Ethereum, Hyperledger Fabric i R3 Corda. Llegiu la primera part de Blockchain vs. DLT. 

Blockchain vs. Plataformes tecnològiques distribuïdes

Cal reconèixer que si la coordinació de bases de dades i una assignació més eficient del codi són la funcionalitat desitjada d’un sistema, és possible que la cadena de blocs no sigui necessàriament la solució que busca una organització. Els sistemes de tecnologia de comptabilitat distribuïda (DLT) com Hyperledger Fabric o R3 Corda són capaços de tenir funcions similars als sistemes de cadenes de blocs, però s’ha de tenir en compte que les cadenes de blocs són un subconjunt separat de llibres de distribució que tenen funcionalitats addicionals més enllà de la coordinació de codis. Les cadenes de bloqueig són capaces de fer funcions que els llibres majors distribuïts no són en termes d’instanciació de valor digital en funció de la composició del sistema.

En aquest document, s’exploraran consideracions arquitectòniques que identifiquin els aspectes que contribueixen a la funcionalitat de blockchain. Un examen seria que potser hi ha un compromís entre el que les blockchains són capaços d’aconseguir i el que proporcionen els DLT. DLT estava pensat per al processament de transaccions en un entorn de confiança compartit, mentre que les autèntiques cadenes de blocs van ser dissenyades per sacrificar la necessitat d’una configuració de confiança per aconseguir una alta fidelitat i immutabilitat dels comptes. Els aspectes d’alta fidelitat i immutabilitat són fonamentals per a l’èxit de la digitalització adequada dels actius. L’anàlisi d’aquest document recobrirà els components arquitectònics de tots els processos empresarials per tal de dilucidar encara més aquests matisos tecnològics en totes les plataformes.

És important fer distincions entre les piles de tecnologia i la seva comparació en termes de funcionalitat i casos d’ús. Tot i que la tecnologia de llibres distribuïts va estar molt influenciada per la tecnologia blockchain, hauríem de distingir les consideracions arquitectòniques de les plataformes tecnològiques.

Les comparacions es faran basant-se en diverses característiques distintives clau que existeixen a les plataformes de programari. Les principals àrees que s’exploraran en aquest document són:

• Estat: L’estat fa referència a la unitat principal de lògica que pot incloure el codi per tal de facilitar la representació de la informació en un entorn informàtic. Tot i que estat pot tenir diversos significats en contextos diferents, l’ús de l’estat a l’entorn de la cadena de blocs i del llibre major distribuït consisteix en la configuració actual de la característica ontològica d’una estructura de dades..
• Transaccions: Dins d’un entorn blockchain, les transaccions es consideren els esdeveniments computacionals que poden conduir a la generació de transicions d’estat o estat que es produeixen dins de l’ecosistema de desenvolupament. Les transaccions poden iniciar contractes o contractar contractes preexistents.
• Contractes intel·ligents: En avaluar una plataforma blockchain des d’una perspectiva arquitectònica, és important determinar l’estructura del codi de contracte intel·ligent i el seu funcionament en relació amb la topologia de la xarxa blockchain real. Els contractes intel·ligents es consideren les unitats de codi individuals que executen accions a l’ecosistema de la plataforma.

La taula següent mostra una breu visió general de les principals diferències entre les diverses característiques tecnològiques de les plataformes respectives.

Una visió general de les característiques tecnològiques d’Ethereum, Hyperledger Fabric i R3 Corda.

I. Estat

Ethereum

Com a ecosistema amb configuracions distribuïdes compartides, Ethereum instancia el concepte d ‘”Estat” mitjançant una configuració d’objectes anomenada “Comptes”. Hi ha dos tipus de comptes a Ethereum:

• Comptes de contracte: comptes controlats per codi de contracte
• Comptes de propietat externa: comptes controlats per una clau privada

Ethereum utilitza el concepte d’estat mundial, que és un mapatge d’adreces i estats del compte. L’arrel_estat és una arrel de l’arbre de Patricia Merkle de la fusió de comptes al sistema. I dins dels comptes, els estats contractuals també s’organitzen en aquesta estructura de dades de Patricia Merkle Tree. El hash arrel de l’estat es pot utilitzar per assegurar la identitat de les dades de l’arbre merkle permetent la replicació a tota la xarxa, cosa que en última instància té com a resultat la immutabilitat teòrica del sistema.

Les autèntiques cadenes de blocs es distingeixen de DLT en funció de la seva dependència d’aquesta estructura de dades de Patricia Merkle Tree i de la seva orquestració entre blocs, que s’utilitza per instanciar l’estat del sistema. Aquest concepte és fonamental per a la integritat, validesa i fidelitat de les dades d’una arquitectura de sistemes blockchain.

Comentari

La funcionalitat que crea Ethereum World State és un sistema poc fiable que permet la instanciació de valor en format digital. Les fonts de valor de la representació digital originàries de l’economia simbòlica es poden obtenir a partir de la composició de comptes i estructures de subdades d’Ethereum; de la mateixa manera que les portes lògiques són capaces d’instanciar algorismes funcionals en enginyeria tradicional.

Les plataformes derivades d’Ethereum, inclosos els clients d’Ethereum i les implementacions privades, poden beneficiar-se d’aquesta instantània de valor per convicció d’aquests estàndards pel que fa a la preservació de l’estat i la implementació de la lògica. Les plataformes que no puguin instanciar una d’aquestes funcionalitats basades en el valor lògic no podran facilitar la creació de veritables valors d’actius digitals descentralitzats.

Teixit Hyperledger

A Hyperledger Fabric, l’estat es conserva en una estructura de base de dades amb dependència de magatzems de claus / valors per a l’estat. La interacció entre els programes de Chaincode i com s’instal·len a la topologia de la plataforma permeten emetre ordres i accions al sistema. Aquestes accions donen lloc a actualitzacions dels magatzems de dades, ja que les transaccions generen actualitzacions a l’estat conegut com a llibre major. El llibre major es formula com una base de dades distribuïda compartida que proporciona als usuaris un accés superior a la informació i les transaccions que es produeixen a l’entorn de computació distribuïda. State es troba a l’entorn de la base de dades mitjançant eines tradicionals de desenvolupament de programari:

• LevelDB crea una base de dades de claus / valors
• CouchDB contindria la base de dades Document JSON

A l’arquitectura Fabric, el format de base de dades d’organització de tots els processos permet augmentar el processament de transaccions i maximitzar l’eficiència computacional a l’ecosistema.

A la base de dades d’estats, els valors de la versió més recent de les claus del registre de transaccions de la cadena s’emmagatzemen com a parells clau / valor. Els valors clau coneguts com a Estat Mundial s’indexen per a una visualització als registres de transaccions que hi ha a l’arquitectura del canal. CouchDB actua com un procés de base de dades independent que rep actualitzacions de l’API del codi de xinc.

Comentari

Hyperledger Fabric ha creat un procés que substitueix els principis clau d’un sistema blockchain a canvi d’aconseguir transicions d’estat d’alt rendiment. L’ús de l’arquitectura actual permet modificar i manifestar més fàcilment els estats dins d’un esquema de programari tradicional, donant lloc a accés de lectura / escriptura. Tot i que l’ordenació de l’estat dins de l’entorn Fabric és eficaç, no té la capacitat d’instanciar el valor en un ecosistema públic descentralitzat, de la mateixa manera que seria capaç de fer una autèntica cadena de blocs com Ethereum o Bitcoin. El moviment de dades a l’entorn de programari de Fabric és indicatiu del que és capaç d’una base de dades distribuïda. La creació d’actius digitals dins de Fabric seria essencialment informació digital emmagatzemada en una base de dades controlada per les parts o grups controladors d’un consorci sense adherir-se a l’estructura econòmica dels béns digitals..

R3 Corda

A R3 Corda, State es basa en la seqüenciació i la versió de diferents conjunts de dades dins de l’arquitectura de la plataforma. Al sistema, la xarxa manté una caixa forta, que és una base de dades que emmagatzema els estats històrics que es fan un seguiment del sistema. A Corda, es considera que l’estat inclou dades opaques que són comparables a un fitxer de disc que no necessàriament s’actualitza, tot i que s’utilitzen per generar nous successors. Aquest sistema actua com una sèrie d’actualitzacions d’estat modificades i ressorgides dins d’un entorn controlat i compartit pels usuaris.

El llibre major es considera el conjunt de tots els estats actuals que s’activen. Tot i això, el préstec del model UTXO de Bitcoin no implementa el mateix estat de preservació de les característiques dels arbres de Patricia Merkle que existeixen a la tecnologia blockchain, tot i que utilitza una part de la tecnologia en subseccions de la plataforma en lloc del nucli. Tot i que els estats actuen com a instàncies de classes emmagatzemades al magatzem, la seqüenciació i la versió de les dades proporcionen un mitjà viable per emmagatzemar les dades.

A Corda, els estats es consideren classes que emmagatzemen dades. Les classes són implementacions de la interfície “ContractState” que actua com a capa d’interoperabilitat dins de la plataforma. Els camps de dades determinats “Estat” poden incloure:

• Emissió
• Propietari
• Valor facial i quantitat>
• data de maduresa

El format d’aquest disseny era permetre l’adjunt de dades en una cadena d’esdeveniments que permetés rastrejar la procedència d’on provenen les dades en un entorn controlat. La procedència està controlada pels membres del consorci que tenen determinats controls d’accés a la plataforma de programari. Mitjançant aquesta configuració, els bancs i les institucions financeres podran maximitzar l’eficiència en termes de processament d’informació en un ecosistema de llibres compartits. Les dades es poden moure i processar millor entre organitzacions, tot reduint la necessitat de confiança substancial entre contraparts no fiables.

Comentari

Aquesta configuració arquitectònica també pot processar dades compartides en un entorn semi-fiable en què les contraparts no necessiten confiar plenament les unes en les altres. Les dades es poden processar i afegir amb èxit al que Corda considera estat, tot i que la plataforma no té els components d’un sistema blockchain que pugui revelar un valor inequívoc. A Corda, l’estat no és una construcció lògica, tot i que es tracta d’informacions que s’afegeixen a un llibre de registre semblant a una base de dades. Tot i que els actius es poden digitalitzar i emmagatzemar dins del format d’estat gastat i no gastat, els actius no podran ser unitats de valor diferents, semblants a com Bitcoin, Ethereum i l’economia simbòlica creen nous mercats, tot i que el programari bancari podria ser una bona confiança configuració que pot ajudar a actuar com a centre d’atestació per obtenir informació no pública segura, de manera similar a com funciona actualment el sistema bancari.

II. Transaccions

Ethereum és un ecosistema de màquines basat en transaccions on l’estat global de les transaccions s’emmagatzema dins dels blocs. Quan es produeixen transaccions, les transicions d’estat resulten en nous estats del sistema. Aquest procés sacrifica la rapidesa del processament ràpid de transaccions de bases de dades per la integritat d’un sistema que emblematitza l’estat, així com la transacció que va conduir a aquest estat dins de la configuració de l’estructura de dades de l’arbre Patricia Merkle blockchain.

Dins d’aquesta arquitectura, l’estat juntament amb les transaccions que condueixen a transicions d’estat es conserven en un paradigma de programari que utilitza Patricia Merkle Trees per bloquejar les dades en una realitat històrica que es realitza dins dels blocs..

Hi ha dos tipus de transaccions:

• Missatges de trucades
• Creacions de contractes.

Les transaccions inclouen un mecanisme intern de transferència de valor. La transferència de valor dins de comptes contractuals comporta canvis d’estat. Com que el sistema es basa en la transferència de valor entre contractes intel·ligents que existeixen entre esdeveniments d’execució de transaccions, es poden utilitzar els diversos estats compartimentats per instanciar lògica i acords comercials d’alta fidelitat.

Comentari

La característica distintiva clau d’Ethereum és que les transaccions s’utilitzen com a unitats de procés individuals dins de l’entorn de la cadena de blocs d’Ethereum i, mitjançant aquesta configuració, mantenen un registre permanent dels estats transaccionals del sistema. Ethereum és capaç tant de les capacitats tecnològiques relacionades amb la base de dades de llibres distribuïts tradicionals com de combinar la confiança desitjada amb el valor digital. Les tecnologies derivades de la cadena de blocs d’Ethereum poden agrupar transaccions i lògica comercial en blocs d’una cadena de blocs. Les funcions empresarials derivades d’aquesta configuració inclouen:

• Autèntica economia digital
• Béns i actius digitals controlats per incentius econòmics enfront dels incentius organitzatius / monopolístics
• Interfície d’interacció entre institucions privades i l’economia digital pública

L’arquitectura d’Ethereum permet que les plataformes afiliades puguin instanciar capes d’incentius criptoeconòmics al sistema. Això significa que es poden crear diverses capes d’incentius i dissenys de mecanismes per assegurar la xarxa general, en comparació amb la dependència de serveis controlats centralment proporcionats pels dissenys de programari tradicionals. Aquesta capa d’incentius criptoeconòmics es pot aplicar tant a l’economia dels béns digitals com a la capa d’interfície entre versions privades i públiques d’una plataforma blockchain..

Teixit Hyperledger

Totes les transaccions s’executen dins de l’arquitectura multicanal de Fabric per garantir un alt rendiment de transaccions a l’entorn de confiança. Les transaccions s’afegeixen a un llibre major compartit que existeix a l’entorn d’execució. Amb aquesta arquitectura, Fabric permet l’accés de lectura / escriptura i la facilitat al seu entorn de programari, permetent una funcionalitat i usabilitat semblants al mainframe. Se sap que les bases de dades SQL són diversos ordres de magnitud més eficaces que qualsevol cadena de blocs que hi ha actualment disponible, i la configuració de Fabric pren molt dels paradigmes utilitzats en les eines de base de dades tradicionals que permeten un rendiment de transacció superior..

Hi ha dos tipus de transaccions:

• Desplegar transaccions: creeu un codi de cadena nou. S’instal·la un codi de connexió a l’entorn de desenvolupament de programari
• Invoca transaccions: invoca el codi de cadena creat prèviament i les funcions corresponents. Quan s’executa correctament, el codi de cadena compleix una funció i introdueix canvis a l’estat
• Les funcions d’invocació generen transaccions “obtenir” o “establir”

Per tal de maximitzar el processament de dades eficient i velocitats superiors, les transaccions individuals AKA blobs són distribuïdes per un servei de comandes Apache Kafka i es publiquen com a “blocs” mitjançant un esdeveniment de lliurament. Les transaccions (blobs) estan ordenades pel Servei de Comandes d’Apache Kafka i s’afegeixen a les particions de Kafka. El que això significa és que l’arquitectura Fabric sacrifica la integritat i la fidelitat de dades d’un veritable sistema de cadena de blocs per tal d’obtenir un processament i un rendiment de transaccions més ràpids dins d’un entorn de transmissió de dades de confiança, tal com es desprèn de l’ús del servei de comandes d’Apache Kafka..

Com es pot avaluar a partir de la documentació de Fabric, les transaccions ordenades s’afegeixen directament a les particions afiliades als temes de Kafka. Això dóna lloc a transaccions d’alt rendiment que es produeixen en un entorn de transmissió de dades de confiança. (Font: Apache Kafka)

Comentari

Tot i que el sistema utilitza terminologia blockchain-esque, no es tracta d’una cadena de blocs en el sentit tradicional, ja que no hi ha preservació de transaccions estatals i complementàries en una estructura de dades de Patricia Merkle Tree. Hyperledger Fabric és un DLT, no una cadena de blocs. L’arquitectura de Fabric es va dissenyar per a un processament de transaccions superior, tal com es pot veure a partir de l’adhesió de blobs de dades al servei de comandes de transmissió de dades de Kafka. Com que això s’aconsegueix en un entorn de confiança, les execucions es poden produir lliurement al sistema. L’ús d’aquesta configuració en un sistema de transferència de valor no seria l’ideal, tenint en compte que tota confiança s’hauria d’atribuir directament a una arquitectura de programari d’una única entitat en lloc d’un ecosistema o protocol compartit. Com es pot veure als documents tècnics, Fabric ha renunciat arquitectònicament a la integritat i seguretat de les dades assolides a les plataformes blockchain per obtenir un processament superior entre els components de la transacció.

R3 Corda

A R3 Corda, les transaccions es consideren propostes per actualitzar la base de dades Vault, que es pot anomenar llibre major. Les transaccions s’han d’executar en un entorn on els notaris puguin validar que no es gasten el doble i que estan signades per les parts necessàries. Això és similar al concepte utilitzat a l’ecosistema bitcoin, tot i que un sistema de confiança facilita l’evitació de la doble despesa.

Hi ha dos tipus bàsics de transaccions:

• Transaccions de canvi notarial: s’executen per circular pels notaris del sistema. Els notaris evitaran la doble despesa i podran validar les transaccions
• Proporcionar consens sobre la singularitat
• Transaccions generals: s’utilitzen per a tota la resta

Les transaccions són actualitzacions proposades a l’estat de l’entorn de la base de dades que requereixen la validació de signatures d’altres parts del sistema. Perquè una transacció sigui vàlida, ha de:

1. Estar signat per les parts implicades
2. Obteniu la validació del codi de contracte que determina la transacció

L’ús del model similar a UTXO en un entorn de base de dades compartida permet a la plataforma Corda controlar l’estat i les transicions. L’ús del notari i diverses interaccions entre fluxos i cordapps a la configuració de xarxa mostren un entorn distribuït compartit on es conserva l’estat en un format de dades integral de l’arquitectura del sistema. L’ús de transaccions per navegar per la instanciació d’estats dins de l’entorn basat en nodes entre fluxos i els Cordapps que es programen en nodes, indiquen un mitjà viable per executar canvis d’estat en un llibre major.

Comentari

Per a la formació d’actius digitals, els usuaris i les contraparts depenen de la confiança de la plataforma Corda en general. Tot i que actua com un fort sistema de registre distribuït compartit de confiança per mantenir dades financeres sensibles, el sistema actua d’acord amb diversos estàndards que existeixen a l’ecosistema bancari. La plataforma proporciona:

• Emmagatzematge superior de dades financeres no públiques
• Configuració de confiança per a institucions financeres que no confien
• Volter avançat d’interaccions comercials

Els diagrames arquitectònics que impliquen fluxos i entorns d’execució entre nodes mostren que Corda va ser dissenyat per particionar l’accés entre els membres de confiança de la seva plataforma de consorci. Tot i que és capaç de tenir certs aspectes d’usabilitat, R3 Corda no té funcionalitats inherents a ser un substrat universal per a la transferència de valor econòmic, social i polític, a causa de la manca d’una capa d’incentius criptoeconòmics i d’un entorn d’actius digitals públics. Com que el sistema està tancat, no té els rails i els trets tecnològics necessaris per construir un ecosistema impulsat per incentius econòmics. És probable que R3 Corda s’utilitzi millor per a certes facetes de la infraestructura bancària tradicional, tot i que no per a la creació d’actius digitals.

III. Contractes intel·ligents

Ethereum

A Ethereum, els contractes intel·ligents s’escriuen en llenguatges de programació d’alt nivell com solidity, LLL o Viper i es compilen en bytecode EVM, cosa que permet executar binaris mitjançant la màquina virtual Ethereum (EVM). Els nodes de la xarxa Ethereum executen la seva pròpia implementació EVM que actua com a entorn d’execució dels contractes intel·ligents a l’ecosistema Ethereum. L’estat i les transaccions que condueixen a transicions estatals s’emblemen a l’estat mundial de la cadena de blocs d’Ethereum mitjançant la replicació per EVM, donant lloc a un sistema que pot implementar una confiança insubornable en una sèrie d’espectres..

L’EVM actua com un entorn d’execució per executar recursivament transicions d’estat per tal de calcular l’estat del sistema i l’estat de la màquina a mesura que passa per les transaccions.

• Estat del sistema = Estat global d’Ethereum
• Estat de la màquina = lògica comercial dels comptes contractuals & codi replicat en temps d’execució EVM

Com que tots els nodes de l’EVM repliquen tots els codis de contractes intel·ligents, la cadena de blocs d’Ethereum i les instàncies relacionades poden preservar la validesa del codi per garantir la coherència dels contractes. La coherència dels contractes contribueix a la immutabilitat pràctica de la cadena de blocs Ethereum i dels seus clients i implementacions afiliats. Els contractes intel·ligents d’Ethereum uneixen tot l’ecosistema mitjançant la creació d’instàncies de transaccions que acaben donant lloc a transicions a nous estats dins l’entorn de màquines virtuals.

Comentari

Com que les implementacions de l’EVM s’adhereixen estrictament a les especificacions designades al llibre groc d’Ethereum, les diferents instàncies d’Ethereum (públiques, privades i consorciats) són capaces d’interoperabilitat segons es determina a partir de la recopilació comuna de llenguatges d’alt nivell, en forma de contractes – en codi bytec d’Ethereum per EVM. A partir d’aquesta disposició d’Ethereum, és capaç d’actuar com a capa intermediària entre diverses facetes de grans instal·lacions de dades privades institucionals i l’economia pública de béns digitals que actualment està evolucionant i que es porta a bon port a partir de la recent creació de l’economia simbòlica..

En permetre aquesta funcionalitat entre les cadenes d’Ethereum, es poden construir sistemes interoperables sencers que assignin la finalitat econòmica entre els sistemes de coordinació i processament de dades en plataformes privades d’Ethereum als productes digitals de la cadena pública. Els contractes intel·ligents sobre Ethereum incapsulen la lògica programable dins d’aquests sistemes i permeten als desenvolupadors interactuar amb la màquina virtual Ethereum mitjançant transaccions que creen nous entorns d’estat dins de la infraestructura tecnològica. A mesura que es desenvolupin casos d’ús complets dins dels entorns de cadena pública, privada i de cadena de consorci interoperables, els contractes intel·ligents utilitzats a Ethereum podran unir els sistemes sota una interfície lògica comuna..

Teixit Hyperledger

Chaincode no és necessàriament un contracte intel·ligent desplegat en una cadena de blocs basada en comptes, sinó un programa que s’instal·la i que posteriorment implementa una interfície a través d’una API. La interfície API requereix les instruccions basades en codi per dirigir la lògica i la funcionalitat empresarials a tot el sistema, de manera similar a l’entorn de desenvolupament de programari tradicional. Els mètodes afiliats a l’API inclouen:

• Iniciació: iniciació dels estats de l’aplicació
• Invocar – processar propostes de transaccions

Chaincode ha d’implementar interfícies des de l’API:

• Interfície de codi de xat
• ChaincodeStubInterface

A Hyperledger Fabric, el codi de cadena s’executa en contenidors Docker segurs, on s’aïlla dels processos executats pel par d’adhesió. Normalment, el codi s’escriu a Go o Node.js, cosa que permet una interacció que gestiona la lògica empresarial. Un matís a tenir en compte és que el codi de cadena Fabric no és reproduït pels nodes de l’ecosistema de la mateixa manera que s’espera d’una autèntica arquitectura blockchain..

Chaincode s’instal·la inicialment a Peers i després s’instancia en canals. El flux del procés es detalla als diagrames següents:

Al llarg del flux del procés Chaincode, es produeixen diverses interaccions amb System Chaincode, que s’executa dins d’un procés parell executable enfront d’un contenidor aïllat. S’utilitza per implementar comportaments del sistema sense polítiques d’aprovació ni processos de cicle de vida. System Chaincode no passa pel cicle de vida del codi de Chaincode normal. S’implementen dues funcions de l’API Shim de la interfície de codi de xinc. El codi el compila i manté el parell. Chaincode no està afiliat als canals ni als encarregats fins que el desenvolupador determina que vol instal·lar encara més el programa.

El codi de cadena es pot configurar per crear actius que finalment actuïn com a parells clau-valor que s’emmagatzemen a la base de dades de llibres majors. El flux de treball d’enviament d’ordres d’inici i d’invocació de transaccions es detalla al diagrama anterior en termes de com es mouen les ordres a través del sistema. La lògica empresarial es codifica dins de les regles de la xarxa i s’invoca a través d’aplicacions del costat del client. El tipus de coordinació i interacció de codi és molt indicatiu del desenvolupament de programari tradicional a través de les dependències de funcions tradicionals i interfícies d’iniciació.

Comentari

El moviment de Chaincode a través d’aquesta configuració de xarxa permet una organització racional del sistema. L’arquitectura del programari està preparada per actuar com una estructura de comandament i control molt eficient en termes de distribució de dades i organització de l’entorn de desenvolupament de programari per a determinats casos d’ús empresarials. Com es pot distingir del paquet, la instal·lació, la creació d’instàncies i l’actualització de la configuració, aquesta arquitectura es va dissenyar per optimitzar els punts de contacte necessaris per processar el codi. Les interfícies API necessàries a mesura que es processen les transaccions recorden molt el disseny de programari tradicional. Àrees de nota:

• Arquitectura monolítica per al màxim control
• Interacció comercial segura entre contraparts
• Processament coordinat de manera centralitzada per al rendiment de transaccions

Chaincode és més un sistema d’ordres que no pas un llenguatge de contractes intel·ligent que es reprodueix mitjançant una cadena de blocs. Com que l’ecosistema Hyperledger Fabric té un conjunt vibrant de característiques fortes en termes de funcionalitat i disseny com a llibre major distribuït, el sistema de fet no té les qualitats inherents a un autèntic sistema blockchain. Com a eina que es pot utilitzar per integrar-se amb infraestructures i paradigmes heretats, Fabric és eficaç a causa de la seva adhesió als estàndards de programari preexistents, tal com es pot deduir del disseny arquitectònic descrit anteriorment..

Quan Fabric guanya en funcionalitat pel que fa al seu sistema, que és una mica emblemàtic dels sistemes dissenyats al voltant de grans mainframes i centres de dades, perd en altres aspectes en termes de connexió distribuïda a factors econòmics de càlcul, com es pot accedir en una economia de token digital intrínsecament descentralitzada . Si Fabric s’integrés en un veritable entorn de cadena de blocs, encaixaria bé com un entorn de base de dades distribuïda i segur que validés la informació abans de la interacció amb un ecosistema públic de cadena de blocs..

R3 Corda

A Corda, els contractes intel·ligents es consideren classes que implementen la interfície Contract. Els contractes intel·ligents s’escriuen en Java / Kotlin i es compilen a través de la màquina virtual de Java (JVM), que és la màquina informàtica en què s’executa el codi. La funció principal que s’utilitza als contractes és la funció “verificar”.

El codi s’executa a la JVM on les transaccions es processen mitjançant el sistema de notarització i la lògica empresarial està restringida als fluxos que poden allotjar i aïllar el procés de negoci entre diferents contraparts..

Components de contractes intel·ligents:

• Codi executable
• Valida els canvis en les transaccions
• Objectes d’estat
• Dades conservades al llibre major
• Estat actual d’un contracte
• Utilitza entrades i sortides de transaccions
• Ordres
• Dades addicionals
• S’utilitza per instruir el codi de contracte executable

El codi Java i Kotlin es compila en un bytecode idèntic mitjançant la JVM. Els comandaments transmeten al codi de contracte dades addicionals que no existeixen a l’estat. Els comandaments actuen com a estructures de dades amb claus públiques adjuntes que s’utilitzen per signar transaccions, tot i que s’ha de reconèixer que els contractes no funcionen directament amb les signatures digitals. Els contractes dins d’aquest entorn es repliquen a tot el sistema en el context de com els fluxos estan disposats a coordinar-se entre parts de confiança.

Comentari

El codi de contracte s’adapta a les necessitats de casos d’ús dins de l’entorn Corda i és capaç de complir les funcions necessàries de rendiment de transaccions. Les limitacions inclouen la interoperabilitat amb altres ecosistemes. Per tal que els sistemes puguin interoperar amb Corda, haurien d’utilitzar el marc de codi de contractes Corda dissenyat al voltant del DLT tancat. A diferència d’una plataforma de blockchain autèntica com Ethereum, que pot actuar com a capa d’interoperabilitat entre processos econòmics i funcions entre instantànies privades i instantànies públiques, Corda es limita a estar més centrat en els processos d’un sistema tancat. L’ús de la JVM és innovador, tot i que la instància està aïllada dins de l’ecosistema Corda. En aquest escenari, Corda guanya el processament de transaccions en un entorn segur alhora que sacrifica la capacitat d’interoperar i coordinar-se entre diferents entorns de cadenes de blocs, com un sistema interoperable..

IV. Conclusió i avaluació

Basant-nos en la nostra anàlisi, els principals factors distintius que Ethereum és capaç d’implementar més enllà del que és capaç de DLT són:

• Actiu digital o economia simbòlica
• Capes d’incentius criptoeconòmics del protocol
• Interoperabilitat entre consorci i cadenes de blocs públiques

Tot i que els DLT com R3 Corda i Hyperledger Fabric són capaços d’aconseguir funcionalitats en la gestió de bases de dades compartides i en el cicle de vida del processament de transaccions, no es garanteix que puguin assolir les funcionalitats clau tal com es descriu anteriorment. Aquestes plataformes no són defectuoses, sinó més aviat limitades en la seva configuració arquitectònica per exhibir alguns dels casos d’ús purs que només les autèntiques cadenes de blocs poden afirmar.

Les tecnologies Blockchain estan dissenyades per combinar la confiança creada al seu interior i el valor tangible que es crea a partir d’aquesta confiança. Només a través d’una autèntica plataforma construïda a partir dels fonaments bàsics d’una cadena de blocs, els sistemes socials, polítics i econòmics podran ser consagrats fonamentalment dins de la infraestructura d’un protocol de programari. Tot i que les plataformes de gestió de bases de dades centrades en DLT es poden integrar i interoperar amb una plataforma blockchain, els rails sobre els quals es basaran les transferències de valor i la coordinació d’aquesta confiança han de ser una blockchain que incorpori els principis bàsics de confiança, immutabilitat, integritat i fidelitat a la informació..

El que revela aquesta anàlisi no és que certs sistemes siguin millors que altres, sinó que són útils en diferents capacitats. La capacitat de les plataformes DLT d’actuar com a bases de dades distribuïdes privades amb un alt rendiment i funcionalitat de transaccions, els permeten actuar com a sistemes fiables que poden interoperar dins d’una plataforma blockchain quan són necessàries certes facetes de la informació privada per a l’avaluació, com ara dades bancàries / financeres o informació sensible relacionada amb el funcionament intern d’una institució privada que no s’hauria de revelar al públic. Els diversos models de negoci sobre com utilitzar aquestes fonts de dades privades afiliades a DLT encara estan en desenvolupament i haurien de ser iterats tenint en compte les interfícies blockchain, ja que és necessari un sistema de valor digital descentralitzat per a algunes de les interaccions entre blockchains i DLT..

Connecteu-vos amb els nostres experts en blockchain

El nostre equip global de solucions ofereix formació en blockchain, assessorament estratègic, serveis d’implementació i oportunitats d’associació. Contacteu amb nosaltres Butlletí de notícies Subscriviu-vos al nostre butlletí per obtenir les últimes novetats, solucions empresarials, recursos per a desenvolupadors i molt més sobre Ethereum.Guia

Guia completa de xarxes empresarials Blockchain

Seminari web

Introducció a la tokenització

Seminari web

El futur de les finances: actius digitals i DeFi

Seminari web

Què és Enterprise Ethereum?

Paper blanc

Els bancs centrals i el futur dels diners

Cas pràctic

Komgo: Blockchain per al comerç de mercaderies