Cosmos L1이 어떻게 다음의 킬러 앱을 구축할 수 있을까?
작성: RainandCoffee
번역: TechFlow 인턴
지난 몇 주 동안, 테라 생태계의 붕괴 이후 더 큰 IBC 생태계에도 영향을 미친 상황에서 코스모스(Cosmos) 생태계는 부활하고 있다. 이에 따라 애플리케이션과 창시자들이 코스모스 위의 L1인 고유 앱 체인(특정 애플리케이션 블록체인)을 구축하기로 결정하거나 그 의사를 밝히고 있다.
하지만 우리는 기술적으로 전체 시스템이 매우 잘 유지되고 있다는 점을 주목해야 한다. 거래량은 매우 불안정했지만, IBC를 통해 내부 및 외부 메시지와 자산 전송을 체인 간 처리할 수 있었으며, 코스모스 SDK와 텐더민트(Tendermint), ABCI, 특정 VM(예: EVM)을 통해 내부 체인 상에서 이를 처리할 수 있었다.
본문에서는 특수 목적 체인의 부상 뒤에 있는 이론과, 이러한 체인이 제공하는 주권, 컴포저빌리티(조합 가능성), 상호 운용성이 다가올 사이클에서 다음 ‘킬러 애플리케이션’과 생태계를 구축하는 데 왜 중요한지를 설명하고자 한다.
논문 자체를 깊이 있게 분석하기 전에, 먼저 코스모스 생태계만의 독특한 기술들을 쉽게 이해할 수 있도록 간략히 소개하겠다. 전체 아키텍처는 다음과 같다:
코스모스 SDK
코스모스 SDK는 개발자가 가상 머신에 종속되지 않는 방식으로 애플리케이션 계층 로직을 구축할 수 있게 해주는 모듈화된 도구 세트이다. 코스모스 SDK는 ABCI를 통해 텐더민트와 연결되도록 설계되어 있으며, 앱 전용 블록체인 생성 프레임워크일 뿐 아니라 프로토콜 독립적인 거버넌스, 트랜잭션, 스테이킹 메커니즘 등 다양한 맞춤형 옵션도 제공한다. SDK는 대부분의 애플리케이션 로직 작업을 처리하므로 개발자는 처음부터 모든 것을 새로 구현할 필요가 없다. 텐더민트 합의 엔진으로부터 받은 트랜잭션을 라우터를 통해 처리하며, 메시지를 적절한 처리 모듈로 상태 변화와 함께 전달한다.
ABCI
ABCI(Application Blockchain Interface)는 블록체인 애플리케이션 부분과 텐더민트 상태 복제 엔진(합의 및 네트워크 메커니즘 제공) 사이의 인터페이스다. ABCI는 블록체인 스택을 분리함으로써 애플리케이션 부분이 가상 머신에 무관하게 작동할 수 있게 하며, 따라서 어떤 VM이나 실행 환경이라도 사용 가능하다. Junowasm, Cosmwasm, Agoric의 Hardened JavaScript, 심지어 TEE를 활용하는 Secret의 Cosmwasm 버전 등이 예시다. 텐더민트는 자체적으로 애플리케이션 부분과 세 가지 ABCI 연결을 형성하여, 메모리풀 전파 시 트랜잭션 검증, 애플리케이션과 합의 엔진 간 연결, 블록 제안 및 애플리케이션 상태 조회 기능을 담당한다.
텐더민트
텐더민트 코어는 코스모스 생태계 내 체인의 합의 및 네트워크 계층을 담당한다. 합의 계층은 네트워크 참여자들 간의 합의 알고리즘 과정을 통해 트랜잭션의 유효성과 순서를 보장하며, 네트워크 계층은 시스템 내 노드 간의 P2P 통신을 촉진하고, 제3자 애플리케이션 및 노드가 합의 계층과 상호작용할 수 있게 한다.
텐더민트는 비잔틴 장애 허용(BFT) 합의 모델을 사용하며 즉시 종결성(instant finality)을 구현한다. BFT 과정은 제안된 블록이 최종적으로 커밋되기 전에 세 단계를 거친다:
제안 단계(Propose): 특정 높이에서 블록이 지정된다.
사전 투표 단계(Pre-vote): 검증자의 2/3 이상이 제안된 블록에 대해 사전 투표를 한다.
사전 커밋 단계(Pre-commit): 검증자의 2/3 이상이 제안된 블록에 대해 사전 커밋을 한다.
IBC
IBC(Inter-Blockchain Communication)는 유사한 구조를 가진 블록체인 간 정보 전달을 위한 프로토콜이다. 즉, 즉시 종결성을 제공하는 텐더민트 합의 알고리즘과 경량 클라이언트 기능을 갖춘 체인처럼 유사한 특성을 공유하는 체인들을 연결한다.IBC는 서로 연결하고자 하는 두 체인이 목적지 체인에 거버넌스 제안을 제출하는 방식으로 작동한다. 현재로서는 일반적으로 코스모스 허브(Cosmos Hub) 또는 오스모시스(Osmosis)를 통해 이루어진다(오스모시스는 현재 45개, 코스모스는 40개 연결). 이는 프로토콜 수준에서 직접 연결이 가능하므로 외부의 제3자 크로스체인 브릿지가 필요하지 않다는 의미다.
두 체인은 서로의 경량 클라이언트를 통해 합의 상태를 암호학적으로 검증해야 하며, 중계기(relayer)가 두 체인의 경량 클라이언트 사이에서 정보를 전달해야 한다. 중계기는 유효성 조건으로, 노드 간 정보 교환 및 합의 성공 여부를 확인할 수 있어야 한다. 이것이 실제로 어떻게 작동하는지 살펴보자:
이는 신뢰 가정(trust assumption)이 연결된 두 체인의 검증자에 위치한다는 의미이며, 다른 유형의 크로스체인 브릿지나 메시지 전달 프로토콜보다 훨씬 적은 신뢰를 요구한다. 예를 들어 폴카닷(Polkadot) 생태계의 XCMP는 리레이 체인(폴카닷)에만 신뢰를 둔다.
IBC의 코스모스 생태계 내 호환성과 광범위함, 그리고 연결된 체인의 수를 보여주기 위해 현재 실시간 연결 규모를 살펴보자:
ICS
ICS는 Interchain Standard의 약자로, IBC를 사용하는 체인 간 거래의 매개변수를 정의한다. ICS는 기본적으로 IBC 거래를 위한 모듈 사양이며, 두 체인이 IBC를 사용하려면 동일한 ICS를 가져야 한다.
흥미롭고 독특한 ICS 중 하나는 ICS-27, 즉 체간 계정(Interchain Accounts)이다.
ICS-27
체간 계정은 컴포저빌리티, 즉 상호 운용성을 실현한다. 체인 간 데이터 교환뿐 아니라 한 체인의 스마트 계약이 다른 체인의 상태를 작성하도록 허용한다. 즉, 거래의 종점을 지정하기만 하면 사용자는 자산 또는 메시지 이전 시 여러 인터페이스를 왔다갔다 할 필요 없이 소스 체인의 단일 인터페이스를 활용할 수 있다. ICS-27을 지원하는 체인은 다른 ICS-27 지원 체인 상에 계정을 생성하고 IBC 거래를 통해 해당 계정을 제어할 수 있다. 체간 계정은 일반 계정의 모든 기능을 유지하지만, 별도의 체인 또는 최종 사용자가 IBC를 통해 운영하며, 소스 체인의 소유자가 대상 체인에 등록된 모든 크로스체인 계정에 대해 완전한 제어권을 유지할 수 있다.
IBC 거래 후 절차는 각 체인이 반드시 갖춰야 할 ICS 사양에 따라 진행된다. 이는 특정 애플리케이션 중심의 거래를 애플리케이션 독립적으로 전환함으로써 다양한 네트워크 간 진정한 컴포저빌리티를 가능하게 한다.
체간 보안(Interchain Security)
체간 보안은 한 체인 또는 허브가 다른 체인의 블록을 생성할 수 있게 한다. 검증자는 각 체인에 하나씩 두 개(또는 그 이상)의 노드를 운영하지만, 주 체인에서만 네이티브 토큰을 스테이킹하면 된다. 이는 IBC 수준의 프로토콜인 크로스체인 검증(Cross-chain Validation)을 통해 구현된다. 서브 체인은 IBC를 통해 주 체인과 통신하며, 체간 보안에 참여하는 검증자를 추적한다. 이렇게 함으로써 주 체인에서 잠긴 가치로부터 얻은 보안이 서브 체인과 공유된다. 따라서 소비자/서브 체인은 자체 검증자 네트워크를 구축하지 않고도 주 체인의 보안을 얻을 수 있다. 이는 자본 부담이 적은 애플리케이션이 자신의 체인을 쉽게 출시하면서 기존 검증자의 강력한 보안 수준을 유지할 수 있게 한다.
주 체인은 일련의 서브 체인에 대한 블록 생성을 담당하며, 검증자는 자신이 검증 중인 체인에서 스테이킹 보상을 받는다. 슬래싱(slashing)은 악의적인 행위를 방지하는 데 도움이 된다.
요약
애플리케이션 전용 블록체인은 우리가 말하는 블록 공간의 '창고화(warehousing)'를 실현한다. 블록체인 스택을 공급망으로 본다면, 스택 구성 요소들의 블록 공간은 기술적으로 해당 체인/계층 상의 애플리케이션에 의해 '구매'된다. 즉, 수많은 애플리케이션이 동일한 블록 공간 내에서 가스 비용을 함께 부담하게 되며, 이는 극도로 혼잡하고 경쟁적이 되어 비용 상승을 초래한다.
수천 개의 애플리케이션이 몰려 있는 심각하게 혼잡한 단일체 체인으로 인한 이러한 비용 급등은 결국 사용자에게 전가되며, 이들은 막대한 수수료를 부담해야 한다. 반면 애플리케이션 전용 체인에서는 애플리케이션 자체가 최종 사용자가 지불하는 수수료를 더 잘 제어할 수 있고, 이를 일정한 수준으로 유지할 수 있다. 오스모시스(Osmosis)가 좋은 예다.
이러한 애플리케이션은 X 또는 Y 체인을 창고로 의존하지 않으므로, 평균 비용이 높아지는 위험을 감수하지 않아도 되며, 이는 마치 상점의 재고 위험과 유사하다. 즉, 애플리케이션 자체와 그 확장인 커뮤니티가 재고 위험 관리에 참여할 수 있다. 이는 자원 가격 책정의 효율성을 초래하며, 결과적으로 애플리케이션의 더 나은 경제 모델로 이어진다.
애플리케이션이 자신이 존재하는 체인의 소유자이기 때문에 요금 구조를 자기 관리할 수 있으며, 더 이상 자신이 존재하는 체인에 종속되지 않고, 자신의 체인에서 각 자원의 비용을 결정할 수 있다.
게다가 저수준 기술 스택이 허용하는 유연성은 애플리케이션 계층의 최적화를 가능하게 하며, 원생적인 크로스체인 정보 전달 시스템 덕분에 더 큰 생태계 내에서 체인 간의 컴포저빌리티를 유지한다. 이 컴포저빌리티는 제3자의 신뢰 없이도 완전히 작동한다.
코스모스가 등장하기 전까지 애플리케이션과 인프라(체인) 사이에는 명확한 격차가 있었지만, IBC를 갖춘 애플리케이션 전용 체인은 이를 해체하고 애플리케이션이 연결되고 조합 가능한 인프라가 되도록 허용한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
