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”.
Gli incontri si svolgono ogni mercoledì dalle 14 UTC alle 15 UTC.
A partire dal 1° febbraio, le discussioni della tavola rotonda di Node Operator si sono concentrate sui parametri di configurazione per Leap v3.2 e versioni successive. I nodi per scopi speciali hanno trovato inclusione l'8 febbraio. I nodi dedicati per scopi speciali hanno consumato le riunioni del 15 e 22 febbraio. Il gruppo ha continuato a portare avanti il documento "bozza di tassonomia dei ruoli svolti dai diversi nodi di antilope".
15 febbraio: Nodi per scopi speciali (continua) - Nodi API
Guarda la tavola rotonda del 15 febbraio su YouTube dell'ENF. Leggi le note su EOS Nation (Leap) GitHub.
AGGIORNAMENTO:
Aome discusso in precedenza, Leap v4.0.0 prevede di iniziare i test su Jungle a marzo. Un aggiornamento del consenso probabilmente non avverrà fino a settembre. Inoltre, aspettati un blocco del codice prima dei primi test nelle prossime settimane.
ARGOMENTI "CHIAVE" DISCUSSI
L'ultima riunione è stata interrotta con i nodi API. La riunione del 15 febbraio ha rivisitato le definizioni fondamentali per i tipi di nodo. Questa settimana sono stati introdotti un paio di tipi di nodo, insieme a uno stimatore di transazioni. Vedere la tassonomia del nodo antilope (bozza) per i dettagli.
Informazioni sui tipi di nodo
Le classificazioni del tipo di nodo sono state definite per la prima volta la scorsa settimana. L'attenzione era rivolta agli scopi primari.
Tipi di nodi discussi in precedenza
Block Producer Node, obiettivi primari e configurazione delle best practice
Nodo di inoltro solo blocchi e configurazione delle best practice
Nodo di inoltro di blocchi e transazioni
Inizio del focus sui nodi API
Due tipi di nodi API primari identificati erano:
Push API Node: “Accetta transazioni tramite client HTTP e funge da Transaction Relay in uscita.”
“Non accetta transazioni p2p in entrata, a meno che non agisca anche come Blocks & Transactions Relay Node.”
Chain API Node: “Fornisce l'accesso per leggere le primitive blockchain... e i dati di stato...”
I tipi di nodo della cronologia hanno requisiti molto diversi rispetto a quelli che un nodo API della catena può fornire.
Vedere la bozza del documento di tassonomia per note dettagliate e una potenziale discussione dedicata.
A chiudere le classificazioni dei tipi di nodo questa settimana sono state le seguenti ampie utilità:
Developer Node: per il test, soddisfa tutti i ruoli del nodo su un dispositivo locale all'interno di una rete a nodo singolo
Consulta la bozza del documento per qualche dettaglio in più.
Transaction Estimator: accetta, convalida e applica le transazioni senza inoltrarle alla rete
Consulta la bozza del documento per qualche dettaglio in piu.
Altri due tipi di nodi (classificati come "feeder" durante la discussione della prossima settimana) erano::
Snapshotting Node: esegue periodicamente uno snapshot e pubblica un file su un host interno/esterno
Consulta la bozza del documento per qualche dettaglio in più.
Trace API Node: registra le informazioni di traccia transazionale sul disco locale di un client per accedervi tramite API.
Soluzioni "Layer-2"
Un nodo del provider di risorse è stato tra le prime soluzioni di livello 2 identificate:
Nodo fornitore di risorse: accetta, interpreta, convalida ed esegue la logica aziendale sulle transazioni client per determinare se un cosign è garantito per coprire i costi CPU/NET/RAM
È stata inclusa una nota sul servizio del nodo del provider di risorse che potrebbe evolversi in una soluzione plug-in chiavi in mano.
VEDUTA
Diversi argomenti coincidono con la discussione sui tipi di nodo e sulle potenziali soluzioni di livello 2. Includono la redazione di best practice tra i tipi di nodo, possibilmente esplorando pacchetti di nodi speciali e flag integrati per impostazioni predefinite di configurazione.
22 febbraio: Nodi per scopi speciali (continua) - Feeder e Layer-2
Guarda la tavola rotonda del 22 febbraio su YouTube dell'ENF. Leggi le note su EOS Nation (Leap) GitHub.
AGGIORNAMENTO:
L'ENF prevede di esaminare le funzionalità di Leap v4.0.0 prima del blocco del codice precedentemente menzionato. Controlla la data della tavola rotonda che illustra le nuove funzionalità.
ARGOMENTI CHIAVE DISCUSSI
La discussione sui nodi per scopi speciali è proseguita con il feedback sul documento di tassonomia dei nodi di antilope (bozza). Le note dettagliate sulla riunione sono disponibili qui. Sono stati introdotti un nodo DeepMind Logger e un nodo Cronologia stato nell'avanzamento di una soluzione di livello 2. I servizi di storia sono di particolare interesse qui.
Si noti che è stata accennata l'idea del "caricamento prioritario". L'idea è di istituire una regola dei 3 colpi per risolvere un problema di vecchia data (bot). Il caricamento prioritario sembra efficace anche quando si affrontano gli impegnativi problemi di transazione di WAX. L'estensione dei tempi da mezzo secondo a pochi secondi "ripulisce" un nodo. La soluzione non modificherebbe in modo significativo le operazioni esistenti (per la maggior parte). Estendere il caricamento prioritario a un minuto o due sarebbe eccessivo. Una soluzione precisa ed efficiente anche se l'argomento non si presentava nella registrazione.
Concettualizzazione dei nodi di alimentazione (feeder)
Vedere la sezione precedente per una parola sui tipi di nodo. Entrambi i tipi di nodo feeder hanno discusso del lavoro ricevendo blocchi da peer configurati. Entrambi aiutano anche ad abilitare soluzioni cronologiche di livello 2:
DeepMind Logger Node: “serializza continuamente il blocco corrente, le tracce, ecc. e li trasmette in stdout per ulteriori elaborazioni...”
State History Node: “memorizza blocchi/tracce in un file di cronologia dello stato...”
Soluzioni Layer-2
Dopo i pensieri della scorsa settimana sulle soluzioni di livello 2 c'erano un paio di servizi in più. La formattazione è stata la chiave della discussione.
Event Capture Service: Affronta il compito di elaborare gli output del nodo alimentatore in formati per scopi speciali per garantire gli scopi previsti. Come esempio è stato utilizzato un servizio provider di cronologia.
History Provider Service: un servizio di base disponibile in qualsiasi formato che fornisce dati storici su richiesta di un cliente tramite un'API
Si noti che il servizio Event Capture deve gestire la risoluzione fork.
VEDUTA
IOltre agli elementi di outlook elencati per il 15 febbraio, molti altri elementi sono stati elencati in Passi successivi: vedere la (bozza) tassonomia del nodo antilope per i dettagli. Le soluzioni Layer-2 dovrebbero continuare la prossima settimana. Inoltre, è necessario definire una matrice delle caratteristiche per gli alimentatori.