« Quatre questions » pour vous aider à comprendre comment construire un AVS
TechFlow SélectionTechFlow Sélection
« Quatre questions » pour vous aider à comprendre comment construire un AVS
Le service de validation active (AVS) désigne tout système nécessitant ses propres sémantiques de validation distribuée pour effectuer la validation.
Dédié à des analyses Web3 approfondiesRédaction : IOSG Ventures
Source : EigenLayer, IOSG
Récemment, l'utilisation d'EigenLayer pour construire des projets d'infrastructure est devenue très populaire au sein de la communauté des développeurs. Ces projets sont appelés des services de validation active (AVS), désignant tout système nécessitant sa propre sémantique de validation distribuée. Ces systèmes peuvent inclure une couche DA, une nouvelle machine virtuelle (VM), des oracles, des ponts, etc.
Mais comment construire un AVS exactement ?
Pour définir les règles fondamentales d’un AVS, vous devez répondre à quatre questions principales.
Q1 : Qu'est-ce qui définit une tâche dans votre AVS ?
Dans EigenLayer, une tâche est l'unité minimale de travail qu'un opérateur (Operator) s'engage à fournir pour un AVS. Ces tâches peuvent être associées à une ou plusieurs conditions de slashing pour l’AVS.
Voici deux exemples de tâches :
-
Héberger et fournir un « DataStore » dans EigenDA
-
Publier la racine d'état d'une autre blockchain pour un pont inter-chaînes
EigenLayer fournit un exemple plus détaillé dans le flux de travail suivant. La tâche de cet AVS consiste à calculer le carré d'un nombre spécifique.
-
Un générateur de tâches publie des tâches à intervalles réguliers. Chaque tâche spécifie le nombre dont il faut calculer le carré. Elle inclut également une liste prédéfinie de participants (quorum) et un seuil en pourcentage, stipulant qu'au moins un certain ratio d'opérateurs parmi ce quorum doit signer pour valider la tâche.
-
Les opérateurs actuellement inscrits à l’AVS doivent lire le numéro de la tâche depuis le contrat, calculer le carré du nombre, signer le résultat, puis envoyer celui-ci ainsi que la signature à l’agrégateur (Aggregator).
-
L'agrégateur collecte les signatures des opérateurs et les agrège. Si les réponses d’un groupe d’opérateurs atteignent ou dépassent le seuil défini par le générateur lors de la publication de la tâche, l’agrégateur regroupe ces réponses et les publie sur le contrat de tâche.
-
Pendant la période de résolution des litiges, toute personne peut soulever un différend. Le contrat de résolution des litiges (DisputeResolution) gère les réponses erronées d’un opérateur spécifique (ou son absence de réponse durant cette fenêtre temporelle).
-
Si le litige est validé et traité, l’opérateur est gelé dans le contrat d’enregistrement (Registration), et un comité de veto d’EigenLayer décide si le gel doit être annulé ou non.
Q2 : Quel type de confiance votre AVS souhaite-t-il hériter ?
Source : EigenLayer, IOSG Ventures
EigenLayer propose trois types de confiance programmable.
-
Confiance économique
La confiance économique repose sur la confiance accordée aux actifs mis en jeu (staked). Si le profit tiré de la corruption est inférieur au coût de celle-ci, un acteur rationnel sur le plan économique n’aura aucun intérêt à lancer une attaque. Par exemple, si le coût d’une attaque contre un pont inter-chaînes est de 1 milliard de dollars, mais que le gain potentiel n’est que de 500 millions, alors économiquement, lancer une attaque serait irrationnel.
En tant que primitive cryptographique largement adoptée, le slashing peut considérablement augmenter le coût de la corruption, renforçant ainsi la sécurité économique.
-
Confiance décentralisée
L’essence de la confiance décentralisée réside dans la possession d’un ensemble vaste et largement distribué de validateurs, qu’il s’agisse d’une distribution virtuelle ou géographique. Pour éviter la collusion entre nœuds dans un AVS et les attaques de vivacité (liveness attacks), il est préférable qu’un seul fournisseur de services ne contrôle pas tous les nœuds.
Sur EigenLayer, différents AVS peuvent personnaliser leur niveau de décentralisation. Par exemple, ils peuvent imposer des exigences géographiques aux opérateurs ou autoriser uniquement des opérateurs individuels à fournir des services de nœud, en offrant des incitations supplémentaires pour attirer ce type d’opérateurs.
Voici un exemple :
Shutter propose une solution visant à empêcher le MEV via le chiffrement seuil. Ce processus implique un groupe de nœuds appelés Keypers, qui participent via une génération distribuée de clés (DKG) au calcul d’un ensemble de clés publiques et privées partagées. Ces nœuds sont élus par la gouvernance de Shutter DAO.
Il est clair que DKG repose sur l'hypothèse d'une majorité honnête.
En utilisant les services d'exploitation de nœuds proposés par EigenLayer, Shutter peut obtenir une distribution plus large des Keypers. Cette approche réduit non seulement le risque de collusion entre Keypers, mais renforce également la sécurité et la résilience du réseau.
De même, le comité d'état Lagrange (LSC) de Lagrange est composé de re-stakers. Pour chaque preuve d'état, au moins 2/3 des membres du comité doivent signer un en-tête de bloc spécifique avant qu'une preuve d'état soit générée via SNARK.
Confiance d’« inclusion » Ethereum
Les validateurs Ethereum, outre leur engagement via le staking vers Ethereum, peuvent s'engager de manière fiable envers un AVS en effectuant un re-staking sur EigenLayer. Cela permet aux validateurs de proposer certains services sur Ethereum (par exemple, des enchères de blocs partiels via MEV-Boost++) sans avoir besoin de modifications au niveau du protocole Ethereum.
Par exemple, les enchères futures d'espace-bloc permettent aux acheteurs de garantir à l'avance un espace dans des blocs futurs. Les validateurs participant au re-staking peuvent s'engager de façon fiable à inclure ces transactions ; s'ils omettent par la suite d'inclure la transaction de l'acheteur, ils encourent un slashing.
Supposons que vous construisiez un oracle et que vous deviez fournir un prix pendant une certaine période. Ou encore, supposons que vous exploitiez un L2 et que vous deviez publier périodiquement les données L2 sur Ethereum. Ce sont là des cas d'utilisation typiques des enchères futures d'espace-bloc.
Q3 : Le travail requis des opérateurs est-il léger ou lourd ?
Si vous souhaitez hériter de la décentralisation des validateurs Ethereum, les tâches de l’AVS doivent être conçues pour être aussi légères que possible.
Si une tâche consomme beaucoup de ressources informatiques, un opérateur individuel (Solo Operator) pourrait ne pas être en mesure de la gérer.
Q4 : Quelles sont les conditions de slashing ?
En effectuant un re-staking vers un service spécifique, les re-stakers acceptent le risque potentiel de slashing, défini par l’AVS.
En tant qu’AVS, vous devez concevoir des conditions de slashing vérifiables sur chaîne, prouvables et objectivement attribuables. Par exemple, signer deux fois un bloc sur Ethereum, ou qu’un nœud dans un AVS de pont inter-chaînes signe un bloc invalide provenant d’une autre chaîne.
Des conditions de slashing mal conçues pourraient entraîner des divergences et provoquer des risques systémiques.
L’AVS doit également assurer l’observabilité, en permettant la surveillance, le suivi et l’enregistrement des requêtes et réponses entre services.
Comment quantifier cela ?
Quelle quantité de confiance votre AVS nécessite-t-il (capital en re-staking, nombre de validateurs distribués distincts, et nombre de validateurs Ethereum devant s’engager) ? Et comment allez-vous les inciter ?
Par exemple, si un pont inter-chaînes traite 100 millions de dollars par semaine et loue une sécurité d'une valeur de 100 millions de dollars, les utilisateurs peuvent se sentir en sécurité. Même si les validateurs tentaient de compromettre le système, les utilisateurs seraient protégés car ils pourraient être compensés via la redistribution des fonds slashés.
Étant donné que la TVL du pont, le nombre d’ETH en re-staking, le nombre d’opérateurs participant, ainsi que de nombreux autres paramètres évolueront constamment et pourront connaître de fortes fluctuations, l’AVS doit disposer d’un moyen d’ajuster son budget de sécurité et ses marges de sécurité.
L’AVS peut utiliser une partie de son offre totale de jetons pour payer la sécurité économique.
Mais, compromets-je l'utilité de mon jeton en utilisant EigenLayer ?
Absolument pas !
EigenLayer prend en charge le double staking (Dual Staking). Cela vous permet d’utiliser simultanément l’ETH et votre jeton natif pour sécuriser le réseau, tout en ajustant dynamiquement la proportion de chaque jeton selon vos besoins. Au début du réseau, l’ETH pourrait représenter une part importante. À mesure que le réseau mûrit, vous pouvez souhaiter que le jeton natif joue un rôle plus important. Dans ce cas, l’AVS peut augmenter la proportion du jeton natif via la gouvernance du protocole.
De plus, lorsque la demande de sécurité d’un AVS augmente rapidement à court terme — par exemple, lorsque la TVL des protocoles DeFi utilisant l’oracle de l’AVS croît rapidement — l’AVS peut toujours utiliser EigenLayer pour renforcer sa sécurité économique.
De ce point de vue, EigenLayer constitue un marché de confiance programmable, offrant une sécurité « élastique ».
Quels outils externes puis-je utiliser ?
Voici quelques projets notables.
-
Dans le marché tripartite d’EigenLayer, les opérateurs dépendent des développeurs AVS pour coder correctement le logiciel AVS et définir des conditions de slashing raisonnables. Toutefois, compte tenu de la diversité des AVS, la logique d’interaction entre chaque AVS et les opérateurs peut varier, créant ainsi un nouveau domaine. Pour éviter les slashings accidentels, les AVS peuvent auditer leur base de code avant déploiement. En outre, EigenLayer dispose d’un comité de veto capable de rejeter via multisignature les décisions de slashing incorrectes.
-
Par ailleurs, Cubist collabore avec EigenLabs pour développer un cadre ouvert anti-slashing, utilisant du matériel sécurisé et des stratégies personnalisées pour signer des transactions et des messages de validation au sein d’un gestionnaire de clés. Par exemple, signer simultanément deux en-têtes de bloc à des hauteurs différentes ne sera jamais approuvé par le moteur de stratégie du gestionnaire de clés.
-
Les re-stakers/opérateurs ayant un goût plus élevé pour le risque pourraient souhaiter rejoindre des AVS précoces afin d’obtenir des rendements plus élevés. Dans ce cas, l’Anti-slasher de Cubist pourrait être utile.
-
Beaucoup savent qu’EigenLayer peut aider un AVS à construire un réseau de confiance, mais combien l’AVS doit-il payer pour la sécurité économique, et comment se prémunir contre les attaques économiques ?
-
Anzen Protocol a développé le facteur de sécurité (SF), une métrique standard universelle pour mesurer la sécurité économique d’un AVS. Le SF repose sur les concepts de coût de corruption et de profit de corruption.
-
Anzen aide les AVS à maintenir un niveau minimum de sécurité économique sans payer excessivement pour celle-ci.
-
EigenLabs développe EigenSDK pour aider les AVS à écrire le code logiciel de leurs nœuds. Ce SDK inclut des modules d’agrégation de signatures, d’interaction avec les contrats EigenLayer, de réseau, de cryptographie et de client de surveillance d’événements.
-
Parallèlement, Othentic construit un outil de développement pour aider les AVS à accélérer leur mise sur le marché.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
IOSG Ventures
