Kripto para kullanıcıları arasında yaygın bir inanış vardır: doğru adresi girerseniz, doğru ağı seçerseniz ve ücreti karşılayacak kadar yerel tokenınız varsa, işlem gerçekleşir. Çoğu durumda bu doğru olacaktır.
Ama her blokzincirin kendi gizli kuralları vardır - yalnızca çok özel durumlarda ortaya çıkan kurallar. Ve öyle bir durumda, sizin açıdan her şey doğru yapılsa bile işlem başarısız olabilir.
Tam da bize, takas servisimiz Rabbit.io müşterisinden gelen LTC'yi SOL'a çevirme işlemi sırasında böyle bir şey oldu. Miktar çok küçüktü - 0.0003 SOL'dan az; mevcut fiyatlarla üç sentin altında. Önceki birçok yazımda takaslarda üst limit koymadığımızı belirtmiştim. Evet, sıklıkla son derece küçük miktarları da işliyoruz.
İstenen SOL'u göndermeye çalıştığımızda bir sorunla karşılaştık. Adres doğruydu. Ağ Solana Mainnet'ti. Bakiyemiz yeterliydi. Ücret hesaba katılmıştı. Yine de işlem defalarca başarısız oluyordu.
Açıklama bizim için bile beklenmedikti. Müşteriye anlattığımızda o da önce inanmadı. Bu olay beni şu konuda düşündürdü: farklı blokzincirlerde kaç tane benzer gizli tuzak var?
Araştırmaya karar verdim ve günlük olarak geniş bir yelpazede kripto takasları gerçekleştirmeme rağmen beni bile şaşırtabilecek en ilginç örnekleri derledim.
1. Solana. Yerel SOL İçin Bile "Kira" Ödemek
Neden Bu Sürpriz Oluyor
Birçok kişi Solana'da, daha önce o adreste bulunmamış SPL tokenlerini (USDT, USDC vb.) almak için adresin küçük miktarda SOL'a sahip olması gerektiğini duymuştur. Teknik olarak tamamen doğru sayılmaz, ama içinde bir doğruluk payı vardır.
Her token ayrı bir Associated Token Account (ATA) içinde saklanır ve bu hesabın oluşturulması yaklaşık 0.002 SOL maliyetindedir. Ancak alıcının SOL'u sıfır olsa bile tokenler alınabilir - çünkü ATA'yı oluşturmayı gönderen taraf öder, alıcı değil.
Daha az bilinen şey ise benzer bir gerekliliğin bazen yerel SOL transferleri için de geçerli olabilmesidir. Bizim müşterimizin istediği minik miktarı göndermeye çalıştığımızda tam olarak bu oldu.
Mechanizm Nasıl Çalışıyor
Solana'da bir hesap sadece adresi temsil eden karakter dizisi değildir. O, blokzincirin güncel durumunda saklanan gerçek bir kayıttır. Bu kayıt doğrulayıcı düğümlerin diskinde yer kaplar - ve depolama ücretsiz değildir.
Bu mekanizma "rent exemption" (kira muafiyeti) olarak bilinir. Bir hesabın var olabilmesi için bakiyesinin belirli bir asgari değerin üzerinde olması gerekir - pratikte iki yıllık depolama kira maliyeti kadar.
Bu değer sabit değildir, fakat şu anda temel bir sistem hesabı (normal bir cüzdan) için minimum 890.880 lamport, yani 0.00089088 SOL'dür.
Bir adres henüz zincirde var değilse (bakiyesi sıfırsa), bu eşiğin altında bir miktarla hesabı oluşturmayı deneyen ilk işlem reddedilir.
Bizim durumumuzda tam olarak bu oluyordu. Yepyeni bir adrese yaklaşık 0.0003 SOL gönderiyorduk - gerekli eşiğin yaklaşık üçte biri kadar. Müşterimiz böyle bir kuralın varlığına inanmak istemedi. Ve dürüst olmak gerekirse, Solana'nın resmi dokümantasyonunda bunun açık bir ifadesini bulmakta zorlandık. Bulabildiğimiz tek dolaylı onay, RPC yöntemi getMinimumBalanceForRentExemption açıklamasındaydı; o da bu kuralı ima ediyordu ama açıkça belirtmiyordu.
Burada önemli bir nüans var. Daha önce müşterilere bu tür küçük miktarları birçok kez sorunsuz göndermiştik. Pratik deneyimimize göre Solana istediğiniz kadar küçük meblağların transferine izin veriyor.
Ve bu doğru - ama sadece alıcı hesabı zaten zincirde mevcutsa. Eğer gelen ikinci, üçüncü veya yüzüncü işlemse, adres 1 lamport bile alabilir. Ama bir hesap ilk kez oluşturuluyorsa kira muafiyeti kontrolü uygulanır.
2. XRP Ledger ve Stellar. Adres Var Ama Hesap Yok
Solana'da karşılaştığımız sorun aslında daha geniş bir kalıbın özel bir örneğidir. Bazı ağlarda adres bir kriptografik nesne iken, hesap dağıtık defterde ayrı bir giriştir. Asgari bir başlangıç bakiyesi olmadan hesap basitçe var olmaz.
XRP Ledger'da her yeni hesabın en az 1 XRP rezerv alması gerekir. Ağın erken dönemlerinde bu gereklilik çok daha yüksekti - lansmanda 200 XRP, sonra 50, sonra 20, sonra 10 XRP idi. XRP fiyatı zamanla arttıkça rezerv kademeli olarak şu anki 1 XRP seviyesine düşürüldü.
Bu rezerv hesaba kalıcı olarak kilitlenir. Harcanamaz. İşlem ücretlerini ödemek için kullanılamaz. Bazı XRP Ledger gezginleri toplam bakiye ile kilitli rezervi ayrı gösterir, böylece cüzdan sahipleri ne kadar XRP'nin aslında harcanabilir olduğunu net biçimde görebilir.
Stellar ağı benzer bir mantığı takip eder. Bir adres, minimum bakiyeyi alana kadar defterde var olmaz. Bir Stellar hesabının etkinleşmesi ve çalışır durumda kalması için en az 1 XLM gereklidir.
Belki hatırlarsınız, bir keresinde 1.000 USDC'yi 1 XLM'ye çeviren bir hatadan bahsetmiştim. O makalede anlatılan durum tam olarak bu mekanizmanın bir örneğiydi: bir token işlemi, gönderici doğru şekilde imzalamış olsa bile, alıcının bazı önkoşulları karşılamaması halinde hesaba geçmez.
XRP Ledger ve Stellar'ın ayırt edici bir özelliği de şudur: bir hesap, belirli bir varlıkla etkileşime açık hale gelmedikçe o tokenleri alamaz. Bu geliştiricilerin kasıtlı bir tasarım kararıdır ve avantajları vardır.
Diğer ağlarda balina ve ünlü adresleri genellikle yeni oluşturulan spam tokenlerle dolup taşar; bu da adres sahibinin bunları satın aldığı yanılsamasını yaratır. XRP Ledger ve Stellar'da böyle spam mümkün değildir - çünkü bir varlığı almak önceden yetkilendirme gerektirir.
3. Lightning Network. Likidite Var Ama Rota Yok
Lightning Network, bitcoin göndermek için her transferi blokzincire kaydetmeden kullanılan ödeme kanallarından oluşan bir ağdır. Normal on-chain işlemlerin aksine, bir Lightning ödemesi ağdaki tüm düğümler tarafından doğrulanmaz ve madencilerce bir blokta onaylanmaz. Bunun yerine bir dizi aracılık yapan düğüm aracılığıyla iletilir.
Ve işte burada gözle görülmeyen bir hata sınıfı ortaya çıkar.
Yönlendirme Nasıl Çalışır
Alice'ten David'e Bob ve Carol gibi ara düğümler üzerinden bir ödeme gitmesi için rotanın her segmentinde gerekli yönde yeterli likidite olmalıdır.
Ağ her kanalın toplam kapasitesini bilir, ancak bakiye iki taraf arasında nasıl dağıtılmış bilmiyordur. Bu şu gibi durumlara yol açabilir:
- David’in Carol ile kanalında yeterli inbound likidite vardır.
- Ancak Bob ile Carol arasındaki kanalda neredeyse tüm bakiye Carol tarafında toplanmıştır. Bob ödemeyi onun yönüne iletemez.
Sonuç olarak, Alice'ten David'e olan ödeme "route not found" (rota bulunamadı) hatasıyla başarısız olur - oysa Alice'in yeterli fonu vardır, David ödeme alabilecek aktif bir kanala sahiptir ve ağ grafiğinde formal olarak bir rota mevcuttur.
Gizli Ücret Limiti Tuzakları
Başka özellikle sinsi bir nüans da şudur: LND'de (yaygın kullanılan Lightning node implementasyonlarından biri) varsayılan yönlendirme ücret limiti 0 satoshi olarak ayarlanmıştır.
Bu, düğümün yalnızca tamamen ücretsiz rotaları denemeye çalışacağı anlamına gelir - gerçek ağda pratikte böyle rotalar neredeyse yoktur. Bu varsayılanı hiç değiştirmeyen kullanıcılar, ödeme küçük bir yönlendirme ücreti izin verilse başarılı olacağı halde defalarca "route not found" hatasıyla karşılaşabilirler.
Bu bir kusur değildir. Aksine LND geliştiricileri, kullanıcılar adına hangi maksimum ücreti ödemeye razı olacaklarına karar vermemeyi kasıtlı olarak seçtiler. Eğer pozitif bir limit varsayılan olarak ayarlanmış olsaydı, kullanıcılar daha sonra farkında olmadan yönlendirme ücretleri kesildiğini keşfedebilirdi.
"Route not found" hatasının diğer nedenleri:
- Alıcının düğümü çevrimdışıdır ve kanalları inaktif durumdadır.
- Fatura (invoice) süresi dolmuştur. Lightning faturalarının geçerlilik süresi sınırlıdır, genellikle bir saat civarıdır.
- Miktar çok büyüktür. Büyük ödemeleri yönlendirmek, küçük ödemelerden daha zordur.
- Önceki bir deneme likiditeyi "yapıştırmış" olabilir. Zaman kilitli HTLC sözleşmeleri kanal kapasitesini süresi dolana kadar geçici olarak kilitleyebilir.
Bitcoin'i Lightning Network üzerinden takas ederken tüm bu sorunlarla karşılaşıyoruz. Bunlar geleneksel blokzincir işlemlerine göre sıra dışı görünebilir, ama her birinin bir çözümü vardır. Bu nedenle Rabbit.io'da hem Lightning üzerinden bitcoin gönderebilir hem alabilir, bu tuzaklar konusunda endişe etmeden işlem yapabilirsiniz.
4. USDT ve USDC. Farklı Mimarilerde Kara Listeler
USDT ve USDC merkezi olarak yönetilen stablecoin'lerdir. Akıllı kontratlarında kara liste fonksiyonları vardır: ihraççılar — Tether ve Circle — bir adresi herhangi bir zamanda kara listeye ekleyebilir ve bundan sonra o adresteki tokenlerle işlemler imkansız hale gelebilir.
Bu bilinen bir gerçektir. Daha az bilinen ise USDT ve USDC'deki kısıtlama mekanizmalarının temelde farklı olduğudur ve bu farkın önemli pratik sonuçları vardır.
USDC (Circle): Her İki Taraf da Engellenir
USDC kontratında kara liste kontrolü hem göndericiye hem alıcıya uygulanır. Eğer alıcı adres kara listedeyse, akıllı kontrat işlemi reddeder. Gönderen sadece biraz gaz kaybeder, USDC ise cüzdanında kalır.
Gönderen açısından bu daha güvenli bir modeldir: fonlar donmuş bir adrese kaybolmaz.
USDT (Tether): Sadece Gönderen Engellenir
USDT kontratında (TetherToken) transfer fonu şu kontrolü içerir: require(!isBlackListed[msg.sender]). Bu, sadece gönderenin kara listeye karşı kontrol edildiği anlamına gelir. Alıcı adres transfer sırasında doğrulanmaz.
Pratikte bunun sonuçları şunlardır:
- USDT'yi kara listedeki bir adrese başarıyla gönderebilirsiniz.
- İşlem hatasız gerçekleşir.
- Blokzincir transferi kaydeder.
- Ama fonlar donmuş hale gelir.
Ne alıcı ne de başka kimse daha sonra bu tokenleri hareket ettiremez - kara listedeki bir adresten giden işlemler yasaktır. Sadece ihraççı Tether müdahale edebilir ve destroyBlackFunds fonunu kullanarak kara listedeki adresteki tokenleri fiilen silebilir.
Bu özel durumda doğru yapılandırılmış bir işlemin doğrudan başarısız olmasının daha iyi olduğunu iddia edebilirsiniz. USDC kontratında uygulanan yaklaşım, işlem başarılı olduktan sonra transferin aslında anlamsız çıktığı USDT modeline göre daha şeffaf ve adil görünmektedir.
Önerilerim:
- USDT ile çalışırken, göndermeden önce karşı taraf adresini yaptırım veya kara liste verilerine karşı kontrol edin. Dünü temiz görünen bir adresin durumu yarın en kötü anda değişebilir.
- Mümkünse Tether'in bireysel adresleri dondurma yetkisi olmadığı Liquid blockchain üzerindeki USDT'yi kullanmayı düşünün.
Bununla birlikte, tüm veriler doğru görünse bile USDT transferleri de bazen doğrudan başarısız olabilir. Bu makalenin II. kısmında bu tür vakaları ve Bitcoin, Ethereum ve Tron ağlarındaki daha az bilinen işlem kısıtlamalarını ele alacağım.
II. bölüm tam olarak bir hafta içinde burada yayınlanacak.
