고정훈 | researcher of CURG | kjh24871@naver.com
블록체인 기술은 항상 어떤 문제를 해결하기 위한 솔루션이 나오면서 발전해 왔다. 특히 이더리움의 스마트 컨트랙트는 기존의 코인 거래만 가능했던 비트코인의 단점을 해결하면서 블록체인 2.0시대를 만들었다. 앞으로의 블록체인 기술 또한 새로운 문제를 해결하기 위한 방향으로 발전될 것이다. 체인들이 다양해지고 확장성 문제에 대한 솔루션으로 체인들 간의 데이터를 주고받는 것이 새로운 문제로 떠올랐다. 이에 크로스 체인 프로젝트와 인터 체인 프로젝트가 생겨났다. 이 글에서는 대표적인 인터 체인 프로젝트인 Cosmos(코스모스) 체인의 IBC 프로토콜과 크로스 체인 Bridge와 같이 다른 체인과의 상호작용하는 방법을 분석한다.
내 토큰을 다른 체인에서 사용하고 싶은 경우 크게 3가지 방법이 있다.
- 거래소교환
- Bridge
- Interchain
거래소 교환
가장 원시적인 방법으로, 거래소에서 교환하는 방법이다.
기본적으로 서로 다른 체인 간의 교환은 브릿지 없이 가능하다. 거래소에서 내가 가진 토큰을 팔고 다른 체인의 토큰을 사면 된다. 하지만 이 방법에는 많은 수수료와 시간이 걸린다. 또한 중간에 법정 화폐로 변환해야만 하는 아쉬움이 있다. 법정 화폐에 대한 의존성이 높아질수록 암호 화폐의 필요성이 낮아지기 때문이다.
Bridge
브릿지는 말 그대로 교량이란 뜻으로 각각의 체인의 교량 역할을 해준다.
브릿지에서 가장 많이 사용되는 방식은 Lock & Mint 방식이다.
Lock & Mint 방식의 흐름은 다음과 같다
- A 체인에서 토큰을 동결시키고 브릿지에 트랙잭션를 넘긴다
- 브릿지는 A 체인에서 보낸 토큰의 수량과 종류를 확인하고 B 체인에 해당 토큰과 알맞은 수량과 종류를 B 체인에 Minting 할 것을 요청한다
- B 체인은 A 체인의 토큰의 가격과 똑같이 페깅된 토큰을 B 체인에 minting 하는 트랙잭션을 보낸다.
- 이 트랙잭션이 유효하다고 검증되면 B 체인에 A 체인과 같은 가치의 토큰을 발행한다.
Wrapped 종류의 토큰들이 브릿지를 통해 넘어온 토큰이다. WETH(Wrapped Ethereum)는 이더리움 토큰에 1 : 1 비율로 페깅되어 넘어온 토큰이라고 생각하면 된다.
브릿지 프로젝트에서 가장 중요한 부분은 당연히 보안성이다. 하지만 현재 역설적이게도 브릿지 프로젝트에서 가장 큰 문제점도 보안성이다.
지난 1일에도 크로스 체인 브릿지 노마드는 2억(한화 2941 억 원) 상당의 해킹 피해를 입었다. 그 외에도 수없이 많은 브릿지 프로젝트가 해킹에 의해 무너지는 사례들이 있다. 반복되는 브릿지 프로젝트 해킹 사례에 사용자들의 신뢰도는 떨어지고 있는 상황이다.
IBC (Inter Blockchain Communication) Protocol
기본적으로 IBC 프로토콜의 교환 방식은 Lock & mint 방식과 동일하다. 하지만 상대 체인과 소통하는 방법에서 차이가 있다.
IBC는 TCP 구조의 많은 영향을 받은 만큼 그 구조가 매우 흡사하다. 각 체인의 IBC 모듈에는 고유한 포트와 Client, Channel, Connection이 있어서 포트에 채널을 연결시켜 두 체인의 상호작용을 가능하게 한다. 패킷은 채널을 타고 전달되며 패킷의 전송에는 릴레이어가 반드시 등장한다. 서로 다른 체인에서는 직접 데이터를 전송할 수 없기 때문에 릴레이어가 메세지가 담긴 패킷을 받아 상대 체인에 전달하는 역할을 수행한다. A체인에서 B체인으로 전송하는 트랙잰셕이 발생하면 릴레이어가 이를 캐치해 메세지를 가로채는 방식이다. 하지만 현재 IBC에는 릴레이어에 대한 리워드가 정의되어 있지 않은 상황이다. 릴레이어는 일정량의 grant를 요구하는 거버넌스를 제출하는 방식으로 리워드를 제공받아야 하는 번거로움이 있다.
패킷의 메세지 내용은 Lock & mint 방식과 동일하다. A 체인의 토큰을 동결시키고 그만큼 상응한 B 체인의 토큰에 mint하는 방식이다.
검증 방식과 라이트 클라이언트
일반적으로 체인의 블록을 검증하고 채굴하는 노드들, 즉 풀 노드는 자신이 갖고 있는 DB에 넣어 조회함으로써 이를 검증할 수 있습니다. 그런데 풀 노드는 그런 개별 검증 이외에 새로 추가될 블록 전체를 검증하여 체인 전체를 관리하기 때문에 모든 스테이트와 트랜잭션을 DB에 가지고 있기에 내가 검증하고 싶은 트랙잭션만 검증하기에는 너무 비효율적으로 작동했다. 그러다 보니 자신이 관심 있는 트랜잭션 과 스테이트만 확인하는 일에만 특화시킨 경량화된 노드가 필요해지게 되었고, 이를 라이트 클라이언트라고 부른다.
IBC는 상대 체인의 스테이트에 내 패킷이 반영됐는지만 확인하면 되는 것이기 때문에 이는 통상적으로 쓰이던 ‘라이트 클라이언트’가 원래 다루던 문제와 정확히 일치했기에 라이트 클라이언트 방식을 그대로 채택했다. IBC는 상대 체인의 라이트 클라이언트를 필요로 하며, 이러한 방식을 잘 구현한다면 상대방의 풀 노드를 돌리는 과정 없이 빠르고 가볍게 검증을 할 수 있게 된다.
무엇이 다를까?
확장성
IBC의 경우 확장성에 엄청난 강점이 있다.
코스모스 체인은 코스모스 Hub에 다양한 Zone이 연결되어 있는 구조이다. Zone 이란 코스모스 SDK로 구현된 다양한 체인들이고 Zone들은 허브를 통해서 서로 상호작용할 수 있다. IBC에 참여하고자 하는 체인들은 검증을 위해 서로의 모든 라이트 클라이언트를 구현해야 한다. 즉, IBC에 참여하는 N 개의 체인들은 그물망 구조로 N*(N-1) 개의 라이트 클라이언트를 구현해야 한다는 소리이다. 하지만 코스모스 Hub는 허브 체인과 Zone 체인들을 중개해 주는 역할을 수행하며 위 그림의 구조로 Zone 체인은 Hub 체인과만 직접적으로 IBC를 수행한다면 2*N 개의 라이트 클라이언트 구현으로 모든 IBC 통신을 가능케 한다. 참여하는 체인의 수가 늘어날수록 Hub 구조의 장점은 더욱 뚜렷해진다.
또한, Bridge에서는 토큰의 전송만을 위한 프로젝트였다면 IBC는 22년 1분기에 ICA(Interchain Account)라는 다른 체인에서 계정을 컨트롤할 수 있는 모듈을 제공하면서 더욱 다양한 방식의 접근이 가능해졌다. 이를 통해 IBC로 더 이상 토큰 전송만 하는 것이 아니라 새로운 서비스로 확장될 수 있다는 것이다.
보안성
Bridge 방식의 경우에는 두 체인이 안정적이라도 브릿지 자체가 보안에 취약하면 해킹의 위험에 처할 수밖에 없다. 브릿지에 사용되는 노드 수가 이더리움과 비트코인같이 큰 규모가 아니기 때문에 어쩔 수 없이 보안성 문제가 대두된다. 이 문제가 브릿지 프로젝트의 해결할 수 없는 가장 큰 취약점으로 꼽힌다. 하지만 IBC 프로토콜의 경우에는 두 체인이 안전하다면 safety한 결과가 도출된다. 중간의 릴레이어는 패킷의 전송에만 가담할 뿐 그 안의 내용을 임의로 바꿀 수 없기 때문이다. 그렇다고 IBC가 보안성이 완벽하다는 것은 아니다. IBC의 경우, 한 체인이 safety 하지 않다면 IBC를 통해서 다른 체인들을 공격하면서 보안성이 전염될 수 있는 가능성이 생긴다.
이에, 노먼 코헨(인터 체인 디벨로퍼 총괄)은 올해 안으로 코스모스 체인에서 Interchain Security 기능을 출시하겠다고 밝혔다. 기존 체인 공격이 IBC를 통해 확산되는 것을 방지하는 기능이라고 설명했다.
개발 속도
코스모스의 텐더민트 코어는 P2P 네트워킹 층과 합의 층을 일반 엔진으로 묶어 개발자가 복잡한 기본 프로토콜이 아닌 디앱 개발에 집중할 수 있도록 지원하는 솔루션이다. 즉 개발자들은 네트워크 층과 합의 층을 구현할 필요 없이 애플리케이션 부분만 구현하면 되는 것이다. 또한 애플리케이션 부분도 코스모스 SDK를 제공해 모두 모듈화되어 있어서 개발자들의 진입 장벽이 엄청나게 낮아졌다. IBC 또한 모듈러화 되어 있기 때문에 개발 속도 측면에서 Bridge 프로젝트와 엄청난 차이가 있다.
블록체인 판의 성장에 따라 수많은 체인이 생겨남에 따라 체인 간의 Communication의 문제는 점점 더 중요해질 것이다. 체인끼리의 소통에는 보안성이 가장 중요한 문제로 대두되는 만큼 IBC와 Bridge 방식 모두 보안성 문제에 심혈을 기울여야 할 것이다. 앞선 설명으로 현재 브릿지 프로젝트 구조에 문제점들에 대해 생각해 보면서 코스모스 IBC 프로토콜에 눈이 갈 수밖에 없었다. IBC 프로토콜의 다양한 도전에 박수를 보내주고 싶다. 모듈화를 통해 개발자들의 진입장벽이 낮아진 점은 분명 코스모스 생태계의 큰 파워로 치환될 것이다. 이미 코스모스 생태계의 주요 체인들은 IBC를 지원하고 있고 점점 더 많은 체인들이 코스모스 생태계에 들어 올 것 이다. 앞으로의 상황을 그려볼 때 코스모스의 IBC는 웹 3.0 환경에서 큰 역할로 자리매김 할 수 있을 것 같다는 생각이 든다.
