Conversation avec Cipher, le proposant du RGB++ : RGB++, UTXO et BTCFi à mes yeux

Le 22 juillet 2024, Geek Web3 a eu la chance d'inviter Cipher, le co-créateur de CKB et proposant de RGB++, à mener une série d'échanges sur RGB++ et le système UTXO, CKB lui-même et l'écosystème Bitcoin en ses yeux Au cours de cette période, Cipher He a parlé de son expérience passée, de l'importance unique de la couche RGB++ et du modèle UTXO pour BTCFi, ainsi que de quelques problèmes et opinions sur l'écologie CKB et Bitcoin. Les questions spécifiques abordées dans cette interview incluent :

1. L'expérience personnelle de Cipher

2 La connexion entre la pile UTXO et la couche RGB++

3. Vues sur la deuxième couche de Bitcoin et BTCFi, en particulier la deuxième couche du système EVM.

4 . Les scénarios et concepts de développement uniques de RGB++ Layer par rapport au système EVM

5 Interprétation de la propre philosophie de conception de CKB

6 Comment résoudre certaines lacunes du modèle UTXO dans la construction écologique Defi

7. choisit RISC-V et la sélection du langage de développement de contrat associé

8. Opinions sur les problèmes de décentralisation de l'écologie Bitcoin et Ethereum

Ce qui suit est la version texte de cette interview. Vous êtes invités à la lire attentivement.

Faust : Tout d’abord, souhaiteriez-vous que Cipher se présente ?

Cipher : Je suis entré en contact pour la première fois avec la blockchain en 2013 lorsque je participais au minage de Bitcoin. À cette époque, le minage n'était pas si impliqué. En conséquence, j'ai rencontré un fabricant louche lorsque j'ai acheté une machine de minage pour la première fois. . En 2014 ou 2015, parce que le prix du Bitcoin fluctuait considérablement, j’ai écrit un programme pour spéculer automatiquement sur les pièces et gagner un peu d’argent. Le marché baissier est arrivé fin 2015 et j'ai temporairement quitté le cercle des devises. À cette époque, je n'avais pas encore établi de foi et je ne faisais que spéculer.

En 2016, je suis officiellement entré dans l'industrie de la blockchain, je suis entré à l'institut de recherche blockchain au sein du système et j'ai participé au développement de la monnaie numérique et de la chaîne d'alliance de la banque centrale, avec le poste de chef de produit. Au cours de cette période, j'ai également rédigé des livres blancs, des premiers documents sur la protection de la vie privée dans l'industrie et des brevets liés aux droits de propriété numérique.

En 18 ans, j'ai complètement réalisé que la chaîne d'alliance était dans la mauvaise direction : toutes les alliances auront des chefs d'alliance, s'il y a un chef d'alliance, il n'est pas nécessaire d'utiliser la blockchain. S'il s'agit d'une chaîne d'alliance avec le préfixe. "国", ça n'aura encore plus de sens. Ce sont juste les mots du leader. Plus tard, je me suis tourné vers les chaînes publiques qui ne nécessitaient pas d’autorisation. Par hasard, plusieurs partenaires et moi-même avons participé aux premières constructions de CKB. J'étais responsable du produit et d'une partie des travaux de recherche.

Vers 2021, je deviendrai progressivement indépendant de la Fondation CKB et créerai ma propre entreprise pour réaliser des projets périphériques au sein de l'écosystème CKB, comme JoyID. JoyID compte actuellement plus de 500 000 utilisateurs et peut être considéré comme le portefeuille Passkey le plus complet du secteur. Bien que Passkey lui-même présente certaines limites en termes de compatibilité avec les appareils, notre portefeuille reste très facile à utiliser et peut éliminer directement le besoin de numéros de téléphone mobile. , adresses e-mail et mnémoniques. Le mot, en termes de modèle de sécurité, est un portefeuille non dépositaire.

À l’été de l’inscription en 2023, l’ensemble de l’écosystème Bitcoin a commencé à reprendre, voire à renaître. À la mi-février de cette année, j'ai proposé un concept, RGB++, avec la vision de créer un environnement de contrat intelligent natif pour BTCFi sans perdre la sécurité du Bitcoin. Nous avons rapidement constitué un groupe dédié et lancé le protocole RGB++ avant la réduction de moitié du Bitcoin en avril de cette année, et les résultats ont été plutôt bons. Dans le même temps, certains projets de l'écosystème CKB, notamment DEX, Launch pad et Suanwen, ont également été lancés les uns après les autres. Dans l’ensemble, l’écosystème RGB++ est en plein essor.

Après avoir résolu le problème de l'expansion des fonctions de BTC, nous nous sommes concentrés sur l'expansion et d'autres aspects. En avril, nous avons créé une société spécifiquement pour lancer la chaîne publique UTXO ou la pile UTXO de deuxième couche de Bitcoin. Quant à la raison pour laquelle nous avons choisi le modèle UTXO, l'essentiel est que Bitcoin lui-même est un modèle UTXO, et il est très différent d'Ethereum. Si nous appliquons la couche 2 sur Bitcoin, comment devrions-nous implémenter la preuve de transition d'état, inter-chaînes. retrait forcé des actifs et DA et autres parties ? Si vous copiez le modèle de compte d’Ethereum et les idées de Rollup, il sera difficile d’obtenir de bons résultats. C’est aussi mon point de vue depuis le début : copier les idées d’Ethereum sur Bitcoin ne se terminera guère bien.

UTXO Stack a actuellement finalisé le premier tour de financement, et le deuxième tour de financement est également en cours. Bien que la popularité de l'écosystème Bitcoin ait diminué récemment, nous sommes toujours très confiants et disposés à porter la bannière et à construire un proche. -Solution native pour l'extension des fonctions BTCFi et l'écologie programmable. À l'heure actuelle, nous avons travaillé davantage au niveau du marché et des entreprises, et certaines activités liées à l'environnement suivront. Vous pouvez vous attendre à des progrès dans ce domaine.

Wuyue : Quelle est la relation entre UTXO Stack et RGB++Layer ? Il semble y avoir une relation de subordination entre les deux ? Pouvez-vous donner une bonne introduction à cet aspect ?

Chiffre : La relation entre les deux peut être présentée sous deux angles. Du point de vue de la marque, RGB++Layer est un produit sous la marque UTXO Stack ; d'un point de vue technique, RGB++Layer utilise une liaison isomorphe pour ajouter une couche d'exécution de contrat intelligent à BTCFi. La liaison isomorphe s'applique non seulement à BTC et CKB, mais également au vaste écosystème de la chaîne publique tel que Cardano, Fuel et Sui, à condition qu'elle soit liée à UTXO.

Quant à UTXO Stack, il est quelque peu similaire à OP Stack et peut être utilisé pour démarrer rapidement BTC Layer2. Il est directement livré avec une fonction de liaison isomorphe, qui peut transférer les actifs BTCFi du réseau principal vers Layer2 pour les transactions via Leap. Le contrat intelligent d'OP Stack s'exécute sur Ethereum et le contrat intelligent d'UTXO Stack s'exécute sur la couche RGB++.

Pour en revenir à l'affiliation finale et à la priorité des deux, cela implique un problème logique : le principe de la création de tous les L2 est fondamentalement que L1 est déjà suffisamment encombré, ou que L1 a des fonctions limitées et ne peut pas répondre aux besoins des utilisateurs.

Actuellement, il n'y a pas tellement d'actifs et d'applications émergents sur la couche de contrat intelligent composée de Bitcoin + RGB++layer, nous espérons donc guider d'abord les nouveaux développeurs et utilisateurs vers RGB++Layer, pour développer des applications Defi, des plateformes de trading et l'émission d'actifs, développez d'abord l'écosystème BTCFi, puis approfondissez le travail L2. Ce n’est que lorsque BTCFi lui-même aura suffisamment de popularité que l’expansion de BTC deviendra une réelle demande. À l’heure actuelle, le lancement d’UTXO Stack sera une évidence.

Faust : Vous avez mentionné ici la deuxième couche de BTC. Les nouvelles récentes que nous avons reçues de certaines chaînes suggèrent également que la couche 2 de BTC a atteint un plancher périodique et que de plus en plus de personnes ou d'institutions prêtent attention à BTCFi. Mais de nombreux BTCFi ne sont que des modèles WBTC, reliant Bitcoin à d’autres chaînes publiques ou chaînes latérales Bitcoin, et ne sont pas du tout natifs BTC. À votre avis, quelle est la vraie différence entre quelque chose comme BTCFi et WBTC ?

Cipher : Mon point de vue constant est que le plafond de la couche 2 du système EVM est très bas. La raison est très simple. L'utilisation de l'EVM n'est pas d'étendre l'écosystème Bitcoin, mais d'introduire le BTC dans d'autres écosystèmes. Nous savons qu’il est difficile de mettre en œuvre des contrats intelligents sur le réseau principal Bitcoin, et le TPS ne peut pas être élevé. Il existe un moyen très simple : relier Bitcoin à d’autres endroits. Cela semble résoudre le problème, mais cela évite en fait l’essentiel :

De cette façon, la propre écologie de Bitcoin n’a pas été développée du tout, et il n’y aura pas de revenus pour les mineurs de Bitcoin, ni de données sur la chaîne, etc. changements, tout ce que vous faites est de combler les éléments les plus simples. Une fois le pont sorti, pouvez-vous obtenir de nouvelles histoires et de nouvelles scènes ? Évidemment pas. Parce que tout ce que vous faites a été fait très tôt par le WBTC et l’écosystème Ethereum. Il n’y a pas d’innovation, il s’agit simplement de la création d’un actif de pont BTC supplémentaire. Alors quel est le sens de votre existence ?

La même chose est EVM, pouvez-vous encore surpasser le système DeFi existant sur Ethereum ? La deuxième couche de Bitcoin basée sur EVM peut créer une fausse prospérité à court terme en raison des attentes de parachutage, mais son développement à long terme peut facilement être limité. Ce qui peut avoir un impact à long terme et renforcer l’écosystème Bitcoin doit être la couche 2, plus native, basée sur UTXO.

La deuxième couche dite native du BTC, son point attractif n'est pas sa légitimité, mais le fait que ce "natif" peut apporter des scénarios plus intéressants à l'écosystème Bitcoin. Par exemple, RGB++ dispose d'une technologie appelée Leap inter-chaînes sans pont. Les actifs BTCFi peuvent aller et venir entre L1 et L2 ou L2. Cette méthode n'a pas besoin de s'appuyer sur le paradigme Lock-Mint des ponts inter-chaînes traditionnels et peut être contournée. Les ponts inter-chaînes traditionnels comportent de nombreux risques, mais ils présentent également de grands avantages en termes de vitesse de réponse inter-chaînes et d'agrégation de liquidités, ce qui peut apporter une grande commodité à l'écosystème Defi. La fonction Leap est en ligne depuis avril et de nombreux utilisateurs apprécient le confort apporté par cette technologie. C’est l’une des innovations apportées par la solution native Bitcoin.

De plus, l'existence ou non d'attributs natifs de BTC affectera également le public. Par exemple, de nombreux détenteurs de BTC n’aiment même pas utiliser Metamask, préférant utiliser les portefeuilles traditionnels existants dans l’écosystème BTC. Bien qu'il existe certaines solutions dites AA qui permettent aux portefeuilles Bitcoin d'extraire les comptes au niveau de la couche d'application EVM, cette approche présente divers problèmes qui entraveront l'entrée des détenteurs de BTC. Une solution à deux couches basée sur UTXO comme la nôtre prend directement en charge l'interaction avec les portefeuilles Bitcoin. Son implémentation AA est plus proche de la couche inférieure et les utilisateurs peuvent même ne pas le remarquer. C'est très pratique, plus simple, plus facile à utiliser et plus transparent.

De plus, nous savons que le modèle UTXO est un « calcul hors chaîne, vérification en chaîne ». Ce modèle est particulièrement adapté aux scénarios de transactions basés sur l'intention. La soi-disant intention est que ma transaction indique uniquement au système ce que je suis prêt à payer et ce que je dois obtenir, mais je n'ai pas à me soucier de la façon d'appeler le contrat intelligent, de définir les paramètres de la fonction, etc. .Je mets les résultats d'entrée et de sortie que je veux, il suffit de les mettre sur la chaîne et de les vérifier. Si vous souhaitez réaliser des scénarios d'intention sur Ethereum, vous aurez peut-être besoin d'une série de composants tels que l'opérateur et l'agrégateur, qui sont relativement volumineux, mais dans le monde UTXO, c'est très simple. C'est aussi la caractéristique de la deuxième couche d'UTXO par rapport à la deuxième couche d'EVM. En bref, nous sommes optimistes quant à la nouvelle scène DeFi qu'UTXO peut créer pour la couche 2.

Faust : Quels sont les principaux points d'intégration entre RGB++Layer et BTC Quels scénarios sont les plus importants ? Que comprendront la prochaine disposition écologique de base et la feuille de route de RGB++ et CKB ?

Cipher : La combinaison des deux réside principalement dans divers scénarios d'application. Certains scénarios viennent d’être évoqués, et voici quelques exemples. Nous savons que les prêts flash sont très présents dans l'écosystème Ethereum. Il peut appeler en continu une série de contrats au sein d'une transaction, obtenir les résultats de la transaction et les afficher sur la plateforme de prêt : les actifs et les intérêts que je vous ai prêtés peuvent vous être restitués. instantanément vous. Nous pouvons utiliser des prêts flash en chaîne pour réaliser rapidement diverses activités financières, mais il n'y a pas de prêts flash dans le monde UTXO, mais il y a d'autres choses.

Par exemple, UTXO dispose d'un mécanisme d'imbrication de scripts de contrat qui peut générer en continu une série de transactions, simplifiant ainsi le processus de transfert de compte de l'utilisateur. Le résultat de la transaction précédente peut être directement utilisé comme paramètre d'entrée de la transaction suivante. , nous pouvons générer rapidement un lot d'instructions de trading connectées du début à la fin. Laissez-moi vous donner un exemple. Par exemple, si vous souhaitez créer un DeFi cross-chain, traversez d'abord les actifs de la chaîne A à la chaîne B, puis vendez-en la moitié en DEX, puis formez une paire LP avec la partie invendue. des jetons et les mettre dans la liquidité dans le pool sexuel. Ces opérations en quatre étapes sont implémentées dans le cadre de contrat intelligent de RGB++Layer en un seul clic à l'aide de la méthode d'imbrication de script de contrat mentionnée ci-dessus. Cela signifie que l'utilisateur n'a besoin d'exécuter l'ensemble des processus mentionnés ci-dessus qu'une seule fois, et le reste peut être complété automatiquement par le contrat intelligent décentralisé.

Il existe également un point d'intégration clair, qui est IB0, qui se finance via Bitcoin. Bien entendu, ce n’est pas nouveau. Ethereum utilise cette méthode de financement. Au début, un Bitcoin pouvait être échangé contre 10 000 ou 20 000 Ethereum. Mais le problème avec IB0 dans le passé était que même s'il s'agissait du même financement qu'IC0, il n'y avait pas de gameplay après la levée des actifs. Permettez-moi de vous donner un exemple, comme certaines ICO, qui ont une courbe de prix claire. Par exemple, après les 100 à 200 premiers blocs, le prix d'achat montre une hausse ou une baisse progressive. Dans certains cas, le premier acheteur doit se verrouiller. pendant un mois. La dernière personne à acheter devra peut-être rester bloquée pendant trois mois. Un autre exemple est de verrouiller pendant un mois de plus et de donner 50 % de pièces en plus, et de verrouiller pendant un an et de donner 100 % de plus. Il existe de nombreuses méthodes différentes comme celle-ci.

Auparavant, ce type de règles spéciales ne pouvait pas être implémenté sur IB0, mais nous pouvons changer cela via RGB++ Layer. Un problème majeur avec les actifs Bitcoin est qu’ils n’ont pas de programmabilité, ce qui équivaut à émettre uniquement des pièces Meme. Une fois qu’ils peuvent être combinés avec des contrats intelligents, cela signifie que les actifs peuvent être habilités. Ce n’est qu’une fois ces choses clarifiées que les projets seront prêts à construire l’écosystème Bitcoin.

Pour BTCFi ou n'importe quel Fi, le principe est d'avoir des actifs et des scénarios riches correspondants. Si cet actif est limité au BTC lui-même, il ne peut souvent s'engager que dans des scénarios uniques tels que le jalonnement à distance et le cross-chain. un écosystème pour prospérer Pour se relever, il faut émettre divers actifs pour laisser éclore une centaine de fleurs. Dans le monde Ethereum actuel, la valeur marchande des actifs ERC-20 et de l'ETH lui-même devrait être similaire, et cette dernière pourrait même être supérieure à la première, tandis que les actifs non BTC dans l'écosystème Bitcoin pourraient même ne pas représenter 1 % de la valeur marchande de l'ETH. valeur marchande du BTC. Par conséquent, comment créer de nouveaux actifs dans l’écosystème BTC est la clé du développement.

Je pense donc que la plus grande combinaison de RGB++ Layer et Bitcoin est d'utiliser la programmabilité de RGB++ Layer pour créer une classe d'actifs décentralisée qui donne réellement du pouvoir à Bitcoin. Cela ne s'est jamais produit auparavant avec Bitcoin. Cependant, il s'agit soit de Memecoin, soit d'actifs centralisés. En résumé, nous sommes très optimistes quant à la possibilité d’utiliser la couche de contrat intelligent pour créer de nouveaux actifs pour l’écosystème Bitcoin.

Faust : En 2018-19, CKB s'est positionné comme "Couche 1 conçue spécifiquement pour la couche 2". Il a réalisé de nombreuses conceptions de support dans des scénarios tels que le règlement du statut pour la couche 2. On peut dire qu'il a été spécialement conçu pour Rollup. Couche de vérification centralisée. À cet égard, quels sont selon vous les principaux avantages de CKB par rapport aux chaînes publiques ordinaires ?

Cipher : Il est en fait difficile de définir ce qu'est la couche un et la couche deux dans l'écosystème Bitcoin. Je pense que CKB et RGB++Layer ne sont pas basés sur la vérification et le règlement d'une certaine deuxième couche. En tant que chaîne UXTO, CKB est efficace pour vérifier les résultats des calculs hors chaîne, plutôt que d'exécuter des calculs directement sur la chaîne. C'est un point sur lequel Jan, en tant qu'architecte en chef, a insisté lors de la création de CKB. entre Les ressources informatiques, les ressources de stockage et les ressources de bande passante de la blockchain sont extrêmement précieuses. Elles ne doivent pas être utilisées pour effectuer des travaux complexes, mais doivent faire les choses les plus simples.

En fait, qu'il s'agisse de la couche 2 ou de la couche 1, un consensus doit être atteint sur le changement de statut, et il n'y a que deux façons d'atteindre un consensus. La première consiste à prendre le contrat qui exécute le changement de statut, et tout le monde peut le calculer. encore une fois et obtenir le même résultat Afin d'atteindre un consensus, c'est la logique du modèle de compte ; la seconde est que vous effectuez le changement de statut hors chaîne, et vous m'envoyez la preuve qui prouve sa validité, et je viens de le faire. Vérifiez la preuve. Il n'est pas nécessaire de calculer le contenu original moi-même. C'est en fait maintenant l'idée du Rollup.

Lorsque nous avons proposé la deuxième méthode en 2018, tout le monde pensait que c'était étrange. La calculer une fois et la vérifier à nouveau semblait être la même chose, mais Jan a dit qu'ils étaient en fait différents. Par exemple, dans les algorithmes de tri, la complexité de la vérification des résultats est bien moindre que la complexité du calcul direct. À cette époque, beaucoup de gens pensaient qu'il n'était pas nécessaire de faire cela pour les transferts d'actifs ERC-20 ordinaires, mais tout le monde connaît l'histoire plus tard. Qu'il s'agisse de ZK ou de Rollup, il s'agit d'un paradigme d'informatique hors chaîne et en chaîne. vérification. Ce n’est qu’alors que vous découvrirez que la deuxième méthode est plus efficace et plus précieuse.

Le modèle UTXO présente également de nombreux avantages pour le calcul parallèle. Nous savons qu'Ethereum a récemment mentionné le récit de l'EVM parallèle, mais par certains canaux, j'ai appris que le soi-disant EVM parallèle n'atteint souvent même pas 2 degrés de parallélisme après sa mise en service réelle. UTXO prend intrinsèquement en charge le calcul parallèle. Autant qu'il y a de cœurs de processeur, il peut y avoir autant de threads en parallèle. Cette efficacité ne peut être comparée à celle des éléments basés sur EVM.

Nous empruntons la voie UTXO depuis 5 ans. Dans certains des scénarios que nous venons de décrire, UTXO présente naturellement plus d'avantages que le modèle de compte. De plus, nous et Bitcoin sommes tous deux UTXO, qui peut prendre en charge la liaison isomorphe, simplifiant encore davantage certaines fonctions. Je pense donc que le principal avantage réside dans l’architecture. Il sera certainement plus efficace pour nous d’utiliser l’architecture UTXO pour nous connecter à Bitcoin.

Faust : Certaines personnes pensent qu'UTXO n'est pas propice au support de DeFi. Par exemple, il n'y a aucun moyen de s'appeler mutuellement entre les différents UTXO. Ils pensent même que RGB++ et CKB rencontreront de la résistance s'ils développent directement l'écosystème Defi sur. la première couche. Que pensez-vous de ces points de vue ? Et quelles solutions avez-vous introduites pour résoudre ces problèmes ?

Cipher : Tout d'abord, ces points de vue sont raisonnables dans une certaine mesure, car le modèle de compte est plus intuitif que le programme autonome précédent, il est acceptable d'envisager certains scénarios d'attaque. Le modèle UTXO n'est pas le cas. Le contrat que vous écrivez sur la chaîne est un validateur, et un calculateur spécial doit être construit à partir de la chaîne. Nous l'appelons généralement un agrégateur ou un générateur. Le générateur est chargé de calculer l'état hors chaîne, de le générer, puis de le jeter sur la chaîne pour vérification, ce qui est relativement compliqué.

S'il s'agit d'une plateforme DEX basée sur UTXO comme UTXOSwap, il vous est difficile de connaître le résultat lorsque vous lancez une transaction, car il peut y avoir 100 personnes soumettant l'opération en même temps, mais les attributs spéciaux d'UTXO le feront exiger que parmi 100 personnes, seules 100 personnes puissent soumettre l'opération en même temps. Si une personne peut réécrire son statut, des problèmes de contention surgiront. Si ces demandes de transaction conflictuelles ne sont pas traitées, seule une transaction sur 100 peut réussir et les 99 transactions restantes peuvent toutes échouer. Ce problème constitue un énorme défi pour la conception des produits, c'est pourquoi tout le monde dit que le modèle UTXO n'est pas propice à la DeFi.

Mais nous avons également constaté que même au cours des deux dernières années, de nouvelles chaînes UTXO sont apparues, comme Fuel. Pourquoi les gens continuent-ils à utiliser le modèle UTXO malgré toutes sortes de problèmes ? Parce qu’il présente de nombreux avantages, que j’ai déjà évoqués. Alors, avec le recul, comment pouvons-nous surmonter ces problèmes ? Après cinq ans de peaufinage, nous disposons déjà d'une solution très mature capable d'implémenter des fonctions de type Uniswap sur la chaîne UTXO. UTXOSwap dans l'écosystème a également été lancé sur le réseau principal il n'y a pas si longtemps, et de nombreuses personnes ajoutent déjà des LP et des paires de trading. Si vous en faites vraiment l'expérience, vous constaterez que ce n'est presque pas différent d'Uniswap.

En fait, la conception d'UTXOSwap est également très simple. Nous divisons chaque transaction en deux étapes. La première étape consiste pour l'utilisateur à soumettre son intention à la chaîne. La deuxième étape consiste pour l'agrégateur à regrouper l'intention de chacun et à l'initier. une transaction après la fusion. Une transaction interagit avec le pool de liquidité. Le pool de liquidité peut satisfaire ces intentions d’un seul coup et générer un UTXO final pour le résultat.

Il peut y avoir un problème de retard de bloc ici, car dans la première étape, l'utilisateur doit d'abord envoyer son intention individuelle à la chaîne, puis l'agrégateur/séquenceur la conditionnera et la traitera, puis passera à l'étape suivante sur le dernière chaîne. Cependant, en fonctionnement réel, les utilisateurs peuvent envoyer directement les intentions de transaction à l'agrégateur hors chaîne, et ce dernier les traitera par lots. Cela peut résoudre le problème du délai de réponse. En fait, c'est similaire au Rollup. Nous disposons déjà de solutions très matures à ces problèmes d'UTXO, et CKB travaille également sur certaines solutions pour mettre en œuvre les processus mentionnés ci-dessus.

Il y a un autre aspect, UTXO est très approprié pour prendre en charge le modèle du carnet de commandes. Dans le passé, il existait un modèle de carnet de commandes DEX sur Ethereum, mais il a disparu plus tard. Il y a de nombreuses raisons à cela. La raison principale est que le carnet de commandes DEX n'est pas adapté pour fonctionner sur le modèle de compte, car chaque commande en attente et. La commande annulée sera perdue même si elle n'est pas terminée. Il y a des frais de traitement, ce qui est inabordable pour PMF, c'est pourquoi le modèle AMM est apparu plus tard. Mais ce sera différent dans le modèle UTXO. Par exemple, 100 commandes peuvent être passées en même temps. Dans le monde UTXO, il est facile et peu coûteux d'associer une transaction à 100 UTXO. . Par conséquent, dans le modèle UTXO, le carnet de commandes DEX sera plus utile.

De plus, nous disposons également de la technologie de signature partielle PSBT. La transaction de commande en attente n'a même pas besoin d'être soumise à la chaîne. Vous pouvez simplement envoyer une signature concise qui regroupera les signatures de plusieurs parties et activera la transaction. la chaîne ensemble. De cette façon, le modèle de carnet de commandes sera plus adapté au modèle UTXO. En incluant AMM, vous pouvez utiliser des prix à intervalles comme UniswapV3 pour fournir de la liquidité virtuelle, en plaçant différentes actions de liquidité à des prix différents au lieu d'une courbe lisse.

Ce sont des scénarios DeFi uniques dans l'environnement UTXO, et ce sont tous des innovations d'assez haut niveau. Il est peu probable que ce niveau d'innovation soit réalisé sur une chaîne EVM. Les chaînes EVM sont pour la plupart des projets copiés sans aucune idée innovante. Nous voulons vraiment attirer les développeurs natifs de l’écosystème Bitcoin, ou les développeurs qui aiment le modèle UTXO. Ces développeurs ont souvent de fortes capacités et une volonté d’innovation. Nous sommes également très optimistes quant à la possibilité d’un nouveau paradigme BTCFi sous ce modèle.

Faust : CKB utilise le jeu d'instructions RISC-V et peut prendre en charge plusieurs langages de programmation. Cependant, certaines personnes pensent que prendre en charge trop de langages de programmation n'est pas une bonne chose et rendra l'écosystème de développeurs d'une chaîne publique confus et fragmenté. À cet égard, quel est selon vous le langage préféré pour le développement sur CKB ?

Cipher : Actuellement, Rust est le premier choix, suivi de C, qui ont tous deux un support relativement complet. RISC-V est désormais une architecture CPU grand public et devrait surpasser ARM d'ici 5 à 10 ans. Il prend également en charge de nombreux compilateurs. Mais actuellement, CKB prend officiellement en charge davantage de Rust et de C, ainsi que certains langages de script. Nous avons également créé nous-mêmes certains environnements d'exécution pour prendre en charge LUA et Javascript, mais la perte de performances sera énorme et, à l'extrême, il peut s'agir d'un ralentissement de 30 à 300 %. Par conséquent, s'il s'agit d'une entreprise à forte intensité d'algorithmes, il est toujours recommandé de l'écrire en Rust ou en C, et il n'y aura pas trop de langages de programmation​​pour fragmenter l'écosystème des développeurs.

Je veux en fait parler des avantages de RISC-V lui-même. Lorsque nous avons lancé CKB en 2018, nous étions les seuls au monde à choisir d'utiliser RISC-V comme machine virtuelle à chaîne publique. simple. RISC-V convient aux périphériques matériels. Le jeu d'instructions est conçu avec deux caractéristiques : simplicité et prudence. Étant donné que le jeu d'instructions est conçu pour le matériel, il est souvent relativement stable et n'augmente ou ne diminue pas les instructions chaque année comme EVM. Ce type de prudence est exactement ce qu'exigent les protocoles open source.

Deuxièmement, pour les plateformes de contrats intelligents ou les blockchains, nous pensons qu'il est préférable de ressembler à Bitcoin, avec ses fonctions de base tendant à être corrigées, sinon il sera trop facile de causer des problèmes en ajoutant ou en soustrayant du contenu tous les trois jours. On peut dire que toute notre réflexion est différente de celle d’Ethereum. EVM itère essentiellement les opcodes chaque année, et cela a été le cas ces dernières années. Cela aura un impact sur la compatibilité et la stabilité du programme, ce que nous faisons de notre mieux pour éviter. C'est donc sur la base de cette idée que nous avons adopté le jeu d'instructions RISC-V, qui s'est avéré très avant-gardiste.

Maintenant que ZK devient populaire, vous constaterez que de nombreux projets utilisent RISC-V comme machines virtuelles au niveau inférieur. En tant que chaîne publique basée sur RISC-V, il nous est très facile d'être compatible avec le nouveau ZK. Au niveau de l'instruction, aucune traduction n'est requise et l'efficacité est évidemment bien supérieure à l'exécution de RISC-V sur l'EVM.

Faust : Du point de vue de CKB, que pensez-vous de l'écosystème Bitcoin ? Par exemple, pensez-vous qu’il existe une organisation centralisée similaire à la Fondation Ethereum dans l’écosystème Bitcoin actuel ? Certaines personnes ont pensé que BlockStream était un peu arbitraire. CKB a-t-il sa propre opinion à ce sujet ?

Cipher : Je pense que la structure de l’écosystème Bitcoin est complètement différente de celle de l’écosystème Ethereum. La Fondation Ethereum a une voix très forte. En regardant le monde Bitcoin, on peut dire que les principaux développeurs derrière elle sont une organisation avec une influence relativement forte. Cependant, il existe des freins et contrepoids évidents de la part de plusieurs parties dans l'écosystème Bitcoin. Il existe une relation de jeu solide entre les pools miniers, les développeurs et les principaux acteurs du Bitcoin. Cela ne signifie pas que les mineurs accepteront inconditionnellement tout ce que les développeurs proposent. Si la proposition est excessive, les mineurs et les pools miniers s'y opposeront directement.

Je pense que ce point est différent d'Ethereum. Des choses comme Ethereum POW to POS et EIP-1159 étaient très controversées à l'époque, mais la Fondation Ethereum ou Vitalik lui-même ont largement couvert le ciel d'une seule main. D’un autre côté, l’écosystème Ethereum est désormais très vaste, avec de nombreux actifs émis de manière centralisée, tels que les RWA, les stablecoins, etc. Une fois qu’un véritable fork se produit, ce sont ces actifs centralisés qui détermineront véritablement l’orientation future de l’émetteur.

Ainsi, que ce soit subjectivement ou objectivement, les forces centralisées dirigées par EF dans l'écosystème Ethereum ont une voix beaucoup plus forte que les différentes organisations de l'écosystème Bitcoin. Un autre point est qu'il n'y a pas de valeurs particulièrement unifiées dans l'écosystème Bitcoin. Par exemple, les développeurs principaux sont plus proches du maximalisme du Bitcoin et résistent à des choses comme OP_CAT ou des inscriptions. Ils espèrent que Bitcoin n'apportera pas trop de changements aux développeurs périphériques. enclin à soutenir le passage d'OP_CAT ou similaire. Sur la couche externe, des équipes telles que Lightning Network et RGB sont plus enclines aux nouveautés que les deux premières. Ensuite, il y a des gens comme nous qui sont non seulement plus disposés à accepter de nouvelles choses, mais qui prennent également l'initiative de rechercher l'innovation et le changement. La dernière couche est la deuxième couche du pont multi-signature et du système EVM.

Parce qu'il existe toutes sortes de personnes d'origines différentes, l'écosystème Bitcoin est très tolérant. Il n'y a pas lieu de craindre qu'une certaine couche ou une certaine personne se trompe. Ses erreurs biaiseront l'ensemble de l'écosystème. Il y a tellement de groupes de personnes, du moment qu'un groupe a raison à la fin. Bien que le modèle d'Ethereum soit plus rapide en surface, le modèle de Bitcoin est plus stable. Il n'y a pas lieu de s'inquiéter d'une mauvaise décision d'une petite personne qui entraînera l'ensemble de l'écosystème dans l'abîme. De ce point de vue, nous sommes très optimistes quant à l’écosystème Bitcoin, car il ressemble à un creuset doté de fortes capacités d’inclusivité et de correction d’erreurs.

Prenons à nouveau la deuxième couche de BTC comme exemple. J'ai vu que votre site Web BTCEden résume diverses solutions avec différentes idées, y compris des modes de vérification client tels que Lightning Network et RGB, ainsi que des chaînes latérales et même sur Ethereum sur la seconde. étage de Fangfang et Bitcoin, bref, une centaine de fleurs s'épanouissent, chacune montrant ses capacités. Et si vous regardez Ethereum, personne n'a fait Sharding, et personne n'a rien fait concernant les canaux d'état et Plasma. Il n'y a presque qu'une seule route du système Rollup. Alors bien sûr nous préférons l’écosystème Bitcoin, plus libre et plus stable.

CKB 재단은 의사결정을 보다 분산화하기 위해 노력하고 있습니다. 물론 지금은 기초도 아니고 발언권도 없지만 점차 커뮤니티 중심으로 변해가는 역할이 많아지는 모습을 볼 수 있습니다. CKB의 전체 규모는 여전히 상대적으로 작으며, 분산형 의사결정에 대한 수요는 그다지 크지 않습니다. CKB에 대한 모든 사람의 기대는 더 빠를 수도 있습니다. 그러나 제가 아는 한, CKB의 핵심 의사 결정자들은 매우 개방적이며 자신의 손에 너무 많은 권한을 부여하지 않을 것입니다. 그들은 확실히 탈중앙화를 완료할 적절한 시기를 찾을 것입니다.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!