Ethereum pending və reverted: yoxlama addımları

Pending hələ nəticə deyil, reverted isə nəticədir

Ethereum əməliyyatı pending olduqda adətən bloka daxil edilmiş yekun receipt yoxdur. Reverted əməliyyatda receipt mövcuddur və EVM icranı səhvlə geri çevirib. Birincidə əməliyyat növbəsi araşdırılır, ikincidə contract çağırışının niyə uğursuz olduğu.

İnterfeys hər ikisinə qırmızı xəbərdarlıq verə bilər, lakin eyni addımı tətbiq etmək olmaz. Reverted əməliyyatı gözləməklə düzəlmir; pending əməliyyata isə eyni məzmunlu təsadüfi yeni transfer əlavə problem yarada bilər.

Pending əvvəlcə harada sübut olunur?

Wallet notification əvəzinə hash-i etibarlı Ethereum mənbəyində axtarın, sender address-in confirmed və pending nonce vəziyyətini yoxlayın. Hash yoxdur, lakin eyni nonce ilə başqa transaction görünürsə, ilk namizəd yalnız müəyyən RPC-də qalmış və ya replaced olmuş ola bilər. Hash, nonce, recipient, data, fee və vaxtı saxlayın.

Speed up və cancel necə işləyir?

Speed up adətən eyni nonce və eyni ödəniş niyyəti ilə daha yüksək fee yaradır. Cancel çox vaxt eyni nonce ilə öz address-inizə sıfır value transaction-dur. Hər ikisi mempool-da rəqabət edir; original əvvəl təsdiqlənərsə cancel uğursuz sayılır. Yeni və köhnə hash-ləri birlikdə izləyin.

Bir neçə wallet-də manual nonce dəyişmək queue-nu qarışdıra bilər. Ən aşağı pending nonce-dan başlayın.

Azərbaycandan xarici xidmətə ödəniş edirsinizsə, pending əməliyyatın AZN qarşılığını, istifadə olunan məzənnəni və göndərmə vaxtını ayrıca qeyd edin. Müştəriyə və ya ailə üzvünə yeni ödəniş etməzdən əvvəl əvvəlki nonce-un nəticəsini blokçeyndə təsdiqləyin; bank və ya platforma qəbzi on-chain nəticəni əvəz etmir.

Eyni transaction-u müxtəlif RPC-lərdə izləmək nə verir?

Bir RPC pending transaction-u saxlayır, digəri onu mempool-dan çıxarmış ola bilər. Hash və sender nonce-i iki etibarlı mənbədə yoxlamaq replacement və local wallet keşini ayırmağa kömək edir. Buna baxmayaraq mempool məlumatı konsensus deyil; final nəticə block və receipt-dir. Speed up göndərdikdən sonra original və replacement hash-lərini eyni cədvəldə saxlayın, hansı RPC-nin hansını gördüyünü qeyd edin. Bir provider “not found” deyəndə yenidən başqa content-lə transaction imzalamaq olmaz. Bu xüsusilə platforma və hardware wallet birlikdə istifadə olunanda duplicate niyyət riskini azaldır.

Fee parametrləri necə qiymətləndirilir?

EIP-1559 transaction-da max fee, priority fee və cari base fee-ni müqayisə edin. Original max fee base fee-dən aşağı qalıbsa, inclusion çətinləşir. Wallet-in təklifi son bloklara əsaslanan təxmindir, dəqiq vaxt zəmanəti deyil.

Gas limit icra üçün sərhəddir, Gas price deyil. Out of gas səbəbində uyğun limit kömək edə bilər; contract-ın öz revert şərtində limit artırmaq eyni uğursuzluğu bahalaşdırır.

Nonce zəncirini açın

Ethereum hesabının əməliyyatları nonce ardıcıllığı ilə icra olunur. Aşağı nonce-li əməliyyat hələ pendingdirsə, sonrakı əməliyyatlar onun arxasında qala bilər. Hesab tarixçəsində ilk gözləyən nonce-i tapın.

Pulqabının speed up funksiyası çox vaxt eyni nonce ilə daha yüksək fee-li əvəzləyici yaradır. Cancel də eyni nonce üçün başqa əməliyyat qurur. Hər iki halda yeni hash yaranır və hansı əməliyyatın əvvəl bloka düşdüyü vacibdir.

İmzalamazdan əvvəl yeni əməliyyatın:

• Ethereum mainnet-də olduğunu;
• nonce-in məqsədli şəkildə eyni saxlandığını;
• alıcı və dəyərin gözlənilən olduğunu;
• maksimum xərcin qəbul edilə bildiyini yoxlayın.

Birdən çox pulqabıda nonce-i əl ilə dəyişmək qarışıq əvəzləmə yarada bilər.

Hadisə bitəndə nonce sırası necə audit edilir?

Address-in confirmed transaction sayını və bütün pending namizədləri müqayisə edin. Hər nonce üçün hansı hash-in block-a daxil olduğunu, hansının replaced/dropped qaldığını və hansı fee-nin ödənildiyini yazın. Sonra ETH və token before/after balansını, allowance dəyişikliklərini və platforma order nəticəsini yoxlayın. Bu audit bir frontend-in “failed” bildirişindən daha etibarlıdır. Əgər naməlum transaction və ya approval varsa, yeni imza vermədən təhlükəsizlik planına keçin.

Revert-dən sonra eyni DApp-a nə vaxt qayıtmaq olar?

Yalnız rəsmi mənbədən daxil olduğunuzu, contract və method-un dəyişmədiyini, revert səbəbini başa düşdüyünüzü və qalan allowance-i yoxladığınızı təsdiqlədikdən sonra. Yeni quote, deadline və slippage parametrlərini oxuyun. Şübhəli domain, naməlum spender və ya izah olunmayan calldata varsa, təkrar imza verməyin. Əvvəlki approve success qalıbsa, əlavə approve lazım olmaya bilər; sonsuz allowance-i yenidən artırmaq riski böyüdür. Hər retry yeni hash və potensial fee-dir.

Receipt reverted deyirsə

Transaction receipt blok nömrəsini, Gas istifadəsini və statusu göstərir. Status uğursuz olduqda token və contract vəziyyəti geri çevrilə bilər, amma sərf olunmuş hesablama üçün ETH tutulur.

Səbəblər müxtəlifdir: allowance azdır, deadline bitib, contract dayandırılıb, slippage şərti ödənməyib, input səhvdir və ya Gas limit icra üçün çatmayıb. Sadəcə fee-ni yüksəltmək business logic səhvini aradan qaldırmır.

Token yerindədir, ETH azalıb

Bu reverted vəziyyətində normal ola bilər. Contract dəyişiklikləri geri qayıdır, hesablama xərci geri qaytarılmır. Token balansını və receipt gasUsed sahəsini ayrıca yoxlayın.

Əməliyyat successdirsə, amma token gözlənilən ünvanda deyil, transfer event, müqavilə və chain-i araşdırın. Eyni 0x ünvanı başqa EVM zəncirində ola bilər.

Reverted niyə ETH xərcləyir?

Validator transaction-u icra edib resurs sərf etdiyi üçün state dəyişiklikləri geri dönsə də istifadə olunan Gas ödənə bilər. Receipt status, gasUsed və effectiveGasPrice faktiki xərci göstərir. Token transfer hadisəsi yoxdursa, token adətən recipient-ə keçməyib, lakin ETH fee azalıb.

Platforma hesabından məbləğ də çıxıbsa, receipt ilə göndərən platformaya müraciət edin; qəbul tərəfi uğursuz transferi kreditləşdirə bilməz.

Revert səbəbi necə tapılır?

Simulation, trace və contract error mesajına baxın. Slippage, deadline, allowance, balans, pause, blacklist və yanlış parametr səbəb ola bilər. Slippage-i həddindən artıq açmaq success ehtimalını artırsa da pis qiymət və MEV riskini yüksəldir. Təzə quote alın və token/route-u yoxlayın.

Approval success, swap failed

Approve ayrıca transaction-dur. Swap reverted olduqda allowance qala bilər. Token, spender və məbləği etibarlı permission alətində yoxlayın; artıq istifadə etmirsinizsə revoke və ya azaltmağı qiymətləndirin. Şübhəli DApp-ın öz “refund” düyməsinə kor-koranə imza verməyin.

Dəstəyə nə göndərilir?

Hash, chain, əməliyyat vaxtı, tətbiq addımı, receipt status və məxfi olmayan xəta mətni kifayətdir. Məxfi açar, seed, API secret və birdəfəlik kod contract xətasını izah etmir.

“Bir az ETH göndərin, reverted statusunu dəyişək” deyən şəxs keçmiş bloku redaktə edə bilməz. Səbəb həll edildikdən sonra yalnız yeni əməliyyat qurula bilər.

Support üçün hesabat

Chain ID, bütün hash-lər, nonce, fee parametrləri, method, recipient/contract, receipt, replacement əlaqəsi, asset before/after və etdiyiniz speed up/cancel/revoke addımlarını verin. Seed və private key hesabatın hissəsi deyil.

Multi-signature və L2 fərqləri

Multi-sig interface-də pending yalnız yetərli owner approval olmadığını göstərə bilər və hələ Ethereum hash yoxdur. Proposal ID ilə TxID-ni ayırın. L2 EVM görünüşlü olsa da chain ID, fee və cross-layer finality fərqlidir; mainnet explorer-də L2 hash-in olmaması normaldır.

Təkrar ödənişdən qorunma

Eyni nonce-li bütün hash-ləri və recipient-də token transfer hadisəsini yoxlayın. Frontend timeout success transaction-u gizlədə bilər. Merchant order bütün candidate hash-ləri saxlamalı, yalnız final success və doğru content-i bir dəfə kreditləşdirməlidir.

Təhlükəsizlik hadisəsi nə vaxtdır?

Transaction sizə aid deyil, address clipboard-da dəyişib, naməlum approval və ya seed sızması varsa, yalnız Gas problemi deyil. Təhlükəsiz cihazdan read-only inventar çıxarın, yeni wallet və qalan aktivlərin köçürülməsini planlaşdırın. Təsdiqlənmiş icazəsiz transaction üçün zəmanətli on-chain refund yoxdur.

Pending vəziyyətini ən aşağı nonce-dən başlayın

Göndərən ünvanın confirmed transaction count-u növbəti icra olunacaq nonce-ni göstərir. Wallet-də daha yüksək nonce-li bir neçə əməliyyat görünsə də ən aşağı pending nonce bloklanıbsa, sonrakılar queue-da qala bilər. Explorer və wallet nəticəsini müqayisə edin, hər hash üçün nonce, max fee və first-seen vaxtını yazın.

Yalnız son əməliyyatın fee-sini artırmaq nonce boşluğunu həll etmir. Ən aşağı problemli transaction üçün speed-up və ya cancel seçilir. Hesabın müxtəlif wallet tətbiqlərində açılması qarışıq lokal tarixçə yarada bilər; canonical nəticə public chain və mempool məlumatıdır.

Dropped, replaced və pending fərqi

Pending node-un transaction-u hələ yadda saxladığını göstərir. Dropped müəyyən node-un onu mempool-dan çıxardığını, replaced isə eyni nonce-li başqa transaction-un üstün gəldiyini göstərə bilər. Müxtəlif provider-lər köhnə qeydi fərqli müddət saxlaya bilər. Bir explorer not found yazdıqda dərhal yenidən eyni ödənişi göndərməyin.

Replacement hash-i tapmaq üçün göndərən ünvan və nonce üzrə axtarın. Yeni transaction mined olubsa köhnə hash artıq icra edilməyəcək. Recipient və value replacement-da dəyişibsə, mühasibat üçün məhz mined transaction əsasdır. Hər iki hash hadisə jurnalında əlaqələndirilir.

EIP-1559 replacement fee-si

Max fee per gas, max priority fee və cari base fee birlikdə qiymətləndirilir. Max fee base fee-dən aşağıdırsa transaction block-a uyğun olmaya bilər. Replacement node siyasətində əvvəlki təklifdən kifayət qədər yüksək olmalıdır; çox kiçik artım replacement transaction underpriced xətası verə bilər.

Wallet-in rəsmi speed-up funksiyası eyni nonce və eyni niyyəti qorumağa kömək edir. Naməlum web saytında raw transaction imzalamaq, seed daxil etmək və ya “validator fee” göndərmək lazım deyil. Gas limit və gas price fərqli sahələrdir; limit artırmaq inclusion təklifini mütləq yüksəltmir.

Cancel əməliyyatının həddi

Cancel adətən öz ünvanınıza sıfır ETH göndərən, eyni nonce-li daha rəqabətli transaction-dur. O da mempool-da yarışır və mined olmalıdır. Köhnə transaction əvvəl mined olsa cancel uğursuz və ya mənasız ola bilər. Buna görə cancel zəmanətli geri çağırma kimi təqdim edilməməlidir.

Token transferini cancel etmək tokeni geri qaytarmaq deyil; məqsəd ilkin transaction mined olmadan onun nonce-ni başqa transaction-la istifadə etməkdir. İlkin hash artıq success-dirsə cancel gecdir. Recipient-dən refund yalnız yeni, ayrıca imzalanmış transaction ilə mümkündür.

Reverted receipt-i oxumaq

Receipt status 0 olduqda EVM state dəyişiklikləri geri alınır, lakin istifadə olunan Gas haqqı qalır. Explorer bəzən revert reason və decoded input göstərir. execution reverted, custom error, panic code və out-of-gas fərqli səbəblərdir. Sadəcə daha çox ETH göndərmək hamısını həll etmir.

Token Transfer event-i yaranmayıbsa recipient-in balansına həmin transfer keçməyib. Transaction daxilində əvvəl yaranan event-lər də tam revert zamanı canonical state nəticəsi sayılmır. Faktiki post balance və receipt log-ları əsas götürülür.

Out-of-gas ilə məntiqi revert-i ayırmaq

Gas limit icra üçün ayrılan maksimum vahiddir. Limit həqiqətən kifayət etməyibsə, etibarlı simulation və wallet estimate daha uyğun limit təklif edə bilər. Lakin allowance, rol, deadline, slippage və contract pause səbəbindən revert olursa limit artırmaq eyni xətanı daha baha təkrarlayar.

Input decoder-də funksiya və parametrləri oxuyun. Recipient, amount, spender, deadline və minimum output gözlənilən əməliyyatla uyğun deyilirsə yenidən imzalamayın. Naməlum contract-a limitsiz approval sadə transfer düzəlişi deyil.

Allowance xətaları

ERC20 transferFrom çağırışı sahibin spender üçün kifayət qədər allowance verməsini tələb edir. Approval başqa chain-də, başqa token contract-a və ya başqa spender-ə verilibsə burada işləmir. Explorer allowance məlumatı chain və block kontekstində yoxlanır.

Approval success, əsas swap isə revert ola bilər. Bu halda allowance aktiv qala bilər və ayrıca təhlükəsizlik qərarı tələb edir. Etibarlı revoke əməliyyatı özü Gas ödəyən transaction-dur. DApp-dan disconnect etmək on-chain allowance-i silmir.

Slippage və deadline xətaları

DEX swap-da minimum output bazar hərəkətinə görə ödənmirsə transaction revert edə bilər. Deadline keçibsə validator onu sonradan uğurlu edə bilməz. Slippage-i həddən artıq genişləndirmək sandwich və pis icra riskini artırır; istifadəçi qiymət təsirini və route-u yenidən yoxlamalıdır.

Yeni quote köhnə transaction-un davamı deyil, yeni niyyətdir. Token contract, router, recipient, input və minimum output yenidən təsdiqlənir. Saxta support linkində “slippage fix” imzalamaqdan çəkinin.

Insufficient funds mesajının iki forması

Broadcast-dan əvvəl insufficient funds for gas * price + value hesabda ETH çatmadığını göstərir və public TxID yaranmaya bilər. Contract daxilində token balansı çatışmazlığı isə simulation və ya receipt revert reason kimi görünə bilər. Birincidə native fee, ikincidə token və contract şərti araşdırılır.

Başqa EVM chain-dəki ETH və wrapped ETH Ethereum mainnet Gas-ı deyil. Fee üçün məhz əməliyyatın chain-ində native ETH lazımdır. Naməlum şəxsdən “gas loan” alarkən seed və approval vermək tələb olunursa dayandırın.

RPC xətası və real broadcast

Wallet “submitted” göstərə bilər, lakin RPC timeout səbəbindən transaction-un qəbul olunub-olunmadığı aydın olmaya bilər. Yaranan hash-i bir neçə etibarlı Ethereum node mənbəyində axtarın. Tapılmırsa wallet log-dakı error və raw transaction-un lokal mövcudluğu araşdırılır.

Raw transaction public məlumat kimi broadcast oluna bilər, amma onu naməlum sayta ötürmək məxfi olmasa da əməliyyatın yayımlanmasına səbəb olur. Recipient və amount-u təsdiqləmədən rebroadcast etməyin. Private key və seed heç bir RPC diaqnostikası üçün verilmir.

Token transfer success, UI balansı köhnə

Receipt success və doğru Transfer event-i varsa, wallet UI token balansını cache səbəbindən yeniləməyə bilər. Doğru contract-ı custom token kimi read-only əlavə etmək və RPC-ni yeniləmək mümkündür. Eyni simvollu saxta tokeni seçməmək üçün contract və decimals yoxlanır.

Platforma hesabında balans görünmürsə bu wallet UI problemi deyil, credit mərhələsidir. Ticket-ə hash, event recipient, contract, amount və confirmations verilir. Platforma internal indexer-i istifadəçinin wallet refresh-i ilə idarə olunmur.

Internal transaction və contract payout

Contract ETH göndərişi explorer-də internal transfer kimi göstərilə bilər. Əsas transaction to sahəsi recipient olmayacaq, lakin execution trace daxilində value hərəkəti görünə bilər. Bəzi platforma depozit parser-ləri internal transferi avtomatik kredit etməyə bilər.

Trace, recipient və value support paketinə əlavə edilir. Recovery siyasəti platformadan asılıdır. İstifadəçi platformanın ünvanından özü çıxarış imzalaya bilməz və kənar “miner” confirmed state-i dəyişdirə bilməz.

Layer 2 qarışıqlığı

Arbitrum, Optimism, Base və başqa EVM chain-lərində nonce və transaction statusu ayrıca ledger-dədir. Ethereum mainnet explorer-də hash tapılmaması onun L2-də olmadığını göstərmir. Wallet network, chain ID və platforma seçimi eyni olmalıdır.

Bridge pending olduqda source transaction, message relay və destination execution ayrılır. Source success köhnə transaction-u destination chain-ə çevirmir. Rəsmi bridge domain-də message statusu yoxlanır; məbləği təkrar göndərmək ikiqat risk yaradır.

Hardware wallet ilə replacement

Hardware cihazında replacement imzalanarkən nonce, recipient, value və fee cihaz ekranında mümkün qədər yoxlanır. Kompüter proqramı “speed up” yazsa belə cihazın göstərdiyi əməliyyat fərqli ola bilər. Blind signing tələb olunursa contract və risk əvvəlcədən başa düşülməlidir.

Seed-i software wallet-ə import etməklə tələsik sürətləndirmə hardware qorumasını zəiflədir. Rəsmi wallet interfeysi replacement dəstəkləmirsə, təhlükəsiz alternativ sənədləşdirilir və kiçik risklə sınaq edilir.

Platforma withdrawal pending-dirsə

Birja processing göstərir, amma public hash vermirsə Ethereum mempool problemi hələ sübut olunmayıb. Platforma risk review, queue və ya wallet maintenance mərhələsində ola bilər. Order ID-ni TxID kimi explorer-də axtarmayın. Public hash yarandıqdan sonra nonce və fee araşdırmasına keçilir.

Platforma hash-i dəyişərsə köhnə və yeni dəyərləri qeyd edin. Batch withdrawal-da event recipient və amount seçilir. Eyni məbləği öz wallet-inizdən ayrıca göndərmək platformanın pending order-ini ləğv etmir.

Hadisə jurnalı və qərar nöqtələri

Hash, nonce, first-seen vaxtı, fee parametrləri, son status, replacement hash, receipt və faktiki balans dəyişikliyi cədvəldə saxlanır. Hər müdaxilədən əvvəl məqsəd yazılır: inclusion sürətləndirmək, cancel yarışı etmək, revert səbəbini düzəltmək və ya platforma credit-i araşdırmaq.

Əməliyyat mined olduqda canonical hash və block qeyd edilir. Failed nəticədə xərclənən fee, success nəticədə recipient event-i yoxlanır. Sonra wallet-də köhnə pending sətir qalırsa UI təmizlənir, lakin public tarixçə dəyişdirilmir.

Fırıldaq siqnalları

“Nonce vergisi”, “validator kilidi”, “mempool sertifikatı” və “refund activation” adı ilə şəxsi ünvana ödəniş protokol proseduru deyil. Explorer məlumatı açıqdır və diaqnostika üçün seed tələb etmir. Support əməkdaşı private key ilə transaction-u sürətləndirməməlidir.

Naməlum signature istəyən saytın domain, contract və bütün çağırışları yoxlanmadan wallet qoşulmur. Şübhəli approval artıq verilibsə, yeni imzanı dayandırın, allowance və aktiv inventarı çıxarın, sızma ehtimalında təhlükəsiz köçürmə planı hazırlayın.

Multisig nonce ilə EOA nonce-ni qarışdırmamaq

Safe və başqa multisig wallet-lər öz contract daxili nonce modelindən istifadə edə bilər. Proposal yaradılıb imzalar toplanır, sonra executor ayrıca Ethereum transaction-u broadcast edir. Multisig proposal ID-ni EOA transaction nonce-si kimi explorer-də axtarmaq düzgün deyil.

İmzalar kifayət etmirsə vəziyyət pending on-chain deyil, off-chain approval mərhələsidir. Execution hash yarandıqdan sonra fee, EOA nonce və receipt araşdırılır. Hər signer yalnız başa düşdüyü recipient, value və calldata-nı təsdiqləməlidir.

Account abstraction əməliyyatları

Smart account UserOperation göndərə, bundler onu sonradan chain transaction-a daxil edə bilər. UserOp hash ilə final transaction hash fərqli ola bilər. Paymaster sponsorship rədd olunarsa istifadəçi wallet-də pending görsə də public transaction receipt yaranmaya bilər.

Araşdırmada bundler statusu, smart account nonce, paymaster cavabı və final hash ayrı saxlanır. “Gas sponsorluğu” adı ilə seed və limitsiz token approval tələb edən naməlum xidmətə inanmayın. Rəsmi wallet log və public entry point hadisələri kifayətdir.

Base fee sürətlə artanda

Transaction yaradılarkən max fee yetərli olsa da sonrakı block-larda base fee yüksələrsə inclusion gecikə bilər. Max priority fee yüksək olsa belə max fee tavanı base fee-ni qarşılamırsa transaction uyğun deyil. Wallet-in replacement təklifində hər iki sahə yenilənməlidir.

Şəbəkə yükü azalarsa köhnə transaction sonradan qəbul oluna bilər. İstifadəçi artıq başqa ödəniş göndəribsə ikiqat nəticə mümkündür. Buna görə replacement və tamamilə yeni nonce-li payment arasındakı fərq anlaşılmalıdır.

Blob və rollup yükünün təsiri

Ethereum yeniləmələrindən sonra rollup data yükü ayrıca fee bazarı istifadə edə bilər, lakin adi ETH və ERC20 transaction-u yenə execution Gas şərtlərinə tabedir. Xəbərlərdə “blob fee yüksəkdir” görmək hər pending transferin səbəbini sübut etmir. Öz transaction sahələri əsas götürülür.

L2 withdrawal zamanı isə challenge və settlement müddəti ola bilər. L1 hash, L2 hash və bridge mesajı ayrı izlənir. Sadəcə Ethereum mainnet fee-ni artırmaq artıq yaradılmış L2 mesajının bütün mərhələlərini sürətləndirmir.

Audit üçün minimum son qeyd

Problem kateqoriyası, ilkin hash, nonce, fee parametrləri, müdaxilə, canonical hash, receipt statusu, token event-i və faktiki balans nəticəsi yazılır. Failed transaction-da revert səbəbi və xərclənmiş fee, replacement-da köhnə-yeni əlaqəsi göstərilir.

İstifadəçi üçün qarşı tədbir konkret olur: ən aşağı nonce-ni yoxlamaq, simulation xəbərdarlığını oxumaq, chain ID-ni address book-da saxlamaq və naməlum approval-dan uzaq durmaq. Bu qeyd gələcək “pending” hadisəsini eyni təhlükəsiz ardıcıllıqla idarə etməyə imkan verir.