Abstrait

Cet article explore les méthodes pratiques permettant d'activer la vérification ZK dans Bitcoin, en abordant des sujets tels que le modèle UTXO de Bitcoin, les limitations de scripting, Taproot, OP_CAT, BitVM et les preuves d'état de la chaîne. Il présente un argument clair selon lequel l'intégration de ZK dans le protocole Bitcoin est inévitable. Deux routes potentielles sont mises en évidence : l'une consiste à réintroduire l'opcode OP_CAT pour prendre en charge directement la vérification SNARK dans les scripts Bitcoin - un changement qui a de fortes chances d'être approuvé à terme. La deuxième approche tourne autour de BitVM, qui intègre des preuves de fraude. De plus, la proposition de l'équipe ZeroSync concernant les preuves d'état de la chaîne vise à réduire le coût de vérification des données historiques pour les clients du nœud.

Pour bien comprendre Bitcoin, il est utile de le considérer comme un système social. Dans ses premiers jours, les créateurs de Bitcoin ont défini le logiciel que les nœuds doivent exécuter, tout comme l'établissement des règles qui régissent une société. La stabilité de Bitcoin dépend d'un large consensus sur sa nature fondamentale, ce qui soulève des questions telles que "Qu'est-ce que Bitcoin au fond ?" et "Qu'est-ce que Bitcoin devrait évoluer en ?" Cependant, parvenir à un consensus sur ces questions est notoirement difficile, car les opinions varient largement et évoluent continuellement.

Cela remonte à l'origine historique de Bitcoin. Lorsque Satoshi Nakamoto a publié le livre blanc sur Bitcoin, il a déclaré: «Je travaille sur un tout nouveau système de paiement électronique. Ce système est entièrement P2P et n'a pas besoin de s'appuyer sur un tiers.» Ce passage a été publié sur la liste de diffusion Cypherpunks (un groupe de discussion par e-mail créé en 1992, composé d'un groupe de cryptographes et de passionnés de technologie préoccupés par la protection de la vie privée et la technologie de cryptographie).

Cependant, Bitcoin limite le débit de données au niveau de la conception du produit. Le nombre de transactions qu'il peut traiter par unité de temps est limité. Si le nombre de transactions à traiter augmente rapidement, les utilisateurs lanceront une guerre des prix pour terminer rapidement la transaction, augmentant rapidement les frais de traitement payés. La transaction unique avec les frais de traitement les plus élevés dans le réseau Bitcoin s'est produite après la réduction de moitié de la récompense de bloc en 2024, et les frais de traitement pour une transaction avec une priorité moyenne sur la chaîne ont atteint 150 $. On peut dire que les frais de transaction coûteux du réseau Bitcoin sont devenus un problème.

Pour résoudre le problème des frais de transaction, les gens ont investi beaucoup de ressources dans le développement du Lightning Network. Mais selon un article publié en 2016, le Lightning Network ne peut soutenir que des dizaines de millions d'utilisateurs en pratique et ne peut pas réaliser sa vision d'un système de paiement mondial. En plus des frais de transaction excessivement chers, il y a un autre problème, c'est que Bitcoin n'a jamais été capable d'atteindre l'anonymat qu'il envisageait.

Satoshi Nakamoto a souligné dans un groupe de discussion par e-mail cypherpunk que Bitcoin a une fonction de protection de la vie privée et que l’initiateur de la transaction peut être complètement anonyme. Cependant, bien que l’initiateur de la transaction n’exige pas de KYC, les données de transaction sur la chaîne Bitcoin laissent échapper beaucoup d’informations, exposant la vie privée des utilisateurs dans une large mesure. Bien qu’il existe des clients de portefeuille dotés de fonctions de confidentialité qui résolvent les problèmes ci-dessus dans une certaine mesure, les développeurs de ces clients de portefeuille sont confrontés à des menaces de différentes tailles. Par exemple, le développeur du portefeuille Samourai CoinJoin a été arrêté par le FBI en avril 2024, et une semaine plus tard, le développeur du portefeuille Wasabi a fermé son composant de coordination CoinJoin. De toute évidence, ces soi-disant portefeuilles de confidentialité ne sont pas entièrement dignes de la confiance des utilisateurs.

En résumé, bon nombre des concepts de Bitcoin sont loin d'être réalisés à ce jour, et les technologies connexes sont toujours en développement continu. Même ainsi, de nombreuses personnes dans la communauté Bitcoin croient que la conception du protocole de Bitcoin devrait rester inchangée, mais il y a aussi beaucoup de personnes, comme moi, qui sont passionnées par l'amélioration de Bitcoin. Alors, dans quelle direction Bitcoin devrait-il s'améliorer ?

En réponse aux problèmes mentionnés ci-dessus, il existe de nombreuses propositions dans la communauté Bitcoin, et celles avec les meilleurs résultats théoriques devraient être liées à ZK et SNARKs. Avec ZK et SNARKs, les fonctionnalités suivantes peuvent être atteintes:

1. Confidentialité considérablement améliorée : utilisez l'engagement homomorphe de Peterson pour le montant de la transaction et la preuve de portée pour améliorer considérablement la confidentialité de l'utilisateur (comme dans la chaîne latérale d'Element de Blockstream) ; utilisez des signatures liables (comme Monero) pour masquer les traces de transaction ; réalisez des transactions véritablement privées (comme Zcash).

2. Améliorer le débit des transactions

De nombreuses solutions techniques pourraient résoudre les problèmes actuels de Bitcoin, mais pourquoi ces technologies n'ont-elles pas été intégrées dans le protocole Bitcoin ? La réponse réside dans la difficulté de modifier le protocole. Contrairement à Ethereum, Bitcoin n'a pas d'organisation centralisée comme la Fondation Ethereum. Tout changement de protocole nécessite un haut niveau de consensus communautaire, impliquant une négociation approfondie et un équilibre des intérêts. En conséquence, tandis qu'Ethereum met régulièrement à jour ses opcodes EVM, le protocole de Bitcoin a connu très peu de changements depuis sa création.

À certains égards, cette difficulté à modifier le protocole est bénéfique. Si les changements étaient faciles à mettre en œuvre, les altérations ou attaques malveillantes seraient plus probables. Cela soulève la question : comment améliorer les performances de Bitcoin sans modifier le protocole ?

Pour répondre à cela, nous devons revenir à quelques bases de Bitcoin. Lorsque vous transférez du Bitcoin à quelqu'un d'autre, vous créez une transaction et la diffusez sur le réseau Bitcoin. Les données de sortie de la transaction spécifient le montant de BTC transféré. Le destinataire peut alors créer une nouvelle transaction pour dépenser les BTC reçus, générant de nouvelles données de sortie dans le processus.

Il est important de noter que Bitcoin n'a pas un état global comme Ethereum, et il manque en particulier un état de compte ; il n'a que des données de sortie de transaction. Chaque sortie de transaction a deux états : soit elle a été dépensée par le destinataire, soit elle reste non dépensée. Les sorties de transaction non dépensées (UTXO) sont ce que nous connaissons. En plus du montant BTC associé, chaque sortie de transaction a également un script attaché écrit en Bitcoin Script. Celui qui peut fournir la preuve correcte (témoin) à ce script peut dépenser l'UTXO.

Le script Bitcoin est un langage de programmation basé sur la pile avec une série d'opcodes. Les programmes attachés aux UTXO consistent souvent en plusieurs opcodes, effectuant des calculs basés sur la pile et renvoyant les résultats à celle-ci. De nombreux scripts Bitcoin courants existent depuis la création de Bitcoin. Par exemple, le script le plus courant se compose d'une clé publique et d'un opcode vérifiant la signature numérique. Cet opcode exige que pour dépenser ou déverrouiller un UTXO, il faille fournir une signature numérique correspondant à la clé publique.

Lecture recommandée: [Approche de BTC : Connaissances de base pour comprendre BitVM (1)]

Capacités du script Bitcoin

Ce que le script Bitcoin peut faire :

• Réorganiser la pile et effectuer des vérifications d'égalité (pour vérifier des conditions spécifiques et garantir la sécurité et la validité des transactions).
• Effectuer des opérations conditionnelles similaires aux déclarations if-else.
• Effectuer des opérations arithmétiques limitées sur des nombres de 32 bits, telles que l'addition et la soustraction.
• Hasher les données et vérifier les signatures ECDSA et Schnorr.

Ce que le script Bitcoin ne peut pas faire :

• Pas de boucles, de sauts ou de récursivité ; il n'est pas Turing-complet, avec des capacités de programmation très limitées.
• Impossible d'effectuer des opérations bit à bit.
• Manque d'opcodes pour la multiplication et la division.
• Impossible de concaténer des éléments sur la pile.
• A une capacité très limitée de lire et de vérifier les données de transaction sur la chaîne. Le script Bitcoin ne peut pas accéder directement au montant de chaque transaction et ne peut pas passer d'état (les UTXO sont à usage unique et chaque transfert brûle les anciens et en génère de nouveaux).

Dans les premières versions de Bitcoin, certaines des fonctionnalités de « ne peut pas faire » mentionnées ci-dessus étaient possibles, mais certains opcodes ont été désactivés ultérieurement par Satoshi Nakamoto en raison de vulnérabilités de sécurité. Par exemple, l'opcode OP_CAT, qui pouvait combiner deux éléments de pile, était utilisé pour attaquer à distance les nœuds Bitcoin et provoquer des plantages. Satoshi a désactivé OP_CAT et d'autres opcodes pour des raisons de sécurité.

Alors, Bitcoin Script peut-il vérifier les SNARKs ? Théoriquement, même si Bitcoin Script n'est pas Turing-complet, ses opérations de base sont suffisantes pour vérifier n'importe quel calcul. Cependant, en pratique, la vérification des SNARKs n'est pas réalisable car la taille du programme requise pour les étapes de vérification dépasse la limite maximale de bloc de Bitcoin de 4 Mo. Bien que nous puissions essayer des opérations arithmétiques dans de grands champs finis, le coût serait prohibitif. Par exemple, dans BitVM, la multiplication de deux entiers de 254 bits a donné une taille de script Bitcoin d'environ 8 Ko. De plus, sans OP_CAT, le coût de vérification des preuves de Merkle est également élevé, car cela nécessite des opérations similaires à des boucles.

Alors, pourquoi ne pas simplement modifier le protocole Bitcoin pour ajouter des opcodes plus puissants ? Comme mentionné précédemment, parvenir à un consensus majoritaire sur de nouvelles règles de protocole est extrêmement difficile. Bitcoin manque d'un décideur centralisé, et toute proposition visant à améliorer Bitcoin Script fait face à une opposition considérable de la part des parties prenantes ayant des perspectives différentes. Il n'existe aucun moyen efficace de mesurer le consensus de la communauté dans le réseau Bitcoin, et forcer une mise à jour sans cela pourrait entraîner des divisions de chaînes. Bien sûr, Bitcoin n'est pas entièrement immuable. Les mises à jour les plus récentes étaient SegWit en 2017 et Taproot en 2021.

La mise à niveau Taproot, qui a modifié de nombreuses règles, a mis trois ans et demi pour passer d'une sortie théorique à une activation réelle. Le facteur clé permettant de rendre Taproot possible était qu'il n'a pas modifié les hypothèses de sécurité existantes et a apporté des améliorations claires au protocole Bitcoin. Par exemple, il permet l'utilisation de signatures Schnorr au lieu d'ECDSA. Les deux sont basés sur l'hypothèse du logarithme discret et utilisent la même courbe elliptique, mais le premier est plus efficace et nécessite moins de calcul.

De plus, les améliorations apportées à Bitcoin par Taproot peuvent être catégorisées en trois aspects suivants:

Premièrement, Taproot réduit les coûts de vérification des scripts avec de nombreuses branches conditionnelles, permettant à Bitcoin de prendre en charge des programmes plus complexes.

Deuxièmement, Taproot réduit la quantité de données de script à révéler sur la chaîne, et vous pouvez assembler plusieurs programmes de script dans un arbre de Merkle, chaque script étant situé sur une feuille différente. Si vous voulez déclencher un certain script, vous avez seulement besoin de révéler la feuille où il se trouve et la preuve de Merkle;

Troisièmement, Taproot a également ajouté d'autres conceptions de mécanismes.

Compte tenu du précédent de Bitcoin avec Taproot pour intégrer des fonctionnalités plus avancées, on peut se demander pourquoi un opcode dédié à la vérification SNARK n'a pas été introduit. La différence clé réside dans la complexité et le consensus requis pour OP_SNARK. Contrairement à Taproot, qui avait une conception claire et simple qui a bénéficié d'un large soutien, les propositions OP_SNARK varient considérablement, rendant difficile la mobilisation de la communauté autour d'une seule approche. Si elle était mise en œuvre, chaque nœud Bitcoin devrait prendre en charge cette méthode spécifique de vérification SNARK, ce qui augmenterait considérablement les exigences techniques. De plus, la complexité inhérente à OP_SNARK constitue un obstacle majeur - Taproot a ajouté environ 1 600 lignes de code, gérables selon les normes de la communauté, alors que OP_SNARK nécessiterait un codage bien plus complexe. En outre, déterminer qui évaluerait l'activation de OP_SNARK et parvenir à un consensus lorsque peu de personnes comprennent pleinement ses subtilités ajoute des difficultés supplémentaires. Compte tenu de ces défis, il est peu probable qu'une mise à niveau OP_SNARK se matérialise dans un avenir proche.

Cependant, il existe d'autres moyens de vérifier les SNARKs dans Bitcoin Script. Nous pouvons rendre les scripts Bitcoin plus fonctionnels en ajoutant des opcodes plus simples, permettant aux gens de mettre en œuvre des programmes de validation SNARK dans les scripts. Mais en réalité, il est très difficile d'écrire un programme de vérification SNARK dans le langage de script Bitcoin. C'est pourquoi l'équipe de recherche de Blockstream développe Simplicity, un langage de programmation conçu pour remplacer Bitcoin Script. Simplicity est spécifiquement conçu pour les systèmes de consensus de blockchain et n'est intentionnellement pas Turing-complet, ce qui facilite l'analyse statique et la vérification formelle.

Portons maintenant notre attention sur une proposition en apparence simple mais très impactante qui pourrait considérablement améliorer les capacités de script de Bitcoin : la réactivation de l'opcode OP_CAT. L'opcode OP_CAT a été initialement inclus dans le code initial de Bitcoin, mais a été désactivé ultérieurement par Satoshi Nakamoto en raison de son potentiel à permettre des attaques par déni de service dans des conditions spécifiques. Cependant, il existe désormais un intérêt croissant au sein de la communauté Bitcoin pour le réintroduire.

La fonction OP_CAT est simple - elle prend les deux éléments supérieurs de la pile, les concatène, puis pousse le résultat de nouveau sur la pile. Bien que cela puisse paraître basique, il a le potentiel de débloquer des améliorations substantielles dans le langage de script de Bitcoin. Par exemple, les scripts Bitcoin actuels ne sont pas en mesure d'accéder à certaines données de transaction sur chaîne, telles que les montants impliqués, mais avec OP_CAT, cette capacité pourrait être introduite. De plus, OP_CAT pourrait être instrumental dans la vérification des preuves de Merkle.

En essence, OP_CAT est une mise à niveau de l'opcode de bas niveau qui pourrait conduire à une large gamme de nouvelles fonctionnalités. Beaucoup ont souligné que OP_CAT pourrait être crucial pour atteindre divers objectifs. Une question clé est de savoir si OP_CAT pourrait aider à la vérification SNARK dans les scripts. La réponse est oui. Étant donné que la vérification de la preuve de Merkle est une étape vers la validation des SNARKs basés sur FRI, OP_CAT serait un ajout précieux. Dans le passé, les scripts conçus pour la vérification SNARK auraient pu être trop volumineux pour tenir dans les limites de taille de bloc de Bitcoin, mais OP_CAT pourrait aider à simplifier ces scripts, les rendant plus compacts.

OP_CAT a été discuté pendant des années, avec une prise de conscience croissante de son rôle potentiel dans l'introspection des transactions. L'un de ses principaux avantages par rapport à d'autres propositions est qu'il faisait autrefois partie intégrante de Bitcoin Script, ce qui pourrait faciliter l'obtention d'un consensus au sein de la communauté. Cependant, l'inconvénient est que l'activation d'OP_CAT pourrait avoir un impact négatif sur les profits de la valeur extractible par les mineurs (MEV), ce qui a donné lieu à un débat continu au sein de la communauté sur sa réactivation.

En résumé, Bitcoin pourrait faire un pas vers la vérification SNARK dans les scripts en réintroduisant des opcodes simples tels que OP_CAT. De plus, il convient de mentionner une proposition récente appelée la « Grande Restauration de Script », qui réintroduit un opcode de multiplication et permet à toutes les opérations arithmétiques d'être effectuées avec une précision arbitraire.

De plus, lors de l'évaluation de l'impact d'OP_CAT sur le réseau Bitcoin, il est important de prendre en compte ses effets sur les opérateurs de nœuds Bitcoin. Pour garantir que Bitcoin reste résistant à la censure et décentralisé, la communauté s'efforce d'avoir autant de personnes que possible qui exécutent des nœuds pour valider les transactions. Si Bitcoin devait mettre en œuvre la vérification SNARK, cela n'augmenterait pas significativement le coût de fonctionnement d'un nœud, ce qui n'affecterait pas beaucoup la sécurité ou la résistance à la censure de Bitcoin.

Actuellement, un bloc Bitcoin peut contenir jusqu'à 4 Mo de données, de nouveaux blocs étant extraits environ toutes les 10 minutes. La plupart des blocs sont remplis de scripts Bitcoin et de données de témoin (similaires aux signatures numériques). En moyenne, chaque bloc peut accueillir entre 7 000 et 10 000 vérifications de signatures, avec un maximum d'environ 80 000 vérifications par bloc. Pour donner un contexte, mon processeur Intel de 2020 met environ 3,2 secondes pour vérifier un bloc Bitcoin. Naturellement, la vitesse de vérification des blocs est influencée par des facteurs autres que le temps de vérification des signatures.

De plus, si les transactions Bitcoin prennent éventuellement en charge des preuves de connaissance zéro (ZK), toute augmentation du temps de génération des transactions pourrait ne pas être une préoccupation majeure. Les portefeuilles matériels, qui sont utilisés pour le stockage d'actifs à long terme, ont généralement des écrans et des designs compacts axés sur le stockage de clés et la création de signatures. Ces portefeuilles ont généralement des processeurs à faible consommation d'énergie, tels qu'un processeur double cœur de 240 MHz, mais ils gèrent efficacement les transactions Bitcoin.

J'ai réalisé une petite enquête en demandant aux utilisateurs quel était le délai maximum qu'ils accepteraient pour qu'un dispositif de signature génère une preuve, et beaucoup de personnes étaient d'accord pour attendre plus longtemps, surtout s'il y avait des gains significatifs à la clé. Donc, si nous introduisons ZK dans les transactions Bitcoin, il ne semble pas y avoir beaucoup de problèmes.Nous avons passé beaucoup de temps à discuter des changements potentiels de la conception sous-jacente de Bitcoin, mais il existe de nombreuses applications qui peuvent être développées sans modifier Bitcoin lui-même. Une application intéressante à mentionner est Chain State Proofs, qui est liée à BitVM. Cette approche utilise des preuves à divulgation nulle pour valider la justesse des hachages de blocs.

Quel impact cette technologie a-t-elle sur Bitcoin? Tout d'abord, les preuves d'état de chaîne peuvent considérablement réduire la charge de travail liée à la synchronisation et à la vérification des données historiques de Bitcoin, ce qui réduit à son tour les coûts liés à l'exécution d'un nœud. Actuellement, la synchronisation et la vérification des données depuis le bloc de genèse jusqu'au dernier bloc prennent environ 5 heures et 30 minutes sur un appareil haut de gamme, et plusieurs jours sur un appareil de niveau Raspberry Pi. Les preuves d'état de chaîne pourraient considérablement raccourcir ce processus.

Deuxièmement, les Preuves d'État de la Chaîne jouent un rôle crucial dans l'avancée de BitVM. L'équipe ZeroSync a effectué des recherches approfondies sur les Preuves d'État de la Chaîne et a développé une version simplifiée appelée « Preuves de chaîne d'en-tête ». Cette approche utilise des preuves à connaissance nulle pour valider les en-têtes de bloc Bitcoin, créant ainsi une « chaîne d'en-tête » qui englobe les 850 000 en-têtes de bloc de l'histoire de Bitcoin. Chaque en-tête de bloc est haché pour produire une preuve de 80 octets. Cette méthode nécessite des calculs SHA-256 doubles pour chaque en-tête afin de vérifier la preuve de travail associée. ZeroSync utilise des STARKs pour générer ces preuves de chaîne d'en-tête, ce qui coûte environ 4 000 $ à produire, tandis que la vérification ne prend que 3 secondes dans mon navigateur.

Cependant, étant donné que les preuves de chaîne de blocs d'en-tête ne vérifient pas les transactions au sein des blocs, elles ne peuvent supposer que la chaîne de blocs avec le plus de preuves de travail (PoW) est valide et compter sur les clients Bitcoin pour synchroniser les derniers blocs de cette chaîne. Dans cette configuration, un attaquant pourrait théoriquement créer des blocs avec des transactions invalides, ajouter plus de blocs après eux et générer une preuve de chaîne d'en-tête pour induire en erreur les clients synchronisant des données historiques. Cependant, le coût d'une telle attaque serait prohibitif et elle serait probablement détectée par les clients de nœuds complets Bitcoin existants.

Cependant, même si les chances de réussite d'une telle attaque sont faibles, si elle pouvait permettre aux attaquants de voler une quantité importante de BTC, les preuves de chaîne d'en-tête ne seraient pas considérées comme une solution totalement sécurisée. Pour vérifier l'état complet de la chaîne, nous devons nous assurer que tous les contenus des blocs Bitcoin sont valides, y compris les vérifications de signature ECDSA et Schnorr basées sur la courbe elliptique secp256k1. Les blocs historiques de Bitcoin contiennent environ 30 millions de signatures chaque mois, totalisant environ 2,5 milliards de signatures historiquement, ainsi que de nombreuses calculs SHA-256. En conséquence, le réseau Bitcoin génère environ 7 Go de données de bloc par mois, avec des données historiques dépassant 650 Go - et en pratique, ce chiffre pourrait être 2 à 3 fois plus élevé.

Regardons maintenant BitVM. BitVM permet à Bitcoin de vérifier n’importe quelle tâche de calcul, offrant ainsi un moyen optimal d’effectuer une vérification SNARK sans modifier le protocole. BitVM surmonte les limitations de taille de script de Bitcoin en utilisant deux méthodes. Tout d’abord, il s’appuie sur la structure de script Taproot MerkleTree. Deuxièmement, il utilise un schéma de stockage KV accessible entre les scripts individuels, ce qui facilite les connexions à un grand nombre de programmes de script. Cependant, le protocole Bitcoin n’impose pas l’intégrité de ce schéma de stockage KV. BitVM résout ce problème en utilisant des preuves de fraude pour détecter les prouveurs malveillants. Si un prouveur fait des déclarations invalides ou utilise un stockage KV défectueux, d’autres peuvent initier une transaction sur la blockchain Bitcoin pour signaler l’inconduite du prouveur et saisir les actifs jalonnés du prouveur.

En résumé, Bitcoin est confronté à d'importants défis et, bien que diverses propositions aient été avancées pour y remédier, il est peu probable qu'elles soient rapidement acceptées par la communauté Bitcoin. Les changements de protocole ne sont pas réalisables à court terme, ce qui reflète à la fois les forces et les contraintes de la décentralisation et de la sécurité de Bitcoin. Le potentiel des SNARKs et des STARKs suscite une grande excitation au sein de la communauté. BitVM semble être la méthode la plus prometteuse pour intégrer la vérification SNARK à moyen et long terme, mais elle nécessite des recherches et des développements supplémentaires pour être pleinement pratique. La réactivation de l'opcode OP_CAT est une autre piste à explorer, mais il faut démontrer que les avantages de la réactivation l'emportent sur les risques, et identifier quels opcodes simples pourraient faciliter la vérification SNARK ou des fonctions similaires dans les scripts Bitcoin. En fin de compte, la communauté Bitcoin vise à améliorer la praticité de la technologie et à soutenir des cas d'utilisation plus concrets.

Lire le contenu original ici :https://www.youtube.com/watch?v=GrSCZmFuy7U

Avertissement:

1. Cet article est repris de [ Geek Web3], Tous les droits d'auteur appartiennent à l'auteur original [Geek Web3]. Si vous avez des objections à cette réimpression, veuillez contacter leGate Learnl'équipe et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent aucun conseil 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.