TeleportDAO : Sécurité et efficacité dans la validation des données, les dernières pratiques en conception de nœuds légers
TechFlow SélectionTechFlow Sélection
TeleportDAO : Sécurité et efficacité dans la validation des données, les dernières pratiques en conception de nœuds légers
TeleportDAO est un projet axé sur l'infrastructure de communication inter-chaînes entre Bitcoin et les blockchains EVM.
Dédié à des analyses Web3 approfondiesAuteurs : Andy, Arthur
TL;DR
TeleportDAO et Eigen Labs ont récemment publié conjointement un article centré sur les défis de sécurité et d'efficacité auxquels sont confrontés les nœuds légers lorsqu'ils accèdent et valident des données en chaîne dans les blockchains à preuve d'enjeu (PoS). L'article propose une nouvelle solution visant à garantir la sécurité et l'efficacité des nœuds légers dans les blockchains PoS grâce à des incitations économiques, un mécanisme de pré-sécurité assuré, une « sécurité programmable » personnalisée et des mesures rentables. Cette approche est hautement prospective et mérite une étude approfondie.
Note : Eigen Labs est le développeur derrière le protocole Restaking EigenLayer et EigenDA. À ce jour, Eigen Labs a levé plus de 150 millions de dollars auprès de sociétés de capital-risque renommées telles qu'a16z, Polychain et Blockchain Capital.
TéléportDAO, basé à Vancouver au Canada, est un projet d'infrastructure pour la communication inter-chaînes entre Bitcoin et les chaînes EVM. Le protocole a récemment mené avec succès une vente publique via CoinList, levant 9 millions de dollars. Ce tour de financement a réuni plusieurs investisseurs, notamment Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across et bitSmiley.
Problèmes actuels liés à la conception des nœuds légers
Actuellement, dans les blockchains PoS, les validateurs participent au réseau de consensus en verrouillant une certaine quantité de jetons mis en jeu (par exemple 32 ETH sur Ethereum), assurant ainsi la sécurité du réseau. La sécurité des blockchains PoS repose donc essentiellement sur une protection économique : plus le montant total mis en jeu est élevé, plus le coût ou la perte nécessaire pour attaquer le réseau de consensus est important. Ce mécanisme de sanction repose sur une fonction appelée « sécurité par responsabilité », qui permet de confisquer les mises si un validateur signe des états contradictoires.
Les nœuds complets jouent un rôle crucial dans le maintien de l'intégrité des blockchains PoS. Ils stockent toutes les informations des transactions, vérifient les signatures de consensus, dupliquent l'historique complet des transactions et exécutent les mises à jour d'état. Ces opérations nécessitent d'importantes ressources informatiques et du matériel complexe. Par exemple, faire fonctionner un nœud complet Ethereum requiert au minimum un disque dur SSD de 2 To. En revanche, les nœuds légers réduisent leurs besoins en ressources informatiques en ne stockant que les en-têtes de blocs, ce qui les limite à des cas d'utilisation spécifiques comme la validation de transactions/états particuliers, par exemple dans les portefeuilles mobiles ou les ponts inter-chaînes. De plus, les nœuds légers dépendent des nœuds complets pour obtenir les informations de bloc, mais le marché des fournisseurs de nœuds est actuellement assez concentré, compromettant ainsi leur sécurité, indépendance et rapidité. Cet article examine donc les compromis entre coût d'acquisition des données et latence pour atteindre une sécurité optimale des nœuds légers.
Conceptions existantes de nœuds légers
Bitcoin a introduit la vérification de paiement simplifiée (SPV) comme protocole pour ses nœuds légers. L’SPV permet aux nœuds légers de vérifier qu’une transaction est incluse dans un bloc spécifique en utilisant une preuve de Merkle et les en-têtes de blocs. Ainsi, les nœuds légers peuvent télécharger uniquement les en-têtes de blockchain et valider la finalité des transactions en examinant la profondeur du bloc. Dans ce cas, le coût de calcul pour la vérification du consensus par les nœuds légers dans Bitcoin est relativement faible. Toutefois, dans les blockchains PoS comme Ethereum, la vérification du consensus est fondamentalement plus complexe. Elle implique de maintenir l’ensemble complet des validateurs, de suivre les changements de leurs mises, et d’effectuer de nombreuses vérifications de signatures pour le réseau de consensus. D’autre part, la sécurité des nœuds légers PoW repose sur l’hypothèse que la majorité des nœuds complets sont honnêtes. Pour résoudre les limites de l’SPV, FlyClient et les preuves non interactives de travail (NiPoPoW) offrent aux clients une preuve des blocs à un coût sous-linéaire. Toutefois, leur applicabilité aux modèles de consensus PoS est limitée.
En comparaison, les blockchains PoS tirent leur sécurité du mécanisme de confiscation. Ce système suppose que les participants au consensus agissent rationnellement : tant que le coût d'une attaque dépasse tout profit potentiel, ils n'attaqueront pas le réseau. Pour réduire les coûts de validation, le protocole actuel des nœuds légers d'Ethereum s'appuie sur un comité de synchronisation (sync committee), composé de 512 validateurs sélectionnés aléatoirement, chacun ayant misé 32 ETH, mais dont les signatures ne sont pas soumises à confiscation. Ce design sans risque de confiscation présente un grave défaut de sécurité : des membres malhonnêtes du comité peuvent induire les nœuds légers en erreur en leur transmettant des données invalides, sans encourir aucune sanction. Même avec l'introduction d'un mécanisme de confiscation, la mise totale du comité de synchronisation reste très faible par rapport au vaste pool de validateurs d'Ethereum (dépassant 1 million de validateurs en mars 2024). Ainsi, cette méthode ne peut offrir aux nœuds légers une sécurité équivalente à celle de l'ensemble des validateurs d'Ethereum. Ce modèle représente une variante particulière du calcul multipartite dans un cadre rationnel, mais il ne fournit pas de garanties économiques ni ne résout les menaces posées par des fournisseurs de données malveillants et irrationnels.
Pour relever les défis de sécurité et d'efficacité durant l'amorçage PoS, PoPoS a introduit un jeu segmenté afin de contester efficacement l'arbre de Merkle adversarial du timing PoS. Bien qu'il réalise une occupation minimale de l'espace et évite d'exiger que le client reste constamment en ligne ou maintienne une mise, il ne résout pas encore le problème des coûts élevés pour les clients qui se reconnectent après une période hors ligne.
Une autre voie de recherche exploite les preuves à connaissance nulle (zero-knowledge proofs) pour créer des preuves concises. Par exemple, Mina et Plumo facilitent efficacement la validation légère du consensus grâce à des combinaisons récursives de SNARK et à des preuves de transition d'état basées sur SNARK. Toutefois, ces méthodes imposent un fardeau de calcul considérable aux producteurs de blocs et ne traitent pas la question de la compensation des pertes potentielles des nœuds légers. Dans d'autres protocoles PoS (comme Tendermint utilisé par Cosmos), le rôle des nœuds légers est exploré dans le cadre de leur protocole de communication inter-chaînes (IBC). Mais ces implémentations sont propres à leurs écosystèmes respectifs et ne s'appliquent pas directement à Ethereum ou à d'autres blockchains PoS diverses.
Nouvelle conception de nœud léger
Globalement, la nouvelle solution introduit un module de sécurité économique pour réaliser une « sécurité programmable », permettant aux nœuds légers d’adapter leur niveau de sécurité selon leurs besoins. Les hypothèses de sécurité reposent essentiellement sur 1/N + 1/M, c’est-à-dire que le bon fonctionnement du réseau est garanti dès lors qu’il existe au moins un nœud complet honnête et un inspecteur honnête.
Modules/Rôles impliqués
-
Blockchain : le protocole repose sur une blockchain programmable dont les règles de finalisation des blocs sont déterministes. Par exemple, sur Ethereum, la finalisation d’un bloc nécessite au moins deux epochs suivants, soit environ 13 minutes.
-
Contrat intelligent de confiscation : le protocole comprend un contrat de confiscation en chaîne conforme à l’abstraction standard des contrats intelligents. Il peut accéder au hachage du bloc précédent dans la blockchain. Toutes les parties peuvent envoyer des informations à ce contrat.
-
Fournisseur de données : les fournisseurs exécutent des nœuds complets et surveillent l’état le plus récent de la blockchain. Ils misent des actifs pour offrir un service de validation de l’authenticité des états demandés par les nœuds légers. Ils signent toutes les données envoyées aux nœuds légers avec la clé privée correspondant à leur clé publique, garantissant ainsi l’origine et l’intégrité des données.
-
Inspecteur : un inspecteur est un nœud complet connecté à un nœud léger, qui l’aide à vérifier les données. N’importe qui peut devenir inspecteur et tirer profit de la surveillance et de la confiscation des entités malhonnêtes. Par souci de simplicité, le schéma suivant suppose que chaque nœud léger est connecté à au moins un inspecteur honnête.
-
Nœud léger : un nœud léger cherche à valider à moindre coût qu’un état/transaction spécifique est bien inclus dans la blockchain. Pendant la vérification, il interagit avec un ensemble de fournisseurs de données et d’inspecteurs.
-
Réseau : les fournisseurs de données forment un réseau pair-à-pair (p2p) qui diffuse les données via le protocole Gossip. Les nœuds légers se connectent à certains fournisseurs pour envoyer des requêtes et recevoir des réponses.
Solution 1 : priorité à la sécurité
La solution 1 repose principalement sur une période de contestation et un réseau d’inspecteurs pour assurer la fiabilité des données. En résumé, après avoir reçu des données signées par un fournisseur, le nœud léger transmet ces données au réseau d’inspecteurs pour examen. Pendant une période définie, si une falsification est détectée, l’inspecteur alerte le nœud léger que les données ne sont pas fiables ; le module de confiscation du contrat intelligent saisit alors la mise du fournisseur. À défaut d’avertissement, le nœud léger peut considérer les données comme fiables.
Procédure de demande de données par le nœud léger :
-
Le nœud léger récupère la liste la plus récente des fournisseurs de données disponibles sur le réseau et fixe une période de contestation. Cette période varie selon les nœuds légers, mais son maximum est commun à tous. La période de contestation correspond au temps maximal accordé au réseau d’inspecteurs pour vérifier la fiabilité des données : plus elle est longue, plus la latence pour chaque transaction augmente.
-
Après avoir obtenu la liste, le nœud léger sélectionne un groupe de fournisseurs dont les mises individuelles dépassent la valeur de la transaction concernée. En théorie, plus la mise est élevée, plus le coût de la malhonnêteté est grand, et donc plus faible est le coût de confiance pour le nœud léger.
-
Le nœud léger envoie une requête de données à ce groupe, incluant le numéro de bloc cible et l’état visé (la preuve d’inclusion de la transaction).
-
Le fournisseur renvoie le hachage du bloc concerné, la preuve d’inclusion de la transaction, accompagnés de sa signature.
-
Une fois ces éléments reçus, le nœud léger les transfère à son réseau d’inspecteurs. Si aucun avertissement n’est reçu à l’issue de la période de contestation, il procède à la vérification de la signature. S’il n’y a pas d’anomalie, les données passent le test de fiabilité.
-
Si en revanche un avertissement est reçu du réseau d’inspecteurs, le nœud léger doit rejeter la signature précédemment reçue. Le réseau d’inspecteurs soumet alors la preuve correspondante au module de confiscation du contrat intelligent. Après vérification, si une malversation est confirmée, la mise du fournisseur est confisquée. Comme certains ou tous les fournisseurs sélectionnés ont été sanctionnés, le nœud léger doit récupérer une nouvelle liste de fournisseurs actifs sur le réseau pour s’assurer que l’événement de confiscation a bien eu lieu.
Autres points importants :
-
Tout nœud complet peut rejoindre ou quitter le réseau de fournisseurs de données en envoyant une demande d’« inscription » ou de « retrait » au contrat intelligent. L’inscription nécessite un seuil minimal de mise. Une fois qu’un nœud lance une demande de retrait, son statut passe immédiatement à « départ », et il ne peut plus recevoir de requêtes de nœuds légers, empêchant ainsi toute tentative de malhonnêteté rapide. En outre, le réseau de fournisseurs met à jour périodiquement la liste des fournisseurs actifs. Pendant cette période, les retraits sont bloqués et ne seront effectifs qu’au dernier bloc du cycle. La fréquence de mise à jour est supérieure à la durée maximale de la période de contestation, garantissant ainsi que tous les tests de disponibilité des données soient terminés. En raison de cette dynamique, les nœuds légers doivent rafraîchir régulièrement la liste des fournisseurs actifs. Un cycle plus long facilite la validation (en permettant d’estimer la liste active à partir des inscriptions et retraits du cycle précédent), mais allonge le délai d’attente pour les nœuds souhaitant sortir.
-
Après réception de la signature, le réseau d’inspecteurs vérifie qu’elle provient bien du fournisseur concerné et évalue si les données ont été « finalisées » par le réseau de consensus. Si les données n’apparaissent pas sur la chaîne valide, deux cas sont possibles : soit elles n’ont pas encore été finalisées par la blockchain (selon des règles spécifiques à chaque chaîne, comme la règle de la chaîne la plus longue), soit la transaction figure dans un bloc d’une autre chaîne valide. En cas de falsification, le réseau d’inspecteurs envoie une demande de confiscation au contrat intelligent, incluant la clé publique du fournisseur, sa signature, le numéro de bloc, ainsi qu’une preuve de l’incident pour alerter le nœud léger. Le contrat intelligent compare alors le numéro du bloc finalisé selon la couche de consensus avec celui reçu. En cas d’incohérence, la confiscation est déclenchée. Par ailleurs, si un fournisseur sélectionné est confisqué à cause d’une autre requête, le réseau d’inspecteurs informe immédiatement le nœud léger de cette baisse de fiabilité, qui devra alors choisir d’autres fournisseurs.
Évaluation :
-
Sécurité : Le nœud léger détermine, via le module de mise et le réseau d’inspecteurs, le coût de la malhonnêteté pour les fournisseurs rationnels et irrationnels, améliorant ainsi la fiabilité des données. Toutefois, comme le protocole dépend du réseau de consensus (testé ici sur Ethereum), une attaque contre la couche de consensus entraînerait également une crise de confiance potentielle. On pourrait envisager d’introduire un mécanisme de réputation pour limiter les risques systémiques en cas d’extrême urgence.
-
Sécurité au niveau du nœud complet : Cette solution vise à offrir des hypothèses de sécurité équivalentes à celles du PoS d’Ethereum, c’est-à-dire que tout nœud complet faisant une fausse déclaration encourt un risque de confiscation.
-
Vitalité du réseau : Si peu de fournisseurs rationnels sont présents, le nœud léger subira plusieurs retards. Toutefois, comme chaque fournisseur a un débit non nul, chaque requête sera toujours traitée. Ainsi, tant qu’un seul nœud complet rationnel est actif, le réseau peut continuer à fonctionner. De plus, comme la rémunération des fournisseurs est proportionnelle à leur mise, cela encourage les nœuds complets à sur-miser pour protéger le réseau.
-
Efficacité : Selon les auteurs, les validateurs d’Ethereum seront probablement les principaux participants au rôle de fournisseurs, car ils exécutent déjà des nœuds complets et peuvent ainsi générer des revenus supplémentaires. Pour les petites transactions, un seul fournisseur peut suffire (le nœud léger effectue une seule vérification), tandis que pour les grosses transactions, plusieurs fournisseurs seront nécessaires (le nombre de vérifications augmentant linéairement avec le nombre de fournisseurs).
Solution 2 : priorité à l’efficacité
La solution 2 ajoute un mécanisme d’assurance à la solution 1 pour permettre une confirmation rapide des données. En résumé, après que le nœud léger a défini le montant et la durée de la police d’assurance, une partie ou la totalité de la mise du fournisseur peut être utilisée pour indemniser le nœud léger en cas de dommage causé par des données frauduleuses. Ainsi, une fois la signature des données validée, le nœud léger peut considérer initialement les données comme fiables.
Procédure de demande de données par le nœud léger :
-
Le nœud léger calcule la perte maximale potentielle de la transaction, puis fixe le montant et la durée de la police d’assurance. Le montant misé par le fournisseur dans l’assurance doit dépasser celui de la police, afin de garantir une couverture suffisante.
-
Le nœud léger choisit la période de contestation pour cette transaction. Notons que la durée de la police peut couvrir plusieurs vérifications d’inclusion. Par conséquent, la période totale de contestation choisie ne doit pas excéder la durée de la police, sans quoi certaines transactions risqueraient de ne pas être couvertes.
-
Après avoir défini les paramètres (montant de la police, durée, montant misé dans l’assurance, liste de fournisseurs), le nœud léger envoie une requête au contrat intelligent. Il attend ensuite la finalisation du bloc pour vérifier si l’achat d’assurance a réussi. Un échec peut survenir si un autre nœud léger a sélectionné le même fournisseur auparavant, laissant une mise insuffisante pour répondre à la demande initiale.
-
Le nœud léger envoie sa requête de données, qui inclut non seulement le numéro de bloc et l’état cible (preuve d’inclusion), mais aussi un identifiant d’assurance.
-
Le fournisseur renvoie les données et sa signature. Le nœud léger vérifie la signature, la transmet au réseau d’inspecteurs, et considère alors la transaction comme initialement fiable.
-
L’inspecteur, après réception des données et de la signature, effectue une vérification préliminaire. En cas de malversation, il soumet une preuve au contrat intelligent, déclenchant la confiscation du fournisseur, dont une partie est versée au nœud léger.
Autres points importants :
-
Les mises des fournisseurs dans l’assurance sont isolées entre les différentes requêtes de nœuds légers, évitant ainsi tout risque de double remboursement. Une fois qu’un fournisseur est sélectionné, le contrat intelligent bloque la mise correspondante, empêchant tout autre nœud léger d’utiliser cette portion pendant la durée de la police. Si les transactions sont indépendantes, le montant de la police égale le montant maximal d’une transaction. Sinon, il égale la somme totale des transactions. À mise égale, les nœuds légers tendent à choisir le moins de fournisseurs possible pour maximiser l’efficacité.
-
Un fournisseur peut demander un « retrait » avant la fin de la période d’assurance, mais le paiement ne sera effectué qu’après expiration de la police.
-
Précisément, la durée de la police doit être supérieure au temps de finalisation du bloc + la période totale de contestation + les délais de communication + les délais de calcul/vérification. Plus il y a de fournisseurs sélectionnés, plus la durée de la police doit être prolongée en fonction de la période totale de contestation.
Évaluation :
-
Extensibilité : l’extensibilité de la solution 2 dépend du montant total de jetons que les fournisseurs acceptent de mettre en assurance.
-
Coût de l’assurance : comme un niveau de sécurité plus élevé est lié à une période de contestation plus longue, les fournisseurs doivent maintenir leur mise pendant une durée égale ou supérieure. Ainsi, plus la demande de sécurité est forte, plus la période de mise est longue, et plus le coût pour le nœud léger est élevé. Formellement, le coût de mise du fournisseur est calculé par : revenu du nœud / (utilisation moyenne annuelle × nombre total de blocs par an). Le prix payé par le nœud léger est alors : coût de mise × durée de la police × montant de la police.
Efficacité des solutions
Premièrement, en termes d'efficacité de calcul pour les nœuds légers, les deux solutions affichent une efficacité de vérification de l'ordre de la milliseconde (le nœud léger n'effectue qu'une seule vérification).
Deuxièmement, concernant la latence, dans différents scénarios expérimentaux (voir ci-dessous), la latence reste de l'ordre de la milliseconde. Bien qu'elle augmente linéairement avec le nombre de fournisseurs, elle reste néanmoins très faible. Toutefois, dans la solution 1, le nœud léger doit attendre la fin de la période de contestation, ce qui entraîne une latence d’environ 5 heures. Cette latence pourrait être fortement réduite si le réseau d’inspecteurs était suffisamment fiable et performant.
Troisièmement, en matière de coût pour les nœuds légers, deux facteurs entrent en jeu : les frais de gaz et les primes d’assurance, tous deux croissants avec le montant de la police. Par ailleurs, pour les inspecteurs, les frais de gaz engagés lors de la soumission de preuves sont compensés par les amendes, garantissant ainsi une incitation suffisante à participer.
Directions d’extension
-
Plusieurs types de collatéraux : Actuellement, le collatéral misé par les fournisseurs est de l’ETH, mais les transactions sont exprimées en unité fiduciaire (U). Cela oblige les nœuds légers à évaluer constamment le taux de change de l’ETH pour maintenir un niveau de mise suffisant. Autoriser plusieurs types de jetons comme collatéral offrirait plus de flexibilité aux fournisseurs et éviterait une exposition excessive à un seul actif.
-
Autorisation : À l’instar du minage en association, des petits détenteurs pourraient autoriser leurs ETH à des nœuds complets pour participer au réseau de fournisseurs, les revenus étant distribués selon leurs propres règles, comme dans les LSD.
-
Garantie de production de bloc : Pour éviter d’attendre la période de finalisation (12-13 secondes sur Ethereum), les nœuds légers pourraient recourir à une garantie réduisant ce délai. Le nœud léger ajoute un indicateur à sa requête précisant le type de garantie souhaité (finalisé ou proposé). Le fournisseur répond avec les données et la signature. S’il n’a pas produit de bloc « proposé » dans le cas d’une garantie « proposé », il est sanctionné.
Note : Un bloc « proposé » sera ultérieurement finalisé ou deviendra un bloc oncle. -
Coûts et frais : Les inspecteurs doivent miser une quantité de jetons (supérieure aux frais de gaz) pour soumettre une preuve au contrat intelligent. Ces preuves pourraient être rendues moins coûteuses grâce aux zkp. Dans le mécanisme d’assurance, la prime versée par le nœud léger va au fournisseur, tandis que le réseau d’inspecteurs perçoit une part des amendes des fournisseurs malhonnêtes.
-
Disponibilité des données : Les fournisseurs de données sont essentiellement des nœuds complets pouvant non seulement participer à la couche de consensus, mais aussi valider la disponibilité des données. Deux modèles existent : Pull model et Push model. Le premier consiste pour le nœud léger à extraire aléatoirement des données auprès des nœuds complets. Le second implique que le producteur de blocs distribue des fragments de blocs aux fournisseurs. Pour les fournisseurs utilisant le Pull model, ils doivent répondre aux requêtes d’échantillonnage. Le nœud léger transmet les données à un nœud de confiance ou à un validateur, qui tente de reconstruire le bloc. En cas d’échec, le fournisseur est sanctionné. Le protocole de nœud léger présenté ici, enrichi du mécanisme d’assurance, ouvre de nouvelles pistes de recherche sur la disponibilité des données.
Conclusion et évaluation
La solution proposée pour les nœuds légers offre une « sécurité programmable » adaptée à divers niveaux de besoin. La solution 1 privilégie la sécurité au détriment de la latence, tandis que la solution 2 introduit un mécanisme d’assurance pour offrir un « accord instantané » aux nœuds légers. Ces solutions conviennent aux cas d’usage nécessitant une confirmation de la finalité des transactions, tels que les échanges atomiques ou les applications inter-chaînes.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@eureka_partners
