@BabylonLabs_io Ich starrte länger als erwartet in eine Zeile in den Staking-Contract-Dokumenten von Babylon hinein: Jede Validator-Instanz sollte für jedes unterschiedliche PoS-System, das sie validiert, einen eigenen EOTS-Schlüssel verwenden. Drei Validatoren, die vier PoS-Systeme absichern, ergeben zwölf separate Schlüssel – jeder aktiv, jeder eine potenzielle Schwachstelle. Einen einzelnen Schlüssel über zwei Systeme hinweg wiederzuverwenden, um Overhead zu sparen, und ein einzelnes geleaktes Geheimnis kostet dich nicht nur eine Delegation: Es slashed jede Menge an Stake, die mit diesem Schlüssel verbunden ist, über alle Netzwerke hinweg, die er berührt hat.

Einer dieser exakten Fehler existierte bereits auf der Restaking-Seite von Ethereum. Das ursprüngliche Design von EigenLayer erlaubte, dass der gesamte delegierte Stake eines Operators durch jede einzelne AVS, in die er sich einklinkte, geslashed wurde – ohne Isolation. Erst ein dediziertes Protokoll-Upgrade, ELIP-003, brachte auf Infrastrukturebene sichere Key-Rotation, -Revocation und -Recovery in das System. Das ist ein Restaking-Netzwerk mit Milliardenbudget, das offenbar erkannt hat, dass das Key-Management-Problem real genug war, um eine maßgeschneiderte Lösung zu benötigen.

Babylon läuft in dasselbe strukturelle Risiko hinein, ohne dass diese Schicht bereits gebaut ist. Die Anforderung, separate EOTS-Schlüssel pro PoS-System zu betreiben, existiert zwar, aber die Rotation-, Revocation- und Recovery-Tooling, die EigenLayer nachträglich erst entwickeln musste, ist nicht Bestandteil der aktuellen Spezifikation. Multi-Staking wird bislang rein auf der Yield-Seite vermarktet: ein BTC-Deposit, mehrere Reward-Streams. Niemand kalkuliert ein, dass das Key-Inventar im gleichen N-fach-zu-M-fach-Verhältnis skaliert wie die Rewards, und zwar ohne das protokollseitige Sicherheitsnetz, das Ethereum’s Restaking-Layer irgendwann erst aufbauen musste.

Ethereum brauchte ein dediziertes Upgrade, um zu verhindern, dass Key-Mismanagement systemisch wird. Babylon skaliert dieselbe Exposition, bevor es dieses Kapitel überhaupt aufgeschlagen hat.

Ein Netzwerk, das das Upside von Restaking kopiert, ohne dessen Sicherheitsfixes schon zu kopieren, läuft das ungelöste Problem aus dem letzten Zyklus auf dem Asset dieses Zyklus durch.
#baby $BABY $CYS $HEI
Was ist das größte Risiko von Multi-Staking?

🔑 Key management
50%
📉 Correlated slash
25%
⚙️ Too complex
0%
🤷 Not worried
25%
4 Stimmen • Abstimmung beendet