Blockchain, O Que És Tu? Definindo uma Palavra da Moda da Indústria

À medida que nos aproximamos de 2016, parece haver discussões intermináveis sobre 'blockchain'. É um termo que é cada vez mais citado até mesmo no jornalismo convencional, enquanto no espaço FinTech sozinho há uma série de possíveis fornecedores e possíveis usuários alegando que 'blockchain' revolucionará qualquer número de aplicações.

Esse uso agora comum sugere que deve ser algo precisamente definido e bem compreendido, mas isso parece ser mais uma questão de mantra do que de compreensão.

As câmaras de eco da Internet reverberam muitas opiniões, mas tentativas de encontrar um significado preciso parecem encontrar uma falta de acordo desanimadora. Para ser algo mais do que uma hipérbole de marketing, realmente precisamos das respostas para algumas perguntas.

O que é? O que T é? O que pode ser? Pode ser algo que nos permitirá construir sistemas novos e duradouros? Em suma, qual é a essência do blockchain?

O white paper de Satoshi

Quase todas as discussões sobre blockchains começam com oLivro branco de Satoshi, mas é essa mesma fundação que nos coloca no caminho da confusão. Nem os termos 'blockchain' ou 'block chain' aparecem ali; há 67 usos de 'block' e 27 de 'chain', mas zero de 'block chain' ou 'blockchain'. Deixando isso de lado, vamos ver aonde essa origem nos leva.

O white paper é curto; tem apenas nove páginas. A primeira menção de 'bloco' e 'cadeia' começa na parte inferior da página 2, seção 3, onde há uma discussão sobre um servidor de timestamp básico. Antes disso, o white paper descreve uma série de objetivos de design associados ao design do Bitcoin , como a capacidade de permitir que duas partes realizem transações sem precisar confiar em uma terceira parte.

A declaração dos objetivos do design é fundamentalmente importante. Eles definem o cenário para uma implementação para atender a esses objetivos nos quais as características são sobrepostas umas às outras, mas é informativo observar o que cada nova camada faz.

Em nossa busca pela natureza de um blockchain, precisamos ter cuidado ao procurar coisas que sejam seus atributos, em vez de características desta primeira implementação.

Transações

A seção 1 do white paper é uma introdução e é na seção 2 que vemos algo realmente substancial. A seção 2 define um cenário para uma moeda digital, mas é descrita como sendo uma cadeia de transações em que a "moeda" é atribuída a novos proprietários. A moeda é realmente uma metáfora para um histórico de transações de transações vinculadas.

Curiosamente, a seção 2 também descreve como um sistema centralizado T precisa fazer isso.

Blocos e correntes

Com a seção 3, vemos a essência do padrão de design que pode descrever melhor a base de um blockchain. Ele é dado como algo que é construído a partir de uma série de blocos incrementais de dados, cada um dos quais pode ser identificado por um hash criptográfico sobre seu conteúdo. Além disso, cada bloco incorpora o hash criptográfico de seu bloco predecessor para garantir a construção de uma cadeia.

Os hashes de bloco são publicados como uma forma de evidência amplamente testemunhada que demonstra a existência tanto dos dados do bloco quanto do hash predecessor. Alterar o predecessor ou os outros dados dentro do bloco resultaria em uma assinatura de hash diferente para o bloco que não corresponderia à visão amplamente testemunhada.

Essas características são todas fundamentais, e sem elas não podemos construir nada interessante. O que é igualmente interessante, porém, é o que não é declarado como necessário neste ponto. Não há menções a moedas, nem menções a redes peer-to-peer, nem menções a mineração, ETC Em vez disso, a sugestão é que publicar hashes em qualquer forma amplamente disseminada seria suficiente, com os dois exemplos sendo dados como publicação em um jornal ou publicação via Usenet.

Embora vejamos algumas características explícitas, elas levam a algumas implícitas:

A publicação dos hashes não tem sentido a menos que esses mesmos hashes possam ser recomputados independentemente por um observador externo que recebe apenas os dados dos blocos na cadeia. É essa característica que permite que os observadores não tenham que confiar no originador da cadeia de blocos; em vez disso, eles são capazes de comparar hashes históricos por si mesmos.

A recomputação dos hashes requer que o algoritmo pelo qual os blocos são produzidos seja determinístico e bem especificado. Sem isso, nosso observador externo não pode recomputar os hashes.

Habilitando operações ponto a ponto

A próxima seção, 4, do white paper fala sobre proof-of-work. A primeira linha é interessante: "Para implementar um servidor de timestamp distribuído em uma base peer-to-peer (P2P), precisaremos usar um sistema de proof-of-work semelhante ao Hashcash de Adam Back". O proof-of-work não é necessário para construir um blockchain, apenas para habilitar a implementação peer-to-peer do servidor de timestamp.

Projetos subsequentes de Criptomoeda mostraram que há outras abordagens que podem ser adotadas aqui também (por exemplo: formas de prova de participação ou híbridos de ambos), mas se estivermos satisfeitos com uma abordagem cliente-servidor, então nenhuma delas é realmente necessária.

Isso não quer dizer que a prova de trabalho não possa ter outros usos em um design de blockchain, mas nenhum parece fundamental para nossa busca.

Rede e além

A Seção 5 descreve as características de implementação da rede Bitcoin . Nada aqui estende explicitamente o conceito do que é um blockchain, ou pode exigir. De fato, nem as seções 6, 7, 8, 9, 10, 11 ou 12 (a seção final) continuam a oferecer explicitamente quaisquer novas ideias sobre o que um blockchain pode ser.

Respostas às nossas perguntas

Se o white paper de Satoshi é a origem do design de blockchain, ficamos com uma definição bem tênue, mas talvez esse seja o aspecto mais esclarecedor. Ele é muito explícito sobre escolhas particulares de design e seus propósitos, o que tende a levar à percepção de que muitas das alegações sobre 'blockchains' podem, na verdade, ser uma questão de implementação em vez de arquitetura.

Vamos então fazer algumas perguntas específicas!

Uma blockchain precisa ter moedas?

Há uma discussão interessante no white paper sobre a necessidade de fornecer incentivos para aqueles que fornecem segurança à rede P2P para permanecerem honestos e como um meio de introduzir 'moedas' no sistema, mas a discussão está claramente no contexto da rede P2P. O conceito de moedas em si é notado como desnecessário com uma 'casa da moeda' confiável.

Uma casa da moeda confiável não é algo desejável em uma Criptomoeda, mas parece não haver nenhuma exigência para moedas se quisermos construir uma cadeia de blocos criptograficamente vinculados. Há uma questão interessante a ser feita sobre confiança, mas retornaremos a isso mais tarde.

Uma blockchain deve implementar contratos inteligentes?

Da perspectiva do white paper, isso parece improvável. A palavra "contrato" não aparece em lugar nenhum.

Um blockchain pode habilitar contratos inteligentes? Sim, claro que pode, mas pode habilitar muitas outras coisas também.

Um blockchain deve ser programável?

Novamente a resposta parece ser não. Nem as palavras 'programa' nem 'script' aparecem no white paper.

Um blockchain tem um requisito para ser interpretável por um ou mais observadores independentes, então ele é claramente construído a partir de uma ou mais estruturas de dados bem definidas. A estrutura de dados do bloco deve conter um hash de bloco anterior, e o hash criptográfico do bloco deve ser executado de uma forma muito específica, mas nenhum deles requer que a estrutura de dados carregue qualquer noção de código executável.

Um blockchain pode conter alguma forma de código de programa? Esta é uma questão de implementação e a resposta é sim. O Bitcoin inclui uma linguagem de script limitada e outros sistemas, como Ethereum, posteriormente tentaram dar suporte a modelos de programação mais elaborados.

A escolha de dar suporte a tais conceitos parece ser mais uma questão de conveniência ou de objetivos de design mais ambiciosos, mas parece que um blockchain não precisa ser mais "programável" do que qualquer outra estrutura de dados de lista vinculada.

Um blockchain é um banco de dados?

Mais uma vez a resposta parece ser não. Como antes, a palavra 'banco de dados' não aparece no white paper.

Em sua CORE, um blockchain é um tipo especial de estrutura de dados. Os blocos dentro da cadeia contêm dados, mas isso não a torna um banco de dados; na melhor das hipóteses, os blocos representam o log de transações de uma implementação específica de banco de dados.

Da mesma forma, não há semântica para consultar um blockchain, assim como não há para consultar uma lista encadeada. Uma implementação específica pode permitir consultas de qualquer um, mas a implementação não define a coisa em si.

Como ponto de comparação, os pacotes IP para os pacotes TCP que transportam este artigo são definidos como estruturas de dados em uma série de documentos IETF (Internet Engineering Task Force) RFC (Request For Comments). Os documentos descrevem a forma dos pacotes e seu comportamento quando são transportados. Os destinatários desses pacotes são capazes de fazer suas próprias determinações de sua validade sem considerar qualquer parte da implementação da rede entre eles e o originador.

Uma implementação de um roteador/firewall pode oferecer um recurso para capturar esses pacotes para que eles possam ser analisados mais tarde, e pode oferecer consultas de banco de dados desses pacotes, mas não há nada na natureza de um pacote IP que o torne um banco de dados, nem há nada nos RFCs que sugira o contrário. Recursos de implementação e especificação são coisas muito diferentes.

Um blockchain é confiável?

A resposta aqui também é não, mas isso é porque a questão é muito ampla. Um blockchain nos permite exigir menos confiança do que muitos sistemas tradicionais, mas qualquer implementação ainda requer algum nível de confiança.

Um destinatário de dados de bloco deve confiar que eles foram entregues sem serem comprometidos por algum intermediário. A distribuição P2P de blocos dentro do Bitcoin e redes similares foi criada para tentar minimizar a confiança em pares, mas mesmo esse modelo tem potenciais pontos de falha. Aqui estão alguns:

• Confiamos que o software blockchain que estamos executando não foi comprometido para fornecer dados falsificados
• Confiamos que o sistema operacional sob o qual nosso software blockchain está sendo executado não foi comprometido para fornecer dados falsificados
• Confiamos que os processadores de rede que fornecem conectividade ao nosso sistema não foram comprometidos para fornecer dados falsificados.

"In code we trust" é um mantra interessante, mas mais de 30 anos de malware, spyware, ETC, nos informam que esta é uma estratégia altamente discutível.

Um design de blockchain torna as falsificações mais difíceis para um adversário e torna erros acidentais dramaticamente menos prováveis. Somos capazes de "confiar, mas verificar" (dentro dos limites), mas isso ainda é uma melhoria significativa em relação à confiança cega. Mais importante, nenhuma dessas características de minimização de confiança são aspectos do design de rede P2P, mas são intrínsecas à codificação do bloco.

Um blockchain deve ser não autorizado ou pode ser sem permissão?

Um blockchain é apenas uma estrutura de dados, então realmente a questão não faz sentido. Quem tem a capacidade de ler ou escrever uma estrutura de dados é uma questão totalmente diferente.

Vamos ignorar essa distinção sutil por um momento, no entanto, e agir como se a pergunta pudesse fazer sentido. Considere o caso do Bitcoin; quem escreve o blockchain?

A resposta é que os mineradores (ou mais precisamente, os fabricantes de blocos, como operadores de pools de mineração, não aqueles que apenas fazem hash de blocos) conseguem escrever novos blocos. Os transatores na rede podem fornecer transações candidatas para serem incluídas em blocos, mas isso não garante que os blocos conterão essas transações. Com o Bitcoin, falamos sobre isso ser "não autorizado" porque ninguém precisa de nenhuma permissão explícita para se tornar um Maker de blocos.

Se considerarmos outros usos potenciais de um design de blockchain, no entanto, há um conjunto frequentemente muito bem definido de participantes que gostaríamos que pudessem escrever dados de bloco. Em muitos casos, pode até ser um único participante.

Uma crítica feita a tais usos potenciais de um blockchain é que isso não o torna melhor do que um banco de dados, mas um banco de dados convencional é algo em que confiança cega deve ser depositada. Seu estado interno é geralmente incognoscível. Mesmo em seus usos mais simples, um blockchain pode pelo menos fornecer um meio de verificar o estado de tal sistema, e fazê-lo de uma forma que permita que os históricos sejam validados. Este é apenas o começo das possibilidades, no entanto!

Uma blockchain é a Internet do dinheiro (ou a Internet de qualquer outra coisa)?

Realisticamente, não, ou pelo menos não por si só.

Quando olhamos para "não é um banco de dados", também abordamos o motivo pelo qual essa afirmação T faz muito sentido. Superficialmente, o argumento parece sedutor. O pensamento é que podemos construir muita Tecnologia em cima de um blockchain da mesma forma que uma pilha de rede é em camadas.

Há muitos problemas com essa proposição, mas o mais óbvio é que um blockchain é apenas uma estrutura de dados. Ele é um bom candidato para ser usado para transmitir informações pela Internet, mas T permite nada por si só.

Separar o blockchain de qualquer transporte de um blockchain, no entanto, dá alguma esperança de que os blockchains possam permitir aplicações financeiras mais confiáveis pela Internet. Uma separação clara também permite experimentação em cada camada do design do sistema e esta é uma característica fundamental que permitiu que a Internet fosse tão bem-sucedida.

Com a Internet, candidatos para todas as camadas da pilha de rede podem ser testados, substituídos ou modificados, permitindo que os melhores designs WIN. Da mesma forma, a abordagem baseada em padrões permitiu que implementações díspares funcionassem juntas sem impedir que vantagens comerciais fossem buscadas e monetizadas.

No caso de blockchains, já vimos que há um requisito para dar suporte a observadores externos e isso exige um nível de interoperabilidade.

Últimos Pensamentos

Nós olhamos para o que um blockchain pode ou não ser, e talvez tenhamos visto algumas dicas do que ele pode permitir. A Tecnologia que sustenta o Bitcoin pode ser usada para construir muitas coisas, e o legado do bitcoin não deve ser apenas o Bitcoin em si – ele mostrou a viabilidade de algo muito mais fundamental.

O debate sobre o que constitui um blockchain T termina aqui, mas precisamos levar a discussão adiante e resistir à tentação de permitir que isso seja apenas mais um chavão de marketing.

Para que isso aconteça, precisamos tanto de terminologia clara quanto de uso bem fundamentado. Precisamos evitar a confusão de muitas ideias diferentes e precisamos que as alegações Tecnologia sejam realistas e realizáveis. Se falharmos, então, eventualmente, o termo "blockchain" não terá mais sentido e terá que ser substituído. Isso parece o resultado errado.

Se tivermos sucesso, então a ideia de um blockchain não será o fim da história. Em vez disso, ele tomará seu lugar como uma camada sobre a qual sistemas melhores e cada vez mais úteis podem ser construídos.

Este artigo foi republicado com a permissão deHashingit.com. Você pode Siga Dave no Twitter em @hashingitcom.

Imagemvia Shutterstock