Loading...
أُعدّ لصالح ZecHub · روجع في 27 سبتمبر 2026 · جميع الادعاءات موثقة بمصادر ضمنية
أثار ZecHub هذا السؤال بعد إضافة DASH المحمي كخيار تبرع للويكي: هل يمكن أن تنتقل مفاتيح العرض بأسلوب Zcash، أو التوقيعات الحدّية لـFROST، إلى Dash؟
أعاد البحث تأطير المسألة. مفاتيح العرض ليست سؤالاً مفتوحاً — فقد أطلقت Dash Zcash Orchard للمجمّع المحمي ضمن سلسلة Evolution الخاصة بها، ويتضمن تسلسل مفاتيح Orchard مفاتيح العرض بحكم تصميمه. وتضعها خارطة الطريق الخاصة بـDash في سياق الإفصاح للمدققين والامتثال لقاعدة السفر. هذا الجانب منشور بالفعل، لا افتراضي.
FROST هو موضع الفجوة الحقيقية. تشغّل Dash بالفعل توقيعات BLS الحدّية عبر مجاميع العقد الرئيسية طويلة العمر، لكن هذه تخدم إجماعاً على مستوى الشبكة — ChainLocks وInstantSend. يستهدف ZIP 312 شيئاً مختلفاً: تفويض إنفاق حدّي على حساب محمي واحد تحتفظ به مجموعة صغيرة من حاملي المفاتيح الأفراد. لا يمكن استبدال أحدهما بالآخر. وبما أن ZIP 312 لا يزال مسودة، فلا يوجد تطبيق مرجعي على أي من السلسلتين يمكن نقله، لذا سيكون هذا عملاً جديداً أياً كان الطرف الذي يبنيه.
وقع حدثان يتعلقان بالمجمّعات المحمية خلال أسابيع من بعضهما في منتصف 2026.
انتقلت Zcash بعيداً عن Orchard. كشف الباحث Taylor Hornby عن ثغرة في الدارة ضمن Orchard يمكن استغلالها لتضخيم المعروض دون إمكانية اكتشاف ذلك. وردّ Zcash بتفعيل Ironwood (NU6.3) في 28 يوليو 2026، مقدماً مجمّعاً محمياً جديداً مع آلية هجرة turnstile.
انتقلت Dash إلى Orchard. أعلنت Dash الخطة في 19 فبراير 2026 — "نتوقع أن نتمكن من إطلاق التحويلات المحمية قريباً، بطبيعة الحال رهن عمليات التدقيق الأمني ومراجعة إضافية للشفرة." وتسجل خارطة الطريق الخاصة بـDash الأرصدة المحمية باعتبارها مكتملة في يوليو 2026 مع Dash Platform v4.0، ونشرت Dash "المعاملات المحمية أصبحت متاحة على الشبكة الرئيسية لـDash Evolution" في 4 أغسطس 2026.
ملاحظة حول الترتيب. وضعت بعض التغطيات تفعيل الشبكة الرئيسية لـDash في 17 يوليو 2026، ما يجعله سابقاً لـIronwood. ويبدو أن ذلك التاريخ يعود إلى تقارير صحفية عن الإعلان وليس إلى عملية تفعيل. في مصادر Dash نفسها، اكتملت الميزة في يوليو وأُعلن عن توفرها في 4 أغسطس — بعد Ironwood. تقاطع مسار السلسلتين خلال بضعة أسابيع؛ ويعتمد الترتيب الدقيق على المَعلم الذي يُحتسب، ولا يدّعي هذا الموجز ترجيح أحدهما.
والأهم أن Dash لم ترث الخطأ. إعلانها واضح: "نفذنا إصدار Orchard من دون خطأ تضخم معروف. احتوى الإصدار السابق على خطأ كان يمكن استغلاله لتضخيم معروض Zcash على نحو غير قابل للاكتشاف."
لذا تشغّل Dash الآن تفرعاً مصححاً من التشفير الذي ابتعدت عنه Zcash نفسها على الطبقة الأساسية، في حين أن مجمّع Zcash من الجيل التالي (Ironwood) ومخطط تفويض الإنفاق من الجيل التالي (FROST) أصبحا، على التوالي، متاحاً حديثاً وما زال مسودة.
المجمّع المحمي لدى Dash هو Orchard، ومبني على Halo 2 zk-SNARKs الذي لا يتطلب إعداداً موثوقاً. لطالما تضمّن تسلسل مفاتيح Orchard مفاتيح العرض الكاملة ومفاتيح العرض الواردة ضمن تصميمه، لا كإضافة لاحقة — ولذلك وصلت القدرة مع الشفرة، لا كنقل اضطرت أي من السلسلتين إلى التفاوض عليه.
وتذكر خارطة طريق Dash الغرض مباشرة:
"على خلاف أنظمة الخصوصية الإلزامية التي واجهت إلغاءات إدراج في البورصات واحتكاكاً تنظيمياً، تدعم الأرصدة المحمية الإفصاح الانتقائي عبر مفاتيح العرض — مما يتيح للمستخدمين والشركات مشاركة تفاصيل المعاملات مع المدققين أو الامتثال لمتطلبات قاعدة السفر عند الحاجة، من دون المساس بالخصوصية للاستخدام اليومي."
ثمت ملاحظتان جديرتان بالتسجيل:
تضع Dash مفاتيح العرض ضمن حالة استخدام إنتاجية أكثر تحديداً مما بلغته أدوات Zcash نفسها. ظلت أدوات الإفصاح عن المدفوعات في Zcash تجريبية إلى حد كبير واختيارية عبر المحافظ. وتشحن Dash مفاتيح العرض كميزة امتثال ذات حالات استخدام محددة، على سلسلة توفر أيضاً تسوية حتمية تقارب الثانية الواحدة ومزامنة للمحفظة تقارب عشرين ثانية وفقاً لإعلانها الخاص.
العنصر المفتوح هو انجراف التوافق، لا القدرة. يجدر تتبع ما إذا كان تنفيذ مفاتيح العرض في Dash سيبقى متوافقاً على مستوى التنسيق السلكي مع تنسيق مفاتيح العرض في Zcash Orchard مع تطور السلسلتين باستقلالية. إنه سؤال مراقبة لا مشروع بحث.
يتناول هذا القسم سؤال المراجع مباشرة. الإجابة المختصرة هي أن أشجار المفاتيح المحمية متطابقة تقريباً لأن الشفرة مشتركة — أما الفروق المهمة فتقع في كيفية تجذير كل سلسلة لتلك الشجرة ضمن فضاء مفاتيح محفظتها، وما الأشياء الأخرى التي تشغل ذلك الفضاء.
تستخدم Zcash ZIP 32، المحافظ الحتمية الهرمية المحمية، التي حالتها نهائية. وبدلاً من وضع المفاتيح المحمية داخل شجرة BIP 32 واحدة، يمنح ZIP 32 كل مجمّع محمي مفتاحه الرئيسي ومساره الخاص:
m_Orchard / purpose' / coin_type' / account'
m_Sapling / purpose' / coin_type' / account'
تكون purpose ثابتة عند 32' (0x80000020) وفق BIP 43، وتتبع coin_type معيار SLIP 44، حيث تشترك كل شبكات الاختبار في الفهرس 1.
داخل حساب Orchard، يكون التسلسل هرمياً في اتجاه واحد بصورة صارمة — إذ يمكن لكل مستوى اشتقاق كل ما تحته ولا شيء مما فوقه:
| المفتاح | ما يمكنه فعله | ما يشتقه |
|---|---|---|
| Spending key | إنفاق الملاحظات | ask، nk، rivk |
Spend authorizing key (ask) | تفويض عمليات الإنفاق | — |
Full Viewing Key (ak, nk, rivk) | رؤية المدفوعات الواردة والصادرة | IVK، OVK |
| Incoming Viewing Key | رؤية المدفوعات الواردة فقط | العناوين المتنوعة |
| Outgoing Viewing Key | استعادة تفاصيل المدفوعات الصادرة | — |
| Diversified address | الاستلام | — |
بسّط Orchard هذا مقارنةً بـSapling: فبحسب Orchard Book، أزيل مفتاح nullifier الخاص nsk، وأصبح nk عنصراً حقلياً بدلاً من نقطة منحنى، وأصبح ovk مشتقاً من مفتاح العرض الكامل بدلاً من الاحتفاظ به منفصلاً.
وفوق ذلك يوجد ZIP 316، العناوين الموحدة ومفاتيح العرض الموحدة — المراجعة 0 نشطة، والمراجعة 1 مسحوبة، والمراجعة 2 مسودة — والذي يجمع مفاتيح كل مجمّع في Full Viewing Key موحد ("يجمع عدة عناصر Full Viewing Key…") وIncoming Viewing Key موحد. والتمييز الذي يجب على مطور المحفظة احترامه: يكشف UFVK النشاط الوارد والصادر معاً، بينما يكشف UIVK الوارد فقط.
تجذّر Dash كل شيء في شجرة BIP 32 تقليدية، بنوع عملة SLIP 44 هو 5'، وتضيف امتدادين خاصين بها للاشتقاق.
تُدخل DIP-0009، مسارات اشتقاق الميزات مستوى ميزة يقسّم فضاء المفاتيح بحسب الوظيفة الخاصة بالعملة:
m / purpose' / coin_type' / feature' / *
حيث تكون purpose ثابتة عند 9' (0x80000009) وcoin_type عند 5' (0x80000005). ودافع DIP المعلن هو العزل — "قد يكون من المرغوب الحفاظ على الأموال المختلطة في مسار معزول عن الأموال غير المختلطة."
ويذهب DIP-0014، اشتقاق المفاتيح الموسعة باستخدام أعداد صحيحة غير موقعة من 256 بت، أبعد من ذلك، إذ يرفع حد الفهرس البالغ 31 بت في BIP 32 كي تحمل مكونات المسار قيماً كاملة من 256 بت. وهذا يسمح بمسارات مشتقة من الهوية مثل:
m(userA)/9'/5'/15'/0'/(userA's unique id)/(userB's unique id)
حيث يمثل المكونان الأخيران تجزئات هوية المستخدم. لا يوجد لـZcash نظير: لا يتضمن ZIP 32 مفهوماً لاشتقاق مسار مفتاح من هوية طرف آخر.
الشجرة الفرعية المحمية هي نفسها. مفاتيح Dash المحمية هي مفاتيح Orchard، لأن مجمّع Dash المحمي هو Orchard. ومطور المحفظة الذي ينتقل بينهما يعمل مع بنية مفتاح الإنفاق إلى مفتاح العرض نفسها.
يختلف التجذير. يعزل Zcash كل مجمّع محمي تحت مفتاحه الرئيسي الخاص بغرض 32'. وتعلّق Dash الميزة المحمية بشجرة موحدة واحدة تحت الغرض 9'، إلى جانب كل ميزة أخرى. فصل Zcash يتم بحسب المجمّع التشفيري؛ وفصل Dash يتم بحسب ميزة المنتج.
يحتوي فضاء مفاتيح Dash على شيء لا يمتلكه Zcash: نطاق BLS منفصل. مفاتيح مشغلي العقد الرئيسية ومفاتيح التصويت ومفاتيح المجاميع المستخدمة بواسطة LLMQs هي مفاتيح BLS، وليست مفاتيح من عائلة Schnorr، وتقع كلياً خارج شجرة BIP 32 الموضحة أعلاه. وهنا تحديداً يوجد التوقيع الحدّي الحالي لدى Dash — ولهذا تحديداً لا يتركب مع تفويض الإنفاق في Orchard، كما يوضح القسم التالي.
الاشتقاق المرتبط بالهوية خاص بـDash. توجد مسارات DIP-0014 ذات 256 بت لاشتقاق مفاتيح من العلاقات بين الهويات. وهو مفهوم من Dash Platform لا يملك Zcash مقابلاً له، وهو أوضح حالة تباعد فيها مخططا الاشتقاق عن قصد لا بمحض المصادفة.
انظر الشكل 1 لمخططي التجذير وهما يتلاقيان في شجرة فرعية Orchard مشتركة.
تمتلك Dash نظام توقيع حدّي ناضجاً في LLMQs القائمة على BLS (مجاميع العقد الرئيسية طويلة العمر)، ويُستخدم من أجل ChainLocks وInstantSend وإجماع مدققي Dash Platform.
يفعل ZIP 312، FROST لتوقيعات الإنفاق المتعددة لتفويض الإنفاق، بحالة مسودة، شيئاً آخر. فهو يجعل توقيعات تفويض الإنفاق القائمة على Schnorr، والمحددة مسبقاً بـSapling وOrchard — أي RedJubjub وRedPallas على التوالي — حدّية، بحيث يمكن، بحسب صياغة ZIP نفسها، أن يطلب "المستخدمون وخدمات الأطراف الثالثة الذين يتشاركون حفظ محفظة، أو مجموعة من الأشخاص يديرون أموالاً مشتركة" موافقة حدّية مثل 2 من 3 قبل الإنفاق. وهو مصنف بوصفه ZIP خاصاً بالمحفظة: ينتج توقيعات متوافقة مع تفويض الإنفاق الحالي بدلاً من تغيير الإجماع. ويحتفظ بدور المنسق، الذي يرفض ZIP صراحة إزالته، ويناقش كلاً من توليد المفاتيح بواسطة طرف موثوق وتوليد المفاتيح الموزع.
التمييز المهم، وسبب عدم كون هذين بديلين:
| Dash BLS / LLMQ | Zcash FROST (ZIP 312) | |
|---|---|---|
| مخطط التوقيع | BLS | Schnorr — RedJubjub / RedPallas |
| من يوقّع | مجموعة من العقد الرئيسية | مجموعة صغيرة من حاملي المفاتيح الأفراد |
| ما الذي يُفوَّض | حقيقة شبكية: قفل كتلة أو قفل معاملة | إنفاق من حساب محمي واحد |
| الطبقة | الإجماع | المحفظة |
| فضاء المفاتيح | نطاق BLS منفصل | مفتاح تفويض الإنفاق Orchard/Sapling |
| الحالة | منشور | مسودة، بلا تطبيق مرجعي |
إن امتلاك Dash لتوقيعات BLS الحدّية لا يعني أنها تمتلك FROST أو تحتاجه. لكنه يعني أن مهندسي Dash لديهم خبرة داخلية في التوقيع الحدّي وتوليد المفاتيح الموزع وتنسيق المجاميع — وهي خبرة قابلة للنقل فعلاً إذا اختاروا بناء ذلك.
انظر الشكل 2 لمعرفة ما الذي يوقّع عليه كل مخطط فعلياً.
مفاتيح العرض — وثّقها، لا تبحثها. القدرة منشورة على كلتا السلسلتين. تمنع ملاحظة قصيرة في الويكي تسجل أن المجمّع المحمي لدى Dash يتضمن مفاتيح عرض، وترتبط بخارطة طريق Dash، جمهور ZecHub من افتراض أنها لا تزال افتراضية. تتبع توافق التنسيق السلكي مع تطور السلسلتين.
FROST — فرصة حقيقية، لكنها محجوبة في المنبع. تعتمد على وصول ZIP 312 إلى تطبيق مرجعي، أو اختيار Dash البناء بالتوازي. لا يمكن لـZecHub تسريعها مباشرة.
الخطوة التالية الأعلى قيمة هي محادثة، لا مزيد من البحث المكتبي. الأشخاص الذين سيبنون هذا يمكن الوصول إليهم. تقود Shielded Labs تطوير ZIP 312؛ وقد تفاعل فريق هندسة Dash بإيجابية مع صياغة "المستعار من Zcash" حول تكامل Orchard. إن نقاشاً عابراً للمجتمعين يربط الطرفين سيكشف أكثر من جولة قراءة إضافية، وقد بلغ هذا الموجز حدود ما يمكن أن تحسمه المصادر العامة.
الشكل 1 — تجذير اشتقاق المفاتيح: Zcash ZIP 32 وDash DIP-0009/0014، يتلاقيان في شجرة فرعية Orchard مشتركة.
assets/Zcash_Dash_Key_Derivation.svg
الشكل 2 — ما الذي يوقّع عليه كل مخطط حدّي: مجموعة من العقد الرئيسية تشهد على حقيقة شبكية، مقابل مجموعة حاملي مفاتيح تفوّض إنفاقاً محمياً واحداً.
assets/FROST_vs_BLS_LLMQ.svg
Zcash — البروتوكول
Dash — البروتوكول والإعلانات
تغطية معاصرة
تم التحقق من المصادر في 27 سبتمبر 2026. يتحرك كل من Dash Platform وZIP 312؛ لذا ينبغي إعادة التحقق من الأشكال والحالات قبل إعادة النشر.