Autore: Marco González

Editore: Randall Roland

Traduttore: Peter Valenčič

Gli operatori dei nodi, gli sviluppatori principali di Antelope e i membri della comunità si riuniscono ogni settimana per discutere le accattivanti domande del giorno. L'obiettivo principale di ogni tavola rotonda degli operatori di nodo è:

"...per migliorare il protocollo Antelope (in particolare) per gli operatori di nodi".

Riunione si svolgera ogni mercoledì dalle 14 UTC alle 15 UTC (dalle 13 UTC alle 14 UTC durante l'ora legale). Per coloro che desiderano apprendere le basi delle operazioni dei nodi EOS, EOS Network Foundation fornisce tutorial e documentazione.

La discussione sui nodi speciali è stata nuovamente rinviata. Invece, gli sviluppatori con core Antelope hanno fornito informazioni sulle versioni 4.0 e 5.0 di Leap nel mese di aprile 05 e 12 tavole rotonde rispettivamente. Gli sviluppatori principali hanno cercato di informare la comunità e acquisire feedback.

Questa settimana, il gruppo ha dato il benvenuto agli sviluppatori principali di ENF per fornire approfondimenti e demo della v4.0.0. Brian Hazzard ha fornito note che sono disponibili anche su EOS Nation GitHub per aprile 05. Guarda la tavola rotonda registrata sugli ENF Youtube.

Antelope v4.0.0 farà avanzare ulteriormente il dominio di EOS in termini di prestazioni, scalabilità e affidabilità rispetto ad altre blockchain. Le caratteristiche identificate (dalle note di Brian) includono:

Takeaways specifici (dagli appunti di Brian):

Dopo la panoramica di Brian c'è stata una presentazione di Lin Huang. In vista di transazioni (e attività) di sola lettura, Lin ha discusso:

Lin ha eseguito una dimostrazione < /cleos push transaction > e transazioni di sola lettura. Le caratteristiche principali delle transazioni (e attività) di sola lettura parallelizzate sono:

Gli elementi chiave presentati da Vlad per la pianificazione delle istantanee includono:

Ha descritto le istantanee ricorrenti come "la caratteristica più interessante". Le istantanee vengono popolate ogni 20 blocchi e continueranno fino a quando non verranno terminate. Gli snapshot non pianificati possono essere eseguiti con un ID.

Vlad ha anche menzionato un nuovo strumento (leap-util) che sta attualmente aggiungendo nuove funzionalità e avrà un supporto /cleos aggiornato.

Peter Oschwald ha dettagliato una procedura dettagliata del cablaggio delle prestazioni con un esempio e un report della riga di comando. Inizialmente si pensava di stabilire un modo migliore per eseguire le metriche delle prestazioni su diversi nodi operativi. Gli sviluppatori potrebbero quindi vedere come i loro miglioramenti potrebbero influire sulle prestazioni in tutto l'ecosistema.

Peter ha attraversato tre diversi livelli dell'imbracatura delle prestazioni: semplice, base e avanzato. Più avanzato è il livello, più parametri sono consentiti. Maggiori informazioni sul banco di prova e sulle configurazioni tipiche possono essere trovate nel README di Pefromance_tests [vedi 31:12 del video].

Peter prosegue descrivendo il generatore di transazioni, un sostituto del plug-in associato e la gestione di TPS di grandi dimensioni. Dopo aver esaminato più funzionalità, indica i piani per continuare a sviluppare metriche sulle prestazioni. Ad esempio, misurare se le prestazioni di nodeos stanno migliorando o peggiorando.

Kevin Heifner, che ha rapidamente passato in rassegna diversi argomenti prima di chiudere la riunione. Utilizzando gli appunti di Brian, Kevin ha esaminato quattro ampie aree di miglioramento e i relativi sottoargomenti:

Kevin ha continuato a testare come funziona attualmente il peering automatico. L'esempio è andato alla connettività relativa alla pianificazione BP.

Successivamente, ha fornito alcune note sul plug-in di esportazione Prometheus:

A conclusione dell'incontro, è stato menzionato che nodeos ha accesso alla directory (retain) ma non agli archivi. La storia dello stato segue lo stesso comportamento.

Kevin ha terminato con le micro-ottimizzazioni in cui i blocchi si propagano dopo una convalida dell'intestazione e non è necessario che si verifichino sul thread principale. Oltre a un miglioramento di 4 volte in get_block, la propagazione dei blocchi dovrebbe essere molto più rapida in un ambiente 4.0. Descrive come "è un periodo più veloce" e più della metà del processo (tempo) è stato spostato dal thread principale.

EOS è una blockchain più veloce che mai. Lo sviluppo della v4.0.0 da parte di Antelope renderà EOS sostanzialmente più veloce, efficiente e intuitivo per gli sviluppatori.

Gli sviluppatori principali di Antelope hanno fornito la loro visione di un ambiente 5.0 e hanno chiesto feedback. Sono stati fatti confronti con le operazioni esistenti, un ambiente 4.0 e la visione 5.0. Cerca le note della tavola rotonda del 12 aprile e un collegamento video su EOS Nation GitHub.

Le nuove funzionalità in arrivo con v4.0.0-rc3 sono dettagliate nel collegamento fornito.

L'orario di ufficio degli sviluppatori bisettimanale fornirà ulteriore supporto a coloro che partecipano alle riunioni della tavola rotonda. Stephen Diesel condurrà le riunioni. Il primo sarà il 20 aprile e ogni altro giovedì successivo. Sentiti libero di contattare Stephen su Telegram per saperne di più su CDT e altre cose relative agli sviluppatori (ad esempio DUNE, punti dolenti e i nuovi pod Antler).

Dato che un aggiornamento del consenso 5.0 è lontano mesi (forse all'inizio dell'autunno) l'incontro è stato meno strutturato del solito. I principali argomenti di interesse includono:

4.0 introdurrà il plugin Prometheus. Nel breve periodo in cui è stato sottoposto a test, i membri della comunità hanno chiesto di rendere disponibile il plug-in per l'esecuzione su una porta configurabile separata. Quello ora sembra essere un oggetto primario per 5.0.

Prometheus su un endpoint separato ha ispirato altre configurazioni di endpoint. Alcune categorie di endpoint proposte includono:

Le categorie non saranno configurabili con ogni endpoint. Piuttosto, gli endpoint saranno raggruppati in modi sensati. Ci sarà anche uniformità tra le categorie. L'impostazione predefinita sarà che tutti gli endpoint siano in una categoria in modo che il sistema possa funzionare come sempre.

Condivisa è stata una proposta intitolata “configurazioni personalizzate di porta/io”.

Un'altra priorità per 5.0 è l'introduzione di IPv6.

L'idea di categorie di endpoint efficienti sembrava andare bene. Alcuni feed e risposte iniziali includevano:

Così com'è oggi, get_info è generalmente reso pubblico. Tuttavia, negli ambienti peer (ad esempio i nodi produttori) è necessario che get_info rimanga non pubblico.

Si noti che ci sono opinioni forti sul mantenimento di get_info su tutti gli endpoint.

La tavola rotonda si è conclusa discutendo una sorta di modalità di recupero e soglia configurabile.

Brian ha chiuso l'incontro chiedendo alla comunità un ambiente da sogno per il 5.0. Ha fornito suggerimenti sulle aree in cui concentrare le proposte, ma ha sostenuto che il feedback dovrebbe essere praticamente illimitato:

La rete EOS è ora connessa a Ethereum tramite EOS EVM. 4.0 (nessun aggiornamento del consenso previsto) e 5.0 (aggiornamento del consenso pianificato) stanno facendo progressi con sicurezza. Entrambe le versioni migliorano la velocità e la funzionalità. EOS ha già superato di gran lunga le prestazioni nello spazio blockchain. Ora è il momento di realizzare i sogni.