Blok explorerini oxumaq: hash-dən statusa, hesabdan hadisəyə

Qatar biletindəki seriya nömrəsi səfəri tapmağa kömək edir, amma sərnişinin niyə getdiyini, vaqonda nə baş verdiyini və yükün kimə məxsus olduğunu izah etmir. Stansiyanın hadisə jurnalı daha çox detal verə bilər, yenə də həmin detalı düzgün qatla oxumaq lazımdır.

Transaction hash və ya Solana signature da axtarış açarıdır. Explorer onun ətrafında status, ünvan, ödəniş, proqram çağırışı, token hadisəsi və platformanın öz etiketlərini toplayır. Bu sahələrin eyni ekranda görünməsi onların eyni sübut gücünə malik olması demək deyil.

Birinci qat şəbəkə və tam identifikatordur

Etherscan sənədi tx hash-i blokçeyndəki əməliyyat üçün unikal identifikator kimi izah edir. Lakin identifikator şəbəkədən kənarda təkbaşına kifayət etmir. Ethereum mainnet, başqa EVM chain, Solana mainnet-beta və test mühitləri ayrı vəziyyət məkanlarıdır.

Minimum başlanğıc qeydi chain və ya cluster adı, chain ID mümkündürsə həmin dəyər, tam hash/signature, istifadə edilən explorer URL-si və müşahidə vaxtından ibarətdir. Qısaldılmış hash ekran oxunaqlılığı üçündür; sübut faylında tam dəyər saxlanır.

Explorer axtarışında nəticə çıxmaması da şəbəkəsiz hökm deyil. Yanlış chain seçilə, provider gecikə, Solana sorğusunda commitment fərqli ola və ya indeksləşdirici müvəqqəti cavab verməyə bilər. “Bu sorğuda bu vaxt tapılmadı” ilə “zəncirdə mövcud deyil” ayrı nəticələrdir.

Daxil edilmə və icra statusu eyni cümlə deyil

Transaction bir bloka daxil edilə bilər, lakin çağırılan məntiq uğursuz ola bilər. Explorer-də status, block, confirmation və timestamp sahələri əvvəl ayrılıqda oxunur. “Success” adətən zəncir qaydalarına görə icranın səhvsiz tamamlandığını göstərir; insanın gözlədiyi iqtisadi nəticənin əldə edildiyini avtomatik sübut etmir.

Confirmation sayı və finality anlayışı şəbəkəyə görə dəyişir. Müəyyən anda bir neçə confirmation görünməsi gələcəkdə bütün risklərin sıfır olduğu demək deyil. Qeyddə explorer-in göstərdiyi konkret vəziyyət və vaxt saxlanır, sonra müşahidə yenilənərsə əvvəlki sətir silinmir.

Failed transaction üçün də yalnız “uğursuz” yazmaq yetərli deyil. EVM-də gas xərci yarana bilər; çağırışın hansı mərhələdə revert olduğu və token hadisələrinin baş verib-vermədiyi ayrıca baxılır. Məbləğin, fee-nin və state change-in hamısını bir status sözündən çıxarmaq olmaz.

EVM səhifəsində göndərən, hədəf və value-ni ayır

Etherscan tx səhifəsi from, to, value, transaction fee/gas, nonce və input data kimi sahələri göstərir. `from` transaction-u imzalayan ünvanı, `to` isə birbaşa çağırılan hədəfi göstərə bilər. Müqavilə daxilində son token alan ünvan `to` ilə eyni olmaya bilər.

`value` EVM-in yerli aktivinin transaction-la göndərilən hissəsidir. ERC-20 transfer məbləği çox vaxt input və log/event qatında görünür. Buna görə explorer başlığında zero native value görmək “heç nə köçməyib” nəticəsi vermir; token hərəkəti ayrıca araşdırılır.

Gas limit, gas used və fee də token məbləği deyil. Onlar icra resursu və şəbəkə ödənişi haqqında məlumat verir. Yüksək fee token dəyərini, aşağı fee isə əməliyyatın təhlükəsizliyini göstərmir. Fee hansı yerli aktivdə ölçülürsə vahid açıq saxlanır.

Nonce göndərən hesabın transaction ardıcıllığı ilə əlaqəlidir. O, token transferinin sıra nömrəsi və ya istifadəçinin saytdakı hesab ID-si deyil. Bu sahənin mənası yalnız göndərən EVM hesabı kontekstində yazılır.

Input, daxili çağırış və log ayrı izlərdir

Müqaviləyə göndərilən input data hansı funksiya selector-u və arqumentlərin kodlaşdırıldığını göstərə bilər. Explorer verified source və ABI tapdıqda bunu insan dilinə yaxın formada aça bilər. Dekodlaşdırılmış etiket faydalıdır, amma explorer-in interpretasiyasıdır; xam input və hədəf ünvanı saxlanmadan tək etiket sübut sayılmır.

Müqavilə başqa müqavilələri çağıra bilər. Daxili çağırışlar icra yolunu göstərir, token logları isə standart event forması ilə dəyişiklik izi verə bilər. Hər daxili çağırış ayrıca istifadəçi əməliyyatı deyil; hər log da hüquqi ödəniş sənədi deyil.

Event-də `from` və `to` sahələri görünəndə onların token müqaviləsinin hadisə arqumentləri olduğu qeyd edilir. Bunları transaction envelope-un `from` və `to` sahələri ilə qarışdırmaq vasitəçi, router və multisend əməliyyatlarında yanlış nəticə yaradır.

Tokenin tam müqavilə ünvanı event-i hansı aktivlə bağladığımızın əsas hissəsidir. Simvol və loqo kifayət etmir. Proxy, bridge və wrapped token varsa əlaqə ayrıca mənbə tələb edir.

Balans dəyişikliyi niyyəti sübut etmir

Explorer bir transaction əvvəl və sonra balans dəyişikliklərini göstərə bilər. Dəyişiklik müşahidədir, səbəb və sahiblik şərhi deyil. Ünvanın token alması həmin ünvanın real dünyada hansı şəxsə aid olduğunu, alıcının ödəniş etdiyini və transferin könüllü olduğunu göstərmir.

Bir hesabın balansı fee, rent, refund, daxili çağırış və başqa proqram hərəkətləri ilə dəyişə bilər. Yekun fərqi yalnız başlıqdan oxumaq əvəzinə hadisələr, çağırışlar və hesab növləri yoxlanır. Tokenin onluq dəqiqliyi də xam vahidin ekrandakı məbləğə necə çevrildiyini müəyyən edir.

“Böyük cüzdan aldı” kimi sosial media nəticəsi üçün transaction səhifəsi təkbaşına kifayət etmir. Aktiv kimliyi, ünvanın sübut edilmiş əlaqəsi, əvvəl/sonra vəziyyəti və alternativ izahlar lazımdır. Explorer etiketi bu boşluqları avtomatik doldurmur.

Solana-da transaction hesablar və instructions üzərində işləyir

Solana core sənədləri accounts-un vəziyyət saxladığını, programs-ın stateless icra məntiqi olduğunu, instructions-un transaction daxilində birləşdiyini və transaction-un atomik olduğunu izah edir. Bu modelə görə “contract balance” ifadəsini EVM-dən olduğu kimi köçürmək düzgün deyil.

Solana qeydi cluster, tam signature, slot, block time varsa həmin dəyər, transaction message, account keys, instructions və `meta` qatlarını ayırır. `getTransaction` sənədinə görə seçilmiş commitment-də transaction tapılmadıqda cavab null ola bilər. Null permanent yoxluq deyil; RPC endpoint, commitment və sorğu vaxtı saxlanır.

`meta.err` icra nəticəsini, `fee` şəbəkə ödənişini, `innerInstructions` proqramlararası çağırış izlərini, `logMessages` isə icra loglarını göstərə bilər. Sahələrin nullable olması “boş siyahı” ilə eyni deyil. Provider cavabında meta yoxdursa nəticə uydurulmur.

Atomiklik transaction daxilindəki instructions-un ümumi icra sərhədidir. Bu, xarici xidmətin verdiyi vədin, sonrakı başqa transaction-un və ya offchain hesabın atomik olması demək deyil.

Mint account ilə token account-u qarışdırma

Solana SPL Token Basics mint account-u tokenin ortaq kimliyi və supply/authority məlumatı üçün, token account-u isə müəyyən sahibin müəyyən mint üzrə balansı üçün ayırır. Explorer-də böyük balanslı account görmək onu mint etmir. Aktiv kimliyi üçün mint ünvanı, sahib balansı üçün mintə bağlı token account lazımdır.

Transaction daxilində pre/post token balances görünəndə account index, mint, owner sahəsi varsa həmin dəyər və decimals birlikdə oxunur. Xam miqdar decimals olmadan insan üçün göstərilən token vahidi deyil. Owner etiketi də real dünyadakı benefisiar sahibliyi sübut etmir.

Associated token account rahatlıqla yaradılan ünvan modelidir, amma hər token account-un bütün iqtisadi nəzarətini tək adla izah etmək olmaz. Delegate, authority və proqram idarəsi kimi sahələr tədqiqat sualına uyğun ayrıca yoxlanır.

EVM Transfer event-i ilə Solana token balance dəyişməsini eyni sütuna yerləşdirmək olar, ancaq source model sahəsi qalmalıdır. Biri log hadisəsi, digəri account vəziyyəti fərqi ola bilər; “token movement” onların yuxarı səviyyəli təsviridir, xam sübutu əvəz etmir.

Explorer etiketi və screenshot son qatdır

Explorer name tag, token loqosu, dekodlaşdırılmış funksiya adı və “interacted with” kimi rahat xülasələr verə bilər. Bunlar naviqasiya qatıdır. Etiket dəyişə, səhv ola və ya platformanın offchain məlumatına əsaslana bilər. Tam ünvan və xam chain vəziyyəti ayrıca qalır.

Screenshot yalnız çəkildiyi anda görünən səhifəni saxlayır. Hash kəsilibsə, şəbəkə görünmürsə və URL qeyd olunmayıbsa təkrar yoxlama zəifləyir. Şəkildəki yaşıl status konkret icranı göstərə bilər, amma dairəyə alınmış mətnin bütün şərhini sübut etmir.

Bu məqalədə saxta explorer interfeysi və hesab hekayəsi istifadə edilmir. Əməliyyat sahələri rəsmi sənədlərdən izah olunur. Gələcəkdə konkret public transaction screenshot-u lazım olsa orijinal fayl, mənbə URL-si, çəkilmə vaxtı və dəyişdirilmə qeydi sübut reyestrində saxlanmalıdır.

Proxy müqaviləsində iki ünvanı saxla

Explorer proxy etiketi göstərirsə istifadəçinin toxunduğu proxy ünvanı ilə kodun yerləşdiyi implementasiya ünvanı ayrı yazılır. State çox vaxt proxy ünvanında, funksiya məntiqi implementasiyada olur. Yalnız implementasiya səhifəsinə baxmaq cari storage və admin vəziyyətini göstərmir.

Implementasiya slotu, admin slotu və upgrade hadisəsi oxunan blokla saxlanır. Cari implementasiyanı köhnə transaction-a tətbiq etmək olmaz; həmin blokdakı kod ünvanı tələb olunur. Explorer-in “read as proxy” rahat görünüşü bu zaman sərhədini avtomatik izah etməyə bilər.

Doğrulanmış mənbə kodu faydalıdır, lakin deploy edilmiş bytecode ilə uyğunluq etiketi və compiler parametrləri yoxlanır. Kodun oxunaqlı olması onun təhlükəsiz və dəyişməz olması demək deyil.

Token transfer cədvəli transaction-un hamısı deyil

Explorer token transfer tabı dekodlanmış log hadisələrindən cədvəl yaradır. Eyni transaction daxilində native value, daxili çağırışlar, bir neçə token transferi və DEX hadisələri ola bilər. Tək sətiri seçib bütün iqtisadi əməliyyat kimi təqdim etmək konteksti itirir.

Approval hadisəsi token transferi deyil; sahib spender üçün limit müəyyən edir. Limitin verilməsi bütün məbləğin dərhal köçürüldüyünü göstərmir. Sonrakı `transferFrom` ayrıca transaction və state dəyişməsidir. Permit imzası da yalnız düzgün icra və nonce vəziyyəti ilə on-chain nəticəyə çevrilir.

NFT, ERC-20 və native transfer eyni “value” sözü ilə qarışdırılmır. Token ID, amount, decimals və müqavilə standartı ayrıdır. Explorer UI ikonuna deyil, müqavilə və log mövzusuna əsaslanır.

Finality və reorg qeydini unutma

Transaction bloka daxil olanda explorer success göstərə bilər, lakin müxtəlif şəbəkələrdə finality anlayışı fərqlidir. Blok hündürlüyü, block hash və baxış vaxtı saxlanır. Daha sonra reorg baş verərsə köhnə receipt kanonik tarixçədə qalmaya bilər.

Solana-da commitment səviyyəsi processed, confirmed və finalized kimi fərqlənə bilər. RPC və explorer eyni anda müxtəlif səviyyə göstərə bilər. “Final” sözü yalnız istifadə olunan şəbəkənin və mənbənin dəqiq semantikasına görə yazılır.

Araşdırma screenshot-u finality sübutunun yerini tutmur. Dinamik səhifə cookie örtüyü, indeksləmə gecikməsi və ya sonrakı yenilənmə ilə natamam ola bilər. Xam identifikator və yenidən yoxlama addımı əsas qalır.

Explorer qeydi üçün təkrarlama paketi

Təkrarlama paketi şəbəkə adı, chain ID və ya cluster, tam transaction identifikatoru, blok/slot, baxış vaxtı və istifadə olunan explorer URL-indən başlayır. EVM üçün status, from, to, native value, input selector, internal calls və logs ayrı sahələrdir. Solana üçün fee payer, account keys, instructions, inner instructions, log və token balance dəyişiklikləri ayrı saxlanır.

Müqavilə və ya proqram kimliyi rəsmi mənbə ilə əlaqələndirilmədən layihə adı yazılmır. Explorer label-i axtarış ipucudur; tam ünvan və on-chain davranışın yerini tutmur. Naməlum caller və hesab naməlum qalır.

Son cümlə hər nəticənin qatını göstərir: birbaşa state, receipt/log müşahidəsi, rəsmi sənəddən çıxarılan məna və ya hələ təsdiqlənməyən izah. Bu paket screenshot-dan daha uzunömürlüdür, çünki başqa oxucu identifikatorlarla eyni zəncir obyektinə qayıda bilir.

Contract creation transaction-u izlə

Contract ünvanının başlanğıcı creation transaction və receipt ilə bağlanır. Deploy edən ünvan, nonce və ya CREATE2 salt, init code və yaranan runtime bytecode ayrı sahələrdir. Explorer creator etiketi cari owner demək deyil; sonrakı ownership və role hadisələri izlənir.

CREATE2 eyni deployer və salt kontekstində deterministik ünvan yarada bilər, amma başqa chain-də eyni görünən ünvan eyni state və layihə deyil. Chain ID və bytecode hash birlikdə saxlanır. Selfdestruct və yenidən deploy davranışı şəbəkə qaydası və fork versiyasına görə ayrıca araşdırılır.

Constructor parametrləri ilkin recipient, supply və admin barədə məlumat verə bilər. Doğrulanmış source yoxdursa decode ehtimal kimi qalır; ABI-ni başqa müqavilədən köçürüb fakt kimi göstərmək olmaz.

Method selector təkbaşına funksiya sübutu deyil

EVM input-un ilk dörd baytı selector-dur. Eyni selector nəzəri olaraq bir neçə signature ilə toqquşa bilər. Explorer decoded adı müqavilənin doğrulanmış ABI-sinə əsaslanırsa güclü siqnaldır; naməlum ABI bazasındakı ehtimal isə ayrıca işarələnir.

Proxy çağırışında selector implementasiya kodunda işlənir, state proxy-də dəyişir. Nested call-lar başqa müqavilələrə gedə bilər. Tək üst səviyyə funksiya adı bütün transaction davranışını izah etmir.

Calldata daxilində ünvan və məbləğ görünməsi həmin əməliyyatın uğurla icra edildiyini göstərmir. Receipt statusu, call trace və son state yoxlanır.

Event log state-in tam surəti deyil

Log müqavilə kodunun emit etdiyi hadisədir. Standart Transfer faydalıdır, lakin müqavilə hadisəni qeyri-standart qaydada emit edə və ya state dəyişib hadisə yazmaya bilər. Event mövzusu, emitting address və log index saxlanır.

Bir transaction-da eyni adlı event bir neçə müqavilədən gələ bilər. Token ünvanı yoxlanmadan bütün log-ları bir aktivə aid etmək olmaz. Proxy kontekstində emitting address-in proxy və ya başqa component olması da nəzərə alınır.

State iddiası üçün mümkün olduqda storage/read funksiyası və əvvəl-son snapshot istifadə olunur. Log səbəb və niyyət haqqında avtomatik hökm yaratmır.

Internal call normal transfer tabında gizlənə bilər

EVM müqaviləsi başqa müqaviləyə native value və calldata ilə daxili çağırış edə bilər. Normal transaction tabı yalnız xarici göndərən və ilk hədəfi göstərir. Trace görünüşü call, delegatecall, staticcall və create addımlarını ayırır.

Delegatecall zamanı kod başqa ünvandan, state isə çağıran müqavilədən gəlir. Value və msg.sender semantikası adi call-dan fərqlidir. Bu fərq proxy və router araşdırmasında xüsusilə vacibdir.

Trace provider node konfiqurasiyasından asılı ola bilər. Trace əlçatan deyilsə daxili davranış tam təsdiqlənmiş kimi yazılmır; receipt və log-la məhdud nəticə verilir.

Gas sahəsi transfer məbləği deyil

Gas limit, gas used, effective gas price və transaction fee fərqli sahələrdir. Fee native şəbəkə aktivində ödənilir, token transfer amount-u ilə eyni deyil. EIP-1559 bazasında base fee və priority fee ayrıca rol oynayır.

Uğursuz transaction da gas sərf edə bilər. Status failed olduqda token state dəyişiklikləri revert ola, amma fee ödənmiş qala bilər. “Pul getdi” cümləsi hansı aktiv və hansı sahənin nəzərdə tutulduğunu açmadan yazılmır.

L2 şəbəkələrdə L1 data fee və əlavə komponentlər ola bilər. Ethereum gas izahını bütün EVM şəbəkələrinə dəyişməz tətbiq etmək olmaz.

Token allowance cari limit snapshotıdır

Approval event spender üçün limit dəyişikliyini göstərə bilər. Cari allowance read funksiyası son state-i verir; keçmiş event-lərin sadə cəmi həmişə cari limiti bərpa etmir. Infinite allowance böyük tam ədəd kimi görünə bilər, amma bu, həmin məbləğin transfer edildiyi demək deyil.

Spender müqaviləsinin kimliyi ayrıca yoxlanır. Router adının UI-da görünməsi tam müqavilə ünvanını əvəz etmir. Proxy və upgrade imkanı varsa cari implementasiya qeyd olunur.

Allowance riski barədə nəticə token balansı, spender səlahiyyəti və istifadəçinin sonrakı revoke/transfer hadisələrindən ayrıdır. Explorer yalnız görünən state-i göstərir.

Solana account ownership mənasını dəqiqləşdir

Solana-da account owner həmin hesabın datasını idarə edən proqram ID-sidir; wallet sahibinin insan kimliyi deyil. Token account-un owner sahəsi ilə runtime account owner anlayışı fərqli kontekstdə görünə bilər. Explorer etiketinə baxarkən sahənin hansı schema-ya aid olduğu yoxlanır.

Program Derived Address private key daşımır, proqram qaydası ilə seed-lərdən yaranır. Bununla belə PDA-dakı aktivlərin necə hərəkət edə bildiyi program instruction-larından asılıdır. “Açarsız ünvan” ifadəsi avtomatik burn demək deyil.

Address Lookup Table transaction account siyahısını genişləndirə bilər. Yalnız əsas mesajda görünən qısa siyahı bütün toxunulan hesablar deyil. Explorer-in resolved görünüşü və xam message birlikdə oxunur.

Solana instruction və inner instruction ayrıdır

Üst səviyyə instruction proqramı çağırır, həmin proqram CPI vasitəsilə başqa proqramlara inner instruction göndərə bilər. Token transferi çox vaxt router və ya DEX instruction-un içində görünür. Yalnız üst səviyyə proqram adını oxumaq faktiki token hərəkətini gizlədə bilər.

Pre/post token balances mint, owner və ui amount sahələri ilə müqayisə olunur. Decimals xam amount-un görünüşünə tətbiq edilir. Balans fərqi transaction niyyətini tam sübut etmir; fee, account creation və close kimi addımlar da kontekstdədir.

Log mesajı proqramın yazdığı mətndir. Success statusu runtime nəticəsidir; log daxilində “success” sözü ayrıca finality zəmanəti deyil.

Memo və calldata insan niyyətinin etibarlı sübutu deyil

İstifadəçi memo sahəsinə istənilən mətn yaza bilər. Orada layihə adı, order nömrəsi və ya iddia görünməsi həmin tərəfin real kimliyini təsdiqləmir. Memo yalnız transaction daxilində müşahidə olunan mətndir.

Calldata-da URL və simvol da müqavilə əlaqəsi yaratmır. Rəsmi mənbə və on-chain ünvan mapping-i ayrıca olmalıdır. Zərərli transaction məşhur layihə adını daxil edə bilər.

Şəxsi məlumat görünürsə araşdırma lazımsız şəkildə onu təkrar yayımlamır. Sübut üçün transaction identifikatoru və texniki sahə kifayət edirsə memo-nun şəxsi hissəsi sitat gətirilmir.

Explorer API və UI eyni anda yenilənməyə bilər

UI indekslənmiş məlumatı, API başqa cache qatını və RPC birbaşa node state-ni göstərə bilər. Eyni provider brendi altında olmaq eyni snapshot demək deyil. Hər cavabın vaxtı, endpoint-i və blok sərhədi saxlanır.

API rate limit və ya pagination səbəbilə natamam siyahı qaytara bilər. “İlk səhifədə yoxdur” hadisənin mövcud olmadığını sübut etmir. Cursor, page və sort istiqaməti qeyd olunur.

UI dinamik yüklənmirsə browser screenshot ilə boşluq saxta şəkildə doldurulmur. Xam API və ya RPC əlçatan deyilsə məhdudiyyət owner blocker kimi yazılır.

Multi-call transaction-da iqtisadi yol

Router transaction-u approve, wrap, swap, fee və unwrap addımlarını birləşdirə bilər. İqtisadi yolu çıxarmaq üçün bütün çağırış və token dəyişiklikləri zaman sırası ilə yazılır. Bir transfer sətiri yekun alınan məbləğ olmaya bilər.

Refund və change transferi istifadəçiyə geri dönə bilər. Gross giriş ilə net çıxış fərqlidir. İş vərəqi sadə toplama ilə “xərclənən məbləğ” yaratmır; token və native balans dəyişikliklərini fee-lərlə ayrır.

MEV bundle və private relay məlumatı explorer-də tam görünməyə bilər. Görünməyən off-chain order niyyəti uydurulmur; yalnız kanonik transaction və açıq mənbə qeyd olunur.

Explorer sübutunun yenidən yoxlanması

Yenidən yoxlama eyni tam identifikatoru ən azı etibarlı explorer və mümkün olduqda node/RPC-də açır. Chain, block hash, status və əsas log-lar uzlaşmalıdır. Fərq varsa indeksləmə və finality araşdırılır.

Screenshot istifadə olunubsa cookie və reklam örtüyünün əsas sahəni bağlamadığı, tam ünvan və transaction-un göründüyü yoxlanır. Dinamik balans screenshot-u cari state üçün uzunmüddətli sübut deyil.

Nəticə qeydi baxış tarixini yeniləyir, amma mənbə əlçatan olmayanda köhnə faktı cari kimi təsdiqləmir. Naməlum sahələr naməlum qalır.

Yekun qeyd müşahidə ilə şərhi ayırır

Təkrar yoxlanılan transaction qeydi şəbəkə, identifikator, block/slot, vaxt, status, fee, envelope from/to, native value, input/instructions, daxili çağırışlar, token hadisələri və ya account dəyişiklikləri, istifadə edilən explorer/RPC və məhdudiyyətdən ibarətdir.

Hər nəticə “birbaşa müşahidə”, “sənədlə çıxarılan məna”, “explorer etiketi” və “hələ sübut edilməyən iddia” kimi işarələnir. “Success” birinci qatda qala bilər; “şəxs tokeni satın aldı” isə kimlik və iqtisadi səbəb sübutu olmadan sonuncu qatda qalır.

Explorerin gücü ictimai vəziyyəti təkrar yoxlamağa imkan verməsidir. Onu etibarlı edən rəngli səhifə deyil, düzgün şəbəkə, tam identifikator, xam sahələr, müşahidə vaxtı və iddianın həmin sahələrin həqiqətən dəstəklədiyi sərhəddə saxlanmasıdır.