يتيح MuSig2 لعدة أشخاص إنشاء توقيع Schnorr واحد يثبت الموافقة على رسالة محددة دون كشف مفاتيحهم الخاصة. تتضمن إجراءات BIP327 جولتين للتواصل، تجمعان المفاتيح العامة في مفتاح مجمّع ومساهمات التوقيع في توقيع متوافق مع BIP340. النموذج الأساسي n-of-n: يجب أن يسهم جميع الموقّعين المشاركين.
تخيّل خزينة مشتركة تتطلب موافقة أليس وبوب على كل دفعة. يثبت التوقيع الرقمي الإذن بالدفع باستخدام مفتاح خاص، وهو قيمة عددية سرية، دون الكشف عن المفتاح. قد يكشف Multisig التقليدي القائم على السكربت عدة مفاتيح وتوقيعات في المعاملة. أما مع MuSig2 فيحتفظ كل شخص بمفتاحه الخاص ويسهم في توقيع مشترك، وتتحقق الشبكة من نتيجة واحدة. التوفير يخص التسجيل والتحقق على السلسلة؛ ولا يلغي الحاجة إلى التنسيق بين المشاركين. قدّم Jonas Nick وTim Ruffing وYannick Seurin البروتوكول في ورقة بحثية نُشرت في أكتوبر 2020. [3] [2] [10]
ليس MuSig2 وحده ترتيباً من نوع 2-of-3 يمكن فيه لأي اثنين تعويض غياب الثالث. في نموذج n-of-n يجب أن يسهم كل عضو في المجموعة. ويمكن لمشارك غير متاح أو رافض أن يوقف التعاون. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. إذا أريد للمحفظة أن تعمل أيضاً في هذه الحالة، فلا بد من مسار إنفاق أو آلية توقيع أخرى مصممة مسبقاً؛ اسم MuSig2 لا يوفر ذلك تلقائياً. [1] [8]
قبل التوقيع يبني المشاركون مفتاحاً عاماً مجمّعاً. يُستخدم المفتاح العام للتحقق من التوقيعات، ولا يلزم إبقاؤه سرياً. في الجولة الأولى يتبادلون قيم nonce العامة، وهي مساهمات أحادية الاستخدام لتحضير التوقيع. وفي الثانية ينشئون توقيعات جزئية للرسالة والسياق نفسيهما ويتبادلونها ثم يجمعونها. وفق شروط البروتوكول، يمكن تحضير الجولة الأولى قبل معرفة تفاصيل الدفع. لكن قبل إنشاء توقيعه الجزئي، يجب على كل مشارك مراجعة المعاملة المحددة، وخصوصاً المستلم والمبلغ والرسوم. التحضير ليس موافقة على دفعة مجهولة؛ والمراجعة بعد التوقيع متأخرة. [1] [3]
قد يسمح الجمع الساذج لمهاجم باختيار مفتاحه العام على نحو يستغل مفاتيح الآخرين. لذلك يستخدم MuSig2 أوزاناً عددية تسمى معاملات، تُشتق من قائمة المفاتيح. يراعي KeyAgg ترتيبها أيضاً، ويمكن للتطبيق استخدام KeySort لتوحيد الترتيب. يجب أن يعتمد الجميع القائمة والقواعد نفسيهما، وإلا فلن يحسبوا المفتاح المجمّع نفسه. [1] [5]
لا تعني nonce هنا عدّاد التعدين، بل بيانات توقيع أحادية الاستخدام: تُرسل pubnonce إلى الآخرين، بينما تبقى secnonce لدى الموقّع. لا يجوز مطلقاً إعادة استخدام nonce سرية في استدعاء آخر لـSign. فقد يكشف توقيعان جزئيان نتجا عن إعادة استخدامها المفتاح الخاص. تغيير الرسالة أو تكرار دفعة تبدو مطابقة ليس استثناءً آمناً. [1] [7]
لا تكفي الحسابات التشفيرية الصحيحة إذا استعاد التطبيق بعد إعادة التشغيل secnonce مستخدمة من نسخة احتياطية أو سلّمها لمهمتين متزامنتين. تُبطل libsecp256k1 قيمة nonce السرية بالكتابة فوقها أثناء التوقيع، لكن نسخة خارج سيطرتها قد تتجاوز الحماية. يجب أن تمنع إدارة الحالة إعادة الاستخدام عند الخطأ والاستعادة والتزامن. يمكن إعادة استخدام مفتاح التوقيع الخاص نفسه؛ شرط الاستخدام الواحد يخص nonce. [7]
يمكن لمنسّق جمع قيم nonce العامة والتوقيعات الجزئية وتيسير التبادل. عند التطبيق الصحيح للبروتوكول، لا يمنحه ذلك القدرة على التوقيع بدلاً من مشارك أمين، لكنه يستطيع إفشال العملية. وعلى كل موقّع مراجعة ما يوقّعه. قد يساعد التحقق من التوقيعات الجزئية في كشف المشكلة، لكنه يحتاج إلى المساهمات العامة الأصلية والسياق الصحيح؛ لا تكفي nonce المجمّعة وحدها لتحديد المتسبب. [1] [7]
النتيجة توقيع BIP340 بطول 64 بايت. Taproot key path طريقة إنفاق تتحقق فيها الشبكة من توقيع للمفتاح المسجل في المخرج، دون كشف سكربت بديل. إذا لم يُستخدم الوضع الافتراضي، يأتي بعد التوقيع بايت يحدد نوع sighash. وهو يحدد أجزاء المعاملة التي يرتبط بها التوقيع، بحيث يؤدي تغييرها إلى إبطاله. لا يكشف التوقيع وحده عدد المشاركين أو مفاتيحهم الفردية. لكن MuSig2 لا يخفي المبالغ أو كل روابط الدفع أو تواصل الأطراف. ولا يجمع تلقائياً توقيعات المدخلات المختلفة، التي تشير إلى مخرجات مستلمة سابقاً تنفقها هذه المعاملة. [5] [6]
إلى جانب key path المشترك، يمكن أن يتضمن Taproot شروط سكربت، مثل مجموعة مفاتيح أخرى أو قفل زمني. يتيح القفل مساراً معيناً بعد وقت أو ارتفاع كتلة محدد، ولا يعوض التوقيعات المطلوبة. تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. ارتفاع الكتلة هو موضعها في السلسلة. يجب تثبيت الشروط تشفيرياً عند إنشاء المخرج، وهو مبلغ محدد مرتبط بقواعد إنفاق. لا يمكن إضافتها بعد فقد أحد الموقّعين. Script path هو الإنفاق عبر ذلك السكربت؛ يكشف الشروط المعنية وقد تكون تكلفته أعلى. لذلك تتطلب الاستعادة معلومات الترتيب المختار، لا المفاتيح السرية الفردية فقط. [6] [1] [9]
يصف BIP327 البروتوكول، بينما تحدد المكتبة والمحفظة الواجهة الفعلية والنسخ الاحتياطية والإجراءات المدعومة. تحقق من الإصدار ومتجهات الاختبار والتعامل مع nonce ومراجعة المعاملة المراد توقيعها. دعم توقيعات Schnorr لا يعني تلقائياً اكتمال دعم MuSig2 في كل محفظة. يستخدم التوقيع المشترك قواعد BIP340 وTaproot القائمة، ولا يحتاج استخدام MuSig2 بحد ذاته إلى opcode إجماع جديد. [4] [7] [2]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Schnorr Signature, Taproot, Multisig, PSBT. تشير إلى هذا المدخل أيضًا Schnorr Signature, Submarine Swap, FROST, PTLC.