Qualidade de Serviço Ponderada por Stake: tudo o que você precisa saber

Introdução

A Solana está na vanguarda da tecnologia blockchain como uma rede de alto throughput e baixa latência, ampliando os limites do que uma rede descentralizada pode alcançar. No entanto, isso traz desafios significativos. Um momento decisivo no desenvolvimento da Solana foi sua interrupção de 30 de abril de 2022, que ressaltou a necessidade de mecanismos mais robustos para lidar com grandes volumes de transações e manter o desempenho da rede sob carga intensa.

A Qualidade de Serviço Ponderada por Stake (SWQoS) foi criada em resposta a esse evento. Esse mecanismo prioriza o tráfego da rede com base no stake mantido pelos validadores, garantindo que aqueles com mais stake possam enviar transações com maior prioridade. A SWQoS foi projetada para impedir que validadores com pouco stake sobrecarreguem a rede, aumentando a resiliência e a eficiência da Solana.

Este artigo explora a SWQoS, o modelo de processamento de transações da Solana e como a SWQoS o influencia. Também aborda as conexões com stake, sua configuração e a diferença entre SWQoS e taxas de prioridade. Além disso, o artigo discute implicações futuras, especificamente a crescente importância dos validadores e dos tokens de staking líquido (LSTs), as barreiras de entrada e as premissas de confiança inerentes a esse sistema.

Este artigo pressupõe conhecimento sobre o modelo de programação da Solana e QUIC. Se você não conhece esses tópicos, recomendamos ler primeiro os seguintes artigos antes de se aprofundar neste:

• O modelo de programação da Solana: uma introdução ao desenvolvimento na Solana
• Como mitigar spam rapidamente com QUIC: tudo o que você precisa saber sobre Solana e QUIC

Ainda assim, fornecemos contexto sempre que necessário.

O que é Qualidade de Serviço Ponderada por Stake?

A Qualidade de Serviço Ponderada por Stake (SWQoS) é um mecanismo que prioriza o tráfego da rede com base no stake mantido pelos validadores. Esse mecanismo garante que validadores com mais stake possam enviar transações de maneira mais eficaz, melhorando a qualidade do serviço.

Como a Solana é uma rede de Proof of Stake, é natural estender a ponderação por stake ao desempenho das transações. Em termos simples, a Solana usa o stake (ou seja, fundos bloqueados com um validador para proteger a rede) para indicar o grau de confiabilidade de um validador. Quanto mais stake um validador detém, maior é seu interesse direto na segurança e na confiabilidade da rede. Além disso, a qualidade de serviço é um conceito de redes no qual determinados pacotes são priorizados para que tenham um desempenho mais confiável na rede. Assim, a Solana oferece aos validadores com stake um desempenho mais confiável no envio de transações, encaminhando-as por conexões priorizadas.

O principal objetivo da SWQoS é impedir que validadores com pouco stake sobrecarreguem a rede com transações que acabariam suprimindo as enviadas por validadores de maior qualidade ou com mais stake. Por exemplo, se um validador detém 5% do stake total, ele pode enviar 5% do total de pacotes ao líder. A SWQoS pode ser considerada um mecanismo de resistência a ataques Sybil, pois dificulta que agentes mal-intencionados inundem a rede com transações de “baixa qualidade”.

Imagine que você esteja em um evento popular, como um show ou parque de diversões, com um número limitado de ingressos. Há filas comuns nas quais qualquer pessoa pode aguardar para comprar ingressos, mas elas podem ficar longas e lentas. Também há filas VIP reservadas para clientes que pagam mais. Essas filas VIP são muito menores e mais rápidas porque o acesso é limitado a quem atende a determinados critérios, como possuir uma associação específica, e um número definido de pessoas tem entrada garantida por vez. No contexto da Solana, a SWQoS funciona como essas filas VIP, nas quais o acesso é determinado pela quantidade de stake que um validador detém. Quanto mais stake você tem, mais acesso VIP (ou seja, conexões priorizadas) recebe, garantindo um processamento de ingressos (transações) mais rápido e confiável.

Então, como isso funciona na prática? Primeiro, é importante entender como a Solana processa transações.

Como a Solana processa transações

A Unidade de Processamento de Transações (TPU) da Solana gerencia e executa transações com eficiência. O processamento ocorre em várias etapas distintas para garantir que as transações sejam validadas, executadas e propagadas pela rede. São elas: Fetch Stage, SigVerify Stage, Banking Stage, serviço de Proof of History (PoH) e Broadcast Stage.

Fetch Stage

A Fetch Stage recebe transações dos clientes pela rede. Ela agrupa as entradas de um socket UDP em lotes e as classifica em três sockets principais:

• tpu: para transações comuns, como transferências de tokens, emissão de NFTs e interações com programas
• tpu_vote: para transações de voto
• tpu_forwards: encaminha pacotes não processados ao próximo líder caso o líder atual não consiga processar todas as transações.

Esses sockets são criados no Gossip e armazenados na struct ContactInfo, marcados por seu socket correspondente.

A Fetch Stage usa um mecanismo para combinar pacotes recebidos simultaneamente, reduzindo o número de operações individuais de processamento e aumentando o throughput. Ao receber pacotes encaminhados, ela os marca com uma flag FORWARDED para garantir que sejam reconhecidos corretamente nas etapas seguintes. Se o nó não for o líder atual, esses pacotes encaminhados serão descartados para evitar processamento desnecessário. No entanto, se o nó for o líder, esses pacotes serão aceitos e processados adequadamente.

A Fetch Stage cria canais sem limite (por exemplo, packet_sender, packet_receiver) para passar as transações à etapa seguinte, a SigVerify Stage. Esses canais desacoplam as etapas da TPU, permitindo que operem simultaneamente sem bloquear umas às outras. A função unbounded cria um canal com capacidade ilimitada para garantir que os pacotes não sejam descartados por sobrecarga do canal. 

As transações são agrupadas em lotes de 128 pacotes antes de serem encaminhadas à SigVerify Stage. Esse agrupamento ajuda a processar as transações com mais eficiência e reduz a sobrecarga associada ao tratamento de pacotes individuais. 

Observe que a Fetch Stage opera em várias threads para lidar com um alto throughput. Cada thread é responsável por uma tarefa específica, como receber pacotes, processar lotes e encaminhar transações. Uma thread para cada tipo de socket (ou seja, tpu, tpu_vote, tpu_forwards) é criada com a função streamer::receiver. Cada thread monitora o socket atribuído, processa os pacotes recebidos e os envia pelo canal apropriado.

Ao gerenciar com eficiência a entrada e a classificação das transações, a Fetch Stage estabelece a base para todas as etapas de processamento seguintes na TPU da Solana.

SigVerify Stage

A SigVerify Stage é a segunda etapa do pipeline de processamento de transações da Solana. Ela é essencial para garantir a integridade e a autenticidade das transações. 

Nessa etapa, a TPU recebe da Fetch Stage transações agrupadas em lotes por meio de canais sem limite. A principal tarefa aqui é verificar as assinaturas das transações usando o esquema de assinatura Ed25519. Essa validação criptográfica confirma que o proprietário correto das contas envolvidas assinou a transação.

A SigVerify Stage foi projetada para oferecer alto desempenho, aproveitando os recursos de processamento paralelo de CPUs e GPUs modernas para verificar assinaturas. Por padrão, a CPU realiza todo o processamento. No entanto, devido à natureza paralelizada da tarefa, transferir o trabalho para a GPU acelera significativamente o processo quando bibliotecas de desempenho estão disponíveis.

O processo começa com a função new, que inicializa a SigVerify Stage e configura os canais receptores necessários para receber pacotes da Fetch Stage. A função verifier é responsável por receber grupos e verificar assinaturas. Ela realiza a desduplicação, descarta o excesso de pacotes e verifica os pacotes restantes. A função usa o método ed25519_verify de verificação de assinaturas. Durante períodos de alto volume de transações, ocorre descarte de carga. É nesse momento que a SigVerify Stage descarta pacotes excedentes. Ela faz isso agrupando os pacotes pelo endereço IP de origem e definindo um número máximo de pacotes a processar por endereço.

As transações com assinaturas inválidas são sinalizadas e descartadas. Esse processo garante que apenas transações válidas avancem, impedindo que transações fraudulentas ou incorretas prossigam para a próxima etapa.

Após a verificação das assinaturas, as transações válidas são encaminhadas à etapa seguinte (ou seja, a Banking Stage) por outro conjunto de canais sem limite. Isso garante que as etapas permaneçam desacopladas e possam operar simultaneamente. Observe que essa etapa funciona em várias threads, cada uma processando um subconjunto de transações, verificando assinaturas e realizando desduplicação e descarte de carga.

Banking Stage

A Banking Stage é a terceira etapa do pipeline de processamento de transações da Solana. Essa etapa é crítica, pois é nela que as transações são executadas e aplicadas ao estado atual do ledger. A Banking Stage usa o runtime exclusivo Sealevel da Solana para permitir o processamento paralelo de transações com alto throughput.

A Banking Stage tem seis threads: duas dedicadas ao processamento de transações de voto provenientes da TPU ou do Gossip e quatro dedicadas a transações que não são de voto. Cada thread opera de forma independente e recebe pacotes de um canal compartilhado (observe que isso mudará após a versão 1.18), para o qual a SigVerify envia pacotes em lotes. Cada thread extrai transações desse canal compartilhado e as armazena em um buffer local. O buffer local funciona como uma fila de prioridade, sendo atualizado dinamicamente para refletir mudanças em tempo real no status das transações e nas demandas da rede. 

O tratamento dessas transações depende de o validador estar ou não na programação de líderes. Se o validador não estiver perto de se tornar líder, ele encaminha os pacotes ao próximo líder e depois os descarta. À medida que se aproxima de seu turno (a cerca de ~20 slots), ele continua encaminhando os pacotes, mas os retém caso os próximos líderes não consigam processá-los. Quando está a dois slots de se tornar líder, o validador mantém os pacotes para garantir que sejam processados quando assumir a liderança.

Cada thread processa transações durante a produção de blocos, extraindo as 128 transações prioritárias de sua fila local. O processo envolve etapas como bloqueio, verificação, carregamento, execução, registro, confirmação e desbloqueio. 

A Banking Stage usa uma abordagem com múltiplos iteradores para agrupar transações em lotes. Essa abordagem permite percorrer simultaneamente um conjunto de dados e agrupar as transações em lotes sem conflitos. Primeiro, as transações são serializadas em um vetor baseado em prioridade. Em seguida, o multi-iterador posiciona iteradores em pontos nos quais as transações não entram em conflito, criando lotes de 128 transações. As transações conflitantes são ignoradas e incluídas em lotes posteriores após a resolução dos conflitos. Depois que um lote é formado, as transações são executadas. As transações bem-sucedidas são registradas no serviço de Proof of History e transmitidas à rede por meio do Turbine.

Serviço de Proof of History (PoH)

O serviço de Proof of History (PoH) é um componente fundamental do pipeline de processamento de transações da Solana. Ele oferece uma forma verificável de acompanhar o tempo e ordenar eventos na rede, garantindo o sequenciamento eficiente e seguro das transações. Por meio do encadeamento de hashes, ele gera uma sequência criptográfica que funciona como timestamp para as transações. Essa cadeia contínua de hashes cria um registro histórico que comprova a passagem do tempo entre os eventos.

O serviço de PoH garante que todos os participantes da rede possam concordar sobre a ordem das transações sem a necessidade de uma autoridade central de controle do tempo. Ele também ajuda a sincronizar os validadores em toda a rede. Além disso, sustenta o processo de eleição de líderes da Solana ao fornecer um timestamp confiável para determinar quando um validador deve se tornar líder e produzir o próximo bloco.

O serviço de PoH começa inicializando um valor de semente, que gera uma sequência de hashes. À medida que as transações são recebidas, elas são marcadas com o hash atual da sequência de PoH, que lhes fornece um timestamp exclusivo. Em seguida, os validadores verificam a sequência de hashes para confirmar a ordem e o momento das transações.

Para saber mais sobre Proof of History, leia nosso artigo Proof of History, Proof of Stake e Proof of Work — explicados. Se criptografia parece outro idioma para você, também recomendamos nosso artigo Introdução às ferramentas criptográficas — funções hash e árvores de Merkle explicadas.

Broadcast Stage

A Broadcast Stage é a etapa final do pipeline de processamento de transações da Solana. Ela é responsável por distribuir as transações validadas e confirmadas ao restante da rede.

Depois que as transações são processadas e confirmadas durante a Banking Stage, elas são organizadas em entradas. Em seguida, essas entradas são agrupadas em estruturas de dados chamadas shreds. A Broadcast Stage serializa esses shreds, os assina e gera códigos de correção de erros para melhorar a integridade e a recuperação dos dados. Os shreds são enviados aos peers por meio de um processo estruturado de disseminação em formato de árvore chamado Turbine. Esse é um processo de distribuição eficiente e redundante, enquanto a codificação de correção de erros permite que os validadores reconstruam dados ausentes ou corrompidos.

Para uma análise mais abrangente do Turbine, leia nosso artigo Turbine: propagação de blocos na Solana.

O ciclo de vida de uma transação com SWQoS

Ao contrário de outras blockchains, a Solana não tem um mempool no qual as transações aguardam antes do processamento. Em vez disso, as transações são encaminhadas diretamente ao líder atual e processadas por sua TPU. Os usuários criam transações, direta ou indiretamente, com uma carteira ou aplicação, e as enviam a nós RPC por meio da API JSON RPC. Esses nós atuam como intermediários entre os usuários e os validadores da Solana. É importante observar que eles não devem ter nenhum stake na rede. Ou seja, os nós RPC não têm stake, não votam e, portanto, não participam do consenso.

As conexões com um líder agora são feitas por QUIC. QUIC foi adicionado às portas que recebem transações de usuários para substituir UDP na TPU da Solana. Como QUIC exige um handshake, é possível impor limites ao tráfego de um agente para que a rede se concentre no processamento de transações legítimas enquanto filtra spam. É claro que essa era a intenção da implementação de QUIC, e sua eficácia atual não será debatida neste artigo. O importante é observar que as conexões com o líder são feitas por QUIC.

Há dois tipos de conexão:

• 500 conexões abertas acessíveis a qualquer nó RPC
• 2.000 conexões ponderadas por stake, acessíveis apenas a validadores com stake. Os validadores recebem uma parcela proporcional dessas conexões com base em seu stake

Para que um RPC retransmita uma transação com eficiência, ele precisa estar pareado com um validador com stake. Como os RPCs não têm stake na rede, os validadores precisam estender virtualmente seu stake. Os validadores podem usar a flag --staked-nodes-overrides para alocar uma parte de suas conexões com stake a nós RPC específicos. 

Um validador precisa especificar o caminho de um arquivo YAML usando --staked-nodes-overrides flag para configurar suas conexões ponderadas por stake. O arquivo YAML contém mapeamentos no seguinte formato:

staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

Cada chave pública de uma determinada identidade RPC exige um valor em lamports. Esse valor especifica o peso de stake que você deseja atribuir à identidade RPC. Por exemplo, se você especificar um milhão de SOL, estará alocando a ela um milhão de SOL dividido pelo stake ativo total. Na prática, você fornece conexões com stake ao nó RPC como se ele fosse um validador com essa quantidade de stake na rede. É como dizer: “Na minha visão local, trate esta identidade RPC como se ela tivesse x de stake ao se comunicar com meu validador.” Observe que essa configuração não exige a reinicialização do validador: as alterações podem ser feitas no arquivo e recarregadas em tempo real.

Além disso, o relayer da Jito é compatível com a flag de substituições de nós com stake. Para otimizar o desempenho, recomendamos executar o relayer na mesma máquina que o nó com stake.

Para usar essas conexões com stake, os operadores de RPC devem usar a flag --rpc-send-transaction-tpu-peer, que exige o IP e a porta da TPU do validador com stake. Normalmente, a porta da TPU corresponde ao início do intervalo de portas dinâmicas mais três, conforme encontrado no Gossip. No caso da Jito, o tráfego será direcionado ao relayer executado pelo operador, pois os relayers públicos da Jito não podem ser usados. Os operadores de RPC devem procurar nos logs entradas como solana_quic_client e warm para verificar a conexão. Observe que essa configuração exige que o nó RPC execute um cliente Agave v1.17.28 ou posterior para oferecer suporte à flag necessária.

Em termos gerais, o ciclo de vida de uma transação com SWQoS permanece praticamente igual ao de uma transação comum. Os usuários criam e enviam transações por meio de nós RPC, que então as enviam ao líder. No entanto, as transações são enviadas por conexões com stake quando um nó RPC está pareado com um validador com stake e usa a flag --rpc-send-transaction-tpu-peer. Em resumo:

• Criação da transação: um usuário cria uma transação usando sua carteira, uma aplicação ou código 
• Envio a um nó RPC: a transação é enviada a um nó RPC por meio da API JSON RPC
• Conexão QUIC: o nó RPC estabelece uma conexão QUIC com o líder, usando conexões abertas ou ponderadas por stake de acordo com sua configuração
• QoS ponderada por stake: se o nó RPC estiver pareado com um validador com stake, ele usará as conexões com stake do validador, melhorando o desempenho da transação
• Encaminhamento ao líder: a transação é enviada ao líder por essas conexões com stake, com menor probabilidade de atraso ou descarte
• Processamento da transação: a transação passa pela TPU, como mencionado anteriormente, e é processada pelo líder

A SWQoS aprimora o ciclo de vida das transações ao garantir que validadores com stake e seus nós RPC pareados tenham melhor acesso ao líder, reduzindo a probabilidade de atrasos causados pelo congestionamento da rede. Esse mecanismo funciona em conjunto com as taxas de prioridade para melhorar o desempenho das transações.

SWQoS vs. taxas de prioridade: uma distinção clara

Em cenários de congestionamento da rede, a SWQoS reduz a probabilidade de que as transações de validadores com muito stake sofram atrasos ou sejam descartadas. Esse sistema pode ser, e costuma ser, comparado a uma rodovia pedagiada na qual validadores com mais stake têm acesso a caminhos menos congestionados, como se tivessem mais faixas à disposição. Considere a imagem acima, por exemplo. No Colorado, os motoristas podem ficar presos no trânsito ou pagar alguns dólares a mais para dirigir em uma faixa pedagiada. As Express Lanes são a rede de faixas premium do Colorado, cujos preços são ajustados constantemente para permanecerem altos o suficiente para manter o fluxo do trânsito. Podemos, portanto, comparar as conexões com stake da Solana às Express Lanes do Colorado, pois ambas são vias priorizadas que buscam reduzir o congestionamento para usuários premium.

No entanto, é essencial distinguir a SWQoS das taxas de prioridade, pois a analogia comum com uma rodovia pedagiada pode tornar menos clara a diferença entre esses dois conceitos:

• As taxas de prioridade entram em ação durante a Banking Stage, quando os líderes priorizam as transações com base nas taxas pagas. A ideia é que as transações que pagam taxas mais altas sejam processadas antes, garantindo uma execução mais rápida para os usuários dispostos a pagar mais.
• A SWQoS melhora o acesso às conexões e não afeta a priorização das transações na fila do líder. A SWQoS garante que validadores com stake tenham melhor acesso à rede, reduzindo a probabilidade de que transações sofram atrasos ou sejam descartadas devido ao congestionamento da rede

Enquanto as taxas de prioridade afetam a forma como as transações são ordenadas e processadas depois que entram na fila do líder, a SWQoS garante que transações enviadas por validadores com stake tenham uma via priorizada para chegar ao líder. Ambos os mecanismos buscam melhorar o desempenho da rede, mas operam em etapas diferentes do ciclo de vida das transações.

As guerras da SWQoS

A SWQoS deve se tornar um aspecto fundamental da infraestrutura de rede da Solana daqui em diante. Ela influenciará significativamente o ecossistema ao otimizar o processamento de transações e priorizar as conexões de validadores com stake ao líder. Não tenho como enfatizar esse fato o suficiente.

Pode-se argumentar que a vantagem de usar validadores com muito stake começa a diminuir quando a rede não está congestionada e as transações não são sensíveis ao tempo. Isso ocorre porque a rede tem capacidade suficiente para processar transações rapidamente, independentemente do peso do stake por trás delas. No entanto, conforme a demanda pela Solana cresce e a adoção em massa se aproxima, a rede pode nem sempre ter capacidade suficiente para processar todas as transações sem atrasos ou descartes ocasionais. Isso não significa que a Solana não possa escalar, pois ela é, indiscutivelmente, uma das melhores opções de blockchain escalável, se não a melhor. A questão é que, à medida que a demanda cresce, a SWQoS continuará sendo importante para oferecer uma UX excelente.

Por sua vez, o papel dos validadores se torna ainda mais crucial, levando a mais concorrência e inovação para oferecer o melhor serviço possível. Naturalmente, isso não significaria que todos gostariam de executar o próprio validador?   

Validadores e tokens de staking líquido (LSTs)

A tendência é clara: todo protocolo sério da Solana executará um validador. Isso será necessário para sustentar sua aplicação. Se você tem interesse em executar seu próprio validador, temos este guia no blog da Helius sobre como começar.

Estamos à beira de uma enorme explosão cambriana de LSTs na Solana, intensificada pela SWQoS. Somente neste mês, o stake total (ou seja, nativo + LST) aumentou aproximadamente 3,2 milhões. Atualmente, o valor de mercado apenas dos LSTs está entre 6 e 9 bilhões de dólares neste mês. Protocolos como o Sanctum estão se consolidando como grandes participantes, pois sua plataforma permite que validadores e aplicações criem seus próprios LSTs. Além disso, a Picasso Network permite restaking na Solana, funcionando como um hub para que LSTs tenham maior utilidade e rendimento. Portanto, a capacidade de criar um LST com utilidade adicional já existe e está em plena expansão.

No entanto, é preciso considerar algumas possíveis barreiras de entrada.

Barreiras de entrada

Apesar de seus possíveis benefícios, a SWQoS introduz várias barreiras de entrada. Mais especificamente, um requisito mínimo de stake foi introduzido na v1.17.31 do cliente Agave para tratar validadores com pouco stake como peers sem stake. O problema era que nós com pouco stake podiam abusar das conexões com stake ao receber uma largura de banda desproporcional. Agora, nós com uma proporção de stake inferior à fórmula a seguir são tratados como não tendo stake:

stake / total_stake < 1 / (max packet per 100ms)

Isso significa que clientes com menos de aproximadamente 15.000 SOL em stake agora são classificados como validadores sem stake. Esse requisito pode elevar ainda mais as já altas exigências financeiras e técnicas para executar um validador da Solana, possivelmente impedindo que participantes menores e validadores independentes participem da rede. Esse requisito equivale a aproximadamente 3 milhões de dólares, o que parece muito à primeira vista. 

No entanto, como Austin Federa observa, o limite corresponde a apenas 1/25.000 do stake total, o que pode ser considerado baixo. Além disso, se a maioria dos validadores que disputam stake melhorar continuamente seu desempenho para oferecer o melhor serviço possível e maximizar os próprios retornos, isso beneficiará a rede como um todo. É exatamente isso que Toly descreve como o objetivo geral da SWQoS.

Na Helius, estamos reduzindo a barreira de entrada para todos os planos pagos que enviam transações com a taxa recomendada pela Helius. Ou seja, qualquer usuário que enviar transações por meio de um plano compartilhado pago será encaminhado por nossas conexões com stake se usar um valor igual ou superior ao recomendado por nossa API de taxas de prioridade. Também simplificamos esse processo com nossa nova funcionalidade Smart Transactions, adicionada aos nossos SDKs para Node.js e Rust. No nível mais básico, independentemente do SDK usado, os usuários fornecem seu par de chaves e as instruções que desejam executar, e nós cuidamos do restante. Agora, os usuários podem acessar conexões compartilhadas com stake por apenas 50 USD por mês em um plano Developer. Observe que também oferecemos conexões dedicadas com stake, que garantem largura de banda e são recomendadas para grandes empresas, quants e empresas de trading. Se você tiver interesse em conexões dedicadas com stake, entre em contato com nossa equipe de vendas.

É importante observar que o stake provavelmente começará a se concentrar entre validadores operados por grandes protocolos e provedores de RPC capazes de cobrar 0% de comissão. Considere a Helius, por exemplo: podemos gerar receita em outras áreas para subsidiar os custos de operação de um validador. Fazemos isso para melhorar a descentralização da rede, mantendo um validador de alto nível operado por uma equipe nativa da Solana e, ao mesmo tempo, obtendo maior acesso a conexões com stake para aprimorar a experiência dos nossos usuários.

Premissas de confiança

Se o stake provavelmente se concentrará entre validadores operados por grandes protocolos e provedores de RPC, é importante delegá-lo a um validador que priorize os interesses da Solana. A SWQoS introduz várias premissas de confiança.

Uma das principais premissas é a necessidade de um alto nível de confiança entre validadores e nós RPC. Como descrito ao longo deste artigo, a SWQoS permite que os líderes identifiquem e priorizem transações de validadores com stake. Como os nós RPC não têm stake, não votam e não participam do consenso, eles não podem se beneficiar diretamente das transações priorizadas da mesma forma que os validadores com stake. Portanto, validadores e nós RPC precisam estabelecer uma relação de confiança para aproveitar os benefícios da SWQoS.

Essa relação de confiança é crucial porque habilitar a SWQoS envolve compartilhar configurações de rede confidenciais e permite que os nós RPC influenciem a priorização das transações. Os validadores precisam garantir que os nós RPC com os quais se pareiam atuarão no melhor interesse da rede e não usarão indevidamente o stake estendido para fins maliciosos. Validadores e nós RPC devem estabelecer previamente um acordo e um entendimento mútuo sobre como as conexões com stake serão usadas. O ideal é que essa configuração exista entre entidades com alto nível de confiança, como parceiros de longa data ou integrantes da mesma organização.

Atualmente, essas relações costumam permanecer ocultas. E, daqui em diante, não vislumbro um futuro no qual os operadores de RPC não negociem substituições de stake com validadores. É necessária mais transparência para que o usuário comum saiba quais RPCs e validadores está apoiando. Essa demanda só aumentará com o tempo.

Conclusão

A SWQoS está pronta para revolucionar a infraestrutura de rede da Solana. Embora ofereça muitos benefícios, incluindo melhor desempenho das transações e maior resistência a ataques Sybil, ela também introduz novos desafios e premissas de confiança que precisam ser tratados com cuidado. Embora a SWQoS tenha sido projetada para priorizar transações enviadas por validadores com stake, atualmente nada impõe essa prioridade. Validadores profissionais costumam substituir as configurações padrão e podem até bloquear determinados agentes. Isso destaca a necessidade de confiança e transparência nas relações entre validadores e nós RPC para garantir o uso justo e eficaz da SWQoS. De qualquer forma, sua implementação representa um avanço significativo na evolução da Solana como uma rede eficiente e resiliente.

Ao longo deste artigo, exploramos a SWQoS e como ela influencia o processamento de transações. Também abordamos distinções importantes, como a diferença entre SWQoS e taxas de prioridade. Além disso, discutimos a ascensão dos validadores e dos LSTs, possíveis barreiras de entrada e as premissas de confiança envolvidas, oferecendo um ponto de partida crítico para futuras discussões. Entender todos esses elementos é essencial para aproveitar a SWQoS com eficiência e melhorar a Solana como um todo.

Se você leu até aqui, agradecemos, anon! Insira seu endereço de e-mail abaixo para nunca perder uma atualização sobre as novidades da Solana. Quer se aprofundar? Explore os artigos mais recentes no blog da Helius e continue hoje mesmo sua jornada pela Solana.

Recursos adicionais

• Relatório e medidas de mitigação da interrupção da Solana Mainnet Beta em 30/04/2022
• Guia da Qualidade de Serviço Ponderada por Stake na Solana
• Como configurar um validador da Solana
• Envio de Smart Transactions
• Educação para validadores da Solana — QoS ponderada por stake