Uso do Alchemy: aumentando a transparência e a simplicidade

Contexto

Nosso modelo de preços é baseado no conceito de "compute units" - uma medida do total de recursos computacionais que suas aplicações estão usando na Alchemy. Você pode pensar nisso como a forma que você pagaria a Amazon pelo uso da AWS. Algumas queries são leves e rápidas de executar (ex. eth_blockNumber) e outras podem ser mais intensas (ex. queries grandes de eth_getLogs). Queremos te dar o menor custo possível, então, em vez de cobrar pelo número de queries, cobramos apenas pela quantidade de compute usada.

Desafios

Quando o compute é medido a cada requisição, as compute units (e, como resultado, o uso mensal) podem ser difíceis de prever. Alguns métodos têm intensidade altamente variável (ex. eth_call), então o número de compute units que consomem pode variar em até 100x. Isso faz com que coisas como otimizar o uso ou prever o custo mensal fiquem mais confusas do que deveriam.

Queremos tornar a medição e a previsão de uso na Alchemy simples e fáceis de entender para todos os nossos clientes. Por esse motivo, e para criar a plataforma mais amigável possível para desenvolvedores, decidimos atualizar a forma como medimos as compute units.

Uma atualização nas compute units

Com nosso novo modelo de compute units, cada método recebe um número fixo de compute units, derivado de sua intensidade média. Isso significa que você saberá exatamente quantas compute units uma determinada chamada vai consumir antes de fazê-la, aumentando muito a previsibilidade e a transparência.

Como exemplo de como essa atualização melhora a experiência do desenvolvedor, considere um usuário fazendo 10.000 requisições trace:

Com as compute units antigas, o usuário faria 10.000 requisições trace_call, sem saber até que elas terminassem quantas compute units foram usadas. Dependendo dos blocos, contratos e do timing das chamadas, o usuário pode acabar usando 750.000 ou 1.000.000 de compute units no total. Mesmo assim, na próxima vez que ele fizer 10.000 requisições trace_call, o resultado pode ser diferente.

Usando o novo modelo de compute units, se alguém fizesse 10.000 requisições trace_call, a 75 CU por chamada, isso consumiria um total de 10.00075 = 750.000 CUs, sempre e em todas as vezes.

Sem adivinhação e variabilidade - apenas uma medida justa e determinística de uso!

Para uma lista completa das atribuições de CU por método, determinadas a partir de anos de uso com benchmark, veja nossa documentação.

Rate limits melhores

Atualmente, usamos o conceito de queries por segundo, ou QPS, como principal limite de rate. Embora essa seja uma forma bastante típica de as APIs limitarem a taxa, é uma ferramenta relativamente pouco precisa. Isso significa que, muitas vezes, somos forçados a errar pelo lado da cautela e ser mais rígidos do que o necessário em relação aos rate limits.

Com a definição atualizada de compute units, conseguimos substituir o QPS por uma medida mais favorável: compute units por segundo, ou CUPS.

Os rate limits de CUPS são, na prática, uma versão ponderada do QPS, onde o peso de cada método é sua intensidade computacional. Esse limite acaba sendo mais preciso por considerar a variabilidade nas requisições e os tipos de métodos que estão sendo chamados. Isso nos permite oferecer um serviço geral ainda mais confiável, com limites tão generosos (ou mais, em muitos casos!) para todos os nossos clientes.

Resumo

No geral, achamos que essa mudança será uma grande melhoria para nossos clientes. Sempre levamos seu feedback a sério e nos esforçamos para tornar a experiência do desenvolvedor a melhor possível, para que todos possamos focar em criar os melhores produtos possíveis.

Não hesite em entrar em contato caso tenha dúvidas ou precise de esclarecimentos, teremos prazer em ajudar.