Arquitetura projetada para prova, não apenas armazenamento.
Cada componente existe por um motivo: tornar eventos críticos verificáveis, resistentes à adulteração e defensáveis.
Uma requisição não é apenas armazenada. Ela é transformada em evidência.
Quando um evento entra no ImmutableLog, ele passa por validação, idempotência, selagem criptográfica, ordenação, consenso e persistência append-only antes de fazer parte do ledger.
É isso que transforma um log em algo que pode ser provado.
- Estágios obrigatórios
- 11 Nenhum opcional
- Modelo de consenso
- PoA Proof of Authority
- Nós em consenso
- N Maioria qualificada
- Operações destrutivas
- 0 Sem update, sem delete
- 01
Cliente
Papel: Origem do eventoSua aplicação envia eventos críticos por uma API segura.
GaranteOrigem identificada e autenticada por chave e endereço de rede.
Sem eleSem autenticação na origem, qualquer agente externo poderia injetar eventos forjados.
- 02
API de Ingestão
Papel: Porta de entradaA API recebe eventos, valida a estrutura, autentica a requisição e prepara o payload para processamento no ledger.
GaranteCada evento entra com carimbo de tempo do servidor e identidade do cliente.
Sem eleSem timestamp confiável do servidor, a ordem cronológica seria controlada pelo cliente — e manipulável.
- 03
Validação + Enriquecimento
Papel: Porteiro do ledgerEventos são normalizados, enriquecidos com metadados e verificados antes de entrar no pipeline do ledger.
GaranteEventos malformados são rejeitados antes de tocar o ledger; o hash é calculado a partir de uma representação canônica única.
Sem eleSem canonização, dois clientes serializariam o mesmo evento de formas diferentes e gerariam hashes distintos.
- 04
Idempotência
Papel: Defesa contra duplicaçãoRetries não devem criar verdades duplicadas. A idempotência garante que o mesmo evento seja registrado apenas uma vez, mesmo em falhas ou requisições repetidas.
GaranteA mesma operação produz um único registro, independentemente de retries de rede ou de cliente.
Sem eleSem idempotência, instabilidade de rede vira evento duplicado — e duplicação corrompe a história.
- 05
Mempool
Papel: Buffer ordenadoEventos válidos entram em uma fila temporária onde são ordenados e preparados para consenso.
GarantePicos de carga não derrubam o sistema; a ordem de chegada é preservada.
Sem eleSem mempool, ou você processa cada evento sincronamente (lento), ou descarta sob carga (perde história).
- 06
Gossip / Propagação interna
Papel: Distribuição entre nósOs nós trocam eventos pendentes internamente para que a rede convirja para o mesmo estado do ledger.
GaranteNenhum nó isolado controla o que está sendo proposto à rede.
Sem eleSem gossip, um nó comprometido poderia esconder eventos dos outros antes do consenso.
- 07
Consenso PoA
Papel: Acordo coletivoImmutableLog utiliza um modelo permissionado de Proof of Authority entre nós confiáveis. Blocos são acordados, não presumidos.
GaranteA história é uma decisão coletiva auditável, não a opinião de um único processo.
Sem eleSem consenso, um administrador com acesso a um nó reescreveria o histórico sozinho.
- 08
Produção de blocos
Papel: Encadeamento criptográficoEventos são agrupados em blocos. Cada bloco referencia o anterior, criando uma cadeia criptográfica de histórico.
GaranteAlterar qualquer evento passado quebra o hash do bloco e de todos os blocos posteriores — a adulteração se torna matematicamente detectável.
Sem eleSem encadeamento por hash, eventos antigos poderiam ser editados sem deixar rastro verificável.
- 09
Persistência append-only
Papel: Armazenamento append-onlyDepois de gravados, os registros não são atualizados nem apagados. A imutabilidade é garantida pela arquitetura, não por política.
GaranteEventos não podem ser editados nem apagados, nem por administradores de banco.
Sem eleSem append-only, qualquer DBA com permissão consegue reescrever o passado e o sistema vira só mais um log.
- 10
Replicação
Papel: Redundância da históriaO ledger é replicado entre nós para preservar disponibilidade e impedir manipulação unilateral do histórico.
GaranteFalha de hardware ou desastre em um nó não apaga a história.
Sem eleSem replicação, perder o disco de um nó é perder evidência.
- 11
Verificação independente
Papel: Estado final verificávelQualquer parte autorizada pode verificar que um evento existe e que a cadeia permanece íntegra sem confiar no operador.
GaranteQualquer auditor consultando qualquer nó obtém a mesma resposta — e pode verificar a prova localmente, sem depender do operador.
Sem eleSem consistência, dois auditores teriam respostas diferentes para a mesma pergunta — e a evidência perde valor probatório.
Princípios de design
Cinco escolhas que definem como a infraestrutura é construída — e por quê.
- 01
Prova
acima de
presunção
- 02
Imutabilidade
acima de
conveniência
- 03
Ordenação determinística
acima de
ambiguidade
- 04
Verificação independente
acima de
confiança no operador
- 05
Performance enterprise
acima de
overhead de blockchain pública
Não é blockchain pública. Não é observabilidade. Não é analytics.
ImmutableLog usa primitivas criptográficas de nível blockchain, mas não depende de redes públicas, tokens, mineração ou validadores externos.
É um ledger privado e permissionado projetado para auditabilidade enterprise.
- ✕Sem token
- ✕Sem mineração
- ✕Sem rede pública
- ✕Sem validador externo
A prova vive nos dados.
A verificação não exige confiar no ImmutableLog, nos administradores de banco ou nos logs da aplicação.
Se os hashes validam e a cadeia está íntegra, o histórico pode ser provado. Se algo foi alterado, a quebra se torna visível.