Bekleyen Ethereum İşlemleri: Nonce, Değiştirme ve İptal

Bir Ethereum işlemini imzaladıktan sonra cüzdanınız bunu bir yürütme istemcisine veya işlem hizmetine gönderebilir. İşlemi kabul eden düğümler eşlerine iletebilir, bir blok önericisi de daha sonra işlemi bir bloğa dahil edebilir. Dahil edilene kadar işlem, kanonik zincir durumunu değiştirmez. Cüzdan veya gezgindeki “beklemede” ifadesi genellikle hizmetin işlemden haberdar olduğu ama onu henüz bir blokta görmediği anlamına gelir; ağ genelinde tek bir kuyruk bulunduğunu göstermez. Ethereum.org işlem kılavuzu, imzalama ve yayından blok dahil edilmesine kadar olan süreci açıklar.

Bir işlem çeşitli nedenlerle bekleyebilir. Ücret üst sınırları bir bloğa dahil edilme koşullarını karşılamıyor olabilir, aynı hesaptan daha önce gönderilen bir işlem hâlâ çözümlenmemiş olabilir, düğüm işlemi almamış olabilir ya da cüzdan eski veya sağlayıcıya özgü bilgiler gösteriyor olabilir. Her neden farklı kontroller gerektirir. Ücreti artırmak yanlış ağ seçimini düzeltmez; ilk işlemi kontrol etmeden başka bir ödeme göndermek ise ikinci bir ödemeye yol açabilir.

“Beklemede” durumu “onaylandı”, “kesinleşti” veya “başarısız” durumundan farklıdır. İşlem makbuzu oluşmadan önce işlem hash’i görünebilir; makbuz işlem bloğa dahil edildikten sonra kullanılabilir. Ethereum blokları daha sonra konsensüs aşamalarından geçer. Cüzdanlar ve gezginler bu etiketleri farklı kullanabileceğinden tek bir kısa duruma güvenmek yerine işlem hash’ini, bloğu, makbuzu ve zincirin güncel durumunu inceleyin.

Sıradan bir Ethereum harici sahipli hesabın (EOA) işlemlerini sıralayan bir nonce değeri vardır. Nonce; ücret, zaman damgası veya benzersiz işlem hash’i değildir, bir sayaçtır. Zincir her hesap için yalnızca hesabın mevcut durumunda beklenen sıradaki nonce’u kullanan işlemi kabul eder. Aynı hesap, kanonik zincirde aynı nonce ile iki işlem yürütemez. Ethereum.org hesap belgeleri, nonce’u hesabın işlem sayacı ve tekrar oynatma koruma mekanizması olarak açıklar.

Bir hesap için sıradaki kullanılmamış nonce’un 41 olduğunu varsayalım. Sıradaki geçerli işlem nonce 41’i kullanır; bu işlem bloğa dahil edilip uygulandıktan sonra gelen işlem nonce 42’yi kullanır. Nonce, hedef adrese değil gönderen hesaba bağlıdır. Her hesabın kendi sırası bulunduğundan iki farklı hesabın aynı anda 41 numaralı bir işlemi olabilir.

Bir işlem, hesabın zincir üzerindeki mevcut nonce’undan ileride bir nonce ile imzalanabilir; ancak yürütme sırasında sırayı atlayamaz. Önce eksik olan daha eski nonce tüketilmelidir. Hesabın zaten tükettiği nonce’u kullanan işlem eskidir ve yeni bir işlem olarak yürütülemez. Bu sıralama, işlemler farklı zamanlarda yayımlansa veya farklı düğümlerden gelse bile ağın her hesabın işlemlerini sırayla işlemesini sağlar.

Nonce kuralı, Ethereum yürütme katmanındaki sıradan EOA işlemleri için geçerlidir. Her cüzdan soyutlamasını, rollup sıralayıcısını veya zinciri evrensel biçimde açıklamaz. Akıllı hesap sistemleri kendi işlem ve nonce kurallarını ekleyebilir; bu konu kılavuzun ilerleyen bölümünde ele alınır.

Ethereum'da her cüzdanın, düğümün, blok gezgininin ve blok önericisinin tamamen aynı biçimde gördüğü tek bir eşzamanlı bekleme odası yoktur. Her yürütme istemcisi, aldığı ve kendi sınırları ile politikalarına göre uygun bulduğu işlemleri yerel bir işlem havuzunda tutar. Bir işlem bir düğümün havuzunda bulunurken diğerinde olmayabilir. Geth txpool RPC belgeleri, bu istemcinin yerel pending ve queued gruplarını gösterir ve aynı gönderen ile nonce için birden fazla işlem bulunabileceğini belirtir.

Geth terminolojisinde pending genellikle hesabın mevcut durumundan başlayarak nonce sırasıyla işlenebilecek işlemleri ifade eder; queued ise bir boşluğun kapanmasını bekleyen ileri nonce'lu işlemleri içerebilir. Bu adlar istemci arayüzüne aittir; tüm Ethereum yazılımlarının göstermesi gereken konsensüs düzeyi durumları değildir. Bir cüzdan onaylanmamış işlemlerinin tamamına “beklemede” diyebilirken bir gezgin yalnızca kendi veri sağlayıcılarının gördüğü işlemleri gösterebilir.

Örneğin bir düğüm nonce 41 ve nonce 43 ile birer işlem biliyorsa 43'ü 42'den önce yürütemez. Düğüm, 42 gelene veya hesap durumu başka bir yolla ilerleyene kadar 43'ü kuyrukta tutabilir. 43'ü hiç almayan başka bir düğüm bu işlemi hiç göstermez. Bu yüzden iki gezgin bir işlemin beklediği veya bulunamadığı konusunda farklı şeyler gösterebilir; tek bir ekran tüm doğrulayıcıların ne gördüğünü kanıtlamaz.

Bazı istemciler aynı gönderen ve nonce için birden fazla onaylanmamış işlem adayı tutabilir. Bunlar sırayla ikisi de uygulanabilen işlemler değil, aynı sıra yerini almak için yarışan seçeneklerdir. Havuz kapasitesi, işlem ömrü ve değiştirme kuralları uygulama politikalarıdır ve yazılım sürümleri arasında değişebilir. Örneğin Geth'in yapılandırılabilir işlem havuzu seçeneklerinde istemciye özgü bir fiyat artışı eşiği bulunur; bu eşik evrensel Ethereum ücret kuralı sayılmamalıdır. Bu seçeneklerin kapsamı Geth komut satırı başvurusunda açıklanır.

Bir hesabın zincir üzerindeki sıradaki nonce'unun 41 olduğunu düşünün. Önce nonce 41 ile A işlemini, ardından nonce 42 ile B işlemini yayımlıyorsunuz. A çözümlenmeden B önce yürütülemez. B yerel bir kuyrukta kalabilir, yalnızca cüzdanda beklemede görünebilir veya kendisine ulaşmayan bir gezginde hiç görünmeyebilir. Önemli olan, cüzdanın işlemleri hangi sırayla oluşturduğu ya da gösterdiği değil, nonce sırasıdır.

A sonunda bloğa dahil edilirse hesabın nonce'u 42'ye ilerler ve B kendi geçerlilik, ücret ve havuz politikası koşullarını da karşıladığı takdirde uygun hâle gelebilir. A, nonce 41 kullanan başka bir geçerli işlemle değiştirilirse, bloğa dahil edilen işlem aynı sıra yerini alır. Hesaptan başka bir işlem nonce 41'i tükettiyse eski 41 adayı geçersizleşir ve artık yürütülemez.

Bu nedenle daha yüksek nonce ile yeni bir işlem göndermek, takılan bir işlemi açmanın genel bir yolu değildir. Yalnızca boşluğun arkasına bir işlem daha ekler. B zaten sonraki işlemse onu iptal etmek de A'yı çözmez. Herhangi bir şeyi değiştirmeden önce hesaptaki en eski çözümlenmemiş nonce'u bulun ve durumunu doğrulayın.

Bir boşluk geçici olabilir veya kalıcı hâle gelebilir. Önceki işlem kontrol ettiğiniz düğüme ulaşmamış, ücreti mevcut koşullara göre cazip ya da yeterli olmayacak biçimde ayarlanmış veya bir düğümün havuzundan çıkarılmış olabilir. Cüzdan, başka bir cihazda oluşturulan kuyruktaki bir işlemi de gösterebilir. Ekran tek başına ne olduğunu söylemez; hesabın onaylanmış nonce'unu, işlem hash'lerini ve birden fazla güvenilir görünümü karşılaştırın.

Nonce sırası ve ücret uygunluğu ayrı kısıtlardır. Doğru sıradaki nonce'u kullanan işlem bile ücret parametreleri bloğa dahil edilme koşullarını karşılamıyorsa bekleyebilir. Daha yüksek nonce'lu bir işlem daha büyük bahşiş teklif ederek öne geçemez. nonce 42'nin ücretini artırmak nonce 41'i ortadan kaldırmaz.

Standart bir EIP-1559 işleminde maksimum ücret, işlemin dahil edileceği bloğun base fee tutarını karşılayabilmelidir; priority fee de blok önericisinin seçimini etkileyebilir. İşlem beklerken hem base fee hem de kullanılabilir blok alanı değişebilir. Maksimum ücret bir üst sınırdır; sınırı yükseltmek belirli bir onay süresini garanti etmez. Ethereum gas ücreti kılavuzu, bu alanları ve efektif ücretin nasıl belirlendiğini açıklar.

Bir düğüm veya cüzdan ek iletim ya da değiştirme kuralları uygulayabilir. Bu politikalar, belirli bir hizmetin neyi kabul edip ileteceğini belirler; hepsi konsensüs kuralı değildir. Örneğin Geth, kendi havuzunda bekleyen bir işlemi değiştirmek için yapılandırılabilir bir fiyat artışı eşiği sunar. Başka bir istemci, sağlayıcı, cüzdan veya yazılım sürümü farklı davranabilir. Hatırladığınız bir yüzdeye ya da sabit bekleme süresine ağ genelinde garanti olarak güvenmeyin.

İşleminiz daha düşük bir nonce çözümlenmediği için bekliyorsa önce bu nonce'u kullanan işlemi belirleyin. Maksimum ücret mevcut base fee koşullarını karşılamadığı için bekliyorsa değişiklik yapmadan önce ücret alanlarını anlayın. Ücret hesabı için Ethereum gas kılavuzuna başvurabilirsiniz; bu yazı ayrı bir konu olan işlem sıralamasına odaklanır.

Cüzdandaki “hızlandır” özelliği genellikle aynı hesaptan, aynı nonce ile ama ayarlanmış ücret parametreleriyle yeni bir işlem oluşturur. Hesap bu nonce için yalnızca bir işlem yürütebildiğinden iki aday birbiriyle çakışır. İlgili işlem havuzları değiştirme adayını kabul edip bloğa dahil ederse bu aday nonce sırasını alabilir; orijinal işlem artık kanonik zincirde onunla birlikte yürütülemez. MetaMask'in bekleyen işlemler kılavuzu, kendi hızlandırma akışını aynı nonce ve daha yüksek ücretle yeniden gönderim olarak açıklar.

Değiştirme işlemi, ücret alanlarını değiştirirken orijinal alıcıyı ve eylemi koruyabilir; ancak varsayımda bulunmak yerine imzalama ekranını inceleyin. Bir cüzdan uygulaması başka alanlar gösterebilir veya özelliği farklı adlandırabilir. Değiştirme işlemini imzalamadan önce gönderen hesabı, nonce'u, hedef adresi, değeri ve sözleşme verilerini doğrulayın. Yeni işlem ne yapacağını değiştiriyorsa bu yalnızca zararsız bir ücret ayarı değildir.

Değiştirme adayının her yerde kabul edilmesi veya hızla bloğa dahil edilmesi garanti değildir. Orijinal işlem zaten bloğa dahil edilmiş olabilir; bir düğüm kendi politikası gereği değiştirmeyi reddedebilir; yeni aday önerici için hâlâ cazip olmayabilir veya hizmet, izlediğiniz düğümlere işlemi iletmeyebilir. Orijinal işlem onaylandıysa tüketilmiş nonce ile başka işlem göndermek onu geri alamaz ve bu işlem genellikle eski nonce nedeniyle reddedilir.

Buradaki “değiştirme”, aynı hesap ve nonce ile gönderilen rakip işlemi ifade eder. Bitcoin'in RBF veya CPFP adımlarını Ethereum'a taşımayın. Bitcoin farklı bir işlem modeli kullanır; ücret artırma yöntemleri Ethereum hesapları için talimat değildir.

İmzalanmış bir Ethereum işlemi yayımlandıktan sonra onu tüm düğümlerden geri çeken protokol düzeyinde bir geri alma komutu yoktur. Bazı cüzdanlar işlem henüz onaylanmamışken iptal seçeneği sunar. Bu seçenek genellikle aynı hesaptan aynı nonce ile başka bir işlem yayımlamaya çalışır; yaygın cüzdan yöntemlerinden biri gönderenin kendi adresine sıfır değerli bir işlem göndermektir. İptal adayı kabul edilip orijinalden önce bloğa dahil edilirse nonce'u tüketir ve orijinal adayın daha sonra yürütülmesini geçersiz kılar. Kesin oluşturma biçimi ve kullanılabilirlik cüzdana bağlıdır.

Orijinal işlem ile iptal adayı yarışabilir. Orijinal önce bloğa dahil edilirse sonradan gönderilen iptal etkileri geri alamaz. İki adaydan hiçbiri kabul edilmez veya bloğa dahil edilmezse nonce çözümlenmemiş kalabilir. Cüzdanda düğmeye basılması ya da başarı bildirimi, iptal adayının yarışı kazandığını kanıtlamaz. Oluşan işlem hash'ini ve kanonik zincir durumunu kontrol edin. MetaMask talimatları iptal girişimini açıkça hâlâ bekleyen işlemlerle sınırlar ve onaylanmış bir işlemin iptal edilemeyeceğini belirtir.

İptal işlemini imzalamadan önce, yerinden etmek istediğiniz işlemle aynı hesap ve nonce'u kullandığını kontrol edin ve cüzdanın gösterdiği tüm alanları inceleyin. İptal adayı bloğa dahil edilirse başka bir ağ ücreti gerekebilir. İptal adayı da bekleyebilir veya ilgili havuz politikaları nedeniyle orijinalin yerini alamayabilir. Cüzdandaki “iptal edildi” ifadesi protokolün işlemi geri aldığı anlamına gelmez; sonucu ancak nonce'u hangi işlemin tükettiğini doğruladıktan sonra belirleyin.

İşlem bir token onayı, sözleşme çağrısı veya transfer gerçekleştirdiyse daha sonra gelen bir işlemi iptal etmek tamamlanmış durum değişikliğini geri alamaz. Bazı sözleşme eylemlerinin ayrıca izlenecek yöntemleri olabilir; bunların varlığı ve sonuçları sözleşmeye bağlıdır. Arayüz iptal olarak adlandırıyor diye bilmediğiniz bir işlemi imzalamayın.

Bloğa dahil edilen bir işlemin blok bilgisi ve makbuzu vardır. Başarılıysa amaçlanan durum değişiklikleri uygulanmış olabilir. EVM yürütmesi revert ile geri alınırsa o yürütmenin durum değişiklikleri geri çevrilir; ancak işlem yine de hesabın nonce'unu tüketir ve gas ücreti doğurabilir. Cüzdan bildiriminden başarı sonucu çıkarmak yerine işlem makbuzunu ve yürütme durumunu inceleyin. Bloğa dahil edilme ile yürütme sonucu arasındaki fark Ethereum.org işlem kılavuzunda ve gas kılavuzunda açıklanır.

“Düşmüş” veya “bulunamadı” etiketi çoğu zaman tek bir cüzdan, gezgin, RPC sağlayıcısı ya da yerel havuzun bildirimidir. Bu, protokolün işlemi iptal ettiğini veya nonce'un serbest olduğunu tek başına kanıtlamaz. Başka bir düğüm işlemi hâlâ biliyor olabilir, cüzdan imzalı işlemi yeniden yayımlayabilir ya da sonraki bir blok hesabın nonce'unun ilerlediğini gösterebilir. Tersine, kontrol ettiğiniz görünümlerde eski işlem yokken hesabın onaylanmış nonce'u değişmemiş olabilir.

Bir işlem hash'i bulunmuyorsa işlemi oluşturan aynı zinciri ve hesabı seçtiğinizi kontrol edin. Hesabın zincirdeki en güncel nonce'unu işlem nonce'u ile karşılaştırın ve gönderenin yakın tarihli işlemlerine bakın. nonce too low yanıtı, sorguladığınız uç noktanın nonce'un tüketilmiş olduğunu düşünüyor olabileceğine işarettir; aynı isteği tekrar tekrar göndermek için neden değildir. Bu nonce'u hangi işlemin kullandığını ve bloğun hâlâ kanonik olup olmadığını doğrulayın.

Zincir yerleşmeden önce kısa süreli bir zincir yeniden düzenlemesi de bloğa dahil edilmiş işlemi etkileyebilir. Cüzdan ve gezginler gözlemleri değiştikçe etiketlerini güncelleyebilir. Önemli bir transferde alıcı hizmetin onay politikasını bekleyin ve gerektiğinde daha güçlü konsensüs kesinliğini izleyin. “Bir blokta görüldü” ile “her koşulda geri döndürülemez” aynı iddia değildir.

Önce doğru zinciri, gönderen hesabı ve işlem hash'ini doğrulayın. Hash'i doğru ağdaki güvenilir bir gezginde arayın. Makbuz olup olmadığını, hangi nonce'u kullandığını, yürütmenin başarılı olup olmadığını ve hesabın daha sonra işlem yapıp yapmadığını kontrol edin. İşlemi kontrol etmek için seed phrase'inizi açıklamayın veya girmeyin; herkese açık zincir verilerine bakmak için genel adres ve işlem hash'i yeterlidir.

Hash görünmüyorsa hesabın en son onaylanmış nonce'u ile cüzdanınızda görünen nonce'u karşılaştırın. Bir geliştirici veya düğüm operatörü, latest ve pending blok etiketlerini kullanarak eth_getTransactionCount sorgusu yapabilir. Ethereum.org'un JSON-RPC başvurusu, latest etiketini en son blok durumuna, pending etiketini ise bekleyen işlem durumuna bağlar. Pending sonucu da RPC uç noktasının görünümüne özeldir; iki sağlayıcıdan alınan değerler farklı olabilir. Çoğu kullanıcı aynı ilk ipuçlarını komut çalıştırmadan cüzdanın hesap hareketlerinden ve güvenilir bir gezginden görebilir.

Ardından henüz tüketilmemiş en düşük nonce'tan başlayın. Orijinal işlem hâlâ görünüyorsa ve cüzdan değiştirmeyi destekliyorsa imzalamadan önce yeni işlemin tüm alanlarını ve ücret ayarlarını inceleyin. Görünmüyorsa ağdan kaybolduğunu varsaymak yerine cüzdana veya RPC sağlayıcısına yeniden yayım ve değiştirme davranışını sorun. Nonce zaten tüketilmişse başka bir şey yapmadan önce bloğa dahil edilen işlemi bulun. Daha ileri nonce'larla tekrar tekrar işlem göndermekten kaçının; ilk boşluğu çözmeden kuyruğu uzatabilir.

Bu adımlar sıradan Ethereum harici sahipli hesap işlemlerini kapsar. Hesap soyutlama sistemleri UserOperation işlemlerini bundler'lar üzerinden gönderebilir ve akıllı hesaplarında tek sayaçtan daha karmaşık nonce anahtarları ile sıra numaraları bulunabilir. EIP-4337, bu işlemlere yönelik nonce yapısını tanımlar; bu nedenle hesap soyutlaması kullanan cüzdanlar yazıdaki EOA örneklerinden farklı davranabilir. Hedef ağlar, adresler ve transfer durumu için kripto transferi kontrol listesi ile devam edin.