Priorità CometBFT per il secondo trimestre del 2023

https://medium.com/the-interchain-foundation/cometbft-priorities-for-2023-q2-3735253eacc9

Ecco le principali considerazioni:

Nel secondo trimestre del 2023, il team Comet si concentrerà su cinque linee di lavoro. Ciascuna di queste linee mira a risolvere un problema principale dal nostro backlog delle priorità.

I problemi che stiamo affrontando hanno una portata più ampia di questo trimestre. Pertanto, prevediamo di continuare a concentrarci su questi problemi per il resto del 2023.

I cinque problemi di focus sono, in ordine di priorità:

1. CometBFT offre scarso supporto di progettazione del protocollo agli sviluppatori delle applicazioni.

2. Attualmente non esiste un'alternativa alla sincronizzazione dello stato basata su rete.

3. Il JSON/RPC esposto dai nodi CometBFT è instabile.

4. Il consumo di storage e larghezza di banda è costoso per gli operatori che eseguono nodi CometBFT.

Per soluzioni specifiche, consulta il post completo qui sotto.

Contesto: Abbiamo lanciato CometBFT all'inizio di febbraio 2023. Sono passati 2 mesi da allora. In questo breve periodo, il team CometBFT ha compiuto progressi significativi nello sviluppo di CometBFT. In questo post, riassumeremo innanzitutto i principali successi ottenuti durante il primo trimestre. Successivamente, forniremo una panoramica delle priorità che intendiamo affrontare come parte del secondo trimestre, nonché del processo che abbiamo utilizzato per stabilire queste priorità.

Sommario del Q1: Il primo trimestre è stato un periodo interessante per il team CometBFT perché il primo mese (gennaio) è stato denso di attività legate alla biforcazione di Tendermint Core, alla rinominazione di quella biforcazione in CometBFT e alla preparazione della sua annuncio pubblico. Questo lavoro è stato noioso ma molto gratificante: ci ha permesso di ripartire lo sviluppo e di fornire una solida base per continuare a evolvere questo software verso la crescita dell'Interchain. Leggi l'annuncio che introduce CometBFT qui e in questa discussione.

In termini di deliverable tecnici e documentazione, durante il Q1 abbiamo rilasciato quanto segue:

• 3 febbraio, 4: abbiamo rilasciato v0.34.25 e v0.34.26, il primo rilascio è stato un patch di sicurezza per la linea v0.34.*. Entrambi questi rilasci sono stati effettuati dalla fork pubblica del team Informal Systems di Tendermint Core.

• 27 febbraio: abbiamo rilasciato v0.34.27, il primo rilascio ufficiale di CometBFT, un sostituto diretto di Tendermint Core v0.34.x

• 28 febbraio: abbiamo pubblicato la documentazione ufficiale di CometBFT su https://docs.cometbft.com/

• 6 marzo: rilasciato v0.37.0, il primo rilascio di CometBFT con ABCI 1.0

• 29 marzo: rilasciato v0.38.0-alpha.1, una pre-release con ABCI 2.0

Entrambi i rilasci v0.37.* e v0.38.* sono stati in preparazione per molto tempo. Siamo grati a tutti i team e ai contributori che hanno contribuito a progettare e perfezionare ABCI 2.0 negli ultimi ~2 anni. È davvero emozionante vedere tutto questo lavoro giungere a compimento e le numerose reti interessate a sfruttare le nuove funzionalità nell'interfaccia ABCI.

Nelle ultime due settimane di marzo, siamo stati occupati a gestire il nostro backlog e a stabilire le nostre priorità in modo da avere chiarezza sul lavoro che faremo nei prossimi 3 mesi.

Priorità per il Q2 (aprile, maggio, giugno) Abbiamo cinque linee di ricerca e sviluppo in programma per il prossimo trimestre. Prima parleremo del problema che ciascuna di queste linee di lavoro cerca di affrontare e quindi forniremo alcuni dettagli sullo spazio delle soluzioni.

Problema (1) CometBFT v0.34 offre scarso supporto agli sviluppatori di applicazioni per affrontare nuovi casi d'uso CometBFT v0.34, utilizzato attualmente in produzione, comprende l'interfaccia ABCI v0.17. ABCI è l'API che separa l'applicazione dal motore di consenso. Questa è l'interfaccia a disposizione degli sviluppatori di applicazioni per interagire con CometBFT.

ABCI v0 è stato progettato circa nel 2015-2016. Da allora, l'ecosistema crittografico più ampio ha subito un'evoluzione rapida. Le applicazioni richiedono oggi maggiore flessibilità e controllo. Gli sviluppatori di applicazioni cercano di avere un controllo più dettagliato su ciò che CometBFT mette all'interno dei blocchi e di utilizzare CometBFT per scambiare informazioni tra i nodi diversamente attraverso i blocchi.

Per affrontare questo problema, è stato proposto ABCI++ circa nel 2020 (RFC 013). ABCI++ viene fornito attraverso due versioni: ABCI v1 (CometBFT v0.37) e ABCI v2 (CometBFT v0.38). Come già accennato, abbiamo rilasciato ABCI v1, e per v2 siamo nelle fasi finali: abbiamo già rilasciato un alpha-1. Quello che resta è definire il design dell'interfaccia, scrivere documentazione più completa di ABCI v2 e fare un'estensiva QA su larga scala, che di solito coinvolge testnet di 200 nodi.

Prevediamo che il rilascio di v0.38.0 richiederà ancora 1-2 mesi di lavoro.

Problema (2) Attualmente non esiste un'alternativa alla sincronizzazione dello stato basata su rete In CometBFT v0.34, la sincronizzazione di un nodo fresco con il resto della rete si basa su un protocollo che recupera snapshot dagli altri nodi nella rete. Alcuni svantaggi di questo approccio sono che è fragile (perché i snapshot dei peer potrebbero non essere immediatamente disponibili) e intensivo in termini di larghezza di banda.

Esistono alternative alla sincronizzazione dello stato basata su rete. Ad esempio, utilizzando uno snapshot locale, che potrebbe essere stato generato dal nodo stesso o copiato da una fonte fidata, la sincronizzazione dello stato potrebbe evitare trasferimenti di grandi dimensioni da parte dei peer remoti. Tale alternativa è stata esplorata e prevediamo di portare questo lavoro in un futuro rilascio di CometBFT.

Questo problema è particolarmente interessante perché gli operatori utilizzano frequentemente la sincronizzazione dello stato dei nuovi nodi. Lo fanno perché il consumo di storage dei nodi cresce nel tempo, quindi c'è una preferenza per configurare regolarmente nuovi nodi. Il problema della crescita dello storage è qualcosa di cui siamo consapevoli ed è anche una priorità (vedi sotto). In ultima analisi, si tratta di un problema importante, e come ha sottolineato un importante utente nella tracciatura.

Problema (4) e (5) Il consumo di storage e larghezza di banda è costoso per gli operatori che gestiscono nodi CometBFT Sul fronte dello storage, il problema è che la potatura non funziona efficacemente. Ciò porta a un aumento dei costi di storage nel tempo. A un livello più basilare, CometBFT supporta più backend di database, ma non esiste un caso d'uso documentato delle caratteristiche di carico di lavoro previste per questi backend. Di conseguenza, non è chiaro quale di essi sia più adatto dal punto di vista delle prestazioni ed efficienza. Analogamente al problema del JSON/RPC, vogliamo ridurre la superficie sotto la nostra manutenzione e preferiremmo quindi limitare i database supportati a quello che si adatta meglio.

In termini di larghezza di banda, siamo consapevoli che gli operatori stanno sostenendo costi elevati a causa del consumo di larghezza di banda delle reti basate su CometBFT. Per mitigare questo problema, un'indagine iniziale ha portato a una riduzione del 50% delle Precommit votes inviate tra i peer. Stiamo continuando questa indagine per ridurre il consumo di larghezza di banda non relativo ai voti (ad esempio parti dei blocchi o transazioni). Un elemento importante di questa indagine riguarda la stesura delle specifiche per i moduli P2P e di consenso, che sono al centro dell'attenzione per quanto riguarda l'uso della larghezza di banda.

Processo Abbiamo scelto i problemi in base ai feedback e alle informazioni che abbiamo raccolto da vari canali (Slack, Discord, Telegram, Twitter e chiamate della comunità).

Gli elementi specifici dei feedback a cui ci interessava erano:

• Ci sono persone specifiche che possono confermare il problema? Abbiamo una buona comprensione delle preoccupazioni sottostanti o della causa radice?

• C'è un'articolazione dell'impatto del problema, ad esempio in termini di denaro, opportunità, tempo o energia? Questo rende il problema urgente, rispetto ad altri problemi?

• Ci sono utenti specifici con cui possiamo lavorare per confrontare le nostre idee, per de-riskare le soluzioni ed assicurare un feedback continuo?

• Possiamo compiere passi incrementali verso una soluzione? Inoltre, abbiamo anche dato una leggera preferenza a problemi a rapida risoluzione e ad alto impatto.

Ciò ci ha portato a categorizzare i problemi in una tabella. Ciò ha gettato luce e chiarezza su tutti i problemi confrontandoli in termini di urgenza, impatto, utenti, complessità ed sforzo.

La tabella sottostante è un estratto dai nostri appunti grezzi durante l'esercizio di prioritizzazione. Mostra i problemi più urgenti per il Q2. Nota che la colonna "Utente" non è esaustiva: alcuni utenti non vengono menzionati per evitare di ingrandire la tabella.

Il seguente estratto mostra anche il nostro attuale backlog dei problemi prescelti.

Sia le priorità scelte che il backlog sono allineati con il progetto. La differenza è che in queste tabelle e nelle nostre discussioni interne siamo andati più in profondità nell'analizzare il problema e lo spazio delle soluzioni, catturando anche utenti ed impatto.

Pensieri finali Siamo consapevoli che questo approccio alla prioritizzazione non è del tutto oggettivo. Se ci sono feedback o idee per migliorare, saremmo lieti di coinvolgere la comunità per perfezionare la nostra prioritizzazione.

Infine, stiamo eseguendo queste priorità in parallelo a un lavoro di ricerca pluriennale su fork di Tendermint Core e CometBFT (ad esempio, fork di Celestia, Sei, Skip, Numia o Polygon tra molti altri). L'obiettivo di questa indagine è scoprire quali miglioramenti hanno fatto altre squadre nei loro fork che sarebbero appropriati e desiderabili per essere upstreamed in CometBFT. Per ciascun candidato, stiamo valutando complessità ed impatto. L'idea è collaborare con alcune di queste squadre per upstreamare le modifiche in CometBFT, in modo che tutta la comunità possa beneficiare dei miglioramenti corrispondenti.