Sim, você pode precisar de um Blockchain

Balaji S. Srinivasan é ex-CTO da Coinbase, sócio do conselho da Andreessen Horowitz e membro do conselho consultivo da CoinDesk.

O artigo a seguir foi publicado originalmente na Consensus Magazine, distribuída exclusivamente aos participantes do evento Consensus 2019 da CoinDesk.

Existe um certo tipo de desenvolvedor que afirma que os blockchains são apenasterrível bancos de dados. Conforme a narrativa, por que não usar apenas o PostgreSQL para seu aplicativo? Ele é maduro, robusto e de alto desempenho. Comparado aos bancos de dados relacionais, o cético alega que os blockchains são apenas bancos de dados lentos, desajeitados e caros que T escalam.

Embora algumas críticas a esta crítica já existam (1,2), eu proporia uma refutação simples de uma frase: blockchains públicas são úteis para armazenar estado compartilhado, particularmente quando esse estado compartilhado representa dados valiosos que os usuários desejam exportar/importar sem erros — como seu dinheiro.

O problema da exportação/importação de dados

Dê uma olhada nos diagramas de nuvens paraServiços da Web da Amazon,Microsoft Azure, ou Nuvem do Google. Há ícones para balanceadores de carga, transcodificadores, filas e funções lambda.

Existem ícones para VPCs e todos os tipos de bancos de dados WED, incluindo os mais novos blockchain gerenciadoserviços (que são distintos dos blockchains públicos, embora potencialmente úteis em algumas circunstâncias).

O que T há um ICON para é o estado compartilhado entre contas. Ou seja, todos esses diagramas de nuvem assumem implicitamente que uma única entidade e seus funcionários (ou seja, a entidade com acesso ao conta raiz na nuvem) é o ONE que apresenta o diagrama de arquitetura e lê ou escreve no aplicativo que ele sustenta. Mais precisamente, esses diagramas geralmente assumem a presença de um único ator econômico, ou seja, a entidade que paga as contas da nuvem.*

Mas se visualizarmos os diagramas de nuvem não apenas para um , mas para ONE atores econômicos corporativos por vez, algumas questões imediatas surgem. Esses atores podem interoperar? Seus usuários podem extrair seus dados e levá-los para outros aplicativos? E dado que os próprios usuários são atores econômicos, se esses dados representam algo de valor monetário, os usuários podem ter certeza de que seus dados T foram modificados durante toda essa exportação e importação?

Esses são os tipos de perguntas que surgem quando pensamos na exportação e importação de dados do aplicativo de cada entidade como um requisito de primeira classe. E (com exceções que abordaremos), em geral, a resposta a essas perguntas hoje é tipicamente não.

Não — diferentes aplicativos normalmente T têm software interoperável, nem permitem que seus usuários exportem/importem facilmente seus dados em um formato padrão, nem dão aos usuários a certeza de que seus dados T foram intencionalmente adulterados ou corrompidos inadvertidamente durante toda a exportação e importação.

A razão pela qual se resume a incentivos. Para a maioria dos principais serviços de internet, simplesmente não há incentivo financeiro para permitir que os usuários exportem seus dados, muito menos para permitir que os concorrentes importem rapidamente esses dados. Enquanto alguns chamam isso deportabilidade de dadosproblema, vamos chamá-lo de problema de exportação/importação de dados para focar a atenção nos mecanismos específicos de exportação e importação.

Abordagens atuais para o problema de exportação/importação de dados

Embora os incentivos financeiros ainda T estejam presentes para uma solução geral para o problema de exportação/importação de dados, mecanismos foram criados para muitos casos especiais importantes. Esses mecanismos incluem APIs, exportações JSON/PDF/CSV, arquivos MBOX e (em um contexto bancário) SFTP.

Vamos analisar cada um deles para entender o estado atual das coisas.

• APIs. Uma das formas mais populares de exportar/importar dados é por meio de Interfaces de Programação de Aplicativos, mais conhecidas como APIs. Algumas empresas permitem que você obtenha alguns de seus dados ou lhe dão a capacidade de gravar dados em sua conta. Mas há um custo. Primeiro, seu formato de dados interno é tipicamente proprietário e não um padrão da indústria. Segundo, às vezes as APIs não são centrais para seus negócios CORE e podem ser desligado. Terceiro, às vezes as APIs são essenciais para o seu negócio CORE e o preço pode ser dramaticamente aumentado. Em geral, se você estiver lendo ou escrevendo para uma API hospedada, você estará à mercê do provedor da API. Nós chamamos isso de risco de plataforma, e ser desplataformado sem cerimônia temprejudicado muitos um comece.
• JSON.Outra solução relacionada é permitir que usuários ou scripts baixem arquivos JSON, ou leiam/escrevam nas APIs mencionadas anteriormente. Isso é bom até certo ponto, mas JSON é muito livre e pode descrever praticamente qualquer coisa. Por exemplo, o FacebookAPI de gráficoe do LinkedInAPI RESTlidam com coisas semelhantes, mas retornam resultados JSON muito diferentes.
• PDF.Outra solução muito parcial é permitir que os usuários exportem um PDF. Isso funciona para documentos, pois o PDF é umpadrão aberto que pode ser lido por outros aplicativos como Preview, Adobe Acrobat, Google Drive, Dropbox e assim por diante. Mas um PDF é feito para ser um produto final, para ser lido por um Human. Ele não é feito para ser uma entrada para nenhum aplicativo além de um visualizador de PDF.
• CSV.O humilde arquivo de valores separados por vírgulas se aproxima mais do que queremos para uma solução geral para o problema de importação/exportação de dados. Ao contrário do backend de uma API proprietária, o CSV é umformato padrãodescrito porRFC 4180. Ao contrário do JSON, que pode representar quase tudo, um CSV normalmente representa apenas uma tabela. E, ao contrário de um PDF, um CSV normalmente pode ser editado localmente por um usuário por meio de uma planilha ou usado como entrada legível por máquina para um aplicativo local ou em nuvem. Como a maioria dos tipos de dados pode ser representada em um banco de dados relacional e como os bancos de dados relacionais geralmente podem serexportado como um conjunto de CSVs possivelmente gigantescos, também é bem geral. No entanto, os CSVs são desfavorecidos de algumas maneiras. Primeiro, diferentemente de uma API proprietária, eles T são hospedados. Ou seja, não há um único lugar canônico para ler ou escrever um CSV representando (digamos) um registro de transações ou uma tabela de metadados de mapa. Segundo, os CSVs T são resistentes a adulterações. Se um usuário exporta um registro de transações do serviço A, o modifica e o recarrega para o serviço B, o segundo serviço não saberia. Terceiro, os CSVs T têm verificações de integridade integradas para proteger contra erros inadvertidos. Por exemplo, as colunas de um CSV T têm informações de tipo explícitas, o que significa que uma coluna contendo os meses do ano de 1 a 12 pode ter seu tipo convertido automaticamente na importação para um inteiro simples, causando confusão.
• MBOX.Embora menos conhecido que o CSV, oFormato MBOXpara representar coleções de mensagens de e-mail é a coisa mais próxima que existe de uma estrutura de dados padronizada construída para importação e exportação entre as principais plataformas e aplicativos independentes. Na verdade, houvepapéis propondo o uso de MBOX em contextos fora do e-mail. Enquanto CSV representa dados tabulares, MBOX representa um tipo de dados estruturados em log. É essencialmente um único arquivo de texto simples enorme de mensagens de e-mail em ordem cronológica, mas também pode representar imagens/anexos de arquivo via MIME. Assim como CSV, os arquivos MBOX são um padrão abertoe pode ser exportado, editado localmente e reimportado. E como CSV, MBOX tem as desvantagens de não ter host canônico ou verificação de integridade de dados intrínseca.
• SFTP. Antes de prosseguirmos, há mais um mecanismo de exportação/importação de dados que merece ser mencionado: o protocolo de transferência segura de arquivos, ou SFTP. Embora venerável, esta é, na verdade, a maneira como os indivíduos enviam pagamentos ACH de um FORTH para o outro. Essencialmente, as instituições financeiras usam servidores SFTP para receber dados de transações eletrônicas em arquivos especialmente formatadose transmiti-lo ao Federal Reserve todos os dias para sincronizar os débitos e créditos ACH entre si (consulteaqui,aqui,aqui, e aqui).

Cada um desses mecanismos é amplamente utilizado. Mas eles são insuficientes para permitir o caso geral de importação e exportação resistentes a adulteração de dados valiosos entre atores econômicos arbitrários — sejam eles entidades corporativas, usuários individuais ou scripts headless. Para isso, precisamos de blockchains públicos.

Blockchains públicas permitem estado compartilhado ao incentivar a interoperabilidade. Blockchains públicas convertem muitos tipos de problemas de importação/exportação de dados em uma classe geral de problemas de estado compartilhado. E eles fazem isso em parte ao incorporar muitos dos melhores recursos dos mecanismos descritos acima.

• Blockchains públicos fornecem métodos canônicos para acesso de leitura/escrita como uma API corporativa hospedada, mas sem o mesmo risco de plataforma. Nenhum ator econômico pode desligar ou negar serviço a clientes de um blockchain público descentralizado como Bitcoin ou Ethereum.
• Eles também permitem que usuários individuais exportem dados críticos para seus computadores locais ou para um novo aplicativo como JSON/CSV/ MBOX (seja enviando fundos ou exportando chaves privadas), ao mesmo tempo em que fornecem garantias criptográficas de integridade de dados.
• Eles fornecem um meio para atores econômicos arbitrários (sejam corporações, usuários individuais ou programas) interoperarem perfeitamente. Todo ator econômico que lê de um blockchain público vê o mesmo resultado, e qualquer ator econômico com fundos suficientes pode escrever em um blockchain público da mesma forma. Nenhuma configuração de conta é necessária e nenhum ator pode ser bloqueado do acesso de leitura/gravação.
• E talvez o mais importante, blockchains públicos oferecem incentivos financeiros para interoperabilidade e integridade de dados.

Este último ponto merece elaboração. Um blockchain público como Bitcoin ou Ethereum normalmente registra a transferência de coisas de valor monetário. Essa coisa pode ser a Criptomoeda intrínseca da cadeia, um token emitido no topo da cadeia ou outro tipo de ativo digital.

Como os dados associados a um blockchain público representam algo de valor monetário, eles finalmente fornecem o incentivo financeiro para a interoperabilidade. Afinal, qualquer aplicativo web ou móvel que queira receber (digamos) BTC deve honrar as convenções do blockchain do Bitcoin . De fato, os desenvolvedores de aplicativos não teriam escolha devido ao fato de que o Bitcoin, por design, tem uma única cadeia de prova de trabalho canônica mais longa com validação criptográfica de cada bloco nessa cadeia.

Então, esse é o incentivo financeiro para importação.

Quanto ao incentivo para exportação, quando se trata de dinheiro em particular, os usuários exigem a capacidade de exportar com total fidelidade e muito rapidamente. Não são suas fotos antigas de gatos, que eles podem estar bem em perder de vista devido a inconveniências ou problemas técnicos. É seu dinheiro, seu Bitcoin, sua Criptomoeda. Qualquer aplicativo que o tenha deve disponibilizá-lo para exportação quando quiserem retirá-lo, seja isso significando suporte à funcionalidade de envio, oferecendo backups de chave privada ou ambos. Se não, é improvável que o aplicativo receba depósitos em primeiro lugar.

Então, esse é o incentivo financeiro para exportação. Assim, um blockchain público incentiva economicamente cada ator econômico que interage com ele a usar o mesmo formato de importação/exportação que todos os outros atores, sejam eles corporações, usuários ou programas. Em outras palavras, os blockchains públicos são o próximo passo após o código aberto, pois fornecem dados abertos. Qualquer um pode codificar seu próprio explorador de blocos lendo de um blockchain público, e qualquer um pode criar sua própria carteira capaz de gravar em um blockchain público.

Esse é um verdadeiro avanço. Agora temos uma maneira confiável de incentivar o uso do estado compartilhado, para permitir simultaneamente que milhões de indivíduos e empresas acessem para ler (e milhares para escrever) o mesmo armazenamento de dados, ao mesmo tempo em que reforçamos um padrão comum e mantemos alta confiança na integridade dos dados.

Isso é muito diferente do status quo. Você normalmente T compartilha a senha root do seu banco de dados na internet, porque um banco de dados que permite que qualquer um leia/escreva nele geralmente é corrompido. Blockchains públicos resolvem esse problema com criptografia em vez de permissões, aumentando muito o número de usuários simultâneos.

É verdade que hoje os blockchains públicos são tipicamente focados em aplicações monetárias e financeiras, onde o conjunto de dados subjacente representa um histórico de transações somente de acréscimo com registros imutáveis. Isso limita sua generalidade, em termos de abordar todas as diferentes versões do problema de importação/exportação de dados. Mas há desenvolvimento contínuo em versões de blockchain públicas de coisas como OpenStreetMaps, Wikipedia e Twitter, bem como sistemas como Filecoin/IPFS. Eles T representariam apenas registros de transações financeiras onde a imutabilidade fosse um requisito, mas poderiam representar outros tipos de dados (como entradas de mapas ou enciclopédias) que seriam atualizados rotineiramente.

Feitos corretamente, esses novos tipos de sistemas públicos baseados em blockchain podem permitir que qualquer ator econômico com fundos suficientes e/ou credenciais criptográficas não apenas leia e escreva, mas também edite seus próprios registros, preservando a integridade dos dados. Dada essa capacidade, não há razão para que T ONE possa colocar uma camada SQL em cima de um blockchain público para trabalhar com o estado compartilhado que ele oferece, assim como um banco de dados relacional antigo. Isso resulta em um novo tipo de banco de dados sem proprietário privilegiado, onde todos os sete bilhões de humanos no planeta (e seus scripts!) são usuários autorizados, e que podem ser escritos por qualquer entidade com fundos suficientes.

Esse dia ainda T chegou. Resta ver até onde podemos levar os casos de uso para cadeias públicas. E os desafios de escala são abundantes. Mas, esperançosamente, está claro que, embora as blockchains públicas sejam de fato um novo tipo de banco de dados, elas oferecem algo bem diferente do que um banco de dados tradicional oferece.

* A ONE exceção é o chamado recurso "Requester Pays" que a Amazon e outros serviços de nuvem oferecem. Este é um recurso legal que permite que alguém pague para escrever no seu bucket S3. Mas é permissionado – ainda requer que cada escritor em potencial abra uma conta AWS, e o proprietário do bucket tem que estar disposto a deixá-los escrever em seu bucket, então ainda há um único proprietário distinto.

Imagem de banco de dados via Shutterstock