في شبكة اختبار TRON Nile يتم عرض نموذج مفتوح المصدر لمحفظة ذكية تعمل بعقود ذكية، ويمكن التحكم بها باستخدام مفتاح تشفير تم إنشاؤه مباشرة داخل Apple Secure Enclave على iPhone.
يؤكد المستخدم العملية عبر Face ID، ويقوم iPhone بتوقيعها بمفتاح محمي فعليًا P-256، ويتحقق عقد TRON الذكي تلقائيًا من التوقيع على البلوكشين.
الميزة الأساسية: لا يتم تصدير المفتاح الخاص من iPhone ولا يتم تمريره إلى أي خادم أو إلى relayer أو إلى البلوكشين.
هذا يوضح كيف يمكن لمحافظ التشفير في المستقبل أن تتخلى عن نموذج التخزين اليدوي لعبارة seed، وهو نموذج مألوف للمستخدمين.
ما علاقة ذلك بـ Apple Secure Enclave؟
Secure Enclave عبارة عن بيئة أجهزة محمية منفصلة داخل أجهزة Apple، مخصصة أيضًا للعمل مع مفاتيح التشفير.
في النموذج الأولي المعروض، يقوم iPhone بإنشاء مفتاح P-256 (secp256r1) مباشرة داخل Secure Enclave. يبقى الجزء الخاص من المفتاح داخل الجهاز. يحصل التطبيق على القدرة لاستخدام المفتاح للتوقيع فقط بعد تأكيد وجود المستخدم عبر Face ID أو رمز الجهاز. وفي الوقت نفسه، يمكن تمرير المفتاح العام بأمان إلى العقد الذكي.
من المهم فهم أن Face ID بحد ذاته لا يُعد توقيعًا تشفيرياً للمعاملة. يتيح التعرّف الحيوي فقط لـ Secure Enclave استخدام المفتاح الخاص. أما التوقيع الذي تم الحصول عليه بالفعل فتتحقق منه البلوكشين.
لماذا كانت هذه المشكلة قائمة من قبل؟
تستخدم أغلب محافظ العملات المشفرة الكلاسيكية المنحنى البيضاوي secp256k1. يعمل Apple Secure Enclave مع P-256، المعروفة أيضًا باسم secp256r1. لذلك، فإن مخطط التحقق القياسي للتوقيع، وهو المعتاد لدى كثير من محافظ البلوكشين، لا ينطبق هنا مباشرة.
في TRON، تحل P256VERIFY هذه المشكلة—وهي آلية خاصة للتحقق من توقيعات P-256 موصوفة في TIP-7951. يقوم العقد الذكي بإرسال هاش العملية إليه، ومعلمات التوقيع وإحداثيات المفتاح العام. وإذا كان التوقيع صحيحًا، يمكن تنفيذ العملية.
هذه الإمكانية تحديدًا تجعل مفاتيح الأجهزة في الهواتف الذكية الحديثة قابلة للتوافق بدرجة محتملة مع حسابات TRON الذكية (smart-accounts).
كيف تتم المعاملة؟
يبدو المخطط تقريبًا كالتالي: iPhone → Face ID → Secure Enclave → توقيع P-256 → relayer → محفظة TRON الذكية → P256VERIFY → تنفيذ العملية.
في الوقت نفسه، لا يقوم المستخدم بالتوقيع على رسالة مجردة «السماح بإجراء العملية». يتم تضمين معلمات محددة في التوقيع: عنوان المحفظة، ومعرّف الشبكة، وعنوان المستلم، والمبلغ، وهاش بيانات المعاملة، وnonce، ومدة صلاحية التفويض. وهذا يحمي التوقيع من إعادة استخدامه أو نقله إلى عملية أخرى.
يدفع الـ relayer مقابل المعاملة، لكنه لا يتحكم في المحفظة
جزء آخر مثير للاهتمام في البنية هو استخدام relayer. فهو يستلم العملية التي تم توقيعها بالفعل من قبل المستخدم ويرسل معاملة خارجية إلى TRON، مع دفع تكلفتها لنقلها إلى الشبكة.
لكن وجود مفتاح relayer لا يمنحه الحق في التصرف بالأصول الخاصة بالـ smart-wallet بشكل مستقل. تمنح الموافقة النهائية توقيع P-256 الصادر من المستخدم، والذي يتحقق منه العقد مباشرة داخل البلوكشين.
وبذلك يمكن فصل وظيفتين: المستخدم يُفوض إجراءً ما، بينما تقوم البنية التحتية الطرفية بتوصيل المعاملة ودفع تكلفتها.
تم اختبار التقنية بالفعل على Nile
هذه ليست مجرد بنية نظرية. فقد نشر المطور الكود المصدر ونتائج عدة اختبارات على iPhone حقيقي داخل شبكة TRON Nile.
في أحد الاختبارات المؤكدة، قام smart-wallet بإرسال 10 SUN بنجاح: قام iPhone بتوقيع العملية، وأرسل الـ relayer العملية إلى الشبكة، ثم تحقق العقد من توقيع P-256 عبر P256VERIFY وأجرى التحويل.
أي أن السلسلة الكاملة من مفتاح جهاز iPhone إلى تنفيذ العملية في TRON قد تم بالفعل عرضها على شبكة اختبار.
هل يعني ذلك أنه لم تعد هناك حاجة إلى عبارات seed؟
لا، ليس بعد. المشروع المعروض هو Proof of Concept وليس محفظة جاهزة للاستخدام من قبل المستخدمين.
في التنفيذ الحالي يوجد مفتاح ثابت واحد فقط؛ لا توجد استعادة وصول ولا تغيير للمفتاح، وحدود للإنفاق، وحماية كاملة للـ relayer، إضافة إلى عدد من آليات الأمان الأخرى.
إذا فقدت iPhone ضمن التنفيذ الحالي التجريبي، يمكن أن تفقد أيضًا القدرة على إدارة المحفظة. لذلك لا يمكن استخدام هذا النموذج الأولي لتخزين الأصول الحقيقية.
بالنسبة لمنتج صناعي، ستحتاج إلى نظام استعادة، وتدوير للمفاتيح، وسياسات أمان إضافية، وبنية تحتية محمية، وتدقيق مستقل.
لماذا يعتبر التجريب مهمًا لـ TRON؟
القيمة الأساسية للتطوير ليست فقط القدرة على قول «المحفظة تعمل مع Face ID». والأكثر إثارة للاهتمام هو أن البلوكشين قادر على التحقق من توقيع المفتاح الذي يتم توليده ويبقى داخل وحدة جهازية محمية داخل هاتف ذكي عادي.
قد لا يحتاج المستخدم بعد الآن إلى رؤية المفتاح الخاص أو نسخه أو الاحتفاظ به بنفسه. وهذا يغيّر تجربة المستخدم بشكل كبير.
اليوم، تتمثل إحدى أهم مشاكل self-custody في أن المسؤولية عن عبارة seed تقع بالكامل على عاتق المالك. إذا فقدها أحدهم—يفقد الوصول. إذا حصل شخص آخر على نسخة—فإن الأصول تكون تحت التهديد.
تسمح المفاتيح المحمية عبر الأجهزة مع حسابات smart-accounts ببناء نموذج آخر.
الخلاصة
برأيي، يُعد P256VERIFY واحدًا من أكثر تحديثات TRON التقنية إثارة للاهتمام عمليًا خلال الفترة الأخيرة. ليس لأنك الآن تستطيع تأكيد معاملة التشفير بوجهك. فـ Face ID هنا هو مجرد آلية مريحة لمنح صلاحية الوصول إلى المفتاح.
الميزة الرئيسية هي ربط أمان الأجهزة في الهواتف الذكية الحديثة مباشرةً مع محفظة العقود الذكية.
إذا أضفنا إلى هذا التصميم استعادة وصول آمنة، وتبديل الأجهزة، وحدودًا وغيرها من آليات account abstraction، فقد يصبح محفظة التشفير لمستخدم عادي مشابهة بالفعل لتطبيق بنكي: افتح iPhone → أكد Face ID → أرسل الأصول.
وفي الوقت نفسه يبقى المفتاح الخاص محميًا على الجهاز، بينما يظل المستخدم هو من يتحكم في صلاحية إجراء العملية.
حالياً، لا يزال الأمر مجرد تجربة على Nile. لكن مثل هذه التطويرات هي التي يمكن أن تزيل تدريجيًا إحدى أكبر العوائق أمام self-custody الجماعي: الحاجة إلى أن يدير الشخص العادي بنفسه عبارات seed والمفاتيح الخاصة.