أعدتُ مؤخرًا (@Dusk ) مراجعة ما كُتب حول جسر السلاسل المتقاطعة لهذا العام مرة أخرى، وأفضل ما يُشاهَد ليس كلمتي “تمت سرقته”، بل أين حدث العطل بالضبط. في 16 يناير، كانت المشكلة في محفظة التوقيع التي يستخدمها الجسر: بعد أن حصل المهاجم على صلاحية الإقراض، نقل الأصول من جهة Dusk، ثم حوّل جزءًا منها إلى BSC. أوضحت الجهة الرسمية بشكل صريح أن الأمر ليس فشلًا في الإجماع، وليس اختراقًا/اختراقًا للبروتوكول على مستوى L1.
لكن هذا لا يعني أن السلسلة الأساسية بخير، وأن على المستخدم تجاهل مخاطر الجسر. في البنية القديمة، كانت عملية استلام الأحداث والتوقيع وإطلاق الأموال كلها مضغوطة في مسار واحد: السرعة كانت جيدة، لكن بمجرد أن يُخترق جانب التوقيع، تصبح الصلاحيات شديدة التركّز. أما إعادة التصميم لاحقًا ففصلت بين ثلاث مسائل: أولًا، تُسجَّل الأحداث كمهام؛ وثانيًا، يقوم الـ worker بمعالجتها وفقًا لآلة حالات (state machine)؛ وثالثًا، تُحفظ المعاملة الأصلية المُوقَّعة أولًا، وإذا فشلت تُعاد عملية الإرسال لنفس المعاملة. كما أن المحفظة الساخنة لا تحتفظ إلا برصيدٍ يلزم للمدة القريبة، وإذا انخفض عن حدّ معيّن تُوقَف العملية، وتُكمَّل يدويًا في المحفظة الباردة.
كنتُ أيضًا سابقًا أسهل من الوقوع في فكرة أن “الجسر ليس بروتوكولًا” كجملة تعفي من المسؤولية، لكنني الآن أميل لرؤية الأمر بالعكس: طالما اعتبر المستخدم الجسر بوابة للسيولة، فهذا يعني أن الجسر دخل بالفعل حدود الأمان الحقيقية لـ $DUSK . إن أمان الإجماع على السلسلة وأمان نقاط دخول/خروج الأصول هما ورقتان يجب أن يحصل فيهما كلاهما على حدّ النجاح.
اتجاه المعالجة هذه المرة صحيح، لكن نقاط المخاطرة لم تختفِ: هل سيستمر تنفيذ عزل المفاتيح على المدى الطويل؟ وهل العتبة منطقية؟ وهل يمكن تدقيق التوقف وعمليات إضافة الرصيد (التعويض)؟ يجب الاستمرار في مراقبة كل ذلك. المجتمع #dusk ينبغي ألا يسأل فقط “هل تم اختراق السلسلة؟”، بل “أي مفتاح ما زال يحتفظ بصلاحيات تتجاوز النطاق الضروري؟”. أنتم عندما تنظرون إلى الجسر عبر السلاسل: هل تبدأون بتدقيق الشيفرة، أم تبدأون بفهم كيفية قصّ صلاحيات التشغيل؟
$TREE $ETH
لكن هذا لا يعني أن السلسلة الأساسية بخير، وأن على المستخدم تجاهل مخاطر الجسر. في البنية القديمة، كانت عملية استلام الأحداث والتوقيع وإطلاق الأموال كلها مضغوطة في مسار واحد: السرعة كانت جيدة، لكن بمجرد أن يُخترق جانب التوقيع، تصبح الصلاحيات شديدة التركّز. أما إعادة التصميم لاحقًا ففصلت بين ثلاث مسائل: أولًا، تُسجَّل الأحداث كمهام؛ وثانيًا، يقوم الـ worker بمعالجتها وفقًا لآلة حالات (state machine)؛ وثالثًا، تُحفظ المعاملة الأصلية المُوقَّعة أولًا، وإذا فشلت تُعاد عملية الإرسال لنفس المعاملة. كما أن المحفظة الساخنة لا تحتفظ إلا برصيدٍ يلزم للمدة القريبة، وإذا انخفض عن حدّ معيّن تُوقَف العملية، وتُكمَّل يدويًا في المحفظة الباردة.
كنتُ أيضًا سابقًا أسهل من الوقوع في فكرة أن “الجسر ليس بروتوكولًا” كجملة تعفي من المسؤولية، لكنني الآن أميل لرؤية الأمر بالعكس: طالما اعتبر المستخدم الجسر بوابة للسيولة، فهذا يعني أن الجسر دخل بالفعل حدود الأمان الحقيقية لـ $DUSK . إن أمان الإجماع على السلسلة وأمان نقاط دخول/خروج الأصول هما ورقتان يجب أن يحصل فيهما كلاهما على حدّ النجاح.
اتجاه المعالجة هذه المرة صحيح، لكن نقاط المخاطرة لم تختفِ: هل سيستمر تنفيذ عزل المفاتيح على المدى الطويل؟ وهل العتبة منطقية؟ وهل يمكن تدقيق التوقف وعمليات إضافة الرصيد (التعويض)؟ يجب الاستمرار في مراقبة كل ذلك. المجتمع #dusk ينبغي ألا يسأل فقط “هل تم اختراق السلسلة؟”، بل “أي مفتاح ما زال يحتفظ بصلاحيات تتجاوز النطاق الضروري؟”. أنتم عندما تنظرون إلى الجسر عبر السلاسل: هل تبدأون بتدقيق الشيفرة، أم تبدأون بفهم كيفية قصّ صلاحيات التشغيل؟
$TREE $ETH
