Résumé :

Le réseau B^2 a établi une couche de disponibilité des données (DA) appelée B^2 Hub au sein de la chaîne Bitcoin, s'inspirant des concepts de Celestia. Ce réseau de couche DA met en œuvre un échantillonnage de données et un codage d'effacement pour assurer une distribution rapide de nouvelles données à de nombreux nœuds externes et éviter la rétention de données. De plus, le Committer au sein du réseau B^2 Hub est responsable de télécharger l'index de stockage et le hachage de données de la couche DA sur la chaîne Bitcoin pour un accès public.

Pour alléger la charge sur les nœuds de la couche DA, les données historiques dans B^2 Hub ne sont pas conservées de manière permanente. En conséquence, B^2 s'est efforcé de reconstruire un réseau de stockage, en employant un mécanisme d'incitation au stockage similaire à celui d'Arweave pour inciter plus de nœuds à stocker des ensembles de données historiques complets en échange de récompenses de stockage；

· En ce qui concerne la vérification de l'état, B^2 adopte une approche de vérification hybride pour valider les preuves ZK hors chaîne et exploite le concept de bitVM pour défier les traces de vérification de preuves ZK sur chaîne. La sécurité du réseau B^2 est assurée lorsqu'un nœud challenger lance un défi lors de la détection d'une erreur, s'alignant sur le modèle de confiance du protocole de preuve de fraude. Cependant, en raison de l'utilisation de preuves ZK, ce processus de vérification de l'état est essentiellement hybride dans sa nature;

·En accord avec la feuille de route future du réseau B^2, le Hub B^2 compatible avec l'EVM a le potentiel de servir de couche de vérification hors chaîne et de couche DA connectant plusieurs solutions Bitcoin de couche 2. Son objectif est d’évoluer en une couche d'expansion fonctionnelle hors chaîne similaire à BTCKB pour Bitcoin. Étant donné les limitations de Bitcoin dans le support de divers scénarios, le développement d'une couche d'expansion fonctionnelle hors chaîne est prévu de devenir une pratique prédominante au sein de l'écosystème de la couche 2.

B^2 Hub : couche universelle de disponibilité des données (DA) et couche de vérification au sein de la chaîne Bitcoin

L'écosystème actuel de Bitcoin ressemble à une vaste étendue d'opportunités et de risques, où les conséquences de l'été des inscriptions ont insufflé une nouvelle vie à ce domaine, semblable à un sol fertile et vierge avec le parfum de la richesse flottant dans l'air. L'avènement de Bitcoin Layer 2 plus tôt cette année a transformé ce paysage autrefois désolé en un pôle d'aspirations pour de nombreux visionnaires.

Revenir au cœur du problème : la définition de la couche 2 reste un point de discorde entre les individus. Est-ce une chaîne latérale ? Un indexeur ? Le terme couche 2 englobe-t-il des chaînes qui établissent des connexions ? Un simple plug-in dépendant de Bitcoin et d'Ethereum peut-il être qualifié de couche ? Ces interrogations ressemblent à des équations non résolues sans solution définitive.

Selon les perspectives des communautés Ethereum et Celestia, la couche 2 représente une instance distincte d'une blockchain modulaire. Dans ce contexte, une interdépendance étroite existe entre la soi-disant "deuxième couche" et la "première couche." La sécurité de la couche 1 peut être partiellement ou significativement héritée par le réseau de la deuxième couche. La sécurité elle-même englobe diverses sous-catégories, notamment DA, vérification de statut, vérification de retrait, résistance à la censure et résistance à la réorganisation.

Compte tenu des limitations inhérentes du réseau Bitcoin, il n'est pas intrinsèquement propice à la prise en charge d'un réseau de couche 2 complet. Par exemple, en termes de DA, la capacité de traitement des données de Bitcoin est nettement inférieure à celle d'Ethereum. Avec un temps moyen de génération de bloc de 10 minutes, le taux de traitement des données maximal de Bitcoin n'est que de 6,8 Ko/s, soit environ 1/20e de la capacité d'Ethereum. Par conséquent, l'espace de bloc congestionné entraîne des coûts élevés pour la publication de données.

(Le coût de publication de données dans un bloc Bitcoin peut même atteindre 5 $ par Ko)

Si la couche 2 publie directement les nouvelles données de transaction ajoutées au bloc Bitcoin, elle n'atteindra pas un débit élevé ou des frais de transaction bas. Pour remédier à cela, une approche consiste à compresser considérablement les données avant de les téléverser dans le bloc Bitcoin. Citrea utilise actuellement cette méthode, indiquant qu'ils téléchargeront les modifications d'état (différence d'état) se produisant sur plusieurs comptes sur la chaîne Bitcoin, accompagnées de certificats ZK correspondants sur une période spécifique.

Cela permet à quiconque de vérifier la validité de la différence d'état et de la ZKP téléchargée depuis le réseau principal Bitcoin tout en maintenant des données légères sur la chaîne.

(L'ancien livre blanc de Polygon Hermez explique le principe du schéma de compression ci-dessus)

Malgré la compression significative de la taille des données obtenue par cette méthode, elle peut rencontrer des goulots d'étranglement dans des scénarios où de nombreuses transactions entraînent des changements d'état dans de nombreux comptes dans un court laps de temps. Bien que plus léger que le téléchargement direct des données de transaction individuelles, le téléchargement des modifications de compte entraîne tout de même des coûts importants de libération de données.

En conséquence, de nombreuses solutions de couche 2 de Bitcoin choisissent de ne pas télécharger les données DA sur le réseau principal de Bitcoin et utilisent plutôt des couches DA tierces comme Celestia. En revanche, B^2 adopte une approche différente en établissant un réseau de Disponibilité des Données (DA) directement sous la chaîne, connu sous le nom de B^2 Hub. Dans cette conception, les données cruciales telles que les données de transaction ou les diffs d'état sont stockées hors chaîne, seuls leurs index de stockage et hachages de données (appelés données pour simplifier) étant téléchargés sur le réseau principal de Bitcoin.

Ces hachages de données et index de stockage sont enregistrés sur la chaîne Bitcoin à l'instar des inscriptions. En exécutant un nœud Bitcoin, les individus peuvent accéder localement au hachage de données et à l'index de stockage. En utilisant la valeur de l'index, ils peuvent récupérer les données d'origine de la couche de stockage ou de DA hors chaîne de B^2. Le hachage de données permet de vérifier la correction des données obtenues à partir de la couche de DA hors chaîne par rapport au hachage correspondant sur la chaîne Bitcoin. Cette approche simple permet aux solutions de couche 2 de réduire la dépendance au mainnet Bitcoin pour les problèmes de DA, de réduire les coûts de transaction et d'atteindre un débit élevé.

Cependant, il est crucial de reconnaître que les plates-formes DA tierces sous la chaîne peuvent se livrer à des pratiques de rétention de données, empêchant l'accès externe à de nouvelles données - un phénomène connu sous le nom d'"attaque de rétention de données". Diverses solutions DA abordent différemment cette question, dans le but commun de diffuser rapidement et largement les données pour empêcher quelques nœuds sélectionnés de contrôler les autorisations d'accès aux données.

Selon la nouvelle feuille de route officielle de B^2 Network, sa solution DA s'appuie sur Celestia. Dans ce dernier design, les fournisseurs de données tiers fourniront continuellement des données au réseau Celestia. Les producteurs de blocs de Celestia organiseront ces fragments de données sous forme d'arbre de Merkle, les inséreront dans des blocs TIA et les diffuseront sur le réseau. Valideur/nœud complet.

Comme il y a beaucoup de données et que les blocs sont relativement volumineux, la plupart des gens ne peuvent pas se permettre d'exécuter des nœuds complets et ne peuvent exécuter que des nœuds légers. Le nœud léger ne synchronise pas le bloc complet, mais synchronise uniquement un en-tête de bloc avec la racine de l'arbre de Mekrle qui y est inscrite.

Selon la dernière feuille de route du réseau B^2, sa solution DA s'inspire de Celestia. Dans ce cadre, les fournisseurs de données externes fournissent continuellement des données au réseau Celestia. Les producteurs de blocs au sein de Celestia organisent ces fragments de données dans une structure d'arbre de Merkle, les intègrent dans des blocs TIA et les diffusent aux validateurs et aux nœuds complets du réseau. En raison du volume substantiel de données et de la taille importante des blocs, de nombreuses personnes choisissent d'exécuter des nœuds légers au lieu de nœuds complets. Les nœuds légers ne synchronisent que les en-têtes de bloc contenant la racine de l'arbre de Merkle.

Bien que les nœuds légers manquent d'une vue globale de l'arbre de Merkle et ne peuvent pas vérifier le nouveau contenu des données, ils peuvent demander des nœuds feuilles spécifiques aux nœuds complets. Les nœuds complets fournissent les nœuds feuilles demandés ainsi que les preuves de Merkle correspondantes pour convaincre les nœuds légers de leur existence au sein de l'arbre de Merkle du bloc Celestia, en garantissant qu'il ne s'agit pas de données fabriquées.

(Source de l'image : W3 Hitchhiker)

Dans le réseau Celestia, il existe une multitude de nœuds légers qui effectuent un échantillonnage de données à haute fréquence à partir de divers nœuds complets. Ces nœuds légers sélectionnent aléatoirement des fragments de données spécifiques de l'arbre de Merkle et les diffusent rapidement et efficacement à d'autres nœuds connectés, dans le but de distribuer des données à un large public de personnes et d'appareils. Cette approche facilite la diffusion rapide des données, garantissant qu'un nombre suffisant de nœuds reçoivent rapidement les dernières données, éliminant ainsi le besoin de compter sur un groupe limité de fournisseurs de données. Cet objectif fondamental souligne l'essence même de la Disponibilité des Données (DA) et de la distribution des données.

Cependant, malgré l'efficacité de la solution susmentionnée pour permettre un accès rapide aux données, elle ne garantit pas l'intégrité de la source de données. Par exemple, un producteur de blocs Celestia pourrait potentiellement insérer des données erronées dans un bloc, compliquant les efforts de reconstruction de l'ensemble de données complet et précis. Même si les personnes obtiennent tous les fragments de données dans le bloc, elles ne peuvent pas restaurer l'ensemble de données complet qui “devrait être inclus”.(Remarque: Le mot “devrait” est important ici).

De plus, dans les scénarios où certaines données de transaction restent cachées aux parties externes, le fait de retenir à peine 1% des fragments de données peut empêcher les extérieurs de reconstruire l'ensemble des données - une situation rappelant les attaques de retenue de données.

Dans le contexte décrit ci-dessus, la compréhension de la disponibilité des données concerne la question de savoir si les données de transaction au sein d’un bloc sont complètes, accessibles et facilement partageables à des fins de vérification. Contrairement à la perception commune, la disponibilité ne désigne pas uniquement l’accessibilité des données historiques de la blockchain à des entités externes. En conséquence, les responsables de Celestia et les fondateurs de L2BEAT préconisent de renommer la disponibilité des données en « libération de données », ce qui signifie la publication d’un ensemble de données de transactions complet et accessible au sein d’un bloc.

Pour résoudre le problème des attaques de rétention de données, Celestia utilise un codage d'effacement bidimensionnel. Si au moins 1/4 des fragments de données (codes d'effacement) au sein d'un bloc sont valides, les individus peuvent reconstruire l'ensemble de données d'origine. Cependant, si un producteur de bloc insère 3/4 de fragments de données erronés, la reconstruction de l'ensemble de données devient impossible. Notamment, une présence excessive de données indésirables dans un bloc peut être facilement identifiée par les nœuds légers, agissant comme un moyen de dissuasion contre les activités malveillantes des producteurs de blocs.

En mettant en œuvre cette solution, Celestia atténue efficacement la rétention de données sur sa plateforme de distribution de données. B^2 Network prévoit d'utiliser la méthodologie d'échantillonnage de données de Celestia comme point de référence fondamental à l'avenir, potentiellement en intégrant des technologies cryptographiques comme l'engagement KZG pour améliorer l'efficacité et la fiabilité des processus d'échantillonnage et de vérification des données menés par des nœuds légers.

Il est crucial de reconnaître que tandis que la solution susmentionnée traite de la rétention des données au sein de la plateforme DA elle-même, dans l'infrastructure de la couche 2, à la fois la plateforme DA et le Séquenceur possèdent des capacités de rétention des données. Dans des flux de travail comme celui de B^2 Network, le Séquenceur génère de nouvelles données en organisant et en traitant les transactions des utilisateurs et les changements d'état résultants en lots avant de les transmettre aux nœuds B^2 Hub servant de couche DA.

Dans les cas où des anomalies surviennent au sein d'un lot généré par le Séquenceur, il existe un risque de rétention de données ou d'autres activités malveillantes. Par conséquent, dès réception du lot, le réseau DA de B^2 Hub vérifie méticuleusement son contenu et rejette tout lot problématique. Ainsi, B^2 Hub fonctionne non seulement comme une couche DA similaire à Celestia, mais également comme une couche de vérification hors chaîne similaire à CKB dans le protocole RGB++.

(Diagramme de structure sous-jacente du réseau B^2 incomplet)

Conformément à la dernière feuille de route technologique du réseau B^2, une fois que le B^2 Hub reçoit et vérifie un lot, il le conserve pendant une période spécifique avant son expiration et son retrait du nœud local. Pour répondre aux problèmes d'obsolescence et de perte de données similaires à l'EIP-4844, le réseau B^2 établit un réseau de nœuds de stockage chargés de stocker définitivement les données de lot pour une récupération facile des données historiques en cas de besoin.

Cependant, il est peu probable que les particuliers exploitent un nœud de stockage B^2 sans raison convaincante. Pour encourager davantage de participants à exécuter des nœuds de stockage et renforcer la décentralisation du réseau, un mécanisme d'incitation doit être établi. La mise en œuvre d'un tel mécanisme nécessite des mesures pour prévenir les activités frauduleuses. Par exemple, si un système d'incitation récompense les particuliers qui stockent des données localement sur leurs appareils, il existe un risque de comportement malhonnête où quelqu'un supprime une partie des données après le téléchargement tout en prétendant à tort que ses données stockées sont complètes, une forme de triche trop courante.

Filecoin utilise des protocoles de preuve connus sous le nom de PoRep et PoSt, permettant aux nœuds de stockage de fournir des certificats de stockage comme preuve pour démontrer qu'ils ont effectivement stocké des données de manière sécurisée dans un laps de temps spécifié. Cependant, cette approche de preuve de stockage implique la génération de preuves ZK, qui sont intensives en termes de calcul et imposent des demandes matérielles significatives aux nœuds de stockage, les rendant potentiellement économiquement non réalisables.

Dans la dernière feuille de route technologique du réseau B^2, les nœuds de stockage mettront en œuvre un mécanisme similaire à Arweave, rivalisant pour l'opportunité de produire des blocs afin de gagner des incitations en jetons. Si un nœud de stockage supprime secrètement des données, sa probabilité de devenir le prochain producteur de blocs diminue. Les nœuds préservant le plus de données ont plus de chances de produire des blocs avec succès et de recevoir de plus grandes récompenses. Par conséquent, il est avantageux pour la plupart des nœuds de stockage de conserver l'ensemble complet des données historiques pour optimiser leurs perspectives de production de blocs.

Schéma de vérification d'état mixte avec ZK et preuve de fraude

Plus tôt, nous avons élaboré sur la solution de disponibilité des données (DA) du réseau B^2, et maintenant nous allons approfondir son mécanisme de vérification d'état. Le terme "schéma de vérification d'état" concerne la manière dont la couche 2 garantit une transition d'état suffisamment "sans confiance".

(Le site web L2BEAT évalue les cinq principaux indicateurs de sécurité pour Scroll. La validation de l'état fait référence au schéma de vérification de l'état)

Tel qu'indiqué sur le site web L2BEAT, qui évalue les indicateurs de sécurité pour Scroll, la validation d'état adresse spécifiquement le schéma de vérification d'état. Dans le réseau B^2 et la majorité des processus de couche 2, de nouvelles données sont générées par le séquenceur. Cette entité consolide et traite les transactions initiées par l'utilisateur ainsi que leurs changements d'état résultants après exécution. Ces modifications sont regroupées en lots et diffusées à divers nœuds au sein du réseau de couche 2, englobant les nœuds complets de couche 2 standard et les nœuds B^2 Hub.

À la réception des données de lot, le nœud Hub B^2 analyse méticuleusement et vérifie son contenu, englobant la « vérification de l'état » précédemment mentionnée. Essentiellement, la vérification de l'état consiste à valider l'exactitude des « changements d'état post-exécution de la transaction » documentés dans le lot généré par le séquenceur. Tout statut erroné dans un lot entraîne un rejet par le nœud Hub B^2.

Fonctionnant comme une chaîne publique de preuve d'enjeu (POS), B^2 Hub fait la distinction entre les producteurs de blocs et les vérificateurs. Périodiquement, les producteurs de blocs de B^2 Hub génèrent de nouveaux blocs et les diffusent à d'autres nœuds (validateurs). Ces blocs encapsulent des données de lot soumises par le séquenceur, reflétant un processus similaire à Celestia. Les nœuds externes demandent fréquemment des fragments de données au nœud B^2 Hub, facilitant la distribution des données de lot à de nombreux appareils de nœuds, y compris le réseau de stockage mentionné ci-dessus.

Au sein de B^2 Hub, opère un rôle pivot connu sous le nom de Committer. Cette entité hache les données de lot (notamment la racine de Merkle), stocke l'indice et les soumet à la chaîne Bitcoin sous forme d'inscription. L'accès au hachage des données et à l'indice de stockage permet de récupérer les données complètes de la couche de stockage/stockage hors chaîne. En supposant que N nœuds stockent les données de lot sous la chaîne, une fois qu'un nœud est prêt à partager des données avec des entités externes, toute partie intéressée peut accéder aux données requises. L'hypothèse de confiance dans ce scénario est de 1/N.

Il est certain que dans le processus susmentionné, B^2 Hub, chargé de valider les transitions d'état de la couche 2, fonctionne de manière indépendante du réseau principal Bitcoin, ne servant que de couche de vérification hors chaîne. Par conséquent, le schéma de vérification d'état de la couche 2 à ce stade ne parvient pas à égaler la fiabilité du réseau principal Bitcoin.

En général, ZK Rollup a la capacité d'hériter pleinement de la sécurité de la Couche 1. Cependant, étant donné les limitations actuelles de la chaîne Bitcoin en ne prenant en charge que des calculs de base et en l'absence de capacités de vérification directe des preuves ZK, aucune solution de Couche 2 sur Bitcoin ne peut rivaliser avec le modèle de sécurité d'Ethereum, en particulier celles utilisant des techniques de ZK Rollup comme Citrea et BOB.

Jusqu'à présent, l'approche la plus viable, telle qu'elle est élucidée dans le livre blanc de BitVM, consiste à décharger les processus de calcul complexes de la chaîne Bitcoin. Seules les calculs essentiels sont migrés vers la chaîne lorsqu'ils sont nécessaires. Par exemple, les traces de calcul générées lors de la vérification de la preuve ZK peuvent être divulguées publiquement et partagées avec des entités externes pour examen. Si des divergences apparaissent dans les étapes de calcul complexes, les individus peuvent vérifier ces calculs litigieux sur la chaîne Bitcoin. Cela nécessite de tirer parti du langage de script Bitcoin pour émuler les fonctionnalités des machines virtuelles spécialisées telles que l'Ethereum Virtual Machine (EVM). Bien que cette entreprise puisse nécessiter des efforts d'ingénierie importants, elle reste une entreprise réalisable.

Références :Une interprétation minimaliste de BitVM : Comment vérifier la preuve de fraude sur la chaîne BTC (exécuter le code d'opération de l'EVM ou d'un autre VM)

Dans la solution technique du réseau B^2, une fois que le séquenceur génère un nouveau lot, il est transmis à l'agrégateur et au Prover. Le Prover ZK-ise alors le processus de vérification des données du lot, produit un certificat ZK, et le transfère finalement au nœud B^2 Hub compatible avec l'EVM. La preuve ZK est authentifiée via un contrat Solidity, avec tous les processus de calcul décomposés en circuits logiques de bas niveau complexes. Ces circuits sont encodés dans le langage de script Bitcoin, formatés et soumis à une plateforme de disponibilité des données (DA) tierce avec un débit adéquat.

Si des individus remettent en question les traces de vérification ZK divulguées et soupçonnent une erreur à une étape spécifique, ils ont la possibilité de lancer un "défi" sur la chaîne Bitcoin. Ce défi incite le nœud Bitcoin à examiner directement l'étape contestée et à infliger des conséquences appropriées si nécessaire.

(Le diagramme de structure globale du réseau B^2, à l'exclusion des nœuds d'échantillonnage de données)

Alors qui est puni ? En fait, c'est le Committer. Dans le cadre du réseau B^2, le Committer diffuse non seulement le hachage de données mentionné précédemment à la chaîne Bitcoin, mais divulgue également l'engagement de vérification du certificat ZK au réseau principal Bitcoin. Grâce à des configurations spécifiques de Bitcoin Taproot, les individus conservent la capacité de poser des questions et de contester l'engagement de vérification de la preuve ZK émis par le Committer sur la chaîne Bitcoin à tout moment donné.

Pour élaborer sur le concept d'"engagement," il désigne des individus affirmant l'exactitude de certaines données hors chaîne et publiant une déclaration correspondante sur la chaîne de blocs. Cette déclaration sert d'"engagement" où les valeurs de promesse sont liées à des données hors chaîne spécifiques. Dans la solution B^2, si une partie remet en question l'engagement de vérification ZK émis par le Committer, elle a la possibilité de le contester.

On pourrait se demander pourquoi B^2 Hub doit vérifier le certificat ZK "de manière répétée et approfondie" s'il valide déjà le lot dès réception. Pourquoi ne pas divulguer publiquement le processus de vérification du lot pour des défis directs au lieu d'introduire une preuve ZK? L'inclusion de la preuve ZK sert à condenser les traces de calcul en une taille plus gérable avant la publication. La révélation publique du processus de vérification impliquant les transactions de couche 2 et les changements d'état dans les portes logiques et les scripts Bitcoin entraînerait une taille de données substantielle. La ZKisation compresse efficacement ces données avant leur diffusion.

Voici un résumé concis du flux de travail de B^2 :

1. Le séquenceur dans B^2 génère de nouveaux blocs de couche 2 et consolide plusieurs blocs en lots de données. Ces lots sont transmis à l'agrégateur et au nœud validateur dans le réseau B^2 Hub.

2. L'agrégateur envoie le lot de données au nœud Prover, permettant la création de la preuve du zéro-connaissance correspondante. Par la suite, le certificat ZK est transmis au réseau de vérification et de DA de B^2 (B^2 Hub).

3. Le nœud B^2 Hub vérifie si la preuve ZK de l'agrégateur correspond au lot du séquenceur. Une correspondance réussie indique le passage de vérification. Le hash de données du lot vérifié et l'index de stockage sont relayés à la chaîne Bitcoin par un nœud B^2 Hub désigné (Committer).

4. L'ensemble du processus de calcul pour vérifier la Preuve de Connaissance Zero est publiquement divulgué par B^2 Hub, avec l'engagement de ce processus soumis à la chaîne Bitcoin pour d'éventuels défis. Un défi réussi entraîne des pénalités économiques pour le nœud émetteur B^2 Hub (leur UTXO sur la chaîne Bitcoin est déverrouillé et transféré au challenger).

Cette approche de vérification d'état du réseau B^2 intègre les méthodologies ZK et anti-fraude, constituant une méthode hybride de vérification d'état. Avec au moins un nœud honnête sous la chaîne prêt à contester dès la détection d'une erreur, une assurance est fournie concernant l'intégrité de la transition d'état du réseau B^2.

Selon les informations des membres de la communauté Bitcoin occidentale, il y a des spéculations sur une éventuelle future bifurcation du réseau principal de Bitcoin pour prendre en charge des capacités de calcul améliorées. Cela pourrait ouvrir la voie à une vérification directe de la preuve ZK sur la chaîne Bitcoin, annonçant des changements transformateurs pour l'ensemble du paysage du Bitcoin Layer 2. En tant que couche de DA et de vérification fondamentale, B^2 Hub fonctionne non seulement comme composant central du réseau B^2, mais renforce également d'autres couches secondaires Bitcoin. Dans le domaine concurrentiel des solutions Bitcoin Layer 2, les couches d'expansion fonctionnelle hors chaîne gagnent en importance, avec B^2 Hub et BTCKB représentant juste un aperçu de ce paysage en évolution.

Avertissement :

1. Cet article a été reproduit à partir de [Geek Web3 ), avec le titre original “Analyse de la nouvelle feuille de route technologique B^2 : la nécessité de la couche de DA et de vérification sous la chaîne Bitcoin.” Les droits d'auteur sont attribués à l'auteur original, Faust de Geek Web3. Si vous avez des objections à la reproduction, veuillez contacter le Équipe d'apprentissage de Gatepour une résolution rapide suivant les procédures pertinentes.

2. Les perspectives et opinions exprimées dans cet article reflètent uniquement les points de vue personnels de l'auteur et ne constituent pas des conseils en investissement.

3. Les traductions de l'article dans d'autres langues sont fournies par l'équipe Gate Learn. Les articles traduits ne peuvent être copiés, diffusés ou plagiés sans mentionner Gate.