En novembre dernier, nous avions présenté EigenLayer dans cet article « EigenLayer : Bringing Ethereum-level trust to middleware ». Depuis près d'un an, 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 du réseau principal. Au cours de cette période, la communauté Ethereum a également eu 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 machines Oracle) ne s'appuient pas entièrement sur la logique de la 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. L’approche habituelle consiste à gérer d’abord le projet, puis à introduire des incitations symboliques pour attirer les participants au système et parvenir progressivement à la décentralisation.
Cela pose au moins deux difficultés. La première est que l’introduction d’un mécanisme d’incitation nécessite des coûts supplémentaires : le coût d’opportunité pour les participants d’acheter des jetons pour participer à l’engagement, et le coût de fonctionnement pour la partie au projet pour maintenir la valeur des jetons. Deuxièmement, même si les coûts ci-dessus sont payés et qu’un réseau décentralisé est construit, sa sécurité et sa durabilité restent inconnues. Ces deux points sont particulièrement délicats pour les projets de start-up.
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, mais s’ils font le mal, leur exposition initiale à l’Ethereum sera perdue.
Les avantages de ceci sont les suivants : premièrement, la partie du projet n'a pas besoin de diriger elle-même le nouveau réseau de confiance, mais le sous-traite aux validateurs Ethereum, réduisant ainsi les coûts d'investissement autant que possible ; deuxièmement, la sécurité économique de l'ensemble des validateurs Ethereum est très solide, de sorte que la sécurité est également garantie dans une certaine mesure. Du point de vue des donateurs d'Ethereum, le réengagement leur procure un revenu supplémentaire. Tant qu'il n'y a pas d'intention malveillante subjective, le risque global est contrôlable.
Sreeram, le fondateur d'EigenLayer, a mentionné trois cas d'utilisation et modèles de confiance d'EigenLayer sur Twitter et sur des podcasts :
Confiance économique. Autrement dit, la réutilisation de l’exposition au jalonnement Ethereum, le jalonnement de jetons de valeur plus élevée 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 s'engagent à certains engagements crédibles par rapport à leur exposition promise. Ci-dessous, nous donnerons quelques exemples pour illustrer davantage.
## Participants au système
Source : IOSG Ventures
EigenLayer sert de marché ouvert qui relie les trois principaux acteurs.
*Réengagement. Si vous êtes exposé au jalonnement Ethereum, vous pouvez participer au nouveau jalonnement en transférant les informations de retrait à EigenLayer, 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, l'AVS doit rémunérer les réhypothécateurs 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
![IOSG Ventures : Un regard sur les derniers progrès et cas d'utilisation d'EigenLayer dans le domaine du "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-7417ebaed1-dd1a6f -6d2ef1)
Source : Dankrad Feist
En tant que solution frontale pour Danksharding, EIP-4844 introduit « Blob-carrying Transaction », chaque transaction transportera 125 Ko de données supplémentaires. Dans le contexte de l'expansion du partage de données, les données nouvellement ajoutées augmenteront sans aucun doute la charge sur les nœuds. Alors, existe-t-il un moyen pour le nœud de télécharger uniquement une petite partie des données et de vérifier également que toutes les données sont disponibles ?
Ce que fait DAS, c'est permettre aux nœuds d'échantillonner de manière aléatoire une petite partie des données plusieurs fois. Chaque échantillonnage réussi augmente la confiance du nœud dans la disponibilité des données, et 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 un engagement sur chaque bloc de données, appelé 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 x 1, x 2, ..., xt et demander au prouveur d'ouvrir des engagements en ces points : p(x 1), p(x 2), ... , 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 C 1', C 2', ..., Cm' et vérifier qu'ils sont cohérents avec les engagements publiés C 1, C 2, . .. , Cm correspond.
En bref, grâce aux engagements KZG, le vérificateur n'a besoin que d'un petit ensemble de points pour vérifier l'exactitude de l'ensemble du codage. De cette façon, nous obtenons le DAS complet.
Comment
Source : EigenLayer
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, une fois que le séquenceur a obtenu les données, il divise les données en plusieurs blocs, utilise des codes 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 envers le contrat EigenDA en tant que témoin.
Ensuite, le séquenceur distribue les blocs de données avec leurs engagements KZG à chaque nœud EigenDA un par un. Une fois que le nœud a obtenu l'engagement KZG, il le compare avec l'engagement KZG sur le contrat EigenDA. Après avoir confirmé qu'il est correct, le bloc de données est stocké et signé.
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, car le nœud EigenDA prétend uniquement stocker le bloc de données via la signature. Nous avons également besoin d'un moyen de garantir que les nœuds EigenDA ne mentent pas. EigenDA utilise une 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 réaliser une 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 tricherie ; une fonction spécifique aux nœuds DA, qui prend les données DA et la valeur secrète en entrée, et s'il y a une bombe en 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.
![IOSG Ventures : Un regard sur les derniers progrès et cas d'utilisation d'EigenLayer dans le domaine du "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-5e2b72172c-dd1a6f-6d2ef1 )
Source : EigenLayer
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, KZG promet environ 32 à 64 cœurs de processeur pour calculer 32 Mo de données en 1 seconde, 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'est 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 réalise le découplage entre 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 à profiter gratuitement du consensus Ethereum : le processus par lequel Sequencer émet des engagements KZG et des signatures agrégées, vérifie les signatures par des contrats intelligents et coupe les nœuds malveillants se produit tous sur Ethereum, et Ethereum fournit des garanties de consensus, il n'y a donc pas besoin de redémarrer le réseau de confiance.
Problèmes de 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 indépendamment et aléatoirement un groupe d'échantillons à échantillonner, et la contrepartie ne sait pas qui a demandé quels échantillons. De cette façon, la contrepartie ne peut pas modifier la stratégie en conséquence pour tromper les nœuds.
Échantillonnage simultané : le DAS doit être effectué par plusieurs nœuds en même temps, afin que l'attaquant ne puisse pas distinguer l'échantillonnage d'un nœud de celui des 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 permettre à plusieurs nœuds légers d'effectuer un échantillonnage aléatoire pour satisfaire la concurrence et le caractère aléatoire, mais il n'existe actuellement aucun bon moyen de satisfaire l'échantillonnage IP privé. Il existe donc encore des vecteurs d’attaque contre le DAS, ce qui fait que le DAS n’offre actuellement que de faibles garanties. Ces problèmes sont toujours activement résolus.
Couche propre et MEV
Source : EigenLayer
Sreeram a parlé de l'utilisation d'EigenLayer dans la pile MEV lors du MEVconomics Summit. En se concentrant sur les primitives cryptoéconomiques du staking et du slashing, les proposants peuvent mettre en œuvre les quatre caractéristiques 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 le bloc par le proposant. Cela ne peut pas être attribué et ne peut donc pas apporter de garanties économiques déterministes.
Si ce service est fourni par les proposants participants, ils peuvent prendre des engagements crédibles quant au déclenchement des opérations, et si ces transactions ne sont pas finalement incluses dans le bloc, le proposant est sabré. Cela offre des garanties plus solides que les auditeurs/exécuteurs tiers.
Dans des applications pratiques (telles que les accords 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. Cela est lié à la fenêtre de temps précédant la liquidation, où un taux 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 l'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. Il n'y a qu'une poignée de constructeurs par rapport aux proposants plus largement distribués, et ils peuvent s'entendre pour censurer et extorquer des transactions spécifiques, car les proposants ne peuvent pas inclure les transactions qu'ils souhaitent dans MEV-Boost.
Source : EigenLayer
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.
Source : Dankrad Feist
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, un groupe de nœuds distribués gère les clés de chiffrement et de déchiffrement. Les utilisateurs chiffrent les transactions, qui ne sont déchiffrées et exécutées qu'une fois la transaction incluse dans un bloc.
Le chiffrement à seuil repose cependant sur l’hypothèse d’honnêteté majoritaire. Si la plupart des nœuds agissent mal, les transactions décryptées peuvent ne pas être incluses dans le bloc. Les proposants de re-staking peuvent prendre un engagement crédible envers la transaction cryptée pour garantir son inclusion dans le bloc. Si le proposant n'inclut pas la transaction décryptée, elle sera coupée. Bien entendu, si une majorité malveillante de nœuds ne libère pas la clé de déchiffrement, le proposant peut proposer un bloc vide.
Enchères Blockspace à long terme
Les enchères d'espaces de blocs à long terme permettent aux acheteurs d'espaces de blocs de réserver à l'avance de futurs espaces de blocs pour un validateur donné. Les validateurs participant au re-staking peuvent prendre des engagements crédibles et seront réduits s'il n'y a pas de transaction impliquant des acheteurs à l'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
Source: Barnabé Monnot
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émontons cette chaîne logique une par une.
Tout d'abord, prenons comme exemple le PBS MEV-Boost hors protocole. Actuellement, MEV-Boost s'appuie sur le mécanisme de slashing au niveau du protocole Ethereum, c'est-à-dire que si le proposant signe deux en-têtes de bloc différents à la même hauteur de bloc, ils seront sabrés. Étant donné que le proposant doit signer l'en-tête de bloc soumis par le relais, cela équivaut à former une liaison entre l'en-tête de bloc et le proposant, le relais a donc des raisons de croire que le bloc du constructeur sera proposé. Sinon, le proposant ne peut être contraint qu'à abandonner le slot, ou à proposer un bloc différent (ce qui entraînerait une barre oblique). À ce stade, 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 », c'est-à-dire garantir que les blocs publiés par des constructeurs honnêtes seront proposés. En tant que PBS intégré au protocole, ePBS sera intégré à la couche consensus d’Ethereum et garanti par le protocole.
PEPC est une autre extension d'ePBS. ePBS promet que "le bloc du constructeur sera proposé". Si cette question est étendue aux enchères de blocs partiels, aux enchères de blocs parallèles, aux futures enchères de blocs, etc., nous pouvons permettre aux proposants de faire plus de choses - et la couche de protocole garantit que ces choses sont exécutées 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 participant au réengagement peuvent toujours théoriquement rompre leurs engagements, même s'ils seront punis financièrement ; tandis que le PEPC se concentre sur "l'application du protocole", c'est-à-dire sur le protocole. layer Obligatoire est implémenté sur le bloc. 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 va faire à l'avenir et maintenir l'alignement d'Ethereum grâce au re-staking).
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 estime 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 plutôt que sur le refus 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, héberge déjà un grand nombre d’applications. Il est donc très important d’éviter de provoquer de grandes divisions 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 de l'original est un bon exemple. Aujourd'hui, le TVL total de L2 dépasse les dizaines de milliards de dollars et s'il y a un problème, cela impliquera beaucoup. À l'heure actuelle, si la communauté propose de mettre en œuvre un hard fork et de faire reculer l'État, cela provoquera inévitablement une énorme controverse. En supposant que vous et moi disposions d’une grosse somme d’argent, comment choisirons-nous : récupérer l’argent ou craindre 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.
Conclusion
Source : EigenLayer
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.
IOSG Ventures : Un regard sur les dernières avancées et cas d'utilisation d'EigenLayer dans le domaine du "re-pledge"
Auteur original : Jiawei, IOSG Ventures
Source : EigenLayer
En novembre dernier, nous avions présenté EigenLayer dans cet article « EigenLayer : Bringing Ethereum-level trust to middleware ». Depuis près d'un an, 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 du réseau principal. Au cours de cette période, la communauté Ethereum a également eu 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 machines Oracle) ne s'appuient pas entièrement sur la logique de la 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. L’approche habituelle consiste à gérer d’abord le projet, puis à introduire des incitations symboliques pour attirer les participants au système et parvenir progressivement à la décentralisation.
Cela pose au moins deux difficultés. La première est que l’introduction d’un mécanisme d’incitation nécessite des coûts supplémentaires : le coût d’opportunité pour les participants d’acheter des jetons pour participer à l’engagement, et le coût de fonctionnement pour la partie au projet pour maintenir la valeur des jetons. Deuxièmement, même si les coûts ci-dessus sont payés et qu’un réseau décentralisé est construit, sa sécurité et sa durabilité restent inconnues. Ces deux points sont particulièrement délicats pour les projets de start-up.
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, mais s’ils font le mal, leur exposition initiale à l’Ethereum sera perdue.
Les avantages de ceci sont les suivants : premièrement, la partie du projet n'a pas besoin de diriger elle-même le nouveau réseau de confiance, mais le sous-traite aux validateurs Ethereum, réduisant ainsi les coûts d'investissement autant que possible ; deuxièmement, la sécurité économique de l'ensemble des validateurs Ethereum est très solide, de sorte que la sécurité est également garantie dans une certaine mesure. Du point de vue des donateurs d'Ethereum, le réengagement leur procure un revenu supplémentaire. Tant qu'il n'y a pas d'intention malveillante subjective, le risque global est contrôlable.
Sreeram, le fondateur d'EigenLayer, a mentionné trois cas d'utilisation et modèles de confiance d'EigenLayer sur Twitter et sur des podcasts :
## Participants au système
Source : IOSG Ventures
EigenLayer sert de marché ouvert qui relie les trois principaux acteurs.
*Réengagement. Si vous êtes exposé au jalonnement Ethereum, vous pouvez participer au nouveau jalonnement en transférant les informations de retrait à EigenLayer, 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, l'AVS doit rémunérer les réhypothécateurs 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.
![IOSG Ventures : Un regard sur les derniers progrès et cas d'utilisation d'EigenLayer dans le domaine du "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-7417ebaed1-dd1a6f -6d2ef1)
Source : Dankrad Feist
En tant que solution frontale pour Danksharding, EIP-4844 introduit « Blob-carrying Transaction », chaque transaction transportera 125 Ko de données supplémentaires. Dans le contexte de l'expansion du partage de données, les données nouvellement ajoutées augmenteront sans aucun doute la charge sur les nœuds. Alors, existe-t-il un moyen pour le nœud de télécharger uniquement une petite partie des données et de vérifier également que toutes les données sont disponibles ?
Ce que fait DAS, c'est permettre aux nœuds d'échantillonner de manière aléatoire une petite partie des données plusieurs fois. Chaque échantillonnage réussi augmente la confiance du nœud dans la disponibilité des données, et 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 un engagement sur chaque bloc de données, appelé 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 x 1, x 2, ..., xt et demander au prouveur d'ouvrir des engagements en ces points : p(x 1), p(x 2), ... , 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 C 1', C 2', ..., Cm' et vérifier qu'ils sont cohérents avec les engagements publiés C 1, C 2, . .. , Cm correspond.
En bref, grâce aux engagements KZG, le vérificateur n'a besoin que d'un petit ensemble de points pour vérifier l'exactitude de l'ensemble du codage. De cette façon, nous obtenons le DAS complet.
Source : EigenLayer
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, une fois que le séquenceur a obtenu les données, il divise les données en plusieurs blocs, utilise des codes 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 envers le contrat EigenDA en tant que témoin.
Ensuite, le séquenceur distribue les blocs de données avec leurs engagements KZG à chaque nœud EigenDA un par un. Une fois que le nœud a obtenu l'engagement KZG, il le compare avec l'engagement KZG sur le contrat EigenDA. Après avoir confirmé qu'il est correct, le bloc de données est stocké et signé.
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, car le nœud EigenDA prétend uniquement stocker le bloc de données via la signature. Nous avons également besoin d'un moyen de garantir que les nœuds EigenDA ne mentent pas. EigenDA utilise une 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 réaliser une 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 tricherie ; une fonction spécifique aux nœuds DA, qui prend les données DA et la valeur secrète en entrée, et s'il y a une bombe en 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.
![IOSG Ventures : Un regard sur les derniers progrès et cas d'utilisation d'EigenLayer dans le domaine du "re-pledging"] (https://img-cdn.gateio.im/resized-social/moments-7f230462a9-5e2b72172c-dd1a6f-6d2ef1 )
Source : EigenLayer
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, KZG promet environ 32 à 64 cœurs de processeur pour calculer 32 Mo de données en 1 seconde, 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'est 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 réalise le découplage entre 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 à profiter gratuitement du consensus Ethereum : le processus par lequel Sequencer émet des engagements KZG et des signatures agrégées, vérifie les signatures par des contrats intelligents et coupe les nœuds malveillants se produit tous sur Ethereum, et Ethereum fournit des garanties de consensus, il n'y a donc pas besoin de 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 permettre à plusieurs nœuds légers d'effectuer un échantillonnage aléatoire pour satisfaire la concurrence et le caractère aléatoire, mais il n'existe actuellement aucun bon moyen de satisfaire l'échantillonnage IP privé. Il existe donc encore des vecteurs d’attaque contre le DAS, ce qui fait que le DAS n’offre actuellement que de faibles garanties. Ces problèmes sont toujours activement résolus.
Couche propre et MEV
Source : EigenLayer
Sreeram a parlé de l'utilisation d'EigenLayer dans la pile MEV lors du MEVconomics Summit. En se concentrant sur les primitives cryptoéconomiques du staking et du slashing, les proposants peuvent mettre en œuvre les quatre caractéristiques 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 le bloc par le proposant. Cela ne peut pas être attribué et ne peut donc pas apporter de garanties économiques déterministes.
Si ce service est fourni par les proposants participants, ils peuvent prendre des engagements crédibles quant au déclenchement des opérations, et si ces transactions ne sont pas finalement incluses dans le bloc, le proposant est sabré. Cela offre des garanties plus solides que les auditeurs/exécuteurs tiers.
Dans des applications pratiques (telles que les accords 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. Cela est lié à la fenêtre de temps précédant la liquidation, où un taux 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 l'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. Il n'y a qu'une poignée de constructeurs par rapport aux proposants plus largement distribués, et ils peuvent s'entendre pour censurer et extorquer des transactions spécifiques, car les proposants ne peuvent pas inclure les transactions qu'ils souhaitent dans MEV-Boost.
Source : EigenLayer
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.
Source : Dankrad Feist
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, un groupe de nœuds distribués gère les clés de chiffrement et de déchiffrement. Les utilisateurs chiffrent les transactions, qui ne sont déchiffrées et exécutées qu'une fois la transaction incluse dans un bloc.
Le chiffrement à seuil repose cependant sur l’hypothèse d’honnêteté majoritaire. Si la plupart des nœuds agissent mal, les transactions décryptées peuvent ne pas être incluses dans le bloc. Les proposants de re-staking peuvent prendre un engagement crédible envers la transaction cryptée pour garantir son inclusion dans le bloc. Si le proposant n'inclut pas la transaction décryptée, elle sera coupée. Bien entendu, si une majorité malveillante de nœuds ne libère pas la clé de déchiffrement, le proposant peut proposer un bloc vide.
Enchères Blockspace à long terme
Les enchères d'espaces de blocs à long terme permettent aux acheteurs d'espaces de blocs de réserver à l'avance de futurs espaces de blocs pour un validateur donné. Les validateurs participant au re-staking peuvent prendre des engagements crédibles et seront réduits s'il n'y a pas de transaction impliquant des acheteurs à l'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
Source: Barnabé Monnot
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émontons 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 participant au réengagement peuvent toujours théoriquement rompre leurs engagements, même s'ils seront punis financièrement ; tandis que le PEPC se concentre sur "l'application du protocole", c'est-à-dire sur le protocole. layer Obligatoire est implémenté sur le bloc. 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 va faire à l'avenir et maintenir l'alignement d'Ethereum grâce au re-staking).
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 estime 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 plutôt que sur le refus 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, héberge déjà un grand nombre d’applications. Il est donc très important d’éviter de provoquer de grandes divisions 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 de l'original est un bon exemple. Aujourd'hui, le TVL total de L2 dépasse les dizaines de milliards de dollars et s'il y a un problème, cela impliquera beaucoup. À l'heure actuelle, si la communauté propose de mettre en œuvre un hard fork et de faire reculer l'État, cela provoquera inévitablement une énorme controverse. En supposant que vous et moi disposions d’une grosse somme d’argent, comment choisirons-nous : récupérer l’argent ou craindre 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.
Conclusion
Source : EigenLayer
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 !