최근, 업비트 원화마켓에 코스모스(아톰)가 안착했다. 왜 사람들은 코스모스에 열광해왔고, 다시금 관심이 재점화 된 것일까?

“코스모스 = 인터체인” 이란 개념에 대한 이해와 함께, 현재 가장 자주 언급되는 경쟁자와 코스모스를 비교해 보았을 때 어떤 특징을 갖고 있는지에 대해 알아보자.

코스모스의 경쟁사로는 중국에서 “Chain for the enterprises by the modularization(모듈화를 통한 기업 간 체인)”라는 슬로건을 외치는 널스(NULS)라는 곳이 꼽힌다.

해당 프로젝트와의 비교분석을 통해 우선 코스모스 자체에 대한 이해를 할 기회를 갖고, 이후 널스에 대한 이해 및 코스모스와의 공통점과 차이점을 알아본 후, 우리가 얻을 수 있는 시사점에 대해 언급하는 방식으로 글이 진행될 것이다.

 

코스모스 vs 널스

 

코스모스널스
레이어 갯수
23
합의체계 (Consensus)
텐더민트 (DPoS + PBFT)PoC (Proof of Credit)
체인 형성 방법
Plug-in
Chain factory
모듈화 정도

(코드 종속성)

단일 구조가능한 부분 최대 모듈화
인터체인

(크로스체인) 형태

허브메인 네트워크

 

위 표에서 기록된 것처럼, 5개의 비교 항목들을 볼 수 있다. 상단 항목부터 차례대로 짚어보도록 하자.

 

1. 레이어 갯수

 

코스모스, 널스 둘 다 어플리케이션 레이어와 코어 레이어를 분리하여, 노드에 대한 부담 및 오류 가능성을 줄였다.

하지만, 레이어 갯수에서 차이가 난다.

먼저 코스모스부터 살펴보자.

코스모스의 기본구조는, 코스모스 허브 (또는 브릿징 존(bridging zone))와, 허브와 같은 구조를 갖고 있는 존 (Zone)들 간의 상호작용 구조라고 생각하면 쉽다.

이는 아래와 같다.

 

그림: 코스모스 생태계 (출처 : 블록인프레스)

 

핵심인 허브 (Hub) – 다양한 존 (Zone)끼리 “같은 구조”로 구성되는지 보여주는 생태계표이다.

상호작용이 꾸준히 일어날 수 있기에, 왜 “Inter”chain (인터체인)로 명명된 지 또한 알 수 있다.

저기 사이에 연결해주는 것들에 대해 알아보자면, ABCI (Application BlockChain Interface)의 경우, 어플리케이션 레이어와 합의 & 네트워크 레이어와 같은 베이스 레이어를 연결해주는 존재이다. IBC (Inter-Blockchain Communication)의 경우, 이러한 존들 간의 통신을 위해 (물론 브릿징 존인, 코스모스 허브를 통해) 존재하는 통신수단이라고 생각하면 된다. 인터넷에서는 TCP/IP가 통신 프로토콜로 있는데, 이를 생각해보면 조금이나마 이해를 돕지 않을까 싶다.

위에서 볼 수 있듯, 허브 (or 존)은 2개의 층, Cosmos SDK과 Tendermint/Core로 구성된다.

허브(or 존)의 구조를 좀 더 상세히 보자면 아래와 같다.

 

그림; 코스모스 기본 구조 설명

 

그렇다면, 널스의 생태계 구조는 어떻게 되어있을까?

이에 대해 알아보기 전에, “최대 모듈화”를 외치는 프로젝트를 알아보는 것이기 때문에 모듈이 뭔지에 대해 간단히 알아보면 좋을 듯하다.

모듈 (module)이란 공사장에서 볼 수 있는 컨테이너를 생각하면 개념 이해가 상대적으로 쉬운 편이다.

 

 

다변량 데이터에서는 “어떠한 주제로 개념들을 묶어놔야” 이해/암기에 효율적이다.

코딩을 할 때도, 마찬가지로 효율성을 위해 비슷한 기능/성질을 갖는 요소들을 묶어 보관하는 것을 “모듈”이라고 표현한다. (혹시 코딩을 한 번쯤이라도 해본 사람은 Docker(도커)라는 프로그램 또한 알텐데, 이 것도 효율성/집합성 추구란 같은 결을 띄고 있기에 백엔드에서 자주 활용되고 있다.)

이러한 개념을 이해하고, 전체 생태계를 확인해보자.

널스 체인은 1. 댑 레이어(Dapp Layer), 2. 블록체인 베이식 서비스 레이어(Blockchain Basic Service Layer), 3. 마이크로서비스 인프라스트럭쳐 레이어(Microservice Insfrastructure Layer, NULSTAR) 이렇게 총 3개의 레이어로 구성되어 있다.

아래 그림을 살펴보자. 아래 그림의 경우, 인프라스트럭쳐 레이어는 코스모스에 비해 모든 과정들이 “모듈화”를 통해 기능상 확실히 분리되었기에, 크로스체인 생태계를 보여주는데에 따로 표시되지 않았다.

 

그림: 널스 생태계 (출처: 널스 홈페이지)

 

상위 댑 레이어, 블록체인 베이식 서비스 레이어를 해당 생태계 그림에서 확인할 수 있다.

그러면 레이어들에 대한 간단한 설명을 아래에서 확인해보자.

 

 

그림: 널스 기본 구조 설명

 

위에서 말했듯, 널스는 상대적으로 더 “모듈화”를 추구하기에, 어플리케이션 레이어가 2개로 다시 나뉘어 있는 것을 볼 수 있다.

댑 레이어가 추가적으로 나뉜 이유는, 스마트 계약 자체에 집중하여 기본 앱 라이브러리를 통해 지원하는 것이 낫다 판단했기 때문이다.

따라서, 두 프로젝트 모두 듀얼 체인 시스템처럼, 실제 업무 레이어 (어플리케이션 레이어) & 기반 레이어 (합의/네트워크 레이어)를 분리했으나, 널스쪽에선 한층 더 업무 레이어를 분리한 것을 볼 수 있다.

 

2. 합의체계

코스모스는 텐더민트 (Tendermint), 널스는 PoC (Proof of Credit)라는 다르지만 비슷한 합의체계를 활용한다.

두 합의체계 모두 PoS와 BFT를 응용하였다. 더 자세히는, DPoS와 PBFT를 응용했다.

따라서, 여기에선 기본적으로 검증인 (Verifier) & 대리인 (Delegate)의 개념이 중요하다. 검증인은 노드를 만들고, 스테이킹을 통해 합의 체계에 참여한다. 그리고 대리인이 되는 것이다.

이런 부분에선 두 프로젝트의 성격이 같다. 하지만, 다른 점은 코스모스는 상당히 로드맵에서 뒤쳐진 상황이었기에 메인넷을 이번년도에 들어 런칭했다. 그리고 몇 주 전, phase 2를 시작했다. phase 1에선 밸리데이터 노드가 100개까지만 서포트 가능했다.

하지만, 널스의 경우엔 이미 작년에 런칭 후 꾸준히 운영되는 상황이었으며, 널스는 노드 수 제한이 없다.

그렇기에 참여 노드 수의 경우, 최근 코스모스쪽이 늘은 편이나, 블록 높이의 경우 확연한 차이를 보임을 알 수 있다.

 

 

그림: 코스모스 메인넷 상황

 

 

그림; 널스 메인넷 상황

 

그러면 텐더민트와 PoC의 가장 큰 차이는 무엇일까?

바로 Consistency (정합성)에 대한 접근법이다.

전자의 경우, 네트워크 파티션에 수반되는 정합성 이슈를 원칙적으로 해결하고자 하여, “2/3” 이상의 노드들이 투표에 참여하지 않는다면, 네트워크 자체가 이를 기다리게 된다. “Parallel-chain communication”이란 특수한 형태가 이러한 해결책을 만든 이유로, 아래에서 다루겠다.

후자의 경우, “final consistency”, 즉 마지막에 집중하여, 파티션된 네트워크들은 블록 생성을 정상적으로 할 수 있고, 마지막에 합치는 경우에 합쳐지고 정합성 관련 합의시스템을 진행하여 80% 이상 컨펌일 경우 통과하게 된다.

이러한 차이 외에도, POS와 POW 중 뭐가 더 맞는 합의체계인지에 대해선 여러 갑론을박이 오가고 있으나, 현재 이 시스템을 활용하는 이상, 최대한 두 프로젝트 모두 안전하게/효율적으로 이를 진행하려 하고 있다. 그래서, PBFT 또한 활용하는 중이다.

 

3. 체인 형성 방법

코스모스, 널스 둘 다 “모듈”을 활용한다는 점에선 결이 같다. 하지만, 개발자들이 원래 활용하던 체인을 연결시킬 때 차이가 난다.

코스모스의 경우, Plug-in (플러그인) 구조를 활용하여, 특정 체인이 Cosmos SDK에 붙어야 된다. 내장된 플러그인이기에, 만약 다른 언어 활용 체인을 쓰고 있었다면 코스모스의 개발언어에 종속되는 경우가 생긴다.

(코스모스 기본 구조 설명 그림 참고)

즉, 따로 플러그인 개발 및 적용을 하기 위한 비용이 추가적으로 발생할 수가 있는 것이다.

널스의 경우 최대한의 모듈화를 고려하기에 개발언어에 상관없이 활용될 수 있다.

아래의 그림을 보자

 

그림: Module Repository

 

그림: Chain Factory

베이식 서비스 레이어(Basic Service Layer)에 위치한 모듈 저장소(Module Repository)를 통해 자주 활용되는 모듈 종류를 바로 입히거나, 같은 레이어에 위치한 “Chain Factory”에서 새로이 만들 수 있다. 마치 DIY와 FAQ같은 서비스가 연상된다.

DIY/FAQ 같은 서비스를 제공하기에, 상대적으로 개발자들이 힘을 덜 들이고 활용할 수도 있겠단 생각을 할 수 있다.

물론 선택은 간단하지 않다. 소규모 블록체인 시스템의 경우, 차라리 플러그인을 편하게 연동시키는 게 나을 수 있다. 하지만, 다양한 케이스를 제공하는 것도 분명 소비자, 즉 개발자들에게 굉장히 좋은 인센티브를 제공한다고 생각할 수 있다.

 

4. 모듈화 정도 (코드 종속성)

코드 종속성 (Code dependency)란 무엇인가? 바로, 특정 코드를 “맞춰서” 사용해야 한다는 것이다. 이는 개발언어부터 일반 코딩 방식까지 적용될 수 있는 성질인데, 위에서 봤던 플러그인 방식은 모듈화 정도를 낮추는 요소로서, 코드 종속성을 늘리는 방식이다.

또한 “단일구조 (Monolithic structure)”라는 표현을 위에서 활용했는데, 코스모스를 활용하기 위해선 개발 및 테스트를 위해 코스모스의 모든 코드를 다운받아야 하기 때문이다.

게다가 플러그인 방식을 활용해야하니 자연스레 이용자들은 코스모스의 형식에 많이 맞춰가야한다는 번거로움이 생긴다.

반대로 널스의 경우, 모듈간의 독립성을 최대한 보장하는 방향으로 미리 모듈, SDK 등을 준비하여. 코드 종속성을 최소화했다. 비용 최적화가 따라서 가능하다.

정말 간단하게는, 가장 아랫 레이어인 NULSTAR (인프라 레이어)에 여러가지 모듈이 연결된 가지가 쳐져있는 모습을 상상하면 쉬울 듯하다.

또한 하나의 추가적인 차이로는, 코스모스는 텐더민트 코어를 결국 거쳐야하기에, 합의체계 역시 코스모스를 따라야한다. 하지만 널스의 경우, 합의체계를 베이식 서비스 레이어에 넣어서 선택권을 부여한다.

(Protocol Transfer Layer을 통해, 널스 생태계 참고)

즉, 이는 이용자들의 니즈에 따라 조정할 수 있다.

위에서 언급했듯, 둘 다 장단이 있다.

“편의성/안정성”이 필요한 정도에 따라 선택의 자유도를 선택하여 맞는 체인을 선택하는 것이다.

 

5. 인터체인 (크로스체인) 형태

두 프로젝트 모두 커뮤니케이션 자체에 집중하는 것은 맞다.

다만, 코스모스의 경우 코스모스 허브를 “브릿징 존”으로 활용하여 “Parallel-chain communication(병렬적 체인 커뮤니케이션)”을 통해 커뮤니케이션의 중심지로 활용한다. 즉, 모든 것이 실시간으로 운용될 수 있도록 체인 운영을 하는 것이다.

물론 노드 2/3 이하 참여일 경우 네트워크 마비와 같은 상황이 생길 수는 있다. 그래서 합의체계 또한 정합성을 위해 어찌보면 타이트한 것이다.

하지만, 널스의 경우, 위에서 설명했듯 메인넷에서 최종적 합의체계를 거치기 때문에 정합성 부분 해결책의 형태가 상대적으로 다르다.

허나, 외부 퍼블릭 체인 (비트코인, 이더리움 등)의 연동 처리 관련해서는 결이 같다: 바로 ‘간접적 연결’이다.

코스모스의 경우, SDK를 활용하여 “Proxy chain (프록시 체인)”을 만들고 코스모스 허브를 통해 간접적으로 다른 체인들과 소통하게 만든다.

반면, 널스의 경우, 프로토콜 컨버젼 레이어(Protocol Conversion Layer)를 통해 간편하게 메인넷과 연동을 할 수 있게하며, 다른 연결된 체인들과도 상호운용할 수 있도록 서비스를 제공한다.

 

시사점

두 프로젝트 모두 상호운용성(Inter-operability)에 집중하고, 여러 특장점들을 갖고 있다.

코스모스는 이 아이디어를 실제로 운용할 수 있게 시작의 포문을 열어준 프로젝트라고 볼 수 있다면, 널스는 후발주자로서 단점들로 생각되는 부분들을 자신만의 방식으로 고친 후, 중국의 뚝심으로 빠르게 빌딩/운영을 꾸준히 진행해오는 프로젝트이다.

둘 다 결국 최대한 베이스 레이어를 꾸리려고 노력하는 것이다. 이러한 노력들은 시도 자체만으로도 블록체인 생태계에 매우 의미있는 프로젝트들이라고 할 수 있다. 각각 미국, 중국의 느낌이 물씬 나는 프로젝트로서 어떻게 각자만의 로컬 커뮤니티를 또한 잘 활용할지 (중국의 경우 PCTA)가 기대되며, 현재 대기업 및 새로운 프로젝트들도 빠른 메인넷 런칭과 함께 다가오는 상황에서 어떻게 이들이 엮일지도 모르는 일이다. 두 기업의 발전과정이 기대된다.

 

 

참조 문헌:

– https://explorer.nuls.io/address

– https://hubble.figment.network/cosmos/chains/cosmoshub-2

– https://medium.com/@matthewminseokkim/%EC%BD%94%EC%8A%A4%EB%AA%A8%EC%8A%A4%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-a4549b541658

– https://www.reddit.com/r/nulsservice/comments/8xvw08/nuls_is_in_mainnet/

Leave comment

Your email address will not be published. Required fields are marked with *.

WordPress Image Lightbox