قُل الحقيقة، عندما أنظر إلى SIGN الآن، أول ما يخطر في بالي ليس "هل يمكن إصدار هذا الإثبات"، بل مجموعة أخرى من الأسئلة الأكثر تحديدًا: متى تنتهي صلاحيته، من يمكنه إلغاؤه، ماذا يحدث عند انتهاء صلاحيته، هل لا يزال الإصدار القديم ساريًا بعد التجديد، وأي إصدار سيعترف به النظام لاحقًا.
عندما يتحدث الكثير من الناس عن الشهادات، المؤهلات، والإثباتات، يعتقدون تلقائيًا في "هل يوجد" فقط. لكنني أزداد قناعة بأن ما يجعل الأنظمة المعقدة صعبة حقًا ليس مجرد إصدار مرة واحدة، بل هل يمكن للنظام استيعاب كامل دورة حياة هذا الإثبات من السريان إلى انتهاء الصلاحية، من الإلغاء إلى التحديث، من الإصدار القديم إلى الإصدار الجديد. لأن الإثباتات في الواقع ليست مجرد لقطة تكتمل بمجرد التصوير. بعض المؤهلات قد تنتهي، بعض التفويضات قد تُسحب، بعض التصريحات قد تكون سارية فقط لفترة معينة، وقد لا يُمكن استخدام الشهادات القديمة بمجرد تحديث معلومات الهوية. إذا كنت تعتقد أن الإثبات مجرد "نتيجة تُنتج مرة واحدة"، فإن التوزيع، الصلاحيات، وتقدير المؤهلات من السهل أن تتلوث بالحالة القديمة.
لذلك أصبحت لا أحب أكثر فأكثر ذلك النوع من سرديات المشاريع التي تكتب الإثبات بشكل خفيف. وكأن الأمر سينتهي بمجرد أن يكون هناك attestation، وكأن هناك credential، وكأن هناك تأكيدًا واحدًا. لكن الصعوبة الحقيقية على مستوى المنتج ليست “إرساله”، بل “كيف يستمر في الحياة”. هل ما زال هذا الإثبات صالحًا؟ تحت هذا الـ schema، هل يمكن للأشياء التي تم إصدارها لاحقًا أن تُستعلم، وتُلغى، وتُوقّع مجددًا، وتُستعاد كمرجع؟ بعد انتهاء صلاحية هذه النسخة، هل سيُخرج النظام تلقائيًا الحالة القديمة من المسارات اللاحقة؟ هذه الأسئلة إذا لم يُعالجها أحد، فغالبًا ما تكون “الشهادات القابلة للتحقق” مجرد لقطات على السلسلة وليست كائنات ضمن مسار الإجراءات.
وهذا أيضًا هو مستوى التفكير الذي أتعمقه عندما أنظر إلى Sign Protocol. في نظري، attestation ليست مجرد أثر يُترك مرة واحدة، بل ينبغي أن تكون كائنًا ديناميكيًا يمكن الاستعلام عنه، ويجوز الاستشهاد به، ويمكن إبطاله، ويمكن أن تنتهي صلاحيته، ويمكن تجديده. وقيمة الـ schema لا تكمن فقط في تعريف الحقول، بل في جعل هذا النوع من الكائنات يمتلك بنية مستقرة، بحيث يعرف النظام لاحقًا كيف ينظر إليها، وكيف ينظر إلى نسختها، وكيف ينظر إلى تغيرات حالتها. بمعنى آخر، لا يتعامل النظام مع “هل توجد شهادة أم لا”، بل مع “ما هي الحالة التي توجد عليها هذه الشهادة الآن”. تبدو هاتان الكلمتان متشابهتين، لكن الفرق الحقيقي هو نضج سلسلة المنتج بأكملها.
إن معنى TokenTable هنا لن يراه كثيرون كما ينبغي. فهو ليس مجرد “أداة إصدار عملة” أو “منصة توزيع”، بل هو ما إذا كانت دورة حياة الإثبات يمكن أن تدخل فعليًا ضمن حلقة التوزيع وتنفيذ الصلاحيات. إذا كانت attestation الخاصة بالأهلية انتهت صلاحيتها، أو تم إبطالها، أو تم استبدالها بإصدار جديد، فهل منطق الانتماء وفتح الوصول والاستلام في الخطوة التالية يمكنه أن يتحدث تلقائيًا بنفس الاتجاه؟ إذا لم يحدث ذلك، فإن كل ما فعلته من ادعاءات قابلة للتحقق يبقى في جوهره مجرد شيء موجود على السلسلة، وليس جزءًا حقيقيًا من النظام. كثيرون يكتبون المشاريع بسهولة: “تم إثبات ذلك”، لكن ما يهمني أكثر الآن هو: بعد أن يوجد، كيف يعيش؟ وكيف يتغير؟ وكيف يموت؟ وهل بعد موته يعرف النظام اللاحق أنه قد مات بالفعل؟
لماذا أهتم بهذا الأمر تحديدًا؟ لأنني أجد أكثر فأكثر أن العمليات في العالم الحقيقي لن تتحول فجأة إلى عالم ثابت لمرة واحدة لمجرد أنك أدخلته إلى السلسلة. بالعكس تمامًا: كلما اقتربنا أكثر من سيناريوهات العالم الحقيقي، كلما طالت دورة حياة الإثبات، وزادت تعقيدات إدارة النسخ، وأصبح من السهل أن تتغير حالات الصلاحيات. لديك أهلية اليوم لا يعني أن لديك أهلية أيضًا في الشهر القادم؛ حصولك على تفويض اليوم لا يعني أن التفويض لن يُسحب أبدًا؛ أن هذه التصريحات يمكن الاستشهاد بها اليوم لا يعني أنها ستظل نفس مجموعة القواعد بعد ستة أشهر. أكثر ما تخشاه الأنظمة المعقدة ليس ألا يكون هناك إثبات، بل أن يحمل أحدهم إثباتًا منتهي الصلاحية ويواصل السير به. ظاهريًا توجد كائنات وسجلات وحالة، لكن في الحقيقة المسار اللاحق كله يظل مجرورًا بالإصدار القديم.
ومن زاوية باحث في المنتجات، أشعر أن مثل هذه الأشياء ليست مثيرة للضجة. لكن بمجرد دمجها في مزيد من مسارات سلسلة الكتل، ستصبح الالتصاقية قوية جدًا. لأنك بمجرد أن تبدأ بمعالجة دورة حياة الإثبات بجدية، ستصبح كل الأمور اللاحقة مثل الأهلية والصلاحيات والتوزيع والاستمرارية أكثر استقرارًا. وبالعكس، إذا ظلت تعامل الإثبات كنتيجة ثابتة لمرة واحدة، فقد تتبخر في النهاية قدرات التحقق التي تبدو رائعة، بسبب “تحديث الحالة” وهو أكثر مشكلة واقعية. قد لا يفهم السوق قيمة ذلك فورًا على المدى القصير، لأنها ليست سردية تولّد نقطة انفعال بسرعة. لكن من منظور عمق المنتج، أهم من “كم عدد الإثباتات التي تم إصدارها”.
لذلك أنا الآن أنظر إلى $SIGN ، ولا أريد فقط أن أعرف ما إذا كان بإمكانه إصدار عدة إثباتات. بل أريد أن أرى هل يمكنه تحويل سلسلة “الإثبات من الإنشاء إلى انتهاء الصلاحية” إلى بنية حقيقية. هل يمكن للنظام أن يعرف هل هذه attestation جديدة أم قديمة، حية أم ميتة، وهل يمكن استخدامها، وهل ينبغي أن يُواصلها مسار الإجراءات اللاحقة؟ لأن كثيرًا من المشاريع تتعامل مع الإثبات كأنه مجرد لقطة شاشة، لكن الجزء الأصعب هو أن الإثبات نفسه له دورة حياة. من يستطيع أن يحول دورة الحياة هذه إلى منتج؟ ليس مجرد ميزة إضافية، بل شيء أقرب إلى منطق العالم الحقيقي: يتغير، وينتهي، ويتم تحديثه.