Les "Engagements" de Bitcoin sont des mécanismes qui fixent des conditions pour les futures transactions Bitcoin. L'article décrit les concepts de base, les scénarios d'application et les méthodes d'implémentation technique des clauses restrictives, et discute des principes de conception qui les sous-tendent. Des propositions techniques telles que OP_CAT, OP_CTV et APO sont introduites, et comment elles améliorent la programmabilité et les fonctions de contrat intelligent de Bitcoin. En même temps, l'article aborde également l'application des clauses restrictives dans le réseau Bitcoin, telles que le contrôle de la congestion, les coffres-forts, les canaux d'état, etc., et discute des idées de conception pour implémenter des clauses restrictives et des éventuels litiges communautaires.

Co-écrit par Jeffrey HuetHarper Li

Il y a eu récemment une vague de discussions dans la communauté Bitcoin concernant la réactivation d'opcodes tels que OP_CAT, et Taproot Wizard a attiré beaucoup d'attention en lançant les NFT de Quantum Cats, affirmant avoir obtenu l'assignation BIP-420. Les partisans affirment que l'activation d'OP_CAT permettra de réaliser des “conventions”, et ainsi d'apporter des contrats intelligents ou de la programmabilité dans Bitcoin.

Si vous remarquez le mot "covenants" et faites un peu de recherche, vous verrez que c'est un autre gros sujet. Les développeurs parlent depuis des années de technologies qui implémentent des covenants, tels que OP_CTV, APO, OP_VAULT, et plus encore, en plus de OP_CAT.

Plus précisément, les scripts Bitcoin actuels comportent également certains types de conventions, telles que des verrous temporels basés sur les opcodes, qui sont mis en œuvre en inspectant le champ nLock ou nSequence d'une transaction pour limiter le temps avant que la transaction puisse être dépensée, mais sont toujours limités aux restrictions temporelles.

Alors, quels sont exactement les « covenants » de Bitcoin ? Pourquoi a-t-il attiré tant d'attention et suscité tant de discussions de la part des développeurs depuis des années ? Quelle programmabilité de Bitcoin peut être réalisée ? Quels sont les principes de conception qui le sous-tendent ? Cet article tente de fournir un aperçu et une discussion.

Qu'est-ce que les “Covenants”?

Le Covenant est un mécanisme qui peut définir des conditions sur les futures transactions Bitcoin.

En fait, les scripts Bitcoin actuels contiennent des contraintes, telles que devoir entrer une signature légitime, envoyer des scripts conformes lors des dépenses. Tant que l'utilisateur peut le déverrouiller, il peut dépenser ce UTXO où il le souhaite.

Le Covenant consiste à imposer plus de restrictions en plus de cette limitation sur la manière de déverrouiller, telles que limiter les dépenses de UTXO après qu'il a été dépensé, ce qui permet d'obtenir un effet similaire à celui de l'affectation, ou d'autres conditions d'entrée alimentées dans une transaction, etc.

Alors pourquoi les développeurs et les chercheurs conçoivent-ils ces contrôles de restriction ? C'est parce que les clauses restrictives ne sont pas simplement des restrictions pour rien, mais plutôt pour définir les règles d'exécution des transactions. De cette manière, l'utilisateur ne peut exécuter que des transactions conformes aux règles prédéfinies, complétant ainsi le processus commercial prévu.

Donc, de manière plutôt contre-intuitive, cela apporte plus de scénarios d'application.

Scénarios d'application

Garantir les pénalités de mise en jeu

Un des exemples les plus intuitifs d'un pacte est la transaction de réduction de Babylone dans le processus de mise en jeu de Bitcoin.

Le processus de mise en jeu de Bitcoin de Babylon implique que les utilisateurs envoient leur BTC à un script spécial sur la chaîne principale avec deux conditions de dépense :

• Heureuse fin : après un certain laps de temps, l'utilisateur peut déverrouiller avec sa propre signature, ce qui signifie que le processus de désenclavement est complet.
• Mauvaise fin : Si l'utilisateur est victime d'une attaque de double-dépense sur la chaîne PoS, l'utilisateur peut débloquer les actifs avec sa propre signature via EOTS (signatures à usage unique extractibles), et une partie des actifs peut être forcée d'être envoyée à l'adresse de brûlage (slash) par un acteur exécutant dans le réseau.

Source: Bitcoin Staking: Déblocage de 21M Bitcoins pour Sécuriser l'Économie de Preuve d'Enjeu

Notez le mot "forcé", ce qui signifie que même si le UTXO peut être déverrouillé, l'actif ne peut pas être envoyé ailleurs, il ne peut être que brûlé. Cela garantit qu'un utilisateur malveillant ne peut pas s'en sortir en transférant l'actif à lui-même avec sa propre signature connue.

Cette fonctionnalité, après la mise en œuvre de clauses telles que OP_CTV, peut être mise en œuvre en ajoutant des opcodes à la "mauvaise fin" du script de mise en jeu.

Avant l'activation de OP_CTV, Babylon aura besoin d'une solution de contournement pour émuler l'effet de l'application des conventions en faisant travailler ensemble l'utilisateur et le comité.

Contrôle de congestion/Échelle

En règle générale, la congestion se produit lorsque les frais sont élevés sur Bitcoin avec un nombre relativement élevé de transactions accumulées dans le pool de transactions en attente d'être emballées, donc si un utilisateur souhaite confirmer une transaction rapidement, il ou elle doit augmenter les frais.

À ce stade, si un utilisateur doit envoyer plusieurs transactions à plusieurs adresses, il devra augmenter ses frais et supporter des coûts plus élevés. En conséquence, cela fera monter davantage les frais de transaction de l'ensemble du réseau.

S'il y a une entente, alors il y a une solution : une seule transaction engagée avec des sorties multiples. Cet engagement peut convaincre tous les destinataires que la transaction finale aura lieu et que chacun peut attendre que les frais soient bas avant d'envoyer la transaction spécifique.

Comme le montre ci-dessous, lorsque la demande d'espace de bloc est élevée, il devient très cher de mener des transactions. En utilisant OP_CHECKTEMPLATEVERIFY, un processeur de paiement à volume élevé peut regrouper tous ses paiements dans une seule transaction O(1) pour confirmation. Ensuite, après un certain temps, lorsque la demande d'espace de bloc diminue, les paiements peuvent être étendus à partir de ce UTXO.

Source: https://utxos.org/uses/scaling/

Ce scénario est l'un des cas d'utilisation les plus typiques présentés par cette restriction OP_CTV. De nombreux autres cas d'utilisation peuvent être trouvés àhttps://utxos.org/uses.En plus du contrôle de congestion mentionné ci-dessus, la page répertorie les paris Soft Fork, les options décentralisées, les Drivechains, les canaux batch, les canaux non interactifs, les pools miniers sans coordination ni confiance, les coffres, les contrats sécurisés verrouillés dans le temps (HTLCS) et plus encore.

Coffres-forts

Les coffres-forts sont l'un des cas d'utilisation de Bitcoin les plus largement discutés, en particulier dans le domaine des pactes. Parce que les opérations quotidiennes impliquent inévitablement un équilibre entre la nécessité de garder les fonds en sécurité et la nécessité de les utiliser, on aimerait avoir un tel coffre-fort qui peut garder les fonds en sécurité, voire restreindre leur utilisation en cas de piratage du compte (par exemple, compromettre la clé privée).

Basé sur les techniques utilisées pour mettre en œuvre des clauses de restriction, ce type de coffre de garde peut être construit relativement facilement.

Prenez le schéma de conception de OP_VAULT comme exemple : lors de la dépense des fonds dans le coffre, une transaction doit d'abord être envoyée à la chaîne. Cette transaction indique l'intention de dépenser le coffre, ce qui est un "déclencheur", et des conditions y sont définies :

• Si tout va bien, alors la deuxième transaction finira par retirer les fonds. Après avoir attendu N blocs, les fonds peuvent être dépensés n'importe où.
• S'il s'avère que la transaction a été volée (ou forcée dans une "attaque de déclenchement"), les actifs peuvent être envoyés immédiatement à une autre adresse sécurisée (plus sûre pour l'utilisateur) juste avant que la transaction de retrait ne soit envoyée après N blocs.

Processus de OP_VAULT ，source：BIP-345

Notez qu'il est également possible de construire un coffre-fort sans engagements, et une façon possible de le faire est d'utiliser une clé privée pour préparer une signature pour une dépense ultérieure, puis de détruire cette clé privée. Cependant, il existe encore plus de limitations, telles que la nécessité de s'assurer que la clé privée a été détruite (similaire au processus de configuration de confiance dans les preuves de zéro connaissance), et le manque de flexibilité dans la détermination du montant et des frais à l'avance (en raison de la pré-signature).

Coffres précalculés et OP_VAULT, source: BIP-345

Canaux d'état plus robustes et flexibles

On peut généralement supposer que les canaux d'état, y compris le Lightning Network, offrent presque la même sécurité que la chaîne principale (en termes de garantir que les nœuds peuvent observer le dernier état et peuvent correctement publier le dernier état à la chaîne). Cependant, avec les pactes, certains nouveaux designs de canaux d'état peuvent être créés de manière plus robuste ou plus flexible au-dessus du Lightning Network. Certains des plus connus incluent Eltoo, Ark.

Eltoo (également connu sous le nom de LN-Symmetry) est un exemple typique. En prenant l'acronyme de "L2", cette technologie propose une couche d'exécution pour le réseau Lightning qui permet à tout état de canal ultérieur de remplacer l'état précédent sans mécanisme de pénalité, évitant ainsi le besoin pour les nœuds du réseau Lightning de sauvegarder plusieurs états précédents pour empêcher leurs adversaires de commettre des actes malveillants. Pour atteindre l'effet ci-dessus, Eltoo propose la signature SIGHASH_NOINPUT, APO (BIP-118).

Ark vise à réduire la difficulté de la liquidité entrante et de la gestion des canaux du réseau lightning. Il s'agit d'un protocole sous forme de joinpool, où plusieurs utilisateurs peuvent accepter un fournisseur de services comme contrepartie pour une certaine période, et échanger des UTXOs virtuels (vUTXOs) hors chaîne, mais partagent un UTXO sur la chaîne pour réduire les coûts. Similaire aux voûtes, Ark peut être implémenté sur le réseau Bitcoin actuel ; cependant, avec l'introduction de covenants, Ark peut réduire la quantité d'interaction requise en fonction de modèles de transaction, permettant une sortie unilatérale plus décentralisée.

Aperçu des Engagements

Comme on peut le voir à partir des applications ci-dessus, les engagements sont plus comme un effet qu'une certaine technologie, et en tant que tels, il existe de nombreuses façons techniques de les mettre en œuvre. Ils peuvent être catégorisés comme suit :

• Type: générique, restrictif
• Implémentation: basée sur les opcodes, basée sur les signatures
• Récursion : récursif, non récursif

Ici, récursif signifie : il existe des implémentations de conventions qui peuvent également limiter la sortie de la prochaine transaction en limitant la sortie de cette transaction, ce qui signifie que chaque transaction dans la chaîne de transactions est restreinte par la précédente.

Certains des designs de covenants populaires incluent:

Conceptions des Alliances

Comme on peut le voir dans l'introduction précédente, les scripts Bitcoin actuels restreignent principalement les conditions de déverrouillage et ne limitent pas la manière dont cet UTXO peut être dépensé. Pour mettre en œuvre des pactes, nous devons penser autrement : pourquoi les scripts Bitcoin actuels ne peuvent-ils pas mettre en œuvre des pactes ?

La principale raison est que les scripts Bitcoin actuels ne peuvent pas lire la transaction elle-même, ce qui signifie l'introspection de la transaction.

Si nous pouvions implémenter l'introspection - inspecter n'importe quoi dans la transaction (y compris la sortie) - alors nous pourrions implémenter des pactes.

Ainsi, la conception des alliances est également centrée sur la façon de mettre en œuvre l'introspection.

Basé sur l'opcode contre basé sur la signature

La plus simple et la plus rudimentaire des idées est d'ajouter un ou plusieurs opcodes (un opcode + plusieurs paramètres, ou plusieurs opcodes avec des fonctions différentes) et de lire directement le contenu de la transaction. C'est aussi connu sous le nom d'idée basée sur les opcodes.

Une autre façon de penser est qu'au lieu de lire et de vérifier le contenu de la transaction elle-même directement dans le script, le hachage du contenu de la transaction peut être utilisé, ce qui signifie que si ce hachage a été signé, alors en transformant l'opcode comme OP_CHECKSIG dans le script pour vérifier cette signature, il est possible de mettre en œuvre indirectement l'inspection de la transaction et les engagements. Cette idée est basée sur l'approche de conception de signature. Elle inclut principalement APO et OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) est une proposition pour un hachage de signature. La manière la plus simple de signer est de s'engager à la fois sur les entrées et les sorties d'une transaction, mais il existe une manière plus flexible pour Bitcoin de s'engager sélectivement sur les entrées ou les sorties d'une transaction, connue sous le nom de SIGHASH.

La gamme actuelle de SIGHASH et ses combinaisons de signatures pour les entrées et les sorties des transactions (source : Mastering Bitcoin, 2e)

Comme indiqué ci-dessus, en plus de TOUS, qui s'applique à toutes les données, AUCUN est signé de telle manière qu'il s'applique uniquement à toutes les entrées et non aux sorties, et SIMPLE construit là-dessus en l'appliquant uniquement aux sorties avec le même numéro d'index d'entrée. De plus, SIGHASH peut être combiné, avec le modificateur ANYONECANPAY superposé, pour s'appliquer uniquement à une entrée.

Le SIGHASH de APO, en revanche, ne signe que la sortie, pas l'entrée. Cela signifie qu'une transaction signée avec APO peut être attachée ultérieurement à n'importe quel UTXO qui remplit les conditions.

Cette flexibilité est la justification de la mise en œuvre des engagements par APO :

• Une ou plusieurs transactions peuvent être créées à l'avance
• Les informations de ces transactions sont utilisées pour construire une clé publique à partir de laquelle seule la signature de dépense peut être dérivée/vérifiée
• de sorte que tous les actifs envoyés à cette adresse de clé publique ne peuvent être dépensés que par le biais de transactions pré-créées.

Il convient de noter que, étant donné que cette clé publique ne possède pas de clé privée correspondante, cela garantit que ces actifs ne peuvent être dépensés que par le biais de transactions pré-créées. Ensuite, nous pouvons mettre en œuvre un pacte en spécifiant où vont les actifs dans ces transactions pré-créées.

Cela peut être mieux compris en le comparant aux contrats intelligents d'Ethereum : ce que nous pouvons réaliser avec les contrats intelligents, c'est que nous ne pouvons retirer de l'argent d'une adresse contractée que si certaines conditions sont remplies, plutôt que de le dépenser arbitrairement avec une signature EOA. De ce point de vue, Bitcoin peut réaliser cet effet grâce à des améliorations dans le mécanisme de signature.

Le problème avec le processus ci-dessus, cependant, est qu'il y a un dev@lists.linuxfoundation.org/msg08075.html">dépendance circulaire dans le calcul, car il est nécessaire de connaître l'entrée pour pré-signer et créer la transaction.

La signification de la mise en œuvre de APO et SIGHASH_NOINPUT de cette méthode de signature est qu'elle résout ce problème de dépendance circulaire en n'ayant besoin de connaître (spécifier) que la sortie complète de la transaction au moment du calcul.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), ou BIP-119, utilise une amélioration de l'opcode. Il prend le hachage d'engagement comme argument et exige que toute transaction exécutant un opcode contienne un ensemble de sorties qui correspondent à cet engagement. Avec CTV, il permettrait aux utilisateurs de Bitcoin de limiter la façon dont ils utilisent Bitcoin.

Initialement introduit sous le nom d'OP_CHECKOUTPUTSHASHVERIFY (COSHV) et avec un premier axe sur la capacité à créer des transactions de contrôle de congestion, la critique de la proposition s'est également concentrée sur le fait qu'elle n'est pas assez générique et est trop spécifique au cas d'utilisation du contrôle de congestion.

Dans le cas d'utilisation du contrôle de la congestion mentionné ci-dessus, Alice, l'expéditeur, pourrait créer 10 sorties et hacher ces 10 sorties, et utiliser le digest résultant pour créer un script tapleaf qui contient COSHV. Alice pourrait également utiliser les clés publiques des participants pour former une clé interne Taproot qui leur permettrait de collaborer pour dépenser l'argent sans révéler le chemin du script Taproot.

Alice donne ensuite à chaque destinataire une copie de tous les 10 outputs afin que chacun puisse vérifier la transaction de configuration d'Alice. Lorsqu'ils veulent dépenser le paiement plus tard, l'un d'entre eux peut créer une transaction avec les outputs engagés.

Tout au long du processus, alors qu'Alice crée et envoie la transaction de configuration, Alice peut envoyer ces 10 copies des sorties via des méthodes de communication asynchrones existantes, telles que l'e-mail ou les services de cloud. Cela signifie que les destinataires n'ont pas besoin d'être en ligne ou d'interagir les uns avec les autres.

Source: https://bitcoinops.org/fr/newsletters/2019/05/29/#proposed-transaction-output-commitments

Tout comme les APO, les adresses peuvent être construites en fonction des conditions de dépenses, et des "verrous" peuvent être effectués de différentes manières, y compris des clés supplémentaires, des verrous temporels relatifs ou fixes, et d'autres logiques pour les combiner.

Source :https://twitter.com/OwenKemeys/status/1741575353716326835

Sur cette base, CTV propose de vérifier si la transaction dépensée après le hachage correspond à celle définie, ce qui signifie que les données de la transaction sont utilisées comme clé pour déverrouiller le "verrou".

Nous pouvons étendre l'exemple ci-dessus de 10 destinataires, où un destinataire peut également faire en sorte que sa clé d'adresse soit une TX signée mais non diffusée envoyant au lot suivant de destinataires, et ainsi de suite, formant une structure arborescente comme indiqué dans la figure ci-dessous. Alice peut construire un changement dans les soldes des comptes impliquant plusieurs utilisateurs sur la chaîne en n'utilisant qu'1 UTXO d'espace de bloc.

Source: https://twitter.com/OwenKemeys/status/1741575353716326835

Et si l'une des feuilles est un canal d'éclairage, ou un stockage à froid, ou un autre chemin de paiement? Alors l'arbre sera étendu d'un arbre de paiement multi-couche unidimensionnel à un arbre de paiement multi-couche multidimensionnel, et les scénarios qui peuvent être pris en charge seront plus riches et plus flexibles.

Source: https://twitter.com/OwenKemeys/status/1744181234417140076

Depuis sa proposition, CTV a subi un changement de nom de COSHV en 2019, a été assigné BIP-119 en 2020, et l'émergence de Sapio, le langage de programmation utilisé pour créer le contrat de support de CTV, a suscité beaucoup de discussions, de mises à jour et de débats au sein de la communauté sur ses options d'activation en 2022 et 2023, et reste l'une des propositions de mise à jour de fork logiciel les plus discutées dans la communauté.

OP_CAT

OP_CAT, tel que décrit dans le paragraphe d'ouverture, est également une proposition de mise à niveau qui reçoit actuellement beaucoup d'attention, et implémente une fonction qui concatène deux éléments ou deux ensembles de données de la pile. Bien que cela semble simple, OP_CAT est très flexible et peut être implémenté dans les scripts de nombreuses manières.

L'exemple le plus direct est l'opération de l'arbre de Merkle, qui peut être interprété comme la concaténation de deux éléments puis haché. Actuellement, il existe des opcodes de hachage tels que OP_SHA256 et d'autres dans le script Bitcoin, donc si vous pouvez concaténer deux éléments en utilisant OP_CAT, vous pouvez implémenter la fonction de vérification de l'arbre de Merkle dans le script, ce qui offre également la possibilité d'une vérification du client léger dans une certaine mesure.

Une autre base pour l'implémentation est l'amélioration des signatures de Schnorr : vous pouvez définir la condition de signature de dépense d'un script comme une concaténation de la clé publique de l'utilisateur et d'une nonce publique ; puis si le signataire veut signer une autre transaction pour dépenser les fonds ailleurs, il ou elle doit utiliser la même nonce, ce qui peut divulguer la clé privée. Autrement dit, OP_CAT permet l'engagement de la nonce et garantit ainsi la validité de la transaction signée.

D'autres applications d'OP_CAT incluent Bistream,signatures d'arbre, signatures Lamport résistantes aux attaques quantiques, coffres-forts et plus encore.

OP_CAT en soi n'est pas une nouvelle fonctionnalité, car elle existait dans les premières versions de Bitcoin, mais elle étaitdésactivéen 2010 en raison de son potentiel d'être exploité par des attaquants. Par exemple, l'utilisation répétée de OP_DUP et OP_CAT pourrait facilement provoquer un dépassement de pile de nœud complet lors du traitement de tels scripts, comme on peut le voir dans ce démonstration.

Mais le problème d'explosion de pile susmentionné ne se produira-t-il pas de nos jours une fois que OP_CAT aura été réactivé ? Parce que la proposition actuelle OP_CAT ne concerne que son activation dans le tapscript, qui a une limite de 520 octets par élément de pile, cela ne causera pas le problème d'explosion de pile précédent. Il y a aussi des développeurs qui pensent que Satoshi Nakamoto a peut-être été trop sévère en désactivant complètement OP_CAT. Cependant, en raison de la flexibilité de OP_CAT, il se peut que certaines scénarios d'application susceptibles de conduire à des vulnérabilités existent.

Par conséquent, en combinant les scénarios d'application et les risques potentiels, OP_CAT a récemment suscité beaucoup d'attention et a également eu un Examen PR, et est actuellement l'une des propositions de mise à niveau les plus populaires.

Conclusion

'L'autorégulation apporte la liberté', comme on peut le voir dans l'introduction ci-dessus, les engagements peuvent être mis en œuvre directement dans les scripts Bitcoin pour qualifier davantage les dépenses sur les transactions, permettant ainsi des règles de transaction similaires à l'effet des contrats intelligents. Cette approche de programmation peut être vérifiée de manière plus native sur Bitcoin que les approches hors chaîne telles que BitVM, et peut également améliorer les applications sur la chaîne principale (contrôle de la congestion), les applications hors chaîne (canaux d'état), et d'autres nouvelles directions d'application (staking slashing, etc.).

Les techniques de mise en œuvre des pactes, combinées à d'autres mises à niveau, pourraient encore débloquer le potentiel de la programmabilité. Par exemple, la récente proposition pour l'arithmétique 64-bit

dans le examenpourrait être combiné plus loin avec le proposéOP_TLUVou d'autres engagements qui pourraient être programmés en fonction du nombre de satoshi en sortie d'une transaction.

Cependant, les alliances peuvent également conduire à des abus ou des vulnérabilités non planifiés, c'est pourquoi la communauté est également prudente à ce sujet. De plus, une mise à niveau des alliances devrait impliquer une mise à niveau en douceur des règles de consensus. Étant donné les circonstances entourant la mise à niveau de Taproot, il est probable que la mise à niveau liée aux alliances prendra également du temps pour être complétée.

Remerciements spéciaux

Merci Ajian, PêcheuretBenpour examen et suggestions!

Références

• https://utxos.org/
• https://bitcoincovenants.com/
• Une collection de ressources liées aux alliances : https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• BIP 345 : proposition OP_VAULT : https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/fr/topics/op_cat/
• OP_CAT: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
• Astuce CAT et Schnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Avis de non-responsabilité : Ce document est destiné uniquement à des fins d'information générale et ne constitue ni ne doit être interprété comme une forme de conseil en investissement, une sollicitation ou une offre d'investissement, et HashKey Capital n'accepte aucune responsabilité en ce qui concerne l'utilisation ou la confiance accordée à de telles informations.

Restez informés des dernières nouvelles de HashKey Capital -

Site web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

déclaration:

1. Cet article est reproduit à partir de [moyen], le droit d'auteur appartient à l'auteur original [Jeffrey HuetHarper Li] , si vous avez des objections à la reproduction, veuillez contacter le Gate Learnl'équipe, et l'équipe le traitera dès que possible selon les procédures pertinentes.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent aucun conseil en investissement.

3. D'autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn et ne sont pas mentionnées dans Gate, l'article traduit ne doit pas être reproduit, distribué ou plagié.