SwissBorg: Proof of Liabilities

A chi si rivolge questo report?

Lettore: tutti.

Livello tecnico: medio.

Conoscenze richieste: un po' di crittografia.

Essere aggiornati sull'informatica.

Questo documento vuole essere accessibile al maggior numero possibile di lettori. Detto questo, si tratta di una spiegazione tecnica di processi computazionali, che richiede al lettore una certa conoscenza di teoria dell'informatica e di crittografia per comprendere appieno l'argomento.

Introduzione

Gli eventi recenti nel mondo crypto hanno reso chiarissimo che il pubblico ha il diritto di sapere che i propri saldi sono al sicuro, controllati e disponibili per la verifica.

Nell'ambito della nostra iniziativa per la trasparenza chiamata In SwissBorg We Trust, siamo lieti di annunciare il lancio del SwissBorg Proof of Liabilities Portal, una soluzione di reporting web che permette ai nostri utenti di vedere le proprie passività, assicurando che i loro saldi siano stati inclusi nella somma totale.

In sostanza, un protocollo di Proof of Liabilities mostra il totale delle passività verso gli utenti e permette a ogni utente di verificare che le proprie passività siano incluse nel totale, dimostrando di fatto che non sono state omesse dal totale né ridotte.

In linea con la filosofia di SwissBorg incentrata sulla community, da tempo era un requisito che i nostri utenti potessero verificare da soli che le proprie passività fossero incluse nella nostra PoL, senza dover dipendere da un revisore esterno. Rendere questo controllo semplice per gli utenti è stato un elemento chiave del meccanismo di verifica della PoL.

Nella ricerca della soluzione giusta, il team di ingegneria di SwissBorg ha creato un meccanismo di verifica della PoL basato su consolidate tecniche crittografiche ad albero di Merkle, che offrono una base tecnica solida e nota su cui costruire.

Per l'implementazione abbiamo scelto una soluzione web in cui è il browser a verificare le passività dell'utente, offrendo piena trasparenza sul processo di verifica a chiunque voglia vedere e ispezionare il codice e i dati.

Crediamo che, grazie a questi metodi di verifica e di implementazione robusti e affidabili, la nostra soluzione PoL combini nel miglior modo possibile l'autoverifica e la facilità d'uso.

Questo articolo spiega le scelte crittografiche, di progettazione e di sviluppo alla base della soluzione Proof of Liabilities di SwissBorg, per aiutarti a capire meglio perché e come è nata.

Se trovi questo documento troppo tecnico ma vuoi comunque sapere come fare la verifica, vai alla sezione "Come verificare" più avanti per i passaggi.

Per dare un orizzonte temporale, i nostri prossimi passi sono illustrati nella timeline qui sotto:

Le basi

Un documento o una dashboard di Proof of Liabilities (PoL) usa un protocollo che fa interagire un Prover e i Verifier per mostrare le passività tra le due parti. Com'è logico, il Prover fornisce la prova e il Verifier la riceve e ne controlla la correttezza. Nel nostro caso, il Prover è SwissBorg e i Verifier sono i nostri utenti.

Le passività sono i saldi che gli utenti detengono nei propri wallet gestiti da SwissBorg. Il valore di queste passività, o saldi, è rappresentato semplicemente da un numero positivo.

L'obiettivo principale del servizio PoL è permettere agli utenti di verificare che i propri saldi siano inclusi nella somma totale delle passività di tutti gli utenti. In sostanza, una PoL dà la garanzia che il Prover non possa aver omesso le passività di un utente.

Divulgazione delle passività

Il metodo più semplice per fornire una PoL è quello in cui la società mostra pubblicamente quanto detiene ciascuno dei suoi utenti, come se la tua banca pubblicasse un estratto con tutte le disponibilità di tutti i clienti. In termini più tecnici, è il caso in cui il Prover mostra un elenco di tutti i Verifier e delle loro passività. Questo elenco deve mostrare chiaramente tutte le informazioni, essere liberamente accessibile al pubblico e, idealmente, restare dinamico per riflettere qualsiasi modifica.

In un esempio molto semplificato, vediamo un registro di conti, i valori associati e il totale: un registro in cui il Prover ha messo le informazioni a disposizione di tutti per essere viste e ispezionate, e in cui gli utenti fanno da Verifier per assicurarsi che le informazioni siano corrette.

Alice: 9 USD

Bob: 6 USD

Carlos: 7 USD

Diana: 4 USD

----------------------

Totale: 26 USD

In questo esempio di base ci sono alcuni punti chiave da considerare.

• Ogni utente può verificare che le proprie passività corrispondano a quelle elencate e che la somma di tutte le passività sia pari al totale pubblicato.
• Se il Prover omette le passività degli utenti o le indica in modo errato, il Prover ne è chiaramente responsabile e corre il rischio di essere scoperto.
• Questo approccio elementare funziona, ma presenta gravi limiti, in particolare per quanto riguarda la privacy.

Guardando agli attributi più specifici della PoL, i temi seguenti mostrano le qualità fondamentali che devono essere presenti nel processo PoL e comunicate ai Verifier.

Privacy

Divulgare informazioni finanziarie insieme alle identità dei rispettivi utenti è chiaramente escluso, e non fa parte del nostro processo di reporting PoL.

Immutabilità
Un altro possibile problema è la malleabilità delle informazioni divulgate. In pratica, il Prover potrebbe mostrare elenchi di passività diversi a utenti diversi, nel tentativo di ridurre il valore reale del totale delle passività. Per superare questa minaccia occorre introdurre una "impronta pubblica dei dati" che ogni singolo utente può verificare, per garantire che tutti abbiano ricevuto lo stesso insieme di dati. In informatica, questo tipo di infrastruttura di pubblicazione si chiama Public Bulletin Board (PBB), o bacheca pubblica.

Sul tema dell'immutabilità vale la pena citare altre due proprietà da far rispettare:

Saldi positivi

Parte della verifica della somma dei saldi degli utenti consiste nel controllare che ogni saldo sia positivo. Un Prover malintenzionato può aggiungere voci false - che non corrispondono a nessun utente - senza alcun rischio di essere scoperto.

Anche se il Prover potrebbe aggiungere queste voci false, non avrebbe alcun incentivo a farlo, perché aumenterebbe solo le passività a suo carico. Dal punto di vista degli utenti, l'unica cosa che cambierebbe è che il Prover sembrerebbe meno solvibile di quanto sia in realtà, quindi non c'è un vero incentivo.

Unicità degli identificativi utente

Quando le passività di tutti gli utenti vengono divulgate pubblicamente, ogni singola passività deve ovviamente essere collegata al rispettivo utente tramite un identificativo.

Su questo tema c'è una mossa scorretta che il Prover potrebbe fare. Se due utenti diversi avessero esattamente lo stesso saldo, potrebbero ricevere entrambi lo stesso identificativo e diventare così lo stesso "utente" con la stessa prova di inclusione, permettendo a SwissBorg di ridurre di fatto la somma in cima all'albero di Merkle. Conteremmo i saldi dei due utenti una volta sola.

Nel nostro sistema l'identificativo utente è unico sia per il singolo utente sia per il nostro sistema, il che lo rende univoco e distinguibile da quello degli altri utenti.

La Proof of Liabilities di SwissBorg

Scelte di progettazione di alto livello

Il design specifico del servizio Proof of Liabilities di SwissBorg è il risultato dell'uso di metodi esistenti allo stato dell'arte, adattati ai nostri requisiti specifici - più valute, verifica nel browser, nessun revisore esterno - insieme alla necessità di un'implementazione e di un rilascio rapidi.

Dopo aver analizzato la letteratura esistente sui protocolli di PoL, è emerso chiaramente che potevamo scegliere tra due opzioni principali:

• Basata su un albero di Merkle standard
• Basata su crittografia avanzata (ad es. zk-SNARK)

La prima scelta, l'approccio basato su un albero di Merkle standard, deriva da primitive crittografiche consolidate che si possono implementare facilmente in quasi tutti i linguaggi di programmazione, mentre i protocolli basati su crittografia avanzata richiederebbero librerie crittografiche avanzate e "di nicchia", con uno sforzo di implementazione molto maggiore.

A orientare ulteriormente la decisione, l'uso di primitive crittografiche semplici e ben comprese rende il risultato meno soggetto a errori. Per questo motivo, il nostro design della PoL si basa sulla linea di lavoro sugli alberi di Merkle avviata dalla proposta Maxwell-Todd del 2013, presentata da Gregory Maxwell e Peter Todd. Abbiamo studiato la letteratura e le implementazioni funzionanti esistenti per applicare i miglioramenti più recenti.

Chi è Merkle e perché ha un albero?

Le funzioni di hash crittografiche sono l'ingrediente centrale di numerosi protocolli crittografici. Un hash è una funzione che prende un input di qualsiasi dimensione e restituisce un output piccolo e di dimensione fissa. Ad esempio, l'input "Satoshi" darà come output le 4 cifre 2341, e l'input di tutto il testo del primo libro di Harry Potter darà anch'esso un output di sole 4 cifre, 7654.

Gli hash producono output della stessa lunghezza a partire da input di lunghezza diversa, e dall'output non si può risalire all'input. Grazie a questa caratteristica, l'output, chiamato anche "hash", è un'impronta computazionalmente unica del suo input.

Quando poi si calcola l'hash dell'hash, inizia a formarsi una struttura che si riduce a ogni iterazione e ricorda foglie, rami e un tronco. Man mano che la sequenza prosegue, i dati in qualsiasi punto del processo non possono essere modificati, altrimenti cambierebbero anche tutti gli hash successivi: si ottiene così una struttura in cui i dati di input sono al riparo da modifiche.

Il concetto di albero di Merkle risale all'invenzione della crittografia a chiave pubblica alla fine degli anni '70 e prende il nome dal suo inventore, Ralph Merkle. Nella sua forma più semplice, un albero di Merkle è una struttura dati simile a un albero binario in cui ogni foglia è l'hash di un blocco di dati e ogni nodo padre è l'hash di entrambi i figli:

Hparent = Hash ( HA | | HB ) [ se HA e HB sono i rispettivi valori di hash dei figli ]

In cima, l'elemento radice (e sì, sappiamo che le radici degli alberi stanno in basso, sottoterra, ma stai al gioco) contiene un hash che in sostanza aggrega tutti i dati sottostanti.

Per via delle proprietà delle funzioni di hash, è impossibile modificare i dati in qualsiasi punto dell'albero senza cambiare il valore di hash della radice: se qualcosa cambia, cambia anche il resto della struttura. Fin qui non è molto diverso dal calcolare l'hash di tutti i dati. Quello che l'albero di Merkle permette di fare, però, è aggregare un gran numero di input di dati - detti anche blocchi - in modo da rendere molto efficiente la verifica dell'inclusione di uno specifico blocco di dati.

In altre parole, questo metodo di verifica può servire a dimostrare che un dato blocco è stato incluso nell'albero e che si trovava sul percorso dei successivi nodi fratelli (sul "percorso di inclusione") fino all'hash radice. Per questo la dimensione della prova di inclusione diventa logaritmica anziché lineare: con 1 milione di foglie, la prova contiene solo 20 nodi, senza contare il nodo radice.

In cima all'albero, il valore di hash della radice funziona come un vincolo di impegno (commitment): una volta mostrato questo valore, i dati sottostanti non possono più essere modificati. Il rovescio della medaglia è che è impossibile sostenere che siano stati inclusi dati che non c'erano quando l'albero di Merkle è stato costruito, perché è tutto visibile e non può essere manomesso.

La linea Maxwell-Todd della PoL

Come detto sopra, la prima proposta di PoL basata su un albero di Merkle si deve a Maxwell-Todd, nel 2013. La loro proposta prevedeva un albero di Merkle con blocchi di dati che includevano il saldo di un utente. Inoltre, ogni nodo di questo albero di Merkle è arricchito con una passività pari alla somma di tutte le passività dei rispettivi nodi figli. Per questo ogni nodo è composto da un digest e da un saldo positivo.

In questo modo il saldo del nodo radice diventa la somma di tutte le passività verso gli utenti. Questa struttura dati si chiama "summation Merkle Tree" (albero di Merkle con somma), come si vede nel diagramma qui sotto.

Ed è qui che le cose si fanno interessanti. Il valore di hash di un nodo foglia si ottiene calcolando l'hash dell'ID dell'utente, della sua credenziale e del suo saldo. La credenziale dell'utente serve a mascherare l'ID utente, per proteggerne la privacy. Per rendere il metodo più sicuro, la posizione del nodo foglia di un dato utente viene scelta a caso, così da spezzare il collegamento tra un utente e il suo saldo. Il valore di hash di ogni altro nodo si calcola applicando l'hash alle passività dei nodi figli e ai rispettivi valori di digest.

Hparent = Hash ( BalA | | BalB | | HA | | HB )

Per mostrare a un utente che le sue passività sono incluse nell'albero di Merkle, il Prover fornisce un percorso di inclusione. Si procede come con un albero di Merkle standard, con in più la somma delle passività.

Nella verifica, l'utente calcola l'hash del nodo padre, come sopra, e poi controlla la somma dei saldi dei figli. Nell'ambito di questo controllo, l'utente verifica anche che BalA e BalB siano entrambi positivi e che BalA + BalB = Bal, dove BalA e BalB sono i saldi dei figli e Bal la passività del padre. Questa verifica viene eseguita a ogni livello dell'albero di Merkle, dalle foglie fino alla radice.

Osserviamo che l'albero di Merkle con somma descritto sopra è una versione leggermente modificata dell'albero di Merkle originale di Maxwell-Todd, perché applica le indicazioni di un articolo accademico di Hu, Zhang e Guo (2019), che ha corretto una falla di sicurezza. La nuova variante dell'albero di Merkle, aggiornata con questa correzione, è stata battezzata "Maxwell+ Merkle Tree" in un articolo accademico di Ji-Chalkias (2021), e il nome è rimasto.

Proseguendo su questa linea, l'articolo di Ji-Chalkias (2021) cita un metodo per nascondere i saldi originali degli utenti dividendo ciascuno in più frammenti (shard) - un'idea attribuita a Chalkias, Lewi, Mohassel e Nikolaenko nel 2019 - e mescolandoli a caso tra le foglie dell'albero. Seguendo la stessa logica di denominazione, questa variante successiva è stata chiamata Maxwell++ Merkle Tree da Ji-Chalkias (2021).

Mettendo tutto insieme, possiamo dire che l'evoluzione di questo metodo crittografico verso un uso pratico nella Proof of Liabilities è arrivata con l'iterazione di Maxwell-Todd, in cui l'albero di Merkle ha potuto includere la somma. Proseguendo nella storia dell'innovazione, è stata scoperta e corretta una falla di sicurezza, che ha portato alla nascita e all'uso della variante Maxwell+, e la versione finale, in cui il saldo di ogni utente viene diviso in frammenti per offuscare le passività reali degli utenti, ha dato origine a Maxwell++. Ognuno di questi miglioramenti è stato importante e accolto con favore dalla community. Siamo contenti di usare questa tecnologia anche nella nostra soluzione.

Le scelte di design di SwissBorg

Dato che l'app SwissBorg supporta diverse valute fiat e criptovalute, di solito gli utenti ne possiedono più d'una. In linea di principio potremmo usare un unico albero di Merkle per tutte le valute contemporaneamente, sommando i saldi valuta per valuta. Tuttavia, per molti utenti la ripartizione delle valute nel portafoglio è unica e creerebbe quindi un serio problema di privacy.

Per mitigare questo rischio, il nostro design gestisce ogni valuta separatamente, costruendo un albero di Merkle dedicato per ciascuna valuta. Aggreghiamo poi tutti i dati delle radici degli alberi di Merkle in un cosiddetto Audit Commitment Hash, cioè il valore di hash di tutte le passività per valuta e dei rispettivi hash radice degli alberi.

In sostanza, l'intera costruzione può essere vista come un unico albero di Merkle, con la differenza che il livello superiore ha tanti rami quante sono le valute. Per questo, per verificare le passività, tutte le radici degli alberi di Merkle delle valute devono essere inviate come parte della prova di inclusione.

Per migliorare ulteriormente la privacy dei saldi degli utenti, dividiamo ogni saldo in almeno 2 sotto-saldi o frammenti positivi, la cui posizione tra le foglie dell'albero di Merkle viene determinata a caso. Per semplicità, e per nascondere in parte il numero di utenti per valuta, generiamo sempre un numero di sotto-saldi pari a una potenza di 2, così che l'albero binario di Merkle sia completo.

Vale la pena notare che la divisione dei saldi è in linea con la soluzione PoL di Bitmex e con la variante Maxwell++ con un fattore di divisione > 2.

Seguendo il design Maxwell++, la privacy degli utenti si ottiene includendo nei dati delle foglie alcuni nonce di mascheramento ad alta entropia: partendo da un nodo foglia - l'hash e il saldo - non è possibile risalire all'identità dell'utente corrispondente. Questo cosiddetto "leaf nonce" deriva da una credenziale di audit per utente, cioè un valore casuale a 128 bit dedicato esclusivamente alla PoL.

Dove trovo la mia credenziale?

Trovi la tua credenziale nella scheda Sicurezza dell'app SwissBorg. L'abbiamo chiamata "credenziale" per sottolineare che i nostri utenti devono tenerla riservata, perché qualcuno potrebbe usarla per rivelare i saldi di un utente, con i relativi nodi foglia.

La credenziale è pensata per essere conservata a lungo e riutilizzata in più audit di Proof of Liabilities. Seguendo le prassi crittografiche standard, i leaf nonce vengono derivati - con una funzione crittografica di derivazione della chiave (Key Derivation Function) - in modo gerarchico:

• Identificativo dell'audit, credenziale di audit dell'utente → Audit Nonce
• Audit Nonce, valuta → Merkle Tree Nonce
• MT Nonce, indice della foglia → nonce del nodo foglia
• Dati della foglia: leaf nonce, userId, frammento di saldo

Un altro dettaglio importante è che questi diversi livelli di nonce potrebbero essere usati per rivelare informazioni relative alle passività dell'utente a diversi livelli di dettaglio, ad esempio per audit o per valuta.

Naturalmente ognuno ha bisogno di un identificativo utente, e per questo abbiamo deciso di usare lo SwissBorg ID, che resta associato al suo utente in ogni fase del processo. Lo trovi facilmente nell'app, in fondo al menu Profilo, nel formato "ID: 20XXX". Questo identificativo non cambia mai ed è unico per ogni utente.

Il servizio PoL di SwissBorg fornisce diversi percorsi di inclusione nell'albero di Merkle, uno per ogni frammento di sotto-saldo dell'utente, che vengono verificati da uno script eseguito nel browser e restituiscono i saldi totali di quell'utente.

Il controllo di verifica viene eseguito rispetto agli audit commitment hash, che verranno resi pubblici tramite Twitter. L'algoritmo si può riassumere così:

1. Tutti i nodi radice degli alberi di Merkle vengono confrontati con l'"Audit Commitment Hash". Inoltre, l'utente può controllare che questo hash corrisponda a quello pubblicato su Twitter.
2. Per ogni percorso di inclusione, il percorso viene verificato calcolando ricorsivamente il nodo padre con il nodo fratello fornito dalla prova di inclusione e controllando che il nodo in cima corrisponda a uno dei nodi radice degli alberi di Merkle verificati al passaggio precedente. In questo processo si controlla anche che ogni nodo fratello abbia passività positive.
3. Dopo ogni verifica riuscita di una prova di inclusione, il saldo della foglia corrispondente viene aggiunto alle passività totali dell'utente.
4. Se non si è verificato alcun errore, all'utente vengono restituite le sue passività totali.

Discussione

Il design della Proof of Liabilities di SwissBorg si basa su una costruzione ad albero di Merkle allo stato dell'arte, che garantisce la massima privacy delle identità degli utenti e delle relative passività. Inoltre, abbiamo scelto di puntare sulla semplicità d'uso e sull'autoverifica da parte degli utenti, quindi non serve coinvolgere un revisore esterno, a differenza di diverse altre soluzioni di Proof of Liabilities, come quella di Kraken ad esempio.

Il nostro approccio è più in linea con il modo in cui Bitmex ha scelto di farlo, con la differenza principale che la nostra verifica è più leggera e supporta più valute.

Questa leggerezza deriva dal fatto che l'utente non deve scaricare un intero albero di Merkle, ma solo le prove di inclusione, che rappresentano solo una piccola parte dell'albero. Questo permette una verifica nel browser che l'utente può ispezionare, se lo desidera.

Siamo giunti alla conclusione che non pubblicare gli alberi di Merkle completi non è in alcun modo una vulnerabilità, perché l'audit commitment hash garantisce l'integrità dei dati sottostanti: è crittograficamente impossibile modificare in seguito qualsiasi dato nell'albero di Merkle.

La divulgazione dell'albero di Merkle completo può solo garantire che la struttura sia ben formata, nel senso che tutte le passività sono positive e che gli hash dei nodi non foglia sono corretti.

Limiti

Quanto ai limiti, un utente che esegue la verifica non può accorgersi se la passività di un altro utente è errata o è stata omessa. Per scoprire una manipolazione da parte di un fornitore malintenzionato serve la verifica degli utenti interessati, indipendentemente dalla pubblicazione dell'albero di Merkle completo o delle prove di inclusione.

La garanzia che il numero totale delle passività e il valore totale delle passività non siano stati ridotti dal fornitore dipende dal livello di coinvolgimento degli utenti.

Con questo sistema di autoverifica senza terze parti, basato solo sulle prove di inclusione, più utenti controllano le proprie passività, meglio è. Più persone guardano le informazioni, infatti, più è probabile che un eventuale errore venga notato e più forte è il consenso tra gli utenti.

Il principio di base è: "più persone controllano qualcosa, meno è probabile che il Prover possa manipolarlo senza essere notato".

Nella Sezione 5 dell'articolo accademico già citato di Ji-Chalkias, gli autori presentano un calcolo dettagliato di quanti utenti devono verificare le prove di inclusione per scoprire un comportamento scorretto da parte del Prover.

La nostra soluzione ha altri limiti che non rappresentano una minaccia per la sicurezza e su cui lavoriamo costantemente per migliorarli. Questi limiti riguardano:

• alcune informazioni sulle singole passività - con assolutamente nessun collegamento agli ID utente,
• la privacy del numero di utenti per valuta,
• le passività totali.

A nostro avviso, il primo punto dell'elenco - il limite di privacy sulle informazioni relative alle singole passività - è stato risolto con la nostra soluzione grazie alla "divisione dei saldi", che mostra comunque informazioni parziali, ad esempio se un saldo supera un certo importo, ma non dati personali sensibili.

Per chiarire, dividere i saldi significa semplicemente frammentare il saldo originale dell'utente in sotto-saldi, in modo che la somma dei sotto-saldi = saldo originale. Così il saldo originale non compare nell'albero di Merkle.

Il secondo e il terzo limite riguardano soprattutto informazioni che il fornitore potrebbe voler mantenere riservate e non comportano un vero rischio per la privacy dei nostri utenti. La buona notizia è che si sta lavorando a soluzioni moderne basate su costruzioni crittografiche più avanzate, come gli zk-SNARK, che risolvono questi problemi e ci daranno in futuro la possibilità di implementarle e ridurre ancora di più i limiti.

Al momento, essendo così recenti, queste soluzioni sono meno accessibili e richiedono più sviluppo da parte nostra. Per questi motivi abbiamo deciso di implementare prima la collaudata soluzione ad albero di Merkle, dato che i problemi rimanenti non sono affatto critici.

Seguiamo da vicino tutte queste soluzioni, tra cui la molto discussa proposta di Vitalik e la promettente soluzione Dapol+ di Ji-Chalkias già citata, che ha attirato per la prima volta l'attenzione della comunità crittografica alla Computer and Communications Security Conference, ACM CCS 2021. Continueremo a far evolvere la nostra soluzione, integrando i miglioramenti man mano che arrivano, sempre guardando avanti.

Perché nessun revisore esterno?

L'autoverifica da parte degli utenti era un requisito imprescindibile del nostro sistema, ma questo non esclude che in futuro possa essere coinvolto un revisore esterno. Uno dei possibili vantaggi di coinvolgerne uno è aumentare la capacità di rilevamento, senza affidarsi solo al coinvolgimento degli utenti per scoprire un fornitore fraudolento.

Ecco alcuni buoni esempi di questo contributo positivo.

• Un revisore esterno potrebbe verificare in modo sistematico alcuni campioni di passività degli utenti rispetto alla Proof of Liabilities.
• Il coinvolgimento di un revisore per risolvere una controversia in cui un utente segnala passività errate o mancanti nel report di Proof of Liabilities.

Un problema del genere sembra difficile da risolvere con mezzi puramente tecnici, e il coinvolgimento di un revisore esterno potrebbe aiutare molto. A sostegno di questo punto, nella analisi di sicurezza di Chalkias sulla PoL di Binance, l'autore osserva che il coinvolgimento di un revisore potrebbe impedire al fornitore di tracciare gli utenti che eseguono la verifica e di omettere le passività di chi non controlla mai. Tutti aspetti da considerare per le versioni future.

Come verificare

Come utente, puoi controllare e verificare le tue passività visitando la pagina Secure with SwissBorg sul nostro sito.

Segui le istruzioni sulla pagina e inserisci il tuo Audit Credential ID personale, che trovi nella sezione Sicurezza dell'app SwissBorg.

È importante sapere che le passività che vedrai sono rilevate al momento dell'ultimo audit e quindi non sono una rappresentazione "in tempo reale" delle tue passività. Questi audit sono programmati a cadenza regolare, con una frequenza che verrà annunciata una volta definita.

Se hai dimestichezza con il termine "repo GitHub" e vuoi controllare e verificare le tue passività in locale sul tuo computer, segui le istruzioni nel codice sorgente pubblicato SwissBorg Proof of Liabilities Repo.

Conclusioni

Dimostrare ciò che deteniamo per i nostri utenti è diventata una prassi standard nel settore crypto, e siamo orgogliosi di aver sviluppato in modo indipendente una soluzione che offre agli utenti la possibilità di controllare le proprie disponibilità.

La prima versione del SwissBorg Proof of Liabilities Portal è stata rilasciata e permette a ogni utente di verificare facilmente le proprie passività senza dipendere da revisori esterni, raggiungendo al tempo stesso un elevato livello di sicurezza e privacy.

Si tratta di un'iniziativa in corso e teniamo d'occhio i possibili sviluppi. In particolare, quando sarà il momento potremmo valutare l'implementazione di una delle tecniche crittografiche più avanzate per rafforzare il sistema, come la proposta di Vitalik.

Le prove sicure, aperte, facili da usare e incentrate sull'utente sono un tema cruciale, su cui lavorano molti attori brillanti e da diverse prospettive. Detto questo, potrebbe volerci un po' prima che il settore converga verso una standardizzazione della PoL, ma la consideriamo un'evoluzione positiva e inevitabile, per tutti.

Per ora, però, ognuno conta su tutti gli altri: contiamo sui nostri fantastici utenti perché si prendano un momento per verificare le proprie passività tramite il Proof of Liabilities Portal, e, così facendo, sappiano che non solo si assicurano che le proprie crypto siano al sicuro e conteggiate, ma contribuiscono anche a rafforzare la fiducia in SwissBorg e nella nostra straordinaria community.

Disclaimer

Tieni presente che le informazioni sulle passività verso gli utenti fornite dal nostro protocollo di Proof of Liabilities sono registrate a partire dal sistema contabile interno di SwissBorg. SwissBorg non potrà essere ritenuta responsabile per eventuali saldi errati derivanti da sbagli o errori nel registro contabile. Il protocollo non fornisce informazioni su altre passività o rischi della società. Questo articolo ha esclusivamente scopo di orientamento generale e informativo e non costituisce un'offerta al pubblico di asset virtuali o strumenti finanziari, né una consulenza finanziaria, una consulenza in materia di investimenti o qualsiasi altro tipo di consulenza, e non deve essere interpretato o inteso come una qualsiasi forma di promozione, raccomandazione, sollecitazione, offerta o approvazione a (i) acquistare o vendere qualsiasi prodotto, (ii) effettuare transazioni o (iii) concludere qualsiasi altro atto giuridico. Né BlockNodes SAS né le sue affiliate rilasciano alcuna dichiarazione, garanzia o assicurazione in merito alla completezza, accuratezza, tempestività o idoneità delle informazioni contenute in qualsiasi parte di questo articolo, né al fatto che siano prive di errori.