Gegeben einigen Vermögenswert X, bezeichnen wir mit [X] den wieder eingesetzten Vermögenswert, d.h. einen Vermögenswert "Boxen" X, sodass ein Teil oder alle X von einer Partei unter einer beliebigen Bedingung erfasst werden können.
Das grundlegende Beispiel, das von EigenLayer eingeführt wurde, ist das eines einzelnen Stakers, der seine aktuellen ETH erneut stakt. Dazu aktualisiert der einzelne Staker seine Auszahlungsadresse auf die Adresse einesEigenLayer-PodEigenPods sind intelligente Verträge, die verfolgen, für welche Dienste sich der Allein-Staker angemeldet hat, um sie mit seinem Einsatz zu sichern. Der EigenPod wird letztendlich zum Besitzer des soETH-Vermögens, während er den Allein-Staker mit einer neu eingesetzten Darstellung seines gestakten ETH gutschreibt.
Der Besitz des soETH-Vermögens in unserem Rahmen bezeichnet das "erste Recht" über das aus dem Ethereum-Protokoll abgehobene ETH, d.h. besitzt einen vorrangigeren Anspruch als jeder andere Teilnehmer in der Kette. Wenn der Solo-Staker beschließt, ihr ETH aus dem Ethereum-Protokoll abzuziehen, wird das abgehobene ETH durch den EigenPod-Vertrag gefiltert, um zu überprüfen, ob der Solo-Staker berechtigt ist, die gesamte Menge an soETH einzulösen oder nicht (wir werden später sehen, wann dies möglicherweise nicht der Fall ist). Mit unseren Bilanzen:
Wir machen jeden Schritt im Folgenden explizit:
Wir können bereits einige interessante Beobachtungen aus den obigen Bilanzen machen. Die erste ist, dass das Ethereum-Protokoll überhaupt keine Vorstellung von [soETH] hat, da dies nicht auf seiner eigenen Bilanz erscheint. Dieses Problem wurde in „Entbündelung von PBS: Hin zu protokollbasierten Vorschlagsverpflichtungen (PEPC)Ein Validator, der von EigenLayer slashed wurde, hat immer noch einen vollen Staking-Saldo in der Bilanz des Ethereum-Protokolls, was moralisches Risiko und Belohnungsungleichgewichte verursachen kann (ein tatsächlich halbge-staketer Validator erhält immer noch volle Belohnungen vom Ethereum-Protokoll). Wir erläutern das Slashing-Szenario in den folgenden Bilanzen und verwenden beliebige Zahlen, um das Problem zu veranschaulichen:
Dieses Problem wird behoben, sobald EigenLayer den EigenLayer-Slash eines Validierers treu dem Ethereum-Protokoll meldet und die Tabellen neu ausbalanciert. Dies ist möglich mit EIP-7002: Ausführungsschicht auslösbare Exits, wenn auch auf einer groben Ebene, da der binäre Trigger einfach den Validator verlässt, aber immer noch die EigenLayer-Middleware oder der EigenPod benötigt wird, um das Signal an das Ethereum-PoS-Protokoll auszulösen. Dieses Vorgehen ist im Interesse von EigenLayer, denn eine ordnungsgemäße Buchhaltung kommt den über EigenLayer gesicherten Diensten zugute und erhöht letztlich auch das Vertrauen der Betreiber und Re-Staker in die getreue Ausführung der Plattform.
Ein feinerer Auslöser könnte eine teilweise Abhebung des Validator-Guthabens aus dem Ethereum-Konsens erzwingen, ohne den Validator vollständig zu verlassen. Dies ist wünschenswert für EigenLayer-Dienste, die Validatorn teilweise bestrafen möchten, ohne einen Ausstieg auszulösen. Beachten Sie, dass weder EIP-7002 noch durch die Ausführungsschicht ausgelöste teilweise Abhebungen heute im Ethereum-Mainnet verfügbar sind. Beachten Sie auch, dass @mikeneuder/eip-7251-faq">MaxEB (Entfernen der 32 ETH-Obergrenze des Prinzips eines einzelnen Validierers im Einsatz) würde sich gut mit teilweisen Abhebungen kombinieren, um einen zusätzlichen Anreiz für Validierer zu entfernen, desaggregiert zu bleiben (anstatt beispielsweise viele 32 ETH-Validierer anstelle eines einzelnen 2048 ETH-Validierers zu betreiben).
Ohne diese teilweise Abhebungsfunktion besteht ein zusätzlicher Anreiz, die EigenLayer-Buchhaltung von der Ethereum-Protokollbuchhaltung getrennt zu halten, was wie oben erwähnt zu Fehlausrichtungen führen kann. Im Folgenden stellen wir einen Validierer dar, der von EigenLayer um 8 ETH gekürzt wurde, was den Validierer nicht von seinen Konsenspflichten entlässt (das Ausgleichsgleichgewicht beträgt 16 ETH):
Man fragt sich vielleicht, wohin die 8 [soETH] im vorherigen Beispiel gehen. Diese Entscheidung obliegt den EigenLayer-betriebenen aktiv validierten Diensten (AVS). Ein AVS ist ein Dienst, der eine gewisse Einlage als Sicherheit verlangt. Die Einlage ermöglicht es dem Dienst, sich glaubwürdig zu verpflichten, eine bestimmte Leistung zu erbringen, da die Einlage gekürzt werden kann, wenn der Dienst nicht ordnungsgemäß erbracht wird.
Der erneute Staking-Validierer schreibt sich über ihren EigenPod in AVSs ein. Wenn sie dies tun, prägt der EigenPod neue Ansprüche, die den AVSs angeboten werden und das derzeit im EigenPod gehaltene Kollateral repräsentieren. Wir müssen jetzt den Unterschied zwischen zwei Arten von Ansprüchen machen:
Sobald der Validator den Zielen des AVS zuwiderhandelt (z. B. indem er eine Slashing-Bedingung des AVS auslöst), kann das AVS beispielsweise entscheiden, den Anspruch des Validators auf seine ETH-Einsatz zu verbrennen oder den Einsatz als Einnahme für das AVS zu behalten. Wir veranschaulichen diese zweite Option im Folgenden, indem wir annehmen, dass das Ethereum-Protokoll einfach 8 ETH dem EigenPod als teilweisen Abzug nach dem EigenLayer-Slashing-Bericht gutschreibt, woraufhin EigenLayer es an das AVS überweist:
Das Merkmal (und das Risiko), das EigenLayer bietet, ist die Möglichkeit für einen erneuten Staker, neue Verpflichtungen einzugehen, die sie versprechen einzuhalten. Mit anderen Worten, nachdem der Einsatz erneut eingesetzt wurde, kann der erneut eingesetzte Einsatz immer wieder und wieder und wieder eingesetzt werden... Praktischer ausgedrückt, der erneute Staker geht neue Verpflichtungen ein, indem er sich für weitere Dienste über sein EigenPod anmeldet.
Um die volle Allgemeinheit zu erreichen und in Erwartung der folgenden Abschnitte, in denen Vermögenswerte außer soETH erneut gestaked werden, bezeichnen wir mit $X$ den Vermögenswert, der vom erneuten Staker erneut gestaked wird. Mal sehen, wie sich das mehrfache Neustaken bewährt:
Wir bezeichnen das Vermögen X, das p-mal neu angelegt wird, mit [X]p. Im Moment handelt es sich um eine einfache Definition, aber wir werden auf einige der Eigenschaften dieser Vermögenswerte hinweisen, nachdem wir die Schritte dieser Bilanz detailliert beschrieben haben. Das EigenPod ist in der Lage, diese Verbindlichkeiten nach Belieben zu drucken und neue Vermögenswerte zu schmieden, wann immer sich der Neu-Anleger zu neuen AVSs verpflichtet.
Basierend auf den obigen Bilanzen stellen wir uns nun einige Fragen. Wir beobachten, dass Kette Y [X]¹ erhält, während Kette Z [X]² erhält. Handelt es sich bei diesen Vermögenswerten um denselben Typ, und könnten wir einfach sagen, dass sie beide Vermögenswerte des Typs [X] erhalten?
Die Antwort wäre nein, wenn es eine Hierarchie von AVS-Ansprüchen gäbe. Stellen Sie sich ein Szenario vor, in dem der erneute Staker gleichzeitig auf beiden Ketten strafbare Handlungen begeht und beide Ketten das gesamte Sicherheitenkapital kürzen möchten. Wir können dann an zwei Fälle denken:
Im vorherigen Abschnitt haben wir AVSs vorgestellt, die Dienste sind, die der erneut stakende Validator bereitstellt. Das Engagement wird über EigenLayer abgesichert, das das Stake des validierenden Re-Staker übernimmt und Ansprüche von AVSs begleicht.
Aber was ist genau ein AVS? Ähnlich wie wir oben die LST-Protokolle und die LST-Betreiber getrennt haben, macht es hier Sinn, diese zwei funktionellen Rollen separat zu diskutieren und ihnen verschiedene Vermögenswerte und Ansprüche zuzuweisen.
Kurz gesagt verlangt die AVS Sicherheiten, um einen Service anzubieten, z. B. macht die AVS die glaubwürdige Behauptung, dass ein Angriff auf die AVS zum Verlust eines Teils der derzeit von der AVS gehaltenen Sicherheiten führen wird. Die AVS wird hier also als Protokoll betrachtet, das Betreiber für einen Service einbindet. Wir unterscheiden dann zwei Möglichkeiten, wie Re-Staker mit der AVS interagieren können:
In den obigen Abschnitten haben wir den validierenden Re-Staker sowohl als Kapitalanbieter (ihr eigener Einsatz wird erneut eingesetzt) als auch als AVS-Betreiber identifiziert (von ihnen wird erwartet, dass sie einen bestimmten Dienst bereitstellen). Wir können jedoch eine andere Konstruktion in Betracht ziehen, bei der der validierende Re-Staker den AVS nicht selbst betreibt, sondern diese Funktion stattdessen an einen Betreiber delegiert. Dies könnte es Einzelstakern ermöglichen, bei der Rendite mit integrierten Staking-Service-Anbietern (SSPs)/Betreibern zu konkurrieren. Das folgende Beispiel zeigt eine Situation, in der ein einzelner AVS-Betreiber in einigen Ketten Y und Z im Auftrag eines Re-Stakers validiert. Wir gehen davon aus, dass alle AVS-Ansprüche des gleichen Typs [X] sind (keine Anspruchshierarchie).
In diesem Paradigma stellen wir vertraute Konstruktionen wieder her. Ein Vermögenswert wird vom Re-Staker nicht erhalten, was bereits auf die Möglichkeit hinweist, solche Positionen zu liquidieren. Wir werden diese fortgeschrittenen Konstruktionen im nächsten Beitrag diskutieren, aber bevor wir dies tun, wollen wir die laufende Forschung zu "PBS für AVS" erwähnen, um die zentrale Operatorzentralisierung zu reduzieren.
Unter dem Optimistisches Delegationsframework (ODF)vorgeschlagen von Drew Van der Werff (siehe auch Der kürzliche Vortrag von 0xKydo beim Columbia Cryptoeconomics Workshop) kann ein Re-Staker den Betrieb der AVS, die er auf einem offenen Markt von "Co-Prozessoren" abschließt, in Auftrag geben. Co-Prozessoren können mit der "Builder"-Rolle von PBS identifiziert werden, einer spezialisierten Einheit, die in der Lage ist, potenziell intensive Operationen durchzuführen, die für unerfahrene oder rechenbeschränkte Einheiten wie Solo-Staker unzugänglich sind. Co-Prozessoren geben in einem auktionsähnlichen Mechanismus Angebote an die Re-Staker ab, so dass der Re-Staker den profitabelsten Betreiber ermitteln kann. Um die Leistung weiter zu gewährleisten, sind Mitverarbeiter gebundene Teilnehmer, die sich dem Verlust ihrer Bindung aussetzen, wenn sie im Laufe ihrer Tätigkeit eine nachweislich ungültige Arbeit einreichen.
Поділіться
Gegeben einigen Vermögenswert X, bezeichnen wir mit [X] den wieder eingesetzten Vermögenswert, d.h. einen Vermögenswert "Boxen" X, sodass ein Teil oder alle X von einer Partei unter einer beliebigen Bedingung erfasst werden können.
Das grundlegende Beispiel, das von EigenLayer eingeführt wurde, ist das eines einzelnen Stakers, der seine aktuellen ETH erneut stakt. Dazu aktualisiert der einzelne Staker seine Auszahlungsadresse auf die Adresse einesEigenLayer-PodEigenPods sind intelligente Verträge, die verfolgen, für welche Dienste sich der Allein-Staker angemeldet hat, um sie mit seinem Einsatz zu sichern. Der EigenPod wird letztendlich zum Besitzer des soETH-Vermögens, während er den Allein-Staker mit einer neu eingesetzten Darstellung seines gestakten ETH gutschreibt.
Der Besitz des soETH-Vermögens in unserem Rahmen bezeichnet das "erste Recht" über das aus dem Ethereum-Protokoll abgehobene ETH, d.h. besitzt einen vorrangigeren Anspruch als jeder andere Teilnehmer in der Kette. Wenn der Solo-Staker beschließt, ihr ETH aus dem Ethereum-Protokoll abzuziehen, wird das abgehobene ETH durch den EigenPod-Vertrag gefiltert, um zu überprüfen, ob der Solo-Staker berechtigt ist, die gesamte Menge an soETH einzulösen oder nicht (wir werden später sehen, wann dies möglicherweise nicht der Fall ist). Mit unseren Bilanzen:
Wir machen jeden Schritt im Folgenden explizit:
Wir können bereits einige interessante Beobachtungen aus den obigen Bilanzen machen. Die erste ist, dass das Ethereum-Protokoll überhaupt keine Vorstellung von [soETH] hat, da dies nicht auf seiner eigenen Bilanz erscheint. Dieses Problem wurde in „Entbündelung von PBS: Hin zu protokollbasierten Vorschlagsverpflichtungen (PEPC)Ein Validator, der von EigenLayer slashed wurde, hat immer noch einen vollen Staking-Saldo in der Bilanz des Ethereum-Protokolls, was moralisches Risiko und Belohnungsungleichgewichte verursachen kann (ein tatsächlich halbge-staketer Validator erhält immer noch volle Belohnungen vom Ethereum-Protokoll). Wir erläutern das Slashing-Szenario in den folgenden Bilanzen und verwenden beliebige Zahlen, um das Problem zu veranschaulichen:
Dieses Problem wird behoben, sobald EigenLayer den EigenLayer-Slash eines Validierers treu dem Ethereum-Protokoll meldet und die Tabellen neu ausbalanciert. Dies ist möglich mit EIP-7002: Ausführungsschicht auslösbare Exits, wenn auch auf einer groben Ebene, da der binäre Trigger einfach den Validator verlässt, aber immer noch die EigenLayer-Middleware oder der EigenPod benötigt wird, um das Signal an das Ethereum-PoS-Protokoll auszulösen. Dieses Vorgehen ist im Interesse von EigenLayer, denn eine ordnungsgemäße Buchhaltung kommt den über EigenLayer gesicherten Diensten zugute und erhöht letztlich auch das Vertrauen der Betreiber und Re-Staker in die getreue Ausführung der Plattform.
Ein feinerer Auslöser könnte eine teilweise Abhebung des Validator-Guthabens aus dem Ethereum-Konsens erzwingen, ohne den Validator vollständig zu verlassen. Dies ist wünschenswert für EigenLayer-Dienste, die Validatorn teilweise bestrafen möchten, ohne einen Ausstieg auszulösen. Beachten Sie, dass weder EIP-7002 noch durch die Ausführungsschicht ausgelöste teilweise Abhebungen heute im Ethereum-Mainnet verfügbar sind. Beachten Sie auch, dass @mikeneuder/eip-7251-faq">MaxEB (Entfernen der 32 ETH-Obergrenze des Prinzips eines einzelnen Validierers im Einsatz) würde sich gut mit teilweisen Abhebungen kombinieren, um einen zusätzlichen Anreiz für Validierer zu entfernen, desaggregiert zu bleiben (anstatt beispielsweise viele 32 ETH-Validierer anstelle eines einzelnen 2048 ETH-Validierers zu betreiben).
Ohne diese teilweise Abhebungsfunktion besteht ein zusätzlicher Anreiz, die EigenLayer-Buchhaltung von der Ethereum-Protokollbuchhaltung getrennt zu halten, was wie oben erwähnt zu Fehlausrichtungen führen kann. Im Folgenden stellen wir einen Validierer dar, der von EigenLayer um 8 ETH gekürzt wurde, was den Validierer nicht von seinen Konsenspflichten entlässt (das Ausgleichsgleichgewicht beträgt 16 ETH):
Man fragt sich vielleicht, wohin die 8 [soETH] im vorherigen Beispiel gehen. Diese Entscheidung obliegt den EigenLayer-betriebenen aktiv validierten Diensten (AVS). Ein AVS ist ein Dienst, der eine gewisse Einlage als Sicherheit verlangt. Die Einlage ermöglicht es dem Dienst, sich glaubwürdig zu verpflichten, eine bestimmte Leistung zu erbringen, da die Einlage gekürzt werden kann, wenn der Dienst nicht ordnungsgemäß erbracht wird.
Der erneute Staking-Validierer schreibt sich über ihren EigenPod in AVSs ein. Wenn sie dies tun, prägt der EigenPod neue Ansprüche, die den AVSs angeboten werden und das derzeit im EigenPod gehaltene Kollateral repräsentieren. Wir müssen jetzt den Unterschied zwischen zwei Arten von Ansprüchen machen:
Sobald der Validator den Zielen des AVS zuwiderhandelt (z. B. indem er eine Slashing-Bedingung des AVS auslöst), kann das AVS beispielsweise entscheiden, den Anspruch des Validators auf seine ETH-Einsatz zu verbrennen oder den Einsatz als Einnahme für das AVS zu behalten. Wir veranschaulichen diese zweite Option im Folgenden, indem wir annehmen, dass das Ethereum-Protokoll einfach 8 ETH dem EigenPod als teilweisen Abzug nach dem EigenLayer-Slashing-Bericht gutschreibt, woraufhin EigenLayer es an das AVS überweist:
Das Merkmal (und das Risiko), das EigenLayer bietet, ist die Möglichkeit für einen erneuten Staker, neue Verpflichtungen einzugehen, die sie versprechen einzuhalten. Mit anderen Worten, nachdem der Einsatz erneut eingesetzt wurde, kann der erneut eingesetzte Einsatz immer wieder und wieder und wieder eingesetzt werden... Praktischer ausgedrückt, der erneute Staker geht neue Verpflichtungen ein, indem er sich für weitere Dienste über sein EigenPod anmeldet.
Um die volle Allgemeinheit zu erreichen und in Erwartung der folgenden Abschnitte, in denen Vermögenswerte außer soETH erneut gestaked werden, bezeichnen wir mit $X$ den Vermögenswert, der vom erneuten Staker erneut gestaked wird. Mal sehen, wie sich das mehrfache Neustaken bewährt:
Wir bezeichnen das Vermögen X, das p-mal neu angelegt wird, mit [X]p. Im Moment handelt es sich um eine einfache Definition, aber wir werden auf einige der Eigenschaften dieser Vermögenswerte hinweisen, nachdem wir die Schritte dieser Bilanz detailliert beschrieben haben. Das EigenPod ist in der Lage, diese Verbindlichkeiten nach Belieben zu drucken und neue Vermögenswerte zu schmieden, wann immer sich der Neu-Anleger zu neuen AVSs verpflichtet.
Basierend auf den obigen Bilanzen stellen wir uns nun einige Fragen. Wir beobachten, dass Kette Y [X]¹ erhält, während Kette Z [X]² erhält. Handelt es sich bei diesen Vermögenswerten um denselben Typ, und könnten wir einfach sagen, dass sie beide Vermögenswerte des Typs [X] erhalten?
Die Antwort wäre nein, wenn es eine Hierarchie von AVS-Ansprüchen gäbe. Stellen Sie sich ein Szenario vor, in dem der erneute Staker gleichzeitig auf beiden Ketten strafbare Handlungen begeht und beide Ketten das gesamte Sicherheitenkapital kürzen möchten. Wir können dann an zwei Fälle denken:
Im vorherigen Abschnitt haben wir AVSs vorgestellt, die Dienste sind, die der erneut stakende Validator bereitstellt. Das Engagement wird über EigenLayer abgesichert, das das Stake des validierenden Re-Staker übernimmt und Ansprüche von AVSs begleicht.
Aber was ist genau ein AVS? Ähnlich wie wir oben die LST-Protokolle und die LST-Betreiber getrennt haben, macht es hier Sinn, diese zwei funktionellen Rollen separat zu diskutieren und ihnen verschiedene Vermögenswerte und Ansprüche zuzuweisen.
Kurz gesagt verlangt die AVS Sicherheiten, um einen Service anzubieten, z. B. macht die AVS die glaubwürdige Behauptung, dass ein Angriff auf die AVS zum Verlust eines Teils der derzeit von der AVS gehaltenen Sicherheiten führen wird. Die AVS wird hier also als Protokoll betrachtet, das Betreiber für einen Service einbindet. Wir unterscheiden dann zwei Möglichkeiten, wie Re-Staker mit der AVS interagieren können:
In den obigen Abschnitten haben wir den validierenden Re-Staker sowohl als Kapitalanbieter (ihr eigener Einsatz wird erneut eingesetzt) als auch als AVS-Betreiber identifiziert (von ihnen wird erwartet, dass sie einen bestimmten Dienst bereitstellen). Wir können jedoch eine andere Konstruktion in Betracht ziehen, bei der der validierende Re-Staker den AVS nicht selbst betreibt, sondern diese Funktion stattdessen an einen Betreiber delegiert. Dies könnte es Einzelstakern ermöglichen, bei der Rendite mit integrierten Staking-Service-Anbietern (SSPs)/Betreibern zu konkurrieren. Das folgende Beispiel zeigt eine Situation, in der ein einzelner AVS-Betreiber in einigen Ketten Y und Z im Auftrag eines Re-Stakers validiert. Wir gehen davon aus, dass alle AVS-Ansprüche des gleichen Typs [X] sind (keine Anspruchshierarchie).
In diesem Paradigma stellen wir vertraute Konstruktionen wieder her. Ein Vermögenswert wird vom Re-Staker nicht erhalten, was bereits auf die Möglichkeit hinweist, solche Positionen zu liquidieren. Wir werden diese fortgeschrittenen Konstruktionen im nächsten Beitrag diskutieren, aber bevor wir dies tun, wollen wir die laufende Forschung zu "PBS für AVS" erwähnen, um die zentrale Operatorzentralisierung zu reduzieren.
Unter dem Optimistisches Delegationsframework (ODF)vorgeschlagen von Drew Van der Werff (siehe auch Der kürzliche Vortrag von 0xKydo beim Columbia Cryptoeconomics Workshop) kann ein Re-Staker den Betrieb der AVS, die er auf einem offenen Markt von "Co-Prozessoren" abschließt, in Auftrag geben. Co-Prozessoren können mit der "Builder"-Rolle von PBS identifiziert werden, einer spezialisierten Einheit, die in der Lage ist, potenziell intensive Operationen durchzuführen, die für unerfahrene oder rechenbeschränkte Einheiten wie Solo-Staker unzugänglich sind. Co-Prozessoren geben in einem auktionsähnlichen Mechanismus Angebote an die Re-Staker ab, so dass der Re-Staker den profitabelsten Betreiber ermitteln kann. Um die Leistung weiter zu gewährleisten, sind Mitverarbeiter gebundene Teilnehmer, die sich dem Verlust ihrer Bindung aussetzen, wenn sie im Laufe ihrer Tätigkeit eine nachweislich ungültige Arbeit einreichen.