العقود الذكية المولدة بواسطة الذكاء الاصطناعي: أين تفيد، وأين تفشل، وكيفية استخدامها بأمان

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

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

ما الذي تغير في تطوير العقود الذكية بمساعدة الذكاء الاصطناعي؟

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

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

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

أين يقدم الذكاء الاصطناعي أكبر قيمة؟

1. النماذج الأولية السريعة

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

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

2. نماذج موحدة ومعايير مفهومة جيدًا

يمكن للذكاء الاصطناعي توفير الوقت في كتابة التعليمات البرمجية المتكررة عندما يتوافق السلوك المطلوب بالفعل مع المعايير المعتمدة. على سبيل المثال، يمكنه المساعدة في تجميع تطبيق ERC-20 أو ERC-721 باستخدام مكونات موثوقة بدلاً من إعادة بناء منطق الرموز الأساسي من الصفر.

هنا تبرز أهمية اختيار المكتبة. تُعرّف OpenZeppelin حزمة Contracts الحالية بأنها مكتبة مكونات مُدققة من قِبل المجتمع، تتضمن معايير وصلاحيات ووحدات بناء عقود ذكية قابلة لإعادة الاستخدام. كما تُفرّق وثائقها بين الإصدارات المستقرة المُدققة وإصدارات التطوير. راجع وثائق OpenZeppelin Contracts . بالنسبة للعديد من مشاريع الإنتاج، يُعدّ تكليف الذكاء الاصطناعي بتكوين مكونات مكتبة مُدققة أكثر أمانًا من تكليفه بابتكار عناصر أساسية مُكافئة من الصفر.

3. المساعدة في إعداد الاختبارات ومراجعتها

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

يكمن القيد في أن المراجعة القائمة على الذكاء الاصطناعي قد تغفل تحديدًا الخطأ المنطقي الأكثر أهمية في الأعمال. فقد يتعرف النموذج على إعادة الدخول النموذجية، لكنه يعجز عن فهم أن الافتراض الاقتصادي للبروتوكول، أو مصدر السعر، أو التسلسل المحاسبي، أو انتقال الحوكمة، كلها أمور خاطئة. كما وجدت دراسة نُشرت عام ٢٠٢٥ أن اكتشاف الثغرات الأمنية القائم على نموذج LLM قد يعاني من نتائج إيجابية خاطئة وانخفاض في دقة الاستدعاء لبعض فئات نقاط الضعف الحديثة في لغة Solidity. وهذا سبب وجيه لدمج مراجعة الذكاء الاصطناعي مع الاختبارات القائمة على التنفيذ، والتحليل الثابت، والاختبار العشوائي، والثوابت، ومراجعة الخبراء، بدلًا من استبدالها.

ما هي أهم المخاطر الأمنية؟

تُصنّف قائمة OWASP لأهم عشرة ثغرات أمنية في العقود الذكية لعام 2025 نقاط الضعف التالية ضمن فئات رئيسية: ثغرات التحكم في الوصول، والتلاعب بأسعار البيانات، والأخطاء المنطقية، وعدم التحقق من صحة المدخلات، وإعادة الدخول، والمكالمات الخارجية غير المُدققة، وهجمات القروض السريعة، والمشاكل الحسابية، والعشوائية غير الآمنة، وهجمات حجب الخدمة. تتوفر القائمة الكاملة من مشروع OWASP لأمن العقود الذكية . قد يواجه الكود المُولّد بواسطة الذكاء الاصطناعي أيًا من هذه الفئات؛ فلا يوجد استثناء أمني مُنفصل لأن الكود المصدري مُنتج بواسطة نموذج.

هل يكون الذكاء الاصطناعي أكثر أماناً عندما يستخدم مكتبات موثوقة؟

عادةً، ولكن فقط إذا كان التكامل صحيحًا. استخدام المكونات الجاهزة يقلل من كمية التعليمات البرمجية المخصصة الحساسة أمنيًا، وهو أمرٌ قيّم. مع ذلك، لا يضمن ذلك صحة الأدوار، أو المعلمات، أو التوريث، أو التهيئة، أو منطق الترقية، أو عمليات التكامل الخارجية.

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

ماذا عن العقود القابلة للتحديث؟

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

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

أي نهج تطويري يناسب أي حاجة؟

كيف ينبغي للفرق مراجعة العقود التي يتم إنشاؤها بواسطة الذكاء الاصطناعي؟

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

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

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

متى يجب رفض الكود الذي تم إنشاؤه بواسطة الذكاء الاصطناعي بدلاً من إصلاحه؟

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

قد يكون العقد الأصغر حجمًا، المبني على مكونات مفهومة، أفضل من تصميم معقد مُولّد لا يستطيع أي فرد في الفريق صيانته بثقة. ولطالما أوصت وثائق Solidity بالحفاظ على العقود صغيرة ومفهومة لهذا السبب تحديدًا.

كيف تعرف أن الذكاء الاصطناعي يحسن عملية التطوير؟

قِس النتائج المهمة. تشمل المؤشرات المفيدة تقليل وقت إنتاج الكود المُراجع، وزيادة تغطية الاختبار، وتحديد المزيد من الحالات الشاذة قبل النشر، وتقليل دورات مراجعة العمل الروتيني، وتحسين التوثيق. لا تستخدم "عدد أسطر الكود المُولّد" أو "وقت التجميع الأولي" كمقياس رئيسي للنجاح؛ فكلاهما قد يتحسن بينما تتدهور جودة الأمان.

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

خلاصة القول

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

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