IOSG : 'Quatre questions' vous permettent de comprendre comment créer AVS sur EigenLayer

<img src="/static/imghw/default1.png" data-src="https://img.php.cn/upload/article/000/000/164/171159066812979.png" class="lazy" alt="IOSG : Quatre questions vous permettent de comprendre comment créer AVS sur EigenLayer">Source: EigenLayer, IOSG

Récemment, l'utilisation d'EigenLayer pour construire des projets d'infrastructure est devenue très populaire dans la communauté des développeurs. Ces projets sont appelés Active Verification Services (AVS), faisant référence à tout système qui nécessite sa propre sémantique de vérification distribuée pour la vérification. Ces systèmes peuvent inclure des couches DA, de nouvelles machines virtuelles, des oracles, des ponts, etc.

Mais comment construit-on exactement un AVS ?

Afin de fixer les règles de base de l'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 la plus petite unité de travail que l'opérateur promet de fournir des services pour AVS. Ces tâches peuvent être associées à une ou plusieurs conditions de réduction d'AVS.

Voici deux exemples de tâches :

• Hébergez et fournissez un "DataStore" dans EigenDA
• Publiez la racine d'état d'une autre blockchain pour un pont entre chaînes

EigenLayer fournit un flux de travail plus détaillé dans l'exemple détaillé suivant. La tâche de cet AVS est de calculer le carré d'un nombre spécifique.

Task Generator publie des tâches à intervalles fixes. Chaque tâche précise le nombre à mettre au carré. Il comprend également les quorums et les pourcentages de seuil de quorum, stipulant que chaque quorum répertorié nécessite au moins un certain pourcentage de signatures d'opérateur pour réussir cette tâche.

L'Opérateur qui rejoint actuellement AVS doit lire le numéro de tâche du contrat de tâche, calculer son carré, signer le résultat du calcul et envoyer le résultat du calcul et la signature à l'Agrégateur.

Aggregator collecte les signatures des opérateurs et les regroupe. Si une réponse de l'opérateur dépasse le seuil de pourcentage défini par le générateur de tâches lors de la publication de la tâche, l'agrégateur regroupe ces réponses et les publie dans le contrat de tâche.

Pendant la période de résolution des litiges, toute personne peut soulever un litige. Le contrat DisputeResolution gère les réponses d'erreur d'un opérateur spécifique. (Ou l'Opérateur ne répond pas dans ce délai)

Si le litige est finalement vérifié et traité, l'Opérateur sera gelé dans le contrat d'enregistrement, et le comité de veto d'EigenLayer décidera s'il doit opposer son veto à la demande de gel.

Q2 : De quel type de confiance votre AVS veut-il hériter ?

<img src="/static/imghw/default1.png" data-src="https://img.php.cn/upload/article/000/000/164/171159066870472.png" class="lazy" alt="IOSG : Quatre questions vous permettent de comprendre comment créer AVS sur EigenLayer">Source: EigenLayer, IOSG Ventures

EigenLayer fournit trois confiances programmables.

Confiance économique

La confiance économique repose sur la confiance des citoyens dans les actifs promis. Si les bénéfices de la corruption sont inférieurs aux coûts de la corruption, les acteurs économiquement rationnels n’attaqueront pas. Par exemple, si le coût d’une attaque contre un pont inter-chaînes est de 1 milliard de dollars, mais que le bénéfice n’est que de 500 millions de dollars, il est clairement irrationnel d’un point de vue économique de mener cette attaque.

En tant que primitive cryptoéconomique largement adoptée, la réduction 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 est d'avoir un ensemble large et largement distribué de validateurs, que ce soit virtuellement ou géographiquement. Pour éviter la collusion et les attaques de vivacité entre les nœuds dans AVS, il est préférable de ne pas laisser un seul fournisseur de services exécuter tous les nœuds.

Sur EigenLayer, différents AVS peuvent personnaliser leur degré de décentralisation. Par exemple, ils peuvent fixer des exigences de localisation géographique pour les opérateurs, ou autoriser uniquement des opérateurs individuels à fournir des services de nœuds et, par conséquent, offrir davantage d'incitations pour attirer ces opérateurs.

Voici un exemple :

Shutter propose une solution pour empêcher MEV en utilisant le cryptage par seuil. Le processus implique un groupe de nœuds, appelés Keypers, qui participent au calcul d'un ensemble partagé de clés publiques et privées via la génération de clés distribuées (DKG). Ces nœuds sont élus par la gouvernance de Shutter DAO.

Évidemment, le DKG s'appuie sur l'hypothèse d'une majorité honnête.

En tirant parti du service d'exploitation de nœuds fourni par EigenLayer, Shutter peut obtenir une distribution plus large de Kepers. Cette approche réduit non seulement le risque de collusion entre les Keypers, mais améliore également la sécurité et la résilience du réseau.

De même, le Comité d'État de Lagrange (LSC) de Lagrange est composé de réengageurs. 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 ne soit générée via SNARK.

Ethereum « Inclusion » Trust

En plus de prendre des engagements envers Ethereum via le jalonnement, les validateurs d'Ethereum peuvent également prendre des engagements crédibles envers AVS s'ils misent davantage sur EigenLayer. Cela permet aux proposants de fournir certains services sur Ethereum (par exemple, des enchères de blocs partiels via MEV-Boost++) sans nécessiter de modifications au niveau du protocole d'Ethereum.

Par exemple, les enchères d'espaces de blocs à terme permettent aux acheteurs de sécuriser à l'avance les futurs espaces de blocs. Les validateurs participant au re-staking peuvent prendre un engagement crédible sur l'espace de bloc, et s'ils n'incluent pas ultérieurement la transaction de l'acheteur, ils seront réduits.

Supposons que vous construisez un oracle et que vous deviez peut-être fournir des prix dans un certain délai. Ou disons que vous utilisez un L2 et que vous devrez peut-être publier des données L2 sur Ethereum toutes les quelques minutes. Ce sont tous des cas d’utilisation des enchères d’espaces de blocs à terme.

Q3 : Le travail à effectuer par l'opérateur est-il léger ou lourd ?

Si vous souhaitez hériter de la décentralisation des validateurs Ethereum, la tâche de l'AVS doit être conçue pour être aussi légère que possible.

Si les tâches consomment beaucoup de ressources informatiques, Solo Operator risque de ne pas être en mesure de les gérer.

Q4 : Quelles sont les conditions de slashing ?

En re-staking sur un service spécifique, le re-stakeholder accepte le risque éventuel de slashing, et cette condition de slashing sera précisée par AVS.

En tant qu'AVS, nous devons concevoir des conditions de réduction vérifiables, prouvables et objectivement attribuables sur la chaîne. Par exemple, doubler la signature d'un bloc dans Ethereum et un nœud dans un pont inter-chaînes de nœuds légers AVS signer un bloc invalide d'une autre chaîne.

Des conditions de réduction mal conçues peuvent conduire à des désaccords et donc à des risques systémiques.

AVS devrait également garantir l'observabilité, permettant aux demandes et aux réponses d'être surveillées, suivies et enregistrées dans tous les services.

Comment quantifier ?

De quel degré de confiance votre AVS a-t-il besoin (capital de remise en jeu, différents numéros de validateurs distribués et nombre de validateurs Ethereum nécessaires pour remplir la promesse du validateur Ethereum), et comment allez-vous l'encourager ?

Par exemple, si un pont inter-chaînes a un volume de transactions hebdomadaire de 100 millions de dollars et loue 100 millions de dollars de sécurité, les utilisateurs peuvent être sûrs qu'ils sont en sécurité. Même si les validateurs tentent de briser le système, les utilisateurs sont protégés car ils peuvent les compenser en réduisant les redistributions.

Étant donné que la TVL sur les ponts, le montant du rééquilibrage d'ETH, le nombre d'opérateurs qui s'y inscrivent et de nombreux autres paramètres changeront constamment et potentiellement fluctuent considérablement, AVS a besoin d'un moyen d'ajuster son budget de sécurité et son espace tampon.

AVS peut payer la sécurité économique avec une partie de son approvisionnement total en jetons.

Mais est-ce que je compromet mon utilitaire de jeton en utilisant EigenLayer ?

Absolument pas !

EigenLayer prend en charge le double jalonnement. Cela vous permet de sécuriser le réseau avec à la fois l'ETH et votre jeton natif, en ajustant le ratio de chaque jeton selon vos besoins. Dans les premiers stades du réseau, l’ETH peut représenter une proportion plus importante. À mesure que le réseau évolue, vous souhaiterez peut-être que le jeton natif joue un rôle plus important. Dans ce cas, AVS peut augmenter la proportion de jetons natifs grâce à la gouvernance du protocole.

De plus, lorsque les besoins de sécurité d'AVS augmentent rapidement à court terme, par exemple lorsque la TVL du protocole DeFi servi par l'oracle AVS augmente rapidement, AVS peut toujours utiliser EigenLayer pour renforcer sa sécurité économique.

De ce point de vue, EigenLayer est un marché de confiance programmable qui offre une sécurité « résiliente ».

Quels outils externes puis-je utiliser ?

Voici quelques éléments remarquables.

Sur le marché tripartite d'EigenLayer, les opérateurs s'appuient sur les développeurs AVS pour coder correctement le logiciel AVS et définir des conditions de réduction raisonnables. Cependant, compte tenu de la diversité des AVS, la logique d'interaction entre chaque AVS et Opérateur peut être différente, ce qui crée un tout nouveau domaine. Pour éviter les événements de coupure accidentels, AVS peut auditer la base de code avant la publication. De plus, EigenLayer dispose d'un comité de veto qui peut opposer son veto aux décisions de réduction incorrectes grâce à des signatures multiples.

Pendant ce temps, Cubist travaille avec EigenLabs pour développer un cadre ouvert anti-slashing qui exploite un matériel sécurisé et utilise des politiques personnalisées pour signer les transactions et vérifier les messages au sein du gestionnaire de clés. Par exemple, la signature simultanée de deux en-têtes de bloc de hauteurs différentes ne sera jamais approuvée par le moteur de stratégie du gestionnaire de clés.

Les parties prenantes/opérateurs ayant un appétit pour le risque plus élevé peuvent souhaiter participer à l'AVS anticipé pour des rendements plus élevés. Dans ce cas, l'Anti-slasher de Cubist peut être utile.

Beaucoup de gens savent qu'EigenLayer peut aider AVS à construire un réseau de confiance, mais combien AVS doit-il payer pour la sécurité économique et comment se défendre contre les attaques économiques ?

Le protocole Anzen a développé le facteur de sécurité (SF), une mesure standard universelle pour mesurer la sécurité économique des AVS. SF est basé sur les concepts de coûts et de bénéfices de la corruption.

Anzen aide AVS à maintenir un niveau minimum de sécurité financière sans payer trop cher pour la sécurité financière.

EigenLabs développe EigenSDK pour aider AVS à coder son logiciel de nœud. Le SDK comprend l'agrégation de signatures, la logique d'interaction avec les contrats EigenLayer, les modules clients de mise en réseau, de cryptographie et de surveillance des événements.

Pendant ce temps, Othentic développe un outil de développement pour aider AVS à publier ses produits plus rapidement.

Références :

https://medium.com/@lagrangelabs/state-committees-on-eigenlayer-via-lagrange-7752f1916db4

https://www.blog.eigenlayer.xyz/ycie/

https : //www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/

https://github.com/Layr-Labs

https://docs.eigenlayer.xyz/eigenlayer/overview/

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!