التوقيع البارد للمعاملات المحمية
الفكرة الأساسية: ترى المحفظة المرافقة كل ما يلزم لبناء معاملة محمية ومراقبتها. تحتفظ محفظة الأجهزة وحدها بصلاحية تفويض الإنفاق. هذا الفصل هو جوهر التوقيع البارد للمعاملات المحمية.
ينطوي التحصين في Zcash على نقل الأموال من عنوان عام وشفاف إلى عنوان خاص ومحصّن، وإخفاء تفاصيل المعاملة باستخدام ميزات الخصوصية الخاصة بـ Zcash.
ما الذي يتغير عند تحصين ZEC؟
في معاملة Zcash شفافة، يمكن ملاحظة معلومات مثل:
- عنوان المرسل
- عنوان المستلم
- المبلغ المحوَّل
على البلوكشين.
عند تحصين ZEC، تنتقل أموالك إلى مجمع خاص (مثل Ironwood). يمكن للبلوكشين التحقق من صحة المعاملة دون كشف تفاصيل معاملتك الخاصة. منذ ترقية NU6.3 في 28 يوليو 2026، تدخل الأموال المحصنة حديثًا إلى مجمع Ironwood لأن مجمع Orchard الأقدم لم يعد يقبل إيداعات جديدة، لكنه ما زال يسمح بالسحوبات.
مكوّنات المعاملة المحمية
1. المذكرة (سجل الرصيد المحمي)
المذكرة هي سجل خاص وتشفيري يمثل مبلغًا غير مُنفَق من ZEC يملكه مستخدم.
بخلاف البلوكشين العام، حيث تُدرج الأرصدة بنص واضح، تشفّر المذكرة المحمية القيمة وتفاصيل الملكية كي لا يتمكن مراقبو السلسلة من رؤية من يملك الأموال.
عند بدء معاملة، تفحص المحفظة المرافقة دفتر السجل، وتحدد مذكرات المستخدم غير المنفقة، وتختار المذكرات التي ستُنفق.
2. المُبطِل (آلية كشف الإنفاق المزدوج)
لأن تفاصيل المذكرة مخفية عن دفتر السجل العام، تحتاج الشبكة إلى آلية لكشف الإنفاق المزدوج دون كشف المذكرة التي يجري إنفاقها.
المُبطِل هو علامة تشفيرية فريدة مشتقة من مذكرة محددة. عند إنفاق مذكرة، يُنشر مُبطِلها على البلوكشين.
تتحقق الشبكة من أن المُبطِل لم يُسجل سابقًا. إن لم يكن كذلك، يمكن قبول الإنفاق. والأهم أن مراقبًا خارجيًا لا يستطيع استخدام المُبطِل لتحديد المذكرة المحددة التي جاء منها.
تشتق المحفظة المرافقة المُبطِل المناسب وتبنيه كجزء من تجميع بيانات المعاملة.
المفاتيح
المفاتيح هي أجزاء معلومات تشفيرية تتحكم في الوصول إلى أموالك وتسمح لمحفظتك بإجراء عمليات مثل تلقي ZEC وعرضه وإنفاقه.
تحتفظ المحفظة بعدة مفاتيح مختلفة، يؤدي كل منها غرضًا مختلفًا، تمامًا كما قد يحتوي حساب واحد على بيانات اعتماد منفصلة لوصول القراءة مقابل وصول الكتابة.
تُعد المفاتيح محورية للعلاقة بين المحفظة المرافقة ومحفظة الأجهزة، لأن المفاتيح المختلفة تؤدي أغراضًا مختلفة، ولا يحتاج سوى أحدها إلى البقاء مقفلًا بعيدًا.
من المهم معرفة أن كل مجمع محمي يبني مفاتيحه كشجرة اشتقاق، حيث تشير الأسهم من مكوّن إلى كل ما يمكن اشتقاقه منه. يجب أن يمتلك المستخدمون الراغبون في تلقي مدفوعات محمية عنوان دفع محميًا، ويُولَّد هذا العنوان من مفتاح إنفاق.
التسلسل الهرمي للمفاتيح
1. مفتاح الإنفاق
هذا هو المفتاح الأكثر حساسية من ناحية الأمان. يمنح القدرة التشفيرية على تفويض إنفاق ZEC.
هذا هو المفتاح المشار إليه كلما وردت عبارة «محفظة الأجهزة تحتفظ بالمفتاح» في مواضع أخرى من هذا التقرير.
في بنية التوقيع البارد، يُحتفظ بمفتاح الإنفاق داخل محفظة الأجهزة ولا يُكشف أبدًا للمحفظة المرافقة. وينبغي ألا تحتاج المحفظة المرافقة إلى امتلاك هذا المفتاح إطلاقًا.
في كل من Sapling وOrchard، تشتق التسلسلات الهرمية للمفاتيح صلاحية الإنفاق وقدرات العرض كفرعين منفصلين من مفتاح إنفاق جذري:
- Sapling: يشتق مفتاح إنفاق موسع (𝑎𝑠𝑘,𝑛𝑠𝑘,𝑜𝑣𝑘) مفاتيح تفويض الإثبات (𝑎𝑘,𝑛𝑠𝑘) ومفاتيح عرض كاملة (𝑎𝑘,𝑛𝑘,𝑜𝑣𝑘)، التي تنتج بدورها مفاتيح عرض واردة (𝑖𝑣𝑘) وعناوين متنوعة.
- Orchard: يتفرع مفتاح إنفاق جذري (𝑠𝑘) مباشرة إلى مفتاح تفويض إنفاق (𝑎𝑠𝑘) ومفتاح عرض كامل (𝑎𝑘,𝑛𝑘,𝑟𝑖𝑣𝑘).
يوفر هذا الفصل الهيكلي الأساس التشفيري الرسمي لعزل مفاتيح الأجهزة، والذي يتضمن أن تصدّر المحفظة فرع العرض (UFVK) إلى الحاسوب المضيف لمزامنة الرصيد وبناء المعاملات، مع إبقاء فرع تفويض الإنفاق مقفلًا بصورة دائمة على الجهاز.
اشتقاق المفاتيح أحادي الاتجاه بصورة صارمة. وهذا يعني أنه لا يمكن عكس مفاتيح العرض لإعادة بناء صلاحية الإنفاق. يجعل عدم القابلية للعكس تشفيريًا تصدير Full Viewing Key موحّد (UFVK) آمنًا لأنه يمنح رؤية كاملة للمحفظة من دون كشف أسرار الإنفاق الموجودة على الجهاز.
2. مفاتيح العرض
يفصل Zcash القدرة على رؤية النشاط المحمي عن القدرة على إنفاقه. يسمح مفتاح العرض لمحفظة أو طرف آخر مفوّض بعرض معلومات عن المعاملات المحمية من دون منح صلاحية الإنفاق.
- Full Viewing Key (FVK)، مغلفًا بوصفه Full Viewing Key موحدًا (UFVK): مشتق عمدًا من مفتاح الإنفاق، ويسمح للبرمجيات بكشف نشاط المحفظة المحمي وفك تشفيره، وبذلك تحديد المعاملات. كما يسمح لها بحساب الأرصدة من دون القدرة على تفويض إنفاق. ومن الأفضل وصفه بأنه مشتق أقل خصوصية من مفتاح الإنفاق، لا نسخة أضعف من البذرة.
يوفر Full Viewing Key (FVK) رؤية كاملة للقراءة فقط مع الحفاظ على فصل أمني صارم. ومن خلال فك تشفير نصوص المذكرات الواردة والصادرة معًا (عبر مكوّن مفتاح العرض الصادر)، تستطيع المحفظة المرافقة التي لا تمتلك سوى FVK عرض سجل معاملات كامل وموسوم، بدلًا من مجرد رصيد تراكمي.
تشترك عدة عناوين دفع متنوعة غير قابلة للربط في FVK نفسه ومفتاح العرض الوارد (IVK)، ما يسمح بتوليد عناوين بلا حد من دون زيادة أعباء مسح البلوكشين.
يشكل هذا الفصل الوظيفي أساس تدفقات عمل التوقيع البارد. يُنقل كل مسح مستمر للسلسلة وتتبع للسجل وإدارة للعناوين إلى برمجيات المضيف، بينما تبقى صلاحية الإنفاق معزولة على جهاز الأجهزة.
التمييز الحاسم: UFVK مقابل مفتاح الإنفاق
يمكن مشاركة UFVK. يجب أن يبقى مفتاح الإنفاق على محفظة الأجهزة.
تستخدم المحفظة المرافقة مفتاح العرض لمراقبة المحفظة، وكشف الأموال الواردة، وتحديد المذكرات، والمساعدة في إعداد المعاملات. ولا تملك المفتاح الخاص اللازم لتفويض الإنفاق.
كما ذُكر سابقًا، فإن فصل المفاتيح هو أساس بنية التوقيع البارد.
تستطيع المحفظة المرافقة تنفيذ معظم العمل اللازم لإعداد معاملة من دون امتلاك السيطرة على الأموال مطلقًا. ولا تحتاج محفظة الأجهزة إلا إلى تلقي المعاملة المُعدة وإجراء عملية التوقيع النهائية.
لا تحتاج الشركات المصنعة لمحافظ الأجهزة إلى اختراع هذا الفصل بنفسها. يفصل تصميم مفاتيح Zcash بالفعل بين قدرات العرض وصلاحية الإنفاق على مستوى البروتوكول، ولا تفعل الشركات المصنعة سوى بناء وظائف التوقيع والتصدير فوق هذا الهيكل القائم. يسمح البروتوكول باشتقاق معلومات مثل عنوان محمي أو مفتاح عرض كامل من مفتاح إنفاق، بينما يظل مفتاح الإنفاق نفسه خاصًا، ما يتيح لمحافظ الأجهزة مثل Ledger وKeystone وHito منح البرمجيات المرافقة معلومات العرض التي تحتاجها دون كشف المفتاح الخاص القادر على إنفاق الأموال مطلقًا.
ما الذي تفعله المحفظة المرافقة فعليًا بمعلومات المفتاح
باستخدام مادة مفتاح العرض، تستطيع المحفظة المرافقة:
- تحديد أموالك ومذكراتك
- تحديد المذكرات التي يمكن إنفاقها
- اشتقاق العناوين ذات الصلة أو تحديدها
- بناء المعاملة
- إنشاء الإثباتات المطلوبة أو تنسيقها
- إعداد المعاملة للتوقيع
من المهم معرفة أن الحاجة إلى بناء معاملة ليست مماثلة للحاجة إلى مفتاح الإنفاق الخاص. ويُعد هذا الفصل أحد الأفكار الأمنية الأساسية وراء دمج محافظ الأجهزة.
بناء المعاملة المحمية وتفويضها
هذه هي العمليات المتضمنة في إنشاء المعاملة وتفويضها. وبعبارات بسيطة، فهي ما تفعله المحفظة فعليًا بتلك البيانات لإرسال الأموال:
بناء المعاملة (تجميع المعاملة المحمية)
بناء المعاملة هو عملية تجميع المعلومات اللازمة لإنشاء معاملة Zcash صالحة من الدفعة التي يقصدها المستخدم.
تجمع عملية بناء المعاملة المذكرات المحددة والمستلمين والمبالغ والرسوم والمُبطِلات وغيرها من بيانات المعاملة المطلوبة في هيكل للمعاملة. وبالنسبة للمعاملات المحمية، فإنها تُعد أيضًا المعلومات اللازمة لتوليد إثباتات المعرفة الصفرية والتوقيعات الضرورية.
تؤدي المحفظة المرافقة هذه المرحلة عمومًا. وهي:
- تختار المذكرات المراد إنفاقها
- تحدد مدخلات المعاملة ومخرجاتها
- تحسب القيم اللازمة
- تُعد بيانات المعاملة التي سيُثبت لاحقًا صحتها ويُوقَّع عليها.
في إعداد توقيع بارد، يمكن تجميع بيانات المعاملة الناتجة في PCZT وتمريرها إلى محفظة الأجهزة لتنفيذ خطوة التوقيع الحرجة أمنيًا.
الإثبات (إظهار صحة البروتوكول)
يشير الإثبات إلى توليد إثباتات المعرفة الصفرية (مثل Halo 2 أو Groth16) التي تُظهر أن المعاملة تتبع قواعد بروتوكول Zcash.
يساعد الإثبات الشبكة على ضمان:
- أن مستخدم الإنفاق مخول بإنفاق المذكرات
- أن المذكرات موجودة فعليًا
- أن المُبطِلات المقابلة فريدة
- أن إجمالي المدخلات يساوي إجمالي المخرجات زائد الرسوم.
ويؤدي كل ذلك دون كشف أي تفاصيل خاصة أساسية.
يتطلب توليد الإثباتات قدرة حسابية مكثفة. ومنع تحميل هذه المسؤولية على جهاز المرافقة محفظة الأجهزة من التوقف أو نفاد الذاكرة.
التوقيع (تفويض الإنفاق)
يختلف التوقيع جوهريًا عن الإثبات. يعمل التوقيع الرقمي كختم تفويض صريح ينتجه حامل المفتاح الخاص.
بينما يتحقق إثبات المعرفة الصفرية من صحة المعاملة، يثبت التوقيع الرقمي صلاحية الإنفاق. ويؤكد التوقيع أن المالك الحقيقي يوافق على معلمات التحويل المحددة.
يتطلب التوقيع قدرة حوسبة ضئيلة، ما يجعله مثاليًا لمحفظة أجهزة.
ما هو التوقيع البارد للمعاملات المحمية؟
التوقيع البارد للمعاملات المحمية هو طريقة لتفويض معاملة Zcash محمية مع إبقاء مفاتيح الإنفاق الخاصة معزولة عن المحفظة المرافقة المتصلة بالإنترنت. يمكن بناء المعاملة وإعدادها على حاسوب متصل بالإنترنت، بينما تستخدم محفظة أجهزة منفصلة، تبقى غير متصلة أو معزولة بطريقة أخرى، مفاتيحها المحمية لتفويض المعاملة.
يمكن تبسيط العملية كالآتي:
ترسل المحفظة المرافقة معلمات المعاملة المنظمة إلى جهاز الأجهزة، الذي يوقع الحمولة داخليًا من دون إطلاق مفتاح الإنفاق الخاص إلى الجهاز المضيف مطلقًا.
المحافظ المرافقة ومحافظ الأجهزة
يمكن أن تشمل المعاملات المحمية كلاً من محفظة مرافقة ومحفظة أجهزة، بحيث تؤدي كل منهما وظيفة مميزة.
المحفظة المرافقة
ما هي المحفظة المرافقة؟
تعمل المحفظة المرافقة على حاسوب أو جهاز محمول وتنفذ معظم المهام المتضمنة في إنشاء المعاملة، مثل:
- اختيار المذكرات التي سيجري إنفاقها
- بناء المعاملة
- حساب بيانات المعاملة اللازمة
- تنسيق توليد إثباتات المعرفة الصفرية المطلوبة.
لماذا تكون المحفظة المرافقة مفيدة؟
تتولى المحفظة المرافقة عملية إنشاء المعاملة، لكن إذا أصيب الحاسوب ببرمجيات خبيثة، فقد يستطيع المهاجم:
- رؤية ما تفعله،
- تعديل معاملة غير موقعة،
- محاولة خداعك للموافقة على شيء ما.
لا تحتاج المحفظة المرافقة إلى الوصول إلى المفتاح الخاص المخزن في محفظة الأجهزة، ولذلك يمكنها التعامل مع بناء المعاملات وغيرها من المهام الحسابية، بينما توفر محفظة الأجهزة الحد الأمني للمفتاح الخاص.
محفظة الأجهزة
محفظة الأجهزة هي جهاز مادي غير متصل يعزل مفاتيحك الخاصة عن الهواتف أو الحواسيب المتصلة، ويعمل كخزنة آمنة لأصولك المشفرة.
لماذا تكون محفظة الأجهزة مفيدة؟
إذا أصيب حاسوبك ببرمجيات خبيثة، فقد يستطيع المهاجم:
- رؤية ما تفعله،
- تعديل معاملة غير موقعة،
- محاولة خداعك للموافقة على شيء ما.
لا يمكن ببساطة استخراج المفتاح الخاص من محفظة الأجهزة، ولذلك يمكن للجهاز أن يعمل كحد أمني.
صورة قدرات المحفظة المرافقة مقابل الأجهزة
يُعد الفصل بين هاتين المحفظتين مهمًا بصفة خاصة للمعاملات المحمية لأنها أكثر تعقيدًا من المعاملات الشفافة، وتتضمن مكونات مثل المذكرات المحمية والمُبطِلات والالتزامات وإثباتات المعرفة الصفرية وتوقيعات المعاملات.
لن يكون عمليًا أن تنفذ محفظة الأجهزة كل عملية حسابية. بدلًا من ذلك، تُعد المحفظة المرافقة المعاملة وتوفر المعلومات اللازمة لمحفظة الأجهزة للتوقيع، بينما يبقى مفتاح الإنفاق الخاص معزولًا داخل جهاز الأجهزة.
عزل المفاتيح
يعني عزل المفاتيح أن المفاتيح الخاصة القادرة على تفويض إنفاق لا تغادر محفظة الأجهزة مطلقًا. تستطيع المحفظة المرافقة إعداد المعاملة؛ لكنها لا تستطيع توقيعها.
يشير عزل المفاتيح إلى إبقاء المفاتيح الخاصة اللازمة لتفويض معاملة منفصلة عن المحفظة المرافقة والجهاز الذي تعمل عليه. في إعداد توقيع بارد محمي، تستطيع المحفظة المرافقة بناء المعاملة وتنسيق الإثباتات المطلوبة، بينما تبقي محفظة الأجهزة مفاتيح الإنفاق الخاصة الحساسة معزولة.
إذا تعرض حاسوب أو هاتف المرافقة للاختراق، فقد يستطيع المهاجم التفاعل مع المعاملة قبل توقيعها، لكنه من الناحية المثالية لا يستطيع استخراج المفتاح الخاص من محفظة الأجهزة. ولذلك يبقى المفتاح ضمن الحد الأمني لجهاز الأجهزة.
يسمح هذا الفصل للمحفظة المرافقة بتنفيذ بناء المعاملات والمهام الحسابية من دون منحها وصولًا مباشرًا إلى مادة المفتاح اللازمة لتفويض المعاملة.
التمييز الأساسي الذي ينبغي إجراؤه هو أن «مفتاح العرض» لا يعني أن التطبيق يتلقى نسخة أضعف من البذرة.
في Zcash، يُشتق Full Viewing Key (FVK/UFVK) عمدًا من مفتاح الإنفاق ويمنح حامله القدرة على كشف وفك تشفير النشاط المحمي ذي الصلة، لكن ليس تفويض الإنفاقات. إن FVK مشتق أقل سرية من مفتاح الإنفاق.
تنبيه مهم متعلق بالخصوصية:
لذلك ينبغي معرفة أن التطبيق لا يستطيع سرقة الأموال باستخدام UFVK فقط، لكنه يستطيع رؤية النشاط المحمي الخاص بالمحفظة.
ولهذا من الأدق وصف التطبيق المرافق بأنه يمتلك صلاحية عرض، بدلًا من القول ببساطة إنه يمتلك «معلومات عامة».
أبسط طريقة لعرض الفكرة كاملة هي أن المحفظة المرافقة تحصل على ما يكفي من مادة المفتاح لمعرفة ما يحدث للمحفظة، لكن ليس ما يكفي من مادة المفتاح لتفويض ما يحدث لأموال المحفظة. أما محفظة الأجهزة، فتبقي صلاحية الإنفاق معزولة ولا تستخدمها إلا حين يوافق المستخدم على معاملة.
هذا هو نموذج عزل المفاتيح الأساسي وراء تصميمات محافظ الأجهزة المحمية الخاصة بـ Zcash، وهو النموذج نفسه الذي يظهر، تنفيذًا بعد تنفيذ، في Ledger وKeystone وHito، والتي ستُغطى قريبًا.
PCZT
يرمز PCZT إلى معاملة Zcash المُنشأة جزئيًا. وهي الحزمة التي تحمل معاملة Zcash والمعلومات اللازمة لإكمالها من مرحلة إلى أخرى.
إنه تنسيق موحد لمعاملة Zcash بينما لا تزال المعاملة قيد البناء. ويسمح لمشاركين أو أجهزة مختلفة بتنفيذ أجزاء مختلفة من عملية إنشاء المعاملة وتمرير المعاملة المكتملة جزئيًا بينها.
إن بناء معاملة أكثر تعقيدًا بكثير من توقيع تحويل عام بسيط في بروتوكولات العملات المشفرة ذات المعرفة الصفرية مثل Zcash. تتطلب المعاملات المحمية إثباتات معرفة صفرية كثيفة حاسوبيًا، مثل تلك المُولدة باستخدام Halo 2 أو Groth16. ونتيجة لذلك، قد تفتقر الأجهزة منخفضة الطاقة مثل محافظ الأجهزة إلى الذاكرة وقدرة المعالجة للتعامل مع سير عمل المعاملة بالكامل.
يعالج إدخال PCZT عدة تحديات أساسية في بنية العملات المشفرة المحمية. إن PCZT تنسيق بيانات وسيط موحد يقسم إنشاء المعاملة إلى أدوار معيارية ومستقلة. ويسمح لحاسوب مرافق قوي بالتعامل مع تجميع المعاملة وتوليد الإثباتات، مع قصر محفظة أجهزة غير متصلة بشكل صارم على التفويض والتوقيع.
قيود الأجهزة والتخزين البارد
رغم أن محافظ الأجهزة توفر بيئة آمنة لحماية مفاتيح الإنفاق الخاصة، فإنها تملك عادةً ذاكرة RAM وقدرة حوسبة وقدرات نقل بيانات محدودة مقارنة بحواسيب المرافقة. تجعل هذه القيود تنفيذها لتوليد إثباتات المعرفة الصفرية الكثيفة حاسوبيًا أو الاحتفاظ بحالة المعاملة الكاملة اللازمة أثناء عملية بناء المعاملة أمرًا غير عملي.
ونتيجة لذلك، تستطيع المحفظة المرافقة التعامل مع المهام المتطلبة حاسوبيًا، بينما تظل محفظة الأجهزة مركزة على العملية الحرجة أمنيًا المتمثلة في تفويض المعاملة باستخدام مفاتيح الإنفاق المحمية الخاصة بها.
وهذا يجعلك تتساءل: إذا كان الجهاز مقيدًا إلى هذا الحد، فكيف يبقى قادرًا على تنفيذ قدر كافٍ من التحقق ليكون جديرًا بالثقة؟
ببساطة، لا تستطيع محفظة الأجهزة قبول قيمة عشوائية من حاسوب مرافق وتوقيعها. فهي تحتاج إلى معلومات كافية لإثبات أن القيمة الموقعة تقابل المعاملة التي يقصد المستخدم تفويضها. ويخلق هذا توازنًا صعبًا، لأن الجهاز يجب أن ينفذ قدرًا كافيًا من التحليل والتحقق لحماية عملية التوقيع، مع العمل ضمن حدود صارمة للذاكرة والحوسبة وحجم البرنامج الثابت وتعقيد التنفيذ.
تعد معالجة Ledger لـ Orchard PCZT مثالًا على هذا التحدي، إذ تشير إلى أن التحليل المتخصص المعتمد على الدارة يمكن أن يجعل التنفيذ أسهل إدارة على الأجهزة المقيدة، لكنه قد يتطلب أيضًا تغييرات في البرنامج الثابت عند تطور هياكل المعاملات أو الدارات المدعومة.
يوضح مسعيان مستمران استجابتين مختلفتين لهذا القيد نفسه.
طُرح مقترح بحثي بشأن خط أنابيب إثبات بزمن ثابت بالكامل ومناسب لبنيات محافظ الأجهزة مفتوحة المصدر والحواسيب العادية في المنحة رقم 423. وكان الهدف دراسة بنية تحتية تشفيرية يمكن تنفيذها بأمان في بيئات مثل C أو Rust، مع تقليل عبء التعقيد والصيانة لدعم Zcash المحمي.
لكن نهجًا بديلًا يمثله Zcash SeedSigner المقترح، وهو موقّع مفتوح المصدر ومعزول هوائيًا مبني من مكونات متاحة بسهولة ومنخفضة التكلفة. يُبقي سير العمل المقترح الحاسوب المرافق منفصلًا عن جهاز التوقيع، ويمرر PCZT عبر فجوة هوائية للتحقق والتوقيع على الجهاز.
https://forum.zcashcommunity.com/t/grant-application-research-on-a-fully-constant-time-proving-pipeline-for-open-source-hardware-wallet-architectures-reusable-for-standard-computers/57555
توضح هذه الأساليب معًا التحدي الهندسي الأوسع وراء محافظ الأجهزة المحمية: يمكن أن يحدث بناء المعاملة والإثبات خارج الجهاز الحرج أمنيًا، لكن يجب أن يظل لدى الموقّع معلومات وقدرة تحقق كافيتان لتفويض المعاملة الناتجة بأمان.
PCZT يتيح البنية المنقسمة
إن معيار المعاملة Zcash المُنشأة جزئيًا (PCZT) هو بنية البيانات الرسمية التي تصل المحفظة المرافقة بمحفظة الأجهزة.
تستطيع المحفظة المرافقة التعامل مع اختيار المذكرات، وحساب المُبطِلات، وتوليد إثبات المعرفة الصفرية من تلقاء نفسها. وهذا ممكن لأن المعلومات اللازمة لهذه الخطوات، بما فيها المفتاح المستخدم لاشتقاق المُبطِلات، تأتي من مفتاح العرض لا من أي شيء مرتبط بصلاحية الإنفاق. ثم تجمع المحفظة المرافقة هذه العناصر في حاوية PCZT.
يُسلَّم PCZT إلى محفظة الأجهزة، التي تقرأ سياق المعاملة (مثل المبالغ وعناوين المستلمين)، وتطبق التوقيع باستخدام مفاتيح الإنفاق المحمية الخاصة بها، وتعيد PCZT المحدّث إلى جهاز المرافقة.
ينشئ هذا التصميم حدًا أمنيًا صارمًا: يمكن لأجهزة المضيف القوية تنفيذ رياضيات المعرفة الصفرية المعقدة دون الحاجة إلى الوصول إلى مفاتيح الإنفاق، بينما تستطيع أجهزة التخزين البارد منخفضة الطاقة فرض الأمان المالي دون الحاجة إلى حساب تشفير ثقيل.
تنازلات خصوصية المُثبِت
رغم أن تفويض توليد إثبات المعرفة الصفرية إلى المحفظة المرافقة أو مُثبت آخر يبقي مفاتيح الإنفاق معزولة، فإنه يتطلب من المُثبت الوصول إلى معلومات معاملة حساسة، مثل قيم المذكرات وعناوين المستلمين والالتزامات.
يحافظ PCZT على الفصل البنيوي من خلال ضمان إمكانية توفير هذه المعلومات للإثبات دون نقل مفاتيح الإنفاق الخاصة المطلوبة للتفويض.
وهذا يضمن فصل صلاحية الإثبات عن صلاحية الإنفاق. يستطيع المُثبت تنفيذ توليد الإثبات المكثف حاسوبيًا من دون الحصول على الصلاحية التشفيرية لإنفاق أموال المستخدم.
قابلية التشغيل البيني لـ PCZT
بما أن PCZT يصبح جزءًا مهمًا من تدفقات عمل محفظة أجهزة Zcash والتوقيع متعدد التوقيعات والتوقيع المعزول هوائيًا، تصبح قابلية التشغيل البيني بين التطبيقات المستقلة مهمة على نحو متزايد.
أشار مقترح من AngryDavee في يونيو 2026 إلى أن تطبيقات PCZT كانت موجودة بالفعل عبر مشاريع تشمل Ledger وKeystone وHito وOneKey والتطبيق المرجعي في librustzcash. لكن المقترح حدد غياب اختبارات مشتركة لتأكيد أن هذه التطبيقات تفسر PCZTs باستمرار.
كان الحل المقترح عبارة عن مجموعة اختبارات توافق تشغيلي مفتوحة المصدر تحتوي على متجهات اختبار PCZT معيارية واختبارات عبر التطبيقات تغطي سير العمل الكامل إنشاء ← توقيع ← إنهاء. كما اقترح اختبار حدود الأدوار مثل Combiner، حيث يمكن جمع معلومات موقعة جزئيًا من موقّعين مختلفين قبل إنهاء معاملة.
وهذا ذو صلة خاصة بمحافظ الأجهزة لأن PCZT يسمح بفصل بناء المعاملة عن توقيعها: تستطيع المحفظة المرافقة بناء معاملة وإعداد PCZT، بينما يتلقى جهاز الأجهزة معلومات التوقيع المطلوبة وينفذ عملية التوقيع الحرجة أمنيًا.
لم يُنفذ المقترح لأن Zcash Community Grants قرر عدم المضي قدمًا في المنحة بعد مراجعة المقترح والنظر في ملاحظات المجتمع. ونتيجة لذلك، لم تُطور مجموعة الاختبارات المقترحة عبر التطبيقات من خلال هذه المنحة. ولذلك فهي استجابة مقترحة لتحدي قابلية التشغيل البيني المحدد في PCZT، وليست معيارًا قائمًا حاليًا عبر Zcash.
https://forum.zcashcommunity.com/t/pczt-interoperability-test-suite-feedback-before-at-grant-submission/55931
دورة حياة PCZT
| # | المرحلة | الوصف |
|---|
| 1 | المنشئ | يهيئ PCZT ببيانات وصفية عالمية للمعاملة، تشمل إصدارات المعاملات ومعرفات فروع الإجماع وأعلام المجمعات. |
| 2 | الباني | يملأ المعاملة بالمدخلات والمخرجات المقصودة عبر المجمعات الشفافة أو Sapling أو Orchard أو Ironwood. |
| 3 | مُنهي IO | يعلن اكتمال مجموعة المدخلات والمخرجات، ويحسب مفاتيح توقيع الربط، ويوقع إنفاقات وهمية عند الحاجة. |
| 4 | المُحدِّث | يرفق بيانات السياق اللازمة للمشاركين اللاحقين، مثل مفاتيح العرض الكاملة والمراسي وشهود Merkle. |
| 5 | المُثبت والموقّع | ينفذ توليد إثباتات المعرفة الصفرية والتوقيع التشفيري. في إصدارات PCZT الحديثة، تكون هاتان المهمتان مستقلتين تمامًا ويمكن أن تحدثا بالتتابع أو بالتوازي. |
| 6 | الجامع | يدمج عدة مثيلات من PCZT بصورة حتمية إذا عملت أجهزة مختلفة على جوانب من المعاملة نفسها في آن واحد. تتطلب قواعد الدمج حلًا صارمًا للتعارضات لمنع فقدان البيانات عرضًا. |
| 7 | مُنهي الإنفاق والمستخرج | يتحقق من جميع العناصر التشفيرية المطلوبة، ويزيل بيانات السياق الوسيطة، وينتج معاملة Zcash نهائية جاهزة للبث إلى الشبكة. |
تطبيقات محافظ الأجهزة في العالم الحقيقي
نظرة سريعة
| الجهاز | ما تتلقاه المحفظة المرافقة | ما يبقى على الجهاز | النقل |
|---|
| Ledger | UFVK / Orchard FVK، العناوين | صلاحية الإنفاق | USB / BLE |
| Keystone | UFVK + Unified Address | البذرة / مفاتيح الإنفاق | QR (معزول هوائيًا) |
| Hito | UFVK، Unified Address، بصمة البذرة | البذرة ومفاتيح الإنفاق الخاصة | QR / محلي |
طُورت عدة تطبيقات لمحافظ الأجهزة لاستكشاف كيفية دعم معاملات Zcash المحمية مع إبقاء مفاتيح الإنفاق الحساسة معزولة عن المحفظة المرافقة. تمثل Ledger وKeystone وHito أساليب مختلفة لدمج حماية المفاتيح المعتمدة على الأجهزة مع سير عمل معاملات Zcash.
لفهم كيفية حمايتها للأموال المحمية، من المهم التمييز بين مفاتيح الإنفاق ومفاتيح العرض. عبر الأجهزة الثلاثة، يتبع الفصل الشكل نفسه:
| الجهاز | ما يمكن أن يتلقاه تطبيق المرافقة | ما يبقى محميًا على الجهاز |
|---|
| Ledger | UFVK / Orchard FVK، العناوين والمعلومات العامة | صلاحية الإنفاق / مادة المفتاح الخاص |
| Keystone | UFVK + Unified Address | البذرة / مفاتيح الإنفاق |
| Hito | UFVK، Unified Address، بصمة البذرة ومعلومات الشبكة | البذرة ومفاتيح الإنفاق الخاصة |
Ledger بوصفه بيئة توقيع الأجهزة
Ledger شركة محافظ أجهزة. بُنيت أجهزتها حول Secure Element، وهي شريحة مخصصة صُممت للاحتفاظ بمادة المفتاح الخاص وإبقائها معزولة ماديًا عن بقية الجهاز وعن أي شيء متصل به. ويُعد Secure Element السبب كله الذي يجعل جهاز Ledger جديرًا بالثقة للتخزين البارد. وهذا يعني أنه حتى لو تعرض الحاسوب أو الهاتف الموصول به للاختراق، فلا يمكن استخراج المفاتيح داخل Secure Element.
لكن جهاز Ledger بمفرده فارغ فيما يخص أي عملة مشفرة محددة. فهو يحتاج إلى تطبيق مثبت عليه يعرف كيفية التعامل مع التشفير الخاص بتلك العملة.
يكون جهاز Ledger فارغًا فيما يخص أي عملة مشفرة محددة، ولذلك يحتاج إلى تطبيق يعرف تشفير تلك العملة. بالنسبة إلى Zcash، كان هناك جيلان:
- تطبيق “Zcash Shielded” الأصلي الذي بنته Zondax، ويُستخدم مع محافظ مرافقة مثل Zkool، ويجري سحبه في 5 نوفمبر 2026، و
- تطبيق Zcash الأحدث من Ledger (3.9.4+)، والذي تستخدمه أصلًا Ledger Wallet Desktop 4.21+ من أجل Ironwood المحمي ZEC.
ينطبق نموذج عزل المفاتيح أدناه على كليهما.
Zkool هي المحفظة المرافقة على هاتفك أو حاسوبك التي تتواصل مع ذلك التطبيق. وهي تبني المعاملة، وترسلها إلى Ledger، ثم يوقعها تطبيق Zondax على الجهاز ويرسل التوقيع مرة أخرى.
لذلك فإن Zondax هي البرمجيات العاملة على الأجهزة، وZkool هي البرمجيات العاملة خارجها التي تستخدم تطبيق Zondax للتواصل مع الجهاز.
ما الذي يغادر Ledger؟
تتضمن برمجيات Ledger الخاصة بـ Zcash وظيفة محددة لتصدير مفتاح عرض المحفظة، وهو المفتاح الذي يسمح للبرمجيات برؤية الأرصدة والمعاملات دون القدرة على إنفاق أي شيء.
يمكن أن تعيد هذه الوظيفة أحد شيئين:
- Full Viewing Key موحد (UFVK)، وهو مفتاح العرض الكامل الذي يغطي كل مجمعات Zcash المحمية دفعة واحدة، أو
- Orchard Full Viewing Key (FVK)
في كلتا الحالتين، ما يخرج ليس سوى مفتاح عرض. وبصرف النظر عن الإصدار الذي تطلبه، لا تملك هذه الوظيفة أي طريقة لإعادة الجزء الوحيد من المعلومات الذي سيسمح فعلًا لشخص بنقل الأموال، وهو مفتاح الإنفاق.
وهذا هو جوهر طريقة بنائها، إذ صُممت بحيث إن الشيء الوحيد القادرة على تصديره هو شيء آمن لتسليمه إلى تطبيق مرافق.
بُني تسلسل مفاتيح Zcash بحيث يشتق مفتاح الإنفاق، لكل مجمع محمي، شيئين منفصلين:
- مفتاح تفويض إنفاق، و
- مفتاح عرض كامل
يمكن لـ FVK بعد ذلك اشتقاق قدرات أخرى خاصة بالعرض، لكن مسار الاشتقاق هذا لا يؤدي في أي نقطة إلى صلاحية الإنفاق. وما إن يتفرع المفتاح إلى جانب العرض من التسلسل الهرمي، فإنه يبقى هناك ولا يمكن استخدامه لإعادة بناء مفتاح صلاحية الإنفاق الذي جاء منه.
يتبع Ironwood النمط نفسه، لأنه يعيد استخدام البنية الأساسية لمفاتيح ومذكرات Orchard. لكنه مع ذلك مجمع مميز على مستوى الإجماع، وله شجرة التزام ومجموعة مُبطِلات خاصتان به. وهذا يعني أن UFVK هو في الواقع حزمة من مفاتيح العرض لكل مجمع (شفاف، Sapling، Orchard، والآن Ironwood)، لا مفتاحًا مسطحًا واحدًا.
لن يتضمن UFVK صُدّر قبل تفعيل Ironwood مفتاح عرض Ironwood، لأن ذلك المجمع لم يكن موجودًا بعد. وهذا تحديدًا سبب حاجة المحافظ إلى التحديث للتعرف على UFVKs القادرة على Ironwood واشتقاقها بعد ترقية NU6.3.
ما الذي يبقى على Ledger؟
تبقى صلاحية الإنفاق على الجهاز.
يتلقى موقّع Ledger معاملة/PCZT من المضيف وينشئ توقيع تفويض الإنفاق اعتمادًا على المجمع الذي تنفق منه المعاملة (مجمع Ironwood لأن تكامل Ledger الحالي يدعم Ironwood فقط). ثم يُنتج التوقيع على الجهاز، ولا يتلقى المضيف إلا التوقيع، لا مفتاح الإنفاق الخاص.
وهذا يتسق أيضًا مع نموذج الأمان العام لـ Ledger. يعزل Secure Element الخاص به مادة المفتاح الخاص، وتحظر متطلبات أمان التطبيقات في Ledger تحديدًا على التطبيقات كشف تلك الأسرار للمضيف.
يمكن لموقّع Ledger تصدير FVK/UFVK مع تنفيذ توقيع المعاملة بصورة مستقلة. تُوفَّر القدرتان عبر وظائف منفصلة، وليستا مجمعتين في وظيفة واحدة.
ماذا يعني ذلك عمليًا؟
افترض أن Ledger يحتوي على 10 ZEC.
يمكن للمحفظة المرافقة أن تمتلك UFVK، وبالتالي تحدد: «تلقت هذه المحفظة 10 ZEC.» ويمكنها مسح المعاملات والأرصدة وعرضها.
لكن إذا اخترق شخص ما المحفظة المرافقة، فإن UFVK وحده لا يمنحه القدرة على إنشاء توقيع تفويض الإنفاق.
الغرض من توقيع تفويض الإنفاق المنفصل هو تمكين الأجهزة المقيدة، مثل محافظ الأجهزة، من تفويض الإنفاقات المحمية دون الاضطرار إلى تنفيذ إثبات zk-SNARK الكامل بنفسها.
تطبيق Zondax Ledger؛ جانب محفظة الأجهزة
ما هو Zondax؟
Zondax شركة تطوير خارجية بنت تطبيق Ledger Zcash. وهو تطبيق البرنامج الثابت الفعلي الذي يعمل على أجهزة Ledger ويمنح الجهاز القدرة على فهم ومعالجة معاملات Zcash من الأساس.
Zondax مطور خارجي. لا تمتلك أجهزة Ledger قدرة فطرية على معالجة معاملات Zcash، وتأتي هذه القدرة بالكامل من برمجيات Zondax.
تنفيذ Zcash Ledger الأصلي
مستودع تطبيق Zondax Ledger Zcash هو البرمجيات التي تعمل على جهاز Ledger. ركز التطبيق في البداية على معاملات Sapling المحمية، قبل وجود Orchard بوصفه مجمع Zcash المحمي الأساسي، ولذلك كان دعم Sapling هو نطاق ما يمكن لجهاز Ledger فعله مع ZEC المحمي.
توضح بنيته الفصل، حيث يُعد جانب المضيف/المرافق معلومات المعاملة بينما يتعامل Ledger مع عمليات المفاتيح الحساسة والتوقيع.
حتى في هذه النسخة الأولى جدًا من دعم محفظة أجهزة Zcash، كانت المبادئ الأساسية، وهي البناء والإثبات على المضيف ثم التوقيع المعزول على الجهاز، هي التصميم بالفعل.
التطور نحو Orchard
انتقل عمل Ledger نحو Orchard + PCZT. كان هذا انتقالًا ذا معنى لا تحديثًا بسيطًا، نظرًا إلى أن Orchard يستخدم نظام إثبات مختلفًا (Halo 2، مقابل Groth16 في Sapling) وبنية مختلفة للمذكرات والمفاتيح، لذا فإن توسيع برنامج ثابت خاص بـ Sapling فقط للتعامل مع توقيع Orchard تطلب أساسًا تشفيريًا جديدًا من جانب الجهاز، لا مجرد رقعة للبرنامج الثابت.
لكن مع انتقال Zcash نحو Ironwood، حول Zondax وLedger تركيز تطويرهما نحو دعم Ironwood مباشرة، بدلًا من إكمال تنفيذ Orchard ثم إعادة تصميمه لاحقًا لـ Ironwood. ويمثل ذلك مرحلة إضافية في تطور تنفيذ Ledger، إذ يبني Ironwood على البنية التشفيرية لـ Orchard مع إدخال مجمع محمي منفصل وتغييرات بروتوكول إضافية.
ما يحدث داخل تطبيق Ledger هذا
يوصف التدفق الناتج كالآتي:
- يبني المضيف PCZT.
- يرسل المضيف معلومات المعاملة ذات الصلة إلى جهاز Ledger.
- ينتج الجهاز توقيعات تفويض إنفاق Orchard.
- يتولى المضيف كل ما يلي ذلك، بما في ذلك توقيع الربط وتجميع المعاملة النهائي.
لا يرى التطبيق الذي يعمل داخل Ledger ولا ينتج أي شيء يتجاوز توقيع تفويض الإنفاق ذاته، ويبقى كل العمل الكثيف حاسوبيًا أو المتطلب للبيانات (الإثبات والربط والتجميع) على المضيف، حيث لا يلزم الوثوق به بمادة المفتاح.
التكامل المحمي الأصلي لـ Ledger؛ Ledger Wallet Desktop
يوفر أحدث تكامل لـ Ledger مع Zcash مثالًا ملموسًا لكيفية فصل بناء المعاملة المحمية والتوقيع الحرج أمنيًا بين برمجيات مرافقة ومحفظة أجهزة.
مع Ledger Wallet Desktop 4.21+ وتطبيق جهاز Zcash 3.9.4+، يمكن للمستخدمين إرسال Ironwood المحمي ZEC وتلقيه مباشرة عبر Ledger Wallet Desktop. يدعم التكامل التحويلات الخاصة إلى الخاصة، والتحصين من المجمع الشفاف، وإزالة التحصين إلى المجمع الشفاف، وعناوين التلقي الخاصة، والمذكرات. يجري التحقق من المعاملات وتوقيعها على جهاز Ledger بدلًا من الاعتماد فقط على المعلومات المعروضة من الحاسوب.
جزء أساسي من هذه البنية هو الفصل بين قدرات العرض والإنفاق. أثناء مزامنة الرصيد الخاص، يصدّر Ledger Full Viewing Key موحدًا (UFVK)، يُخزن محليًا على الحاسوب. يسمح UFVK لـ Ledger Wallet Desktop بكشف المعاملات المحمية ذات الصلة وتحديد رصيد المحفظة، لكنه لا يمنح صلاحية إنفاق الأموال. تبقى صلاحية الإنفاق الحرجة أمنيًا على جهاز Ledger، الذي ينفذ عملية التوقيع النهائية. ويخلق ذلك حدًا واضحًا بين الحاسوب، الذي يدير حالة المحفظة ويبني المعاملات، وجهاز الأجهزة، الذي يحمي القدرة اللازمة لتفويض الإنفاق.
لكن التكامل الحالي مخصص لـ Ironwood فقط. فهو لا يعرض أو يدير أموال Orchard أو Sapling عبر Ledger Wallet Desktop. وهذا مهم تاريخيًا لأن تطوير Ledger السابق لـ Zcash كان مرتبطًا بدعم Orchard المحمي قبل أن يتطور التنفيذ نحو بروتوكول Ironwood.
يسلط الانتقال الضوء أيضًا على أهمية توافق المفاتيح والحسابات. لدى Ledger تطبيق «Zcash Shielded» أقدم طوره Zondax وتستخدمه تكاملات مثل YWallet وzkool، وهو الآن قيد الإيقاف. ولأن ذلك التطبيق الأقدم استخدم مخطط اشتقاق مختلفًا للحسابات المحمية، فلا يمكن إعادة إنتاج حسابات Sapling ببساطة بواسطة تطبيق Ledger الجديد.
يوضح التكامل بالتالي كلا من التقدم والقيود المتبقية لدعم محافظ الأجهزة المحمية. يستطيع Ledger الآن توفير تجربة Ironwood كاملة تتولى فيها البرمجيات المرافقة مزامنة المحفظة وإعداد المعاملات، بينما يبقى جهاز الأجهزة الحد الأمني للإنفاق.
في الوقت نفسه، يبين توافق الحسابات التاريخي، ودعم مجمعات محمية محددة فقط، وحدود حجم معاملات الأجهزة، وقيود المنصة، والقيود الحسابية والبرامج الثابتة المتضمنة في تحليل المعاملات المحمية والتحقق منها، أن دعم محفظة الأجهزة لـ Zcash لا يعتمد فقط على قدرات البروتوكول، بل أيضًا على تصميم وموارد كل تطبيق فردي.
Zkool + Ledger — استخدام تطبيق Zondax الرسمي
باعتباره خليفة Ywallet، ورث Zkool هدف التوقيع البارد للمعاملات المحمية، لكنه اتخذ مسارًا مختلفًا لتحقيقه، تشكل مباشرة بفعل أن التشفير وحده لا يجعل التكامل قابلًا للاستخدام إذا لم يمكن توزيع تطبيق التوقيع بأمان.
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
استخدام Zkool لتطبيق Zondax
انتقل Zkool نحو استخدام تطبيق Ledger Zcash الرسمي الذي طوره Zondax، بدلًا من تطبيق Ywallet Ledger الخاص المهجور. وبدلًا من صيانة تطبيق مخصص لا يقبله متجر Ledger، بُني Zkool فوق التطبيق الذي كان مقبولًا وموزعًا بالفعل عبر منظومة Ledger نفسها.
يعني هذا التحول أن المستخدمين لم يعودوا بحاجة إلى الاعتماد على تثبيت تطبيق Ledger مخصص غير موقّع لاستخدام هذا التكامل، لأن تطبيق Zondax كان موزعًا رسميًا من خلال منظومة Ledger.
لكن هذا التكامل يواجه تغييرًا مهمًا في 5 نوفمبر 2026، حين يُتوقع أن ينتهي دعم تطبيق Zcash Shielded القديم مع قيام Ledger بإيقافه تدريجيًا. ولأن تكامل Zkool مع Ledger يعتمد على هذا التطبيق، يثير التغيير تساؤلات حول الإتاحة المستقبلية للاتصال القائم. ويتوقف الأثر الدقيق على Zkool على ما إذا كان بإمكانه مواصلة استخدام التطبيق القديم خارج Ledger Wallet أو الانتقال إلى بديل متوافق.
المجمعات المحمية المدعومة
وفقًا لمطور Ywallet، استخدم تكامل Zkool مع Ledger تطبيق Ledger الرسمي الذي طوره Zondax، ودعم Zcash الشفاف والمحصن معًا. لكن دعمه المحمي اقتصر على Sapling ولم يدعم Orchard، إلى جانب قيود تكامل أخرى مثل حد أقصى بخمسة مدخلات ومخرجات من كل نوع وغياب توافق Ledger Live.
عكس هذا القيد نطاق تنفيذ Zondax Ledger الأساسي في ذلك الوقت. وفر عمل Zondax السابق في Ledger دعم Sapling، واستبعد إصداره اللاحق في 2024 لتطبيق Zcash Shielded Ledger في البداية Orchard والعناوين الموحدة. ولذلك، ورث التكامل المبني حول ذلك التطبيق قدرات وقيود تنفيذ محفظة الأجهزة التي اعتمد عليها.
تطور الوضع لاحقًا مع إصدار تطبيق Zcash Shielded Ledger المخصص في نوفمبر 2024. ذكر Zondax أن التطبيق صدر رسميًا عبر Ledger Live، ونشر لاحقًا إرشادات التكامل وحزم Rust وJavaScript لتمكين محافظ أخرى من الدمج معه. ومع ذلك، عند الإطلاق، كان التطبيق يتواصل حصريًا مع Zecwallet Lite Desktop، بينما كانت تكاملات المحافظ الأوسع لا تزال قيد التطوير.
كانت المرحلة التالية تطوير تطبيق Ledger Rust الأحدث المعتمد على Zcash. بحلول يونيو 2026، أفاد Ledger بتنفيذ مشاركة UFVK وتوليد Orchard Unified Address، بينما ظل توقيع معاملات Orchard وClearSign قيد التطوير. وذكر Ledger أيضًا أن العمل سيمتد إلى مسار Ironwood مع تغير البروتوكول.
تطلب Ironwood لاحقًا تحديثات عبر منظومة محافظ Zcash. أصدر Zkool دعمًا للانتقال من Orchard إلى Ironwood بدءًا بالإصدار 6.24.0، واستمر في تحسين مسار الانتقال والمعاملات في الإصدارات اللاحقة. ودمج Ledger، بصورة منفصلة، توقيع PCZT v2 في تطبيقه الجديد في 27 يوليو، رغم أن التنفيذ لم يكن قد أكمل بعد مراجعة Ledger وطرح Ledger Live بحلول 20 أغسطس، وهي مرحلة أُنجزت منذ ذلك الحين، إذ يقدم Ledger Wallet Desktop 4.21+ الآن دعم Ironwood أصليًا مباشرة.
https://forum.zcashcommunity.com/t/a-path-forward-for-ledger-and-zcash/50951/177
لذلك، من الأفضل فهم التطور لا بصفته ترقية واحدة من Zondax إلى Ironwood، بل كتطورات متعددة مترابطة: تنفيذ Sapling الأصلي الذي ركز على Zondax، وتطبيق Zcash Shielded Ledger لعام 2024، وتطبيق Ledger Rust الأحدث بدعم Orchard وPCZT، والتكامل الأصلي لـ Ledger في Ledger Wallet Desktop، والتحديثات المتوازية لمحافظ مثل Zkool مع انتقال المنظومة إلى Ironwood.
دعم أجهزة ومنصات Ledger الحالي لـ Zcash
يعتمد دعم Zcash على Ledger على:
- طراز الجهاز
- التطبيق المثبت
- المنصة المستخدمة لإدارته، و
- ما إذا كانت المعاملة شفافة أم محمية.
اعتبارًا من 21 يوليو 2026 (آخر تحديث لـ Ledger)، يدعم تطبيق Zcash Shielded أجهزة Nano S Plus وStax وFlex، لكنه لا يدعم بعد Nano X أو Nano Gen5.
ما زال بإمكان Nano X والطرازات الأخرى باستثناء Nano S الأصلي استخدام تطبيق Zcash الكلاسيكي، الذي يدعم المعاملات الشفافة وإنفاق الأموال المحمية إلى عناوين شفافة (إزالة التحصين)، لكن ليس التوقيع من محمي إلى محمي. ولا يدعم Nano S الأصلي أيًا من التطبيقين، لأن Ledger يوقف دعم الجهاز تدريجيًا ولأن أحدث تطبيق Zcash غير متاح عليه. تتصل الأجهزة بـ Ledger Wallet (المعروف سابقًا باسم Ledger Live)، وهو تطبيق المرافقة الخاص بـ Ledger، والمتاح على سطح المكتب لـ Windows وmacOS وLinux، وعلى الهاتف المحمول لـ iOS وAndroid.
أضاف Ledger دعم Zcash محميًا أصليًا إلى Ledger Wallet Desktop، مبنيًا على مجمع Ironwood، مما يلغي الحاجة إلى محفظة مرافقة منفصلة. لا يُدعم ZEC المحمي بعد في تطبيق Ledger المحمول على iOS وAndroid، مع أن دعم الأجهزة المحمولة مخطط لإصدار مستقبلي.
خارج برمجيات Ledger الخاصة، يعتمد الاستخدام المحمي على محفظة مرافقة متوافقة ومنصاتها المدعومة. ومع استمرار Ledger في توسيع دعم Ironwood، يعتمد التوافق على طراز الجهاز والبرنامج الثابت وإصدار التطبيق ونظام التشغيل، ولذلك فإن دعم Zcash العام لا يضمن بالضرورة التوافق.
https://www.youtube.com/watch?v=VhkhfG0LCFs
التوقيع البارد لـ YWallet؛ نهج سابق
Ywallet محفظة مرافقة منفصلة عن كل من Ledger وZondax، اتبعت مسارها الخاص نحو التوقيع البارد للمعاملات المحمية.
يكتسب Ywallet أهمية تاريخية لأنه استكشف التوقيع البارد لـ Zcash، أي أن جهاز التوقيع يمكن إبقاؤه منفصلًا عن المحفظة المتصلة بالإنترنت.
لتحقيق هذه البنية على أجهزة Ledger، بنى Ywallet تطبيق Ledger خاصًا به، وهو تطبيق مملوك ومتميز عن تطبيق Zondax المغطى في القسم السابق. وهذا يعني أن Ywallet لم يكن يعتمد على تنفيذ Zondax القائم لـ Sapling؛ بل كان لديه برنامج ثابت خاص به يدير جانب التوقيع من العلاقة.
سبب أهمية التكامل
لا يكفي امتلاك التشفير وشفرة التوقيع. فتكامل محفظة الأجهزة ليس مجرد مشكلة تشفيرية، بل هو أيضًا مشكلة توزيع ومنصة لا يمكن تجنبها. ويتضمن، كحد أدنى:
- اعتماد/توزيع التطبيق — ما إذا كان متجر التطبيقات الرسمي لمصنع الأجهزة سيقبل التطبيق ويوزعه
- أمان البرنامج الثابت/التطبيق — ما إذا كان التطبيق يفي بمتطلبات أمان المصنع للتعامل مع مادة المفتاح
- بروتوكولات الاتصال — كيفية تبادل المحفظة المرافقة والجهاز لبيانات المعاملة فعليًا
- التوافق مع المحفظة — ما إذا كانت تنسيقات بيانات تطبيق التوقيع وتدفقه تطابق ما تتوقعه المحفظة المرافقة
- المجمعات المحمية المدعومة — أي من Sapling أو Orchard (والآن Ironwood) يمكن للتطبيق التوقيع لها فعليًا
لبى تطبيق Ywallet Ledger المملوك المتطلبات التشفيرية والبنيوية؛ إذ كان بإمكانه توقيع معاملات Zcash المحمية، لكنه لم يُقبل في متجر التطبيقات الرسمي لـ Ledger.
الابتعاد عن تطبيق Ledger المملوك
لأن التطبيق لم يُقبل رسميًا، كان سيتعين على Ywallet أن يطلب من المستخدمين تثبيت برنامج ثابت غير موقّع لاستخدامه، وهذا تنازل أمني حقيقي للمستخدمين، وقد اختار Ywallet عدم طلب ذلك منهم. ولذلك تخلى Ywallet في النهاية عن ذلك التكامل بالذات بدلًا من سلوك هذا المسار.
وبدلًا من إحياء تطبيق مملوك، انتقل التطوير اللاحق (عبر Zkool، خليفة Ywallet) نحو تطبيق Zondax الذي بنته Ledger رسميًا بدلًا منه، مستبدلًا تنفيذًا مخصصًا مرفوضًا بتنفيذ موحد مقبول بالفعل في منظومة توزيع Ledger. وهذا التحول هو ما أتاح في النهاية تكامل Ledger يعمل من جديد.
إرث Ywallet
حتى بعد أن تراجع Ywallet نفسه عن التطوير النشط، ظل منشئه Hanh، الذي هو أيضًا عضو في ZCG، صوتًا ذا صلة في المنظومة، وبخاصة عندما أبرز انتقال Ironwood مشكلات مُبلغًا عنها تتعلق بأموال بدا أنها اختفت.
ZODL: واجه مستخدم حقيقي أموالًا مفقودة بعد انتقال Orchard → Ironwood
أبلغ مستخدم، Jmo0615، أن الأموال التي كانت ظاهرة سابقًا في محفظة ZODL الخاصة به لم تعد تظهر بعد الانتقال من Orchard إلى Ironwood. وذكر أنه استعاد البذرة الأصلية، وأعاد ضبط المحفظة واستردها، وسمح للإصدار 3.14.1 (1) من ZODL بالمزامنة بالكامل. كما أكد أنه لم تشارك أي محفظة أجهزة Keystone.
لم يثبت أن الأموال فُقدت بالفعل. بل يُشتبه في أنها مشكلة تتعلق باكتشاف المحفظة أو بالانتقال، حيث لم تعد الأموال الظاهرة سابقًا معروضة بعد الانتقال إلى Ironwood. ولا ينبغي وصف الأموال التي لا يتم كشفها أو عرضها تلقائيًا بأنها أموال فُقدت بصورة دائمة، وهذا التمييز مهم عند فهم مشكلات الانتقال.
https://forum.zcashcommunity.com/t/funds-not-showing-since-ironwood/57792
Zkool: يمكن أن تفسر «المذكرات المقفلة» الأموال التي تبدو غير متاحة
جانب مهم آخر للمحافظ المحمية هو كيفية تأثير حالة المحفظة في الأموال التي يستطيع المستخدم إنفاقها فعليًا. أوضح Hanh أن المستخدم قد يقفل مذكرة عن طريق الخطأ من خلال التحكم بالعملات، وهي ميزة تسمح للمستخدمين باختيار المذكرات المستخدمة للإنفاق يدويًا. في هذه الحالة، قد تبقى المذكرة موجودة في المحفظة، لكنها تُعلّم بوصفها غير متاحة للإنفاق.
يسلط هذا الضوء على تمييز مهم عند التحقيق في مشكلات المحافظ. لا يكون مقدار ZEC الموجود في المحفظة دائمًا مساويًا للمقدار المتاح حاليًا للإنفاق. يمكن لعوامل مثل اختيار المذكرات والمزامنة وحالة الانتقال واسترداد المحفظة وإعدادات التحكم بالعملات أن تؤثر في الرصيد المعروض أو القابل للإنفاق. ولذلك ينبغي التمييز بعناية في تقارير «الأموال المفقودة» بين الأموال التي لا تُكتشف أو لا تُعرض، والأموال التي تُكتشف لكن لا تتاح للإنفاق، والأموال التي فُقدت بالفعل.
https://youtube.com/shorts/eAOMRVYJFTA?si=xytBs-wZKn8hmu8D
2. Keystone
ما هو Keystone؟
Keystone محفظة أجهزة معزولة هوائيًا. لا يحتوي جهاز التوقيع الخاص بها على اتصال سلكي أو لاسلكي مباشر بتطبيق المرافقة أثناء عملية التوقيع نفسها، بل يتواصل عبر رموز QR. وهي مقترنة هنا بـ Zashi (الذي أُعيدت تسميته الآن Zodl)، وهي المحفظة المرافقة الأصلية لـ Zcash، وهذا الاقتران يجعل مبدأ عزل المفاتيح صريحًا وسهل التتبع على نحو غير معتاد.
تدفق Keystone/Zashi
يجعل تكامل Keystone مع Zcash وZashi هذا الفصل صريحًا بصفة خاصة. عندما توصل Keystone بـ Zashi، يُنقل Full Viewing Key الموحد من Keystone إلى Zashi.
إذًا يكون التدفق:
ماذا يستطيع Zashi فعله باستخدام UFVK؟
يستطيع Zashi استخدامه من أجل:
- تحديد المعاملات المحمية الواردة
- تحديد الأرصدة
- الحصول على معلومات عن النشاط المحمي
لكنه لا يستطيع إنفاق الأموال لمجرد امتلاكه UFVK.
إن UFVK هو «قدرة عرض» تسمح بمعرفة الأرصدة والمعاملات، لكنها لا تسمح بالإنفاق.
ما الذي يبقى داخل Keystone؟
تبقى صلاحية البذرة/الإنفاق على Keystone. لا يتلقى Zashi البذرة أو مفتاح الإنفاق أو المفتاح الخاص لتفويض الإنفاق. بل يتلقى UFVK ومعلومات العنوان والمعلومات اللازمة للتشغيل بوضع العرض فقط.
تكمل هاتان النصفان الصورة معًا. ما يغادر الجهاز، مثل UFVK والعناوين ومعلومات العرض فقط، يكفي لـ Zashi لمراقبة الحساب، لكن لا شيء يغادر الجهاز يكفي لنقل الأموال منه.
لهذا يستطيع تكامل Zashi وKeystone توفير تخزين بارد محمي. يستطيع تطبيق المحفظة مراقبة الحساب دون امتلاك الصلاحية اللازمة للإنفاق منه. أُطلق التكامل تحديدًا لتمكين التخزين البارد لـ ZEC المحمي.
عندما ترغب في الإنفاق:
3. Hito
يتبع Hito نموذج عزل مفاتيح مشابهًا جدًا لـ Keystone، لكن تنفيذه أحدث. بدلًا من الاقتران بمحفظة مرافقة قائمة مثل Zashi، يأتي Hito مع محفظته الخاصة Android، وتوثق مراحل تطوير Hito عملية الإعداد بين جهاز الأجهزة وتطبيق Android.
الإعداد: ما يتلقاه تطبيق Hito
تستخدم محفظة Android:
- Full Viewing Key الموحد (UFVK)
- Unified Address
- بصمة بذرة ZIP-32
- معلومات الشبكة
عند إعداد حساب الأجهزة.
لاحظ أن تطبيق Android لا يتلقى مطلقًا بذرة محفظة الأجهزة أو مفاتيح الإنفاق الخاصة.
ماذا يحصل عليه تطبيق Hito؟
تتضمن معلومات الإعداد الموثقة:
- UFVK
- Unified Address
- بصمة بذرة ZIP-32
- الشبكة
يمنح UFVK محفظة Android المعلومات التي تحتاجها لتشغيل الحساب بوصفه محفظة قادرة على العرض دون تلقي البذرة. بصمة البذرة هي معرف بطول ثابت مشتق من البذرة، يُستخدم للتعرف على الحساب، وليست البذرة نفسها ولا تمنح أي قدرة على الإنفاق، ولهذا لا يتناقض وجودها مع عبارة «لا تتلقى البذرة مطلقًا» أعلاه.
ما الذي يبقى على Hito؟
تبقى البذرة الفعلية ومفاتيح الإنفاق الخاصة وصلاحية التوقيع على جهاز الأجهزة. ثم ينفذ Hito التوقيع دون اتصال.
تنص المرحلة الحالية لـ Hito على أن سير عمل الإنشاء والتصدير والتوقيع دون اتصال والاستيراد بأكمله يعمل، ويتميز بنقل BLE وتصدير QR لـ BBQr لموقّع PCZT.
يجدر تسمية سير العمل هذا صراحةً، لأنه المثال الملموس للدورة الكاملة التي غطاها هذا التقرير سابقًا: تنشئ محفظة Android PCZT غير الموقّع، وتصدره إلى Hito، ويوقع Hito دون اتصال باستخدام مادة مفتاحه المعزولة، ثم يُستورد PCZT الموقّع مرة أخرى إلى محفظة Android.
لا تعبر البذرة أو مفتاح الإنفاق ذلك الحد في أي اتجاه في أي وقت.
Orchard إلى Ironwood: تطور دعم محافظ الأجهزة
Orchard مجمع محمي في بروتوكول Zcash يتيح للمستخدمين تخزين ZEC وإجراء المعاملات به مع خصوصية محسنة. قُدم في ترقية الشبكة 5 (NU5)، ويستخدم Orchard نظام الإثبات Halo 2 وبنية تشفيرية معاد تصميمها لدعم المعاملات المحمية دون كشف معلومات المعاملة الحساسة، مثل المرسل أو المستلم أو المبلغ.
Ironwood مجمع محمي قُدم في ترقية شبكة Zcash NU6.3 بوصفه خليفة لمجمع Orchard. يستخدم بروتوكول Orchard التشفيري مع إدخال تغييرات صُممت لتحسين أمان الأموال المحمية على المدى الطويل، بما فيها إمكانية الاسترداد الكمي وضمانات أقوى حول سلامة العرض.
في البداية، من الضروري توضيح أن Ironwood لم يستبدل بروتوكول Orchard بنظام تشفيري جديد كليًا. قُدم Ironwood بوصفه مجمعًا محميًا جديدًا مبنيًا من بروتوكول Orchard القائم. وهذا يعني أن لهما بنية Action نفسها، ونظام الإثبات Halo 2 نفسه، وبنى المذكرات والمفاتيح نفسها.
لدى Ironwood شجرة التزامات للمذكرات ومجموعة مُبطِلات ومرساة ومجمع قيم خاص به، لذا فهو على مستوى الإجماع مجمع منفصل فعلًا. لكنه تشفيريًا امتداد لـ Orchard لا إعادة بناء له.
صُمم بهذه الطريقة من أجل:
- سلامة العرض. في 29 مايو 2026، كشف الباحث الأمني Taylor Hornby سرًا عن خلل خطير في متانة نظام إثبات المعرفة الصفرية الخاص بـ Orchard، كان يمكن أن يسمح بإنشاء ZEC مزيف دون ترك أثر على السلسلة. ولأن بيانات معاملات Orchard خاصة، لا يستطيع أحد التحقق بصورة مستقلة من عدم إنشاء ZEC مزيف قبل الإصلاح. إن إغلاق المجمع القديم والبدء بآخر جديد من الصفر يحل المشكلة بطريقة لا يمكن لترقيع Orchard في مكانه حلها.
- ضمان قابلية الاسترداد الكمي. صُمم Ironwood بحيث تستطيع أمواله المشاركة في آلية استرداد مستقبلية إذا ما كُسرت افتراضات اللوغاريتم المتقطع الأساسية.
- تقليل تغييرات التنفيذ. بدلًا من تصميم بروتوكول محمي جديد بالكامل، أعيد استخدام البنية المثبتة لـ Orchard. وهذا يعني وجوب كتابة قدر أقل بكثير من شفرة المعاملات والإثبات والمحفظة ومحفظة الأجهزة من الصفر.
الخط الزمني العام
- 29 مايو: يُكشف عن ثغرة Orchard.
- يونيو: تُقيَّد معاملات Orchard مؤقتًا بينما يُشحن إصلاح أولي عبر NU6.2. في 12 يونيو، يستهدف مطور أساسي 21 يوليو للترقية الكاملة؛ ثم تأجلت أسبوعًا. أُثير قلق مجتمعي من أن مالكي Keystone سيكونون آخر من ينتقل، ورد مطور أساسي بأن Keystone سيدعم Ironwood منذ اليوم الأول، مع استهداف البرنامج الثابت ليوم 3 يوليو، رهنًا بثوابت توقيع نهائية وتغييرات API لـ Orchard من نواة Zcash.
- أوائل يوليو: يصل NU6.3 إلى شبكة الاختبار؛ ويُشحن Zebra 6.0.0 في 10 يوليو.
- 27–28 يوليو: يندمج عمل توقيع Ledger Ironwood PCZT v2 في فرع تكامل. يُفعّل Ironwood (NU6.3) في 28 يوليو عند الكتلة 3,428,143، فيغلق مجمع Orchard الأصلي خلف بوابة تحد مقدار ZEC الذي يمكن أن يغادر Orchard بالمقدار المودع فيه بصورة مشروعة، ويقدم تنسيق معاملة جديدًا.
يصبح Zebra العقدة المطلوبة، لأن zcashd لا يدعم قواعد الإجماع الجديدة. لا تتغير العناوين لأن Ironwood يعيد استخدام بنية مستقبل Orchard، ولذلك توجه المحافظ العناوين القائمة إلى المجمع الجديد تلقائيًا. لكن ما تحتاجه المحافظ هو وظيفة الانتقال، إذ يجب في النهاية أن ينقل مالكو أموال Orchard تلك الأموال إلى Ironwood، كما أن المخرجات الجديدة التي تتلقى Orchard محجوبة الآن بالإجماع بالكامل.
ما الذي تغير تقنيًا
انتقلت تنسيقات المعاملات من الإصدار 5 إلى الإصدار 6، ولذلك يمكن لمعاملة واحدة أن تحمل مكوّن Ironwood إلى جانب مكونات Sapling/Orchard/الشفافة القائمة. امتد PCZT بالتزامن:
- انتقل الترميز من PCZT v1 إلى v2.
- أصبحت حزمة Ironwood منفصلة بجانب حزم Sapling وOrchard.
- تُدعم معاملات v6 وsighash جديد لـ v6.
- اكتسبت النصوص الواضحة للمذكرات إصدارًا جديدًا (V3).
يهم تغيير sighash محافظ الأجهزة بصفة خاصة. في v6، تستبعد مراسي Orchard وIronwood من تجزئة التوقيع ولا تدخل إلا في ملخص بيانات التفويض. هذا تغيير حقيقي في البرنامج الثابت، وليس مجرد رفع إصدار. يجب على الجهاز تنفيذ sighash الجديد بشكل صحيح وإعادة حسابه بنفسه بدلًا من الوثوق بما يزعم تطبيق المرافقة أنه يوافق عليه.
لم يتغير عقد العزل نفسه: ما زال الجهاز يعيد توقيع تفويض الإنفاق فقط، لا alpha مطلقًا، ولا ينتج توقيع الربط، كما يظل المضيف مسؤولًا عن الإثبات وكل شيء آخر.
تغيرت قاعدة واحدة للموقّع مع v6: توقع إنفاقات الحشو الوهمية بواسطة مُنهي IO بدلًا من الجهاز، لأن الجهاز لا يملك طريقة للتحقق منها مقابل بيانات مذكرة حقيقية. يتجاوز دور الموقّع في الجهاز هذه الإنفاقات بدلًا من مطالبته بتوقيع شيء لا يستطيع التحقق منه. كما تجمع الرسوم المعروضة الآن أرصدة القيمة في Orchard وIronwood معًا، لأن معاملة v6 تستطيع الإنفاق من أي من المجمعين في المعاملة نفسها.
إن ضبط محاسبة المجمعات بصورة صحيحة مهم عمليًا، لا نظريًا فقط. ويوضح خطأ حديث في محفظة Brave الخاصة بـ Zcash ذلك: إذ افترض حساب الرسوم أن جميع المدخلات المحمية تنتمي إلى مجمع Orchard القديم، ما أدى إلى Actions مكررة وتقديرات رسوم خاطئة كلما تضمنت معاملة فعلًا Ironwood. وهذه بالضبط فئة الأخطاء التي يوجد مبدأ «أعد حسابها بنفسك، لا تثق بالمضيف» الكامن وراء توقيع محفظة الأجهزة لاكتشافها. أخطأت محفظة مرافقة في محاسبة المجمع، ولن يكتشف ذلك قبل التوقيع إلا جهاز يتحقق بشكل مستقل من حساباته الخاصة.
موقف كل موقّع
غيّر Ledger المشهد كله للتو. في 23 سبتمبر 2026، شحن Ledger دعم Zcash المحمي الأصلي مباشرة داخل Ledger Wallet Desktop، ولم تعد هناك حاجة إلى تطبيق مرافق منفصل. يبقى مفتاح إنفاقك على الجهاز، وينفذ الحاسوب رياضيات المعاملة، وتوافق على كل شيء على الشاشة قبل توقيعه. وهو يدعم Ironwood فقط، وليس مجمعي Orchard أو Sapling القديمين. أما العيب فهو أن تطبيق «Zcash Shielded» القديم الذي بناه Zondax، والذي احتاج إلى محفظة مرافقة مثل Zkool ليعمل، يجري إيقافه. يسحب Ledger ذلك التطبيق الأقدم من الإتاحة في 5 نوفمبر، لذا يحتاج كل من لا يزال يستخدمه إلى نقل أمواله قبل ذلك.
وضع Keystone جيد. أضاف البرنامج الثابت 3.0.2 دعم Ironwood كاملًا في يوليو، وما زال هذا هو المتطلب الحالي والمستقر. لكن يلزم ذلك الإصدار أو إصدار أحدث لتوقيع أي شيء.
تجاوز Hito مرحلة شبكة الاختبار الأولية. نجح في توقيع وإرسال أول معاملة حقيقية من Orchard إلى Ironwood على أجهزة مادية (في البداية على شبكة الاختبار). أكدت التحديثات اللاحقة تدفقات الشبكة الرئيسية (Ironwood→Ironwood، وIronwood→شفاف، وغيرها) على أجهزة إنتاجية. ولا يزال البرنامج الثابت المستقر والإصدار الأوسع قيد التقدم.
إن Zondax وZkool حاليًا في حالة تغير. تطبيق Zondax هو الذي يجري إيقافه على Ledger. ولم يشر Zkool، الذي اعتمد على ذلك التطبيق للتواصل مع أجهزة Ledger، إلى ما سيحدث لهذا الدور حال اختفاء التطبيق القديم. ومن غير الواضح ما إذا كان سيظل ذا صلة لمستخدمي Ledger مستقبلًا، أو ما إذا كان مستقبله سيكون أساسًا مع أجهزة أخرى.
يمثل الانتقال نفسه أكبر أثر متسلسل. لأن المقدار العابر بين المجمعات عام، توزع المحافظ التحويلات على فئات معيارية بمرور الوقت بدلًا من نقل رصيد في كتلة ظاهرة واحدة، ما يعني الكثير من المعاملات للتوقيع لكل عملية انتقال، ولهذا تحديدًا كان التوقيع الدفعي لـ PCZT مهمًا جدًا لمحافظ الأجهزة.
واجه عمل البرنامج الثابت لـ Ledger أيضًا حدود الأجهزة: فقد يصل إنفاق مذكرة حقيقية إلى عشرات آلاف استدعاءات النظام التشفيرية في أمر واحد، ما يؤدي إلى تشغيل مؤقت مراقبة الجهاز. نقل الإصلاح حسابات الحقول إلى البرمجيات وتطلب حالة عمل مؤقتة مشتركة لتناسب قيود مكدس Nano X.
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
التطور في صورة واحدة
