DR
Uma prova de conhecimento zero permite que uma parte (um verificador) determine a validade de uma afirmação dada por outra parte (o provador) sem qualquer conhecimento do conteúdo da afirmação. Por exemplo, a Binance pode querer provar que apoiou totalmente os fundos dos seus usuários em reservas, sem revelar todos os saldos individuais dos usuários.
Uma “Prova de Reservas” poderia ser construída com uma árvore Merkle que protege contra falsificação de seus dados internos, neste caso, seus saldos líquidos totais de clientes, sendo passivos da bolsa para com seus usuários. Isso pode então ser combinado com um zk-SNARK (um protocolo de prova de conhecimento zero) que garante que os usuários possam verificar se seu saldo faz parte do saldo total de ativos líquidos do usuário sem conhecer os saldos individuais.
Introdução
À luz dos acontecimentos do mercado, a segurança dos criptoativos sob custódia tornou-se um tema crítico. Os usuários do Blockchain valorizam muito a transparência e a abertura, mas também apoiam a privacidade e a confidencialidade. Isto cria um dilema ao comprovar as reservas de fundos detidas pelos custodiantes. Muitas vezes, existe um compromisso entre transparência, confiança e confidencialidade dos dados.
No entanto, isso não precisa ser o caso. Ao combinar protocolos à prova de conhecimento zero, como zk-SNARKs, com árvores Merkle, podemos encontrar uma solução eficaz para todas as partes.
O que é prova de conhecimento zero?
Uma prova de conhecimento zero permite que uma parte (um verificador) determine a validade de uma afirmação dada por outra parte (o provador) sem qualquer conhecimento do conteúdo da afirmação. Vejamos um exemplo simples.
Você tem um cofre trancado para o qual só você conhece a solução. O cofre, por exemplo, não pode ser arrombado, forçado ou aberto de qualquer outra forma que não seja conhecendo a combinação. Este fato também é estabelecido, verificado e conhecido pelo seu amigo participante do experimento.
Você afirma que conhece a combinação para seu amigo, mas não quer entregá-la nem abrir a caixa na frente dele. No topo da caixa há um buraco onde seu amigo pode colocar um bilhete. Para tornar isso uma prova de conhecimento zero, seu amigo não deve ter nenhuma informação extra sobre o processo além da afirmação fornecida.
Você pode provar ao seu amigo que conhece a combinação abrindo a caixa, contando o que estava escrito no bilhete e fechando-a novamente. Em nenhum momento você, entretanto, revelou a combinação.
Para um exemplo mais avançado, consulte nosso artigo O que é prova de conhecimento zero e como isso afeta o Blockchain? artigo.
Por que usamos a prova de conhecimento zero?
As provas de conhecimento zero são adequadas para provar algo sem revelar informações ou detalhes confidenciais. Este pode ser o caso se você não quiser fornecer suas informações financeiras ou pessoais que possam ser usadas de forma inadequada.
Na criptografia, você pode provar que possui uma chave privada sem revelá-la ou assinar algo digitalmente. Uma bolsa de criptomoedas também pode querer provar o status de suas reservas sem revelar informações confidenciais sobre seus usuários, incluindo os saldos de suas contas individuais.
Para esses exemplos (e muitos outros), uma prova de conhecimento zero usaria algoritmos que pegam uma entrada de dados e retornam “verdadeiro” ou “falso” como saída.
Definindo Provas de Conhecimento Zero em Termos Técnicos
Uma prova de conhecimento zero, em termos técnicos, segue uma estrutura específica com determinados critérios. Já cobrimos as funções de provador e verificador, mas também há três critérios que uma prova de conhecimento zero deve cobrir:
Completude. Se a afirmação for verdadeira, o verificador ficará convencido pela prova apresentada, sem necessidade de qualquer outra informação ou verificação.
Solidez. Se a afirmação for falsa, o verificador não ficará convencido da veracidade da afirmação pela prova fornecida.
Conhecimento zero. Se a afirmação for verdadeira, o verificador não aprende nenhuma informação além de a afirmação ser verdadeira.
O que é um zk-SNARK?
Um zk-SNARK (argumento de conhecimento sucinto e não interativo de conhecimento zero) é um protocolo de prova que segue os princípios de conhecimento zero descritos anteriormente. Com um zk-SNARK, você pode provar que conhece o valor original do hash (discutido mais abaixo) sem revelar o que é. Você também pode provar a validade de uma transação sem revelar qualquer informação sobre os valores, valores ou endereços específicos envolvidos.
zk-SNARKs são comumente usados e discutidos no mundo blockchain e criptomoeda. Mas você pode se perguntar por que alguém se preocuparia em usar um zk-SNARK quando poderia usar um método simples de par de chaves públicas e privadas para proteger as informações. No entanto, não seríamos capazes de implementar a prova matemática para garantir que não fossem incluídos saldos negativos e a soma da árvore Merkle.
No caso das reservas de uma bolsa, queremos provar o apoio 1:1 dos saldos dos clientes sem que os identificadores e saldos de cada conta sejam tornados públicos. Além disso, a tecnologia zk-SNARK torna a falsificação de dados ainda mais improvável.
O que é uma árvore Merkle?
Apresentar os fundos somados das contas dos usuários da Binance requer trabalhar com um grande conjunto de dados. Uma maneira de apresentar essa grande quantidade de dados criptograficamente é usar uma árvore Merkle. Uma grande quantidade de informações pode ser armazenada com eficiência nele, e sua natureza criptográfica torna sua integridade facilmente verificável.
Funções hash
Para codificar sucintamente uma entrada, uma árvore Merkle depende do uso de funções hash. Resumindo, hashing é o processo de geração de uma saída de tamanho fixo a partir de uma entrada de tamanho variável. Em outras palavras, quando uma entrada de qualquer comprimento é hash por meio de um algoritmo, ela produzirá uma saída criptografada de comprimento fixo.
Enquanto a entrada permanecer a mesma, a saída também permanecerá. Isso significa que podemos pegar grandes quantidades de dados transacionais e transformá-los em uma saída gerenciável. A saída será radicalmente diferente se alguma informação for alterada na entrada.
Por exemplo, poderíamos pegar o conteúdo de 100 livros e inseri-los na função hash SHA-256. Em seguida, forneceria algo assim como saída:
801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea
Se alterássemos um único caractere da entrada (aqueles 100 livros), o hash seria completamente diferente, assim:
abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410
Essa é uma propriedade importante das funções hash porque permite fácil verificação da precisão dos dados. Se alguém replicar o processo de hash desses mesmos 100 livros usando o algoritmo SHA-256, obterá exatamente o mesmo hash da saída. Se a saída for diferente, podemos afirmar com certeza que a entrada foi alterada. Isso significa que não há necessidade de verificar individualmente ou manualmente as diferenças entre os insumos, o que pode exigir muito trabalho.
Árvores Merkle no mundo das criptomoedas
Ao armazenar dados de transações em um blockchain, cada nova transação é enviada por meio de uma função hash, que gera valores hash exclusivos. Imagine que temos oito transações (A a H) que fazemos hash individualmente para obter suas saídas hash. Estes são o que chamamos de nós folha Merkle. Na imagem abaixo, você pode ver o valor hash exclusivo de cada letra: hA para A, hB para B, hC para C, etc.
Podemos então pegar pares de saídas com hash, combiná-los e receber uma nova saída com hash. Os hashes de hA e hB combinados, por exemplo, nos dariam uma nova saída de hash de hAB conhecida como ramificação Merkle. Observe que cada vez que uma nova saída é gerada, ela vem com comprimento e tamanho fixos, de acordo com a função hash utilizada.
Agora temos os dados de duas transações (por exemplo, A e B) combinadas em um hash (hAB). Observe que se alterarmos qualquer informação de A ou B e repetirmos o processo, nossa saída com hash hAB seria completamente diferente.
O processo continua à medida que combinamos novos pares de hashes para hash novamente (veja a imagem abaixo). Fazemos hash de hAB com hCD para obter um hash exclusivo hABCD e fazemos o mesmo com hEF e hGH para obter hEFGH. No final, recebemos um único hash representando as saídas de hash de todos os hashes de transações anteriores. Em outras palavras, a saída hash hABCDEFGH representa todas as informações que vieram antes dela.
O gráfico exibido acima é chamado de árvore Merkle, e a saída com hash hABCDEFGH é a raiz Merkle. Usamos raízes Merkle em cabeçalhos de bloco, pois elas resumem criptograficamente todos os dados de transação em um bloco de maneira sucinta. Também podemos verificar rapidamente se algum dado foi adulterado ou alterado dentro do bloco.
As limitações das árvores Merkle
Voltemos ao nosso exemplo de reservas CEX. Uma CEX deseja provar o respaldo 1:1 de todos os ativos de seus clientes e constrói uma árvore Merkle que combina os UIDs de seus clientes com seus ativos líquidos (compensando ativos e passivos) em nível simbólico. Uma vez liberada (e assinada para provar a propriedade da raiz Merkle fornecida), um usuário individual não teria como verificar se a árvore Merkle é válida sem acessar todas as suas entradas.
Uma troca pode ter perdido a inclusão de algumas entradas. Também poderia criar contas falsas com saldos negativos para alterar o passivo total. Por exemplo, embora os ativos dos clientes possam totalizar US$ 1.000.000, uma conta falsa pode ser adicionada com um saldo de -US$ 500.000. Isto criaria uma meta de reservas de apenas US$ 500.000.
O caso da prova de reservas é diferente da raiz Merkle de um bloco, pois os usuários podem ver todas as transações que um bloco contém em um explorador de blockchain. Um CEX, entretanto, não deseja divulgar o saldo de cada conta por motivos de segurança e privacidade de dados. Os clientes também não ficariam satisfeitos com a divulgação pública dos saldos das suas contas. Nesse caso, o CEX não pode provar que os saldos dos usuários somam o total correto sem tornar visíveis os saldos de outros usuários.
Uma solução que as bolsas podem considerar empregar é usar um auditor terceirizado de confiança. O auditor pode verificar as contas e reservas individuais antes de finalmente atestar a validade da raiz Merkle fornecida. No entanto, para os usuários, este método exige confiança no auditor e nos dados utilizados para a auditoria. Você não precisa depender de terceiros quando pode confiar nos dados.
Combinando zk-SNARKs com árvores Merkle
A questão acima é um caso perfeito para usar zk-SNARKs. Queremos provar que as reservas cobrem integralmente as responsabilidades dos utilizadores e não são falsificadas. No entanto, por razões de privacidade e segurança, não queremos mostrar ao verificador a composição exata dos saldos e reservas dos usuários.
Ao usar um zk-SNARK, uma troca de criptografia pode provar que todos os conjuntos de saldos de nós folha da árvore Merkle (ou seja, saldos de contas de usuários) contribuem para o saldo total de ativos do usuário reivindicado pela troca. Cada usuário pode acessar facilmente seu nó folha como tendo sido incluído no processo. O zk-SNARK também garante que qualquer árvore Merkle gerada não contenha usuários com saldo patrimonial líquido total negativo (o que implicaria falsificação de dados, já que todos os empréstimos são excessivamente garantidos). Também é utilizado um cálculo do estado global da Binance, ou seja, uma lista do saldo líquido total de cada ativo que cada cliente da Binance possui.
Vamos dar uma olhada em como a Binance aborda a situação. Para começar, a Binance define as restrições da computação que deseja provar e as define como um circuito programável. Abaixo está o conjunto de três restrições que a Binance usa em seu modelo.
Para o conjunto de saldo de cada usuário (nó folha da árvore Merkle), nosso circuito garante que:
Os saldos de ativos de um usuário são incluídos no cálculo da soma dos saldos líquidos totais do usuário com a Binance.
O saldo líquido total do usuário é maior ou igual a zero.
A mudança da raiz da árvore Merkle é válida (ou seja, não usa informações falsificadas) após atualizar as informações de um usuário para o hash do nó folha.
A Binance pode então gerar uma prova zk-SNARK para a construção da árvore Merkle de acordo com o circuito. Isso implica que a troca execute o cálculo pesado de hashing dos IDs e saldos dos usuários, ao mesmo tempo que garante que a prova passe nas restrições.
Um verificador examinará a prova (e seu código-fonte aberto divulgado publicamente) para se convencer de que a computação é executada com todas as restrições atendidas. O cálculo da verificação leva um tempo extremamente curto em comparação com o tempo de prova.
A cada divulgação do Comprovante de Reservas, a bolsa publicará:
1. A prova Merkle para cada usuário.
2. A prova zk-SNARK e entrada pública (um hash da lista do saldo líquido total de cada ativo e raiz Merkle) do circuito para todos os usuários.
As partes interessadas podem verificar a prova Merkle, garantindo que seus saldos individuais contribuíram para a raiz da árvore Merkle. Eles também podem verificar a prova zk-SNARK para garantir que a construção da árvore Merkle atenda às restrições definidas no circuito. Para uma explicação mais detalhada da solução zk-SNARK e seu desempenho, consulte nosso blog Como zk-SNARKs melhoram o sistema de prova de reservas da Binance.
Considerações finais
Os zk-SNARKs fornecem a tecnologia necessária para garantir a integridade e a privacidade dos dados ao mesmo tempo. Sua aplicação para comprovar reservas e aumentar a transparência da CEX deve ajudar a construir confiança na indústria de blockchain. Para muitos, um desenvolvimento como este é há muito aguardado e chega num momento crucial para os CEXs.
Esta é a primeira versão do nosso zk-SNARK e estamos ansiosos para receber feedback da comunidade para que possamos continuar a melhorar o sistema.
Leitura adicional
(Blog) Como zk-SNARKs melhoram o sistema de prova de reservas da Binance
(Academia) Prova de Reservas (PoR)
(Academia) O que é prova de reservas e como funciona na Binance
(Announcement) Binance Releases Proof of Reserves System