SwissBorg: La preuve par les dettes, une innovation financière révolutionnaire

À qui s’adresse ce rapport ?

Lecteur : Tout le monde.
Niveau technique : Moyen.
Connaissances préalables : Quelques notions de cryptographie et être à jour en informatique.
Ce document se veut accessible à un large éventail de lecteurs. Cependant, il s’agit d’une explication technique de processus informatiques qui nécessite une certaine connaissance de la théorie informatique et de la cryptographie pour comprendre pleinement le sujet.

Présentation

Les récents événements dans le domaine des cryptomonnaies ont montré clairement que le public a le droit de savoir que ses soldes sont en sécurité, vérifiés et disponibles pour inspection. Dans le cadre de notre initiative de transparence intitulée “In SwissBorg We Trust”, nous sommes heureux d’annoncer le lancement du SwissBorg Proof of Liabilities Portal, une solution de rapport en ligne permettant à nos utilisateurs de voir leurs engagements, garantissant que leurs soldes ont été pris en compte dans la somme totale. Un protocole de Preuve de Responsabilité montre essentiellement les engagements totaux des utilisateurs et permet à chaque utilisateur de vérifier que ses engagements sont pris en compte dans le total, montrant ainsi que ses engagements n’ont pas été omis ou réduits. Conformément à la philosophie centrée sur la communauté de SwissBorg, il est depuis longtemps nécessaire que nos utilisateurs puissent vérifier eux-mêmes que leurs engagements sont inclus dans notre Preuve de Responsabilité, sans avoir à compter sur un auditeur tiers pour le leur montrer. Faciliter ce processus de vérification pour les utilisateurs a été une partie essentielle du mécanisme de validation de la Preuve de Responsabilité. Dans la recherche de la bonne solution, l’équipe d’ingénierie de SwissBorg a créé un mécanisme de vérification de la Preuve de Responsabilité basé sur des techniques cryptographiques bien établies de l’Arbre de Merkle, garantissant une base technique solide et connue sur laquelle construire. En ce qui concerne la mise en œuvre, nous avons choisi d’utiliser une solution basée sur le web où le navigateur valide les engagements de l’utilisateur, donnant une transparence totale du processus de validation à quiconque souhaite voir et inspecter le code et les données. Nous croyons qu’en utilisant ces méthodes de validation et de mise en œuvre solides et fiables, notre solution de Preuve de Responsabilité combine les approches d’auto-vérification et d’utilisabilité fluide de la meilleure façon possible. Cet article explique les choix de conception et de construction cryptographiques effectués pour la solution de Preuve de Responsabilité de SwissBorg, dans le but de vous donner une meilleure compréhension de pourquoi et comment elle a été créée. Si vous trouvez ce document trop technique, mais que vous voulez quand même savoir comment valider, rendez-vous à la section “Comment valider” ci-dessous pour les étapes. En ce qui concerne les étapes à venir, nos prochaines étapes sont présentées sur la chronologie ci-dessous : Perspectives futures pour la Preuve de Responsabilité. Perspectives futures pour la Preuve de Responsabilité.

Les Fondamentaux

Un document ou un tableau de bord Proof of Liabilities (PoL) utilise un protocole qui interagit entre un Prover et des Vérificateurs pour montrer les obligations entre les deux parties. Dans notre cas, le Prover est SwissBorg et les Vérificateurs sont nos utilisateurs. Les obligations sont les soldes que les utilisateurs détiennent dans leurs portefeuilles gérés par SwissBorg. La valeur de ces obligations, ou soldes, est simplement représentée par un nombre positif. L’objectif principal du service PoL est de permettre aux utilisateurs de vérifier que leurs soldes sont pris en compte dans la somme totale des obligations de tous les utilisateurs. En gros, un PoL garantit que le Prover n’a pas pu omettre les obligations d’un utilisateur.

Révélation des dettes

La méthode la plus simple pour fournir une preuve de passif (PoL) consiste à montrer publiquement combien chaque utilisateur détient, comme si votre banque affichait un relevé avec tous les avoirs de tous les clients. Plus techniquement, il s’agit de montrer une liste de tous les vérificateurs et de leurs passifs. Cette liste doit clairement afficher toutes les informations, être accessible au public et idéalement être maintenue dynamique pour montrer tous les changements. Dans un exemple simplifié, nous pouvons voir un registre des comptes, leurs valeurs associées et le total ; un registre où le fournisseur a fourni les informations pour que tous puissent les voir et les inspecter, et où les utilisateurs agissent en tant que vérificateurs pour s’assurer que les informations sont exactes.
Alice : 9 USD
Bob : 6 USD
Carlos : 7 USD
Diana : 4 USD
Total : 26 USD
Dans cet exemple de base, il y a quelques points clés à considérer. Chaque utilisateur peut vérifier que ses propres passifs correspondent à ceux indiqués et que tous les passifs s’additionnent au montant total publié. Si le fournisseur omet ou fournit de manière incorrecte les passifs des utilisateurs, le fournisseur est clairement responsable et prend le risque d’être découvert. Cette approche élémentaire fait le travail, mais présente de sérieuses lacunes, en particulier en ce qui concerne la confidentialité.
En ce qui concerne les attributs spécifiques de la PoL, les sujets ci-dessous montrent les qualités essentielles qui doivent être utilisées dans le processus de PoL et divulguées aux vérificateurs.
Confidentialité : La divulgation d’informations financières avec les identités des utilisateurs respectifs est clairement exclue et ne fait pas partie de notre processus de rapport de PoL.
Immutabilité : Un autre problème potentiel est la malléabilité des informations divulguées. En effet, le fournisseur peut afficher différentes listes de passifs à différents utilisateurs dans le but de réduire la valeur réelle du total des passifs. Pour surmonter cette menace, nous devons introduire une “empreinte digitale de données publiques” qui peut être vérifiée par chaque utilisateur pour garantir que tout le monde a reçu le même ensemble de données. En informatique, le terme utilisé pour désigner ce type d’infrastructure de publication est un “tableau d’affichage public” (PBB).
Dans ce domaine de l’immutabilité, il convient de mentionner deux propriétés supplémentaires qui doivent être respectées :
Soldes positifs : Une partie de la vérification de la somme des soldes des utilisateurs est une vérification que chaque solde est positif. Il est possible pour un fournisseur malveillant d’ajouter de fausses entrées – qui ne correspondent à aucun des utilisateurs – sans aucun risque d’être détecté. Même si le fournisseur pourrait ajouter ces fausses entrées, il n’y aurait aucun incitatif pour le fournisseur à le faire, car cela ne ferait qu’augmenter les passifs qu’ils détiennent. Du point de vue des utilisateurs, la seule chose qui changerait est que le fournisseur semblerait moins solvable qu’il ne l’est réellement, il n’y a donc aucun véritable incitatif.
Unicité des identifiants des utilisateurs : Lorsqu’il y a une divulgation publique de tous les passifs des utilisateurs, tous les passifs individuels doivent bien sûr être liés à leur utilisateur spécifique par le biais d’un identifiant. Dans ce domaine, le fournisseur pourrait faire un mouvement malicieux.

La preuve des passifs de SwissBorg

Choix de conception stratégiques

Le service Proof of Liabilities de SwissBorg a été conçu en utilisant des méthodes de pointe existantes, adaptées à nos besoins spécifiques tels que le support de plusieurs devises, la vérification dans le navigateur et l’absence d’auditeur externe. Après avoir étudié la littérature existante sur les protocoles PoL, nous avons constaté qu’il existait deux principales options : une approche basée sur l’arbre de Merkle standard et une approche basée sur la cryptographie avancée (par exemple, zk-snarks). Nous avons choisi d’utiliser l’approche basée sur l’arbre de Merkle standard, car elle repose sur des primitives cryptographiques établies, faciles à mettre en œuvre dans la plupart des langages de programmation, et présente moins de risques d’erreurs. Notre conception PoL s’appuie sur le travail de l’arbre de Merkle initié par la proposition de Maxwell-Todd en 2013, telle que présentée par Gregory Maxwell et Peter Todd. Nous avons étudié la littérature existante et les implémentations en cours pour appliquer les dernières améliorations.

Merkle et son arbre : Qui est-il et pourquoi possède-t-il un arbre ?

Les fonctions de hachage cryptographique sont un ingrédient essentiel de nombreux protocoles cryptographiques. Un hachage est une fonction qui prend une entrée de n’importe quelle taille et renvoie une sortie de taille fixe. Par exemple, une entrée de “Satoshi” renverra les 4 chiffres 2341, et l’entrée de tout le texte du premier livre de Harry Potter ne donnera également que la sortie de 4 chiffres 7654. Les hachages donnent des sorties de même longueur à partir d’entrées de longueurs différentes et la sortie ne peut pas être retracée jusqu’à l’entrée. En raison de cette caractéristique, cette sortie, également appelée “hachage”, est une empreinte unique calculée de manière informatique de son entrée. Lorsque vous prenez ensuite le hachage du hachage, une structure commence à se former, réduisant de taille à chaque itération, ressemblant à des feuilles, des branches et un tronc. Au fur et à mesure que cette séquence se poursuit, les données à n’importe quel point du processus ne peuvent pas être modifiées, sinon tous les hachages suivants changeraient également, ce qui conduit à une structure où les données d’entrée sont protégées contre les modifications. L’introduction de l’arbre de Merkle remonte à l’invention de la cryptographie à clé publique à la fin des années 1970 et porte le nom de son inventeur Ralph Merkle. Dans sa forme la plus simple, un arbre de Merkle est constitué d’une structure de données en arbre binaire où chaque feuille est le hachage d’un bloc de données et chaque nœud parent est le hachage des deux enfants.

Reformulation du sous-titre de section d’article de blog : “Le hparent est généré en utilisant le hash des valeurs HA et HB, si HA et HB sont des valeurs de hachage enfant respectives

Au sommet, l’élément racine (et oui, nous savons que les racines des arbres sont en bas de l’arbre dans le sol, mais allons-y) contient un hachage qui agrège essentiellement toutes les données sous-jacentes. L’arbre de Merkle permet d’agréger un grand nombre de blocs de données de manière très efficace pour vérifier l’inclusion d’un bloc de données spécifique. En d’autres termes, cette méthode de vérification peut être utilisée pour démontrer qu’un bloc de données donné a été inclus dans l’arbre et que ce bloc se trouvait sur le chemin des nœuds frères ultérieurs (sur le “chemin d’inclusion”) jusqu’au hachage racine. La valeur du hachage racine agit comme un verrou de commitment-lock car une fois cette valeur affichée, les données sous-jacentes ne peuvent pas être modifiées. D’un autre côté, il est impossible de prétendre que des données ont été incluses qui n’étaient pas présentes lorsque l’arbre de Merkle était en cours de construction, car tout est là à voir et ne peut pas être altéré.

La ligne de Maxwell-Todd du PoL reformulée de manière simple

Comme mentionné précédemment, la première proposition de PoL basée sur un arbre de Merkle est créditée à Maxwell-Todd en 2013. Leur proposition était basée sur l’utilisation d’un arbre de Merkle avec des blocs de données comprenant le solde d’un utilisateur. De plus, chaque nœud de cet arbre de Merkle est amélioré avec une responsabilité comprenant la somme de toutes les responsabilités des nœuds enfants respectifs. Pour cette raison, chaque nœud est composé d’un condensé et d’un solde positif. Ainsi, le solde du nœud racine devient la somme de toutes les responsabilités de l’utilisateur. Cette structure de données est appelée un “arbre de Merkle avec sommation”.Maintenant, les choses deviennent intéressantes. La valeur hachée d’un nœud feuille est obtenue en hachant l’identifiant d’un utilisateur, son accréditation et son solde. L’accréditation de l’utilisateur sert à masquer son identifiant, afin de protéger sa vie privée. Pour améliorer la sécurité de cette méthode, la position du nœud feuille d’un utilisateur donné est choisie au hasard pour rompre le lien entre un utilisateur et son solde. La valeur hachée de tout autre nœud est calculée en hachant les responsabilités des nœuds enfants et leurs valeurs de condensé respectives.

La reformulation demandée est : “Hparent est le résultat du hachage des valeurs BalA, BalB, HA et HB

Pour montrer à un utilisateur que ses responsabilités sont incluses dans l’arbre de Merkle, le Prover fournit un chemin d’inclusion. Cela se fait de la même manière qu’avec un arbre de Merkle standard, mais avec une sommation des responsabilités. Lors de la validation, l’utilisateur calcule le hash parent, comme précédemment, puis vérifie la sommation des soldes des enfants. Dans le cadre de cette vérification de sommation, l’utilisateur vérifie également que BalA et BalB sont positifs et que BalA + BalB = Bal, où BalA, BalB sont les soldes des enfants et Bal la responsabilité du parent. Cette étape de validation est effectuée à chaque niveau de l’arbre de Merkle, des feuilles jusqu’à la racine.

Nous notons que l’arbre de Merkle de sommation ci-dessus correspond à une version légèrement modifiée de l’arbre de Merkle original de Maxwell-Todd en raison de l’application des idées présentées dans un article académique de Hu, Zhang et Guo (2019) qui a corrigé une faille de sécurité. La nouvelle variante de l’arbre de Merkle a été mise à jour avec cette correction de faille de sécurité et a été appelée “Maxwell+ Merkle Tree” dans un article académique de Ji-Chalkias (2021) ; le nom est resté.

En poursuivant cette logique, dans l’article de Ji-Chalkias (2021), il est mentionné une méthode pour masquer les soldes d’origine des utilisateurs en les divisant en plusieurs fragments – une idée attribuée à Chalkias, Lewi, Mohassel et Nikolaenko en 2019 – et en les mélangeant au hasard dans les feuilles de l’arbre. Suivant cette logique de nomenclature, cette prochaine variante a été appelée “Maxwell++ Merkle Tree” par Ji-Chalkias (2021).

En résumé, nous pouvons dire que la progression de cette méthode cryptographique pour une utilisation pratique sur la Preuve des Responsabilités est venue avec l’itération de Maxwell-Todd où l’arbre de Merkle a été en mesure d’inclure la sommation. En avançant dans le temps de l’innovation, une faille de sécurité a été trouvée et corrigée, ce qui a conduit à l’établissement et à l’utilisation de la variante Maxwell+, et la version finale où le solde de chaque utilisateur a été divisé en fragments afin d’obscurcir les véritables responsabilités de l’utilisateur a donné naissance à Maxwell++. Chacune de ces améliorations a été importante et a été bien accueillie par la communauté. Nous sommes heureux d’utiliser cette technologie dans notre solution également.

Choix de conception de SwissBorg

L’application SwissBorg prend en charge plusieurs devises fiat et cryptomonnaies, ce qui fait que les utilisateurs en possèdent généralement plusieurs. En principe, nous pourrions utiliser un seul arbre de Merkle pour couvrir toutes les devises en appliquant la somme des soldes, par devise. Cependant, pour de nombreux utilisateurs, la répartition des devises dans leur portefeuille est unique et poserait donc un grave problème de confidentialité. Pour remédier à cela, notre conception traite chaque devise séparément en construisant un arbre de Merkle dédié par devise. Nous agrégeons ensuite toutes les données racines des arbres de Merkle dans un hash d’engagement d’audit, qui est la valeur de hachage de toutes les dettes en devises et des racines d’arbres respectives. Essentiellement, toute la construction peut être considérée comme un seul arbre de Merkle, la différence étant que la couche supérieure se compose de autant de branches que le nombre de devises. En raison de cette caractéristique, pour vérifier les dettes, toutes les racines des arbres de Merkle des devises doivent être envoyées dans le cadre de la preuve d’inclusion. Pour améliorer davantage la confidentialité des soldes des utilisateurs, nous divisons chaque solde utilisateur en au moins 2 sous-soldes positifs et leurs positions dans les feuilles de l’arbre de Merkle sont déterminées de manière aléatoire. Dans un souci de simplicité et pour masquer partiellement le nombre d’utilisateurs par devise, nous générons toujours un certain nombre de sous-soldes égal à la puissance de 2, de sorte que l’arbre binaire de Merkle soit complet. Il est important de noter que la division des soldes est conforme à la solution PoL de Bitmex et à la variante Maxwell++ avec un facteur de division > 2. En suivant la conception de Maxwell++, la confidentialité des utilisateurs est assurée en incluant des nonces de masquage de haute entropie dans les données des feuilles ; à partir d’un nœud feuille – le hash et le solde – il n’est pas possible de découvrir l’identité de l’utilisateur correspondant. Ce nonce de feuille, appelé “leaf nonce”, est dérivé d’une preuve d’audit par utilisateur, qui est une valeur aléatoire de 128 bits exclusivement consacrée aux fins du PoL.

Où puis-je trouver mes informations d’identification ?

Votre identifiant se trouve dans l’onglet de sécurité de l’application SwissBorg. Nous l’appelons “identifiant” pour mettre en évidence le fait que nos utilisateurs doivent le garder confidentiel, car quelqu’un pourrait le prendre et révéler les soldes d’un utilisateur – avec les nœuds correspondants. L’identifiant doit être conservé à long terme et réutilisé lors de plusieurs instances de vérifications Proof of Liabilities. En suivant les pratiques cryptographiques standard, les nonces de feuilles sont dérivés – avec une fonction de dérivation de clé cryptographique – de manière hiérarchique: Identifiant de vérification, identifiant de vérification de l’utilisateur → Nonce de vérification Nonce de vérification, devise → Nonce de l’arbre de Merkle Nonce de l’arbre de Merkle, index de la feuille → Nonce de la feuille Données de la feuille: nonce de la feuille, identifiant de l’utilisateur, fragment de solde Un autre détail important est que ces différents niveaux de nonces peuvent être utilisés pour révéler des informations relatives aux obligations de l’utilisateur à différentes spécificités, par exemple par vérification ou par devise. Bien sûr, tout le monde a besoin d’un identifiant d’utilisateur, donc pour cela, nous avons décidé d’utiliser l’identifiant SwissBorg, qui est associé à son utilisateur à tous les points du processus. Il peut facilement être trouvé dans l’application, en bas du menu Profil, sous la forme “ID: 20XXX”. Cet identifiant ne change jamais et est unique pour chaque utilisateur. Le service SwissBorg PoL fournit plusieurs chemins d’inclusion d’arbres de Merkle, un par fragment de sous-solde de l’utilisateur en fait, qui seront validés par un script exécuté dans le navigateur et afficheront les soldes totaux pour cet utilisateur. La vérification est effectuée par rapport aux hachages d’engagement de vérification qui seront rendus publics via Twitter. L’algorithme peut être résumé comme suit: Tous les nœuds racines de l’arbre de Merkle sont vérifiés par rapport au “Hachage d’engagement de vérification”. De plus, l’utilisateur peut vérifier que ce hachage correspond à celui publié sur Twitter. Pour chaque chemin d’inclusion, le chemin est validé en calculant de manière récursive le nœud parent avec le nœud sibling fourni par la preuve d’inclusion et en vérifiant que le nœud supérieur correspond à l’un des nœuds racines de l’arbre de Merkle qui ont été validés à l’étape précédente. Dans le cadre de ce processus, une vérification est effectuée pour chaque sibling afin de s’assurer qu’ils ont des obligations positives. Après chaque validation réussie de la preuve d’inclusion, le solde de feuille de l’utilisateur correspondant est ajouté aux obligations totales de l’utilisateur. Si aucune erreur ne s’est produite, les obligations totales de l’utilisateur sont renvoyées à l’utilisateur.

Échange de points de vue

Le concept de Proof of Liabilities de SwissBorg repose sur une construction basée sur les arbres de Merkle, garantissant ainsi la confidentialité maximale des identités des utilisateurs et de leurs responsabilités associées. Contrairement à d’autres solutions de Proof of Liabilities, comme celle de Kraken par exemple, nous avons choisi de mettre l’accent sur une opération facile et une vérification effectuée par l’utilisateur lui-même, sans nécessiter l’intervention d’un auditeur tiers. Notre approche est plus proche de celle adoptée par Bitmex, avec la principale différence étant que notre vérification est plus légère et permet de gérer plusieurs devises. Cette caractéristique de légèreté provient du fait que l’utilisateur n’a pas besoin de télécharger un arbre de Merkle complet, seulement les preuves d’inclusion, qui représentent seulement une petite fraction de l’arbre. Cela permet une validation dans le navigateur qui peut être inspectée par l’utilisateur s’il le souhaite. Nous en sommes arrivés à la conclusion que ne pas publier les arbres de Merkle complets n’est en aucun cas une vulnérabilité, car le hash d’engagement d’audit garantit l’intégrité des données sous-jacentes – il est cryptographiquement impossible de modifier les données de l’arbre de Merkle par la suite. La divulgation de l’arbre de Merkle complet ne peut garantir que la structure est bien formée, dans le sens où toutes les responsabilités sont positives et que les hachages des nœuds non-feuilles sont corrects.

Contraintes et restrictions

En ce qui concerne les limitations, un utilisateur qui valide ne peut pas détecter si une dette d’un autre utilisateur est incorrecte ou a été omise. Pour déceler une manipulation par un fournisseur malveillant, il faut une validation des utilisateurs concernés, indépendamment de l’arbre de Merkle complet ou de la divulgation des preuves d’inclusion. À la fois l’assurance que le nombre total de dettes et la valeur totale des dettes n’ont pas été réduits par le fournisseur dépend du niveau de participation des utilisateurs. Avec ce système d’auto-vérification basé sur les preuves d’inclusion, plus il y a d’utilisateurs qui vérifient leurs dettes, mieux c’est. Cela s’explique par le fait que plus de personnes examinent les informations, plus il est probable que si quelque chose ne va pas, cela sera remarqué, et plus il y aura un consensus des utilisateurs. Cela revient au concept de base selon lequel “plus il y a de personnes qui vérifient quelque chose, plus il est improbable que le Fournisseur puisse y interférer sans être remarqué”. Dans la section 5 de l’article académique précédemment mentionné de Ji-Chalkias, les auteurs présentent des calculs détaillés sur le nombre d’utilisateurs effectuant des vérifications de preuves d’inclusion nécessaires pour détecter tout comportement incorrect de la part du Fournisseur. Notre solution présente d’autres limitations qui ne menacent pas la sécurité et sont constamment examinées en vue d’améliorations. Ces limitations concernent certaines informations sur les dettes individuelles – sans aucun lien avec les identifiants des utilisateurs – et la confidentialité du nombre d’utilisateurs par devise et des dettes totales. À notre avis, la première limitation – la confidentialité des informations sur les dettes individuelles – a été résolue avec notre solution grâce à la “fragmentation des soldes”, qui indique toujours des informations partielles, comme indiquer si un solde est supérieur à un certain montant, mais pas de données personnelles sensibles. Pour clarifier, la fragmentation des soldes signifie simplement que le solde initial de l’utilisateur est fragmenté en sous-soldes de telle sorte que la somme des sous-soldes soit égale au solde initial. Cela fait que le solde initial n’apparaît pas dans l’arbre de Merkle. Les deuxième et troisième limitations concernent davantage des informations que le fournisseur pourrait vouloir garder confidentielles et ne présentent aucun risque réel pour la confidentialité de nos utilisateurs. La bonne nouvelle est qu’il existe des solutions modernes basées sur des constructions cryptographiques plus avancées, telles que zk-SNARKS, qui résolvent ces problèmes et nous donnent des options pour l’avenir afin de réduire encore davantage les limitations. Actuellement, en raison de leur nouveauté, ces solutions sont moins accessibles et nécessitent davantage de développement de notre part. Pour ces raisons, nous avons décidé de mettre en œuvre en premier lieu la solution éprouvée de l’arbre de Merkle, car les problèmes restants ne sont pas du tout critiques. Nous suivons de près toutes ces solutions, y compris la proposition très discutée de Vitalik et la solution très prometteuse de Dapol+ de Ji-Chalkias, qui a d’abord attiré l’attention de la communauté cryptographique lors de la conférence sur la sécurité informatique et des communications ACM CCS 2021. Nous continuerons d’innover notre solution en intégrant les améliorations au fur et à mesure ; toujours en innovant vers l’avant.

Pourquoi pas d’auditeurs tiers ?

Bien que la vérification de soi des utilisateurs soit une exigence stricte de notre système, cela ne exclut pas la possibilité de faire appel à un auditeur externe à l’avenir. L’un des avantages potentiels de son implication est d’accroître les capacités de détection et de ne pas se fier uniquement à la participation des utilisateurs pour détecter un fournisseur frauduleux. Quelques exemples concrets de cette influence positive sont les suivants. Un auditeur externe pourrait vérifier de manière systématique des échantillons de passifs des utilisateurs par rapport à la Preuve des Passifs. L’implication d’un auditeur dans le cadre d’un règlement de litige où un utilisateur revendique des passifs incorrects ou manquants dans le rapport de Preuve des Passifs. Il semble que ce type de problème serait difficile à résoudre uniquement par des moyens techniques et que l’intervention d’un auditeur externe pourrait grandement aider. Pour étayer ce point, dans l’analyse de sécurité de Chalkias sur la Preuve des Passifs de Binance, il souligne le fait que l’implication d’un auditeur pourrait empêcher le fournisseur de suivre les utilisateurs qui effectuent la vérification et d’omettre les passifs pour ceux qui ne vérifient jamais. Autant de choses à prendre en compte pour les futures versions.

Comment vérifier

En tant qu’utilisateur, vous pouvez vérifier et valider vos engagements en visitant la page “Sécurité avec SwissBorg” sur notre site web. Suivez les instructions sur la page et entrez votre identifiant d’audit personnalisé que vous trouverez dans la section Sécurité de l’application SwissBorg. Il est important de savoir que les engagements que vous verrez sont pris au moment du dernier audit et ne sont donc pas une représentation en temps réel de vos engagements. Ces audits sont programmés pour se dérouler régulièrement, la fréquence sera annoncée lorsqu’elle sera définitivement déterminée. Si vous êtes familier avec le terme “référentiel GitHub” et que vous souhaitez vérifier et valider vos engagements localement sur votre ordinateur, suivez les instructions du code source publié sur le référentiel SwissBorg Proof of Liabilities.

Réflexions finales

Nous sommes fiers d’avoir créé indépendamment la première version du SwissBorg Proof of Liabilities Portal, qui permet à chaque utilisateur de vérifier facilement ses engagements correspondants. Cette solution offre un haut niveau de sécurité et de confidentialité, sans avoir recours à des auditeurs tiers. Nous surveillons les évolutions potentielles dans ce domaine et envisageons d’implémenter des techniques cryptographiques avancées pour renforcer la solidité du système. Il est important de noter que la standardisation du Proof of Liabilities peut prendre du temps, mais nous considérons cela comme une évolution positive pour tous. En attendant, nous comptons sur nos utilisateurs pour vérifier leurs engagements via le Proof of Liabilities Portal, renforçant ainsi la confiance envers SwissBorg et notre communauté exceptionnelle. Vérifiez votre solde instantanément sur votre compte SwissBorg et assurez-vous que vos actifs crypto sont en sécurité. Veuillez noter que les informations sur les engagements des utilisateurs fournies par notre protocole de preuve de passif sont enregistrées à partir de notre système interne. SwissBorg ne peut être tenu responsable de tout solde erroné résultant d’une erreur ou d’une omission dans le registre. Cet article est destiné à des fins d’information générale et ne constitue en aucun cas une offre au public de biens virtuels ou d’instruments financiers, ni un conseil financier, d’investissement ou autre. Ni SwissBorg Solutions OÜ ni ses filiales ne garantissent l’exhaustivité, l’exactitude, l’actualité ou l’adéquation des informations contenues dans cet article, ni leur absence d’erreur.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %