O que é a Qualidade de Serviço Ponderada por Stake (QoS)?
O QoS (Qualidade de Serviço) ponderado por stake é uma funcionalidade de implementação que, quando ativada, permite que os líderes (produtores de blocos) identifiquem e priorizem transações transmitidas através de um validator com stake como mecanismo adicional de resistência a ataques sybil. Dado que a Solana é uma rede de prova de stake, é natural estender a utilidade da ponderação por stake à qualidade de serviço das transações. Neste modelo, um validator com 0,5% de stake teria o direito de transmitir até 0,5% dos pacotes ao líder e seria capaz de resistir a ataques sybil provenientes do restante da rede.
Os operadores que ativarem esta funcionalidade melhorarão a segurança e o desempenho da rede, reduzindo a probabilidade de que validators com pouco ou nenhum stake (de menor qualidade) consigam "sufocar" as transações provenientes de validators de maior qualidade (com maior stake) (também conhecida como resistência Sybil aprimorada).
Um benefício potencial da implementação do QoS ponderado por stake poderá ser realizado se determinados acordos entre Validators e nós RPC estiverem em vigor. Os nós RPC podem incluir mais transações em blocos ao concordarem em estabelecer peering com Validators, e os Validators podem vender mais capacidade aos nós RPC. Estes acordos devem ser feitos diretamente entre os operadores de RPC e os Validators e incluem a implementação dos passos descritos abaixo neste documento para concluir o peering.
Quem beneficia com o QoS ponderado por stake?
Os operadores de infraestrutura RPC comercial e as exchanges serão provavelmente os principais beneficiários do QoS ponderado por stake. Os operadores de RPC estarão em posição ideal para adquirir ou negociar acordos com validators com stake, permitindo-lhes alcançar uma percentagem melhorada de transações incluídas em blocos no geral. As exchanges (ou outras entidades) que alojam os seus próprios nós validator e nós RPC na mesma infraestrutura poderão ativar a funcionalidade internamente, com a confiança de que os nós RPC a correr na sua própria infraestrutura são de confiança.
Por que razão o QoS ponderado por stake é importante?
Com o QoS ponderado por stake ativado, um validator com 1% de stake terá o direito de transmitir até 1% dos pacotes ao líder. Desta forma, os validators com maior stake têm garantida uma maior qualidade de serviço, o que impede validators de menor qualidade (com menos stake) de inundar maliciosamente essas transações, aumentando a Resistência Sybil global.
Por outras palavras, imagine como seria o mundo se carros com apenas um passageiro pudessem circular livremente na faixa de alta ocupação. Em pouco tempo, essa faixa — concebida para transportar mais pessoas utilizando o mesmo troço de estrada — tornar-se-ia inútil. A funcionalidade global da estrada ficaria comprometida e menos condutores conseguiriam chegar ao seu destino. Este efeito é semelhante ao que acontece quando se permite que validators com pouco stake submetam transações ao Líder com a mesma prioridade que validators com muito stake.
Quem deve ativar o QoS ponderado por stake?
O QoS ponderado por stake deve ser ativado por nós validator emparelhados com nós RPC de elevada confiança. Isto é útil em situações como executar um RPC e um Validator na mesma infraestrutura, onde o nível de confiança já é elevado. O QoS ponderado por stake funciona melhor em configurações de alta confiança e requer que o Validator e o RPC cheguem a um acordo prévio antes de ativar a funcionalidade. É fortemente recomendado que os Validators não tentem ativar o QoS ponderado por stake com RPCs não confiáveis.
O stake deve ser aplicado a validators que produzem blocos. Não é necessário, recomendado nem eficaz delegar stake a servidores RPC.
Como funciona o QoS ponderado por stake?
Com o QoS ponderado por stake ativado, os nós RPC emparelhados com um validator obtêm um stake "virtual" relativamente à forma como esse líder trata o tráfego TPU (Unidade de Processamento de Transações) de entrada proveniente desse nó RPC, algo que normalmente não é possível. Por definição, os nós RPC são "sem stake" e "sem votação", também conhecidos como "sem consenso", e não conseguem aceder aos benefícios das transações priorizadas por meio de staking da mesma forma que os nós de consenso. Como utilizar o QoS ponderado por stake para incluir transações? A ativação do QoS ponderado por stake requer a configuração de um nó validator e de um nó RPC para formarem uma relação de peer de confiança. Isto implica passos de configuração separados tanto para o nó validator como para o nó RPC listados abaixo. Os operadores que pretendam ativar o QoS ponderado por stake precisarão do seguinte antes de começar:
Um validator com stake a correr na rede E um RPC em peering com o validator
O QoS ponderado por stake não funcionará a menos que AMBOS os lados estejam corretamente configurados.
Configurar o nó Validator
No validator, terá de ativar
--staked-nodes-overrides /path/to/overrides.yml. O
flag --staked-nodes-overrides ajuda o validator a priorizar transações
enviadas de fontes conhecidas para aplicar stake às suas transações. Isto pode
ajudar um validator a priorizar determinadas transações de hosts conhecidos em relação a outros,
permitindo a utilização do QoS ponderado por stake com RPCs. Os RPCs não devem ter stake
de qualquer forma.
Atualmente, o QoS ponderado por stake atribui uma prioridade ponderada por stake a 80% da capacidade TPU de um líder. No entanto, existem opções de configuração que podem ser utilizadas para atribuir virtualmente diferentes pesos de stake a peers TPU, incluindo a atribuição de stake virtual a peers sem stake.
O ficheiro de substituições para --staked-nodes-overrides tem o seguinte aspeto:
staked_map_id:pubkey1: 1000000000000000pubkey2: 4000000000000000
staked_map_id contém um mapa de chave pública de identidade para o montante de stake em
lamports a aplicar a cada RPC. Quando definido, o validator priorizará as ligações QUIC
com o RPC encontrado nessa publicKey de identidade, atribuindo um montante
de stake às suas transações. Os 80% da capacidade TPU do líder serão
divididos proporcionalmente com base nos montantes em lamports especificados no
ficheiro staked-nodes-overrides e no stake existente no cluster.
Configurar o nó RPC
No RPC, terá de utilizar --rpc-send-transaction-tpu-peer para encaminhar
transações para um líder específico. A utilização exata seria
--rpc-send-transaction-tpu-peer HOST:PORT. O Host é o endereço IP do
líder no qual tem o staked-nodes-overrides ativado e a Port é a porta QUIC
TPU desse host. A porta QUIC TPU de um líder pode ser identificada
efectuando uma chamada RPC a getClusterNodes.
O peering teria o seguinte aspeto:
Diagrama de RPCs em peering com o Validator para QoS ponderado por Stake
Conclusão
O QoS ponderado por stake é uma funcionalidade opcional que chegou na v1.14 do cliente Solana, atualmente conhecido como Agave. O Agave é uma versão bifurcada do cliente da Solana Labs que se tornou o ramo ativo utilizado pela equipa Anza, uma organização derivada composta pela antiga equipa de engenharia da Solana Labs.
A funcionalidade de QoS ponderado por stake será muito provavelmente útil para os operadores de infraestrutura RPC que estejam em posição de estabelecer relações de confiança com operadores de nós com stake. Também será útil para as Exchanges, que operam tanto nós RPC como nós validator e conseguem estabelecer ligações de alta confiança internamente.
Is this page helpful?