코스모스 인터체인 보안에서 제공자와 소비자 체인이 어떻게 연결되는지, 누가 검증에 참여하는지, 보상은 어떻게 전달되는지, 소비자 체인의 장애가 제공자 지분에 왜 영향을 줄 수 있는지 살펴봅니다.
이 글에서 다루는 내용제공자 체인은 검증 보안을 제공하지만 위임자의 지분을 옮기지는 않습니다
짧은 요약
코스모스 인터체인 보안은 제공자 체인의 검증자 일부 또는 전체를 소비자 체인에 참여시킵니다. 스테이킹된 자산은 제공자 체인에 남으며, 어떤 보안과 위험이 공유되는지는 소비자 체인의 검증자 구성, IBC 메시지 경로, 보상 규칙, 위반 처리 방식에 달려 있습니다.
제공자 체인은 검증 보안을 제공하지만 위임자의 지분을 옮기지는 않습니다
인터체인 보안(Interchain Security, ICS)은 인터블록체인 통신(IBC) 프로토콜을 통해 서로 다른 코스모스 체인을 연결합니다. 제공자 체인은 검증자 집합을 관리하고, 소비자 체인은 참여 자격을 갖춘 제공자 검증자를 이용해 자체 블록을 제안하고 확인합니다. 두 체인은 별도의 상태 머신과 원장을 운영하며, 수수료·토큰·거버넌스·애플리케이션 규칙도 서로 다를 수 있습니다.
“보안 공유”는 네트워크 간 관계를 뜻합니다. 위임자의 코인이 소비자 체인으로 이동한다는 뜻은 아닙니다. 위임자의 ATOM은 제공자 체인의 스테이킹 규칙에 따라 계속 묶여 있습니다. 소비자 체인은 제공자 지분의 뒷받침을 받는 검증자 참여를 이용하고, 특정 검증자 위반을 제공자 체인에 보고할 수 있습니다. 따라서 지갑 잔액, 소비자 체인 토큰, 제공자 체인에 예치된 지분은 서로 다른 항목입니다.
ICS는 단순한 IBC 토큰 브리지와도 다릅니다. IBC는 체인 간 인증된 통신을 제공하지만, ICS는 검증자 집합 변경과 위반 증거를 전달하는 전용 교차 체인 검증 애플리케이션을 사용합니다. 토큰 전송은 검증자 집합을 공유하지 않고 ICS-20만 사용할 수 있습니다. 반대로 검증자를 공유해도 소비자 체인의 모든 애플리케이션과 토큰이 안전해지는 것은 아닙니다.
제공자 체인의 검증자 집합 전체가 모든 소비자 체인에 복제되는 것은 아닙니다. 부분 집합 보안(Partial Set Security, PSS)을 사용하면 소비자 체인이 일부 검증자만 선택할 수 있습니다. Top N 방식은 제공자 투표권에서 정한 비율에 따라 검증자를 고릅니다. opt-in 방식은 자격을 갖춘 검증자가 특정 소비자 체인을 직접 선택해 참여하는 방식입니다. 어느 규칙을 쓰는지는 소비자 체인의 현재 설정으로 확인해야 합니다.
권력 구성(power shaping) 설정은 소비자 검증자 집합을 더 줄이거나 재조정할 수 있습니다. 체인 설정에 따라 검증자 수 상한, 소비자 투표권에서 한 검증자가 차지할 수 있는 비율 상한, 허용 목록 또는 차단 목록을 둘 수 있습니다. 이런 설정은 소비자 체인의 검증자 집합에 적용되며, 제공자 체인의 위임 지분 분포를 바꾸지는 않습니다.
권력 상한의 효과를 보기 위해 공식 문서의 가상 구성을 살펴볼 수 있습니다. 제공자 투표권이 A 100, B·C·D 각 1이고 네 검증자만 소비자에 opt-in했다고 합시다. 소비자에서 검증자별 상한을 30%로 두면, 제공자에서 A가 차지하던 약 97%의 투표권은 소비자에서 약 29%가 되고 나머지 세 검증자는 약 25%, 23%, 23%로 재조정될 수 있습니다. 제공자 체인의 원래 투표권은 이 과정에서 바뀌지 않습니다.
이 예시는 cap이 단순한 차단선이 아니라 소비자 내부의 voting power를 다시 나누는 설정임을 보여줍니다. 검증자가 너무 적으면 정한 비율을 수학적으로 맞출 수 없어 설정이 best-effort로 동작할 수 있습니다. 또한 보상 분배가 소비자에서 조정된 투표권을 기준으로 계산될 수 있으므로, 실제 validator set과 상한을 확인해야 보안 집중도와 보상 비중을 함께 이해할 수 있습니다.
허용·차단 목록은 Top N 비율의 의미도 바꿀 수 있습니다. 공식 문서의 예에서는 제공자 투표권 10%를 가진 상위 검증자를 Top 50% 소비자에서 denylist하면, 소비자 체인은 제공자 전체 투표권에서 최소 40% 수준의 보안만 확보할 수 있습니다. 따라서 Top N이라는 이름만 보지 말고 실제 참여 검증자와 각각의 provider power를 대조해야 합니다.
일부 소비자 체인의 출범에는 제공자 거버넌스 승인이 필요하지만, 현재 문서는 opt-in 체인을 허가 없이 시작하는 경로도 설명합니다. “코스모스 체인”이라는 말만으로 출범 경로를 추정하면 안 됩니다. 체인 ID와 출시 상태, Top N 또는 opt-in 규칙, 권력 구성 매개변수, 제공자 체인의 현재 거버넌스 절차를 확인하세요. 공식 문서는 버전이 있으며 기능도 바뀔 수 있습니다.
소비자 체인에 참여하는 제공자 검증자는 보통 별도의 소비자 체인 노드를 운영하고 해당 체인의 소프트웨어와 출시 절차를 따라야 합니다. 제공자 체인의 서명 키를 그대로 쓰는 대신 소비자 전용 합의 키를 지정할 수도 있습니다. 키를 분리하면 소비자 노드가 침해되었을 때 제공자 서명 키까지 노출될 가능성을 줄일 수 있지만, 운영·소프트웨어·서명 위험 자체가 사라지는 것은 아닙니다.
체인의 참여 규칙은 누가 소비자 노드를 운영해야 하는지에도 영향을 줍니다. Top N 체인은 제공자 투표권과 임계값에 따라 참여 의무가 생길 수 있습니다. opt-in 체인은 일반적으로 검증자가 자발적으로 참여합니다. 투표권 상한 같은 설정은 최종 소비자 집합을 다시 바꿀 수 있습니다. 검증자는 소비자 체인별 자격, 키 등록, 실행 파일 해시, 가동 시각, 모니터링 조건을 확인해야 합니다.
위임자가 직접 소비자 노드를 시작하는 것은 보통 아닙니다. 제공자 체인에서 위임한 지분은 추가 운영을 맡은 검증자를 뒷받침하며, 소비자 체인의 페널티가 제공자 지분에 반영될 수 있습니다. 따라서 제공자 검증자의 신원과 가동 시간만 살펴서는 충분하지 않습니다. 소비자별 참여 방식과 위반 처리 규칙도 확인해야 합니다.
제공자의 일부 검증자가 독립된 소비자 체인에 참여하고 스테이크는 제공자에 남으며, 보상과 위반 신호는 별도 경로를 따르는 글자 없는 개념 그림입니다.
검증자 집합 변경은 전용 IBC 채널을 통해 전달됩니다
제공자 지분이나 참여 자격이 바뀌면 소비자 검증자 집합도 갱신되어야 할 수 있습니다. ICS는 교차 체인 검증(CCV) 채널을 통해 검증자 집합 변경 내용을 보냅니다. 릴레이어는 메시지를 체인 사이로 전달하고, 각 체인은 프로토콜이 정한 상태를 검증한 뒤 자체 변경을 적용합니다. 릴레이어가 소비자 체인의 검증자가 되거나 유효한 서명을 직접 정하는 것은 아닙니다.
이 조정 과정은 단독 체인보다 참여 및 이탈 시점을 복잡하게 만들 수 있습니다. 과거 CCV 설계 문서는 체인 간 언본딩 보호를 위해 검증자 집합 변경 패킷과 만기 알림을 다룹니다. 이후 구현에서는 언본딩 조정도 바뀌었습니다. 정확한 동작은 프로토콜 버전과 매개변수에 달려 있으므로, 일반적인 ICS 설명만으로 제공자 언본딩에 시간이 얼마나 더 걸리는지 단정할 수 없습니다.
위임을 변경하거나 인출하기 전에 제공자와 소비자 체인의 최신 문서를 읽고, 대기 중인 언본딩 기록을 살펴보세요. 일반 스테이킹 대기 기간과 ICS 전용 조정 조건을 구분해야 합니다. 릴레이어 지연이나 오래된 클라이언트는 기본 규칙을 바꾸지는 않지만 패킷 진행을 늦출 수 있습니다.
소비자 체인은 검증자 위반을 제공자에게 보고할 수 있습니다. 현재 인터체인 보안 문서는 가동 중단과 이중 서명 같은 합의 위반을 구분합니다. 소비자 체인의 위반 매개변수와 제공자가 수락한 증거에 따라 검증자가 감옥(jail) 처분, 지분 슬래싱 또는 두 조치를 모두 받을 수 있습니다. 처분은 제공자 체인의 규칙으로 적용되므로, 한 소비자 체인의 사건이 검증자의 제공자 지분과 다른 소비자 체인에서의 자격에도 영향을 줄 수 있습니다.
모든 체인에 공통으로 적용되는 단일 페널티 비율은 없습니다. 소비자별 설정이 슬래싱 비율과 감옥 기간을 정하고, 프로토콜 버전에 따라 제출할 수 있는 증거와 처리 방식도 달라집니다. 예를 들어 일정한 가동 중단 기준을 넘으면 제공자 쪽에서 감옥 처분이 시작될 수 있고, 유효한 이중 서명 증거는 더 심한 조치로 이어질 수 있습니다. 이는 규칙상 가능한 처리 경로이며 특정 검증자나 체인에 대한 예측은 아닙니다.
제공자 스테이킹 규칙에 따라 검증자의 자기 위임분과 위임자의 지분 모두 슬래싱의 경제적 영향을 받을 수 있습니다. 감옥 처분은 검증자를 제공자 활성 집합에서 제외하고, 결과적으로 소비자 검증자 집합에서도 제외할 수 있습니다. 소비자 토큰 보상에만 영향이 있다고 가정하지 말고 실제 체인 매개변수와 사건 처리 절차를 확인하세요.
현재 공식 문서 안에서도 가동 중단(downtime) 처분 설명이 일치하지 않습니다. 검증자 안내는 허브의 가동 중단 위반에 제공자 측 감옥 처분만 있고 슬래싱은 없다고 설명하지만, 소비자 주도 슬래싱 페이지는 소비자별 매개변수에 따라 감옥 처분과 슬래싱을 함께 설명합니다. 이는 프로토콜 버전과 설정을 함께 확인해야 한다는 뜻입니다. 실제로 위임하거나 검증할 체인의 제공자 구현, 활성 매개변수, 증거 전달 절차를 확인하세요.
소비자 체인은 블록 보상이나 수수료 중 설정된 몫을 보안 제공 대가로 제공자 체인에 보낼 수 있습니다. 보상은 IBC 토큰 전송 채널을 통해 주기적으로 이동합니다. 제공자 체인에서는 허용된 보상 단위만 분배되며, 분배 대상은 소비자 체인의 규칙에 따라 달라집니다. 현재 문서는 검증자가 opt-in 상태여야 하고, 정해진 연속 에포크 동안 검증해야 보상 대상이 될 수 있다고 설명합니다. 이후 위임자도 제공자 분배 규칙에 따라 나눠 받을 수 있습니다.
간단한 가정으로, 어떤 기간에 소비자 체인에서 수수료와 인플레이션 보상 12,000단위가 발생했고 거버넌스가 제공자 몫을 25%로 정했다고 해보겠습니다. 산술상 제공자 보상 풀을 향해 3,000단위가 전송됩니다. 이 계산만으로 달러 가치, 검증자별 최종 분배액, 지급 시점, 미래 수익률을 알 수는 없습니다. 투표권 상한이 적용되면 분배 비율은 제공자 원래 투표권이 아니라 조정된 소비자 검증자 집합에 근거할 수도 있습니다.
보상 토큰은 가격 변동성이 있거나 유동성이 낮고, 출금 비용이 클 수 있습니다. 지갑에 표시되는 연환산 수익률에는 소비자 체인 활동, 보상 비율, 참여 검증자, 수수료, 제공자 분배, 단위 등록, opt-in 유지 기간 등 바뀔 수 있는 가정이 포함됩니다. 소비자 보상을 보장된 APY나 슬래싱 위험을 상쇄하는 수익으로 보면 안 됩니다.
제공자 검증자를 사용하면 작은 새 검증자 집합만으로 운영하는 경우보다 소비자 체인을 공격하기 어려워질 수 있습니다. 그렇다고 소비자 체인이 제공자와 같아지는 것은 아닙니다. 소비자 체인은 자체 애플리케이션 소프트웨어, 거버넌스, 경제 설계, IBC 클라이언트와 채널, 운영 의존성, 스마트 계약과 모듈을 가질 수 있습니다.
검증자 집합은 보안 모델의 한 부분일 뿐입니다. 소비자 체인의 검증자 일부 집합은 제공자의 전체 집합과 집중도나 가동 특성이 다를 수 있습니다. 클라이언트나 릴레이어 문제로 조정이 늦어질 수 있고, 제공자 검증자가 올바르게 행동해도 소비자 소프트웨어 결함이 소비자 체인에 영향을 줄 수 있습니다. 거버넌스는 매개변수를 바꿀 수 있으며, 토큰 가치는 합의 절차와 별개로 하락할 수 있습니다.
“코스모스 허브가 보안을 제공한다”는 설명은 조사할 출발점이지 종합적인 위험 등급은 아닙니다. 어떤 제공자가 참여하는지, 검증자 집합이 어떻게 구성되는지, 어떤 위반이 슬래싱 대상인지, 어떤 보상을 보내는지, 체인의 이탈 또는 전환 절차가 무엇인지 확인하세요. 보안은 실제 설정과 운영 기간에 연결됩니다.
소비자 체인의 정확한 ID와 제공자부터 확인하세요. Top N과 opt-in 중 어떤 방식을 쓰는지, 투표권 상한이나 허용·차단 목록이 집합을 바꾸는지, 공개된 검증자 목록이 최신 변경을 반영하는지 살펴보세요. 검증자 수만 세어서는 투표권 집중도를 알 수 없습니다.
검증자나 위임자라면 해당 검증자가 opt-in해야 하는지, 소비자 전용 합의 키를 사용하는지, 올바른 실행 파일을 운영하는지, 가동 중단과 합의 위반은 어떻게 처리되는지 확인하세요. 최신 감옥·슬래싱 매개변수도 읽어야 합니다. 위임 중이라면 제공자에 묶인 지분과 지갑에 표시되는 소비자 보상을 구분하세요.
마지막으로 보상 단위 허용 목록, 보상 대상이 되기까지 필요한 에포크 수, 분배·수수료 규칙, 소비자 거버넌스 권한, 릴레이어와 클라이언트 상태, 최신 언본딩 및 전환 절차를 살펴보세요. 제공자 단독 스테이킹이나 토큰 전송과 비교할 때도 서로 다른 질문에 대한 답이라는 점을 기억해야 합니다. 이 모두를 하나의 “보안 공유”라는 말로 묶으면 중요한 차이를 놓칩니다.
특히 permissionless 방식에서는 사람이 읽는 chain ID만으로 소비자를 구분할 수 없을 수 있습니다. 제공자 체인이 발급한 consumer ID와 현재 단계도 함께 확인하고, 그 ID가 검증자 키 배정·참여·매개변수 조회에 쓰이는 대상과 일치하는지 살펴보세요. 공개된 런치 자료의 실행 파일 해시와 시작 시각도 실제 운영자가 사용하는 값과 대조해야 합니다. 이렇게 확인하면 비슷한 이름의 체인이나 이전 버전의 매개변수를 현재 설정으로 착각할 가능성을 줄일 수 있습니다.
위임자는 지갑이나 대시보드에 표시된 총 APR만 보지 말고, 제공자 기본 스테이킹 보상과 소비자 보상을 단위와 발생 경로별로 나눠야 합니다. 보상 단위가 IBC denom으로 표시된다면 어떤 소비자에서 왔는지 추적하고, 제공자가 해당 denom을 허용하는지 확인하세요. 검증자 수수료와 제공자 분배 수수료도 같은 항목이 아닙니다. 서로 다른 보상을 합산한 연환산 숫자는 실제 청구 가능한 수량, 시점, 토큰 가격을 보장하지 않습니다.
검증자는 launch 시점에 적용되는 genesis와 실행 파일 버전, consumer 전용 합의 키 등록 여부, monitoring·업데이트 절차를 운영 측 자료와 대조해야 합니다. Top N이면 참여 요건을 충족하지 못했을 때 제공자 검증 상태에 어떤 결과가 생기는지 확인하고, opt-in이면 자발적으로 참여한 뒤 빠져나가는 조건과 소비자 보상 시작 조건을 각각 확인하세요. 위임자는 검증자가 이런 추가 작업을 실제로 수행하는지, 운영 장애나 프로토콜 변경을 어떻게 알리는지도 살펴볼 수 있습니다.
신고가 접수됐다는 사실을 제재가 확정됐다는 뜻으로 받아들이면 안 됩니다. 가동 중단 보고는 소비자에서 올라오고, 이중 서명과 같은 합의 위반은 별도의 증거 제출 및 검증 절차를 거칩니다. 누가 증거를 제출하는지, 제공자에서 어떻게 검증하는지, 처리 전후 검증자 상태를 어디서 확인할 수 있는지 살펴보세요. 그러면 막연한 “slashing 위험” 대신 실제 사건 경로를 이해할 수 있습니다.
