Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Reduce the overhead of seal in light clients

Abierto
  • ¿Algo no está bien?
#242 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust
Área
blockchain

Línea de trabajo

Empieza por localizar la definición de UpdateHeader de Foundry y el código de light client y de ICS que lo serializa y verifica. Rastrea cómo new_header y seal_for_current contribuyen al hashing del header, y determina después los cambios necesarios en el hashing y las pruebas; el trabajo estará terminado cuando las actualizaciones del light client sigan siendo verificables, mientras que UpdateHeader ya no contenga datos de seal redundantes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
36
Forks
11
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CodeChain-io/foundry

Todos los issues de CodeChain-io/foundry

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.