Blockchains rápidos introduzem novos desafios para a gestão de largura de banda e a equidade de RPC. Hoje, estamos a introduzir um mecanismo para moldar o acesso a RPC usando compromissos de staking líquido. O sistema está ativo através do RPC ShMonad da FastLane. Este tópico explora a arquitetura e a razão por trás disso. 🧵

Redes de alto rendimento como a Monad (~0,5s de tempo de bloco, ~1s de finalização) deixam pouco espaço para estrangulamento reativo. Quando um ponto de extremidade RPC detecta que está sob um ataque de spam, o dano já foi feito. A mitigação deve ser proativa e alinhada com incentivos. /2

A principal limitação é a largura de banda. Nós adjacentes aos validadores são limitados em recursos e sensíveis à latência. Se o acesso sem permissão for concedido indiscriminadamente, clientes adversários podem excluir participantes honestos—resultando em uma experiência de usuário degradada e custos para os validadores sem recurso. /3

A nossa solução utiliza o ShMonad, um token de staking líquido programável (LST) com capacidades de compromisso em cadeia. Os utilizadores recebem uma URL RPC privada em troca do compromisso de ShMON a uma "Política RPC" em cadeia. Este compromisso governa os limites de taxa de acesso. /4

A largura de banda é alocada proporcionalmente: a RPS do utilizador = (ShMON comprometido do utilizador / ShMON total comprometido) × RPS_max-global Isto resulta num modelo de largura de banda dinamicamente partilhável e ponderado por participação, sem introduzir limitadores de taxa centralizados fora da cadeia. 5/

O Stake está comprometido por uma duração (atualmente 20 blocos), o que permite o caching. O relay intermitentemente faz polling e snapshots do estado de compromisso on-chain. Isso previne chamadas EVM no caminho crítico e suporta 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 provável. Por enquanto, os utilizadores estão limitados no relé. Mas o roteiro inclui sistemas de prova em cadeia baseados em deltas de nonce e recibos de utilização assinados. 9/

Um design minimalista poderia comparar os nonces das contas entre as alturas de bloco n e m, e penalizar (ou seja, 'aplicar uma 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 relay que faz com que as transações pareçam explosivas.

Para mitigar isso, introduzimos um segundo canal: recibos de uso assíncronos com carimbo de data/hora. Quando uma transação é submetida, ela será multicast tanto para o validador quanto para um "emissor de recibos" separado. O emissor retorna um objeto assinado ao remetente, com carimbo de data/hora e incluindo metadados de nonce de pré-execução. Isso retira a sobrecarga de rastreamento e verificação do caminho quente 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 tanto EOAs quanto userOps 4337 (assumindo pacotes não compartilhados ou integração vertical com o nosso próprio pagador). Em versões futuras, podemos impor que o signatário da transação corresponda ao titular da política ou tenha sido autorizado durante o compromisso da política. A ser determinado. 13/

O nosso objetivo é mover a aplicação da lei para a blockchain sem sacrificar o desempenho. Graças ao amplo espaço de bloco da Monad e à rápida finalização, submeter provas de estado, verificar recibos e cobrar taxas de excesso é viável na blockchain... algo inviável em redes de maior custo. 14/

As penalizações por excesso (análogas à precificação de congestionamento) ainda estão em fase de design. Estamos aguardando a estrutura de mercado de taxas finalizada da Monad antes de finalizarmos um cronograma de sobretaxa - não faria sentido para nós projetar a taxa de excesso sem saber qual é a taxa base. 15/

A capacidade de RPC está atualmente medida em agregado (txs + eth_call), mas futuras atualizações irão desagregar as classes de largura de banda. As solicitações de leitura serão direcionadas através de nós otimizados regionalmente, removendo-os do estrangulamento criado pelas limitações de largura de banda dos validadores. 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/