DC Expertise · mandat de 3 mois et plus
Decentralized Compute Engineering
Distribuez un calcul seulement quand la propriété à obtenir justifie sa complexité.
Architecture d’exécution distribuée et vérifiable : le workload, l’environnement, le nœud, le résultat, l’attestation et les métriques restent inspectables, sans confondre décentralisation, performance et vérification.
Toutes les preuves de cette page indiquent leur niveau de provenance, limites comprises. Voir les preuves
Le moment où ça devient un sujet
Vous reconnaissez l’un de ces moments, ou ce n’est pas encore le sujet.
Ce sont des situations datables, pas des symptômes généraux. Si aucune ne vous parle, cette page peut se refermer ici.
-
Un workload doit tourner chez plusieurs opérateurs pour une raison de souveraineté, de résilience ou de dépendance fournisseur déjà identifiée.
-
Un client ou un protocole doit vérifier qui a exécuté un calcul, dans quel environnement et sur quelle version.
-
Des GPU ou des CPU distribués sont disponibles, mais le scheduler, la confiance, la mesure et le repli ne sont contractés nulle part.
-
Une architecture TEE, ZK, réplication ou multi-fournisseur est envisagée avant que la propriété à vérifier ait été nommée.
-
Les benchmarks disponibles comparent des systèmes sous des workloads ou des environnements qui ne sont pas équivalents.
-
Un protocole publie des affirmations de coût, de performance ou de vérifiabilité que rien ne relie à un contrat de métrique.
Aucune de ces situations n’est urgente en soi. Chacune le devient à une date connue d’avance.
Ce que ça coûte si rien ne change
Quatre blocages, et le contournement qui ne les réduit pas.
Chaque blocage reçoit une réponse plus bas — dans les offres, le déroulé ou les engagements. Aucun n’est laissé ouvert.
Le benchmark ne permet pas de décider
Deux architectures comparées sans population commune, sans versions, sans environnement et sans métrique partagée produisent deux chiffres, pas une décision. Le choix se prend alors sur la source la plus assurée plutôt que sur la mesure la plus comparable.
Le contournement habituel, et sa limite
Le contournement habituel consiste à rassembler des chiffres publiés séparément. Ils restent séparés : un débit mesuré sur un autre workload, une autre version et une autre fenêtre ne devient pas comparable en entrant dans le même tableau.
Un nœud identifié n’est pas un résultat correct
Une attestation prouve les propriétés qu’elle atteste : l’identité du nœud, l’image exécutée, parfois l’isolation mémoire. Elle ne dit rien de la justesse applicative du résultat, et c’est pourtant sur ce glissement que reposent la plupart des promesses de calcul vérifiable.
Le contournement habituel, et sa limite
Ajouter une couche de preuve au-dessus d’un calcul que personne ne conteste déplace le coût sans lever de doute. La justesse applicative demande ses propres tests, ou sa propre preuve.
La distribution ajoute des domaines de panne que le cluster n’avait pas
Réseau, scheduling, réplication, sortie de fournisseur et gouvernance deviennent des composants à exploiter. Un cluster centralisé peut n’avoir aucune raison de les porter, et les porter sans les avoir décidés est ce qui rend un système distribué plus fragile que celui qu’il remplace.12
Le contournement habituel, et sa limite
Le repli vers une route centralisée est souvent supposé disponible et rarement rejoué. Tant qu’il ne l’a pas été, c’est une intention, pas une procédure.
Le marché de ressources est pris pour l’architecture
Un marketplace de GPU règle l’accès et la facturation. Il ne définit ni le workload, ni l’observabilité, ni la procédure de reprise, et il ne dit pas quelle propriété la décentralisation devait apporter.
Le contournement habituel, et sa limite
Choisir le réseau avant la propriété inverse la décision : le mécanisme est figé, et la question « qu’est-ce qu’un tiers doit pouvoir vérifier ? » se pose après le déploiement, quand la réponse coûte une migration.
Pour qui, et sous quelle pression
Le décideur qui achète ce mandat, et ce qui pèse sur lui.
CTO / responsable infrastructure de calcul
Thomas Vasseur
Aujourd’hui
Un workload doit être distribué, exécuté chez plusieurs opérateurs ou rendu vérifiable, mais les raisons, les métriques et les hypothèses de confiance restent mélangées.
Après le mandat
Le workload, son environnement, le nœud d’exécution, les résultats, les attestations, les métriques et le repli sont bornés dans une architecture testable et transférable.
Un avatar de décision sert à clarifier le problème et le résultat attendu. Il reste à valider avec vos entretiens et les comportements que vous observez. Les avatars, en entier
Avant de réserver quoi que ce soit
Cinq conditions d’entrée, cinq motifs de refus.
Elles sont écrites ici plutôt que découvertes au devis. La colonne de droite a le même poids que celle de gauche.
C’est le bon mandat si
- Une décision réelle est en jeu : une promotion en production, un audit, un renouvellement, un lancement ou un remplacement de système.
- Un sponsor nommé peut arbitrer le périmètre et signer la recette.
- L’accès aux systèmes, aux données ou aux documents nécessaires est possible sous NDA dans les trois premières semaines.
- Un workload représentatif est accessible, et la raison pour laquelle un opérateur unique ne suffit pas peut être écrite.
- Un vérificateur, ou la propriété de souveraineté ou de résilience visée, peut être nommé avant le prototype.
Ce n’est pas le bon mandat si
- Vous cherchez un panorama de tendances ou une veille : le format court de la clinique de décision coûte moins cher et répond mieux.
- Le résultat attendu dépend d’une signature réglementaire que seul un rôle statutaire de votre organisation peut porter.
- Aucun accès aux preuves n’est possible : sans données, sans journaux et sans documents, il n’y a rien à rendre défendable.
- Le mécanisme — TEE, ZK, réplication, registre — est déjà imposé sans propriété à vérifier : il n’y a plus d’architecture à décider, seulement à exécuter.
- Le cloud ou le cluster actuel satisfait déjà la confiance, la disponibilité, le coût et la gouvernance : la décentralisation n’aurait aucun résidu à traiter.
Un « non » dit à cette étape coûte vingt minutes. Dit après le devis, il coûte un trimestre à tout le monde.
L’état d’arrivée
Ce que le mandat déplace.
un calcul envoyé à un réseau, un résultat accepté
une exécution bornée, attribuable et rejouable
Le workload, l’environnement, le nœud, le vérificateur, les métriques et les états d’échec cessent d’être implicites : ils sont reliés à un reçu et à une procédure de rejeu. Ce que le reçu ne prouve pas est écrit au même endroit que ce qu’il prouve.
Axe par axe, avant et après
Six axes, et ce qui change sur chacun.
Un axe par ligne, comparé des deux côtés. Une colonne de frustrations face à une colonne de fonctionnalités ne serait pas une comparaison.
Workload
Aujourd’hui
Décrit par l’application qui le lance
Après
Enveloppe lisible par une machine et workload de référence versionné
Confiance
Aujourd’hui
Fournisseur supposé fiable
Après
Propriété, vérificateur et frontière de confiance nommés
Exécution du calcul
Aujourd’hui
Journaux locaux au fournisseur
Après
Reçu d’exécution versionné et inspectable
Benchmark
Aujourd’hui
Chiffres issus de sources différentes
Après
Contrat de métrique et campagnes appariées
Panne
Aujourd’hui
Retry et repli supposés disponibles
Après
Domaines de panne et repli rejoués dans une fenêtre annoncée
Portabilité
Aujourd’hui
Dépendance constatée après l’incident
Après
Exigences et adaptateurs documentés avant le choix
Ce qui est visé, et de quel type
Trois critères de recette, un exemple déjà construit, aucun résultat observé.
Chaque ligne indique son statut : critère de recette, estimation modélisée, ou exemple déjà construit.
-
Visé — critère de recette
Un workload de référence et son comparateur conventionnel sont versionnés avant toute mesure.
Critère de recette : les deux côtés portent les mêmes versions, la même fenêtre et le même contrat de métrique.
-
Visé — critère de recette
Chaque métrique publiée porte sa variable, son unité, sa population, sa période, sa source et sa limite.
Critère de recette : une valeur à laquelle il manque l’un de ces six champs n’est pas publiée.
-
Visé — critère de recette
Le repli et la réplication sont rejoués avant la mise en production, pas décrits.
Critère de recette : un test d’échec documente le comportement observé du retry, de la réplication et de la route de secours.
-
Exemple — déjà construit
Folder Mapper : outil Rust original avec persistance SQLite, dépôt public.
Exemple déjà construit : preuve d’outillage systèmes et de persistance locale. Ce n’est pas une plateforme de calcul distribué en production.
Aucun de ces résultats n’est présenté comme mesuré chez un client : les métriques de production sont sous NDA sur chaque mandat. Reste la question qui suit — sur quoi ces engagements reposent-ils ?
Ce sur quoi ça repose, et ce que ça ne prouve pas
Des preuves proportionnées à la promesse.
Trois preuves publiques distinctes — outillage systèmes en Rust, contribution d’implémentation on-chain, mécanismes de vérification — et deux preuves qui manquent, nommées ici plutôt que passées sous silence.
Projet public
Folder Mapper — inventaire de système de fichiers en Rust
Outil d’inventaire de système de fichiers écrit en Rust, avec persistance SQLite, sous dépôt public. • Capability demonstrated : Systèmes — outillage Rust et persistance locale, pas une plateforme de calcul distribué.
Examiner la preuveProjet public
Lottery dApp — contribution attribuée commit par commit
26 commits publics sur 29 attribués sur le dépôt du projet. • Capability demonstrated : Implémentation — logique Solidity/EVM et tests de contrat, pas sécurité de production.
Examiner la preuveCrédential
Encode Club — ZK · ZKML · Solana
Bootcamps sur les preuves à divulgation nulle, ZKML (EZKL, GKR) et le développement Solana. • Capability demonstrated : Vérification — connaissance des mécanismes de preuve. Le profil public classe ZK/ZKML « à confirmer » : ce n’est pas une expertise certifiée.
Manquant
Benchmark public d’un workload distribué livré sous cette offre
Aucun benchmark apparié n’est publié à ce jour pour un workload livré sous cette offre. Tant qu’il n’existe pas, cette page ne porte aucune affirmation de débit, de latence ou de coût.34
Manquant
Résultat client avant/après et SLO de production
Les déploiements clients sont décrits au niveau architecture sous NDA. Aucun SLO de production ni résultat avant/après n’est publiable tant que le mandat n’est pas clos.
Sources & méthodes 4 placements · 4 unités de preuve
Chaque marqueur numéroté renvoie à une observation bornée : ce qui a été mesuré, sur quelle population, sur quelle période, et ce que le chiffre n’établit pas. Une affirmation qui ne peut pas être adossée à une de ces unités perd son marqueur — elle n’est pas rattachée à une source plus vague.
-
La réplication de machine à états tolérante aux fautes byzantines (PBFT) tolère des fautes byzantines sous des hypothèses explicites de réplicas et de réseau, avec des optimisations évaluées expérimentalement.
Implémentation NFS tolérante aux fautes byzantines, mesurée environ 3 % plus lente que le NFS standard non répliqué sur le benchmark Andrew, dans l’environnement rapporté ; tolère f fautes byzantines avec 3f+1 réplicas sous les hypothèses énoncées. 1999
Ce que ce chiffre n’établit pas Sûreté, vivacité et performance dépendent des hypothèses PBFT ; ce n’est pas une recommandation universelle pour le calcul décentralisé.
-
Sur le benchmark Andrew rapporté, le service NFS tolérant aux fautes byzantines a mis environ 3 % de temps de plus que le NFS standard non répliqué.
Quel surcoût en régime normal l’implémentation NFS tolérante aux fautes byzantines a-t-elle montré face au NFS standard ? Sur le benchmark Andrew rapporté, le service NFS tolérant aux fautes byzantines a pris environ 3 % de temps de plus que le NFS standard non répliqué.
Les intitulés de catégorie sont ceux de la table source, non traduits : les traduire changerait ce que la source rapporte.
Réponse à une question de graphe sur l’overhead du service NFS BFT par rapport au NFS standard, benchmark Andrew 1999. 1999
Ce que ce chiffre n’établit pas Benchmark NFS ancien, spécifique au workload et à l’implémentation ; ne prédit pas l’overhead du calcul décentralisé moderne.
-
Pinocchio met en œuvre un calcul externalisé publiquement vérifiable et mesure les coûts du prouveur et du vérificateur sur sept applications, démontrant des preuves très petites et un temps de vérification faible pour le système évalué.
Sept applications évaluées ; preuve de 288 octets ; ~10 ms de vérification ; réduction d’effort de prouveur de 19 à 60× par rapport au travail antérieur. 2013
Ce que ce chiffre n’établit pas Spécifique au protocole, à l’implémentation et à la charge de travail. Aucune revendication universelle de vérification bon marché ou rapide.
Pinocchio: Nearly Practical Verifiable Computation · Microsoft Research, 2013
-
Pour le système Pinocchio évalué, les preuves mesurent 288 octets et la vérification dure environ 10 ms ; l’effort du prouveur est réduit de 19 à 60× par rapport au travail antérieur.
Quel coût de vérification Pinocchio rapporte-t-il pour les applications évaluées ? - Proof size
- 288 bytes
- Verification time
- 10 ms
- Prover-effort reduction versus prior work
- 19–60 x
Pour le système Pinocchio évalué, les preuves font 288 octets et la vérification prend typiquement environ 10 ms ; l’effort du prouveur est rapporté 19 à 60× inférieur au travail antérieur.
Les intitulés de catégorie sont ceux de la table source, non traduits : les traduire changerait ce que la source rapporte.
Réponse à une question de graphe sur l’overhead de vérification de Pinocchio, sept applications évaluées. 2013
Ce que ce chiffre n’établit pas Mesures spécifiques au protocole, à l’implémentation et au workload. Aucune revendication universelle de coût ou de vitesse.
Pinocchio: Nearly Practical Verifiable Computation · Microsoft Research, 2013
Chaque élément indique sa nature et son niveau de provenance. Les limites sont affichées au même titre que les réalisations. Le registre complet des projets et de leur provenance
Évaluer la missionCe qui est dedans, ce qui n’y est pas
Le périmètre, ses exclusions et ses dépendances.
Dans le périmètre
- Caractérisation du workload, topologie de ressources et modèle de confiance fournisseur/nœud.
- Choix du mécanisme de vérification — attestation, TEE, ZK, réplication — uniquement lorsqu’une propriété nommée le justifie.
- Adaptateurs scheduler et fournisseurs, reçus d’exécution, observabilité et magasin de preuves.
- Banc de benchmark apparié, tests d’échec, conception du repli et gates de mise en production.
- PoC, implémentation, assurance technique et passation à l’équipe qui exploitera.
Hors périmètre, explicitement
- Garantie de coût ou de performance avant mesure sur votre workload.
- Classement de fournisseurs qui n’a pas été mesuré sur ce workload-là.
- Exploitation 24/7 par défaut : c’est une décision séparée, avec son propre contrat.
- Choix imposé d’un registre, d’un TEE ou d’un ZK sans propriété à vérifier, et certification formelle.
Ce qui dépend de vous
- Un sponsor joignable qui tranche un arbitrage de périmètre en moins d’une semaine.
- L’accès aux systèmes, journaux ou documents concernés, sous NDA.
- Une ou deux personnes de votre équipe disponibles pour la phase de passation — sans elles, le mandat produit une dépendance au lieu d’une capacité.
- Un workload représentatif et son comparateur conventionnel, accessibles dans les trois premières semaines.
Format 3–12 mois · diagnostic, architecture, PoC vérifiable et delivery
Le déroulé, et où l’on peut s’arrêter
Six phases, six sorties possibles.
Chaque phase se termine par un artefact et une décision. Vous pouvez vous arrêter à la fin de n’importe laquelle avec quelque chose entre les mains.
-
Caractérisation
Le workload, la localisation des données, les métriques et la tolérance aux pannes, décrits avant toute discussion de mécanisme.
Sortie de phase Enveloppe de workload et workload de référence.
-
Modèle de confiance
La propriété à vérifier, le vérificateur, les fournisseurs, les secrets et les hypothèses d’attaque.
Sortie de phase Carte de confiance et frontières écrites.
-
Conception
Topologie, sélection du mécanisme minimal, schéma du reçu et route de repli.
Sortie de phase Architecture cible et schéma de reçu.
-
Benchmark apparié
Comparateur, contrat de métrique, campagnes observées et valeurs dérivées, tenues séparées.
Sortie de phase Rapport de benchmark et jeu de données rejouable.
-
Vérification et durcissement
Contrôles d’attestation, tests d’échec, gates de mise en production et observabilité.
Sortie de phase Tests d’échec rejoués et gates de release.
-
Passation
Rejeu, rollback, sortie de fournisseur, propriété des artefacts et rétention des preuves.
Sortie de phase Runbook de rejeu et transfert d’exploitation.
Les blocs de travail
Dix blocs, activables séparément et dans n’importe quel ordre.
Contrat de workload
Le workload de référence, ses exigences machine et le comparateur conventionnel contre lequel il sera mesuré.
Topologie et domaines de panne
Fournisseurs, nœuds, accélérateurs, régions, et l’énoncé de ce qui tombe ensemble.
Identité de l’exécution
Ce qui doit être lié pour qu’un vérificateur retrouve qui a exécuté quoi, où, et sur quelle version.
Couche de vérification
Le mécanisme choisi après la propriété, jamais avant : signature, attestation, réplication ou preuve.
Sélecteur TEE / ZK / réplication
La comparaison écrite des mécanismes candidats, avec l’overhead que chacun ajoute et l’hypothèse de confiance qu’il retire.
Banc de comparaison
Contrat de métrique, campagnes appariées, séparation entre valeurs observées et dérivées, et rejeu.
Reprise et sortie de fournisseur
Retry, réplication, rollback, route de secours et procédure de sortie, chacun accompagné de son test.
Adaptateur de marché de ressources
Scheduling, sélection de fournisseur et tarification, activés seulement si le problème les contient.
Attestation de nœud
Identité du nœud et de l’environnement, avec l’énoncé explicite de ce que l’attestation ne couvre pas.
Mesure
Débit, latence, disponibilité dans la fenêtre de test, coût natif et surcoût de vérification.
Un bloc que vous tenez déjà sort du périmètre et du devis. C’est la première chose qu’on regarde à l’appel de qualification.
Ce qui est garanti, et ce qui ne peut pas l’être
Ce qui est garanti est le produit de travail, jamais le résultat d’une autorité.
Périmètre écrit avant facturation
Le périmètre, les exclusions, les dépendances et les critères de recette sont écrits et acceptés avant le premier jour facturé. Un changement de périmètre est un avenant, pas une surprise en fin de mission.
Livrables complets ou repris
Un livrable qui ne satisfait pas ses critères de recette est repris jusqu’à ce qu’il les satisfasse, sans facturation supplémentaire. Les critères sont écrits avant de produire, pas après.
Réversibilité à la sortie
Code, données, schémas, décisions et journaux vous appartiennent et partent avec vous. Aucun composant propriétaire, aucune licence, aucun hébergement dont dépendrait la suite du travail.
Frontière de confidentialité
Tout livrable ou exercice qui manipule vos données porte une classification et une règle explicite : autorisé, anonymisé, synthétique ou interdit. La règle est écrite avant la manipulation, pas constatée après.
Frontière de décision humaine
Chaque cas traité indique où l’assistance automatique s’arrête et où une validation humaine est obligatoire. Un système qui décide sans que la limite soit écrite n’est pas livré.
Noyau neutre vis-à-vis des outils
Objectifs, critères de recette et preuves sont écrits indépendamment d’un fournisseur ou d’un modèle donné. Un changement d’outil est un avenant, jamais une reprise à zéro de l’investissement.
Ce qui n’est pas garanti, et ne peut pas l’être honnêtement
- Aucune garantie de performance, de coût inférieur ou de disponibilité avant mesure sur votre workload : un chiffre annoncé avant le benchmark n’aurait ni population ni période.
- Une attestation ne prouve que les propriétés qu’elle atteste. La justesse applicative du résultat n’en découle pas et demande ses propres tests.
Les conditions contractuelles complètes — acompte, préavis, propriété intellectuelle, confidentialité — sont publiées et ne sont pas reformulées ici. Lire les conditions
Ce qui reste à lever
Six questions, avec la réponse et sa raison.
Les questions qui changent le périmètre, le prix ou la responsabilité sont déjà répondues plus haut. Ici, le reste.
Pourquoi ne pas rester sur un cloud public ou un cluster privé ?
Si l’opérateur unique satisfait la propriété, le workload et le modèle de panne, rester centralisé est parfaitement acceptable — et c’est la conclusion écrite du diagnostic dans ce cas.
TEE ou ZK ?
La décision dépend de la propriété, du modèle de menace, du workload, des secrets et de l’overhead acceptable. Aucun mécanisme n’est choisi par défaut, et les deux peuvent être écartés.
Une attestation de nœud prouve-t-elle que le résultat est correct ?
Non. Elle ne prouve que les propriétés effectivement attestées. La justesse applicative demande ses propres tests ou sa propre preuve, et le reçu dit lequel des deux a été produit.
Peut-on comparer plusieurs réseaux de calcul entre eux ?
Oui si le workload, les versions, la période et les métriques sont compatibles. Sinon les chiffres restent séparés, et ils sont présentés séparément.
Construisez-vous un marketplace de GPU ?
C’est possible comme module, si le scheduling, la tarification et la sélection de fournisseur font partie du problème. Ce n’est pas le cœur obligatoire de l’offre.
Garantissez-vous que ce sera moins cher que le cloud ?
Non. Le coût se mesure sur un workload, une période, des unités natives et un comparateur explicitement définis, et le résultat peut être défavorable à la distribution.
La prochaine étape, en entier
Évaluer la mission en 20 minutes
Le premier échange sert à décider s’il y a un mandat, pas à le vendre. S’il n’y en a pas, vous repartez avec la raison.
- 20 minutes, en visio ou au téléphone.
- Vous, le sponsor si ce n’est pas vous, et moi. Pas de commercial : il n’y en a pas.
- On y regarde le contexte, la décision en jeu, le niveau de risque et les preuves accessibles.
- Vous repartez avec un avis fit / no-fit motivé et, si c’est fit, le périmètre et la fourchette de la première étape.
Le bon format d’intervention, avant le premier rendez-vous.
Décrivez la décision à prendre — pas votre budget. Vous repartez avec le format d’intervention adapté et les ressources qui y mènent.
Cette expertise appliquée à votre cas : quatre écrans, une lecture gratuite, et l’offre qu’elle désigne.
Preuve