Yandırma ünvanı təklifin azalması demək deyil: dörd sütun

“Yandırıldı” cümləsi tək fakt kimi görünür, əslində eyni anda üç ayrı iddianı daşıyır: hansısa əməliyyat baş verib, onu göndərən tərəfin bunu etməyə əsası olub, və tokenin hansısa təklif sahəsi bunun nəticəsində kiçilib. Cümlə yalnız üçü birlikdə doğru olanda dayanıqlıdır. Təkcə birincisi doğrudursa, təsvir olunan hadisə adi köçürmə də ola bilər.

Eyni köçürmə həm sahib dəyişikliyi, həm də təklifdən çıxma ola bilər və müşahidə səhifəsində bu iki hal bir-birinə oxşayır. Fərqi “yandırıldı” sözü deyil, hər üç iddianın ayrıca yığılması göstərir.

Aşağıda həmin yığma qaydası və araşdırma qeydində saxlanılacaq dörd sütun izah olunur. Buradakı dörd sütun təklif hadisəsinə aiddir; sayt daxilindəki səlahiyyət yazısında işlənən dörd sütunla eyni dəst deyil. Heç bir konkret token müzakirə edilmir, heç bir token təhlükəsiz və ya təhlükəli adlandırılmır, qiymət və alqı-satqı mövzusuna toxunulmur.

EIP-20 sıfır ünvan qaydasını yalnız yaradılış üçün verir

Başlanğıcda bir şeyi dəqiqləşdirmək lazımdır: yandırma ERC-20 standartının əməliyyatı deyil.

EIP-20 mətnində sadalanan metodlar bunlardır: name, symbol, decimals, totalSupply, balanceOf, transfer, transferFrom, approve, allowance. Hadisələr isə yalnız Transfer və Approval. Nə yandırma funksiyası, nə də Burn adlı hadisə siyahıda var. Standart totalSupply barədə cəmi bir cümlə yazır — "Returns the total token supply." — və bu rəqəmin necə dəyişdiyini tənzimləmir.

Standart təklif dəyişikliyi ilə bağlı bir qayda verir, amma əks istiqamətdə: yeni token yaradan müqavilə "SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created". Sıfır ünvan burada from tərəfdə dayanır və vahidlərin yeni yarandığını işarələyir. Yandırma tərəfdə isə standart heç bir to qaydası təyin etmir.

ethereum.org-un ERC-20 izah səhifəsi (səhifə özünü 9 iyul 2026 tarixi ilə işarələyir) mətn boyu burn sözünü ümumiyyətlə işlətmir. Bu, yuxarıdakı müşahidə ilə üst-üstə düşür.

Deməli “bu, standart ERC-20-dir, ona görə yandırma ümumi təklifdə görünəcək” mülahizəsinin dayaq nöqtəsi yoxdur. Konkret bir yandırmanın təklifi azaldıb-azaltmaması müqavilənin öz kodundan və həmin əməliyyatın hansı yoldan keçməsindən asılıdır.

Hadisə sübutu: to sahəsi sıfır ünvandır və ümumi təklif aşağı düşür

Praktikada geniş yayılmış yazılış OpenZeppelin-dən gəlir. Onun 5.x ERC20 sənədi daxili funksiya _burn(account, value) barədə yazır ki, o, account hesabından müəyyən miqdarda tokeni məhv edir, ümumi təklifi aşağı salır və "Emits a IERC20.Transfer event with to set to the zero address".

Bu təsvir iki hissəli imza verir: Transfer hadisəsinin to sahəsi sıfır ünvandır, üstəlik ümumi təklif buna uyğun azalır. Qeydə köçürülməli olan məhz bu iki hissədir, hansısa səhifədəki “yandırıldı” sözü yox.

Hissələrdən biri əskik olanda dəstəklənən ifadə daralır. Yalnız hadisəni yazsanız, sübut etdiyiniz şey to sahəsi sıfır olan bir hadisənin baş verməsidir. Yalnız təklif fərqini yazsanız, sübut etdiyiniz şey iki müşahidə anında rəqəmlərin fərqli olmasıdır, aradakı əməliyyatlar isə naməlum qalır. İkisini yan-yana saxlamaq nəticə cümləsi yazmaqdan ucuz başa gəlir və sonradan yoxlanışa daha yaxşı tab gətirir.

Köçürərkən kiçik bir vərdiş faydalıdır: value dəyərini zəncirdəki xam vahidlə yazın, decimals-i ayrıca sütunda saxlayın, insana oxunaqlı çevrilmiş rəqəmi isə ayrı sətirdə. Üçü bir xanaya yığılanda bir neçə həftədən sonra hansının hansı olduğu itir.

Sıfır ünvana adi köçürmə keçmir — “qara dəlik ünvanı” barədə mülahizə

Eyni sənəd açıq transfer funksiyasının Requirements bəndində yazır: "to cannot be the zero address". transferFrom üçün şərt "from and to cannot be the zero address" formasındadır, xəta tiplərinin siyahısında isə ERC20InvalidReceiver durur.

Bu bəndi əvvəlki bölmənin bəndi ilə birləşdirəndə birbaşa nəticə alınır: adi köçürmə yolu ilə sıfır ünvana çatmaq mümkün deyil. Deməli, ictimai olaraq yandırma ünvanı adlandırılan və eyni zamanda token qəbul edə bilən istənilən ünvan sıfırdan fərqli ünvandır; ora köçürülən qalıq yalnız sahib dəyişir və totalSupply-ın içində qalmağa davam edir. Bu, sadalanan iki bənddən çıxarılan nəticədir və bu yazının öz mülahizəsidir; nə OpenZeppelin-in, nə də hər hansı platformanın rəsmi bəyanatı deyil və istinad edilərkən məhz bu güclə yazılmalıdır.

Hansı ünvanların qara dəlik adlandırıldığına gəlincə: rəsmi tərif əldə edilmədiyi üçün bu versiyada yoxlanılmayıb. Qeyddə “ictimai olaraq yandırma adlandırılan sıfırdan fərqli ünvan” yazılır, ünvanın özü xam şəkildə köçürülür və ona “yandırılıb” etiketi əlavə edilmir. Belə ünvanların sahiblər siyahısına düşməsi paylanma oxunuşunu da əyir, lakin bu, ayrı mövzudur; burada yalnız bir pillə yuxarıdakı sual verilir: həmin ünvan hansı əsasla yandırma ünvanı adlanır.

Hadisə sayını artıran iki hal: sıfır dəyərli köçürmə və ERC20FlashMint

EIP-20-də ayrıca qeyd var: "Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event." Sıfır dəyərli köçürmə də Transfer hadisəsi doğurur. Ona görə “bu tokendə çoxlu yandırma hadisəsi var” cümləsi, hər hadisənin value sahəsi ayrıca oxunmayana qədər, təklif dəyişikliyinə çevrilmir.

İkinci hal ERC20FlashMint ilə bağlıdır. OpenZeppelin onu belə təsvir edir: "token level support for flash loans through the minting and burning of ephemeral tokens", ERC-3156 kimi standartlaşdırılıb. Yaradılma və məhv edilmə eyni əməliyyatın içində cüt halında baş verir, müvəqqəti vahidlər görünüb yox olur. Yalnız sayı hesablayan adam yandırma hadisələrinin artdığını görür, ümumi təklif isə əməliyyat bitəndən sonra əvvəlki yerinə qayıdır.

Hər iki hal eyni vərdişə işarə edir: saymağa başlamazdan əvvəl sayın nəyə aid olduğunu — əməliyyat sayına, yoxsa miqdara — dəqiqləşdirmək lazımdır.

Nəzarət sübutu: yandırma funksiyası genişləndirmədən gəlir, burnFrom allowance tələb edir

İkinci sütun soruşur ki, bu hərəkəti kim başlada bilər və konkret bu əməliyyat hansı əsasla başladılıb.

burn və burnFrom nüvə ERC20-nin içində deyil; onlar extensions/ERC20Burnable.sol genişləndirməsindən gəlir. Eyni sənəd nüvə ERC20 barədə yazır ki, o, "is agnostic to the way tokens are created" — yəni həm yaradılma, həm də məhv etmə tərəfi tətbiqin öhdəsinə buraxılır. Müqavilədə açıq yandırma girişinin olub-olmaması ancaq həmin müqavilənin kodundan oxunur, “o, ERC-20-dir” cümləsindən çıxarılmır.

burnFrom(account, value) çağırışı isə çağıranın allowance həcmindən çıxılır; sənəd açıq yazır ki, çağıran account-un tokenləri üzrə ən azı value həcmində icazəyə malik olmalıdır. Qeyd baxımından bunun faydası iki ünvanı ayırmaqdır: əməliyyatı imzalayan tərəf ilə balansı azalan tərəf eyni olmaya bilər. “Filan ünvan token yandırdı” cümləsi bu qatı itirir.

Həmin səlahiyyətləri kimin daşıdığı və sonradan yeni vahid yaradıla bilib-bilməyəcəyi ayrıca oxunuş tələb edir; sayt daxilində müqavilə səlahiyyətlərini oxumaq yazısı bununla məşğuldur. Burada yalnız bir xatırlatma qalır: nəzarət sütunu konkret bu əməliyyatın imza əsasını saxlayır, ümumi səlahiyyət mənzərəsi isə başqa sətirdə yazılır.

ERC20Capped: yandırma yuxarı həddi aşağı salmır

Bəzən yandırma ilə təklif həddi bir-birinə bağlanır: nə qədər yandırılıbsa, tavan da bir o qədər enir. Sənəd bunu təsdiqləmir.

ERC20Capped-də cap "is immutable, it can only be set once during construction"; hədd aşılanda ERC20ExceededCap(increasedSupply, cap) xətası atılır. Mexanizm təklifin artması istiqamətini məhdudlaşdırır, sənəddə yandırmanın cap-i azaltması barədə heç nə yazılmır.

Buna görə qeyddə iki xana ayrılır: hadisədən sonra totalSupply neçədir və cap dəyişibmi. Əksər hallarda ikinci xananın cavabı “dəyişməyib” olur, amma onu yazmaq həmin şeyi yoxladığınızı bildirir.

Solana tərəfdə Burn, BurnChecked və dondurma səlahiyyəti

Solana-da eyni məsələ tamam başqa sözlərlə ifadə olunur.

Rəsmi sənəd yazır ki, yandırma "permanently decreases a token account balance and reduces the mint's total supply by the same amount"; icra Token Program-ın Burn və ya BurnChecked təlimatı ilə gedir. Hesab qalığı ilə mint-in ümumi təklifi eyni anda azalır və bu, EVM tərəfdəki quruluşdan daha birbaşa yazılıb.

BurnChecked əlavə parametr istəyir: çağıran mint-in decimals dəyərini təqdim etməlidir ki, təlimat "verify the expected token precision before burning" edə bilsin. Əməliyyatın BurnChecked ilə getdiyini görmək qeydə bir fakt əlavə edir — dəqiqlik zəncir üzərində yoxlanılıb.

İmza tərəfində sənəd token hesabının owner-ini və ya təsdiqlənmiş delegate-i göstərir; Token Extension Program şəraitində mint-in permanent delegate-i də yandırmaya icazə verə bilər. permanent delegate-in tam semantikası üzrə bu versiyada yalnız həmin bir cümlə əldə edilib, qalanı yoxlanılmayıb, ona görə qeyd də bu cümlənin gücündən artıq yazılmır.

İki məhdudiyyət ayrıca sətir tələb edir. Birincisi: "The native mint does not support burning. Use CloseAccount instead." CloseAccount-un təklif sahələrinə hansı təsiri olması bu versiyada yoxlanılmayıb və nəticə çıxarılmır. İkincisi: freeze authority tərifə görə 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. Yəni eyni səlahiyyət həm köçürməni, həm də yandırmanı dayandırır; oxuyarkən adətən yalnız birinci hissə yadda qalır.

Mint vəziyyətində mint_authority, supply, decimals, is_initialized və freeze_authority sahələri saxlanılır. Sənədin ifadəsi belədir: mint authority yoxdursa, mint sabit təklifə malikdir və yeni vahid yaradıla bilməz. Tərsinə oxunanda bu o deməkdir ki, mint authority qalırsa, indi azaldılan miqdarın sonradan bərpa olunub-olunmayacağı sualına yandırma qeydi cavab vermir.

Dörd sütun: bir yandırma iddiasından nə qalır

Sütun adları sayt daxilindəki təklif, bazar dəyəri və FDV yazısındakı bölgü ilə uzlaşır; orada təsnifat verilir, burada isə hər xananın necə doldurulduğu.

Ardıcıllıq belədir: hadisə, nəzarət, vaxt, təsirlənən təklif sahəsi. Nəzarət vaxtdan əvvələ qoyulub, çünki vaxt sütunu ən rahat doldurulandır və onu birinci yazan adam iki hündürlük arasındakı fərqi elə həmin əməliyyatın hesabına keçirməyə meyllidir; yavaş oxumağın yeganə qazancı odur ki, bütün xanaları dolu bir qeyd yanlış əməliyyata bağlanmır.

Doldurarkən iki qayda dəyişmir. Birincisi: hadisənin to sahəsi sıfırdan fərqlidirsə “həmin ünvana köçürüldü” yazılır, səhifədəki ifadədən asılı olmayaraq “yandırıldı” yazılmır. İkincisi: sahə əldə edilmirsə “əldə edilmədi” yazılır, sıfır yox — təklif fərqi məhz bu xanalardan çıxma yolu ilə hesablanır, sıfır real çıxılan, “əldə edilmədi” isə boş xanadır; ikisi qarışanda yekun fərq artıq və ya əskik çıxır.

Hadisə sübutu

Bu sütunun ölçüsü sadədir: yalnız onun məzmunu ilə başqa bir adam eyni əməliyyatı tapıb yenidən oxuya bilməlidir.

• Şəbəkə və müqavilə ünvanı, Solana tərəfdə mint ünvanı, xam şəkildə
• Əməliyyat heşi
• Faktiki çağırılan funksiya və ya təlimat: _burn, burnFrom, Burn, BurnChecked, yaxud sadəcə transfer
• Hadisənin from, to, value sahələri ayrı xanalarda; to sıfırdan fərqlidirsə “həmin ünvana köçürüldü” yazılır, “yandırıldı” yox
• value xam vahidlə, decimals ayrıca, çevrilmiş rəqəm isə ayrı sətirdə
• value sıfırdırsa, hadisə yenə də mövcuddur; belə sətir sıfır dəyərli köçürmə kimi işarələnir və miqdar xanasına düşmür

Nəzarət sübutu

Bu sütun ən çox yarımçıq qalır: imzalayan ünvan ilə balansı azalan ünvan ayrı-ayrı xanalarda saxlanmasa, əməliyyatın hansı əsasla mümkün olduğu görünmür.

• Əməliyyatı kim imzalayıb
• Hansı əsasla: öz balansı, allowance, delegate, yaxud permanent delegate
• Sonradan təklifin artma yolu qalırmı: mint_authority yerindədirmi, müqavilədə yaradılma girişi varmı
• Əldə edilməyən hissə olduğu kimi yazılır, “yəqin ki yoxdur” ilə əvəz edilmir

Vaxt

Vaxt sütunu səbəb-nəticə göstərmir; onun işi iki oxunuşu müqayisə oluna bilən nöqtələrə bağlamaqdır.

• Əməliyyatın blok hündürlüyü və ya slotu
• Əvvəlki oxunuşun hündürlüyü və sonrakı oxunuşun hündürlüyü, iki ayrı xanada
• Səhifənin müşahidə vaxtı, zəncir hündürlüyündən ayrı
• İki oxunuş arasında başqa əməliyyatlar varsa, bir cümlə ilə qeyd olunur

Təsirlənən təklif sahəsi

Nəticənin dili bu sütundan asılıdır: hansısa təklif sahəsinin nə qədər azaldığı yazılmayıbsa, qalan üç sütun birlikdə yalnız bir köçürməni təsvir edir.

• totalSupply və ya mint-in supply dəyəri azalıbmı, nə qədər
• Yoxsa yalnız bir ünvanın qalığı dəyişib, ümumi rəqəm yerindədir
• cap xanası toxunulmamış qalıbmı
• Provayder səhifəsindəki təklif rəqəmi “ayrıca yoxlanılsın, bu hadisə ilə sübut olunmayıb” işarəsi ilə saxlanılır; provayderlərin “daimi yandırma” meyarı bu versiyada yoxlanılmayıb və burada nəticə çıxarılmır

İki sərhəd də bu sütuna aiddir: protokol səviyyəsində şəbəkənin öz vahidinin yandırılması bu yazıdakı token müqaviləsi mexanizmi ilə eyni deyil, bu versiyada yoxlanılmayıb və açılmır; çoxşəbəkəli tokenlərdə bir şəbəkədə oxunan azalma yalnız həmin şəbəkədəki müqavilənin vəziyyətini bildirir, digər şəbəkələr ayrıca qeyd olunur.

Tez-tez verilən suallar

Token ictimai yandırma ünvanına köçürülübsə, ümumi təklif azalıbmı?

Həmin ünvanın sıfır ünvan olub-olmadığına baxmaq lazımdır. OpenZeppelin sənədi transfer üçün to sahəsinin sıfır ünvan ola bilməyəcəyini yazır; token qəbul edə bilən ünvan sıfır deyil, deməli qalıq totalSupply-ın içində qalır. Bu addım bənddən çıxarılan nəticədir və yazının öz mülahizəsidir. Təklif azalmasının imzası isə Transfer hadisəsində to sahəsinin sıfır olması və ümumi təklifin düşməsidir.

Müqavilədə burn funksiyası varsa, bu, yandırmanın baş verəcəyi anlamına gəlirmi?

burn və burnFrom ERC20Burnable genişləndirməsindən gəlir; onların mövcudluğu yalnız həmin girişin koda yazıldığını bildirir. Kimin çağıra bildiyi və çağırılıb-çağırılmadığı ayrı suallardır. burnFrom üçün əlavə olaraq kifayət qədər allowance tələb olunur.

Yandırma hadisələri çoxdursa, təklif niyə demək olar dəyişmir?

Hadisə sayı ilə miqdar eyni şey deyil. Sıfır dəyərli köçürmə də standarta görə Transfer hadisəsi doğurur; flash mint tipli mexanizmlərdə yaradılma və məhvetmə eyni əməliyyatın içində cüt gedir və sonda ümumi rəqəm əvvəlki yerinə qayıdır. Çevirmə yalnız hər hadisənin value sahəsi oxunandan sonra mümkündür.

Tokenin “həmişəlik yandırıldığını” yazmaq olarmı?

Bu dörd sütun “həmişəlik” sözünü daşımır. Onların dəstəklədiyi ifadənin forması dardır: müəyyən hündürlükdə müəyyən əməliyyat müəyyən funksiyanı çağırıb və müəyyən təklif sahəsi filan dəyərə keçib. Solana sənədindəki permanently sözü isə həmin azalmanın özünün geri qaytarılmadığını bildirir; təklif səviyyəsinin bir daha qalxmayacağı mənasına gəlmir — bu sual mint authority-nin yerində olub-olmaması ilə həll olunur, EVM tərəfdə isə yaradılma funksiyası və səlahiyyət quruluşu ilə.

Eyni şəkildə çıxarıla bilməyən iki şey də var. Birincisi niyyətdir: qeyd baş vermiş vəziyyət dəyişikliyini təsvir edir, səbəbini və gələcəkdə təkrarlanıb-təkrarlanmayacağını göstərmir. İkincisi ümumi rəqəmdən kənar paylanmadır: bir təklif sahəsinin kiçilməsi qalan hissənin kimin əlində olduğunu və cəmləşmənin dəyişib-dəyişmədiyini demir, bu ayrıca oxuma dövrəsi tələb edir.

Bu qeyddən yadda saxlanılası cümlə budur: yandırma sütunu təklifin yenidən artıb-artmayacağı sualına cavab vermir.