Prova de Reservas

Auditoria

Saiba mais sobre o processo de auditoria da Kraken

Processo de Auditoria de Prova de Reservas da Kraken  

Introdução

Este documento fornece informação e orientação sobre o processo de auditoria da Kraken.

A Kraken detém reservas completas e emprega uma auditoria independente, criptograficamente verificada, a fim de provar a terceiros, incluindo os nossos clientes, que os fundos dos clientes são custodiados adequadamente. Transparência e auditorias verificadas de forma independente são fundamentais para garantir que as empresas possuem reservas completas dos recursos dos clientes. Um esquema público de prova de reservas é tecnicamente possível de implementar. No entanto, existem externalidades importantes, a privacidade do usuário entre elas, que devem ser cuidadosamente consideradas na implementação específica de um esquema público de prova de reservas. Acreditamos que as exchanges e carteiras devem inspirar confiança através da prestação de contas e que nós temos a responsabilidade de atender ao desejo da comunidade por transparência.

Ao longo das últimas semanas, a Kraken desenvolveu e completou com sucesso uma auditoria independente, criptograficamente verificada e sem paralelo. Estamos orgulhosos de apresentar um resumo do nosso processo para a comunidade global das moedas digitais. Acreditamos que a indústria do Bitcoin seja capaz de fornecer um nível de garantia e responsabilidade superior a indústria tradicional de serviços financeiros, e o nosso objetivo é conduzir este processo em direção à transparência ideal.

Panorama Atual

O ímpeto dessa iniciativa é a proposta de Greg Maxwell para as carteiras/exchanges comprovarem suas reservas de Bitcoin. [1]

Até o momento, as auditorias realizadas pela indústria do Bitcoin têm sido obscuras, superficiais e sem verificação criptográfica publicamente visível e verificável de maneira independente. A Kraken busca oferecer provas de conceito e definir padrões na indústria com maior transparência e responsabilidade no ecossistema dos ativos digitais que outros poderão seguir e melhorar.

Qualidade do Processo

A proposta de Maxwell teria exigido que as empresas de bitcoin revelassem todos os endereços que contivessem saldo. Esse método tornaria público o conhecimento dos portfólios de bitcoin das exchanges e provedores de carteiras e suas participações totais, informações que são comercialmente sensíveis e apresentam riscos de segurança em potencial para as empresas e seus usuários. Ainda pior, resultaria em uma inadmissível violação da privacidade do usuário, na qual terceiros poderiam rastrear o histórico de bens individuais e atividade financeira sem justa causa ou processo devido.

Nosso processo não exige que divulguemos nosso saldo total, endereços ou chaves para o público. Combinando e alavancando os pontos fortes de um auditor confiável e uma criptografia publicamente verificável, a auditoria Kraken representa o equilíbrio ideal entre privacidade e transparência.

Como o Bitcoin é a criptomoeda dominante, nossa auditoria inicial cobrirá apenas as reservas de Bitcoin. No entanto, auditorias para outros ativos serão consideradas em futuros desenvolvimentos.

Resumo do Processo

  • Fase 1 - O auditor verifica os fundos de toda a carteira da Kraken

    A Kraken fornece ao auditor todos os seus endereços públicos e os assina. O hash do bloco no momento da assinatura faz parte da mensagem assinada e pode ser usada como um registro de tempo de quando a assinatura foi feita. As assinaturas desses endereços públicos serão verificadas e o auditor usará a blockchain do bitcoin para extrair o valor total disponível nesses endereços em um determinado momento.

    O código requerido para esta fase foi escrito por Michael Gronager, Diretor de Operações da Payward, e pode tornar-se totalmente open-source no futuro. No entanto, a maior parte do código já é open source, visto que foi baseado na libcoin. [2]

  • Fase 2 - O auditor verifica se os saldos dos usuários da Kraken coincidem com os fundos da carteira da Kraken

    A Kraken fornece ao auditor os saldos de BTC de cada um dos nossos usuários e gera uma árvore de Merkle. O auditor irá publicar o root node hash para todos verem, e afirmará, se for verdade, que o total de fundos representados pelo root hash está muito próximo do valor que ele vê em nossa carteira na blockchain. Esse fluxo também garante que a Kraken não está ocultando nada em nenhum dos nodes que levam root node.

    Nesta fase da auditoria, o auditor terá acesso ao código-fonte do programa gerador da árvore e ao arquivo de dados dos saldos das contas individuais. A Kraken lançou o código C ++ para esta fase sob a licença MIT: https://github.com/payward/krakendb

  • Fase 3 - Os usuários verificam de forma independente que os saldos de suas contas foram incluídos nos dados utilizados ​​pelo auditor

    A Kraken fornece aos usuários o valor que foi informado ao auditor, bem como os nodes (e nodes adjacentes) de sua conta ao root (que corresponde ao publicado pelo auditor). Nós também revelamos o método de hashing utilizado para gerar a hash de seu node, para que eles possam verificar se o node representa a quantia que reivindicamos.

    Isso permitirá que os usuários verifiquem por conta própria que sua conta foi incluída nos dados verificados pelo auditor.

Limitações

Nesta seção, nós descrevemos algumas das limitações dessa auditoria. Tenha em mente que, obviamente, essa não é uma lista exaustiva dos pontos fracos. No entanto, como valorizamos a transparência para nossos usuários, fornecemos dados informais sobre as limitações específicas que identificamos até agora no processo de auditoria.

Ao contrário dos ativos físicos, as informações não precisam ser removidas da posse de uma pessoa para serem adquiridas por outra. Portanto, a Kraken ou outra empresa que utilizar esse método de auditoria não é capaz de provar que as chaves privadas não foram duplicadas por um invasor. Também não podemos provar que temos posse exclusiva dos fundos auditados. Apenas podemos provar que, no momento da auditoria, éramos um dos proprietários das chaves privadas.

Provavelmente, a auditoria completa não pode ser feita mediante solicitação, sem aviso prévio. Considerando as informações necessárias, a estrutura da auditoria e as práticas de segurança padrão das carteiras frias na indústria, não é possível realizar uma auditoria surpresa no mesmo dia. Imaginamos que uma auditoria mais "leve", com base em uma auditoria completa anterior, contando com assinaturas geradas anteriormente, possa ser feita com mais frequência.

O auditor deve ser confiável e competente. A comunidade também deve acreditar que o auditor valoriza sua reputação e é tecnicamente qualificado. Existem várias oportunidades nesse processo de auditoria para que um auditor menos técnico ou menos paranóico possa ser enganado pela entidade auditada. Há também oportunidades para o auditor comprometer intencionalmente ou inadvertidamente informações confidenciais da empresa e dos clientes. Tanto o auditor quanto a entidade auditada devem considerar quem fornece o computador, o espaço de auditoria, a blockchain, a conexão com a Internet, o roteador, o DNS, etc. Se o objetivo é esconder uma fraude de bilhões de dólares, as partes seriam capazes de qualquer coisa para comprometer a auditoria.

A auditoria não é continuamente renovada em tempo real. É possível que as chaves tenham sido perdidas ou que fundos tenham sido roubados desde a última auditoria. A auditoria completa renova a alegação de que as chaves não foram perdidas, embora crie uma maior exposição a ameaças, pois é necessário usar chaves de armazenamento a frio para realizar a auditoria.

A entidade auditada pode emprestar fundos temporariamente ou compartilhar chaves com o verdadeiro dono dos fundos para passar em uma auditoria.

O auditor pode concordar ou sucumbir às ameaças da entidade auditada.

De maneira contínua

Pretendemos realizar auditorias periódicas de maneira contínua. Como não há um auditor universal de confiança, podemos usar um auditor diferente ou vários auditores a cada vez. Isso satisfaz aqueles que podem duvidar das credenciais de um determinado auditor.

Mudanças Futuras e Melhorias

Esperamos receber feedbacks da comunidade para ajudar-nos a melhorar esse processo para futuras auditorias. Como membros dessa comunidade, também esperamos trabalhar com organizações da indústria, como a DATA (www.datauthority.org), para ajudar a desenvolver padrões básicos, ferramentas escaláveis ​​e um manual compreensivo para que outras empresas da indústria possam realizar auditorias semelhantes.

Referências

[1] Resumo por Zak Wilcox: https://iwilcox.me.uk/2014/proving-bitcoin-reserves. Gostaríamos de agradecer a Greg Maxwell por suas ideias.

[2] libcoin é a transformação do bitcoin em bibliotecas modulares e reutilizáveis:&nbsphttps://github.com/libcoin/libcoin

Como verificar o saldo da sua conta individual com a Kraken na auditoria feita pela Kraken

Veja também: Processo de auditoria de prova de reservas da Kraken.

Essas instruções explicam como verificar criptograficamente o saldo da sua conta na Kraken e sua inclusão na auditoria.

Essa verificação corresponderá ao saldo de Bitcoin (XBT) da sua conta no momento da auditoria.

 

  • Passo 1

    Se ainda não está logado, faça o login na sua conta Kraken.

    Visite https://www.kraken.com/ e certifique-se de que a barra de endereços do seu navegador exibe "https://www.kraken.com/"

  • Passo 2

    Clique na guia "Depósitos e Retiradas" -> subguia "Auditoria" -> "Bitcoin (XBT)" no lado esquerdo.

    Figura 1. Página da Auditoria de Bitcoin da Kraken 

  • Passo 3

    Veja as informações sobre sua conta verificadas pelo auditor

    • Momento da auditoria, que é o timestamp usado pelo auditor.

    • Código de Envio, que é um 64 bit salt.

    • Montante de Bitcoins mantidos em sua conta no momento da auditoria. Este é o valor do saldo da sua conta que fornecemos ao auditor.

    • As Notas incluem informações do auditor provando que o root hash foi usado para a auditoria. Um link para um relatório assinado e detalhado também é fornecido.

    • Os Hashes do seu node hash até o root hash, incluindo os hashes adjacentes. Os valores do hash em sua rota direta são mostrados com um asterisco (*) para diferenciá-los do node hash adjacentes. Com esses hashes, você pode verificar se o seu node foi incluído no root:

    • A primeira linha deve corresponder ao valor do root hash fornecido pelo auditor.

      Se deseja verificar o seu node hash (o último hash com um * na lista), faça o seguinte:

      
      sha256(sha256(<c de envio> || ":" || <montante com ponto decimal e zeros iniciais removidos>))</montante></c>

      Esse valor deve corresponder ao último valor dado nos hashes.

      Código de exemplo

      Código de envio: 379377cd8190f9bf

      Montante: 0.01500000

      Python

      
      import hashlib; print(hashlib.sha256(hashlib.sha256(b'379377cd8190f9bf:1500000').digest()).hexdigest());
      

      PHP

      
      echo hash('sha256', hash('sha256', '379377cd8190f9bf:1500000', true));
      

      Resultado

      
      66b51ba0f4a5cf8278acac6782ffdfb9a64b9f7c895bc308266b0757c7025b27
      

      Você pode verificar totalmente seus ramos Merkle fazendo um hash de cada par de hashes (ou "tuple"). O formato é:

      
      sha256(left-hash || right-hash)
      

      O resultado deve corresponder ao tuple hash anterior (ou ao hash da raiz) com um * nele. Isso seria feito para todos tuples.

      Com exceção do root hash, todos os hashes são dados como tuples, representando o left-hash e o right-hash, nessa ordem. O * é dado aos hashes que representam seus nodes diretos.

      Código de exemplo:

      Hashes:

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3* c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b* 5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c
      

      Python

      
      import hashlib; print(hashlib.sha256(b'c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'.decode('hex'))).hexdigest();
      

      PHP

      
      echo hash('sha256', hex2bin('c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'));
      

      Resultado

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3