Token müqaviləsində mint, dondurma və owner səlahiyyətlərini oxumaq

Explorer səhifəsində ad, onluq dəqiqlik və ümumi təklif ilk gözə dəyən sahələrdir. Onları oxumaq asandır. Çətin sual bir addım sonra gəlir: bu rəqəmləri sabah kimsə dəyişə bilərmi. Səhifədə “kim dəyişə bilər” adlı hazır sütun yoxdur.

Səlahiyyət zəncirdə oxunan bir şeydir, sadəcə tək yerdə toplanmayıb. O, müqavilənin seçdiyi giriş nəzarəti modelinə, ünvanın arxasında dəyişdirilə bilən məntiqin olub-olmadığına və Solana tərəfdə əlinizdəki açarın hansı mərtəbəyə aid olduğuna görə parçalanır. Aşağıda həmin parçaları hansı ardıcıllıqla oxumaq izah olunur.

Burada heç bir token təhlükəsiz və ya təhlükəli elan edilmir, qiymət proqnozu verilmir, alqı-satqı tövsiyə olunmur.

Standartın siyahısı harada bitir

EIP-20 mətni interfeysi dəqiq sadalayır: name, symbol, decimals, totalSupply, balanceOf, transfer, transferFrom, approve, allowance, üstəgəl Transfer və Approval hadisələri. Siyahı burada bitir. mint, burn, pause, owner, dondurma və qara siyahı — heç biri standartın içində deyil.

Bu faktın praktik istifadəsi tərsinədir. Bir token əlavə emissiya və ya dayandırma imkanına malikdirsə, həmin imkan standartın nəticəsi olduğu üçün yox, müqavilədə ayrıca yazıldığı üçün mövcuddur. Deməli “o, standart ERC-20-dir” cümləsindən nə “emissiya edə bilməz”, nə də “emissiya edə bilər” çıxarılır. Standart doqquz funksiya və iki hadisə ilə məhdudlaşır, qalanı tətbiqin öhdəsinə buraxılır.

Ona görə sualın forması dəyişir: standartdan artıq nəyin yazıldığını və həmin funksiyaları kimin çağıra bildiyini soruşmaq lazım gəlir. Cavab standart sənədində yoxdur.

Proxy və implementation yuvası: oxuduğunuz kod hələ də icra olunurmu

Proxy quruluşu yuxarıdakı işi bir addım geri çəkir. OpenZeppelin-in proxy sənədi mexanizmi açıq yazır: Proxy fallback təqdim edir və EVM-in delegatecall əməliyyatı ilə gələn bütün çağırışları başqa müqaviləyə ötürür, həmin implementation ünvanı isə dəyişdirilə bilər. Explorer-də açdığınız ünvan hazırda işləyən məntiqin yerləşdiyi yer olmaya bilər.

Bu iki ünvan ERC-1967 tərəfindən təyin olunmuş yuvalarda saxlanılır. implementation yuvası `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`, admin yuvası `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103` kimi göstərilir və hər ikisi eth_getStorageAt ilə oxuna bilər.

Oxuyarkən kiçik bir vərdiş faydalıdır. Yuva bütöv bir yaddaş sözü qaytarır, qısaldılmış ünvan yox; qayıdan dəyəri olduğu kimi köçürün, yalnız sonuncu hissəsini saxlamayın. Tamamilə sıfır oxunubsa, yazılası cümlə “həmin blokda bu yuva boş idi” olur, “bu, proxy deyil” yox. Qeyri-standart proxy tətbiqləri də var.

Proxy-nin öz növləri də fərqlənir. Transparent Proxy-də admin olmayan bütün çağırışlar implementation-a ötürülür; admin-in çağırışları ötürülmür və upgradeToAndCall icra edə bilir. Yəni yeniləmə imkanı yalnız bir kimliyə bağlıdır. UUPS modelində yeniləmə məntiqi implementation-ın içinə köçür, tətbiq UUPSUpgradeable-i miras alıb `_authorizeUpgrade` funksiyasını üstələməlidir, bu yol sonda tamamilə silinə də bilər; daxili mexanizm UUPS ilə uyğun olmayan tətbiqə keçidin qarşısını alır. İki quruluşda “məntiqi kim dəyişə bilər” sualının cavabı fərqli yerdə axtarılır.

Sahib bir sətirdir, rollar ayrı cədvəldir

EVM tərəfdə giriş nəzarətinin iki geniş yayılmış forması var, oxunuşları isə üst-üstə düşmür.

Ownable tək sahib saxlayır. Müqavilə qurularkən owner initialOwner parametri ilə təyin olunur, sonra transferOwnership ilə ötürülə və ya renounceOwnership ilə tərk edilə bilər. OpenZeppelin sənədi sonuncu barədə açıq xəbərdarlıq verir: sahiblik tərk edildikdən sonra onlyOwner ilə qorunan idarəetmə əməliyyatları artıq çağırıla bilməz. Bu xəbərdarlıq iki tərəfə işləyir, çünki eyni cümlə tərk etməzdən əvvəl həmin əməliyyatların çağırıla bildiyini də bildirir.

AccessControl fərqli formadadır. O, səlahiyyətləri bytes32 rol identifikatorları ilə ayırır; sənəddəki nümunə MINTER_ROLE-dur və `keccak256("MINTER_ROLE")` ifadəsindən alınır. DEFAULT_ADMIN_ROLE bütün rolların standart idarəedici roludur. Asanlıqla gözdən qaçan bir qayda da var: susmaya görə hər hansı rolu daşıyan hesab həmin rolu özü verə və ya geri ala bilmir; grantRole və revokeRole çağıranın müvafiq admin rolunu daşımasını tələb edir.

Eyni sənəd nümunə üzərində mint və burn əməliyyatlarının rollarla məhdudlaşdırıldığını göstərir. Bu, birinci bölmənin nəticəsini təsdiqləyir: emissiya səlahiyyəti genişləndirmə və rol quruluşundan gəlir, ERC-20 standartının özündən yox. Yalnız owner sahəsini oxuyub dayanan araşdırmada rollarla idarə olunan emissiya, dayandırma və parametr dəyişikliyi ümumiyyətlə görünmür.

Solana-da mint authority və freeze authority ayrı mərtəbələrdədir

Solana tərəfdə ilk sual dəyişir: baxdığınız hesab hansı mərtəbəyə aiddir.

Mint Account mərtəbəsində iki sahə durur. mint authority həmin tokenin yeni vahidlərini yaratmağa, təklifi artırmağa səlahiyyətli hesabdır; mint authority yoxdursa, bu mint sabit təklifə malikdir və yeni vahid yaradıla bilməz. freeze authority isə hansısa Token Account-dakı tokenləri dondurmağa, onların köçürülməsini və ya yandırılmasını dayandırmağa səlahiyyətli hesabdır. Sənəddə hər iki sahənin Rust quruluşundakı tipi boş ola bilən seçim tipidir; deməli “dəyər yoxdur” qanuni və mənalı bir vəziyyətdir, “oxuya bilmədim” ilə eyni şey deyil.

Token Account ayrı mərtəbədir. Onun owner sahəsi həmin Token Account-dan token köçürməyə səlahiyyətli hesabı göstərir, əlavə olaraq delegate sahəsi və ona uyğun icazə həcmi mövcuddur. Bu mərtəbə tək hesab səviyyəsində işləyir və yalnız həmin balansın hərəkətini idarə edir.

Mərtəbələri qarışdırmaq qəribə nəticələr doğurur. Böyük balansı olan bir ünvan öz Token Account-unda owner-dir, bu isə yalnız həmin balansı hərəkət etdirə bildiyini bildirir; ümumi təklifin artırıla bilməsi ilə əlaqəsi yoxdur. Tərsinə, mint mərtəbəsindəki freeze authority sahəsində dəyər durursa, oxunan şey yalnız bu imkanın həmin token üzərində mövcud olmasıdır: neçə dəfə və kimə qarşı işlədildiyi bu sahədən görünmür.

Doğrulama səviyyəsi hansı funksiyaları oxuya biləcəyinizi müəyyən edir

Yuxarıdakı addımlar bir şeyi ehtimal edir: mənbə kodu sizə açıqdır. Bu açıqlığın özü səviyyələrə bölünür.

Etherscan bilik bazası mənbə doğrulamasını developer-in zəncirdəki müqavilənin mənbə kodunu sübut edib ictimailəşdirməsi kimi təsvir edir; bunun sayəsində istifadəçi kodu oxuya və hansısa funksiyanın həqiqətən elan etdiyi işi görüb-görmədiyini müstəqil yoxlaya bilir. Doğrulama dörd vəziyyətə ayrılır: Unverified; Similar Match — constructor arguments nəzərə alınmır; Exact Match — constructor arguments daxil olmaqla; Runtime Match — deployment bytecode və constructor arguments nəzərə alınmır.

Bu səviyyələrin fərqi səlahiyyət oxumasında konkret hiss olunur. Doğrulamanın özü mənbə kodunu ictimailəşdirmək əməliyyatı olduğuna görə, Unverified sadəcə həmin əməliyyatın hələ baş vermədiyini bildirir: owner, rol və yeniləmə funksiyalarının oxunaqlı adı olmur. Qalan üç səviyyə arasındakı fərq uyğunluğun nəyi əhatə etməsindədir: Similar Match constructor arguments-i nəzərə almır, Runtime Match deployment bytecode ilə constructor arguments-in hər ikisini kənarda saxlayır, yalnız Exact Match constructor arguments-i də hesaba qatır. Bunu qeyd etmək lazımdır, çünki initialOwner məhz qurulma anında təyin olunan parametrdir. Üstəlik dörd səviyyədən yalnız Exact Match daxili Read / Write contract düymələri ilə qarşılıqlı əlaqə imkanı verir.

Bir məqamı da dəqiq yazmaq lazımdır. Mənbə doğrulaması yalnız bir suala cavab verir: mənbə kodu zəncirdəki bytecode ilə uyğun gəlirmi. Bu hədd sayt daxilində risk balı olmadan araşdırma yazısında izah olunub; burada yalnız onun səlahiyyət oxumasına birbaşa nəticəsi əlavə edilir: doğrulama səviyyəsi neçə funksiya adını oxuya biləcəyinizi müəyyən edir, həmin adların arxasında nə yazıldığını yox. Bu nəticə sadalanan müddəalardan çıxarılan öz mülahizəmizdir, hər hansı platformanın rəsmi bəyanatı deyil.

Niyə proxy yuvası owner-dən əvvəl oxunur

Proxy yuvaları owner-dən əvvəl oxunur. Bu ardıcıllıq təsadüfi seçilməyib.

owner oxumaq əməliyyatı özü bir şərtə söykənir: oxuduğunuz kod hazırda icra olunan koddur. Ünvanın arxasında proxy varsa, admin yuvasından kənarda gördüyünüz səlahiyyət funksiyaları hansısa bir implementation-a aiddir. Əvvəlcə implementation-ı təsbit etsəniz, sonra oxunan owner və rollar aydın bir obyektə bağlanır; tərsinə işləyəndə proxy sonradan aşkarlanarsa qeydlərin çoxu yenidən oxunmalı olur.

Bədəli var: müqavilələrin böyük hissəsi proxy deyil, iki yuvadan iki sıfır alırsınız və zəhmət boşa getmiş görünür. Addım yenə də birinci qalır, çünki proxy-ni ötürməkdən doğan səhv səssiz olur — tam, öz-özü ilə uzlaşan, lakin yanlış obyektə aid bir qeyd alırsınız.

Səlahiyyət qeydində hansı dörd sütun qalır

Yuxarıdakı bölmələri saxlanıla bilən formaya salmaq üçün dörd sütun kifayət edir: müşahidə sahəsi, oxunan dəyər, oxuma vaxtı və blok, hələ müəyyən edilməyən hissə. Bal yoxdur, çəki yoxdur, rəng verilmir. Aşağıda hər müşahidə sahəsi ayrıca sadalanır: başlığın özü müşahidə sahəsidir, altındakı üç sətir isə qalan üç sütundur.

ERC-1967 implementation yuvası

• Oxunan dəyər: bütöv yaddaş sözünün xam dəyəri
• Oxunma vaxtı və blok: vaxt və blok hündürlüyü
• Hələ müəyyən deyil: qeyri-standart proxy ehtimalı

ERC-1967 admin yuvası

• Oxunan dəyər: bütöv yaddaş sözünün xam dəyəri
• Oxunma vaxtı və blok: vaxt və blok hündürlüyü
• Hələ müəyyən deyil: admin ünvanının arxasındakı quruluş

Doğrulama vəziyyəti

• Oxunan dəyər: dörd səviyyədən biri
• Oxunma vaxtı və blok: müşahidə tarixi
• Hələ müəyyən deyil: doğrulanmayıbsa funksiyaların mənası

owner

• Oxunan dəyər: ünvan və ya sıfır ünvan
• Oxunma vaxtı və blok: blok hündürlüyü
• Hələ müəyyən deyil: həmin ünvanın hesab növü

Tapılan rollar

• Oxunan dəyər: rol identifikatoru və daşıyıcı
• Oxunma vaxtı və blok: blok hündürlüyü
• Hələ müəyyən deyil: sadalanmamış digər rollar

mint authority

• Oxunan dəyər: ünvan və ya boş dəyər
• Oxunma vaxtı və blok: slot
• Hələ müəyyən deyil: keçmişdə dəyişdirilib-dəyişdirilmədiyi

freeze authority

• Oxunan dəyər: ünvan və ya boş dəyər
• Oxunma vaxtı və blok: slot
• Hələ müəyyən deyil: faktiki istifadə tarixçəsi

Sahə oxunmayanda “əldə edilmədi” yazılır, sıfır yox. Sonrakı istinadlarda bu ikisinin mənası köklü şəkildə fərqlənir.

Sahələri doldurduqdan sonra da bilinməyənlər

Sütunları doldurmaq bəzi sualları həll etmir.

owner sahəsi sizə bir ünvan verir, həmin ünvanın hansı hesab formasına aid olduğunu isə zəncir özü elan etmir; bunu ayırd etmək artıq növbəti oxuma dövrəsidir və owner sütunundan çıxarıla bilməz.

Sahibliyin tərk edilməsi də səlahiyyətlərin sıfırlanması demək deyil. Bir müqavilə eyni vaxtda həm Ownable, həm rollar işlədə bilər, üstəlik proxy arxasında dayana bilər. owner-in sıfır ünvana keçməsi yalnız onlyOwner qrupunun bağlandığını göstərir; rol daşıyıcıları və proxy admin-i ayrıca oxunur.

Sonuncu məsələ niyyətdir. Sadalanan sahələr imkanı təsvir edir. Hansısa hesabın dondurma imkanına sahib olduğunu oxumaq yalnız bunu dəstəkləyir: həmin anda bu imkan mövcuddur və bu hesaba yönəlib. Həmin imkanın nə vaxtsa istifadə olunub-olunmadığı, gələcəkdə istifadə olunacağı isə ayrı sübut tələb edir; burada təsvir olunan oxunuş bu suala cavab vermir.

Səlahiyyət dəyəri niyə blok hündürlüyünə bağlanır

Səlahiyyət vəziyyəti dəyişkəndir. transferOwnership istənilən blokda icra oluna bilər, implementation da dəyişdirilə bilər. Hər müşahidə sahəsinin yanında blok hündürlüyünün durmasının səbəbi budur: həmin hündürlükdən kənarda dəyərlər tarixi qeyd statusuna keçir.

Bu, köhnə qeydlərə istinad qaydasına da təsir edir. Üç ay əvvəl “mint authority boşdur” oxunubsa, bu gün dəstəklənən ifadə “üç ay əvvəlki müşahidədə boş idi” olur. Yeni dəyər fərqlidirsə, iki qeydi yan-yana saxlamaq köhnəsini üstündən yazmaqdan daha çox məlumat verir.

Kimlik ilə səlahiyyəti birləşdirmək istəyirsinizsə, müqavilə ünvanının yoxlanması yazısı işin birinci yarısına aiddir: hansı şəbəkədəki hansı obyekti oxuduğunuzu təsbit etmək.

Tez-tez verilən suallar

Müqavilə doğrulanıbsa, emissiya səlahiyyəti yoxdur demək olarmı?

Doğrulama mənbə kodu ilə zəncirdəki bytecode arasındakı uyğunluğu göstərir və kodu oxumağa imkan verir. Kodun içində rol və ya owner ilə qorunan emissiya funksiyasının olub-olmadığını isə özünüz oxumalısınız. Doğrulama səviyyəsi nə qədər oxuya biləcəyinizi müəyyən edir, kodun məzmununu yox.

owner sıfır ünvandırsa, bütün səlahiyyətlər bitibmi?

Yalnız onlyOwner ilə qorunan əməliyyatların çağırıla bilmədiyini demək olar; OpenZeppelin sənədinin renounceOwnership barədə xəbərdarlığı məhz bundan bəhs edir. Müqavilə əlavə olaraq rollar işlədirsə və ya proxy arxasındadırsa, həmin səlahiyyətlər öz yerlərində oxunmalıdır.

Solana-da bir ünvan owner görünürsə, o, emissiya edə bilərmi?

Əvvəlcə bunun hansı mərtəbənin owner-i olduğuna baxmaq lazımdır. Token Account-un owner-i həmin hesabdan token köçürməyə səlahiyyətlidir və tək balansı idarə edir; yeni vahid yaratmaq imkanı isə Mint Account mərtəbəsindəki mint authority sahəsinə aiddir.