Ritual vs Bittensor : quelles différences ?

Ces deux noms ne renvoient pas à une même cryptomonnaie liée à l’IA. La différence tient au rôle de chaque réseau. Ritual Chain est une chaîne EVM dont l’identifiant est 784, et les règles d’approvisionnement de RITUAL sont établies sur cette chaîne. Acheter du RITUAL au comptant sur Gate ne modifie pas la manière dont un sous-réseau rémunère les mineurs.

La comparaison ci-dessous s’appuie sur la documentation de Ritual Chain, la page consacrée à la tokénomique de RITUAL et le guide du réseau Bittensor. Le tableau utilise uniquement les données indiquées dans ces trois pages.

Points clés

• Ritual règle les appels de modèles, les appels HTTP et les planifications sur une chaîne EVM. Bittensor enregistre l’appartenance aux sous-réseaux et les émissions sur subtensor, tandis que le travail lui-même s’exécute hors chaîne.

• Sur Ritual, l’appelant prépaye en RITUAL. Sur Bittensor, la chaîne émet des TAO pour le travail évalué par les validateurs.

• Ritual peut conserver les entrées d’un appel dans un environnement d’exécution de confiance. Le guide de minage de Bittensor indique que les requêtes adressées aux mineurs ne bénéficient d’aucune garantie de confidentialité.

• Bittensor ajoute un jeton alpha par sous-réseau en plus du TAO. L’actif natif de Ritual est RITUAL, avec une représentation bridgée qui n’augmente pas l’offre totale.

• Commencez par le besoin : un appel unique sur chaîne, ou un marché qui évalue des producteurs concurrents. Il ne s’agit pas d’un classement des rendements futurs.

Ces lignes présentent des éléments de conception issus des documents liés, et non une notation. Lorsqu’une page ne fournit pas d’information, la ligne ne comble pas ce manque par un slogan.

Qu’est-ce que Ritual et Ritual Chain ?

Ritual Chain est la Layer 1 compatible EVM du réseau Ritual. Un smart contract paie en RITUAL pour appeler un modèle, demander des données externes, exécuter une tâche d’IA et programmer une exécution ultérieure. Le projet désigne cette couche sous le nom d’EVM++, une machine virtuelle Ethereum étendue aux applications d’IA et aux calculs plus intensifs sur chaîne. L’identifiant de chaîne est 784. Le RITUAL natif ne possède pas d’adresse de contrat. Une forme bridgée sur BNB Smart Chain et Base partage l’adresse 0x256Ea35422b2F36B24aC1D66159Fe69e75918C37 et n’augmente pas l’offre totale, car les jetons de la chaîne source sont verrouillés.

L’appelant approvisionne un solde sponsorisé dans RitualWallet. Chaque tâche asynchrone réserve un budget maximal, est réglée, puis l’excédent est remboursé. Ritual utilise une conception de consensus appelée Symphony pour les charges de travail d’IA. Les frais de gas ordinaires constituent un paiement distinct, effectué par le signataire de la transaction. La page consacrée à la tokénomique indique qu’au lancement, les exécuteurs sont admis au moyen d’une attestation matérielle et d’une liste approuvée. Cette liste limite les personnes autorisées à exécuter la tâche. Il ne s’agit pas d’un enregistrement de mineurs de type Bittensor, où un hotkey brûle des frais pour rejoindre un sous-réseau puis concourt pour recevoir des émissions.

L’offre initiale est de 10 milliards, dont 18 % seront déverrouillés lors du mainnet public du 26 octobre 2026, avec un verrouillage d’un an pour les initiés, tandis que les votes contraignants des stakers restent un objectif ultérieur. Ces règles décrivent la dilution. Elles n’indiquent pas si un contrat doit appeler Ritual ou interroger un sous-réseau Bittensor.

Qu’est-ce que Bittensor ?

Bittensor est une blockchain, subtensor, qui coordonne et rémunère du travail utile. Bittensor a lancé son mainnet en 2023. Le travail s’effectue hors chaîne au sein de sous-réseaux, où la chaîne coordonne et rémunère des modèles d’IA ou d’autres services hors chaîne. La chaîne enregistre les participants, mesure le consensus sur la qualité du travail et émet des TAO. Le guide du réseau indique un temps de bloc d’environ 12 secondes. Subtensor repose sur Substrate et non sur une chaîne EVM ; un contrat Solidity ne peut donc pas y être déployé comme il le serait sur Ritual Chain.

Un sous-réseau est un marché d’incitation doté d’un netuid entier. Son propriétaire définit le mécanisme et les hyperparamètres. Les mineurs sont des hotkeys qui produisent la ressource du sous-réseau, qui peut être de l’inférence, du stockage, des prédictions ou d’autres travaux et modèles, selon le code de ce sous-réseau. Les validateurs sont des hotkeys disposant d’un stake suffisant pour obtenir une autorisation. Ils évaluent les mineurs en définissant des pondérations, souvent à partir des résultats actuels et, dans certains modèles, de signaux liés aux performances passées. À la limite d’une époque, le consensus Yuma combine ces pondérations, selon le stake des validateurs, afin de déterminer les parts d’émissions.

Le TAO est le jeton natif. Chaque sous-réseau possède également un alpha, échangé contre du TAO dans le pool de ce sous-réseau. Staker du TAO dans un sous-réseau l’échange contre de l’alpha au prix du pool. L’alpha d’un sous-réseau n’est pas l’alpha d’un autre. Le réseau racine, netuid 0, ne possède ni mineurs ni alpha. La limite de places d’un sous-réseau est fixée par défaut à 256 neurones, et l’entrée dans un sous-réseau complet évince le neurone non immunisé le moins bien classé. Ces règles rendent les places de sous-réseau limitées. Bittensor organise le travail au moyen d’incitations, et non d’un barème de frais de gas.

Où les modèles d’IA s’exécutent-ils ?

Sur Ritual, l’appel est un objet sur chaîne. La documentation définit des types générés par le protocole pour un appel planifié, un engagement asynchrone qui réserve un séquestre, et un règlement qui paie l’exécuteur ou renvoie le résultat. Les calculs intensifs peuvent s’exécuter à côté du client d’exécution, dans un sidecar décrit par le projet, afin que chaque validateur n’ait pas à répéter la même tâche. Les nœuds peuvent également se spécialiser dans différentes charges de travail au lieu d’exécuter tous le même travail. La chaîne doit néanmoins accepter la sortie attestée. Infernet, le réseau d’oracles décentralisé de Ritual pour l’IA, coordonne l’accès à ce travail externe. Vérifier une transaction consiste à examiner l’identifiant de chaîne 784 et l’attestation de l’exécuteur, et non l’adresse axon hors chaîne d’un mineur.

Sur Bittensor, la chaîne n’exécute pas le modèle. Les mineurs publient un point de terminaison axon. Les validateurs envoient des requêtes à ce point de terminaison, puis inscrivent des pondérations sur chaîne. Le guide de minage précise que la ressource est définie par le code propre au sous-réseau et que le service du point de terminaison ne démarre pas automatiquement lorsque le hotkey rejoint le sous-réseau. Si le mineur change de machine, il doit publier le nouvel axon. Le rôle de la chaîne concerne l’appartenance, les pondérations et les émissions. L’échec d’un modèle est un échec hors chaîne qui apparaît plus tard sous la forme d’un score faible, et non comme une transaction EVM annulée. Le sous-réseau et ses points de terminaison se situent hors du chemin d’exécution de la chaîne, mais affectent néanmoins les incitations sur chaîne.

Pour un développeur, c’est là que se situe la distinction. Si le travail doit être réglé comme un appel unique sur chaîne, utilisez Ritual. Si une évaluation hors chaîne ultérieure est acceptable, utilisez Bittensor. Intégrer un UID de sous-réseau dans un contrat Ritual, ou une précompilation Ritual dans un sous-réseau, nécessite un bridge distinct. Aucune des deux chaînes ne propose ce chemin par défaut.

Qui paie et qui reçoit le jeton dans les entités autonomes ?

Le payeur sur Ritual est l’utilisateur de l’appel. Des RITUAL quittent RitualWallet lorsqu’un exécuteur renvoie un résultat, lorsqu’un appel HTTP est dimensionné ou lorsqu’un appel planifié arrive à échéance. Les agents paient pour continuer à fonctionner ; une planification continue crée donc une demande continue d’appels financés en RITUAL. Si le solde est vide, la planification ne se poursuit pas gratuitement. L’émission existe toujours : la page consacrée à la tokénomique décrit des récompenses de staking commençant à environ 5 % annualisés, versées aux validateurs, aux exécuteurs et aux délégateurs, tandis que les frais de base sont brûlés. Cette émission rémunère les rôles de sécurité et d’exécution. Elle ne correspond pas à la facture d’un prompt spécifique. Le prompt possède son propre prix, publié sur chaîne pour chaque modèle.

Sur Bittensor, le payeur du travail lui-même est le calendrier d’émissions. La chaîne émet des TAO vers les sous-réseaux, puis vers les participants proportionnellement à la valeur mesurée. Les validateurs gagnent des dividendes lorsque leurs pondérations correspondent au consensus et partagent ces dividendes avec les nominateurs après prélèvement d’une commission. Les mineurs reçoivent la part d’incitation du sous-réseau. Les stakers qui délèguent reçoivent une part des dividendes des validateurs. Le guide du réseau renvoie à une répartition des émissions par tempo. Le signal destiné à un mineur est de produire ce que les validateurs rémunèrent. La demande ne parvient au mineur qu’au travers de ces scores, et non parce qu’un appelant identifié a prépayé cette réponse HTTP.

Les deux mécanismes peuvent être qualifiés d’incitations, mais le paiement et l’usage approprié diffèrent. Les frais de Ritual augmentent lorsqu’une personne souhaite un appel spécifique et accepte de le prépayer. L’émission de Bittensor intervient lorsque des validateurs pondérés par le stake considèrent que le mineur a accompli la tâche du sous-réseau, même si aucun utilisateur unique n’a prépayé cette réponse. L’inférence facturée à l’usage se traduit par un débit dans RitualWallet. La production rémunérée par émission se traduit par une incitation de sous-réseau et des dividendes. Confondre les deux revient à mal interpréter la conception, par exemple en évaluant Ritual selon les émissions de TAO ou un sous-réseau selon qu’un appel Solidity a été annulé.

Le calendrier de déverrouillage de RITUAL n’est pas le halving du TAO, et le prix de marché d’aucun des deux actifs n’entre dans cette comparaison. Les RITUAL verrouillés ne peuvent pas être stakés. Le poids du stake sur Bittensor suit sa propre formule : l’alpha staké sur ce sous-réseau, auquel s’ajoute le stake en TAO du réseau racine ajusté par un poids TAO défini par la gouvernance. Comparer les rendements de staking des deux systèmes sans tenir compte de ces formules ne revient pas à comparer le même mécanisme.

Comment le travail est-il vérifié ?

Ritual vérifie un appel par attestation et règlement. L’exécuteur est censé prouver qu’il a exécuté un logiciel approuvé dans un environnement d’exécution de confiance. La chaîne paie ensuite à partir du budget réservé ou enregistre le résultat. Un environnement d’exécution de confiance masque les entrées à l’opérateur matériel, et son parcours d’attestation permet de vérifier comment la tâche a été exécutée. Cela ne prouve pas, à lui seul, que le modèle est celui attendu par l’utilisateur, sauf si la politique d’attestation lie ce logiciel. La page consacrée à la tokénomique indique que la liste approuvée fait partie du processus d’admission au lancement. Une liste fermée est plus facile à superviser et à censurer. La vérification inclut les deux aspects.

Bittensor vérifie le travail par l’accord entre validateurs stakés. Un validateur dont les pondérations restent proches du consensus conserve ses dividendes. Un validateur qui perd son autorisation perd ses dividendes et ses obligations. Les mineurs qui gagnent peu se rapprochent de l’éviction une fois leur immunité terminée. La vérification est sociale et pondérée par le stake, au sens technique du consensus Yuma, et non une attestation matérielle d’une enclave unique. Le guide de minage ajoute une limite de confidentialité : les requêtes circulent entre validateurs et mineurs sans garantie de confidentialité. Un prompt qui doit rester caché à l’opérateur ne doit pas emprunter ce chemin, à moins qu’un sous-réseau spécifique ajoute des protections que le guide de base ne revendique pas.

Une vérification se situe hors de ces deux conceptions : déterminer si la réponse est vraie. Les attestations et pondérations de validateurs présentées dans ces pages ne vérifient pas les faits énoncés par le modèle. Ritual vérifie que le calcul a été exécuté comme convenu. Bittensor vérifie les scores attribués par les pairs. Aucun des deux ne prouve que la réponse elle-même est correcte. Un produit nécessitant une vérification factuelle requiert toujours une source extérieure à la couche d’incitation.

Quel réseau convient à quel besoin ?

Choisissez Ritual si le besoin est un contrat sur une chaîne EVM qui doit appeler un modèle, interroger un point de terminaison HTTP ou se planifier lui-même, et que l’appelant est prêt à prépayer en RITUAL. Cela inclut un agent dont la clé et le budget se trouvent sur la chaîne d’identifiant 784, ainsi qu’un développeur qui programme déjà en Solidity. Cela n’inclut pas le souhait d’être rémunéré en TAO pour servir des mineurs anonymes.

Choisissez Bittensor si le besoin consiste à produire la ressource d’un sous-réseau en concurrence avec d’autres mineurs, ou à évaluer ces mineurs en tant que validateur, dans le cadre d’un calendrier d’émissions et d’un pool alpha. Cela inclut une équipe qui crée une ressource de sous-réseau autour de laquelle mineurs et validateurs peuvent concourir, ainsi qu’une équipe qui souhaite que la chaîne rémunère un travail utile sans client unique prépayant chaque réponse. Cela n’inclut pas le déploiement d’un contrat EVM existant sur subtensor en s’attendant à ce que des précompilations Ritual apparaissent.

Ne choisissez ni l’un ni l’autre, et utilisez une conception différente, si l’exigence porte sur une gouvernance contraignante des détenteurs de jetons dès les premiers mois, des prompts privés sur le chemin par défaut des mineurs de Bittensor, ou un ensemble ouvert d’exécuteurs Ritual sans liste approuvée. Les pages citées ne décrivent pas ces éléments comme des fonctionnalités déjà actives au lancement. Les limites déterminent qui peut participer au lancement.

Après ce choix, l’achat de l’actif relève du trading au comptant. Acheter du TAO n’enrôle pas un mineur. Acheter du RITUAL ne déploie pas un agent. L’achat ne modifie qu’un solde, et la paire RITUAL/USDT doit toujours correspondre au réseau de dépôt.

Quelles sont les limites de cette comparaison ?

Ces paramètres évoluent ; c’est donc la valeur indiquée sur la page au moment considéré qui prévaut. Les hyperparamètres de Bittensor, tels que le poids du TAO dans le stake, la limite d’autorisations de validateurs et la durée d’immunité, sont définis par la gouvernance ou par le sous-réseau, et le guide du réseau recommande de consulter la valeur en direct. La liste d’exécuteurs, le barème des frais et l’objectif du 12e mois concernant les votes contraignants de Ritual sont des déclarations de lancement figurant sur la page de tokénomique, et non une promesse que la liste restera fermée pour toujours. Cette comparaison couvre les mécanismes tels qu’ils ont été publiés, et non un vote ultérieur.

L’autre limite tient au niveau de détail des explications publiques. Les explications publiques de Ritual s’arrêtent souvent à « AI Layer 1 » et n’indiquent pas qui prépaye, ou présentent la gouvernance comme une fonction déjà assurée par le jeton, alors que les votes contraignants des stakers interviennent plus tard. Les explications publiques de Bittensor s’arrêtent souvent à une désignation générale telle que « IA décentralisée » et omettent les détails opérationnels utilisés ici, notamment l’alpha, les points de terminaison axon et l’absence de garantie de confidentialité. Cette comparaison ne classe pas les jetons et n’estime pas les rendements.

Résumé

Ritual est une Layer 1 EVM où les smart contracts prépayent en RITUAL des opérations d’IA telles qu’un appel de modèle, un appel HTTP ou une planification, et où un exécuteur peut exécuter ce travail dans un environnement d’exécution de confiance figurant sur une liste approuvée. Bittensor est une chaîne Substrate où les mineurs produisent des solutions d’IA hors chaîne dans des marchés de sous-réseaux évalués, les validateurs définissent des pondérations, et les émissions de TAO ainsi qu’un pool alpha par sous-réseau rémunèrent les participants selon le consensus Yuma. Utilisez Ritual pour un appel structuré comme un contrat avec un budget réservé. Utilisez Bittensor pour un marché évalué de producteurs. Le marché au comptant sur lequel le RITUAL est négocié constitue une étape distincte de ces deux conceptions.

FAQ

En quoi Ritual diffère-t-il de Bittensor ?

Ritual exploite une chaîne EVM d’identifiant 784, sur laquelle les contrats prépayent en RITUAL des appels de modèles, HTTP et planifiés, et Infernet est le réseau d’oracles décentralisé de Ritual pour l’IA. Bittensor exploite subtensor, où le travail des sous-réseaux s’effectue hors chaîne et où la chaîne émet des TAO selon les pondérations des validateurs. L’un est un chemin d’appel prépayé pour les modèles d’intelligence. L’autre est un marché d’émissions destiné aux producteurs de sous-réseaux.

Bittensor utilise-t-il le même type de staking que Ritual ?

Non. Les RITUAL déverrouillés sont stakés ou délégués aux validateurs Ritual, et les RITUAL verrouillés ne peuvent pas être stakés. Sur Bittensor, staker du TAO dans un sous-réseau l’échange contre l’alpha de ce sous-réseau, et les autorisations de validateurs dépendent du poids du stake. Les deux flux de récompenses ne sont pas interchangeables.

Un smart contract Ritual peut-il appeler un mineur Bittensor ?

Pas sous la forme d’une précompilation intégrée sur l’une ou l’autre chaîne. Un contrat Ritual n’appelle pas un mineur Bittensor par défaut, même si Infernet est le réseau d’oracles décentralisé de Ritual pour l’IA. Les appels Ritual passent par ses propres exécuteurs et RitualWallet. Les mineurs Bittensor sont contactés lorsqu’un validateur envoie une requête à un axon. Un bridge entre les deux serait une application distincte, et non le chemin de règlement par défaut.

Quel réseau préserve la confidentialité des prompts ?

La conception de Ritual peut placer les entrées dans un environnement d’exécution de confiance afin que les prompts soient cachés aux personnes exploitant la machine. Le guide de minage de Bittensor indique que les requêtes entre validateurs et mineurs ne bénéficient d’aucune garantie de confidentialité ; son chemin par défaut n’offre donc pas le même contrôle de la confidentialité. Un prompt qui doit rester caché correspond à la première description, et non à la seconde, à moins qu’un sous-réseau spécifique n’ajoute une protection que le guide de base ne mentionne pas.

L’achat de RITUAL ou de TAO choisit-il le réseau pour un développeur ?

Non. Un achat au comptant ne modifie qu’un solde. Le déploiement d’un contrat sur Ritual ou l’enregistrement d’un hotkey sur un sous-réseau Bittensor constitue une étape distincte. Les développeurs examinent également les outils, leur mode de connexion et leur capacité à créer pour un nouveau marché. L’ordre au comptant n’enrôle ni mineur ni exécuteur. Les événements planifiés et les hackathons de Ritual sont des programmes communautaires. Acheter le jeton ne sélectionne pas le réseau.