Un échantillon d'entraînement, un fichier de poids, un appel d'inférence — qui doit être rémunéré ? Les plateformes traditionnelles répondent avec leur propre registre et un accord papier ; les contributeurs ne peuvent ni vérifier facilement, ni faire appliquer. L'absence de droits est d'abord une lacune d'ingénierie et d'institutions, non un déficit de slogans. Cet article présente les mécanismes qui rendent les droits exécutables, et la manière dont les conceptions liées à Bitroot s'articulent au règlement et à l'informatique de confiance.
Trois registres opaques
Données : une fois remises à une plateforme, les contributeurs ne peuvent souvent pas prouver quels modèles ont utilisé leurs échantillons, encore moins réclamer une part lorsque les modèles génèrent des revenus. Les données deviennent une matière première jetable au lieu d'un actif traçable.
Modèles : les paramètres et la structure sont des actifs numériques dépourvus de droits communs, de licences et de comptage des appels. Lorsque les poids résident en un seul endroit, les tiers ne peuvent pas vérifier de manière indépendante le nombre d'appels ni les revenus ; les concepteurs acceptent le décompte de règlement de la plateforme.
Revenus : même les plateformes volontaires s'appuient encore sur un audit manuel et des contrats hors ligne — lents et propices aux litiges. Les parties prenantes des données, des modèles et du calcul ne disposent pas d'une machine à états de paiement partagée qui s'exécute telle qu'elle est écrite.
Le passage « on-chain » n'efface pas ces lacunes à lui seul ; la chaîne fournit seulement un environnement d'exécution programmable et auditable. Pour la carte des lacunes de confiance, voir Convergence entre le Web3 et l'IA.
Des registres de plateforme à un pipeline vérifiable
Le schéma oppose la comptabilité unilatérale d'une plateforme à une intuition de flux de valeur fondée sur index + cryptographie + contrat (illustratif — il ne s'agit pas d'une promesse financière) :
Des métadonnées on-chain, pas l'intégralité du corpus
Une approche raisonnable enregistre on-chain les hachages de fichiers, les versions, les tailles et les empreintes de différences ; les charges utiles restent dans un stockage décentralisé ou objet, avec livraison par fragments et vérifications de Merkle pour l'intégrité du téléchargement. Chacun peut vérifier que les fragments récupérés correspondent à l'enregistrement — la chaîne n'a pas besoin d'héberger les corpus bruts. Cela n'équivaut pas à « frapper le jeu de données comme une image ».
Contrôle d'accès : clés à seuil + audit TEE facultatif
Les données et modèles commerciaux nécessitent un contrôle d'accès. Le chiffrement à seuil / MPC fractionne les clés afin que le déchiffrement ou la signature exige un quorum, réduisant le vol par un nœud unique. Les changements d'accès et d'autorisation doivent laisser des enregistrements on-chain ; les tranches sensibles peuvent s'exécuter dans des TEE pour un audit d'usage borné par le matériel — en acceptant les risques de canal auxiliaire et de chaîne d'approvisionnement. Répartition des rôles : Cadre d'informatique de confiance.
Poids de modèle : utilisables sans être dérobables
Un problème difficile des actifs de modèle consiste à permettre aux nœuds de servir l'inférence sans donner à une contrepartie unique l'intégralité des poids. Une voie d'ingénierie est le partage à seuil (t, n) : n'importe quelles t parts permettent d'agréger un résultat d'inférence ; moins de t parts ne donnent aucun poids utilisable. Les nœuds calculent sur des parts locales, agrègent via MPC et peuvent adjoindre des contraintes ZK pour vérifier l'intégrité de la sortie.
Les droits d'usage et la pleine propriété peuvent être séparés techniquement ; le droit d'auteur et les licences juridiques nécessitent toujours des contrats et des juridictions — les règles on-chain ne remplacent pas chaque texte de loi sur le droit d'auteur.
Répartition par contrat intelligent : les parts comme machine à états
Lorsque les appels génèrent des revenus, les contrats déclenchent des paiements à partir de parts préenregistrées : contributeurs de données, concepteurs de modèles et fournisseurs de calcul disposent chacun de ratios on-chain ; chaque règlement est auditable. Cela répond à la question de savoir si les règles s'exécutent — pas si les ratios sont équitables (cela relève toujours de la gouvernance et de la négociation).
La connexion sociale / les clés de session à seuil abaissent l'obstacle d'expérience utilisateur lié à la clé privée, mais exposent la garde et la récupération à l'ensemble des participants MPC ; explicitez ce modèle de menace.
Comment cela rejoint le règlement et le calcul
Les machines de droits et de paiement ont besoin d'une confirmation prévisible et d'un débit suffisant — en particulier pour la facturation d'inférence à haute fréquence et les répartitions multi-contrats. Lorsqu'un EVM parallèle optimiste constitue le substrat de règlement, lisez les chiffres de performance comme des objectifs de testnet ou d'ingénierie et surveillez si les points chauds de conflit effondrent le parallélisme — voir Vue d'ensemble de l'architecture EVM parallèle de Bitroot et Glossaire des métriques de performance. Interfaces d'acceptation des tâches et de paiement : Calcul distribué GPU et edge. Limites de capacité : Chaîne de blocs native pour l'IA.
Cet article ne traite ni n'implique aucun rendement ni retour sur investissement.
Trois pièges de conception courants
Une propriété purement affichée, sans transitions de révocation ou de répartition ; un comptage incontestable qui recentralise la facturation ; l'ignorance de l'héritage de version ou de licence pour les ajustements fins et la distillation. Un MVP plus stable : enregistrement de hachages + répartitions simples par appel + licences révocables, avec un mécanisme de litige fonctionnel avant les schémas à seuil complexes. Séparez le discours sur les mécanismes de l'imagination de rendement. Savoir si le règlement supporte les répartitions de micropaiements : Conception de l'exécution parallèle multi-moteur.
Selon les juridictions, les règles on-chain fournissent au mieux des « programmes à exécution automatique convenus entre les parties » ; elles n'effacent pas la copie hors plateforme et ne statuent pas sur la contrefaçon éventuelle des corpus d'entraînement. La documentation doit indiquer ce que le système garantit (hachages, événements de licence, exécution des répartitions) et ce qu'il ne garantit pas (titre de droit d'auteur mondial, niveaux de rendement). Protection des accès : Cadre d'informatique de confiance ; lacunes de confiance : Convergence Web3–IA.
Si les répartitions impliquent de nombreux paiements minuscules à haute fréquence, évaluez aussi l'abstraction de compte, le règlement par lots ou les canaux hors ligne afin que le gaz et la gigue de confirmation ne dévorent pas la répartition elle-même. Ce sont des choix d'architecture applicative au-dessus de la capacité de règlement — non des raisons pour qu'un L1 subventionne chaque répartition. Ceci ne constitue pas un conseil en investissement ou en rendement.
Comptage, révocation et litiges : la seconde moitié des droits
L'enregistrement de hachages n'est qu'un début. Des droits exécutables exigent aussi un comptage anti-double, l'arrêt de la facturation à l'expiration ou en cas de manquement à la licence, un multisig ou une gouvernance pour les changements de parts, et la capacité de geler les flux pendant les litiges de droit d'auteur sans détruire les pistes d'audit. Sans ces machines à états, les index on-chain ne sont que des clés primaires coûteuses.
Lors du raccordement aux réseaux de calcul, l'acceptation ne doit pas être automatiquement assimilée à « payable » — les appelants ont toujours besoin d'une licence valide. Les micro-répartitions à haute fréquence sur une couche de règlement parallèle amplifient le gaz et la surface de conflit ; une agrégation hors ligne avec des engagements de détail contestables peut être nécessaire. Conflits : Points chauds de conflit et charges de travail. Place dans la pile : La pile d'IA décentralisée.
Tension entre confidentialité et audit public
Les droits veulent l'auditabilité ; les données commerciales veulent la confidentialité. Le partage à seuil et les TEE aident, mais ne peuvent pas offrir simultanément « n'importe qui vérifie chaque inférence » et « les poids ne quittent jamais un ensemble de confiance » à un coût quasi nul. Les produits doivent choisir un public principal : audit du régulateur, contrôle des paiements aux contributeurs, ou inférence vérifiable publiquement — chacun avec une courbe de coût différente.
Évitez de laisser entendre à la fois une confidentialité totale, une vérifiabilité publique totale et un coût quasi nul. Une stratification honnête : comptage et répartitions on-chain ; détails hors ligne autorisés ; preuves minimales en cas de litige. Rôles de l'informatique de confiance : Cadre d'informatique de confiance.
À retenir
Des droits exécutables nécessitent des métadonnées vérifiables, des clés et des poids à seuil, un accès auditable et des contrats de paiement automatiques — superposés à l'informatique de confiance et au règlement. Ils font passer « qui a contribué à quoi, selon quelle règle » d'une boîte noire de plateforme à une machine à états vérifiable. Ils ne règlent pas automatiquement les litiges de droit d'auteur et ne transforment pas les réseaux de calcul en produits de rendement. Lors de la lecture de documents connexes, privilégiez les modèles de menace et les flux d'acceptation.