Author
Jooman Han
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Devops Engineer, a41(@ a41-ventures)
Reviewed By 정재환
[IBC Research]
- Cosmos IBC Process
- IBC Handshake & 트랜잭션 검증
- ICA & IBC query
목차
- Intro
- ICA — Interchain Account
- IBC Query
- 정리
1. Intro
우리가 상대방과 대화하기 위해서는 우리가 사용하는 언어가 상대방이 이해할 수 있는 언어라는 점이 전제로 해야 합니다. 인터넷상에서도 데이터를 전달하기 위해서 우리가 사용하는 통신 방식이 누군지 모르는 상대방도 이해할 방법이라는 점이 전제로 해야 합니다.
TCP/IP 프로토콜을 기반으로 데이터를 원하는 곳으로, 높은 신뢰도를 가지고 전달할 수 있게 되었고, 통일된 통신 규약인 TCP/IP를 기반으로 우리가 매일 쓰고 있는 HTTP, HTTPS와 같은 프로토콜이 등장하여 지금과 같이 모두가 널리 사용하는 편한 인터넷이 되었습니다.
이러한 인터넷 발전의 역사를 블록체인으로 확장해 보았을 때, 블록체인 간 서로 통신할 수 있는 프로토콜 IBC의 발전은 중요한 의미를 가지며, 통일된 IBC 규약 위에서 이를 사용하는 또 다른 프로토콜이 등장하여 더 깊은 의미의 상호운용성을 전달할 수 있을 것이라 기대할 수 있습니다.
지금까지 앞 서 글에서 설명한 IBC 기술을 인터넷의 측면에서 해석해보면 IBC 또한 마치 TCP/IP와 같이 체인 간 연결을 위한 레이어와, HTTP/HTTPS과 같이 Application을 위한 레이어로 나뉘어 있는데 이는 이전 글에서 봤던 아래 그림에서 각각 IBC/TAO와 IBC/APP 레이어로 확인할 수 있습니다.
참고로 IBC/TAO의 ‘TAO’ 는 전송(Transport), 인증(Authentication), 순서(Ordering) 의미하며, 체인간 통신을 위한 기술 계층을 의미합니다.
시리즈 1,2편에서는 IBC 가 무엇인지, 어떻게 동작하는지, 또한 기술적으로 어떻게 Trustless 하다고 할 수 있는지 이해했습니다. 이번 글에서는 IBC 프로토콜을 기반으로 한 Application 레이어인 ICA와 IBC-query를 설명하겠습니다.
2. ICA — Interchain Accounts
2.1. 배경
최근 몇 년 사이에 Defi 분야는 빠른 속도로 성장을 하였습니다. 다양한 서비스가 내보냈고, 새로운 시도들이 많이 이뤄졌습니다. 또한 기술의 성숙과 동시에 당연하게도 서비스의 복잡성도 증가 했으며, 기존 서비스와 달리 서비스 간 결합성(Composability)와 상호운용성이 굉장히 중요해졌습니다.
코스모스 생태계도 이런 흐름 속에서, 단순히 IBC를 통한 토큰 전송 뿐만 아니라 더 큰 의미의 상호운용성과 결합성을 제공할 방법이 필요했고 이런 배경 속에서 ICA 기술이 등장했습니다.
2.2. ICA란?
ICA란 IBC 프로토콜을 기반으로 다른 체인의 주소를 컨트롤 할 수 있는 기술입니다. 예를 들면, 주노 체인에서 오스모시스 체인의 어카운트를 통해서 DEX를 이용하거나 혹은 반대로 오스모시스 체인에서 주노 체인의 스마트 컨트랙트를 실행할 수도 있습니다. ICA 기술은 더 중요도가 높아진 상호운용성과 체인 간 결합성을 사용자들에게 전달할 수 있습니다.
2.3. 구조
위 그림처럼 ICA의 구조는 기존의 IBC/APP 모듈과 차이가 있습니다.
기존의 IBC /APP 모듈의 경우 타 체인에서 사용할 모듈의 기능이 IBC 모듈 내에 정의되어 있어야 했습니다. 즉, IBC 모듈 내에서 어떤 모듈을 사용해야 할지 정해져 있었습니다. 하지만 ICA의 경우 트랜잭션을 받은 IBC 모듈은 단순히 Account에 트랜잭션을 전달만 해줍니다. 이후의 실행에 대한 책임은 온전히 체인과 Account에 할당합니다.
이런 구조는 합리적이라 생각되는데, 앱체인들의 업데이트가 빠르게 이뤄지는 코스모스 생태계에서 ICA 모듈의 의존성을 최소화하여 업데이트 시에도 다양한 메시지들을 지원할 수 있도록 하기 위한 구조로 이해할 수 있습니다.
2.4. 동작 방식
ICA의 동작 방식을 보기 앞서서 주요 용어를 정의하겠습니다.
- Host chain: Interchain Account가 등록되는 곳, 컨트롤러 체인이 보내는 IBC 패킷을 받고 있음.
- Controller chain: 호스트 체인에 어카운트를 등록하는 체인, Authentication module을 가지고 있어야 함.
- Authentication Module: Interchain Accounts의 생성 및 관리를 위한 로직이 담겨 있음. Authentication 모듈은 필수적으로 1) Interchain Account의 소유자임을 인증해야 하며, 2) 소유자와 관련된 ICA를 찾고, 3) IBC 요청을 보낼 채널이 사용 가능한지 확인함.
- Interchain Account: 호스트 체인에 있는 계정, 특정 트랜잭션에 사인하지 않고 컨틀롤러 체인의 Authentication 모듈이 보낸 트랜잭션을 수행하는 역할을 함.
ICA 기능을 사용하기 위해서 먼저 Interchain Account을 생성하는 과정을 거쳐야 합니다. 이 과정이 종료되면, 컨트롤러 체인과 호스트 체인은 각각 ICA에 관한 정보를 가지게 됩니다. 해당 과정은 다음과 같은 순서로 진행됩니다.
- User와 트랜잭션을 보냄.
- Authentication 모듈로 전달된 요청은 ICA 모듈의 RegisterInterchainAccount 요청을 실행함.
- RegisterInterchainAccount 요청을 실행할 때, 컨트롤러 체인은 새로운 포트를 생성하고 소유자와 포트를 연결하여 기록함.
- 호스트 체인에서는 요청을 받으면 ICA를 생성하고 포트 번호와 ICA 계좌를 연결해서 기록함. (여기서 포트 번호는 IP, Port 개념과 다른 고유의 개념입니다.)
- InterChain Account는 일반적인 계좌와 다르게, ICA 모듈 계좌의 서브 계좌로 구현함.
특이한 점은 서브 계좌로 구현되는 특징 때문에 오로지 컨트롤러 체인에 의해서만 작동한다는 점입니다. 서브계좌는 시드 구문이나 개인키 같은 정보를 알 수 없기 때문에, 누군가 호스트 체인의 ICA 계정을 무단으로 이용할 수 없습니다.
위 과정을 통해 Controller chain의 소유자와 Interchain Account를 연결할 수 있게 됩니다.
다음으로는 실제 명령 실행 과정을 살펴보도록 하겠습니다. 계정 등록이 완료되면, 소유자는 자신의 Interchain Account로 실행할 트랜잭션의 Raw 파일을 보내게 됩니다.
ICA 데모 실행 과정 중 아래 트랜잭션을 예시로 보시면 쉽게 이해할 수 있습니다. intertx 모듈의 submit이라는 명령어를 통해 sendTx를 실행하게 되는데, 인자로서 Hostchain에서 실행할 트랜잭션의 정보를 입력하게 됩니다.
# Submit a staking delegation tx using the interchain account via ibc
icad tx intertx submit \
'{
"@type":"/cosmos.staking.v1beta1.MsgDelegate",
"delegator_address":"cosmos15ccshhmp0gsx29qpqq6g4zmltnnvgmyu9ueuadh9y2nc5zj0szls5gtddz",
"validator_address":"cosmosvaloper1qnk2n4nlkpw9xfqntladh74w6ujtulwnmxnh3k",
"amount": {
"denom": "stake",
"amount": "1000"
}
}' --connection-id connection-0 --from $DEMOWALLET_1 --chain-id test-1 --home ./data/test-1 --node tcp://localhost:16657 --keyring-backend test -yHost chain에서 허용한 메시지 타입인지 검사를 한 후 일반적인 트랜잭션과 동일하게 전달받은 메시지를 Interchain Account가 실행하게 됩니다.
3. IBC query
3.1 배경
ICA 기능은 IBC를 사용해 Token Transfer만 가능했던 코스모스 생태계에 상호운용성과 결합성을 제공할 수 있게 됐습니다.
하지만 ICA를 사용한 Use-case들을 구현하다 보니 자연스레 상대방이 어떤 상태인지 알아야 요청을 보낼 수 있는 상황들이 많이 생겼고, IBC를 통해서 이를 해결하고자 하는 논의가 이어졌습니다.
3.2 IBC query란?
IBC query란 IBC 프로토콜을 기반으로 다른 체인의 상태를 확인할 수 있는 기능을 의미합니다. 예를 들어 이 기술을 사용하면 주노체인에서 오스모시스 거래소의 토큰 가격을 query 할 수 있게 됩니다.
하지만 아직 IBC query는 글을 작성하는 시점에도 스펙에 대한 논의가 활발하게 이뤄지고 있기 때문에 이 글에서는 현재까지 논의된 내용을 정리하도록 하겠습니다.
3.3 ICS-031
논의 되고 있는 구조는 다음과 같습니다.
- Query를 요청하는 체인은 sendQuery 이벤트를 발생시킴.
- 릴레이어는 위 이벤트를 Query를 받는 체인으로 전달함.
- 데이터를 검색하고, proof를 생성하여 Query를 요청한 모듈로 전달됨.
특별한 점은 Query 요청결과는 블록 높이를 포함하여 결과가 어느 시점에 유효한 데이터인지 확인할 수 있게 합니다. 또한 relayer에 의해 데이터가 조작될 수 있는 가능성을 차단할 수 있습니다.
또 디자인 시 고려해야하는 속성으로 다음과 같은 내용이 논의 중 입니다.
- Permissionless: 쿼리하는 체인은 제 3자의 허가 또는 합의 없이도 쿼리할 수 있어야 함.
- Minimum Querying Chain Work: 쿼리를 받는 체인은 크로스 체인 쿼리를 위해 추가적인 구현이나 추가적인 모듈이 필요 없어야 함 . (이는 RPC client, relayer를 이용하여 가능함)
- Modular: 크로스 체인 쿼리를 붙이는 것은 모듈을 붙이는 것 만큼 쉬워야 함
- Control Queried Data: 쿼리하는 체인이 쿼리 데이터를 컨트롤할 수 있는 모든 권한을 가져야 함
- Incentivization: 릴레이어한테 충분한 보상이 되어야 함.
위 내용을 요약해 보면, 쿼리하는 체인에서는 RPC client와 relayer를 사용해서 추가적인 구현 없이 상대방 체인의 데이터를 검색할 수 있게되며, 이에 대한 쿼리 결과는 Cross-chain query모듈에서 관리하는 방식으로 구현될 것이라 생각해볼 수 있습니다.
ICA와 함께 IBC query가 가능해진다면 코스모스 체인에 더 깊은 상호운용성 경험을 선사할 것으로 보입니다.
4. 정리
지난 몇 년간 빠르게 발전한 기술과 새로운 시도들로 인해서 블록체인간 상호운용성과 결합성이 어느 때보다 중요해지고 있습니다. 이러한 배경 속에서 코스모스 생태계도 IBC 기술을 기반으로 한 ICA와 IBC query를 통해 확장된 블록체인 사용 경험을 제공하기 위해 노력하고 있습니다. 아직 위 기술들이 활발하게 사용되는 프로젝트는 많지 않지만, 기술이 성숙해 나가면서 어떤 식으로 다양한 Use-case가 나올 수 있을지 공부해 가면 좋을 것 같습니다.
