Rapport de recherche de HashKey Capital : les conventions, la programmabilité du Bitcoin

Auteur original : Jeffrey HU, responsable de la recherche en investissement chez HashKey Capital, Harper LI, gestionnaire des investissements chez HashKey Capital

Récemment, il y a eu une vague de discussions dans la communauté Bitcoin sur la réactivation des opcodes tels que OP_CAT. Taproot Wizard a également attiré beaucoup d'attention en lançant les NFT Quantum Cats et en affirmant avoir obtenu le numéro BIP-420. Les partisans affirment que l'activation d'OP_CAT peut mettre en œuvre des conventions et réaliser des contrats intelligents ou la programmabilité de Bitcoins.

Si vous remarquez le mot restrictions et faites une petite recherche, vous verrez qu'il s'agit d'un autre gros terrier de lapin. Les développeurs discutent depuis des années du fait qu'en plus d'OP_CAT, il existe OP_CTV, APO, OP_VAULT et d'autres techniques pour implémenter des clauses de restriction.

Alors, quelles sont exactement les restrictions du Bitcoin ? Pourquoi suscitent-elles autant d'attention et de discussions de la part des développeurs depuis des années ? Quel type de programmabilité le Bitcoin peut-il atteindre ? Quels sont les principes de conception qui le sous-tendent ? Cet article tente de donner un aperçu et une discussion.

Qu'est-ce qu'une clause restrictive ?

Les conventions, traduites en chinois par des clauses restrictives et parfois traduites par des contrats, sont un mécanisme qui peut définir les conditions des futures transactions Bitcoin.

Le script Bitcoin actuel contient également des conditions restrictives, telles que la saisie d'une signature légale et la saisie d'un script correspondant lors des dépenses. Cependant, tant que l'utilisateur peut le déverrouiller, il peut dépenser l'UTXO où il le souhaite.

Les conditions restrictives visent à créer davantage de restrictions en fonction de la manière de débloquer cette restriction, comme la limitation des dépenses après UTXO, c'est-à-dire pour obtenir un effet similaire aux fonds de garantie à des fins spéciales ; ou d'autres conditions d'entrée envoyées dans une transaction.

Plus précisément, les scripts Bitcoin actuels ont également certaines restrictions, telles que les verrous temporels basés sur des opcodes, qui implémentent des limites de temps avant que les transactions ne soient dépensées en introspectant les champs nLock ou nSequence des transactions, mais ils sont fondamentalement limités aux limites de temps.

Alors pourquoi les développeurs et les chercheurs conçoivent-ils ces contrôles de restriction ? Parce que les clauses de restriction ne servent pas seulement à restreindre les transactions, mais aussi à établir des règles pour l'exécution des transactions. De cette façon, les utilisateurs ne peuvent exécuter des transactions que selon les règles prédéfinies pour terminer le processus métier prédéterminé.

Ce qui est contre-intuitif, c’est que cela peut ouvrir la voie à davantage de scénarios d’application.

Scénario d'application

Assurer des pénalités de jalonnement

L’un des exemples les plus intuitifs de clauses restrictives est celui des transactions slash de Babylon dans le processus de jalonnement de Bitcoin.

Le processus de jalonnement Bitcoin de Babylons consiste pour les utilisateurs à envoyer leurs actifs BTC à un script spécial sur la chaîne principale. Les conditions de dépenses comprennent deux types :

• Fin heureuse : après un certain temps, l'utilisateur peut le déverrouiller avec sa propre signature, complétant ainsi le processus de désengagement

• Mauvaise fin : Si un utilisateur a une double signature ou un autre comportement malveillant sur une chaîne PoS louée par Babylon, alors grâce à EOTS (signatures uniques extractibles), cette partie des actifs peut être déverrouillée et le rôle exécutif dans le réseau forcera une partie des actifs à être envoyés à l'adresse de gravure (barre oblique)

Source : Bitcoin Staking : débloquer 21 millions de bitcoins pour sécuriser l'économie de la preuve d'enjeu

Notez l'envoi forcé ici, ce qui signifie que même si l'UTXO peut être déverrouillé, l'actif ne peut pas être envoyé ailleurs à volonté et ne peut qu'être brûlé. Cela garantit que les utilisateurs malveillants ne peuvent pas utiliser leurs signatures connues pour se retransférer les actifs à l'avance afin d'échapper à la sanction.

Si cette fonction est implémentée après l'implémentation de termes restrictifs tels que OP_CTV, des opcodes tels que OP_CTV peuvent être ajoutés à la branche de fin incorrecte du script de jalonnement pour implémenter les restrictions.

Avant l’activation d’OP_CTV, Babylon devait utiliser une méthode de contournement, avec les utilisateurs et le comité la mettant en œuvre conjointement, pour simuler l’effet de l’application des clauses restrictives.

Contrôle de la congestion

D'une manière générale, la congestion signifie que lorsque le taux de frais de transaction sur le réseau Bitcoin est très élevé, de nombreuses transactions attendent d'être regroupées dans le pool de transactions. Par conséquent, si les utilisateurs souhaitent confirmer rapidement les transactions, ils doivent augmenter les frais de transaction.

Si un utilisateur doit envoyer plusieurs transactions à plusieurs destinataires, il devra augmenter les frais de traitement et supporter des coûts relativement élevés, ce qui augmentera également le taux de frais de traitement de l'ensemble du réseau.

S'il existe des restrictions, une solution consiste à ce que l'expéditeur s'engage d'abord à effectuer une transaction par lots. Cet engagement peut faire croire à tous les destinataires que la transaction finale sera effectuée et ils peuvent attendre que les frais de traitement soient bas avant d'envoyer la transaction spécifique.

Comme le montre la figure ci-dessous, lorsque la demande d'espace de bloc est élevée, il devient très coûteux d'effectuer des transactions. En utilisant OP_CHECKTEMPLATEVERIFY, les processeurs de paiement à volume élevé peuvent regrouper tous leurs paiements en une seule transaction O(1) pour confirmation. Ensuite, quelque temps plus tard, lorsque la demande d'espace de bloc diminue, les paiements peuvent être étendus à partir de cet UTXO.

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

Ce scénario est un cas d'application typique proposé par la clause de restriction OP_CTV. D'autres cas d'application peuvent être trouvés sur https://utxos.org/uses/. En plus du contrôle de congestion ci-dessus, la page Web répertorie les paris Soft Fork, les options décentralisées, les chaînes de transmission, les canaux par lots, les canaux non interactifs, les pools miniers sans coordination et sans confiance, les coffres-forts, les limites de contrats verrouillés dans le temps haché plus sûrs (HTLCS), etc.

Sauter

Les coffres-forts sont un scénario d'application largement discuté dans les applications Bitcoin, en particulier dans le domaine des restrictions. Étant donné que les opérations quotidiennes doivent inévitablement équilibrer la nécessité de conserver des fonds et de les utiliser, les gens espèrent avoir un type d'application de coffre-fort qui peut garantir la sécurité des fonds et même restreindre l'utilisation des fonds même si le compte est piraté (fuite de clé privée).

Grâce à la technologie de mise en œuvre des clauses de restriction, les applications de type coffre-fort peuvent être créées relativement facilement.

Prenons comme exemple la conception de OP_VAULT : lors de la dépense de fonds dans le coffre-fort, une transaction doit d'abord être envoyée à la chaîne. Cette transaction indique l'intention de dépenser les fonds du coffre-fort, c'est-à-dire le déclencheur, et définit les conditions qui y sont associées :

• Si tout se passe bien, la deuxième transaction est la transaction de retrait finale. Après avoir attendu N blocs, les fonds peuvent être dépensés n'importe où.

• S'il est découvert que cette transaction a été volée (ou forcée lors d'une attaque de type « clé à molette »), elle peut être immédiatement envoyée à une autre adresse sécurisée (pour une garde plus sûre par l'utilisateur) avant que la transaction de retrait de N blocs ne soit envoyée.

Processus OP_VAULT, source : BIP-345

Il convient de noter qu'une application de coffre-fort peut être créée sans restrictions. Une solution envisageable consiste à utiliser la clé privée pour préparer la signature en vue d'une utilisation ultérieure, puis à détruire la clé privée. Cependant, de nombreuses restrictions subsistent, comme la nécessité de s'assurer que la clé privée a été détruite (comme dans le processus de configuration de confiance dans la preuve à connaissance nulle), le montant et les frais de traitement sont déterminés à l'avance (en raison de la pré-signature) et manquent donc de flexibilité.

Comparaison des processus OP_VAULT et Vault pré-signés, source : BIP-345

Des canaux d’État plus robustes et plus flexibles

On peut généralement penser que les canaux d'état, y compris le Lightning Network, ont presque la même sécurité que la chaîne principale (à condition que les nœuds puissent observer le dernier statut et puissent publier normalement le dernier statut sur la chaîne). Cependant, avec les restrictions, certaines nouvelles idées de conception de canaux d'état peuvent être plus robustes ou plus flexibles sur le Lightning Network. Parmi elles, les plus connues incluent Eltoo, Ark, etc.

Eltoo (également connu sous le nom de LN-Symmetry) en est un exemple typique. Cette solution technique reprend l'homonyme de L2 et propose une couche d'exécution pour le Lightning Network, permettant à tout état de canal ultérieur de remplacer l'état précédent sans avoir besoin d'un mécanisme de pénalité. Par conséquent, il peut également éviter aux nœuds du Lightning Network d'avoir à sauvegarder plusieurs états précédents pour empêcher les adversaires de faire le mal. Afin d'obtenir l'effet ci-dessus, Eltoo a proposé la méthode de signature SIGHASH_NOINPUT, à savoir APO (BIP-118).

Ark vise à réduire la difficulté de la liquidité entrante et de la gestion des canaux du Lightning Network. Il s'agit d'un protocole de type joinpool où plusieurs utilisateurs peuvent accepter un fournisseur de services comme contrepartie dans un certain laps de temps pour échanger des UTXO virtuels (vUTXO) hors chaîne, mais partager un UTXO sur la chaîne pour réduire les coûts. Similairement au coffre-fort, Ark peut également être implémenté sur le réseau Bitcoin actuel ; mais après avoir introduit des restrictions, Ark peut réduire la quantité d'interaction requise en fonction du modèle de transaction et obtenir une sortie unilatérale plus fiable.

Aperçu technique des restrictions

À partir des applications ci-dessus, nous pouvons voir que les clauses de restriction s'apparentent davantage à un effet qu'à une certaine technologie, il existe donc de nombreuses manières techniques de les mettre en œuvre. Si elles sont classées, elles peuvent inclure :

• Type : usage général, usage spécial

• Méthode d'implémentation : basée sur l'opcode, basée sur la signature

• Récursivité : récursive, non récursive

La récursivité signifie que si des clauses restrictives sont implémentées, la sortie de la transaction suivante peut être restreinte en restreignant la sortie suivante. Les restrictions ajoutées peuvent aller au-delà d'une transaction et atteindre une profondeur de transaction plus élevée.

Certaines conceptions de clauses de restriction populaires incluent :

* Récursivité : si combinée avec OP_CAT

Conception des clauses restrictives

D'après l'introduction précédente, nous pouvons voir que le script Bitcoin actuel restreint principalement les conditions de déverrouillage, mais ne restreint pas la manière dont l'UTXO peut être dépensé davantage. Pour mettre en œuvre la clause de restriction, nous devons y penser à l'envers : pourquoi le script Bitcoin actuel ne peut-il pas implémenter la clause de restriction ?

La raison principale est que le script Bitcoin actuel ne peut pas lire le contenu de la transaction elle-même, c'est-à-dire l'introspection de la transaction.

Si nous pouvons mettre en œuvre l’introspection des transactions – en inspectant tout contenu d’une transaction (y compris les sorties), alors nous pouvons mettre en œuvre des restrictions.

Par conséquent, les idées de conception des clauses restrictives tournent également principalement autour de la manière de parvenir à l’introspection.

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

L'idée la plus simple et la plus grossière est d'ajouter un ou plusieurs opcodes (c'est-à-dire un opcode + plusieurs paramètres, ou plusieurs opcodes avec des fonctions différentes) pour lire directement le contenu de la transaction. Ceci est également basé sur l'idée des opcodes.

Une autre idée consiste à utiliser le hachage du contenu de la transaction au lieu de lire et de vérifier directement le contenu de la transaction dans le script. Si le hachage a été signé, alors tant que le script est modifié pour vérifier la signature, comme OP_CHECKSIG, les clauses d'introspection et de restriction de la transaction peuvent être implémentées indirectement. Cette idée est basée sur la méthode de conception des signatures. Elle comprend principalement APO et OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) est une méthode de signature Bitcoin proposée. La manière la plus simple de signer est de valider à la fois l'entrée et la sortie d'une transaction, mais Bitcoin dispose d'une méthode plus flexible, SIGHASH, qui valide de manière sélective l'entrée ou la sortie d'une transaction.

La plage de signatures actuelle de SIGHASH et sa combinaison pour l'entrée et la sortie des transactions (Source : Mastering Bitcoin, 2e

Comme le montre la figure ci-dessus, en plus de ALL, qui s'applique à toutes les données, la méthode de signature NONE s'applique uniquement à toutes les entrées, pas aux sorties ; SINGLE est basée sur cela et s'applique uniquement aux sorties avec le même numéro de séquence d'entrée. De plus, SIGHASH peut également être combiné, et une fois le modificateur ANYONECANPAY superposé, il n'est applicable qu'à une seule entrée.

Cependant, les APO SIGHASH ne signent que la sortie, pas l'entrée. Cela signifie qu'une transaction signée avec APO peut être attachée à n'importe quel UTXO qui répond aux conditions.

Cette flexibilité constitue la base théorique de la clause de restriction de mise en œuvre de l'APO :

• Une ou plusieurs transactions peuvent être pré-créées

• Une clé publique qui ne peut générer qu’une seule signature est construite à partir des informations de ces transactions.

• De cette façon, tous les actifs envoyés à l’adresse de clé publique ne peuvent être dépensés que via des transactions pré-créées.

Il convient de noter que, comme cette clé publique n'a pas de clé privée correspondante, elle peut garantir que ces actifs ne peuvent être dépensés que par le biais de transactions pré-créées. Nous pouvons ensuite spécifier la destination des actifs dans ces transactions pré-créées, mettant ainsi en œuvre des clauses de restriction.

Nous pouvons mieux comprendre cela en le comparant aux contrats intelligents d’Ethereum : grâce aux contrats intelligents, nous ne pouvons retirer de l’argent de l’adresse du contrat 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 obtenir cet effet en améliorant le mécanisme de signature.

Le problème avec le processus ci-dessus est qu’il existe une dépendance circulaire dans le calcul car le contenu d’entrée doit être connu pour pré-signer et créer la transaction.

L'importance de l'implémentation de cette méthode de signature avec APO et SIGHASH_NOINPUT est qu'elle peut résoudre le problème de dépendance circulaire. Lors du calcul, il vous suffit de connaître (spécifier) toutes les sorties de la transaction.

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), ou BIP-119, adopte une approche améliorée de l'opcode. Il prend un hachage d'engagement comme paramètre et exige que toute transaction qui exécute l'opcode contienne un ensemble de sorties correspondant à cet engagement. Avec CTV, les utilisateurs de Bitcoin seront autorisés à restreindre la façon dont ils utilisent Bitcoin.

La proposition a été initialement introduite sous le nom OP_CHECKOUTPUTSHASHVERIFY (COSHV) et s'est d'abord concentrée sur la possibilité de créer des transactions contrôlées par la congestion. Les critiques de la proposition se sont donc également concentrées sur le fait que la solution n'était pas suffisamment générale et était trop spécifique au cas d'utilisation du contrôle de la congestion.

Dans le cas d'utilisation du contrôle de congestion mentionné ci-dessus, l'expéditeur Alice peut créer 10 sorties et hacher ces 10 sorties et utiliser le condensé résultant pour créer un script tapleaf contenant COSHV. Alice peut également utiliser les clés publiques des participants pour former une clé interne Taproot afin de leur permettre de collaborer sur les dépenses sans révéler le chemin du script Taproot.

Alice donne ensuite à chaque destinataire une copie des 10 sorties afin qu'ils puissent chacun vérifier la transaction de configuration d'Alice. Lorsqu'ils souhaitent ensuite dépenser ce paiement, chacun d'entre eux peut créer une transaction qui inclut la sortie validée.

Tout au long du processus, lorsqu'Alice crée et envoie la transaction de configuration, elle peut envoyer ces 10 copies de la sortie via des méthodes de communication asynchrones existantes telles que le courrier électronique ou les lecteurs 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/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

Similaires à l'APO, les adresses peuvent également être construites en fonction des conditions de dépenses, et les verrous peuvent être fabriqués de différentes manières, notamment : en ajoutant d'autres clés, des verrous horaires et une logique combinable.

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

Sur cette base, CTV a proposé qu'il soit possible de vérifier si la transaction de dépenses hachée correspond à la définition, c'est-à-dire d'utiliser les données de transaction comme clé pour ouvrir la serrure.

Nous pouvons étendre l'exemple de 10 destinataires ci-dessus. Le destinataire peut en outre définir sa clé d'adresse sur une transmission signée mais non diffusée à envoyer au prochain lot d'adresses de destinataires, et ainsi de suite, formant ainsi une structure arborescente comme illustré dans la figure ci-dessous. Alice peut construire un changement de solde de compte impliquant plusieurs utilisateurs en utilisant uniquement 1 espace de bloc utxo sur la chaîne.

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

Et si l'une des feuilles était un canal Lightning, un stockage à froid ou un autre chemin de paiement ? L'arbre passerait alors d'un arbre de dépenses unidimensionnel et multicouche à un arbre de dépenses multidimensionnel et multicouche, et les scénarios qu'il peut prendre en charge seront plus riches et plus flexibles.

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

Depuis sa proposition, CTV a été renommé COSHV en 2019, BIP-119 lui a été attribué en 2020, et le langage de programmation Sapio pour la création de contrats prenant en charge CTV a émergé. En 2022 et 2023, il a fait l'objet de nombreuses discussions et mises à jour au sein de la communauté, ainsi que de débats sur son plan d'activation. Il s'agit toujours de l'une des propositions de mise à niveau du soft fork qui fait l'objet de plus de discussions au sein de la communauté.

OP_CAT

Comme mentionné au début, OP_CAT est également une proposition de mise à niveau très populaire. Il implémente la fonction de concaténation de deux éléments dans la pile. Bien qu'il semble simple, OP_CAT peut implémenter de manière flexible de nombreuses fonctions dans le script.

L'exemple le plus direct est l'opération liée à l'arbre de Merkle. L'arbre de Merkle peut être compris comme deux éléments concaténés d'abord puis hachés. Actuellement, il existe des opcodes de hachage tels que OP_SHA 256 dans le script Bitcoin, donc si OP_CAT peut être utilisé pour concaténer deux éléments, la fonction de vérification de l'arbre de Merkle peut être implémentée dans le script, ce qui signifie qu'il a la capacité de vérification légère du client dans une certaine mesure.

L'autre base d'implémentation comprend également l'amélioration de la signature Schnorr : la condition de signature de dépense du script peut être définie comme la concaténation de la clé publique et du nonce public de l'utilisateur ; si le signataire veut signer une autre transaction pour dépenser les fonds ailleurs, il doit utiliser le même nonce, ce qui entraînera la fuite de la clé privée. C'est-à-dire que l'engagement envers le nonce est réalisé via OP_CAT, ce qui garantit la validité de la transaction signée.

D'autres scénarios d'application d'OP_CAT incluent : Bistream, signature d'arbre, signature Lamport résistante quantique, coffre-fort, etc.

OP_CAT en soi n'est pas une nouvelle fonctionnalité. Elle existait dans les premières versions de Bitcoin, mais elle a été désactivée en 2010 car elle pouvait être exploitée par des attaques. Par exemple, l'utilisation répétée de OP_DUP et OP_CAT peut facilement provoquer l'explosion de la pile d'un nœud complet lors du traitement de tels scripts, comme le montre cette démo.

Mais le problème d'explosion de pile mentionné ci-dessus ne se produira-t-il pas si OP_CAT est réactivé maintenant ? Étant donné que la proposition OP_CAT actuelle implique uniquement son activation dans tapscript, et que tapscript limite chaque élément de pile à 520 octets maximum, elle ne provoquera pas le problème d'explosion de pile précédent. Certains développeurs pensent également que la désactivation directe d'OP_CAT par Nakamoto peut être trop sévère. Cependant, en raison de la flexibilité d'OP_CAT, certains scénarios d'application peuvent en effet conduire à des vulnérabilités qui ne peuvent pas être épuisées à l'heure actuelle.

Par conséquent, compte tenu des scénarios d'application et des risques potentiels, OP_CAT a récemment fait l'objet d'une grande attention et a également fait l'objet d'un examen PR. Il s'agit de l'une des propositions de mise à niveau les plus populaires à l'heure actuelle.

Conclusion

L'autodiscipline apporte la liberté. À partir de l'introduction ci-dessus, nous pouvons voir que les clauses de restriction peuvent être directement implémentées dans le script Bitcoin pour limiter les dépenses ultérieures de la transaction, réalisant ainsi des règles de transaction similaires à l'effet des contrats intelligents. Par rapport aux méthodes hors chaîne telles que BitVM, cette méthode de programmation peut être vérifiée de manière plus native sur Bitcoin et peut également améliorer les applications sur la chaîne principale (contrôle de congestion), les applications hors chaîne (canaux d'état) et d'autres nouvelles directions d'application (pénalités de jalonnement, etc.).

Si la technologie d'implémentation des restrictions peut être combinée avec certaines mises à niveau sous-jacentes, elle libérera encore davantage le potentiel de programmabilité. Par exemple, la proposition d'opérateurs 64 bits dans revoir récemment, il peut être combiné avec les clauses de restriction OP_TLUV proposées ou d'autres clauses de restriction pour programmer en fonction du nombre de satoshis dans la sortie de transaction.

Cependant, les restrictions peuvent également conduire à des abus ou des failles imprévus, c'est pourquoi la communauté est prudente à ce sujet. De plus, la mise à niveau des restrictions nécessite également une mise à niveau en soft fork des règles de consensus. Compte tenu de la situation lors de la mise à niveau de la racine pivotante, la mise à niveau des restrictions peut également prendre un certain temps.

Merci à Ajian, Fisher et Ben pour avoir relu et fourni des suggestions sur cet article !

Les 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/en/topics/op_cat/

OP_CAT:

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md

Astuces CAT et Schnorr : https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Cet article provient d'Internet : HashKey Capital Research Report : Covenants, la programmabilité du Bitcoin

En relation : La pièce de monnaie BONK est susceptible de subir une baisse de 50% en raison de signaux baissiers

En bref Le prix de Bonk est dans un coin descendant et la ligne de tendance inférieure sera probablement testée à nouveau. Cela entraînerait un potentiel drawdown de 50%, que les signaux du marché plus large soutiennent. Les détenteurs de BONK parient également sur une baisse des prix puisque les taux de financement sont très négatifs. Bonk n'a pas réussi à franchir une ligne de tendance de résistance clé, ce qui aurait permis à la pièce mème d'échapper à une nouvelle baisse. Cependant, en regardant le coin descendant dans lequel BONK est coincé, cela justifie un autre drawdown. Ce sentiment est également partagé par les investisseurs qui placent des paris courts sur la pièce mème. Le taux de financement de Bonk baisse à nouveau Au moment de la rédaction de cet article, le prix de Bonk est au-dessus d'une ligne de support importante de $0.00002153. Ce niveau a été testé plusieurs fois dans le passé, mais cette fois-ci, le…