Par
Le 13 février, Cipher, co-fondateur de CKB, a introduit un protocole étendu pour RGB : RGB++ . Cette annonce a rapidement attiré l’attention du marché et a eu un impact notable sur les prix du CKB sur le marché secondaire.
Avant le dévoilement de ce protocole, j'ai engagé plusieurs discussions approfondies avec Cipher concernant le protocole RGB, explorant ses concepts et formulations initiaux. Par conséquent, j'ai décidé d'écrire un bref article pour exprimer ma compréhension simple du protocole RGB++, mes opinions personnelles à ce sujet et mes points de vue sur les implications et les effets potentiels de ce protocole.
Pour comprendre de manière concise RGB++, considérez les points clés suivants :
Il intègre certaines technologies du protocole RGB. Bien qu'il n'appartienne pas strictement à l'écosystème RVB, il élargit considérablement les cas d'utilisation de la technologie RVB.
Il résout les défis techniques existants dans l'application pratique du protocole RVB et introduit des fonctionnalités améliorées, notamment des « processus de vérification », une « programmabilité contractuelle » et des « machines virtuelles complètes de Turing ».
Les UTXO Bitcoin sont mappés sur les cellules Nervos CKB. Ce processus exploite les contraintes de script sur les blockchains CKB et Bitcoin pour garantir l'exactitude des calculs d'état et la légitimité des transferts de propriété. Je pense que le concept de liaison isomorphe offre un potentiel d'évolutivité important.
Ceux qui connaissent mon travail savent que j'ai été profondément impliqué dans la recherche sur le protocole RVB, en surveillant constamment son développement et la croissance de son écosystème. Mes recherches approfondies ont révélé que, bien que le protocole RVB soit magnifiquement conçu, il rencontre plusieurs défis lors de sa mise en œuvre pratique :
L’un des facteurs qui y contribuent est que la majorité de ses éléments de conception sont soit des concepts entièrement nouveaux, soit visant à établir de nouvelles normes. Les deux nécessitent une planification méticuleuse et complète et la création d’un nouveau code à partir de zéro.
Un autre facteur est le nombre relativement restreint de développeurs engagés dans la couche protocolaire. Cela ressort de la composition du personnel du LNP/BP et de la portée limitée des projets en cours au sein de l’écosystème.
Par exemple, le protocole RVB est généralement conçu pour fonctionner sur le réseau Lightning. Cependant, la norme Bolt-Ln actuelle ne prend pas en charge de manière adéquate les contrats RVB. Pour résoudre ce problème, l'association LNP/BP a introduit une nouvelle norme pour le réseau Lightning appelée bifrost. Mais la mise en œuvre de bifrost est une entreprise colossale, nécessitant un travail substantiel et potentiellement en attente de développements plus larges dans le réseau Lightning.
De plus, le processus de transfert en RGB implique la gestion des factures et des commissions. Actuellement, ceux-ci peuvent être gérés via des plateformes comme le web2 (Twitter, Telegram, etc.) ou des réseaux peer-to-peer. Cependant, pour une approche plus unifiée, un protocole de transmission standardisé est nécessaire. Ce rôle est destiné aux nœuds de tempête. Cependant, la mise en place d’un tel réseau est également une tâche à forte intensité de main d’œuvre.
Cela implique que, même après la sortie complète de la version 0.11, un temps considérable est nécessaire pour évaluer les performances et la fiabilité de la machine virtuelle. De plus, une période considérable est nécessaire pour accumuler de l'expérience dans le développement de code à l'aide d'AluVM et dans la création de bibliothèques standard.
Ces défis permettent à RGB de se démarquer sur un marché où chaque seconde compte, à l’instar de la première phase de développement de BTC. Cela introduit diverses incertitudes : impacts des cycles de marché (comme manquer des phases de financement haussières), influences émotionnelles, fusion d'autres nouvelles technologies (intégrations qui combinent d'autres technologies avec des aspects du RVB pour obtenir un avantage précoce), entre autres.
Résumer:
Le RVB est très prometteur, mais la pleine réalisation du protocole est un long processus semé d’incertitudes.
Cela constitue la toile de fond et les défis que le protocole RGB++ cherche à relever.
En tant que tel, l'accent principal des premières étapes de discussion s'est concentré sur deux questions clés : « Comment pouvons-nous résoudre les défis de mise en œuvre auxquels est confronté le RVB ? » » et « Est-il possible d'exploiter les technologies existantes de CKB pour résoudre ces problèmes dans une certaine mesure ? »
Dans une approche créative, Cipher a utilisé l'élément fondamental du RVB, « UTXO », et son parallélisme architectural avec CKB, proposant le concept de « liaison isomorphe ». Ce concept a progressivement jeté les bases de la structure du protocole « RGB++ ».
Considérez l'illustration suivante, qui intègre deux composants cruciaux du protocole RVB avec le framework CKB :
L' UTXO en RVB, agissant comme un conteneur, peut être mappé sur le Cell de CKB. Ceci est réalisé en utilisant le script de verrouillage dans la cellule.
Le mécanisme de vérification côté client hors chaîne dans RGB peut être transformé en vérification publique en chaîne au sein de CKB. Les données et l'état utilisés pour la vérification en RVB peuvent en conséquence être intégrés aux éléments de données et de type au sein de la cellule.
Source:
En utilisant la « liaison isomorphe », le processus d'interprétation des comités RVB sur CKB a été réalisé. De plus, pour maintenir la compatibilité, les utilisateurs peuvent toujours effectuer des interprétations sur RVB, ce qui constitue une fonctionnalité particulièrement intéressante.
Une analyse plus approfondie révèle que Cipher a effectivement « déconstruit » et « modularisé » la technologie RVB. Il s’agit d’évaluer si certains modules pourraient tirer parti d’approches technologiques alternatives ou de substituts, ouvrant ainsi la voie à un plus large éventail de possibilités.
Suite à la mise en œuvre de la « liaison isomorphe », le protocole gagne naturellement en extensibilité, permettant la réalisation de diverses fonctions d'extension (des informations détaillées peuvent être trouvées dans le livre blanc) :
En tirant parti de la programmabilité des cellules CKB, plusieurs transactions CKB peuvent être alignées sur une seule transaction Bitcoin RGB++. Cette stratégie permet l’expansion de la chaîne Bitcoin, qui est généralement plus lente et a un débit plus faible, en utilisant la chaîne CKB hautes performances.
En élargissant le concept de « repliement des transactions », il est possible que tous les changements d'état ne nécessitent pas de synchronisation sur la blockchain Bitcoin, introduisant essentiellement un mécanisme de « vérification hors chaîne » dans CKB.
Les contrats sans leader sont conçus de manière à ce que n'importe qui puisse modifier l'état du contrat tant qu'il respecte ses contraintes, sans qu'il soit nécessaire que les modifications soient initiées par un fournisseur de signature numérique spécifié.
Ce type de contrat ouvre la voie à des systèmes contractuels plus complexes tels que les Automated Market Makers (AMM).
Une caractéristique des transferts selon le protocole RVB est la nécessité pour les deux parties de communiquer certaines informations pour finaliser une transaction. Cette exigence a ses avantages (comme la protection contre les jetons frauduleux), mais ajoute également à la complexité et à la courbe d'apprentissage des utilisateurs. RGB++ peut tirer parti de ces avantages en transférant des processus interactifs vers l'environnement CKB, en mettant en œuvre une opération d'envoi-réception pour faciliter la logique de transfert non interactive.
Cette approche est essentielle pour exécuter efficacement des parachutages à grande échelle.
Il est possible d'intégrer la conception AMM basée sur une grille de CKB, créant ainsi un modèle de tenue de marché basé sur le système UTXO. Bien que différent du modèle de tenue de marché de la courbe de prix d'Uniswap, cela représente un pas en avant significatif pour les modèles basés sur UTXO.
Étant donné que le protocole a été récemment introduit et que son développement complet est encore en cours, et que de nombreuses personnes ne connaissent pas parfaitement le protocole RVB lui-même, il existe un manque général de sensibilisation aux effets transformateurs potentiels que RVB++ pourrait apporter. Je développerai mon point de vue concernant l'impact du protocole RGB++ sous plusieurs angles :
CKB, connu pour son mécanisme POW et son modèle avancé « UTXO », est considéré pour son « orthodoxie ». Cependant, malgré le soutien précoce de plusieurs institutions de premier plan, son réseau et son écosystème n'ont pas connu de croissance particulièrement impressionnante.
Cette année, avec son pivotement vers l'espace L2 de Bitcoin, je considère cela comme une période d'opportunité cruciale pour CKB. D’une part, la technologie sous-jacente et l’infrastructure de base ont mûri au cours des dernières années. D’un autre côté, il s’aligne opportunément sur la vague d’intérêt actuelle.
Lors de mes discussions avec Cipher, il a avancé une perspective que j’ai trouvée particulièrement éclairante :
La clé pour gagner dans l’arène Bitcoin L2 dépend de la L1.
RGB++ favorise une intégration plus profonde entre CKB et la chaîne principale Bitcoin, renforçant ainsi sa prétention à « l'orthodoxie ». Cette connexion approfondie est la raison pour laquelle je la considère comme l’un des points d’ancrage essentiels.
Le concept de technologie Layer 2 (L2), en particulier dans sa forme mature, a principalement évolué à partir des développements d’Ethereum. À mesure que diverses solutions L2 et développements modulaires ont progressé, la définition de L2 est devenue plus ambiguë. Dans le contexte d’Ethereum, l’approche tend vers le pragmatisme et l’idée d’« orthodoxie » diminue progressivement.
Cependant, dans le réseau Bitcoin, la notion d'« orthodoxie » a toujours été un signal important tout au long de son processus de développement. À l’heure actuelle, selon mon point de vue personnel, la hiérarchie « orthodoxe » au sein de la L2, classée de la plus élevée à la plus basse, est la suivante :
Ces trois systèmes sont familiers à beaucoup. Essentiellement, chacun suit un chemin de mise en œuvre fondamentalement différent et aborde des aspects distincts. Actuellement, le Lightning Network est le plus avancé en termes de développement, suivi de RGB, puis de BitVM.
Les exemples incluent Liquid, Stacks, CKB et autres. La majorité d'entre eux utilisent toujours l'architecture UTXO mais avec certaines adaptations ou innovations pour améliorer des aspects tels que l'évolutivité (y compris la confidentialité et la programmabilité) et pour affiner le mécanisme de consensus.
Les sidechains, dans une certaine mesure, peuvent être perçues comme des chaînes expérimentales pour BTC, servant à tester de nouvelles fonctions ou fonctionnalités temporairement irréalisables sur la chaîne principale BTC.
Cette catégorie pourrait englober « L2 basé sur des protocoles inter-chaînes », « L2 basé sur EVM (Ethereum Virtual Machine) » et plus encore. Je suis généralement d’accord avec le point de vue d’Ajian.
Source:
Le protocole RGB possède intrinsèquement la capacité de fusionner avec d’autres blockchains publiques construites sur l’architecture UTXO. La publication officielle sur Twitter de l'association LNP/BP a révélé son intention de faciliter l'interopérabilité avec le réseau Liquid.
Source:
Grâce à l'intégration de certaines technologies de CKB et RGB, la viabilité pratique de cette combinaison sera largement démontrée.
Plonger plus profondément : si nous extrayons davantage le protocole RGB++, en le transformant en une couche d'extension plus étendue conçue pour relier le protocole RGB à toutes les blockchains publiques basées sur l'architecture UTXO qui possèdent une évolutivité, son récit et sa proposition de valeur seraient considérablement améliorés. C’est également la direction que je prévois pour Cipher dans sa prochaine phase d’efforts.
De plus, cette stratégie offre des voies de développement alternatives pour les projets au sein de l'écosystème RVB, s'écartant de l'approche simpliste des « ponts multi-signatures entre chaînes » et fondée sur des méthodologies natives.
La décomposition analytique de l'architecture technologique RVB effectuée par Cipher pourrait constituer un paradigme de réflexion précieux pour les techniciens travaillant sur d'autres solutions de couche 2.
Ils pourraient intégrer les technologies RVB spécifiques nécessaires aux caractéristiques techniques et aux atouts uniques de leur projet. Cela leur permettrait de « synthétiser » ces éléments dans un nouveau paradigme de produit, pouvant même obtenir un « avantage de premier plan » (le terme « avantage de premier plan » ici n'est pas péjoratif ; il signifie la nature combinatoire de la technologie et de l'innovation au sein de l'écosystème BTC. Cet « avantage majeur » favoriserait probablement également la prolifération et l'évolution du protocole RVB).
Dans l’ensemble, même si RGB++ n’en est actuellement qu’au stade du livre blanc, je garde un optimisme théorique à son égard. Il a le potentiel d’injecter une nouvelle vitalité dans le protocole RGB et pourrait également revigorer le réseau CKB.
Biographie de l'auteur :
Cet article est une traduction du message original de DaPangDun.