Bazı Blokzincirleri Neden Ne İmzaladığınızı Gösterir (Diğerleri Göstermez)?
Cüzdanınızın her zaman neyi imzaladığınızı gösterememesinin nedeni ve bundan hangi blokzincirlerinin sorumlu olduğu.
Temel içgörüler
Açık imzalama, donanım cüzdanlarının kullanıcı onayı öncesinde alıcı, tutar, ücret ve akıllı sözleşme fonksiyonu gibi tüm işlem detaylarını gösterebilme yeteneğidir. Bu, yalnızca blokzincir protokolü işlemleri kendi kendini tanımlayan, insan tarafından okunabilir şekilde kodlarsa mümkündür. Sınırlı ve tipli işlem modellerine sahip blokzincirler (XRP Ledger, Polkadot, Cosmos, NEAR gibi) açık imzalamayı tasarım gereği mümkün kılarken; opak, ikili kodlanmış akıllı sözleşme verilerine dayananlar (Ethereum, Solana, TON gibi) açık imzalamayı zorlaştırır veya imkânsız hale getirir ve genellikle dış metaveri katmanlarına ihtiyaç duyar. Sonuç olarak, makale protokol düzeyindeki tasarım kararlarının — cüzdan yazılımından ziyade — açık imzalama imkanını belirlediğini ve işlem şeffaflığının eksikliğinin büyük güvenlik risklerine yol açtığını vurgular.
Açık imzalama nedir?
Açık imzalama, donanım cüzdanınızın güvenilir ekranında bir işlemi onaylamadan önce işlemin gerçek detaylarını — alıcı, tutar, ücret ve çağrılan akıllı sözleşme fonksiyonu gibi — size göstermesi anlamına gelir. Buradaki belirleyici unsur, cüzdan yazılımının kalitesi değil, blokzincir protokolünün işlemleri kendi kendini tanımlayan tipli yapılar olarak mı, yoksa yorumlanması için dış metaveri gerektiren opak ikili bloklar olarak mı kodladığıdır. Bu, protokol tasarım aşamasında verilen mimari bir karardır ve gerçek güvenlik sonuçları vardır.
⚠️ February 2025: 1,5 milyar dolarlık Bybit hack'i — kripto tarihinin en büyük hırsızlığı — tam olarak donanım cüzdanı imzalayıcılarının sıradan bir transfer ile kötü niyetli bir proxy sözleşme yükseltmesini ayırt edememesi nedeniyle gerçekleşti. Protokol, cüzdanlara ayırt edebilecekleri hiçbir bilgi sunmadı.
Bazı blokzincirleri neden açık imzalamayı kolaylaştırıyor?
Bazı zincirlerin açık imzalamayı neden kolaylaştırdığını, bazılarının ise neredeyse imkânsız kıldığını anlamak için, her bir blokzincirin işlemleri nasıl kodladığına, akıllı sözleşme fonksiyonlarını nasıl tanımladığına ve programlanabilir mantığı nasıl ele aldığına bakmak gerekir.
13 büyük blokzincir ekosistemi, mimarilerinin açık imzalamayı nasıl desteklediğine göre üç ayrı katmanda toplanır. Sınırlı ve tipli işlem modellerine sahip zincirler en üst katmanda yer alır. Genel amaçlı akıllı sözleşmelere sahip zincirler ise sürekli olarak zorlanır; programlanabilirlik arttıkça açık imzalama sağlamak da o kadar zorlaşır.
- İşlemler nasıl kodlanıyor?: Format, kendi kendini yorumlayacak kadar tip bilgisini içeriyor mu, yoksa dış bağlam olmadan çözülemeyen ham ikili veri mi?
- Programlanabilir mantık nasıl çalışıyor?: Sınırlı tipli işlemler tanım gereği okunabilir; genel amaçlı akıllı sözleşmeler ise keyfi komut verisiyle opaktır.
1. Katman: Mimari olarak şeffaf — işlem amacı tasarımdan okunabilir
Dört ekosistem, açık imzalamayı harici araçlara gerek bırakmadan protokol tasarımının doğal sonucu haline getirmesiyle öne çıkar.
XRP Ledger
XRP Ledger, büyük blokzincirler arasında en güçlü açık imzalama desteğine sahiptir. Mimarisi, her biri adlandırılmış ve tipli alanlardan oluşan tam tanımlı şemaya sahip ~50'den fazla işlem türü (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint vb.) kullanır.
İkili format kendi kendini tanımlar — TransactionType alanı, işlemin kesin olarak ayrıştırılmasını sağlar ve tüm alan şeması rippled kaynak kodundaki definitions dosyasında tutulur.
Bir donanım cüzdanı, bilinen her işlem türünün tüm alanlarını gösterebilir: alıcı, tutar (tokenlar için para birimi ve ihraççı ile), ücret, notlar ve tipe özel parametreler. Hesap tabanlı modelde tutarlar açıkça belirtilir (UTXO karmaşıklığı yoktur) ve ücretler gizli hesaplama yerine basit bir alandır.
Mevcut ana ağ işlemlerinin neredeyse %100'ü tamamen açık imzalanabilir. Tek risk, protokol güncellemeleriyle eklenen yeni işlem türlerinin donanım cüzdanı uygulaması güncellemeleri gerektirmesidir; bilinmeyen türlerde kör imzalamaya geri dönülür.
Polkadot / Substrate
Polkadot, sektördeki en gelişmiş açık imzalama çözümünü geliştirmiştir. Çalışma zamanı metaveri sistemi (MetadataV14/V15), her bir pallet (modül), çağrı ve veri tipi için tam, kendi kendini tanımlayan bir tip kaydı sunar.
Her işlem (extrinsic), pallet_index || call_index || encoded_arguments şeklinde yapılandırılır ve metaveri, bu indekslerin ne anlama geldiğini ve argümanların nasıl çözüleceğini tam olarak belirtir.
Temel zorluk, tam metaverinin 200KB'yi aşmasıdır — yaklaşık 64KB RAM'e sahip donanım cüzdanları için çok büyüktür. Çözüm, RFC-0078 (Merkleized Metadata), metaveriden bir Merkle ağacı oluşturur ve yalnızca ilgili alt kümeyi (işlem için gereken tipler) ve dahil olunduğuna dair kriptografik kanıtı iletir.
Metaveri hash'i, CheckMetadataHash imzalı uzantısı ile zincir üzerinde doğrulanır ve sistemi güvenilir kılar. Bu sayede, tüm Polkadot parachain ve relay chain'lerinde çalışan tek bir genel Ledger uygulaması mümkündür, zincir başına güncelleme gerekmez.
Bu yaklaşım, çalışma zamanı güncellemelerini zarifçe yönetir; çağrı indeksleri değişse bile yeni metaveri ve kanıtlar imzalamanın doğruluğunu korur.
Cosmos / Tendermint
Cosmos/Tendermint zincirleri, her işlemin bir veya daha fazla sdk.Msg nesnesi içerdiği tipli mesaj mimarisinden faydalanır. Bunlar Protobuf'un google.protobuf.Any yapısına sarılır ve mesaj tipini belirten bir type_url alanı içerir.
Standart mesajlar (MsgSend, MsgDelegate, MsgVote) iyi bilinen şemalara sahiptir.
Ekosistemin açık imzalama çözümü, Cosmos SDK v0.50 ile gelen SIGN_MODE_TEXTUAL (ADR-050)'dir. İşlemleri küçük cihazlara uygun ekran dizileri olarak sunar (~40 karakter), value renderers ise ham veriyi insan tarafından okunabilir formata dönüştürür: coinler "2 ATOM" şeklinde, adresler bech32 ile, zaman damgaları RFC3339 ile gösterilir.
Geliştiriciler, kendi mesaj tipleri için özel göstericiler sağlayabilir (format ve parse fonksiyonlarının tamamen tersinir olması şartıyla). İmzalanan veri hem metinsel gösterimi hem de ham baytların hash'ini içerir; bu da güvenliği korur.
NEAR Protocol
NEAR Protocol, insan tarafından okunabilirliği önceliklendiren mimari tercihleriyle açık imzalamayı mümkün kılar. Hesap tanımlayıcıları, "alice.near" gibi okunabilir adlardır; hex adresleri yerine kullanılır.
İşlemler, her zaman tanımlanabilen tipli Action enumlarını (Transfer, Stake, FunctionCall, AddKey vb.) içerir. Özellikle FunctionCall işlemi, yöntem adını düz metin olarak (ör. "transfer", "set_greeting") ve varsayılan olarak JSON-ile serileştirilmiş argümanları içerir.
Bir donanım cüzdanı şu şekilde gösterebilir: "app.defi.near üzerinde 'swap' metodunu çağır, argümanlar: {amount: 1000, token: 'usdc.near'}." Bu, herhangi bir seçici tabanlı sistemden çok daha okunabilirdir. Ana sınırlama, bazı sözleşmelerin gaz verimliliği için Borsh-ile serileştirilmiş argümanlar kullanmasıdır; şema olmadan opaktır.
2. Katman: Koşullu Açıklık — Yerel İşlemler Açık, Akıllı Sözleşmelerde Şeffaflık Kaybolur
Taban katmanında açık imzalama mümkündür. Genel amaçlı programlanabilirlik devreye girdiğinde şeffaflık ciddi şekilde azalır.
Bitcoin
Bitcoin, işlem modeli nedeniyle akıllı sözleşme olmadan bile açık imzalama zorlukları yaşar. UTXO modeli, ham işlemlerde giriş tutarlarının yer almaması anlamına gelir; girişler önceki çıkışlara işlem hash'i ve indeks ile referans verir, ancak bu çıkışların değeri belirtilmez.
Bu bilgi olmadan, donanım cüzdanı ücreti (toplam girişler eksi toplam çıkışlar) hesaplayamaz veya fazla ödeme yapılmadığını doğrulayamaz. PSBT (BIP 174) bunu, imzasız işlemleri UTXO metaverisi ve değişim adreslerini tanımlamak için BIP32 türetme yolları ile sarmalayarak çözer.
PSBT ile donanım cüzdanları, standart ödemelerde alıcı adresi, tutar ve ücreti net şekilde gösterebilir ve bu tipik işlemlerin yaklaşık %90'ını kapsar. Çoklu imza yapıları, zaman kilitli komut dosyaları ve Taproot script-path harcamalarıyla karmaşıklık artar — P2SH ve P2WSH, keyfi komut dosyalarını hash'lerin arkasına gizler; Taproot'un MAST yapısı ise alternatif harcama koşullarını kullanılana kadar görünmez kılar.
Aptos
Aptos, Move'un güçlü tip sistemi ve zincir üstü ABI'leri sayesinde avantajlıdır. İşlem yükleri, 0x1::aptos_account::transfer gibi tam nitelikli fonksiyon tanımlayıcıları, modül adresi, modül adı ve fonksiyon adını içerir.
SDK, zincir üstü ABI'leri sorgulayarak BCS-ile kodlanmış argümanları ayrıştırabilir. Bu, ABI erişimi olan bir donanım cüzdanının "0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000) çağrısı" gösterebileceği anlamına gelir.
Ancak, BCS (Binary Canonical Serialization) kendi kendini tanımlamaz; ABI şeması olmadan ham BCS baytları anlamsızdır. Komut dosyası yükleri (keyfi Move bytecode) ise yapılandırılmış giriş fonksiyonunu tamamen atlar. Ledger Aptos uygulamasında karmaşık işlemler için açıkça "Kör İmzalamayı Etkinleştir" ayarı bulunur; bu, basit ve karmaşık işlemler arasındaki farkı gösterir.
Stellar
Bu katmanın en saf örneği. 26 klasik işlem türü (Payment, ChangeTrust, ManageSellOffer vb.) sabit şemalara sahiptir ve tamamen ayrıştırılabilir — Ledger uygulaması işlem türü, tutar, hedef, varlık, not ve ücreti adım adım gösterir. Klasik işlemler için yaklaşık %95 kapsama sağlar.
- 2024'te başlatılan Soroban akıllı sözleşmeleri, Ethereum'da görülen opaklık sorununu yeniden ortaya çıkarır. Çağrılar, sözleşme adreslerinin opak formatta olduğu ve parametrelerin çözüm için sözleşmeye özgü bilgi gerektiren ScVal tipinde kodlandığı InvokeHostFunction işlemleri olarak gelir. Dış metaveri olmadan ham Soroban işlemlerinde neredeyse %0 açık imzalama mümkündür.
Algorand
Yedi tipli işlem türü (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof) — tamamı MessagePack kodlamasından tamamen ayrıştırılabilir. ARC-4 ABI standardı, uyumlu akıllı sözleşmeler için yöntem imzaları, parametre adları ve açıklamalar sunar.
- ARC-4 dışındaki sözleşmelerde argümanlar opaktır.
- Tüm akıllı sözleşmeler, imzalama sırasında tamamen görünmez olan 256'ya kadar iç işlem (8 seviye derinliğe kadar iç içe çağrılar dahil) üretebilir.
Cardano & Tezos
Cardano'nun eUTXO modeli, basit işlemler için giriş, çıkış, ücret ve çoklu varlık değerlerinin net gösterimini sağlar. Ancak Plutus komut dosyası etkileşimlerinde, insan tarafından yorumlanabilecek standart bir şeması olmayan keyfi CBOR kodlu datums ve redeemer'lar kullanılır. CIP-21, Plutus modunun "maksimum esneklik için kullanıcıların yanıltılması pahasına" çalıştığını açıkça belirtir.
Tezos ise yapısal bir avantaja sahiptir — sözleşme parametre tipleri zincir üzerinde tutulur ve giriş noktaları hash tabanlı seçiciler yerine dize adları kullanır; bu, çakışma sorununu ortadan kaldırır. Ancak Micheline ikili kodlama, tam ayrıştırma için yine de sözleşme tip şeması gerektirir ve Ledger Tezos uygulaması karmaşık parametrelerin sınırlı gösterimini kabul eder.
❌ Mimari Olarak Opak — Açık İmzalama Zorlaştırılmıştır
Burada temel tasarım tercihleri — araç eksiklikleri değil — açık imzalamayı doğası gereği zorlaştırır. Dış metaveri katmanları kısmen yardımcı olabilir ama temel mimariyi düzeltemez.
Ethereum / EVM Zincirleri
En bilinen ve en çok incelenen örnek. Bir kullanıcı akıllı sözleşme ile etkileşime girdiğinde, işlemin veri alanı 4 baytlık fonksiyon seçici (fonksiyon imzasının keccak256 ile ilk 4 baytı) ve ardından 32 baytlık kelimeler halinde ABI ile kodlanmış parametreler içerir. Sözleşmenin ABI JSON'u — zincir üzerinde tutulmadığı için — olmadan bu tamamen onaltılık bir gürültüdür. Bir donanım cüzdanı 0xa9059cbb000...03e8 gördüğünde, dış metaveri olmadan bunun "0xABC... adresine 1000 token transferi" anlamına geldiğini bilemez.
EVM'ye özgü kalıplarla zorluklar katlanır:
- Fonksiyon seçici çakışmaları: 4byte.directory veritabanında neredeyse 1 milyon imza yer alır — 32 bitlik alan için çakışma eşiği çoktan aşılmıştır. Farklı fonksiyonlar aynı seçiciyi üretebilir.
- Proxy sözleşmeler: Çalıştırmayı, adresleri her an değişebilen implementation sözleşmelerine delegatecall ile yönlendirir. Bybit hack'i tam olarak bu boşluktan yararlanmıştır.
- Multicall kalıpları: ABI ile kodlanmış calldata'yı parametrelerin içinde iç içe gömer, özyinelemeli ayrıştırma gerektirir.
- EIP-712: Zincir dışı mesajlar (izinler, emirler) için okunabilirliği artırır ancak zincir üzerindeki işlem opaklığına dokunmaz.
Solana
Açık imzalama açısından en zorlu mimarilerden biri. İşlem talimatları bir program_id, hesap listesi ve opak bir bayt dizisi içerir. Standart bir ABI yoktur — her program kendi serileştirme formatını tanımlar. Anchor framework, 8 baytlık ayırt ediciler (talimat adının SHA-256'sından) ile yarı-standart bir yaklaşım sunar; ancak bu bir framework geleneğidir, protokol gerekliliği değildir. Birçok program Anchor kullanmaz ve IDL yayınlamaz.
- Sürüm numaralı işlemlerdeki Adres Bakım Tabloları, 32 baytlık adresleri 1 baytlık indekslere sıkıştırır — donanım cüzdanları, zincir üzerinde erişim olmadığı için tablo içeriğini doğrulayamaz. Solana'nın kendi belgeleri de bunu açıkça kabul eder.
- Çapraz Program Çağrı zincirleri imzalama sırasında görünmezdir.
- Basit SOL transferleri ve SPL token işlemleri — Ledger bunları ayrıştırabilir. DeFi etkileşimleri, Solana işlem hacminin büyük çoğunluğunu oluşturur — kör imzalama neredeyse zorunludur.
TON
Açık imzalamaya direnç gösteren birden fazla mimari özelliği bir araya getirir:
- Cell tabanlı veri yapısı: Tüm veriler, her biri 1023 bit ve 4 referansa kadar tutabilen hücre ağaçları olarak temsil edilir; birden fazla hücreye sığan mesajları ayrıştırmak için özyinelemeli ağaç dolaşımı gerekir.
- TL-B kodlama: Bit düzeyinde çalışır, karmaşık yapıcılar ve özyinelemeli referanslar içerir — bayt hizalı formatlara göre donanımda ayrıştırması çok daha zordur.
- Evrensel bir ABI yoktur: 32 bitlik op kodları bir gelenektir, protokol zorunluluğu değildir.
- Eşzamansız yürütme: Tek bir kullanıcı işlemi, sonraki bloklarda birden fazla sözleşme ve shard arasında zincirleme iç mesajlar tetikleyebilir. Kullanıcı yalnızca ilk dış mesajı imzalar — devamındaki her şey imzalama sırasında görünmez ve öngörülemezdir.
Sui (Mansiyon)
Aptos ile aynı Move tip sistemini paylaşır, bu da talimat düzeyinde yardımcı olur. Ancak Sui'nin Programlanabilir İşlem Blokları (PTB), işlemler arasında zincirlenen 1.024'e kadar komut içerebilir — bir coin'i böl, DeFi protokolüne yatır, teminat karşılığı borç al, bakiyeyi transfer et; hepsi tek bir atomik işlemde. Bireysel komutlar iyi tiplenmiş olsa da, çok adımlı bir PTB'nin donanım cüzdanı ekranında gerçekten anlamlı şekilde gösterilmesi aşırı zordur. Tüm işlemi anlamak, tüm komut dizisinin ve aradaki veri bağımlılıklarının analizini gerektirir.
Hızlı Referans
| Zincir | Temel Zorluk | Açık İmzalama |
|---|---|---|
| XRP Ledger | Yeni işlem türleri cüzdan güncellemesi ister | İyi |
| Polkadot | 200KB+ metaveri — Merkle kanıtı ile çözüldü | İyi |
| Cosmos | Özel mesaj tipleri özel gösterici ister | İyi |
| NEAR | Borsh-ile kodlanan argümanlar şema olmadan opak | İyi |
| Bitcoin | UTXO modeli giriş tutarlarını gizler; karmaşık komut dosyaları | Orta |
| Aptos | BCS argümanları dış ABI gerektirir; script yükleri yapıyı atlar | Orta |
| Stellar | Klasik işlemler sorunsuz; Soroban neredeyse hiç kapsanmaz | Orta |
| Algorand | ARC-4 dışı sözleşmeler opak; 256 görünmez iç işlem | Orta |
| Cardano | Plutus datums/redeemer'larda standart gösterim yok | Orta |
| Tezos | Karmaşık parametreler sözleşme tip şeması gerektirir | Orta |
| Ethereum / EVM | Zincir üstü ABI yok; proxy; seçici çakışmaları; multicall | Zor |
| Solana | Standart ABI yok; görünmez CPI zincirleri; lookup tablo opaklığı | Zor |
| TON | Bit düzeyinde kodlama; zincirleme mesajlar; evrensel ABI yok | Zor |
| Sui | 1.024 komutlu PTB'ler ve arası veri bağımlılıkları | Zor |
Açık İmzalama Kalitesini Aslında Ne Belirler?
Üç mimari desen en güçlü belirleyiciler olarak öne çıkar:
- Sınırlı tipli işlem modelleri (XRP, Stellar klasik, Algorand taban katman) — her olası işlem için bilinen bir şema vardır. Tanım gereği en kolay gösterilenlerdir.
- Kendi kendini tanımlayan metaveri sistemleri (Polkadot çalışma zamanı metaverisi, Cosmos tipli mesajları) — işlemler doğrudan okunabilir değildir ama dış kayıtlara gerek kalmadan ayrıştırılacak kadar tip bilgisi taşır.
- Opak komut verisi (Solana, Ethereum, TON) — protokol, akıllı sözleşme parametrelerini keyfi bayt dizileri olarak ele alır. Dış araçlar ne kadar gelişmiş olursa olsun, bunu tam olarak telafi edemez.
Sektörün Yanıtı
Ekosistem, 3. katmandaki zincirler için pratik çözüm olarak dış metaveri katmanlarında birleşti. ERC-7730, Ledger'ın Generic Parser'ı ve MetaMask ortaklığı en olgun uygulamalardır. Polkadot'un Merkleized Metadata'sı ise muhtemelen en zarif çözümdür — güvenilirdir, tüm parachain'lerde çalışır, dış kayıt gerektirmez. Cosmos'un SIGN_MODE_TEXTUAL'ı doğrudan SDK'ya entegredir. Solana ve TON için henüz ekosistem çapında bir açık imzalama standardı yoktur.
Dış metaverinin ne olduğuna net bakalım: Çalışır, gereklidir, ancak yerel olarak şeffaf bir protokol kadar kapsamlı olamaz. Sürekli topluluk bakımı gerektirir, yeni sözleşme dağıtımlarının gerisinde kalır ve yerel çözümlerin taşımadığı güven varsayımlarını beraberinde getirir.
Bu işin yanlış yapılmasının bedeli milyar dolarlarla ölçülür: Bybit hack'i, kör imzalamanın bir kullanıcı deneyimi sorunu değil, sistemik bir altyapı açığı olduğunu gösterdi. Yeni blokzincir tasarımlarında çıkarılacak ders nettir: İşlem okunabilirliğini protokol katmanına yerleştirmek, bunu sonradan dış standartlarla yamalamaktan kat kat daha etkilidir.
