Qu'est-ce que Nervos Network : CKB, Cells et couche 1 centrée sur la vérification

2026-08-24

La couche de base de Nervos Network s’appelle CKB, pour Common Knowledge Base. Elle emploie le modèle Cell pour l’état on-chain, exécute des scripts dans la CKB-VM compatible RISC-V et utilise un consensus Proof of Work. Cet article explique des rôles documentés ; il ne constitue pas une incitation à agir au sujet du réseau ou de son actif natif.

Pour comprendre l’écosystème et les cas d’usage de Nervos, Nervos Network lui-même et son fonctionnement, il faut distinguer la couche de base, l’actif natif de capacité et les applications ou protocoles qui peuvent employer cette couche. La documentation Nervos présente CKB comme la base qui préserve l’état et vérifie les règles associées à cet état.

Cette distinction est importante, car un nom de projet, un réseau, un ticker et une application précise ne sont pas interchangeables. CKB est le CKByte natif de la couche de base, une Cell est un conteneur d’état et un Script est le code qui peut restreindre l’usage d’une Cell. L’état actuel d’une application, d’un outil ou d’une intégration distincte demande ses propres sources et son propre examen on-chain.

Qu'est-ce que Nervos Network ?

Nervos Network est le système plus large organisé autour de CKB, la Common Knowledge Base. La documentation officielle décrit CKB comme la couche fondamentale de Nervos Network et comme une blockchain publique et permissionless de couche 1. Son rôle est de fournir aux autres couches et applications un environnement sûr et décentralisé pour l’état et la vérification.

Common Knowledge Base décrit une architecture, et non la véracité de chaque affirmation d’une application. La couche de base enregistre et vérifie des changements d’état définis selon des règles de consensus, mais elle ne décide pas si une description externe est exacte, si une interface est fiable ou si une règle applicative est judicieuse. L’acceptation d’une transaction par le protocole ne répond pas automatiquement à ces questions.

Nervos est aussi présenté comme une conception multicouche. Dans ce cadre, la couche de base privilégie sécurité et décentralisation, tandis que d’autres couches ou protocoles peuvent traiter des besoins différents d’exécution ou d’application. Le découpage en couches répartit les responsabilités, mais ne transmet pas automatiquement les propriétés de la base à chaque produit de couche supérieure.

La première réponse prudente à la question de ce qu’est Nervos Network est donc la suivante : c’est un système autour de la couche de base programmable CKB avec Proof of Work. Il faut ensuite établir quelles Cells sont concernées, quels Scripts les régissent, de quel réseau il est question et quels documents officiels ou enregistrements publics de chaîne soutiennent une affirmation précise.

Quel problème Nervos Network cherche-t-il à résoudre ?

Une chaîne publique doit permettre à des participants indépendants de contrôler les changements d’état. Si une règle détermine qui peut employer un actif ou quelles données un programme reconnaît, les nœuds doivent la valider sans faire confiance à la base d’un opérateur unique. Nervos traite cette tâche de base avec des Cells, des Scripts, des transactions et un consensus Proof of Work plutôt qu’avec un unique modèle de solde partagé pour toute logique applicative.

Le modèle Cell généralise l’idée d’une sortie non dépensée en conteneur d’état. Une Cell peut contenir de la capacité, des données et des Scripts qui définissent des conditions. Une fois ajoutée à la chaîne, une Cell n’est pas modifiée sur place ; une mise à jour valide consomme l’ancienne Cell et crée une ou plusieurs nouvelles Cells, afin que le réseau puisse vérifier une transition visible entre entrées et sorties.

Cette organisation rend la règle de mise à jour explicite. Un programme ne remplace pas un enregistrement discrètement : la transaction fournit entrées et sorties, et les Scripts associés évaluent si le changement est autorisé. Cela peut servir aux actifs, aux données ou à un état d’application, mais n’élimine pas la nécessité de comprendre les règles des Scripts. La validité signifie uniquement que les règles déployées ont accepté la transition.

Proof of Work couvre une autre partie du problème : l’accord de participants distribués sur l’historique valide et l’ordre des transactions. Les documents officiels de Nervos décrivent NC-MAX comme une évolution du consensus de Nakamoto avec un processus de proposition et d’engagement. Ce sont des propriétés de la vérification réseau, pas une raison de présumer l’authenticité de tout site, libellé d’adresse ou message d’application.

Comment fonctionne Nervos Network ?

À haut niveau, Nervos représente l’état on-chain réutilisable sous la forme de Live Cells. Une transaction choisit des Live Cells existantes comme entrées et crée de nouvelles output Cells. Les Cells d’entrée sont consommées et les Cells de sortie deviennent le candidat pour l’état suivant. Ainsi, la question de savoir comment fonctionne Nervos Network est plus précise lorsqu’elle identifie les Cells consommées, créées et les Scripts qui doivent accepter la transition.

Chaque Cell possède une capacité mesurée en CKBytes et peut contenir des données ainsi que des références à des Scripts. La documentation officielle explique qu’un Lock Script associé contrôle propriété et accès à une Cell, tandis qu’un Type Script peut définir comment une Cell peut être utilisée ou modifiée dans une transaction. Le premier porte généralement sur le droit de consommer une Cell ; le second peut ajouter des règles pour un type de Cells ou un état d’application.

Lorsqu’une transaction est soumise, les nœuds exécutent les Scripts pertinents pour ses entrées et ses sorties. La CKB-VM charge et exécute le code référencé par les champs Script de la transaction. Un résultat concluant laisse passer cette partie de la vérification ; l’échec d’un Script empêche l’acceptation de la transaction. Il s’agit de vérification programmable, non d’une attestation générale de sûreté pour tout contrat ou interface.

La CKB-VM utilise l’ensemble d’instructions RISC-V. Les documents Nervos la décrivent comme l’environnement d’exécution des Scripts et mentionnent le comptage des cycles ainsi que des limites au niveau du bloc. Pour le lecteur, l’essentiel est que le protocole vérifie des règles exécutables pour une transition indiquée ; pour le développeur ou l’examinateur, le code hash exact, les arguments, dépendances, données de transaction et version réseau restent déterminants.

Quel rôle CKB joue-t-il dans Nervos Network ?

CKB est le ticker officiel de CKByte, l’actif natif de la couche de base Nervos. La documentation officielle de Nervos indique qu’un CKByte correspond à un octet de capacité de stockage de données on-chain. La capacité occupée par une Cell lie directement CKB au stockage d’état, au lieu de le traiter comme une simple unité de transfert générique.

CKB a aussi un rôle documenté dans les frais liés aux transactions et au calcul. Cela relie l’actif à l’usage de la couche de base, mais un rôle de protocole ne détermine aucun résultat pour un détenteur ou une application. Les règles du réseau, le besoin de capacité, la construction de transaction, les versions logicielles et les conditions d’un déploiement donné comptent dans chaque cas.

Dans le modèle Cell, la capacité a une conséquence pratique : tant que l’état occupe des octets, les CKBytes correspondants restent associés à cet état. Lorsque l’état est retiré par une transition valide, la capacité concernée peut être disponible pour un autre usage. Cela explique la présence de CKB dans le modèle de stockage comme dans celui des frais, sans remplacer l’examen des données Cell et des Scripts d’un enregistrement précis.

CKB est natif de la couche de base Nervos ; cet article n’invente donc pas une adresse unique de token contract. Il faut distinguer l’actif natif d’une représentation séparée qui pourrait exister dans un autre contexte. La première étape fiable consiste à identifier le réseau, puis à vérifier l’adresse, la transaction, la Cell ou le script hash revendiqué dans la documentation officielle et le CKB Explorer.

Écosystème Nervos et cas d’usage

Schéma Nervos CKB : une transaction consomme des Live Cells, crée de nouvelles Cells, exécute des Scripts dans CKB-VM et est vérifiée par la couche de base.

L’écosystème Nervos et les cas d’usage s’expliquent mieux par les composants exposés par la documentation officielle que par une liste changeante de noms. La documentation propose des ressources sur les Cells, les Scripts, les SDK, les actifs et les objets numériques. Un cas d’usage prend un sens concret lorsqu’il indique le réseau, la structure Cell, les Scripts, les données et le chemin de vérification.

Par exemple, un développeur peut modéliser un actif personnalisé ou un état d’application à l’aide de Cells et de Scripts, tandis qu’un utilisateur peut rencontrer une application qui repose sur ces règles. La couche de base vérifie la transaction selon les Scripts associés. Elle n’approuve pas l’objectif d’une application, ne garantit pas la disponibilité de son interface et ne rend pas vraie une affirmation externe parce qu’une adresse apparaît dans la chaîne.

Les documents officiels de Nervos renvoient aussi vers des projets, outils, ressources de développement et un Explorer liés à CKB. Ces entrées sont utiles pour commencer une recherche, mais elles ne mesurent ni l’utilisation, ni la sûreté, ni la décentralisation, ni la continuité de service. Chaque projet peut changer, opérer sur un réseau donné ou employer une autre version et un autre contrat ; une affirmation actuelle sur une intégration exige des éléments actuels propres au projet.

Pour évaluer un cas d’usage revendiqué, quatre questions sont utiles : quelles Cells conservent l’état concerné, quels Lock Scripts et Type Scripts interviennent, quel transaction hash ou script hash précis peut être contrôlé, et quel document officiel relie ces enregistrements à la fonction annoncée ? Cette méthode est plus solide qu’une conclusion tirée du seul nom du réseau.

Comment l’architecture multicouche de Nervos est-elle structurée ?

L’architecture officielle place CKB en couche 1 d’un système multicouche. Il fournit un environnement pour l’état durable, le consensus et la vérification ; d’autres protocoles ou applications peuvent traiter des besoins différents d’exécution, de communication ou d’expérience d’usage. Les couches sont liées, mais une affirmation sur l’une ne doit pas être transférée à une autre sans élément technique.

Dans la couche de base, le modèle Cell, les Scripts, la CKB-VM, les transactions et le consensus ont des fonctions distinctes. Les Cells représentent l’état, les Scripts limitent certaines transitions, la machine virtuelle exécute les Scripts, la transaction propose la transition, et les nœuds ainsi que les mineurs participent à la vérification et à la formation de l’historique selon le protocole de consensus. Séparer les rôles aide à repérer l’endroit où une affirmation peut échouer.

Le dépôt officiel du nœud CKB décrit le logiciel comme une implémentation publique et permissionless de couche 1, et indique la compatibilité RISC-V de la CKB-VM. Un code source accessible est précieux pour l’examen, mais un dépôt visible n’est pas un résultat d’audit. Il faut faire correspondre une release, une configuration réseau, un binaire Script ou un déploiement précis avec l’objet réellement invoqué.

Cette structure signifie aussi qu’il n’existe pas de réponse universelle sur la sûreté ou l’utilité d’une application. La réponse peut dépendre de la qualité du code, de dépendances externes, de la construction d’une transition Cell, de l’actualité du Script et du fait que l’utilisateur regarde le réseau prévu. Le protocole de base fournit des règles de vérification ; une évaluation responsable nécessite des faits précis.

Risques et limites

Le risque principal est de confondre validité du protocole et sûreté d’une application. Une transaction peut satisfaire les Lock Scripts et Type Scripts déployés alors que la conception de l’application, son interface, l’interprétation des données ou un service externe comporte toujours une faiblesse. Les Scripts sont des programmes ; un programme peut contenir des erreurs, dépendre d’hypothèses ou être déployé avec une configuration inattendue.

L’état fondé sur les Cells exige aussi une lecture attentive. Un solde d’adresse visible n’explique pas à lui seul quelles Cells existent, quelles données elles contiennent ou quels Scripts les limitent. Un actif, une application ou un identifiant revendiqué peut avoir un nom connu tout en visant un autre réseau, Script ou format de données. Un enregistrement Explorer n’est un élément utile qu’après vérification du réseau, de l’adresse ou du hash et de son lien avec la documentation officielle.

Les détails du réseau et du protocole peuvent évoluer avec des releases ou des processus de mise à niveau. La documentation porte des dates, et les sources officielles décrivent un hard fork comme un changement qui oblige les nœuds à suivre des règles mises à jour. Le comportement actuel doit donc être contrôlé au regard de la release, du réseau et de la documentation technique datée pertinents, plutôt que déduit d’un ancien tutoriel ou d’une branche de code sans rapport.

Il existe également des risques opérationnels ordinaires : sites trompeurs, adresses copiées, logiciels non pris en charge, services indisponibles et documentation incomplète peuvent mener à de mauvaises conclusions. Cet article ne formule aucune conclusion d’audit. L’absence d’un problème sur une page consultée ne prouve pas qu’un code, un contrat ou une interface précise a été évalué de manière indépendante ou fonctionnera comme prévu.

Un incident de sécurité concret a sa place dans cette section. En juin 2025, le pont inter-chaînes du projet, Force Bridge, a été compromis par une faille de contrôle des droits ; les sociétés de sécurité et les médias qui l'ont couvert ont situé la perte dans une fourchette d'environ 3 à 3,9 millions de dollars plutôt qu'à un chiffre unique, et ont indiqué que les actifs détournés avaient été convertis en ETH puis passés par le mélangeur Tornado Cash. L'exploitation du pont a été suspendue pendant l'enquête. Lorsque des rapports indépendants divergent sur l'ampleur d'une perte, un profil doit conserver la fourchette au lieu de choisir un nombre.

L'incident a aussi eu une conséquence hors du protocole. Le 2 juin 2025, la Digital Asset eXchange Alliance, l'association de plateformes d'échange sud-coréennes agréées connue sous le nom de DAXA, a émis un avis de prudence visant CKB après avoir confirmé que des actifs de l'écosystème Nervos avaient été compromis via un pont. Un tel avis est une mesure de protection des investisseurs et non un constat de faute ; il permet aux plateformes membres d'aller plus loin, par exemple en signalant l'actif comme nécessitant de la prudence ou en mettant fin à sa prise en charge. Vérifiez son statut actuel auprès des plateformes qui l'ont émis plutôt que de le supposer inchangé.

Comment vérifier Nervos Network vous-même ?

Commencez par la documentation officielle de Nervos et confirmez la date, le périmètre de la page et le réseau auxquels se rapporte une affirmation. La documentation fixe le vocabulaire : CKB est le CKByte natif, une Cell porte état et capacité, et les Scripts définissent les règles de vérification concernées. Si une affirmation ne peut être reliée à une page officielle, un dépôt ou un enregistrement de chaîne identifiable, elle doit rester non vérifiée.

Pour les données publiques de chaîne, utilisez l’explorateur de blocs officiel de CKB pour contrôler une adresse CKB, un transaction hash, une hauteur de bloc ou un script hash. Comparez le réseau exact, l’identifiant, les entrées et sorties de la transaction ainsi que les détails Cell ou Script affichés avec la documentation. C’est un chemin de consultation seule, qui ne demande ni signature ni soumission de transaction.

Comme CKB est natif de la couche de base Nervos, il ne faut pas supposer qu’une adresse de contrat figurant sur une page promotionnelle représente le CKB natif. Déterminez d’abord si l’affirmation concerne le réseau CKB ou une représentation séparée dans un autre environnement, puis comparez les identifiants exacts avec l’Explorer officiel et la documentation. L’important est de vérifier toute la chaîne de preuves, pas seulement un nom ressemblant.

Pour les affirmations sur le logiciel ou le protocole, utilisez le dépôt officiel de Nervos Network et rapprochez la branche, la release, la version de la documentation et le réseau. Les changements et avis de sécurité doivent être lus dans leur contexte. Le dépôt officiel est une source fiable pour le code publié, mais il ne prouve pas seul qu’un site tiers exécute ce même code ni qu’un déploiement particulier est exempt de défaut.

Conclusion

Nervos Network se comprend le mieux à travers la couche de base CKB centrée sur la vérification. Elle combine le consensus Proof of Work, un modèle Cell pour l’état, des Scripts qui contrôlent les transitions et une machine virtuelle compatible RISC-V qui exécute ces Scripts. Cette conception explique précisément comment une transition d’état est vérifiée, mais ne transforme pas toute affirmation d’application en fait établi.

CKB est l’actif natif CKByte. Ses rôles documentés comprennent la fourniture de capacité de stockage et la couverture de frais liés aux transactions et au calcul. Ces rôles expliquent le lien entre CKB et le modèle d’état, mais ne répondent pas à la question de la fiabilité d’une application, d’une interface ou d’une représentation séparée. Avant de vous appuyer sur une affirmation, contrôlez le réseau, les Cells, les Scripts, les identifiants, les documents officiels actuels et l’explorateur de blocs officiel.

Pages de marché associées

Pages Bitbase pour les jetons cités dans cet article :

- CKB : Voir le prix · Marché des contrats perpétuels

Articles associés

Autres articles Bitbase sur ce sujet :

- Les métriques on-chain d'offre et de profit

- Sentiment et activité des développeurs

- Qu'est-ce que le minage de cryptomonnaies ?

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il explique ce que fait un projet et quel rôle son jeton joue dans ce système ; il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance, et il ne vaut ni recommandation ni approbation d'un projet ou d'un jeton. Bitbase n'a pas effectué de diligence raisonnable sur le projet décrit ici, et le mentionner ne signifie pas que Bitbase référence ou prend en charge cet actif. Les cryptoactifs comportent un risque important, notamment la volatilité des prix, une liquidité faible, la défaillance des contrats intelligents, l'incertitude réglementaire et la perte possible de toute leur valeur. Rédigé en août 2026 ; le statut d'un projet, sa tokenomics, son équipe et ses contrats peuvent changer à tout moment. Vérifiez tout par vous-même via les canaux officiels, l'adresse du contrat et un explorateur de blocs, et méfiez-vous des sites imitant le projet et des liens d'hameçonnage.