Autor: Hartwig Mayer, 10 de outubro de 2019

Introdução: Confirmação do Problema

Os blockchains públicos permitem a inserção de dados arbitrários. Até mesmo blockchains de propósito específico, como o Bitcoin, já contêm muitos dados não financeiros. Embora essa inserção de dados possa ser benéfica em alguns casos de uso (por exemplo, Proof of Existence – PoE), ela também pode causar danos. Se uma blockchain contivesse vídeos com instruções sobre como torturar alguém, haveria imediatamente um consenso geral de que esses dados deveriam ser excluídos. Mas, como os blockchains devem ser bancos de dados imutáveis, a questão é: o que pode ser feito se isso acontecer?

Em nosso artigo anterior (Imutabilidade: existe um limite?) Discutimos a inserção de dados não financeiros em blockchains de uma perspectiva diferente. O exemplo foi um relatório publicado contendo informações importantes para a sociedade, mas que incomodam um pequeno grupo de pessoas. A análise mostrou métodos realistas de censura de dados do blockchain, explorando vulnerabilidades e limitações conhecidas desta tecnologia. Em um cenário, a censura é desejável e em outro não.

Nas páginas a seguir revisamos dois artigos que propõem formas de apagar dados quando há amplo consenso, sem ter que reiniciar o sistema e sem colocar em risco toda o blockchain. Os artigos em revisão são Apagando Dados de Nodes Blockchain [BF19] e Blockchain redutível na configuração sem permissão [DM19].

Outra estratégia evita tais situações filtrando os dados antes que eles entrem no blockchain. O artigo [HH18b] pesquisa quais informações não financeiras já entraram no blockchain do Bitcoin. Também revisamos o artigo Impedindo a Inserção Indesejada de Conteúdo da Blockchain [HH18a], que discute métodos para impedir a inserção de dados não financeiros.

Projetos de Blockchain Editáveis

Blockchains criam uma sequência de blocos de dados em que o conteúdo de cada bloco é bloqueado por seu sucessor (consulte a Figura 1).

Blockchains têm dois elementos principais para atingir esse tipo de bloqueio:

1. Uma rede que segue um protocolo para armazenar, manter e compartilhar as informações do blockchain com novos pares.

2. Uma função que é resistente à colisão: uma função H para a qual é (quase) impossível encontrar dois blocos diferentes B, B ‘que são mapeados para a mesma saída, ou seja, H (B) = H (B’).

As funções de hash são usadas para bloquear os blocos juntos, o que explica a terminologia comum: BlockHash para o hash H (B) do bloco B e PrevBlockHash para o hash do bloco anterior (consulte a Figura 2). O conteúdo do bloco Bi-1 é bloqueado para si mesmo incluindo H (Bi-1) para seu sucessor Bi. Se alguém edita / suprime o bloco Bi-1 resultando em um novo bloco B ‘, então todos os pares, novos e antigos, podem notar essa mudança, já que o cálculo de BlockHash H (B’) não coincidiria com o valor PrevBlockHash H (Bi-1) no bloco Bi.

Uma abordagem para a edição do blockchain é por meio de uma função que permite que um grupo específico de usuários produza colisões. O artigo [AM17] interrompe essa abordagem em que uma parte de um trapdoor (função armadilha) é fornecida a cada membro do grupo. Todo o grupo deve consentir em desbloquear as conexões e redigir o bloqueio. Isso só funciona bem para casos de uso especiais. Conforme mencionado no artigo [DM19], o método da chave trapdoor é insuficiente para redes como a rede Bitcoin: ele não pode ser dimensionado para grandes redes e apenas os detentores da chave trapdoor estão cientes dos dados alterados, reduzindo a transparência.

Nas páginas seguintes, revisamos e comparamos os artigos [BF19] e [DM19], que apresentam um mecanismo de edição para a rede Bitcoin. Sua contribuição está na modificação do primeiro elemento para o “bloqueio” entre os blocos, introduzindo outra camada de comunicação entre os nodes da rede. Ambos fazem uso do fato de que os servidores de node completo têm o blockchain inteiro e podem suprimir sua cópia armazenada localmente do livro-razão, uma prática já usada para apagar partes antigas do blockchain para redução de armazenamento.

Apagando Dados de Nodes Blockchain

Visão Geral da Proposta

Os autores de [BF19] sugerem alterar o protocolo de rede para tornar possível o apagamento de dados. Os nodes da rede marcam os dados que devem ser apagados em seu banco de dados de eliminação local (semelhante ao banco de dados chainstate no cliente Bitcoind) antes de excluir os dados de sua cópia do blockchain. Dessa forma, fica garantida a responsabilidade pelos dados apagados, necessária para evitar a solicitação desses dados novamente a outros nodes e para diferenciar entre dados inexistentes e apagados. A mudança de protocolo proposta sugere uma política de validação de transação para os nodes quando eles se deparam com uma transação referente aos dados que eles apagaram de sua cópia local do blockchain. A política é baseada na mesma ideia do método de verificação de pagamento simplificado. Para obter mais detalhes, consulte a seção Detalhes de Protocolo de Eliminação de Dados de Nodes de Blockchain.

Escopo da Pesquisa

A proposta funciona em geral para qualquer blockchain baseada no modelo UTXO que inclua o modelo Bitcoin. A mudança de protocolo proposta não atrapalha a funcionalidade de todo o sistema blockchain e pode ser implantada sem intervir na arquitetura central do blockchain. A pesquisa não inclui um mecanismo descentralizado para encontrar consenso sobre quais dados devem ser removidos. Os autores demonstram a viabilidade da proposta por meio de uma implementação de prova de conceito utilizando o software Bitcoind para participação na rede Bitcoin.

Resumo das Limitações

Os autores de [BF19] apresentam uma maneira interessante e muito pragmática de apagar dados em blockchains, mas a proposta atual vem com certas limitações:

Resumo das Limitações

A proposta não cobre a eliminação de todos os métodos de inserção de dados possíveis discutidos na pesquisa [SSV19]. O foco é definido apenas em um campo de dados, isto é, os dados de saída da transação scriptPubKey (para obter mais detalhes, consulte Detalhes do Protocolo para Apagar Dados).

A proposta não inclui um mecanismo de consenso descentralizado para chegar a um acordo e responsabilidade sobre a eliminação de dados específicos. Em vez disso, o consenso é alcançado fora da cadeia e a responsabilidade é gerenciada localmente. Por exemplo, através da publicação em uma página da web as identidades de transação a serem apagadas e os nodes atualizam seu banco de dados de eliminação localmente.

Limitações de compatibilidade

Os nodes que não estão atualizando seu software para essas alterações recentemente propostas, ocasionalmente divergirão dos nodes que executam o software atualizado. Portanto, o novo protocolo de validação deve ser introduzido como um soft fork.

Limitações de Segurança

A mudança de protocolo proposta aumenta a probabilidade de forks de blockchain que impactam a segurança de todo o sistema (ver [GK16]). Embora os forks só possam ser criados por um usuário desonesto, isso abre um novo vetor de ataque. Um estudo formal das implicações de segurança está faltando.

A validação de cadeia refere-se ao processo que os nodes de rede novos ou fora de sincronia executam para garantir que as informações de blockchain recebidas sejam realmente válidas. A eliminação de dados torna impossível para novos nodes validar a cadeia, uma vez que os dados apagados estão faltando para calcular e verificar o valor da BlockHash.

Limitações da implementação de Proof of Concept

Suas restrições atuais de implementação são devido ao uso da lógica de eliminação de lixo existente do software cliente Bitcoind:

• Mais dados são apagados além de apenas o arquivo de dados indesejados, ou seja, todos os blocos até a altura do alvo/objetivo. Portanto, os nodes que apagam dados não serão mais nodes completos arquivando e indexando o blockchain completo.
• O apagamento completo pode ser feito não antes de aproximadamente 50 horas após o conteúdo ter sido incluído na cadeia ativa devido à lógica de remoção do Bitcoind.
• Sugere-se evitar o uso do protocolo no modo de mineração, pois pode causar forks de blockchain. Portanto, a rede ainda terá muitos nodes completos, ou seja, nodes de mineração, que ainda disponibilizarão os dados apagados por meio de suas cópias locais.

• A implementação da prova de conceito é ainda mais restrita a saídas de transações que não são transações SegWit.

Blockchain editável na configuração não permissionada

Visão geral da proposta

Os autores do segundo artigo [DM19] propõem um método seguro para o apagamento de dados. Os nodes da rede podem propor a edição de campos de dados armazenados no blockchain. Para que esta proposta seja aprovada, uma política de validação especificada deve ser seguida, que inclui que a maioria dos nodes da rede votem nas propostas dentro de um determinado período de tempo. A validação da cadeia e do bloco é modificada para capturar os blocos editados.

Escopo da Pesquisa

A proposta pode ser aplicada a blockchains baseada em Proof of Work (PoW) e pode ser facilmente adaptada a qualquer mecanismo de consenso. A proposta requer mudanças do protocolo blockchain principal. Ele introduz um mecanismo de votação descentralizado usando a infraestrutura blockchain disponível para decidir quais dados devem ser apagados. Como um subproduto, todas as informações sobre as edições do blockchain são escritas de forma transparente no livro-razão. A pesquisa inclui uma análise de segurança formal rigorosa e fornece uma implementação de prova de conceito para demonstrar a viabilidade da proposta.

Resumo das Limitações

Os autores de [DM19] apresentam um método interessante e comprovado como seguro para o apagamento de dados em blockchains.

Limitações Funcionais

A proposta permite alterar apenas os componentes das transações que não afetam a consistência de eventos passados ​​e futuros, por ex. OP_RETURN em Bitcoin. Este formulário, não abrange todos os métodos de inserção de dados (ver [SSV19]), por ex. a saída da transação PaytoPublicKeyHash (P2PKH), que é um componente que pode ser gasto, embora se usado para dados arbitrários, não pode ser gasto. Esta restrição não se deve a razões técnicas, mas para proteger os usuários de eventuais inconsistências futuras no blockchain. De qualquer forma, essas restrições podem ser ajustadas. É mais um mecanismo para remover a responsabilidade do usuário em decidir quais novas edições/redações podem causar inconsistências na cadeia no futuro.

Limitações de compatibilidade

A proposta requer que os nodes da rede modifiquem seu software para executar o protocolo aprimorado. Em particular, a estrutura do bloco Bitcoin deve acomodar outro campo (para obter mais informações, consulte a seção Detalhes de Protocolo para Blockchains Editáveis). Isso exigiria um hard fork da blockchain do Bitcoin e, portanto, o apoio de toda a comunidade.

Limitações de Segurança

Existe um risco aumentado de Ataque de Negação de Serviço (DoS), uma vez que mineradores mal-intencionados podem incluir muitas solicitações de edição para diminuir o desempenho geral do sistema.

Desempenho

O protocolo aprimorado produz uma nova sobrecarga devido à votação e validação adicionais para transações editadas, mas os testes de sua implementação de prova de conceito mostram que a sobrecarga adicional é muito pequena.

Limitações da implementação da Proof of Concept

A implementação da Proof of Concept está em um ambiente de teste que imita todas as funcionalidades básicas do Bitcoin. Inclui a linguagem de script Bitcoin que permite inserir dados arbitrários na cadeia, que podem ser editados posteriormente. Um teste na rede Bitcoin atual não é viável, pois isso exigiria que todos os nodes atualizassem seus softwares.

Comparação

Na Tabela 1, resumimos as limitações e pontos fortes de ambas as propostas para a blockchain do Bitcoin medindo-os em relação às seguintes métricas:

Limitações Funcionais

• Faixa de dados editáveis: o mecanismo de edição cobre todo o espectro de possíveis componentes de inserção de dados?

• Votação descentralizada: o protocolo fornece um sistema descentralizado para propor e votar em solicitações de edição?

Limitações de compatibilidade

• Fácil Adoção de Protocolo: A mudança de protocolo requer suporte apenas da comunidade (Sim) ou também requer uma mudança na arquitetura central do blockchain (Não)?

Limitações de Segurança

• Responsabilidade: o protocolo fornece um método seguro e transparente para contabilizar todas as solicitações aprovadas de edição?

• Análise de Segurança: Não há análise de segurança (Baixa), há uma discussão sobre segurança (Média) e há uma análise de segurança formal (Alta).

Desempenho

• Escalabilidade: A mudança de protocolo mantém a sobrecarga computacional estável quando comparada à versão original do blockchain (Sim – Moderado – Não)?

• Crescimento moderado do Blockchain: A alteração do protocolo mantém o crescimento do tamanho da blockchain semelhante à versão original da blockchain? (Sim – Moderado – Não)

Prevenção de inserção de dados indesejados

Impedindo a inserção indesejada de conteúdo no blockchain

Visão geral da proposta e escopo da pesquisa

Os autores do artigo [HH18a] analisam métodos de filtragem de conteúdo tendo o Bitcoin como principal exemplo. Eles primeiro identificam o padrão de transações que transportam dados indesejados e, em seguida, propõem contramedidas contra a inserção de dados indesejados:

1. Detectores de conteúdo: transações com dados de grande porte que transportam muitas saídas de transação com texto geram sinais positivos, o que resulta na exclusão dessas transações em blocos durante a geração de blocos.

2. Incentivos econômicos: Uma política de taxas de transação, que aumenta a taxa de acordo com o tamanho dos dados da transação. Isso torna o sistema menos atraente para a inserção de dados não financeiros, visto que eles deveriam ser grandes, enquanto as transações financeiras padrão permanecem “baratas”.

Por fim, os autores propõem Compromissos de Identificador (Cis) – uma nova ferramenta de criptografia que permite que nodes completos verifiquem se os endereços do receptor na saída da transação são endereços válidos ou dados arbitrários. Isso permite identificar e descartar transações com dados prejudiciais durante a geração do bloco. No protocolo Bitcoin atual, apenas quando as transações são gastas, os nodes verificam a validade do endereço do receptor, mas a essa altura eles já fazem parte do blockchain.

Resumo das Limitações

Limitações Funcionais

Os detectores de conteúdo não podem capturar todos os dados indesejados, por exemplo, impedir a inserção de arquivos binários não é viável por meio desta abordagem.

Da mesma forma, a introdução de incentivos econômicos não impede todos os casos. Não está claro qual deve ser o preço de publicação em Bitcoin para evitar qualquer inserção de dados indesejados no blockchain. Qual é o preço de prejudicar a reputação de outra pessoa ou mostrar qualquer tipo de dado prejudicial?

Limitações de compatibilidade

Ambos os métodos de filtragem são fáceis de implantar. A introdução de ICs requer que os nodes da rede modifiquem o software do blockchain para participar com o novo protocolo. Isso requer que toda a comunidade apoie a mudança de protocolo.

Desempenho

A introdução de ICs implica que os nodes de validação têm mais trabalho computacional a realizar, mas o overhead computacional é mínimo.

Detalhes e análise do protocolo

Lembrete do formato de transação Bitcoin

Uma transação T possui dados de entrada e saída, bem como um identificador de transação iT (TxID) – o hash da transação T. Os dados de entrada (prevOut) fazem referência a transações anteriores usando o TxID (consulte a Figura 3). O remetente deve fornecer uma prova de autenticação para gastar esta entrada (ScriptSig) e ele deve especificar nos dados de saída o valor da transação (Valor) e o endereço do destinatário (scriptPubKey).

Detalhes de Protocolo de Apagamento de Dados de Nodes de Blockchain

O protocolo proposto [BF19] permite apenas apagar dados indesejados armazenados no campo de dados de saída scriptPubKey. Os nodes executam as seguintes etapas:

1. Apague os dados X de uma transação T com TxID iTresultando em uma transação T ‘.

2. Armazene T ’em um banco de dados de apagamento junto com o identificador iT.

3. Apague fisicamente T da cópia local do blockchain.

Apagar dados do blockchain pode causar problemas ao validar transações referentes a dados apagados. A política proposta é a seguinte:

1. As transações não confirmadas, ou seja, as transações que ainda não fazem parte do blockchain, mas apenas “fofocadas” entre os nodes da rede para inclusão no próximo bloco, são sempre consideradas inválidas e não são comunicadas a outros pares se fizerem referência a dados apagados.

2. As transações confirmadas, ou seja, as transações já aprovadas pela rede e que fazem parte do blockchain, são sempre consideradas válidas, mesmo que façam referência a dados apagados.

Análise de Apagamento de Dados de Nodes de Blockchain

Para facilitar a exposição, usamos os termos nodes honestos para nodes que seguem o antigo protocolo de validação e nodes de apagamento para nodes que apagam dados e seguem a nova política de validação aprimorada. Tanto os nodes honestos quanto os nodes apagadores são “honestos” em oposição aos nodes desonestos, que não seguem um protocolo específico o tempo todo.

Observação 1

A nova política de validação não afeta a segurança do blockchain quando aplicada a transações não confirmadas. Os problemas surgem quando o blockchain contém transações confirmadas com uma referência a dados de saída mais antigos que eram dados arbitrários e não um endereço de receptor válido. Observe que isso só pode acontecer quando a transação foi explorada por um node desonesto ou um node não validador (um node que não válida para recursos seguros e corre o risco de perder a recompensa do bloco). Tais transações são transações inválidas devido aos dados de entrada incorretos e não são incluídas nas propostas de bloco nem por nodes honestos nem apagadores. Por este motivo, a ocorrência de transações confirmadas com dados apagados não é frequente, mas a possibilidade não pode ser excluída uma vez que pode ser produzida por mineiros desonestos dependendo do seu poder de mineração.

Como mencionado no artigo, nesses casos, haverá um desacordo sobre a validade de tais transações entre nodes honestos e apagadores da rede. Dependendo de qual grupo supera o outro, as transações são finalmente consideradas como inválidas ou válidas. Isso leva aos seguintes novos riscos adicionais em comparação com o protocolo original (Bitcoin):

Maior número de forks:

Discordâncias sobre a validade de transações específicas entre nodes honestos e de apagamento são refletidas como “forks” no blockchain. Normalmente, estas bifurcações aparecem devido a atrasos na comunicação da rede, resultando em uma falta de sincronização entre os nodes. Em muitos protocolos de blockchain, a regra da cadeia mais longa ajuda os mineiros a se reconciliarem após uma bifurcação indesejada: a cadeia mais longa é a válida. Isso também acarreta problemas de segurança, como ataques de gasto duplo que são bifurcações intencionais. Este tópico é bem estudado em [GK16]. A política de validação aprimorada proposta em [BF19] aumenta as chances de desacordos temporais que podem ser explorados por nodes desonestos, embora mais estudos sobre as implicações de segurança sejam necessários.

Explorando forks:

A análise de risco em [BF19] considera dois casos: 1) Os nodes de apagamento formam a minoria. 2) Os nodes de apagamento constituem a maioria. A análise não reflete a estabilidade do sistema quanto a sua dependência da porcentagem de nodes desonestos. Por exemplo, se assumirmos que 15% da rede é desonesta e os nodes de apagamento formam uma minoria de 36%, uma transação confirmada com referência a dados apagados pode fazer parte da cadeia mais longa (ou seja, considerada válida), dependendo da decisão da parte desonesta.

Soft Forks:

Além disso, neste caso, a situação é diferente de ataques de gasto duplo em que duas cadeias válidas são apresentadas e a regra da cadeia mais longa decide qual é a correta. Aqui, os mineiros honestos, que não apagam os dados indesejados, considerarão a cadeia mais longa como uma cadeia inválida quando um node de apagamento minar um bloco com uma referência aos dados apagados. Isso leva a uma “divisão” permanente da rede se houver uma maioria de nodes de apagamento, não apenas uma bifurcação temporal, uma vez que nodes honestos não seguem o protocolo dos nodes de apagamento. Isso implica que a proposta deve ser apresentada como um soft fork. Vemos isso como um problema, desde que o banco de dados apagado seja mantido localmente e não haja uma visão comum sobre esse banco de dados.

Observação: Se supormos que 100% da comunidade concorda com quais dados devem ser removidos e apagados de suas cópias locais, então não há risco de forks adicionais. No entanto, isso exigiria um bom sistema de responsabilidade, onde todos os usuários vissem e agissem com base nas informações. O cenário de consenso total é difícil de imaginar, dada a diversidade cultural e geográfica dentro de qualquer comunidade de blockchain.

Observação 2:

Bootstrapping:

Outro grande risco é a validação da cadeia insegura durante o bootstrapping. O blockchain do Bitcoin tem um método muito seguro para isso que é resistente a Sybil (usando a cadeia mais longa). Como a validação da cadeia requer todos os dados que constituem o blockchain, o apagamento torna a validação da cadeia impossível. Isso pode ser resolvido deixando todos os nodes da rede ou armazenando os dados relevantes em um banco de dados central que novos nodes podem consultar para validar a cadeia. No primeiro caso, os dados indesejados ainda estarão acessíveis a todos, enquanto a segunda solução leva a uma centralização muito forte com todos os riscos implícitos, por exemplo, ponto único de falha, mau uso de energia, etc. Portanto, os autores começaram a definir um método sem confiança para bootstrapping que ainda não foi completamente descrito.

Detalhes de protocolo para blockchain editável

O protocolo do [DM19] tem três componentes: Proposta de edição, validação da proposta e validação de bloco e cadeia. Para contabilizar as edições, o cabeçalho do bloco (consulte a Figura 1) deve acomodar um campo adicional chamado old_MerkleRoot: Todos os blocos contêm uma lista de transações e um compromisso com esse conjunto de transações usando seu MerkleRoot. Quando um bloco é inicialmente criado, ou seja, antes de qualquer edição, este novo campo assume o mesmo valor da raiz Merkle. Se uma edição for aprovada, este campo será atualizado, enquanto old_MerkleRoot armazenará a raiz Merkle antiga para fornecer uma conta transparente no histórico de edição.

Proposta de Edição

Os usuários que desejam propor uma edição constroem uma transação especial editTx que contém a transação original T com seu identificador de transação iT e a transação editada T ’. Em seguida, os nodes transmitem a transação especial editTx que requer uma taxa de transação como de costume. A transação proposta T ‘é validada verificando seu conteúdo em relação a T, e se for válida, pode ser considerada para votação.

Validação da Proposta

O novo protocolo de validação dita os requisitos e restrições para operações de edição no blockchain. Os autores fornecem uma descrição formal e uma descrição informal de uma política (básica) para Bitcoin que poderia ser implementada, que citamos aqui:

• A edição proposta T ‘é idêntica à transação T, exceto que pode remover dados.

• Apenas dados que nunca serão gastos, por exemplo, scripts de saída OP RETURN, podem ser removidos.

• Nenhuma edição de votos pode ser proposta para outras edições na cadeia.

• A edição proposta recebe mais de 50% dos votos nos 1024 blocos consecutivos (período de votação) após o editTx correspondente estar estável na cadeia.

Após uma votação bem-sucedida, os nodes substituem em seu livro razão local a transação T por (iT, T ‘).

Validação de bloco e corrente (block and chain)

Quando os nodes têm que validar um bloco contendo uma transação editada, o node pode verificar se a transação original T estava lá antes e agora é substituída por T ‘. A verificação da primeira parte faz uso do identificador de transação iT e old_MerkleRoot (árvores de Merkle), enquanto a segunda parte é processada localizando o editTx correspondente na cadeia e verificando se a solicitação de edição satisfaz a política de validação.

Quando os nodes precisam validar uma cadeia completa e encontrar um bloco editado, o minerador verifica se a edição foi aprovada. O minerador rejeita uma cadeia como inválida se qualquer um dos seguintes ocorrer: (1) a edição de um bloco não foi aprovada de acordo com a política, (2) o valor MerkleRoot do bloco redigido está incorreto em relação ao conjunto de transações ou (3) uma edição aprovada anteriormente não foi realizada na cadeia.

Análise de Blockchain Editável

Observação 1

Ataque de Negação de Serviço – DoS (Denial of Service Attacks):

Enviar spam para a rede com muitas solicitações de edição pode levar à negação do serviço. No entanto, conforme mencionado no artigo, os mineiros são dissuadidos de fazer isso porque isso incorre no custo de uma taxa de transação para as solicitações de edição. Além disso, uma taxa de transação mais alta para solicitações de edição pode ajudar ainda mais a proteger o sistema contra esse tipo de ataque. De qualquer forma, existem técnicas mais refinadas, conforme listadas aqui, para proteger a rede.

Observação 2

Aumento da sobrecarga computacional:

A votação, a validação de proposta adicional e o protocolo aprimorado para validação de bloco e cadeia aumentam a sobrecarga computacional que os nodes precisam realizar. No entanto, conforme estimado pelos autores usando sua implementação de Proof of Concept, o cálculo extra não deve ser considerado crítico.

Observação 3

Escopo da análise de segurança:

O modelo de segurança de [GKL15] é usado para provar formalmente que as alterações de protocolo propostas não estão afetando a segurança do blockchain. Este modelo de segurança se aplica aos blockchain públicos, incluindo o blockchain do Bitcoin. Embora, por exemplo, o protocolo de Proof of Stake – (PoS) de Ouroboros se baseie nesse artigo, as considerações teóricas do jogo são feitas separadamente. Uma investigação mais aprofundada deve ser feita para saber se a introdução de um mecanismo de edição (com uma política que permita redigir mais componentes da transação) permite ou não outras estratégias racionais com recompensa maior do que a honesta.

Detalhes do protocolo para impedir a inserção de conteúdo indesejado

Detectores e filtragem de conteúdo

Os autores descobriram que quase a totalidade das aproximadas 255 milhões de transações em Bitcoin (em agosto de 2017) tinham no máximo 50 saídas de transações (99,73%). Além disso, de todas as transações, 97,22% têm no máximo 5 saídas e 91,77% têm no máximo 2 saídas. Em contraste, a inserção de dados arbitrários usa mais de 50 saídas de transação devido ao tamanho limitado dos dados nos campos de saída e, portanto, podem ser detectados por meio de seu tamanho maior.

O primeiro método de filtragem detecta se as transações contêm texto, arquivos baseados em ASCII ou quaisquer arquivos binários de imagens ou arquivos. Além disso, os autores apresentam um detector que fornece sinais positivos quando uma transação contém muitos caracteres ASCII imprimíveis distribuídos em muitas (por exemplo, mais de 50) saídas de transação.

O segundo método de filtragem propõe uma taxa mínima obrigatória para penalizar grandes transações. A fórmula para calcular a taxa obrigatória considera o tamanho da transação e o número de saídas, e tem o objetivo de desestimular a inserção de conteúdo não financeiro.

Mudança de protocolo: compromissos do identificador (Indentifier Commitments – IC)

Identifier Commitments (IC) ajudam a evitar a inserção arbitrária de dados colocados nos campos de dados de saída de uma transação. A ideia básica deste conceito consiste em não enviar o endereço público do destinatário no blockchain – que pode conter dados nocivos em vez de um endereço -, mas sim um dado diferente que impede a inserção de dados não financeiros e funciona como endereço do destinatário. Referimo-nos a [HH18a] para mais detalhes sobre a solução técnica.

Análise de como impedir a inserção de conteúdo indesejado

Observação 1

Detector de conteúdo:

O método de filtragem, proposto com base em arquivos de dados de grande porte também pode causar falsos positivos. A alta qualidade de filtragem pode penalizar algumas transações honestas de grande porte, por exemplo, emitido por trocas de criptografia ou um pagamento de receita para muitas partes interessadas. O risco de falsos positivos existe, embora os experimentos mostrem alta probabilidade de sinais corretos. A limitação de tais detectores é que eles são incapazes de detectar campos de dados binários que podem transportar dados perigosos codificados. Esta é a motivação dos autores para apresentar ICs.

Observação 2

Incentivos econômicos:

As taxas obrigatórias mínimas podem afetar os pagamentos com muitos resultados, por exemplo, repartições de recompensas para investidores ou pagamentos de serviços de câmbio. O problema aqui é que quanto melhor a proteção contra a inserção de dados prejudiciais, maior será a penalização de algumas transações financeiras.

Observação 3

Compromissos do identificador:

A introdução de ICs requer uma mudança de software a fim de integrar o conceito e permitir um processo de validação aprimorado. Essa mudança pode ser alcançada facilmente, mas precisa do suporte da comunidade do blockchain.

Os ICs ajudam a rejeitar a inserção de dados prejudiciais nos campos de saída das transações, mas deixam outros métodos de inserção de dados possíveis, conforme discutido em [SSV19], ainda em aberto.

A sobrecarga computacional adicional causada pela validação do IC é insignificante. Nodes completos precisam de apenas 4 segundos a mais de acordo com seus experimentos. Esse atraso não é crítico, pois a geração média de blocos leva cerca de 10 minutos. Os ICs aumentam o tamanho geral da transação, mas a economia no armazenamento do blockchain por meio da anulação de dados não financeiros pode superar o tamanho do blockchain aumentado pelos ICs.

Conclusões

Na Tabela 1, resumimos os aspectos gerais dos protocolos [BF19] e [DM19]. De acordo com nossa análise, o primeiro artigo deve fornecer provas de segurança mais fortes, uma vez que a alteração proposta aumenta o número de forks, o que pode reduzir a segurança de todo o sistema de blockchain. Esses forks também podem resultar em divisões permanentes da comunidade. Se todos os nodes seguirem a política de validação proposta em [BF19], esses dois riscos são eliminados. No entanto, é essencial encontrar um método seguro de concordar sobre quais dados devem ser apagados. Além disso, deve haver um registro verificável de dados removidos legitimamente para que a inicialização seja possível. Se esse registro for mantido por uma autoridade central, como os autores de [BF19] sugerem, contradizemos a filosofia blockchain de descentralização. Também é questionável até que ponto e com que rapidez os acordos podem ser alcançados, dada a natureza heterogênea das comunidades de blockchain.

O artigo [DM19] sugere um método para apagar dados do blockchain que requer que a comunidade atualize seu software para executar o novo protocolo. Os autores apresentam uma forte análise de segurança e os únicos pequenos defeitos da proposta são um pequeno risco de um ataque de negação de serviço e uma sobrecarga computacional ligeiramente maior. Gostaríamos de ver uma análise da teoria dos jogos de sua proposta para avaliar o uso indevido potencial das novas regras. Se todos os nodes seguirem o protocolo aprimorado, não haverá risco de segurança e nenhum obstáculo à inicialização. Embora a proposta inclua um mecanismo de votação seguro, é novamente questionável se um acordo sobre dados prejudiciais pode ser alcançado facilmente entre uma comunidade multicultural.

A abordagem do [HH2a] consiste em prevenir a inserção de dados prejudiciais, fazendo uso de detectores de texto e incentivos econômicos. Ambos os métodos melhoram a prevenção, mas falham em excluir totalmente dados prejudiciais. A ferramenta criptográfica proposta ajuda a detectar dados prejudiciais que passam pelos dois primeiros filtros, mas não podem controlar todos os métodos de inserção possíveis.

Referencias

[AM17] G. Ateniese, B. Magri et al.: Redactable Blockchain or Rewriting History in Bitcoin and Friends, IEEE European Symposium on Security and Privacy, 2017.

[BF19] S. Beaucamp, M. Florian, et al.: Erasing Data from Blockchain Nodes, arxiv:1904.08901, 2019. 

[DM19] D. Deuber, B. Magri et al.: Redactable Blockchain in the Permissionless Setting, IEEE Symposium on Security and Privacy, 2019. 

[GK16] A. Gervais, G. K. Karame, et al.: On the Security and Performance of Proof of Work Blockchains, Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016.

[GKL15] J.A. Garay, A. Kiayias, N. Leobardos: The Bitcoin Backbone Protocol: Analysis and Applications, Proc. Eurocrypt, 2015.

[HH18a] M. Henze, J. Hiller, et al.: Thwarting Unwanted Blockchain Content Insertion, IEEE International Conference on Cloud Engineering, 2018. 

[HH18b] M. Henze, J. Hiller, et al.: A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin, in Proc. 22nd International Conference on Financial Cryptography and Data Security, 2018

[M13] G. Maxwell: To Prevent Arbitrary Data Storage in Txouts – The Ultimate Solution, 2013.

[SSV19] F. Stonedahl, A. Sward, I. Vecna: Data Insertion in Bitcoin’s Blockchain, Ledger Journal Vol 3, 2019.

Portrait Image by Brian J. Matis. License creative commons.