Lier des clés cryptographiques à des identités est un problème depuis l'introduction de la technologieLe défi consiste à fournir et à maintenir une correspondance publiquement disponible et cohérente entre les identités et les clés publiques (auxquelles ces identités ont la clé privée). Sans une telle correspondance, les messages destinés à être secrets peuvent aller de travers - parfois avec des conséquences désastreuses. Ce même défi existe dans le web3.

Trois solutions possibles existent actuellement. Les deux approches classiques sont un répertoire de clés publiques et le chiffrement basé sur l'identité. La troisième est le chiffrement basé sur l'enregistrement, qui était jusqu'à récemment entièrement théorique. Les trois approches offrent différents compromis entre l'anonymat, l'interactivité et l'efficacité, ce qui peut sembler clair au départ, mais le contexte de la blockchain introduit de nouvelles possibilités et contraintes. L'objectif de cet article est donc d'explorer cet espace de conception et de comparer ces approches lorsqu'elles sont déployées sur une blockchain. Lorsque les utilisateurs ont besoin de transparence et d'anonymat sur la chaîne, un schéma pratique de chiffrement basé sur l'enregistrement est le grand gagnant, surmontant l'hypothèse de confiance forte du chiffrement basé sur l'identité, mais à un coût.

Les trois approches en bref

L'approche classique de la liaison des clés cryptographiques aux identités est une infrastructure de clé publique (ICP), avec un annuaire de clés publiques au cœur. Cette approche nécessite qu'un expéditeur potentiel interagisse avec un tiers de confiance (le gestionnaire de l'annuaire ou l'autorité de certification) pour envoyer des messages. De plus, dans le cadre du web2, la maintenance de cet annuaire peut être coûteuse, fastidieuse et...sujet aux erreurs, et les utilisateurs courent le risque de abus par l'autorité de certification.

Les cryptographes ont suggéré des alternatives pour contourner les problèmes avec les PKI. En 1984, Adi Shamir a suggéréchiffrement basé sur l'identité (IBE), dans lequel l'identifiant d'une partie - numéro de téléphone, e-mail, nom de domaine ENS - sert de clé publique. Cela élimine le besoin de maintenir un annuaire de clés publiques mais implique l'introduction d'un tiers de confiance (le générateur de clés). Dan Boneh et Matthew Franklin ont donné le première construction pratique IBEen 2001, mais l'IBE n'a pas été largement adopté sauf dans des écosystèmes fermés tels que les entreprises ou lesdéploiements gouvernementaux, peut-être en raison de l'hypothèse de confiance forte. (Comme nous le verrons ci-dessous, cette hypothèse peut être partiellement atténuée en s'appuyant plutôt sur un quorum de parties de confiance, ce que peut facilement faciliter une blockchain).

Une troisième option, le chiffrement basé sur l'enregistrement (RBE), était proposéen 2018. RBE maintient la même architecture générale que l'IBE mais remplace le générateur de clé de confiance par un "conservateur de clé" transparent qui ne réalise que des calculs sur des données publiques (plus précisément, il accumule des clés publiques dans une sorte de "digest" publiquement disponible). La transparence de ce conservateur de clés rend l'environnement blockchain - où un smart contract peut remplir le rôle du conservateur - particulièrement adapté à RBE. RBE était théorique jusqu'en 2022, lorsque mes co-auteurs et moi avons introduit le première construction RBE pratiquement efficace.

Évaluer les compromis

Cet espace de conception est complexe, et comparer ces schémas nécessite de prendre en compte de nombreuses dimensions. Pour simplifier les choses, je vais faire deux hypothèses:

1. Les utilisateurs ne mettent pas à jour ou révoquent leurs clés.
2. Le contrat intelligent n'utilise aucun service de disponibilité de données hors chaîne (DAS) ou données blob.

Je discuterai à la fin de la façon dont chacune de ces considérations supplémentaires pourrait affecter nos trois solutions potentielles.

Répertoire de clés publiques

Résumé: Tout le monde peut ajouter une entrée (id, pk) à une table on-chain (le répertoire) en appelant le contrat intelligent, à condition que l'identifiant n'ait pas encore été revendiqué.

Un PKI décentralisé est essentiellement un smart contract qui maintient un répertoire d'identités et de leurs clés publiques correspondantes. Par exemple, le Registre du Service de Noms Ethereum (ENS)maintient une correspondance entre les noms de domaine ("identités") et leurs métadonnées correspondantes, y compris les adresses auxquelles ils se résolvent (à partir des transactions desquelles une clé publique peut être dérivée). Un PKI décentralisé fournirait une fonctionnalité encore plus simple : la liste maintenue par le contrat stockerait uniquement la clé publique correspondant à chaque ID.

Pour s'inscrire, un utilisateur génère une paire de clés (ou utilise une paire de clés précédemment générée) et envoie son ID et sa clé publique au contrat (peut-être avec un paiement). Le contrat vérifie que l'ID n'a pas encore été revendiqué et, le cas échéant, ajoute l'ID et la clé publique à l'annuaire. À ce stade, n'importe qui peut chiffrer un message à un utilisateur enregistré en demandant au contrat la clé publique correspondant à un ID. (Si l'expéditeur a déjà chiffré quelque chose pour cet utilisateur, il n'a pas besoin de demander au contrat à nouveau.) Avec la clé publique, l'expéditeur peut chiffrer son message comme d'habitude et envoyer le texte chiffré au destinataire, qui peut utiliser la clé secrète correspondante pour récupérer le message.)

Jetons un coup d'œil aux propriétés de cette méthode.

Du côté négatif du grand livre :

• Pas succinct. Le répertoire complet des clés doit être stocké sur la chaîne afin qu'il soit toujours disponible pour tous (rappelez-vous, pour l'instant nous supposons qu'il n'y a pas de DAS). Pour les ~900K noms de domaine uniques enregistrés dans ENS au moment de la rédaction, cela signifie près de 90 Mo de stockage persistant. Les parties enregistrantes doivent payer pour le stockage que leur entrée occupe, environ 65K de gaz (actuellement environ 1 $ - voir l'évaluation des performances ci-dessous).
• Cryptage quelque peu interactif. L’expéditeur doit lire la chaîne pour récupérer la clé publique d’un utilisateur, mais uniquement si c’est la première fois que l’expéditeur chiffre un message à cet utilisateur particulier. (N’oubliez pas que nous supposons que les utilisateurs ne mettent pas à jour ou ne révoquent pas leurs clés.)
• Pas anonyme pour l'expéditeur. Lorsque vous récupérez la clé publique de quelqu'un, vous vous liez à ce destinataire, ce qui indique que vous avez une sorte de relation avec lui. Imaginez par exemple que vous récupériez la clé publique de WikiLeaks : cela pourrait créer une suspicion selon laquelle vous divulgueriez des documents classifiés. Ce problème pourrait être atténué avec du "trafic de couverture" (récupérer un grand lot de clés, dont la plupart ne sont pas destinées à être utilisées) ou de manière similaire en exécutant un nœud complet, ou avec une recherche d'informations privées (PIR).

Du bon côté :

• Déchiffrement non interactif. Les utilisateurs déchiffrent les messages avec leur clé secrète stockée localement, il ne nécessite donc aucune interaction.
• Transparent. La liste des utilisateurs et des clés est entièrement publique, donc n'importe qui peut vérifier s'ils ont été enregistrés correctement ou non.
• Jeu d’ID arbitraire. Le domaine des ID n’est pas limité a priori par la construction ; en théorie, l’ID peut être un chaîne arbitraire (dans la limite des contraintes imposées par la mise en œuvre et le stockage du contrat spécifique).

Quand pourriez-vous avoir besoin d'utiliser un annuaire de clés publiques? Un annuaire de clés publiques décentralisé est facile à mettre en place et à gérer, c'est donc un bon choix de base. Cependant, si les coûts de stockage ou la confidentialité sont une préoccupation, l'une des autres options ci-dessous pourrait être un meilleur choix.

(Threshold) Chiffrement basé sur l'identité (IBE)

Résumé : L'identité d'un utilisateur est sa clé publique. Une tierce partie ou plusieurs tierces parties de confiance sont nécessaires pour émettre des clés et détenir un secret maître (porte dérobée) pendant toute la durée du système.

Dans IBE, un utilisateur ne génère pas sa propre paire de clés, mais s’inscrit auprès d’un générateur de clés approuvé. Le générateur de clés a une paire de clés « maîtresse » (msk, mpk dans la figure). À partir de l’ID d’un utilisateur, le générateur de clés utilise la clé secrète principale msk et l’ID pour calculer une clé secrète pour l’utilisateur. Cette clé secrète doit être communiquée à l’utilisateur par un canal sécurisé (qui peut être établi à l’aide d’un Protocole d’échange de clés).

IBE optimise l'expérience de l'expéditeur : il télécharge une fois le mpk du générateur de clés, après quoi il peut chiffrer un message vers n'importe quel ID en utilisant l'ID lui-même. Le déchiffrement est également simple : un utilisateur enregistré peut utiliser la clé secrète qui lui a été délivrée par le générateur de clés pour déchiffrer le texte chiffré.

La clé secrète principale du générateur de clés est plus persistante que la clé secrète « déchets toxiques » générés par les cérémonies de configuration de confianceutilisé pour certains SNARKs. Le générateur de clés en a besoin pour émettre de nouvelles clés secrètes, donc le générateur de clés ne peut pas l'effacer après la configuration, comme le font les participants aux cérémonies SNARK. C'est aussi une information dangereuse. Quiconque dispose du msk peut décrypter tous les messages envoyés à n'importe quel utilisateur du système. Cela signifie qu'il y a un risque constant d'exfiltration avec des conséquences catastrophiques.

Même si la msk est conservée en sécurité, chaque utilisateur qui s'inscrit dans le système doit faire confiance au générateur de clés pour ne pas lire ses messages, car le générateur de clés peut conserver une copie de la clé secrète de l'utilisateur ou la recalculer à partir de la msk à tout moment. Il pourrait même être possible pour le générateur de clés de délivrer une clé secrète défectueuse ou «contrainte» à l'utilisateur qui décrypte tous les messages sauf certains interdits tels que déterminés par le générateur de clés.

Cette confiance peut être répartie entre un quorum de générateurs de clés, de sorte qu'un utilisateur n'ait besoin de faire confiance qu'à un nombre seuil d'entre eux. Dans ce cas, un petit nombre de générateurs de clés malveillants ne peuvent pas récupérer de clés secrètes ou calculer de mauvaises clés, et un attaquant devrait s'introduire dans plusieurs systèmes pour voler le secret maître complet.

Si les utilisateurs sont d'accord avec cette hypothèse de confiance, (seuil) l'IBE offre de nombreux avantages :

• Stockage constant/minimal sur la chaîne. Seule la clé publique principale (un seul élément de groupe) doit être stockée sur la chaîne. Cela représente beaucoup moins de stockage que celui requis par un annuaire de clés publiques sur la chaîne. Pour l'IBE Boneh-Franklin sur la courbe BN254, cela signifie ajouter 64 octets de stockage persistant sur la chaîne une fois pendant la phase de configuration, ce qui permet au service de ne dépenser que 40K de gaz.
• Chiffrement non interactif. Un expéditeur a seulement besoin de la clé publique principale (qu'il télécharge une fois au début) et de l'identifiant du destinataire pour crypter un message. Ceci est en contraste avec l'annuaire de clés publiques, où il aurait besoin de récupérer une clé pour chaque nouvel utilisateur avec lequel il souhaite communiquer.
• Déchiffrement non interactif. Les utilisateurs utilisent à nouveau leurs clés secrètes stockées localement pour déchiffrer les messages.
• Expéditeur anonyme. L'expéditeur n'a pas besoin de récupérer d'informations spécifiques au destinataire de la chaîne. En comparaison, dans le cas d'un registre de clés publiques, l'expéditeur doit interagir avec le contrat d'une manière qui dépend du destinataire.
• Ensemble d'ID arbitraire. Comme dans le registre de clés publiques, les ID peuvent être des chaînes arbitraires.

Mais !

• Fortes hypothèses de confiance. Contrairement au registre de clés publiques, où les utilisateurs génèrent leurs propres clés, l'IBE nécessite une partie de confiance ou un quorum de parties avec un secret principal (piège) pour émettre des clés. Le secret principal doit être conservé pendant toute la durée de vie du système et peut compromettre tous les messages des utilisateurs enregistrés s'il est jamais divulgué ou mal utilisé.

Quand pourriez-vous vouloir utiliser (seuil) IBE? Si un tiers de confiance ou des tiers sont disponibles et que les utilisateurs sont prêts à leur faire confiance, l'IBE offre une option beaucoup plus économique en termes d'espace (et donc moins chère) par rapport à un registre de clés on-chain.

Chiffrement basé sur l'inscription (RBE)

Résumé : Comme pour IBE, l’identité d’un utilisateur sert de clé publique, mais le tiers/quorum de confiance est remplacé par un accumulateur transparent (appelé « curateur de clé »).

Dans cette section, je vais discuter de la construction efficace de RBE à partir de mon papier, car contrairement à la (à ma connaissance) Seulement d’autres constructions pratiques, il est actuellement déployable sur une blockchain (étant basé sur l’appariement au lieu d’être basé sur un treillis). Chaque fois que je dis « RBE », je fais référence à cette construction particulière, bien que certaines affirmations puissent être vraies pour RBE en général.

Dans RBE, un utilisateur génère sa propre paire de clés et calcule des « valeurs de mise à jour » (a dans la figure) dérivées de la clé secrète et de la chaîne de référence commune (CRS). Bien que la présence d’un CRS signifie que la configuration n’est pas complètement non approuvée, le CRS est un puissances-de-tauconstruction, qui peut êtreCalculé de manière collaborative sur la chaîne et est sécurisé tant qu'il y a eu une seule contribution honnête.

Le contrat intelligent est configuré pour un nombre attendu d’utilisateurs N, regroupés en compartiments. Lorsqu’un utilisateur s’inscrit dans le système, il envoie son ID, sa clé publique et ses valeurs de mise à jour au contrat intelligent. Le contrat intelligent maintient un ensemble de paramètres publics pp (distincts du CRS), qui peuvent être considérés comme un « condensé » succinct des clés publiques de toutes les parties enregistrées dans le système. Lorsqu’il reçoit une demande d’enregistrement, il effectue une vérification des valeurs de mise à jour et multiplie la clé publique dans le compartiment approprié de pp.

Les utilisateurs enregistrés doivent également conserver localement certaines « informations auxiliaires », qu’ils utilisent pour aider au déchiffrement et qui sont ajoutées à chaque fois qu’un nouvel utilisateur s’inscrit dans le même compartiment. Ils peuvent le mettre à jour eux-mêmes en surveillant la blockchain pour les enregistrements dans leur compartiment, ou le contrat intelligent peut aider en maintenant une liste des valeurs de mise à jour qu’il a reçues des enregistrements les plus récents (par exemple, au cours de la dernière semaine), que les utilisateurs peuvent extraire périodiquement (au moins une fois par semaine).

Dans ce système, les expéditeurs téléchargent le CRS une seule fois et téléchargent occasionnellement la version la plus récente des paramètres publics. Pour les paramètres publics, tout ce qui compte du point de vue de l’expéditeur est qu’ils incluent la clé publique du destinataire prévu ; Il n’est pas nécessaire qu’il s’agisse de la version la plus récente. L’expéditeur peut ensuite utiliser le CRS et les paramètres publics, ainsi que l’ID du destinataire, pour chiffrer un message envoyé au destinataire.

Lors de la réception d'un message, l'utilisateur vérifie les informations auxiliaires stockées localement pour une valeur satisfaisant à certaines conditions. (S'il n'en trouve aucune, cela signifie qu'il doit récupérer une mise à jour depuis le contrat.) À l'aide de cette valeur et de sa clé secrète, l'utilisateur peut décrypter le texte chiffré.

Clair, ce schéma est plus complexe que les deux autres. Mais il nécessite moins de stockage on-chain que l'annuaire de clés publiques tout en évitant l'hypothèse de confiance forte de l'IBE.

• Paramètres concis. La taille des paramètres à stocker on-chain est sous-linéaire en fonction du nombre d'utilisateurs. C'est beaucoup plus petit que le stockage total requis pour un annuaire de clés publiques (linéaire en fonction du nombre d'utilisateurs), mais ce n'est toujours pas constant et donc moins bon par rapport à IBE.
• Cryptage quelque peu interactif. Pour envoyer un message, un expéditeur a besoin d’une copie des paramètres publics qui contient le destinataire prévu. Cela signifie qu’il doit mettre à jour les paramètres à un moment donné après l’enregistrement d’un destinataire prévu, mais pas nécessairement pour chaque destinataire prévu qui s’enregistre, car une mise à jour peut inclure les clés de plusieurs destinataires. Dans l’ensemble, l’envoi de messages est plus interactif que l’IB, mais moins interactif qu’un annuaire.
• Un chiffrement quelque peu interactif. Semblable au cas du chiffrement, le destinataire a besoin d'une copie des informations auxiliaires qui "correspond" à la version des paramètres publics utilisée pour le chiffrement. Plus précisément, à la fois le paramètre public et les seaux auxiliaires sont mis à jour chaque fois qu'un nouvel utilisateur s'inscrit dans ce seau, et la valeur capable de décrypter un texte chiffré est celle correspondant à la version pp utilisée pour chiffrer. Comme les mises à jour des paramètres publics, un utilisateur peut décider de récupérer les mises à jour des seaux auxiliaires seulement périodiquement, sauf en cas d'échec de décryptage. Contrairement aux mises à jour des paramètres publics, récupérer plus souvent les mises à jour des seaux auxiliaires ne divulgue pas nécessairement d'informations.
• Expéditeur-anonyme. Comme dans le cas de l'annuaire, l'expéditeur peut chiffrer un message entièrement par lui-même (à condition qu'il dispose de paramètres à jour) sans demander d'informations spécifiques au destinataire. Les informations lues sur la chaîne, le cas échéant, sont indépendantes du destinataire prévu. (Pour réduire la communication, l'expéditeur pourrait demander uniquement un certain compartiment pp, divulguant des informations partielles.)
• Transparent. Bien que le système doit être configuré en utilisant une cérémonie de configuration de confiance (potentiellement distribuée et/ou administrée de l'extérieur) produisant une CRS perforée, il ne repose sur aucun parti ou quorum de confiance une fois la configuration terminée : bien qu'il repose sur un tiers coordinateur (le contrat), il est entièrement transparent et n'importe qui peut être un coordinateur ou vérifier qu'il se comporte honnêtement en confirmant ses transitions d'état (c'est pourquoi il peut être implémenté en tant que contrat intelligent). De plus, les utilisateurs peuvent demander une preuve de (non-)appartenance succincte pour vérifier s'ils (ou quelqu'un d'autre) sont enregistrés ou non dans le système. Cela contraste avec le cas de l'IBE, où il est difficile pour le parti/parties de confiance de prouver qu'ils n'ont pas révélé secrètement une clé de déchiffrement (à eux-mêmes en faisant une copie secrète ou à quelqu'un d'autre). Le répertoire de clés publiques, en revanche, est entièrement transparent.
• Ensemble d'identifiants restreints. J'ai décrit une version «basique» de la construction RBE. Pour déterminer de manière transparente dans quel compartiment tombe un ID, les IDs doivent avoir un ordre public et déterministe. Les numéros de téléphone peuvent simplement être classés par ordre, mais classer des chaînes arbitraires est difficile, voire impossible, car le nombre de compartiments peut être extrêmement grand ou non borné. Cela pourrait être atténué en offrant un contrat séparé qui calcule une telle correspondance ou en adoptant l'approche de hachage cuckoo proposée dans Gate.io.ce travail de suivi.

Avec des extensions :

• Destinataire-anonyme. le schéma peut être étendu de sorte que les textes chiffrés ne révèlent pas l'identité du destinataire.

Quand pourriez-vous utiliser RBE ? RBE utilise moins de stockage on-chain qu’un registre on-chain tout en évitant les hypothèses de confiance fortes requises par IBE. Par rapport à un registre, RBE offre également des garanties de confidentialité plus fortes à l’expéditeur. Cependant, étant donné que RBE vient tout juste de devenir une option viable pour la gestion des clés, nous ne savons pas encore quels scénarios bénéficieraient le plus de cette combinaison de propriétés. S’il vous plaît faites moi savoir si vous avez des idées.

Comparaison des performances

J’ai estimé les coûts (au 30 juillet 2024) du déploiement de chacune de ces trois approches on-chain dans ce cahier Colab. Les résultats pour une capacité système d'environ 900 000 utilisateurs (le nombre de noms de domaine uniques enregistrés dans ENS au moment de la rédaction) sont présentés dans le tableau ci-dessous.

PKI n'a pas de coût de configuration et un faible coût d'enregistrement par utilisateur, tandis que l'IBE a un faible coût de configuration et un coût d'enregistrement pratiquement gratuit par utilisateur. RBE a un coût de configuration plus élevé et également un coût d'enregistrement étonnamment élevé, malgré le faible stockage en chaîne requis.

La majeure partie du coût d’enregistrement (en supposant que le calcul soit effectué sur une L2) provient du fait que les parties doivent mettre à jour une partie des paramètres publics dans le stockage persistant, ce qui représente un coût d’enregistrement élevé.

Bien que RBE soit plus cher que les alternatives, cette analyse montre qu’il est possible de le déployer sur le réseau principal d’Ethereum aujourd’hui, sans les hypothèses de confiance potentiellement risquées de PKI ou d’IBE. Et c’est sans compter les optimisations telles que le déploiement de plusieurs instances plus petites (et donc moins chères) ou l’utilisation de données d’objets blob. Étant donné que le RBE présente des avantages par rapport à l’annuaire à clés publiques et à l’IBE sous la forme d’un anonymat plus fort et d’hypothèses de confiance réduites, il pourrait être attrayant pour ceux qui accordent de l’importance à la confidentialité et aux configurations sans confiance.

Noemi Glaeser est une candidate au doctorat en informatique à l'Université du Maryland et à l'Institut Max Planck pour la sécurité et la confidentialité. Elle a été stagiaire de recherche chez a16z crypto pendant l'été '23. Elle est une récipiendaire de la bourse de recherche aux cycles supérieurs de la NSF et a précédemment été stagiaire de recherche chez NTT Research.

Annexe : Considérations supplémentaires

Traitement des mises à jour / révocations de clés

Dans le cas d'un répertoire de clés publiques, la gestion des mises à jour et des révocations de clés est simple : pour révoquer une clé, une partie demande au contrat de l'effacer du répertoire. Pour mettre à jour une clé, l'entrée (id, pk) est écrasée par une nouvelle clé (id, pk').

Pour la révocation dans IBE, Boneh et Franklin ont suggéré que les utilisateurs mettent périodiquement à jour leurs clés (par exemple, chaque semaine) et que les expéditeurs incluent la période actuelle dans la chaîne d’identité lors du chiffrement (par exemple, « Bob »). En raison de la nature non interactive du chiffrement, les expéditeurs n’ont aucun moyen de savoir quand un utilisateur révoque sa clé, de sorte que certaines mises à jour périodiques sont inhérentes. Boldyreva, Goyal et Kumar ont donné un mécanisme de révocation plus efficace fondé sur IBE flouce qui nécessite deux clés pour le déchiffrement: une clé d'“identité” et une clé d'“heure” supplémentaire. De cette manière, seule la clé d'heure doit être mise à jour régulièrement. Les clés d'heure des utilisateurs sont accumulées dans un arbre binaire, et un utilisateur peut utiliser n'importe quel nœud le long du chemin (dans le cas de base, seul le nœud racine est nécessaire et c'est la seule partie qui est publiée par le générateur de clés). La révocation de clé est réalisée en ne publiant plus de mises à jour pour un utilisateur particulier (en supprimant les nœuds le long du chemin de cet utilisateur de l'arbre), auquel cas la taille de la mise à jour augmente mais n'est jamais supérieure à logarithmique en fonction du nombre d'utilisateurs.

Notre construction RBE efficace n'a pas pris en compte les mises à jour et les révocations, unetravail de suivifournit un compilateur qui peut « améliorer » notre schéma pour ajouter ces fonctionnalités.

Déplacer les données hors chaîne avec DAS

Utiliser une solution de disponibilité des données (DAS) pour déplacer le stockage en chaîne hors chaîne n'affecterait que le calcul du répertoire de clés publiques et du RBE, réduisant les deux au même volume de stockage en chaîne. Le RBE conserverait l'avantage d'être plus privé pour l'expéditeur, car il évite toujours de divulguer l'identité du destinataire via les motifs d'accès. L'IBE avait déjà un stockage minimal en chaîne et ne bénéficierait pas du DAS.

Avertissement:

1. Cet article est repris à partir de [ a16zcrypto], Tous les droits d'auteur appartiennent à l'auteur original [ Noemi Glaeser ]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe, et ils le géreront rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux 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 Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.