Vai al contenuto principale
Tutte le collezioniEOS Support Media
Riepilogo della tavola rotonda dell'operatore di nodo bimestrale [luglio 2023 n. 2]
Riepilogo della tavola rotonda dell'operatore di nodo bimestrale [luglio 2023 n. 2]

Pubblicato il 4 agosto 2023

Dario Cesaro avatar
Scritto da Dario Cesaro
Aggiornato più di un anno fa

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 tavole rotonde contenute all'interno di questo riepilogo bimestrale:

  • 19 luglio: modifiche alla configurazione consigliate da ENF per la versione 5.0

  • 26 luglio: annullato

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

19 luglio: modifiche alla configurazione consigliate da ENF per la versione 5.0

Il 19 luglio tavola rotonda potrebbe rivelarsi il punto in cui la comunità degli operatori di nodi sposta la sua attenzione da Antelope v4.0 a v5.0. L'azione intrapresa per preparare l'implementazione 5.0 probabilmente inizia con le modifiche alla configurazione dell'ENF discusse nella riunione odierna.

PANORAMICA

Eric Passmore ha pubblicato note su Telegram che delineano le raccomandazioni dell'ENF per le modifiche alla configurazione dei nodi. I punti principali delle note sono elencati nella sezione seguente.

Eric ha iniziato portando l'attenzione su quanto è cambiato da quando B1 ha rilasciato la versione 2.0. La modifica della configurazione ha senso su così tanti livelli. Tuttavia, l'ENF basa le sue raccomandazioni sia sui test delle prestazioni che sui dati empirici.

ARGOMENTO: Raccomandazioni pubblicate dal canale Telegram degli operatori di nodo del 18 luglio

Il primo elemento identificato sono le transazioni all'interno dell'ambiente di produzione che superano i 30 ms. È qui che spicca l'aggiornamento della transazione read_only aggiunto in Leap 4.0. L'aumento dei limiti avvantaggia immediatamente sia le transazioni read_only che quelle dell'ambiente di produzione generale.

Le modifiche alla configurazione suggerite da ENF nel luglio 2023 (come pubblicato da Eric Passmore) sono i seguenti.

1. Per modifiche alla configurazione di sola lettura,sono interessate solo le versioni Leap 4.0 e successive:

  • "(165ms) finestra di sola lettura-lettura-time-us a 165.000"

  • "(151 ms) tempo massimo di transazione a 151"

2. Per le modifiche multisig, solo il testnet Jungle è interessato (al momento). Non sono ancora necessarie modifiche per la mainnet:

  • "(150ms) max_transaction_cpu_usage a 150.000"

  • "(200ms) max_block_cpu_usage a 200.000"

Aspettatevi che le modifiche suggerite rimangano incentrate sul Jungle TestNet fino a quando un piano di implementazione non sarà coordinato con la riunione settimanale degli operatori dei nodi.

Le modifiche suggerite precedono la configurazione predefinita che prevede di accompagnare il rilascio della versione 5.0. Il post di Eric si conclude con la notifica che le impostazioni di configurazione saranno tra gli elementi tracciati per garantire che sia i produttori che le catene abbiano le stesse impostazioni per garantire un'implementazione coordinata della versione 5.0.

Discussione della riunione

Eric si è unito alla tavola rotonda per discutere le modifiche consigliate. La comunità non ha avuto bisogno di impegnarsi in molte discussioni per comprendere l'intento dell'ENF. Né ci sono state obiezioni.

Gli argomenti discussi brevemente includono:

  • chiarimenti temporali

  • l'aumento da 30 a 151 millisecondi fornisce ampio respiro

  • aspettatevi un paio di settimane di test su Jungle per nuove modifiche

  • l'enfasi sulla fluidità del coordinamento inizia con le modifiche alla configurazione

  • sufficienza della fatturazione soggettiva per gli errori di transazione

La fatturazione soggettiva aiuta a scoraggiare le transazioni non riuscite in base al costo della CPU e alle modifiche alla configurazione.

Tieni presente che è impossibile simulare perfettamente l'attività sulla rete EOS. Potrebbe essere necessario modificare le modifiche pianificate. Ulteriore considerazione dovrebbe essere data a ciò che potrebbe andare storto (soprattutto per quanto riguarda i produttori di blocchi).

È a questo punto che è stato suggerito un nuovo post sul blog. Gli operatori di nodo sono menzionati più volte nel post del blog del 24 maggio Introduzione alla fatturazione soggettiva e alle transazioni perse.

Altre menzioni degne di nota relative alle modifiche alla configurazione includono test di prestazioni/benchmark. C'è la certezza che le configurazioni reggeranno.

Versione 5.0, fatturazione soggettiva e rimozione dei blocchi più rapida

How will Antelope Leap version 5.0 get blocks out faster? The May 24 post (mentioned above) introduces subjective billing updates:

“Le nuove funzionalità di Mandel 3.1 consentiranno agli operatori dei nodi di impostare il parametro del tempo di decadimento della fatturazione soggettiva del proprio nodo al momento dell'inizializzazione. Questa opzione regolerà il tempo necessario per azzerare la fattura soggettiva di un account.”

The August 8 announcement, Leap v3.1 Release Features & Additional Tools, outlines new transaction lifestyle tools:

“Gli articoli precedenti hanno esplorato il modo in cui il sistema di fatturazione soggettiva può causare transazioni perse e delineato le soluzioni esistenti per problemi comuni del ciclo di vita delle transazioni come le transazioni perse. La versione Leap v3.1 introduce nuovi strumenti per affrontare questi problemi e altri ostacoli all'esperienza utente.”

Sono in arrivo miglioramenti profondi man mano che il sistema di fatturazione soggettiva si sviluppa con la versione 5.0. Invece di transazioni non applicate in coda, il blocco successivo può iniziare immediatamente. È stato addirittura suggerito che 12 blocchi possano essere completati in un singolo ciclo. Si è raccomandata cautela riguardo al controllo dell'ultimo blocco.

La riunione si è conclusa presto mentre la comunità guarda avanti per coordinarsi per la versione 5.0.


Fonti & Riferimenti

Hai ricevuto la risposta alla tua domanda?