Guida alla Quality of Service ponderata sullo stake su Solana

Cos'è la Quality of Service ponderata sullo stake (QoS)?

La QoS ponderata sullo stake (Quality-of-Service) è una funzionalità di implementazione che, se abilitata, consente ai leader (produttori di blocchi) di identificare e dare priorità alle transazioni inoltrate tramite un validator con stake, come meccanismo aggiuntivo di resistenza ai sybil attack. Poiché Solana è una rete proof of stake, è naturale estendere l'utilità della ponderazione sullo stake alla quality of service delle transazioni. In questo modello, un validator con lo 0,5% di stake avrebbe il diritto di trasmettere fino allo 0,5% dei pacchetti al leader e sarebbe in grado di resistere agli attacchi sybil dal resto della rete.

Gli operatori che abilitano questa funzionalità miglioreranno la sicurezza e le prestazioni della rete, riducendo la probabilità che i validator con stake basso o nullo (di qualità inferiore) riescano a "sopraffare" le transazioni provenienti da validator di qualità superiore (con stake più elevato), aumentando così la resistenza ai sybil attack.

Un potenziale vantaggio dell'implementazione della QoS ponderata sullo stake potrebbe essere realizzato qualora siano in vigore determinati accordi tra validator e nodi RPC. I nodi RPC potrebbero registrare più transazioni nei blocchi concordando di effettuare il peering con i validator, mentre i validator potrebbero vendere maggiore capacità ai nodi RPC. Questi accordi devono essere conclusi direttamente tra gli operatori RPC e i validator e comprendono l'implementazione dei passaggi descritti di seguito in questo documento per completare il peering.

A chi è utile la QoS ponderata sullo stake?

Gli operatori di infrastrutture RPC commerciali e le exchange saranno probabilmente tra i principali beneficiari della QoS ponderata sullo stake. Gli operatori RPC si troveranno nella posizione ideale per acquisire o negoziare accordi con validator dotati di stake, consentendo loro di ottenere una percentuale migliorata di transazioni registrate complessivamente nei blocchi. Le exchange (o altre entità) che ospitano i propri nodi validator e nodi RPC sulla stessa infrastruttura potranno abilitare la funzionalità internamente, con la certezza che i nodi RPC in esecuzione sulla propria infrastruttura siano affidabili.

Perché la QoS ponderata sullo stake è importante?

Con la QoS ponderata sullo stake abilitata, un validator che detiene l'1% di stake avrà il diritto di trasmettere fino all'1% dei pacchetti al leader. In questo modo, ai validator con stake più elevato è garantita una qualità del servizio superiore, impedendo ai validator di qualità inferiore (con meno stake) di inondare malevolmente tali transazioni, aumentando così la resistenza complessiva ai sybil attack.

In altre parole, immaginate come sarebbe il mondo se le auto con un solo passeggero potessero circolare liberamente nella corsia preferenziale. Ben presto la corsia preferenziale, progettata per spostare più persone utilizzando lo stesso tratto di autostrada, diventerebbe inutile. La funzionalità complessiva dell'autostrada ne risulterebbe compromessa e meno pendolari riuscirebbero a raggiungere le proprie destinazioni. Questo effetto è simile a ciò che accade quando ai validator con stake basso è consentito inviare transazioni al Leader con la stessa priorità dei validator con stake elevato.

Chi dovrebbe abilitare la QoS ponderata sullo stake?

La QoS ponderata sullo stake dovrebbe essere abilitata dai nodi validator abbinati a nodi RPC altamente affidabili. Ciò è utile in situazioni come quella di eseguire un RPC e un validator sulla stessa infrastruttura, dove il livello di fiducia è già elevato. La QoS ponderata sullo stake funziona meglio per configurazioni ad alta affidabilità e richiede che il validator e l'RPC raggiungano un accordo preventivo prima di abilitare la funzionalità. Si raccomanda vivamente ai validator di non tentare di abilitare la QoS ponderata sullo stake con RPC non affidabili.

Lo stake deve essere applicato ai validator che producono blocchi. Non è necessario, consigliato né efficace delegare stake ai server RPC.

Come funziona la QoS ponderata sullo stake?

Con la QoS ponderata sullo stake abilitata, i nodi RPC abbinati a un validator acquisiscono uno stake "virtuale" riguardo al modo in cui quel leader gestisce il traffico TPU (Transaction Processing Unit) in entrata da quel nodo RPC, cosa che normalmente non è possibile. Per definizione, i nodi RPC sono "senza stake" e "non votanti", ovvero "non partecipano al consenso", e non sono in grado di accedere ai vantaggi delle transazioni prioritarie tramite lo staking nello stesso modo in cui lo fanno i nodi di consenso. Come si utilizza la QoS ponderata sullo stake per registrare le transazioni? L'abilitazione della QoS ponderata sullo stake richiede la configurazione di un nodo validator e di un nodo RPC per formare una relazione di peer affidabile. Ciò comporta passaggi di configurazione separati sia per il nodo validator che per il nodo RPC elencati di seguito. Gli operatori che desiderano abilitare la QoS ponderata sullo stake avranno bisogno di quanto segue prima di iniziare:

Un validator con stake in esecuzione sulla rete E un RPC in peering con il validator

La QoS ponderata sullo stake non funzionerà a meno che ENTRAMBI i lati non siano configurati correttamente.

Configurazione del nodo validator

Sul validator, dovrai abilitare --staked-nodes-overrides /path/to/overrides.yml. Il flag --staked-nodes-overrides aiuta il validator a dare priorità alle transazioni provenienti da sorgenti note per applicare lo stake alle loro transazioni. Questo può aiutare un validator a dare priorità a determinate transazioni su host noti rispetto ad altri, abilitando l'utilizzo della QoS ponderata sullo stake con gli RPC. Gli RPC non dovrebbero avere stake in alcun modo.

Attualmente, la QoS ponderata sullo stake assegna una priorità ponderata sullo stake all'80% della capacità TPU di un leader. Tuttavia, esistono opzioni di configurazione che possono essere utilizzate per assegnare virtualmente diversi pesi di stake ai peer TPU, inclusa l'assegnazione di stake virtuale ai peer senza stake.

Il file di override per --staked-nodes-overrides si presenta così:

staked_map_id:
  pubkey1: 1000000000000000
  pubkey2: 4000000000000000

staked_map_id contiene una mappa dalla chiave pubblica dell'identità all'importo di stake in lamport da applicare a ciascun RPC. Una volta impostato, il validator darà priorità alle connessioni QUIC con l'RPC trovato in quella chiave pubblica di identità, assegnando una quantità di stake alle loro transazioni. L'80% della capacità TPU del leader verrà suddiviso proporzionalmente in base agli importi in lamport specificati nel file staked-nodes-overrides e allo stake esistente nel cluster.

Configurazione del nodo RPC

Sull'RPC dovrai utilizzare --rpc-send-transaction-tpu-peer per inoltrare le transazioni a un leader specifico. L'utilizzo esatto sarebbe --rpc-send-transaction-tpu-peer HOST:PORT. L'Host è l'indirizzo IP del leader su cui hai abilitato --staked-nodes-overrides e la Port è la porta QUIC TPU di quell'host. La porta QUIC TPU di un leader può essere identificata effettuando una chiamata RPC a getClusterNodes.

Il peering si presenterebbe come segue:

Diagramma degli RPC in peering con il validator per la QoS ponderata sullo stake

Conclusione

La QoS ponderata sullo stake è una funzionalità opzionale introdotta nella versione v1.14 del client Solana, ora noto come Agave. Agave è una versione derivata del client Solana Labs che è diventata il branch attivo utilizzato dal team Anza, un'organizzazione spin-out composta dall'ex team di ingegneria di Solana Labs.

La funzionalità QoS ponderata sullo stake sarà molto probabilmente utile per gli operatori di infrastrutture RPC che sono nella posizione di stabilire relazioni di fiducia con gli operatori di nodi con stake. Sarà inoltre utile per le exchange, che gestiscono sia nodi RPC che nodi validator e sono in grado di stabilire connessioni ad alta affidabilità internamente.