Introduction

Les blockchains sont des registres mondialement distribués qui parviennent à un consensus sur un état global. Certaines blockchains sont équipées d'un environnement d'exécution complet de Turing qui permet la programmabilité sur cet état global. Les programmes ciblant les environnements d'exécution des blockchains sont appelés contrats intelligents, et les blockchains sous-jacentes sont appelées plateformes de contrats intelligents. Ethereum, Solana et Avalanche sont parmi les plateformes de contrats intelligents les plus connues. Nous pouvons considérer les plateformes de contrats intelligents comme des ordinateurs distribués, l'environnement d'exécution (ou la machine virtuelle) agissant comme l'UCP et l'état jouant le rôle de stockage.

Ce cadrage des blockchains en tant qu'ordinateurs sera important pour motiver pourquoi les coprocesseurs / calcul hors chaîne sont inévitables, notamment dans le contexte des blockchains. Dans l'informatique traditionnelle, les coprocesseurs ont été créés dans la microarchitecture pour améliorer les performances. De même, les coprocesseurs sur Ethereum promettent l'accès à des données historiques et un calcul hors chaîne performant pour augmenter les fonctionnalités et l'espace de conception du protocole de couche de base. Consultez cet article introductif sur les coprocesseurs pour en savoir plus.

Cet article explore les coprocesseurs à partir des premiers principes, dans le but de clarifier leur importance et leurs méta-propriétés. Nous les comparons ensuite aux rollups, démontrant comment ces deux concepts, bien qu'ils soient différents, sont étroitement liés. Nous fournissons également des exemples de cas où les rollups et les coprocesseurs peuvent être utilisés conjointement. Par exemple, même un rollup tout-puissant ou un L1 pourrait avoir besoin d'un coprocesseur pour des tâches intensives.

Nous concluons cet article en observant que les blockchains se dirigent vers un avenir où le calcul est centralisé, mais la vérification reste décentralisée. Les rollups, coprocesseurs et toute autre forme de calcul vérifiable hors chaîne ne sont que des instantiations différentes de cet avenir.

Comment nous en sommes arrivés ici :

Dans "Les limites de la scalabilité de la blockchain", Vitalik a mentionné que pour la décentralisation de la blockchain, il est important que les utilisateurs réguliers puissent exécuter un nœud.

Comme mentionné précédemment, Ethereum peut être conceptualisé comme un ordinateur mondial décentralisé à bien des égards. Il s'agit d'un réseau de nœuds exécutant un logiciel qui fournit des ressources de calcul pour l'exécution de contrats intelligents. La blockchain Ethereum stocke des informations d'état et du code, similaire au stockage et à la mémoire d'un ordinateur. Et la Machine Virtuelle Ethereum (EVM) s'exécute sur chaque nœud, traitant les transactions et exécutant du code comme un CPU. Cependant, Ethereum est sans permission et décentralisé, utilisant un consensus entre des nœuds non fiables. Si certains nœuds se déconnectent, le réseau continue de fonctionner. Pour garantir la correction des opérations de l'EVM, les validateurs sur les réseaux de Proof-of-Stake (PoS) comme Ethereum doivent effectuer toutes les transitions d'état pour les vérifier. Cela limite la vitesse d'un réseau PoS à ses nœuds les plus lents, limitant la quantité de calcul que les développeurs d'applications ont à leur disposition.

Contrairement à un ordinateur ordinaire, Ethereum limite le calcul et le stockage pour empêcher les abus réseau. Des frais sont facturés pour chaque opération, rendant les boucles infinies financièrement peu pratiques. Cette approche maintient les barrières à l'entrée basses, permettant à un matériel quotidien tel qu'un Raspberry Pi de faire tourner des nœuds réseau. Les contraintes permettent un système inclusif où tout le monde peut aider à exploiter le réseau décentralisé Ethereum.

En raison de ces restrictions de calcul des nœuds Ethereum, des applications complexes telles que des modèles d'apprentissage automatique, des jeux ou des applications de calcul scientifique ne peuvent pas être exécutées directement sur Ethereum aujourd'hui.

C'est un compromis pour rendre Ethereum largement accessible, sécurisé et durable en tant que base pour les applications de base. Mais inévitablement, certaines limitations existent par rapport à un ordinateur computationnellement non restreint. Il présente des limites même par rapport à un processeur ancien comme un Pentium 5 :

Pas de calculs en virgule flottante complexes - L'EVM ne prend en charge que les opérations mathématiques et logiques de base. Les calculs numériques avancés tels que les réseaux neuronaux ne sont pas réalisables. (Un fait intéressant est l'incapacité à gérer les nombres à virgule flottante a également rendu plus difficile dans l'histoire récente le swap d'actifs de rebase comme Ampleforth, etc., et parfois même incompatible avec certains DEXs).

Calcul limité par bloc - Les frais de gaz mesurent les calculs, de sorte que des logiciels complexes comme les jeux seraient prohibitivement coûteux. La limite de gaz par bloc est de 30M gaz.

Mémoire restreinte - Les contrats intelligents ont de petites limites de stockage permanent, ce qui rend les grands programmes difficiles.

Aucun stockage de fichier persistant - Il n'y a aucun moyen de stocker des fichiers tels que des graphiques, de l'audio ou de la vidéo sur la blockchain.

Vitesse lente - Les vitesses de transaction sur Ethereum sont actuellement d'environ ~15 TPS, plusieurs ordres de grandeur plus lentes qu'un CPU.

En fin de compte, le stockage et le calcul limités restreignent les degrés de liberté disponibles pour les applications (ces limites diffèrent d'une blockchain à l'autre, mais elles existent toujours). Les gens ont comparé les blockchains aux environnements de calcul contraints des années 1970-1980, mais nous pensons qu'il existe de grandes différences entre ces deux :

La croissance de l'informatique dans les années 1970-1980 a été rapide (avec le nombre de transistors dans les microprocesseurs passant d'environ 1 000 à environ 1 000 000 au cours de cette période). Mais cette croissance ne signifiait pas que les gens achetaient souvent ou mettaient à jour leurs ordinateurs. Comme les plateformes de contrats intelligents sont limitées par leurs nœuds les plus lents, une accélération à la pointe de l'informatique ne conduira pas nécessairement à ce que les blockchains voient une augmentation proportionnelle de la vitesse de calcul. Une accélération ne peut se produire que si les exigences de base pour les nœuds sur la blockchain sont mises à jour.

Il existe également un compromis clair entre la mise à jour constante des exigences matérielles minimales pour les nœuds et la décentralisation. Les validateurs individuels pourraient ne pas vouloir mettre à niveau le matériel tous les deux ans (et ils ne veulent certainement pas surveiller les performances quotidiennement), ce qui conduit uniquement les professionnels à vouloir gérer l'infrastructure de la blockchain.

Tout cela pour dire qu'au fil des ans, les processeurs se sont améliorés et que nous avons obtenu plus de cœurs de processeur sur chaque appareil pour nous permettre d'accomplir des tâches de plus en plus compliquées. Si nous pensons que les ordinateurs blockchain n'accéléreront pas aussi rapidement que l'informatique traditionnelle (en raison des exigences de base des nœuds), il est logique d'essayer de trouver des sources de calcul alternatives. Une analogie intéressante à faire ici est que les processeurs dans l'informatique traditionnelle ne se sont pas bien comportés dans les tâches de traitement graphique, ce qui a conduit à la montée en puissance des GPU dans presque tous les ordinateurs. De même, étant donné que les blockchains se concentrent sur le fait d'être des magasins sécurisés d'états avec des batteries de calcul simples activées, il existe une opportunité claire pour que le calcul hors chaîne élargisse l'espace de conception des applications. Aujourd'hui, les blockchains ne sont logiques que pour les applications à faible calcul qui souhaitent des propriétés telles que l'accès ouvert, la souveraineté individuelle, la résistance à la censure et la composabilité. Pour mettre une plus grande variété d'applications onchain, nous devons lever les contraintes que nous imposons aux développeurs d'applications. Nous disons cela en comprenant que ces contraintes ont également été une aubaine pour l'expérimentation. Par exemple, les CLOB ne pouvaient pas fonctionner efficacement sur Ethereum en raison des contraintes de calcul, c'est pourquoi les AMM ont été adoptés, ayant depuis enregistré mille milliards de dollars de volume.

Il existe deux approches courantes pour rendre plus de puissance de calcul disponible pour les applications blockchain :

Augmenter relativement souvent les exigences de base des nœuds. C'est à peu près le chemin intégré des blockchains haute performance comme Solana et Sui. Un niveau de base élevé pour les nœuds rend possible la construction d'une blockchain très rapide et lève également certaines contraintes de conception de l'application. Phoenix, un DEX de carnet d'ordres limité sur Solana, ne pourrait pas être construit sur Ethereum (ou tout L2) aujourd'hui. L'inconvénient d'augmenter les exigences de base est que si elles augmentent constamment, l'exécution des nœuds pourrait ne être viable que pour les fournisseurs d'infrastructure professionnels. Les exigences historiques en RAM font un assez bon travail pour montrer comment les exigences matérielles ont augmenté de manière constante sur Solana:

Archive Web (Note : nous utilisons les exigences médianes en RAM de 2020)

Déplacer le calcul hors chaîne vers des tiers. C'est la stratégie adoptée par l'écosystème Ethereum. Ces tiers pourraient eux-mêmes être des blockchains (dans le cas des rollups), des dispositifs de calcul vérifiables hors chaîne (c'est-à-dire des coprocesseurs) ou des tiers de confiance (comme c'est le cas avec le calcul hors chaîne spécifique à une application comme le carnet de commandes dydx).

Vers l'unification du calcul hors chaîne

Récemment, il y a eu une augmentation des discussions sur les coprocesseurs, qui offrent un calcul vérifiable hors chaîne. Les coprocesseurs peuvent être mis en œuvre de différentes manières, notamment mais sans s'y limiter, les preuves de connaissance nulle ou les environnements d'exécution de confiance (TEEs). Quelques exemples sont :

Coprocesseurs ZK : Axiom, Bonsaï de Risc Zero.

TEEs: Huitre de Marlin,

En même temps, en ce qui concerne le déchargement des calculs, la feuille de route centrée sur le rollup d'Ethereum décharge les calculs vers divers rollups qui se règlent sur Ethereum. Au cours des dernières années, un flux constant de développeurs et d'utilisateurs ont migré vers les rollups en raison d'une combinaison de transactions moins chères et plus rapides et d'incitations fournies par les rollups. Dans un monde idéal, les rollups permettent à Ethereum d'étendre sa capacité de calcul globale via l'exécution hors chaîne sans ajouter d'hypothèses de confiance. Plus de calcul ne se réfère pas seulement à l'exécution de plus de transactions, mais aussi à la réalisation de calculs plus expressifs par transaction. Les nouveaux types de transactions élargissent l'espace de conception disponible pour les applications, et le débit plus élevé réduit le coût de réalisation de ces transactions expressives, garantissant un accès abordable à une classe d'applications plus élevée.

Avant d'aller plus loin, définissons brièvement à la fois les rollups et les coprocesseurs pour éviter toute confusion :

Rollups: Les Rollups maintiennent un état persistant et partitionné différent de leurs chaînes de base/hôtes mais héritent toujours des propriétés de sécurité de leur base en postant des données/ preuves. En déplaçant l'état de la chaîne hôte, les Rollups peuvent utiliser des calculs supplémentaires pour effectuer des transitions d'état avant de poster des preuves d'intégrité de ces transitions d'état à la chaîne hôte. Les Rollups sont particulièrement utiles aux utilisateurs qui ne veulent pas payer les frais élevés d'Ethereum mais souhaitent accéder aux propriétés de sécurité d'Ethereum.

Avant de plonger dans les coprocesseurs, donnons un peu plus de contexte sur la façon dont le développement de contrats intelligents limité sur Ethereum est aujourd'hui. Ethereum a un stockage d'état persistant dans son état global - soldes des comptes, données des contrats, etc. Ces données persistent indéfiniment sur la blockchain. Cependant, il existe des limitations :

La taille maximale des données de contrat est limitée (par exemple, 24 Ko par contrat actuellement et a été définie dans l'EIP 170). Stocker de gros fichiers dépasserait cette limite. (*Pas résolu non plus par les coprocesseurs)

La lecture/écriture du stockage de contrat est plus lente qu'un système de fichiers ou une base de données. Accéder à 1 Ko de données peut coûter des millions de gaz.

Tant que l'état global persiste, les nœuds individuels ne conservent que l'état récent localement en mode "élagage". L'historique complet de l'état nécessite un nœud d'archive.

Il n'existe pas de primitives de système de fichiers natifs pour gérer des fichiers tels que des images, de l'audio et des documents. Les contrats intelligents ne peuvent lire/écrire que des types de données de base dans le stockage.

Les solutions à ce sujet sont :

Les gros fichiers peuvent être divisés en plus petites parties pour s'adapter aux limites de stockage du contrat.

Les références de fichiers peuvent être stockées on-chain, les fichiers étant stockés off-chain dans des systèmes comme IPFS.

Coprocesseurs: Les coprocesseurs ne conservent aucun état eux-mêmes; ils se comportent comme des fonctions lambda sur AWS, où les applications peuvent leur envoyer une tâche de calcul, et ils renvoient le résultat avec une preuve de calcul. Les coprocesseurs augmentent fondamentalement la puissance de calcul disponible pour une transaction donnée, mais comme la preuve sur les coprocesseurs se fait également sur une base par transaction, les utiliser sera plus coûteux que les rollups. Étant donné le coût, les coprocesseurs sont susceptibles d'être utiles aux protocoles ou aux utilisateurs qui souhaitent effectuer des tâches complexes ponctuelles de manière vérifiable. Un autre avantage des coprocesseurs est qu'ils permettent aux applications utilisant un calcul hors chaîne d'accéder également à l'intégralité de l'historique de l'Éthereum sans ajouter d'hypothèses de confiance à l'application elle-même; ce qui n'est pas possible sur un contrat intelligent classique aujourd'hui.

Pour illustrer la différence entre les Rollups et les coprocesseurs, référons-nous aux saveurs ZK de ces deux primitives. Les Rollups ZK accèdent à la vérifiabilité et à l'aspect de compression des preuves à divulgation nulle, ce qui leur permet d'augmenter fondamentalement le débit pour leur écosystème. Les coprocesseurs, quant à eux, n'accèdent qu'à la propriété de vérifiabilité des preuves zk, ce qui signifie que le débit global du système reste le même. De plus, les Rollups ZK nécessitent des circuits pouvant prouver n'importe quel programme ciblant la machine virtuelle pour ce Rollup (par exemple, les Rollups sur Ethereum ont construit des zkEVM pour les contrats ciblant l'EVM). En revanche, les coprocesseurs ZK ont seulement besoin de construire des circuits pour les tâches auxquelles ils sont affectés à effectuer.

Donc, il semble que les deux plus grandes différences entre les rollups et les coprocesseurs sont :

Les Rollups maintiennent un état persistant partitionné, et les coprocesseurs non (ils utilisent l'état de la chaîne hôte).

Les Rollups (comme leur nom l'indique) regroupent plusieurs transactions ensemble, et les coprocesseurs sont généralement utilisés pour des tâches compliquées faisant partie d'une seule transaction (du moins dans le paradigme actuel).

Récemment, les Booster Rollups ont été proposés, qui exécutent des transactions comme s'ils fonctionnaient directement sur la chaîne hôte, avec accès à l'état complet de l'hôte. Cependant, les Booster Rollups ont également leur propre stockage, ce qui leur permet de mettre à l'échelle la computation et le stockage à la fois sur l'hôte et sur le rollup. La proposition de Booster Rollup souligne qu'il existe un spectre dans la conception de calcul hors chaîne, avec des rollups traditionnels et des coprocesseurs se situant à chaque extrémité de ce spectre. Les Rollups, les Booster Rollups et les Coprocesseurs fournissent tous un accès à plus de calcul et ne diffèrent que par la quantité d'état qu'ils détiennent partitionnée de leur base L1.

Lors d'une intervention au Modular Summit de 2023 intitulée "Les transactions protégées sont des Rollups", Henry De Valence a parlé de ce concept précis et a présenté une image très simple pour définir un rollup :

Le discours pose que toute exécution déchargée par la chaîne de base à un tiers est un rollup. Selon sa définition, les coprocesseurs seraient également des rollups. Cela diffère légèrement de notre vision unifiante des rollups et des coprocesseurs sous la bannière du calcul vérifiable hors chaîne, mais le sentiment global reste le même!

Dans sa vision de l'Endgame, Vitalik discute d'un avenir où la production de blocs est centralisée et la validation des blocs est sans confiance et hautement décentralisée. Nous croyons que c'est à peu près le bon modèle pour réfléchir à ce qui se passe maintenant. Dans un zk-rollup, la production de blocs et le calcul de transition d'état sont centralisés. Cependant, les preuves permettent à la vérification d'être bon marché et décentralisée. De même, un co-processeur zk n'a pas de production de blocs; il accède uniquement aux données historiques et calcule les transitions d'état sur ces données. Il est probable que le calcul sur un co-processeur zk soit toujours effectué sur une machine centralisée; cependant, la preuve de validité retournée avec un résultat permet à quiconque de vérifier les résultats avant de les utiliser. Peut-être est-il correct de reformuler la vision de Vitalik comme suit : « un avenir où le calcul est centralisé, mais la vérification du calcul centralisé est sans confiance et hautement décentralisée ».

Même même mais différent

Malgré leurs similitudes globales, les rollups et les coprocesseurs servent aujourd'hui des marchés très différents. On pourrait se demander : « Si nous pouvons simplement utiliser un coprocesseur sur ETH L1 et accéder à sa liquidité, pourquoi avons-nous besoin de rollups ? » Bien que ce soit une question légitime, nous pensons qu'il y a quelques raisons pour lesquelles les rollups ont encore du sens (et présentent aujourd'hui une opportunité de marché beaucoup plus importante que les coprocesseurs).

Comme mentionné précédemment, les coprocesseurs vous permettent d'accéder à plus de puissance de calcul dans la même transaction que le L1. Mais ils ne peuvent pas aider à déplacer l'aiguille sur le nombre de transactions pouvant être effectuées par la blockchain qui appelle le coprocesseur (si vous pensez au regroupement, voilà, vous êtes arrivé à un rollup). En maintenant un état persistant partitionné, les rollups peuvent augmenter le nombre de transactions disponibles pour les personnes qui souhaitent accéder à l'espace de blocs avec les propriétés de sécurité d'Ethereum. Cela est possible car les rollups ne postent que sur Ethereum tous les n blocs et n'obligent pas tous les validateurs d'Ethereum à vérifier qu'une transition d'état s'est produite. Les parties intéressées peuvent simplement se fier à la preuve.

Même si vous utilisez des coprocesseurs, vous devez quand même payer le même ordre de grandeur de frais que toute autre transaction sur le L1. En revanche, les rollups via regroupement peuvent réduire les coûts de plusieurs ordres de grandeur.

De plus, étant donné que les rollups offrent la possibilité d'exécuter des transactions sur cet état séparé, ils se comportent toujours comme des blockchains (des blockchains plus rapides et moins décentralisées, mais des blockchains néanmoins), ils ont donc également des limites claires sur la quantité de calcul accessible à partir du rollup lui-même. Dans ce scénario, un coprocesseur peut être utile pour les rollups si un utilisateur souhaite effectuer des transactions arbitrairement complexes (et maintenant vous effectuez des transactions vérifiables sur un rollup, donc vous n'avez qu'à obéir aux lois physiques du rollup).

Un autre point important à noter ici est que la plupart de la liquidité réside actuellement sur ETH L1, donc pour de nombreux protocoles qui dépendent de la liquidité pour améliorer leurs produits, il pourrait être astucieux de toujours se lancer sur le mainnet Ethereum. Une application sur le mainnet Ethereum peut avoir accès à plus de puissance de calcul en effectuant intermittemment des transactions sur un coprocesseur. Par exemple, un DEX comme Ambient ou Uniswap v4 peut utiliser des hooks en conjonction avec des coprocesseurs pour effectuer une logique compliquée sur la manière de modifier les frais ou même de modifier la forme de la courbe de liquidité en fonction des données du marché.

Une analogie intéressante compare l'interaction entre les rollups et les coprocesseurs à la programmation impérative et fonctionnelle. La programmation impérative se concentre sur les états mutables et les effets secondaires, spécifiant pas à pas comment exécuter les tâches. La programmation fonctionnelle met l'accent sur les données immuables et les fonctions pures, évitant les changements d'état et les effets secondaires. De la même manière, les rollups sont comme des programmes impératifs qui modifient l'état qu'ils détiennent, tandis que les coprocesseurs sont comme des programmes fonctionnels qui ne mutent pas l'état mais produisent un résultat avec des preuves de calcul. De plus, tout comme la programmation impérative et fonctionnelle, les rollups et les coprocesseurs ont leur place et doivent être utilisés en conséquence.

Un avenir basé sur la preuve

Si nous nous retrouvons dans un monde où le calcul est centralisé, mais où la vérification du calcul centralisé est sans confiance et hautement décentralisée, où cela laisse-t-il Ethereum? L'ordinateur mondial sera-t-il réduit à une simple base de données? Est-ce une mauvaise chose?

En fin de compte, l'objectif d'Ethereum est de donner à ses utilisateurs accès à un calcul et un stockage sans confiance. Dans le passé, la seule façon d'accéder à un calcul sans confiance sur Ethereum était que le calcul soit effectué et vérifié par tous les nœuds. Avec l'avancée des techniques de preuve (en particulier des preuves à divulgation nulle), nous pouvons déplacer une grande partie du calcul effectué sur les nœuds validateurs vers un calcul hors chaîne et faire en sorte que seuls les validateurs vérifient les résultats sur la chaîne. Cela transforme essentiellement Ethereum en tableau d'affichage immuable du monde. Les preuves de calcul nous permettent de vérifier qu'une transaction a été effectuée correctement, et en les publiant sur Ethereum, nous obtenons une horodatage et un historique immuable pour ces preuves. À mesure que les preuves à divulgation nulle deviennent plus efficaces sur les calculs arbitraires, il est probable qu'à un moment donné, le coût du calcul en ZK soit significativement inférieur au coût de le faire sur une blockchain (peut-être même une chaîne CometBFT à 100 validateurs). Dans un tel monde, il est difficile d'imaginer que les preuves à divulgation nulle ne deviennent pas le mode dominant d'accès au calcul sans confiance. Des réflexions similaires ont récemment été exprimées par David Wong également:

Un avenir dans lequel toute computation peut être prouvée nous permet également de construire une infrastructure pour les types d'applications sans confiance qui ont une demande d'utilisateur au lieu d'essayer de modifier la couche de base d'Ethereum pour devenir le foyer de ces applications. Dans le cas idéal, une infrastructure sur mesure créera des expériences utilisateur plus fluides et évoluera également avec les applications construites dessus. Cela permettra espérons-le aux applications web3 de rivaliser avec leurs homologues web2 et d'introduire le futur sans confiance, basé sur la preuve, dont les cypherpunks ont toujours rêvé.

Dans l'ensemble, nous croyons que nous nous dirigeons vers le paradigme suivant :

————————————————————Ne faites pas confiance, vérifiez————————————————————-

Avertissement：

1. Cet article est repris de [Gatemiroir]. Tous les droits d'auteur appartiennent à l'auteur original [Jacob Ko]. Si des objections sont soulevées concernant cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.