Mantle Network : la seconde couche modulaire pour Ethereum

Mantle Network est une couche secondaire pour Ethereum (Layer 2 ou L2) : un réseau qui permet de traiter des transactions et d’exécuter des smart contracts rapidement, pour un faible coût. Comme plusieurs solutions de scalabilité pour Ethereum, Mantle Network est basé sur les rollups.

Mantle Network a la particularité d’être modulaire : les couches gérant les calculs et l’accessibilité aux données sont indépendantes. Ethereum gère le consensus, tandis que la disponibilité des données est assurée par une infrastructure nommée EigenLayer.

Les L2 visent à rendre Ethereum scalable, facile et peu coûteux à utiliser, sans sacrifier sa sécurité. Chaque solution est basée sur un compromis – le fameux trilemme des blockchains – entre scalabilité, sécurité et décentralisation. Mantle Network a une approche unique, que nous présentons dans cet article.

Cet article promotionnel vous est proposé en collaboration avec Mantle

Les concepts-clés pour comprendre Mantle 

Nous allons tout d’abord définir quelques concepts importants pour comprendre Mantle Network, et plus largement les layers 2 d’Ethereum. Ces réseaux secondaires permettent d’augmenter son débit, en traitant un grand nombre de transactions. Ils déchargent la chaîne principale (layer 1), car seul l’état résultant de l’ensemble des opérations y est finalisé.

Il existe différents types de L2. Ils peuvent ainsi être basés sur des sidechains, des chaînes Plasma, ou des rollups. Parmis toutes ces techniques, les sidechains/Plasma chains assurent le traitement des données et les calculs. Ce n’est pas le cas des solutions basées sur les rollups.

Les rollups sur Ethereum

Il existe deux types de rollups pour créer une infrastructure de couche secondaire pour Ethereum. Les Optimistic Rollups ont été privilégiés au départ, car les zkRollups n’étaient pas EVM-compatibles. Cela a récemment changé, notamment avec l’arrivée de Kakarot et de Scroll.

Dans les deux cas, les rollups servent à traiter de grandes quantités de transactions sur le L2 (batches). Les opérations restant à traiter sur le L1 (Ethereum) sont :

• Les dépôts et les retraits des fonds des utilisateurs sur L2 ;
• La vérification de la validité des opérations effectuées sur le L2.

Tout se déroule donc au sein d’un smart contract sur le L1. Les rollups sont donc accompagnés d’une preuve à divulgation nulle de connaissance (ZKP) permettant de valider ce qui se déroule sur le L2. C’est ici que réside la différence entre optimistic et ZK rollups.

À titre d’exemple, voici un tableau résumant les différences entre les deux types de rollups en termes de coûts, de période de verrouillage et de complexité.

Ce tableau est donné à titre indicatif, car les techniques progressent, et les solutions de scalabilité basées sur les rollups sont améliorées fréquemment. Pour comprendre et approfondir le sujet des zk-Rollups, veuillez vous référer à l’article de présentation de Scroll et de sa zkEVM.

Qu’est-ce qu’un optimistic rollup ?

Un Optimistic Rollup est un rollup ne nécessitant pas de preuve de validité pour être pris en compte par le Layer 1. En effet, les transactions sont validées hors-chaîne.

En revanche, un réseau de vérificateurs génère des preuves de fraude (fraud proofs) dans le cas où une transaction est invalide. L’adjectif “optimiste” provient donc du fait que le Layer 1 assume la validité du rollup.

Les Optimistic Rollups sont apparus sur Ethereum avec Optimism. Leur fonctionnement est le suivant :

• Tout d’abord, un module appelé le Séquenceur collecte les transactions des utilisateurs et va les traiter sur le Layer 2  ;
• Les données de transactions et la racine d’état du L2 sont ensuite envoyées au L1 ;
• Tous les nœuds du Layer 2 exécutent ces transactions et mettent alors à jour leur chaîne ;
• Enfin, les nœuds vérificateurs comparent leur propre racine d’état à celle qui est envoyée par le séquenceur au Layer 1.

Dans le cas où les racines d’état sont différentes, les nœuds vérificateurs génèrent une preuve de fraude. Ils exécutent les transactions sur le L2 mais pas sur le L1 : ainsi, la racine d’état résultante ne peut être falsifiée.

Si un Vérificateur challenge la validité d’un rollup, les transactions seront soumises au L1 pour confirmer leur invalidité. Le Séquenceur responsable est alors pénalisé : une partie de son enjeu (stake) est brûlé (slashed). Il devra ensuite recalculer les racines d’état correctement.

La disponibilité des données

La notion de disponibilité des données décrit, dans notre cas, la capacité des nœuds du L2 à accéder à l’historique des données de transaction. C’est nécessaire pour vérifier la validité de la transition d’état. Il existe plusieurs manières de stocker cet historique, on chain (sur le L1) et off chain (sur le L2).

La notion de confiance

Assurer la disponibilité des données de manière “trustless”, c’est-à-dire sans devoir faire confiance à une tierce partie, est un défi technique. Sur une blockchain classique, il faut posséder un nœud complet, qui stocke l’intégralité de l’historique des transactions du réseau. De cette façon, n’importe quel utilisateur peut vérifier qu’un participant suit bien les règles du protocole.

Les nœuds d’un L2 doivent aussi accéder aux données de bloc pour vérifier la validité des rollups, et générer d’éventuelles preuves de fraude. Sur Mantle, le Séquenceur publie sur le L1 (Ethereum) les données de transaction complètes, accompagnées d’une preuve cryptographique de la transition d’état (la racine de son arbre de Merkle). Chacun peut alors vérifier que ladite transition d’état du L1 est correcte, et challenger le séquenceur dans le cas contraire.

De manière générale, la disponibilité des données de blocs est primordiale pour assurer la scalabilité d’une blockchain. Dans le cas d’un L2, elle a également des implications en termes de sécurité et de résistance à la censure.

L’idée centrale de l’architecture de Mantle Network est d’utiliser une couche dédiée à la disponibilité des données de bloc. Elle s’appelle EigenLayer, un protocole de restaking. Nous reparlerons plus bas de cette infrastructure majeure.

Les bridges : relier Mantle Network à Ethereum

Les Bridges (ou ponts) permettent de déplacer des actifs entre Ethereum et un Layer 2. Il y a deux catégories de bridges : trusted ou trustless. Les trusted bridges sont opérés par une entité centrale : l’utilisateur lui confie ses actifs et opère sur le L2. Les trustless bridges sont des smart contracts, donc leur sécurité dépend de celle du L1.

Dans le cas de Mantle Network, un utilisateur possédant des ETH sur le L1 devra utiliser le Bridge pour les verrouiller sur le L2, et effectuer ses transactions.

Fonctionnement de Mantle Network

Dans le cas des Optimistic Rollups traditionnels, disponibilité des données et calculs sont tous deux gérées par Ethereum. Le L1 assure la disponibilité des données, sert de couche de règlement, et permet de vérifier les transactions du L2 afin de générer des preuves de fraude.

Les Optimistic Rollups bénéficient donc du même degré de sécurité qu’Ethereum. Bien qu’ils améliorent sa scalabilité, ils présentent des inconvénients. Tout d’abord, les frais seront importants, car les données de transaction sont envoyées sur Ethereum. Ensuite, les nœuds du L2 sont limités en termes de débit par les capacités d’Ethereum. Enfin, la finalisation des transactions sur le L1 est assez longue. Les utilisateurs doivent attendre une période de sûreté avant de pouvoir déverrouiller leurs fonds sur le L2.

Rollups modulaires

Mantle Network est un L2 modulaire. Ainsi, différentes couches de son infrastructure assurent exécution des transactions, consensus, règlement et disponibilité des données. En conséquence, confier chacune de ces tâches à un module spécialisé diminue les coûts globaux du rollup, et améliore ses performances.

La séparation des couches gérant le consensus et la disponibilité des données est une approche privilégiée pour résoudre le fameux trilemme des blockchains. En effet, cela améliore grandement le compromis entre décentralisation, scalabilité et sécurité. C’est le cas, par exemple, de Celestia.

Ce principe, appliqué aux rollups, est donc au cœur de l’architecture de Mantle Network :

• La séparation des ressources, couplée à la spécialisation de chaque couche de l’infrastructure, améliore grandement les performances du réseau ;
• Tous les utilisateurs du L2 bénéficient du même degré de sécurité que les nœuds complets du L1 ;
• Les nœuds réalisant le calcul des preuves déchargent les autres participants de la tâche de réexécution des transactions.

Sur Mantle, la couche qui gère la disponibilité des données est basée sur un protocole spécifique.

La disponibilité des données avec EigenLayer

EigenLayer est un protocole de restaking. Les stakers d’Ethereum sont les utilisateurs ayant mis en jeu des ETH pour participer à sa sécurisation. Avec Eigen, il peuvent « restaker » leurs ETH, et devenir ainsi validateurs pour n’importe quel service logiciel bâti sur Ethereum. Cela inclut tous les modules de l’écosystème : protocoles de consensus, machines virtuelles, oracles, environnements d’exécution sécurisés, multisigs, et donc… disponibilité des données (data availability ou DA).

Les validateurs d’Ethereum ont ainsi la possibilité de fournir des services de disponibilité des données, pour tous les L2 basés sur des rollups. Leurs ethers « stakés une deuxième fois » servent alors de collatéral; il est même possible d’ajouter des conditions de performance pour récompenser les validateurs. Les mécanismes d’incitation économique d’EigenLayer leur donnent droit à des intérêts.

La solution de disponibilité des données d’EigenLayer s’appelle EigenDA. Mantle Network utilise cette implémentation, qui permet aux nœuds de fournir leurs services. Les nœuds assurant la disponibilité des données de Mantle participent également à son modèle économique, grâce au staking du jeton MNT que nous présenterons plus bas dans cet article. EigenDA présente trois caractéristiques :

• La séparation des couches de consensus et de disponibilité des données ;
• Les échanges de données entre les participants du réseau passent par un canal monodiffusion, améliorant grandement la transmission et le stockage des données ;
• Avec un taux d’effacement (erasure rate) fixé, les acteurs du réseau peuvent utiliser des données de bloc incomplètes du L1 et du L2 pour reconstruire les données de bloc complètes.

EigenDA est donc la solution sur laquelle s’appuie Mantle Network pour fournir un haut débit à ses utilisateurs.

Le séquenceur décentralisé de Mantle Network

Le Séquenceur est le module qui produit les optimistic rollups. Les L2 traditionnels utilisent un séquenceur centralisé, généralement maintenu par l’équipe de développement. C’est pratique du point du vue de l’utilisateur, car ce dernier reçoit instantanément une pré-confirmation de sa transaction (soft confirmation). S’il fait confiance au séquenceur, il sait que sa transaction sera incluse dans un batch, puis finalisée sur le L1.

Cependant, le modèle du séquenceur unique pose un problème de sécurité. Le séquenceur détient en effet un accès privilégié en écriture sur la chaîne L2, et lui seul peut transmettre les batches de transactions au L1. Il s’agit donc un point unique de défaillance, si seule la core team gérant le L2 peut l’opérer.

Architecture

Le séquenceur de Mantle Network sera décentralisé. N’importe quel utilisateur pourra donc devenir producteur de blocs pour le L2. Les nœuds séquenceurs seront récompensés en jeton MNT. Ils bénéficieront également des récompenses MEV (maximum extractable value).

Un mécanisme d’élection sur le L1 détermine le nœud leader qui produit les blocs pour une période donnée (sur l’ensemble des nœuds séquenceurs). En d’autres termes, c’est le leader qui crée le rollup des transactions du L2, et diffuse le nouveau bloc au réseau des séquenceurs.

Plusieurs autres séquenceurs succèdent au leader (Sequencer Followers). Ils reçoivent le nouveau bloc de la part du leader pour la période courante, et exécutent les transactions qu’il contient.

Il existe aussi un autre rôle pour les nœuds du L2 : le Planificateur. Un seul nœud assure ce rôle à un moment donné. C’est le planificateur qui élit un leader parmi l’ensemble des séquenceurs, d’après les règles fixées. Il est également validateur des blocs produits par les séquenceurs, et détermine leur finalité. Si le leader ne soumet pas de bloc au planificateur dans le délai imparti, ce dernier en choisit un nouveau parmi les followers.

Les preuves de fraude (Fraud Proofs) de Mantle Network

Dans le cas des zkRollups, les blocs du L2 sont accompagnés d’une preuve de validité, qui permet d’assurer la correcte exécution du code et des transactions du rollup.

À l’inverse, les Optimistic Rollups utilisent des preuves de fraude. Elles permettent de signaler des séquences de calcul ou des transactions invalides. Les blocs du L2 sont donc considérés valides par le L1, jusqu’à preuve du contraire ! Dans ce modèle, l’implémentation de ces preuves est critique.

Preuves de fraude « classiques »

Avec le modèle basique, le smart contract qui règle les litiges (On-chain Verifier) va exécuter toutes les instructions du rollup pour vérifier leur validité. Cependant, il ne peut le faire qu’en utilisant un langage de bas niveau (MIPS ou WASM). Il faut donc que le client EVM recompile les preuves de fraudes dans ce langage, afin que vérificateur on-chain les interprète. On parle de « low-level transpilation » – transpilation de bas niveau.

Cela pose un problème de confiance. En effet, le vérificateur n’a aucune garantie que les preuves de fraude proviennent d’un client EVM conforme : il doit les accepter « à l’aveugle ».

Les preuves de fraude améliorées de Mantle

L’idée est d’évaluer les preuves de fraude en utilisant directement les instructions de l’EVM. C’est le modèle utilisé par Mantle Network, à l’instar de Specular. Les preuves sont compilées et vérifiées via des instructions conformes à l’EVM. Cela confère deux avantages :

• Tous les logiciels client Ethereum peuvent interagir sans permission avec un système de preuve commun ;
• De fait, cela minimise la confiance nécessaire entre les vérificateurs, les logiciels clients et les compilateurs.

Mantle Network est ainsi un « trust-minimized optimistic rollup » :

La conception des rollups de façon « EVM-native » est supérieure en termes de sécurité et de confiance. L’exécution des instructions d’un rollup, et la résolution des litiges, s’opèrent sur le même niveau d’abstraction. Le vérificateur on-chain est agnostique en termes de logiciel client Ethereum. Cela renforce donc aussi l’auditabilité des optimistic rollups.

Les différentes étapes d’une transaction sur Mantle Network

Nous allons dans ce chapitre illustrer le fonctionnement de Mantle Network en détaillant le cycle de vie d’une transaction.

Initiation

Au départ, un utilisateur connecté au L2 de Mantle Network via son wallet initie une transaction (ou une tâche quelconque). Il utilise à cette fin une application décentralisée, intégrée à Mantle Network (via le SDK – kit de développement). Une requête de transaction basique contiendra donc l’adresse de réception des fonds et le montant transféré.

Une fois les frais de l’opération pris en compte, la requête est signée à l’aide de la clé privée de l’utilisateur. Elle est alors envoyée vers un Séquenceur du Mantle Network.

Prise en charge

Premièrement, la machine virtuelle d’Ethereum (EVM) déployée sur ces nœuds vérifie la validité de la requête. Il s’agit de s’assurer que les fonds sont disponibles, les frais corrects, et les instructions valides. L’état local du L2 est mis à jour en y incluant la transaction avant qu’elle ne soit traitée. Jusqu’ici, ce processus est très rapide. La confirmation est donc instantanée, en termes d’expérience utilisateur.

Deuxièmement, les blocs du L2 sont regroupés en batches, qui sont envoyés sur Ethereum pour y être finalisés.

Troisièmement, un autre type de nœud vérifie que les données de bloc sont correctes : les nœuds MPC. MPC signifie « Multi-Party Computation » ou calcul multipartite. Nous détaillerons le rôle de ces nœuds dans le chapitre décrivant l’architecture de Mantle Network : ils vérifient les racines d’état des blocs du L2 transmises par le Séquenceur, puis signent les données de bloc.

Stockage

Le Séquenceur transmet ensuite les données de bloc, une fois signées, sur Ethereum. Sur le L2, les vérificateurs vont rendre ces données accessibles aux autres utilisateurs et aux dApps. Sur le L1, les données sont enregistrées on-chain, une fois approuvées par le mécanisme de consensus d’Ethereum.

Les nœuds responsables de leur disponibilité (DA Nodes) vont alors les synchroniser, et garantir leur accessibilité à tout instant. En échange, ils sont récompensés via le jeton MNT.

Architecture de Mantle Network

Le réseau Mantle est composé de différents modules, dont le maintien est assuré par 4 acteurs. Ils ont chacun un rôle précis. Ces nœuds sont incités économiquement à assurer le bon fonctionnement et la sécurité du système.

Les différents acteurs de Mantle Network

Il s’agit des Séquenceurs, des Nœuds MPC, des Vérificateurs de rollups (Rollup Verifiers) et des Nœuds DA (Data Availability Nodes).

Les Séquenceurs

Les Séquenceurs reçoivent les transactions des utilisateurs et les enregistrent en temps réel. Ils vont également produire les blocs du L2 lorsqu’ils sont désignés leader. Ils agrègent les transactions dans un rollup, qu’ils accompagnent de sa racine d’état.

Les Séquenceurs reçoivent également les blocs signés de la part des nœuds MPC. Ils diffusent ensuite les données correspondantes à travers le L2 et le L1.

Il est à noter qu’au lancement du Mainnet de Mantle Network, l’équipe opérera son propre séquenceur. Les Séquenceur sera décentralisé au fur et à mesure de l’avancement de la feuille de route.

Les nœuds MPC (calcul multipartite)

L’implémentation de ces nœud découle de la volonté de minimiser les risques de confiance sur le L2. En effet, les Optimistic Rollups « classiques » nécessitent une longue période de sûreté avant qu’un utilisateur ne puisse déverrouiller ses fonds. Les nœuds MPC permettent de régler ce problème.

Les schémas de signature à seuil

Le calcul multipartite (Multi-Party Computation ou MPC) est une branche de la cryptographie où des calculs (et leur évaluation) sont fragmentés entre plusieurs parties, sans que ces dernières n’aient à révéler leurs données privées.

Dans le cas de Mantle Network, cela permet d’utiliser un schéma de signature distribué afin de vérifier les données de bloc.

Le diagramme ci-dessus montre comment les multiples nœuds MPC vérifient et signent les données de bloc issues du Séquenceur. Le schéma de signature comporte trois phases :

• Génération de la clé privée : chaque nœud MPC exécute la fonction de génération. Il dérive ensuite la clé publique associée. Bien entendu, il ne doit en aucun cas dévoiler sa clé privée.
• Signature : la fonction de signature reçoit le message à signer comme entrée publique. En sortie, elle génère une signature via la clé privée.
• Vérification : l’algorithme vérifie la validité de la signature grâce à la clé publique.

Ce schéma de signature est distribué entre les nœuds MPC : on parle de schéma de signature à seuil (Threshold Signature Scheme ou TSS). Ainsi, chaque participant peut générer une signature valide, et vérifier les données de la signature distribuée. Il faut cependant qu’une proportion suffisante des acteurs soient honnêtes.

Le gros avantage des TSS est qu’elles éliminent le point unique de défaillance qu’est la clé privée. Avec les TSS, chaque nœud MPC ne possède qu’un fragment de la clé. De plus, c’est un processus beaucoup plus rapide pour vérifier la validité des transactions effectuées sur le L2.

Les nœuds MPC doivent mettre sous séquestre (stake) des jetons MNT afin de générer les signatures. Ils sont récompensés pour cela, mais souffrent de pénalités s’ils se comportent mal ou s’avèrent défaillants.

Architecture du réseau des nœuds MPC

Le schéma ci-dessus décrit les trois composants du réseau des nœuds MPC implémentant le TSS :

• MPC Core : il déploie l’implémentation du TSS utilisé par Mantle (https://github.com/bnb-chain/tss-lib) ;
• MPC Manager : c’est ce module qui gère les nœuds MPC et assigne leurs tâches ;
• MPC Nodes : un nœud MPC génère sa propre clé privée, et communique en pair à pair avec les autres nœuds. Ils produisent conjointement une signature grâce à ladite clé privée.

Tous les nœuds MPC sont complets et connectés en permanence au Séquenceur. Ils doivent donc exécuter toutes les transactions pour arriver à une racine d’état correcte.

Le résultat d’exécution

Le résultat d’exécution fait référence aux racines d’état des rollups signées par les nœuds MPC. La racine d’état, si elle est valide, repasse par le MPC Manager, puis par le Batch Submitter, avant d’arriver sur le L1.

Le résultat d’exécution est ainsi utilisé pour vérifier toutes les données provenant du MPC Manager.

Élection des nœuds MPC

Le processus d’élection comporte six phases. Afin de devenir nœud MPC, il faut au préalable placer sous séquestre des jetons MNT.

• Staking de jetons MNT sur le mainnet d’Ethereum ;
• Verrouillage des MNT sur le L1 – le smart contract enregistre le montant du stake ;
• Élection des nœuds MPC à travers la gouvernance de Mantle (le cluster) ;
• Génération de la clé privée hors-ligne, et dérivation de la clé publique du cluster ;
• Diffusion de la clé publique sur le L1 ;
• Confirmation lorsque tous les nœuds MPC ont envoyé la clé publique au L1.

Pénalisation des nœuds MPC (slashing)

Le système détecte les mauvais comportements (signature malicieuse ou mauvaise connectivité/downtime). En conséquence, le nœud MPC incriminé est pénalisé, via le mécanisme du slashing (destruction du stake).

Il faut prémunir le système des temps d’arrêts trop prolongés de la part des nœuds MPC. Le MPC Manager enregistre donc les absences : si elles se répètent, tout membre du cluster peut demander à brûler le stake du nœud MPC absent. La proposition doit être signée par la majorité (en stake) des nœuds du cluster pour devenir effective.

En cas de signature malicieuse, les nœuds honnêtes dénoncent le fraudeur au MPC Manager. Ce dernier émet alors une proposition de sanction : slashing et exclusion définitive du cluster. De la même façon, elle doit être signée par la majorité des nœuds du cluster MPC.

Les Vérificateurs de rollups

Les Vérificateurs ont 4 tâches à gérer :

• Synchroniser les données des rollups issues du Séquenceur ;
• Vérifier les racines d’état que le Séquenceur diffuse sur le L2 ;
• Forger des preuves de fraude dans le cas où les données d’état sont invalides ;
• Diffuser les données des rollups aux utilisateurs.

Les DA (data availability) Nodes

Ce sont les fameux nœuds assurant la disponibilité des données grâce à EigenDA. Ils possèdent les données de transaction complètes de Mantle Network. Afin de garantir leur accessibilité, ils signent ces données via le schéma Boneh–Lynn–Shacham (BLS).

Au niveau de l’incitation économique, ils profitent des frais collectés sur le L2 en MNT. Voici comment est articulé EigenDA :

Les Opérateurs

Ce sont les fournisseurs de services d’EigenDA. Afin d’opérer un nœud DA, il faut placer (restake) des ETH en collatéral. Ils s’engagent via leur signature numérique, doivent déployer un nœud et y stocker les données pour une période prédéfinie. Ils diffusent ensuite ces données à la demande; les Opérateurs sont récompensés au prorata de leur stake.

Les Disperseurs

Les Disperseurs sont les utilisateurs du service de disponibilité des données, et paient pour cela. Ils encodent les données pour une période temporelle fixée et les donnent aux opérateurs d’EigenDA. Les frais sont dépendants de la période de disponibilité.

Ils agrègent ensuite les signatures des opérateurs, puis postent une attestation de la disponibilité des données sur la blockchain.

Les Challengers

Les Challengers jouent un rôle important. Premièrement, ils surveillent les opérations qui ne sont pas vérifiées sur le L1 : dans le cas d’une défaillance, le problème est réglé on-chain, et le fautif est pénalisé (slashing).

Les Challengers suivent un protocole très intéressant nommé Proof-of-Custody. Ce protocole permet de solutionner le problème du « validateur fainéant ». En effet, un opérateur pourrait prétendre que ses données sont disponibles, sans que ce soit le cas. Il économiserait ainsi des ressources, et génèrerait plus de profit. La technique du PoC est ingénieuse : il s’agit d’insérer des données « piégées » de temps à autre. Si l’opérateur ne tient pas ses obligations, il passera à côté des données piégées, et sera lourdement pénalisé.

Les smart contracts d’EigenDA

Plusieurs smart contracts sont chargés d’assurer les tâches suivantes :

• Vérifier la disponibilité des données. Le protocole requiert un minimum de stake et de signatures pour les opérateurs.
• Implémenter la Proof-of-Custody et permettre aux challengers de diffuser des données on-chain ;
• Vérifier la validité des litiges initiés par les Challengers, et pénaliser le nœud fautif le cas échéant.

Stockage des données

Tout d’abord, les morceaux de données sont encodés par les Disperseurs. Ils génèrent aussi des preuves, permettant aux opérateurs de vérifier que le fragment est correct. Ensuite, les données sont dispersées vers les opérateurs. Enfin, vient la phase de vérification. Si les données sont correctes, les opérateurs les stockent, puis génèrent une attestation pour la période temporelle donnée. Cette attestation est signée et renvoyée aux Disperseurs. Lorsque les Disperseurs ont suffisamment de signatures pour les données, ils en publient l’agrégat sur le L1.

Les interactions entre les nœuds de Mantle Network

Les Séquenceurs et les Vérificateurs interagissent en permanence pour maintenir le système. Théoriquement, un seul vérificateur de rollup honnête, pouvant valider l’intégralité de la chaîne et diffuser les données de bloc aux autres participants, suffit à assurer la sécurité du réseau.

Les Vérificateurs ont un intérêt économique à participer : ils sont récompensés lorsqu’ils produisent des preuves de fraude valides. De plus, maintenir un nœud Ethereum complet confère de nombreux avantages.

Les frais de transaction

Sur Mantle Network, ils sont composés des frais d’exécution sur le L2 et des frais d’Ethereum, dits « frais de données« .

Les frais sur le L2 (Mantle Network)

Les frais d’exécution d’une transaction sur Mantle Network sont calculés de la même façon que sur Ethereum. Il s’agit de la quantité de gas nécessaire à la transaction multipliée par le prix du gas.

La quantité de gas nécessaire est plus ou moins la même que sur Ethereum, grâce à la compatibilité EVM de Mantle. En revanche, les prix du gas sont drastiquement plus faibles, ce qui fait tout l’intérêt d’un layer 2.

Les frais sur le L1 (Ethereum)

En attendant le déploiement d’EigenDA, les frais de données du L1 représentent la plus grosse part des coûts totaux d’utilisation. Les données nécessaires au déploiement d’un nœud Mantle sont stockées sur Ethereum. Ainsi, la publication des transactions du L2 sur Ethereum est chère. Les frais dépendent à la fois :

• Du prix du gas ;
• De la quantité de gas nécessaire pour publier la transaction. Elle est proportionnelle à sa taille.
• D’un surplus de gas fixe (2100 actuellement) ;
• D’un surplus de gas dynamique (d’un facteur 1 actuellement).

Rassurez-vous, Mantle est pour l’instant en testnet, et ces frais disparaîtront lorsqu’EigenDA sera déployé. En attendant, il n’est pas possible de fixer de limite pour les frais du L1. Le prix du gas est automatiquement mis à jour, ce qui peut faire varier les frais du L1 de plus ou moins 25% en cas de volatilité extrême.

Sur le L2, c’est le logiciel client de l’utilisateur (son wallet) qui va estimer le coût de la transaction. Ensuite, le Séquenceur calcule les frais nécessaires en fonction du prix du gas. Ces frais sont déduits du compte de l’utilisateur, et le Séquenceur envoie la transaction sur le L1.

Mantle n’intègre pas l’EIP-1559 (le marché des frais d’Ethereum). Il est donc déconseillé d’envoyer des transactions EIP-1559 via Mantle pour éviter les erreurs d’estimation du gas.

Les frais collectés par Mantle en MNT seront brûlés en fonction de la gouvernance du protocole.

La gouvernance de Mantle Network

La gouvernance de Mantle Network, à travers son jeton, le MNT, est encore en cours de structuration. Les tokenomics du MNT sont notamment sujettes à discussion.

Les point-clés

La gouvernance s’article autour de plusieurs acteurs et processus.

Les détenteurs de jetons MNT peuvent déterminer l’orientation stratégique de Mantle. Cela concerne, par exemple :

• Le lancement de nouveaux produits ;
• La modification des tokenomics du MNT ;
• L’allocation des postes de dépense et du budget ;
• Des actions correctives ;
• La structuration organisationnelle de Mantle ;
• Les règles du Comité ;
• Les choix techniques ;
• La modification des paramètres de gouvernance.

Les token holders ont donc autorité et peuvent participer activement à de nombreux aspects du projet.

La DAO (organisation autonome décentralisée) de Mantle est flexible. Elle peut être modifiée en fonction des propositions et de son développement.

Les propositions sont soumises sous l’étiquette MIP – Mantle Improvement Proposal. Les MIP et leurs mécanismes d’approbation sont formalisés auprès de la communauté des détenteurs de jetons.

Une période de révision et de feedback permet de jauger du sentiment général vis-à-vis de la proposition. Elle sera ensuite éventuellement modifiée puis soumise au vote.

En cas d’approbation, la proposition est implémentée sous forme de code, et déployée off-chain ou on-chain.

Le jeton MNT

Le MNT est à la fois un jeton de gouvernance et un jeton utilitaire. Il confère à ses détenteurs des droit de vote et des fonctionnalités pratiques.

Dans le processeur de gouvernance, chaque jeton MNT présente le même droit de vote. Le poids d’un vote est donc pondéré par le stake en MNT du votant.

Quant à son aspect utilitaire, le MNT est tout d’abord requis pour payer les frais d’utilisation de Mantle Network. De plus, il sert de collatéral pour les nœuds Mantle. Cela incite ainsi ses détenteurs à devenir acteurs du réseau, et donc à améliorer sa décentralisation et sa sécurité.

Le MNT est un jeton ERC-20 comme ses homologues pour différents L2, tels Arbitrum ou Optimism.

Les tokenomics du MNT

Tous les jetons MNT de la Trésorerie sont soumis à la gouvernance de Mantle. Les processus de budgétisation, d’appel aux capitaux et de distribution des MNT sont stricts. Pour l’instant, les postes de dépense suivants sont considérés :

• Adoption : l’adoption utilisateur de Mantle sera favorisée par diverses stratégies. Il peut s’agir de trophées, de quêtes ou d’autres programmes incitatifs. Les métriques ciblées sont par, exemple, le nombre d’utilisateurs actifs au quotidien ou la TVL (total value locked) au sein du réseau.
• Partenariats : au niveau technologique, il est important d’inciter les dApps, les fournisseurs d’infrastructures et les développeurs de technologies rollups à contribuer à la croissance de Mantle. L’équipe est ouverte à la collaboration.
• Core team et conseillers : il faut bien évidemment rémunérer l’équipe des contributeurs principaux. Ce budget est également voté en toute transparence.
• Opportunités diverses : toutes les opportunités qui pourraient se présenter – acquisitions, échange de jetons, vente de jetons de la Trésorerie, etc. Tout est examiné au cas par cas en tenant compte des objectifs long termes de l’écosystème Mantle.

À titre d’exemple, un vote est en cours quant aux allocations pour la première année de lancement.

Le processus de délégation des jetons MNT

Afin de voter, les détenteurs de MNT doivent déléguer leur jetons à une adresse donnée. Il peut s’agir de l’adresse du détenteur, mais elle est unique.

La délégation des jetons n’implique aucun verrouillage, et il est toujours possible de les transférer. Les jetons délégués à une adresse compromise, volée ou incorrecte ne sont pas perdus. Le cas échéant, le détenteur des jetons pourra les déléguer à une autre adresse.

Les gros détenteurs de MNT sont incités à rendre leur profil public. De même, ils s’engagent à voter dans l’intérêt des utilisateurs de Mantle et des holders. Enfin, les votes doivent être motivés par une expertise ou un intérêt, et les raisons du vote doivent être publiées sur le forum.

Cadre et processus de la gouvernance de Mantle Network

La gouvernance de Mantle s’articule autour de plusieurs paramètres :

• Le ratio vote/jeton est pour le moment simplement 1 MNT pour 1 vote; cependant, la communauté peut tout à fait proposer des systèmes pondérés à l’avenir.
• Un quorum est requis afin de ne pas spammer la communauté de propositions.
• Les fonds de la Trésorerie sont gérés par une implémentation de Gnosis Safe. En effet, cette infrastructure de multisig est particulièrement solide, testée et éprouvée.

La gouvernance de Mantle Network s’effectue off-chain. Tout d’abord, les membres de la Core Team ou de la communauté soumettent le fruit de leurs discussions. Ces dernières doivent être suffisamment pertinentes pour être introduites à la communauté via le forum :

https://forum.mantle.xyz/

Si la discussion génère suffisamment d’intérêt et de sentiment positif, elle pourra être formalisée en proposition (MIP). Ensuite, elle devra passer l’épreuve du vote des détenteurs de MNT. Dans le cas d’une approbation, les membres de la Core Team veilleront à l’implémenter.

Ce processus de gouvernance est dit hors-chaîne, car le résultat d’un vote n’implique pas de mise à jour automatique du code. Ce n’est pas le cas, par exemple, du mécanisme de gouvernance d’une blockchain comme Bitcoin.

À l’instar de nombreuses DAO sur Ethereum, la gouvernance de Mantle s’effectue via Gnosis Snapshot :

https://snapshot.org/#/bitdao.eth

Mantle Network en pratique

Mantle est pour l’instant accessible sur le testnet d’Ethereum Goerli. Il faut générer quelques gETH du testnet, puis des MNT via le faucet. Si l’on souhaite déployer un nœud, il y a 3 possibilités.

Déployer un nœud Mantle

Tout d’abord, commençons par un nœud Vérificateur (Rollup Verifier). La configuration requise est la suivante :

• CPU – 4 cœurs +
• RAM – 16 Go
• Disque – 100 Go + en SSD

Après s’être procuré la dernière version de Mantle (une version légèrement modifiée de Geth), il faut déployer le nœud via Docker. Ensuite, télécharger et compiler le script gérant le transport des données (DTL).

Le cas des nœuds MPC/TSS est particulier. Il faut en effet détenir un stake minimum d’un million de MNT et être approuvé par la Core Team. Les spécifications de tels nœuds sont basiques, puisqu’il s’agit de stockage (500 Go d’espace, 4 Go de RAM).

Quant aux nœuds DA, il faut privilégier la bande-passante. Voici la configuration requise pour stocker et diffuser les données :

• Un minimum de 10 Mo/sec en téléchargement
• CPU – 4 cœurs +
• 1 To en SSD
• 8 Go de RAM

Toutes les instructions et les outils relatifs au déploiement des nœuds se trouvent dans la documentation de Mantle.

Ressources et bibliographie

Pour aller plus loin, voici tous les liens et les ressources utiles pour comprendre Mantle Network et les Optimistic Rollups en profondeur.

Mantle Network

• Site officiel
• Twitter
• Telegram
• Discord
• GitHub
• Blog
• Documentation
• Bridge (Testnet)

Optimistic Rollups

• An Incomplete Guide to Rollups – Vitalik Buterin
• An Introduction to Optimism’s Optimistic Rollup – Kyle Charbonnet
• Towards Secure, Trust-minimized Optimistic Rollups – Specular
• EigenLayer – Site officiel
• EigenLayer – Documentation
• EigenLayer – The Restaking Collective (whitepaper)
• Trust-minimized Optimistic Rollups – Specular
• Proofs of Custody – Dankrad Feist
• An overview of Multi-Signature and Multi-Party Computation – Itai Turbahn
• Securing Multi-party Crypto Wallets – Raouf Rokhjavan