لقد كنت أراجع تحديثات بروتوكول Dusk هذه الأيام، وعلقت بسبب تغيير صغير يسهل تجاهله:
**بدأ Boreas في مطالبة منصات التداول بأن تكون لديها “إدراك بالإصدار”.**
تبدو هذه الجملة كأنها صادرة عن مهندس.
لكن عندما قمت بتفكيكها، أدركت أنها تحل مشكلة واقعية جدًا:
إذا قامت سلسلة ما بترقية قواعد البروتوكول، فهل يمكن اعتبار معاملة واحدة “هي نفس المعاملة” بالنسبة للعُقد ذات الإصدارات المختلفة، حتى لو تغيرت القواعد؟
قدّم Boreas الآن معالجة للمعاملات مع مراعاة النسخ (canonical, version-aware)، كما عدّل تسعير الـ VM وقواعد النشر، وأعاد تعريف دلالات انتقالات الحالة ومعنى reverted-event. وتذكر الوثائق الرسمية صراحةً أن هذه التغييرات تشكّل جزءًا أساسيًا من عملية هارد فورك.
كنت عندما أنظر إلى L1، أركّز بسهولة على TPS والنهائية وGas.
لكن الآن أشعر بالعكس: قد يكون الأهم هو **هل يمكن بعد ترقية البروتوكول الحفاظ على أن الجميع يفهمون “نفس مجموعة القواعد”**.
لأن المشكلة الحقيقية ليست الترقية نفسها.
بل هي:
كيف تفسّر العقد؟
كيف تفسّر جهة التحقق؟
كيف تفسّر إعادة تشغيل المعاملات التاريخية (replay)؟
وكيف تفسّرها التطبيقات؟
طالما أن هناك طبقة واحدة تختلف في فهمها، فلن تكون المشكلة أداءً بعد الآن؛ بل سيكون السؤال برمته: من الذي يُعترف له بالحالة الصحيحة؟
لذلك جعلني Boreas أفهم لأول مرة بشكل ملموس لماذا تقضي سلاسل الكتل الناضجة وقتًا كبيرًا في التعامل مع هذه القواعد التي تبدو “غير مثيرة”.
إنها لا تضيف ميزة جديدة للمستخدم.
بل إنها ترسم حدودًا مسبقًا للمطورين والـ nodes والتطبيقات في المستقبل.
كنت أظن أن كتابة مثل هذه التحديثات صعبة لأنها لا تتضمن أرقامًا جميلة ولا منتجًا جديدًا.
لكن الآن أشعر بالعكس: هذا هو المكان الذي يظهر فيه نضج هندسة السلسلة بشكل أوضح.
**البروتوكول الموثوق حقًا لا يقتصر على التعامل مع معاملات اليوم، بل يجب أن يضمن أيضًا أنه بعد ترقية الغد، لن تكتسب معاملات الأمس فجأة تفسيرًا مختلفًا.**
ربما هذا هو السبب الحقيقي في أن Boreas يستحق أن يُنظر إليه.
#dusk $DUSK @Dusk
**بدأ Boreas في مطالبة منصات التداول بأن تكون لديها “إدراك بالإصدار”.**
تبدو هذه الجملة كأنها صادرة عن مهندس.
لكن عندما قمت بتفكيكها، أدركت أنها تحل مشكلة واقعية جدًا:
إذا قامت سلسلة ما بترقية قواعد البروتوكول، فهل يمكن اعتبار معاملة واحدة “هي نفس المعاملة” بالنسبة للعُقد ذات الإصدارات المختلفة، حتى لو تغيرت القواعد؟
قدّم Boreas الآن معالجة للمعاملات مع مراعاة النسخ (canonical, version-aware)، كما عدّل تسعير الـ VM وقواعد النشر، وأعاد تعريف دلالات انتقالات الحالة ومعنى reverted-event. وتذكر الوثائق الرسمية صراحةً أن هذه التغييرات تشكّل جزءًا أساسيًا من عملية هارد فورك.
كنت عندما أنظر إلى L1، أركّز بسهولة على TPS والنهائية وGas.
لكن الآن أشعر بالعكس: قد يكون الأهم هو **هل يمكن بعد ترقية البروتوكول الحفاظ على أن الجميع يفهمون “نفس مجموعة القواعد”**.
لأن المشكلة الحقيقية ليست الترقية نفسها.
بل هي:
كيف تفسّر العقد؟
كيف تفسّر جهة التحقق؟
كيف تفسّر إعادة تشغيل المعاملات التاريخية (replay)؟
وكيف تفسّرها التطبيقات؟
طالما أن هناك طبقة واحدة تختلف في فهمها، فلن تكون المشكلة أداءً بعد الآن؛ بل سيكون السؤال برمته: من الذي يُعترف له بالحالة الصحيحة؟
لذلك جعلني Boreas أفهم لأول مرة بشكل ملموس لماذا تقضي سلاسل الكتل الناضجة وقتًا كبيرًا في التعامل مع هذه القواعد التي تبدو “غير مثيرة”.
إنها لا تضيف ميزة جديدة للمستخدم.
بل إنها ترسم حدودًا مسبقًا للمطورين والـ nodes والتطبيقات في المستقبل.
كنت أظن أن كتابة مثل هذه التحديثات صعبة لأنها لا تتضمن أرقامًا جميلة ولا منتجًا جديدًا.
لكن الآن أشعر بالعكس: هذا هو المكان الذي يظهر فيه نضج هندسة السلسلة بشكل أوضح.
**البروتوكول الموثوق حقًا لا يقتصر على التعامل مع معاملات اليوم، بل يجب أن يضمن أيضًا أنه بعد ترقية الغد، لن تكتسب معاملات الأمس فجأة تفسيرًا مختلفًا.**
ربما هذا هو السبب الحقيقي في أن Boreas يستحق أن يُنظر إليه.
#dusk $DUSK @Dusk
