Hoskinson pourrait se tromper sur l’avenir du calcul décentralisé

Hoskinson pourrait se tromper sur lavenir du calcul decentralise

Le trilemme de la blockchain a de nouveau fait son apparition au Consensus de Hong Kong en février, dans une certaine mesure, mettant Charles Hoskinson, le fondateur de Cardano, en retrait – devant rassurer les participants sur le fait que les hyperscalers comme Google Cloud et Microsoft Azure sont pas un risque pour la décentralisation.

Il a été souligné que les grands projets de blockchain besoin hyperscalers, et que l’on ne devrait pas se soucier d’un seul point de défaillance car :

  • La cryptographie avancée neutralise le risque
  • Le calcul multipartite distribue le matériel clé
  • L’informatique confidentielle protège les données utilisées

L’argument reposait sur l’idée que « si le cloud ne peut pas voir les données, il ne peut pas contrôler le système », et il a été laissé là en raison de contraintes de temps.

Mais il existe une alternative à l’argument de Hoskinson en faveur des hyperscalers qui mérite plus d’attention.

MPC et l’informatique confidentielle réduisent l’exposition

Il s’agissait en quelque sorte d’un bastion stratégique dans l’argumentation de Charles : selon lequel des technologies telles que le calcul multipartite (MPC) et l’informatique confidentielle garantissent que les fournisseurs de matériel n’auraient pas accès aux données sous-jacentes.

Ce sont des outils puissants. Mais ils ne pas dissoudre le risque sous-jacent.

MPC distribue les éléments clés à plusieurs parties afin qu’aucun participant ne puisse reconstituer un secret. Cela réduit considérablement le risque d’un seul nœud compromis. Toutefois, la surface de sécurité s’étend dans d’autres directions. La couche de coordination, les canaux de communication et la gouvernance des nœuds participants deviennent tous essentiels.

Au lieu de faire confiance à un seul détenteur de clé, le système dépend désormais d’un ensemble distribué d’acteurs se comportant correctement et de la bonne mise en œuvre du protocole. Le point unique de défaillance ne disparaît pas. En fait, cela devient simplement une surface de confiance distribuée.

L’informatique confidentielle, en particulier les environnements d’exécution fiables, introduit un compromis différent. Les données sont cryptées lors de l’exécution, ce qui limite l’exposition à l’hébergeur.

Mais les environnements d’exécution de confiance (TEE) reposent sur des hypothèses matérielles. Ils dépendent de l’isolation microarchitecturale, de l’intégrité du micrologiciel et d’une mise en œuvre correcte. La littérature académique, par exemple, ici et ici, a démontré à plusieurs reprises que des vulnérabilités de canal secondaire et architecturales continuent d’émerger dans les technologies enclavées. La frontière de sécurité est plus étroite que celle du cloud traditionnel, mais elle n’est pas absolue.

Plus important encore, les MPC et les TEE fonctionnent souvent sur une infrastructure hyperscaler. Le matériel physique, la couche de virtualisation et la chaîne d’approvisionnement restent concentrés. Si un fournisseur d’infrastructure contrôle l’accès aux machines, à la bande passante ou aux régions géographiques, il conserve un levier opérationnel. La cryptographie peut empêcher l’inspection des données, mais elle n’empêche pas les restrictions de débit, les arrêts ou les interventions politiques.

Les outils cryptographiques avancés rendent les attaques spécifiques plus difficiles, mais ils ne suppriment toujours pas le risque de défaillance au niveau de l’infrastructure. Ils remplacent simplement une concentration visible par une autre plus complexe.

L’argument selon lequel « aucun L1 ne peut gérer le calcul global »

Hoskinson a souligné que les hyperscalers sont nécessaires car aucune couche 1 ne peut à elle seule gérer les demandes informatiques des systèmes mondiaux, faisant référence aux milliards de dollars qui ont aidé à construire de tels centres de données.

Bien entendu, les réseaux de couche 1 n’ont pas été conçus pour exécuter des boucles de formation à l’IA, des moteurs de trading à haute fréquence ou des pipelines d’analyse d’entreprise. Ils existent pour maintenir le consensus, vérifier les transitions d’état et fournir une disponibilité durable des données.

Il a raison sur la raison pour laquelle la couche 1 est utilisée. Mais les systèmes globaux ont avant tout besoin de résultats que chacun peut vérifier, même si le calcul a lieu ailleurs.

Dans l’infrastructure cryptographique moderne, les calculs lourds se produisent de plus en plus hors chaîne. Ce qui compte, c’est que les résultats puissent être prouvés et vérifiés en chaîne. C’est la base des rollups, des systèmes sans connaissance et des réseaux informatiques vérifiables.

Se concentrer sur la question de savoir si un L1 peut exécuter un calcul global passe à côté de la question centrale de savoir qui contrôle l’infrastructure d’exécution et de stockage derrière la vérification.

Si le calcul s’effectue hors chaîne mais repose sur une infrastructure centralisée, le système hérite de modes de défaillance centralisés. La colonisation reste décentralisée en théorie, mais la voie à suivre pour produire des transitions étatiques valides est concentrée dans la pratique.

Le problème devrait porter sur la dépendance au niveau de la couche infrastructure, et non sur la capacité de calcul à l’intérieur de la couche 1.

La neutralité cryptographique n’est pas la même chose que la neutralité participative

La neutralité cryptographique est une idée puissante et quelque chose que Hoskinson a utilisé dans son argumentation. Cela signifie que les règles ne peuvent pas être arbitrairement modifiées, que des portes dérobées cachées ne peuvent pas être introduites et que le protocole reste équitable.

Mais la cryptographie continue matériel.

Cette couche physique détermine qui peut participer, qui peut se le permettre et qui finit par être exclu, car le débit et la latence sont finalement limités par les machines réelles et l’infrastructure sur laquelle elles fonctionnent. Si la production, la distribution et l’hébergement du matériel restent centralisés, la participation devient économiquement limitée même lorsque le protocole lui-même est mathématiquement neutre.

Dans les systèmes de calcul intensif, le matériel change la donne. Il détermine la structure des coûts, qui peut évoluer et la résilience face à la pression de la censure. Un protocole neutre fonctionnant sur une infrastructure concentrée est neutre en théorie mais contraint en pratique.

La priorité devrait se déplacer vers la cryptographie combinée à diversifié propriété du matériel.

Sans diversité des infrastructures, la neutralité devient fragile sous la pression. Si un petit groupe de fournisseurs peut limiter les charges de travail, restreindre les régions ou imposer des barrières de conformité, le système hérite de son influence. L’équité des règles ne garantit pas à elle seule l’équité de la participation.

La spécialisation bat la généralisation sur les marchés informatiques

La concurrence avec AWS est souvent présentée comme une question d’échelle, mais cela aussi est trompeur.

Les hyperscalers optimisent la flexibilité. Leur infrastructure est conçue pour servir des milliers de charges de travail simultanément. Couches de virtualisation, systèmes d’orchestration, outils de conformité d’entreprise et garanties d’élasticité : ces fonctionnalités sont des atouts pour le calcul à usage général, mais elles constituent également des couches de coûts.

Les calculs prouvant la connaissance nulle et vérifiables sont déterministes, denses en calcul, limités en bande passante mémoire et sensibles au pipeline. En d’autres termes, ils récompensent la spécialisation.

Un réseau de preuve spécialement conçu rivalise en matière de preuve par dollar, de preuve par watt et de preuve par latence. Lorsque le matériel, les logiciels de démonstration, la conception des circuits et la logique d’agrégation sont intégrés verticalement, l’efficacité se conjugue. La suppression des couches d’abstraction inutiles réduit les frais généraux. Le débit soutenu sur les clusters persistants surpasse la mise à l’échelle élastique pour les charges de travail étroites et constantes.

Sur les marchés informatiques, la spécialisation surpasse systématiquement la généralisation pour les tâches régulières et à volume élevé. AWS optimise pour optionnalité. Un réseau d’essai dédié optimise pour une classe de travail.

La structure économique diffère également. Prix ​​​​des hyperscalers pour les marges des entreprises et la grande variabilité de la demande. Un réseau aligné sur des incitations protocolaires peut amortir le matériel différemment et ajuster les performances autour d’une utilisation soutenue plutôt que de modèles de location à court terme.

La concurrence porte sur l’efficacité structurelle pour une charge de travail définie.

Utilisez des hyperscalers, mais n’en dépendez pas

Les hyperscalers ne sont pas des ennemis. Ce sont des fournisseurs d’infrastructures efficaces, fiables et distribués à l’échelle mondiale. Le problème, c’est la dépendance.

Une architecture résiliente fait appel à des fournisseurs majeurs pour la capacité de rafale, la redondance géographique et la distribution périphérique, mais elle n’ancre pas les fonctions de base chez un seul fournisseur ou un petit groupe de fournisseurs.

Le règlement, la vérification finale et la disponibilité des artefacts critiques doivent rester intacts même en cas de défaillance d’une région cloud, d’un fournisseur qui quitte un marché ou de contraintes politiques plus strictes.

C’est là que les infrastructures de stockage et de calcul décentralisées deviennent une alternative viable. Les artefacts de preuve, les enregistrements historiques et les entrées de vérification ne doivent pas être retirés à la discrétion du fournisseur. Au lieu de cela, ils devraient vivre sur des infrastructures économiquement alignées sur le protocole et structurellement difficiles à désactiver.

Les hypescalers doivent être utilisés comme un facultatif un accélérateur plutôt que quelque chose de fondamental pour le produit. Le cloud peut toujours être utile pour la portée et les rafales, mais la capacité du système à produire des preuves et à conserver ce dont dépend la vérification n’est pas contrôlée par un seul fournisseur.

Dans un tel système, si un hyperscaler disparaît demain, le réseau ne fera que ralentir, car les éléments les plus importants sont détenus et exploités par un réseau plus large plutôt que loués à un point d’étranglement de grande marque.

C’est ainsi que l’on renforce la philosophie de décentralisation de la cryptographie.

Laisser un commentaire