Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Reduce the overhead of seal in light clients

Aperta
#242 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
blockchain

Direzione di ricerca

Inizia individuando la definizione di UpdateHeader in Foundry e il codice del light client e di ICS che lo serializza e lo verifica. Traccia il modo in cui new_header e seal_for_current contribuiscono all’hashing dell’header, quindi determina le modifiche necessarie all’hashing e alle prove; il lavoro è completo quando gli aggiornamenti del light client rimangono verificabili, mentre UpdateHeader non contiene più dati di seal ridondanti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
36
Fork
11
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CodeChain-io/foundry

Tutte le issue di CodeChain-io/foundry

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.