TRON hesabı aktif değil: neyi engeller ve nasıl açılır
Ağ bir adres için hesap tutana kadar o adres yalnızca bir anahtar çiftidir. «TRON hesabı aktif değil» durumunun tamamı budur ve insanları şaşırtan yanıt da budur: adres kurallı yazılmıştır, cüzdan onu gösterir, QR kodu okunur ve zincir onu hiç duymamıştır. Bir ödeme masası için bu durum iki ayrı yerde ortaya çıkar — gönderim yapan cüzdanda ve ödeme yapılan adreste — ve yalnızca biri bir reddir.
Aktivasyon aslında nedir
Bir TRON adresi, çevrimdışı olarak bir anahtar çiftinden türetilir. Oluşturulurken hiçbir yere kayıt düşülmez; ağ da onu ancak bir işlem ona ait bir hesap kaydı oluşturduğunda öğrenir. Bizim kontrolümüz bu konuda birebir davranır: bir düğüme adresin arkasındaki hesabı sorarız ve boş bir yanıt, activated: false demektir. «Bulamadık» değil, «yeni görünüyor» da değil — orada hesap yoktur.
Bir hesabın olağan yoldan var olması, gelen bir TRX transferiyle olur: adrese TRX gönderirsiniz, ağ da o transferi yürütürken hesabı oluşturur. Hesap açmak bedava değildir. Bunun ne tuttuğu, bir sayfaya basılmaya değer bir rakam değil bir zincir parametresidir; o yüzden onu bir yıl bayatlamış olabilecek herhangi bir yerden değil ağdan okuyun. Burada önemli olan, bunun tek bir olağan işlem olması ve sonrasında adresin diğerleri gibi bir hesap hâline gelmesidir.
Neyi engeller: gönderim yapacak cüzdanı
Enerji bir hesaba devredilir; hesap yoksa devredilecek bir yer de yoktur. Reddin tamamı budur. Böyle bir cüzdanı from olarak anan mode A ya da mode C siparişi, details.reason alanı inactive_wallet olan bir 422 invalid_address ile döner; yanında da details.index — toplu işin hangi transferi olduğu — ve details.address gelir. Bu, bir ödeme masasının tekrar tekrar karşılaştığı dört başarısızlıktan biri ve bir siparişin fiyatlamak yerine doğrudan geri çevirdiği ikisinden biridir.
Bu reddin, işleyicisi yazılmadan önce önem taşıyan üç özelliği var.
Idempotency-Key anahtarını harcamaz. Bu ailedeki retlerin hiçbiri harcamaz: istek kurallıdır, biz onu yalnızca o adreslerle kabul edemeyiz. Cüzdan var olduktan sonra, aynı anahtar ve bayt bayt aynı gövde bir çakışma değil geçerli bir yinelemedir; dolayısıyla sizin tarafınızda yeniden türetilmesi gereken hiçbir şey yoktur.
Yanıt önbellekten verilmez. Adres durumu burada önbelleğe alınır, ama bir sipariş bu yüzden geri çevrilmeden önce aktivasyon önbelleğin dışından yeniden okunur — saniyeler önce aktive edilmiş bir cüzdan, bir kaydın süresi dolduğunda değil hemen kabul edilir. Hemen yineleyin; beklenecek bir şey yok.
Mode B'de böyle bir ret yoktur. Orada işlem, gönderen adresin sahibi tarafından zaten imzalanmış olarak gelir; hesap kuruluşu gereği oradadır ve bu kontrol, kendi kendini yanıtlamış bir soruyu sormak olurdu.
Aktif olmamak bozuk olmak değildir
İki yanıt aynı hata kodunu taşır ve birbirinin tersini anlatır. Hiç details.reason taşımayan 400 invalid_address, adres metninin biçimiyle ilgilidir: bu bir TRON adresi değildir ve zincirde olacak hiçbir şey onu adres yapmaz. details.reason taşıyan 422 invalid_address ise gayet düzgün bir adresin durumuyla ilgilidir ve tek bir işlem bunu düzeltir. İkisine aynı davranan bir işlem hattı, birincisini sonsuza kadar yineler, ikincisini bırakır; bu yüzden dallanmayı, ikisinin ortak olduğu hata kodu üzerinden değil details.reason alanının varlığı üzerinden yapmaya değer.
Ne tutar: ödeme yapılan adres
Alıcı tarafında hiçbir şey geri çevrilmez; aktive edilmemiş bir alıcı bir fiyattır. USDT bakiyesi olmayan bir adrese yapılan transferin, jetonları taşımanın yanı sıra alıcının jeton hesabını da açması gerekir; bu da zaten USDT tutan bir adres için gereken yaklaşık 65,000 birime karşılık yaklaşık 131,000 birim enerji ister (ikisi neden farklı). Protokol oranıyla bu, 6.5 TRX yerine 13.1 TRX yakmak demektir ve yeni müşterilere yapılan bir ödeme turunda toplu işin çoğu aynı anda bu durumda olabilir — o enerjiyi kiralamanın ne tuttuğu piyasayla birlikte hareket eder, yakma etmez.
Burada iki soru birbirinden ayrılır ve adlar karıştırmaya davetiye çıkarır, o yüzden tam olun. activated, ağın o adres için bir hesabı olup olmadığını sorar. holds_usdt, adresin USDT bakiyesinin sıfırın üstünde olup olmadığını sorar. Fiyat ikincisini izler: adres USDT tutmuyorsa, aktive edilmiş olsun olmasın, kind double olur. inactive_recipient uyarısı ise birincisini izler. Böylece yıllar önce aktive edilmiş ama hiç USDT ile ödeme almamış bir adres hiçbir uyarı taşımaz ve yine de double fiyatlanır; hiç aktive edilmemiş bir adres ise USDT tutuyor olabilir — bir TRC-20 bakiyesi jeton sözleşmesinin kendi deposunda yaşar, dolayısıyla gelen bir transfer bir hesap değil bir bakiye oluşturur — ve o adres hem single fiyatlanır hem de aynı anda inactive_recipient uyarısı alır. Bir adres ikisine farklı yanıt verene kadar bunlar tek bir soru gibi görünür.
Bir adresi kontrol etmek, beş yüz adresi kontrol etmek
Tek bir adres için GET /v1/address-check bu iki soruyu ve iki tanesini daha tek çağrıda yanıtlar: activated, holds_usdt, blacklisted, is_contract ve bunlardan çıkan expected_kind.
Toplu iş için POST /v1/estimate 500 transfere kadar alır ve hiçbirini geri çevirmez — fark ettiği her şey, bir siparişi durduracak bulgular dâhil, kalemin üzerinde warnings olarak döner. Alıcılar her zaman incelenir. Gönderen ise yalnızca siz bir tane adlandırırsanız incelenir: bir tahmin kaleminde from isteğe bağlıdır, hiçbir fiyatı değiştirmez ve satın aldığı tek şey yanıttır. Oradaki inactive_sender, bir siparişin 422 olarak bildirdiği bulgunun aynısıdır; yalnızca ortada kaybedilecek bir şey yokken gelir.
POST /v1/estimate
{"transfers":[{"from":"TN3W…","to":"TMu1…"}]}
# bir kalemin taşıyabileceği warnings: blacklisted, inactive_recipient,
# contract_recipient, inactive_sender, blacklisted_sender
İki çağrı da ne bir şey ayırır ne de bir şey tahsil eder; dolayısıyla bir liste, hız limitlerinin izin verdiği sıklıkta taranabilir. İkisinin de provasını yapmadığı şey, her modda gerçek para harcayan siparişin kendisidir.
Çözüm
Adrese biraz TRX gönderin, o işlemin onaylanmasını bekleyin ve siparişi aynı anahtar ve aynı baytlarla yineleyin. Kayıt adımı yok, başvuru yok, bize ikinci bir çağrı da yok. Yazılmaya değer tek sıralama kuralı şu: cüzdanın, transferden önce değil siparişten önce var olması gerekir; enerji bir hesaba teslim edilir, dolayısıyla onu alacak hesabın orada olması şarttır.
Aynı koşul, dolu tutulmasını istediğiniz bir cüzdan için de geçerlidir. Bir Auto-refill kuralı, aktive edilmemiş bir adreste aynı gerekçe sözcüğüyle, bir sözleşme adresinde ise contract_wallet ile geri çevrilir — bir sözleşmenin enerji tüketimi başka türlü işler ve kuralın boyutlandıracağı bir şey yoktur. Önce aktive edin, sonra kuralı kurun.