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 è:
“...migliorare il protocollo Antelope (in particolare) per gli operatori dei nodi”.
Riunioni si verificano ogni mercoledì dalle 14 UTC alle 15 UTC (dalle 13 UTC alle 14 UTC durante l'ora legale). La EOS Network Foundation fornisce tutorial e documentazione per coloro che desiderano apprendere le basi del funzionamento di un nodo EOS (e altro).
Di seguito è riportato un elenco delle due tavole rotonde contenute in questo riepilogo bimestrale:
21 giugno: documento sui miglioramenti P2P che elenca il problema e le soluzioni
28 giugno: Block Trimming, Planning for Leap 5.0, IF, OC
Cerca ulteriori note e commenti sulla riunione Git Hub. Le registrazioni video risiedono sul YT di NFE.
21 giugno: documento sui miglioramenti P2P che elenca il problema e le soluzioni
L'incontro del 21 giugno ha continuato la discussione sul P2P. UN documento GitHub rispondere ad alcuni dei feedback delle ultime settimane ha guidato la discussione.
Panoramica
Il documento guida definisce chiaramente il problema. La definizione di una soluzione accettabile si allinea strettamente con il feedback precedente.
Aggiornamenti
Il patch 4.0.3 per LEAP è stato rilasciato durante l'incontro
Abbattere il documento guida sui miglioramenti P2P
La pagina del documento guida è suddivisa in diverse sezioni: Problema, Soluzione, Problemi, Risorse e Commenti.
Problema: opportunità, pubblico e strategia
Ci sono esigenze diverse per i gruppi di utenti mirati. Le priorità ora sono meglio comprese.
Il pubblico identificato è basato su Antelope e:
"individui tecnicamente competenti" (operatori di nodi) interessati a "soluzioni affidabili, convenienti e semplificate"
Per allineare il problema con lo sviluppo di base, è necessario concentrarsi su “migliorare l'esperienza dell'utente e l'efficienza dell'infrastruttura”. L'implementazione di successo prevede di produrre "adozione più ampia e successo del protocollo Antelope".
Tornando alle opportunità degli utenti target, le priorità principali sono le seguenti:
Il più alto nell'elenco è "migliorare la selezione dei pari in modalità catch-up per i blocchi disponibili".
La larghezza di banda è stata una discussione comune nelle ultime settimane. Migliorare i controlli del "consumo di larghezza di banda tra pari" è la prossima priorità. Evitare gli abusi e la rotazione automatica dei pari sono punti focali.
La terza priorità principale è la "capacità di etichettare le connessioni peer come interne o esterne". Riuscire qui si aspetta di risolvere "fiducia (livelli) all'interno dell'infrastruttura interna".
Vedere il documento e/o il video per le descrizioni di altri problemi, tra cui un'interfaccia utente basata su terminale, blacklist peer e sincronizzazione.
Definire una soluzione e identificare i rischi
Il nome dato all'opportunità del prodotto sopra descritta è "Miglioramenti P2P". Le quattro metriche principali per il successo, elencate nel file su GitHub:
Migliora il tempo di sincronizzazione per un nodo nuovo o riavviato
Ridurre il numero di passaggi per configurare un nuovo nodo
Migliora l'affidabilità delle transazioni che transitano sulla rete P2P
Migliora la velocità delle transazioni che transitano sulla rete P2P
Il processo di identificazione dei rischi è guidato da un articolo (I quattro grandi rischi) scritto dal Silicon Valley Project Group. La domanda posta è incentrata sulla RFP P2P Peer Discovery relativa alle tempistiche parallele:
"C'è qualche rischio di conflitto o sovrapposizione?"
Consulta la pagina della documentazione per ulteriori risorse e problemi.
Commenti e feedback sulle riunioni
Le risposte dei partecipanti includono:
nodi interni e colli di bottiglia
la velocità di archiviazione è fondamentale
bloks-log menzionato come preoccupazione per quanto riguarda la lettura e i peer locali (ad es. numero di operazioni e sincronizzazione)
opzioni di sincronizzazione limitate
larghezza di banda rispetto all'intervallo di stato (potrebbe non essere un problema se larghezza di banda sufficiente e peer rotanti)
Dialogo conclusivo
L'incontro si è concluso con domande di chiarimento. È stata fatta un'indagine sul throttling (rallentamento) come strategia di gestione della larghezza di banda. Dal feedback, la limitazione è considerata un'opzione rispetto alla disconnessione dei peer.
Il team di sviluppo invita gli operatori dei nodi ad aiutare a guidare il corso dei prossimi passi. È stata richiamata l'attenzione sulla sezione di suddivisione delle attività ("Caratteristiche/Epic") della pagina del documento. Qui sono stati menzionati la larghezza di banda ei meccanismi di controllo.
28 giugno: Block Trimming, Pianificazione
per Leap 5.0, IF, OC
La riunione del 28 giugno ha individuato nel taglio dei blocchi un'area da migliorare. La pianificazione per Leap 5.0 include tempi di preparazione, nuovi standard, IF, OC e altro.
Panoramica
Gli operatori dei nodi hanno condiviso la loro esperienza con l'attuale processo di taglio dei blocchi. Sono stati discussi diagnostica, automazione e altri tipi di soluzioni. L'ultimo terzo dell'incontro ha discusso della pianificazione e dei preparativi per Leap 5.0.
Aggiornamenti
non ci sono nuovi aggiornamenti su Leap 4.0
il team di sviluppo continua a rielaborare un programma provvisorio 5.0 per una release candidate
Maggiori informazioni su Leap 5.0 in una sezione successiva.
Preoccupazioni della comunità
La sala era aperta per ascoltare le preoccupazioni che persistono nelle menti della comunità. La discussione è iniziata sul taglio dei blocchi e sui diversi problemi per l'attuale aspettativa 4.0.3 rispetto a 5.0. La rifilatura dei blocchi ha suscitato un interesse immediato. L'utilizzo di leap-util per tagliare una soluzione per un'eccezione di bloks-log ha suscitato diversi commenti. La necessità di estendere il taglio a diverse centinaia di blocchi sembra poter essere migliorata. I tagli più piccoli che possono identificare gli errori (eccezioni) sono una caratteristica interessante da aggiungere.
Argomenti discussi in modo più approfondito
Due argomenti sembravano risuonare dal discorso di apertura:
formattazione e contenuto di leap-util (ad es. smoke test)
è necessario eseguire il rollback di bloks-log
Di seguito è riportato un elenco delle specifiche citate. Le voci dell'elenco seguono un ordine cronologico e logico generale registrato durante la riunione:
visualizzazione vs. funzionalità
potenziali miglioramenti per il taglio minimo
garantendo una soluzione sicura
suggerito di aggiungere ritagli successivi (uno per uno).
uno strumento diagnostico di taglio potrebbe determinare blocchi corrotti
soluzione di riparazione automatica che fa attenzione a non rimuovere automaticamente i blocchi
soluzioni di nodi pubblici e privati
la correzione completa tramite snapshot rimanda alle avvertenze relative ai nodi pubblici e privati
La comunità sembra desiderare strumenti diagnostici e di ripristino più semplici. Per maggiori dettagli, visitare il
PIANIFICAZIONE PER LEAP 5.0
Come accennato in precedenza, è iniziata la pianificazione per una candidata al rilascio di Leap 5.0. Il team di sviluppo lavora per mitigare il lungo e complicato processo coinvolto in un aggiornamento del consenso. Leap 5.0 stabilirà una procedura standard. Sono necessari un paio di mesi per preparare la comunità. I piani si concentrano su un rilascio prima delle vacanze, iniziando quindi un'implementazione a settembre.
Le aspettative sono che Leap subirà due importanti rilasci all'anno. Uno dei quali probabilmente richiede un aggiornamento del consenso. La riduzione dei costi operativi dei nodi è tra le principali preoccupazioni. Ciò include riduzioni dei costi per gli operatori dei nodi durante l'aggiunta di nuove catene. Sono stati fatti commenti sui vantaggi dell'esperienza e dell'ottimizzazione (RAM, CPU e spazio su disco). È stata sottolineata l'importanza per più persone di passare alla versione 4.0.
Due funzionalità principali di aggiornamento del protocollo per 5.0 sono:
Finalità istantanea (IF)
Ottimizzazione delle funzionalità del compilatore (OC).
SE sembra essere il punto decisivo dei due. IF rimane un'iniziativa chiave del piano iniziale dell'ENF per la Nuova EOS. Le funzionalità OC sono vantaggi prestazionali intesi principalmente a migliorare EVM. Tuttavia, ci sono vantaggi complessivi OC che includono i produttori. Vedere "Add eos-vm-oc-enable auto mode #1322" per maggiori informazioni.
Altri elementi si stanno sviluppando in parallelo, previsti nelle versioni future per non ritardare la 5.0.
Dialogo conclusivo
L'incontro si conclude con un esame delle funzionalità OC per 5.0. Lo sviluppo attuale riguarda miglioramenti fondamentali. OC dovrebbe prima essere eseguito sui contratti del sistema eosio (ad esempio per token ed EOS EVM) prima delle altre funzionalità menzionate. Le nuove funzionalità e la preparazione per Leap 5.0 rimarranno probabilmente al centro degli incontri futuri.
Fonti & Riferimenti