IBC

• “IBC 프로토콜”은 블록체인 간 통신 프로토콜을 의미
• Cosmos가 ICS(Interchain Standards)로 표준화하고 있는 IBC 프로토콜

+---------------------------------------------------------------------------------------------+
| Distributed Ledger A                                                                        |
|                                                                                             |
| +----------+     +----------------------------------------------------------+               |
| |          |     | IBC Module                                               |               |
| | Module A | --> |                                                          | --> Consensus |
| |          |     | Handler --> Packet --> Channel --> Connection --> Client |               |
| +----------+     +----------------------------------------------------------+               |
+---------------------------------------------------------------------------------------------+

    +---------+
==> | Relayer | ==>
    +---------+

+--------------------------------------------------------------------------------------------+
| Distributed Ledger B                                                                       |
|                                                                                            |
|               +---------------------------------------------------------+     +----------+ |
|               | IBC Module                                              |     |          | |
| Consensus --> |                                                         | --> | Module B | |
|               | Client -> Connection --> Channel --> Packet --> Handler |     |          | |
|               +---------------------------------------------------------+     +----------+ |
+--------------------------------------------------------------------------------------------+

Client

• 클라이언트는 IBC 의 ICS-002 에 정의된 라이트 클라이언트
• 클라이언트의 목적은 IBC와 통신하는 블록체인이 다른 블록체인이 동의한 상태에 대한 업데이트를 확인할 수 있도록 하는 것
• 헤더를 제출하여 클라이언트에 대한 업데이트가 이루어짐.
  • 제출된 헤더가 확인되면 내부적으로 유지 관리되는 ConsensusState 및 ClientState가 업데이트 됨

ClientState

• 특정 Key/Value 쌍(key : id, chaincodeHeader, ibcPolicy…)이 주어진 Height의 State에 존재하는지 여부를 증명하는 데 사용
• Endorsement Policy, Chaincode ID, Chaincode Version 추적

interface ClientState {
  id: string
  chaincodeHeader: ChaincodeHeader
  ibcPolicy: Policy
  chaincodeInfo: ChaincodeInfo
  mspInfos: MSPInfos
}

interface ChaincodeHeader {
  sequence: commitment.Sequence // Value & Timestamp
}

interface ChaincodeInfo {
  channelId: string
  chaincodeId: ChaincodeID
  endorsementPolicy: []byte
}

interface Policy {
  policy: []byte
  sequence: uint64
}

interface MSPInfos {
 infos: []MSPInfo
}

interface MSPInfo {
  mspID: string // unique for its ClientState
  config: []byte // proto.Marshal(msppb.MSPConfig)
  policy: Policy
  frozen: bool // avoid reusing ID after deletion
}

Consensus

ConsensusState

• ConsensusState는 유효성 조건자별로 헤더를 검증하는 데 사용

interface ConsensusState {
  timestamp: int64
}

Header

• ConsensusState를 업데이트하기 위한 정보가 포함
• ChaincodeHeader 와 ChaincodeInfo가 포함

interface Header {
  chaincodeHeader: Maybe<ChaincodeHeader>
  ibcPolicy: Maybe<PolicyHeader>
  chaincodeInfo: Maybe<ChaincodeInfoHeader>
  mspInfoHeaders: Maybe<MSPInfoHeaders>
}

interface ChaincodeHeader {
  sequence: commitment.Sequence // contains Value, Timestamp
  proof: CommitmentProof
}

interface PolicyHeader {
  policy: Policy
  proof: MessageProof
}

interface ChaincodeInfoHeader {
  channelId: string
  chaincodeId: ChaincodeID
  endorsementPolicy: []byte
  ibcPolicySequence: uint64
  proof: MessageProof
}

interface MSPInfoHeaders {
  headers: []MSPInfoHeader
}

type MSPInfoHeaderType = "Create" | "UpdatePolicy" | "UpdateConfig" | "Freeze"

interface MSPInfoHeader {
  type: MspInfoHeaderType
  mspID: string
  config: []byte // proto.Marshal(msppb.MSPConfig)
  // when type is "UpdateConfig", policy.Sequence must be needed.
  policy: Maybe<Policy>
  ibcPolicySequence: uint64
  proof: MessageProof
}

ChaincodeHeader.Proof

• ConsensusState에서 Sequene을 업데이트하는 데 필요한 패브릭 클라이언트의 제안 결과에 대한 증거 역할
• 포함된 서명은 ClientState가 보유한 보증 정책을 충족해야함

interface CommitmentProof {
  proposal: []byte
  nsIndex: uint32
  writeSetIndex: uint32
  identities: [][]byte
  signatures: [][]byte
}

PolicyHader.Proof

• ClientState에서 IBC 정책을 업데이트하는 데 필요한 IBC 정책에 대한 증거 역할
• 포함된 서명은 ClientState가 보유한 보증 정책을 충족해야함

interface MessageProof {
  identities: [][]byte
  signatures: [][]byte
}

ChaincodeInfo.Proof

• ClientState에서 ChaincodeInfo를 업데이트하는 데 필요한 ChaincodeInfo에 대한 증거 역할
• 포함된 서명은 ClientState가 보유한 보증 정책을 충족해야함
• PolicyHeader.Proof와 유사하게 MessageProof가 사용

Misbehaviour

• Fabric-IBC의 오작동은 ClientState의 Sequence에 대한 동일한 Sequence 값에 대한 두 개의 서로 다른 Proofs 또는 상태 검증의 Endorsed Commitment와 관련하여 동일한 키에 대한 서로 다른 값에 대한 두 개의 Proofs로 구성

type Misbehaviour = MisbehaviourSubHeader | MisbehaviourEndorsedCommitment

type SubHeader = ChaincodeHeader | PolicyHeader | ChaincodeInfoHeader | MSPInfoHeader

type SequenceType = "ChaincodeHeader" | "IbcPolicy" | "MSPInfo"

type StateType =
  | "ClientConsensusState" | "ConnectionState" | "ChannelState"
  | "PacketCommitment" | "PacketAcknowledgement" | "PacketAcknowledgementAbsense"
  | "NextSequenceRecv"

interface MisbehaviourSubHeader {
  sequence: uint64
  sequenceType: SequenceType
  h1: SubHeader
  h2: SubHeader
}

interface MisbehaviourEndorsedCommitment {
  key: string
  stateType: StateType
  p1: CommitmentProof
  p2: CommitmentProof
}

Validity Predicate

• 현재 ConsensusState를 기반으로 헤더의 유효성 검증 함수 포함
• https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#validity-predicate 참고

VerifyChaincodeHeader

• WriteSet에 ChaincodeHeader를 포함하는 제안 응답이 현재 등록된 보증 정책에 따라 서명되었는지 확인

VerifyChaincodeInfo

• ChaincodeInfo가 현재 등록된 IBC 정책에 따라 서명되었는지 확인

State Verification Function

• Client가 추적해야 하는 State의 내부 상태를 확인하는 함수

verifyClientConsensusState

• 대상 블록체인의 특정 클라이언트에 보관된 ConsensusState에 대한 Proof를 확인

verifyConnectionState

• 대상 블록체인에 있는 특정 ConnectionState에 대한 Proof를 확인

verifyChannelState

• 대상 블록체인에 보관된 특정 IBC ChannelState에 대한 증명을 확인

verifyPacketData

• 특정 IBC 채널, 포트 또는 시퀀스에서 시작된 패킷에 대한 증명을 확인

verifyPacketAcknowledgement

• 특정 IBC 채널, 포트 및 시퀀스에서 수신된 패킷 확인에 대한 증명을 확인

verifyPacketAcknowledgementAbsence

• 특정 IBC 채널, 포트 및 시퀀스에서 수신할 누락된 패킷 확인 확인을 확인

verifyNextSequenceRecv

• 특정 IBC 채널 및 포트에서 수신할 다음 시퀀스의 증명을 확인

Endorsed Commitment

• IBC는 적은 계산 비용으로 Key/Value 쌍이 대상 블록체인의 상태에 존재하는지(또는 존재하지 않는지) 확인하기 위해 Proof of Commitment를 요구
• Fabric-IBC에서 Proof는 ClientState에서 유지 관리되는 보증 정책을 만족하는 Endorser에게 제안 응답을 반환하는 Chaincode를 쿼리하여 생성되며, Read-Write Set이 포함
• 이를 Endorsed Cmmitment로 규정함
• Endorsed Commitment의 검증은 제안 응답의 서명이 위에서 설명한 ClientState의 승인 정책을 충족하는지 확인하는 것

Connection, Channel

• Connection은 IBC와 통신하는 두 블록체인 각각이 보유하고 있는 상태이며 Client와 연계하여 사용됩니다. 블록체인 간에 통신하려면 연결이 설정되어야함

Packet

• Relayer가 블록체인 간에 중계하기 위해서는 IBC Channel, Source와 Destination이 모두 사용하는 Port, Data에 대한 정보를 가지고 있어야 함

Relayer

• IBC에서 정의한 오프체인 프로세스로 블록체인의 트랜잭션 상태를 읽고 블록체인 간에 패킷으로 전달 가능
  • 비잔틴 동작이 있는 릴레이의 존재는 IBC가 충족해야 하는 중요한 안전 속성, 즉 정확히 한 번 및 전달 또는 시간 초과를 손상시키지 않음
  • 정상적으로 동작하는 Relayer가 하나 이상 있으면 Packet Relay의 활성이 유지
  • 릴레이 자체는 누구나 할 수 있으며 릴레이에 필요한 모든 검증은 블록체인에서 이루어짐

Relayer Initialization

• Fabric-IBC에서 Relayer는 서비스가 시작되기 전에 연결될 두 개의 IBC Chaincode와 관련된 config를 부여받음
• Relayer는 Fabric의 클라이언트 역할을 하는 서비스
• Fabric-CA 에서 Relayer의 인증서를 발급받아야 함

Fabric-BIC Module

• 상태 확인을 위해 Fabric 클라이언트가 요구하는 Proof 및 헤더를 생성하는 기능을 제공하는 일련의 체인코드
  • Chaincode header generator
  • Endorsed commitment generator

Chaincode header generator

• 시퀀스 값을 증가시키기 위한 API
• 클라이언트가 지정한 현재 또는 과거 시퀀스에 대한 승인된 Endorsed Commitment을 생성

Endorsed commitment generator

• IBC 상태의 특정 약정을 참조하기 위한 증거로 Endorsed Commitment 샏성
• 상태 확인을 위해 기능별로 API를 제공