Tous les protocoles Web3 n'ont pas besoin d'un Native Token

Lors du développement d'un nouveau protocole, l'hypothèse par défaut est presque toujours qu'un nouveau token natif doit suivre. La plupart des blockchains et des frameworks Web3 s'appuient sur des systèmes cryptoéconomiques comprenant des incitations et des pénalités pour maintenir la sécurité du protocole et dissuader les acteurs malveillants.

\ Cependant, le déploiement d'une nouvelle application Web3 en tant que solution "roll up" ou "Layer Two" est devenu courant ces dernières années. Qu'elle soit implémentée comme un roll up sur Ethereum, une parachain sur Polkadot, ou un subnet sur Avalanche, l'objectif principal est de tirer parti de la robuste sécurité économique du réseau parent, en utilisant son important pool de validateurs et ses garanties de sécurité.

Les obstacles : Justification pour un Token séparé

Actuellement, le défi technique de construction d'une blockchain a été considérablement atténué grâce à la disponibilité de nombreux SDK et frameworks. Des outils tels que le SDK Polkadot et le SDK Cosmos permettent aux développeurs d'utiliser des modèles et de lancer rapidement un réseau fonctionnel, avec toutes les fonctionnalités standard que l'on attendrait de tout protocole Web3 standard.

\ Malgré ces avancées, une barrière majeure demeure : l'identité, à savoir, s'assurer que nous avons une certaine résistance aux attaques Sybil.

\ ==Nous avons toujours besoin d'un moyen pour garantir que les acteurs malveillants ne puissent pas complètement spammer ou nuire à notre réseau, ce qui est l'une des principales raisons pour lesquelles les aspects économiques des systèmes cryptoéconomiques comme le Proof of Work ou le Proof of Stake existent.==

\ La tokenomique devient alors une préoccupation subséquente : si le modèle de token d'un projet est défectueux ou mal conçu, il peut compromettre l'ensemble de l'effort, quelle que soit la qualité de la technologie sous-jacente.

\ La nécessité de concevoir et de sécuriser un réseau cryptoéconomique entièrement séparé présente un obstacle considérable pour les développeurs et les startups dont la mission principale est de construire une application ou une infrastructure supérieure et plus résiliente, et non de gérer une politique monétaire.

\ Heureusement, le paysage évolue, offrant une solution à cette complexité.

La solution : Utiliser le Token du réseau "parent"

Si un nouveau protocole s'appuie sur un réseau existant et se déploie en tant que roll up/Layer Two, ils devraient, par nature, hériter de leur sécurité du réseau parent.

\ Cela soulève une question critique : pourquoi ne pas simplement utiliser le token natif du réseau parent pour toutes les opérations ? Tout est déjà configuré ; nous devons juste nous assurer que nous pouvons effectuer en toute sécurité des vérifications et des équilibrages lors des transferts vers et depuis le réseau parent. ==À l'avenir, il pourrait être possible de lancer un roll up sans token du tout, si nous résolvons le problème Sybil, et en supposant que nous ayons un réseau parent qui fournit la sécurité pour notre roll up/service.==

\ Polkadot permet le lancement d'une parachain "sans token". La parachain peut plutôt utiliser le token de la Layer One (comme DOT sur Polkadot) pour faciliter toutes les opérations, y compris les frais de transaction et les mécanismes de sécurité.

\ Cette approche libère l'équipe pour se concentrer sur ==la construction de solutions et la logique d'application centrale==. En d'autres termes, vous vous concentrez davantage sur la mise en route de votre protocole afin de pouvoir construire votre application/infrastructure résiliente plutôt que d'être enlisé par les mécanismes de token.

Un exemple concret : EduChain

Ce concept n'est pas simplement théorique. L'équipe d'éducation technique de la Web3 Foundation (dont je fais partie !) a expérimenté avec EduChain, qui sert de démonstration en direct de cette configuration sans token. Elle utilise le token du réseau parent, spécifiquement le token PAS sur le testnet Paseo, comme sa monnaie fonctionnelle.

\ La configuration d'EduChain fonctionne via un transfert adossé à une réserve utilisant XCM, qui fonctionne comme suit :

\

• Offre initiale nulle : la chaîne commence avec une offre totale nulle de son propre token potentiel. Pour financer un compte réseau, un transfert cross-chain via XCM doit être initié depuis le réseau parent (Paseo).

• La réserve et le compte souverain : La parachain désigne une parachain système (comme le Paseo Asset Hub) comme réserve pour le token parent (PAS). Lors de la création de la parachain, un compte spécialisé, connu sous le nom de compte souverain, est automatiquement généré sur la chaîne parent exclusivement pour la parachain.

• Transfert de PAS :

• Lorsqu'un utilisateur envoie du PAS depuis son compte sur la chaîne parent (Paseo) vers la parachain (EduChain), le PAS est déposé dans le compte souverain de la parachain sur la chaîne parent, où il fonctionne comme réserve.

• Simultanément, un nouvel actif local représentant le PAS est créé sur la parachain et crédité sur le compte de l'utilisateur.

• Lorsqu'un utilisateur renvoie cet actif local vers la chaîne parent, l'actif local est brûlé sur la parachain, et le montant correspondant de PAS est débloqué et transféré du compte souverain vers le compte du bénéficiaire sur la chaîne parent.

  \

Ce mécanisme XCM garantit que chaque unité de PAS sur la parachain est entièrement adossée 1:1 par du PAS réel détenu dans une réserve sécurisée sur le réseau parent, éliminant ainsi la nécessité d'un token distinct spécifique au projet.

\ En règle générale, une parachain contrôle sa propre représentation locale d'un actif et pourrait, en principe, modifier ces soldes selon sa propre gouvernance. Cependant, l'Asset Hub — en tant qu'emplacement de réserve — maintient la comptabilité canonique adossée à la réserve pour cet actif à travers le réseau, et les parachains sont censées utiliser les instructions XCM via l'Asset Hub afin que cette comptabilité reste correcte et cohérente.

\ Pour des détails complets sur EduChain et ses mécanismes opérationnels, la documentation est disponible à : https://web3educhain.xyz/

Conclusion

Cet article visait à mettre en évidence le potentiel significatif de déléguer les préoccupations économiques et de sécurité d'un roll up ou d'une Layer Two au réseau parent lui-même. En employant des transferts XCM adossés à des réserves, un projet peut complètement contourner les difficultés substantielles associées au lancement d'un nouveau protocole Web3, permettant à l'équipe de consacrer tout son effort à la construction d'une application supérieure et à la résolution de problèmes du monde réel.

\ Les personnes intéressées par la mise en œuvre de cette solution peuvent explorer le lancement d'une parachain sur Paseo, ainsi que le dépôt EduChain pour plus d'informations :

\

• Tutoriels Parachain Zero To Hero
• Web3 Educhain

\