182 / 736FROST

FROST

توقيع واحد يتطلب قرار أكثر من شخص

تريد آنا ويان وإيفا إدارة أموال مشتركة بحيث لا يستطيع أي منهم إرسالها بمفرده. يتيح FROST تحديد التعاون المطلوب ثم جمع الحسابات الجزئية في توقيع واحد. ولا يلزم أثناء التوقيع تجميع المفتاح السري الكامل على جهاز واحد.

FROST بروتوكول لتوقيعات شنور العتبية، أي توقيعات رقمية ينشئها عدة مشاركين معًا. وتعني العتبة أن التوقيع يتطلب تعاون عدد أدنى محدد من حاملي حصص مختلفة من مفتاح سري مشترك. والمفتاح السري عدد يُستخدم لإنشاء التوقيع؛ أما هنا فيستخدم المشاركون حصصهم أثناء التوقيع بدلًا من المفتاح الكامل. ويمكن التحقق من النتيجة بمفتاح عام واحد للمجموعة، يمكن مشاركته مع الآخرين ولا يتيح التوقيع بمفرده. والاسم اختصار لعبارة Flexible Round-Optimized Schnorr Threshold؛ فهو ليس محفظة ولا نوعًا جديدًا من البيتكوين.

لنتخيل جمعية يدير مدخراتها آنا ويان وإيفا. اختاروا قاعدة 2 من 3: يمكن لآنا ويان، أو آنا وإيفا، أو يان وإيفا الموافقة على دفعة. يحتفظ كل منهم بحصة سرية مختلفة، أي جزء من بيانات المفتاح المشترك أُنشئ باستخدام أساليب رياضية من علم التعمية. لا تكفي حصة واحدة، لكنها ليست أيضًا ثلاث نسخ من كلمة المرور نفسها. إذا تعذر حضور إيفا، يستطيع الآخران التعاون. وتنطبق الحدود نفسها على المهاجم: حصوله على حصص كافية يمكّنه من التوقيع أيضًا. لذلك لا يفيد التوزيع إلا إذا كان اختراق جهاز أو حساب واحد لا يفتح الطريق إلى جميع الحصص الأخرى. [1] [2]

لا ينبغي لآنا تأكيد العملية لمجرد أن التطبيق يعرض طلب توقيع. عليها معرفة المستلم والمبلغ والرسوم، والتأكد من عودة المبلغ المتبقي إلى الجمعية إن وُجد. يحتاج كل موقّع إلى وسيلة موثوقة للتحقق من المعاملة الفعلية. أما Hash، وهو بصمة تشفيرية قصيرة للبيانات، فلا يشرح مضمونها للإنسان بمفرده. يتيح FROST التعاون على الرسالة نفسها؛ لكنه لا يحكم على صحة الفاتورة أو فهم الشخص لما يوافق عليه. وحتى اكتمال التوقيع لا يعني تأكيد الدفعة داخل كتلة. الكتلة مجموعة معاملات مسجلة في السجل المشترك لشبكة Bitcoin. RFC 9591 مواصفة معلوماتية للبروتوكول، وليست شهادة أمان للتطبيق بأكمله. [1] [2]

Taproot تحديث في Bitcoin يتيح إنفاق الأموال إما بتوقيع للمفتاح المعني أو باستيفاء شروط محددة مسبقًا. يمكن لتوقيع عتبي مُنشأ بصورة صحيحة، عند الإنفاق عبر مسار المفتاح في Taproot، أن يبدو كتوقيع عادي بمفتاح واحد. ولا يكشف التوقيع وحده عدد الحصص الداخلي أو العتبة المطلوبة. يفيد ذلك الخصوصية وحجم بيانات التوقيع، لكنه لا يجعل المعاملة كلها أو اتصالات المشاركين مجهولة الهوية. يتطلب Bitcoin الالتزام الدقيق بقواعد BIP 340؛ ولا يكفي استخدام FROST العام على المنحنى secp256k1، وهو الأساس الرياضي للحسابات المتعلقة بمفاتيح Bitcoin. لذلك توفر Zcash Foundation (ZF) تنفيذًا منفصلًا هو frost-secp256k1-tr مخصصًا لـ Taproot. ويجب أيضًا التعامل الصحيح مع تعديلات المفتاح التي يستخدمها Taproot. تطابق اسم المنحنى ليس دليلًا على التوافق، ووجود مكتبة برمجية لا يعني دعمها في كل محفظة. [3] [4]

قبل أن توقّع الجمعية أي شيء، يجب إنشاء الحصص بأمان. يستطيع موزّع موثوق إنشاء المفتاح كاملًا وتقسيمه. لكن هذه لحظة حساسة: فهو يعرف المفتاح كله، وقد تسمح نسخة يحتفظ بها بتجاوز الموافقة المشتركة المقصودة. البديل هو DKG، أي التوليد الموزع للمفتاح، بحيث لا يلزم أن يظهر المفتاح السري كاملًا لدى مشارك واحد. ويتطلب ذلك اتصالات محمية ومتحققًا من هوية أطرافها وتنفيذًا صحيحًا للبروتوكول. لا يكفي إرسال بعض الملفات بالبريد الإلكتروني. يركز RFC 9591 على التوقيع ولا يَعِد تلقائيًا بوجود DKG في كل منتج. كذلك تختلف حصة المفتاح طويلة الأجل عن حصة توقيع دفعة بعينها. [1] [2]

يجري التوقيع نفسه في جولتين، لا تشملان إنشاء المفتاح السابق. أولًا ينشئ كل مشارك مختار قيمتين سريتين للاستعمال مرة واحدة تُسمّيان nonce، ويرسل التزاماتهما العامة؛ وهي قيم تربطه تشفيريًا بتلك القيم السرية. ثم يتلقى الرسالة المشتركة وقائمة الالتزامات، ويتحقق من البيانات ويحسب حصته من التوقيع. يجمع المنسق هذه الحصص. وتربط عوامل الربط الحسابات بالرسالة المحددة والمفتاح العام للمجموعة والالتزامات. في قاعدة 2 من 3 يمكن بدء جلسة بمشاركين اثنين. لكن إذا اختير الثلاثة للجلسة، فعلى الجميع تقديم مساهمتهم؛ ولا يمكن ببساطة إسقاط من توقف عن الرد. [1] [3]

تعني nonce هنا قيمة سرية لمحاولة توقيع واحدة، لا كلمة مرور قابلة للتكرار. وقد تكشف إعادة استخدامها مادة المفتاح السرية. إذا تعطل حاسوب يان بعد إرسال حصته من التوقيع، فلا يجوز لاستعادة حالة قديمة أن تجعل قيم nonce المستخدمة تبدو جديدة. وعدم اكتمال الدفعة لا يبيح إعادة استخدامها أيضًا. يحتاج التنفيذ الآمن إلى عشوائية جيدة وفصل المحاولات المتزامنة واستبعاد القيم المستهلكة بصورة موثوقة. وهذا أحد أسباب عدم تركيب FROST ذاتيًا من نصوص برمجية عشوائية. صحة الرياضيات وحدها لا تحمي البيانات السرية إذا أُسيئت إدارتها. [1]

ينظم المنسق الرسائل، لكن هذا الدور وحده لا يمنحه سلطة التوقيع نيابة عن الجمعية. فهو يحتاج إلى مساهمات حاملي الحصص المختارين. ومع ذلك يستطيع حجب الاتصالات أو إيقاف الجلسة، كما قد تُفشلها مساهمة غير صالحة من أحد المشاركين. تستطيع الفحوص اكتشاف حصة توقيع غير صالحة؛ أما إسناد الخطأ لشخص محدد فيتطلب معرفة موثوقة بمصدر الرسائل. واكتشاف المشكلة لا يضمن إتمام العملية. تحتاج محاولة جديدة إلى مجموعة مخوّلة ومتاحة وقيم nonce جديدة. لذلك تحتاج الجمعية إلى خطة للأعطال والخلافات، لا إلى رقم للعتبة على شاشة البداية فحسب. [1] [2]

إذا فقدت إيفا جهازها، فلن يعيد اسم FROST الأموال بمفرده. يجب أن تحفظ النسخة الاحتياطية حصتها ومعرّفها وبيانات المجموعة اللازمة وإمكانية تحميلها ببرنامج متوافق. وليست هذه تلقائيًا Seed Phrase عادية، أي نسخة احتياطية للمحفظة في صورة كلمات. استعادة الحصة بمساعدة الآخرين وتجديد الحصص إجراءان إضافيان يجب أن يدعمهما النظام المعني. وتظل نسخة حصة إيفا هي الحصة نفسها، ولا تضيف صوتًا مستقلًا. كما أن التجديد مع الإبقاء على مفتاح المجموعة نفسه لا يبطل مجموعة كافية من الحصص المسروقة سابقًا. لذلك يجب أن تشمل التجربة قبل استخدام مدخرات حقيقية الاستعادة والأعطال والتحقق من الإصدار الدقيق للبرنامج، لا مجرد نجاح توقيع واحد. [2] [3]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Schnorr Signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing, Bitcoin.

DOC · 001RFC 9591 — FROSTمواصفة DOC · 002ZF FROST Book — key generation and recoveryمصدر أولي DOC · 003ZF frost-secp256k1-tr — Taproot implementationمصدر أولي DOC · 004BIP 340 — Schnorr Signatures for secp256k1مواصفة
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية