Auteur: KarenZ, Foresight News
Les 25 et 26 juin, le réseau principal de Base a connu des interruptions consécutives de la production de blocs pendant deux jours. Base a ensuite fourni un compte-rendu, indiquant que les deux pannes étaient dues au même problème sous-jacent : un bug dans la logique de construction de blocs du séquenceur.
Selon l'analyse de Base, ce bogue a conduit à ce que l'état obsolète des journaux persiste après l'échec de la validation des transactions, affectant le calcul du Gas pour les transactions valides ultérieures, générant ainsi des blocs de transfert d'état invalides et arrêtant toute production de blocs sur le réseau L2. Après la première interruption, le problème a été corrigé par un patch, rétablissant la production de blocs. De plus, un état de concurrence critique dans la réinitialisation des moteurs lors du redémarrage du cluster de séquenceurs de Base a empêché la reprise de la synchronisation, contribuant indirectement à la brève panne du lendemain.
Au cours de cette même période, le déploiement prévu de B20 sur le réseau principal a également été mis en pause.
Le 26 juin, Base a déclaré : « En raison des récents problèmes de stabilité du réseau, le déploiement sur le réseau principal du B20 Activation Registry est reporté pour garantir un processus de mise en ligne fluide. »
Cette approche, bien que prudente, montre en réalité l'importance cruciale de B20. Il ne s'agit pas d'une mise à jour d'application périphérique, mais d'une porte d'entrée au niveau de la chaîne que Base prévoit d'utiliser pour accueillir les stablecoins, les RWA (Real World Assets) et d'autres émissions d'actifs. Plus cette porte d'entrée est proche de la couche inférieure, plus il est essentiel de considérer non seulement la fonctionnalité, mais aussi la stabilité du réseau, le rythme des mises à niveau et la conception des autorisations pour tout supporter.
B20 : L'interface native d'émission de jetons sur Base
B20 fait partie de la mise à niveau du réseau Beryl de Base. Les trois changements majeurs de Beryl sont : l'introduction de B20, la réduction du délai de finalisation pour les retraits à preuve unique courants de 7 à 5 jours, et l'amélioration du stockage des nœuds et des performances de débit via Reth V2.
On peut d'abord comprendre B20 de manière très simple : c'est la version Base de l'ERC-20, mais elle intègre dans les composants natifs de Base une grande partie de la logique que les projets écrivaient, auditaient et maintenaient eux-mêmes auparavant.
Un jeton ERC-20 ordinaire est généralement porté par un contrat intelligent déployé par le projet, gérant la logique des soldes, des autorisations, des transferts, des émissions, des destructions, etc. La différence avec B20 est que le jeton possède toujours une adresse on-chain et peut être appelé par les portefeuilles, les explorateurs et les protocoles DeFi comme un ERC-20 ; cependant, B20 est implémenté via un précompilateur Rust et non un contrat intelligent EVM, ce qui le rend plus rapide et moins coûteux.
En d'autres termes, les intégrateurs externes voient une interface de jeton compatible ERC-20, tandis que les émetteurs accèdent à une infrastructure d'émission de jetons intégrée à Base.
C'est également pourquoi B20 est appelé le standard natif de jeton de Base. La documentation officielle de Base précise que B20 est la propre version Base de l'ERC-20, supportant les appels et événements standard ERC-20 comme le transfert, l'autorisation de transfert par un tiers, l'approbation de montants, la consultation des soldes, les allowances ; tout en ajoutant des capacités étendues comme les mémo, le minting/burning, les stratégies de contrôle d'accès, les suspensions granulaires et la fonction ERC-2612 permit (autorisation par signature).
Il convient d'expliquer séparément l'ERC-2612 permit, c'est-à-dire la capacité d'autorisation par signature. Dans un ERC-20 classique, lorsqu'un utilisateur souhaite autoriser un contrat à dépenser ses jetons, il doit généralement effectuer une transaction `approve`, qui nécessite du Gas. L'ERC-2612 permit permet à l'utilisateur d'utiliser une signature hors ligne de son portefeuille pour autoriser, le projet ou l'application soumettant ensuite cette signature sur la chaîne. L'utilisateur n'a pas besoin d'effectuer lui-même une transaction `approve` distincte, réduisant ainsi une opération on-chain.
Pour utiliser une analogie plus concrète, le ERC-20 traditionnel ressemble à chaque émetteur construisant sa propre maison avec des plans standard, la qualité de construction dépendant de son développement et de son audit. B20 ressemble plus à une structure préfabriquée unifiée fournie par Base : l'entrée, les interfaces et les fonctions clés sont standardisées, l'émetteur décide toujours des paramètres de l'actif et des règles de gestion, mais les capacités de base proviennent du même ensemble de composants au niveau de la chaîne.
En termes de déploiement, B20 ne permet pas non plus aux projets de simplement copier un contrat de jeton. Tous les jetons B20 sont créés via le précompilateur singleton B20 Factory, en choisissant la variante Asset ou Stablecoin, et en transmettant des paramètres tels que le nom, le symbole, l'administrateur initial, le plafond d'offre, l'appel d'initialisation, etc.
Ainsi, l'objectif principal de B20 n'est pas de faire de l'émission de jetons un bouton front-end plus joli, mais de faire passer cette émission de « chaque projet écrit son propre contrat » à « Base fournit une interface d'émission unifiée et des capacités de stratégie intégrées ». Il réduit le coût de reconstruction répétitive des fonctions standard, tout en intégrant plus profondément l'émission d'actifs dans les mises à niveau de base de Base.
Le véritable enjeu est le « contrôle » : permissions, listes noires/blanches, gel et mémo
La boîte à outils de l'émetteur listée par Base comprend : compatibilité ERC-20, ERC-2612 permit, contrôle d'accès basé sur les rôles, mint/burn, plafond d'offre optionnel, stratégies de transfert, destruction des soldes des adresses gelées par politique, et mémo de transfert.
Ces fonctions semblent techniques, mais dans la pratique des émetteurs, elles répondent principalement à trois types de problèmes : qui a le droit de gérer le jeton, quelles adresses peuvent participer à la circulation, et comment laisser une trace traçable des opérations on-chain.
Premièrement, les permissions de gestion peuvent être hiérarchisées. Les droits de mint, burn, suspendre les transferts, reprendre les transferts, modifier les métadonnées ne doivent pas être mélangés dans un seul rôle d'administrateur. La documentation de B20 liste les rôles par défaut : administrateur, mint, burn, suspension, reprise, gestion des métadonnées, etc. Ainsi, l'émetteur peut confier différentes opérations à différents rôles, réduisant le risque d'une clé privée unique ou d'un administrateur unique ayant trop de pouvoir.
Deuxièmement, la portée de circulation des jetons peut être contrainte par des stratégies. Le Policy Registry de B20 prend en charge les listes blanches et noires. L'émetteur peut contraindre séparément les adresses d'envoi de transfert, les adresses de réception de transfert, ainsi que l'appelant qui initie le transfert dans le scénario `transferFrom` ; dans les scénarios de mint, il peut également contraindre l'adresse de réception des nouveaux jetons créés. En termes simples, B20 peut gérer « qui envoie, qui reçoit, qui initie le transfert pour le compte d'autrui », et aussi « dans les mains de qui vont les nouveaux jetons ». Ces capacités sont particulièrement importantes pour les stablecoins, les RWA et les actifs réglementés, car ces actifs nécessitent souvent des adresses KYC, des destinataires restreints, des gels et des voies de traitement ultérieures.
Troisièmement, les opérations on-chain peuvent laisser un index métier. B20 prend en charge le mémo, c'est-à-dire un champ de remarque `bytes32` attaché aux opérations sur les jetons. Il ne remplace pas un registre comptable off-chain complet, mais peut servir de point de connexion entre une transaction on-chain et des enregistrements off-chain. Par exemple, un paiement on-chain peut correspondre à un numéro de commande, un remboursement à un règlement backend, une émission à un lot d'enregistrements de distribution ; le mémo peut aider l'émetteur, le portefeuille, le dépositaire ou un service d'indexation à faire correspondre ces informations.
Conclusion
Il faut cependant préciser que B20 ne fait que mettre les outils à disposition des émetteurs, et ne s'occupe pas automatiquement de la conformité pour eux. Chaque portée de stratégie est par défaut `ALWAYS_ALLOW` lors de la création du jeton, c'est-à-dire que tout est autorisé par défaut. Si l'émetteur n'établit pas activement de liste blanche, de liste noire ou d'autres restrictions, ce jeton B20 circulera librement comme un jeton ouvert ordinaire.
En d'autres termes, B20 donne à l'émetteur la capacité de « définir des règles », mais la décision de les établir ou non, et comment, reste à la charge de l'émetteur.
Cela explique également pourquoi B20 s'adresse principalement aux émetteurs de stablecoins, aux créateurs de jetons RWA et d'autres actifs. Les stablecoins ont besoin de capacités de permission et de gel, les RWA nécessitent des restrictions de transfert et des mappages avec les registres off-chain, et d'autres actifs nécessitent des coûts d'émission standardisés plus faibles. Ces trois besoins semblent différents, mais au fond, ils pointent vers la même question : une L2 peut-elle offrir une intégration suffisamment unifiée, suffisamment contrôlable, et suffisamment fluide avec l'écosystème ERC-20 existant ?
