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

Reduce the overhead of seal in light clients

Đang mở
  • Có gì không ổn?
#242 0 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
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
rust
Lĩnh vực
blockchain

Hướng nghiên cứu

Bắt đầu bằng việc tìm định nghĩa UpdateHeader của Foundry và mã light-client và ICS thực hiện việc tuần tự hóa và xác minh nó. Theo dõi cách new_header và seal_for_current đóng góp vào việc băm header, sau đó xác định các thay đổi cần thiết đối với việc băm và các proof; công việc được xem là hoàn tất khi các bản cập nhật của light-client vẫn có thể được xác minh, trong khi UpdateHeader không còn chứa dữ liệu seal dư thừa.

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

Mô tả

consensus light-client

Background

Light clients (both standalone and ICS) utilize the concept of 'Update header', which is a set of data that is enough to update a light client's best header. (In abstract terms, we call this 'update of client state'.)
Currently Foundry's UpdateHeader contains new_header, validator_set, and seal_for_current (for new_header).

We don't actually need all fields in the header for light clients. For example, author, parent_hash, extra_data... and even the seal
However, we must provide them to light clients since they contribute to the block hash, which will be verified by the seal_for_current.

As you can see, UpdateHeader contains two seals.

Problem

You might think it's tolerable, but it's not. It has a problem with ICS.
Of course ICS's light client will have the same problem of having two seals, but the worse part of doing this is that the UpdateHeader in IBC will be recorded in the transaction, and ultimately, in the block.
This means that a full node will carry approximately 3 seals per block if it is Foundry-Foundry IBC and each's chain has similar block generation rate.

  • one for its own block
  • one for update_header.new_header.seal
  • one for update_header.seal_for_current

How to solve

We can change the hashing scheme of our header to:
hash(header.a1, header, a2, .... , hash(header.b1, header.b2, ...))
where a#s are fields that the light client actually uses, and b#s are not. (e.g seal)
This forms a 2-depth Merkle tree and the UpdateHeader will contain only a#s + hash(header.b1, header.b2, ...), not the whole new_header.

BLS

It might be 'tolerable' if we decided to introduce BLS to master.

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.