Bazı Blokzincirler Neden İmzaladığınız İşlemleri Gösteriyor (Bazıları
Cüzdanınızın her zaman neyi imzaladığınızı gösterememesinin nedeni ve bunun sorumlusu olan blokzincirler.
Temel içgörüler
Açık imzalama, donanım cüzdanlarının onay öncesinde alıcı, tutar, ücret ve sözleşme fonksiyonu gibi tüm işlem detaylarını gösterebilmesini ifade eder. Bu, yalnızca blokzincir protokolü işlemleri 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ımsal olarak mümkün kılar. Oysa Ethereum, Solana ve TON gibi opak, ikili kodlanmış akıllı sözleşme verilerine dayalı zincirlerde açık imzalama çok zordur veya imkânsızdır; genellikle harici metadata katmanları gerekir. Sonuç olarak, protokol düzeyindeki tasarım tercihleri — cüzdan yazılımı değil — açık imzalama imkanını belirler ve işlem şeffaflığı eksikliği büyük güvenlik risklerine yol açabilir.
Açık imzalama nedir?
Açık imzalama, donanım cüzdanınızın güvenilir ekranında bir işlemi onaylamadan önce size işlemin gerçek detaylarını — alıcı, tutar, ücret ve çağrılan sözleşme fonksiyonunu — göstermesi anlamına gelir. Buradaki belirleyici unsur cüzdan yazılımının kalitesi değil, blokzincir protokolünün işlemleri kendini tanımlayan, tipli yapılarda mı yoksa harici metadata gerektiren opak ikili veri olarak mı kodladığıdır. Bu, protokol tasarım aşamasında verilen mimari bir karardır ve doğrudan güvenlik sonuçları doğurur.
⚠️ February 2025: 1,5 milyar dolarlık Bybit saldırısı — 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 başarıya ulaştı. Protokol, imzalayıcıya yorumlayacak hiçbir bilgi sunmadı.
Bazı blokzincirlerde açık imzalama neden daha kolay?
Bazı zincirlerde açık imzalamanın neden kolay, bazılarında ise neredeyse imkânsız olduğunu 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 işlediğine bakmak gerekir.
13 büyük blokzincir ekosistemi, mimarilerinin açık imzalamayı nasıl desteklediğine göre üç temel katmana ayrılı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 genellikle zorlanır; programlanabilirlik arttıkça açık imzalama daha da zorlaşır.
- İşlemler nasıl kodlanıyor? Format, kendini yorumlamak için yeterli tip bilgisini içeriyor mu, yoksa harici 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 okunabilirdir; genel amaçlı akıllı sözleşmeler ise keyfi komut verileriyle şeffaflığı kaybeder.
1. Katman: Mimari olarak şeffaf — işlem amacı tasarımdan okunabilir
Dört ekosistem, açık imzalamayı harici araçlara gerek duymadan protokol tasarımının doğal bir sonucu hâline getirerek öne çıkıyor.
XRP Ledger
XRP Ledger, büyük blokzincirler arasında en güçlü açık imzalama desteğine sahiptir. Mimarisi, her biri isimlendirilmiş ve tipli alanlardan oluşan tam tanımlı şemalara sahip yaklaşık 50+ işlem türü (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint vb.) içerir.
İkili format kendini tanımlar — TransactionType alanı işlemin kesin olarak ayrıştırılmasını sağlar ve tam alan şeması rippled kaynak kodundaki tanımlar dosyasında tutulur.
Bir donanım cüzdanı, bilinen tüm işlem türlerinin her alanını gösterebilir: alıcı, tutar (tokenlar için para birimi ve ihraççı), ücret, notlar ve tipe özel parametreler. Hesap tabanlı modelde tutarlar açıkça belirtilir (UTXO karmaşıklığı yoktur) ve ücretler basit bir alan olarak yer alır.
Mevcut ana ağ işlemlerinin neredeyse %100'ü tamamen açık imzalanabilir. Yalnızca yeni işlem türleri (ör. Vault ve Loan işlemleri) protokol güncellemeleriyle eklendiğinde donanım cüzdanı uygulamasının güncellenmesi gerekir; bilinmeyen türler için kör imzalama devreye girer.
Polkadot / Substrate
Polkadot, sektördeki en gelişmiş açık imzalama çözümünü geliştirmiştir. Çalışma zamanı metadata sistemi (MetadataV14/V15), çalışma zamanındaki her pallet (modül), çağrı ve veri tipi için eksiksiz ve kendini tanımlayan bir tip kayıt defteri sunar.
Her işlem (extrinsic), pallet_index || call_index || encoded_arguments yapısındadır ve metadata, bu indekslerin ne anlama geldiğini ve argümanların nasıl çözüleceğini tam olarak belirtir.
En büyük zorluk, tam metadata'nın 200KB'yi aşmasıdır — ~64KB RAM'e sahip donanım cüzdanları için çok büyük. Çözüm, RFC-0078 (Merkleized Metadata) ile metadata'dan bir Merkle ağacı oluşturmak ve yalnızca ilgili alt küme ile kriptografik dahil olma kanıtını aktarmaktır.
Metadata hash'i, CheckMetadataHash imzalı uzantısı ile zincir üzerinde doğrulanır ve sistemin güvenilirliğini sağlar. Böylece, tüm Polkadot parachain ve relay chain'lerde çalışan tek bir genel Ledger uygulaması mümkün olur; zincir başına güncelleme gerekmez.
Bu yaklaşım, çalışma zamanı yükseltmelerini de sorunsuz yönetir; çağrı indeksleri değişse bile taze metadata ve kanıtlarla imzalama doğruluğu korunur.
Cosmos / Tendermint
Cosmos/Tendermint zincirleri, işlemlerin bir veya daha fazla sdk.Msg nesnesi ve Protobuf'un google.protobuf.Any yapısı ile tipli mesaj mimarisinden faydalanır. type_url alanı mesaj tipini tanımlar.
Standart mesajlar (MsgSend, MsgDelegate, MsgVote) iyi bilinen şemalara sahiptir.
Ekosistemin açık imzalama çözümü SIGN_MODE_TEXTUAL (ADR-050) olup, işlemleri küçük ekranlara uygun ardışık ekranlar olarak gösterir. Value renderers ham verileri insan tarafından okunabilir biçime çevirir: coin miktarları "2 ATOM" olarak, adresler bech32 ile, zaman damgaları RFC3339 ile gösterilir.
Geliştiriciler, kendi mesaj tipleri için özel renderers sağlayabilir (format ve parse fonksiyonlarının birebir terslenebilir 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 çeşitli mimari tercihlerle açık imzalamayı mümkün kılar. Hesap tanımlayıcıları, "alice.near" gibi okunabilir isimlerdir; onaltılık adresler yerine.
İşlemler, her zaman tanımlanabilen tipli Action enumları (Transfer, Stake, FunctionCall, AddKey vb.) içerir. Özellikle FunctionCall işlemi, method_name'i düz metin olarak (ör. "transfer", "set_greeting") ve argümanları varsayılan olarak JSON-serialize edilmiş şekilde içerir.
Bir donanım cüzdanı, "app.defi.near üzerinde 'swap' metodunu args: {amount: 1000, token: 'usdc.near'} ile çağır" gibi bir ekran gösterebilir. Bu, selector tabanlı sistemlere göre çok daha okunabilirdir. Ana kısıtlama, bazı sözleşmelerin gaz verimliliği için Borsh-serialize edilmiş argümanlar kullanmasıdır; şema olmadan bunlar opaktır.
2. Katman: Koşullu Şeffaflık — Yerel İşlemler Okunur, Akıllı Sözleşmelerde Zorlaşır
Taban katmanında açık imzalama mümkündür. Genel amaçlı programlanabilirlik devreye girdiğinde şeffaflık önemli ölçüde azalır.
Bitcoin
Bitcoin, işlem modeliyle açık imzalama konusunda benzersiz bir konuma sahiptir: Akıllı sözleşme olmadan bile, UTXO modeli nedeniyle ham işlemler giriş tutarlarını içermez; girişler, önceki işlemlere referans verir ama bu çıktılar ne kadar değer taşıyordu, bu bilgi yoktur.
Bu bilgi olmadan donanım cüzdanı, ücreti (toplam giriş eksi toplam çıkış) hesaplayamaz veya fazla ödeme riskini tespit edemez. PSBT (BIP 174), imzasız işlemleri UTXO metadata ve değişim adreslerinin BIP32 türetim yollarıyla sarmalayarak bu sorunu çözer.
PSBT ile donanım cüzdanları, standart ödemeler için alıcı adreslerini, tutarları ve ücretleri net şekilde gösterebilir — tipik işlemlerin yaklaşık %90'ı kapsanır. Çoklu imza, zaman kilitli scriptler ve Taproot script-path harcamalarında ise karmaşıklık artar; P2SH ve P2WSH, keyfi scriptleri hash arkasında gizler, Taproot'un MAST yapısı 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'lerin erişilebilirliği 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ı içerir.
SDK, zincir üstü ABI'leri sorgulayarak BCS ile kodlanmış argümanları ayrıştırabilir. Yani ABI erişimi olan bir donanım cüzdanı, "0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000) çağrısı" gösterebilir.
Ancak BCS (Binary Canonical Serialization) kendini tanımlamaz; ABI şeması olmadan ham BCS baytları anlamsızdır. Script yükleri (keyfi Move bayt kodu) tamamen yapılandırılmış giriş fonksiyonu biçimini atlar. Ledger Aptos uygulamasında karmaşık işlemler için "Kör İmzalamayı Etkinleştir" seçeneği bulunur; bu da basit ve karmaşık işlemler arasındaki farkı gösterir.
Stellar
2. katman örneğinin en saf hali. 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 oranı vardır.
- Soroban akıllı sözleşmeleri (2024'te başlatıldı) Ethereum'daki opaklık sorununu aynen geri getirir. Çağrılar, opak formatta sözleşme adresleri ve yalnızca sözleşmeye özel bilgiyle çözülebilen ScVal tipinde parametrelerle InvokeHostFunction işlemleri olarak gelir. Harici metadata olmadan ham Soroban işlemlerinde açık imzalama neredeyse sıfırdır.
Algorand
Yedi tipli işlem türü (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof) — hepsi MessagePack kodlamasıyla tamamen ayrıştırılabilir. ARC-4 ABI standardı, uyumlu akıllı sözleşmeler için metod imzaları, parametre adları ve açıklamalar sağlar.
- ARC-4 olmayan 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 iç içe çağrı 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 script etkileşimlerinde, insan tarafından yorumlanabilecek standart bir şeması olmayan keyfi CBOR ile kodlanmış datums ve redeemer'lar yer alır. CIP-21, Plutus modunun "maksimum esneklik için kullanıcıların yanıltılma riski" taşıdığını açıkça belirtir.
Tezos, yapısal avantaj sunar — sözleşme parametre tipleri zincir üstünde saklanır ve giriş noktaları hash tabanlı selector yerine dize adları kullanır; çakışma sorunu ortadan kalkar. Ancak Micheline ikili kodlamada, tam ayrıştırma için sözleşme tip şeması gerekir ve Ledger Tezos uygulaması karmaşık parametrelerin gösteriminin sınırlı olduğunu belirtir.
❌ Mimari Olarak Opak — Açık İmzalama Zorunlu Bir Mücadeledir
Burada temel tasarım tercihleri — araç eksiklikleri değil — açık imzalamayı doğası gereği zorlaştırır. Harici metadata katmanları kısmen yardımcı olabilir ama temel mimariyi düzeltemez.
Ethereum / EVM Zincirleri
En belirgin ve en çok incelenen örnek. Bir kullanıcı akıllı sözleşmeyle etkileşime geçtiğ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 kelimelerle ABI ile kodlanmış parametreler içerir. Sözleşmenin ABI JSON'u zincir üstünde saklanmadığı için, bu alan saf onaltılık gürültüdür. Bir donanım cüzdanı 0xa9059cbb000...03e8 gördüğünde, harici metadata olmadan bunun "0xABC... adresine 1000 token transferi" olduğunu bilemez.
EVM'de yaygın olan bazı kalıplar zorlukları artırır:
- Fonksiyon seçici çakışmaları: 4byte.directory veritabanı neredeyse 1 milyon imza içeriyor — 32 bitlik alan için çakışma riski çoktan aşıldı. Farklı fonksiyonlar aynı seçiciyi üretebilir.
- Proxy sözleşmeler: delegatecall ile yürütmeyi, adresi her an değişebilecek uygulama sözleşmelerine yönlendirir. Bybit saldırısı tam olarak bu boşluktan faydalandı.
- Multicall kalıpları: ABI ile kodlanmış çağrı verisini parametreler içinde iç içe gömer; özyinelemeli ayrıştırma gerekir.
- EIP-712: Zincir dışı mesajlar (izinler, emirler) için okunabilirliği artırır ama zincir üstü işlem opaklığına çözüm getirmez.
Solana
Açık imzalama açısından belki de en zorlu mimari. İşlem komutları bir program_id, hesap listesi ve opak bir bayt dizisi içerir. Standart bir ABI yoktur — her program kendi serileştirme formatını belirler. Anchor çerçevesi (komut adının SHA-256'sından türetilen 8 baytlık ayırt edici) yarı-standart bir yaklaşım sunar; ancak bu bir protokol şartı değil, çerçeve konvansiyonudur. Birçok program Anchor kullanmaz ve IDL yayımlamaz.
- 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 üstü erişim olmadığı için tablo içeriğini doğrulayamaz. Solana'nın kendi belgelerinde bu açıkça belirtilir.
- Ç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 ise Solana işlem hacminin büyük bölümünü oluşturur ve neredeyse her zaman kör imzalama gerektirir.
TON
Bağımsız olarak açık imzalamaya dirençli birçok mimari özelliği bir arada barındırır:
- Hücre 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ç taraması gerekir.
- TL-B kodlama: Bit düzeyinde, karmaşık yapıcılar ve özyinelemeli referanslarla çalışır — bayt hizalı formatlara göre donanımda ayrıştırmak çok daha zordur.
- Evrensel ABI yok: 32 bitlik op kodları sadece bir konvansiyondur, protokol zorunluluğu değildir.
- Eşzamansız yürütme: Tek bir kullanıcı işlemi, sonraki bloklarda birden çok sözleşme ve shard arasında zincirleme dahili mesajlar tetikleyebilir. Kullanıcı sadece ilk dış mesajı imzalar — sonrasındaki her şey imzalama sırasında görünmez ve öngörülemezdir.
Sui (Özel Not)
Aptos ile aynı Move tip sistemini paylaşır; bu, komut düzeyinde avantaj sağlar. Ancak Sui'nin Programlanabilir İşlem Blokları, 1.024 komuta kadar zincirleme işlemi destekler — bir coin'i böl, DeFi protokolüne yatır, teminat gösterip borç al, tümünü tek atomik işlemde gerçekleştir. Bireysel komutlar iyi tiplenmiş olsa da, çok adımlı bir PTB'yi donanım cüzdanı ekranında gerçekten anlamlı şekilde göstermek ciddi bir kullanıcı deneyimi zorluğudur. Tüm işlemi anlamak, komutlar arası veri bağımlılıklarını da analiz etmeyi gerektirir.
Hızlı Referans
| Zincir | Temel Zorluk | Açık İmzalama |
|---|---|---|
| XRP Ledger | Yeni işlem türleri cüzdan güncellemesi gerektirir | İyi |
| Polkadot | 200KB+ metadata — Merkle kanıtlarıyla çözüldü | İyi |
| Cosmos | Özel mesaj tipleri için özel gösterici gerekir | İyi |
| NEAR | Borsh ile kodlanmış argümanlar şemasız opak | İyi |
| Bitcoin | UTXO modeli giriş tutarlarını gizler; karmaşık scriptler | Orta |
| Aptos | BCS argümanları harici ABI ister; script yükleri yapıyı atlar | Orta |
| Stellar | Klasik işlemler iyi; Soroban neredeyse sıfır kapsama | Orta |
| Algorand | ARC-4 olmayan sözleşmeler opak; 256 görünmez iç işlem | Orta |
| Cardano | Plutus datums/redeemer'ların standart gösterimi yok | Orta |
| Tezos | Karmaşık parametreler için sözleşme tip şeması gerekir | Orta |
| Ethereum / EVM | Zincir üstü ABI yok; proxy; seçici çakışmaları; multicall | Zor |
| Solana | Standart ABI yok; görünmez CPI zincirleri; lookup tablosu opaklığı | Zor |
| TON | Bit düzeyinde kodlama; zincirleme mesajlar; evrensel ABI yok | Zor |
| Sui | 1.024 komutlu PTB'ler; komutlar arası 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) — tüm olası işlemler bilinen bir şemaya sahiptir. Gösterimi en kolay olanlar bunlardır.
- Kendini tanımlayan metadata sistemleri (Polkadot çalışma zamanı metadata, Cosmos tipli mesajlar) — işlemler doğrudan okunabilir olmasa bile, harici 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 işler. Harici araçlar bile bunu tam olarak telafi edemez.
Sektörün Yaklaşımı
Ekosistem, 3. katman zincirler için pratik çözüm olarak harici metadata katmanlarında birleşti. ERC-7730, Ledger'ın Genel Ayrıştırıcısı ve MetaMask ortaklığı en olgun uygulamalardır. Polkadot'un Merkleized Metadata'sı ise belki de en zarif çözümdür — güvenilir, tüm parachain'lerde çalışır, harici kayıt gerektirmez. Cosmos'un SIGN_MODE_TEXTUAL'ı doğrudan SDK'ya entegredir. Solana ve TON için ise henüz ekosistem genelinde bir açık imzalama standardı yoktur.
Harici metadata nedir, açık olalım: Çalışır, gereklidir, ancak yerel olarak şeffaf bir protokol kadar kapsama asla ulaşamaz. Sürekli topluluk bakımı gerektirir, yeni sözleşme dağıtımlarının gerisinde kalır ve yerel çözümlerde olmayan güven ilişkileri doğurur.
Bunun yanlış yapılmasının maliyeti milyarlarla ölçülür: Bybit saldırısı, kör imzalamanın bir kullanıcı deneyimi sorunu değil, sistemsel bir altyapı açığı olduğunu gösterdi. Yeni blokzincir tasarımlarında ders açıktır: İşlem okunabilirliğini protokol katmanına yerleştirmek, sonradan harici standartlarla yamalamaktan kat kat daha etkilidir.
