Explorer Berachain : analyse des protocoles natifs et des aspects techniques
TechFlow SélectionTechFlow Sélection
Explorer Berachain : analyse des protocoles natifs et des aspects techniques
Analyse de l'architecture de Berachain, des conceptions de ses trois applications natives et des processus d'exécution des contrats associés.
Dédié à des analyses Web3 approfondiesRédaction : Beosin
Berachain, une blockchain très surveillée par le marché, dispose de plusieurs innovations et caractéristiques qui attirent l'attention d'une grande communauté et de nombreux développeurs. Grâce à son mécanisme PoL et son modèle à trois jetons, Berachain propose une solution unique aux problèmes de liquidité sur la chaîne. Alors que Berachain s'apprête à lancer son réseau principal, il a mis en place un programme incitatif et une TGE afin d’attirer et soutenir les premiers utilisateurs et projets de son écosystème.
Cet article explique l'architecture de Berachain, la conception de ses trois applications natives et les processus d'exécution des contrats associés, afin d'aider les lecteurs à mieux comprendre Berachain.
1. Architecture
Berachain est une chaîne EVM équivalente de niveau 1 (Layer1) qui se distingue par l'introduction d'un modèle à trois jetons et d'un mécanisme de consensus Proof-of-Liquidity (preuve de liquidité), intégrant liquidité, consensus et gouvernance. Ce système offre davantage d'incitations aux fournisseurs de liquidité au sein de l'écosystème de la chaîne.
L'architecture de Berachain se divise principalement en deux niveaux :
(1) La couche de consensus BeaconKit. Cette couche gère principalement le mécanisme de consensus de la blockchain, en utilisant CometBFT comme algorithme de base, enrichi du Proof-of-Liquidity. CometBFT est un protocole de consensus basé sur Tendermint, offrant une confirmation rapide des transactions et une tolérance aux fautes byzantines (BFT). Dans Berachain, BeaconKit encapsule davantage CometBFT pour permettre son interaction avec tout environnement d'exécution compatible avec la machine virtuelle Ethereum (EVM).
(2) La couche d’exécution EVM. La couche d'exécution de Berachain utilise la même machine virtuelle qu'Ethereum — l’EVM (Ethereum Virtual Machine) — garantissant ainsi la compatibilité avec les outils existants d'Ethereum, les contrats intelligents et l'écosystème. Les développeurs peuvent donc transférer directement leurs contrats intelligents et applications décentralisées (dApps) d’Ethereum vers Berachain.
Les nœuds dans Berachain sont divisés en deux types : les nœuds validateurs et les nœuds RPC. Chaque nœud peut être configuré en nœud complet ou nœud d'archive. Chaque type de nœud combine un client d'exécution et un client de consensus, ce qui signifie qu'au niveau exécution, il supporte tout client EVM d'exécution, apparié avec le client de consensus BeaconKit et sa structure conçus par Berachain.
● Client d’exécution : responsable de l'exécution du code des contrats intelligents, de la gestion des changements d'état et de la logique des transactions. En utilisant l'API Ethereum Engine, Berachain prend en charge six clients d'exécution EVM majeurs : Geth, Erigon, Nethermind, Besu, Reth et Ethereumjs.
● Client de consensus : chargé d'atteindre un consensus entre les nœuds du réseau, assurant la validation et l'ordonnancement des transactions et blocs. Berachain utilise BeaconKit comme client de consensus.
2. Proof-of-Liquidity (PoL)
Le modèle économique Proof-of-Liquidity (PoL) de Berachain implique trois jetons principaux :
$BERA : Le jeton natif gas de Berachain, utilisé pour payer les frais de transaction et comme jeton de mise en jeu (staking) pour les validateurs.
$BGT : Le jeton de gouvernance de Berachain, utilisé pour participer à la gouvernance on-chain, distribuer des récompenses et déléguer aux validateurs. Ce jeton se distingue des jetons de gouvernance traditionnels par le fait qu'il s'agit d'un jeton « soulbound », c'est-à-dire non transférable. Ainsi, les utilisateurs ne peuvent pas transférer BGT entre adresses différentes, mais peuvent échanger BGT contre BERA selon un ratio 1:1. Il convient de noter que cette opération est unidirectionnelle : BERA ne peut pas être reconverti en BGT. En tant que jeton « soulbound » non transférable, BGT symbolise que seuls les utilisateurs ayant réellement participé à l'écosystème Berachain (par exemple en fournissant de la liquidité ou en empruntant) peuvent participer à la gouvernance, et non ceux qui l'auraient acquis par achat ou échange.
$HONEY : La monnaie stable native de Berachain, servant de moyen fiable et stable d’échange à l’intérieur et à l’extérieur de l’écosystème. Selon la présentation officielle, sa valeur est indexée sur 1 dollar américain. HONEY est une monnaie stable entièrement garantie, frappée en déposant des collatéraux approuvés dans un coffre-fort. Chaque type de collatéral a un taux de frappe différent, défini par la gouvernance via BGT.
Le mécanisme Proof of Liquidity (PoL) adopté par Berachain diffère des mécanismes de consensus traditionnels (comme PoW ou PoS), car il tient compte des contributions de tous les fournisseurs de liquidité de l'écosystème. Par le biais du minage de liquidité et du staking, Berachain utilise PoL pour inciter davantage d'utilisateurs à participer à l'ensemble de son écosystème. Voici, à titre d'exemple, le flux principal de PoL dans l'écosystème Berachain, illustré via BEX, le DEX natif de Berachain :
-
Staking initial : L'utilisateur stake d'abord BERA pour devenir un validateur éligible à proposer des blocs.
-
Proposition de bloc : Un validateur actif est sélectionné aléatoirement pour proposer un nouveau bloc.
-
Distribution des récompenses : Le validateur proposant le bloc reçoit des jetons de gouvernance (BGT), qu’il distribue ensuite vers différents fonds de récompense de l’écosystème, paramétrés par chaque validateur.
-
Fournisseurs de liquidité : Sur BEX, les fournisseurs de liquidité peuvent déposer des jetons (par exemple HONEY et BERA) dans les pools pour fournir de la liquidité, obtenir des jetons justificatifs de liquidité (ex. $HONEY-WBERA), puis staker ces derniers dans les fonds de récompense afin de recevoir des récompenses en BGT proportionnelles à leur contribution.
-
Délégation du jeton de gouvernance : Les détenteurs de BGT peuvent déléguer leurs jetons à des validateurs actifs, augmentant ainsi le poids de distribution des récompenses de ces validateurs lors de la proposition de blocs, influençant ainsi la répartition des BGT, sans toutefois affecter la probabilité de création de blocs par le validateur.
Actuellement, les jetons de gouvernance BGT proviennent principalement de trois dApps natifs officiels sur Berachain : le DEX natif BEX, le protocole de prêt non gardé Bend, et la plateforme de trading à effet de levier décentralisée Berps. Cet article se concentre principalement sur la logique métier de ces trois projets.
3. PoL et BEX
BEX (Berachain Exchange) est le protocole DEX natif de Berachain, permettant aux utilisateurs d'échanger n'importe quelle paire d'actifs cryptographiques sans intermédiaire. BEX est un composant clé de l'écosystème Berachain, et en tant que DEX natif, il s'intègre étroitement au mécanisme de consensus PoL via les moyens suivants :
-
Pools de liquidité : Les pools de liquidité sur BEX peuvent être mis à niveau via la gouvernance en fonds de récompense PoL, devenant ainsi éligibles aux récompenses en BGT.
-
Fournisseurs de liquidité : Les utilisateurs peuvent fournir de la liquidité sur BEX, obtenir des jetons LP, puis staker ces jetons dans les fonds de récompense PoL pour gagner des récompenses en BGT.
-
Gouvernance : Le mécanisme de gouvernance de BEX permet, par le biais de propositions, d'ajouter de nouveaux pools de liquidité à la liste blanche des fonds de récompense PoL, leur permettant ainsi de recevoir des récompenses en BGT.
En analysant les contrats sur le réseau test, l'architecture principale de BEX se compose actuellement de trois parties. La première est le contrat BeraCrocMultiSwap (https://bartio.beratrail.io/address/0x21e2C0AFd058A89FCf7caf3aEA3cB84Ae977B73D), qui gère les échanges multi-paires de jetons ; lorsque l'échange d’un utilisateur nécessite un jeton intermédiaire, ce contrat est appelé.
La deuxième partie est le contrat CrocSwapDex (https://bartio.beratrail.io/address/0xAB827b1Cc3535A9e549EE387A6E9C3F02F481B49), responsable de toutes les opérations entre les utilisateurs et les pools, notamment l’ajout et le retrait de liquidité, l’échange de jetons, etc.
La troisième partie concerne les contrats Path. Il existe actuellement huit types de contrats Path sur BEX. Chaque type correspond à une fonction spécifique. Selon le paramètre User Cmd transmis par l’utilisateur au contrat CrocSwapDex, ce dernier délègue via un proxy l’appel au contrat Path approprié pour exécuter la logique requise.
La logique principale du projet est divisée selon les fonctions des différents contrats Path :
-
BootPath : Fonctionnalités liées à la mise à jour du contrat
-
ColdPath : Logique de gestion non liée aux échanges, incluant l’initialisation des pools et la fonctionnalité de sur-collatéralisation
-
HotPath : Gère la logique la plus courante des échanges, soit l’échange simple étape d’un jeton
-
KnockoutPath : Déclenché lorsqu’un échange franchit un point prédéfini de frontière de liquidité ou de prix (appelé bump point), permettant de réévaluer ou ajuster la liquidité. Contrairement aux chemins d’échange normaux, le code traversant une frontière de liquidité est complexe et ne peut pas être entièrement inclus dans HotPath, d’où la nécessité d’un traitement séparé.
-
LongPath : Gère les ordres composites longs (Long-chain Compound Orders), généralement des transactions complexes constituées de plusieurs opérations simples sur une plateforme de trading décentralisée ou dans un pool de liquidité.
-
MicroPaths : Comprend des composants intermédiaires liés à des opérations atomiques individuelles, pouvant être invoqués dans le contexte d’une courbe de liquidité préchargée lors de l’exécution d’opérations composites complexes.
-
SafeModePath : Son objectif principal est, en cas d’état d’urgence du contrat DEX, de restreindre toutes les autres opérations et d’autoriser uniquement certaines actions de gestion spécifiques.
-
WarmPath : Contient la logique centrale des opérations des fournisseurs de liquidité : frapper de la liquidité ambiante (Mint ambient liquidity), frapper de la liquidité concentrée sur une plage définie (Mint concentrated range liquidity), brûler de la liquidité ambiante (Burn ambient liquidity), brûler de la liquidité concentrée (Burn concentrated range liquidity).
3.1 Ajout de liquidité
Cette section présente principalement deux logiques courantes : l’ajout de liquidité et l’échange de jetons. Lorsqu’un utilisateur ajoute de la liquidité, il appelle d’abord via l’interface ou un contrat la fonction userCmd du contrat CrocSwapDex, où callpath est un index sur 16 bits identifiant le contrat Path vers lequel la commande sera transférée via DELEGATECALL.
Ensuite, le contrat appelle la fonction callUserCmd du contrat ProxyCaller, qui délègue selon le proxyIdx au contrat Path correspondant, ici WarmPath. La fonction commitLP du contrat WarmPath entre alors dans la branche logique appropriée d’ajout de liquidité selon les paramètres transmis. Trois types d’ajout de liquidité sont disponibles : MINT_AMBIENT_LIQ_LP, MINT_AMBIENT_BASE_LP, MINT_AMBIENT_QUOTE_LP, représentant respectivement l’ajout direct d’une quantité donnée de liquidité, ou le calcul de la quantité à ajouter selon le jeton base ou quote du pool.
Enfin, la fonction mintAmbientLiq du contrat WarmPath est principalement chargée de frapper la liquidité. Elle appelle la fonction settleFlows du contrat SettleLayer pour frapper les jetons justificatifs de liquidité destinés à l’utilisateur.
La logique de retrait de liquidité étant similaire, elle ne sera pas détaillée ici.
3.2 Échange de jetons
Lorsqu’un utilisateur effectue un échange de jetons via BEX, il appelle d’abord la fonction multiSwap du contrat BeraCrocMultiSwap, qui procède étape par étape à l’échange via le contrat CrocSwapDex selon le chemin indiqué. Ensuite, la fonction caluserCmd du contrat CrocSwapDex est appelée pour entrer dans le contrat HotPath ou KnockoutPath correspondant et exécuter la logique d’échange. Ici, le contrat HotPath, le plus courant, est utilisé. HotPath appelle la fonction swapOverPool de MarketSequencer pour calculer la quantité de jetons à échanger. Enfin, le contrat HotPath appelle la fonction settleFlows du contrat SettleLayer pour transférer à l’utilisateur les jetons cibles obtenus après l’échange.
En résumé, comparé aux DEX traditionnels comme Uniswap V2, BEX présente les caractéristiques suivantes :
Gestion de l’état de la courbe (CurveState)
Snapshots de l’état de la courbe (Snapshotting CurveState) : Pour optimiser la consommation de gaz, BEX copie l’état actuel de la courbe (CurveState) depuis le stockage blockchain (EVM Storage) vers la mémoire, puis réécrit l’état modifié sur la blockchain après la transaction.
Les informations sauvegardées dans le snapshot incluent la racine de prix (priceRoot), les graines de liquidité (ambientSeeds) et la liquidité concentrée (concLiq_). Pour plus d’informations sur ces concepts, voir le livre blanc d’Ambient Finance (Crocswap) : https://crocswap-whitepaper.netlify.app/
Exécution des échanges (Swap Execution)
Exécution progressive des transactions : L’architecture de BEX permet d’exécuter les transactions par étapes, notamment pour les grandes transactions traversant plusieurs frontières de liquidité (comme les ticks dans Uniswap V3). À chaque passage d’une frontière, la liquidité et le prix doivent être réajustés. Calcul itératif : En parcourant chaque intervalle de liquidité (ou tick), le système consomme ou accumule progressivement la liquidité nécessaire jusqu’à compléter la transaction ou atteindre la limite de prix de l’utilisateur.
Structure bitmap : Similaire à Uniswap V3, Ambient DEX utilise un bitmap pour indiquer la présence de liquidité dans chaque plage de prix, permettant une recherche rapide du prochain intervalle disponible. Toutefois, comme les pools sur BEX utilisent actuellement uniquement la liquidité ambiante — c’est-à-dire que les fournisseurs de liquidité offrent de la liquidité globalement, sans ajout concentré sur une plage de prix spécifique — les opérations d’échange actuelles ne diffèrent guère de celles d’Uniswap V2.
4. PoL et Bend
Bend est un protocole de prêt non gardé sur la chaîne Bera, dont le cœur est de fournir des services de prêt de base à l’écosystème Berachain. Projet clé de l’écosystème Berachain, en tant que marché de prêt officiel, il s’intègre étroitement au mécanisme de consensus PoL.
Les emprunteurs peuvent emprunter des jetons HONEY en collatéralisant des cryptomonnaies (comme wBTC), et reçoivent simultanément une certaine quantité de jetons de gouvernance, contribuant ainsi à la distribution de BGT dans le cadre du consensus PoL. Quant aux fournisseurs de HONEY, ils apportent de la liquidité et perçoivent une part des intérêts générés par les prêts.
Les principaux participants de Bend sont au nombre de trois :
1. Les fournisseurs de liquidité en $HONEY.
2. Les emprunteurs qui collatéralisent des cryptomonnaies pour emprunter des jetons HONEY.
3. Les liquidateurs, chargés de garantir la solvabilité du protocole.
Voici l’architecture principale du projet :
Par analyse des contrats sur le réseau test, les fournisseurs de liquidité déposent des jetons HONEY via l’interface supply et reçoivent en retour des jetons AHONEY en proportion 1:1. Au fil du temps, le solde de leurs jetons AHONEY augmente avec les intérêts générés, contribuant ainsi à maintenir l’écosystème du pool de prêt et garantissant que les emprunteurs disposent toujours de fonds. Plus tard, les fournisseurs peuvent retirer leurs HONEY via l’interface withdraw, en échangeant 1:1 leurs jetons AHONEY contre des HONEY, réalisant ainsi un profit.
Les emprunteurs peuvent collatéraliser des actifs via l’interface borrow pour emprunter un montant de HONEY inférieur à la valeur de leur collatéral, et reçoivent en retour des vdHONEY, des jetons de dette. Comme les HONEY, les vdHONEY augmentent également au fil du temps, obligeant l’emprunteur à rembourser davantage de HONEY. Toutefois, sur la chaîne Bera, les emprunteurs reçoivent aussi une certaine quantité de jetons de gouvernance (BGT) lors de l’emprunt de HONEY, ce qui stimule leur motivation à emprunter, soutient l’écosystème du pool de prêt et contribue également au consensus PoL.
Dans Bend, toute personne peut devenir liquidateur. Lorsque le coefficient de santé d’un emprunteur descend en dessous de 1, cela signifie que la valeur de son collatéral ne suffit plus à couvrir sa dette. Un liquidateur peut alors déclencher une liquidation et recevoir 5 % de la valeur du collatéral comme récompense, incitant ainsi les liquidateurs à agir.
4.1 Ajout de liquidité
Lorsqu’un fournisseur de liquidité dépose des fonds, la fonction supply met d’abord à jour le cache des réserves et le taux d’intérêt, afin de maintenir la santé du système et disposer des données les plus récentes. Ensuite, elle vérifie si le jeton ATOKEN a atteint sa limite de frappe, évitant ainsi une surfrappe.
Si ces vérifications sont passées, des jetons ATOKEN sont frappés 1:1 pour le fournisseur. Lors d’un retrait, la fonction withdraw met également à jour le cache des réserves et le taux d’intérêt, puis calcule le solde actualisé d’ATOKEN selon les intérêts courants, permettant un retrait 1:1 du collatéral.
À noter : si le fournisseur a contracté un prêt, il ne peut retirer sa liquidité que si son facteur de santé est satisfaisant. Actuellement sur Berachain, seul le jeton HONEY peut être emprunté et générer des intérêts ; les autres collatéraux ne rapportent aucun intérêt par prêt.
4.2 Emprunt
Lorsqu’un emprunteur utilise Bend pour emprunter, il doit d’abord déposer suffisamment de collatéral via la fonction supply. Ensuite, il appelle la fonction borrow. Celle-ci met d’abord à jour le cache des réserves pour disposer des dernières informations, puis appelle validateBorrow pour vérifier la légalité de l’emprunt (plafond, valeur du collatéral, crédit utilisateur, etc.). Si la vérification réussit, un nombre correspondant de jetons de dette (vdHONEY) est frappé, permettant alors d’obtenir les HONEY.
Lors du remboursement, la fonction repay met également à jour le cache des réserves et le taux d’intérêt, puis calcule selon ces données le montant de HONEY à rembourser. Après remboursement réussi, le nombre correspondant de jetons vdHONEY est brûlé. L’emprunteur ne peut utiliser la fonction withdraw pour récupérer son collatéral que s’il a remboursé suffisamment de vdHONEY pour que la dette restante reste saine après retrait.
4.3 Liquidation
Lorsque la valeur du collatéral d’un emprunteur devient insuffisante, toute personne peut appeler la fonction liquidationCall pour effectuer une liquidation. Cette fonction met d’abord à jour les données du cache de dette, puis appelle validateLiquidationCall pour vérifier le facteur de santé de l’emprunteur et la disponibilité du collatéral. Si la valeur de la dette dépasse le seuil de liquidation, le facteur de santé devient trop bas. Si celui-ci est inférieur à 1, la liquidation peut être exécutée : les jetons de dette sont brûlés, et le collatéral est envoyé à l’adresse du fonds de réserve. Le liquidateur reçoit 5 % de la valeur du collatéral comme récompense, ce qui incite à effectuer les liquidations.
5. PoL et Berps
Berachain Berps est une plateforme de trading à effet de levier décentralisée permettant des contrats à terme perpétuels. La monnaie stable native de Berachain, $HONEY, sert de collatéral, de moyen de paiement et de dépôt pour toutes les transactions. Les utilisateurs peuvent générer des revenus en fournissant de la liquidité de trading via le coffre $bHONEY. Les déposants du coffre perçoivent les frais de transaction générés par Berps et agissent comme contrepartie aux positions des traders. De plus, le coffre de Berps peut également bénéficier des incitations PoL : les utilisateurs déposant des fonds dans le coffre reçoivent des $BGT.
Actuellement, Berps est disponible sur le réseau test et prend en charge les contrats perpétuels libellés en USDT pour quatre jetons : BTC, ETH, ATOM et TIA.
L’architecture de Berps est très similaire à celle des plateformes de perpétuels décentralisées existantes, avec les principaux contrats suivants :
● Entrypoint : Point d'entrée des utilisateurs pour les transactions (y compris les liquidations). Le contrat Entrypoint vérifie la validité des transactions lancées par l'utilisateur ; si la vérification réussit, il crée la transaction correspondante.
● FeesAccrued : Calcule et gère les frais d'emprunt
● FeesMarkets : Calcule et gère les frais associés à toutes les paires de trading
● Markets : Gère les paramètres et limites de toutes les paires de trading
● Orders : Gère les ordres soumis par les utilisateurs et stocke leurs fonds
● Settlement : Met à jour les changements d'état des transactions
● Vault : Agit comme contrepartie aux traders, fournissant la liquidité nécessaire. Les utilisateurs peuvent déposer des fonds dans le Vault pour percevoir les frais de la plateforme et des incitations en jetons PoL.
6. Conclusion
En résumé, Berachain est une blockchain L1 EVM équivalente construite sur Cosmos SDK, utilisant un mécanisme de consensus unique, Proof-of-Liquidity (PoL). Les utilisateurs fournissant de la liquidité à Berachain reçoivent des récompenses via le mécanisme PoL. Grâce à PoL, Berachain renforce la liquidité et la sécurité de la chaîne. Comparé à d'autres blockchains, Berachain dispose d'applications natives telles que BEX, Bend et Berps, offrant aux utilisateurs une gamme complète de services DeFi : échange de jetons, minage de liquidité, prêt et trading perpétuel. Couplé à PoL, cela positionne Berachain comme un acteur performant en matière de profondeur de marché et d'expérience utilisateur dans l'écosystème DeFi.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@Beosin_com
