Light client module interface for ICS

未關閉
  • 哪裡不對？
#174 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
18/100
Issue 類型
功能
描述清晰度
需要釐清
活躍度
停滯
技術堆疊
rust
領域
blockchain

研究方向

該 issue 未指出任何檔案、測試或進入點。首先定位 Rust light-client 和模組介面抽象，然後將它們與提議的查詢、交易和驗證簽章進行比較。當介面和序列化行為達成共識、完成實作，並由適當的測試涵蓋時，即視為完成。

由索引模型根據 Issue 內容生成。

描述

ics light-client

This issue is a work-in-progress version of the interface for a light client module.

Serialization format

Module programmers will use two types of serialization format.

Let's assume that chain A has light clients of chain B, and chain C. Chain B is using MessagePack to serialize data. Chain C is using ProtoBuf to serialize data. Let's think of verifyChannelState in the light client. The handler module passes the expected ChannelEnd value to the function. So we need a serialization method of how to serialize the ChannelEnd (this is the serialization type 1). To verify the ChannelEnd struct, each light client serializes the ChannelEnd data to each chain's serialization format (MessagePack and ProtoBuf). This is the serialization type 2.

Serialization type 1

We will use JSON.

The handler module will send several types of data to the light client modules. If we use "RLP" for this serialization format, each module's developer should implement decoder of RLP. To reduce the light client developer's work, we (Junha and I) concluded to use JSON format in this case.

If the module system supports a default serialization method of simple struct types, we can use it instead.

Serialization type 2

Each light client must implement each chain's serialize code.

Interface functions

Query
fn query_client_state(client_id: String, block_number: Option<u64>) -> Bytes

fn query_consensus_state(
        client_id: String,
        counterparty_block_number: u64,
        block_number: Option<u64>,
    ) -> Bytes
Transaction
fn create(id: IdentifierSlice, _consensus_state: Bytes, header: Bytes)

fn update(id: IdentifierSlice, header: Bytes)
Functions can be called from other modules
pub fn query_latest_height(id: IdentifierSlice) -> u64

pub fn verify_connection_state(
        client_identifier: IdentifierSlice,
        proof_height: BlockNumber,
        proof: Bytes,
        counterparty_connection_identifier: IdentifierSlice,
        connection_end: &ConnectionEnd,
    )

fn verify_channel_state(
        id: IdentifierSlice,
        proof_height: BlockNumber,
        proof: Bytes,
        port_identifier: IdentifierSlice,
        counterparty_channel_identifier: IdentifierSlice,
        channel_end: &ChannelEnd,
    )

fn verify_packet_data(
        id: IdentifierSlice,
        proof_height: BlockNumber,
        proof: Bytes,
        counterparty_port_identifier: IdentifierSlice,
        counterparty_channel_identifier: IdentifierSlice,
        sequence: &Sequence,
        packet_commitment: &PacketCommitment,
    )

fn verify_packet_acknowledgment(
        id: IdentifierSlice,
        proof_height: BlockNumber,
        proof: Bytes,
        port_identifier: IdentifierSlice,
        channel_identifier: IdentifierSlice,
        sequence: &Sequence,
        acknowledgment: &Acknowledgement,
    )

fn verify_packet_acknowledgment_absence(
        id: IdentifierSlice,
        proof_height: BlockNumber,
        proof: Bytes,
        port_identifier: IdentifierSlice,
        channel_identifier: IdentifierSlice,
        sequence: &Sequence,
    )

fn verify_next_sequence_recv(
        id: IdentifierSlice,
        proof_height: BlockNumber,
        proof: Bytes,
        port_identifier: IdentifierSlice,
        channel_identifier: IdentifierSlice,
        next_sequence_recv: &Sequence,
    )
主要語言
Rust
星號
36
分支
11
30 天內沒有已合併 PR

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

CodeChain-io/foundry 的其他 Issue

查看 CodeChain-io/foundry 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。