Analisi: gli slot da 250 ms di Solana potrebbero mettere alla prova la stabilità della rete

Il coordinamento dei validatori di Solana ha iniziato a operare con un tempo obiettivo dello slot di 250 millisecondi all'epoca 1037 il 18 settembre, secondo il registro delle modifiche ingegneristiche di Solana e un rapporto di Solana Compass, che ha collocato il passaggio intorno alle 05:06 UTC. Uno slot è l'intervallo obiettivo della rete entro il quale un validatore produce un blocco. L'intervallo più breve crea opportunità più frequenti per l'inclusione delle transazioni, dando però ai validatori meno tempo per trasferire la produzione da un leader al successivo. Un primo campione del 20 settembre, relativo a 60 finestre di un minuto, ha registrato circa 266 millisecondi per slot prodotto. L'epoca 1037 ha saltato circa lo 0,05% dei suoi slot programmati. La finestra di osservazione limitata consente una lettura iniziale incoraggiante, ma non stabilisce una tendenza della performance nel lungo periodo. Il passaggio a 200 millisecondi restava in sospeso sulla mainnet il 20 settembre e il calendario degli attivatori di funzionalità di Anza non indicava una data certa di attivazione. La pagina di Solana sulla riduzione del tempo degli slot afferma che ulteriori riduzioni dipendono da una performance della rete accettabile, compresi i tassi di slot saltati. La bozza di proposta di design SIMD-0525 ridurrebbe il budget dei blocchi da 62,5 milioni di unità di calcolo a 250 millisecondi a 50 milioni a 200 millisecondi. Entrambe le impostazioni lasciano il tetto nominale del protocollo vicino a 250 milioni di unità di calcolo al secondo. Gli slot più brevi modificano quindi più direttamente la cadenza e la latenza che la capacità, perché i blocchi arrivano più spesso ma contengono meno lavoro consentito. Il throughput effettivo delle transazioni dipende ancora dalla domanda, dalla programmazione e dall'efficacia con cui i leader riempiono lo spazio nei blocchi. Il design mantiene fisso a quattro slot il turno di ciascun leader. Ciò dà a un leader una finestra nominale di un secondo a 250 millisecondi e una finestra di 800 millisecondi a 200 millisecondi. I validatori avrebbero meno tempo per ricevere il traffico e iniziare a produrre dopo un passaggio di consegne. Un'analisi ingegneristica della Solana Foundation ha misurato una penalità mediana sulla durata del primo slot di circa 28 millisecondi quando i leader consecutivi si trovavano a meno di 500 chilometri di distanza e di 122 millisecondi quando si trovavano a più di 8.000 chilometri. La penalità maggiore equivale al 61% di uno slot obiettivo di 200 millisecondi. La metrica confronta il primo slot di un leader con i suoi slot successivi e rileva più della sola latenza di rete. Il registro delle modifiche di Solana del 18 settembre identifica l'inoltro pessimista al leader successivo come una delle risposte ingegneristiche quando una transazione potrebbe non raggiungere la destinazione prevista. I team dei client stanno inoltre testando l'esecuzione di blocchi e transazioni rispetto a binari di conformità tra implementazioni e versioni. La bozza di proposta mantiene una soglia di rinvio del recupero di 250 millisecondi nella fase a 200 millisecondi. Tale ritardo è più lungo di uno slot obiettivo. Si tratta di margini ingegneristici prospettici, non di prove di un problema attuale. Il guasto di routing del 12 agosto presso TeraSwitch si è verificato prima dell'impostazione a 250 millisecondi e non è stato causato da essa. Il rapporto sull'incidente di TeraSwitch ha affermato che 12 siti hanno perso la raggiungibilità e che un sito di Miami è stato rimosso per contenere il problema. Solana Compass ha misurato come inadempiente il 28,83% dello stake della rete per circa 33 minuti. La Solana Foundation ha affermato che i blocchi hanno continuato a essere prodotti e che le transazioni hanno continuato a essere incluse. Dati indipendenti del 7 settembre hanno indicato a 18 il coefficiente di Nakamoto di Solana basato sullo stake e hanno collocato il suo validatore più grande vicino al 4% dello stake attivo. Un rapporto di un provider relativo alla stessa data ha attribuito a TeraSwitch il 22,1% dello stake attivo. La Foundation ha inoltre affermato che lo scorso anno TeraSwitch ospitava il 38% dello stake, prima che la sua quota fosse ridotta al di sotto del 30%. Queste cifre non hanno una data né un metodo comuni, quindi la rilevazione del 7 settembre costituisce l'istantanea attuale più chiara, non una serie continua. Una query ponderata per stake del 20 settembre ha raggruppato circa l'87,4% dello stake sulle versioni 4.x dei client, il 7,3% sulle versioni 0.x e il 5,3% sulle versioni 26.x. I numeri delle versioni principali sono solo indicatori approssimativi dei software della famiglia Agave, Frankendancer e Firedancer, perché non possono distinguere ogni variante dello scheduler o ogni build derivata. La concentrazione dello stake, la linea di derivazione dei client e la quota di hosting misurano diverse esposizioni ai guasti. Gli slot più rapidi non creano tali concentrazioni, ma margini più ridotti nei passaggi di consegne e nel recupero possono rendere più rilevanti le interruzioni correlate. Una decisione più solida sui 200 millisecondi si baserebbe su misurazioni sostenute della durata degli slot, dei tassi di slot saltati, dell'inclusione delle transazioni e dei passaggi di consegne tra leader. Idealmente, tali misurazioni dovrebbero essere suddivise per famiglia di client e provider dell'infrastruttura, per individuare coorti più deboli o code più lunghe nascoste da una media a livello di rete. Alpenglow segue una tempistica separata perché è un aggiornamento del consenso che punta a una finalità di circa 150 millisecondi, mentre il tempo degli slot governa la cadenza delle opportunità di produzione dei blocchi. Le pagine ufficiali di Solana indicano finestre di pianificazione diverse per Alpenglow, tra cui un obiettivo per il terzo trimestre e una finestra a ottobre per Agave 4.3, senza che nessuna delle due fornisca un giorno esatto di attivazione. Il test centrale per i 200 millisecondi consiste nel verificare se l'inoltro, le transizioni tra leader, il recupero e le diverse implementazioni dei client riescano a tenere il passo per un periodo di osservazione più lungo e in condizioni geografiche e infrastrutturali meno favorevoli.