Estamos assistindo ao surgimento de um fenômeno em franca expansão que pode ser descrito como um catalisador para mudanças significativas na maneira como o mundo é hoje, mudanças essas que atingirão governança, modos de vida, modelos corporativos tradicionais, instituições em escala global e a sociedade como um todo.
Desafiando velhos padrões e ideias que povoam nossa mente há séculos, a arquitetura blockchain desafiará a governança e as maneiras centralizadas e controladas de realizar transações [1], sendo injusto defini-la apenas como um mero registro distribuído. Tal representa apenas uma de suas muitas dimensões cuja amplitude pessoas e empresas ainda não são capazes de qualificar e quantificar.
Conceitos, funcionalidades e características das blockchains ainda estão sendo desvendados, já é possível, contudo, vislumbrar que o caminho para arquitetar soluções em blockchains exige insights e avaliações de seus recursos subjacentes.
Nessa linha, o objetivo deste artigo é fazer uma breve análise comparativa entre blockchains e Ledgers Distribuídos, abordando algumas de suas funções-chave e características para, assim, ajudar a identificar quais vantagens e desvantagens que podem advir de sua adoção. Comentários de desenvolvedores são benvindos para ajudar a corrigir imperfeições técnicas.
Blockchains vs. Tecnologias de Contabilidade Distribuída (DLTs)
Conquanto seja muito comum o uso dos termos “blockchains” e “DLTs” (Distributed Ledger Technologies, em inglês) como sinônimos, a verdade é que apesar das blockchains (Bitcoin e Ethereum, por exemplo) possuírem semelhanças com tecnologias de contabilidade distribuída (como Hyperledger Fabric ou R3 Corda), com elas não se confundem.
Confira nossas sugestões de Pre-Sales para investir agora
As tecnologias de contabilidade distribuída (DLTs), ou como preferem alguns, as arquiteturas e estruturas de registros distribuídos, foram criados para o processamento de transações em um ambiente compartilhado por atores que se conhecem (por uma relação contratual, por exemplo), enquanto as verdadeiras blockchains foram projetadas para que desconhecidos possam transferir valor com segurança, dispensando a necessidade de agentes validadores, para obter certeza (exatidão, veracidade, fidelidade) e imutabilidade em transações e dados. Merecendo destaque, aqui, que veracidade e imutabilidade são essenciais para o sucesso de uma digitalização adequada dos ativos.
Por outro lado, ao analisar alguns dos vários recursos tecnológicos existentes no Ethereum, IBM Hyperledger Fabric e R3 Corda, podemos identificar mais algumas diferenças entre blockchains e DLTs.
Ethereum
As transações na blockchain do Ethereum são armazenadas dentro de blocos, com transições de estado resultando em novos estados do sistema (o que sacrifica a velocidade do processamento de transações do banco de dados em prol da integridade do sistema).
Sendo o ecossistema Ethereum construído a partir de uma combinação de ecossistemas blockchain privadas e blockchain públicas, para o objetivo deste artigo, faz mais sentido sintetizar as nuances de rede pública do Ethereum.
Assim, quanto à participação, tal se dá sem permissão, ou seja, qualquer pessoa tem acesso à rede Ethereum, sem a necessidade de autorização. O modo de participação, vale ressaltar, tem um profundo impacto sobre como o consenso é alcançado.
Quanto ao consenso, no Ethereum, todos os participantes precisam chegar a um consenso sobre a ordem de todas as transações que ocorreram, independentemente de o participante ter contribuído ou não com uma transação específica. A ordem das transações é crucial para o estado consistente do ledger. Se uma ordem definitiva de transações não puder ser estabelecida, há uma chance de que gastos duplos possam ter ocorrido. Como a rede pode envolver partes que não se conhecem (ou possuem qualquer vinculo contratual), um mecanismo consensual deve ser empregado para proteger o livro-razão contra participantes fraudulentos que pretendam executar gastos duplos. Na implementação “atual” do Ethereum, esse mecanismo é estabelecido pela mineração com base no esquema de prova de trabalho (PoW) [2] . Todos os participantes têm que concordar com um livro comum e todos os participantes têm acesso a todas as entradas já registradas. As conseqüências são que o PoW afeta desfavoravelmente o desempenho do processamento de transações . No que diz respeito aos dados armazenados no ledger, embora os registros sejam “pseudônimos”, eles são acessíveis a todos os participantes, o que pode comprometer aplicativos que exigem maior grau de privacidade.
Outra funcionalidade digna de nota é que o Ethereum possui uma criptomoeda embutida chamada Ether. Ele é usado para pagar recompensas para nós que contribuem para alcançar consenso por blocos de mineração, bem como para pagar taxas de transação. Portanto, aplicativos descentralizados (DApps) podem ser construídos para o Ethereum, que permitem transações monetárias. Além disso, um token digital para casos de uso personalizados pode ser criado com a implantação de um contrato inteligente que esteja em conformidade com um padrão pré-definido. Dessa forma, moedas ou ativos próprios podem ser definidos.
Além disso, a arquitetura do Ethereum também permite que “plataformas afiliadas” sejam capazes de adicionar camadas de incentivos “cripto-economicos” no sistema.
Por fim, o Ethereum possui integração na comoditização digital de ativos, ou seja, pode se integrar em uma economia de bens digitais, o que não é possível nem no Hyperledger Fabric, nem no R3 Corda.
Hyperledger Fabric
Já o IBM Hyperledger Fabric substitui os princípios-chave de um sistema blockchain, mantendo a execução de todas as transações dentro da arquitetura multicanal para garantir alto rendimento de transações dentro de um ambiente confiável. O Hyperledger Fabric é um DLT, não uma blockchain.
A arquitetura Fabric sacrifica a integridade e a fidelidade de dados de um sistema blockchain para obter processamento de transações e taxa de transferência mais rápidos em um ambiente confiável de fluxo de dados. Todavia, conquanto o arranjo de estado dentro do ambiente do Fabric seja eficiente, ele não tem a capacidade de preservar valor em um ecossistema público descentralizado, da mesma forma que uma blockchain, como o Ethereum ou o Bitcoin, seria capaz de fazer.
Quanto à participação, no Hyperledger Fabric ela é autorizada (permissionada), de modo que os participantes da rede são selecionados antecipadamente e o acesso à rede é restrito a estes apenas.
Em relação ao consenso, a interpretação do Hyperledger Fabric é mais refinada e não se limita à mineração baseada em PoW (Proof of Work, ou prova de trabalho em português) ou um derivado dela. Por operar de modo permissionado (autorizado), o Hyperledger Fabric fornece um controle de acesso mais refinado para os registros e, assim, privilegia a privacidade. Além disso, obtém-se um ganho de desempenho, eis que somente as partes que participam de uma transação precisam chegar a um consenso. O consenso do Fabric é amplo e abrange todo o fluxo de transações, isto é, desde a proposição de uma transação para a rede até o comprometimento com o ledger. Além disso, os dispositivos computacionais (conhecidos também por “nós”) assumem papéis e tarefas diferentes no processo de obtenção de consenso.
No Hyperledger Fabric, os “nós” são diferenciados, classificando-se em Client or submitting-client, peer e consenter . Sem adentrar em detalhes técnicos, o Fabric permite um controle refinado sobre o consenso e acesso restrito a transações, o que resulta em melhor escalabilidade e privacidade do desempenho.
Fabric não requer criptomoedas embutidas, pois o consenso não é alcançado através da mineração. Com o Fabric, no entanto, é possível desenvolver uma moeda nativa ou um token digital com o chaincode.
R3 Corda
Na arquitetura do R3 Corda, por sua vez, o processamento de dados compartilhados ocorre em ambiente “parcialmente confiável”, isto é, as contrapartes não precisam confiar totalmente umas nas outras, embora sua plataforma não possua os componentes de um sistema blockchain capazes de assegurar valor inequívoco, exato e imutável.
No R3 Corda, partes de informações são anexadas a um ledger parecido com um banco de dados, que adiciona dados em uma cadeia de eventos, e permite a rastreabilidade de sua procedência em ambiente controlado. A procedência dos dados é controlada pelos membros do Consórcio R3 Corda que detém certos controles de acesso à plataforma de software. Usando essa configuração, bancos e instituições financeiras poderão maximizar a eficiência em termos de processamento de informações em um ecossistema de contabilidade 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. Para que uma transação no R3 Corda seja válida, ela deve: ser assinada pelas partes envolvidas, ser validada pelo código do contrato que determina a transação.
Quanto à participação no R3 Corda, do mesmo modo que no Hyperledger Fabric, ela é autorizada (permissionada) de modo que os participantes da rede são selecionados antecipadamente e o acesso à rede é restrito a estes apenas.
Em relação ao consenso no R3 Corda, sua interpretação é mais refinada e não limita-se à mineração baseada em PoW(Proof of Work, ou prova de trabalho em português) ou um derivado dela. Por operar com permissão, R3 Corda fornece controle de acesso mais refinado para registros e, assim, aumenta a privacidade. Além disso, obtém-se ganho de desempenho, pois apenas as partes que participam de uma transação precisam chegar a um consenso. Semelhante ao Fabric, o consenso em R3 Corda também é alcançado no nível de transação, envolvendo apenas partes. Sujeitam-se ao consenso a validade da transação e a unicidade da transação, sendo tal validade garantida pela execução de um código de smart contracts associados a uma transação. Consenso sobre exclusividade de uma transação é alcançado entre os participantes conhecidos por “notary nodes”.
Aqui, é importante destacar que por ser um sistema está fechado, o R3 Corda não possui os meios necessários e as características tecnológicas para construir um ecossistema baseado em incentivos econômicos, nem um ambiente de ativos digitais públicos. Mais ainda, o R3 Corda não requer criptomoedas embutidas, pois o consenso não é alcançado através da mineração, além do que o White Paper do Corda não prevê a criação de criptomoedas ou tokens .
Arquiteturas Ethereum, Hyperledger Fabric e R3 Corda quanto aos possíveis casos de uso
Ao analisar os White Papers do Ethereum, do Hyperledger Fabric e do Corda, extrai-se que essas estruturas têm visões muito diferentes quanto a possíveis campos de aplicação .
Nesse passo, a motivação do desenvolvimento do Hyperledger Fabric e R3 Corda reside em casos de uso concretos. Os casos de uso de Corda são extraídos do setor de serviços financeiros, razão pela qual neste setor reside o principal campo de aplicação do R3 Corda. O Hyperledger Fabric, de outro lado, pretende fornecer uma arquitetura modular e extensível que pode ser empregada em vários setores, desde serviços bancários e de saúde até cadeias de suprimentos.
O Ethereum também se mostra totalmente independente de qualquer campo específico de aplicação, mas em contraposição ao Hyperledger Fabric, não é a especificidade que se destaca, mas o fornecimento de uma plataforma genérica para todos os tipos de transações e aplicações.
Considerações finais
Conclui-se, pois, que as arquiteturas aqui apresentadas brevemente são inerentemente diferentes umas das outras. Blockchains como Ethereum possuem certos recursos que não existem nos ledgers distribuídos, e estes por sua vez, possuem recursos de “desempenho” que o Ethereum “atualmente” não consegue atingir na mesma medida.
Ademais, todas as infraestruturas analisadas estão ainda em construção e, portanto, seus protocolos devem ser cuidadosamente examinados por empresários e gestores, que devem compreendê-los com a profundidade necessária antes de qualquer implementação prática.
Saber onde se pretende ir e quão próximas essas arquiteturas estão de replicar os graus desejados de funcionalidade, é essencial.
Como a ilusão de sabedoria, assim como a ignorância, são os maiores obstáculos ao conhecimento, contribuições de desenvolvedores para corrigir imperfeições técnicas são benvindas.
Referencias
[1] Na medida em que a arquitetura blockchain ajuda a diminuir, e potencialmente pode até eliminar, nossa dependência de agentes validadores de confiança (como bancos, governos, advogados, notários e funcionários responsáveis pela conformidade regulatória).
[2] Vitalik Buterin, criador do ethereum, lançou recentemente um guia de implementação que revela que os desenvolvedores da rede começarão com um sistema “híbrido” que mescla proof-of-work (PoW) com seu tão esperado e ainda experimental sistema proof-of-stake chamado Casper, criado por Buterin.
Bibliografia
Ethereum. In: Ethereum State Transition Function. Github. Disponível em: https://github.com/ethereum/wiki/wiki/White-Paper#ethereum-state-transition-function.
Ethereum. In: Philosophy. GitHub. Disponível em: https://github.com/ethereum/wiki/wiki/White-Paper#philosophy
Hearn, Mike. In: Corda: A distributed ledger. Corda Technical Whitepaper. Corda, 2016. Disponível em: https://docs.corda.net/_static/corda-technical-whitepaper.pdf
Mougayar, William (Author); Butterin, Vitalik (Prologo) In: The Business Blockchain: Promise, Practice, and Application of the Next Internet Technology. Amazon, 2017.
Ray, Shaan. In: The Difference Between Blockchain And Distributed Ledger Technology. Towards Data Science, 2018.
The Linux Foundation. In: Hyperledger Explainer. Hyperledger. Disponível em: https://youtu.be/js3Zjxbo8TM
The Linux Foundation. In: Hyperledger Architecture, Volume 1. Hyperledger Whitepaper. Disponível em: https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf
Valenta, Martin; Sandner, Phillip. In: Comparison of Ethereum, Hyperledger Fabric and Corda. Frankfurt School Blockchain Center, 2017.
Wikipedia, A enciclopédia livre. In: White Paper. Disponível em: https://pt.wikipedia.org/wiki/White_paper
Xu, Bent. In: Blockchain vs. Distributed Ledger Technologies. Consensys, 2018.