تدفق إجراء التوقيع على إجراء معروّف

الغالبية العظمى من الأفراد الذين يتعاملون مع الأنظمة الرقمية لا يولون اهتمامًا كبيرًا لما يحدث بين وقت تقديم العنصر ووقت التأكد من المعلومات. تضغط على زر، وسيحدث شيء، هذا كل شيء. ومع ذلك، عندما يتم ذلك على شكل اعتماد، أو مؤهل، أو فحص هوية، أو اتفاق، أو سجل حكومي، فإن ما يحدث في وسط العملية يهم بشكل كبير. تحت @SignOfficial، توجد عملية رسمية محددة جيدًا تقبل مدخلًا وتحوله إلى شيء يمكن التحقق منه بشكل مستقل، دون استدعاء أي شخص، ودون الحاجة إلى الحفاظ على قاعدة بيانات مركزية، ودون أن تصبح عملية التحقق قديمة بمجرد أن يصبح ذلك غير مريح.

تبدأ العملية عندما لا يتم تقديم أي بيانات على الإطلاق. يجب أولاً تحديد مخطط (Schema) قبل أن يتم أي تصديق، وهو بمثابة الخطة الأساسية لكيفية تنظيم المعلومات، ونوعها، وشكلها. اعتبر المخطط بمثابة تحديد مسبق لما من المتوقع أن يبدو عليه الاعتماد قبل توقيعه. فحص KYC، شهادة جامعية، شهادة امتثال - كل منها له شكله الخاص، ويحتاج إلى حقول مختلفة، ويملك علاقات مختلفة بين نقاط البيانات. سجل المخططات (Schema Registry) هو مستودع عام لهذه القوالب بواسطة $SIGN، مما يوفر لمصدق يعمل وفقًا لمخطط معين معيارًا متفقًا عليه للعمل به. هذا هو الأساس الذي يجعل البيانات قابلة للقراءة والكتابة من قبل أي طرف ثالث في downstream التصديق الناتج.

عندما يوجد مخطط، يمكن للمصدق، أو الشخص، أو المؤسسة، أو العقد الذكي إصدار تصديق. يتم تأكيد صحة الادعاء وتصديقه. تقوم SIGN بذلك باستخدام بيانات موقعة رقميًا ومهيكلة تلتزم بالمخطط المسجل، وتُؤمن على السلسلة أو خارجها. يكمل المصدق الحقول اللازمة، ويوقع المعلومات بمفتاحه الخاص بمساعدة التوقيع الرقمي، ويرسلها. هذا هو الفرق بين التصديق وسجل بسيط. فهو لا يثبت فقط وجود البيانات، بل يثبت أن طرفًا معينًا وقابلًا للتحديد قد شهد بصحتها في وقت معين.

بمجرد توقيع التصديق، يتخذ البروتوكول قرارات بشأن مكان تخزينه اعتمادًا على حجمه واستخدامه. يمكن تخزين التصديقات الصغيرة بالكامل على السلسلة لضمان أقصى درجات الأمان، بينما يتم تخزين البيانات الأساسية خارج السلسلة - على Arweave أو IPFS - مع وجود ارتباط تشفيري مع blockchain. هذا قرار تصميم مهم. من المكلف وغير عملي تخزين كل شيء على السلسلة، خاصة أنظمة الاعتماد التي تستخدمها الحكومات. ستتمكن SIGN من العمل على ملايين الاعتمادات عن طريق عزل دليل الإثبات وجسم البيانات لتجنب تسجيل جميع البايتات في سجل تشفيري. تحتوي السلسلة على العنصر الأهم، وهو بصمة التحقق. والباقي يُخزن في تخزين غير متطاير وحذر.

يحدث التحقق عند إنشاء التصديق وليس بعد ذلك. يتم استدعاء Hooks المخطط المعروفة باسم ISPHooks بعد كل وظيفة تصديق، مما يتيح تنفيذ فحوصات ومنطق إضافي عند نقطة الإنشاء. ستعيد عملية التراجع عن Hook إلى حالة التراجع عن المعاملة كاملة، وبالتالي لن يتم تسجيل بيانات غير صحيحة. هذا نموذج أبسط من الأنظمة التي يستخدمها معظمهم. بدلاً من وضع علامة عليها للمستقبل، ترفض SIGN التصديقات غير الصحيحة عند إصدارها. يتم فحص القائمة البيضاء، والرسوم، والتنسيق، قبل أي إجراء يتم تنفيذه. عندما يتم تسجيل التصديق على السلسلة، يكون قد تم فحصه بالفعل.

يمكن فهرسة التصديقات، ويمكن البحث عن مواقعها باستخدام SignScan، وهو طبقة الفهرسة والمتصفح لـ SIGN. يوفر بروتوكول SIGN خدمة فهرسة للعثور على معلومات المخطط والتصديق بأسرع وقت ممكن، من خلال واجهات REST و GraphQL، مباشرة مع SDK الخاص بـ NPM. يمكن لمصدق آخر، أو بوابة حكومية، أو تطبيق طرف ثالث استرجاع أي تصديق بواسطة معرفه، والتحقق من توقيعه، والتحقق من المخطط، والتحقق من الطابع الزمني، والتأكد من عدم إلغائه. كل ذلك دون الحاجة للتواصل مع المصدر الأصلي. الثقة تُبنى على البنية التحتية.

إنه شيء أكثر ديمومة من وثيقة، وأكثر صدقًا من سجل قاعدة بيانات يُنشئه هذا التدفق. إنه سلسلة من عمليات الحفظ، الإدخال، التحقق من المخطط، التوقيع التشفيري، التخزين، وأخيرًا الاسترجاع، حيث يمكن تتبع كل عملية، ولا يتطلب أي منها شخصًا يتحمل المسؤولية بعد ذلك. يتم تداول رمز $SIGN عبر هذا النظام بأكمله، حيث تُعالج رسوم المعاملات، وتُدار الحوكمة، وتُقدم حوافز الشبكة لتشغيلها.

إنه التصميم الفعلي للتحقق من طرف إلى طرف، والذي تم تصميمه بشكل صحيح. ليس PDF. ليس لقطة شاشة. ليس اتصالًا بمكتب المساعدة. بيانات موقعة رقميًا، مقيدة بمخطط، ومؤمنة تشفيرياً، تثبت نفسها في أي وقت لأي طرف يحتاج إلى فحصها.