Bazı Blokzincirler Neden İmzaladığınız İşlemleri Gizler?
Ethereum ve Solana gibi zincirler neden sizi boş bir çeki imzalamaya zorluyor ve sektör bunu nasıl çözmeye çalışıyor?
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 anlatan bir özet okuyorsunuz, ya da ham onaltılık kodun bir duvarını imzalayıp en iyisini umuyorsunuz. Kör imzalama, dijital bir işlemin tüm ayrıntılarını insan tarafından okunabilir bir formatta doğrulayamadan onaylama eylemidir.
In February 2025, blind signing contributed to the $1.5 billion Bybit hack , the largest crypto theft in history. The attackers didn't break any cryptography. They exploited the fact that human signers couldn't distinguish a routine transfer from a malicious contract upgrade. Whether your wallet can show you a clear, readable summary before you sign isn't a question of software quality. It comes down to how each blockchain was designed at the protocol level. Some chains were built so that transactions describe themselves. Others hide critical details inside binary blobs that require external information to decode. This article explains how those design decisions break down across the major blockchains and what it means for your security. The Three-Tier Framework Clear Signing is a security process that lets you verify the full details of a digital transaction in a human-readable format on a secure screen before approving it. Across 13 major blockchain ecosystems, clear signing support falls into three distinct tiers based on protocol architecture. This isn't about which chains are good or bad, it's about design tradeoffs made years ago, often before the security implications were fully understood. Tier 1: Built for Transparency These blockchains make clear that signing is a natural outcome of their design. The core reason: they use a finite set of typed transaction structures where every field has a name, a type, and a defined schema. A hardware wallet doesn't need any external information to parse them, the transaction tells you what it is. The
Üç Kademe Çerçevesi
Açık İmzalama, dijital bir işlemin tüm ayrıntılarını güvenli bir ekranda insan tarafından okunabilir şekilde onaylamadan önce doğrulamanızı sağlayan bir güvenlik sürecidir.
13 büyük blokzincir ekosisteminde açık imzalama desteği, protokol mimarisine göre üç farklı kademeye ayrılır. Burada hangi zincirin iyi veya kötü olduğundan değil, yıllar önce yapılan ve çoğu zaman güvenlik sonuçları tam anlaşılmadan verilen tasarım tercihlerinden söz ediyoruz.
Kademe 1: Şeffaflık İçin Tasarlandı
Bu blokzincirler, imzalamanın tasarımlarının doğal bir sonucu olduğunu açıkça gösterir. Temel sebep: Her alanın adı, türü ve tanımlı bir şeması olan sonlu sayıda tiplenmiş işlem yapısı kullanırlar. Bir donanım cüzdanı, işlemleri ayrıştırmak için harici bilgiye ihtiyaç duymaz; işlem kendi ne olduğunu söyler.
The XRP Ledger , büyük zincirler arasında en güçlü ve net imzalama hikayesine sahip olabilir. İkili formatında, 50'den fazla işlem türünü belirleyen bir TransactionType alanı bulunur: Payment, OfferCreate, TrustSet, EscrowCreate ve daha fazlası. Her alanın tanımlı bir şeması vardır. Donanım cüzdanı, alıcıyı, miktarı, ü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 tamamı tamamen açık 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 size bu indekslerin ne anlama geldiğini ve argümanların nasıl çözüleceğini tam olarak söyler. Zorluk, tam metadatanın 200KB'yi aşması ve sınırlı belleğe sahip donanım cüzdanları için fazla büyük olmasıdır.
Çözüm ise RFC-0078 (Merkleized Metadata): Metadata'dan kriptografik bir ağaç oluşturur, sadece ilgili alt küme iletir ve dahil edilme kanıtını zincir üzerinde doğrular. Sonuç olarak, tüm Polkadot parachain'lerinde ayrı zincir güncellemeleri olmadan çalışan tek bir Ledger uygulaması elde edilir.
Cosmos, tiplenmiş mesaj mimarisi ve SIGN_MODE_TEXTUAL standardı (ADR-050) ile çalışır; bu, işlemleri küçük ekranlar için insan tarafından okunabilir şekilde sunar. Coin miktarları "2 ATOM" şeklinde gösterilir, "2000000uatom" değil. NEAR Protocol ise insan tarafından okunabilir hesap adları (ör. "alice.near") ve cüzdanın düz metin olarak gösterebileceği JSON-serialize edilmiş fonksiyon argümanlarıyla 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ı kontratlar devreye girdiğinde şeffaflık önemli ölçüde azalır. Bitcoin bunun en iyi örneğidir. UTXO modeli, ham işlemlerin giriş miktarlarını içermediği anlamına gelir; donanım cüzdanı, önceki çıktılar hakkında ek bilgi olmadan ücreti 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ı hâlâ opaklık yaratır.
Stellar, ikinci kademedeki ayrımı en net gösterir. 26 klasik işlem tipi (Payment, ManageSellOffer, ChangeTrust) sabit şemalara sahiptir ve donanım cüzdanlarında güzelce görüntülenir. Ancak 2024'te başlatılan Soroban akıllı kontratları, EVM tarzı opaklığı yeniden getirir; parametreler, yalnızca kontrata özel bilgiyle çözülebilen kodlanmış ikili türler olarak gelir ve klasik işlemlerde yaklaşık %95 olan şeffaflık, ham Soroban etkileşimlerinde neredeyse sıfıra iner. Algorand, Cardano, Aptos ve Tezos da benzer bir yol izler: güçlü yerel işlem kapsamı, 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 zorlaştıran mimari tercihlere sahiptir. Nedenini anlamak, kör imzalama uyarılarının neredeyse tüm büyük DeFi arayüzlerinde neden yer aldığını açıklamaya yardımcı olur.
Ethereum ve tüm EVM-uyumlu zincirler temel sorunu paylaşır: ABI kodlaması kendini tanımlamaz. Bir akıllı kontrat ile etkileşime geçtiğinizde, işlem veri alanı fonksiyon adının ilk dört baytının hash'i olan 4 baytlık bir fonksiyon seçicisi ve ardından 32 baytlık bloklarda kodlanmış parametreler içerir. Kontratın ABI JSON'u olmadan bu, yalnızca onaltılık bir gürültüdür. Bu ABI zincir üzerinde tutulmaz. Donanım cüzdanı, 0xa9059cbb...'nin "1.000 USDC'yi 0xABC...'ye gönder" anlamına geldiğini harici metadata olmadan bilemez.
Proxy kontratlar, yürütmeyi adresleri değişebilen uygulama kontratlarına yönlendirir ve sorunu daha da karmaşıklaştırır; Bybit saldırısı tam olarak böyle gerçekleştirildi.
Sektörün buna yanıtı ERC-7730 oldu; bu, belirli kontrat etkileşimlerinin nasıl çözüleceğini ve görüntüleneceğini açıklayan JSON dosyaları sağlayan bir metadata standardıdır. Çalışır, ancak her etkileşime girebileceğiniz kontrat için birinin bu metadata'yı yazması ve güncel tutması gerekir. Temelde, şeffaflık için tasarlanmamış bir mimariye uygulanan bir yamadır.
Solana ise belki de daha zorludur. İşlem talimatları, standart bir ABI olmadan program kimliği ve opak bir bayt dizisi içerir; her program kendi serileştirme formatını tanımlar. Anchor framework, 8 baytlık ayıraçlar kullanan yarı-standart bir yaklaşım sunar; ancak birçok program Anchor kullanmaz ve arayüz tanımlarını herkese açık yayınlamaz. DeFi etkileşimlerinde, Solana işlem hacminin çoğu kör imzalama gerektirir.
TON ise asenkron yürütme ile ek karmaşıklık katar: 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ı kontrat etkileşimlerinde mutlaka araştırma yapmalısınız. Kademe 3'te ise, bir DeFi protokolünde her işlemi ekstra şüpheyle değerlendirin ve dApp ile 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ı, sektördeki en zarif çözümlerden biri olarak öne çıkıyor: güvene dayalı olmayan, kriptografik olarak doğrulanmış ve protokol-yerel. Sektör daha iyi standartlara doğru ilerliyor; ancak Kademe 3 zincirlerin temel protokol kısıtları ortadan kalkmıyor.
En basit kural: Eğer cüzdanınız size bir hash veya onaltılık bir bayt akışı gösterip imzalamanızı istiyorsa, bunu kırmızı bayrak olarak görün.
Kaynaklar ve Ek Okuma
Bu kaynaklar, makalede ele alınan protokol ve standartlar hakkında teknik derinlik sunar.
EVM açık imzalama metadata standardı | |
Bitcoin kısmi işlem imzalama | |
Polkadot güvene dayalı olmayan açık imzalama | |
Cosmos insan okunabilir imzalama | |
İnsan okunabilir hesap tanımlayıcıları | |
XRP tiplenmiş işlem şemaları | |
Zincir dışı tiplenmiş veri imzalama standardı | |
Polkadot/Substrate metadata sistemi | |
Topluluk metadata katkıları | |
Algorand akıllı kontrat ABI |
FAQ
-
Açık imzalama, donanım cüzdanınızın onaylamadan önce güvenilir ekranında alıcı adresi, token miktarı, ağ ücreti ve yetkilendirdiğiniz işlemi insan tarafından okunabilir şekilde göstermesi demektir. Kör imzalama ise cüzdanın yorumlayamayacağınız kodlanmış ikili veriyi (genellikle bir hex dizesi) göstermesi ve sizin bunu güvenerek onaylamanızdır. Güvenlik riski, ele geçirilmiş bir uygulamanın ekranda size bir şey gösterirken imzanızı tamamen farklı bir işleme yönlendirebilmesidir.
-
Her zaman değil, ancak risk gerçektir. Sadece iki normal cüzdan arasında basit ETH transferlerinde donanım cüzdanınız genellikle alıcıyı ve miktarı net şekilde gösterebilir. Opaklık sorunu, akıllı kontratlarla etkileşime geçtiğinizde başlar; token takası, likidite sağlama, izin onaylama gibi işlemlerde. Bu tür etkileşimlerde, net bir ekran görüp görmemeniz, ilgili dApp ve cüzdan kombinasyonunun ERC-7730 metadata desteği olup olmamasına bağlıdır. Destek yoksa kör imzalama yapıyorsunuz demektir.
-
Protokol tasarımı bazı ödünleşmeler içerir. Ethereum'un esnek ABI sistemi, XRP Ledger gibi daha kısıtlı zincirlerde mümkün olmayan zengin bir DeFi uygulama ekosistemine olanak tanır. Bu esneklik, işlemlerin kendini tanımlamaması pahasına gelir. Bunu geriye dönük olarak değiştirmek, binlerce dağıtılmış akıllı kontratta uyumsuzluk yaratır. ERC-7730 metadata yaklaşımı ve EIP-712 gibi çabalar, mevcut mimari içinde pratik iyileştirmeler sunar; tam bir protokol yeniden tasarımı değildir.
-
ERC-7730, donanım cüzdanlarının belirli akıllı kontrat etkileşimlerini nasıl çözüp görüntüleyeceğini anlatan bir JSON metadata standardıdır. Bir protokol ekibi, kontrat fonksiyonlarının ham ABI kodlamasını insan tarafından okunabilir etiket ve formatlara eşleyen bir metadata dosyası sunabilir.
-
Evet, anlamlı şekilde daha güvenlidir. Donanım cüzdanı açık bir özet yerine kodlanmış veri gösterse bile, özel anahtar güvenli elementten asla çıkmaz ve imzalama kararı izole donanımda gerçekleşir. Ele geçirilmiş bir bilgisayar anahtarınızı çekemez. Donanım cüzdanında kör imzalama riski, anlamadığınız bir işlemi onaylayabilmenizdir; fakat anahtarınız yine de güvende kalır. Kör imzalama yapan yazılım cüzdanları ise hem onay kararınızı hem de (yazılım ele geçirilirse) anahtarınızı riske atar.
