Il Leap 3.2 è stato rilasciato, ed è stato rivelato in questa tavola rotonda. Inoltre, è stato discusso il problema fondamentale dello State Database, il suo utilizzo di RAM astronomicamente elevato. Sono state esplorate potenziali correzioni a lungo e breve termine, nonché compromessi..

Inoltre, un breve riassunto delle specifiche dei miglioramenti del plug-in NET è stato fornito dall'ENF a conclusione dell'incontro, in cui è stato anche deciso il programma per la seguente tavola rotonda: Prometheus Exporter di Leap 4.0 presenta statistiche per la scatola nera nodEOS . 13 partecipanti si sono uniti alla tavola rotonda questa volta

Lo sviluppo del software è l'argomento principale di discussione durante le sessioni settimanali della tavola rotonda degli operatori di nodi EOS. Sviluppatori, produttori di blocchi, ingegneri blockchain e membri della comunità che desiderano saperne di più sul processo di sviluppo di EOS beneficiano tutti della conoscenza che fornisce..

Un ecosistema può crescere in modo sano e naturale condividendo e interagendo spesso. La EOS Network Foundation ha ricevuto commenti favorevoli sui suoi progressi da BP e sviluppatori. La comunità EOS è consapevole del fatto che la sua voce è ora apprezzata e ascoltata. Ultimo ma non meno importante, si stanno dando risposte alle preoccupazioni della comunità.

Riepilogo degli aggiornamenti di Antelope Leap in arrivo da Stephen Diesel (ENF, Product Manager di Leap)

AGGIORNAMENTI	TEMPI DI RILASCIO
Leap 3.2 final release	rilasciato sull Github
System contract updates	in lavoro
Release del DUNE	dicembre, 2022

All'inizio di questo incontro Stephen ha annunciato che Leap 3.2 è rilasciato su Github, ma non è un upgrade di consenso e quindi facoltativo.

Brian Hazzard accetta di essere disponibile per qualsiasi domanda riguardante l'aggiornamento in vari canali. La prossima settimana ci sarà un aggiornamento del documento Net Plugin Enhancements, poiché l'ultimo incontro ha raccolto grandi idee e definito alcune nuove potenziali funzionalità per il backlog.

Ritaglio del database di stato riformulato: troppa RAM utilizzata per archiviare la cronologia di stato

Michael di EOSUSA non poteva essere presente all'incontro, ma aveva suggerito l'argomento per questo incontro: taglio del database di stato. I partecipanti hanno convenuto che il vero problema è che viene utilizzata troppa RAM. Per Stephen è in fase di redazione una RFP con l'obiettivo di fare ricerche per indagare sul problema della RAM.

Prestazioni di compromesso rispetto alle dimensioni della RAM

La domanda principale è stata posta da Kevin Heifner: "Quante prestazioni sei disposto a scambiare per le dimensioni della RAM? Sei disposto a scambiare il ciclo di produzione di 1 blocco per il caricamento dei dati nella RAM (come un blocco di riscaldamento)?" Tuttavia, esiste un alto rischio di spam con questa soluzione..

C'è semplicemente un'enorme richiesta di RAM che sembra non essere mai soddisfatta. Al momento sono necessari 128 GB di RAM per eseguire il database di stato WAX senza problemi. Il problema è che i normali dispositivi non hanno abbastanza spazio per più RAM. È difficile trovare dispositivi con CPU potenti e molto spazio per la RAM. Forse i dispositivi di graphic designer/animatori potrebbero soddisfare i requisiti futuri.

Opportunità definite a breve e lungo termine (citato)

Opportunità a breve termine

Una RFP è stata redatta dalla coalizione Antelope per ricercare questo problema.
Rendi più veloce l'avvio e l'arresto della modalità Heap
C'è un'opportunità per rendere il tmpfs più fuori dagli schemi?
Lasciare le query dell'account disabilitate può risparmiare sulla RAM (opportunità per la configurazione dell'operatore del nodo, già possibile)
Memorizza le query dell'account su disco (forse 4 GB per circa 14 milioni di account su WAX di ram risparmiati qui, probabilmente non ne vale la pena)

Opportunità a lungo termine

È possibile incentivare i contratti intelligenti per specificare la RAM rispetto all'archiviazione su disco?
I fornitori di hardware devono iniziare a offrire core CPU molto veloci con elevate quantità di RAM

Miglioramenti P2P (Net Plugin) (di Brain Hazzard)

Brian Hazzard ha toccato rapidamente le seguenti preoccupazioni e si è offerto di presentarle in modo più dettagliato nella riunione successiva dopo una breve domanda da parte dell'ospite, Daniel Keyes, se poteva fornire un breve riassunto delle proposte specifiche per il miglioramento del Net Plugin recentemente discusse internamente.

Ci sarebbe la possibilità di effettuare convalide più leggere che si verificano per blocchi su relè. Ciò potrebbe far risparmiare tempo e velocizzare la trasmissione
Sarebbe possibile codificare se un blocco è pieno (in termini di tempo di CPU costruito) trasmettendo e iniziando dal blocco successivo.
Configurazione automatica dei peer per ottimizzare la latenza (i BP lo fanno manualmente al momento).
1. ottimizzare per il programma (Quale BP viene prima, quale dopo?)
2. ottimizzare in termini di latenza

Ordine del giorno della prossima settimana

Un dibattito su quali dati inserire nell'esportatore Prometheus nel prossimo Leap 4.0 proposto da Matthew di EOS Nation

nodeEOS è come una scatola nera, molti operatori di nodi non hanno idea di cosa stia succedendo all'interno. C'è una richiesta di fornire alcune statistiche al riguardo.

I partecipanti alla riunione del nodo sono incoraggiati a portare la loro lista dei desideri per Prometeo durante la prossima riunione.

Partecipanti (13) della tavola rotonda:

Randall Roland | EOSsupport.io
Dario | EOSsupport.io
Kevin Heifner | OCI
Matt Witherspoon | ENF
Brian Hazzard
Jannis - Rakeden (Jannis)
Max Cho | KOREOS
Daniel Keyes | EOS Nation
Stephen Diesel | ENF
Matthew Darwin | EOS Nation
Corvin Meyer auf der Heide | liquiid.io
Patrick Burns | Aloha EOS
Ross Dold | EOSphere

Fonti & Risorse

Riepilogo della tavola rotonda dell'operatore del nodo EOS di Daniel Keyes

Crediti
- Banner dal EOS Support Graphics