---
title: "توقيعات BLS"
description: "دليل يركز على التحقق من توقيعات Boneh-Lynn-Shacham وأنماط التجميع وحزم التشفير ودفاعات المفاتيح الخبيثة واستخدامها في إجماع Ethereum ومخاطر التنفيذ."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# توقيعات BLS

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

<a id="answer"></a>

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

توقيع 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 ولا يجعل الإجماع نهائيا. تأتي هذه الخصائص من البروتوكول المحيط.

<a id="mechanism"></a>

## آلية العمل

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، وقارن مكتبات مستقلة قبل النشر.

<a id="example"></a>

## أمثلة محلولة

- **الضغط لا يلغي بيانات العضوية.** يرمز إجماع 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؛ ويجب تدقيق افتراضات الثقة والفشل بصورة مستقلة.

<a id="risks"></a>

## المخاطر

- استخدام منحنى أو ترتيب مجموعات أو 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 غير مفحوص.
- التقليل من تكلفة الاقتران ومدخلات حجب الخدمة والقنوات الجانبية وحفظ المفاتيح والترقيات وغياب أمان ما بعد الكم.

<a id="misconceptions"></a>

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

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

<a id="related"></a>

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

- [دالة التجزئة التشفيرية](/ar/crypto/cryptographic-hash/)
- [إثبات الحصة](/ar/crypto/proof-of-stake/)
- [توقيع العتبة](/ar/crypto/threshold-signature/)

<a id="sources"></a>

## المصادر

- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (accessed: 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (accessed: 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (accessed: 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (accessed: 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (accessed: 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (accessed: 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (accessed: 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (accessed: 2026-08-12)

Source: https://wiki.fcontext.com/ar/crypto/bls-signature/index.mdx