dr: A criptografia de testemunha é teoricamente possível desde 2013, mas permanece criptograficamente não implantável. Passei vários anos construindo um sistema que aproxima suas propriedades principais usando provas ZK do lado do cliente, geração de chaves homomórficas de duas partes e redução econômica – com duas implementações de teste funcionais em execução hoje. Esta postagem é sobre o problema, o enquadramento e um relato honesto de onde ficam os limites da confiança.
O problema
A criptografia de testemunha descreve uma primitiva aparentemente simples: criptografar uma mensagem de forma que ela só possa ser descriptografada por alguém que possa produzir uma testemunha válida para uma instrução NP. A condição é a chave. Nenhuma parte confiável. Sem guardião. Apenas prova.
Nenhuma construção geral segura existe hoje. A construção original do mapa multilinear foi quebrada. As abordagens evasivas de LWE são promissoras, mas ainda não implementáveis. Enquanto isso, os problemas que a criptografia testemunharia resolveria – recuperação de chave privada, entrega de dados vinculados à identidade, acesso condicional sem confiança – estão sendo corrigidos com custodiantes e mecanismos de recuperação social que introduzem exatamente os modos de falha que a criptografia deveria eliminar.
A Substituição
Você pode construir um sistema onde um segredo esteja criptograficamente vinculado a uma condição – onde satisfazer a condição seja necessário e suficiente para recuperar o segredo – sem uma parte confiável e sem que o segredo exista em texto simples? A vedação e a retirada da vedação exigem comunicação com um processador, mas o processador não aprende nada sobre o segredo ou as condições.
A resposta é sim – com uma substituição. Em vez da garantia matemática de que nenhum partido pode descriptografar sem uma testemunha válida, você constrói uma garantia econômica de que nenhuma das partes vai – porque isso destrói irreversivelmente o capital investido.
Esta é uma construção criptoeconómica, não puramente criptográfica. O objetivo não é aumentar o teto da segurança criptográfica, mas elevar o piso alto o suficiente para que a verdadeira experiência do usuário se torne possível sem sacrificar a autocustódia.
Primitivo proposto (informal)
Um sistema que fornece:
- Confidencialidade contra todos, exceto um operador publicamente cortável
- Verificação criptográfica das condições de liberação
- Mau comportamento publicamente atribuível com aplicação sem permissão
- Compatível com futura substituição criptográfica da função do operador
Princípios de Design
Antes de descrever a construção, quatro princípios restringem o projeto:
Composição primitiva, não invenção. Nihilium não introduz novas primitivas criptográficas. Ele compõe Shamir Secret Sharing, criptografia homomórfica ECElGamal, provas de conhecimento zero, piquetagem e corte baseado em EVM e árvores Merkle para carimbo de data / hora – todos usando bibliotecas estabelecidas. A contribuição é uma configuração nova que atinge as propriedades desejadas.
Decomposição de valor. O que é selado nunca é o ativo em si – apenas um componente sem valor isoladamente. Uma senha sem seu arquivo criptografado tem valor autônomo zero. Um arquivo criptografado sem senha tem valor autônomo zero. A combinação deles tem o valor total do ativo. Isso significa que a participação do processador precisa apenas exceder o valor que um invasor poderia extrair apenas do componente selado – que é zero sob uso correto. A comparação entre o valor da aposta e o valor do activo que inicialmente parece problemática é o enquadramento errado.
Ônus da prova do lado do cliente. Ao contrário dos sistemas MPC e de limite, onde os servidores avaliam as condições, o Nihilium inverte a responsabilidade: o cliente prova, o processador valida. Os processadores permanecem sem estado e leves. A linguagem de condição é infinitamente extensível sem atualizações de software do processador. O conteúdo da condição permanece oculto dos processadores até a abertura do lacre.
Blockchain apenas para aplicação. O EVM fornece contratos imutáveis, cortes resistentes à censura e registro de participação sem permissão. Na operação normal, apenas o fluxo de dados requer transações regulares na cadeia. Clientes e processadores interagem fora da cadeia, a menos que seja acionada uma redução ou execução forçada.
Atores do Sistema
O protocolo possui quatro tipos de atores:
O cliente detém segredos e tem total responsabilidade pelas operações criptográficas – definindo condições de abertura de lacre, gerando todas as provas de conhecimento zero e executando operações de criptografia homomórfica dentro de circuitos ZK.
O processador é um operador independente que se compromete com a desencriptação condicional através de participação económica. Os processadores possuem uma chave de assinatura EdDSA e uma chave de descriptografia ECElGamal (ambas no Baby Jubjub). Eles assinam compromissos de selamento, validam a execução de provas encadeadas no momento da abertura e descriptografam textos cifrados homomórficos após validação bem-sucedida. Eles são totalmente sem estado, escalam horizontalmente sem coordenação e operam de forma independente – não são nós em uma rede de consenso. Cada processador pode ser cortado de forma independente, e a participação do processador é um capital de reputação em risco em todos os compromissos: um único mau comportamento comprovável perde toda a participação permanentemente.
O fluxo de dados é um mecanismo de registro de data e hora e ancoragem de dados apoiado por estaca. Ele usa uma árvore Merkle de duas camadas com um contrato inteligente por operador atualizado a cada bloco Ethereum. Sua função crítica é ancorar o valor de revelação que inicia a abertura – criando a observabilidade pública obrigatória de todas as tentativas de abertura. Também produz reivindicações de exclusão apoiadas por estacas: afirmações assinadas de que um valor não não existem no fluxo de dados dentro de uma janela de tempo especificada. Se for refutado, o operador será cortado. Um mecanismo de inclusão forçada proporciona resistência à censura. E existirá uma versão completa on-chain para garantir vivacidade
A Blockchain (EVM) serve como a camada de aplicação sem permissão – registro e corte de participação de processador e fluxo de dados, registro de chave pública e registro de contrato de verificação de condição de abertura de lacre.
Como funciona
O projeto se chama Nihilium. A arquitetura completa ainda não é de código aberto, mas a estrutura conceitual é a seguinte.
Geração de chaves bipartidas. Um processador gera um componente chave e o cliente gera um segundo dentro de um circuito ZK. Os componentes são combinados dentro de um texto cifrado homomórfico — a chave final existe apenas como uma soma criptografada, nunca em texto simples durante a construção. O processador detém a chave de descriptografia desse texto cifrado, mas descriptografá-lo sem a apresentação de uma prova válida é uma ofensa passível de redução. Se a chave descriptografada for observada fora de um fluxo de abertura válido, a atribuição é inequívoca: o processador é a única parte capaz de produzi-la. Qualquer um pode iniciar um desafio de corte on-chain sem permissão; o processador deve apresentar uma prova de abertura válida ou perderá sua aposta.
Provas encadeadas. Um pipeline de condição combinável que suporta verificadores de prova ZK e contratos convencionais em cadeia. As etapas passam sinais digitados entre si, suportam bifurcação para lógica OR e são comprometidas em uma única raiz hash no momento do selamento – vinculação sem revelação. A execução acontece fora da cadeia no processador; os contratos on-chain servem como camada de desafio, mantendo a operação normal quase sem gás. Um coprocessador ZK poderia compactar toda a cadeia em uma prova on-chain de tamanho constante – ainda não implementada, mas a arquitetura suporta isso.
As condições são montadas em um editor visual usando uma biblioteca de módulos reutilizáveis (veja exemplo abaixo).
Aplicação simétrica. O mesmo mecanismo que reduz a divulgação antecipada também impõe a resistência à censura ao contrário: um processador que recusa um pedido válido de abertura do selo enfrenta cortes idênticos. Ruína binária para qualquer violação – não uma garantia social, a mesma prova operando em ambas as direções.
Observabilidade pública. Cada tentativa de abertura do lacre fica publicamente visível antes que a descriptografia ocorra. Para iniciar a abertura, o cliente deve inserir um valor de revelação no fluxo de dados – uma etapa obrigatória que pode ser observada por qualquer pessoa que o monitore. O proprietário de um segredo selado pode observar tentativas inesperadas em tempo real, sem confiar em nenhuma parte para denunciá-las. Esta observabilidade estrutural é também o que torna as condições baseadas no tempo significativas: os bloqueios temporais e as janelas de revogação só funcionam se a própria tentativa de abertura não puder ser ocultada. A tentativa não pode ser feita sem deixar um rastro público, com carimbo de data e hora, na cadeia – uma propriedade de auditoria que a criptografia de testemunha e as construções de MPC não fornecem.
Redundância de limite. O Shamir Secret Sharing entre vários processadores independentes proporciona recuperação social onde os guardiões são contratos, não contatos. O fardo da orquestração – tutores indisponíveis, perda de contacto – é substituído por um limiar de intervenientes economicamente empenhados, qualquer subconjunto dos quais pode servir o pedido. A recuperação é uma prova, não uma conversa.
Onde vai além do primitivo
Timelocks. A criptografia de testemunha para timelocks ainda requer uma âncora temporal do mundo real – na prática, uma prova ZK de um cabeçalho de bloco de uma cadeia confiável e resistente à censura que nenhuma parte controla. O fluxo de dados do Nihilium se ancora na altura do bloco Ethereum – a mesma cadeia na qual o corte é aplicado. Isto não é acidental: todas as reivindicações temporais, verificação de condições e aplicação económica partilham uma única fonte de verdade. Um timelock WE puramente criptográfico exigiria uma suposição de confiança entre cadeias para usar a mesma âncora; aqui é nativo.
Revogações. A criptografia de testemunha é apenas anexada – uma vez que uma condição pode ser satisfeita, ela pode ser satisfeita. Os operadores de fluxo de dados da Nihilium – múltiplos, com participação independente, com pelo menos um assumido como honesto e com compromissos auditáveis publicamente – podem produzir reivindicações de exclusão apoiadas por participação: afirmações assinadas criptograficamente de que não existe um valor no fluxo de dados entre o tempo X e Y. Se existir e puder ser comprovado, o operador é cortado. Isto permite condições do tipo “prova válida E nenhum sinal de revogação na janela T a T+N” – interruptores de homem morto com janelas de cancelamento, períodos de atraso de fraude, janelas de intervenção regulatória. Nada disso pode ser expresso na primitiva de criptografia testemunha.
Comparação
| Propriedade | Puro NÓS | Nihílio | Carteiras MPC | Recuperação Social |
|---|---|---|---|---|
| Implantável hoje | Não | Sim (rede de teste) | Sim | Sim |
| Modelo de segurança | Criptográfico | Criptoeconômico | Criptográfico | Confiança social |
| Operador publicamente cortável | Não | Sim | Não | Não |
| Expressividade da condição | Qualquer NP | Contratos ZK + | Específico do aplicativo | Nenhum |
| Revogação | Não | Sim | Não | Manual |
| Resistência à censura | Inerente | Sim (simétrico) | Parcial | Nenhum |
| Carga de orquestração | Nenhum | Nenhum | Baixo-médio | Alto |
| Agnóstico secreto | Sim | Sim | Não | Não |
| Observabilidade desbloqueada | Não | Sim (fluxo de dados) | Não | Não |
| Compatível com futuras substituições de criptografia | N / D | Sim | Não | Não |
O processador não é uma parte confiável no sentido tradicional – é um operador publicamente cortável, cujo mau comportamento é atribuível e contestável sem permissão.
Escopo
O protocolo é completamente independente da natureza do valor selado. Qualquer segredo representável como bytes pode ser selado – chaves privadas, senhas, registros médicos, documentos legais, tokens de API. O que importa são as condições e as condições são definidas pela aplicação. O EVM fornece garantias de suporte – contratos imutáveis, cortes resistentes à censura, registro de participação sem permissão – mas os aplicativos que mais importam podem não ter nada a ver com blockchains no nível do usuário.
Duas implementações de teste estão em execução: entrega de arquivo com identidade verificada usando ZKPassport e um fluxo de recuperação de “esqueci a senha” usando ZKEmail, onde a recuperação requer resposta a um e-mail – sem link de redefinição, sem 2FA, sem servidor guardando seu segredo. Uma implementação de referência incluindo o servidor de e-mail será de código aberto.
‘Esqueci minha senha’: recovery.nihilium.io
Transferência de arquivos baseada em identidade: transfer.nihilium.io
Perguntas abertas
- A suposição de detectabilidade – de que chaves vazadas surgem em contextos publicamente verificáveis – pode ser reforçada criptograficamente?
- Existe uma definição formal de segurança para liberação de chave condicional cortável como uma primitiva autônoma, distinta de WE e MPC?
- O pipeline de prova encadeado pode ser compilado de forma eficiente em uma única prova de validade ZK via coprocessador sem sacrificar as propriedades de composição?
O que estou procurando
Estou compartilhando isso para estabelecer publicamente o território conceitual e solicitar comentários sérios sobre o enquadramento, a análise do limite de confiança e as questões em aberto acima. Aberto à colaboração com pesquisadores que trabalham em aproximações WE ou primitivas relacionadas, e a conversas com equipes que estão construindo em espaços de problemas adjacentes.
O projeto é Nihilium: nihilium.io, x.com/nihiliumio
-Olavo
Fontesethresear


