Ana içeriğe atla

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Bu sayfa yapay zekâ tarafından otomatik olarak çevrilmiştir. İngilizce sürüm esas alınır.İngilizce sürümü görüntüle →
Solana işlemi, atom şeklinde yürütülen bir talimat listesidir. İşlem yapısını anlamak — talimatlar, hesaplar, imzalayanlar, bilişim bütçesi — Raydium ile herhangi bir şey inşa etmek, hata ayıklamak veya optimize etmek için ön koşuldur. Bu sayfa yapıyı, onu sınırlayan limitleri ve iki ücret kategorisinin (Solana ağ ücretleri, Raydium protokol ücretleri) gerçek bir swapda nasıl toplandığını kapsar.

İşlem anatomisi

Solana işleminin üç temel bileşeni vardır:
  • Message: talimatların sıralı listesi, referans aldıkları hesaplar ve son blockhash.
  • Signatures: imzalayanlar başına bir tane, işlemin yetkilendirildiğini doğrular.
  • Recent blockhash: işlemin yakın zamanda yapıldığını ispatlar; eski blockhash’e sahip işlemler (>150 slot eski) reddedilir.

Talimatlar

Bir talimat belirtir:
  • program_id — çağırılacak program.
  • accounts — programın erişebileceği hesaplar (ve bunların yazılabilir/imzalayan bayrakları).
  • data — program tarafından yorumlanan opak baytlar.
Tek bir işlem birden fazla talimat içerebilir. Bunlar sırayla yürütülür; herhangi biri başarısız olursa, önceki talimatların tümü geri alınır (atomik). Tipik bir Raydium swap işlemi şunları içerir:
  1. ComputeBudget::SetComputeUnitLimit — varsayılan CU limitini yükseltin.
  2. ComputeBudget::SetComputeUnitPrice — öncelik ücreti belirleyin.
  3. İsteğe bağlı CreateAssociatedTokenAccount — kullanıcı birinin olmadığı takdirde çıkış ATA’sı oluşturun.
  4. Raydium::SwapBaseInput — swapı yürütün.
  5. İsteğe bağlı CloseAccount — sarılmış SOL ATA’sını kapatın.
SDK bu işlemleri raydium.trade.swap() aracılığıyla otomatik olarak paketler.

İşlemlerdeki hesaplar

İşlemdeki herhangi bir talimat tarafından dokunulan her hesap, işlemin hesap anahtarları listesinde bulunmalıdır. Her hesap şu şekilde işaretlenir:
  • İmzalayan / imzalayan olmayan: hesap sahibi işlemi imzalamalı mı?
  • Yazılabilir / salt okunur: işlem hesabı değiştirebilir mi?
Çalışma zamanı bu bayrakları uygular: bir programı yazılabilir olmayan hesaba yazmaya çalışırsa başarısız olur ve çalışma zamanı gerekli imzalayanları kaçıran işlemleri reddeder. CPMM swapı için hesap listesinin ~13 girişi vardır (bkz. solana-fundamentals/account-model). Birden fazla tick dizisi geçişine sahip CLMM swapları 20+ olabilir.

İşlem boyutu limiti

Solana işlemleri imzalar, mesaj ve başlıklar dahil olmak üzere 1232 bayt ile sınırlandırır. Bu, karmaşık işlemler için tek en yaygın engeldir — Raydium’un multi-hop yönlendirmeli CLMM’si düzenli olarak bu limite karşı çıkar. Tipik ~1000 baytlık Raydium swapının dağılımı:
BileşenBoyut
İmza64 B
İmza sayısı1 B
İleti başlığı3 B
Blockhash32 B
Hesap anahtarları (13 × 32 B)416 B
Talimatlar (4 × ~100-150 B)400–600 B
Toplam~900–1100 B

Address Lookup Tables (ALT)

ALT’ler bir işlemin 32 baytlık tam genel anahtar yerine yayımlanmış bir tabloya 1 baytlık bir dizin ile hesaplara başvurmasını sağlar. Bu bir işlemi önemli ölçüde sıkıştırır:
  • Doğrudan 20 hesaba başvuran bir işlem: ~640 B genel anahtarlar.
  • ALT kullanan aynı işlem: ~20 B dizinler + ALT referansları.
Raydium mainnet’teki CPMM/CLMM swap yolları için ALT’leri korur. SDK bunları otomatik olarak kullanır. Multi-hop rotalar oluşturan toplayıcılar bunlara yoğun şekilde dayanır.
import { VersionedTransaction } from "@solana/web3.js";

// SDK, ALT referanslarıyla v0 (versioned) tx oluşturur
const { transaction } = await raydium.trade.swap({ /* ... */ });
// transaction bir VersionedTransaction'dır, legacy Transaction değil.

Bilişim bütçesi

Her işlemin bir compute unit (CU) bütçesi vardır. Aşması yürütmeyi sonlandırır ve işlemi başarısız kılar.
  • Varsayılan: işlem başına 200.000 CU.
  • Maksimum: işlem başına 1.400.000 CU (ComputeBudget::SetComputeUnitLimit aracılığıyla yükseltilir).
  • Blok başına tavan: blok başına 48 milyon CU (protokol seviyesi).
Tipik Raydium CU tüketimi (tam tablo için integration-guides/priority-fee-tuning bkz.):
TalimatCU
CPMM swap~140.000
CLMM swap (tick geçişi yok)~170.000
CLMM swap (4 tick geçişi)~320.000
Farm v6 stake~130.000
CPMM havuz oluşturma~250.000
Her zaman ComputeBudget aracılığıyla açık bir CU limiti belirleyin; aksi takdirde 200k varsayılanını alırsınız, bu çoğu Raydium talimatı için çok düşüktür.
import { ComputeBudgetProgram } from "@solana/web3.js";

tx.add(
  ComputeBudgetProgram.setComputeUnitLimit({ units: 300_000 }),
);
CU limitinizi çok düşük ayarlarsanız, işlem kapa ulaştığında başarısız olur; çok yüksek ayarlarsanız, tıkanıklık altında deprioritize edilme riski taşırsınız (ve fiyatlandırma modeline bağlı olarak, hiçbir zaman kullanmadığınız bilişim için ödeme yaparsınız).

Öncelik ücretleri

Temel işlem ücreti (imza başına 5000 lamport) ötesinde, doğrulayıcılar giderek öncelik ücretleri ödeyen işlemleri önceliklendiriyor: mikro lamport cinsinden CU başına bir bahşiş.
priority_fee = compute_unit_price (mikro-lamport) × compute_unit_limit
Örnek: 10.000 µL/CU × 300.000 CU = 3.000.000 µL = 0,003 SOL. Öncelik ücretleri yereldir — yalnızca bir blok içinde sıralamayı etkilerler; dahil edilme vs. edilmeme şansınızı iyileştirmezler. Makul bir öncelik ücreti belirlemek tıkanıklık sırasında önemlidir.
tx.add(
  ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 10_000 }),
);
Bunu dinamik olarak nasıl boyutlandıracağınız için integration-guides/priority-fee-tuning bkz.

Talimat sayısı ve hesap sayısı limitleri

1232 baytlık toplam limitin ötesinde:
  • İşlem başına maksimum hesap: 128.
  • Talimat başına maksimum hesap (CPI): 64.
  • İşlem başına maksimum talimat: hiç sınırı yok, yalnızca boyut sınırı ile sınırlandırılmış.
  • Maksimum CPI derinliği: 4 (bir program başkasını çağırabilir, bu da başkasını çağırabilir, 4 seviye derin).
Birden fazla tick dizisini geçen Raydium CLMM swapları hesap limitine karşı sıkı şekilde çıkabilir — tek bir swap havuza, giriş/çıkış kasalarına, giriş/çıkış ATA’larına, birkaç tick dizisine, muhtemelen bir transfer-hook programının ek hesaplarına ve zorunlu bilişim bütçesi / sistem / token program referanslarına dokunur. Raydium’u CPI aracılığıyla oluşturan tasarımlar (örn. otomatik bileşenler) bunu dikkate almalıdır.

Raydium swapında ücret kategorileri

Bir kullanıcı swap işlemi iki kategorideki ücretleri öder:

Solana ağ ücretleri

Doğrulayıcılara SOL cinsinden ödenir.
  • Temel imza ücreti: imza başına 5000 lamport. Neredeyse her zaman 1 imza = 0,000005 SOL.
  • Öncelik ücreti: CU-fiyatı × CU-limit mikro lamportlarda. Tıkanıklığa göre değişir; integration-guides/priority-fee-tuning bkz.
Bu ücretler doğrulayıcılara gider, Raydium ile ilgisizdir ve başarısız işlemler için de alınır (bazı öncelik ücreti uç durumları dışında).

Raydium protokol ücretleri

Swap miktarından düşülür.
  • Swap ücreti: giriş yüzdesi (CPMM %0,25 tipik, CLMM %0,01–%1 katman başına). LP’ler ve protokol hedefleri arasında bölünmüş. Bkz. ray/protocol-fees.
Bu ücretler Raydium’un muhasebesi içindir — kullanıcı bunları sıfır ücreti havuzun üreteceğinden daha küçük bir çıkış miktarı olarak görür.

Örnek: CPMM %0,25 katmanı aracılığıyla $1000 USDC → SOL

Ücret kategorisiMiktarGider
Temel imza ücreti0,000005 SOL (~$0,0007)Doğrulayıcı
Öncelik ücreti (10k µL × 300k CU)0,003 SOL (~$0,45)Doğrulayıcı
CPMM swap ücreti (%0,25)$2,50LP’ler + protokol
Toplam kullanıcı maliyeti~$2,95
Slippage (fiyat etkisi + pazar hareketi) bir ücret değildir ancak aynı sonucu etkiler.

Versioned işlemler

Solana’nın iki işlem biçimi vardır:
  • Legacy: orijinal biçim, ALT desteği yok.
  • v0 (Versioned): ALT’leri destekler, gelecek sürümlere genişletilebilir.
Tüm modern Solana araçları v0 kullanır. Raydium SDK varsayılan olarak v0 işlemleri yayınlar.
// Doğrudan v0 tx oluşturma
import { VersionedTransaction, TransactionMessage } from "@solana/web3.js";

const msg = new TransactionMessage({
  payerKey:        owner.publicKey,
  recentBlockhash: blockhash,
  instructions:    [ /* ... */ ],
}).compileToV0Message([lookupTableAccount]);

const tx = new VersionedTransaction(msg);
tx.sign([owner]);

Blockhash tazeliği

Bir işlem son ~150 slot (~60 saniye) içinden bir blockhash içermelidir. Bu pencere ötesinde, doğrulayıcılar onu reddederler. Yeniden deneme döngüleri için her yeniden denememde taze bir blockhash alın:
async function sendWithRetry(tx, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    const { blockhash, lastValidBlockHeight } = await connection.getLatestBlockhash();
    tx.message.recentBlockhash = blockhash;
    tx.sign([owner]);
    try {
      return await connection.sendRawTransaction(tx.serialize());
    } catch (e) {
      if (i === maxRetries - 1) throw e;
    }
  }
}
Artan ücret yeniden deneme paterni için integration-guides/priority-fee-tuning bkz.

Paralel yürütme

Solana, çok çekirdekli doğrulayıcılarda çakışmayan işlemleri paralel olarak yürütür. Her iki işlem de aynı hesabı yazarsa çakışırlar. Raydium için çıkarımlar:
  • Aynı havuzdaki iki swap paralel olarak yürütülemez — her ikisi de havuz durumunu yazar.
  • Pool A’daki bir swap ve Pool B’deki bir swap, hesap listeleri çakışmazsa paralel olarak yürütülür.
  • Salt okunan bir işlem aynı hesapta bir yazara hiçbir zaman engel olmaz (salt okunan kendisiyle eşzamanlıdır ancak yazma ile değil).
Bu, Solana’nın tek havuz serileştirmesine rağmen yüksek DEX verimini sürdürebilme nedenidir.

İşlem onay seviyeleri

Bir işlem gönderirken bir onay seviyesi seçersiniz:
SeviyeBeklemeSon halya
processed~400 msSonlandırılmadı; geri alınabilir
confirmed~1 sÇoğunluk oyladı
finalized~13 sÇoğunluk köklendi
Swap UX’i için confirmed standarttır. Büyük değeri işleyen işlemler için (havuz oluşturma, ödül doldurma), finalized daha güvenlidir.
await connection.sendAndConfirmTransaction(tx, [owner], {
  commitment: "confirmed",
});

Simülasyon

Solana, gönderilmeden önce bir işlemi simüle etmeyi destekler:
const sim = await connection.simulateTransaction(tx);
console.log(sim.value.logs);
console.log(sim.value.unitsConsumed);
Raydium SDK, seçilen rotanın gerçekten başarılı olduğunu doğrulamak için getBestSwapInfo hesaplarken içeride simülasyon kullanır. Simülasyon ücretsiz değildir — RPC kapasitesi tüketir — ancak ücretini ödemeden önce hataları yakalar.

İşaretçiler

Kaynaklar: