*Faites suivre l'Original Titre‘How ZKP and ZK-Rollups help solve the scalability problem: a review of the zkSync blockchain’

Dans cet article, nous expliquerons ce qu'est la technologie de preuve de connaissance nulle et parlerons d'une blockchain populaire - zkSync : comment les transactions fonctionnent dans zkSync et les principales différences avec la machine virtuelle Ethereum (EVM). Nous discuterons également des avantages et inconvénients de cette blockchain, qui, selon nous, pourrait avoir un avenir prometteur.

ZkSync est une blockchain de deuxième niveau (Layer 2 — L2) pour Ethereum, conçue pour résoudre les problèmes de frais élevés et de débit limité (Transactions Par Seconde — TPS) sur le réseau Ethereum. Cette plateforme utilise la technologie ZK-Rollup, qui utilise des Preuves de Connaissance Zéro (ZKP) pour regrouper plusieurs transactions en dehors du réseau principal (L1). Seules les preuves cryptographiques de la justesse des transactions et leurs données compressées sont envoyées à L1, améliorant significativement l'efficacité et réduisant les coûts.

Développé par Matter Labs, zkSync est annoncé comme un produit entièrement open source (100% open source), géré par la communauté. Selon Cryptorank, le projet a déjà attiré l'attention, levant des investissements de 458 millions de dollars. À long terme, Matter Labs vise à créer un écosystème complet. Actuellement, deux blockchains sont opérationnelles : zkSync Lite, qui traite les paiements en ETH et en jetons ERC20, et zkSync Era, prenant en charge des contrats intelligents à part entière. Les projets futurs comprennent le lancement d'un système hyperchain (L3), garantissant une haute sécurité. L'objectif de Matter Labs est de mettre à l'échelle la technologie à un niveau qui attirera les prochains milliards d'utilisateurs de blockchain.

Contexte

ZkSync représente une nouvelle approche pour résoudre le problème de scalabilité connu sous le nom detrilemme de la blockchainCe projet, comme d'autres solutions de couche 2 (L2), cherche à trouver un équilibre entre sécurité, évolutivité et décentralisation dans les réseaux blockchain.

1. Scalabilité : La capacité d'un système à gérer efficacement un volume croissant de transactions ou de données sans perdre en performance et en sécurité.
2. Sécurité de la blockchain : garantir la fiabilité et la protection des données contre l'accès non autorisé, la manipulation ou les modifications.
3. Décentralisation : L'absence d'une structure de contrôle centralisée. Dans un système décentralisé, la gestion et la prise de décision sont démocratiquement réparties entre tous les participants du réseau.

Ethereum met l'accent sur la sécurité et la décentralisation, en mettant l'accent sur son statut en tant que protocole pair à pair avec des nœuds répartis dans le monde entier. Pour les dernières informations sur la distribution des nœuds, consultezNodeWatch.

Pour maintenir la décentralisation dans le réseau, chaque nœud doit vérifier toutes les transactions. Cela ralentit intrinsèquement le réseau. De plus, sous une charge réseau élevée, les transactions peuvent devenir assez coûteuses et nécessiter un temps significatif pour être traitées.

Couche 2

La tâche principale pour augmenter le TPS du réseau Ethereum sans augmenter la charge sur les nœuds a été l'introduction de Shardingen combinaison avec la transition vers un consensus PoS (Preuve d'enjeu). Cela impliquait de diviser les validateurs en sous-groupes pour traiter des segments séparés du réseau, réduisant ainsi la charge globale et augmentant le débit. Cependant, la communauté s'est concentrée sur les solutions de Couche 2, compte tenu de leur développement rapide.

En plus de l'idée de mettre en œuvre le Sharding dans Ethereum, d'autres solutions de scalabilité ont émergé, telles que :

• Paiement et canaux d'état
• Sidechains
• Plasma
• Optimistic Rollup

Ainsi que des technologies basées sur des preuves de zéro connaissance (ZKP), y compris :

• Validium
• zkRollup
• Volonté

Des informations plus détaillées peuvent être trouvées ici.

Bien que le Sharding soit encore en développement, le hardfork de Dencun est prévu pour début 2024, ce qui implémentera Proto-Danksharding. Cette étape intermédiaire vise à améliorer les solutions de couche 2, rendant le stockage de données sur L1 plus économique. Ainsi, Proto-Danksharding promet de réduire les coûts de transaction sur L2, comme une étape vers une solution de Sharding à part entière.

À première vue, les blockchains L2 peuvent sembler similaires, car leur tâche principale est d'augmenter le nombre de transactions en dehors de L1 tout en déléguant le rôle de garant de sécurité à L1. Les développeurs de telles blockchains prétendent souvent que leurs solutions sont les plus rapides, les plus fiables et les plus simples. En réalité, chaque approche de mise à l'échelle a ses subtilités et des compromis inévitables concernant la vitesse des transactions, le niveau de sécurité ou le degré de décentralisation. Des solutions entièrement centralisées sont également courantes. Tous ces aspects nous ramènent aux problèmes fondamentaux du trilemme de la blockchain.

Danscet article, les critères clés pour évaluer les protocoles utilisés dans les solutions de couche 2 sont proposés. Ils comprennent:

• sécurité,
• performance et efficacité économique,
• facilité d'utilisation,
• des aspects supplémentaires tels que le support des contrats intelligents, la compatibilité du bytecode EVM et les options de confidentialité.

Important ! L'article est rédigé par Matter Labs et, à mon avis, certaines choses sont "étirées" en faveur de zkRollup (étant donné qu'il y a un conflit d'intérêts évident), mais ce n'est pas si important, l'essentiel est de voir quelles différences existent entre les protocoles de couche 2.

Ci-dessous, je vais fournir un tableau, et ici je vais brièvement décrire son contenu.

Sécurité

• Hypothèse de la vivacité ou de la "viabilité" de la couche 2. On suppose que pour maintenir la fonctionnalité de la couche 2, certains participants seront toujours en ligne au niveau de la couche 1 pour répondre à d'éventuels cas de fraude. Il s'agit soit de validateurs qui bloquent une certaine somme de fonds (marquée comme "Engagée" dans le tableau) sur L1, soit de tiers qui garantissent la sécurité du protocole en échange d'une récompense. Comme le montre le tableau, les solutions utilisant ZKP (Validium et zkRollup) n'ont pas cette nécessité.
• Problème de sortie massive. Un problème qui se pose s'il est nécessaire, pour des raisons de sécurité, d'initier le retrait des fonds par tous les utilisateurs de L2 à L1. Comme on peut le voir dans le tableau, ce problème n'existe qu'avec le protocole Plasma, sur lequel on peut en savoir plus.ici.
• Gardiennage. La question de savoir si les validateurs de L2 peuvent temporairement bloquer ou confisquer les fonds des utilisateurs.
• Vulnérabilités économiques. Comprend diverses attaques contre les validateurs de la couche 2, y compris la corruption des mineurs de la couche 1, la création de DAO "fantômes" et d'autres attaques motivées économiquement.
• Cryptographie. La différence entre les primitives cryptographiques standard et nouvelles. Les primitives standard sont plus étudiées et potentiellement vulnérables, tandis que les nouvelles (telles que SNARK et STARK) offrent une fiabilité accrue mais nécessitent des connaissances supplémentaires et des audits de la part des développeurs.

Performance et Économie

En ce qui concerne les performances, c'est simple. TPS (Transactions Par Seconde) indique le débit du réseau, et dans le contexte de l'évolutivité, c'est le paramètre le plus crucial.

Aspects économiques :

• Efficacité du capital: Cet aspect est particulièrement important pour les canaux de paiement. Ils nécessitent de bloquer des fonds équivalant au volume moyen des opérations dans le canal, les rendant moins efficaces en termes d'investissement en capital.
• Transaction L1 pour la création d'un compte L2. Aussi un inconvénient pour les canaux de paiement, car dans toutes les autres solutions, un compte créé en L1 fonctionne par défaut en L2.
• Coût de transaction : Avec le TPS, il s'agit de l'un des facteurs les plus critiques de la scalabilité, déterminant l'attractivité économique de la solution.

Facilité d'utilisation

• Temps de retrait de L2 à L1: Cette période peut varier de quelques minutes à plusieurs semaines. Les Rollups optimistes et Plasma sont particulièrement inconvenants à cet égard, car ils nécessitent plus de temps pour le retrait des fonds.
• Temps de finalité subjective de la transaction: Détermine à quelle vitesse une transaction devient irrévocable sur L1 du point de vue des observateurs externes. Par exemple, dans les Rollups Optimistes, obtenir la finalité sur L1 ne nécessite qu'une seule confirmation sur Ethereum, mais la finalité totale de la transaction prend environ une semaine.
• Vérifiabilité de la finalité subjective avec le code client : Détermine si le temps de finalité subjective peut être vérifié par les clients légers (navigateurs/portefeuilles mobiles). En continuant avec l'exemple des Rollups Optimistes, pour confirmer la finalité de la transaction, un utilisateur doit télécharger et vérifier l'intégralité du rollup d'état de la semaine précédente.
• Confirmations de transactions instantanées. Le protocole peut-il fournir des confirmations de transactions instantanées avec une garantie totale ? Ou garantit-il cela uniquement au niveau du consensus L2.
• Finalité instantanée visible : Peut être implémentée sur la plupart des protocoles de couche 2, ce qui signifie que les transactions sont instantanément confirmées dans l'interface utilisateur. Seuls les canaux de paiement (canaux d'état) offrent des garanties de sécurité complètes pour ces confirmations, tandis que dans d'autres protocoles, ces transactions peuvent encore être annulées dans un certain délai avant d'être confirmées dans la couche 1.

Autres Aspects

• Contrats intelligents : Évaluation de savoir si la solution L2 prend en charge des contrats intelligents entièrement programmables, ou seulement un sous-ensemble limité de fonctions à travers des prédicats.
• Compatibilité avec le bytecode EVM : évalue la faisabilité de transférer les contrats intelligents existants Ethereum EVM vers L2 sans modifications significatives.
• Support de confidentialité intégré : Considération de l'efficacité de la protection de la vie privée dans les solutions L2, en particulier dans le contexte de la disponibilité et de la rentabilité des transactions confidentielles.

Voici un tableau comparatif des principales solutions basées sur la preuve de connaissance nulle (ZKP).

Pour une compréhension plus détaillée des preuves de connaissance nulle (ZKP), je recommande de se référer à cet articledans notreblockchain-wiki, créé par des développeurs pour des développeurs avec un amour pour les preuves et les plongées profondes dans les détails.

Cycle de vie de la transaction dans zkSync

Le fonctionnement des ZK-Rollups peut être représenté de manière générale comme suit :

1. Formation de Rollup : les transactions sont regroupées dans un rollup.
2. Création de ZKP: Une preuve de connaissance nulle est formée.
3. Vérification dans Ethereum： La preuve est envoyée pour vérification à un contrat intelligent Ethereum.

Dans le contexte de l'architecture de zkSync, le processus ressemble à ceci :

1. Collection de blocs internes : les validateurs zkSync collectent des blocs internes à partir des transactions toutes les quelques secondes.
2. Formation du paquet de blocs : Toutes les 30 à 90 secondes, un paquet de blocs est créé à partir des blocs internes.
3. Engagement d'état de la blockchain : les validateurs enregistrent l'état actuel de la blockchain et transmettent les données modifiées à L1 en tant que données d'appel pour une éventuelle récupération.
4. Calcul et soumission de SNARK : Les validateurs calculent le SNARK (ZKP) pour le paquet et l'envoient pour vérification à un contrat intelligent Ethereum. Après vérification, le nouvel état du réseau devient final.

Les validateurs dans les ZK-Rollups jouent un rôle clé, emballant les transactions dans des blocs et générant des preuves de connaissance nulle pour elles. Une caractéristique du système est que les validateurs ne peuvent physiquement pas voler des fonds. Le préjudice potentiel le plus important qu'ils peuvent causer est un arrêt temporaire du réseau.

Note: Dans l'ère zkSync, le rôle des validateurs est rempli par les opérateurs.

Les développeurs de zkSync mettent en avant les garanties suivantes de leur architecture :

1. Sécurité des fonds: Les opérateurs ne peuvent jamais endommager l'état du réseau ou voler des fonds, ce qui est un avantage par rapport aux Sidechains.
2. Possibilité de récupération de fonds : les utilisateurs peuvent toujours extraire leurs fonds même si les opérateurs cessent leurs activités. Cela est possible grâce à la disponibilité des données, contrairement au système Plasma.
3. Indépendance de la surveillance : Grâce à ZKP, les utilisateurs ou les tiers de confiance n'ont pas besoin de surveiller en continu les blocs Rollup pour prévenir la fraude, ce qui est un avantage par rapport aux systèmes basés sur des preuves de fraude, tels que les canaux de paiement ou les Rollups optimistes.

Les transactions dans l'ère zkSync passent par plusieurs états clés, différents des confirmations Rollup habituelles dans L1 :

• En attente : La transaction a été reçue par l'opérateur mais n'a pas encore été traitée.
• Traitement: La transaction est en cours de traitement par l'opérateur et est prête à être incluse dans le prochain bloc.
• Engagement : Les données de transaction sont publiées sur Ethereum, garantissant la disponibilité des données, mais ne confirment pas son exécution correcte.
• Exécuté : La dernière étape où la preuve de validité (SNARK) de la transaction est vérifiée par un contrat intelligent Ethereum, rendant la transaction finale.

En plus du numéro de bloc, les transactions dans zkSync affichent également le numéro de package. À l'origine, des paramètres tels que block.number, block.timestamp et blockhash étaient pris de L1. Cependant, après une mise à jour, ces valeurs seront désormais obtenues à partir de L2. Malgré cela, les développeurs prévoient de fournir des méthodes pour accéder aux données depuis L1.

Différences entre zkEVM et EVM

La compatibilité des solutions de couche 2 basées sur ZKP avec Ethereum est une tâche complexe. Cela est dû à ce que Ethereum n'a pas été initialement conçu pour une interaction optimale avec ZKP. Par conséquent, dans le développement de tels systèmes, il faut trouver un compromis entre les performances et le potentiel de scalabilité d'une part, et la compatibilité avec Ethereum et l'EVM d'autre part. L'article de Vitalik Buterin Les différents types de ZK-EVMdiscute de ces aspects en détail et met en évidence différents niveaux de compatibilité.

zkSync a choisi l'un des chemins les plus difficiles, visant des performances élevées mais avec une compatibilité limitée à la fois avec Ethereum et EVM. Pour obtenir un bytecode compatible avec zkEVM, le LLVMLe projet est utilisé avec une suite de compilateurs et optimiseurs propriétaires. Dans le cas de Solidity et Yul, après le compilateur solc standard, le code passe par plusieurs étapes supplémentaires avant de devenir un bytecode zkEVM. Le schéma ci-dessous illustre toutes les étapes de ce processus (décrites plus en détail ici):

Important! Les optimisations dans zksolc sont prises en charge.

Le bytecode spécifiquement compilé pour l'EVM n'est pas compatible avec zkEVM. Cela signifie que les adresses des contrats intelligents identiques sur Ethereum et zkSync seront différentes. Cependant, les développeurs prévoient de résoudre ce problème à l'avenir.

Un des avantages significatifs de cette approche est l'indépendance vis-à-vis des langages de programmation spécifiques. À l'avenir, les développeurs de zkSync promettent d'ajouter le support de langages tels que Rust et C++. Il est important que le délai dans les mises à jour et l'intégration des innovations entre les compilateurs de haut niveau (par exemple, solc) et les compilateurs de plateforme (par exemple, zksolc) soit minimal. À l'origine, il y avait une idée de créer leur propre langage de programmation, Zinc, mais pour l'instant, l'équipe se concentre sur le support de langages de programmation plus populaires.

La question de la compatibilité des zk-compilateurs avec les outils de développement et de débogage existants pour les contrats intelligents Solidity et Vyper est importante. Les plateformes de développement actuelles telles que Remix, Hardhat et Foundry ne prennent pas en charge les zk-compilateurs par défaut, ce qui crée des difficultés dans leur utilisation. Cependant, solutionssont en cours de développement qui promettent de faciliter le processus de migration des projets et l'adaptation aux nouvelles technologies.

L'article de Vitalik Buterin mentionne qu'Ethereum s'efforcera probablement d'améliorer la compatibilité avec ZKP au niveau du protocole au fil du temps. De même, les solutions de couche 2 avec ZKP s'adapteront pour une meilleure compatibilité avec Ethereum. En conséquence, à l'avenir, les différences entre ces systèmes pourraient devenir presque imperceptibles, garantissant une intégration et une transition plus fluides pour les développeurs.

Fonctionnalités de zkEVM

Important ! Le protocole est en cours de développement actif ; veuillez toujours vous référer à la dernière version de la documentation !

zkEVM diffère de l'EVM et malgré les efforts des développeurs pour cacher ces différences "sous le capot", il y a des fonctionnalités importantes à prendre en compte lors de l'écriture de contrats intelligents :

1. Différences par rapport à l'EVM : Le comportement du code écrit en Solidity pour zkEVM peut différer, surtout en ce qui concerne des aspects tels que block.timestamp et block.number. Il est important de vérifier régulièrement le documentationpour les changements.
2. Contrats système : Dans zkSync, il existe des contrats intelligents systèmes pour diverses fonctions, tels que ContractDeployer pour le déploiement de contrats intelligents et MsgValueSimulator pour travailler avec l'ETH. Vous pouvez en savoir plus sur les contrats intelligents systèmes dans le documentation.
3. Modèle de proxy pour le déploiement : Il est recommandé d'utiliser un modèle de proxy au cours des premiers mois suivant le déploiement pour éviter d'éventuelles erreurs de compilation.
4. Calcul du gaz : Le modèle de calcul du gaz dans zkEVM diffère d'Ethereum, comprenant un ensemble différent d'opcodes et une dépendance du prix du gaz sur L1. Les détails peuvent être trouvés ici.
5. Test local : Les outils standard tels que Hardhat Node ou Anvil ne sont pas adaptés pour le test local de zkEVM. Au lieu de cela, options spécialessont utilisés, y compris le mode de test de fork.
6. Vérification de la signature : Il est recommandé d'utiliser le support intégré de l'abstraction de compte au lieu de ecrecover.
7. Suivi des erreurs liées au gaz : Dans zkSync, il est impossible de suivre les erreurs liées aux pénuries de gaz en raison des spécificités de l'exécution au sein du contrat intelligent du système DefaultAccount.

Pour une compréhension approfondie du travail avec zkEVM, il est recommandé d'étudier la documentation, y compris la section "Sécurité et meilleures pratiques".

Abstraction de compte

L'abstraction de compte dans zkSync offre plusieurs avantages clés par rapport à ERC-4337:

1. Niveau de mise en œuvre : Dans zkSync, l'abstraction de compte est intégrée au niveau du protocole, rendant tous les comptes, y compris les comptes détenus par des tiers (EOA), fonctionnellement similaires aux contrats intelligents.
2. Traitement des transactions: Alors qu'ERC-4337 utilise un mempool séparé pour les assembleurs, créant deux flux de transactions différents, zkSync Era dispose d'un seul mempool. Cela signifie que les transactions provenant des EOAs et des contrats intelligents sont traitées dans un seul flux, garantissant une intégration et un traitement plus fluides.
3. Support des Paymasters: zkSync prend en charge les paymasters pour tous les types de comptes, permettant la configuration des frais de gaz en jetons ERC20 pour n'importe quel compte.

Infrastructure zkSync

L'infrastructure de l'ère zkSync gagne rapidement du terrain et comprend déjà des dizaines de protocoles: Bridges, DeFi, protocoles d'infrastructure, et plus encore. (La liste actuelle peut être consultéeici).

Un autre avantage est la compatibilité avec les portefeuilles Ethereum, tels que MetaMask ou TrustWallet.

Hyperchains

Le protocole zkSync a commencé son développement avec le lancement de zkSync Lite, visant uniquement les transferts d'ether et de jetons ERC-20, sans la possibilité de déployer des protocoles complets. Cette étape a été une étape importante dans le développement mais a seulement précédé l'arrivée de l'ère zkSync - une solution L2 complète pour Ethereum, qui théoriquement peut être adaptée à d'autres blockchains L1 également. Cependant, les ambitions de zkSync ne s'arrêtent pas là, car les plans de développement incluent le lancement des soi-disant hyperchaînes.

Les hyperchaînes, ou "mise à l'échelle fractale", se composent de réseaux ZKP, chacun formant ses propres blocs et preuves. Ces preuves sont ensuite collectées et publiées sur le réseau principal L1. Chacun de ces réseaux est une copie complète de l'ensemble du système et peut être considéré comme son "fractal".

L'unicité des hyperchaînes réside dans le fait qu'elles peuvent être créées et déployées de manière indépendante. Pour garantir la cohérence et la compatibilité, chaque hyperchaîne doit utiliser un moteur zkEVM commun, faisant partie de la pile ZK (avec zkSync Era agissant comme la première hyperchaîne). Cela permet aux hyperchaînes d'hériter de leur sécurité de L1, garantissant ainsi leur fiabilité et éliminant le besoin de mesures de confiance et de sécurité supplémentaires.

Les hyperchaînes représentent une approche innovante pour mettre à l'échelle les réseaux de blockchain, réduisant la charge sur le réseau principal et augmentant la vitesse de traitement des transactions. Les aspects clés de cette approche comprennent :

• Transfert de preuve entre Hyperchains : Les Hyperchains se transféreront mutuellement des preuves de bloc, augmentant la distance qu'une transaction doit parcourir avant d'atteindre le réseau principal L1. Cela aide à répartir la charge et à éviter les problèmes de goulot d'étranglement.

• Transparence pour les utilisateurs : les utilisateurs ne remarqueront pas la différence - leurs transactions sont traitées dans des hyperchaînes et peuvent passer par plusieurs niveaux avant d'atteindre le réseau principal, créant de l'asynchronicité dans le traitement.
• Avantages par rapport aux solutions existantes: Contrairement aux solutions L2 actuelles, qui sont plus rapides mais toujours limitées en volume de transactions et parfois compromises en termes de sécurité, les hyperchains promettent une évolutivité nettement supérieure.
• Flexibilité dans la création de blockchains personnalisées: Les Hyperchains permettent la création de blockchains et de comptes personnalisés avec différents niveaux de sécurité et de confidentialité. Même avec un plus bas niveau de sécurité, dans le pire des cas, seule une pause temporaire des fonds est prévue.

Plus d'informations à ce sujet peuvent être trouvées ici.

Avantages et inconvénients de zkSync

Avantages

1. Sécurité : Sécurité proche du niveau L1 et potentiel de décentralisation à l'avenir.
2. Compatibilité EVM : prise en charge des contrats intelligents compatibles avec l'EVM.
3. Web3 API et Portefeuilles: API Web3 standard et prise en charge des portefeuilles Ethereum comme MetaMask.
4. Abstraction de compte : prise en charge native de l'abstraction de compte.
5. Vitesse de transaction : Traitement rapide des transactions sur L2 avec confirmation ultérieure sur L1.
6. Frais réduits : Frais de gaz réduits par rapport à L1.
7. Paiements de gaz ERC20 : Possibilité de payer les frais de gaz en jetons ERC20.
8. Infrastructure évolutive : Développement très actif de l'infrastructure.
9. Potentiel de scalabilité : Opportunités d'améliorations significatives de la scalabilité.

Pro

1. Compatibilité EVM limitée : Comparé à ses concurrents (par exemple, Polygon zkEVM, Scroll), il a une compatibilité EVM plus faible.
2. Risque d'erreurs dans les contrats intelligents : Risque accru d'erreurs, nécessitant des tests et des audits approfondis.
3. Besoin spécifique de pile de développement : Nécessité d'adapter la pile de développement aux spécificités du protocole.
4. Retard dans les technologies de base : Retard dans l'adoption d'innovations dans les compilateurs et les mises à jour de bibliothèques.
5. Centralisation du réseau : Actuellement, le réseau est géré par un nombre limité d'opérateurs.
6. Besoin de contrats intelligents évolutifs : De tout ce qui précède, il découle qu'il est nécessaire de toujours créer des contrats évolutifs au début du projet, afin de pouvoir rectifier rapidement les déficiences et les vulnérabilités.

Conclusion

Le protocole zkSync semble très prometteur et a un grand potentiel, bien que, actuellement, le lancement sur cette blockchain soit encore associé à un certain nombre de risques qui doivent être pris en compte. Le développement pour zkSync est actuellement plus difficile que pour les blockchains qui sont beaucoup plus compatibles avec l'EVM et la pile de développement EVM. Cependant, peut-être qu'à l'avenir, cette différence deviendra insignifiante ou disparaîtra complètement.

Avertissement：

1. Cet article est repris de [ MetaLamp]. Transférer le titre original 'Comment ZKP et ZK-Rollups aident à résoudre le problème de la scalabilité : une revue de la blockchain zkSync'. Tous les droits d'auteur appartiennent à l'auteur original [MetaLamp]. Si des objections sont formulées à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en chargeront 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 en aucun cas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.