코스모스는 대체로 여러 블록체인을 연결하는 ‘상호 운영성(Interoperability) 솔루션’으로 여겨진다. 하지만 상호 운영성은 코스모스 팀이 추구하는 목표 중 하나이며, 코스모스를 단순한 상호 운영성 솔루션으로 보고 있다면 코스모스의 중요한 핵심들을 놓친 것이다. 코스모스는 단순히 상호 운영성 솔루션 역할을 하기 위해 만들어진 프로젝트가 절대 아니다. 코스모스의 진정한 가치에 대해 제대로 설명하기 위해 코스모스의 비전에 대해 처음부터 설명해보고자 한다.
간단하게 블록체인이란 서로를 신뢰할 필요가 없는 노드들에서 복사되어 나오는 결정론적 상태(deterministic state) 머신을 의미한다. 상태(state)가 무엇을 의미하는지는, 각 어플리케이션에 따라 달라진다 (예를 들면: 각 계정에 들어있는 토큰 잔고가 ‘상태’이다). 그리고 이 상태를 변화시키는 것이 트랜잭션(transaction)이다 (코인을 A 계좌에서 B로 전송할 경우 블록체인에 트랜잭션이 전파되고, 이 트랜잭션에 의해 ‘상태’에 해당하는 A와 B 계좌의 코인 ‘잔고’가 변한다). 구조적인 관점에서 블록체인은 개념적인 3개의 층(Layer, 이하 레이어)으로 나눠질 수 있다.
네트워킹(Networking): 트랜잭션을 전파하는 역할하는 레이어
컨센서스(Consensus; 합의): 검증인 노드들이 다음에 처리할 트랜잭션 목록에 동의하도록 만드는 레이어
어플리케이션(Application): 검증인들이 합의한 트랜잭션에 따라 상태를 업데이트하는 레이어 (블록에 포함된 트랜잭션 정보를 블록체인에 추가하는 역할)
네트워킹 레이어는 각 노드들이 서로 트랜잭션을 주고받을 수 있도록 만든다. 컨센서스 레이어는 각 노드들이 보유한 블록체인에 기록된 상태를 ‘모두 동일한 트랜잭션’을 바탕으로 변경하는 것에 동의하도록 만든다. 어플리케이션 레이어의 경우 검증인들이 합의한 트랜잭션을 처리한다. 검증인의 합의를 통과한 트랜잭션과 기존 상태가 어플리케이션 레이어에 전달되면, 어플리케이션 레이어는 기존의 상태 값을 새로운 상태 값으로 변경한다. 비트코인의 경우를 예를 들면, ‘상태’는 각 계좌에 있는 ‘비트코인 잔고’를 의미한다 (‘비트코인의 잔고’는 정확히는 UTXO의 리스트를 의미한다, UTXO란 사용되지 않은 트랜잭션 출력값[Unspent Transaction Output]을 의미한다. 하지만 본문에서는 간략한 설명을 위해 ‘비트코인 잔고’라고 표현했다). 트랜잭션이 ‘비트코인 잔고’라는 ‘상태’에 변화를 주는 것이다. 이더리움의 경우 어플리케이션은 가상 머신(virtual machine)이다. 각 트랜잭션은 가상 머신에 전달되고, 가상 머신은 전달받은 트랜잭션에 의해 호출되는 스마트 컨트렉트에 의해 상태를 수정한다.
텐더민트가 세상에 등장하기 전에는 블록체인을 만들기 위해서 이 세 가지 레이어를 전부 처음부터 만들어야 했다. 그래서 이러한 지루한 일을 피하기 위해 대다수의 개발자들이 비트코인의 코드를 포크해서 블록체인을 만드는 방법을 선호했으나, 이는 만들어진 블록체인이 비트코인 프로토콜의 한계에 제한된다는 단점을 동반했다. 이더리움의 등장으로 이더리움의 가상 머신 위에 누구나 자신만의 로직을 스마트 컨트렉트를 통해 쉽게 구현할 수 있게 되면서 분산화 어플리케이션을 만드는 일이 매우 쉬워졌다. 하지만 이더리움은 블록체인 그 자체를 개발하는 과정을 단순화시키지는 못했다. 왜냐하면 고-이더리움(Go-Ethereum)은 비트코인처럼 하드포크 하기 어려운 하나의 단일 블록체인이기 때문이다. 이 지점에서 텐더민트가 필요해진다.
텐더민트의 목적은 다양한 블록체인 어플리케이션을 만들 수 있는 범용성 높은 엔진을 제공하는 것이며, 이를 위해 텐더민트는 블록체인의 네트워킹 레이어와 컨센시스 레이어를 사용자들에게 제공한다. 텐더민트가 있는 경우 개발자들은 블록체인을 만들 때 오직 어플리케이션 레이어만 개발하면 된다. 이는 개발자들이 블록체인을 처음부터 만든다고 가정했을 때 필요한 수백 시간의 개발 기간을 단축시켜 준다. 텐더민트는 ‘텐더민트 코어 엔진(Tendermint core engine)’에 사용되는 비잔틴 결함 장애 컨센서스 알고리즘의 이름이기도 하다. 프로토콜에 대한 더 구체적인 내용이 궁금한 경우, 이 팟캐스트를 참조하면 된다.
텐더민트 코어 엔진은 어플리케이션 블록체인 인터페이스(ABCI, Application Blockchain Interface)로 불리는 소켓 프로토콜을 통해 어플리케이션과 연결되어있다. 이 프로토콜은 어떠한 컴퓨터 언어로도 개발될 수 있기 때문에 개발자들은 그들이 어플리케이션을 만드는데 사용하고 싶은 언어를 선택할 수 있다. 이것이 전부가 아니다. 텐더민트의 목표는 개발자들에게 단순한 테스트용 블록체인 어플리케이션을 만들 수 있는 도구를 제공하는 것이 아닌, 매우 고성능의 블록체인 어플리케이션을 개발할 수 있는 도구를 제공하는 것이다. 다음과 같은 특성들이 텐더민트를 최첨단 블록체인 엔진으로 만들어준다:
퍼블릭 혹은 프라이빗 블록체인 지원(Public or private blockchain capable): 텐더민트는 오직 블록체인의 네트워킹 및 컨센서스 레이어를 다루는 블록체인 엔진이다. 즉, 텐더민트 엔진은 노드들이 트랜잭션을 전파하고, 검증인들이 한 세트의 동일한 트랜잭션을 블록체인에 추가하는 것에 동의하는 과정을 다뤄준다. ‘검증인은 어떻게 선출되는가?’와 같은 법칙과 규정들은 어플리케이션 레이어에서 결정된다. 그러므로 개발자들은 텐더민트를 기반으로 퍼블릭 혹은 프라이빗 체인을 모두 만들 수 있다. 만약, 어플리케이션 레이어에서 검증인의 선출 기준을 ‘얼마나 많은 코인을 묶었는지’로 정하는 경우, 해당 블록체인은 POS(Proof-Of-Stake) 블록체인이 된다. 하지만, 만약 어플리케이션 레이어에서 검증인은 ‘사전에 승인된 제한된 주체들만 검증인이 될 수 있다’라고 정하면, 이 블록체인은 POA(Proof-Of-Authority) 기반의 프라이빗 블록체인이 된다. 개발자들은 자신의 블록체인의 검증인을 어떤 기준으로 선출할 것인지 자유롭게 설정할 수 있다.
고성능(High Performance): 텐더민트 코어는 약 1초의 블록 타임을 가지고 있으며, 초 당 수천 건의 트랜잭션을 처리한다.
즉각적인 완결성(Instant finality): 텐더민트 컨센서스 알고리즘의 특징은 즉각적인 완결성이다. 이는 ⅓ 이상의 검증인이 비잔틴 행위를 하지 않는 이상 포크가 절대 발생하지 않음을 의미한다. 사용자들은 블록이 생성되는 즉시 그들의 트랜잭션이 완결됐음을 확신할 수 있게 된다.
보안성(Security): 텐더민트 컨센서스는 비잔틴 장애 저항성뿐만 아니라, 책임성(accountability)을 가지고 있다. 만약, 블록체인에 포크가 발생하면 해당 포크의 책임이 어떤 검증인에게 있는지 확정할 수 있는 것이다.
텐더민트의 또다른 장점은 ABCI가 모듈화 되어 있기 때문에 기존에 존재하는 블록체인의 코드를 텐더민트 엔진에 올려서(Port) 사용하는 것이 가능하다. 예를 들어, 당신은 이더리움의 가상 머신 코드를 가져와 텐더민트 위에 플러그 인 시킬 수 있다. 실제 우리는 이러한 일을 작업을 수행했고, 텐더민트 위에 이더리움 가상 머신을 올린 결과물에 이더민트(ethermint)라는 이름을 붙였다. 이더민트는 이더리움과 똑같이 동작한다. 그러나 위에 언급된 텐더민트의 모든 장점을 그대로 활용할 수 있다. 트러플(Truffle), 메타마스크(Metamask)와 같은 이더리움 툴(Tool)들은 이더민트에서 동일하게 사용 가능하며, 기존에 작성된 이더리움 스마트 컨트렉트 코드들 또한 추가적인 노력 없이 이더민트에서 그대로 사용이 가능하다.
우리는 이제 블록체인 개발에 ‘텐더민트’를 활용할 수 있다. 텐더민트를 통해 개발자들은 누구나 매우 쉽게 고성능의 블록체인을 네트워킹 및 컨센서스 레이어에 대한 고민 없이 개발할 수 있다. 이렇게 개발된 블록체인들의 어플리케이션 층은 모두 다르지만, 모두 동일한 네트워킹 및 컨센서스 레이어를 가진다. 이러한 이유로 텐더민트 기반의 블록체인은 서로 쉽게 연결된다.
텐더민트 블록체인간의 연결은 IBC라고 불리는 프로토콜을 통해 이뤄진다. IBC는 블록체인 커뮤니케이션 프로토콜(Inter-Blockchain Communication Protocol)의 줄임말이다. IBC는 텐더민트의 즉각적인 블록 완결성을 바탕으로 이종의 체인이 서로 가치(예를 들면, 코인)을 교환할 수 있게 만들어준다. IBC가 어떻게 동작하는지, 어떻게 블록체인의 인터넷인 코스모스를 형성하는데 사용되는지는 백서에 기술되어 있다.
먼저, 우리는 이종체인이 무엇을 의미하는지 이해할 필요가 있다. 이종체인은 다음과 같은 특징을 가진다.
서로 다른 레이어(Different layers): 이종 체인은 서로 다른 레이어를 가진다. 즉, 이종 체인은 서로 다른 네트워크, 컨센서스, 어플리케이션 레이어가 서로 다른 체인을 말한다. 이러한 차이점이 블록체인 간의 소통에 제한이 생기는 주원인이 되며, 그중 컨센서스가 빠른 완결성을 가지지 못한 경우 블록체인 간의 소통이 매우 어려워진다. POW(Proof-Of-Work) 체인의 경우 확률론적으로 완결성이 확보되기 때문에 빠른 완결성을 갖지 못하는 체인으로 분류된다.
주권(Sovereignty): 모든 블록체인은 일련의 검증인 집합(set of validators)에 의해 유지된다. 검증인들은 블록체인에 커밋될 다음 블록에 어떤 트랙잭션들이 포함될 것인지를 동의하는 역할을 수행한다. POW의 경우, 검증인들은 채굴자들로 불린다. 주권을 가진 블록체인이라는 의미는 블록체인이 고유한 검증인 집합을 가지고 있음을 의미한다. 검증인들이 블록체인의 상태 변화를 책임지기 때문에 대부분의 경우 각 블록체인이 고유한 주권을 가지는 것이 매우 중요해진다. 이더리움의 경우 모든 어플리케이션이 동일한 검증인들에 의해서 운영되기 때문에 각 어플리케이션은 매우 제한된 주권만 가진다.
IBC는 이종 체인 간의 코인 교환을 가능하게 만든다. 이것은 블록체인이 서로 다른 검증인 집합을 가지고, 블록체인 위에 만들어진 어플리케이션 레어어가 달라도 블록체인 간에 상호 운영성이 생김을 의미한다. 이것은 블록체인의 유연성을 극대화시킨다는 점에서 매우 중요하다. 예를 들어, IBC가 도입되면 퍼블릭 블록체인과 프라이빗 블록체인의 코인 교환이 가능해진다.
IBC의 동작 원리는 매우 간단하다. 만약 블록체인 A에서 10개의 ‘X 코인’을 블록체인 B로 보내는 경우를 생각해보자. 먼저, 이 10개의 X 코인이 체인 A에서 임의로 움직일 수 없게 ‘잠겨야’ 한다. 그 뒤 ‘X 코인 10개가 블록체인 A에서 움직이 못하게 잠겼다는 사실’이 A 체인에서 B 체인으로 전달된다. 그러면 체인 B는 체인 A의 ‘검증인의 집합’이 어떻게 변했는지를 확인한다. 만약, A 체인의 검증인의 2/3가 해당 사실(X 코인 10개가 체인 A에서 잠겼다)에 서명한 경우 체인 B의 검증인들인 이를 유효하다고 인정하고, 체인 B에 10개의 X 코인을 발행한다.
체인 A에 잠겨있는 코인을 풀기 위해서 체인 B에 있는 X 코인 10개를 체인 A로 되돌리는 과정도 유사한 매커니즘이 적용된다. IBC에 대해 보다 포괄적인 설명은 해당 문서에 기술되어 있다. 현재 IBC 프로토콜은 이종 블록체인 간의 가치 이동에 최적화되어 있으며, 차후 이종 블록체인간 로직 이동을 지원할 수 있다.
우리는 이종 체인간의 코인 교환을 가능하게 만드는 IBC라는 프로토콜이 있다. 이를 바탕으로 어떻게 블록체인의 인터넷을 만들수 있을까?
한 가지 방법은 네트워크 상에 존재하는 모든 블록체인이 IBC를 통해 서로 직접 연결되는 것이다. 이러한 접근 방법은 두 가지 문제점이 있다.
연결점의 개수(Number of connections): 만약, 100개의 블록체인이 네트워크 상에 존재하고, 이들이 모두 IBC를 통해 서로 직접 연결되려면 총 4,950개의 접촉점이 요구된다. 즉, 이러한 방법을 사용하는 경우 네트워크 상의 블록체인의 숫자가 증가하면 요구되는 접촉점의 숫자가 기하급수적으로 증가하는 문제가 발생한다.
높은 신뢰성 필요(High trust requirements): 체인 A가 코인을 발행한 블록체인으로부터 해당 코인을 직접 전달받는 경우, 오직 한 단계의 신뢰성만 요구된다(해당 코인을 발행한 블록체인만 믿으면 된다). 즉, 체인 A는 오직 코인을 보낸 체인의 검증인들이 ‘보낸 수량만큼 코인을 잠그지 않거나’, ‘더블 스팬딩’을 하지 않을 것임을 믿으면 된다. 하지만, 체인 A가 해당 블록체인에서 발행하지 않은 코인을 전달받는 경우 체인 A는 더 높은 신뢰도를 요구받는다. 왜냐하면 코인을 받는 체인 A의 입장에서 해당 코인을 신뢰하기 위해서는 ‘코인이 발행된 블록체인에 해당 코인이 제대로 잠겨있고’, ‘해당 코인이 거쳐온 모든 블록체인에서 더블 스팬딩이 하나도 없다’라는 전제 조건을 신뢰해야 하기 때문이다. 코인이 거쳐온 블록체인의 숫자가 증가할수록 해당 코인을 받는 블록체인은 더 많은 신뢰성을 요구받는다. 이 것은 현실적이지 않다. 이러한 문제를 막기 위해 코인이 생성된 블록체인에서 해당 코인의 잠김을 푼 뒤 다시 다른 블록체인에 보내는 방법을 사용할 수 있다(무조건 코인을 발행한 블록체인에서 보내는 코인만 받는 방식). 하지만 이것보다 더 좋은 해결 방법이 있다.
이러한 문제를 풀기 위해서 코스모스는 두 가지 형태의 블록체인(허브와 존)을 모듈화한 구조를 제안한다. 존(Zone)은 일반적으로 존재하는 서로 다른 블록체인을 의미하고, 허브(Hubs)는 존을 연결하는 특별한 블록체인을 의미한다. 하나의 존이 허브와 IBC를 통해 연결되면, 이 존은 허브에 연결된 다른 존들과 코인을 교환할 수 있게 된다. 이로써 각 존은 제한된 숫자의 허브와 제한된 숫자의 IBC 연결만 유지하면 된다. 이로써 허브는 존들의 더블 스팬딩을 막을 수 있고, 각 존은 다른 코인을 받을 때 연결된 허브와 그 코인이 생성된 존만 신뢰하면 된다.
코스모스 생태계(Cosmos Ecosystem)에서 최초로 런칭되는 허브가 코스모스 허브(Cosmos Hub)이다. 코스모스 허브는 아톰(Atom)으로 명명된 코인을 바탕으로 동작하는 POS 블록체인이며, 블록체인의 전송 수수료로 아톰과 포톤(Photon)을 비롯한 다수의 코인이 사용될 수 있다. 이 첫 허브의 런칭과 함께 코스모스 네트워크가 시작된다.
텐더민트 기반이 아닌 다른 체인을 연결하는 방법 (Bridging non-Tendermint chains)
지금까지의 서술된 코스모스 생태계 구조를 보면 오직 텐더민트 기반의 체인만 상호 운영성을 확보할 수 있는 것으로 보인다. 그러나 코스모스 생태계는 텐더민트 기반의 체인에만 한정되지 않는다. 사실, 어떠한 블록체인도 코스모스 생태계에 연결될 수 있다.
빠른 완결성을 갖는 체인과 확률론적으로 완결성이 확보되는 체인이 코스모스 생태계에 연결되는 방법은 다음과 같다.
빠른 완결성을 가진 컨센서스 알고리즘을 사용하는 블록체인의 경우 IBC를 받아들여 코스모스 네트워크에 접속할 수 있다. 예를 들어, 이더리움의 컨센시스가 캐스퍼 FFG (완결성이 빠르게 확정되는)로 전환되면, 캐스퍼에 IBC를 받아들여 코스모스 생태계와 연결될 수 있다.
POW 같이 빠르게 완결성이 확보되지 않는 컨센시스를 사용하는 체인을 코스모스 생태계와 연결하는 작업은 좀 더 어려울 수 있다. 이러한 체인을 코스모스 생태계에 연결하기 위해 페그존(Peg-Zone)으로 명명된 특화된 프록시 체인이 사용된다.
페그존은 다른 블록체인의 상태(State)를 추적하는 블록체인이다. 페그존 자체는 빠른 완결성을 가지기 때문에 IBC와 호환된다. 페그존은 블록체인을 코스모스 생태계에 연결하기 위해 필요한 빠른 완결성을 책임지는 역할을 한다. 예시를 통해 이를 좀 더 자세히 이해해보자.
우리는 POW 기반의 이더리움을 코스모스 생태계에 연결해 코스모스와 이더리움간의 코인 이동이 가능하게 만들고자 한다. POW 기반의 이더리움은 빠른 완결성을 가지지 않기 때문에 이더리움과 코스모스를 연결해줄 페그존이 필요해진다.
먼저, 페그존은 오리지널 체인에서 완결성을 확보하기까지 얼마나 기다려야 할 것인지를 결정해야 한다. 예를 들어, 페그존은 오리니지널 체인에서 완결성이 확보되기까지 약 100개의 블록이 생성되어야 한다고 기준을 세울수 있다. 이더리움 메인 블록체인에서 특정 계약이 만들어져 네트워크를 통해 전파되면, 페그존은 그 특정 계약을 지속적으로 추적한다. 사용자가 이더리움에서 코스모스로 코인을 보내길 원하는 경우, 사용자들은 실제 이 계약 주소로 이더리움을 보낸다. 그러면, 이더리움 상에 쓰여진 계약에 의해 해당 계약 주소로 들어온 이더리움은 잠기고, 100개의 이더리움 블록이 생성된 뒤 100개의 이더리움의 가치를 지니는 코인 100개가 페그존에서 발행된다. 동일한 메커니즘이 코스모스에서 이더리움으로 코인을 보내는 경우에도 이뤄진다(코스모스 코인들은 이더리움 위에서 ERC20 형태로 발행된다). 텐더민트 팀은 현재 이더리움 체인과 코스모스를 연결하는 페그존인 패기(Peggy)를 만들고 있다.
페그존의 문제점은 각 블록체인을 연결하기 위해서 그에 맞게 특화된 페그존을 만들어야 한다는 점이다. 이더리움은 계좌-베이스(account-based) 구조, 스마트 컨트렉트가 가능하기 때문에 이더리움 페그존을 만드는 일은 상대적으로 쉽다. 그러나 비트코인 페그존을 만드는 것은 더 어려운 일이다. 비트코인 페그존을 어떻게 만드는지에 대한 내용은 이 글에서 다루고자 하는 범위를 넘어간다. 그러나 비트코인 페그존을 만드는 일은 이론적으로 가능하며, 해당 페그존에 대한 구체적인 설명은 해당 문서를 참조하면 된다.
현재까지, 우리는 다음과 같은 툴(Tool, 도구)을 디자인하기 위해 힘을 기울여왔다.
텐더민트와 ABCI를 이용해 블록체인을 개발하는 것을 쉽고, 빠르게 만들어주는 툴
블록체인들이 IBC와 페그존을 통해 서로 상호 운영 가능하게 만들어주는 툴
그러나 여전히 블록체인 개발은 개발자들에게 쉬운 일이 아닌가? 현시점에서 개발자들이 텐더민트 코어를 사용하는 경우 오직 어플리케이션 레이어만 만들면 블록체인을 만들 수 있다. 이는 이미 충분히 블록체인 개발이 쉬워졌음을 의미한다. 하지만 우리는 개발자들에게 이보다 더 쉽게 블록체인을 개발할 수 있는 환경을 제공하고자 한다.
블록체인 기반의 어플리케이션을 개발하는 것은 여전히 쉬운 일이 아닐 수 있다. 그렇기 때문에 코스모스-SDK가 필요해진다. 코스모스-SDK는 텐더민트 위에 안전한 블록체인 어플리케이션을 개발할때 사용되는 일반화된 개발 툴이다. 이것은 다음과 같은 두 가지 중요한 원칙을 가진다:
구성가능성(Composability): 코스모스-SDK의 목적은 개발자들이 에플리케이션의 모든 기능을 직접 코딩할 필요 없이 모듈을 조합해 사이드체인을 쉽게 만들 수 있는 모듈 생태계를 만드는 것이다. 누구나 코스모스-SDK에 사용되는 모듈을 만들 수 있으며, 이미 만들어진 모듈을 간단하게 자신의 어플리케이션에 적용할 수 있다. 예를 들어, 텐더민트 팀은 코스모스 허브를 운영하기 위해 필요한 스테이킹, IBC, 거버넌스와 같은 기본적인 모듈들을 만들고 있다. 이러한 모듈들은 텐더민트를 사용해 블록체인 어플리케이션을 만들고자하는 개발자는 누구나 사용할 수 있다. 개발자는 아직 개발되지 않은 자신의 어플리케이션에 특화된 모듈만 직접 개발하면 된다. 코스모스 네트워크의 개발팀으로서, 우리는 모듈 생태계가 급속도로 확장될 것을 기대하고 있으며, 복잡한 블록체인 어플리케이션을 만드는 것이 점점 더 쉬워질 것을 기대한다. 코스모스-SDK를 어떻게 사용하는지 설명하는 문서는 곧 나올 예정이다.
기능 기반 보안성(Capabilities based security): 기능(Capabilities)이 모듈 간 보안성의 경계를 제한하기 때문에, 개발자가 모듈 구성의 가능성을 더 깊이 고민할 수 있으며, 악의적인 공격과 예상하지 못한 상호작용이 발생할 수 있는 범위를 제한할 수 있다. 기능에 대해서는 해당 문서에 자세하게 기술되어 있다. 우리는 코스모스-SDK에서 사용하는 기능 기반의 보안을 구체적으로 다루는 문서를 발표할 것이다.
코스모스-SDK는 커맨드-라인 인터페이스, REST 서버, HSM 라이브러리와 같은 유용한 툴들을 가지고 있다.
코스모스-SDK의 단점은 무엇일까?
현재, 코스모스-SDK는 오직 고랭 언어만 지원한다. 그러므로 코스모스-SDK를 사용할 경우 고랭 언어를 기반으로 어플리케이션을 만들어야 한다. 미래에는 SDK가 다른 언어를 지원할 수 있을 것으로 기대한다. 현재로썬, 개발자가 고랭을 사용하지 않을 경우 ABCI 위에 처음부터 어플리케이션을 만들어야한다. 만약, 당신이 자바스크립트를 사용하길 원한다면 로션JS(LotionJS)라는 좋은 프레임워크가 준비되어 있다.
최종적으로 코스모스-SDK는 다른 코스모스 툴과 마찬가지로 모듈 형태로 디자인된다. 이로써 개발자들은 텐더민트 컨센서스 엔진 위에서 블록체인을 쉽게 개발할 수 있다. 또한 코스모스-SDK는 다른 컨센서스 엔진에서도 사용될 수 있다. 미래에 우리는 전혀 다른 구조로 설계된 다양한 SDK가 개발되고, 다수의 컨센서스 엔진과 호환될 것을 기대한다. 코스모스라는 단일 생태계에 수많은 블록체인들이 함께 있는 것이다 (All within a single ecosystem: Cosmos).
우리는 이제 쉽게 블록체인을 만들고, 서로 연결할 수 있다. 그럼 무엇이 남았을까? 아마 당신은 이번 세션의 제목인 ‘확장성’을 그 대답이 아닐까 떠올릴 것이다. 오늘날의 블록체인은 확장성이 없다. 그리고 이는 블록체인 생태계에서 가장 큰 문제 중 하나로 지적되고 있다.
코스모스는 다음과 같은 두 가지 방식의 확장성을 제시한다:
수직적인 확장성(Vertical scalability): 수직적 확장성은 블록체인 자체의 확장성을 증가시키는 방법을 의미한다. POW를 벗어나 각 구성 요소를 최적화하는 과정을 통해 텐더민트 코어는 초당 수천 개의 트랜잭션을 처리할 수 있다. 처리 성능을 감소시키는 요인은 주로 어플리케이션 그 자체에서 발생한다. 예를 들면, 가상 머신(이더리움의 가상 머신)과 같은 어플리케이션의 트랜잭션 처리 성능은 상태 변화 및 트랜잭션 처리 기능이 블록체인에 직접 올라간 어플리케이션(코스모스-SDK로 만들어진 어플리케이션)에 비해 대폭 낮아진다. 이것이 어플리케이션에 특화된 블록체인이 필요한 이유 중 하나이다 (다른 추가적인 이유는 해당 문서에 기술되어 있다).
수평적인 확장성(Horizontal scalability): 컨센서스 엔진과 어플리케이션이 아무리 최적화돼도 하나의 체인에서 처리할 수 있는 트랜잭션 처리 용량은 어느 시점에서 더 이상 증가할 수 없는 한계에 도달한다. 이것이 수직적인 확장성의 한계이다. 이러한 수직적 확장성을 뛰어넘기 위해서, 우리는 멀티-체인 구조(multi-chains architectures)를 도입했다. 아이디어의 핵심은 수평적인 관계에 있는 다수의 체인이 동일한 어플리케이션을 동일한 검증인 집합에 의해 돌리는 것이며, 이러한 방법을 통해 이론적으로 무한한 확장성(indefinitely scalable)을 가지는 것이 가능해진다. 이러한 수평적인 확장성에 대한 구체적인 내용은 매우 복잡하기 때문에 이번 글에서 다루지 않는다.
코스모스는 런칭 당시 수직적인 확장성을 지원할 것이며, 이 것만으로도 블록체인의 확장성은 매우 큰 폭으로 증가할 것이다. 이후 수평적인 확장 솔루션이 도입될 것이다.
여기서 의문이 생길 수 있다. 왜 분산화된 어플리케이션을 블록체인 가상 머신위에서 만들 수 있고, 이 블록체인이 확장성을 가질수 있다면 왜 새로운 블록체인을 새로 만들어야하는가? 현재 이더리움과 같은 가상 머신을 지원하는 블록체인 위에 대다수의 탈중앙화 어플리케이션이 만들어졌다는 점을 고려하면, 이는 당연한 질문이다. 우리는 이러한 현상이 발생한 가장 큰 이유를 스마트 컨트렉트를 사용한 어플리케이션 개발보다 블록체인을 직접 개발하는것이 더 어렵기 때문이라고 생각한다. 하지만 이제 더 이상은 아니다. 코스모스-SDK를 통해 누구나 쉽게 어플리케이션에 특화된 블록체인을 만들 수 있기 때문이다. 왜 어플리케이션에 특화된 블록체인이 필요한지, 왜 이 방식이 합리적인지는 해당 내용을 설명한 문서에 자세하게 나와있다. 만약, 개발자가 자신만의 블록체인을 만들고 싶지 않은 경우 코스모스와 호환되는 이더민트와 같은 존에서 스마트 컨트렉트를 통해 어플리케이션을 개발하는 것도 가능하다.
우리는 지금까지 코스모스에 대해 많은 부분을 다뤘다. 여기서 코스모스가 무엇인지 세 가지 문장으로 간결하게 정리하고, 요약해보자.
무엇보다, 코스모스는 하나의 제품이 아니다. 코스모스는 모듈화 된 개발 툴과 적용 가능하고, 상호 교환 가능한 툴로 만들어지는 하나의 생태계를 의미하는 단어이다. 개발자들에게 이미 개발된 툴을 개선하고, 새로운 툴을 만들어 블록체인 기술의 본래 목적을 현실에서 구현하는 일에 동참하기를 권한다. 이렇게 만들어진 툴들은 탈중앙화 된 인터넷을 만들고, 글로벌 금융의 미래를 설계하기 위한 기초가 될 것이다.
우리는 지금까지 코스모스의 비전과, 코스모스의 잠재력에 대해 알아보는 시간을 가졌다. 지금부터는 코스모스가 어떻게 사용되는지를 명확한 사용 예시와 함께 설명하고자 한다.
펀드레이징 존 (Fundraiser Zone)
만약, ICO 존을 코스모스에 만드는 경우를 생각해보자. 코스모스에 만들어진 ICO 존은 탈중앙화되어 있고, 투명하게 운영되고 있는 모든 암호화폐를 받아들일 수 있다. 또한, ICO 존은 확장성이 있고, 다른 분산화된 어플리케이션과 함께 돌아가지 않는다 (가상 머신과 같은 어플리케이션 없이 단독 어플리케이션으로 구동된다). 즉, 사용자들이 모든 ICO를 하나의 고성능 플랫폼을 통해 참여할 수 있게 되는 것이다.
우리는 개발자들의 편의성을 위해 코스모스-SDK를 사용해 ICO 존을 만들고자 한다. 우리가 만들 ICO 존은 퍼블릭 POS 존이며, 여기에는 다음과 같은 모듈이 사용된다.
스테이킹(Staking): POS를 다루기 위한 모듈
계좌와 은행(Accounts and Bank): 각 사용자의 코인 수량을 지속적으로 추적하는 모듈
거버넌스(Governance): 소프트웨어 업그레이드 및 유지 보수를 위한 모듈
IBC: 코인을 보내고, 받기 위한 모듈
운 좋게 ICO 존을 만들기 위해 필요한 모든 모듈이 이미 개발되어 있다. 우리는 ICO 존을 위해 새로운 코딩을 할 필요가 없다. 이제 특화된 어플리케이션을 만들기 위해 필요한 ICO 모듈을 만드는 일만 남았다. 이것은 어려운 일이 아니다(코스모스-SDK 모듈을 어떻게 코딩하는지를 설명하는 문서는 곧 공개될 예정이다).
이것이 전부다! 퍼블릭이고, 상호 운영이 가능하고, 확장성 있는 블록체인을 코딩하는 것이 이제 간단하게 모듈을 조합하는 것만으로 가능해졌다. 이제 남은 것은 블록체인 어플리케이션을 위한 프런트-앤드 개발이다. 이 것은 그렇게 어려운 일이 아니다.
우리가 오픈 소스 정신이 있다면, 우리는 개발한 ICO 모듈 코드와 문서를 무료로 공개해 모든 개발자들이 그들의 어플리케이션에 ICO 모듈을 붙여서 해당 기능을 사용하게 만들 수 있다.
탈중앙화 거래소 (Decentralised Exchange)
탈중앙화 거래소를 구현하는 것은 암호화폐 거래소들의 ‘성배(Holy grail)’라고 할 수 있다 (오랜 숙원이다). 탈중앙화 거래소의 경우 사용자들이 자신의 자산을 언제나 직접 컨트롤한다. 즉, 탈중앙화 거래소는 사용자들이 자산을 거래소 운영자들에게 위탁하고, 그들을 믿어야되는 시스템을 가진 기존의 중앙화 거래소와는 전혀 다르다.
코스모스 위에 탈중앙화 거래소를 만드는 일은 상당히 간단하다. 거래소 블록체인은 자금의 보관과 청산을 담당한다. 오더북 매칭은 사용자들을 만족시킬 수 있는 사용자 경험과 풍부한 오더북을 제공하기 위해 중앙화된 운영자들에 의해 관리될 수 있다 (관련 내용은 해당 문서에 자세히 기술되어 있다).
우리는 우리가 설계하는 탈중앙화 거래소에 법정 화폐를 지원하고자 한다. 하지만 법정 화폐는 규제에서 자유롭지 않기 때문에 퍼블릭 블록체인 상에서 발행되기 어렵다. 이 때문에 우리의 탈중앙화 거래소는 2-체인 구조(2-chains infrastructure)를 가질 것이다. 하나의 체인은 법정 화폐를 담당하는 프라이빗 POA(Proof-Of-Authority) 체인이 될 것이고, 다른 체인은 퍼블릭 POS 체인으로 암호화폐 거래를 담당한다. 이 두 체인 모두 텐더민트 컨센서스 엔진을 기반으로 만들어진다. 이 두 개의 체인은 IBC를 통해 서로 연결되어 있으며, 코스모스 허브와도 연결될 수 있다.
이러한 복잡한 구조를 가진 분산화 거래소를 만들기 위해서 무엇이 필요할까? 생각보다 많은 것이 필요하지 않다. 스테이킹, 거버넌스, 계좌-은행, IBC 모듈은 이미 구현되어 있다. 추가로 개발이 필요한 모듈은 다음과 같다:
POA 모듈(A Proof-Of-Authority module): 법정화폐를 다루는 프라이빗 블록체인의 검증인 집합을 설정하기 위한 모듈
법정화폐 모듈(A FIAT-token module): 관할구역의 법적 규제의 틀 안에서 법정 화폐를 블록체인에 발행 및 이전하는 모듈
결제 모듈(A settlement module): 두 체인 간의 코인 거래를 체결하는 모듈
이 세 가지 모듈이 추가되면 우리는 탈중앙화 거래소를 만들기 위해 필요한 기초 블록체인 아키텍처 레이어를 구성할 수 있다.
지역 화폐 (Local currencies)
7개의 미국 주(State) 정부가 그들 고유의 지역 화폐를 발행하고자 하는 경우를 생각해보자. 각 주 정부는 자신의 주에 속한 도시를 연결하는 블록체인을 운영해 주 정부가 발행한 지역 화폐를 관리할 것이다. 이러한 블록체인을 코스모스 위에서 만드는 것은 매우 쉬운 일이다. 계좌-은행 모듈, 거버넌스 모듈이 이미 있기 때문이다. 남은 일은 POA 모듈을 만들어서 각 주가 그들 고유의 프라이빗 체인을 운영할 수 있도록 만드는 것이다.
이제 7개의 주가 각각 운영하는 프라이빗 체인을 서로 연결해 상호 운영성(코인을 서로 교환하는 것)을 가질 필요성이 생겼다고 생각해보자. 이 필요성을 해결하는 것은 매우 쉬운 일이다. 각 주 정부가 운영하는 프라이빗 블록체인을 모두 연결하는 ‘허브’를 런칭하면 이 문제는 바로 해결된다. 각 주 정부에 의해 독립적으로 운영되는 7개의 프라이빗 체인과 이들을 연결하는 하나의 허브가 존재하면 되는 것이다. 이를 과정에서 필요한 일은 7개의 프라이빗 체인에 IBC 모듈을 붙이고, IBC 모듈을 통해 허브에 7개의 체인을 연결하는 것이다.
이를 통해서 총 7개의 지역 화폐가 발행되고, 7개의 지역 화폐는 7개의 주에 걸쳐서 유통되고, 사용 가능해진다. 만약, 7개의 주 정부가 그들이 발행한 지역 화폐가 퍼블릭 블록체인 기반의 암호화폐와도 교환이 가능하게 만들고 싶은 경우에는 어떻게 해야 될까? 이는 어려운 일이 아니다. 7개의 프라이빗 체인과 연결된 허브가 코스모스 허브와 IBC를 통해 연결되면 문제가 해결된다. 만약, 이 연결이 성사되면, 암호화폐가 지역 허브를 통해 7개의 주의 블록체인에 흘러들어갈 수 있다. 이렇게 IBC를 통해 서로 연결되고, 코인을 교환하는 구조는 커다란 장점을 가진다. 만약, 코스모스 허브가 다운된다고 해도 지역 허브는 여전히 기능을 유지한다. 즉, 코스모스 허브가 다운된 경우 주 정부가 운영하는 7개의 블록체인은 코스모스 허브를 통해 코인을 전송할 수는 없지만, 여전히 그들 간의 코인 및 화폐 교환은 지역 허브를 통해 문제없이 유지된다. 이것이 IBC의 구조의 힘이며, IBC를 통해 각 블록체인은 고유의 주권은 유지한체 다른 블록체인과 상호 운영성을 확보하는 것이 가능해진다.
지금까지 몇 가지 구체적인 예시를 들었다. 코스모스 어플리케이션의 잠재력은 사실상 무한하다. 코스모스는 모듈화 되고, 어디에든 적용 가능하고, 확장성 있게 설계되었다. 코스모스는 블록체인이 한 약속을 세상에 구현하기 위해 존재한다. 당신이 어떤 블록체인을 만들든 간에 당신은 코스모스 위에 이를 쉽게 만들 수 있는 툴을 찾을 수 있을 것이다. 이것은 몇 년 후에 올 미래의 이야기가 아니다, 이 모든 것은 바로 지금 가능한 일들이다.
