Résoudre le problème du gaz de Bitcoin (sans fork) | Opinion

Chaque plateforme de contrats intelligents intègre une asset de frais. Par exemple, Ethereum (ETH) a ETH, Solana (SOL) a SOL, mais avec Bitcoin (BTC), les choses deviennent compliquées. Si vous souhaitez des applications expressives, vous devez généralement adopter l’économie d’un second réseau.

Résumé

• Bitcoin ne valorise pas la computation, seulement l’espace de bloc. Contrairement à Ethereum ou Solana, le marché des frais de BTC est basé sur sat/vB pour l’inclusion des transactions, et non sur la mesure de l’exécution des contrats intelligents.
• L’exécution peut se faire hors chaîne tandis que le règlement reste sur Bitcoin. Des systèmes comme OpNet exécutent la logique des contrats dans une VM Wasm tout en ancrant les paiements et les changements d’état final via des transactions BTC classiques.
• BTC peut fonctionner comme l’actif de gas sans créer un nouveau jeton. En valorisant les coûts d’exécution en satoshis et en réglant les interactions via des transactions Bitcoin, les applications évitent de créer une seconde économie de frais.

Sur Stacks, par exemple, vous payez en STX. Sur les couches Bitcoin de style EVM, on vous dira que BTC est le jeton de gas, mais il s’agit généralement d’une représentation native de Layer 2 avec des conventions similaires à EVM (y compris 18 décimales), et vous opérez toujours dans cet environnement Layer 2. Bitcoin lui-même dispose déjà d’un marché de frais clair, où les utilisateurs enchérissent pour l’espace de bloc en sat/vB, et les mineurs privilégient les taux de frais plus élevés.

Avec cela en tête, que se passerait-il si une interaction de contrat intelligent pouvait être initiée et payée comme une transaction Bitcoin normale, avec des frais en BTC (sans jeton de gas supplémentaire ou fork), tandis que la partie intelligente s’exécute ailleurs et reste prouvablement liée à Bitcoin ? OpNet cherche à apporter une réponse.

Bitcoin ne mesure pas la computation (c’est un problème)

Le marché des frais de Bitcoin est excellent pour une chose : valoriser l’espace de bloc. Vous concourez en sat/vB, les mineurs choisissent les taux de frais les plus élevés, et le réseau reste simple et robuste face aux attaques. Ce que Bitcoin ne fait pas, c’est exécuter un environnement d’exécution à usage général où la chaîne peut mesurer et facturer toute computation arbitraire. Bitcoin Script est délibérément sans état et non Turing-complet, notamment en l’absence de boucles ou de goto, afin que chaque nœud puisse valider les scripts de manière prévisible sans ouvrir la porte à une computation illimitée.

C’est pourquoi la plupart des approches de contrats intelligents sur Bitcoin finissent par placer l’exécution sur un système séparé capable de mesurer la computation et de gérer sa propre économie de frais. Une fois cette couche d’exécution séparée en place, elle s’accompagne généralement d’un actif de frais distinct (par exemple, Stacks facture en STX).

Ce n’est pas idéal, et un système où vous pourriez maintenir le paiement dans le marché de frais natif de Bitcoin tout en déplaçant l’exécution ailleurs serait préférable.

L’exécution n’est pas ce que Bitcoin doit faire

Une fois que vous acceptez que Bitcoin Script est volontairement limité (sans état et non conçu pour une computation illimitée), vous commencez à réfléchir à comment faire régler les résultats et les paiements par Bitcoin.

En effet, l’exécution peut se faire dans une machine virtuelle dédiée conçue pour exécuter la logique des contrats intelligents de manière déterministe, tandis que Bitcoin reste la couche de base qui horodate, ordonne et valorise les interactions via son marché de frais existant. Dans la conception d’OpNet, la logique des contrats est évaluée par une VM orientée Wasm (OP-VM), tandis que la pile de nœuds plus large est explicitement conçue pour gérer et exécuter des contrats intelligents en utilisant les mécanismes de transactions et UTXO de Bitcoin.

Ce qui est crucial, c’est que cela ne soit pas associé à un nouvel actif de frais. Bitcoin n’a pas besoin de mesurer la computation pour être la monnaie de gas. Il doit simplement être la couche de règlement final vers laquelle tout converge et qui sert d’ancrage.

À quoi ressemble un appel de contrat payé en BTC

Notre modèle d’interaction suit un flux de simulation puis de dépense plutôt qu’un schéma classique d’exécution de contrat intelligent, avec l’étape finale d’exécution sous forme d’une transaction Bitcoin réelle. D’abord, votre application appelle une méthode de contrat en mode simulation. Cette requête passe par un fournisseur vers un nœud OPNet, qui exécute le contrat dans sa VM et retourne un CallResult (incluant des estimations de gas/frais) sans diffuser quoi que ce soit sur Bitcoin.

Si l’appel modifie l’état, vous utilisez ce CallResult pour effectuer une exécution. À ce stade, la bibliothèque construit une transaction Bitcoin, la signe, et la diffuse sur le réseau Bitcoin. Deux points importants :

• Les frais de mineurs sont natifs à Bitcoin. Vous choisissez un taux de frais en sat/vB, ajoutez éventuellement un feePrioritaire en sats, et fixez un plafond de dépenses en frais via maximumAllowedSatToSpend (le paramètre porte littéralement ce nom).
• La cible du contrat est exprimée sous forme d’adresse de contrat P2OP. L’instance du contrat expose son format d’adresse p2op, et les transactions font référence à une “adresse de contrat p2op” comme destination du contrat.

Par ailleurs, la mesure de computation propre à OpNet existe toujours. Mais elle est évaluée en satoshis (SATS Gas estimés, remboursements en SATS, etc.), de sorte que l’unité ne dérive jamais vers une économie de jetons séparée.

Moins de friction, des incitations plus claires

Les utilisateurs n’ont plus besoin d’adopter une seconde économie de frais pour interagir avec les applications. Sur Bitcoin, les frais sont déjà une enchère pour l’espace de bloc, tarifés par octet et payés aux mineurs. Quand les appels de contrat ne sont que des transactions Bitcoin, vous retrouvez un terrain familier (avec des frais en sat/vB, la gestion du mempool, et des incitations des mineurs), sans avoir à apprendre un marché de jetons de gas séparé.

De plus, les outils s’appuient sur des workflows Bitcoin standards tels que la gestion des UTXO, la connexion aux fournisseurs, et même la signature hors ligne ou en mode froid. Les contrats vivent dans un runtime Wasm et sont écrits en AssemblyScript, visant une expressivité proche de Solidity sans faire croire que Bitcoin Script est soudain devenu une VM.

Bitcoin comme gas, sans second jeton

L’affirmation selon laquelle BTC ne peut pas faire office de gas repose généralement sur l’hypothèse que la couche de base doit mesurer la computation pour la valoriser. Bitcoin ne mesure pas la computation ; il mesure l’espace de bloc et règle la valeur.

La solution consiste à laisser une machine virtuelle gérer l’exécution de manière déterministe, puis à faire passer chaque interaction modifiant l’état par une transaction Bitcoin standard, où les frais sont exprimés en termes familiers comme sat/vB et plafonnés en satoshis. Dans notre cas, cela est implémenté au niveau du client via des paramètres comme feeRate et maximumAllowedSatToSpend.

Ainsi, peut-être que BTC comme gas est réellement envisageable. Les frais restent natifs à BTC du début à la fin, tandis que l’environnement d’exécution des contrats reste basé sur WebAssembly (AssemblyScript → Wasm), conservant une logique expressive sans changer la devise des frais.

Frederic Fosco

Frederic Fosco, aussi connu sous le nom de Danny Plainview, est co-fondateur d’OP_NET et impliqué dans Bitcoin depuis 2013. Il a lancé OP_NET pour rendre Bitcoin nativement programmable, déverrouillant contrats intelligents et primitives DeFi directement sur la couche 1. Son objectif est de construire une véritable fonctionnalité en chaîne sans ponts, custodians, wrapping ou Bitcoin synthétique, en maintenant la garde autonome et la décentralisation comme priorités.