Ethereum EIP-8479 expliqué : PeerDAS post-quantique et blobs de taille variable

2026/11/03 16:03:00

Et si Ethereum pouvait rendre son infrastructure de disponibilité des données plus résistante aux futurs ordinateurs quantiques tout en offrant aux réseaux de niveau 2 une plus grande flexibilité sur la façon dont ils publient les données de transaction ? Une nouvelle proposition introduite par le chercheur de la Ethereum Foundation Francesco Risitano le 1er novembre 2026 explore précisément cette possibilité. Le projet, initialement numéroté EIP-9999, propose de remplacer les engagements KZG dans PeerDAS par des engagements Merkle Keccak-256 et des preuves STARK LeanDA. Il introduit également des blobs de taille variable allant de 2 Ko à 512 Ko, permettant aux rollups de sélectionner une capacité de données plus étroitement alignée sur leurs besoins. Le fil de discussion Ethereum Magicians utilise la désignation EIP-8479, ce qui rend la distinction de numérotation importante lors du suivi de la proposition. Bien que la conception reste à un stade précoce d'examen, elle relie trois priorités majeures du développement Ethereum : la cryptographie post-quantique, la disponibilité des données et l'évolutivité des niveaux 2. Son potentiel d'importance dépasse l'ingénierie du protocole, soulevant des questions sur les coûts des rollups, la compétitivité de l'infrastructure d'Ethereum et la valeur à long terme d'ETH dans son écosystème.

Points clés

Une nouvelle proposition post-quantique : le projet explore le remplacement des engagements PeerDAS basés sur KZG par des engagements Merkle Keccak-256 et des preuves LeanDA STARK.
Blocs de taille variable : la conception permet des tailles de blocs puissances de deux, de 2 Ko à 512 Ko, tout en conservant 128 colonnes par bloc.
Implications de la couche 2 : les rollups pourraient sélectionner des capacités de données plus étroitement alignées sur les lots de transactions, ce qui pourrait améliorer l'utilisation des données.
Changements cryptographiques : les chemins d'authentification Merkle remplaceraient les preuves de cellule KZG, tandis que les preuves STARK vérifieraient le codage Reed-Solomon et la dérivation de l'engagement.
Phase de développement précoce : La proposition reste un projet, avec les paramètres du système de preuve, l'intégration client et les benchmarks de performance qui nécessitent encore des travaux.
Pertinence du marché ETH : La proposition pourrait renforcer le récit à long terme de l'infrastructure d'Ethereum, mais elle ne crée pas de catalyseur immédiat pour les prix de l'ETH ni ne garantit des frais de transaction plus bas.

Qu'est-ce que l'EIP-8479 d'Ethereum et pourquoi a-t-il été proposé ?

La proposition aborde deux défis interconnectés : la sécurité cryptographique à long terme de la couche de disponibilité des données d'Ethereum et le besoin d'une capacité de données plus flexible pour les rollups. Sa spécification originale est intitulée EIP-9999, et le fil de discussion de novembre 1 utilise le titre EIP-8479. Elle a été rédigée par Francesco Risitano, Thomas Coratger et Tom Wambsgans, et sa version initiale date du 26 octobre 2026. La proposition est une EIP Core, Standards Track et porte actuellement le statut de Draft. Elle fait référence à plusieurs propositions connexes, notamment EIP-4844, EIP-7594, EIP-7892, EIP-8141 et EIP-8288.

Pourquoi PeerDAS existant nécessite une approche cryptographique différente

PeerDAS, ou Peer Data Availability Sampling, permet aux nœuds Ethereum de vérifier si les données de blob sont disponibles sans télécharger chaque octet d'un blob entier. Le mécanisme répartit les données en colonnes, attribue des responsabilités de garde aux nœuds et permet aux participants d'échantillonner des parties sélectionnées. Cela réduit les exigences en données pour les validateurs ordinaires tout en préservant une méthode pour vérifier la disponibilité des données.

Le design actuel utilise des engagements KZG et des preuves de cellules pour authentifier les données échantillonnées. KZG repose sur la cryptographie par appariement de courbes elliptiques, qui est vulnérable en principe aux ordinateurs quantiques suffisamment performants et tolérants aux pannes exécutant l'algorithme de Shor. Bien que des ordinateurs quantiques pratiques capables de briser les hypothèses cryptographiques d'ethereum ne soient pas actuellement disponibles, les chercheurs du protocole évaluent des alternatives avant que cette menace ne devienne opérationnelle. La discussion de l'EIP-8479 reflète donc une stratégie de sécurité prospective plutôt qu'une réponse à une attaque quantique immédiate.

Pourquoi la flexibilité des Blob est importante pour Ethereum

La deuxième motivation concerne la manière dont les rollups achètent et publient de la capacité de données. Des structures de données de taille fixe peuvent créer des inefficacités lorsque le lot de transactions d'un rollup ne correspond pas à la capacité disponible. Un lot plus petit peut laisser de l'espace inutilisé, tandis que l'attente pour accumuler un lot plus important peut introduire des retards supplémentaires dans la publication.

Les blobs de taille variable visent à donner aux opérateurs de rollup un meilleur contrôle sur ce compromis. Au lieu de traiter chaque soumission comme une unité de capacité fixe, la conception proposée permet aux tailles de blobs prises en charge d'augmenter selon des puissances de deux. Cela pourrait rendre la publication de données plus adaptable aux différents volumes de transactions et aux exigences opérationnelles.

Comment EIP-8479 remplace-t-il KZG par des STARKs post-quantiques ?

Le changement cryptographique central consiste à remplacer les engagements KZG et les preuves de cellule par des engagements Merkle Keccak-256, des chemins d'authentification Merkle et des preuves STARK LeanDA. La conception sépare la tâche d'authentifier des échantillons de données individuels de la tâche de prouver que l'ensemble du blob a été encodé et engagé correctement. Cela vise à éliminer la dépendance aux hypothèses de couplage sur les courbes elliptiques et à supposer la configuration de confiance requise par la construction KZG existante.

Engagements Merkle Keccak-256

Un arbre de Merkle organise les données par hachage répété. Les éléments de données individuels sont d'abord hachés pour former des nœuds feuilles, puis les paires de hachages sont combinées pour créer des nœuds de niveaux supérieurs. Le processus se poursuit jusqu'à ce qu'une seule racine de Merkle représente la structure de données sous-jacente.

Dans le design proposé de PeerDAS, chaque blob reçoit un engagement Merkle basé sur Keccak-256. Lorsqu'un nœud échantillonne une cellule de données particulière, il peut recevoir le chemin d'authentification Merkle correspondant et vérifier indépendamment que la cellule appartient au blob engagé. Cela offre un moyen d'authentifier les données échantillonnées sans s'appuyer sur les preuves de cellules KZG.

Keccak-256 est particulièrement pertinent car les constructions cryptographiques basées sur des fonctions de hachage sont généralement considérées comme plus adaptées à la sécurité post-quantique que les schémas fondés sur le logarithme discret sur courbe elliptique. Les algorithmes de recherche quantique peuvent tout de même réduire la sécurité effective des fonctions de hachage, ce qui rend les paramètres de sécurité et les détails d'implémentation toujours importants. La proposition doit donc être comprise comme un pas vers des hypothèses cryptographiques résistantes à l'ordinateur quantique, et non comme une garantie contre toute attaque quantique future.

Que vérifie exactement LeanDA STARK ?

L'authentification de Merkle établit qu'une cellule échantillonnée appartient à une structure de données spécifique, mais le protocole doit également vérifier que le codage des données du blob et la génération de l'engagement sont corrects. C'est ici que LeanDA STARK devient important.

La preuve STARK proposée démontre deux propriétés centrales : que le blob satisfait sa relation d'encodage Reed-Solomon et que l'engagement Merkle associé a été correctement dérivé. Le codage Reed-Solomon introduit de la redondance permettant de reconstituer les parties manquantes des données tant qu'assez de parties valides restent disponibles. La preuve permet au réseau de vérifier les relations d'encodage et d'engagement pertinentes sans exiger que chaque vérificateur effectue indépendamment l'ensemble du calcul.

La proposition relie également les preuves LeanDA à l'EIP-8288, qui fournit un cadre de regroupement récursif STARK au niveau du bloc. Plutôt que de traiter chaque preuve comme une tâche de vérification isolée, la conception introduit des cadres de dépendance de disponibilité des données dont les preuves peuvent être pliées dans le regroupement global au niveau du bloc. Cette intégration est techniquement significative car les coûts de génération, de regroupement et de vérification des preuves influenceront la praticabilité de cette conception pour les clients Ethereum.

Comment les blobs de taille variable modifient-ils la disponibilité des données sur ethereum ?

La proposition introduit des tailles de blobs allant de 2 Ko à 512 Ko, avec des longueurs en octets limitées aux puissances de deux. Chaque blob conserve 128 colonnes, ce qui signifie que la longueur en octets des unités de données individuelles change, tandis que la structure globale des colonnes reste cohérente. Cela constitue un écart significatif par rapport au modèle traditionnel de blobs de taille fixe utilisé par l'infrastructure de disponibilité des données existante d'ethereum.

De la capacité fixe à la publication de données flexible

Selon le design proposé, un rollup pourrait sélectionner une taille de blob plus proche du montant de données qu'il doit publier. Un petit lot de transactions pourrait utiliser un blob plus petit, tandis qu'un lot plus important pourrait opter pour une capacité supérieure. L'objectif est de réduire le remplissage inutile et d'offrir aux rollups une plus grande flexibilité pour équilibrer les coûts de disponibilité des données avec la fréquence de publication.

Les exemples suivants illustrent la plage de capacité proposée :

2 Ko : Une soumission de données petite nécessitant une capacité limitée.
8 Ko–64 Ko : Tailles intermédiaires pour des lots de transactions relativement compacts.
128 Ko : Un point de référence familier correspondant à la capacité traditionnelle des blocs.
256 Ko–512 Ko : Soumissions plus volumineuses nécessitant une capacité de données supplémentaire.

La proposition spécifie également des modifications aux transactions transportant des blobs. Plutôt que de s'appuyer uniquement sur la représentation par hachage versionné existante, la structure de transaction proposée utilise une racine Merkle et un champ de longueur en octets explicite. Les transactions transportant des blobs sont représentées à l'aide de transactions cadre EIP-8141, reliant la nouvelle structure de données à la conception plus large du format de transaction.

Comment les blobs de taille variable pourraient-ils affecter les coûts de gaz ?

La capacité flexible des blobs pourrait améliorer l'utilisation des données, mais la relation entre la taille des blobs et les frais n'est pas aussi simple que de choisir un blob plus petit et de payer automatiquement moins cher. La proposition modifie également les exigences réseau et la comptabilisation du gaz, y compris les coûts associés à l'authentification Merkle et au nouveau processus de vérification.

Pour les opérateurs de rollup, le calcul pertinent implique plus que la capacité brute des données. Ils doivent prendre en compte la taille des lots de transactions, la fréquence de publication des blobs, les coûts de génération des preuves, la propagation sur le réseau et le prix du marché du gaz blob. Un blob plus petit peut être plus efficace pour une charge de travail donnée, tandis qu'une soumission plus importante peut être préférable pour une autre.

La conception introduit donc une opportunité d'optimiser la publication des données plutôt que de promettre une réduction universelle des frais. Les économies réelles dépendront des indicateurs de mise en œuvre et de la manière dont les développeurs de rollup adapteront leurs stratégies de regroupement après que la proposition aura fait l'objet d'un examen supplémentaire.

Que pourrait signifier EIP-8479 pour les réseaux de couche 2 d'ethereum ?

La proposition pourrait rendre l'infrastructure de disponibilité des données d'Ethereum plus adaptable aux besoins des réseaux de niveau 2, en particulier des rollups qui publient les données de transaction par lots. Arbitrum, Optimism et Base sont des exemples de grands écosystèmes de mise à l'échelle d'Ethereum dont les opérateurs sont intéressés par une publication de données efficace et prévisible. Toutefois, l'EIP-8479 ne modifie pas directement leurs environnements d'exécution ni ne garantit des réductions immédiates des frais de transaction pour les utilisateurs.

Avantages potentiels pour les opérateurs de rollup

Les rollups doivent équilibrer la fréquence des soumissions de lots de transactions avec le coût de la publication des données sur Ethereum. Des blobs de capacité fixe peuvent créer un décalage entre les besoins réels en données et la capacité achetée. Des blobs de taille variable pourraient offrir aux opérateurs davantage de choix lors de la conception des tailles de lots et des calendriers de publication.

Par exemple, un rollup connaissant une activité de transactions relativement faible pourrait préférer publier des lots plus petits sans attendre d'accumuler suffisamment de données pour remplir une structure de capacité fixe plus grande. Un rollup à fort volume pourrait, au contraire, utiliser des blocs plus volumineux pour regrouper davantage de données dans chaque soumission. Ces choix pourraient améliorer la flexibilité opérationnelle et aider les développeurs à optimiser la relation entre les coûts de disponibilité des données et la latence des transactions.

Le bénéfice ne sera pas nécessairement identique sur les différents réseaux. Les rollups diffèrent par le volume de transactions, les techniques de compression, les modèles de séquençage et les stratégies de publication des données. Par conséquent, les développeurs devront évaluer si la flexibilité supplémentaire compense les coûts d’implémentation et de génération des preuves.

Implications pour la concurrence des couches 2 d'Ethereum

Ethereum concurrence avec d'autres écosystèmes de blockchain qui proposent des approches différentes en matière d'exécution, de règlement des transactions et de disponibilité des données. Améliorer l'efficacité de son infrastructure de blobs pourrait soutenir la position d'Ethereum en tant que couche de règlement et de disponibilité des données pour les applications basées sur des rollups.

Cependant, la compétitivité du réseau dépend de bien plus que de la capacité de blobs. Les développeurs et les utilisateurs prennent également en compte les frais de transaction, les performances des applications, la liquidité, l’interopérabilité, la sécurité et le soutien de l’écosystème. EIP-8479 traite une partie importante de cette équation plus large : l’infrastructure cryptographique et de disponibilité des données sous-jacente au scaling par rollup.

Sa contribution potentielle est donc mieux évaluée comme une amélioration de l'infrastructure qui pourrait renforcer l'environnement de développement Layer 2 d'Ethereum avec le temps, plutôt que comme un avantage concurrentiel immédiat déjà démontré.

Comment EIP-8479 s'inscrit-il dans la feuille de route post-quantique d'ethereum ?

EIP-8479 traite la composante de disponibilité des données du programme de recherche post-quantique plus vaste d'Ethereum. Il ne remplace pas chaque primitive cryptographique utilisée par le réseau, et il ne rend pas Ethereum entièrement résistant aux ordinateurs quantiques. Les signatures de consensus, l'authentification des comptes et d'autres systèmes cryptographiques nécessitent leurs propres stratégies de migration.

Trois domaines cryptographiques nécessitent une attention particulière

L'architecture cryptographique d'Ethereum comprend plusieurs composants avec des hypothèses de sécurité différentes :

Signatures de consensus : les validateurs Ethereum utilisent des signatures BLS pour participer au consensus et agréger les attestations. Étant donné que BLS repose sur la cryptographie de paire de courbes elliptiques, les chercheurs explorent des systèmes de signature alternatifs offrant de meilleures propriétés de sécurité post-quantique.

Signatures de compte : Les comptes externes standards utilisent des signatures ECDSA. Un ordinateur quantique suffisamment puissant pourrait théoriquement utiliser l'algorithme de Shor pour dériver des informations sur la clé privée à partir de clés publiques exposées, sous les hypothèses courantes des courbes elliptiques. L'abstraction de compte et les mécanismes alternatifs de vérification de signature font partie des approches qui pourraient faciliter une migration future.

Engagements de disponibilité des données : les engagements KZG sont le composant directement visé par cette proposition. Les remplacer par des engagements Merkle basés sur des hachages et des preuves STARK permettrait de traiter une partie spécifique de l'exposition cryptographique du protocole.

Ces domaines sont liés, mais ils ne peuvent pas être mis à niveau via un seul changement. La transition post-quantique d'ethereum nécessitera un travail coordonné sur le consensus, l'exécution, le réseau et l'infrastructure des applications.

Pourquoi les conceptions basées sur STARK sont importantes

Les systèmes STARK utilisent des fonctions de hachage et des constructions de preuve transparentes plutôt que des appariements de courbes elliptiques et un réglage de confiance conventionnel. Leurs propriétés en font des candidats pour des applications post-quantiques, bien que la taille des preuves, les performances de vérification, la complexité d'implémentation et les paramètres de sécurité des fonctions de hachage doivent encore être évalués.

EIP-8479 démontre également l'importance de relier la recherche cryptographique à l'ingénierie des protocoles. Un système de preuve théoriquement sécurisé n'est pas suffisant en soi : il doit fonctionner dans les contraintes de temporisation des blocs Ethereum, de bande passante, de ressources des validateurs et de compatibilité des clients. L'intégration de la proposition avec EIP-8288 reflète cette exigence de considérer la vérification des preuves au niveau global des blocs.

Quel est l'état actuel de l'EIP-8479 ?

Au 2 novembre 2026, la proposition reste un brouillon de phase précoce plutôt qu'une mise à niveau du réseau Ethereum approuvée. Sa discussion du 1er novembre et sa demande de tirage sur GitHub sollicitent des commentaires des développeurs de rollup, des équipes de consensus et de client d'exécution, des contributeurs réseau et des chercheurs en cryptographie. La spécification identifie explicitement plusieurs problèmes non résolus, ce qui signifie qu'un travail substantiel de conception et d'implémentation reste à accomplir avant qu'un déploiement sur mainnet puisse être envisagé.

Défis techniques exceptionnels

Le premier problème est la finalisation du programme invité LeanDA et son hachage de clé de vérification. Ces composants sont importants car ils définissent le calcul étant prouvé et les paramètres utilisés par les vérificateurs pour vérifier la preuve STARK résultante.

Le deuxième problème est l'implémentation client. La proposition exige des modifications coordonnées au niveau de l'exécution, de la couche de consensus et des composants réseau. Les développeurs doivent s'assurer que les différents clients interprètent de manière cohérente les engagements de blob, les champs de transaction et les procédures d'authentification des données.

La troisième question concerne les performances. La génération de preuves, l'agrégation récursive, les chemins d'authentification Merkle et la bande passante PeerDAS doivent être benchmarkés sur différentes configurations de nœuds. Une conception qui fonctionne dans un environnement de recherche contrôlé doit également rester pratique pour le réseau plus large de validateurs.

Enfin, les opérateurs de rollup doivent confirmer si la répartition proposée de la taille des blobs correspond à la demande réelle. Les retours sur les capacités préférées aideront à déterminer si les blobs de taille variable offrent des avantages significatifs au-delà de la complexité protocolaire supplémentaire.

Que devraient surveiller les développeurs et les investisseurs ensuite ?

Les développements les plus importants seront les progrès sur la spécification, la publication d'un prototype fonctionnel, un examen cryptographique indépendant et les résultats de performance. Les retours des équipes rollup aideront également à déterminer si la plage de capacité proposée est utile pour des charges de travail réelles de publication de données.

Le statut des propositions associées est également important. EIP-8288 fournit le cadre d'agrégation de preuves récursives référencé par LeanDA, tandis que EIP-8141 fournit la structure de transaction proposée. Leur avancement pourrait influencer le chemin d'intégration pour la nouvelle conception.

Pour les investisseurs, la distinction entre une proposition de recherche et une mise à jour prévue est essentielle. Une Draft EIP peut influencer le récit à long terme du développement d'Ethereum, mais elle ne doit pas être considérée comme une preuve qu'une fonctionnalité spécifique atteindra le mainnet ou produira un changement mesurable dans la demande d'ETH.

EIP-8479 pourrait-il affecter le prix de l'ETH et l'adoption d'Ethereum ?

EIP-8479 présente des implications à long terme pour l'infrastructure d'Ethereum, mais son impact immédiat sur ETH valuation sera probablement davantage guidé par les attentes du marché que par des changements directs à l'économie du réseau. La proposition n'a pas encore été mise en œuvre, et aucun calendrier de activation sur le mainnet n'a été confirmé. Par conséquent, elle ne fournit pas encore de preuves mesurables de frais de rollup réduits, d'une utilisation accrue des blobs ou d'une demande accrue de transactions ETH.

À court terme, les traders et les analystes sont plus susceptibles de surveiller l'activité de trading au comptant de l'ethereum, la position sur les dérivés, les flux des ETF et les conditions générales du marché. Les nouvelles concernant la proposition pourraient renforcer l'intérêt pour la feuille de route technique d'Ethereum, mais une spécification provisoire seule ne suffit pas à créer un catalyseur de prix durable.

À plus long terme, une mise en œuvre réussie pourrait soutenir le rôle d'Ethereum en tant que couche de disponibilité des données et de règlement sécurisée. Une capacité de blob plus flexible pourrait aider les rollups à gérer la publication des données, tandis que les engagements basés sur le hachage et les preuves STARK pourraient contribuer à la transition post-quantique du réseau. Ces améliorations pourraient renforcer la confiance des développeurs et la participation à l'écosystème si elles apportent des avantages de performance pratiques.

Néanmoins, la valorisation globale de l'ETH continuera de dépendre de l'activité du réseau, du staking, de la dynamique de l'offre, de l'adoption des applications et de la concurrence d'autres écosystèmes blockchain. EIP-8479 doit donc être considéré comme un composant du développement à long terme de l'infrastructure d'Ethereum, et non comme une thèse d'investissement indépendante.

Conclusion

La proposition d'Ethereum pour PeerDAS post-quantique et la conception de blobs de taille variable représente une direction de recherche importante pour l'infrastructure de disponibilité des données du réseau. En remplaçant les engagements KZG et les preuves de cellule par des engagements Merkle Keccak-256 et la vérification LeanDA STARK, la proposition explore une architecture cryptographique mieux alignée avec les objectifs de sécurité post-quantique à long terme. Sa conception de blobs de taille variable, allant de 2 Ko à 512 Ko, introduit également une plus grande flexibilité pour les rollups qui doivent publier des volumes différents de données de transaction.

Cependant, la proposition reste à un stade précoce de rédaction. Ses paramètres de preuve, son intégration client, les modifications réseau et ses exigences de performance doivent encore être abordés par un examen technique et des tests d'implémentation. Pour Ethereum, l'importance de ce développement réside dans la combinaison de la résilience cryptographique et de l'efficacité des données de couche 2. Que cela améliore finalement l'économie des rollups ou influence l'adoption de l'ETH dépendra d'une implémentation réussie et de bénéfices mesurables pour l'écosystème. Pour l'instant, EIP-8479 est mieux compris comme une proposition d'infrastructure prospective dans le cadre plus large de la recherche d'Ethereum sur l'évolutivité et la cryptographie post-quantique.

FAQ

Quelle est la différence entre un EIP et un ERC ?

Une Proposition d'amélioration d'Ethereum (EIP) décrit les changements proposés au protocole, aux normes ou aux processus de développement d'Ethereum. Une Demande de commentaires d'Ethereum (ERC) spécifie généralement des normes de niveau application, telles que les interfaces de jetons et les conventions de contrats intelligents. EIP-8479 est une proposition Core car elle concerne la disponibilité fondamentale des données et le comportement du protocole.

Que signifie PeerDAS ?

PeerDAS signifie Peer Data Availability Sampling. C'est un mécanisme qui permet aux nœuds Ethereum de prélever des portions de données de blobs distribuées plutôt que de télécharger chaque élément de données. Cette approche aide à réduire les besoins en données des nœuds individuels tout en conservant un moyen de vérifier la disponibilité des données.

Qu'est-ce que le codage Reed-Solomon ?

Le codage Reed-Solomon est un code de correction d'erreurs qui ajoute de la redondance aux données. Cela permet de reconstituer les parties manquantes lorsque suffisamment de parties valides restent disponibles. Il est pertinent pour PeerDAS car la disponibilité distribuée des données dépend de la capacité du réseau à reconstituer les données originales à partir des composants échantillonnés et distribués.

Qu'est-ce qu'une configuration de confiance en cryptographie ?

Un setup de confiance est un processus d'initialisation utilisé par certains systèmes cryptographiques pour générer des paramètres publics. Si les informations secrètes ne sont pas correctement détruites, cela peut créer des risques de sécurité. Les engagements KZG reposent sur un setup de confiance, tandis que la conception proposée basée sur STARK vise à éviter cette exigence grâce à une construction de preuve transparente.

Comment les utilisateurs peuvent-ils suivre l'avancement d'une proposition d'amélioration d'Ethereum ?

Les utilisateurs peuvent suivre le dépôt Ethereum EIPs sur GitHub, examiner les discussions techniques sur Ethereum Magicians et surveiller les mises à jour des développeurs Ethereum. Les jalons importants incluent les révisions de spécification, les examens indépendants, les implémentations prototypes, les tests clients et toute décision formelle concernant l'inclusion dans une future mise à niveau du réseau.

Avertissement : Ces informations générales sur le marché, provenant éventuellement de sources tierces, commerciales ou sponsorisées, sont fournies à titre de référence et éducatif uniquement et ne constituent ni un conseil financier ni un conseil en investissement, ni une offre, une sollicitation ou une garantie. Nous déclinons toute responsabilité quant à son exactitude, complétude, fiabilité et aux pertes résultantes. Les investissements/le trading comportent des risques ; les performances passées ne garantissent pas les résultats futurs. Les utilisateurs doivent effectuer leurs propres recherches, juger avec prudence et assumer pleine responsabilité. Pour plus de détails, veuillez consulter les Conditions d'utilisation et les Divulgation des risques de KuCoin.

Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.