Operazioni Nodi Vaulta: Spring 2.0, Adozione del Peering Gossip e Proposte di Sicurezza della Rete

Questa settimana, gli operatori di nodi per Vaulta, precedentemente conosciuta come EOS, si sono riuniti per discutere importanti aggiornamenti. L'incontro ha coperto i progressi sul software Antelope Spring 2.0, come sta funzionando il nuovo sistema gossip per connettere i produttori di blocchi e idee per rendere le connessioni di rete più sicure. Gli operatori di nodi hanno condiviso le loro esperienze con problemi tecnici e come sono configurate le loro reti, il tutto mantenendo la blockchain di Vaulta in funzione senza intoppi.

Punti chiave

• La Developer Preview 1 di Antelope Spring 2.0 è stata rilasciata, concentrandosi sulle chiamate sincrone, con modifiche più significative previste nella Preview 2 intorno a settembre.

• Il nuovo sistema di eventi richiederà agli operatori di nodi di impostare limiti di archiviazione, con maggiori dettagli in arrivo man mano che lo sviluppo prosegue.

• L'adozione del sistema di peering gossip sta avvenendo, ma non tutti i principali produttori di blocchi sono ancora connessi, il il che significa che la rete non è completamente interconnessa.

• L'impostazione della rete gossip è stata difficile, con problemi nel trovare i peer e suggerimenti fatti per utilizzare elenchi ospitati per aiutare i nuovi nodi a connettersi.

• Una nuova idea è quella di consentire agli operatori di nodi di creare elenchi di peer consentiti o bloccati per il sistema gossip per aiutare a gestire le connessioni e la sicurezza.

Progressi nello sviluppo di Antelope Spring 2.0

Lo sviluppo di Antelope Spring 2.0 sta procedendo, con la prima Developer Preview (DP1) ora disponibile. Questa versione iniziale introduce il supporto per le chiamate sincrone e fornisce accesso a un ambiente testnet. Agli sviluppatori viene chiesto di ricostruire i loro contratti utilizzando CDT 5.0 dev 1.1. Al momento, la DP1 non cambia molto per gli operatori di nodi, poiché gli impatti maggiori sono attesi con la DP2. La prossima preview, la DP2, è prevista per l'inizio di settembre e includerà il nuovo sistema di eventi insieme a miglioramenti sulla velocità di esecuzione.

Anteprima e implicazioni del sistema di eventi

La prossima Developer Preview 2 (DP2) per Antelope Spring 2.0 introdurrà un nuovo sistema di eventi. Questo sistema consentirà la trasmissione di eventi effimeri che sono crittograficamente impegnati all'interno dei dati di consenso. Per gli operatori di nodi, ciò significa che verrà introdotto un nuovo parametro di configurazione, che richiederà loro di impostare le impostazioni minime di archiviazione per questi eventi. I dettagli esatti e le migliori pratiche per la gestione di questi eventi sono ancora in fase di elaborazione man mano che lo sviluppo procede, ma la DP2 fornirà le funzionalità e le configurazioni iniziali rilevanti per i nodi necessarie per gestirli. Le implicazioni per gli operatori di nodi sono significative, poiché dovranno adattare le loro configurazioni per accogliere questo nuovo flusso di dati.

Funzionalità del sistema di eventi

• Gli eventi sono messaggi temporanei.

• Sono protetti tramite impegni crittografici nel consenso.

• Gli operatori di nodi devono definire i limiti di archiviazione.

Requisiti di configurazione per gli operatori di nodi

1. Impostare l'archiviazione minima per gli eventi effimeri.

2. Monitorare il flusso di dati degli eventi.

3. Adattarsi ai nuovi parametri di configurazione nella DP2.

Impatto previsto del sistema di eventi

• Nuovi tipi di dati da gestire.

• Potenziale per un monitoraggio di rete migliorato.

• Necessità di procedure operative aggiornate.

Stato di adozione del peering BP Gossip

Diversi importanti Produttori di Blocchi (BP) hanno intrapreso passi per registrare le loro chiavi peer, il che è un buon inizio. Stiamo assistendo a alcune connessioni di peering parziali, come tra Genereos ed Eosphere, dimostrando che la connettività di base è funzionale per alcuni. Tuttavia, questo non sta ancora accadendo su tutta la rete. L'adozione è ancora un lavoro in corso, e una maggiore coordinazione e chiare conferme da parte dei BP aiuterebbero davvero ad accelerare le cose. Non abbiamo raggiunto una massa critica di adozione, il che potrebbe essere il motivo per cui la rete gossip non è completamente interconnessa come previsto.

Sfide tecniche nella formazione della rete Gossip

Configurare una rete gossip stabile per i Produttori di Blocchi (BP) non è così semplice come potrebbe sembrare. Ci sono alcuni ostacoli che stiamo incontrando. Per cominciare, trovare altri peer può essere un successo o un fallimento. Questo spesso accade perché alcuni BP potrebbero non avere le loro configurazioni completamente sistemate, o forse i firewall stanno ostacolando, bloccando quelle connessioni. Ciò significa che a volte, i nodi semplicemente non riescono a vedersi quando dovrebbero essere in grado di farlo.

Al momento, per far funzionare le cose, le persone suggeriscono di aggiungere manualmente i peer per avviare le connessioni. Questo funziona, ma non è l'ideale per un sistema decentralizzato che dovrebbe trovare la propria strada. Ci manca un modo per i nodi di scoprirsi automaticamente, come un sistema di "seed peer" che aiuti i nuovi nodi a trovare quelli esistenti. Alcune idee che circolano includono l'utilizzo di elenchi JSON di peer ospitati per aiutare con questa configurazione iniziale.

Funzionalità proposta di Whitelist/Blacklist per le connessioni Gossip

Per aiutare a gestire le connessioni all'interno della rete gossip, si sta considerando una funzionalità che consenta l'uso di whitelist e blacklist di peer. Ciò darebbe agli operatori di nodi un maggiore controllo su quali altri nodi si connettono. L'idea è di consentire agli operatori di specificare account di Produttori di Blocchi (BP) particolari che sono consentiti o non consentiti a connettersi.

Questo sistema proposto funzionerebbe insieme alle configurazioni manuali esistenti dei peer. Qualsiasi peer aggiunto manualmente alla configurazione del nodo avrebbe comunque la priorità. Tuttavia, per i peer scoperti tramite il protocollo gossip, si applicherebbero quindi le regole di whitelist e blacklist.

L'obiettivo principale di questa funzionalità è fornire un modo per prevenire connessioni con nodi che potrebbero essere malfunzionanti o sotto qualche forma di attacco. È vista come un modo per ridurre la necessità per gli operatori di gestire complesse regole di firewall esterni solo per filtrare il traffico gossip in entrata.

Ecco una ripartizione di come potrebbe funzionare:

• Whitelist: Un elenco di account BP specifici esplicitamente autorizzati a connettersi al tuo nodo tramite gossip.

• Blacklist: Un elenco di account BP specifici esplicitamente proibiti dal connettersi al tuo nodo tramite gossip.

• Comportamento predefinito: Se né una whitelist né una blacklist sono configurate, o se un peer non è in nessuno dei due elenchi, il nodo seguirebbe probabilmente il suo comportamento di connessione predefinito, consentendo potenzialmente la connessione.

Preoccupazioni sull'identificazione dei peer e la mitigazione degli abusi

Sfide nell'identificazione dei peer

Una delle principali preoccupazioni con il sistema gossip è capire chi sta effettivamente inviando cosa. Poiché i messaggi possono essere passati tra diversi nodi, è difficile rintracciare dove il traffico dannoso è realmente iniziato. Questo rende difficile fermare i problemi alla fonte. Se blocchi un nodo che sta causando problemi, potrebbe continuare a diffondersi attraverso altri nodi che non hai ancora identificato. Sembra un po' come giocare a 'colpisci la talpa', e non c'è un modo semplice per sapere con certezza chi fosse il mittente originale.

Strategie di mitigazione degli abusi

Per affrontare questo problema, le persone chiedono modi migliori per controllare chi può connettersi e quale tipo di traffico è consentito. Ciò significa avere più di un semplice blocco. Abbiamo bisogno di sistemi che possano esaminare l'identità dei peer e applicare le regole con maggiore attenzione. La configurazione attuale non ci offre quel tipo di controllo dettagliato, il che è un grande ostacolo per mantenere la rete pulita e sicura. È chiaro che bloccare solo i singoli nodi non è sufficiente quando la rete è progettata per trasmettere informazioni così liberamente.

Vincoli di rete che influenzano la fattibilità delle funzionalità

Quando consideriamo di far funzionare nuove funzionalità, specialmente cose come la whitelist e la blacklist proposte per le connessioni gossip, ci imbattiamo in alcuni problemi di rete reali. Non è sempre così semplice come premere un interruttore. Ad esempio, molti nodi utilizzano server proxy per connettersi. Questo è abbastanza comune, ma significa che l'indirizzo IP originale di una connessione viene nascosto. Ciò rende difficile sapere esattamente da dove proviene il traffico, il che è un grosso problema se si sta cercando di controllare chi può connettersi.

Poi c'è la tecnologia sottostante stessa. Il protocollo TCP, che è quello che usa gossip, non offre lo stesso tipo di controllo granulare su chi si connette come potrebbe fare qualcosa come HTTP. Ciò significa che non possiamo facilmente impostare regole per consentire o bloccare connessioni specifiche basate su informazioni dettagliate. Inoltre, con gli indirizzi IP dinamici e tutte queste diverse configurazioni proxy, cercare di imporre una whitelist o una blacklist rigorosa diventa un vero grattacapo. Sembra che siamo costantemente a rincorrere.

A causa di queste sfide, molti operatori di nodi stanno scoprendo che i controlli tradizionali a livello di firewall sono ancora il modo più pratico ed efficace per gestire il loro traffico di rete. Sono abituati a questo, e funziona in modo affidabile, anche se non è così integrato come potrebbe essere una funzionalità specifica per il gossip. Dobbiamo considerare se le funzionalità proposte possano davvero superare queste realtà di rete esistenti o se aggiungeranno solo maggiore complessità senza risolvere i problemi principali.

Conclusione e prossimi passi

Lo sviluppo di Antelope Spring 2.0, in particolare la prossima Developer Preview 2 (DP2) e il suo sistema di eventi integrato, rappresenta un'area significativa per i futuri test e feedback degli operatori di nodi. Sono importanti anche gli sforzi continui per incoraggiare e monitorare l'adozione del protocollo Gossip per il peering dei Produttori di Blocchi (BP). La funzionalità proposta di whitelist e blacklist per la gestione delle connessioni gossip è stata riconosciuta come uno strumento potenzialmente utile, sebbene le sue attuali limitazioni significhino che non è una soluzione completa per la sicurezza della rete. Ulteriori ricerche e input dalla comunità saranno raccolti per valutare la fattibilità pratica e l'efficacia dell'implementazione di tali funzionalità.

Aree chiave di interesse per gli operatori

• DP2 e il sistema di eventi: Gli operatori di nodi dovrebbero prepararsi a testare questi componenti non appena saranno disponibili.

• Adozione del Peering Gossip: La partecipazione continua e la conferma del successo del peering sono incoraggiate per costruire una rete gossip più robusta.

• Feedback sulle funzionalità di sicurezza: Fornire input sul meccanismo proposto di whitelist/blacklist e altre preoccupazioni sulla sicurezza aiuterà a plasmare gli sviluppi futuri.

Considerazioni future

1. Robustezza della rete Gossip: Affrontare le sfide nella scoperta dei peer e nella stabilità della connessione rimane una priorità.

2. Identità e Abuso: Sviluppare metodi più efficaci per identificare e mitigare gli abusi all'interno della rete gossip richiede ulteriori indagini.

3. Realtà della rete: I vincoli pratici relativi al mascheramento IP e all'infrastruttura di rete esistente devono essere attentamente considerati quando si progettano nuove funzionalità.

Questo articolo è stato creato con il supporto di una tecnologia basata sull'intelligenza artificiale, attingendo a molteplici fonti affidabili. Il contenuto finale è stato accuratamente revisionato e modificato dal team editoriale di BlockzHub per garantire accuratezza, chiarezza e coerenza. Le fonti originali delle informazioni vengono citate ove appropriato e necessario. Le opinioni espresse in questo articolo non rappresentano necessariamente le posizioni o i punti di vista ufficiali di BlockzHub. Questo articolo ha esclusivamente scopo informativo e non deve essere considerato come consulenza finanziaria o professionale. Investire comporta dei rischi ed è consigliabile consultare un consulente finanziario qualificato prima di prendere qualsiasi decisione di investimento.