Feeds MultiChain para integração de banco de dados

Obtendo dados do blockchain e para o mundo mais amplo

Com o primeiro lançamento público do MultiChain, em 2015, vimos interesse em aplicativos blockchain de uma direção surpreendente. Embora tivéssemos projetado originalmente o MultiChain para permitir a emissão, transferência e custódia de ativos digitais, um número crescente de usuários estava interessado em usá-lo para aplicativos orientados a dados.

Nesses casos de uso, o objetivo do blockchain é permitir o armazenamento e a recuperação de informações de uso geral, que não precisam ser de natureza financeira. A motivação para usar um blockchain em vez de um banco de dados regular é evitar depender de um intermediário confiável para hospedar e manter esse banco de dados. Por razões comerciais, regulatórias ou políticas, os usuários do banco de dados desejam que essa seja uma responsabilidade distribuída em vez de centralizada.

A evolução das correntes

Em resposta a este feedback, em 2016 nós introduzido Streams MultiChain, que fornecem uma abstração simples para o armazenamento, indexação e recuperação de dados gerais em um blockchain. Uma cadeia pode conter qualquer número de fluxos, cada um dos quais pode ser restrito para gravação por determinados endereços. Cada item de fluxo é marcado pelo endereço de seu editor, bem como uma chave opcional para recuperação futura. Cada nó pode decidir independentemente se deve assinar cada fluxo, indexando seus itens em tempo real para recuperação rápida por chave, editor, tempo, bloco ou posição. Streams foi um sucesso instantâneo entre os usuários do MultiChain e o diferenciou fortemente de outras plataformas de blockchain corporativas.

Em 2017, os streams eram opção para suportar texto nativo JSON e Unicode, várias chaves por item e vários itens por transação. Esta última alteração permite que mais de 10,000 itens de dados individuais sejam publicados por segundo em hardware de última geração. Então, em 2018, adicionamos suporte perfeito para dados fora da cadeia, em que apenas um hash de alguns dados é publicado na cadeia e os próprios dados são entregues fora da cadeia aos nós que os desejam. E mais tarde naquele ano, lançamos a Comunidade MultiChain 2.0 com Filtros inteligentes, permitindo que o código JavaScript personalizado execute a validação arbitrária de itens de fluxo.

Durante 2019, nosso foco se voltou para o MultiChain 2.0 Enterprise, a versão comercial do MultiChain para clientes maiores. O primeiro Demonstração Empresarial aproveitou dados fora da cadeia em fluxos para permitir permissão de leitura, entrega de dados criptografados e a recuperação seletiva e eliminação de itens individuais. Como sempre, a complexidade subjacente está oculta por trás de um conjunto simples de APIs relacionadas a permissões e itens de fluxo. Com streams, nosso objetivo tem sido consistentemente ajudar os desenvolvedores a se concentrarem nos dados de seus aplicativos, e não se preocupar com o blockchain em execução nos bastidores.

O dilema do banco de dados

À medida que os fluxos MultiChain continuam a evoluir, enfrentamos um dilema constante. Para ler e analisar os dados em um fluxo, o MultiChain deve seguir o caminho de se tornar um banco de dados completo? Deveria estar oferecendo indexação de campo JSON, consulta otimizada e relatórios avançados? Em caso afirmativo, qual paradigma de banco de dados ele deve usar - relacional (como MySQL ou SQL Server), NoSQL (MongoDB ou Cassandra), pesquisa (Elastic ou Solr), série temporal (InfluxDB) ou in-memory (SAP HANA)? Afinal, existem casos de uso de blockchain adequados para cada uma dessas abordagens.

Uma opção que consideramos é usar um banco de dados externo como armazenamento de dados primário do MultiChain, em vez da combinação atual de LevelDB embutido e arquivos binários. Esta estratégia foi adotada por Núcleo da Corrente (interrompido), cadeia postal (ainda não é público) e está disponível como uma opção em Hyperledger Fabric. Mas, no final das contas, decidimos não usar essa abordagem, devido aos riscos de depender de um processo externo. Você realmente não quer que seu nó blockchain congele porque perdeu sua conexão com o banco de dados ou porque alguém está executando uma consulta complexa em seu armazenamento de dados.

Outro fator a ser considerado é o agnosticismo de tecnologia e integração. Em uma rede blockchain que abrange várias organizações, cada participante terá suas próprias preferências em relação à tecnologia de banco de dados. Eles já terão aplicativos, ferramentas e fluxos de trabalho desenvolvidos nas plataformas que atendem às suas necessidades. Portanto, ao escolher qualquer banco de dados específico, ou mesmo ao oferecer algumas opções, acabaríamos deixando alguns usuários insatisfeitos. Assim como cada participante do blockchain pode executar seu nó em uma ampla variedade de versões do Linux, eles devem ser capazes de se integrar com o banco de dados de sua escolha.

Apresentando MultiChain Feeds

Hoje temos o prazer de lançar nossa abordagem para integração de banco de dados - MultiChain Feeds. Um feed é um log binário em disco em tempo real dos eventos relacionados a um ou mais streams de blockchain, para leitura por processos externos. Também estamos oferecendo o código aberto Adaptador de alimentação MultiChain que pode ler um feed e replicar automaticamente seu conteúdo para um banco de dados Postgres, MySQL ou MongoDB (ou vários de uma vez). O adaptador é escrito em Python e tem uma licença liberal, portanto, pode ser facilmente modificado para oferecer suporte a bancos de dados adicionais ou adicionar filtragem e transformação de dados. (Também documentamos o formato de arquivo de feed para quem deseja escrever um analisador em outro idioma.)

Um nó não precisa se inscrever em um fluxo para replicar seus eventos em um feed. Isso permite que a indexação de fluxo embutida do MultiChain seja completamente ignorada, para economizar tempo e espaço em disco. Os feeds também refletem a recuperação e eliminação de dados fora da cadeia e podem relatar a chegada de novos blocos na cadeia. Para economizar espaço em disco, você pode controlar exatamente quais eventos são gravados em um feed e quais campos são registrados para cada um desses eventos. Além disso, os arquivos de feed são alternados diariamente e há um comando de purga simples para remover os arquivos após o processamento.

Por que os feeds MultiChain são gravados em disco, em vez de serem transmitidos entre processos ou pela rede? Porque queremos que eles sirvam como um log de replicação ultraconfiável, resiliente ao tempo de inatividade do banco de dados, travamentos do sistema, perda de energia e assim por diante. Ao usar arquivos de disco, podemos garantir durabilidade e permitir que o banco de dados de destino seja atualizado de forma assíncrona. Se por algum motivo este banco de dados ficar sobrecarregado ou desconectado, o MultiChain pode continuar operando sem interrupção e o banco de dados será atualizado quando as coisas voltarem ao normal.

Primeiros passos com feeds

Os feeds são integrados ao mais recente demo / beta do MultiChain Enterprise, que é disponível para download agora. Comece lendo a documentação do Adaptador de alimentação MultiChain, ou revisando o APIs relacionadas a feed. Nós adoraríamos ouça seu feedback sobre esse recurso e como podemos expandi-lo no futuro.

Com o lançamento de feeds, a versão 2.0 do MultiChain Enterprise está agora com recursos completos - consulte o Baixe e instale página para uma comparação completa entre as edições Community e Enterprise. Nos próximos meses, estaremos concluindo seus testes e otimização e esperamos que esteja pronto para produção no final do primeiro trimestre. Enquanto isso, para obter informações sobre o licenciamento ou preços do MultiChain Enterprise, não hesite em entrar em contato.

Por favor, poste comentários no LinkedIn.

Fonte: https://www.multichain.com/blog/2020/02/multichain-feeds-for-database-integration/