"보안" 태그로 연결된 5개 게시물개의 게시물이 있습니다.

위험, 감사 또는 컴플라이언스를 손상시키지 않으면서 시장 속도에 맞춰 움직이는 보관 및 실행 스택을 설계하는 방법.

--

요약​

보관과 거래는 이제 별개의 영역이 될 수 없습니다. 오늘날 디지털 자산 시장에서 고객 자산을 안전하게 보관하는 것만으로는 충분하지 않습니다. 가격이 움직일 때 밀리초 단위로 거래를 실행하지 못하면 수익을 놓치게 되고, 최대 추출 가치(MEV), 거래 상대방 실패, 운영 병목과 같은 회피 가능한 위험에 노출됩니다. 현대적인 보관 및 실행 스택은 최첨단 보안과 고성능 엔지니어링을 결합해야 합니다. 이는 서명을 위한 다중당사계산(MPC) 및 하드웨어 보안 모듈(HSM)과 같은 기술을 통합하고, 정책 엔진 및 프라이빗 트랜잭션 라우팅을 사용해 프론트러닝을 완화하며, 오프체인 결제 정산을 통한 액티브/액티브 인프라를 활용해 거래소 위험을 줄이고 자본 효율성을 높이는 것을 의미합니다. 또한 컴플라이언스는 부가 기능이 될 수 없으며, 여행 규칙 데이터 흐름, 불변 감사 로그, SOC 2와 같은 프레임워크에 매핑된 제어를 거래 파이프라인에 직접 내장해야 합니다.

“보관 속도”가 지금 중요한 이유​

과거 디지털 자산 보관업체는 한 가지 목표에 집중했습니다: 키를 잃지 않기. 이는 여전히 기본이지만, 요구사항은 진화했습니다. 오늘날 최선 실행과 시장 무결성은 동등하게 협상 불가능한 요구사항입니다. 거래가 공개 메모풀을 통과하면 정교한 행위자가 이를 보고 재정렬하거나 “샌드위치” 공격을 통해 손해를 입힐 수 있습니다. 이는 MEV의 실제 사례이며 실행 품질에 직접적인 영향을 미칩니다. 프라이빗 트랜잭션 릴레이를 사용해 민감한 주문 흐름을 공개에서 차단하는 것이 효과적인 방어책입니다.

동시에 거래소 위험도 지속적인 우려 사항입니다. 대규모 잔액을 단일 거래소에 집중하면 상당한 거래 상대방 위험이 발생합니다. 오프체인 정산 네트워크는 거래소가 제공하는 신용을 활용하면서 자산을 분리된 파산 방지 보관에 유지하도록 하여 해결책을 제공합니다. 이 모델은 안전성과 자본 효율성을 크게 향상시킵니다.

규제 당국도 격차를 메우고 있습니다. 금융 행동 태스크포스(FATF) 여행 규칙 집행과 IOSCO·금융안정위원회와 같은 기관의 권고는 디지털 자산 시장을 “동일 위험, 동일 규칙” 프레임워크로 끌어당기고 있습니다. 이는 보관 플랫폼이 처음부터 컴플라이언스 데이터 흐름과 감사 가능한 제어를 내장해야 함을 의미합니다.

설계 목표 (“좋은” 모습)​

고성능 보관 스택은 몇 가지 핵심 설계 원칙을 중심으로 구축되어야 합니다:

• 예산 가능한 지연: 클라이언트 의도부터 네트워크 브로드캐스트까지의 모든 밀리초를 측정·관리·엄격한 서비스 수준 목표(SLO)로 강제합니다.
• MEV‑저항 실행: 민감한 주문은 기본적으로 프라이빗 채널을 통해 라우팅합니다. 공개 메모풀 노출은 의도적인 선택이어야 하며, 기본값이 아닙니다.
• 키 소재에 대한 실질적 보증: 개인 키는 MPC 샤드, HSM, 신뢰 실행 환경(TEE) 등 보호 경계 밖으로 절대 나가지 않아야 합니다. 키 회전, 쿼럼 적용, 강력한 복구 절차는 기본 전제입니다.
• 액티브/액티브 신뢰성: 시스템은 장애에 강해야 합니다. 이를 위해 RPC 노드와 서명자를 위한 다중 지역·다중 공급자 중복을 구축하고, 자동 회로 차단기와 킬스위치를 통해 거래소·네트워크 사고에 대응합니다.
• 컴플라이언스‑바이‑컨스트럭션: 컴플라이언스는 사후 작업이 될 수 없습니다. 아키텍처는 여행 규칙 데이터, AML/KYT 검사, 불변 감사 트레일을 위한 훅을 내장하고, 모든 제어를 SOC 2 신뢰 서비스 기준에 직접 매핑해야 합니다.

레퍼런스 아키텍처​

다음 다이어그램은 위 목표를 충족하는 보관 및 실행 플랫폼의 고수준 아키텍처를 보여줍니다.

• Policy & Risk Engine 은 모든 명령의 중앙 관문입니다. 여행 규칙 페이로드, 속도 제한, 주소 위험 점수, 서명 쿼럼 요구사항 등을 평가한 뒤에야 키 소재에 접근합니다.
• Signer Orchestrator 는 자산·정책에 가장 적합한 제어 평면으로 서명 요청을 지능적으로 라우팅합니다. 가능한 옵션:
  • MPC (Multi‑Party Computation) – t‑of‑n ECDSA/EdDSA와 같은 임계 서명 방식을 사용해 신뢰를 여러 파티·디바이스에 분산합니다.
  • HSMs (Hardware Security Modules) – 하드웨어 기반 키 보관, 결정적 백업·회전 정책을 제공합니다.
  • Trusted Execution Environments (예: AWS Nitro Enclaves) – 서명 코드를 격리하고 키를 attested된 소프트웨어에 직접 바인딩합니다.
• Execution Router 는 최적 경로로 트랜잭션을 전송합니다. 대규모·민감 주문은 프라이빗 트랜잭션 제출을 기본으로 하여 프론트러닝을 방지하고, 필요 시 공개 제출로 전환합니다. 또한 다중 공급자 RPC 페일오버 를 활용해 네트워크 정전 상황에서도 고가용성을 유지합니다.
• Observability Layer 는 시스템 상태를 실시간으로 제공합니다. 메모풀·새 블록 구독, 거래 후 정산, 불변 감사 기록 을 통해 모든 결정·서명·브로드캐스트를 기록합니다.

보안 구성 요소 (왜 중요한가)​

• 임계 서명 (MPC): 키를 여러 파티가 나눠 보관하므로 단일 머신·인간이 단독으로 자금을 이동시킬 수 없습니다. 최신 MPC 프로토콜은 생산 환경 지연 예산에 맞는 빠르고 악의적 공격에 안전한 서명을 지원합니다.
• HSM 및 FIPS 정렬: HSM은 변조 방지 하드웨어와 문서화된 보안 정책으로 키 경계를 강제합니다. FIPS 140‑3·NIST SP 800‑57 등 표준에 맞추면 감사 가능한 보안 보장을 제공합니다.
• Attested TEEs: 신뢰 실행 환경은 특정 측정된 코드와 격리된 엔클레이브에 키를 바인딩합니다. 키 관리 서비스(KMS)와 연계해 정책적으로 attested 워크로드에만 키를 제공하도록 할 수 있어 승인된 코드만 서명하도록 보장합니다.
• MEV 보호를 위한 프라이빗 릴레이: 프라이빗 릴레이는 민감 트랜잭션을 직접 블록 빌더·밸리데이터에 전달해 공개 메모풀을 우회합니다. 이는 프론트러닝 및 기타 MEV 형태 위험을 크게 감소시킵니다.
• 오프체인 정산: 담보를 분리 보관하면서 중앙화된 거래소에서 거래할 수 있게 해줍니다. 이는 거래 상대방 노출을 제한하고 순정산을 가속화하며 자본을 해방시킵니다.
• SOC 2/ISO 매핑 제어: 운영 제어를 인정받은 프레임워크에 문서화·테스트하면 고객·감사인·파트너가 보안·컴플라이언스 상태를 신뢰하고 독립적으로 검증할 수 있습니다.

지연 플레이북: 밀리초는 어디에 쓰이는가​

저지연 실행을 달성하려면 트랜잭션 수명 주기의 모든 단계가 최적화되어야 합니다:

• Intent → Policy Decision: 정책 평가 로직을 메모리에 상시 유지합니다. KYT·허용 리스트 데이터를 짧은 TTL로 캐시하고, 가능한 경우 서명 쿼럼을 사전 계산합니다.
• Signing: 지속적인 MPC 세션과 HSM 키 핸들을 활용해 콜드 스타트 오버헤드를 없앱니다. TEEs는 엔클레이브를 고정하고 attestation 경로를 미리 준비하며, 안전한 경우 세션 키를 재사용합니다.
• Broadcast: HTTP보다 RPC 노드와의 지속적인 WebSocket 연결을 선호합니다. 실행 서비스는 주요 RPC 공급자의 리전과 동일하게 배치합니다. 지연이 급증하면 멱등 재시도와 다중 공급자 헤징을 적용합니다.
• Confirmation: 트랜잭션 상태를 폴링하지 말고 네트워크에서 직접 영수증·이벤트를 구독합니다. 이러한 상태 변화를 정산 파이프라인에 스트리밍해 사용자에게 즉시 피드백을 제공하고 내부 장부를 업데이트합니다.

각 홉에 대한 엄격한 SLO 를 설정합니다(예: 정책 검사 < 20 ms, 서명 < 50‑100 ms, 브로드캐스트 < 50 ms(정상 부하 시)). 오류 예산과 자동 페일오버를 통해 p95·p99 지연이 악화될 때 즉시 대응합니다.

설계에 내재된 위험·컴플라이언스​

현대 보관 스택은 컴플라이언스를 시스템의 일부로 취급해야 합니다.

• 여행 규칙 오케스트레이션: 모든 전송 명령에 대해 발신자·수신자 데이터를 실시간으로 생성·검증합니다. 알 수 없는 가상자산 서비스 제공자(VASP)와의 거래는 자동 차단하거나 우회하고, 모든 데이터 교환에 대한 암호화 영수증을 감사 로그에 기록합니다.
• 주소 위험·허용 리스트: 온체인 분석·제재 스크리닝 리스트를 정책 엔진에 직접 통합합니다. 기본적으로 차단(deny‑by‑default) 방식을 적용해 명시적으로 허용된 주소 또는 정책 예외에만 전송을 허용합니다.
• 불변 감사: 모든 요청·승인·서명·브로드캐스트를 해시해 추가 불가능한 원장에 기록합니다. 이는 변조 방지 감사 트레일을 형성해 SIEM에 실시간 위협 탐지를 제공하고, 감사인에게 제어 테스트 자료를 제공합니다.
• 제어 프레임워크: 모든 기술·운영 제어를 SOC 2 신뢰 서비스 기준(보안, 가용성, 처리 무결성, 기밀성, 프라이버시)에 매핑하고, 지속적인 테스트·검증 프로그램을 운영합니다.

오프체인 정산: 더 안전한 거래소 연결​

기관 규모의 보관 스택은 거래소 노출을 최소화해야 합니다. 오프체인 정산 네트워크 는 이를 가능하게 합니다. 기업은 자체 분리 보관에 자산을 유지하면서 거래소가 제공하는 신용을 이용해 즉시 거래할 수 있습니다. 최종 정산은 고정 주기로 DvP(Delivery versus Payment)와 유사한 보증을 통해 이루어집니다.

이 설계는 “핫 월렛” 규모를 크게 줄이고 거래소 위험을 감소시키며, 활발한 거래에 필요한 속도를 유지합니다. 또한 자본 효율성을 높여 여러 거래소에 과다하게 자금을 배치할 필요가 없어지고, 담보를 분리·감사 가능하게 함으로써 운영 위험 관리가 단순화됩니다.

제어 체크리스트 (런북에 복사·붙여넣기)​

• 키 보관
  • 독립된 신뢰 도메인(멀티‑클라우드, 온프레미스, HSM 등) 간 t‑of‑n 임계값을 적용한 MPC.
  • 가능하면 FIPS‑인증 모듈 사용; 분기별 키 회전 및 사고 시 재키 계획 유지.
• 정책·승인
  • 속도 제한·행동 히스토리·업무 시간 제약을 포함한 동적 정책 엔진 구현.
  • 고위험 작업에 4인 승인(4‑eyes) 적용.
  • 서명 전 반드시 주소 허용 리스트와 여행 규칙 검증 수행.
• 실행 강화
  • 대규모·민감 주문은 기본적으로 프라이빗 트랜잭션 릴레이 사용.
  • 상태 기반 헤징과 강력한 재전송 방지를 위한 이중 RPC 공급자 활용.
• 모니터링·대응
  • 의도율, 가스 가격 급등, 네트워크 오류 등을 실시간으로 감시하고 알림 설정.
  • SIEM 연동을 통한 실시간 위협 탐지 및 자동 회로 차단기 적용.
• 컴플라이언스
  • 여행 규칙, AML/KYT, 불변 감사 로그 등 모든 제어를 SOC 2 기준에 매핑하고 정기적인 내부 감사를 수행.

코드 예시​

레이어제로 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을 배포하는 애플리케이션은 여전히 초기에 해당 키를 설정해야 합니다. 전반적으로, 멀티시그 모델은 이종 체인 간에 부트스트랩하기 더 쉽고 (체인별 맞춤형 라이트 클라이언트 필요 없음), 시장 출시가 더 빠르지만, 오프체인 운영 복잡성과 보통의 온체인 검증 비용이 발생합니다.

• 증명 집계 (레이어제로): 여기서 복잡성은 가능한 많은 검증 방법의 조정에 있습니다. 레이어제로는 표준화된 인터페이스 (엔드포인트 및 MessageLib 컨트랙트)를 제공하고 DVN이 특정 검증 API를 준수할 것을 기대합니다. 애플리케이션 관점에서 레이어제로를 사용하는 것은 매우 간단하지만 (lzSend를 호출하고 lzReceive 콜백을 구현), 내부적으로는 많은 일이 벌어집니다. 각 DVN은 자체 오프체인 인프라를 가질 수 있습니다 (일부 DVN은 본질적으로 액셀러 네트워크나 체인링크 오라클 서비스와 같은 미니 브리지 자체입니다). 프로토콜 자체는 복잡한데, 서로 다른 증명 유형을 안전하게 집계해야 하기 때문입니다. 예를 들어, 한 DVN은 EVM 블록 증명을 제공하고, 다른 DVN은 SNARK를, 또 다른 DVN은 서명을 제공하는 등, 컨트랙트는 각각을 차례로 검증해야 합니다. 장점은 이 복잡성의 대부분이 레이어제로의 프레임워크에 의해 추상화된다는 것입니다. 비용은 얼마나 많은, 그리고 어떤 유형의 증명이 필요한지에 따라 달라집니다. 스나크를 검증하는 것은 비쌀 수 있고 (온체인 영지식 증명 검증은 수십만 가스가 들 수 있음), 몇 개의 서명을 검증하는 것은 더 저렴합니다. 레이어제로는 앱이 메시지당 보안에 대해 얼마를 지불할지 결정하게 합니다. DVN에 작업에 대한 비용을 지불하는 개념도 있습니다. 메시지 페이로드에는 DVN 서비스를 위한 수수료가 포함됩니다. 예를 들어, 앱은 DVN과 실행자가 메시지를 신속하게 처리하도록 인센티브를 주는 수수료를 첨부할 수 있습니다. 이는 비용 차원을 추가합니다. 더 안전한 구성 (많은 DVN 또는 비싼 증명을 사용)은 수수료가 더 비싸고, 간단한 1-of-1 DVN (단일 릴레이어와 같은)은 매우 저렴하지만 덜 안전할 수 있습니다. 업그레이드 가능성과 거버넌스도 복잡성의 일부입니다. 앱이 보안 스택을 변경할 수 있기 때문에 이를 수행하기 위한 거버넌스 프로세스나 관리자 키가 필요하며, 이는 그 자체로 신뢰/복잡성 관리 지점입니다. 요약하면, 레이어제로를 통한 증명 집계는 매우 유연하지만 내부적으로는 복잡합니다. 메시지당 비용은 효율적인 DVN을 선택하여 최적화할 수 있습니다 (예: 최적화된 초경량 클라이언트 사용 또는 기존 오라클 네트워크의 규모의 경제 활용). 많은 개발자들은 (기본값이 제공되는) 플러그 앤 플레이 방식을 매력적으로 생각할 것입니다. 예를 들어, 편의를 위해 기본 DVN 집합을 사용하는 것입니다. 하지만 이는 제대로 이해하지 못하면 최적이 아닌 신뢰 가정을 초래할 수 있습니다.

업그레이드 가능성 및 거버넌스​

• 라이트 클라이언트 (IBC): IBC 연결 및 클라이언트는 참여 체인의 온체인 거버넌스 제안을 통해 업그레이드될 수 있습니다 (특히 라이트 클라이언트에 수정이 필요하거나 소스 체인의 하드포크에 대한 업데이트가 필요한 경우). IBC 프로토콜 자체를 업그레이드하는 것 (예: IBC 2.0에서 3.0 기능으로)도 체인 거버넌스가 새로운 버전의 소프트웨어를 채택해야 합니다. 이는 IBC가 신중한 업그레이드 경로를 가지고 있음을 의미합니다. 변경은 느리고 합의가 필요하지만, 이는 보안 우선 접근 방식과 일치합니다. 스위치를 켤 수 있는 단일 주체는 없습니다. 각 체인의 거버넌스가 클라이언트나 매개변수 변경을 승인해야 합니다. 긍정적인 점은 이것이 취약점을 도입할 수 있는 일방적인 변경을 방지한다는 것입니다. 부정적인 점은 민첩성이 떨어진다는 것입니다. 예를 들어, 라이트 클라이언트에서 버그가 발견되면 이를 패치하기 위해 여러 체인에 걸쳐 조정된 거버넌스 투표가 필요할 수 있습니다 (비상 조정 메커니즘이 있기는 함). dApp 관점에서 IBC는 "앱 수준 거버넌스"가 없습니다. 체인이 제공하는 인프라입니다. 애플리케이션은 토큰 전송이나 인터체인 계정과 같은 IBC 모듈을 사용하고 체인의 보안에 의존합니다. 따라서 거버넌스와 업그레이드는 블록체인 수준 (허브 및 존 거버넌스)에서 발생합니다. 흥미로운 새로운 IBC 기능은 맞춤형 채널과 라우팅 (예: 폴리머나 넥서스와 같은 허브)으로, 앱을 중단시키지 않고 기본 검증 방법을 전환할 수 있습니다. 그러나 대체로 IBC는 안정적이고 표준화되어 있습니다. 업그레이드는 가능하지만 드물며, 이는 신뢰성에 기여합니다.

• 멀티시그 브리지 (하이퍼레인/웜홀): 이러한 시스템은 종종 컨트랙트를 업그레이드하거나, 검증인 집합을 변경하거나, 매개변수를 수정하기 위한 관리자 또는 거버넌스 메커니즘을 가지고 있습니다. 예를 들어, 집합에 새로운 검증인을 추가하거나 키를 교체하려면 브리지 소유자의 멀티시그나 DAO 투표가 필요할 수 있습니다. 하이퍼레인이 무허가라는 것은 모든 사용자가 맞춤형 검증인 집합으로 자신의 ISM을 배포할 수 있음을 의미하지만, 기본값을 사용하는 경우 하이퍼레인 팀이나 커뮤니티가 업데이트를 제어할 가능성이 높습니다. 업그레이드 가능성은 양날의 검입니다. 한편으로는 업그레이드/개선이 쉽지만, 다른 한편으로는 중앙화 위험이 될 수 있습니다 (권한 있는 키가 브리지 컨트랙트를 업그레이드할 수 있다면, 이론적으로 해당 키가 브리지를 러그풀할 수 있음). 잘 관리되는 프로토콜은 이를 제한할 것입니다 (예: 시간 잠금 업그레이드 또는 탈중앙화 거버넌스 사용). 하이퍼레인의 철학은 모듈성이므로, 앱은 실패하는 구성 요소를 ISM 전환 등으로 우회할 수도 있습니다. 이는 개발자에게 위협에 대응할 수 있는 힘을 줍니다 (예: 한 검증인 집합이 손상된 것으로 의심되면, 앱은 신속하게 다른 보안 모델로 전환할 수 있음). 거버넌스 오버헤드는 앱이 보안 모델을 결정하고 잠재적으로 자체 검증인을 위한 키를 관리하거나 하이퍼레인 핵심 프로토콜의 업데이트에 주의를 기울여야 한다는 것입니다. 요약하면, 멀티시그 기반 시스템은 더 업그레이드 가능하며 (컨트랙트는 종종 업그레이드 가능하고 위원회는 구성 가능), 이는 신속한 개선과 새로운 체인 추가에 좋지만, 거버넌스 프로세스에 대한 신뢰가 필요합니다. 과거의 많은 브리지 익스플로잇은 손상된 업그레이드 키나 결함 있는 거버넌스를 통해 발생했으므로, 이 영역은 신중하게 다루어져야 합니다. 긍정적인 측면은 새로운 체인에 대한 지원을 추가하는 것이 컨트랙트를 배포하고 검증인이 해당 노드를 실행하도록 하는 것만큼 간단할 수 있다는 것입니다. 근본적인 프로토콜 변경이 필요 없습니다.

• 증명 집계 (레이어제로): 레이어제로는 변경 불가능한 전송 레이어 (엔드포인트 컨트랙트는 업그레이드 불가)를 내세우지만, 검증 모듈 (메시지 라이브러리 및 DVN 어댑터)은 추가 전용이며 구성 가능합니다. 실제로는 각 체인의 핵심 레이어제로 컨트랙트는 고정된 상태로 유지되면서 (안정적인 인터페이스 제공), 새로운 DVN이나 검증 옵션이 핵심을 변경하지 않고 시간이 지남에 따라 추가될 수 있습니다. 애플리케이션 개발자는 자신의 보안 스택을 제어할 수 있습니다. DVN을 추가하거나 제거하고, 확인 블록 깊이를 변경하는 등의 작업을 할 수 있습니다. 이것은 앱 수준의 업그레이드 가능성 형태입니다. 예를 들어, 특정 DVN이 더 이상 사용되지 않거나 새롭고 더 나은 DVN (더 빠른 영지식 클라이언트 등)이 등장하면, 앱 팀은 이를 구성에 통합하여 dApp을 미래에 대비할 수 있습니다. 이점은 분명합니다. 앱은 과거의 보안 기술에 얽매이지 않고 새로운 개발에 (적절한 주의를 기울여) 적응할 수 있습니다. 그러나 이는 거버넌스 질문을 제기합니다. 앱 내에서 누가 DVN 집합을 변경하기로 결정하는가? 이상적으로, 앱이 탈중앙화되어 있다면 변경은 거버넌스를 통해 이루어지거나 불변성을 원한다면 하드코딩될 것입니다. 단일 관리자가 보안 스택을 변경할 수 있다면, 그것은 신뢰의 지점입니다 (악의적인 업그레이드에서 보안 요구 사항을 낮출 수 있음). 레이어제로 자체의 지침은 이러한 변경에 대한 견고한 거버넌스를 설정하거나 필요한 경우 특정 측면을 불변으로 만들 것을 권장합니다. 또 다른 거버넌스 측면은 수수료 관리입니다. DVN과 릴레이어에 지불하는 비용을 조정할 수 있으며, 잘못 정렬된 인센티브는 성능에 영향을 미칠 수 있습니다 (기본적으로 시장의 힘이 수수료를 조정해야 함). 요약하면, 레이어제로의 모델은 새로운 검증 방법을 추가하는 측면에서 매우 확장 가능하고 업그레이드 가능하지만 (이는 장기적인 상호운용성에 좋음), 각 애플리케이션이 이러한 업그레이드를 책임감 있게 관리해야 하는 부담이 있습니다. 레이어제로의 기본 컨트랙트는 전송 레이어가 러그풀되거나 검열될 수 없도록 불변으로 만들어져, 메시징 파이프라인 자체가 업그레이드를 통해 그대로 유지된다는 신뢰를 줍니다.

비교를 요약하면, 아래 표는 주요 차이점을 강조합니다.

DeFi의 구성성과 공유 유동성에 미치는 영향​

크로스체인 메시징은 서로 다른 체인의 DeFi 컨트랙트가 상호 작용할 수 있는 능력인 구성성을 위한 강력한 새로운 패턴을 열어주고, 여러 체인에 걸쳐 자산을 마치 하나의 시장처럼 풀링하는 공유 유동성을 가능하게 합니다. 위에서 논의된 보안 모델은 프로토콜이 얼마나 자신감 있고 원활하게 크로스체인 기능을 활용할 수 있는지에 영향을 미칩니다. 아래에서는 각 접근 방식이 실제 사례와 함께 멀티체인 DeFi를 어떻게 지원하는지 탐구합니다.

• 레이어제로를 통한 옴니체인 DeFi (Stargate, Radiant, Tapioca): 레이어제로의 일반 메시징과 옴니체인 대체 가능 토큰 (OFT) 표준은 유동성 사일로를 깨기 위해 설계되었습니다. 예를 들어, Stargate Finance는 레이어제로를 사용하여 네이티브 자산 브리징을 위한 통합 유동성 풀을 구현합니다. 각 체인에 분산된 풀 대신, 모든 체인의 Stargate 컨트랙트는 공통 풀을 활용하고, 레이어제로 메시지는 체인 간의 락/릴리스 로직을 처리합니다. 이로 인해 Stargate의 브리지는 월간 8억 달러 이상의 거래량을 기록하며 상당한 공유 유동성을 보여주었습니다. 레이어제로의 보안 (Stargate는 견고한 DVN 집합을 사용하는 것으로 추정됨)에 의존함으로써, 사용자는 메시지 진위성에 대한 높은 신뢰를 가지고 자산을 전송할 수 있습니다. Radiant Capital은 또 다른 예입니다. 사용자가 한 체인에 예치하고 다른 체인에서 대출할 수 있는 크로스체인 대출 프로토콜입니다. 이는 레이어제로 메시지를 활용하여 체인 간 계정 상태를 조정하고, 사실상 여러 네트워크에 걸쳐 하나의 대출 시장을 만듭니다. 유사하게, Tapioca (옴니체인 머니 마켓)는 레이어제로 v2를 사용하며, 메시지를 보호하기 위해 자체 DVN을 필수 검증인으로 운영하기도 합니다. 이러한 예는 유연한 보안을 통해 레이어제로가 신용 확인, 담보 이동, 청산과 같은 복잡한 크로스체인 작업을 지원할 수 있음을 보여줍니다. 구성성은 레이어제로의 "OApp" 표준 (옴니체인 애플리케이션)에서 비롯되며, 개발자들이 여러 체인에 동일한 컨트랙트를 배포하고 메시징을 통해 조정할 수 있게 합니다. 사용자는 어떤 체인의 인스턴스와 상호 작용하든 애플리케이션을 하나의 통합된 시스템으로 경험합니다. 보안 모델은 미세 조정이 가능합니다. 예를 들어, 대규모 전송이나 청산은 (안전을 위해) 더 많은 DVN 서명을 요구할 수 있고, 소규모 작업은 더 빠르고 저렴한 경로를 통과할 수 있습니다. 이러한 유연성은 보안이나 UX가 모두에게 동일할 필요가 없도록 보장합니다. 실제로, 레이어제로의 모델은 공유 유동성을 크게 향상시켰으며, 수십 개의 프로젝트가 토큰에 OFT를 채택하여 (토큰이 별도의 래핑된 자산이 아닌 "옴니체인"으로 존재할 수 있도록) 이를 증명합니다. 예를 들어, 스테이블코인과 거버넌스 토큰은 OFT를 사용하여 모든 체인에 걸쳐 단일 총 공급량을 유지할 수 있으며, 이는 이전의 래핑된 토큰이 겪었던 유동성 파편화 및 차익 거래 문제를 피할 수 있습니다. 전반적으로, 신뢰할 수 있는 메시징 레이어를 제공하고 앱이 신뢰 모델을 제어할 수 있게 함으로써, 레이어제로는 여러 체인을 하나의 생태계로 취급하는 새로운 멀티체인 DeFi 설계를 촉진했습니다. 절충점은 사용자와 프로젝트가 각 옴니체인 앱의 신뢰 가정을 이해해야 한다는 것입니다 (서로 다를 수 있으므로). 그러나 OFT와 같은 표준과 널리 사용되는 기본 DVN은 이를 더 균일하게 만드는 데 도움이 됩니다.

• IBC의 인터체인 계정 및 서비스 (코스모스 DeFi): 코스모스 세계에서 IBC는 토큰 전송을 넘어선 풍부한 크로스체인 기능의 태피스트리를 가능하게 했습니다. 대표적인 기능은 **인터체인 계정 (ICA)**으로, 블록체인 (또는 체인 A의 사용자)이 체인 B의 계정을 마치 로컬 계정처럼 제어할 수 있게 합니다. 이는 트랜잭션을 담은 IBC 패킷을 통해 이루어집니다. 예를 들어, 코스모스 허브는 오스모시스의 인터체인 계정을 사용하여 사용자를 대신해 토큰을 스테이킹하거나 스왑할 수 있으며, 이 모든 것이 허브에서 시작됩니다. 구체적인 DeFi 사용 사례는 Stride의 유동성 스테이킹 프로토콜입니다. Stride (체인)는 사용자로부터 ATOM과 같은 토큰을 받고, ICA를 사용하여 코스모스 허브에 원격으로 해당 ATOM을 스테이킹한 다음, 사용자에게 stATOM (유동성 스테이킹된 ATOM)을 발행합니다. 전체 흐름은 IBC를 통해 신뢰 없이 자동화됩니다. Stride의 모듈은 허브의 계정을 제어하여 위임 및 위임 해제 트랜잭션을 실행하며, 확인 및 타임아웃으로 안전을 보장합니다. 이는 크로스체인 구성성을 보여줍니다. 두 주권 체인이 원활하게 공동 워크플로우 (여기서 스테이킹하고, 저기서 토큰 발행)를 수행합니다. 또 다른 예는 오스모시스 (DEX 체인)로, 95개 이상의 연결된 체인에서 자산을 끌어오기 위해 IBC를 사용합니다. 모든 존의 사용자는 IBC를 통해 토큰을 보내 오스모시스에서 스왑할 수 있습니다. IBC의 높은 보안 덕분에, 오스모시스와 다른 체인들은 IBC 토큰을 신뢰할 수 있는 관리인 없이도 진품으로 자신 있게 취급합니다. 이로 인해 오스모시스는 가장 큰 인터체인 DEX 중 하나가 되었으며, 일일 IBC 전송량은 많은 브리지 시스템을 초과하는 것으로 보고됩니다. 또한, IBC 3.0의 **인터체인 쿼리 (ICQ)**를 통해 한 체인의 스마트 컨트랙트는 다른 체인에서 데이터 (가격, 이자율, 포지션 등)를 신뢰 최소화 방식으로 가져올 수 있습니다. 이는 예를 들어, 여러 존의 수익률을 쿼리하고 그에 따라 자산을 재할당하는 인터체인 수익률 애그리게이터를 가능하게 할 수 있으며, 이 모든 것이 IBC 메시지를 통해 이루어집니다. IBC의 라이트 클라이언트 모델이 구성성에 미치는 주요 영향은 신뢰와 중립성입니다. 체인은 주권을 유지하면서도 제3자 브리지 위험에 대한 두려움 없이 상호 작용할 수 있습니다. Composable Finance와 Polymer와 같은 프로젝트는 이러한 기능을 활용하기 위해 IBC를 비-코스모스 생태계 (폴카닷, 이더리움)로 확장하고 있습니다. 그 결과, IBC 클라이언트 표준을 채택하는 모든 체인이 "블록체인의 보편적 인터넷"에 연결될 수 있는 미래가 올 수 있습니다. 코스모스의 공유 유동성은 이미 상당합니다. 예를 들어, 코스모스 허브의 네이티브 DEX (Gravity DEX)와 다른 DEX들은 다양한 존에서 유동성을 풀링하기 위해 IBC에 의존합니다. 그러나 지금까지의 한계는 코스모스 DeFi가 대부분 비동기적이라는 것입니다. 한 체인에서 시작하면 다른 체인에서 약간의 지연 (초 단위) 후에 결과가 발생합니다. 이는 거래나 스테이킹과 같은 작업에는 괜찮지만, 체인 간 플래시 론과 같은 더 복잡한 동기적 구성성은 근본적인 지연 시간 때문에 아직 범위 밖입니다. 그럼에도 불구하고, IBC가 가능하게 한 크로스체인 DeFi의 스펙트럼은 넓습니다: 멀티체인 수익률 파밍 (수익률이 가장 높은 곳으로 자금 이동), 크로스체인 거버넌스 (한 체인이 거버넌스 패킷을 통해 다른 체인에서 작업을 실행하도록 투표), 그리고 소비자 체인이 제공자 체인의 검증인 집합을 활용하는 인터체인 보안 (IBC 검증 패킷을 통해)까지 가능합니다. 요약하면, IBC의 안전한 채널은 코스모스에서 인터체인 경제를 육성했습니다. 프로젝트들이 별도의 체인에서 전문화되면서도 신뢰 최소화 메시지를 통해 유동적으로 협력할 수 있는 경제입니다. 공유 유동성은 오스모시스로의 자산 흐름과 존 간에 자유롭게 이동하는 코스모스 네이티브 스테이블코인의 부상 등에서 분명하게 나타납니다.

• 하이브리드 및 기타 멀티체인 접근 방식 (하이퍼레인 및 그 이상): 하이퍼레인의 무허가 연결 비전은 자산 브리징을 위한 **워프 루트 (Warp Routes)**와 다양한 생태계에 걸친 인터체인 dApp과 같은 개념으로 이어졌습니다. 예를 들어, 워프 루트는 이더리움의 ERC-20 토큰을 하이퍼레인의 메시지 레이어를 사용하여 솔라나 프로그램으로 텔레포트할 수 있게 합니다. 구체적인 사용자 대면 구현 중 하나는 하이퍼레인의 넥서스 브리지로, 하이퍼레인 인프라를 통해 여러 체인 간에 자산을 전송하는 UI를 제공합니다. 모듈식 보안 모델을 사용하여 하이퍼레인은 경로별로 보안을 맞춤화할 수 있습니다. 소액 전송은 간단하고 빠른 경로 (하이퍼레인 검증인 서명만)를 통과할 수 있고, 대규모 전송은 집계 ISM (하이퍼레인 + 웜홀 + 액셀러 모두 증명)을 요구할 수 있습니다. 이는 고가치 유동성 이동이 여러 브리지에 의해 보호되도록 보장하여, 예를 들어 1,000만 달러의 자산을 크로스체인으로 이동할 때 신뢰를 높입니다 (이를 훔치려면 여러 네트워크를 손상시켜야 함). 이는 더 높은 복잡성/수수료를 대가로 합니다. 구성성 측면에서, 하이퍼레인은 **"컨트랙트 상호운용성"**이라고 부르는 것을 가능하게 합니다. 체인 A의 스마트 컨트랙트는 메시지가 전달되면 마치 로컬인 것처럼 체인 B의 함수를 호출할 수 있습니다. 개발자들은 하이퍼레인 SDK를 통합하여 이러한 크로스체인 호출을 쉽게 디스패치합니다. 예를 들어, 이더리움과 BNB 체인에 일부가 존재하는 크로스체인 DEX 애그리게이터가 하이퍼레인 메시지를 사용하여 둘 사이에서 차익 거래를 할 수 있습니다. 하이퍼레인은 EVM 및 비-EVM 체인 (코즘와즘 및 무브VM 통합에 대한 초기 작업 포함)을 지원하기 때문에 **"모든 체인, 모든 VM"**을 연결하고자 합니다. 이 넓은 범위는 다른 방법으로는 쉽게 연결되지 않는 생태계를 브리징함으로써 공유 유동성을 증가시킬 수 있습니다. 그러나 대규모 DeFi에서 하이퍼레인의 실제 채택은 아직 성장 중입니다. 브리징에서 웜홀이나 레이어제로의 거래량을 아직 따라잡지 못했지만, 무허가 특성으로 인해 실험을 유치했습니다. 예를 들어, 일부 프로젝트는 복잡한 라이트 클라이언트 솔루션을 기다리지 않고 자체 검증인 집합을 설정할 수 있었기 때문에 앱별 롤업을 이더리움에 신속하게 연결하기 위해 하이퍼레인을 사용했습니다. 리스테이킹 (아이겐레이어)이 성장함에 따라, 하이퍼레인은 상대적으로 낮은 지연 시간으로 모든 롤업에 이더리움급 보안을 제공함으로써 더 많은 채택을 볼 수 있습니다. 이는 새로운 멀티체인 구성을 가속화할 수 있습니다. 예를 들어, 옵티미즘 롤업과 폴리곤 zk-롤업이 하이퍼레인 AVS를 통해 메시지를 교환하고, 각 메시지는 사기일 경우 슬래싱될 ETH로 뒷받침됩니다. 구성성에 미치는 영향은 공유 표준이 없는 생태계 (이더리움과 임의의 L2 등)조차도 양측이 신뢰하는 브리지 컨트랙트를 가질 수 있다는 것입니다 (경제적으로 보호되기 때문). 시간이 지남에 따라 이는 **개발자가 "구성성을 조절"**할 수 있는 상호 연결된 DeFi 앱의 웹을 낳을 수 있습니다 (어떤 호출에 어떤 보안 모듈을 사용할지 선택).

이 모든 경우에서 보안 모델과 구성성 간의 상호 작용은 분명합니다. 프로젝트는 보안이 견고할 때만 대규모 유동성 풀을 크로스체인 시스템에 맡길 것입니다. 따라서 신뢰 최소화 또는 경제적으로 보호되는 설계에 대한 추진이 있습니다. 동시에, 통합의 용이성 (개발자 경험)과 유연성은 팀이 여러 체인을 활용하는 데 얼마나 창의적일 수 있는지에 영향을 미칩니다. 레이어제로와 하이퍼레인은 개발자를 위한 단순성 (SDK를 가져오고 익숙한 송수신 호출 사용)에 중점을 두는 반면, 더 낮은 수준인 IBC는 모듈에 대한 더 많은 이해를 요구하며 애플리케이션 개발자보다는 체인 개발자가 처리할 수 있습니다. 그럼에도 불구하고, 세 가지 모두 사용자가 자신이 어떤 체인에 있는지 알 필요 없이 멀티체인 dApp과 상호 작용하는 미래를 향해 나아가고 있습니다. 앱은 어디에서나 유동성과 기능을 원활하게 활용합니다. 예를 들어, 대출 앱 사용자는 체인 A에 예치하고 대출이 체인 B의 풀에서 발생했다는 사실조차 깨닫지 못할 수 있습니다. 이 모든 것이 크로스체인 메시지와 적절한 검증으로 처리됩니다.

실제 구현, 위협 모델 및 채택 현황​

이러한 프로토콜이 실제 환경에서 어떻게 작동하고 있는지, 즉 현재 구현 현황, 알려진 위협 벡터 및 채택 수준을 평가하는 것이 중요합니다.

• 실제 운영 중인 레이어제로 v2: 레이어제로 v1 (2개 주체 오라클+릴레이어 모델)은 상당한 채택을 얻었으며, 2024년 중반까지 500억 달러 이상의 전송량을 확보하고 1억 3,400만 건 이상의 크로스체인 메시지를 처리했습니다. 60개 이상의 블록체인과 통합되었으며, 주로 EVM 체인이지만 앱토스와 같은 비-EVM 체인도 포함되며, 솔라나에 대한 실험적 지원도 예정되어 있습니다. 레이어제로 v2는 2024년 초에 출시되어 DVN과 모듈식 보안을 도입했습니다. 이미 Radiant Capital, SushiXSwap, Stargate, PancakeSwap 등 주요 플랫폼들이 유연성을 활용하기 위해 v2로 마이그레이션하거나 구축하기 시작했습니다. 주목할 만한 통합 중 하나는 플레어 네트워크 (데이터에 중점을 둔 레이어1)로, 한 번에 75개 체인과 연결하기 위해 레이어제로 v2를 채택했습니다. 플레어는 보안을 맞춤화할 수 있는 능력에 매력을 느꼈습니다. 예를 들어, 저가치 메시지에는 단일의 빠른 DVN을 사용하고 고가치 메시지에는 여러 DVN을 요구하는 것입니다. 이는 실제 운영에서 애플리케이션이 실제로 "혼합 및 매치" 보안 접근 방식을 판매 포인트로 사용하고 있음을 보여줍니다. 보안 및 감사: 레이어제로의 컨트랙트는 불변이며 감사되었습니다 (v1은 여러 번, v2도 마찬가지). v1의 주요 위협은 오라클-릴레이어 공모였습니다. 두 오프체인 당사자가 공모하면 메시지를 위조할 수 있었습니다. v2에서는 이 위협이 DVN 공모로 일반화됩니다. 앱이 의존하는 모든 DVN이 한 주체에 의해 손상되면 가짜 메시지가 통과될 수 있습니다. 레이어제로의 해답은 앱별 DVN을 장려하고 (공격자가 앱 팀도 손상시켜야 함) 검증인의 다양성을 확보하는 것입니다 (공모를 더 어렵게 만듦). 또 다른 잠재적 문제는 잘못된 구성 또는 업그레이드 오용입니다. 앱 소유자가 악의적으로 사소한 보안 스택 (자신이 제어하는 1-of-1 DVN 등)으로 전환하면, 보안을 우회하여 자신의 사용자를 착취할 수 있습니다. 이는 프로토콜 버그라기보다는 거버넌스 위험이며, 커뮤니티는 옴니체인 앱의 보안이 어떻게 설정되는지에 대해 경계를 늦추지 않아야 합니다 (변경에 대해 멀티시그나 커뮤니티 승인을 요구하는 것이 바람직함). 채택 측면에서, 레이어제로는 현재 DeFi의 메시징 프로토콜 중 가장 많은 사용량을 자랑합니다. Stargate, 서클의 CCTP 통합 (USDC 전송용), 스시의 크로스체인 스왑, 많은 NFT 브리지, 그리고 수많은 OFT 토큰 (프로젝트들이 토큰을 여러 체인에서 사용할 수 있도록 레이어제로를 선택)의 브리징을 지원합니다. 네트워크 효과는 강력합니다. 더 많은 체인이 레이어제로 엔드포인트를 통합할수록 새로운 체인이 "옴니체인" 네트워크에 참여하기가 더 쉬워집니다. 레이어제로 랩스 자체는 하나의 DVN을 운영하고, 커뮤니티 (구글 클라우드, 영지식 증명을 위한 폴리헤드라 등 제공업체 포함)는 2024년까지 15개 이상의 DVN을 출시했습니다. 현재까지 레이어제로의 핵심 프로토콜에 대한 주요 익스플로잇은 발생하지 않았으며, 이는 긍정적인 신호입니다 (일부 애플리케이션 수준의 해킹이나 사용자 오류는 다른 기술과 마찬가지로 발생했습니다). 전송 레이어를 단순하게 유지하는 (본질적으로 메시지를 저장하고 증명을 요구하는) 프로토콜의 설계는 온체인 취약점을 최소화하고 대부분의 복잡성을 DVN으로 오프체인으로 이전합니다.

• 실제 운영 중인 하이퍼레인: 하이퍼레인 (이전 Abacus)은 이더리움, 여러 L2 (옵티미즘, 아비트럼, zkSync 등), 코스모스-SDK 모듈을 통한 오스모시스와 같은 코스모스 체인, 심지어 무브VM 체인 등 수많은 체인에서 운영 중입니다 (지원 범위가 상당히 넓음). 그러나 채택률은 거래량 측면에서 레이어제로와 웜홀과 같은 기존 업체에 뒤처져 있습니다. 하이퍼레인은 종종 "주권 브리지" 솔루션의 맥락에서 언급됩니다. 즉, 프로젝트가 하이퍼레인을 배포하여 맞춤형 보안을 갖춘 자체 브리지를 가질 수 있습니다. 예를 들어, 일부 앱체인 팀은 공유 브리지에 의존하지 않고 자신의 체인을 이더리움에 연결하기 위해 하이퍼레인을 사용했습니다. 주목할 만한 발전은 2024년 중반에 출시된 **하이퍼레인 액티브 검증 서비스 (AVS)**로, 이더리움 리스테이킹의 첫 번째 애플리케이션 중 하나입니다. 검증인 (많은 상위 아이겐레이어 운영자 포함)이 ETH를 리스테이킹하여 하이퍼레인 메시지를 보호하며, 처음에는 빠른 크로스-롤업 메시징에 중점을 둡니다. 이는 현재 이더리움 L2 롤업 간의 상호운용성을 좋은 결과로 확보하고 있습니다. 본질적으로 옵티미스틱 롤업의 7일 출금 대기 시간보다 빠른 거의 즉각적인 메시지 전달을 이더리움에 연결된 경제적 보안으로 제공합니다. 위협 모델 측면에서, 하이퍼레인의 원래 멀티시그 접근 방식은 충분한 수의 검증인 키가 손상되면 공격받을 수 있습니다 (다른 멀티시그 브리지와 마찬가지로). 하이퍼레인은 과거 보안 사고가 있었습니다. 2022년 8월, 초기 테스트넷 또는 출시 중에 공격자가 한 체인의 하이퍼레인 토큰 브리지 배포자 키를 탈취하여 토큰을 발행한 익스플로잇이 있었습니다 (약 70만 달러 손실). 이는 멀티시그 자체의 실패가 아니라 배포 관련 운영 보안의 문제였습니다. 이는 업그레이드 가능성과 키 관리의 위험을 강조했습니다. 팀은 손실을 보상하고 프로세스를 개선했습니다. 이는 거버넌스 키가 위협 모델의 일부임을 강조합니다. 관리자 제어를 확보하는 것이 검증인만큼 중요합니다. AVS를 사용하면 위협 모델이 아이겐레이어 컨텍스트로 이동합니다. 누군가 잘못된 슬래싱을 유발하거나 잘못된 행동에도 불구하고 슬래싱을 피할 수 있다면 문제가 될 것입니다. 그러나 아이겐레이어의 프로토콜은 이더리움에서 슬래싱 로직을 처리하며, 이는 올바른 사기 증명 제출을 가정할 때 견고합니다. 하이퍼레인의 현재 채택은 롤업 공간과 일부 앱별 체인에서 증가하고 있습니다. 아직 일부 경쟁사의 수십억 달러 흐름을 처리하지는 못하지만, 개발자가 완전한 제어와 쉬운 확장성을 원하는 틈새 시장을 개척하고 있습니다. 모듈식 ISM 설계는 창의적인 보안 설정을 볼 수 있음을 의미합니다. 예를 들어, DAO는 하이퍼레인 서명뿐만 아니라 시간 잠금이나 두 번째 브리지 서명을 모든 관리자 메시지에 요구할 수 있습니다. 하이퍼레인의 무허가 정신 (누구나 검증인을 운영하거나 새 체인에 배포할 수 있음)은 장기적으로 강력할 수 있지만, 생태계가 성숙해야 함을 의미하기도 합니다 (예: 기본 집합을 탈중앙화하기 위해 더 많은 제3자 검증인 참여. 2025년 현재 활성 검증인 집합이 실제로 얼마나 탈중앙화되어 있는지는 불분명함). 전반적으로, 하이퍼레인의 궤적은 보안 (리스테이킹으로)과 사용 편의성을 개선하는 것이지만, IBC나 레이어제로와 같은 수준의 커뮤니티 신뢰를 얻으려면 회복력을 입증하고 주요 유동성을 유치해야 합니다.

• 실제 운영 중인 IBC 3.0 및 코스모스 상호운용성: IBC는 2021년부터 운영되어 왔으며 코스모스 내에서 매우 전투적으로 테스트되었습니다. 2025년까지 115개 이상의 존 (코스모스 허브, 오스모시스, 주노, 크로노스, 액셀러, 쿠지라 등 포함)을 연결하고 월 수백만 건의 트랜잭션과 수십억 달러의 토큰 흐름을 처리합니다. 인상적이게도 프로토콜 수준에서 주요 보안 실패가 없었습니다. 한 가지 주목할 만한 IBC 관련 사고가 있었습니다. 2022년 10월, IBC 코드 (모든 v2.0 구현에 영향을 미침)에서 많은 IBC 연결 체인에서 가치를 빼낼 수 있는 치명적인 취약점이 발견되었습니다. 그러나 공개적으로 알려지기 전에 조정된 업그레이드를 통해 비밀리에 수정되었고, 익스플로잇은 발생하지 않았습니다. 이는 공식적으로 검증된 프로토콜도 버그가 있을 수 있다는 경각심을 불러일으켰습니다. 그 이후로 IBC는 추가적인 감사와 강화를 거쳤습니다. IBC의 위협 모델은 주로 체인 보안에 관한 것입니다. 연결된 한 체인이 적대적이거나 51% 공격을 받으면 상대방의 라이트 클라이언트에 유효하지 않은 데이터를 제공하려고 시도할 수 있습니다. 완화 조치에는 불안정한 체인과의 연결을 중단하거나 닫기 위해 거버넌스를 사용하는 것이 포함됩니다 (예를 들어, 코스모스 허브 거버넌스는 특정 체인이 고장난 것으로 감지되면 해당 체인의 클라이언트 업데이트를 끄도록 투표할 수 있음). 또한, IBC 클라이언트는 종종 언본딩 기간이나 신뢰 기간을 정렬합니다. 예를 들어, 텐더민트 라이트 클라이언트는 언본딩 기간보다 오래된 검증인 집합 업데이트를 수락하지 않습니다 (장거리 공격 방지). 또 다른 가능한 문제는 릴레이어 검열입니다. 릴레이어가 패킷을 전달하지 않으면 자금이 타임아웃에 갇힐 수 있습니다. 그러나 릴레이는 무허가이며 종종 인센티브가 주어지므로 이는 일반적으로 일시적입니다. IBC 3.0의 인터체인 쿼리 및 새로운 기능이 출시되면서, 크로스체인 DEX 애그리게이터 (예: 스킵 프로토콜이 ICQ를 사용하여 체인 간 가격 데이터 수집) 및 크로스체인 거버넌스 (예: 코스모스 허브가 인터체인 계정을 사용하여 소비자 체인인 뉴트론 관리)와 같은 분야에서 채택이 이루어지고 있습니다. 코스모스 외부로의 채택도 이야기거리입니다. 폴리머와 아스트리아 (롤업을 위한 상호운용성 허브)와 같은 프로젝트는 허브/스포크 모델을 통해 IBC를 이더리움 롤업으로 효과적으로 가져오고 있으며, 폴카닷의 파라체인은 IBC를 사용하여 코스모스 체인과 성공적으로 연결했습니다 (예: 코스모스와 폴카닷 간의 센타우리 브리지, 컴포저블 파이낸스가 구축, 코스모스 측에 GRANDPA 라이트 클라이언트를 사용하여 내부적으로 IBC 사용). 폴리머와 데이터체인이 진행 중인 IBC-솔리디티 구현도 있어, 이더리움 스마트 컨트랙트가 IBC 패킷을 검증할 수 있게 될 것입니다 (라이트 클라이언트 또는 유효성 증명 사용). 이러한 노력이 성공하면, 코스모스를 넘어 IBC의 사용이 극적으로 확대되어, 신뢰 최소화 모델이 해당 체인의 더 중앙화된 브리지와 직접 경쟁하게 될 수 있습니다. 공유 유동성 측면에서, 코스모스의 가장 큰 한계는 이더리움과 동등한 네이티브 스테이블코인이나 깊은 유동성 DEX의 부재였습니다. 이는 코스모스 네이티브 스테이블코인 (IST, CMST 등)의 부상과 USDC와 같은 자산의 연결 (액셀러와 그래비티 브리지가 USDC를 가져왔고, 이제 서클이 노블을 통해 코스모스에 네이티브 USDC를 출시)로 변화하고 있습니다. 유동성이 깊어짐에 따라, 높은 보안과 원활한 IBC 전송의 조합은 코스모스를 멀티체인 DeFi 거래의 중심지로 만들 수 있습니다. 실제로, 블록체인 캐피탈 보고서는 IBC가 2024년 초까지 이미 레이어제로 또는 웜홀보다 더 많은 거래량을 처리하고 있었다고 언급했습니다. 비록 이것이 주로 코스모스-코스모스 트래픽의 강점에 기인하지만 (이는 매우 활발한 인터체인 경제를 시사함). 앞으로 IBC의 주요 과제와 기회는 보안 정신을 희생하지 않고 이종 체인으로 확장하는 것입니다.

요약하면, 각 프로토콜은 발전하고 있습니다: 레이어제로는 많은 체인 및 애플리케이션과 신속하게 통합하고, 유연성과 개발자 채택을 우선시하며, 앱이 자체 보안의 일부가 되도록 하여 위험을 완화하고 있습니다. 하이퍼레인은 리스테이킹과 모듈성으로 혁신하고 있으며, 구성 가능한 보안으로 새로운 체인을 연결하는 가장 쉬운 방법이 되는 것을 목표로 하지만, 여전히 신뢰와 사용량을 구축하고 있습니다. IBC는 해당 영역 내에서 신뢰성의 황금 표준이며, 이제 더 빨라지고 (IBC 3.0) 코스모스를 넘어 영역을 확장하기를 희망하며, 강력한 실적을 바탕으로 하고 있습니다. 사용자와 프로젝트는 각 프로토콜의 성숙도와 보안 사고를 고려하는 것이 현명합니다. IBC는 수년간의 안정적인 운영 (그리고 막대한 거래량)을 가지고 있지만 특정 생태계에 제한되어 있습니다. 레이어제로는 빠르게 사용량을 축적했지만 맞춤형 보안 설정을 이해해야 합니다. 하이퍼레인은 실행 면에서는 더 새롭지만 비전은 유망하며, 경제적 보안을 향한 신중한 단계를 밟고 있습니다.

결론 및 전망: 멀티체인 미래를 위한 상호운용성 아키텍처​

멀티체인 DeFi 환경의 장기적인 생존 가능성과 상호운용성은 세 가지 보안 모델이 모두 공존하고 심지어 서로를 보완하면서 형성될 가능성이 높습니다. 각 접근 방식은 명확한 강점을 가지고 있으며, 만능 해결책보다는 **라이트 클라이언트 모델 (IBC)**이 주요 경로 (특히 주요 체인 간)에 대한 최고 수준의 보증 기반을 제공하고, **증명 집계 시스템 (레이어제로)**이 맞춤형 신뢰로 보편적인 연결성을 제공하며, **멀티시그 모델 (하이퍼레인 및 기타)**이 틈새 수요를 충족하거나 새로운 생태계를 신속하게 부트스트랩하는 스택을 보게 될 것입니다.

보안 대 연결성 절충: IBC와 같은 라이트 클라이언트는 "블록체인 인터넷"에 가장 가까운 것을 제공합니다. TCP/IP와 유사한 중립적이고 표준화된 전송 레이어입니다. 이는 상호운용성이 새로운 약점을 도입하지 않도록 보장하며, 이는 장기적인 지속 가능성에 중요합니다. 그러나 표준에 대한 광범위한 합의와 체인당 상당한 엔지니어링이 필요하므로 새로운 연결이 형성되는 속도가 느려집니다. 반면에 레이어제로와 하이퍼레인은 즉각적인 연결성과 유연성을 우선시하며, 모든 체인이 동일한 프로토콜을 구현하지 않을 것임을 인정합니다. 그들은 중간에 약간의 신뢰를 더 수용하더라도 "모든 것을 모든 것과" 연결하는 것을 목표로 합니다. 시간이 지남에 따라 격차가 좁혀질 것으로 예상됩니다. 레이어제로는 더 많은 신뢰 최소화 DVN을 통합할 수 있고 (IBC 자체도 DVN으로 래핑될 수 있음), 하이퍼레인은 경제적 메커니즘을 사용하여 네이티브 검증의 보안에 접근할 수 있습니다. 실제로, 폴리머 프로젝트는 IBC와 레이어제로가 경쟁자가 아니라 계층화될 수 있다고 구상합니다. 예를 들어, 레이어제로는 가능한 경우 IBC 라이트 클라이언트를 DVN 중 하나로 사용할 수 있습니다. 이러한 교차 수분은 공간이 성숙함에 따라 가능성이 높습니다.

구성성과 통합 유동성: DeFi 사용자 관점에서 궁극적인 목표는 유동성이 체인에 구애받지 않게 되는 것입니다. 우리는 이미 그 단계를 보고 있습니다. 옴니체인 토큰 (OFT)을 사용하면 토큰 버전이 어느 체인에 있는지 걱정할 필요가 없으며, 크로스체인 머니 마켓을 사용하면 다른 체인의 담보를 상대로 모든 체인에서 대출할 수 있습니다. 아키텍처 선택은 이러한 시스템에 대한 사용자 신뢰에 직접적인 영향을 미칩니다. 브리지 해킹이 발생하면 (과거 일부 멀티시그 브리지에서 발생했듯이), 신뢰와 유동성이 깨집니다. 사용자는 더 안전한 장소로 후퇴하거나 위험 프리미엄을 요구합니다. 따라서 지속적으로 보안을 입증하는 프로토콜이 가장 큰 유동성 풀을 뒷받침할 것입니다. 코스모스의 인터체인 보안과 IBC는 한 가지 길을 보여주었습니다. 여러 존에 걸친 여러 오더북과 AMM은 전송이 신뢰 없고 빠르기 때문에 본질적으로 하나의 큰 시장으로 구성됩니다. 레이어제로의 Stargate는 또 다른 길을 보여주었습니다. 통합 유동성 풀이 많은 체인의 전송을 서비스할 수 있지만, 사용자는 레이어제로의 보안 가정 (오라클+릴레이어 또는 DVN)을 신뢰해야 했습니다. 레이어제로 v2가 각 풀이 더 높은 보안을 설정할 수 있게 함에 따라 (예: 모든 전송을 검증하기 위해 여러 유명 검증인 네트워크 사용), 신뢰 격차를 줄이고 있습니다. 멀티체인 DeFi의 장기적인 생존 가능성은 상호운용성 프로토콜이 보이지 않지만 신뢰할 수 있게 되는 것에 달려 있을 가능성이 높습니다. 인터넷 사용자가 TCP/IP에 대해 생각하지 않는 것처럼, 암호화폐 사용자는 dApp이 어떤 브리지나 메시징 시스템을 사용하는지 걱정할 필요가 없어야 합니다. 이는 보안 모델이 실패가 극히 드물 정도로 견고하고, 이러한 상호운용성 네트워크 간에 어느 정도의 수렴이나 구성성이 있을 때 일어날 것입니다.

상호운용성의 상호운용성: 몇 년 후에는 레이어제로 대 하이퍼레인 대 IBC를 별개의 영역으로 이야기하는 대신, 계층화된 시스템으로 이야기하게 될 것이라고 상상할 수 있습니다. 예를 들어, 이더리움 롤업은 폴리머를 통해 코스모스 허브와 IBC 연결을 가질 수 있고, 그 코스모스 허브는 레이어제로 엔드포인트도 가질 수 있어, 메시지가 안전한 IBC 채널을 통해 롤업에서 레이어제로의 네트워크로 전송될 수 있습니다. 하이퍼레인은 심지어 대체 또는 집계 역할을 할 수도 있습니다. 앱은 궁극적인 보증을 위해 IBC 증명과 하이퍼레인 AVS 서명을 모두 요구할 수 있습니다. 이러한 프로토콜 간 보안 집계는 가장 진보된 위협 모델조차도 해결할 수 있습니다 (IBC 라이트 클라이언트 와 독립적인 리스테이킹된 멀티시그를 동시에 전복시키는 것은 훨씬 더 어렵습니다). 물론 이러한 조합은 복잡성과 비용을 추가하므로, 고가치 컨텍스트에 예약될 것입니다.

거버넌스와 탈중앙화: 각 모델은 다른 행위자에게 다른 권한을 부여합니다. IBC는 체인 거버넌스의 손에, 레이어제로는 앱 개발자 (그리고 간접적으로 그들이 선택한 DVN 운영자)의 손에, 하이퍼레인은 브리지 검증인과 잠재적으로 리스테이커의 손에 있습니다. 장기적인 상호운용성 환경은 단일 당사자나 카르텔이 크로스체인 거래를 지배할 수 없도록 보장해야 합니다. 이는 예를 들어, 한 프로토콜이 보편화되었지만 소수의 행위자에 의해 제어되는 경우 위험입니다. 병목 현상이 될 수 있습니다 (중앙화된 인터넷 서비스 제공업체와 유사). 이를 완화하는 방법은 메시징 네트워크 자체를 탈중앙화하고 (더 많은 릴레이어, 더 많은 DVN, 더 많은 검증인 – 모두 무허가 참여) 대체 경로를 갖는 것입니다. 이 점에서 IBC는 많은 독립적인 팀이 있는 개방형 표준이라는 이점이 있으며, 레이어제로와 하이퍼레인은 모두 제3자 참여를 늘리기 위해 움직이고 있습니다 (예: 누구나 레이어제로 DVN 또는 하이퍼레인 검증인을 운영할 수 있음). 경쟁과 개방형 참여가 이러한 서비스를 정직하게 유지할 가능성이 높습니다. L1의 채굴자/검증인이 기본 레이어를 탈중앙화 상태로 유지하는 것과 같습니다. 시장은 또한 발로 투표할 것입니다. 한 솔루션이 불안정하거나 너무 중앙화된 것으로 판명되면, 개발자는 다른 솔루션으로 마이그레이션할 수 있습니다 (특히 브리징 표준이 더 상호운용 가능해짐에 따라).

결론적으로, 레이어제로 v2, 하이퍼레인, IBC 3.0의 보안 아키텍처는 각각 다른 철학으로 멀티체인 DeFi 비전을 현실로 만드는 데 기여합니다. 라이트 클라이언트는 신뢰성과 중립성을 우선시하고, 멀티시그는 실용주의와 통합 용이성을 우선시하며, 집계 접근 방식은 맞춤화와 적응성을 우선시합니다. 미래의 멀티체인 DeFi 환경은 이러한 조합을 사용할 가능성이 높습니다. 중요한 인프라와 고가치 전송은 신뢰 최소화 또는 경제적으로 보호되는 방법으로 보호되고, 유연한 미들웨어는 새로운 체인과 앱의 롱테일에 연결됩니다. 이것들이 제자리에 있으면, 사용자는 단일 체인을 사용하는 것과 같은 자신감과 용이함으로 통합된 유동성과 크로스체인 구성성을 즐길 수 있을 것입니다. 앞으로의 길은 수렴의 길입니다. 반드시 프로토콜 자체의 수렴이 아니라, 결과의 수렴입니다. 상호운용성이 안전하고, 원활하며, 표준이 되는 세상입니다. 이를 달성하려면 지속적인 엄격한 엔지니어링 (익스플로잇 방지), 협력적 거버넌스 (IBC 또는 보편적인 컨트랙트 인터페이스와 같은 표준 설정), 그리고 아마도 가장 중요하게는 모든 세계의 최고를 혼합하는 보안에 대한 반복적인 접근 방식이 필요할 것입니다. 수학, 경제적 인센티브, 지능적인 설계. 최종 상태는 종종 인용되는 비유를 진정으로 실현할 수 있습니다. 블록체인은 인터넷의 네트워크처럼 상호 연결되고, 레이어제로, 하이퍼레인, IBC와 같은 프로토콜은 DeFi가 예측 가능한 미래에 탈 옴니체인 고속도로를 형성할 것입니다.

출처:

• LayerZero v2 architecture and DVN security – LayerZero V2 Deep Dive; Flare x LayerZero V2 announcement
• Hyperlane multisig and modular ISM – Hyperlane Docs: Validators; Tiger Research on Hyperlane; Hyperlane restaking (AVS) announcement
• IBC 3.0 light clients and features – IBC Protocol Overview; 3Commas Cosmos 2025 (IBC 3.0)
• Comparison of trust assumptions – Nosleepjohn (Hyperlane) on bridge tradeoffs; IBC vs bridges (Polymer blog)
• DeFi examples (Stargate, ICA, etc.) – Flare blog on LayerZero (Stargate volume); IBC use cases (Stride liquid staking); LayerZero Medium (OFT and OApp standards); Hyperlane use cases
• Adoption and stats – Flare x LayerZero (cross-chain messages, volume); Range.org on IBC volume; Blockchain Capital on IBC vs bridges; LayerZero blog (15+ DVNs); IBC testimonials (Osmosis, etc.).

암호화폐를 보낼 때 여러분은 어떤 절차를 밟나요? 대부분은 거래 내역에서 수신자의 주소를 복사하는 것이죠. 0x1A2b...8f9E 와 같은 40자 문자열을 외우는 사람은 없으니까요. 모두가 사용하는 편리한 바로 가기입니다.

하지만 그 편리함이 정교하게 꾸며진 함정일 수도 있습니다.

블록체인 주소 중독이라는 파괴적인 사기가 바로 이 습관을 노리고 있습니다. 카네기 멜론 대학의 최신 연구에 따르면, 이 위협은 엄청난 규모에 이른다고 합니다. 이더리움과 바이낸스 스마트 체인(BSC) 네트워크만으로도 2년 동안 사기꾼들은 2억 7천만 건 이상의 공격을 시도했으며, 1천 7백만 명의 피해자를 겨냥해 최소 8,380만 달러를 탈취했습니다.

이는 틈새 위협이 아니라 오늘날 가장 크고 성공적인 암호화 피싱 수법 중 하나입니다. 작동 원리와 보호 방법을 살펴보겠습니다.

사기의 작동 원리 🤔​

주소 중독은 시각적 트릭을 이용합니다. 공격자의 전략은 단순하지만 뛰어납니다.

1. 유사 주소 생성: 공격자는 사용자가 자주 송금하는 주소를 파악한 뒤, 강력한 컴퓨터를 이용해 시작과 끝 문자가 정확히 일치하는 새로운 암호화 주소를 만들어냅니다. 대부분의 지갑과 블록 탐색기는 주소를 축약해서 표시하기 때문에(0x1A2b...8f9E), 사기 주소는 눈에 보기에 진짜와 동일합니다.

2. 거래 내역에 “독” 주입: 다음으로 공격자는 그 유사 주소를 여러분의 지갑 내역에 넣어야 합니다. 이를 위해 “독” 거래를 보냅니다. 방법은 다음과 같습니다.

   • 소액 전송: 공격자는 유사 주소에서 아주 작은 금액(예: $0.001)을 보냅니다. 그러면 해당 주소가 최근 거래 목록에 나타납니다.
   • 무가치 전송: 더 교묘하게는 많은 토큰 계약에 존재하는 기능을 악용해, 여러분이 그 주소로 보낸 것처럼 보이는 0달러 전송을 만들어냅니다. 이렇게 하면 가짜 주소가 더욱 신뢰성을 얻게 됩니다.
   • 가짜 토큰 전송: “USDTT”(USDT가 아니라)와 같은 가치 없는 토큰을 만들어, 이전에 실제로 보낸 금액과 비슷하게 보이도록 전송합니다.

3. 실수 기다리기: 이제 함정이 완성되었습니다. 다음에 정당한 상대에게 송금하려고 할 때, 여러분은 거래 내역을 스캔하고, 올바른 주소라고 생각되는 것을 복사해 전송합니다. 실수를 깨달았을 때는 이미 자금이 사라진 뒤이며, 블록체인의 불가역성 때문에 은행에 전화해도 되돌릴 방법이 없습니다.

범죄 조직의 실태 🕵️‍♂️​

이것은 고독한 해커가 만든 것이 아닙니다. 연구에 따르면, 이러한 공격은 규모가 크고 조직적인 범죄 집단에 의해 수행됩니다.

목표 대상​

공격자는 소액 계정을 낭비하지 않습니다. 그들은 다음과 같은 사용자를 체계적으로 노립니다.

• 부유한 사용자: 스테이블코인 등 큰 잔액을 보유한 사람.
• 활발한 사용자: 빈번하게 거래를 하는 사람.
• 고액 거래자: 대규모 금액을 옮기는 사람.

하드웨어 무기 경쟁​

유사 주소를 생성하는 것은 무차별 대입(brute‑force) 연산 작업입니다. 일치시킬 문자 수가 많을수록 난이도는 기하급수적으로 상승합니다. 대부분의 공격자는 일반 CPU로 어느 정도 설득력 있는 가짜 주소를 만들지만, 가장 정교한 범죄 조직은 한 차원 높은 하드웨어를 사용합니다.

이 최상위 그룹은 목표 주소의 20자까지 일치시키는 주소를 생성했습니다. 이는 일반 컴퓨터로는 거의 불가능한 수준이며, 연구진은 이들이 GPU 팜—고성능 게임이나 AI 연구에 쓰이는 대규모 그래픽 처리 장치—을 활용하고 있다고 결론지었습니다. 막대한 초기 투자에도 불구하고 피해자들로부터 빠르게 회수하기 때문에 비즈니스 모델이 성립합니다. 조직적인 범죄 집단이 운영하는 사업이 바로 여기 있습니다.

자산을 보호하는 방법 🛡️​

위협은 정교하지만 방어는 간단합니다. 나쁜 습관을 끊고 더 경계하는 태도를 갖추면 됩니다.

1. 모든 사용자에게 (가장 중요한 부분)

   • 전체 주소를 확인하세요. “확인” 버튼을 누르기 전, 주소 전체를 문자 하나하나씩 눈으로 확인하는 데 5초만 더 투자하세요. 앞뒤 몇 자리만 보는 실수를 피합니다.
   • 주소록을 활용하세요. 신뢰할 수 있는 주소를 지갑의 주소록이나 연락처에 저장하고, 송금 시 동적 거래 내역이 아니라 주소록에서 선택하도록 합니다.
   • 테스트 송금을 실행하세요. 큰 금액이나 중요한 결제일 경우, 먼저 소액을 보내 상대에게 도착했는지 확인한 뒤 전체 금액을 전송합니다.

2. 지갑 개발자를 위한 제안

   • 사용자 인터페이스를 개선해 기본적으로 주소를 더 많이 표시하거나, 소액·무가치 전송만으로 상호작용한 주소에 대해 강력하고 명시적인 경고를 추가하도록 합니다.

3. 장기적인 해결책

   • 이더리움 네임 서비스(ENS)와 같은 시스템을 활용하면 yourname.eth 같은 인간 친화적인 이름을 주소에 매핑할 수 있어, 이 문제를 근본적으로 차단할 수 있습니다. 널리 채택되는 것이 핵심입니다.

탈중앙화된 세계에서 여러분은 스스로 은행이자 보안 책임자입니다. 주소 중독은 편리함과 부주의를 노리는 조용하지만 강력한 위협입니다. 신중하게 두 번 확인함으로써 여러분의 소중한 자산이 사기꾼의 함정에 빠지는 일을 방지할 수 있습니다.

Ethereum 과 같은 블록체인 기술의 핵심 약속 중 하나는 일정 수준의 익명성이다. 검증자라 불리는 참여자들은 암호화된 가명 뒤에 숨겨져 실제 신원을 보호하고, 따라서 보안도 확보된다고 여겨진다.

하지만 ETH Zurich 와 기타 기관의 연구원들이 발표한 최근 논문 “Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue”는 이 가정에 중대한 결함이 있음을 밝혀냈다. 그들은 검증자의 공개 식별자를 해당 검증자가 실행 중인 머신의 IP 주소와 직접 연결하는 간단하고 저비용인 방법을 시연했다.

요컨대, Ethereum 검증자는 많은 사람들이 생각하는 만큼 익명하지 않다. 이 발견은 Ethereum Foundation 으로부터 버그 현상금까지 수여받을 정도로 프라이버시 유출의 심각성을 인정받았다.

취약점 작동 원리: 가십(Gossip) 내 결함​

취약점을 이해하려면 먼저 Ethereum 검증자들이 어떻게 통신하는지 기본적인 그림을 그려야 한다. 네트워크에는 백만 명이 넘는 검증자가 존재하며, 이들은 지속적으로 체인의 상태에 대해 “투표”한다. 이러한 투표를 attestation(인증)이라 하며, 피어‑투‑피어 ($P2P$) 네트워크를 통해 모든 다른 노드에 전파된다.

검증자가 너무 많아 모든 투표를 모두에게 전파하면 네트워크가 즉시 과부하된다. 이를 해결하기 위해 Ethereum 설계자는 영리한 확장 방안을 도입했다: 네트워크를 64개의 별도 통신 채널, 즉 subnet(서브넷)으로 나눈 것이다.

• 기본적으로 각 노드(검증자 소프트웨어가 실행되는 컴퓨터)는 이 64개 서브넷 중 두 개에만 구독한다. 노드의 주요 역할은 그 두 채널에서 보는 모든 메시지를 충실히 중계하는 것이다.
• 검증자가 투표를 해야 할 때, 해당 attestation 은 무작위로 64개 서브넷 중 하나에 할당되어 전파된다.

바로 여기서 취약점이 발생한다. 예를 들어, 채널 12와 13만 관리하도록 설정된 노드가 있다고 하자. 이 노드는 하루 종일 그 두 채널의 메시지만을 전달한다. 그런데 어느 순간, 채널 45에 속한 메시지를 받게 된다.

이는 강력한 단서다. 왜 노드가 자신이 담당하지 않은 채널의 메시지를 처리하겠는가? 가장 논리적인 결론은 그 노드 자체가 해당 메시지를 생성했다는 것이다. 즉, 채널 45에 대한 attestation 을 만든 검증자가 바로 그 머신에서 실행되고 있다는 의미다.

연구진은 바로 이 원리를 이용했다. 자신들의 청취 노드를 구축하고, 피어들이 어느 서브넷에서 attestation 을 보내는지 모니터링했다. 피어가 공식적으로 구독하지 않은 서브넷에서 메시지를 보낼 경우, 그 피어가 해당 검증자를 호스팅하고 있다고 높은 확신을 가지고 추론할 수 있었다.

이 방법은 놀라울 정도로 효과적이었다. 세 날 동안 네 개의 노드만 사용해 팀은 161,000개 이상의 검증자 IP 주소를 찾아냈으며, 이는 전체 Ethereum 네트워크의 15% 이상에 해당한다.

왜 중요한가: 익명성 해제의 위험​

검증자의 IP 주소가 노출되는 것은 사소한 문제가 아니다. 이는 개별 운영자를 겨냥한 공격은 물론, 전체 Ethereum 네트워크의 건전성을 위협하는 문을 연다.

1. 표적 공격 및 보상 탈취
Ethereum 은 다음 블록을 제안할 검증자를 몇 분 전에 공개한다. 공격자는 해당 검증자의 IP 주소를 알면 DDoS(서비스 거부) 공격을 감행해 트래픽을 폭주시켜 오프라인 상태로 만들 수 있다. 검증자가 4초 안에 블록을 제안하지 못하면 기회는 다음 검증자에게 넘어간다. 공격자가 바로 그 다음 검증자라면, 피해자 대신 블록 보상과 귀중한 트랜잭션 수수료(MEV)를 차지할 수 있다.

2. 네트워크 가용성 및 안전성 위협
자원이 풍부한 공격자는 이러한 “스니핑” 공격을 반복해 전체 블록체인의 처리 속도를 늦추거나 정지시킬 수 있다(가용성 공격). 더 심각한 경우, 이 정보를 이용해 네트워크 분할 공격을 수행해 체인의 이력에 대한 합의를 깨뜨릴 수 있다(안전성 공격).

3. 중앙화된 현실 드러남
연구는 네트워크 탈중앙화에 대한 불편한 진실도 밝혀냈다:

• 극단적 집중: 팀은 하나의 IP 주소가 19,000개 이상의 검증자를 운영하고 있음을 발견했다. 단일 머신의 장애가 네트워크에 과도한 영향을 미칠 수 있다.
• 클라우드 의존: 찾아낸 검증자의 90% 이상이 AWS, Hetzner 등 클라우드 제공업체에서 운영되고 있었다. 이는 개인 홈 스테이커가 아닌 클라우드에 의존하고 있음을 의미한다.
• 숨겨진 의존성: 많은 대형 스테이킹 풀은 운영자가 독립적이라고 주장하지만, 연구 결과 서로 경쟁하는 풀의 검증자들이 같은 물리 머신에서 실행되고 있는 사례가 발견돼 시스템적 위험이 은폐돼 있음을 보여준다.

완화 방안: 검증자는 어떻게 스스로를 보호할 수 있는가?​

다행히 이 익명성 해제 기법에 맞설 방법이 존재한다. 연구진은 다음과 같은 완화 방안을 제시했다:

• 노이즈 증가: 검증자는 두 개 이상의 서브넷—심지어는 전체 64개—에 구독하도록 선택할 수 있다. 이렇게 하면 관찰자가 중계 메시지와 자체 생성 메시지를 구분하기 훨씬 어려워진다.
• 다중 노드 운영: 운영자는 서로 다른 IP를 가진 여러 머신에 검증자 역할을 분산시킬 수 있다. 예를 들어, 하나의 노드는 attestation 전송에만 사용하고, 별도의 프라이빗 노드는 고가치 블록 제안에만 활용한다.
• 프라이빗 피어링: 검증자는 신뢰할 수 있는 소수의 노드와 전용 연결을 구축해 메시지를 중계함으로써 진짜 출처를 작은 신뢰 그룹 안에 숨길 수 있다.
• 익명 브로드캐스트 프로토콜: Dandelion 과 같이 메시지의 출처를 무작위 “줄기(stem)”를 통해 전달한 뒤 널리 퍼뜨리는 방식을 구현하면 출처 추적을 더욱 어렵게 만든다.

결론​

이 연구는 분산 시스템에서 성능과 프라이버시 사이의 근본적인 트레이드오프를 강력히 보여준다. 확장성을 위해 Ethereum 의 $P2P$ 네트워크가 채택한 설계는 가장 핵심적인 참여자들의 익명성을 희생시켰다.

취약점을 공개함으로써 연구진은 Ethereum 커뮤니티에 문제 인식과 해결 방안을 제공했다. 이 작업은 보다 견고하고 안전하며 진정으로 탈중앙화된 네트워크를 구축하기 위한 중요한 첫걸음이다.

실리콘밸리 스타트업에서는 Docker Compose가 컨테이너화된 애플리케이션을 빠르게 배포하고 관리하기 위한 선호 도구 중 하나입니다. 하지만 편리함에는 보안 위험이 따르기 마련이죠. 사이트 신뢰성 엔지니어(SRE)로서 보안 취약점이 가져올 수 있는 재앙적인 결과를 잘 알고 있습니다. 이 글에서는 Docker Compose와 Ubuntu 시스템을 실제 업무에 결합해 적용하면서 정리한 최고의 보안 관행을 공유합니다. Docker Compose의 편리함을 누리면서도 시스템 보안을 확실히 지키는 방법을 알려드리겠습니다.

I. Ubuntu 시스템 보안 강화​

컨테이너를 배포하기 전에 Ubuntu 호스트 자체의 보안을 확보하는 것이 가장 중요합니다. 주요 단계는 다음과 같습니다.

1. Ubuntu와 Docker를 정기적으로 업데이트​

시스템과 Docker 모두 최신 상태를 유지해 알려진 취약점을 즉시 패치합니다.

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Docker 관리 권한 제한​

Docker 관리 권한을 엄격히 제어해 권한 상승 공격을 방지합니다.

sudo usermod -aG docker deployuser
# 일반 사용자가 쉽게 Docker 관리 권한을 얻지 못하도록 함

3. Ubuntu 방화벽(UFW) 설정​

네트워크 접근을 합리적으로 제한해 무단 접근을 차단합니다.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Docker와 UFW 연동 올바르게 구성​

Docker는 기본적으로 UFW를 우회해 iptables를 설정하므로 수동 제어가 필요합니다.

Docker 설정 파일을 수정합니다:

sudo nano /etc/docker/daemon.json

다음 내용을 추가합니다:

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Docker 서비스를 재시작합니다:

sudo systemctl restart docker

Docker Compose에서 주소를 명시적으로 바인딩합니다:

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Docker Compose 보안 모범 사례​

아래 설정은 Docker Compose v2.4 이상을 기준으로 합니다. Swarm 모드와 비 Swarm 모드의 차이점에 유의하세요.

1. 컨테이너 권한 제한​

컨테이너가 기본적으로 root 권한으로 실행되면 위험이 크므로 비 root 사용자로 전환합니다.

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000"  # 비 root 사용자
    read_only: true    # 읽기 전용 파일시스템
    volumes:
      - /tmp/app:/tmp  # 쓰기 권한이 필요한 경우에만 특정 디렉터리 마운트
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

설명

• 읽기 전용 파일시스템은 컨테이너 내부에서의 변조를 방지합니다.
• 마운트하는 볼륨은 반드시 필요한 디렉터리만 제한합니다.

2. 네트워크 격리 및 포트 관리​

내부 네트워크와 외부 네트워크를 명확히 구분해 민감한 서비스가 외부에 노출되지 않도록 합니다.

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• frontend 네트워크: 외부에 공개 가능.
• backend 네트워크: 내부 통신 전용으로 엄격히 제한.

3. 비밀 관리 보안​

민감한 데이터는 Compose 파일에 직접 넣지 않습니다.

단일 머신 모드:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

Swarm 모드:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true  # Swarm 내장 비밀 관리 사용

주의

• Docker Swarm의 기본 비밀 관리 기능은 Vault, AWS Secrets Manager와 같은 외부 도구를 직접 사용할 수 없습니다.
• 외부 비밀 저장소가 필요하다면 자체적으로 읽어오는 로직을 구현해야 합니다.

4. 리소스 제한 (Docker Compose 버전에 맞게 적용)​

컨테이너 하나가 호스트 리소스를 고갈시키는 일을 방지합니다.

단일 머신 모드 (v2.4 권장):

version: '2.4'

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Swarm 모드 (v3 이상):

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

Note: 비 Swarm 환경에서는 deploy 섹션의 리소스 제한이 적용되지 않으니 Compose 파일 버전에 유의하세요.

5. 컨테이너 헬스 체크​

헬스 체크를 설정해 문제를 사전에 감지하고 서비스 다운타임을 최소화합니다.

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. latest 태그 사용 금지​

프로덕션 환경에서는 latest 태그가 가져오는 불확실성을 피하고, 명시적인 이미지 버전을 지정합니다.

services:
  api:
    image: your-image:1.4.0

7. 로그 관리 적절히 수행​

컨테이너 로그가 디스크를 가득 채우는 일을 방지합니다.

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Ubuntu AppArmor 설정 확인​

Ubuntu는 기본적으로 AppArmor를 활성화합니다. Docker 프로파일 상태를 확인하는 것이 좋습니다.

sudo systemctl enable --now apparmor
sudo aa-status

Ubuntu에서 Docker는 기본적으로 AppArmor를 활성화하므로 별도 설정이 필요하지 않습니다. Ubuntu에 SELinux를 동시에 활성화하면 충돌이 발생하므로 권장되지 않습니다.

9. 지속적인 업데이트와 보안 스캔​

• 이미지 취약점 스캔: CI/CD 파이프라인에 Trivy, Clair, Snyk 등 도구를 연동합니다.

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• 자동 보안 업데이트 프로세스: 알려진 취약점을 해결하기 위해 최소 주 1회 이상 이미지를 재빌드합니다.

III. 사례 연구: Docker Compose 설정 실수에서 얻은 교훈​

2019년 7월, Capital One은 1억 명이 넘는 고객의 개인 정보를 유출하는 대규모 데이터 유출 사고를 겪었습니다12. 주요 원인은 AWS 설정 오류였지만, 컨테이너 보안 문제도 크게 작용했습니다.

1. 컨테이너 권한 문제: 공격자는 과도한 권한을 가진 컨테이너 내 WAF 취약점을 이용했습니다.
2. 네트워크 격리 미비: 침해된 컨테이너가 다른 AWS 리소스에 접근할 수 있었으며, 이는 네트워크 격리가 충분히 이루어지지 않았기 때문입니다.
3. 민감 데이터 노출: 설정 오류로 인해 대량의 고객 민감 데이터에 접근·탈취가 가능했습니다.
4. 보안 설정 실수 누적: 컨테이너와 클라우드 서비스 설정 오류가 복합적으로 작용해 사고가 확대되었습니다.

이 사건으로 Capital One은 수억 달러 규모의 벌금과 장기적인 신뢰 위기를 겪었습니다. 권한 관리, 네트워크 격리, 민감 데이터 보호 등 보안 설정의 중요성을 다시금 일깨워 주는 사례라 할 수 있습니다.

IV. 결론 및 권고사항​

Docker Compose와 Ubuntu 조합은 컨테이너 애플리케이션을 빠르게 배포하는 편리한 방법이지만, 보안은 전체 프로세스에 걸쳐 내재되어야 합니다.

• 컨테이너 권한과 네트워크 격리를 철저히 관리합니다.
• 민감 데이터가 유출되지 않도록 비밀 관리를 강화합니다.
• 정기적인 보안 스캔과 업데이트를 수행합니다.
• 기업 규모가 커짐에 따라 Kubernetes와 같은 고급 오케스트레이션 시스템으로 전환을 고려합니다.

보안은 끝이 없는 연속적인 실천입니다. 이 글이 Docker Compose + Ubuntu 환경을 보다 안전하게 운영하는 데 도움이 되길 바랍니다.