CKB联创Jan: Qu'est-ce que le problème de la faim L1? Comment concevoir L2 et L1?

Compilation: Wuyue & Baiding, Geek Web3

Ce document est un discours prononcé par Jan, co-fondateur de Nervos, lors de la conférence HBS Blockchain+Crypto Club en 2019. Le sujet porte sur la relation entre Layer2 et Layer1, et il est clairement souligné que la blockchain modulaire est la bonne direction à prendre.** Le discours aborde également la question du mécanisme de stockage des données sur la blockchain. En même temps, Jan a également soulevé un sujet intéressant : comment résoudre le problème de la faim de Layer1 causée par l’émergence de Layer2.**

En tant que l’une des premières équipes à soutenir la narration de Layer2 et de la blockchain modulaire, la vision de Nervos était avant-gardiste en 2018 et 2019. À l’époque, la communauté d’ETH avait des illusions irréalistes sur le Sharding, et la narration de la haute performance d’une seule chaîne était encore largement discutée et n’avait pas encore été complètement réfutée.

Cependant, en ce jour de 2024, en regardant les problèmes révélés par Layer2 d’ETH dans la pratique, ainsi que les inconvénients de la « chaîne publique à haute performance » représentée par Solana en matière de Décentralisation et de non-confiance, il faut dire que Jan avait une vision très perspicace il y a 5 ans. Par intérêt pour Layer2 lui-même, le « web3 geek » a organisé la conférence de Jan sous forme de texte et l’a publiée ici. Bienvenue aux amateurs de Layer2 de Nervos, d’ETH et de la communauté BTC pour étudier et discuter ensemble.

Voici le texte original de la conférence de Jan.

Définition de Layer1 et Layer2

Voici ma définition de L1 et L2 (réseau de deuxième niveau), comme indiqué sur le schéma.

La première chose à souligner est que Nerovs n’est qu’un réseau de chaînes de blocs qui s’efforcent de répondre aux besoins de l’économie de décentralisation et n’est pas responsable de la résolution de « tous les problèmes ». Dans notre cognition, la clé de la différence entre la couche 1 et la couche 2 réside dans la force du consensus. Le réseau L1 doit avoir le consensus le plus large, le « consensus mondial ». **Grâce au Consensus Mondial sans permission, n’importe qui dans le monde peut participer au processus de Consensus L1, et éventuellement la couche 1 peut servir de « point d’ancrage » de l’économie de décentralisation. De ce point de vue, nous pouvons appeler L1 la « couche de consensus ».

En revanche, la portée du consensus de **L2 réseau peut être plus restreinte, **ses participants peuvent provenir uniquement d’un pays, d’un secteur d’activité, voire d’une seule entreprise ou institution, ou même d’une communauté très restreinte. Le sacrifice de la portée du consensus de L2 est un coût qui entraîne des progrès dans d’autres domaines, tels qu’un TPS plus élevé, une latence plus faible et une meilleure extensibilité, entre autres. Nous pouvons appeler L2 le “protocol layer”, et la connexion entre L1 et L2 est souvent réalisée via des bridges cross-chain.

Il est important de souligner que notre objectif en construisant un réseau L2 n’est pas seulement de résoudre le problème de la scalabilité de la blockchain, mais aussi parce que l’architecture en couches est la meilleure façon de mettre en œuvre un blockchain modulaire. Le terme blockchain modulaire fait référence à la résolution de différents types de problèmes dans des modules distincts.

Beaucoup de gens discutent depuis longtemps des problèmes de conformité et de réglementation de la blockchain. Comment pouvons-nous intégrer BTC ou ETH dans le cadre réglementaire existant ? L’architecture en couches peut-être une réponse à ce problème. Ajouter directement une logique métier conforme aux exigences réglementaires au niveau de la couche 1 pourrait compromettre la décentralisation et la neutralité. Par conséquent, la logique liée à la conformité peut être mise en œuvre séparément sur la couche 2.

Layer2 peut être personnalisé selon des réglementations ou des normes spécifiques, telles que la création d’une petite blockchain basée sur la permission, ou quelque chose comme le réseau de canaux d’état. Cela permet de garantir la conformité sans affecter la décentralisation et la neutralité de Layer1.

De plus, nous pouvons également résoudre le conflit entre la sécurité et l’expérience utilisateur grâce à une architecture en couches. Par analogie, si vous voulez assurer la sécurité de votre Clé privée, vous devez sacrifier une certaine commodité, tout comme c’est le cas pour la blockchain ; si vous voulez garantir une sécurité absolue de la blockchain, vous devez sacrifier quelque chose, comme les performances de cette chaîne, etc.

Mais si nous utilisons une architecture en couches, nous pouvons viser pleinement la sécurité sur le réseau L1, tout en sacrifiant un peu de sécurité sur le réseau L2 pour une meilleure expérience utilisateur. Par exemple, nous pouvons utiliser des canaux d’état sur L2 pour optimiser les performances du réseau, Gouttelatence. Ainsi, la conception de la couche 2 n’est rien d’autre qu’un compromis entre la sécurité et l’expérience utilisateur.

Ce qui précède soulève naturellement une question : est-ce que n’importe quelle blockchain peut être utilisée en tant que couche 1 ?

La réponse est non, tout d’abord nous devons être clairs que la Décentralisation et la sécurité du réseau Layer1 sont supérieures à tout, car nous devons réaliser une résistance à la censure par la Décentralisation. La poursuite de la sécurité de Layer1 est fondamentalement due au fait que L1 est la racine de l’ensemble du réseau Blockchain, c’est l’ancre de l’ensemble du système économique chiffré.

Selon ces critères, **BTC et Ethereum sont sans aucun doute les réseaux L1 les plus classiques, avec un consensus extrêmement fort. En dehors de ces deux-là, la plupart des blockchains ne répondent pas aux critères L1 et ont un degré de consensus plus faible. Par exemple, le consensus d’EOS ne répond pas aux normes et ne peut servir que de réseau L2, d’autant plus que certaines de ses règles ne s’appliquent qu’à lui-même.

Problèmes actuels du réseau Layer1

Une fois que la définition de Layer1 est claire, nous devons souligner que certains réseaux L1 existants présentent trois problèmes, qui existent également dans une certaine mesure dans les réseaux BTC et ETH :

1. Le problème de la tragédie des biens communs de stockage de données

Lorsque nous utilisons la chaîne de blocs Bloc, nous devons payer des frais, mais dans le modèle économique du BTC, la structure des frais ne tient compte que des coûts de calcul et de bande passante réseau, sans tenir compte de manière mature des coûts de stockage des données.

Par exemple, les utilisateurs ne doivent payer qu’une seule fois pour stocker des données off-chain, mais la durée de stockage est permanente, de sorte que les ressources de stockage peuvent être utilisées de manière abusive pour mettre n’importe quoi sur la chaîne de manière permanente, ce qui finit par faire supporter des coûts de stockage de plus en plus élevés aux Full Nodes du réseau. Cela pose un problème : tout opérateur de nœud qui souhaite participer aux coûts de ce réseau sera maximisé.

Supposons que l’état/compte des données d’une certaine blockchain dépasse 1 To, il n’est pas facile pour tout le monde de synchroniser complètement l’état et l’historique des transactions. Dans ce cas, même si vous pouvez synchroniser l’état complet, il est difficile de vérifier indépendamment l’historique des transactions correspondant, ce qui affaiblirait la confiance sans tiers de la blockchain, qui est précisément la valeur fondamentale de la blockchain.

La Fondation ETH a pris conscience de ce problème et a donc inclus dans l’EIP-103 une conception de système de location de stockage, mais nous pensons que ce n’est pas la solution optimale.

Nous avons proposé un nouveau modèle d’état dans Nervos appelé “Cell”, qui peut être considéré comme une extension de l’UTXO. Dans l’état de l’UTXO du BTC, vous ne pouvez stocker que la valeur du solde BTC, alors que dans Cell, vous pouvez stocker n’importe quel type de données et généraliser la quantité et la valeur entière de l’UTXO du BTC en utilisant la “Capacité” pour spécifier la capacité de stockage maximale de la Cell.

De cette manière, nous associons la quantité et l’état des actifs natifs sur CKB à la taille de l’espace. Aucun espace occupé par une cellule ne peut dépasser sa limite de capacité, de sorte que la quantité totale de données reste dans une certaine plage.

De plus, nous assurons une inflation de Jeton appropriée pour garantir que la taille des données d’état ne perturbe pas les opérations des Nœuds. Tout le monde peut participer au réseau CKB et vérifier les données historiques ainsi que la validité de l’état final, ce qui est la solution proposée par CKB pour les problèmes de stockage sur la chaîne Bloc.

2.Problème de faim de couche 1

Si nous nous étendons sur Layer2 et déplaçons une grande quantité d’activités de transaction sur Layer2, il est inévitable que le nombre de transactions sur Layer1 diminue et que les récompenses économiques des Mineurs/Nœuds de Layer1 diminuent également. Cela entraînera une baisse de la motivation des Mineurs/Nœuds de Layer1, ce qui entraînera finalement une baisse de la sécurité de Layer1. C’est ce qu’on appelle le problème de la faim de Layer1.

Prenons un exemple extrême, si nous transférons toutes les activités de transaction sur L2, alors L1, qui en est la base, ne sera pas durable. Alors comment résoudre ce problème?

Pour ce faire, nous devons distinguer les différents types d’utilisateurs dans le réseau blockchain, qui peuvent être simplement divisés en utilisateurs de Store of Value (SoV user, utilisateurs de stockage de valeur) et utilisateurs d’utilité.

En prenant toujours CKB comme exemple, les utilisateurs de SOV utilisent l’actif natif CKB Jeton comme moyen de stockage de valeur, tandis que les utilisateurs d’utilité utilisent Cell pour stocker l’état. Les utilisateurs de SOV rejettent la dilution des prix causée par l’inflation de CKB Jeton, tandis que l’utilisateur d’utilité doit payer des frais de stockage d’état au Mineur, ces frais étant proportionnels à la durée et à l’espace de stockage des données.

Nous continuerons à émettre de nouveaux jetons CKB dans le réseau pour créer un taux d’inflation fixe et les donner aux mineurs, ce qui équivaut à diluer la valeur des jetons dans les mains des utilisateurs de services publics (c’est l’un des trois modes d’émission de CKB économique, appelé “émission de deuxième niveau”, qui émettra 1,344 milliard de jetons CKB chaque année, pour plus de détails, veuillez consulter “Interprétation de Stable++: Lancement officiel du premier protocole de stablecoin de la couche RGB++”).

Au cours de ce processus, les actifs des utilisateurs SoV sont également dilués, nous pouvons donc leur accorder une certaine compensation pour compenser les pertes d’inflation (ce qui deviendra plus tard la répartition NervosDAO). En d’autres termes, les mineurs ne sont rémunérés que par les utilisateurs de services publics pour les revenus qu’ils tirent de l’inflation CKB. Bientôt, nous publierons un document économique émettant des Jetons CKB, où ces questions seront expliquées en détail.

Basé sur une conception de tokenomics Jeton similaire, les mineurs peuvent recevoir une récompense même s’il n’y a aucune activité de transaction sur la chaîne CKB, ce qui nous permet de compatibiliser avec n’importe quelle couche de stockage de valeur ou Layer2. En résumé, nous résolvons le problème de la famine Layer1 grâce à une inflation fixe intentionnelle.

3. Manque de primitives de chiffrement

Les utilisateurs ont besoin de différentes primitives de chiffrement pour utiliser différentes méthodes de chiffrement ou différents algorithmes de signature, tels que Schnorr, BLS, etc.

Pour devenir une blockchain de couche 1, il est nécessaire de considérer comment interagir avec la couche 2. Certaines personnes de la communauté Ethereum proposent d’utiliser ZK ou Plasma pour réaliser la couche 2, mais comment pouvez-vous effectuer la vérification sur la couche 1 sans primitives ZK ?

De plus, Layer1 doit également envisager l’interopérabilité avec d’autres Layer1. Prenons l’exemple d’Ethereum, où certains demandent à l’équipe d’Ethereum de précompiler la fonction de hachage Blake2b en un opcode compatible avec l’EVM. L’objectif de cette proposition est de créer un pont entre Zcash et Ethereum afin que les utilisateurs puissent effectuer des transactions entre les deux. Bien que cette proposition ait été faite il y a deux ans, elle n’a toujours pas été mise en œuvre, principalement en raison du manque de primitives de chiffrement correspondantes, ce qui a sérieusement entravé le développement de Layer1.

Pour résoudre ce problème, CKB a construit une Machine virtuelle très abstraite, appelée CKB-VM, qui est complètement différente de la Machine virtuelle BTC et de l’EVM. Par exemple, BTC dispose d’un opcode spécifique OP_CHECKSIG utilisé pour vérifier les signatures secp256k1 dans les transactions BTC. En revanche, dans CKB-VM, les signatures secp256k1 n’ont pas besoin d’un traitement spécial et peuvent être vérifiées simplement à l’aide de scripts personnalisés ou de smart contracts.

CKB utilise également secp256k1 comme son Algorithme de signature par défaut, mais fonctionne dans CKB-VM plutôt qu’en tant que primitive de chiffrement codée en dur.

La raison initiale de la construction de CKB Machine virtuelle était que l’exécution de l’algorithme de chiffrement dans d’autres machines virtuelles telles que EVM était très lente, donc il fallait améliorer cette situation. La vérification d’une signature secp256k1 unique prend environ 9 millisecondes dans EVM, alors que l’utilisation du même Algorithme dans le calcul de CKB-VM ne prend que 1 milliseconde, ce qui représente une amélioration d’efficacité d’environ dix fois.

La valeur de CKB-VM réside dans le fait que les utilisateurs peuvent désormais personnaliser les primitives de chiffrement et que la plupart d’entre elles sont compatibles avec CKB-VM, car il utilise l’ensemble d’instructions RISC-V. Toute langue compilée par GCC (GNU Compiler Collection, un ensemble de compilateurs largement utilisé) peut être exécutée sur CKB.

De plus, la grande compatibilité de CKB-VM améliore également la sécurité de CKB. Comme les développeurs le disent toujours, « Ne créez pas votre propre version des algorithmes de chiffrement, vous le ferez toujours mal ». Définir soi-même un algorithme de chiffrement peut souvent entraîner des risques de sécurité imprévus.

En résumé, le réseau CKB résout les trois problèmes auxquels est confronté le réseau L1 que j’ai soulevés, ce qui explique pourquoi CKB peut être considéré comme un réseau Layer1 qualifié.