Comprendre la chaîne SUAVE de Flashbots du point de vue des développeurs : au-delà de la MEV, quelles sont les autres possibilités offertes par l'EVM + TEE ?
TechFlow SélectionTechFlow Sélection
Comprendre la chaîne SUAVE de Flashbots du point de vue des développeurs : au-delà de la MEV, quelles sont les autres possibilités offertes par l'EVM + TEE ?
La chaîne SUAVE, en introduisant un environnement TEE, offre aux développeurs d'applications des capacités suffisamment puissantes, ouvrant ainsi la voie à de nombreux cas d'utilisation potentiels.
Dédié à des analyses Web3 approfondiesRédaction : ZHIXIONG PAN, DUGUBUYAN
SUAVE est un projet décentralisé développé par Flashbots. Il met en place un réseau doté d’un environnement TEE (Enclave de confiance) afin de résoudre des problèmes rencontrés dans les processus MEV tels que la gestion des clés et la confiance mutuelle entre plusieurs parties. L’intégration du TEE dans le projet SUAVE ouvre également des possibilités bien au-delà de la simple résolution des problèmes liés au MEV.
Dépôts de code associés à SUAVE
Étant une extension d’Ethereum, SUAVE est naturellement compatible avec la machine virtuelle Ethereum (EVM). Les projets actuellement disponibles sur GitHub incluent notamment : SUAVE-geth, SUAVE-std et SUAVE-examples.
SUAVE-geth correspond au niveau d’exécution étendu basé sur geth. Ce dépôt ajoute essentiellement un environnement de calcul chiffré à geth ainsi que certains précompilés (precompile) fonctionnant au sein de cet environnement cryptographique. Un précompilé notable permet d’effectuer des requêtes HTTPS standard, offrant aux développeurs la possibilité, via l’environnement TEE, de fournir aux utilisateurs un accès à d’autres réseaux. En outre, il inclut toute une série de précompilés destinés à exploiter les fonctionnalités du TEE, comme l’obtention de paramètres chiffrés, le stockage et la récupération d’informations sécurisées, formant ainsi une infrastructure de développement fondée sur un environnement de confiance.
SUAVE-std est un dépôt conçu pour faciliter l’utilisation par les développeurs ; on peut le voir comme une bibliothèque d’outils de développement. Par exemple, il encapsule l’utilisation des requêtes HTTP, allant jusqu’à proposer une bibliothèque dédiée à ChatGPT. Cela permet aux développeurs d’éviter de construire manuellement les messages de requête ou de parser les réponses de ChatGPT : il leur suffit de remplacer leur propre clé API lors de l’assemblage de la requête HTTP. La sécurité de cette clé API est garantie par l’environnement TEE, puisque toutes les opérations s’y déroulent. Initialement, cette bibliothèque standard utilisait par défaut le modèle GPT-3.5-turbo avec une température fixée à 0.7. Des interfaces plus flexibles ont désormais été ajoutées, permettant de transmettre le modèle et d'autres paramètres en tant qu'arguments.
Le dépôt SUAVE-examples fournit des cas pratiques illustrant le développement d’applications, ce qui en fait un excellent tutoriel pour débutants. Les développeurs nouvellement initiés au développement d’applications SUAVE peuvent apprendre et se former grâce aux exemples contenus dans ce projet.
Pratique du développement SUAVE
Étant une extension d’Ethereum (son environnement exécutable étant appelé MEVM, pour Modified Ethereum Virtual Machine), le développement de contrats intelligents sur SUAVE est compatible EVM. La documentation officielle utilise exclusivement Solidity pour ses explications. Ainsi, toute expérience antérieure en développement Solidity est directement applicable. Le développement d’applications SUAVE peut être vu comme du développement Solidity enrichi des fonctionnalités de calcul sécurisé offertes par l’environnement TEE.
Plusieurs précompilés MEVM jouent un rôle central dans SUAVE. Le premier est confidentialInputs, qui permet de recevoir des paramètres chiffrés provenant de requêtes applicatives. Ces paramètres sont généralement des informations sensibles telles que des clés privées ou des clés API. Leur sécurité repose sur le fait que le texte clair n’apparaît jamais en dehors de l’environnement TEE. Dans le développement d'applications, c’est précisément via cette interface que l’on accède au contenu en clair. Le processus de transmission est entièrement chiffré et sécurisé — nous reviendrons plus tard sur son fonctionnement. Le deuxième est confidentialStore, utilisé pour stocker des informations confidentielles. Une fois récupérées, ces données peuvent ne pas être immédiatement nécessaires au calcul et doivent donc être conservées pour une utilisation ultérieure. Le troisième est confidentialRetrieve, qui permet, lorsque les données confidentielles sont requises pour un calcul, de les récupérer depuis le contexte sécurisé du TEE.
La capacité de SUAVE à stocker en toute sécurité des informations privées permet des scénarios comme celui-ci : « Un utilisateur téléverse sa clé privée, et une tierce partie effectue des calculs métier. Lorsque certaines conditions sont remplies, cette tierce partie peut utiliser directement la clé privée de l’utilisateur pour signer une transaction. Ainsi, la tierce partie peut utiliser la clé privée conformément à des règles prédéfinies, mais elle n’a jamais accès au texte clair de cette clé. »
SUAVE utilise des requêtes HTTPS pour effectuer des opérations inter-chaînes. Son kit d’outils inclut une bibliothèque nommée gateway permettant directement de lire des informations sur d’autres chaînes. En pratique, cela consiste à configurer le nœud RPC d’une chaîne donnée, ou plus couramment, à téléverser des clés API provenant de services comme Infura ou Etherscan. Lorsqu’un appel est nécessaire, une requête HTTP est envoyée directement au nœud concerné. Pour les écritures inter-chaînes, le kit inclut un module transaction aidant les développeurs à encoder des messages conformes à EIP-1559, puis à diffuser la transaction via l’interface eth_sendRawTransaction.
Un autre cas d’usage mérite d’être mentionné : compiler un bytecode Solidity, le téléverser comme paramètre confidentiel et le stocker, puis le déployer et l’exécuter uniquement lorsque certaines conditions sont remplies. Cela permet de créer des bibliothèques privées. Ce scénario peut être étendu à la combinaison « clé privée + bytecode privé », rendant ainsi possible des transactions entièrement privées lors d’appels délégués à des tiers.
Caractéristiques de SUAVE
L’état final visé par SUAVE est une blockchain autonome, appelée « chaîne SUAVE ». Cette chaîne implémente le MEVM. Étant compatible EVM, il est possible d’y créer des actifs standards tels que ERC20 ou ERC721, et les opérations sur chaîne n’ont rien de différent par rapport aux autres blockchains EVM. Sa particularité réside toutefois dans l’intégration d’opérations hors chaîne, comme l’envoi de transactions vers des nœuds d’autres blockchains. Les résultats de ces opérations hors chaîne, ou les conditions d’utilisation, peuvent être enregistrés sur la chaîne SUAVE, avec une garantie de consensus. Cela assure la cohérence entre les calculs hors chaîne et l’état sur chaîne. Par exemple, un développeur peut écrire un contrat intelligent qui enregistre certaines conditions (modifiables) sur chaîne, et transfère un actif ERC20 prédéfini dès lors que le résultat obtenu après interrogation d’un nœud de blockchain satisfait ces conditions.
Toutes ces fonctionnalités découlent du calcul fiable hors chaîne permis par SUAVE. Sachant que SUAVE est développé par l’équipe Flashbots, et considéré par celle-ci comme « The Future of MEV », la gestion des transactions par lots (bundles) est bien sûr intégrée. Le principe MEV sur la chaîne SUAVE, reposant sur un environnement de confiance, est très simple : assembler un bundle de transactions et l’envoyer aux nœuds relais de Flashbots. Les clés privées, voire même le code, peuvent être stockés de manière confidentielle, ouvrant ainsi un potentiel d’utilisation immense. Par exemple, un builder pourrait percevoir non seulement la récompense en frais de gaz sur la chaîne cible, mais aussi recevoir certains actifs numériques sur la chaîne SUAVE. Pour le marché MEV, la possibilité de définir librement des logiques métiers sous garantie de confidentialité représente un progrès majeur par rapport à l’actuel (qui repose uniquement sur la confiance, les contrats ou la réputation hors chaîne).
Outils de développement et infrastructure de SUAVE
Pour les développeurs, le développement d’un dApp inclut non seulement les contrats intelligents, mais aussi des outils front-end comme ether.js. Dans le cas de SUAVE, étant donné que la chaîne est une version modifiée de l’EVM, les bibliothèques classiques telles qu’ether.js ou web3.js restent utilisables. Elles interagissent avec les contrats SUAVE exactement comme avec tout autre contrat EVM, mais uniquement pour les fonctions ne nécessitant pas l’environnement confidentiel. Un contrat SUAVE distingue deux types d’opérations : celles sur chaîne (c’est-à-dire sur SUAVE) et celles hors chaîne (y compris les interactions inter-chaînes), ces dernières correspondant en réalité à des calculs confidentiels. Pour ces calculs confidentiels, l’équipe Flashbots propose des SDK dans deux langages (Go et TypeScript), dont l’utilisation est documentée dans la documentation SUAVE. Lorsqu’on envoie à un nœud SUAVE une transaction impliquant un calcul confidentiel (appelée par Flashbots « Confidential Compute Request »), on peut y inclure des confidentialInputs, c’est-à-dire des paramètres privés. Tout au long de leur transmission, ces paramètres ne seront déchiffrés qu’au sein de l’environnement TEE.
Enfin, concernant le déploiement des contrats intelligents, le réseau de test de SUAVE s’appelait initialement Regil, mais a été mis à jour sous le nom de Toliman. La méthode de déploiement est détaillée dans la documentation SUAVE. En pratique, le processus de déploiement ainsi que les interactions post-déploiement ne diffèrent guère de ceux utilisés sur Ethereum.
Kettle
Après le déploiement d’un contrat intelligent, son mode d’exécution réel diffère de celui d’Ethereum. L’unité principale d’exécution dans SUAVE s’appelle Kettle. Kettle constitue l’environnement d’exécution TEE de SUAVE (comprenant un nœud MEVM et un magasin de données confidentielles). Une fois qu’un développeur a écrit et déployé un contrat, lorsque l’utilisateur envoie une « confidential compute request » (CCR), toute opération nécessitant un calcul confidentiel est en réalité exécutée par Kettle.
La structure de Kettle est illustrée ci-dessous :
On observe que les applications développées en Solidity par les développeurs, après déploiement, aboutissent finalement à Kettle, où elles sont traitées par le MEVM. Ce dernier intègre non seulement les fonctionnalités de geth, mais aussi des précompilés supplémentaires permettant de stocker et récupérer des données confidentielles, ainsi que de gérer (modifier, consulter) l’état sur la chaîne SUAVE.
La principale mission de Kettle est de recevoir et traiter les calculs confidentiels, ainsi que de gérer le stockage et la récupération des données privées. Prenons l’exemple du stockage d’une donnée sensible : le frontend utilisateur utilise un SDK ou l’outil suave geth pour envoyer une requête CCR à un contrat intelligent sur la chaîne SUAVE. Le SDK ou suave geth chiffre alors la donnée sensible à l’aide d’une clé de données (clé symétrique), qui n’apparaîtra jamais en clair en dehors de l’environnement TEE de Kettle. Le nœud RPC de SUAVE ne verra que le texte chiffré. Quant à savoir si chaque Kettle est associé à un seul nœud, ou aux détails précis du mécanisme d’échange de clés, la documentation SUAVE ne fournit pas d’information claire. Néanmoins, d’après le processus de chiffrement connu, les développeurs peuvent raisonnablement supposer que la protection des données confidentielles est assurée durant tout le trajet entre le frontend utilisateur et l’environnement TEE interne de Kettle.
Les données confidentielles sont conservées par Kettle dans un « confidential data store ». Lors du développement du contrat, le développeur spécifie les entités autorisées à accéder ou modifier ces données. Kettle diffuse ces permissions via son réseau de transport. Si l’accès est limité au contrat lui-même, alors les futures requêtes CCR devront être adressées au même Kettle, car le stockage des données dans Kettle n’est pas synchronisé globalement. Après déploiement du contrat, les utilisateurs peuvent accéder au Kettle approprié (la requête CCR inclut un paramètre indiquant l’adresse de Kettle). L’accès aux données confidentielles s’effectue alors via un identifiant et une clé associés au moment du stockage, signifiant que les données sont consultées et utilisées selon un système de clés-valeurs.
Les requêtes HTTP sont également traitées par Kettle. Clairement, ces opérations relèvent du hors chaîne, c’est-à-dire qu’elles sont exécutées sur un seul nœud. Bien que SUAVE soit une blockchain, son caractère décentralisé est ici affaibli : lorsqu’un Kettle traite une requête CCR, il n’y a pas de validation par plusieurs nœuds. La raison en est simple : l’accès à des ressources externes ne peut garantir une idempotence stricte. Ainsi, les résultats de ces opérations hors chaîne dépendent fortement du nœud exécutant Kettle. Les développeurs doivent donc prêter attention à l’adresse du Kettle lors du déploiement (en ce sens, Kettle peut être vu comme un contrat intelligent particulier), et veiller à ce que les requêtes CCR ultérieures incluent bien l’adresse correcte du Kettle.
Un autre point mérite l’attention des développeurs : sur le réseau de test actuel, Toliman, les Kettles ne sont pas garantis comme fonctionnant dans un environnement TEE. Il convient donc d’être prudent lors du développement sur le testnet, et d’éviter de manipuler de véritables données sensibles.
Conclusion
Grâce à l’introduction de l’environnement TEE, SUAVE offre aux développeurs des capacités extrêmement puissantes, ouvrant la voie à de nombreux cas d’usage potentiels. Ses opérations inter-chaînes simples et efficaces stimulent largement l’imagination dans la conception de dApps.
La conception de Kettle dans SUAVE permet de traiter des ressources externes, mais soulève des questions relatives à la validation et au consensus. Un Kettle malhonnête pourrait compromettre gravement le réseau. Comment garantir que Kettle ne commette pas de mauvaises actions ? Ou, s’il en commet, comment s’assurer qu’il soit sanctionné, ou que le coût de la malhonnêteté soit prohibitif ? Ce sont là des défis cruciaux à résoudre. Le consensus de SUAVE repose actuellement sur un modèle PoA (Proof of Authority). Sa robustesse face aux réalités pratiques reste à démontrer, et la communauté de développeurs observe attentivement son évolution.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@ChainFeedsxyz
