Comprendre le concept de Proof of Liabilities : Comment SwissBorg assure la transparence et la sécurité financière
Read Time:17 Minute, 9 Second
Pour qui est destiné ce rapport ?
Ce contenu s’adresse à tout le monde et ne nécessite qu’une connaissance de base en cryptographie et une familiarité avec l’informatique. Il explique de manière technique les processus de calcul, il est donc conseillé d’avoir des connaissances en théorie de l’information et en cryptographie pour bien comprendre le sujet.
Présentation
Les événements récents dans le domaine de la crypto-monnaie ont souligné l’importance de la transparence et de la sécurité des soldes des utilisateurs. SwissBorg a donc lancé le portail Proof of Liabilities (preuve de passif) pour permettre à nos utilisateurs de vérifier que leurs soldes ont bien été pris en compte. Grâce à cette solution de reporting en ligne, les utilisateurs peuvent s’assurer que leurs passifs sont inclus dans le total, sans avoir à compter sur un auditeur tiers. Nous avons utilisé une technique cryptographique solide appelée “arbre de Merkle” pour garantir la fiabilité du processus de vérification. Cette solution web offre une transparence totale et permet à quiconque de consulter et d’inspecter le code et les données. Nous croyons que notre approche de l’auto-vérification combinée à la facilité d’utilisation offre la meilleure solution possible. Si vous souhaitez savoir comment valider votre passif, consultez la section “Comment valider” dans l’article. Nous avons également prévu des perspectives d’avenir pour améliorer encore la preuve de passif.
Introduction aux concepts fondamentaux
Un document ou un tableau de preuve de passif (PoL) utilise un protocole qui permet à SwissBorg, en tant que prouveur, de montrer les passifs des utilisateurs à travers une preuve. Les utilisateurs, en tant que vérificateurs, reçoivent cette preuve et s’assurent qu’elle est correcte. Les passifs font référence aux soldes détenus par les utilisateurs dans leurs portefeuilles gérés par SwissBorg. Ces soldes sont simplement représentés par des nombres positifs. L’objectif principal du service PoL est de permettre aux utilisateurs de vérifier que leurs soldes sont inclus dans le total des passifs de tous les utilisateurs. En résumé, une PoL garantit que SwissBorg n’a pas omis les passifs d’un utilisateur lors de la vérification.
Preuve des dettes
Une méthode simple pour fournir une preuve de passif consiste à montrer publiquement combien chaque utilisateur détient. C’est comme si votre banque montrait un relevé avec tous les avoirs de tous les clients. D’un point de vue plus technique, cela signifie que le prouveur montre une liste de tous les vérificateurs et de leurs passifs. Cette liste doit être claire, accessible au public et idéalement dynamique pour refléter tous les changements.
Prenons un exemple simplifié : un grand livre de comptes avec les avoirs de chaque utilisateur et le total. Le prouveur fournit ces informations pour que tout le monde puisse les voir et les vérifier, et les utilisateurs agissent en tant que vérificateurs pour s’assurer que les informations sont exactes.
Dans cet exemple, il y a quelques points clés à considérer. Chaque utilisateur peut vérifier que son propre passif correspond à ce qui est indiqué, et que la somme de tous les passifs correspond au montant total publié. Si le prouveur omet ou fournit un passif inexact pour un utilisateur, le prouveur est clairement responsable et risque d’être pris.
Cette approche basique fonctionne, mais présente des lacunes en termes de confidentialité. Les informations financières avec les identités des utilisateurs ne sont pas divulguées dans notre processus de preuve de passif.
Un autre problème potentiel est la manipulation des informations divulguées. Le prouveur pourrait afficher différentes listes de passifs à différents utilisateurs dans le but de réduire la valeur réelle du total des passifs. Pour éviter cela, nous introduisons une “empreinte de données publiques” qui peut être vérifiée par chaque utilisateur pour garantir que tous ont reçu le même ensemble de données. Cela s’appelle un Public Bulletin Board (PBB) en informatique.
En ce qui concerne l’immuabilité, il y a deux autres propriétés importantes à mettre en œuvre. Premièrement, chaque solde doit être vérifié pour s’assurer qu’il est positif. Deuxièmement, les identifiants des utilisateurs doivent être uniques pour lier les passifs individuels à chaque utilisateur.
Ces attributs spécifiques de la preuve de passif sont cruciaux dans le processus de vérification pour les utilisateurs.
La Preuve des Engagements de SwissBorg
Conception à un niveau élevé” pourrait être reformulé comme “Conception avancée” ou “Conception de niveau supérieur
Le service Proof of Liabilities de SwissBorg, a été conçu en utilisant des méthodes avancées existantes, adaptées à nos besoins spécifiques. Nous avons étudié différentes options et avons finalement opté pour une approche basée sur un arbre de Merkle, qui est une méthode de cryptographie bien établie et facile à mettre en œuvre dans différents langages de programmation. Cela nous permet de garantir la sécurité et la fiabilité de notre service, tout en simplifiant le processus de mise en œuvre. Nous avons également consulté la littérature existante et les implémentations de travail pour nous assurer d’appliquer les dernières améliorations dans notre conception.
L’importance de Merkle et son arbre
Les fonctions de hachage cryptographiques sont essentielles dans de nombreux protocoles cryptographiques. En termes simples, une fonction de hachage prend une entrée de n’importe quelle taille et produit une sortie de taille fixe. Cela signifie que peu importe la taille de l’entrée, la sortie sera toujours de la même taille. De plus, il est impossible de retrouver l’entrée à partir de la sortie. Cela fait de la sortie une empreinte unique de l’entrée. L’utilisation de fonctions de hachage permet de créer une structure où les données ne peuvent être modifiées sans altérer tous les hachages suivants. Cela garantit que les données sont protégées contre toute modification ultérieure.
L’arbre de Merkle est une structure de données qui a été introduite avec l’invention de la cryptographie à clé publique dans les années 1970. Il tient son nom de son inventeur, Ralph Merkle. Un arbre de Merkle est essentiellement un 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. Cette structure permet de vérifier rapidement l’intégrité des données, car il suffit de comparer les hachages pour déterminer si un bloc de données a été modifié ou non.
Reformulation du sous-titre de section d’article de blog : “Hparent est un hash qui est créé en combinant les valeurs de hachage HA et HB (si HA et HB sont des valeurs de hachage enfants respectives)
Au sommet de l’arbre de Merkle se trouve un hachage qui agrège toutes les données sous-jacentes. Ce hachage de la racine est essentiel car il garantit l’intégrité des données. Si une modification est apportée à l’une des données, la valeur du hachage de la racine sera également modifiée. L’arbre de Merkle permet d’agréger efficacement un grand nombre de données, appelées blocs, et de vérifier l’inclusion d’un bloc spécifique. Cette méthode de vérification permet de prouver que le bloc de données donné a été inclus dans l’arbre et qu’il se trouve sur le chemin des nœuds frères successifs jusqu’à la racine de l’arbre. La taille de la preuve d’inclusion est logarithmique, ce qui la rend très efficace. De plus, une fois que la valeur de hachage de la racine est affichée, les données sous-jacentes ne peuvent plus être modifiées. Il est donc impossible de prétendre avoir inclus des données qui ne l’étaient pas lors de la construction de l’arbre de Merkle.
La branche Maxwell-Todd de la Preuve de Responsabilité (PoL)
Comme je l’ai mentionné précédemment, la première proposition de Proof of Liabilities (PoL) basée sur un arbre de Merkle a été faite par Maxwell-Todd en 2013. Leur proposition consistait à utiliser un arbre de Merkle avec des blocs de données comprenant le solde des utilisateurs. Chaque nœud de cet arbre de Merkle était également étendu avec un passif, qui était la somme des passifs des nœuds enfants. Ainsi, chaque nœud était composé d’un digest (valeur de hachage) et d’un solde positif. En conséquence, le solde du nœud racine représentait la somme des passifs de tous les utilisateurs. Cette structure de données était appelée “arbre de Merkle avec sommation”.
Maintenant, les choses deviennent intéressantes. La valeur hachée d’un nœud feuille était obtenue en hachant l’identifiant de l’utilisateur, son mot de passe d’audit et son solde. Le mot de passe de l’utilisateur était utilisé pour masquer son identifiant, afin de protéger sa vie privée. Pour renforcer la sécurité de cette méthode, la position du nœud feuille d’un utilisateur donné était choisie de manière aléatoire, rompant ainsi le lien entre l’utilisateur et son solde. La valeur hachée de tout autre nœud était calculée en hachant les passifs des nœuds enfants et leurs valeurs digest respectives.
La reformulation du sous-titre de section d’article de blog pourrait être : “Formule de hachage pour le calcul de Hparent en utilisant les valeurs de BalA, BalB, HA et HB
Pour prouver à un utilisateur que sa dette est incluse dans l’arbre de Merkle, le prouveur fournit un chemin d’inclusion. Cela se fait de la même manière qu’avec un arbre de Merkle classique, mais en utilisant la somme des dettes. Lors de la validation, l’utilisateur calcule le hash parent, puis vérifie la somme des soldes des enfants. En plus de cette vérification, l’utilisateur s’assure que BalA et BalB sont positifs et que BalA + BalB = Bal, où BalA et BalB sont les soldes des enfants et Bal est la dette du parent. Cette étape de validation est effectuée à chaque niveau de l’arbre de Merkle, des feuilles à la racine.
Il est important de noter que l’arbre de Merkle par sommation décrit ci-dessus est une version modifiée de l’arbre de Merkle Maxwell-Todd original, basée sur les idées présentées dans un article universitaire de Hu, Zhang et Guo (2019) qui a corrigé une faille de sécurité. Cette nouvelle variante a été appelée “variante de Maxwell+” dans un autre article universitaire de Ji-Chalkias (2021).
En suivant cette logique, l’article de Ji-Chalkias (2021) mentionne également une méthode pour cacher les soldes originaux des utilisateurs en les divisant en fragments et en les mélangeant au hasard dans les feuilles de l’arbre. Cette idée a été attribuée à Chalkias, Lewi, Mohassel et Nikolaenko en 2019. Cette nouvelle variante a été nommée la “variante de Maxwell++” par Ji-Chalkias (2021).
En résumé, la progression de cette méthode cryptographique pour une utilisation pratique dans les Preuves de Responsabilité est apparue avec l’itération de Maxwell-Todd, où la sommation a pu être incluse dans l’arbre de Merkle. Ensuite, une faille de sécurité a été découverte et corrigée, donnant lieu à la variante Maxwell+. Enfin, la version finale, Maxwell++, a été développée pour diviser les soldes de chaque utilisateur en fragments afin de masquer leur dette réelle. Chacune de ces améliorations a été bien accueillie par la communauté et nous sommes ravis d’utiliser cette technologie dans notre solution également.
Les décisions prises par SwissBorg pour la conception
La plateforme SwissBorg prend en charge de nombreuses devises fiat et cryptoactifs, ce qui signifie que les utilisateurs ont souvent plusieurs devises dans leur portefeuille. Pour garantir la confidentialité des utilisateurs, nous utilisons une approche qui traite chaque devise séparément. Nous créons un arbre de Merkle dédié pour chaque devise, puis agrégeons les racines de tous ces arbres dans un “Audit Commitment Hash”, qui représente les totaux des passifs par devise. Ce processus peut être considéré comme la construction d’un seul arbre de Merkle, avec une couche supérieure constituée de branches correspondant aux différentes devises. Pour vérifier les passifs, toutes les racines des arbres de Merkle doivent être incluses dans la preuve. De plus, pour renforcer la confidentialité des soldes des utilisateurs, nous divisons chaque solde en sous-soldes positifs, dont les positions dans l’arbre de Merkle sont déterminées de manière aléatoire. Cela permet de masquer partiellement le nombre d’utilisateurs par devise. Nous utilisons également des nonces de masquage à haute entropie pour assurer la confidentialité des utilisateurs. Ces nonces, dérivés d’un identifiant d’audit par utilisateur, empêchent de découvrir l’identité de l’utilisateur correspondant à un nœud feuille spécifique.
Comment puis-je retrouver mon mot de passe d’audit ?
Votre mot de passe est stocké dans l’onglet Sécurité de l’application SwissBorg. Il est essentiel de le garder confidentiel pour éviter toute utilisation malveillante qui pourrait révéler vos soldes. Ce mot de passe est destiné à être conservé à long terme et réutilisé lors de plusieurs audits du Proof of Liabilities (PoL). Les nonces des feuilles sont dérivées de manière hiérarchique à partir de l’identifiant d’audit et du mot de passe d’audit de l’utilisateur. Ces nonces sont ensuite utilisées pour révéler des informations sur le passif de l’utilisateur à différents niveaux de spécificité.
L’identifiant d’utilisateur SwissBorg est utilisé à tous les stades du processus et peut être facilement trouvé dans l’application. Il est unique pour chaque utilisateur et ne change jamais. Le service PoL de SwissBorg propose plusieurs chemins d’inclusion de l’arbre de Merkle, un pour chaque shard de sous-solde de l’utilisateur. Ces chemins sont validés à l’aide d’un script exécuté dans le navigateur et affichent les soldes totaux de l’utilisateur.
La validation est effectuée en comparant les Audit Commitment Hashes avec ceux publiés sur Twitter. Les nœuds racines de l’arbre de Merkle sont vérifiés par rapport à ces hash. Pour chaque chemin d’inclusion, le chemin est validé en calculant récursivement le nœud parent à l’aide du nœud frère fourni par la preuve d’inclusion. Il est ensuite vérifié que le nœud supérieur correspond à l’un des nœuds racines de l’arbre de Merkle validés précédemment. Une vérification est également effectuée pour s’assurer que les frères ont un passif positif.
À chaque validation réussie, le solde feuille de l’utilisateur est ajouté au passif total de l’utilisateur. Si aucune erreur ne se produit, le total du passif de l’utilisateur lui est affiché.
Échange de points de vue
La Proof of Liabilities de SwissBorg est basée sur la technologie de construction d’arbre de Merkle, ce qui permet de garantir la confidentialité des utilisateurs et de leurs passifs. Contrairement à d’autres solutions de Proof of Liabilities, notre approche met l’accent sur la facilité d’utilisation et l’auto-vérification par l’utilisateur, sans avoir besoin d’un auditeur tiers. Notre méthode est similaire à celle de Bitmex, avec une différence majeure : notre vérification est plus légère et adaptée à un environnement multi-devises. L’utilisateur n’a pas besoin de télécharger un arbre de Merkle complet, mais seulement des preuves d’inclusion qui sont une petite partie de l’arbre. Cela permet une validation dans le navigateur, que l’utilisateur peut vérifier s’il le souhaite. Nous sommes convaincus que ne pas publier l’arbre de Merkle complet ne présente aucune vulnérabilité, car l’Audit Commitment Hash garantit l’intégrité des données. 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 sert qu’à vérifier la structure, en s’assurant que tous les passifs sont positifs et que les hachages des nœuds sont corrects.
Restrictions
En termes de limitations, lors de la validation, un utilisateur ne peut pas détecter si les passifs d’un autre utilisateur sont inexacts ou s’ils ont été omis. Pour détecter toute manipulation de la part d’un fournisseur malveillant, une validation par les utilisateurs concernés est nécessaire, indépendamment de la publication complète de l’arbre de Merkle ou de la divulgation des preuves d’inclusion. La confiance dans le fait que le nombre total de passifs ou la valeur totale des passifs n’a pas été réduite par le fournisseur dépend du niveau d’implication des utilisateurs.
Avec ce système d’auto-vérification sans tiers, basé uniquement sur la preuve d’inclusion, plus il y a d’utilisateurs vérifiant leurs passifs, mieux c’est. En effet, plus il y a de personnes qui examinent les informations, plus il y a de chances que si quelque chose ne va pas, cela soit remarqué, ce qui conduit à un consensus plus fort entre les utilisateurs. Cela repose sur le concept fondamental selon lequel “plus il y a de personnes qui vérifient quelque chose, moins il y a de chances que le prouveur puisse le modifier sans être remarqué”.
Dans la section 5 de l’article universitaire de Ji-Chalkias mentionné précédemment, les auteurs présentent des calculs détaillés sur le nombre d’utilisateurs qui doivent effectuer des vérifications de preuves d’inclusion pour détecter toute mauvaise conduite de la part du prouveur.
Notre solution présente également d’autres limitations qui ne compromettent pas la sécurité et font l’objet de recherches constantes d’amélioration. Ces limitations concernent certaines informations sur les passifs individuels – sans aucun lien avec les identifiants des utilisateurs, la confidentialité du nombre d’utilisateurs par devise et le total des passifs.
Selon nous, la première limitation de la confidentialité des informations sur les passifs individuels a été résolue grâce à notre solution de “fractionnement des soldes”, qui affiche toujours des informations partielles, telles qu’une indication de solde supérieur à un certain montant, mais pas de données personnelles sensibles.
Pour clarifier, le fractionnement des soldes signifie simplement que le solde original de l’utilisateur est divisé en sous-soldes de sorte que la somme des sous-soldes soit égale au solde original. Ainsi, le solde d’origine n’apparaît pas dans l’arbre de Merkle.
Les deuxième et troisième limitations concernent davantage les informations que le fournisseur pourrait vouloir garder privées et ne posent pas de réel risque pour la vie privée de nos utilisateurs. La bonne nouvelle est qu’il existe des solutions modernes basées sur des constructions cryptographiques plus avancées, telles que les zk-SNARKS, qui résolvent ces problèmes. Cela nous donne la possibilité, à l’avenir, de mettre en œuvre et de réduire encore ces limitations.
Pour l’instant, 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.
L’absence d’auditeurs externes pour SwissBorg : pourquoi ?
L’introduction d’un auditeur tiers dans notre système pourrait présenter des avantages considérables, tels que renforcer la détection de fournisseurs frauduleux et ne pas se reposer uniquement sur les utilisateurs pour cela. Par exemple, l’auditeur pourrait vérifier régulièrement un échantillon des passifs des utilisateurs par rapport à la Proof of Liabilities (PoL). De plus, lorsqu’un litige survient et qu’un utilisateur signale des passifs inexacts ou manquants dans le rapport de PoL, l’auditeur pourrait intervenir pour résoudre le problème. Il est important de noter que certains problèmes ne peuvent pas être résolus uniquement par des moyens techniques et que l’intervention d’un auditeur tiers serait très utile. Dans une analyse de sécurité de la PoL de Binance, Chalkias souligne également 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 de ceux qui ne vérifient jamais. Toutes ces considérations devraient être prises en compte pour les futurs développements.
Valider en matière de blockchain et de finance
En tant qu’utilisateur, vous pouvez vérifier et valider vos passifs en visitant la page “En sécurité avec SwissBorg” sur notre site web. Il vous suffit de suivre les instructions de la page et de saisir votre mot de passe d’audit personnalisé, que vous trouverez dans la section Sécurité de l’application SwissBorg. Il est important de noter que les passifs que vous verrez sont ceux qui ont été audités lors du dernier contrôle et ne représentent pas en temps réel vos passifs. Les audits sont effectués régulièrement, et la fréquence sera annoncée une fois qu’elle sera définitivement déterminée. Si vous êtes familier avec le terme “GitHub repo” et que vous souhaitez vérifier et valider vos passifs localement sur votre ordinateur, vous pouvez suivre les instructions du code source publié sur le SwissBorg Proof of Liabilities Repo.
Conclusions et dernières réflexions
Nous sommes fiers de vous annoncer que SwissBorg a développé son propre portail Proof of Liabilities, qui permet à nos utilisateurs de vérifier facilement leurs avoirs sans avoir besoin de tiers de confiance. Cela garantit un niveau élevé de sécurité et de confidentialité. Bien que cette initiative soit en constante évolution, nous envisageons d’intégrer des techniques cryptographiques avancées à l’avenir pour renforcer notre système. La standardisation des Proof of Liabilities dans l’industrie prendra du temps, mais nous considérons cela comme une évolution positive inévitable. En attendant, nous comptons sur nos utilisateurs pour valider leurs passifs via le portail Proof of Liabilities, ce qui renforce la confiance en notre communauté et en SwissBorg. Veuillez noter que les informations sur les passifs des utilisateurs proviennent de notre propre système et que nous ne pouvons être tenus responsables d’éventuelles erreurs. Les informations contenues dans cet article sont fournies à titre informatif seulement et ne doivent pas être interprétées comme des conseils financiers ou d’investissement. Nous ne faisons aucune déclaration ni garantie quant à l’exhaustivité, l’exactitude ou l’adéquation de ces informations.
Happy
0 %
Sad
0 %
Excited
0 %
Sleepy
0 %
Angry
0 %
Surprise
0 %
0
0