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

blog 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressboletins informativos

Assine a nossa newsletter.

Endereço de email

Nós respeitamos sua privacidade

HomeBlog Enterprise Blockchain

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

Uma análise comparativa das arquiteturas e da dinâmica governante de Ethereum, Hyperledger Fabric e R3 Corda.by ConsenSys 23 de maio de 2018Postado em 23 de maio de 2018

blockchain dlt 2 hero

Esta é a Parte 2 de uma análise comparativa de duas partes de Ethereum, Hyperledger Fabric e R3 Corda. Leia a Parte 1 do Blockchain vs. DLTs. 

Plataformas de tecnologia Blockchain vs. Distributed Ledger

Deve-se reconhecer que, se a coordenação do banco de dados e a alocação mais eficiente de código for a funcionalidade desejada de um sistema, o blockchain pode não ser necessariamente a solução que uma organização está procurando. Sistemas de tecnologia de razão distribuída (DLT) como Hyperledger Fabric ou R3 Corda são capazes de funcionalidades semelhantes aos sistemas de blockchain, mas deve ser levado em consideração que blockchains são um subconjunto separado de livros-razão distribuídos que têm funcionalidade adicional além da coordenação de código. Blockchains são capazes de funções que os livros-razão distribuídos não são em termos de instanciação de valor digital com base na composição do sistema.

Neste documento, serão exploradas as considerações arquitetônicas que identificam os aspectos que contribuem para a funcionalidade do blockchain. Um exame seria que talvez haja uma compensação entre o que os blockchains são capazes de realizar e o que os DLTs fornecem. O DLT foi criado para o processamento de transações em um ambiente confiável compartilhado, enquanto os blockchains verdadeiros foram projetados para sacrificar a necessidade de uma configuração confiável para obter alta fidelidade e imutabilidade das contas. Aspectos de alta fidelidade e imutabilidade são essenciais para o sucesso da digitalização adequada dos ativos. A análise deste documento irá sobrepor componentes arquitetônicos em processos de negócios para elucidar ainda mais essas nuances tecnológicas em plataformas.

Figura 1 É importante fazer distinções entre as pilhas de tecnologia e como elas se comparam em termos de funcionalidade e casos de uso. Embora a tecnologia de razão distribuída tenha sido fortemente influenciada pela tecnologia blockchain, devemos distinguir as considerações arquitetônicas das plataformas de tecnologiaÉ importante fazer distinções entre as pilhas de tecnologia e como elas se comparam em termos de funcionalidade e casos de uso. Embora a tecnologia de razão distribuída tenha sido fortemente influenciada pela tecnologia blockchain, devemos distinguir as considerações arquitetônicas das plataformas de tecnologia.

As comparações serão feitas com base em vários recursos distintivos importantes que existem nas plataformas de software. As principais áreas que serão exploradas neste documento incluem:

  • Estado: O estado refere-se à unidade principal de lógica na qual o código pode ser composto para facilitar a representação de informações em um ambiente de computação. Embora o estado possa ter vários significados em diferentes contextos, o uso do estado dentro do blockchain e do ambiente de razão distribuído consiste na configuração atual de uma característica ontológica da estrutura de dados.
  • Transações: Dentro de um ambiente de blockchain, as transações são consideradas os eventos computacionais que podem levar à geração de estado ou transições de estado que ocorrem dentro do ecossistema de desenvolvimento. As transações podem iniciar contratos ou solicitar contratos pré-existentes.
  • Contratos Inteligentes: Ao avaliar uma plataforma de blockchain de uma perspectiva arquitetônica, é importante determinar a estrutura do código de contrato inteligente e como ele funciona em relação à topologia de rede de blockchain real. Contratos inteligentes são considerados as unidades individuais de código que executam ações dentro do ecossistema da plataforma.

A tabela a seguir mostra uma breve visão geral das principais diferenças entre os diversos recursos tecnológicos das respectivas plataformas.

recursos da plataformaUma visão geral dos recursos tecnológicos de Ethereum, Hyperledger Fabric e R3 Corda.

Eu Estado

Ethereum

Como um ecossistema com configurações distribuídas compartilhadas, Ethereum instancia o conceito de “Estado” por meio de uma configuração de objetos chamados “Contas”. Existem dois tipos de contas no Ethereum:

  • Contas de contrato – contas controladas por código de contrato
  • Contas de propriedade externa – contas controladas por uma chave privada

Ethereum usa o conceito de Estado Mundial, que é um mapeamento de endereços de contas e estados de contas. O State_Root é uma raiz da árvore de Patricia Merkle do amálgama de contas no sistema. E dentro das contas, os estados do contrato também são organizados nesta estrutura de dados da Árvore de Patricia Merkle. O hash raiz do estado pode ser usado para proteger a identidade dos dados na árvore merkle, permitindo a replicação em toda a rede, o que acaba resultando na imutabilidade teórica do sistema.

Os blockchains verdadeiros são diferenciados do DLT com base em sua confiança na estrutura de dados da árvore de Patricia Merkle e na orquestração entre os blocos que são usados ​​para instanciar o estado do sistema. Este conceito é parte integrante da validade de integridade de dados e fidelidade de uma arquitetura de sistema de blockchainOs blockchains verdadeiros são diferenciados do DLT com base em sua confiança na estrutura de dados da árvore de Patricia Merkle e na orquestração entre os blocos, que é usada para instanciar o estado do sistema. Este conceito é parte integrante da integridade, validade e fidelidade dos dados de uma arquitetura de sistema blockchain.

Comentário

A funcionalidade que o Ethereum World State cria é um sistema confiável que permite a instanciação do valor em formato digital. Fontes de valor representacional digital que são nativas para a economia de token podem ser derivadas da composição de contas e estruturas de sub-dados do Ethereum; da mesma forma que as portas lógicas são capazes de instanciar algoritmos funcionais na engenharia tradicional.

Plataformas derivadas de Ethereum, incluindo clientes Ethereum e implementações privadas, podem se beneficiar dessa instanciação de valor por convicções a esses padrões em relação à preservação do estado e implementação lógica. As plataformas que falham em instanciar uma dessas funcionalidades baseadas em valor lógico não serão capazes de facilitar a criação de verdadeiros valores de ativos digitais descentralizados.

Tecido Hyperledger

No Hyperledger Fabric, o estado é preservado em uma estrutura de banco de dados com base em armazenamentos de chave / valor para o estado. A interação entre os programas Chaincode e como eles são instalados na topologia da plataforma permite que comandos e ações sejam emitidos no sistema. Essas ações resultam em atualizações dos armazenamentos de dados, pois as transações resultam em atualizações do estado conhecido como razão. O razão é formulado como um banco de dados distribuído compartilhado que fornece aos usuários acesso superior a informações e transações que ocorrem dentro do ambiente de computação distribuída. O estado é aninhado no ambiente de banco de dados por meio de ferramentas tradicionais de desenvolvimento de software:

  • LevelDB cria um banco de dados de chave / valor
  • CouchDB manteria o banco de dados JSON de documento

arquitetura de tecidoNa arquitetura do Fabric, o formato do banco de dados de como todos os processos são organizados é capaz de aumentar o processamento de transações e maximizar a eficiência computacional no ecossistema.

No Banco de Dados de Estado, os valores de versão mais recentes para chaves no log de transações em cadeia são armazenados como pares de chave / valor. Os valores-chave conhecidos como o estado mundial são indexados para uma visualização nos logs de transações que existem na arquitetura do canal. CouchDB atua como um processo de banco de dados separado que recebe atualizações da API chaincode.

Comentário

O Hyperledger Fabric criou um processo que substitui os princípios-chave de um sistema blockchain em troca de alcançar transições de estado de alto rendimento. O uso da arquitetura atual permite que os estados sejam mais facilmente modificados e manifestados dentro de um esquema de software tradicional, resultando em acesso de leitura / gravação. Embora o arranjo de estado dentro do ambiente Fabric seja eficiente, ele não tem a capacidade de instanciar valor em um ecossistema público descentralizado, da mesma forma que um blockchain verdadeiro como Ethereum ou Bitcoin seria capaz de fazer. A movimentação de dados no ambiente de software do Fabric é um indicativo do que um banco de dados distribuído é capaz. A criação de ativos digitais dentro da Fabric seria essencialmente informação digital armazenada em um banco de dados que é controlado pelas partes controladoras ou grupos dentro de um consórcio, sem aderência à estrutura econômica dos bens digitais.

R3 Corda

No R3 Corda, o estado é baseado no sequenciamento e no controle de versão de diferentes conjuntos de dados dentro da arquitetura da plataforma. No sistema, a Rede mantém um Cofre, que é um banco de dados que armazena os estados históricos que são rastreados dentro do sistema. No Corda, o estado é considerado como incluindo dados opacos que são comparáveis ​​a um arquivo de disco que não é necessariamente atualizado, embora seja usado para gerar novos sucessores. Este sistema atua como uma série de atualizações de estado modificadas e reaparecidas dentro de um ambiente controlado e compartilhado pelos usuários.

Figura 5 O razão é considerado como o conjunto de todos os estados atuais que são ativados. Isso toma emprestado do modelo UTXO bitcoin, embora não implemente as mesmas características de preservação de estado das Árvores de Patricia Merkle que existem na tecnologia de blockchain, embora use alguma da tecnologia em subseções da plataforma em oposição ao núcleo Enquanto os estados atuam como instâncias de classes armazenadas no cofre, o sequenciamento e a versão dos dados fornecem um meio viável de armazenar os dadosO razão é considerado como o conjunto de todos os estados atuais que estão ativados. Isso se baseia no modelo UTXO de bitcoin, embora não implemente as mesmas características de preservação de estado das Árvores Patricia Merkle que existem na tecnologia de blockchain, embora use parte da tecnologia nas subseções da plataforma em oposição ao núcleo. Enquanto os estados atuam como instâncias de classes armazenadas no vault, o sequenciamento e a versão dos dados fornecem um meio viável de armazenar os dados.

No Corda, os estados são considerados classes que armazenam dados. As classes são implementações da interface “ContractState” que atua como a camada de interoperabilidade dentro da plataforma. Os certos campos de dados de “Estado” podem incluir:

  • Emissão
  • Proprietário
  • faceValue and Amount>
  • maturityDate

O formato deste projeto foi permitir a anexação de dados em uma cadeia de eventos, permitindo a capacidade de rastrear a proveniência de onde os dados vêm no ambiente controlado. A proveniência é controlada pelos membros do consórcio que possuem determinados controles de acesso à plataforma de software. Usando essa configuração, bancos e instituições financeiras serão capazes de maximizar a eficiência em termos de processamento de informações em um ecossistema de razão compartilhada. Os dados podem ser melhor movidos e processados ​​entre organizações, reduzindo a necessidade de confiança substancial entre contrapartes não confiáveis.

Comentário

Essa configuração arquitetônica é capaz de processar dados compartilhados em um ambiente semiconfiável, onde as contrapartes não precisam confiar totalmente umas nas outras. Os dados podem ser processados ​​com sucesso e anexados no que Corda considera estado, embora a plataforma não tenha os componentes de um sistema de blockchain que pode revelar um valor inequívoco. No Corda, o estado não é uma construção lógica, mas sim pedaços de informação anexados a um livro-razão semelhante a um banco de dados. Embora os ativos possam ser digitalizados e armazenados no formato de estado gasto e não gasto, os ativos não serão capazes de ser unidades distintas de valor semelhantes a como Bitcoin, Ethereum e a economia de token criam novos mercados, embora o software bancário possa ser um bom confiável configuração que pode ajudar a atuar como um centro de atestado para informações não públicas seguras, semelhante a como o sistema bancário funciona atualmente.

II. Transações

Ethereum é um ecossistema de máquina baseado em transações, onde o estado global das transações é armazenado dentro dos blocos. Quando ocorrem transações, as transições de estado resultam em novos estados do sistema. Este processo sacrifica a velocidade do processamento rápido da transação do banco de dados pela integridade de um sistema que simboliza o estado, bem como a transação que levou a esse estado dentro da configuração da estrutura de dados do blockchain Patricia Merkle Tree.

Figura 6 Dentro desta arquitetura, o estado junto com as transações que levam às transições de estado são preservados em um paradigma de software que utiliza Patricia Merkle Trees para bloquear os dados em uma realidade histórica que é realizada dentro dos blocosDentro dessa arquitetura, o estado e as transações que levam às transições de estado são preservados em um paradigma de software que utiliza Árvores Patricia Merkle para bloquear dados em uma realidade histórica que é realizada dentro dos blocos.

Existem dois tipos de transações:

  • Chamadas de mensagem
  • Criações de contrato.

As transações incluem um mecanismo interno de transferência de valor. Transferência de valor dentro de contas de contrato resulta em mudanças de estado. Como o sistema é baseado na transferência de valor entre contratos inteligentes que existem entre eventos de execução de transações, os vários estados compartimentados podem ser usados ​​para instanciar acordos e lógicas de negócios de alta fidelidade.

Comentário

O principal recurso distintivo do Ethereum é que as transações são usadas como unidades individuais de processo dentro do ambiente de blockchain da Ethereum e, por meio dessa configuração, mantém um registro permanente dos estados transacionais dentro do sistema. Ethereum é capaz de recursos tecnológicos relacionados ao banco de dados de razão tradicional distribuído, bem como unir a confiança desejada com valor digital. As tecnologias derivadas do blockchain Ethereum são capazes de agrupar transações e lógica de negócios em blocos de um blockchain. A funcionalidade comercial derivada desta configuração inclui:

  • A verdadeira economia digital
  • Bens e ativos digitais controlados por incentivos econômicos em oposição a incentivos organizacionais / monopolistas
  • Interface de interação entre instituições privadas e a economia digital pública

A arquitetura do Ethereum permite que as plataformas afiliadas sejam capazes de instanciar camadas de incentivos criptoeconômicos no sistema. Isso significa que várias camadas de incentivo e designs de mecanismo podem ser criados para proteger a rede geral, em vez de depender de serviços controlados centralmente fornecidos por designs de software tradicionais. Esta camada de incentivo criptoeconômico pode ser aplicada tanto à economia de bens digitais quanto à camada de interface entre as versões privada e pública de uma plataforma de blockchain.

Tecido Hyperledger

Todas as transações são executadas dentro da arquitetura multicanal do Fabric para garantir um alto rendimento da transação no ambiente confiável. As transações são anexadas a um razão compartilhado que existe no ambiente de tempo de execução. Com essa arquitetura, o Fabric permite acesso de leitura / gravação e facilidade para seu ambiente de software, permitindo funcionalidade e usabilidade semelhantes a mainframe. Sabe-se que os bancos de dados SQL têm várias ordens de magnitude mais desempenho do que qualquer blockchain disponível atualmente, e a configuração do Fabric usa muitos paradigmas usados ​​em ferramentas de banco de dados tradicionais, permitindo o rendimento de transação superior.

Existem dois tipos de transações:

  • Implantar transações – criar um novo código de cadeia. Instala chaincode no ambiente de desenvolvimento de software
  • Invocar transações – invoca o chaincode criado anteriormente e as funções correspondentes. Quando isto é executado com sucesso, o chaincode cumpre uma função e introduz mudanças no estado
  • Funções de chamada resultam em transações ‘get’ ou ‘set’

Para maximizar o processamento de dados eficiente e velocidades superiores, as transações individuais, também conhecidas como blobs, são agrupadas por um serviço de pedidos Apache Kafka e enviadas como “blocos” por meio de um evento de entrega. As transações (blobs) são ordenadas pelo Apache Kafka Ordering Service e anexadas às partições Kafka. O que isso significa é que a arquitetura do Fabric sacrifica a integridade e fidelidade de dados de um verdadeiro sistema de blockchain para obter processamento de transação e taxa de transferência mais rápidos em um ambiente de streaming de dados confiável, conforme aparente com o uso do Serviço de Pedidos Apache Kafka.

Figura 7 Como pode ser avaliado na documentação do Fabric, as transações ordenadas são anexadas diretamente às partições afiliadas ao Kafka. Tópicos Isso resulta em transações de alto rendimento que ocorrem em um ambiente de streaming de dados confiável Fonte Apache KafkaComo pode ser avaliado na documentação do Fabric, as transações solicitadas são anexadas diretamente às Partições afiliadas aos Tópicos Kafka. Isso resulta em transações de alto rendimento que ocorrem em um ambiente de streaming de dados confiável. (Fonte: Apache Kafka)

Comentário

Embora o sistema utilize a terminologia do tipo blockchain, este não é um blockchain no sentido tradicional, pois não há preservação do estado e das transações complementares em uma estrutura de dados da árvore de Patricia Merkle. Hyperledger Fabric é um DLT, não um blockchain. A arquitetura do Fabric foi projetada para processamento de transações superior, como pode ser visto na adição de blobs de dados ao serviço de pedido de streaming de dados Kafka. Como isso é obtido em um ambiente confiável, as execuções podem ocorrer livremente no sistema. O uso desta configuração em um sistema de transferência de valor não seria ideal, considerando que toda a confiança precisaria ser atribuída diretamente a uma arquitetura de software de uma única entidade em oposição a um ecossistema ou protocolo compartilhado. Como pode ser visto nos documentos técnicos, o Fabric renunciou arquitetonicamente à integridade de dados e à segurança alcançada em plataformas de blockchain para obter processamento superior entre os componentes da transação.

R3 Corda

No R3 Corda, as transações são consideradas propostas para atualizar o banco de dados do Vault, que pode ser chamado de razão. As transações devem ser executadas em um ambiente onde os tabeliães possam validar que elas não são gastas em dobro e que são assinadas pelas partes necessárias. Isso é semelhante ao conceito usado no ecossistema bitcoin, embora a prevenção de gastos duplos seja facilitada por um sistema confiável.

Existem dois tipos básicos de transações:

  • Transações de mudança de tabelião – são executadas para percorrer os tabeliães no sistema. Os tabeliães evitarão gastos em dobro e podem validar transações
  • Forneça um consenso de exclusividade
  • Transações gerais – usadas para todo o resto

estado final

As transações são atualizações propostas para o estado do ambiente do banco de dados que requerem que as assinaturas sejam validadas de outras partes dentro do sistema. Para que uma transação seja válida, ela deve:

  1. Ser assinado pelas partes envolvidas
  2. Seja validado pelo código do contrato que determina a transação

arquitetura do cliente

O uso do modelo UTXO-like em um ambiente de banco de dados compartilhado permite que a plataforma Corda controle o estado, bem como as transições. O uso do Notário e várias interações entre Flows e Cordapps na configuração de rede mostram um ambiente distribuído compartilhado onde o estado é preservado em um formato de dados integral para a arquitetura do sistema. O uso de transações para navegar na instanciação de estados dentro do ambiente baseado em Nó entre Fluxos, bem como os Cordapps que são programados em nós, indicam um meio viável de executar mudanças de estado em um razão.

Comentário

Para a formação de ativos digitais, usuários e contrapartes depende da confiança de toda a plataforma Corda. Enquanto atua como um forte sistema de contabilidade compartilhado e confiável para manter dados financeiros confidenciais, o sistema atua de acordo com vários padrões existentes no ecossistema bancário. A plataforma oferece:

  • Armazenamento superior de dados financeiros não públicos
  • Configuração confiável para instituições financeiras não confiáveis
  • Segurança avançada de interações comerciais

Os diagramas de arquitetura envolvendo fluxos e ambientes de tempo de execução entre os nós mostram que o Corda foi projetado para particionar o acesso entre os membros confiáveis ​​de sua plataforma de consórcio. Embora capaz de certos aspectos de usabilidade, R3 Corda carece de funcionalidade inerente a ser um substrato universal para transferência de valor econômico, social e político, devido à falta de uma camada de incentivo criptoeconômico, bem como um ambiente de ativo digital público. Por ser fechado, o sistema carece dos trilhos e das características tecnológicas necessárias para a construção de um ecossistema impulsionado por incentivos econômicos. R3 Corda é provavelmente mais usado para certas facetas da infraestrutura bancária tradicional, embora não para a criação de ativos digitais.

III. Contratos Inteligentes

Ethereum

No Ethereum, os contratos inteligentes são escritos em linguagens de programação de alto nível como solidez, LLL ou Viper e compilados em bytecode EVM, permitindo que binários sejam executados pela Máquina Virtual Ethereum (EVM). Os nós na rede Ethereum executam sua própria implementação EVM, que atua como um ambiente de execução para contratos inteligentes no ecossistema Ethereum. O estado e as transações que levam a transições de estado são simbolizados no estado mundial da blockchain Ethereum por meio da replicação pelo EVM, resultando em um sistema que pode implementar confiança incorruptível em uma variedade de espectros.

EVM 1

O EVM atua como um ambiente de tempo de execução para executar transições de estado recursivamente, a fim de computar o estado do sistema e o estado da máquina à medida que faz um loop pelas transações.

  • Estado do sistema = estado global Ethereum
  • Estado da máquina = lógica de negócios das contas de contrato & código replicado em tempo de execução EVM

Como todo código de contrato inteligente é replicado por todos os nós no EVM, o blockchain Ethereum e instanciações relacionadas são capazes de preservar a validade do código para garantir a consistência dos contratos. A consistência dos contratos contribui para a imutabilidade prática do blockchain Ethereum e seus clientes afiliados e implementações. Contratos inteligentes no Ethereum unem todo o ecossistema por meio de transações de instanciação que eventualmente resultam em transições para novos estados dentro do ambiente geral da máquina virtual.

Comentário

Como as implementações do EVM seguem estritamente as especificações designadas no Livro Amarelo Ethereum, diferentes instanciações do Ethereum (pública, privada e consórcio) são capazes de interoperabilidade conforme determinado pela compilação comum de linguagens de alto nível – na forma de contratos – em bytecode Ethereum pelo EVM. A partir dessa disposição do Ethereum, ele é capaz de atuar como a camada intermediária entre várias facetas de grandes instalações de dados privados institucionais e a economia de bens digitais públicos que está atualmente evoluindo e se concretizando com a recente criação da economia simbólica.

Ao permitir essa funcionalidade entre as cadeias Ethereum, sistemas interoperáveis ​​inteiros podem ser construídos para alocar finalidade econômica entre os sistemas de coordenação e processamento de dados em plataformas Ethereum privadas para bens digitais na cadeia pública. Os contratos inteligentes no Ethereum encapsulam a lógica programável dentro desses sistemas e permitem que os desenvolvedores interajam com a Máquina Virtual Ethereum por meio de transações que criam novos ambientes de estado dentro da infraestrutura tecnológica. À medida que casos de uso abrangentes se desenvolvem em ambientes de cadeia pública interoperável, cadeia privada e cadeia de consórcio, os contratos inteligentes usados ​​no Ethereum serão capazes de ligar os sistemas em uma interface lógica comum.

Tecido Hyperledger

Chaincode não é necessariamente um contrato inteligente implantado em um blockchain baseado em conta, mas sim um programa que é instalado e que subsequentemente implementa uma interface por meio de uma API. A interface API requer as instruções baseadas em código para direcionar a lógica de negócios e a funcionalidade em todo o sistema, semelhante a um ambiente de desenvolvimento de software tradicional. Os métodos afiliados à API incluem:

  • Init – iniciação dos estados de aplicação
  • Chamar – processar propostas de transação

Chaincode deve implementar interfaces da API:

  • Interface Chaincode
  • ChaincodeStubInterface

No Hyperledger Fabric, chaincode é executado em contêineres Docker protegidos, onde é isolado dos processos executados pelo par de endosso. O código normalmente é escrito em Go ou Node.js, permitindo a interação que lida com a lógica de negócios. Uma nuance a ter em mente é que o código de cadeia do Fabric não é replicado pelos nós dentro do ecossistema da mesma forma que é esperado de uma verdadeira arquitetura de blockchain.

Chaincode é inicialmente instalado em Peers e depois instanciado em canais. O fluxo do processo é detalhado nos seguintes diagramas:

Ao longo do fluxo do processo Chaincode, várias interações ocorrem com o System Chaincode, que é executado dentro de um processo de mesmo nível executável versus um contêiner isolado. Isso é usado para implementar comportamentos do sistema sem políticas de endosso ou processos de ciclo de vida. O System Chaincode não passa pelo ciclo de vida do código do Chaincode normalEm todo o fluxo do processo Chaincode, várias interações ocorrem com o System Chaincode, que é executado em um processo executável de mesmo nível em comparação a um contêiner isolado. Isso é usado para implementar comportamentos de sistema sem políticas de endosso ou processos de ciclo de vida. O Chaincode do sistema não passa pelo ciclo de vida do código do Chaincode normal. Duas funções da API Shim da interface chaincode são implementadas O código é compilado e mantido pelo par Chaincode não é afiliado a canais ou solicitantes até que o desenvolvedor determine que deseja instalar o programa posteriormenteDuas funções da API Shim da interface chaincode são implementadas. O código é compilado e mantido pelo par. Chaincode não é afiliado a canais ou compradores até que o desenvolvedor determine que eles desejam instalar o programa posteriormente.

Chaincode pode ser configurado para criar ativos que, em última análise, atuam como pares de valores-chave que são armazenados no banco de dados do razão. O fluxo de trabalho de envio de comandos de iniciação e chamada de transações é detalhado no diagrama acima em termos de como os comandos são movidos pelo sistema. A lógica de negócios é codificada dentro das regras da rede e invocada por meio de aplicativos do lado do cliente. O tipo de coordenação e interação de código é muito indicativo do desenvolvimento de software tradicional por meio da dependência de funções tradicionais e interfaces de iniciação.

Comentário

A movimentação do Chaincode através desta configuração de rede permite uma organização simplificada do sistema. A arquitetura de software é preparada para atuar como uma estrutura de comando e controle muito eficiente em termos de distribuição de dados e organização do ambiente de desenvolvimento de software para determinados casos de uso corporativo. Como pode ser percebido na configuração de pacote, instalação, instanciação e atualização, essa arquitetura foi projetada para otimizar os pontos de contato necessários para processar o código. As interfaces de API necessárias à medida que as transações são processadas lembram muito o design de software tradicional. Áreas importantes:

  • Arquitetura monolítica para controle máximo
  • Interação de negócios segura entre as contrapartes
  • Processamento centralmente coordenado para a taxa de transferência da transação

Chaincode é mais um sistema de comandos do que uma linguagem de contrato inteligente que é replicada por um blockchain. Como o ecossistema do Hyperledger Fabric tem um conjunto vibrante de características fortes em termos de funcionalidade e design como um livro razão distribuído, o sistema, na verdade, não possui as qualidades inerentes de um verdadeiro sistema blockchain. Como uma ferramenta que pode ser usada para integração com infraestrutura e paradigmas legados, o Fabric é eficaz devido à sua aderência aos padrões de software pré-existentes, como pode ser deduzido do projeto de arquitetura, conforme descrito acima.

Onde o Fabric ganha em funcionalidade em termos de seu sistema que é um tanto emblemático de sistemas projetados em torno de grandes mainframes e data centers, ele perde em outros aspectos em termos de conexão distribuída a fatores econômicos de computação, pois pode ser acessado em uma economia de token digital inerentemente descentralizada . Se o Fabric fosse integrado a um ambiente de blockchain verdadeiro, ele se encaixaria bem como um ambiente de banco de dados distribuído seguro que valida as informações antes da interação com um ecossistema de blockchain público.

R3 Corda

No Corda, os contratos inteligentes são considerados classes que implementam a interface do Contrato. Os Smart Contracts são escritos em Java / Kotlin e compilados por meio da Java Virtual Machine (JVM), que é a máquina de computação na qual o código é executado. A principal função usada nos contratos é a função “verificar”.

O código é executado na JVM onde as transações são processadas por meio do sistema de reconhecimento de firma e a lógica de negócios é restrita aos fluxos que podem abrigar e isolar o processo de negócios entre diferentes contrapartes.

objeto de estado

Componentes do contrato inteligente:

  • Código executável
  • Valida as mudanças nas transações
  • Objetos de Estado
  • Dados mantidos no livro-razão
  • Estado atual de um contrato
  • Usa entradas e saídas de transações
  • Comandos
  • Dados adicionais
  • Usado para instruir o código executável do contrato

O código Java e Kotlin é compilado em bytecode idêntico por meio do JVM. Os comandos passam dados adicionais que não existem no estado para o código do contrato. Os comandos atuam como estruturas de dados com chaves públicas anexadas usadas para assinar transações, embora deva ser reconhecido que os contratos não funcionam diretamente com as assinaturas digitais. Os contratos neste ambiente são replicados em todo o sistema no contexto de como os Fluxos estão dispostos a coordenar entre as partes confiáveis.

Comentário

O código do contrato atende às necessidades dos casos de uso dentro do ambiente Corda e é capaz de realizar as funções necessárias de rendimento da transação. As limitações incluem interoperabilidade com outros ecossistemas. Para que os sistemas interoperem com o Corda, eles precisariam utilizar a estrutura do código do contrato Corda projetada em torno do DLT fechado. Ao contrário de uma verdadeira plataforma de blockchain como Ethereum, que pode atuar como a camada de interoperabilidade entre processos econômicos e funções entre instanciações privadas e instanciações públicas, Corda se limita por estar mais focado em processos dentro de um sistema fechado. O uso da JVM é inovador, embora a instância seja isolada dentro do ecossistema Corda. Neste cenário, Corda ganha processamento de transações em um ambiente seguro, sacrificando a capacidade de interoperar e coordenar entre diferentes ambientes de blockchain como um sistema interoperável seria capaz de fazer.

4. Conclusão e Avaliação

Com base em nossa análise, os principais fatores de distinção que a Ethereum é capaz de implementar além do que é capaz de DLT são:

  • Ativo digital ou economia de token
  • Camadas de incentivo criptoeconômico no protocolo
  • Interoperabilidade entre consórcio e blockchains públicos

Embora DLTs como R3 Corda e Hyperledger Fabric sejam capazes de alcançar funcionalidade no gerenciamento de banco de dados compartilhado e ciclo de vida de processamento de transações, não é garantido que eles serão capazes de alcançar as funcionalidades-chave descritas acima. Essas plataformas não são falhas, mas sim limitadas em sua configuração arquitetônica para exibir alguns dos casos de uso puros que apenas blockchains verdadeiros são capazes de afirmar.

As tecnologias Blockchain são projetadas para acoplar a confiança instanciada dentro delas com o valor tangível que é criado a partir dessa confiança. Somente por meio de uma verdadeira plataforma construída a partir dos fundamentos centrais de uma blockchain os sistemas sociais, políticos e econômicos poderão ser consagrados fundamentalmente na infraestrutura de um protocolo de software. Embora as plataformas de gerenciamento de banco de dados com foco em DLT possam se integrar e interoperar com uma plataforma de blockchain, os trilhos sobre os quais as transferências de valor e a coordenação dessa confiança serão construídas devem ser um blockchain que incorpore os princípios básicos de confiança, imutabilidade, integridade e fidelidade de informações.

O que esta análise revela não é que certos sistemas sejam melhores do que outros, mas sim que são úteis em diferentes capacidades. A capacidade das plataformas DLT de atuarem como bancos de dados privados distribuídos com alta capacidade de transação e funcionalidade, permite que atuem como sistemas confiáveis ​​que podem interoperar dentro de uma plataforma blockchain quando certas facetas de informações privadas são necessárias para avaliação, como dados bancários / financeiros ou informações confidenciais relativas ao funcionamento interno de uma instituição privada que não devem ser reveladas ao público. Os vários modelos de negócios sobre como utilizar essas fontes de dados privados afiliados ao DLT ainda estão em desenvolvimento e devem ser iterados com interfaces de blockchain em mente, pois um sistema de valor digital descentralizado é necessário para algumas das interações entre blockchains e DLTs.

Conecte-se com nossos especialistas em blockchain

Nossa equipe global de soluções oferece treinamento em blockchain, consultoria estratégica, serviços de implementação e oportunidades de parceria. Fale conosco Boletim Assine nosso boletim informativo para obter as últimas notícias da Ethereum, soluções empresariais, recursos para desenvolvedores e muito mais. Endereço de e-mailConteúdo exclusivoGuia completo para redes de negócios BlockchainGuia

Guia completo para redes de negócios Blockchain

Introdução à TokenizaçãoWebinar

Introdução à Tokenização

O Futuro dos Ativos Digitais Financeiros e DeFiWebinar

O futuro das finanças: ativos digitais e DeFi

O que é Enterprise EthereumWebinar

O que é Enterprise Ethereum?

Bancos centrais e o futuro do dinheiroPapel branco

Bancos centrais e o futuro do dinheiro

Komgo Blockchain para Financiamento do Comércio de CommoditiesCase Stud

Komgo: Blockchain para Financiamento do Comércio de Commodities