En tant que principe de conception fondamental du Bitcoin, le modèle UTXO constitue un paradigme technique important dans le domaine de la blockchain depuis sa création. Il joue un rôle crucial en garantissant la sécurité et la traçabilité des transactions, en proposant une solution alternative au modèle traditionnel de solde des comptes. Avec l'évolution et l'expansion continues de la technologie blockchain ces dernières années, le modèle UTXO lui-même n'a cessé d'évoluer et de s'étendre, comme eUxo, Cell, Strict Access List, etc.

Cet article présente le modèle UTXO en langage clair et donne un bref aperçu du modèle UTXO et des méthodes de mise en œuvre de BTC, Sui, Cardano, Nervos et Fuel.

Qu'est-ce que UTXO ?

Pour illustrer le modèle UTXO, nous utilisons un exemple :

Imaginez deux personnes, Alice et Bob, qui avaient chacun 5 dollars au départ. Par la suite, un conflit a éclaté et Bob a volé 2 dollars à Alice. Le patrimoine final de chacun est le suivant :

Il est évident qu'Alice finit avec 3 dollars et Bob avec 7 dollars. Cette méthode comptable élémentaire de type arithmétique est couramment utilisée dans les systèmes bancaires et est appelée « modèle compte/solde ». Dans ce modèle, le solde d'un compte existe sous la forme d'une valeur numérique unique.

Si nous devions adopter une approche différente du modèle de compte, par exemple en utilisant UTXO pour représenter le transfert de patrimoine entre Alice et Bob, le schéma illustratif prendrait une autre apparence :

À ce stade, Alice a encore 3 dollars et Bob 7 dollars, mais ces 7 dollars ne sont pas représentés par une seule valeur numérique. Ils sont plutôt divisés en « 5 dollars » et « 2 dollars ». Cette approche peu conventionnelle vous semble quelque peu familière ? Il s'agit de la méthode comptable unique connue sous le nom d'UTXO.

L'acronyme anglais UTXO signifie Unspent Transaction Output. Selon cette approche comptable, chaque transaction en chaîne se manifeste par des modifications et des transferts dans UtxOS. Par exemple, lors de l'événement de transaction mentionné, « 5 dollars » appartenant initialement à Alice servent de paramètres d'entrée, étiquetés UTXO_0, qui seront marqués comme dépensés ; simultanément, le système génère « 2 dollars » (UTXO_1) et « 3 dollars » (UTXO_2) comme paramètres de sortie. UTXO_1 sera transféré à Bob et UTXO_2 sera rendu à Alice, clôturant ainsi le transfert de patrimoine entre Alice et Bob.

Dans le modèle UTXO, il n'existe aucun concept explicite de « comptes » et de « soldes ». UTXO sert de structure de données qui facilite l'exécution des transactions, en enregistrant des informations telles que le montant qu'il représente et l'indice des transactions associé. Chaque UTXO représente une transaction non dépensée, avec un propriétaire désigné. Lorsqu'une transaction a lieu, certains UTXO peuvent être utilisés comme entrées, et lors de leur destruction, de nouveaux UTXO sont générés en tant que sorties de transaction.

C'est ainsi que Bitcoin tient ses comptes : à chaque transaction, les anciens UTXO sont détruits et de nouveaux sont créés. Le nombre total d'UTXO détruits est égal au nombre d'UTXO récemment créés (une partie étant réservée aux frais de transaction aux mineurs). Cela garantit que les fonds ne peuvent pas être augmentés arbitrairement.

Comparaison entre le modèle UTXO et le modèle de compte/solde

Supposons qu'un groupe d'utilisateurs lance un grand nombre de demandes de transaction simultanément. Comment la situation serait-elle gérée en utilisant le modèle UTXO par rapport au modèle compte/solde ?

Dans le modèle compte/solde, chaque utilisateur possède un compte avec des informations de solde enregistrées. Lorsqu'une transaction est effectuée, le solde du compte correspondant doit être mis à jour, ce qui implique à la fois des opérations de « lecture » et d' « écriture ». Cependant, si deux transactions concernent le même compte, cela entraîne souvent des conflits de lecture-écriture, ce qui entraîne des conflits entre États, une situation à éviter.

Les systèmes de base de données traditionnels résolvent généralement les conflits entre lecture et écriture grâce à un mécanisme de « verrouillage ». Dans un tel scénario, les transactions litigieuses pour les mêmes données doivent souvent être mises en file d'attente, ce qui empêche leur exécution simultanée et réduit l'efficacité du traitement des transactions. Lorsqu'un grand nombre de transactions sont en attente de traitement, cela peut entraîner d'importants goulots d'étranglement en termes de performances, les transactions en litige étant confrontées à des délais d'attente prolongés sans traitement rapide.

Contrairement au modèle de solde des comptes, le modèle UTXO de Bitcoin est mieux adapté pour gérer les problèmes de contention de données. Dans cette approche, l'entité de traitement direct de chaque transaction n'est plus un « compte » spécifique mais plutôt un UTXOS individuel et indépendant. Comme les différents UTXO n'interfèrent pas les uns avec les autres, chaque transaction sur le réseau Bitcoin fonctionne indépendamment. Par conséquent, les nœuds du réseau Bitcoin peuvent traiter plusieurs transactions simultanément sans avoir besoin de « verrous », ce qui améliore considérablement le débit du système et les performances de simultanéité.

De plus, dans le modèle UTXO, les portefeuilles cryptés génèrent généralement une nouvelle adresse pour l'utilisateur après avoir initié une transaction. Cette approche améliore la confidentialité, en rendant plus difficile l'association d'une transaction à une personne en particulier. En revanche, le modèle compte/solde, qui utilise des adresses fixes, est plus sensible à l'analyse des associations.

Cependant, le modèle UTXO a ses limites. Il a été initialement conçu pour faciliter les transferts de devises simples et n'est pas adapté à la gestion de logiques commerciales complexes. Bien que les fonctionnalités de base telles que les signatures multiples et les blocages temporels puissent être implémentées à l'aide de langages de script, le minimum d'informations d'état que l'UTXO de Bitcoin peut enregistrer le rend moins capable de gérer des opérations plus complexes.

Les limites de l'UTXO de Bitcoin ont indirectement contribué à l'émergence d' « Ethereum ». Vitalik, l'un des premiers contributeurs au magazine Bitcoin, était bien conscient des défauts de Bitcoin. Le modèle compte/solde, plus facile à comprendre pour la plupart des gens, répond aux défis auxquels UTXO est confrontée en matière de gestion des applications riches. Comme Vitalik l'a indiqué dans le livre blanc d'Ethereum :

UTXO peut être dépensé ou non dépensé ; il n'est pas possible de conclure des contrats en plusieurs étapes ou de créer des scripts qui conservent un autre état interne au-delà de cela. Il est donc difficile de conclure des contrats d'options en plusieurs étapes, des offres d'échange décentralisées ou des protocoles d'engagement cryptographiques en deux étapes (nécessaires pour sécuriser les primes informatiques). Cela signifie également qu'UTXO ne peut être utilisé que pour créer des contrats simples et ponctuels, et non des contrats « avec état » plus complexes, tels que des organisations décentralisées, et rend les méta-protocoles difficiles à mettre en œuvre. L'état binaire combiné à la cécité des valeurs signifie également qu'une autre application importante, celle des limites de retrait, est impossible.

Application, optimisation et extension du modèle UXTO

Avant d'examiner les différentes applications et optimisations du modèle UTXO, analysons les domaines à améliorer tout en préservant ses avantages. Elles peuvent être résumées comme suit :

1. Abstraire la signification de l'état enregistré dans UtxOS.

2. Abstraction de la propriété de l'État.

3. Résolution des problèmes de conflit d'état lors du partage d'UtxOS.

En BTC, le seul sens de l'État est la quantité de jetons. La propriété est généralement définie à l'aide de clés publiques, et les litiges entre États ne sont pas abordés de manière approfondie, car le BTC n'a pas été conçu pour les DApps.

Sui

Sui fournit aux développeurs deux types d'objets : OwnedObject et SharedObject. Le premier est similaire à UTXO (en particulier une version améliorée), tandis que le second est comparable au modèle compte/solde. Les deux peuvent être utilisés simultanément.

Un objet peut être partagé, ce qui signifie que tout le monde peut lire ou écrire dessus. Contrairement au OwnedObject mutable (avec un seul rédacteur), SharedObject nécessite un consensus pour ordonner les lectures et les écritures.

Dans les autres blockchains, chaque objet est partagé. Cependant, les développeurs Sui peuvent généralement choisir d'utiliser OwnedObject, SharedObject ou une combinaison des deux pour implémenter des cas d'utilisation spécifiques. Ce choix peut avoir un impact sur les performances, la sécurité et la complexité de la mise en œuvre.

À Sui, les objets possédés sont similaires aux UTXO, et seul leur propriétaire peut les utiliser. Les objets ont également des numéros de version, et une version d'un objet ne peut être dépensée qu'une seule fois par son propriétaire. Par conséquent, une version d'un objet correspond essentiellement à un UTXO.

En ce qui concerne les conflits entre États, Sui les résout par le biais d'une gestion spéciale (commande locale, similaire à Fuel) dans SharedObjects.

Cardano

Cardano utilise un modèle UTXO étendu connu sous le nom d'eUxo. eUxo permet une programmabilité accrue tout en conservant les avantages du modèle Bitcoin UTXO.

Dans Cardano, le sens de l'État est encore élargi grâce à des scripts, et la propriété de l'État est définie de manière plus générale. Les sets UTXO sont utilisés pour minimiser les problèmes de conflit d'État. Plus précisément, eUxo est amélioré à deux égards :

1. Le modèle eUxo inclut des adresses plus généralisées. Ces adresses ne sont pas uniquement basées sur le hachage des clés publiques, mais peuvent être définies selon n'importe quelle logique spécifiant les conditions dans lesquelles l'eUxo peut être dépensé, permettant ainsi la programmabilité de la propriété de l'État.

2. Outre les adresses et les valeurs, les sorties peuvent contenir (presque) toutes les données, ce qui permet de programmer la signification de l'état par le biais de scripts.

Plus précisément, eUxo permet aux utilisateurs d'ajouter des données arbitraires dans un format similaire à JSON à UtxOS, appelées Datum. Datum permet aux développeurs de fournir des fonctionnalités similaires à des états pour les scripts, associées à des UTXOS spécifiques.

De plus, les transactions sur Cardano peuvent comporter des paramètres liés à des utilisateurs spécifiques, appelés utilisateurs. Redeemer permet à l'initiateur de la transaction de définir la manière dont les UTXOS sont utilisés et peut être utilisé par les développeurs de dApp à des fins diverses.

Lorsqu'une transaction est validée, le script de validation fonctionne à l'aide de Datum, Redeemer et du contexte contenant les données de transaction. Ce script inclut la logique d'utilisation d'UtxOS lorsque les conditions sont remplies.

Il convient de noter qu'eUxo effectue toujours des tâches d'extension par le biais de scripts, ce qui diffère considérablement de la notion traditionnelle de « contrats intelligents » (Charles Hoskinson, le fondateur, suggère de le qualifier de « validateur programmable », mais le terme « contrats intelligents » est plus largement accepté sur le marché).

Nervos

Dans Nervos (CKB), la signification de l'État est résumée par TypeScript, et la propriété de l'État est abstraite par un lockscript. Un modèle d'optimisation UTXO simple sous forme de code cellulaire est le suivant :

pub struct CellOutput {

    capacité du pub : capacité,

 données de publication : Vec & lt ; u8 >,

 pub lock : script,

 pub type_ : Option & lt ; script >,

}

Pour ce qui est de la question des litiges entre États, CKB poursuit actuellement ses recherches sur Open Transaction, dans le cadre desquelles les utilisateurs peuvent proposer un UTXO partiel précisant l'objectif de la transaction, puis les entremetteurs les agréger pour former une transaction complète.

Le modèle cellulaire de Nervos est une version « généralisée » d'UTXO, et Jan a fourni une explication détaillée sur le forum Nervos :

La couche 1 se concentre sur l'état, et avec la couche 1 comme cible de conception, CKB se concentre naturellement sur l'état.

Ethereum sépare l'historique des transactions et l'historique des états en deux dimensions, où les blocs et les transactions représentent des événements déclenchant des transitions d'état plutôt que l'état lui-même. En revanche, le protocole Bitcoin fusionne les transactions et les états en une seule dimension : les transactions, c'est l'État, et l'État, la transaction. C'est une architecture centrée sur l'État.

Dans le même temps, CKB vise à vérifier et à préserver non seulement NValue en tant qu'État, mais aussi toutes les données considérées comme précieuses et approuvées par consensus pour une conservation à long terme. La structure de sortie des transactions de Bitcoin n'est pas adaptée à cette fin, mais elle nous a beaucoup inspiré. En généralisant NValue et en le transformant d'un espace contenant des entiers en un espace capable de contenir toutes les données, nous obtenons un « CtxOut » ou une cellule plus généralisé.

Dans une cellule, NValue devient deux champs : capacité et données. Ces champs représentent conjointement un espace de stockage, où la capacité est un entier indiquant la taille de l'espace en octets, et les données indiquent l'endroit où l'état est stocké et peut contenir n'importe quelle séquence d'octets. La ScriptPubKey devient un verrou, il suffit de changer de nom, pour indiquer qui est le propriétaire de cet espace de consensus. Seule la personne capable de fournir des paramètres (comme une signature) pour que le script de verrouillage s'exécute correctement peut « mettre à jour » l'état de cette cellule. Le nombre total d'octets occupés par l'ensemble de CellOutput doit être inférieur ou égal à la capacité. CKB possède de nombreuses cellules, et leur collection constitue l'état actuel complet de CKB, stockant des connaissances partagées plutôt qu'une simple monnaie numérique spécifique.

Les transactions représentent toujours des changements/migrations de l'État. Le changement d'état ou la « mise à jour » du contenu des cellules se font en fait par destruction et création (et non en modifiant directement le contenu de la cellule d'origine). Chaque transaction détruit effectivement un lot de cellules tout en créant un nouveau lot de cellules. Les cellules nouvellement créées ont de nouveaux propriétaires et stockent de nouvelles données, mais la capacité totale détruite est toujours supérieure ou égale à la capacité totale créée, afin que personne ne puisse l'augmenter arbitrairement. Comme la capacité peut être transférée mais pas augmentée arbitrairement, posséder de la capacité revient à posséder une quantité correspondante d'espace public consensuel. La capacité est l'atout natif du réseau CKB. La destruction d'une cellule indique simplement qu'elle est « détruite », de la même manière que les Bitcoin UTXO non dépensés sont dépensés sans être retirés physiquement de la blockchain. Chaque cellule ne peut être détruite qu'une seule fois, tout comme chaque UTXO ne peut être dépensé qu'une seule fois.

Les caractéristiques de ce modèle sont les suivantes :

1. L'État est primordial.

2. La propriété est un attribut de l'État, chaque État ayant un seul propriétaire.

3. Les États sont continuellement détruits et créés.

Par conséquent, une cellule est une version généralisée d'UTXO.

Carburant

Fuel adopte le modèle de liste d'accès stricte, qui est une optimisation UTXO basée sur le concept du Contract UTXO.

Comme indiqué précédemment, l'UTXO traditionnel en BTC ne possède que deux attributs : la quantité de pièces et le propriétaire. En revanche, Contract UTXO fournit des propriétés fondamentales supplémentaires, notamment la quantité de pièces, l'identifiant du contrat, le hachage du code du contrat et la racine de stockage.

Si vous utilisez un modèle d'exécution apatride, seul Contract UTXO nécessite un hachage du code du contrat et une racine de stockage. Dans un modèle d'exécution dynamique, ces champs peuvent être omis dans Contract UTXO, mais un type Storage Element UTXO distinct est nécessaire. L'identifiant UTXO, identifiant unique pour chaque UTXO servant de clé dans une base de données de stockage de valeurs clés, est généré à partir du point de sortie de l'UTXO ou de sa variante (par exemple, le hachage du point de sortie et de ses champs).

Dans ce modèle, Contract UTXO, similaire aux contrats intelligents, peut être appelé par n'importe qui.

Il est essentiel de noter que Fuel propose des fonctionnalités plus proches des contrats intelligents que des scripts. Les limites du modèle UTXO lui-même compliquent le développement d'applications avec une machine virtuelle, notamment en ce qui concerne la gestion des problèmes de contention UTXO. Il existe généralement trois solutions : d'abord, traiter hors chaîne, par exemple dans le cadre du cumul ; deuxièmement, pré-séquencer les tâches supplémentaires, que Fuel emploie ; troisièmement, la transaction ouverte mentionnée ci-dessus dans CKB, où chaque utilisateur peut proposer des transactions partielles, et un système de matchmaking (similaire à un séquenceur) les combine en transactions complètes. La solution correspondante en BTC est le PBST.

Conclusion

Grâce à cet article, nous avons compris les principes fondamentaux d'UTXO, reconnu les points forts et les points faibles de son modèle par rapport au modèle compte/solde d'Ethereum, et avons eu une meilleure idée du concept d'UTXO et de ses extensions associées.

En tant que principe de conception fondamental du Bitcoin, le modèle UTXO joue un rôle crucial pour garantir la sécurité et la traçabilité des transactions. Avec l'évolution et l'expansion continues de la technologie blockchain, le modèle UTXO s'est développé (comme EUTXO, cell, Strict Access List), offrant de nouvelles possibilités pour les transactions et la gestion des actifs numériques. Grâce à des recherches approfondies et à une compréhension du concept UTXO et de ses extensions associées, nous pourrons mieux saisir l'essence de la technologie blockchain, jetant ainsi des bases plus solides pour les innovations et applications futures.

Avertissement：

1. Cet article est reproduit depuis [ Web3]. Tous les droits d'auteur appartiennent à l'auteuroriginal [0xAYA]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.