La guerre de succession des couches 2 Bitcoin : origines, tournants et le choix de CKB
TechFlow SélectionTechFlow Sélection
La guerre de succession des couches 2 Bitcoin : origines, tournants et le choix de CKB
La rapidité n'est pas notre caractéristique, notre caractéristique est d'être lent.
Dédié à des analyses Web3 approfondiesPréparation : Zijieyuan CKB
Source du podcast : Orange Book
Dans le dernier épisode du podcast Orange Book, Li Yang reçoit Jan Xie, architecte principal de Nervos, pour discuter des sujets liés à la couche 2 (Layer 2) de Bitcoin. Il y a beaucoup d'informations concrètes, et nous recommandons vivement son écoute.
Voici la transcription audio du podcast, environ 20 000 caractères au total. Pour plus de lisibilité, quelques titres ont été ajoutés 😊 :
1. Introduction
Li Yang (animateur) : Bonjour à tous, bienvenue sur Orange Book. Dans cet épisode, nous continuons à parler de l'écosystème Bitcoin, avec comme thème central la Layer 2 de Bitcoin.
À la fin du précédent épisode, j'avais déjà le sentiment fort que les inscriptions ne constituaient que la première vague de l’écosystème Bitcoin, et que nous n’en étions qu’au début. Mais je n’aurais jamais imaginé que la nouvelle tendance autour de la Layer 2 de Bitcoin puisse s’accélérer aussi vite.
Je vais vous raconter une histoire effrayante : actuellement, il existe déjà publiquement 34 projets déclarés visant à construire une Layer 2 sur Bitcoin. Sans compter ceux qui ne se sont pas encore révélés, on peut estimer leur nombre à plus de 60. Au total, cela fait donc plus de 100 projets en compétition dans ce domaine. Je ne me souviens même plus de la dernière fois où un secteur de la crypto-économie était aussi saturé. Si aujourd’hui je vous demandais ce qu’est une Layer 2 de Bitcoin ou à quoi elle sert, je parie que vous seriez tout autant perplexe que moi. Même ceux qui travaillent réellement sur ces projets peuvent difficilement en donner une explication claire. Le reste d’entre nous n’a entendu parler que du terme, mais personne ne sait vraiment ce que c’est. J’ai le pressentiment que dans trois ou quatre mois, la Layer 2 de Bitcoin sera aussi populaire que les inscriptions l’ont été l’année dernière – car pour l’instant, cette effervescence reste souterraine, pas encore visible pour le grand public.
Quoi qu’il en soit, mon invité aujourd’hui est Jan Xie. Il est l’architecte principal de Nervos CKB, et selon moi, la personne qui correspond le mieux à la définition de « technophile idéaliste ». Son parcours est très riche, centré sur la technique, et il a longuement œuvré dans les écosystèmes Bitcoin et Ethereum.
Nous avons discuté de l’origine de l’écosystème Bitcoin Layer 2, de son évolution, des tentatives passées et des nouvelles opportunités offertes par les inscriptions. Bien sûr, nous nous sommes surtout concentrés sur la position et la stratégie de CKB face à ce marché, et pourquoi CKB pourrait être la Layer 2 idéale pour Bitcoin.
2. Pourquoi avoir tweeté « CKB est la couche 2 idéale pour Bitcoin » ?
Li Yang (animateur) : Récemment, j’ai vu ton fil Twitter expliquant pourquoi CKB est la Layer 2 idéale pour Bitcoin. J’ai été assez surpris en le lisant. Peut-on interpréter cela comme un changement stratégique (pivot) de CKB ?
Jan Xie : On peut dire que oui, c’est un pivot. Mais on peut aussi dire que nous faisons simplement ce que nous avons toujours fait.
La raison pour laquelle j’ai publié ce tweet est avant tout liée aux grands changements observés dans l’environnement global, notamment dans la communauté crypto depuis la deuxième moitié de 2023. Ce changement est principalement dû à l’apparition des Ordinals et des BRC-20, qui ont provoqué une série de bouleversements sur le marché. Ce qui m’a frappé, c’est que précédemment, peu de gens semblaient s’intéresser à l’écosystème Bitcoin ou aux systèmes UTXO. Beaucoup pensaient qu’Ethereum avait déjà gagné, que la guerre des blockchains était terminée, et qu’Ethereum représentait l’avenir – alors autant continuer à développer dessus.
Mais l’arrivée des Ordinals et des BRC-20 a révélé de nouvelles possibilités, montrant qu’il existait encore un vaste océan bleu. Avant, il n’y avait rien, c’était désert. Les actifs étaient passifs : BTC était inerte, on pouvait seulement le conserver sans rien faire d’autre. Même si on voulait essayer quelque chose, par exemple utiliser 1 dollar sur 100, cela semblait impossible. Aujourd'hui, les gens commencent à croire que c'est faisable.
Ensuite, quels que soient les facteurs – effet de richesse ou autres – de nombreux utilisateurs sont entrés dans cet écosystème, et de nombreux développeurs ont commencé à étudier comment fonctionnent les systèmes UTXO. On parle désormais d’UTXO, on discute des contraintes liées à l’UTXO, voire on les accepte, exactement comme les utilisateurs et développeurs acceptaient auparavant les limitations d’Ethereum. C’est un changement fondamental.
Face à ce changement, j’ai senti qu’il s’agissait d’une excellente opportunité pour aider les gens à comprendre ce que nous faisons, à comprendre CKB. Car CKB a toujours été fidèle à ses convictions : PoW, UTXO, suivre la voie tracée par Bitcoin, plutôt que de faire un virage à 180 degrés vers le modèle de compte (Account Model) ou le PoS. Avant, quand on essayait d’expliquer cela à d’autres, en raison de nos propres limites, il était difficile d’obtenir de l’adhésion ou même d’éveiller l’intérêt. Mais aujourd’hui, les choses ont changé : les gens comprennent plus facilement. Ils disent : « L’UTXO est intéressant, je commence à m’y intéresser, je veux savoir ce qu’on peut faire dessus. Bitcoin a beaucoup de limites, comment votre UTXO est-il différent ? ». Cette perception fondamentale commence à changer. C’est donc une bonne chose pour nous. Comme dit un proverbe : « Il faut compter sur son propre effort, mais aussi tenir compte du cours de l’histoire ». Voilà précisément ce que je ressens. L’évolution du contexte général nous offre une opportunité unique pour que les gens comprennent ce qu’est CKB.
Nous pouvons parfaitement considérer CKB comme une Layer 2 de Bitcoin. Réfléchissons : qu’est-ce qu’une Layer 2 ? Comment la définir ? Pourquoi CKB correspond-il si bien à cette définition ? Telle est la raison de mon tweet.
Li Yang (animateur) : J’ai un peu le même sentiment. Ces derniers mois, on entend soudain des gens dire « Ethereum est fini », alors que quelques mois plus tôt ils disaient encore « adoptons Ethereum ». Ce retournement est tellement rapide, comme si tout le monde se précipitait pour pousser un mur qui s’effondre. C’est assez incroyable.
3. Qu’est-ce qu’une Layer 2 de Bitcoin ?
Li Yang (animateur) : Si CKB est une Layer 2 de Bitcoin, alors le point central est que nous savons bien ce qu’est une Layer 2 d’Ethereum, mais personne n’a encore d’idée claire sur celle de Bitcoin. Selon toi, qu’est-ce qu’une Layer 2 de Bitcoin ?
Jan Xie : Historiquement parlant, le concept initial était celui d’« Off-Chain », opposé à « On-Chain ».
Beaucoup de choses sont faites sur la chaîne (On-Chain), qu’il s’agisse de calcul, de stockage ou d’autres opérations. En raison de diverses contraintes, les performances sont fortement limitées, tout comme la capacité d’évolution. Dès lors, on souhaite déplacer certaines opérations hors chaîne. En réfléchissant ainsi, on a vu apparaître toutes sortes de protocoles Off-Chain. À mes yeux, le terme « Off-Chain » englobe tout : Layer 2, Layer 3, ou même Layer N.
Au départ, les structures étaient simples, comme des canaux unidirectionnels. Il n’y avait à l’époque que cette structure élémentaire, déjà discutée dès les premiers jours du forum Bitcoin.
Progressivement, le concept d’Off-Chain s’est enrichi : peut-on créer des canaux bidirectionnels ? Peut-on construire une autre blockchain reliée à la première ? Peut-on faire du minage fusionné (Merged Mining) ? Peut-on combiner des canaux bidirectionnels en un réseau ?
En regardant en arrière, on constate un chemin clair d’évolution : les gens ont progressivement ajouté des concepts et structures de plus en plus complexes. Des structures simples sont devenues complexes, donnant naissance à une classification fine. On distingue alors deux grandes catégories : basées sur des canaux (Channel-based) ou sur des chaînes (Chain-based).
Avant l’avènement d’Ethereum, les protocoles Off-Chain étaient déjà largement étudiés. Toutefois, ils étaient alors limités par les capacités techniques de Bitcoin. En raison des restrictions de programmabilité, les avancées étaient modestes et progressives.
Après l’arrivée d’Ethereum, on a vu plusieurs détours : d’abord le sharding, puis les State Channels, ensuite Plasma, et enfin le consensus autour du Rollup. C’est ainsi qu’Ethereum a progressivement adopté une feuille de route centrée sur les Rollups. La décision finale a été prise : la Layer 1 doit être optimisée pour les Rollups. Le plan de sharding a dû être revu, afin d’ajouter davantage d’espace de stockage utile aux Rollups au niveau de la Layer 1.
Cela reflète probablement une caractéristique humaine : nous accordons plus d’importance à ce qui est récent. Actuellement, les Rollups dominent notre attention, donc quand on parle de Layer 2, on pense immédiatement aux Rollups. C’est naturel, surtout pour les chercheurs ou développeurs occasionnels. Mais en examinant toute l’histoire des évolutions, la notion de Layer 2 devient beaucoup plus large.
Si tu me demandes une définition, je dirais que la Layer 2 est d’abord Off-Chain, donc pas directement sur la chaîne. Elle entretient un lien direct avec la Layer 1. Une Layer 3, en revanche, serait liée à la Layer 2, pas à la Layer 1 – c’est là la signification du mot « couche ».
Ensuite, la Layer 2 permet d’apporter à la Layer 1 des capacités accrues, qu’il s’agisse de performance, de fonctionnalités contractuelles ou de confidentialité. Globalement, il y a trois axes : résoudre les problèmes de performance, de programmabilité ou de confidentialité. Et elle entretient un lien direct avec la Layer 1, que ce soit au niveau du consensus (comme le minage fusionné), via un pont (bridge) – appelé Two-Way Peg (2WP) dans l’écosystème Bitcoin, Bridge dans celui d’Ethereum – ou par tout autre type de lien, même économique.
Telle est ma définition de la Layer 2 : assez large.
Li Yang (animateur) : En ce qui concerne les définitions, dans l’écosystème Bitcoin, personne n’a encore réussi à imposer une norme claire pour la Layer 2, du moins pour l’instant. Je ne sais pas si cela arrivera un jour.
Jan Xie : C’est justement ce qui rend l’écosystème Bitcoin plus passionnant. Chaque équipe peut avoir sa propre vision. Dans cet écosystème, on n’a pas à craindre qu’un jour Satoshi Nakamoto sorte de l’ombre pour dire que votre projet est incorrect et le fermer. Cet événement aléatoire ne se produira probablement pas dans l’écosystème Bitcoin. En revanche, ici, vous devez faire preuve de davantage de force, participer à une compétition plus intense, car personne ne viendra vous dire qui a raison ou tort. Personne ne vous aidera ; vous devez compter uniquement sur vous-même.
4. Projets influents de Layer 2 sur Bitcoin
Li Yang (animateur) : Parmi les Layer 2 actives sur Bitcoin, quels projets sont les plus influents ou prometteurs ?
Jan Xie : Je peux en citer quelques-uns, même si ma liste risque d’être incomplète.
Celui qui a eu le plus d’impact est probablement Lightning (le réseau Lightning). Il existe depuis longtemps et progresse lentement mais sûrement, avec des itérations techniques constantes. De l’extérieur, on le connaît sous le nom de Lightning, mais personnellement, j’adore le concept de réseau de canaux (Channel Network).
Son avantage principal est sa scalabilité théorique quasi illimitée, contrairement à d’autres solutions qui présentent des goulets d’étranglement clairs au niveau du protocole. Le modèle canal n’a pas ce problème. Toutefois, en pratique, sa mise en œuvre rencontre de nombreux obstacles, ce qui explique sa progression lente et ses nombreux défis. C’est fascinant : plus un sujet est difficile, plus il est intéressant. Ce n’est pas impossible en théorie, mais on ne sait pas encore comment le résoudre.
Prenons un exemple intéressant dans un réseau de canaux : un réseau composé de plusieurs canaux, A vers B, B vers C, C vers D. Supposons que A veuille envoyer de l’argent à F. Ce montant peut être divisé en plusieurs paiements envoyés via différents chemins. Par exemple, 10 dollars peuvent être scindés en dix paiements d’un dollar chacun. Comment garantir que les dix dollars arrivent ensemble à F – soit tous réussissent, soit tous échouent ?
C’est un problème classique en théorie des graphes, ou bien un défi courant dans les réseaux de données. Sur Internet, les paquets sont transmis de cette manière : fragmentés, envoyés via différents chemins, puis recombinés à destination. C’est un problème de routage. Mais dans un réseau de valeur, cela devient extrêmement complexe, car on transfère de la valeur, des actifs, pas simplement des données.
Quelle est la différence ? En transmission de données, le canal (qu’on peut simplifier comme un câble entre deux ordinateurs) a une capacité illimitée. Je peux continuer à t’envoyer des messages sans interruption. Mais dans un réseau de valeur comme Lightning, chaque transfert consomme la capacité du canal. Par exemple, si j’ai initialement 100 dollars de mon côté et toi zéro, après dix transferts de 10 dollars, mon côté est vide. Impossible de continuer sans rouvrir un canal.
Ces différences rendent le réseau Lightning bien plus complexe qu’un réseau de données. Et comme il implique de l’argent, la sécurité devient critique. C’est un problème très complexe. Après tant d’années, Lightning progresse régulièrement, malgré sa difficulté. Pendant longtemps, on a critiqué son lent développement, accusant Bitcoin de ne pas avancer. Mais ce n’est pas vrai : c’est juste un problème extrêmement difficile. Comparer Lightning à d’autres solutions revient à comparer des problèmes de difficultés inégales. Les solutions basées sur des canaux sont intrinsèquement plus difficiles que celles basées sur des chaînes. Lightning ajoute même une exigence supplémentaire : la confidentialité. Cela rend tout encore plus compliqué. Si Lightning fonctionne sur TON, chaque étape doit préserver la vie privée – une tâche redoutable.
Quoi qu’il en soit, j’adore ce projet. Revenons-en : Lightning est bel et bien une Layer 2.
Ensuite, Liquid, un sidechain développé par Blockstream. Son article fondateur se qualifiait lui-même de sidechain. Le consensus de Liquid repose sur le Proof of Authority (PoA), que l’on peut assimiler à une multisignature : 10 personnes prennent alternativement part à la production des blocs. Le pont entre Liquid et Bitcoin, appelé Two-Way Peg (2WP) dans l’écosystème Bitcoin, est également une multisignature. Donc, un sidechain multisignature relié par un pont multisignature.
Ce qui rend Liquid intéressant, c’est qu’il vise à la fois à améliorer l’évolutivité de Bitcoin (rendre les transferts moins coûteux), et à servir de laboratoire technologique pour Bitcoin. Car Liquid est structurellement similaire à Bitcoin, mais intègre des fonctionnalités qu’il est difficile d’implémenter directement sur la Layer 1, comme la confidentialité ou les Contrats (Covenants).
Grâce à ces éléments, on peut construire une Layer 3 sur Liquid. Par exemple, déployer Lightning sur Liquid. Normalement, l’ouverture et la fermeture de canaux Lightning se règlent sur la Layer 1. Mais si l’on règle ces opérations sur la Layer 2, la capacité globale de Lightning augmente.
Liquid est donc un excellent terrain d’expérimentation. Si vous êtes prêt à accepter son caractère centralisé et nécessitant confiance, l’expérience utilisateur est meilleure : frais plus bas, et structure UTXO similaire à Bitcoin.
Un autre projet consiste à superposer une couche EVM à Bitcoin, combinée à du minage fusionné (merge mining) : Rootstock. C’est aussi un excellent projet, avec des améliorations notables au niveau du consensus et du merge mining. Leur technologie est solide.
Toutefois, le merge mining pose des problèmes. La sécurité de la Layer 2 dépend alors entièrement des mineurs Bitcoin. Or, ces derniers n’ont pas nécessairement intérêt à protéger la Layer 2 : si celle-ci s’effondre, cela n’affecte pas leurs revenus tant que la Layer 1 continue de fonctionner.
Le merge mining est donc souvent critiqué : la majorité de la puissance de calcul Bitcoin pourrait facilement attaquer n’importe quelle chaîne en merge mining. C’est un reproche que Rootstock pourrait subir. D’autres projets suivent cette voie, cherchant à résoudre ces problèmes, par exemple en alignant les incitations. Drivechain, par exemple, explore ce domaine.
Il y a aussi Stacks, qui a récemment effectué une mise à jour majeure, rapprochant davantage son système de Bitcoin. Personnellement, je considère toujours Stacks comme un sidechain, malgré ses ajustements. Sa nouvelle architecture utilise divers mécanismes pour démontrer comment Stacks est lié au consensus de Bitcoin, comment les données sont stockées sur la Layer 1, de sorte que lorsque la Layer 1 finalise, la Layer 2 finalise aussi. Mais pour moi, c’est toujours un sidechain.
Stacks présente plusieurs aspects intéressants. D’abord, son consensus est original : il exige que les participants verrouillent du BTC sur la Layer 1 pour participer au consensus, ce qu’on appelle le Proof of Transfer (PoX). Ensuite, il lie ce consensus à la conception de son pont : il faut staker le jeton natif STX pour participer à la signature multisignature du pont. Bien qu’il s’agisse techniquement d’un pont multisignature, les signataires sont permissionless : n’importe qui peut participer en stakant du STX. En contrepartie, ils reçoivent du BTC – provenant des frais en BTC payés lors des transferts, et d’une partie du BTC misé par les mineurs Stacks participant au PoX. C’est donc un ensemble de mécanismes très innovants.
Sur Stacks, les capacités de programmation sont renforcées, permettant davantage d’applications. Stacks a conçu un langage appelé Clarity, plus sécurisé et formellement vérifiable.
Cette mise à jour de Stacks, je pense, renforce significativement son lien avec Bitcoin, tant au niveau du consensus que du pont. Avant, sa stratégie était plus distante de la Layer 1 ; maintenant, elle est plus intégrée.
Un autre projet récent, non sidechain mais couche de staking : Babylon. Ce protocole permet d’utiliser directement du BTC sur Bitcoin pour du staking, garantissant ainsi la sécurité de diverses autres chaînes Layer 2. C’est un peu comme EigenLayer sur Ethereum, qui fait du Restaking. Babylon, lui, permet de staker du BTC sur Bitcoin pour sécuriser des chaînes Layer 2, qui peuvent toutes être des chaînes PoS.
Voilà les projets de Layer 2 Bitcoin que je trouve les plus intéressants pour l’instant.
Li Yang (animateur) : Mis à part Babylon, relativement nouveau, les autres chaînes sont anciennes – au moins trois ou quatre ans, voire plus pour Lightning. Je connais assez bien Lightning et Stacks, mais j’ai rarement entendu parler des progrès de Liquid. Mon impression est que Lightning ressemble à un groupe de scientifiques travaillant sur une fusion nucléaire contrôlée : formidable, mais extrêmement difficile, on ne sait pas quand ça aboutira. Quant aux autres projets, leurs objectifs sont flous, ou les utilisateurs s’en moquent. Ai-je raison ?
Jan Xie : Pas entièrement. À mon avis, l’écosystème futur de la Layer 2 accueillera une coexistence de différents types de projets.
Lightning est particulier car basé sur des canaux, avec une logique fondamentalement différente. Les solutions basées sur des canaux et celles basées sur des chaînes ont chacune leurs forces et faiblesses. J’apprécie beaucoup Lightning et les modèles basés sur des canaux, mais ils ont aussi leurs problèmes.
Premièrement, il y a le problème de liquidité des canaux. Comme mentionné précédemment, pour transférer de l’argent via un canal, il faut déjà avoir des fonds de mon côté. Si je suis un nouvel utilisateur, pour ouvrir un canal et envoyer de l’argent, je dois d’abord déposer des fonds au moment de la création. C’est fastidieux pour l’utilisateur moyen.
Deuxièmement, la gestion de la liquidité est compliquée. Si je t’envoie régulièrement de l’argent (par exemple, en tant que patron à un employé), cela crée un flux unidirectionnel. Après trois salaires, mon côté est vide. Je dois alors fermer le canal et en ouvrir un nouveau, ou trouver un moyen de réinjecter de la liquidité. Fermer et rouvrir un canal implique une transaction sur la Layer 1, ce qui est coûteux et lent.
Troisièmement, si quelqu’un veut t’envoyer de l’argent, tu dois déjà avoir un canal ouvert. Contrairement à un rollup, où un nouvel utilisateur n’a aucun prérequis : il suffit de lui envoyer de l’argent à son adresse, et plus tard, il pourra dépenser ces fonds en ouvrant son compte sur le rollup. C’est bien plus convivial pour l’utilisateur individuel.
Les canaux impliquent aussi de nombreuses tâches de gestion. Par exemple, lors de l’ouverture, il faut configurer divers frais. Lors de la fermeture, si les frais sont élevés, il faut ajuster la transaction, ce qui requiert des mécanismes complexes. Un problème pénible.
En résumé, les Layer 2 basées sur des canaux me semblent mal adaptées aux utilisateurs ordinaires (C-end). Si tu es un simple utilisateur, que tu préfères éviter la complexité, que tu acceptes de faire confiance à des tiers, ou que tu ne joues qu’avec de petites sommes, les solutions basées sur des chaînes te conviendront mieux.
Lightning convient mieux aux scénarios B2B. Si tu es une entreprise ayant de véritables besoins commerciaux, tu pourrais apprécier la confidentialité ou la scalabilité exceptionnelle de Lightning, et tu aurais les compétences et la volonté de gérer les canaux. Imagine une banque embauchant une équipe dédiée à la gestion des canaux – ce n’est pas un problème. Les utilisateurs particuliers, en revanche, ne veulent pas s’embêter avec ça. Mais ils seront heureux d’utiliser des rollups ou sidechains, plus conviviaux.
Comment transférer la liquidité entre ces chaînes ? Là, les canaux peuvent jouer un rôle important. En ouvrant des canaux des deux côtés, on peut intégrer les chaînes dans un vaste réseau de canaux, permettant une circulation fluide des actifs.
À long terme, ces projets et solutions pourraient coexister et se compléter.
5. Les inscriptions vont-elles accélérer le développement de la Layer 2 Bitcoin ?
Li Yang (animateur) : Avant les inscriptions, il n’y avait guère de demande pour des solutions destinées aux utilisateurs grand public. Peut-être parce que ces solutions n’étaient pas assez matures. Ou bien, comme je le pense, parce que les détenteurs de Bitcoin les conservaient simplement. Avec les inscriptions, beaucoup ont commencé à effectuer des opérations fréquentes sur la chaîne. Penses-tu que les inscriptions et le regain d’activité qui suit vont accélérer massivement le développement de l’écosystème Bitcoin, ou du moins le rendre plus ciblé ?
Jan Xie : Oui, absolument. Le boom des inscriptions ressemble beaucoup aux ICO sur Ethereum. Beaucoup partagent ce point de vue, et je suis entièrement d’accord.
Les inscriptions attirent de nouveaux utilisateurs et créent de nouveaux actifs, mais elles ne résolvent pas le problème fondamental : sur Bitcoin, il n’y a rien d’autre à faire qu’émettre des actifs. Contrairement à Ethereum, dont la Layer 1 permet déjà de nombreuses actions, après une ICO, on peut continuer à développer sur Ethereum. Sur Bitcoin, une fois l’actif émis, si on veut faire davantage, il faut passer hors chaîne, Off-Chain, donc sur une Layer 2.
Ainsi, je pense que les inscriptions vont inévitablement attirer davantage d’attention, d’utilisateurs et de capitaux vers l’écosystème Off-Chain ou Layer 2.
6. Comment CKB va-t-elle aborder la Layer 2 Bitcoin ?
Li Yang (animateur) : Alors, comment CKB va-t-elle aborder la Layer 2 Bitcoin ?
Jan Xie : Dans le cadre de la Layer 2 Bitcoin, CKB peut être classée comme une Sovereign Chain. Si vous étudiez la typologie, il existe une catégorie de chaînes souveraines : elles ont leur propre consensus et un lien avec la blockchain Bitcoin. CKB a son propre consensus, son propre PoW.
Pour que CKB devienne une Layer 2 de BTC, un élément indispensable est un pont entre les deux. Ce pont peut être centralisé, décentralisé, ou hybride. C’est une condition nécessaire : grâce à lui, les actifs Bitcoin peuvent être transférés vers CKB, ouvrant de nouveaux cas d’usage.
Outre le pont, CKB possède des caractéristiques distinctives par rapport aux autres Layer 2 Bitcoin. Par exemple, CKB prend en charge divers algorithmes de signature. Cela signifie que les applications sur CKB peuvent être utilisées directement avec des portefeuilles Bitcoin, comme MetaMask pour Ethereum.
Pour l’utilisateur, cela renforce l’impression d’appartenir au même écosystème – un point crucial pour réduire la barrière d’entrée. Pour un utilisateur Bitcoin, passer de UniSat sur la Layer 1 à MetaMask sur la Layer 2 serait déroutant.
Sur CKB, c’est transparent : tu peux verrouiller tes actifs sous une adresse Bitcoin, puis les récupérer avec un portefeuille Bitcoin. L’utilisateur, même ignorant la technologie, perçoit qu’il reste dans l’écosystème Bitcoin, sans jamais en sortir. Il peut même croire qu’il opère toujours sur Bitcoin, alors que beaucoup d’opérations se déroulent en réalité sur la Layer 2.
Sous cet angle, nous pourrions même offrir une expérience supérieure à Lightning. L’utilisateur ne sent pas qu’il a changé de lieu. Pont et expérience utilisateur sont des atouts de CKB.
Pour les développeurs, que se passe-t-il quand on arrive sur la Layer 2 ? Entre-t-on dans le monde EVM et Account Model, ou reste-t-on dans l’univers UTXO ? Les deux types de développeurs existent. CKB convient bien à ceux qui apprécient l’architecture technique de Bitcoin, qui aiment travailler dans l’univers UTXO, et qui maîtrisent les deux paradigmes. D’autres développeurs s’en moquent, mais doivent supporter le changement mental constant : coder un jour en UTXO, un autre en Account Model. C’est fatiguant, surtout pour un pont, où il faut écrire des contrats des deux côtés. Mais si tu veux juste développer sur la Layer 2, le modèle importe peu.
Pour les développeurs, l’avantage de CKB est son isomorphisme avec Bitcoin. Beaucoup de choses semblent naturelles et pratiques, car on peut y faire davantage. Ce que CKB doit faire : améliorer l’expérience utilisateur et développeur. Construire un bon pont, fournir des outils, afin que les développeurs puissent créer leurs applications facilement. C’est notre objectif.
Li Yang (animateur) : Tu as dit que les utilisateurs pouvaient utiliser UniSat à la fois pour Bitcoin et CKB. Cela nécessite-t-il une adaptation de la part de UniSat ?
Jan Xie : Non, aucune adaptation n’est nécessaire de la part de UniSat. Tout portefeuille Bitcoin disposant d’une interface de signature fonctionne. L’adaptation se fait au niveau du contrat CKB, qui peut valider les signatures. Peu importe l’algorithme de signature ou de hachage utilisé, le portefeuille signe une transaction, et le contrat sur CKB vérifie cette signature.
CKB dispose de la capacité d’implémenter divers algorithmes cryptographiques : Secp256k1, Schnorr, etc. C’est simple sur CKB, car c’est une machine virtuelle RISC-V. Il suffit de porter les implémentations existantes de Bitcoin. Si tu maîtrises C ou Rust, tu peux les copier-coller directement dans la VM CKB.
Contrairement à Ethereum, où il faudrait réécrire un algorithme C en Solidity, ce qui est coûteux, risqué (bugs), et produit un code lent. Peu de gens osent le faire.
Ces problèmes n’existent pas sur CKB. C’est pourquoi CKB peut prendre en charge facilement divers algorithmes cryptographiques, y compris UniSat.
Li Yang (animateur) : Donc, avec UniSat, je peux transférer mes bitcoins vers CKB, puis les utiliser sur CKB pour diverses opérations : créer des inscriptions, acheter, vendre, etc.
Jan Xie : Exactement.
Li Yang (animateur) : L’expérience semble donc très agréable. Changer de portefeuille est toujours un obstacle psychologique et pratique pour l’utilisateur.
Jan Xie : En comparant toutes les Layer 2, celles qui préservent l’expérience utilisateur et développeur de Bitcoin forment une catégorie. D’autres auront des positions différentes, ciblant d’autres groupes d’utilisateurs.
7. Que faire après avoir migré Bitcoin vers la Layer 2 ?
Li Yang (animateur) : L’expérience Ethereum montre que toute solution incompatible avec EVM ou MetaMask peine à être considérée comme une vraie Layer 2 Ethereum, et peine à migrer les utilisateurs. Donc, après avoir migré Bitcoin vers CKB, que peut-on faire ? Que peuvent faire les développeurs, les utilisateurs ?
Jan Xie : Excellente question. On peut faire beaucoup de choses, car CKB est un modèle UTXO amélioré. Jian a écrit un excellent article : « Comprendre la programmabilité de CKB à travers les applications Bitcoin ». Je vous invite à le lire, il explique très clairement.
Ces améliorations se manifestent sur plusieurs plans. D’abord, au niveau de la machine virtuelle : sur Bitcoin, on ne peut écrire qu’avec Bitcoin Script, un langage simple, minimaliste, avec peu d’instructions. C’est une limitation fondamentale de l’expressivité contractuelle.
Sur CKB, nous avons implémenté l’ensemble complet de l’instruction set RISC-V. RISC-V est un jeu d’instructions développé depuis des années, largement adopté dans l’industrie, open source, compatible avec GCC et LLVM. Ainsi, on peut utiliser divers langages de programmation sur CKB.
Ensuite, l’amélioration du modèle UTXO. Sur CKB, chaque UTXO peut contenir davantage de données arbitraires, pas seulement un montant. Sur Bitcoin, un UTXO ne stocke que deux informations : le nombre de Sats et le propriétaire.
Sur CKB, un UTXO peut stocker des données libres : une chanson, une image, un fichier. On peut aussi y placer un TypeScript, qui décrit les règles de modification des données. Par exemple, si un poème est stocké, le TypeScript peut spécifier : « On ne peut qu’ajouter à la fin, jamais modifier le début. Chaque contributeur ne peut ajouter qu’à la fin ». C’est une règle de modification des données – une avancée.
Autre innovation : dans CKB, un script peut lire les données d’autres UTXO, ce qui est impossible sur Bitcoin. Grâce à ces capacités, CKB permet facilement des fonctionnalités comme les Covenants (clauses restrictives). Un Covenant permet de spécifier, dans le script d’un UTXO, que les nouveaux UTXO générés doivent avoir un script ou une adresse spécifique.
Sans Covenant, après avoir dépensé un UTXO, les nouveaux UTXO peuvent être configurés librement. Avec Covenant, on peut restreindre toute une chaîne d’UTXO futures. Cette propriété est cruciale. Elle détermine si l’on peut construire des Layer 2 comme les Rollups sur Bitcoin. Sans elle, c’est impossible. Avec elle, c’est faisable. C’est pourquoi les Covenants sont aujourd’hui très discutés, avec des propositions pour les intégrer à la Layer 1. Mais sur CKB, ils existent naturellement.
Avec tout cela, CKB permet de créer des jetons fongibles (FT), des NFT, des applications DeFi, DAO, des systèmes de gouvernance, des mondes autonomes, des jeux entièrement sur chaîne.
En réalité, tout ce que l’on peut faire sur Ethereum est faisable sur CKB. La différence est comme entre iPhone et Android : des architectures sous-jacentes différentes. La structure UTXO de CKB ressemble beaucoup à Git. GitHub, le plus grand site communautaire pour développeurs, repose sur Git, un outil de gestion de dépôts.
CKB ressemble à un immense Git partagé, comme GitHub. On peut y déposer n’importe quoi : du code C, du Python, des poèmes, des articles, y tenir un blog, y stocker des images ou des fichiers binaires obscurs. Chaque fichier a une propriété claire : celui-ci appartient à Li Yang, seul Li Yang peut le modifier ; celui-là à Jan. Certains fichiers sont communs, modifiables par tous, mais sous conditions définies par contrat. Ce gigantesque dépôt mondial, dont le stockage et les modifications sont sécurisés par un consensus PoW, permet de construire n’importe quelle application.
Li Yang (animateur) : Quand tu as parlé d’iPhone et d’Android, j’ai eu une idée. Peut-on dire que Bitcoin est une version primitive d’Android, open source, Ethereum en est une dérivée plus fonctionnelle mais centralisée comme l’iPhone, et CKB serait comme une version avancée d’Android basée sur cette base open source ?
8. CKB : Contract Kernel of Bitcoin
Li Yang (animateur) : J’ai lu un commentaire de Yang Min disant « CKB : Contract Kernel of Bitcoin ». Que signifie « Contract Kernel » ?
Jan Xie : Il considère Bitcoin comme une couche d’émission et de stockage d’actifs. Nous pouvons utiliser Bitcoin comme un coffre-fort ultra-sécurisé pour stocker de la valeur.
Mais ce coffre est vide. Si nous voulons donner un usage à ces actifs, construire des produits, il nous faut un moteur d’exécution pour implémenter la logique applicative.
Le « Contract Kernel » est précisément ce moteur d’exécution. En complément d’une blockchain SOV (store of value) comme Bitcoin, il permet de stocker les act
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@CKBEcoFund
