Ethereum köçürməsi: ERC20, 0x ünvanı və ETH qazı

Ethereum, ERC20 və 0x eyni məlumat deyil

Ethereum şəbəkənin adıdır. ERC20 həmin şəbəkədə token müqavilələrinin geniş istifadə etdiyi interfeysdir. 0x ilə başlayan sətir isə EVM ünvan formatıdır. Köçürmə qərarında bu üç məlumat birlikdə uyğun gəlməlidir.

Türkcə, rusca və ya ingiliscə interfeys istifadə edirsinizsə, seçim Ethereum, ERC20, Ethereum network və ya сеть Ethereum kimi görünə bilər. Tərcüməyə deyil, qəbul səhifəsinin faktiki chain seçiminə baxın. BSC də 0x ünvanı göstərdiyi üçün ünvanın görünüşü şəbəkəni təyin etmir.

Token köçürməsi arxa planda contract çağırışıdır

Pulqabı “100 USDT göndər” kimi sadə ekran göstərə bilər. İmzalanan Ethereum əməliyyatı isə token müqaviləsinə ünvan və məbləğ daxil edilmiş çağırışdır. Buna görə təsdiq ekranında aşağıdakıları oxumaq vacibdir:

• şəbəkə Ethereum mainnet-dirmi;
• çağırılan müqavilə gözlənilən token müqaviləsidirmi;
• qəbul ünvanı tamdırmı;
• xərclənəcək token və ETH qaz limiti nədir;
• tətbiq transfer əvəzinə əlavə icazə istəyirmi.

Ad və loqo müqaviləni sübut etmir. Eyni simvoldan saxta və ya dəstəklənməyən müqavilə də istifadə edə bilər.

ETH və ERC20 köçürməsi necə ayrılır?

ETH native value kimi, ERC20 isə token müqaviləsinin vəziyyətində hərəkət edir. ERC20 əməliyyatında explorer-in yuxarı to sahəsi müqavilə ola bilər, real alıcı Transfer hadisəsində görünür. Value sıfır olsa da token köçürülə bilər. Müqavilə ünvanı, hadisədə from/to, decimals və məbləğ birlikdə yoxlanmalıdır.

Saxta token eyni ad və loqodan istifadə edə bilər. Müqaviləni emitentin rəsmi məlumatı ilə tutuşdurmadan platforma depoziti etməyin.

Böyük ödəniş üçün iki mərhələli yoxlama

Əvvəl read-only mərhələdə chain ID, recipient, token contract, platforma minimumu və pending nonce yoxlanılır. Sonra imza mərhələsində hardware/wallet ekranında recipient, amount, method, allowance və maksimum fee yenidən oxunur. Bu iki mərhələ clipboard dəyişməsini və DApp-ın son anda başqa calldata hazırlamasını tutmağa kömək edir. Kiçik sınaq success və faktiki kreditləşməyə qədər gözlənilir; əsas məbləğdə bütün məlumat yenə yoxlanılır. Sınaq yalnız keçmiş anda eyni route-un işlədiyini göstərir, növbəti imzanın məzmununu təsdiqləmir.

Smart contract interaction üçün əvvəlcədən risk büdcəsi

İstifadəçi maksimum itirə biləcəyi fee, token allowance və slippage dəyərini əməliyyatdan əvvəl müəyyən edir. Wallet-in maxFee rəqəmi ilə token-in bütün balansı ayrı riskdir: az Gas ödəyib limitsiz approval vermək mümkündür. DApp yeni və tanınmırsa, ayrıca boş wallet, məhdud token məbləği və aşağı allowance istifadə etmək əsas wallet-i qoruyur; amma seed-ləri bir sayta birlikdə daxil etmək olmaz. Contract verified olsa da admin upgrade və oracle riski qala bilər. İmza sonrası hash, method, spender və receipt arxivlənir. AZN uçotu üçün faktiki Gas və token nəticəsi ayrıca yazılır, çünki qiymət dəyişməsi transaction failure deyil.

Ethereum transaction-u hansı sahələr müəyyən edir?

Göndərən, qəbul edən, value, data, nonce, Gas limit, fee parametrləri və imza birlikdə transaction-u yaradır. Nonce hesab əməliyyatlarının sırasıdır; aşağı nonce pending qalanda sonrakılar gözləyə bilər. data boş deyilsə, sadə ETH göndərişi deyil, müqavilə çağırışı ola bilər. İmza ekranında yalnız token məbləğini deyil, method və spender-i də oxuyun.

EIP-1559 tipində max fee və priority fee istifadəçinin qəbul etdiyi yuxarı həddi göstərir. Faktiki xərc receipt-dəki gasUsed və effectiveGasPrice ilə yoxlanır. Platforma çıxarış haqqı isə xidmət qiymətidir və bu hesablamaya bərabər olmaq məcburiyyətində deyil.

Ünvan checksum-u nə qədər qoruyur?

Ethereum ünvanı 20 baytdır və adətən 0x ilə birlikdə 40 onaltılıq işarə kimi göstərilir. ERC-55 böyük-kiçik hərf düzülüşündən checksum yaradır. Bu, bəzi yazı səhvlərini tutmağa kömək edir, lakin ünvanın sahibini, şəbəkəni və qəbul dəstəyini təsdiqləmir.

Ünvanı mesajlaşma tətbiqindən almısınızsa, başqa etibarlı kanalla da yoxlayın. Zərərli clipboard proqramı bir düzgün 0x ünvanını başqa düzgün 0x ünvanı ilə əvəz edə bilər; format yoxlaması bunu aşkarlamaya bilər.

Qaz niyə ETH ilə ödənir?

Ethereum hər icra üçün Gas istifadə edir. Son xərc istifadə olunan Gas və bloka daxil edilmə zamanı tətbiq edilən qiymət parametrləri ilə formalaşır. ERC20 token balansı ETH rolunu avtomatik daşımır; hesabda USDT olduğu halda belə qaz üçün ETH lazım ola bilər.

Pulqabının göstərdiyi maksimum ehtimal olunan xərc son tutulma ilə eyni olmaya bilər. Gas limit icra üçün yuxarı həddir, fee parametrləri isə əməliyyatın blok şəraitinə münasibətini müəyyən edir. Limiti kor-koranə azaltmaq contract icrasını uğursuz edə bilər.

Nonce sırası pozulanda nə etmək olar?

Eyni ünvanın bütün pending transaction-larını nonce üzrə düzün və ən kiçik boşluğu tapın. Wallet “speed up” ilə eyni nonce və daha rəqabətli fee yarada bilər; “cancel” çox vaxt eyni nonce ilə özünə sıfır value göndərən rəqib transaction-dur. Heç biri əvvəlki əməliyyatın artıq təsdiqlənmədiyinə zəmanət vermir.

Yeni və köhnə hash-ləri saxlayın. Bir neçə wallet-də əl ilə təsadüfi nonce seçmək araşdırmanı çətinləşdirir.

Pending və reverted fərqli diaqnozdur

Pending əməliyyatda hələ yekun receipt olmaya bilər. Burada əvvəlki nonce, yayım və fee parametrləri yoxlanır. Eyni hesabın daha kiçik nonce-li əməliyyatı gözləyirsə, sonrakılar onun arxasında qala bilər.

Reverted əməliyyat artıq bloka daxil edilib, amma EVM icranı geri çevirib. Token hərəkəti baş verməyə bilər, hesablanmış qaz isə sərf olunur. Receipt status, contract, input və tətbiqin səhv mesajı araşdırılmalıdır; eyni əməliyyatı dəyişmədən təkrar göndərmək çox vaxt yenə qaz itirir.

Uğurlu receipt, görünməyən depozit

Receipt uğurludursa, token transfer hadisəsində ünvanı və məbləği yoxlayın. Bundan sonra məsələ qəbul platformasının qatına keçir: müqavilə dəstəyi, təsdiq həddi, minimum depozit və texniki xidmət vəziyyəti.

Dəstəyə transaction hash, şəbəkə, müqavilə, ünvan, məbləğ və vaxt təqdim edin. Heç bir receipt araşdırması bərpa sözləri, məxfi açar, parol və ya birdəfəlik kod tələb etmir.

Platformaya ETH/ERC20 depozitində son yoxlama

Şəbəkə Ethereum olmalı, token müqaviləsi platformanın qəbul etdiyi versiya ilə eyni, ünvan cari depozit səhifəsindən alınmış, məbləğ minimumdan yuxarı olmalıdır. On-chain success-dən sonra platformanın təsdiq həddini gözləyin. Hədd keçib kredit yoxdursa, TxID, Transfer hadisəsi, ünvan və müqavilə ilə rəsmi ticket açın.

Approval niyə ayrıca riskdir?

Token approve müəyyən spender-ə aktivdən istifadə limiti verir, swap və depoziti özü tamamlamır. Swap reverted olsa da əvvəlki approval success qala bilər. Token, spender, chain və məbləği oxuyun; birdəfəlik əməliyyat üçün limitsiz approval riskini anlayın. Şübhəli DApp-dan ayrıldıqdan sonra etibarlı alətdə allowance-i yoxlamaq və lazım olsa azaltmaq olar.

Transaction simulation hansı sərhədə qədər faydalıdır?

Simulation cari state-də transaction-un revert edib-etməyəcəyini və bəzi asset dəyişikliklərini göstərə bilər. İmza ilə block-a daxilolma arasında state dəyişdiyi üçün zəmanət deyil. Simulation success olsa da recipient səhvdirsə, texniki olaraq uğurlu səhv ödəniş alınacaq. Ona görə network, address, contract, method, allowance və fee ayrıca yoxlanılır. Proxy contract eyni address-də implementation dəyişə bilər; keçmişdə təhlükəsiz interaction gələcək davranışı sübut etmir. Böyük approval və ya blind signing tələb edən tətbiqdə rəsmi mənbə, verified code və admin riskini qiymətləndirmədən imza verməyin.

Təhlükəsizlik sərhədi

Hash, receipt və balans oxumaq private key tələb etmir. “Pending həll edirik” adı ilə seed, remote desktop və ya əvvəlcədən vergi istəyən şəxs normal nonce/Gas prosesini aparmır. Şübhəli imza olubsa, bunu təkcə fee problemi deyil, mümkün təhlükəsizlik hadisəsi kimi araşdırın.

Ethereum transaction sahələrini birlikdə oxumaq

Transaction detail-də hash, status, block, timestamp, from, to, value, nonce, gas limit, gas used, base fee və priority fee ayrı məna daşıyır. to EOA ola bilər, contract ola bilər və ya contract yaradılmasında boş qala bilər. Token transferində əsas value sıfır görünsə də event log daxilində ERC20 məbləği hərəkət edə bilər. Buna görə ETH dəyəri ilə token nəticəsini qarışdırmayın.

Receipt status 1 olduqda EVM çağırışı uğurludur, 0 olduqda revert baş verib. Uğursuz transaction üçün istifadə olunan Gas geri qaytarılmır, xərclənməyən gas limit isə balansdan tam tutulmur. Explorer-in göstərdiyi faktiki fee gas used və effective gas price əsasında yoxlanır.

Nonce ardıcıllığı pending əməliyyatlara necə təsir edir?

Hər göndərən hesabın transaction-ları nonce sırası ilə icra olunur. Aşağı nonce-li əməliyyat mempool-da ilişibsə, daha yüksək nonce-lər kifayət qədər fee versə belə gözləyə bilər. Wallet-də yalnız son əməliyyatı “speed up” etmək əvəzinə ən aşağı pending nonce-ni tapın. Eyni nonce ilə yeni transaction qəbul edilirsə, köhnə əməliyyat əvəzlənə bilər.

Replacement üçün node adətən əvvəlki əməliyyatdan daha yüksək uyğun fee tələb edir. Sadəcə gas limit artırmaq priority fee-ni yüksəltmir. Ləğv də sehrli silmə deyil: istifadəçi öz ünvanına sıfır dəyərli, eyni nonce-li və rəqabətli fee-li yeni transaction imzalayır. Hansı variantın mined olacağına zəmanət yoxdur.

EIP-1559 fee məlumatını praktik oxumaq

Max fee per gas istifadəçinin ödəyə biləcəyi tavan, max priority fee validator üçün nəzərdə tutulan əlavə, base fee isə block tələbinə görə protokol tərəfindən dəyişən hissədir. Faktiki qiymət hər zaman max fee qədər olmur. Wallet estimate zamanı ən yeni block və gözlənilən inclusion müddətini nəzərə almalıdır.

Əməliyyat uzun müddət pending qalırsa, explorer-dəki fee-ni son block-ların base fee-si ilə müqayisə edin. Max fee cari base fee-dən aşağıdırsa, inclusion üçün şərt yaranmaya bilər. Bununla belə, naməlum saytda wallet qoşub “gas unlock” imzalamaq lazım deyil; replacement yalnız etibar etdiyiniz wallet vasitəsilə qurulmalıdır.

ERC20 transferini event log ilə təsdiqləmək

Token simvolu, adı və logo saxtalaşdırıla bilər. Contract ünvanını rəsmi issuer məlumatı və qəbul edən platformanın dəstək səhifəsi ilə tutuşdurun. Transfer event-ində from, to və raw value oxunur; decimals tətbiq edildikdən sonra görünən məbləğ alınır. Eyni transaction-da birdən çox event varsa, məhz gözlənilən contract və recipient seçilir.

Fee-on-transfer və rebasing kimi token davranışları göndərilən və alınan məbləği fərqləndirə bilər. Platforma belə tokeni dəstəkləmirsə, chain success avtomatik credit demək deyil. Ticket-də yalnız token adı deyil, contract, event index və faktiki recipient məbləği də verilir.

Contract çağırışında revert səbəbini ayırmaq

Revert allowance çatışmazlığı, deadline bitməsi, slippage həddi, paus edilmiş contract, rol icazəsi və ya tətbiq məntiqi səbəbindən ola bilər. Gas artırmaq yalnız hesablama resursu çatmadıqda kömək edir; biznes qaydasını dəyişmir. Explorer input decoder göstərə bilirsə, çağırılan funksiya və parametrləri seed olmadan oxumaq mümkündür.

Wallet simulation xəbərdarlıq verirsə, onu kor-koranə keçməyin. Naməlum approve, setApprovalForAll, permit və ya proxy upgrade imzası sadə transfer deyil. Domen, contract və gözlənilən hərəkət uyğun gəlmirsə, sessiyanı bağlayın və əvvəlki allowance-ları ayrıca audit edin.

Layer 2 və Ethereum mainnet-i qarışdırmamaq

Arbitrum, Optimism, Base və başqa EVM şəbəkələrində ünvan formatı Ethereum ilə eyni görünə bilər, lakin chain ID, native fee bazarı və transaction dəftəri ayrıdır. Ethereum explorer-də hash tapılmırsa, wallet-in seçilmiş chain-ini və platformanın withdrawal network sahəsini yoxlayın. Eyni 0x ünvan aktivin mainnet-də olduğu anlamına gəlmir.

Bridge istifadə edilibsə, source transaction, cross-chain message və destination icrası ayrı sübutlardır. Source success destination credit-in dərhal baş verdiyini göstərməyə bilər. Rəsmi bridge status səhifəsində message ID və claim tələbi yoxlanır; problemi həll etmək üçün məbləği təkrar göndərmək ikiqat köçürmə yarada bilər.

Platforma depoziti görünməyəndə

Əvvəl recipient-in platformanın cari depozit ünvanı olduğunu, token contract-ın dəstəkləndiyini, məbləğin minimumdan yuxarı olduğunu və tələb olunan confirmation sayına çatdığını yoxlayın. Contract event-i düzgün olsa da maintenance, compliance review və daxili indexer gecikməsi credit-i saxlaya bilər. Bunlar on-chain statusdan ayrıca mərhələlərdir.

Ticket paketində hash, chain ID, block, from, event recipient, contract, amount, confirmations və depozit səhifəsinin network adı olmalıdır. Private key, seed, API secret və login kodu lazım deyil. Dəstək manual recovery təklif edərsə, fee və müddəti yalnız hesab daxilindəki rəsmi ticket-dən təsdiqləyin.

Təhlükəsiz hadisə jurnalı

Hər yoxlamaya UTC vaxtı, istifadə olunan explorer domeni və görülən status əlavə edin. Pending-dən success-ə keçid, replacement hash-i və platforma credit vaxtı eyni hadisənin fərqli mərhələləridir. Köhnə qeydi silmək əvəzinə yeni sətrə dəyişiklik yazmaq sonradan nonce və fee qərarını izah etməyə imkan verir.

Araşdırma bitdikdə address book-da şəbəkə adını recipient ilə birlikdə saxlayın, token contract-ı yenidən təsdiqləyin və böyük transferdən əvvəl cari estimate alın. Keçmiş əməliyyatın fee-si gələcək Ethereum yükünü və ya contract davranışını zəmanət etmir.

ENS adını recipient kimi istifadə edərkən

ENS adı oxunaqlıdır, lakin wallet imzadan əvvəl onu konkret Ethereum address-inə resolve edir. Adın owner-i record-u dəyişə bilər və eyni ada müxtəlif coin type record-ları bağlana bilər. Ödəniş üçün resolved address qarşı tərəfin ikinci kanal təsdiqi ilə müqayisə olunur. Köhnə screenshot-da görünən nəticə daimi deyil.

Subdomain və oxşar Unicode simvollar phishing riski yaradır. Wallet cihaz ekranında yalnız hexadecimal recipient göstərirsə, istifadəçi ENS adını deyil həmin ünvanı təsdiqlədiyini anlamalıdır. Böyük məbləğdə əvvəl kiçik sınaq və cari resolution vaxtı saxlanır.

Contract creation transaction-u

Yeni contract deploy ediləndə to sahəsi boş ola bilər və yaradılan address receipt-dən hesablanır. Success contract kodunun biznes baxımından təhlükəsiz olduğunu göstərmir. Deployer, bytecode, constructor parametrləri və verified source sonradan yoxlanır.

CREATE2 ilə address əvvəlcədən hesablana bilər, amma həmin address-də düzgün kodun deploy ediləcəyinə və bütün chain-lərdə eyni olduğuna zəmanət yoxdur. Tokeni undeployed və ya yanlış chain contract address-inə əvvəlcədən göndərmək recovery riskidir.

Event ilə state uyğunsuz görünəndə

Explorer event log göstərir, lakin son balans fərqli ola bilər; sonrakı transfer, rebasing, fee-on-transfer və ya proxy məntiqi nəzərə alınır. Hadisə müəyyən block-da doğru ola, cari state isə daha yeni əməliyyatlardan sonra dəyişə bilər. Araşdırmada block-tagged balance və son transaction-lar istifadə olunur.

Reorg olmuş log canonical chain-dən çıxa bilər. Receipt-in son canonical block hash-i yoxlanır. DApp-ın lokal notification-u public receipt-dən üstün deyil. Platforma credit-i üçün canonical event və tələb olunan finality əsasdır.

MEV və private transaction route-u

Swap və böyük DeFi əməliyyatında public mempool front-running və sandwich riskinə məruz qala bilər. Etibarlı wallet private relay seçimi təqdim edə bilər, lakin bu xidmət recipient və calldata yoxlamasını ləğv etmir. Private submission success zəmanəti və ya refund deyil.

Transaction public mempool-da görünməsə, relay statusu və son on-chain hash izlənir. Naməlum “MEV qoruma” domeninə seed və limitsiz approval verilməz. Sadə ETH transferində belə xidmət çox vaxt lazım deyil.

Forked və test şəbəkələri

Sepolia və lokal fork-da transaction success mainnet aktivini hərəkət etdirmir. Test tokenləri bazar USDT və ETH-si deyil. Wallet-də network adı və chain ID imzadan əvvəl görünməlidir. Saxta dApp testnet görüntüsünü real balans kimi təqdim edə bilər.

Təlim üçün testnet istifadə olunursa nəticə yalnız proses məşqidir. Mainnet recipient, contract, fee və platforma dəstəyi ayrıca yoxlanır. Test seed-i ilə real seed eyni saxlanmır.

Ethereum monitorinqinin yekun forması

Forma chain ID, hash, nonce, block, receipt, from, faktiki recipient, native value, token contract, event amount, fee və final platforma nəticəsini saxlayır. Contract çağırışında decoded function və revert reason əlavə olunur. Hər məlumatın explorer domeni və müşahidə vaxtı göstərilir.

Bu forma pending, failed, yanlış token və credit gecikməsini bir-birindən ayırır. Public sübut kifayət etdiyi üçün seed və cihaz PIN-i daxil edilmir. Hadisə bağlandıqda qarşı tədbir konkret sahəyə bağlanır.