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 è:

Tavola rotonda avviene ogni mercoledì. Visita il canale Telegramm per informazioni sull'adesione. 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 tavole rotonde contenute all'interno di questo riepilogo bimestrale:

Cerca ulteriori note e commenti sulla riunione Git Hub. I video risiedono sul YT di NFE.

La tavola rotonda del 2 agosto non è stata registrata. Quella che segue è una conversazione aperta su cosa aspettarsi nelle settimane che precedono l'aggiornamento del consenso di Antelope Leap 5.0. Data la natura critica e la tempistica desiderata, aspettatevi che la tavola rotonda diventi più formale (come condotta nelle versioni 3.0)..

La pianificazione per un aggiornamento del consenso è stata toccata nelle ultime settimane. La prossima tavola rotonda prevede di introdurre il programma di lancio.

Il programma di lancio di Leap 5.0 metterà in evidenza gli elementi essenziali e non essenziali. Alcune caratteristiche sembrano già pronte, mentre restano dubbi su altre. Solo un paio di elementi potrebbero giustificare il ritardo del lancio.La finalità istantanea (IF) è un elemento di lancio critico. Rimane al centro delle discussioni della tavola rotonda durante la fase iniziale.

Le discussioni della comunità dovrebbero anche concentrarsi su:

In attesa dell'annuncio della programmazione, la community ha identificato alcuni elementi straordinari. A guidare il feedback è stato Michael di EOSUSA:

Alcune altre preoccupazioni includono:

Sebbene l'ENF abbia svolto un lavoro eccellente nel perfezionare la documentazione di base su docs.eosnetwork.com, Leap 5.0 offre un'opportunità unica. Gli aggiornamenti del consenso sono impegnativi a causa dell'immenso sforzo di coordinamento con tutte le parti (attive). I BP devono agire insieme entro un periodo di tempo concordato per completare un multisig. La configurazione dei dispositivi è una preoccupazione sia dei BP che degli operatori dei nodi.

Mantenere una rete sicura e funzionante è l'obiettivo finale. Un'altra iniziativa per la v5.0 è tostabilire un nuovo standard per il processo di aggiornamento del consenso. La nuova documentazione è parte integrante dello sforzo. Alcuni suggerimenti per la nuova documentazione includono modifiche alla configurazione tra le versioni e l'introduzione di nuove funzionalità (ad es Ottimizzazione del compilatore). Sono state suggerite anche le notifiche sulle configurazioni specifiche per le modifiche preesistenti (per le versioni 4.0) che facilitano il passaggio alla transizione v5.0.

Ancora una volta, aspettatevi che la prossima tavola rotonda assuma un'ambientazione più formale simile ai mesi di sviluppo e lancio della versione 3.0, il prodotto di successo di ENF. La combinazione di velocità e qualità dei prodotti recenti della fondazione (da diverse versioni 4.0 a ora 5.0) è semplicemente impressionante

La Tavola rotonda del 9 agosto è stata registrata ed è disponibile. L'ENF ha condiviso il piano per lanciare Leap v5.0.

Gli argomenti chiave discussi nella tavola rotonda del 9 agosto includono:

Sebbene le date possano cambiare, il programma presentato alla tavola rotonda del 9 agosto rappresenta l'ordine delle operazioni per il lancio di Leap v5.0.

La prima, importante pietra miliare è prevista per metà settembre con la release candidate (5.0.0-rc1). Diverse attività devono essere completate prima di ricevere la chiamata go/no-go dai BP. Quello include:

La chiamata go/no-go si basa sull'attivazione da parte dei BP. Quella chiamata è (provvisoriamente) programmata per la fine di novembre / inizio dicembre. Il contratto di sistema deve essere aggiornato prima di abilitare la finalità immediata. Dall'attivazione alla distribuzione IF prevede di impiegare circa una settimana. Si spera che IF sarà attivo e funzionante su EOS entro l'inizio di dicembre.

La comunità si aspetta di condurre future discussioni sulla programmazione. La peer discovery e le transazioni di sola lettura difficilmente ritarderanno Leap v5.0. Entro settembre, il team prevede di avere una data di lancio fissa o semi-fissa.

Oltre SE, test di riproduzione è l'altra caratteristica che potrebbe alterare significativamente il piano di lancio (vedi tavola rotonda del 2 agosto).

Un argomento di interesse si verifica intorno al segno dei 7 minuti. La discussione si è incentrata sul taglio di una versione candidata e sul replay testing. Un fattore determinante sarà il confronto degli hash di integrità delle successive istantanee più riproduzioni di blocchi. Si noti che l'aggiornamento a Leap v5.0 non richiederà una risincronizzazione del registro dei blocchi.

Rimangono dei problemi sulla conduzione di un replay completo di Genesis. Micheal di EOSUSA ha sollevato i problemi di regressione (ora risolti) e il tempo fino al completamento. Il team di sviluppo si concentra sul lancio della v5.0 con un replay del log dei blocchi. Indagare sui replay di Genesis è qualcosa che il team ha tenuto a mente per un futuro aggiornamento.

Un'altra energica discussione è iniziata quando è stato menzionato il testnet di Kylin. Mathew di EOS Nation ha raccomandato di non eseguire Kylin in parallelo con il testnet Jungle. Ciò che è seguito è stato un cambiamento di programmazione che ha mantenuto le date obiettivo per includere un Kylin eseguito entro metà ottobre. I test devono essere completati prima del rilascio stabile pianificato di Leap v5.0.0 prima di novembre.

Le transazioni differite sono ora deprecate. Idealmente, verrebbero rimossi per la v5.0. Se le transazioni posticipate rimangono nella versione 5.0, potrebbero persistere per un altro anno. Non è noto se eventuali contratti dipendano da loro.

Sono allo studio due decisioni per rimuovere le transazioni differite. La prima soluzione consente di fare marcia indietro. Tuttavia, l'attuazione richiederebbe molto tempo.

L'altra opzione, più ragionevole, prevede che i BP eseguano un test che disabilita brevemente la funzione. Quindi il feedback della comunità potrebbe determinare il destino delle transazioni differite. Nessun progetto è noto per fare affidamento su transazioni differite.

Per la prossima settimana, aspettati che la discussione si concentri nuovamente sul lancio di Antelope Leap v5.0.