B A S I L KHAN

#dusk $DUSK @Dusk Bu gün NPEX/Dusk elanlarının tarixinə ən yeni hype postunu əvvəl oxumaq əvəzinə, ardıcıllıqla geri qayıdıb baxdım və onu xronoloji düzəndə görəndə faktiki zaman xətti fərqli görünür.
2025-ci ilin dekabrı: Dusk və NPEX Avropanın ilk blokçeyn güclü qiymətli kağızlar birjası kimi təsvir edilən layihəni başlatmaq üçün tərəfdaş olur; NPEX lisenziyalı Hollandiya MTF-i kimi fəaliyyət göstərir. 2025-ci ilin fevralı: Cordial Systems qəyyumluq (custody) qatını əlavə edir. 2025-ci ilin noyabrı: Dusk və NPEX xüsusi olaraq NPEX-in rəsmi birja məlumatlarının on-çeynə yerləşdirilə bilməsi üçün Chainlink-in CCIP və DataLink standartlarını qəbul edir. Dusk Trade dApp-ın özü isə DuskEVM üzərində işlədiyi kimi təsvir olunur: NPEX, 21X və digər institusional oyunçulardan tokenləşdirilmiş aktivlərlə başlanır; daha əvvəlki xəbərlərdə €300M kimi rəqəmlər aktivlər kimi istinad edilir.
Bu, həqiqətən ciddi tənzimləyici “stack”dir — MTF, Broker, ECSP lisenziyaları, həmçinin DLT-TSS lisenziyasının gələcəkdə olacağı təsvir olunur. Bu sadəcə “kağız üzərində” tərəfdaşlıq deyil; NPEX artıq Hollandiyada qiymətli kağızlar üzrə real, lisenziyalı ikincil bazar işlədir.
Amma son bir neçə ayda tarixlənmiş tapa bildiyim bütün mənbələrə baxsam da, Dusk Trade-də bu gün həqiqətən canlı və ticarət edilə bilən aktivlərin sayı barədə təsdiqlənmiş tək bir rəqəm tapa bilmədim — eləcə də elanlarda yalnız tərəf kimi adı çəkilən aktivlərin sayı ilə müqayisədə. Mənim gördüyüm bütün istinadlar imkanlar, lisenziyalar və inteqrasiya işləri barədə idi — hazırkı siyahı (listing) sayı barədə yox. “€300M aktiv” ifadəsini artıq tokenləşdirilib ticarət edilir kimi götürmək nəticəni “nailiyyət” kimi oxumaq olardı və bunun üçün hələ sübutum yoxdur.
İrəlidə yoxlayacağım məhz budur: Dusk Trade birjalarda olduğu kimi ictimai, sorğulanabilən listing sayını dərc edirmi; NPEX-in özünün investor yönümlü saytında tərəfdaşlığın özündən çox, canlı Dusk əsaslı ticarətə istinad olunurmu; və Chainlink DataLink feed-i hazırda canlı NPEX bazar məlumatını on-çeynə itələyirmi, yoxsa hələ inteqrasiya testindədir.

#dusk $DUSK @Dusk Bu gün DuskEVM testnet explorer-dən canlı nömrələri birbaşa çıxarmağa çalışdım; elan mesajlarına güvənmək əvəzinə, amma nəyi axtardığımı əslində dəyişən bir vəziyyətlə rastlaşdım.
Testnet explorer Blockscout üzərində işləyir və adətən veriləri sorğulanabilir API vasitəsilə təqdim edir — amma səhifə özü client-side (brauzer tərəfi) render edir, ona görə də birbaşa fetch etməklə mövcud transaksya/kontrakt saylarını çıxara bilmədim. Bu, bu cür məlumatı brauzerdən kənardan yoxlamağın real məhdudiyyətidir və həqiqətən yoxlamadığım bir rəqəmi demək istəmirəm.
Amma tapdıqlarım, sadəcə xam saydan daha maraqlı idi. DuskEVM-in ictimai testnet-i 5 dekabr 2025-ci ildə işə düşdü; o zaman “mainnet işə salınmasına qədər son addım” kimi təsvir edilirdi. DuskEVM Mainnet üçün ayrı bir Blockscout instansı artıq mövcuddur və bu günə kimi məlumatları indeksləşdirir. Bu zaman xətti səkkiz ay əvvəl verilmiş “mainnet-ə qədər son addım” çərçivəsindən daha sıxdır — üstəlik 10 avqust 2026-dakı Dusk-etiketli bir paylaşım hələ də Solidity/Hardhat testləri üçün testnet-i təbliğ edirdi; bu da geliştiricilərin hazırda dəqiq hansı mühitə yönləndirildiyi barədə real sual yaradır.
Həmçinin DuskEVM-in arxitekturasında işarələməyə dəyər struktur bir özəllik diqqətimi çəkdi: o, hazırda yalnız sequencer rejimində işləyir və açıq mempool yoxdur. Bu, bu mərhələdə OP Stack rollup-lar üçün normaldır, amma bu o deməkdir ki, burada “fəallıq” L1 kimi eyni şəkildə ölçülmür — aşağı testnet transaksya sayı mütləq aşağı developer marağı demək deyil, çünki sequencer-only zəncirlər Ethereumun mempool-u kimi gözləyən aktivliyi göstərmir.
Yoxlaya bilməyəcəyim bir rəqəm təxmin etmək əvəzinə, indi izlədiyim şeylər bunlardır: Dusk-un öz kanallarında geliştiricilərə testnet əvəzinə mainnet explorer-ə istiqamət verilməyə başlanıb-başlanmadığı, testnet-in açıq şəkildə köhnəlmiş (deprecatd) elan edilib-edilmədiyi və ya paralel olaraq işləməyə davam edib-etmədiyi, həmçinin mainnet Blockscout instansındakı “verified-contract” saylarının real deploy-lardan yüksəlməyə başlayıb-başlamadığı — yoxsa yalnız test skriptlərindən qaynaqlanıb-qaynalmadığı.

#dusk $DUSK @Dusk Bu gün Citadel-in arxasındakı real GitHub repolarına baxdım; sadəcə elan səhifəsini oxumaqla kifayətlənmədim və iki şey arasındakı fərq gözlədiyimdən daha böyük çıxdı.
Citadel yanvar 2023-də tam bir tədqiqat məqaləsi, işlək protokol dizaynı, üç müəyyən tərəf (istifadəçi, lisenziya provayderi, xidmət provayderi) və məhz real bir problemi həll etmək üçün qurulmuş private NFT modeli ilə rəsmi şəkildə təqdim edilmişdi—digər SSI sistemlərində olan bir çatışmazlığı: sıfır-bilik sübutları (zero-knowledge proofs) etimadnamənin məzmununu gizlətsə belə, həmin etimadnamə adətən ictimai və izlənə bilən on-çeyn dəyər kimi saxlanılır. Citadel-in əsas töhfəsi həmin sızmanı düzəltmək idi.
Alətlər də mövcuddur — Moat, Citadel SDK-si GitHub-da canlıdır; protokola əsaslanmaq üçün CLI və uzaqdan giriş API-si var, bunun üçün işlək bir Rusk nodu və qoşulmuş wallet tələb olunur. Bu, sadəcə “vaporware” deyil; kod realdır və açıqdır.
Amma cari sənədləşdirmə mərkəzini yoxlayanda məni dayandıran bir qeyd gördüm: “SDK mövcuddur, amma cari Rusk modeli üçün yenilənməlidir.” Bu, “protokol dizayn edildi və dərc olundu” ilə “protokol şəbəkənin indiki tətbiqinə qarşı aktiv şəkildə saxlanılır” arasında ciddi bir boşluqdur. Texniki olaraq sağlam olan üç illik kripto dizaynı yalnız inteqrasiya qatının, o vaxtdan bəri zəncirin keçdiyi çoxqatlı arxitektura dəyişikliklərinə nə qədər ayaq tutduğunu göstərmir.
Məncə bu, Citadel-in tərk edildiyi demək deyil — tədqiqat səviyyəli məxfilik alətləri çox vaxt inteqrasiya işləri partlayışları arasında yuxuda qalır; xüsusən də komandanın diqqəti DuskDS/DuskEVM/DuskVM üzərində olanda. Amma bu, Citadel-i hazırda “canlı uyğunluq (live compliance) infrastrukturu” kimi dəlil kimi göstərməyi düzgün olmayan dərəcədə şişirdir.
Gələcəkdə izlədiyim məsələlər: Moat-ın current Rusk modelinə uyğun commit ilə yenilənib-yenilənməyəcəyi; hər hansı adla göstərilən institutun və ya KYC provayderinin Citadel-i sadəcə istifadə halı (use case) kimi istinad etmədən, həqiqətən istehsalat mühitində deploy edib-etməyəcəyi; və Citadel-in DuskEVM/DuskVM roadmap-ə açıq şəkildə daxil olub-olmayacağı, yoxsa 2023-cü ilin ayrıca bir artefaktı olaraq qalacağı.

#dusk $DUSK @Dusk Əgər kimsə “Dusk” üzərində ödənişin “təsdiqləndiyini” deyirsə, həmin sözə əsasən siz əmtəəni həqiqətən buraxardınız, müqavilə bağlayardınız və ya köçürmə (wire) göndərərdiniz?
“confirmed” (“təsdiqləndi”) və “done” (“başa çatdı”) ifadələrini bir-biri ilə eyni kimi qəbul etdiyimi anlayandan sonra yekunluq (finality) vəziyyətlərini yenidən nəzərdən keçirdim; bu zəncirdə onlar əslində eyni deyil.
Blok dörd ayrı mərhələdən keçir: Accepted, Confirmed, Stable və Final. Yalnız Final deterministikdir və kriptoqrafik olaraq həqiqətən geri dönməzdir. Stable isə onun bir addım əvvəlki vəziyyətidir və açıq şəkildə ehtimallıdır (probabilistic), mütləq deyil. Bu o deməkdir ki, blok elə dərin basdırılıb ki, geri dönüş son dərəcə mümkünsüzdür, amma geri dönüşün riyazi olaraq tamamilə qeyri-mümkün olması demək deyil.
Bu fərq real pul məsələsində çox daha böyük önəm daşıyır. Əgər siz Stable, amma hələ Final olmayan bir əməliyyatı “yerləşmə/settlement” kimi qəbul edib aktiv buraxırsınızsa, ticarəti təsdiqləyirsinizsə, vəsaitləri “cleared” (təmin olunmuş) sayırsınızsa, siz zəmanə yox, bir ehtimalı qəbul edirsiniz; fərq isə sadəcə cüzdan və ya explorer-də status etiketini oxuyaraq dərhal aydın görünmür. Final statusuna həqiqətən çatmaq üçün lazım olan blok sayının sabit qaydası da yoxdur; Dusk “rolling finality” (dinamik yekunluq) modelinə keçib, yəni şəbəkə şəraitinə görə hər dövrdə say dəyişir. Bu da o deməkdir ki, “X blok gözləyin və yetərlidir” kimi tək bir qaydaya kor-koranə etibar edə bilməzsiniz.
@Dusk _Foundation Stable ilə Final arasındakı boşluğun real şəbəkə şəraitində nə qədər uzana biləcəyinə dair dərc olunmuş aydın bir “ən pis halda” (worst-case) rəqəm tapmamışam; yalnız bunun dizayna görə dəyişkən olduğunu bilmişəm.
Əgər siz Dusk-dan real yerləşmə ilə bağlı hər hansı işdə istifadə edirsinizsə, vəsaitləri təhlükəsiz saymazdan əvvəl həqiqətən Final-ı yoxlayırsınız, yoxsa Stable-a dayanırsınız, çünki “bitmiş kimi səslənir”?

#dusk $DUSK @Dusk Əgər DUSK-u DuskEVM körpüsü üzərindən göndərsəniz, qarşı tərəfdə vəsaitlərinizin təhlükəsiz olduğunu nə vaxt və necə bildiyinizi əslində haradan bilirsiniz — və səhv etsəniz nə baş verir?
Praktikada bunu demək olar ki, özüm də səhv bir fərziyyə edəcəkdim deyə araşdırdım. Mənim instinktim belə idi: blok tədqiqatçısında (block explorer) daxil edilmə (inclusion) təsdiqlənibsə, deməli vəsait istifadəyə yararlıdır. Məlum oldu ki, bunu düşünmək dəqiq yanlış yanaşmadır.
Dusk-ın öz tərtibatçı sənədləri bununla bağlı açıq danışır: daxil edilmə (inclusion) və ödəniş/settlement (tam hesablaşma) iki ayrı mərhələdir və DuskEVM ilə DuskDS təbəqəsi arasında dəyər hərəkət etdirən tətbiqlərə protokolun və ya wallet-in statusunu birbaşa yoxlamaq tapşırılır — sadəcə müəyyən vaxt keçib deyə yekunluğu (finality) güman etmək yox.
DuskEVM-də tranzaksiya daxil edilməsi sequencer əsaslı L2 olduğuna görə tez baş verir, amma bu, vəsaitlərinizin faktiki olaraq baza təbəqəsinə qarşı artıq təhlükəsiz şəkildə hesablaşdığı həmin an deyil.
Praktik olaraq bunun mənası budur: əgər siz aktivləri körpüləyirsinizsə və “yəqin ki, indi artıq iş bitib” deyərək göndərir və ya xərcləyirsinizsə, protokolun özü tərəfindən açıq şəkildə xəbərdarlıq edilən bir təxminə söykənirsiniz. “Daxil edildiyi görünür” ilə “əslində hesablaşıb” arasındakı boşluq, vaxtından əvvəl hərəkət etməyin real risk yaratdığı elə pəncərədir — hələ də yenidən təşkil (reorg) oluna və ya həqiqətən yekunlaşmadan əvvəl etibarsız sayılma potensialı olan vəsaitlərlə hərəkət etmək.
@Dusk _Foundation — normal şəbəkə şəraitində DuskEVM daxil edilməsindən DuskDS ödəniş/yekun hesablaşma finality-sinə qədər tipik gözləmə vaxtı üçün rəsmi dərc olunmuş bir rəqəm tapa bilmədim; yalnız vaxtı saymaq yox, statusu yoxlamaq barədə istiqamət var.
Protokol özü elapsed time (keçən vaxt) ilə təxmin etməyin olmaz deyirsə, onda əksər wallet-lər və körpü UI-ləri istifadəçilərə real settlement statusunu həqiqətən göstərirmi, yoxsa insanlar hələ də sadəcə taymerə baxıb təxmin edir?

#dusk $DUSK @Dusk Hər iki təbəqədə yan-yana aktiv buraxılışı axınlarını test edərkən gördüm ki, iki protokol təkcə müxtəlif zəncirlərə köçürülmüş eyni alət deyil — onların alt qatda həqiqətən fərqli kriptoqrafiya ilə məxfilik problemi həll etməsi var.
Zedger DuskDS-də natv şəkildə işləyir və UTXO əsaslıdır; bu da struktur olaraq hesab əsaslı sistemdə təkrarlanması çətin olan bir şəkildə tam anonimlik təklif etməyə imkan verir. Hedger isə DuskEVM-də işləyir; standart Ethereum alətləri ilə tam uyğunluq üçün qurulub — amma EVM-in hesab əsaslı modeli Zedger-in verdiyi eyni səviyyəli anonimliyi dəstəkləyə bilmədiyi üçün Hedger tamamilə fərqli texniki yola gedir. O, elliptik əyrilər üzərində ElGamal olan homomorf şifrələməni sıfır-bilikli sübutlarla birləşdirir; beləliklə balanslar və köçürmələr sonuna qədər şifrəli qalır, eyni zamanda hesablanıb audilə edilə bilir — sadəcə gizlədilmək yox, həm də yoxlanılmaq mümkündür.
Gözləmədiyim hissə budur: Hedger-in sübutları müştəri tərəfdə, brauzerdə, iki saniyədən az müddətdə yaradılır. Bu, marketinq iddiası deyil — real istifadə rahatlığı arqumentidir: EVM tərəfdə şəxsi şəkildə əməliyyat aparmaq üçün institusional istifadəçilərin xüsusi sübut infrastrukturu hazırlamasına ehtiyac qalmır.
Beləliklə, Zedger ilə Hedger arasındakı faktiki seçim "daha məxfi olan hansıdır" deyil. Seçim, buraxan tərəfin hansı etibar və alətləmə modelinə ehtiyac duymasıdır. Zedger UTXO səviyyəsində anonimlik verir, amma natv Dusk alətləri tələb edir. Hedger tam Ethereum uyğunluğu və sürətli brauzer-də sübutlamanı verir, lakin qurulduğu hesab modeli səbəbilə həmin anonimlik tavanını verərək qarşılığında kompromisə gedir.
Hələ də buraxanın reallıqda necə qərar verməli olduğu barədə aydın cavab görməmişəm: eyni aktivdə həm EVM-kompozisiyasını, həm də Zedger səviyyəsində anonimliyi birlikdə lazım olanda — bunun bu gün mümkün olub-olmaması və ya heç kimin tam həll etmədiyi bir kompromisə məcbur olub-olmamaq.

#dusk $DUSK @Dusk
Yerli mühitdə sübut (proof) generasiyasını dövr etmək üçün (circuit performance) benchmark etmək məqsədilə çalışdırarkən diqqətimi çəkən bir şey oldu və məni marketinq səhifələrinin əvəzinə kriptoqrafiya komandasının öz yazılarını yenidən oxumağa qaytardı.
PLONK-un real rəqəmləri uyğunluq (compliance) arqumentinin işə yaramasını təmin edir — təkcə məxfilik tərəfi yox. Verifikasiya vaxtı dövrənin ölçüsündən asılı olmayaraq təxminən 6–9 millisekund səviyyəsində qalır; sübut etmə vaxtı isə dövrənin mürəkkəbliyi ilə artır (məhdud resurslu avadanlıqda 2^16-gate-lik dövrə üçün təxminən 5.46 saniyə). Amma verifikatorun tərəfi sürətli və sabit qalır. Bu asimmetriya tənzimlənən maliyyə üçün insanların düşündüyündən daha önəmlidir: auditor və ya tərəfdaş sübutu yoxlayarkən hər dəfə mənalı hesablamanı xərcləmir — hətta əsas əməliyyat məntiqi getdikcə mürəkkəbləşsə belə.
Gözləmədiyim isə PLONK-un özündə, sadəcə nəzəri risk deyil, real açıqlanmış bir zəifliyin olması idi. Dusk tədqiqat komandası Fiat–Shamir transformasiyasının necə tətbiq edildiyində kritik problem tapdı — bu, interaktiv sübutu qeyri-interaktivə çevirən hissədir: canlı verifikatorun çətinlikləri göndərməsi əvəzinə, çətinliklər (challenges) verilənlərin hash-lənməsi ilə alınır. İlkin implementasiya açıq (public) girişləri kifayət qədər erkən hash etmirdi; bu da soundness (səsliyə zəmanət) təminatını zəiflətdi. Trail of Bits açıqlamanın koordinasiyasını etdi, Dusk isə mainnet-dən öncə bunu yamaqladı və onun üzərində oturmaq əvəzinə düzəlişi ictimai şəkildə paylaşdı.
Mənim yadda qalan bu detaldır — uyğunluğa yönəlmiş bir zəncirin kriptoqrafik sübut sisteminə əsaslanması, həmin sistemdə isə prodakşona yaxın kodda real bir soundness xətasının olması; üstəlik bu, problem “əhəmiyyətli olandan” əvvəl aşkarlanıb düzəldilib. PLONK-dan başqa haradasa istifadə edən neçə implementasiyanın bu ictimaiyyətə çıxandan sonra hələ də zəif olub-olmadığını və açıqlama ilə digər layihələrin öz fork-larını yamaqlaması arasındakı zaman boşluğunun nə qədər olduğunu bilmirəm.

#dusk $DUSK Blokçeyn həqiqətən məxfi ola bilər və buna baxmayaraq tənzimləyicilər qanuni olaraq görməli olduqlarını görə bilər?
Cavabın açarın başqa bir açarla şifrələnməsindən asılı olacağını gözləmirdim. Əksər məxfilik sikkələri məxfiliyi görünürlüğü tamamilə aradan qaldırmaqla həll edir — heç kim heç vaxt heç nəyə baxmır. @Dusk isə fərqli bir fərziyyə ilə işləyir: məxfilik tam (mütləq) deyil, seçmə olmalıdır.
İstifadəçinin tranzaksiya yükü istifadəçi açarı ilə şifrələnir və həmin açar ayrıca auditor açarı ilə yenidən şifrələnir; yəni yalnız səlahiyyətli auditor onu aça bilər. Zəncir ictimaiyyət üçün “shielded” qalır, amma sıfır bilik (zero-knowledge) sübutları istifadəçilərə auditor açarının düzgün istifadə olunduğunu sübut etməyə imkan verir və yük qaydalara uyğun olduğunu məzmunu başqa heç kimə açmadan nümayiş etdirir. Bu, anonimlikdən struktur olaraq fərqlidir: müəyyən şərtlər daxilində kimsə görə bilər, hətta ictimai zəncir heç nə göstərməsə də.
Bu, kimliyə də təsir edir. Dusk-un şəxsiyyət qatında (Citadel) kiminsə KYC-ni bir dəfə tamamlamasına və sonra uyğunluğu sıfır bilik sübutları ilə isbat etməsinə imkan verilir; hər dəfə şəxsi məlumatları yenidən açmadan. Bu, həm də daha əvvəlki məxfilik ID sistemlərindəki boşluğu düzəldir: hətta sızma-davamlı (leak-proof) sübutlar olsa belə, onlar yenə də ictimai, izlənə bilən on-çeyn dəyərləri ilə bağlı olurdu.
Mənim cavabsız qalan tərəfim budur: seçmə açıqlama yalnız auditor açarı heç vaxt sındırılmırsa və ya sui-istifadə olunmursa səni qoruyur. Məxfilik sikkəsinin belə bir açarı kompromisə uğratmaq mümkün olmadığı kimi bir təminatı yoxdur — onun zəmanəti “heç kim heç nə görmür” mütləqdir. Dusk bu mütləq zəmanəti tənzimləyici baxımdan yararlılığa görə dəyişir; məqsəd də müəssisələr üçün budur, amma onun məxfiliyi yalnız riyaziyyatla deyil, auditor girişinə nə qədər sərt nəzarət edildiyindən də qismən asılı qalır.
Əgər Dusk-da məxfilik qismən auditor açarlarını kiminsə əlində saxlamasından asılıdırsa, onda “komplayansə (uyğunluğa) əsaslanan məxfilik”də kriptografiya nə qədərdir və nə qədər hissəsi sıfır bilik sübutunun üstündə geyinilmiş institusional etibardır?

#dusk $DUSK @Dusk Öz tokenlərinizi heç bir hack olmadan zəncirlər arasında köçürmək həqiqətən sizə pul xərclədirmi?

Bunu yazmazdan əvvəl bir axşam Dusk-un migrasiya müqaviləsinin koduna baxdım, çünki “native vs. wrapped” adətən sadəcə kosmetik fərq kimi izah olunur. Deyil.
Diqqətimi çəkən detal budur: native DUSK 9 onluqdan istifadə edir, amma ERC20/BEP20 DUSK 18. Migrasiya müqaviləsi sabit əmsala əsasən çevirir və köçürdüyünüz məbləğ 1 LUX-ın təmiz (kəsirsiz) qatında deyilsə, müqavilə səssizcə aşağı yuvarlaqlaşdırır. Həmin həddən aşağı toz (dust) ilə bir məbləğ köçürsəniz, artıq hissə native DUSK kimi sizə geri qayıtmır. Sadəcə olaraq, dizayn olaraq “itmişdir”, bug kimi yox.
Etibar modeli haqqında da ayrıca deməyə dəyər. Əsas şəbəkədəki native DUSK, siz BEP20-ə native DUSK körpülədikdə həqiqi həqiqət mənbəyidir: protokol əvvəl əsas şəbəkədəki tokenlərinizi kilidləyir, sonra BSC-də mint (bölüşdürmə) işə düşür. Wrapped BEP20 tokeni yalnız bu kilid sayəsində mövcuddur; müstəqil şəkildə dəstəklənmir. Hər ikisi cüzdanınızda eyni sald (balance) kimi görünsə də, bu, native DUSK-u birbaşa saxlamaqla müqayisədə fundamental olaraq fərqli risk profilidir.
Sonra isə tamamilə dizayn seçimindən kənar bir hissə var — əməliyyat riski. Native DUSK-u BEP20-yə körpüləmək üçün təyinat BSC ünvanını memo sahəsinə daxil etmək lazımdır. Buraxsanız və ya səhv yazsanız, sənədlər qəti şəkildə deyir ki, körpü əməliyyatı nəzərə almır və vəsait itir. Heç bir smart kontrakt revert (geri qaytarma) etmir, avtomatik refund yoxdur. Sadəcə itir, çünki o biri tərəfdəki mint-in gedəcəyi yer heç vaxt olmur.
Məncə, çoxsaylı holder-lər tokenləri birja və cüzdanlar arasında köçürməzdən əvvəl hansı versiyanı həqiqətən saxladıqlarını yoxlamır — onlar sadəcə “DUSK” görür və bunun dəyişdirilə bilən olduğunu düşünürlər.

Əgər native DUSK həqiqi həqiqət mənbəyidirsə və wrapped versiyalar yalnız kilid və mint sübutuna görə mövcuddursa, niyə ekosistem yenə də bunu bu qədər asan edir ki, tək bir memo sahəsi unudulanda vəsait itirmək mümkün olsun?

#dusk $DUSK @Dusk
"Trustless" (etibarsızlıqsız) ifadəsi körpü iki müxtəlif icra qatları arasında aktivlərinizi hərəkət etdirdiyi halda əslində nə deməkdir?
Duskun DuskDS-ni DuskEVM-ə necə bağladığını oxuduqdan sonra bu suala dönə-dönə qayıtdım, çünki "trustless bridge" demək olar ki, hər yerdə marketinq ifadəsi kimi işlədilir və yaxın mütaliə zamanı nadir hallarda olduğu kimi qalır.
Baş verən budur: DuskDS yekunlaşma və konsensus qatıdır — burada sonluq (finality), təhlükəsizlik və məlumatların mövcudluğu yaşayır. DuskEVM isə Solidity kontraktları üçün ayrıca icra mühiti kimi onun üzərində işləyir. Aktivləri onların arasında daşımaq, tək bir zəncirin öz vəziyyətində (state) daşımaqla eyni deyil — deməkdir ki, bir qat digərinə dövlət dəyişməsinin həqiqətən baş verdiyini sübut etməlidir; iki tərəfdən heç biri digərinin sözünü sadəcə qəbul etmir.
Burada əslində önəmli olan "native" hissəsidir. Çox yayılmış klassik körpü dizaynında olduğu kimi kənar validator dəstəsinə və ya sığortalı aktivi (wrapped assets) saxlayan multisig qəyyumuna güvənmək əvəzinə — bu sənayedəki cross-chain (zəncirlərarası) istismarların çoxuna səbəb olan yanaşma — körpü birbaşa protokolun öz yekunlaşma (settlement) zəmanətlərinə inteqrasiya olunub. DuskDS-in sonluğu ("Final" vəziyyəti, kriptoqrafik olaraq zəmanətlənən və geri dönməz) körpünün digər tərəfdə transferin tanınmasının həqiqətən təhlükəsiz olduğunu təsdiqləmək üçün söykəndiyi məhz budur.
Bu, ayrıca imzalayanlar dəsti ilə təmin edilən körpüdən xeyli fərqli bir etibar modeli deməkdir. Amma bu həm də o deməkdir ki, körpünün təhlükəsizliyi yalnız DuskDS-in öz konsensus fərziyyələri qədər güclüdür — əgər komitə əsaslı sonluğun (finality) mübahisəyə açıldığı və ya gecikdiyi hər hansı bir ssenari olsa, körpü həmin eyni qeyri-müəyyənliyi miras alar; ayrıca, ayrı bir risk deyil.
Hələ aydın cavab tapmamışam: DuskDS-in "Final"-a çatması ilə aktivin DuskEVM-də istifadəyə çevrilməsi arasında real gecikmə (latency) nə qədərdir və bu boşluq kriptoqrafiyanı sındırmaqdan başqa, yalnız vaxtlama (timing) ilə istismar etmək üçün hər hansı pəncərə yarada bilərmi?
Körpü yalnız altındakı yekunlaşma qatının qədər "trustless" ola bilər, yoxsa DuskEVM üstə əlavə, özünün müstəqil riskini də gətirir?

#baby @BabylonLabs_io Bir validator zərərli olarsa, ona delegasiya edən hər kəs birlikdə cəzalandırılır, yoxsa yalnız onların hədəf aldığı konkret insanlar?
Cavabın sadəcə "bəli, hamı öz payını itirir" kimi bir şeydən çox, şifrələmə hiylələrini əhatə edəcəyini gözləmirdim. Naiv şəkildə düşündüm ki, slashing əksər PoS zəncirlərində olduğu kimi işləyir: bir pis validator, ona delegasiya etmiş hər kəs üçün kollektiv cəza.
Babylon isə adaptor signature-lardan istifadə edərək bunu fərqli edir. Staker delegasiya edəndə həm staker, həm də covenant komitəsi bu razılaşmanı əvvəlcədən təsdiqləyir, amma sonradan slashing-i həqiqətən işə salmaq üçün lazım olan tək şey delegasiya olunmuş validatorun öz imzasıdır. Quldur validatorun bir stakerin vəsaitlərini özbaşına zərərli şəkildə slashing etməsinin qarşısını almaq üçün, staker öz əvvəlcədən təsdiqini həmin validatorun öz EOTS public key-si ilə şifrələyir. Bu o deməkdir ki, validator heç vaxt həmin konkret stakeri zərərli şəkildə hədəf almağa çalışarsa, imzanı şifrədən açmaq üçün validatorun öz şəxsi açarı sızmalıdır — bu da həmin validatorun tamamilə öz-özünə delegasiya etdiyi payını və onu delegasiya edən bütün digərlərin paylarını da onunla bağlı şəkildə slashing edilə bilən edir.
Başqa sözlə, bir nəfəyə hücum etmək validatorun öz ifşasını onlara bağlı hər kəsin üzərinə çəkir. Bu, siyasətlə izolyasiya deyil; izolyasiya elə hücumun hücumçunu özünə zərər verəcək şəkildə dağıdıcı hala gətirməklə təmin olunur.
Yəni, kompomiss (təhlükəyə düşmə) sonrası validatorin heç nə itirməməsi və bir dəfə güzəştə gedib bütün delegatorlar üzərində maksimum ziyan vurmağa çalışacağı kimi bir perverse (qeyri-sağlam) stimul yaradırmı — yoxsa yalnız birini hədəfləmək barədə düşünməyə məcbur edir? Bunu tam razı salan bir cavab tapa bilməmişəm.
Əgər bir nəfərin slashing-i hər halda həmin validatorun altındakı hamıya kaskad edə bilirsə, "izolyasiya olunmuş slashing" çərçivəsi praktikada nə qədər doğrudan da özünü doğruldur?
#baby $BABY

#baby $BABY Bəs Bitcoin-də heç bir daxili slashing məntiqi yoxkən validatoru necə "slash" edirsiniz?
Bunu həqiqətən başa düşmək gözlədiyimdən daha uzun çəkdi, çünki cavab smart kontrakt deyil — kodla deyil, riyaziyyatla hiylə edən imza sxemidir.
@BabylonLabs_io adlanan şeydən istifadə edir: Extractable One-Time Signature (EOTS), Bitcoin-in yerli Schnorr imzaları üzərində qurulmuşdur. Əsas fənd budur: finalitet provayderi səs verdiyi hər blok hündürlüyü üçün unikal açar cütü yaradır. Onlar hər hündürlük üçün yalnız bir dəfə imza atarsa, imza tamamilə təhlükəsiz qalır və heç nə sızmır. Amma eyni hündürlükdə iki zidd blok üçün imza atarlarsa, riyaziyyat dağılar. Hündürlük üzrə bu tək açarı iki müxtəlif mesaja imzalamaq üçün təkrar istifadə etmək, Schnorr imza riyaziyyatı nonce (sayğac) yenidən istifadə olunanda necə işlədiyinə görə onların özəl açarını birbaşa ifşa edir.
Finalitet raundunun özü, bir blokun həqiqətən yekunlaşması üçün qoyulmuş (staked) BTC çəkisinin üçdə ikisindən çoxundan imza tələb edir; yəni hər hansı təhlükəsizlik pozuntusu tərifinə görə ikiqat imza atan stake-in üçdə birindən çox olmasını tələb edir. Bu da "tam slashable" zəmanətin riyazi olaraq təmin edilməsinə səbəb olur — sadəcə siyasət vədindən yox. Açar sızan kimi, hətta yalnız Babylon yox, hər kəs slashinq tranzaksiyasını qura və yayımlaya bilər. Bu mərhələdə komitə səsverməsi də yoxdur, apellyasiya prosesi də yox — sadəcə ifşa edən riyaziyyat.
Aydın bir cavab görmədiyim məsələ: hər blok hündürlüyü üçün açar generasiyası, eyni anda bir neçə BSN işlətdikləri üçün finalitet provayderləri üçün nəzərə çarpan əməliyyat yükü yaradırmı və bu yük özü bir hücum səthi ola bilərmi — məsələn, provayder yüklənmə altında təsadüfi (randomness) yaddaşını səhvən, zülm (malice) yox, səhv üzündən təkrar istifadə etsə?
EOTS təhlükəsizliyi yalnız sırf riyazi zəmanətdirmi, yoxsa finalitet provayderlərinin həm də key-management (açar idarəetməsi) baxımından möhkəm infrastruktura sahib olmasına səssizcə etibar edir?
$BABY

#baby $BABY Mən əvvəllər Bitkoinin hərəkətsiz (idle) tədarükünü sabit bir məhdudiyyət kimi düşünürdüm — hərəkətsiz saxlanılan bir aktivin işlədilənə nisbətən daha dəyərli olacağı fikri. Sonra isə “idle”in əslində nəyə bərabər gəldiyini araşdırdım.

Hazırda dövriyyədə olan Bitkoinin 99%-dən çoxu tam şəkildə kilidlənməmiş (staked deyil). Bu sadəcə yuvarlaqlaşdırma xətası deyil — bu, bütün kripto bazarında ən böyük passiv kapital hovuzudur; təxminən bir trilyon dollar iqtisadi çəki elə-belə qalıb, yalnız pul kisələrində oturur.

Mənə baxışımı dəyişən məqam belə oldu: digər əsas zəncirlər təhlükəsizliyini sıfırdan qurdu — illər ərzində yaradılmalı, təşviq edilməli və sıfırdan böyüdülməli olan staked kapital üçün yarışdılar. Bitkoində bu problem yoxdur. Kapital artıq mövcuddur. Bu, məkanın ən etibarlı dəyər saxlayıcısıdır. Yeganə çatışmayan hissə onu etibarlı edən və ilk növbədə ona güvən yaradan “custody” (sahibliyin qorunması) zəmanətlərini qırmadan işə salacaq mexanizm idi.

Buradakı əsas mərc @BabylonLabs_io -in — yəni Bitkoinin yeni bir istifadə halına ehtiyacı olması deyil; əksinə, həmin istifadə halının bütün bu müddət ərzində istifadəsiz oturmasıdır. Bu, tələbin olmamasından yox, texniki bir boşluqdan bloklanmışdı.

Düşünmürəm ki, bu proses bir gecəyə həll olunacaq. Real qəbul üçün kifayət qədər BSN işə düşməlidir, kifayət qədər “finality” provayderləri etibarlı olduqlarını sübut etməlidir, və kifayət qədər delegatorlar da yazdığım səylə (diligence) həqiqətən həmin işlərə girişməlidir. Mexanizm artıq işləkdir. Bu mexanizmin o trilyon dolların mənalı bir hissəsinə qədər miqyaslanıb-mi çıxmayacağı hələ də açıq sualdır; əvvəlcədən qəti nəticə kimi qəbul edilmir.

Növbəti mərhələyə keçərkən izlədiyim məqam BSN-lərin ümumi sayından ibarət deyil — məhz o “idle” 99%-in hansı faizinin həqiqətən hərəkətə başlamasıdır.
$1000RATS $IDOL
@BabylonLabs_io #1000sats

#HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B

Babilə (Babylon) nə qədər hərəkətsiz (idle) Bitkoin köçəcək?

#baby $BABY @BabylonLabs_io

Əvvəllər “staking” anlayışının avtomatik olaraq sikkələrini başqa birinə vermək demək olduğunu düşünürdüm—sadəcə nağdlaşdırana qədər. Sonra isə Babylon staking əməliyyatına daxil olan kimi BTC-nin əslində nə baş verdiyini araşdırdım.

Heç vaxt nəzarətimdən çıxmır.

BTC, real aktivin əvəzinə duran tokenin “wrapped” formada olmadığı, açarları saxlayan qəyyumun olmadığı və istismara məruz qala biləcək körpü (bridge) müqaviləsinin olmadığı bir ssenari ilə, birbaşa Bitcoin-ə uyğun skript vasitəsilə kilidlənir. Kilid mövcuddur və Bitcoin-in öz zəncirindədir; Bitcoin-in öz qaydaları ilə tətbiq olunur — mənim indiyə qədər etdiyim hər bir əməliyyatı artıq təhlükəsiz edən eyni qaydalarla.

Əslində baş verən budur: iki xərcləmə (spending) yolu nəzərdə tutulmuş Taproot skripti. Biri vaxt məhdudiyyəti (timelock) bitəndən sonra BTC-ni mənə geri qaytarmağa imkan verir. Digəri isə mənim tapşırdığım (delegasiya etdiyim) validator protokolu pozarsa yalnız o zaman aktivləşir — bu isə slashing yoludur və vəsaitlərimin nəzərdə tutduğum yoldan kənara çıxdığı yeganə ssenaridir.

Bunu riskin sıfır olması kimi başa düşmürəm. Müəyyən şərtlərin icrası ilə məşğul olan bir “covenant committee” var və pis yekunlaşdırma (finality) təminatçısına delegasiya etmək hələ də nəticələr doğurur. Amma “açarlarınızı bir şirkətə etibar edin” ilə “Bitcoin script-i ilə tətbiq edilən, müəyyən və yoxlanıla bilən mexanizmə etibar edin” arasında real fərq var. Qəyyumlu staking sizdən bir vədi inanmağı istəyir. Bu isə sizdən kodu yoxlamağı tələb edir.

BTC-ni məhz başqasından asılı olmamaq üçün tutan hər kəs üçün vacib olan detal budur: gəlir (yield) rəqəmi yox, həmin gəliri səssizcə qazanmaq, Bitcoin-in aradan qaldırmaq üçün qurulduğu eyni asılılığı yenidən doğururmu—doğurmurmu.

@BabylonLabs_io Mən Babilonun Finality Provider modelini adi PoS delegasiyası ilə müqayisə edirdim və diqqətimi çəkən bir şey oldu: təşviq (incentive) strukturu insanların düşündüyü kimi simmetrik deyil.
Əksər delegasiya edilmiş PoS sistemlərində, əgər validator qaydalara zidd davranırsa, cəza sizin stake-inizin də kəsilməsi ilə onun aldığı cəzaya şərik olur. Məna tam budur: delegatorları həqiqətən kimə delegasiya etdiklərini yoxlamağa məcbur edir. Babilonun quruluşu Bitcoin üçün həmin əsas ideyanı saxlayır—seçdiyiniz Finality Provider-ə əsasən sizin BTC-niz slashing riskinə məruz qalır; halbuki siz sikkilərin kuryorluğunu (custody) heç kimə vermirsiniz.
Niyə bu önəmlidir: self-custody adətən “təhlükəsizlik” kimi reklam olunur, qalan hər şey durur. Amma self-custody başqa birinin pis davranışına məruz qalmağınızı aradan qaldırmır—sadəcə kuryor (custodial) riskini xüsusi olaraq çıxarır. Siz BTC-yə tam nəzarəti saxlaya bilərsiniz, amma diqqətsiz delegasiya etsəniz, slashing nəticəsində onu itirə bilərsiniz. Bu “birjaya hücum oldu” riskindən ciddi dərəcədə fərqli bir riskdir, amma sıfır deyil; məncə, Bitcoin staking ətrafındakı mesajlaşma bəzən bu xətti bulanıqlaşdırır.
Adını çəkməyə dəyər ticarət (trade-off): bu, real due diligence-i stakerlərin üzərinə qoyur. Finality Provider seçimi kosmetik seçim deyil—bu, aktiv risk qərarıdır; uptime, imzalama davranışı, əməliyyat təhlükəsizliyi kimi məsələlər bu şəkildə sizin probleminizə çevrilir. İlk dəfə BTC staking edən çox adamlar bu cür düşünməyə öyrəşməyib, çünki BTC özü insanları əsasən yalnız custody riskinə yönəltmək üzrə “tərbiyə edib”, başqa şeylərə yox.
Yəni, təşviq dizaynı kağız üzərində düzgündür—nəzəri olaraq etibarlı Finality Provider-lər etibar qazanmalı, pis olanlar isə delegasiya çatışmazlığından “susdurulmalıdır”. Amma bu bazarın həqiqətən formalaşıb-formalaşmaması stakerlərin dizaynın güman etdiyi due diligence-i etməsindən asılıdır.#baby $BABY

Bu gün @BabylonLabs_io docs-larında vaxt sərf edib Finality Providers-in əslində nə etdiyini anlamağa çalışdım. Rol ilk göründüyündən daha az aydındır.

Normal PoS şəbəkəsində validatorlar səsvermə gücü qazanmaq üçün zəncirin doğma tokenini stake edirlər. Finality Providers isə fərqli bir iş görür. Onlar staker-lardan BTC delegasiyaları alır və delegasiya olunmuş həmin Bitcoin-i blok finality-sinə dair səslərinin iqtisadi çəkisi kimi istifadə edirlər.

Staker heç vaxt BTC-ni köçürmür. Heç bir şəxsi açar hərəkət etmir. BTC, Bitcoin üzərində self-custodial skript daxilində kilidlənmiş vəziyyətdə qalır. Delegasiya olunan yalnız BTC-nin təmsil etdiyi səsvermə gücüdür. Finality Provider səs verir. Bitcoin həmin səsi iqtisadi baxımdan dəstəkləyir, amma bu heç vaxt staker-in nəzarətindən çıxmır.

Düşüncəm dəyişən məqam budur: bu, bu təhlükəsizliyə güvənən PoS şəbəkələri üçün nə deməkdir. Onların təhlükəsizliyi artıq yalnız doğma tokeninin dəyərindən asılı deyil. Hər finality səslinin arxasında duran Bitcoin-in iqtisadi çəkisi həlledicidir. Bu, bu gün əksər PoS zəncirlərində olmayan, köklü şəkildə fərqli bir təhlükəsizlik əsaslandırmasıdır.

Slashing tərəfi də mənzərəni tamamlayır. Əgər Finality Provider ikiqat imza atarsa, EOTS onların şəxsi açarını aşkarlayır və slashing şərtləri avtomatik işə düşür. Onlara delegasiya edilən səsvermə gücü real nəticələrlə bağlı idi.

Məni düşündürən son məqam staker-in mövqeyi oldu. Siz davranışını birbaşa idarə edə bilmədiyiniz bir Finality Provider-ə delegasiya edirsiniz. Kriptoqrafiya principal-ınızın qorunmasını təmin edir. Amma şəbəkələrin təhlükəsizliyini təmin edən tərəflərin sağlamlığı üçün provider seçiminiz yenə də önəmlidir.

Səsvermə gücü delegasiya olunur, amma BTC heç vaxt tərpənmir. Bəs delegasiya ediləcək yeri seçən staker üçün məsuliyyət (accountability) faktiki olaraq necə görünür?

#baby $BABY

#baby $BABY / @BabylonLabs_io
Bu gün Babylon sənədlərini oxuyarkən bir sualda tez-tez dayanırdım.

Bitcoin-in smart kontraktları yoxdur. Bəs heç vaxt Bitcoin zəncirini tərk etməyən BTC üzərində slashing (cəzalandırma) necə tətbiq olunur?
Covenant Committee (Əhdnamə Komitəsi) cavabdır, amma düşündüyüm kimi deyil.

Hər bir staking (stoklama) əməliyyatı aktivləşməzdən əvvəl komitə tərəfindən yoxlanılır. Onlar unbonding (kiliddən azad etmə) və slashing şərtlərinin Babylon-un qaydalarına uyğun olduğunu yoxlayırlar. Kvoruma çatdıqlarmı, həmin anda unbonding və slashing əməliyyatlarını əvvəlcədən (pre-sign) imzalayırlar. Bu imzalar staking dövrü başlamazdan əvvəl artıq hazır olur.

Bu əvvəlcədən imzalama detayı mənim bütün modeli başa düşmə tərzimə dəyişiklik gətirdi. Komitə səhv davranışı izləyib ona reaksiya vermir. Onlar hər şeyi əvvəlcədən imzalayırlar. Bundan sonra slashing-i icra etmək üçün yalnız Finality Provider-in öz imzası çatmır. Və həmin imza yalnız provider ikiqat imza atanda (double sign) əlçatan olur; EOTS-in məhz bunu üzə çıxarmaq üçün nəzərdə tutulması da budur.

Məndə qalan ən önəmli məqam staker-lər üçün nəzərdə tutulmuş qorunmadır. Komitə sizin stake-inizi oğurlaya bilməz. Yanlış slashing yarada bilməz. Slashing şərtində sizin öz EOTS açarınız tələb olunur və onu yalnız siz saxlayırsınız. Hətta tamamilə komprometlənmiş komitə belə Bitcoin-i istədiyinizə qarşı hərəkət etdirə bilməz...

Mən hər yerdə “etibadsız Bitcoin staking” ifadəsini görüb elə-belə qəbul etmişdim. Sonra staking skriptinin sənədlərini həqiqətən oxudum.
Orada bir kovenant komitəsi var.

Bitcoin-in publika açarları birbaşa staking tranzaksiyasına “bişirilmiş” tərəflər qrupu. Onların işi: protokolun hər dəfə on-çeyn konsensus tələb etmədən slashing və unbonding-i tətbiq etməsi üçün müəyyən xərcləmə yollarına birlikdə imza verməkdir.

Onlar olmadan bütün mexanizm işləmir — unbonding tez olmayacaq, slashing tətbiq olunmayacaq.

Yəni burada başlıqda heç kimin demədiyi real kompromis var: Babylon kənar custodian-ı çıxarır, amma bütün etibarlı tərəfləri yox etmir. O, etibarı tək bir şirkətlə və audit edə bilmədiyiniz ledger ilə yox, kriptoqrafik məhdudiyyətləri olan müəyyən bir komitəyə qədər kiçildir.
Bu, real fərqdir — qaydaları dərc olunmuş multisig komitəsi, hesabınızı dondura bilən custodian kimi risk deyil. Amma bu “tam etibadsızlıq” da deyil və bunu elə bilindiyi kimi qəbul etmək insanları sonradan sürprizə salır.

Bu gün staking edənlərin çoxu həmin komitənin kimlərdən ibarət olduğunu, ya da vəsaiti hərəkət etdirmək üçün neçə imza həddinin (threshold) lazım olduğunu yoxlamır.

Mən yoxladım. BTC-ni nəyəsə kilidləməzdən əvvəl bunu etmək dəyər.

Etibadsız “bəli/xeyr” deyil. Bu bir spektrdir və Babylon onu custodial körpülərlə müqayisədə bir az daha irəli aparıb — amma hamısına qədər deyil.

#baby $BABY @BabylonLabs_io

#baby $BABY bu gün @BabylonLabs_io staking sənədlərini yoxladım və bir detalın burada “native” anlayışını necə düşündüyümü yenidən çərçivələdiyini anladım.

Bitcoinə gəlir gətirən mövcud hər bir yolun bir məqamda aktiv mübadiləsi tələb edir. “Wrapping” isə BTC-ni onun dəyəri körpüdə saxlanan aktivdən asılı olan sintetik törəməyə çevirir. Bridging (körpüləmə) BTC-ni təmsil edən nəyisə başqa zəncirdə hərəkət etdirir, BTC-nin orijinalı isə başqa yerdə kilidlənmiş qalır. Hər iki halda sonda Bitcoinə deyil, Bitcoinə dair bir tələb (claim) tutursunuz.

Babylon-un “staking” mexanizmi isə fərqli işləyir. BTC-niz birbaşa Bitcoin-də Bitcoin-in öz skript dili ilə kilidlənir; timelock-lar və imza aqreqasiyası istifadə olunur və Bitcoin tərəfdə hər hansı smart kontrakt sisteminə ehtiyac yoxdur. BTC heç nəyə çevrilmir. O, stakerin idarə etdiyi self-custodied skript daxilində tam olaraq olduğu kimi qalır: bir Bitcoin UTXO.

Kilidlənmişkən həmin BTC-nin nə etdiyi isə maraqlı hissədir. O, Finality Providers-un arxasında delegated stake kimi proof of stake şəbəkələrinə iqtisadi təhlükəsizlik təmin edir. Əgər bir Finality Provider iki dəfə imza atsa (double sign), onun arxasında duran stake slashing-ə məruz qala bilər. Real iqtisadi girov kimi Bitcoin-in mövcudluğu, onu əsas götürən şəbəkələr üçün təhlükəsizliyi inandırıcı edən şeydir.

Unbonding detayı mənimlə qaldı. Timelock müddəti bitəndə edilən default (standart) geri çəkilmə Babylon-dan və ya istənilən xarici operatordan heç bir əməkdaşlıq tələb etmir. Erkən unbonding isə Covenant Committee-nin (Əhd Komitəsi) ko-imza­sını tələb edir, sonra isə vəsaitlərin geri çəkilə bilməsi üçün 7 gün gözləmə var. Hətta hər hansı xarici tərəf yoxa çıxsay belə staker default yolla həmişə çıxış edə bilər.

Bu müstəqillik bir çox wrapped BTC yanaşmalarının təkrarlaya bilmədiyi xüsusiyyətdir. Çıxış yolu vault yaradılarkən Bitcoin skriptində kodlanır; kimsənin başqasının custody-sində saxlanılmır.

Əgər nəhayət Bitcoin üzərində staking gəliri heç vaxt Bitcoin-dən çıxmadan mümkün olarsa, zaman keçdikcə wrapped alternativlərə olan tələbat nə olur????

#baby $BABY
Bu gün Babil sənədlərindən keçdim və bir rəqəm məni dayandırırdı. Bitkoinin yalnız 1%-i DeFi-də istifadə olunur.

Bitkoin bazar kapitallaşmasına görə ən böyük kripto aktivdir. Üstəlik, geniş fərqlə desək, o, deşentralizasiya olunmuş maliyyədə ən çox “idle” qalan (istifadə olunmayan) aktivdir. Səbəb laqeydlik deyil. Giriş xərci. DeFi-yə mövcud olan hər bir yol Bitkoin sahibinin ya üçüncü tərəfə əl dəyişdirməsini (custody), zəncirlərarası körpüdən keçirməsini, aktivini sintaetik (uydurma) versiyaya çevirməsini, ya da öhdəliyi real risk olan bir vasitəçiyə etibar etməsini tələb edir. Bunlar məhz uzun illər ərzində Bitkoin sahiblərinin rədd etdiyi uzunmüddətli güzəştlərdir.

@BabylonLabs_io -in ətrafında qurduğu isə fərqli başlanğıc nöqtəsidir. BTC heç vaxt Bitkoini tərk etmir. O, depozit qoyan şəxsin vault yaradılarkən birgə imza atdığı (co-signs) Taproot skriptinə kilidlənir. Hər bir qanuni xərcləmə yolu vault işə düşməzdən əvvəl əvvəlcədən imzalanır. Bundan sonra heç bir tərəf yeni bir xərcləmə uydura bilməz. Protokol BTC-ni başqa yerə köçürə, onu borc verə və ya başqa məqsədə yönləndirə bilməz. Təminat (collateral) yalnız skriptin icazə verdiyini edir.

Ethereum tərəfdə isə, bir protokol kontraktı hər bir vault-u izləyir və inteqrasiya olunmuş DeFi tətbiqinə onu girov kimi qəbul etməyə imkan verir. Çarpaz-zəncir vəziyyət keçidləri etibarlı vasitəçiyə görə deyil, kriptoqrafiya vasitəsilə təmin edilir. Etibar fərziyyəsi kassirin (custodian) öhdəliklərinin ödənmə qabiliyyətindən protokolun kriptoqrafiyasına və iki əsas şəbəkəyə keçir.
Məni ən çox təsirləndirən çərçivə Babylonun ilkin mənada vault adlandırdığı şeydir. Çox istifadəçinin riski birlikdə bölüşdüyü hovuzlu kapital kontraktı deyil. Ayrılmış və depozit qoyan şəxsin sahib olduğu Bitcoin çıxışı (output). DeFi likvidlik hovuzundan daha çox bankdakı təhlükəsiz bölmə (secure compartment) kimidir.

Əgər Bitkoinin 99%-i DeFi-dən kənarda qalırsa, çünki mövcud hər bir yol nəsə verməyi tələb edir, giriş xərci həqiqətən yox olarsa, məkan necə görünər???