#GIWA #链上安全 يبدو أن رقم سلسلة (Chain ID) صحيحًا، فهل يمكن للأصول أن تعبر بأمان؟ تقدم أزمة GIWA اليوم مثالًا صارخًا: الحلقة الأكثر خطورة قد لا تكون عند ظهور تحذير من المحفظة، بل عندما يعتقد المستخدم والتطبيق أنهما قد تحققا من هوية الشبكة لديهما.
لنرتب الخط الزمني أولًا. في بكين وقت 27 سبتمبر الساعة 15:18، صرّحت مؤسسة GIWA الرسمية بوضوح أن الشبكة الرئيسية (Mainnet) غير قيد التشغيل حاليًا، وأن أي منشورات تدّعي امتلاك وصول إلى RPC لشبكة GIWA الرئيسية ليست صحيحة، مع التنبيه إلى التحقق من عقد التفاعل (interact contract). في الساعة 16:06، نشرت DyorSwap إعلانًا عن حادث أمني: كانت «شبكة GIWA الرئيسية» التي تعرّفت عليها سابقًا في الواقع سلسلة مزيفة تم إنشاؤها من قبل المحتالين. وذكرت الشركة أن الشبكة المزيفة استخدمت Chain ID 9134، ما جعل التحقق الأولي يبدو موثوقًا؛ وقد ترتبت خسائر كبيرة عبر جسر تبادل/ربط عبر السلاسل (cross-chain bridge) ذي الصلة. جاءت هذه الادعاءات حول الخسائر من DyorSwap، وما زالت الأرقام الدقيقة والعناوين وسلسلة المسؤولية قيد التحقق المستقل.
الأمر الذي يستحق الانتباه فعلًا ليس ما إذا كان رقم واحد قد تم إدخاله بشكل صحيح. إن Chain ID لا يخبر إلا المحفظة بالشبكة ذات الرقم المعرّف التي تتفاعل معها؛ ولا يمكنه وحده إثبات أن RPC تابع رسميًا للمشروع، ولا ضمان أن عقد الجسر والواجهة الأمامية (الفرونت إند) ومسار الأموال فعليًا هو ما يدعيه المحتال. يمكن للمحتالين تمامًا نسخ إعداد يبدو صحيحًا، ثم يدفعون المستخدمين لعبور السلاسل برسالة سردية مفادها أن «الشبكة الرئيسية تم تشغيلها». الوثائق الرسمية لـ GIWA المتاحة حاليًا تشير إلى شبكة اختبار Sepolia، بينما لا تزال الصفحة الرئيسية تحمل وسم «قيد التطوير»؛ كون شبكة الاختبار تعمل وأنه يمكن استقبال الأصول الحقيقية بأمان على الشبكة الرئيسية أمران مختلفان.
تقديري هو أن ما انكشف هذه المرة يتمثل في ضغط «مسؤولية التحقق» إلى نقطة واحدة: الحالة الرسمية للمشروع، الشبكة التي توفرها الواجهة الأمامية للتطبيق، عقد جسر الربط عبر السلاسل، وصفحة تأكيد المحفظة. إذا لم تتطابق هذه العناصر مستقلة عن بعضها، فإن السماح يتم استكماله بمجرد Chain ID، ويصبح التحقق شكليًا. وقد أشارت DyorSwap إلى أنها ستتواصل مع فريق الأمان لتتبع الأموال وحفظ الأدلة، وستدرس استخدام تعويض من الخزانة (الـ treasury). هذا مجرد خطة للتعامل، وليس تأكيدًا بعد بأهلية التعويض أو مبالغ التعويض أو توقيته.
الخطوة التالية التي يجب النظر إليها ليست من يعتذر أولًا، بل العناوين التي يمكن التحقق منها، والمعاملات، ونطاق المتضررين، وقواعد التعويض، فضلًا عن التنفيذ الفعلي. إذا أظهر تتبع السلسلة أن المسار المتأثر لا يطابق ما ورد في الإعلان، فسأعدّل حكمِي على آلية الحادث؛ وإذا تم نشر عملية تحقق كاملة يمكن الرجوع إليها، فسأغير كذلك تقييمِي لمخاطر الضبط/التحكم اللاحق. برأيك، قبل إطلاق منتج عبر السلاسل لشبكة جديدة، ما الذي لا يمكن الاستغناء عنه: التحقق من مصدر الشبكة الرسمية، أم المراجعة المستقلة لعقد الجسر ومسار الأموال؟
لنرتب الخط الزمني أولًا. في بكين وقت 27 سبتمبر الساعة 15:18، صرّحت مؤسسة GIWA الرسمية بوضوح أن الشبكة الرئيسية (Mainnet) غير قيد التشغيل حاليًا، وأن أي منشورات تدّعي امتلاك وصول إلى RPC لشبكة GIWA الرئيسية ليست صحيحة، مع التنبيه إلى التحقق من عقد التفاعل (interact contract). في الساعة 16:06، نشرت DyorSwap إعلانًا عن حادث أمني: كانت «شبكة GIWA الرئيسية» التي تعرّفت عليها سابقًا في الواقع سلسلة مزيفة تم إنشاؤها من قبل المحتالين. وذكرت الشركة أن الشبكة المزيفة استخدمت Chain ID 9134، ما جعل التحقق الأولي يبدو موثوقًا؛ وقد ترتبت خسائر كبيرة عبر جسر تبادل/ربط عبر السلاسل (cross-chain bridge) ذي الصلة. جاءت هذه الادعاءات حول الخسائر من DyorSwap، وما زالت الأرقام الدقيقة والعناوين وسلسلة المسؤولية قيد التحقق المستقل.
الأمر الذي يستحق الانتباه فعلًا ليس ما إذا كان رقم واحد قد تم إدخاله بشكل صحيح. إن Chain ID لا يخبر إلا المحفظة بالشبكة ذات الرقم المعرّف التي تتفاعل معها؛ ولا يمكنه وحده إثبات أن RPC تابع رسميًا للمشروع، ولا ضمان أن عقد الجسر والواجهة الأمامية (الفرونت إند) ومسار الأموال فعليًا هو ما يدعيه المحتال. يمكن للمحتالين تمامًا نسخ إعداد يبدو صحيحًا، ثم يدفعون المستخدمين لعبور السلاسل برسالة سردية مفادها أن «الشبكة الرئيسية تم تشغيلها». الوثائق الرسمية لـ GIWA المتاحة حاليًا تشير إلى شبكة اختبار Sepolia، بينما لا تزال الصفحة الرئيسية تحمل وسم «قيد التطوير»؛ كون شبكة الاختبار تعمل وأنه يمكن استقبال الأصول الحقيقية بأمان على الشبكة الرئيسية أمران مختلفان.
تقديري هو أن ما انكشف هذه المرة يتمثل في ضغط «مسؤولية التحقق» إلى نقطة واحدة: الحالة الرسمية للمشروع، الشبكة التي توفرها الواجهة الأمامية للتطبيق، عقد جسر الربط عبر السلاسل، وصفحة تأكيد المحفظة. إذا لم تتطابق هذه العناصر مستقلة عن بعضها، فإن السماح يتم استكماله بمجرد Chain ID، ويصبح التحقق شكليًا. وقد أشارت DyorSwap إلى أنها ستتواصل مع فريق الأمان لتتبع الأموال وحفظ الأدلة، وستدرس استخدام تعويض من الخزانة (الـ treasury). هذا مجرد خطة للتعامل، وليس تأكيدًا بعد بأهلية التعويض أو مبالغ التعويض أو توقيته.
الخطوة التالية التي يجب النظر إليها ليست من يعتذر أولًا، بل العناوين التي يمكن التحقق منها، والمعاملات، ونطاق المتضررين، وقواعد التعويض، فضلًا عن التنفيذ الفعلي. إذا أظهر تتبع السلسلة أن المسار المتأثر لا يطابق ما ورد في الإعلان، فسأعدّل حكمِي على آلية الحادث؛ وإذا تم نشر عملية تحقق كاملة يمكن الرجوع إليها، فسأغير كذلك تقييمِي لمخاطر الضبط/التحكم اللاحق. برأيك، قبل إطلاق منتج عبر السلاسل لشبكة جديدة، ما الذي لا يمكن الاستغناء عنه: التحقق من مصدر الشبكة الرسمية، أم المراجعة المستقلة لعقد الجسر ومسار الأموال؟
