Vitalik : une nouvelle conception pour améliorer l'efficacité et la sécurité grâce à l’architecture de glue et de coprocesseur

Le glue doit être optimisé pour être un bon glue, tandis que le coprocessor doit être optimisé pour être un bon coprocessor.

Titre original : « Glue and coprocessor architectures »

Auteur : Vitalik Buterin, fondateur d'Ethereum

Traduction : Deng Tong, Jinse Finance

Remerciements particuliers à Justin Drake, Georgios Konstantopoulos, Andrej Karpathy, Michael Gao, Tarun Chitra et divers contributeurs de Flashbots pour leurs retours et commentaires.

Si vous analysez avec un niveau de détail moyen tout calcul intensif en ressources dans le monde moderne, vous remarquerez à maintes reprises une caractéristique : le calcul peut être divisé en deux parties :

• Une quantité relativement faible de « logique métier » complexe mais peu gourmande en calcul ;
• Un grand volume de « travail coûteux » intensif mais hautement structuré.

Ces deux formes de calcul sont mieux traitées de manière différente : la première, dont l’architecture peut être moins efficace mais doit être très polyvalente ; la seconde, dont l’architecture peut être moins polyvalente mais doit être extrêmement efficace.

Quels sont les exemples pratiques de ces différentes approches ?

Commençons par l’environnement que je connais le mieux : la machine virtuelle Ethereum (EVM). Voici la trace de débogage geth d’une transaction Ethereum récente : la mise à jour du hash IPFS de mon blog sur ENS. Cette transaction a consommé au total 46 924 gas, répartis comme suit :

• Coût de base : 21 000
• Données d’appel : 1 556
• Exécution EVM : 24 368
• Opcode SLOAD : 6 400
• Opcode SSTORE : 10 100
• Opcode LOG : 2 149
• Autres : 6 719

Trace EVM de la mise à jour du hash ENS. L’avant-dernière colonne indique la consommation de gas.

La morale de cette histoire est la suivante : la majeure partie de l’exécution (environ 73 % si l’on ne considère que l’EVM, environ 85 % si l’on inclut la partie du coût de base couvrant le calcul) se concentre sur un très petit nombre d’opérations coûteuses et structurées : lectures et écritures de stockage, logs et cryptographie (le coût de base inclut 3 000 pour la vérification de signature, l’EVM inclut également 272 pour le hash). Le reste de l’exécution correspond à la « logique métier » : manipuler les bits de calldata pour extraire l’ID de l’enregistrement que j’essaie de définir et le hash que je souhaite lui attribuer, etc. Dans un transfert de tokens, cela inclurait l’ajout et la soustraction de soldes, dans des applications plus avancées, cela pourrait inclure des boucles, etc.

Dans l’EVM, ces deux formes d’exécution sont traitées différemment. La logique métier de haut niveau est écrite dans des langages de haut niveau, généralement Solidity, qui peut être compilé vers l’EVM. Le travail coûteux est toujours déclenché par des opcodes EVM (SLOAD, etc.), mais plus de 99 % du calcul réel est effectué dans des modules spécialisés écrits directement dans le code client (voire dans des bibliothèques).

Pour renforcer la compréhension de ce modèle, explorons-le dans un autre contexte : le code IA écrit en Python avec torch.

Propagation avant d’un bloc d’un modèle Transformer

Que voyons-nous ici ? Nous voyons une quantité relativement faible de « logique métier » écrite en Python, qui décrit la structure des opérations exécutées. En pratique, il y aura également un autre type de logique métier qui décide de la manière d’obtenir les entrées et des opérations à effectuer sur les sorties. Mais si nous examinons chaque opération individuelle (self.norm, torch.cat, +, *, les différentes étapes à l’intérieur de self.attn...), nous voyons des calculs vectorisés : la même opération est effectuée en parallèle sur de nombreuses valeurs. Comme dans le premier exemple, une petite partie du calcul est consacrée à la logique métier, la majeure partie à l’exécution de grandes opérations structurées sur des matrices et des vecteurs — en fait, la plupart ne sont que des multiplications de matrices.

Comme dans l’exemple EVM, ces deux types de travail sont traités de deux manières différentes. Le code de logique métier de haut niveau est écrit en Python, un langage très polyvalent et flexible, mais aussi très lent ; on accepte simplement cette inefficacité car elle ne concerne qu’une petite partie du coût total du calcul. Pendant ce temps, les opérations intensives sont écrites dans du code hautement optimisé, généralement du code CUDA s’exécutant sur GPU. On voit même de plus en plus d’inférences LLM réalisées sur ASIC.

La cryptographie programmable moderne, telle que SNARK, suit à nouveau un modèle similaire à deux niveaux. Premièrement, le prouveur peut être écrit dans un langage de haut niveau, où le travail lourd est effectué par des opérations vectorisées, comme dans l’exemple IA ci-dessus. Mon code STARK circulaire en est un exemple. Deuxièmement, le programme exécuté à l’intérieur de la cryptographie lui-même peut être écrit de manière à séparer la logique métier générale et le travail coûteux hautement structuré.

Pour comprendre comment cela fonctionne, examinons l’une des tendances récentes des preuves STARK. Pour plus de généralité et de facilité d’utilisation, les équipes construisent de plus en plus de prouveurs STARK pour des machines virtuelles minimales largement adoptées, comme RISC-V. Tout programme nécessitant une preuve d’exécution peut être compilé en RISC-V, puis le prouveur peut prouver l’exécution du code RISC-V.

Diagramme issu de la documentation RiscZero

C’est très pratique : cela signifie que nous n’avons besoin d’écrire la logique de preuve qu’une seule fois, et à partir de là, tout programme nécessitant une preuve peut être écrit dans n’importe quel langage de programmation « traditionnel » (par exemple, RiskZero prend en charge Rust). Mais il y a un problème : cette approche génère une grande surcharge. La cryptographie programmable est déjà très coûteuse ; ajouter la surcharge d’exécution du code dans un interpréteur RISC-V est trop important. Les développeurs ont donc trouvé une astuce : identifier les opérations coûteuses spécifiques qui constituent la majeure partie du calcul (généralement le hash et la signature), puis créer des modules spécialisés pour prouver ces opérations très efficacement. Ensuite, il suffit de combiner le système de preuve RISC-V inefficace mais généraliste avec un système de preuve efficace mais spécialisé pour obtenir le meilleur des deux mondes.

La cryptographie programmable au-delà des ZK-SNARK, comme le calcul multipartite (MPC) et le chiffrement homomorphe complet (FHE), peut également être optimisée de manière similaire.

Globalement, quel est le phénomène ?

L’informatique moderne suit de plus en plus ce que j’appelle l’architecture glue et coprocessor : vous avez un composant central « glue », très polyvalent mais peu efficace, chargé de transférer des données entre un ou plusieurs composants coprocessor, qui sont peu polyvalents mais très efficaces.

Ceci est une simplification : en pratique, la courbe de compromis entre efficacité et polyvalence comporte presque toujours plus de deux niveaux. Les GPU et autres puces généralement appelées « coprocessor » dans l’industrie sont moins polyvalents que les CPU, mais plus que les ASIC. Le compromis de spécialisation est complexe, dépendant des prédictions et intuitions sur quelles parties de l’algorithme resteront inchangées dans cinq ans et lesquelles changeront dans six mois. Dans l’architecture de preuve ZK, on observe souvent une spécialisation à plusieurs niveaux similaire. Mais pour un modèle de pensée général, deux niveaux suffisent. On retrouve des situations similaires dans de nombreux domaines informatiques :

D’après les exemples ci-dessus, il est évident que le calcul peut être divisé de cette manière, ce qui semble être une loi naturelle. En fait, on trouve des exemples de spécialisation informatique depuis des décennies. Cependant, je pense que cette séparation s’accentue. Et il y a des raisons à cela :

Ce n’est que récemment que nous avons atteint la limite de l’augmentation de la vitesse d’horloge des CPU, de sorte que seuls des gains supplémentaires peuvent être obtenus par la parallélisation. Mais la parallélisation est difficile à raisonner, il est donc souvent plus pratique pour les développeurs de continuer à raisonner séquentiellement et de laisser la parallélisation se produire en arrière-plan, encapsulée dans des modules spécialisés pour des opérations spécifiques.

La vitesse de calcul n’est devenue que récemment si rapide que le coût du calcul de la logique métier est devenu réellement négligeable. Dans ce contexte, il est également logique d’optimiser la VM exécutant la logique métier pour des objectifs autres que l’efficacité du calcul : convivialité pour les développeurs, familiarité, sécurité et autres objectifs similaires. Pendant ce temps, les modules « coprocessor » spécialisés peuvent continuer à être conçus pour l’efficacité, tirant leur sécurité et leur convivialité de leur « interface » relativement simple avec le glue.

Il devient de plus en plus clair quelles sont les opérations coûteuses les plus importantes. Cela est particulièrement évident en cryptographie, où les types d’opérations coûteuses les plus probables sont : opérations modulaires, combinaisons linéaires sur courbes elliptiques (aussi appelées multiplications scalaires multiples), transformées de Fourier rapides, etc. En IA, c’est aussi de plus en plus évident : depuis plus de vingt ans, la plupart des calculs sont « principalement des multiplications de matrices » (bien que le niveau de précision varie). D’autres domaines suivent des tendances similaires. Par rapport à il y a 20 ans, il y a beaucoup moins d’inconnues dans le calcul (intensif).

Qu’est-ce que cela signifie ?

Un point clé est que le glue doit être optimisé pour être un bon glue, tandis que le coprocessor doit être optimisé pour être un bon coprocessor. Nous pouvons explorer ce que cela signifie dans plusieurs domaines clés.

EVM

Les machines virtuelles blockchain (comme l’EVM) n’ont pas besoin d’être efficaces, seulement familières. Il suffit d’ajouter les bons coprocessors (aussi appelés « précompilés »), et le calcul dans une VM inefficace peut en fait être aussi efficace que dans une VM native efficace. Par exemple, la surcharge induite par les registres 256 bits de l’EVM est relativement faible, tandis que les avantages de la familiarité de l’EVM et de l’écosystème de développeurs existant sont énormes et durables. Les équipes optimisant l’EVM ont même constaté que le manque de parallélisation n’est généralement pas le principal obstacle à la scalabilité.

La meilleure façon d’améliorer l’EVM pourrait simplement être (i) d’ajouter de meilleures précompilations ou opcodes spécialisés, par exemple une combinaison d’EVM-MAX et de SIMD pourrait être raisonnable, et (ii) d’améliorer la disposition du stockage, par exemple, les modifications des arbres Verkle réduisent considérablement le coût d’accès à des slots de stockage adjacents.

Optimisation du stockage dans la proposition d’arbre Verkle d’Ethereum, regroupant les clés de stockage adjacentes et ajustant le coût en gas pour le refléter. Des optimisations comme celle-ci, combinées à de meilleures précompilations, sont probablement plus importantes que de modifier l’EVM lui-même.

Calcul sécurisé et matériel ouvert

L’un des grands défis pour améliorer la sécurité de l’informatique moderne au niveau matériel est sa nature trop complexe et propriétaire : les puces sont conçues pour être efficaces, ce qui nécessite des optimisations propriétaires. Les portes dérobées sont faciles à cacher, les vulnérabilités par canaux auxiliaires sont constamment découvertes.

Des efforts sont continuellement déployés sous plusieurs angles pour promouvoir des alternatives plus ouvertes et plus sûres. Certains calculs sont de plus en plus effectués dans des environnements d’exécution de confiance, y compris sur le téléphone de l’utilisateur, ce qui a déjà amélioré la sécurité des utilisateurs. Le mouvement en faveur d’un matériel grand public plus open source se poursuit, avec quelques victoires récentes comme des ordinateurs portables RISC-V fonctionnant sous Ubuntu.

Ordinateur portable RISC-V fonctionnant sous Debian

Cependant, l’efficacité reste un problème. L’auteur de l’article lié ci-dessus écrit :

Les conceptions de puces open source plus récentes comme RISC-V ne peuvent pas rivaliser avec les technologies de processeur existantes qui ont bénéficié de décennies d’amélioration. Le progrès a toujours un point de départ.

Des idées plus paranoïaques, comme cette conception d’un ordinateur RISC-V construit sur FPGA, font face à une surcharge encore plus grande. Mais que se passerait-il si l’architecture glue et coprocessor signifiait que cette surcharge n’a en fait pas d’importance ? Et si nous acceptions que les puces ouvertes et sûres soient plus lentes que les puces propriétaires, voire que nous abandonnions des optimisations courantes comme l’exécution spéculative et la prédiction de branchement, mais que nous essayions de compenser cela en ajoutant des modules ASIC (propriétaires si nécessaire) pour les types de calculs les plus intensifs ? Les calculs sensibles pourraient être effectués sur la « puce principale », optimisée pour la sécurité, la conception open source et la résistance aux canaux auxiliaires. Les calculs plus intensifs (par exemple ZK proof, IA) seraient effectués dans des modules ASIC, qui auraient moins d’informations sur le calcul en cours (éventuellement, via un aveuglement cryptographique, dans certains cas même zéro information).

Cryptographie

Un autre point clé est que tout cela est très optimiste pour la cryptographie, en particulier pour l’adoption grand public de la cryptographie programmable. Nous avons déjà vu des implémentations ultra-optimisées de certains calculs hautement structurés dans SNARK, MPC et autres contextes : le surcoût de certains hash functions n’est que de quelques centaines de fois plus élevé que l’exécution directe du calcul, et le surcoût de l’IA (principalement la multiplication de matrices) est également très faible. Des améliorations comme GKR pourraient encore réduire ce niveau. L’exécution VM totalement générique, en particulier dans un interpréteur RISC-V, pourrait continuer à générer un surcoût d’environ dix mille fois, mais pour les raisons décrites dans cet article, cela n’a pas d’importance : tant que les parties les plus intensives du calcul sont traitées séparément avec des techniques spécialisées efficaces, le surcoût global reste maîtrisé.

Schéma simplifié d’un MPC spécialisé pour la multiplication de matrices, le composant principal de l’inférence de modèles IA. Voir cet article pour plus de détails, y compris comment préserver la confidentialité du modèle et des entrées.

Une exception à l’idée que « la couche glue n’a besoin que d’être familière, pas efficace » concerne la latence, et dans une moindre mesure la bande passante des données. Si le calcul implique des opérations lourdes répétées des dizaines de fois sur les mêmes données (comme en cryptographie et en IA), toute latence causée par une couche glue inefficace peut devenir le principal goulot d’étranglement du temps d’exécution. Ainsi, la couche glue a aussi des exigences d’efficacité, bien que plus spécifiques.

Conclusion

Dans l’ensemble, je pense que les tendances décrites ci-dessus sont très positives sous plusieurs angles. Premièrement, c’est une manière raisonnable de maximiser l’efficacité du calcul tout en préservant la convivialité pour les développeurs, permettant d’obtenir davantage des deux au bénéfice de tous. En particulier, en réalisant la spécialisation côté client pour l’efficacité, cela améliore notre capacité à exécuter localement sur le matériel utilisateur des calculs sensibles et exigeants en performance (par exemple ZK proof, inférence LLM). Deuxièmement, cela crée une immense fenêtre d’opportunité pour s’assurer que la quête d’efficacité ne se fait pas au détriment d’autres valeurs, notamment la sécurité, l’ouverture et la simplicité : sécurité et ouverture contre les canaux auxiliaires dans le matériel informatique, réduction de la complexité des circuits dans les ZK-SNARK, et réduction de la complexité dans les machines virtuelles. Historiquement, la recherche d’efficacité a relégué ces autres facteurs au second plan. Avec l’architecture glue et coprocessor, ce n’est plus nécessaire. Une partie de la machine optimise l’efficacité, l’autre la polyvalence et d’autres valeurs, les deux travaillant en synergie.

Cette tendance est également très favorable à la cryptographie, car la cryptographie elle-même est un exemple majeur de « calcul structuré coûteux », et cette tendance accélère son développement. Cela offre une opportunité supplémentaire d’améliorer la sécurité. Dans le monde de la blockchain, cela permet également d’améliorer la sécurité : nous pouvons moins nous soucier de l’optimisation de la machine virtuelle et nous concentrer davantage sur l’optimisation des précompilations et des autres fonctionnalités coexistant avec la VM.

Troisièmement, cette tendance offre des opportunités aux acteurs plus petits et plus récents. Si le calcul devient moins monolithique et plus modulaire, cela abaisse considérablement la barrière à l’entrée. Même un ASIC pour un seul type de calcul peut avoir un impact. Il en va de même dans le domaine des preuves ZK et de l’optimisation EVM. Il devient plus facile et plus accessible d’écrire du code avec une efficacité proche de l’état de l’art. L’audit et la vérification formelle de ce type de code deviennent également plus faciles et plus accessibles. Enfin, comme ces domaines informatiques très différents convergent vers certains modèles communs, il y a plus d’espace pour la collaboration et l’apprentissage mutuel.