Vitalik Buterin explore « la colle et le coprocesseur » pour l'informatique

Le créateur Ethereum Vitalik Buterin, explore un nouveau concept sur la façon dont l'informatique moderne peut être divisée en deux parties : un composant « colle » et un « coprocesseur ».

L’idée ici est simple : diviser le travail. La colle effectue les tâches générales et moins intenses, tandis que le coprocesseur s'occupe des calculs lourds et structurés. 

Vitalik nous l'explique Ethereum (EVM) sont déjà divisés de cette façon. Certaines parties du processus nécessitent une efficacité élevée, tandis que d’autres sont plus flexibles mais moins efficaces.

Prenez Ethereum , par exemple. Lors d'une transaction récente au cours de laquelle Vitalik a mis à jour le hachage IPFS de son blog sur Ethereum Name Service (ENS), la consommation de gaz a été répartie sur différentes tâches. La transaction a consommé au total 46 924 gaz. 

La répartition ressemble à ceci : 21 000 gaz pour le coût de base, 1 556 pour les données d'appel et 24 368 pour l'exécution EVM. Des opérations spécifiques comme SLOAD et SSSTORE ont consommé respectivement 6 400 et 10 100 gaz. Les opérations LOG ont nécessité 2 149 gaz, et le reste a été consommé par divers processus.

Vitalik affirme qu'environ 85 % du gaz de cette transaction a été consacré à quelques opérations lourdes, telles que les lectures et écritures de stockage, la journalisation et la cryptographie.

Le reste était ce qu'il appelle la « logique métier », les éléments les plus simples et de niveau supérieur, comme le traitement des données qui dictent quel enregistrement mettre à jour. 

Vitalik souligne également que l’on peut voir la même chose dans les modèles d’IA écrits en Python. Par exemple, lors de l'exécution d'une passe avant dans un modèle de transformateur, la plupart du travail est effectué par des opérations vectorisées, comme la multiplication matricielle. 

Ces opérations sont généralement écrites dans du code optimisé, souvent CUDA exécuté sur des GPU. La logique de haut niveau, cependant, est en Python, un langage général mais lent qui ne touche qu'une petite partie du coût total de calcul.

Le développeur Ethereum pense également que ce modèle devient de plus en plus courant dans la cryptographie programmable moderne, comme les SNARK.

Il souligne les tendances en matière de démonstration STARK, où les équipes construisent des prouveurs à usage général pour les machines virtuelles minimales comme RISC-V.

Tout programme nécessitant une preuve peut être compilé dans RISC-V, et le prouveur prouve l'exécution de RISC-V. Cette configuration est pratique, mais elle entraîne des frais généraux. La cryptographie programmable est déjà coûteuse, et ajouter le coût d'exécution du code dans un interpréteur RISC-V représente une somme considérable.

Alors, que font les développeurs ? Ils contournent le problème. Ils dent les opérations spécifiques et coûteuses qui occupent la majeure partie du calcul (comme les hachages et les signatures) et créent des modules spécialisés pour prouver efficacement ces opérations. 

Ensuite, ils combinent le système d’essai général RISC-V avec ces systèmes efficaces et spécialisés, obtenant ainsi le meilleur des deux mondes. Selon Vitalik, cette approche sera probablement observée dans d'autres domaines de la cryptographie, comme le calcul multi-parties (MPC) et le cryptage entièrement homomorphique (FHE).

Où la colle et le coprocesseur entrent en jeu

Selon Vitalik, nous assistons à la montée en puissance d'une architecture « colle et coprocesseur » en informatique. La colle est générale et lente, chargée de gérer les données entre un ou plusieurs coprocesseurs, spécialisés et rapides. Les GPU et les ASIC sont de parfaits exemples de coprocesseurs. 

Ils sont moins généraux que les CPU mais bien plus efficaces pour certaines tâches. Le plus délicat est de trouver le bon équilibre entre généralité et efficacité.

Dans Ethereum , l'EVM n'a pas besoin d'être efficace, il doit juste être familier. En ajoutant les bons coprocesseurs ou précompilations, vous pouvez rendre une VM inefficace presque aussi efficace qu'une machine nativement efficace. 

Et si cela n’avait pas d’importance ? Et si nous acceptions que les puces ouvertes soient plus lentes et utilisions une architecture de colle et de coprocesseur pour compenser ? 

L'idée est que vous puissiez concevoir une puce principale optimisée pour la sécurité et la conception open source tout en utilisant des modules ASIC propriétaires pour les calculs les plus intensifs. 

Les tâches sensibles pourraient être gérées par la puce principale sécurisée, tandis que les tâches lourdes, comme le traitement de l'IA ou la vérification ZK, pourraient être confiées aux modules ASIC.