Les « modèles de confiance » méritent-ils leur titre ?

L'une des propriétés les plus précieuses de nombreuses applications blockchain est l'absence de confiance : la capacité de l'application à continuer à fonctionner de la manière attendue sans avoir besoin de compter sur un acteur spécifique pour se comporter d'une manière spécifique.

Même lorsque leurs intérêts peuvent changer et les pousser à agir d'une manière différente et inattendue à l'avenir.

Les applications Blockchain ne sont jamais totalement sans confiance, mais certaines applications sont beaucoup plus proches de l'être que d'autres. Si nous voulons faire des progrès pratiques vers la minimisation de la confiance, nous voulons avoir la possibilité de comparer différents degrés de confiance.

Tout d'abord, ma définition simple de la confiance en une phrase : la confiance est l'utilisation de toute hypothèse sur le comportement des autres . Si avant la pandémie, vous marchiez dans la rue sans vous assurer de garder deux mètres de distance avec des inconnus pour qu'ils ne puissent pas soudainement sortir un couteau et vous poignarder, c'est une sorte de confiance : à la fois confiance que les gens sont très rarement complètement dérangés , et j'espère que les personnes qui gèrent le système judiciaire continueront de fournir de fortes incitations contre ce type de comportement.

Lorsque vous exécutez un morceau de code écrit par quelqu'un d'autre, vous avez confiance qu'il a écrit le code honnêtement (que ce soit en raison de son propre sens de la décence ou en raison d'un intérêt économique à maintenir sa réputation), ou du moins qu'il existe suffisamment de personnes vérifiant le code qu'un bogue serait trouvé.

Ne pas cultiver sa propre nourriture est un autre type de confiance : croire qu'un nombre suffisant de personnes se rendront compte qu'il est dans leur intérêt de cultiver de la nourriture pour pouvoir vous la vendre. Vous pouvez faire confiance à différentes tailles de groupes de personnes, et il existe différents types de confiance.

Pour les besoins de l'analyse des protocoles blockchain, j'ai tendance à décomposer la confiance en quatre dimensions :

• De combien de personnes avez-vous besoin pour vous comporter comme prévu ?

  
  

• Sur combien ?

  
  

• Quels types de motivations sont nécessaires pour que ces personnes se comportent? Doivent-ils être altruistes ou simplement rechercher le profit ? Doivent-ils être non coordonnés ?

  
  

• Dans quelle mesure le système échouera-t-il si les hypothèses sont violées ?

Pour l'instant, concentrons-nous sur les deux premiers. On peut tracer un graphique :

Plus c'est vert, mieux c'est. Explorons les catégories plus en détail :

• 1 sur 1 : il y a exactement un acteur, et le système fonctionne si (et seulement si) cet acteur fait ce que vous attendez de lui. C'est le modèle « centralisé » traditionnel, et c'est ce que nous essayons de mieux faire.

  
  

• N de N : le monde "dystopique". Vous comptez sur tout un tas d'acteurs, qui doivent tous agir comme prévu pour que tout fonctionne, sans sauvegarde si l'un d'entre eux échoue.

  
  

• N/2 sur N : c'est ainsi que fonctionnent les blockchains - elles fonctionnent si la majorité des mineurs (ou validateurs PoS) sont honnêtes. Notez que N/2 de N devient significativement plus précieux à mesure que N augmente ; une blockchain avec quelques mineurs/validateurs dominant le réseau est beaucoup moins intéressante qu'une blockchain avec ses mineurs/validateurs largement distribués. Cela dit, nous voulons améliorer même ce niveau de sécurité, d'où l' inquiétude de survivre à 51 % des attaques .

  
  

• 1 sur N : il y a beaucoup d'acteurs, et le système fonctionne tant qu'au moins l'un d'entre eux fait ce que vous attendez d'eux. Tout système basé sur des preuves de fraude entre dans cette catégorie, tout comme les configurations de confiance, bien que dans ce cas, le N soit souvent plus petit. Notez que vous voulez que le N soit aussi grand que possible !

  
  

• Peu de N : il y a beaucoup d'acteurs, et le système fonctionne tant qu'au moins un petit nombre fixe d'entre eux font ce que vous attendez d'eux. Les vérifications de la disponibilité des données entrent dans cette catégorie.

  
  

• 0 sur N : le système fonctionne comme prévu sans aucune dépendance vis-à-vis d'acteurs externes. La validation d'un bloc en le vérifiant vous-même entre dans cette catégorie.

Bien que tous les buckets autres que "0 sur N" puissent être considérés comme "de confiance", ils sont très différents les uns des autres !

Croire qu'une personne (ou une organisation) en particulier fonctionnera comme prévu est très différent de croire qu'une seule personne, n'importe où , fera ce que vous attendez d'elle.

"1 de N" est sans doute beaucoup plus proche de "0 de N" que de "N/2 de N" ou "1 de 1". Un modèle 1 sur N peut ressembler à un modèle 1 sur 1 parce que vous avez l'impression de passer par un seul acteur, mais la réalité des deux est très différente : dans un système 1 sur N, si l'acteur avec lequel vous travaillez en ce moment disparaît ou devient méchant, vous pouvez simplement passer à un autre, alors que dans un système 1 sur 1, vous êtes foutu.

En particulier, notez que même l'exactitude du logiciel que vous exécutez dépend généralement d'un modèle de confiance "quelques N" pour garantir que s'il y a des bogues dans le code, quelqu'un les détectera.

Avec ce fait à l'esprit, essayer vraiment de passer de 1 de N à 0 de N sur un autre aspect d'une application revient souvent à fabriquer une porte en acier renforcé pour votre maison lorsque les fenêtres sont ouvertes.

Une autre distinction importante est : comment le système échoue-t-il si votre hypothèse de confiance est violée ? Dans les blockchains, les deux types de défaillance les plus courants sont les défaillances de vivacité et les défaillances de sécurité .

Un échec de vivacité est un événement dans lequel vous êtes temporairement incapable de faire quelque chose que vous voulez faire (par exemple, retirer des pièces, obtenir une transaction incluse dans un bloc, lire des informations de la blockchain).

Une défaillance de sécurité est un événement dans lequel quelque chose se produit activement que le système était censé empêcher (par exemple, un bloc invalide est inclus dans une blockchain).

Voici quelques exemples de modèles de confiance de quelques protocoles de couche 2 de blockchain. J'utilise " petit N " pour désigner l'ensemble des participants du système de couche 2 lui-même, et " grand N " pour désigner les participants de la blockchain ; l'hypothèse est toujours que le protocole de couche 2 a une communauté plus petite que la blockchain elle-même.

Je limite également mon utilisation du mot "échec de vivacité" aux cas où les pièces sont bloquées pendant une durée significative ; ne plus pouvoir utiliser le système mais être capable de se retirer presque instantanément ne compte pas comme une panne de vivacité.

• Canaux (y compris les canaux d'État, le réseau Lightning): 1 confiance sur 1 pour la vivacité (votre contrepartie peut temporairement geler vos fonds, bien que les dommages puissent être atténués si vous répartissez les pièces entre plusieurs contreparties), N / 2 de confiance big-N pour la sécurité (une attaque blockchain 51% peut voler vos pièces)

  
  

• Plasma (en supposant un opérateur centralisé): 1 confiance sur 1 pour la vivacité (l'opérateur peut temporairement geler vos fonds), N / 2 de la confiance big-N pour la sécurité (attaque blockchain 51%).

  
  

• Plasma (en supposant un opérateur semi-décentralisé, par exemple DPOS) : N/2 de confiance petit-N pour la vivacité, N/2 de confiance grand-N pour la sécurité.

  
  

• Cumul optimiste : 1 sur 1 ou N/2 de confiance petit-N pour la vivacité (selon le type d'opérateur), N/2 de confiance grand-N pour la sécurité.

  
  

• ZK rollup : 1 of small-N trust for liveness (si l'opérateur n'inclut pas votre transaction, vous pouvez retirer, et si l'opérateur n'inclut pas votre retrait immédiatement, il ne peut pas produire plus de lots et vous pouvez vous retirer vous-même avec l'aide de n'importe quel nœud complet du système de cumul); aucun risque de défaillance de la sécurité

  
  

• ZK rollup (avec amélioration du retrait de lumière ) : pas de risque de défaillance de la vivacité, pas de risque de défaillance de la sécurité

Enfin, il y a la question des incitations : l'acteur en qui vous avez confiance doit-il être très altruiste pour agir comme prévu, peu altruiste ou est-il suffisamment rationnel ? La recherche de preuves de fraude est "par défaut" légèrement altruiste, bien que son degré d'altruisme dépende de la complexité du calcul (voir le dilemme du vérificateur ), et il existe des moyens de modifier le jeu pour le rendre rationnel.

Aider les autres à se retirer d'un cumul ZK est rationnel si nous ajoutons un moyen de micro-paiement pour le service, il y a donc vraiment peu de raisons de s'inquiéter que vous ne puissiez pas sortir d'un cumul avec une utilisation significative.

Pendant ce temps, les risques plus importants des autres systèmes peuvent être atténués si nous convenons en tant que communauté de ne pas accepter les chaînes d'attaque à 51% qui reviennent trop loin dans l'histoire ou bloquent la censure trop longtemps.

Conclusion : quand quelqu'un dit qu'un système « dépend de la confiance », demandez-lui plus en détail ce qu'il veut dire ! Signifient-ils 1 sur 1, ou 1 sur N, ou N/2 sur N ? Exigent-ils de ces participants qu'ils soient altruistes ou simplement rationnels ? Si altruiste, est-ce une petite dépense ou une énorme dépense ?

Et si l'hypothèse est violée - avez-vous juste besoin d'attendre quelques heures ou quelques jours, ou avez-vous des actifs qui sont bloqués pour toujours ? Selon les réponses, votre propre réponse à savoir si vous voulez ou non utiliser ce système peut être très différente.

Publié à l'origine sous le nom de " Modèles de confiance "