Czym jest Stake-weighted Quality of Service (QoS)?
Stake-weighted QoS (Quality-of-Service) to funkcja implementacyjna, która — po włączeniu — umożliwia liderom (producentom bloków) identyfikację i nadawanie priorytetu transakcjom przesyłanym za pośrednictwem stakowanego validator jako dodatkowy mechanizm odporności na ataki sybil. Ponieważ Solana jest siecią proof of stake, naturalne jest rozszerzenie użyteczności stake-weightingu na jakość obsługi transakcji. W tym modelu validator posiadający 0,5% stake miałby prawo do przesyłania do 0,5% pakietów do lidera i byłby w stanie odpierać ataki sybil z reszty sieci.
Operatorzy, którzy włączą tę funkcję, poprawią bezpieczeństwo i wydajność sieci, zmniejszając prawdopodobieństwo, że validator z niskim lub zerowym stake (niższej jakości) będą w stanie „zagłuszyć“ transakcje pochodzące od validator wyższej jakości (z wyższym stake) (tzw. ulepszona odporność na ataki Sybil).
Jedną z potencjalnych korzyści wdrożenia Stake-weighted QoS można by osiągnąć, gdyby między Validators a węzłami RPC obowiązywały określone porozumienia. Węzły RPC mogą trafiać więcej transakcji do bloków, zgadzając się na współpracę z Validators, a Validators mogą sprzedawać więcej przepustowości węzłom RPC. Porozumienia te muszą być zawierane bezpośrednio między operatorami RPC a Validators i obejmują wdrożenie kroków opisanych poniżej w tym dokumencie w celu ukończenia parowania.
Komu przynosi korzyści Stake-weighted QoS?
Komercyjni operatorzy infrastruktury RPC oraz giełdy prawdopodobnie znajdą się wśród głównych beneficjentów Stake-weighted QoS. Operatorzy RPC będą w idealnej pozycji, aby nabywać lub negocjować umowy ze stakowanymi validators, umożliwiając im osiągnięcie wyższego odsetka transakcji trafiających do bloków. Giełdy (lub inne podmioty), które hostują własne węzły validator i węzły RPC na tej samej infrastrukturze, będą mogły włączyć tę funkcję wewnętrznie, mając pewność, że węzły RPC działające na ich własnej infrastrukturze są godne zaufania.
Dlaczego Stake-weighted QoS jest ważny?
Po włączeniu Stake-weighted QoS validator posiadający 1% stake będzie miał prawo do przesyłania do 1% pakietów do lidera. W ten sposób validators z wyższym stake mają zagwarantowaną wyższą jakość obsługi, co zapobiega złośliwemu zalewaniu transakcji przez validator niższej jakości (z mniejszym stake), zwiększając ogólną odporność na ataki Sybil.
Innymi słowy, wyobraź sobie, jak wyglądałby świat, gdyby samochody z jednym pasażerem mogły bez przeszkód korzystać z pasa dla pojazdów wspólnych. Wkrótce pas dla pojazdów wspólnych, zaprojektowany po to, by przewozić więcej ludzi tą samą trasą, stałby się bezużyteczny. Ogólna funkcjonalność autostrady zostałaby ograniczona, a mniej kierowców mogłoby dotrzeć do celu. Podobny efekt pojawia się, gdy validators z niskim stake mogą przesyłać transakcje do Lidera z takim samym priorytetem jak validators z wysokim stake.
Kto powinien włączyć Stake-weighted QoS?
Stake-weighted QoS powinien być włączony przez węzły Validator sparowane z wysoce zaufanymi węzłami RPC. Jest to pomocne w sytuacjach takich jak uruchamianie RPC i Validator w tej samej infrastrukturze, gdzie poziom zaufania jest już wysoki. Stake-weighted QoS działa najlepiej w konfiguracjach o wysokim poziomie zaufania i wymaga, aby Validator i RPC osiągnęły porozumienie z wyprzedzeniem przed włączeniem tej funkcji. Zdecydowanie zaleca się, aby Validators nie próbowały włączać Stake-weighted QoS z niezaufanymi RPCs.
Stake powinien być przydzielany validatorom produkującym bloki. Delegowanie stake do serwerów RPC nie jest konieczne, zalecane ani skuteczne.
Jak działa Stake-weighted QoS?
Po włączeniu Stake-weighted QoS węzły RPC sparowane z validator uzyskują „wirtualny“ stake w odniesieniu do tego, jak lider traktuje przychodzący ruch TPU (Transaction Processing Unit) z tego węzła RPC — co normalnie nie jest możliwe. Z definicji węzły RPC są „unstaked“ i „non-voting“, czyli „non-consensus“, i nie są w stanie uzyskać dostępu do korzyści wynikających z nadawania priorytetu transakcjom poprzez staking w taki sam sposób, jak robią to węzły konsensusowe. Jak korzystać ze Stake-weighted QoS do realizacji transakcji? Włączenie Stake-weighted QoS wymaga skonfigurowania węzła validator i węzła RPC w celu utworzenia relacji zaufanego parowania. Wiąże się to z oddzielnymi krokami konfiguracyjnymi zarówno dla węzła validator, jak i węzła RPC opisanymi poniżej. Operatorzy chcący włączyć Stake-weighted QoS będą potrzebować następujących elementów przed rozpoczęciem:
Validator ze stake działający w sieci ORAZ RPC sparowany z validator
Stake-weighted QoS nie zadziała, jeśli OBE strony nie są prawidłowo skonfigurowane.
Konfigurowanie węzła Validator
Na validatorze konieczne będzie włączenie
--staked-nodes-overrides /path/to/overrides.yml. Flaga
--staked-nodes-overrides pomaga validatorowi nadawać priorytet transakcjom
wysyłanym ze znanych źródeł i stosować stake do ich transakcji. Może to
pomóc validatorowi nadać priorytet określonym transakcjom od znanych hostów
ponad innymi, umożliwiając korzystanie ze Stake-weighted QoS z RPCs. RPCs nie
powinny być stakowane w żaden sposób.
Obecnie Stake-weighted QoS przyznaje priorytet stake-weighted dla 80% pojemności TPU lidera. Istnieją jednak opcje konfiguracyjne, których można użyć do wirtualnego przypisania różnych wag stake do partnerów TPU, w tym przypisania wirtualnego stake niestakowanym partnerom.
Plik overrides dla --staked-nodes-overrides wygląda następująco:
staked_map_id:pubkey1: 1000000000000000pubkey2: 4000000000000000
staked_map_id zawiera mapę identity public key do kwoty stake w
lamports, która ma zostać zastosowana do każdego RPC. Po ustawieniu validator będzie nadawał priorytet połączeniom QUIC z RPC znalezionym pod danym identity publicKey, przypisując określoną ilość stake do ich transakcji. 80% pojemności TPU lidera zostanie podzielone proporcjonalnie na podstawie kwot w lamports określonych w pliku
staked-nodes-overrides oraz istniejącego stake klastra.
Konfigurowanie węzła RPC
Na RPC konieczne będzie użycie --rpc-send-transaction-tpu-peer do przekazywania
transakcji do konkretnego lidera. Dokładne użycie to
--rpc-send-transaction-tpu-peer HOST:PORT. Host to adres IP lidera, na którym włączono staked-nodes-overrides, a Port to port QUIC TPU tego hosta. Port QUIC TPU lidera można zidentyfikować, wykonując wywołanie RPC do getClusterNodes.
Parowanie wyglądałoby następująco:
Diagram RPCs parowanych z Validator dla Stake-weighted QoS
Podsumowanie
Stake-weighted QoS to opcjonalna funkcja, która pojawiła się w wersji v1.14 klienta Solana, obecnie znanego jako Agave. Agave jest forkiem klienta Solana Labs, który stał się aktywną gałęzią używaną przez zespół Anza — organizację wyodrębnioną z byłego zespołu inżynierskiego Solana Labs.
Funkcja Stake-weighted QoS najprawdopodobniej okaże się przydatna dla operatorów infrastruktury RPC, którzy mają możliwość nawiązania zaufanych relacji z operatorami stakowanych węzłów. Będzie również przydatna dla giełd, które prowadzą zarówno węzły RPC, jak i węzły validator i są w stanie nawiązywać wewnętrznie połączenia o wysokim poziomie zaufania.
Is this page helpful?