Livre blanc

1. Résumé

Parmeton Network est une blockchain indépendante de couche 1. Son testnet utilise un graphe de blocs, ou DAG, et le Proof of Matrix (PoM). Les mineurs produisent des preuves sur GPU et les nœuds les rejouent sur CPU. PMN est l’actif natif du réseau.

Le projet développe un service d’inférence distribué. L’utilisateur choisira dans Ollama un modèle local ou un modèle du réseau Parmeton. Pour une requête réseau, un mineur exécutera le modèle et diffusera la réponse hors chaîne. Le portefeuille autorisera le financement en PMN. La Proof of Inference (PoI) vise à vérifier le calcul fourni. Le protocole de service et son règlement restent en développement.

La blockchain conserve les transactions, l’état et les engagements nécessaires à la validation. Les prompts et les réponses circulent hors chaîne. Les diagnostics de l’infrastructure restent dans les outils d’administration.

2. Consensus et minage

Le testnet 0.2.51 utilise le genesis parmeton-testnet-v4. Un bloc peut référencer jusqu’à 16 parents. GHOSTDAG, avec K = 124, ordonne les blocs parallèles et le nœud applique les transactions à l’état UTXO. Une transaction consomme des sorties existantes et crée de nouvelles sorties contrôlées par des clés Ed25519.

La difficulté vise un intervalle de 100 ms, soit 10 blocs/s en moyenne. La progression du DAG et celle du score DAA sont mesurées séparément. Le point de finalité suit le chemin du parent sélectionné avec une profondeur de 432 000 DAA, soit environ 12 heures si le score avance à 10 DAA/s. Le délai réel dépend du réseau.

Le PoM actif utilise le profil Phi-4-mini-instruct Q8_0. Le GPU calcule des candidats liés au travail demandé et au modèle de référence. Les nœuds vérifient les preuves sur CPU et appliquent les règles du DAG et du registre. Un nœud de validation peut fonctionner sans GPU. Le DAG et l’architecture de la 0.2.51 détaillent ces règles.

3. PMN, émission et tarification

Politique monétaire du testnet V4

• 21 millions de PMN dans le calendrier initial, avec une émission de queue comptabilisée séparément. Un PMN vaut un milliard d’atomes.
• 90 % au mineur, 10 % à la trésorerie pour la récompense effectivement créée. Les sorties deviennent dépensables à partir du DAA canonique de création plus 10 000.
• Les transferts paient des frais réseau. Le tarif de base évolue par fenêtres de 661 DAA. Les transactions d’autorisation des mineurs sont exemptées.
• La première dépense d’une sortie de récompense mineur est taxée sur la valeur entière de cette sortie, y compris lors d’une consolidation. Le taux de référence part de 15 % à la création et décroît jusqu’à zéro à 77 760 000 DAA. La maturité s’applique avant la dépense. Les sorties de récompense de la trésorerie sont exonérées.
• Le registre brûle les frais et la taxe quand le transfert est appliqué. Le burn ne recrédite pas le calendrier d’émission.

La page Émission donne les paramètres de calcul et le relevé de l’offre. Les règles de production feront l’objet d’une décision distincte du profil de testnet.

Tarification de l’inférence envisagée

Dans le modèle envisagé, les utilisateurs règlent les services en PMN existants et les workers reçoivent des PMN. AIC désigne une unité de mesure et d’affichage équivalente à 4 joules. Le PMN reste le seul actif de règlement.

Une tarification de référence peut convertir l’énergie forfaitaire des jetons d’entrée et de sortie en coût, puis exprimer ce coût en PMN. La relation entre un jeton IA et le forfait énergétique, les sources de prix, la validité du devis et l’arrondi aux atomes restent à spécifier. Le devis devra être présenté avant autorisation et le règlement devra respecter le plafond accepté.

énergie de référence (kWh) = jetons facturables × joules par jeton / 3 600 000
coût de référence (EUR) = énergie de référence × prix de l’électricité (EUR/kWh)
montant de référence (PMN) = coût de référence / cours du PMN (EUR par PMN)

4. Ollama, inférence et paiement

Le client est le fork Ollama installé chez l’utilisateur. Le mode local exécute les modèles sur son poste. Le mode Parmeton envoie une requête au réseau et reçoit les jetons générés au fil de l’inférence. La clé de dépense et la phrase de récupération restent dans le portefeuille. Ollama utilise une clé Service avec une délégation bornée.

Le mineur fournit la capacité de calcul. L’intégration prévue lui permet de suspendre le PoM sur l’accélérateur pendant une inférence, puis de reprendre le minage. La réutilisation du même tampon de poids par le PoM et le moteur d’inférence reste à qualifier. Le choix du worker dépend notamment du modèle exact, de la disponibilité et de la latence.

Le mineur doit vérifier l’autorité du payeur, le destinataire, la finalité exigée, le verrou DAA et le budget restant. La lecture poi.fundingInfo reste à raccorder au nœud actif. La reprise d’une demande de financement doit réutiliser le même identifiant et, si elle a déjà été signée, la même transaction.

Ce que les preuves doivent établir

• Financement : la chaîne établit l’effet canonique du transfert et son statut de finalité.
• Livraison : le client atteste ce qu’il a reçu selon les règles de la session.
• Exécution : les engagements lient le calcul au modèle et aux paramètres retenus. Un audit échantillonné couvre les opérations examinées et ses garanties dépendent du protocole d’audit.

Le client peut recevoir les jetons sans attendre un bloc à chaque étape. Le devis et les limites de génération doivent borner les dépenses avant le démarrage. La continuité de service et le basculement vers un autre worker ou modèle restent à qualifier.

Dans le protocole expérimental, le mineur et le relais peuvent lire le contenu qui leur est transmis. Les prompts et les réponses restent hors du registre public. Une garantie de confidentialité vis-à-vis de ces opérateurs demanderait des mécanismes et une qualification supplémentaires.

5. Nœuds, stockage et reprise

Le nœud valide les blocs et maintient le DAG et les UTXO. Le stockage paginé publie les changements par lots. Le journal et les checkpoints servent à réutiliser l’état local et à reprendre le traitement après un arrêt. Le checkpoint de stockage et le point finalisé du DAG ont des rôles distincts.

La 0.2.51 conserve l’historique. Les nœuds élagués et la synchronisation à partir d’un snapshot distribué restent des cibles à qualifier. Un snapshot de démarrage réseau doit être ancré à une référence vérifiable et contenir les données de consensus nécessaires à la validation de la suite. La configuration matérielle minimale dépendra de mesures sur des historiques et des charges représentatifs.

6. Matériel et modèles

Les résultats PoM sont soumis à la même validation CPU. Les annonces de capacités sont signées par les mineurs. La signature authentifie la déclaration, dont le GPU et la mémoire restent autodéclarés.

Le profil PoM actif et le futur catalogue d’inférence ont des usages distincts. Un modèle est identifié par son manifeste, ses poids et son profil de calcul. Les poids restent hors chaîne. La sélection des modèles d’inférence dépendra aussi de leur licence, du tokenizer, du contexte et de la mémoire réellement exploitable.

Les configurations multi-GPU et multi-modèles, ROCm/HIP, Ryzen AI Max, DGX Spark et d’autres accélérateurs restent des chantiers à qualifier. La distribution des modèles entre pairs et les pools restent également à étudier.

7. Transparence et limites

Le site public affiche un relevé HTTPS du seed publié toutes les 30 secondes. Il présente l’état observé par ce nœud, notamment le DAG, le DAA, les pairs et l’émission. Le débit en blocs/s mesure la progression nette du compteur entre deux relevés. Les tentatives PoM/s et les jetons d’inférence/s sont des mesures distinctes.

Le JSON-RPC du nœud est réservé à l’accès privé. VPSmon sert à l’exploitation et distingue le rejeu PoM du travail d’admission. Un explorateur historique complet et des métriques couvrant l’ensemble du réseau demandent une couche d’indexation dédiée.

Les priorités de sécurité incluent les réorganisations du DAG, la reprise de l’état, le rejeu des autorisations, les doubles engagements de budget et les fausses preuves. Les garanties de finalité du registre et celles du service d’inférence doivent être qualifiées séparément.

8. État du projet et prochaines étapes

Livre blanc · Révision du 4 novembre 2026 · Référence technique du testnet 0.2.51.