---
title: "Alchemy、Data APIsとTier-1バリデーションへの道筋でStellarサポートを拡大"
description: "Alchemyは、Stellarにおけるtier-1バリデーターを目指しており、mainnetとtestnetでの転送履歴、トークン残高、NFT保有状況向けに、インデックス化された3つのData APIsを追加した。"
---

# Alchemy、Data APIsとTier-1バリデーションへの道筋でStellarサポートを拡大

<ImageBlock
  src="https://media.alchemy.com/stellar.png"
  alt="AlchemyとStellarのパートナーシップ"
  width={1920}
  height={900}
  priority
/>

[Alchemyは以前からStellarのサポートを提供している](https://www.alchemy.com/docs/reference/stellar-api-quickstart)。RPC、websocketサポート、そしてサポート対象の全ネットワークで維持している99.99%のアップタイムとSOC 2 Type IIの信頼性を備える。今回、その範囲を2つの面でさらに深める。Alchemyは Stellarでのtier-1バリデーターを目指して稼働を進めており、また大規模にStellarを読み取るためのインデックス済みData APIを3種類追加した。

Stellar上でtier-1バリデーションの構築を進めている。地理的に分散した3基のフルバリデーターがコンセンサスに参加し、公開の履歴アーカイブを公開し、ネットワークが定める最高水準のアップタイムとクオラム品質を満たす。[tier-1バリデーター](https://developers.stellar.org/docs/validators/tier-1-orgs)は多くのクオラムセットに含まれ、ネットワークの耐障害性を支える存在であり、これがAlchemyが目指している水準だ。

RPCとwebsocketに加えて、mainnetとtestnetでインデックス済みかつアドレス中心の3種類のData APIを新たに提供する。転送履歴、トークン残高、NFT保有状況だ。アドレスとネットワークを指定するだけで、インデックス済みの履歴または状態が返ってくる。自前のインデクサーを運用する必要はない。統合されたインフラフルスタックを運用しているからこそ提供できるものであり、チェーン上のデータが1回のクエリに集約される仕組みだ。

## チェーンを運用することがなぜ読み取りにとって重要か

Stellarを本番規模で読み取ることは、本質的にインデックス作成の問題だ。[Soroban RPC](https://developers.stellar.org/docs/build/smart-contracts/overview)が提供するのは直近の短いウィンドウのledgerのみだ。[Horizon](https://developers.stellar.org/docs/data/apis/horizon)は履歴を提供するが、「このアカウントがこれまでに受け取った全アセット」といった単純な問いに答えるだけでも、大量のプリミティブをページングし、自前のコピーを同期させ続ける必要がある。多くのチームは、ポートフォリオ画面を支えるためだけにインデクサーを運用することになる。

tier-1バリデーションに向けた構築は、この問題に対する答えの土台を変える。tier-1の組織はフルバリデーターを運用し、公開の履歴アーカイブを公開する。これはまさに本格的なインデクサーが必要とする耐久性のある完全なledgerレコードであり、AlchemyがStellar上で構築しているインフラそのものだ。したがって、AlchemyのData APIは外部からチェーンをスクレイピングするサードパーティではない。Alchemyがエンドツーエンドで運用するインフラ上で動作し、ネットワークの残りの部分を同期させ続けているのと同じ種類の履歴レコードに基づいている。バリデーション、RPC、websocket、Data APIは、1つのAPIキーの背後にある1つのスタックであり、1つの信頼性基準に基づいている。

## Stellar Data APIの内容

インターフェースは意図的に小さく保たれている。各メソッドはアカウントアドレスとネットワークを受け取り、自前のバックフィルが必要になるはずのインデックス済みデータを返す。

- **転送履歴:** あるアドレスに関するアセット移動の記録を、ページネーション形式で取得
- **トークン残高:** あるアドレスが保有する現在のアセット残高を、1回の呼び出しで取得
- **NFT保有状況:** あるアドレスが保有するNFTを取得。クラシックなStellarアセットとStellarスマートコントラクト（Soroban）トークンの両方をカバー

あるアドレスが何を保有しているか、あるいは何をしてきたかを尋ねると、インデックス済みの履歴から答えが組み立てられる。正確なリクエスト・レスポンスのフィールドは[Stellar API quickstart](https://www.alchemy.com/docs/reference/stellar-api-quickstart)を参照。基本形はアドレスを入力し、インデックス済みの履歴を得るというものだ。

## Stellarに独自のパイプラインが必要な理由

汎用的なEVMインデクサーはStellarには適合しない。ledgerにはoperation、payment、trustline、クラシックアセットという独自の構造がある。それに加えて、Sorobanはまったく別のモデルを持つスマートコントラクトトークンを追加する。Stellar上のNFTはクラシックアセットの場合もSorobanコントラクトトークンの場合もあり、正しい保有状況の答えはその両方を考慮する必要がある。

そのため、Data APIはこのモデルに特化して構築されたパイプライン上に構築されており、4つの段階から成る。

## パイプラインの仕組み

まず、Stellarネットワークの公式ledgerエクスポートツールである[Galexie](https://developers.stellar.org/docs/data/indexers/build-your-own/galexie)から始まる。Galexieはledgerのメタデータをオブジェクトストレージに順序付けられたパーティションとして書き込む。これにより、ノードに負荷をかけることなく、耐久性がありリプレイ可能なチェーンの信頼できる情報源が得られる。チェーンは一度だけエクスポートされ、以降のすべての処理はそのパーティションから読み取る。

次に、Stellar専用のインジェスターがそれらのパーティションを走査し、正規化された行を書き込む。これがStellar対応である理由は2つある。1つは、別々のbackfillとfrontfillのパスではなく1つの統合モデルを実行する点だ。これにより過去の履歴への追いつきと最新状態への追従が同じコードとなり、パーティションごとに最も新しく取り込まれたledgerでチェックポイントされる。もう1つは、別個のワークロードとして実行される点だ。1つは転送と残高を分類し、別のNFT分類器が同じパーティションを走査してクラシックアセットとSorobanアセットの両方にわたる保有状況を解決する。ワーカーは並列実行され、ネットワークごとにスケールするため、mainnetとtestnetは独立してサイズ調整される。

正規化されたデータは、Stellar専用の[ClickHouse](https://clickhouse.com/)クラスターに格納される。ClickHouseは分析的な読み取り用に構築されたカラム指向データベースであり、これはこれらのクエリ（アドレスでフィルタし、スキャンし、集計する）にまさに適している。Stellarに専用のクラスターを与えることでそのクエリ負荷を分離し、ネットワーク間のレイテンシーを削減する。

Data APIサービスはClickHouseから読み取り、他のすべてのAlchemyチェーンと同じゲートウェイ、認証、レート制限、compute-unit課金を通じて公開される。Stellarは独自のログインや独自の癖を持つサイドシステムではない。同じAPIキーの背後にあるもう1つのネットワークに過ぎない。

## リクエストの形

3つのメソッドはすべて1つの形を共有している。入力はアドレスとネットワークだ。出力はインデックス済みでページネーション化された履歴または状態で、開発者が期待するアセットモデル（クラシックとSorobanが統合された形）にすでに解決済みだ。呼び出し側が「これは最近のものか、それとも過去のものか」を判断する必要はない。統合されたインジェスションモデルにより、インデックスは概して最新かつ完全な状態にあるからだ。

この均一性こそが重要な点だ。転送を統合したチームは、新しいリクエストパターンを学ぶことなく残高やNFT保有状況を追加できる。1つのメソッドで機能するアドレスは、3つすべてのメソッドで機能する。

## AlchemyがStellarに対して現在提供しているもの

Stellarは他のすべてのチェーンと同じAPIキーとツールの背後で、ファーストクラスのネットワークとして稼働している。

- tier-1に向けたバリデーターインフラ。地理的に分散したフルバリデーターと公開の履歴アーカイブを含む
- 99.99%のアップタイムとグローバルな冗長性を備えたRPCおよびwebsocketサポート
- mainnetとtestnetで、転送履歴、トークン残高、NFT保有状況に対応する3種類のインデックス済みData API
- 1兆ドル超のオンチェーントランザクションを処理する、SOC 2 Type II認証済みのインフラ

## はじめに

- [dashboard](https://dashboard.alchemy.com/)でキーを作成し、Stellar mainnetまたはtestnetを呼び出す
- 転送、残高、NFTの各メソッドリファレンスは[Stellar API quickstart](https://www.alchemy.com/docs/reference/stellar-api-quickstart)を参照
- ボリュームまたはエンタープライズ向けのニーズについては、[お問い合わせください](https://www.alchemy.com/contact-sales)

## よくある質問

### Alchemyは独自のStellarインフラを運用していますか？

はい。Alchemyは、コンセンサスに参加し、公開の履歴アーカイブを公開する地理的に分散したフルバリデーターを運用しながら、Stellar上でtier-1バリデーションの構築を進めている。RPC、websocket、Data APIは同じインフラ上で動作するため、ネットワークの運用に関わるプロバイダーからStellarを読み取ることになり、サードパーティのインデクサーを経由するわけではない。

### どのネットワークがサポートされていますか？

StellarのmainnetとtestnetのRootが両方サポートされている。ワーカーはネットワークごとにスケールするため、両者は独立してサイズ調整され、一方の負荷急増がもう一方に影響することはない。

### 自前のインデクサーを運用する必要はまだありますか？

いいえ。APIは完全にインデックス済みの転送履歴、残高、保有状況を返すため、ポートフォリオや履歴ビューを支えるためにGalexieを運用したり、backfillを維持したり、自前のledgerコピーを同期させ続けたりする必要はない。

### Sorobanトークンはどのように扱われますか？

専用の分類器が、クラシックなStellarアセットとSorobanスマートコントラクトトークンの両方にわたる保有状況を解決するため、1回の保有状況クエリで、両方のモデルを自分で突き合わせることなく反映される。

### Soroban RPCやHorizonとの違いは何ですか？

Soroban RPCは直近の短いウィンドウのledgerしか公開しておらず、Horizonは組み立てる必要のある生のプリミティブとして履歴を返す。Data APIは、履歴全体にわたるインデックス済みでアドレス中心の答えを1回の呼び出しで返す。
