Au cours du second semestre 2023, l’écosystème des différents protocoles dérivés du BTC se développera rapidement. En plus de la résurgence du protocole Ordinals et BRC20, des protocoles tels que Atomicals et Taproot Assets ont également reçu une grande attention de la part du marché.
Auparavant, Beosin a analysé les risques de plusieurs types de protocoles dérivés BTC : « L’explosion de l’écosystème BTC, en analysant les opportunités et les risques potentiels de ses différents protocoles dérivés ». **Dans cet article, Beosin expliquera en détail un protocole d’émission d’actifs très important dans l’écosystème BTC - le protocole RVB. **
1. Développement du protocole RVB
Le rôle du protocole RVB est d’ajouter une fonctionnalité de contrat intelligent à Bitcoin sur le Lightning Network, un protocole de canal d’état basé sur des preuves à divulgation nulle de connaissance qui permet aux utilisateurs d’effectuer des transactions hors chaîne préservant la confidentialité. **
RGB n’est pas un protocole de jeton, mais il a la capacité d’émettre et de gérer plusieurs actifs hautement évolutifs, programmables et confidentiels, et peut jouer un rôle important dans de nombreux autres secteurs en dehors de la finance. Le développement de son protocole est passé par plusieurs phases importantes, de sa conception initiale à la version actuelle RGB v0.10 qui apporte la fonctionnalité de contrat intelligent à Bitcoin et au Lightning Network.
1 En 2016, Giacomo Zucco a proposé l’idée initiale du protocole RVB en se basant sur les idées de Peter Todd.
2 En 2017, BHB Network a lancé la version originale du protocole RVB, qui était prise en charge par le groupe Poseidon.
3 En 2019, Maxim Orlovsky et Giacomo Zucco ont fondé la LNP/BP Standards Association pour promouvoir le RVB pour des applications pratiques, et le Dr Maxim Orlovsky a commencé à repenser le protocole RVB.
4 En 2021, l’association a fait la démonstration de la machine virtuelle Turing-Complete (AluVM) du protocole RVB, qui a également commencé à fonctionner sur le Lightning Network.
-
En 2022, Contractum, un nouveau langage pour l’écriture de contrats intelligents RVB pour Bitcoin et Lightning Network, a été lancé, ainsi que son nouveau site Web.
-
En avril 2023, RGB v0.10 a été publié, apportant une prise en charge complète des contrats intelligents à Bitcoin et au Lightning Network, marquant l’étape la plus importante du développement du protocole RGB.
2. Logique de conception du protocole RVB
L’idée de base du protocole RVB est construite autour du consensus et du stockage de données hors chaîne.
Tout d’abord, la valeur la plus importante du système distribué est le maintien du consensus, l’utilisation de la couche de consensus binaire n’a besoin que de maintenir de courts engagements cryptographiques pour les événements du registre, la technologie consistant à prouver l’existence de données spécifiques mais ne révélant pas le contenu réel des données, généralement implémentée via la fonction de hachage, ne stockant ces soumissions que sur la chaîne pour garantir l’authenticité et l’intégrité des données, réduisant ainsi le fardeau des données on-chain.
Les données du registre RVB sont stockées hors chaîne, ce qui signifie que toutes les données contractuelles et les transitions d’état restent hors chaîne, et non sur la blockchain. Suivez et vérifiez l’état des contrats intelligents avec des sceaux à usage unique et des transitions d’état, en traitant et en vérifiant efficacement l’état et les transactions des contrats intelligents sans stocker toutes les données sur la chaîne.
La couche de base du RVB est la blockchain Bitcoin, y compris le consensus PoW de Nakamoto et le registre des transactions. Bien qu’il ne soit pas nécessaire de stocker des données sur la chaîne, il est toujours nécessaire de suivre l’infrastructure existante et d’utiliser les transactions Bitcoin comme stockage pour ces engagements.
2.1 Authentification du client
Contrats intelligents RVB en mode de vérification côté client, où toutes les données resteront en dehors des transactions Bitcoin, telles que la blockchain Bitcoin ou l’état du canal du réseau Lightning, permettant au système de fonctionner au-dessus du réseau Lightning et fournissant également la base d’un haut niveau d’évolutivité et de confidentialité du protocole.
Contrat intelligent RVB 2.2
La structure de base d’un contrat intelligent RVB se compose de la genèse, de l’état et des transitions, chacun ayant des fonctions et des rôles différents :
Genèse (创世)
Genesis est la déclaration d’initialisation d’un contrat intelligent, qui définit les propriétés de base et les règles du contrat. Il s’agit notamment du type de contrat, de son objet et de ses paramètres initiaux. Dans le code, la partie genèse définit le point de départ du contrat, comme dans un contrat d’authentification, qui peut spécifier les informations d’identité initiales.
État(状态)
L’état représente l’état actuel du contrat à un moment donné et constitue un instantané en temps réel des données du contrat, y compris toutes les valeurs de variable et les informations sur les actifs.
Transitions(转换)
Les transitions sont des règles qui définissent les transitions d’un état à un autre. Ces règles déterminent la façon dont l’état change en fonction de la logique du contrat. op Vocation et op Transfer sont des exemples de transformations qui définissent comment transférer d’un état d’identité à un autre, ou comment transférer entre des jetons.
Ces trois composants permettent de définir et d’exécuter diverses opérations et protocoles. Genesis définit les règles et les paramètres sous-jacents, State maintient les informations actuelles du contrat et Transitions stipule la logique des changements entre les états, qui forment ensemble l’architecture de base du contrat intelligent RVB.
2.3 一次性密封(joints à usage unique)
Assurer une gestion sécurisée et efficace des transferts d’actifs tout en protégeant la vie privée des utilisateurs. Le protocole RVB utilise une approche de « sceaux à usage unique », qui permet aux actifs (tels que les jetons) d’être liés à une sortie de transaction spécifique de Bitcoin, de sorte que chaque transfert d’actifs nécessite « d’ouvrir » un ancien sceau et d’en « créer » un nouveau. **L’encapsulation unique est utilisée pour représenter la propriété ou l’état contractuel d’un actif. Chaque fois qu’un transfert d’état ou une transaction se produit, l’encapsulation associée est fermée et une nouvelle encapsule est créée, ce qui présente l’avantage que chaque sceau ne peut être utilisé qu’une seule fois, empêchant ainsi la réutilisation ou le double paiement des actifs, assurant la sécurité de la transaction et garantissant ainsi que le transfert des actifs ne peut pas être altéré.
Dans le même temps, comme ces opérations sont effectuées côté client au lieu d’être toutes stockées sur la blockchain, la protection de la vie privée des utilisateurs est considérablement améliorée et l’occupation de l’espace blockchain est réduite, ce qui améliore l’efficacité et l’évolutivité de l’ensemble du réseau.
Étapes logiques pour les joints à usage unique :
-
Le début de chaque contrat RVB est une opération de genèse, où l’état initial et l’encapsulation unique associée sont définis, représentant l’allocation initiale des ressources ou des autorisations définies dans le contrat.
-
Dans le contrat, l’état est utilisé pour représenter la configuration actuelle de l’actif ou de l’autorisation. Chaque état est associé à une encapsulation unique qui représente la propriété ou les autorisations actuelles.
-
Lorsqu’il est nécessaire de transférer ou de modifier des actifs ou des autorisations, il y a des transitions d’état impliquées. Ce processus implique la fermeture de l’encapsulation ponctuelle actuelle (représentant l’ancien état) et la création d’une nouvelle encapsulation (représentant le nouvel état).
-
La fermeture d’un emballage consiste à vérifier son intégrité et à le marquer comme utilisé pour éviter sa réutilisation. Ensuite, sur la base des règles du contrat, une nouvelle encapsulation est créée pour représenter le nouvel état.
-
Lorsqu’une transaction a lieu, les participants au contrat doivent vérifier que l’encapsulation unique pertinente est valide pour garantir la légitimité de la transaction. Ce processus de vérification est automatique et est effectué de manière collaborative par les nœuds RVB et les portefeuilles participants.
3. Caractéristiques du protocole RVB
Les caractéristiques du RVB se reflètent dans l’innovation des contrats intelligents RVB, et voici quelques points clés pour vous :
1. Concept de schéma
Le protocole RVB utilise le concept de schéma, similaire aux classes en programmation orientée objet. Les modes sont utilisés pour définir des normes pour les actifs RVB**, ce qui permet aux portefeuilles, aux échanges, aux navigateurs et aux nœuds BTC de prendre facilement en charge les actifs RVB. Dans ce cadre, un contrat RVB concret est une instance d’un motif, créé par le constructeur du schéma (l’opération de genèse). Cette approche sépare les rôles du développeur de contrat (développeur de modèles) et de l’émetteur de contrat, éliminant ainsi la nécessité pour ce dernier d’avoir des connaissances en programmation ou en sécurité.
2. Machine virtuelle AluVM
Le protocole RVB introduit également la machine virtuelle AluVM, une machine virtuelle Turing-complète similaire à l’EVM d’Ethereum. Il peut effectuer presque tous les types de calculs, mais est limité par le nombre d’étapes de fonctionnement. AluVM limite le calcul grâce à une mesure cumulative de la complexité de calcul, similaire au mécanisme de consommation de gaz d’Ethereum.
3. Exemple de définition de contrat
En termes de définition de contrat, le protocole RVB utilise des types de données spécifiques, tels que PgpKey, qui ne font pas directement partie du contrat mais peuvent être partagés par plusieurs contrats. L’état et les actions d’un contrat, tels que l’identité et la révocation, sont définis comme des composants de l’état du contrat et des transitions d’état possibles.
4. Instances de contrat et transitions d’état
L’instanciation de contrat se fait en appliquant un modèle à une situation spécifique, par exemple, meSatoshiNakamoto implémente le modèle DecentralizedIdentity, qui définit l’état initial et l’affecte à un sceau à usage unique. Les transitions d’état, telles que l’opération Vocation, impliquent la mise à jour d’une identité et son affectation à un nouveau sceau à usage unique.
5. Fonctionnalités de contrat étendues
Le protocole RVB permet d’étendre les fonctionnalités du contrat, comme l’ajout de jetons IOU (I dowe you), qui sont représentés comme des états propriétaires dans le contrat, IOYTokens. En outre, il existe des États mondiaux, tels que IOYTicker et IOYName, qui sont des propriétés globales du contrat et ne sont directement détenus par aucune partie.
6. Le concept d’extension de l’État
Le concept d’extension de l’état permet au public de participer à des parties logiques spécifiques du contrat, par exemple en déclarant Burn. L’opération d’expansion de l’état permet à quiconque de créer une extension d’état sans s’engager sur la chaîne, à l’instar d’une transaction Bitcoin qui n’est pas encapsulée dans un bloc.
7. 合约接口(Contract Interface)
Communication standardisée : l’interface de contrat fournit un moyen standard de communiquer avec un nœud RVB, ce qui l’oblige à renvoyer un état sémantiquement significatif et à créer des opérations.
Similaire à la norme ERC d’Ethereum : Ces interfaces sont similaires à la norme ERC d’Ethereum, et l’interface générique est appelée « RGBxx » et est définie comme une norme LNP/BP autonome.
8. Exemple de création d’une interface de jeton universel
Définitions de l’interface : définit les états globaux (par exemple, le symbole et le nom) et les états détenus (par exemple, l’inflation et l’actif), ainsi que les opérations (par exemple, les émissions et les transferts).
Implémentation de l’interface : lorsqu’une interface est implémentée, l’état et le fonctionnement d’un mode spécifique sont liés à l’interface. Par exemple, l’interface FungibleToken implémente des liaisons d’état global et possédé pour le modèle DecentralizedIdentity.
4. Application du protocole RVB
Applications financières :
1 Utilisé pour créer des tokens qui représentent des actions d’une entreprise ou d’un projet, émis de manière centralisée mais négociés de manière décentralisée, augmentant ainsi la liquidité et la transparence du marché.
-
Gérez les prêts et les obligations, et automatisez l’émission et le remboursement des prêts et des obligations grâce à des contrats intelligents.
-
Créez des stablecoins qui fonctionnent sur le Lightning Network et utilisez-les comme moyen de paiement.
-
Créez un échange décentralisé (DEX).
-
Appliquer des solutions AMM telles que les stablecoins sur-collatéralisés algorithmiquement pour fournir de la liquidité et de la stabilité au marché.
Applications non financières :
-
Utilisé pour gérer des solutions d’identité autonomes qui permettent aux individus de contrôler et de gérer leurs informations d’identité numérique.
-
Créer un système mondial décentralisé d’enregistrement de noms afin que les gens puissent enregistrer et gérer les noms de domaine et autres identifiants Web.
-
Gérer la propriété et les droits de licence pour le contenu numérique, y compris les droits d’auteur et les licences.
-
Utilisé pour tokeniser les œuvres d’art, offrant une nouvelle propriété numérique et une plate-forme d’échange pour les artistes et les collectionneurs.
-
Gérer les DAO pour une prise de décision et une gouvernance décentralisées.
-
Utilisé pour créer un système de journal d’audit prouvable et vérifiable afin d’accroître la transparence et la crédibilité des entreprises et des projets.
5. Risques du protocole RVB actuel
1 Instabilité
Le protocole RVB actuel est la première version à prendre entièrement en charge les contrats intelligents, et il peut y avoir des mises à jour ou des modifications majeures du protocole RVB à l’avenir, ce qui empêchera le développement actuel du contrat de fonctionner de manière sûre et stable dans les versions ultérieures. Le validateur client de RGB est toujours en cours de mise à jour, et il n’y a pas encore de version stable.
2 Complexité
La conception et la mise en œuvre du protocole RVB sont assez complexes, et de nombreuses caractéristiques du protocole RVB doivent être prises en compte pour les contrats intelligents développés sur la base du protocole RVB. Par exemple, si les jetons émis sur la base du protocole RVB échouent ou ne sont pas confirmés par le nœud RVB, alors ces jetons n’appartiennent à aucun UTXO et sont équivalents à être brûlés, et les développeurs et les parties au projet doivent examiner attentivement l’impact de telles situations sur l’économie des jetons du projet.
Résumé
Le protocole RVB n’en est encore qu’à ses débuts. Le protocole RGB a démontré son innovation dans le domaine des contrats intelligents BTC grâce à sa définition de schéma unique, sa machine virtuelle AluVM, sa gestion flexible de l’état des contrats et son mécanisme de mise à l’échelle, prenant en charge l’émission et le transfert de plusieurs actifs sur le réseau Bitcoin et le réseau Lightning. Cependant, à l’heure actuelle, le protocole RVB n’est pas entièrement compatible avec le réseau Lightning, et le développement et le fonctionnement des contrats intelligents ne sont pas sécurisés, de sorte que les utilisateurs doivent être conscients des risques liés à l’utilisation du protocole RVB. **
