Restaking, AVS, EigenLayer
도입
Restaking은 "Ethereum 보안을 빌려 쓴다"는 문장만으로 이해하면 위험하다. 제품팀이 실제로 확인해야 할 것은 어느 operator가 어떤 AVS에 opt-in했고, 그 AVS가 어떤 작업을 검증하며, fault가 발생했을 때 어떤 slashing 또는 payment rule이 작동하는가다. oracle, bridge, DA, keeper, automation이 stablecoin 제품에 들어오면 AVS 장애는 곧 가격, mint, redemption, reconciliation 장애가 된다.
이 레슨의 목표는 restaking을 투자 상품이 아니라 dependency model로 읽는 것이다. 높은 yield나 큰 TVL보다 중요한 것은 fault definition, operator concentration, liveness fallback, product ledger와의 분리다.
학습 목표
- restaking과 AVS의 보안 공유 모델을 설명한다.
- 외부 검증 네트워크 의존성을 제품 위험으로 평가한다.
개념 설명
핵심 개념
- restaking과 AVS의 보안 공유 모델을 설명한다.
- 외부 검증 네트워크 의존성을 제품 위험으로 평가한다.
검증 지점
- slashing, withdrawal delay, operator concentration 근거가 stage 결정에 연결되는가
- AVS 장애가 결제 제품의 중단, 축소 출시, 관찰 중 어느 결정으로 이어지는가
- restaking 모델을 설명했다.
실습 산출물
- Restaking, AVS, EigenLayer 이해 점검
- Restaking, AVS, EigenLayer 적용 과제
- 월간 재검토가 가능한가
AVS는 검증 네트워크이자 운영 의존성이다
EigenLayer whitepaper는 staker가 EigenLayer smart contract에 추가 slashing 조건을 허용하고, oracle network, bridge, DA layer, keeper network 같은 module을 검증할 수 있다고 설명한다. AVS는 off-chain container와 on-chain slashing/payment contract를 함께 갖는 구조로 이해하면 쉽다.
핵심은 "shared security"가 자동 안전을 뜻하지 않는다는 점이다. AVS마다 작업 내용, slashing 가능성, operator set, upgrade authority, liveness guarantee가 다르다. stablecoin 제품은 AVS output을 원장에 바로 반영하지 않고 reconciliation layer를 둬야 한다.
stablecoin 제품과 연결되는 지점
| 연결 지점 | AVS가 제공할 수 있는 것 | 반드시 확인할 질문 |
|---|---|---|
| Oracle | price, PoR, NAV feed | 잘못된 값이 objective하게 증명되고 slashing되는가 |
| Bridge | cross-chain message attestation | double attestation이나 equivocation을 막는가 |
| DA | rollup data availability | data withholding을 누가 어떻게 증명하는가 |
| Keeper | liquidation, peg defense, scheduled settlement | missed job에 대한 liveness guarantee가 있는가 |
| Automation | reconciliation, NAV update, reporting | 실패 시 fallback operator나 manual run이 있는가 |
risk model
| 리스크 | 설명 | stablecoin 대응 |
|---|---|---|
| Correlated slashing | 같은 operator가 여러 AVS에서 동시에 실패 | operator diversification dashboard |
| Weak slashing | fault를 onchain으로 증명하기 어렵다 | objective fault 여부와 dispute path 검토 |
| Liveness failure | operator가 일을 하지 않는다 | fallback provider, stale output timeout |
| Operator concentration | 소수 operator에 stake와 작업이 몰린다 | concentration threshold와 review trigger |
| AVS upgrade risk | slashing/payment rule이 바뀐다 | governance, timelock, change alert |
| Yield chasing | reward만 보고 dependency를 채택한다 | risk-adjusted adoption decision |
코드로 확인하기
restaking과 AVS는 yield source가 아니라 추가 slashing surface다. 코드에서는 어떤 service에 얼마를 노출하고, 어떤 이벤트가 risk dashboard를 바꾸는지 표현해야 한다.
백엔드AVS exposure 계산
type AvsPosition = { avsId: string; restakedEth: bigint; slashingBps: number; correlatedWith: string[];};function worstCaseLoss(position: AvsPosition) { return position.restakedEth * BigInt(position.slashingBps) / 10_000n;}function totalCorrelatedExposure(positions: AvsPosition[], group: string) { return positions .filter((position) => position.correlatedWith.includes(group)) .reduce((sum, position) => sum + worstCaseLoss(position), 0n);}AVS를 여러 개 붙였다고 risk가 분산되는 것은 아니다. 같은 validator set, 같은 operator, 같은 oracle dependency를 공유하면 손실이 함께 터질 수 있다.
운영slashing event ingestion schema
{ "event": "avs_slashing_detected", "avsId": "price-oracle-avs", "operator": "operator-17", "slashingBps": 250, "affectedService": "stablecoin-risk-dashboard", "action": "pause_new_yield_allocation"}이 이벤트는 알림으로 끝나면 안 된다. stablecoin reserve나 yield strategy에 연결돼 있다면 신규 배분 중지, exposure 축소, 사용자 공지 판단까지 이어져야 한다.
강의 포인트
Restaking/AVS를 stablecoin 제품에 붙일 때는 "보안이 더 강하다"보다 "어떤 실패를 누가 책임지는가"를 먼저 묻는다. AVS 기반 oracle이 틀린 price를 내면 mint를 멈출 수 있는가. bridge AVS가 double attestation을 하면 추가 mint를 차단할 수 있는가. keeper AVS가 liquidation을 놓치면 peg defense가 어떤 상태로 전환되는가.
실무 검토는 다음 순서로 진행한다.
- AVS가 검증하는 작업을 한 문장으로 정의한다.
- fault proof가 objective하게 제시될 수 있는지 확인한다.
- operator set, stake 분포, uptime, client diversity를 수치로 본다.
- AVS output을 product ledger로 바로 쓰지 않고 quarantine/reconciliation 단계를 둔다.
- 장애 시 fallback path와 user-facing 상태를 정의한다.
실무 예시
AVS 기반 Proof of Reserve feed를 stablecoin reserve dashboard에 붙인다고 가정한다.
| 단계 | 정상 경로 | 실패 경로 |
|---|---|---|
| Feed update | AVS가 reserve value를 제출한다. | update timeout 또는 conflicting value 감지 |
| Validation | internal policy가 source timestamp와 deviation을 확인한다. | deviation threshold 초과 시 quarantine |
| Ledger impact | dashboard에 verified 상태로 반영한다. | mint/redeem policy에는 반영하지 않고 manual review |
| Incident | operator health와 AVS status를 기록한다. | fallback feed, pause rule, disclosure 준비 |
이 설계에서 중요한 점은 dashboard와 mint policy를 분리하는 것이다. reserve feed가 늦거나 불확실하면 "표시 데이터가 늦다"로 끝낼 수 있지만, mint acceptance policy에 바로 연결되어 있으면 사용자 자금과 compliance risk가 커진다.
흔한 오해와 실패 시나리오
| 오해 | 실패 장면 | 바로잡는 기준 |
|---|---|---|
| restaked ETH가 많으면 AVS output은 안전하다. | fault가 objective하게 증명되지 않아 slashing이 작동하지 않는다. | stake size와 slashing enforceability를 분리해 본다. |
| AVS 장애는 infra 문제라 제품 상태와 무관하다. | oracle/bridge output이 멈춰 mint, redeem, dashboard가 동시에 영향을 받는다. | AVS dependency boundary와 fallback state를 product state machine에 넣는다. |
| operator는 많을수록 자동으로 분산된다. | 실제 stake와 작업이 소수 operator에 집중된다. | operator concentration과 client diversity를 주기적으로 확인한다. |
| restaking yield를 reserve asset으로 넣으면 수익성이 좋아진다. | slashing, liquidity, accounting risk가 reserve 안정성을 훼손한다. | stablecoin reserve와 yield strategy를 별도 risk bucket으로 둔다. |
실습 과제
- Restaking, AVS, EigenLayer 이해 점검: AVS 하나를 골라 operator set, slashing rule, dependency boundary, liveness fallback을 표로 정리한다.
- Restaking, AVS, EigenLayer 적용 과제: AVS 기반 oracle 또는 bridge를 stablecoin product에 붙인다고 가정하고 due diligence checklist를 작성한다.
output accepted,output stale,conflicting output,manual review,fallback used상태를 포함한다.
완료 기준
- restaker, operator, AVS, slashing/payment rule의 관계를 설명했다.
- slashing 가능성, liveness, operator concentration, upgrade risk를 제품 위험으로 정리했다.
- AVS dependency checklist와 fallback policy를 만들었다.
근거 자료
- Restaking AVS EigenLayer: 10-인프라-MEV-리스테이킹/02-Restaking-AVS-EigenLayer.md
- EigenLayer Whitepaper: https://docs.eigencloud.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf