Hier, j’ai demandé des droits d’accès API pour un projet. J’ai rempli le formulaire, puis j’ai attendu trois jours. L’e-mail m’a répondu que la validation avait été refusée, sans donner la moindre raison. Autrement dit, j’ai attendu pour rien.
Ce type d’approbation en « boîte noire » est malheureusement trop courant sur le Web2 : tu ne sais même pas où ça coince, et tu n’as aucune direction pour faire évoluer la situation.
Le ModelFactory d’OpenLedger transforme l’accès aux jeux de données en un processus d’approbation on-chain. Pour utiliser un modèle de micro-ajustement (fine-tuning) à partir de données Datanet, il faut d’abord déposer un montant en $OPEN et lancer une requête. Une fois la demande reçue, le fournisseur de données vote pour décider s’il te donne ou non les droits. Le résultat du vote et les raisons sont entièrement enregistrés on-chain. En cas de refus, tu peux aussi voir qui a voté contre et pour quelles raisons.
J’ai parcouru le livre blanc : ils utilisent un mécanisme de multisignature. Ce n’est pas une seule partie qui décide. Un jeu de données peut avoir plusieurs contributeurs. Chacun détient des droits de vote pondérés selon sa contribution. Pour obtenir les données, il faut obtenir un pourcentage de votes favorables dépassant un certain seuil. Cette conception empêche le fournisseur de données d’abuser de son pouvoir. Par exemple, le rejeter simplement parce qu’il ne t’aime pas.
En plus, si la requête est refusée, les $OPEN mis en gage sont remboursés intégralement selon l’itinéraire initial : aucune déduction n’a lieu. Ce n’est que si, après avoir obtenu les données, tu les utilises de manière non conforme et qu’un validateur le détecte, que le dépôt est confisqué. Le design est plutôt raisonnable : il distingue « demande échouée » et « utilisation non conforme ». Contrairement à certains projets qui déduisent de l’argent dès le moindre échec — c’est clairement piégeux pour l’utilisateur.
J’ai comparé avec d’autres plateformes d’IA : la plupart ont encore des processus d’approbation centralisés où l’administrateur décide. Tu n’as même pas de canal d’appel. Les premiers pools de mineurs de “l’époque des gros paiements” étaient aussi centralisés ; ensuite, ils ont progressivement été remplacés par des pools P2P, parce que tout le monde s’est rendu compte que la concentration du pouvoir engendre la corruption. Les contrats intelligents d’Ethereum ont aussi connu la même évolution : d’un contrôle centralisé vers une validation décentralisée. Cette mécanique d’approbation par vote on-chain d’OpenLedger reproduit, dans l’essence, le même chemin — à ceci près que le contexte est le contrôle d’accès aux jeux de données.
Mais j’ai aussi remarqué un problème : si de gros détenteurs avec des droits de vote importants se coordonnent pour s’opposer à un demandeur, en théorie ils pourraient le bannir définitivement. Le livre blanc ne décrit pas de mesures concrètes contre la collusion. Ce manque devra être corrigé.
Je vais attendre qu’il sorte quelques cas d’approbation réels avant d’évaluer si ce mécanisme est équitable.@OpenLedger #OpenLedger
Ce type d’approbation en « boîte noire » est malheureusement trop courant sur le Web2 : tu ne sais même pas où ça coince, et tu n’as aucune direction pour faire évoluer la situation.
Le ModelFactory d’OpenLedger transforme l’accès aux jeux de données en un processus d’approbation on-chain. Pour utiliser un modèle de micro-ajustement (fine-tuning) à partir de données Datanet, il faut d’abord déposer un montant en $OPEN et lancer une requête. Une fois la demande reçue, le fournisseur de données vote pour décider s’il te donne ou non les droits. Le résultat du vote et les raisons sont entièrement enregistrés on-chain. En cas de refus, tu peux aussi voir qui a voté contre et pour quelles raisons.
J’ai parcouru le livre blanc : ils utilisent un mécanisme de multisignature. Ce n’est pas une seule partie qui décide. Un jeu de données peut avoir plusieurs contributeurs. Chacun détient des droits de vote pondérés selon sa contribution. Pour obtenir les données, il faut obtenir un pourcentage de votes favorables dépassant un certain seuil. Cette conception empêche le fournisseur de données d’abuser de son pouvoir. Par exemple, le rejeter simplement parce qu’il ne t’aime pas.
En plus, si la requête est refusée, les $OPEN mis en gage sont remboursés intégralement selon l’itinéraire initial : aucune déduction n’a lieu. Ce n’est que si, après avoir obtenu les données, tu les utilises de manière non conforme et qu’un validateur le détecte, que le dépôt est confisqué. Le design est plutôt raisonnable : il distingue « demande échouée » et « utilisation non conforme ». Contrairement à certains projets qui déduisent de l’argent dès le moindre échec — c’est clairement piégeux pour l’utilisateur.
J’ai comparé avec d’autres plateformes d’IA : la plupart ont encore des processus d’approbation centralisés où l’administrateur décide. Tu n’as même pas de canal d’appel. Les premiers pools de mineurs de “l’époque des gros paiements” étaient aussi centralisés ; ensuite, ils ont progressivement été remplacés par des pools P2P, parce que tout le monde s’est rendu compte que la concentration du pouvoir engendre la corruption. Les contrats intelligents d’Ethereum ont aussi connu la même évolution : d’un contrôle centralisé vers une validation décentralisée. Cette mécanique d’approbation par vote on-chain d’OpenLedger reproduit, dans l’essence, le même chemin — à ceci près que le contexte est le contrôle d’accès aux jeux de données.
Mais j’ai aussi remarqué un problème : si de gros détenteurs avec des droits de vote importants se coordonnent pour s’opposer à un demandeur, en théorie ils pourraient le bannir définitivement. Le livre blanc ne décrit pas de mesures concrètes contre la collusion. Ce manque devra être corrigé.
Je vais attendre qu’il sorte quelques cas d’approbation réels avant d’évaluer si ce mécanisme est équitable.@OpenLedger #OpenLedger
