Autore: Markus Hinrichs
Editore: Randall Roland
Trduttore: Markus Hinrichs
Gli operatori di nodi, gli sviluppatori principali di Antelope e i membri della comunità si incontrano ogni settimana per discutere sulla rete e il suo sviluppo. L'obiettivo principale di ogni Tavola Rotonda degli Operatori di Nodi è:
"...migliorare il protocollo Antelope (in modo specifico) per gli operatori di nodi."
Le tavole rotonde si svolgono ogni mercoledì. Visita il canale Telegram per informazioni su come partecipare. La Fondazione EOS Network fornisce tutorial e documentazione per coloro che desiderano apprendere le basi del funzionamento di un nodo EOS.
Di seguito è riportato un elenco delle tavole rotonde contenute in questo riassunto bimensile:
18 ottobre: Miglioramento della configurazione della CPU, Discussione sulla funzione dei blocchi iniziali, Semplificazione della configurazione a livello di rete e altro
25 ottobre: Desideri e aspirazioni per il formato delle chiamate degli operatori di nodi, Ultimi obiettivi per raggiungere RC3
Assicurati di cercare ulteriori note e commenti sugli incontri su GitHub. I video sono disponibili sul canale YouTube di ENF.
18 ottobre: Leap 5.0 è in arrivo: Blocchi iniziali, Miglioramenti delle prestazioni e Contributi della comunità
Rilascio di Leap 5.0 e Testing:
L'incontro è iniziato con una discussione approfondita sul rilascio di Leap 5.0.
Si è fortemente incoraggiata la partecipazione attiva dei membri della comunità nei test della versione candidata, RC2, con l'obiettivo principale di individuare e affrontare eventuali problemi prima del rilascio stabile ufficiale.
Modifiche all'opzione Percentuale di Sforzo della CPU:
È stata introdotta una modifica significativa riguardo all'opzione percentuale di sforzo della CPU.
La proposta prevedeva il passaggio dall'uso di valori percentuali alla configurazione dello sforzo della CPU in millisecondi.
Le opzioni esistenti, come la percentuale di sforzo della CPU, lo sforzo della CPU dell'ultimo blocco, lo spostamento dell'ultimo blocco e le versioni dell'ultimo blocco, dovevano essere sostituite da una nuova opzione chiamata "offset di produzione dei blocchi in ms."
Dettagli della nuova opzione "offset di produzione dei blocchi in ms":
La nuova opzione "offset di produzione dei blocchi in ms" appena introdotta consente agli operatori di nodi di specificare il numero di millisecondi che desiderano assegnare per l'intera serie, composta da 12 blocchi.
Questo offset svolge un ruolo cruciale nella determinazione del tempo assegnato per gestire la latenza nella produzione di blocchi.
È importante sottolineare che questa modifica non avrebbe influenzato il meccanismo di consenso ed è stata progettata specificamente per migliorare l'efficienza nella produzione dei blocchi.
Produzione anticipata di blocchi e Testing:
Le discussioni successive hanno riguardato l'introduzione della produzione anticipata di blocchi in Leap 5.0.
Michael, EOSUSA, ha presentato il concetto di modifica delle impostazioni dell'orologio di sistema, suscitando preoccupazioni riguardo a possibili problemi e conseguenze non intenzionali.
Sono state espresse preoccupazioni su come la produzione anticipata di blocchi potesse influenzare la rete e se avrebbe potuto portare a biforcazioni o altre complicazioni.
Prestazioni nei test di laboratorio:
Kevin Heifner ha espresso entusiasmo riguardo ai potenziali miglioramenti delle prestazioni dovuti alla produzione anticipata di blocchi.
La discussione ha evidenziato come la produzione anticipata di blocchi consenta più tempo per l'inclusione delle transazioni nei blocchi, beneficiando in ultima analisi dell'efficienza della rete.
L'OC (Ottimizzatore del Compilatore) di EOS VM è stato riconosciuto come un miglioramento significativo delle prestazioni, soprattutto per le DApps e i contratti di EOSIO.
È stato messo in evidenza il fatto che vi è la possibilità che un carico maggiore venga spostato verso soluzioni storiche per gestire l'aumento delle prestazioni.
"Ci sono un sacco di miglioramenti delle prestazioni dai giorni 1.8 a oggi, è come un motore molto più sintonizzato e quindi dovrebbe essere in grado di gestire il carico", ha dichiarato Kevin Heifner, OCI.
Configurazione dell'opzione "offset di produzione dei blocchi in ms" e valori predefiniti:
La conversazione si è spostata verso la configurazione dell'opzione "offset di produzione dei blocchi in ms" e i valori predefiniti proposti.
È stato proposto un valore predefinito di 450 millisecondi per "offset di produzione dei blocchi in ms," con discussioni che enfatizzavano l'importanza delle impostazioni predefinite nell'influenzare il comportamento dei nodi.
È stata sottolineata la flessibilità come fattore chiave, che consente agli operatori di adattare l'impostazione alle loro specifiche condizioni di rete.
Blocchi in ritardo e Sincronizzazione dell'orologio:
È stata affrontata la questione dei blocchi in ritardo e della loro gestione nel contesto della produzione anticipata di blocchi.
Sono state prese in considerazione le potenziali conseguenze della sincronizzazione dell'orologio e della latenza di rete sui blocchi in ritardo.
Kevin ha chiarito che i blocchi in ritardo potrebbero portare a microbiforcazioni, ed è stata esplorata la funzione della sincronizzazione dell'orologio in questo contesto.
Impostazione del "Tempo Massimo di Transazione" e del "Tempo Finestra di Lettura in Sola Lettura":
La discussione ha riguardato l'impostazione del "Tempo Massimo di Transazione" e le possibili modifiche.
Kevin Heifner ha raccomandato un'impostazione predefinita di "circa 500 millisecondi."
È stata evidenziata l'importanza della configurazione delle impostazioni per il "Tempo Finestra di Lettura in Sola Lettura," enfatizzando l'ottimizzazione della rete per migliori prestazioni.
È stato suggerito che gli operatori di nodi dovrebbero impostare questi valori in base alle loro specifiche esigenze d'uso.
Esecuzione tramite Consenso On-Chain:
È stata introdotta l'idea di controllare le impostazioni tramite consenso on-chain come mezzo per semplificare le modifiche a livello di rete.
"...ora i BP possono controllarlo a livello di rete attraverso un'impostazione di consenso", ha dichiarato Kevin Heifner.
Discussione sul PR per l'Etichettatura dei Peer-to-Peer Peers:
È stata brevemente menzionata una Richiesta Pull pendente relativa all'etichettatura dei peer-to-peer peers.
A causa dei vincoli di tempo e dell'assenza del membro chiave del team, Matthew Darwin, una discussione dettagliata su questo argomento è stata rinviata a un futuro incontro.
L'incontro si è concluso con un appello alla comunità affinché testi attivamente Leap 5.0 rc2 e fornisca un feedback al fine di garantire una transizione senza intoppi al rilascio stabile.
25 ottobre: Auguri e aspirazioni per il formato della chiamata degli operatori di nodi, ultimi obiettivi per raggiungere RC3
Argomento principale: Come continuare il Roundtable degli operatori di nodi
Riflessioni e Coinvolgimento:
Ross di EOS Sphere ha apprezzato le riflessioni del team tecnico.
Shaq ha sottolineato la necessità di informazioni Leap e approfondimenti tecnici.
Michael di EOSUSA ha riconosciuto l'impatto della collaborazione sulla maturazione del software.
Kevin Heifner, OCI, ha enfatizzato l'importanza del feedback dagli operatori di nodi.
Desideri per i Futuri Incontri:
Discussione sull'inclusione della documentazione nelle future chiamate.
Sono stati evidenziati diversi tipi di documentazione, tra cui documenti sul protocollo, operatori di nodi e sviluppatori.
Considerazione delle funzionalità in evoluzione e dei potenziali cambiamenti.
Richieste di esplorazione approfondita delle prossime funzionalità.
Formati delle Chiamate:
Si è discusso dell'idea di diverse chiamate per argomenti specifici, con i partecipanti che consideravano se le chiamate ad hoc o a breve durata sarebbero state preziose.
Sono state sollevate preoccupazioni che un passaggio a formati più ampi potrebbe involontariamente trasformare queste chiamate in incontri orientati agli sviluppatori, causando il disimpegno degli operatori di nodi.
Selezione dei Partecipanti:
I partecipanti hanno espresso il desiderio che sviluppatori esperti (ad esempio, Nathan James) si uniscano occasionalmente a queste chiamate. È stata proposta l'idea di uno scambio reciproco, portando Kevin Heifner agli incontri degli sviluppatori e sfruttando l'esperienza di Nathan per la documentazione e l'orientamento.
Il "dream team" dei partecipanti includerebbe Kevin Heifner, Nathan James e contributori regolari (Michael EOSUSA, Ross di EOS Sphere, Matthew Darwin). Potrebbero essere inclusi anche operatori di nodi con infrastruttura pesante come Aaron Cox (Greymass) e specialisti L2 come Stan di EOS Amsterdam.
Frequenza degli Incontri:
Inclinazione a mantenere un calendario settimanale.
Durata degli Incontri:
Suggerimento di mantenere gli incontri costanti per un'ora.
Considerazione di estendere per discussioni approfondite.
Orari degli Incontri Alternativi:
Sfida a interrompere le routine e frammentare la partecipazione.
Proposte chiamate aggiuntive in orari diversi.
Miglioramenti all'Agenda:
Suggerita un'agenda flessibile con aggiornamenti sullo stato e argomenti principali.
Valutazione delle Note degli Incontri:
Discussione sull'adeguatezza delle note degli incontri.
Raccomandato cercare il feedback delle persone assenti.
Registrazioni degli Incontri:
Nessuna preoccupazione riguardo alla registrazione degli incontri.
Note e Trascrizioni Generati da IA:
Note generate da IA benvenute, a condizione di registrazione attiva.
Aumentare la Partecipazione:
L'argomento finale riguardava l'aumento della partecipazione, con la suggerimento di coinvolgere attivamente i non partecipanti al fine di ampliare la partecipazione in queste preziose discussioni.
Parte relativa ai Obiettivi riguardanti l'aggiornamento Leap da RC2 a RC3
Si è posto l'accento sulla disponibilità della CPU per la firma delle transazioni, con un riferimento specifico a un parametro di configurazione, l'"offset di produzione del blocco", e strategie per ottimizzarlo per le massime prestazioni.
Sono stati delineati obiettivi, con un focus sulla risoluzione dei problemi per il prossimo candidato alla pubblicazione.
Sono state discusse alcune questioni critiche, tra cui i test BLS che hanno fallito nelle compilazioni ARM, con il lavoro in corso per affrontarle.
Parametri di Configurazione
L'impostazione corretta per il parametro "offset di produzione del blocco" è stata un argomento significativo, con la domanda posta da Ross e Kevin che ha fornito una spiegazione dettagliata su come questa sia migliorata nella prossima versione.
RC2 aveva un valore predefinito del 90% o 600 millisecondi, che è stato considerato troppo conservativo.
Nella nuova versione, il nuovo valore esprime l'offset in millisecondi, consentendo una regolazione più precisa. I partecipanti hanno discusso diverse impostazioni e i benefici potenziali, come un miglioramento del processo di transazione e una riduzione della latenza.
"Esiste un potenziale aumento della latenza per le transazioni che capitano di colpire il 12° blocco, ma solo per quelle che capitano di colpire l'ultimo blocco, quindi si tratta di un piccolo svantaggio rispetto a un vantaggio piuttosto grande per tutto il resto", ha affermato Kevin Heifner.
Il vantaggio più significativo si verifica durante i periodi di congestione della catena. Aiuta anche a gestire in modo più efficace le transazioni fallite, fornendo tempo aggiuntivo per la loro valutazione senza influire negativamente sulla capacità complessiva della CPU. In sostanza, ottimizza l'utilizzo della CPU.