Solana RPC Endpoint mit ERPC - Dokumentation

Solana RPC Endpoint

Ein Solana RPC Endpoint verbindet Ihre Anwendung mit Solana, damit sie Kontodaten abfragen, Transaktionen senden und per WebSocket Updates abonnieren kann. Mit ERPC nutzen Sie einen globalen Solana Endpoint über edge.erpc.global. Fügen Sie Ihren API key als Parameter api-key hinzu.
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>

Beispiele:

Hier ist ein Beispiel für eine HTTP-Anfrage.
bash
curl https://edge.erpc.global?api-key=<YOUR_API_KEY> --header 'Content-Type: application/json' --data '{
  "jsonrpc":"2.0","id":1,
  "method":"getBlockHeight"
}'
Hier ist ein Beispiel für ein WebSocket-Abonnement. Der Host ist derselbe wie bei HTTP.
endpoint
wss://edge.erpc.global?api-key=<YOUR_API_KEY>
bash
# Example: subscribe to slot updates
wscat -c "wss://edge.erpc.global?api-key=<YOUR_API_KEY>"
# After connected, send:
{"jsonrpc":"2.0","id":1,"method":"slotSubscribe"}
Sie können Ihren API key im ERPC Dashboard abrufen und prüfen: ERPC Dashboard
Wenn Sie eine geringere Latenz als mit WebSocket benötigen, prüfen Sie Geyser gRPC oder ShredStream. Details können Sie über das ERPC Dashboard mit uns besprechen.

History Access

Hängen Sie history=true an die URL edge.erpc.global einer HTTP-Anfrage an, um ältere Blöcke und Transaktionen abzurufen; der Wert muss genau true lauten, in Kleinbuchstaben. Mit Ausnahme von getTransactionsForAddress wird eine Anfrage ohne history=true aus dem aktuellen Bereich beantwortet, den jeder Knoten vorhält; die Option gilt für diese Methoden:
  • getBlock
  • getBlockTime
  • getBlocks
  • getBlocksWithLimit
  • getTransaction, einschließlich getParsedTransaction
  • getSignaturesForAddress
  • getSignatureStatuses, wenn searchTransactionHistory den Wert true hat
  • getTransactionsForAddress, wenn transactionDetails den Wert "full" hat (History Access erforderlich)
Geben Sie den API key und die Option als Query-Parameter in der URL an:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true
Oder senden Sie Authorization: Bearer <YOUR_API_KEY> als Header, mit der Option in der URL:
endpoint
https://edge.erpc.global?history=true
Hier ist ein Beispiel für eine HTTP-Anfrage mit History Access.
bash
curl 'https://edge.erpc.global?history=true' \
  --header 'Authorization: Bearer <YOUR_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
  "jsonrpc":"2.0","id":1,
  "method":"getBlock",
  "params":[<SLOT>,{"maxSupportedTransactionVersion":1}]
}'
Für jede Methode außer getTransactionsForAddress im Modus "full":
  • Jeder von History Access beantwortete Aufruf kostet 640 Token mehr als sein regulärer Preis: getBlock kostet 42 + 640 = 682.
  • Auch bei einem Ergebnis von History Access, das null, leer oder nur teilweise ist, fällt der Aufpreis an. Bei einem fehlgeschlagenen Abruf fällt kein Aufpreis an.
  • Ein aus aktuellen Daten beantworteter Aufruf behält seinen regulären Preis, auch mit history=true.
  • Ein Batch zählt jeden Aufruf einzeln; getSignatureStatuses zählt einmal pro Aufruf, nicht pro Signatur.
  • Lassen Sie history=true beim Polling nach aktuellen Transaktionen weg: Für jedes null dort fällt der Aufpreis an.
Kostenlose Kontingente, einschließlich des Kontingents des Free-Plans, haben ein Limit für History Access. Der Free-Plan ist auf eine Anfrage mit History Access pro 10 Sekunden begrenzt.
Ein Aufruf von getTransactionsForAddress mit auf "full" gesetztem transactionDetails ist History Access, unabhängig davon, ob die Transaktionen aktuell oder alt sind:
  • Der Aufruf erfordert history=true in der URL edge.erpc.global. Eine Anfrage ohne diese Option wird mit dem Fehler zu History Access (Code -32011) abgelehnt, und es fallen keine Kosten an.
  • Mit history=true kostet der Aufruf 420 + 640 × N Token: seinen regulären Preis von 420 plus 640 für jede der N abgerufenen Transaktionen, ob aktuell oder alt. Eine Zeile ohne Transaktion wird nicht gezählt.
  • Der Aufruf muss als eigene Anfrage gesendet werden. Ein Batch, der ihn enthält, wird abgelehnt, mit oder ohne history=true: Jeder Aufruf im Batch wird mit dem Fehler -32600 und der Meldung This request is not available in a mixed JSON-RPC batch. Please send it as a separate request. beantwortet, und keiner davon wird gesendet.
Der Standardmodus signatures benötigt kein history=true, und es fällt kein Aufpreis an. Um eine Adresse auf neue Transaktionen zu pollen, verwenden Sie den Modus signatures und rufen Sie die benötigten Transaktionen mit getTransaction ab.
Der Abruf älterer Blöcke oder Transaktionen kann deutlich länger dauern als eine reguläre Anfrage, in manchen Fällen mehrere Sekunden. History Access ist eine separate Option, die diese Abrufe von regulären Anfragen trennt, damit reguläre Anfragen schnell bleiben.
Ohne history=true kann eine Anfrage an getBlock oder getBlockTime für einen älteren Slot diesen Fehler zurückgeben:
json
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32011,
    "message": "This request needs history access. Add history=true to the endpoint URL.",
    "data": {
      "erpcCode": "ERPC_HISTORY_OPTION_REQUIRED"
    }
  },
  "id": 1
}
getTransaction, getParsedTransaction und getSignatureStatuses (mit searchTransactionHistory: true) geben für eine Signatur, die älter ist als das, was der Knoten vorhält, null zurück, während getSignaturesForAddress, getBlocks und getBlocksWithLimit ein leeres oder teilweises Ergebnis zurückgeben.
Eine Anfrage mit history=true kann diese Meldungen zurückgeben:
  • This plan has reached its limit for history access. Add a paid plan to use tokens for history access. — wird angezeigt, wenn ein Kontingent, etwa das des Free-Plans, sein Limit erreicht.
  • History access is unavailable while your token balance is low. Add tokens. — wird bei einem kostenpflichtigen Plan angezeigt, wenn das Token-Guthaben niedrig ist.
  • On the Free plan, history access is limited to one request per 10 seconds. Slow down or use a paid plan. — wird beim Free-Plan angezeigt, wenn Anfragen mit History Access zu schnell eintreffen.

Unterstützte Methoden für Unlimited Endpoint

Unlimited Endpoints sind dedizierte HTTP-Endpunkte, die für latenzarme Standardaufrufe der Solana RPC optimiert sind. Dies sind die unterstützten Standardmethoden der Solana RPC:
  • getSlot
  • getBlockHeight
  • getLatestBlockhash
  • getBalance
  • getAccountInfo
  • getMultipleAccounts
  • getTransaction
  • sendTransaction
  • simulateTransaction
  • getSignatureStatuses
  • getRecentPrioritizationFees
  • getHealth
  • getVersion
  • getEpochInfo
  • getBlock
Für Methoden außerhalb dieser unterstützten Auswahl verwenden Sie https://edge.erpc.global?api-key=<YOUR_API_KEY>.

Solana RPC Methoden und Dokumentation

Die vollständige Liste der Methoden, Parameter und Abonnement-Spezifikationen finden Sie in der offiziellen Dokumentation. Sie deckt sowohl HTTP als auch WebSocket ab.