Tuotantovalmius

Paikallinen kehitys ja testaus devnetissä ovat loistavia tapoja aloittaa Solana-maksujen käyttö. Kun olet kuitenkin valmis ottamaan sovelluksen käyttöön mainnetissä, sinun on oltava tietoinen mainnetin erityispiirteistä. Devnet antaa virheet anteeksi. Mainnet ei. Tämä opas käsittelee merkittävät erot varmistaaksesi käyttäjillesi sujuvan käyttökokemuksen.

RPC-infrastruktuuri

Julkiset endpointit (api.mainnet-beta.solana.com) ovat nopeusrajoitettuja ilman SLA:ta. Ne sopivat kehitykseen, mutta epäonnistuvat tuotannon maksuvirroissa—kuin yrittäisit ajaa maksuprosessoria jaetun API:n kautta ilman käytettävyystakuuta.

Kun valitset RPC-palveluntarjoajaa, etsi:

• Luotettavuus: SLA:t käytettävyystakuilla (99,9 %+)
• Viive: Maantieteellinen läheisyys käyttäjiisi
• Ominaisuudet: Transaktioiden laskeutumisominaisuudet, indeksointi, prioriteettimaksu-API:t

Täydellinen luettelo RPC-palveluntarjoajista löytyy RPC-infrastruktuurin palveluntarjoajat -oppaasta.

Redundantti RPC-konfiguraatio

Kuten mikä tahansa verkkopalveluntarjoaja, RPC-palveluntarjoajat voivat kokea käyttökatkoja tai heikentyneen suorituskyvyn jaksoja. Varmistaaksesi sovelluksesi kestävyyden sinun tulisi konfiguroida sovelluksesi käyttämään useita RPC-palveluntarjoajia.

Solana Kit tarjoaa kirjaston RPC-siirtojen mukauttamiseen, jonka avulla voit rakentaa oman redundantin RPC-asiakkaasi. Tässä on esimerkki siitä, miten voit käyttää sitä redundantin RPC-asiakkaan rakentamiseen:

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);
}

Jos et halua rakentaa omia reititystyökalujasi, voit hyödyntää kolmannen osapuolen palvelua, kuten Iron Forge, joka hoitaa reitityksen puolestasi.

Transaktion laskeutuminen

Devnetissä transaktiot laskeutuvat melko helposti. Mainnetissä kilpailet lohkotilasta. Lisätäksesi mahdollisuuksia transaktiosi sisällyttämiseen lohkoon, sinun tulee varmistaa, että olet koonnut transaktiosi oikein. Tämä tarkoittaa:

• tuoreen blockhash-arvon sisällyttämistä ennen transaktion lähettämistä
• prioriteettipalkkio-ohjeen sisällyttämistä transaktioon kilpailukykyisellä prioriteettipalkkiolla
• laskentayksikkörajoitusohjeen sisällyttämistä transaktioon laskentayksikkörajoituksella, joka perustuu transaktion vaatimien laskentayksiköiden arvioon

Lisäksi sinun kannattaa harkita muita työkaluja, kuten Jito Bundles, lisätäksesi mahdollisuuksia transaktiosi sisällyttämiseen lohkoon. Tutkitaan näitä työkaluja tarkemmin.

Transaktion lähetyskonfiguraatio

Kun lähetät transaktioita Mainnetissä, määritä nämä parametrit optimaalisten laskeutumisprosenttien saavuttamiseksi:

Blockhash-hallinta:

• Hae confirmed -sitoutumisella
• Tallenna lastValidBlockHeight, jonka getLatestBlockhash palauttaa – tämä kertoo, milloin transaktiosi vanhenee
• Blockhash-arvot vanhenevat ~150 lohkon jälkeen (~60–90 sekuntia)

Lähetysasetukset:

• maxRetries: 0 — Poista automaattiset RPC-uudelleenyritykset käytöstä. Käsittele uudelleenyritykset itse, jotta voit päivittää blockhash-arvon tarvittaessa.
• skipPreflight: true — Ohita simulointi ennen lähettämistä. Käytä tätä, kun olet jo validoinut transaktion ja haluat pienimmän viiveen. Pidä se false -tilassa kehityksen aikana virheiden havaitsemiseksi varhaisessa vaiheessa.

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

Käytä prioriteettimaksuja

Jokainen Solana-transaktio vaatii transaktiomaksun, joka maksetaan SOL:ssa. Transaktiomaksut jakautuvat kahteen osaan: perusmaksuun ja prioriteettimaksuun. Perusmaksu korvaa validaattoreille transaktion käsittelystä. Prioriteettimaksu on valinnainen maksu, joka lisää todennäköisyyttä, että nykyinen johtaja käsittelee transaktiosi. Ajattele sitä kuin pikatoimitusta: maksat enemmän nopeammasta ja luotettavammasta toimituksesta.

Miten maksut toimivat:

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

Todelliset kustannukset:

• Yksinkertainen USDC-siirto: ~0,001–0,005 $ normaaleissa olosuhteissa
• Ruuhkan aikana: ~0,01–0,05 $
• Huippuruuhkassa: voi nousta korkeammaksi

Esimerkkitoteutus:

@solana-program/compute-budget-paketti tarjoaa apufunktion, jolla voit helposti päivittää tai liittää laskentayksikön hinnan (mikrolamporteissa) -ohjeen transaktioon.

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)
);

Maksuarvioiden hakeminen: Useimmat RPC-palveluntarjoajat tarjoavat prioriteettimaksu-API:t:

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

Täydelliset maksumekaniikan tiedot löydät kohdasta Transaktiomaksut ja oppaastamme: Miten lisätä prioriteettimaksuja transaktioon.

Optimoi laskentayksiköt

Laskenta Solanassa on käytännössä mitta siitä, kuinka paljon työtä ohjelma tekee. Transaktiossa käytettävän laskennan määrälle on raja (tällä hetkellä 1,4 miljoonaa laskentayksikköä), ja tilin lohkoa kohden käytettävän laskennan määrälle on raja (tällä hetkellä 100 miljoonaa laskentayksikköä).

Kun lähetät transaktion, sinun on arvioitava käytettävän laskennan määrä ja asetettava laskentayksikön raja vastaavasti – tämä on käytännössä pyyntö siitä, kuinka suuri osa kokonaiskapasiteetista tulisi varata transaktiollesi. Käytännössä tämä tarkoittaa, että transaktiosi vaatimien laskentayksiköiden oikea arviointi on kriittistä transaktiosi sisällyttämiseksi lohkoon (ja tärkeää prioriteettimaksujesi hallinnassa).

Solana JSON RPC API:lla on simulatetransaction-metodi, jota voidaan käyttää arvioimaan transaktion vaatimia laskentayksiköitä. Tämä sisältää arvion käytettävistä laskentayksiköistä. @solana/kit tarjoaa apufunktioita, jotka arvioivat transaktion resurssirajoitukset ja asettavat ne viestiin yhdellä kertaa (käyttäen simulatetransaction-metodia taustalla). Versio 1 -transaktioille nämä apufunktiot arvioivat myös ladattujen tilien datakoon rajan.

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

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

Tuotantoympäristössä, jos toistat saman tyyppistä transaktiota useita kertoja, sinun kannattaa harkita laskenta-arvion välimuistiin tallentamista kyseiselle transaktiotypille, jotta vältät laskentayksiköiden arvioimisesta aiheutuvan yleisrasitteen joka kerta.

Jito-paketit

Jito-paketit ovat työkalu useiden transaktioiden atomisen suorituksen hallintaan. Tämä saavutetaan lähettämällä useita transaktioita Jito-verkkoon tippiä käyttäen. Tippejä voidaan käyttää kannustimena Jito-verkolle, jotta se sisällyttää transaktiosi lohkoon.

Resurssit:

• Jito-dokumentaatio
• 🎥 Video: Jito-paketit
• QuickNoden opas Jito-paketeista

Uudelleenyritysstrategiat

Transaktiot voivat epäonnistua monista syistä. Toisin kuin perinteiset maksu-API:t, jotka palauttavat onnistumisen tai epäonnistumisen välittömästi, lohkoketjutransaktiot edellyttävät vahvistuksen seuraamista.

Keskeiset käsitteet:

• Lohkohashin vanheneminen: Transaktiot ovat voimassa noin 150 lohkon ajan (~60–90 sekuntia)
• Idempotenssi: Sama allekirjoitettu transaktio tuottaa aina saman allekirjoituksen — uudelleenlähetys on turvallista
• Eksponentiaalinen peruutus: Vältä verkon kuormittamista nopeilla uudelleenyrityksillä

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;
}

sendAndConfirmTransactionFactory kohteesta @solana/kit käsittelee vahvistuksen kyselyt ja lohkon korkeuden seurannan automaattisesti. Se heittää SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED kun transaktion lohkohashin voimassaolo päättyy, merkkinä siitä, että sinun on rakennettava transaktio uudelleen tuoreella lohkohashilla.

Lisäresurssit

• Opas: Transaktion vahvistus & vanhentuminen
• Helius: Kuinka tehdä transaktioita Solanassa
• QuickNode: Strategiat Solana-transaktioiden optimointiin

Vahvistustasojen ymmärtäminen

Solana tarjoaa kolme vahvistustasoa. Perinteisen rahoituksen termein:

Milloin käyttää kutakin:

• Käyttöliittymäpäivitykset: Näytä processed välittömän palautteen saamiseksi ("Maksu lähetetty")
• Käyttäjätilin hyvitys: Odota confirmed (turvallinen useimmille transaktioille)
• Fyysisten tavaroiden toimitus: Odota finalized
• Suuret nostot: Odota finalized
• Vaatimustenmukaisuus/auditointi: Tallenna aina finalized -tila

Lisätietoja transaktion tilan tarkistamisesta on kohdassa Vuorovaikutus Solanan kanssa.

Virheenkäsittely

Solana Kit tarjoaa tyypitetyt virheet isSolanaError():n kautta. Käytä tiettyjä virhekoodeja merkkijonojen vastaavuuden sijaan:

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 };
}

Yleiset virhekoodit:

Kaasuttomat transaktiot

Käyttäjät odottavat maksavansa stablecoineilla eivätkä halua hankkia SOL-tokeneita verkkomaksuja varten. Kaasuttomat transaktiot ratkaisevat tämän – samoin kuin Venmon käyttäjät eivät ajattele ACH-maksuja. Katso Maksujen abstrahointi täydellisen toteutuksen osalta.

Tietoturva

Avainten hallinta

• Älä koskaan paljasta yksityisiä avaimia käyttöliittymäkoodissa. Käytä taustapalvelun allekirjoitusta, laitteistolompakkeita, moniallekirjoituslompakkeita tai avaintenhallintapalveluita.
• Erota kuumat ja kylmät lompakot toisistaan. Kuuma lompakko operaatioita varten, kylmä kassaa varten.
• Varmuuskopioi kaikki tuotantoavaimet. Tallenna salatut varmuuskopiot useisiin turvallisiin sijainteihin. Avaimen menettäminen tarkoittaa pysyvää pääsyn menetystä.
• Käytä eri avaimia devnetille ja mainnetille. Devnet-avaimesi eivät saa olla mainnet-avaimiasi. Käytä ympäristöpohjaista konfiguraatiota varmistaaksesi, että oikeat avaimet ladataan kullekin verkolle.

Allekirjoitusinfrastruktuuri

Tuotannon taustapalvelun allekirjoitukseen käytä Keychainia – yhtenäinen allekirjoituskirjasto, joka abstrahoi useita avaintenhallintataustajärjestelmiä yhden rajapinnan kautta: Memory, Vault, Privy, Turnkey, AWS KMS, Fireblocks, GCP KMS, CDP, Para, Dfns, Crossmint, Openfort ja Utila. Tämän ansiosta voit kehittää paikallisesti muistissa olevilla avaimilla ja vaihtaa sitten tuotantotason taustajärjestelmiin muuttamatta sovelluskoodia.

Etkö ole varma, mikä taustajärjestelmä sopii sinulle? Katso Taustajärjestelmän valinta. Keychain on saatavilla sekä Rustille että TypeScriptille.

RPC-turvallisuus

Käsittele RPC-päätepisteitä kuten API-avaimia—älä paljasta niitä frontend-koodissa, josta ne voidaan poimia ja väärinkäyttää. Käytä backend-välityspalvelinta tai ympäristömuuttujia, joita ei upoteta asiakaskoodiin.

• QuickNode: Endpoint Security Best Practices
• Helius: Protect Your Solana API Keys: Security Best Practices

Seuranta

Seuraa näitä mittareita tuotannossa:

Aseta hälytykset seuraaville:

• Kynnysarvon ylittävät siirrot kassasta
• Epäonnistuneiden transaktioiden määrän piikkaukset
• Epätavalliset vastaanottajamallit
• RPC-virheprosentin nousu

Reaaliaikaista transaktioseurantaa laajassa mittakaavassa varten tutustu Indexing Guide -oppaaseemme.

Vahvista osoitteet

Jokaisella tokenilla ja ohjelmalla on täsmälleen yksi oikea osoite mainnetissä. USDC:tä ja muita vakaakolikoita jäljittelevät väärennetyt tokenit ovat yleisiä—niillä on sama nimi ja symboli, mutta eri mint-osoite. Sovelluksesi tulisi kovakoodata tai sallittujen listalle lisätä mint-osoitteet (vaatimustesi mukaan), älä koskaan hyväksy niitä dynaamisesti epäluotettavista lähteistä.

Ympäristöpohjainen konfiguraatio: Devnet ja Mainnet käyttävät usein täysin erilaisia token mint -osoitteita. Määritä sovelluksesi konfiguraatio lataamaan oikeat osoitteet ympäristökohtaisesti – älä kovakoodaa mainnet-osoitteita ja unohda vaihtaa niitä testauksen aikana, tai vielä pahempaa, lähetä devnet-osoitteita tuotantoon.

Yleisiä stablecoin mint -osoitteita ovat:

Myös ohjelma-osoitteet ovat tärkeitä. Ohjeiden lähettäminen väärään ohjelmaan epäonnistuu – tai pahimmassa tapauksessa johtaa peruuttamattomaan varojen menetykseen. Token Program -osoitteet ovat:

Oikeiden osoitteiden salliminen suojaa väärennetyiltä tokeneilta, mutta ei suojaa väärän tyyppisen tilin käyttämiseltä. Vastaanottajan osoite voi olla lompakko, token account, mint tai ohjelma, ja jokainen vaatii erilaista käsittelyä. Native SOL, joka lähetetään muulle kuin lompakolle, poistuu lähettäjän hallinnasta — katoaa kokonaan mint:lle tai ohjelmalle lähetettäessä, ja on palautettavissa ainoastaan tilin omistajan toimesta token account:lle lähetettäessä — ilman epäonnistunutta transaktiota, joka varoittaisi käyttäjää.

Julkaisua edeltävä tarkistuslista

• Mainnet SOL hankittu maksuja ja rent:iä varten
• Tuotanto-RPC konfiguroitu (ei julkinen päätepiste)
• Varakopio-RPC-päätepiste konfiguroitu
• Prioriteettimaksut toteutettu dynaamisella hinnoittelulla
• Uudelleenyrityslogiikka käsittelee lohkohashin vanhentumisen
• Vahvistustaso sopiva käyttötapaukseen
• Kaikki yleiset virheet käsitelty hallitusti
• Gasless konfiguroitu (tarvittaessa)
• Mainnet-token-osoitteet vahvistettu (ei devnet-minttejä)
• Vastaanottajan osoitteen validointi ennen lähettämistä (lompakko vs token account vs mint vs ohjelma)
• Kaikki avaimet varmuuskopioitu turvallisesti
• Avainten hallinta tarkastettu (ei avaimia käyttöliittymässä)
• Transaktioiden seuranta ja hälytykset aktiivisia
• Kuormitustestattu odotetulla volyymilla

Ohjelmien käyttöönotto

Jos otat käyttöön mukautetun Solana-ohjelman osana maksuinfrastruktuuriasi, on huomioitava lisäseikkoja.

Ennen käyttöönottoa

• Solana CLI -versio: Varmista, että käytät uusinta versiota Solana CLI -työkalusta.
• Ohjelman keypair: Ohjelmallasi on eri osoite mainnetissä kuin devnetissä (ellet käytä samaa keypair-avainta uudelleen). Päivitä kaikki viittaukset sovelluksesi asetuksissa. Säilytä ohjelmasi keypair turvallisessa paikassa (huomaa, että cargo clean saattaa poistaa ohjelmasi keypair-avaimen).
• Tilien alustaminen: Jos ohjelmasi vaatii ylläpitäjätilejä, PDA-tilejä tai muita tilatilejä, varmista, että nämä on luotu mainnetissä ennen kuin käyttäjät käyttävät sovellustasi. Sama koskee kaikkia Associated Token Accounts (ATAs) -tilejä, joita ohjelmasi tarvitsee.

Käyttöönottoprosessi

• Puskuritilit: Suuret ohjelmat otetaan käyttöön puskuritilien kautta. Komento solana program deploy hoitaa tämän automaattisesti, mutta huomaa, että käyttöönotto ei ole atominen – jos se keskeytyy, saatat joutua palauttamaan tai sulkemaan puskuritilejä. Katso Ohjelmien käyttöönotto.
• Päivitysoikeus: Päätä, pitäisikö ohjelmasi olla päivitettävissä julkaisun jälkeen. Muuttumattomuuden takaamiseksi peruuta päivitysoikeus käyttöönoton jälkeen. Joustavuuden säilyttämiseksi suojaa päivitysoikeusavain asianmukaisesti.
• Vuokra: Varmista, että käyttöönottoihin käyttämälläsi lompakolla on riittävästi SOL:ia kattamaan vuokravapaan vähimmäismäärän kaikille program accounts -tileille.
• Varmennus: Varmenna ohjelmasi varmistaaksesi, että Solanan verkkoon käyttöön ottamasi suoritettava ohjelma vastaa repositoriosi lähdekoodia.

Täydelliset ohjeet ohjelman käyttöönottoon löydät sivulta Ohjelmien käyttöönotto.