Lien original en anglais : https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2
Dans le monde actuel de la blockchain, il existe deux principales méthodes de tenue de registres : le modèle UTXO (Unspent Transaction Output) et le modèle de compte. Bitcoin utilise le modèle UTXO et Ethereum utilise le modèle Account.
Bitcoin a été conçu à l'origine comme un système de paiement électronique peer-to-peer. Dans Bitcoin, chaque transaction consomme l'UTXO généré par la transaction précédente puis génère un nouvel UTXO. Le solde du compte est l'ensemble de tous les UTXO non dépensés appartenant à l'UTXO. L'état global de Bitcoin est une collection de tous les UTXO actuellement non dépensés. Ethereum a l'intention de créer un protocole plus général prenant en charge les langages de programmation complets de Turing, sur lesquels les utilisateurs peuvent rédiger des contrats intelligents et créer diverses applications décentralisées. En raison des lacunes du modèle UTXO en termes de préservation de l'état et de programmabilité, Ethereum a introduit le modèle Account.
Ci-dessous, nous développons davantage les avantages et les inconvénients des deux modèles.
Modèle UTXO
Dans le modèle UTXO, les transactions représentent uniquement les modifications apportées à la collection UTXO. Les concepts de comptes et de soldes sont des abstractions supérieures sur les collections UTXO, et les concepts de numéros de compte et de soldes n'existent que dans les portefeuilles.
avantage:
Le calcul est hors chaîne et la transaction elle-même est à la fois le résultat et la preuve. Le nœud n'a besoin que d'effectuer une vérification, il n'a pas besoin d'effectuer de calculs supplémentaires sur la transaction et il n'y a pas de stockage d'état supplémentaire. Le calcul du résultat UTXO de la transaction elle-même est effectué dans le portefeuille, de sorte que la charge de calcul de la transaction soit entièrement supportée par le portefeuille, ce qui réduit dans une certaine mesure la charge sur la chaîne.
À l'exception des transactions Coinbase, l'entrée de la transaction est toujours liée derrière un UTXO. Les transactions ne peuvent pas être rejouées, et la séquence et les dépendances des transactions peuvent être facilement vérifiées, et il est également facile de prouver si les transactions ont été consommées.
Le modèle UTXO est sans état et plus facile à traiter simultanément.
Meilleure confidentialité pour les transactions de type P2SH. Les entrées dans la transaction ne sont pas liées les unes aux autres et des technologies telles que CoinJoin peuvent être utilisées pour augmenter un certain degré de confidentialité.
défaut:
Il est incapable de mettre en œuvre une logique plus complexe et sa programmabilité est médiocre. Pour les logiques complexes ou les contrats qui nécessitent la préservation de l’état, la mise en œuvre est difficile et l’utilisation de l’espace d’état est relativement faible.
Lorsqu'il y aura plus d'entrées, les scripts de témoins augmenteront également. La signature elle-même consomme plus de CPU et d'espace de stockage.
Modèle de compte
Pour le modèle Account, le modèle Account enregistre l'état mondial et l'état de la chaîne est généralement convenu sous la forme de StateRoot et ReceiptRoot dans le bloc. La transaction n'est que l'événement lui-même et ne contient pas le résultat. Le consensus de la transaction et le consensus de l'État peuvent être essentiellement isolés.
avantage:
Le contrat est stocké dans le compte sous forme de code et le compte a son propre état. Ce modèle a une meilleure programmabilité, est plus facile à comprendre pour les développeurs et propose un plus large éventail de scénarios.
Les transactions groupées sont moins coûteuses. Imaginez que le pool minier paie aux mineurs des frais de traitement. Dans UTXO, étant donné que chaque entrée et sortie nécessite un script témoin ou un script de verrouillage distinct, la transaction elle-même sera très volumineuse et la vérification de la signature et le stockage de la transaction consommeront des ressources précieuses sur la chaîne. . Le modèle de compte peut réduire considérablement les coûts grâce aux contrats.
défaut:
Il n'y a aucune dépendance entre les transactions du modèle de compte et le problème de relecture doit être résolu.
Pour la mise en œuvre de Lightning Network/Thunder Network, Plasma, etc., un mécanisme de preuve de preuve plus complexe est requis pour la preuve utilisateur, et un protocole plus complexe est requis pour la migration d'état des sous-chaînes vers la chaîne principale.
Compte UTXO VS
Faisons une analyse et une comparaison des avantages et des inconvénients ci-dessus.
Premièrement, concernant les problèmes de calcul
La transaction UTXO elle-même n'a pas de calculs compliqués pour la blockchain. Pour le dire simplement, elle n'est pas tout à fait exacte. Premièrement, la plupart des propres transactions de Bitcoin sont P2SH et le script Witness n'est pas complet et ne le fait pas. exister. Pour le modèle de compte, tel qu'Ethereum, étant donné que la plupart des calculs sont effectués sur la chaîne et sont complets par Turing, les calculs sont généralement plus complexes et la sécurité du contrat peut facilement devenir un problème relativement important. Bien sûr, que Turing soit complet ou non n’a aucune incidence directe sur le fait qu’il s’agisse d’un modèle de compte. Mais une fois le modèle de compte introduit, le contrat peut exister en tant qu'entité indépendante qui n'est contrôlée par personne, ce qui est d'une grande importance.
Deuxièmement, concernant le fait qu'UTXO soit plus facile à utiliser en simultanéité
Dans le modèle UTXO, l'état mondial est un ensemble d'UTXO. Afin de vérifier les transactions plus rapidement, les nœuds doivent stocker les index de tous les UTXO en mémoire, les UTXO sont donc très coûteux. Les UTXO qui ne sont pas consommés pendant une longue période occuperont toujours la mémoire du nœud. Par conséquent, pour ce modèle, les utilisateurs devraient théoriquement être encouragés à produire moins d’UTXO et à consommer plus d’UTXO. Cependant, si vous souhaitez utiliser UTXO pour des transactions parallèles, vous avez besoin de plus d'UTXO en entrée, et en même temps, vous devez générer plus d'UTXO pour garantir la concurrence. Il s'agit essentiellement d'une attaque de poussière sur le réseau. Et comme les transactions sont construites au sein du portefeuille, une conception plus complexe du portefeuille est nécessaire. En repensant au modèle de compte, chaque compte peut être considéré comme une machine à états distincte qui ne s'affecte pas les uns les autres, et les comptes communiquent via des messages. Par conséquent, en théorie, lorsqu'un utilisateur initie plusieurs transactions et que ces transactions ne s'appellent pas mutuellement sur le même compte, les transactions peuvent être exécutées simultanément.
Troisièmement, concernant le problème de relecture des transactions du modèle de compte
Ethereum utilise la méthode d'ajout de nonce dans le compte. Chaque transaction correspond à un nonce, et le nonce est incrémenté à chaque fois. Bien que cette méthode soit destinée à résoudre le problème de relecture, elle introduit également des problèmes séquentiels et rend les transactions impossibles à paralléliser. Par exemple, dans Ethereum, un utilisateur envoie plusieurs transactions. Si la première transaction ne parvient pas à être empaquetée, les transactions suivantes ne seront pas empaquetées avec succès. Dans CITA, nous utilisons un schéma de nonce aléatoire, de sorte qu'il n'y a pas de dépendance séquentielle entre les transactions des utilisateurs, ce qui ne provoquera pas de défaillance en série et permettra également de traiter les transactions en parallèle.
Quatrièmement, les problèmes de stockage
Parce que dans le modèle UTXO, l'état ne peut être sauvegardé que dans les transactions. L'état du modèle de compte est enregistré dans le nœud et stocké à l'aide de MPT dans Ethereum. Dans le bloc, seul le consensus StateRoot est requis. De cette façon, pour les données en chaîne, le modèle de compte est en réalité plus petit et la quantité de transmission réseau est plus petite. Dans le même temps, l'état est enregistré localement sur le nœud à l'aide de MPT, ce qui est plus efficace en termes d'utilisation de l'espace. Par exemple, si A transfère de l'argent à B, s'il y a 2 entrées et 2 sorties dans UTXO, 2 scripts de témoin et 2 scripts de verrouillage sont requis dans le modèle de compte, une seule signature est requise et le contenu de la transaction ne contient que le montant ; . Après la mise en œuvre du dernier Segregated Witness, la quantité de données de transaction Bitcoin a également été considérablement réduite, mais en fait, les nœuds de vérification et les nœuds complets doivent toujours transmettre et vérifier le script Witness.
Cinquièmement, pour que les nœuds légers obtiennent un certain statut d'adresse, UTXO est plus compliqué
Par exemple, dans un portefeuille, vous devez demander tous les UTXO concernant une certaine adresse au nœud complet. Le nœud complet peut envoyer certains UTXO. Il est difficile pour le portefeuille de vérifier si l'UTXO a été consommé, et c'est difficile pour le portefeuille. le portefeuille pour prouver que l'UTXO est l'ensemble complet plutôt qu'une collection partielle. Le modèle de compte est beaucoup plus simple. L'état correspondant dans l'État est trouvé en fonction de l'adresse. La preuve d'État de l'état actuel peut prouver l'authenticité des données du contrat. Bien entendu, pour UTXO, la racine d’UTXO peut également être vérifiée dans chaque bloc. Ceci est lié à l’implémentation actuelle de Bitcoin et n’est pas une fonctionnalité d’UTXO.
en conclusion
Pour résumer, le modèle Account présente plus d'avantages en termes de programmabilité et de flexibilité ; dans les affaires simples et inter-chaînes, UTXO présente des avantages tout à fait uniques et révolutionnaires. Le modèle à choisir doit être basé sur des scénarios commerciaux spécifiques.