Solana (SOL): İşlemler ve Doğrulayıcılar Nasıl Çalışır

Durum hesaplarda yaşar

Kalıcı Solana durumunun her parçası, 32 baytlık bir adresle tanımlanan bir hesapta tutulur. Bir hesap, lamportları, veriyi, bir sahip programını ve yürütmeyle ilgili alanları kaydeder. Sahip, o hesap verisini değiştirmesine izin verilen programdır; bir cüzdan anahtarını kontrol eden kişi olması gerekmez.

Solana programları, sBPF bayt kodu içeren yürütülebilir hesaplardır. Bir program genellikle durumsuz olarak kabul edilir çünkü değişken uygulama durumu, her talimata sağlanan ayrı hesaplarda yaşar. Bu, çalışma zamanının yürütmeden önce bir işlemin hangi hesapları okuyacağını veya yazacağını görmesini ve aynı yazılabilir durum için rekabet etmeyen işleri planlamasını sağlar.

Cüzdanlar, token hesapları ve PDA'lar

Bir cüzdan adresi SOL'ye sahip olabilir ve işlemleri yetkilendirebilir, ancak bir SPL token bakiyesi normalde bir mint ve sahiple ilişkili bir token hesabında bulunur. Bir Program Türetilmiş Adres, bir program ID ve tohumlardan deterministik olarak türetilir; program, adres için özel bir anahtar olmasa bile çalışma zamanı kuralları aracılığıyla onun adına yetki verebilir.

Bir token göndermeden önce, mint'i, hedef token hesabını ve çağrılan programı doğrulayın. Tanıdık bir kısaltma veya cüzdan etiketi, bir mint'in kanonik olduğunun kanıtı değildir. Hesapları kapatmak, oluşturmak veya yeniden tahsis etmek de lamportları taşıyabilir, bu nedenle işlem özeti, başlıktaki token miktarının ötesinde incelenmelidir.

Mesaj, imzalar ve talimatlar

Mesaj, hesap adreslerini, yakın tarihli bir blokhash'i ve derlenmiş talimatları listeler. Her talimat bir programı adlandırır ve kullanabileceği hesapları tanımlar. Gerekli imzalayanlar mesajı yetkilendirir ve sürümlü işlemler, her adresi doğrudan pakete koymadan daha fazla hesaba başvurmak için adres arama tablolarını kullanabilir.

Tazelik ve onay

Yakın tarihli bir blokhash, sıradan bir işlemin süresiz olarak geçerli kalmasını önler. İşlenmeden önce süresi dolarsa, işlem yeniden oluşturulmalı ve yeniden imzalanmalıdır; eski imzayı yeniden yayınlamak yeni bir işlem oluşturmaz. Özel çevrimdışı veya gecikmeli imzalama için dayanıklı nonce iş akışları mevcuttur ve ayrı işlem gerektirir.

RPC istemcileri işlenmiş, onaylanmış ve kesinleşmiş onay düzeylerini gösterir. Hızlı bir arayüz, daha güçlü küme anlaşmasına ulaşılmadan önce işlenmiş sonuçları gösterebilir. Mevduatlar, köprüler ve bağımlı uygulama eylemleri, bu hizmetin gerektirdiği düzeyi beklemeli ve imzayı güncel bir RPC veya gezgin aracılığıyla doğrulamalıdır.

Temel ve öncelik bileşenleri

Her işlem, gerekli imzalar için SOL cinsinden bir temel ücret öder. Protokol SOL'yi lamports cinsinden ifade eder ve bu nedenle temel tutar, bir ödemenin veya token takasının değerine değil, imza sayısına bağlıdır. Başarısız bir işlem, imza doğrulaması ve yürütme denendiği için temel ücreti tüketebilir.

İsteğe bağlı bir önceliklendirme ücreti, istenen hesaplama birimi limitine ve seçilen hesaplama birimi fiyatına dayanır. Limit bir bütçedir, gerçek kullanımın bir tahmini değildir, bu nedenle gerekenden çok daha yüksek ayarlamak öncelik bileşenini fazla ödeyebilir. Cüzdan tahminleri, başka bir uygulamadan sabit bir ücret kopyalamak yerine yakın tarihli koşulları ve işlem simülasyonunu kullanmalıdır.

Operasyonel kontroller

Aktarılan varlık bir SPL token olsa bile ücret için yeterli SOL bulundurun. Hesaplama bütçesi talimatlarını inceleyin, çünkü bunlar istenen limiti ve öncelik fiyatını değiştirebilir. Ayrıca işlem ücretlerini hesap finansmanından, kira ile ilgili bakiyelerden, takas fiyat etkisinden ve uygulama ücretlerinden ayırt edin; bir cüzdan bunları birlikte özetlese bile bunlar ayrı maliyetlerdir.