Au cours de la dernière année, EigenLayer a publié son livre blanc, finalisé une ronde de financement de série A de 50 millions de dollars et lancé la première phase de son réseau principal. Au cours de cette période, la communauté Ethereum a également tenu des discussions approfondies autour d'EigenLayer et de ses cas d'utilisation. Cet article suivra et triera ces discussions.
arrière-plan
Dans l'écosystème Ethereum, certains services middleware (tels que les oracles) ne s'appuient pas entièrement sur la logique en chaîne, ils ne peuvent donc pas s'appuyer directement sur le consensus et la sécurité d'Ethereum et doivent rediriger le réseau de confiance. La pratique habituelle consiste à gérer d’abord le projet, puis à introduire des incitations symboliques pour attirer les participants au système et réaliser progressivement la décentralisation.
Cela pose au moins deux difficultés. Premièrement, l'introduction d'un mécanisme d'incitation nécessite des coûts supplémentaires : le coût d'opportunité pour que les participants achètent des jetons pour participer à l'engagement, et le coût opérationnel pour le côté projet pour maintenir la valeur des jetons. Deuxièmement, même si les coûts mentionnés ci-dessus sont payés et qu’un réseau décentralisé est construit, sa sécurité et sa durabilité restent inconnues. Pour les projets de start-up, ces deux points sont particulièrement délicats.
L'idée d'EigenLayer est d'assurer la sécurité économique de ces middlewares (Actively Validated Services, AVS) en re-staking par les jalonneurs Ethereum existants. Si ces réengagements travaillent honnêtement, ils peuvent être récompensés, et s’ils font le mal, l’exposition initiale à l’Ethereum sera perdue.
Les avantages sont les suivants : premièrement, la partie projet n'a pas besoin de diriger elle-même le nouveau réseau de confiance, mais elle le confie au validateur Ethereum, ce qui réduit autant que possible le coût en capital ; deuxièmement, la sécurité économique du validateur Ethereum. L'ensemble est très solide, de sorte que la sécurité a également été garantie dans une certaine mesure. Du point de vue des donateurs d'Ethereum, le réengagement leur procure des revenus supplémentaires. Tant qu'il n'y a pas d'intention malveillante subjective, le risque global est contrôlable.
Sreeram, le fondateur d'EigenLayer, a mentionné un jour les trois cas d'utilisation et modèles de confiance d'EigenLayer sur Twitter et sur les podcasts :
CONFIANCE ÉCONOMIQUE. Autrement dit, la réutilisation de l’exposition au staking d’Ethereum, le staking de jetons de plus grande valeur signifie une sécurité économique plus solide, comme indiqué ci-dessus.
Confiance décentralisée. Le comportement malveillant de certains services (tels que le partage de secrets) peut ne pas être imputable et les mécanismes de réduction ne peuvent pas être invoqués. Il doit y avoir un groupe de personnes suffisamment décentralisé et indépendant qui fasse quelque chose pour se prémunir contre le risque de collusion et de collusion.
Engagement du validateur Ethereum. Les producteurs de blocs prennent certains engagements crédibles en utilisant l'exposition promise comme garantie. Ci-dessous, nous énumérerons quelques exemples pour illustrer davantage.
# Participants au système
EigenLayer agit comme un marché ouvert, reliant trois acteurs majeurs.
Re-Pledger. Si vous êtes exposé au jalonnement Ethereum, vous pouvez participer en transférant les informations de retrait à EigenLayer pour participer au nouveau jalonnement, ou simplement en déposant du LST tel que stETH pour participer. Si une nouvelle partie prenante n'est pas en mesure d'exécuter elle-même un nœud AVS, elle peut également déléguer son exposition à un opérateur.
opérateur. L'opérateur accepte la délégation des nouvelles parties prenantes et exécute le nœud AVS. Ils sont libres de choisir quels AVS ils souhaitent desservir. Une fois que vous fournissez des services à AVS, vous devez accepter les règles de réduction définies par celui-ci.
AVS. En tant que demandeur/consommateur, AVS doit payer les re-stakers et obtenir la sécurité économique qu'ils offrent.
Avec ces concepts de base, examinons les cas d'utilisation spécifiques d'EigenLayer.
EigenDA
EigenDA est le produit phare lancé par EigenLayer. La solution est dérivée de Danksharding, la solution d'extension Ethereum. Parmi eux, le Data Availability Sampling (DAS) est également largement utilisé dans les projets DA tels que Celestia et Avail. Dans ce chapitre, nous donnons une introduction rapide à DAS, puis examinons la mise en œuvre d'EigenDA et ses innovations.
LE
En tant que solution frontale pour Danksharding, EIP-4844 introduit la « transaction transportant des objets blob ». Chaque transaction transportera une taille de données supplémentaire d'environ 125 Ko. Dans le contexte de l'expansion du partage de données, les nouvelles données augmenteront sans aucun doute la charge pesant sur les nœuds. Alors, existe-t-il un moyen de faire en sorte que le nœud télécharge uniquement une petite partie des données et de vérifier également que toutes les données sont disponibles ?
L'approche DAS consiste à laisser les nœuds échantillonner de manière aléatoire une petite partie des données à plusieurs reprises. Chaque échantillonnage réussi augmentera la confiance que le nœud pense que les données sont disponibles. Une fois qu'un certain niveau prédéfini est atteint, les données sont considérées comme disponibles. Cependant, il est toujours possible pour un attaquant de cacher une petite partie des données – nous avons également besoin d’une certaine sorte de tolérance aux pannes.
DAS utilise le codage d'effacement (Erasure Coding). L'idée principale du codage par effacement est de diviser les données en morceaux, puis de coder ces morceaux pour générer des morceaux redondants supplémentaires. Ces blocs redondants contiennent une partie des informations des blocs de données d'origine, de sorte que lorsque certains blocs de données sont perdus ou endommagés, les blocs de données perdus peuvent être récupérés via les blocs redondants. De cette manière, le codage par effacement offre redondance et fiabilité au DAS.
De plus, nous devons également vérifier si les blocs redondants résultants sont correctement codés, car les données originales ne peuvent pas être reconstruites en utilisant de mauvais blocs redondants. Danksharding adopte l'engagement KZG (Kate-Zaverucha-Goldberg). L'engagement KZG est une méthode permettant de vérifier un polynôme en prouvant que sa valeur à un emplacement spécifique est cohérente avec une valeur numérique spécifiée.
Le prouveur choisit un polynôme p(x) et utilise p(x) pour calculer les engagements pour chaque bloc de données, appelés C1, C2, ..., Cm. Le prouveur publiera l'engagement avec le bloc de données. Pour vérifier un encodage, le vérificateur peut échantillonner aléatoirement t points x1, x2, ..., xt et demander au prouveur d'ouvrir des engagements à ces points : p(x1), p(x2), ..., p(xt ) . En utilisant l'interpolation lagrangienne, le vérificateur peut reconstruire le polynôme p(x) à partir de ces t points. Le vérificateur peut désormais utiliser le polynôme reconstruit p(x) et les blocs de données pour recalculer les engagements C1', C2', ..., Cm' et vérifier qu'ils correspondent aux engagements publiés C1, C2, ..., Cm.
En bref, grâce aux engagements KZG, les vérificateurs n'ont besoin que d'un petit nombre de points pour vérifier l'exactitude de l'ensemble du codage. De cette façon, nous obtenons le DAS complet.
Comment
EigenLayer emprunte des idées à DAS et les applique à EigenDA.
Premièrement, les nœuds EigenDA sont réimplantés et enregistrés dans le contrat EigenLayer.
Deuxièmement, après avoir obtenu les données, le séquenceur divise les données en plusieurs blocs, utilise le codage d'effacement pour générer des blocs redondants et calcule l'engagement KZG correspondant à chaque bloc de données. Sequencer publie un par un les engagements de KZG dans le cadre du contrat EigenDA en tant que témoin.
Par la suite, le séquenceur distribue le bloc de données ainsi que son engagement KZG à chaque nœud EigenDA un par un. Une fois que le nœud a obtenu l'engagement KZG, il le compare à l'engagement KZG sur le contrat EigenDA, stocke le bloc de données après avoir confirmé qu'il est correct et le signe.
Ensuite, le séquenceur collecte ces signatures, génère des signatures agrégées et les publie dans le contrat EigenDA, et le contrat EigenDA vérifie les signatures. Une fois la vérification de la signature correcte, l’ensemble du processus est terminé.
Dans le processus ci-dessus, le nœud EigenDA prétend uniquement avoir stocké le bloc de données via des signatures. Nous avons également besoin d'un moyen de garantir que le nœud EigenDA ne ment pas. EigenDA adopte la preuve de garde.
L'idée de la preuve de séquestre est de mettre une "bombe" dans les données. Une fois que le nœud la signe, elle sera coupée. Afin de mettre en œuvre la preuve de séquestre, il est nécessaire de concevoir : une valeur secrète pour distinguer les différents nœuds DA afin d'éviter la triche ; une fonction spécifique au nœud DA, prenant en entrée les données DA et la valeur secrète, et la présence ou l'absence de des bombes comme sortie. Si le nœud ne stocke pas toutes les données qu'il est censé stocker, cette fonction ne peut pas être calculée. Dankrad a partagé plus de détails sur la preuve d'engagement sur son blog.
S'il y a un nœud paresseux, n'importe qui peut soumettre une preuve au contrat EigenDA, et le contrat vérifiera la preuve, et si la vérification est réussie, le nœud paresseux sera condamné à une amende.
En termes de configuration matérielle requise, l'engagement de KZG de calculer 32 Mo de données en 1 seconde nécessite environ 32 à 64 processeurs centraux, mais cette exigence concerne uniquement le côté séquenceur et n'imposera pas de charge au nœud EigenDA. Dans le réseau de test d'EigenDA, le débit de 100 nœuds EigenDA a atteint 15 Mo/s, tandis que la demande de bande passante de téléchargement des nœuds n'était que de 0,3 Mo/s (beaucoup inférieure aux exigences pour l'exécution des validateurs Ethereum).
**En résumé, nous pouvons voir qu'EigenDA a réussi à dissocier la disponibilité des données et le consensus, et que la propagation des blocs de données n'est plus limitée par le goulot d'étranglement du protocole de consensus et le faible débit du réseau P2P. Parce qu'EigenDA équivaut à un tour gratuit sur le consensus Ethereum : le processus par lequel Sequencer émet des engagements KZG et des signatures globales, vérifie les signatures par des contrats intelligents et punit les nœuds malveillants se produit tous sur Ethereum, et Ethereum fournit des garanties de consensus, il n'est donc pas nécessaire pour redémarrer le réseau de confiance. **
Problèmes du DAS
Actuellement, le DAS en tant que technologie présente certaines limites. Nous devons supposer que les contreparties malveillantes utiliseront tous les moyens possibles pour tromper les nœuds légers et les amener à accepter de fausses données. Sreeram avait expliqué ce qui suit dans son tweet.
Pour qu'un seul nœud ait une probabilité suffisamment élevée que les données soient disponibles, les conditions suivantes doivent être remplies :
Échantillonnage aléatoire : chaque nœud doit sélectionner de manière indépendante et aléatoire un groupe d'échantillons à échantillonner, et la contrepartie ne sait pas qui a demandé quels échantillons. De cette manière, la contrepartie ne peut pas modifier sa stratégie en conséquence pour tromper les nœuds.
Échantillonnage simultané : le DAS doit être effectué par plusieurs nœuds simultanément, ce qui rend impossible pour un attaquant de distinguer l'échantillonnage d'un nœud de celui d'autres nœuds.
Échantillonnage d'adresses IP privées : signifie utiliser une adresse IP anonyme pour chaque bloc de données interrogé. Sinon, l’adversaire peut identifier différents nœuds qui effectuent l’échantillonnage et fournir sélectivement aux nœuds les parties qu’ils ont interrogées sans fournir d’autres parties des données.
Nous pouvons laisser plusieurs nœuds légers effectuer un échantillonnage aléatoire pour répondre à la concurrence et au caractère aléatoire, mais il n'existe actuellement aucun bon moyen de répondre à l'échantillonnage IP privé. Il existe donc encore des vecteurs d’attaque contre le DAS, de sorte que le DAS n’offre actuellement que de faibles garanties. Ces problèmes sont toujours activement résolus.
Couche propre et MEV
Sreeram a parlé de l'utilisation d'EigenLayer dans la pile MEV lors du sommet MEVconomics. Sur la base des primitives cryptoéconomiques de jalonnement et de slashing, les proposants peuvent mettre en œuvre les quatre fonctionnalités suivantes, qui constituent le troisième point mentionné ci-dessus – le cas d'utilisation de l'engagement du validateur.
Activation basée sur les événements
Des protocoles tels que Gelato permettent de réagir à des événements spécifiques en chaîne. C'est-à-dire une surveillance continue des événements sur la chaîne, et lorsqu'un événement se produit, certaines opérations prédéfinies sont déclenchées. Ces tâches sont généralement effectuées par des auditeurs/exécuteurs tiers.
On l'appelle « tiers » car il n'y a aucun lien entre l'auditeur/exécuteur et le proposant qui gère réellement l'espace de bloc. Supposons qu'un auditeur/exécuteur déclenche une transaction mais (pour une raison quelconque) ne soit pas inclus dans un bloc par un proposant, ce qui ne peut pas être attribué et n'apporte donc pas de garanties économiques déterministes.
Si ce service est fourni par des proposants qui participent au restaking, ils peuvent prendre des engagements crédibles quant au déclenchement des opérations, et si ces transactions ne sont pas incluses dans le bloc, le proposant est slashé. Cela offre des garanties plus solides par rapport aux auditeurs/exécuteurs tiers.
Dans des applications pratiques (telles que les protocoles de prêt), l’un des objectifs de la fixation du taux de surdimensionnement est de couvrir les fluctuations de prix sur une certaine période. Ceci est lié à la fenêtre de temps précédant la liquidation, un ratio de surdimensionnement plus élevé signifie une période tampon plus longue. Si la majorité des transactions adoptent une stratégie de réaction événementielle avec de fortes garanties fournies par le proposant, alors (pour les actifs liquides) la volatilité du ratio de surdimensionnement peut être limitée à quelques intervalles de blocs, réduisant ainsi le taux de surdimensionnement et améliorant efficacité du capital.
Enchères en bloc partiel
Dans la conception actuelle de MEV-Boost, le proposant sous-traite complètement l'espace du bloc au constructeur et ne peut recevoir et proposer passivement que l'intégralité du bloc soumis par le constructeur. Les constructeurs constituent une infime minorité par rapport aux proposants plus largement distribués, et ils peuvent s'entendre pour censurer et faire chanter des transactions spécifiques, car les proposants ne peuvent pas inclure les transactions qu'ils souhaitent dans MEV-Boost.
EigenLayer propose MEV-Boost++ pour mettre à niveau MEV-Boost, introduit la partie proposant dans le bloc et le proposant peut inclure n'importe quelle transaction dans la partie proposant. Le proposant peut également construire un bloc alternatif B-alt en même temps, et proposer ce bloc alternatif B-alt lorsque le relais ne libère pas le Builder_part. Cette flexibilité garantit non seulement la résistance à la censure, mais résout également le problème de la vivacité des relais.
Ceci est cohérent avec la conception de la couche de protocole - l'objectif de crList proposé par ePBS, c'est-à-dire que nous devons garantir qu'un large éventail de proposants peuvent participer à la décision de la composition du bloc pour obtenir une résistance à la censure.
Chiffrement à seuil
Dans la solution MEV basée sur le chiffrement à seuil, les clés de chiffrement et de déchiffrement sont gérées par un groupe de nœuds distribués. Les utilisateurs chiffrent les transactions, qui sont déchiffrées et exécutées après avoir été incluses dans un bloc.
Cependant, le chiffrement à seuil repose sur l’hypothèse d’honnêteté majoritaire. Si la plupart des nœuds sont malveillants, la transaction déchiffrée peut ne pas être incluse dans le bloc. Les proposants effectuant un restaking peuvent s'engager de manière crédible sur des transactions cryptées pour garantir leur inclusion dans les blocs. Si le proposant n'inclut pas la transaction décryptée, elle sera coupée. Bien entendu, si une majorité malveillante ne libère pas la clé de déchiffrement, alors le proposant peut proposer un bloc vide.
Enchères Blockspace à long terme
Les enchères de blocs d'espace à long terme permettent aux acheteurs de blocs d'espace de réserver à l'avance le futur bloc d'espace pour un validateur. Les validateurs qui participent au re-staking peuvent prendre des engagements crédibles et seront perdus s'ils n'incluent pas la transaction de l'acheteur à son expiration. Cette garantie d’accès à l’espace de bloc présente quelques cas d’utilisation pratiques. Par exemple, l'oracle doit alimenter les prix sur une certaine période ; Arbitrum publie les données L2 sur Ethereum L1 toutes les 1 à 3 minutes, Optimism toutes les 30 secondes - 1 minute, etc.
#PEPC
Revenons au PEPC (Protocol-enforced Proposer Commitment), qui a été largement discuté par la communauté Ethereum récemment. Le PEPC est en fait la promotion ou la généralisation de l’ePBS.
Décomposons cette chaîne logique une par une.
Tout d'abord, prenons comme exemple PBS MEV-Boost en dehors du protocole. Actuellement, MEV-Boost s'appuie sur le mécanisme de slash au niveau du protocole Ethereum, c'est-à-dire que si un proposant signe deux en-têtes de bloc différents à la même hauteur de bloc, ils seront tailladé. Étant donné que le proposant doit signer l'en-tête de bloc soumis par le relais, ce qui équivaut à la liaison entre l'en-tête de bloc et le proposant, le relais a des raisons de croire que le bloc du constructeur sera proposé. Sinon, le proposant sera simplement contraint d'abandonner le créneau ou de proposer un bloc différent (ce qui entraînera une réduction). A ce moment, l'engagement du proposant est garanti par la sécurité économique du jalonnement/slashing.
*En gros, un principe important dans la conception d'ePBS est la « sécurité de publication des constructeurs honnêtes », qui garantit que les blocs publiés par des constructeurs honnêtes seront proposés. En tant que PBS au sein du protocole, ePBS sera inclus dans la couche consensus d'Ethereum et garanti par le protocole.
PEPC est une autre promotion d'ePBS. ePBS promet que "le bloc du constructeur sera proposé." Si cela est étendu aux enchères de blocs partiels, aux enchères de blocs parallèles, aux enchères de blocs futures, etc., nous pouvons permettre au proposant de faire plus de choses - et la couche de protocole s'assure que ces les choses sont faites correctement.
Il existe une relation subtile entre PEPC et EigenLayer. Il n'est pas difficile de constater qu'il existe certaines similitudes entre les cas d'utilisation du PEPC mentionnés ci-dessus et les cas d'utilisation du producteur de blocs d'EigenLayer. Cependant, une différence importante entre EigenLayer et PEPC est que les proposants qui participent au réengagement peuvent théoriquement toujours violer leurs engagements, même s'ils seront punis financièrement ; tandis que PEPC se concentre sur "Application du protocole", c'est-à-dire obligatoire est implémenté au niveau de la couche de protocole. Si la promesse ne peut pas être exécutée, le bloc sera invalide.
(PS : d'un simple coup d'œil, il est facile de constater qu'EigenDA est similaire à Danksharding et que MEV-Boost++ est similaire à ePBS. Ces deux services sont comme la version opt-in de la conception de la couche de protocole. Par rapport à la couche de protocole, c'est une solution plus rapide pour le marché. , suivre le rythme de ce qu'Ethereum fera à l'avenir et maintenir l'alignement d'Ethereum grâce à un nouvel engagement).
Ne surchargez pas le consensus Ethereum ?
Il y a quelques mois, l'article de Vitalik, Don't Overload Ethereum Consensus, était considéré par la plupart comme une critique de Resttaking. L'auteur pense qu'il s'agit simplement d'un rappel ou d'un avertissement visant à Maintenir le consensus social, l'accent étant mis sur le consensus social et non sur la négation d'un nouvel engagement.
Au début d’Ethereum, l’attaque DAO a suscité une énorme controverse et la communauté a eu une discussion animée sur l’opportunité de faire un hard fork. Aujourd’hui, l’écosystème Ethereum, dont Rollup, contient déjà un grand nombre d’applications. Il est donc très important d’éviter de provoquer de grands désaccords au sein de la communauté et de maintenir la cohérence du consensus social.
Hermione crée une couche 2 réussie et affirme que, parce que sa couche 2 est la plus grande, elle est intrinsèquement la plus sécurisée, car s'il y a un bug provoquant le vol de fonds, les pertes seront si importantes que la communauté n'aura pas le choix. mais à forker pour récupérer les fonds des utilisateurs Risque élevé.
La citation ci-dessus tirée du texte original en est un bon exemple. Aujourd'hui, le TVL total de L2 dépasse les 10 milliards de dollars américains et s'il y a un problème, il sera extrêmement impliqué. À l'heure actuelle, si la communauté propose de mettre en œuvre un hard fork et de revenir sur le statut, cela provoquera inévitablement une énorme controverse. Supposons que vous et moi disposions d'une grosse somme d'argent, comment choisirons-nous : récupérer l'argent ou respecter l'immuabilité de la blockchain ? Le point de Vitalik est le suivant : les projets qui dépendent d'Ethereum doivent gérer correctement les risques, et ne doivent pas essayer de gagner le consensus social d'Ethereum, et lier fortement la vie et la mort du projet à Ethereum.
Pour en revenir à la discussion d'EigenLayer, la gestion des risques se concentre sur le fait qu'AVS doit définir des règles de réduction objectives, en chaîne et attribuables pour éviter les désaccords. Par exemple, la double signature de blocs sur Ethereum ; la signature de blocs invalides d'une autre chaîne dans un pont inter-chaînes léger basé sur des nœuds ; la preuve de dépôt EigenDA discutée ci-dessus, et ainsi de suite. Ce sont des règles de confiscation claires.
Épilogue
EigenLayer devrait achever le lancement du réseau principal au début de l'année prochaine et lancer son produit phare EigenDA. De nombreux projets d'infrastructure ont annoncé leur coopération avec EigenLayer. Nous avons discuté d'EigenDA, MEV et PEPC ci-dessus, et de nombreuses discussions intéressantes sont en cours autour de différents cas d'utilisation. La réhypothécation devient l’un des récits dominants sur le marché. Nous continuerons à suivre les progrès d’EigenLayer et à partager nos avis !
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
EigenLayer : Replenishment introduit la révolution de la confiance dans le middleware
Source : IOSG Ventures
Au cours de la dernière année, EigenLayer a publié son livre blanc, finalisé une ronde de financement de série A de 50 millions de dollars et lancé la première phase de son réseau principal. Au cours de cette période, la communauté Ethereum a également tenu des discussions approfondies autour d'EigenLayer et de ses cas d'utilisation. Cet article suivra et triera ces discussions.
arrière-plan
Dans l'écosystème Ethereum, certains services middleware (tels que les oracles) ne s'appuient pas entièrement sur la logique en chaîne, ils ne peuvent donc pas s'appuyer directement sur le consensus et la sécurité d'Ethereum et doivent rediriger le réseau de confiance. La pratique habituelle consiste à gérer d’abord le projet, puis à introduire des incitations symboliques pour attirer les participants au système et réaliser progressivement la décentralisation.
Cela pose au moins deux difficultés. Premièrement, l'introduction d'un mécanisme d'incitation nécessite des coûts supplémentaires : le coût d'opportunité pour que les participants achètent des jetons pour participer à l'engagement, et le coût opérationnel pour le côté projet pour maintenir la valeur des jetons. Deuxièmement, même si les coûts mentionnés ci-dessus sont payés et qu’un réseau décentralisé est construit, sa sécurité et sa durabilité restent inconnues. Pour les projets de start-up, ces deux points sont particulièrement délicats.
L'idée d'EigenLayer est d'assurer la sécurité économique de ces middlewares (Actively Validated Services, AVS) en re-staking par les jalonneurs Ethereum existants. Si ces réengagements travaillent honnêtement, ils peuvent être récompensés, et s’ils font le mal, l’exposition initiale à l’Ethereum sera perdue.
Les avantages sont les suivants : premièrement, la partie projet n'a pas besoin de diriger elle-même le nouveau réseau de confiance, mais elle le confie au validateur Ethereum, ce qui réduit autant que possible le coût en capital ; deuxièmement, la sécurité économique du validateur Ethereum. L'ensemble est très solide, de sorte que la sécurité a également été garantie dans une certaine mesure. Du point de vue des donateurs d'Ethereum, le réengagement leur procure des revenus supplémentaires. Tant qu'il n'y a pas d'intention malveillante subjective, le risque global est contrôlable.
Sreeram, le fondateur d'EigenLayer, a mentionné un jour les trois cas d'utilisation et modèles de confiance d'EigenLayer sur Twitter et sur les podcasts :
# Participants au système
EigenLayer agit comme un marché ouvert, reliant trois acteurs majeurs.
Avec ces concepts de base, examinons les cas d'utilisation spécifiques d'EigenLayer.
EigenDA
EigenDA est le produit phare lancé par EigenLayer. La solution est dérivée de Danksharding, la solution d'extension Ethereum. Parmi eux, le Data Availability Sampling (DAS) est également largement utilisé dans les projets DA tels que Celestia et Avail. Dans ce chapitre, nous donnons une introduction rapide à DAS, puis examinons la mise en œuvre d'EigenDA et ses innovations.
En tant que solution frontale pour Danksharding, EIP-4844 introduit la « transaction transportant des objets blob ». Chaque transaction transportera une taille de données supplémentaire d'environ 125 Ko. Dans le contexte de l'expansion du partage de données, les nouvelles données augmenteront sans aucun doute la charge pesant sur les nœuds. Alors, existe-t-il un moyen de faire en sorte que le nœud télécharge uniquement une petite partie des données et de vérifier également que toutes les données sont disponibles ?
L'approche DAS consiste à laisser les nœuds échantillonner de manière aléatoire une petite partie des données à plusieurs reprises. Chaque échantillonnage réussi augmentera la confiance que le nœud pense que les données sont disponibles. Une fois qu'un certain niveau prédéfini est atteint, les données sont considérées comme disponibles. Cependant, il est toujours possible pour un attaquant de cacher une petite partie des données – nous avons également besoin d’une certaine sorte de tolérance aux pannes.
DAS utilise le codage d'effacement (Erasure Coding). L'idée principale du codage par effacement est de diviser les données en morceaux, puis de coder ces morceaux pour générer des morceaux redondants supplémentaires. Ces blocs redondants contiennent une partie des informations des blocs de données d'origine, de sorte que lorsque certains blocs de données sont perdus ou endommagés, les blocs de données perdus peuvent être récupérés via les blocs redondants. De cette manière, le codage par effacement offre redondance et fiabilité au DAS.
De plus, nous devons également vérifier si les blocs redondants résultants sont correctement codés, car les données originales ne peuvent pas être reconstruites en utilisant de mauvais blocs redondants. Danksharding adopte l'engagement KZG (Kate-Zaverucha-Goldberg). L'engagement KZG est une méthode permettant de vérifier un polynôme en prouvant que sa valeur à un emplacement spécifique est cohérente avec une valeur numérique spécifiée.
Le prouveur choisit un polynôme p(x) et utilise p(x) pour calculer les engagements pour chaque bloc de données, appelés C1, C2, ..., Cm. Le prouveur publiera l'engagement avec le bloc de données. Pour vérifier un encodage, le vérificateur peut échantillonner aléatoirement t points x1, x2, ..., xt et demander au prouveur d'ouvrir des engagements à ces points : p(x1), p(x2), ..., p(xt ) . En utilisant l'interpolation lagrangienne, le vérificateur peut reconstruire le polynôme p(x) à partir de ces t points. Le vérificateur peut désormais utiliser le polynôme reconstruit p(x) et les blocs de données pour recalculer les engagements C1', C2', ..., Cm' et vérifier qu'ils correspondent aux engagements publiés C1, C2, ..., Cm.
En bref, grâce aux engagements KZG, les vérificateurs n'ont besoin que d'un petit nombre de points pour vérifier l'exactitude de l'ensemble du codage. De cette façon, nous obtenons le DAS complet.
EigenLayer emprunte des idées à DAS et les applique à EigenDA.
Premièrement, les nœuds EigenDA sont réimplantés et enregistrés dans le contrat EigenLayer.
Deuxièmement, après avoir obtenu les données, le séquenceur divise les données en plusieurs blocs, utilise le codage d'effacement pour générer des blocs redondants et calcule l'engagement KZG correspondant à chaque bloc de données. Sequencer publie un par un les engagements de KZG dans le cadre du contrat EigenDA en tant que témoin.
Par la suite, le séquenceur distribue le bloc de données ainsi que son engagement KZG à chaque nœud EigenDA un par un. Une fois que le nœud a obtenu l'engagement KZG, il le compare à l'engagement KZG sur le contrat EigenDA, stocke le bloc de données après avoir confirmé qu'il est correct et le signe.
Ensuite, le séquenceur collecte ces signatures, génère des signatures agrégées et les publie dans le contrat EigenDA, et le contrat EigenDA vérifie les signatures. Une fois la vérification de la signature correcte, l’ensemble du processus est terminé.
Dans le processus ci-dessus, le nœud EigenDA prétend uniquement avoir stocké le bloc de données via des signatures. Nous avons également besoin d'un moyen de garantir que le nœud EigenDA ne ment pas. EigenDA adopte la preuve de garde.
L'idée de la preuve de séquestre est de mettre une "bombe" dans les données. Une fois que le nœud la signe, elle sera coupée. Afin de mettre en œuvre la preuve de séquestre, il est nécessaire de concevoir : une valeur secrète pour distinguer les différents nœuds DA afin d'éviter la triche ; une fonction spécifique au nœud DA, prenant en entrée les données DA et la valeur secrète, et la présence ou l'absence de des bombes comme sortie. Si le nœud ne stocke pas toutes les données qu'il est censé stocker, cette fonction ne peut pas être calculée. Dankrad a partagé plus de détails sur la preuve d'engagement sur son blog.
S'il y a un nœud paresseux, n'importe qui peut soumettre une preuve au contrat EigenDA, et le contrat vérifiera la preuve, et si la vérification est réussie, le nœud paresseux sera condamné à une amende.
En termes de configuration matérielle requise, l'engagement de KZG de calculer 32 Mo de données en 1 seconde nécessite environ 32 à 64 processeurs centraux, mais cette exigence concerne uniquement le côté séquenceur et n'imposera pas de charge au nœud EigenDA. Dans le réseau de test d'EigenDA, le débit de 100 nœuds EigenDA a atteint 15 Mo/s, tandis que la demande de bande passante de téléchargement des nœuds n'était que de 0,3 Mo/s (beaucoup inférieure aux exigences pour l'exécution des validateurs Ethereum).
**En résumé, nous pouvons voir qu'EigenDA a réussi à dissocier la disponibilité des données et le consensus, et que la propagation des blocs de données n'est plus limitée par le goulot d'étranglement du protocole de consensus et le faible débit du réseau P2P. Parce qu'EigenDA équivaut à un tour gratuit sur le consensus Ethereum : le processus par lequel Sequencer émet des engagements KZG et des signatures globales, vérifie les signatures par des contrats intelligents et punit les nœuds malveillants se produit tous sur Ethereum, et Ethereum fournit des garanties de consensus, il n'est donc pas nécessaire pour redémarrer le réseau de confiance. **
Actuellement, le DAS en tant que technologie présente certaines limites. Nous devons supposer que les contreparties malveillantes utiliseront tous les moyens possibles pour tromper les nœuds légers et les amener à accepter de fausses données. Sreeram avait expliqué ce qui suit dans son tweet.
Pour qu'un seul nœud ait une probabilité suffisamment élevée que les données soient disponibles, les conditions suivantes doivent être remplies :
Nous pouvons laisser plusieurs nœuds légers effectuer un échantillonnage aléatoire pour répondre à la concurrence et au caractère aléatoire, mais il n'existe actuellement aucun bon moyen de répondre à l'échantillonnage IP privé. Il existe donc encore des vecteurs d’attaque contre le DAS, de sorte que le DAS n’offre actuellement que de faibles garanties. Ces problèmes sont toujours activement résolus.
Couche propre et MEV
Sreeram a parlé de l'utilisation d'EigenLayer dans la pile MEV lors du sommet MEVconomics. Sur la base des primitives cryptoéconomiques de jalonnement et de slashing, les proposants peuvent mettre en œuvre les quatre fonctionnalités suivantes, qui constituent le troisième point mentionné ci-dessus – le cas d'utilisation de l'engagement du validateur.
Activation basée sur les événements
Des protocoles tels que Gelato permettent de réagir à des événements spécifiques en chaîne. C'est-à-dire une surveillance continue des événements sur la chaîne, et lorsqu'un événement se produit, certaines opérations prédéfinies sont déclenchées. Ces tâches sont généralement effectuées par des auditeurs/exécuteurs tiers.
On l'appelle « tiers » car il n'y a aucun lien entre l'auditeur/exécuteur et le proposant qui gère réellement l'espace de bloc. Supposons qu'un auditeur/exécuteur déclenche une transaction mais (pour une raison quelconque) ne soit pas inclus dans un bloc par un proposant, ce qui ne peut pas être attribué et n'apporte donc pas de garanties économiques déterministes.
Si ce service est fourni par des proposants qui participent au restaking, ils peuvent prendre des engagements crédibles quant au déclenchement des opérations, et si ces transactions ne sont pas incluses dans le bloc, le proposant est slashé. Cela offre des garanties plus solides par rapport aux auditeurs/exécuteurs tiers.
Dans des applications pratiques (telles que les protocoles de prêt), l’un des objectifs de la fixation du taux de surdimensionnement est de couvrir les fluctuations de prix sur une certaine période. Ceci est lié à la fenêtre de temps précédant la liquidation, un ratio de surdimensionnement plus élevé signifie une période tampon plus longue. Si la majorité des transactions adoptent une stratégie de réaction événementielle avec de fortes garanties fournies par le proposant, alors (pour les actifs liquides) la volatilité du ratio de surdimensionnement peut être limitée à quelques intervalles de blocs, réduisant ainsi le taux de surdimensionnement et améliorant efficacité du capital.
Enchères en bloc partiel
Dans la conception actuelle de MEV-Boost, le proposant sous-traite complètement l'espace du bloc au constructeur et ne peut recevoir et proposer passivement que l'intégralité du bloc soumis par le constructeur. Les constructeurs constituent une infime minorité par rapport aux proposants plus largement distribués, et ils peuvent s'entendre pour censurer et faire chanter des transactions spécifiques, car les proposants ne peuvent pas inclure les transactions qu'ils souhaitent dans MEV-Boost.
EigenLayer propose MEV-Boost++ pour mettre à niveau MEV-Boost, introduit la partie proposant dans le bloc et le proposant peut inclure n'importe quelle transaction dans la partie proposant. Le proposant peut également construire un bloc alternatif B-alt en même temps, et proposer ce bloc alternatif B-alt lorsque le relais ne libère pas le Builder_part. Cette flexibilité garantit non seulement la résistance à la censure, mais résout également le problème de la vivacité des relais.
Ceci est cohérent avec la conception de la couche de protocole - l'objectif de crList proposé par ePBS, c'est-à-dire que nous devons garantir qu'un large éventail de proposants peuvent participer à la décision de la composition du bloc pour obtenir une résistance à la censure.
Chiffrement à seuil
Dans la solution MEV basée sur le chiffrement à seuil, les clés de chiffrement et de déchiffrement sont gérées par un groupe de nœuds distribués. Les utilisateurs chiffrent les transactions, qui sont déchiffrées et exécutées après avoir été incluses dans un bloc.
Cependant, le chiffrement à seuil repose sur l’hypothèse d’honnêteté majoritaire. Si la plupart des nœuds sont malveillants, la transaction déchiffrée peut ne pas être incluse dans le bloc. Les proposants effectuant un restaking peuvent s'engager de manière crédible sur des transactions cryptées pour garantir leur inclusion dans les blocs. Si le proposant n'inclut pas la transaction décryptée, elle sera coupée. Bien entendu, si une majorité malveillante ne libère pas la clé de déchiffrement, alors le proposant peut proposer un bloc vide.
Enchères Blockspace à long terme
Les enchères de blocs d'espace à long terme permettent aux acheteurs de blocs d'espace de réserver à l'avance le futur bloc d'espace pour un validateur. Les validateurs qui participent au re-staking peuvent prendre des engagements crédibles et seront perdus s'ils n'incluent pas la transaction de l'acheteur à son expiration. Cette garantie d’accès à l’espace de bloc présente quelques cas d’utilisation pratiques. Par exemple, l'oracle doit alimenter les prix sur une certaine période ; Arbitrum publie les données L2 sur Ethereum L1 toutes les 1 à 3 minutes, Optimism toutes les 30 secondes - 1 minute, etc.
#PEPC
Revenons au PEPC (Protocol-enforced Proposer Commitment), qui a été largement discuté par la communauté Ethereum récemment. Le PEPC est en fait la promotion ou la généralisation de l’ePBS.
Décomposons cette chaîne logique une par une.
Il existe une relation subtile entre PEPC et EigenLayer. Il n'est pas difficile de constater qu'il existe certaines similitudes entre les cas d'utilisation du PEPC mentionnés ci-dessus et les cas d'utilisation du producteur de blocs d'EigenLayer. Cependant, une différence importante entre EigenLayer et PEPC est que les proposants qui participent au réengagement peuvent théoriquement toujours violer leurs engagements, même s'ils seront punis financièrement ; tandis que PEPC se concentre sur "Application du protocole", c'est-à-dire obligatoire est implémenté au niveau de la couche de protocole. Si la promesse ne peut pas être exécutée, le bloc sera invalide.
(PS : d'un simple coup d'œil, il est facile de constater qu'EigenDA est similaire à Danksharding et que MEV-Boost++ est similaire à ePBS. Ces deux services sont comme la version opt-in de la conception de la couche de protocole. Par rapport à la couche de protocole, c'est une solution plus rapide pour le marché. , suivre le rythme de ce qu'Ethereum fera à l'avenir et maintenir l'alignement d'Ethereum grâce à un nouvel engagement).
Ne surchargez pas le consensus Ethereum ?
Il y a quelques mois, l'article de Vitalik, Don't Overload Ethereum Consensus, était considéré par la plupart comme une critique de Resttaking. L'auteur pense qu'il s'agit simplement d'un rappel ou d'un avertissement visant à Maintenir le consensus social, l'accent étant mis sur le consensus social et non sur la négation d'un nouvel engagement.
Au début d’Ethereum, l’attaque DAO a suscité une énorme controverse et la communauté a eu une discussion animée sur l’opportunité de faire un hard fork. Aujourd’hui, l’écosystème Ethereum, dont Rollup, contient déjà un grand nombre d’applications. Il est donc très important d’éviter de provoquer de grands désaccords au sein de la communauté et de maintenir la cohérence du consensus social.
Hermione crée une couche 2 réussie et affirme que, parce que sa couche 2 est la plus grande, elle est intrinsèquement la plus sécurisée, car s'il y a un bug provoquant le vol de fonds, les pertes seront si importantes que la communauté n'aura pas le choix. mais à forker pour récupérer les fonds des utilisateurs Risque élevé.
La citation ci-dessus tirée du texte original en est un bon exemple. Aujourd'hui, le TVL total de L2 dépasse les 10 milliards de dollars américains et s'il y a un problème, il sera extrêmement impliqué. À l'heure actuelle, si la communauté propose de mettre en œuvre un hard fork et de revenir sur le statut, cela provoquera inévitablement une énorme controverse. Supposons que vous et moi disposions d'une grosse somme d'argent, comment choisirons-nous : récupérer l'argent ou respecter l'immuabilité de la blockchain ? Le point de Vitalik est le suivant : les projets qui dépendent d'Ethereum doivent gérer correctement les risques, et ne doivent pas essayer de gagner le consensus social d'Ethereum, et lier fortement la vie et la mort du projet à Ethereum.
Pour en revenir à la discussion d'EigenLayer, la gestion des risques se concentre sur le fait qu'AVS doit définir des règles de réduction objectives, en chaîne et attribuables pour éviter les désaccords. Par exemple, la double signature de blocs sur Ethereum ; la signature de blocs invalides d'une autre chaîne dans un pont inter-chaînes léger basé sur des nœuds ; la preuve de dépôt EigenDA discutée ci-dessus, et ainsi de suite. Ce sont des règles de confiscation claires.
Épilogue
EigenLayer devrait achever le lancement du réseau principal au début de l'année prochaine et lancer son produit phare EigenDA. De nombreux projets d'infrastructure ont annoncé leur coopération avec EigenLayer. Nous avons discuté d'EigenDA, MEV et PEPC ci-dessus, et de nombreuses discussions intéressantes sont en cours autour de différents cas d'utilisation. La réhypothécation devient l’un des récits dominants sur le marché. Nous continuerons à suivre les progrès d’EigenLayer et à partager nos avis !