Blog · 4 Kasım 2026

TRON işlemi beklemede, süresi doldu ya da bulunamadı: bir USDT transferi için her biri ne anlama gelir

TRON her üç saniyede bir blok üretir; yani zincirde beş dakika yüz bloktur. Bundan sonra hâlâ beklemede görünen bir USDT transferi dört yerden birindedir: imzalanmış ama hiç yayınlanmamış, bir düğüm tarafından kabul edilmiş ama henüz bir blokta değil, henüz geri döndürülemez olmayan bir blokta ya da zincirde kesinleşmiş ve alıcı platformun hesaba geçirmesini bekliyor. Yol boyunca iki sözcük daha sık karşınıza çıkar: hash'i bulamayan bir blok gezgini ve işlemin süresinin dolduğunu söyleyen bir düğüm. Her birinin kendi çözümü var ve çözümlerden biri, çok erken uygulanırsa, aynı transferi iki kez öder.

Her işlem kendi son tarihini taşır

Blok aralığı protokolün bir sabitidir: 3,000 milisaniye. Öbür sayı işlemin içindedir. Bir cüzdan bir transfer kurarken bir expiration zamanını, imzalanan kısım olan raw_data içine yazar ve her düğüm onu denetler. Son kullanma anı geçmiş bir işlem geri çevrilir; son kullanma anı düğümün uçtaki bloğunun bir günden fazla ilerisinde olan da öyle. Düğümün ikisi için de sözcüğü TRANSACTION_EXPIRATION_ERROR'dır.

İkinci bir alan çifti işlemi yakın bir bloğa bağlar. ref_block_bytes ve ref_block_hash, ağın hâlâ tuttuğu bir bloğu adlandırır ve bir düğüm son 65,536 bloğu, yani yaklaşık 54 saatlik zinciri hatırlar. Bundan eski bir referans ya da bir test ağından alınmış olan, bunun yerine TAPOS_ERROR kazanır. İkisinin de saati işlem kurulduğunda başlar.

«Beklemede» dört şey anlamına gelebilir

İmzalanmış, hiç yayınlanmamış

Bir cüzdan ya da ödeme betiği bir transferi imzalayıp sonra onu hiçbir düğüme vermeyebilir; imzalama ile gönderme arasında bir zaman aşımı ya da çökme olmuştur. Transferin yine de bir hash'i vardır, çünkü hash işlemin kendi baytlarından hesaplanır. Bu, raw_data'nın SHA-256'sıdır ve hiçbir düğüm bir şey görmeden önce de vardır. Günlüklerinizdeki bir hash, transferin kurulduğunu kanıtlar. Onun için «bulunamadı» yanıtı veren bir blok gezgini haklıdır: okuduğu hiçbir düğüm o baytları tutmuyor.

Bir düğümce kabul edilmiş, henüz bir blokta değil

Bir işlemi alan düğüm hemen yanıt verir ve onu, bir blok taşıyana kadar bekleyen işlemler havuzunda tutar. Kabul ile bloğa girme ayrı olaylardır ve kendi sipariş durumlarımız da onları ayrı tutar: müşterinin imzaladığı bir transferi bizim yayınladığımız mode B'de broadcasted, bir düğümün işlemi kabul ettiği anlamına gelir ve henüz bir blok hakkında hiçbir şey söylemez. Üç saniyelik bir zincirde bu durum kısadır. Bir düğüm, hiçbir bloğun hiç taşımadığı bir işlemi de kabul edebilir; genellikle o havuzdan düşürüldüğü için. Böyle bir transfer, son kullanma anı geçtiğinde kesin olarak yok olur.

Bir blokta, henüz geri döndürülemez değil

Zincirin ucundaki en yeni bloklar hâlâ değiştirilebilir. TRON, ucun gerisinde ikinci bir işaretçi tutar: ağın geri döndürülemez saydığı en yeni blok olan son kesinleşmiş blok; bir düğüm ikisini de sunar. Aralarındaki mesafe, bir transferin kesinleşmeden bir blokta ne kadar durduğudur. İki işaretçiyi de herkese açık bir tam düğümden, aynı anda yapılan iki çağrıyla bir kez okuduk.

Blok numaralarındaki aralık ile zaman damgalarındaki aralık, blok başına üç saniyede uyuşur. Mode B kalemlerimiz yalnızca kesinleşmeden sonra confirmed durumuna ulaşır; API referansımız bunu yaklaşık bir dakika olarak verir ve okuma buna uygundur. Bu, TRON'da bir USDT transferinin ne kadar sürdüğüne olağan yanıtı verir: her üç saniyede bir blok ve yaklaşık bir dakika sonra kesinleşme. Bu, tek bir düğümden tek bir okumadır. Aralığın gün boyunca nasıl hareket ettiğini ya da kendi siparişlerimizin teslimattan yayına, bloğa giden sürelerini ölçmedik.

Zincirde kesinleşmiş, henüz hesaba geçmemiş

Bir borsa ya da ödeme işlemcisi bir para yatırma işlemini, kendi belirlediği bir blok sayısından sonra hesaba geçirir. Hiçbir platformun sayısını bilmiyoruz ve bir tane de belirtmiyoruz. Platforma sormadan önce transferin yanında yazan sonucu okuyun. Bir transfer bir blokta olup yine de başarısız olmuş olabilir; ücret harcanmıştır ve hiçbir jeton yer değiştirmemiştir ve o yerde SUCCESS dışındaki her şey bir başarısızlıktır (OUT_OF_ENERGY ne demek ve bir USDT transferinin başarısız olmasının diğer yolları). Kesinleşmiş bir blokta başarılı bir transfer, alıcının adresine ulaşmıştır. Geriye kalan platformun muhasebesidir ve onun desteği bunu hash'ten izleyebilir.

Süresi doldu ne demek ve yeniden nasıl gönderilir

Son kullanma anını geçen bir işlem hiçbir bloğa giremez. Her düğüm onu geri çevirir; bu yüzden aynı imzalanmış baytları yeniden yayınlamak yalnızca bir ret daha toplar. Kurtarma yolu yeni bir işlemdir: transferi taze bir son kullanma anı ve yakın bir bloğa referansla yeniden kurun ve imzalayın.

Yeniden kurmak iki kez ödemez. Hiçbir bloğun taşımadığı bir işlem hiç yürütülmemiştir: hiçbir jeton yer değiştirmemiş ve hiçbir şey yakılmamıştır, çünkü bir transfer enerjisini ve TRX'ini bir blokta çalışırken harcar. Bir işlem bir bloğa girdikten sonra hiçbir düğüm onu ikinci kez çalıştırmaz. Parayı iki kez göndermenin tek yolu, orijinal hâlâ inebilecekken onun yerine geçecek bir işlemi imzalamaktır. Bir düğüm son kullanma anını, saatinizin gerisinde kalabilen uçtaki bloğunun zamanına göre yargılar; bu yüzden son tarihten önceki son saniyelerde üretilmiş bir blok orijinali yine de taşıyabilir ve geride kalmış bir düğüm ya da blok gezgini onu henüz göstermeyebilir. Orijinali kuran yazılım onu elinde tutar ve epoch'tan bu yana milisaniye olarak raw_data.expiration değerini okuyabilir. Son kesinleşmiş blok o anı geçene kadar bekleyin — bu, bizim okumamızda yaklaşık bir dakika daha sürer — ve sonra bir düğüme hash'e göre sorun. Düğüm işlemi hâlâ tanımıyorsa orijinal artık inemez ve yeni transfer tek transferdir.

Bir enerji siparişinde beklemede ve süresi doldu

Kiralanan enerji ikinci bir zamanlayıcı ekler. Bir siparişin enerjisi teslim edildiğinde sipariş send_before taşır: kiralamanın üç saniye eksiği — beş dakikalık kiralamada 297 saniye, saatlikte 3,597. Pencere, onaylandığını gördüğümüz devirden sayılır ve zincirdeki kiralama ondan bir blok ve bir sorgulama döngüsü önce başlamıştır; bu yüzden pencerenin son saniyelerini çoktan gitmiş sayın (kiralanan enerji ne kadar sürer). Enerji cüzdandan ayrıldıktan sonra bir bloğa ulaşan bir transfer, gönderenin TRX'ini birim başına 100 sun olan protokol oranıyla yakar; USDT tutan bir adrese yapılan transfer için yaklaşık 6.5 TRX.

Pencere kapandığında ne olacağı, kimin gönderdiğine bağlıdır. Mode A'da transferi kendiniz yayınlarsınız. Ağı izleriz, transferiniz göründüğünde kalemi sent olarak işaretleriz ve order.item.sent webhook'unu, hash'i data.txid içinde olacak biçimde göndeririz. send_before'a kadar hiçbir transfer görünmediyse kalem expired olur ve ücretlendirilir, çünkü enerji teslim edilmiştir.

Mode B'de bize imzalanmış bir işlem verirsiniz ve biz onu enerji iner inmez yayınlarız (mode B nasıl çalışır). Kalem broadcasting ve broadcasted üzerinden confirmed durumuna ilerler; sonuncusu yalnızca kesinleşmeden sonra. send_before'dan sonra asla yayınlamayız: zamanında gönderemediğimiz kalem failed olarak, error: broadcast_window_missed ile kapanır ve rezerv eksiksiz geri döner. Oradaki pencere ayrıca işlemin kendi son kullanma anı eksi yayın için bir pay ile sınırlıdır; bu yüzden bize az ömrü kalmış hâlde ulaşan bir işlem kısa bir pencere alır.

Mode B son kullanma anını girişte de denetler. İşlemi aldığımızda kalan ömrü en az 180 saniye, en fazla 23 saat 59 dakika olmalıdır. Fazla ileride bir son tarih 400 invalid_request ile ve details.reason alanı expiration_too_far olarak, çok az ömür ise aynı 400 ile yalnızca details.index taşıyarak döner. İki yanıt da herhangi bir enerji satın alınmadan önce gelir.

Neye, hangi sırayla bakılır

1. Bir düğümün işlemi hiç kabul edip etmediği. Onu gönderen yazılım düğümün yanıtını tutar ya da yayın hiç olmadığı için hiçbir şey tutmaz. Bir hash tek başına hiçbir şeyi çözmez, çünkü herhangi bir yayından önce de vardır.
2. Hash'in bulunup bulunmadığı: bir blok gezgininde ya da hash'e göre sorulan bir düğümden. Bulunmuyorsa ve son kullanma anı hâlâ ilerideyse aynı imzalanmış baytları yeniden yayınlayın. Son kesinleşmiş blok son kullanma anını geçtiyse ve hash hâlâ bulunmuyorsa yeni bir işlem kurun ve imzalayın.
3. Bulunan bir hash'in yanındaki sonuç. SUCCESS transferin geçtiği anlamına gelir. Başka her şey, çalıştığı ve başarısız olduğu anlamına gelir ve ücret çoktan harcanmıştır.
4. Bloğunun kesinleşip kesinleşmediği. Bizim okumamızda en yeni geri döndürülemez blok uçtan yaklaşık bir dakika geride kaldı; dolayısıyla bundan genç başarılı bir transfer hâlâ yerleşiyor.
5. Alıcı platformun kendi blok sayısı ve ondan sonra, hash ile birlikte, desteği.
6. Bizdeki bir siparişte kalem: mode A'da sent ve txid'si, mode B'de confirmed. Pencere önce kapandığında mode A expired gösterir, mode B ise failed gösterir, error: broadcast_window_missed ile. Mode B'deki bir expired, bir düğümün işlemi kendi yapısı yüzünden geri çevirdiği ya da işlemin bir blokta geri alındığı anlamına gelir ve ücretlendirilir.

Bir kalemin ready'de durup sonra expired olmasını, ortada gerçek hiçbir şey yokken izleyin: test ortamında transferi hiç gelmeyen bir alıcı var →