Multisig cüzdanlar: M-of-N onayıyla fonlar nasıl hareket…

Multisig cüzdanlar açıklandı: çoklu imza cüzdanı, en az M adet N yetkili anahtarın aynı işlemi onaylaması durumunda fon gönderir, tek bir özel anahtara güvenmek yerine. Bu tasarım, saklama işlemini bir işletim modeline dönüştürür; bir teklif ve inceleme akışı, ücret lojistiği ve fonları güvenli tutabilecek veya onları sıkışmış bırakabilecek zincir özel uygulama seçimleri ile.

Anahtar Çıkarımlar

• Bir multisig cüzdanı, genellikle 2'den 3'e veya 3'ten 5'e gibi m of n eşiği kullanarak bir işlemi yetkilendirmek için iki veya daha fazla özel anahtar gerektirir.
• Temel iş akışı bir onay hattıdır: bir imzalayıcı bir işlem önerir, diğer imzalayıcılar imzalar ekler, cüzdan eşiği kontrol eder, ardından işlem yayınlanır.
• Bir protokole (örneğin, BitcoinP2SH), farklı davranır akıllı sözleşme cüzdanı çoklu imza üzerinde Ethereum (Safe cüzdan gibi), sözleşme riski ve dapp uyumluluğu ERC-1271 aracılığıyla.
• Çoklu imza ve mpc “paylaşılan kontrolü” farklı şekilde çözer: çoklu imza, belirli anahtarlara bağlı bir on-chain onay izi bırakırken, MPC, tam bir anahtar oluşturmadan off-chain hesaplama yoluyla imzalar üretir.

Multisig cüzdanlar anahtar kontrolünü nasıl değiştirir

Tek imza cüzdanı, yetkiyi tek bir özel anahtarda toplar; bu da bir ihanet veya kaybolan bir anahtarın terminal olabileceği anlamına gelir. Multisig, yetkiyi birden fazla anahtar arasında bölerek ve fonların hareket etmeden önce belirli bir onay eşiği gerektirerek bu kontrol yüzeyini değiştirir. Bu nedenle multisig, cüzdan güvenliği tartışmalarında ve daha geniş kripto cüzdan türlerinin açıklandığı konuşmalarda bu kadar sık karşımıza çıkar. Bu sadece "daha fazla anahtar" değildir. Bu, kimin neyi yetkilendirebileceğine dair bir kural setidir.

Önemli zihinsel model yönetişimdir, kriptografi değil. Çoklu imza (multisig) kurulumu, bir ekibin, ailenin veya bir grup insanın onay politikasını kodlar.DAOzaten davranır. Gerçek süreç “iki kişi onaylamalı” ise, 2-of-2 niyeti karşılar ama herhangi bir imzalayan kaybolursa ciddi bir kesinti riski yaratır.

Gerçek süreç “iki kişi imzalamalı, ancak bir kurtarma yolu olmalı” ise, 2-of-3 yaygın varsayılan yöntemdir çünkü bir eksik anahtara tolerans gösterirken tek taraflı kontrolü engeller.

Multisig, aynı zamanda saklama spektrumunda belirli bir yerde durmaktadır. Bu hala birnon custodial cüzdanimzacıların anahtarları kontrol ettiği ve hiçbir üçüncü tarafın fonları tek taraflı olarak hareket ettiremeyeceği bir model. Fark, “sahip”in artık tek bir kişi değil, bir grup politikası olmasıdır. Bu politika, bir zincir tarafından yerel olarak uygulanabilir veya akıllı sözleşme zincirlerinde bir sözleşme ile zorlanabilir. Bu uygulama seçimi, birçok operasyonel sürprizin kaynağıdır.

M-of-N modeli ve iş akışları

Eşik kuralı tüm oyundur: N, yetkilendirilmiş anahtarların toplam sayısıdır ve M, bir işlemi onaylamak için gereken minimum imza sayısıdır. Yaygın yapılandırmalar, gerçek onay süreçlerine temiz bir şekilde karşılık gelir: Eşit ortaklar için 2-of-2, yedek anahtara sahip küçük ekipler için 2-of-3 ve yoklukları sürdürebilen komite tarzı kontrol için 3-of-5.

İş akışı önemlidir çünkü çoklu imza, fonlar hareket ettiğinde her seferinde çalışan bir onay boru hattıdır. Tipik bir akış, sıralı bir diziyi takip eder:

1. Bir işlem teklifi oluşturun. Yetkili bir imzalayıcı, hedefi, adres, miktarı ve herhangi bir çağrı verisini taslak haline getirir. 2. İmzaları toplayın. Diğer yetkili imzalayıcılar teklifi gözden geçirir ve kendi özel anahtarlarıyla imzalar. 3. Eşiği doğrulayın. Cüzdan, en az M geçerli imzalayıcı onayının mevcut olduğunu kontrol eder. 4. Yayınlayın ve yürütün. Tamamen onaylanmış işlem, onay için ağa gönderilir.

İki operasyonel detay, çoklu imzanın “güvenli” mi yoksa “takılmış” mı hissettireceğini belirleme eğilimindedir. İlki imzalayıcıların erişilebilirliğidir: Eğer M imzalayıcı, organizasyonun ihtiyaç duyduğu süre içinde yanıt veremezse, cüzdan bir darboğaz haline gelir. İkincisi ise ücret finansmanıdır.

EIP-86, Ethereum'un tarihindeki somut bir acı noktasını erken bir aşamada belirtmiştir: çoklu imza işlemleri, birden fazla onaylama işlemi gerektirebilir ve katılımcılar bu onayları göndermek için ücretler için ETH'ye ihtiyaç duyabilir. Bu, teorik bir dipnot değildir. Bu, bir ekibin zaman baskısı altında fonları hareket ettirmeye çalışırken ve imzalayıcıların onay için bile ödeme yapamadığını keşfettiğinde ortaya çıkan türden bir sürtünmedir.

Zincir üstü ve akıllı sözleşme çoklu imza

Bitcoin tarzı çoklu imza ve Ethereum tarzı çoklu imza dışarıdan benzer görünebilir, ancak farklı şekilde başarısız olurlar çünkü farklı şekilde inşa edilmiştir. Zincir üstü çoklu imza, Bitcoin P2SH'nin kanonik örneği ile yerel protokol desteğidir. Harcama koşulları, zincirin betimleme kurallarında yer alır. Avantajı, güvenilecek ayrı bir sözleşme kodu olmadığı için daha küçük bir yüzey alanıdır. Dezavantajı, özellik setinin temel protokolün desteklediği ile sınırlı olmasıdır.

Akıllı sözleşme çoklu imzası farklı bir hayvandır. Ethereum ve benzeri zincirlerde, çoklu imza genellikle bir akıllı sözleşme cüzdanıdır ve Safe cüzdan, yaygın olarak kullanılan referans uygulamasıdır. Sözleşme, varlıkları tutar ve onay kurallarını kodda zorunlu kılar. Bu esneklik sağlar, ancak sözleşme riski ve uyumluluk çalışması getirir.

Uyumluluk, Ethereum çoklu imzasının imzalardan daha fazla standartlarla ilgili hale geldiği yerdir. Birçok uygulama, dışarıdan sahip olunan bir hesaptan imzalı bir mesaj bekler. Bir sözleşme, normal bir ECDSA imzası üretemez çünkü özel anahtarı yoktur.

ERC-1271, bunu düzeltmek için el sıkışmadır: “imzalayıcı” bir sözleşme olduğunda uygulamaların çağırabileceği isValidSignature(hash, signature) yöntemini tanımlar ve doğrulama geçerse sihirli değer 0x1626ba7e'yi döndürmeyi gerektirir. Bir dapp ERC-1271'i desteklediğinde, bir sözleşme cüzdanından gelen onayları gerçek yetkilendirme olarak değerlendirebilir.

Desteklemediğinde, çoklu imza, imzalı mesajlara dayanan iş akışlarından engellenebilir, örneğin zincir dışı sipariş sistemleri.

Çoklu imzanın kullanıldığı yerler

Multisig, gerçek gereksinimlerin paylaşılan kontrol ve denetim izi olduğu her yerde ortaya çıkar. Kurumsal ve proje hazineleri, transferler için açık onayları zorlamak amacıyla multisig kullanır, böylece tek bir operatör fonları tek taraflı olarak hareket ettiremez. DAO'lar ve topluluk fonları, özellikle grubun kimin neyi onayladığına dair görünür bir hesap verebilirlik istediğinde, pragmatik bir kontrol katmanı olarak multisig kullanır.

Escrow benzeri düzenlemeler de doğal bir uyum sağlar. 2-of-3 modeli, bir anahtarı alıcıya, birini satıcıya ve birini tarafsız bir hakeme atayabilir. Fonlar yalnızca iki taraf anlaştığında hareket eder, bu da tek bir aracıya güvenme ihtiyacını azaltır. Aynı yapı, hiçbir tarafın diğerinin tek taraflı çekim haklarına sahip olmak istemediği ortaklık fonları için de kullanılabilir.

Kişisel güvenlik kurulumları daha sessiz bir kullanım durumudur ve genellikle yanlış anlaşılır. 2-of-3, anahtarları cihazlar ve konumlar arasında bölüştürebilir veya kurtarma için güvenilir bir yedek ekleyebilir. Amaç karmaşık bir imza ritüeli oluşturmak değildir. Amaç, hata alanlarını ayırmaktır.

Tüm anahtarlar aynı cihaz ekosisteminde yaşıyorsa veya tüm anahtarlar “kolaylık” için aynı kişi tarafından tutuluyorsa, multisig etiketi pazarlama işlevi görmektedir, risk işlevi değil.

Bu, işletim modeli tezinin de devreye girdiği yerdir. Doğru m of n, onay süreciyle ve bir imzalayan kaybolursa kabul edilebilir kesinti süresiyle eşleşen olandır. 2-of-2, bir ortak hesap için mükemmel olabilir, ta ki bir anahtar kaybolana kadar. 3-of-5, grup onaylarının artık planlama gerektirdiğini fark edene kadar süreklilik için mükemmel olabilir.

Güvenlik faydaları ve operasyonel ticaret dengeleri

Multisig'in güvenlik faydası açıktır: bir anahtarın ele geçirilmesi, fonları hareket ettirmek için yeterli değildir. Bu, oltalama, tek bir cihazda kötü amaçlı yazılım veya tek bir içeriden gelen kişinin kötüye kullanımı gibi durumların etkisini azaltır. Ayrıca, onaylar belirgin imzalayan anahtarlarına bağlı olduğu için daha net bir hesap verebilirlik oluşturur ve cüzdanın yürütme geçmişinin bir parçası olarak denetlenebilir.

Ticaret dengeleri çoğunlukla operasyoneldir ve hata modları olarak ortaya çıkar. Koordinasyon belirgin olanıdır, ancak daha maliyetli problemler genellikle prosedürel olanlardır. Gayri resmi inceleme, yanlış yükü imzalamaya, yanlış yere göndermeye veya yanlış nonce'u onaylamaya yol açar. Multisig, bir kontrol listesi kültürü oluşturmayı kolaylaştırır, ancak varsayılan olarak birini zorlamaz.

Ücret lojistikleri diğer tekrar eden tuzaktır. EIP-86, multisig'in birden fazla onaylama işlemi gerektirebileceğini ve katılımcıların ücretler için ETH'ye ihtiyaç duyabileceğini açıkça vurgulamıştır. Bu, her multisig grubunun yanıtlaması gereken bir politika sorusu yaratır: Onaylar için imzalayanları finanse etmekten kim sorumludur ve finanse edilmediklerinde ne olur?

Hesap-sözleşme yaklaşımları, sözleşmenin ETH tutma ve ücretleri ödeme arzusuyla kısmen motive edilmiştir, tam olarak “her imzalayanın gaz ihtiyacı vardır” kırılgan bir işletim varsayımı olduğu için.

Eşik seçimi son ticaret dengesidir ve daha fazla imzalayan eklemekle çözülmez. 2-of-2, karşılıklı kontrolü maksimize eder ancak bir anahtar kaybolursa fonları kalıcı olarak dondurabilir. 2-of-3, yedek bir anahtar aracılığıyla fazlalık eklediği için popülerdir. 3-of-5, yokluklar sırasında sürekliliğin hızdan daha önemli olduğu durumlarda yönetim kalitesindedir.

Daha yüksek N, koordinasyon hatalarını artırabilir, bu da “daha fazla imzalayan” cüzdanın ihtiyaç duyduğunda hareket etme olasılığını azaltabileceği anlamına gelir.

Multisig'in MPC ile karşılaştırılması

Multisig ve mpc, tek anahtar riskini azaltmayı amaçlar, ancak bunu farklı hesap verebilirlik ve operasyonel özelliklerle yaparlar. Multisig, farklı imzalayıcılar tarafından tutulan birden fazla tam anahtar kullanır ve cüzdan, bir işlemi yetkilendirmek için onayları zincir üzerinde birleştirir.

Onay izleme, belirgin ve farklı imzalayıcı kimliklerine bağlıdır; bu nedenle, şeffaflık ve denetlenebilirlik gereksinimleri olduğunda multisig genellikle tercih edilir.

MPC, bir imzalama anahtarını parçalara ayırır ve tam anahtarı hiçbir tarafın tutmadığı bir dış hesaplama yoluyla imzalar oluşturur. Bu mimari, daha akıcı otomasyonu destekleyebilir ve çok zincirli işlemler için daha blockchain bağımsız olabilir. Ancak, onay süreci, multisig'in yaptığı gibi doğası gereği zincir üzerinde, imzalayıcıdan imzalayıcıya bir denetim izi değildir.

Karar çerçevesi, evrensel bir iddia olarak 'hangisi daha güvenli' değildir. 'Zincir üzerinde neyin kanıtlanabilir olması gerektiği ve neyin hızlı ve operasyonel olarak akıcı olması gerektiği'dir. Eğer gereksinim onaylar için yönetim ve net hesap verebilirlik ise, multisig doğal olarak uyum sağlar. Eğer gereksinim, politika odaklı otomasyon ile birçok zincir boyunca operasyonel verimlilik ise, MPC genellikle daha iyi uyum sağlar.

Bu aynı zamanda uygulama detaylarının önemli olduğu yerdir. Yerel destekle bir zincirdeki bir multisig, imzalı mesaj iş akışları için ERC-1271 uyumluluğuna bağlı olan sözleşme tabanlı bir multisig'den farklı davranır. Bu fark, açıklanan cüzdan türlerinin bir parçasıdır ve iki ürünün de 'multisig' olarak adlandırılabilmesinin nedenidir, ancak tamamen farklı şekillerde başarısız olabilirler.

Alıntı

Takımların multisig'i bir onay kutusu gibi ele aldığını ve ardından kırılgan bir onay hattı inşa ettiklerini izledim. Pahalı an, cüzdanın oluşturulduğu gün değildir. Bir imzalayıcının seyahat ettiği, bir cihazın bozulduğu ve grubun seçtikleri eşiklerin çok gerçek bir kesinti bütçesi anlamına geldiğini fark ettiği gündür.

Temiz bir duruş, multisig'i bir masa kontrol sistemi gibi tasarlamaktır: öneri, inceleme, imzalar, eşik kontrolü, yayınlama, ücret finansmanı için sahiplik ve imzalayıcı kaybolma planı. 2-of-2 kontrol maksimize edilmiş ve dondurulmaya eğilimlidir, 2-of-3 pratik varsayılandır çünkü bir kurtarma yolu vardır ve 3-of-5, sürekliliğin hızdan daha önemli olduğu durumlarda kullanılır. İmzalayıcı sayısı özellik değildir. İşletim modeli önemlidir.

Kaynaklar

• Cobo
• Ethereum İyileştirme Önerileri
• Ethereum Geliştirme Önerileri
• Orta