Bazı Blok Zincirleri Neden İmzaladığınız İşlemleri Gizler?

Bir donanım cüzdanında kripto işlemini onayladığınızda iki şeyden birini yapıyorsunuz: Ya tam olarak ne olacağını açıkça gösteren bir özet okuyorsunuz, ya da ham onaltılık kod yığınını imzalayarak güveniyorsunuz. Kör imzalama, bir dijital işlemin tüm ayrıntılarını insan tarafından okunabilir bir formatta doğrulayamadığınız halde onaylama eylemidir.
 

  2025 Şubat'ında, kör imzalama  $1.5 milyar Bybit hackine katkıda bulundu; bu, tarihteki en büyük kripto hırsızlığıydı. Saldırganlar hiçbir kriptografiyi kırmadı. İnsan imzalayıcıların sıradan bir transfer ile kötü niyetli bir sözleşme yükseltmesini ayırt edememesinden faydalandılar.
 

Cüzdanınız size imzalamadan önce açık ve okunabilir bir özet gösterebiliyor mu, bu bir yazılım kalitesi meselesi değildir. Bu, her blok zincirinin protokol düzeyinde nasıl tasarlandığıyla ilgilidir. Bazı zincirler, işlemlerin kendilerini tanımlayacak şekilde inşa edilmiştir. Diğerleri ise kritik ayrıntıları, dışarıdan bilgi gerektiren ikili veri bloklarının içine gizler. Bu makalede, bu tasarım kararlarının büyük blok zincirlerinde nasıl ayrıştığı ve güvenliğiniz açısından ne anlama geldiği açıklanmaktadır.

Üç Kademe Çerçevesi

Açık İmzalama, bir dijital işlemin tüm ayrıntılarını güvenli bir ekranda, insan tarafından okunabilir biçimde onaylamadan önce doğrulamanızı sağlayan bir güvenlik sürecidir. 

13 büyük blok zinciri ekosisteminde, açık imzalama desteği protokol mimarisine göre üç farklı kademeye ayrılır. Bu, hangi zincirlerin iyi ya da kötü olduğu ile ilgili değil; yıllar önce, güvenlik sonuçları tam anlaşılmadan yapılan tasarım tercihleriyle ilgilidir.

Kademe 1: Şeffaflık İçin Tasarlandı

Bu blok zincirleri, imzalamanın tasarımlarının doğal bir sonucu olduğunu açıkça ortaya koyar. Temel neden: Her alanın adı, türü ve tanımlı şeması olan sonlu sayıda tiplenmiş işlem yapısı kullanırlar. Bir donanım cüzdanı, onları ayrıştırmak için harici bir bilgiye ihtiyaç duymaz; işlemin kendisi ne olduğunu söyler.

The XRP Ledger belki de herhangi bir büyük zincir arasında en güçlü ve en açık imzalama örneğini sunar. İkili formatında, 50'den fazla işlem türünü belirleyen TransactionType alanı bulunur: Payment, OfferCreate, TrustSet, EscrowCreate ve daha fazlası. Her alanın tanımlı bir şeması vardır. Bir donanım cüzdanı, alıcıyı, tutarı, ücreti, notu ve işlem türüne özel tüm parametreleri harici bir bilgiye ihtiyaç duymadan gösterebilir. Mevcut ana ağ işlemlerinin neredeyse %100'ü tamamen açık şekilde imzalanabilir.

Polkadot sektördeki en teknik olarak gelişmiş açık imzalama çözümünü  çalışma zamanı metadata sistemi (MetadataV14/V15) ile geliştirdi. Her işlem, palet ve çağrı indekslerine referans verir ve metadata bu indekslerin ne anlama geldiğini ve argümanların nasıl çözüleceğini tam olarak belirtir. Zorluk, tam metadatanın 200 KB'yi aşmasıdır; bu, sınırlı belleğe sahip donanım cüzdanları için fazladır. 

Çözüm ise  RFC-0078 (Merkleized Metadata) ile geldi; metadata'dan kriptografik bir ağaç oluşturulur, yalnızca ilgili alt küme iletilir ve dahil olma kanıtı zincir üzerinde doğrulanır. Sonuç olarak, tüm Polkadot parachain'lerinde zincir başına güncelleme gerektirmeyen tek bir Ledger uygulaması çalışır.
 

Cosmos, tiplenmiş mesaj mimarisi ve  SIGN_MODE_TEXTUAL standardı (ADR-050) ile, işlemleri küçük ekranlara uygun insan tarafından okunabilir ekranlar olarak sunar. Coin miktarları "2 ATOM" gibi gösterilir, "2000000uatom" gibi değil. NEAR Protocol ise  insan tarafından okunabilir hesap adları (örn. "alice.near") ve cüzdanın düz metin olarak gösterebileceği JSON-serileştirilmiş fonksiyon argümanları ile okunabilirliği daha da ileri taşır.
 

Kademe 2: Temel İşlemler İçin Uygun, Karmaşıkta Zayıf

Altı ekosistem, yerel işlemler için güçlü açık imzalama sunar; ancak akıllı sözleşmeler devreye girdiğinde ciddi şekilde zayıflar. Bitcoin bu konuda öğretici bir örnektir. UTXO modeli, ham işlemlerde giriş miktarlarının bulunmaması anlamına gelir; bir donanım cüzdanı, önceki çıktılara dair ek bilgi olmadan ücretinizi hesaplayamaz.  PSBT (BIP 174) bu sorunu standart ödemeler için çözer ve tipik işlemlerin yaklaşık %90'ını kapsar; ancak Taproot script-path harcamaları ve karmaşık çoklu imza kurulumları hala opaklık yaratır.
 

Stellar, ikinci kademe ayrımını en net şekilde gösterir. 26 klasik işlem türü (Payment, ManageSellOffer, ChangeTrust) sabit şemalara sahiptir ve donanım cüzdanlarında net şekilde görüntülenir. Ancak 2024'te başlatılan Soroban akıllı sözleşmeleri, EVM benzeri opaklığı yeniden getirir; parametreler, yalnızca sözleşmeye özel bilgiyle çözülebilen kodlanmış ikili tipler olarak gelir ve klasik işlemler için yaklaşık %95 olan kapsama oranı, ham Soroban etkileşimlerinde neredeyse sıfıra düşer. Algorand, Cardano, Aptos ve Tezos da benzer bir yol izler: Güçlü yerel işlem desteği, karmaşık programlanabilir mantıkta önemli boşluklar.
 

Kademe 3: Opaklık Temelde Var

Üç ekosistem, açık imzalamayı cüzdan yazılımı ne kadar iyi olursa olsun zorlu hale getiren mimari tercihlere sahiptir. Bunun nedenini anlamak, neredeyse tüm büyük DeFi arayüzlerinde kör imzalama uyarılarının neden bulunduğunu açıklar.
 

Ethereum ve tüm EVM-uyumlu zincirler temel bir sorun paylaşır: ABI kodlaması kendini tanımlamaz. Bir akıllı sözleşmeyle etkileşime girdiğinizde, işlem veri alanı, fonksiyon adının ilk dört baytının hash'inden oluşan 4 baytlık bir fonksiyon seçici ve ardından 32 baytlık parçalara kodlanmış parametreler içerir. Sözleşmenin ABI JSON'u olmadan, bu tamamen onaltılık bir gürültüdür. Bu ABI zincir üzerinde saklanmaz. Bir donanım cüzdanı, 0xa9059cbb...'nin "1.000 USDC'yi 0xABC...'ye gönder" anlamına geldiğini harici metadata olmadan bilemez. 
Proxy sözleşmeleri, yürütmeyi adresi değişebilen uygulama sözleşmelerine yönlendirerek sorunu daha da karmaşıklaştırır; Bybit hack'i tam da bu şekilde gerçekleştirildi.
 

Sektörün buna yanıtı  ERC-7730 oldu; 2024'te oluşturulan bu metadata standardı, belirli sözleşme etkileşimlerinin nasıl çözüleceğini ve görüntüleneceğini tanımlayan JSON dosyaları sağlar. Çalışır, ancak her etkileşimde bulunabileceğiniz sözleşme için birinin bu metadata dosyasını yazıp güncel tutması gerekir. Temelde, şeffaflık için tasarlanmamış bir mimariye uygulanan bir yamadır.
 

Solana ise belki de daha zorludur. İşlem talimatları, bir program kimliği ve standartlaşmamış bir ABI ile tanımsız bir bayt dizisi içerir; her program kendi serileştirme formatını belirler. Anchor framework'ü 8 baytlık ayırt edicilerle yarı-standart bir yaklaşım sunar; ancak birçok program Anchor kullanmaz ve arayüz tanımlarını halka açık şekilde yayınlamaz. DeFi işlemlerinde, Solana'nın işlem hacminin çoğu kör imzalama gerektirir. 

TON, asenkron yürütme ile daha da karmaşık hale gelir: Sadece ilk mesajı imzalarsınız ve sonraki bloklarda gerçekleşen her şey imzalama anında görünmezdir.

 Çıkarımlar

En pratik çıkarım: DeFi için bir donanım cüzdanı kullanmadan önce zincirinizin hangi kademede olduğunu bilin. Kademe 1 zincirlerinde açık imzalama beklendiği gibi çalışır. Kademe 2'de, basit transferleri güvenle imzalayabilirsiniz; ancak karmaşık akıllı sözleşme işlemlerinde mutlaka araştırma yapmalısınız. Kademe 3'te ise, bir DeFi protokolünde yapılan her işlemi ekstra şüpheyle değerlendirin ve onaylamadan önce dApp ve cüzdan kombinasyonunun ERC-7730 metadata desteği olup olmadığını kontrol edin.
 

Donanım cüzdanı üreticileri bu konuda aktif olarak çalışıyor. Ledger'ın Generic Parser'ı ERC-7730 metadata dosyalarını okuyup işlem ayrıntılarını güvenli ekranda gösteriyor. 

Polkadot'un Merkleized Metadata yaklaşımı ise sektördeki en zarif çözüm olarak öne çıkıyor: güvene dayalı olmayan, kriptografik olarak doğrulanabilir ve protokol-yerel. Sektör daha iyi standartlara doğru ilerliyor; ancak Kademe 3 zincirlerinin temel protokol kısıtları ortadan kalkmayacak.
 

En basit kural: Cüzdanınız size bir hash veya bir dizi hex bayt gösterip imzalamanızı istiyorsa, bunu bir uyarı işareti olarak değerlendirin.

Kaynaklar ve Daha Fazlası

Bu kaynaklar, makalede ele alınan protokol ve standartlarla ilgili teknik derinlik sunar.