Solana Cüzdan Oluşturma: ed25519 Anahtarları ve Adresler

Solana, hem DeFi hem de tüketici uygulamaları için en yaygın kullanılan blokzincirlerinden biridir, ancak cüzdan oluşturma süreci Bitcoin ve Ethereum'dan önemli ölçüde farklıdır. Farklı eliptik eğri, farklı türetim yolları, farklı adres kodlaması ve anahtar yönetimine ilişkin farklı varsayımlar. Bitcoin veya Ethereum dünyasından geliyorsanız, bu farklar önemlidir --- ve bunları yanlış anlamak kayıp fonlara veya güvenlik ihlallerine yol açabilir.

Bu rehber, Solana cüzdan oluşturma sürecinin tamamını kapsar: ed25519 eliptik eğrisi, Solana'ya özgü türetim yolları, Base58 adres kodlaması ve Solana ekosistemine özgü güvenlik değerlendirmeleri.

Solana Bitcoin ve Ethereum'dan Nasıl Farklılaşır?¶

En genel düzeyde, fark eliptik eğridedir. Bitcoin ve Ethereum her ikisi de Standards for Efficient Cryptography Group (SECG) tarafından tanımlanan secp256k1 eğrisini kullanır. Solana ise Daniel J. Bernstein ve meslektaşları tarafından tasarlanan Edwards formunda bir eğri olan ed25519'u kullanır. Eğri seçimi yığının her katmanına yansır.

Solana'nın tasarım tercihleri önceliklerini yansıtır: yüksek işlem hacmi ve hızlı imza doğrulama. Ed25519 imzalarının doğrulanması, secp256k1 üzerindeki ECDSA imzalarına kıyasla yaklaşık iki kat daha hızlıdır --- bu, saniyede binlerce işlem gerçekleştirdiğinizde önemlidir. İki eğrinin daha derin bir teknik karşılaştırması için secp256k1 vs ed25519 yazısına bakın.

ed25519 Eğrisi¶

Ed25519, Curve25519 üzerinde çalışan Edwards eğrisi Dijital İmza Algoritmasının (EdDSA) belirli bir örneğidir. Eğri, 2^255 - 19 asal alanı üzerinde tanımlanmıştır (adı buradan gelir) ve bükülmüş Edwards formu kullanır:

-x^2 + y^2 = 1 + d*x^2*y^2

burada d belirli bir sabittir. Güvenlik seviyesi yaklaşık 128 bittir --- secp256k1 ile karşılaştırılabilir --- ancak uygulama özellikleri önemli ölçüde farklıdır.

Anahtar Üretimi¶

Bir Solana özel anahtarı, ed25519 terminolojisinde genellikle "tohum" olarak adlandırılan 32 baytlık rastgele bir skaler ile başlar (bir BIP39 tohum cümlesi ile karıştırılmamalıdır). Bu 32 baytlık değer, SHA-512 ile hashlenerek 64 baytlık genişletilmiş bir anahtar üretir. Alt 32 bayt (bit kırpma sonrası) imzalama için kullanılan skaler olur. Üst 32 bayt ise imza sürecinde ek rastgelelik olarak kullanılır.

Açık anahtar, eğrinin taban noktası B'nin kırpılmış skaler ile çarpılmasıyla türetilir. Sonuç, sıkıştırılmış Edwards formunda 32 baytlık bir noktadır. Bu 32 baytlık açık anahtar aynı zamanda Solana adresidir --- Ethereum'un Keccak-256 gibi ek bir hashleme adımı yoktur.

Rastgele 32 bayt → SHA-512 → 64 baytlık genişletilmiş anahtar
    → Alt 32 bayt (kırpılmış) × Taban noktası B → 32 baytlık açık anahtar = Solana adresi

Deterministik İmzalar¶

Ed25519'un ECDSA'ya kıyasla avantajlarından biri, imzaların deterministik olmasıdır. ECDSA, her imza için rastgele bir nonce gerektirir ve arızalı bir rastgele sayı üreteci özel anahtarı felaketle sızdırabilir (bu Bitcoin ve Ethereum tarihinde birden fazla kez yaşanmıştır). Ed25519, nonce'u mesajdan ve özel anahtardan türeterek bu tüm güvenlik açığı sınıfını ortadan kaldırır.

Performans¶

Ed25519 imza doğrulaması hızlıdır --- modern tek bir CPU çekirdeğinde saniyede yaklaşık 70.000 doğrulama. Bu, secp256k1 üzerindeki ECDSA doğrulamasının yaklaşık iki katı hızdır. Solana'nın 400 milisaniyelik blok süreleri ve yüksek işlem hacmini hedefleyen mimarisi için bu hız avantajı önemlidir.

Solana Türetim Yolları¶

Bitcoin ve Ethereum gibi, Solana cüzdanları da tek bir tohum cümlesinden birden fazla anahtar üretmek için HD cüzdan türetimi kullanır. Mnemonik oluşturma için BIP39 ve hiyerarşik türetim için BIP32 standartları kullanılır, ancak Solana'ya özgü yollarla.

Standart Yol: m/44'/501'/0'/0'¶

Kanonik Solana türetim yolu şudur:

m/44'/501'/0'/0'

Bunu BIP44'e göre parçalarsak:

• 44' --- Amaç: BIP44 çoklu hesap hiyerarşisi.
• 501' --- Para birimi türü: 501, Solana için SLIP44 kayıtlı dizinidir.
• 0' --- Hesap: ilk hesap.
• 0' --- "Üstü" seviyesi, ancak Solana'nın kurallarında bu adres dizinidir.

Dört seviyenin tümünün sertleştirilmiş türetim (apostrof ile gösterilir) kullandığına dikkat edin. Bu, Ethereum'un son iki seviye için sertleştirilmemiş türetim kullanan m/44'/60'/0'/0/0 yolundan farklıdır. Solana'nın tamamı sertleştirilmiş yol tercihi, türetilmiş anahtarlar arasında daha güçlü izolasyon sağlar: bir türetilmiş anahtarın ele geçirilmesi kardeş anahtarların ele geçirilmesine yol açamaz.

Birden Fazla Hesap¶

Ek hesaplar için hesap dizinini artırın:

• İlk hesap: m/44'/501'/0'/0'
• İkinci hesap: m/44'/501'/1'/0'
• Üçüncü hesap: m/44'/501'/2'/0'

Bazı cüzdanlar (Phantom gibi) son dizini artırmayı da destekleyebilir:

• m/44'/501'/0'/0'
• m/44'/501'/0'/1'
• m/44'/501'/0'/2'

Uyumluluk Hususları¶

Tüm Solana cüzdanları tam olarak aynı türetim yolunu kullanmaz. Tarihsel olarak Solana CLI m/44'/501' (yalnızca iki seviye) kullanırken, çoğu GUI cüzdan m/44'/501'/0'/0' kullanır. Bu tutarsızlık, aynı tohum cümlesinin farklı cüzdanlarda farklı adresler üretebileceği anlamına gelir. Bir cüzdanı kurtarırken, cüzdanın hangi türetim yolunu beklediğini her zaman doğrulayın.

SafeSeed'in Solana Tohum Cümlesi Oluşturucusu, kullanılan tam türetim yolunu gösterir, böylece hangi yolun hangi adresle eşleştiğini kesin olarak bilirsiniz.

Adım Adım Cüzdan Oluşturma¶

İşte bir BIP39 tohum cümlesinden Solana cüzdanı oluşturmanın tam süreci, ayrık adımlara bölünmüş haliyle.

Adım 1: Entropi Üretme¶

128 bit (12 kelimelik bir cümle için) veya 256 bit (24 kelimelik bir cümle için) entropi üretmek için kriptografik olarak güvenli bir rastgele sayı üreteci kullanın. SafeSeed'de bu, crypto.getRandomValues() aracılığıyla tarayıcının Web Crypto API'sini kullanır.

Adım 2: Mnemoniğin Oluşturulması¶

SHA-256 sağlama toplamı bitlerini entropiye ekleyin, 11 bitlik segmentlere bölün ve her segmenti BIP39 kelime listesindeki bir kelimeyle eşleştirin. Sonuç 12 veya 24 İngilizce kelimedir. Bu süreç Bitcoin ve Ethereum ile aynıdır --- BIP39 blokzincirinden bağımsızdır. Tam bir açıklama için BIP39 Explained yazısına bakın.

Adım 3: Ana Tohumun Türetilmesi¶

Mnemonik dizesine (isteğe bağlı parola tuzu ile) 2.048 yinelemeli PBKDF2-HMAC-SHA512 uygulayarak 512 bitlik bir ana tohum üretin.

Adım 4: Solana Anahtarının Türetilmesi¶

m/44'/501'/0'/0' türetim yolunu takip edin, her seviyede HMAC-SHA512 alt anahtar türetimi gerçekleştirin. Solana, secp256k1 yerine ed25519 kullandığından, alt anahtar türetimi doğrudan BIP32 değil, ed25519 anahtarlarının hiyerarşik olarak nasıl türetileceğini belirten SLIP-0010 standardını kullanır.

Yolun sonundaki çıktı 32 baytlık bir ed25519 tohumudur.

Adım 5: Anahtar Çiftinin Oluşturulması¶

32 baytlık tohumu ed25519 anahtar üretimine besleyin:

1. 64 bayt elde etmek için tohumun SHA-512'sini hesaplayın.
2. Alt 32 bayta bit kırpma uygulayın (en düşük 3 biti temizleyin, en yüksek biti temizleyin, ikinci en yüksek biti ayarlayın).
3. 32 baytlık açık anahtarı elde etmek için taban noktası B'yi kırpılmış skaler ile çarpın.

Anahtar çifti, 64 baytlık genişletilmiş özel anahtar (tohum + açık anahtar) ve 32 baytlık açık anahtardan oluşur.

Adım 6: Adresin Kodlanması¶

32 baytlık açık anahtar, insan tarafından okunabilir Solana adresini üretmek için Base58 ile kodlanır. Ek hashleme yok, önek baytı yok --- yalnızca açık anahtar baytlarının ham Base58 kodlaması.

Bu akışın tamamını SafeSeed'in Solana Özel Anahtar Oluşturucusu kullanarak oluşturabilir ve inceleyebilirsiniz; bu araç tohum cümlesini, türetim yolunu, özel anahtarı, açık anahtarı ve nihai adresi gösterir.

Base58 Adres Formatı¶

Solana adresleri Base58 kodlaması kullanır --- Bitcoin'in eski adreslerinde kullanılan aynı Base58 alfabesi, görsel olarak kafa karıştırıcı karakterleri hariç tutar: 0 (sıfır), O (büyük o), I (büyük i) ve l (küçük L).

Tipik bir Solana adresi şöyle görünür:

7EcDhSYGxXyscszYEp35KHN8vvw3svAuLKTzXwCFLtV

Özellikler¶

• Uzunluk: 32--44 karakter (genellikle 43--44). Uzunluk değişir çünkü Base58 kodlaması sabit genişlikli değildir; öndeki sıfır baytlar öndeki 1 karakterleri üretir.
• Karakter seti: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
• Önek yok: Bitcoin (1, 3 veya bc1 ile başlar) veya Ethereum (0x ile başlar) aksine, Solana adreslerinin sabit bir öneki yoktur. Bu, görsel tanımlamayı zorlaştırır ancak adresleri kısa tutar.
• Gömülü sağlama toplamı yok: Base58Check (Bitcoin eski adreslerinde kullanılır) aksine, Solana'nın Base58 kodlaması bir sağlama toplamı içermez. Bir yazım hatası, başka birine ait veya hiç kimseye ait olmayan geçerli görünen bir adres üretebilir.

Sağlama toplamının olmaması dikkatli işlemeyi zorunlu kılar. Her zaman manuel yazım yerine kopyala-yapıştır kullanın. Mümkün olduğunda QR kodları kullanın. Ve herhangi bir fon göndermeden önce Solana Adres Doğrulayıcı kullanarak adres formatını doğrulayın. Blokzincirler arasında adres formatlarının daha geniş bir karşılaştırması için Crypto Address Formats Explained yazısına bakın.

Solana İçin Güvenlik Hususları¶

Anahtar güvenliğinin genel ilkeleri, herhangi bir blokzincir için olduğu gibi Solana için de geçerlidir, ancak Solana'ya özgü birkaç faktör özel ilgiyi hak eder.

Çevrimdışı Oluşturma Kritiktir¶

Solana adreslerinde gömülü sağlama toplamı olmadığından, oluşturma sırasındaki hatalar tespit edilmesi daha zordur. Cüzdanınızı çevrimdışı olarak --- ağ bağlantısı olmayan bir makinede --- oluşturmak, sızdırma riskini ortadan kaldırır ve çıktıyı dikkatli bir şekilde doğrulamak için kontrollü bir ortam sağlar. SafeSeed'in araçları bunun için tasarlanmıştır: sayfayı yükleyin, bağlantıyı kesin, oluşturun ve kaydedin. Genel çevrimdışı oluşturma ilkeleri için Online Seed Generator Safety yazısına bakın.

Anahtar Çifti Dosyaları¶

Solana CLI, özel anahtarları tipik olarak id.json olarak adlandırılan dosyalarda 64 baytlık JSON dizileri (ed25519 anahtar çifti) olarak saklar. Cüzdanınızı bir GUI'den dışa aktarıp CLI'ye (veya tam tersi) aktarıyorsanız, bu formatla karşılaşabilirsiniz. Anahtar çifti dosyalarını tohum cümleleriyle aynı titizlikle koruyun: şifreleyin, hava boşluklu ortamda saklayın ve asla ağa bağlı makinelerde bırakmayın.

Token Hesapları¶

Ethereum'da ERC-20 tokenlarının ETH ile aynı adreste tutulmasından farklı olarak, Solana ilişkili token hesapları (ATA'lar) kullanır --- her token türü için ayrı zincir üstü hesaplar. Bu bir uygulama detayıdır, bir anahtar güvenlik sorunu değildir, ancak Solana adresinizin tek başına varlıklarınızın tam hikayesini anlatmadığı anlamına gelir. Belirli bir cüzdan adresinden türetilen tüm ATA'lar aynı özel anahtar tarafından kontrol edilir, bu nedenle tohum cümlesi yedeğiniz yine de yeterlidir.

Program Türetilmiş Adresler (PDA'lar)¶

Solana'nın programlama modeli, bir program kimliği ve bir tohum kümesinden deterministik olarak oluşturulan ve kasıtlı olarak karşılık gelen bir özel anahtarı olmayan Program Türetilmiş Adresler kullanır. PDA'lar akıllı sözleşmeler (programlar) tarafından zincir üstü durumu yönetmek için kullanılır. PDA'ları oluşturmanız veya yedeklemeniz gerekmez; bunlar kullanıcı kontrollü cüzdanlar değildir.

Dayanıklı Nonce'lar ve İşlem İmzalama¶

Solana işlemleri, tekrar koruması için yakın zamanlı bir blok hash'i içerir, bu da işlemlerin yaklaşık 60--90 saniye sonra sona erdiği anlamına gelir. Bu, çevrimdışı imzalama iş akışları için önemlidir: çevrimiçi bir makinede yakın zamanlı bir blok hash'i (veya dayanıklı bir nonce) almanız, imzalama için çevrimdışı makineye aktarmanız ve ardından blok hash'i sona ermeden imzalı işlemi yayınlamanız gerekir. Donanım cüzdanları bunu otomatik olarak yapar, ancak özel bir çevrimdışı imzalama sistemi oluşturuyorsanız, zamanlama kısıtlaması önemli bir tasarım hususudur.

Özel Anahtar Güvenliği En İyi Uygulamaları¶

Temel ilkeler zincirden bağımsız olarak aynı kalır: tohum cümlenizi asla paylaşmayın, ağa bağlı bir cihazda dijital olarak asla saklamayın ve önemli varlıklar için soğuk depolama kullanın. Kapsamlı bir inceleme için Private Key Security Best Practices yazısına bakın.

Solana'nın cüzdan oluşturma süreci kavramsal olarak Bitcoin ve Ethereum'a benzer --- entropi tohum cümlesine, tohum cümlesi ana anahtara ve türetim yolları bireysel hesaplara dönüşür. Ancak altta yatan eğri (ed25519), türetim standardı (SLIP-0010) ve adres formatı (sağlama toplamı olmayan ham Base58), birlikte çalışabilirlik, kurtarma ve güvenlik için önemli olan farklı bir uygulama detayları seti oluşturur. Bu farkları anlamak akademik değildir; Solana varlıklarınızı korumanın temelidir.