Il conteggio delle transazioni di Solana e, con esso, la cifra headline di transazioni al secondo (TPS) sono diminuiti quando la rete ha attivato Alpenglow il 21 ottobre. La documentazione sull'upgrade della Solana Foundation definisce il calo "una modifica contabile, non una regressione della throughput." Questa lettura lascia comunque una domanda aperta per chiunque osservi un grafico di Solana: l'attività è davvero diminuita, o solo il conteggio? La risposta va oltre il singolo giorno dell'upgrade, perché la TPS è tra le cifre di throughput più citate nella copertura delle blockchain, e il conteggio di Solana dopo il 21 ottobre è calcolato secondo una definizione diversa rispetto a ogni numero pubblicato in precedenza.

Cosa Alpenglow ha rimosso dalla lista delle transazioni

Con TowerBFT, il sistema di consenso utilizzato da Solana fino al 21 ottobre, i validatori esprimevano i propri voti come normali transazioni. I blocchi ne contenevano centinaia insieme a pagamenti, swap e altro traffico applicativo, e ogni conteggio delle transazioni totali includeva quel traffico di voto. Poiché quei voti provenivano dai validatori e non dagli utenti, parte di ogni cifra TPS pre-upgrade rifletteva il meccanismo di consenso della rete piuttosto la domanda per le sue applicazioni.

Alpenglow sostituisce il meccanismo con Votor, un protocollo in cui i validatori scambiano i voti direttamente e li raggrupo in certificati. I certificati si trovano nel footer di ciascun blocco anziché nella lista delle transazioni, quindi un contatore che totalizza le transazioni smette di vedere i voti dal momento del passaggio.

Cosa mostrano i blocchi di passaggio

Coindoo ha esaminato i blocchi ai due lati del passaggio tramite la RPC pubblica della mainnet di Solana, l'interfaccia esposta dai nodi per leggere i dati della catena, utilizzando il metodo getBlock. Ogni blocco occupa uno slot, una finestra di circa 400 millisecondi. TowerBFT ha funzionato per i primi 5.000 slot dell'epoca prima di essere sostituito da Alpenglow.

L'ultimo blocco TowerBFT è arrivato alle 13:54:00 UTC del 21 ottobre, e il primo blocco Alpenglow è seguito alle 13:54:03, senza blocchi prodotti negli otto slot intermedi. Circa tre transazioni su cinque nell'ultimo blocco TowerBFT, 649 in totale, erano voti di validatori; un blocco dopo, non ce n'erano più. Il blocco Alpenglow era comunque il più grande dei due. Una singola coppia di blocchi non può mostrare se l'attività di rete sia aumentata o diminuita; mostra il meccanismo. Misurare un trend richiede migliaia di blocchi.

I voti non sono l'unico rumore nel conteggio

I fallimenti aggiungono un secondo livello. Leggendo il campo error nei metadati di ciascuna transazione, Coindoo ha rilevato che 844 delle 1.701 transazioni nel primo blocco Alpenglow hanno generato un errore di esecuzione, lasciandone 857 andate a buon fine. Una transazione fallita paga comunque una fee e rimane nel blocco, ma non ha completato alcun pagamento o scambio. La lettura come modifica contabile copre solo il livello dei voti, quindi anche un conteggio senza voti richiede un filtro sul campo error prima di descrivere il lavoro effettivamente completato.

Anche le transazioni riuscite non corrispondono a persone. Un singolo account di trading automatizzato può inviare transazioni in grande quantità, e una singola transazione può contenere più istruzioni. Contare ciò che le transazioni hanno effettivamente realizzato, come swap completati o trasferimenti di token, si avvicina di più all'uso reale di qualsiasi totale grezzo di transazioni.

Dove si trovano i dati per il confronto

Il metodo getRecentPerformanceSamples di Solana riporta, per ciascun campione, il conteggio totale delle transazioni, il conteggio non-voto e la durata del campione in secondi. Dividere un conteggio per la dur fornisce una media per quella finestra.

Il metodo restituisce al massimo 720 campioni di circa un minuto ciascuno, ovvero circa le ultime 12 ore. Una query effettuata più di mezza giornata dopo il passaggio non raggiunge più TowerBFT, quindi il lato pre-upgrade di qualsiasi confronto deve provenire da campioni archiviati in precedenza o da blocchi storici.

Tre filtri, applicati in modo identico prima e dopo il passaggio, rendono il confronto significativo:

1. Rimuovere i voti dei validatori. Alpenglow lo fa sul lato nuovo; il lato vecchio richiede un intervento manuale.
2. Rimuovere le transazioni fallite utilizzando il campo error di ciascuna transazione. Il conteggio non-voto dell'API le include ancora.
3. Confrontare finestre temporali uguali: medie di un minuto contro medie di un minuto, mai un picco di dashboard contro un totale giornaliero.

Gli strumenti che leggono i voti vanno riconfigurati

Le transazioni di voto facevano più che gonfiare la TPS. Gli strumenti di monitoraggio leggono le istruzioni del programma Vote dalla lista delle transazioni per tracciare quali validatori partecipavano. Con Alpenglow quell'input è scomparso, e la Foundation indirizza tali strumenti ai certificati di voto nei footer dei blocchi. Un tracker che continuasse a leggere la vecchia fonte mostrerebbe validatori silenziosi mentre continuano a votare.

Per le cifre di utilizzo di Solana, il numero utile arriverà quando diversi giorni di transazioni non-voto riuscite potranno essere confrontati con dati pre-upgrade archiviati che coprano le stesse ore. Fino ad allora, qualsiasi grafico headline della TPS che comprenda il 21 ottobre mescola la modifica contabile con i reali cambiamenti nell'uso.

Fonte: Coindoo