라이도 CSM v3: 퍼미션리스 모듈에서 프로토콜의 기반으로

Key Takeaways

• 라이도(Lido)의 커뮤니티 스테이킹 모듈(Community Staking Module, 이하 CSM)은 2024년 출시 이후 1.5년간 퍼미션리스 스테이킹의 가능성을 증명해왔다. 현재 CSM은 라이도 전체 스테이크의 약 7.5%를 차지하며, 이더리움 밸리데이터 세트의 탈중앙화에 기여하고 있다.

• LIP-33을 통해 제안된 CSM v3은 이더리움 펙트라 업그레이드의 핵심인 0x02 밸리데이터를 네이티브로 지원하며, 기존 인스턴스와 별개의 새 인스턴스를 배포하는 듀얼 인스턴스 아키텍처를 채택한다. 이를 통해 퍼미션리스 참여를 15% 이상으로 확대하면서도 밸리데이터 수를 현재 수준 이하로 유지할 수 있다.

• CSM v3의 코드베이스는 라이도 전체 스테이크의 약 90%를 담당하는 큐레이티드 모듈 v2(CM v2)의 기반으로도 활용된다. 퍼미션리스 실험에서 출발한 모듈이 프로토콜 전체의 아키텍처를 규정하게 된 것이며, 이는 라이도의 모듈 설계 철학에서 주목할 만한 전환점이다.

1. 라이도와 커뮤니티 스테이킹

Source: Lido

이전에 CM v2 아티클에서 언급한 바 있듯이, 라이도의 스테이킹 인프라는 스테이킹 라우터(Staking Router)라는 상위 구조 아래 여러 모듈로 구성되어 있다. 각 모듈은 독립적인 밸리데이터 세트를 관리하며, 새로운 예치금은 각 모듈의 남은 용량과 점유율 한도에 따라 자동으로 분배된다.

현재는 세 개의 모듈이 운영 중인데, 큐레이티드 모듈은 DAO 심사를 통과한 전문 노드 오퍼레이터가 참여하는 허가 기반의 모듈이고, 심플 DVT 모듈(Simple DVT Module)은 분산 밸리데이터 기술을 활용한 클러스터 기반 모듈이다. 그리고 CSM은 보증 담보금만 예치하면 누구나 참여할 수 있는 무허가형 모듈이다.

CSM은 라이도 전체에서 약 7.5% 정도로 작은 비중을 차지하는 모듈이지만, 필자는 CSM이야말로 라이도의 미래를 좌우하는 모듈이라고 생각한다. 그 이유는 이 글의 후반부에서 다루겠다.

2. CSM이 걸어온 길

2.1 CSM의 탄생 배경

CSM은 라이도가 오랫동안 받아온 중앙화 비판에 대한 기술적 응답이었다. 라이도 초기에는 큐레이티드 모듈만 존재했고, 이 모듈에 참여하려면 DAO의 심사를 통과해야 했다. 전문 스테이킹 조직만이 참여할 수 있는 구조는 운영 안정성 면에서 유리했지만, 이더리움 커뮤니티의 핵심 가치인 탈중앙화와는 긴장 관계에 놓였다.

CSM은 이 문제를 보증 담보금 메커니즘으로 풀었다. DAO의 심사 대신, 노드 오퍼레이터가 ETH, stETH, 또는 wstETH 형태의 보증 담보금을 예치하면 누구든 밸리데이터를 운영할 수 있게 한 것이다. 보증 담보금은 슬래싱이나 오프라인 등 문제가 발생했을 때 손실을 보전하는 담보 역할을 한다. 신뢰 대신 경제적 인센티브로 정렬을 확보하는 방식이며, 이는 블록체인의 근본 철학과도 맥이 닿아있다.

2024년 메인넷에 배포된 CSM은 빠르게 성장했다. 2025년 3분기에는 이미 점유율 한도(당시 3%)에 도달했고, v2 업그레이드를 거치며 한도가 5%, 이후 7.5%로 순차적으로 확대되었다. 2026년 3월 현재 CSM에는 550개 이상의 독립 오퍼레이터가 참여하고 있으며, 이는 라이도 밸리데이터 세트의 다양성을 실질적으로 높이는 데 기여하고 있다.

2.2 펙트라 업그레이드로 인한 새로운 버전 요구

CSM v2는 식별된 커뮤니티 스테이커(Identified Community Staker, ICS) 프레임워크 도입, 오퍼레이터 유형별 차등 파라미터 설정, 우선순위 큐(Priority Queue) 등 중요한 개선을 이루었다. 그러나 CSM v2가 자리를 잡을 무렵, 이더리움 베이스 레이어에서 CSM의 다음 진화를 요구하는 변화가 일어났다.

2025년 5월 메인넷에 적용된 이더리움의 펙트라(Pectra) 업그레이드가 바로 그것이다. 펙트라는 EIP-7251을 통해 밸리데이터당 최대 유효 잔액을 기존 32 ETH에서 2,048 ETH로 높였다. 이 변경의 핵심은 0x02라는 새로운 출금 자격 증명 유형의 도입이다. 0x02 밸리데이터는 32 ETH에서 2,048 ETH 사이의 금액을 스테이킹할 수 있고, 보상이 잔액 2,048 ETH에 이를 때까지 자동으로 복리 적용된다. 기존 0x01 밸리데이터에서는 32 ETH 초과분이 자동으로 출금되었기 때문에, 복리 효과를 얻으려면 그때마다 새 밸리데이터를 만들어야 했다. CSM v2는 밸리데이터 한 대의 잔액이 32 ETH라는 가정 위에 설계되어 있었고, 이 가정이 무너진 이상 새로운 버전이 불가피해졌다.

3. CSM v3, 무엇이 바뀌는가

라이도 거버넌스 포럼에 최근 올라온 LIP-33은 이러한 맥락에서의 제안이다. 해당 제안은 CSM v3과 큐레이티드 모듈 v2(CM v2)를 하나의 패키지로 묶어 소개하고 있는데, CM v2에 대해서는 기존의 글에서 다룬 바 있으므로, 본 글에서는 CSM v3에 초점을 맞추어 설명하겠다.

3.1 0x02 밸리데이터 네이티브 지원

CSM v3의 가장 큰 변화는 0x02 밸리데이터에 대한 네이티브 지원이다. CSM v3는 단순히 0x02 밸리데이터에 대한 호환성을 갖추는 수준이 아닌, 0x02의 동작 방식을 전제로 모듈 전체를 설계했다.

0x02 밸리데이터의 입금은 두 단계로 이루어진다. 먼저 초기 32 ETH가 입금되어 밸리데이터 인덱스가 할당되고, 이후 탑업(top-up)을 통해 최대 2,048 ETH까지 추가 입금이 진행된다. CSM v3은 이 2단계 흐름을 프로토콜 수준에서 처리한다. 초기 입금 순서를 기록해두었다가, 탑업 단계에서 해당 순서에 따라 추가 입금을 배분하는 방식이다. 탑업 한도는 합의 레이어 증명을 통해 검증되므로, 아직 합의 레이어에 반영되지 않은 미완료 입금을 이중으로 처리하는 것을 방지한다.

3.2 듀얼 인스턴스 아키텍처

0x02를 지원한다고 해서 기존 0x01 밸리데이터를 곧바로 대체할 수는 없다. CSM v3은 두 유형을 한 모듈에서 동시에 지원하는 대신, 별도의 인스턴스로 분리하는 접근을 택했다. 기존 CSM 인스턴스는 v3로 업그레이드되어 0x01 밸리데이터만 계속 지원하고, 0x02 밸리데이터를 위해서는 별도의 새 CSM v3 인스턴스가 배포된다.

왜 이런 구조를 선택했을까?

0x01과 0x02 밸리데이터는 회계 모델이 근본적으로 다르다. 0x01은 단위 기반(1 밸리데이터 = 32 ETH)이고, 0x02는 잔액 기반(32~2,048 ETH 가변)이다. 두 회계 모델을 한 인스턴스에서 동시에 운용하면 복잡성이 크게 증가하고, 보안 감사의 범위도 넓어진다. 라이도가 선택한 방법은 각 인스턴스를 단일 출금 자격 유형에 집중시켜 단순성과 안전성을 보존하는 것이다.

기존 CSM 오퍼레이터 중 0x02로 전환하고 싶은 이들은 기존 인스턴스에서 밸리데이터를 퇴장시키고, 새 인스턴스에서 0x02 밸리데이터를 새로 만들어야 한다. 이 과정을 장려하기 위해 0x02 인스턴스에는 기존 ICS 오퍼레이터를 위한 특별 오퍼레이터 유형이 도입될 예정이며, 입금 우선권(deposit-priority boost)과 더 나은 경제적 조건이 제공된다. LIP-33의 추산에 따르면, 기존 0x01 밸리데이터의 약 80%가 수년 내에 0x02로 전환될 것으로 예상되며, 이 경우 퍼미션리스 밸리데이터의 수가 약 90% 감소하면서도 퍼미션리스 스테이크 규모는 유지되거나 오히려 증가하게 된다.

이러한 밸리데이터 수의 감소는 역설적으로 퍼미션리스 참여의 확대를 가능하게 한다. LIP-33은 퍼미션리스 참여 비율을 현재의 약 7.5%에서 15% 이상으로 확대할 수 있을 것으로 전망한다. 이전에는 밸리데이터 한 대에 32 ETH만 배정할 수 있었으므로, 퍼미션리스 비율을 높이려면 그만큼 밸리데이터 수가 늘어나 네트워크에 부담을 주었다. 0x02 체제에서는 한 밸리데이터가 최대 2,048 ETH까지 담당하므로, 같은 스테이크 규모를 훨씬 적은 밸리데이터로 커버할 수 있다. 이는 곧 퍼미션리스 참여의 확대 여력이 되며, 밸리데이터 통합을 통한 네트워크 혼잡 감소라는 이더리움의 방향성과도 맞닿아있다.

3.3 페널티 및 보상 체계의 정비

참여 구조가 확대되는 만큼, 이를 뒷받침하는 인센티브 체계도 함께 정비되어야 한다. CSM v3은 0x02 밸리데이터의 가변 잔액에 맞추어 페널티와 보상 양쪽의 체계를 재설계했다.

3.3.1 페널티 산정의 변화

기존에는 밸리데이터의 잔액이 32 ETH로 고정되어 있었기에 페널티 산정이 단순했으나, 이제는 실제 출금 잔액을 기준으로 페널티를 계산해야 한다. 퇴장 지연 페널티와 성과 부진 페널티 모두 밸리데이터의 실제 잔액에 비례하여 조정된다. 또한 슬래싱(slashing)된 밸리데이터와 그렇지 않은 밸리데이터의 출금 보고 흐름이 분리된다. 슬래싱된 밸리데이터의 경우, 먼저 슬래싱 사실을 증명한 뒤, 이지 트랙(Easy Track) 모션을 통해 정확한 페널티 금액과 출금 잔액을 보고하는 별도 절차를 거치게 된다.

3.3.2 퇴장 관련 페널티의 구조화

CSM은 v2부터 밸리데이터 퇴장과 관련된 페널티 체계를 운영해왔다. VEBO(Validator Exit Bus Oracle)가 특정 밸리데이터에 퇴장을 요청하면, 노드 오퍼레이터는 오퍼레이터 유형별로 설정된 시간 내에 이를 이행해야 하며, 이 시간을 초과하면 해당 밸리데이터는 지연(stuck) 상태로 기록된다. 퇴장과 관련된 페널티는 세 가지로 구분된다.

• 지연 퇴장 페널티(Delayed Exit Penalty): 제때 퇴장하지 않은 것에 대한 벌금

• 성과 부진 퇴출 페널티(Bad Performance Ejection Penalty): 스트라이크 누적으로 강제 퇴출된 경우에 적용

• 트리거 가능한 퇴장(Triggerable Exit) 수수료: EIP-7002를 통한 강제 퇴장 시 발생하는 비용

CSM v3에서 달라지는 것은 이 페널티들의 산정과 적용 방식이다. 먼저, 모든 퇴장 관련 페널티가 밸리데이터의 실제 출금 잔액에 비례하여 조정되도록 변경되어, 0x02 밸리데이터의 가변 잔액을 반영할 수 있게 되었다. 또한 이 페널티들은 새로 도입된 ExitPenalties.sol 컨트랙트에서 통합 관리되며, 기록 시점에 즉시 차감되는 것이 아니라 밸리데이터가 실제로 출금되는 시점에 일괄 적용된다. 출금 보고 과정에서 해당 밸리데이터에 지연 또는 성과 부진 기록이 있는지 확인하고, 있을 경우 기록된 페널티와 TE 수수료를 보증 담보금에서 차감하는 구조다.

3.3.3 보상 분배 및 청구의 개선

CSM v3은 패널티뿐만 아니라 보상의 분배와 청구에 관한 전체 과정도 함께 정비했다. CSM에 대한 기존의 보상흐름은 아래와 같다.

1. 이더리움의 AccountingOracle이 보고할 때마다 StakingRouter가 CSM에 할당된 보상을 민팅하여 FeeDistributor.sol에 전달한다.

2. CSM 퍼포먼스 오라클이 각 오퍼레이터의 합의 레이어 성과를 기반으로 보상 분배 머클 트리를 계산하고, 오라클 멤버 간 합의에 도달하면 해당 트리의 루트가 FeeDistributor.sol에 제출된다.

3. 오퍼레이터가 머클 증명을 제출하여 자신의 보상을 청구한다.

이 과정에서 CSM v3은 세 가지 실질적인 개선을 도입했다.

첫째, pullFeeRewards라는 메서드가 추가되어, 오퍼레이터가 보상을 외부 주소로 인출하지 않고 보증 담보금에 직접 적립할 수 있게 되었다. 슬래싱이나 페널티로 보증 담보금이 줄어든 경우, 보상으로 이를 자동 보충하는 데 유용하다.

둘째, 보상 청구 시 커스텀 주소를 지정할 수 있게 되어, 오퍼레이터의 보상 관리가 유연해졌다.

셋째, 내장형 수수료 분할 기능(FeeSplits)이 도입되었다. 오볼(Obol)이나 SSV 같은 분산 인프라 제공자에게 스테이킹 보상의 일정 비율을 자동으로 분배할 수 있으며, 최대 10개의 수수료 분할 수신자를 설정할 수 있다. 프로토콜 길드 등 공익 펀딩 서비스에 대한 자발적 기부에도 활용할 수 있어, 인프라 제공자 수수료 지급, 공익 기부, 보증 담보금 보충 등을 하나의 트랜잭션 흐름 안에서 처리할 수 있게 된다.

3.4 기타 기술적 개선

LIP-33에는 위에서 다룬 변화들 외에도 다음의 기술적 개선을 포함한다.

• 일반 지연 페널티 메커니즘: CSM v2까지는 실행 레이어 보상 탈취에 한정되어 있던 오프체인 페널티 체계를, CSM v3에서는 보다 범용적인 프레임워크로 확장했다. 오프체인에서 위반 사실이 보고되면 보증 담보금이 잠기고, 이의 제기 기간을 거친 후 이지 트랙 투표를 통해 확정되는 절차를 따른다. 또한 보증 담보금이 부족한 경우에는 부채 기록(bond debt record)이 새로 생성되어 향후 보증 담보금 보충 시 자동으로 차감되는 구조가 추가되었다.

• 파라미터 레지스트리(Parameters Registry): CSM v2에서 도입된 오퍼레이터 유형별 파라미터 관리에 세분화된 역할 기반 접근 제어(RBAC)가 추가되어, 파라미터 그룹별로 관리 권한을 분리할 수 있게 되었다. 밸리데이터 자발적 퇴장(Voluntary Ejection) 메커니즘도 최적화되어, EIP-7002를 통한 퇴장 프로세스가 간소화되었다.

4. CSM이 라이도의 운영 체제가 되다

LIP-33의 제안 범위에는 CSM v3뿐만 아니라 CM v2가 포함되어 있다. 그리고 CM v2는 CSM v3의 코드베이스를 기반으로 만들어진다.

이는 필자가 이번 제안에서 가장 주목하는 지점이다.

큐레이티드 모듈은 라이도 전체 스테이크의 약 90%를 담당하는 핵심 모듈인 반면, CSM은 전체의 약 7.5%를 담당하는 상대적으로 작은 모듈이다. 그런데 이 작은 모듈의 코드가 큰 모듈의 재설계를 위한 기반이 되었다는 점은, 일반적인 기대와는 다른 방향으로 보인다.

이런 역전이 가능했던 이유는 CSM이 라이도에서 처음으로 보증 담보금 메커니즘, 자동화된 성과 관리, 오퍼레이터 유형 분류 등 현대적인 스테이킹 모듈의 핵심 개념들을 실전에서 검증한 모듈이었기 때문이다. 큐레이티드 모듈은 라이도 v2 출시 이후 거의 변하지 않은 채로 운영되어 왔다. 보증 담보금 없이 평판에만 의존하는 구조, 32 ETH 고정 밸리데이터를 전제로 한 회계 모델, 모든 오퍼레이터에게 동일한 수수료를 적용하는 경직된 경제 구조 등이 그대로 유지되고 있었다. CSM이 1.5년간 퍼미션리스 환경에서 보증 담보금, 성과 기반 페널티, 유형별 차등 파라미터 등을 실험하고 검증하는 동안, 큐레이티드 모듈은 제자리에 머물러 있었던 셈이다.

결과적으로 라이도가 큐레이티드 모듈을 재설계해야 하는 시점이 왔을 때, 바닥부터 새로 만드는 것보다 CSM에서 이미 검증된 아키텍처를 가져와 확장하는 것이 합리적인 선택이 되었다. 기술적으로 보면, CM v2의 핵심 컨트랙트인 CuratedModule.sol은 CSM과의 공통 로직을 담은 BaseModule.sol을 상속받아, 그 위에 큐레이티드 모듈 고유의 기능을 덧붙이는 구조다. 대부분의 보조 컨트랙트는 CSM v3과 동일한 코드를 각각 독립 배포하는 형태로 공유된다.

물론 CM v2에는 CSM에 없는 고유한 기능들이 추가된다. 하나의 오퍼레이터가 여러 유형의 서브 오퍼레이터를 운영할 수 있게 하는 메타 레지스트리(Meta Registry), 선입선출 큐 대신 가중치 기반으로 스테이크를 배분하는 그리디(greedy) 할당 알고리즘, 그리고 향후 밸리데이터 마켓플레이스를 위한 기반 등이 그것이다. 하지만 이 모든 것의 토대는 CSM이 쌓아온 코드베이스다.

필자는 이 구도에서 소프트웨어 공학의 오래된 교훈 하나를 떠올린다. 좋은 아키텍처는 작은 곳에서 먼저 검증된다는 것이다. 리눅스 커널이 처음 리눅스 토발즈의 개인 프로젝트에서 출발하여 전 세계 서버 인프라의 표준이 된 것처럼, CSM도 퍼미션리스라는 비교적 작은 실험장에서 출발하여 라이도 전체 아키텍처의 표준을 정의하는 위치에 올라섰다. 퍼미션리스 환경은 신뢰할 수 없는 참여자를 전제로 설계해야 하기 때문에, 자연스럽게 보증 담보금, 자동화된 페널티, 증명 기반 검증 등 더 견고한 메커니즘을 요구한다. 이런 환경에서 단련된 코드가 결국 퍼미션드 모듈의 재설계에도 적합한 기반이 된다는 점은 직관적이면서도 시사하는 바가 크다.

5. 보안 고려사항

LIP-33은 0x02 밸리데이터의 도입이 새로운 보안 고려사항을 수반함 또한 언급하고 있으며 가능한 공격 시나리오와 방어 기법에 대해 다루고 있다. 본 글에서는 제안에서 제시된 각 시나리오에 대해 간단하게 다루어보겠다.

5.1 탑업과 출금의 타이밍 불일치 악용 시나리오

탑업이 밸리데이터에 전달되었지만 아직 합의 레이어에 반영되지 않은 상태에서 밸리데이터가 퇴장하고, 이후 탑업 금액이 합의 레이어에 적용되어 별도로 출금되는 경우, 해당 출금이 정상적인 밸리데이터 출금으로 오인되어 노드 오퍼레이터의 보증 담보금이 부당하게 차감될 수 있다. 반대의 경우, 즉 실제로는 페널티를 받아야 하는데, 탑업 금액이 이를 상쇄하는 경우에는 프로토콜이 손실을 보게 된다.

라이도는 이 위험을 최소화하기 위해 최소 출금 비율(MIN_WITHDRAWAL_RATIO)이라는 파라미터를 설정한다. CSM v3의 0x02 인스턴스에서는 이 값이 1%로, 약 6개월간의 오프라인에 해당하는 수준이다. CSM에는 성과 부진 스트라이크 시스템이 있어 약 3개월의 저조한 성과 후에는 자동 퇴출이 이루어지므로, 밸리데이터가 6개월 이상 오프라인 상태로 방치될 가능성은 매우 낮다. 또한 노드 오퍼레이터들에게 자체적으로 증명 봇(prover bot)을 운영하여 밸리데이터 출금을 적시에 보고할 것을 권고하고 있다.

5.2 탑업 큐의 조기 디큐잉 시나리오

CSM v3에서 0x02 밸리데이터의 탑업은 입금 봇(Depositor Bot)이 합의 레이어 증명을 기반으로 각 밸리데이터의 탑업 한도를 계산하고, 이를 StakingRouter를 통해 모듈에 전달하는 방식으로 이루어진다.

문제는 입금 봇의 버그로 인해 특정 밸리데이터에 대한 미결 입금(pending deposits)이 실제보다 과대 보고될 수 있다는 점이다. 이 경우 CSM은 해당 밸리데이터가 이미 2,048 ETH까지 완전히 입금된 것으로 판단하여 탑업 큐에서 조기에 제거하게 되고, 결과적으로 밸리데이터가 의도한 금액에 도달하지 못한 채 추가 입금 대상에서 빠지게 된다.

LIP-33은 이 상황의 발생 가능성이 낮다고 판단하면서도, 대응 메커니즘을 마련해두었다. CSMC(CSM Committee)에 부여된 권한을 통해, 탑업 큐의 헤드 포인터를 완전히 입금되지 않은 밸리데이터 키 위치로 롤백할 수 있다. 롤백 후에는 수정된 입금 봇이 정확한 정보를 전달하고, 이미 완전히 입금된 키들은 합의 레이어 증명에 의해 탑업 한도가 0으로 산출되므로 자동으로 건너뛰게 된다.

5.3 GateSeal: 최후의 방어선

CSM v3은 제로데이 취약점에 대한 최후 방어선으로 기존에 구현된 GateSeal 메커니즘을 그대로 유지하고 있다. GateSeal은 라이도 프로토콜 전반에서 사용되는 일회성 긴급 일시 정지 계약으로, 지정된 보안 위원회가 심각한 취약점이 발견되었을 때 핵심 컨트랙트들을 즉시 일시 정지시킬 수 있다. GateSeal은 일회성으로, GateSeal이 발동되면 해당 계약은 소진되어 재사용할 수 없으며, 재개는 별도의 권한을 통해서만 가능하다. 이는 긴급 대응 수단이 남용되지 않도록 하면서도, 실제 위기 상황에서는 거버넌스 투표 없이 즉각 대응할 수 있는 균형점을 제공한다.

6. 맺으며

필자가 생각하기에 이번 CSM v3 업그레이드 제안이 갖는 의미는 아래와 같다.

첫째는 이더리움 생태계 수준의 의미다. 펙트라의 0x02 밸리데이터가 네트워크 효율을 높이려면, 실제로 스테이킹 프로토콜들이 이를 채택해야 한다. 라이도는 이더리움 스테이킹의 약 23%를 차지하는 최대 프로토콜이고, CSM v3과 CM v2를 통해 퍼미션리스 모듈과 큐레이티드 모듈 양쪽에서 0x02를 전면 도입한다. 이는 이더리움 전체의 0x02 채택률을 한 단계 끌어올리는 계기가 될 것이다.

둘째는 라이도 프로토콜 내부의 아키텍처 진화다. CSM은 퍼미션리스 실험에서 출발했지만, 1.5년의 운영을 통해 검증된 그 코드베이스가 이제 라이도 전체 아키텍처의 기반이 되고 있다. 이는 단순한 코드 재활용을 넘어서, 라이도의 모듈 설계 철학이 전환되고 있음을 시사한다. 퍼미션리스 환경에서 먼저 검증하고, 그 검증된 메커니즘을 퍼미션드 환경에도 적용한다는 흐름이 형성되고 있는 것이다.

필자가 주목하는 마지막 포인트는, CSM의 이러한 진화가 탈중앙화의 비용에 대한 흥미로운 관점을 제시한다는 것이다. 퍼미션리스 참여를 위해서는 보증 담보금, 자동화된 페널티, 증명 기반 검증 등 더 정교한 메커니즘이 필요하고, 이는 설계와 운영의 복잡성을 높인다. 그러나 그렇게 높아진 복잡성이 결국에는 프로토콜 전체의 견고함으로 환원된다는 CSM의 사례는, 탈중앙화가 단순히 비용이 아니라 투자이기도 하다는 점을 보여준다.