Article de Francisco Calderón publié le 8 novembre 2021 sur le site Grunch.dev. Traduction de Pierre-Louis.
Satoshi Nakamoto a lancé le premier nœud Bitcoin le 3 janvier 2009. De nouveaux nœuds l’ont ensuite rejoint et Bitcoin a commencé à se comporter comme une nouvelle forme de vie. Une forme de vie qui n’a cessé d’évoluer depuis, petit à petit, jusqu’à devenir le réseau le plus sûr du monde. Cette performance a été atteinte grâce à sa conception unique, très bien pensée par Satoshi et fondées sur des incitations économiques. Le réseau attire des utilisateurs, communément appelés mineurs, qui investissent en énergie et en puissance de calcul pour contribuer à la sécurité du réseau.
Alors que Bitcoin poursuit sa croissance et son adoption, il est confronté à des problèmes d’évolutivité. Partant du principe que le réseau Bitcoin permet de miner des transactions environ toutes les 10 minutes, et en supposant que 144 blocs sont minés par jours, contenant 2700 transactions chacun, le réseau permettrait 4,5 transactions par seconde. Comme nous pouvons le lire dans un mail envoyé à Mike Hearn en mars 2011, Satoshi était conscient de cette limitation. Ce dernier expliquait le fonctionnement des canaux de paiements que nous connaissons aujourd’hui avec le Lightning Network. Des micropaiements à la fois rapides et sécurisés, qui n’ont pas besoin d’être inscrits dans un bloc du réseau. C’est ainsi qu’interviennent les protocoles off-chain (en dehors de la Blockchain).
Selon Christian Decker, les protocoles off-chain sont généralement des systèmes dans lesquels les utilisateurs utilisent les données d’une blockchain et les gèrent sans toucher à la blockchain elle-même, jusqu’à la dernière minute. C’est sur la base de ce concept qu’est né le Lightning Network, un réseau qui utilise des protocoles off-chain pour permettre d’effectuer des paiements en bitcoins de manière quasi instantanée. Comme toutes ces opérations ne sont pas inscrites sur la blockchain, il permet d’effectuer des milliers de transactions par seconde et de faire passer Bitcoin à l’échelle.
La recherche et le développement dans le domaine des protocoles off-chain sur Bitcoin a ouvert une boîte de pandore. Aujourd’hui, nous savons que nous pouvons réaliser beaucoup plus que le transfert de valeur, et cela, de manière décentralisée.
L’association à but non lucratif LNP/BP se concentre sur le développement des protocoles de layer 2 et 3 sur Bitcoin et le Lightning Network. Parmi ces projets, RGB sort du lot.
1. Qu’est-ce que RGB ?
RGB est né des recherches de Peter Todd sur les « single-use-seals » et la « client-side-validation ». Ces recherches ont été reprises de 2016 à 2019 par Giacomo Zucco et la communauté, pour construire un protocole d’actifs pour Bitcoin et le Lightning Network. Cela a conduit au développement de RGB, un système de smart-contract à part entière, conçu par Maxim Orlovsky qui dirige sa mise en œuvre depuis 2019 avec la participation de la communauté.
Nous pouvons définir RGB comme un ensemble de protocoles open source qui nous permet d’exécuter des smart-contracts complexes de manière évolutive et confidentielle. Il ne s’agit pas d’un réseau particulier (comme Bitcoin ou Lightning), car chaque smart-contract ne concerne que les participants au contrat qui peuvent interagir en utilisant différents canaux de communication (par défaut le réseau Lightning). RGB utilise la blockchain Bitcoin comme couche d’engagement d’état et maintient le code du smart-contract et les données off-chain. Cela le rend évolutif, dans la mesure où il exploite les transactions Bitcoin (et Script) pour contrôler la propriété des smart-contracts, tandis que l’évolution de ces derniers est définie en dehors de la chaîne. Il est important de noter que tout est validé du côté client.
En termes simples, RGB est un système qui permet à l’utilisateur d’auditer un smart-contract, de l’exécuter et de le vérifier individuellement à tout moment sans avoir un coût supplémentaire. En effet, RGB n’utilise pas une blockchain comme le font les systèmes « traditionnels ». Les systèmes complexes de smart-contracts ont été lancés par Ethereum mais, comme ils exigent que l’utilisateur dépense des quantités importantes de gaz pour chaque opération, ils n’ont jamais atteint l’évolutivité qu’ils promettaient. Par conséquent, ces derniers n’ont jamais été une option pour bancariser les utilisateurs exclus du système financier actuel.
Aujourd’hui, l’industrie de la blockchain promeut l’idée que le code des smart-contracts et les données doivent être stockés dans la blockchain et exécutés par chaque nœud du réseau. Cela sans se soucier de l’augmentation excessive de la taille ou de l’utilisation abusive des ressources informatiques.
Le schéma proposé par RGB est beaucoup plus intelligent et efficace. Il coupe avec le paradigme de la blockchain en ayant des smart-contracts et des données séparées de celle-ci. Cela évite la saturation observée sur d’autres réseaux, dans la mesure où il ne force pas chaque nœud à exécuter chaque contrat. Le fait que seules les parties impliquées exécutent le contrat ajoute également un niveau de confidentialité jamais vu auparavant.
2. Les Smart-contracts sur RGB
Avec RGB, le développeur du smart-contract définit un schéma spécifiant les règles d’évolution de ce contrat dans le temps. Le principe du schéma est la norme pour la construction des smart-contracts dans RGB, et toutes les parties au contrat doivent l’approuver. Tant l’émetteur, lorsqu’il définit le contrat pour l’émission, qu’un Wallet ou une plateforme d’échange, doivent adhérer à ce schéma particulier. Ce n’est que si la validation est correcte que chaque partie peut accepter des demandes et travailler avec le token.
Un contrat intelligent sur RGB est un « directed acyclic graph » (DAG) de changements d’état, où seule une partie du « graph » est toujours connue et où il n’y a aucun accès au reste. Le schéma RGB est un ensemble de règles de base pour l’évolution de ce graph avec lequel le smart-contract commence. Chaque participant au contrat peut ajouter des éléments à ces règles (si cela est autorisé par le schéma) et le graph résultant est construit à partir de l’application répétée de ces règles.
3. Les tokens fongibles
(à ne pas confondre avec les tokens non fongibles, ou NFT, de la partie 5)
Les tokens fongibles sur RGB suivent la spécification LNPBP RGB-20. Lorsqu’un RGB-20 est défini, les données du token appelées « genesis data », sont distribuées par le réseau Lightning. Ces données contiennent ce qui est nécessaire pour utiliser le token. La forme la plus élémentaire de token ne permet pas l’émission secondaire, le burn de token, la renomination ou le remplacement.
Parfois, l’émetteur aura besoin d’émettre plus de jetons à l’avenir. C’est notamment le cas des stablecoins comme USDT, qui maintiennent la valeur de chaque token liée à la valeur d’une monnaie inflationniste comme l’USD. Pour y parvenir, il existe des schémas RGB-20 plus complexes qui, en plus des données de genèse, exigent de l’émetteur qu’il produise des consignations, qui circuleront également dans le réseau Lightning. Ces informations nous permettront de connaître l’offre totale de cet actif en circulation. Il en va de même pour le burn de token ou le changement de son nom.
Les informations relatives à l’actif peuvent être publiques ou privées. Si l’émetteur exige la confidentialité, il peut choisir de ne pas partager les informations sur le token et d’effectuer des opérations en toute confidentialité. Nous avons en revanche également le cas inverse dans lequel l’émetteur et les détenteurs ont besoin que l’ensemble du processus soit transparent. Pour cela, il faut partager les données du token.
4. Les procédures RGB-20
La procédure de burn désactive les tokens et ces derniers ne peuvent plus être utilisés ensuite.
La procédure de remplacement intervient lorsque les tokens sont « brûlés » et qu’une nouvelle quantité du même token est créée. Cela permet de réduire la taille des données historiques de l’actif, ce qui est important pour maintenir sa vitesse.
Pour prendre en charge le cas où il est possible de « brûler » des tokens sans avoir à les remplacer, un sous-schéma du RGB-20 est utilisé pour permettre uniquement ce burn de token.
5. Les tokens non fongibles (NFT)
Les jetons non fongibles dans RGB suivent la spécification LNPBP RGB-21. Lorsque nous travaillons avec des NFT, nous avons également un schéma principal et un sous-schéma. Ces schémas ont une procédure de gravure, qui permet au propriétaire du jeton d’attacher des données personnalisées. L’exemple le plus courant que nous voyons dans les NFT aujourd’hui est l’œuvre d’art numérique liée au token.
L’émetteur du jeton peut interdire la gravure de ces données en utilisant le sous-schéma RGB-21. Contrairement à d’autres systèmes de blockchain NFT, RGB permet de distribuer des tokens avec des données média de grande taille de manière totalement décentralisée et résistante à la censure. RGB utilise, pour cela, une extension du réseau P2P Lightning appelée Bifrost, qui est également utilisée pour construire de nombreuses autres formes de smart contracts spécifiques à RGB.
Outre les tokens fongibles et les NFT, RGB et Bifrost peuvent aussi être utilisés pour produire d’autres formes de contrats intelligents comme des DEX, des pools de liquidité, des Stablecoins algorithmiques, etc.
6. NFT de RGB vs NFT d’autres réseaux
- Pas de stockage coûteux intégré dans une blockchain.
- Pas besoin d’IPFS. Une extension du réseau Lightning (appelée Bifrost) est utilisée à la place (et elle est entièrement chiffrée de bout en bout).
- Pas besoin d’une solution spéciale de gestion des données – là encore, Bifrost joue ce rôle.
- Il n’est pas nécessaire de faire confiance à des sites Web pour la gestion des données relatives aux jetons NFT, aux actifs émis ou aux ABI des contrats.
- Chiffrement DRM intégré et gestion de la propriété.
- Infrastructure pour les sauvegardes utilisant le Lightning Network (Bifrost).
- Moyens de monétiser le contenu (pas seulement la vente du NFT lui-même, mais l’accès au contenu, plusieurs fois)
Conclusion
Depuis le lancement de Bitcoin, il y a presque 13 ans, il y a eu beaucoup de recherches et d’expérimentations dans le domaine. Les succès et les erreurs nous ont permis de comprendre un peu mieux comment les systèmes décentralisés se comportent dans la pratique, ce qui les rend vraiment décentralisés et quelles actions ont tendance à les conduire à la centralisation. Tout cela nous a amené à conclure qu’une décentralisation réelle est difficile à atteindre. La décentralisation réelle n’a été réalisée que par Bitcoin et c’est pour cette raison que nous concentrons nos efforts pour construire au-dessus de son protocole.
RGB a son propre « rabbit hole » à l’intérieur de celui de Bitcoin. Je m’y aventure et je posterai ce que j’y apprendrai. Dans le prochain article, je parlerai des nœuds LNP et RGB et j’expliquerai comment les utiliser.
A propos de l’auteur
Ingénieur logiciel, Francisco Calderón est consultant indépendant sur des projets Open source liés à Bitcoin/Lightning Network. Il publie son travail sur le site grunch.dev.
A propos du traducteur
Passionné par le Bitcoin depuis 2017, Pierre-Louis anime le blog choose-bitcoin.com consacré au protocole Bitcoin et au Lightning network.
