العودة
أنوبيس تطلق إثبات العمل بـ WebAssembly بعد عام من التطوير
SiTech AI Team2 წთ. საკითხავი

أنوبيس تطلق إثبات العمل بـ WebAssembly بعد عام من التطوير

بعد عام من التطوير ومئات الالتزامات البرمجية ومطاردة خطأ في LLVM، ينتقل أنوبيس إلى إثبات عمل مرتبط بالذاكرة مكتوب بـ WebAssembly، ما يجعل مزارع الحلّالين المبنية على CUDA مكلفة للغاية.

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

سيظهر للمرة الأولى معطّلًا افتراضيًا في الإصدار Anubis v1.28.0، بينما يُخطط لتفعيله افتراضيًا في الإصدار v1.29.0 اعتمادًا على ملاحظات المشغّلين.

أحجية تستهلك الذاكرة لا المعالج فقط

يستخدم التحقق الجديد خوارزمية argon2id، وهي دالة مرتبطة بالذاكرة (memory-hard)، بدلًا من التجزئة القديمة المرتبطة بالمعالج. والهدف العملي هو الكلفة: فحل هذه الأحاجي على نطاق واسع يحتاج إلى عرض نطاق للذاكرة إلى جانب القدرة الحسابية، ما يرفع كلفة مسار «نقل الحلّال إلى CUDA» الذي يجرّبه كاشطو البيانات. يربط المشرف التحدي بقاعدة محددة، مثل عتبة «اشتباه متوسط» بدرجة صعوبة 6.

يتيح WebAssembly أيضًا للعميل والخادم تشغيل الملف التنفيذي نفسه بدل تطبيقين منفصلين للخوارزمية؛ فقد كان تحدي «fast» موجودًا مرتين، مرة بلغة JavaScript وأخرى بلغة Go. ويشبّه المؤلف ذلك بشريحة القفل في جهاز Nintendo Entertainment System حيث ينفّذ الطرفان المنطق ذاته. وقد كُتب كود WebAssembly بلغة Rust (no-std, wasm32-unknown-unknown) لأنه ينتج ملفات صغيرة وسريعة.

تفاصيل استهلكت عامًا: خطأ في LLVM وChrome 75

معظم التأخير جاء من التفاصيل. لا يزال أنوبيس يدعم Chrome 75 لأن كثيرًا من أجهزة التلفاز الذكية والهواتف الرخيصة العاملة بأندرويد لا تملك مسار ترقية. تبيّن أن مكتبة Rust المعيارية المُجمَّعة مسبقًا تستخدم reference types، وهي ما ترفضه إصدارات Chrome القديمة بخطأ «expected table index 0, found 128». وكان الحل تجريد ميزات WebAssembly بواسطة wasm-opt: قاعدة MVP مع ما يفهمه Chrome 75 فقط.

وعند بناء أداة حتمية للتحويل من WebAssembly إلى JavaScript ظهر خطأ في LLVM أيضًا: كان المترجم يمرّ على كتل معالجة الاستثناءات بترتيب مؤشرات الذاكرة، فكان كل بناء يختلف بنحو 29 بايت. وقد أكّد تعطيل عشوائية فضاء العناوين التشخيص، ثم أُصلح الخطأ في المصدر الأصلي. ولاختبار المتصفحات القديمة بنى المؤلف أداة «chromesweep» تُشغّل إصدارات كثيرة من Chrome، ونُشرت كمكتبة TecharoHQ/gubal.

ما لم يكتمل بعد

ثمة مسار احتياطي يحوّل WebAssembly عائدة إلى JavaScript للمتصفحات التي تعطّل WASM بسياساتها، مثل وضع Lockdown في iOS أو Vanadium في GrapheneOS. هذا المسار بطيء ولم يُربط فيه شريط التقدم بعد. ولأن حلّال WebAssembly سريع جدًا، قد تحتاج درجات الصعوبة إلى إعادة ضبط، ويجري العمل على مصنّف يستخدم سمعة عناوين IP وبصمة TLS لمنح الهواتف قدرًا أكبر من التسامح.

SSiTech

SiTech — تطوير ويب مدعوم بالذكاء الاصطناعي

نبني مواقع سريعة وعصرية وندمج الذكاء الاصطناعي في سير عمل الشركات. لديك مشروع أو سؤال؟ يسعدنا مساعدتك.