Alchemy expande o suporte ao Stellar com Data APIs e um caminho para validação Tier-1

Desde que a Alchemy lançou suporte a Stellar, com RPC, suporte a websocket e o mesmo uptime de 99,99% e a confiabilidade SOC 2 Type II que mantemos em todas as redes suportadas. Hoje essa presença se aprofunda de duas formas: a Alchemy está trabalhando para se tornar um validador tier-1 na Stellar, e adicionamos três Data APIs indexadas para ler dados da Stellar em escala.

Estamos implantando validação tier-1 na Stellar: um trio de validadores completos geograficamente distribuídos que participam do consenso, publicam arquivos públicos de histórico e atendem ao padrão mais alto da rede em termos de uptime e qualidade de quorum. Validadores tier-1 são incluídos em muitos conjuntos de quorum e ajudam a sustentar a resiliência da rede, e é esse o padrão que estamos buscando.

Além de RPC e websockets, agora oferecemos três Data APIs indexadas e centradas em endereço na mainnet e na testnet: histórico de transferências, saldos de tokens e posses de NFTs. Você envia um endereço e uma rede, e recebe de volta histórico ou estado indexado, sem precisar rodar seu próprio indexador. É isso que operar uma pilha de infraestrutura integrada de ponta a ponta nos permite entregar a um desenvolvedor, e é assim que esses dados saem da chain e chegam a uma única query.

Por que operar a chain importa para lê-la

Ler dados da Stellar em escala de produção é um problema de indexação. O Soroban RPC serve apenas uma janela curta de ledgers recentes. O Horizon fornece histórico, mas responder a uma pergunta tão simples quanto "todos os ativos que essa conta já recebeu" ainda significa paginar por uma grande quantidade de primitivas e manter sua própria cópia sincronizada. A maioria das equipes acaba rodando um indexador só para sustentar uma tela de portfólio.

Construir em direção à validação tier-1 muda a base sobre a qual nossa resposta a esse problema se apoia. Organizações tier-1 rodam validadores completos e publicam arquivos públicos de histórico, que é o mesmo registro de ledger durável e completo de que qualquer indexador sério precisa, e é a infraestrutura que estamos construindo na Stellar. Então nossas Data APIs não são um terceiro fazendo scraping da chain de fora. Elas rodam em infraestrutura que operamos de ponta a ponta, sobre o mesmo tipo de registro histórico que mantém o resto da rede sincronizado. Validação, RPC, websockets e as Data APIs são uma única pilha por trás de uma única API key, sujeita a um único padrão de confiabilidade.

O que as Stellar Data APIs fazem

A superfície é deliberadamente pequena. Cada método recebe um endereço de conta e uma rede, e retorna dados indexados que de outra forma exigiriam seu próprio backfill:

• Histórico de transferências: o registro de movimentações de ativos de um endereço, em formato paginado
• Saldos de tokens: saldos de ativos atualmente detidos por um endereço, em uma única chamada
• Posses de NFTs: NFTs detidos por um endereço, cobrindo tanto ativos clássicos da Stellar quanto tokens de smart contract Stellar (Soroban).

Você pergunta o que um endereço possui ou o que ele fez, e a resposta é montada a partir de histórico indexado. Os campos exatos de request e response estão no Stellar API quickstart. A ideia a ter em mente é: endereço entra, histórico indexado sai.

Por que a Stellar precisa de um pipeline personalizado

Um indexador genérico de EVM não se encaixa na Stellar. O ledger tem sua própria estrutura de operations, payments, trustlines e ativos clássicos. Além disso, o Soroban adiciona tokens de smart contract com um modelo ainda diferente. Um NFT na Stellar pode ser um ativo clássico ou um token de contrato Soroban, e uma resposta correta sobre posses precisa considerar os dois.

Por isso as Data APIs se apoiam em um pipeline construído especificamente para esse modelo, em quatro etapas.

Como o pipeline funciona

Começa com o Galexie, a ferramenta oficial de exportação de ledger da rede Stellar. O Galexie grava metadados de ledger em object storage como partições ordenadas, o que nos dá uma fonte de verdade durável e reproduzível para a chain sem sobrecarregar um node. A chain é exportada uma vez, e tudo a jusante lê a partir dessas partições.

Um ingestor específico para Stellar então percorre essas partições e grava linhas normalizadas. Duas coisas fazem dele algo "ciente" da Stellar. Ele roda um único modelo unificado em vez de caminhos separados de backfill e frontfill, então a recuperação histórica e o acompanhamento da ponta são o mesmo código, com checkpoint por partição baseado no ledger de maior índice já ingerido. E ele roda como workloads distintos: um classifica transferências e saldos, enquanto um classificador separado de NFTs percorre as mesmas partições para resolver posses entre ativos clássicos e Soroban. Os workers rodam em paralelo e escalam por rede, então mainnet e testnet têm dimensionamento independente.

Esses dados normalizados chegam a um cluster ClickHouse dedicado à Stellar. ClickHouse é um banco de dados colunar construído para leituras analíticas, que é exatamente o que essas queries são: filtrar por endereço, escanear, agregar. Dar à Stellar seu próprio cluster isola sua carga de queries, reduzindo assim a latência entre redes.

O serviço de Data API lê do ClickHouse e é exposto através do mesmo gateway, autenticação, rate limiting e contabilidade de compute units que qualquer outra chain na Alchemy. A Stellar não é um sistema paralelo com seu próprio login e suas próprias particularidades. É mais uma rede por trás da mesma API key.

Como é um request

Os três métodos compartilham uma única estrutura. A entrada é um endereço mais uma rede. A saída é histórico ou estado indexado e paginado, já resolvido no modelo de ativos que um desenvolvedor espera, clássico e Soroban juntos. Não há uma decisão separada de "isso é recente ou histórico" para quem chama, porque o modelo unificado de ingestão faz com que o índice seja, em geral, ao mesmo tempo atual e completo.

Essa uniformidade é o ponto central. Uma equipe que integra transferências pode adicionar saldos e posses de NFTs sem aprender um novo padrão de request, e o mesmo endereço que funciona para um método funciona para os três.

O que a Alchemy oferece para Stellar hoje

A Stellar roda como uma rede de primeira classe na Alchemy, por trás da mesma API key e das mesmas ferramentas que qualquer outra chain:

• Infraestrutura de validador a caminho do tier-1, com validadores completos geograficamente distribuídos e arquivos públicos de histórico
• Suporte a RPC e websocket com uptime de 99,99% e redundância global
• Três Data APIs indexadas para histórico de transferências, saldos de tokens e posses de NFTs na mainnet e na testnet
• Infraestrutura certificada SOC 2 Type II que processa mais de US$1T em transações onchain

Comece agora

• Crie uma key e chame a Stellar mainnet ou testnet a partir do dashboard
• Encontre as referências dos métodos de transfers, balances e NFT no Stellar API quickstart
• Para necessidades de volume ou enterprise, fale conosco

Perguntas frequentes

A Alchemy opera sua própria infraestrutura Stellar?

Sim. A Alchemy está implantando validação tier-1 na Stellar, rodando validadores completos geograficamente distribuídos que participam do consenso e publicam arquivos públicos de histórico. RPC, websockets e as Data APIs rodam sobre essa mesma infraestrutura, então você está lendo dados da Stellar a partir de um provedor que ajuda a operar a rede, não de um indexador terceirizado.

Quais redes são suportadas?

Tanto a mainnet quanto a testnet da Stellar. Os workers escalam por rede, então as duas têm dimensionamento independente, e um pico de carga em uma não afeta a outra.

Ainda preciso rodar meu próprio indexador?

Não. As APIs retornam histórico de transferências, saldos e posses totalmente indexados, então você não precisa rodar o Galexie, manter um backfill ou manter sua própria cópia do ledger sincronizada para sustentar uma visão de portfólio ou histórico.

Como os tokens Soroban são tratados?

Um classificador dedicado resolve posses tanto para ativos clássicos da Stellar quanto para tokens de smart contract Soroban, então uma única consulta de posses reflete os dois modelos sem que você precise reconciliá-los por conta própria.

Qual a diferença em relação ao Soroban RPC ou ao Horizon?

O Soroban RPC expõe apenas uma janela curta de ledgers recentes, e o Horizon retorna histórico como primitivas brutas que você precisa montar. As Data APIs retornam respostas indexadas e centradas em endereço, cobrindo todo o histórico em uma única chamada.