Ü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 amacıyla kullanılabilecek bir simulatetransaction yöntemi vardır; bu yöntem, kullanılacak hesaplama birimlerinin tahminini de içerir. @solana/kit, bir işlemin kaynak limitlerini tahmin eden ve bunları tek adımda mesaja ayarlayan yardımcı fonksiyonlar sunar (arka planda simulatetransaction yöntemini kullanarak). Versiyon 1 işlemler için bu yardımcılar aynı zamanda yüklenen hesap verisi boyut limitini de tahmin eder.

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

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

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

Jito Bundle'ları

Jito bundle'ları, birden fazla işlemin atomik olarak yürütülmesini yönetmek için bir araçtır. Bu, birden fazla işlemi Jito ağına bir bahşiş ile 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 belgeleri
• 🎥 Video: Jito Bundle'ları
• QuickNode'un Jito bundle'ları rehberi

Yeniden Deneme Stratejileri

İşlemler birçok nedenden dolayı başarısız olabilir. Hemen başarı/başarısızlık döndüren geleneksel ödeme API'lerinin aksine, blok zinciri işlemleri onay takibi gerektirir.

Temel kavramlar:

• Blok hash'i süresi dolumu: İşlemler yaklaşık ~150 blok (~60-90 saniye) boyunca geçerlidir
• Etkisizlik: Aynı imzalı işlem her zaman aynı imzayı üretir — yeniden göndermek güvenlidir
• Üstel geri çekilme: Ağı hızlı yeniden denemelerle aşırı yüklememek için dikkatli olun

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, @solana/kit'dan onay yoklaması ve blok yüksekliği takibini otomatik olarak yönetir. İşlemin blok karması süresi dolduğunda SOLANA_ERROR__BLOCK_HEIGHT_EXCEEDED hatası fırlatır; bu, işlemi yeni bir blok karmasıyla yeniden oluşturmanız gerektiğini bildirir.

Ek Kaynaklar

• Kılavuz: İşlem Onayı ve Sona Erme
• Helius: Solana'da İşlemler Nasıl Gerçekleştirilir
• QuickNode: Solana İşlemlerini Optimize Etme Stratejileri

Onay Seviyelerini Anlamak

Solana üç onay seviyesi sunar. Geleneksel finans terimleriyle:

Her biri ne zaman kullanılır:

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

İşlem durumunu kontrol etme hakkında daha fazla bilgi için bkz. Solana ile Etkileşim.

Hata Yönetimi

Solana Kit, isSolanaError() aracılığıyla türlendirilmiş hatalar sağlar. Dize eşleştirme 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ı:

Gassız İşlemler

Kullanıcılar ağ ücretleri için SOL edinmek yerine stablecoin ile ödeme yapmayı bekler. Gassız işlemler bunu çözer—tıpkı Venmo kullanıcılarının ACH ücretleri hakkında düşünmemesi gibi. Tam 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 hizmetleri kullanın.
• Sıcak ve soğuk cüzdanları birbirinden 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. Şifreli 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üklenmesini sağlamak amacıyla ortam tabanlı yapılandırma kullanın.

İmzalama Altyapısı

Üretim ortamında backend imzalama için Keychain kullanın—tek bir arayüz aracılığıyla birden fazla anahtar yönetim backend'ini soyutlayan birleşik bir imzalama kütüphanesi: Memory, Vault, Privy, Turnkey, AWS KMS, Fireblocks, GCP KMS, CDP, Para, Dfns, Crossmint, Openfort ve Utila. Bu sayede yerel ortamda bellek içi anahtarlarla geliştirme yapabilir, ardından uygulama kodunu değiştirmeden üretim kalitesindeki backend'lere geçiş yapabilirsiniz.

Hangi backend'in uygun olduğundan emin değil misiniz? Backend seçimi bölümüne bakın. Keychain hem Rust hem de TypeScript için kullanılabilir.

RPC Güvenliği

RPC uç noktalarını API anahtarları gibi ele alın—bunları çıkarılıp kötüye kullanılabileceği frontend kodunda ifşa etmeyin. İstemci koduna paketlenmeyen ortham değişkenlerini veya bir backend proxy kullanın.

• QuickNode: Uç Nokta Güvenliği En İyi Uygulamaları
• Helius: Solana API Anahtarlarınızı Koruyun: Güvenlik En İyi Uygulamaları

İzleme

Üretim ortamında şu metrikleri takip edin:

Şunlar için uyarılar kurun:

• Hazineden eşik değerinin üzerindeki transferler
• Başarısız işlem oranı artışları
• Olağandışı alıcı desenleri
• 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 sabit paraları taklit eden sahte tokenlar yaygındır—aynı isme ve sembole sahip olacaklar ancak farklı bir mint adresine sahip olacaklardır. Uygulamanız mint adreslerini (gereksinimlerinize göre) sabit kodlamalı veya allowlist'e eklemelidir, bunları asla 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 üretime göndermemeye dikkat edin.

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önüşü olmayan fon kaybına yol açar. Token Program adresleri şunlardır:

Doğru adresleri izin listesine eklemek sahte token'lara karşı koruma sağlar; ancak yanlış türde bir hesaba gönderimi engellemez. Alıcı adresi bir cüzdan, token account, mint veya program olabilir ve her biri farklı işlem gerektirir. Bir cüzdan dışındaki herhangi bir adrese gönderilen yerel SOL, gönderenin kontrolünden çıkar — bir mint veya program söz konusuysa tamamen kaybolur, token account söz konusuysa yalnızca hesap sahibi tarafından kurtarılabilir — ve kullanıcıyı uyaracak herhangi bir başarısız işlem oluşmaz.

Yayına Alma Öncesi Kontrol Listesi

• Ücretler ve rent için Mainnet SOL temin edildi
• Üretim RPC yapılandırıldı (genel uç nokta değil)
• Yedek RPC uç noktası yapılandırıldı
• Dinamik fiyatlandırmayla öncelik ücretleri uygulandı
• Yeniden deneme mantığı blockhash süre aşımını ele alıyor
• Onay düzeyi kullanım senaryosuna uygun
• Tüm yaygın hatalar sorunsuz biçimde ele alındı
• Gassız yapılandırıldı (varsa)
• Mainnet token adresleri doğrulandı (devnet mint'leri değil)
• Göndermeden önce alıcı adres doğrulaması yapıldı (cüzdan vs token account vs mint vs program)
• Tüm anahtarlar güvenli biçimde yedeklendi
• Anahtar yönetimi gözden geçirildi (ön uçta anahtar yok)
• İşlem izleme ve uyarı sistemi aktif
• Beklenen hacimde yük testi yapıldı

Program Dağıtımı

Ödeme altyapınızın bir parçası olarak özel bir Solana programı dağıtıyorsanız göz önünde bulundurmanız gereken ek hususlar bulunmaktadır.

Dağıtım Öncesi

• Solana CLI sürümü: Solana CLI uygulamasının en güncel sürümünü kullandığınızdan emin olun.
• Program keypair: Programınız, mainnet üzerinde devnet'tekinden farklı bir adrese sahip 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 komutunun çalıştırılmasının program keypair'inizi silebileceğini unutmayın).
• Hesapları başlatın: Programınız yönetici hesapları, PDA'lar veya diğer durum hesapları gerektiriyorsa, kullanıcılar uygulamanızla etkileşime geçmeden önce bu hesapların mainnet üzerinde oluşturulduğundan emin olun. Programınızın ihtiyaç duyduğu Associated Token Accounts (ATA'lar) için de aynı durum geçerlidir.

Dağıtım Süreci

• Buffer hesapları: Büyük programlar, buffer accounts aracılığıyla dağıtılır. solana program deploy komutu bunu otomatik olarak gerçekleştirir; ancak dağıtımın atomik olmadığını unutmayın—kesintiye uğrarsa buffer accounts'ları kurtarmanız veya kapatmanız gerekebilir. Bkz. Programları Dağıtma.
• Yükseltme yetkisi: Programınızın lansmanın ardından yükseltilip yükseltilmeyeceğine karar verin. Değişmezlik için dağıtımın ardından 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 accounts için kira muafiyeti minimumlarını karşılayacak yeterli SOL bulunduğundan emin olun.
• Doğrulama: Solana ağına dağıttığınız yürütülebilir programın deponuzdaki kaynak kodla eşleştiğinden emin olmak için programınızı doğrulayın.

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