관련 프로젝트
Key Takeaways
라이도의 기존 비상 정지 메커니즘인 게이트실은 일회용 설계로 인해 매년 재배포가 필요했으며, 보호 대상 컨트랙트가 10개 이상으로 늘어나면서 운영 부담이 복리로 증가해왔다.
써킷브레이커는 영구 주소, 컨트랙트별 독립적 권한 관리, 하트비트 기반 위원회 활성 증명이라는 세 가지 설계로 게이트실의 보안 속성을 유지하면서 재배포 부담을 제거한다.
써킷브레이커는 탈중앙 프로토콜이 비상 정지라는 중앙화된 수단의 운영 비용을 어떻게 구조적으로 낮출 수 있는지를 보여주는 거버넌스 설계 사례다.
한 번 배포되면 누구도 임의로 멈출 수 없다는 점은 스마트 컨트랙트의 가장 큰 강점이자 약점이다. 평상시에는 라이브니스(Liveness)라는 가치를 제공하지만, 동시에 치명적인 버그나 해킹이 발생했을 때는 피해가 실시간으로 확산되는데도 즉각 대응할 수 없다는 문제를 갖는다. 이에 대응하기 위해 대부분의 크립토 프로젝트들은 이상 상황을 감지했을 때 핵심 기능을 일시 정지시키는 메커니즘을 구현해왔다.
그런데 이러한 메커니즘에서 누가 정지 버튼을 누를 수 있느냐는 프로토콜의 탈중앙화 정도에 따라 매우 까다로운 문제가 될 수 있다. 거버넌스 투표로 결정하자니 며칠이 걸리고, 특정 개인에게 맡기자니 중앙화 리스크가 생긴다. 라이도는 이 딜레마를 멀티시그 위원회가 합의하면 발동할 수 있는 일회성 비상 정지 컨트랙트, 게이트실(GateSeal)로 타협해왔다. 그리고 4월 9일 오늘, 라이도에서 기존의 게이트실을 써킷브레이커(CircuitBreaker)라는 영구적 메커니즘으로 교체하자는 제안이 올라왔다.
Source: Lido
본 글에서는 써킷브레이커의 등장 배경과 구현체 상세, 그리고 써킷브레이커가 남기는 시사점에 대해 다뤄보겠다.
1. 게이트실이 남긴 숙제
게이트실의 작동 원리는 전기 퓨즈에 비유하면 이해가 쉽다. 가정에서 과전류가 흐르면 퓨즈 내부의 도선이 끊어져 회로를 보호하지만, 한 번 끊어진 퓨즈는 새것으로 교체해야 한다. 게이트실도 동일한 패턴을 갖는다. 비상 상황에서 발동하면 즉시 만료되고, 발동하지 않더라도 최대 1년의 유효기간이 지나면 자동 소멸한다. 이때 위원회는 등록된 컨트랙트 중 일부만 골라서 정지시킬 수 있지만, 어떤 선택을 하든 게이트실 자체는 즉시 만료된다. 예를 들어 8개의 컨트랙트가 등록된 게이트실에서 2개만 정지시켰더라도, 나머지 6개를 나중에 정지시키고 싶으면 이미 만료된 게이트실로는 불가능하다.
발동에 의한 소멸이든, 만료에 의한 소멸이든 새 인스턴스를 배포하고, 보안 감사를 받고, 스냅샷 투표를 거쳐, 온체인 투표로 기존 인스턴스의 정지 권한을 회수한 뒤 새 인스턴스에 부여하는 절차를 반복해야 한다. 이는 DAO가 더 나은 영구적 솔루션을 만들도록 압박하기 위한, 의도적으로 불편하게 만들어진 설계였다.
라이도 V2 시점에서 게이트실이 보호하는 컨트랙트는 아래의 두 개뿐이었고, 갱신 주기도 연 1회였기에 큰 운영 부담을 발생시키지 않았다.
WithdrawalQueue: 사용자의 stETH → ETH 출금 대기열 담당
ValidatorsExitBus: 노드 오퍼레이터의 밸리데이터 퇴출 버스
그러나 3년이 지난 현재, 라이도에는 다음과 같은 업그레이드들이 도입되면서 보호 대상이 크게 늘어났다.
라이도 V3: 커스텀 스테이킹을 위한 stVault 도입
트리거 가능한 출금(Triggerable Withdrawals): DAO가 직접 밸리데이터 퇴출을 트리거하는 프레임워크
이중 거버넌스(Dual Governance): stETH 홀더에게 DAO 결정에 대한 거부권을 부여하는 메커니즘
커뮤니티 스테이킹 모듈(Community Staking Module): 개인 스테이커의 참여를 위한 모듈
이에 따라 현재 비상 정지가 필요한 컨트랙트가 10개 이상으로 늘어났으며, 이를 4개의 별도 게이트실로 관리한다는 것은 매년 각각을 배포하고 검증하는 과정을 반복해야 하는 문제를 낳는다.
더 근본적인 문제도 있다. 게이트실의 유효기간 만료 시점과 새 게이트실의 온체인 투표 완료 시점 사이에는 비상 정지 수단이 없는 공백이 발생할 수 있다. 2024년 4월의 갱신 사례를 보면, 기존 게이트실의 만료일(5월 1일)과 투표 완료일(4월 26일) 사이 여유가 불과 며칠이었다. 프로토콜 규모가 커질수록, 이러한 타이트한 일정은 점점 더 위험 요소로 동작하게 된다.
2. 써킷브레이커: 퓨즈에서 차단기로
써킷브레이커는 이름 그대로, 가정의 두꺼비집에 있는 차단기를 연상하면 된다. 퓨즈와 달리 차단기는 과전류 발생 시 회로를 차단하지만, 문제가 해결되면 레버를 올려 재사용할 수 있다. 써킷브레이커 컨트랙트도 이 패턴을 따른다. 한 번 배포하면 영구적으로 존재하며, 발동 후에도 DAO가 권한을 재부여하면 다시 사용할 수 있다.
써킷브레이커의 핵심 설계 요소는 세 가지가 존재한다.
첫번째는 영구 주소이다. 써킷브레이커는 단 하나의 컨트랙트로, 주소가 변하지 않는다. DAO가 각 정지 가능한 컨트랙트에 "이 주소가 너를 정지시킬 수 있다"는 권한을 한 번만 부여하면 된다. 게이트실에서 매년 반복되던, 이전 인스턴스 권한 회수 이후 신규 인스턴스 권한 부여라는 갱신 절차가 완전히 사라진다.
Source: Lido
두번째는 단일 사용 정지 메커니즘이다. 비상 상황에서 위원회가 특정 컨트랙트의 정지를 트리거하면, 써킷브레이커는 대상을 정지시킨 뒤 해당 컨트랙트에 대한 위원회의 권한을 즉시 소거한다. 위원회가 같은 컨트랙트를 반복 정지시키려면 DAO의 재승인이 필요하다. 이는 게이트실의 핵심 안전장치였던 일회성이라는 속성을 그대로 계승한 것이다. 다만 게이트실과의 결정적 차이는, 하나의 컨트랙트를 정지시켜도 나머지 컨트랙트에 대한 권한은 그대로 유지된다는 점이다. 게이트실에서는 부분 정지를 선택하더라도 게이트실 자체가 만료되어 나머지에 대한 대응 능력을 잃었지만, 써킷브레이커에서는 컨트랙트별로 권한이 독립적으로 관리되므로 비상 대응 능력이 보존된다.
Source: Lido
세번째는 활성 상태 증명(Heartbeat)으로, 써킷브레이커에서 가장 주목할 설계다. 위원회는 주기적으로 하트비트(heartbeat) 트랜잭션을 보내 비상시 대응 준비가 되어 있음을 온체인으로 증명해야 한다. 하트비트가 만료된 위원회는 정지도, 하트비트 갱신도 할 수 없으며, DAO가 새로운 위원회로 교체해야 한다. 게이트실에서는 컨트랙트 자체의 만료가 DAO의 주의를 환기시켰다면, 써킷브레이커에서는 위원회의 활성 상태 만료가 같은 역할을 한다. 단, 컨트랙트를 재배포하는 무거운 절차 대신 단순한 트랜잭션 하나로 갱신이 완료된다.
Source: Lido
실제로 2024년 6월에 진행된 게이트실 훈련에서는 위원회 전원이 소집되어 25분 만에 모의 발동을 완료한 바 있다. 하트비트는 2024년 훈련에서 시도된 위원회 활성 상태 점검이라는 아이디어를, 온체인에서 주기적으로 강제하는 메커니즘으로 발전시킨 것에 가깝다.
3. 써킷브레이커의 매개변수 설계
써킷브레이커에 제안된 매개변수 중 가장 중요한 것은 정지의 지속 시간이다. 게이트실은 처음에 6일, 이후 11일의 정지 지속 시간을 가지지만, 써킷브레이커에서는 초기값으로 21일이 제안되었다. 이 숫자는 다음과 같은 산술에서 나온다.
비상 정지가 발동된 후 DAO는 후속 조치를 위한 투표를 진행해야 한다. 아라곤(Aragon) 투표에 5일이 소요되며, 정족수 미달 시 재투표에 5일이 추가된다. 그리고 이중 거버넌스 하에서는 stETH 홀더들의 거부권 행사 기간, 즉 최소 4일의 타임락(timelock)이 추가된다. 여기까지 합산하면 14일로, 상황 분석, 개발팀 조율, 투표 준비를 위한 7일의 버퍼를 더하면 21일이 된다.
이 계산에는 이중 거버넌스가 큰 영향을 미친다. 기존에는 비상 정지 후 DAO가 단순 투표 한 번으로 후속 조치를 취할 수 있었지만, 이중 거버넌스 도입 이후에는 stETH 홀더들이 해당 결정에 이의를 제기할 수 있는 기간이 추가되었기 때문이다. 즉 거버넌스 프로세스 전체가 길어졌으므로, 정지 지속 시간도 이에 맞춰 늘어나야 하는 것이다. 만약 정지가 거버넌스 사이클보다 먼저 만료되면, 취약점이 아직 수정되지 않은 상태에서 컨트랙트가 재개되는 최악의 시나리오가 발생한다.
Source: Lido
불변 경계값도 주목할 만하다. 라이도는 정지 지속 시간의 하한이 5일, 상한이 60일로 컨트랙트에 하드코딩한다. DAO가 관리자 권한으로 21일이라는 초기값을 조정할 수는 있지만, 이 경계를 벗어나는 것은 불가능하다. 이는 DAO 자체가 거버넌스 공격을 당하더라도, 정지 시간을 극단적으로 축소하거나 확장하여 프로토콜을 악용하는 것을 원천적으로 막는 안전장치다.
반면, 써킷브레이커가 단일 컨트랙트로 구현되어 있다는 점은 취약점으로 인해 전체 비상 정지 능력이 무력화될 가능성을 제기할 수 있다. 이에 대해 라이도는 외부 의존성 없이 자체 구현된 단일 라이브러리만 사용하는 구조로 공격 표면을 극소화했으며, 이중 거버넌스의 재봉인 위원회(Reseal Committee)가 써킷브레이커의 초기 정지를 필요시 연장할 수 있도록 하는 방식의 방어 메커니즘을 구현해두었다.
4. 시사점
써킷브레이커의 핵심 가치는 비상 정지라는 기능 자체가 아니라, 그 기능의 유지 비용을 구조적으로 낮춘다는 데 있다. 써킷 브레이커는 기존에 게이트실이 해결했던 문제인 거버넌스보다 빠른 비상 대응은 그대로 유지하면서, 게이트실이 만들어낸 문제인 주기적 재배포라는 운영 부채를 제거한다.
한편, 하트비트 모델이 도입하는 미묘한 트레이드오프가 존재한다. 게이트실의 강제 만료는, 만료일이 다가오면 DAO 전체가 "비상 정지 수단이 곧 사라진다"는 사실을 인지하고 공개적으로 논의하며 행동해야 하는 자연스러운 조율 지점의 역할을 했다. 실제로 갱신 제안이 올라오면 포럼에서 논의가 이루어지고, 커뮤니티가 현재 보안 상태를 점검하는 계기가 되었다. 써킷브레이커에서는 하트비트 만료가 위원회 내부의 문제에 가까워질 수 있어, DAO 전체의 주의 환기 효과가 약화될 가능성이 있다. 모니터링과 알림 시스템으로 보완할 수 있는 부분이지만, 구조적 강제와 운영적 모니터링 사이의 신뢰도 차이는 존재한다.
Source: Lido
비상 정지 메커니즘의 장기적 방향성에 대해서는, 2024년 4월 게이트실 갱신 논의에서 라이도 개발자 skozin이 남긴 코멘트가 참고할 만하다. 그는 프로토콜의 불변 조건(invariant)을 정형화하여 누구든 "이 상태 전이가 불변 조건을 위반한다"는 증명을 제출하면 자동으로 정지가 발동되는 허가 없는(permissionless) 서킷 브레이커로의 전환을 제안한 바 있다. 궁극적으로는 프로토콜 코드의 형식 검증(formal verification)과 핵심 코드 고정(ossification)을 통해 서킷 브레이커 자체를 제거하는 것이 이상적인 종착점이라는 것이다.
이는 써킷브레이커의 위치를 가늠하는 데 유용한 프레임을 제공한다. 써킷브레이커는 위원회라는 신뢰 가정을 당장 제거하지는 못하지만, 매년 갱신에 소모되던 거버넌스 자원을 줄임으로써 이러한 다음 단계를 모색할 여유를 확보해주는 역할을 할 수 있다.
써킷브레이커 제안이 던지는 근본적인 질문은 "탈중앙 프로토콜이 비상 정지라는 중앙화된 수단을 얼마나 오래 정당화할 수 있는가"이다. 써킷브레이커가 성공적으로 안착한다면, 라이도뿐 아니라 유사한 딜레마를 안고 있는 다른 디파이 프로토콜들에게도 신뢰 가정을 단계적으로 줄여가는 거버넌스 설계의 참고 사례가 될 수 있을 것으로 생각된다.
