Üretime hazırlık

Yerel olarak geliştirme ve devnet üzerinde test etme, Solana ödemeleriyle başlamak için harika yollardır. Ancak Mainnet'e dağıtıma hazır olduğunuzda, mainnet'in nüanslarının farkında olmanız gerekir. Devnet hataları affeder. Mainnet affetmez. Bu kılavuz, kullanıcılarınızın sorunsuz bir deneyim yaşamasını sağlamak için önemli olan farklılıkları kapsar.

RPC altyapısı

Genel endpoint'ler (api.mainnet-beta.solana.com) hız sınırlıdır ve SLA sunmaz. Geliştirme için iyidirler ancak üretim ödeme akışlarında başarısız olurlar—tıpkı bir ödeme işlemcisini çalışma süresi garantisi olmayan paylaşımlı bir API üzerinden çalıştırmaya çalışmak gibi.

Bir RPC sağlayıcısı seçerken şunlara dikkat edin:

• Güvenilirlik: Çalışma süresi garantileriyle SLA'lar (%99,9+)
• Gecikme: Kullanıcılarınıza coğrafi yakınlık
• Özellikler: İşlem gerçekleştirme özellikleri, indeksleme, öncelik ücreti API'leri

RPC sağlayıcılarının tam listesi için RPC altyapı sağlayıcıları kılavuzuna bakın.

Yedekli RPC yapılandırması

Herhangi bir ağ hizmeti sağlayıcısı gibi, RPC sağlayıcıları da kesinti veya düşük performans dönemleri yaşayabilir. Uygulamanızın dayanıklı olmasını sağlamak için uygulamanızı birden fazla RPC sağlayıcısı kullanacak şekilde yapılandırmalısınız.

Solana Kit RPC aktarımlarını özelleştirmek için bir kütüphane sağlar ve kendi yedekli RPC istemcinizi oluşturmanıza olanak tanır. İşte yedekli bir RPC istemcisi oluşturmak için nasıl kullanabileceğinize dair bir örnek:

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

Kendi yönlendirme araçlarınızı oluşturmayı tercih etmiyorsanız, yönlendirmeyi sizin için halletmesi için Iron Forge gibi üçüncü taraf bir hizmetten yararlanabilirsiniz.

İşlem iniş

Devnet'te işlemler oldukça kolay iniş yapar. Mainnet'te ise blok alanı için rekabet ediyorsunuz. İşleminizin bir bloğa dahil edilme şansını artırmak için, işleminizi düzgün bir şekilde oluşturduğunuzdan emin olmalısınız. Bu şu anlama gelir:

• işlemi göndermeden önce yeni bir blockhash ekleme
• işlemde rekabetçi bir öncelik ücreti ile bir öncelik ücreti talimatı ekleme
• işlemde, işlem için gereken tahmini hesaplama birimlerine dayalı bir hesaplama birimi limiti talimatı ekleme

Ayrıca, işleminizin bir bloğa dahil edilme şansını artırmak için Jito Bundles gibi diğer araçları da değerlendirmelisiniz. Bu araçları daha ayrıntılı olarak inceleyelim.

İşlem gönderme yapılandırması

Mainnet'te işlem gönderirken, optimum iniş oranları için bu parametreleri yapılandırın:

Blockhash yönetimi:

• confirmed taahhüdü ile getir
• getLatestBlockhash tarafından döndürülen lastValidBlockHeight değerini saklayın—bu size işleminizin ne zaman sona ereceğini söyler
• Blockhash'ler yaklaşık 150 blok sonra (~60-90 saniye) sona erer

Gönderme seçenekleri:

• maxRetries: 0 — Otomatik RPC yeniden denemelerini devre dışı bırakır. Yeniden denemeleri kendiniz yönetin, böylece gerektiğinde blockhash'i yenileyebilirsiniz.
• skipPreflight: true — Göndermeden önce simülasyonu atlar. Bunu işlemi zaten doğruladığınızda ve en düşük gecikme istediğinizde kullanın. Hataları erken yakalamak için geliştirme sırasında false olarak tutun.

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

Öncelik ücretlerini kullanın

Her Solana işlemi, SOL cinsinden ödenen bir işlem ücreti gerektirir. İşlem ücretleri iki bölüme ayrılır: temel ücret ve öncelik ücreti. Temel ücret, doğrulayıcıları işlemi işlemek için tazmin eder. Öncelik ücreti, mevcut liderin işleminizi işleme olasılığını artırmak için isteğe bağlı bir ücrettir. Bunu ekspres kargo gibi düşünün: daha hızlı, daha güvenilir teslimat için daha fazla ödeme yaparsınız.

Ücretler nasıl çalışır:

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

Gerçek dünya maliyetleri:

• Basit USDC transferi: normal koşullarda ~$0.001-0.005
• Yoğunluk sırasında: ~$0.01-0.05
• Yoğunluk zirvesinde: daha yüksek seviyelere çıkabilir

Örnek uygulama:

@solana-program/compute-budget paketi, bir işleme hesaplama birimi fiyatı (mikro-lamport cinsinden) talimatını kolayca güncellemek veya eklemek için yardımcı bir fonksiyon sağlar.

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

Ücret tahminleri almak: Çoğu RPC sağlayıcısı öncelik ücreti API'leri sunar:

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

Tam ücret mekanikleri için Transaction Fees bölümüne ve rehberimize bakın: How to Add Priority Fees to a Transaction.

Hesaplama birimlerini optimize edin

Solana'da hesaplama, programın yaptığı iş miktarının etkin bir ölçüsüdür. Bir işlemde kullanılabilecek hesaplama miktarında bir sınır (şu anda 1,4 milyon hesaplama birimi) ve blok başına hesap başına kullanılabilecek hesaplama miktarında bir sınır (şu anda 100 milyon hesaplama birimi) vardır.

Bir işlem gönderdiğinizde, kullanılacak hesaplama miktarını tahmin etmeniz ve hesaplama birimi sınırını buna göre ayarlamanız gerekir - bu, işleminiz için ayrılması gereken toplam kapasitenin ne kadarının talep edildiğini gösterir. Pratikte bu, işleminiz için gereken hesaplama birimlerini doğru şekilde tahmin etmenin, işleminizin bir bloğa dahil edilmesi için kritik olduğu (ve öncelik ücretlerinizi yönetmek için önemli olduğu) anlamına gelir.

Solana JSON RPC API'sinin bir işlem için gereken hesaplama birimlerini tahmin etmek üzere kullanılabilen bir simulatetransaction metodu bulunmaktadır; bu metod kullanılacak hesaplama birimlerinin tahminini içerir. @solana-program/compute-budget paketi, bir işlem için gereken hesaplama birimlerini kolayca tahmin etmek için yardımcı bir fonksiyon sağlar (bu fonksiyon arka planda simulatetransaction metodunu kullanır).

import {
  estimateComputeUnitLimitFactory,
  updateOrAppendSetComputeUnitLimitInstruction
} from "@solana-program/compute-budget";

const estimateComputeUnitLimit = estimateComputeUnitLimitFactory({ rpc });
const computeUnitLimit = await estimateComputeUnitLimit(tx);
const txWithComputeUnitLimit = updateOrAppendSetComputeUnitLimitInstruction(
  computeUnitLimit,
  tx
);

Üretim ortamında, aynı türde işlemi birden çok kez tekrarlıyorsanız, her seferinde hesaplama birimlerini tahmin etmenin yükünden kaçınmak için işlem türü için hesaplama tahminini önbelleğe almayı düşünmelisiniz.

Jito paketleri

Jito paketleri, birden fazla işlemin atomik olarak yürütülmesini yönetmek için bir araçtır. Bu, birden fazla işlemi bir bahşiş ile Jito ağına göndererek sağlanır. Bahşişler, Jito ağını işlemlerinizi bir bloğa dahil etmeye teşvik etmek için kullanılabilir.

Kaynaklar:

• Jito dokümantasyonu
• 🎥 Video: Jito paketleri
• Jito paketleri hakkında QuickNode rehberi

Yeniden deneme stratejileri

İşlemler birçok nedenden dolayı başarısız olabilir. Başarı/başarısızlığı anında döndüren geleneksel ödeme API'lerinin aksine, blokzincir işlemleri onay takibi gerektirir.

Temel kavramlar:

• Blockhash sona ermesi: İşlemler yaklaşık 150 blok (~60-90 saniye) boyunca geçerlidir
• Idempotency: Aynı imzalanmış işlem her zaman aynı imzayı üretir—yeniden gönderme güvenlidir
• Üstel geri çekilme: Hızlı yeniden denemelerle ağı bunaltmaktan kaçının

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

@solana/kit içindeki sendAndConfirmTransactionFactory, onay yoklamasını ve blok yüksekliği takibini otomatik olarak yönetir. İşlemin blockhash'i sona erdiğinde SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED hatası fırlatır ve işlemi yeni bir blockhash ile yeniden oluşturmanız gerektiğini bildirir.

Ek kaynaklar

• Kılavuz: İşlem onayı ve süre sonu
• Helius: Solana'da işlemler nasıl gerçekleştirilir
• QuickNode: Solana işlemlerini optimize etme stratejileri

Onay seviyelerini anlama

Solana üç onay seviyesi sunar. Geleneksel finans terimleriyle:

Her birinin ne zaman kullanılacağı:

• UI güncellemeleri: Anında geri bildirim için processed gösterin ("Ödeme gönderildi")
• Kullanıcı hesabına kredi: confirmed bekleyin (çoğu işlem için güvenli)
• Fiziksel ürün gönderimi: finalized bekleyin
• Büyük para çekme işlemleri: finalized bekleyin
• Uyumluluk/denetim: Her zaman finalized durumunu kaydedin

İşlem durumunu kontrol etme hakkında daha fazla bilgi için, Solana ile etkileşim bölümüne bakın.

Hata yönetimi

Solana Kit, isSolanaError() aracılığıyla tiplendirilmiş hatalar sağlar. Dize eşleştirmesi yerine belirli hata kodlarını kullanın:

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

Yaygın hata kodları:

Gaz ücreti olmayan işlemler

Kullanıcılar ağ ücretleri için SOL edinmek yerine stablecoin ile ödeme yapmayı bekler. Gaz ücreti olmayan işlemler bunu çözer—tıpkı Venmo kullanıcılarının ACH ücretlerini düşünmemesi gibi. Eksiksiz uygulama için Ücret soyutlama bölümüne bakın.

Güvenlik

Anahtar yönetimi

• Özel anahtarları asla frontend kodunda açığa çıkarmayın. Backend imzalama, donanım cüzdanları, çoklu imza cüzdanları veya anahtar yönetim hizmetlerini kullanın.
• Sıcak ve soğuk cüzdanları ayırın. İşlemler için sıcak cüzdan, hazine için soğuk cüzdan kullanın.
• Tüm üretim anahtarlarını yedekleyin. Şifrelenmiş yedekleri birden fazla güvenli konumda saklayın. Bir anahtarı kaybetmek, erişimi kalıcı olarak kaybetmek anlamına gelir.
• Devnet ve mainnet için farklı anahtarlar kullanın. Devnet anahtarlarınız mainnet anahtarlarınız olmamalıdır. Her ağ için doğru anahtarların yüklendiğinden emin olmak için ortam tabanlı yapılandırma kullanın.

RPC güvenliği

RPC uç noktalarına API anahtarları gibi davranın—çıkarılıp kötüye kullanılabilecekleri frontend kodunda açığa çıkarmayın. Backend proxy veya istemci koduna paketlenmeyen ortam değişkenleri kullanın.

• QuickNode: Uç nokta güvenliği en iyi uygulamaları
• Helius: Solana API anahtarlarınızı koruyun: Güvenlik en iyi uygulamaları

İzleme

Üretimde şu metrikleri takip edin:

Şunlar için uyarılar ayarlayın:

• Hazineden eşik değerinin üzerindeki transferler
• Başarısız işlem oranı artışları
• Olağandışı alıcı kalıpları
• RPC hata oranı artışları

Ölçekte gerçek zamanlı işlem izleme için İndeksleme kılavuzumuza bakın.

Adresleri doğrulayın

Her token ve programın mainnet üzerinde tam olarak bir doğru adresi vardır. USDC veya diğer stablecoin'leri taklit eden sahte tokenlar yaygındır—aynı ada ve sembole sahip olacaklar ancak farklı bir mint adresine sahip olacaklar. Uygulamanız mint adreslerini sabit kodlamalı veya izin listesine almalıdır (gereksinimlerinize göre), asla bunları güvenilmeyen kaynaklardan dinamik olarak kabul etmemelidir.

Ortam tabanlı yapılandırma: Devnet ve Mainnet genellikle tamamen farklı token mint'leri kullanır. Uygulamanızın yapılandırmasını her ortam için doğru adresleri yükleyecek şekilde ayarlayın—mainnet adreslerini sabit kodlayıp test sırasında değiştirmeyi unutmayın veya daha kötüsü, devnet adreslerini production'a göndermeyin.

Bazı yaygın stablecoin mint'leri şunlardır:

Program adresleri de önemlidir. Yanlış programa talimat göndermek başarısız olur—veya daha kötüsü, geri döndürülemez fon kaybına neden olur. Token Program adresleri şunlardır:

Lansman öncesi kontrol listesi

• Ücretler ve rent için mainnet SOL edinildi
• Production RPC yapılandırıldı (genel endpoint değil)
• Yedek RPC endpoint'i yapılandırıldı
• Dinamik fiyatlandırma ile öncelik ücretleri uygulandı
• Yeniden deneme mantığı blockhash süre aşımını ele alıyor
• Onay seviyesi kullanım durumu için uygun
• Tüm yaygın hatalar düzgün bir şekilde ele alınıyor
• Gasless yapılandırıldı (uygulanabilirse)
• Mainnet token adresleri doğrulandı (devnet mint'leri değil)
• Tüm anahtarlar güvenli bir şekilde yedeklendi
• Anahtar yönetimi gözden geçirildi (frontend'de anahtar yok)
• İşlem izleme ve uyarı aktif
• Beklenen hacimde yük testi yapıldı

Programları dağıtma

Ödeme altyapınızın bir parçası olarak özel bir Solana programı dağıtıyorsanız, dikkate almanız gereken ek hususlar vardır.

Dağıtım öncesi

• Solana CLI sürümü: Solana CLI'nin en son sürümünü kullandığınızdan emin olun.
• Program keypair'i: Programınızın mainnet'te devnet'tekinden farklı bir adresi olacaktır (aynı keypair'i yeniden kullanmıyorsanız). Uygulama yapılandırmanızdaki tüm referansları güncelleyin. Program keypair'inizi güvenli bir konumda saklayın (cargo clean komutunu çalıştırmanın muhtemelen program keypair'inizi sileceğini unutmayın).
• Hesapları başlatma: Programınız yönetici hesapları, PDA'lar veya diğer durum hesapları gerektiriyorsa, kullanıcılar uygulamanızla etkileşime geçmeden önce bunların mainnet'te oluşturulduğundan emin olun. Programınızın ihtiyaç duyduğu ilişkili token hesapları (ATA'lar) için de aynısı geçerlidir.

Dağıtım süreci

• Buffer hesapları: Büyük programlar buffer hesapları aracılığıyla dağıtılır. solana program deploy komutu bunu otomatik olarak halleder, ancak dağıtımın atomik olmadığını anlayın—kesintiye uğrarsa, buffer hesaplarını kurtarmanız veya kapatmanız gerekebilir. Bkz. Programları dağıtma.
• Yükseltme yetkisi: Programınızın lansmanın ardından yükseltilebilir olup olmaması gerektiğine karar verin. Değiştirilemezlik için, dağıtımdan sonra yükseltme yetkisini iptal edin. Esneklik için, yükseltme yetkisi anahtarını uygun şekilde güvence altına alın.
• Kira: Dağıtım cüzdanınızda tüm program hesapları için kira muafiyeti minimumlarını karşılayacak yeterli SOL olduğundan emin olun.
• Doğrulama: Solana ağına dağıttığınız yürütülebilir programın deponuzdaki kaynak koduyla eşleştiğinden emin olmak için programınızı doğrulayın

Eksiksiz program dağıtım rehberliği için bkz. Programları dağıtma.