Prova di Riserve

Audit

Scopri di più riguardo al processo di audit di Kraken

Processo di Audit sulla Prova di riserve Kraken  

Introduzione

Questo documento fornisce informazioni e linee guida sul processo di audit di Kraken.

Kraken detiene riserve complete e ci serviamo di un a procedura indipendente, verificata crittograficamente per dimostrare a terzi, inclusi i nostri clienti, che i fondi dei clienti sono correttamente protetti. La trasparenza e gli audit verificati in modo indipendente sono fondamentali per garantire che le società detengano riserve complete di fondi dei clienti. È tecnicamente possibile implementare uno schema pubblico di prova della riserva. Tuttavia, esistono fattori esterni importanti, tra cui la privacy degli utenti, che devono essere attentamente considerati nell'attuazione specifica di uno schema pubblico di prova di riserva. Crediamo che exchanges e portafogli debbano creare fiducia attraverso la rendicontazione e che abbiamo la responsabilità di rispondere al desiderio di trasparenza della comunità.

Nelle scorse settimane Kraken ha sviluppato e completato con successo un audit indipendente, leader nel settore, controllato da crittografia. Siamo orgogliosi di presentare questa panoramica del nostro processo alla comunità globale della moneta digitale. Riteniamo che l'industria dei Bitcoin sia in grado di fornire un livello di affidabilità e responsabilità che supera il tradizionale settore dei servizi finanziari e miriamo a definire uno standard verso una trasparenza ottimale.

Panorama Corrente

L'impulso per questa iniziativa è la proposta di Greg Maxwell per exchanges / wallet per dimostrare le loro riserve di Bitcoin.[1]

Ad oggi, gli audit prodotti dall'industria dei Bitcoin sono stati opachi, superficiali e senza la verifica crittografica visibile e soggetta a verifica indipendente. Kraken cerca di fornire una dimostrazione del concetto e stabilisce standard di settore di maggiore trasparenza e responsabilità dall'ecosistema della moneta digitale che altri possono seguire e migliorare.

Qualità del Processo

La proposta di Maxwell avrebbe obbligato le compagnie operanti sulla blockchain bitcoin a rivelare al pubblico tutti i loro indirizzi contenenti i fondi. Queste informazioni sono sensibili e renderle note implica esporsi a maggiori rischi sulla sicurezza per le compagnie e i loro clienti. Ancora peggio, avrebbe messo a rischio la privacy dei clienti, la cui attività sarebbe potuta essere monitorata da terze parti senza necessità di essere in possesso dei dovuti permessi e delle dovute ragioni.

il nostro processo non ci richiede di rivelare al pubblico il nostro saldo totale, indirizzi o chiavi. Combinando e facendo leva sulle qualità di un auditor affidabile e su crittografia pubblicamente verificabile, l'audit di Kraken rappresenta il giusto equilibrio tra privacy e trasparenza.

Essendo Bitcoin la criptovaluta dominante, il nostro audit di partenza coprirà solo le riserve di Bitcoin. Considereremo la possibilità di eseguire audit su altri asset in futuro.

Panoramica del Processo

  • Fase 1 - L'auditor controlla i fondi dell'intero portafoglio di Kraken

    Kraken consegna al revisore tutti gli indirizzi pubblici e li firma. L'hash del blocco al momento della firma è parte del messaggio firmato e può essere utilizzato come timestamp per quando è stata effettuata la firma. Verranno quindi verificate le firme di tali indirizzi pubblici e il revisore utilizzerà la blockchain bitcoin per estrarre l'importo totale disponibile a tali indirizzi in un determinato momento.

    Il codice richiesto per questa fase è stato scritto da Michael Gronager, COO presso Payward, e potrebbe essere open source in futuro nella sua interezza. Tuttavia, la maggior parte del codice è già open source perché il codice è basato su libcoin. [2]

  • Fase 2 - Il revisore verifica che i saldi degli utenti Kraken corrispondano ai fondi del portafoglio Kraken

    Kraken fornisce al revisore i saldi BTC di ciascuno dei nostri utenti e genera un albero Merkle. L'auditor pubblicherà l'hash del nodo radice affinché tutti possano vedere, e affermerà, se è vero, che le partecipazioni totali rappresentate dall'hash radice si avvicinano molto al valore che vede nel nostro portafoglio dalla blockchain. Questo flusso garantisce inoltre che Kraken non stia nascondendo nulla in nessuno dei nodi che portano al nodo radice.

    Per questa fase dell'audit, il revisore avrà accesso al codice sorgente per il programma di generazione di alberi e il file di dati dei saldi dei conti individuali. Kraken ha rilasciato il codice C++ per questa fase con la licenza MIT:  https://github.com/payward/krakendb

  • Fase 3 - Gli utenti verificano in modo indipendente che i loro saldi dei conti siano stati inclusi nei dati utilizzati dal revisore

    Kraken fornisce agli utenti l'importo che abbiamo segnalato all'auditor, così come i nodi (e nodi adiacenti) dal loro account alla radice (che corrisponde a quello pubblicato dall'auditor). Divulghiamo anche il metodo di hashing utilizzato per generare l'hash per il loro nodo, in modo che possano verificare che il nodo rappresenti la quantità che noi affermiamo di fare.

    Ciò consentirà agli utenti di verificare autonomamente che il loro account è stato incluso nei dati verificati dal revisore.

Difetti e mancanze

In questa sezione descriviamo alcuni dei difetti e delle lacune di questo processo di audit. Notare che non è una lista esaustiva di mancanze. Comunque, siccome vogliamo essere trasparenti ai nostri clienti, forniamo un informale estratto dei difetti da noi finora rilevati sul processo di audit.

Diversamente dagli oggetti fisici, le informazioni informatiche necessitano di essere private ad uno per essere in totale possesso di un altro. Perciò, Kraken o altre compagnie che usano questo metodo non possono provare che le chiavi private non possano essere duplicate da un malintenzionato. Non possiamo nemmeno provare che siamo gli unici che entrano in possesso di tali dati. Possiamo solo provare che al momento dell'audit, eravamo uno dei possessori delle chiavi private.

L'audit probabilmente non potrà essere eseguito on-demand, senza preavviso. Date le informazioni necessarie, la struttura dell'audit, e gli standard di sicurezza ad oggi applicati ai cold storage, un audit "a sorpresa" non è eseguibile in giornata. Nella nostra visione futura c'è un audit versione 'light' che si basa su un audit precedentemente eseguito e che sfrutta firme generate in precedenza, e che potrebbe essere eseguito più frequentemente.

L'auditor deve essere affidabile e competente. La community deve porre fiducia nell'auditor, nei suoi valori e competenze. Ci sono svariati passaggi in questo processo dove un auditor meno attento o meno "paranoico" di un altro potrebbe ricadere in qualche trappola tesa dall'entità sotto indagine. Esiste anche l'eventualità per cui l'auditor potrebbe (intenzionalmente o non) compromettere informazioni confidenziali della compagnia o del cliente. Sia l'auditor che l'entità sotto indagine devono considerare chi fornisce i computer, le risorse per l'audit, la blockchain, la connessione Internet, il router, DNS, ecc. Se l'obiettivo è eseguire una frode da un milione di dollari, un malintenzionato potrebbe prendersi carico di un lungo lavoro per sfruttare queste inefficienze.

L'audit non è continuamente aggiornato in tempo reale. Potrebbe essere che le chiavi o i fondi siano persi dal momento dell'audit. Nonostante l'audit rafforza l'affermazione che le chiavi non siano andare perdute, crea un'esposizione al rischio in quanto è necessario usare chiavi private del cold storage per la sua esecuzione.

L'entità sotto indagine potrebbe essere in grado di utilizzare temporaneamente dei fondi o dei dati per poter passare il test durante l'audit.

L'auditor potrebbe essere colluso o soggetto a minacce da parte dell'entità sotto indagine.

Con Continuità

Vogliamo che questi audit vengano eseguiti con continuità. Non essendoci un auditor riconosciuto globalmente, potremmo usare un auditor differente, o diversi auditor allo stesso tempo. Questo per soddisfare chi potrebbe dubitare dell'affidabilità di un particolare auditor.

Futuri cambiamenti e miglioramenti

Speriamo di ricevere un feedback dalla community che aiuti noi e gli altri a migliorare questo processo di audit per il futuro. Come membri di questa community, anche noi speriamo di lavorare con organizzazioni come DATA (www.datauthority.org) per aiutare a sviluppare i basic standards, strumenti per la scalabilità e istruzioni per far eseguire questo audit anche ad altri attori di questo settore.

Riferimenti

[1] Summary by Zak Wilcox: https://iwilcox.me.uk/2014/proving-bitcoin-reserves. Vogliamo ringraziare Greg Maxwell per le sue idee.

[2] libcoin is the transformation of bitcoin into modular, reusable libraries: https://github.com/libcoin/libcoin

Come verificare attraverso l'audit che il saldo del tuo account Kraken è nelle nostre riserve

Vedi anche: Processo di Audit sulla Prova di riserve Kraken.

Queste istruzioni spiegano come verificare criptograficamente il saldo del tuo account Kraken e la sua inclusione nell'audit.

Questa verifica rifletterà il saldo di bitcoin (XBT) del tuo account al momento dell'audit.

 

  • Passo 1

    Fail il login nel tuo account Kraken, se non già eseguito.

    Vai su https://www.kraken.com/ e assicurati che la barra degli indirizzi del tuo browser mostri "https://www.kraken.com/"

  • Passo 2

    Clicca sulla tab "Funding"e poi su -> "Audit" nel sotto-menu -> e "Bitcoin (XBT)" sulla sinistra.

    Figura 1. Kraken Bitcoin Audit page

  • Passo 3

    Vedi le informazioni riguardanti il tuo account, verificate dall'auditor

    • L' ora dell'audit, che è il timestamp usato dall'auditor.

    • Il codice della richiesta (64 bit).

    • La Quantità  di Bitcoins nel tuo account all'ora dell'audit.

    • Note  include informazioni dell'auditor che prova il root hash utilizzato per l'audit. Viene fornito anche un link per un report firmato e dettagliato.

    • Gli Hash dal tuo node hash al root hash, inclusi gli hash adiacenti. Gli Hash diretti sono mostrati con un asterisco (*) per distinguerli da quelli adiacenti. Con questi hash, puoi verificare che il tuo node è incluso nel root:

    • La prima linea deve corrispondere al root hash fornito dall'auditor.

      Se vuoi verificare il tuo node hash (l'ultimo con un asterisco nella lista), devi:

      sha256(sha256(<submission code> || ":" || <amount with decimal point removed and leading 0's removed>))
      

      Questo valore deve corrispondere con l'ultimo fornito nel campo degli hash.

      Esempio

      Codice richiesta: 379377cd8190f9bf

      Quantità: 0.01500000

      Python

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

      PHP

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

      Risultato

      66b51ba0f4a5cf8278acac6782ffdfb9a64b9f7c895bc308266b0757c7025b27
      

      Puoi verificare i tuoi Merkle branches facendo un hash per ogni paio di hashe (o “tuple”). Il formato è:

      sha256(hash-sinistro || hash-destro)
      

      Il risultato deve corrispondere al precedente tuple hash (o al root hash) con un *. Questo dovrebbe essere fatto per tutti i tuples.

      Ad eccezione del root hash, tutti gli hash sono forniti come tuple, rappresentando l'hash sinistro e destro in quest'ordine. Un asterisco * va a rappresentare i tuoi direct nodes.

      Esempio:

      Hash:

      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3* c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b* 5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c
      

      Python

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

      PHP

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

      Risultato

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3