Cosmos SDK의 IBC Overview 번역입니다. 오역 발견 시 피드백 주시면 감사드리겠습니다.
IBC가 무엇인지, IBC의 컴포넌트와 사용 사례에 대해 알아보겠습니다.
IBC (Inter-Blockchain Communication) 프로토콜
이 문서는 IBC 앱 개발자를 위한 가이드입니다.
IBC 프로토콜의 모듈식 설계는 IBC 앱 개발자가 클라이언트, 연결 및 증명 검증의 하위 레벨 세부 사항에 대한 심층적 지식을 필요로 하지 않게 합니다. 애플리케이션 개발자가 IBC 프로토콜을 전반적으로 이해할 수 있도록 하위 레벨 스택에 대한 간략한 설명이 제공됩니다.
채널 및 포트의 추상화 계층 세부 정보는 앱 개발자와 관련있는 영역입니다. 개발자는 사용자 지정 패킷 및 IBCModule 콜백을 정의할 수 있습니다.
모듈이 IBC를 통해 상호 작용하려면 다음 요구 사항을 충족해야 합니다.
- 하나 이상의 포트에 바인딩합니다.
- 패킷 데이터를 정의합니다.
- 추가적으로 승인 구조체와 구조체를 인코딩, 디코딩할 수 있는 메서드를 정의합니다.
- IBCModule 인터페이스를 구현합니다.
Component Overview
이 섹션에서는 IBC 컴포넌트에 대해 설명합니다.
Client
IBC 클라이언트는 고유한 클라이언트 ID로 식별되는 라이트 클라이언트입니다. IBC 클라이언트는 클라이언트 합의 상태 증명을 검증하는데 필요한 다른 블록체인의 합의 상태와 그 증명을 추적합니다. 클라이언트는 여러 체인에 원하는 만큼 연결할 수 있습니다. 지원되는 IBC 클라이언트는 다음과 같습니다.
- Solo Machine light client: devices such as phones, browsers, or laptops.
- Tendermint light client: The default for Cosmos SDK-based chains.
- Localhost (loopback) client: Useful for testing, simulation, and relaying packets to modules on the same application.
Connections
Connection 컴포넌트는 두 블록체인의 ConnectionEnd 객체를 캡슐화한 것입니다. 각 ConnectionEnd는 다른 블록체인의 클라이언트 (상대방 블록체인)와 연결됩니다. connection handshake에서 각 체인의 라이트 클라이언트는 상대방이 올바른지 확인하는 역할을 합니다. 연결이 설정되면 IBC 상태에 대한 cross-chain 검증이 용이하도록 지원할 책임이 생기며, 원하는 만큼 다수의 채널과 연결할 수 있습니다.
Proofs and Paths
IBC에서 블록체인은 네트워크를 통해 직접 메시지를 전달하지 않습니다.
- 블록체인은 정의된 특정 메시지 유형 및 특정 상대방을 위해 예약된 경로로 상태를 커밋합니다. 예를 들어, handshake의 일부 정보로 connectionEnd를 저장한 블록체인이나 상대방 체인의 모듈에 전달하기 위한 패킷 등입니다.
- 릴레이 프로세스는 경로에 대한 업데이트를 모니터링하고 해당 데이터의 증명과 함께 경로에 저장된 데이터를 상대방 체인에 제출하여 메시지를 릴레이합니다.
- IBC 메시지를 커밋하기 위해 IBC 구현체에서 지원해야 하는 경로는 ICS-24 host requirements에 정의되어 있습니다.
- 구현체에서 증명 생성과 검증을 위한 포맷은 ICS-23 implementation에 정의되어 있습니다.
Capabilities
IBC는 모듈이 서로에 대한 신뢰가 필요하지 않은 실행 환경에서 작동하도록 설계되었습니다. 적합한 권한이 있는 모듈만 채널을 사용할 수 있도록 IBC가 포트 및 채널에 대한 모듈 작업을 인증해야 합니다. 이 보안은 dynamic capabilities를 사용하여 수행됩니다. 포트에 바인딩하거나 모듈의 채널을 만들 때 IBC는 모듈이 해당 포트 또는 채널을 사용하기 위해 할당해야 하는 dynamic capabilities을 반환합니다. 이 바인딩 전략은 적절한 기능을 소유하고 있지 않은 모듈이 해당 포트나 채널을 사용하는 것을 방지합니다.
IBC는 하위 레벨의 추상화된 부분과 상호 작용할 필요가 없습니다. IBC 애플리케이션 개발자는 채널과 포트의 추상화 계층에만 관심을 가져도 됩니다.
IBC 애플리케이션 자체 모듈로 작성합니다. 블록체인 모듈은 다른 블록체인 모듈과 유니크한 (channelID, portID) 쌍으로 구분되는 채널을 통해 전송, 수신, 패킷 승인 등의 통신을 할 수 있습니다.
IBC 모듈을 인터넷 앱과 비교해봅시다. 채널은 IP 연결의 개념이고, IBC 포트 ID는 IP 포트와 같고, IBC 채널 ID는 IP 주소와 같습니다. IBC 모듈의 단일 인스턴스는 여러 모듈들과 동일한 포트로 통신할 수 있으며, IBC는 (channelID, portID ) 쌍을 이용하여, 관련있는 모듈에 패킷을 정확하게 전달합니다. IBC 모듈은 (portID <-> portID)패킷 스트림을 전송하여 다른 IBC모듈과 멀티 포트로 통신할 수 있습니다.
Ports
IBC 모듈은 원하는 수 만큼 포트에 바인딩할 수 있습니다. 각 포트는 고유한 portID로 구분됩니다. IBC는 동일 원장에서 작동하는 상호 신뢰가 필요없는 모듈로 보안을 확보하도록 설계되어있기 때문에, 바인딩된 포트는 dynamic object capability를 반환합니다. 예를 들어 특정 포트에 대해 어떠한 작업을 처리하기 위해 portID로 채널을 열었을 때, 모듈은 IBC 핸들러로 dynamic object capability를 제공해야합니다. 이 요구 사항은 악의적인 모듈이 자신이 소유하지 않은 포트를 사용하여 채널을 여는 것을 방지합니다.
IBC 모듈은 요청받은 경우, BindPort에 대해 capability를 반환할 책임이 있습니다.
Channels
두 IBC 포트 사이에 IBC 채널을 설정할 수 있습니다. 포트는 하나의 모듈이 독점적으로 소유합니다. IBC 패킷은 채널을 통해 전송됩니다. IP 패킷에 대상 IP 주소, IP 포트, 소스 IP 주소 및 IP 포트가 포함된 것과 마찬가지로 IBC 패킷은 대상 portID, channelID, 소스 portID 및 channelID 를 포함합니다. IBC 패킷은 패킷을 대상 모듈로 올바르게 라우팅하면서, 패킷 수신 모듈이 발신 모듈을 확인할 수 있도록 정보를 제공합니다.
- 채널이
ORDERED인 경우, 송신 모듈의 패킷은 전송된 순서대로 수신 모듈에서 처리되어야 합니다. - 추천되는 방식인
UNORDERED의 경우,송신 모듈의 패킷은 수신 모듈에 전송된 순서대로 처리되며, 송신 모듈에서 발신한 순서가 보장되지 않습니다.
모듈은 통신할 채널을 선택할 수 있습니다. IBC는 모듈이 채널 handshake 도중에 호출되는 콜백을 구현하였을 것으로 예상합니다. 구현된 콜백을 사용하여 커스텀 채널 초기화 로직을 수행할 수 있습니다. 콜백에서 오류가 반환되면 채널 handshake가 실패합니다. 콜백에서 오류를 반환함으로써 모듈은 채널을 거부하거나 수락할 수 있습니다.
채널 handshake는 4단계로 진행됩니다. 간단한 예로, 주어진 체인 A가 이미 설정된 연결을 사용하여 체인 B가 있는 채널을 열려는 경우,
- 체인 A는
ChanOpenInit메시지를 보내 체인 B와 채널 초기화를 시도합니다. - 체인 B가
ChanOpenTry메시지를 보내 체인 A와 채널 열기를 시도합니다. - 체인 A는
ChanOpenAck메시지를 보내 채널 종료 상태를 열림 상태로 표시합니다. - 체인 B는
ChanOpenConfirm메시지를 보내 채널 종료 상태를 열림으로 표시합니다.
이 모든 작업이 성공적으로 수행되면 채널은 양쪽에서 모두 열립니다. handshake의 각 단계에서 ChannelEnd와 연결된 모듈은 handshake의 해당 단계에 대해 콜백을 실행합니다. 즉, ChanOpenInit 시, 체인 A의 모듈은 콜백 OnChanOpenInit을 실행합니다.
포트가 dynamic copability와 함께 제공되었듯이, 채널 초기화는 패킷 전송과 같은 채널 작업을 인증하는 기능을 전달하기 위해 모듈이 할당해야 하는 dynamic copability을 반환합니다. channel capability는 handshake의 시작 부분에서 콜백으로 전달됩니다. (채널 오픈을 시도하는 체인의 OnChanOpenInit과 상대방 체인의 OnChanOpenTry)
Packets
모듈은 IBC 채널을 통해 패킷을 전송하여 서로 통신합니다. 모든 IBC 패킷에는 다음이 포함됩니다.
- Destination
portID - Destination
channelID - Source
portID - Source
channelID
포트와 채널을 통해 모듈은 주어진 패킷의 송신 모듈을 알 수 있습니다.
- 순서를 강제할 수 있는 sequence (Optional)
TimeoutTimestampandTimeoutHeight
타임아웃 값이 0이 아닌 경우, 이 값이 수신 모듈이 패킷을 처리해야 하는 마감 기한을 결정합니다. 패킷이 성공적으로 수신되지 않은 상태에서 타임 아웃이 발생하면 송신 모듈이 패킷을 타임 아웃시키고, 이에 대한 적절한 작업을 수행시킬 수 있습니다.
모듈은 IBC 패킷의 Data [] byte 필드를 통해 애플리케이션으로 데이터를 전송합니다. 패킷 데이터는 IBC 핸들러에서는 읽을 수 없게 되어 있습니다. 송신 모듈은 애플리케이션 별 패킷 정보를 패킷의 Data필드에 인코딩하여 전달합니다. 수신 모듈은 Data필드 값을 기존 애플리케이션 데이터로 다시 디코딩합니다.
Receipts and Timeouts
IBC는 분산 네트워크를 통해 작동하며 장애가 발생할 수 있는 relayer에 의존하여 원장 간에 메시지를 전달하기 때문에, IBC는 패킷이 적시에 대상에 전송되지 않거나 아예 전송되지 않는 경우, 이에 대해 처리 가능해야 합니다. 대상 체인에서 패킷 수신을 제한하는 timeout height 또는 timeout timestamp를 패킷에 지정합니다.
타임 아웃에 도달하면 기존 체인에 timeout proof-of-packet을 제출할 수 있습니다. 이 타임 아웃은 패킷 전송 변경 사항을 롤백하는 (송신인에게 잠긴 자금 환불 등) 등의 애플리케이션 별 로직을 수행합니다.
ORDERD 채널에서는 하나의 패킷에서 타임 아웃이 발생하면 채널이 닫히게 됩니다. 만일 n이라는 packet sequence가 타임 아웃 값이었을 때, n보다 큰 k sequence의 패킷은 ORDERED 채널의 규칙을 위반하는 것이기 때문에 수신될 수 없습니다. 패킷들은 전송된 순서대로 처리되어야 하기 때문입니다. ORDERD 채널에서는 이 규칙이 강제되므로, 패킷 n의 지정된 타임 아웃 시점까지 대상 체인에 sequence n이 수신되지 않았다는 사실에 근거하여 패킷 n을 timeout 처리하고 채널을 닫을 수 있습니다.
UNORDERED의 경우 패킷은 어떤 순서로도 수신될 수 있습니다. IBC는 UNORDERED 채널에서 수신한 각 sequence에 대한 패킷 수신을 기록합니다. 이 receipt은 별다른 정보를 포함하지 않으며 단순히 UNORDERED 채널이 지정된 sequence로 패킷을 수신했음을 나타내기 위한 마커입니다. UNORDERED 채널에서 패킷이 타임 아웃되려면 패킷의 sequence가 지정된 타임 아웃 시점까지 수신되지 않는다는 증명이 필요합니다. 물론 UNORDERED 채널에서의 패킷 타임 아웃은 해당 패킷에 대한 애플리케이션 별 타임 아웃 로직을 트리거하지만 채널을 닫지는 않습니다.
이러한 이유로 UNORDERED 채널을 사용하는 대부분의 모듈은 해당 채널 사용자의 효율적인 작동을 위한 수명 보장이 덜 필요하기 때문에 권장됩니다.
Acknowledgement
모듈은 패킷을 처리할 때 애플리케이션 별 승인도 기록합니다. 승인은 다음과 같이 처리됩니다.
- 모듈이 IBC 모듈로부터 패킷을 수신하는 즉시 처리하는 경우
OnRecvPacket에서 동기화됩니다. - 모듈이 패킷을 수신한 후 나중에 패킷을 처리하는 경우 비동기로 수행됩니다.
승인 데이터는 패킷의 Data처럼 IBC에서는 내용을 확인할 수 없는 상태이며 []byte형태의 문자열로 처리됩니다. 수신 모듈에서 수신 승인을 인코딩해서 전송해야 송신 모듈이 수신 승인을 올바르게 디코딩할 수 있습니다. 승인 인코딩 방식은 채널 handshake 중 버전 협의을 통해 결정해야 합니다.
승인은 송신 모듈이 적절한 조치를 취할 수 있는 추가 정보와 함께 패킷 처리의 성공 여부를 인코딩할 수 있습니다.
수신 체인에 의해 승인이 기록된 후, relayer는 기존 송신 모듈로 승인을 전달하고, 모듈에서는 승인 데이터를 사용하여 애플리케이션 별 승인 로직을 실행합니다. 승인에는 승인 실패 시의 패킷 전송 변경 사항을 롤백하는 작업이 포함될 수 있습니다. (전송인에게 환불)
기존 송신 체인에 승인이 성공적으로 수신되면 IBC 모듈은 해당 패킷 커밋이 더 이상 필요하지 않으므로 패킷 커밋을 삭제합니다.
Futher Readings and Specs
IBC에 대해 자세히 알아보려면 다음 사양을 참조하십시오.
