Izuchukwu

The new @eigencloud security model ————————— blog.eigenlayer.xyz/introduc… ————————— Shortcomings of original security model ————————— The original security model had the following structure: each operator can opt into a subset of AVSs, and the entire stake delegated to that operator could be slashed by any of those AVSs, which meant:  1. Less control over slashing risk: An AVS sharing slashable stake could be inadvertently exposed to the risks of slashing by other AVSs. Additionally, the entirety of an operator’s delegated stake is at risk of being slashed by any AVS it opted into.  2. No slashable stake assurances for AVSs: AVSs had no assurance that they would have access to slashable stake when needed. 3. Needs a common slashing veto committee: The system needed a common veto committee to buffer slashing events from becoming systemic.  4. Permissioned onboarding of AVSs: Because of the need for a common veto committee, AVS onboarding needed to be permissioned otherwise the veto committee would be taking on uncalibrated risks. 5. Tragedy of commons for payments: xB$ pooled security is enough and so no avs is incentivized to grow the common stake. ————————— The new security model ————————— The new EigenLayer security model is based on the following key idea: operators can opt into a set of AVSs and for each AVS specify a fraction of stake that’s slashable uniquely by each avs with the fractions adding up to <1. Please read the blog for details (there is a bunch). ————————— Properties: 1. Greater control over slashing risk: With Unique Stake, the risk of slashing is isolated to the individual AVS, and operators can control how much of their stake any AVS can slash. 2. Guaranteed slashable stake: Each AVS knows how much slashable stake they have by adding up the Unique Stake allocated to them across all its operators 3. No need for a common veto committee: Since slashing is localized to individual AVSs, there is no necessity for a common veto committee. Each AVS can specify its own mechanisms for slashing and governance.  4. Permissionless onboarding of AVSs: AVS onboarding is permissionless and only requires operators to opt in. 5. Pooled security via total stake: imagine a 10B$ with all stakers staked equally across all 100 avs. Even though each avs gets 100M$ unique stake. However it is possible to make the attack cost with new stake prohibitive as more than 5B$ is necessary to take over the quorum. 6. AVS Payments incentivized: each avs has a uniquely slashable stake and avs needs to pay for this portion of the stake. No tragedy of the commons. 7. Future Redistribution: the design is forward compatible for redistribution of slashed stake to avs. This feature will not be supported in the v1 release but added on later. ————————— nitter.gq/eigenlayer/status/1833…