SSP'de SPL Token'ları ve Token Hesapları

Ethereum'da ERC-20 token kullandıysanız, Solana'nın token modeli otuz saniye kadar tanıdık gelir, sonra anlam vermeyi bırakır. Ethereum'da bir token sözleşmesi kimin neye sahip olduğunun defterini tutar ve adresiniz o defterde bir satır olarak görünür. Solana'da adresiniz token'ın kayıtlarında hiç geçmez. Onun yerine, o belirli token'daki bakiyenizi tutmak üzere ayrı bir hesap oluşturulur — size ait, ama ana adresinizden farklı.

Bu tek tasarım kararı, insanların SPL token'larında karşılaştığı hemen her sürprizi açıklar: bir token'ı yeni birine göndermenin neden onu zaten tutan birine göndermekten pahalı olduğunu, bir cüzdanın o token'a hiç dokunmamış bir adres için neden sıfır bakiye gösterebildiğini ve ondalık basamakların burada neden her yerdekinden daha çok önem taşıdığını. Bu yazı, modeli SSP'nin uyguladığı biçimiyle adım adım ele alıyor.

Solana neden her token için ayrı bir hesaba ihtiyaç duyar

Solana'nın temel kuralı şudur: her şey bir hesaptır ve her hesabın bir sahibi, bir boyutu ve o boyutla orantılı bir kira teminatı vardır. Kullanıcılar arttıkça sessizce büyüyen dahili bir eşleme tutan sözleşme diye bir şey yoktur — depolama bir yerde, bir hesabın içinde durmak zorundadır ve bunun bedelini birinin ödemesi gerekir.

Bu yüzden SPL Token programı işi böler. Mint hesabı token'ın kendisine dair olguları tutar: toplam arz, ondalık basamaklar ve kimin yeni basabileceği. Her sahip kendi token hesabını alır: tek bir mint için tek bir bakiye kaydeden ve bir sahip belirten, sabit boyutlu küçük bir hesap. SOL bakiyeniz adresinizde yaşar; USDC bakiyeniz ise adresinizin kontrol ettiği bir token hesabında.

Bu tasarımın artısı öngörülebilirliktir — her token bakiyesi aynı biçimdedir ve saklaması aynı maliyeti taşır. Bedeli ise, yeni bir token tutmanın yeni bir hesabı var etmeyi gerektirmesidir. Özet yerine spesifikasyon istiyorsanız Solana'nın token belgeleri birincil kaynaktır.

İlişkili token hesabı ve bedelini kimin ödediği

Her sahibin bir token hesabına ihtiyacı varsa ve hesapları herkes oluşturabiliyorsa, kişi ve mint başına birden çok token hesabıyla ve hangisine göndereceğinizi bilmenin bir yolu olmadan kalırdınız. İlişkili token hesabı — ATA — bunu çözen kuraldır: verili bir sahip ve verili bir mint için, ikisinden deterministik olarak türetilen tek bir kanonik adres vardır. Cüzdanlar bunu hesaplayabilir, dolayısıyla kimsenin yayımlamasına gerek kalmaz.

İşin püf noktası kiradır. Bir token hesabı yaklaşık 165 bayttır; bu da hesap var olduğu sürece kira teminatı olarak tutulan yaklaşık 0,002 SOL eder. Bu teminat hesap kapatıldığında geri alınabilir, ama peşin ödenmesi ve SOL'ü olan biri tarafından ödenmesi gerekir — ki ilk kez token alan kişide tanımı gereği SOL bulunmayabilir.

SSP bunu diğer tüm Solana ücretlerini ele aldığı gibi ele alır. ATA'sı bulunmayan birine SPL token gönderdiğinizde, işlem bunu oluşturacak idempotent bir komut içerir ve kirayı SSP'nin paymaster'ı öder. Kasanız paymaster'a aynı işlemin içinde geri ödeme yapar; yeni bir alıcıya yapılan o ilk transferin, aynı kişiye yapılan tekrar transferden yaklaşık 0,0025 SOL pahalı olmasının sebebi budur. Burada önemli sözcük "idempotent"tir: hesap zaten varsa komut başarılı olur ve hiçbir şey yapmaz; tüm transferi düşürmez.

Bu oluşturma komutunun multisig teklifinin dışında durduğuna dikkat edin. Birinin token hesabını oluşturmak sizin paranızı hareket ettirmez ve kasanızdan yetki gerektirmez; dolayısıyla iki cihazınızın imzaladığı bölüme ait değildir. Paranızı gerçekten hareket ettiren geri ödeme ise teklifin içindedir.

SSP kutudan çıktığı hâliyle neyi destekler

SSP; yerel SOL, Circle'ın resmî USDC mint'i ve Solana üzerindeki FLUX ile gelir. Kasanızda beliren diğer SPL token'lar da çözümlenip bunların yanında gösterilir.

Bilinçli bir sınırı açıkça söylemekte fayda var: SSP'nin Solana transferleri klasik SPL Token programı üzerine kurulur. Transfer hook'ları, gizli transferler ve başka uzantılar taşıyan yeni program Token-2022 ile ihraç edilen token'lar bugün gönderim yolunun parçası değildir. Bu bir gözden kaçırma değil, kapsam kararıdır: Token-2022 uzantıları bir transferin ne yaptığını değiştirebilir ve bunları desteklemek, her uzantıyı aşağıda anlatılan cihaz üzerinde çözümleme güvencelerine karşı denetlemek demektir.

Bir token transferi gerçekte nasıl kurulur

SSP'den bir SPL token gönderdiğinizde, imzalanan işlem sırasıyla şunları içerir:

1. Gerekirse alıcının ATA'sını oluştur — idempotent, paymaster öder, teklifin dışında.
2. TransferChecked — bakiyeyi kasanızın token hesabından alıcınınkine taşır, kasa tarafından yetkilendirilir.
3. Paymaster'a geri öde — kasanızdan yapılan düz bir SOL transferi, teklifin içinde.

Hepsi tek bir atomik işlem olarak iner. Ayrı bir onay adımı, zincirde bekleyen bir teklif ya da alıcının hesabının oluşturulup transferin gerçekleşmediği bir ara durum yoktur. Ya tamamı yürür ya da hiçbiri.

Kaynak hesap, kasanızın kendi ATA'sıdır — aynı deterministik yolla, kasanın program adresi sahip olacak biçimde türetilir. Kasa bir anahtar çifti değil, programdan türetilmiş bir adres olduğu için türetme, ed25519 eğrisi dışında kalan bir sahibi açıkça kabul eder. Kasa adresinin neden böyle çalıştığına dair alttaki ayrıntıyı isterseniz, kendi kendini başlatan Solana multisig bunu ele alıyor.

Ondalık basamaklar imzanın parçasıdır

Yavaşlamaya değen kısım burası, çünkü bir token'ın size yalan söyleyebileceği yer burasıdır.

Bir mint, token'ının kaç ondalık basamak kullandığını beyan eder. USDC altı kullanır; birçok token dokuz kullanır; kural yoktur. Bir cüzdan "100 USDC" gösterip de transferi yanlış ondalık varsayan bir ham birim sayısı üzerinden kurarsa, bin kat fazla gönderip ekranda hiçbir tuhaflık görmeyebilirsiniz.

SSP, düz transfer komutu yerine TransferChecked kullanır. Fark şu: TransferChecked mint adresini ve ondalık baytını doğrudan imzalanan komut verisine gömer. Buradan üç ayrı kontrol doğar:

• Eklentiniz baytları çözer ve gösterdiği şeyle karşılaştırır.
• SSP Key aynı baytları telefonunuzda bağımsız olarak çözer ve eklentinin verdiği token meta verisiyle karşılaştırır.
• Zincir üstündeki SPL Token programı, komuttaki ondalıkları mint'in gerçek ondalıklarıyla karşılaştırır ve farklıysa işlemi reddeder.

Üçüncü kontrol, lafla aşılamayacak olandır. Sahip olduğundan farklı ondalık iddia eden bir mint yanlış bir transfer üretmez — başarısız bir işlem üretir.

Token almak

Almak daha basittir, tek bir incelikle. Gönderene cüzdan adresinizi verin — SSP'nin alma ekranında gösterdiği adresi — bir token hesabı adresini değil. Ne gönderiyor olurlarsa olsunlar, doğru ATA sizin adresinizden ve mint'ten türetilir ve gerekirse gönderenin cüzdanı onu oluşturur.

Kasanız o token'ı hiç tutmadıysa, ilk transfer gelene kadar hesap var olmaz ve kirasını size gönderen kişi öder. Bu normaldir ve sizden bir şey gerektirmez. Ancak şu anlama gelir: size vaat edilmiş ama henüz ulaşmamış bir token için blok gezgini hiçbir token hesabı göstermez — bu, henüz var olmayan bir hesaptır, kaybolmuş bir transfer değil.

Sık yapılan hatalar

Cüzdan adresi yerine token hesabı adresine göndermek. Bazı gezginler ATA'yı öne çıkarır. Bir token'ı sahibine değil de token hesabına yollamak, Solana'da para kaybetmenin iyi bilinen yollarından biridir. SSP sahibin cüzdan adresini bekler ve gerisini kendisi türetir.

Cüzdanınızda göründüğü için tanımadığınız bir token'ı güvenli saymak. Herkes bir mint oluşturup size gönderebilir ve mint'ler gerçek token'ları taklit eden adlar taşıyabilir. Bir token'ın kasanızda belirmesi bir onay değildir. Bir bakiyeyi gerçek değer saymadan önce mint adresini resmî bir kaynakla doğrulayın.

Ethereum tarzı onaylar beklemek. SPL token'larında bir vekil (delegate) mekanizması vardır, ama ERC-20 onaylarını süreğen bir riske dönüştüren kalıcı izin deseni, Solana uygulamalarının çoğunun kurulduğu yol değildir. Ethereum'dan geliyorsanız, token onayları: verip durduğunuz izinler unutmakta olduğunuz alışkanlığı anlatıyor, SSP'de Ethereum ise karşılaştırmayı veriyor.

İlk gönderim farkını unutmak. Yeni bir alıcıya yapılan ilk transferdeki fazladan ~0,0025 SOL kiradır, SSP'nin tahsil ettiği bir ücret değil. Alıcının token hesabında durur ve bir gün o hesabı kapatırsa kendisi tarafından geri alınabilir.

Gerçek bir transferin adım adım mekaniği için SSP ile Solana gönderme yazısına bakın. SSP'nin alttaki kasayı yaratıcısı olmayan bir 2-of-2 multisig içinde nasıl tuttuğu için SSP'de Solana ile başlayın.