Apresentando o MultiChain Streams

Nó Fonte: 1213525

Para bancos de dados de valores-chave e séries temporais imutáveis

Hoje estamos orgulhosos de lançar a versão mais recente do MultiChain, que implementa um novo conjunto de funcionalidades crucial chamado “streams”. Streams fornecem uma abstração natural para casos de uso de blockchain que se concentram na recuperação geral de dados, registro de data e hora e arquivamento, em vez da transferência de ativos entre os participantes. Streams podem ser usados ​​para implementar três tipos diferentes de bancos de dados em uma cadeia:

  1. Um banco de dados de valor-chave ou armazenamento de documentos, no estilo NoSQL.
  2. Um banco de dados de série temporal, que se concentra na ordem das entradas.
  3. Um banco de dados baseado em identidade onde as entradas são classificadas de acordo com seu autor.

Estes podem ser considerados como 'o quê', 'quando' e 'quem' de um banco de dados compartilhado.

Noções básicas de streams

Qualquer número de streams pode ser criado em uma blockchain MultiChain, e cada stream atua como uma coleção independente de itens apenas para acréscimos. Cada item em um fluxo tem as seguintes características:

  • Um ou mais editores que assinaram digitalmente esse item.
  • Um opcional chave para recuperação posterior conveniente.
  • Alguns dados,, que pode variar de um pequeno pedaço de texto a muitos megabytes de binário bruto.
  • A timestamp, que é obtido do cabeçalho do bloco em que o item é confirmado.

Nos bastidores, cada item em um fluxo é representado por uma transação blockchain, mas os desenvolvedores podem ler e gravar fluxos sem perceber esse mecanismo subjacente. (Usuários mais avançados podem usar transações brutas para gravar em vários fluxos, emitir ou transferir ativos e / ou atribuir permissões em uma única transação atômica.)

Os streams se integram ao sistema de permissões do MultiChain de várias maneiras. Em primeiro lugar, os fluxos só podem ser criados por aqueles que têm permissão para fazê-lo, da mesma forma que ativos só podem ser emitidos por determinados endereços. Quando um fluxo é criado, ele é aberto ou fechado. Streams abertos podem ser gravados por qualquer pessoa que tenha permissão para enviar uma transação blockchain, enquanto streams fechados são restritos a uma lista mutável de endereços permitidos. No último caso, cada fluxo tem um ou mais administradores que podem alterar essas permissões de gravação ao longo do tempo.

Cada blockchain tem um fluxo 'raiz' opcional, que é definido em seu parâmetros e existe a partir do momento em que a cadeia é criada. Isso permite que um blockchain seja usado imediatamente para armazenar e recuperar dados, sem esperar que um fluxo seja explicitamente criado.

Como eu discutido anteriormente, a confidencialidade é o maior desafio em um grande número de casos de uso de blockchain. Isso ocorre porque cada nó em uma blockchain vê uma cópia completa do conteúdo da cadeia inteira. Streams fornecem uma maneira natural de oferecer suporte a dados criptografados em um blockchain, da seguinte maneira:

  1. Um fluxo é usado pelos participantes para distribuir suas chaves públicas para qualquer esquema de criptografia de chave pública.
  2. Um segundo fluxo é usado para publicar dados, onde cada pedaço de dados é criptografado usando criptografia simétrica com uma chave única.
  3. Um terceiro fluxo fornece acesso aos dados. Para cada participante que deve ver um dado, é criada uma entrada de fluxo que contém a chave secreta dos dados, criptografada usando a chave pública do participante.

Isso fornece uma maneira eficiente de arquivar dados em um blockchain, ao mesmo tempo que os torna visíveis apenas para determinados participantes.

Recuperando de streams

O valor central dos streams está na indexação e recuperação. Cada nó pode escolher quais fluxos assinar, com o blockchain garantindo que todos os nós que assinam um fluxo específico verão os mesmos itens dentro. (Um nó também pode ser configurado para se inscrever automaticamente em cada novo fluxo criado.)

Se um nó estiver inscrito em um fluxo, as informações podem ser recuperadas desse fluxo de várias maneiras:

  • Recuperando itens do fluxo em ordem.
  • Recuperando itens com uma chave específica.
  • Recuperando itens assinados por um editor específico.
  • Listando as chaves usadas em um fluxo, com contagens de itens para cada chave.
  • Listar os editores em um fluxo, com contagens de itens.

Conforme mencionado no início, esses métodos de recuperação permitem que os fluxos sejam usados ​​para bancos de dados de valores-chave, bancos de dados de séries temporais e bancos de dados baseados em identidade. Todas as APIs de recuperação oferecem começo e contar parâmetros, permitindo que subseções de listas longas sejam recuperadas com eficiência (como uma cláusula LIMIT em SQL). Valores negativos para começo permitir que os itens mais recentes sejam recuperados.

Streams podem conter vários itens com a mesma chave, e isso naturalmente resolve a tensão entre a imutabilidade do blockchain e a necessidade de atualizar um banco de dados. Cada 'entrada' efetiva do banco de dados deve receber uma chave exclusiva em seu aplicativo, com cada atualização dessa entrada representada por um novo item de fluxo com sua chave. As APIs de recuperação de fluxo do MultiChain podem então ser usadas para: (a) recuperar a primeira ou última versão de uma determinada entrada, (b) recuperar um histórico de versão completo para uma entrada, (c) recuperar informações sobre várias entradas, incluindo a primeira e a última versões de cada um.

Observe que, devido à arquitetura ponto a ponto de um blockchain, os itens em um fluxo podem chegar a nós diferentes em ordens diferentes, e o MultiChain permite que os itens sejam recuperados antes de serem "confirmados" em um bloco. Como resultado, todas as APIs de recuperação oferecem uma escolha entre ordenação global (o padrão) ou local. A ordenação global garante que, uma vez que a cadeia tenha alcançado o consenso, todos os nós recebam as mesmas respostas das mesmas chamadas de API. A ordenação local garante que, para qualquer nó particular, a ordenação dos itens de um fluxo nunca mudará entre as chamadas de API. Cada aplicativo pode fazer a escolha apropriada para suas necessidades.

Streams e o roteiro MultiChain

Com o lançamento dos streams, concluímos a última grande parte do trabalho do MultiChain 1.0 e agora estamos no caminho para a versão beta. Esperamos passar os próximos meses expandindo nosso conjunto de testes internos (já bastante grande!), Finalizando as portas do Windows e Mac, adicionando algumas APIs mais úteis, atualizando o Explorer para streams, aprimorando aspectos do mecanismo de consenso, lançando nossa demonstração na web e, geralmente, organizando o código e as mensagens de ajuda. E o mais importante, continuaremos corrigindo quaisquer bugs assim que forem descobertos, para que nossos erros não interrompam seu trabalho.

A longo prazo, onde os streams se encaixam no roteiro do MultiChain? Dando um passo para trás, o MultiChain agora oferece três áreas de funcionalidade de alto nível:

  • Permissões para controlar quem pode conectar, transacionar, criar ativos / fluxos, minerar / validar e administrar.
  • Ativos incluindo emissão, reemissão, transferência, troca atômica, garantia e destruição.
  • Streams com APIs para criar fluxos, escrever, assinar, indexar e recuperar.

Após o lançamento do MultiChain 1.0 (e uma versão premium), o que vem a seguir nesta lista? Se você olhar para o Comando API que é usado para criar fluxos, você notará um parâmetro aparentemente supérfluo, com um valor fixo de stream. Este parâmetro permitirá que MultiChain suporte outros tipos de entidade de alto nível no futuro.

Os possíveis valores futuros para o parâmetro incluem evm (para um Ethereum-máquina virtual compatível), sql (para um banco de dados no estilo SQL) ou mesmo wiki (para texto editado colaborativamente). Qualquer entidade compartilhada cujo estado é determinado por uma série ordenada de mudanças é um candidato potencial. Cada uma dessas entidades precisará de: (a) APIs que fornecem a abstração correta para atualizar seu estado, (b) mecanismos apropriados para os nós assinados para rastrear esse estado e (c) APIs para recuperar de forma eficiente parte ou todo o estado. Estamos esperando para saber quais outras entidades de alto nível seriam mais úteis, para serem implementadas por nós ou por terceiros por meio de uma arquitetura de plug-in.

E os contratos inteligentes?

Em um sentido geral, MultiChain adota a abordagem em que dados, está embutido imutavelmente em um blockchain, mas o código para interpretar esses dados estão no nó ou na camada de aplicativo. Isso é deliberadamente diferente do paradigma dos “contratos inteligentes”, como exemplificado por Ethereum, no qual o código é embutido no blockchain e executado em uma máquina virtual. Em teoria, porque os contratos inteligentes são Turing completo, eles podem reproduzir o comportamento do MultiChain ou de qualquer outra plataforma de blockchain. Na prática, no entanto, os contratos inteligentes do tipo Ethereum têm muitas deficiências dolorosas:

  • Cada nó deve realizar todos os cálculos, sejam eles de interesse ou não. Por outro lado, no MultiChain, cada nó decide quais streams assinar e pode ignorar os dados contidos por outros.
  • A máquina virtual usada para contratos inteligentes tem um desempenho drasticamente pior do que o código que foi compilado nativamente para uma determinada arquitetura de computador.
  • O código de contrato inteligente é imutavelmente integrado em uma cadeia, evitando que recursos sejam adicionados e bugs corrigidos. Isso foi demonstrado com força no morte do DAO.
  • Transações enviadas para um contrato inteligente não pode atualizar o estado de uma blockchain até que sua ordem final seja conhecida, devido à natureza da computação de propósito geral. Isso leva a atrasos (até que uma transação seja confirmada em um bloco), bem como a possíveis reversões (no caso de uma bifurcação na cadeia). Por outro lado, MultiChain pode tratar cada tipo de transação não confirmada da maneira apropriada: (a) os ativos de entrada atualizam imediatamente o saldo não confirmado de um nó, (b) os itens de fluxo de entrada estão instantaneamente disponíveis, com sua ordem global posteriormente finalizada, (c) mudanças de permissões são aplicados imediatamente e depois reproduzidos nos blocos de entrada.

No entanto, como eu tenho disse antes, certamente não descartamos os contratos inteligentes como um paradigma útil para aplicativos de blockchain, se e quando vemos casos de uso fortes. No entanto, no MultiChain, os contratos inteligentes seriam implementados em uma camada semelhante a um fluxo no topo do blockchain, ao invés do nível de transação mais baixo. Isso preservará o desempenho superior do MultiChain para entidades de blockchain mais simples, como ativos e fluxos, enquanto oferece computação on-chain mais lenta onde é realmente necessário. Mas existem menos casos assim do que você imagina.

 

Por favor, poste comentários no LinkedIn.

 

Adendo Técnico

Todos os comandos relacionados a streams são documentados integralmente no Página da API MultiChain, mas aqui está um breve resumo:

  • Crie um stream usando create stream or createfrom ... stream
  • Adicionar um item a um fluxo com publish or publishfrom
  • Recupere uma lista de streams usando liststreams
  • Comece ou pare de rastrear um stream com subscribe e unsubscribe
  • Recupere itens de fluxo usando liststreamitems, liststreamkeyitems e liststreampublisheritems
  • Listar chaves de stream e editores com liststreamkeys e liststreampublishers
  • Para grandes itens de fluxo, recupere os dados completos usando gettxoutdata (Vejo maxshowndata abaixo)
  • Controle as permissões por transmissão com chamadas como grant [address] stream1.write
  • Ver as permissões de um stream usando listpermissions stream1.*

Algumas outras notas do desenvolvedor relacionadas a streams:

  • A create permissão permite que um endereço crie fluxos.
  • Permissões relevantes por transmissão são write, admin e activate
  • Novo parâmetros de blockchain: root-stream-name (deixe em branco para nenhum), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
  • Novo parâmetros de tempo de execução: autosubscribe para se inscrever automaticamente em novos fluxos criados e maxshowndata para limitar a quantidade de dados nas respostas da API (consulte gettxoutdata acima).
  • O tamanho máximo dos dados de um item de fluxo é fixado pelo max-std-op-return-size parâmetro blockchain, bem como o menor dos maximum-block-size e max-std-tx-size valores menos algumas centenas de bytes.
  • Nós que usam o formato antigo de carteira não podem se inscrever em streams, e deve ser atualizado.

 

Carimbo de hora:

Mais de Multichain