Scaling Blockchains With Off-chain Data

Republicado por Platão

seguidores: 0

Quando um hash vale um milhão de palavras

Agora está claro que muitos casos de uso de blockchain não têm nada a ver com transações financeiras. Em vez disso, o objetivo da cadeia é permitir a agregação descentralizada, ordenação, registro de data e hora e arquivamento de qualquer tipo de informação, incluindo dados estruturados, correspondência ou documentação. O valor central do blockchain é permitir que seus participantes concordem de forma comprovada e permanente sobre exatamente quais dados foram inseridos, quando e por quem, sem depender de um intermediário confiável. Por exemplo, o SAP recentemente lançado plataforma blockchain, que oferece suporte a MultiChain e Hyperledger Fabric, visa uma ampla gama de aplicações da cadeia de suprimentos e outras aplicações não financeiras.

A maneira mais simples de usar um blockchain para registrar dados é incorporar cada parte dos dados diretamente em uma transação. Cada transação de blockchain é assinada digitalmente por uma ou mais partes, replicada para cada nó, ordenada e com registro de data e hora pelo algoritmo de consenso da cadeia e armazenada permanentemente de forma à prova de violação. Quaisquer dados dentro da transação serão, portanto, armazenados de forma idêntica, mas independentemente por cada nó, junto com uma prova de quem os escreveu e quando. Os usuários da rede podem recuperar essas informações a qualquer momento.

Por exemplo, MultiChain 1.0 permitia que um ou mais “streams” nomeados fossem criados em um blockchain e então usados para armazenar e recuperar dados brutos. Cada fluxo tem seu próprio conjunto de permissões de gravação e cada nó pode escolher livremente em quais fluxos se inscrever. Se um nó for inscrito em um fluxo, ele indexa o conteúdo desse fluxo em tempo real, permitindo que os itens sejam recuperados rapidamente com base em seu pedido, carimbo de data / hora, número de bloco ou endereço do editor, bem como por meio de uma "chave" (ou rótulo) pelos quais os itens podem ser marcados. MultiChain 2.0 (desde alfa 1) streams estendidos para suportar texto Unicode ou dados JSON, bem como várias chaves por item e vários itens por transação. Ele também adicionou funções de resumo, como “mesclagem JSON”, que combinam itens com a mesma chave ou editor de uma forma útil.

Confidencialidade e escalabilidade

Embora o armazenamento de dados diretamente em um blockchain funcione bem, ele sofre de duas deficiências principais - confidencialidade e escalabilidade. Para começar com a confidencialidade, o conteúdo de cada item do fluxo é visível para todos os nós da cadeia e isso não é necessariamente um resultado desejável. Em muitos casos, uma parte dos dados deve ser visível apenas para um determinado subconjunto de nós, mesmo se outros nós forem necessários para ajudar com sua ordenação, registro de data e hora e reconhecimento de firma.

A confidencialidade é um problema relativamente fácil de resolver, criptografando as informações antes que elas sejam incorporadas a uma transação. A chave de descriptografia para cada parte dos dados é compartilhada apenas com os participantes que devem vê-la. A entrega da chave pode ser realizada na cadeia usando criptografia assimétrica (como descrito aqui) ou por meio de algum mecanismo fora da cadeia, como é preferido. Qualquer nó sem a chave para descriptografar um item verá nada mais do que uma tagarelice binária.

A escalabilidade, por outro lado, é um desafio mais significativo. Digamos que qualquer plataforma de blockchain decente deve suportar uma taxa de transferência de rede de 500 transações por segundo. Se a finalidade da cadeia for o armazenamento de informações, o tamanho de cada transação dependerá principalmente da quantidade de dados que ela contém. Cada transação também precisará de (pelo menos) 100 bytes de overhead para armazenar o endereço do remetente, a assinatura digital e alguns outros bits e peças.

Se pegarmos um caso fácil, onde cada item é uma pequena estrutura JSON de 100 bytes, a taxa de transferência geral de dados seria de 100 kilobytes por segundo, calculada de 500 × (100 + 100). Isso se traduz em menos de 1 megabit / segundo de largura de banda, que está confortavelmente dentro da capacidade de qualquer conexão de Internet moderna. Os dados se acumulariam a uma taxa de cerca de 3 terabytes por ano, o que não é pouca coisa. Mas com discos rígidos de 12 terabytes agora amplamente disponível e RAID controladores que combinam várias unidades físicas em uma única lógica, poderíamos facilmente armazenar de 10 a 20 anos de dados em cada nó sem muitos problemas ou despesas.

No entanto, as coisas parecem muito diferentes se estivermos armazenando peças maiores de informações, como documentação digitalizada. Uma digitalização JPEG de qualidade razoável de uma folha de papel A4 pode ter 500 kilobytes de tamanho. Multiplique isso por 500 transações por segundo e teremos uma taxa de transferência de 250 megabytes por segundo. Isso se traduz em 2 gigabits / segundo de largura de banda, que é mais rápido do que a maioria das redes locais, quanto mais conexões com a Internet. Mais barato na Amazon Web Services preço publicado de $ 0.05 por gigabyte, significa uma conta anual de largura de banda de $ 400,000 por nó. E onde cada nó armazenará os 8000 terabytes de novos dados gerados anualmente?

É claro que, para aplicativos de blockchain que armazenam muitos dados grandes, o armazenamento on-chain direto não é uma escolha prática. Para piorar a situação, se os dados são criptografados para resolver o problema de confidencialidade, os nós estão sendo solicitados a armazenar uma grande quantidade de informações que eles não podem nem mesmo ler. Esta não é uma proposta atraente para os participantes da rede.

A solução de hashing

Então, como podemos resolver o problema de escalabilidade de dados? Como podemos aproveitar as vantagens da notarização descentralizada de dados do blockchain, sem replicar esses dados para todos os nós da cadeia?

A resposta é com uma tecnologia inteligente chamada “hash”. Um hash é um número longo (pense em 256 bits, ou cerca de 80 dígitos decimais) que identifica exclusivamente um dado. O hash é calculado a partir dos dados usando um função unidirecional que tem uma propriedade criptográfica importante: dado qualquer dado, é fácil e rápido calcular seu hash. Mas, dado um determinado hash, é computacionalmente inviável encontrar um dado que geraria esse hash. E quando dizemos “computacionalmente inviável”, queremos dizer mais cálculos do que átomos no universo conhecido.

Hashes desempenham um papel crucial em todas as cadeias de bloqueio, identificando exclusivamente transações e blocos. Eles também estão na base do desafio computacional em sistemas de prova de trabalho como o bitcoin. Muitas funções hash diferentes foram desenvolvidas, com nomes de gobbledygook como BLAKE2, MD5 e RIPEMD160. Mas para que qualquer função hash seja confiável, ela deve passar por extensas análises e testes acadêmicos. Esses testes vêm na forma de tentativas de ataque, como "pré-imagem" (encontrar uma entrada com o hash fornecido), "segunda pré-imagem" (encontrar uma segunda entrada com o mesmo hash da entrada fornecida) e "colisão" (encontrar qualquer duas entradas diferentes com o mesmo hash). Sobreviver a esse desafio está longe de ser fácil, com uma longa e trágica história de funções de hash quebradas comprovando a famosa máxima: "Não role sua própria criptografia."

Voltando ao nosso problema original, podemos resolver a escalabilidade de dados em blockchains incorporando os hashes de grandes pedaços de dados nas transações, em vez dos próprios dados. Cada hash atua como um “compromisso” com seus dados de entrada, com os próprios dados sendo armazenados fora da blockchain ou “fora da cadeia”. Por exemplo, usando a popular função hash SHA256, uma imagem JPEG de 500 kilobytes pode ser representada por um número de 32 bytes, uma redução de mais de 15,000 ×. Mesmo a uma taxa de 500 imagens por segundo, isso nos coloca confortavelmente de volta ao território dos requisitos viáveis de largura de banda e armazenamento, em termos dos dados armazenados na própria cadeia.

Claro, qualquer participante do blockchain que precisa de uma imagem fora da cadeia não pode reproduzi-la de seu hash. Mas se a imagem puder ser recuperada de alguma outra maneira, o hash na cadeia serve para confirmar quem a criou e quando. Assim como os dados regulares na cadeia, o hash está embutido em uma transação assinada digitalmente, que foi incluída na cadeia por consenso. Se um arquivo de imagem cair do céu e o hash dessa imagem corresponder a um hash no blockchain, a origem e o carimbo de data / hora dessa imagem serão confirmados. Portanto, o blockchain está fornecendo exatamente o mesmo valor em termos de reconhecimento de firma como se a imagem estivesse embutida na cadeia diretamente.

Uma questão de entrega

Até agora tudo bem. Incorporando hashes em um blockchain em vez dos dados originais, temos uma solução fácil para o problema de escalabilidade. No entanto, uma questão crucial permanece:

Como entregamos o conteúdo original fora da cadeia para os nós que precisam dele, se não através da própria cadeia?

Esta pergunta tem várias respostas possíveis e sabemos de usuários do MultiChain que aplicam todas elas. Uma abordagem básica é configurar um repositório centralizado em alguma parte confiável, onde todos os dados fora da cadeia são carregados e posteriormente recuperados. Esse sistema poderia naturalmente usar “endereçamento de conteúdo”, o que significa que o hash de cada pedaço de dados serve diretamente como seu identificador para recuperação. No entanto, embora essa configuração possa funcionar para uma prova de conceito, não faz sentido para a produção, porque o objetivo de um blockchain é remover intermediários confiáveis. Mesmo que os hashes na cadeia impeçam o intermediário de falsificar os dados, ele ainda pode excluir os dados ou não entregá-los a alguns participantes, devido a uma falha técnica ou ações de um funcionário desonesto.

Uma possibilidade mais promissora é a comunicação ponto a ponto, na qual o nó que requer alguns dados fora da cadeia os solicita diretamente do nó que os publicou. Isso evita depender de um intermediário confiável, mas apresenta três deficiências alternativas:

Ele requer um mapa de endereços de blockchain para endereços IP, para permitir que o consumidor de alguns dados se comunique diretamente com seu editor. Em geral, os blockchains podem evitar esse tipo de configuração de rede estática, o que pode ser um problema em termos de failover e privacidade.
Se o nó do editor original deixou a rede ou está temporariamente fora de serviço, os dados não podem ser recuperados por mais ninguém.
Se um grande número de nós estiver interessado em alguns dados, o editor ficará sobrecarregado de solicitações. Isso pode criar congestionamento de rede severo, reduzir a velocidade do sistema do editor e levar a longos atrasos para aqueles que tentam recuperar esses dados.

Para evitar esses problemas, o ideal é usar algum tipo de mecanismo de entrega descentralizado. Os nós devem ser capazes de recuperar os dados de que precisam sem depender de nenhum sistema individual - seja um repositório centralizado ou o editor original dos dados. Se várias partes tiverem um dado, eles devem compartilhar o fardo de entregá-lo a qualquer pessoa que o queira. Ninguém precisa confiar em uma fonte de dados individual, porque os hashes on-chain podem provar que os dados não foram adulterados. Se um nó malicioso entregar os dados errados para um hash, posso simplesmente descartar esses dados e tentar perguntar a outra pessoa.

Para quem tem experiência com compartilhamento de arquivos ponto a ponto protocolos como o Napster, Gnutella ou BitTorrent, tudo isso soará muito familiar. Na verdade, muitos dos princípios básicos são os mesmos, mas existem duas diferenças principais. Primeiro, supondo que estamos usando nosso blockchain em um contexto corporativo, o sistema é executado em um grupo fechado de participantes, em vez da Internet como um todo. Em segundo lugar, o blockchain adiciona um backbone descentralizado de ordenação, registro de data e hora e reconhecimento de firma, permitindo que todos os usuários mantenham uma visão comprovadamente consistente e resistente a adulteração de exatamente o que aconteceu, quando e por quem.

Como um desenvolvedor de aplicativo blockchain pode conseguir essa entrega descentralizada de conteúdo fora da cadeia? Uma escolha comum é usar uma plataforma de compartilhamento de arquivos ponto a ponto existente, como a plataforma de nome divertido Sistema de arquivos interplanetários (IPFS) e usá-lo junto com o blockchain. Cada participante executa um nó blockchain e um nó IPFS, com alguma coordenação de middleware entre os dois. Ao publicar dados fora da cadeia, esse middleware armazena os dados originais no IPFS e, em seguida, cria uma transação blockchain contendo o hash dos dados. Para recuperar alguns dados fora da cadeia, o middleware extrai o hash do blockchain e, em seguida, usa esse hash para buscar o conteúdo do IPFS. O nó IPFS local verifica automaticamente o conteúdo recuperado em relação ao hash para garantir que não tenha sido alterado.

Embora essa solução seja possível, ela é bastante desajeitada e inconveniente. Primeiro, cada participante deve instalar, manter e atualizar três partes distintas de software (nó blockchain, nó IPFS e middleware), cada um dos quais armazena seus dados em um local separado. Em segundo lugar, haverá duas redes ponto a ponto separadas, cada uma com sua própria configuração, portas de rede, sistema de identidade e permissões (embora deva ser observado que o IPFS ainda não oferece suporte a redes fechadas). Finalmente, o acoplamento forte do IPFS e do blockchain tornaria o middleware cada vez mais complexo. Por exemplo, se quisermos que os dados fora da cadeia referenciados por algumas transações do blockchain sejam recuperados instantaneamente (com novas tentativas automáticas), o middleware precisará estar constantemente ativo e em execução, mantendo seu próprio estado complexo. Não seria bom se o nó blockchain fizesse tudo isso por nós?

Dados fora da cadeia no MultiChain 2.0

Hoje temos o prazer de lançar o terceira versão prévia (alfa 3) do MultiChain 2.0, com uma solução totalmente integrada e contínua para dados fora da cadeia. Cada informação publicada em um fluxo pode estar dentro ou fora da rede, conforme desejado, e o MultiChain cuida de todo o resto.

Na verdade, queremos dizer tudo. Como um desenvolvedor que utiliza MultiChain, você não precisa se preocupar com hashes, armazenamento local, descoberta de conteúdo, entrega descentralizada ou verificação de dados. Aqui está o que acontece nos bastidores:

O nó MultiChain de publicação grava os novos dados em seu armazenamento local, dividindo itens grandes em pedaços para fácil digestão e entrega.
A transação para publicar itens de fluxo fora da cadeia é construída automaticamente, contendo os hash (s) e tamanho (s) em bytes.
Essa transação é assinada e transmitida para a rede, propagando-se entre os nós e entrando no blockchain da maneira usual.
Quando um nó inscrito em um fluxo vê uma referência a alguns dados fora da cadeia, ele adiciona os hashes do bloco para esses dados em sua fila de recuperação. (Ao assinar um fluxo antigo, um nó também enfileira quaisquer itens fora da cadeia publicados anteriormente para recuperação.)
Como um processo em segundo plano, se houver chunks na fila de recuperação de um nó, consultas são enviadas para a rede para localizar esses chunks, conforme identificados por seus hashes.
Essas consultas de chunk são propagadas para outros nós na rede de forma ponto a ponto (limitado a dois saltos por enquanto - consulte os detalhes técnicos abaixo).
Qualquer nó que tenha os dados de um bloco pode responder, e essa resposta é retransmitida ao assinante de volta ao longo do mesmo caminho da consulta.
Se nenhum nó responder à consulta do bloco, o bloco será retornado à fila para uma nova tentativa posterior.
Caso contrário, o assinante escolhe a fonte mais promissora para um bloco (com base em saltos e tempo de resposta) e envia uma solicitação para os dados desse bloco, novamente no mesmo caminho ponto a ponto da resposta anterior.
O nó de origem entrega os dados solicitados, usando o mesmo caminho novamente.
O assinante verifica o tamanho e o hash dos dados em relação à solicitação original.
Se tudo estiver certo, o assinante grava os dados em seu armazenamento local, tornando-os imediatamente disponíveis para recuperação por meio das APIs de fluxo.
Se o conteúdo solicitado não chegar ou não corresponder ao hash ou tamanho desejado, o fragmento é retornado à fila para recuperação futura de uma fonte diferente.

E o mais importante, tudo isso acontece extremamente rápido. Em redes com baixa latência, pequenos pedaços de dados fora da cadeia chegarão aos assinantes em uma fração de segundo da transação que os referencia. E para aplicativos de alta carga, nossos testes mostram que MultiChain 2.0 alpha 3 pode sustentar uma taxa de mais de 1000 itens fora da cadeia ou 25 MB de dados fora da cadeia recuperados por segundo, em um servidor de médio alcance (Core i7) com um decente Conexão de internet. Tudo funciona bem com itens fora da rede de até 1 GB de tamanho, muito além do limite de 64 MB para dados dentro da rede. É claro que esperamos melhorar ainda mais esses números à medida que gastamos tempo otimizando o MultiChain 2.0 durante sua fase beta.

Ao usar dados fora da cadeia em vez de dados na cadeia em fluxos, os desenvolvedores de aplicativos MultiChain precisam fazer exatamente duas coisas:

Ao publicar dados, passe um sinalizador “offchain” para as APIs apropriadas.
Ao usar as APIs de consulta de fluxo, considere a possibilidade de alguns dados fora da cadeia ainda não estarem disponíveis, conforme relatado pelo sinalizador “disponível”. Embora essa situação seja rara em circunstâncias normais, é importante que os desenvolvedores de aplicativos lidem com ela de maneira adequada.

Obviamente, para evitar que cada nó recupere todos os itens fora da cadeia, os itens devem ser agrupados em fluxos de maneira apropriada, com cada nó assinando esses fluxos de interesse.

Os itens na cadeia e fora da cadeia podem ser usados dentro do mesmo fluxo, e as várias funções de consulta e resumo de fluxo se relacionam a ambos os tipos de dados de forma idêntica. Isso permite que os editores façam a escolha apropriada para cada item em um fluxo, sem afetar o restante de um aplicativo. Por exemplo, um fluxo de itens JSON sobre as atividades das pessoas pode usar dados fora da cadeia para informações de identificação pessoal e dados na cadeia para o resto. Os assinantes podem usar a fusão JSON do MultiChain para combinar os dois tipos de informações em um único JSON para leitura.

Se você quiser dar uma chance aos itens de fluxo fora da cadeia, basta seguir as regras normais do MultiChain Iniciando tutorial e certifique-se de não pular a seção 5.

Então o que vem depois?

Com suporte contínuo para dados fora da cadeia, o MultiChain 2.0 oferecerá um grande passo em frente para aplicativos de blockchain focados em registro de data e hora de dados em grande escala e reconhecimento de firma. A longo prazo, já estamos pensando em uma tonelada de possíveis melhorias futuras para esse recurso para as edições Community e / ou Enterprise do MultiChain:

Implementando fluxo ler permissões usando uma combinação de itens fora da cadeia, hashes salgados, consultas de blocos assinados e entrega criptografada.
Permitir que dados fora da cadeia sejam explicitamente “esquecidos”, tanto voluntariamente por nós individuais ou por todos os nós em resposta a uma mensagem na cadeia.
Assinaturas de fluxo seletivo, em que os nós apenas recuperam os dados para itens fora da cadeia com editores ou chaves específicos.
utilização árvores merkle para permitir que um único hash na cadeia represente um número ilimitado de itens fora da cadeia, dando outro salto enorme em termos de escalabilidade.
Mecanismos de armazenamento plugáveis, permitindo que dados fora da cadeia sejam mantidos em bancos de dados ou sistemas de arquivos externos, em vez de disco local.
Nós aprendendo ao longo do tempo onde cada tipo de dados fora da cadeia geralmente está disponível em uma rede e focalizando suas consultas por blocos de forma adequada.

Nós adoraríamos ouça seu feedback na lista acima, bem como itens fora da rede em geral. Com o MultiChain 2.0 ainda oficialmente em alfa, há muito tempo para aprimorar esse recurso antes de seu lançamento final.

Nesse ínterim, já começamos a trabalhar em “Filtros Inteligentes”, o último recurso importante planejado para a Comunidade MultiChain 2.0. Um Filtro Inteligente é um pedaço de código embutido na blockchain que implementa regras personalizadas para validar dados ou transações. Filtros inteligentes têm algumas semelhanças com “contratos inteligentes” e podem fazer muitas das mesmas coisas, mas têm diferenças importantes em termos de segurança e desempenho. Estamos ansiosos para lhe dizer mais no devido tempo.

Por favor, poste comentários no LinkedIn.

Detalhes técnicos

Embora os itens de fluxo fora da cadeia no MultiChain 2.0 sejam simples de usar, eles contêm muitas decisões de design e recursos adicionais que podem ser de interesse. A lista abaixo será relevante principalmente para desenvolvedores que criam aplicativos blockchain e pode ser ignorada por tipos menos técnicos:

Políticas por transmissão. Quando um fluxo MultiChain é criado, ele pode ser opcionalmente restrito para permitir apenas dados on-chain ou off-chain. Existem várias razões possíveis para fazer isso, em vez de permitir que cada editor decida por si mesmo. Por exemplo, os itens da rede oferecem uma garantia de disponibilidade férrea, enquanto os itens antigos da rede podem se tornar irrecuperáveis se seu editor e outros assinantes abandonarem a rede. Por outro lado, os itens na cadeia não podem ser “esquecidos” sem modificar o blockchain, enquanto os itens fora da cadeia são mais flexíveis. Isso pode ser importante em termos de regras de privacidade de dados, como os novos regulamentos GDPR da Europa.
Metadados on-chain. Para itens fora da cadeia, a transação na cadeia ainda contém o (s) editor (es), chave (s), formato (JSON, texto ou binário) e tamanho total do item. Tudo isso ocupa muito pouco espaço e ajuda os desenvolvedores de aplicativos a determinar se a indisponibilidade de um item fora da cadeia é uma preocupação para uma consulta de fluxo específica.
Limite de dois saltos. Ao retransmitir consultas de blocos pela rede ponto a ponto, há uma compensação entre acessibilidade e desempenho. Embora seja bom que cada consulta seja propagada ao longo de cada caminho, isso pode obstruir a rede com “tagarelice” desnecessária. Portanto, por enquanto, as consultas de chunk estão limitadas a dois saltos, o que significa que um nó pode recuperar dados fora da cadeia de qualquer par de seus pares. Nas redes menores de menos de 1000 nós que tendem a caracterizar blockchains empresariais, acreditamos que isso funcionará bem, mas é fácil para nós ajustar essa restrição (ou oferecê-la como um parâmetro) se estivermos errados.
Armazenamento local. Cada nó MultiChain armazena dados fora da cadeia dentro do diretório “chunks” de seu diretório blockchain regular, usando um formato binário eficiente e índice LevelDB. Um subdiretório separado é usado para os itens em cada um dos fluxos assinados, bem como aqueles publicados pelo próprio nó. Em cada um desses subdiretórios, blocos duplicados (com o mesmo hash) são armazenados apenas uma vez. Quando um nó cancela a assinatura de um fluxo, ele pode escolher se deseja ou não limpar os dados fora da cadeia recuperados para esse fluxo.
Cache binário. Ao publicar grandes partes de dados binários, seja na cadeia ou fora da cadeia, pode não ser prático para os desenvolvedores de aplicativos enviar esses dados para a API do MultiChain em uma única solicitação JSON-RPC. Portanto, o MultiChain 2.0 implementa um cache binário, que permite que grandes pedaços de dados sejam construídos em várias chamadas de API e, então, publicados em uma breve etapa final. Cada item no cache binário é armazenado como um arquivo simples no subdiretório “cache” do diretório blockchain, permitindo que gigabytes de dados também sejam enviados diretamente por meio do sistema de arquivos.
APIs de monitoramento. MultiChain 2.0 alpha 3 adiciona duas novas APIs para monitorar a recuperação assíncrona de dados fora da cadeia. A primeira API descreve o estado atual da fila, mostrando quantos blocos (e quantos dados) estão esperando ou sendo consultados ou recuperados. A segunda API fornece estatísticas agregadas para todas as consultas e solicitações de blocos enviadas desde a inicialização do nó, incluindo contagens de diferentes tipos de falha.
Lavar ao publicar. Ao publicar um item fora da cadeia, o MultiChain garante que sua cópia local dos dados seja totalmente gravada (ou “liberada”) na unidade de disco físico antes da transação que faz referência aos dados ser transmitida para a rede. Caso contrário, se o nó tiver o azar de perder energia imediatamente após a transmissão da transação, os dados fora da cadeia podem ser perdidos permanentemente. Isso não é um problema para o MultiChain em si, uma vez que os atrasos entre as tentativas de recuperação de um bloco aumentam automaticamente com o tempo. Mas pode causar problemas no nível do aplicativo, onde todos sabem da existência de alguns dados, mas ninguém é capaz de encontrá-los.
Desempenho de publicação. Ao liberar dados fora da cadeia para o disco dessa maneira, o MultiChain pode incorrer em uma penalidade de desempenho, pois os discos físicos são lentos. Por exemplo, um disco rígido de 7200 rpm de faixa média pode realizar apenas cerca de 100 gravações de dados aleatórios por segundo, limitando por sua vez a taxa na qual um nó individual pode publicar itens fora da cadeia. Existem três soluções alternativas possíveis para este problema. Em primeiro lugar e da forma mais simples, os nós podem usar uma unidade de dispositivo de estado sólido (SSD) em vez de um disco rígido normal, que suporta 10,000 operações de gravação aleatória por segundo. Em segundo lugar, vários itens fora da cadeia podem ser publicados em uma única transação usando a API “createrawsendfrom”. Nesse caso, o MultiChain grava todos os dados fora da cadeia referenciados por uma transação em uma única operação de disco. Finalmente, o MultiChain pode ser configurado para não liberar dados fora da cadeia para o disco antes de transmitir a transação que faz referência a eles. Use esta opção com cuidado.
Integração de moeda nativa. Para casos de uso que exigem isso, MultiChain sempre ofereceu a opção de usar uma moeda nativa em um blockchain para evitar spam de transações e / ou incentivar validadores de bloco (“mineradores”). Nestes casos, as transações devem oferecer aos mineiros uma taxa mínima proporcional ao seu tamanho em bytes, para serem retransmitidas e confirmadas na cadeia. Esse mecanismo foi estendido para permitir que o spam fora da cadeia seja evitado, exigindo uma taxa adicional mínima por kilobyte de dados fora da cadeia referenciados em uma transação.
Nós de arquivo. Se um nó deseja se inscrever em cada fluxo e, portanto, recuperar e armazenar todos os itens fora da cadeia publicados, ele pode ser configurado para fazer isso usando o parâmetro de tempo de execução “autosubscribe”. Qualquer um desses nodos atuará como backup de toda a rede, garantindo que os itens fora da cadeia não sejam perdidos ou indisponíveis, não importa quais outros nodos desapareçam. Pode-se imaginar empresas terceirizadas oferecendo isso como um serviço comercial.