Na semana passada, eu fiquei preso em uma pequena dúvida sobre prova em cripto.
Antes de perguntar se a prova pode ser verificada, como saber que ainda é a prova original correta?
Alguns dias depois, lendo a seção de exemplo do zkTLS no Twitter/X nos docs do Newton Protocol, eu parei no detalhe do proofCid.
No começo, eu achava que o CID era apenas um endereço para armazenar a prova.
Uma prova de zkTLS é criada. O client armazena essa prova. O gateway retorna o proofCid. Depois, a task usa esse CID para que os operadores saibam qual prova pegar ao executar a avaliação de políticas.
À primeira vista, parece apenas um passo bem comum de salvar um arquivo.
Mas quanto mais eu leio, mais eu vejo que @NewtonProtocol não está perguntando apenas onde a prova está.
Ele está perguntando se o conteúdo por trás daquele endereço é, de fato, a prova que o client criou.
Este é o ponto em que CID difere de uma URL comum.
A URL normalmente diz onde o conteúdo pode ser encontrado.
O CID diz algo mais forte: que tipo de hash este conteúdo tem.
Se o conteúdo mudar, o CID também deve mudar. Portanto, um proofCid não é apenas um apontador. É um compromisso com os bytes por trás desse apontador.
Mas no fluxo de autorização, apenas receber um CID do Gateway e confiar nisso não é suficiente.
O exemplo do Newton não para em apenas receber proofCid. Ao recuperar os bytes da prova, o client verifica se os bytes retornados batem com o multihash do CID. Depois de store(), o SDK ainda deriva novamente o CID a partir dos bytes que ele mesmo enviou e rejeita se a resposta do Gateway não corresponder.
Este detalhe é pequeno, mas abre um limite muito importante.
Newton não deixa proofCid virar uma promessa do Gateway.
Ele cumpre a promessa para voltar e conferir com os bytes reais.
Por isso, o client não terceiriza completamente a confiança no Gateway nem na camada de storage quando a evidência entra no caminho da autorização. Ele verifica novamente, não por uma sensação de confiança, mas comparando o CID com o próprio conteúdo.
Esta é a parte que eu acho interessante.
Uma prova de zkTLS pode estar correta. Uma policy pode estar bem escrita. Uma task pode parecer válida. Mas se a passagem entre a criação da prova e a avaliação da policy divergir, se proofCid apontar para bytes diferentes da prova original, então o sistema está avaliando a evidência errada.
O erro então não está na criptografia da prova.
Isso fica na fronteira de armazenamento da evidência.
O Protocolo Newton parece estar tentando bloquear esse tipo de erro bem na fronteira do client. Antes da prova ser colocada na task, antes de operadores usarem, antes da policy depender dela, o client precisa garantir que o endereço e o conteúdo realmente correspondem.
Visto por esse ângulo, o Limite de Integridade do CID não é sobre guardar a prova por conveniência.
É a forma de manter a evidência intacta no trajeto desde a criação até ser usada para autorizar.
Claro, a integridade do CID não resolve tudo.
Ele não comprova que a alegação na prova é boa. Ele não substitui a policy. Também não garante que a fonte de dados externa seja sempre confiável.
Mas ele protege um trecho muito específico: a prova é armazenada, recuperada e passada para a task sem que o conteúdo por trás do endereço seja alterado.
Para mim, é um detalhe pequeno, mas notável em Newton.
A autorização não precisa apenas seguir a regra correta.
Ainda é preciso provas evidentes.
E antes que a evidência seja confiada, o sistema precisa ter certeza de que ela realmente é aquilo que o usuário/client criou.
Talvez proofCid não devesse ser visto como um link para a prova.
Deve ser encarado como a promessa de que a prova por trás daquele link não foi adulterada.