Reduce the overhead of seal in light clients
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
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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di CodeChain-io/foundry
-
Remove informer Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 30/100
CodeChain-io/foundry#607 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
CodeChain-io/foundry#606 ·
-
CodeChain-io/foundry#605 · 1 reazione · 1 assegnatario ·
-
Handle invalid transactions. Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
CodeChain-io/foundry#604 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
CodeChain-io/foundry#603 ·
Tutte le issue di CodeChain-io/foundry
Issue simili
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
yantrikos/yantrik-os#255 ·
-
Replayed reasoning items send "content": null, which the Responses API schema does not permit Apertabug CLI custom-model
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
raphamorim/rio#1956 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
rust-bitcoin/rust-bitcoin#6930 · 1 commento ·