Discussion with Bitlayer, CKB, and Bool Network (Part 2): Perspectives on Technical Solutions for the BTC Ecosystem
TechFlow SélectionTechFlow Sélection
Discussion with Bitlayer, CKB, and Bool Network (Part 2): Perspectives on Technical Solutions for the BTC Ecosystem
Trois invités discutent de ponts cross-chain pour Bitcoin, de BitVM, du réseau Lightning et de RGB ainsi que de RGB++.
Dédié à des analyses Web3 approfondiesModérateur : Jomosis, geek web3
Invités : Kevin He, co-fondateur de Bitlayer ;
Baiyu, associé du fonds CKB Eco Fund ;
Kai, chercheur chez Bool Network
Le 16 mai au soir, geek web3 a invité des représentants de Bitlayer, CKB et Bool Network à un débat sur Twitter Space autour des nombreuses questions liées aux couches 2 du Bitcoin. De nombreux sujets intéressants ont été abordés. En raison de la quantité importante d'échanges, le compte rendu écrit est divisé en deux parties. La deuxième partie couvre les questions suivantes :
-
Comparé à Ethereum, Bitcoin n'est pas adapté comme couche 1 pour accueillir des couches 2. Quels sont les obstacles concrets posés par Bitcoin ?
-
Il y a deux jours, le pont xlink a perdu plus de 4 millions de dollars à cause d'une fuite de clé privée. La sécurité des ponts, notamment des ponts de retrait, est l'un des problèmes centraux des Layer2. Comment votre équipe résout-elle ce problème de sécurité des ponts de retrait ?
-
Le réseau Lightning et le protocole RGB ont tous deux suscité de grands espoirs, mais leurs écosystèmes restent décevants. Quelle est votre opinion à ce sujet ?
-
Parmi les projets actuels de la couche 2 Bitcoin, lesquels vous semblent techniquement ou narrativement supérieurs ? Pourquoi ?
-
Pour que les couches 2 du Bitcoin atteignent une popularité comparable à celles d’Ethereum, combien de problèmes restent-ils à résoudre ?
Au cours des discussions, les intervenants ont livré plusieurs phrases marquantes. Baiyu a déclaré franchement : « À mon avis, le plus grand obstacle pour l’écosystème Bitcoin, c’est qu’Ethereum a été trop réussi. Les esprits gardent de profondes empreintes mentales issues d’Ethereum. »
En raison de la longueur du texte, nous l’avons divisé en deux parties. Voici donc la deuxième moitié, que nous vous invitons à lire pour puiser de l’inspiration dans les propos passionnants des intervenants.
Lien vers la première partie :« Dialogue avec Bitlayer, CKB et Bool Network (Partie 1) : Grand débat entre courants opposés de la couche 2 Bitcoin »
1. Jomosis : Bitcoin n’est en réalité pas adapté comme couche 1 pour héberger des couches 2. Où se situent précisément les obstacles qu’il pose ?
Kevin : Principalement au niveau de la mise en œuvre technique des Layer2. Personnellement, je pense que la clé d’une couche 2 réside dans sa reconnaissance par les gros portefeuilles, notamment les baleines, qui doivent la juger sûre. Or, selon mes observations, beaucoup de détenteurs importants hésitent encore à transférer leurs BTC vers une couche 2 ou à entrer dans des canaux de rendement peu fiables, et font souvent davantage confiance aux exchanges centralisés (CEX).
On peut toutefois observer des projets comme Babylon, qui propose un modèle de sécurité clair et résout effectivement certains problèmes. Ces initiatives gagnent progressivement la confiance des détenteurs de BTC, voire des investisseurs institutionnels. Elles montrent qu’il est possible d’utiliser Bitcoin de manière sécurisée sur une couche 2 ou ailleurs, en bloquant les actifs sur la chaîne principale tout en générant des rendements ailleurs. Ce scénario gagne en acceptation auprès des utilisateurs.
Revenons à notre question initiale. D’un point de vue technique, la multiplicité des approches s’explique essentiellement par les limites inhérentes à Bitcoin. Plus précisément, la blockchain Bitcoin manque de capacité de vérification. Lorsqu’elle ne peut pas valider, il devient difficile de vérifier qu’une opération de retrait a bien eu lieu sur la couche 2 lors du retour vers la couche 1, compromettant ainsi la sécurité du pont bidirectionnel.
De plus, sous le modèle UTXO, chaque UTXO constitue un espace indépendant, ce qui rend difficile leur interconnexion. Des fonctionnalités comme les Covenants n’ont pas encore été adoptées par la communauté.
Un autre point critique : Bitcoin n’a pas d’état global. Sans état global, il est impossible de mettre en œuvre certaines fonctionnalités telles que les salles d’évacuation (escape hatch), les retraits forcés, ou encore des actions conditionnelles basées sur des résultats de validation. On doit alors recourir à des indexeurs hors chaîne, à des nœuds légers lisant les transactions, ou à des méthodes spécifiques pour indexer ou relier les données.
En somme, la perception du Bitcoin et de ses couches 2 doit évoluer, et des percées techniques restent nécessaires. Par exemple, CKB innove avec son modèle Cell, tandis que BitVM tente d’introduire des mécanismes de vérification sur Bitcoin, transformant ainsi radicalement l’écosystème et le rendant plus performant qu’auparavant.
Baiyu : Je pense que l’obstacle principal est que Ethereum a été trop réussi, laissant une empreinte mentale forte dans les esprits. À son époque, Ethereum était très avant-gardiste. Il a brisé le conservatisme de la communauté Bitcoin en montrant qu’on pouvait utiliser la blockchain comme plateforme de contrats intelligents, abandonnant le modèle UTXO au profit du modèle de comptes.
Bien qu’Ethereum ait semblé novateur à l’époque, on constate aujourd’hui qu’il convient surtout aux applications financières. Même son fondateur reconnaît qu’il s’agit d’un monde fortement financiarisé. Le seul exemple massif d’application non financière serait ENS, dont le prix a même été artificiellement soutenu par une déclaration de Vitalik Buterin — ce qui est ironique.
Aujourd’hui, en voulant construire dans l’écosystème Bitcoin, on retombe souvent dans le piège de recopier ce qui existe sur Ethereum. Beaucoup s’évertuent à bâtir dans l’écosystème Bitcoin, mais peuvent être désorientés par une simple remarque venant des grandes figures d’Ethereum. Récemment, j’ai rencontré un ami qui envisageait de rejoindre l’équipe nord-américaine de CKB. Mais après avoir entendu mon projet, il m’a demandé : « Tout cela existe déjà sur Ethereum, pourquoi aller sur Bitcoin ? »
Beaucoup d’experts pensent comme lui : ils considèrent que tout ce qui se fait sur Bitcoin existe déjà sur Ethereum, donc pourquoi recommencer ? Cette question m’agace profondément. Cette fois-ci, l’enjeu crucial est de réfléchir à ce que l’écosystème Bitcoin peut faire et que celui d’Ethereum ne peut pas faire. Ethereum change constamment, mais finit toujours par revenir au Staking, puis au Restaking. Devons-nous reproduire cela sur Bitcoin ?
Se libérer de cette empreinte mentale issue d’Ethereum est essentiel. C’est aussi le principal frein à l’entrée des talents dans l’écosystème Bitcoin. Comment attirer les meilleurs esprits, les cerveaux les plus brillants, pour continuer à repousser les frontières de la blockchain ?
2. Jomosis : Il y a quelques jours, le pont xlink a perdu plus de 4 millions de dollars à cause d’une fuite de clé privée. La sécurité des ponts, en particulier des ponts de retrait, est l’un des problèmes centraux des Layer2. Beaucoup de Layer2 utilisent encore des ponts multisignatures simples, vulnérables aux complicités internes ou aux attaques externes. Pouvez-vous expliquer comment vos équipes respectives abordent la sécurité des ponts de retrait ?
Kai : En résumé, le problème des ponts Bitcoin vient du fait que, contrairement à Ethereum, les scripts Bitcoin ne sont pas Turing-complets. Impossible donc d’exécuter directement sur Bitcoin les mêmes mécanismes de vérification. Face à cela, nous avons réfléchi chez Bool Network. L’approche la plus simple revient à traiter chaque couche 2 comme un exchange centralisé. Pour les transferts bidirectionnels, un gestionnaire d’actifs décentralisé pourrait superviser les opérations.
Bool Network prolonge cette idée en cherchant à rendre le gestionnaire d’actifs plus décentralisé. Notre première étape consiste à sécuriser les témoins du pont. Nous utilisons un système POS permettant un accès sans permission. Ensuite, nous sélectionnons dynamiquement des témoins parmi le réseau Bool via TEE, MPC et notre propre RingVRF. En bref, parmi 200 nœuds, quelques-uns sont choisis aléatoirement par un algorithme pour servir de témoins.
Le TEE garantit que le code s’exécute strictement selon les règles définies, rendant extrêmement difficile toute altération par des tiers. Grâce à MPC, les clés de gestion du pont changent continuellement, en rotation parmi les centaines de nœuds du réseau Bool.
Cependant, les nœuds du réseau Bool étant publics, il faut aussi préserver la confidentialité pour empêcher les attaquants d’identifier les gestionnaires de clés. Nous avons donc développé RingVRF avec protection de la vie privée : vous pouvez prouver que votre clé publique appartient à un ensemble de N clés (lui-même caché cryptographiquement), sans révéler laquelle. Cette preuve se fait via ZK, et vous diffusez seulement une clé de communication temporaire.
Notre logique globale est donc claire : nous dissimulons les nœuds du comité DHC (Dynamic Hidden Committee) au sein du vaste réseau de témoins (des centaines, voire milliers de nœuds). Via ZK + RingVRF, les identités (clés publiques) des témoins sont masquées. Personne ne sait qui sont les témoins du pont. Chaque nœud exécute TEE, MPC et le programme central dans un environnement sécurisé où les calculs restent invisibles. Même les témoins sélectionnés ignorent parfois qu’ils ont été choisis. Cela empêche toute collusion ou attaque externe.
Baiyu : Pour CKB, nous classons les actifs en deux catégories : le Bitcoin lui-même, et les actifs dérivés émis sur Bitcoin, comme BRC-20 ou divers runes. Nous avons étudié en interne que, sans fork dur ou doux, la solution idéale pour connecter Bitcoin à une couche 2 est BitVM, mais sa mise en œuvre prendra encore du temps. Ainsi, à court terme, aucune méthode cryptographiquement sécurisée ne permet de faire voyager Bitcoin de façon sûre entre les couches 1 et 2.
Dans ce contexte, les ponts Bitcoin tendent vers deux extrêmes. L’un est extrêmement centralisé, comme un établissement financier agréé. Les gros portefeuilles font confiance car ils sont régulés. WBTC en est l’exemple typique, avec une capitalisation de dizaines de milliards d’euros sur Ethereum, géré par BitGo.
L’autre extrême vise une décentralisation maximale. Mais attention : tous les ponts ne se valent pas. Il ne faut pas croire que tous les ponts sont équivalents. Leur degré de confiance varie énormément — parfois plus que la différence entre un pont et un non-pont. Il faut examiner leur niveau de confiance. Le meilleur cas ressemble à un modèle POS, utilisant des incitations économiques pour approcher la sécurité cryptographique : pénaliser les témoins malhonnêtes.
Mais la plupart des modèles de ponts Bitcoin ont déjà été testés dans les ponts BTC-ETH. Toutes les façons de sortir le Bitcoin pour l’envoyer sur Ethereum ont déjà été explorées. Inutile d’inventer quoi que ce soit de nouveau. Parmi les solutions plus décentralisées, on trouve TBTC, mais son utilisation reste limitée.
CKB collabore actuellement avec Bool Network, et développe aussi un pont similaire à WBTC. En outre, nous travaillons sur des protocoles d’actifs de type UTXO, comme RGB++, permettant un transfert sans confiance entre CKB et d’autres blockchains UTXO grâce au lien isomorphe.
Nous examinons aussi si ce lien isomorphe peut être combiné avec DLC ou les avancées de BitVM pour permettre une validation sur BTC, afin d’émettre un RBTC (similaire à un BTC enveloppé). Ces pistes sont prometteuses, mais rien n’est encore décidé.
Soyez donc vigilants : les ponts sont des pots de miel remplis d’argent, avec un risque supplémentaire : outre les piratages, il peut arriver, comme pour Multichain, que l’équipe disparaisse à cause de forces extérieures incontrôlables, entraînant la perte des fonds.
Kevin : Je vais brièvement aborder la question des ponts. Premièrement, sécurité et degré de décentralisation ne sont pas absolument liés. Fireblocks gère d’énormes sommes sans pertes notables, tandis que les ponts décentralisés perdent fréquemment des fonds. Donc, pour l’instant, il n’y a pas de corrélation absolue entre sécurité et décentralisation.
Deuxièmement, il faut rechercher des ponts technologiquement avancés, ce qui implique des innovations de notre part ou de la communauté, pour créer des ponts sans confiance (trustless). Car le caractère trustless renforce la sécurité du pont lui-même, ce que nous devons viser.
Examinons maintenant les modèles de ponts. Traditionnellement, l’utilisateur remet entièrement ses fonds à l’opérateur du pont, perdant tout contrôle. Le flux des fonds est géré par multisignature, POS, preuves de fraude ou vérifications ZK. Tous ces modèles ont un défaut commun : l’utilisateur perd totalement le contrôle de ses actifs. Existe-t-il un moyen de lui conserver une partie de ce contrôle ?
Pendant nos recherches, Bitlayer a découvert que le modèle DLC pourrait apporter des changements. Dans un DLC, l’utilisateur et la plateforme verrouillent conjointement des actifs via une multisignature 2-2 ou des signatures pré-définies, anticipant les résultats futurs. L’utilisateur ne perd pas complètement le contrôle. Dans un pont OP-DLC, même si le pont refuse de coopérer, vos actifs ne seront pas détournés. Fondamentalement, les ponts basés sur DLC ou canaux introduisent de nouvelles dynamiques dans les modèles de confiance et la répartition du pouvoir.
C’est pourquoi notre livre blanc technique et notre second testnet incluront cette approche, offrant ainsi une nouvelle option au marché et à la communauté.
Concernant les fuites de clés, les principales pertes passées étaient causées par des fuites, dues à du social engineering ou autres raisons. Comment mieux gérer les clés ? La solution MPC en résout une partie. D’autres principes comme la séparation froide/chaude ou la séparation des rôles multisignatures sont des standards du secteur. Nous les formaliserons dans un Security Codebook destiné à notre communauté de développeurs.
3. Jomosis : Passons maintenant à Lightning Network et au protocole RGB. Ces deux projets ont suscité de grands espoirs, mais leurs écosystèmes restent décevants. Quelle est votre analyse ?
Baiyu : Notre parcours favori dans l’écosystème Bitcoin inclut Lightning Network. Comme disent Cipher et Jan, Lightning Network est le phare du monde Bitcoin. Nous souhaitons ardemment en promouvoir le développement. Mais après cinq ou six ans d’efforts, dont ceux de grandes entreprises comme Lightning Labs, les progrès restent lents. Cela reflète un problème au sein de la communauté Bitcoin, d’où la nécessité d’équipes stimulantes comme CKB.
Quand CKB a annoncé vouloir développer son propre Lightning Network et que RGB++ pourrait y être intégré, Lightning Labs a accéléré ses développements. Nous pensons que Lightning Network devrait devenir une norme ouverte, plutôt que de rester sous le contrôle exclusif de quelques entreprises centralisées. Elle devrait être compatible avec tout actif UTXO standard sur la couche 1 Bitcoin. Or, Lightning Labs concentre ses efforts sur Taproot Assets, et son infrastructure priorise ces actifs, sans devenir pleinement ouverte.
Nous espérons que l’écosystème Bitcoin continuera à promouvoir l’ouverture de standards comme Lightning Network. Actuellement, il cible davantage les entreprises (ToB) que les consommateurs (ToC). La majorité des utilisateurs trouvent l’expérience utilisateur de Lightning Network difficile. Pour assurer la sécurité, elle sacrifie la commodité. Pour être pratique, il faut céder un peu de sécurité. Des services proches des institutions financières survivent ainsi dans cet écosystème, faisant des compromis sur la sécurité mais offrant une grande facilité d’usage — comme LSD, dont la conception intègre aussi la conformité réglementaire. Voilà l’état actuel de Lightning Network.
Notre propre Lightning Network sera lancé sur testnet vers mi-juin, avec des tests ouverts à tous. Nous espérons que, combiné à RGB++ et à des portefeuilles PassKey comme Joyid, il puisse être utilisé à grande échelle.
Concernant RGB, au lieu d’en parler directement, examinons plutôt ses deux composantes clés : d’abord, la vérification côté client (CSV), une piste cruciale de scalabilité pour Bitcoin. Malheureusement, CSV est négligé. Beaucoup préfèrent appliquer la logique d’Ethereum à Bitcoin, alors que l’extension Bitcoin ne passe pas par une autre blockchain, mais par un réseau pair-à-pair hors chaîne.
Ce qui caractérise le mieux la communauté Bitcoin, selon moi, c’est le P2P, la connexion directe entre pairs permettant une validation mutuelle. CSV suit exactement cette logique : construire un réseau P2P hors chaîne où deux utilisateurs peuvent valider eux-mêmes la validité d’un transfert. Pour cela, un concept clé est le sceau à usage unique (Single-Use Seal), réalisé via les UTXO de la blockchain Bitcoin.
Ces deux éléments sont au cœur de RGB, et permettent de nombreuses innovations. Vous pouvez voir CSV comme un service, et créer une plateforme DAPP basée sur CSV. Chez CKB, notre contribution majeure à partir de RGB est RGB++. Nous utilisons CKB comme client hors chaîne de RGB, assurant la sécurité par liaison isomorphe.
Nous envisageons même une idée audacieuse : faire du CSV sur Bitcoin n’est peut-être pas optimal, car les capacités de vérification de Bitcoin sont limitées. On pourrait faire du CSV sur CKB, notamment en combinaison avec Nostra. Nous allons probablement publier prochainement un schéma technique sur l’intégration de Nostra à CKB, pour encourager les projets à développer des applications sociales.
En résumé, la communauté Bitcoin dispose de concepts puissants comme RGB et Lightning Network, des protocoles excellents qui méritent d’être valorisés. En les combinant, on peut créer ce qu’Ethereum ne peut pas faire. Ethereum avait tenté de développer Lightning Network — ceux qui sont arrivés tôt connaissent le réseau Raiden — mais a finalement abandonné. C’est une opportunité pour Bitcoin. Alors pourquoi ne pas poursuivre dans cette direction ?
D’ailleurs, j’apprends qu’Ethereum abrite aussi des projets explorant la vérification côté client (CSV), mais ces idées viennent toutes de la communauté Bitcoin. Nous pouvons donc les amplifier.
Kevin : Concernant Lightning Network, si je me souviens bien, son objectif initial était les petits paiements. Mais il y a un problème fondamental : payer en petits montants avec Bitcoin est moins efficace qu’avec une stablecoin. La pauvreté des actifs supportés par Lightning Network est un vrai problème. Avec la reconnaissance d’Ordinals, BRC-20 ou Runes, peut-on imaginer émettre des stablecoins via ces nouveaux protocoles et les utiliser pour payer ou échanger sur Lightning Network ? Cela pourrait ouvrir de nouvelles perspectives. J’attends cela avec impatience.
Avant de lancer Bitlayer, nous avons étudié RGB, mais nous n’avons pas retenu cette voie technique, estimant que ce protocole de niche nécessite encore une éducation du marché. Pour nous, la priorité va à l’adoption large et à l’acceptation généralisée. C’est pourquoi nous avons choisi de travailler sur BitVM dans l’écosystème Bitcoin. Étant donné la taille actuelle de la communauté BitVM, de véritables percées technologiques sont possibles, même sans fork majeur de la chaîne BTC. D’ailleurs, notre preuve de concept (POC) de BitVM fonctionne déjà.
Globalement, notre vision est celle d’un écosystème Bitcoin florissant, où diverses idées peuvent s’imposer. Bitlayer peut supporter plusieurs machines virtuelles (VM) et plusieurs modèles de sécurité. Une fois la capacité de vérification améliorée, nous pourrons également prendre en charge différents modèles de programmation.
Kai : Lightning Network reste limité par son absence de complétude Turing et l’absence de contrats intelligents, ce qui freine son expansion applicative. Initialement pensé pour les petits paiements rapides, CKB représente une avancée majeure en offrant une complétude Turing.
Baiyu : Kevin et Kai ont bien souligné deux points essentiels. Aujourd’hui, Lightning Network n’est plus uniquement dédié aux petits paiements. Personne n’utilise vraiment Bitcoin pour payer ; on le considère surtout comme réserve de valeur. Les petits détenteurs n’ayant pas beaucoup de BTC, le scénario réaliste est que Lightning Network devienne une infrastructure capable d’accueillir divers protocoles d’actifs émis sur Bitcoin.
Par exemple, si vous émettez un USDT via RGB++, ce USDT peut entrer dans Lightning Network. Ainsi, Lightning devient une autoroute où d’autres véhicules peuvent circuler, au-delà du seul Bitcoin. C’est là sa transformation majeure.
Un autre point important, mentionné par Kai, est que le Lightning Network Bitcoin reste non Turing-complet, mais sur CKB, on peut ajouter des conditions, permettant au moins de compatibiliser plusieurs protocoles d’actifs. On peut alors réaliser des swaps, voire du DeFi dans Lightning Network — les possibilités sont immenses.
4. Jomosis : Pour que les couches 2 Bitcoin atteignent la taille de celles d’Ethereum, combien de problèmes restent-ils à résoudre ?
Kevin : Premièrement, un problème de perception. Il faut que les gens reconnaissent que Bitcoin a d’autres qualités que le stockage de valeur. Deuxièmement, un problème technique : il faut résoudre la vérification sur chaîne et faire accepter largement l’idée de vérification côté client.
Baiyu : Je pense que les attentes envers l’écosystème Bitcoin sont trop basses. L’écosystème Ethereum a mis des années à découvrir les applications adaptées à son architecture. L’écosystème Bitcoin aura besoin de plus de temps pour bâtir un écosystème prospère. Il s’appuiera sur les réussites d’Ethereum, dont il s’inspirera — ce qui est important.
Bien sûr, nous devons aussi explorer les spécificités de Bitcoin, comme les possibilités du modèle UTXO. Par exemple, nous étudions si UTXO est mieux adapté aux NFT, car il est par nature parallèle et appartient directement à l’utilisateur, contrairement aux actifs détenus par des contrats intelligents.
Dans le domaine du DeFi, le modèle UTXO calcule hors chaîne, puis valide les résultats sur chaîne. Cette architecture « calcul hors chaîne – validation sur chaîne » convient mieux aux systèmes intent et order book. L’idée d’un order book vient d’Ethereum, mais leurs réalisations sont médiocres, aboutissant surtout à des AMM (market makers automatisés). Dans l’écosystème Bitcoin, ce ne sera peut-être pas le cas. Tout cela demande du temps, de l’expérimentation et une mise sur le marché.
Kai : Les couches 2 Bitcoin doivent garantir leur caractère sans confiance et leur sécurité, en proposant une solution standardisée. En outre, l’expérience utilisateur doit être bonne. Beaucoup de couches 2 utilisent encore le modèle de comptes d’Ethereum, mais on pourrait aussi directement réutiliser le modèle de comptes Bitcoin pour créer des scénarios sur couche 2. Bien sûr, ce ne sont que des hypothèses. Je pense qu’à terme, de meilleures solutions émergeront pour résoudre les problèmes actuels.
5. Jomosis : Dans l’écosystème actuel des couches 2 Bitcoin, quels projets admirez-vous particulièrement, tant sur le plan technique que narratif ?
Kevin : Là, je dois bien sûr parler de Bitlayer, haha. Je pense que Bitlayer a une architecture claire et une démarche logique pour résoudre les problèmes.
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
@godrealmx
