مترجم Solidity البرمجي (solc)

ما هو مترجم Solidity البرمجي (solc)؟

مترجم Solidity البرمجي، المعروف باسم solc، هو الأداة التي تحوّل كود المصدر للعقود الذكية المكتوب بلغة Solidity إلى مخرجات قابلة لقراءة الآلة، ويمكن نشرها والتحقق منها وتحليلها والتفاعل معها على شبكات البلوكشين المشابهة لـ Ethereum.

Solidity هي لغة برمجة عالية المستوى للعقود الذكية، مصممة لآلة Ethereum الافتراضية، ويصفها موقع Solidity الرسمي بأنها لغة ذات كتابة ثابتة وأقواس معقوفة لتطوير العقود الذكية التي تعمل على Ethereum.

تكمن أهمية solc في أن شبكات البلوكشين لا تشغّل كود Solidity المقروء بشريًا مباشرةً.

بدلاً من ذلك، يكتب المطورون ملفات المصدر بلغة Solidity، ويحوّل المترجم هذه الملفات إلى بايت كود EVM وبيانات ABI والبيانات الوصفية والتمثيلات الوسيطة والتحذيرات والأخطاء ومخرجات البناء الأخرى.

توضح وثائق مترجم Solidity الرسمية أن المترجم يمكنه إنتاج مخرجات تتراوح بين الملفات الثنائية وAssembly وأشجار البنية النحوية المجردة وتقديرات الغاز.

في تطوير الكريبتو، تقع solc بين مطور العقد الذكي والعقد المنشور على السلسلة.

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

لذلك، لا تُعد solc مجرد أداة مريحة للمطورين.

بل هي جزء حاسم من أمان العقود الذكية وموثوقية النشر والتحقق من كود المصدر وثقة المستخدمين.

ببساطة، مترجم Solidity هو البرنامج الذي يحول العقود الذكية المكتوبة بلغة Solidity إلى البايت كود وبيانات الواجهة اللازمة لتشغيلها على شبكات البلوكشين الداعمة لـ EVM.

لماذا تُعد solc مهمة في الكريبتو؟

تُعد solc مهمة لأن العقود الذكية غالبًا ما تدير التوكنات وأنظمة التخزين وأسواق الإقراض والجسور ومنطق الحوكمة ومجموعات NFT وضوابط الخزانة وبروتوكولات DeFi.

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

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

وهذا يعني أن البايت كود المترجم هو منطق البرنامج الفعلي الذي تنفذه الشبكة.

قد يقرأ المستخدمون ملف Solidity واضحًا على موقع إلكتروني، لكن البلوكشين لا يفرض سوى البايت كود المنشور.

إذا لم يتطابق كود المصدر مع البايت كود المترجم، فلا يمكن للمستخدمين افتراض أن المصدر المنشور يمثل العقد النشط بأمان.

توضح وثائق التحقق من عقود Ethereum أن التحقق من العقد يقارن كود المصدر بالبايت كود المترجم للتأكد من تطابقهما.

كما تهم solc لأن إصدارات المترجم قد تقدم ميزات لغوية وتحذيرات وإصلاحات أخطاء وتحسينات للمُحسّن وتغييرات في هدف EVM وتغيرات سلوكية جديدة.

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

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

كيف تعمل solc؟

تأخذ solc كود مصدر Solidity كمدخلات وتعالجه عبر عدة مراحل للترجمة البرمجية.

يحلل المترجم الكود أولًا ويتحقق من صحة الصياغة.

ثم يحلل الكود للتحقق من صحة الأنواع وعلاقات الوراثة ورؤية الدوال وتخطيط التخزين وعمليات الاستيراد وقواعد اللغة الأخرى.

إذا احتوى الكود على أخطاء، تتوقف solc وتبلغ عن تلك الأخطاء.

وإذا احتوى على مشكلات قد تنطوي على مخاطر لكنها غير قاتلة، يمكن لـ solc الإبلاغ عن تحذيرات.

بعد التحليل، يمكن لـ solc إنشاء تمثيلات وسيطة تساعد في التحسين وتوليد الكود.

ثم ينتج المترجم بايت كود النشر وبايت كود وقت التشغيل وبيانات ABI والبيانات الوصفية والمخرجات الأخرى المطلوبة.

يُستخدم بايت كود النشر عند إنشاء العقد على السلسلة.

أما بايت كود وقت التشغيل فهو الكود الذي يبقى في عنوان العقد بعد النشر.

تصف ABI كيفية استدعاء المستخدمين الخارجيين والمحافظ والبرامج النصية والعقود الأخرى لدوال العقد وفك ترميز البيانات المُعادة.

كود مصدر Solidity

كود مصدر Solidity هو الكود المقروء بشريًا الذي يكتبه المطورون قبل الترجمة البرمجية.

تستخدم ملفات Solidity عادة امتداد الملف .sol.

يمكن أن يتضمن ملف المصدر تعليمة pragma وعمليات استيراد وتعريفات العقود والواجهات والمكتبات والبُنى والتعدادات والأحداث والأخطاء والدوال والمعدلات والتعليقات.

يقرأ المترجم هذه الملفات ويطبق قواعد إصدار لغة Solidity المحدد.

تحدد تعليمة pragma عادةً إصدارات المترجم المسموح بها للملف.

على سبيل المثال، قد تسمح pragma فقط بإصدارات المترجم ضمن نطاق محدد من 0.8.x.

وهذا مهم لأن سلوك لغة Solidity قد يتغير بين الإصدارات.

قد لا يترجم ملف مصدر جرى تجميعه بأمان بإصدار ما بالطريقة نفسها باستخدام إصدار آخر.

ينبغي للمطورين اختيار إصدارات المترجم عمدًا، بدل الاعتماد على أي إصدار مثبت حاليًا.

في مشاريع الكريبتو الإنتاجية، ينبغي تثبيت كود المصدر وإصدارات التبعيات وإصدار المترجم وإعداداته وجعلها قابلة لإعادة الإنتاج.

البايت كود

البايت كود هو كود منخفض المستوى قابل لقراءة الآلة ويعمل على آلة Ethereum الافتراضية.

تُنشئ solc البايت كود من كود مصدر Solidity.

يُستخدم بايت كود النشر لإنشاء عقد، وقد يتضمن منطق المنشئ ووسيطات المنشئ المرمزة.

بايت كود وقت التشغيل هو الكود المخزن في عنوان العقد بعد إنشائه.

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

لهذا السبب، يفيد كود المصدر المتحقق منه في تعزيز الشفافية.

لكن EVM تنفذ البايت كود، وليس نص Solidity الأصلي.

وهذا التفريق مهم لأن ملفي مصدر يبدوان متشابهين قد يُترجمان إلى بايت كود مختلف إذا اختلفت إعدادات المترجم.

وهو مهم أيضًا لأن إعدادات المُحسّن قد تغير بنية البايت كود بشكل ملحوظ.

عند مراجعة العقود الذكية الجادة، ينبغي للمطورين والمدققين فهم أن البايت كود المنشور هو المصدر النهائي للحقيقة.

ABI

يرمز ABI إلى Application Binary Interface.

توضح مواصفة Solidity ABI الرسمية أن ABI الخاصة بالعقد هي الطريقة القياسية للتفاعل مع العقود في منظومة Ethereum من خارج البلوكشين ومن استدعاءات عقد إلى عقد.

تحدد ABI للأدوات كيفية ترميز استدعاءات الدوال وفك ترميز القيم المُعادة.

وتتضمن أسماء الدوال وأنواع المدخلات وأنواع المخرجات والأحداث والأخطاء وتفاصيل الواجهة الأخرى.

تستخدم المحفظة أو البرنامج النصي ABI لمعرفة كيفية استدعاء دالة العقد الذكي بصورة صحيحة.

على سبيل المثال، إذا احتوى عقد توكن على دالة transfer، فإن ABI توضح للبرنامج كيفية ترميز عنوان المستلم والمبلغ.

من دون ABI، يمكن للمستخدمين إرسال calldata خام، لكن ذلك سيكون أصعب بكثير وأكثر عرضة للأخطاء.

لا تُعد ABI هي نفسها كود مصدر العقد.

كما أنها ليست البايت كود.

إنها وصف للواجهة يساعد البشر والبرامج على التفاعل مع العقود الذكية المترجمة.

البيانات الوصفية للمترجم

يمكن لـ solc تضمين بيانات وصفية تصف كيفية ترجمة العقد برمجيًا.

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

قد تتضمن البيانات الوصفية معلومات ملف المصدر وإصدار المترجم والإعدادات وتكوين المُحسّن وABI وتفاصيل الترجمة الأخرى.

تساعد هذه المعلومات مستكشفات البلوكشين وأدوات التحقق على إعادة إنشاء مخرجات الترجمة.

وتهم البيانات الوصفية أيضًا لأن الفروق الصغيرة في إعدادات المترجم قد تغير البايت كود.

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

كما قد تكشف البيانات الوصفية معلومات مفيدة للباحثين والمدققين.

لكن البيانات الوصفية وحدها لا تثبت أن العقد آمن.

إنها تساعد أساسًا في إثبات ما إذا كان المصدر والإعدادات المنشورة تتطابق مع البايت كود المنشور.

ينبغي للمستخدمين التعامل مع البيانات الوصفية المتحقق منها باعتبارها إشارة للشفافية، لا ضمانًا للأمان.

إدخال وإخراج Standard JSON

واجهة Standard JSON هي الطريقة المنظمة الموصى بها لاستخدام solc في أنظمة البناء الآلية.

توضح وثائق مترجم Solidity أن solc يمكنها قبول إدخال Standard JSON عبر الإدخال القياسي وإرجاع مخرجات JSON عبر الإخراج القياسي.

يمكن لإدخال Standard JSON تحديد ملفات المصدر وإعدادات المترجم وإعدادات المُحسّن وإصدار EVM والمكتبات وعمليات إعادة التعيين والمخرجات المطلوبة.

وقد يتضمن إخراج Standard JSON الأخطاء والتحذيرات وABIs والبايت كود وبايت كود المنشور والبيانات الوصفية وتقديرات الغاز وتخطيط التخزين والنتائج المطلوبة الأخرى.

هذا التنسيق مفيد لأن مشاريع العقود الذكية الحديثة غالبًا ما تضم ملفات وتبعيات كثيرة.

كما يجعل الترجمة البرمجية أكثر قابلية لإعادة الإنتاج، إذ يمكن تسجيل الإعدادات في كائن منظم واحد.

غالبًا ما تعتمد أدوات البناء وخدمات التحقق على Standard JSON أو بيانات مماثلة لتكوين المترجم.

ينبغي للمطورين الاحتفاظ بمدخلات المترجم النهائية المستخدمة في النشر كلما أمكن.

يساعد ذلك في عمليات التدقيق المستقبلية والتحقيقات في الحوادث والتحقق من كود المصدر.

بالنسبة إلى العقود الذكية الإنتاجية، تُعد الترجمة القابلة لإعادة الإنتاج ممارسة مثلى للأمان والشفافية.

إصدارات المترجم

تكتسب إصدارات مترجم Solidity أهمية لأن قواعد اللغة وسلوك المترجم قد يتغيران بمرور الوقت.

تنشر صفحة إصدارات Solidity إعلانات عن إصدارات المترجم تصف الميزات الجديدة وإصلاحات الأخطاء وتغييرات التوافق وتحديثات هدف EVM.

وفقًا لمعلومات الإصدارات لعام 2026 على موقع Solidity الرسمي، يُعد Solidity Compiler v0.8.35 إصدارًا حديثًا يضيف وظائف جديدة للمترجم ويستعرض تغييرات مستقبلية.

قد لا يترجم عقد مكتوب لإصدار مترجم معين باستخدام إصدار آخر من دون تعديلات.

وحتى إذا تمت ترجمته، فقد يختلف البايت كود الناتج.

لهذا السبب، تثبت معظم مشاريع Solidity إصدار المترجم في تكوين البناء.

يمكن لتعليمة pragma التعبير عن نطاق إصدار متوافق، لكن عمليات البناء الإنتاجية غالبًا ما تثبت إصدار المترجم الدقيق بشكل منفصل.

قد يوفر استخدام مترجم أحدث إصلاحات للأخطاء وتحذيرات محسنة.

لكن استخدام مترجم أحدث دون مراجعة قد يقدم تغييرات تتطلب الاختبار.

ينبغي للمطورين قراءة ملاحظات الإصدار قبل ترقية solc للعقود الإنتاجية.

Pragma Solidity

تحدد تعليمة pragma إصدارات Solidity المقصودة لملف المصدر.

ولا تمثل pragma المترجم نفسه.

بل هي تعليمة في كود المصدر تساعد الأدوات على رفض إصدارات المترجم غير المتوافقة.

على سبيل المثال، قد يستخدم مشروع pragma تسمح بنطاق من إصدارات Solidity 0.8.x.

قد يكون ذلك ملائمًا للمكتبات، لكنه ينطوي على مخاطر في عمليات النشر إذا لم يُثبت الإصدار الدقيق في موضع آخر.

قد تسمح pragma واسعة لمطورين مختلفين بترجمة الكود نفسه باستخدام إصدارات تصحيح مختلفة.

وقد يجعل ذلك التحقق من البايت كود أصعب إذا لم يُسجل إصدار النشر النهائي.

بالنسبة إلى عقود التطبيقات، تجمع الفرق غالبًا بين pragma معقولة وإصدار مترجم دقيق في أداة البناء.

يخلق ذلك توافقًا لملفات المصدر مع الحفاظ على قابلية إعادة إنتاج عمليات بناء النشر.

ينبغي للمستخدمين الذين يراجعون العقود المتحقق منها فحص pragma وإصدار المترجم الفعلي المستخدم في التحقق معًا.

المُحسّن

مُحسّن Solidity هو ميزة في المترجم تحاول جعل الكود المُنشأ أكثر كفاءة.

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

قد يقلل التحسين غاز النشر أو غاز وقت التشغيل أو كليهما وفقًا للإعدادات وسلوك العقد.

ويمكن للمُحسّن أيضًا تغيير بنية البايت كود بشكل ملحوظ.

وهذا مهم لأن العقد المترجم مع تفعيل المُحسّن لن يتطابق مع العقد نفسه المترجم مع تعطيل المُحسّن.

عدد عمليات تشغيل المُحسّن هو إعداد يخبر المترجم بمدى أولوية كفاءة وقت التشغيل مقارنة بتكلفة النشر.

قد تفضّل قيمة تشغيل منخفضة تكلفة نشر أقل للكود الذي يُستدعى نادرًا.

وقد تفضّل قيمة تشغيل مرتفعة تكلفة وقت تشغيل أقل للكود الذي يُستدعى مرات كثيرة.

ينبغي للمطورين اختبار سلوك الغاز ضمن أنماط استخدام واقعية قبل اختيار الإعدادات.

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

via-IR

via-IR هي مسار للترجمة البرمجية في Solidity يمرر الترجمة عبر التمثيل الوسيط للمترجم.

يمكن للتمثيل الوسيط أن يساعد المترجم على تنفيذ بعض التحسينات والتحويلات قبل إنشاء بايت كود EVM.

قد يؤدي استخدام via-IR إلى بايت كود مختلف عن المسار القديم.

يعني ذلك ضرورة اختبار العقود اختبارًا شاملًا إذا تغير البناء بين ترجمة دون via-IR وترجمة عبر via-IR.

تستخدم بعض المشاريع via-IR لتحسين نتائج التحسين أو دعم احتياجات ترجمة معقدة.

لكن تغيير مسارات الترجمة قرب موعد النشر قد ينطوي على مخاطر إذا لم يختبر المشروع جميع المسارات.

ينبغي للمطورين الحفاظ على اتساق إعدادات via-IR بين التطوير المحلي والاختبار والتدقيق والنشر والتحقق.

ينبغي للمدققين معرفة ما إذا كانت via-IR مفعلة، لأنها قد تغير البايت كود وأحيانًا سلوك الغاز.

بالنسبة للمستخدمين، تكون via-IR غير مرئية في الغالب، لكنها مهمة للبناء القابل لإعادة الإنتاج والتحقق.

الممارسة الأكثر أمانًا هي التعامل مع مسار المترجم بوصفه جزءًا من تكوين العقد الإنتاجي.

إصدار EVM

يحدد إعداد إصدار EVM قواعد وميزات آلة Ethereum الافتراضية التي تستهدفها solc.

قد تغير ملاحظات إصدار Solidity إصدار EVM الافتراضي عندما تقدم ترقيات شبكة Ethereum أكواد تشغيل أو سلوكًا جديدًا.

توضح ملاحظات إصدار Solidity 0.8.30 أن إصدار EVM الافتراضي تغير من Cancun إلى Prague لترقية شبكة Ethereum Pectra.

وهذا مهم لأن البايت كود الذي يستهدف إصدار EVM أحدث قد يستخدم تعليمات لا تدعمها الشبكات الأقدم.

إذا نشر مطور عقدًا على سلسلة لا تدعم إصدار EVM المحدد، فقد يفشل العقد أو يتصرف على نحو غير متوقع.

ينبغي للمطورين الذين يبنون لشبكات متعددة متوافقة مع EVM التحقق من ميزات EVM التي تدعمها كل شبكة.

ينبغي تسجيل إصدار EVM مع إصدار المترجم وإعدادات المُحسّن.

قد يفشل تطابق عقد متحقق منه إذا استُخدم إصدار EVM خاطئ أثناء التحقق.

بالنسبة إلى مستخدمي الكريبتو، إصدار EVM جزء خفي لكنه مهم من أمان نشر العقد.

وبالنسبة إلى المطورين، فهو إعداد لا ينبغي تخمينه مطلقًا.

عمليات الاستيراد وعمليات إعادة التعيين

تستخدم مشاريع Solidity غالبًا عمليات الاستيراد لإعادة استخدام الواجهات والمكتبات ووحدات العقود المشتركة.

يجب أن تحل solc عمليات الاستيراد تلك قبل أن تتمكن من ترجمة العقد بالكامل.

تحدد عمليات إعادة التعيين للمترجم كيفية تعيين مسارات الاستيراد إلى أدلة محلية أو أدلة التبعيات.

وهذا شائع في المشاريع التي تستخدم مديري الحزم أو أطر العقود الذكية.

يهم حل الاستيراد لأن الترجمة باستخدام إصدار تبعية خاطئ يمكن أن تنتج بايت كود مختلفًا أو سلوكًا غير آمن.

قد يبدو المشروع صحيحًا في ملف العقد الرئيسي، بينما يعتمد سرًا على مكتبة مستوردة مختلفة عما هو متوقع.

ينبغي للمطورين تثبيت إصدارات التبعيات ومراجعة الكود المستورد بعناية.

ينبغي للمدققين فحص شجرة التبعيات الكاملة، وليس ملف المصدر الرئيسي فقط.

ينبغي للمستخدمين الذين يراجعون العقود المتحقق منها تذكر أن الملفات المستوردة جزء من كود المصدر الذي يجري التحقق منه.

لا يجعل ملف رئيسي واضح العقد آمنًا إذا كانت تبعية مستوردة ضارة أو قديمة.

المكتبات والربط

يمكن ترجمة مكتبات Solidity وربطها بعمليات نشر العقود.

تُضمّن بعض المكتبات مباشرة في البايت كود، بينما قد تتطلب المكتبات الخارجية الربط عبر العنوان.

تحذر وثائق مترجم Solidity من أن الربط اليدوي بعد الترجمة قد يؤثر في البيانات الوصفية وتطابق البايت كود.

وهذا مهم لأن التحقق قد يفشل إذا لم تُسجل عناوين المكتبات بدقة.

كما يهم لأن استخدام عنوان مكتبة خاطئ يمكن أن يجعل العقد المنشور يستدعي كودًا غير متوقع.

ينبغي أن تتولى أدوات البناء والنشر الموثوقة ربط المكتبات.

ينبغي للمطورين تسجيل عناوين المكتبات المستخدمة وقت النشر.

ينبغي للمدققين التحقق من أن المكتبات المرتبطة تطابق كود المصدر الذي جرت مراجعته.

ينبغي للمستخدمين فحص ما إذا كان العقد المتحقق منه يعتمد على مكتبات خارجية.

قد يعتمد أمان العقد على البايت كود الخاص به وعلى البايت كود للمكتبات المرتبطة.

التحقق من كود المصدر

التحقق من كود المصدر هو عملية إثبات أن كود المصدر المنشور يُترجم إلى البايت كود المنشور على السلسلة.

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

للتحقق من عقد، يحتاج المُتحقق عادة إلى ملفات المصدر الدقيقة وإصدار المترجم وإعدادات المُحسّن ووسيطات المنشئ وعناوين المكتبات وإصدار EVM والإعدادات المتعلقة بالبيانات الوصفية.

إذا اختلف أي من هذه المدخلات، فقد لا يتطابق البايت كود المترجم مع البايت كود المنشور.

يساعد كود المصدر المتحقق منه المستخدمين على قراءة ما يفترض أن يفعله العقد.

كما يساعد المحافظ والمستكشفات والمدققين والباحثين على فك ترميز المعاملات والأحداث.

لكن كود المصدر المتحقق منه لا يعني أن العقد آمن أو خضع للتدقيق.

إنه يعني فقط أن المصدر والإعدادات المنشورة يبدوان متطابقين مع البايت كود المنشور.

ينبغي للمستخدمين اعتبار التحقق خطوة أساسية للشفافية.

ولا تزال المراجعة الأمنية تتطلب فهم الكود والتصميم والصلاحيات وقابلية الترقية والمخاطر الاقتصادية.

أخطاء المترجم

المترجمات برامج، وقد تحتوي البرامج على أخطاء.

تتتبع وثائق أخطاء Solidity المعروفة أخطاء المترجم المعروفة والإصدارات المتأثرة بها.

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

تكون أخطاء المترجم نادرة عادةً مقارنة بأخطاء العقود الذكية على مستوى التطبيق، لكن تأثيرها قد يكون خطيرًا.

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

ينبغي للفرق أيضًا استخدام إصدارات مستقرة حديثة من المترجم عندما يكون ذلك عمليًا وبعد اختبار مناسب.

ينبغي للمدققين تضمين مراجعة إصدار المترجم في عملية التدقيق.

قد تحذر أدوات التحقق أيضًا عندما يُترجم عقد بإصدار متأثر بمشكلات معروفة.

قد يزيد استخدام إصدار مترجم قديم بلا سبب من المخاطر.

تتعامل عملية التطوير الآمنة مع المترجم بوصفه جزءًا من قاعدة الكود الموثوقة.

التحذيرات والأخطاء

تبلغ solc عن الأخطاء عندما يتعذر ترجمة الكود بأمان وفقًا لقواعد اللغة.

وتبلغ solc عن التحذيرات عندما يمكن ترجمة الكود لكنه قد يتضمن سلوكًا محفوفًا بالمخاطر أو مهملًا أو مربكًا أو غير مقصود.

ينبغي للمطورين عدم تجاهل تحذيرات المترجم في المشاريع الإنتاجية.

قد يكشف التحذير عن متغيرات غير مستخدمة أو تعريفات محجوبة أو معرفات SPDX مفقودة أو اقتراحات تتعلق بقابلية التغيير أو ميزات مهملة أو أنماط خطيرة.

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

ينبغي لأنظمة البناء الإنتاجية التعامل مع التحذيرات الخطيرة على أنها مشكلات تحتاج إلى مراجعة.

غالبًا ما يفحص المدققون تحذيرات المترجم لأنها قد تكشف افتراضات أغفلها المطور.

لا يستطيع المستخدمون عادة رؤية كل تحذير لعقد منشور ما لم تُنشر مخرجات البناء.

وهذا أحد أسباب وجوب نشر المشاريع مفتوحة المصدر لملفات البناء الناتجة عندما يكون ذلك ممكنًا.

لا تثبت الترجمة النظيفة الأمان، لكن التحذيرات المتجاهلة إشارة سيئة.

تقديرات الغاز

يمكن لـ solc إنتاج تقديرات للغاز لبعض الدوال ومخرجات النشر.

تتضمن وثائق مترجم Solidity تقديرات الغاز ضمن مخرجات المترجم المحتملة.

قد تساعد تقديرات الغاز المطورين على فهم تكلفة نشر العقد أو استدعائه.

لكن قد لا تعكس التقديرات بالكامل ظروف الشبكة الفعلية أو جميع مسارات وقت التشغيل.

قد يعتمد الاستخدام الفعلي للغاز على قيم التخزين وحجم المدخلات ومسارات التفرع والاستدعاءات الخارجية والوصول إلى الحسابات الباردة والدافئة وقواعد الشبكة.

ينبغي للمطورين اختبار سلوك الغاز بحالات اختبار واقعية وعدم الاعتماد على تقديرات المترجم فقط.

يهم الغاز في الكريبتو لأن الدوال المكلفة قد تضر بتجربة المستخدم أو تجعل إجراءات البروتوكول المهمة غير عملية أثناء الازدحام.

وقد يزيد الكود كثيف الاستهلاك للغاز تكلفة النشر والضغط الناتج عن حجم العقد.

قد يقلل المُحسّن الغاز في بعض الحالات، لكنه قد يغير أيضًا المفاضلات بين تكاليف النشر ووقت التشغيل.

ينبغي أن تكون مراجعة الغاز جزءًا من التحليل الهندسي والأمني معًا.

تخطيط التخزين

يصف تخطيط التخزين كيفية ترتيب متغيرات الحالة في فتحات تخزين العقد.

يمكن لـ solc إخراج معلومات تخطيط التخزين للعقود.

وهذا مهم بصفة خاصة للعقود الذكية القابلة للترقية.

إذا رقّى مشروع منطق التنفيذ لكنه غيّر تخطيط التخزين بصورة غير صحيحة، فقد يفسد العقد حالته.

قد يؤدي تلف التخزين إلى تعطيل الأرصدة أو الملكية أو إعدادات الحوكمة أو محاسبة التوكنات أو ضوابط الوصول.

ينبغي للمطورين الحفاظ على توافق تخطيط التخزين عند استخدام أنماط الترقية القائمة على Proxy.

ينبغي للمدققين مراجعة مخرجات تخطيط التخزين وخطط الترقية معًا.

ينبغي للمستخدمين توخي الحذر مع العقود القابلة للترقية، لأن Proxy المنشور قد يشير لاحقًا إلى بايت كود تنفيذ جديد.

لا تمنع solc بمفردها كل تصميم ترقية سيئ.

إنها توفر مخرجات يمكن للمطورين الحذرين استخدامها لتقليل مخاطر الترقية.

حجم العقد

يمكن لمخرجات solc مساعدة المطورين على مراقبة حجم بايت كود العقد.

تفرض شبكات EVM غالبًا حدًا أقصى لحجم بايت كود وقت التشغيل المنشور للعقد.

قد تفشل العقود الكبيرة في النشر إذا تجاوزت حدود الحجم.

يمكن للمُحسّن أحيانًا تقليل حجم البايت كود عبر إزالة التكرار وتبسيط الكود.

وقد يقسم المطورون أيضًا الأنظمة الكبيرة إلى عقود أو مكتبات أو وحدات متعددة.

يهم حجم العقد لأن العقود شديدة التعقيد قد يصعب تدقيقها وتكون تكلفة نشرها أعلى.

العقد الأصغر ليس بالضرورة أكثر أمانًا، لكن التعقيد غير الضروري يزيد صعوبة المراجعة.

تساعد solc في كشف حجم الكود قبل النشر.

ينبغي لأنظمة البناء أن تفشل مبكرًا إذا كان حجم البايت كود كبيرًا جدًا للشبكة المستهدفة.

تُعد مراقبة حجم البايت كود جزءًا من هندسة العقود الذكية الاحترافية.

solc في أطر التطوير

لا يشغّل كثير من مطوري العقود الذكية solc يدويًا في كل عملية بناء.

بل يستخدمون أطرًا تستدعي solc في الخلفية.

يمكن لهذه الأدوات إدارة هيكل المشروع والتبعيات والترجمة والاختبار والنشر والتحقق.

حتى عندما يخفي إطار العمل أوامر المترجم المباشرة، تظل إعدادات solc مهمة.

يجب أن يختار إطار العمل إصدار المترجم وإعدادات المُحسّن وإصدار EVM ومسارات الاستيراد وخيارات المخرجات.

قد ينشر مطور لا يفهم هذه الإعدادات عن غير قصد بايت كود مختلفًا عن البناء الذي خضع للتدقيق.

ينبغي للفرق إضافة ملفات تكوين المترجم إلى نظام التحكم في الإصدارات.

كما ينبغي أن تجعل عمليات النشر قابلة لإعادة الإنتاج من بيئات نظيفة.

ينبغي للمدققين مراجعة إعدادات مترجم إطار العمل باعتبارها جزءًا من قاعدة الكود.

قد تكون solc مخفية في سير العمل، لكنها تظل الأداة التي تنتج البايت كود النهائي.

solc-js

Solc-js هو إصدار JavaScript أو غلاف لمترجم Solidity يُستخدم في كثير من عمليات سير العمل على الويب وNode.js.

تصف وثائق تثبيت Solidity الرسمية طرقًا مختلفة لتثبيت مترجم سطر الأوامر وحزم المترجم.

تُعد Solc-js مفيدة للأدوات المستندة إلى المتصفح وأنظمة البناء بـ JavaScript والمترجمات عبر الإنترنت وعمليات التحقق الآلية من العقود.

ينبغي للمطورين رغم ذلك التحقق من إصدار المترجم الذي تستخدمه solc-js.

لا يلغي استخدام حزمة JavaScript الحاجة إلى تثبيت الإصدارات والإعدادات.

قد تحل بيئات مختلفة عن غير قصد نسخ مترجم مختلفة إذا كانت إصدارات التبعيات غير مقيدة.

وقد يكسر ذلك قابلية إعادة الإنتاج والتحقق.

بالنسبة إلى العقود الإنتاجية، ينبغي معرفة إصدار المترجم الدقيق وتسجيله.

تتميز Solc-js بالسهولة، لكن السهولة لا تغني عن عمليات البناء الحتمية.

ينبغي أن يتطابق ملف المترجم الناتج مع ملف النشر الناتج تمامًا.

الدور الأمني لـ solc

لا تُعد solc مدققًا أمنيًا، لكنها تؤدي دورًا مهمًا في أمان العقود الذكية.

يفرض المترجم قواعد اللغة ويبلغ عن التحذيرات وينشئ البايت كود ويمكنه إخراج معلومات مفيدة للتحليل.

يمكنه كشف أخطاء الصياغة وأخطاء الأنواع وتحذيرات الكود غير القابل للوصول وبعض الأنماط الخطيرة.

لكن solc لا تستطيع إثبات أن التصميم الاقتصادي لبروتوكول ما آمن.

ولا تستطيع ضمان صحة ضوابط الوصول.

ولا تستطيع ضمان موثوقية حوكمة الترقية.

كما لا تستطيع ضمان أمان تصميم Oracle أو منطق التصفية أو اقتصاديات التوكن.

لا يزال الأمان يتطلب الاختبار والتدقيق والأساليب الرسمية عند الاقتضاء ونمذجة التهديدات والمراقبة وإجراءات النشر الحذرة.

توضح الأعمال الأكاديمية مثل ورقة التحليل الساكن لـ Slither كيف يمكن للأدوات الإضافية تحليل العقود الذكية بما يتجاوز الترجمة الأساسية.

تمثل solc أساس عملية البناء، لكنها ينبغي أن تكون جزءًا من سير عمل أمني أوسع.

مخرجات solc الشائعة

أكثر مخرجات solc شيوعًا هي البايت كود للعقد.

ومن المخرجات الشائعة الأخرى ABI.

كما تُنشأ البيانات الوصفية عادةً للتحقق والأدوات.

قد تساعد تقديرات الغاز المطورين على فهم تكاليف التنفيذ التقريبية.

قد يساعد تخطيط التخزين المطورين في إدارة العقود القابلة للترقية.

قد تساعد أشجار البنية النحوية المجردة أدوات التحليل على فهم بنية كود المصدر.

قد تساعد مخرجات التمثيل الوسيط المطورين المتقدمين على فحص تحويلات المترجم.

قد تساعد مخرجات Assembly في التحسين العميق وتصحيح الأخطاء.

تساعد مخرجات الأخطاء والتحذيرات المطورين على إصلاح الكود قبل النشر.

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

الأخطاء الشائعة عند استخدام solc

من الأخطاء الشائعة الترجمة باستخدام إصدار مترجم مختلف عن الإصدار المستخدم أثناء عمليات التدقيق.

وخطأ آخر هو تغيير إعدادات المُحسّن بعد اكتمال الاختبار.

والخطأ الثالث هو نشر البايت كود دون تسجيل مدخلات المترجم الدقيقة.

والخطأ الرابع هو استخدام pragma واسعة وافتراض أن كل إصدار مترجم متوافق ينتج مخرجات متطابقة.

والخطأ الخامس هو تجاهل تحذيرات المترجم.

والخطأ السادس هو استهداف إصدار EVM خاطئ لشبكة النشر.

والخطأ السابع هو ربط المكتبات يدويًا وإفساد التحقق القائم على البيانات الوصفية.

والخطأ الثامن هو عدم تضمين كل الملفات المستوردة أثناء التحقق.

والخطأ التاسع هو افتراض أن كود المصدر المتحقق منه يعني كود مصدر خضع للتدقيق.

والخطأ العاشر هو ترقية المترجم قبل النشر مباشرة دون اختبار كامل.

كيف يقرأ المستخدمون معلومات solc في المستكشفات

يمكن للمستخدمين غالبًا العثور على معلومات المترجم في صفحات العقود المتحقق منها ضمن مستكشفات البلوكشين.

قد تتضمن هذه المعلومات إصدار المترجم وحالة التحسين وعدد عمليات تشغيل المُحسّن وإصدار EVM ومعرف الترخيص ووسيطات المنشئ وملفات المصدر المتحقق منها.

ينبغي للمستخدمين التحقق مما إذا كان العقد متحققًا منه قبل الثقة بعرض كود المصدر.

إذا كان العقد غير متحقق منه، فقد لا يرى المستخدمون سوى البايت كود ومعلومات مفكوكة الترميز محدودة.

أما إذا كان العقد متحققًا منه، فيمكن للمستخدمين فحص كود المصدر وABI بسهولة أكبر.

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

تساعد معلومات المترجم على الإجابة عما إذا كان الكود المرئي يطابق البايت كود المنشور.

ولا تجيب عما إذا كان استخدام الكود آمنًا.

في التفاعلات عالية القيمة، ينبغي للمستخدمين أيضًا مراجعة عمليات التدقيق والصلاحيات والأقفال الزمنية وضوابط الترقية ووثائق المشروع.

بيانات solc جزء واحد من العناية الواجبة للعقد.

أفضل الممارسات للمطورين

ثبّت إصدار solc الدقيق المستخدم في عمليات البناء الإنتاجية.

أضف إعدادات المترجم إلى نظام التحكم في الإصدارات.

استخدم بيئات بناء قابلة لإعادة الإنتاج للاختبار والتدقيق والنشر والتحقق.

راجع ملاحظات إصدار Solidity قبل تغيير إصدارات المترجم.

تحقق من أخطاء المترجم المعروفة للإصدار المحدد.

حافظ على اتساق إعدادات المُحسّن بعد بدء التدقيق.

عيّن إصدار EVM الصحيح للشبكة المستهدفة.

احتفظ بملفات إدخال وإخراج Standard JSON للعقود المنشورة.

تحقق من العقود بعد النشر باستخدام المصدر والإعدادات الدقيقة.

تعامل مع تحذيرات المترجم باعتبارها عناصر للمراجعة، لا ضوضاء غير ضارة.

أفضل الممارسات للمستخدمين

تحقق مما إذا كان كود مصدر العقد متحققًا منه قبل التفاعل معه.

راجع إصدار المترجم وإعداداته عند توفرها.

تذكر أن كود المصدر المتحقق منه لا يساوي كود مصدر خضع للتدقيق.

توخ الحذر مع العقود غير المتحقق منها التي تطلب موافقات للتوكنات أو إيداعات للأصول.

تحقق مما إذا كان العقد يستخدم Proxies قابلة للترقية أو مكتبات مرتبطة.

راجع ما إذا كانت ABI تطابق الدوال التي تطلب منك الواجهة استدعاءها.

توخ الحذر عندما يطلب منك موقع إلكتروني توقيع معاملات لعقد لا يمكنك فحصه.

استخدم محافظ موثوقة تعرض استدعاءات العقود وبيانات الدوال المفكوكة الترميز عندما يكون ذلك ممكنًا.

بالنسبة إلى المعاملات الكبيرة، قارن وثائق المشروع الرسمية بعنوان العقد المتحقق منه.

لا تعامل البيانات الوصفية للمترجم باعتبارها ضمانًا للأمان أو للقيمة المستقبلية.

الأسئلة الشائعة

ماذا تعني solc؟

تعني solc مترجم Solidity، وهو المترجم الذي يحول كود مصدر Solidity إلى بايت كود EVM وبيانات ABI والبيانات الوصفية ومخرجات بناء العقود الذكية الأخرى.

هل solc هي نفسها Solidity؟

لا، Solidity هي لغة البرمجة، بينما solc هو المترجم الذي يعالج كود Solidity.

ماذا تنتج solc؟

يمكن لـ solc إنتاج البايت كود والبايت كود المنشور وبيانات ABI والبيانات الوصفية وتقديرات الغاز وتخطيط التخزين وأشجار البنية النحوية المجردة وAssembly والتمثيل الوسيط والأخطاء والتحذيرات.

لماذا يهم إصدار solc؟

يهم إصدار solc لأن إصدارات المترجم المختلفة قد تدعم ميزات لغوية وتحذيرات وإصلاحات أخطاء وإعدادات EVM افتراضية ومخرجات بايت كود مختلفة.

ما هو البايت كود في ترجمة Solidity؟

البايت كود هو الكود منخفض المستوى الذي تُنشئه solc ويمكن لآلة Ethereum الافتراضية تنفيذه.

ما هي ABI في ترجمة Solidity؟

ABI هي وصف الواجهة الذي يوضح للمحافظ والبرامج النصية والتطبيقات كيفية ترميز الاستدعاءات وفك ترميز الاستجابات لعقد ذكي.

هل تجعل solc العقود الذكية آمنة؟

لا، تفرض solc قواعد اللغة وتنشئ البايت كود، لكن أمان العقود الذكية لا يزال يتطلب الاختبار والتدقيق ونمذجة التهديدات والتصميم الحذر.

ما هو المُحسّن في solc؟

المُحسّن ميزة في المترجم تحاول تقليل حجم الكود أو تكلفة النشر أو تكلفة غاز وقت التشغيل وفقًا للإعدادات وأنماط الاستخدام.

ما هو Standard JSON في solc؟

Standard JSON هو تنسيق منظم لإدخال وإخراج المترجم، يُستخدم للترجمة الآلية الموثوقة وملفات البناء الناتجة والتحقق من العقود.

لماذا يحتاج التحقق من العقد إلى إعدادات solc؟

يحتاج التحقق من العقد إلى إعدادات solc لأن كود المصدر يجب أن يُترجم بالإصدار نفسه وإعدادات المُحسّن والمكتبات وإصدار EVM وإعدادات البيانات الوصفية نفسها لكي يطابق البايت كود المنشور.

الخلاصة

يُعد مترجم Solidity، أو solc، أحد أهم الأدوات في تطوير العقود الذكية على Ethereum.

فهو يحول كود مصدر Solidity إلى بايت كود EVM وبيانات ABI والبيانات الوصفية وتخطيط التخزين وتقديرات الغاز والمخرجات الأخرى التي يعتمد عليها المطورون والمدققون والمحافظ والمستكشفات.

تُعد إعدادات solc حاسمة، لأن إصدار المترجم وخيارات المُحسّن وإصدار EVM وربط المكتبات وعمليات الاستيراد والبيانات الوصفية وخيارات مسار الترجمة يمكن أن تؤثر جميعها في البايت كود النهائي المنشور.

بالنسبة إلى المطورين، ينبغي التعامل مع solc بوصفها جزءًا من نطاق الأمان الإنتاجي، لا أداة بناء تعمل في الخلفية.

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

لكن الترجمة والتحقق لا يضمنان أن العقد آمن أو عادل أو خضع للتدقيق أو سليم اقتصاديًا.

قد يظل العقد المتحقق منه يحتوي على أخطاء أو ضوابط مسؤول محفوفة بالمخاطر أو مسارات ترقية أو اقتصاديات توكن سيئة أو منطق ضار.

تجمع الممارسة الجيدة للعقود الذكية بين الترجمة الصحيحة والاختبار والتدقيق وعمليات البناء القابلة لإعادة الإنتاج والنشر الآمن والمراقبة والتحقق الشفاف.

بالنسبة إلى المبتدئين، من الأفضل فهم solc باعتبارها الأداة التي تحول Solidity إلى كود قابل للتنفيذ على البلوكشين.

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

في سياق مسرد الكريبتو، يعني Solidity Compiler (solc) أداة الترجمة الرسمية لـ Solidity المستخدمة لتحويل كود مصدر العقود الذكية إلى مخرجات EVM قابلة للنشر والتحقق.

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