크로스체인 메시징과 공유 유동성: 레이어제로 v2, 하이퍼레인, IBC 3.0의 보안 모델
레이어제로 v2 (LayerZero v2), 하이퍼레인 (Hyperlane), IBC 3.0과 같은 상호운용성 프로토콜은 멀티체인 DeFi 생태계의 핵심 인프라로 부상하고 있습니다. 각 프로토콜은 크로스체인 메시징과 공유 유동성에 대해 서로 다른 접근 방식을 취하며, 고유한 보안 모델을 가지고 있습니다.
- 레이어제로 v2 – 탈중앙화 검증 네트워크 (DVN)를 사용하는 증명 집계 모델
- 하이퍼레인 – 멀티시그 검증인 위원회를 자주 사용하는 모듈식 프레임워크
- IBC 3.0 – 코스모스 생태계 내 신뢰 최소화 릴레이어를 갖춘 라이트 클라이언트 프로토콜
이 보고서는 각 프로토콜의 보안 메커니즘을 분석하고, 라이트 클라이언트, 멀티시그, 증명 집계 방식의 장단점을 비교하며, DeFi 구성성과 유동성에 미치는 영향을 살펴봅니다. 또한 현재 구현 현황, 위협 모델, 채택 수준을 검토하고, 이러한 설계 선택이 멀티체인 DeFi의 장기적인 생존 가능성에 어떻게 영향을 미치는지에 대한 전망으로 마무리합니다.
주요 크로스체인 프로토콜의 보안 메커니즘
레이어제로 v2: 탈중앙화 검증 네트워크 (DVN)를 통한 증명 집계
레이어제로 v2는 모듈식, 애플리케이션 구성 가능 보안 레이어를 강조하는 옴니체인 메시징 프로토콜입니다. 핵심 아이디어는 애플리케이션이 하나 이상의 독립적인 **탈중앙화 검증 네트워크 (DVN)**를 통해 메시지를 보호하도록 하는 것입니다. 이 DVN들은 집합적으로 크로스체인 메시지를 증명합니다. 레이어제로의 증명 집계 모델에서 각 DVN은 본질적으로 메시지를 독립적으로 검증할 수 있는 검증인들의 집합입니다 (예: 블록 증명 또는 서명 확인). 애플리케이션은 메시지를 수락하기 전에 여러 DVN으로부터 집계된 증명을 요구할 수 있으며, 이를 통해 임계값 기반의 "보안 스택"을 형성합니다.
기본적으로 레이어제로는 몇 가지 DVN을 즉시 사용할 수 있도록 제공합니다. 예를 들어, 2/3 멀티시그 검증을 사용하는 레이어제로 랩스 운영 DVN과 구글 클라우드가 운영하는 DVN이 있습니다. 하지만 결정적으로, 개발자들은 DVN을 혼합하여 사용할 수 있습니다. 예를 들어, 특정 DVN의 서명 과 함께 다른 5개 중 2개의 서명을 요구하는 "1 of 3 of 5" 구성을 요구할 수 있습니다. 이러한 유연성은 라이트 클라이언트, 영지식 증명, 오라클 등 다양한 검증 방법을 하나의 집계된 증명으로 결합할 수 있게 합니다. 사실상, 레이어제로 v2는 v1의 초경량 노드 모델 (하나의 릴레이어 + 하나의 오라클에 의존)을 DVN 간의 X-of-Y-of-N 멀티시그 집계로 일반화한 것입니다. 각 체인에 있는 애플리케이션의 레이어제로 엔드포인트 컨트랙트는 요구되는 DVN 쿼럼이 해당 메시지에 대한 유효한 증명을 작성한 경우에만 메시지를 전달합니다.
보안 특성: 레이어제로의 접근 방식은 요구되는 집합 내 최소 하나의 DVN이 정직하거나 (또는 하나의 영지식 증명이 유효한 경우 등) 신뢰가 최소화됩니다. 앱이 자체 DVN을 필수 서명자로 실행하도록 허용함으로써, 레이어제로는 앱 팀의 검증인이 승인하지 않는 한 어떤 메시지도 거부할 수 있는 권한을 앱에 부여합니다. 이는 (중앙화의 대가를 치르더라도) 보안을 크게 강화하여, 앱의 서명 없이는 어떠한 크로스체인 메시지도 실행되지 않도록 보장합니다. 반면에, 개발자들은 더 강력한 신뢰 분산을 위해 더 탈중앙화된 DVN 쿼럼 (예: 15개 독립 네트워크 중 5개)을 선택할 수도 있습니다. 레이어제로는 이를 "애플리케이션 소유 보안"이라고 부릅니다. 각 앱은 DVN을 구성하여 보안, 비용, 성능 간의 절충점을 선택합니다. 모든 DVN 증명은 궁극적으로 변경 불가능한 레이어제로 엔드포인트 컨트랙트에 의해 온체인에서 검증되어 무허가 전송 레이어를 유지합니다. 단점은 보안이 선택된 DVN만큼만 강력하다는 것입니다. 만약 구성된 DVN들이 공모하거나 손상되면, 사기성 크로스체인 메시지를 승인할 수 있습니다. 따라서 각 애플리케이션은 견고한 DVN을 선택하거나 더 약한 보안의 위험을 감수해야 하는 부담을 가집니다.
하이퍼레인: 모듈식 ISM을 갖춘 멀티시그 검증인 모델
하이퍼레인은 대상 체인에서 메시지가 전달되기 전에 이를 검증하는 온체인 **인터체인 보안 모듈 (ISM)**을 중심으로 하는 상호운용성 프레임워크입니다. 가장 간단한 (그리고 기본) 구성에서, 하이퍼레인의 ISM은 멀티시그 검증인 집합을 사용합니다. 오프체인 검증인 위원회가 소스 체인에서 나가는 모든 메시지의 머클 루트와 같은 증명에 서명하고, 목적지에서는 임계값 이상의 서명이 필요합니다. 즉, 하이퍼레인은 "메시지 X가 체인 A에서 실제로 발생했다"는 것을 확인하기 위해 허가형 검증인 쿼럼에 의존하며, 이는 블록체인의 합의와 유사하지만 브리지 수준에서 이루어집니다. 예를 들어, 웜홀은 19명의 가디언과 13/19 멀티시그를 사용하는데, 하이퍼레인의 접근 방식은 정신적으로 유사합니다 (물론 하이퍼레인은 웜홀과 다릅니다).
핵심 특징은 하이퍼레인이 프로토콜 수준에서 단일한 고정 검증인 집합을 가지고 있지 않다는 것입니다. 대신, 누구나 검증인을 운영할 수 있으며, 다른 애플리케이션들은 다른 검증인 목록과 임계값을 가진 ISM 컨트랙트를 배포할 수 있습니다. 하이퍼레인 프로토콜은 기본 ISM 배포 (팀이 부트스트랩한 검증인 집합 포함)를 제공하지만, 개발자들은 자신의 앱에 맞게 검증인 집합이나 보안 모델을 자유롭게 커스터마이징할 수 있습니다. 실제로 하이퍼레인은 여러 유형의 ISM을 지원하며, 여기에는 여러 검증 방법을 결합하는 **집계 ISM (Aggregation ISM)**과 메시지 매개변수에 따라 ISM을 선택하는 **라우팅 ISM (Routing ISM)**이 포함됩니다. 예를 들어, 앱은 하이퍼레인 멀티시그 와 외부 브리지 (웜홀이나 액셀러 등)의 서명을 모두 요구하여 중복성을 통해 더 높은 보안 수준을 달성할 수 있습니다.
보안 특성: 하이퍼레인 멀티시그 모델의 기본 보안은 대다수 검증인의 정직성에서 비롯됩니다. 만약 임계값 (예: 8명 중 5명)의 검증인이 공모하면 사기성 메시지에 서명할 수 있으므로, 신뢰 가정은 대략 N-of-M 멀티시그 신뢰입니다. 하이퍼레인은 아이겐레이어 리스테이킹과 통합하여 이 위험을 해결하고 있으며, 검증인들이 잘못된 행동에 대해 슬래싱될 수 있는 스테이킹된 ETH를 예치하도록 요구하는 *경제적 보안 모듈 (ESM)*을 만들고 있습니다. 이 "액티브 검증 서비스 (AVS)"는 만약 하이퍼레인 검증인이 유효하지 않은 메시지 (실제로 소스 체인 기록에 없는 메시지)에 서명하면, 누구나 이더리움에 증거를 제출하여 해당 검증인의 지분을 슬래싱할 수 있음을 의미합니다. 이는 사기를 경제적으로 억제함으로써 보안 모델을 크게 강화합니다. 하이퍼레인의 크로스체인 메시지는 검증인의 사회적 평판뿐만 아니라 이더리움의 경제적 가치 에 의해 보호됩니다. 그러나 한 가지 절충점은 슬래싱을 위해 이더리움에 의존하면 이더리움의 활성성에 대한 의존성이 생기고, 사기 증명을 제시간에 제출하는 것이 가능하다고 가정해야 한다는 것입니다. 활성성 측면에서, 하이퍼레인은 임계값을 충족할 만큼 충분한 검증인이 온라인 상태가 아니면 메시지 전달이 중단될 수 있다고 경고합니다. 프로토콜은 유연한 임계값 구성을 허용하여 이 문제를 완화합니다. 예를 들어, 더 큰 검증인 집합을 사용하여 간헐적인 다운타임이 네트워크를 중단시키지 않도록 합니다. 전반적으로, 하이퍼레인의 모듈식 멀티시그 접근 방식은 검증인 집합에 대한 신뢰를 추가하는 대가로 유연성과 업그레이드 가능성 (앱이 자체 보안을 선택하거나 여러 소스를 결합)을 제공합니다. 이는 진정한 라이트 클라이언트보다 약한 신뢰 모델이지만, 최근의 혁신 (리스테이킹된 담보 및 슬래싱 등)을 통해 실제로는 유사한 보안 보장을 달성하면서도 여러 체인에 걸쳐 배포하기 쉬운 상태를 유지할 수 있습니다.
IBC 3.0: 신뢰 최소화 릴레이어를 갖춘 라이트 클라이언트
코스모스 생태계에서 널리 사용되는 인터체인 통신 (IBC) 프로토콜은 근본적으로 다른 접근 방식을 취합니다. 새로운 검증인 집합을 도입하는 대신, 온체 인 라이트 클라이언트를 사용하여 크로스체인 상태를 검증합니다. IBC에서 각 체인 쌍은 연결을 설정하며, 체인 B는 체인 A의 라이트 클라이언트를 보유합니다 (그 반대도 마찬가지). 이 라이트 클라이언트는 본질적으로 상대 체인의 합의에 대한 단순화된 복제본입니다 (예: 검증인 집합 서명 또는 블록 해시 추적). 체인 A가 체인 B로 메시지 (IBC 패킷)를 보낼 때, 릴레이어 (오프체인 행위자)는 증명 (패킷의 머클 증명과 최신 블록 헤더)을 체인 B로 전달합니다. 그러면 체인 B의 IBC 모듈은 온체인 라이트 클라이언트를 사용하여 해당 증명이 체인 A의 합의 규칙 하에서 유효한지 검증합니다. 증명이 확인되면 (즉, 패킷이 A의 확정된 블록에 커밋된 경우), 메시지는 수락되어 B의 대상 모듈로 전달됩니다. 본질적으로, 체인 B는 중개자가 아닌 체인 A의 합의를 직접 신뢰합니다. 이것이 IBC가 종종 신뢰 최소화 상호운용성이라고 불리는 이유입니다.
IBC 3.0은 이 프로토콜의 최신 진화 (2025년경)를 의미하며, 더 낮은 지연 시간을 위한 병렬 릴레이, 특수 사용 사례를 위한 맞춤형 채널 유형, 원격 상태 읽기를 위한 인터체인 쿼리와 같은 성능 및 기능 업그레이드를 도입합니다. 주목할 점은 이들 중 어느 것도 핵심 라이트 클라이언트 보안 모델을 변경하지 않는다는 것입니다. 속도와 기능성을 향상시킬 뿐입니다. 예를 들어, 병렬 릴레이는 여러 릴레이어가 병목 현상을 피하기 위해 동시에 패킷을 전달할 수 있음을 의미하며, 보안을 희생하지 않고 활성성을 향상시킵니다. **인터체인 쿼리 (ICQ)**는 체인 A의 컨트랙트가 체인 B에 데이터 (증명 포함)를 요청할 수 있게 하며, 이는 A의 B에 대한 라이트 클라이언트에 의해 검증됩니다. 이는 IBC의 기능을 토큰 전송을 넘어 더 일반적인 크로스체인 데이터 액세스로 확장하며, 여전히 검증된 라이트 클라이언트 증명에 기반합니다.
보안 특성: IBC의 보안 보장은 소스 체인의 무결성만큼 강력합니다. 체인 A가 정직한 다수 (또는 구성된 합의 임계값)를 가지고 있고, 체인 B의 A에 대한 라이트 클라이언트가 최신 상태라면, 수락된 모든 패킷은 반드시 A의 유효한 블록에서 온 것이어야 합니다. 브리지 검증인이나 오라클을 신뢰할 필요가 없습니다. 유일한 신뢰 가정은 두 체인의 네이티브 합의와 라이트 클라이언트의 신뢰 기간 (이 기간이 지나면 오래된 헤더가 만료됨)과 같은 일부 매개변수뿐입니다. IBC의 릴레이어는 신뢰할 필요가 없습니다. 유효한 헤더나 패킷을 위조할 수 없는데, 이는 검증에 실패할 것이기 때문입니다. 최악의 경우, 악의적이거나 오프라인인 릴레이어는 메시지를 검열하거나 지연시킬 수 있지만, 누구나 릴레이어를 운영할 수 있으므로 최소 한 명의 정직한 릴레이어가 존재하면 결국 활성성이 달성됩니다. 이것은 매우 강력한 보안 모델입니다. 사실상 기본적으로 탈중앙화되고 무허가이며, 체인 자체의 속성을 반영합니다. 절충점은 비용과 복잡성에 있습니다. 다른 체인에서 라이트 클라이언트 (특히 처리량이 높은 체인의 경우)를 실행하는 것은 리소스 집약적일 수 있습니다 (검증인 집합 변경 사항 저장, 서명 검증 등). 텐더민트/BFT를 사용하는 코스모스 SDK 체인의 경우 이 비용은 관리 가능하며 IBC는 매우 효율적입니다. 하지만 이더리움이나 솔라나와 같은 이종 체인을 통합하려면 복잡한 클라이언트 구현이나 새로운 암호학이 필요합니다. 실제로, IBC를 통해 비-코스모스 체인을 브리징하는 것은 더 느렸습니다. 폴리머 (Polymer)나 컴포저블 (Composable)과 같은 프로젝트들이 IBC를 이더리움 및 다른 체인으로 확장하기 위해 라이트 클라이언트나 영지식 증명을 개발하고 있습니다. IBC 3.0의 개선 사항 (예: 최적화된 라이트 클라이언트, 다른 검증 방법 지원)은 이러한 비용을 줄이는 것을 목표로 합니다. 요약하자면, IBC의 라이트 클라이언트 모델은 더 높은 구현 복잡성과 모든 참여 체인이 IBC 프로토콜을 지원해야 한다는 제한을 감수하는 대신, 가장 강력한 신뢰 보장 (외부 검증인 없음)과 견고한 활성성 (여러 릴레이어 존재 시)을 제공합니다.
라이트 클라이언트, 멀티시그, 증명 집계 비교
각 보안 모델 – 라이트 클라이언트 (IBC), 검증인 멀티시그 (하이퍼레인), 집계된 증명 (레이어제로) – 은 뚜렷한 장단점을 가집니다. 아래에서 주요 차원별로 비교해 보겠습니다.
보안 보장
-
라이트 클라이언트 (IBC): 소스 체인의 합의에 온체인 검증을 고정함으로써 최고 수준의 보안을 제공합니다. 새로운 신뢰 계층이 없습니다. 소스 블록체인 (예: 코스모스 허브 또는 이더리움)이 이중 블록을 생성하지 않는다고 신뢰한다면, 해당 체인이 보내는 메시지도 신뢰할 수 있습니다. 이는 추가적인 신뢰 가정과 공격 표면을 최소화합니다. 그러나 소스 체인의 검증인 집합이 손상되면 (예: 텐더민트에서 >⅓ 또는 PoS 체인에서 >½이 악의적으로 행동), 라이트 클라이언트에 사기성 헤더가 제공될 수 있습니다. 실제로는 IBC 채널이 주로 경제적으로 안전한 체인 간에 설정되며, 라이트 클라이언트는 위험을 완화하기 위해 신뢰 기간 및 블록 완결성 요구 사항과 같은 매개변수를 가질 수 있습니다. 전반적으로, 신뢰 최소화는 라이트 클라이언트 모델의 가장 강력한 장점입니다. 각 메시지에 대한 암호학적 유효성 증명이 있습니다.
-
멀티시그 검증인 (하이퍼레인 및 유사 브리지): 보안은 오프체인 서명자 집합의 정직성에 달려 있습니다. 일반적인 임계값 (예: 검증인의 ⅔)이 각 크로스체인 메시지 또는 상태 체크포인트에 서명해야 합니다. 장점은 충분히 평판이 좋거나 경제적으로 스테이킹된 검증인이 있다면 상당히 안전하게 만들 수 있다는 것입니다. 예를 들어, 웜홀의 19명 가디언이나 하이퍼레인의 기본 위원회는 시스템을 손상시키기 위해 집단적으로 공모해야 합니다. 단점은 이것이 새로운 신뢰 가정을 도입한다는 것입니다. 사용자는 체인 외에 브리지의 위원회도 신뢰해야 합니다. 이는 일부 해킹에서 실패 지점이 되었습니다 (예: 개인 키가 도난당하거나 내부자가 공모하는 경우). 하이퍼레인의 리스테이킹된 ETH 담보와 같은 이니셔티브는 이 모델에 경제적 보안을 추가합니다. 유효하지 않은 데이터에 서명한 검증인은 이더리움에서 자동으로 슬래싱될 수 있습니다. 이는 멀티시그 브리지를 블록체인의 보안에 더 가깝게 만듭니다 (사기를 재정적으로 처벌함으로써). 하지만 여전히 라이트 클라이언트만큼 신뢰가 최소화되지는 않습니다. 요약하면, 멀티시그는 신뢰 보장 측면에서 더 약합니다. 소규모 그룹의 다수에 의존하지만, 슬래싱과 감사는 신뢰를 강화할 수 있습니다.
-
증명 집계 (레이어제로 v2): 이것은 다소 중간 지점입니다. 애플리케이션이 보안 스택에 라이트 클라이언트 DVN 또는 영지식 증명 DVN을 포함하도록 구성하면, 해당 검증에 대한 보장은 IBC 수준 (수학 및 체인 합의)에 근접할 수 있습니다. 위원회 기반 DVN (레이어제로의 2/3 기본값 또는 액셀러 어댑터 등)을 사용하면 해당 멀티시그의 신뢰 가정을 상속받습니다. 레이어제로 모델의 강점은 여러 검증인을 독립적으로 결합할 수 있다는 것입니다. 예를 들어, "영지식 증명이 유효함" 과 "체인링크 오라클이 블록 헤더가 X라고 말함" 과 "우리 자체 검증인이 서명함"을 모두 요구하면 공격 가능성을 극적으로 줄일 수 있습니다 (공격자는 이 모든 것을 한 번에 깨뜨려야 함). 또한, 앱이 자체 DVN을 의무화하도록 허용함으로써, 레이어제로는 그렇게 구성된 경우 앱의 동의 없이는 어떤 메시지도 실행되지 않도록 보장합니다. 약점은 개발자가 (더 저렴한 수수료나 속도를 위해) 느슨한 보안 구성을 선택하면 보안을 약화시킬 수 있다는 것입니다. 예를 들어, 알려지지 않은 당사자가 운영하는 단 일 DVN을 사용하는 것은 단일 검증인을 신뢰하는 것과 유사합니다. 레이어제로 자체는 의견이 없으며 이러한 선택을 앱 개발자에게 맡기므로, 보안은 선택된 DVN만큼만 좋습니다. 요약하면, 증명 집계는 매우 강력한 보안 (여러 독립적인 증명을 요구함으로써 단일 라이트 클라이언트보다 더 높을 수 있음)을 제공할 수 있지만, 잘못 구성되면 약한 설정도 허용합니다. 유연합니다. 앱은 고가치 거래에 대해 보안을 강화하고 (예: 여러 대형 DVN 요구) 저가치 거래에 대해서는 완화할 수 있습니다.
활성성 및 가용성
-
라이트 클라이언트 (IBC): 활성성은 릴레이어와 라이트 클라이언트가 최신 상태를 유지하는지에 따라 달라집니다. 긍정적인 측면은 누구나 릴레이어를 운영할 수 있다는 것이므로, 시스템이 특정 노드 집합에 의존하지 않습니다. 한 릴레이어가 멈추면 다른 릴레이어가 작업을 이어받을 수 있습니다. IBC 3.0의 병렬 릴레이는 모든 패킷을 하나의 경로로 직렬화하지 않음으로써 가용성을 더욱 향상시킵니다. 실제로는 IBC 연결이 매우 안정적이었지만, 활성성이 저하될 수 있는 시나리오가 있습니다. 예를 들어, 오랫동안 릴레이어가 업데이트를 게시하지 않으면 라이트 클라이언트가 만료될 수 있고 (예: 신뢰 기간이 갱신 없이 지나면) 안전을 위해 채널이 닫힙니다. 그러나 이러한 경우는 드물며 활발한 릴레이어 네트워크에 의해 완화됩니다. 또 다른 활성성 고려 사항은 IBC 패킷이 소스 체인 완결성의 영향을 받는다는 것입니다. 예를 들어, 텐더민트에서 1-2 블록 (몇 초)을 기다리는 것이 표준입니다. 전반적으로, IBC는 최소 한 명의 활성 릴레이어가 있는 한 높은 가용성을 제공하며, 지연 시간은 일반적으로 확정된 블록에 대해 낮습니다 (초 단위). 멀티시그에서처럼 검증인 쿼럼이 오프라인이 되는 개념은 없습니다. 블록체인 자체의 합의 완결성이 주요 지연 시간 요인입니다.
-
멀티시그 검증인 (하이퍼레인): 검증인 집합이 작으면 활성성이 약점이 될 수 있습니다. 예를 들어, 브리지가 8명 중 5명의 멀티시그를 사용하고 4명의 검증인이 오프라인이거나 연결할 수 없는 경우, 임계값을 충족할 수 없으므로 크로스체인 메시징이 중단됩니다. 하이퍼레인 문서는 검증인 다운타임이 구성된 임계값에 따라 메시지 전달을 중단시킬 수 있다고 언급합니다. 이것이 가동 시간을 개선하기 위해 더 큰 위원회나 더 낮은 임계값 (안전성 절충)을 선택하는 이유 중 하나입니다. 하이퍼레인의 설계는 필요한 경우 새로운 검증인을 배포하거나 ISM을 전환할 수 있도록 하지만, 이러한 변경에는 조정/거버넌스가 필요할 수 있습니다. 멀티시그 브리지의 장점은 일반적으로 임계값 서명이 수집되면 빠른 확인이 가능하다는 것입니다. 목적지 체인에서 소스 체인의 블록 완결성을 기다릴 필요가 없는데, 멀티시그 증명 자체가 완결성이기 때문입니다. 실제로는 많은 멀티시그 브리지가 몇 초 내에 메시지를 서명하고 릴레이합니다. 따라서 일부 체인에서는 지연 시간이 라이트 클라이언트와 비슷하거나 더 낮을 수 있습니다. 병목 현상은 검증인이 느리거나 지리적으로 분산되어 있거나 수동 단계가 포함된 경우 발생합니다. 요약하면, 멀티시그 모델은 대부분의 경우 매우 활성적이고 지연 시간이 낮을 수 있지만, 검증인 집합에 활성성 위험이 집중되어 있습니다. 너무 많은 검증인이 충돌하거나 그들 사이에 네트워크 분할이 발생하면 브리지는 사실상 다운됩니다.
-
증명 집계 (레이어제로): 여기서 활성성은 각 DVN과 릴레이어의 가용성에 따라 달라집니다. 메시지는 필요한 DVN으로부터 서명/증명을 수집한 다음 대상 체인으로 릴레이되어야 합니다. 좋은 점은 DVN이 독립적으로 작동한다는 것입니다. 만약 (집합 중 하나인) DVN 하나가 다운되고 그것이 필수가 아니라면 ("N 중 M"의 일부일 뿐), 임계값이 충족되는 한 메시지는 계속 진행될 수 있습니다. 레이어제로의 모델은 일부 DVN 실패를 용납하도록 쿼럼을 구성하는 것을 명시적으로 허용합니다. 예를 들어, "5개 중 2개" DVN 집합은 프로토콜을 중단시키지 않고 3개의 DVN이 오프라인인 상태를 처리할 수 있습니다. 또한, 누구나 최종 실행자/릴레이어 역할을 할 수 있기 때문에 메시지 전달에 단일 실패 지점이 없습니다. 주 릴레이어가 실패하면 사용자나 다른 당사자가 증명을 가지고 컨트랙트를 호출할 수 있습니다 (이는 IBC의 무허가 릴레이어 개념과 유사합니다). 따라서 레이어제로 v2는 시스템을 하나의 중개인에 묶지 않음으로써 검열 저항성과 활성성을 추구합니다. 그러나 필수 DVN이 보안 스택의 일부인 경우 (예: 앱이 항상 자체 DVN의 서명을 요구하는 경우), 해당 DVN은 활성성 의존성이 됩니다. 오프라인이 되면 메시지는 다시 온 라인이 되거나 보안 정책이 변경될 때까지 일시 중지됩니다. 일반적으로, 증명 집계는 (중복 DVN과 모든 당사자 릴레이를 통해) 모든 검증인이 동시에 다운될 가능성이 거의 없도록 견고하게 구성될 수 있습니다. 절충점은 여러 DVN에 연락하는 것이 단일의 더 빠른 멀티시그에 비해 약간 더 많은 지연 시간을 유발할 수 있다는 것입니다 (예: 여러 서명을 기다리는 것). 그러나 이러한 DVN은 병렬로 실행될 수 있으며, 많은 DVN (오라클 네트워크나 라이트 클라이언트 등)은 신속하게 응답할 수 있습니다. 따라서 레이어제로는 높은 활성성과 낮은 지연 시간을 달성할 수 있지만, 정확한 성능은 DVN이 어떻게 설정되었는지에 따라 달라집니다 (일부는 안전을 위해 소스 체인에서 몇 번의 블록 확인을 기다릴 수 있으며, 이는 지연을 추가할 수 있습니다).
비용 및 복잡성
-
라이트 클라이언트 (IBC): 이 접근 방식은 구현은 복잡하지만 호환되는 체인에 설정되면 사용 비용이 저렴한 경향이 있습니다. 복잡성은 각 블록체인 유형에 대한 정확한 라이트 클라이언트 구현을 작성하는 데 있습니다. 본질적으로 체인 A의 합의 규칙을 체인 B의 스마트 컨트랙트에 인코딩하는 것입니다. 유사한 합의를 가진 코스모스 SDK 체인의 경우 이는 간단했지만, 코스모스를 넘어 IBC를 확장하려면 상당한 엔지니어링이 필요했습니다 (예: 폴카닷의 GRANDPA 완결성을 위한 라이트 클라이언트 구축 또는 영지식 증명을 사용 한 이더리움 라이트 클라이언트 계획). 이러한 구현은 사소하지 않으며 매우 안전해야 합니다. 온체인 저장 공간 오버헤드도 있습니다. 라이트 클라이언트는 상대 체인의 최근 검증인 집합 또는 상태 루트 정보를 저장해야 합니다. 이는 체인의 상태 크기와 증명 검증 비용을 증가시킬 수 있습니다. 결과적으로, 예를 들어 이더리움 메인넷에서 직접 IBC를 실행하는 것 (코스모스 헤더 검증)은 가스 측면에서 비쌀 것입니다. 이것이 폴리머와 같은 프로젝트가 이러한 라이트 클라이언트를 메인넷 외부에서 호스팅하기 위해 이더리움 롤업을 만드는 이유 중 하나입니다. 코스모스 생태계 내에서 IBC 트랜잭션은 매우 효율적입니다 (종종 몇 센트 상당의 가스만 소요). 이는 라이트 클라이언트 검증 (ed25519 서명, 머클 증명)이 프로토콜 수준에서 잘 최적화되어 있기 때문입니다. 사용자에게 IBC 사용 비용은 상대적으로 저렴하며, 릴레이어는 목적지 체인에서 일반적인 트랜잭션 수수료만 지불합니다 (ICS-29 미들웨어를 통해 수수료로 인센티브를 받을 수 있음). 요약하면, IBC의 비용은 개발 복잡성에 선행 투자되지만, 일단 실행되면 네이티브하고 수수료 효율적인 전송을 제공합니다. 연결된 많은 코스모스 체인 (100개 이상의 존)은 공통 구현을 공유하므로 표준화를 통해 복잡성을 관리하는 데 도움이 됩니다.
-
멀티시그 브리지 (하이퍼레인/웜홀 등): 여기서 구현 복잡성은 종종 더 낮습니다. 핵심 브리징 컨트랙트는 대부분 저장된 공개 키에 대해 서명 집합을 검증하기만 하면 됩니다. 이 로직은 완전한 라이트 클라이언트보다 간단합니다. 오프체인 검증인 소프트웨어는 운영상의 복잡성을 도입하 지만 (체인 이벤트를 관찰하고, 메시지의 머클 트리를 유지하며, 서명 수집을 조정하는 등), 이는 브리지 운영자가 관리하고 오프체인에 유지됩니다. 온체인 비용: 몇 개의 서명 (예: 2개 또는 5개의 ECDSA 서명)을 검증하는 것은 너무 비싸지는 않지만, 단일 임계값 서명이나 해시 확인보다는 확실히 더 많은 가스를 소모합니다. 일부 브리지는 온체인 비용을 1개의 서명 검증으로 줄이기 위해 집계 서명 체계 (예: BLS)를 사용합니다. 일반적으로 이더리움이나 유사한 체인에서 멀티시그 검증은 보통의 비용이 듭니다 (각 ECDSA 서명 확인은 약 3000 가스). 브리지가 10개의 서명을 요구하면 검증에만 약 3만 가스가 들고, 새로운 머클 루트 저장 등이 추가됩니다. 이는 크로스체인 전송이 고가치 작업임을 감안할 때 일반적으로 수용 가능하지만, 누적될 수 있습니다. 개발자/사용자 관점에서 멀티시그 브리지와 상호 작용하는 것은 간단합니다. 입금하거나 전송 함수를 호출하면 나머지는 검증인/릴레이어가 오프체인에서 처리한 다음 증명이 제출됩니다. 앱 개발자에게는 브리지의 API/컨트랙트를 통합하기만 하면 되므로 복잡성이 거의 없습니다. 한 가지 복잡성 고려 사항은 새로운 체인 추가입니다. 모든 검증인은 메시지를 관찰하기 위해 각 새로운 체인에 대한 노드나 인덱서를 실행해야 하며, 이는 조정의 골칫거리가 될 수 있습니다 (이는 일부 멀티시그 설계에서 확장 병목 현상으로 지적되었습니다). 하이퍼레인의 해답은 무허가 검증인 (ISM에 포함된 경우 누구나 체인에 참여할 수 있음)이지만, ISM을 배포하는 애플리케이션은 여전히 초기에 해당 키를 설정해야 합니다. 전반적으로, 멀티시그 모델은