لقد قرأت هذه المرة وثائق تطوير Dusk، ولم يكن الذي جعلني أتوقف فعلًا هو ZK، ولا الخصوصية.
بل كانت هناك تفاصيل صغيرة لواجهة برمجية:** تخبر العقد العميل بإصدار Rusk الخاص بها، كما يمكن للعميل أن يطلب نطاقًا من الإصدارات بشكلٍ استباقي.**
إذا لم تكن الإصدارات متوافقة، يتم الرفض مباشرة.
عند النظر لأول مرة، لا يبدو أن هذا له علاقة مطلقًا بالرواية الكبرى للبلوك تشين.
لكن عندما أضعه في سير العمل الحقيقي للتطوير، أجده مثيرًا للاهتمام بالفعل.
لأن أكثر ما تخشاه تطبيقات البلوك تشين على الإطلاق ليس أن الواجهة بطيئة قليلًا.
بل هو:
أن تكون الأمور تعمل اليوم، ثم بعد الترقية فجأة تبدأ تظهر حالة “بعض العقد تتعرف، وبعض العقد لا تتعرف”.
إذا لم يعرف المطور ما الإصدار الذي تعمل عليه العقد التي يتصل بها فعلًا، يصبح من الصعب جدًا تحديد ما إذا كانت المشكلة مصدرها الكود، أم العقد، أم أن سببها في جوهر البروتوكول نفسه.
يضع Dusk الآن معلومات الإصدار مباشرةً داخل استجابة HTTP، وفي الوقت نفسه يسمح للعميل بتنفيذ strict version check.
كنتُ في السابق أميل أكثر إلى تقييم جودة L1 بناءً على TPS والنهائية.
لكن الآن أشعر أن مثل هذه القواعد الصغيرة على مستوى الواجهة—تكشف أكثر ما إذا كانت الشبكة تفكر فعلًا في المتاعب التي سيواجهها المطورون في الواقع.
فالبنية التحتية لا تخشى التعقيد.
بل تخشى **عدم اليقين**.
إذا كان تطبيق ما يعتمد على قدرات عقدة معيّنة، ثم بعد ترقية العقد تتغير سلوكياتها، فعادةً ما لا يكون الأسوأ هو فريق البروتوكول، بل التطبيق الذي تم إطلاقه بالفعل.
لذلك فإن التحكم بالإصدارات الذي يبدو وكأنه “عمل مهندس” في ظاهره، إنما يعالج مشكلة واقعية جدًا:
أن يعرف المطور مع أي مجموعة من قواعد البروتوكول يتحدث تحديدًا.
وهذا أيضًا ما يجعلني أعتقد الآن أن Dusk جديرة بالبحث.
فالـ L1 الناضج لا يكفي أن “يشغّل السلسلة”.
بل يجب أيضًا أن يوضح للآخرين أين تقع الحدود عندما ينضمون إليه.
#dusk $DUSK @Dusk
بل كانت هناك تفاصيل صغيرة لواجهة برمجية:** تخبر العقد العميل بإصدار Rusk الخاص بها، كما يمكن للعميل أن يطلب نطاقًا من الإصدارات بشكلٍ استباقي.**
إذا لم تكن الإصدارات متوافقة، يتم الرفض مباشرة.
عند النظر لأول مرة، لا يبدو أن هذا له علاقة مطلقًا بالرواية الكبرى للبلوك تشين.
لكن عندما أضعه في سير العمل الحقيقي للتطوير، أجده مثيرًا للاهتمام بالفعل.
لأن أكثر ما تخشاه تطبيقات البلوك تشين على الإطلاق ليس أن الواجهة بطيئة قليلًا.
بل هو:
أن تكون الأمور تعمل اليوم، ثم بعد الترقية فجأة تبدأ تظهر حالة “بعض العقد تتعرف، وبعض العقد لا تتعرف”.
إذا لم يعرف المطور ما الإصدار الذي تعمل عليه العقد التي يتصل بها فعلًا، يصبح من الصعب جدًا تحديد ما إذا كانت المشكلة مصدرها الكود، أم العقد، أم أن سببها في جوهر البروتوكول نفسه.
يضع Dusk الآن معلومات الإصدار مباشرةً داخل استجابة HTTP، وفي الوقت نفسه يسمح للعميل بتنفيذ strict version check.
كنتُ في السابق أميل أكثر إلى تقييم جودة L1 بناءً على TPS والنهائية.
لكن الآن أشعر أن مثل هذه القواعد الصغيرة على مستوى الواجهة—تكشف أكثر ما إذا كانت الشبكة تفكر فعلًا في المتاعب التي سيواجهها المطورون في الواقع.
فالبنية التحتية لا تخشى التعقيد.
بل تخشى **عدم اليقين**.
إذا كان تطبيق ما يعتمد على قدرات عقدة معيّنة، ثم بعد ترقية العقد تتغير سلوكياتها، فعادةً ما لا يكون الأسوأ هو فريق البروتوكول، بل التطبيق الذي تم إطلاقه بالفعل.
لذلك فإن التحكم بالإصدارات الذي يبدو وكأنه “عمل مهندس” في ظاهره، إنما يعالج مشكلة واقعية جدًا:
أن يعرف المطور مع أي مجموعة من قواعد البروتوكول يتحدث تحديدًا.
وهذا أيضًا ما يجعلني أعتقد الآن أن Dusk جديرة بالبحث.
فالـ L1 الناضج لا يكفي أن “يشغّل السلسلة”.
بل يجب أيضًا أن يوضح للآخرين أين تقع الحدود عندما ينضمون إليه.
#dusk $DUSK @Dusk
