Trustodial: un dilemme ontologique

Beaucoup de critiques ont circulé après l’annonce récente selon laquelle le portefeuille de Satoshi reviendra sous peu aux États-Unis grâce à l’intégration du récent système «Spark» de LightSpark, se concentrant spécifiquement sur la question des modèles de confiance et si la nouvelle version de Wallet of Satoshi constitue un portefeuille non custodial ou non.

Spark est un système basé sur StateChains (article explicateur là-bas). Statechains n’a pas le modèle de confiance le plus clair. Spark est essentiellement la version Channel Factory de StateChains, avec de nombreuses Statechains imbriquées à l’intérieur d’un arbre de transaction construit sur un seul UTXO sur chaîne.

Statechains est un système de couche 2 qui permette à des UTXO entiers d’être transférés librement hors de la chaîne sans contraintes de liquidité, mais avec l’exigence d’accepter certains compromis de confiance. Vous devez croire qu’un opérateur, le fournisseur de services essentiellement, supprimera le matériel de clé privé à chaque fois que la Statechain est transférée.

Voyons donc ce qui rend quelque chose de non-Coustodial.

  • Un utilisateur a un contrôle unilatéral sur ses fonds ou la capacité de le retrouver.
  • Aucune autre partie (ni parti) n’a la capacité d’empêcher l’utilisateur de dépenser ses fonds, ou de retrouver sa capacité ou de les dépenser sans l’implication de l’utilisateur.

La première qualité s’applique définitivement à Statechains. Tout comme un canal Lightning, un utilisateur a la possibilité d’utiliser une transaction pré-signée pour récupérer ses fonds après une période TimeLock pour assurer un règlement honnête. La deuxième qualité n’est pas si claire en termes d’application ou de non-application.

Le protocole Statechain exige que l’opérateur et l’utilisateur d’origine générent en collaboration une clé dont aucune des parties n’a jamais une connaissance complète. En utilisant leurs parts, ils peuvent collaborer pour pré-signaler la transaction de retrait des utilisateurs. Lorsque l’utilisateur d’origine le transfère à quelqu’un d’autre, l’utilisateur d’origine, le nouvel utilisateur et l’opérateur collaborent tous pour «régénérer» la même clé mais avec un ensemble différent de partages entre le nouvel utilisateur et l’opérateur.

Après avoir signé la transaction de retrait du nouvel utilisateur, l’opérateur est ensuite censé supprimer le partage qu’ils ont généré avec les utilisateurs d’origine. Cela empêche l’opérateur de signer une nouvelle transaction avec l’utilisateur d’origine, et le Timelock plus court sur la transaction du nouvel utilisateur garantit qu’il peut dépenser le leur avant que l’utilisateur d’origine puisse dépenser le sien.

Si l’opérateur ne supprime pas les anciennes partages clés, il serait possible pour eux de collaborer avec tout utilisateur passé qui a gardé sa part de clé pour voler les fonds dans la Statechain.

L’opérateur

Si l’opérateur fait ce qu’il est censé faire et supprime ses anciennes partages clés à chaque fois que la Statechain est transférée, ce n’est pas un système de garde. Ils sont physiquement incapables de signer des transactions en collaboration avec quiconque, sauf le propriétaire actuel et légitime de la Statechain. Les transactions pré-signées décrémentantes garantissent que le propriétaire actuel peut toujours Confirmez leur transaction de retrait devant tout propriétaire précédent.

Les opérateurs peuvent même exécuter leur logiciel dans une enclave SGX ou un autre environnement informatique sécurisé, et demander à l’enclave forcer le comportement correct du logiciel. Il peut même fournir des preuves (vous a fait confiance à l’environnement pour ne pas être brisé) que d’autres peuvent vérifier.

Ils ont également une forte incitation à gérer honnêtement le protocole, car ce faisant, ils ne sont pas tenus de se conformer aux réglementations qui se présentent à un service de garde détenant l’argent des autres.

Les utilisateurs

Les utilisateurs finaux ont une transaction de retrait unilatérale. Cela peut être utilisé à tout moment après l’expiration du timelock pour leur propriété et avant l’expiration du timelock pour la fenêtre temporelle des propriétaires précédents. Si l’opérateur cesse de répondre ou de disparaître, il a cette option.

Mais ils doivent croire que l’opérateur exploite honnêtement le protocole et supprime les actions clés passées. Il n’y a aucun moyen pour eux de vraiment Vérifiez cela. Comme mentionné ci-dessus, quelque chose comme l’enclave SGX pourrait gérer la sécurité du logiciel de l’opérateur et les preuves des signes qu’il exécute un logiciel honnête. Mais tout ce qui fait, c’est éloigner le point de confiance de l’opérateur et sur Intel, les fabricants de l’enclave SGX.

Même lorsqu’il s’agit d’un opérateur vraiment honnête, qui n’a jamais exécuté un logiciel honnête et n’a jamais triché un seul utilisateur, un utilisateur ne peut jamais réellement savoir qu’ils sont un opérateur honnête. Ils ne peuvent voir que l’opérateur a été Honnête, et j’espère qu’ils continueront d’être.

Donc….?

Il n’y a pas de réponse claire réelle. Dans la situation où un opérateur est en fait Étant honnête, cela correspond à tous les critères que j’ai énoncés ci-dessus pour être non gardiens. L’utilisateur a une capacité sans entrave à accéder plein à ses fonds, et personne d’autre n’est en mesure de l’empêcher de le faire ou de voler ses fonds.

Le problème est que ce n’est pas vérifiable.

Il n’y a aucun moyen de vérifier sans confiance en tant qu’utilisateur que vous avez un contrôle sans confiance sur vos fonds. Même si vous le faites.

Il y a donc un problème avec l’étiquetage de non-Custodial, car même si c’est le cas, il n’est pas possible pour un utilisateur de le vérifier vraiment. Mais il y a aussi un problème à l’appeler gardien, car l’opérateur ne peut rien faire pour déplacer des fonds sans collaborer avec un autre utilisateur et l’utilisateur actuel a une transaction de retrait unilatérale. Cela crée un dilemme en termes de catégorisation des outils dans l’espace.

Je ne sais pas quelle est la solution, mais la première étape, je pense, est de reconnaître les réalités techniques qui se produisent avant de sauter pour étiqueter les choses d’une manière ou d’une autre (pourquoi pas une nouvelle catégorie?) En raison de vos propres incitations. Ces types de questions, en particulier dans un environnement de changements de protocole de Bitcoin lent glaciaire, deviendront plus fréquents à mesure que les développeurs ont du mal avec les émanés des limites actuelles du Bitcoin.

Bitcoin est un argent programmable, et la façon dont les gens le programmeront ne s’adapteront pas toujours bien à nos boîtes prédéfinies.

Laisser un commentaire