Gli operatori di nodi, gli sviluppatori principali di Antelope e i membri della comunità si incontrano ogni settimana per discutere della rete e della sua 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 tengono ogni mercoledì. Visita il canale Telegram per informazioni su come partecipare. La Fondazione della Rete EOS fornisce tutorial e documentazione per coloro che desiderano imparare le basi del funzionamento di un nodo EOS.
Di seguito è riportato un elenco delle tavole rotonde contenute in questo riassunto bimestrale:
4 ottobre: Leap 5 Technical Highlights, posticipazione dell'aggiornamento del consenso a Leap 6
11 ottobre: Leap 5.0 RC2, miglioramento del processo di test, sfide nell'aggiornamento
Assicurati di cercare ulteriori note delle riunioni e commenti su GitHub. I video sono disponibili sul canale YouTube della ENF.
4 ottobre: Evidenziazioni tecniche di Leap 5.0, posticipazione dell'aggiornamento del consenso a Leap 6
Durante la discussione iniziale della tavola rotonda in ottobre, Brian Hazzard della ENF ha fornito una panoramica di diversi aspetti tecnici e sviluppi imminenti legati al prossimo rilascio di Leap 5.0. Successivamente, gli operatori di nodi hanno partecipato a una sessione di domande e risposte, affrontando argomenti come Prometheus RC1, esecuzioni di transazioni e altro.
Evidenziazioni tecniche di Leap 5.0
Riduzione dello stato di memoria: Si è raggiunta una riduzione del 20% dello stato di memoria, con la possibilità di una riduzione aggiuntiva del 6%. Utile per gli operatori di nodi EOS e potenzialmente anche per altre catene.
Anteprima delle note di rilascio: Brian Hazzard ha presentato una bozza delle note di rilascio e ha menzionato l'imminente rilascio di una guida all'aggiornamento. Ulteriori dettagli saranno condivisi sul canale Telegram degli operatori di nodi di Antelope.
Rimozione delle transazioni differite: Le modifiche rilevanti includono la rimozione delle transazioni differite tramite modifiche alla configurazione. Sarà inoltre incluso un elemento di protocollo per la loro rimozione.
Libreria BLS: Aggiunta per l'aggregazione di firme e l'implementazione della prova a conoscenza zero, in particolare nella base del codice di Leap.
Ottimizzazioni: Miglioramenti in termini di memoria, prestazioni CPU e capacità P2P. Queste ottimizzazioni migliorano la capacità dell'EOS EVM di gestire transazioni più grandi e primitive crittografiche. Inoltre, il processo di transazione nativa EOS ne beneficerà positivamente.
Miglioramenti dell'efficienza
Recupero asincrono dei blocchi: Il recupero asincrono dei blocchi viene introdotto, consentendo a nodeos di recuperare il prossimo batch di blocchi in modo indipendente. Questo processo agevola l'efficienza di sincronizzazione ottimizzando latenza e utilizzo della larghezza di banda con nuove impostazioni predefinite.
Selezione dei peer: Ora i peer sanno quali blocchi possiedi, semplificando la selezione dei peer in base alla disponibilità dei blocchi per ridurre i tempi di trasferimento.
Controllo della larghezza di banda: Una nuova impostazione consente di limitare la larghezza di banda massima allocata per il recupero dei blocchi, garantendo che la sincronizzazione non consumi tutte le risorse di larghezza di banda disponibili.
Riduzione della memoria di stato: Il contributo della comunità ha portato alla riconfigurazione delle strutture dati per la base della catena, con una riduzione del 20% dello stato di memoria. Ulteriori ottimizzazioni potrebbero portare a una riduzione aggiuntiva del 6%.
"Sono davvero entusiasta di molte cose in questo rilascio. I miglioramenti nel recupero dei blocchi sono davvero interessanti, come se non potessi fallire su 5.0, ottieni sempre informazioni indietro ed è 4 volte più veloce..." Kevin Heifner, OCI
11 OTTOBRE: Leap 5.0 RC2, miglioramento del processo di test, sfide nell'aggiornamento
La riunione è iniziata con un aggiornamento su Leap 5 RC1, che aveva una breve finestra di accesso prima di essere ritirato a causa di un bug. Ciò ha portato alla promozione di RC2 come il nuovo candidato al rilascio ufficiale. Man mano che le discussioni si concentravano sulle procedure di test, Eric Passmore (ENF) ha presentato un nodo API di accesso anticipato per migliorare i test, affrontando questioni come la registrazione dei bug e potenziali problemi di prestazioni. La ricerca di efficienza e di un processo di test più efficace ha trovato riscontro tra i partecipanti, con domande sull'aggiornamento dei BP e degli operatori di nodi.
Discussione sui test
"...anche i test semplici vanno bene. Saresti disposto a testare un po', e quale formato sarebbe il migliore?" Eric Passmore, ENF
Rilascio anticipato del nodo API per i test.
Focus sulla correzione dei bug, sulla registrazione degli errori e sui potenziali problemi di prestazioni.
Preferenza per i test del codice o del pacchetto di sviluppo?
Importanza dei test specifici basati sui valori.
Sfide degli operatori di nodi
Sfide legate ai nodi di cronologia di stato, alla gestione delle risorse e agli ambienti di test.
Necessità di una migliore coordinazione e comunicazione.
Piano e comunicazione
Richiesta di maggiore trasparenza nella roadmap di sviluppo di Antelope.
Comunicazione chiara per gli sviluppatori sulle modifiche e gli aggiornamenti.
Aggiornamenti di rete
Le ragioni per l'aggiornamento includono nuove funzionalità, miglioramenti delle prestazioni e l'evitamento dei fork.
"...c'è un'altra ragione principale per l'aggiornamento, che è che non si vuole che la catena faccia un fork..." Shaq
"...questi exchange probabilmente sono sulla versione 3.1, una versione stabile e funzionante, finché non spingiamo un aggiornamento del consenso a 5.0 probabilmente rimarranno sulla 3.1, perché tutto funziona." Michael, EOS USA
Build personalizzati su reti diverse.
Gestione dei build personalizzati e allineamento con la base del codice principale.
dApps e supporto L2
Importanza della compatibilità dei nodi e della scalabilità per le dApps.
Coordinamento con i fornitori di soluzioni di livello due.
Accordi in corso per transizioni fluide.
"...ci sono sicuramente alcune soluzioni chiave di livello due che sarebbe bello avere..." Michael, EOS USA
Differenze nei processi di aggiornamento
Processi di aggiornamento unici a causa di build personalizzati su reti diverse.
Gestione di personalizzazioni diverse e collaborazione con gli sviluppatori.
Personalizzazioni varie adattate alle esigenze specifiche della rete.
Gestione di personalizzazioni diverse su reti diverse.
Molto codice personalizzato su WAX, Ultra, UX, ecc. → questi sono molto più complicati da aggiornare.