Résumé:

Delphi Digital a récemment publié un rapport intitulé "L'aube de la programmabilité du Bitcoin : Paver la voie pour les Rollups", qui décrit les concepts clés liés aux Rollups Bitcoin, y compris la suite BitVM, les restrictions OP_CAT et Covenant, la couche DA de l'écosystème Bitcoin, les ponts et quatre principales solutions de couche 2 utilisant BitVM : Bitlayer, Citrea, Yona et Bob. Bien que le rapport donne un aperçu de la technologie Bitcoin de couche 2, il reste assez général et manque de descriptions détaillées, le rendant quelque peu difficile à saisir. Geek Web3 a étendu le rapport Delphi pour aider plus de gens à comprendre systématiquement des technologies comme BitVM.

Nous travaillerons avec l'équipe de recherche Bitlayer et la communauté chinoise BitVM pour lancer une série intitulée "Approaching BTC". Cette série mettra l'accent sur des sujets clés tels que BitVM, OP_CAT et les ponts inter-chaînes Bitcoin, dans le but de démystifier les technologies de la couche 2 de Bitcoin pour un public plus large et de préparer le terrain pour plus d'enthousiastes.

Il y a quelques mois, Robin Linus, le leader de ZeroSync, a publié un article intitulé “BitVM : Compute Anything on Bitcoin”, introduisant officiellement le concept de BitVM et faisant avancer la technologie Bitcoin Layer 2. Il s'agit de l'une des innovations les plus révolutionnaires de l'écosystème Bitcoin, suscitant un intérêt et une activité significatifs dans l'espace Bitcoin Layer 2. Il a attiré des projets remarquables comme Bitlayer, Citrea et BOB, apportant une nouvelle énergie sur le marché. Depuis lors, d'autres chercheurs ont rejoint pour améliorer BitVM, donnant lieu à plusieurs versions itératives telles que BitVM1, BitVM2, BitVMX et BitSNARK. La vue d'ensemble générale est la suivante :

1. Robin Linus a initialement présenté le livre blanc de mise en œuvre de BitVM l'année dernière, qui est basé sur un circuit conceptuel de portes logiques et est connu sous le nom de BitVM0.
2. Lors de présentations ultérieures et d'entretiens, Robin Linus a informellement introduit un concept BitVM basé sur un CPU théorique, appelé BitVM1. Cela est similaire au système de preuve de fraude Cannon d'Optimism, et il peut simuler l'effet d'un CPU polyvalent hors chaîne en utilisant des scripts Bitcoin.
3. Robin Linus a également proposé BitVM2, un protocole de preuve de fraude non interactif en une seule étape sans permission.
4. Les membres de Rootstock Labs et Fairgate Labs ont publié un livre blanc sur BitVMX. Similaire à BitVM1, ils visent à simuler l'effet d'un processeur généraliste hors chaîne en utilisant des scripts Bitcoin.

Pour l'instant, la construction de l'écosystème de développeurs lié à BitVM devient de plus en plus claire, et l'amélioration itérative des outils périphériques est également visible à l'œil nu. Comparé à l'année dernière, l'écosystème BitVM d'aujourd'hui est devenu "vaguement visible" depuis le "château en l'air" initial, ce qui a également attiré de plus en plus de personnes. De plus en plus de développeurs et de VC se précipitent dans l'écosystème Bitcoin.

Pour la plupart des gens, comprendre BitVM et les termes techniques liés à Bitcoin Layer 2 n'est pas facile. Cela nécessite une maîtrise systématique des connaissances fondamentales, en particulier des scripts Bitcoin et de Taproot. Les ressources en ligne existantes sont souvent soit trop longues et remplies de détails non pertinents, soit trop succinctes pour être claires. Nous avons pour objectif de résoudre ces problèmes en utilisant un langage clair et concis pour aider plus de gens à comprendre les concepts fondamentaux de Bitcoin Layer 2 et à acquérir une compréhension complète du système BitVM.

MATT et Engagements: Le concept central de BitVM

Le concept central de BitVM tourne autour de MATT, qui signifie Merkleize All The Things. Cette approche utilise un arbre de Merkle, une structure de stockage de données hiérarchique, pour représenter l'exécution de programmes complexes. Elle vise à permettre la vérification native de la preuve de fraude sur le réseau Bitcoin. MATT peut capturer les détails d'un programme complexe et ses activités de traitement de données, mais ne publie pas ces données étendues directement sur la blockchain Bitcoin en raison de leur taille importante. Au lieu de cela, l'approche MATT stocke ces données dans un arbre de Merkle hors chaîne et publie uniquement la racine de Merkle (le résumé le plus élevé de l'arbre de Merkle) sur la blockchain. L'arbre de Merkle contient principalement trois composants clés:

• Code de script de contrat intelligent
• Données requises pour le contrat
• Traces d'exécution du contrat (enregistrements des modifications de la mémoire et des registres CPU lors de l'exécution de contrats intelligents dans des machines virtuelles comme l'EVM)

(Un schéma schématique simple de l'arbre de Merkle. Sa racine de Merkle est calculée à partir des 8 fragments de données en bas de l'image à travers le hachage multi-couches)

Dans le cadre du schéma MATT, seule la très petite racine de Merkle est stockée sur la chaîne, et l'ensemble des données contenues dans l'arbre de Merkle est stocké hors chaîne. Cela utilise une idée appelée « engagement ». Voici une explication de ce qu'est l'« engagement ».

Une promesse est comme une déclaration succincte, nous pouvons la comprendre comme l'“empreinte” obtenue après compression d'une grande quantité de données. En règle générale, la personne qui émet un “engagement” sur la chaîne déclarera que certaines données stockées hors chaîne sont exactes. Ces données hors chaîne doivent correspondre à une déclaration concise, et cette déclaration est l'“engagement.”

À un moment donné, le hachage des données peut être utilisé comme un "engagement" envers les données elles-mêmes. D'autres schémas d'engagement incluent l'engagement KZG ou l'arbre de Merkle. Dans le protocole habituel de preuve de fraude de Layer2, l'éditeur de données publiera l'ensemble complet de données hors chaîne et un engagement de publier l'ensemble de données sur chaîne. Si quelqu'un découvre des données invalides dans l'ensemble de données hors chaîne, l'engagement de données sur chaîne sera contesté.

Grâce à l'engagement, la deuxième couche peut compresser une grande quantité de données et ne publier que son "engagement" sur la chaîne Bitcoin. Bien sûr, il est également nécessaire de s'assurer que l'ensemble complet de données publiées hors chaîne peut être observé par le monde extérieur.

Actuellement, les principaux schémas BitVM tels que BitVM0, BitVM1, BitVM2 et BitVMX suivent tous une structure abstraite similaire :

1. Décomposition du programme et engagement: Initialement, un programme complexe est décomposé en de nombreux opcodes de base (compilation). Les traces d'exécution de ces opcodes (essentiellement les changements d'état lorsqu'un programme s'exécute sur le CPU et la mémoire, connus sous le nom de Trace) sont enregistrées. Toutes les données, y compris la Trace et les opcodes, sont organisées dans un ensemble de données, et un engagement est généré pour cet ensemble de données. Divers schémas d'engagement peuvent être utilisés, tels que les arbres de Merkle, les PIOPs (divers algorithmes ZK), et les fonctions de hachage.
2. Participation aux actifs et pré-signature: Le éditeur de données et le vérificateur doivent verrouiller un certain montant d'actifs sur la blockchain via une pré-signature, avec des conditions restrictives spécifiques. Ces conditions déclenchent des actions pour des événements futurs potentiels. Si l'éditeur de données agit de manière malveillante, le vérificateur peut soumettre une preuve et prendre les actifs de l'éditeur de données.
3. Publication de données et d'engagement: L'éditeur de données publie l'engagement on-chain et le jeu de données complet off-chain. Le vérificateur récupère et vérifie le jeu de données pour les erreurs. Chaque partie du jeu de données off-chain est liée à l'engagement on-chain.
4. Défi et pénalité: Si le vérificateur trouve des erreurs dans les données fournies par l'éditeur de données, il apporte cette partie des données on-chain pour une vérification directe (nécessitant des données finement détaillées). Ce processus suit la logique des preuves de fraude. Si les données sont confirmées comme étant invalides, les actifs de l'éditeur de données seront pris par le vérificateur contestataire. En résumé, l'éditeur de données, Alice, divulgue toutes les traces générées lors de l'exécution des transactions de la couche 2 hors chaîne et publie l'engagement correspondant on-chain. Pour prouver qu'une partie des données est incorrecte, vous devez d'abord montrer au nœud Bitcoin que ces données se rapportent à l'engagement on-chain, confirmant qu'elles ont été divulguées par Alice, puis le nœud Bitcoin vérifie l'exactitude des données. Après avoir compris l'idée générale de BitVM, toutes les variantes de BitVM adhèrent à ce paradigme de base. Ensuite, nous nous plongerons dans certaines des principales technologies utilisées dans ce processus, en commençant par les fondamentaux des scripts Bitcoin, Taproot et les pré-signatures.

Qu'est-ce que le script Bitcoin?

Comprendre Bitcoin peut être plus difficile que Ethereum, car même les transactions les plus simples impliquent plusieurs concepts clés. Il s'agit notamment de UTXO (Unspent Transaction Output), des scripts de verrouillage (également connus sous le nom de ScriptPubKey) et des scripts de déverrouillage (également connus sous le nom de ScriptSig). Décortiquons d'abord ces concepts fondamentaux.

(Un exemple de code de script Bitcoin se compose d'opcodes de bas niveau par rapport aux langages de haut niveau) La méthode de représentation des actifs d'Ethereum est similaire à des systèmes tels qu'Alipay ou WeChat, où chaque transaction ajuste simplement les soldes des différents comptes. Cette approche basée sur les comptes traite les soldes d'actifs comme de simples chiffres associés aux comptes. En revanche, la représentation des actifs de Bitcoin est plus semblable à celle de la négociation de l'or, où chaque morceau d'or (UTXO) est étiqueté avec un propriétaire. Une transaction Bitcoin détruit essentiellement l'ancien UTXO et en crée un nouveau, la propriété changeant dans le processus. Un UTXO Bitcoin comprend deux composants clés:

• Montant: Mesuré en “satoshis” (un BTC équivaut à cent millions de satoshis);
• Script de verrouillage (ScriptPubKey): Cela définit les conditions requises pour déverrouiller l'UTXO. La possession de l'UTXO Bitcoin est déterminée par le script de verrouillage. Par exemple, si vous souhaitez transférer votre UTXO à Sam, vous initieriez une transaction qui détruit votre UTXO et crée un nouveau avec la condition « uniquement Sam peut déverrouiller ». Lorsque Sam veut utiliser ces bitcoins, il doit soumettre un script de déverrouillage (ScriptSig). Dans ce script, Sam fournit sa signature numérique pour prouver son identité. Si le script de déverrouillage correspond au script de verrouillage original, Sam peut alors déverrouiller les bitcoins et les transférer à quelqu'un d'autre.

(Le script de déverrouillage doit correspondre au script de verrouillage) Dans les transactions Bitcoin, chaque transaction se compose de plusieurs entrées et sorties. Chaque entrée spécifie une UTXO à déverrouiller et fournit un script de déverrouillage pour le faire, qui déverrouille ensuite et détruit l'UTXO. Les sorties de la transaction montrent les UTXO nouvellement créées et affichent publiquement les scripts de verrouillage associés. Par exemple, dans une entrée de transaction, vous prouvez que vous êtes Sam en déverrouillant plusieurs UTXO que d'autres vous ont envoyés, les détruisant dans le processus. Ensuite, vous créez plusieurs nouveaux UTXO et spécifiez que xxx peut les déverrouiller à l'avenir.

Plus précisément, dans les données d’entrée d’une transaction, vous devez déclarer les UTXO que vous avez l’intention de déverrouiller et spécifier le « lieu de stockage » de ces données UTXO. Il est important de comprendre que Bitcoin et Ethereum gèrent cela différemment. Ethereum utilise des comptes contractuels et des comptes détenus par des tiers (EOA) pour stocker des données, les soldes d’actifs étant enregistrés sous forme de chiffres sous ces comptes. Toutes ces informations sont stockées dans une base de données appelée « État mondial ». Lorsqu’une transaction a lieu, « l’état mondial » met directement à jour les soldes de comptes spécifiques, ce qui facilite la localisation des données. En revanche, Bitcoin n’a pas d'« État mondial ». Au lieu de cela, les données sur les actifs sont distribuées entre les blocs précédents sous forme d’UTXO non dépensés, stockés individuellement dans la sortie de chaque transaction.

Si vous voulez déverrouiller un certain UTXO, vous devez indiquer dans quelle sortie de transaction l'information UTXO existe dans le passé, et montrer l'ID de la transaction (qui est son hachage). Laissez le nœud Bitcoin le rechercher dans l'historique. Si vous voulez interroger le solde Bitcoin d'une certaine adresse, vous devez parcourir tous les blocs depuis le début pour trouver l'UTXO déverrouillé associé à l'adresse xx.

Lorsque vous utilisez habituellement un portefeuille Bitcoin, vous pouvez rapidement vérifier le solde de Bitcoin détenu par une certaine adresse. Cela est souvent dû au fait que le service de portefeuille lui-même indexe toutes les adresses en scannant les blocs, ce qui nous permet de consulter rapidement.

(Lorsque vous créez une transaction pour transférer votre UTXO à quelqu'un d'autre, vous devez spécifier l'emplacement de ce UTXO dans l'historique des transactions de Bitcoin en faisant référence à l'identifiant/à la hachure de la transaction à laquelle il appartient.) Fait intéressant, les résultats des transactions Bitcoin sont calculés hors chaîne. Lorsque les utilisateurs génèrent des transactions sur leurs appareils locaux, ils doivent créer tous les inputs et outputs au préalable, calculant ainsi efficacement les outputs de la transaction. La transaction est ensuite diffusée sur le réseau Bitcoin, vérifiée par les nœuds, et ajoutée à la blockchain. Ce modèle de "calcul hors chaîne - vérification sur chaîne" est totalement différent de celui d'Ethereum. Sur Ethereum, vous n'avez besoin de fournir que les paramètres d'entrée de la transaction, et les résultats de la transaction sont calculés et produits par les nœuds Ethereum. De plus, le script de verrouillage d'un UTXO peut être personnalisé. Vous pouvez définir un UTXO comme "déverrouillable par le propriétaire d'une adresse Bitcoin spécifique", exigeant du propriétaire qu'il fournisse une signature numérique et une clé publique (P2PKH). Dans les transactions Pay-to-Script-Hash (P2SH), vous pouvez ajouter un script Hash au script de verrouillage du UTXO. Toute personne capable de soumettre le script correspondant à ce hash et de remplir les conditions spécifiées dans le script peut déverrouiller le UTXO. Le script Taproot, sur lequel BitVM s'appuie, utilise des fonctionnalités similaires à celles des P2SH.

Comment déclencher un script Bitcoin

Pour comprendre le mécanisme de déclenchement des scripts Bitcoin, nous commencerons par l'exemple P2PKH, qui signifie « Payer à la hachage de clé publique ». Dans cette configuration, le script de verrouillage d'un UTXO contient un hachage de clé publique et pour le déverrouiller, la clé publique correspondante doit être fournie. Ce mécanisme est conforme au processus standard des transactions Bitcoin. Dans ce contexte, un nœud Bitcoin doit vérifier que la clé publique dans le script de déverrouillage correspond au hachage de clé publique spécifié dans le script de verrouillage. Essentiellement, il vérifie que la « clé » fournie par l'utilisateur correspond à la « serrure » définie par l'UTXO. Plus en détail, dans le cadre du schéma P2PKH, lorsqu'un nœud Bitcoin reçoit une transaction, il combine le script de déverrouillage de l'utilisateur (ScriptSig) avec le script de verrouillage (ScriptPubKey) de l'UTXO à déverrouiller, puis exécute ce script combiné dans l'environnement d'exécution de script Bitcoin. L'image ci-dessous illustre le résultat concaténé avant l'exécution :

Les lecteurs ne sont peut-être pas familiers avec l’environnement d’exécution de script BTC, alors présentons-le brièvement. Les scripts Bitcoin se composent de deux éléments : les données et les opcodes. Ces éléments sont poussés sur une pile séquentiellement de gauche à droite et exécutés selon la logique spécifiée pour produire le résultat final (pour une explication de ce qu’est une pile, les lecteurs peuvent consulter ChatGPT). Dans l’exemple ci-dessus, le côté gauche montre le script de déverrouillage (ScriptSig) fourni par quelqu’un, qui inclut sa signature numérique et sa clé publique. Le côté droit montre le script de verrouillage (ScriptPubKey), qui contient une série d’opcodes et de données définis par le créateur de l’UTXO lors de la génération de cet UTXO (il suffit de comprendre l’idée générale ; nous n’avons pas besoin de nous plonger dans la signification de chaque opcode). Les opcodes du script de verrouillage de droite, tels que DUP, HASH160 et EQUALVERIFY, hachent la clé publique à partir du script de déverrouillage de gauche et la comparent au hachage de clé publique prédéfini dans le script de verrouillage. S’ils correspondent, il confirme que la clé publique dans le script de déverrouillage correspond au hachage de clé publique dans le script de verrouillage, en réussissant la première vérification. Cependant, il y a un problème : le contenu du script de verrouillage est visible publiquement sur la blockchain, ce qui signifie que tout le monde peut voir le hachage de la clé publique. Par conséquent, n’importe qui pourrait soumettre la clé publique correspondante et prétendre faussement être la personne autorisée. Pour résoudre ce problème, après avoir vérifié la clé publique et le hachage de la clé publique, le système doit également vérifier si l’initiateur de la transaction contrôle réellement la clé publique, ce qui implique de vérifier la signature numérique. L’opcode CHECKSIG dans le script de verrouillage gère cette vérification. En résumé, dans le cadre du schéma P2PKH, le script de déverrouillage de l’initiateur de la transaction doit inclure la clé publique et la signature numérique. La clé publique doit correspondre au hachage de clé publique spécifié dans le script de verrouillage, et la signature numérique doit être correcte. Ces conditions doivent être remplies pour réussir à déverrouiller l’UTXO.

(Il s'agit d'une illustration dynamique : un diagramme des scripts de déverrouillage de Bitcoin sous le schéma P2PKH
Source:https://learnmeabitcoin.com/technical/script)

Il est important de noter que le réseau Bitcoin prend en charge différents types de transactions au-delà de Pay to Public Key / Public Key Hash, tels que P2SH (Pay to Script Hash). Le type spécifique de transaction dépend de la façon dont le script de verrouillage est configuré lorsque l'UTXO est créée.

Il est important de comprendre que dans le cadre du schéma P2SH, le script de verrouillage peut prédéfinir un hachage de script, et le script de déverrouillage doit fournir le contenu complet du script correspondant à ce hachage de script. Le nœud Bitcoin peut ensuite exécuter ce script, et s'il inclut une logique de vérification à plusieurs signatures, il active efficacement les portefeuilles à plusieurs signatures sur la blockchain Bitcoin. Dans le cadre du schéma P2SH, le créateur de la UTXO doit informer la personne qui déverrouillera la UTXO à l'avenir du contenu du script correspondant au hachage de script. Tant que les deux parties sont conscientes du contenu du script, nous pouvons mettre en œuvre une logique métier encore plus complexe que simplement la signature multiple. Il convient également de noter que la blockchain Bitcoin n'enregistre pas directement quelles UTXO sont liées à quelles adresses. Au lieu de cela, elle enregistre quelles UTXO peuvent être déverrouillées par quel hachage de clé publique ou hachage de script. Cependant, nous pouvons rapidement déduire l'adresse correspondante (la chaîne de caractères qui ressemble à du charabia affichée dans les interfaces de portefeuille) à partir du hachage de clé publique ou du hachage de script.

La raison pour laquelle vous pouvez voir le montant de Bitcoin associé à une adresse spécifique sur les explorateurs de blocs et les interfaces de portefeuille est que ces services analysent et interprètent les données de la chaîne de blocs pour vous. Ils analysent tous les blocs et, en fonction du hachage de clé publique ou du hachage de script déclaré dans les scripts de verrouillage, calculent l'"adresse" correspondante. Cela leur permet d'afficher combien de Bitcoin est associé à cette adresse.

Témoin Segregué et Témoin

Comprendre P2SH nous rapproche de Taproot, un composant crucial pour BitVM. Cependant, avant de plonger dans Taproot, il est essentiel de saisir le concept de témoin et de témoin séparé (SegWit). Examiner les scripts de déverrouillage et de verrouillage, ainsi que le processus de déverrouillage de l'UTXO, met en évidence un problème : la signature numérique d'une transaction est incluse dans le script de déverrouillage. Lors de la génération de cette signature, le script de déverrouillage lui-même ne peut pas faire partie des données signées (car les paramètres utilisés pour générer la signature ne peuvent pas inclure la signature elle-même).

Par conséquent, la signature numérique ne peut couvrir que des parties des données de transaction en dehors du script de déverrouillage, ce qui signifie qu'elle ne peut pas protéger entièrement l'ensemble des données de transaction. Cela entraîne une vulnérabilité où un intermédiaire peut légèrement modifier le script de déverrouillage sans affecter la vérification de la signature. Par exemple, les nœuds Bitcoin ou les pools de minage pourraient insérer des données supplémentaires dans le script de déverrouillage. Même si cette altération n'affecte pas la vérification et le résultat de la transaction, elle modifie légèrement les données de transaction, ce qui modifie à son tour le hachage de transaction/ID de transaction calculé. Ce problème est connu sous le nom de malléabilité de transaction.

Le problème avec cela est que si vous prévoyez d'initier plusieurs transactions séquentielles qui dépendent les unes des autres (par exemple, la transaction 3 fait référence à la sortie de la transaction 2, et la transaction 2 fait référence à la sortie de la transaction 1), les transactions subséquentes doivent faire référence aux hachages des transactions précédentes. Tout intermédiaire, comme un pool de minage ou un nœud Bitcoin, peut apporter de légères modifications au script de déverrouillage, ce qui entraîne une différence du hachage de transaction par rapport à votre attente une fois qu'il est sur la blockchain.

Cette divergence peut invalider votre séquence prévue de transactions interdépendantes. Cette question est particulièrement pertinente dans le contexte des ponts DLC et de BitVM2, où des lots de transactions séquentiellement liées sont construits, rendant de tels scénarios assez courants.

En termes simples, le problème de malléabilité de la transaction se produit parce que le calcul de l’ID de transaction/hachage inclut les données du script de déverrouillage. Les intermédiaires, tels que les nœuds Bitcoin, peuvent apporter de légères modifications au script de déverrouillage, ce qui entraîne un ID de transaction qui ne correspond pas aux attentes de l’utilisateur. Ce problème découle des premières limitations de conception de Bitcoin. La mise à niveau de Segregated Witness (SegWit) résout ce problème en dissociant l’ID de transaction du script de déverrouillage. Avec SegWit, le calcul du hachage de la transaction exclut les données du script de déverrouillage. Les scripts de verrouillage UTXO sous SegWit commencent par un opcode « OP_0 » comme marqueur, et le script de déverrouillage correspondant est renommé de SigScript à Witness.

En adhérant aux règles Segregated Witness (SegWit), le problème de malléabilité des transactions est efficacement résolu, éliminant ainsi les inquiétudes concernant la falsification des données de transaction par les nœuds Bitcoin. La fonctionnalité de P2WSH (Pay to Witness Script Hash) est essentiellement la même que celle de P2SH (Pay to Script Hash). Vous pouvez prédéfinir un hachage de script dans le script de verrouillage UTXO, et la personne qui soumet le script de déverrouillage fournira le contenu de script correspondant à la chaîne pour exécution. Cependant, si le contenu du script dont vous avez besoin est très volumineux et contient beaucoup de code, les méthodes conventionnelles peuvent ne pas vous permettre de soumettre l’intégralité du script à la blockchain Bitcoin (en raison des limites de taille des blocs). Dans de tels cas, Taproot entre en jeu. Taproot permet de compresser le contenu des scripts on-chain, ce qui permet de gérer des scripts plus volumineux. BitVM s’appuie sur Taproot pour créer des solutions plus complexes. Dans le prochain article de notre série « Approche du BTC », nous fournirons des explications détaillées sur Taproot, la pré-signature et d’autres technologies avancées liées à BitVM. Rester à l'écoute!

Avertissement :

1. Cet article est repris de [Geek Web3], avec des droits d'auteur appartenant aux auteurs originaux [Nickqiao & Faust & Shew Wang]. Si vous avez des objections à la reproduction, veuillez contacter le Porte Apprendrel'équipe, et l'équipe le traitera rapidement selon les procédures pertinentes.
2. Avis de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux des auteurs et ne constituent aucun conseil en investissement.
3. D'autres versions de l'article ont été traduites par l'équipe Gate Learn. Sans mentionnerGate.io, les articles traduits ne doivent pas être copiés, diffusés ou plagiés.