727 FinanceBir olay sadece varlıkları değil, güveni de alıp götürür. Kripto böyle devam edemez; kendimizi kurtarmalıyız.
Yazar: Robert Mao, ArcBlock'un Kurucusu ve CEO'su
Bu makale, herkesin özgürce çoğaltması ve iletmesi için yetkilendirilmiştir; umuyoruz ki daha fazla insan sektörün kendini kurtarması için bu çağrıyı görür.
Kripto bu şekilde devam edemez. Tekrar tekrar yaşanan büyük çaplı hırsızlıklar sadece varlıkları değil, katılımcıların tüm sektöre olan güvenini de alıp götürüyor. Kendimizi kurtarmalıyız.
29 Ekim 2026'da Binance'te büyük bir güvenlik olayı meydana geldi. Ön duyurusunda yaklaşık 6,3 milyar dolar değerinde varlığın etkilendiği tahmin edildi ve etkilenen varlıkların yaklaşık 3 milyar doları dondurulmuştu; soruşturma başlangıçta bir DevOps mühendisinin dizüstü bilgisayarına işaret etti ve ardından diğer olası sızma noktaları da keşfedildi. Binance ayrıca cüzdan özel anahtarının sızdığına dair herhangi bir kanıt bulunmadığını belirtti. Etkilenen tutar nihai net kayıp değildir ve tam saldırı zinciri hâlâ soruşturma altındadır. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Bu girişim, Ethereum ve Solana gibi blok zinciri projelerinin inşaatçılarına ve ayrıca Binance, Coinbase, Kraken ve katılmaya istekli tüm borsalara, cüzdanlara, protokollere ve güvenlik inşaatçılarına yöneliktir: varlıkları korumak için temeli birlikte yeniden inşa edelim. Ben katılmaya istekliyim ve daha fazla insanın birlikte harekete geçmesini umuyorum.
Bu zaten yeterince ağır. Ancak beni daha çok endişelendiren, bu olayın Kripto'ya olan güveni ne kadar yok edeceği ve kaç saldırganın bu sektörü hâlâ saldırmaya değer bir hedef olarak görmesine yol açacağıdır. Kayıpları nihayetinde birileri üstlense bile, tazminat kullanıcıların güvenini otomatik olarak onaramaz ve aynı türden yıkımın tekrar yaşanmasını da engelleyemez.
Binance, bugün sorunla yüzleşmemizi zorlayan sadece giriş noktasıdır. Başka yöne baktığımızda, borsalar, köprüler, zincir üstü protokoller ve cüzdanlar uzun süredir uzun bir yara izi bırakmıştır. Yeni ağlar ve ürünler sürekli ortaya çıkıyor, ancak eski başarısızlık modelleri tekrar tekrar tekrarlanıyor. Bir duyuru yapıp bir süre bekleyemeyiz ve sonra bir sonraki olayı rutin olarak ele alamayız.
Ayrıca kabul etmeliyiz ki dolandırıcılıklar ve sadece kavram yaratıp inşa etme sorumluluğunu üstlenmeme uygulaması bu sektöre uzun süredir zarar vermiştir. Teknolojiyi ve altyapıyı ciddi şekilde inşa eden ekipler de kaybedilen güvenin sonuçlarını birlikte üstlenmek zorundadır. İnsanlar tüm Kripto'yu bir dolandırıcılık olarak gördüğünde, gerçekten korunmaya değer teknoloji ve keşif de onunla birlikte terk edilebilir.
ArcBlock'un kurucusu ve Kripto ile Blok Zinciri'nde bir uygulayıcı olarak, böyle bir sonucu kabul etmeye istekli değilim. Bu sektörün korunmaya değer bir değeri olduğuna inanıyorum ve kendi güvenlik temelimizin sorumluluğunu üstlenmemiz gerektiğine de inanıyorum. Bir sonraki olayı pasif bir şekilde beklemeye devam edersek, tekrarlanan kan kaybı sonunda birlikte inşa ettiğimiz her şeyi yok edebilir.Şu girişimi başlatmak istiyorum: borsa, cüzdan ve blok zinciri geliştiricileri, varlık kontrolü ve güvenlik doğrulamasının temelini ortaklaşa yeniden inşa etmeli; böylece tek bir ihlalin yol açacağı hasarın kapsamı sınırlandırılabilsin. Aşağıdaki zaman çizelgesi değişimin neden gerekli olduğunu açıklıyor; ardından gelen teknik öneri, başlayabileceğimize inandığım çalışmadır.
2008'de Satoshi Nakamoto, ödemeleri güvenilir aracılara daha az bağımlı hale getirmeye çalışan eşler arası bir elektronik nakit sistemi önerdi. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Ancak o zamandan bu yana yaşanan büyük olaylar, fonların, yetkilendirmenin ve yazılım bağımlılıklarının yeniden yoğunlaşması sorununu defalarca ortaya koydu.
Aşağıda merkezi borsalar (CEX), merkeziyetsiz borsalar (DEX), köprüler ve cüzdanlar gibi alanlardaki temsili olayların kronolojik bir listesi yer alıyor. Bu ne eksiksiz bir olay veritabanı ne de yıl bazında kayıp istatistiğidir. Tutarların belirtildiği yerlerde, olay anındaki yaklaşık brüt etkiyi ifade eder; hırsızlık, dondurma ve sonraki geri kazanım ayrı ayrı açıklanır ve kalıcı kayıplar olarak toplanamaz.
2008 · Bitcoin Whitepaper
Başlangıç noktası
Bitcoin whitepaper, finansal kurumları aracı olmadan eşler arası ödemeler önerdi.
Kaynak
2011–2014 · Mt. Gox uzun süreli hırsızlık
CEX
Mt. Gox uzun süreli hırsızlığa maruz kaldı ve sonunda faaliyetlerini durdurdu. Daha sonra ABD Adalet Bakanlığı iddianamesi, 2011 ile 2014 arasında yaklaşık 647.000 BTC'nin çalındığını öne sürdü. Bu, 2014'te tek günlük bir saldırı değildi.
Kaynak
2012 · Bitcoinica ve Bitfloor
CEX / saklama altyapısı
Bitcoinica'nın Linode barındırma ortamı ele geçirildi; aynı yıl Bitfloor'un şifrelenmemiş cüzdan yedeği bir saldırı giriş noktası haline geldi. Platformun arkasındaki sunucular ve yedekler de varlık güvenliği sınırının bir parçasıdır.
Kaynak
2015 · Bitstamp sıcak cüzdan
CEX
Bitstamp'in sıcak cüzdanı ele geçirildi ve işletim ortamı ardından yeniden inşa edildi. Olayın kapsamı ile çevrimdışı rezervler arasındaki resmi ayrım, izolasyonun maruz kalma kapsamını sınırlayabileceğini gösterdi.
Kaynak
2016 · Bitfinex
CEX
Bitfinex'ten yaklaşık 120.000 BTC çalındı. Çoklu imza düzenlemeleri hâlâ uçtan uca bağımsız yetkilendirme ve doğrulama gerektirir.
Kaynak 1 · Kaynak 2
2016 · The DAO
Zincir üstü protokol
The DAO sözleşmesi yeniden giriş saldırısına maruz kaldı ve yaklaşık 3,6 milyon ETH bir alt DAO'ya aktarıldı, ardından bir Ethereum çatallanması tetiklendi. Meşru bir yürütme yolu felaket niteliğinde iş sonuçları üretebilir.
Kaynak 1 · Kaynak 2
2017 · Parity ortak cüzdan kütüphanesi
Sözleşme cüzdanı
Parity ortak cüzdan kütüphanesi yok edildi ve yaklaşık 513.000 ETH donduruldu. Aktarılmamış olsa bile fonlar, ortak kod bağımlılıkları nedeniyle kullanılamaz hale gelebilir.
Kaynak
2018 · Coincheck
CEXCoincheck'in NEM sıcak cüzdanı çalındı. Çevrimdışı rezervler, sıcak cüzdan izinleri ve iş ihtiyaçları arasındaki sınır bir kez daha sorun haline geldi.
Kaynak
2019 · Binance
CEX
Binance, tek bir işlemde 7.000 BTC'nin çekildiğini duyurdu. Büyük ölçekli varlık çıkışları imzalamadan önce kısıtlanmalıdır.
Kaynak
2020 · KuCoin
CEX
KuCoin sıcak cüzdan olayı, ardından çok taraflı işbirliğiyle büyük miktarda varlık geri kurtarıldı. Brüt çalınan tutar ile nihai kayıp aynı sayı değildir.
Kaynak
2021 · Poly Network
Zincirler arası protokol
Yaklaşık 612 milyon dolar değerinde varlık Poly Network'ten transfer edildi ve ardından aşamalı olarak iade edildi. Zincirler arası yetkilendirme ve varlık kontrolü yalnızca normal iş yollarıyla sağlanamaz.
Kaynak
2022 · Ronin köprüsü
Köprü
Ronin doğrulayıcı izinleri ele geçirildi ve 173.600 ETH ile 25,5 milyon USDC transfer edildi. Birden fazla doğrulayıcının anahtarları da aynı saldırı zincirine düşebilir.
Kaynak
2022 · Slope cüzdanı
Cüzdan
Solana ekosistemindeki Slope cüzdan olayı. Solana resmi olarak özel anahtar bilgilerinin yanlışlıkla bir uygulama izleme hizmetine iletildiğini; bunun Solana konsensüsünün ihlali olmadığını belirtti.
Kaynak
2023 · Euler
Borç verme protokolü
Yaklaşık 197 milyon dolar değerinde varlık, bir protokol güvenlik açığı nedeniyle Euler'den transfer edildi ve ardından geri kurtarıldı. Tek bir işlemdeki karmaşık kombinasyonlar iş mantığı kusurlarını büyütebilir.
Kaynak
2023 · Ledger Connect Kit
Cüzdan bağlantı aracı
Ledger Connect Kit bir tedarik zinciri saldırısına uğradı ve kötü amaçlı kod uygulama ön yüzüne girdi. Donanım cihazı güvenliği, işlem içeriği doğrulamasının yerini tutamaz.
Kaynak
2024 · DMM Bitcoin
CEX
DMM Bitcoin'den yaklaşık 308 milyon dolar çalındı. FBI ve diğer kurumlar ardından ilgili personel ve imzalama zincirini hedef alan sosyal mühendislik saldırılarını açıkladı.
Kaynak
2024 · Radiant Capital
Borç verme protokolü / imzalama
Radiant Capital'den yaklaşık 50 milyon dolar çalındı ve birden fazla geliştirici cihazı ele geçirildi. Çok taraflı imzalama yine de toplu olarak kirletilmiş işlem bilgilerine bağımlı olabilir.
Kaynak
2025 · Bybit / Safe
CEX / cüzdan ön yüzü
Yaklaşık 1,5 milyar dolarlık Bybit olayı Safe geliştirici ortamını ve ön yüzünü içeriyordu ve imzalayıcılar cüzdan kontrol mantığını değiştiren bir işlemi onayladı.
Kaynak 1 · Kaynak 2
2025 · Cetus DEX
DEXSui üzerindeki Cetus'ta yaklaşık 223 milyon dolarlık olay; araştırmacılar bir matematik kütüphanesindeki kusura işaret ediyor. EVM dışı ortamlar da kodlarını ve varlık maruziyet kapsamını aynı şekilde incelemelidir.
Kaynak
2026-07 · COLDCARD rastgele sayı kusuru
Donanım cüzdanı / seed oluşturmaBir firmware kusuru seed üretimini zayıflatarak saldırganların cihaz çevrimdışıyken ilgili özel anahtarları yeniden oluşturmasına olanak tanıdı. Yükseltme yapmak, hâlihazırda üretilmiş zayıf seed'leri düzeltemez; danışma belgesine göre geçiş hâlâ gereklidir.
Kaynak
2026-10 · Ledger donanım implantı
Donanım cüzdanı / dağıtım saldırısı
Ledger, orijinal cihazların değiştirilerek Güneydoğu Asya'daki dağıtım kanalları üzerinden dolaşıma sokulduğunu ve yerleştirilen bileşenlerin başlatma sırasında kurtarma ifadelerini çaldığını doğruladı. Satıcı, çiplerinin, işletim sisteminin ve sunucularının ele geçirilmediğini söylüyor.
Kaynak
2026 · Binance çok zincirli olay
CEX / çok zincirli
Binance başlangıçta yaklaşık 6,3 milyar dolar değerinde varlığın etkilendiğini tahmin etti ve diğer olası sızma noktalarına ilişkin soruşturmalar hâlâ sürüyor. Tek bir işletim sistemi, varlıkları aynı anda birden fazla ağda açığa çıkarabilir.
Kaynak 1 · Kaynak 2 · Kaynak 3
Burada CEX'ler olduğu kadar merkeziyetsiz borsalar, borç verme protokolleri ve köprüler de var; çalınan varlıklar ve dondurulan varlıklar var. Saldırılar farklı katmanlarda gerçekleşiyor ve giderme yöntemleri farklılık gösteriyor. Tüm bunları "kullanıcılar özel anahtarlarını koruyamadı" tek cümlesine indirgemeye karşıyım. Kullanıcılar bir aracın geliştirme ortamının, belirli bir paylaşılan kütüphanenin veya anlaşılmaz bir yetkilendirmenin tüm varlıklarının giriş noktası haline geleceğini nasıl bilebilir?
Dağıtık ağlar şimtiden çok şey yaptı, ancak varlık kontrolü için hata izolasyonu hâlâ yeterli olmaktan uzak. Zincir üstü yürütme bir işlemi sadakatle tamamlar, ancak bu işlemin neden bu kadar çok şeyi taşıma hakkına sahip olduğu sorusuna bizim adımıza yanıt veremez.
Ethereum'un katkısı önemlidir. Daha fazla kişinin zincir üstü uygulamalar yazmasını sağladı ve zengin bir araç ve geliştirme deneyimi kümesini teşvik etti. Ancak bugün birçok yeni zincir ve L2 (katman-2 ölçeklendirme ağları), EVM uyumluluğunu birincil hedefleri olarak görüyor. Ethereum akıllı sözleşmelerini yürüten sanal makine olan EVM, yaygın olarak kopyalanan bir teknik öncül haline geliyor. Uyumluluk, uygulama geçişini gerçekten kolaylaştırıyor; Unichain gibi projelerin belgeleri, eşdeğer bir yürütme ortamının değeri olarak Ethereum araçlarının yeniden kullanılmasını açıkça belirtiyor. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
EVM uyumluluğunu sektörün varsayılan yanıtı olarak ele almanın yapısal risk yoğunlaşması yarattığına inanıyorum. Birçok ağ adı olabilir ve doğrulayıcılar farklılık gösterebilir, ancak geliştiriciler aynı sözleşmeleri tekrar tekrar dağıtabilir, aynı yetkilendirme alışkanlıklarını kullanabilir ve aynı yazılım kütüphanelerine güvenebilir. Paylaşılan bağımlılıklardaki hatalar, dağıtım başka bir zincirde gerçekleştiği için ortadan kalkmaz. Bu, teknik yola ilişkin bir yargıdır; her EVM uygulamasının zorunlu olarak aynı güvenlik açığına sahip olduğu iddiası değildir.Eleştirim Ethereum'a da bu noktada yöneliyor. Genel amaçlı sözleşme yürütme yeteneği doğrudan transfer edilebilir varlıklara bağlanıyor; bu da uygulama koduna ve cüzdan etkileşimlerine muazzam bir sorumluluk yüklüyor. Sözleşmeler sözleşmeleri çağırabiliyor, yetkilendirmeler uzun süre kalıcı olabiliyor ve görünüşte sıradan bir onay, bir hesabın sonraki kontrol modunu değiştirebiliyor. Güvenlik giderek her geliştirme ekibinin bu kombinasyonları doğru anlamasına ve her kullanıcının neyi imzaladığını doğru anlamasına bağlı hale geliyor.
EIP-7702 bu sorunu çok net biçimde ortaya koyuyor. Sıradan bir transfer "bu sefer kime ne kadar" sorusudur; bir delegasyon yetkilendirmesi ise "bundan böyle bu kod parçası benim hesabım adına işlem yürütsün" anlamına gelebilir. Kullanıcı deneyimini iyileştirme ve izinleri inceltme hedefleri taşıyor, ancak bir delegasyon kurmak tek başına geniş yürütme yeteneği veriyor ve ince taneli izinlerin yine delegasyon kodunun kendisi tarafından doğru biçimde uygulanması gerekiyor. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Minfeng Qi ve diğerlerinin "EIP-7702 Phishing Attack" ön baskısı, bu tür yetkilendirmelerin imzalatılmasının ardından bir hesabın kalıcı olarak kontrol edilmesinin izini inceliyor. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) Kolaylık arttıkça güvenlik sorumluluğu da artıyor; ilki basitçe kullanıcılara devredilemez.
Bu Binance olayı birden fazla zinciri kapsıyor ve soruşturma henüz tamamlanmadı; dolayısıyla etkinin tamamı doğrudan EIP-7702'ye veya EVM'ye atfedilemez. Yeniden giriş (reentrancy), imzalama hizmetlerinin ele geçirilmesi ve ön uç tahrifatı da aynı güvenlik açığı değildir. Ancak bu tür ayrımlar, mimariyi sorgulamayı bırakmak için bahane haline gelmemelidir: üst katmanlardaki hatalar adına alt katman neden kolayca atlatılamayan daha fazla kısıt tutmuyor?
MEV de beni tatmin etmiyor. Katılımcıların işlemlerin dahil edilmesi, hariç tutulması ve sıralanması yoluyla ek değer elde ettiği alanı ifade ediyor. Bana göre, sıralama gücünü kullanarak kullanıcı işlemlerini sandviçleyip yürütme sonuçlarını kötüleştirmek, birileri bundan kâr edebildiği için korunmaya değer bir özellik olarak paketlenmek yerine düzeltilmesi gereken bir hata olarak ele alınmalı. Ethereum'un kendi belgeleri de işlem sandviçlemenin kullanıcılara zararını ve MEV'nin ağ istikrarına yönelik riskini açıkça kabul ediyor. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV yalnızca Ethereum'a özgü değildir ve arbitraj ile tasfiye gibi farklı faaliyetleri de kapsar; sektörde halihazırda hafifletme araştırmaları mevcuttur. Benim eleştirim, ağı sürdürme teşvikinin kullanıcıların işlem koşullarını feda etmenin gerekçesi haline gelemeyeceğidir. Daha iyi bir işlem sistemi, asgari teslimat sonucunu ve izin verilen ücretleri yetkilendirmeye yazmalı ve sıralayıcıların doldurulmamış bilgileri kullanıcılara zarar vermek için kullanma alanını sınırlamalıdır.Ethereum'un Crypto üzerindeki etkisinin, PHP'nin İnternet üzerindeki etkisine bir bakıma benzediğini her zaman hissettim: birçok insanın bir şeyler inşa etmesini sağladı ve aynı zamanda uzun süre geri ödenmesi gereken mühendislik borcu bıraktı. PHP'nin Ekim 2026'da hâlâ ciddi bir uzaktan kod yürütme güvenlik açığını düzeltmesi gerekti. Olgunluk ve popülerlik, sürekli sertleştirmenin yerini tutamaz. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) İnternet'in değerli yanı, dillerin, çerçevelerin ve bulut hizmetlerinin ayrı ayrı evrilebilmesidir. Biz de farklı varlık modellerinin ve yürütme yöntemlerinin gelişmeye devam etmesine izin vermeliyiz; "aynı sanal makineyle uyumluluk"u ekosisteme katılmanın bileti olarak görmemeliyiz.
Bu nedenle Bitcoin, Solana ve Ripple/XRP Ledger ekosistemlerine ve ArcBlock dahil olmak üzere geliştiricilere sesleniyorum: ortak bir güvenlik temeli inşa etmeye ciddi şekilde katılın. Standartlara ve birlikte çalışabilirliğe katılmak, önce kendini Ethereum'a dönüştürmeyi gerektirmez. Çeşitlilik, varlık kontrolü ve doğrulama yöntemlerinde hayata geçirilmeli ve kamu denetimine açık olmalıdır. Slope ve Cetus olayları bize zaten EVM dışının da güvenlik muafiyeti olmadığını hatırlattı.
Şekillenmesini umduğum şey, farklı yürütme ortamlarının benimseyebileceği bir güvenlik spesifikasyonudur: aynı varlık limitleri ve doğrulama gereksinimleri EVM ve diğer yollar tarafından ayrı ayrı uygulanabilir, ardından her birinin sağladığı garantiler ve maliyetler kamuya açık şekilde incelenebilir.
1. Temel risk kontrollerinin, varlıkları tasarruf etme yetkisini kısıtlamasına izin verin
Büyük cüzdanlar alıcı beyaz listeleri, kümülatif harcama üst limitleri ve yeni alıcılar için bekleme süreleri belirleyebilmelidir. Kilit nokta, bu kuralların aynı günlük işlem anahtarıyla derhal iptal edilememesidir. Kuralların değiştirilmesi bağımsız yetkilendirme gerektirir ve izleme ile geri alma için zaman bırakmalıdır.Mevcut akıllı hesaplar zaten bir uygulama temeline sahiptir; örneğin Safe Guards, multisig'in ötesinde işlem kısıtlamaları ekleyebilir. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Bunu, tüm varlık kontrol yollarını kapsayan, benimsenmesi daha kolay bir temel yetenek haline getirmemiz gerekiyor. Yalnızca doğrudan transferler kısıtlanırken sınırsız onaylar, modüller veya yükseltmeler üzerinden baypaslara izin verilirse koruma başarısız olur. Beyaz liste sözleşmesinin yükseltilip yükseltilemeyeceği ve alıcının izinlerinin değişip değişmediği de doğrulama kapsamına girmelidir.Apple'ın Activation Lock özelliği günlük hayattan bir ilham sunar: çalınan cihazların yeniden etkinleştirilmesini kısıtlar ve belirli çalınan parçaların kalibrasyonunu sınırlar; amaç, hırsızlıktan sonra istismar edilebilecek değeri azaltmaktır. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Cüzdanlar da bu yönde tasarlanmaya değer. Bir saldırgan bir anahtar ele geçirirse, nakde çevrilebilecek varlık aralığı sınırlı kalır ve bir saldırıdan beklenen getiri azalabilir; hizmetleri aksatma gibi risklerin yine de ayrıca ele alınması gerekir.
Ben buna varlık güvenliğinin "anayasası" diyorum: operasyonel yetki tehlikeye girebilir, ancak sınırları değiştirme yetkisi bağımsız kalmalıdır. Kurtarma süreçleri de kısıtlanmalıdır; böylece tek bir yanlış yapılandırma varlıkları kalıcı olarak kilitlemez.
II. Cüzdanları yalnızca anımsatıcı kelimeleri teslim etmek yerine güvenlik sorumluluğunu üstlenmeye yönlendirmek
Bugünün cüzdan sistemlerine karşı güçlü bir memnuniyetsizliğim var: Bir ürün sıradan bir kişiden bir dizi kelimeyi kopyalamasını, bunları asla sızdırmamasını, kaybetmemesini veya kandırılıp kaptırmamasını talep ederse ve sonraki tüm başarısızlıkları kullanıcı sorumluluğuna yüklerse, bunu sorumsuz bir tasarım olarak görüyorum. Öz saklama insanlara kontrol vermeli, aynı zamanda kullanılabilir koruma ve kurtarma yetenekleri de vermelidir. Her kullanıcının önce bir güvenlik uzmanı olmasını gerektirmemelidir. Bu aynı zamanda Crypto'nun daha fazla sıradan kullanıcıya ulaşmak için aşması gereken bir eşiktir.Son olaylar bu sorunu doğrudan gündeme getirdi. Ekim 2026'da Ledger, saldırganların orijinal cihazları değiştirip Güneydoğu Asya'daki dağıtım kanalları üzerinden yeniden piyasaya sürdüğünü ve yerleştirilen bileşenlerin başlatma sırasında kurtarma kelimelerini çaldığını doğruladı. Ledger bunu, cihaz fabrikadan çıktıktan sonra yerelleştirilmiş bir dağıtım saldırısı olarak tanımladı; çipinin, işletim sisteminin veya sunucularının ele geçirilmesi olarak değil. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) COLDCARD'ın Temmuz olayı, tohum üretimini zayıflatan ürün yazılımını içeriyordu: saldırganın ilgili özel anahtarları yeniden oluşturabilmesi için cihazın uzaktan kontrol edilmesine gerek yoktu. Ürün yazılımının güncellenmesi üretim sürecini ileriye dönük olarak düzeltir, ancak halihazırda üretilmiş zayıf tohumların yine de taşınması gerekir. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Bu iki olay aynı türden güvenlik açıkları değildir, ancak birlikte şunu gösterir: kullanıcılar kelimeleri dikkatlice kopyalayıp cihazı çevrimdışı tutsa bile, rastgeleliği ve tedarik zincirinin bütünlüğünü üretici adına doğrulayamazlar. Cihazın yedekleme kelimelerini göstermesi, çevrimdışı kurtarma amacı taşır, ancak aynı zamanda tam kurtarma sırrının korunması gereken bir ekran ve yedekleme yolundan geçmesine neden olur. Çip güvenliği, tüm cihazın ve teslimat sürecinin doğrulanmasının yerini alamaz.
İyileştirmenin hedefi tam cüzdan yaşam döngüsü olmalıdır: anahtarların nasıl üretildiği, işlemlerin nasıl açıklandığı, izinlerin nasıl ayrıldığı ve cihaz kaybolduktan sonra kurtarmanın nasıl çalıştığı. Hesap soyutlaması, yani hesapların yetkilendirmeyi programlanabilir kurallar aracılığıyla doğrulamasına izin vermek ve SLIP-39 gibi eşik yedeklemeleri, her ikisinin de standartları ve uygulama temelleri zaten var, bu nedenle sektörde kimsenin bunlar üzerinde çalışmadığı söylenemez. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Ancak bu yetenekleri test edilmiş, kullanımı kolay korumalar haline getirmemiz gerekiyor; kullanıcıların karmaşık şemaları kendi başlarına bir araya getirmelerini sağlamak yerine.
Anımsatıcı kelimelerin basit şekilde gizlenmesi yeterli değildir. Daha güvenilir yönler arasında incelenmiş şifreli yedeklemeler, eşik kurtarma ve bağımsız cihaz yetkilendirmesi ile kullanıcıların büyük miktarda varlık yatırmadan önce kurtarma tatbikatlarını tamamlamalarını sağlamak yer alır. Yedekleme parçaları ve çoklu imza farklı katmanlardır: ilki kurtarma sırasında aynı sırra yeniden birleşebilir, ikincisi ise bir işlemi onaylamak için birden fazla bağımsız imzalayıcı gerektirir. Kurtarma hizmetleri sessizce yeni bir ana anahtar haline gelmemeli ve ekstra bir parola, kaybedilmesi kurtarılamaz kayıp anlamına gelen başka bir tuzak haline gelmemelidir.Kişisel cüzdanlar ve borsa cüzdanı sistemleri; işlem açıklamaları, imzalama talepleri, varlık kısıtlamaları ve kurtarma süreçleri için güvenlik spesifikasyonlarını paylaşabilirken farklı limitler ve onay politikaları benimseyebilir. Bitcoin'in PSBT'si halihazırda imzasız işlemlerin araçlar arasında aktarılması için bir format sunmaktadır ve bu ortak arayüzü geliştirmeye devam etmek değerlidir. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Ortak olan, doğrulanabilir güvenlik gereksinimleridir; her zincirin yine de kendi uyarlama kurallarını netleştirmesi gerekir. Cüzdanlar bu imzanın neyi transfer edeceğini ve sonrasında kime ne kadar yetki verdiğini açıkça sunmalı ve bağımsız politikalar sınır dışı işlemleri reddetmelidir; daha güzel bir onay sayfası yeterli değildir.
III. Gerekli minimum açıklama ile doğrulanabilirliği sağlayın
Bir koşulun sağlandığını kanıtlamak her zaman kullanıcıların tüm temel verileri açıklamasını gerektirmemelidir. Seçmeli açıklama, sıfır bilgi kanıtları ve talep üzerine verilen denetim erişimi altyapıda normal seçenekler haline gelmelidir. Bu aynı zamanda varlık güvenliğiyle de ilgilidir: kamuya açık kimlik ve varlık ilişkileri hedefli aldatma için ipuçları sağlayabilir; işletmenin ihtiyaç duymadığı veriler mümkün olduğunca az açığa çıkarılmalıdır.
W3C'nin doğrulanabilir kimlik bilgisi sistemi halihazırda seçmeli açıklama için teknik bir yola sahiptir; ancak girdilerin gerçek olduğunu, kimlik bilgilerinin geçerliliğini koruduğunu ve durumun nasıl iptal edildiğini kanıtlamak hâlâ netleştirilmelidir. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Sıfır bilgi kanıtlarının (ZK) benimsenmesi işlem tutarlarını ve ilişkilerini otomatik olarak gizlemez; ölçekleme kanıtları ve gizlilik koruması farklı hedeflerdir.
Örneğin, bir işletme yalnızca katılım uygunluğunu doğrulamaya ihtiyaç duyduğunda, kullanıcı tam mali materyalleri açıklamadan güvenilir bir kurum tarafından verilmiş geçerli bir uygunluk sonucu sunabilir. Gizli bir değerin bir koşulu sağladığını kanıtlamak gerektiğinde, uygun bir kanıt mekanizması kullanılabilir. Kimlik bilgisinin güvenilir kaynağı ve iptal durumu yine de doğrulanmalıdır.
Benim girişimim önce "kimin neyi doğrulaması gerektiğini" netleştirmek ve ardından kamuya açıklanması gereken verileri tasarlamaktır. Uygunluğu doğrulayanlar yalnızca uygunluk sonucuna ihtiyaç duyabilir; belirli denetim sorumluluklarını taşıyanlar kısıtlı kanıtlar elde edebilir. Kamuya açık olarak doğrulanabilir kısıtlamalar, herkese kalıcı olarak açığa çıkarılan kişisel bilgileri en aza indirmelidir.
IV. İşlem hizmetlerini mümkün olduğunca merkezi saklamadan bağımsız hale getirinAlım-satım eşleştirme, yol bulma ve varlık takası ayrı ayrı tasarlanmalıdır. Alım satım giriş noktası sağlayan bir hizmet, mevcut takası mümkün olduğunca tamamlamak için yalnızca gerekli izinleri almalı; böylece kullanıcı varlıkları geri kalan süre boyunca kendi kontrolleri altında kalır. Mevcut niyet tabanlı işlem protokolleri yolun bir kısmını zaten keşfetmiştir ve sektör bunu tamamlamaya devam edebilir. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Kullanıcıların kabul ettiği şey net takas koşulları olmalıdır: ne ödendiği, en az ne alındığı, ne zaman sona erdiği ve izin verilen ücretler. Bir alım satım hizmeti ele geçirildikten sonra saldırgan hizmeti reddedebilir, ancak bu koşulları keyfi olarak değiştiremez. Hâlâ merkezi saklama gerektiren işletmeler de rezerv ve operasyonel izinleri ayırmalı, sıcak cüzdan maruziyetini ve otomatik yenileme limitlerini sınırlamalıdır.
IBIT, iShares'in bitcoin borsa yatırım ürünüdür ve piyasada işlem gören şey onun paylarıdır. Düzenlemesi kısmi izolasyona bir örnek sunar: paylar ve dayanak Bitcoin ayrı ayrı kaydedilir ve Vault Balance (saklama bakiyesi) için ilgili özel anahtarlar soğuk depolamada tutulur. Pay alım satım kaydındaki değişiklikler, dayanak Bitcoin'in her işlemle birlikte hareket etmesini gerektirmez. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Bundan çıkarılacak ders, alım satım hakları ile rezerv tasarruf haklarının ayrılmasıdır. Trading Balance (alım satım hizmeti bakiyesi) farklı bir düzenlemeye sahiptir ve saklamanın kendisi de risk taşır; soğuk depolama bağımsız talimat ve imza doğrulamasıyla eşleştirilmelidir.
Alım satım giriş noktasını bir yönlendiriciye benzetiyorum, umarım tüm kullanıcıların varlıkları üzerinde bir ana şalter taşımadan değiştirilebilir. Takas, paket yönlendirmeden daha karmaşıktır ve varlık teslimi ile yetkilendirme yine de bağımsız olarak doğrulanmalıdır. Bir hizmeti saklamasız hale getirip ardından ona sınırsız çekim hakkı vermek, yalnızca merkezi riski geri getirir.
V. Hataları izole etmek ve değiştirilebilirliği korumak için katmanlı bir mimari kullanınKimlik ve yetkilendirme arayüzlerine, varlık politikalarına ve bağımsız olarak evrilebilen mutabakat doğrulama yöntemlerine ihtiyacımız var. Farklı zincirler kendi yürütme modellerini koruyabilir ve net arayüzler aracılığıyla bağlanabilir. Arayüzler yalnızca "çağrı başarılı oldu" demekle kalmamalı, güvenlik garantilerini ve bunların koşullarını belirtmelidir.İnternet deneyimi bu yaklaşımı destekler. RFC 9518'de, "Merkezileşme, Merkeziyetsizleşme ve İnternet Standartları" başlıklı belgede Mark Nottingham, merkezileşmenin yardımcı olabileceği durumları özellikle ele almakta ve beraberinde getirdiği gücü ve riskleri de analiz etmektedir. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Bu tam da öğrenmeye değer bir tutumdur: mimarinin hangi sorumlulukların merkezileştirilebileceğine, ne ölçüde merkezileştirilebileceğine ve bu gücün genişlemesinin nasıl önleneceğine yanıt vermesine izin verin. Bir hizmetin anomalileri merkezi olarak tanımlamasına izin verilebilirken, varlıklara dokunma yetkisi sınırlı tutulabilir; kullanıcılar kendi varlık politikalarını ve doğrulama kayıtlarını kaybetmeden hizmetler arasında geçiş yapabilmelidir.
En önemli kabul sorusu şudur: bir iş hizmeti ele geçirildikten sonra, hangi bağımsız katman onu hâlâ reddedebilir? Eğer tüm katmanlar tek bir yönetim anahtarını paylaşıyorsa, sözde katmanlama yalnızca bir dağıtım şeması üzerindeki katmanlamadır.
Bu hedef, beş sorumluluk katmanı olarak görülebilir: işlem hizmeti talepleri iletir, cüzdan kullanıcı niyetini ifade eder, bağımsız politika varlık tasarrufu üzerindeki yetkiyi sınırlar, doğrulama bileşeni işlemleri ve kanıtları denetler ve mutabakat katmanı kısıtlamaları uygular ve doğrulanabilir kayıtlar sağlar. Bunlar farklı ekipler tarafından uygulanabilir ve bağımlılıkları ile arıza koşulları da ayrı ayrı tanımlanmalıdır.
Bu makalede savunulan hedef mimari. Mutabakat katmanı varlık politikasını uygulamalıdır; cüzdandaki istemler bu kısıtlamanın yerini alamaz. Günlük imzalama, kural değişiklikleri ve kurtarma yetkisi izole edilmeli ve atlatma testlerine tabi tutulmalıdır.
6. Kullanıcıların kendi varlıklarını hafifçe doğrulamasına izin verin
Sıradan insanlar kendi bakiyelerini ve makbuzlarını doğrulamak için tüm zincirin tüm geçmişini saklamak ve yürütmek zorunda kalmamalı; cüzdanın arkasındaki tek bir sunucuya da güvenmek zorunda kalmamalıdır. Satoshi Nakamoto, beyaz kitabın 8. bölümünde SPV'yi, basitleştirilmiş ödeme doğrulamasını zaten önermişti. Bitcoin'in BIP-157'si, istemcilerin filtreleri indirmesine ve kendileriyle ilgili blokları bulmasına izin vermeyi araştırmaya devam etmektedir; Ethereum'da da hafif istemci tasarımları vardır. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Yani sorun, kimsenin bunu hiç düşünmemiş olması değil, net güvenlik koşullarına sahip doğrulama yeteneğini kullanıcıların her gün kullandığı cüzdanlara hâlâ yerleştirmemiz gerektiğidir.Hesap durumu kanıtlarını destekleyen bir zinciri örnek alalım: bir bakiye sorgulanırken sunucu hem bakiyeyi hem de bir kanıtı döndürmelidir. Cüzdan önce o zincirin kurallarına göre kısa bir blok özetini, yani blok başlığını doğrular, ardından bu bakiyenin özetin taahhüt ettiği verilerle tutarlı olup olmadığını kontrol eder. Sunucu yanıtı sağlar ve cüzdan yanıtı doğrulayabilir. Bitcoin'in SPV'si ilgili işlemlerin dahil edildiğine dair kanıtı doğrular; doğrudan bakiye kanıtı olarak kopyalanamaz. Cüzdan ayrıca nereye kadar senkronize olduğunu ve hangi bilgilerin doğrulandığını açıkça göstermelidir; kanıtlar eksik olduğunda, veriler bayatladığında veya kaynaklar çeliştiğinde uyarı vermeli ya da bu bilgilere dayanan yüksek riskli işlemleri durdurmalı ve sessizce kör güvene geri dönmemelidir.
Hafif doğrulamanın hâlâ koşulları vardır. Bir işlemin bir bloğa dahil edildiğini kanıtlamak, bloktaki tüm işlemlerin geçerli olduğunu kendi başına kontrol etmekle aynı şey değildir. Farklı şemalar hash gücünün çoğunluğunun dürüst olmasına veya güvenilir bir başlangıç kaydına, yani bir kontrol noktasına dayanabilir; ayrıca sunucuların veri saklamasına veya kullanıcıları bayat bir zincir kaydında izole etmesine karşı da korunmalıdır. Sorgunun kendisinin kullanıcının önemsediği adresleri açığa çıkarıp çıkarmadığı da ele alınmalıdır. Tam düğümler ve blok üreticileri aynı rol değildir; Ethereum bugün blok üretimi için madenciler yerine doğrulayıcıları kullanır.
Daha da önemlisi, "bu transferin gerçekten zincir üzerinde gerçekleştiğini" kanıtlamak, "bunun tam olarak kullanıcının istediği transfer olduğunu" kanıtlayamaz. Hafif istemciler önceki varlık limitlerinin ve imza kontrollerinin yerini alamaz. Kullanıcıların doğrulanamayan bir yanıta daha az güvenmesini sağlarlar; varlık politikası ise geçerli bir imzanın bile varlıkları sınırsız şekilde tasfiye edememesini sağlar. Doğrulama yeteneğinin katılımcılar arasında dağıtılabilmesi ancak her iki katmanın birlikte inşa edilmesiyle mümkündür.
7. Anomali tespitini ve güvenlik doğrulamasını kamu altyapısı olarak inşa edin
Bir işlemden önce birileri, işlemin varlık politikasına uyup uymadığını ve geçmiş davranışı aniden değiştirip değiştirmediğini kontrol etmelidir. Belirgin anomaliler bir duraklatmayı veya yükseltilmiş incelemeyi tetikleyebilir; izinlerin genişletilmesi başka bir bağımsız yol gerektirir. YZ yargıya katılabilir, ancak katı kuralları geçersiz kılan bir serbest geçiş almamalıdır.
Aynı zamanda, tekrar tekrar çalıştırılabilen saldırı vakalarını, izin testlerini ve doğrulama araçlarını birlikte sürdürmemiz gerekir. Yalnızca spesifikasyonları paylaşarak ve bağımsız uygulamaları ve bağımsız doğrulamayı koruyarak ortak mod arızaları azaltılabilir. Vakıflar ve borsalar hâlihazırda güvenlik yatırımlarına sahiptir; örneğin Ethereum Vakfı'nın Trillion Dollar Security Initiative'i. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) Sorulması gereken bir sonraki soru, yatırımın diğer ekiplerin de benimseyebileceği ve denetleyebileceği kamu altyapısına dönüştürülüp dönüştürülemeyeceğidir.Bu yedi iş kaleminin hiçbiri mutlak güvenliği garanti edemez. Sunmaları gereken şey denetlenebilir sınırlardır: hangi izin ihlali koşullarında en fazla ne kadar varlık riske girer, anormallikler ne kadar hızlı tespit edilebilir ve kurtarma hâlâ kime bağlıdır.
Bu noktada bazıları şöyle diyebilir: yön doğru görünüyor, ancak sektör bunca yıldır devam ediyor; yeniden inşa kaç kişi ve ne kadar zaman gerektirir? Bu hâlâ idealizm değil mi?
Geçmiş yazılım üretim biçimine göre tahmin edilirse, bu şüphe çok gerçekçidir. Ancak 2026'ya gelindiğinde, kodlama ajanlarının ve yapay zekâ destekli yazılım mühendisliğinin, harekete geçirebileceğimiz inşa kapasitesini çoktan değiştirdiğine inanıyorum. Burada bahsedilen kodlama ajanları, bir geliştirme ortamında kod okuyup yazabilen, araçları çağırabilen, testleri çalıştırabilen ve geri bildirime dayanarak çalışmaya devam edebilen yapay zekâ programlama asistanlarıdır. İnşa edenler hedefler koyar, güvenlik sınırlarını tanımlar, bu araçları sistemleri uygulamak ve kontrol etmek için kullanır ve sonuçların sorumluluğunu üstlenir.
Daha önce büyük ekiplerin tekrar tekrar uygulamasını, uyarlamasını ve bakımını gerektiren işler, artık bu yeni mühendislik yaklaşımıyla küçük ekipler tarafından denenebilir. Bir ekip bir katmanı üstlenir, net arayüzler etrafında bileşenler teslim eder, ardından diğer ekipler bunları denetler ve birleştirir. İnsan mimari muhakemesini, kodlama ajanlarının uygulama kapasitesini ve bağımsız güvenlik doğrulamasını organize etmek, bence ciddi şekilde yeniden değerlendirilmeye değer inşa yoludur.
Anthropic ve PNNL'nin araştırması somut bir örnek sunuyor: sınırlı bir kritik altyapı simülasyon ortamında, araştırmacılar saldırı yeniden yapılandırmasının muhtemelen birkaç haftadan yaklaşık üç saate kısaltıldığını bildirdi. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Bu, küçük bir ekibin tüm sektörü zaten güvenli şekilde yeniden yazabileceğini kanıtlamaz, ancak daha önce pahalı olan doğrulama ve saldırı-savunma işlerinin yeni maliyet koşullarına sahip olabileceğini gösterir.
Şimdi başlatılabilecek bir organizasyonel yaklaşım, ortaklaşa bir Build in Public AI Factory inşa etmektir. Sektör uzmanları, akademisyenler ve uygulayıcılar gereksinimleri ve kabul şartnamelerini (spec) açıkça yazar; neyin korunacağını, hangi işlemlere izin verildiğini ve hangi izinler ihlal edildikten sonra hangi sınırların hâlâ geçerli olması gerektiğini açıklar ve ardından bu gereksinimleri kabul testlerine dönüştürür. Kodlama ajanları grupları ana kodlama, test etme ve hata ayıklama işlerini üstlenir; farklı ekipler tasarımları ve sonuçları denetler ve insanlar muhakeme ve kabul sorumluluğunu taşır.Katılımcılar fikirler, makineler, hesaplama gücü ve model çağrı kotaları, yani AI token'ları ile katkıda bulunabilir. AI ve bulut bilişim şirketleri de model kotaları, hesaplama kaynakları ve araçlarla bu kamusal inşayı destekleyebilir. Spesifikasyonlar, prototip kodu, ajan iş akışları, test ortamları ve doğrulama sonuçlarının tümü ortaklaşa sürdürülen altyapı haline gelebilir ve bir sonraki ekibin doğrudan oradan devam etmesini sağlayabilir. Amaç, geliştirme kapasitesini yeniden kullanılabilir kamusal tesislere dönüştürmek ve herhangi bir kişinin zamanına veya herhangi bir ekibin zamanına bağımlılığı azaltmaktır.
Saldırganlar da AI kullanıyor ve artık savunmayı geçmişin üretim yöntemlerine bırakmak için hiçbir nedenimiz yok. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Ancak kod üretiminin hızlı olması yalnızca başlangıç noktasıdır. Kısıtlamaları açıkça yazmak, testleri tekrar tekrar çalıştırılabilir kılmak ve bir bileşeni denetlenebilir ve değiştirilebilir hale getirmekle AI yeteneği ancak altyapı iyileştirmesine dönüştürülebilir.
Bağımsız geliştiriciler kodlama ajanları ve AI araçları yardımıyla birlikte çalışır. Uzay atölyesi kamusal inşa için bir metafor.Özellikle hâlâ inşa etmeyi sevenlere bu çağrıyı yöneltmek istiyorum. Buradaki "hacker", bir sistemin nasıl çalıştığını anlamaya istekli, bulduklarını paylaşmaya istekli ve başkalarının kendi işini test etmesine izin vermeye istekli kişiyi ifade eder. Bu ruh bir zamanlar İnternet'i ileri taşıdı ve bugün Crypto'yu da ileri taşıyabilir.
Bu sektörün akıllı insanlardan yoksun olduğuna inanmıyorum ve Crypto ile AI sektörlerinin bu işi destekleyecek kaynakları bulamayacağına da inanmıyorum. Daha zor olan, yetenek, finansman ve sürekli sorumluluğu bir arada organize etmektir. Vakıflar ve yetenekli şirketler, doğrudan gelir üretmeyen ancak herkese fayda sağlayan temel işlerin uzun vadeli maliyetini üstlenmeye istekli olmalıdır.
Herkesin küresel olarak paylaşılan bir kriptografik altyapı inşa etmek için birlikte çalışmasını umuyorum. Farklı ağlar ve ekipler ortak güvenlik kısıtlamaları altında işbirliği yapabilir, her biri kendi çözümlerini uygulayabilir ve birbirlerininkini test edebilir, kullanıcılar seçebilir ve geçiş yapabilir. Tek bir bileşenle başlayabilir, ancak yön tüm sektörün birlikte inşa etmesini barındıracak kadar büyük olmalıdır. ArcBlock dahil tüm katılımcılar doğrulanabilir işlerle katkıda bulunmalıdır.
Birlikte öyle bir altyapı inşa etmeliyiz ki, bir parçası tehlikeye girmiş olsa bile varlıkların hâlâ sınırları olsun, diğer sistemler hâlâ hataları reddedebilsin ve kullanıcıların hâlâ kurtarma ve çıkış yolları olsun. Adını Star Wars'tan ödünç alarak, bu bizim A New Hope'umuz. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) Umut, harekete geçmeye istekli sıradan inşaatçılardan ve aynı zamanda kodlama ajanlarının ve yeni mühendislik yöntemlerinin onların daha fazla inşa işi üstlenmesini mümkün kıldığı bu andan gelir.Ethereum, Solana, Bitcoin ve XRP Ledger gibi projelerin geliştiricilerine, Binance, Coinbase ve Kraken gibi borsalara, ayrıca cüzdan, protokol, güvenlik araştırması, yapay zeka ve bulut bilişim ekiplerine bir davet göndermek istiyorum: net kapsamlı bir pilot ile başlayın ve diğer ekiplerin benimseyip test edebileceği iyileştirmeleri birlikte üretin.
Listelenen isimler yalnızca örnektir, belirli bir sıra yoktur. Büyüklüğünüz veya seçtiğiniz teknik yol ne olursa olsun, katılımınız memnuniyetle karşılanır. Bu davet, bu makalede eleştirilen teknik yolların geliştiricilerini de kapsamaktadır; varlık güvenliğini birlikte iyileştirmek, kendi ekosistemlerimizin sınırlarını aşmaya değer.
Ben şahsen katılmaya ve mevcut altyapımızı, yazılım mühendisliği ve yapay zeka iş birliği uygulamalarımızı katkıda bulunmaya istekliyim. Sektörde yalnızca küçük bir ekibiz ve yapabileceklerimiz sınırlıdır. Bir prototip ve bir dizi tekrarlanabilir test ile başlamayı umuyorum.
Pratik operasyonel deneyime sahip kişiler anonimleştirilmiş saldırı senaryoları sağlayabilir, cüzdan ve protokol ekipleri korumaları uygulayabilir, bağımsız araştırmacılar bunları atlatmayı deneyebilir. Her ekip üstesinden gelebileceği kısmı üstlenir, çözümü birlikte test eder ve bir sonraki adıma karar verir.
Bu makaledeki varlık sınırlama ve kurtarma gereksinimlerini ilk kamuya açık spesifikasyon haline getirme sürecini organize etmeye katılmaya ve bu pilot için diğer katılımcılarla birlikte kamuya açık bir AI Factory oluşturmak üzere ilgili teknik ve mühendislik uygulamalarını katkıda bulunmaya istekliyim. Önce çok spesifik bir problem seçin: günlük işlem anahtarı ele geçirildiğinde, saldırganın cüzdanı tek seferde boşaltması nasıl hâlâ engellenebilir? İzin verilen kayıp aralığını, kuralları değiştirme yetkisini ve kurtarma koşullarını kabul testlerine yazın, ardından geliştirme ajanlarına bir prototip uygulatın ve başka bir ajan grubu ile bağımsız araştırmacılara atlatma yolları aramalarını sağlayın. Yanlış bakiye döndüren veri sunucuları ve cihaz kaybından sonra kurtarma da kademeli olarak testlere eklenebilir. Prototipin neyi başardığı, nerede başarısız olduğu ve hangi bağımlılıkların kaldığı kamuya açık şekilde açıklanmalı ve bir sonraki adıma kanıtlara dayanarak karar verilmelidir.
Katılmak isteyenler, bu girişimi X'te kamuya açık şekilde yeniden paylaşmaya veya alıntılamaya ve @mave99a'yı etiketlemeye, çözmek istediğiniz problemi, anonimleştirilmiş saldırı vakalarını veya katkıda bulunabileceğiniz kaynakları anlatmaya davetlidir. Tartışmanın kamuya açık şekilde ilerlemesini, böylece daha fazla geliştiricinin bunu görebilmesini ve katılabilmesini umuyorum.
Kripto böyle devam edemez. Birlikte çalışmaya istekli olanlar, hadi şimdi harekete geçelim, inşa edilebilen ve testlere dayanabilen bir iyileştirme ile başlayalım.Binance, ilk duyuru resmi gönderisi ve takip soruşturması resmi güncellemesi, 2026-10-30; TRM çok zincirli analiz. Bu taslak 2026-10-30 itibarıyla doğrulanmıştır; soruşturma ve kurtarma durumu değişebilir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: Eşten Eşe Elektronik Nakit Sistemi, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Eşdeğerliği. Paylaşılan bağımlılıkların risk yoğunlaşması bu makalede yazarın değerlendirmesidir, söz konusu belgenin bir sonucu değildir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: EOA'lar için Kod Ayarlama, oluşturulma 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Oltalama Saldırısı, 2025-12-13, arXiv v1 ön baskı; bu Binance olayının tanımlanması değildir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maksimum çıkarılabilir değer (MEV), sıralama mekanizmaları, farklı türleri ve olumsuz etkileri; "bir hata olarak düzeltilmelidir" ifadesi yazarın kullanıcılara zarar veren davranışlara ilişkin mühendislik tutumudur. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
PHP resmi 2026 haber arşivi; CISA 2026-10-26 Bilinen İstismar Edilen Güvenlik Açıkları güncellemesi, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards ve Modules, işlevsellik ve izin risklerinin açıklaması. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple, kullanılmış orijinal parçalara destek ile onarım seçeneklerini genişletecek, 2024-04-11; güncel parça eşleştirme destek açıklaması. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger'ın Donanım İmplant Saldırısına Yanıtı, 2026-10, dağıtım zincirindeki bir saldırıya ilişkin satıcı açıklaması; Joe Grand, donanım implantları üzerine tersine mühendislik araştırması. Doğrulanmamış ağ kaybı tahminlerini kesin sonuçlar olarak sunmayın. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Güncel COLDCARD Güvenlik Durumu, erişim 2026-10-30, Temmuz 2026 olayı ve iyileştirmeye ilişkin sürekli güncellenen kayıt; yükseltme ve seed taşıma iki ayrı işlemdir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Alt Mempool Kullanarak Hesap Soyutlama; Trezor, SLIP39 SSS, eşik kurtarma, uyumluluk ve ek parola riskleri. Mevcut mekanizmalar inşa için bir temeldir ve her dağıtımın güvenilir olduğu anlamına gelmez. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Kısmen İmzalanmış Bitcoin İşlem Formatı, imzalanmamış işlemler için bir değişim formatıdır, zincirler arası genel bir varlık stratejisi spesifikasyonu değildir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Doğrulanabilir Kimlik Bilgileri Genel Bakış v1.0, 2026-07-30 Grup Notu; Ethereum gizlilik notları. Genel bakışta açıklanan teknolojilerin standart durumu her durumda bağımsızdır. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
CoW Protocol dokümantasyonu, işlem niyetleri ve çözücü mekanizmaları; bu makale herhangi bir spesifik dağıtım için kapsamlı bir güvenlik onayı sunmamaktadır. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Yıllık Raporu, PDF sayfa 8–10 saklama düzenlemeleri ve sayfa 45 risk açıklamaları. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Merkezileşme, Merkeziyetsizleşme ve İnternet Standartları, 2023-12, bağımsız olarak sunulmuş, bilgilendirici RFC, standart izleme spesifikasyonu değildir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin beyaz kitabı Bölüm 8 Basitleştirilmiş Ödeme Doğrulaması; BIP-157: İstemci Tarafı Blok Filtreleme; Ethereum, Hafif istemciler. Farklı hafif istemciler farklı doğrulama kapsamlarına ve güven koşullarına sahiptir. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Trilyon Dolarlık Güvenlik Girişimi'nin Duyurusu, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, Kritik altyapıyı savunmak için yapay zeka, 2026-01-08, PNNL ile işbirliği içinde sınırlı ortam araştırması. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Yapay zeka destekli siber tehditlerin haritalanması, gerçek kötüye kullanım örnekleri üzerine araştırma. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Bölüm IV), 1977; bu makale başlığı ve ortak kendi kendini kurtarma imgesini ödünç almaktadır. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)