Titre original : « Le véritable potentiel du RVB » Auteur original : A Jian

Cet article tente de fournir une description concise de RGB, un protocole d'émission d'actifs sur Bitcoin (il peut également être compris comme un système de contrat intelligent hors chaîne), et souligne qu'il est très différent des autres protocoles qui visent le même objectif. ou des fonctions similaires. Ces différences rendent le protocole RVB beaucoup plus évolutif qu'eux et laissent un espace de programmation plus large. En plus de présenter les conceptions terminées de RGB, nous explorerons également ces possibilités de programmation1.

Qu'est-ce que le protocole RVB ?

L'idée d'émettre des actifs sur Bitcoin existe depuis longtemps 2 3 . Mais le protocole Bitcoin a ses propres caractéristiques 4 : son état est exprimé par et uniquement Bitcoin UTXO (« unspent transaction output ») ; un UTXO ne transporte que deux données : sa propre dénomination (valeur Bitcoin), et une « clé publique de script » ( également appelé « script de verrouillage »), utilisé pour programmer les conditions de dépense des fonds, par exemple : fournir une signature d'une certaine clé publique, l'opcode qui permet la programmation du script de verrouillage est déterminé par le consensus Bitcoin. Des règles sont fournies ; ; ils ne peuvent pas être utilisés pour mettre en œuvre des règles de sécurité arbitraires. Par conséquent, il est impossible de créer d’autres actifs dans UTXO – les scripts Bitcoin ne peuvent pas programmer de contrôles de sécurité pour ces actifs. Cela signifie que toutes les idées d’émission d’actifs sur Bitcoin sont essentiellement des utilisations créatives de l’espace de bloc Bitcoin. Cela signifie que nous devons concevoir un système de contrat intelligent hors chaîne et exiger des informations sur les étapes qui modifient l'état du contrat : par exemple, le contrat A modifie les paramètres et B transfère une certaine quantité d'un actif à C. , afin que le dernier statut de ce système de contrat intelligent puisse être obtenu en collectant ces informations.

Une idée de conception approximative consiste à télécharger intactes les informations sur les étapes qui modifient le statut du contrat sur la blockchain Bitcoin. Cela peut certainement fonctionner, mais cela posera plusieurs problèmes : (1) Étant donné que des informations complètes sont téléchargées, elles peuvent consommer plus d'espace de bloc lorsque l'utilisateur doit modifier le statut du contrat (comme un transfert). À ce stade, vous devrez également devez payer plus de frais de traitement en chaîne. En particulier, lorsque nous espérons qu'un tel système de contrat hors chaîne aura une meilleure programmabilité que Bitcoin, l'augmentation de la programmabilité peut se faire au détriment de la consommation de plus d'espace de bloc (2) Presque toutes les transactions au sein du bloc. Les informations en un seul endroit peuvent changer ; les contrats intelligents en dehors de la chaîne, les utilisateurs doivent donc obtenir tous les numéros de bloc Bitcoin. Selon les données, nous pouvons obtenir le dernier statut de ce système de contrat intelligent hors chaîne, c'est-à-dire que son coût de vérification est plus élevé (3) Selon la conception du système de contrat intelligent hors chaîne, nous ne pourrons peut-être que ; obtenir la même confidentialité que Bitcoin, voire pire, et si plus de confidentialité peut être fournie, plus d'espace de bloc peut être consommé 5.

Dans le passé, un protocole largement utilisé appelé « Omni » ne téléchargeait pas des informations complètes sur les transactions contractuelles hors chaîne, mais uniquement la valeur de hachage de la transaction. Cette approche résout le problème 1 ci-dessus et dissocie la complexité des transactions contractuelles hors chaîne de ses coûts économiques. Toutefois, les utilisateurs doivent toujours obtenir la quantité totale de données de bloc Bitcoin pour obtenir le dernier statut du protocole Omni ; Il n'y a pas d'amélioration spécifique de la confidentialité.

RGB utilise un nouveau paradigme appelé « sceaux à usage unique ». Son utilisation est très simple : RGB exige que chaque état de chaque contrat soit attaché à un certain Bitcoin UTXO et une fois que vous souhaitez changer cet état, vous devez dépenser cet UTXO et laisser la transaction qui le dépense obtenir la confirmation de la blockchain ; De plus, la transaction Bitcoin qui la dépense doit également fournir un hachage du contenu de la transition d'état, indiquant l'UTXO attaché au changement d'état.

Pour les développeurs RVB, le design est similaire à un sceau en plastique numéroté : il est facile de savoir s'il a été retiré, et une fois retiré, il ne peut plus être réutilisé. Cependant, une autre perspective est de considérer l'UTXO possédé comme un conteneur dans cet état ou une tirelire en céramique - si vous voulez retirer l'argent de la tirelire, vous devez casser la tirelire puis mettre le contenu à l'intérieur. Mettez l'argent dans le nouveau pot.

Cette conception contraste fortement avec les protocoles précédents qui traitaient l'ensemble du bloc comme un grand tableau d'écriture : utiliser UTXO comme conteneur signifie que les transactions qui ne dépensent pas cet UTXO ne peuvent avoir aucun impact sur le statut du contrat dans le conteneur. un certain état d'un certain contrat, nous n'avons pas besoin d'obtenir les données de tous les blocs, tout ce dont nous avons besoin est une série de transactions Bitcoin, la preuve que ces transactions Bitcoin existent dans un certain bloc, et ces bits RVB promis par l'échange de pièces. Transition d’état (paire un à un avec les transactions Bitcoin associées), c’est tout. Ces données, qui peuvent être reliées en chaîne, doivent permettre de remonter à l'état initial de ce contrat, permettant d'identifier l'essence de cet état.

Pour les lecteurs familiers avec les systèmes de contrats intelligents en chaîne (comme Ethereum), une chose difficile à comprendre dans ce processus est que s'il ne repose pas sur le consensus de la blockchain (ce qui signifie que l'état initial du contrat et chaque changement d'état sera vérifié par chaque nœud), comment la sécurité de ce système de contrat intelligent est-elle garantie ? Comment garantir que les actifs que vous recevez sont ceux que vous souhaitez et comment garantir que les actifs n’ont pas été émis illégalement ?

La réponse est également très simple, elle s'appelle "validation côté client" - vous la vérifiez vous-même. Dans le système de contrat en chaîne, les nœuds vérifient chaque opération de transition d'état conformément aux règles publiques de transition d'état, rejettent les opérations non valides, puis calculent le dernier état en fonction de l'état initial. Cependant, tant que les règles de transition d'état et l'état initial sont connus, la vérification par consensus en chaîne n'est pas le seul moyen pour les utilisateurs de vérifier si chaque étape de la transition d'état suit la transition d'état initialement définie sur la base des informations fournies par. la règle du payeur. De cette manière, la partie vérificatrice (supposée être le destinataire de l'actif) peut également détecter les transitions d'état illégales et refuser de les accepter.

Enfin, nous utilisons un exemple pour démontrer les caractéristiques du protocole RGB :

Désormais, Alice possède UTXO A, qui détient X unités de l'actif Y émises selon le protocole RGB. Elle souhaite transférer Z unités de Y à Bob. Ce lot d'actifs est passé par un total de 5 propriétaires précédents (y compris l'émetteur de l'actif) avant d'arriver entre les mains d'Alice. Par conséquent, Alice doit fournir à Bob la preuve de ces quatre transitions d'état (dont les trois premières ont été fournies à Alice par le propriétaire précédent), y compris l'état initial du contrat et les règles de transition d'état, ainsi que les bits utilisés pour chaque transfert. Les transactions Bitcoin, les transactions RVB engagées par chaque échange Bitcoin et la preuve que ces transactions Bitcoin ont été confirmées par un certain bloc sont envoyées à Bob. Bob vérifiera que ces quatre transferts ne violent pas les règles de transition de l'État. du contrat, puis décider de l'accepter ou non. Lorsqu'Alice construit une transaction RVB, puisque Z est inférieur à X, elle organise également elle-même un UTXO pour recevoir la partie restante. Enfin, Alice intègre la valeur de hachage de cette transaction RVB dans une transaction Bitcoin qui coûte UTXO A' pour effectuer le paiement.

Enfin, grâce à l'utilisation de conteneurs UTXO, le dernier état d'un contrat RVB peut être représenté comme un point sur un graphe acyclique dirigé qui n'a pas de descendants (chaque point représente un état stocké dans un conteneur UTXO). De plus, pour le propriétaire P dans la figure ci-dessous, il ne connaîtra que le processus depuis l'état initial G du contrat pour l'atteindre, c'est-à-dire le processus marqué par le cercle rouge, et ne saura rien des points gris :

Avantages RVB

État léger vérifiable

Comme mentionné ci-dessus, par rapport aux précédents protocoles d'émission d'actifs (systèmes de contrats hors chaîne) apparus sur Bitcoin, RGB réduit considérablement le coût de la vérification (un certain état d'un contrat). Au cours de la transaction, le destinataire n'a plus besoin de parcourir tous les blocs pour collecter des informations sur les changements de statut du contrat, mais n'a besoin que d'obtenir une série de transactions Bitcoin, ainsi que les transactions RVB promises par ces échanges, et les blocs de ces Bitcoin. les transactions contiennent des preuves (basées sur les preuves Merkle dans l'en-tête du bloc), vous pouvez être sûr que le payeur possède réellement un certain montant d'un certain actif.

Cette réduction des coûts de vérification réduit également considérablement la dépendance (la confiance) des utilisateurs à l’égard des grands fournisseurs d’infrastructures. Dans les protocoles précédents, en raison des coûts de vérification élevés, il était difficile pour les utilisateurs de calculer eux-mêmes le dernier statut du contrat, de sorte que les utilisateurs devaient faire confiance à certains fournisseurs (tels que le fournisseur de statut du contrat utilisé en même temps par leur portefeuille) ; , parce qu'ils pourraient se le permettre. Il y a moins de fournisseurs pour calculer les coûts, ce qui signifie également une centralisation des fournisseurs. Mais en RVB, les utilisateurs peuvent se le permettre eux-mêmes en utilisant simplement le client Bitcoin Light pour vérifier la partie transactionnelle avec Bitcoin et le protocole RVB pour vérifier la partie de la transaction RVB.

Comparé à certains systèmes de contrat en chaîne, RVB est également plus léger. Cela se reflète dans le fait que RGB peut vérifier spécifiquement un certain état d'un contrat ; sur les systèmes qui ne sont pas basés sur UTXO, en raison de l'absence d'un mécanisme de contrôle d'accès comme UTXO, toute transaction peut changer n'importe quel état, donc vous Il est presque impossible de vérifier spécifiquement un certain état, mais on ne peut déterminer un certain état qu'en calculant tous les derniers états - en ce sens, les caractéristiques exprimées comme "état global" devraient en fait être appelées "uniformes". state)", bien qu'il offre la fonctionnalité d'accès croisé entre les contrats, il détermine également que son coût de vérification sera plus élevé et qu'il sera plus difficile d'obtenir l'absence de confiance.

Sur ces protocoles de contrat en chaîne, une mesure d'optimisation majeure consiste à exiger que l'en-tête du bloc s'engage sur le dernier état (« racine d'état »), permettant ainsi aux clients légers de vérifier un certain état d'un contrat obtenu à partir du nœud complet en fonction de ces engagements. Il s'agit d'une méthode de réutilisation de calculs déjà effectués (calculs exécutés par le nœud complet), et elle est également très efficace, donc si l'absence de confiance n'est pas prise en compte, elle peut être considérée comme plus efficace que RVB. Cependant, cela signifie après tout que les nœuds légers s'appuient sur des nœuds complets pour la vérification de base des transactions et le calcul du statut du contrat. Dans le portefeuille RVB qui utilise le client Bitcoin light, l'hypothèse de confiance sur laquelle il s'appuie est que la transaction Bitcoin concernée est une transaction valide et que la partie liée au statut du contrat a été personnellement vérifiée par le client, il s'agit donc d'une plus grande confiance. gratuit. . L’inconvénient est que le délai de vérification est plus long et qu’il faut conserver davantage de données.

Évolutivité

L’évolutivité du RVB se reflète sous deux aspects :

La transaction Bitcoin contient simplement une valeur de hachage, ce qui signifie qu'il n'y a aucune limite sur la taille de la transaction RVB (à l'exception des règles personnalisées du contrat) - même si vous divisez un actif RVB en 100 parties (la transaction RVB elle-même sera très grande), et il n’y a qu’une seule valeur de hachage qui doit être intégrée dans une transaction Bitcoin. Comme mentionné dans la note 6, il existe deux manières d'intégrer une telle valeur de hachage : l'une consiste à utiliser la sortie OP_RETURN, ce qui signifie qu'elle consommera l'espace en chaîne d'une valeur de hachage ; l'autre consiste à masquer la sortie de la clé publique du script ; Taproot sur l'arborescence de script validée - cela ne consomme aucun espace sur la chaîne. Cela signifie également que les utilisateurs n'ont pas à sacrifier l'économie pour la programmabilité, mais uniquement en tenant compte des frais en chaîne.

Le dernier état du contrat RVB est un point indépendant sur un graphe acyclique orienté sans descendants - cela signifie que ces états peuvent être modifiés indépendamment sans s'affecter mutuellement, ce qui signifie que la concurrence est autorisée. Il s'agit en fait d'une fonctionnalité héritée d'UTXO. Cela signifie également que les modifications invalides (transactions invalides) qui se produisent sur une succursale n'affecteront pas les autres succursales, et encore moins bloqueront l'ensemble du contrat, cela peut donc également être considéré comme un avantage en matière de sécurité.

Un point qui a été critiqué pour l'évolutivité de RGB est que chaque transfert nécessite que le destinataire vérifie toutes les transactions impliquées depuis l'état initial jusqu'à l'état payeur - à mesure que le nombre de fois que l'actif change de mains augmente, la charge de vérification des destinataires ultérieurs augmente. deviendra de plus en plus lourd. Cette critique est vraie. L’optimiser signifie également trouver un moyen de réutiliser les opérations déjà réalisées. Les technologies de systèmes de preuve telles que les SNARK promettent de fournir une telle solution 7 .

Différenciation de la définition des actifs et du mécanisme de conservation

Le dernier avantage est toujours lié à UTXO et dépend de la façon dont nous comprenons le mécanisme de script de verrouillage d'UTXO.

Un script de verrouillage peut être utilisé pour programmer les conditions de déverrouillage d'un fonds et, par conséquent, il peut mettre en œuvre des règles de conservation. Par exemple, si un script de verrouillage contient une et une seule clé publique, cela signifie que seul le propriétaire de la clé privée correspondante peut le contrôler. Cependant, ces règles de garde constituent également la base de la programmation du protocole contractuel Bitcoin8. Par exemple, un UTXO utilisant un script de verrouillage multi-signature 2 sur 2 pourrait être un canal Lightning au cours du canal, les deux parties pourraient se payer un nombre presque infini de fois sans aucune modification du canal ; forme de chaîne des fonds. En d'autres termes, à l'heure actuelle, le script de verrouillage multi-signature 2 sur 2 constitue un mécanisme de transfert de valeur qui permet aux deux parties de transférer de la valeur sans changer la forme des fonds sur la chaîne.

Un tel mécanisme peut être utilisé pour la valeur Bitcoin portée par UTXO. Naturellement, il peut également être utilisé pour les actifs RVB qu'il transporte. Nous pouvons émettre un actif RVB et l'attacher à un UTXO multi-signature 2 sur 2, utilisant ainsi le mécanisme de Lightning Channel pour payer cet actif un nombre illimité de fois 9. De la même manière, les actifs RGB peuvent également être conclus dans d’autres contrats basés sur des scripts Bitcoin.

Ici, le script UTXO et le protocole RGB forment une différenciation fonctionnelle : le premier s'engage à mettre en œuvre les règles de conservation et de transfert de valeur tandis que le second se concentre sur la définition des actifs ; Ainsi, la garde des actifs et la définition des actifs peuvent être séparées. Il s’agit d’une amélioration importante de la sécurité et d’un objectif que les gens recherchent dans certains autres systèmes de contrats en chaîne.

Des designs déjà réalisés par RGB

Les propriétés ci-dessus sont vraies pour pratiquement tous les protocoles basés sur le scellement unique UTXO et la vérification côté client. Mais sur cette base, le protocole RVB a été conçu davantage.

Lors du développement du protocole RVB actuel, les développeurs sont particulièrement préoccupés par la confidentialité du protocole, c'est pourquoi RVB renforce la confidentialité sous deux aspects :

UTXO aveugle. Dans une transaction RVB, le destinataire utilise simplement l'identifiant UTXO obscurci pour recevoir l'actif sans exposer les caractéristiques de l'UTXO qui a réellement reçu l'actif. Cela ne nuit en rien à la capacité du destinataire à fournir des preuves au propriétaire suivant, tout en permettant aux destinataires ultérieurs des actifs de se défendre contre les regards indiscrets du propriétaire précédent.

Blindé. Peut être utilisé pour masquer le montant spécifique de chaque transaction. Toutefois, les propriétaires d’actifs ultérieurs peuvent toujours vérifier qu’aucune émission supplémentaire n’a eu lieu auparavant.

Espace à explorer

Dans cette section, j'aborderai l'espace que le protocole RVB peut continuer à explorer, principalement lié à la programmabilité.

Actuellement, les modèles de contrat RVB (schéma) proposés se concentrent sur l’émission d’actifs. Cependant, puisque RGB utilise un paradigme de « validation côté client », nous pouvons en fait y ajouter n'importe quelle fonctionnalité qui peut être assurée avec la validation côté client - uniquement limitée par la structure d'UTXO.

Restrictions

Sur la base d'UTXO, un concept qui peut élargir la programmabilité est appelé « covenants »10. L’intention initiale d’une clause restrictive est de limiter la destination vers laquelle une somme d’argent peut être transférée. Avec cette capacité, nous pouvons programmer de nombreuses applications intéressantes, telles que :

Pool de fonds pour les retraits non interactifs. Nous pouvons regrouper les fonds de nombreuses personnes dans le même UTXO et utiliser des restrictions pour garantir que chacune d’entre elles puisse retirer ses propres fonds sans l’aide des autres. Cela peut avoir pour effet d’aider les gens à quitter les lieux à haut risque à faible coût lorsque la demande d’espace de bloc est élevée.

Contrat de coffre-fort. Un fonds doit d'abord être dépensé quelque part et passer par un verrouillage temporel avant de pouvoir être dépensé librement ; pendant la période de verrouillage temporel, le propriétaire du coffre-fort peut interrompre le processus avec une clé d'urgence et transférer immédiatement les fonds vers un autre endroit. Ce dispositif peut être d’une grande aide pour une garde autonome.

Le script Bitcoin actuel n'a pas cette capacité, donc l'activation des restrictions sur Bitcoin Script nécessite un soft fork.

Cependant, tant que nous sommes prêts à sacrifier certains des avantages apportés par la « différenciation des mécanismes de définition et de conservation des actifs », nous pouvons expérimenter de telles fonctionnalités sur les actifs RVB. Nous pouvons implémenter de telles fonctions au niveau du contrat RVB – bien que cela soit possible. seulement Cela ne fonctionne pas pour les actifs RVB qui l'utilisent (et non pour Bitcoin), mais ouvrira certainement un espace intéressant.

Les recherches existantes sur les clauses de restriction montrent qu'elles peuvent élargir l'espace de programmation des transactions basées sur UTXO et fournir de nombreuses fonctionnalités. Mais ces études sont essentiellement basées sur Bitcoin, et sur des protocoles comme Bitcoin, nous serons plus conservateurs. Sur RVB, nous pouvons généraliser avec audace les capacités de base des contraintes (la capacité de lire les transactions qui se dépensent au niveau du script) pour offrir une programmabilité plus flexible : la possibilité d'accéder de manière croisée aux contrats.

accès croisé

Des termes peu restrictifs signifient que lorsqu'un UTXO est dépensé, son script peut lire le résultat de la transaction de dépense. Mais une contrainte entièrement généralisée signifie qu'elle peut lire toutes les parties de la transaction qui l'ont dépensée. Cela signifie qu'il peut également lire d'autres entrées de la transaction. Si nous ne limitons pas les autres entrées à provenir du même contrat, cela signifie qu'il peut lire le statut d'autres contrats.

En RVB, par défaut, chaque contrat est un univers indépendant avec son propre graphe acyclique orienté. Toutefois, il reste possible pour un utilisateur de détenir simultanément le statut de deux contrats différents. De telles capacités d'accès croisé pourraient avoir des cas d'utilisation si les transactions RVB permettaient la dépense simultanée d'actifs des deux contrats (même si cela pourrait éventuellement rendre la vérification des transactions plus complexe).

En fait, il existe déjà des systèmes de contrats en chaîne basés sur des structures similaires à UTXO (par exemple : Nervos Network), qui l'utilisent pour obtenir des capacités d'accès croisé des contrats 11. Il s’agit d’un domaine très nouveau, ouvrant sur des domaines rarement abordés par les recherches précédentes sur Bitcoin, et il pourrait y avoir quelques surprises enfouies là-bas.

en conclusion

Dans cet article, les lecteurs découvriront qu'il existe un concept qui est fréquemment mentionné et qui traverse tous les processus de raisonnement et de fantaisie : « UTXO ». C'est exactement mon intention. Si vous ne comprenez pas UTXO, vous ne pouvez pas comprendre le point de départ de la conception d'un protocole comme RVB, ni les avantages de la conception du protocole RVB, ni imaginer la façon dont les gens l'utilisent. L’identité du protocole RGB est largement façonnée par sa forme UTXO, unique et scellée. En conséquence, les recherches sur UTXO accumulées dans le domaine de la recherche Bitcoin peuvent également être appliquées à la recherche sur RVB.

Cela explique également pourquoi les personnes qui ne comprennent pas Bitcoin auront du mal à comprendre le RVB. Les personnes qui aiment Bitcoin reconnaîtront le design réalisé par RGB.

Étant donné que l'article contient trop de commentaires, veuillez consulter le lien source ci-dessous.