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

feat: external block provider for genesis sync

Aperta
  • Qualcosa non va?
#26 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
Da chiarire
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
backend-api-design, distributed-systems

Direzione di ricerca

La issue non indica file, test o punti di ingresso esistenti. Inizia individuando l’archivio dei blocchi corrente, il flusso di sincronizzazione iniziale, l’applicazione delle transizioni di stato e la configurazione del nodo, quindi determina dove può integrarsi un’API del provider. Il lavoro è completato quando l’API, il server basato sull’archivio, la sincronizzazione del client, la possibilità di riprendere e la configurazione dell’URL del provider funzionano come indicato nei criteri di accettazione.

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

Descrizione

Summary

Nodes running in pruning mode (default) discard old blocks to bound disk growth. To support syncing new nodes from genesis without requiring every node to be a full archive node, we need an external block serving service.

Motivation

  • Block archive storage now prunes by default (retention window of ~100k blocks)
  • Chain-index (SQLite) serves RPC/explorer queries independently of the block archive
  • Only seed/archive nodes need full block history
  • New nodes joining the network need a way to sync from genesis without requiring every peer to store all blocks

Design

An external block provider service that:

  1. Stores all blocks from genesis (potentially using commonware's immutable::Archive with freezer for minimal memory + compression)
  2. Serves block data over a well-defined API (HTTP/gRPC) to syncing nodes
  3. Can be operated independently of the P2P network -- e.g., a centralized service, cloud storage, or a dedicated archive node
Sync flow
New Node                    Block Provider
  |                              |
  |-- request blocks [0, N) --->|
  |<--- stream ArchivedBlock ---|
  |                              |
  |-- apply blocks to STF ---   |
  |-- build chain-index ---     |
  |                              |
  |-- join P2P, continue from  |
  |   latest block              |
Considerations
  • The provider does not need to be trusted for correctness -- the node validates state roots against the chain's state transition function
  • Provider could be backed by object storage (S3/R2) serving pre-compressed block segments
  • Protocol should support range requests and resumable sync
  • Consider using commonware's immutable::Archive (freezer) as the backing store for the provider -- it's designed for exactly this workload (write-once, read-many, minimal memory, compressed)

Acceptance Criteria

  • Define block provider API (gRPC service definition or HTTP endpoints)
  • Implement block provider server backed by full block archive
  • Implement client-side sync that fetches blocks from provider and applies them
  • Support resumable sync (track last synced block)
  • Node config option to specify block provider URL for initial sync
Lingua principale
Rust
Stelle
4
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

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 evstack/ev-rs

Tutte le issue di evstack/ev-rs

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.