Autore: Markus Hinrichs
Editore: Randall Roland
Traduttore: Markus Hinrichs
Operatori di nodi, sviluppatori principali di Antelope e membri della comunità si incontrano ogni settimana per parlare della rete e del suo sviluppo. L'obiettivo principale di ogni tavola rotonda degli operatori di nodi è:
"…migliorare il protocollo Antelope (specificamente) per gli operatori di nodi."
Le tavole rotonde si svolgono ogni mercoledì. Puoi trovare informazioni su come partecipare nel canale Telegram. La Fondazione della Rete EOS fornisce tutorial e documentazione per coloro che vogliono apprendere le basi del funzionamento di un nodo EOS.
Ecco un elenco delle tavole rotonde incluse in questo riepilogo bimestrale:
9 novembre: Stato di Leap 5.0, Piano di migrazione, Discussione sulla modalità OC Auto, Rischio potenziale per nodi non aggiornati e altro
15 novembre: Fix EOS VM OC completati, Rilascio RC3 previsto tra inizio e metà dicembre, Discussione su problemi.
Assicurati di cercare ulteriori note e commenti sulla riunione su GitHub. I video sono disponibili sul canale YT della ENF.
9 novembre: Stato di Leap 5.0, Piano di migrazione, Discussione sulla modalità OC Auto, Rischio potenziale per nodi non aggiornati e altro
Aggiornamento dello stato di Leap 5.0:
Il lavoro per Leap 5.0 è stato completato per lo più da alcune settimane.
Un problema in sospeso legato alle librerie BLS è in fase di risoluzione per il Release Candidate 3 (RC3).
Non sono previsti cambiamenti significativi in RC3, rispetto alle discussioni precedenti.
Piano di migrazione per l'aggiornamento a 5.0:
L'impostazione predefinita è ora "ES VM OC enable equals AUTO", abilitando la modalità OC in modo selettivo in base al contesto.
Discussione su come gestire reti eterogenee in cui alcuni nodi si aggiornano a 5.0 mentre altri no.
"Ci sono alcune condizioni in cui potrebbe sorgere una preoccupazione potenziale; dipende dal carico di rete pesante (CPU)" Brian Hazzard
Raccomandazione per i nodi che eseguono versioni precedenti di impostare "ES VM OC enable ON" per tenere il passo con il throughput più veloce dei nodi Leap 5.0 (più efficienti in termini di memoria, più efficienti in termini di CPU, ecc.).
La comunicazione chiara e il coinvolgimento della comunità saranno cruciali per gestire eventuali problemi che sorgono e aiutare alla fine i membri della comunità ad aggiornare i propri nodi.
Discussione sulla modalità OC Auto:
Chiarezza sulla modalità OC Auto che dipende dal tipo di macchina (produttore o non produttore) e dai contratti di sistema.
Produttori che utilizzano OC per i contratti di sistema EOSIO; non produttori che utilizzano OC per tutti i contratti a meno che non siano configurati diversamente.
Rischi potenziali per nodi non aggiornati:
Se un produttore non si aggiorna a 5.0, in modalità abilitata OC, i blocchi potrebbero non essere verificati da altri produttori durante carichi pesanti di contratti non di sistema.
La dinamica della contro pressione potrebbe incoraggiare i nodi non aggiornati a effettuare l'aggiornamento.
"... E dovrebbero aggiornare… Se c'è un carico, allora aggiornare" Matthew Darwin
Cronologia per il rilascio di Leap 5.0:
Il rilascio stabile è previsto tra alcune settimane, con rc3 previsto tra circa una settimana.
Incoraggiamento per gli operatori di nodi a testare le versioni candidate sulle reti non di produzione, iniziando con le testnet.
Raccomandazioni di aggiornamento tempestivo per nodi non di produzione e di produzione nelle reti principali.
Segnalazioni di problemi e contributi:
Riconoscimento delle segnalazioni di problemi, specialmente da parte di contributori attivi come Matthew.
La maggior parte dei problemi critici è stata affrontata e rc3 incorpora correzioni da rc2+.
Brian Hazzard esprime gratitudine per un feedback prezioso, la partecipazione attiva al Round Table degli operatori di nodi di Antelope e al Canale della Comunità è molto apprezzata. L'invito a partecipare alla prossima sessione chiude la chiamata.
15 novembre: Fix EOS VM OC completati, Rilascio RC3 previsto tra inizio e metà dicembre, Discussione su problemi.
Aggiornamento dello stato 5.0
Le correzioni delle funzioni host di EOS VM OC sono complete.
Confronto tra due versioni delle funzioni host con differenze di prestazioni.
Il rilascio 5.0 RC3 è previsto tra il 6 e il 14 dicembre.
Richiesta di testare RC3 su reti di test o nodi non-BP in produzione.
Feedback e discussione su problemi segnalati
Supporto per etichette arbitrarie sui peer P2P (Kevin Heifner)
Discussione sulla necessità di etichette arbitrarie, poiché aggiungono complessità e riducono la leggibilità.
Secondo Matthew Darwin, probabilmente sarebbe meglio aggiungere una struttura JSON per informazioni peer aggiuntive.
Considerazione della ristrutturazione della configurazione di peering prima dell'implementazione.
"Comunque non sarà incluso in Leap 5, quindi ha senso aspettare quel lavoro di refactoring"
Suggerimento di Mathew Darwin: non forzare il flush dei file di stato all'uscita di Nodeos
La discussione ha riguardato il suggerimento e il suo impatto sulle prestazioni complessive del sistema.
Kevin Heifner considera il flush come cruciale, ma riconosce problemi associati, come notevoli ritardi durante i riavvii. Questa sfida deriva dalla necessità di flushare non solo il piccolo file di nodeos, ma anche numerosi file da altre catene.
In questo contesto, Ross ha condiviso un articolo su Medium che discute potenziali miglioramenti con ZFS.
Kevin ha raccomandato di chiudere il problema discusso e ha sostenuto di testare il flushing con Leap 5.0. Ha sottolineato i numerosi miglioramenti delle prestazioni in Leap 5.0, incluso il feature "mapped private node", che ha il potenziale per accelerare significativamente il processo di flushing.
Opzioni non predefinite di Log, una per riga
Quando nodeos si avvia, registra tutte le opzioni non predefinite in una riga lunga.
Si tratta di una scelta di stile secondo Brian Hazzard
Motivazioni per l'utilizzo della delimitazione delle righe:
Implementato per migliorare la ricerca, rendendo più facile la ricerca all'interno dei file di log.
Motivazioni per la consolidazione in una singola riga:
Considerato utile per il debug, aumentando la probabilità di essere incluso in un incolla di linea di log.
Migliora la praticità e semplifica l'utilizzo in situazioni di risoluzione dei problemi.
Aggiungere una nuova funzione: è lo stato compatibile
Proposta per uno script di servizio progettato per facilitare i controlli di compatibilità, riducendo così i ritardi temporali.
È seguita una deliberazione sull'utilizzo di snapshot e codici di uscita Nodeos.
Fonti & Riferimenti