في الأنظمة الموزعة، لا ينبغي أن يعتمد الثقة على خادم واحد يُصرّح بأن قرار التفويض صحيح. إذا وافق مكوّن واحد فقط أو رفض كل طلب، يصبح ذلك خطرًا أمنيًا وكذلك نقطة فشل وحيدة محتملة. يعالج نيوتن هذا التحدي باستخدام شواهد BLS لتوفير دليل تشفير بأن قرارات التفويض تمت الموافقة عليها من مجموعة مؤهلة من المشغّلين قبل أن تعتمد عليها العقود الذكية.
مشكلة الهندسة
تعتمد تطبيقات البلوك تشين الحديثة بشكل متزايد على معلومات خارج السلسلة، مثل التحقق من الامتثال، أو تقييم السياسات، أو اتخاذ قرارات بمساعدة الذكاء الاصطناعي. إن إرجاع نتيجة "السماح" أو "الرفض" فقط من خدمة خارج السلسلة يتطلب من المستخدمين والعقود الذكية الوثوق بتلك الخدمة.
تنتج البنية الموثقة لـ Newton بدلًا من ذلك شهادة تشفيرية لنتائج تقييم السياسة، مما يسمح للعقود الذكية بالتحقق من أن القرار نشأ من شبكة المشغلين الموزعة التابعة للبروتوكول وليس من سلطة واحدة.
ما هي شهادات BLS؟
وفقًا للورقة البيضاء التقنية لـ Newton، يقوم المشغلون بتقييم مهمة السياسة نفسها بشكل مستقل. وبعد الوصول إلى النتيجة الحتمية نفسها، ينتج المشغلون المشاركون توقيعات BLS فردية، والتي تُجمع في شهادة BLS واحدة تمثل اتفاق النصاب. ثم تُتحقق هذه الشهادة المجمعة قبل أن تستمر المعاملة المرتبطة بها.
بدلًا من إثبات أن مشغلًا واحدًا وافق على طلب ما، تثبت الشهادة أن النصاب المطلوب من المشغلين شارك في إنتاج قرار التفويض.
أين تقع في البنية المعمارية
ضمن سير العمل الموثق لـ Newton، تظهر شهادات BLS بعد تقييم السياسة وقبل التنفيذ على السلسلة.
يمكن تلخيص العملية كما يلي:
يتم تقديم نية معاملة.
يقيم المشغلون السياسة بشكل حتمي.
يتم إنشاء توقيعات BLS الفردية لنتيجة التقييم.
تُجمع التوقيعات في شهادة BLS واحدة.
يتحقق العقد الذكي من الشهادة المجمعة قبل تنفيذ المعاملة المصرح بها.
يضمن هذا الفصل أن التنفيذ يعتمد على دليل تشفيري على الاتفاق الموزع بدلًا من الثقة في استجابة وحيدة خارج السلسلة.
تشبيه بالواجهة الخلفية
يمكن لمهندسي الواجهة الخلفية أن يفكروا في شهادة BLS على أنها شيء مشابه لطلب عدة خدمات موافقة مستقلة قبل قبول طلب API.
في بيئة الخدمات المصغرة التقليدية، قد تقوم عدة أنظمة موافقة بالتوقيع بالموافقة قبل أن يستمر النشر. ويتبع Newton مبدأً معماريًا مشابهًا، إلا أن الموافقات ممثلة كتوقيعات تشفيرية تُجمع في شهادة واحدة مدمجة مناسبة للتحقق على سلسلة الكتل.
توجد حدود لهذه المقارنة. فعادةً ما تعتمد أنظمة الموافقة المؤسسية على الثقة التنظيمية، بينما يعتمد تحقق Newton على التحقق التشفيري من توقيعات المشغلين المجمعة بدلًا من الثقة في مزودي البنية التحتية الأفراد.
لماذا هذا مهم
بالنسبة للمطورين، توفر شهادات BLS جسرًا قابلًا للتحقق بين تقييم السياسة خارج السلسلة والتنفيذ على السلسلة.
بالنسبة لوكلاء الذكاء الاصطناعي، فإنها تتيح أن تستند الإجراءات الآلية إلى اتفاق تشفيري موزع بدلًا من خادم تفويض مركزي.
تستفيد أنظمة المؤسسات لأن نتائج التفويض تصبح قابلة للتحقق بشكل مستقل، بينما يمكن للمدققين فحص إيصالات الامتثال غير القابلة للتغيير التي يسجلها البروتوكول. وتوضح الوثائق أيضًا أن تقييمات السياسات حتمية، مما يجعل من الممكن إعادة تشغيلها للتحقق والاعتراض عند الحاجة.
تحليل معماري مستقل
يبرز التصميم الموثق عدة مزايا هندسية.
إن تجميع التوقيعات في شهادة واحدة يقلل الحاجة إلى أن تعالج العقود الذكية العديد من الموافقات الفردية مع الحفاظ على دليل الاتفاق الموزع. ويتطلب البروتوكول أيضًا نصابًا قابلًا للتهيئة من المشغلين المرهونين قبل إمكانية إنتاج شهادة صالحة، مما يمنع مشغلًا واحدًا أو ائتلافًا دون عتبة النصاب من تفويض المعاملات بمفرده.
من خلال الجمع بين تقييم السياسة الحتمي والشهادات التشفيرية المجمعة، يفصل Newton بوضوح بين التقييم والاتفاق والتنفيذ إلى مسؤوليات معمارية متميزة.
الخلاصة
توضح شهادات BLS مبدأً مهمًا في بنية Newton: يجب أن يكون التفويض قابلًا للتحقق، لا مجرد ادعاء. وبدلًا من مطالبة العقود الذكية بالثقة في خدمة خارجية، يوفر البروتوكول دليلًا تشفيريًا على أن مجموعة مشغلين مؤهلة قد اتفقت على نتيجة التفويض قبل التنفيذ.
إشعار شراكة مدفوعة: هذا التحليل التقني هو جزء من حملة Newton CreatorPad ومخصص للنقاش التعليمي فقط.
سؤال للنقاش: مع دمج تطبيقات اللامركزية المزيد من تقييم السياسات خارج السلسلة، هل يجب أن تصبح الشهادات التشفيرية الآلية القياسية لإثبات قرارات التفويض قبل تنفيذ العقود الذكية؟