Reduce the overhead of seal in light clients
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- rust
- 領域
- blockchain
調査の方向性
まず、Foundry の UpdateHeader の定義と、それをシリアライズおよび検証する light-client と ICS のコードを見つけます。new_header と seal_for_current がヘッダーのハッシュ計算にどのように寄与するかを追跡し、次に必要なハッシュ計算と証明の変更を特定します。UpdateHeader が冗長な seal データを持たなくなり、light-client の更新が引き続き検証可能であれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Rust
- スター
- 36
- フォーク
- 11
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
CodeChain-io/foundry のほかの issue
-
Remove informerオープン
難易度 3/5 1〜2日 初心者へのやさしさ 30/100
CodeChain-io/foundry#607 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
CodeChain-io/foundry#606 ·
-
Change the return type of execute_transactions to signify it always succeeds再び着手できるかも @dynaxis が 2113 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
CodeChain-io/foundry#605 · リアクション 1 件 · 担当者 1 名 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
CodeChain-io/foundry#604 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
CodeChain-io/foundry#603 ·
CodeChain-io/foundry の issue をすべて見る
似ている issue
-
llm translation
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
CybercentreCanada/sawp#13 ·
-
area: backend type: enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 61/100
armadavalor/WinKnife#6 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
5omeOtherGuy/phaseone#870 ·
メンテナーはふだん 1 日以内に返信