مواقع Walrus تم الترويج لها بشكل مبالغ فيه، قائلين إن البيانات المخزنة عليها لا يمكن تعديلها بعد كتابتها، وبالتالي فهي مقاومة للرقابة بشكل طبيعي. يبدو الأمر رائعًا، لكن هناك مشكلة واقعية تم تجاهلها — وهي أن صفحات الويب بحاجة إلى تحديث.

كيف يمكن تنفيذ التحديثات؟ عليك إدخال طبقة وسيطة ديناميكية، عادةً ما تكون نطاق SuiNS أو معرف الكائن على السلسلة، هذا العنصر يلعب دور المؤشر، وهو مسؤول عن الإشارة إلى أحدث ملف HTML Blob. يبدو الأمر لا مركزيًا، أليس كذلك؟

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

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

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