Les portefeuilles sur chaîne réalisent un mappage approximatif 1-1 des transactions aux transactions : pour chaque transaction économique qu'un utilisateur effectue, environ une transaction blockchain est nécessaire. Les agrégations, les coinjoin, les paiements cut-through, etc. modifient un peu cette déclaration. Mais c'est approximativement correct.

Lightning a réalisé un mappage de nombreux-à-un des transactions vers les transactions : la magie de Lightning est qu'un nombre effectivement infini de transactions économiques peut se produire dans un seul canal d'éclairage, qui est lui-même lié à une seule sortie de transaction non dépensée (UTXO). Essentiellement, nous avons pris la dimension "temps" - les transactions - et réalisé une mise à l'échelle significative en réduisant cette dimension.

Mais créer même un seul UTXO par utilisateur n'est, sans doute, pas suffisant. Il existe donc de nombreuses propositions visant à obtenir une plus grande mise à l'échelle en permettant à plusieurs utilisateurs de partager un seul UTXO de manière auto-souveraine. Encore une fois, en regroupant une autre dimension de mise à l'échelle, les utilisateurs, en un seul UTXO.

Notre objectif ici est de faire une vue d'ensemble de toutes ces propositions, de comprendre quels schémas techniques elles partagent, de comprendre de quels types de nouveaux opcodes et autres mises à niveau de fork doux elles ont besoin pour fonctionner, et de créer un tableau comparatif montrant comment toutes les parties s'emboîtent. En chemin, nous définirons également ce qu'est réellement un protocole de couche 2, quelle est la capacité de mise à l'échelle du Lightning, et nous comprendrons quelles améliorations nous devons apporter aux mempools pour réaliser tout cela.

Merci va àFulgur Venturespour parrainer cette recherche. Ils n'ont eu aucun contrôle éditorial sur le contenu de ce post et ne l'ont pas examiné avant sa publication.

Merci également àDaniela Brozzoni, Sarah Cox, et d'autres pour une revue préalable à la publication.

Définitions

Qu'est-ce que le Layer 2?

Souvent, le terme "Layer 2" est défini de manière large, au point que même une entité de type bancaire (par exemple, Liquid) pourrait être définie comme une couche 2. Aux fins de cet article, nous adopterons une définition stricte : une couche 2 (L2) est un système libellé en Bitcoin, dans le but de permettre aux BTC d'être transigés plus souvent que le nombre de transactions sur chaîne avec d'autres parties. De sorte que soit :

1. Personne n'est en mesure de voler des fonds de manière rentable dans le système, en tenant compte des sanctions et des coûts du système. Les coûts et les sanctions hors système tels que la perte de réputation, les conséquences légales, etc. ne sont pas pris en compte dans notre définition.
2. (Préféré) Les véritables propriétaires des fonds peuvent retirer unilatéralement leurs fonds, moins les frais de transaction, sans la coopération de tiers.

La première option est nécessaire car nous voulons que nos systèmes de couche 2 puissent représenter des montants et des transactions d'une si petite valeur qu'ils ne peuvent pas être représentés on-chain. Par exemple, dans Lightning, les HTLC peuvent avoir une valeur trop petite pour être représentée on-chain. Dans ce cas, la valeur de HTLC est ajoutée aux frais de transaction de la transaction d'engagement. Alors qu'un nœud Lightning peut "voler" un HTLC de poussière en fermant un canal au bon moment, le faire est plus cher.¹que la valeur de HTLC, rendant le vol non rentable.

Cela dit, le retrait unilatéral est toujours notre objectif principal de conception.²

Avec cette définition, des choses comme Lightning sont considérées comme des systèmes de couche 2. Cependant, des systèmes tels que Liquid, Cashu et Fedimint ne sont pas des L2, car une autre partie ou d'autres parties ont le contrôle de vos fonds. Les schémas de validation côté client comme RGB ne sont également pas des L2 selon cette définition, car ils ne peuvent pas effectuer des transactions BTC de manière fiable. Enfin, @RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains ne parvient pas à passer le cap, car l'entité Statechain peut voler des fonds s'ils ne suivent pas le protocole.

Quels sont les Engagements ?

...et pourquoi les systèmes L2 plus évolutifs en ont-ils besoin ?

Dans le script Bitcoin, les pactes sont des mécanismes par lesquels la manière dont une txout peut être dépensée est restreinte à l'avance, de sorte que la forme des transactions utilisées pour dépenser cette txout est prédéfinie ou autrement restreinte d'une manière qui n'est pas uniquement limitée aux signatures. Les systèmes de couche 2 qui partagent des UTXO entre plusieurs parties ont besoin de pactes car ils ont besoin de moyens de restreindre la façon dont l'UTXO peut être dépensée pour implémenter les règles et les incitations du protocole de couche 2.

Covenants récursifs

Un covenant récursif est un covenant avec la propriété que les règles contraignant la façon dont un UTXO peut être dépensé peuvent être appliquées de manière récursive, aux UTXO enfant de la transaction de dépense indéfiniment. Les covenants récursifs ont longtemps été considéré comme indésirable par certainsparce qu'ils peuvent grever les pièces indéfiniment. Ou du moins, indéfiniment sans l'autorisation d'un tiers tel qu'un gouvernement.

Objectifs

Lightning est actuellement le meilleur système de couche 2. Cependant, il présente des limitations. Notamment :

1. Le dimensionnement - Lightning nécessite actuellement au moins un UTXO par utilisateur final.³
2. La liquidité - Lightning exige que les fonds soient bloqués dans des canaux.
3. Interactivité - Lightning exige que les destinataires des paiements soient en ligne pour les recevoir en toute confiance.

En évaluant les systèmes de couche 2, notre objectif sera d'améliorer ces limitations clés, idéalement sans ajouter de nouvelles limitations.

Limites de mise à l'échelle de Lightning

Que signifie "une UTXO par utilisateur final" en pratique ? Étant donné que les canaux Lightning peuvent fonctionner indéfiniment, on peut se demander combien de nouveaux canaux peuvent être créés par an.⁴. Créer une sortie taproot a un coût marginal de 43vB ; si la création de canal est amortie, avec de nombreux canaux créés dans une seule transaction, les autres frais de transaction peuvent être rendus négligeables et un nombre assez important de canaux peuvent être ouverts par an pour intégrer de nouveaux utilisateurs. Par exemple, supposons que 90% de la capacité de bloc soit consacrée à l'ouverture de nouveaux canaux Lightning taproot :

On estime que environ la moitié de la population mondiale possède un smartphone, 4,3 milliards de personnes. Nous pouvons donc en fait intégrer un pourcentage important de la population entière qui est susceptible de pouvoir utiliser un canal Lightning par an.

Cependant, les canaux ne durent pas éternellement. À l’occasion, les utilisateurs voudront changer de portefeuille, augmenter ou diminuer la capacité des canaux, etc. La méthode la plus efficace pour modifier la capacité d’un canal consiste à raccordement, notamment mis en œuvre dans Portefeuille Phoenix.

Comme l'ouverture de canal, le raccordement pourrait également être effectué de manière amortie pour améliorer l'efficacité, avec plusieurs opérations de raccordement partageant une seule transaction pour réduire le nombre d'entrées et de sorties nécessaires pour ajouter et retirer des fonds⁵Ainsi, l'espace de bloc delta requis par tranche d'utilisateurs, en supposant l'utilisation demusig, est la sortie de la racine pivotante de 43 vB plus la sortie

57.5vB dépense de chemin clé taproot, pour un total de 100.5vB. Si nous supposons à nouveau une utilisation de l'espace de blocs de 90%, nous obtenons :

Enfin, notez comment le basculement des canaux Lightning entre les portefeuilles peut être effectué dans une seule transaction en faisant confiance au portefeuille suivant pour signer une transaction d'engagement après que les fonds ont été envoyés à l'adresse d'engagement, ou avec un soutien de fermeture-coopérative-au-nouveau-canal dans les deux implémentations de portefeuille.

Bien sûr, il existe des cas d’utilisation concurrents pour Bitcoin au-delà des canaux Lightning, et il est difficile de savoir comment cela se traduira par des taux de frais. Mais ces chiffres nous donnent une approximation approximative qui suggère qu’avec la technologie actuelle, il est au moins techniquement possible de prendre en charge des centaines de millions d’utilisateurs de Lightning auto-souverains.

Aperçu de la couche 2

Selon notre définition des systèmes de couche 2, il existe deux modèles de conception principaux discutés dans la communauté de développement Bitcoin:

1. Canaux
2. UTXOs virtuels

Dans le schéma de canal, dont Lightning est le principal exemple, le protocole progresse en échangeant des transactions pré-signées entre les parties qui pourraient être minées, mais qui ne se trouvent pas dans le « chemin heureux ». Ces transactions pré-signées divisent un UTXO entre les parties ; les transactions se produisent en modifiant à plusieurs reprises l'équilibre de cette division, avec de nouvelles transactions pré-signées. Étant donné qu'il existe de nombreuses transactions valides possibles dépensant le même UTXO, un mécanisme d'incitation est nécessaire pour s'assurer que la transaction correcte est celle qui est réellement minée.

Dans le modèle de conception Virtual UTXO (V-UTXO), dont Ark est l’exemple le plus frappant, les V-UTXO sont créés via des covenants ou des accords multipartites, via la création de transactions qui pourraient être minées pour retirer unilatéralement les fonds V-UTXO en les mettant sur la chaîne, mais qui ne sont pas sur le « chemin heureux ». À cet égard, les V-UTXO sont similaires aux canaux. Mais contrairement aux canaux, les systèmes V-UTXO effectuent des transactions en dépensant les V-UTXO eux-mêmes, en (conceptuellement) un seul⁶transaction pré-signée.

Le modèle de conception « happy path » est l’utilisation d’un chemin de script « toutes les parties sont d’accord », tel qu’un multisig N-of-N ; taproot est conçu spécifiquement pour ce concept, ce qui permet au chemin de clé d’être un multisig N-of-N via musig. En supposant que toutes les parties soient d’accord, le chemin heureux permet aux pièces d’être dépensées efficacement (et en privé).

De manière intéressante, étant donné que les UTXO virtuels sont « réels » à bien des égards, il est assez facile de construire des canaux sur les UTXO virtuels en créant simplement des UTXO virtuels qui, s'ils sont extraits, aboutiraient à la création des UTXO requis pour les canaux. En ce sens, les schémas UTXO virtuels sont une

couches légèrement inférieures aux canaux.

Éclairage

Le statu quo, mis en production sous le nom de Lightning Network, est principalement basé sur le normes BOLTs. Lightning est une combinaison de plusieurs éléments, comprenant des canaux Lightning et des HTLCs, le réseau de routage P2P, le routage en oignon, les normes d'invoicing, etc. Il est important de noter que Lightning n'est pas un système de consensus, donc les différents éléments du « système Lightning » n'ont pas besoin d'être adoptés de la même manière par tous les utilisateurs. Dans le cadre de cet article, lorsque nous disons « Lightning », nous l'entendons dans le sens large, incluant les mises à niveau facilement prévisibles du(des) protocole(s) Lightning actuel(s) qui sont largement utilisées.

Comme discuté ci-dessus, la caractéristique clé de Lightning est sa limite de scalabilité pour les utilisateurs finaux, en raison de la nécessité d'avoir au moins une UTXO par utilisateur. Cela dit, pour l'élément de routage "central" de Lightning - les nœuds publics de Lightning qui routent la grande majorité des transactions - ces limites de scalabilité ne sont pas vraiment une préoccupation car Lightning fonctionne très bien s'il y a beaucoup plus d'utilisateurs finaux que de nœuds de routage, car chaque canal public utilisé pour le routage des paiements peut facilement prendre en charge un grand nombre de transactions par seconde. C'est aussi pourquoi de nombreux futurs systèmes L2 prévoient également de participer au réseau Lightning. Nous le voyons également dans la manière dont les systèmes existants qui ne sont pas tout à fait des systèmes L2 comme Cashu dà0e9pendent fortement du réseau Lightning pour être réellement utiles : l'utilisation principale de Cashu est probablement d'envoyer et de recevoir des paiements Lightning.

Canaux Non-Interactifs

Cette construction améliore les canaux Lightning en utilisant OP_CTV pour réduire les exigences d'interactivité. Cependant, comme elle ne permet pas d'améliorer la limite d'échelle de 1-UTXO-par-utilisateur, nous n'en discuterons pas davantage.

Usines de canaux

Ici, nous avons plusieurs parties qui négocient une adresse multisig unique n-of-n, ainsi qu'une transaction dépensant cette adresse multisig pour créer n différents UTXO, divisant les fonds. Ces UTXO sont à leur tour utilisés pour les canaux de paiement. Les canaux peuvent être utilisés avec la même sécurité que s'ils avaient été ouverts directement on-chain, car dans le cas où l'état du canal doit être mis on-chain, la transaction divisée peut être minée. Cela permet potentiellement d'économiser de l'espace on-chain lorsque les canaux sont fermés, car les n parties peuvent — en théorie — fermer coopérativement tous les nn canaux en une seule fois.

Puisque les usines de canal négocient des UTXO qui pourraient être minés, mais ne devraient pas réellement être minés dans le scénario optimal, elles sont un exemple très primitif de V-UTXOs.

Les usines de chaînes en elles-mêmes ne nécessitent aucun fork pour être possibles. Cependant, les simples usines de chaînes décrites ci-dessus sont probablement impraticables au-delà de petits nombres de parties en raison de la coordination nécessaire pour réellement obtenir un avantage d'échelle. Ainsi, des propositions de conventions telles que OP_Evictou CTV (via arbres txout) visent à permettre des résultats plus fins où des parties individuelles peuvent être contraintes on-chain, sans forcer tout le monde on-chain en même temps.

Eltoo/LN-Symmetry

Étant donné que Eltoo est un nom terriblement confus, nous n'utiliserons que le nom mis à jour LN-Symmetry à partir de maintenant.

Alors que les canaux Poon-Dryja encouragent la publication de l’état correct sur la chaîne en punissant les états incorrects, LN-Symmetry permet plutôt de mettre à jour les états incorrects avec une transaction supplémentaire. Cela a l’avantage de simplifier les canaux Lightning en supprimant la complexité des pénalités. Cependant, cela est susceptible d’être un inconvénient dans les scénarios non fiables, car des pénalités sont sans doute nécessaires pour décourager la fraude.

LN-Symmetry a besoin d'une mise à niveau logicielle pour être activéeSIGHASH_ANYPREVOUTqui est nécessaire pour permettre aux transactions d'état de réutiliser d'autres transactions d'état lors des mises à jour.

En soi, LN-Symmetry n'offre aucune amélioration de mise à l'échelle sur les canaux Lightning conventionnels. Mais les partisans ont argumenté que cela facilite la mise en œuvre de choses comme les usines de canaux.

Ark

Ark adopte une nouvelle approche de la mise à l’échelle des transactions : des UTXO virtuels entièrement transférables (V-UTXO), qui peuvent être fusionnés et divisés en atomiques⁷Transactions hors chaîne. Dans Ark, un coordinateur central, le Fournisseur de services Ark (FSA), fournit des V-UTXO aux utilisateurs avec une durée de vie définie, par exemple 4 semaines. Ces périodes sont connues sous le nom de tours. Ces V-UTXOs sont créés via des txouts de pool, un par tour, via un mécanisme quelconque tel que CTV pour permettre à un seul txout de la chaîne de valider un arbre de V-UTXOs. L'expiration de la période est la façon dont Ark obtient un avantage d'échelle : à la fin d'un tour, le txout de pool se déverrouille, permettant au FSA de le dépenser unilatéralement avec une seule signature dans une petite transaction. En raison du délai d'expiration, les V-UTXOs eux-mêmes expirent lorsque les txouts de pool qui les créent expirent : les utilisateurs qui possèdent un V-UTXO doivent soit dépenser ce V-UTXO avant que le délai d'expiration du txout de pool ne soit atteint, soit le mettre sur la chaîne (retrait unilatéral).

Pour effectuer des transactions V-UTXO entre les parties, le coordinateur Ark cosigne les transactions qui dépensent un ou plusieurs V-UTXO, de sorte que les transactions ne sont valides que si un ou plusieurs autres V-UTXO sont créés dans un autre tour. En combinaison avec quelques délais prudents - voir la documentation Ark pour tous les détails - cette dépendance est ce qui rend les V-UTXO dépensables sans confiance : les V-UTXO ne peuvent pas être réclamés sur la chaîne à moins que de nouveaux V-UTXO ne soient créés dans une autre transaction de pool. Il existe quelques façons potentielles de mettre en œuvre cette dépendance. Mais les détails exacts ne sont pas pertinents pour les besoins de cet article.

Remarquez comment cela signifie qu'un ASP donné aura de nombreuses rondes actives différentes se déroulant en même temps. De nouvelles rondes sont fréquemment créées pour permettre le transfert des fonds dans les rondes existantes. Mais les rondes existantes chevauchent les nouvelles rondes, car elles expireront généralement après les nouvelles rondes, et les nouvelles sorties de transactions de pool sont créées.

Ark Economics

Lorsqu'un V-UTXO est dépensé, l'ASP doit fournir des BTC correspondants dans une nouvelle sortie de transaction de pool représentant un nouveau tour. Mais ils ne peuvent pas récupérer la valeur du V-UTXO dépensé avant l'expiration du tour. Ainsi, l'économie des dépenses de V-UTXO a un coût de la valeur temporelle de l'argent, en raison de la liquidité que l'ASP doit fournir.

Plus précisément, le coût est engagé lorsque le V-UTXO est dépensé. Tant que le V-UTXO n'est pas dépensé, il représente un UTXO potentiel très réel qui pourrait être mis sur la blockchain pour retirer unilatéralement les fonds ; l'utilisateur possède ces fonds. Cependant, pour dépenser le V-UTXO, l'ASP doit créer une nouvelle sortie de transaction pool, en utilisant des fonds que l'ASP obtient par ailleurs, tandis que les fonds du V-UTXO dépensé ne sont pas disponibles pour l'ASP jusqu'à ce que le délai d'expiration soit atteint.

Ainsi, dépenser un V-UTXO nécessite un prêt à court terme, empruntant des fonds pour couvrir l'intervalle de temps entre maintenant et l'expiration du tour. Cela signifie que le coût de liquidité pour dépenser un V-UTXO diminue en réalité à mesure que le V-UTXO vieillit et que le temps d'expiration se rapproche, atteignant finalement — en théorie — zéro lorsque le tour expire enfin.

Enfin, rappelez-vous que le coût de dépenser un V-UTXO est lié à la taille totale du V-UTXO dépensé. Pas le montant payé au destinataire. Cela signifie que les portefeuilles destinés à effectuer des transactions directes avec des V-UTXOs (par opposition à la gestion d'un seul V-UTXO à des fins, par exemple, d'un canal d'éclairage basé sur V-UTXO) doivent faire des compromis sur la façon dont ils répartissent les fonds en V-UTXOs. Un seul V-UTXO minimise le coût du retrait unilatéral, tout en maximisant les frais de transaction basés sur la liquidité ; diviser les fonds en plusieurs V-UTXOs fait le contraire. C'est totalement différent de l'économie du Bitcoin on-chain ou des transactions Lightning.

Quel est ce coût de liquidité ? Au moment de la rédaction, le portefeuille Lightning Phoenix facture des frais de 1 % pour réserver la liquidité du canal pendant 1 an ; au pire, Phoenix devrait immobiliser ses fonds pendant 1 an. Cependant, cela suppose que la liquidité n'est pas utilisée. Il est tout à fait possible que le coût du capital pour Phoenix soit en réalité plus élevé, et qu'ils supposent que le client moyen utilise leur liquidité entrante en moins d'un an. Phoenix gagne également de l'argent sur les frais de transaction, ce qui pourrait subventionner la liquidité du canal. Enfin, Phoenix pourrait ne pas être rentable !

Le taux des bons du Trésor américain nous donne une autre estimation. À l'heure actuelle, le taux des bons du Trésor à 3 mois est d'environ 5 % par an. Étant donné qu'il est argumenté que ce taux est surestimé en raison de l'inflation du dollar américain, nous supposerons un coût de liquidité de 3 % par an pour les fonds libellés en BTC pour notre analyse.

Si l’intervalle d’arrondi est de 4 semaines, cela signifie qu’une transaction commencera avec un coût de liquidité de

, pour finalement atteindre zéro. En supposant que l'utilisateur essaie de déplacer ses fonds vers une nouvelle ronde deux semaines avant l'expiration de la ronde, l'utilisateur paie environ 1,5% par an en frais de liquidité pour obtenir la garde de ses fonds. D'un autre côté, si l'utilisateur attend jusqu'au dernier moment⁸, le coût pourrait être presque nul, au risque de manquer le délai d'expiration.

Les utilisateurs peuvent ne pas considérer cela comme un coût trivial. Et ce coût suppose que les coûts fixes de chaque tour ont été rendus insignifiants en amortissant les frais de transaction et autres coûts sur un grand nombre de participants.

Et si les coûts fixes n'étaient pas si insignifiants ? Supposons que l'ASP compte 1000 utilisateurs et que les sorties de la piscine soient créées en moyenne une fois par heure. Sur une période de 4 semaines, cela représente 672 transactions sur la chaîne. Cela signifie que pour simplement conserver leurs fonds, les utilisateurs de l'ASP doivent collectivement payer presque autant de transactions que les utilisateurs ! Il serait probablement moins cher pour eux d'ouvrir tous leurs propres canaux Lightning, même si l'ASP exige qu'ils attendent une heure entière pour une confirmation.

Arche d’amorçage

Un nouveau ASP avec peu d'utilisateurs est confronté à un dilemme : soit les rondes ASP se produisent rarement, et les utilisateurs doivent attendre longtemps que la ronde proposée rassemble assez de V-UTXOs pour obtenir une mise à l'échelle utile et une réduction des frais de transaction. Soit les transactions du pool ASP se produisent fréquemment, avec des frais de transaction élevés payés par utilisateur. Comme nous l'avons montré dans la section précédente, il peut falloir beaucoup d'utilisateurs pour amortir les rondes fréquentes et leurs sorties txout sous-jacentes.

Parce que les rounds expirent, ce problème est un problème continu, encore pire que celui rencontré par les canaux Lightning : au moins un canal Lightning peut continuer à être utile indéfiniment, permettant l'ouverture d'un canal maintenant et son amortissement progressif sur de nombreux mois. Deuxièmement, parce que les rounds expirent, il y a moins de flexibilité quant au moment de créer les nouveaux txouts qui soutiennent ces rounds : si les frais sont élevés pendant une ou deux semaines, les utilisateurs dont les txouts de leur pool expirent n'ont d'autre choix que de (collectivement) payer ces frais élevés pour maintenir leur garde sur leurs fonds. Avec les canaux Lightning, il y a beaucoup plus de flexibilité quant à quand ouvrir réellement un canal.

Alors que les auteurs d'Ark ont initialement imaginé un scénario très optimiste où de nouveaux rounds seraient créés toutes les quelques secondes, le démarrage initial devra probablement se faire avec des cas d'utilisation qui peuvent se permettre d'attendre plusieurs heures pour qu'une transaction Ark soit confirmée, si les frais de transaction ne sont pas subventionnés.

Interactivité

L’Ark non dépositaire est un protocole hautement interactif : puisque vos V-UTXO expirent, vous avez des délais stricts pour interagir avec votre ASP, sinon l’ASP pourrait choisir de prendre vos fonds. Cette interactivité ne peut pas non plus être externalisée : alors que Lightning a watchtowers qui découragent les contreparties d’essayer de vous arnaquer - même si votre chaîne n’a pas été en ligne - les propriétaires de pièces Ark doivent utiliser leurs propres clés privées pour rafraîchir les fonds sans confiance. La chose la plus proche possible dans Ark des tours de guet serait de signer des transactions permettant à une tour de guet de retirer unilatéralement vos fonds on-chain vers l’heure d’expiration, ce qui a un coût de transaction important.

Imaginez ce qu’il advient d’un V-UTXO si le propriétaire se déconnecte : après l’expiration du tour, l’ASP doit récupérer les fonds pour récupérer ses liquidités pour les tours suivants. Si un propriétaire de V-UTXO se déconnecte, la mise en place de ce V-UTXO sur la chaîne entraîne des coûts de transaction importants, car l’ASP doit maintenant récupérer des fonds à plusieurs niveaux de l’arbre V-UTXO. L’ASP peut recréer les V-UTXO non dépensés lors d’un nouveau tour. Mais ce n’est pas sans confiance du point de vue des propriétaires de V-UTXO, car ils ne peuvent pas dépenser ces V-UTXO sans obtenir de données⁹ à partir de l’ASP. L’ASP pourrait aussi simplement enregistrer les V-UTXO non dépensés en tant que solde de garde. Ou peut-être même avoir une politique de saisie des fonds !

Personnellement, je soupçonne que compte tenu du coût non négligeable de l'auto-conservation à Ark, de nombreux utilisateurs opteront plutôt pour des ASP avec une politique de roulement des fonds dans un nouveau tour et accepteront simplement le potentiel de fraude à la fin de chaque tour. C'est moins cher que de déplacer proactivement leurs fonds suffisamment tôt pour garantir la sécurité en cas de, par exemple, leur échec à allumer leur téléphone à temps pour que leur portefeuille déplace les fonds vers un nouveau tour.

Advanced Ark

Il peut être envisageable de réduire les exigences de liquidité d'Ark grâce à des conventions plus avancées, s'il est courant que la liquidité soit utilisée en partie au cours d'un cycle. Par exemple, supposons que 50% de la valeur totale de V-UTXO dans une sortie de transaction de pool a été dépensée. Si l'ASP pouvait récupérer cette partie de la sortie de transaction de pool du cycle, il pourrait récupérer plus rapidement la liquidité, réduisant ainsi les coûts de liquidité globaux. Bien qu'aucune proposition concrète sur la façon de le faire n'ait été publiée, il semble certain que cela devrait être possible avec des conventions Suffisamment Avancées™. Probablement grâce à une sorte de mise à jour de soft-fork de script qui ajoute de nombreux opcodes utiles en une seule fois.

De même, grâce aux engagements Sufficiently Advanced™, la structure complète de l'arbre de txout pourrait être remplacée par une sorte de schéma de retrait progressif, offrant potentiellement des économies d'espace. Nous aborderons cette question dans une section ultérieure, car cette technique est potentiellement utile pour d'autres schémas.

La question de la garde en fin de tour est un autre cas où les accords suffisamment avancés™ pourraient résoudre un problème : un accord, en particulier un accord de preuve ZK, pourrait contraindre l'ASP à recréer tous les V-UTXO non dépensés au tour suivant, éliminant ainsi le problème de la garde qui leur revient en fin de tour. Bien qu'il soit probablement impossible de le rendre sans confiance, car l'utilisateur aura probablement besoin de certaines données de l'ASP pour dépenser leur V-UTXO lors du nouveau tour, cela pourrait empêcher l'ASP de bénéficier financièrement d'une fraude contre les utilisateurs hors ligne.

Paiement de frais sur chaîne lors du retrait unilatéral

Similaire à Lightning, l'économie du paiement des frais on-chain et la valeur réelle d'un V-UTXO après les frais déterminent si l'utilisation d'Ark correspond à notre définition d'un L2 via un retrait unilatéral, ou une fraude qui ne profite pas à l'ASP. Nous discuterons plus en détail de ces spécificités lorsque nous aborderons le modèle de conception de l'arbre txout.

Rollups de validité

Une grande classe de constructions de type sidechain, généralement proposées pour utiliser diverses formes de technologie de preuve à connaissance nulle (ZK) pour appliquer les règles de la chaîne. La technologie ZK-proof est la différence essentielle entre la technologie de cumul de validité et d’autres formes de sidechain : si le schéma ZK-proof fonctionne, la validité des transactions peut être garantie par des mathématiques plutôt que de faire confiance à un tiers. L’aspect « connaissance zéro » d’une preuve ZK n’est pas réellement une exigence dans ce cas d’utilisation : il est parfaitement acceptable que la preuve « divulgue » des informations sur ce qu’elle prouve. Il se trouve que la plupart des schémas mathématiques pour cette classe de preuve se trouvent être des preuves à divulgation nulle de connaissance.

Du point de vue de Bitcoin, un schéma de validation rollup nécessite un engagement, car nous voulons être en mesure de créer des UTXO pour le schéma qui ne peuvent être dépensés que si les règles du schéma sont suivies. Ce n'est pas nécessairement un processus décentralisé. De nombreux schémas de validation rollup sont en fait entièrement centralisés ; la preuve de rollup prouve que le séquenceur de transaction centralisé a suivi les règles pour une séquence particulière de transactions.

En ce qui concerne le contrat... La technologie de preuve à divulgation nulle de connaissance est encore un domaine très récent, avec des avancées régulières. Il est donc très peu probable que nous voyions des opcodes ajoutés à Bitcoin qui valideraient directement des schémas de preuve à divulgation nulle de connaissance spécifiques. Au lieu de cela, il est généralement accepté que des schémas spécifiques utiliseraient plutôt des opcodes plus généraux, en particulier OP_CAT, pour valider les preuves à divulgation nulle de connaissance via des scripts. Par exemple, StarkWareestcampagnepour que OP_CAT soit adopté.

Les rollups de validité sont un sujet potentiellement important, avec de nombreux projets de faible substance et de grande hype, que nous ne discuterons pas plus en détail, en dehors de souligner les opcodes qui rendent potentiellement cette classe de conception viable.

BitVM

De manière très approximative, BitVM est un moyen de construire un canal d'éclair entre deux parties de telle sorte que les règles du canal d'éclair soient appliquées par une preuve de connaissance nulle. Comme il n'a pas réellement besoin de covenants pour être implémenté sur Bitcoin aujourd'hui, et parce qu'il ne peut pas être directement utilisé pour créer un système L2 qui évolue au-delà de la limite d'1-UTXO-par-utilisateur, nous n'en discuterons pas davantage.

Canaux hiérarchiques

Canaux hiérarchiques¹⁰vise à rendre le redimensionnement des canaux rapide et bon marché : « Les canaux hiérarchiques font pour la capacité des canaux ce que le LN fait pour le bitcoin ». Cependant, ils ne dépassent toujours pas fondamentalement la limite d'une UTXO par utilisateur. De plus, ils ne nécessitent de toute façon aucune modification du protocole Bitcoin. Nous n'allons donc pas les discuter plus en détail. Leurs défenseurs devraient simplement les mettre en œuvre ! Ils n'ont pas besoin de notre permission.

CoinPool

CoinPool permet à plusieurs utilisateurs de partager un seul UTXO, de transférer des fonds entre différents utilisateurs et de retirer unilatéralement. La proposition de papier CoinPool nécessite trois nouvelles fonctionnalités de softfork, SIGHASH_ANYPREVOUT, un SIGHASH_GROUP permettant à une signature de s'appliquer uniquement à des UTXO spécifiques, et un OP_MerkleSub pour valider la suppression de branches spécifiques d'un arbre de Merkle ; cette dernière pourrait également être réalisée avec OP_CAT.

À l’heure actuelle, le développement de CoinPool semble avoir stagné, le dernier commit sur le site Web de spécification datant d’il y a deux ans.

Réseau Enigma

Alors que l'on m'a demandé de couvrir le réseau Engima, il semble y avoir un manque de documentation sur ce que propose réellement la proposition. Bitfinex’sBillet de blog fait beaucoup de revendications ; le page MIT est vide. Étant donné que le billet de blog ne précise pas clairement ce qui est censé se passer, nous n'en discuterons pas davantage.

Considérations de Mempool

La politique actuelle de mempool dans Bitcoin Core n’est pas idéale pour les systèmes L2. Nous allons passer en revue ici quelques-uns des principaux défis auxquels ils sont confrontés et les améliorations potentielles.

Transaction Pinning

Finalement, une exploitation économique, les attaques de blocage de transaction, font référence à une variété de situations où quelqu'un peut intentionnellement (ou involontairement) rendre difficile l'extraction d'une transaction souhaitée en raison de la diffusion préalable d'une transaction conflictuelle qui n'est pas extraite. Il s'agit d'une exploitation économique, car dans une situation de blocage de transaction réelle, il existe une transaction souhaitable que les mineurs pourraient exploiter s'ils l'exécutaient ; la transaction de blocage conflictuelle n'est pas extraite dans un délai raisonnable, voire jamais.

L’exemple le plus simple d’épinglage vient du fait que sans RBF complet, le remplacement des transactions peut être désactivé. Ainsi, nous pouvons avoir une transaction à faible taux d’honoraires, avec le remplacement désactivé, qui ne sera pas minée mais ne pourra pas être remplacée. Essentiellement, 100% de la puissance de hachage a résolu ce problème en activant le RBF complet, et au moment de la rédaction de cet article, le RBF complet devrait être activé par défaut dans la prochaine version de Bitcoin Core (après 11 années d'effort!).

Cela laisse l’épinglage de la règle BIP-125 #3, le seul problème d’épinglage restant qui est pertinent pour les protocoles L2 multipartites et non résolu dans Bitcoin Core. À titre de référence, la règle #3 du BIP-125 stipule ce qui suit :

Une transaction de remplacement est nécessaire pour payer des frais absolus plus élevés (non

juste le taux des frais) que la somme des frais payés par toutes les transactions remplacées.

Cette règle peut être exploitée en diffusant une transaction d’épinglage importante et à faible taux de frais dépensant la ou les sorties pertinentes pour le protocole multipartite (alternativement, un groupe de transactions). Étant donné que la transaction a un faible taux de frais, elle ne sera pas minée en temps opportun, voire jamais. Pourtant, comme il a des frais totaux élevés, le remplacer par une transaction différente n’est pas rentable.

La règle n°3 est assez facilement corrigée viataux de remplacement par frais, et ce correctif fonctionne dans toutes les situations. Malheureusement, il n’est pas clair si RBFR sera adopté par Core dans un avenir proche, car ils ont consacré beaucoup d’efforts à une solution partielle inférieure. Transactions TRUC/V3.

Paiement des frais: RBF, CPFP, SIGHASH_ANYONECANPAY, Ancres et Parrainage

Étant donné que les taux de frais sont imprévisibles, il est difficile de payer de manière fiable et économique dans les situations où les transactions sont pré-signées. La norme en matière de paiement des frais est d'utiliser RBF, en commençant par une estimation initiale « basse », et de remplacer la transaction par des versions à frais plus élevés si nécessaire jusqu'à ce qu'elle soit confirmée. Par exemple, le logiciel de calendrier OpenTimestamps utilise RBF de cette manière depuis des années, et LND a ajouté une prise en charge pour RBF conscient de la date limite dans v0.18.

RBF est l’étalon-or pour le paiement des frais, car il est le plus efficace dans presque tous les domaines.¹¹situations: les transactions de remplacement n'ont pas besoin d'entrées ou de sorties supplémentaires, par rapport à ce qui aurait été nécessaire si le bon frais avait été deviné dès le premier essai.

L'efficacité est importante, car les inefficacités dans le paiement des frais rendent paiement de frais hors bandeune source rentable de revenus pour les grands mineurs; les mineurs plus petits et décentralisés ne peuvent pas profiter des paiements de frais hors bande en raison de l'impraticabilité et de l'inutilité de payer un petit mineur pour confirmer une transaction. Les paiements de frais hors bande semblent également inviter des problèmes de LMA/CTF : à l'heure actuelle, la plupart des systèmes de paiement de frais hors bande réellement disponibles nécessitent une sorte de processus de LMA/CTF pour effectuer un paiement de frais, à l'exception notable de la mempool.space accélérateur, qui, au moment de la rédaction de cet article (août 2024), accepte Lightning sans compte.

Pour utiliser directement le RBF dans les situations où les transactions sont pré-signées, vous devez pré-signer des variantes de frais couvrant l’ensemble des frais potentiels. Bien que cela soit tout à fait faisable dans de nombreux cas, le nombre de variantes nécessaires est généralement faible¹², jusqu'à présent, le protocole Lightning de production - et d'autres protocoles proposés - ont plutôt choisi d'utiliser L’enfant paie pour les parents (CPFP), généralement via des sorties d’ancrage.

L'idée derrière une sortie d'ancrage est d'ajouter une ou plusieurs sorties à une transaction avec une valeur minimale ou nulle, dans l'intention de payer les frais via CPFP en dépensant ces sorties dans des transactions secondaires. Cela est bien sûr très inefficace lorsqu'il est appliqué à des protocoles tels que LN qui ont de petites transactions sur chaîne, presque...doubler la taille totale d'une transaction d'engagement LN utilisant une sortie d'ancrage éphémère. Ce serait moins préoccupant lorsqu'il s'agit de protocoles utilisant des transactions plus importantes, tels que tout ce qui utilise OP_CAT pour mettre en œuvre des conventions.

Un problème moins évident avec les sorties d'ancre est le besoin de conserver des UTXO supplémentaires pour payer les frais. Dans une application "client" typique, cela peut représenter un fardeau global important, car sans les sorties d'ancre, il n'est souvent pas du tout nécessaire de conserver plus d'un UTXO. En effet, il est probable que certains portefeuilles Lightning existants, axés sur les consommateurs, soient vulnérables au vol par la partie distante du canal dans des environnements à frais élevés en raison de l'incapacité à payer les frais.

SIGHASH_ANYONECANPAY peut être utilisé pour le paiement des frais dans certains cas en permettant d’ajouter des entrées supplémentaires aux transactions signées ; SIGHASH_SINGLE permet également d’ajouter des sorties. Lightning l’utilise pour les transactions HTLC. À l’heure actuelle, cette pratique peut être vulnérable à l’épinglage des transactions si elle n’est pas gérée avec soin¹³, car un attaquant pourrait ajouter un grand nombre d’entrées et/ou de sorties à une transaction pour créer un code PIN à frais élevés/à faible taux de frais. RBFR résout ce problème ; l’approche utilisée dans les transactions TRUC/V3 n’est pas en mesure de résoudre ce problème. Ce mode de paiement des frais n’est pas aussi efficace que le RBF. Mais cela peut être plus efficace que les sorties d’ancrage.

Enfin, il y a eu une variété de propositions de fork-logiciel pour ajouter un parrainage des fraissystème au protocole Bitcoin. Cela permettrait aux transactions de déclarer des dépendances à d'autres transactions, de sorte que la transaction sponsorisée ne pourrait être minée que si la transaction sponsorisée était également minée (probablement dans le même bloc). Cela pourrait être beaucoup plus efficace qu'un CPFP traditionnel car la transaction sponsorisée pourrait déclarer cette dépendance en utilisant significativement moins de vbytes que la taille d'une entrée de transaction.

Remplacement Cyclisme

L'attaque de remplacement de cyclisme¹⁴utilise le remplacement de transaction pour tenter de remplacer une transaction L2 désirée assez longtemps pour que soit minée une transaction non désirée à la place. En substance, les attaques de remplacement cyclique sont, pour l'attaquant, une alternative aux techniques de verrouillage de transaction dans la mesure où elles visent à empêcher qu'une transaction désirée et honnête soit minée suffisamment longtemps pour permettre qu'une transaction non désirée et malhonnête soit minée à la place. Contrairement aux attaques de verrouillage de transaction, une attaque de remplacement cyclique ne peut pas se produire accidentellement.

L'exemple canonique concerne un contrat de verrouillage temporel de hachage (HTLC). Bien qu'il soit facile de considérer un HTLC comme étant un contrat permettant soit d'autoriser une transaction à être dépensée en révélant une préimage, soit en utilisant un délai d'expiration. En réalité, en raison des limitations du script Bitcoin, un HTLC permet à une transaction d'être toujours dépensée en révélant une préimage, puis, après un délai d'expiration, également via le mécanisme de délai d'expiration.

Le remplacement cyclique profite de cela en utilisant l'image avant le délai, pour remplacer la transaction essayant de racheter la sortie HLTC via le mécanisme de délai sans que la victime n'apprenne l'image. Une attaque de remplacement cyclique réussie le fait pendant suffisamment longtemps pour qu'un autre HTLC du canal expire.

Un défi majeur dans l'exploitation rentable du cycle de remplacement est que chaque cycle de remplacement coûte de l'argent. Une implémentation Lightning consciente des délais dépensera des frais de plus en plus élevés en essayant de dépenser la sortie HTLC expirée avant l'expiration de la prochaine sortie HTLC à son tour. Deuxièmement, n'importe qui peut vaincre l'attaque en rediffusant simplement la transaction remplacée¹⁵une fois que le cycle de remplacement est terminé.

Tout comme le verrouillage de transaction, le remplacement cyclique est également une exploitation économique des mineurs. À la fin de chaque cycle de remplacement, il existe une transaction qui a été supprimée des pools de mémoire, mais qui est entièrement valide et pourrait être extraite si les mineurs l'avaient encore dans leurs pools de mémoire.

Modèles de caractéristiques et soft forks

Maintenant que nous vous avons donné un aperçu de la variété des systèmes L2 dépendants des covenants disponibles et des défis de la mempool, nous allons essayer de résumer ces informations à un ensemble de fonctionnalités de soft fork remarquables (principalement de nouveaux opcodes) et de modèles de conception partagés par ces systèmes L2. Pour les propositions de soft fork, nous discuterons également des risques techniques spécifiques à chaque proposition et des défis liés au déploiement de chaque proposition.

OP_Expire

Commençons par là. OP_Expire a été proposé¹⁶ comme un moyen simple d’éliminer l’attaque cyclique de remplacement en réglant le problème à la source : le fait que les HTLC peuvent être dépensés de deux manières différentes à la fois. Dans le contexte des systèmes L2, cela est pertinent pour tout ce qui utilise un mécanisme de type HTLC, et éventuellement d’autres cas d’utilisation. OP_Expire rendrait possible qu’une sortie de transaction ne soit pas dépensable après un certain temps, ce qui permettrait aux conditions de dépenses HTLC d’être un véritable OU exclusif plutôt qu’un « OU des programmeurs ».

Un soft-fork OP_Expire réel consisterait très probablement en deux fonctionnalités, de la même manière que le OP_CheckLockTimeVerifyetOP_CheckSequenceVerifyles opcodes se composent de deux parties:

1. Un champ de hauteur d'expiration pour les transactions, très probablement mis en œuvre dans l'annexe de taproot.
2. Un code OP_Expire qui vérifie que la hauteur d'expiration est définie au moins à la hauteur souhaitée.

Bien que OP_Expire lui-même ne soit guère qualifié comme un pacte, il semble être utile pour de nombreux systèmes L2 dépendants des pactes. Cependant, cela peut ne pas être suffisamment utile étant donné que le remplacement cyclique peut également être atténué par une retransmission altruiste.¹⁵

Un défi très notable avec le déploiement et l’utilisation de OP_Expire est la réorganisation : la communauté technique Bitcoin, à commencer par Satoshi¹⁷a essayé de s'assurer que le protocole de consensus Bitcoin est conçu de manière à ce que, après une réorganisation profonde, les transactions précédemment extraites puissent être extraites dans de nouveaux blocs. Ce principe de conception tente d'éviter le scénario cauchemardesque d'un grand nombre de pièces confirmées devenant définitivement invalides - et donc les personnes qui comptent sur ces pièces perdant de l'argent - si une défaillance du consensus entraîne une grande réorganisation.

Dans le cas d’une réorganisation importante, les transactions utilisant l’expiration peuvent devenir impossibles à miner en raison de leur hauteur d’expiration atteinte. La proposition de OP_Expire propose d’atténuer ce problème en traitant les sorties des transactions utilisant l’expiration de la même manière que les transactions coinbase, ce qui les rend également non dépensables pour ~100 blocs.

Une barrière significative à la mise en œuvre de l'expiration des transactions consiste à parvenir à un consensus sur le fait de savoir si ce compromis est acceptable, voire nécessaire. Les types de transactions pour lesquelles OP_Expire serait utile impliquent déjà des délais relativement longs où les fonds des utilisateurs sont gelés. Ajouter encore plus de temps à ces délais n'est pas souhaitable. De plus, les doubles dépenses ont toujours été un moyen d'annuler les pièces après un réorg : avec l'utilisation croissante de RBF et la proposition d'utiliser des sorties d'ancrage sans clé, l'expiration des transactions ferait-elle une différence significative ?

SIGHASH_ANYPREVOUT

BIP-118propose deux nouveaux modes de hachage de signature, dont aucun ne s'engage à dépenser l'UTXO spécifique. SIGHASH_ANYPREVOUT, qui (essentiellement) s'engage plutôt au scriptPubKey, et SIGHASH_ANYPREVOUTANYSCRIPT, qui permet n'importe quel script. Comme discuté ci-dessus, cela a été initialement proposé pour être utilisé par LN-Symmetry afin d'éviter la nécessité de signer séparément chaque état de canal précédent qui pourrait nécessiter une réaction.

SIGHASH_ANYPREVOUT est également potentiellement utile dans les cas où nous voulons utiliser des variantes de taux de frais RBF pré-signées en conjonction avec des transactions pré-signées, car le fait que la signature ne dépende plus d'un txid spécifique évite unexplosion combinatoire des variantes de taux de frais. Cependant, la proposition BIP-118 actuelle ne traite pas ce cas d'utilisation et peut être incompatible avec celui-ci en raison du fait que SIGHASH_ANYPREVOUT est également proposé pour s'engager à la valeur de l'UTXO.

Une objection initiale à SIGHASH_ANYPREVOUT était l'idée que les portefeuilles se mettraient en difficulté en l'utilisant de manière inappropriée. Le problème est que dès qu'une seule signature SIGHASH_ANYPREVOUT a été publiée, elle peut être utilisée pour dépenser n'importe quel txout avec le script spécifié. Ainsi, si un deuxième sortie avec le même script est créé accidentellement, SIGHASH_ANYPREVOUT permet une attaque de rejeu trivial pour voler ces pièces. Cependant, comme il y a tellement d'autres problèmes inhérents aux portefeuilles et aux implémentations L2, cette préoccupation semble avoir disparu.

Pour l'instant, la communauté technique générale semble raisonnablement positive quant à la mise en œuvre de BIP-118. Cependant, comme discuté ci-dessus dans notre discussion sur LN-Symmetry, il y a un débat sur le fait que son principal cas d'utilisation - LN-Symmetry - est en réalité une bonne idée.

OP_CheckTemplateVerify

Notre première proposition d'opcode spécifique au covenant, OP_CheckTemplateVerify, ou "CTV" comme on l'appelle communément, vise à créer un opcode de covenant très spécifique et restreint en faisant exactement une chose : hacher la transaction de dépense d'une manière spécifiée qui ne s'engage pas vis-à-vis des UTXO d'entrée, et vérifier le digest résultant par rapport à l'élément en haut de la pile. Cela permet de restreindre la transaction de dépense à l'avance, sans rendre possible de vraies restrictions de covenant récursives.

Pourquoi les covenants récursifs ne sont-ils pas possibles dans CTV ? Parce que les fonctions de hachage : le CTV vérifie la transaction de dépense par rapport à un hachage de modèle, et il n'y a aucun moyen¹⁸de créer un modèle contenant un CTV avec un hachage de lui-même.

Cela dit, il ne s’agit pas nécessairement d’une réelle limitation : vous pouvez facilement hacher une chaîne de hachages de modèles CTV à une profondeur de dizaines de millions de transactions en quelques secondes seulement sur un ordinateur moderne. Avec verrous de temps nSequence relatifset la taille de bloc limitée qui atteint en fait la fin d'une telle chaîne pourrait facilement prendre des milliers d'années.

La proposition actuelle de CTV dans BIP-119n'a qu'un seul mode de hachage, connu sous le nom de DefaultCheckTemplateVerifyHash, qui s'engage essentiellement à tous les aspects de la transaction de dépense dans le hachage du modèle. D'un point de vue pratique, cela signifie que dans de nombreuses circonstances, le seul mécanisme disponible pour le paiement des frais sera le CPFP. Comme mentionné ci-dessus, c'est un problème potentiel car cela rend le paiement des frais hors bande non trivial dans les cas où les transactions utilisant CTV sont petites.

On peut dire que CTV bénéficie du soutien le plus large de la communauté technique parmi toutes les propositions d'opcode covenant en raison de sa simplicité relative et de sa large gamme de cas d'utilisation.

LNHANCE

Une proposition pour implémenter CTV consiste à la combiner avec deux autres opcodes, OP_CheckSigFromStack(Verify) et of OP_InternalKey. Le problème est que, au moment de l'écriture, la documentation dans ce pull-req et les BIP associés ne sont tout simplement pas suffisants pour argumenter en faveur ou contre cette proposition. Les BIP manquent complètement de toute justification pour ce que les opcodes sont censés faire réellement dans des exemples concrets, sans parler d'exemples de scripts approfondis.

Bien que les auteurs aient probablement de bonnes raisons pour leur proposition, il leur incombe en fait d'expliquer ces raisons et de les justifier correctement. Ainsi, nous n'en discuterons pas davantage.

OP_TXHASH

Similar to CTV, cette proposition permet d'obtenir une fonctionnalité de contrat non récursif en hashant les données de la transaction de dépense. Contrairement à CTV, la proposition TXHASH offre un mécanisme de « sélecteur de champ », ce qui permet une flexibilité dans la façon dont la transaction de dépense est contrainte. Cette flexibilité permet d'atteindre deux objectifs principaux :

1. Permettre l'ajout de frais à une transaction sans rompre un protocole multi-tx.
2. Des protocoles multi-utilisateurs où les utilisateurs ne contrôlent que leurs propres entrées et sorties.

Le principal problème avec OP_TXHASH est que le mécanisme de sélecteur de champ ajoute beaucoup de complexité, rendant l'examen et les tests difficiles par rapport à la proposition CTV beaucoup plus simple. Pour le moment, il n'y a tout simplement pas eu beaucoup d'analyse de conception sur la façon dont le mécanisme de sélecteur de champ serait réellement bénéfique, ou comment il serait exactement utilisé. Ainsi, nous n'en discuterons pas davantage.

OP_CAT

L’opérateur de concaténation, qui concatène les deux premiers éléments de la pile et repousse le résultat concaténé sur la pile. À l’origine, Bitcoin était livré avec OP_CAT activé. Mais Satoshi l'a discrètement supprimé en 2010, probablement en raison du fait que la mise en œuvre initiale était vulnérable aux attaques DoS en raison du manque de restrictions sur la taille de l'élément de script résultant. Considérez le script suivant:

DUP CHAT DUP CHAT…

Sans restriction de taille d'élément, chaque itération DUP CAT double la taille de l'élément de pile supérieur, utilisant éventuellement toute la mémoire disponible.

La concaténation est suffisante pour implémenter de nombreux types de covenants, y compris les covenants récursifs, en faisant ce qui suit:

1. Assembler une transaction partielle, sans données de témoin, sur la pile avec une ou plusieurs invocations de OP_CAT (et toute logique spécifique au covenant est nécessaire).
2. Valider que la transaction sur la pile correspond à la transaction de dépense.

Il s'avère que, parabusant des mathématiques des signatures de Schnorr, il est possible d'effectuer la deuxième étape avec OP_CheckSig via des signatures soigneusement construites. Cependant, il est plus probable qu'un soft-fork OP_CAT serait combiné avec OP_CheckSigFromStack, permettant à la deuxième étape d'être effectuée en validant qu'une signature sur la pile est une signature valide pour la transaction¹⁹, puis réutiliser cette même signature avec OP_CheckSig pour valider que la transaction de dépense correspond.²⁰

Le fait que nous devons seulement assembler la transaction sans les données de témoin est un point clé: le covenant doit seulement valider ce que la transaction fait - ses entrées et sorties - pas les données de témoin (s'il y en a) qui la rendent effectivement valide.

En limitant la taille du script modulo, la combinaison de OP_CAT et OP_CheckSigFromStack est suffisante pour construire de nombreux types de covenants, y compris des covenants récursifs. Comparé à des solutions plus efficaces telles que CTV, c'est plus cher. Mais la différence de coût est moins importante que ce à quoi vous vous attendriez!

En gros, utiliser OP_CAT pour faire cela nécessite que toutes les parties non témoins de la transaction de dépense soient placées sur la pile via le témoin. Pour des cas d'utilisation CTV typiques tels que les arbres de txout, la transaction de dépense n'aura pas du tout de données de témoin. Étant donné que l'espace de témoin est réduit de 75%, cela augmente notre frais de transaction effectif pour la transaction enfant de seulement 25%. Pas mal!

OP_CAT est-il trop puissant?

C'est probablement le plus grand obstacle politique et technique au déploiement de OP_CAT: il est très difficile de prévoir les cas d'utilisation rendus possibles par OP_CAT. Et une fois que le "chat" est sorti du sac, il est très difficile de le remettre dedans.

Un excellent exemple est la prétendue suffisance d'OP_CAT pour permettre une efficacité et une sécurité raisonnablement efficaces Vérification STARK à mettre en œuvre dans le script Bitcoin. Étant donné que les STARK sont capables de prouver des énoncés extrêmement généraux, rendant ainsi possible de mettre en œuvre efficacement les STARK, cela a des ramifications significatives qui vont au-delà de la portée des systèmes L2, car cela permettrait à de nombreux systèmes différents d'être construits sur Bitcoin. Un argument solide contre OP_CAT est que ces cas d'utilisation pourraient ne pas être totalement bénéfiques pour les utilisateurs de Bitcoin.

La création de la valeur extractible par les mineurs centralisateurs nocifs est un problème potentiel clé, appelé "MEV qui est evIL" (MEVil)par Matt Corallo. En bref, le MEVil est toute situation dans laquelle les gros mineurs/pools peuvent extraire une valeur supplémentaire en utilisant des stratégies avancées de minage de transactions - au-delà de la simple maximisation des frais totaux - qui sont impraticables pour les mineurs/pools plus petits. La complexité des instruments financiers potentiels pouvant être créés avec OP_CAT rend très difficile l'élimination du MEVil. Une MEVil significative est déjà apparue sur Bitcoin à partir de protocoles d'enchères de jetons; heureusement, ce cas spécifique a été vaincu grâce à l'adoption de la pleine RBF.

En plus du potentiel de MEVil, il existe de nombreux autres cas d'utilisation concrets d'OP_CAT qui sont potentiellement nuisibles. Par exemple, la proposition Drivechains a été chroniqué ici, et est largement considéré comme nuisible à Bitcoin. C'est censé être possiblepour mettre en œuvre Drivechain avec OP_CAT. Un autre exemple est les propositions de jetons comme les actifs Taproot. Bien qu'il soit impossible en général de les empêcher d'être mis en œuvre avec validation côté client, il existe des propositions visant à les mettre en œuvre avec OP_CAT de manière potentiellement beaucoup plus attrayante pour les utilisateurs finaux, tout en utilisant beaucoup plus d'espace de bloc, ce qui pourrait potentiellement surenchérir sur les transactions Bitcoin « légitimes ». Ces cas d'utilisation peuvent également soulever des problèmes juridiques en raison de la fréquence à laquelle les protocoles de jetons sont utilisés pour la fraude financière.

Hachage incrémental

Pour les covenants, OP_CAT serait principalement utilisé pour concaténer des données, puis les hacher. Une autre façon d'atteindre le même objectif est d'utiliser un type d'opcode de hachage incrémental qui prend un état intermédiaire SHA256 de quelque sorte, et hache davantage de données dedans ; SHA256 lui-même fonctionne sur des blocs de 64 octets. Il existe de nombreux designs possibles pour les opcodes de hachage incrémental.

Une décision de conception importante consiste à savoir s'il faut ou non exposer les octets d'état intermédiaire réels sur la pile sous une forme canonique, ou les représenter sous une nouvelle forme de type d'élément de pile opaque dont la valeur réelle en octets ne peut pas être directement manipulée. SHA256 est spécifié pour un vecteur d'initialisation particulier et fixe, et il semble inconnu si les propriétés cryptographiques de SHA256 sont vraies si des états intermédiaires/vecteurs d'initialisation arbitraires sont autorisés.

Bien sûr, étant donné que le hachage incrémental peut faire à peu près ce que OP_CAT peut faire, mais de manière plus efficace, il partage toutes les préoccupations concernant la trop grande puissance de OP_CAT.

Renaissance du script

OP_CAT était l'un des 15 opcodes que Satoshi a désactivés. En plus de restaurer OP_CAT, Rusty Russell propose²¹pour essentiellement restaurer le script Bitcoin à la «Vision originale de Satoshi» en réactivant la plupart de ces opcodes, en ajoutant des limites DoS et potentiellement en ajoutant quelques autres dans le même soft-fork. En particulier, un OP_CheckSigFromStack est probablement.

Bien que OP_CAT seul rende possible l’existence de clauses restrictives (récursives), une « renaissance complète du script » rendrait possibles des clauses plus sophistiquées – et beaucoup plus faciles à mettre en œuvre – car certaines parties de la transaction de dépenses pourraient être manipulées directement. Par exemple, vous pouvez imaginer un script covenant qui utilise des opcodes arithmétiques pour s’assurer que la valeur totale des txouts dans la transaction adhère à une propriété souhaitée.

Encore une fois, le renouveau du scénario soulève les mêmes préoccupations, et plus encore, sur le fait d’être trop puissant que OP_CAT seul.

Simplicité

Similaire à Script Revival, Simplicity est pertinent pour les L2 et les covenants en rendant possible de faire n'importe quoi. Contrairement à Script Revival, une soft-fork Simplicity ajouterait un tout nouveau langage de programmation au système de script de Bitcoin basé sur neuf opérateurs primitifs connus sous le nom de combinateurs.

En pratique, la Simplicité est à la fois trop simple et pas du tout simple. Les combinateurs primitifs sont d'un niveau ridiculement bas, si bien que des opérations de base comme l'addition doivent être laborieusement implémentées à partir de zéro ; la Simplicité brute serait exceptionnellement verbeuse en pratique. Ainsi, toute utilisation réelle de la Simplicité ferait appel à un système de substitutions de code, similaire à des appels de fonctions de bibliothèque, connu sous le nom de jets. Cela pose un problème pratique/politique: comment décider quelles jetons implémenter? Il est fort probable que les jetons soient implémentés en C++, comme tout autre opcode, nécessitant une bifurcation douce pour chaque nouveau jeton.

OP_FancyTreeManipulationStuff

Il existe une grande variété d’opcodes relativement spécialisés qui ont été proposés pour faire de la manipulation d’arbres d’une manière efficace dans l’espace pour les propositions L2 dépendantes des covenants. Par exemple, les Coinpools ont proposé à la fois TAPLEAF_UPDATE_VERIFYetOP_MERKLESUB, tous deux manipulent les arbres taproot de manière nécessaire pour la proposition Coinpools, et le MATTLa proposition a proposé un code opérationnel OP_CheckContractVerify qui, fondamentalement, vérifie les déclarations concernant les arbres de Merkle.

Dans le cadre de cet article, nous n'avons pas besoin d'entrer dans les détails de chacune de ces nombreuses propositions. Au lieu de cela, nous pouvons en parler comme d'un groupe : ce sont toutes des propositions relativement spécifiques à un cas d'utilisation qui rendent une classe de L2 possible, idéalement sans effets secondaires indésirables. Ils ont tous l'avantage de l'efficacité : ils utilisent tous moins d'espace de bloc que l'obtention du même objectif avec des opcodes plus génériques tels que la manipulation OP_CAT. Mais ils ont tous l'inconvénient d'ajouter de la complexité au système de script, pour un cas d'utilisation potentiellement de niche.

Le même dynamisme se produirait si Bitcoin adoptait le système de script Simplicity. L'équivalent des opcodes dans Simplicity consiste à ajouter un jet pour un motif couramment utilisé. Encore une fois, la mise en œuvre de jets pour des opérations spécifiques à un cas d'utilisation comme la manipulation d'arbres présente des avantages et des inconvénients similaires à la mise en œuvre d'opcodes complexes pour des opérations spécifiques à un cas d'utilisation.

Fonds de Pools

Tous les systèmes de couche 2 qui tentent de faire en sorte que plusieurs utilisateurs partagent un seul UTXO peuvent être considérés comme une sorte de pool de fonds multi-utilisateurs, les utilisateurs étant en possession d'un certain droit de retrait. Potentiellement, il y aura également un mécanisme pour ajouter des fonds au pool (au-delà de la création du pool avec des fonds préassignés).

Pour qu'un pool de fonds soit utile, il doit être associé à une sorte d'état de partage de données : comment la valeur de txout est-elle répartie ? Si le pool de fonds doit évoluer au fil du temps, cet état doit également changer à mesure que des fonds sont ajoutés ou retirés du pool. Comme nous construisons sur Bitcoin, l'ajout ou le retrait de fonds du pool impliquera inévitablement de dépenser l'UTXO que le pool contrôle.

Rappelez-vous que le système de consensus Bitcoin lui-même est basé sur la validation des changements d'état: les transactions prouvent via leurs témoins que les changements apportés à l'état de l'ensemble UTXO sont valides; la preuve de travail nous permet de parvenir à un consensus sur l'ensemble de transactions correct. Cela signifie que les pools de fonds seront eux-mêmes également basés sur la validation des changements d'état: nous prouvons à chaque nœud Bitcoin que les règles du pool de fonds sont suivies à chaque changement d'état.

Mais il y a un autre aspect clé des pools de fonds L2 sans confiance : lorsque l'état du pool de fonds change, le système doit publier intrinsèquement suffisamment de données pour que les utilisateurs participant au pool de fonds puissent récupérer leurs fonds. Si nous ne l'avons pas fait, alors notre système ne fournit pas de retrait unilatéral, sans la coopération de tiers. De nombreux schémas basés sur Rollup échouent ici : ils souffrent de pannes de disponibilité de données, où l'utilisateur est incapable de récupérer ses fonds si les coordinateurs tiers sont hors ligne, car ils n'ont aucun moyen d'obtenir les données nécessaires pour construire une transaction de récupération de fonds valide.

Avec ces contraintes à l'esprit, sur quelles structures de données les pools de fonds vont-ils être basés? Inévitablement, ce sont tous une sorte d'arbre. Plus précisément, une sorte d'arbre de Merkle. Ils doivent être un arbre, car c'est à peu près la seule structure de données évolutive en informatique; ils doivent être merkelisés, car c'est fondamentalement la seule façon raisonnable de s'engager cryptographiquement à l'état de l'arbre. Enfin, les mises à jour de l'arbre seront inévitablement publiées sur la blockchain Bitcoin, car c'est la seulemoyen de publicationtous les utilisateurs de la couche 2 partagent, et le seul sur lequel nous pouvons contraindre les utilisateurs à publier pour déplacer des pièces. Et parce que toute mise en œuvre de convenant aura besoin de parties de l'arbre pour valider que les règles du convenant sont respectées.

Alors, avec la théorie de haut niveau réglée, comment cela se traduit-il réellement en scripts et transactions Bitcoin ?

Transactions individuelles pré-signées

Le cas dégénéré d’un arbre, avec exactement une feuille à l’intérieur. Ici, l’état de notre pool de fonds peut changer d’état, grosso modo, une fois. Par exemple, un canal Lightning standard entre dans cette catégorie et, une fois ouvert, ne peut être que fermé. Les données publiées lorsqu’un canal est fermé sont la transaction elle-même, ce qui constitue une information suffisante pour que la contrepartie du canal apprenne le txid à partir des données de la blockchain et récupère ses fonds en les dépensant.

Le seul «pacte» requis ici est le pacte le plus fondamental : la transaction pré-signée.

Arbres de Txout

Le motif de conception suivant, plus complexe, que nous voyons dans les pools de fonds est l'arbre txout. Ark en est un exemple notable. Ici, le pool de fonds peut être divisé en dépensant l'UTXO racine dans un arbre de transactions prédéfinies, appliqué avec des engagements simples tels que des transactions pré-signées ou CTV, divisant la valeur de cet UTXO en des montants de plus en plus petits jusqu'à ce que des nœuds feuilles soient atteints et puissent être dépensés par les propriétaires légitimes.

Il est important de reconnaître que le but de l'arbre des txout est de donner aux utilisateurs des options pour récupérer leurs fonds, et ces options ont un coût : un arbre des txout sera toujours un moyen plus coûteux de diviser un pool de fonds et de les retourner à leurs propriétaires que de simplement diviser les UTXO dans une seule transaction. Chaque couche de l'arbre ajoute un coût en raison des octets utilisés dans les txouts et txins nécessaires pour créer cette couche.

Alors, quelles options un arbre de txout pourrait-il offrir ? Encore une fois, Ark est un excellent exemple : nous ne voulons pas que le rachat on-chain d'un seul V-UTXO nécessite que chaque V-UTXO soit mis sur la chaîne. En utilisant un arbre, le rachat peut plutôt diviser l'arbre en parties plus petites jusqu'à ce que le V-UTXO souhaité soit mis sur la chaîne.

Tout comme dans le cas d'une transaction individuelle pré-signée, les informations publiées sont les transactions elles-mêmes, qui permettent au portefeuille d'autres utilisateurs de savoir comment dépenser leurs fonds si nécessaire.

L’évolutivité des arbres txout permet de réaliser des économies d’échelle intéressantes. Le coût pour que le premier V-UTXO soit mis sur la chaîne, dans un pool de fonds avec n V-UTXO, est à peu près log2(n)log2(n) fois plus cher qu’une seule transaction, car les niveaux log2(n) des transactions fractionnées doivent être mis sur la chaîne. Cependant, une fois que le premier V-UTXO est mis sur la chaîne, les V-UTXO suivants deviennent moins chers à racheter sur la chaîne parce que quelqu’un d’autre a déjà payé le coût de l’extraction des transactions intermédiaires.

Rappelez-vous que le nombre total d'éléments dans un arbre binaire avec

n feuilles est 2n. Cela signifie que pour mettre tous les V-UTXO sur la chaîne, le coût total pour le faire via un arbre txout serait un petit multiple du coût total pour le faire dans une seule transaction. Étonnamment efficace!

Ou peut-être pas... Si la taille totale des rachats du fonds est suffisamment élevée, ils peuvent représenter une demande non négligeable sur l'ensemble de l'espace de bloc. L'espace de bloc est un système d'offre et de demande, donc à un moment donné, les frais augmenteront en raison d'une forte demande. À l'extrême, il est tout à fait possible de créer des arbres de txout si grands et si profonds qu'il est en fait possible de racheter chaque

V-UTXO dans l'arbre est impossible.

Une question ouverte concernant les arbres txout est de savoir qui paie les frais, et comment ? Une solution évidente consiste à utiliser des sorties d'ancrage sans clé sur les transactions feuilles, et permettre à quiconque souhaite que les transactions feuilles soient extraites de payer les frais via CPFP. Dans certains cas d'utilisation, les V-UTXO eux-mêmes peuvent être dépensés immédiatement après leur création, sans délai CSV, de sorte que les V-UTXO eux-mêmes pourraient être dépensés pour ajouter des frais via CPFP.

La mise en œuvre de RBF est complexe en raison des autorisations : l'endroit évident pour prendre des frais pour RBF est la valeur V-UTXO. Mais comment garantir que seul le propriétaire a la possibilité de signer une transaction à frais plus élevés ? Dans de nombreuses circonstances, il n'est pas évident de le faire de manière plus efficace qu'une sortie d'ancrage sans clé. Cependant, ne pas le faire pose de sérieux défis pour les schémas utilisés par les portefeuilles d'utilisateurs finaux, qui peuvent ne pas avoir de UTXO à dépenser pour effectuer une CPFP, si les V-UTXO eux-mêmes ne peuvent pas être dépensés immédiatement.

Enfin, il faut réfléchir attentivement aux incitations dans les systèmes d'arbres txout, en tenant compte du paiement des frais. Par exemple, dans un système de type Ark, si un ensemble de V-UTXO coûte individuellement trop cher pour être récupéré en dehors de la chaîne, un coordinateur peu coopératif pourrait refuser de permettre le rachat de ces V-UTXO hors chaîne, puis réaliser un profit en volant la valeur de ces V-UTXO dans une seule transaction UTXO une fois qu'un délai est atteint.

Si tel est le cas, on peut soutenir que ce système ne répondrait pas à nos critères pour être considéré comme un L2 pour les petits V-UTXO.

Schémas basés sur l'équilibre

La machine à états d'un arbre txout est encore relativement simple : soit le fonds existe, soit il est dépensé pour créer deux ou plusieurs fonds plus petits. Avec des engagements plus avancés, nous pourrions plutôt traiter le fonds comme un solde évolutif, avec la capacité d'ajouter et de soustraire des fonds à ce solde.

Pour ce faire, nous devons implémenter une machine à états non triviale. Mais nous avons également besoin de ce qui est essentiellement une base de données partagée. Pourquoi? Parce que l’objectif ici est de partager un UTXO entre de nombreux propriétaires différents. Enfin, si nous voulons réellement obtenir une amélioration de l’évolutivité, nous devons le faire d’une manière qui met le moins possible de ces données de propriété sur la chaîne.

Ces exigences nous conduisent intrinsèquement à une sorte de structure de données merkélisée en forme d’arbre, telle qu’un arbre de somme de Merkle. La manipulation de cette structure de données va intrinsèquement nécessiter quelque chose comme OP_CAT, une sorte d’opcode de vérification de preuve à divulgation nulle de connaissance, ou un opcode de manipulation d’arborescence spécifique à l’objectif.

Il est intéressant de noter que, comme dans les arbres txout, vous ne pouvez pas faire mieux que la mise à l’échelle de l’ordre log(n) tout en conservant des propriétés de sécurité similaires. Pourquoi? Supposons que nous ayons un OP_ZKP hypothétique qui, grâce à des mathématiques avancées, n’a besoin que de 32 octets pour prouver une affirmation. Bien que cette preuve zk puisse prouver que la structure de données merkelisée a été manipulée selon les règles du système de couche 2, elle ne fournirait pas les données nécessaires pour que l’utilisateur suivant effectue également un changement d’état. Cela ne répond pas à nos critères préférés d’activation du retrait inconditionnel : au mieux, un utilisateur pourrait être en mesure d’obtenir un retrait inconditionnel. Mais aucun autre utilisateur n’a pu le faire.

En revanche, si les parties modifiées de la structure de données merklisée sont publiées via le scriptsig du covenant - par exemple, les empreintes de frères dans un arbre de Merkle - le prochain utilisateur dispose de suffisamment de données pour mettre à jour sa compréhension de l'état du système et effectuer lui-même un retrait inconditionnel.

Un moyen potentiel de contourner ce problème serait si le pacte exige une preuve de publication sur un support de publication différent de la chaîne Bitcoin. Cependant, les garanties de sécurité seront moins solides que ce qui est possible via Bitcoin.

Enfin, remarquez comment les arbres txout et une approche basée sur l'équilibre peuvent être combinés. Si la structure de données manipulée est un arbre txout, des fonds pourraient être ajoutés à l'arbre txout en dépensant la sortie et en ajoutant de nouveaux fonds, avec un script de convention qui valide que les fonds ont effectivement été ajoutés à l'arbre txout. De même, les fonds peuvent être supprimés par tous les mécanismes normalement disponibles pour un arbre txout. Advanced Ark est un exemple de cette classe de schéma.

Ratio de données d'échec

Les L2 parviennent à mettre à l'échelle en ajoutant une exigence d'interactivité dans des situations adverses. Dans presque tous les cas, cela signifie que les parties honnêtes du protocole ont des délais à respecter pour que leurs transactions soient validées ; si les délais ne sont pas respectés, les fonds peuvent être volés.

La capacité maximale de bloc dans toutes les blockchains décentralisées (et centralisées) est limitée par des contraintes techniques. Dans Bitcoin, la taille maximale du bloc est telle que Bitcoin fonctionne essentiellement à pleine capacité ~100% du temps. Comme l'exploitation minière de Bitcoin agit comme un système d'enchères, mettant aux enchères des espaces de bloc au plus offrant, en pratique, cela signifie que le taux de frais minimum pour faire traiter une transaction augmente et diminue en fonction de la demande.

Le taux de commission est toujours pris en compte dans l'économie de la couche 2 et les modes de défaillance. Par exemple, dans Lightning, les HTLC de taille "poussière" qui sont trop petits pour être rentablement rachetés sur la chaîne utilisent un modèle de sécurité différent des HTLC plus importants. Bien que le protocole Lightning n'implémente pas encore correctement cela, en théorie, ce seuil devrait être dynamique, en fonction des taux de commission à la hausse et à la baisse, idéalement jusqu'au point où une partie pourrait choisir si oui ou non un HTLC existe même dans une transaction d'engagement donnée en fonction du taux de commission.

Une variété d'attaques ont été proposées où cette situation est intentionnellement déclenchée sur Lightning, comme l'inondation et le pillage²² et l’attaque de sortie de masse²³. Étant donné que la capacité de la blockchain Bitcoin est partagée entre tous les cas d'utilisation, des attaques entre différents systèmes de couche 2 sont également possibles : par exemple déclencher une sortie massive sur Ark pour profiter des canaux Lightning.

Les L2 qui partagent des UTXO entre plusieurs utilisateurs rendent ces problèmes potentiellement plus graves, car la demande d'espace de bloc en cas de défaillance est proportionnellement plus élevée. À l'heure actuelle, nous n'avons jamais réellement observé de défaillances à grande échelle sur Lightning où un grand nombre de canaux ont dû être fermés simultanément. Il est valable de dire que nous devrions acquérir une expérience opérationnelle supplémentaire avec Lightning et son passage à environ 1 UTXO par utilisateur, avant de repousser encore plus les limites avec des schémas de partage d'UTXO.

Deuxièmement, avant que de nouveaux systèmes de partage UTXO ne soient largement adoptés, des recherches minutieuses doivent être menées sur la rentabilité potentielle des attaques en cas de forte demande d’espace de bloc. Par exemple, dans un système comme Ark où l’ASP peut racheter des fonds en utilisant beaucoup moins d’espace de blocage que les autres parties, il se peut que le déclenchement intentionnel de taux de frais élevés, puis la saisie de fonds qui ne peuvent pas être retirés unilatéralement de manière rentable soit une fraude rentable, violant nos deux conditions pour un véritable système L2.

Nettoyage du consensus

Il y a plusieurs choses que Satoshi a mal faites dans le protocole initial de Bitcoin, en particulier les attaques DoS de scripting, l'attaque timewarp et les problèmes avec l'arbre de Merkle. Auparavant, un certain nombre d'autres bogues de consensus ont déjà été corrigés avec des fork doux, tels que le passage à l'évaluation des nLockTime basés sur le temps par rapport au temps médian écoulé, (tentative de) corriger le problème de txid en double, etc.

Le plus récent soft-fork, Taproot, a eu un processus de déploiement relativement controversé, prenant un temps assez long pour être effectivement déployé. Un argument en faveur de la réalisation d'un soft-fork de nettoyage de consensus en premier, avant d'activer de nouveaux opcodes ou d'autres fonctionnalités pour les nouveaux types de L2, est que nous en apprendrions davantage sur la volonté de la communauté plus large de mettre en œuvre ce qui devrait être un soft-fork relativement non controversé et qui profite à tout le monde.

Test de dépendance des L2s à Soft-Fork

Les développeurs n’ont pas besoin d’attendre qu’un soft-fork se produise pour tester leurs idées. Une approche particulièrement sophistiquée utilisée par les développeurs d’Ark dans Ark sans alliance est de simuler les engagements dont ils ont besoin avec des transactions pré-signées. Cela leur permet de tester les idées d’Ark avec de vrais BTC, sur le réseau principal, avec les mêmes caractéristiques de confiance, que celles qu’Ark est censé atteindre avec les covenants. La contrepartie est qu’Ark sans engagement exige que toutes les parties soient en ligne pour signer les transactions pré-signées. Étant donné que clArk fonctionne avec de vrais BTC, il peut même s’avérer suffisamment utile pour être utilisé en production pour certains cas d’utilisation qui peuvent tolérer le compromis d’interactivité.

Une approche plus simple consiste simplement à faire semblant que certaines parties ne peuvent pas effectuer les actions que les conventions empêcherait. Par exemple, si un protocole proposé souhaite utiliser CTV pour faire respecter le fait qu'un arbre txout est dépensé dans un arbre de transaction, chaque utilisation de CTV pourrait être remplacée par un NOP ou CheckSig. Bien que dans la réalité, l'arbre txout n'est pas effectivement appliqué, chaque morceau de code interagissant avec l'arbre et chaque partie peut être testé comme s'il l'était, et puisque NOP et CheckSig sont autorisés dans les scripts standard, le protocole peut être testé sur mainnet avec de vrais fonds.

Soft-forks potentiels

Quel est le chemin à suivre? Ici, nous allons tracer toutes les principales stratégies de couche 2 que nous avons analysées, et les soft-forks qui sont utiles (U) ou nécessaires (R) pour rendre ces schémas de couche 2 réussis. Comme discuté ci-dessus, OP_CAT (et par extension, Script Revival, qui inclut OP_CAT), peut émuler tous les autres soft-forks de cette liste, à l'exception de OP_Expire et Fee Sponsorship, donc si les besoins d'un projet sont les mieux satisfaits par un autre soft-fork directement, nous n'inclurons pas OP_CAT.

Nous allons également laisser de côté tous les opcodes de manipulation de l’arbre de Merkle proposés. Ils sont tous trop spécialisés, trop spécifiques à des cas d’utilisation, pour avoir une chance significative d’être adoptés à l’heure actuelle. Dans la mesure où ces opcodes sont utiles, l’implémentation de leurs effets via OP_CAT et/ou Script Revival est une voie beaucoup plus probable vers l’adoption.

CTV est le grand gagnant ici, suivi de SIGHASH_ANYPREVOUT (OP_Expire est utile à de nombreuses choses en étant une correction cyclique de remplacement, mais pas essentiel). CTV l'emporte car tant de choses s'inscrivent dans le modèle de conception de "s'assurer que la transaction de dépense correspond à ce modèle"; même les constructions OP_CAT peuvent efficacement utiliser CTV.

Contrairement à OP_CAT, CTV ne semble pas présenter beaucoup de risques de conséquences involontaires, sauf en encourageant les paiements de frais hors bande dans certains cas. Ce n'est pas idéal. Mais personne n'a proposé une alternative largement soutenue.

Ma recommandation personnelle : faire un soft-fork de nettoyage consensuel, suivi de CTV.

Démenti:

1. Cet article est reproduit à partir de [petertodd], Transmettez le titre original 'Le feuille de route d'Ethereum est-elle hors piste ?', Tous les droits d'auteur appartiennent à l'auteur original [petertodd]. Si des objections sont soulevées à cette reproduction, veuillez contacter le Gate Apprendrel'équipe, et ils s'en occuperont rapidement.

2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.