새로운 인터체인 기능들

1. 코스모스 생태계의 장단점

코스모스는 “블록체인의 인터넷”을 표방하며, 블록체인간에 유기적인 통신이 가능한 생태계를 구축하는 것을 목표로 이 세상에 등장했다. 물론, 현실은 같은 코스모스 SDK를 통해서 구축한 블록체인이 아니면 통신하기 어렵다는 부분이 있겠지만, 현재 악셀라(Axelar)와 같은 다양한 인터체인 솔루션들을 통해서 코스모스 생태계가 아닌 곳에서도 자산을 들여오려는 시도를 하고있다. 이러한 코스모스 생태계의 장점과 단점은 무엇이 있을까?

1.1 장점: 어플리케이션 특화 블록체인 구축 가능

코스모스 생태계의 장점은, 각각의 블록체인이 특정 어플리케이션에 특화되게 설계가 가능하다는 부분이다. 코스모스가 등장하기 전 까지의 블록체인은, 단일 블록체인에 다양한 어플리케이션이 구현되는 것이 너무 당연했지만 코스모스가 SDK(Software Development Kit)를 출시하고나서 코스모스 기반의 블록체인을 설계하는 것이 쉬워지자, 기존에 블록체인 위에서 서비스를 구현하고자 했었던 개발자들도 코스모스 생태계에서 어플리케이션 특화 체인을 구축하곤 했었다.

이러한 어플리케이션 특화 체인이 가지는 장점은: 1) 자체 체인이기 때문에 블록체인의 성능과 기능을 어플리케이션 하나에 맞출 수 있다. 2) 어디에도 종속되지 않는 독립적인 인프라를 구축할 수 있다 3) 단일 어플리케이션만 구축되는 경우가 대부분이기 때문에 네트워크 혼잡도가 비교적으로 적다. 로 요약될 수 있다. 또한, “블록체인의 인터넷”을 표방하는 만큼 같은 코스모스 SDK 기반의 체인들끼리는 매우 유기적으로 자산을 옮길 수 있다는 것 역시나 큰 장점으로 꼽힌다.

1.2 단점: 완벽하지 못한 소통

하지만 단점 역시나 명확한데, 이들은 ‘독자적인 어플리케이션 특화체인’을 표방하기 때문에 독립성은 보장할 수 있지만, 각각의 체인들이 곧 어플리케이션인 만큼, 이들간에 유연한 소통방식이 구현 가능한지의 여부도 매우 중요하다. 결국 유저들은 기존 블록체인에서 어플리케이션을 사용했을 때와 비슷하거나 더 나은 경험을 원할텐데 코스모스가 어플리케이션간 부자연스러운 연결성을 보여준다면, 유저들은 코스모스의 어플리케이션을 사용하지 않을 것이기 때문이다.

코스모스 생태계의 블록체인들은 IBC(Inter-block communication)이라는 프로토콜을 통해서 서로간에 소통을 하는데, IBC의 문제는 체인들간의 자산 이동은 매우 편리했지만, 체인들간에 컨트랙트 콜을 호출한다던지(기존 체인에서 다른 체인의 스마트 컨트랙트를 실행할 수 있는)하는 나름대로 복잡한 소통은 여태까지 불가능 했었다는 점이었다. 해서, 기존 모놀리틱 블록체인이 가지고 있는 어플리케이션간 “상호호환성(composability)”은 부재했다고 볼 수 있다.

또한, 독자적인 블록체인을 구축해야하기 때문에 벨리데이터를 모집하고, 초반에 벨리데이터들에게 보상을 해줘야한다는 부담 때문에 성공적인 레이어1 블록체인을 구축하는 것이 매우 어려웠다. 블록체인은 절대로 혼자서 만들어가는 프로덕트가 아니기 때문이었다.

2. 진정한 인터체인을 구축하기 위한 새로운 기능들: ICA, ICQ, RS

물론 코스모스 생태계의 개발자들도 이러한 한계점들을 명확하게 인지하고 있었기 때문에 앱체인들간 통신을 보다 더 고도화 시키려고 하였고, 이러한 노력속에 등장한 기술이 바로 Interchain Account(이하 ICA)와 Interchain Queries(이하 ICQ), 그리고 RS(Replicated Security) 이다. 좀 더 쉬운 이해를 돕기 위해서 스트라이드 블록체인과 코스모스 허브 블록체인을 실질적인 예시로 이 기능들을 설명하도록 하겠다.

2.1 Interchain Account

ICA는 하나의 체인(예시: 스트라이드)에 있는 계정이 다른 체인(코스모스 허브)과 소통하며 해당 체인의 계정을 컨트롤 할 수 있게 만드는 기능이다. 소통하고자 하는 체인들이 ICA 업그레이드만 했다면, 이들은 서로의 체인에 계정을 생성할 수 있다.

ICA를 이해하기 위해선 두 가지 개념을 이해해야한다: **컨트롤러 체인(Controller Chain)**과 **호스트 체인(Host Chain)**이 바로 그것들이다. 여기서 컨트롤러 체인은 다른 체인의 계정을 ‘컨트롤’하는 체인을 말하고, 호스트 체인은 컨트롤 되는 계정이 있는 체인을 말한다. 즉 필자가 방금 든 예시(스트라이드<>코스모스 허브)에선 스트라이드가 컨트롤러 체인이 되는 것이고, 코스모스 허브가 호스트 체인이 되는 것이다.

 

ICA가 작동하는 과정은 아래와 같다.

1. 컨트롤러 체인(스트라이드)이 호스트 체인(코스모스 허브)에 IBC 패킷을 전송한다.
2. 릴레이어는 해당 패킷을 전달받아 호스트 체인(코스모스 허브)의 IBC 모듈로 전송한다.
3. 호스트 체인의 ICA가 IBC 패킷과 함께 어떤 업무를 수행(스테이킹인지, 거버넌스, CDP를 여는 것인지 등등)해야하는지에 대한 정보를 전달받는다.
4. 호스트 체인의 ICA가 릴레이어에게 전달 받은대로 트랜잭션을 발생시켜 업무를 수행한다.

ICA가 활성화 되기 이전에는 다른 체인들에서 넘어오는 IBC 트랜잭션마다 다른 인터체인 표준(Interchain Standard)이 필요했다면, ICA가 활성화 되고 나서는 IBC모듈은 넘어오는 트랜잭션을 처리하는 것이 아니라 인터체인 어카운트에 해당 트랜잭션을 전달하는 역할만 수행하고, 넘어오는 트랜잭션에 대한 처리는 체인의 자체적인 로직(Interchain account가 전달받은대로 트랜잭션을 수행하는 것)에 의해서 진행된다.

ICA와 같은 기능이 추가되면 아까 위에서 언급했던, ‘스테이킹 유동화’만을 위한 앱체인이 구현 가능해진다. 왜냐하면, 스테이킹 유동화 앱체인이 ICA를 통해서 독립적인 다른 앱체인들에 대한 접근 권한이 생기기 때문이다. 스트라이드를 예시로 들어보면 아마 스트라이드에서 아톰을 스테이킹하는 과정은 아래와 같이 진행될 것이다.

1. 유저가 ATOM을 스트라이드에 예치 한다(그러면 증표 토큰인 stATOM을 그 대가로 받게 된다).
2. 스트라이드는 IBC를 통해 해당 ATOM을 코스모스 허브에 있는 ICA(Delegation ICA)에 전달한다.
3. 허브에 있는 ICA는 메시지를 확인하고 ATOM을 스테이킹하는 트랜잭션을 발생시켜 스테이킹한다(어떤 벨리데이터에 델리게이션을 할지도 정한다).

방금 설명한 스테이킹 유동화 말고도, 이미 스테이킹 유동화 되어있는 토큰들에 쌓이는 보상을 재투자 할 때에도 ICA는 사용된다: 실제로 스트라이드는 6시간마다 스테이킹 토큰에 쌓이는 보상을 처리하는데 보상의 90%는 위임 ICA에 보내서 다시 스테이킹 하고, 10%는 수수료 ICA에 보내서 수수료를 지불한다. 이런식으로, 스트라이드는 코스모스에서 발생하는 사건들도 직접 컨트롤하여 유기적으로 스테이킹 보상을 재투자한다.

이러한 기술들은 나름대로 복잡한 과정을 가지고 있다고 보일수도 있지만 실제로 유저들이 크게 해야하는 일은 없고 오히려 유저들은 ICA를 통해서 코스모스 허브에 직접 접근하지 않고도 코스모스 허브에 토큰을 스테이킹/재투자 할 수 있게 될 것이다.

2.2 Interchain Queries

ICA는 컨트롤러 체인이 호스트 체인에 대한 특정 권한을 행사할 수 있게 접근권을 주는 것이라고 한다면 Interchain queries (이하 ICQ)는 다른 블록체인에 있는 데이터를 제3자에 대한 의존 없이도 불러올 수 있는 인터체인 솔루션이라고 보면된다. 블록체인은 본질적으로 블록체인 외부의 환경과 독립된 데이터 베이스다. 그 뜻은, 블록체인이 자체적으로 생산한 데이터가 아니라면, 그 외의 데이터를 신뢰하기 어려운 환경이라는 말이다. 하지만 블록체인이 더 유용한 데이터 베이스가 되기 위해선, 결국 자기 체인 외부의 환경들(다른 블록체인도 여기에 포함된다)에서 발생한 데이터도 받아올 수 있어야 할 뿐만 아니라 해당 데이터가 유효한지에 대해서도 검증할 수 있어야 한다. 이렇게 블록체인이 자체적으로 해줄 수 없는 일들을 기존엔 오라클 솔루션이라고 부르는 써드파티 서비스들(체인링크, 피스 네트워크, 밴드 프로토콜등)이 담당해왔다. 하지만 결국 체인 외부의 데이터를 가져오기 위해서 써드파티 서비스에 의존해야 한다는 것은 그 자체로도 많은 위험을 감수하는 것이고, 실제로 해커들은 오라클 솔루션들을 공격하여 자금을 탈취하기도 하였기 때문에 오라클 솔루션들도 결코 좋은 대안이라고 불릴 수 없다.

이러한 한계속에서 등장한 것이 바로 ICQ이고, ICQ는 코스모스 생태계가 기존에도 IBC 라는 프로토콜을 코스모스 SDK 기반의 체인들끼리 소통해왔기 때문에 구현이 가능한 기술이라고 볼 수 있다. ICQ를 통해서 코스모스 생태계 체인들이 데이터를 주고 받는 방식은 아래와 같다.

 

1. (Interchain-Queries를 통해 체인들이 데이터를 주고 받는 방식 | 출처: quasar)

2. 위 그림에서 데이터 쿼리를 보내는 체인이 ‘홈 체인(home chain)’이고, 쿼리를 받는 체인이 ‘위성 체인(satellite chain)’라고 했을 때, 홈 체인의 노드가 IBC 패킷에 쿼리값들을 구성하고 릴레이어를 통해 패킷을 위성 체인으로 전달한다.
3. 그러면 위성 체인은 IBC 모듈을 통해 패킷을 전달받고 패킷을 알맞는 모듈들에 전달한다.
4. ICQ 모듈이 쿼리 값들을 확인하고 쿼리들이 필요한 위성 체인의 어플리케이션 모듈로 전달한다.
5. 전달 받은 쿼리값을 사용한 후 나온 결과값을 ICQ모듈과 IBC 모듈을 통해 홈 체인으로 전달한다.

 

(필자가 설명한 ICQ의 과정은 위와 같지만, ICQ가 오픈소스 프로토콜이기 때문에 다양한 방식의 변형이 생길 수 있고 다양한 방법을 통해 데이터를 가져올 수 있을 것이기 때문에 위의 예시는 ICQ를 사용해서 데이터를 불러오는 방식들 중에 하나정도라고 생각해주시면 되겠다.)

결국 스트라이드는 인터체인 생태계의 스테이킹 유동화 체인이기 때문에, 스트라이드를 통해서 스테이킹 되어있는 자산들이 얼마만큼 스테이킹 보상을 받고 있는지를 확인해야한다. 이럴 때 바로 ICQ 를 사용하여 스테이킹 보상값을 읽어올 수 있다.

2.3 RS(Replicated Security)

ICA와 ICQ만큼이나 코스모스 생태계의 가장 중요한 구성요소라고 할 수 있는 또 다른 기능은 바로 인터체인 시큐리티라고 불렸던 Replicated Security(이하 RS 또는 ICS)다. 현재 RS를 가장 먼저 도입했던 뉴트론을 시작으로 인터체인 스테이킹에 특화된 앱체인인 스트라이드, 그리고 DEX 특화 앱체인인 Duality까지 RS 도입을 계획하고 있다. 그렇다면 RS는 무엇이고 RS 이후로 코스모스 생태계에 어떤 변화가 있을까?

2.3.1. 토큰의 가치가 곧 보안인 PoS 생태계

우선 코스모스 허브를 포함한 코스모스 생태계의 모든 체인들은 근본적으로 PoS 컨센서스를 가지고 있다. 그 뜻은, 체인 자체의 보안이 토큰의 가치와 직접적인 연관성이 있다는 것이기도 하다. 예를 들어서, A 앱체인에서 발행한 네이티브/거버넌스 토큰의 시가총액이 100불이라고 한다면, 토큰의 50불만 조금 넘는 금액만 있어도 해당 체인의 토큰을 구매해서 체인을 공격할 수 있게 된다. 그렇기 때문에 새롭게 런칭하는 PoS 계열의 체인들은 시가총액이 높은 체인들 보다 보안에 취약할 수 밖에 없는 구조적 한계들이 존재하고, 이를 보완하기 위해서 나온 개념이 바로 RS다.

3.3.2 RS알아보기

RS를 이해하기 위해선 두 가지 개념을 먼저 이해해야한다: 프로바이더 체인(Provider-Chain)과 컨슈머 체인(Consumer-Chain)이라는 개념들이 바로 그것들이다. 프로바이더 체인은 말 그대로 컨슈머 체인에게 보안을 제공해주는 체인이고, 컨슈머 체인은 프로바이더 체인이 제공해주는 보안을 대가로 컨슈머 체인의 네이티브 토큰을 보상으로 지급해주는 관계이다. 많은 사람들이 RS를 이해할 때 ‘코스모스 허브가 앱체인에게 보안을 공유해주는 것’ 이라고 이해하지만, 나중엔 어떤 앱체인도 프로바이더 체인이 될 수 있을 것이다. 다만, 현재까지 코스모스 생태계에서 코스모스 허브의 가치가 제일 높기 때문에 코스모스 허브가 대표적인 프로바이더 체인이 될 것이라서 당분간은 코스모스 허브가 유일한 프로바이더 체인이 될 가능성이 높다 (이미 다른 코스모스 생태계의 앱체인들은 다른 방식의 보안공유 방식들을 채택하고 있는 중이라서, 보안을 공유하는 것이 코스모스 허브만이 아니라는 것은 이미 자명해졌다).

프로바이더 체인과 컨슈머 체인을 이해했다면 본격적으로 RS가 어떻게 작동하는지를 알아보자. 우선 프로바이더 체인은 해당 체인의 벨리데이터 셋을 IBC(Inter-block communication) 프로토콜을 통해 컨슈머 체인으로 전달한다. 그러면 컨슈머 체인은 프로바이더 체인에게 전달받은 벨리데이터 셋을 기준으로 컨슈머 체인의 벨리데이터 셋에 적용한다. 이런 방식으로 프로바이더 체인의 벨리데이터 셋과 컨슈머 체인의 벨리데이터셋을 똑같이 구성할 수 있다. 이렇게 구성된 벨리데이터들이 컨슈머 체인의 블록을 대신 생산해주고, 트랜잭션에 대한 검증도 대신 해준다. 그런데 문제는 동일 벨리데이터들이 컨슈머 체인의 블록을 생산하고 트랜잭션을 검증해준다고 해서 컨슈머 체인이 프로바이더 체인과 동일 수준의 보안을 갖는 것은 아니라는 것이다. 결국 중요한 것은 컨슈머 체인과 프로바이더 체인의 연결성이고, 이러한 이유로 RS를 해줄 때, 프로바이더 체인의 벨리데이터들은 프로바이더 체인의 네이티브 토큰(예: ATOM)을 사용하여 컨슈머 체인의 검증인 역할도 대신하는 것이다. RS를 할 때 프로바이더 체인의 네이티브 토큰을 사용한다는 뜻은, 벨리데이터들이 컨슈머 체인에 대한 검증과 블록생산을 소홀히 하게 되었을 때, 이들이 잃는 것은 컨슈머 체인의 토큰이 아닌, 프로바이더 체인의 토큰을 잃는다는 뜻이고 이러한 구조 때문에 프로바이더 체인의 보안 수준을 공유한다고 하는 것이다.

2.3.3 RS의 문제점

물론 RS도 문제가 없지는 않다. 최근에 코스모스 생태계의 유명 벨리데이터인 Chorus One에서 RS 자체의 지속가능성에 대한 의문을 제기한 리서치를 발간하면서 규모가 작은 군소 벨리데이터들에겐 RS가 오히려 비용적으로 큰 부담이라는 문제가 제기되었다. RS라는 기능이 표면적으로 봤을 땐, 모두에게 윈윈인 기술로 비춰질 수 있으나(코스모스 허브 벨리데이터에겐 추가적인 보상이 주어지고, 컨슈머 체인의 경우엔 코스모스 허브에 준하는 보안을 누릴 수 있다는 점에서) 실질적은 내막을 보면 허브 벨리데이터가 추가적으로 블록체인을 더 운용하는 것이기 때문에 비용적으로 부담이 추가될 수 밖에 없다. Chorus One이 지적했던 것처럼, RS를 통해서 대형 벨리데이터만 지속적으로 이득을 보는 상황들이 연출된다면, RS가 원래 가졌던 의미는 희석될 것이고 결국 RS를 통해 블록체인을 런칭하고자 했던 수요가 줄어들면서 지속 가능성에 문제가 생길 수 있기 때문에 RS의 인센티브 구조에 대해서 좀 더 고차원적인 논의가 필요할 것이다.

 

3. 맺으며: 진화하는 생태계

모든 블록체인 생태계가 그렇듯, 코스모스 생태계 또한 여러가지 문제점들이 존재한다. 하지만, ICA, ICQ, RS와 같은 새로운 기능들을 통해 문제점을 계속해서 보완해나가려는 움직임 또한 존재한다. 코스모스 생태계가 성공하기 위해선 아직도 갈 길이 멀다고 생각하지만, 옳은 방향으로 가고있다고 생각한다. 코스모스 허브의 중립성을 유지하면서도 코스모스 생태계가 성장함과 동시에 코스모스 허브에도 가치를 전달할 수 있는 체계를 완성하고, 통신 프로토콜을 지속적으로 발전시켜서 어플리케이션 특화 체인들이 좀 더 유기적으로 소통할 수 있는 발판을 마련한다면 코스모스 생태계는 진정으로 블록체인들의 인터넷이 될 수 있을 것이다.

 

Four Pillars — Website | Twitter(EN) | Twitter(KO) | Telegram

포필러스는 서울에 거점을 둔 글로벌 블록체인 리서치 회사로, 한국에서 가장 영향력 있는 블록체인 리서처들로 구성되어 있습니다. 탄탄한 리서치와 거버넌스 기술을 통해 다양한 시장 플레이어들이 블록체인 산업에 쉽게 진입할 수 있도록 돕는 한편, 프로토콜의 한국 및 글로벌 시장 진출을 지원하고 있습니다.

Writer: Steve Kim, Co-Founder and CEO at Four Pillars 
Reviewer: 100y, Co-Founder and Publication Lead at Four Pillars 

#Cosmos #Interchain #Multichain #Appchain #FourPillars