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.

Le prime due tavole rotonde di marzo hanno proseguito la discussione sui Nodi Speciali, in particolare per quanto riguarda le best practices. La tavola rotonda del 1 marzo ha esplorato gli obiettivi di BP Nodes rispetto alle migliori pratiche. L'8 marzo si è concluso con i nodi di inoltro solo blocco. Se sei qui per l'imminente "blocco del codice", aspettati un annuncio entro pochi giorni dalla tavola rotonda dell'8 marzo. Per quanto riguarda una versione testnet di Leap 4.0.0, il team di sviluppo rimane nei tempi previsti per l'obiettivo di fine marzo/inizio aprile.

La "bozza di tassonomia dei ruoli svolti dai diversi nodi di antilope" contiene note complete. Per esplorare l'inizio della discussione sui nodi speciali, visita la sezione intitolata "Riunioni post aggiornamento" su GitHub.

Guarda la tavola rotonda del 1° marzo su YouTube dell'ENF. Leggi le note su EOS Nation (Leap) GitHub.

La tavola rotonda del 1 marzo è la quarta di una discussione in corso sui nodi per scopi speciali. Tra i problemi ci sono modelli di risorse più efficienti in tutto l'ecosistema. Ciò include una regola dei tre colpi rispetto alle esigenze di fatturazione soggettive.

Il gruppo ha raccolto annotazioni sui fornitori di storia. I tipi di nodi primari che menzionano specificamente la cronologia nella bozza del documento includono:

Layer-2 le soluzioni che menzionano la storia includono:

Per quanto riguarda la "storia dello stato", tra le questioni ci sono:

Inoltre, vedere i suggerimenti di follow-up per la cronologia.

L'elenco dei tipi di nodo si conclude con il nodo del provider di risorse, la terza soluzione di livello 2 nell'elenco. Il suo obiettivo è migliorare l'esperienza dell'utente. Sebbene il nodo del provider di risorse esegua attualmente node.js, alla fine potrebbe diventare decentralizzato come un plug-in API. La bozza del documento di tassonomia definisce il nodo del fornitore di risorse come:

L'incontro è proseguito con le best practice e l'impegno ei requisiti per una configurazione ottimale. Un obiettivo chiave per le migliori pratiche include l'identificazione dei minimi nelle reti Antelope (ad esempio WAX, Telos...).

Probabilmente ci saranno dibattiti sulle migliori pratiche, soprattutto considerando le diverse esigenze tra le reti. Ad esempio, tutti i seguenti variano in base all'utilizzo della rete blockchain:

I requisiti del dispositivo hanno preso il sopravvento sulla discussione sulle best practice. Gli operatori dovrebbero controllare la configurazione complessiva di nodeos quando cambiano un tipo di nodo. Ad esempio, l'esecuzione con avvii e arresti rispetto a quella ininterrotta dovrebbe risintonizzare una CPU secondo i consigli di AtticLabs. Consulta la bozza del documento di tassonomia per il collegamento AtticLabs e altri requisiti del dispositivo come RAM ECC, processori x86 e altro.

A chiudere la tavola rotonda sono state le note sulle migliori pratiche di sicurezza e sul non riutilizzo delle chiavi hardware.

Chain API Node ha ricevuto alcune parole finali riguardanti le migliori pratiche di configurazione di nodeos per Block Producer Nodes. Le raccomandazioni includono:

La discussione su Chain API Node si è conclusa su ciò che dovrebbe essere disponibile (ad esempio semplificando solo con Getinfo, sebbene Prometheus possa altrimenti fornire una soluzione).

Tieni presente che alcuni tipi di nodi richiedono configurazioni variabili. La riunione si chiude con ulteriori elementi di follow-up (nella sezione Fasi successive della bozza del documento di tassonomia).

Guarda la tavola rotonda dell'8 marzo su YouTube dell'ENF. Leggi le note su EOS Nation (Leap) GitHub.

Il team di Antelope riferisce di essere sulla buona strada per un candidato al rilascio di fine mese/inizio aprile. Lo sviluppo incentrato sul futuro di Antelope Leap 4.0.0 si è concluso per il momento. Un annuncio su un "blocco del codice" è imminente. Una release candidate 4.0.0 prevede di seguire entro un paio di settimane.

La discussione iniziale ha rivisitato le migliori pratiche di configurazione di nodeos per Block Producer Nodes. Il peering è quasi sempre interno. La protezione di una rete di nodi interni con una chiave WireGuard (ad esempio) è efficace. WireGuard è solo un'opzione. Tali chiavi impediscono connessioni impreviste e fastidiose.

Scenari di casi d'uso speciali (ad es. risincronizzazione) sono stati aggiunti agli elementi di follow-up nella sezione Passaggi successivi. Si consigliava inoltre di considerare l'aumento dell'efficienza.

Il resto della tavola rotonda si è concentrato sui nodi di inoltro solo blocco e sulle loro migliori pratiche di configurazione. Il gruppo è andato nei dettagli sul numero di connessioni. In una riunione precedente, sono state ritenute appropriate per il file di configurazione da 10 a 15 connessioni. Questo piccolo intervallo di connessione è solo un punto di partenza.

Per quanto riguarda Leap 3.2, il massimo delle connessioni Block-only Relay Node tra 25-50 è sicuro. Diverse note aggiunte sono state:

La prima considerazione menzionata per i requisiti del dispositivo Block-only Relay Node è stata che è necessario più di uno per evitare un singolo punto di errore.

Gran parte del resto della discussione si è concentrata su connettività e velocità. Una connessione internet affidabile è stressata. Quindi era un disco veloce con un focus di scrittura pesante. Vedere altre best practice nella bozza del documento di tassonomia per i commenti sui registri di blocco completi e parziali. Si noti che Leap 4.0 prevede di avere una funzione di connessione a nodo automatico.

Qui viene fatta un'importante distinzione riguardo a un malinteso popolare. Sulle catene Antelope, un'istantanea è solo lo stato corrente. È diverso dalla definizione di Ethereum. Pertanto, per le catene Antelope, una rete peer necessita solo di un registro di blocco completo. Non è necessaria una cronologia completa per i relè interni sulle catene Antelope.

MIn tutta la discussione sulla bozza della tassonomia è menzionato l'impatto dell'adeguamento delle variabili al di fuori delle migliori pratiche. Ad esempio, un nodo di inoltro solo blocco puro non accetta nient'altro che blocchi. Inoltre, tieni presente che Leap 4.0 potrebbe non richiedere nodi di inoltro solo blocco.

Aspettatevi che la tavola rotonda della prossima settimana continui la discussione sulle best practice per la configurazione dei nodi specifica per i nodi API.