Blockchains rápidas introduzem novos desafios para o gerenciamento de largura de banda e equidade RPC. Hoje estamos introduzindo um mecanismo para moldar o acesso RPC usando compromissos de staking líquidos. O sistema está ao vivo através do ShMonad RPC da FastLane. Este tópico explora a arquitetura e a lógica. 🧵

Redes de alto rendimento como Monad (~0.5s block time, ~1s finality) deixam pouco espaço para limitação reativa. No momento em que um ponto de extremidade RPC deteta que está sob ataque de spam, o dano já foi feito. A mitigação deve ser proativa e alinhada com incentivos. /2

A principal restrição é a largura de banda. Os nós adjacentes ao validador são restritos a recursos e sensíveis à latência. Se o acesso sem permissão for concedido indiscriminadamente, os clientes adversários podem excluir participantes honestos, resultando em custos degradados de UX e validador sem recurso. /3

Nossa solução aproveita o ShMonad, um token de staking líquido programável (LST) com recursos de compromisso on-chain. Os usuários recebem uma URL RPC privada em troca de comprometer o ShMON com uma "Política RPC" on-chain. Este compromisso rege os limites das taxas de acesso. /4

A largura de banda é alocada proporcionalmente: RPS do usuário = (ShMON comprometido do usuário / ShMON total comprometido) × RPS_max-global Isso produz um modelo de largura de banda dinamicamente compartilhável e ponderado por estaca sem introduzir limitadores de taxa off-chain centralizados. 5/

A estaca é confirmada por uma duração (atualmente 20 blocos), o que permite o armazenamento em cache. O revezamento sonda e fotografa intermitentemente o estado de compromisso on-chain. Isso evita chamadas EVM no caminho crítico e suporta o uso de alta frequência sem latência adicional. 6/

Empiricamente, este sistema resulta em uma latência consistentemente mais baixa. Em várias sessões de benchmarking independentes, o RPC ShMonad da FastLane apresenta um tempo de resposta mediano/médio ~20ms mais baixo do que o segundo provedor mais rápido, com uma diferença maior em relação aos RPCs públicos. 7/

O ShMON comprometido com a política RPC está apostado com validadores que participam na rede de relé FastLane (atualmente >90% dos validadores Monad). Isso cria alinhamento: os consumidores de largura de banda apoiam os mesmos validadores que atendem ao seu tráfego, e os validadores têm a possibilidade de serem compensados diretamente através de penalidades por excesso.

Mas para impor limites de largura de banda de forma credível e sem confiança, precisamos de mais do que limites de taxa... precisamos de uma aplicação comprovada. Por enquanto, os usuários estão limitados no revezamento. Mas o roteiro inclui sistemas de prova on-chain baseados em deltas nonce e recibos de uso assinados. 9/

Um design mínimo poderia comparar os nonces de conta entre as alturas de bloco n e m e a barra (ou seja, "aplicar sobretaxa" e entregá-la ao validador) o uso excessivo acima do RPS máximo. Mas há um problema: isso é vulnerável a ataques de liberação em lote por um relé fazendo com que os txs pareçam estourados.

Para mitigar isso, introduzimos um segundo canal: recibos de uso assíncronos com carimbo de data/hora. Quando uma transação é enviada, ela será multicast para o validador e um "emissor de recibo" separado. O emissor retorna um objeto assinado ao remetente, com carimbo de data/hora e incluindo metadados nonce de pré-execução. Ele tira a sobrecarga de rastreamento e verificação do caminho ativo entre o usuário e o validador. 11/

Estes recibos (que serão assinados) servem a um duplo propósito: 1. Feedback do utilizador: Se os recibos deixarem de chegar, os clientes podem interromper voluntariamente o tráfego para evitar taxas de excesso. 2. Prova on-chain: Os recibos ancoram a atividade temporal, desambiguando spam real de agrupamentos induzidos por relay. 12/

Este modelo suporta EOAs e 4337 userOps (assumindo pacotes não partilhados ou integração vertical com o nosso próprio paymaster). Em versões futuras, poderemos impor que o signatário da transação corresponda ao tomador da apólice ou tenha sido incluído na lista de permissões durante o compromisso da apólice. TBD. 13/

Nosso objetivo é levar a aplicação on-chain sem sacrificar o desempenho. Graças ao espaço de bloco abundante e à rápida finalização da Monad, enviar provas estaduais, verificar recibos e cobrar taxas de excesso é viável on-chain... algo inviável em redes de custo mais elevado. 14/

As penalizações por excesso de idade (análogas às tarifas de congestionamento) ainda estão a ser concebidas. Estamos aguardando a estrutura finalizada do mercado de taxas da Monad antes de finalizar um cronograma de sobretaxa - não faria sentido para nós projetar a taxa de overage sem saber qual é a taxa básica. 15/

A taxa de transferência RPC é atualmente medida em agregado (txs + eth_call), mas atualizações futuras desagregarão classes de largura de banda. As solicitações de leitura serão roteadas através de nós otimizados regionalmente, removendo-os do gargalo criado pelas restrições de largura de banda do validador. 16/

Para aplicações sensíveis à latência (por exemplo, nós completos, formadores de mercado), suportamos peering e alimentação direta de blocos via p2p. Para blocos completos, a prioridade de propagação será ponderada pelo stake (LSWQoS): usuários com ShMON comprometido mais alto recebem blocos marginalmente mais cedo, sujeitos a limiares de inclusão. 17/

Isto representa uma mudança em relação ao RPC tradicional de "melhor esforço". Com pedidos de leitura para um RPC, o montante de participação comprometida determina o número de pedidos. Para blocos enviados a partir dos nossos nós, o montante de participação comprometida determina a ordem de envio. 18/

O controlo de acesso sem confiança é viável em cadeias de alta capacidade se os incentivos, a aplicação e a observabilidade forem projetados a partir de princípios fundamentais. O RPC ShMonad é uma implementação de referência dessa tese. Aguardamos com expectativa iterações e escrutínio externo. 19/