Entretien avec Cipher, proposant de RGB++ : RGB++, UTXO et BTCFi selon mon point de vue
TechFlow SélectionTechFlow Sélection
Entretien avec Cipher, proposant de RGB++ : RGB++, UTXO et BTCFi selon mon point de vue
Cipher évoque son parcours personnel, la signification unique du modèle RGB++ Layer et UTXO pour BTCFi, ainsi que certaines questions et points de vue concernant CKB et l'écosystème Bitcoin.
Dédié à des analyses Web3 approfondiesInterviewé : Cipher
Interview : Geek Web3
Le 22 juillet 2024, Geek Web3 a eu l'honneur d'inviter Cipher, co-fondateur de CKB et créateur du concept RGB++, à échanger sur sa vision de RGB++ et de l'architecture UTXO, ainsi que sur CKB lui-même et l'écosystème Bitcoin. Au cours de cet entretien, Cipher a partagé son parcours personnel, expliqué l'importance particulière du modèle UTXO et de la couche RGB++ pour BTCFi, et livré ses réflexions sur CKB et l'écosystème Bitcoin. Les sujets abordés incluent :
-
Le parcours personnel de Cipher
-
Le lien entre la pile UTXO (UTXO Stack) et la couche RGB++
-
Son point de vue sur les couches 2 de Bitcoin et sur BTCFi, en particulier celles basées sur EVM
-
Les cas d'usage et la philosophie de développement uniques de RGB++ par rapport aux solutions EVM
-
Son interprétation de la philosophie fondatrice de CKB
-
Comment résoudre certaines limites du modèle UTXO dans la construction d'un écosystème DeFi
-
Pourquoi CKB a choisi RISC-V et les langages de développement associés
-
Sa comparaison des écosystèmes Bitcoin et Ethereum en matière de décentralisation
Voici la transcription intégrale de cet entretien. Bonne lecture à tous.
Faust : Pour commencer, pourriez-vous vous présenter ?
Cipher : J'ai découvert la blockchain en 2013 via le minage de Bitcoin. À l’époque, le secteur était moins saturé, mais j’ai malheureusement acheté mon premier matériel de minage auprès d’un vendeur peu scrupuleux. Entre 2014 et 2015, face à la forte volatilité du prix du Bitcoin, j’ai développé un programme automatisé de trading qui m’a permis de réaliser quelques bénéfices. En fin d’année 2015, avec l’arrivée du marché baissier, j’ai quitté temporairement l’espace crypto. Je n’avais alors aucune conviction profonde, seulement une approche spéculative.
En 2016, je suis entré officiellement dans l’industrie blockchain en rejoignant un institut public de recherche blockchain, où j’ai participé au développement de la monnaie numérique de banque centrale et de blockchains privées, en tant que responsable produit. J’ai également rédigé plusieurs white papers, des documents pionniers sur la protection de la vie privée, ainsi que des brevets liés à la propriété numérique.
En 2018, j’ai compris que les blockchains privées étaient une mauvaise direction : toute alliance comporte un leader, et s’il y a un leader, inutile d’utiliser la blockchain. Dans le cas des consortiums pilotés par des entités étatiques, c’est encore plus absurde : cela revient à donner la parole à un seul acteur. J’ai donc recentré mes efforts sur les blockchains publiques sans permission. Par hasard, j’ai rejoint un groupe de travailleurs indépendants impliqués dans la construction précoce de CKB, où j’ai pris en charge la gestion produit et une partie de la recherche.
Vers 2021, je me suis progressivement détaché de la fondation CKB pour créer ma propre entreprise, axée sur des projets complémentaires au sein de l’écosystème CKB, comme JoyID. Aujourd’hui, JoyID compte plus de 500 000 utilisateurs et est considéré comme le portefeuille Passkey le plus abouti du secteur. Bien que Passkey présente certaines limitations en termes de compatibilité matérielle, notre portefeuille reste très pratique : il ne nécessite ni numéro de téléphone, ni adresse e-mail, ni phrase de récupération. D’un point de vue sécurité, c’est un portefeuille non-custodial.
Pendant l’été des inscriptions (« Ordinals Summer ») de 2023, tout l’écosystème Bitcoin a connu un renouveau, presque une renaissance. Fin février de cette année, j’ai proposé un nouveau concept, RGB++, dont la vision est de créer un environnement de contrats intelligents natifs pour BTCFi, sans compromettre la sécurité de Bitcoin. Nous avons rapidement formé une équipe dédiée et lancé le protocole RGB++ juste avant la halving de Bitcoin en avril. Le résultat est encourageant. Par ailleurs, plusieurs projets au sein de l’écosystème CKB, notamment un DEX, une plateforme de lancement (launchpad), et une stablecoin algorithmique, ont également été déployés. Globalement, l’écosystème RGB++ est en pleine croissance.
Après avoir résolu la question de l’extension fonctionnelle de Bitcoin, nous nous sommes tournés vers la scalabilité. En avril, nous avons créé une entreprise spécialisée dans le déploiement rapide de chaînes publiques UTXO ou de couches 2 Bitcoin — ce que nous appelons UTXO Stack. Pourquoi avoir choisi le modèle UTXO ? Tout simplement parce que Bitcoin lui-même repose sur ce modèle, très différent de celui d’Ethereum. Si l’on veut construire une couche 2 sur Bitcoin, comment gérer la preuve de transition d’état, les ponts inter-chaînes, les retraits forcés d’actifs ou encore la disponibilité des données (DA) ? Copier bêtement le modèle de comptes et l’approche Rollup d’Ethereum mène rarement à de bons résultats. C’est d’ailleurs une conviction que je défends depuis longtemps : essayer d’appliquer les idées d’Ethereum à Bitcoin ne peut que mal finir.
UTXO Stack a déjà levé un premier tour de financement, et un second est en cours. Même si l’engouement récent autour de l’écosystème Bitcoin a un peu diminué, nous restons confiants et déterminés à porter ce projet afin de construire un écosystème presque natif, extensible et programmable pour BTCFi. Nous menons désormais davantage d’activités commerciales et marketing, et de nouveaux événements écosystémiques sont à venir. Restez attentifs.
Nebula : Quel est le lien entre UTXO Stack et RGB++ Layer ? On dirait qu’il existe une relation hiérarchique entre les deux. Pouvez-vous préciser cela ?
Cipher : Cette relation peut être expliquée selon deux angles. D’un point de vue branding, RGB++ Layer est un produit inclus dans la grande marque UTXO Stack. D’un point de vue technique, RGB++ Layer ajoute une couche d’exécution de contrats intelligents à BTCFi grâce à un mécanisme de « binding » homogène. Ce binding homogène s’applique non seulement à Bitcoin et CKB, mais aussi à d’autres blockchains comme Cardano, Fuel ou Sui — en fait, à tout écosystème reposant sur UTXO.
UTXO Stack ressemble un peu à OP Stack : il permet de lancer rapidement une couche 2 Bitcoin, avec une fonctionnalité de binding homogène intégrée, permettant de transférer les actifs BTCFi de la chaîne principale vers une couche 2 via une fonction appelée Leap. Contrairement à OP Stack dont les contrats intelligents s’exécutent sur Ethereum, ceux d’UTXO Stack s’exécutent sur RGB++ Layer.
Concernant la relation hiérarchique finale et les priorités, il faut raisonner logiquement : l’existence d’une couche 2 suppose généralement que la couche 1 soit suffisamment congestionnée ou trop limitée pour répondre aux besoins des utilisateurs.
À l’heure actuelle, la couche de contrats intelligents constituée par Bitcoin + RGB++ Layer n’a pas encore vu émerger suffisamment d’actifs et d’applications. Nous souhaitons donc d’abord orienter les nouveaux développeurs et utilisateurs vers RGB++ Layer pour développer des applications DeFi, des plateformes d’échange et émettre des actifs, afin de faire grandir l’écosystème BTCFi avant de pousser davantage sur les couches 2. Ce n’est que lorsque BTCFi aura acquis une popularité suffisante que la scalabilité deviendra une demande réelle, et là, le déploiement d’UTXO Stack sera naturel.
Faust : Vous mentionnez ici les couches 2 Bitcoin. Récemment, selon plusieurs sources, le domaine des couches 2 Bitcoin traverserait un creux. Beaucoup d’acteurs se concentrent désormais sur BTCFi. Pourtant, beaucoup de ces initiatives BTCFi reposent sur le modèle WBTC, consistant à transférer du Bitcoin vers d'autres blockchains ou sidechains, ce qui n'est pas vraiment natif à Bitcoin. Selon vous, quelle est la vraie différence entre BTCFi et ce genre de solutions comme WBTC ?
Cipher : Mon opinion est claire : le plafond des couches 2 Bitcoin basées sur EVM est très bas. La raison est simple : utiliser EVM, ce n’est pas développer l’écosystème de Bitcoin, c’est exporter du BTC vers d’autres écosystèmes. Nous savons que les contrats intelligents sont difficiles à implémenter sur la chaîne Bitcoin, et que le TPS est faible. Une solution simple consiste à transférer le Bitcoin ailleurs. Cela semble résoudre le problème, mais en réalité, on contourne l’essentiel :
Avec cette approche, l’écosystème Bitcoin lui-même ne progresse pas. Les mineurs ne voient pas leurs revenus augmenter, les données sur chaîne ne changent pas. Vous faites juste un pont d’actifs. Et après avoir transféré vos actifs, avez-vous vraiment accès à de nouveaux scénarios ? Évidemment non. Tout ce que vous faites, Ethereum et son écosystème le faisaient déjà. Il n’y a aucune innovation, juste un nouvel actif BTC bridgé. Alors, quel est votre intérêt réel ?
Même en utilisant EVM, pensez-vous pouvoir surpasser l’écosystème DeFi existant sur Ethereum ? À court terme, les couches 2 Bitcoin basées sur EVM peuvent connaître une fausse prospérité grâce aux anticipations d’airdrop, mais leur potentiel de croissance à long terme est limité. Ce qui pourra durablement impacter et renforcer l’écosystème Bitcoin, ce seront des couches 2 plus natives, basées sur UTXO.
L’intérêt d’une couche 2 véritablement native à Bitcoin ne réside pas dans une quelconque orthodoxie, mais dans les nouveaux scénarios qu’elle permet. Par exemple, RGB++ propose une technologie appelée Leap, un pont sans pont (bridgeless cross-chain), qui permet aux actifs BTCFi de sauter d’une couche L1 à une couche L2, ou entre deux couches L2, sans recourir au paradigme classique Lock-Mint des ponts traditionnels. Cela évite bon nombre de risques associés aux ponts classiques, tout en offrant de grands avantages en termes de rapidité de réponse et d’agrégation de liquidités, facilitant ainsi l’écosystème DeFi. La fonction Leap est opérationnelle depuis avril, et de nombreux utilisateurs profitent déjà de cette commodité. C’est une des innovations rendues possibles par une solution native à Bitcoin.
Un autre point important concerne l’impact sur les utilisateurs. Par exemple, de nombreux détenteurs de BTC n’aiment même pas utiliser Metamask, et préfèrent les portefeuilles populaires de l’écosystème Bitcoin. Certains proposent des solutions d’abstraction de compte (AA) permettant aux portefeuilles Bitcoin d’interagir avec des applications EVM, mais ces solutions posent de nombreux problèmes et freinent l’adoption. Avec notre solution basée sur UTXO, il est possible d’utiliser directement un portefeuille Bitcoin, avec une implémentation AA plus proche de la couche basse, si transparente que l’utilisateur ne la perçoit même pas. C’est bien plus simple, plus fluide, plus intuitif.
Par ailleurs, le modèle UTXO suit le principe du « calcul hors chaîne, vérification sur chaîne », parfaitement adapté aux transactions pilotées par les intentions (intent-driven). Une transaction intent signifie que je dis simplement au système ce que je veux donner et ce que je veux recevoir, sans avoir à gérer les appels de contrats ou les paramètres de fonctions. Je soumets simplement mes entrées et sorties attendues à valider sur chaîne. Sur Ethereum, mettre en œuvre ce type de scénario nécessite souvent des composants complexes comme Operator ou Aggregator, ce qui alourdit le système. Mais dans un monde UTXO, c’est extrêmement simple. Voilà une autre spécificité des couches 2 UTXO par rapport aux couches 2 EVM. En résumé, nous pensons que UTXO peut générer de nouveaux scénarios DeFi innovants.
Faust : Quels sont les principaux points de convergence entre RGB++ Layer et Bitcoin ? Quels scénarios sont les plus importants ? Quelles sont les priorités écologiques et la feuille de route à venir pour RGB++ et CKB ?
Cipher : La convergence se situe surtout au niveau des cas d’usage. J’en ai déjà mentionné certains, en voici d’autres. Dans l’écosystème Ethereum, les prêts flash sont très populaires : ils permettent, dans une seule transaction, d’enchaîner plusieurs appels de contrats, puis de prouver que les fonds empruntés et les intérêts sont remboursés instantanément. On peut utiliser cela pour exécuter rapidement diverses opérations financières. Mais dans un monde UTXO, les prêts flash n’existent pas. En revanche, il existe autre chose.
Par exemple, le modèle UTXO permet le « nesting » de scripts contractuels, ce qui autorise la création en cascade de plusieurs transactions, simplifiant ainsi l’expérience utilisateur. La sortie d’une transaction peut servir directement d’entrée à la suivante. Grâce à ce mécanisme, on peut générer automatiquement une série de commandes enchaînées. Prenons un exemple concret : réaliser un DeFi cross-chain. Transférer un actif de la chaîne A à la chaîne B, vendre la moitié sur un DEX, puis combiner la moitié restante avec les jetons obtenus pour créer un pool LP et fournir de la liquidité. Ces quatre étapes peuvent être réalisées d’un seul clic dans le cadre de contrat intelligent de RGB++ Layer, grâce à ce nesting de scripts. Cela signifie que l’utilisateur n’a besoin d’effectuer qu’une seule action, et le reste est automatisé par des contrats intelligents décentralisés.
Un autre point clé est l’IBO — lever des fonds via Bitcoin. Ce n’est pas une nouveauté : Ethereum a commencé ainsi, où un Bitcoin permettait d’obtenir 10 000 ou 20 000 ETH. Mais le problème des IBO passés, c’est que malgré leur rôle de financement similaire aux ICO, les actifs levés n’avaient aucun usage. Par exemple, dans certaines ICO, il existe des courbes de prix définies : les 100 à 200 premiers blocs voient le prix augmenter ou diminuer progressivement. Ou bien, les premiers acheteurs doivent verrouiller leurs tokens pendant un mois, les derniers pendant trois mois. D’autres encore offrent 50 % de jetons supplémentaires pour un verrouillage prolongé d’un mois, ou 100 % pour un an. Il existe de nombreuses variantes.
Jusqu’à présent, ces règles spécifiques ne pouvaient pas être appliquées dans un IBO. C’est là que RGB++ Layer change la donne. Un gros problème du Bitcoin est son absence de programmabilité : il ne permet que d’émettre des memecoins. Mais une fois combiné à des contrats intelligents, il devient possible d’ajouter des fonctionnalités aux actifs. Ce type d’outils incitera les projets à construire sur l’écosystème Bitcoin.
Pour tout écosystème financier (BTCFi ou autre), la condition première est la présence d’actifs variés et de scénarios riches. Si les actifs se limitent uniquement au BTC, on ne peut faire que du staking distant ou des ponts inter-chaînes — des cas d’usage très limités. Pour que l’écosystème prospère, il faut une multitude d’actifs différents. Dans l’univers Ethereum, la capitalisation des actifs ERC-20 est à peu près équivalente, voire supérieure, à celle d’ETH lui-même. En revanche, dans l’écosystème Bitcoin, les actifs non-BTC représentent probablement moins de 1 % de la capitalisation du BTC. Créer de nouveaux actifs sur Bitcoin est donc essentiel.
Je pense donc que le principal point de convergence entre RGB++ Layer et Bitcoin réside dans la capacité de créer, grâce à la programmabilité de RGB++ Layer, de nouvelles catégories d’actifs décentralisés véritablement utiles à Bitcoin. Cela n’a jamais existé auparavant sur Bitcoin — soit c’étaient des memecoins, soit des actifs centralisés. Nous croyons fermement au potentiel des contrats intelligents pour enrichir l’écosystème Bitcoin.
Faust : Entre 2018 et 2019, CKB s’est défini comme une « couche 1 conçue pour les couches 2 », avec de nombreuses fonctionnalités destinées à la validation d’états pour les rollups, comme une couche de vérification décentralisée dédiée. Selon vous, quelle est l’avantage principal de CKB par rapport aux blockchains classiques ?
Cipher : Il est difficile de définir précisément ce qu’est une couche 1 ou 2 dans l’écosystème Bitcoin. Je pense que CKB et RGB++ Layer ne visent pas à être une couche de validation ou de règlement pour une couche 2 spécifique. CKB, en tant que chaîne UTXO, excelle naturellement dans la vérification des calculs hors chaîne, plutôt que dans l’exécution directe des calculs sur chaîne. C’était une conviction fondamentale de Jan, le chef architecte, dès la création de CKB : les ressources de calcul, de stockage et de bande passante de la blockchain sont extrêmement précieuses ; elles ne doivent pas être utilisées pour des tâches complexes, mais pour des opérations simples et essentielles.
En réalité, qu’il s’agisse d’une couche 1 ou 2, il faut parvenir à un consensus sur le changement d’état. Deux méthodes seulement existent : soit on exécute le contrat de modification d’état soi-même, chacun calcule indépendamment et on valide que le résultat est identique — c’est la logique du modèle de comptes ; soit vous effectuez le changement d’état hors chaîne, vous générez une preuve (Proof) que vous envoyez, et je me contente de vérifier cette preuve sans recalculer tout le processus initial — c’est exactement le principe des Rollups.
Quand nous avons proposé cette deuxième méthode en 2018, elle semblait étrange : calculer et vérifier semblaient être la même chose. Mais Jan insistait : ce n’est pas pareil. Par exemple, pour un algorithme de tri, la complexité de vérification est bien inférieure à celle du calcul direct. À l’époque, beaucoup pensaient que pour un simple transfert ERC-20, ce n’était pas nécessaire. Mais aujourd’hui, tout le monde connaît l’histoire : ZK, Rollups, tous reposent sur le paradigme « calcul hors chaîne, vérification sur chaîne ». On comprend alors que cette deuxième méthode est bien plus efficace et pertinente.
Le modèle UTXO présente aussi de grands avantages pour le calcul parallèle. On sait qu’Ethereum travaille sur un EVM parallèle, mais selon certaines sources, le degré réel de parallélisme atteint en production est souvent inférieur à 2. En revanche, UTXO supporte naturellement le parallélisme : autant de threads que de cœurs CPU. Une efficacité que les systèmes basés sur EVM ne peuvent égaler.
Nous suivons cette voie UTXO depuis cinq ans. Dans les scénarios décrits, UTXO présente naturellement plus d’avantages que le modèle de comptes. Et comme nous partageons le modèle UTXO avec Bitcoin, nous pouvons bénéficier d’un binding homogène, simplifiant encore davantage certaines fonctionnalités. Notre avantage principal réside donc dans l’architecture : adopter UTXO pour interfacer avec Bitcoin nous rend incontestablement plus efficaces.
Faust : Certains pensent que UTXO est mal adapté au DeFi, car les différents UTXO ne peuvent pas partager d’états entre eux. Certains craignent que RGB++ et CKB rencontrent des obstacles s’ils développent un écosystème DeFi directement sur la couche 1. Que pensez-vous de ces critiques ? Et quelles solutions avez-vous mises en place ?
Cipher : Ces critiques ont une part de vérité. Le modèle de comptes est plus intuitif, proche des programmes traditionnels : il suffit d’anticiper certains scénarios d’attaque. Avec UTXO, c’est différent : le contrat que vous écrivez sur chaîne est un vérificateur. Vous devez aussi construire un « calculateur » hors chaîne, que nous appelons généralement Aggregator (agrégateur) ou Generator (générateur). Ce dernier calcule l’état hors chaîne, puis le soumet à la chaîne pour vérification. C’est plus complexe.
Sur une plateforme DEX UTXO comme UTXOSwap, il est difficile de connaître immédiatement le résultat d’une transaction, car 100 personnes peuvent envoyer des ordres simultanément. Mais la nature particulière d’UTXO impose que, parmi ces 100 personnes, une seule puisse modifier l’état à un instant donné — d’où un problème de contention. Si on ne traite pas correctement ces demandes conflictuelles, 99 des 100 transactions échoueront. C’est un défi majeur pour la conception de produits, et c’est pourquoi on dit souvent que UTXO n’est pas adapté au DeFi.
Mais on observe aussi que, même ces dernières années, de nouvelles blockchains UTXO émergent, comme Fuel. Pourquoi continuer à adopter UTXO malgré ses complexités ? Parce qu’il offre de nombreux avantages, comme je l’ai dit. Alors, comment résoudre ces problèmes ? Après cinq ans de travail, nous disposons désormais de solutions matures pour implémenter des fonctionnalités similaires à Uniswap sur une chaîne UTXO. UTXOSwap, récemment lancé en mainnet, voit déjà de nombreux utilisateurs ajouter des liquidités et créer des paires. Si vous l’essayez, vous constaterez qu’il n’a rien à envier à Uniswap.
La conception d’UTXOSwap est simple : chaque transaction est divisée en deux étapes. D’abord, l’utilisateur soumet son intention sur chaîne. Ensuite, un Aggregator regroupe toutes les intentions, les fusionne, et initie une transaction avec le pool de liquidité. Ce pool peut satisfaire toutes ces intentions en une seule fois, générant un UTXO final.
Il pourrait y avoir un léger délai d’un bloc, car la première étape nécessite que l’utilisateur soumette individuellement son intention, puis que l’aggrégateur la traite. Mais en pratique, l’utilisateur peut envoyer directement son intention hors chaîne à l’Aggregator, qui la traite par lots — éliminant ainsi le délai. C’est comparable à un Rollup. Nous avons des solutions robustes pour ces problèmes liés à UTXO, et CKB travaille aussi à implémenter ce type de flux.
Autre point : UTXO convient particulièrement bien au modèle de carnet d’ordres. Des DEX à carnet d’ordres ont existé sur Ethereum, mais ont disparu. Plusieurs raisons, mais la principale est que ce modèle ne convient pas au modèle de comptes : chaque ordre ou annulation, même infructueuse, coûte des frais de gaz, ce qui est insoutenable pour le PMF. D’où l’émergence du modèle AMM. Mais dans un monde UTXO, c’est différent : on peut placer 100 ordres simultanément, car lier une transaction à 100 UTXO est facile et peu coûteux. On peut même en placer davantage. Ainsi, les DEX à carnet d’ordres retrouvent tout leur intérêt dans un environnement UTXO.
Sans oublier la technologie PSBT (Partially Signed Bitcoin Transaction), qui permet de signer partiellement des ordres sans les soumettre sur chaîne. Un simple message de signature suffit. Le market maker agrège ensuite les signatures multiples et publie la transaction complète. Cela rend le carnet d’ordres encore plus adapté à UTXO. Même pour les AMM, on peut imiter Uniswap V3 avec des prix par paliers, offrant une liquidité virtuelle, en plaçant différentes parts de liquidité à différents niveaux de prix, plutôt qu’une courbe lisse.
Tous ces cas d’usage sont uniques à l’environnement UTXO, représentant des innovations de haut niveau — impossibles à réaliser sur une chaîne EVM. Les chaînes EVM sont dominées par des projets copiés, sans réelle innovation. Nous voulons attirer les développeurs natifs de l’écosystème Bitcoin, ou ceux passionnés par UTXO — souvent des talents très capables et fortement motivés par l’innovation. Nous croyons profondément à l’émergence d’un nouveau paradigme BTCFi grâce à ce modèle.
Faust : CKB utilise l’architecture RISC-V, compatible avec de nombreux langages. Certains pensent que trop de langages nuisent à l’unité de l’écosystème développeur. Quel langage recommandez-vous actuellement pour développer sur CKB ?
Cipher : Actuellement, Rust est le choix principal, suivi de C — les deux étant bien supportés. RISC-V est désormais une architecture CPU majeure, qui devrait dépasser ARM dans les 5 à 10 ans. Elle dispose de nombreux compilateurs. Mais officiellement, CKB soutient surtout Rust et C, ainsi que certains langages script. Nous avons développé des runtimes pour LUA et JavaScript, mais avec une perte de performance notable — jusqu’à 30 % à 300 % de ralentissement. Pour les applications intensives en calcul, Rust ou C restent fortement recommandés. Et contrairement aux craintes, cela ne fragmente pas l’écosystème développeur.
Je voudrais souligner les avantages de RISC-V : dès 2018, nous étions les seuls au monde à choisir RISC-V comme machine virtuelle pour une blockchain publique. Pourquoi ? Car RISC-V est une architecture matérielle, conçue avec deux principes : simplicité et prudence. Conçue pour le matériel, elle est très stable, contrairement à EVM qui modifie ses opcodes chaque année. Cette prudence est exactement ce dont un protocole open source a besoin.
Deuxièmement, nous pensons que pour une plateforme de contrats intelligents ou une blockchain, mieux vaut que les fonctionnalités centrales soient figées, comme sur Bitcoin. Modifier constamment le noyau crée des risques. Notre philosophie diffère radicalement d’Ethereum. EVM itère ses opcodes chaque année, ce qui nuit à la compatibilité et à la stabilité. Nous faisons tout pour l’éviter. Adopter RISC-V s’est révélé très visionnaire.
Aujourd’hui, avec le boom du ZK, de nombreux projets utilisent RISC-V comme machine virtuelle en couche basse. En tant que blockchain RISC-V, nous pouvons intégrer facilement les nouvelles infrastructures ZK, sans traduction d’instructions, bien plus efficacement qu’une solution EVM exécutant RISC-V.
Faust : Du point de vue de CKB, comment voyez-vous l’écosystème Bitcoin ? Existe-t-il, selon vous, une organisation centralisée similaire à la Fondation Ethereum ? Certains accusent Blockstream de monopoliser les décisions. CKB a-t-il un avis sur ce sujet ?
Cipher : L’écosystème Bitcoin est structurellement très différent de celui d’Ethereum. La Fondation Ethereum a une influence énorme. Dans le monde Bitcoin, certes, les développeurs principaux ont un poids, mais l’écosystème Bitcoin repose sur un équilibre clair entre plusieurs forces : pools de minage, développeurs, gros détenteurs. Aucun groupe ne domine totalement. Les mineurs n’acceptent pas aveuglément les propositions des développeurs. S’ils jugent une proposition excessive, ils s’opposent fermement.
C’est très différent d’Ethereum. Des controverses comme la transition PoW vers PoS ou l’EIP-1159 ont existé, mais la Fondation Ethereum, ou Vitalik lui-même, a souvent imposé sa décision — c’est indéniable. D’autre part, l’écosystème Ethereum est si vaste qu’il contient de nombreux actifs centralisés (RWA, stablecoins…). En cas de fork significatif, ce sont ces émetteurs centralisés qui décident réellement de l’avenir.
Subjectivement et objectivement, le pouvoir des entités centralisées, menées par EF, est bien plus fort dans l’écosystème Ethereum que dans celui de Bitcoin. Autre point : il n’existe pas de valeur unique dominante dans l’écosystème Bitcoin. Les développeurs principaux sont souvent maximalistes, hostiles à OP_CAT ou aux inscriptions, souhaitant garder Bitcoin inchangé. D’autres développeurs, plus périphériques, soutiennent OP_CAT. Les équipes comme Lightning Network ou RGB sont encore plus ouvertes aux nouveautés. Puis il y a des groupes comme le nôtre, qui cherchent activement l’innovation. Enfin, certains
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
