Transmettre le titre original "TeleportDAO: jeu de sécurité et d'efficacité de la vérification des données - Dernières pratiques de conception de nœuds légers"
Remarque : Eigen Labs est le développeur derrière les protocoles de réenjeu EigenLayer et EigenDA. Eigen Labs a actuellement levé plus de 150 millions de dollars américains auprès d'institutions de capital-risque bien connues telles que a16z, Polychain et Blockchain Capital.
TeleportDAO est situé à Vancouver, Canada. Il s'agit d'un projet d'infrastructure de communication inter-chaînes axé sur les chaînes publiques Bitcoin et EVM. Le protocole a réussi à lever 9 millions de dollars lors d'une série de ventes publiques et de financement via Coinlist. Cette levée de fonds a reçu la participation de plusieurs investisseurs, dont Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across et bitSmiley.
Les nœuds complets jouent un rôle vital dans le maintien de l'intégrité de la blockchain PoS. Ils stockent toutes les informations de transaction des blocs, vérifient les signatures de consensus, répliquent une copie complète de l'historique des transactions et effectuent des mises à jour d'état. Ces processus nécessitent beaucoup de ressources informatiques et de matériel complexe. Par exemple, l'exécution d'un nœud Ethereum complet nécessite au moins 2 To de stockage SSD. En revanche, les nœuds légers réduisent les exigences en ressources informatiques et ne stockent que les en-têtes de bloc, ils sont donc uniquement adaptés aux scénarios où des transactions / statuts spécifiques sont vérifiés, comme les portefeuilles mobiles et les ponts inter-chaînes. De plus, les nœuds légers dépendent des nœuds complets pour fournir des informations sur les blocs lors de la vérification des transactions, mais la part de marché actuelle des fournisseurs de services de nœuds est relativement concentrée, donc la sécurité, l'indépendance et l'immédiateté ne peuvent pas être entièrement garanties. Par conséquent, cet article explore le compromis entre le coût d'acquisition des données et la latence pour les nœuds légers afin d'atteindre une sécurité optimale.
En revanche, les blockchains PoS gagnent en sécurité grâce à des mécanismes de slashing. Le système repose sur le fait que les participants au consensus sont rationnels et n’attaquent pas le réseau si le coût d’une attaque dépasse tout profit potentiel. Pour réduire les coûts de vérification, le protocole actuel du nœud léger d’Ethereum s’appuie sur un comité de synchronisation composé de 512 validateurs Ethereum sélectionnés au hasard, chacun d’entre eux misant 32 Ethereum, mais le processus de signature ne sera pas sanctionné. Cette conception non slashable présente une faille de sécurité majeure, et des signatures malhonnêtes dans le comité de synchronisation peuvent induire en erreur les nœuds légers en acceptant des données invalides sans être punis. Même avec l’introduction de mécanismes de slashing, la mise totale du Sync Committee est encore faible par rapport à l’énorme pool de validateurs Ethereum (en mars 2024, le nombre de validateurs Ethereum a dépassé 1 million). Par conséquent, cette approche ne peut pas fournir aux nœuds légers une sécurité équivalente à celle de l’ensemble de validateurs Ethereum. Ce modèle représente une variante spéciale du calcul multipartite dans un cadre rationnel, mais ne fournit pas de garanties économiques ni ne répond aux menaces posées par des fournisseurs de données malveillants et irrationnels.
Pour relever les défis de sécurité et d'efficacité du processus d'amorçage de la PoS, PoPoS introduit un jeu de segmentation pour défier efficacement l'arbre de Merkle adversaire du timing de la PoS. Bien qu'ils réalisent une empreinte minimale et évitent d'exiger que les clients soient toujours en ligne et mis en jeu, le problème permettant aux clients de se déconnecter sans encourir des coûts importants pour rejoindre le réseau reste non résolu.
Une autre approche de recherche se concentre sur l'utilisation de preuves de connaissance nulle pour créer des preuves concises. Par exemple, Mina et Plumo facilitent efficacement la vérification légère du consensus en utilisant une composition SNARK récursive et des preuves de transition d'état basées sur SNARK. Cependant, ces approches imposent un fardeau computationnel considérable aux producteurs de blocs pour générer des preuves, et elles ne traitent pas la question de la compensation des nœuds légers pour les pertes potentielles. Dans le contexte d'autres protocoles de PoS, tels que le protocole Tendermint utilisé dans Cosmos, le rôle des nœuds légers est exploré dans leur protocole de communication inter-chaînes (IBC). Cependant, ces implémentations sont spécifiques à leurs écosystèmes respectifs et ne sont pas directement applicables à Ethereum ou à divers autres blockchains PoS.
Processus spécifique de demande de données par un nœud léger :
Le nœud léger obtient la liste la plus récente des fournisseurs de données du réseau actuel et détermine une période de défi. Il convient de noter que cette période de défi est indépendante parmi les différents nœuds légers, mais la limite supérieure de la période de défi s'applique à tous les nœuds légers. La période de défi est le temps le plus long pour le réseau du procureur de vérifier la crédibilité des données, plus le temps est long, plus le retard par transaction est long.- Après avoir obtenu la liste, le nœud léger sélectionnera un groupe de fournisseurs de données et veillera à ce que leurs fonds mis en jeu respectifs soient supérieurs à la valeur de la transaction actuelle. Théoriquement, plus les fonds mis en jeu sont élevés, plus le coût du comportement répréhensible du fournisseur de données est élevé, et plus faible est le coût de confiance du nœud léger.- Le nœud léger envoie la demande de données correspondante à ce groupe de fournisseurs de données, qui comprend le numéro de bloc correspondant et l'état cible (la preuve d'inclusion de cette transaction).- Le fournisseur de données envoie le hash de bloc correspondant et la preuve d'inclusion de la transaction, et attache une signature.- Après que le nœud léger reçoit les matériaux mentionnés ci-dessus, il les transmet au réseau de procureurs connectés actuels. Si aucun avertissement de crédibilité des données n'est reçu après la fin de la période de contestation, le nœud léger vérifiera cette signature et passera le test de crédibilité des données s'il n'y a pas d'erreur.
Mais si un avertissement est reçu du réseau du procureur, le nœud léger doit abandonner la signature reçue précédemment. Le réseau du procureur soumettra la preuve pertinente au module de pénalité du contrat intelligent. Si le contrat intelligent constate que l'infraction s'est effectivement produite après avoir vérifié les données, l'enjeu du fournisseur de données correspondant sera pénalisé. Comme une partie/de l'ensemble des fournisseurs de données sélectionnés ont été pénalisés, le nœud léger doit obtenir à nouveau une nouvelle liste de fournisseurs de données du réseau actuel pour confirmer que l'événement de réduction a effectivement eu lieu.
Autres points :
Tout nœud complet peut rejoindre ou quitter le réseau de fournisseurs de données en initiant des demandes de «enregistrement» et de «retrait» au contrat intelligent. Il existe un seuil de participation minimum pour s'inscrire au réseau de fournisseurs de données. Une fois qu'un nœud complet choisit d'initier un retrait, son statut dans le réseau passera immédiatement à «en train de partir», et il ne pourra plus recevoir de demandes de nœuds légers, afin de prévenir tout comportement malveillant potentiel d'entrée et de sortie rapide. De plus, le réseau de fournisseurs de données met à jour la liste des fournisseurs de données actuellement actifs par cycles, au cours desquels les fournisseurs de données ne peuvent pas recevoir de fonds de retrait. Une demande de retrait prendra effet dans le dernier bloc du cycle de mise à jour actuel, et la fréquence de mise à jour sera supérieure à la limite de la période de défi pour garantir que tous les tests de disponibilité des données des nœuds légers ont été effectués. En raison de l'activité du réseau de fournisseurs de données, les nœuds légers doivent réobtenir la liste des fournisseurs de données actuellement actifs à chaque mise à jour du réseau. Si le cycle de mise à jour est prolongé, les nœuds légers peuvent profiter d'un processus de vérification plus rationalisé (en estimant la liste active actuelle à travers les demandes de «enregistrement» et de «retrait» du cycle précédent), mais les nœuds souhaitant partir feront face à un temps d'attente plus long.- À la réception de la signature des données, le réseau du procureur vérifie si la signature appartient au fournisseur de données et évalue si les données ont été «enfin confirmées» dans le réseau de consensus. Si les données n'apparaissent pas sur une chaîne raisonnable, il y a deux possibilités. Premièrement, les données n'ont pas encore été finalement confirmées par la blockchain actuelle, différentes chaînes ayant des règles de finalité différentes, telles que le principe de la chaîne la plus longue. Deuxièmement, la transaction est dans un bloc d'une autre chaîne raisonnable. Si les données ci-dessus sont jugées falsifiées, le réseau du procureur enverra une demande de réduction au contrat intelligent, qui inclut la clé publique du fournisseur de données, la signature du fournisseur de données, le numéro de bloc, et en même temps enverra une preuve de l'événement de réduction pour rappeler le nœud léger. À la réception de ces données, le contrat intelligent mesure si le numéro de bloc actuel finalement confirmé est cohérent avec les données reçues selon le principe de finalité de la couche de consensus. S'ils sont incohérents, alors l'événement de réduction est déclenché. De plus, si un fournisseur de données choisi par le nœud léger est réduit en raison d'un autre groupe de demandes de données, le réseau du procureur enverra rapidement l'événement de réduction pour rappeler le nœud léger que la crédibilité des données du fournisseur de données est faible, et le nœud léger obtiendra alors à nouveau la liste et sélectionnera d'autres fournisseurs.Évaluer :
Sécurité : Le nœud léger détermine le coût du comportement malveillant pour les fournisseurs de données rationnels et irrationnels grâce au module de mise en jeu et au réseau des procureurs, améliorant ainsi la crédibilité des données. Cependant, étant donné que l'ensemble du protocole est basé sur le réseau de consensus (cet article teste sur Ethereum), une fois que la couche de consensus est attaquée, le protocole peut également faire face à une crise de confiance potentielle. Par conséquent, un mécanisme de réputation peut être introduit pour garantir les risques systémiques dans des situations extrêmes.- Sécurité au niveau du nœud complet : Ce schéma vise à fournir une sécurité équivalente à l'hypothèse de PoS d'Ethereum, c'est-à-dire que les nœuds complets doivent supporter le risque de réduction pour avoir fait de fausses déclarations.- Activité du réseau : Si le réseau actuel ne compte que quelques fournisseurs de données rationnels, le nœud léger sera confronté à plusieurs tours de retard, mais étant donné que le débit de chaque fournisseur de données n'est pas nul, chaque demande sera toujours complétée. Par conséquent, tant que le réseau dispose d'un nœud complet rationnel, il peut garantir la poursuite du fonctionnement du réseau. En même temps, étant donné que le revenu des fournisseurs de données est lié au montant du jalonnement, cela encourage également les nœuds complets à protéger le réseau en misant plus que nécessaire.- Efficacité : L'équipe d'auteurs de l'article prédit que les validateurs Ethereum sont les principaux utilisateurs participant en tant que fournisseurs de données, car les validateurs exécutent déjà des nœuds complets et peuvent obtenir un revenu supplémentaire grâce à ce protocole. Les petites transactions peuvent obtenir des données crédibles grâce à un seul fournisseur de données (le nœud léger n'a besoin de vérifier qu'une seule fois), tandis que les grandes transactions peuvent nécessiter plusieurs fournisseurs de données pour obtenir des données crédibles (le nombre de vérifications augmente de manière linéaire avec le nombre de fournisseurs).## Option 2 : Efficacité d'abordLa solution 2 réalise une confirmation rapide des données en proposant un mécanisme d'assurance basé sur la solution 1. En termes simples, après que le nœud léger a déterminé l'assurance selon le montant et la durée de la police, une partie/la totalité de l'engagement du fournisseur de données peut être remboursée pour les pertes ultérieures du nœud léger dues à la malveillance des données. Par conséquent, après que le nœud léger a reçu et vérifié la signature des données fournie par le fournisseur, il peut déterminer la crédibilité initiale des données.
Processus spécifique de demande de données par un nœud léger :

Autres points :
Les jetons d'assurance mis en jeu par le fournisseur de données sont indépendants les uns des autres entre les différentes demandes de nœuds légers pour éviter le risque de remboursements d'assurance multiples. Après que le nœud léger a sélectionné le fournisseur de données, le contrat intelligent verrouillera les jetons correspondants engagés pour l'assurance, et les autres nœuds légers ne pourront pas allouer cette partie de l'engagement avant la fin de la période d'assurance. Si les transactions sont indépendantes, le montant de l'assurance est le même que le montant de transaction maximum. Sinon, le montant de l'assurance est le même que le montant total de la transaction. Sous le même montant d'engagement, les nœuds légers choisissent généralement aussi peu de fournisseurs de données que possible pour garantir l'efficacité de la vérification.- Bien que le fournisseur de données puisse initier une demande de "retrait" avant la fin de la période d'assurance, le montant du retrait ne sera reçu qu'après la fin de la période d'assurance.- Strictement parlant, la période de la police d'assurance devrait être supérieure au temps de confirmation du dernier bloc + période totale de défi + délai de communication + délai de calcul/vérification. Plus vous choisissez de fournisseurs de données, plus la période de la police d'assurance sera basée sur la période totale de défi.Évaluer :
La scalabilité: La scalabilité de l'option 2 est déterminée par le montant total de jetons que les fournisseurs de données sont prêts à miser pour l'assurance.- Coût de la politique : Étant donné que des niveaux de sécurité plus élevés sont liés au cycle de défi, cela signifie que le fournisseur de données doit miser pour une période supérieure ou égale au cycle de défi. Par conséquent, plus les exigences en matière de sécurité sont élevées, plus long est le cycle de mise, et plus élevés sont les frais payés par le nœud léger. Selon la formule, le coût de la mise du fournisseur de données est calculé en fonction des revenus du nœud du fournisseur de données / (utilisation moyenne de la mise tout au long de l'année multipliée par le nombre total de blocs par an). Le prix que le nœud léger doit payer est le coût de la mise multiplié par la période de politique et la taille de la politique.

Tout d'abord, en termes d'efficacité de calcul des nœuds légers, les deux solutions de nœuds légers démontrent une efficacité de vérification au niveau de la milliseconde (les nœuds légers n'ont besoin de vérifier les données qu'une seule fois).
Deuxièmement, en termes de latence du nœud léger, dans différents scénarios de configuration expérimentale (voir la figure ci-dessous), la latence est au niveau de la milliseconde. Il est à noter que la latence augmente linéairement avec le nombre de fournisseurs de données, mais la latence est toujours au niveau de la milliseconde. De plus, dans la Solution 1, étant donné que le nœud léger doit attendre les résultats de la période de défi, la latence est de 5 heures. Si le réseau de l'inspecteur est fiable et assez efficace, cette latence de 5 heures peut également être considérablement réduite.

Troisièmement, en termes de coûts des nœuds légers, en réalité, il y a deux coûts pour les nœuds légers : les frais de gaz et la prime d'assurance, tous deux augmenteront à mesure que le montant de la police d'assurance augmente. De plus, pour les inspecteurs, le gaz impliqué dans la soumission des données sera remboursé avec le montant de l'amende pour garantir des incitations à la participation suffisantes.
Remarque : Les blocs proposés seront éventuellement finalisés ou deviendront des blocs oncles.- Coûts et frais : Pour le réseau du procureur, ils doivent bloquer un certain montant de jetons (supérieur au gaz) pour soumettre des preuves au contrat intelligent. De plus, le coût de cette partie de la preuve peut être réduit grâce à la méthode zkp. De plus, dans le cadre du mécanisme d'assurance, les primes soumises par les nœuds légers seront données aux fournisseurs de données, tandis que le réseau du procureur extraira une partie des revenus des pénalités des fournisseurs malveillants.- Disponibilité des données : Les fournisseurs de données sont essentiellement des nœuds complets. En plus de participer au réseau de la couche de consensus, ils peuvent également vérifier la disponibilité des données. Il existe deux types de schémas pour vérifier la disponibilité : le modèle Pull et le modèle Push. Le premier fait référence au nœud léger extrayant de manière aléatoire des données obtenues du nœud complet. Le second fait référence au producteur de blocs distribuant différents blocs aux fournisseurs de données. Pour les fournisseurs de données adoptant le modèle Pull, ils sont responsables de répondre aux demandes d'échantillonnage. Après avoir reçu les données, le nœud léger les transmet au nœud/validateur de confiance, et ils tentent de restaurer le bloc. S'ils échouent, le fournisseur de données sera sanctionné. Le protocole du nœud léger dans cet article propose un mécanisme d'assurance sur cette base, offrant une nouvelle direction d'exploration pour la recherche sur la disponibilité des données.## Conclusion et évaluationLa solution de nœud léger proposée dans cet article offre une "sécurité programmable" pour répondre aux exigences de sécurité dans différentes situations. L'option 1 privilégie une latence plus élevée pour une sécurité accrue, tandis que l'option 2 propose des services de "confirmation instantanée" pour les nœuds légers en introduisant un mécanisme d'assurance. Ces solutions peuvent être utilisées dans des scénarios où la finalité des transactions doit être confirmée, tels que les transactions atomiques et inter-chaînes.





