الانتقال إلى المحتوى
Financial Context Wiki

توقيعات BLS

دليل يركز على التحقق من توقيعات Boneh-Lynn-Shacham وأنماط التجميع وحزم التشفير ودفاعات المفاتيح الخبيثة واستخدامها في إجماع Ethereum ومخاطر التنفيذ.

آخر تحديث

لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

الإجابة المباشرة

توقيع Boneh-Lynn-Shacham هو توقيع رقمي قائم على الاقتران. في ترتيب شائع، ينتج المفتاح السري sk المفتاح العام PK = sk * G1؛ وتحول الرسالة m إلى H(m) في G2؛ ويجري التحقق من التوقيع sig = sk * H(m) عبر e(PK, H(m)) = e(G1, sig). المجموعات الدقيقة والترميزات وحزمة hash-to-curve وفصل النطاق خيارات ciphersuite وليست رموزا قابلة للتبديل.

لـBLS ميزة تشغيلية غير مألوفة: يمكن جمع التوقيعات الصحيحة في عنصر مجموعة واحد ثابت الحجم. يضغط ذلك التوقيعات، لكنه لا يضغط قائمة الموقعين ولا يثبت quorum ولا يحدد المدققين المصرح لهم ولا يمنع equivocation ولا يجعل الإجماع نهائيا. تأتي هذه الخصائص من البروتوكول المحيط.

آلية العمل

  1. ثبّت البروتوكول وciphersuite والإصدار: المنحنى ومجموعتي المفتاح العام والتوقيع والتسلسل ودالة hash-to-curve ووسم فصل النطاق وبناء جذر الرسالة. لا تستنتج التوافق من اسم BLS وحده.
  2. أنشئ sk بإجراء توليد المفتاح المحدد واشتق PK. ارفض الصفر ونقطة اللانهاية والترميزات المشوهة وغير القانونية أو التابعة لمجموعة فرعية خاطئة وفق قواعد KeyValidate وفك التسلسل الدقيقة.
  3. أنشئ bytes الرسالة ونطاق التوقيع بدقة. في إجماع Ethereum، يربط جذر التوقيع جذر كائن SSZ بنطاق مشتق من نوع العملية وبيانات fork؛ النص المعروض ليس الكائن الموقع.
  4. وقّع وتحقق فرديا بالمخطط المختار. تختلف متغيرات Basic وإضافة الرسالة وproof-of-possession في دفاعاتها ضد rogue key، ولا يجوز خلطها بلا تدقيق.
  5. اختر محقق التجميع حسب نمط الرسائل. استخدم FastAggregateVerify فقط لمفاتيح عامة متعددة تم التحقق منها وتوقع الرسالة نفسها ضمن افتراضات proof-of-possession المطلوبة؛ واستخدم AggregateVerify لقائمة المفاتيح والرسائل التي يسمح بها المخطط.
  6. أعد بناء مجموعة الموقعين بصورة مستقلة من بيانات اللجنة أو participant bitlist، وارفض الفهارس المكررة أو غير المصرح بها، وطبق أوزان stake أو threshold، ثم تحقق من التوقيع المجمع. يثبت التجميع الصحيح المجموعة المقدمة، لكنه لا يقرر استيفاءها للسياسة.
  7. طابق النتيجة مع fork choice وشروط slashing وquorum وavailability والتوقيت وfinality. احتفظ بbytes الإدخال والنطاقات وفهارس الموقعين وإصدار التنفيذ وtest vectors، وقارن مكتبات مستقلة قبل النشر.

أمثلة محلولة

  • الضغط لا يلغي بيانات العضوية. يرمز إجماع Ethereum كل مفتاح عام BLS في 48 bytes وكل توقيع في 96 bytes. تشغل 512 توقيعا للرسالة نفسها منفصلة 512 * 96 = 49,152 bytes. يشغل توقيع مجمع واحد مع participant bitlist بطول 512-bit = 64-byte مقدار 96 + 64 = 160 bytes، أي انخفاض 49,152 - 160 = 48,992 bytes أو 99.6744791667%. ويجب أن تبقى مفاتيح المدققين العامة وربط اللجنة متاحة في مكان آخر.
  • تجميع الرسالة نفسها. لنفترض أن المدققين المسجلين 17 و24 و91 يوقعون جذر التوقيع نفسه R. تتجمع توقيعاتهم هكذا sigAgg = sig17 + sig24 + sig91. يستخدم التحقق مجموعة المفاتيح المرتبة والمتحقق منها [PK17, PK24, PK91] وR نفسه وFastAggregateVerify. تثبت النتيجة الصحيحة توقيع هذه المفاتيح على R ضمن المخطط؛ وتحدد قاعدة منفصلة أوزانهم وما إذا كان ثلاثة موقعين يشكلون quorum.
  • الرسائل المختلفة تتطلب API الصحيح. توقع المفاتيح PK1 وPK2 وPK3 الرسائل المختلفة m1 وm2 وm3. يجب أن يحافظ المحقق على الاقترانات [PK1, m1] و[PK2, m2] و[PK3, m3] ويستدعي AggregateVerify المنطبق؛ أما استبدالها برسالة واحدة وFastAggregateVerify فيتحقق من ادعاء مختلف. وفي مخطط Basic يجب أيضا أن تكون الرسائل متميزة.
  • التجميع ليس توقيع threshold. في مجموعة من 8 أعضاء، ينتج التجميع العادي لتوقيعات الأعضاء [1, 2, 4, 6, 8] توقيعا واحدا وقائمة من خمسة موقعين. لا يصبح توقيع 5-of-8 threshold تحت مفتاح عام جماعي واحد. يتطلب threshold BLS فعليا توليد مفتاح موزعا أو نموذجا بجهة موثوقة، وفهارس shares وقواعد interpolation؛ ويجب تدقيق افتراضات الثقة والفشل بصورة مستقلة.

المخاطر

  • استخدام منحنى أو ترتيب مجموعات أو ciphersuite يختلف عن البروتوكول.
  • توقيع bytes متسلسلة مختلفة رغم عرض الرسالة نفسها للبشر.
  • إغفال نطاق fork أو العملية أو التطبيق وإتاحة replay عبر السياقات.
  • اعتبار Internet-Draft منتهي الصلاحية معيارا نهائيا ثابتا.
  • قبول ترميزات نقاط مشوهة أو غير قانونية أو عند اللانهاية.
  • تخطي فحوص المجموعة الفرعية وإدخال نقاط منحنى غير صالح أو مجموعة صغيرة.
  • استخدام code مخصص لـhash-to-curve بدلا من الحزمة وtest vectors المحددة.
  • توليد مفاتيح سرية منحازة أو صفرية أو مكررة أو مسربة أو متوقعة.
  • إعادة استخدام مفتاح عبر بروتوكولات تختلف افتراضات proof-of-possession والنطاق فيها.
  • تجميع مفاتيح عامة غير مسجلة بلا دفاع rogue-key المطلوب في المخطط.
  • استدعاء التحقق السريع للرسالة نفسها على رسائل مختلفة أو جذور غير متسقة.
  • تبديل أو تكرار أو حذف ارتباط المفتاح العام بالرسالة.
  • الثقة في participant bitlist دون فحص عضوية اللجنة وتفرد الفهارس.
  • عد التوقيعات بدلا من stake أو الوزن أو threshold المحدد في البروتوكول.
  • افتراض أن التجميع الواحد يكشف أي توقيع فردي غير صالح.
  • الخلط بين التجميع العادي وmultisignatures وتوقيعات threshold.
  • اعتبار صحة التوقيع دليلا على availability أو صحة التنفيذ أو finality.
  • تجاهل equivocation والرسائل القابلة للعقوبة ونوافذ التوقيت وسياق fork choice.
  • الاعتماد على مكتبة واحدة أو ميزة CPU أو تحسين batch verification غير مفحوص.
  • التقليل من تكلفة الاقتران ومدخلات حجب الخدمة والقنوات الجانبية وحفظ المفاتيح والترقيات وغياب أمان ما بعد الكم.

مفاهيم خاطئة شائعة

  • يثبت التوقيع المجمع مشاركة كل مدقق.
  • يمكن جمع أي مفاتيح وتوقيعات BLS بأمان بلا قواعد proof-of-possession.
  • يلغي التجميع ثابت الحجم الحاجة إلى إرسال عضوية الموقعين أو إعادة بنائها.
  • تجميع BLS وthreshold BLS هما البناء نفسه.
  • يجعل توقيع BLS الصحيح الكتلة أو رسالة الجسر أو البروتوكول آمنا اقتصاديا ونهائيا.

موضوعات ذات صلة

المصادر

التنقل

ابحث في الويكي...