Introduction

Avec du recul, les rollups se sont imposés comme la solution d’échelle définitive pour Ethereum et la technologie décentralisée dans son ensemble. Neuf mois après la mise à niveau Dencun d’Ethereum, qui visait l’échelle de disponibilité des données de rollup, le débit des transactions a dépassé…deux cents transactions par secondereprésentant une augmentation de cinq fois depuis le début de l’année. Les deux principaux rollups, Arbitrum et OP Mainnet, ont atteint la décentralisation de la phase 1 -dépassant plusieurs réseaux Layer 1 alternatifs importantsdans les métriques de décentralisation, avec des rollups supplémentaires potentiellement ciblant la décentralisation de la deuxième phase en 2025. La technologie de preuve de connaissance nulle a progressé pour permettre vérification des transactions équivalentes à Ethereum à des coûts inférieurs à un centime, établissant une voie de vérification efficace de milliers de transactions utilisateur 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 découle principalement de la finalisation peu fréquente des rollups, ce qui entrave une communication inter-chaînes significative. De plus, les rollups optimistes, qui hébergent actuellement la majorité de l’activité de l’écosystème et de la valeur totale verrouillée (TVL), font face à des contraintes techniques inhérentes qui empêchent une communication directe en dehors des ponts partagés, créant une barrière significative à l’interopérabilité entre les principaux réseaux tels qu’Arbitrum et Base. La communauté a proposé diverses solutions, allant des ponts basés sur l’intention et des échanges atomiques à une abstraction de chaîne complète. 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 rollups, à la fois rapide et rentable.

Parmi les solutions de premier plan, qui reposent généralement sur des oracles optimistes (Across), un consensus d’opérateurs spécialisés (Stargate via LayerZero) ou une confiance dans un séquenceur centralisé (Polymer Hub), la couche de finalité rapide de Nuffle Labs (NFFL) présente un équilibre convaincant entre efficacité, sécurité et alignement avec Ethereum. Ce document examine l’approche innovante de NFFL pour permettre la vérification de l’état inter-rouleaux grâce au mécanisme de restaking 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.

Votre avantage Ethereum

Obtenez des recherches de première main livrées par notre équipe d’experts.

Votre adresse e-mail

Contexte

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

Les Rollups 101

Un rollup est une chaîne de blocsqui utilise une autre blockchain indépendante pour l’ordonnancement des transactions, la disponibilité des données et le consensus, tout en exécutant les transactions de manière externe de manière vérifiable par la blockchain parente. Alors que de nombreuses définitions font référence à la chaîne parente comme étant la couche 1 (L1) et au rollup comme étant la couche 2 (L2), certains cadres ne nécessitent 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 plus large des L2.

Un exemple de cette distinction - tous les rollups sont des L2, mais tous les L2 ne sont pas nécessairement des rollups. Source: blog.thirdweb.com

Bien sûr, dans notre cas, le parent L1 est la blockchain Ethereum. Il est responsable de partager son consensus avec les rollups (nous expliquerons cela plus tard). Analysons comment les rollups tirent parti d’Ethereum pour leurs fonctions principales: l’ordonnancement des transactions, la disponibilité des données et le consensus.

Ordre des transactions

Les rollups intègrent une entité appelée séquenceur, responsable de la gestion de l’inclusion et de l’ordonnancement 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 séquentiellement les transactions entrantes des utilisateurs, les agrège 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 autorisé de toutes les transactions publiées et de leur ordre. Les nœuds Rollup doivent surveiller ce contrat pour récupérer les nouveaux blocs et les 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 du L1, l’inclusion et l’ordre de toutes les transactions de ce lot sont garanties par les propriétés de sécurité du L1.

Dans une certaine mesure, le séquenceur est un “déclencheur” du rollup - il aide le rollup à accepter réellement de nouvelles transactions dans le réseau, facilitant ainsi la progression de l’état. Certains rollups mettent en œuvre une séquence décentralisée - un ensemble rotatif d’entités spécialisées réduisant le risque d’interruption de service d’un séquenceur centralisé, et une séquence basée sur la source, qui n’utilise aucun séquenceur comme source de confiance avant de publier le lot sur la L1. Au lieu de cela, la séquence basée permet à n’importe qui d’être un séquenceur, mais ses lots ne sont utilisés par les nœuds que lorsqu’ils sont publiés sur la L1. Cela ne présente pratiquement aucun risque d’interruption de la séquence, au prix d’une inclusion de transaction plus lente (le scénario idéal est de 12 secondes par bloc sur la 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 ne «font» pas nécessairement fonctionner le rollup, car leurs actions ne peuvent pas conduire directement à la transition d’état malveillante.

Un démarreur de moteur. Même s’il ne fait pas tourner le moteur, sans lui, le moteur ne fonctionnerait pas non plus. Pensez au rollup comme au moteur et au séquenceur comme au démarreur.

Disponibilité des données

Cependant, les informations sur la commande 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 illimité à toutes les transactions du lot.

Par conséquent, les séquenceurs de rollup doivent publier des données de transaction complètes sur la L1 d’une manière qui permet au contrat intelligent du rollup de vérifierdisponibilité des données. Une fois que les données de transaction pour 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 appels de séquençage de l’input data (calldata) sur la L1. Par conséquent, toutes les transactions devaient être publiées pour toujours sur la blockchain de la L1. 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 la L1 d’Ethereum ne peut pas stocker de grandes quantités de données sur son grand livre, tandis que les rollups, les voies rapides 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 dans le contrat, plutôt que de le reconstruire à partir de toutes les transactions depuis la genèse.

Enshrined Bridge (Consensus)

Pour simplifier, nous avons simplement inversé la définition du rollup à l’envers—habituellement, toutes les explications commencent par un pont bidirectionnel entre le rollup et son L1. Il est assez courant parmi les rollups d’utiliser la devise native de L1 comme la leur, pour simplifier l’estimation des frais de gaz en fonction des dépenses des séquenceurs et des proposants. De plus, de nombreux rollups veulent obtenir des jetons populaires dans leur écosystème dès le premier jour, pour lesquels les ponts depuis leur L1 sont le meilleur choix.

Implémenter un contrat intelligent de pont de L1 vers le rollup est assez simple - les nœuds rollup écoutent déjà tout ce qui se passe dans leur contrat, nous pouvons donc mettre en œuvre une fonction de dépôt de L1 que tous les nœuds interpréteront comme une commande pour émettre le token “wrapped” correspondant sur le rollup lui-même.

Cependant, les retraits sans confiance nécessitent que le contrat de pont valide toutes les transactions rollup 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 de rollup - les nœuds s’alignent sur la transition d’état du pont indépendamment des forks de chaîne alternatives. Contrairement aux chaînes de blocs traditionnelles, les rollups 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.

Blobs

La mise à niveau Dencun d’Ethereum en mars dernier a introduit des «blobs» - des cellules temporaires de données 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 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 calldata vers les blobs peu de temps après la mise à niveau. En termes de chiffres, avant Dencun, le TPS total des rollups était d’environ 50. Aujourd’hui, il dépasse les 200, avec des limites théoriques à400-800 TPS en fonction du rollup.

Source: L2BEAT

Au-delà des améliorations de capacité, les blobs ont éliminé l’obligation de payer les coûts de gaz EVM pour le stockage de données de transaction, établissant un canal distinct 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 centime dans des réseaux tels que Base.

Source: growthepie.xyz

Règlement Rollup

Alors que les séquenceurs gèrent l’ordre et la publication des transactions, ils ne représentent qu’un seul composant de l’architecture rollup. Les rollups intègrent également des entités appelées “proposants” responsables 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 rollup, telle que sa machine virtuelle.

Le rôle du demandeur varie considérablement en fonction de l’approche de validation de l’état du rollup. Deux méthodologies fondamentalement différentes existent, définissant deux catégories de rollups : Optimiste et Zero-Knowledge (ZK).

Optimistic Rollups

Dans les rollups optimistes, les proposants soumettent régulièrement des mises à jour de l’état au pont L1, généralement aux côtés ou peu de temps après les publications groupées du séquenceur. Ces mises à jour de l’état incluent la nouvelle racine de l’état (un engagement cryptographique de l’ensemble du nouvel état du rollup) après l’exécution de toutes les transactions dans les derniers lots.

Pour éviter les mises à jour d’état invalides, le pont met en œuvre une période de défi (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 avec succès qu’un proposant a soumis une transition d’état invalide, la sortie de l’état est annulée et le challenger est récompensé (souvent à partir d’une caution que les proposants doivent verser). Cela crée un jeu économique où les proposants sont incités à soumettre uniquement des transitions d’état valides.

Zero-Knowledge Rollups

Dans les rollups ZK, les proposants génèrent des preuves mathématiques (appelées « preuves de validité » ou, plus techniquement, « preuves ZK ») qui démontrent la justesse 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 rollup sans révéler les détails spécifiques de leur exécution.

Le pont L1 peut rapidement vérifier 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 de l’état comme étant réglée. Cela signifie que les proposants doivent effectuer un travail de calcul significatif avant de soumettre des mises à jour d’état, mais ces mises à jour sont réglées beaucoup plus rapidement par rapport aux rollups optimistes.

Règlement, Finalité et Interopérabilité

Le temps de règlement à travers les ponts canoniques varie considérablement entre les types de rollups, allant de 7 jours pour les rollups optimistes en raison de leur période de contestation, à plusieurs heures pour les rollups ZK en raison des coûts de génération de preuves et 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 une friction significative pour l’écosystème DeFi plus large.

Considérez comment cela impacte l’utilisation réelle : un utilisateur qui souhaite utiliser sa garantie basée sur Arbitrum pour contracter un prêt sur Base doit d’abord transférer 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 y agir. Une application de jeu souhaitant permettre aux joueurs d’échanger des objets entre différents déploiements de rollup se heurterait à une mauvaise expérience utilisateur avec de tels retards importants.

L’astuce cruciale ici est que les nœuds de rollup peuvent réellement observer les changements d’état beaucoup plus rapidement, généralement dans les secondes suivant la confirmation du bloc L1. Bien que cet état n’ait pas encore fait l’objet d’un 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 nombreux échanges centralisés exploitent déjà cette propriété, créditant les dépôts des utilisateurs à partir des rollups 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 du rollup. Bien que les rollups aient réussi à augmenter 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 qu’ils tirent tous leur sécurité de la même chaîne sous-jacente : Ethereum.

Solutions Existantes

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 différents compromis entre trois propriétés clés:

• Sécurité - À quel point les garanties que la vérification de l’état est correcte sont-elles solides
• Vitesse - À quelle vitesse l’état peut être vérifié à travers les chaînes
• Coût - Combien cela coûte-t-il de maintenir et d’utiliser la solution

La plupart des solutions existantes optimisent la vitesse et les coûts au détriment de la sécurité - s’appuyant souvent sur des opérateurs de confiance, des multisignatures ou des mécanismes optimistes avec un soutien économique minimal. Cela a conduit à plusieurs piratages de ponts de haut niveau, notamment l’exploit du pont Ronin de 625 millions de dollars, mettant en évidence les risques de sacrifier la sécurité pour la commodité.

Le défi fondamental consiste à établir une « source de vérité » sécurisée sur les états de rollup qui peut :

• Vérifiez les changements d’état en quelques secondes ou minutes au lieu de quelques heures ou jours
• Fournir de solides garanties de sécurité cryptéconomique
• Fonctionner de manière rentable à la fois pour les fournisseurs d’infrastructure et les utilisateurs
• Intégrez-vous parfaitement aux architectures rollup existantes

Cette opportunité de permettre une vérification sécurisée et rapide de l’état entre les rollups a suscité une innovation significative. Diverses équipes abordent le problème sous différents angles, cherchant à créer une infrastructure qui peut 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 combinaison novatrice du restaking d’EigenLayer et de NEAR DA, créant ainsi une couche de finalité rapide qui trouve un équilibre judicieux entre sécurité, vitesse et efficacité coûts.

NFFL Deep Dive

Thèse centrale

La couche de finalité rapide Nuffle (NFFL) représente une approche novatrice pour permettre des interactions sécurisées entre chaînes en fournissant une vérification rapide de l’état entre les rollups. Au lieu de contraindre les développeurs à choisir entre sécurité et vitesse, NFFL exploite les ETH restakés d’EigenLayer pour créer une couche de finalité rapide sécurisée sur le plan cryptographique qui peut attester des états des rollups en quelques secondes.

Au cœur de NFFL, fonctionne un service de validation active (AVS) s’exécutant 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 les mises à jour d’état. Ces attestations sont soutenues par les ETH restakés des opérateurs, créant de solides incitations économiques en faveur d’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 de manière sécurisée l’état inter-chaînes en 2 à 3 secondes - des ordres de grandeur plus rapides que le règlement de pont canonique.

Architecture de conception simplifiée de NFFL

Ce qui rend NFFL particulièrement attrayant, 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 nécessitant une finalité plus rapide. Les applications peuvent choisir de s’appuyer sur la sécurité cryptéconomique de NFFL ou d’attendre un 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 entre chaînes tout en garantissant une sécurité optimale.

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 rollup 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 les points de contrôle qui permet l’agrégation et la vérification efficaces des attestations des opérateurs tout en maintenant la responsabilité grâce aux mécanismes de réduction de la couche Eigen.
3. Un mécanisme de stockage de données utilisant NEAR DA permettant la récupération facile de données de rollup attestées sur tous les rollups

Cette conception permet à NFFL de trouver un équilibre délicat entre la sécurité, la rapidité et la rentabilité - trois propriétés qui ont traditionnellement été en conflit dans l’infrastructure 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é.

Dans les sections suivantes, nous explorerons en détail l’architecture de NFFL, examinant comment ses différents composants travaillent ensemble pour permettre cette nouvelle primitive pour l’interaction entre 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.

Composants principaux

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 rapide entre les Rollups. Au lieu de créer un autre réseau cloisonné nécessitant ses propres hypothèses de sécurité, NFFL est construit comme un service validé activement (AVS) sur EigenLayer, ce qui lui permet de se connecter directement à l’écosystème de validateurs 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 réinvestir leur ETH via EigenLayer pour devenir des opérateurs NFFL. Ce faisant, ils mettent leur ETH mis en jeu en danger pour soutenir leurs déclarations sur les états de rollup. Cela crée un puissant lien de sécurité entre le consensus d’Ethereum et la couche de finalité rapide de NFFL.

Lorsqu’un rollup publie de nouvelles données de bloc sur le L1, les relayers 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 rollup 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 rollup, les opérateurs les exécutent dans leurs nœuds de rollup. Étant donné qu’ils exécutent tous le même logiciel de nœud, ils apparaîtront toujours avec la même sortie d’état, correcte. Cette sortie d’état est ensuite signée par tous les opérateurs. Lorsque la majorité des opérateurs s’accorde sur un état spécifique, il est accepté par le système et peut être transmis aux contrats de registre sur tous les rollups.

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 réduction d’EigenLayer :

Dans EigenLayer, les Services Activement Validés peuvent mettre en place un mécanisme de vérification capable de détecter les attestations invalides des opérateurs et de réduire (liquider) leur dépôt par la suite. Comme NFFL « règle préliminairement » l’état de rollup 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 toute incohérence de sortie entre l’attestation et le pont. Cela dissuade économiquement les attestations frauduleuses, car elles peuvent être détectées et réduites par toute entité surveillant l’état L1 et NFFL, même sans exécuter de nœuds de rollup. En d’autres termes, NFFL « assure » les revendications du réseau - les opérateurs prennent un risque financier important pour étayer leurs affirmations concernant les états de rollup.

Ce qui rend cela particulièrement puissant, c’est la manière dont il aligne les incitations à travers le système. Les opérateurs gagnent des frais pour leur participation honnête tout en risquant des pertes importantes en cas de malhonnêteté. Plus il y a d’ETH réinvestis dans NFFL, plus ces incitations deviennent fortes. Et parce que cette sécurité est dérivée d’Ethereum grâce à EigenLayer, elle bénéficie en partie du même modèle de sécurité économique robuste qui sécurise 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 la gestion de la vérification de l’état inter-chaînes à grande échelle. Au lieu d’enregistrer chaque attestation d’état on-chain, ce qui serait prohibitif, NFFL introduit un système à deux couches de Messages et de Tâches qui permet un fonctionnement efficient hors chaîne tout en maintenant de solides garanties de sécurité on-chain sur demande.

Les messages sont l’unité de base de communication 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 y a 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 concernant l’état d’un rollup à une hauteur de bloc spécifique. Chaque message comprend non seulement la racine d’état elle-même, mais aussi une référence à la transaction NEAR DA contenant les données du 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 de l’ensemble des opérateurs de NFFL. Ces Messages sont essentiels pour la sécurité du système car ils permettent aux contrats de registre rollup de maintenir un enregistrement à jour des opérateurs valides, garantissant que seules les attestations des participants autorisés disposant d’une participation à risque sont acceptées.

Bien que les Messages permettent une vérification efficace de l’état, ils ne sont pas suffisants pour garantir la sécurité économique du système. C’est là que les Tâches interviennent. Les Tâches sont des unités de travail sur chaîne qui checkpointent l’état du système à des intervalles réguliers. Au lieu de soumettre chaque Message à Ethereum, les opérateurs construisent périodiquement un Arbre de Merkle Épars contenant tous les Messages d’une période spécifique. La racine de cet arbre est ensuite soumise en tant que réponse de Tâche, créant un engagement efficace sur chaîne à toutes les attestations hors chaîne.

Ce système de point de contrôle est particulièrement ingénieux car il permet la vérification sélective de tout Message sans exiger que tous les Messages soient stockés on-chain. Grâce aux preuves de Merkle, n’importe qui peut vérifier qu’un Message spécifique a été inclus dans un point de contrôle, permettant des mécanismes de défi efficaces tout en maintenant les coûts de base bas. Vous pouvez le considérer comme la création d’un “blockchain d’attestations” où les points de contrôle servent de en-têtes de bloc qui s’engagent à tous les Messages dans une période de temps.

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 un quorum (pondéré par l’ETH mis en jeu) avant de les rendre disponibles pour une utilisation par les applications. Cela crée une interface propre pour les développeurs tout en maintenant les propriétés de sécurité décentralisées du système. Nous expliquerons le service d’agrégation plus en détail dans la section suivante.

Service d’agrégation

L’agrégateur agit comme la 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.

Au cœur de l’agrégateur se trouve la résolution du problème de la tragédie des communs dans l’agrégation de signatures. Sans un 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 unique de collecte pour les signatures d’opérateurs, vérifie le quorum et expose les attestations vérifiées via une API simple.

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

• Les opérateurs signent indépendamment des 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 des enjeux 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 intégrant NFFL. Au lieu de gérer des opérations cryptographiques complexes ou de suivre les enjeux de l’opérateur, 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 des signatures, de la vérification et de l’agrégation BLS en arrière-plan.

Aggrégation de signatures

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

Les gains d’efficacité ici sont importants. 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 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 de signature, pondérées par leurs montants misés pour garantir que la sécurité économique est correctement prise en compte. Le contrat d’enregistrement n’a ensuite besoin que d’effectuer une seule opération de vérification de signature pour confirmer que suffisamment de poids de mise a attesté de la mise à jour de l’état.

Aggregator et Points de contrôle

Il est important de noter que, bien que l’agrégateur offre de la commodité, il ne compromet pas le modèle de sécurité de NFFL. Les signatures qu’il collecte sont publiquement vérifiables et son rôle est purement organisationnel plutôt qu’autoritaire. Les applications peuvent toujours vérifier indépendamment que les signatures agrégées représentent un quorum légitime d’opérateurs engagés. L’agrégateur ne peut ni falsifier les signatures ni cacher des attestations valides, il les rend simplement plus accessibles.

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

Contrats de registre

Le contrat de registre, déployé sur chaque rollup participant, sert de pont critique entre les attestations hors chaîne de NFFL et la vérification de l’état sur chaîne. Ces contrats permettent aux applications de vérifier de manière fiable l’état d’autres rollups en validant les attestations sécurisées cryptographiquement de NFFL.

Ce qui rend le Registre particulièrement intéressant, c’est la manière 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 des opérateurs de NFFL, en suivant les modifications par le biais des attestations de mise à jour de l’ensemble des opérateurs. Cela signifie que, bien que l’ensemble des opérateurs soit géré par EigenLayer sur Ethereum, son état est fidèlement reflété sur tous les rollups participants, leur permettant de vérifier indépendamment les attestations.

Lorsqu’une application doit vérifier l’état d’un autre rollup - par exemple, un protocole de prêt vérifiant le collatéral sur Arbitrum à partir d’Optimism - elle soumet l’attestation pertinente à son contrat de Registre local. Cette attestation comprend la signature BLS agrégée que nous avons discutée précédemment, ainsi que la racine d’état spécifique faisant l’objet de l’attestation et sa référence de transaction DA NEAR 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 contre les clés publiques pondérées de l’ensemble actuel d’opérateurs. 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 rollups qui est à la fois sécurisé et rentable.

Le Registre crée un pont entre les rollups, minimisant la confiance, à la fois sécurisé et rentable. En vérifiant les signatures agrégées par rapport aux clés publiques pondérées de l’ensemble des opérateurs, il peut confirmer qu’une mise à jour de l’é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 à travers différents rollups 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 NFFL. Si une attestation est ultérieurement prouvée frauduleuse grâce au système de contestation, le registre peut l’invalider, protégeant les applications contre la dépendance à un état incorrect. Cela crée plusieurs couches de sécurité - des garanties cryptoeconomiques immédiates provenant d’ETH mis en jeu combinées à une protection contre la fraude à plus long terme grâce à des contestations.

Classification des défauts & Conception de sécurité

Le modèle de sécurité de NFFL se concentre sur la détection et la sanction de deux types principaux de comportements incorrects de l’opérateur : les défaillances de sécurité et les défaillances de vivacité.

Les défaillances de sécurité sont des violations qui affectent l’intégrité du réseau en produisant des états incorrects ou des résultats incohérents par rapport aux règles du système. Il existe deux types clés de défaillances 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, signer des attestations pour différents états racines au même niveau de bloc, ou attester de plusieurs horodatages différents pour le même bloc. Un tel comportement mine la capacité du réseau à parvenir à un consensus sur l’état canonique.
• L’attestation invalide se produit lorsqu’un opérateur signe une déclaration de manière probante incorrecte. Cela pourrait attester d’une mise à jour de l’ensemble de l’opérateur qui ne correspond pas au delta de l’état on-chain, ou 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 de manière objective grâce aux données on-chain.

Alors que les défauts de sécurité attaquent directement la correction, les défauts 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 a un impact à la fois sur 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 grâce aux tâches de point de contrôle afin d’identifier et de sanctionner ce comportement.

Le processus de défi 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 soit des fautes d’inclusion de message, soit des fautes d’exclusion. 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 invalide/hors période a été inclus, le défi réussit. Cela est vérifié à l’aide de preuves de Merkle contre l’arbre de messages du point de contrôle.

Les messages individuels peuvent être contestés après leur période de vérification en prouvant que le contenu du message était invalide. Par exemple:

• Les messages de mise à jour de l’ensemble d’opérateurs peuvent être invalidés en montrant l’ID de mise à jour revendiqué ou si le delta de l’opérateur ne correspond pas à l’état en chaîne.
• Les messages de mise à jour de l’état racine 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 à plusieurs niveaux permet au protocole de maintenir à la fois une opération rapide grâce à des messages hors chaîne tout en préservant de solides garanties de sécurité grâce à des mécanismes cryptographiques. En rendant le comportement invalide détectable de manière prouvable et économiquement punissable grâce à la suppression de EigenLayer, NFFL crée de solides incitations à une opération honnête tout en permettant des défis efficaces lorsque des violations se produisent.

Exemples de flux du monde réel

En établissant un moyen de lecture d’état transversal rapide et bon marché pour les rollups, NFFL ouvre un large éventail d’applications qui n’étaient pas réalisables avec la pile technologique actuelle de l’écosystème. Explorons certaines idées, d’un concept 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 “bonjour” entre différents rollups. Bien que basique, cela démontre les mécanismes de base de la façon dont les applications peuvent exploiter NFFL pour la communication entre chaînes.

Considérons 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 “hello !” 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 l’établissement du pont canonique (potentiellement plusieurs heures ou jours) avant de pouvoir être vérifié par d’autres rollups.

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

Ces attestations circulent à travers le service d’agrégation de NFFL, qui recueille des signatures jusqu’à ce que suffisamment de poids de mise en jeu ait attesté de l’état. Une fois le quorum atteint, la signature agrégée devient disponible via l’API de NFFL, généralement dans les secondes qui suivent la production du bloc d’origine.

Maintenant vient la partie intéressante - consommer le 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 #1
• L’attestation NFFL prouvant que cet État est valide
• Une référence à la transaction NEAR DA contenant les données de bloc

Le protocole routera ces données vers le contrat d’enregistrement 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, permettant ainsi au protocole de le traiter en toute sécurité.

Ce qui rend cela puissant, c’est sa combinaison de vitesse et de sécurité. Tout le processus, de l’envoi du message à la vérification inter-chaînes, peut être terminé en quelques secondes, au lieu de plusieurs heures ou jours avec des ponts canoniques. Mais la sécurité est garantie par des garanties cryptonomiques soutenues par des ETH reposés via EigenLayer, plutôt que paropérateurs de confianceou des hypothèses optimistes.

Bien que l’envoi de messages “hello” puisse sembler trivial, ce même modèle permet des applications inter-chaînes beaucoup plus sophistiquées. La capacité de vérifier rapidement et sans confiance l’état entre les rollups crée des éléments de base pour tout, des applications DeFi inter-chaînes aux expériences utilisateur abstraites de la chaîne.

Pontage de jetons rapide et bon marché

En s’appuyant sur ces fondamentaux, explorons une application plus pratique : un pont de jeton exploitant NFFL pour des transferts rapides entre rollups croisés. Le paysage actuel des ponts force des compromis difficiles entre vitesse, coût et sécurité. Examinons comment NFFL peut remodeler ces dynamiques.

Les principaux ponts d’aujourd’hui illustrent clairement ces compromis. Stargate, alimenté par LayerZero, permet d’obtenir des coûts relativement bas mais prend 10 à 30 minutes pour effectuer des transferts en raison du besoin pour son réseau d’opérateurs de parvenir à un consensus et de le relayer sur plusieurs chaînes. Across permet 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 impactent l’efficacité de la liquidité.

NFFL introduit un nouveau paradigme ici. En exploitant le framework AVS d’EigenLayer au lieu de maintenir un réseau d’opérateurs séparé, NFFL peut parvenir à un consensus sur les états de rollup en quelques secondes. Ce consensus peut être efficacement relayé via des contrats de registre sur tous les rollups participants, permettant des conceptions de pont qui combinent l’efficacité des coûts de Stargate avec une finalité encore plus rapide que Across.

Considérez un utilisateur déplaçant de l’ETH d’Arbitrum vers Base. Lorsque les jetons sont verrouillés dans le contrat de pont sur Arbitrum, les opérateurs NFFL vérifient rapidement et attestent ce changement d’état via leurs nœuds complets. Une fois que l’agrégateur collecte 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 les fonds à l’utilisateur.

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

Les avantages économiques sont considérables ici. Les opérateurs de pont n’ont pas besoin de maintenir une infrastructure de consensus distincte ni de payer 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 vérification. Les fournisseurs de liquidité peuvent gérer les positions de manière plus efficace avec des cycles de rééquilibrage plus rapides.

En plus de ces avantages, le système maintient une sécurité renforcée grâce aux mécanismes de suppression d’EigenLayer. Toute attestation frauduleuse entraînerait la perte des ETH mis en jeu par les opérateurs, tandis que les passerelles peuvent toujours vérifier le règlement final via des passerelles canoniques comme une 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 limites importantes en raison de la fragmentation de la chaîne. Prenons l’exemple d’Aave : bien qu’il soit déployé sur plusieurs cumuls, chaque déploiement fonctionne de manière isolée. 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és pour des prêts significatifs, ce qui remet en question la position marketing d’Aave en matière de prêts simples pour tous, quelle que soit leur taille. « Il suffit d’utiliser Aave. » … mais uniquement sur ses plus grands déploiements.

NFFL permet une approche fondamentalement différente. Considérez un protocole de prêt qui maintient des pools sur plusieurs rollups mais utilise NFFL pour partager l’état du collatéral entre eux. Un utilisateur pourrait déposer du USDC comme collatéral sur Base, puis emprunter immédiatement du USDT sur Arbitrum contre ce même collatéral, même si USDT n’est pas du tout déployé sur Base. Le contrat Arbitrum du protocole vérifie simplement la position du collatéral Base grâce aux attestations NFFL, sans nécessité de pontage.

Cela crée de nouvelles possibilités puissantes en termes d’efficacité du capital. Les utilisateurs peuvent accéder aux meilleurs taux sur n’importe quelle rollup prise en charge sans déplacer les actifs. Les fournisseurs de liquidité peuvent déployer du capital là où il est le plus nécessaire sans avoir à maintenir des positions distinctes par chaîne. Et parce que les positions peuvent être surveillées en temps réel grâce aux attestations NFFL, les protocoles peuvent offrir de meilleurs taux tout en maintenant la sécurité.

Les avantages vont au-delà du simple prêt. Considérez 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 à la fois sur les DEX d’Arbitrum et de Base simultanément. Le protocole peut surveiller toutes les positions grâce aux attestations NFFL, permettant des liquidations rapides si nécessaire tout en donnant aux traders accès aux meilleurs prix dans l’ensemble de l’écosystème.

Ce modèle est nettement plus simple et plus efficace que les approches existantes. Au lieu de mécanismes de pont complexes ou de 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 fluide pour accéder à la liquidité dans l’ensemble de l’écosystème.

Cross-DEX: Déployez une fois, utilisez partout

L’approche actuelle de mise à l’échelle des échanges décentralisés sur les rollups conduit souvent à des inefficacités absurdes. Lorsque des protocoles tels que Uniswap se déploient sur un nouveau rollup, les utilisateurs sont initialement confrontés à des pools dépourvus de liquidité et à des paires d’échange essentielles manquantes. Considérons le déploiement récent d’Uniswap V3 sur ZKsync - malgré l’excitation significative et l’afflux de fonds d’une récente distribution de jetons ZK, de nombreux pools sont restés inutilisables pendant plusieurs 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é profonde, des frais réduits et des prix efficaces 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 différentes chaînes, ce qui entraîne une tarification moins avantageuse et une glissement plus élevé partout. Les utilisateurs doivent effectuer des ponts de jetons et attendre chaque fois qu’ils veulent accéder à une meilleure liquidité sur une autre chaîne. Les équipes de protocole doivent gérer plusieurs déploiements, nécessitant chacun une maintenance et une surveillance distinctes.

Vous l’avez deviné : NFFL permet une approche fondamentalement différente encore. Explorons cela à travers deux schémas 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. Au lieu de lancer des instances séparées sur différentes chaînes, il maintient des pools de liquidité unifiés sur Arbitrum tout en permettant l’accès aux échanges depuis n’importe quel rollup. Voici comment un utilisateur sur Base pourrait interagir avec lui:

1. Alice souhaite échanger 10 000 USDC contre ETH sur Base
2. L’interface de base du DEX interroge l’état du pool Arbitrum via des attestations NFFL
3. Alice voit qu’elle peut obtenir de meilleurs prix que les pools fragmentés de Base
4. Elle approuve l’échange sur Base
5. La transaction s’exécute sur Arbitrum, avec le résultat attesté de retour à Base

Les avantages de cette liquidité unifiée sont considérables. Les fournisseurs de liquidité peuvent concentrer leur capital en un seul endroit, ce qui entraîne une meilleure tarification et une glissement plus faible. 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 ont un accès constant à une liquidité profonde, quel que soit le rollup qu’ils utilisent.

Un tel protocole pourrait utiliser le modèle de pont que nous avons exploré précédemment pour gérer de manière transparente le flux d’échange. En quelques secondes seulement, le fait réel du pont peut être entièrement abstrait. Cela nous rapproche de manière excitante de la thèse de l’abstraction de la chaîne qui est récemment devenue très populaire dans la communauté crypto : si cela n’a pas d’importance pour l’application décentralisée sur quelle chaîne vous êtes, pourquoi vous soucier de la chaîne sur laquelle vous et toutes ces applications êtes ? Un utilisateur peut simplement se rendre sur le site de l’application, connecter son portefeuille et effectuer l’action souhaitée. C’est fait.

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

Déploiements Uniswap avec la plus grande TVL. Base et Arbitrum sont en tête du classement, Optimism ayant une TVL 6 fois plus petite que l’un ou l’autre, et d’autres cumuls relevant de la catégorie « Autres ». Source: DefiLlama

Par exemple, considérez Bob qui a besoin d’échanger une paire de jetons à longue traîne sur Base. Actuellement, ses options sont limitées : soit passer à une autre chaîne et attendre, soit accepter un glissement extrême de la liquidité maigre de Base. Avec un wrapper alimenté par NFFL autour du déploiement d’Uniswap d’Arbitrum, Bob pourrait :

1. Interroger la liquidité disponible dans tous les pools Arbitrum Uniswap via les attestations NFFL
2. Trouvez une liquidité profonde pour sa paire souhaitée dans un pool Arbitrum établi
3. Exécutez la transaction de Base via le protocole wrapper
4. Recevoir 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 que la liquidité se développe sur de nouvelles solutions de mise à l’échelle, les protocoles peuvent instantanément puiser dans des pools établis. Cela est beaucoup plus efficace en termes de capitaux et crée une meilleure expérience utilisateur.

Les possibilités vont bien au-delà des échanges simples. 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 des ordres limites inter-chaînes. Un utilisateur pourrait passer un ordre limite sur Base contre la liquidité d’Arbitrum, le protocole enveloppant surveillant les mouvements de prix grâce aux attestations NFFL et exécutant l’ordre lorsque les conditions sont remplies.

Ce modèle pourrait remodeler notre façon de penser au déploiement de protocoles à travers les rollups. Plutôt que de 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 de 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 de l’ensemble de l’écosystème 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 de MEV auraient besoin de surveiller et d’interagir avec moins de déploiements. Cela pourrait conduire à une découverte plus efficace des prix et à une meilleure exécution pour les utilisateurs de tous les cumuls.

Comme vous l’avez peut-être déjà remarqué, ce modèle de déploiement à chaîne unique avec un accès multi-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, places de marché NFT, et plus encore. L’élément clé est que NFFL rend l’accès multi-chaînes presque aussi transparent que l’interaction intra-chaîne, permettant aux protocoles d’optimiser leur stratégie de déploiement sans sacrifier l’accessibilité. En d’autres termes, NFFL rend Ethereum à nouveau un écosystème.

Feuille de route et développement futur

Alors que NFFL permet déjà de puissantes nouvelles applications inter-chaînes, 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 à travers EigenLayer
• Activation de la participation d’opérateurs sans autorisation avec 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 réduire les coûts de vérification

Expérience de développement

• Construction de SDK et d’outils pour une intégration facile
• Expansion du support pour différents types de rollup et machines virtuelles
• Création de documentation et d’exemples pour des cas d’utilisation courants

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

BLS à ECDSA

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

Le problème vient de la façon dont fonctionne la vérification de la 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’ont créée. Cela signifie que lorsque l’ensemble des opérateurs change sur Ethereum, tous les rollups doivent se mettre à jour avec le même ensemble d’opérateurs avant de pouvoir vérifier de nouvelles attestations. Même une petite différence d’ensemble d’opérateurs entre les chaînes peut empêcher la vérification des signatures et nécessiter la synchronisation de tous les messages de changement d’ensemble d’opérateurs.

Les signatures ECDSA, bien qu’elles nécessitent plus d’espace et de calcul pour être vérifiées, offrent plus de flexibilité. Les signatures individuelles des opérateurs peuvent être vérifiées de manière indépendante, 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 de signature, même si leur vision de l’ensemble complet des opérateurs 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, à savoir la mise en œuvre de jeux d’opérateurs dynamiques. Le système actuel utilise un ensemble d’opérateurs statique et autorisé. Bien que cela ait simplifié le développement initial, cela limite la décentralisation et la scalabilité du protocole.

Un système d’opérateur dynamique permettrait à de nouveaux opérateurs de rejoindre le réseau sans permission en misant à travers EigenLayer. Cela présente plusieurs défis techniques qui doivent être soigneusement abordé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 sur l’ensemble des 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 la performance de l’opérateur et le poids de la mise. À mesure que les opérateurs rejoignent et quittent le système, celui-ci doit maintenir des registres précis de la mise de chaque opérateur et de ses droits de 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 de l’ensemble des opérateurs entre 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 prévue vers ECDSA aidera ici en rendant ces mises à jour plus flexibles.

Enlever les roulettes

Une autre zone critique de développement est l’activation de mécanismes de défi et de réduction de l’autorisation. Ces mécanismes sont essentiels pour garantir un comportement honnête et fournir les garanties de sécurité économique sur lesquelles NFFL repose.

Le système de défi repose sur le 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 sur une période de temps, tout le monde peut contester ces points de contrôle s’ils estiment qu’ils contiennent des attestations invalides. Un défi réussi peut résulter de plusieurs types de fautes :

• Tout d’abord, les failles de sécurité qui affectent directement l’intégrité du réseau. Il s’agit notamment de l’équivoque, où un opérateur signe plusieurs Messages contradictoires pour le même cas, comme attester de différentes racines d’état pour le même bloc. Elles incluent également des attestations invalides, où un opérateur signe des transitions d’état incorrectes ou des mises à jour de l’ensemble des opérateurs qui peuvent être prouvées comme incorrectes.
• Deuxièmement, les pannes de vivacité qui affectent la disponibilité du réseau. Si les opérateurs s’abstiennent systématiquement de participer à la signature de messages, cela affecte la capacité du réseau à vérifier efficacement les états. Le mécanisme de défi doit être en mesure de punir un tel comportement tout en tenant compte des temps d’arrêt légitimes.

Le protocole mettra en œuvre un système de défi basé sur des garanties. Les challengers doivent bloquer des garanties lorsqu’ils soumettent un défi, qu’ils perdent si le défi s’avère invalide. Cependant, s’ils parviennent avec succès à 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 de l’opérateur tout en empêchant les défis 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 atteste de l’état d’un cumul, cela peut être contesté en prouvant soit que les données de bloc pertinentes n’ont pas été correctement publiées dans NEAR DA, soit que l’état attesté ne correspond pas à l’état canonique après le règlement. Cela oblige les challengers à fournir des preuves via le Rainbow Bridge pour la vérification NEAR DA, créant ainsi plusieurs couches de sécurité.

Le mécanisme de réduction lui-même sera mis en œuvre à travers 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 telle sorte que les pertes potentielles dépassent considérablement tout gain provenant d’un comportement malveillant. Une partie de cette mise réduite est attribuée aux challengers réussis, tandis que le reste pourrait ê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 encourent des sanctions financières importantes en cas de mauvais comportement, les challengers sont incités à surveiller le réseau, et les applications peuvent compter sur des garanties cryptographiques soutenues par des ETH réinvestis. Les périodes de défi sont beaucoup plus courtes que les preuves de fraude des rollups optimistes, tout en offrant une sécurité solide grâce aux mécanismes de réduction d’EigenLayer.

Avenir de la rapidité de finalité

Bien que NFFL offre une solution immédiate pour la vérification de l’état cross-rollup, il est intéressant d’examiner comment le protocole s’inscrit dans la feuille de route de mise à l’échelle plus large d’Ethereum. La question clé que beaucoup se posent est : « NFFL restera-t-il pertinent à mesure que la technologie rollup évolue ? »

La réponse devient claire lorsque nous examinons les limitations fondamentales de règlement dans les différents designs de rollup. Les rollups optimistes, malgré leur popularité et leur maturité, ne peuvent pas se régler fondamentalement plus rapidement que leur fenêtre de preuve de fraude - typiquement 7 jours. Bien que des solutions telles que le Superchain d’Optimism et l’Arbitrum Orbit permettent une communication plus rapide entre les rollups partageant un pont, ils n’aident pas à l’interopérabilité en dehors de leurs écosystèmes spécifiques - par exemple, entre ces deux derniers.

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 en matière de 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 encore avoir la capacité de vérifier plusieurs preuves ZK par bloc à travers différents rollups. Lorsque cela deviendra possible, le règlement sera toujours limité par le temps de bloc L1, soit 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 rollups. Au lieu d’attendre que des lots soient publiés sur L1, les opérateurs de NFFL peuvent vérifier et attester les 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é cryptographique solide grâce à EigenLayer.

Il est important de ne pas considérer le NFFL comme concurrent ou menaçant le modèle de sécurité de rouleau d’Ethereum. Au contraire, il fournit un outil complémentaire qui permet de nouvelles possibilités au sein de l’écosystème modulaire d’Ethereum. Les applications peuvent utiliser le NFFL pour une vérification rapide de l’état tout en comptant toujours sur un règlement canonique via L1 en cas de besoin. Cela crée une trousse à outils plus riche pour que les développeurs construisent des applications inter-chaînes avec des modèles de sécurité appropriés à leurs besoins spécifiques.

Conclusion

NFFL représente une approche novatrice pour résoudre l’un des défis les plus pressants de l’écosystème modulaire d’Ethereum - permettant la vérification sécurisée et efficace de l’état de cross-rollup. En utilisant l’ETH retenu par EigenLayer pour la sécurité économique et le stockage de données efficace de NEAR DA, NFFL crée une couche de finalité rapide qui peut vérifier les états de rollup en quelques secondes au lieu de 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. Au lieu de chercher à remplacer le modèle de sécurité des rollups, NFFL fournit une couche complémentaire optimisée pour des cas d’utilisation spécifiques nécessitant une finalité plus rapide. Le système de tâches basé sur les points de contrôle permet un fonctionnement efficace hors chaîne tout en maintenant des garanties de sécurité sur chaîne solides. Et l’architecture de contrat de registre permet aux rollups de vérifier sans confiance les états tout en héritant de la sécurité économique de NFFL.

Peut-être plus important encore, NFFL permet une nouvelle génération d’applications cross-chain qui étaient auparavant impossibles. Des protocoles de prêt unifiés qui partagent des garanties à travers les rollups aux enveloppes DEX qui rendent la liquidité établie universellement accessible, la vérification rapide de l’état de NFFL crée des éléments constitutifs pour une véritable abstraction de chaîne. Cela a des implications profondes pour l’efficacité du capital et l’expérience utilisateur dans l’écosystème.

La feuille de route du protocole démontre un engagement envers l’amélioration continue. Les mises à niveau prévues, telles que la transition vers les signatures ECDSA et la mise en œuvre d’ensembles d’opérateurs dynamiques, amélioreront la décentralisation et la scalabilité. L’activation de mécanismes de défi et de réduction complets renforcera les garanties de sécurité. Et l’intégration de solutions DA supplémentaires au-delà de NEAR rendra NFFL encore plus universel.

Alors que l’écosystème de rollup d’Ethereum continue d’évoluer, le besoin de vérification sécurisée de l’état inter-chaîne ne fera que croître. L’approche de NFFL qui consiste à étendre la sécurité d’Ethereum grâce au restaking 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 des garanties de sécurité solides, NFFL contribue à faire de la vision modulaire d’Ethereum une réalité.

Clause de non-responsabilité :

1. Cet article est reproduit à partir de [[](https://research.2077.xyz/nuffle-ethereums-finality-as-a-service-layer#introduction)[2077 Recherche](https://research.2077.xyz/)\]. Tous les droits d’auteur appartiennent à l’auteur original [Alex Hook]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnl’équipe et ils s’en occuperont rapidement.
2. Clause de non-responsabilité de responsabilité : Les opinions exprimées dans cet article sont uniquement celles de l’auteur et ne constituent en aucun cas des conseils en matière d’investissement.
3. Les traductions de l’article dans d’autres langues sont effectuées par l’équipe d’apprentissage de la porte. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.