Décryptage de l'écosystème d'abstraction des comptes CKB : la pierre angulaire de l'adoption massive de BTC
TechFlow SélectionTechFlow Sélection
Décryptage de l'écosystème d'abstraction des comptes CKB : la pierre angulaire de l'adoption massive de BTC
Découvrez en un article la solution native d'authentification déléguée (AA) de Nervos (CKB) ainsi que le développement de son écosystème.
Dédié à des analyses Web3 approfondiesRédaction : Wu Yue, Geek web3
Édition : Faust
Depuis que la narration AA a gagné en popularité au sein de la communauté Ethereum en 2022, le concept d'abstraction des comptes s'est répandu dans l'écosystème Web3. Il s'agit fondamentalement d'une philosophie de conception du système de comptes visant à établir des normes plus élevées et à renforcer les fonctionnalités des comptes. Toutefois, sur Ethereum et d'autres blockchains principales, la flexibilité et l'universalité du système de comptes sont très limitées en raison de règles fixes, par exemple :
-
votre compte doit disposer au préalable d’ETH ou d’un autre jeton servant de gaz, sinon vous ne pouvez pas initier de transaction, ce qui est clairement peu convivial pour les nouveaux utilisateurs ;
-
les blockchains basées sur EVM ne prennent en charge qu'un seul système de comptes, obligeant les utilisateurs d'autres blockchains ou de plateformes Web2 à adopter de nouveaux outils et interfaces.
La proposition EIP-4337, populaire un temps dans la communauté Ethereum, était censée résoudre ces problèmes. Cependant, en raison de son modèle technique, de ses contraintes historiques, de l’évolution de l’écosystème et de la perception des développeurs, la solution proposée par EIP-4337 ressemble davantage à un correctif qu’à une résolution fondamentale ; EIP-3074, qui tente d'ajouter de nouvelles opcodes à l'EVM, soulève quant à lui des préoccupations en matière de sécurité, créant ainsi de nouveaux problèmes tout en cherchant à en résoudre d'anciens, ce qui fait débattre sur sa faisabilité.
En raison de divers facteurs, l’équipe fondatrice d’Ethereum n’a pas pleinement anticipé la conception du système de comptes au lancement du réseau principal, laissant derrière elle de nombreux héritages technologiques, tels que la distinction entre comptes EOA et comptes contractuels, l’absence de prise en charge des transactions sans frais de gaz, ou encore l’impossibilité d’utiliser plusieurs primitives cryptographiques. Ces héritages entravent sérieusement la mise en œuvre de la feuille de route AA d’Ethereum. On peut même dire que la solution AA d’Ethereum ne permet pas à son système de comptes de surpasser celui des nouvelles blockchains apparues depuis, mais simplement de combler l’écart avec elles. Si une blockchain avait intégré dès le départ une conception réfléchie du système de comptes, elle n’aurait pas eu besoin de suivre le chemin tortueux d’Ethereum.
Contrairement aux blockchains EVM, Nervos a pris en compte dès sa conception les enjeux liés au système de comptes. Après enquête, nous estimons que le système de comptes de Nervos s’aligne davantage sur les bases fondamentales et l’essence de l’AA. Son modèle de compte UTXO et OmniLock, qui prend en charge plusieurs méthodes de vérification, correspondent profondément aux objectifs de l’AA depuis le début, sans bagage historique, et supporte naturellement les systèmes de comptes de BTC, ETH, voire Solana et d'autres blockchains.
De plus, concernant le BTCFi, actuellement très populaire, il s’agit précisément d’introduire des scénarios DeFi autour des actifs Bitcoin natifs. Pour offrir une expérience utilisateur fluide aux détenteurs de Bitcoin, il est essentiel de rester compatible avec les principaux portefeuilles Bitcoin et autres outils connexes. Or, la solution native AA de CKB remplit naturellement cette condition, créant ainsi les prérequis nécessaires à une adoption massive du BTCFi.
Nous allons maintenant analyser le système d’abstraction des comptes de Nervos sous différents angles : philosophie de conception, architecture système, applications et écosystème.
UTXO de Bitcoin et modèle Cell de Nervos
La plupart des gens savent que les blockchains basées sur le modèle UTXO n'utilisent pas une structure de stockage fondée sur « compte - solde », mais adoptent une forme particulière. En effet, les UTXO peuvent être fondus ou frappés comme de l'or, chaque transaction détruisant les anciens UTXO et en créant de nouveaux. De plus, les données UTXO ne sont pas stockées dans une adresse centralisée, mais dispersées dans la transaction ayant généré cet UTXO, nécessitant de consulter les blocs antérieurs pour y accéder.
Sans exagérer, Bitcoin a inauguré un paradigme de stockage différent du modèle traditionnel « compte - information » du Web2, capable de résoudre les problèmes d’explosion d’état, d’inefficacité en lecture/écriture des données et de propriété floue. Dans le modèle UTXO, la localisation des données d’actifs et la répartition de la propriété sont très claires, favorisant le parallélisme/concurrence, facilitant notamment la location de stockage, et évitant ainsi de nombreux pièges du système de comptes classique.
Lors de la conception du système de comptes de la blockchain Nervos, on a pleinement tiré parti des avantages du modèle UTXO de Bitcoin. Le modèle Cell constitue en réalité une version améliorée de l’UTXO Bitcoin, offrant une programmabilité Turing-complète. En outre, que ce soit CKB ou d'autres actifs, tous sont traités comme des actifs de premier ordre, contrairement aux blockchains EVM qui font une distinction entre actif natif et jetons ERC-20.
Le fonctionnement des Cells de CKB est globalement similaire à celui des UTXO Bitcoin : tous deux sont pilotés par un « script de verrouillage » et un « script de déverrouillage ». Chaque UTXO/Cell créé est associé à un « script de verrouillage », agissant comme un cadenas numérique ; tandis que le « script de déverrouillage » représente la clé correspondante, capable de débloquer ce cadenas. Dès lors que vous fournissez la bonne « clé » pour le « cadenas », l’UTXO associé devient entièrement contrôlable par vous.
Toutefois, contrairement à l’UTXO Bitcoin, le Cell ajoute un champ « TypeScript » au-dessus du script de verrouillage. Si le LockScript agit comme un vérificateur d’identité, déterminant qui peut modifier ce Cell, alors le TypeScript est un contrat intelligent attaché au Cell, où l’on peut déployer le code d’une DEX ou d’un protocole de prêt.
Si un développeur souhaite implémenter un pool de liquidité AMM sur CKB, il suffit d’écrire le code du contrat dans le champ TypeScript d’un Cell dédié, puis de stocker les informations d’état du pool (par exemple les soldes des différents actifs) dans le champ Data de ce Cell. Les utilisateurs interagissent ensuite directement avec le code contenu dans le TypeScript.
Cette conception de CKB étend considérablement les cas d’usage possibles du modèle UTXO de Bitcoin, offrant une forte programmabilité. De plus, CKB utilisant une machine virtuelle RISC-V, supportant des programmes écrits dans plusieurs langages, permet bien plus de logiques complexes que Bitcoin.
Quant au script de verrouillage LockScript du Cell, il est directement lié au sujet central de cet article : l’AA. En effet, l’une des caractéristiques majeures prônées par l’AA est la possibilité pour les comptes blockchain de supporter de multiples méthodes d’authentification. Pour l’UTXO, atteindre cet objectif passe par des ajustements sur le LockScript, qui sert de vérificateur d’identité. C’est pourquoi CKB a introduit le script OmniLock, spécialement conçu pour prendre en charge diverses méthodes d’authentification.
Examinons maintenant la conception concrète d’OmniLock.
OmniLock et abstraction des comptes
Comme mentionné précédemment, les permissions d'utilisation des Cells de CKB et des UTXO Bitcoin sont définies par leurs scripts de verrouillage. Le LockScript détermine qui peut modifier ce Cell, remplissant ainsi une fonction d’authentification. Pour soutenir diverses méthodes d’authentification, CKB propose un script de verrouillage universel appelé OmniLock, capable de compatibiliser plusieurs algorithmes de signature et mécanismes de vérification.
OmniLock modularise différentes logiques de vérification : en configurant simplement des paramètres, on peut adapter facilement différents algorithmes. Les utilisateurs peuvent ainsi utiliser directement leurs comptes, portefeuilles ou méthodes d’authentification BTC, ETH, voire WebAuthn, pour manipuler les actifs sur la chaîne CKB.
Mais comment OmniLock fonctionne-t-il concrètement ? En termes simples, OmniLock est un morceau de code déployé directement par l’équipe officielle de Nervos sur la chaîne CKB. Ce code est inscrit dans un Cell spécifique et peut être utilisé par d’autres Cells, un peu comme un « contrat système » sur les blockchains EVM. Lorsqu’un Cell souhaite utiliser OmniLock, il déclare simplement dans son propre script de verrouillage une référence à OmniLock.
Pour mieux comprendre le principe de fonctionnement des scripts de verrouillage et d’OmniLock, examinons un exemple de pseudo-code.
Le script de verrouillage de CKB comporte trois champs : Code hash, hash type et Args. Les deux premiers étant peu pertinents ici, concentrons-nous sur le champ Args. En configurant habilement ce champ, on peut activer différents algorithmes de vérification préprogrammés dans OmniLock.
Le contenu du champ Args se divise en deux parties. La première est « auth », dédiée à l’authentification, longue de 21 octets, composée d’un identifiant flag (1 octet) et de données d’authentification (20 octets). Les données d’authentification contiennent un haché de clé publique prédéfini : seul le propriétaire de la clé publique correspondante peut passer l’authentification et donc modifier les données du Cell.
Le flag dans auth sert d’indicateur pour choisir différentes méthodes d’authentification. Ces méthodes incluent non seulement la vérification cryptographique, mais aussi des processus combinés de traitement d’information. Par exemple, si le flag vaut 0x01, cela indique une méthode d’authentification via un message externe Ethereum. Outre Ethereum, OmniLock prend également en charge Bitcoin, Dogecoin, Tron, signatures multiples, et bien d'autres formats de vérification.
L’autre partie du champ Args s’appelle Omnilock args. Elle agit comme un bouton permettant de sélectionner parmi les modes fonctionnels prédéfinis dans OmniLock, tels que le mode administrateur (comme la fonction de gel USDT), le mode anyone-can-pay pour petits paiements (dons), ou encore le verrou temporel. Bref, en ajustant Omnilock args, on peut activer différentes fonctions préprogrammées dans OmniLock.
En résumé, en modifiant les paramètres des champs Auth et Omnilock args du script de verrouillage d’un Cell, on peut sélectionner différentes méthodes d’authentification provenant de diverses blockchains ou plateformes, introduisant ainsi une grande variété de schémas d’authentification sur CKB. Bien sûr, outre les méthodes prédéfinies dans OmniLock, les développeurs peuvent aussi concevoir leurs propres schémas personnalisés.
Écosystème d’abstraction des comptes de Nervos : CCC, Mobit et JoyID
Nous avons vu que OmniLock est la base de l’abstraction des comptes sur Nervos. Des portefeuilles basés sur OmniLock, tels que Mobit, .bit, Omiga, ainsi que l’intergiciel CCC (Common Chains Connector), forment un riche écosystème d’abstraction des comptes BTCFi sur Nervos. On y trouve également la plateforme DID Did.id, spécialisée dans la protection de la vie privée et la gestion d’identité, et Dobby, une plateforme décentralisée d’échange d’actifs DOBs.
Les bonnes propriétés de l’AA apportent une grande commodité aux applications de l’écosystème BTCFi, permettant aux projets de CKB d’interagir directement avec les portefeuilles BTC, réduisant ainsi les barrières d’entrée. Dans ce qui suit, examinons des cas concrets pour explorer l’écosystème AA de CKB.
Common Chains Connector (CCC)
Prenons d’abord l’exemple de CCC, un intergiciel de connexion de portefeuille, conçu spécifiquement pour permettre aux portefeuilles et aux dApps d’opérer sur CKB depuis diverses blockchains.
L’image ci-dessous montre l’interface de connexion de CCC. Prenons MetaMask comme exemple : si vous avez un compte Ethereum, comment interagir avec votre compte correspondant sur la chaîne CKB ?
Lorsqu’une transaction CKB est effectuée via CCC, la démo invoque la méthode personal_sign de MetaMask pour signer, méthode destinée à signer un message texte hors chaîne.
On constate que ce message contient une série de codes hexadécimaux représentant la transaction CKB. Une fois signé par MetaMask, ce message est envoyé à la chaîne Nervos CKB, puis validé via des mécanismes comme OmniLock.
Comme mentionné précédemment, Nervos prend nativement en charge la vérification des formats de messages Ethereum, ce qui montre que CKB a pensé dès le départ à l’interopérabilité avec d’autres écosystèmes blockchain. Pour les utilisateurs, cela signifie qu’ils peuvent accéder à l’écosystème CKB via leurs outils et interfaces habituels ;
pour les développeurs, Nervos définit au niveau fondamental la norme OmniLock, et CCC abstrait les détails d’implémentation des portefeuilles multi-chaînes, réduisant considérablement la complexité du développement, leur permettant de se concentrer sur la logique métier plutôt que sur les détails techniques inférieurs.
Mobit
Mobit est une plateforme d’identité décentralisée (DID) et de gestion d’actifs basée sur Nervos. Par analogie, Mobit est comme une porte d’entrée vers l’écosystème Nervos, avec un seuil d’accès très bas. Grâce à Mobit, les utilisateurs n’ont presque aucun prérequis technique à connaître : quelques manipulations simples suffisent pour interagir dans l’écosystème Nervos via un compte d’une autre blockchain.
L’image ci-dessous montre l’interface de connexion de Mobit. On voit que Mobit prend déjà en charge plusieurs systèmes de comptes de blockchains principales, et cette liste continue de s’allonger.
Reprenons l’exemple du portefeuille MetaMask. L’interface après connexion affiche à la fois les adresses EVM et CKB de l’utilisateur, ainsi que les jetons et actifs DOBs détenus sur la chaîne CKB.
Parlons maintenant des DOBs. Il s’agit d’actifs spécifiques à l’écosystème Nervos, similaires aux NFT, mais fondamentalement différents. Premièrement, les données des DOBs sont entièrement conservées sur la chaîne, pouvant être considérées comme des « NFT entièrement chainés », contrairement à de nombreux NFT Ethereum dont les données ne sont pas toutes stockées sur la chaîne ;
deuxièmement, chaque DOB peut être doté d’un Chatbot, permettant des interactions conversationnelles avec son détenteur. Avec des parcours d’évolution variés selon les détenteurs, chaque DOB acquiert une individualité bien plus marquée que les NFT traditionnels.
Quant à Omiga, c’est la place de marché des DOBs dans l’écosystème Nervos. Les utilisateurs peuvent y accéder directement depuis l’interface Apps de Mobit d’un simple clic.
Omiga exploite également la fonction d’abstraction des comptes de Nervos.
Facile à utiliser et complet en fonctionnalités, Mobit facilitera les interactions dans le domaine du BTCFi. Le BTCFi vise essentiellement à offrir aux actifs Bitcoin natifs des expériences DeFi variées. La compatibilité avec les principaux portefeuilles Bitcoin sera donc un facteur crucial pour les infrastructures BTCFi, et CKB est déjà prêt à répondre à ce besoin.
Adoption de WebAuthn
WebAuthn est une norme web développée conjointement par le W3C (World Wide Web Consortium) et l’alliance FIDO (Fast IDentity Online), visant à renforcer la sécurité de l’authentification des utilisateurs, simplifier le processus de connexion, et réduire la dépendance aux mots de passe ou clés privées traditionnels.
Des logiciels de gestion de clés intégrés dans des systèmes d’exploitation populaires, comme iOS ou Android, peuvent utiliser des modules de sécurité locaux ou le stockage cloud pour conserver les clés et effectuer des signatures. Actuellement, les implémentations courantes de WebAuthn prennent généralement en charge P-256, P-384, P-521, etc. Étant donné qu’OmniLock de Nervos supporte des primitives cryptographiques personnalisables, il couvre également ces standards.
Voici quelques clients pris en charge par WebAuthn :
-
Apple KeyChain :
-
Security Enclave : les appareils Apple utilisent Secure Enclave pour gérer les opérations cryptographiques sensibles, notamment le stockage des clés privées et la signature.
-
iOS et macOS : les systèmes Apple peuvent utiliser l’API Keychain pour l’authentification et la signature, ou encore s’appuyer sur Face ID ou Touch ID pour authentifier l’utilisateur.
-
Windows Hello :
-
TPM (Trusted Platform Module) : les appareils Windows peuvent utiliser TPM via Windows Hello pour générer des clés privées et signer.
-
Authentification biométrique : Windows Hello prend en charge la reconnaissance d’empreintes digitales et faciale.
-
Android Keystore : les appareils Android peuvent utiliser des modules matériels sécurisés pour stocker les clés et signer, en s’appuyant sur des caractéristiques biométriques (empreinte ou reconnaissance faciale).
-
Ubisoft Security Keys : dispositifs matériels de sécurité comme YubiKey, supportant l’authentification sécurisée et la signature via USB ou NFC.
JoyID, un portefeuille de l’écosystème CKB, est une application concrète mettant en œuvre la technologie WebAuthn. Grâce à JoyID, les utilisateurs peuvent s’authentifier directement via des méthodes biométriques (empreinte ou reconnaissance faciale), offrant une connexion fluide et hautement sécurisée, ainsi qu’une gestion d’identité simplifiée.
Dans l’écosystème Nervos, .bit utilise également l’implémentation WebAuthn d’Apple pour se connecter et utiliser la blockchain.
À partir de ces exemples, on constate que la solution AA de CKB supporte naturellement les utilisateurs d’autres blockchains et du Web2. Pour la majorité des utilisateurs Web2, la prise en charge de WebAuthn est cruciale : elle supprime la gestion des clés privées et des phrases de récupération, abaissant considérablement la barrière d’entrée. Les écosystèmes blockchain qui investissent tôt dans cette direction auront un avantage significatif à l’avenir.
Conclusion
Contraindiction par ses héritages historiques, les solutions AA actuelles d’Ethereum ne font qu’atténuer les symptômes sans guérir la cause. En revanche, Nervos a pleinement pris en compte la conception du système de comptes dès le lancement de son réseau principal, offrant la fonctionnalité OmniLock qui supporte n’importe quelle méthode d’authentification.
Le modèle Cell de Nervos est essentiellement une extension fonctionnelle de l’UTXO Bitcoin. Son script de verrouillage prend en charge plusieurs algorithmes de signature, et OmniLock, semblable à un contrat système, permet à n’importe quel Cell d’y faire appel directement dans son script de verrouillage, offrant ainsi aux développeurs et utilisateurs une expérience proche du Web2 ;
l’écosystème d’abstraction des comptes de Nervos compte désormais des produits comme CCC, Mobit et JoyID, formant un ensemble relativement complet ;
le BTCFi vise essentiellement à offrir aux actifs Bitcoin natifs des expériences DeFi variées. La compatibilité avec les principaux portefeuilles Bitcoin sera donc un facteur critique pour les infrastructures BTCFi. En tant qu’élément clé de l’écosystème BTCFi, CKB adopte une approche inclusive, créant autant que possible, tant côté développeur qu’utilisateur, les conditions nécessaires à une adoption massive du BTCFi.
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
