Blockchains rápidos apresentam novos desafios para o gerenciamento de largura de banda e justiça RPC. Hoje estamos introduzindo um mecanismo para moldar o acesso RPC usando compromissos de staking líquido. O sistema está ativo por meio do ShMonad RPC da FastLane. Este tópico explora a arquitetura e a lógica. 🧵

Redes de alto rendimento como o Monad (~0,5s de tempo de bloco, ~1s de finalidade) deixam pouco espaço para limitação reativa. No momento em que um endpoint RPC detecta que está sob ataque de spam, o dano já foi feito. A mitigação deve ser proativa e alinhada a 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. Esse compromisso rege os limites de taxa de acesso. /4

A largura de banda é alocada proporcionalmente: RPS do usuário = (ShMON confirmado do usuário / ShMON total comprometido) × RPS_max-global Isso produz um modelo de largura de banda ponderado por participação dinamicamente compartilhável sem introduzir limitadores de taxa centralizados fora da cadeia. 5/

O Stake é confirmado por um período (atualmente 20 blocos), o que permite o armazenamento em cache. O retransmissor pesquisa e captura instantâneos intermitentemente do 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, esse sistema resulta em latência consistentemente menor. Em várias sessões de benchmarking independentes, o ShMonad RPC do FastLane exibe um tempo de resposta mediano/médio ~20 ms menor do que o segundo provedor mais rápido, com uma lacuna maior em relação aos RPCs públicos. 7/

O ShMON comprometido com a política RPC é apostado com validadores que participam da rede de retransmissão FastLane (atualmente >90% dos validadores Monad). Isso cria alinhamento: os consumidores de largura de banda suportam os mesmos validadores que atendem ao seu tráfego, e os validadores têm o potencial de serem compensados diretamente por meio de penalidades por excesso de idade. 8/

Mas para impor limites de largura de banda com credibilidade e sem confiança, precisamos de mais do que limites de taxa ... precisamos de uma aplicação comprovável. Por enquanto, os usuários estão limitados no relé. 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 da conta entre as alturas de bloco n e m, e o uso excessivo de barra (ou seja, 'aplicar sobretaxa' e entregá-lo ao validador) acima do RPS máximo. Mas há um problema: isso é vulnerável a ataques de liberação em lote por um retransmissor, fazendo com que os txs pareçam intermitentes.

Para atenuar isso, introduzimos um segundo canal: recibos de uso com carimbo de data/hora assíncrono. 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 quente entre o usuário e o validador. 11/

Esses recibos (que serão assinados) têm dupla finalidade: 1. Feedback do usuário: Se os recibos pararem de chegar, os clientes podem interromper voluntariamente o tráfego para evitar taxas excedentes. 2. Prova on-chain: os recibos ancoram a atividade temporal, desambiguando o spam real do envio em lote induzido por retransmissão. 12/

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

Nosso objetivo é mover a aplicação on-chain sem sacrificar o desempenho. Graças ao espaço de bloco abundante e à finalidade rápida do Monad, enviar provas estaduais, verificar recibos e cobrar taxas excedentes é viável na cadeia... algo inviável em redes de custo mais alto. 14/

As penalidades por excesso (análogas ao preço do congestionamento) ainda estão em andamento. Estamos aguardando a estrutura finalizada do mercado de taxas da Monad antes de finalizar um cronograma de sobretaxa - não faria sentido projetarmos a taxa excedente sem saber qual é a taxa básica. 15/

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

Para aplicativos sensíveis à latência (por exemplo, nós completos, formadores de mercado), oferecemos suporte a peering e feed de bloco direto via p2p. Para blocos completos, a prioridade de propagação será ponderada por stake (LSWQoS): usuários com ShMON confirmado mais alto recebem blocos marginalmente mais cedo, sujeitos a limites de inclusão. 17/

Isso representa um afastamento do RPC tradicional de "melhor esforço". Com solicitações de leitura para um RPC, o valor da participação comprometida determina o número de solicitações. Para blocos enviados de nossos nós, o valor da aposta comprometida determina a ordem de envio. 18/

O controle de acesso sem confiança é viável em cadeias de alta taxa de transferência se os incentivos, a aplicação e a observabilidade forem projetados a partir dos primeiros princípios. O RPC ShMonad é uma implementação de referência dessa tese. Estamos ansiosos para iteração e escrutínio externo. 19/