Bir orijinal Ledger cihazını açdıqdan sonra, TBC öz-özünə idarə etmənin həqiqi sərhədlərini müzakirə edir

Bir müntəzəm kanaldan alınmış bir hardware cüzdan, qablaşdırması tamdır, təhlükəsizlik etiketi dəyişdirilməyib, açıldıqda özünü yoxlama hər şey normaldır. Lakin onun içində bərpa frazasını ələ keçirmək üçün gizli bir komponent yerləşdirilib.

2026-cı il 15 oktyabrda, Ledger bu hadisəyə rəsmi cavab verdi: hücum edənlər orijinal cihazı alıb, onu açaraq hardware yerləşdirib, sonra Cənub-Şərqi Asiya distribyutor kanalları vasitəsilə bazara geri döndəriblər. Ledger çipin, əməliyyat sisteminin və serverlərin heç birinin pozulmadığını vurğuladı, bu hadisəni lokal distribyutor kanalı hücumu olaraq qiymətləndirdi, sistematik təchizat zənciri hücumu deyil.

14 oktyabrda, Tom's Hardware Bloomberg-in hesabatına istinad edərək, itkilərin təxminən 93 milyon dollar olduğunu bildirdi. Aydınlaşdırmaq lazımdır: bu rəqəm üçüncü tərəf mediadan gəlir, Ledger-in rəsmi bəyanatında təsdiqlənmiş məbləğ deyil.

Rəqəmin kimə aid olması vacib deyil. Vacib olan, onun ifşa etdiyi məsələdir.

I. Öz-özünə idarə etmə riskləri aradan qaldırmır, sadəcə risklərin yerini dəyişir

Son on ildə, sənaye çox təmiz bir hekayə danışdı: kriptovalyutanızı bir mübadilə platformasında saxlayırsınızsa, taleyinizi bir şirkətə təhvil verirsiniz; özəl açarınızı öz əlinizdə saxlayırsınızsa, azadsınız.

Bu hekayənin bir hissəsi doğrudur.

Mübadilə platformalarının idarə etdiyi risklər mərkəzləşdirilmiş və görünəndir: mənimsəmə, sıxışdırma, iflas, tənzimləmə dondurması. FTX-dən sonra, "Açarlarınız sizdə deyilsə, valyutalarınız da sizdə deyil" daha çox istifadəçi tərəfindən qəbul edildi, sənaye də öz-özünə idarəetmə alətləri və köməkçi sözlərin saxlanması haqqında daha ciddi müzakirələrə başladı.

Lakin öz-özünə idarə etmə risklərin sonu deyil, risklərin köçürülməsidir.

Bu, "platforma pis niyyətli ola bilərmi" sualını başqa bir sual dəstinə dəyişir: cihazınız haradan gəlib? Firmware dəyişdirilibmi? Köməkçi söz hansı mühitdə yaradılıb? İmza zamanı ekranda görünən məzmun, faktiki imzalanan əməliyyatla uyğun gəlirmi? Kim bu köçürməni başlatmağa səlahiyyətlidir?

Bu sual dəstində, hər hansı bir mərhələnin itirilməsi, nəticə etibarilə mübadilə platformasının iflas etməsi ilə eyni nəticəni verəcək. 93 milyon dollar dəyərindəki üçüncü tərəf təxminləri, əslində bu dərsi satın alır.

Daha da çətin olanı, bu cür hücumların forması dəyişib. O, kriptologiyanı, çipi, konsensus alqoritmini pozmur. O, fiziki dünya və etibar zəncirinin kəsişmə nöqtəsini pozur: distribyutor kanalları, açma mərhələsi, ikinci dəfə qablaşdırma, logistika.

Kriptologiya bir imzanın etibarlılığını sübut edə bilər, lakin imzanı atan əlin zorlandığını sübut edə bilmir, həmçinin o cihazın görünməyən yerdə köməkçi sözləri gizlicə göndərib-göndərmədiyini də sübut edə bilmir.

Təhlükəsizlik modelində ən zəif halqa heç vaxt alqoritm olmur, insan, cihaz və prosesdir.

II. Tək nöqtə özəl açarını bir neçə təsdiqlənə bilən şərtə bölmək

Ledger hadisəsinin həqiqi dərsi "hardware cüzdan istifadə etməyin" deyil, yalnız "özəl açar mənim əlimdədir" bu fərziyyəyə güvənmək, özü tək nöqtə nasazlığıdır.

Düzgün istiqamət, vəsaitin köçürülməsinin eyni anda bir neçə şərti yerinə yetirməsini tələb etməkdir və bu şərtlər fərqli etibar sahələrində yayılmalıdır.

TBC-nin bu məsələdəki mövqeyi daha mütəmadi olmalıdır. O, son hücumları aradan qaldıra biləcəyini iddia etmir, hər hansı bir zəncir bunu edə bilmir. Onun dəyəri, UTXO orijinal müqaviləsi və çox imza alətləri ilə, layihələrin tək nöqtə özəl açar riskini bir neçə təsdiqlənə bilən şərtə bölməsinə imkan tanımasıdır.

Xüsusilə, TBC SHA256 PoW və UTXO modelini istifadə edir, TBCNODE kodu açıq şəkildə araşdırıla bilər. UTXO modelinin təbii xüsusiyyəti budur: hər bir xərclənməmiş çıxış müstəqil skript şərtləri ilə məhdudlaşdırıla bilər, qlobal hesab balansında deyil. Bu, xərcləmə qaydalarının zəncirə yazıla biləcəyini, müəyyən bir arxa xidmətə yazılmadığını göstərir.

tbc-contract SDK zəncir üzərində sorğu, UTXO əldə etmə, əməliyyat qurma, imzalama və yayma imkanı təqdim edir və MultiSig, NFT, FT və Pool iş axınlarını əhatə edir. Rəsmi MultiSig nümunəsi 3-dən 10-a qədər olan açar arasında 1-dən 6-ya qədər imza tələbi təyin etməyə dəstək verir, sənəd 2-of-3 nümunəsini təqdim edir.

Burada tam bir ifadə vermək lazımdır: çox imza konfiqurasiya edilə bilən risk idarəetmə alətidir, avtomatik təhlükəsizlik deyil, daha da əhəmiyyətlisi, mütləq təhlükəsizlik deyil.

Əgər kiminsə düşüncəsi varsa ki, 2-of-3 konfiqurasiyası ilə hər şey yaxşıdır, bu, "hardware cüzdan almışam, artıq təhlükəsizəm" inancıyla eyni səhvdir. Çox imza hücum xərcləri strukturunu dəyişir, hücumun mümkünlüyünü deyil.

TBC AMM sənədi başqa bir şeyi izah edir: SDK yerli olaraq qurur, qiymət təklif edir və imzalayır, yayım tətbiq tərəfindən açıq şəkildə başlatılır; hovuzun vəziyyəti və aktivlərin idarə olunması UTXO və skript qaydalarına bağlıdır. Bu, öz-özünə idarə olunan əməliyyatların və icazələrin ayrılmasının əsasını təşkil edir.

Eyni zamanda sərhədləri aydınlaşdırmaq lazımdır: bu, AMM-nin müqavilə riski, qiymət riski və ya ön tərəf riski olmadığı anlamına gəlmir. Yerli imzalama "özəl açar cihazdan çıxmır" problemini həll edir, lakin "imzaladığınız əməliyyat, həqiqətən imzalamaq istədiyiniz əməliyyatdırmı" problemini həll etmir.

III. Niyə çox imza tez-tez yalnız formal bölünmədir

Bu, atlanması asan, lakin ən ölümcül hissədir.

Əgər bir neçə imza açarı eyni köməkçi sözlərdən gəlirsə, eyni cihazda saxlanılırsa, ya da eyni şəxs tərəfindən idarə olunursa, çox imza yalnız formal bölünmədir.

Hücum edən bir köməkçi söz əldə edərsə, bütün imza hüquqlarını əldə etmiş olur. Cihaz bir dəfə yerləşdirildikdə, bütün tələblər eyni anda itirilmiş olur. Bu konfiqurasiya zəncir üzərində 3-of-5 kimi görünür, lakin reallıqda 1-of-1-dir.

Ona görə də, həqiqətən soruşulması lazım olan sual "neçə imza konfiqurasiyası etdim" deyil, daha çətin suallardır:

• Bu açarların yaradılma mühiti bir-birindən müstəqildirmi?
• Onlar fiziki olaraq ayrılmış fərqli cihazlarda saxlanılırmı?
• Əməliyyatı başlatan şəxs, əməliyyatı təsdiqləyən şəxs eyni insanlardırmı?
• Yüksək riskli köçürmələrdə gecikmə və insan yoxlaması varmı?
• Açar dövriyyəsi və bərpa prosesi məşq edilibmi?

TBC-nin UTXO modeli oğurlanmış özəl açarları avtomatik olaraq bərpa etmir. Bu, qəbul edilməlidir. Zəncir üzərindəki qaydalar, hər hansı bir şərt pozulduqda, icazəsiz vəsait köçürməsini dayandırmağa imkan verir; lakin artıq özəl açar sızmışsa, aktivləri bərpa edə bilmir.

Dəstək mühəndislik praktikaları hələ də əhəmiyyətlidir: müstəqil imzalama cihazları, açar dövriyyəsi, tək əməliyyat və gündəlik limitlər, zaman kilidi, yüksək riskli əməliyyatların çox tərəfli yoxlanması və icra edilə bilən bərpa planları.

Bir başqa məsələni də açıq şəkildə bildirmək lazımdır: TBC özü də inkişaf etməyə davam etməlidir. Çox imza qarşılıqlı əlaqələrinin istifadəsi, əsas hardware cüzdanlarla uyğunluq dərinliyi, açılışda istifadə üçün icazə şablonları, müstəqil üçüncü tərəf standart testləri və SDK, cüzdan, AMM komponentlərinin davamlı auditi, hələ də davam edən işlərdir.

TBCNODE artıq CertiK və SlowMist-in versiyalı təhlükəsizlik yoxlama qeydlərinə malikdir. Lakin audit yalnız müəyyən versiya, müəyyən sahənin yoxlandığını sübut edə bilər, o, hardware terminalını əhatə etmir, istifadəçinin açar idarəetmə vərdişlərini əhatə etmir, gələcəkdə təqdim ediləcək kodu əhatə etmir, həmçinin bütün tətbiq qatının məntiqini əhatə etmir. Audit hesabatını təhlükəsizlik sertifikatı kimi qəbul etmək, başqa bir tənbəllik formasıdır.

IV. Həqiqi öz-özünə idarə etmə zəncir üzərində bir qaydadır

Açılmış cihazın yanına qayıdaq.

Bu, bizə "özəl açar öz əlimdədir" ifadəsinin zəruri bir şərt olduğunu, lakin kifayət qədər şərt olmadığını xatırladır. Cihazın mənbəyi, imza hüquqlarının bölüşdürülməsi, zəncir üzərindəki xərcləmə qaydaları, bu üç şey eyni anda yerinə yetirilməlidir ki, təhlükəsizlik strukturu dayana bilsin.

Sənayenin gələcəkdəki dəyişiklikləri çox güman ki, hardware cüzdan istehsalçıları kanalların idarə olunmasını və açılma dizaynını gücləndirəcəklər, sığorta və idarəetmə xidmətləri fiziki təchizat zənciri risklərini yenidən qiymətləndirəcək, layihə tərəfləri isə "icazə dizaynını" "kod auditinə" bərabər əhəmiyyətli mühəndislik məsələsi kimi qəbul etməyə başlayacaqlar.

TBC bu mənzərədə "hardware hücumlarına qarşı həll" deyil, icazə qaydalarını zəncirə yazmaq üçün alətlər təqdim edir: UTXO orijinal müqaviləsi xərcləmə şərtlərini məhdudlaşdırır, çox imza imza hüquqlarını fərqli etibar sahələrinə bölür, öz-özünə idarə olunan əməliyyat komponentləri özəl açarların yerli olaraq qalmasını təmin edir.

Həqiqi öz-özünə idarə etmə, yalnız bir özəl açara sahib olmaq deyil, eyni zamanda hər hansı bir tək nöqtə itirildikdə, zəncir üzərindəki qaydaların icazəsiz vəsait köçürməsini dayandırmağa imkan verməsidir.

Məlumat mənbəyi Məlumat linki: Ledger · Tom's Hardware · TBCNODE · Contract SDK · MultiSig · AMM · CertiK · SlowMist