O que significa ter direitos para persistir dados privados? – IBM Developer

O que significa ter direitos para persistir dados privados?

Este artigo fornece uma revisão rápida do que são coletas de dados privados e explica o que realmente significa ter direitos para persistir dados privados. Especificamente, ele explora a relevância do atributo policy localizado em um documento de definição de coleção e o que esse atributo significa para as organizações na rede.

Coletas de dados privados

As organizações que estão conectadas a uma rede de negócios do Hyperledger Fabric possuem uma caixa de ferramentas de mecanismos de privacidade e confidencialidade à sua disposição. O canal é o mecanismo primário pelo qual as organizações podem compartilhar um livro-razão distribuído e chamar chaincode para transacionar com outros membros. Dentro desse contexto, as coletas de dados privados permitem que o chaincode controle a disseminação dos dados, armazenando dados em “coleções,” que são visíveis apenas para um subconjunto dos membros da rede, preservando, assim, a privacidade dos dados.

Para alavancar uma coleta de dados privados em sua rede de negócios de blockchain, é necessário criar uma definição de coleção que especifique o nome da coleção, juntamente com suas regras de acesso e de retenção:

  • Quem pode persistir dados privados
  • O número mínimo de peers para os quais os dados precisam ser distribuídos, para uma chamada de endosso bem-sucedida
  • O número máximo de peers para os quais os dados precisam ser distribuídos, para uma chamada de endosso bem-sucedida
  • Por quanto tempo (em termos de número de blocos) os dados privados são persistidos no banco de dados privado

Para os propósitos deste artigo, nós estamos mais interessados na propriedade “quem pode persistir dados privados”. Este atributo indica os peers da organização que têm permissão para persistir os dados da coleção. No documento de definição de coleção, o atributo policy declara organizações desse tipo. Por exemplo, dê uma olhada no documento de definição de coleção a seguir:

[
   {
          "name": "pdc_xyz",
          "policy": "OR('Org1MSP.member', 'Org2MSP.member','Org3MSP.member'')",
          "requiredPeerCount": 0,
          "maxPeerCount": 3,
          "blockToLive": 1000000,
          "memberOnlyRead": true
  }
]

A definição de coleção acima indica que os nós de peer que pertencem às organizações Org1, Org2 e Org3 podem persistir os dados de coleção privados denominados pdc_xyz. Agora, o que isso realmente significa?

Cenário de exemplo: AcmeChain

Antes de abordarmos a questão do que significa ter direitos para persistir dados privados, vamos definir um cenário hipotético de exemplo. Digamos que você tenha uma rede de blockchain, a AcmeChain, na qual as quatro organizações a seguir são participantes:

  • Org1
  • Org2
  • Org3
  • Org4

Digamos também que AcmeChain tenha apenas um canal (channel1) e que existam duas coletas de dados privados nesse canal, PDC1 e PDC2, cada uma com os seguintes valores para o atributo policy:

  • PDC1 –> OR('Org1MSP.member', 'Org2MSP.member')
  • PDC2 –> OR('Org3MSP.member', 'Org4MSP.member')

Os atributos de política acima indicam que os peers de Org1 e Org2 podem persistir PDC1, enquanto peers de Org3 e Org4 podem persistir PDC2.

Agora, como você deve saber, assim que uma coleta de dados privados tiver sido criada (o que acontece no momento da instanciação de chaincode), ela estará pronta para ser usada de dentro de seu chaincode. Para ler e gravar dados privados, use as APIs de chaincode a seguir:

  • GetPrivateData("<collection name>", "<key name>")
  • PutPrivateData("<collection name>", "<key name>", <key value>)

Também vamos supor que entre os vários métodos no componente de chaincode, os quatro a seguir estejam presentes:

  • readPDC1(key) — lê, em PDC1, o valor que corresponde ao argumento-chave
  • readPDC2(key) — lê, em PDC2, o valor que corresponde ao argumento-chave
  • writePDC1(key, value) — designa o valor especificado para o argumento-chave e o armazena em PDC1
  • writePDC2(key, value) — designa o valor especificado para o argumento-chave e o armazena em PDC2

Dada a configuração de rede e de chaincode acima, você pode estar pensando que um peer que pertence à Org1 não tem permissão para chamar o método writePDC2(key, value) — e que se ele o fizesse, essa operação falharia e lançaria um erro não autorizado. Esse é um equívoco comum que temos visto com certa frequência: o campo policy em uma definição de coleção especifica quais organizações têm permissão para chamar o método PutPrivateData("<collection name>", "<key name>", <key value>) para persistir dados privados. No entanto, esse não é o caso.

Em vez disso, o chaincode em execução em quaisquer peers, independentemente da organização à qual o peer pertence, pode chamar o método PutPrivateData("<collection name>", "<key name>", <key value>) para gravar dados privados em qualquer coleta de dados em um canal com permissões. Por exemplo, em AcmeChain, um peer que pertence à Org1 ou Org2 certamente pode chamar o método writePDC2(key, value) para gravar dados privados no PDC2 sem que um erro seja lançado. Em outras palavras, qualquer chaincode em qualquer peer na rede AcmeChain pode gravar em qualquer coleta de dados privados que exista no channel1.

Agora, você pode estar imaginando: o comportamento acima não contradiz a política especificada na definição de coleção? Embora à primeira vista isso possa parecer ser o caso, não é. A primeira coisa a saber é que o chaincode nunca grava diretamente em uma coleção. Em vez disso, o peer armazena os dados em um banco de dados temporário, aguardando o evento de confirmação ocorrer. Quando esse evento de confirmação é recebido, o peer usa o protocolo gossip para distribuir os dados transientes para os peers de âncora da organização especificados pela policy. Embora qualquer um dos peers que pertençam a Org1 ou Org2 possam gravar dados privados em PDC2, eles não podem persistir PDC2 como um banco de dados auxiliar em qualquer um de seus peers.

A segunda coisa a saber é que, embora as operações de gravação nunca sejam aplicadas diretamente às coleções, o chaincode pode emitir leituras com relação a uma coleção. Como resultado, se qualquer um dos peers que pertencem a Org1 ou Org2 chamasse o método readPDC2(key), essa operação falharia, pois eles não podem ler de um armazenamento de dados que eles não possuem.

Considerações-chave

Embora possa parecer que quaisquer organizações podem gravar qualquer coisa em qualquer lugar, esse de fato não é o caso. Há alguns aspectos importantes a serem considerados neste modelo:

  • O chaincode determina quais coleções usar — Como o chaincode é controlado no nível da rede, as organizações têm a oportunidade de revisar o código antes de instalar em seus peers. Elas podem entender como as coleções serão gerenciadas.
  • Uma política de endosso de duas ou mais organizações assegura que ninguém possa falsificar uma transação — Ter duas ou mais organizações executando o chaincode e assinando os resultados reduz a probabilidade de um esforço conjunto para manipular os resultados.
  • Isso coloca a responsabilidade sobre o aplicativo cliente para chamar o chaincode da organização correta — Se o cliente cometer um erro, o chaincode ainda assegurará que a organização correta receba os dados corretos, mas os dados privados poderão residir temporariamente em outro banco de dados temporário do peer da organização.

Vale destacar que no Hyperledger Fabric v2.0 haverá alguns novos recursos que aprimorarão ainda mais as coletas de dados privados:

  • memberOnlyWrite — Se suas necessidades de negócios tornam esse comportamento atual indesejado, isso permitirá alterar o comportamento descrito neste artigo. A configuração desse atributo como true evitará que peers da organização que não estão incluídos no atributo policy gravem dados privados na coleção. Em outras palavras, se memberOnlyWrite estiver configurado como true, apenas peers da organização especificados no atributo policy terão permissão para chamar o método PutPrivateData("<collection name>", "<key name>", <key value>).
  • Eventos de dados privados — Um mecanismo poderoso do Hyperledger Fabric é a capacidade de atender eventos na rede para permitir que aplicativos reajam a situações específicas. Até esse recurso ser introduzido, os aplicativos clientes podiam receber eventos de bloqueio ou transação, mas eles eram comuns a todos os membros da rede. Desse modo, o cliente precisava reclassificar para consultar a coleção por meio do chaincode para descobrir sobre novos eventos. Esse novo recurso permite que as organizações dentro da policy recebam eventos de dados privados para que elas possam ser notificadas diretamente.

Dadas as necessidades de negócios de várias organizações que estão criando soluções de blockchain corporativas com o Hyperledger Fabric, o objetivo de design inicial da equipe de desenvolvimento do Fabric foi fornecer ao chaincode a capacidade de gravar na coleta de dados privados de qualquer organização. Por exemplo, esse recurso permite o compartilhamento de um ativo a partir da coleção unilateral de uma organização com a coleção de outra organização. A organização destinatária pode, então, calcular o valor do hash do ativo compartilhado, confirmar se ele corresponde ao valor do hash no livro-razão e, em seguida, continuar com uma transação pendente que ela possa ter com a outra organização (emissora).

Então…

Experimente! Comece com o tutorial do Fabric sobre coleta de dados privados e veja como essa nova abordagem pode ser aplicada ao seu caso de uso.