Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Light client module interface for ICS

Đang mở
  • Có gì không ổn?
#174 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
18/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
rust
Lĩnh vực
blockchain

Hướng nghiên cứu

Issue không nêu tên tệp, bài kiểm thử hay điểm vào nào. Hãy bắt đầu bằng cách xác định các abstraction của Rust light-client và module-interface, sau đó so sánh chúng với các chữ ký được đề xuất cho query, transaction và verification. Công việc được xem là hoàn tất khi interface và hành vi serialization đã được thống nhất, triển khai và được bao phủ bởi các bài kiểm thử phù hợp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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,
    )
Ngôn ngữ chính
Rust
Star
36
Fork
11
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CodeChain-io/foundry

Tất cả issue của CodeChain-io/foundry

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.