Como funciona a infraestrutura blockchain dedicada

A maioria das cargas de trabalho em produção roda bem em infraestrutura de RPC compartilhada. Um pequeno grupo delas não consegue. Uma mesa de trading cuja latência de ida e volta até o sequencer, o serviço de ordenação de transações do rollup, decide se sua ordem entra no próximo bloco. Uma empresa de segurança cujo motor de simulação roda um tracer de EVM customizado que nenhum provedor compartilhado hospeda. Uma fintech regulada cuja equipe de compliance não aprova hardware compartilhado com a carga de trabalho de outro cliente.

Para essas cargas de trabalho, a resposta é infraestrutura de blockchain dedicada.

Dedicated é a mesma infraestrutura, restrita a um único tenant. Mesma stack de RPC, mesmos serviços de dados, mesmas APIs, mas a capacidade, o host e o runtime são seus. Times como a Blockaid usam Alchemy Dedicated Clusters para proteger mais de US$312 bilhões em ativos com a performance e a consistência que seus clientes exigem.

Essa distinção é o que torna dedicated vantajoso em termos de preço para um conjunto restrito de cargas de trabalho, e o que torna shared o padrão certo para todo o resto. A pergunta útil não é se dedicated é melhor. É se sua carga de trabalho superou o que a infraestrutura compartilhada foi projetada para fazer.

O que é infraestrutura de blockchain dedicada?

Infraestrutura de blockchain dedicada é um cluster de RPC e indexação single-tenant: uma frota de nós de blockchain, infraestrutura de roteamento e serviços de dados em hardware reservado para uma única carga de trabalho. A superfície de API é a mesma da infraestrutura compartilhada por padrão, então as integrações existentes migram sem mudanças de código. A customização estende essa superfície em vez de substituí-la: tracers e binários customizados, regiões escolhidas, e precificação baseada em capacidade em vez de cobrança por requisição.

Um cluster típico inclui:

• Um pool de nós completos da chain, dimensionado para a taxa de pico de requisições do cliente mais um nó extra para que o failover não derrube tráfego durante o restart de um nó, também conhecido como o padrão N+1.
• Nós de archive opcionais para acesso ao estado histórico, que fornecem o estado completo desde o gênesis em vez de apenas os blocos recentes.
• Um edge proxy e um load balancer na frente do pool de nós, atuando como a camada de roteamento que recebe cada requisição e decide qual nó a atende.
• Uma stack de observabilidade, geralmente um dashboard Grafana expondo saúde dos nós, latência de requisições e taxas de erro.
• Um caminho de failover para infraestrutura compartilhada para picos de tráfego que o cluster não foi dimensionado para atender.

A infraestrutura tem o mesmo formato do que os provedores compartilhados rodam internamente. A diferença é o contrato de uso. Dedicated significa que a capacidade é comprometida a um cliente, o runtime é dele para configurar, e o caminho de dados não é compartilhado com a carga de trabalho de mais ninguém.

Quando uma carga de trabalho precisa de infraestrutura dedicada?

Quatro padrões de carga de trabalho ultrapassam o que a infraestrutura compartilhada consegue fazer.

Tracers e binários customizados

Tracers de EVM são as funções que instrumentam a execução de transações. Eles extraem traces de chamadas internas, leituras de storage, struct logs e motivos de revert. Os tracers padrão, como callTracer e prestateTracer, cobrem a maior parte das análises. Ferramentas de segurança, motores de simulação e plataformas forenses precisam de mais: tracers JavaScript customizados que correspondem aos seus schemas internos, ou binários geth e erigon modificados que expõem estado de execução que provedores compartilhados nunca expõem.

Rodar isso em um host compartilhado não é seguro nem para o host nem para o tenant. É por isso que fornecedores de simulação e segurança rodam clusters dedicados.

Latência vinculada a região

Para a maior parte do tráfego de aplicações, alguns hops de rede a mais são invisíveis. Para cargas de trabalho que emitem dezenas de requisições por segundo e se importam com cada uma delas, a distância física entre o cliente, o nó e o sequencer pode decidir se uma transação entra a tempo.

Trading de alta frequência, feeds de oracle e MEV searchers, que são bots que extraem valor da forma como as transações são ordenadas nos blocos, competem nessas margens. Clusters dedicados permitem que o cliente posicione pools de nós na mesma região do sequencer ou do consumidor.

Isolamento regulatório

Alguns frameworks de compliance exigem computação single-tenant. Controles de SOC 2 Type II sobre segregação de dados de clientes, certos regimes bancários e de corretagem, e revisões internas de risco em grandes instituições financeiras frequentemente convergem para a mesma exigência: nenhuma carga de trabalho de outro cliente deve rodar no mesmo host.

A infraestrutura compartilhada roda muitos clientes nos mesmos hosts por design. A infraestrutura dedicada não.

Faixas de consulta sem limite

Provedores de RPC compartilhados limitam faixas de eth_getLogs para proteger o cluster de query bombs. Isso é adequado para carteiras que leem as transações recentes de um usuário, e é por isso que a maioria das cargas de trabalho de análise é roteada para uma Data API indexada em vez de eth_getLogs bruto.

Para exploradores, indexadores e times de análise de chain que precisam varrer grandes faixas históricas de logs brutos, o limite se torna o gargalo. Clusters dedicados podem removê-lo porque o limite existe para proteger outros tenants, e em um cluster single-tenant não há outros tenants a proteger.

Uma referência rápida para a decisão:

Se uma carga de trabalho não se encaixa em um dos quatro padrões dedicated, a infraestrutura compartilhada é quase sempre mais barata, mais simples e mais rápida de colocar em produção.

Como funcionam os clusters dedicados?

A arquitetura de um cluster dedicado se resume a seis escolhas: quem mais roda na máquina, onde as máquinas ficam, quantas delas existem, como concordam sobre o estado, qual software rodam e como é feita a cobrança.

Isolamento single-tenant

Single-tenant significa que os nós do cliente rodam em computação reservada para a carga de trabalho desse cliente. Na prática, revisões de compliance frequentemente exigem documentação de isolamento de carga de trabalho, controles de acesso, auditabilidade e manuseio de chaves.

A implicação prática é o que o isolamento descarta. Um vizinho barulhento em um host compartilhado não pode degradar a cauda de latência do cliente, porque não há vizinho. Um vazamento de side-channel de outro tenant não pode alcançar o processo do cliente. Um revisor de compliance pode apontar para um controle documentado em vez de "confiamos que o provedor mantém as cargas de trabalho separadas".

Implantação regional

A latência de um cliente até um nó de RPC é limitada pela distância de rede. Para a maior parte do tráfego de aplicações, isso é invisível. Para cargas de trabalho que emitem requisições frequentes e sensíveis à latência, posicionar nós mais perto da stack, dos usuários, do sequencer ou dos validadores pode ser a diferença entre um produto competitivo e um lento.

Atendemos clientes em 197 países, e os Dedicated Clusters permitem posicionar pools de nós na região que sua carga de trabalho precisa, seja um cluster por geografia principal de usuários ou um colocado junto ao sequencer de um rollup específico. A contrapartida é operacional: mais regiões significam mais clusters para monitorar, atualizar e pagar. A maioria das cargas de trabalho precisa de uma ou duas.

Redundância N+1 e failover

Um cluster dedicado roda a capacidade-alvo do cliente mais um nó sobressalente. Se algum nó se degrada ou reinicia, o tráfego migra para o sobressalente sem que o cliente perceba. Esse é o padrão N+1, o formato padrão para qualquer serviço que precisa sobreviver à falha de um único nó sem perder disponibilidade.

A pergunta mais difícil é o que acontece quando a carga excede o cluster. Dois casos reais disparam isso: congestionamento da chain, onde o volume de requisições do cluster dispara porque a chain está ocupada, e picos de tráfego do cliente causados por uma campanha, um evento ou uma integração entrando no ar. Um cluster dimensionado para carga em estado estável pode sofrer rate limit sob um pico grande.

Existem duas respostas arquiteturais. Uma é dimensionar o cluster para o pico, o que significa pagar por capacidade ociosa na maior parte do tempo. A outra é o failover automático para infraestrutura compartilhada: quando o cluster satura, o tráfego transborda para a frota compartilhada do provedor em vez de retornar 429s. O cliente mantém a mesma API, a mesma autenticação e o mesmo formato de resposta. Failover é o padrão mais eficiente, mas exige que o provedor dedicado também opere uma infraestrutura compartilhada de primeira linha.

Consistência block-perfect

Nós diferentes em um pool balanceado por carga podem discordar sobre o bloco mais recente por algumas centenas de milissegundos. O nó mais rápido vê o bloco N, o mais lento ainda está no N-1. Para uma carteira verificando um saldo, isso é invisível. Para um bot de trading que lê o mesmo bloco duas vezes através de nós diferentes e obtém estado inconsistente, é um bug real.

Consistência block-perfect significa que o cluster retorna uma visão consistente do estado da chain em todo o pool de nós, para que clientes com estado não vejam leituras desatualizadas ou conflitantes. A contrapartida é que o cluster otimiza tanto para correção quanto para velocidade, o que importa mais quando a carga de trabalho toma decisões a partir de estado fresco da chain.

Tracers e binários customizados

Com um runtime dedicado, o cliente pode rodar um tracer JavaScript customizado, publicar um build geth com patch, trocar o client, ou modificar configurações de client que provedores compartilhados fixam globalmente. Provedores compartilhados não podem expor essa superfície porque mudar a versão ou a configuração do client afeta todos os tenants do host.

É nessa capacidade que produtos de simulação, forense e análise são construídos. O valor deles vem de extrair estado de execução que a interface padrão de tracer não expõe. Sem um runtime dedicado, o produto não existe.

Precificação baseada em capacidade

A infraestrutura compartilhada cobra por requisição, tipicamente como uma unidade de computação por chamada, com multiplicadores para métodos mais pesados. A infraestrutura dedicada cobra por cluster: uma taxa mensal fixa pela capacidade comprometida, independentemente de quantas requisições o cliente enviar contra ela.

O modelo se ajusta a cargas de trabalho com carga de pico previsível que, de outra forma, consumiriam unidades de computação compartilhadas em escala. Em um cluster dedicado, o custo marginal de uma requisição adicional é zero até a carga de trabalho atingir o teto do cluster. Acima de um limiar específico da carga de trabalho, a precificação baseada em capacidade pode ser mais barata do que a cobrança por requisição, mesmo antes de considerar as outras capacidades que o dedicated libera.

Quando shared é o padrão certo?

Três coisas importam ao decidir entre infraestrutura shared e dedicated. Para uma análise mais profunda das compensações, veja nossa visão geral sobre como escolher entre Node RPC e Dedicated Clusters.

Dedicated não torna a stack de RPC inerentemente mais rápida

A stack de RPC por baixo é a mesma, então um benchmark de requisição única em um sistema tranquilo não conta a história toda. Dedicated melhora a latência quando o cluster é posicionado mais perto da carga de trabalho, e melhora a previsibilidade quando o isolamento protege o P99, os 1% mais lentos das requisições, sob carga sustentada.

Para uma visão pública e atual da performance de RPC compartilhado entre provedores, veja os benchmarks de provedores de RPC da Alchemy.

Shared multi-região pode sobreviver mais do que dedicated de região única

Uma queda regional de nuvem que derruba um cluster de região única quase não é percebida em uma frota compartilhada distribuída globalmente. A implantação pragmática combina dedicated em regiões-chave com shared como padrão global.

O teste dos quatro padrões é rigoroso

Se a carga de trabalho não bater em um dos quatro pontos, runtime customizado, exigência de região, isolamento regulatório ou limite de faixa de consulta, shared é mais barato, mais simples e geralmente mais confiável. A migração para dedicated costuma ser imposta pela necessidade, não uma preferência.

Como a Alchemy oferece suporte a infraestrutura de blockchain dedicada?

A maioria das cargas de trabalho começa e permanece em shared. Nossa RPC API e Data API rodam na mesma plataforma Cortex que sustenta dedicated, com um tier gratuito, sem contrato e sem compromisso mínimo. Obtenha uma chave de API no dashboard e comece a enviar requisições em poucos minutos.

Quando uma carga de trabalho se encaixa em um dos quatro padrões, tracer customizado, exigência de região, isolamento regulatório ou limite de faixa de consulta, Alchemy Dedicated Clusters fornece capacidade single-tenant na mesma infraestrutura. Damos suporte a tracers e binários customizados, implantações regionais, redundância N+1 com failover automático para shared, consistência block-perfect, dashboards Grafana desde o primeiro dia, e infraestrutura compatível com SOC 2 Type II para ambientes regulados. A precificação é baseada em capacidade provisionada, não em uso por requisição, então times com carga previsível podem planejar em torno de uma infraestrutura mensal fixa.

Clusters dedicados são a mesma infraestrutura, restrita à sua carga de trabalho. Se shared funciona, fique em shared. Se sua carga de trabalho é uma das poucas que não consegue, fale com nosso time.

Perguntas frequentes

Qual é a diferença entre infraestrutura de blockchain dedicada e RPC compartilhado?

RPC compartilhado roda muitos clientes em uma frota gerenciada. Infraestrutura de blockchain dedicada reserva o runtime, a capacidade e o caminho de dados para uma única carga de trabalho. A superfície de API pode continuar a mesma, mas dedicated adiciona isolamento single-tenant, opções de runtime customizado, posicionamento regional e precificação baseada em capacidade.

Dá para rodar tracers customizados em nós de Ethereum dedicados?

Sim. Como um cluster dedicado é single-tenant, você pode rodar tracers customizados que endpoints compartilhados não conseguem hospedar. Além dos tracers padrão callTracer e prestateTracer, um runtime dedicado permite implantar seu próprio tracer JavaScript ou um binário geth ou erigon modificado que expõe estado de execução que a interface padrão não expõe. É por isso que times de segurança, simulação e forense rodam dedicated. Seus produtos dependem de tracing que a infraestrutura compartilhada fixa globalmente.

Infraestrutura dedicada é o mesmo que um endpoint de RPC privado?

Nem sempre. Um endpoint de RPC privado pode significar uma URL ou política de acesso específica do cliente sobre infraestrutura compartilhada. Infraestrutura dedicada vai além: o pool de nós e o runtime de suporte são reservados para a carga de trabalho de um único cliente.

Quando um time deve evitar infraestrutura dedicada?

Evite infraestrutura dedicada quando a carga de trabalho não exige binários customizados, isolamento regulatório, posicionamento específico de região, ou faixas de consulta brutas incomumente grandes. Nesses casos, RPC compartilhado costuma ser mais simples, mais barato, mais elástico e mais rápido de colocar em produção.

Infraestrutura dedicada e compartilhada podem rodar juntas?

Sim. A maioria dos times que usa Dedicated Clusters roda uma configuração híbrida: dedicated para as chains ou cargas de trabalho com exigências rígidas, e RPC compartilhado para todo o resto. As APIs são iguais, então mover uma carga de trabalho entre os dois é basicamente uma decisão de endpoint e roteamento.

Como funciona a precificação para clusters dedicados?

Clusters dedicados são precificados com base em capacidade provisionada, não em uso por requisição. O preço depende da chain, do tipo de nó, da vazão, da região e das capacidades incluídas. Para cargas de trabalho sustentadas e altas, a precificação de capacidade fixa pode ser mais fácil de prever do que a cobrança por requisição.

Com que rapidez um cluster dedicado pode ser provisionado?

O provisionamento depende da chain, do client, da região e da configuração. Alguns clusters podem ser implantados rapidamente quando os requisitos são padrão. Configurações mais complexas, como binários customizados, hardware especial ou novas regiões, exigem mais planejamento.