Nuffle : la couche de finalité en tant que service d'Ethereum

Rétrospectivement, les rollups sont apparus comme la solution de mise à l'échelle définitive pour Ethereum et la technologie décentralisée dans son ensemble. Neuf mois après la mise à niveau de Dencun d'Ethereum, qui ciblait la mise à l'échelle de la disponibilité des données de rollup, le débit des transactions a dépassé les deux cents transactions par seconde, ce qui représente une multiplication par cinq depuis le début de l'année. Les deux principaux rollups, Arbitrum et OP Mainnet, ont atteint la décentralisation de stade 1 , surpassant plusieurs réseaux alternatifs de premier plan de la couche 1 dans les mesures de décentralisation, avec des rollups supplémentaires ciblant potentiellement la décentralisation de stade 2 en 2025. La technologie de preuve à connaissance nulle a progressé pour permettre la vérification des transactions équivalentes à Ethereum à des coûts inférieurs au centième , établissant une voie pour une vérification efficace de milliers de transactions d'utilisateurs standard sur la blockchain Ethereum contemporaine.

Cependant, cette avancée présente de nouveaux défis. Plusieurs équipes développent des blockchains indépendantes sur Ethereum, avec une interopérabilité limitée entre elles. Cette limitation provient principalement de la finalisation peu fréquente des rollups, ce qui empêche une communication inter-chaîne significative. De plus, les rollups optimistes, qui hébergent actuellement la majorité de l'activité de l'écosystème et Total Value Locked (TVL), sont confrontés à des contraintes techniques inhérentes qui empêchent la communication directe en dehors des ponts partagés, créant ainsi un obstacle important à l'interopérabilité entre les principaux réseaux comme Arbitrum et Base.

La communauté a proposé diverses solutions, allant du pontage basé sur l'intention et des échanges atomiques à l'abstraction complète de la chaîne. Malgré leurs différences, ces solutions partagent une exigence fondamentale : une source de vérité fiable, un protocole permettant une vérification sécurisée de l'état entre les cumuls, à la fois rapide et rentable.

Parmi les solutions les plus importantes, qui reposent généralement sur des oracles optimistes (Across), un consensus d'opérateurs spécialisés (Stargate via LayerZero) ou une confiance centralisée du séquenceur (Polymer Hub), la Fast Finality Layer (NFFL) de Nuffle Labs présente un équilibre convaincant entre efficacité, sécurité et alignement Ethereum. Cet article examine l'approche innovante de NFFL pour permettre la vérification de l'état cross-rollup via le mécanisme de re-staking d'EigenLayer et NEAR DA, explore sa conception architecturale et sa feuille de route de développement, et analyse les applications potentielles et leurs implications pour l'écosystème.

Un rappel sur les rollups

Pour comprendre les défis auxquels la NFFL fait face, examinons l'architecture fondamentale des rollups, leurs objectifs et leurs limites inhérentes :

Un rollup est une blockchain qui utilise une autre blockchain indépendante pour l'ordre des transactions, la disponibilité des données et le consensus, tout en exécutant les transactions en externe d'une manière vérifiable par la blockchain parent. Bien que de nombreuses définitions fassent référence à la chaîne parent comme couche 1 (L1) et au rollup comme couche 2 (L2), certains frameworks n'exigent pas que les L2 utilisent la L1 pour la disponibilité des données. Pour plus de clarté, cet article se concentre spécifiquement sur les rollups plutôt que sur la catégorie L2 plus large.

Bien sûr, dans notre cas, le parent L1 est la blockchain Ethereum. Elle est chargée de partager son consensus avec les rollups (nous développerons ce point plus tard). Analysons comment les rollups exploitent Ethereum pour leurs fonctions principales : l'ordre des transactions, la disponibilité des données et le consensus.

Commande de transaction

Les rollups intègrent une entité appelée séquenceur, chargée de gérer l'inclusion et la commande des transactions via le réseau L1. Le séquenceur fonctionne de manière analogue à un producteur de blocs dans les blockchains traditionnelles. Plus précisément, il accepte les transactions entrantes des utilisateurs de manière séquentielle, les regroupe en lots (comparables aux blocs L1) et publie périodiquement ces lots dans un contrat intelligent désigné sur le L1.

Un contrat intelligent sur le L1 conserve un enregistrement officiel de toutes les transactions publiées et de leur ordre. Les nœuds de cumul doivent surveiller ce contrat pour récupérer de nouveaux blocs et des informations sur les transactions. Une fois qu'un lot est inclus dans un bloc L1 et que ce bloc atteint la finalité grâce au consensus L1, l'inclusion et l'ordre de toutes les transactions au sein de ce lot sont garantis par les propriétés de sécurité du L1.

Dans une certaine mesure, le séquenceur est un « starter » du rollup : il aide le rollup à accepter réellement de nouvelles transactions dans le réseau, facilitant ainsi le déplacement de l'état vers l'avant. Certains rollups implémentent un séquençage décentralisé (un ensemble rotatif d'entités spécialisées réduisant le risque de temps d'arrêt d'un séquenceur par ailleurs centralisé) et un séquençage basé, qui n'utilise aucun séquenceur comme source de confiance avant de publier le lot sur le L1.

(Le séquençage basé sur le temps permet à n'importe qui d'être séquenceur, mais leurs lots ne sont utilisés par les nœuds que lorsqu'ils sont publiés sur le L1. Cela n'entraîne pratiquement aucun risque de temps d'arrêt du séquençage au prix d'une inclusion plus lente des transactions (le meilleur scénario est celui des 12 secondes par bloc du L1).)

Cependant, les séquenceurs ne décident pas du nouvel état des choses dans le rollup, même après l'exécution de leurs propres lots. Par conséquent, les séquenceurs « démarrent » mais n'« exécutent » pas nécessairement le rollup, car leurs actions ne peuvent pas conduire directement à la transition d'état malveillante.

Disponibilité des données

Cependant, les informations sur l'ordre de certaines transactions ne sont pas suffisantes pour les nœuds du rollup, car ils ne possèdent pas les transactions elles-mêmes. Afin d'exécuter ces transactions et de déterminer leur résultat dans la blockchain du rollup, les nœuds doivent avoir un accès complet et sans restriction à toutes les transactions du lot.

Par conséquent, les séquenceurs de cumul doivent publier des données de transaction complètes sur le L1 d'une manière qui permet au contrat intelligent du cumul de vérifier la disponibilité des données . Une fois que les données de transaction d'un lot sont incluses et finalisées sur le L1, leur disponibilité est garantie pour tous les nœuds participants.

Avant la mise à niveau de Dencun, les rollups Ethereum publiaient les données de transaction dans les données d'entrée (calldata) des appels de séquençage sur le L1. Par conséquent, toutes les transactions doivent avoir été publiées sur la blockchain du L1 pour toujours. Cela peut sembler raisonnable, car nous voulons que tous les nœuds, y compris les futurs, puissent reconstruire l'état du rollup. Cependant, cela est très inefficace, car le L1 d'Ethereum ne peut pas stocker de grandes quantités de données sur son grand livre, alors que les rollups, les voies à grande vitesse d'Ethereum, sont très gourmands en données. Au lieu de cela, nous pouvons faire en sorte que le contrat intelligent du rollup vérifie la validité des transactions séquencées, de sorte que les nœuds suivent instantanément l'état du contrat, plutôt que de le reconstruire à partir de toutes les transactions à partir de la genèse.

Taches

La mise à niveau Dencun d'Ethereum en mars dernier avait introduit les « blobs » — des cellules de données temporaires qui sont stockées en dehors de la blockchain et élaguées (supprimées par les validateurs du réseau) après environ 18 jours. Comme les ponts de rollup permettent de reconstruire l'état sans réexécuter les transactions, cette propriété est devenue très utile pour les rollups, qui ont migré des données d'appel vers les blobs peu de temps après la mise à niveau. En termes de chiffres, avant Dencun, le nombre total de TPS des rollups était d'environ 50. Aujourd'hui, il est supérieur à 200, avec des limites théoriques à 400-800 TPS selon le rollup .

Au-delà des améliorations de capacité, les blobs ont éliminé l'obligation de payer les coûts de gaz EVM pour le stockage des données de transaction, en établissant un canal séparé avec un stockage temporaire spécialisé et une tarification indépendante des frais. Ce changement architectural a considérablement réduit les coûts de transaction dans les rollups, les frais passant de 10 à 40 cents par transaction à des niveaux inférieurs à un cent dans des réseaux comme Base.

Pont consacré (consensus)

Pour plus de simplicité, nous avons simplement inversé la définition du rollup : généralement, toutes les explications commencent par un pont à double sens entre le rollup et son L1. Il est assez courant parmi les rollups d'utiliser la devise native du L1 comme la sienne, pour simplifier l'estimation des frais de gaz en fonction des dépenses des séquenceurs et des proposants . De plus, de nombreux rollups souhaitent obtenir des jetons populaires dans leur écosystème dès le premier jour, pour lesquels les relier à leur L1 est le meilleur choix.

La mise en œuvre d'un contrat intelligent de pont de L1 au rollup est assez simple : les nœuds de rollup écoutent déjà tout ce qui se passe dans son contrat, nous pouvons donc implémenter une fonction de dépôt L1 que tous les nœuds interpréteront comme une commande pour émettre le jeton « encapsulé » respectif sur le rollup lui-même.

Cependant, les retraits sans confiance nécessitent que le contrat de pont valide toutes les transactions de cumul et détermine leurs résultats légitimes. Cela permet au pont de traiter les demandes de retrait valides en libérant des fonds aux initiateurs autorisés sur le L1. Ce mécanisme de validation fait du pont la source définitive de l'état canonique du cumul : les nœuds s'alignent sur la transition d'état du pont, quelles que soient les fourches de chaîne alternatives. Contrairement aux blockchains traditionnelles, les cumuls n'implémentent pas de règles de consensus indépendantes pour la sélection de la chaîne. Le contrat de pont sur le L1 est ce qui définit la chaîne canonique.

Règlement cumulatif

Bien que les séquenceurs gèrent l'ordre et la publication des transactions, ils ne représentent qu'un seul composant de l'architecture de cumul. Les cumuls intègrent également des entités appelées « proposants » chargées de convaincre le pont L1 des sorties d'état spécifiques résultant des lots nouvellement séquencés. En substance, alors que les séquenceurs établissent l'occurrence et l'ordre des transactions, les proposants démontrent les résultats de ces transactions selon la logique de traitement du cumul, comme sa machine virtuelle.

Le rôle du proposant varie considérablement en fonction de l'approche de validation de l'état du cumul. Il existe deux méthodologies fondamentalement différentes, définissant deux catégories de cumuls : optimiste et à connaissance nulle (ZK).

Des cumuls optimistes

Dans les cumuls optimistes, les proposants soumettent régulièrement des mises à jour d'état au pont L1, généralement parallèlement ou peu de temps après les publications par lots du séquenceur. Ces mises à jour d'état incluent la nouvelle racine d'état (un engagement cryptographique envers l'ensemble du nouvel état du cumul) après l'exécution de toutes les transactions des derniers lots.

Pour éviter les mises à jour d'état invalides, le pont met en œuvre une période de contestation (généralement 7 jours) pendant laquelle des acteurs spécialisés appelés « challengers » peuvent contester la proposition en soumettant une preuve de fraude . Cette preuve démontre que les transactions ont été exécutées de manière incorrecte en réexécutant la transaction contestée sur le L1 et en comparant les résultats.

Si un challenger parvient à prouver qu'un proposant a soumis une transition d'état non valide, la sortie d'état est annulée et le challenger est récompensé (souvent par une caution que les proposants doivent déposer). Cela crée un jeu économique dans lequel les proposants sont incités à soumettre uniquement des transitions d'état valides.

Cumuls à connaissance nulle

Dans les cumuls ZK, les proposants génèrent des preuves mathématiques (appelées « preuves de validité » ou, plus techniquement correctes, « preuves ZK ») qui démontrent l'exactitude de chaque transition d'état. Ces preuves montrent que toutes les transactions d'un lot ont été exécutées conformément aux règles du cumul sans révéler les détails spécifiques de leur exécution.

Le pont L1 peut vérifier rapidement ces preuves à l'aide d'opérations cryptographiques efficaces, pour environ le coût d'un échange de jetons. Une fois qu'une preuve est vérifiée, le pont accepte la mise à jour d'état comme réglée. Cela signifie que les proposants doivent effectuer un travail de calcul important avant de soumettre des mises à jour d'état, mais ces mises à jour sont réglées beaucoup plus rapidement que les cumuls optimistes.

Règlement, finalité et interopérabilité

Le temps de règlement via les ponts canoniques varie considérablement selon les types de rollups : de 7 jours pour les rollups optimistes en raison de leur période de défi, à plusieurs heures pour les rollups ZK en raison des frais généraux de génération de preuves et des coûts de publication par lots. Bien que ce modèle fonctionne bien pour sécuriser les transactions de grande valeur qui peuvent tolérer des retards, il crée des frictions importantes pour l'écosystème DeFi au sens large.

Considérez l’impact de cette situation sur l’utilisation dans le monde réel : un utilisateur qui souhaite utiliser sa garantie basée sur Arbitrum pour contracter un prêt sur Base doit d’abord relier ses actifs et attendre jusqu’à 7 jours avant de pouvoir les utiliser. Un trader repérant une opportunité d’arbitrage entre les pools Uniswap sur différents rollups verrait l’opportunité disparaître bien avant de pouvoir l’exécuter. Une application de jeu souhaitant permettre aux joueurs d’échanger des objets entre différents déploiements de rollups serait confrontée à une expérience utilisateur inacceptable avec des délais aussi longs.

L'idée essentielle ici est que les nœuds de cumul peuvent en fait observer les changements d'état beaucoup plus rapidement, généralement quelques secondes après la confirmation du bloc L1. Bien que cet état n'ait pas subi de règlement complet dans le pont canonique, il est basé sur des données de transaction qui ont déjà été ordonnées et finalisées sur Ethereum. De nombreuses bourses centralisées exploitent déjà cette propriété, en créditant les dépôts des utilisateurs à partir des cumuls après seulement quelques confirmations de bloc en exécutant leurs propres nœuds et en vérifiant la finalité des transactions sur L1.

Cela crée une dichotomie intéressante dans l'écosystème des rollups. Bien que les rollups aient réussi à faire évoluer le débit des transactions d'Ethereum, ils ont introduit une grave fragmentation de l'état et de la liquidité. Chaque rollup fonctionne effectivement comme une blockchain indépendante qui ne peut pas vérifier efficacement l'état des autres rollups sans attendre le règlement du pont, bien que tous tirent leur sécurité de la même chaîne sous-jacente : Ethereum.

Quelles sont les solutions existantes face à la liquidité et à la fragmentation de l’État ?

L'écosystème a développé diverses approches pour surmonter ces limitations, des ponts centralisés aux réseaux spécialisés hors chaîne. Ces solutions font généralement des compromis différents entre trois propriétés clés :

• Sécurité - Dans quelle mesure les garanties de vérification de l'État sont-elles correctes ?
• Vitesse - La rapidité avec laquelle l'état peut être vérifié sur les chaînes
• Coût - Le coût de maintenance et d'utilisation de la solution

La plupart des solutions existantes optimisent la vitesse et le coût au détriment de la sécurité, en s'appuyant souvent sur des opérateurs de confiance, des multisigs ou des mécanismes optimistes avec un soutien économique minimal. Cela a conduit à plusieurs piratages de ponts très médiatisés, notamment l'exploit de pont Ronin de 625 millions de dollars, soulignant les risques liés au sacrifice de la sécurité au profit de la commodité.

Le défi fondamental est d'établir une « source de vérité » sécurisée sur les états de cumul qui peut :

• Vérifiez les changements d'état en quelques secondes ou minutes plutôt qu'en quelques heures ou jours
• Fournir de solides garanties de sécurité cryptoéconomique
• Fonctionner de manière rentable pour les fournisseurs d'infrastructures et les utilisateurs
• S'intègre parfaitement aux architectures de rollup existantes

Cette opportunité de permettre une vérification rapide et sécurisée de l'état entre les cumuls a suscité une innovation significative. Différentes équipes abordent le problème sous différents angles, cherchant à créer une infrastructure capable d'alimenter la prochaine génération d'applications inter-chaînes sans compromettre la sécurité.

Dans les sections suivantes, nous explorerons comment NFFL aborde ce défi grâce à sa nouvelle combinaison de restaking d'EigenLayer et de NEAR DA, créant une couche de finalité rapide qui établit un équilibre prudent entre sécurité, vitesse et rentabilité.

Comprendre la couche de finalité rapide Nuffle (NFFL)

La couche de finalité rapide Nuffle (NFFL) représente une nouvelle approche permettant des interactions inter-chaînes sécurisées en fournissant une vérification rapide de l'état entre les cumuls. Plutôt que de forcer les développeurs à choisir entre sécurité et rapidité, la NFFL exploite l'ETH re-stadé d'EigenLayer pour créer une couche de finalité rapide sécurisée sur le plan cryptoéconomique qui peut attester des états de cumul en quelques secondes.

À la base, NFFL fonctionne comme un service à validation active (AVS) fonctionnant sur EigenLayer. Un réseau décentralisé d'opérateurs, chacun exécutant des nœuds complets pour les rollups participants, vérifie et atteste des mises à jour d'état. Ces attestations sont soutenues par l'ETH réévalué des opérateurs, créant de fortes incitations économiques pour un comportement honnête. En combinant cela avec la couche de disponibilité des données de NEAR pour un stockage efficace des données de bloc, NFFL permet aux applications de vérifier en toute sécurité l'état inter-chaînes en 2 à 3 secondes, soit des ordres de grandeur plus rapides que le règlement canonique des ponts.

Ce qui rend NFFL particulièrement convaincant, c'est son approche de conception pragmatique. Plutôt que d'essayer de remplacer ou de concurrencer le modèle de sécurité d'Ethereum, il fournit une couche complémentaire optimisée pour les cas d'utilisation qui nécessitent une finalité plus rapide. Les applications peuvent choisir de s'appuyer sur la sécurité cryptoéconomique de NFFL ou d'attendre le règlement complet de L1 en fonction de leurs besoins spécifiques. Cette flexibilité permet à NFFL d'améliorer l'expérience utilisateur pour de nombreuses interactions inter-chaînes tout en maintenant de solides garanties de sécurité.

Le système introduit trois innovations clés :

1. Un réseau d'opérateurs décentralisé qui parvient à un consensus sur les états de cumul en comparant les transitions d'état exécutées localement aux données de bloc publiées sur NEAR DA
2. Un système de tâches basé sur des points de contrôle qui permet une agrégation et une vérification efficaces des attestations des opérateurs tout en maintenant la responsabilité grâce aux mécanismes de découpage d'EigenLayer
3. Un mécanisme de stockage de données utilisant NEAR DA permettant une récupération facile des données de cumul attestées dans tous les cumuls

Cette conception permet à NFFL de trouver un équilibre délicat entre sécurité, rapidité et rentabilité, trois propriétés traditionnellement en contradiction dans les infrastructures inter-chaînes. En fournissant une vérification d'état rapide mais sécurisée, NFFL ouvre de nouvelles possibilités pour les applications inter-chaînes allant des protocoles de prêt aux agrégateurs de liquidités.

Dans les sections suivantes, nous explorerons en détail l'architecture de NFFL, en examinant comment ses différents composants fonctionnent ensemble pour permettre à cette nouvelle primitive d'interagir entre les chaînes. Nous analyserons également son modèle de sécurité, discuterons des applications potentielles et examinerons la feuille de route du protocole pour le développement futur.

Un aperçu des principaux composants de la NFFL

Ensemble d'opérateurs

Au cœur de NFFL se trouve son réseau d'opérateurs - un système décentralisé qui étend la sécurité d'Ethereum pour permettre une vérification croisée rapide. Plutôt que de créer un autre réseau cloisonné nécessitant ses propres hypothèses de sécurité, NFFL est construit comme un service de validation active (AVS) sur EigenLayer, ce qui lui permet d'exploiter directement l'écosystème de validation existant d'Ethereum.

Ce choix architectural est fondamental pour comprendre le modèle de sécurité de NFFL. Les mêmes validateurs qui sécurisent le consensus d'Ethereum peuvent re-staker leur ETH via EigenLayer pour devenir opérateurs NFFL. Ce faisant, ils mettent en danger leur ETH jalonné pour étayer leurs attestations sur les états de cumul. Cela crée un puissant pont de sécurité entre le consensus d'Ethereum et la couche de finalité rapide de NFFL.

Lorsqu'un cumul publie de nouvelles données de bloc sur le L1, les relais les transmettent à NEAR DA. Les opérateurs récupèrent les données de bloc via les deux sources et s'assurent qu'elles sont équivalentes. Nous expliquerons plus en détail pourquoi la publication des données de cumul sur NEAR DA est nécessaire pour rendre les applications utilisant NFFL plus pratiques pour les utilisateurs et les développeurs.

Après avoir récupéré de nouveaux lots de cumuls, les opérateurs les exécutent dans leurs nœuds de cumul. Étant donné qu'ils exécutent tous le même logiciel de nœud, ils apparaîtront toujours avec le même état de sortie correct. Cet état de sortie est ensuite signé par tous les opérateurs. Lorsque la majorité des opérateurs s'accordent sur un état spécifique, celui-ci est accepté par le système et peut être transmis aux contrats de registre pour tous les cumuls.

La sécurité économique d'un tel système a une propriété très intéressante qui découle de la mécanique de découpage d'EigenLayer :

Dans EigenLayer, les services validés activement peuvent mettre en œuvre un mécanisme de vérification capable de détecter les attestations non valides des opérateurs et de liquider leur dépôt par la suite. Étant donné que NFFL « règle de manière préliminaire » l'état de cumul hors chaîne avant qu'il ne soit réglé dans le pont, il est possible de détecter objectivement la fraude en attendant le délai de règlement et en informant le contrat AVS de l'incohérence de sortie dans l'attestation et le pont.

Cela décourage économiquement les attestations frauduleuses, car elles peuvent être détectées et supprimées par toute entité surveillant l'état de L1 et de NFFL, même sans qu'elles n'exécutent de nœuds de cumul. En d'autres termes, NFFL « assure » les revendications du réseau : les opérateurs mettent en jeu des capitaux importants pour soutenir leurs revendications sur les états de cumul.

Ce qui rend cette approche particulièrement efficace, c’est la façon dont elle aligne les incitations sur l’ensemble du système. Les opérateurs perçoivent des commissions pour une participation honnête tout en risquant des pertes importantes en cas de malhonnêteté. Plus l’ETH est réinvesti dans la NFFL, plus ces incitations deviennent fortes. Et comme cette sécurité est dérivée d’Ethereum via EigenLayer, elle bénéficie en partie du même modèle de sécurité économique robuste qui garantit des centaines de milliards de dollars de valeur sur Ethereum lui-même.

Flux de messagerie

Le système de messagerie de NFFL représente une approche innovante pour gérer la vérification d'état inter-chaînes à grande échelle. Au lieu d'enregistrer chaque attestation d'état sur la chaîne, ce qui serait extrêmement coûteux, NFFL introduit un système à deux couches de messages et de tâches qui permet un fonctionnement hors chaîne efficace tout en maintenant de solides garanties de sécurité sur la chaîne à la demande.

Les messages constituent l'unité de communication de base dans NFFL. Lorsque les opérateurs vérifient un nouvel état, ils créent et signent un message attestant de cet état. Ces messages existent principalement hors chaîne, circulant entre les opérateurs et l'agrégateur sans entraîner de coûts de gaz sur la chaîne. Il existe deux types distincts de messages qui circulent dans le système :

• Les messages de mise à jour de la racine d'état contiennent l'attestation d'un opérateur sur l'état d'un cumul à une hauteur de bloc spécifique. Chaque message inclut non seulement la racine d'état elle-même, mais également une référence à la transaction NEAR DA contenant les données de bloc, créant ainsi un lien vérifiable entre l'état attesté et ses données sous-jacentes.

• Les messages de mise à jour de l'ensemble des opérateurs suivent les modifications apportées à l'ensemble des opérateurs de la NFFL. Ces messages sont essentiels à la sécurité du système car ils permettent aux contrats de registre cumulatifs de conserver un enregistrement à jour des opérateurs valides, garantissant que les attestations ne sont acceptées que par les participants autorisés dont les enjeux sont en jeu.

  
  

Bien que les messages permettent une vérification efficace de l'état, ils ne suffisent pas à eux seuls à garantir la sécurité économique du système. C'est là qu'interviennent les tâches. Les tâches sont des unités de travail sur la chaîne qui vérifient l'état du système à intervalles réguliers. Plutôt que de soumettre chaque message à Ethereum, les opérateurs construisent périodiquement un arbre de Merkle clairsemé contenant tous les messages d'une période donnée. La racine de cet arbre est ensuite soumise en tant que réponse à une tâche, créant ainsi un engagement efficace sur la chaîne pour toutes les attestations hors chaîne.

Ce système de points de contrôle est particulièrement intelligent car il permet une vérification sélective de n'importe quel message sans nécessiter que tous les messages soient stockés sur la chaîne. Grâce aux preuves Merkle, n'importe qui peut vérifier qu'un message spécifique a été inclus dans un point de contrôle, ce qui permet des mécanismes de contestation efficaces tout en maintenant les coûts de base à un niveau bas. Vous pouvez le considérer comme la création d'une « blockchain d'attestations » où les points de contrôle servent d'en-têtes de bloc qui s'engagent sur tous les messages au cours d'une période donnée.

L'agrégateur joue un rôle crucial dans ce système en collectant les signatures des opérateurs et en les rendant disponibles via une API. Lorsque les opérateurs signent des messages, ils les envoient à l'agrégateur qui vérifie que les signatures ont atteint le quorum (pondéré par l'ETH jalonné) avant de les exposer pour utilisation par les applications. Cela crée une interface propre pour les développeurs tout en préservant les propriétés de sécurité décentralisées du système. Nous détaillerons le service d'agrégation dans la section suivante.

Service d'agrégation

L'agrégateur agit comme couche de coordination de NFFL, gérant efficacement le flux de messages entre les opérateurs et les applications. Bien que conceptuellement simple, sa conception reflète une prise en compte attentive des besoins pratiques des développeurs et des principes de décentralisation.

Fondamentalement, l'agrégateur résout le problème de la « tragédie des biens communs » dans l'agrégation de signatures. Sans service dédié, chaque application utilisant NFFL devrait collecter et vérifier indépendamment les signatures de tous les opérateurs, un processus inefficace et coûteux. Au lieu de cela, l'agrégateur fournit un point de collecte unique pour les signatures des opérateurs, vérifiant le quorum et exposant les attestations vérifiées via une API simple.

Le processus d’agrégation de signatures fonctionne comme suit :

• Les opérateurs signent indépendamment les messages attestant des mises à jour d'état

• Ces signatures sont envoyées à l'agrégateur pour collecte

• L'agrégateur vérifie la validité de la signature et suit le quorum

• Une fois que le poids d'enjeu suffisant est atteint, la signature agrégée devient disponible

• Les applications peuvent récupérer ces attestations via l'API de l'agrégateur

  
  

Cette conception réduit considérablement la complexité pour les développeurs qui intègrent NFFL. Plutôt que de gérer des opérations cryptographiques complexes ou de suivre les enjeux des opérateurs, les applications peuvent simplement demander des attestations pour des mises à jour d'état spécifiques via une interface API propre. L'agrégateur gère toute la complexité de la collecte de signatures, de la vérification et de l'agrégation BLS en arrière-plan.

Agrégation de signatures

Explorons plus en détail l'agrégation BLS utilisée par NFFL. Les signatures BLS ont une puissante propriété mathématique qui permet de combiner plusieurs signatures en une seule signature. Au lieu de vérifier N signatures individuelles des opérateurs, ce qui serait coûteux en calcul et en gaz, les applications peuvent vérifier une seule signature agrégée qui prouve un accord collectif.

Les gains d’efficacité sont ici considérables. Lorsque les opérateurs NFFL signent un message, ils génèrent des signatures BLS standard à l’aide de leurs clés privées. L’agrégateur peut ensuite combiner ces signatures individuelles en une seule signature compacte qui prouve l’accord du quorum. La taille et le coût de vérification de cette signature agrégée restent constants quel que soit le nombre d’opérateurs participants – une propriété qui rend le système hautement évolutif.

De plus, la signature agrégée peut être vérifiée par rapport aux clés publiques combinées des opérateurs signataires, pondérées par leurs montants mis en jeu afin de garantir que la sécurité économique est correctement prise en compte. Le contrat de registre n'a alors besoin que d'effectuer une opération de vérification de signature pour confirmer qu'un poids de mise suffisant a attesté de la mise à jour de l'état.

Agrégateur et points de contrôle

Il est important de noter que, bien que l'agrégateur soit pratique, il ne compromet pas le modèle de sécurité de NFFL. Les signatures qu'il collecte sont vérifiables publiquement et son rôle est purement organisationnel plutôt qu'autoritaire. Les applications peuvent toujours vérifier de manière indépendante que les signatures agrégées représentent un quorum légitime des opérateurs mis en jeu. L'agrégateur ne peut ni falsifier les signatures ni cacher les attestations valides : il les rend simplement plus accessibles.

L'agrégateur joue également un rôle essentiel dans le système de points de contrôle. En collectant tous les messages au fil du temps, il peut construire les arbres de Merkle clairsemés utilisés dans les tâches de points de contrôle. Cela crée un enregistrement efficace de toutes les attestations qui ont transité par le système, permettant une vérification ultérieure si nécessaire pour des problèmes de sécurité ou à des fins d'audit.

Contrats de registre

Le contrat de registre, déployé sur chaque rollup participant, sert de pont essentiel entre les attestations hors chaîne de NFFL et la vérification de l'état sur la chaîne. Ces contrats permettent aux applications de vérifier en toute confiance l'état d'autres rollups en validant les attestations cryptoéconomiquement sécurisées de NFFL.

Ce qui rend le registre particulièrement intéressant, c'est la façon dont il maintient les propriétés de sécurité de NFFL sur différentes chaînes. Chaque contrat de registre conserve une copie locale de l'ensemble d'opérateurs de NFFL, en suivant les modifications via les attestations de mise à jour de l'ensemble d'opérateurs. Cela signifie que même si l'ensemble d'opérateurs est géré via EigenLayer sur Ethereum, son état est reproduit de manière fiable sur tous les cumuls participants, ce qui leur permet de vérifier les attestations de manière indépendante.

Lorsqu'une application doit vérifier l'état d'un autre cumul (par exemple, un protocole de prêt vérifiant les garanties sur Arbitrum depuis Optimism), elle soumet l'attestation pertinente à son contrat de registre local. Cette attestation comprend la signature BLS agrégée dont nous avons parlé précédemment, ainsi que la racine d'état spécifique attestée et sa référence de transaction NEAR DA associée.

Le processus de vérification dans le registre est remarquablement efficace grâce à l'agrégation de signatures BLS. Le contrat n'a besoin d'effectuer qu'une seule vérification de signature par rapport aux clés publiques pondérées de l'ensemble d'opérateurs actuel. Si la signature est valide et représente un poids d'enjeu suffisant, le registre accepte l'état attesté comme vérifié. Cela crée un pont sans confiance entre les cumuls qui est à la fois sécurisé et rentable.

Le registre crée un pont minimisant la confiance entre les cumuls, à la fois sécurisé et rentable. Grâce à la vérification des signatures agrégées par rapport aux clés publiques pondérées de l'ensemble d'opérateurs, il peut confirmer qu'une mise à jour d'état a reçu un poids d'attestation suffisant pour être considérée comme valide. Cela permet aux applications de vérifier de manière fiable les états sur différents cumuls tout en héritant des garanties de sécurité économique de NFFL.

Le registre joue également un rôle crucial dans le système de contestation de la NFFL. Si une attestation s'avère ultérieurement frauduleuse grâce au système de contestation, le registre peut l'invalider, protégeant ainsi les applications contre le recours à un état incorrect. Cela crée plusieurs niveaux de sécurité : des garanties cryptoéconomiques immédiates grâce à l'ETH mis en jeu, combinées à une protection contre la fraude à plus long terme grâce aux contestations.

Classification des défauts et conception de sécurité dans NFFL

Le modèle de sécurité de la NFFL s'articule autour de la détection et de la pénalisation de deux principaux types de mauvais comportement des opérateurs : les défauts de sécurité et les défauts de vivacité.

Les défauts de sécurité sont des violations qui affectent l'intégrité du réseau en produisant des états ou des résultats incorrects non conformes aux règles du système. Il existe deux principaux types de défauts de sécurité que les opérateurs peuvent commettre :

• L'équivoque se produit lorsqu'un opérateur signe plusieurs messages contradictoires pour le même événement. Par exemple, il signe des attestations pour différentes racines d'état à la même hauteur de bloc ou il atteste de plusieurs horodatages différents pour le même bloc. Un tel comportement compromet la capacité du réseau à parvenir à un consensus sur l'état canonique.
• Une attestation non valide se produit lorsqu'un opérateur signe une déclaration prouvablement incorrecte. Il peut s'agir d'attester d'une mise à jour d'un ensemble d'opérateurs qui ne correspond pas au delta d'état de la chaîne, ou de signer une racine d'état qui ne correspond pas à l'exécution correcte des transactions du bloc. Ces défauts peuvent être vérifiés objectivement grâce aux données de la chaîne.

Alors que les failles de sécurité attaquent directement l'exactitude, les failles de vivacité affectent la disponibilité et l'efficacité du réseau. Si les opérateurs s'abstiennent systématiquement de participer à la signature des messages, cela affecte à la fois la disponibilité du réseau et augmente les coûts de vérification pour les utilisateurs qui ont besoin de plus de signatures pour atteindre le quorum. Le protocole suit la participation des opérateurs via des tâches de point de contrôle pour identifier et pénaliser ce comportement.

Le processus de contestation varie en fonction du type de défaut et du message contesté :

Pour les tâches de point de contrôle, les challengers peuvent prouver des erreurs d'inclusion ou d'exclusion de messages. Si un message avec des attestations valides de la période de temps du point de contrôle a été omis, ou si un message non valide/hors période a été inclus, le challenge réussit. Cela est vérifié par des preuves Merkle par rapport à l'arborescence des messages du point de contrôle.

Les messages individuels peuvent être contestés après leur période de contrôle en prouvant que le contenu du message n'était pas valide. Par exemple :

• Les messages de mise à jour de l'ensemble d'opérateurs peuvent être invalidés en affichant l'ID de mise à jour revendiqué ou le delta de l'opérateur ne correspond pas à l'état de la chaîne
• Les messages de mise à jour de la racine d'état peuvent être contestés en démontrant que la racine d'état revendiquée est incompatible avec l'exécution correcte de la transaction

Ce système de vérification multicouche permet au protocole de maintenir à la fois un fonctionnement rapide grâce à la messagerie hors chaîne tout en préservant de solides garanties de sécurité grâce à des mécanismes cryptoéconomiques. En rendant les comportements invalides détectables de manière prouvable et punissables économiquement grâce au slashing d'EigenLayer, NFFL crée de fortes incitations pour un fonctionnement honnête tout en permettant des contestations efficaces lorsque des violations se produisent.

Applications concrètes de la NFFL

En établissant un moyen de lectures d'état croisées rapides et peu coûteuses, NFFL ouvre un large éventail d'applications qui n'étaient pas réalisables avec la pile technologique actuelle de l'écosystème. Explorons certaines des idées, de quelque chose de théorique et simple à des applications plus complexes et spécifiques, utiles dans les domaines les plus populaires de l'écosystème Ethereum d'aujourd'hui.

Bonjour Protocole

Commençons par un exemple simple, décrit dans la documentation officielle de Nuffle Labs : un protocole qui permet aux utilisateurs d'envoyer des messages « hello » entre différents rollups. Bien que basique, cela démontre les mécanismes de base de la manière dont les applications peuvent exploiter NFFL pour la communication inter-chaînes.

Imaginez un utilisateur souhaitant envoyer un message sur le réseau n°1 qui sera lu sur le réseau n°2. Le processus commence lorsqu'il soumet une transaction sur le réseau n°1 en enregistrant son message « bonjour ! » dans l'état du réseau. À ce stade, le message n'existe que sur le réseau n°1 et nécessiterait normalement d'attendre le règlement canonique du pont (potentiellement des heures ou des jours) avant de pouvoir être vérifié par d'autres cumuls.

C'est là qu'intervient NFFL. Lorsque le bloc contenant ce message est produit, il est envoyé à NEAR DA par le relais du réseau. Les opérateurs NFFL, qui exécutent des nœuds complets pour les deux réseaux, vérifient que les données de ce bloc correspondent à ce que leur nœud réseau n°1 a calculé localement. Après vérification, ils signent des messages attestant de la nouvelle racine d'état.

Ces attestations transitent par le service d'agrégation de NFFL, qui collecte les signatures jusqu'à ce qu'un poids d'enjeu suffisant soit attesté par l'État. Une fois le quorum atteint, la signature agrégée devient disponible via l'API de NFFL, généralement quelques secondes après la production du bloc d'origine.

Vient maintenant la partie intéressante : la consommation du message sur le réseau n°2. Le contrat du protocole Hello sur le réseau n°2 peut accepter une transaction contenant :

• La preuve de stockage montrant que le message existe dans l'état du réseau n°1
• L'attestation NFFL prouvant que cet état est valide
• Une référence à la transaction NEAR DA contenant les données du bloc

Le protocole achemine ces données vers le contrat de registre du réseau n° 2, qui vérifie la signature de l'attestation par rapport à son enregistrement des opérateurs NFFL. Si elle est valide, cela prouve que le message existe dans l'état vérifié du réseau n° 1, ce qui permet au protocole de le traiter en toute sécurité.

Ce qui rend cette solution puissante, c'est sa combinaison de rapidité et de sécurité. L'ensemble du flux, de la soumission du message à la vérification inter-chaînes, peut être réalisé en quelques secondes, plutôt qu'en quelques heures ou jours avec des ponts canoniques. Pourtant, la sécurité provient de garanties cryptoéconomiques soutenues par l'ETH re-staked via EigenLayer, plutôt que d'opérateurs de confiance ou d'hypothèses optimistes.

Bien que l'envoi de messages « bonjour » puisse sembler trivial, ce même modèle permet des applications inter-chaînes beaucoup plus sophistiquées. La possibilité de vérifier rapidement et en toute confiance l'état des cumuls crée des éléments de base pour tout, de la DeFi inter-chaînes aux expériences utilisateur abstraites de la chaîne.

Pont de jetons rapide et bon marché

En nous appuyant sur ces principes fondamentaux, explorons une application plus pratique : un pont de jetons exploitant NFFL pour des transferts inter-routage rapides. Le paysage actuel des ponts impose des compromis difficiles entre vitesse, coût et sécurité. Mais NFFL peut remodeler cette dynamique et permettre une expérience de pontage améliorée pour les utilisateurs.

Les principaux ponts actuels illustrent clairement ces compromis. Stargate, propulsé par LayerZero, atteint des coûts relativement faibles mais prend 10 à 30 minutes pour effectuer les transferts en raison de la nécessité pour son réseau d'opérateurs d'atteindre et de relayer un consensus sur plusieurs chaînes. Across fournit des transferts quasi instantanés mais à des coûts 10 à 100 fois plus élevés, principalement en raison des sorties d'oracle UMA coûteuses et des cycles de rééquilibrage lents (6 heures) qui ont un impact sur l'efficacité de la liquidité.

NFFL introduit ici un nouveau paradigme. En exploitant le framework AVS d'EigenLayer plutôt que de maintenir un réseau d'opérateurs distinct, NFFL peut parvenir à un consensus sur les états de cumul en quelques secondes. Ce consensus peut être efficacement relayé par le biais de contrats de registre sur tous les cumuls participants, ce qui permet des conceptions de ponts qui combinent la rentabilité de Stargate avec une finalité encore plus rapide qu'Across.

Imaginez un utilisateur déplaçant ETH d'Arbitrum vers Base. Lorsque les jetons sont verrouillés dans le contrat de pont sur Arbitrum, les opérateurs NFFL vérifient et attestent rapidement de ce changement d'état via leurs nœuds complets. Une fois que l'agrégateur a collecté suffisamment d'attestations, le contrat de pont sur Base peut immédiatement vérifier le verrouillage du jeton via son contrat de registre et libérer des fonds à l'utilisateur.

Cette vitesse et cette efficacité rendent de nombreuses optimisations de ponts existantes moins pertinentes. Par exemple, les systèmes de ponts basés sur l'intention sont souvent proposés pour contourner la finalité lente - les utilisateurs soumettent des intentions aux jetons de pont, et ces intentions sont mises en correspondance et exécutées par des acteurs spécialisés. Mais avec NFFL fournissant un consensus presque aussi rapidement que la mise en correspondance des intentions, les ponts peuvent à la place utiliser des conceptions de pool de liquidité plus efficaces similaires à Stargate, mais sans ses limitations de vitesse.

Les avantages en termes de coûts sont ici substantiels. Les opérateurs de ponts n'ont pas besoin de maintenir une infrastructure de consensus distincte ou de payer pour des sorties d'oracle coûteuses. Les utilisateurs reçoivent des jetons sur la chaîne de destination en quelques secondes tout en payant principalement les coûts de gaz de base de la vérification. Les fournisseurs de liquidités peuvent gérer les positions plus efficacement avec des cycles de rééquilibrage plus rapides.

En plus, le système maintient une sécurité renforcée grâce aux mécanismes de slashing d'EigenLayer. Toute attestation frauduleuse entraînerait la perte par les opérateurs de leur ETH jalonné, tandis que les ponts peuvent toujours vérifier le règlement final via des ponts canoniques comme couche de sécurité supplémentaire.

Protocole de prêt multi-chaînes

Les prêts inter-chaînes représentent peut-être l’application immédiate la plus convaincante de la NFFL. Les protocoles de prêt actuels sont confrontés à des limitations importantes en raison de la fragmentation de la chaîne. Prenons l’exemple d’Aave : bien qu’il soit déployé sur plusieurs rollups, chaque déploiement fonctionne de manière isolée (ce qui crée plusieurs problèmes).

Les utilisateurs qui souhaitent utiliser des garanties sur plusieurs chaînes doivent relier les actifs et attendre, ce qui fragmente la liquidité et réduit l'efficacité du capital. De plus, certains déploiements sur des rollups plus petits n'ont même pas assez de liquidité pour un prêt significatif, ce qui remet en question la position marketing d'Aave consistant à proposer des prêts simples à tous, quelle que soit leur taille. « Utilisez simplement Aave » pourrait être mieux formulé comme « Utilisez simplement Aave… mais uniquement sur ses plus grands déploiements » dans ce cas.

NFFL permet une approche fondamentalement différente. Imaginez un protocole de prêt qui gère des pools sur plusieurs rollups mais utilise NFFL pour partager l'état des garanties entre eux. Un utilisateur peut déposer des USDC en tant que garantie sur Base, puis emprunter immédiatement des USDT sur Arbitrum contre cette même garantie, même si l'USDT n'est pas du tout déployé sur Base. Le contrat Arbitrum du protocole vérifie simplement la position de garantie de Base via des attestations NFFL, sans qu'aucun pont ne soit requis.

Cela crée de nouvelles possibilités puissantes en matière d'efficacité du capital. Les utilisateurs peuvent accéder aux meilleurs taux sur n'importe quel rollup pris en charge sans déplacer d'actifs. Les fournisseurs de liquidités peuvent déployer du capital là où il est le plus nécessaire sans maintenir des positions distinctes par chaîne. Et comme les positions peuvent être surveillées en temps quasi réel grâce aux attestations NFFL, les protocoles peuvent offrir de meilleurs taux tout en préservant la sécurité.

Les avantages vont au-delà des prêts de base. Envisagez un protocole de trading à effet de levier qui permet aux utilisateurs d'ouvrir des positions sur plusieurs DEX. Un trader pourrait déposer une garantie sur Arbitrum, puis l'utiliser pour ouvrir des positions à effet de levier sur les DEX d'Arbitrum et de Base simultanément. Le protocole peut surveiller toutes les positions via des attestations NFFL, permettant des liquidations rapides si nécessaire tout en donnant aux traders accès aux meilleurs prix sur l'ensemble de l'écosystème.

Ce modèle est considérablement plus simple et plus efficace que les approches existantes. Plutôt que des mécanismes de pont complexes ou des flux de prix centralisés, les protocoles peuvent vérifier directement les positions via des contrats de registre. La finalité rapide de NFFL signifie qu'ils peuvent fonctionner avec des marges de sécurité plus faibles tout en maintenant la sécurité. Et les utilisateurs bénéficient d'une expérience transparente en accédant à la liquidité dans l'ensemble de l'écosystème.

DEX inter-chaînes : déployez une fois, utilisez partout

L'approche actuelle de mise à l'échelle des échanges décentralisés à travers des rollups conduit souvent à des inefficacités absurdes. Lorsque des protocoles comme Uniswap sont déployés sur un nouveau rollup, les utilisateurs sont initialement confrontés à des pools dépourvus de liquidités et manquant de paires de trading critiques.

Prenons l'exemple récent du déploiement d'Uniswap V3 sur ZKsync : malgré l'enthousiasme et le flux de fonds considérables provenant d'un récent largage aérien de ZK, de nombreux pools sont restés inutilisables pendant des jours après le lancement en raison d'une liquidité insuffisante. Pendant ce temps, les déploiements du même protocole sur Arbitrum, Base et d'autres chaînes établies maintiennent une liquidité importante, des frais bas et une tarification efficace pour des milliers de paires.

Cette fragmentation crée des frictions dans tout l'écosystème. Les fournisseurs de liquidités doivent répartir leur capital sur plusieurs chaînes, ce qui entraîne une baisse des prix et un glissement plus important partout. Les utilisateurs doivent relier les jetons et attendre chaque fois qu'ils souhaitent accéder à une meilleure liquidité sur une autre chaîne. Les équipes de protocole doivent gérer plusieurs déploiements, chacun nécessitant une maintenance et une surveillance distinctes.

Vous l'avez deviné : la NFFL permet une approche fondamentalement différente. Explorons cela à travers deux modèles de plus en plus puissants :

Considérez un nouveau DEX déployé exclusivement sur Arbitrum, choisi pour son écosystème DeFi établi et ses coûts de gaz favorables. Plutôt que de lancer des instances distinctes sur plusieurs chaînes, il maintient des pools de liquidité unifiés sur Arbitrum tout en permettant l'accès au trading à partir de n'importe quel rollup.

Voici comment un utilisateur de Base pourrait interagir avec lui :

1. Alice veut échanger 10 000 USDC contre ETH sur Base

2. L'interface de base du DEX interroge l'état du pool Arbitrum via les attestations NFFL

3. Alice voit qu'elle peut obtenir de meilleurs prix que ceux proposés par les pools fragmentés de Base

4. Elle approuve l'échange sur la base

5. La transaction s'exécute sur Arbitrum, avec le résultat attesté à Base

   
   

Les avantages de cette liquidité unifiée sont considérables. Les fournisseurs de liquidités peuvent concentrer leur capital en un seul endroit, ce qui se traduit par une meilleure tarification et une réduction des glissements. L'équipe du protocole n'a besoin de gérer qu'un seul déploiement, ce qui simplifie le développement et réduit les coûts opérationnels. Et les utilisateurs bénéficient d'un accès cohérent à une liquidité importante, quel que soit le cumul qu'ils utilisent.

Un tel protocole pourrait utiliser le modèle de pontage que nous avons exploré plus tôt pour gérer de manière transparente le flux d'échange. En quelques secondes seulement, le fait même de pontage peut être entièrement abstrait. Cela nous rapproche de manière passionnante de la thèse de « l'abstraction de la chaîne » qui est récemment devenue très populaire dans la communauté crypto : si la chaîne sur laquelle vous vous trouvez n'a pas d'importance pour la dapp, pourquoi vous soucieriez-vous de la chaîne sur laquelle vous et toutes ces applications vous trouvez ? Un utilisateur peut simplement se rendre sur le site Web de l'application, connecter son portefeuille et effectuer l'action souhaitée. C'est fait.

Mais NFFL permet un modèle encore plus puissant : encapsuler les protocoles DeFi existants pour un accès inter-chaînes. Au lieu de créer des pools de liquidité concurrents, les développeurs peuvent créer des protocoles « d'aide » qui rendent les pools massifs Uniswap d'Arbitrum accessibles à partir de n'importe quel rollup.

Prenons par exemple Bob qui a besoin d'échanger une paire de jetons à longue traîne sur Base. Actuellement, ses options sont limitées : soit il se connecte à une autre chaîne et attend, soit il accepte un glissement extrême dû à la faible liquidité de Base. Avec un wrapper alimenté par NFFL autour du déploiement Uniswap d'Arbitrum, Bob pourrait :

1. Interrogez la liquidité disponible dans tous les pools Arbitrum Uniswap via les attestations NFFL
2. Trouver une liquidité profonde pour la paire souhaitée dans un pool Arbitrum établi
3. Exécutez la transaction depuis la base via le protocole wrapper
4. Recevez ses jetons sur la base une fois que la NFFL atteste de la fin de l'échange

Ce modèle est transformateur car il transforme les déploiements réussis existants en infrastructure universelle. Au lieu d'attendre des mois ou des années pour que la liquidité s'accumule sur de nouveaux déploiements, les protocoles peuvent instantanément puiser dans des pools établis. Cela permet une efficacité nettement plus efficace du capital et crée une meilleure expérience utilisateur.

Les possibilités vont bien au-delà des simples échanges. Grâce à la vérification de l'état en temps réel de NFFL, les protocoles pourraient offrir des fonctionnalités sophistiquées telles que les ordres à cours limité inter-chaînes. Un utilisateur pourrait passer un ordre à cours limité sur Base contre la liquidité d'Arbitrum, le protocole wrapper surveillant les mouvements de prix via les attestations NFFL et exécutant lorsque les conditions sont remplies.

Ce modèle pourrait remodeler notre façon de concevoir le déploiement des protocoles dans les déploiements. Plutôt que de se déployer automatiquement partout ou de rejoindre les effets de réseau d'une chaîne spécifique, les protocoles pourraient choisir stratégiquement leur chaîne principale en fonction de facteurs tels que :

• Coûts du gaz pour leurs opérations spécifiques
• Pile technologique : machine virtuelle, AA, type de séquençage, DA, etc.
• Considérations réglementaires

Ensuite, grâce à NFFL, ils peuvent toujours servir les utilisateurs dans l’ensemble de l’écosystème de rollup tout en maintenant des opérations plus simples et plus efficaces.

Les implications pour MEV sont également intéressantes. Avec une liquidité unifiée accessible à travers les chaînes, les chercheurs MEV devraient surveiller et interagir avec moins de déploiements. Cela pourrait conduire à une découverte des prix plus efficace et à une meilleure exécution pour les utilisateurs sur tous les rollups.

Comme vous l'avez peut-être déjà remarqué, ce modèle de déploiement à chaîne unique avec accès à plusieurs chaînes via NFFL pourrait s'étendre bien au-delà des DEX. Tout protocole bénéficiant de la profondeur de liquidité ou des effets de réseau pourrait adopter ce modèle : protocoles de prêt, plateformes d'options, marchés NFT, etc. L'idée clé est que NFFL rend l'accès inter-chaînes presque aussi transparent que l'interaction sur la même chaîne, permettant aux protocoles d'optimiser leur stratégie de déploiement sans sacrifier l'accessibilité. En d'autres termes, NFFL fait à nouveau d'Ethereum un écosystème.

Feuille de route et développement futur de Nuffle

Bien que NFFL permette déjà de nouvelles applications inter-chaînes puissantes, le protocole continue d'évoluer. La feuille de route de développement de NFFL se concentre sur trois domaines clés :

Sécurité du protocole

• Mise en œuvre de mécanismes complets de défi et de réduction des pertes via EigenLayer
• Activation de la participation des opérateurs sans autorisation grâce à une gestion robuste des enjeux
• Amélioration de la vérification de l'état inter-chaînes avec des primitives cryptographiques améliorées (BLS→ECDSA)

Évolutivité du réseau

• Optimisation des schémas de signature et de la propagation de l'état
• Améliorer l'efficacité des points de contrôle et les coûts de vérification

Expérience du développeur

• Création d'un SDK et d'outils pour une intégration facile
• Extension de la prise en charge de différents types de cumuls et de machines virtuelles
• Créer de la documentation et des exemples pour des cas d'utilisation courants

Dans les sections suivantes, nous explorerons en détail certaines des améliorations prévues les plus importantes.

Du BLS à l'ECDSA

L’un des changements prévus les plus importants est la transition des signatures BLS vers les signatures ECDSA. Actuellement, NFFL utilise les signatures BLS pour permettre une agrégation efficace : les signatures de plusieurs opérateurs peuvent être combinées en une seule signature qui prouve l’accord de quorum. Bien que cela réduise les coûts de vérification, cela crée des défis pour la gestion des ensembles d’opérateurs dans les chaînes.

Le problème vient du fonctionnement de la vérification de signature BLS. Lors de la vérification d'une signature BLS agrégée, le vérificateur doit utiliser exactement le même ensemble de clés publiques qui l'a créée. Cela signifie que lorsque l'ensemble d'opérateurs change sur Ethereum, tous les cumuls doivent être mis à jour avec exactement le même ensemble d'opérateurs avant de pouvoir vérifier de nouvelles attestations. Même une petite incompatibilité dans les ensembles d'opérateurs entre les chaînes peut empêcher la vérification de la signature et nécessiter la synchronisation de tous les messages de modifications de l'ensemble d'opérateurs.

Les signatures ECDSA, bien que nécessitant plus d'espace et de calcul pour être vérifiées, offrent plus de flexibilité. Les signatures d'opérateurs individuels peuvent être vérifiées indépendamment, ce qui permet des transitions plus fluides lorsque l'ensemble des opérateurs change. Les rollups peuvent vérifier les attestations tant qu'ils reconnaissent les opérateurs signataires, même si leur vision de l'ensemble des opérateurs complets diffère temporairement de celle d'Ethereum. Cette plus grande flexibilité peut valoir la légère augmentation des coûts de vérification.

Ensembles d'opérateurs dynamiques

Ce changement de signature est directement lié à une autre amélioration majeure du protocole : la mise en œuvre d'ensembles d'opérateurs dynamiques. Le système actuel utilise un ensemble d'opérateurs statiques et sur liste blanche. Bien que cela simplifie le développement initial, cela limite la décentralisation et l'évolutivité du protocole.

Un système d'opérateur dynamique permettrait à de nouveaux opérateurs de rejoindre le réseau sans autorisation en jalonnant via EigenLayer. Cela introduit plusieurs défis techniques qui doivent être soigneusement traités :

Tout d'abord, le protocole doit gérer les files d'attente d'entrée et de sortie des opérateurs. Lorsque les opérateurs souhaitent rejoindre ou quitter le réseau, ces changements doivent être coordonnés entre toutes les chaînes participantes. Le système de file d'attente garantit des transitions fluides sans perturber la capacité du réseau à vérifier les attestations.

Deuxièmement, le protocole a besoin de mécanismes pour suivre les performances des opérateurs et le poids des enjeux. À mesure que les opérateurs rejoignent et quittent le système, celui-ci doit conserver des enregistrements précis de l'enjeu de chaque opérateur et de ses droits à participer au consensus. Cela devient plus complexe avec un ensemble dynamique par rapport à l'approche actuelle de la liste blanche.

Enfin, le protocole doit gérer efficacement les mises à jour des opérateurs sur les chaînes. Lorsque l'ensemble des opérateurs change sur Ethereum, ces mises à jour doivent se propager à tous les rollups participants via leurs contrats de registre. La transition ECDSA prévue aidera ici en rendant ces mises à jour plus flexibles.

Enlever les roues d'entraînement

Un autre domaine de développement essentiel est l’activation de mécanismes de contestation et de suppression sans autorisation. Ces mécanismes sont essentiels pour faire respecter un comportement honnête et fournir les garanties de sécurité économique sur lesquelles s’appuie la NFFL.

Le système de contestation s'articule autour du mécanisme de tâche de point de contrôle. Lorsque les opérateurs soumettent des points de contrôle contenant des messages merkleisés d'une période donnée, n'importe qui peut contester ces points de contrôle s'il estime qu'ils contiennent des attestations non valides. Une contestation réussie peut résulter de plusieurs types de défauts :

• Premièrement, les défauts de sécurité qui affectent directement l'intégrité du réseau. Il s'agit notamment des équivoques, où un opérateur signe plusieurs messages contradictoires pour le même cas, comme l'attestation de différentes racines d'état pour le même bloc. Il s'agit également des attestations non valides, où un opérateur valide des transitions d'état ou des mises à jour d'ensemble d'opérateurs manifestement incorrectes.

• Deuxièmement, les défauts de vivacité ont un impact sur la disponibilité du réseau. Si les opérateurs s'abstiennent systématiquement de participer à la signature des messages, cela affecte la capacité du réseau à vérifier efficacement les états. Le mécanisme de contestation doit trouver un équilibre entre la pénalisation de tels comportements et la prise en compte des temps d'arrêt légitimes.

  
  

Le protocole mettra en œuvre un système de contestation basé sur des garanties. Les contestataires doivent bloquer les garanties lors de la soumission d'une contestation, qu'ils perdent si la contestation s'avère invalide. Cependant, s'ils parviennent à prouver une faute de l'opérateur, ils reçoivent une récompense sur la mise de l'opérateur réduit. Cela crée des incitations économiques pour surveiller le comportement des opérateurs tout en empêchant les contestations frivoles.

Pour les mises à jour de la racine de l'état, le processus de contestation est particulièrement intéressant. Une fois qu'un opérateur a attesté de l'état d'un cumul, celui-ci peut être contesté en prouvant soit que les données de bloc pertinentes n'ont pas été correctement publiées sur NEAR DA, soit que l'état attesté ne correspond pas à l'état canonique après le règlement. Cela nécessite que les contestataires fournissent des preuves via le Rainbow Bridge pour la vérification de NEAR DA, créant ainsi plusieurs couches de sécurité.

Le mécanisme de réduction lui-même sera mis en œuvre via les contrats middleware d'EigenLayer. Lorsque les défis réussissent, les opérateurs perdent une partie de leur ETH mis en jeu. Les paramètres de réduction sont conçus de manière à ce que les pertes potentielles dépassent largement les gains provenant d'un comportement malveillant. Une partie de cette mise réduite est attribuée aux challengers qui réussissent, tandis que le reste peut être distribué aux opérateurs honnêtes ou utilisé pour le développement du protocole.

Ces mécanismes créent un cadre de sécurité complet. Les opérateurs s'exposent à des sanctions financières importantes en cas de mauvaise conduite, les challengers sont incités à surveiller le réseau et les applications peuvent s'appuyer sur des garanties cryptoéconomiques soutenues par des ETH remis en jeu. Les périodes de challenge sont beaucoup plus courtes que les preuves de fraude optimistes, tout en offrant une sécurité renforcée grâce aux mécanismes de slashing d'EigenLayer.

L'avenir de la finalité rapide sur Ethereum

Bien que NFFL offre une solution immédiate pour la vérification de l'état de cumul croisé, il convient d'examiner comment le protocole s'intègre dans la feuille de route de mise à l'échelle plus large d'Ethereum. La question clé que beaucoup se posent est la suivante : « NFFL sera-t-il toujours pertinent à mesure que la technologie de cumul progresse ? »

La réponse devient claire lorsque nous examinons les limites fondamentales de règlement dans différentes conceptions de rollups. Les rollups optimistes, malgré leur popularité et leur maturité, ne peuvent fondamentalement pas être réglés plus rapidement que leur fenêtre de protection contre la fraude, généralement 7 jours. Bien que des solutions comme Superchain d'Optimism et Arbitrum Orbit permettent une communication plus rapide entre les rollups partageant un pont, elles ne contribuent pas à l'interopérabilité en dehors de leurs écosystèmes spécifiques, par exemple entre ces deux-là.

Les rollups ZK sont confrontés à des contraintes différentes mais tout aussi importantes. Même si la technologie de preuve ZK s'améliore considérablement, il existe des limites pratiques à la vitesse de règlement. Même si nous atteignons un point où des preuves peuvent être générées pour chaque bloc L1, Ethereum doit toujours avoir la capacité de vérifier plusieurs preuves ZK par bloc sur différents rollups. Lorsque cela deviendra possible, le règlement sera toujours limité par le temps de bloc L1, au moins 12 secondes selon les paramètres actuels.

NFFL propose une approche différente en utilisant des attestations de séquenceur signées à partir de cumuls. Au lieu d'attendre que les lots soient publiés sur L1, les opérateurs NFFL peuvent vérifier et attester des changements d'état dès qu'ils sont produits par le séquenceur. Cela permet une vérification de l'état inter-chaînes en quelques secondes tout en maintenant une sécurité cryptoéconomique solide grâce à EigenLayer.

Il est important de noter que NFFL ne doit pas être considéré comme un concurrent ou une menace pour le modèle de sécurité cumulatif d'Ethereum. Au contraire, il fournit un outil complémentaire qui ouvre de nouvelles possibilités au sein de l'écosystème modulaire d'Ethereum. Les applications peuvent utiliser NFFL pour une vérification rapide de l'état tout en s'appuyant sur le règlement canonique via L1 si nécessaire. Cela crée une boîte à outils plus riche pour les développeurs afin de créer des applications inter-chaînes avec des modèles de sécurité adaptés à leurs besoins spécifiques.

Conclusion

NFFL représente une nouvelle approche pour résoudre l'un des défis les plus urgents de l'écosystème modulaire d'Ethereum : permettre une vérification sécurisée et efficace de l'état de cumul croisé. En exploitant l'ETH re-stadé d'EigenLayer pour la sécurité économique et NEAR DA pour un stockage efficace des données, NFFL crée une couche de finalité rapide qui peut vérifier les états de cumul en quelques secondes plutôt qu'en quelques heures ou jours.

Les choix de conception réfléchis du protocole reflètent une compréhension approfondie des défis de l'infrastructure inter-chaînes. Plutôt que de tenter de remplacer le modèle de sécurité des rollups, NFFL fournit une couche complémentaire optimisée pour des cas d'utilisation spécifiques qui nécessitent une finalité plus rapide. Le système de tâches basé sur des points de contrôle permet un fonctionnement hors chaîne efficace tout en maintenant de solides garanties de sécurité sur la chaîne. Et l'architecture du contrat de registre permet aux rollups de vérifier les états de manière fiable tout en héritant de la sécurité économique de NFFL.

Le plus important est peut-être que NFFL permet une nouvelle génération d'applications inter-chaînes qui étaient auparavant peu pratiques. Des protocoles de prêt unifiés qui partagent les garanties entre les rollups aux wrappers DEX qui rendent la liquidité établie universellement accessible, la vérification rapide de l'état de NFFL crée des éléments de base pour une véritable abstraction de la chaîne. Cela a de profondes implications pour l'efficacité du capital et l'expérience utilisateur dans l'ensemble de l'écosystème.

La feuille de route du protocole démontre un engagement en faveur d'une amélioration continue. Les mises à niveau prévues, comme la transition vers les signatures ECDSA et la mise en œuvre d'ensembles d'opérateurs dynamiques, amélioreront la décentralisation et l'évolutivité. L'activation de mécanismes complets de contestation et de réduction des risques renforcera les garanties de sécurité. Et l'intégration avec d'autres solutions DA au-delà de NEAR rendra NFFL encore plus universel.

Alors que l'écosystème de rollup d'Ethereum continue d'évoluer, le besoin d'une vérification sécurisée de l'état inter-chaînes ne fera que croître. L'approche de NFFL consistant à étendre la sécurité d'Ethereum grâce au retaking tout en optimisant la vitesse et la rentabilité le positionne bien pour répondre à ce besoin. En permettant de nouvelles formes d'interaction inter-chaînes tout en maintenant de solides garanties de sécurité, NFFL contribue à faire de la vision modulaire d'Ethereum une réalité.