tl;dr

Teleportdao et Eigen Labs ont récemment publié un article portant sur les défis de sécurité et d’efficacité auxquels sont confrontés les nœuds légers dans les blockchains de preuve d’enjeu (POS) lors de l’accès et de la vérification des données on-chain. L’article propose une nouvelle solution pour assurer la sécurité et l’efficacité des nœuds légers dans les blockchains de point de vente grâce à des incitations économiques, des mécanismes de pré-sécurité assurés, une « sécurité programmable » personnalisable et une rentabilité. Cette approche novatrice mérite d’être étudiée plus avant. Remarque : Eigen Labs, le développeur à l’origine du protocole de jalonnement EigenLayer et Eigenda, a levé plus de 150 millions de dollars auprès de sociétés de capital-risque renommées telles que A16Z, PolyChain et Blockchain Capital. TeleportDAO, basée à Vancouver, au Canada, se concentre sur l’infrastructure de communication inter-chaînes entre Bitcoin et les chaînes publiques EVM. Le protocole a réussi à lever 9 millions de dollars par le biais d’une vente publique sur Coinlist, avec des investisseurs tels que Appworks, OIG Capital, DeFinanceX, Oak Grove Ventures, Candaq Ventures, Ton, Across et Bitsmiley.

problèmes de conception du light node

actuellement, dans les blockchains pos (preuve d'enjeu), les validateurs assurent la sécurité du réseau en bloquant une certaine quantité d'enjeu (comme 32 eth dans ethereum) pour participer au réseau de consensus. cela signifie que la sécurité des blockchains pos est économiquement garantie : plus l'enjeu total est élevé, plus le coût ou la perte potentielle est élevé pour quiconque tente d'attaquer le réseau. ce mécanisme de confiscation repose sur une fonctionnalité connue sous le nom de "sécurité de responsabilité", qui permet la confiscation de l'enjeu d'un validateur s'ils signent des états conflictuels. les nœuds complets sont essentiels pour maintenir l'intégrité des blockchains pos. ils stockent toutes les données de transaction, vérifient les signatures de consensus, maintiennent un historique complet des transactions et exécutent des mises à jour de l'état. ces tâches demandent des ressources informatiques importantes et du matériel avancé ; par exemple, exécuter un nœud ethereum complet nécessite au moins 2 to de stockage ssd. en revanche, les nœuds légers réduisent les demandes de ressources informatiques en ne stockant que les en-têtes de bloc, ce qui les rend adaptés à la vérification de transactions/états spécifiques dans des applications telles que les portefeuilles mobiles et les ponts inter-chaînes. cependant, les nœuds légers dépendent des nœuds complets pour obtenir des informations sur les blocs lors de la vérification des transactions. actuellement, la part de marché des fournisseurs de services de nœuds est assez concentrée, ce qui compromet la sécurité, l'indépendance et l'immédiateté. cet article explore des solutions pour équilibrer les coûts d'acquisition de données et la latence afin d'atteindre une sécurité optimale pour les nœuds légers.

solutions de conception de nœuds légers existants

Bitcoin a introduit la vérification de paiement simple (SPV) en tant que protocole pour les nœuds légers. SPV permet aux nœuds légers de vérifier si une transaction est incluse dans un bloc spécifique en utilisant une preuve de Merkle et des en-têtes de bloc. Cela signifie que les nœuds légers n'ont besoin que de télécharger les en-têtes de bloc pour vérifier la finalité de la transaction en vérifiant la profondeur du bloc. Par conséquent, le coût de calcul pour la vérification du consensus des nœuds légers dans Bitcoin est relativement faible. Cependant, dans les blockchains PoS comme Ethereum, les vérifications de consensus sont intrinsèquement plus complexes. Elles impliquent de maintenir l'ensemble complet des validateurs, de suivre les changements de leur enjeu et d'effectuer de nombreuses vérifications de signature pour le réseau de consensus. De plus, la sécurité des nœuds légers PoW repose sur l'hypothèse que la plupart des nœuds complets sont honnêtes. Pour surmonter les limites de SPV, Flyclient et les preuves non interactives de preuve de travail (NIPoPoW) offrent des preuves de coût sous-linéaire aux clients. Cependant, ces méthodes sont moins efficaces pour les modèles de consensus PoS.

dans les blockchains de type PoS, la sécurité est assurée par un mécanisme de confiscation. Ce système suppose que les participants au consensus sont rationnels, c'est-à-dire qu'ils n'attaqueront pas le réseau si le coût dépasse les éventuels bénéfices. Pour réduire les coûts de vérification, le protocole actuel des nœuds légers d'Ethereum utilise un comité de synchronisation composé de 512 validateurs sélectionnés de manière aléatoire, chacun misant 32 ETH, mais le processus de signature n'est pas sujet à confiscation. Cette conception sans confiscation présente de graves failles de sécurité ; des signatures malhonnêtes dans le comité de synchronisation peuvent induire les nœuds légers en erreur en acceptant des données invalides sans aucune punition. Même avec un mécanisme de confiscation, la mise totale du comité de synchronisation est faible par rapport au vaste groupe de validateurs Ethereum (plus d'un million en mars 2024). Par conséquent, cette méthode ne garantit pas la sécurité des nœuds légers équivalente à celle de l'ensemble des validateurs Ethereum. Ce modèle est une variante spéciale de la computation multipartie dans des paramètres rationnels, mais il ne comporte pas de garanties économiques et ne parvient pas à résoudre les menaces des fournisseurs de données malveillants et irrationnels.

Pour relever les défis de sécurité et d'efficacité du processus de démarrage de la pos, popos introduit un jeu segmenté pour défier efficacement l'arbre de Merkle adversaire de la synchronisation pos. tout en répondant aux exigences d'espace minimal et en évitant le besoin pour les clients d'être toujours en ligne et de maintenir des enjeux, la question de permettre aux clients de se déconnecter et de rejoindre le réseau sans encourir de coûts importants reste non résolue.

une autre approche de recherche utilise des preuves de connaissance nulle pour créer des preuves concises. par exemple, mina et plumo facilitent la vérification légère du consensus en utilisant des combinaisons récursives de snark et des preuves de transition d'état basées sur snark. cependant, ces méthodes imposent des charges computationnelles significatives aux producteurs de blocs pour générer des preuves et ne compensent pas les nœuds légers pour les pertes potentielles. dans d'autres protocoles de preuve d'enjeu (comme le protocole tendermint dans cosmos), le rôle des nœuds légers a été exploré dans leur protocole de communication inter-chaînes (ibc). mais ces implémentations sont adaptées à leurs écosystèmes spécifiques et ne s'appliquent pas directement à ethereum ou à d'autres blockchains de preuve d'enjeu.

conception d'un nouveau plan de light node

En général, le nouveau plan intègre un module de sécurité économique pour atteindre une “sécurité programmable”, permettant aux nœuds légers de choisir différents designs en fonction de leurs besoins spécifiques en matière de sécurité. Les hypothèses de sécurité suivent le principe 1/n + 1/m, ce qui signifie que tant qu'il y a au moins un nœud honnête et efficace dans le réseau de nœuds complets et dans le réseau d'inspecteurs, le réseau peut fonctionner correctement.

modules/roles impliqués

• blockchain : le protocole est construit sur une blockchain programmable avec des règles définies pour la finalité des blocs. Par exemple, sur la blockchain Ethereum, un bloc est considéré comme final après au moins deux époques ultérieures, prenant généralement environ 13 minutes.
• contrat intelligent de confiscation : le protocole comprend un contrat de confiscation sur chaîne qui suit les abstractions standard des contrats intelligents. il peut accéder au hachage de bloc du bloc précédent dans la blockchain. toutes les parties peuvent envoyer des informations à ce contrat.
• fournisseurs de données: les fournisseurs de données exécutent des nœuds complets et suivent l'état le plus récent de la blockchain. ils s'engagent des actifs et proposent des services pour vérifier la validité des états demandés par les nœuds légers. ils signent toutes les données envoyées aux nœuds légers avec des clés correspondant à leurs clés publiques, garantissant la source et l'intégrité des données.
• inspecteurs : les inspecteurs sont des nœuds complets connectés à des nœuds légers qui aident à vérifier les données. n'importe qui peut devenir un inspecteur et gagner des récompenses en surveillant et en pénalisant les parties qui se comportent mal. pour simplifier, le plan suivant suppose que chaque nœud léger est connecté à au moins un inspecteur honnête.
• light nodes: les light nodes visent à vérifier si un état/une transaction spécifique est inclus(e) dans la blockchain à moindre coût. Ils se connectent à un groupe de fournisseurs de données et d'inspecteurs pendant le processus de vérification.
• réseau: les fournisseurs de données forment un réseau pair à pair (p2p) et utilisent le protocole de rumeur pour diffuser des données. Les nœuds légers se connectent à plusieurs fournisseurs de données pour envoyer des demandes et recevoir des réponses.

plan 1: sécurité d'abord

Le plan 1 vise à garantir la fiabilité des données grâce à une période de défi et à un réseau d'inspecteurs. En termes simples, après qu'un nœud léger reçoit des données signées par les fournisseurs, il transmet ces données au réseau d'inspecteurs pour examen. Si des données frauduleuses sont détectées dans un délai spécifié, l'inspecteur informera le nœud léger que les données ne sont pas fiables, et le module de confiscation du contrat intelligent confisquera les jetons mis en jeu par le fournisseur de données. Sinon, le nœud léger peut faire confiance à la fiabilité des données. Le processus spécifique pour les nœuds légers de demander des données est le suivant:

1. Les nœuds légers obtiennent la dernière liste des fournisseurs de données du réseau actuel et le nœud léger récupère la dernière liste des fournisseurs de données du réseau actuel et définit une période de défi. Notez que les périodes de défi sont indépendantes pour chaque nœud léger, mais il existe une période de défi maximale qui s'applique à tous les nœuds légers. La période de défi est le temps maximum que le réseau de contrôle a pour vérifier la fiabilité des données, donc plus la période est longue, plus le délai pour une transaction unique est long.
2. après avoir obtenu la liste, le nœud léger sélectionne un groupe de fournisseurs de données et s'assure que leurs fonds mis en jeu dépassent la valeur de la transaction actuelle. En théorie, plus les fonds mis en jeu sont élevés, plus le coût pour un fournisseur de données d'agir de manière malveillante est élevé, et plus faible est le coût de confiance pour le nœud léger.
3. le nœud léger envoie une demande de données à ce groupe de fournisseurs de données, y compris le numéro de bloc et l'état cible (la preuve d'inclusion de la transaction).
4. les fournisseurs de données répondent avec le hachage du bloc correspondant et la preuve d'inclusion de la transaction, ainsi que leurs signatures.
5. upon receiving this information, the light node forwards it to the connected inspector network. if no data reliability warning is received by the end of the challenge period, the light node verifies the signatures and, if correct, confirms the data’s reliability.

1. cependant, si un avertissement est reçu du réseau de l'inspecteur, le nœud léger doit abandonner les signatures précédemment reçues. le réseau de l'inspecteur soumettra des preuves au module de forfeiture du contrat intelligent. si le contrat intelligent vérifie qu'une activité malveillante s'est produite, l'enjeu du fournisseur de données sera confisqué. puisque certains ou tous les fournisseurs de données sélectionnés ont été pénalisés, le nœud léger doit obtenir une nouvelle liste de fournisseurs de données du réseau actuel pour confirmer l'événement de forfeiture.

autres points :

• N’importe quel nœud complet peut rejoindre ou quitter le réseau du fournisseur de données en soumettant des demandes d'« enregistrement » et de « retrait » au contrat intelligent. Il existe une exigence minimale de jalonnement pour rejoindre le réseau du fournisseur de données. Une fois qu’un nœud complet a initié un retrait, son état passe à « gauche » et il ne reçoit plus de demandes de nœuds légers pour empêcher les comportements malveillants d’entrée et de sortie rapides. De plus, le réseau des fournisseurs de données met régulièrement à jour la liste des fournisseurs actifs. Pendant cette période, les fournisseurs de données ne peuvent pas retirer leurs fonds, et les demandes de retrait prendront effet à la fin de la période de mise à jour en cours. La fréquence de mise à jour est supérieure à la période de défi maximale pour garantir l’achèvement de tous les tests de disponibilité des données du nœud léger. En raison de l’activité du réseau, les nœuds légers doivent obtenir une nouvelle liste de fournisseurs actifs à chaque cycle de mise à jour. Si le cycle de mise à jour est prolongé, les nœuds légers peuvent bénéficier d’un processus de vérification plus simple (en estimant la liste active en fonction des demandes d’enregistrement et de retrait précédentes), mais les nœuds souhaitant quitter l’entreprise devront attendre plus longtemps.
• Lorsque le réseau Inspector reçoit des signatures de données, il vérifie si les signatures appartiennent aux fournisseurs de données et si les données ont été « définitivement confirmées » dans le réseau de consensus. Si les données n’apparaissent pas sur la chaîne valide, deux possibilités s’offrent à vous. Tout d’abord, les données n’ont pas encore été définitivement confirmées par la blockchain, car les différentes chaînes ont des règles de finalité différentes, comme le principe de la chaîne la plus longue. Deuxièmement, la transaction se trouve dans un bloc d’une autre chaîne valide. Si les données sont frauduleuses, le réseau d’inspecteurs enverra une demande de confiscation au contrat intelligent, y compris la clé publique, la signature et le numéro de blocage du fournisseur de données, ainsi qu’une preuve de l’événement de confiscation pour alerter le nœud Light. Le contrat intelligent utilisera les principes de finalité de la couche de consensus pour comparer le numéro de bloc actuellement confirmé avec les données reçues. S’ils ne correspondent pas, l’événement de confiscation est déclenché. De plus, si un fournisseur de données est pénalisé pour un autre ensemble de demandes de données après avoir été choisi par le nœud léger, le réseau d’inspecteurs informera rapidement le nœud léger de la fiabilité inférieure du fournisseur de données, invitant le nœud léger à obtenir une nouvelle liste et à sélectionner d’autres fournisseurs.

évaluer:

• sécurité: le nœud léger utilise le module d'enjeu et le réseau de l'inspecteur pour déterminer le coût des actions malveillantes pour les fournisseurs de données, qu'ils soient rationnels ou irrationnels, améliorant ainsi la fiabilité des données. Cependant, puisque l'ensemble du protocole est basé sur le réseau de consensus (testé sur Ethereum dans cet article), si la couche de consensus est attaquée, ce protocole pourrait également faire face à une crise de confiance potentielle. Par conséquent, un mécanisme de réputation peut être introduit pour garantir la sécurité du système dans des cas extrêmes.
• sécurité de niveau nœud complet : cette solution vise à offrir des hypothèses de sécurité équivalentes à la preuve d'enjeu d'ethereum, ce qui signifie que les nœuds complets doivent assumer le risque de perte s'ils font de fausses déclarations.
• activité du réseau : si le réseau actuel n'a que quelques fournisseurs de données rationnels, le nœud léger subira plusieurs tours de retard. cependant, étant donné que le débit de chaque fournisseur de données n'est pas nul, chaque demande peut encore être complétée. par conséquent, tant qu'il y a un nœud complet rationnel dans le réseau, il peut continuer à fonctionner. de plus, comme le revenu des fournisseurs de données est lié à leur montant mis en jeu, cela encourage les nœuds complets à sur-miser pour protéger le réseau.
• efficacité : les auteurs estiment que les validateurs Ethereum seront les principaux utilisateurs participant en tant que fournisseurs de données, car ils exécutent déjà des nœuds complets et peuvent gagner un revenu supplémentaire grâce à ce protocole. Les petites transactions peuvent obtenir des données fiables auprès d'un seul fournisseur de données (ne nécessitant qu'une seule vérification pour le nœud léger), tandis que les grandes transactions peuvent nécessiter plusieurs fournisseurs de données pour obtenir des données fiables (le nombre de vérifications augmente linéairement avec le nombre de fournisseurs).

plan 2: prioriser l'efficacité

Le plan 2 s'appuie sur le plan un en introduisant un mécanisme d'assurance pour la confirmation rapide des données. En termes simples, après que le nœud léger détermine l'assurance en fonction du montant et de la durée de la police, une partie ou l'ensemble de l'enjeu du fournisseur de données peut être utilisé pour compenser les pertes ultérieures subies par le nœud léger en raison de données malveillantes. Cela permet au nœud léger d'établir la crédibilité initiale des données dès qu'il reçoit et vérifie la signature des données du fournisseur. Le processus spécifique pour que le nœud léger demande des données est le suivant :

1. Le nœud léger calcule la perte maximale potentielle de la transaction actuelle, puis définit le montant et la durée de la police. Les fonds mis en jeu par le fournisseur de données dans l'assurance doivent dépasser le montant de la police pour garantir une compensation suffisante.
2. le nœud léger détermine la période de défi pour la transaction. il est important de noter que la période de politique peut couvrir la vérification de l'inclusion de plusieurs transactions, donc la période de défi totale choisie par le nœud léger ne peut pas dépasser la période de politique; sinon, certaines transactions peuvent ne pas être garanties.
3. après avoir sélectionné les paramètres (montant de la police, période de la police, montant des fonds mis en jeu par le fournisseur de données dans l'assurance et la liste des intentions du fournisseur de données), le nœud léger envoie une demande au contrat intelligent. Après avoir attendu le temps de confirmation final du bloc, il vérifie si l'achat d'assurance a réussi. S'il échoue, cela peut être dû au fait que d'autres nœuds légers ont également choisi le même fournisseur de données et se sont installés en premier, ce qui a entraîné une insuffisance des enjeux restants pour répondre à la demande initiale.
4. le nœud léger envoie une demande de données, qui comprend le numéro de bloc, l'état cible (la preuve d'inclusion de la transaction) et le numéro d'assurance.
5. le fournisseur de données envoie les données et la signature, que le nœud léger vérifie et transmet au réseau de l'inspecteur. la transaction est alors confirmée préliminairement.
6. Après réception des données et de la signature, l'inspecteur vérifie initialement la crédibilité des données. Si un comportement malveillant est détecté, une preuve est soumise au contrat intelligent et le fournisseur de données correspondant est pénalisé, la pénalité étant répartie sur le nœud léger.

autres points :

• les jetons misés par les fournisseurs de données dans l'assurance sont indépendants pour différentes demandes de nœuds légers afin de prévenir le risque de remboursements d'assurance multiples. Une fois qu'un nœud léger sélectionne un fournisseur de données, le contrat intelligent verrouille les jetons misés correspondants dans l'assurance, et les autres nœuds légers ne peuvent pas allouer cette mise jusqu'à la fin de la période de la police. Si les transactions sont indépendantes, le montant de la police équivaut au montant maximum de la transaction. Si les transactions ne sont pas indépendantes, le montant de la police équivaut au montant total de la transaction. Étant donné le même montant misé, les nœuds légers choisiront généralement le moins de fournisseurs de données possible pour assurer l'efficacité de la vérification.
• Les fournisseurs de données peuvent initier une demande de "retrait" avant la fin de la période d'assurance, mais le montant du retrait ne sera reçu qu'après la fin de la période de la police.
• À proprement parler, la période de la politique devrait être plus longue que le temps de confirmation final du bloc + la période de défi totale + le délai de communication + le délai de calcul/vérification. Plus les fournisseurs de données sont sélectionnés, plus la période de la politique requise est longue en fonction de la période de défi totale.

évaluation :

• scalabilité: la scalabilité du plan deux dépend du montant total de jetons que les fournisseurs de données sont prêts à miser dans l'assurance.
• coût de la politique : puisque des niveaux de sécurité plus élevés sont liés à la période de défi, les fournisseurs de données doivent miser pendant une période égale ou supérieure à la période de défi. Ainsi, des exigences de sécurité plus élevées entraînent des périodes de mise plus longues et des coûts plus élevés pour le nœud léger. En termes de formule, le coût de la mise en jeu pour les fournisseurs de données est calculé comme le revenu du nœud fournisseur de données / (utilisation moyenne annuelle de la mise en jeu 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 en jeu multiplié par la période de politique et la taille de la politique.

efficacité du plan

Premièrement, en ce qui concerne l'efficacité de calcul des nœuds légers, les deux plans pour les nœuds légers montrent une efficacité de vérification à l'échelle des millisecondes (les nœuds légers ne doivent vérifier les données qu'une seule fois). Deuxièmement, en ce qui concerne la latence des nœuds légers, sous différentes configurations expérimentales (comme indiqué dans la figure ci-dessous), la latence est également à l'échelle des millisecondes. Il est important de noter que la latence augmente linéairement avec le nombre de fournisseurs de données, mais reste toujours à l'échelle des millisecondes. De plus, dans le plan un, car 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 d'inspecteurs est fiable et suffisamment efficace, ce retard de 5 heures peut être considérablement réduit.

troisièmement, en termes de coûts du nœud léger, dans la pratique, les nœuds légers supportent principalement deux coûts : les frais de gaz et les primes d'assurance, qui augmentent tous deux avec le montant de la police. de plus, pour les inspecteurs, les frais de gaz liés à la soumission des données seront remboursés par le montant confisqué pour garantir des incitations à la participation suffisantes.

directions d'expansion

• plus de garanties : actuellement, les fournisseurs de données misent des jetons eth, mais les informations de transaction sont calculées en termes de dollars américains. cela nécessite que les nœuds légers évaluent le taux de change de l'eth à chaque fois qu'ils obtiennent des données pour assurer suffisamment de garanties. autoriser plusieurs jetons pour la mise donnerait aux fournisseurs de données plus d'options et réduirait le risque associé à une seule devise.
• autorisation : similaire au minage conjoint, certains investisseurs particuliers peuvent autoriser leur eth à des nœuds complets pour participer au réseau de fournisseurs de données, avec des gains distribués selon leurs accords, similaire au lsd.
• garantie de bloc : pour éviter l'attente de la période de confirmation finale (12-13 secondes sur ethereum), les nœuds légers peuvent utiliser une garantie pour réduire ce temps d'attente. les nœuds légers ajoutent un symbole/identifiant lorsqu'ils font des demandes de données et spécifient le type de garantie nécessaire (confirmation finale/proposée). les fournisseurs de données fournissent ensuite les données correspondantes et la signature lors de la réception de la demande. si les fournisseurs de données échouent à proposer des blocs dans le scénario de “garantie proposée”, ils seront pénalisés.

Note: les blocs proposés seront éventuellement finalisés ou deviendront des blocs oncles.

• Coûts et frais : Pour le réseau d’inspecteurs, ils doivent miser un certain nombre de jetons (supérieur aux frais de gaz) pour soumettre des preuves au contrat intelligent. De plus, l’utilisation de preuves à divulgation nulle de connaissance (ZKP) peut réduire les coûts associés à ces preuves. Dans le cadre du mécanisme d’assurance, les primes payées par les nœuds légers vont aux fournisseurs de données, tandis que le réseau d’inspecteurs prend une partie des revenus confisqués aux 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 couche de consensus, ils peuvent également vérifier la disponibilité des données. Il existe deux schémas pour vérifier la disponibilité : le modèle pull et le modèle push. Le modèle pull consiste en des nœuds légers échantillonnant aléatoirement des données à partir des nœuds complets. Le modèle push implique que les producteurs de blocs distribuent différents blocs aux fournisseurs de données. Les fournisseurs de données utilisant le modèle pull sont responsables de répondre aux demandes d'échantillonnage. Les nœuds légers transmettent les données reçues à des nœuds/validateurs de confiance, qui tentent de reconstruire le bloc. S'ils n'y parviennent pas, le fournisseur de données sera pénalisé. Le protocole de nœud léger proposé dans cet article introduit un mécanisme d'assurance, offrant une nouvelle direction pour la recherche sur la disponibilité des données.

résumé et évaluation

le schéma du nœud léger proposé dans cet article offre une "sécurité programmable" pour répondre aux besoins de sécurité dans diverses situations. Le schéma un donne la priorité à une sécurité accrue au détriment d'une latence accrue, tandis que le schéma deux utilise un mécanisme d'assurance pour offrir aux nœuds légers des services de "confirmation instantanée". Ces schémas sont applicables dans des scénarios nécessitant une finalité des transactions, telles que les transactions atomiques et les transactions inter-chaînes.

disclaimer：

1. Cet article est reproduit à partir de [Partenaires Eureka]. tous les droits d'auteur appartiennent à l'auteur original [andy, arthur]. s'il y a des objections à cette réimpression, veuillez contacter le Porte apprendrel'équipe, et ils s'en occuperont rapidement.
2. clause de non-responsabilité: les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil en investissement.
3. les traductions de l'article dans d'autres langues sont réalisées par l'équipe d'apprentissage de Gate.io. Sauf indication contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.