Token ünvanını yoxlamaq: şəbəkə, tam ünvan və sübut sərhədi

Bakıda eyni küçə adı bir neçə rayonda təkrarlana bilər. Taksi sürücüsünə yalnız küçəni demək kifayət etmir; rayon, bina nömrəsi və giriş də lazımdır. Token adı küçə adına, müqavilə və ya mint isə bina nömrəsinə bənzəyir. Şəbəkə göstərilməsə, uzun ünvan belə natamam istiqamətdir.

Müqavilə yoxlamasının məqsədi ekranda yaşıl nişan tapmaq deyil. Məqsəd hansı zəncirdə hansı obyektə baxıldığını, ünvanın hansı növdə olduğunu, bu əlaqəni hansı mənbənin verdiyini və müşahidənin nə vaxt edildiyini başqa bir şəxsin təkrar yoxlaya biləcəyi formada saxlamaqdır.

Beşsahəli kimlik qeydi ilə başla

Hər token üçün əvvəl bu sahələr yazılır:

• şəbəkənin tam adı və chain ID-si;
• tam müqavilə və ya mint ünvanı;
• obyekt növü: EVM müqaviləsi, Solana minti, token hesabı və ya başqa hesab;
• ünvanı layihəyə bağlayan açıq mənbə;
• müşahidə vaxtı və mümkün olduqda blok nömrəsi.

Ad, simvol, loqo və qısaldılmış ünvan bu beş sahənin heç birini əvəz etmir. Explorer nəticəsində “PEPE” yazılması onun nəzərdə tutulan PEPE olduğunu təkbaşına sübut etmir. Eyni simvol başqa müqavilədə istifadə oluna, loqo explorer məlumatına sonradan əlavə edilə və axtarış nəticəsi reklamla qarışa bilər.

Ünvanı kopyalayarkən baş və son hissəyə baxıb razılaşmaq da zəif üsuldur. Tam dəyər etibarlı rəsmi səhifə, əvvəldən yoxlanmış manifest və ya layihənin texniki sənədindən götürülür, sonra explorer-də tam axtarılır. Qısaldılmış forma yalnız oxunaqlılıq üçündür.

Mənbə iyerarxiyası “rəsmi həmişə doğrudur” qaydası deyil. Rəsmi səhifə layihənin hansı ünvanı özününkü saydığını göstərir; explorer zəncirdə həmin obyektin mövcudluğunu və hadisələrini göstərir; təminatçı xəritəsi bazar məlumatının hansı obyektə bağlandığını göstərir. Üçü fərqli suallara cavab verir.

EVM explorer-də üç ayrı yoxlama var

EVM şəbəkəsində token səhifəsində mənbə kodu, ünvan etiketi və müqavilə sahiblik iddiası yanaşı görünə bilər. Onların hamısını “verified” sözü ilə birləşdirmək olmaz.

Etherscan-ın müqavilə yoxlama sənədi təqdim edilmiş mənbə kodunun kompilyasiya nəticəsini zəncirdə yerləşdirilmiş kodla uyğunlaşdırdığını bildirir. Uğurlu olduqda mənbə kodu açıq oxuna bilir. Bu, mühüm şəffaflıq qatıdır: tədqiqatçı funksiyaları, səlahiyyət yollarını və xarici asılılıqları araşdıra bilər.

Lakin uyğunluq kodun təhlükəsiz, dəyişməz və ya məqsədəuyğun olduğunu demir. Mənbə kodunda riskli funksiya ola bilər; müqavilə proxy vasitəsilə başqa icraya yönələ bilər; idarəetmə açarı ayrıca qala bilər. “Kod oxuna bilir” yoxlamanın başlanğıcıdır, auditin nəticəsi deyil.

Müqavilə kodu yoxlanmayıbsa, bundan “saxtadır” hökmü də avtomatik çıxmır. Mənfi nəticə yalnız budur: bu explorer-də təqdim edilmiş oxunaqlı mənbə ilə yerləşdirilmiş kodun uyğunluq sübutu əldə olunmayıb. Səbəb və risk ayrıca araşdırılır.

Address ownership başqa nəzarət xəttidir

Etherscan ayrıca müqavilə ünvanının sahiblik iddiasını təsvir edir. Yaradıcı ünvanla imzalanmış mesaj müqaviləni bir Etherscan hesabına bağlaya, həmin hesaba token məlumatını və name tag-i yeniləmək imkanı verə bilər.

Bu imza explorer-in məlumat yeniləmə prosesinə nəzarəti göstərir. O, şirkətin benefisiar sahibini, token sahiblərinin hüquqlarını və ya müqavilənin iqtisadi təhlükəsizliyini sübut etmir. “Owner” sözü burada explorer funksiyasının terminidir; gündəlik hüquqi sahiblik mənasına genişləndirilmir.

Name tag və loqo da eyni sərhəddədir. Onlar naviqasiyanı asanlaşdırır, amma zəncir vəziyyətinin yerinə keçmir. Etiket dəyişə, səhv təqdim oluna və ya köhnələ bilər. Yoxlama qeydində etiket dəyəri ilə tam ünvan ayrı sahələrdə saxlanır.

Beləliklə, EVM səhifəsində ən azı üç sübut xətti var: ünvanın zəncirdəki kodu, təqdim edilmiş mənbə kodunun uyğunluğu və explorer hesabının yeniləmə nəzarəti. Birinin mövcudluğu digər ikisinin avtomatik mövcudluğu deyil.

Solana-da mint ilə token hesabını qarışdırma

Solana sənədləri mint hesabını və token hesabını ayrı obyektlər kimi təqdim edir. Mint hesabı token vahidlərinin ortaq kimliyini, onluq dəqiqliyini və mint/dondurma kimi səlahiyyət sahələrini saxlaya bilər. Token hesabı isə müəyyən sahibin müəyyən mint üzrə balansını saxlayır.

İstifadəçi explorer-də böyük balanslı token hesabı tapıb onu “müqavilə ünvanı” adlandıra bilər. Bu, ünvan növü səhvidir. Aktiv kimliyi üçün mint lazımdır; sahiblik araşdırması üçün mintə bağlı token hesabları lazımdır. Bir hesabın balance sahəsi mintin total supply sahəsi deyil.

Səlahiyyət dəyərləri də adla çıxarılmır. Mint authority və freeze authority dəyişdirilə və ya ləğv edilə bilər. Cari vəziyyət canlı hesabdan, konkret blok və vaxtla oxunmalıdır. Explorer etiketi və layihə bəyanatı həmin sahənin xam dəyərini əvəz etmir.

Solana minti də tam kopyalanır. İlk və son simvolların uyğunluğu, eyni şəkil və axtarış nəticəsindəki “verified” etiketi tam ünvan müqayisəsinin yerinə keçmir.

Eyni ünvan mətnini şəbəkələr arasında daşıma

EVM ünvanları bir neçə EVM uyğun zəncirdə eyni `0x...` mətninə malik ola bilər. Bu, həmin ünvanlarda eyni kodun yerləşdirildiyini, eyni administratorun nəzarət etdiyini və ya tokenlərin iqtisadi olaraq bağlı olduğunu göstərmir. Zəncir vəziyyəti hər şəbəkədə ayrıca saxlanılır.

Multichain layihə varsa, rəsmi müqavilə siyahısı hər zəncir üçün ünvan verir və körpü/münasibət sənədi ayrıca lazımdır. “Ad eynidir” ilə “aktiv eynidir” arasında sübut boşluğu qalır. FLOKI-ni iki şəbəkədə izləmək həmin münasibəti təklif və hovuz səviyyəsində geniş izah edir.

Solana ünvanını EVM explorer-də axtarmaq və ya EVM ünvanını yanlış chain seçimi ilə açmaq da etibarlı mənfi sübut deyil. “Nəticə tapılmadı” yalnız istifadə edilən şəbəkə və explorer kontekstində mənalıdır.

Şəkil sübutu canlı vəziyyət deyil

Bu məqalədəki iki şəkil real açıq sənəd səhifələrindən götürülüb, mənbə URL-si, çəkilmə tarixi, orijinal fayl və açıq WebP törəməsi reyestrdə saxlanılır. Onlar əməliyyat təlimatı və ya saxta token interfeysi deyil.

Şəkil yalnız çəkildiyi anda görünən sənəd hissəsini göstərir. Cookie banner, naviqasiya və dizayn fakt mənbəyi deyil. Sənəd sonradan yenilənsə, köhnə şəkil “bu gün də eynidir” demir; tarixli arxiv sübutu kimi qalır.

Explorer-də konkret token ekran görüntüsü istifadə edilərsə, tam ünvan, şəbəkə, səhifə URL-si və çəkilmə vaxtı görünməlidir. Kəsilmiş ünvanlı şəkil kimlik sübutu deyil. Hesab balansı və əməliyyat tarixi kimi dinamik sahələr də mətnə daimi həqiqət kimi dondurulmamalıdır.

Təkrar yoxlanılan qeyd necə saxlanılır?

Yekun qeyd bir cümləlik “verified” statusu yox, kiçik sübut cədvəlidir. Məsələn: şəbəkə; tam ünvan; obyekt növü; rəsmi mənbə URL-si; explorer URL-si; mənbə kodu vəziyyəti; explorer ownership vəziyyəti; səlahiyyət sahələri; blok və müşahidə vaxtı.

Hər sahə üçün üç vəziyyət kifayətdir: müşahidə edilib, çıxarılıb və həll olunmayıb. “Müşahidə edilib” birbaşa cavabı, “çıxarılıb” açıq məntiqi əlaqəni, “həll olunmayıb” isə çatmayan sübutu göstərir. Failed və missing sıfır və ya “yoxdur” kimi çevrilmir.

Yeniləmədə əvvəl şəbəkə və tam ünvan yenidən tutulur, sonra dəyişə bilən sahələr təzələnir. Rəsmi sayt ünvanı dəyişibsə köhnə obyekt silinmir; versiya kimi saxlanır və münasibət araşdırılır. Etiket dəyişibsə zəncir ünvanı dəyişmiş sayılmır.

Bu üsul tokenin alınmalı olub-olmadığını demir. O, daha əsas bir səhvin qarşısını alır: yanlış şəbəkədə yanlış obyekt barədə çox dəqiq görünən araşdırma aparmaq. Kimlik sübutu möhkəm olmadıqda qiymət, təklif, sahiblik və likvidlik üzrə sonrakı bütün nəticələr də etibarsız təməl üzərində qalır.

Rəsmi mənbənin özünü necə təsdiqləməli?

“Rəsmi sayt” etiketi axtarış nəticəsindən avtomatik gəlmir. Domen layihənin digər tanınmış kanalları, sənədləri və əvvəlki qeydləri ilə yoxlanılır. Oxşar yazılmış domen, reklam nəticəsi və sosial şəbəkədə paylaşılmış qısa link müqavilə üçün başlanğıc mənbə sayılmır. Domen təsdiqlənmirsə, oradakı ünvan namizəd kimi saxlanır, təsdiqlənmiş aktiv kimi yox.

Sayt ünvanı dəyişəndə köhnə mənbə dərhal silinmir. Layihə bildirişi və explorer hadisələri dəyişmənin səbəbini aydınlaşdırmağa kömək edə bilər. Miqrasiya sübutu yoxdursa, iki ünvan arasında avtomatik varislik qurulmur. Yeni contract ayrıca obyekt kimi araşdırılır.

Explorer-in verified etiketi hansı sərhəddədir?

Verified source etiketi yüklənmiş mənbə kodunun zəncirdəki bytecode ilə explorer-in metoduna görə uyğunluğunu göstərir. Bu etiket kodun layihəyə məxsus olduğunu, təhlükəsizlik auditindən keçdiyini və ya idarəetmə səlahiyyətlərinin zərərsiz olduğunu göstərmir. Proxy müqaviləsində görünən kod son implementasiyanın bütün tarixini də təkbaşına əhatə etməyə bilər.

Qeyd buna görə verification status, compiler məlumatı, proxy status və implementasiya ünvanını ayrı saxlayır. Bunlardan biri görünmürsə, digər sahələrdən təxmin edilmir. “Contract verified” cümləsi yalnız explorer-in həqiqətən göstərdiyi yoxlamanı ifadə edir.

Proxy və implementasiya zənciri

Proxy aşkar ediləndə istifadəçinin gördüyü ünvanla icra olunan kodun ünvanı fərqli ola bilər. Araşdırma proxy ünvanını, implementasiya ünvanını, admin və upgrade mexanizmi barədə görünən məlumatı ayrıca qeyd edir. Implementasiya sonradan dəyişə bildiyi üçün tək screenshot uzunmüddətli sübut deyil.

Hər müşahidə blok və ya vaxt konteksti daşımalıdır. Explorer yalnız cari implementasiyanı göstərirsə, əvvəlki versiyalar üçün event log və layihə qeydləri lazım ola bilər. Tarixçə əldə olunmursa, qeyd “cari görünən implementasiya” ilə məhdudlaşdırılır.

Solana authority sahələri ayrıca oxunur

Solana tokenində mint authority, freeze authority, decimals və supply fərqli sahələrdir. Bir authority-nin olmaması digərinin də olmadığını göstərmir. Token account sahibi ilə mint authority eyni rol deyil; proqram hesabı ilə istifadəçi hesabı da eyni məna daşımır. Buna görə hər public key-in obyekt tipi əvvəlcə müəyyən edilir.

Solscan etiketi və logo köməkçi məlumatdır. Dəqiq mint layihənin rəsmi mənbəyi ilə bağlanmadıqda, explorer adı təkbaşına rəsmi kimlik yaratmır. WIF kimi aktivdə rəsmi səhifədən dəqiq Solscan mint keçidi bu əlaqəni gücləndirir, amma digər risk sahələrini avtomatik bağlamır.

Ünvanı paylaşarkən səhv riskini azalt

Qısa ünvan yalnız vizual kömək üçündür; araşdırma qeydində həmişə tam sətir saxlanılır. Mətn kopyalananda əvvəl və son simvollar deyil, bütün dəyər etibarlı diff ilə yoxlanılır. Gizli Unicode, boşluq və line-break kimi dəyişikliklər də təmizlənir. QR kod istifadə olunursa, onun açdığı tam dəyər mətnlə yenidən müqayisə edilir.

İstifadəçiyə göstərilən səhifədə chain adı ünvanın yanında görünür. Eyni sətir başqa şəbəkəyə daşınmır və “EVM ünvanıdırsa hər EVM şəbəkəsində eyni aktivdir” nəticəsi çıxarılmır. Bu təqdimat qaydası yanlış şəbəkəyə aid müqavilənin doğru görünməsi riskini azaldır.

Contract creation və deployer nəyi göstərir?

Explorer contract creation transaction-u və deployer ünvanını göstərə bilər. Bu məlumat contract-ın zəncirdə necə yarandığını izləməyə kömək edir, amma deployer-in real şəxsini və layihə ilə münasibətini avtomatik sübut etmir. Factory vasitəsilə yaradılan obyektlərdə birbaşa deployer protokol contract-ı ola bilər.

Qeyd creation tx, block, deployer və mümkün factory münasibətini ayrı saxlayır. Layihə sənədi deployer barədə iddia verirsə, bu ayrıca project-stated sahədir. Ünvan etiketi hüquqi və ya iqtisadi sahiblik sübutu kimi genişləndirilmir.

Bytecode dəyişmirsə risk də dəyişmirmi?

Birbaşa contract bytecode-u dəyişməsə belə, xarici oracle, router, admin, proxy implementasiyası və inteqrasiya olunan contract-lar dəyişə bilər. Buna görə kod hash-i faydalı kimlik sahəsidir, lakin bütün sistemin sabitliyini göstərmir. Proxy olmayan contract belə xarici asılılıqlara malik ola bilər.

Araşdırma dəyişməz sahələri və xarici münasibətləri ayırır. Code hash, contract ünvanı və chain dəyişməz kimliyə yaxın sahələrdir; rol sahibləri, oracle ünvanları və likvidlik obyektləri tarixli müşahidələrdir. Hər birinin yeniləmə ritmi fərqli olur.

Token metadata niyə kifayət etmir?

Name, symbol, decimals və logo istifadəçi interfeysini oxunaqlı edir. Lakin eyni metadata istənilən başqa contract-da təkrarlana bilər. ERC-20 standartı da rəsmi layihə münasibətini yox, ortaq interfeysi təsvir edir. Bu səbəbdən metadata tam ünvanın yerinə keçmir.

Metadata dəyişə bilirsə, dəyişiklik tarixli qeyd kimi saxlanılır. Provider logo-nu yeniləyəndə zəncir contract-ı dəyişmiş sayılmır. Əksinə, rəsmi layihə yeni contract elan edərsə, köhnə metadata oxşarlığı miqrasiyanı təsdiqləmir.

EVM event mövzularını ehtiyatla oxu

Transfer və Approval log-ları contract hadisələridir. Log-da görünən ünvan transaction-un əsas `to` sahəsindən fərqli ola bilər. Router çağırışı içində bir neçə token hadisəsi yarana bilər. Tək transaction səhifəsində tanış simvol görmək araşdırılan contract-ın əsas obyekt olduğunu göstərmir.

Qeyd log emitter ünvanını, event signature-u və decoded parametrləri saxlayır. Decode mənbə kodu təsdiqlənməyibsə, explorer-in təqdim etdiyi şərh ayrıca provider çıxışı kimi qalır. Hadisədən istifadəçi niyyəti və ya layihə münasibəti çıxarılmır.

Təkrar yoxlama tezliyi necə seçilir?

Dəyişməz görünən contract kimliyi hər bazar yeniləməsində yenidən yazılmır, amma rəsmi mənbə, proxy implementasiyası və səlahiyyət sahələri müəyyən hadisədən sonra təzələnir. Layihə miqrasiyası, upgrade event-i və provider mapping dəyişikliyi növbədənkənar yoxlama səbəbidir.

Yoxlama tarixi “hələ də təhlükəsizdir” nişanı deyil. Sadəcə həmin tarixdə hansı sahələrin müşahidə edildiyini bildirir. Növbəti baxış əvvəlki qeydi müqayisə nöqtəsi kimi istifadə edir və yalnız dəyişən sahələrə yeni versiya əlavə edir.

ENS və qısa ad tam ünvan deyil

ENS və başqa ad sistemləri oxunaqlılığı artırır, lakin resolver vəziyyəti zamanla dəyişə bilər. Araşdırma həll olunan tam ünvanı, chain ID-ni, resolver və baxış vaxtını saxlayır. Adı screenshotdan kopyalamaq cari ünvanın dəyişməz sübutu deyil.

Wallet-in address book etiketi yalnız həmin istifadəçi mühitinə aid ola bilər. Explorer label-i də üçüncü tərəf təsnifatıdır. Rəsmi layihə mənbəyi və tam zəncir ünvanı olmadan “official” etiketi qəbul edilmir.

Qısaldılmış `0x1234…abcd` görünüşü iki fərqli ünvan arasında təsadüfi oxşarlıq yarada bilər. Ekran tam ünvanı kopyalamağa imkan verir; yoxlama ilk və son simvolla məhdudlaşmır.

Bytecode oxşarlığı layihə kimliyi deyil

İki müqavilə eyni və ya oxşar bytecode daşıya bilər, çünki standart şablon və klon fabrikindən yaranıb. Kod oxşarlığı həmin müqavilələrin eyni layihəyə, supply-a və adminə aid olduğunu sübut etmir. Deploy transaction, constructor parametrləri və rəsmi mapping ayrıca tələb olunur.

Minimal proxy klonunda runtime bytecode hədəf implementasiyanı göstərə bilər. Klonun immutable argument-ləri, owner və state-i yenə fərqli ola bilər. Yalnız implementasiya auditini bütün klonlara qeyd-şərtsiz tətbiq etmək olmaz.

Doğrulanmamış kod avtomatik saxta token demək deyil, amma hansı funksiyanın işlədiyini açıq yoxlamağı çətinləşdirir. Nəticə məhdud statusla saxlanır.

Kimlik dosyesinin qəbul meyarı

Dosye chain, tam contract və ya mint, rəsmi mənbə, explorer giriş nöqtəsi, obyekt tipi və müşahidə vaxtı olmadan tamamlanmış sayılmır. EVM üçün proxy və verification, Solana üçün mint və authority sahələri ayrıca status alır. Çatışmayan sahə başqa göstəricidən təxmin edilmir.

Bu meyar tokenin dəyəri və ya gələcək davranışı barədə nəticə vermir. O, bütün sonrakı bazar və risk araşdırmasının eyni, dəqiq obyekt haqqında danışmasını təmin edir. Kimlik sabitləşmədən daha mürəkkəb analiz yalnız yanlış obyekt barədə daha çox detal yaradar.