In questa serie in tre parti, sveleremo i traguardi tecnici capaci di migliorare significativamente l'elaborazione dei dati delle applicazioni in esecuzione sul protocollo Internet Computer (ICP).
Questo aggiornamento è una pietra miliare del Stellarator nella roadmap ICP, attualmente in fase di rollout attraverso la rete, il Stellarator ha raggiunto progressi significativi nel deposito di dati on-chain e nel throughput, consentendo a ciascuna subnet di gestire oltre 1TB di memoria e di caricare dati più rapidamente, liberando opportunità per applicazioni ricche di dati precedentemente limitate dalla capacità di archiviazione e throughput.
Questo progresso consente agli sviluppatori di costruire applicazioni complesse che richiedono l'elaborazione di grandi quantità di dati, portando un nuovo livello di utilità alla tecnologia blockchain.
Come ultima parte di questa serie, Kamil Popielarz e Yvonne-Anne Pignolet condivideranno gli ultimi progressi nel miglioramento del throughput dei messaggi in ingresso per l'Internet Computer, se ti sei perso le prime parti di questa serie, puoi trovarle qui e qui.
Aumentare la capacità di throughput dei messaggi in ingresso
Se sei come noi, aspettare che i dati vengano caricati su dapp non è il tuo passatempo preferito, quindi siamo lieti di annunciare che il Network Nervous System (NNS) sta lanciando ottimizzazioni per il protocollo Internet Computer per migliorare il throughput di consenso.
Questi cambiamenti nei protocolli hanno ridotto il consumo di larghezza di banda e il tempo necessari per propagare i blocchi, mantenendo al contempo le proprietà di sicurezza dell'ICP, quindi gli utenti trascorreranno più tempo interagendo più velocemente con i dapp ICP.
Contesto
Il protocollo Internet Computer coordina i nodi della sua rete, garantendo servizi di calcolo decentralizzati anche quando alcuni nodi si discostano dal protocollo.
È ben noto che l'ICP può ospitare qualsiasi applicazione che combina codice e dati, chiamate container, i container possono elaborare messaggi in ingresso inviati dagli utenti e interagire con altri container attraverso lo scambio e l'esecuzione di messaggi.
I nodi della rete non duplicano più l'esecuzione di ogni container su tutti i nodi, ma sono suddivisi in più frammenti, chiamati subnet, ciascuna delle quali adotta un potente protocollo di consenso per garantire l'esecuzione e la coerenza dello stato dei container ospitati sui suoi nodi.
Il protocollo di consenso è responsabile della creazione e della verifica dei blocchi, ciascun blocco contiene un insieme di messaggi container, e dopo aver raggiunto un accordo sull'ordine e sul contenuto di questi blocchi, i nodi possono eseguire il codice dei container in modo deterministico e coerente, mantenendo così l'integrità del servizio di calcolo.
Il payload del blocco contiene messaggi in ingresso inviati dagli utenti, utilizzati per attivare le chiamate ai container replicate, dopo aver ricevuto un messaggio in ingresso dall'utente, il nodo eseguirà una serie di controlli (ad esempio, firma, dimensione, data di scadenza), se questi controlli hanno successo, il nodo aggiungerà il messaggio alla sua pool di ingressi e utilizzerà il protocollo peer-to-peer (P2P) di ICP per trasmettere il messaggio agli altri nodi della subnet.
Quando è il turno di un nodo di creare una proposta di blocco, quel nodo includerà un insieme di messaggi in ingresso dalla sua pool di ingressi, quindi quel nodo trasmette questa proposta ai suoi peer.
Tuttavia, poiché la maggior parte dei peer ha già la maggior parte di questi messaggi in ingresso nelle loro pool locali, questo processo consuma larghezza di banda inutilmente.
Un altro svantaggio di questo approccio è che inviare una proposta contenente 1000 messaggi da 4KB a tutti i peer richiede più tempo rispetto all'invio di una proposta contenente 1000 hash.
Assumendo che le repliche abbiano una larghezza di banda minima suggerita di 300Mbit/s, trasmettere una proposta di blocco contenente un payload di 4MB a tutti i peer in una subnet con 13 nodi richiede: 4MB * (13-1) / 300Mbit/s = 1.28 secondi.
Se ogni hash è inferiore a 50 byte, la stessa proposta può essere trasmessa a tutti i nodi a una velocità superiore a 800 volte, per subnet più grandi, queste differenze si accumuleranno e quindi l'impatto sarà maggiore.
Ottimizzazione
Per ridurre il tempo di consegna della proposta e il consumo di larghezza di banda, il protocollo è stato migliorato per consentire ai nodi di includere un riferimento ai messaggi in ingresso (hash) nei blocchi, piuttosto che i messaggi completi, poiché i nodi comunque trasmettono i messaggi in ingresso utilizzando il protocollo P2P, le repliche dovrebbero essere in grado di ricostruire la proposta di blocco recuperando tutti i messaggi in ingresso dalle rispettive pool.
Tuttavia, alcuni messaggi in ingresso potrebbero andare persi nella pool di ingressi locale di un nodo, questo può essere causato da condizioni di rete sfavorevoli, pool piene, crash del nodo o comportamenti malevoli dei nodi, il nodo deve avere tutti i messaggi in ingresso della proposta per verificare e/o eseguire la proposta, per ottenere i messaggi in ingresso persi, il nodo può richiederli ai peer che hanno pubblicato la proposta.
Alcuni aspetti dell'implementazione della pool di ingressi sono stati modificati per aumentare le possibilità che tutti i messaggi in ingresso esistano nella pool di ingressi di tutti i peer prima della proposta di blocchi contenenti i loro hash.
In primo luogo, i nodi ora inviano messaggi in ingresso direttamente ai peer, anziché inviare pubblicità ai peer e attendere che i peer facciano richiesta, risparmiando almeno un round trip e rendendo così più veloce la trasmissione dei messaggi in ingresso ai peer.
Inoltre, la gestione delle dimensioni della pool di ingressi è stata migliorata, fino ad ora, c'è un limite globale sia sul numero di messaggi che sulla loro dimensione totale, e se si superano questi limiti, il nodo rifiuterà qualsiasi messaggio in ingresso trasmesso dal peer.
Pertanto, in condizioni di carico molto elevato, i nodi su una singola subnet potrebbero finire per avere pool di ingressi quasi non sovrapposte, in questo caso, per ogni proposta di blocco, tutti i nodi devono richiedere tutti i messaggi al produttore del blocco, il che aumenta la latenza e riduce il throughput.
Per risolvere questo problema, il confine globale è stato sostituito dal confine di ciascun nodo peer, fino ad ora, finché c'è spazio nella pool di ingressi per quel nodo peer, il nodo accetterà i messaggi in ingresso da quel nodo peer.
Poiché in qualsiasi momento, le repliche oneste trasmettono i messaggi in ingresso a ciascun confine peer, possiamo essere altamente certi che, anche sotto carichi pesanti, i nodi sulla stessa subnet avranno pool di ingressi altamente sovrapposte.
Per minimizzare le modifiche all'intero protocollo, è stato aggiunto un nuovo componente tra P2P e consenso, responsabile della rimozione dei messaggi in ingresso dalla proposta del mittente e della loro reintegrazione nel ricevente, il resto della logica P2P e di consenso rimane invariato.
Valutazione delle prestazioni
Per illustrare l'impatto dell'ottimizzazione, abbiamo condotto esperimenti in una subnet di test con 13 nodi, imponendo un RTT di 300ms tra i nodi e limitando la larghezza di banda a 300 Mbps.
Gli esperimenti hanno dimostrato che trasmettendo un gran numero di piccoli messaggi (circa 4KB), il throughput è aumentato da 2MB/s a 6MB/s.
Allo stesso modo, nei nostri esperimenti con grandi messaggi (leggermente inferiori a 2MB), il throughput è aumentato da 2MB/s a 7MB/s.
Si noti che negli esperimenti ci siamo concentrati solo sul throughput di consenso, mentre i container che inviamo con i messaggi non stanno eseguendo alcun lavoro significativo.
Il grafico sottostante mostra il throughput negli esperimenti sopra descritti:
Abbiamo anche condotto esperimenti dimostrando che l'adesione di nodi a una subnet (catch-up) e i guasti di nodi, così come le prestazioni di subnet con molti container o molti nodi, sono almeno buone come in precedenza (e in molti casi molto migliori).
Conclusione
Questi cambiamenti nei protocolli migliorano l'esperienza utente dell'Internet Computer, ponendo le basi per ulteriori cambiamenti per gestire messaggi più grandi e più numerosi.
Queste modifiche sono state attivate in alcune sottoreti della mainnet, dove puoi sperimentare di persona che questi benefici si applicano anche a condizioni di rete reali e carichi variabili, non solo a piccoli esperimenti condotti con modelli di traffico sintetico.
Fateci sapere il vostro feedback, potete condividere le vostre idee in qualsiasi momento nel canale DFINITY Developers X e nel forum per sviluppatori, e continuate a seguire ulteriori aggiornamenti sulla roadmap tecnica in arrivo.
Il contenuto IC che ti interessa
Progresso Tecnologico | Informazioni sul Progetto | Attività Globali
Segui il canale Binance IC
Rimanete aggiornati
