Een handleiding voor Stake-gewogen Quality of Service op Solana

Wat is Stake-gewogen Quality of Service (QoS)?

Stake-gewogen QoS (Quality-of-Service) is een implementatiefunctie die, wanneer ingeschakeld, leaders (blockproducenten) in staat stelt om transacties die via een gestakete validator worden doorgegeven te identificeren en te prioriteren als aanvullend sybil-weerstandsmechanisme. Omdat Solana een proof-of-stake-netwerk is, is het logisch om het nut van stake-weging uit te breiden naar de kwaliteit van transactiediensten. Onder dit model heeft een validator met 0,5% stake het recht om tot 0,5% van de pakketten naar de leader te verzenden en zal hij bestand zijn tegen sybil-aanvallen vanuit de rest van het netwerk.

Operators die deze functie inschakelen, verbeteren de beveiliging en prestaties van het netwerk door de kans te verkleinen dat validators met weinig of geen stake (van lagere kwaliteit) transacties van validators van hogere kwaliteit (met meer stake) kunnen 'overstemmen' (ook wel verbeterde Sybil-weerstand genoemd).

Een mogelijk voordeel van het implementeren van Stake-gewogen QoS kan worden gerealiseerd wanneer bepaalde overeenkomsten tussen Validators en RPC-nodes van kracht zijn. RPC-nodes kunnen meer transacties in blocks plaatsen door akkoord te gaan met peering met Validators, en Validators kunnen meer capaciteit verkopen aan RPC-nodes. Deze overeenkomsten moeten rechtstreeks worden gesloten tussen RPC-operators en Validators en omvatten de implementatie van de onderstaande stappen in dit document om de peering te voltooien.

Wie profiteert van Stake-gewogen QoS?

Commerciële RPC-infrastructuuroperators en exchanges zullen waarschijnlijk tot de grootste begunstigden van Stake-gewogen QoS behoren. RPC-operators zijn in een ideale positie om deals te sluiten of te onderhandelen met gestakete validators, waardoor ze een verbeterd percentage van transacties dat in blocks terechtkomt kunnen realiseren. Exchanges (of andere entiteiten) die hun eigen validator-nodes en RPC-nodes op dezelfde infrastructuur hosten, kunnen de functie intern inschakelen, met de zekerheid dat de RPC-nodes op hun eigen infrastructuur vertrouwd kunnen worden.

Waarom is Stake-gewogen QoS belangrijk?

Met Stake-gewogen QoS ingeschakeld heeft een validator met 1% stake het recht om tot 1% van de pakketten naar de leader te verzenden. Op deze manier is gegarandeerd dat validators met meer stake een hogere kwaliteit van service ontvangen, wat voorkomt dat validators van lagere kwaliteit (met minder stake) deze transacties kwaadwillig kunnen overspoelen, waardoor de algehele Sybil-weerstand toeneemt.

Anders gezegd: stel je voor hoe het er aan toe zou gaan als auto's met één passagier ongehinderd gebruik konden maken van de carpoolstrook. Al snel zou de carpoolstrook, die bedoeld is om meer mensen gebruik te laten maken van dezelfde snelweg, nutteloos worden. De algehele functionaliteit van de snelweg zou aangetast worden en minder forensen zouden hun bestemming kunnen bereiken. Dit effect is vergelijkbaar met wat er gebeurt wanneer validators met weinig stake transacties naar de Leader mogen sturen met dezelfde prioriteit als validators met veel stake.

Wie moet Stake-gewogen QoS inschakelen?

Stake-gewogen QoS moet worden ingeschakeld door Validator-nodes die zijn gekoppeld aan sterk vertrouwde RPC-nodes. Dit is nuttig in situaties zoals het uitvoeren van een RPC en een Validator op dezelfde infrastructuur, waarbij het vertrouwensniveau al hoog is. Stake-gewogen QoS werkt het beste voor configuraties met een hoog vertrouwensniveau en vereist dat de Validator en RPC van tevoren een overeenkomst bereiken voordat de functie wordt ingeschakeld. Het wordt sterk aanbevolen dat Validators niet proberen Stake-gewogen QoS in te schakelen met niet-vertrouwde RPC's.

Stake moet worden toegepast op blockproducerende validators. Het is niet nodig, aanbevolen of effectief om stake te delegeren aan RPC-servers.

Hoe werkt Stake-gewogen QoS?

Met Stake-gewogen QoS ingeschakeld krijgen RPC-nodes die zijn gekoppeld aan een validator een 'virtuele' stake met betrekking tot hoe die leader inkomend TPU-verkeer (Transaction Processing Unit) van die RPC-node behandelt, iets wat normaal gesproken niet mogelijk is. RPC-nodes zijn per definitie 'unstaked' en 'non-voting', ook wel 'non-consensus' genoemd, en hebben geen toegang tot de voordelen van geprioriteerde transacties via staking op dezelfde manier als consensusnodes. Hoe gebruik je Stake-gewogen QoS om transacties te plaatsen? Het inschakelen van Stake-gewogen QoS vereist het configureren van een validator-node en een RPC-node om een vertrouwde peer-relatie te vormen. Dit omvat afzonderlijke configuratiestappen voor zowel de validator-node als de RPC-node, die hieronder worden beschreven. Operators die Stake-gewogen QoS willen inschakelen, hebben het volgende nodig voordat ze beginnen:

Een validator met stake die actief is op het netwerk EN een RPC die is gekoppeld aan de validator

Stake-gewogen QoS werkt niet tenzij BEIDE zijden correct zijn geconfigureerd.

De Validator-node configureren

Op de validator moet je --staked-nodes-overrides /path/to/overrides.yml inschakelen. De vlag --staked-nodes-overrides helpt de validator transacties te prioriteren die worden verzonden vanuit bekende bronnen om stake toe te passen op hun transacties. Dit kan een validator helpen bepaalde transacties te prioriteren boven bekende hosts ten opzichte van anderen, waardoor het gebruik van Stake-gewogen QoS met RPC's mogelijk wordt. RPC's mogen op geen enkele manier gestakete zijn.

Momenteel geeft Stake-gewogen QoS een stake-gewogen prioriteit aan 80% van de TPU-capaciteit van een leader. Er zijn echter configuratieopties die kunnen worden gebruikt om virtueel verschillende stake-gewichten toe te wijzen aan TPU-peers, inclusief het toewijzen van virtuele stake aan unstaked peers.

Het overrides-bestand voor --staked-nodes-overrides ziet er als volgt uit:

staked_map_id:
  pubkey1: 1000000000000000
  pubkey2: 4000000000000000

staked_map_id bevat een map van identity public key naar het stakebedrag in lamports dat op elke RPC moet worden toegepast. Wanneer ingesteld, zal de validator QUIC-verbindingen prioriteren met de RPC die wordt gevonden bij die identity publicKey, en een hoeveelheid stake toewijzen aan hun transacties. De 80% van de TPU-capaciteit van de leader wordt proportioneel verdeeld op basis van de lamport-bedragen die zijn opgegeven in het staked-nodes-overrides-bestand en de bestaande clusterstake.

De RPC-node configureren

Op de RPC moet je --rpc-send-transaction-tpu-peer gebruiken om transacties door te sturen naar een specifieke leader. Het exacte gebruik zou zijn --rpc-send-transaction-tpu-peer HOST:PORT. De Host is het IP-adres van de leader waarop je staked-nodes-overrides hebt ingeschakeld en de Port is de QUIC TPU-poort van die host. De QUIC TPU-poort voor een leader kan worden geïdentificeerd door een RPC-aanroep te doen naar getClusterNodes.

De peering zou er als volgt uitzien:

Diagram van RPC's die peeren met Validator voor Stake-gewogen QoS

Conclusie

Stake-gewogen QoS is een optionele functie die werd geïntroduceerd in v1.14 van de Solana-client, nu bekend als Agave. Agave is een geforkte versie van de Solana Labs-client die de actieve branch is geworden die wordt gebruikt door het Anza-team, een afgesplitste organisatie bestaande uit het voormalige technische team van Solana Labs.

De Stake-gewogen QoS-functie zal hoogstwaarschijnlijk nuttig zijn voor RPC-infrastructuuroperators die in staat zijn vertrouwde relaties op te bouwen met gestakete node-operators. Het zal ook nuttig zijn voor Exchanges die zowel RPC-nodes als validator-nodes beheren en in staat zijn intern verbindingen met een hoog vertrouwensniveau tot stand te brengen.