Resumo Técnico: Proveniência de Dados em Blockchain Multichain para Processamento de Fluxo Determinístico com Kafka Streams

1. Declaração do Problema

Pipelines de processamento de fluxos de dados em tempo real, como aqueles construídos sobre Kafka Streams ou Apache Flink, enfrentam desafios críticos de auditabilidade e reprodutibilidade. Esses sistemas são inerentemente não determinísticos devido a dependências de agendamento de tempo de execução, gatilhos de janela, jitters de rede e ordens de chegada de registros. Consequentemente, fluxos de entrada idênticos processados em tempos diferentes ou em nós diferentes podem gerar saídas distintas.

Soluções atuais de proveniência baseadas em blockchain geralmente dependem de cadeias de hash para armazenar impressões digitais de dados. No entanto, os autores identificam duas desvantagens principais nessa abordagem para o processamento de fluxo:

1. Sobrecarga de Armazenamento: À medida que a cadeia cresce, os requisitos de armazenamento aumentam significamente.
2. Custo de Computação: A verificação exige o hashing repetido de cadeias longas, o que é ineficiente para grandes conjuntos de dados.
   Além disso, as cadeias de hash vinculam a proveniência à ordem de ingestão, tornando-as inadequadas para o replay determinístico sob janelas baseadas em tempo ou re-chaveamento onde a participação de registros muda devido a fatores externos (ex: rebalanceamento).

2. Metodologia

O artigo propõe uma arquitetura de proveniência apoiada por blockchain que desacopla payloads de dados pesados do blockchain, armazenando apenas âncoras criptográficas e metadados. O sistema é implementado usando Kafka Streams para processamento e MultiChain (um blockchain com permissão) para ancoragem.

Componentes Principais e Fluxo de Trabalho

1. Ingestão e Processamento:

   • Dados meteorológicos em tempo real de duas estações (Berlim-Brandenburg e Berlim-Tempelhof) são ingeridos via Kafka.
   • O sistema utiliza janelas de tumbling alinhadas por época (epoch-aligned tumbling windows). Diferente das janelas de tempo de processamento, estas são intervalos absolutos fixos (ex: blocos de 2 horas começando em tempos de época específicos) para garantir o determinismo global, independentemente de atrasos de ingestão.
   • Dentro de cada janela, os registros são agregados (mínimo, máximo, média de temperaturas).

2. Canonicização Determinística:

   • Para eliminar o não determinismo causado pela ordenação de registros, o sistema aplica JSON Canônico a todos os registros dentro de uma janela.
   • Este processo envolve a remoção de campos inconsistentes, normalização de timestamps para UTC (ISO-8601) e ordenação lexicográfica das chaves dos objetos.
   • Os registros são então deduplicados.

3. Construção da Árvore de Merkle:

   • Em vez de uma cadeia de hash linear, o sistema constrói uma Árvore de Merkle a partir dos registros canonicizados.
   • Os nós folha são hashes SHA-256 dos registros canônicos.
   • Os nós internos são hashes de nós filhos concatenados.
   • A Raiz de Merkle (Merkle Root) final serve como um compromisso criptográfico compacto a todo o payload da janela.

4. Ancoragem em Blockchain (Checkpoints):

   • O payload completo permanece off-chain (armazenado em um sistema de arquivos distribuído como NDJSON).
   • Um checkpoint contendo a Raiz de Merkle, limites de offset do Kafka (offsetStart, offsetEnd), contagem de registros, caminho do payload e hash do payload é publicado em um stream MultiChain.
   • O MultiChain foi escolhido por suas funcionalidades de stream chave-valor append-only e sua natureza com permissão, evitando a complexidade de contratos inteligentes em favor de lógica de aplicação externa.

5. Verificação:

   • Um auditor independente pode verificar a integridade de uma janela:
     1. Recuperando os metadados do checkpoint (Raiz de Merkle $R$ e contagem de registros $N$) do blockchain.
     2. Carregando o payload off-chain.
     3. Re-canonicando os registros e recomputando a Raiz de Merkle ($\hat{R}$) e a contagem de registros ($\hat{N}$).
     4. Comparando $\hat{R}$ com $R$ e $\hat{N}$ com $N$. A verificação passa apenas se ambos coincidirem.

3. Principais Contribuições

• Proveniência de Janela Determinística: A introdução de um método para criar janelas de fluxo reproduzíveis usando fronteiras alinhadas por época e serialização canônica, resolvendo o não determinismo inerente ao processamento de fluxo padrão.
• Árvore de Merkle sobre Cadeias de Hash: Uma mudança de cadeias de hash lineares para árvores de Merkle para proveniência de janelas, reduzindo a complexidade de verificação de linear para logarítmica em relação ao número de registros.
• Divisão On-Chain/Off-Chain: Uma arquitetura escalável onde payloads grandes e mutáveis são armazenados off-chain, enquanto âncoras criptográficas imutáveis (raízes de Merkle) e metadados são armazenados on-chain, evitando o inchaço do blockchain.
• Auditabilidade Independente: Um framework que permite a auditores terceiros verificar a integridade e a correção de análises derivadas (ex: médias de temperatura) sem precisar acessar o estado interno do motor de streaming.

4. Avaliação e Resultados

O sistema foi avaliado utilizando dados meteorológicos em tempo real de Berlim.

• Reproduzibilidade: Execuções independentes em hardware diferente (MacOS M2 e M4) com Java 21 produziram resultados byte a byte idênticos para o JSON canônico, SHA-256 do payload e raízes de Merkle, confirmando a eliminação do não determinismo induzido pelo ambiente.
• Custo de Verificação:
  • O tempo de verificação de ponta a ponta ($T(n)$) escala linearmente com o número de registros ($n$), seguindo o modelo $T(n) = \alpha n + \beta$.
  • O sistema demonstrou alto throughput (registros por segundo) durante a verificação, sem colapso de desempenho conforme o tamanho das janelas aumentava.
  • Os custos de canonicização e hashing mostraram escalonamento linear, e a construção da árvore de Merkle permaneceu próxima da linear.
• Desempenho do Blockchain:
  • O checkpointing no mundo real resultou em baixo TPS (0–0.015 itens/s) devido à natureza infrequente do fechamento de janelas em comparação com as taxas brutas de eventos.
  • O benchmarking com publicadores paralelos mostrou que o MultiChain pode lidar com TPS mais altos (até ~2.1 tx/s para payloads pequenos), mas atinge um ponto de saturação (em torno de 8 workers) devido ao seu algoritmo de consenso round-robin.

5. Significância e Alegações

O artigo afirma que seu design permite que auditores independentes verifiquem três aspectos críticos do processamento de fluxo:

1. A completude dos payloads das janelas (garantindo que nenhum registro foi descartado ou adicionado).
2. A serialização canônica dos dados (garantindo o processamento determinístico).
3. A correção das análises derivadas (ex: verificando se uma temperatura média relatada é matematicamente consistente com os registros subjacentes).

Os autores posicionam este trabalho como uma solução para o "gap de auditabilidade" no processamento de fluxo moderno. Ao combinar o particionamento por janela determinístico com a ancoragem criptográfica, o sistema permite o reprocessamento reproduzível de fluxos de dados, uma capacidade atualmente ausente nas plataformas de streaming padrão. O artigo nota modestamente que, embora resolva integridade e auditabilidade, ainda não aborda o significado semântico dos dados (exigindo trabalhos futuros com RDF) ou preocupações de privacidade (sugerindo provas de conhecimento zero como uma direção futura). Conclui-se que o blockchain pode ser integrado com sucesso às plataformas de streaming para fornecer uma camada de referência confiável e imutável para a proveniência de dados.