Analyse technique des inscriptions Ethereum ETHS : une spéculation financière plutôt qu'une innovation produit
TechFlow SélectionTechFlow Sélection
Analyse technique des inscriptions Ethereum ETHS : une spéculation financière plutôt qu'une innovation produit
Ethscriptions, profitant de la vague des inscriptions sur BTC, repackagent d'anciennes idées avec un nouveau concept spéculatif, sans toutefois avoir découvert un nouveau paradigme.
Dédié à des analyses Web3 approfondiesRédaction : Wu Yue, Geek Web3
Introduction : Actuellement, les inscriptions sur Ethereum restent essentiellement une réinvention des Ordinals, sans introduire un nouveau paradigme véritable. ETHS comporte toujours des risques de sécurité ; bien qu'il soit plus décentralisé que les Rollups, son processus de retrait dépend encore de tiers tels que des notaires ou administrateurs, ce qui expose à des risques de vol. Il est clair que, pour l'instant, ETHS repose principalement sur la spéculation financière plutôt que d'apporter une innovation que les solutions Layer 2 d'Ethereum ne peuvent offrir.
La récente popularité des inscriptions dans l'écosystème BTC a incité les développeurs d'autres blockchains à construire des systèmes similaires. Les implémentations et fonctionnalités varient légèrement selon les chaînes, mais présentent certaines similitudes :
-
Les inscriptions exploitent les données textuelles ajoutées lors d'une transaction pour exprimer une action souhaitée, par exemple en écrivant « transférer 1 jeton à XXX ». Ces informations sont purement textuelles et n'activent aucune exécution de contrat intelligent sur la blockchain.
-
Les développeurs définissent des normes et protocoles afin de standardiser ces messages textuels.
-
Un outil appelé Indexer est fourni pour collecter toutes ces données textuelles sur la chaîne et calculer l'état du système d'inscription. L’Indexer est un composant open source hors chaîne que toute personne peut exécuter.
Les Ordinals ont permis de créer un mécanisme d’émission de NFTs et de jetons sur BTC, suscitant ainsi un vaste débat sur les Layer 2 de Bitcoin. Sur ce plan, on peut reconnaître aux Ordinals une dimension exploratoire et avant-gardiste. Toutefois, ils sont techniquement limités par l’architecture même de BTC et critiqués par la communauté historique du réseau en raison notamment de la pollution par microtransactions (« dust ») et de l’encombrement du stockage.
Alors, reproduire le concept d’inscriptions sur Ethereum a-t-il un sens ? Après tout, Ethereum dispose déjà de contrats intelligents complexes, de standards ERC20 et NFT intégrés nativement. Quel impact ces projets d’inscriptions auront-ils sur l’écosystème Ethereum ? Verront-ils surgir les mêmes controverses que celles observées sur BTC ?
Méthode technique d’Ethscriptions
Examinons d’abord le fonctionnement d’Ethscriptions, un projet phare d’inscriptions sur Ethereum, qui repose principalement sur l’utilisation du calldata.
Le calldata correspond aux données brutes transmises dans une transaction Ethereum. Généralement utilisé pour passer des paramètres lors d’une interaction avec un contrat intelligent, il peut aussi servir à envoyer des messages texte vers une adresse EOA (messages personnels, gravures, remarques de transfert, etc.). La zone « Input Data » sur l’image ci-dessous représente le calldata.
Si vous souhaitez graver « Hello world » via Ethscriptions, vous devez construire une transaction contenant le calldata suivant :
Une fois cette transaction détectée par l’Indexer hors chaîne, la base de données est mise à jour et l’utilisateur informé : une nouvelle inscription est créée, portant le message « Hello world ». Des contenus plus complexes peuvent également être inclus, comme des images encodées en base64.
Actuellement, Ethscriptions s’appuie sur six ESIP (Propositions d’amélioration du protocole Ethscriptions), semblables aux EIP, pour définir l'utilisation des inscriptions dans différents scénarios. Toutefois, ces propositions restent assez basiques, couvrant par exemple le format des transactions initiées depuis une adresse EOA ou les événements émis par des contrats.
Étant donné qu’Ethscriptions fonctionne sur Ethereum, il peut tirer parti des contrats intelligents pour implémenter certaines logiques. Cependant, interagir directement avec un contrat n’est pas une pratique recommandée par le protocole.
Bien que les marchés officiels de NFT utilisent eux-mêmes des contrats intelligents, selon la documentation, Ethscriptions vise à offrir un « service de calcul décentralisé et abordable » : en déplaçant le calcul hors chaîne, les coûts d’utilisation d’Ethereum sont significativement réduits.
Analysons précisément le coût d’un appel de contrat, qui se compose de trois éléments :
-
Coût de base de transaction : requis pour toute transaction Ethereum, actuellement fixé à 21 000 gas.
-
Coût de transmission des données (calldata) : chaque octet non nul consomme généralement 16 gas (4 gas si l’octet est nul), suite à l’adoption de l’EIP-2028.
-
Coût d’exécution du contrat : si la transaction appelle une fonction de contrat, des frais supplémentaires sont engendrés selon la complexité de l’opération. Par exemple, une mise à jour d’état (comme celle du solde dans un contrat ERC-20) utilisant SSTORE peut coûter entre 5 000 et 20 000 gas.
Prenons l'exemple d’un simple transfert USDT, ayant consommé 63 197 gas au total, dont voici le calldata :
Analysons ce calldata et son coût associé :
-
Le calldata est en hexadécimal : chaque paire de chiffres représente un octet (16² = 2⁸). Le préfixe 0x indique le format hexadécimal.
-
a9059cbbaprès le 0x est le sélecteur de fonction, occupant 4 octets non nuls. -
Les 32 octets suivants représentent l’adresse, dont 12 octets sont nuls (remplissage à gauche car les adresses Ethereum font 20 octets, étendues à 32), puis 20 octets non nuls.
-
Les 32 derniers octets représentent le montant, majoritairement remplis de zéros, avec
3b9aca00à la fin, soit 4 octets non nuls. -
Au total : 28 octets non nuls, 40 octets nuls.
Ainsi, coût_calldata = 28 × 16 + 40 × 4 = 608 gas.
Le coût total étant de 63 197 gas, en soustrayant le coût du calldata et le coût fixe, le coût de calcul du contrat intelligent s’élève à 41 589 gas. Dans cette transaction, le calcul représente la majeure partie du coût, et cela pour une opération simple — les coûts augmenteraient encore pour des transactions plus complexes.
Déplacer le calcul hors chaîne permet effectivement de réduire drastiquement les coûts : au lieu d’appeler directement un contrat, on peut envoyer une transaction de données vers une adresse EOA prédéfinie
0x00000000000000000000000000000000000face7
en incluant dans le calldata l’identité du contrat à appeler ainsi que les paramètres d’entrée. Comme cette adresse est une EOA sans code, aucune opération de calcul n’est déclenchée sur la chaîne. Il s’agit simplement de publier un message.
Hors chaîne, l’Indexer détecte ce message, l’analyse, identifie quel contrat Ethereum devait être appelé, puis effectue le calcul hors chaîne du résultat attendu.
Pour réaliser ces calculs hors chaîne liés aux inscriptions et contrats, l’Indexer doit disposer d’une règle de transformation d’état (STF) et d’un environnement d’exécution, voire d’une machine virtuelle (VM). Ethscriptions a introduit sa propre VM dans l’ESIP-4, initialement nommée Ethscriptions VM, puis renommée Facet VM.
Facet — un peu comme un coprocesseur
Facet se définit comme une plateforme de calcul bon marché, fiable et décentralisée. Il surveille le calldata d’Ethscriptions sur Ethereum, le récupère dans sa VM pour y effectuer des calculs, puis retourne les résultats aux utilisateurs. Facet comprend plusieurs composants clés :
-
Facet VM : une machine virtuelle écrite en Ruby, chargée de surveiller les transactions ETHS, analyser le calldata et exécuter les opérations.
-
Rubidity : langage de programmation de contrats pour Facet, inspiré de Ruby tout en conservant de nombreux concepts et syntaxes de Solidity, afin de faciliter l’adoption par les développeurs.
-
Dumb Contract (contrat stupide) : contrats exécutés sur Facet. Ce nom humoristique joue sur le mot « dumb », signifiant à la fois « muet » (parce qu’ils s’exécutent silencieusement) et « stupide ». D’après le slogan officiel « So dumb, they're smart » (si bêtes qu’ils sont intelligents), on perçoit une provocation envers les « smart contracts », d’où la traduction « contrat stupide » convient parfaitement.
Les contrats stupides ne sont pas réellement déployés sur Ethereum ; leur code est seulement publié sous forme de calldata sur la chaîne. Voici un exemple de frappe d’un contrat stupide via Facet :
Une transaction de frappe envoyée à l’adresse EOA vide (« trou noir »)
0x00000000000000000000000000000000000face7
avec le calldata ci-dessous, indiquant simplement le jeton et la quantité à frapper. Cela ressemble exactement aux Ordinals ou BRC-20 :
Voici maintenant une comparaison visuelle entre Rubidity et Solidity.
Bien que l’équipe affirme que Rubidity reprend des concepts proches de Solidity pour faciliter l’adoption, cela peut en réalité freiner le développement par les développeurs. De plus, la VM Facet ne prend actuellement en charge que les contrats stupides figurant sur une liste blanche officielle, ce qui montre un manque de confiance dans le langage et la VM. On ignore si le choix d’un nouveau langage et d’une nouvelle VM est techniquement plus simple que de réutiliser l’EVM, mais une chose est sûre : un langage, un contrat, un écosystème et une nouvelle manière d’utiliser Ethereum constituent un argument marketing puissant.
La critique de Facet envers les contrats intelligents
Dans ses documents, Facet lance une déclaration explosive : « Les contrats intelligents sont considérés comme la fonctionnalité qui rend Ethereum unique, or la thèse de Facet est que les contrats intelligents sont la plus grande erreur de conception d’Ethereum. »
Selon eux, les contrats intelligents sont un défaut de conception car leurs sorties sont entièrement déterministes à partir des entrées (calldata), donc inutile de les exécuter sur chaîne, ce qui gaspille de l’argent. En lien avec la promesse d’Ethscriptions d’offrir un « service de calcul décentralisé et abordable », le but clair d’Ethscriptions et Facet est de donner l’impression qu’ils inventent un nouveau paradigme de scalabilité et d’utilisation d’Ethereum, alors que leurs propres solutions techniques sont peu fiables.
Du point de vue produit, Facet permet effectivement d’appeler indirectement des contrats hors chaîne et possède son propre système de contrats stupides, ce qui suit bien sa philosophie.
Mais économiquement parlant, il n’y a pas de repas gratuit : le stockage et le calcul coûtent forcément quelque chose. Alors, comment l’Indexer couvre-t-il ces coûts ? Là-dessus, l’équipe reste floue. Imaginons quelques possibilités :
-
Facturation aux utilisateurs, par exemple via des frais prélevés sur un marché NFT. Mais on ne peut pas assimiler le modèle économique d’un projet simple à celui d’un réseau de type L2 à long terme.
-
Richesse générée par la spéculation autour de l’écosystème. Possible à court terme, mais insuffisant pour assurer la pérennité du projet. Si Ethscriptions veut devenir un nouveau paradigme, l’Indexer doit reposer sur un mécanisme économique durable issu du réseau lui-même.
-
Si c’est un bien public non lucratif, qui va le financer ? L’Ethereum Foundation ne sera probablement pas très motivée, car Ethereum dispose déjà de très bonnes solutions — comme les Rollups.
Raisons fondamentales de l’émergence de Facet et des contrats stupides
Si nous voulons seulement une version simple des inscriptions Ethereum, un seul projet comme Ethscriptions suffirait. Pourquoi alors l’ESIP-4 a-t-il conduit à la création de Facet ?
Parce que le système d’inscriptions ne permet pas de gérer des logiques complexes. Prenons le fonctionnement du marché NFT officiel d’Ethscriptions, qui utilise un système de listing (ordre de vente).
Pour déposer un NFT d’inscription dans le contrat, il suffit d’inclure l’EthscriptionId dans le calldata et d’appeler le contrat du marché. Cette opération utilise intentionnellement un appel de fonction invalide, ce qui déclenche automatiquement le fallback().
Un événement nommé PotentialEthscriptionDeposited est alors émis sur Ethereum. L’Indexer, en surveillant cet événement hors chaîne, met à jour localement la propriété du NFT en faveur du contrat du marché.
Pour économiser du gas, le marché ETHS ne stocke pas sur chaîne certains paramètres du vendeur (prix, date limite, etc.), mais les conserve hors chaîne, probablement sur les serveurs de l’application. L’acheteur, en surveillant ces messages, peut ensuite envoyer une commande buyWithSignature() pour acheter.
Ce système de listing est normal pour les NFT, qui sont par nature non fongibles. Mais peut-on utiliser un mécanisme AMM pour des jetons fongibles gravés ? La réponse est non. Ni les NFT ni les jetons gravés n’ont leur état sur L1, comme c’est le cas pour Ordinals ou BRC-20. Cela contredit certaines affirmations communautaires : attention, les inscriptions ne sont pas des actifs natifs de la chaîne Ethereum. Le simple fait que le calldata de création d’un actif soit sur L1, et qu’on puisse y déclarer des actions, ne suffit pas à en faire un actif natif L1. Sinon, on pourrait dire que les actifs natifs L2 des Rollups sont des actifs L1, puisque leur calldata est aussi sur L1. Appeler ces actifs des actifs natifs L1 est manifestement absurde.
Vous vous demandez peut-être : n’a-t-on pas utilisé un contrat intelligent pour acheter et vendre ? Comment dire alors que les contrats ne peuvent pas lire ou manipuler les inscriptions ? En réalité, ce contrat ne fait que recevoir et transférer de l’argent, et émettre un événement que l’Indexer surveille pour déclencher une action. Aux yeux de l’EVM d’Ethereum, l’état des inscriptions ne peut pas être reconstitué dans la « world state », la base de données d’état spécialisée de la chaîne, donc les contrats ne peuvent pas y faire référence.
Quelle que soit la forme de l’actif — jeton, NFT ou autre — voici un critère simple pour distinguer actifs L1 et L2 : l’état de l’actif peut-il être reconstitué dans la « world state » d’Ethereum ? L’EVM L1 peut-il référencer, appeler, consulter ou modifier cet état ? S’il ne le peut pas, ce n’est pas un actif L1.
C’est pourquoi l’événement de dépôt s’appelle PotentialEthscriptionDeposit (« dépôt potentiel d’inscription »), pas un dépôt certain : le contrat ne peut pas vérifier si l’inscription existe ou est valide. Si vous listez une inscription inexistante ou appartenant à autrui, le contrat n’y objectera pas — seul l’Indexer ignorera votre action.
Le système d’inscriptions ne peut donc implémenter que des logiques contractuelles simplifiées, comme le listing. Le listing repose sur l’accord mutuel des deux parties selon une règle donnée. On pourrait l’exprimer en texte brut sans contrat intelligent — tout comme le principe des inscriptions.
Imaginons comment faire sans contrat : le vendeur grave un message dans une transaction ordinaire : « Celui qui m’envoie 1 ETH avec le message ABC obtient mon NFT numéro 123 ». Dès lors, si l’Indexer supporte cette logique, en voyant un transfert de 1 ETH accompagné du message ABC, il met à jour sa base de données hors chaîne.
Bien sûr, ce scénario pose des problèmes, comme plusieurs acheteurs tentant d’acheter le même NFT, conduisant à des doublons. Le vendeur pourrait recevoir plusieurs paiements, mais l’Indexer ne créditera le NFT qu’à une seule personne. C’est probablement l’une des raisons pour lesquelles l’équipe utilise un contrat malgré ses critiques — d’où l’on comprend que l’affirmation selon laquelle Facet appelle des contrats sans calcul est une宣传 peu crédible.
Certes, le listing pourrait théoriquement fonctionner en texte brut, mais un AMM, logique plus complexe, nécessite un contrat intelligent, car il exige une validation contractuelle, pas un simple accord p2p. Le contrat, en tant que vérificateur fiable, doit contrôler les soldes, la liquidité, etc., et effectuer des calculs — il doit donc pouvoir accéder aux données des actifs.
Or, l’AMM est une forme relativement simple de DeFi. Aucune logique complexe ne peut être réalisée uniquement avec Ethscriptions. C’est pourquoi Facet a été créé : sa priorité absolue est l’inter-opérabilité ! Facet est en réalité un L2, même sans structure de blocs — on parle donc de « cross-domain » plutôt que de « cross-chain ». Une fois que tous les actifs L1 sont transférés vers Facet, le problème d’appel impossible est résolu : on peut manipuler tous les actifs hors chaîne via des contrats stupides, permettant des logiques complexes.
Comparaison avec les Rollups
À travers cette longue analyse, on voit que la solution d’Ethscriptions ressemble un peu aux Rollups. Mais ce n’est qu’une « ressemblance » : strictement parlant, elle ne réalise qu’un sous-ensemble des fonctions centrales d’un Rollup. Ces lacunes nuisent gravement à sa crédibilité et exposent les utilisateurs à de sérieux dangers.
Les Rollups forment un système complexe, que nous n’approfondirons pas ici. Points communs avec Ethscriptions :
-
Tous deux soumettent sur Ethereum les données calldata des transactions L2.
-
Tous deux déplacent le calcul hors chaîne.
Ces points communs sont clairs. Examinons maintenant les différences.
Soumission groupée du calldata dans les Rollups
Dans un Rollup, les utilisateurs envoient rarement directement leurs transactions à L1. Ils les soumettent à un séquenceur hors chaîne, qui les trie, regroupe et compresse avant de les envoyer en lot à L1. Ainsi, plusieurs calldata sont regroupés dans une seule transaction, répartissant le coût fixe de 21 000 gas.
Dans Ethscriptions, aucun tel mécanisme n’existe : chaque utilisateur soumet directement son calldata à L1.
Reprenons l’exemple du transfert USDT (608 gas de calldata). Supposons 100 utilisateurs effectuant 100 transactions. Un calcul grossier donne :
-
Chaque utilisateur d’Ethscriptions paie 21 608 gas (608 + 21 000). Pas de frais de calcul, car hors chaîne.
-
Chaque utilisateur de Rollup paie 818 gas ((608×100 + 21 000)/100). Coût de calcul identique.
Bien sûr, les utilisateurs de Rollup doivent aussi payer des frais de calcul et de stockage au séquenceur, mais ceux-ci sont négligeables face à L1. De plus, les Rollups utilisent une compression efficace, contrebalançant l’ajout de champs spéciaux — nous n’entrerons pas dans ces détails.
Ce calcul approximatif montre qu’Ethscriptions n’a aucun avantage en coût face aux Layer 2. D’ailleurs, certains membres de la communauté affirment que « 4000 inscriptions peuvent être transférées en masse pour environ 0,11 ETH, soit 0,05 U par transfert », prouvant la faible coût d’Ethscriptions — mais cela montre surtout qu’ils ne comprennent pas le fonctionnement réel d’ETHS.
Pré-confirmation hors chaîne
Grâce au séquenceur hors chaîne, les utilisateurs de Rollup obtiennent une pré-confirmation en moins d’une seconde, bien meilleure que les 12 secondes ou plus sur L1 pour les inscriptions. Certes, les partisans des inscriptions peuvent rétorquer que l’irrévocabilité finale n’est garantie qu’après écriture sur chaîne.
Résistance à la censure et décentralisation
Les utilisateurs d’un Rollup peuvent être censurés par le séquenceur hors chaîne, contrairement aux utilisateurs d’Ethscriptions. Mais un bon Rollup intègre une fonction de dépôt forcé pour contrer la censure, privant progressivement le séquenceur de ce pouvoir.
Ainsi, l’utilisateur peut contourner le séquenceur en passant directement par L1. Le Rollup offre un choix : rapidité via le séquenceur ou sécurité directe via L1. Ethscriptions, lui, impose l’usage exclusif de L1, sans alternative.
De plus, Ethscriptions critique la centralisation du séquenceur des Rollups. Pourtant, l’Indexer est lui aussi hautement centralisé. Ethscriptions explique que l’Indexer n’est pas centralisé car tout le monde peut l’exécuter et le vérifier, mais en réalité, presque personne ne le fait. ETHS n’apparaît donc plus décentralisé que les Rollups qu’en cas extrême : si le séquenceur tombe en panne, les Rollups peuvent continuer, tandis qu’ETHS peut survivre tant que plusieurs membres de la communauté exécutent des Indexers.
Modèle économique
Aucun projet ne peut vivre d’amour et d’eau fraîche. Pour perdurer, il doit envisager sérieusement son modèle économique, qu’il soit centralisé ou décentralisé, afin d’assurer durablement la sécurité du réseau.
Le séquenceur d’un Rollup a un modèle clair : frais supplémentaires de gas, capture de MEV, etc. Il a donc intérêt à maintenir le réseau opérationnel. Dans Ethscriptions, les utilisateurs envoient directement leurs calldata à L1, rendant difficile la facturation pour l’Indexer.
Convivialité pour les développeurs
La plupart des Rollups réutilisent directement les langages, outils et chaînes de développement d’Ethereum, permettant une migration fluide. Dans Ethscriptions, rien de tel : il faut apprendre Rubidity, construire un nouvel explorateur, maîtriser une nouvelle VM, etc. Bien sûr, ces obstacles peuvent aussi représenter des opportunités pour les pionniers d’un nouvel écosystème.
Retraits et règlement d’état
Voici le point faible fatal de Facet. On sait que les Rollups ne se contentent pas de soumettre le calldata (entrée) à L1 : ils soumettent périodiquement l’état résultant (sortie) après N opérations. ZKR et OPR utilisent différentes méthodes de preuve pour valider la relation entre entrée et sortie. Quelle que soit la méthode, le juge final est un contrat sur L1. Sur un Rollup, entrée et sortie sont traçables et inviolables.
À quoi sert le règlement d’état ? Aux retraits, c’est-à-dire au transfert de fonds de L2 vers L1. Une fois l’état publié sur L1, on peut utiliser une preuve de Merkle pour démontrer qu’une demande de retrait est incluse dans la racine d’état. Après vérification par le contrat, les actifs sont libérés sur L1.
Facet n’a pas de mécanisme de règlement d’état, donc il ne peut pas permettre de retraits sans permission, décentralisés, de L2 vers L1. Or, comme mentionné, il a besoin d’un niveau L2 pour exécuter des logiques complexes, comme son DEX FacetSwap.
On voit clairement sur FacetSwap (un DEX construit avec des contrats stupides) deux actions : déposer et retirer. Normalement, un swap n’a pas de dépôt/retrait, mais ici, il faut d’abord franchir le domaine.
Sur Facet, le dépôt consiste à verrouiller des fonds L1 dans un contrat pont, qui émet un événement ethscriptions_protocol_CreateEthscription pour que l’Indexer l’indexe. Identique aux méthodes de dépôt des autres L2.
Mais le retrait pose un grave problème de sécurité. Faute de mécanisme de règlement d’état, aucun contrat sur L1 ne peut automatiquement vérifier la validité d’un retrait. Alors, quelle méthode Facet utilise-t-il ? L’autorisation par un administrateur, ou « mécanisme de témoin », similaire au pont Axie précédemment piraté.
Regardons directement le contrat pont de Facet, à l’adresse
0xD729345aA12c5Af2121D96f87B673987f354496B.
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
@godrealmx
