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 projets qui visent Pour obtenir des protocoles fonctionnels identiques ou 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 programmation.
Qu'est-ce que le protocole RVB ?
L’idée d’émettre des actifs sur Bitcoin existe depuis longtemps. Mais le protocole Bitcoin a ses propres caractéristiques : son état est exprimé par et uniquement par Bitcoin UTXO (« unspent transaction output ») ; un UTXO ne transporte que deux données : sa propre dénomination (valeur Bitcoin), et une « Script public key » ( également connu sous le nom de « script de verrouillage »), utilisé pour programmer les conditions de dépenses de ce fonds, par exemple : fournir une signature d'une certaine clé publique ; permettre à l'opcode utilisé pour programmer le script de verrouillage d'être déterminé par les règles de consensus de Bitcoin à condition qu'ils ne peut pas être utilisé 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 – le script Bitcoin ne peut 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 les étapes nécessaires pour modifier l'état du contrat - par exemple, le contrat A modifie les paramètres et B transfère une certaine quantité d'un certain actif à C —— Les informations sont téléchargées sur la blockchain, afin que le dernier état du 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 l’état du contrat sur la blockchain Bitcoin. Cela fonctionne certainement, mais se heurte à 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 les utilisateurs doivent modifier le statut du contrat (comme un transfert), ils devront également payer des frais de traitement en chaîne plus élevés. 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 prix d'une consommation plus importante d'espace de bloc ;
(2) Presque toutes les informations contenues dans le bloc peuvent modifier le contrat intelligent en dehors de la chaîne. Par conséquent, les utilisateurs doivent obtenir toutes les données du bloc Bitcoin pour obtenir le dernier statut du système de contrat hors chaîne, c'est-à-dire qu'il est plus coûteux à vérifier ;
(3) Selon la conception du système de contrat intelligent hors chaîne, vous ne pourrez peut-être obtenir qu'une confidentialité comparable à celle du Bitcoin, voire pire ; et si vous pouvez fournir plus de confidentialité, vous devrez peut-être consommer plus d'espace. bloquer l'espace.
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 les problèmes ci-dessus et dissocie la complexité des transactions contractuelles hors chaîne de leurs coûts économiques ; cependant, les utilisateurs doivent toujours obtenir la quantité totale de données de bloc Bitcoin pour obtenir le dernier statut du protocole Omni ; en outre, elle le fait pas spécialement conçu pour améliorer 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 une confirmation. sur la blockchain ; de plus, la transaction Bitcoin qui la dépense doit également fournir un hachage du contenu de la transition d'état pour indiquer l'UTXO attaché à l'état modifié.
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 le récipient ou tirelire en céramique dans cet état - si vous voulez retirer l'argent de la tirelire, vous devez casser la tirelire. Ensuite, mettez l'argent à l'intérieur. dans le nouveau pot.
Cette conception contraste fortement avec les protocoles précédents qui traitaient le bloc entier 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 l'état 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 La conversion d'état RVB promise par le change de devises (une paire un à un avec la transaction Bitcoin correspondante) suffit. 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. Les utilisateurs peuvent 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 le 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 selon les règles de transition d'état. du contrat. , puis décider de l’accepter ou non. Lorsqu'Alice construit la transaction RVB, puisque Z est plus petit que X, elle doit également organiser elle-même un UTXO pour recevoir la partie restante. Enfin, Alice intègre la valeur de hachage de cette transaction RVB dans la 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 orienté 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 et 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 du coût de vérification élevé, il était difficile pour les utilisateurs de calculer eux-mêmes le dernier statut du contrat, les utilisateurs devaient donc faire confiance à certains fournisseurs (tels que le fournisseur de statut du contrat utilisé par leur portefeuille) ; en même temps Il y a moins de fournisseurs pour calculer les coûts, ce qui signifie également une centralisation des fournisseurs. Mais en RVB, les utilisateurs n'ont qu'à utiliser le client Bitcoin light pour vérifier la partie de la transaction avec Bitcoin et le protocole RVB pour vérifier la partie de la transaction RVB, et ils peuvent se le permettre.
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 réalité être. C'est ce qu'on appelle « état uniforme ». fournit 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.
Dans ces protocoles de contrat en chaîne, une mesure d'optimisation majeure consiste à exiger que l'en-tête du bloc s'engage dans 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 le volume 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'incorporer une telle valeur de hachage : l'une consiste à utiliser la sortie OP_RETURN, ce qui signifie qu'elle consommera l'espace sur la chaîne d'une valeur de hachage ; l'autre consiste à masquer la sortie publique du script. dans la clé Taproot - 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 branche n'affecteront pas les autres branches, 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é du RVB 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 où 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.
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 de contrat Bitcoin. Par exemple, un UTXO utilisant un script de verrouillage multi-signature 2 sur 2 peut être un canal éclair ; pendant le fonctionnement du canal, les deux parties peuvent se payer presque d'innombrables fois sans aucun changement dans la forme en chaîne de les 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 canal Lightning pour payer cet actif un nombre illimité de fois. 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.
Conception RVB déjà réalisée
Les caractéristiques ci-dessus sont en réalité vraies pour tous les protocoles basés sur le scellement unique UTXO et la vérification du client. Mais sur cette base, le protocole RVB a été conçu davantage.
Dans le développement actuel du protocole RGB, les développeurs sont particulièrement préoccupés par la confidentialité du protocole, c'est pourquoi RGB renforce la confidentialité sous deux aspects :
UTXO aveugle. Dans une transaction RVB, le destinataire n'a qu'à utiliser 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 le paradigme de « vérification côté client », nous pouvons en fait y ajouter toutes les caractéristiques qui peuvent être assurées par la vérification côté client – uniquement limitées par la structure d'UTXO.
##Restrictions
Sur la base d'UTXO, un concept qui peut élargir la programmabilité est appelé « covenants ». 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 plusieurs personnes dans le même UTXO et utiliser des clauses de restriction 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 ce 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 mettre en œuvre de telles fonctions au niveau du contrat RVB - même si cela peut 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 la capacité principale des clauses de restriction - 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é. Cependant, il reste possible pour un utilisateur de détenir simultanément le statut de deux contrats différents. Si les transactions RVB permettaient la dépense simultanée des actifs des deux contrats, de telles capacités d'accès croisé pourraient avoir des applications (même si elles pourraient éventuellement compliquer la vérification des transactions).
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é aux contrats. 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 revient fréquemment 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. Les caractéristiques du protocole RVB sont largement façonnées par sa forme scellée unique d'UTXO. 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.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Comprendre le véritable potentiel du protocole d'émission d'actifs RVB en un seul article
Auteur : 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 projets qui visent Pour obtenir des protocoles fonctionnels identiques ou 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 programmation.
Qu'est-ce que le protocole RVB ?
L’idée d’émettre des actifs sur Bitcoin existe depuis longtemps. Mais le protocole Bitcoin a ses propres caractéristiques : son état est exprimé par et uniquement par Bitcoin UTXO (« unspent transaction output ») ; un UTXO ne transporte que deux données : sa propre dénomination (valeur Bitcoin), et une « Script public key » ( également connu sous le nom de « script de verrouillage »), utilisé pour programmer les conditions de dépenses de ce fonds, par exemple : fournir une signature d'une certaine clé publique ; permettre à l'opcode utilisé pour programmer le script de verrouillage d'être déterminé par les règles de consensus de Bitcoin à condition qu'ils ne peut pas être utilisé 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 – le script Bitcoin ne peut 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 les étapes nécessaires pour modifier l'état du contrat - par exemple, le contrat A modifie les paramètres et B transfère une certaine quantité d'un certain actif à C —— Les informations sont téléchargées sur la blockchain, afin que le dernier état du 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 l’état du contrat sur la blockchain Bitcoin. Cela fonctionne certainement, mais se heurte à 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 les utilisateurs doivent modifier le statut du contrat (comme un transfert), ils devront également payer des frais de traitement en chaîne plus élevés. 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 prix d'une consommation plus importante d'espace de bloc ;
(2) Presque toutes les informations contenues dans le bloc peuvent modifier le contrat intelligent en dehors de la chaîne. Par conséquent, les utilisateurs doivent obtenir toutes les données du bloc Bitcoin pour obtenir le dernier statut du système de contrat hors chaîne, c'est-à-dire qu'il est plus coûteux à vérifier ;
(3) Selon la conception du système de contrat intelligent hors chaîne, vous ne pourrez peut-être obtenir qu'une confidentialité comparable à celle du Bitcoin, voire pire ; et si vous pouvez fournir plus de confidentialité, vous devrez peut-être consommer plus d'espace. bloquer l'espace.
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 les problèmes ci-dessus et dissocie la complexité des transactions contractuelles hors chaîne de leurs coûts économiques ; cependant, les utilisateurs doivent toujours obtenir la quantité totale de données de bloc Bitcoin pour obtenir le dernier statut du protocole Omni ; en outre, elle le fait pas spécialement conçu pour améliorer 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 une confirmation. sur la blockchain ; de plus, la transaction Bitcoin qui la dépense doit également fournir un hachage du contenu de la transition d'état pour indiquer l'UTXO attaché à l'état modifié.
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 le récipient ou tirelire en céramique dans cet état - si vous voulez retirer l'argent de la tirelire, vous devez casser la tirelire. Ensuite, mettez l'argent à l'intérieur. dans le nouveau pot.
Cette conception contraste fortement avec les protocoles précédents qui traitaient le bloc entier 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 l'état 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 La conversion d'état RVB promise par le change de devises (une paire un à un avec la transaction Bitcoin correspondante) suffit. 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. Les utilisateurs peuvent 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 le 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 selon les règles de transition d'état. du contrat. , puis décider de l’accepter ou non. Lorsqu'Alice construit la transaction RVB, puisque Z est plus petit que X, elle doit également organiser elle-même un UTXO pour recevoir la partie restante. Enfin, Alice intègre la valeur de hachage de cette transaction RVB dans la 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 orienté 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 et 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 du coût de vérification élevé, il était difficile pour les utilisateurs de calculer eux-mêmes le dernier statut du contrat, les utilisateurs devaient donc faire confiance à certains fournisseurs (tels que le fournisseur de statut du contrat utilisé par leur portefeuille) ; en même temps Il y a moins de fournisseurs pour calculer les coûts, ce qui signifie également une centralisation des fournisseurs. Mais en RVB, les utilisateurs n'ont qu'à utiliser le client Bitcoin light pour vérifier la partie de la transaction avec Bitcoin et le protocole RVB pour vérifier la partie de la transaction RVB, et ils peuvent se le permettre.
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 réalité être. C'est ce qu'on appelle « état uniforme ». fournit 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.
Dans ces protocoles de contrat en chaîne, une mesure d'optimisation majeure consiste à exiger que l'en-tête du bloc s'engage dans 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 le volume 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'incorporer une telle valeur de hachage : l'une consiste à utiliser la sortie OP_RETURN, ce qui signifie qu'elle consommera l'espace sur la chaîne d'une valeur de hachage ; l'autre consiste à masquer la sortie publique du script. dans la clé Taproot - 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 branche n'affecteront pas les autres branches, 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é du RVB 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 où 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.
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 de contrat Bitcoin. Par exemple, un UTXO utilisant un script de verrouillage multi-signature 2 sur 2 peut être un canal éclair ; pendant le fonctionnement du canal, les deux parties peuvent se payer presque d'innombrables fois sans aucun changement dans la forme en chaîne de les 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 canal Lightning pour payer cet actif un nombre illimité de fois. 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.
Conception RVB déjà réalisée
Les caractéristiques ci-dessus sont en réalité vraies pour tous les protocoles basés sur le scellement unique UTXO et la vérification du client. Mais sur cette base, le protocole RVB a été conçu davantage.
Dans le développement actuel du protocole RGB, les développeurs sont particulièrement préoccupés par la confidentialité du protocole, c'est pourquoi RGB renforce la confidentialité sous deux aspects :
UTXO aveugle. Dans une transaction RVB, le destinataire n'a qu'à utiliser 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 le paradigme de « vérification côté client », nous pouvons en fait y ajouter toutes les caractéristiques qui peuvent être assurées par la vérification côté client – uniquement limitées par la structure d'UTXO.
##Restrictions
Sur la base d'UTXO, un concept qui peut élargir la programmabilité est appelé « covenants ». 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 plusieurs personnes dans le même UTXO et utiliser des clauses de restriction 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 ce 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 mettre en œuvre de telles fonctions au niveau du contrat RVB - même si cela peut 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 la capacité principale des clauses de restriction - 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é. Cependant, il reste possible pour un utilisateur de détenir simultanément le statut de deux contrats différents. Si les transactions RVB permettaient la dépense simultanée des actifs des deux contrats, de telles capacités d'accès croisé pourraient avoir des applications (même si elles pourraient éventuellement compliquer la vérification des transactions).
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é aux contrats. 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 revient fréquemment 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. Les caractéristiques du protocole RVB sont largement façonnées par sa forme scellée unique d'UTXO. 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.