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 due tavole rotonde contenute in questo riepilogo bimestrale:
5 luglio: Efficienza e stabilità: traffico, dimensione/tempo del blocco e SHiP
12 luglio: Soluzioni user-friendly per autorizzazioni multi-azione e 5.0
5 luglio tavola rotonda:
Efficienza e stabilità: traffico, dimensione/tempo del blocco, 5.0 e SHiP
Con l'avvicinarsi di Leap 5.0, le tavole rotonde assumono la forma di discussioni aperte. Allineare le operazioni dei nodi con la versione 5.0 è impegnativo. Il monitoraggio del sentimento della comunità, la condivisione degli aggiornamenti di sviluppo e la comunicazione determinano probabilmente la fluidità dell'aggiornamento del consenso annuale questo autunno (2023).
Gli interessi della comunità il 5 luglio erano incentrati sulla dimensione e sui tempi del blocco.
Panoramica
Efficienza e stabilità caratterizzano la discussione su problemi di traffico elevato (su Leap versione 4.0), dimensione/tempo del blocco, 5.0 e SHiP. Una sensazione di armonia persiste con l'avvicinarsi di Leap 5.0.
Aggiornamenti
patch in arrivo con i dettagli a breve
Argomento della comunità: efficienza e stabilità
La discussione si è ampiamente concentrata su efficienza e stabilità. I dettagli esaminati includono prestazioni e traffico di rete, SHiP, dimensione del blocco, tempo di elaborazione e miglioramenti di Leap 5.0. Inoltre, notare il collegamento incluso su evitare arresti anomali durante l'elaborazione delle API.
Traffico
Mentre la rete EOS è al centro delle tavole rotonde degli operatori dei nodi, le riunioni sono aperte alle discussioni in tutte le catene pubbliche di AntelopeIO. Tra i più trafficati c'è WAX.
L'enorme traffico su WAX spinge gli operatori dei nodi ai loro limiti. Discutere i problemi di traffico WAX aiuta nello sviluppo di nuove versioni del software AntelopeIO. Le future iterazioni di EOS, WAX e altre catene AntelopeIO andranno sicuramente meglio grazie alle indagini sul traffico.
WAX fatica a implementare Leap versione 4.03 a causa di alcuni problemi esistenti. I test continuano man mano che emergono segnalazioni di bug. Anche il test di carico nel mondo reale è una considerazione. Si noti che la versione 5.0 di Leap si prepara a capacità prestazionali di gran lunga superiori a quelle attualmente possibili negli ambienti 4.0.
Dimensione blocco/tempo e Leap 5.0
La dimensione del blocco rimane un argomento di grande interesse. All'avvio iniziale di EOS, i tempi massimi di blocco della CPU erano impostati su 100 millisecondi. I tempi sono aumentati a 250 millisecondi, ma in risposta ad alcuni problemi iniziali, la rete si è stabilizzata su 200 millisecondi dove rimane oggi. Leap 5.0 tornerà prudentemente a 250 millisecondi con la capacità di gestire velocità molto più elevate.
Altri argomenti e preoccupazioni sollevati includono:
configurazione variabile per la dimensione del blocco
colli di bottiglia
fallimento della transazione e tempi di valutazione
rendimento di rete
whitelist e livelli di account
tempi impostati vs tempo percentuale
Leap 5.0 cambierà le operazioni dei nodi tramite round più veloci e vantaggi derivati dal completamento anticipato del blocco. I dettagli per i round più veloci si suddividono come segue:
sceglie sempre il tempo di blocco più piccolo
offset in millisecondi rispetto a set di blocchi
Il completamento anticipato del blocco comporta la possibilità di iniziare il blocco prima anche se l'ora di fine rimane la stessa.
Mentre 5.0 realizzerà partenze di blocco più veloci (oltre 4.0), il team di sviluppo vuole ancora vedere le capacità esistenti di 4.0.
La necessità di entrare in un thread principale e interrompere le transazioni in corso è risolta in 5.0. Rimane la possibilità di intercessione. Di seguito è stata menzionata la programmazione e il desiderio di iniziare presto i test, prima del rilascio autunnale.
Problemi con la SHiP
Una nuova versione della patch dovrebbe risolvere i problemi recenti con SHiP (State History Plugin). Un rapporto non ha identificato alcun feedback da SHiP privo di connessioni tra pari. Le istantanee possono essere utili in questi casi. Le correzioni riguardano la sincronizzazione di EOS da Genesis. Un altro problema identificato riguardava la mancata ricezione dei dati ABI. Flusso di dati interrotto durante la disconnessione da SHiP. Sembra tutto facile da risolvere.
Fai attenzione alle versioni di patch in arrivo.
12 luglio tavola rotonda:
Soluzioni user-friendly per autorizzazioni multi-azione e 5.0
L'incontro del 12 luglio ha esplorato le applicazioni dinamiche per le autorizzazioni degli utenti. Correzioni di sicurezza risolte. I primi preparativi per Leap 5.0 potrebbero iniziare nelle prossime settimane.
Panoramica
Le applicazioni dinamiche devono considerare gli utenti. Le soluzioni sono state esaminate sia dal lato del portafoglio che dalle modifiche al codice specifiche per gli operatori dei nodi. Le soluzioni di portafoglio per l'autorizzazione multi-azione possono rivelarsi più utili per vari motivi.
Aggiornamenti
Le versioni risolvono una vulnerabilità di sicurezza. Vedere i collegamenti alla versione associata per ulteriori informazioni su ciascuna correzione (inclusa una soluzione di stabilità).
Soluzioni user-friendly per autorizzazioni multi-azione
La tavola rotonda di oggi ha analizzato un tema caldo. Gli utenti blockchain devono mantenere il controllo sulle risorse mentre sperimentano funzionalità familiari simili a web2. Le autorizzazioni dinamiche che considerano prima le soluzioni di portafoglio probabilmente si dimostrano la migliore linea d'azione.
Alcune combinazioni di autorizzazioni considerate durante questa tavola rotonda includono:
un'opzione di scadenza
ricevuta (token) per l'autorizzazione salvata in catena specifica per gli utenti
autorizzazioni del contratto intelligente delegate
standard comuni per le opzioni variabili
whitelisting
richiesta di autorizzazione (RFP)
Le opzioni di scadenza e la whitelist attirano maggiormente l'attenzione. Sebbene possano esistere soluzioni attraverso modifiche al codice di base, le soluzioni di portafoglio affidabili.
Ad esempio, le RFP possono funzionare bene con una soluzione wallet-first simile alle precedenti funzionalità di Scatter. Tuttavia, sono emerse preoccupazioni in merito alla pianificazione delle transazioni e alla chiusura asincrona di portafogli/applicazioni (specialmente giochi).
Un partecipante alla riunione ha menzionato in chat come differiscono "l'autorizzazione all'inserimento nella lista bianca e l'autorizzazione all'inserimento nell'elenco". Il partecipante ha delineato una soluzione in cui un operatore può incorporare:
“uno spazio dei nomi (.ra) e quindi si utilizza la chiave pubblica degli utenti per registrare un nuovo account”
Un approccio generale per qualsiasi soluzione è considerare come le prospettive degli utenti differiscono dal lato tecnico. Sono stati effettuati confronti tra la semplificazione delle autorizzazioni Web tradizionali e le aspettative degli utenti. Gli utenti potrebbero voler mantenere un singolo account blockchain anche se la realtà è più complicata a livello di sviluppatore. Sono state nuovamente suggerite le funzionalità del portafoglio.
Il moderatore ha suggerito argomenti relativi a Leap 5.0 di finalità istantanea (IF) e problemi di rottura del consenso. Gli argomenti chiave del resto della tavola rotonda includono:
coordinare un aggiornamento del protocollo di consenso
ulteriori informazioni sull'inserimento in whitelist e sulle autorizzazioni dell'account (aspetti temporali).
una nuova chiave pubblica per le opzioni di scadenza (problemi di sicurezza sollevati) rispetto al riconoscimento dell'accesso al portafoglio
notazione fatta sui portafogli che attualmente memorizzano chiavi e non applicazioni
le applicazioni mobili possono richiedere opzioni di scadenza uniche e limiti di controllo a livello di eosio (ad es. autorizzazioni di nomi premium per le vendite sul mercato)
chiesto in chat: "...permesso di rimuovere il proprio permesso..." o è sempre necessaria una chiave del proprietario
Alcune idee hanno chiuso l'incontro. Gli argomenti da considerare includono la comprensione delle aspirazioni, l'aggiornamento (ad esempio i gestori di pacchetti), la facilitazione di strumenti di sviluppo personalizzati e l'enfasi sull'importanza della documentazione fondamentale.
Fonti & Riferimenti