عندما كنت أطلع مؤخرًا على بيانات شبكة Acurast، لفت انتباهي من النظرة الأولى وجود 335 ألف هاتف وتغطية أكثر من 175 دولة.

لكن حين أفكر في الأمر بهدوء، أجد أن ما يهمني حقًا ليس «كم عددها»، بل سؤال آخر: هل هذه الهواتف حقيقية فعلًا؟

هذا ليس بحثًا عن العيوب لمجرد الانتقاد. فشبكات DePIN التي تقدم حوافز مقابل القدرة الحاسوبية لا يمكنها تجنب المحاكيات والأجهزة الوهمية المُنشأة بكميات كبيرة ونبضات الاتصال المزيّفة. فإذا كان بإمكان نص برمجي أن يتظاهر بأنه عشرات الهواتف ويواصل استلام المكافآت، فقد تتحول أرقام العُقد، مهما بدت رائعة، في النهاية إلى أرقام لا تمثل قدرة حاسوبية فعلية.

كان تعامل Acurast مع هذه المشكلة أكثر صرامة مما تخيلت في البداية.

عندما ينضم الهاتف إلى الشبكة، يجب أن يجتاز Google Key Attestation على Android أو Apple App Attest على iPhone. وببساطة، تصدر وحدة أمان محمية بالأجهزة داخل الهاتف إثباتًا يؤكد أن الجهاز هاتف حقيقي، وأن نظامه لم يتعرض للتلاعب، وأنه غير مروّت أو مكسور الحماية. ولا يمكن إرسال مهام المطورين إلى الجهاز لتنفيذها إلا بعد اجتيازه هذه الخطوة.

لكن الأمر الحاسم حقًا ليس «إجراء فحص واحد عند التسجيل».

قد تتشارك أجهزة الإثبات التي تستخدمها بعض الهواتف القديمة بين مجموعة من الأجهزة، أو حتى بين طرازات الهواتف نفسها. وإذا تسرّب مفتاح الشركة المصنّعة، فقد يتمكن المهاجمون من جعل خادم أو محاكي ينتحل صفة هاتف حقيقي، بل ومن استنساخ أعداد كبيرة من الأجهزة ذات الهوية نفسها. قد تبدو صيغة الإثبات لهذه الأجهزة صحيحة ظاهريًا، لكن يصعب اكتشاف المشكلة ما لم تواصل الشبكة التحقق من حالة إلغاء المفاتيح.

لذلك تواصل Acurast التحقق من إثباتات الأجهزة. وتُزال الأجهزة المرتبطة بالمفاتيح التي ألغتها Google أو Apple من مجموعة المعالجات (Processor pool)، فلا يمكنها تلقي مهام الحوسبة أو مواصلة الحصول على المكافآت المرتبطة بها.

لكن هذه الآلية لا تخلو من التبعات.

إذا أُلغي مفتاح مشترك بين مجموعة من الهواتف القديمة، فقد تتأثر الأجهزة المرتبطة به كلها، حتى لو كان بعضها يعود إلى مستخدمين ملتزمين. يمكن للمستخدمين محاولة إعادة ضبط المصنع، وترقية النظام الرسمي، وقفل Bootloader قبل إعادة الاتصال، لكن لا ضمان لنجاح ذلك. ولا يمكن لـ Acurast ببساطة إدراج الأجهزة «التي تبدو سليمة» في قائمة سماح، لأن قبول إثبات أُلغي سيتيح للأجهزة المزيفة الدخول أيضًا.

أرى أن من الجدير توضيح هذه الجوانب غير المثالية. فالقيمة الحقيقية لآليات الأمان لا تكمن في الادعاء بأنها لا تخطئ مطلقًا، بل في استعدادها، عند اكتشاف المخاطر، للتضحية بجزء من عدد العُقد الظاهر ومواصلة الحفاظ على موثوقية القدرة الحاسوبية في الشبكة.

وترتبط هذه المسألة أيضًا بنظام الحوافز الخاص بـ $ACU. ينبغي أن يكون شرط حصول مزودي الحوسبة (Compute Provider) على المكافآت هو توفير أجهزة حقيقية وقدرة حوسبة فعلية، لا تشغيل نص برمجي لا يفعل سوى الإبلاغ عن حالة الاتصال بالإنترنت. وكلما قلّ عدد العُقد المزيفة، زادت موثوقية القدرة الحاسوبية التي يشتريها المطورون، وزادت احتمالية وصول مكافآت الشبكة إلى من يوفّرون الموارد فعلًا.

في السابق، عندما كنت أتابع DePIN، كنت أميل تلقائيًا إلى مقارنة المشاريع بحسب عدد عُقدها. أما الآن، فأرى أن عشرات الآلاف من الأجهزة التي يمكن التحقق منها باستمرار قد تكون أهم من ملايين الحسابات التي يتعذر إثبات حقيقتها.

ما الذي توليه أهمية أكبر: عدد العُقد أم موثوقيتها؟

هذه المقالة لا تتعدى كونها ملاحظات شخصية ومشاركة لوجهة نظر حول آليات المشروع، ولا تشكّل نصيحة استثمارية.