내가 Ethereum에 스테이킹한 ETH가 하나의 체인만 지키는 데서 끝나지 않는다면 어떨까요?
같은 ETH가 가격 오라클의 데이터 신뢰성을 검증하고, 크로스체인 브릿지의 자산 이동을 감시하며, 롤업의 운영을 보호하고, 데이터 가용성 레이어까지 지탱한다면 말입니다. 이는 단순히 보상 기회가 늘어나는 이야기가 아닙니다. Blockchain 보안이 구축되고 배분되는 방식 자체가 달라지는 변화입니다.
기존 Proof-of-Stake 환경에서 스테이킹은 비교적 명확했습니다. 검증자는 ETH를 예치하고 Ethereum 네트워크의 블록 생성과 검증에 참여합니다. 정직하게 행동하면 보상을 받고, 규칙을 어기면 예치 자산의 일부가 슬래싱됩니다. 즉, 하나의 스테이크는 하나의 네트워크 보안에 연결되는 구조였습니다.
하지만 새로운 서비스가 등장할 때마다 같은 문제가 반복됐습니다.
- 새 롤업은 자체 검증자와 인센티브 구조를 만들어야 합니다.
- 새 브릿지는 충분한 담보와 감시 체계를 확보해야 합니다.
- 새 오라클은 데이터 조작을 막을 독립적인 검증 네트워크를 구축해야 합니다.
- 작은 프로토콜은 자체 토큰의 가치가 낮아 공격 비용도 낮아질 수 있습니다.
보안을 만들기 위해 자본, 검증자, 토큰 경제가 매번 새로 필요했던 것입니다.
Restaking: 하나의 스테이크를 여러 보안 작업에 연결하다
Restaking은 이미 Ethereum에 스테이킹된 ETH 또는 stETH 같은 유동성 스테이킹 토큰을 다른 서비스의 검증 작업에도 활용하는 구조입니다. 핵심은 “ETH를 다시 맡긴다”는 표현보다, 기존의 경제적 보안을 여러 서비스에 연결한다는 데 있습니다.
작동 방식은 대체로 다음과 같습니다.
- ETH 스테이커는 자신의 스테이크를 Restaking 프로토콜에 등록하거나 위임합니다.
- 운영자(Operator)는 위임받은 자산을 기반으로 여러 검증 서비스에 참여합니다.
- 오라클, 브릿지, 롤업, 데이터 가용성 서비스 같은 AVS는 이 운영자들에게 검증 업무를 맡깁니다.
- 운영자가 정직하게 작업하면 추가 보상을 받고, 규칙을 위반하면 해당 서비스의 슬래싱 조건에 따라 손실을 볼 수 있습니다.
이 구조를 대표하는 사례가 EigenLayer입니다. EigenLayer는 Ethereum의 스테이킹 자본을 활용해 다양한 AVS(Actively Validated Services)가 보안을 확보하도록 돕는 Restaking 인프라입니다.
쉽게 말해, 개별 프로젝트가 처음부터 경비 인력을 모집하고 보안 예산을 쌓는 대신, 이미 신뢰와 자본이 축적된 Ethereum의 보안 기반을 활용하는 모델입니다.
다섯 개의 네트워크를 지킨다는 말의 의미
“하나의 ETH가 다섯 개의 네트워크를 지킨다”는 표현은 같은 자산이 물리적으로 다섯 곳에 나뉘어 예치된다는 뜻은 아닙니다. 하나의 스테이크가 여러 서비스의 행동 보증금으로 작동한다는 의미에 가깝습니다.
예를 들어 한 운영자가 다음과 같은 역할을 동시에 수행할 수 있습니다.
- 오라클: 외부 가격 데이터가 조작되지 않았는지 검증
- 브릿지: 체인 간 자산 이동 메시지가 유효한지 확인
- 롤업 인프라: 거래 순서나 상태 전환이 규칙에 맞는지 검증
- 데이터 가용성 레이어: 필요한 데이터가 실제로 공개됐는지 감시
- 분산형 서비스: 특정 계산, 증명, 주문 처리 결과를 검증
각 서비스는 서로 다른 기능을 수행하지만, 신뢰할 수 있는 검증자가 규칙을 지키도록 만드는 경제적 동기는 공유할 수 있습니다. 이때 ETH 스테이크는 단순한 예치금이 아니라, 여러 디지털 서비스의 정직성을 담보하는 공용 자본이 됩니다.
Blockchain 보안이 ‘프로젝트별 비용’에서 ‘공유 인프라’로 바뀌는 순간
이 변화가 중요한 이유는 신규 프로젝트의 가장 어려운 문제 중 하나가 보안이기 때문입니다. 기술이 좋아도 검증자 수가 적고 담보 규모가 작다면 공격자는 더 낮은 비용으로 시스템을 흔들 수 있습니다.
Restaking 기반의 공유 보안은 이 진입장벽을 낮출 수 있습니다. 작은 팀도 처음부터 자체 토큰을 발행하고 검증자 집단을 키우는 대신, 검증 서비스를 제공하는 운영자와 Ethereum 기반의 스테이크 풀을 활용할 수 있기 때문입니다.
그 결과 Blockchain 생태계의 경쟁 기준도 달라질 가능성이 큽니다.
보안은 직접 쌓아야 하는 자산이 아니라, 신뢰할 수 있는 방식으로 연결하고 설계해야 하는 인프라가 될 수 있습니다.
물론 보안의 재사용에는 대가가 따릅니다. 하나의 운영자가 여러 AVS에 참여할수록 장애, 버그, 악의적 행위의 영향 범위도 넓어질 수 있습니다. 특히 잘못 설계된 슬래싱 규칙은 추가 수익이 아니라 예상치 못한 손실로 이어질 수 있습니다.
그럼에도 Restaking이 던지는 질문은 분명합니다. 각 네트워크가 각자 보안을 처음부터 만들 필요가 있을까? Ethereum의 스테이크가 여러 서비스의 신뢰 기반으로 확장된다면, 블록체인은 체인들의 집합을 넘어 서로 보안을 공유하는 거대한 인프라 네트워크로 진화할 수 있습니다.
EigenLayer의 무대: Staker, Operator, AVS의 삼각 구조와 Blockchain 보안 공유
Restaking 생태계에는 세 명의 주인공이 있습니다. 자산을 제공하는 Staker, 실제 검증 작업을 수행하는 Operator, 그리고 보안을 빌리는 AVS입니다. 이 세 역할이 맞물리는 순간, 기존 Blockchain 네트워크의 보안 자본은 하나의 체인에만 머물지 않고 여러 서비스로 확장됩니다.
EigenLayer의 핵심은 단순히 ETH를 다시 예치하는 데 있지 않습니다. 이미 Ethereum에 스테이킹된 경제적 신뢰를 여러 검증 서비스가 활용할 수 있도록 연결하는 데 있습니다.
| 역할 | 핵심 기능 | 얻는 가치 | 주요 부담 |
|---|---|---|---|
| Staker | ETH 또는 LST를 재스테이킹하고 Operator에게 위임 | 기본 스테이킹 보상 외 추가 수익 기회 | AVS 규칙에 따른 추가 슬래싱 위험 |
| Operator | 위임받은 자산을 기반으로 AVS 검증 노드 운영 | 운영 보상 및 수수료 수익 | 다운타임, 이중 서명, 악의적 검증 책임 |
| AVS | 공유 보안을 활용하는 검증 서비스 | 자체 토큰 없이도 보안 확보 가능 | 합의·슬래싱 규칙 설계 책임 |
Staker: 보안 자본을 공급하는 참여자
Staker는 Ethereum에 스테이킹된 ETH 또는 stETH 같은 LST(Liquid Staking Token)를 EigenLayer에 등록하는 참여자입니다. 이들은 자신의 자산을 직접 여러 서비스에 운영하는 대신, 신뢰할 수 있는 Operator에게 위임할 수 있습니다.
Staker의 관점에서 Restaking은 기존 스테이킹 수익 위에 추가 수익 기회를 쌓는 구조입니다. Ethereum 검증 보상에 더해, Operator가 참여하는 AVS의 검증 보상 일부를 받을 수 있기 때문입니다.
다만 수익이 늘어나는 만큼 책임 범위도 넓어집니다. 일반적인 ETH 스테이킹에서는 Ethereum 네트워크의 규칙만 고려하면 되지만, Restaking 참여자는 자신이 위임한 Operator와 연결된 AVS의 성능 및 슬래싱 조건까지 살펴야 합니다. 즉, Staker는 단순 예치자가 아니라 보안 시장에 자본을 공급하는 참여자가 됩니다.
Operator: 보안을 실제로 실행하는 검증자
Operator는 Staker가 위임한 재스테이킹 자산을 바탕으로 AVS의 검증 작업을 수행합니다. 쉽게 말해, Staker가 보안 담보를 제공한다면 Operator는 그 담보를 기반으로 실제 서비스를 운영하는 기술적 실행 주체입니다.
Operator가 수행할 수 있는 업무는 AVS의 성격에 따라 달라집니다.
- 롤업의 트랜잭션 순서 처리 및 검증
- 크로스체인 브릿지 메시지 검증
- 가격 데이터와 외부 정보의 오라클 검증
- 데이터 가용성(DA) 데이터 저장 및 확인
- 분산형 시퀀서 또는 코프로세서 운영
이 과정에서 Operator는 높은 가동률, 올바른 서명, 정확한 프로토콜 실행을 유지해야 합니다. 만약 노드가 장기간 멈추거나, 상충하는 데이터를 서명하거나, AVS가 금지한 행위를 하면 슬래싱 대상이 될 수 있습니다.
따라서 Operator 선택은 Staker에게 매우 중요합니다. 높은 보상률만 보는 것이 아니라 운영 이력, 인프라 안정성, 보안 체계, 참여 AVS의 위험도를 함께 평가해야 합니다.
AVS: 보안을 빌려 쓰는 서비스
AVS는 Actively Validated Service의 약자로, 지속적인 검증자 활동이 필요한 서비스를 뜻합니다. AVS는 자체 검증자 네트워크와 토큰 경제를 처음부터 구축하는 대신, EigenLayer의 재스테이킹 자산과 Operator 네트워크를 활용할 수 있습니다.
예를 들어 새로운 Blockchain 브릿지를 만든 팀이 있다고 가정해 보겠습니다. 이 브릿지가 독자적인 토큰을 발행하고 충분한 검증자 및 담보를 확보하려면 긴 시간과 막대한 인센티브가 필요합니다. 하지만 AVS로 설계하면, 재스테이킹된 ETH를 기반으로 활동하는 Operator 집합을 활용해 초기 보안 수준을 높일 수 있습니다.
AVS가 설계해야 할 핵심은 다음 세 가지입니다.
검증 규칙
어떤 데이터와 행동을 정직한 것으로 인정할지 정의합니다.보상 구조
Operator와 Staker가 참여할 만큼 충분한 수수료와 인센티브를 설계합니다.슬래싱 조건
어떤 행위를 처벌할지 명확하게 정합니다. 이 규칙이 불명확하거나 과도하면 정상 참여자까지 피해를 볼 수 있습니다.
특히 슬래싱 규칙은 AVS의 신뢰도를 좌우합니다. 너무 약하면 공격자를 막기 어렵고, 너무 강하거나 구현이 불완전하면 대규모 오작동과 불필요한 자산 손실을 초래할 수 있습니다.
삼각 구조가 작동하는 방식
EigenLayer의 보안 공유 시장은 다음과 같은 흐름으로 움직입니다.
- Staker가 ETH 또는 LST를 재스테이킹합니다.
- Staker는 특정 Operator에게 자산을 위임합니다.
- Operator는 하나 이상의 AVS에 참여해 검증 업무를 수행합니다.
- AVS는 검증 수수료 또는 토큰 인센티브를 지급합니다.
- Operator와 Staker는 보상을 나누며, 규칙 위반 시 슬래싱 위험을 부담합니다.
이 구조의 핵심은 자본과 노동, 서비스 수요가 분리되어 있다는 점입니다. Staker는 자본을 제공하고, Operator는 기술 운영을 맡으며, AVS는 보안을 필요로 하는 제품을 만듭니다. 각 참여자가 자신의 역할에 집중할 수 있기 때문에, 새로운 서비스는 보안 네트워크를 처음부터 구축하는 부담을 줄일 수 있습니다.
중요한 것은 ‘공유’가 아니라 ‘책임의 연결’이다
Restaking은 하나의 ETH가 여러 서비스의 보안에 기여하도록 만들어 자본 효율성을 높입니다. 그러나 이는 동시에 하나의 실수나 취약점이 여러 참여자에게 영향을 줄 수 있다는 뜻이기도 합니다.
따라서 EigenLayer 생태계에서 중요한 질문은 “보상을 얼마나 더 받을 수 있는가”만이 아닙니다. 어떤 Operator에게 위임하는지, 어떤 AVS의 규칙을 따르는지, 슬래싱 위험이 어디까지 연결되는지를 함께 이해해야 합니다.
Staker, Operator, AVS의 삼각 구조는 Ethereum의 경제적 보안을 더 넓은 Blockchain 서비스로 확장하는 엔진입니다. 그리고 이 구조가 안정적으로 작동할수록, 보안은 개별 프로젝트의 비용이 아니라 여러 프로토콜이 함께 활용하는 공용 인프라가 될 수 있습니다.
Blockchain 스테이킹에서 슬래싱까지: 공유 보안은 어떻게 작동하는가
Staker가 자산을 예치하는 순간, 보상과 위험은 더 이상 한 갈래로만 움직이지 않습니다. 정직한 검증을 수행하면 Ethereum 스테이킹 보상에 더해 AVS 보상까지 얻을 수 있습니다. 반대로 단 한 번의 잘못된 서명, 운영 장애, 스마트 컨트랙트 오류는 재스테이킹한 자산의 손실로 이어질 수 있습니다.
Restaking 기반의 공유 보안은 단순히 “수익률을 높이는 기능”이 아닙니다. 하나의 스테이크를 여러 Blockchain 서비스의 신뢰 기반으로 사용하는 만큼, 보상 구조와 책임 구조도 함께 확장됩니다.
스테이킹: Ethereum 보안에 자본을 맡기는 과정
기존 Proof-of-Stake 환경에서 검증자는 ETH를 예치하고 Ethereum 네트워크의 블록 제안과 검증에 참여합니다. 검증자는 네트워크 규칙에 따라 정상적으로 업무를 수행하는 대가로 보상을 받습니다.
이 구조의 핵심은 경제적 담보입니다. 검증자가 부정한 블록을 승인하거나 네트워크 합의를 훼손하려 하면, 예치한 자산 일부가 슬래싱될 수 있습니다. 즉, 공격으로 얻을 수 있는 이익보다 잃을 위험을 크게 만들어 정직한 행동을 유도하는 방식입니다.
Restaking: 동일한 스테이크를 여러 서비스에 위임하는 구조
Restaking에서는 이미 Ethereum에 스테이킹했거나 LST(Liquid Staking Token)를 보유한 참여자가 해당 자산을 EigenLayer와 같은 프로토콜에 등록합니다. 이후 참여자는 직접 운영하거나, Operator에게 자산을 위임할 수 있습니다.
Operator는 위임받은 스테이크를 기반으로 여러 AVS에 참여합니다. AVS는 오라클, 브릿지, 데이터 가용성 서비스, 롤업 시퀀서 등 별도의 검증이 필요한 인프라를 뜻합니다.
흐름은 다음과 같이 이해할 수 있습니다.
- Staker가 ETH 또는 LST를 재스테이킹한다.
- Staker는 신뢰할 수 있는 Operator에게 운영 권한을 위임한다.
- Operator는 하나 이상의 AVS에서 검증 업무를 수행한다.
- AVS는 정상 운영에 대한 추가 보상을 지급한다.
- 규칙 위반이 발생하면 AVS가 정한 조건에 따라 슬래싱이 실행될 수 있다.
이 과정에서 하나의 자산은 Ethereum의 경제적 보안 기반이면서 동시에 여러 외부 서비스의 보안 담보 역할을 하게 됩니다.
보상은 왜 늘어나는가
재스테이킹 참여자는 일반적으로 여러 수익원을 기대합니다.
- Ethereum 네트워크의 기본 스테이킹 보상
- 유동성 스테이킹 프로토콜 사용에 따른 보상 구조
- AVS가 지급하는 검증 보상 또는 서비스 수수료
- 초기 생태계 참여에 따른 인센티브
AVS 입장에서도 장점이 있습니다. 자체 토큰을 발행하고 검증자 네트워크를 처음부터 확보하지 않아도, 이미 형성된 Ethereum 스테이크 풀과 Operator 생태계를 활용할 수 있기 때문입니다. 작은 프로토콜도 상대적으로 높은 경제적 보안 수준에서 서비스를 시작할 가능성이 생깁니다.
다만 높은 보상은 대개 더 많은 위험을 반영합니다. 추가 수익은 무료로 생기는 것이 아니라, 추가 검증 책임과 슬래싱 가능성에 대한 대가라는 점을 분명히 이해해야 합니다.
슬래싱: 잘못된 행동의 비용을 강제하는 장치
슬래싱은 검증자가 네트워크 또는 AVS의 규칙을 위반했을 때 예치 자산 일부를 삭감하는 제도입니다. 대표적인 원인은 다음과 같습니다.
- 동일한 상황에서 서로 충돌하는 메시지에 서명하는 행위
- 허위 데이터 또는 조작된 검증 결과를 제출하는 행위
- 브릿지·오라클·시퀀서 업무에서 합의 규칙을 위반하는 행위
- 장기간 노드가 중단되어 서비스 가용성을 해치는 경우
- AVS별로 정의된 특정 보안 조건을 위반하는 경우
여기서 중요한 점은 Ethereum 자체의 슬래싱과 AVS 차원의 슬래싱은 규칙과 실행 구조가 구분될 수 있다는 것입니다. Ethereum 합의 규칙 위반은 Ethereum 프로토콜 차원의 처벌 대상이며, AVS 위반은 재스테이킹 계약과 해당 서비스의 설계에 따른 처벌 대상이 됩니다.
그러나 사용자의 관점에서는 같은 경제적 기반인 ETH 또는 ETH 연계 자산이 위험에 노출될 수 있습니다. 따라서 “어느 서비스의 어떤 규칙에 동의했는가”가 핵심 판단 기준이 됩니다.
공유 보안의 강점과 연쇄 위험
공유 보안은 새로운 서비스가 검증자와 담보를 별도로 모으지 않아도 된다는 점에서 매우 효율적입니다. 특히 초기 단계의 Blockchain 인프라는 보안 예산 부족으로 공격에 취약해지기 쉬운데, Restaking은 이 진입장벽을 낮춥니다.
하지만 하나의 스테이크가 여러 AVS에 연결될수록 위험도 서로 얽힙니다. 예를 들어 대형 Operator가 여러 서비스에 동시에 참여한 상태에서 소프트웨어 버그나 키 관리 사고가 발생하면, 복수의 AVS에서 동시에 문제가 발생할 수 있습니다.
이른바 체계적 슬래싱(Systemic Slashing) 위험입니다. 개별 서비스의 오류가 단일 프로젝트의 손실에 그치지 않고, 동일한 Operator와 Staker가 참여한 다른 서비스의 신뢰도까지 흔들 수 있습니다.
참여 전 반드시 확인할 기준
재스테이킹 참여자는 단순 APY보다 아래 항목을 먼저 점검해야 합니다.
- Operator의 운영 이력과 노드 분산도
- 참여 AVS의 역할과 실제 수익 발생 구조
- 슬래싱 조건의 구체성 및 스마트 컨트랙트 감사 여부
- 여러 AVS에 중복 참여할 때의 위험 노출도
- 출금·위임 해제·재위임에 필요한 대기 기간
- LST 사용 시 발생하는 디페깅 및 유동성 위험
공유 보안은 Ethereum의 스테이크를 더 넓은 디지털 인프라로 확장하는 강력한 모델입니다. 그러나 그 본질은 “하나의 담보로 더 많은 일을 맡는 구조”입니다. 추가 보상만큼 추가 책임이 따른다는 사실을 이해하는 것이 Restaking을 바라보는 가장 중요한 출발점입니다.
Blockchain 보안을 빌리는 시장의 탄생과 연쇄 위험
신생 프로토콜이 자체 토큰을 발행하고, 충분한 검증자를 모으며, 공격 비용을 높이기까지는 긴 시간이 필요합니다. 특히 초기 네트워크는 토큰 유동성과 참여자가 부족해 보안이 약해지기 쉽습니다.
Restaking은 이 과정을 크게 단축합니다. 새로운 서비스가 처음부터 독자적인 검증자 네트워크를 구축하는 대신, 이미 Ethereum에 스테이킹된 ETH의 경제적 보안을 활용할 수 있기 때문입니다. 이는 Blockchain 생태계에서 보안이 단순한 기술 기능이 아니라, 필요에 따라 조달하고 배분할 수 있는 인프라 자원으로 바뀌는 변화를 의미합니다.
보안도 ‘서비스’로 조달하는 구조
EigenLayer와 같은 Restaking 구조에서 AVS는 오라클, 브릿지, 데이터 가용성 레이어, 롤업 시퀀서 등 특정 기능을 수행하는 검증 서비스입니다. AVS는 자체 토큰을 발행해 검증자를 유치하지 않아도, Restaking 참여자와 Operator에게 보상을 제공해 필요한 보안 수준을 확보할 수 있습니다.
작동 방식은 비교적 명확합니다.
- Staker는 이미 스테이킹한 ETH 또는 LST를 Restaking 구조에 등록합니다.
- Operator는 위임받은 자산을 바탕으로 하나 이상의 AVS 운영에 참여합니다.
- AVS는 검증 규칙과 보상 조건, 슬래싱 조건을 설정합니다.
- 정직한 검증에는 추가 보상이 지급되고, 부정행위나 장애에는 슬래싱이 적용됩니다.
이 구조가 확산되면, 신생 프로젝트의 경쟁력은 “얼마나 큰 자체 토큰 보안 풀을 만들었는가”보다 “공유 보안을 활용해 어떤 성능과 사용자 경험을 제공하는가”로 이동할 수 있습니다. 즉, 보안은 각 프로젝트가 독점적으로 구축해야 하는 자산에서, 여러 서비스가 연결해 쓰는 공용 레이어에 가까워집니다.
Restaking의 핵심 가치는 보안을 새로 만드는 것이 아니라, 이미 존재하는 경제적 보안을 더 빠르게 연결하는 데 있습니다.
효율의 대가: 같은 담보를 여러 번 쓰는 문제
하지만 자본 효율성이 높아진다는 말은, 같은 담보가 여러 위험에 동시에 노출된다는 뜻이기도 합니다. 하나의 ETH 스테이크가 Ethereum 검증뿐 아니라 여러 AVS의 보증 자산으로 활용될 경우, 해당 자산은 사실상 복수의 의무를 지게 됩니다.
예를 들어 한 Operator가 브릿지 AVS, 오라클 AVS, 데이터 가용성 AVS에 동시에 참여한다고 가정해 보겠습니다. 이 Operator의 운영 환경에 장애가 발생하거나 키가 탈취되면, 단일 문제가 여러 서비스에서 동시에 부정행위 또는 다운타임으로 판정될 수 있습니다. 그 결과 하나의 운영 실패가 다수의 슬래싱 위험으로 번질 가능성이 생깁니다.
이를 금융 관점에서 보면, 하나의 담보를 여러 곳에 재사용하는 재담보화(rehypothecation)와 유사한 구조입니다. 자산 활용도는 높아지지만, 시장 충격이 발생했을 때 손실이 예상보다 넓고 빠르게 전파될 수 있습니다.
연쇄 위험이 발생하는 세 가지 경로
1. 슬래싱 규칙의 설계 실패
AVS마다 슬래싱 조건은 다를 수 있습니다. 문제는 이 규칙이 지나치게 공격적이거나, 정상적인 장애와 악의적 행위를 정확히 구분하지 못할 때 발생합니다.
예를 들어 네트워크 지연, 클라이언트 버그, 잘못된 업그레이드가 다수 Operator에게 동시에 영향을 미쳤는데도 이를 부정행위로 판단한다면 대규모 슬래싱이 발생할 수 있습니다. 보안 강화를 위해 만든 규칙이 오히려 참여자에게 과도한 위험을 전가하는 셈입니다.
따라서 AVS는 단순히 “잘못하면 자산을 삭감한다”는 규칙을 넘어 다음 요소를 정교하게 설계해야 합니다.
- 악의적 행위와 운영 실수의 구분 기준
- 슬래싱 규모와 상한선
- 오류 발생 시 이의 제기 및 복구 절차
- 업그레이드·네트워크 장애 상황의 예외 처리
- 여러 AVS 간 슬래싱 노출의 중복 여부
2. Operator 집중과 공통 장애
공유 보안 모델은 대형 Operator에게 유리하게 작용할 수 있습니다. 이미 인프라, 자본, 운영 인력을 갖춘 사업자는 여러 AVS에 쉽게 참여할 수 있고, Staker의 위임도 더 많이 받을 가능성이 높습니다.
그러나 소수 Operator가 여러 핵심 서비스를 동시에 운영하면, 한 사업자의 장애가 전체 생태계의 공통 장애로 변할 수 있습니다. 특정 클라우드 인프라의 장애, 동일한 소프트웨어 클라이언트의 버그, 운영 키 관리 실패가 여러 AVS에 동시에 영향을 주는 구조입니다.
Blockchain의 탈중앙성은 노드 수만으로 판단하기 어렵습니다. 실제로는 다음 질문이 더 중요합니다.
- 스테이크는 몇 개의 Operator에게 집중되어 있는가?
- 주요 Operator는 같은 클라우드와 소프트웨어를 사용하는가?
- 하나의 장애가 몇 개 AVS에 동시에 영향을 미치는가?
- 사용자는 Operator별 위험 노출을 확인할 수 있는가?
3. 시장 신뢰와 유동성의 동시 충격
대규모 슬래싱은 온체인 자산의 감소에 그치지 않습니다. Restaking 포지션과 연계된 LST, DeFi 담보, 파생상품 시장에도 심리적 충격을 줄 수 있습니다.
특히 참여자가 추가 수익만 보고 위험을 충분히 이해하지 못했다면, 슬래싱 사건 이후 출금·매도·담보 청산이 동시에 발생할 수 있습니다. 이때 AVS의 기술적 실패가 유동성 문제와 시장 신뢰 하락으로 증폭될 가능성이 있습니다.
따라서 Restaking 수익률은 일반 스테이킹 수익률과 동일하게 해석해서는 안 됩니다. 추가 보상에는 스마트 컨트랙트 위험, Operator 위험, AVS별 슬래싱 위험, 유동성 위험이 함께 포함되어 있기 때문입니다.
성장의 조건은 ‘더 많은 보상’이 아니라 ‘더 정교한 위험 관리’
보안을 빌리는 시장은 신생 서비스의 진입 장벽을 낮추고, Ethereum 중심의 공용 보안 레이어를 확장할 수 있습니다. 다만 이 시장이 안정적으로 성장하려면 보상 경쟁보다 위험의 투명한 분리가 먼저 이루어져야 합니다.
핵심은 각 참여자가 자신이 어떤 AVS에, 어떤 Operator를 통해, 어느 정도의 슬래싱 위험으로 노출되는지 명확히 알 수 있게 만드는 것입니다. AVS별 위험 등급, Operator 분산도, 슬래싱 조건, 손실 대응 절차가 투명하게 공개되어야 공유 보안은 효율성과 신뢰를 함께 확보할 수 있습니다.
Restaking은 보안을 더 쉽게 얻는 방식이지만, 동시에 보안 사고의 영향 범위를 더 넓힐 수 있는 구조입니다. 결국 이 기술의 성공은 얼마나 많은 ETH가 재스테이킹되는가보다, 공유된 담보 위에서 발생할 수 있는 연쇄 위험을 얼마나 정교하게 통제하는가에 달려 있습니다.
Ethereum과 Blockchain: Web3의 신뢰 레이어가 될 수 있는가
Restaking이 성숙하면 Ethereum의 역할은 크게 달라질 수 있습니다. 지금까지 Ethereum은 거래를 처리하고 스마트 컨트랙트를 실행하는 대표적인 Blockchain 네트워크였다면, 앞으로는 다양한 Web3 서비스가 보안을 구매하고 검증을 위임하는 공용 신뢰 인프라가 될 가능성이 있습니다.
핵심은 EigenLayer와 같은 Restaking 구조입니다. 이미 Ethereum에 스테이킹된 ETH가 오라클, 브릿지, 데이터 가용성(DA) 서비스, 롤업 시퀀서 등 여러 AVS의 검증 자원으로 활용되면, 새 프로토콜은 처음부터 자체 토큰과 검증자 네트워크를 구축할 필요가 줄어듭니다. 대신 Ethereum 생태계의 경제적 보안을 활용해 빠르게 서비스를 시작할 수 있습니다.
보안을 직접 만들던 시대에서, 보안을 조달하는 시대로
기존 Blockchain 프로젝트는 대체로 다음의 과정을 거쳤습니다.
- 자체 토큰을 발행한다.
- 검증자에게 보상을 제공한다.
- 충분한 스테이킹 자산과 참여자를 확보한다.
- 공격 비용이 높아질 때까지 보안 취약성을 감수한다.
하지만 초기 프로젝트에는 이 과정이 매우 어렵습니다. 토큰 가치와 유동성이 낮으면 공격 비용도 낮아지고, 검증자가 적으면 네트워크의 탈중앙성도 약해집니다. 특히 브릿지나 오라클처럼 큰 자산 가치를 보호해야 하는 서비스는 초기 보안 설계가 곧 생존 문제로 이어집니다.
Restaking은 이 문제를 다른 방식으로 풉니다. 프로토콜이 직접 보안 네트워크를 처음부터 만드는 대신, 이미 존재하는 ETH 스테이킹 기반의 경제적 담보를 활용하는 것입니다. 이는 클라우드 시대에 기업이 직접 서버를 구축하지 않고 컴퓨팅 자원을 구매하는 방식과 닮아 있습니다. 미래의 Web3에서는 보안 역시 서비스처럼 조달하는 자원이 될 수 있습니다.
Ethereum이 제공할 수 있는 것은 ‘합의’보다 넓다
Ethereum 메인넷의 합의는 Ethereum 자체의 거래와 상태를 보호합니다. 반면 Restaking 기반 AVS는 Ethereum의 스테이킹 자본과 운영자 네트워크를 바탕으로, 메인넷 밖의 검증 작업까지 확장하려는 시도입니다.
예를 들어 다음과 같은 서비스가 공용 보안을 활용할 수 있습니다.
- 롤업 인프라: 시퀀서의 부정 행위, 검증 지연, 데이터 제출 문제를 감시
- 크로스체인 브릿지: 체인 간 자산 이동 메시지의 정당성을 검증
- 오라클 네트워크: 가격, 실물 데이터, 이벤트 결과의 신뢰성을 검증
- 데이터 가용성 서비스: 롤업 데이터가 실제로 공개되고 접근 가능한지 확인
- 분산형 자동화 서비스: 청산, 트랜잭션 실행, 상태 업데이트 등을 검증
이 구조가 널리 채택된다면 Ethereum은 단순히 하나의 체인이 아니라, 여러 체인과 프로토콜이 의존하는 Web3의 신뢰 레이어에 가까워질 수 있습니다. 각 서비스는 기능과 사용자 경험에서 경쟁하고, 보안의 일부는 Ethereum 중심의 공유 인프라에서 확보하는 그림입니다.
다만, ‘공유 보안’이 곧 ‘동일한 보안’은 아니다
여기서 중요한 점이 있습니다. Restaking을 사용한다고 해서 모든 AVS가 자동으로 Ethereum 메인넷과 같은 수준의 보안을 갖는 것은 아닙니다.
AVS의 실제 안전성은 다음 요소에 따라 달라집니다.
슬래싱 규칙의 명확성
어떤 행위를 악의적 행위로 판단할지, 이를 온체인 또는 외부에서 얼마나 정확히 증명할 수 있는지가 중요합니다. 규칙이 모호하면 정직한 운영자가 부당하게 처벌받거나, 반대로 악의적 행위를 제대로 처벌하지 못할 수 있습니다.운영자 집중도
다수의 AVS가 소수 대형 Operator에 의존하면, 공유 보안은 오히려 공유된 단일 실패 지점이 될 수 있습니다. 운영자의 지리적·기술적·경제적 분산이 필요합니다.스마트 컨트랙트와 브리지 설계
Restaking 계약, 위임 구조, 출금 지연, 보상 분배 로직에 취약점이 있다면 큰 규모의 담보가 위험해질 수 있습니다. 보안 감사와 점진적 출시가 필수적입니다.보상과 위험의 균형
추가 수익률이 높아 보여도, 여러 AVS의 슬래싱 위험을 동시에 부담한다면 그것은 단순한 이자가 아니라 복합 리스크의 대가일 수 있습니다. 수익률만으로 참여를 판단해서는 안 됩니다.
즉, Ethereum의 스테이크는 강력한 출발점이지만, 각 서비스의 설계 품질까지 대신 보장하지는 않습니다.
신뢰 레이어가 되기 위한 조건
Ethereum이 진정한 공용 신뢰 레이어로 발전하려면 기술적 확장만으로는 부족합니다. 적어도 세 가지 조건이 필요합니다.
- 안전한 슬래싱 표준: AVS별로 제각각인 처벌 규칙이 무분별하게 확장되지 않도록, 검증 가능한 슬래싱 설계와 위험 관리 기준이 자리 잡아야 합니다.
- 운영자 다변화: 대형 사업자 몇 곳이 대부분의 검증을 맡는 구조를 피하고, 독립적인 운영자가 지속적으로 참여할 수 있어야 합니다.
- 투명한 위험 정보: 스테이커가 자신이 어떤 AVS에 간접 노출되는지, 예상 보상과 최대 손실 가능성이 무엇인지 명확히 확인할 수 있어야 합니다.
결국 Restaking의 미래는 “얼마나 많은 ETH가 재스테이킹됐는가”보다 “그 담보가 얼마나 신중하게 배분되고 관리되는가”에 달려 있습니다.
Ethereum은 Web3의 공용 보안 인프라가 될 잠재력을 갖고 있습니다. 그러나 그 미래는 자동으로 보장되지 않습니다. 공유 보안이 혁신적인 기반이 되려면, 높은 수익률보다 정교한 위험 설계와 탈중앙성, 그리고 신뢰할 수 있는 운영 구조가 먼저 완성되어야 합니다.
