Un mois, quelqu’un m’a demandé : son frère, qui contribue au réseau de test d’OpenLedger, a fourni une série de données. Plus tard, son portefeuille a reçu un petit virement. Ce n’était pas beaucoup, juste assez pour acheter un Americano. Il voulait savoir précisément à quel appel de modèle cette somme correspondait, quelle donnée avait réellement été utilisée. Il a retourné tous les historiques du navigateur, mais n’a trouvé aucune réponse. Sur la chaîne, il n’apparaît qu’un seul hash de règlement groupé, contenant quelques milliers d’attributions : impossible de les dissocier.
Je lui ai dit que cette confusion était particulièrement réaliste. Le partage des attributions peut, mathématiquement, être déterminé avec énormément de décimales, mais ce registre exact n’est pas ouvert au public pour toi personnellement. Tu peux voir le résultat, mais pas le processus. C’est comme si tu allais à la cantine et qu’à la fin du mois on te disait que tu as mangé pour huit cents yuans au total, sans te dire à quel repas correspondait quel plat. Tu sais que le total est correct, mais tu veux quand même savoir combien coûte exactement ce bol de porc braisé.
Cela mène à une question très simple. Avec le mécanisme de Proof of Attribution, l’attribution est faite, mais en tant que contributeur, comment vérifiez-vous que vos données ont bien été prises en compte ? On ne stocke on-chain que le résultat agrégé, sans enregistrer les détails de chaque micro-attribution. Ce n’est pas que l’équipe ne veuille pas les stocker : c’est qu’elle n’en a pas les moyens. Mettre en chaîne toutes les données d’attribution de plusieurs dizaines de millions d’appels ferait exploser la taille des blocs, et le gas serait entièrement consumé. Donc, sur le plan de l’ingénierie, il faut comprimer : ne garder que le grand livre, et jeter le flux.
Ce compromis est raisonnable, mais il modifie le modèle de confiance. En l’absence de détails, vous ne pouvez qu’avoir confiance que le système a correctement calculé, et vous n’avez pas la possibilité de vérifier par vous-même. Cela contredit l’intention initiale de la blockchain, à savoir « sans avoir besoin de faire confiance ». Vous pouvez dire que c’est un défi commun à tous les systèmes de micro-attribution à l’heure actuelle, mais le fait est : c’est un défi, pas une difficulté qui doit être emballée comme « chaque contribution est clairement visible ».
@Openledger Peut-on résoudre ce problème ? Je pense qu’on peut le traiter en deux étapes. Première étape : fournir un service de requêtes d’attribution hors chaîne. Ne pas écrire les détails dans la blockchain, mais permettre aux contributeurs, via une interface, de retrouver le nombre d’appels de chaque élément de leurs données et le montant de leur part. Les données ne sont pas on-chain, mais au moins vous pouvez voir les détails : vous n’avez qu’à additionner vous-même avec une calculatrice et vérifier que le total correspond à la comptabilité globale sur la chaîne. Deuxième étape : hacher régulièrement le résumé de ce service de requêtes et le publier sur la blockchain, afin de garantir que les résultats de la requête n’ont pas été falsifiés. Ainsi, on économise du gas, tout en offrant aux contributeurs un moyen de vérification.
À l’heure actuelle, la feuille de route ne précise pas clairement cette conception dans le livre blanc, mais j’espère qu’elle est déjà en cours. Sans détails d’attribution, c’est comme un supermarché qui ne fournit pas de ticket : on ne peut qu’y croire quand il dit qu’il n’y a pas d’erreur de comptabilité.
Parlons aussi de OpenLoRA. En réalité, le modèle de paiement à l’usage est naturellement porteur de détails. À chaque fois que vous appelez le modèle, le système enregistre une trace, et la facture que vous recevez à la fin du mois comporte des lignes. Si l’attribution des parts pouvait s’inspirer de cette logique—lier l’appel et l’attribution—alors les contributeurs pourraient retrouver, via l’ID d’appel, quelle a été l’ampleur de leur contribution. Sur le plan technique, ce n’est pas impossible : c’est une question de coûts de calcul et de stockage. Mais l’orientation est juste.
Je regarde aussi souvent l’évolution du Bitcoin et d’Ethereum. Si ces deux chaînes tournent, c’est parce que l’essentiel est que n’importe qui peut vérifier chaque transaction. Le pouvoir de vérification est délégué à chaque nœud, sans avoir à faire confiance à un intermédiaire. #OpenLedger Si on veut construire une couche de règlement des valeurs à l’ère de l’IA, il faut affronter les mêmes standards. Les détails de l’attribution n’ont pas besoin d’être entièrement enregistrés on-chain, mais les moyens de vérification doivent être donnés à tout le monde.
$OPEN Dans cette valeur, une partie est précisément focalisée sur ce problème. Si les contributeurs ne peuvent jamais qu’accepter passivement les résultats de règlement, sans pouvoir les vérifier par eux-mêmes, alors la crédibilité de ce système manquera d’un support clé.
Je pense que l’équipe comprend bien ce problème. J’espère qu’à la prochaine mise à jour, on verra un outil permettant au grand public de consulter les détails, sans avoir besoin de connaître les arbres de Merkle, ni de lancer des nœuds : il suffit de cliquer quelques fois pour voir combien d’argent chaque jeu de données vous a rapporté. À ce moment-là, PoA sera vraiment bouclé. #