Pearl vs Bittensor, Akash et Render : principales différences

Les lecteurs qui savent déjà qu’un GPU peut entraîner ou servir un modèle doivent encore distinguer trois architectures : le travail qui crée le bloc, le travail que les validateurs évaluent et le travail pour lequel un acheteur paie. Pearl relève de la première architecture. Un score ou une location peut rester utile à un acheteur, tandis que la chaîne hôte continue de produire des blocs sans ce travail GPU.

Un travail accepté, un score élevé attribué par les validateurs et une réponse gagnante pour une tuile répondent à des questions différentes. Le prix et la disponibilité ne suffisent pas à placer un réseau dans la même architecture.

Points clés

• La loterie de blocs de Pearl repose sur une multiplication matricielle effectuée par un GPU sur sa propre chaîne. Bittensor verse des TAO lorsque les validateurs évaluent les résultats d’un subnet. Akash et Render facturent une location ou un travail, tandis que leurs chaînes hôtes produisent des blocs par staking.
• Une preuve Pearl valide montre qu’une tuile de sortie sélectionnée a été recalculée et qu’elle a atteint le niveau de difficulté requis. Elle ne montre pas que les matrices provenaient du passage avant d’un modèle payant.
• Les listes de matériel publiées par des mineurs tiers ne constituent pas des constantes du protocole. Le parcours documenté de Pearl repose sur un nœud et un mineur vLLM. Akash répertorie des ressources de conteneurs. Render attribue des travaux GPU à des opérateurs de nœuds.
• Les actifs natifs ont des fonctions différentes : le PRL correspond à la subvention de bloc de Pearl, le TAO suit les scores agrégés, l’AKT mis en staking produit les blocs d’Akash tandis qu’une location est payée en ACT, et le RENDER est brûlé pour payer un travail tandis que les opérateurs sont rémunérés selon un calendrier d’émissions distinct.

Que fait réellement chaque réseau ?

Pearl est une blockchain de couche 1 dont l’unité de travail est une multiplication matricielle effectuée par un GPU. Le livre blanc Pearl INT décrit une conception de preuve de travail utile dans laquelle cette multiplication peut également servir de preuve de bloc. Le mineur choisit les matrices, et les tuiles du produit servent de tickets de loterie. Le mineur qui trouve un ticket gagnant publie le bloc et reçoit une rémunération en PRL. Sur Gate, le symbole de marché au comptant de cet actif natif est PEARL.

Bittensor est un réseau ouvert de subnets. Les mineurs produisent une ressource, comme de la puissance de calcul, de l’inférence, du stockage ou de la prédiction. Les validateurs évaluent les mineurs en attribuant des poids, puis le consensus Yuma agrège ces poids au lieu d’évaluer directement le travail. Les créateurs de subnets définissent les mécanismes d’incitation, les stakers soutiennent les validateurs avec des TAO et la chaîne verse des TAO à partir de cet agrégat. Un score élevé constitue un jugement fondé sur les incitations du subnet concerné, et non une règle selon laquelle un produit matriciel doit être la préimage du bloc suivant.

Akash Network est une marketplace de puissance de calcul conteneurisée construite avec le SDK Cosmos et CometBFT. Un locataire décrit le CPU, la mémoire, le stockage et, lorsqu’il est proposé, le GPU dans un fichier de déploiement. Les fournisseurs soumettent des offres, le locataire en accepte une et la chaîne enregistre une location. La preuve d’enjeu déléguée sélectionne les validateurs d’Akash. Le GPU qui exécute le conteneur est le produit loué, et non l’énigme que ces validateurs doivent résoudre.

Render Network attribue des travaux GPU, notamment de rendu et d’autres tâches de calcul associées, à des opérateurs de nœuds. RENDER est un actif SPL sur Solana. Un créateur brûle des RENDER pour obtenir des crédits de travail et soumettre un travail, tandis que les opérateurs de nœuds sont rémunérés selon un calendrier d’émissions distinct, et non avec les tokens brûlés. Les validateurs de Solana produisent les blocs de Solana. Le règlement d’un travail met à jour l’enregistrement du travail sur Render, et non la loterie de blocs de Solana.

Le travail utile, comme une multiplication matricielle, produit-il le bloc ?

Parmi ces quatre réseaux, seul le modèle de Pearl fait du travail utile un élément qui produit le bloc. Les mineurs de Pearl recherchent une tuile dont le hachage atteint la cible de difficulté. Cette recherche constitue la preuve de travail. Répéter ces multiplications jusqu’à ce qu’une tuile soit gagnante rend coûteuse la production d’un historique concurrent.

Les trois autres réseaux peuvent servir un acheteur tout en produisant leurs blocs ailleurs. Bittensor rémunère ce que chaque subnet définit, et le TAO suit les poids agrégés par Yuma. Akash paie un conteneur dans le cadre d’une location. Render paie un travail terminé. Ces chaînes peuvent continuer à produire des blocs même si le marché des GPU devient inactif : la chaîne de Bittensor utilise la preuve d’autorité, tandis qu’Akash et Solana utilisent le staking. Aucun de ces trois réseaux n’utilise le travail GPU comme énigme de bloc.

Figure 1. Pearl paie pour une tuile gagnante issue d’une multiplication matricielle qui produit le bloc. Les trois autres réseaux paient pour un score, une location ou un travail.

Une marketplace peut avoir des clients payants alors que sa chaîne fonctionne grâce au staking. Une chaîne fondée sur une preuve de travail utile peut produire des blocs à partir de multiplications qu’aucun client n’a demandées. Un échec de Pearl met fin à cette tentative sans subvention, un poids Bittensor faible met fin à cette émission, une offre Akash rejetée met fin à cette proposition et un règlement Render échoué met fin à ce travail.

Que prouve réellement une vérification réussie ?

La vérification de Pearl prouve un fait précis. La spécification en virgule flottante étend une preuve de multiplication matricielle entière : le mineur s’engage sur des entrées, le bruit issu de ces engagements est appliqué et le produit est divisé en tuiles. Le vérificateur ne recalcule pas l’intégralité du produit. Il ouvre une tuile, vérifie les preuves de Merkle, dérive les seeds de bruit, recalcule cette tuile et vérifie que le ticket atteint la difficulté requise.

Une vérification réussie signifie que la tuile correspond et que le ticket est gagnant. Elle ne signifie pas qu’un client a reçu des tokens issus d’un modèle. Le mineur choisit les entrées, car un réseau ouvert ne peut pas supposer qu’un donneur de tâche est honnête. L’argument de sécurité repose sur le coût de la multiplication, y compris avec des entrées dégénérées, et non sur un registre de modèles approuvés.

Une étude indépendante de cette limite, The Usefulness Gap in Proof-of-Useful-Work, indique que la vérification accepte un produit matriciel terminé et ne teste pas si les matrices provenaient d’un modèle. Des matrices aléatoires peuvent réussir la vérification. L’étude indique également que le logiciel de minage dominant dans son échantillon ne contenait pas de code d’inférence. Une vérification de tuile fiable peut donc rester valide alors qu’une charge de travail d’inférence payante demeure facultative.

Pour Bittensor, une vérification réussie correspond à un score. Les validateurs examinent les résultats des mineurs en fonction des incitations du subnet et attribuent des poids. Un poids élevé signifie que ces validateurs ont attribué de la valeur au résultat. Cela ne signifie pas que chaque subnet vend des services d’inférence à un client externe, ni que les calculs du mineur ont été réexécutés comme une tuile de consensus. L’introduction de Bittensor expose cette distinction : les mineurs produisent la ressource, les validateurs évaluent les mineurs et les stakers soutiennent les validateurs avec des TAO.

Pour Akash, une vérification réussie correspond à une location. La chaîne enregistre l’offre, l’acceptation par le locataire et les conditions. La fourniture du service constitue ensuite un fait opérationnel concernant un conteneur exécuté sur les machines d’un fournisseur. Une location clôturée ne prouve pas que les GPU du fournisseur entraînent un modèle donné, à moins que la charge de travail du locataire ne soit précisément ce modèle.

Pour Render, une vérification réussie correspond au règlement d’un travail. Un opérateur de nœud est rémunéré lorsque le réseau accepte le travail conformément aux règles applicables au travail et à la réputation. Le règlement prouve l’enregistrement du travail, et non que les mêmes cycles GPU ont servi de preuve de bloc sur Solana. La réputation peut augmenter ou diminuer selon le travail fourni. Ce score de service relève des poids de Bittensor, contrairement à la vérification de tuile de Pearl.

En quoi les parcours matériels et logiciels diffèrent-ils ?

Le parcours de minage documenté de Pearl repose sur une pile GPU construite autour d’un mineur vLLM et d’un nœud Pearl. Le nœud fournit les modèles de blocs. L’adresse du mineur est une adresse Taproot précédée de prl1p sur le réseau principal. La rémunération arrive lorsque ce travail permet de trouver un bloc : elle comprend la subvention et les frais, et non un paiement à l’heure de disponibilité.

Des programmes tiers publient leurs propres listes d’appareils et leurs propres estimations de hashrate. Ces chiffres mesurent les performances de cette version logicielle et ne constituent pas une constante du protocole. Un programme qui demande une phrase de récupération prend le contrôle du portefeuille, car le minage nécessite uniquement une adresse de réception. Un pool peut lisser la variance. L’unité de travail reste la multiplication matricielle.

Le matériel utilisé sur Bittensor dépend du subnet. Un subnet d’inférence peut nécessiter des GPU. Un subnet de stockage ou de prédiction peut ne pas en avoir besoin. L’inscription, le logiciel du mineur et l’évaluation par les validateurs déterminent si la machine est rémunérée.

Le matériel utilisé sur Akash correspond à ce que le fournisseur répertorie et à ce que demande le fichier de déploiement du locataire. Réussir le travail signifie remporter l’offre et maintenir la location, et non atteindre une cible de difficulté. Un fournisseur peut être rémunéré pour une location sans avoir la moindre possibilité de produire un bloc Akash.

Le matériel utilisé sur Render est un nœud GPU qui prend en charge les travaux qui lui sont acheminés. La réputation de l’opérateur et la catégorie du travail jouent un rôle. Une carte qui ne remporte jamais de tuile Pearl peut tout de même régler un travail Render, car ce travail n’est pas un ticket Pearl.

Les récompenses en tokens sont-elles la même chose que les frais de calcul ?

Non. Pearl émet des PRL au moyen de la subvention de bloc. L’offre est plafonnée à 2,1 milliards et s’en approche selon une courbe régulière, sans étape de halving, avec un intervalle cible d’environ 194 secondes. Les PRL reçus par un mineur représentent un droit sur cette émission, et non sur la facture GPU d’un client. Minage de Pearl suit cette courbe parallèlement à l’ajustement de la difficulté.

Bittensor verse des TAO à partir de l’émission orientée par les scores agrégés de Yuma. Un mineur doit obtenir un poids sur un subnet. Un staker délègue à des validateurs. Aucun de ces flux ne constitue le paiement d’un client pour une heure de calcul GPU. Le token sert d’unité de mesure pour les scores.

Akash sépare la production des blocs du paiement de la location. L’AKT mis en staking soutient les validateurs et, par conséquent, la production des blocs. Un locataire finance la location avec de l’ACT, un crédit de calcul indexé sur le dollar américain, et le séquestre paie le fournisseur en ACT. La destruction d’AKT permet de créer ce crédit. Un fournisseur peut être payé pour une location sans produire de blocs, et un validateur peut produire des blocs sans proposer de GPU.

RENDER est l’actif utilisé pour payer un travail. La destruction de RENDER crée des crédits de travail et retire ces RENDER de l’offre. Les opérateurs de nœuds sont rémunérés selon un calendrier d’émissions distinct, et ne reçoivent pas les tokens brûlés. Un compte Solana qui détient des RENDER n’est pas un UTXO Pearl, et un transfert Solana ne règle pas une coinbase Pearl. L’offre peut diminuer lorsque des travaux brûlent des RENDER et augmenter lorsque des émissions sont distribuées, plutôt que lorsqu’une tuile matricielle atteint une cible de difficulté Pearl.

Un reçu indiquant « GPU » peut correspondre à une subvention de bloc, à une émission pondérée par les scores, à un paiement de location ou à un paiement issu des émissions après la destruction de tokens pour un travail. Seul le premier cas correspond à Pearl.

Que devez-vous vérifier avant de considérer ces réseaux comme une même architecture ?

Une tuile Pearl gagnante certifie que la multiplication a atteint la difficulté requise. Elle ne certifie pas qu’un client a reçu le résultat d’un modèle. Un poids Bittensor certifie un score attribué par un validateur. Une location Akash certifie une offre acceptée. Un règlement Render certifie un travail terminé.

L’actif Pearl natif ne possède aucune adresse de contrat sur une autre chaîne, et les adresses de réception du réseau principal commencent par prl1p. Le marché PEARL de Gate concerne cet actif. Le marché PRL de Gate concerne Perle, un projet distinct. Une adresse de contrat, une adresse 0x ou une adresse Solana correspond à un actif différent, même lorsque le nom est identique.

Résumé

La différence entre Pearl, Bittensor, Akash et Render réside dans ce que le GPU prouve. Pearl verse des PRL lorsqu’une tuile issue d’une multiplication matricielle remporte la loterie de blocs sur sa propre chaîne, et la vérification certifie cette tuile, et non une facture client. Bittensor verse des TAO lorsque les validateurs évaluent les résultats d’un subnet. Akash paie une location acceptée en ACT tandis que des validateurs en staking produisent les blocs, et Render brûle des RENDER pour payer un travail tandis que les récompenses des opérateurs proviennent des émissions et que Solana produit les blocs.

FAQ

En quoi Pearl diffère-t-il de Bittensor, d’Akash et de Render ?

Pearl fait de la multiplication matricielle effectuée par un GPU le travail qui peut remporter un bloc et verse au gagnant une rémunération en PRL. Bittensor verse des TAO pour les résultats d’un subnet après l’attribution de scores par les validateurs. Akash enregistre une location de conteneur sur une chaîne fondée sur la preuve d’enjeu et paie cette location à partir d’un séquestre en ACT. Render facture les travaux GPU en brûlant des RENDER pour créer des crédits de travail sur Solana, puis paie les opérateurs de nœuds selon un calendrier d’émissions distinct.

Une preuve Pearl valide signifie-t-elle que le GPU a exécuté un modèle d’IA payant ?

Non. Une preuve Pearl valide montre que la tuile ouverte a été recalculée et que le ticket atteint la difficulté requise. Le mineur choisit les matrices, et des matrices aléatoires peuvent réussir la vérification. Une charge de travail d’inférence payante peut être à l’origine de ces matrices, mais la vérification n’exige pas cette origine.

Akash et Render utilisent-ils une preuve de travail utile ?

Non. Akash enregistre les locations sur une chaîne CometBFT fondée sur la preuve d’enjeu. Render règle les travaux avec des RENDER sur Solana, dont les validateurs produisent les blocs par staking. Les deux réseaux peuvent vendre du temps de calcul GPU utile, mais cette vente ne constitue pas l’énigme de bloc.

N’importe quel GPU peut-il miner Pearl de la même manière qu’il peut prendre en charge un travail Akash ou Render ?

Non. Un fournisseur Akash répertorie les ressources demandées par un locataire et remporte une offre, tandis qu’un opérateur de nœud Render prend en charge un travail qui lui est acheminé. Le parcours documenté de Pearl repose sur un nœud et un mineur qui effectue la multiplication du protocole, avec un paiement uniquement lorsqu’un bloc est trouvé. Une carte capable de prendre en charge un travail de marketplace n’est pas automatiquement un mineur Pearl.

Le marché PRL de Gate concerne-t-il le même actif que Pearl ?

Non. Gate répertorie l’actif Pearl natif sous le symbole PEARL. Le marché PRL de Gate concerne Perle, un projet distinct. L’actif Pearl natif est reçu à une adresse prl1p sur le réseau Pearl et ne possède aucune adresse de contrat sur une autre chaîne.