Jusqu'à présent, le mythe du bien-être dans le secteur monétaire/blockchain perdure, et le prochain domaine important de la « création de richesse » se concentre sur la « piste de jeu ». Le projet XAI organise un événement Odyssey. Si vous êtes intéressé, veuillez participer à mon article sur la place : XAI Game Public Chain Odyssey Event Zero-Cost Beginner's Guide
Dans cet article, je vais vous apporter une explication détaillée du nœud Sentry de la chaîne publique du jeu XAI ! Cet article est relativement technique, donc si vous souhaitez gagner de l’argent, vous devez le lire attentivement. Parce que ce n'est que si vous comprenez vous-même la « logique » et améliorez votre cognition que vous pourrez avoir la possibilité de gagner de l'argent !
Si vous voulez voir directement le nœud Sentry, lisez la première partie directement sans lire plus tard ; si vous voulez une boucle fermée logique, alors vous devez lire les deuxième, troisième et quatrième parties !
Ce que je tiens à souligner, c'est que Xai reçoit le support technique direct d'Offchain Labs. Ce type de support est inimaginable pour les autres chaînes Orbit ! et constitue un élément clé du plan de jeu stratégique de Xai au sein de l’écosystème Arbitrum.
![](https://public.bnbstatic.com/image/pgc/202310/da60948e42fbaf94286d949ab49f5551.png)
Partie 1 : Explication du nœud sentinelle
Le nœud Sentry est un nœud d'observation qui surveille le protocole de cumul Xai et si un mauvais bloc est proposé, il émettra une alerte (par tout moyen choisi par son opérateur) afin que d'autres puissent intervenir. L’objectif du nœud sentinelle est de résoudre le dilemme du vérificateur (voir la partie IV pour plus de détails sur le dilemme du vérificateur).
Cliquez ici pour voir la vidéo promotionnelle :
Promotion vidéo du nœud Sentinelle
Exécutez des nœuds Xai et obtenez des jetons Xai en un seul clic !
Les nœuds Sentinel peuvent s'exécuter sur les ordinateurs portables, les ordinateurs de bureau ou même les instances cloud des membres de la communauté. Tant que le nœud est en cours d'exécution, il existe un algorithme probabiliste qui détermine si l'opérateur du nœud sera récompensé par des jetons esXai du réseau. En jalonnant Xai, vous augmentez la probabilité de l'algorithme. Si vous ne connaissez pas esXai, merci de participer à mon article sur le carré : Interprétation de la « Token Economy » du projet XAI
1. Principe de fonctionnement du nœud sentinelle
Le protocole Attention Challenge v2 implique plusieurs participants, dont la chaîne Xai, une chaîne parent (Arbitrum One), un challenger de confiance, des sentinelles Xai et leurs clés de licence, et un contrat d'arbitre (arbitre). Le challenger crée une paire de clés BLS, enregistre la clé publique du contrat d'arbitre et signe les réclamations faites par le validateur dans le protocole de cumul Xai sur Arbitrum One. Ces signatures sont vérifiées par le contrat d'arbitre et enregistrées comme contestations associées à la réclamation.
Xai Sentinels peut s'inscrire au contrat d'arbitre en achetant une clé de licence Sentinel pour pouvoir publier des déclarations sur les réclamations. Ils obtiennent la racine d'état de l'instruction correcte qui sera le successeur de l'instruction émettrice. Si une certaine condition est remplie, ils émettent une déclaration concernant la déclaration en invoquant le contrat d'arbitrage. Si une déclaration de suivi est créée et confirmée et que Sentinel émet la bonne déclaration, Sentinel contactera le contrat d'arbitre pour émettre une transaction de rachat. L'arbitre vérifiera plusieurs conditions avant de payer la récompense à la Sentinelle.
Ce protocole garantit que chaque revendication doit consommer entièrement les messages de la boîte de réception qui existaient lors de la création de la revendication précédente. Cela signifie qu'une fois qu'une revendication est créée, les racines d'état de ses revendications ultérieures correctes sont entièrement déterminées et peuvent être calculées par n'importe quel nœud. Cela encourage chaque sentinelle à déterminer la racine d’état suivante correcte. La récompense de la sentinelle est déterminée par l'ID d'autorisation d'état de la sentinelle, la racine d'état suivante et une valeur de défi qui n'est connue que lorsque la racine d'état suivante est entièrement déterminée.
2. Qui peut exécuter le nœud ?
N'importe qui peut utiliser Sentinel en téléchargeant le logiciel, en l'installant et en l'exécutant. Cependant, pour recevoir des récompenses symboliques, au moins une clé de licence Sentinel doit être achetée.
Les acheteurs doivent réussir un contrôle KYC pour s'assurer qu'ils :
pas aux États-Unis
Non soumis à aucune sanction américaine de l'OFAC (l'OFAC est reflété dans une liste de sanctions américaines)
Les nœuds Sentinel qui ne fonctionnent pas ou qui ne disposent pas des fonds appropriés pour payer les frais de gaz (GAS) n'accumuleront pas de récompenses, même avec une clé de licence. Par conséquent, les opérateurs voudront s’assurer que leurs nœuds sont financés, en ligne et opérationnels.
3. Contrat d'arbitre (arbitre)
Referee est un contrat intelligent conçu pour faire respecter les règles prédéfinies, vérifier l'origine des soumissions et distribuer des récompenses aux gagnants au sein du système. Le contrat intelligent d'arbitre est un élément clé de l'écosystème Xai, responsable de la gestion et de la validation des réclamations formulées par les nœuds sentinelles du réseau. Le contrat a plusieurs fonctions clés :
3.1 Remise de la déclaration
Le contrat d'arbitre permet aux nœuds sentinelles de soumettre des réclamations aux défis. Cette fonction ne peut être appelée que par le propriétaire de la clé de licence Sentinel ou son adresse approuvée sur ce contrat. Cette fonction vérifie si le défi est toujours ouvert à la soumission et si une NodeLicense a déjà été soumise pour ce défi.
3.2 Recevez des récompenses
Le contrat contient une fonctionnalité qui permet aux utilisateurs de réclamer des récompenses pour les réclamations réussies. Cette fonction vérifie si le défi a été fermé pour soumission et vérifie si le propriétaire de la clé du nœud a terminé KYC. Si ces conditions sont remplies et que la réclamation est éligible au paiement, la récompense sera envoyée à l'utilisateur.
3.3 Créez le hachage de la réclamation et vérifiez le paiement.
Le contrat a une fonction qui crée un hachage de l'ID d'autorisation sentinelle, de l'ID de défi, du challengerSignedHash dans le défi et de la racine d'état ultérieure. Il vérifie ensuite si le hachage est inférieur à un certain seuil, calculé en fonction du nombre total de licences Sentinel émises. Si le hachage est inférieur au seuil, la réclamation est éligible au paiement.
Le contrat d'arbitrage garantit l'intégrité du réseau Xai en validant les réclamations et en récompensant celles qui aboutissent, incitant ainsi les nœuds sentinelles à surveiller le réseau avec précision et diligence.
4. Composante Challenger
Le challenger est une entité de confiance dans l'écosystème Xai. Il crée une paire de clés BLS et enregistre la clé publique dans le contrat d'arbitrage. Lorsqu'un validateur fait une réclamation dans le protocole de cumul Xai, le challenger signe la réclamation à l'aide de sa clé privée et soumet la signature à l'arbitre. L'arbitre vérifie la signature et l'enregistre comme un défi associé à la déclaration. Ce processus garantit l'intégrité des réclamations faites dans le protocole de cumul Xai.
5. Clé (autorisation de clé du nœud Sentinel, basée sur NFT)
La clé de licence Sentinel est un jeton unique et non fongible (NFT) requis pour faire fonctionner un nœud Sentinel dans le réseau Xai. Les licences Sentinel servent de preuve d'éligibilité aux nœuds pour soumettre des réclamations et recevoir des récompenses. Il est frappé en envoyant la quantité correcte d’ETH, et le prix de frappe est déterminé par un système de seuil croissant.
La licence de nœud joue un rôle clé dans le contrat d'arbitrage. Lorsqu'un nœud souhaite soumettre une réclamation à une contestation, il doit fournir son ID d'autorisation Sentinel. Le contrat d'arbitrage vérifie si la licence Sentinel est valide et si le nœud est propriétaire de la licence Sentinel ou un opérateur agréé (section KYC ci-dessus). Si ces conditions sont remplies, la réclamation du nœud est soumise au défi.
Les autorisations Sentinel entrent également en jeu lors de la réclamation de récompenses pour des réclamations réussies. Le contrat d'arbitrage vérifie si le propriétaire de la licence Sentinel a effectué le KYC et si la déclaration est éligible au paiement. Si ces conditions sont remplies, la récompense est envoyée au propriétaire de la licence Sentinel.
En résumé, l'autorisation Sentinel est un élément clé du réseau Xai, qui régule le fonctionnement des nœuds Sentinel, la soumission des réclamations et la distribution des récompenses.
6. Téléchargement et exécution du nœud
Pour exécuter un nœud sentinelle, les utilisateurs doivent uniquement télécharger un progiciel spécifique. Ce package peut être utilisé dans une application de bureau ou comme outil de ligne de commande sur votre ordinateur. En termes simples, ces applications sont des outils qui facilitent l'utilisation du logiciel Sentinel. Le but de ce package est d'automatiser toutes les opérations nécessaires à l'exécution de Sentinel, le rendant très simple à configurer et à utiliser, même si vous n'êtes pas technique.
Ce package aide les utilisateurs dans des tâches telles que la configuration, la gestion et l'interaction avec d'autres parties, et dispose d'une interface facile à utiliser qui permet aux utilisateurs d'afficher et d'ajuster facilement les paramètres. Grâce à ce package, les utilisateurs peuvent se concentrer davantage sur la façon de mieux fonctionner et d'obtenir plus de récompenses symboliques. Les utilisateurs peuvent choisir d'exécuter ce package à l'aide d'une application de bureau ou d'un outil de ligne de commande, qui sont tous deux très faciles à utiliser et rendent le processus de fonctionnement très fluide.
7. Fonction portefeuille Sentinel
Dans l'écosystème Xai, le portefeuille Sentinel joue un rôle clé dans l'interaction entre les nœuds Sentinel et les contrats intelligents d'arbitrage. Sentinel Wallet agit en tant qu'agent intermédiaire et est responsable de soumettre les déclarations à l'arbitre au nom des Sentinels concernés. Ceci est réalisé grâce à des fonctions spécifiques dans le contrat d'arbitre qui ne peuvent être appelées que par le propriétaire de la clé de licence Sentinel ou son adresse approuvée sur ce contrat.
Le portefeuille Sentinel peut soumettre une déclaration au défi en appelant la fonction submitAssertionToChallenge dans le contrat d'arbitre. Cette fonction vérifie si le défi est toujours ouvert à la soumission et si la clé du nœud a déjà été soumise pour ce défi.
Le portefeuille Sentry peut également réclamer des récompenses pour les réclamations réussies en appelant la fonction ClaimReward dans le contrat d'arbitrage. Cette fonctionnalité vérifie si le défi a été fermé pour soumission et vérifie si le propriétaire de la licence Sentinel a effectué une vérification « KYC ». Si ces conditions sont remplies et que la réclamation est éligible au paiement, la récompense sera envoyée au propriétaire du Sentinel.
En résumé, le Sentinel Wallet agit comme un messager, facilitant l'interaction entre les nœuds et les arbitres, assurant ainsi le bon fonctionnement du réseau Xai.
8. Licence
La relation entre le nombre de licences et les capacités de soumission du nœud est fondamentale. Bien qu'il soit possible qu'un nœud soit associé à plusieurs licences, il est important de réaliser que le nombre de licences affecte directement la capacité du nœud à s'engager. Essentiellement, pour garantir des quotas de validation équitables, le ratio licences/instances de nœuds est maintenu à 1:1. En suivant les principes ci-dessus, le système établit une approche structurée en matière de licences, de soumission des droits et de fonctionnement global des nœuds au sein de l'écosystème.
9. Configuration logicielle et matérielle requise pour le nœud Sentry
Le logiciel du nœud Sentinel prend en charge le bureau Windows, Mac et Linux (nécessite 64 bits). Voici les ressources actuelles requises pour exécuter le logiciel du nœud Sentinel pour un maximum de 100 clés de licence :
4 Go de RAM
2 cœurs de processeur
60 Go d'espace disque
Processeur x86/X64 (prend en charge le processeur ARM, tel que la puce Apple M1/M2)
Connexion Internet stable
Lors de l'ajout de clés supplémentaires à un nœud, idéalement, les capacités matérielles devraient augmenter en conséquence. Il n’est cependant pas obligatoire d’attribuer une machine distincte à chaque touche. Le système devrait être évolutif pour accueillir des dizaines de clés sur une seule machine, et peut-être plus.
Remarque : Ces exigences matérielles sont susceptibles de changer.
10. Récompenses estimées du réseau de nœuds Sentry
Modèle économique des jetons XAI, veuillez vous référer à : Interprétation de « l'économie des jetons » du projet XAI
Voici trois scénarios pour estimer les récompenses Xai que vous pourriez gagner en exécutant un nœud Sentry. Ces trois scénarios reposent sur les hypothèses suivantes :
La somme de XAI et esXAI ne dépassera jamais 2 500 000 000. Étant donné que l'écosystème Xai est dynamique, il est impossible de prédire avec précision les récompenses mensuelles en jetons pour chaque clé Sentry.
100 % du GAZ est brûlé, il n’y a donc aucune garantie que l’offre sera toujours inflationniste, elle peut être déflationniste.
La Fondation Xai ne vendra pas plus de 50 000 clés Sentry (un nœud peut charger plusieurs clés). Cela devrait prendre 2 à 3 ans. Les clés Sentry deviennent de plus en plus chères avec le temps.
Le montant mensuel esXAI par clé Sentry peut également fluctuer en fonction du nombre de participants au staking dans l'écosystème.
La signification des trois tableaux suivants est que, sous la circulation différente des jetons XAI et esXAI, le nombre de clés de nœud activées dans le réseau et les récompenses mensuelles attendues correspondantes par clé :
Estimation du scénario A : s'il y a un total de 750 000 jetons XAI et esXAI en circulation, alors chaque clé Sentry recevra des récompenses esXAI selon le tableau suivant :
![](https://public.bnbstatic.com/image/pgc/202310/bc517dde1eece24bf9061a2c6ddd24f0.png)
Estimation du scénario B : s'il y a un total de 1 250 000 000 de jetons XAI et esXAI en circulation, alors chaque clé Sentry recevra des récompenses esXAI selon le tableau suivant :
![](https://public.bnbstatic.com/image/pgc/202310/0df62e39997d0f05fc75ccac41d735c4.png)
Estimation du scénario C : s'il y a un total de 2 187 500 000 jetons XAI et esXAI en circulation, alors chaque clé Sentry recevra des récompenses esXAI selon le tableau suivant :
![](https://public.bnbstatic.com/image/pgc/202310/84db678120e93af9b0f91c49e9473463.png)
![](https://public.bnbstatic.com/image/pgc/202310/b97862068c5713e93fa8b54d94d3696e.png)
Partie 2 : XAI est développé et maintenu par Arbitrum (ARB), nous devons donc faire la lumière sur l'architecture d'Arbitrum :
1.Décision Nitro
Toutes les chaînes Arbitrum sont construites sur Arbitrum Nitro, qui est la technologie sous-jacente à toutes les chaînes de l'écosystème. Nitro exécute une version forkée de Geth et utilise WebAssembly comme machine virtuelle sous-jacente anti-fraude.
2. Décision Anytrust
Anytrust est un protocole Arbitrum qui gère la disponibilité des données via un ensemble de concédants de licence appelé Data Availability Committee (DAC). Ce protocole réduit les frais de transaction en introduisant une hypothèse de confiance supplémentaire concernant la disponibilité des données, plutôt que d’utiliser le mécanisme de disponibilité des données sans confiance d’Ethereum.
3. Introduction aux couches Arbitrum 2 que vous connaissez peut-être
Arbitrum Nova est un exemple de chaîne AnyTrust ; Arbitrum One est une autre chaîne alternative qui implémente le protocole Arbitrum Rollup purement sans confiance (et plus gourmand en gaz L1). Les deux chaînes sont construites sur Nitro.
4. Chaîne orbitale
Arbitrum Orbit permet à des tiers de créer leurs propres chaînes Arbitrum Rollup et AnyTrust autogérées. Arbitrum propose les technologies Rollup et AnyTrust pour une flexibilité maximale lors de la création de chaînes Orbit. Comme toutes les chaînes de l'écosystème Arbitrum, Arbitrum Rollups et la chaîne Arbitrum Anytrust Orbit sont construites en utilisant Nitro comme technologie sous-jacente.
5. Comprendre la situation de base de Xai
Comprenons Xai dans le contexte ci-dessus. Xai fonctionne comme une chaîne Arbitrum Orbit, tirant parti de la technologie Anytrust pour une vitesse maximale et un coût minimum. Contrairement à la plupart des chaînes Orbit « autonomes », Xai bénéficie du support technique direct d’Offchain Labs. Ce type de support est inimaginable pour les autres chaînes Orbit ! et constitue un élément clé du plan de jeu stratégique de Xai au sein de l’écosystème Arbitrum.
![](https://public.bnbstatic.com/image/pgc/202310/b97862068c5713e93fa8b54d94d3696e.png)
Partie 3 : Après avoir compris les concepts ci-dessus, comprenons davantage l'architecture :
1.AnyTrust : infrastructure blockchain révolutionnaire
Dans le cadre d'AnyTrust et en tant que variante de pointe de la technologie Arbitrum Nitro, Offchain Labs tire parti de l'innovation pour résoudre certains des défis les plus urgents dans l'espace blockchain. AnyTrust nous apporte une nouvelle perspective en intégrant des hypothèses de confiance légères, réduisant considérablement les coûts tout en garantissant une forte disponibilité et sécurité des données.
2. Réduisez les coûts grâce à des hypothèses de confiance
Au cœur du protocole Arbitrum, tous les nœuds Arbitrum (y compris les validateurs qui vérifient l'exactitude de la chaîne et mettent en jeu les résultats précis) doivent accéder aux données de chaque transaction de couche deux (L2) dans la boîte de réception de la chaîne Arbitrum. Traditionnellement, le cumul d'Arbitrum garantit l'accès aux données en publiant les données sous forme de données d'appel sur la couche un (L1) d'Ethereum, un processus qui génère d'importants frais de gaz Ethereum, qui constituent un élément de coût majeur dans Arbitrum.
3. Flexibilité des kits
Les Ketsets jouent un rôle clé dans l'architecture d'AnyTrust. Ils précisent les clés publiques des membres du comité et le nombre de signatures requises pour vérifier le certificat de disponibilité des données (DACert). Les Ketsets offrent une flexibilité pour changer de membre du comité et permettent aux membres du comité de mettre à jour leurs clés si nécessaire.
4. Certificats de disponibilité des données (DACerts)
Dans AnyTrust, un concept de base est le certificat de disponibilité des données (DACert). Un DACert comprend le hachage du bloc de données, une heure d'expiration et la preuve que les membres du comité N-1 ont signé la paire (hachage, heure d'expiration). Cette preuve comprend un hachage du jeu de clés utilisé pour la signature, un bitmap indiquant quels membres du comité ont signé et une signature globale BLS sur la courbe BLS12-381, prouvant le signataire.
En raison de l'hypothèse de confiance 2 sur N, DACert sert de preuve que les données d'un bloc seront disponibles pour au moins un membre honnête du comité jusqu'à une heure d'expiration spécifiée. Cette hypothèse de confiance constitue la base de la fiabilité et de la sécurité de la disponibilité des données dans le cadre AnyTrust.
5. Double mécanisme de publication des données
AnyTrust introduit une double méthode de publication de blocs de données sur L1. En plus de la méthode traditionnelle de publication de blocs de données complets, elle permet également la délivrance de DACerts, qui sont des certificats prouvant la disponibilité des données. Le contrat de boîte de réception L1 vérifie la validité des DACerts, y compris la référence aux Kesets valides spécifiés dans le DACert.
Le code L2 responsable de la lecture des données de la boîte de réception est conçu pour gérer les deux formats de données de manière transparente. Lorsqu'un DACert est rencontré, il effectue des contrôles de validité, notamment en s'assurant que le nombre de signataires répond aux exigences de Ketsets, en validant les signatures globales et en confirmant l'expiration au-delà de l'horodatage L2 actuel. Des DACerts valides garantissent que le bloc de données est accessible et peut être exploité par le code L2.
6. Serveur de disponibilité des données (DAS)
Les membres du comité exploitent le Data Availability Server (DAS), qui fournit deux API clés :
(1) API Sorter : conçue pour être utilisée par le trieur de la chaîne Arbitrum, cette interface JSON-RPC permet au trieur de soumettre des blocs de données au DAS pour stockage.
(2) API REST : conçu pour une accessibilité plus large, le protocole basé sur RESTful HTTP(S) permet la récupération de morceaux de données via un hachage. Il est entièrement mis en cache et peut être déployé conjointement avec des proxys de mise en cache ou des CDN pour améliorer l'évolutivité et se protéger contre les attaques DoS potentielles.
7. Interaction trieur-comité
Lorsque le trieur Arbitrum a l'intention de publier un lot de données via le comité, il envoie les données et un délai d'expiration à tous les membres du comité en parallèle via RPC. Chaque membre du comité stocke les données, signe le couple (hachage, heure d'expiration) à l'aide de sa clé BLS et renvoie la signature et l'indicateur de réussite au séquenceur. Une fois que suffisamment de signatures sont collectées, le séquenceur les regroupe pour créer un DACert valide pour les paires (hachage, heure d'expiration). Ce DACert est ensuite publié dans le contrat de la boîte de réception L1, le rendant accessible au logiciel de la chaîne AnyTrust de L2. Dans le cas où le séquenceur ne parvient pas à collecter suffisamment de signatures dans le délai imparti, il adopte une stratégie de « repli vers le rollup » et publie les données complètes directement sur la chaîne L1. Le logiciel L2 excelle dans la compréhension des deux formats de publication de données (via DACert ou données complètes) et dans la gestion appropriée de chaque format. En résumé, AnyTrust, en tant qu'innovation révolutionnaire au sein de l'écosystème Offchain Labs, représente une avancée cruciale en matière de disponibilité des données, de sécurité et de rentabilité de l'infrastructure blockchain. Grâce à une hypothèse de confiance raisonnable et à une nouvelle approche de la publication de données, AnyTrust ouvre la voie à des solutions blockchain plus évolutives, accessibles et sécurisées.
Partie 4 : Avec les concepts ci-dessus à l'esprit, expliquons maintenant pourquoi les nœuds sentinelles sont importants : le problème de la vérification des tricheurs, pourquoi le dilemme du validateur est plus difficile que vous ne le pensez et la solution !
L'auteur est Ed Felten, scientifique en chef chez Arbitrum
Dans les systèmes blockchain, un modèle de conception courant consiste à demander à une partie d'effectuer un travail et de déposer un dépôt pour un comportement correct, puis d'inviter d'autres personnes à vérifier le travail et à retirer ce dépôt s'ils surprennent le travailleur en train de tricher. Vous pourriez l'appeler le modèle de conception « défi d'affirmation ». Nous faisons cela dans Arbitrum et avons récemment vu des propositions comme Optimistic Rollup dans l'actualité.
Ces systèmes peuvent être affectés par le dilemme du validateur, qui consiste essentiellement à observer qu'il ne sert à rien de vérifier le travail de quelqu'un si vous savez qu'il ne trichera pas, mais que si vous ne vérifiez pas, il est incité à tricher. Si vous êtes un concepteur, vous voulez prouver que votre système est compatible avec les incitations, ce qui signifie que si tout le monde se comporte de manière cohérente avec ses incitations, aucune tricherie ne se produira. C’est un domaine dans lequel l’intuition peut vous induire en erreur. Ce problème est beaucoup plus difficile qu’il n’y paraît, comme nous le verrons lorsque nous examinerons ci-dessous les incitations des partis.
Un modèle ultra simple
Nous commençons par construire le modèle le plus simple possible. Supposons qu'il y ait deux joueurs. L'asserteur fait une déclaration qui peut être vraie ou fausse. Le vérificateur peut vérifier la déclaration de l'asserteur, ou il peut choisir de ne rien faire, vraisemblablement en supposant que l'asserteur dit probablement la vérité. Nous supposons que le coût de vérification du vérificateur est C. Si le vérificateur vérifie et constate que l'asserteur a triché, il recevra une récompense de R. (R inclut tous les avantages accumulés par le vérificateur suite à la détection d'une tricherie. Cela inclut les avantages réalisés « en dehors du système » ainsi que tous les avantages obtenus grâce à une confiance accrue dans le système.) Si l'asserteur n'est pas attrapé, sous triche. , le contrôleur perd L, par exemple parce que l'affirmateur tricheur peut frauduleusement prendre des objets de valeur au contrôleur.
Nous devons désormais nous inquiéter de deux menaces : la corruption et la paresse. La corruption est la possibilité pour l'asserteur de soudoyer le vérificateur pour qu'il ne vérifie pas, permettant ainsi à l'asserteur de tricher sans être détecté. Nous pouvons éviter que cela ne se produise en veillant à ce que l'asserteur dépose un dépôt très important, supérieur à la valeur totale dans le système, et paie le vérificateur lorsqu'une tricherie est détectée, de sorte que l'asserteur ne soit pas disposé à payer un montant supérieur à la récompense R du vérificateur. pot-de-vin. Cela empêchera la corruption, mais cela nécessite que le système soit entièrement garanti, ce qui peut être très coûteux.
Une autre menace est la paresse, le risque que le vérificateur décide de ne pas vérifier le travail de l'asserteur. (N'oubliez pas que les contrôleurs peuvent dire qu'ils vérifient, mais ne le font pas réellement.) Examinons les incitations offertes aux contrôleurs pour voir s'il s'agit d'une stratégie raisonnable.
Supposons que l'asserteur triche avec une probabilité X. Désormais, l'utilitaire de l'inspecteur est le suivant :
Si l'examinateur vérifie : RX-C
Si le vérificateur ne vérifie pas : -XL
Vérifier n'a de sens que si l'utilité de vérifier est supérieure à celle de ne pas vérifier, c'est-à-dire si X > C/(R+L). Voici la mauvaise nouvelle : l'asserteur peut tricher de manière aléatoire, avec une probabilité inférieure à C/(R+L), un vérificateur rationnel ne vérifiera jamais, donc l'asserteur ne sera jamais surpris en train de tricher.
Insérons quelques chiffres. Si le coût de vérification de chaque transaction est de 0,10 $ et que le vérificateur reçoit une prime de 75 $ s'il détecte une tricherie, mais perd 25 $ s'il ne parvient pas à détecter la tricherie, alors l'asserteur peut tricher en toute impunité mille fois. Si nous voulons que ce système exécute des milliers de transactions, nous avons alors un gros problème. Nous ne pouvons évidemment rien faire dans ce modèle pour réduire à zéro la probabilité de tricherie. Nous ne pouvons qu’espérer un système surdimensionné afin que le dénominateur de C/(R+L) devienne plus grand.
Il s’agit d’un résultat étonnamment robuste – dans le mauvais sens. Cela ne dépend pas du tout des incitations de celui qui affirme. Tant que l'asserteur obtient un avantage non nul en trichant avec succès, il peut le faire avec une certaine probabilité, sachant que cela ne vaut pas la peine de vérifier de la part du vérificateur. Ce résultat ne dépend pas non plus du temps que nous accordons à l'inspecteur pour terminer le travail, ni du fait que nous rémunérons le (prétendu) inspecteur. Peut-être pensez-vous maintenant que le problème est qu'il n'y a qu'un seul inspecteur. L'ajout de pions supplémentaires réduirait-il le risque de tricherie ? Étonnamment, ce n’est pas le cas.
L'ajout de censeurs n'aide pas à empêcher la tricherie
Encore une fois, formulons un modèle le plus simple. Il y a désormais deux inspecteurs agissant de manière indépendante. Chaque vérificateur paie C s'il vérifie, et si quelqu'un vérifie et surprend l'asserteur en train de tricher, une récompense de R est versée au vérificateur qui réussit, ou s'ils vérifient tous les deux, la récompense est divisée à parts égales entre les deux. (Si vous le souhaitez, vous pouvez donner à l'un d'eux une récompense aléatoire complète de R dans le cas où ils checkent tous. Cela n'affecte pas la stratégie ou les résultats de quiconque.) Comme auparavant, chaque vérificateur perdra L si l'asserteur triche sans obtenir attrapé.
Il reste que si l'asserteur triche moins de C/(R+L) du temps, alors cela ne vaut pas la peine pour le vérificateur de vérifier, puisque l'utilité de vérifier est moindre que l'utilité de ne pas vérifier. En fait, le problème d'incitation est pire qu'auparavant, car le coût du contrôle par contrôleur est toujours C, mais la récompense attendue pour un contrôleur réussi à attraper la triche est inférieure à R, car la récompense doit parfois être divisée - la récompense attendue sera être dans R/2 et R. Si la récompense attendue est bR, où b est compris entre 0,5 et 1, alors l'asserteur peut tricher jusqu'à C/(bR+L) - c'est plus de triche non détectée que s'il n'y avait qu'un seul vérificateur ! (Le calcul devient un peu compliqué car la valeur de b dépend de la stratégie du vérificateur, et sa stratégie dépend de b, mais il doit être clair qu'il devra parfois partager la récompense. De plus, la valeur effective de L est également réduite. , puisque les pions ne peuvent pas perdre leur L en cas de contrôle par d'autres pions).
L’ajout de censeurs serait vraiment utile dans la prévention de la corruption. Avec deux pions, l'asserteur doit payer un pot-de-vin supérieur à R à chaque asserteur, ce qui rend le pot-de-vin deux fois plus cher, permettant une mise de 50 % au lieu d'une mise totale. Mais le compromis est que le nombre de tricheries augmente.
Je n'entrerai pas dans tous les calculs ici, mais dans des hypothèses raisonnables, passer d'un pion à deux pourrait entraîner une augmentation de 50 % des tricheries non détectées.
Ajouter des censeurs ne fait qu'empirer les choses !
Vous pouvez ajouter plus de pions et les choses empireront. À mesure que le nombre de vérificateurs augmente, le vérificateur doit s'inquiéter davantage de la répartition de la récompense de plusieurs manières, de sorte que la récompense attendue pour chaque vérificateur réussi diminue progressivement, ce qui entraîne une augmentation progressive de la probabilité que l'asserteur triche en toute sécurité. De ce point de vue, le pire des cas est que tout le monde puisse devenir censeur. Ce n’est pas infiniment mauvais, puisque les choses empirent à mesure que de plus en plus de censeurs sont ajoutés, mais cela n’aidera certainement pas à prévenir la tricherie, même si cela élimine efficacement le risque de corruption.
Êtes-vous sûr que votre système est compatible avec les incitations ?
Si vous disposez d’un système qui correspond à ce type de modèle et que vous pensez qu’il est compatible avec les incitations, vous devez bien réfléchir aux raisons. En particulier, vous devez expliquer pourquoi le vérificateur ferait le travail de vérification, même s'il pense qu'il est peu probable que l'asserteur triche. Il ne suffit pas d'imposer une lourde pénalité pour tricherie. Il ne suffit pas d’avoir simplement une récompense pour avoir attrapé les tricheurs. Avoir beaucoup de dames ne suffit pas – en fait, cela peut aggraver les choses. Pourquoi votre système est-il immunisé ?
Ce défi s'applique à des systèmes comme Optimistic Rollup. Quand on parle d’Arbitrum, cela s’applique aussi à nous.
Compte tenu de ce qui précède, les méthodes traditionnelles de vérification des incitations n’obtiennent pas les résultats souhaités : il existe un taux de triche de base en dessous duquel les contrôleurs considéreront que le contrôle n’en vaut pas la peine. En conclusion:
Il y a deux joueurs, un asserteur, qui fait une affirmation, qu'elle soit vraie ou fausse, et un vérificateur, qui peut vérifier cette affirmation moyennant un certain coût de calcul. Si le vérificateur vérifie, son utilité est RX-C, s'il ne vérifie pas, son utilité est -XL, où R est la récompense pour avoir détecté une tricherie, C est le coût de la vérification et L est la perte du vérificateur due à la non-détection de la triche. , X est la probabilité que l'asserteur triche (choisi par l'asserteur). Certaines algèbres montrent que si
Pour résoudre ce problème et créer une situation dans laquelle un évaluateur motivé par des incitations vérifiera toujours, nous devons modifier les incitations de l'évaluateur. Le problème fondamental est que dans le modèle original, les incitations positives pour les contrôleurs à vérifier sont toutes proportionnelles à Si nous voulons une incitation au contrôle qui fonctionne indépendamment des actions de l'asserteur, nous devons créer une incitation au contrôle ou une dissuasion pour ne pas vérifier.
TrueBit tente de le faire en ajoutant intentionnellement de fausses affirmations à l'ensemble des assertions, remplaçant essentiellement X par X plus une constante. Cette approche pose certains problèmes. (L'article original d'Arbitrum contient une section sur les problèmes de motivation de TrueBit.)
Concentrez-vous sur les défis
Nous utilisons une approche différente que nous appelons la concentration sur le défi. L’idée est que si l’asserteur calcule une valeur f(x), il émet d’abord x et un défi cryptographique. Pour répondre correctement au défi, l'examinateur doit connaître f(x). Ce n'est qu'après que le défi a eu lieu que l'asserteur publie f(x) - à ce stade, le vérificateur a déjà fait le dur travail de calcul de f(x), il n'est donc pas incité à être paresseux. (Plus de détails sur l'accord suivent.)
Pour réduire le nombre de transactions en chaîne que cela nécessite, nous ferons en sorte que la réponse correcte à un défi lancé par un vérificateur soit généralement le silence. Mais dans de rares cas, le vérificateur doit publier une très petite transaction sur la chaîne. Si le vérificateur donne une mauvaise réponse - silence lorsqu'il doit être relâché, ou silence lorsqu'il doit être relâché - il perdra un petit dépôt.
Adaptons le modèle d'incitation original pour intégrer les défis d'attention. Nous avons besoin de deux nouveaux paramètres (que nous pouvons choisir tous les deux) : P, le pourcentage de temps pendant lequel la réponse correcte du vérificateur est affichée, et A, la pénalité si le vérificateur donne une mauvaise réponse. Maintenant, l'utilitaire de l'inspecteur est :
Si coché : RX-C
Sinon cocher : -LX-PA
L’observation clé est que tant que PA > C, la vérification est la stratégie optimale, quelle que soit X (la probabilité de tricher).
Très faible coût
Pour évaluer le coût, regardons un exemple concret. Supposons qu'il y ait une assertion toutes les cinq minutes et que le coût de la vérification soit de 0,001 $. Si l’on fixe la probabilité P à 0,3%, le vérificateur devra payer un dépôt de 3$. Désormais, le coût par assertion du vérificateur est de 0,0003 $ en frais de gaz (les frais de gaz de 0,10 $ pour la publication de sa réponse non silencieuse, multipliés par la probabilité de 0,3 % qu'il doit publier), plus environ 0,0003 $ pour verrouiller sa mise de 3 $ pendant cinq minutes. Le total le coût des intérêts est de 0,0006 $ par assertion.
Extension pour plusieurs inspecteurs
Le défi de concentration s’adapte bien à plusieurs examinateurs. Le protocole lance un défi qui affecte chaque vérificateur différemment, obligeant chaque vérificateur à calculer f(x) seul. Chaque vérificateur subira le même coût (dans notre cas, 0,0006 $ par assertion).
Dans un système ouvert, n'importe qui peut vérifier les calculs, et vous pouvez autoriser n'importe qui à s'inscrire en tant que vérificateur et à effectuer le petit dépôt requis. Cela les rendra éligibles pour recevoir des défis d’attention et potentiellement recevoir une compensation de la part des développeurs de dapps. N'importe qui peut contester les affirmations incorrectes d'un déclarant, mais seuls les examinateurs enregistrés sont confrontés à des problèmes d'attention.
Détails techniques de l'accord
Maintenant que nous comprenons ce que le fait de se concentrer sur les défis peut faire pour nous, examinons les détails techniques de leur fonctionnement.
Chaque vérificateur possède une clé privée k et une clé publique correspondante gᵏ, définies dans un groupe approprié. La clé publique de chaque vérificateur est connue de tous. Nous nous appuierons également sur une fonction de hachage H adaptée.
Pour lancer un défi au calcul de f(x), où la fonction f est connue à l'avance, l'asserteur génère une valeur aléatoire r puis émet (x, gʳ) comme défi.
Un vérificateur possédant la clé privée k devrait répondre au défi en publiant une petite transaction uniquement si H(gʳᵏ, f(x)) < T, où T est un seuil convenablement choisi. Notez que seuls l'asserteur (qui connaît r) et ce vérificateur particulier (qui connaît sa clé privée k) peuvent calculer le hachage, puisqu'ils sont les seuls à pouvoir calculer gʳᵏ. Notez également que le calcul du hachage nécessite de connaître f(x).
Une fois que les contrôleurs ont eu le temps de poster leurs réponses au défi, l'asserteur peut publier son f(x) et si un contrôleur n'est pas d'accord avec cela, il sera contesté comme d'habitude. À ce stade, l'asserteur peut accuser n'importe quel vérificateur de réponses incorrectes ; l'asserteur doit émettre r pour justifier son accusation. Le mineur ou le contrat peut vérifier si l'accusation est correcte et punir le contrevenant ; mais si l'affirmation de f(x) par l'affirmateur n'est pas finalement acceptée comme correcte, l'accusation sera ignorée ; Si un vérificateur est condamné à une amende, l'asserteur recevra la moitié des fonds confisqués et l'autre moitié sera détruite.
Cette approche donne à l'examinateur les bonnes incitations. Savoir comment un vérificateur doit répondre à un défi nécessite de connaître la clé privée de ce vérificateur et f(x), donc chaque vérificateur voudra calculer f(x). À moins que le vérificateur ne calcule f(x) lui-même, il ne peut pas appliquer le protocole en toute sécurité. Les réponses des autres vérificateurs ne sont pas utiles pour déterminer f(x) car elles s'appuient sur les clés privées de ces vérificateurs. Si un vérificateur s'appuie sur quelqu'un d'autre pour lui dire f(x), il n'a aucun moyen de vérifier cette valeur revendiquée (autre que le calcul de f(x) lui-même), et le vérificateur risque d'être pénalisé s'il se trompe. Il existe même une incitation pour qu'une partie essaie d'induire le vérificateur en erreur à propos de f(x) - c'est-à-dire l'asserteur, qui profite de l'erreur du vérificateur et peut utiliser ces bénéfices pour soudoyer les "amis" du vérificateur afin de lui fournir des informations erronées. .
Optimisation et conclusion
Il existe plusieurs astuces pour rendre ce protocole plus efficace. Par exemple, nous pourrions regrouper une assertion avec le prochain défi dans une transaction en chaîne afin que le défi n'augmente pas le nombre de transactions. Si P est petit (par exemple 0,3 % dans notre exemple) et que le nombre de contrôleurs n'est pas très grand, alors les contrôleurs ont rarement besoin d'écrire des transactions sur la chaîne, donc l'impact global du protocole sur le nombre de transactions en chaîne sera être le plus petit.
Avec une mise en œuvre intelligente, le coût de ce protocole devrait être très faible par rapport au coût initial de l'émission d'assertions en chaîne. Dans notre cas, l’ajout de défis d’attention au protocole de défi d’assertion existant augmente le coût total de moins de 1 %.
Et les gains sont substantiels : nous obtenons un protocole de vérification compatible avec les incitations et qui est à l’abri du dilemme du validateur. Tant qu'au moins un vérificateur est rationnel, les affirmations de l'asserteur seront toujours vérifiées.
Pour d'autres informations sur le projet, veuillez vous référer à : Chaîne publique de jeu Xai : base de données Binance Square