Tokenleştirilmiş RWA için Soğuk Depolama, Multisig ve MPC

Varlık düz ETH değil de tokenlaştırılmış bir RWA olduğunda ne değişir

Saklama sorusu ilk bakışta aynı görünür: özel anahtarınız vardır, onu güvende tutmak istersiniz, işlemleri imzalamak istersiniz. ONDO'nun OUSG'si, BlackRock'ın BUIDL'ı veya Mantle'ın MNT cinsinden hazine ürünleri gibi tokenlaştırılmış gerçek dünya varlıkları (RWA) kriptografiyi değiştirmez. Değiştirdikleri şey, bunun üzerine oturan iş yüküdür.

Tokenlaştırılmış bir para piyasası fonu veya hazine fonu genellikle belirli bir takvimle ihraç ve geri alım yapar. Örneğin OUSG, geri alımları T+1'de sonuçlandırır. BUIDL getiriyi sürekli dağıtır ve ihraççı üzerinden geri alıma ek olarak token düzeyinde transferleri destekler. Bu tempo, bir hazine ekibinin uzun vadeli bir BTC sahibinin yapabileceği gibi tek bir imzalanmamış işlemi bir hafta bekletemeyeceği anlamına gelir. İmzalayan kuyruğunun bir iş günü içinde, çoğu zaman bir geri alım penceresi kapanıyorsa bir saat içinde temizlenmesi gerekir.

İkinci değişiklik denetlenebilirliktir. Sade ETH için zincir üstü kayıt genellikle bir iç finans ekibi için yeterlidir. Düzenlemeye tabi bir RWA söz konusu olduğunda ise zincir dışı tarafta denetçiler, transfer acenteleri ve bazen de bir geri alımın belgelenmiş bir politika kapsamında adı belli insanlar tarafından yetkilendirildiğine dair kanıt isteyecek bir düzenleyici bulunur. Bu gereklilik saklamayı yeniden şekillendirir, çünkü "kim imzaladı" sorusu "imza geçerli" olması kadar önemlidir.

Üçüncü değişiklik, operasyonel anahtarın nadiren tek anahtar olmasıdır. Çoğu RWA ürünü bir politika anahtarını, günlük operasyon anahtarını ve guardian anahtarını ayırır ve her biri farklı kontroller altında tutulur. Bunları tek bir imzalama problemi olarak ele almak, birçok hazine tasarımının hata yaptığı noktadır.

Operasyonel gecikme ile saldırgan maliyeti arasındaki denge

Saklama tek bir karar değildir, iki sayı arasındaki bir dengedir. İlki, işletme ihtiyaç duyduğunda geçerli bir imza üretmenin ne kadar sürdüğüdür. İkincisi, bir saldırganın sahte bir imza üretebilmeden önce ne kadar harcama yapması gerektiği veya kaç bağımsız arızayı tetiklemesi gerektiğidir.

Katı anlamıyla soğuk depolama, saldırgan maliyeti sayısını çok yükseğe taşır ve gecikme sayısını da onunla birlikte yükseltir. Anahtar internete hiç temas etmemiş bir cihazda, ideal olarak bir kasada tutulur ve imzalama onu fiziksel olarak geri almayı gerektirir. Bu, uzun vadeli bir BTC hazinesi için harikadır, ancak her iş günü ONDO veya BUIDL geri alımı yapmak zorunda olan bir fon için zahmetlidir. Yavaş olmanın maliyeti soyut değildir: kaçırılan geri alım pencereleri ceza ücretlerini tetikleyebilir, sizi bir sonraki döngüye atabilir veya aşırı durumlarda pozisyonu ihraççının bir sonraki kesim zamanına kadar kilitleyebilir.

Multisig, güveni imzalayanlar ve cihazlar arasında dağıtarak dengeyi değiştirir. 3-of-5 kurulumu, bir saldırganın üç bağımsız imzalayanı ele geçirmesini gerektirir, bu tek bir imzalayanı ele geçirmekten anlamlı ölçüde daha zordur, gecikme ise en hızlı üç imzalayanınızın hızıdır. Ancak sorun şu ki "bağımsız" kelimesi burada çok iş yapar. İmzalayanlarınızdan üçü aynı kişi tarafından, aynı işletim sisteminde ve aynı yedekleme düzeniyle yönetiliyorsa, multisig size üç saldırganlık zorluk kazandırmamıştır. Size bir tane kazandırmıştır.

MPC, yani GG20, GG20+, Lindell17 veya daha yeni FROST uygulamaları gibi eşik imza şemaları, saldırgan maliyeti hesaplamasını protokolün içine taşır. İmzalama anahtarı hiçbir zaman tek bir yerde var olmaz. Her katılımcı bir pay tutar ve bunların bir eşiği, tam anahtarı asla yeniden oluşturmadan birlikte bir imza üretir. Gecikme çok düşük olabilir, tek imzalayanlı bir hot wallet ile karşılaştırılabilir, saldırganın ise dar bir imzalama penceresi içinde katılımcıların eşik sayısını ele geçirmesi gerekir.

MPC'nin ayrıca yaptığı şey, yeterince gündeme gelmeyen kısım da budur, operasyonel hataların maliyetini düşürmesidir. Multisig ile bir imzalayanı kaybetmek can sıkıcıdır ancak eşiğin üzerinde kaldığınız sürece telafi edilebilir. MPC ile kurtarma hikayesi tamamen payların nasıl oluşturulduğuna, onları kimin tuttuğuna ve saklama kuruluşunun hâlâ var olup olmadığına bağlıdır. Bir dizüstü bilgisayarı silerseniz ve pay yalnızca o dizüstü bilgisayardaysa, politika basitçe kurtarılamaz hale gelebilir ve varlık, altta yatan anahtar payı töreni kalan katılımcılarla yeniden yürütülene kadar fiilen donar.

Kurumsal RWA saklayıcıları neden tüketici tipi donanım cüzdanları değil HSM kullanır?

Ledger, Trezor, GridPlus veya Keystone olsun, tüketici tipi bir donanım cüzdanı bir seed saklayan ve işlemleri çevrimdışı imzalayan küçük bir güvenli öğe cihazıdır. Kişisel bir BTC birikimi veya beş haneli bir ETH pozisyonu için mükemmeldir. Ancak kurumsal bir RWA defterinde itfaları operasyonel olarak imzalayan bir hazine için eksikler birikmeye başlar.

İlk eksik, anahtar dışa aktarma ve klonlamadır. Donanım cüzdanları, seed üzerinde cihaz üreticisinin değil kullanıcının kontrol sahibi olacağı şekilde tasarlanır. Kurumsal açıdan bu bir yükümlülüktür: seed ifadesine ve kiralık kasadaki bir yedeğe sahip ayrılan bir çalışan, kolayca gideremeyeceğiniz bir kilit kişi riskidir. Kurumsal saklayıcılar, yazılı bir politikaya göre döndürebilecekleri, emanete alabilecekleri veya yok edebilecekleri anahtarlar ister ve bu sürecin baştan sona denetlenebilir olmasını ister.

HSM'ler, yani donanım güvenlik modülleri, tam olarak bunun içindir. AWS CloudHSM, Thales Luna, Utimaco veya YubiHSM 2 gibi cihazlar FIPS doğrulamalıdır, rol tabanlı erişimi destekler ve her imzalama denemesini, kimin başlattığını ve hangi kural kapsamında yapıldığını kaydeden politika motorlarıyla entegre olur. Anahtarlar cihazdan hiçbir zaman düz metin olarak çıkmaz, anahtar rotasyonu belgelenmiş bir iş akışıdır ve denetçi temiz bir iz görebilir.

İkinci eksik, neyin imzalandığıyla ilgilidir. Tüketici tipi bir donanım cüzdanı size küçük bir ekranda işlem gösterir ve onaylamanızı ister. OUSG veya BUIDL ile çalışan bir hazine ekibi, imzalayan kişi işlemi görmeden önce politikayı uygulamak zorundadır: varlık başına limitler, izin listesine alınmış karşı taraflar, günlük itfa tavanları, eşiğin üzerindeki her şey için çift kontrol. Bu mantığın yeri, 128x64 piksellik bir ekrana bakan bir insan değil, bir işlem politikası motoru veya modüllere sahip Safe (eski adıyla Gnosis Safe) gibi bir akıllı hesap katmanıdır.

Üçüncü eksik operasyonel iş hacmidir. Donanım cüzdanı ara sıra kullanım için tasarlanmıştır, getiri süpürmeleri, ücret ödemeleri, oracle onayları ve mutabakat kayıtları dahil edildiğinde günlük bir RWA akışının üretebileceği onlarca onay için değil. Güvenlikten çok önce kullanım ergonomisi çöker.

Her şey yolundaymış gibi görünen ama sonra sorun çıkaran multisig kurtarma tuzakları

ETH üzerinde multisig en yaygın olarak, imzalayanları donanım cüzdanlarında tutulan ve belgelenmiş bir kurtarma senaryosu bulunan bir Safe (eski adıyla Gnosis Safe) cüzdanı olarak dağıtılır. Teoride sağlamdır. Pratikte ise üç tuzak tekrar tekrar ortaya çıkar.

İlki imzalayan homojenliğidir. Dokuz imzalayanın da aynı cüzdan yazılımını, aynı firmware sürümünü, aynı yedekleme prosedürünü kullandığını ve üçünün aynı kişi tarafından aynı öğleden sonra kurulduğunu fark edene kadar 5-of-9 güvenli görünür. Multisig'in güvenliği, imzalayanların bağımsızlığıyla ölçeklenir. 9 sayısı süs niteliğindedir. Önemli olan sayı, gerçekten bağımsız ele geçirilme vektörlerinin sayısıdır.

İkincisi imzalayan erişilebilirliğidir. Bir multisig ancak eşiğe ulaşabiliyorsanız çalışır. İmzalayanlarınız üç saat dilimindeki yüklenicilerden, seyahat eden bir yöneticiden ve erişim için iki gün gerektiren bir kasada duran bir cüzdandan oluşuyorsa, en hızlı beş imzalayanınızdan üçü uçaktayken zaman açısından kritik bir ONDO itfasını imzalayamayacak durumda kalabilirsiniz. Çözüm genellikle cold ve warm imzalayanların bir kombinasyonudur, hot imzalayanların yalnızca küçük tutarları onaylayabileceğini söyleyen bir politikayla birlikte. Bu işe yarar, ancak yönetilecek bir multisig daha ekler ve yine özyineleme sorununa dönersiniz.

Üçüncüsü kurtarma anahtarı saklamasıdır. Her Safe'in bir kurtarma senaryosu vardır ve bu genellikle imzalayanların nasıl oluşturulduğunun bir işlevidir. Kurtarma, kasada kağıda yazılmış bir seed ifadesine dayanıyorsa, artık ele geçirilmesi saldırgana çalışan bir imzalayan veren tek bir kağıt parçasına sahipsiniz. Kurtarma, guardians üzerinden sosyal kurtarmaya dayanıyorsa, güveni guardians'a kaydırmış olursunuz ve beş yıl sonra onların düşündüğünüz kişiler olmayabilir. Bunların hiçbiri tek başına işi durduracak türden değildir, ancak her biri düzgün görünen 3-of-5 yapısının sessizce, bir imzalayanı çekmecede olan bir 2-of-5'e dönüştüğü bir noktadır.

MPC anahtar payı kaybolma riski, sade anlatımla

MPC'nin tanımlayıcı özelliği, tam anahtarın hiçbir zaman tek bir yerde bulunmamasıdır ve bu aynı zamanda tanımlayıcı riskidir. İmzalama politikası katılımcılarda yaşar ve katılımcılar ortadan kaybolabilir.

Tedarikçi kaybolması en çok dile getirilen risktir. Fireblocks, Anchorage, BitGo, Fordefi veya benzer bir MPC sağlayıcısıyla saklama yapıyorsanız, paylarınız sizinle onlar arasında bölünür. Tedarikçi satın alınırsa, piyasadan çıkarsa, ciddi bir kesinti yaşarsa veya hizmet katmanınızı basitçe kullanımdan kaldırırsa, varlıklarınızı taşıyabilirsiniz, ancak yalnızca taşıma araçları mevcutsa ve zamanınız varsa. En kötü durumda, siz bir pay tutarsınız, tedarikçi bir pay tutar ve tedarikçi tarafı çevrimdışı ya da isteksiz olduğu için eşik artık ulaşılamaz hale gelir.

Katılımcı cihaz kaybı bir sonraki risktir. MPC payları genellikle HSM'lerde, özel imzalama düğümlerinde veya güçlendirilmiş dizüstü bilgisayarlarda tutulur. Her cihazın, payların nasıl ve nerede yedeklendiği dahil olmak üzere kendi anahtar saklama hikayesi vardır. Bu cihazlardan ikisini kaybederseniz, elinizde yalnızca bir rahatsızlık değil, bir kurtarma sorunu olur. Azaltım yöntemi pay yedeklemesidir, ancak pay yedeklemesi de başlı başına bir saklama kararıdır: yedek paylar nerede durur, bunları kim çözebilir ve hiçbir kişinin yedeklerden anahtarı yeniden oluşturamayacağını bir denetçiye nasıl kanıtlarsınız?

Protokol ve uygulama riski üçüncü risktir. Eşik imza şemaları karmaşık kriptografidir ve uygulamalarda hatalar görülmüştür. 2022'de belirli GG20 uygulamalarındaki bir güvenlik açığına ilişkin açıklama, threshold EdDSA etrafındaki daha yeni bulgular ve cüzdan SDK'lerindeki düzenli sorun akışı, "anahtar hiçbir zaman var olmaz" iddiasının "anahtar hiçbir zaman var olmaz ve imzalama kodu hatasızdır" iddiasından daha güçlü olduğunu hatırlatır. Bir RWA hazine operasyonu için doğru hamle, MPC sağlayıcısının yığınına ilişkin bağımsız güvenlik denetimleri istemek ve pahalı olsa bile farklı bir şemaya geçme seçeneğini açık tutmaktır.

Adını koymaya değer bir nüans var: MPC'nin güvenliği imzalama olayı başınadır. Katılımcıların eşiği imza attığında, katılımcı payları daha sonra yok edilse bile imza sonsuza kadar geçerlidir. Bu nedenle kaybolma riski geçmiş imzalarla değil, gelecekteki imzalama kapasitesiyle ilgilidir. Bir yönetim kuruluna götürülmesi gereken doğru çerçeve budur: geçmiş bir işlemin sahte olarak oluşturulması riski altında değiliz, pozisyonu işletememe riski altındayız.

Günlük itfalı RWA için pratik bir saklama yığını

İş yükü dikkate alındığında, tokenleştirilmiş RWA tutan bir fon veya protokol hazinesi için uygulanabilir kurulum saf olmaktan çok katmanlı görünür.

Temel katman, uzun vadeli rezerv için FIPS doğrulamalı HSM'lere sahip kurumsal bir saklayıcıdır. Pozisyonun büyük bölümü burada, rol ayrımıyla politika kontrollü imzalama altında durur. Sık hareket etmesi gerekmeyen bir OUSG veya BUIDL tahsisi için doğru yer burasıdır, çünkü kasaya girmenin gecikme maliyeti nadiren ödenir ve saldırgan maliyeti çok yüksektir.

Çalışma katmanı, rutin operasyonlar için kullanılan bir multisig Safe veya bir MPC kümesidir: küçük itfalar, getiri süpürmeleri, ücret ödemeleri, oracle onayları. Burada multisig ile MPC arasındaki seçim, imzalama hacmine, imzalayan dağılımına ve ekibin operasyonel risk toleransına bağlıdır. Multisig'i denetlemek daha kolaydır ve ondan kurtarmak daha kolaydır. MPC daha hızlıdır ve yüksek imzalama hacimlerini daha iyi yönetir. Birçok ekip ikisini de kullanır: yönetişim için bir Safe ve yürütme için daha küçük bir MPC kümesi.

Politika katmanı ikisinin de üzerinde yer alır. Bir işlem politikası motoru varlık başına limitleri, izin listesine alınmış sözleşmeleri, günlük tavanları ve çift kontrol kurallarını uygular. İmzalayanlar ham işlemleri görmez; önceden onaylanmış niyetleri görürler ve motor gerçek işlemleri oluşturup gönderir. Operasyonel riskin büyük kısmı aslında burada kontrol edilir ve tüketici tipi donanım cüzdanlarının kurumsal kullanımda yetersiz kaldığı yer de burasıdır, çünkü bu politikayı imzalayanın önünde uygulayamazlar.

Cold rezerv katmanı, yönetişim ve politika değişiklikleri için air-gapped bir multisig'dir: imzalayanları değiştirmek, anahtarları döndürmek, politika motorunu yükseltmek, çalışma katmanından büyük tutarları çıkarmak. Bu olaylar nadir olduğu için buradaki gecikme kabul edilebilir ve anahtarlar bir kasada yaşadığı için saldırgan maliyeti çok yüksektir.

Dürüst özet şudur: kurumsal RWA için "cold storage vs multisig vs MPC" yanlış çerçevedir. Doğru çerçeve, hangi iş yükünün hangi katmana gittiği ve bir pay, bir imzalayan veya bir tedarikçi ortadan kaybolduğunda kurtarma hikayesinin ne olduğudur.

RWA saklama gelişmelerini akıllı şekilde nasıl takip edersiniz

RWA saklama alanı hızlı ilerler, çünkü ürünler, saklayıcılar ve düzenleyiciler aynı anda değişmektedir. OUSG itfalarını, BUIDL dağıtım mekaniklerini, MPC sağlayıcı geçişlerini ve HSM firmware uyarılarını elle takip etmek kaybedilecek bir oyundur. Zippfeed, tokenleştirilmiş RWA haber başlıklarını duyarlılık puanlamasıyla (bullish, neutral veya bearish) ve önem derecelendirmesiyle öne çıkarır, böylece gürültüde boğulmak yerine saklama tasarımınızı gerçekten etkileyen olaylara odaklanabilirsiniz.