Le bridge Namada-Ethereum

Cet article vise à aborder la conception du bridge Namada-Ethereum, en commençant par sa teneur ainsi que les motivations, suivi de la manière dont le bridge fonctionne et par l’architecture des smart contracts.

La blockchain Namada vise à fournir un environnement unifié de confidentialité pour autant d’actifs que possible. En conséquence, l’inter-opérabilité est un composant essentiel pour Namada. En plus de la mise en œuvre du protocole IBC, Namada disposera d’un bridge intégré vers Ethereum.

Dans cet article, nous découvrirons la conception et les fonctionnalités de ce bridge. Nous diviserons la conception en trois parties. Dans la première partie, nous expliquerons pourquoi la décision de construire un bridge dédié et comment s’articule la conception de base du bridge. Dans la deuxième partie, nous donnerons les détails pour le relais des transferts bi-directionnels d’actifs d’Ethereum à Namada. Dans la troisième partie, nous aborderons l’architecture des smart contracts.

Intégration directe dans Namada

Le bridge Ethereum est directement intégré dans Namada plutôt que d’être un protocole autonome. Les validateurs de Namada exécutent ce bridge en tant que partie intégrante du coeur protocolaire de Namada. Pour le transfert d’actifs vers Namada, les validateurs agissent également en tant que “relayers” ; aucun autre acteur n’est nécessaire. Cependant, pour le transfert d’actifs vers Ethereum, des acteurs tiers (également comme relayers) seront impliqués, mais ils ne sont pas responsables de la validation ou de la sécurisation du bridge.

Cela signifie que la pérennité et la sécurité du bridge Ethereum sont directement liées à Namada dans son ensemble. En général, lors du transfert d’actifs via des bridges vers d’autres blockchains, les utilisateurs doivent faire confiance à la fois aux validateurs du bridge ainsi qu’aux validateurs de la blockchain de destination. Comme les utilisateurs doivent de toute façon faire confiance aux validateurs de Namada pour utiliser Namada, l’intégration du bridge n’ajoute aucune menace de sécurité supplémentaire. Il existe d’autres conceptions de bridge compatibles avec IBC telles que celles de Gravity et Axelar, et Namada peut également se connecter à ces bridges et les prendre en charge, mais ils nécessitent que les utilisateurs acceptent des conditions de sécurité supplémentaires (ainsi qu’une certaine latence).

Les validateurs de Namada exécuteront des full nodes Ethereum et surveilleront les événements émis par les smart contracts du bridge déployés sur Ethereum. Les événements des smart contracts sont déclenchés par diverses transactions telles que le transfert de tokens de part et d’autre du bridge, ainsi que certaines opérations dites administratives. Les validateurs de Namada devront attendre que la “transaction déclenchante” soit finalisée notamment, puis partager avec les autres validateurs le fait qu’ils ont vu un événement spécifique émis depuis Ethereum.

Lors du vote sur un nouveau bloc Namada, les validateurs doivent inclure une “liste signée” des nouveaux événements qu’ils ont pu observés à travers leurs votes. Lorsqu’une majorité de 2/3 des validateurs ont voté sur un événement particulier, il est considéré comme “vrai” et la blockchain de Namada peut agir en conséquence. Un validateur ne devrait voter que sur des événements qui ne sont pas susceptibles d’être annulés (dans le sens de la “proof of work” d’Ethereum 1) ou qui sont finalisés (dans le sens de la “proof of stake” d’Ethereum 2).

Dans le contexte d’Ethereum 2 (à l’heure actuelle), la finalité est déterminée lorsque 2/3 du pouvoir de participation ont voté sur un événement “deux fois”, et ce, dans des epochs distinctes. Plus précisément, le premier bloc de chaque epoch peut être finalisé lorsqu’il a été voté dans deux paires distinctes (mais à la fois liée). La première paire permet au bloc d’être “justifié”, et la deuxième paire permet de la finaliser. Ainsi, la finalité intervient plus tard que dans le cas de Namada.

Les événements ont peu de chances d’être annulés si le bloc contient suffisamment de descendants, appelés “confirmations”. Le nombre de confirmations nécessaire pour considérer un événement comme “final” est défini au lancement dans Namada, mais peut être modifié via la gouvernance.

Il est important de noter qu’un validateur peut soumettre un “fake event”, mais il ne recevra pas suffisamment de votes d’appui pour être pris en compte, sauf si la sécurité globale de Namada a été compromise. Si les validateurs de Namada souhaitaient vérifier l’authenticité des événements, cela nécessiterait de fournir des preuves “light client” attestant de l’inclusion d’une transaction dans Ethereum qui a engendré un événement donné. Cela nécessiterait à son tour que les validateurs de Namada exécutent des “light clients Ethereum” pour vérifier de telles preuves. Autoriser les “fake events” signifie que les validateurs de Namada n’ont pas besoin d’exécuter des “light clients Ethereum” pour vérifier l’authenticité des événements. Cela simplifie considérablement le bridge et n’affecte pas de manière substantielle nos conditions de sécurité (car 2/3 du pouvoir de vote pourrait de toute façon signer des blocs arbitraires).

Transférer des actifs vers Namada

Étant donné que la blockchain Namada agit en tant qu’oracle pour les contrats Ethereum, le processus de transfert d’actifs d’Ethereum à Namada est très fluide pour les utilisateurs. Il suffit de soumettre la transaction aux contrats du bridge pour qu’un événement soit émis. Cet événement sera vu et voté par les validateurs de Namada. Une fois qu’il atteint le quorum nécessaire, l’émission d’actifs vers une adresse Namada se fera automatiquement et sans frais. Le paiement des frais de gaz sur Ethereum est suffisant pour prévenir toute attaque par déni de service.

Transférer des actifs vers Ethereum

Le transfert d’actifs vers Ethereum, depuis Namada, n’est évidemment pas aussi simple que l’inverse, car Ethereum n’exécute pas de full nodes Namada. Cela signifie que les transactions sur Namada qui initient un transfert vers Ethereum doivent être relayées vers le smart contract pertinent.

Cela présente de nombreux défis :

• Une transaction Ethereum doit être élaborée.
• Quelqu’un doit soumettre cette transaction.
• Quelqu’un doit payer les frais de gaz.
• Il n’est pas efficient de soumettre des transactions individuellement, le regroupement est nécessaire.

Pour résoudre ces problèmes, Namada conservera un pool pour le bridge Ethereum afin de régir les demandes de transfert d’actifs vers Ethereum. Cette pool doit être considéré comme un “mempool”. Lorsqu’un utilisateur Namada ajoute une demande de transfert à cette pool, il peut choisir de payer une certaine quantité de NAM (ou un autre actif figurant sur la white list) en tant que frais. Ces frais sont gérés par Namada.

N’importe qui peut choisir de relayer un sous-ensemble de demandes de transfert dans la pool à tout moment. La pool du bridge Ethereum est organisé comme un arbre de Merkle, et la dernière “root” est signée par les validateurs. Relayer des demandes de transfert implique de soumettre les transferts au smart contract Ethereum, avec une preuve de Merkle des transferts et une “root” signée par un quorum de validateurs Namada.

Une telle transaction émettra un événement qui sera vu par les validateurs Namada. Une fois qu’elle a été confirmée sur la blockchain, les frais mis de côté pour les transferts seront émis à la personne qui les a relayés.

Notez qu’en utilisant des arbres de Merkle, n’importe quel sous-ensemble du pool du bridge peut être relayé dans n’importe quel ordre. Cela empêche les attaques où de grandes quantités de petites transactions sont envoyées sur le bridge pour le ralentir. Cependant, chaque lot de transferts recevra une sorte d’accréditation pour éviter le repli des transferts.

Cette conception évite le besoin de gaz pour un oracle Ethereum, les incitations du marché pousseront les utilisateurs à déterminer les frais appropriés et ainsi quelles demandes de transfert sont les plus économiques à relayer. Si les frais pour une demande de transfert sont trop bas, éventuellement la demande expirera et sera supprimée de la pool, et tous les actifs mis en séquestre seront restitués. Cette période d’expiration est un paramètre de protocole défini à la genèse qui peut être modifié via la gouvernance Namada.

Preuves sur Ethereum

Nous avons mentionné précédemment que nous devons soumettre une “root” de Merkle signée aux contrats Ethereum pour relayer les demandes de transfert. En fait, toute transaction signée par un quorum de validateurs devrait être acceptée par les smart contracts Ethereum, car elles sont essentiellement des preuves “light clients” de Namada.

Pour rendre ces preuves efficient en termes de gaz, ils doivent utiliser le hachage “Keccak” et le format de sérialisation ABI d’Ethereum. Les validateurs Namada doivent également disposer de comptes sur Ethereum qui leur permettent de signer des preuves avec des clés secp256k1.

Étant donné que les ensembles de validateurs sur Namada peuvent changer à chaque epoch, les smart contracts Ethereum ont besoin d’un moyen de savoir quelles signatures vérifier lors de la vérification d’une preuve. Cela nécessite l’envoi d’une mise à jour de l’ensemble des validateurs à Ethereum à chaque epoch, avec les nouvelles adresses de validateur, les clés publiques et le pouvoir de vote.

Cette mise à jour de l’ensemble des validateurs doit être signée par au moins 2/3 des validateurs par “stake” de l’epoch précédente, autorisant ainsi cette mise à jour en utilisant leurs clés Ethereum. Lorsqu’une nouvelle epoch commence, le nouvel ensemble de validateurs doit approuver l’ensemble des validateurs de l’epoch qui suit dans le cadre de leur vote pour un bloc.

Leur vote sera signé par leurs clés Namada et contiendra le nouvel ensemble de validateurs signées avec leurs clés Ethereum. Les ensembles de validateurs sont planifiés, de sorte qu’ils sont connus deux epochs en amont. De cette manière, le “transfert de pouvoir” est lié au consensus et disponible à la fin d’une epoch.

Lorsqu’une nouvelle epoch commence, le “leader” choisi pour le premier bloc de cette epoch, d’envoyer la mise à jour de l’ensemble des validateurs en tant que transaction à Ethereum, ce qui émettra un événement. Une fois que cet événement est confirmé sur Namada, ce validateur est récompensé par des gratifications inflationnistes pour les compenser.

Il n’y a aucun mécanisme pour punir le “leader” s’il échoue à soumettre avec succès la mise à jour de l’ensemble des validateurs. Comme la mise à jour signée est publiquement disponible sur la blockchain, n’importe qui peut envoyer la mise à jour au contrat Ethereum si nécessaire. Ainsi, cette conception n’expose pas de vecteur d’attaque, et la récompense financière devrait inciter suffisamment le “leader” choisi à relayer les mises à jour de l’ensemble des validateurs.

Les smart contracts

Architecture

Plusieurs smart contracts seront déployés sur le réseau principal d’Ethereum dans le cadre du bridge. Les principaux contrats avec lesquels les utilisateurs interagiront sont le Bridge Contract et le contrat wNAM. Le contrat du bridge est utilisé pour envoyer ou recevoir des actifs de Namada. Le contrat wNAM est un jeton ERC20 pour les NAM wrapped et autorisés sur Ethereum. Il convient de noter que seuls les jetons ERC20 peuvent être transférés entre Namada et Ethereum. Cela signifie que l’Ether ne peut pas être transféré, mais l’Ether “wrapped” le peut (le “wrapping” peut être automatisé par l’interface).

De plus, il y a trois autres contrats : le contrat Proxy, le contrat de Gouvernance , et le contrat Vault. Le contrat Proxy est un contrat fixe qui conserve l’adresse de tous les contrats les plus récents. Cela permet, en cas de mise à jour d’un contrat, d’avoir un seul contrat pour trouver l’adresse où ce contrat est déployé.

Le contrat de Gouvernance conserve l’ensemble de validateurs nécessaires pour vérifier les preuves. Il est également utilisé lors du remplacement des contrats, de l’arrêt du bridge, ou de l’accès aux fonds bloqués dans le bridge si nécessaire.

Le contrat Vault est à la fois un agent de dépôt et un registre de tous les soldes de tokens des actifs sur le bridge. Le fait qu’il soit un contrat distinct minimise la quantité de stockage qui doit être migré si le contrat du bridge est mis à jour.

Une défense en arrière garde

Comme mentionné précédemment, les validateurs de Namada doivent avoir des comptes Ethereum avec des clés publiques connues du bridge. En fait, les validateurs doivent avoir à la fois des clés “hot” et “cold”. Les clés “hot” sont celles qui sont utilisées régulièrement, tandis que les clés “cold” doivent être utilisées rarement car elles sont destinées à des opérations sensibles. Jusqu’à présent, par “clé Ethereum”, nous faisions référence aux clés “hot”.

Les validateurs peuvent utiliser leurs clés “cold” pour récupérer le bridge dans des cas extrêmes, par exemple en cas de défaillance de la pérennité de Namada. Un quorum de validateurs Namada peut utiliser ses clés “cold” pour extraire les fonds mis en séquestre dans le Vault vers n’importe quelle adresse Ethereum.

Ces clés sont également utilisées pour l’administration du bridge, y compris la mise à niveau vers de nouveaux contrats ainsi que des aspects de sécurité importants tels que les “white lists” de tokens, les plafonds de séquestre et les limites de retrait.

Une white list des jetons ERC20 autorisés sera maintenue par le bridge. De plus, une limite du montant total de chaque jeton que le bridge peut conserver en séquestre sera appliquée. Cela limite les pertes potentielles du bridge et réduit la valeur d’une attaque contre celui-ci. Un point important est que la sur-collatéralisation du bridge peut invalider les conditions de sécurité de Namada. Cela se produit si le montant de la valeur sur le bridge dépasse suffisamment la valeur misée par n’importe quel quorum de validateurs Namada.

Le plafonnement de tokens aident à garantir que les “stakes” des validateurs ne sécurisent pas une valeur nettement supérieure à celle qu’ils ont en “staking”. Une autre atténuation est la limitation du taux, ce qui signifie qu’une quantité maximale d’un token donné peut être retirée du bridge par epoch. Cela ralentit les tentatives de déplacer rapidement de la valeur hors du bridge en cas de défaillance de sécurité.

Namada est un protocole blockchain de type layer1 basé sur la preuve d’enjeu (Proof-of-Stake) qui offre une confidentialité agnostique aux actifs sur plusieurs blockchains. En utilisant la technologie avancée zk-SNARKs, Namada facilite des transactions indiscernables pour divers actifs à travers son pool de confidentialité multi-actifs (MASP) unique. Développé par Heliax au sein de l’écosystème Anoma, Namada travaille vers un avenir où la confidentialité des actifs numériques devient la norme, et non l’exception.