1.0 IBC 소개
IBC(블록체인 간 통신) 프로토콜은 블록체인 간 데이터 전송을 표준화하기 위해 개발되고 있습니다. 개별 블록체인이 하나의 행성이라면, IBC는 관련된 모든 이해관계자(네트워크 관리자, 블록 생산자, 블록체인 개발자, 최종 사용자)의 노력을 최소화하도록 설계된 경로를 통해 정보 패킷(packets)을 전송하는 우주 왕복선입니다. 인터넷이 전 세계 다른 지역에 위치한 다양한 종류의 컴퓨터를 연결하듯이, IBC는 신뢰할 수 있고 질서 있고 인증된 정보를 도청(eavesdropping) 없이 한 블록체인에서 다른 블록체인으로 안전하게 전송할 수 있는 슈퍼 고속도로를 만들고자 합니다.
2.0 안텔로프 IBC
안텔로프 IBC는 스마트 컨트랙트를 사용해 구축됩니다. 안텔로프 IBC를 지원하는 블록체인(예: EOS 블록체인) 위에서 실행되는 디앱(dApp)은 IBC 컨트랙트의 특정 액션(Action)을 호출해 다른 안텔로프 IBC를 지원하는 블록체인(예: UX 네트워크)에서 실행되는 다른 디앱과 통신할 수 있습니다. 스마트 컨트랙트인 안텔로프 IBC는 업그레이드뿐만 아니라 감사(Audit)도 쉽습니다. 안텔로프 IBC는 무신뢰성(trustless)을 갖춘 즉각적인 완결성(instant finality)이라는 기능을 채택했습니다.
무신뢰
안텔로프 IBC의 사용자와 개발자는 소스 체인(source chain) 및 목적지 체인(destination chain)의 선출된 활성 블록 생산자(active block producer)의 합의 프로토콜만을 신뢰합니다. 추가적인 제3자에 대한 신뢰는 필요 없습니다.
즉각적인 완결성
안텔로프 블록체인의 블록 생성은 몇 가지 잘 정의된 단계를 따릅니다. 일단, 블록은 제안(proposal)일 뿐 아직 최종적인 것이 아니며, 비잔틴 장애 허용(Byzantine Fault Tolerance)을 충족하지 못하면 다른 블록으로 대체될 수 있습니다. (⅔ + 1) 활성 블록 생성자의 승인을 받으면 최종적이고 되돌릴 수 없는(irreversible) 블록이 됩니다. 현재 안텔로프 블록체인은 제안된 블록이 확정되는 데 180초가 걸립니다. 이러한 긴 블록 확정 시간은 안텔로프 IBC 네트워크에서 디앱 개발에 장애가 됩니다. 이러한 병목 현상을 극복하기 위해 안텔로프 IBC는 즉각적인 완결성이라는 새로운 기술을 개발했습니다. 이 기술이 구현되면 제안된 블록은 몇 초 이내에 블록이 확정되며, 이를 통해 간단한 것부터 복잡한 것까지 다양한 디앱을 개발할 수 있는 길이 열리게 됩니다.
안텔로프 IBC 프로토콜은 다른 안텔로프 IBC 지원 네트워크에서 이벤트가 발생했음을 즉시 증명할 것을 약속합니다. 그림 1에서 볼 수 있듯이 안텔로프 IBC는 두 가지 유형의 증명, 즉 블록 증명(block proof)과 액션 증명(action proof)으로 구성됩니다. 블록 증명은 다시 헤비 증명(heavy proof)과 라이트 증명(light proof)의 두 부분으로 나뉩니다.
그림 1 : 안텔로프 IBC 프로토콜
스마트 컨트랙트는 블록체인이 안텔로프 IBC 프로토콜을 구현할 때 인스턴스화(instantiated) 됩니다. 모든 종류의 애플리케이션(대체 가능한 토큰 전송, 대체 불가능한 토큰 전송, 크로스 체인 계정 생성 및 유지 관리, 크로스 체인 쿼리 등)을 안텔로프 IBC 위에 구축할 수 있습니다. 스마트 컨트랙트가 설정되면 사용자는 단일 증명(single proof) 또는 여러 체계(scheme)의 조합을 사용해 IBC를 통해 통신합니다.
안텔로프 IBC 프로토콜을 채택한 블록체인 네트워크는 다음과 같습니다:
3.0 코스모스 IBC
코스모스 IBC는 크게 그림 2와 같이 전송 레이어(transport layer)과 애플리케이션 레이어(application layer)으로 나뉩니다.
그림 2 : 코스모스 IBC의 기본 레이어
코스모스 IBC를 통해 전달되는 메시지는 데이터 패킷 내에서 암호화되며, 전송 레이어를 통해 주문, 인증 및 전송됩니다. 전송 레이어의 주요 구성 요소는 그림 3에 나와 있습니다.
그림 3 : 코스모스 IBC 전송 레이어의 주요 구성 요소
코스모스 IBC의 라이트 클라이언트(lite client)는 블록체인에 존재하는 모든 메시지의 전체 기록을 저장하지 않습니다. 대신 노드에 연결해 블록 헤더를 확인합니다. 사용 가능한 다양한 유형의 라이트 클라이언트가 그림 4에 나와 있습니다.
그림 4 : 코스모스 IBC의 라이트 클라이언트
단일 기기(휴대폰, 노트북, 브라우저 등)들은 솔로 머신 클라이언트(Solo Machine Client)를 사용해 IBC 지원 머신에 연결할 수 있습니다.
텐더민트(Tendermint) 합의 알고리즘을 사용하여 복제된 스테이트 머신(state machines)은 텐더민트 클라이언트(Tendermint Client)를 사용하여 복제된 다른 스테이트 머신 또는 솔로 머신과 인터페이스할 수 있습니다.
WASM 클라이언트(Wasm clients)는 동적으로 업그레이드할 수 있는 클라이언트입니다.
GRANDPA(GHOST-based Recursive Ancestor Deriving Prefix Agreement) 클라이언트는 다른 스테이트 머신 또는 솔로 머신과 통신하기 위해 GRANDPA 최종성 가젯(gadget)을 사용하는 블록체인으로 구현할 수 있습니다.
릴레이어(relayer)는 IBC 프로토콜로 통신하는 다른 원장(ledgers)의 스테이트를 검색하고 트랜잭션(transactions)을 게시할 수 있는 오프-체인(off-chain) 프로세스입니다. 릴레이어는 각 체인에 자금이 있는 계정과 연결되어야 합니다. 여러 체인을 연결하려면 각 체인 쌍마다 하나의 릴레이어를 사용해야 합니다.
커넥션 시맨틱(Connection semantics)은 다른 체인의 라이트 클라이언트를 가진 두 체인 간에 안전한 연결을 설정하는 프로토콜입니다.
채널 및 패킷 시맨틱(Channel and Packet semantics)은 IBC 프로토콜에 메시지 전달 메커니즘을 제공합니다. 각 채널은 특정 연결과 관련되며, 연결에는 원하는 만큼의 채널을 추가할 수 있습니다.
서로 다른 유형의 모듈 간의 포트 할당은 포트 할당(Port allocation) 알고리즘에 의해 결정됩니다. IBC 모듈에는 원하는 만큼의 포트를 할당할 수 있습니다.
블록체인의 스테이트 머신은 벡터 커미트먼트(vector commitment)의 관리자 역할을 합니다. 스테이트 머신은 커미트먼트(commitment)에서 항목을 추가하거나 제거할 수 있는 권한과 책임이 있습니다.
호스트 스테이트 머신 요구 사항(Host State Machine Requirements)은 구현해야 하는 최소 인터페이스 세트와 스테이트 머신이 충족해야 하는 속성을 정의합니다.
IBC 핸들러(IBC handler) 인터페이스는 IBC 클라이언트, 연결, 채널 및 패킷 릴레이를 처리하는 메서드(methods)로 구성됩니다.
라우팅 모듈(routing module)은 외부 데이터그램(datagrams)을 수락하고 핸드셰이크(handshakes) 및 패킷 릴레이를 처리하기 위해 IBC 핸들러로 호출합니다.
애플리케이션 레이어는 패킷 인코딩 및 처리 시맨틱을 설명합니다. 그림 5는 IBC의 다양한 애플리케이션을 보여줍니다.
그림 5 : 코스모스 IBC 프로토콜의 어플리케이션 레이어
IBC의 가장 중요한 적용 분야는 체인 간 대체 가능한 토큰 전송(fungible token transfer)입니다. 이 표준(standard)을 통해 사용자는 추가 허가(permissioning) 없이도 한 IBC 지원 체인에서 다른 IBC 지원 체인으로 자산을 전송할 수 있습니다.
인터체인 계정(Interchain account)은 크로스체인 계정 관리 프로토콜로, 특정 IBC 지원 체인의 사용자가 네이티브 시스템과 동일한 방식으로 다른 IBC 지원 체인의 계정을 생성하고 제어할 수 있습니다.
체인 간 보안은 크로스 체인 검증(cross-chain validation)을 통해 유지됩니다. 이를 통해 공급자 체인(provider chain)이 여러 소비자 체인(consumer chains)에 보안을 제공할 수 있습니다.
제너럴 릴레이어 인센티브 메커니즘(General Relayer Incentivisation Mechanism)은 IBC 외에 수수료 지불에 사용 됩니다.
IBC 애플리케이션 미들웨어(IBC Application Middleware)는 코어 IBC와 언더라인(underline) 애플리케이션 간의 미들웨어로 제대로 작동하기 위해 모듈이 구현해야 하는 인터페이스와 스테이트 머신 로직을 포함합니다.
크로스 체인 쿼리 모듈(Cross chain query module)은 IBC 지원 체인 간에 크로스 체인 쿼리를 수행할 수 있는 데이터 구조와 스테이트 머신 로직을 포함합니다.
대체 불가능한 토큰 전송 모듈(Non-fungible Token transfer module)은 대체 불가능한 토큰을 특정 IBC 지원 체인에서 다른 IBC 지원 체인으로 전송하기 위한 데이터 구조, 스테이트 머신 처리 로직 및 인코딩 프로세스로 구성됩니다.
코스모스 IBC를 구현한 블록체인은 다음과 같습니다:
4.0 안텔로프 IBC 및 코스모스 IBC 비교
기준 | 안텔로프 IBC | 코스모스 IBC |
크로스-체인 확인 | 즉시 | 즉시 |
무신뢰 | 무신뢰 | 무신뢰 |
적용 가능 | 모든 블록체인 | 모든 블록체인 |
개발 가능한 애플리케이션 | 대체 가능한 토큰 전송, 대체 불가능한 토큰 전송, 크로스체인 계정 생성 및 유지 관리, 크로스체인 쿼리, 토큰 유틸리티 단편화 등과 같은 기능을 사용하는 모든 유형의 디앱. | 대체 가능한 토큰 전송, 대체 불가능한 토큰 전송, 크로스 체인 계정 생성 및 유지 관리, 크로스 체인 쿼리 등과 같은 기능을 사용하는 모든 유형의 디앱. |
가스 수수료 | 매우 낮음 | 낮음 |
확장성 | 다수의 체인 연결 가능 | 다수의 체인 연결 가능 |
5.0 결론
고립 된 블록체인들 사이에 길을 만드는 블록체인 간 통신인 IBC는 블록체인 개발의 차세대 물결입니다. 안텔로프 IBC와 코스모스 IBC 외에도 많은 다른 크로스 체인 커뮤니케이션 프로토콜(맵, 레이어제로, 셀러 등)이 있습니다. 앞으로 안텔로프 연합(Antelope coalition)은 IBC를 적용할 수 있는 인프라를 갖춘 블록체인만 받아들일 것입니다.
작성자: Sukanta Manna
편집자: Markus Hinrichs; Randall Roland; Thian
옮긴이: Terry Jin
출처 및 참고문헌: