Produktionsbereitschaft

Lokales Entwickeln und Testen im Devnet sind großartige Möglichkeiten, um mit Solana-Zahlungen zu beginnen. Wenn Sie jedoch bereit sind, im Mainnet zu deployen, müssen Sie sich der Besonderheiten des Mainnets bewusst sein. Das Devnet verzeiht Fehler. Das Mainnet nicht. Dieser Leitfaden behandelt die wichtigen Unterschiede, um sicherzustellen, dass Ihre Nutzer eine reibungslose Erfahrung haben.

RPC-Infrastruktur

Öffentliche Endpoints (api.mainnet-beta.solana.com) sind ratenlimitiert ohne SLA. Sie sind für die Entwicklung geeignet, werden aber Produktions-Zahlungsabläufe zum Scheitern bringen – als würden Sie versuchen, einen Zahlungsabwickler über eine gemeinsam genutzte API ohne Verfügbarkeitsgarantie zu betreiben.

Bei der Auswahl eines RPC-Providers sollten Sie auf Folgendes achten:

• Zuverlässigkeit: SLAs mit Verfügbarkeitsgarantien (99,9 %+)
• Latenz: geografische Nähe zu Ihren Nutzern
• Features: Transaction-Landing-Features, Indexierung, Priority-Fee-APIs

Eine vollständige Liste der RPC-Provider finden Sie im Leitfaden RPC Infrastructure Providers.

Redundante RPC-Konfiguration

Wie jeder Netzwerkdienstanbieter können auch RPC-Provider Ausfallzeiten oder Phasen mit eingeschränkter Leistung erleben. Um sicherzustellen, dass Ihre Anwendung resilient ist, sollten Sie Ihre Anwendung so konfigurieren, dass sie mehrere RPC-Provider verwendet.

Solana Kit bietet eine Bibliothek zur Anpassung von RPC-Transporten, mit der Sie Ihren eigenen redundanten RPC-Client erstellen können. Hier ist ein Beispiel, wie Sie ihn zum Aufbau eines redundanten RPC-Clients verwenden könnten:

import { RpcTransport } from "@solana/rpc-spec";
import { RpcResponse } from "@solana/rpc-spec-types";
import { createHttpTransport } from "@solana/rpc-transport-http";

// Create a transport for each RPC server
const transports = [
  createHttpTransport({ url: "https://mainnet-beta.my-server-1.com" }),
  createHttpTransport({ url: "https://mainnet-beta.my-server-2.com" }),
  createHttpTransport({ url: "https://mainnet-beta.my-server-3.com" })
];

// Create a wrapper transport that distributes requests to them
let nextTransport = 0;
async function roundRobinTransport<TResponse>(
  ...args: Parameters<RpcTransport>
): Promise<RpcResponse<TResponse>> {
  const transport = transports[nextTransport];
  nextTransport = (nextTransport + 1) % transports.length;
  return await transport(...args);
}

Wenn Sie es vorziehen, keine eigenen Routing-Tools zu erstellen, können Sie einen Drittanbieterdienst wie Iron Forge nutzen, um das Routing für Sie zu übernehmen.

Transaktionslandung

Im Devnet landen Transaktionen relativ einfach. Im Mainnet konkurrieren Sie um Blockspeicherplatz. Um die Chancen zu erhöhen, dass Ihre Transaktion in einen Block aufgenommen wird, sollten Sie sicherstellen, dass Sie Ihre Transaktion korrekt zusammengestellt haben. Das bedeutet:

• Einfügen eines aktuellen Blockhashes vor dem Senden der Transaktion
• Einfügen einer Priority-Fee-Anweisung in die Transaktion mit einer wettbewerbsfähigen Priority Fee
• Einfügen einer Compute-Unit-Limit-Anweisung in die Transaktion mit einem Compute-Unit-Limit basierend auf den geschätzten Compute Units, die für die Transaktion erforderlich sind

Zusätzlich sollten Sie andere Tools wie Jito Bundles in Betracht ziehen, um die Chancen zu erhöhen, dass Ihre Transaktion in einen Block aufgenommen wird. Lassen Sie uns diese Tools genauer betrachten.

Konfiguration des Transaktionsversands

Beim Senden von Transaktionen im Mainnet konfigurieren Sie diese Parameter für optimale Landeraten:

Blockhash-Verwaltung:

• Abrufen mit confirmed-Commitment
• Speichern Sie den lastValidBlockHeight, der von getLatestBlockhash zurückgegeben wird – dieser zeigt Ihnen, wann Ihre Transaktion abläuft
• Blockhashes laufen nach ~150 Blöcken (~60-90 Sekunden) ab

Sendeoptionen:

• maxRetries: 0 — Deaktiviert automatische RPC-Wiederholungen. Verwalten Sie Wiederholungen selbst, damit Sie den Blockhash bei Bedarf aktualisieren können.
• skipPreflight: true — Umgeht die Simulation vor dem Senden. Verwenden Sie dies, wenn Sie die Transaktion bereits validiert haben und die niedrigste Latenz wünschen. Behalten Sie es während der Entwicklung auf false, um Fehler frühzeitig zu erkennen.

import { createSolanaRpc } from "@solana/kit";

const rpc = createSolanaRpc(process.env.RPC_URL!);

// 1. Get blockhash with confirmed commitment
const { value: latestBlockhash } = await rpc
  .getLatestBlockhash({ commitment: "confirmed" })
  .send();

// 2. Build and sign your transaction with the blockhash
// ... (transaction building code)

// 3. Send with production settings
const signature = await rpc
  .sendTransaction(encodedTransaction, {
    encoding: "base64",
    maxRetries: 0n, // Handle retries yourself
    skipPreflight: true, // Skip simulation for speed (use false during dev)
    preflightCommitment: "confirmed"
  })
  .send();

// 4. Track expiration using lastValidBlockHeight
const { lastValidBlockHeight } = latestBlockhash;
// Stop retrying when current block height exceeds lastValidBlockHeight

Priority fees verwenden

Jede Solana-Transaktion erfordert eine Transaktionsgebühr, die in SOL bezahlt wird. Transaktionsgebühren werden in zwei Teile aufgeteilt: die Basisgebühr und die Priority fee. Die Basisgebühr entschädigt Validatoren für die Verarbeitung der Transaktion. Die Priority fee ist eine optionale Gebühr, um die Chance zu erhöhen, dass der aktuelle Leader Ihre Transaktion verarbeitet. Stellen Sie es sich wie einen Expressversand vor: Sie zahlen mehr für eine schnellere, zuverlässigere Zustellung.

So funktionieren Gebühren:

Total fee = Base fee (5,000 lamports per signature) + Priority fee
Priority fee = Compute units x Price per unit (micro-lamports per compute unit)

Kosten in der Praxis:

• Einfache USDC-Überweisung: ~0,001–0,005 $ unter normalen Bedingungen
• Bei Überlastung: ~0,01–0,05 $
• Spitzenüberlastung: kann höher steigen

Beispielimplementierung:

Das @solana-program/compute-budget-Paket bietet eine Hilfsfunktion, um die Anweisung für den Compute-Unit-Preis (in Micro-Lamports) einfach zu aktualisieren oder an eine Transaktion anzuhängen.

import { updateOrAppendSetComputeUnitPriceInstruction } from "@solana-program/compute-budget";

const tx = pipe(
  createTransactionMessage({ version: 0 }),
  (m) => setTransactionMessageFeePayerSigner(payer, m),
  (m) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m),
  (m) => appendTransactionMessageInstructions([myInstructions], m),
  (m) => updateOrAppendSetComputeUnitPriceInstruction(1000n as MicroLamports, m)
);

Gebührenschätzungen erhalten: Die meisten RPC-Anbieter bieten Priority-Fee-APIs an:

• Helius Priority Fee API
• QuickNode Priority Fee Add-on
• Triton Priority Fees API

Für die vollständige Fee-Mechanik siehe Transaktionsgebühren und unseren Leitfaden: So fügen Sie Priority fees zu einer Transaktion hinzu.

Compute-Units optimieren

Compute auf Solana ist effektiv ein Maß für die Menge an Arbeit, die das Programm leistet. Es gibt eine Begrenzung für die Menge an Compute, die in einer Transaktion verwendet werden kann (derzeit 1,4 Millionen Compute-Units), und eine Begrenzung für die Menge an Compute, die pro Konto pro Block verwendet werden kann (derzeit 100 Millionen Compute-Units).

Wenn Sie eine Transaktion einreichen, müssen Sie die Menge an Compute schätzen, die verwendet wird, und das Compute-Unit-Limit entsprechend festlegen – dies ist effektiv eine Anfrage, wie viel der Gesamtkapazität für Ihre Transaktion reserviert werden soll. In der Praxis bedeutet dies, dass die ordnungsgemäße Schätzung der für Ihre Transaktion erforderlichen Compute-Units entscheidend dafür ist, dass Ihre Transaktion in einen Block aufgenommen wird (und wichtig für die Verwaltung Ihrer Priority fees).

Die Solana JSON RPC API verfügt über eine simulatetransaction-Methode, mit der die für eine Transaktion benötigten Compute Units geschätzt werden können, einschließlich einer Schätzung der tatsächlich verwendeten Compute Units. @solana/kit stellt Hilfsfunktionen bereit, die die Ressourcenlimits einer Transaktion schätzen und in einem Schritt festlegen (intern wird dabei die Methode simulatetransaction verwendet). Bei Transaktionen der Version 1 schätzen diese Hilfsfunktionen auch das Datengrößenlimit der geladenen Konten.

import {
  estimateResourceLimitsFactory,
  estimateAndSetResourceLimitsFactory
} from "@solana/kit";

const estimateResourceLimits = estimateResourceLimitsFactory({ rpc });
const estimateAndSetResourceLimits = estimateAndSetResourceLimitsFactory(
  estimateResourceLimits
);
const txWithResourceLimits = await estimateAndSetResourceLimits(tx);

Im Produktionsbetrieb sollten Sie, wenn Sie denselben Transaktionstyp mehrfach wiederholen, das Compute-Schätzergebnis für diesen Transaktionstyp im Cache speichern, um den Overhead der wiederholten Schätzung der Compute Units zu vermeiden.

Jito Bundles

Jito Bundles sind ein Werkzeug zur Verwaltung der atomaren Ausführung mehrerer Transaktionen. Dies wird erreicht, indem mehrere Transaktionen mit einem Trinkgeld an das Jito-Netzwerk gesendet werden. Trinkgelder können genutzt werden, um das Jito-Netzwerk dazu zu motivieren, Ihre Transaktionen in einen Block aufzunehmen.

Ressourcen:

• Jito-Dokumentation
• 🎥 Video: Jito Bundles
• QuickNode-Leitfaden zu Jito Bundles

Wiederholungsstrategien

Transaktionen können aus vielen Gründen fehlschlagen. Anders als bei herkömmlichen Zahlungs-APIs, die sofort Erfolg oder Misserfolg zurückgeben, erfordern Blockchain-Transaktionen eine Bestätigungsverfolgung.

Wichtige Konzepte:

• Blockhash-Ablauf: Transaktionen sind für ~150 Blöcke (~60–90 Sekunden) gültig
• Idempotenz: Dieselbe signierte Transaktion erzeugt stets dieselbe Signatur – eine erneute Einreichung ist sicher
• Exponentielles Backoff: Vermeiden Sie eine Überlastung des Netzwerks durch schnelle Wiederholungsversuche

import {
  createSolanaRpc,
  createSolanaRpcSubscriptions,
  sendAndConfirmTransactionFactory,
  isSolanaError,
  SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED
} from "@solana/kit";

const rpc = createSolanaRpc(process.env.RPC_URL!);
const rpcSubscriptions = createSolanaRpcSubscriptions(process.env.RPC_WSS_URL!);

const sendAndConfirmTransaction = sendAndConfirmTransactionFactory({
  rpc,
  rpcSubscriptions
});

// Send with automatic confirmation tracking and block height monitoring
try {
  await sendAndConfirmTransaction(signedTransaction, {
    commitment: "confirmed",
    // Optional: abort after 75 seconds
    abortSignal: AbortSignal.timeout(75_000)
  });
} catch (e) {
  if (isSolanaError(e, SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED)) {
    // Blockhash expired—rebuild transaction with fresh blockhash and retry
    rebuildAndRetryTransaction(); // implement your own logic for rebuilding and retrying the transaction
  }
  throw e;
}

Der sendAndConfirmTransactionFactory von @solana/kit übernimmt automatisch das Bestätigungs-Polling und die Blockhöhen-Verfolgung. Er wirft SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED, wenn der Blockhash der Transaktion abläuft – das signalisiert, dass die Transaktion mit einem neuen Blockhash neu aufgebaut werden muss.

Weitere Ressourcen

• Leitfaden: Transaktionsbestätigung & Ablauf
• Helius: So landen Sie Transaktionen auf Solana
• QuickNode: Strategien zur Optimierung von Solana-Transaktionen

Bestätigungsstufen verstehen

Solana bietet drei Bestätigungsstufen. In Begriffen des traditionellen Finanzwesens:

Wann welche Stufe verwendet werden sollte:

• UI-Updates: processed für sofortiges Feedback anzeigen ("Zahlung eingereicht")
• Benutzer-Konten gutschreiben: Auf confirmed warten (sicher für die meisten Transaktionen)
• Physische Waren versenden: Auf finalized warten
• Große Auszahlungen: Auf finalized warten
• Compliance/Prüfung: finalized-Status immer aufzeichnen

Weitere Informationen zur Überprüfung des Transaktionsstatus finden Sie unter Interaktion mit Solana.

Fehlerbehandlung

Solana Kit stellt typisierte Fehler über isSolanaError() bereit. Verwenden Sie spezifische Fehlercodes anstelle von String-Vergleichen:

import {
  isSolanaError,
  SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED,
  SOLANA_ERROR__TRANSACTION_ERROR__INSUFFICIENT_FUNDS_FOR_FEE,
  SOLANA_ERROR__TRANSACTION_ERROR__BLOCKHASH_NOT_FOUND,
  SOLANA_ERROR__INSTRUCTION_ERROR__INSUFFICIENT_FUNDS
} from "@solana/kit";

function handlePaymentError(error: unknown): {
  message: string;
  retryable: boolean;
} {
  // Blockhash expired—rebuild and retry
  if (
    isSolanaError(error, SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED) ||
    isSolanaError(error, SOLANA_ERROR__TRANSACTION_ERROR__BLOCKHASH_NOT_FOUND)
  ) {
    return { message: "Transaction expired—rebuilding", retryable: true };
  }

  // Insufficient SOL for fees
  if (
    isSolanaError(
      error,
      SOLANA_ERROR__TRANSACTION_ERROR__INSUFFICIENT_FUNDS_FOR_FEE
    )
  ) {
    return { message: "Not enough SOL for fees", retryable: false };
  }

  // Insufficient token balance
  if (
    isSolanaError(error, SOLANA_ERROR__INSTRUCTION_ERROR__INSUFFICIENT_FUNDS)
  ) {
    return { message: "Insufficient balance", retryable: false };
  }

  // Unknown error
  console.error("Payment error:", error);
  return { message: "Payment failed—please retry", retryable: true };
}

Häufige Fehlercodes:

Gaslose Transaktionen

Nutzer erwarten, in Stablecoins zu bezahlen, anstatt SOL für Netzwerkgebühren zu erwerben. Gaslose Transaktionen lösen dieses Problem – ähnlich wie Venmo-Nutzer nicht über ACH-Gebühren nachdenken. Siehe Fee Abstraction für die vollständige Implementierung.

Sicherheit

Schlüsselverwaltung

• Private Schlüssel niemals im Frontend-Code offenlegen. Verwende Backend-Signierung, Hardware-Wallets, Multisignatur-Wallets oder Schlüsselverwaltungsdienste.
• Hot- und Cold-Wallets trennen. Hot Wallet für den Betrieb, Cold Wallet für die Treasury.
• Alle Produktionsschlüssel sichern. Verschlüsselte Backups an mehreren sicheren Orten aufbewahren. Der Verlust eines Schlüssels bedeutet dauerhaften Zugriffsverlust.
• Unterschiedliche Schlüssel für Devnet und Mainnet verwenden. Devnet-Schlüssel sollten nicht als Mainnet-Schlüssel genutzt werden. Verwende umgebungsbasierte Konfiguration, um sicherzustellen, dass die richtigen Schlüssel für jedes Netzwerk geladen werden.

Signierungsinfrastruktur

Für produktives Backend-Signing verwende Keychain – eine einheitliche Signierungsbibliothek, die mehrere Schlüsselverwaltungs-Backends über eine einzige Schnittstelle abstrahiert: Memory, Vault, Privy, Turnkey, AWS KMS, Fireblocks, GCP KMS, CDP, Para, Dfns, Crossmint, Openfort und Utila. So kannst du lokal mit In-Memory-Schlüsseln entwickeln und anschließend auf produktionsreife Backends umsteigen, ohne den Anwendungscode zu ändern.

Unsicher, welches Backend passt? Siehe Choosing a backend. Keychain ist sowohl für Rust als auch für TypeScript verfügbar.

RPC-Sicherheit

Behandeln Sie RPC-Endpunkte wie API-Schlüssel – machen Sie sie nicht im Frontend-Code zugänglich, wo sie extrahiert und missbraucht werden können. Verwenden Sie einen Backend-Proxy oder Umgebungsvariablen, die nicht in den Client-Code eingebunden werden.

• QuickNode: Best Practices für Endpoint-Sicherheit
• Helius: Schützen Sie Ihre Solana-API-Schlüssel: Best Practices für die Sicherheit

Überwachung

Verfolgen Sie diese Metriken in der Produktion:

Richten Sie Warnungen ein für:

• Überweisungen über dem Schwellenwert aus der Treasury
• Spitzen bei fehlgeschlagenen Transaktionen
• Ungewöhnliche Empfängermuster
• Anstieg der RPC-Fehlerrate

Für Echtzeit-Transaktionsüberwachung im großen Maßstab siehe unseren Indexierungs-Leitfaden.

Adressen verifizieren

Jeder Token und jedes Programm hat genau eine korrekte Adresse im Mainnet. Gefälschte Tokens, die USDC oder andere Stablecoins imitieren, sind weit verbreitet – sie haben denselben Namen und dasselbe Symbol, aber eine andere Mint-Adresse. Ihre Anwendung sollte die Mint-Adressen fest codieren oder auf eine Whitelist setzen (basierend auf Ihren Anforderungen), und sie niemals dynamisch aus nicht vertrauenswürdigen Quellen akzeptieren.

Umgebungsbasierte Konfiguration: Devnet und Mainnet verwenden häufig völlig unterschiedliche Token-Mints. Richten Sie Ihre Anwendungskonfiguration so ein, dass sie die korrekten Adressen pro Umgebung lädt – kodieren Sie keine Mainnet-Adressen fest und vergessen Sie nicht, diese während des Testens auszutauschen, oder noch schlimmer, liefern Sie Devnet-Adressen in die Produktion aus.

Einige gängige Stablecoin-Mints sind:

Programmadressen sind ebenfalls wichtig. Das Senden von Anweisungen an das falsche Programm wird fehlschlagen – oder schlimmer, zu einem unwiderruflichen Verlust von Geldern führen. Die Token Program-Adressen sind:

Die Aufnahme der richtigen Adressen in die Allowlist schützt vor gefälschten Token, aber nicht davor, an den falschen Typ von Konten zu senden. Eine Empfängeradresse kann eine Wallet, ein token account, ein Mint oder ein Programm sein – jede erfordert eine andere Behandlung. Natives SOL, das an etwas anderes als eine Wallet gesendet wird, entzieht sich der Kontrolle des Absenders – bei einem Mint oder Programm unwiederbringlich verloren, bei einem token account nur durch den Konteninhaber wiederherstellbar – ohne dass eine fehlgeschlagene Transaktion den Benutzer warnt.

Checkliste vor dem Launch

• Mainnet SOL für Fee und rent erworben
• Produktions-RPC konfiguriert (kein öffentlicher Endpunkt)
• Fallback-RPC-Endpunkt konfiguriert
• priority fee mit dynamischer Preisgestaltung implementiert
• Wiederholungslogik behandelt Blockhash-Ablauf
• Bestätigungsstufe für den Anwendungsfall geeignet
• Alle häufigen Fehler werden ordnungsgemäß behandelt
• Gasless konfiguriert (falls zutreffend)
• Mainnet-Token-Adressen verifiziert (keine Devnet-Mints)
• Empfängeradressvalidierung vor dem Senden (Wallet vs. token account vs. Mint vs. Programm)
• Alle Schlüssel sicher gesichert
• Schlüsselverwaltung überprüft (keine Schlüssel im Frontend)
• Transaktionsüberwachung und -benachrichtigung aktiv
• Lasttests beim erwarteten Volumen durchgeführt

Programme deployen

Wenn Sie ein benutzerdefiniertes Solana-Programm als Teil Ihrer Zahlungsinfrastruktur deployen, sind zusätzliche Überlegungen erforderlich.

Vor dem Deployment

• Solana CLI-Version: Stellen Sie sicher, dass Sie die neueste Version der Solana CLI verwenden.
• Program keypair: Ihr Programm hat auf dem Mainnet eine andere Adresse als auf dem Devnet (es sei denn, Sie verwenden dasselbe keypair). Aktualisieren Sie alle Referenzen in Ihrer Anwendungskonfiguration. Bewahren Sie Ihr program keypair an einem sicheren Ort auf (beachten Sie, dass die Ausführung von cargo clean Ihr program keypair wahrscheinlich löscht).
• Konten initialisieren: Wenn Ihr Programm Admin-Konten, PDAs oder andere Statuskonten benötigt, stellen Sie sicher, dass diese auf dem Mainnet erstellt wurden, bevor Benutzer mit Ihrer Anwendung interagieren. Gleiches gilt für alle associated token accounts (ATAs), die Ihr Programm benötigt.

Deployment-Prozess

• Buffer-Accounts: Große Programme werden über Buffer-Accounts deployed. Der solana program deploy-Befehl übernimmt dies automatisch, aber beachten Sie, dass das Deployment nicht atomar ist – wird es unterbrochen, müssen Sie möglicherweise Buffer-Accounts wiederherstellen oder schließen. Siehe Deploying Programs.
• Upgrade-Authority: Entscheiden Sie, ob Ihr Programm nach dem Launch aktualisierbar sein soll. Für Unveränderlichkeit widerrufen Sie die Upgrade-Authority nach dem Deployment. Für mehr Flexibilität sichern Sie den Upgrade-Authority-Schlüssel entsprechend ab.
• Rent: Stellen Sie sicher, dass Ihre Deployment-Wallet genügend SOL besitzt, um die Mindestanforderungen für die Rent-Freistellung aller program accounts zu decken.
• Verifizierung: Verifizieren Sie Ihr Programm, um sicherzustellen, dass das ausführbare Programm, das Sie im Netzwerk von Solana deployen, mit dem Quellcode in Ihrem Repository übereinstimmt.

Eine vollständige Anleitung zum Programm-Deployment finden Sie unter Deploying Programs.