From LaTeX and OCaml to LEAN4 and Executables: Lean-Checked Theorems and Generating Proof-Carrying Rust
تقدم هذه الورقة واجهة أمامية بلغة بايثون تعتمد على نظام هيندلي-ميلنر لمجموعة فرعية من لغة أوكامل، تقوم في آن واحد بتوليد نظريات مُثبتة عبر نظام "لين 4" وكود برمجياً قابلاً للتنفيذ بلغة "رست" مع عقود تحمل براهين، وقد تم التحقق من نجاح النظام من خلال الأنواع الاستقرائية المتبادلة، وحساب الأعداد الصحيحة الموقعة، والتحقق من التوافق بين التنفيذين لنواة ومعادلتها ذاتية الوصف.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في عالم البرمجيات، هناك توتر مستمر بين كيفية كتابة الكود وكيفية معرفة مدى أمانه. يستخدم المبرمجون لغات عالية المستوى لوصف المنطق المعقد بطريقة قابلة للقراءة والإدارة، ولكن الآلات التي تشغل هذا الكود تتحدث لغة أبسط وأكثر صرامة. وللانتقال من حالة إلى أخرى، تعمل المترجمات (compilers) كمترجمين، ولكن عملية الترجمة هذه هي المكان الذي تختبئ فيه الأخطاء غالبًا. فمن الممكن أن يؤدي خطأ في الترجمة إلى تحويل تعليمات آمنة إلى تعليمات خطيرة، مما يتسبب في تعطل البرنامج أو تصرفه بشكل غير متوقع. ولعقود من الزمن، كانت الطريقة الأكثر موثوقية لضمان السلامة هي التحقق من كود الآلة النهائي، ولكن هذا أمر صعب لأن المعنى عالي المستوى للبرنامج الأصلي غالبًا ما يُفقد في العملية. والسؤال الذي يطرحه الباحثون هو ما إذا كان بإمكاننا الحفاظ على وضوح اللغة الأصلية عالية المستوى مع الاستمرار في إثبات، بيقين مطلق، أن تعليمات الآلة النهائية ستفعل بالضبط ما ننوي فعله.
لقد بنى برنت هارتشورن نظامًا يجيب على هذا السؤال من خلال التعامل مع قطعة واحدة من الكود كشيئين مختلفين في آن واحد. تخيل وثيقة يمكن قراءتها في وقت واحد كبرهان رياضي وكمجموعة من التعليمات لآلة. في هذا العمل الجديد، يأخذ المؤلف مجموعة فرعية من لغة برمجة تسمى OCaml، وهي معروفة بقواعدها الصارمة حول كيفية التعامل مع البيانات، ويعطي كل تعريف معنيين متميزين. أولاً، يُقرأ الكود كحجة منطقية، حيث يعمل هيكل البرنامج نفسه كبرهان على أن شروطًا معينة سيتم الوفاء بها دائمًا. ثانيًا، يتم ترجمة الكود نفسه إلى لغة مختلفة تسمى Rust، المصممة للسرعة والأمان، ثم تُترجم إلى برنامج يمكن للكمبيوتر تشغيله بالفعل. وتكمن عبقرية هذا النهج في التحقق: يتم فحص البرهان المنطقي بواسطة محرك رياضي صغير وموثوق، بينما يتم فحص البرنامج الذي يعمل مقابل "مفسر مرجعي" (reference interpreter) يحاكي الكود خطوة بخطوة. وإذا تطابق الاثنان، وإذا صمد البرهان المنطقي، فإن النتيجة تكون قطعة من البرمجيات تأتي مع شهادة أمان خاصة بها.
بدأ الباحثون ببناء مترجم يفهم جزءًا محددًا من لغة OCaml. هذا المترجم، المكتوب بلغة بايثون، صغير بما يكفي ليتم قراءته وفهمه من قبل شخص واحد، وهو أمر بالغ الأهمية لأنه إذا كان المترجم نفسه معقدًا للغاية، فلا يمكننا الوثوق بمخرجاته. إنه يأخذ كود OCaml ويقسمه إلى مسارين. في مسار البرهان، يقوم بتحويل الكود إلى تنسيق يمكن لنواة رياضية (mathematical kernel) فحصها. هذه النواة هي برنامج صغير يعمل كقاضٍ، يتحقق من سلامة المنطق دون وضع أي افتراضات. وفي مسار البرنامج، يقوم المترجم بتحويل الكود إلى لغة Rust، وهي لغة تُترجم إلى كود آلة أصلي سريع. ولضمان أن الترجمة كانت مثالية، بنى الفريق أيضًا مفسرًا مرجعيًا يشغل كود OCaml الأصلي مباشرة. ثم قاموا بتشغيل ثلاثة عشر برنامجًا نموذجيًا مختلفًا عبر كل من نسخة Rust المترجمة والمفسر. وفي كل حالة، أنتج الكود المترجم نفس المخرجات تمامًا مثل المفسر، مما أثبت أن عملية الترجمة لم تغير سلوك البرامج.
بمجرد ترجمة الكود بنجاح، طبق الفريق فحص سلامة صارم على نسخة Rust المترجمة. لقد تعاملوا مع الكود المترجم كعقد، حيث كُتبت قواعد محددة حول كيفية تصرف البرنامج كأطروحات رياضية. على سبيل المثال، تحققوا من أن الحسابات العددية لن تتجاوز الحد (overflow) وتلتف حول نفسها لتصبح رقمًا سالبًا عن طريق الخطأ، وهو مصدر شائع للأخطاء في البرمجيات. ووجدوا أنه بينما صحت معظم قواعد السلامة هذه، كانت هناك حالات استثنائية محددة كُسرت فيها القواعد. في أحد عشر سيناريو مختلفًا، وصل الكود المترجم إلى نقطة يمكن أن يحدث فيها تجاوز للعدد الصحي- (integer overflow)، مثل طرح أصغر رقم ممكن من الصفر. حدد النظام هذه الحالات بشكل صحيح كالتزامات مفتوحة (open obligations)، مما يعني أن الكود آمن في كل مكان باستثناء هذه الحدود المحددة والمعروفة. ومن بين تسعين فحص سلامة إجمالي تم إجراؤها على البرامج النموذجية، تم إثبات تسعة وسبعين بالكامل، بينما تُرِكت الأحد عشر المتبقية مفتوحة لأنها مثلت حدودًا حقيقية يمكن الوصول إليها في طريقة تعامل الكمبيوتر مع الأرقام.
ذهب المشروع إلى أبعد من ذلك بتطبيق هذا الأسلوب على نواة نظام تشغيل صغيرة، وهي قطعة برمجية أساسية تدير موارد الكمبيوتر. أخذ الباحثون نواة كُتبت سابقًا بلغتي بايثون ورست، وأعادوا كتابتها بلغة OCaml الفرعية الخاصة بهم. ثم ترجموا هذه النسخة الجديدة إلى Rust وقاموا بترجمتها. وكانت النتيجة هي تنفيذ ثالث لنفس النواة. وعند اختبارها مقابل نسخة بايثون الأصلية، أجابت النسخة الجديدة المشتقة من OCaml بشكل صحيح في جميع حالات الاختبار الـ 236. حاول الفريق إثبات سلامة هذه النواة الجديدة، ونجحوا في إثبات 227 من أصل 236 من التزامات السلامة. أما الحالات القليلة التي ظلت دون إثبات فلم تكن أخطاءً في الكود، بل كانت فجوات في الأدوات الرياضية المستخدمة لفحصها، وتحديدًا فيما يتعلق بكيفية تعامل النظام مع الحلقات التكرارية والعدادات المعقدة. وقد أثبت هذا أن الطريقة يمكن أن تتوسع من الأمثلة الصغيرة إلى مكون وظيفي لنظام تشغيل.
ولعل الجزء الأكثر إثارة في هذا العمل هو القدرة على تحويل معادلة رياضية مباشرة إلى برنامج عامل. أخذ الباحثون معادلة رسمية تصف سلوك النواة، مكتوبة بتدوين رياضي قياسي، وأدخلوها في أداة قامت بتحويلها إلى كود OCaml. تم بعد ذلك ترجمة هذا الكود وتشغيله. وسلك البرنامج الناتج سلوكًا يطابق تمامًا ما وصفته المعادلة، حيث طابق مخرجات نموذج بايثون الأصلي في كل حالة. أظهرت هذه العملية أن وصفًا رياضيًا عالي المستوى يمكن تحويله إلى ملف ثنائي قابل للتنفيذ ومتحقق منه دون فقدان معناه. أثبت الفريق أن النسخة المترجمة من هذه المعادلة استوفت معظم عقود سلامتها، رغم أن بعض الخطوات المنطقية الأكثر تعقيدًا تطلبت مزيدًا من الصقل في أدوات الفحص.
تشير نتائج هذا العمل إلى مسار جديد لبناء برمجيات موثوقة. فمن خلال الحفاظ على الكود المصدري عالي المستوى والتحقق من معناه المنطقي وشكله المترجم في آن واحد، أنشأ الباحثون نظامًا تكون فيه سلامة البرنامج النهائي مدعومة ببرهان رياضي. نجح الأسلوب في تحديد القيود الواقعية في كيفية تعامل أجهزة الكمبيوتر مع الأرقام، مثل تجاوز العدد الصحي، وميز بينها وبين الأخطاء الفعلية. وبينما لم يثبت النظام كل قاعدة سلامة لأكثر أجزاء النواة تعقيدًا، إلا أنه أثبت الغالبية العظمى منها، وكانت الحالات التي ظلت مفتوحة محددة بوضوح كأماكن تحتاج فيها أدوات الفحص إلى تحسين، وليس الكود نفسه. يقف هذا العمل كدليل على إمكانية امتلاك عملية الترجمة من الكود عالي المستوى إلى تعليمات الآلة، مما يضمن أن الملف التنفيذي النهائي يحمل شهادة سلامة لا تقل صرامة عن المنطق الذي أنشأه.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.