Bir cüzdan adresi basit bir şey gibi görünür: kopyaladığınız, yapıştırdığınız ve para gönderdiğiniz bir dizgi. Bitcoin'de neredeyse o kadar basittir. Solana'da ise bir adresin arkasına paylaşılan bir cüzdanı — bir multisig'i — koymak şaşırtıcı derecede zordur. Bu makale nedenini açıklıyor ve serinin geri kalanının yanıtladığı soruyu ortaya koyuyor.
Bir multisig adresinin söz vermesi gereken şeyler
Multisig cüzdan, birden fazla anahtarla denetlenen, para hareket etmeden önce bunlardan sabit bir sayıda olanın anlaşması gereken bir cüzdandır. Örneğin bir "3'te 2" multisig'in üç anahtarı vardır ve bir ödemeyi onaylamak için herhangi ikisinin onayını gerektirir. Amaç tek hata noktalarını ortadan kaldırmaktır: bir anahtarı kaybedersiniz veya bir anahtar çalınır, paranız yine de güvende kalır.
Bunun faydalı olması için adresin iki sözü tutması gerekir. Birincisi, önceden bilinebilir olmalıdır — herhangi bir kurulumu bitirmeden önce birine bir yatırma adresi vermek istersiniz. İkincisi, dürüst olmalıdır: o adrese para gönderen herkes, yalnızca üzerinde anlaşılan anahtar grubunun, üzerinde anlaşılan kurala göre, oradan harcayabileceğine güvenebilmelidir. Bu iki sözü aklınızda tutun. Aşağıdaki her şeyin can damarıdırlar.
Bitcoin'de adres, kuraldır
Bitcoin bunu kolay gösterir. Bir Bitcoin multisig'i küçük bir betikle tanımlanır: açık anahtarların listesi artı "N'de M" kuralı. Adresi elde etmek için o betiği alır ve özetini (hash) çıkarırsınız. Adres (bir P2WSH adresi) tam anlamıyla harcama kurallarının özetidir.
Bunun sessizce güçlü bir sonucu vardır. Herhangi biri, tek bir işlem yayınlanmadan önce, internetsiz bir dizüstü bilgisayarda adresi çevrimdışı hesaplayabilir. "Cüzdanı oluştur" adımı yoktur — cüzdanın para alabilmesi için ağda var olması gerekmez. Betik yalnızca daha sonra, fonlar harcanırken açığa çıkar ve ağ, açığa çıkan betiğin adrese uyduğunu ve yeterli geçerli imza bulunduğunu denetler. Adres önceden bilinebilir mi: evet. Dürüst mü: evet — çünkü adres kuralın kendisinden türetilir, farklı bir anahtar kümesi farklı bir adres üretir.
Solana'da adres, oluşturulması gereken bir hesaptır
Solana farklı çalışır. Solana'da her şey bir hesaptır — sahibi olan, zincir üstü bir depolama yuvası. Fonlarınız hesaplarda yaşar, programlar hesaplarda yaşar ve bir multisig'in yapılandırması da bir hesapta yaşar. Önemlisi, hesaplar bedavaya ortaya çıkmaz. Bir hesabın açıkça oluşturulması ve ödenmesi gerekir: birisi, ağın verilerini saklaması için onu "kira" denen küçük bir miktar SOL ile fonlar.
Solana'da bir multisig bu yüzden yalnızca bir adres değildir — üye listesini ve eşiği tutan, programla denetlenen bir hesaptır. Ve multisig herhangi bir şey yapabilmeden önce o hesabın bir işlemle oluşturulması gerekir. Zorluğun kökü budur: Solana'daki paylaşılan bir cüzdanın, Bitcoin'in basitçe sahip olmadığı bir kurulum adımı vardır.
PDA'lar: özel anahtarı olmayan adresler
Solana'nın bunun için zarif bir aracı vardır: Program Türevli Adres, kısaca PDA. Normal bir Solana adresinin ona karşılık gelen bir özel anahtarı vardır — anahtarı elinde tutan adresi denetler. Bir PDA bilinçli olarak eğrinin dışında olacak şekilde inşa edilir: geçerli görünen bir adrestir ama hiçbir özel anahtarı yoktur ve olamaz. Kimse onun adına kişisel olarak imza atamaz.
Bunun yerine bir PDA belirlenimci (deterministik) biçimde türetilir. Bazı girdi değerlerini — "tohum" (seed) denir — bir programın kimliğiyle birlikte alır, tek yönlü bir işlevden geçirirsiniz ve adres ortaya çıkar. Aynı tohumlar ve aynı program her zaman aynı PDA'yı üretir, böylece herkes onu yeniden üretebilir. Ve özel anahtar olmadığı için, o adres için eylemleri yalnızca sahip program yetkilendirebilir; bunu invoke_signed ile programlar arası çağrı denen bir mekanizmayla yapar: program tohumları Solana çalışma zamanına sunar, çalışma zamanı da ona PDA için imza yetkisi verir. Asla kriptografik bir imza üretilmez — eylem hakkı, bir anahtara sahip olmaktan değil, tohumları bilmekten gelir.
Bir PDA, bir multisig için tam doğru evdir: tek bir kişi tarafından değil, program mantığı tarafından denetlenen bir adres. Şimdiye kadar sorun yok. Zor olan kısım, tohum olarak neyin seçildiğidir.
Oluşturmadan önce fonlama sorunu
Solana'nın baskın multisig'lerinin tökezlediği yer burasıdır. Bitcoin'in belirlenimci modelinin aksine, en yaygın kullanılan Solana multisig'leri — Squads V4 önde gelen örnektir, olgun ve yoğun denetlenmiş — multisig'in adresini, üye kümesinden değil, oluşturma anında seçilen yeni üretilmiş rastgele bir değerden türetir. Squads V4'te bu değere create_key denir; bir oluşturucu, oluşturma işlemini çalıştırdığında üretilen geçici bir anahtardır.
Adresi rastgele bir create_key'den türetmek bilinçli, makul bir tasarım seçimidir — iki farklı grubun tam olarak aynı üye bileşimini istediği rahatsız edici bir kenar durumunu atlatır. Ama net biçimde anlamaya değer iki sonucu vardır:
- Adresi önceden bilemezsiniz. Tohum, biri oluşturma işlemini çalıştırana kadar yoktur, dolayısıyla adres de yoktur. Bir yatırma adresi yazdırıp kurulumdan önce fonlamanın hiçbir yolu yoktur — oluşturmadan önce fonlama sorunu. İlk söz kırılır.
- Oluşturucu, kurulum sırasında tek bir güven noktasıdır. O oluşturma işlemini belirli bir hesabın çalıştırması ve o rastgele değeri seçmesi gerekir. Kurulumun kısa penceresi boyunca o tarafın bunu doğru yapacağına güvenirsiniz.
Bunların hiçbiri Squads V4'ü güvensiz kılmaz — Solana'nın en çok savaş görmüş multisig'idir ve çok büyük meblağları korur. Bu yalnızca Bitcoin'inkinden farklı bir güven biçimidir. Adres artık "kuralın özeti" değildir; "oluşturma işleminin neyi ürettiyse o" olur.
Ethereum bir orta yol buldu
Ethereum benzer bir sorunla karşılaştı ve buna CREATE2 adlı bir özellikle yanıt verdi. Bu özellik, sabit girdilerden yola çıkarak bir akıllı sözleşmenin adresini sözleşme dağıtılmadan önce hesaplamanıza olanak tanır. Safe gibi cüzdanlar bunu, size sözde bir karşı-olgusal adres vermek için kullanır: paylaşabileceğiniz ve üzerinde para alabileceğiniz gerçek, fonlanabilir bir adres; bu sırada asıl sözleşme tembel biçimde dağıtılır — yalnızca fonların ilk kez hareket etmesi gerektiğinde. Daha yeni hesap soyutlama standardı ERC-4337, aynı fikri biçimselleştirir. Ethereum böylece, tıpkı Solana gibi sonunda zincir üstü bir nesneye ihtiyaç duysa da, "önceden bilinebilir" sözünü geri kazanır.
Bu serinin yanıtladığı soru
Üç modeli yan yana koyun. Bitcoin: adres, kuralın özetidir — çevrimdışı bilinebilir, yapısı gereği dürüst, oluşturma adımı yok. Ethereum: bir karşı-olgusal adres — önceden bilinebilir, dağıtımı ertelenmiş. Solana'nın genel multisig'leri: adres, oluşturma anının rastgeleliğinden gelir — önceden bilinemez, kurulumda güvenilecek bir oluşturucuyla.
İşte soru burada. Solana hesaplara ihtiyaç duyar ve hesapların oluşturulması gerekir — bu ortadan kalkmıyor. Ama bir Solana multisig'i Bitcoin özelliğinden vazgeçmek zorunda mı? Adres bunun yerine, çevrimdışı bilinebilir, kurulumdan önce fonlanabilir ve farklı bir anahtar grubu farklı bir adres ürettiği için dürüst olacak şekilde, yalnızca üye kümesinden ve eşikten — kuralın kendisinden — türetilemez mi?
İşte tam da SSP ekibinin kendi Solana multisig programına yerleştirdiği özellik budur. Sonraki makale bunun nasıl olduğunu gösteriyor: üye kümesinin kendisi olan bir adres, zincir üstünde hiçbir şey kaydedilmeden önce fonlayabileceğiniz bir kasa ve hiç oluşturucuya gerek duymayan bir kayıt adımı. Tasarım, SSP Wallet'ta Solana desteğiyle birlikte yayımlandı — sürüm duyurusuna bakın — ve SSP'nin güvenliğe yaklaşımına uygun olarak program şu anda yalnızca devnet'te ve mainnet'ten önce harici bir denetim bekliyor. Multisig'in kendisi sizin için hâlâ yeniyse, multisig nedir ve neden önemlidir ile başlayın; değilse okumaya devam edin.
