Quer provar que está limpo sem entregar a lista de clientes? Há uma solução
O mais constrangedor para uma instituição que entra nesse mercado é querer provar que está limpa sem entregar a lista de clientes. Hoje, basicamente há duas opções: uma é entregar os endereços e o histórico de transações a uma empresa de análise on-chain para receber uma pontuação — o que equivale a revelar suas cartas a terceiros. A outra é criar uma lista branca de Merkle, que só consegue provar que determinado endereço está incluído no conjunto, mas não que o próprio conjunto está limpo. Na camada de dados privados da SXT, experimentei uma terceira opção: colocar a lista interna e a lista pública de endereços restritos na mesma tabela e fazer com que a consulta retorne um valor booleano acompanhado de uma prova. Para o público externo, divulga-se apenas a conclusão, sem revelar nenhum registro. As possibilidades desse uso são maiores do que a maioria imagina: é possível fazer assim a prova de reservas, a triagem de sanções e até verificar se os ativos de um cliente ultrapassam determinado limite. Em todos os casos, o resultado informa apenas sim ou não. O verdadeiro desafio técnico é a atualização: as listas mudam todos os dias, e as provas precisam ser geradas novamente. Caso contrário, você estará provando que estava tudo certo na semana passada. Já passei por isso uma vez: usei uma prova antiga para verificar uma lista nova, e o contrato me disse que estava tudo normal. Naquele instante, senti um frio na espinha. Depois, aprendi a incluir na prova o hash da versão dos dados; se a versão não corresponder, a verificação é rejeitada imediatamente. O obstáculo não está na criptografia, mas na própria lista. Quem a mantém, com que frequência ela é atualizada e se o histórico de alterações pode ser auditado: essas são questões operacionais, e não adianta nada se todo o resto estiver cheio de erros. Além disso, ainda não está claro se a lei reconhece provas criptográficas; os responsáveis pela conformidade preferem ver um relatório com carimbo oficial. Em comparação com a prova de reservas da Chainlink, essa abordagem é mais flexível: permite executar qualquer consulta SQL, em vez de apenas somar saldos. O custo é que você precisa assumir o trabalho de engenharia necessário para gerar as provas. Acredito que esse caminho será adotado primeiro por empresas de RWA e instituições de custódia, pois são elas que mais precisam dessa camada que permite comprovar as próprias alegações sem revelar informações. Para avançar de verdade, ainda será preciso combinar provas de intervalo e provas agregadas. Por exemplo, provar tanto que a exposição total está abaixo do limite quanto que nenhuma contraparte individual o ultrapassa. No momento, não há ferramentas prontas para esse tipo de trabalho; é preciso montar a solução por conta própria. Quando essa camada estiver funcionando bem, até o discurso comercial das instituições vai mudar: de «temos controles de risco rigorosos» para «você mesmo pode verificar».
#sxt $SXT @SpaceandTime
O mais constrangedor para uma instituição que entra nesse mercado é querer provar que está limpa sem entregar a lista de clientes. Hoje, basicamente há duas opções: uma é entregar os endereços e o histórico de transações a uma empresa de análise on-chain para receber uma pontuação — o que equivale a revelar suas cartas a terceiros. A outra é criar uma lista branca de Merkle, que só consegue provar que determinado endereço está incluído no conjunto, mas não que o próprio conjunto está limpo. Na camada de dados privados da SXT, experimentei uma terceira opção: colocar a lista interna e a lista pública de endereços restritos na mesma tabela e fazer com que a consulta retorne um valor booleano acompanhado de uma prova. Para o público externo, divulga-se apenas a conclusão, sem revelar nenhum registro. As possibilidades desse uso são maiores do que a maioria imagina: é possível fazer assim a prova de reservas, a triagem de sanções e até verificar se os ativos de um cliente ultrapassam determinado limite. Em todos os casos, o resultado informa apenas sim ou não. O verdadeiro desafio técnico é a atualização: as listas mudam todos os dias, e as provas precisam ser geradas novamente. Caso contrário, você estará provando que estava tudo certo na semana passada. Já passei por isso uma vez: usei uma prova antiga para verificar uma lista nova, e o contrato me disse que estava tudo normal. Naquele instante, senti um frio na espinha. Depois, aprendi a incluir na prova o hash da versão dos dados; se a versão não corresponder, a verificação é rejeitada imediatamente. O obstáculo não está na criptografia, mas na própria lista. Quem a mantém, com que frequência ela é atualizada e se o histórico de alterações pode ser auditado: essas são questões operacionais, e não adianta nada se todo o resto estiver cheio de erros. Além disso, ainda não está claro se a lei reconhece provas criptográficas; os responsáveis pela conformidade preferem ver um relatório com carimbo oficial. Em comparação com a prova de reservas da Chainlink, essa abordagem é mais flexível: permite executar qualquer consulta SQL, em vez de apenas somar saldos. O custo é que você precisa assumir o trabalho de engenharia necessário para gerar as provas. Acredito que esse caminho será adotado primeiro por empresas de RWA e instituições de custódia, pois são elas que mais precisam dessa camada que permite comprovar as próprias alegações sem revelar informações. Para avançar de verdade, ainda será preciso combinar provas de intervalo e provas agregadas. Por exemplo, provar tanto que a exposição total está abaixo do limite quanto que nenhuma contraparte individual o ultrapassa. No momento, não há ferramentas prontas para esse tipo de trabalho; é preciso montar a solução por conta própria. Quando essa camada estiver funcionando bem, até o discurso comercial das instituições vai mudar: de «temos controles de risco rigorosos» para «você mesmo pode verificar».
#sxt $SXT @SpaceandTime
