Somente para fins educacionais; não constitui aconselhamento de investimento. Um endpoint RPC incorreto ou malicioso pode expor atividades, devolver dados enganosos ou interromper o envio de transações, e transações com ativos digitais podem causar perdas irreversíveis.
Resposta direta
Um nó RPC é um nó de blockchain, ou um serviço diante de um ou mais nós, que aceita chamadas de procedimento remoto de carteiras, exploradores e aplicativos. Em redes compatíveis com Ethereum, a interface comum é JSON-RPC. Ela permite ler dados do nó, simular chamadas, estimar gas e enviar bytes de transações assinadas para transmissão sem manter um nó próprio.
A URL configurada na carteira é um endpoint RPC, não a própria blockchain. Trocá-la pode contornar indisponibilidade do provedor, nó desatualizado, limite de solicitações, método sem suporte ou falha de conexão. Isso não muda regras de contratos, recupera uma transação revertida, desfaz uma transferência confirmada nem corrige uma paralisação geral da rede. O novo endpoint deve atender à rede e ao ID de cadeia pretendidos.
Como funciona
O cliente envia uma solicitação por um transporte compatível, como HTTP ou WebSocket. Uma solicitação JSON-RPC indica um método, fornece parâmetros e inclui um identificador repetido na resposta. O nó executa o método sobre sua visão local da cadeia e devolve um resultado ou erro. Conexões WebSocket também podem oferecer assinaturas quando cliente e endpoint têm esse recurso.
Métodos de leitura têm significados e requisitos distintos. Por exemplo, eth_blockNumber informa o bloco mais recente conhecido pelo nó, enquanto eth_getBalance lê o saldo de um endereço em uma etiqueta ou número de bloco específico. Resultados podem divergir temporariamente entre nós saudáveis devido a diferenças na ponta da cadeia, pools pendentes, modos de poda ou extensões. Um provedor hospedado também pode impor autenticação, cotas, limites de tamanho ou restrições de método que não são regras de consenso.
Em uma transação típica, a carteira constrói e assina localmente e envia os bytes assinados com eth_sendRawTransaction. O nó RPC verifica a solicitação e tenta propagar a transação aos pares. O retorno de um hash significa que o nó aceitou os bytes para envio; não prova inclusão, sucesso ou finalidade. A inclusão e o estado devem ser verificados de forma independente na cadeia correta.
Assim, o endpoint é uma dependência de confiança e disponibilidade. Ele pode observar endereços consultados, informações de IP, horários e transações enviadas; pode omitir ou atrasar dados e apresentar uma visão antiga ou incompleta. Assinaturas criptográficas impedem a alteração silenciosa de uma transação bem assinada, mas não tornam verdadeiras as respostas de leitura nem protegem metadados não assinados e privacidade.
Exemplo
Uma carteira pode solicitar o número do bloco a um cliente de execução Ethereum com esta mensagem:
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}Uma resposta válida pode ser:
{"jsonrpc":"2.0","id":1,"result":"0x12ab34"}O resultado hexadecimal é o último número de bloco conhecido pelo endpoint. Se o provedor habitual expirar, mas um segundo endpoint confiável devolver um bloco mais recente e o ID de cadeia esperado, a troca pode restaurar consultas de saldo e envio de transações. Se ambos mostrarem o mesmo recibo revertido, mudar o RPC não altera esse resultado na cadeia.
Riscos e controles
- Rede errada: um endpoint copiado pode atender a outra cadeia ou bifurcação. Antes de assinar, confirme por uma fonte independente o ID de cadeia, o nome da rede, o ativo nativo e um bloco recente.
- Leituras falsas ou antigas: um endpoint defeituoso ou malicioso pode devolver saldos velhos, omitir logs ou distorcer simulações. Compare leituras importantes com outro provedor ou nó próprio e fixe um bloco explícito quando precisar de reprodutibilidade.
- Vazamento de privacidade: consultas podem ligar a atividade da carteira a metadados de rede. Evite endereços desnecessários, revise políticas de retenção e considere um endpoint próprio confiável quando a privacidade justificar o custo operacional.
- Censura ou atraso: o endpoint pode recusar ou atrasar a transmissão. Guarde o hash assinado, consulte exploradores ou nós independentes e use outra rota confiável se a transação não aparecer. Não assine uma substituição sem verificar o nonce e o efeito sobre taxas.
- Credenciais expostas: chaves de API em código público podem ser roubadas e esgotar cotas. Restrinja por origem ou serviço quando possível, mantenha credenciais privilegiadas fora do cliente e troque chaves vazadas.
- Exposição perigosa do nó: publicar uma interface administrativa ou ampla aumenta a superfície de ataque. Vincule o RPC próprio à interface local por padrão, exponha apenas os namespaces necessários, adicione autenticação e controles de rede e nunca exponha contas desbloqueadas.
- Engano da carteira: uma URL de endpoint não precisa de frase-semente nem chave privada. Rejeite serviços que as peçam, confira os campos da transação na carteira e não identifique o contrato de destino apenas por uma resposta RPC.
Equívocos comuns
- “RPC é a blockchain.” É uma interface para a visão da blockchain mantida por um nó.
- “Um hash significa confirmação.” Em geral, só prova que o endpoint aceitou os bytes assinados; execução e finalidade são etapas distintas.
- “Trocar o RPC muda taxas ou contratos.” Pode mudar estimativas ou qualidade de acesso, mas a execução real depende da transação e das regras do protocolo.
- “Todos os endpoints devolvem os mesmos dados.” Sincronização, pools pendentes, histórico retido, extensões e políticas podem variar.
- “HTTPS torna toda resposta confiável.” HTTPS protege a conexão com o servidor indicado, mas não prova que os dados da blockchain sejam completos ou corretos.
Tópicos relacionados
Fontes
- API JSON-RPC - Ethereum.org (acessado em: 2026-08-21)
- Especificação da API de execução - Ethereum Execution APIs (acessado em: 2026-08-21)
- Servidor JSON-RPC - go-ethereum (acessado em: 2026-08-21)
- Execute seu próprio nó Ethereum - Ethereum.org (acessado em: 2026-08-21)