Aller au contenu
Financial Context Wiki

Clients légers

Guide tenant compte des forks sur l'amorçage des clients légers de consensus, les comités de synchronisation, les points de contrôle de subjectivité faible, les en-têtes optimistes et finalisés, les preuves d'état d'exécution, les fournisseurs RPC, la disponibilité des données et la confidentialité.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Un client léger est un logiciel de vérification qui suit une blockchain en conservant moins d’exécution, d’état et d’historique localement qu’un nœud complet. Un nœud léger est un appareil ou un processus qui exécute ce logiciel. Sur Ethereum en preuve d’enjeu, un client léger de consensus s’amorce depuis un point de contrôle finalisé, récent et de confiance, puis vérifie les mises à jour des comités de synchronisation en tenant compte des forks afin de maintenir des en-têtes optimistes et finalisés. Il ne réexécute pas chaque transaction EVM.

Cette vue vérifiée du consensus n’est que le premier ancrage de confiance. Pour vérifier la valeur d’un compte ou du stockage d’un contrat, le client doit relier l’en-tête beacon authentifié à l’en-tête de la charge utile d’exécution, sélectionner son stateRoot et vérifier une preuve de compte ou de stockage par rapport à cette racine. Une réponse RPC ordinaire dépourvue de la preuve requise reste une affirmation du fournisseur. Les signatures de consensus ne prouvent pas automatiquement l’historique des transactions, les reçus, les traces, la disponibilité des données, le comportement des applications ou leur récupération à long terme.

Fonctionnement

  1. Fixer le réseau et les racines de confiance : identité de la chaîne, racine et heure des validateurs de genèse, calendrier des forks et paramètres prédéfinis, horloge courante, version du client et point de contrôle finalisé, récent et de confiance pour la subjectivité faible. Recouper le point de contrôle auprès de sources authentifiées indépendantes ; l’accord entre pairs ne peut corriger une racine initiale malveillante.
  2. Obtenir un LightClientBootstrap pour la racine du bloc de confiance. Vérifier l’en-tête d’amorçage, le comité de synchronisation courant et sa branche de Merkle, puis initialiser le LightClientStore. Rejeter toute chaîne, empreinte de fork, indice généralisé ou schéma de sérialisation qui ne correspond pas au fork configuré.
  3. Traiter les objets LightClientUpdate par période du comité de synchronisation. Avant la rotation des comités, vérifier les slots, bits de participation, signature BLS agrégée et domaine, branches des comités courant et suivant, branche de finalité et monotonie. Les mises à niveau de fork peuvent modifier les champs des objets et les indices généralisés ; les constantes d’Altair ne sont pas des valeurs universelles permanentes.
  4. Maintenir des politiques distinctes pour optimistic_header et finalized_header. Une mise à jour optimiste peut fournir une information plus récente, mais davantage exposée à une réorganisation ou à une rétention ; une mise à jour finalisée possède un statut de consensus plus fort, mais peut être en retard. L’application doit sélectionner explicitement l’en-tête approprié, plutôt que de rebaptiser finale la réponse la plus récente.
  5. Ancrer les données d’exécution. Vérifier l’en-tête de la charge utile d’exécution et la branche portés par l’en-tête authentifié du client léger, puis lier chaque requête de compte ou de stockage au stateRoot, au hash de bloc et au statut de finalité de cette exécution. Sur Ethereum, eth_getProof peut renvoyer une preuve de compte et les preuves de stockage demandées ; les nœuds, chemins, valeurs et preuves d’inexistence doivent être vérifiés localement.
  6. Inventorier chaque surface non vérifiée. Une preuve de solde n’authentifie ni reçu de transaction, requête de logs, trace, simulation d’appel, mempool, étiquette de token, oracle, blob ou plage historique, ni l’affirmation du fournisseur qu’aucun résultat n’a été omis. Pour chaque objet requis, définir une preuve, une reconstruction indépendante, un repli sur un nœud complet ou une hypothèse de confiance explicite.
  7. Fonctionner en mode fermé en cas d’échec. Enregistrer le point de contrôle, le fork, les racines optimiste et finalisée, le bloc et la racine d’état d’exécution, les nœuds de preuve, le fournisseur et les horodatages. Imposer une ancienneté maximale, diversifier fournisseurs et chemins réseau, protéger la confidentialité des requêtes, tester la reprise après attaque par éclipse ou panne et recourir à un nœud complet ou à un autre système de vérification lorsque la surface de preuve du client léger est insuffisante.

Exemples détaillés

  • Seuil entier du comité de synchronisation. Pour un comité de 512 membres, le test de supermajorité prévu par la spécification est participants * 3 >= 512 * 2. Avec 341 participants, 341 / 512 = 66.6015625% et 1,023 < 1,024 : le test échoue. Avec 342, 342 / 512 = 66.796875% et 1,026 >= 1,024 : il réussit. Cela vérifie la règle configurée pour la mise à jour ; cela ne prouve pas l’honnêteté de chaque membre du comité ou de chaque implémentation.
  • Horloges des en-têtes. Un point de contrôle pédagogique se trouve au slot 10,000, un en-tête attesté au slot 10,064 et son en-tête finalisé au slot 10,032. À 12 seconds/slot, l’en-tête attesté se situe 64 * 12 = 768 seconds = 12 minutes 48 seconds après le point de contrôle, tandis que la finalité accuse un retard de 32 * 12 = 384 seconds = 6 minutes 24 seconds sur l’en-tête attesté. Le rythme des slots ne garantit ni livraison réseau ni finalité selon un SLA fixe en temps réel.
  • Branche compacte, affirmation limitée. Dans un arbre équilibré idéal de 2^20 feuilles, la branche d’une seule feuille comporte 20 hash frères. À 32 bytes/hash, cela représente 640 bytes ; comparée à un objet de 8 MiB = 8,388,608 bytes, la branche représente 0.00762939453125% de sa taille, soit une réduction de 99.99237060546875%. La branche prouve uniquement la relation entre sa feuille et la racine, pas la disponibilité des autres octets.
  • Preuve contre simple RPC. Au niveau d’un stateRoot d’exécution finalisé, une preuve de compte vérifiée donne 3.25 ETH, tandis qu’une réponse RPC sans preuve annonce 3.30 ETH. L’écart est de 0.05 ETH et la réponse non prouvée est supérieure de 0.05 / 3.30 = 1.5151515152%. Il faut retenir la valeur prouvée sous la racine sélectionnée, sans en déduire un solde ultérieur, un reçu, un résultat historique ou l’identité d’un token.

Risques

  • Configurer la mauvaise chaîne, racine des validateurs de genèse, heure de genèse ou paramètres prédéfinis.
  • S’amorcer depuis un point de contrôle malveillant, obsolète ou non finalisé.
  • Utiliser une seule source de point de contrôle non authentifiée ou accepter un fork à longue portée.
  • Laisser une dérive de l’horloge locale fausser slots, périodes, domaines ou décisions d’ancienneté.
  • Exécuter un calendrier de forks, schéma d’objet ou indice généralisé obsolète.
  • Ne pas valider la participation du comité de synchronisation, les signatures BLS ou les domaines.
  • Manquer la rotation du comité ou accepter un comité courant ou suivant invalide.
  • Traiter l’en-tête optimiste comme l’en-tête finalisé.
  • Relier le mauvais en-tête beacon, la mauvaise charge utile d’exécution ou le mauvais hash de bloc d’exécution.
  • Vérifier une preuve de compte ou de stockage par rapport au mauvais stateRoot.
  • Accepter des nœuds de trie, chemins, encodages ou preuves d’inexistence mal formés.
  • Traiter comme vérifiée une méthode RPC non prise en charge ou dépourvue de preuve.
  • Recevoir du fournisseur des réponses obsolètes, censurées, incomplètes ou fabriquées.
  • Subir une attaque par éclipse, Sybil ou une défaillance de contrôle commun entre fournisseurs apparemment distincts.
  • Perdre en disponibilité lorsque les nœuds complets fournissant les preuves élaguent ou cessent de servir les données.
  • Confondre validité du consensus, réexécution et correction de l’application.
  • Confondre preuve valide, disponibilité des données et récupération permanente.
  • Ne pas disposer des reçus, logs, traces, corps ou historiques requis par l’application.
  • Défaillance de l’implémentation, d’une dépendance, du binaire ou de la mise à niveau de fork du client.
  • Fuite des requêtes, IP, comptes et transactions auprès des fournisseurs ou pairs.

Idées reçues

  • Un client léger n’est qu’un nœud complet plus petit ou un endpoint RPC distant rebaptisé.
  • Un en-tête vérifié par le comité de synchronisation rend toute réponse RPC fiable.
  • L’en-tête optimiste le plus récent équivaut à un en-tête finalisé.
  • Une preuve de Merkle ou une signature de consensus prouve la disponibilité des données et l’intégralité de l’historique.
  • L’utilisation d’un client léger procure automatiquement la confidentialité, la disponibilité et la résistance à la censure d’un nœud complet.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...