O que é uma Prova de Reserva?

Um Proof of Reserves (PoR) é uma auditoria independente que é realizada por terceiros. O objectivo de uma PdR é verificar se um depositário possui efectivamente os activos que afirma reter em nome dos seus clientes. Este auditor compila todas as informações sobre o saldo de clientes numa Árvore Merkleque é uma estrutura de dados que respeita o direito dos clientes à privacidade e que contém um instantâneo de todos os saldos de clientes que foram anonimizados.

O auditor adquire então uma Merkle Root, que é uma forma de impressão digital criptográfica que fornece um identificador único para a combinação destes balanços no momento em que o instantâneo foi produzido.

O auditor recolherá então as assinaturas digitais geradas pela troca de moedas criptográficas. Estas assinaturas são utilizadas para demonstrar a propriedade sobre endereços na cadeia que têm saldos que são observáveis publicamente. No último passo, o auditor faz uma comparação e verifica se estes saldos são mais ou iguais aos saldos dos clientes que se reflectem na árvore Merkle. Isto confirma que os activos dos clientes são armazenados numa base que utiliza toda a reserva.

Ao comparar bits específicos de dados com a raiz Merkle, cada cliente tem a capacidade de verificar independentemente que o seu montante foi tido em conta durante a auditoria do Proof of Reserves. Quaisquer alterações feitas aos dados restantes, por mais ínfimas que sejam, terão um efeito sobre a raiz, o que tornará qualquer adulteração clara.

Porque é que o Proof of Reserves é tão importante?

Os bancos são regulados e obrigados pelas autoridades governamentais a reportar quanto activos têm nos seus relatórios anuais, para que os fundos dos clientes não sejam postos em risco. No entanto, como as trocas de moeda criptográfica e os depositários não são regulados pelo governo, como podem os utilizadores ter confiança nos seus serviços?

Neste momento, a grande maioria das trocas centralizadas e outras plataformas de criptocracia CeFi, tais como emprestadores e depositários, armazenam as informações sobre os seus activos em bases de dados confidenciais e proprietárias. Como resultado, podem alegar que o dinheiro pertencente aos seus utilizadores está seguro com eles, mas é impossível verificar estas declarações.

Os clientes não têm apenas de acreditar na sua palavra quando usam uma Prova de Reserva, uma vez que têm uma confirmação inegável dessa promessa. Isto remete para o princípio fundamental da criptografia, que é "Não confie, verifique".

A utilização da prova de reserva ajuda a garantir que os depositários, cambistas e credores não participam em transacções financeiras em segredo, o que pode colocar em perigo os fundos dos seus clientes.

A prova de reserva assegura que um emprestador de moeda criptográfica não empresta mais dinheiro do que as garantias de que dispõe, o que permite que os seus emprestadores sejam reembolsados na totalidade no caso de ocorrer algo inesperado.

O comprovativo de reserva assegura que um depositário de token enrolados, tais como WBTC (embrulhado Bitcoin)tem realmente os bitcoins em reserva. Da mesma forma, assegura que estábulo emissores, como o Circle, têm genuinamente o USD para apoiar todos os USDC que emite.

Como é que uma Merkle Tree Proof-of-Reserve funciona?

A "Merkle Tree", por vezes conhecida como "árvore de hash", é o componente que assegura o sucesso do protocolo da Prova de Reserva. A verificação dos activos detidos em reserva pode ser realizada utilizando uma abordagem à prova de adulteração e criptograficamente segura com a utilização de uma Merkle Tree (ver secção abaixo para uma explicação mais detalhada sobre o seu funcionamento).

Por ser uma estrutura de dados que se baseia num hash, é extremamente sensível mesmo às alterações mais ínfimas e pode assim ser utilizada para proteger contra a fraude e manipulação de dados.

Um terceiro não filiado é responsável pela execução da Prova de Reserva Merkle Tree Proof of Reserve (PoR), como foi indicado anteriormente. A operação é a seguinte:

1. O auditor independente começa por compilar todos os saldos de utilizadores que são mantidos numa troca de moeda criptográfica para uma Merkle Tree após tirar uma fotografia de todos os saldos de utilizadores.

2. Uma função de hash criptográfico é usada para esta enorme recolha de dados. Uma função de hash criptográfica é um algoritmo informático que codifica dados e os cospe como uma única cadeia de 64 caracteres, tal como o seguinte: 3537fkhjtyti67182njkaurghcryrgsjakektio9101sjrrlgekb1644afffnd25.

3. O auditor recolherá as assinaturas digitais da troca que revelam os saldos totais que possui e verificará então se correspondem aos saldos que são registados na árvore Merkle para os utilizadores. A frase "prova de reserva" provém do facto de que isto demonstra que todos os bens dos utilizadores são armazenados na reserva da bolsa e, consequentemente, que todo o dinheiro comercial dos utilizadores também é aí armazenado.

4. O utilizador pode posteriormente verificar que os seus bens foram contabilizados na auditoria do Proof of Reserves utilizando uma identificação de registo única e comparando-a com a raiz de Merkle.

5. Se houvesse alguma alteração no seu equilíbrio de bens, por menor que fosse, ou se fosse um equilíbrio falso, resultaria numa mudança que se transforma em cascata até à raiz de Merkle e altera completamente o valor.

6. O utilizador pode verificar posteriormente que os seus bens foram contabilizados na auditoria do Proof of Reserves utilizando um

O Merkle Tree é o valor único que estabelece a integridade de todas as transacções, tornando evidente até a mais ínfima quantidade de adulteração. Como tal, a Merkle Tree é um valor que prova a integridade de todas as transacções.

Limitações da Prova de Reserva

O objectivo aqui é demonstrar ao público em geral, e mais especificamente às pessoas que colocaram depósitos consigo, que a quantia da sua moeda criptográfica que é mantida em depósito corresponde aos saldos dos utilizadores. É claro que, quando o colocar em realidade, verá que não é assim tão fácil. Não é difícil demonstrar que é responsável por determinado dinheiro em cadeia; no entanto, se precisar desses fundos a curto prazo, pode sempre pedi-los emprestados. Devido a isto, os atestados pontuais não têm muito peso. Além disso, as trocas correm o risco de ter responsabilidades ocultas ou de ter os devedores a reclamar prioridade sobre os depositantes, particularmente se não separarem legalmente os activos dos clientes na plataforma onde operam.

No processo de auditoria e verificação de fundos, ter provas de reserva garante alguma transparência. No entanto, há algumas coisas sobre ela que poderiam ser melhoradas, a reserva assegura de facto alguma transparência. No entanto, há algumas coisas nela que poderiam ser melhoradas. Mesmo que a Prova de Reserva seja capaz de demonstrar controlo sobre os dados na cadeia, bem como sobre o dinheiro que é guardado, não é capaz de verificar que um indivíduo é o único proprietário de uma chave privada.

Existe também o potencial para o auditor e o auditado trabalharem em conjunto para cometerem fraudes. Por outro lado, a obrigação de manter a abertura recai igualmente sobre ambas as partes. As discrepâncias podem também ser representadas pela perda de chaves e pelo roubo de dinheiro. O método Proof of Reserves também não é capaz de determinar se uma troca tomou emprestado fundos para passar uma auditoria. Isto pode reflectir inconsistências que ocorreram durante o processo de verificação. Para pintar com precisão o quadro completo, o Proof of Reserves deve de preferência ser combinado com alguma forma de Prova de Responsabilidades.

Proof of Reserves + Prova de Responsabilidade = Prova de Solvabilidade

O que é a Prova de Responsabilidades?

Em comparação com um Proof of Reserves, uma Prova de Responsabilidades é um conceito muito mais complicado. A combinação destas duas provas, contudo, pode fornecer o que é conhecido como uma Prova de Solvabilidade, pelo menos em relação a um certo token.

Na mesma linha do Proof of Reserves, uma troca pode optar por publicar uma lista de todas as responsabilidades que existem num determinado momento. Esta lista pode, em teoria, incluir o saldo da conta, bem como o nome de cada credor (para mais explicações sobre as razões pelas quais isto não é praticável devido a preocupações de privacidade, ver abaixo). Contudo, uma troca pode facilmente excluir algumas obrigações da lista, dando a impressão de que a empresa é solvente, apesar de estar verdadeiramente numa posição de insolvência.

Há a sugestão de que cada credor individual deve consultar a lista pública de obrigações e verificar se estão incluídas nela como meio de mitigar os efeitos desta questão. Existe a possibilidade de o público considerar a transacção como fraudulenta se mesmo um único credor afirmar que não estão incluídos na lista. O facto de alguns dos credores não verificarem a lista é uma preocupação, evidentemente. Contudo, é provável que esta abordagem seja bastante resiliente, o que significa que os consumidores podem ter muito mais certezas quanto à solvência da troca quando comparados com as plataformas que não empreendem este procedimento. Isto contrasta com as plataformas que não conduzem de todo este processo.

Os métodos acima descritos são obviamente altamente prejudiciais ao direito dos utilizadores à privacidade, dado que o público em geral teria conhecimento do nome de cada utilizador e do histórico do saldo da sua conta. Antes da publicação deste estudo, havia duas abordagens que, quando utilizadas em conjunto, podem aumentar significativamente a capacidade do utilizador para manter a sua privacidade. Por volta do ano 2014, Greg Maxwell foi a primeira pessoa a articular ambas as abordagens de estes conceitos.

1. Obfuscating the relationship between published balances and user identities - O nome da conta do utilizador pode ser omitido da lista; em seu lugar, a lista pode conter um hash do nome do utilizador ou endereço de e-mail conjugado com um nonce aleatório que é emitido para cada utilizador. Um utilizador individual teria a capacidade de garantir que o seu nome seria incluído na lista sem que o seu nome fosse divulgado ao público em geral desta forma.

2. Publicação dos saldos dos utilizadores em parte - A lista completa das responsabilidades não é tornada pública; em vez disso, as responsabilidades são apresentadas sob a forma de folhas dispostas numa estrutura de árvore Merkle. O passivo total da troca é apresentado no topo da árvore Merkle, e o hash no topo da árvore Merkle é tornado público. Depois disso, o mínimo de informação necessária para passar do saldo da conta do utilizador para o início da árvore Merkle é apresentado ao utilizador. Como resultado, cada utilizador pode ter um elevado grau de confiança de que o seu saldo está incluído no total, ao mesmo tempo que adquire muito pouca informação sobre os outros utilizadores no sistema.