Solidity

ما هي Solidity؟

Solidity هي لغة برمجة عالية المستوى تُستخدم لكتابة العقود الذكية التي تعمل على Ethereum وشبكات البلوكشين الأخرى الداعمة لآلة Ethereum الافتراضية.

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

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

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

في الكريبتو، تُستخدم Solidity لبناء التوكنات وبروتوكولات DeFi ومجموعات NFT ومنظمات DAO وأنظمة التخزين وأسواق الإقراض والجسور وأنظمة الضمان وعقود الحوكمة والعديد من التطبيقات الأخرى على السلسلة.

لا يشغّل المستخدمون البشريون كود Solidity مباشرةً.

يكتب المطورون كود مصدر Solidity ثم يترجمونه إلى بايت كود يمكن لآلة Ethereum الافتراضية تنفيذه.

توضح وثائق Solidity أن Solidity لغة عالية المستوى وموجهة للكائنات لتنفيذ العقود الذكية.

ببساطة، Solidity هي لغة البرمجة الرئيسية التي يستخدمها كثير من المطورين لإنشاء تطبيقات كريبتو قابلة للبرمجة على شبكات البلوكشين القائمة على EVM.

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

تُعد Solidity مهمة لأنها تشغّل العديد من العقود الذكية التي يتفاعل معها المستخدمون في منظومة الكريبتو.

عندما يبدّل المستخدم التوكنات أو يسك NFT أو يشارك في تصويت DAO أو يودع ضمانًا أو يطالب بمكافآت أو يتفاعل مع تطبيق DeFi، فقد يعالج عقد ذكي مكتوب بلغة Solidity جزءًا من هذا الإجراء.

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

غالبًا ما تعتمد التوكنات، مثل الأصول القابلة للاستبدال وNFT، على معايير للعقود الذكية تُنفذ عادةً باستخدام Solidity.

يحدد معيار توكن ERC-20 الرسمي واجهة مشتركة للتوكنات القابلة للاستبدال في العقود الذكية.

ويحدد معيار توكن ERC-721 الرسمي واجهة مشتركة للتوكنات غير القابلة للاستبدال.

ويحدد معيار توكن ERC-1155 الرسمي معيارًا متعدد التوكنات يمكنه دعم الأصول القابلة للاستبدال وغير القابلة للاستبدال في نظام عقد واحد.

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

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

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

كيف تعمل Solidity؟

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

ثم يُترجم الكود إلى بايت كود EVM عبر مترجم Solidity، المعروف عادة باسم solc.

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

بعد الترجمة، يُرسل بايت كود النشر في معاملة بلوكشين لإنشاء حساب عقد.

وبعد النشر، يكون للعقد عنوان يمكن للمستخدمين والعقود الأخرى استدعاؤه.

لا يستدعي المستخدمون العقود الذكية عادةً بكتابة بايت كود خام.

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

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

يتطلب كل إجراء يغير الحالة معاملة على البلوكشين ورسومًا يدفعها مرسل المعاملة.

لذلك، يجب أن يراعي تطوير Solidity كلاً من الصحة وتكلفة الغاز.

Solidity وآلة Ethereum الافتراضية

آلة Ethereum الافتراضية، أو EVM، هي بيئة وقت التشغيل التي تنفذ البايت كود المترجم للعقود الذكية.

توضح مقدمة Solidity للعقود الذكية أن EVM هي بيئة وقت التشغيل لعقود Ethereum الذكية، وهي معزولة عن النظام المحيط بها.

صُممت Solidity لاستهداف EVM، أي إن كود Solidity يُترجم إلى تعليمات تفهمها EVM.

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

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

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

تنشئ EVM أيضًا بيئة معزولة تحد مما تستطيع العقود فعله.

لا يستطيع عقد Solidity استدعاء موقع إلكتروني عشوائي مباشرة، أو قراءة بيانات خادم خاصة، أو الوصول إلى معلومات خارج السلسلة ما لم تُجلب تلك المعلومات إلى السلسلة عبر معاملة أو نظام Oracle.

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

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

Solidity والعقود الذكية

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

يحدد الكود الدوال التي يمكن استدعاؤها وما تفعله تلك الدوال.

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

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

كما يمكن للعقد استدعاء عقود أخرى، ما ينشئ أنظمة على السلسلة قابلة للتركيب.

تُعد قابلية التركيب إحدى أهم ميزات Solidity في الكريبتو، إذ يمكن لبروتوكول أن يبني على واجهة عقد بروتوكول آخر.

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

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

تكون العقود الذكية شفافة عادةً بعد التحقق، لكن الشفافية لا تعني الأمان تلقائيًا.

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

صياغة Solidity

تستخدم Solidity الأقواس المعقوفة وتعريفات الدوال والمتغيرات والأنواع والبُنى والتعيينات والأحداث والمعدلات وأنماط الوراثة التي قد تبدو مألوفة للمطورين العارفين بـ JavaScript أو C++ أو Java أو لغات مشابهة.

تشير وثائق Solidity الرسمية إلى أن اللغة متأثرة بـ C++ وPython وJavaScript.

يبدأ ملف Solidity عادة بمعرف ترخيص وتعليمة pragma.

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

ثم يحتوي تعريف العقد على متغيرات الحالة والأحداث والأخطاء والمنشئات والدوال والمعدلات وأحيانًا الأنواع المتداخلة.

تتميز Solidity بكتابة ثابتة، أي إن للمتغيرات ومعلمات الدوال أنواعًا معلنة.

تشمل الأنواع الشائعة bool وuint256 وint256 وaddress وbytes وstring والمصفوفات والبُنى والتعدادات والتعيينات.

يجب على المطورين التفكير بعناية في التخزين والذاكرة وcalldata والرؤية وقابلية التغيير وضبط الوصول.

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

قد تنتج الصياغة التي تبدو بسيطة سلوكًا معقدًا على السلسلة.

العقود

العقد هو اللبنة الأساسية في Solidity.

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

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

وقد يخزن عقد الإقراض الضمانات والديون ومؤشرات الفائدة وإعدادات التصفية.

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

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

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

يستدعي المستخدمون هذا العنوان للتفاعل مع دوال العقد.

لا يعمل كود العقد إلا عندما تشغله معاملة أو استدعاء.

لا يعمل العقد بشكل مستمر كتطبيق خادم عادي.

متغيرات الحالة

متغيرات الحالة هي متغيرات مخزنة بشكل دائم في تخزين العقد.

تُستخدم للبيانات التي يجب أن تبقى متاحة عبر المعاملات.

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

التخزين مكلف لأن عُقد البلوكشين يجب أن تحتفظ بهذه البيانات وتتحقق منها.

ينبغي للمطورين تجنب تخزين بيانات غير ضرورية على السلسلة.

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

قد يؤدي خطأ في تخطيط التخزين إلى إفساد حالة العقد المهمة أثناء الترقية.

يمكن لـ Solidity إخراج معلومات تخطيط التخزين عبر المترجم، ما يساعد المطورين والمدققين على مراجعة مخاطر الترقية.

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

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

الدوال

تحدد الدوال الإجراءات التي يمكن لعقد Solidity تنفيذها.

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

تتحكم رؤية الدالة في من يمكنه استدعاء الدالة وكيفية الوصول إليها.

تشمل كلمات الرؤية الشائعة public وexternal وinternal وprivate.

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

تشمل كلمات قابلية التغيير الشائعة view وpure وpayable.

يمكن لدالة view قراءة الحالة دون تغييرها.

ينبغي ألا تقرأ دالة pure حالة العقد أو تغيرها.

يمكن لدالة payable استقبال الأصل الأصلي للسلسلة عند استدعائها مع قيمة.

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

الأحداث

الأحداث هي سجلات تصدرها عقود Solidity أثناء التنفيذ.

وتساعد المحافظ والمستكشفات والمفهرسات والتطبيقات على تتبع ما حدث في المعاملة.

يصدر تحويل التوكن عادة حدث Transfer عند تنفيذه وفقًا لمعايير التوكنات الشائعة.

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

تفيد الأحداث لأنها أقل تكلفة في التخزين من تخزين العقد الكامل، ويسهل للأنظمة خارج السلسلة فهرستها.

لكن الأحداث ليست هي نفسها حالة العقد.

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

ينبغي للتطبيقات ألا تثق بسجلات الأحداث دون فهم منطق العقد.

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

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

المعدلات

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

يتحقق معدل شائع مما إذا كان المستدعي مالكًا أو مسؤولًا أو حاكمًا أو دورًا مخولًا قبل السماح بتشغيل الدالة.

يمكن للمعدلات تقليل تكرار الكود وتسهيل قراءة ضبط الوصول.

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

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

ينبغي للمطورين الحفاظ على وضوح المعدلات وتركيزها.

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

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

بل ينبغي لهم أيضًا فحص المعدلات الموروثة وشروط ضبط الوصول.

قد يخلق معدل مفقود أو معطل خطرًا أمنيًا جسيمًا.

التعيينات

التعيين هو بنية بيانات مفتاح-قيمة شائعة الاستخدام في عقود Solidity.

غالبًا ما تُخزن أرصدة التوكنات في تعيين من العنوان إلى المبلغ.

وقد تُخزن عمليات السماح في تعيين متداخل من المالك إلى المنفق إلى المبلغ.

قد تستخدم أنظمة الحوكمة التعيينات لتتبع ما إذا كان عنوان ما قد صوّت.

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

تتميز التعيينات بالكفاءة في البحث عن القيم حسب المفتاح.

لكن لا يسهل التكرار فوق التعيينات مباشرة على السلسلة.

غالبًا ما يستخدم المطورون الأحداث أو هياكل بيانات إضافية عندما يحتاجون إلى أن تسرد الأنظمة خارج السلسلة إدخالات التعيين.

التعيينات قوية لكنها تتطلب محاسبة دقيقة.

قد يؤدي تحديث تعيين خاطئ إلى أرصدة غير صحيحة أو صلاحيات معطلة أو أموال مفقودة.

الواجهات

تحدد الواجهة توقيعات الدوال التي يمكن لعقد آخر استدعاؤها.

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

يمكن لواجهة توكن أن توضح لعقد DeFi كيفية استدعاء transfer أو transferFrom أو approve أو balanceOf أو allowance.

يمكن لواجهة Oracle أن توضح لبروتوكول إقراض كيفية قراءة بيانات الأسعار.

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

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

لكن الواجهة تصف فقط الاستدعاءات والقيم المُعادة المتوقعة.

ولا تثبت أن العقد خلف العنوان يتصرف بأمانة أو بصورة آمنة.

ينبغي للمطورين التحقق من الافتراضات المتعلقة بالعقود الخارجية قبل دمجها.

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

المكتبات

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

يمكن للمكتبة توفير دوال رياضية وأدوات للعناوين ومساعدات للتحويل الآمن وأدوات للمصفوفات وللسلاسل النصية أو عمليات هياكل البيانات.

تُضمّن بعض المكتبات في بايت كود العقد أثناء الترجمة.

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

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

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

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

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

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

يكون العقد آمنًا بقدر أمان المجموعة الكاملة من الكود التي تؤثر في سلوكه.

الوراثة

تتيح الوراثة لعقد Solidity إعادة استخدام كود عقود أخرى وتوسيعه.

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

يمكن للوراثة أن تجعل تنظيم الكود أسهل عند استخدامها بعناية.

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

يمكن للعقد الفرعي تجاوز دالة من العقد الأب.

وقد تنشئ الوراثة المتعددة مشكلات دقيقة في الترتيب والتجاوز.

ينبغي للمطورين الحفاظ على بساطة هياكل الوراثة متى أمكن.

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

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

الوراثة قوية، لكن المنطق الموروث المخفي قد يكون خطيرًا عند تجاهله.

ABI

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

توضح مواصفة Solidity ABI الرسمية أن ABI هي الطريقة القياسية للتفاعل مع العقود في منظومة Ethereum.

توضح ABI للبرامج كيفية ترميز استدعاءات الدوال وفك ترميز قيم الإرجاع.

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

من دون ABI، سيحتاج المستخدمون إلى التعامل مع calldata خام، وهو أصعب بكثير للفهم.

قد تتضمن ABI الدوال والأحداث والأخطاء والمدخلات والمخرجات ومعلومات النوع.

لا تثبت ABI أن العقد آمن.

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

يمكن للعقد الضار أن يملك ABI تبدو واضحة.

ينبغي للمستخدمين التعامل مع بيانات ABI باعتبارها طبقة سهولة استخدام، لا ضمانًا للثقة.

مترجم Solidity

يحوّل مترجم Solidity، أو solc، كود مصدر Solidity إلى بايت كود EVM والملفات الداعمة الناتجة.

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

يهم إصدار المترجم وإعداداته الدقيقة لأنهما يؤثران في البايت كود النهائي.

ينص إعلان إصدار Solidity 0.8.35 على أن الإصدار 0.8.35 قدم erc7201 builtin وعلمًا تجريبيًا عالي المستوى ومولد كود SSA CFG تجريبيًا.

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

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

تؤثر أيضًا إعدادات المترجم، مثل حالة المُحسّن وعدد عمليات تشغيله وإصدار EVM وvia-IR وعناوين المكتبات، في المخرجات.

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

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

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

البايت كود

البايت كود هو الكود منخفض المستوى الذي تنفذه EVM بعد ترجمة عقد Solidity ونشره.

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

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

تنفذ شبكات البلوكشين البايت كود بدل نص مصدر Solidity الأصلي.

لهذا يُعد التحقق من كود المصدر مهمًا.

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

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

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

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

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

الغاز

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

يجب أن يهتم مطورو Solidity بالغاز لأن الكود المكلف قد يجعل استخدام العقد مكلفًا أو غير عملي.

تكون الكتابة إلى التخزين عادةً أكثر تكلفة من قراءة الذاكرة أو calldata.

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

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

يكلف نشر العقد غازًا أيضًا، لأن البايت كود يجب تخزينه على السلسلة.

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

لا ينبغي أن يأتي تحسين الغاز على حساب منطق غير واضح أو غير آمن.

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

يوازن التطوير الجيد بـ Solidity بين الأمان والوضوح والكفاءة.

Solidity والتوكنات

تُستخدم Solidity على نطاق واسع لإنشاء عقود التوكنات وإدارتها.

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

يمكن لعقد NFT تتبع معرفات التوكنات الفريدة والمالكين والموافقات وروابط البيانات الوصفية وقواعد التحويل.

يمكن لعقد متعدد التوكنات إدارة أنواع كثيرة من التوكنات داخل نظام عقد واحد.

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

تُعد معايير ERC-20 وERC-721 وERC-1155 من أهم معايير التوكنات على مستوى التطبيقات في منظومة Ethereum.

لكن كتابة توكن بلغة Solidity أو اتباعه معيارًا ما لا يجعله آمنًا أو ذا قيمة.

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

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

تجعل Solidity إنشاء التوكنات ممكنًا، لكن جودة التوكن تعتمد على التصميم والحوكمة.

Solidity وDeFi

تحتل Solidity موقعًا محوريًا في كثير من تطبيقات التمويل اللامركزي (DeFi).

يمكن لعقود DeFi إدارة المبادلات ومجمعات السيولة وأسواق الإقراض والخزائن والمشتقات والتخزين واستراتيجيات العائد وأنظمة الحوكمة.

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

قد يفشل بروتوكول DeFi بسبب خطأ برمجي أو مشكلة Oracle أو نموذج محاسبة سيئ أو قاعدة تصفية معيبة أو ترقية غير آمنة أو هجوم على الحوكمة.

تتيح Solidity للعقود استدعاء بعضها بعضًا، ما يجعل DeFi قابلة للتركيب بدرجة كبيرة.

يمكن لقابلية التركيب أن تنشئ لبنات مالية مفيدة.

لكنها قد تخلق أيضًا مخاطر تبعيات عندما يعتمد بروتوكول على سلوك بروتوكول آخر.

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

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

لا يثبت العائد المرتفع أو حجم التداول المرتفع أن كود Solidity آمن.

Solidity وNFT

تُستخدم Solidity عادةً لإنشاء عقود NFT التي تحدد قواعد الملكية والتحويل للأصول الرقمية الفريدة.

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

غالبًا ما تشير البيانات الوصفية لـ NFT إلى الصور أو السمات أو الأوصاف أو الملفات الخارجية.

قد لا يخزن العقد الذكي كل الوسائط مباشرة على السلسلة، لأن تخزين البيانات الكبيرة على السلسلة قد يكون مكلفًا.

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

قد يكشف عقد NFT مكتوب بـ Solidity ومتحقق منه عن قواعد السك وحدود العرض وسلوك الإتاوات وقيود التحويل وصلاحيات المسؤول.

لكن العديد من مخاطر NFT ليست مخاطر كود فقط.

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

توفر Solidity منطق الملكية، لكنها لا تضمن القيمة الثقافية أو الطلب المستقبلي.

ينبغي لمشتري NFT الجمع بين مراجعة العقد والتحقق من المجموعة وتحليل السيولة.

Solidity وDAO

تُستخدم Solidity غالبًا لبناء عقود حوكمة DAO.

قد يدير عقد DAO المقترحات وقوة التصويت والتفويض والأقفال الزمنية وتنفيذ الخزانة وصلاحيات الأدوار.

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

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

تحتاج عقود DAO إلى تصميم حذر لأن هجمات الحوكمة قد تؤثر في الأصول الحقيقية.

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

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

قد تقلل ضوابط الطوارئ الضرر، لكنها تقدم قوة مركزية أيضًا.

توفر Solidity لـ DAO أدوات حوكمة قابلة للبرمجة، لكن أمان الحوكمة يعتمد على الكود والتنسيق البشري معًا.

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

مخاطر أمان Solidity

يُعد أمان Solidity من أهم موضوعات تطوير الكريبتو.

تتناول وثائق اعتبارات الأمان في Solidity مخاطر مثل إعادة الدخول وحدود الغاز وإرسال ether واستقباله وtx.origin والتفاصيل البسيطة والمخاوف المتعلقة بالمترجم.

قد تحدث إعادة الدخول عندما يستدعي عقد عقدًا خارجيًا قبل تحديث حالته الخاصة بأمان.

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

قد تنشئ أخطاء الأعداد الصحيحة والمحاسبة أرصدة خاطئة أو منطق رسوم معطلًا.

قد تؤدي أخطاء Oracle إلى أسعار غير صحيحة وتصفيات غير عادلة.

وقد تستبدل أخطاء الترقية منطقًا آمنًا بمنطق غير آمن.

قد تنشئ الاستدعاءات الخارجية غير المفحوصة مسارات تنفيذ غير متوقعة.

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

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

إعادة الدخول

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

وقد يسمح ذلك بسحوبات متكررة أو محاسبة معطلة أو تدفق تحكم غير متوقع.

توصي وثائق أمان Solidity بنمط Checks-Effects-Interactions بوصفه إحدى طرق تقليل مخاطر إعادة الدخول.

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

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

ينبغي للمطورين ألا يفترضوا أن إرسال الأصول غير ضار.

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

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

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

قد يصبح تحويل يبدو آمنًا خطيرًا إذا جرت تحديثات الحالة بترتيب خاطئ.

ضبط الوصول

يحدد ضبط الوصول من يمكنه استدعاء دوال Solidity الحساسة.

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

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

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

وقد ينشئ ضبط الوصول شديد المركزية مخاطر ثقة للمستخدمين أيضًا.

قد يعمل العقد من الناحية التقنية لكنه يظل غير آمن إذا كان مفتاح خاص واحد يستطيع استنزاف الأموال أو تغيير القواعد فورًا.

ينبغي للمطورين تصميم الصلاحيات وفق مبدأ أقل امتياز وفصل واضح للأدوار وخطط للاسترداد.

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

يمكن لكود Solidity المتحقق منه أن يكشف منطق الصلاحيات عند توفر المصدر.

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

أمان الأعداد الصحيحة

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

تطلبت إصدارات Solidity الأقدم عناية يدوية أكبر بتجاوز الأعداد الصحيحة للحد الأقصى والحد الأدنى.

قدمت Solidity 0.8.x حسابات مفحوصة افتراضيًا، تتراجع عند معظم حالات التجاوز ما لم تُستخدم كتل unchecked.

لا يلغي هذا التحسن في الأمان كل المخاطر الرياضية.

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

قد تحسن كتل unchecked كفاءة الغاز في حالات محددة، لكن يجب استخدامها بحذر.

تستخدم عقود DeFi غالبًا الرياضيات ذات النقطة الثابتة والمنازل العشرية للتوكنات، ما قد ينشئ أخطاء دقيقة.

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

وينبغي للمستخدمين فهم أن الحسابات الآمنة لا تعني اقتصادًا آمنًا تلقائيًا.

الصيغ الصحيحة لا تقل أهمية عن الحماية من التجاوز.

Oracles والبيانات الخارجية

لا تستطيع عقود Solidity الوصول إلى البيانات خارج السلسلة مباشرةً من تلقاء نفسها.

توضح وثائق Oracle في Ethereum أن Oracles توفر للعقود الذكية بيانات من العالم الخارجي.

يمكن لـ Oracles توفير الأسعار والعشوائية وبيانات الإثبات وبيانات الطقس والرياضة ومعلومات الهوية أو مدخلات أخرى خارج السلسلة.

في DeFi، تمثل Oracles للأسعار أهمية خاصة لأنها قد تحدد قيم الضمانات والتصفيات والسك والاستردادات والتسوية.

قد يسبب تصميم Oracle سيئ خسائر كبيرة حتى لو كان كود Solidity مكتوبًا بصورة صحيحة.

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

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

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

يمكن لـ Solidity فرض القواعد القائمة على Oracle، لكنها لا تستطيع جعل البيانات السيئة جيدة.

البيانات الخارجية أحد أكبر افتراضات الثقة في كثير من أنظمة العقود الذكية.

قابلية الترقية

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

تفصل العقود القابلة للترقية عادةً بين عقد Proxy وعقد تنفيذ.

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

يمكن لقابلية الترقية إصلاح الأخطاء وإضافة الميزات.

لكنها قد تنشئ مخاطر ثقة لأن المسؤولين أو الحوكمة قد يغيرون القواعد بعد إيداع المستخدمين للأموال.

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

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

ينبغي للمطورين توثيق صلاحيات الترقية بوضوح.

ينبغي للمدققين مراجعة التنفيذ الحالي وضوابط الترقية معًا.

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

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

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

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

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

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

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

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

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

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

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

التحقق نقطة بداية للعناية الواجبة، وليس نهايتها.

إصدارات Solidity

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

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

تنشر إعلانات إصدارات Solidity تفاصيل عن إصدارات المترجم وتغييرات اللغة.

وفقًا لمعلومات الإصدار الرسمية المتاحة في 2026، يُعد Solidity 0.8.35 إصدار مترجم حديثًا بوظائف جديدة وميزات مترجم تجريبية.

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

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

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

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

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

يُعد اختيار إصدار Solidity جزءًا من أمان العقد الذكي وقابلية إعادة الإنتاج.

أخطاء مترجم Solidity

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

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

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

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

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

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

ليست كل إصدارات المترجم القديمة غير آمنة تلقائيًا، لكن الإصدارات القديمة قد تفتقر إلى الفحوصات والإصلاحات الأحدث.

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

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

تمثل مخاطر المترجم سببًا آخر للحفاظ على ملفات النشر الناتجة.

أدوات تطوير Solidity

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

يُعد Remix IDE الرسمي بيئة مستندة إلى المتصفح تُستخدم عادةً للتعلم وكتابة عقود Solidity وترجمتها واختبارها.

يمكن لأطر سطر الأوامر وبيئات التطوير المحلية أتمتة الترجمة والاختبارات وعمليات النشر واختبارات Fork والتحقق.

يمكن لأدوات التحليل الساكن فحص كود Solidity بحثًا عن الثغرات الشائعة والأنماط المحفوفة بالمخاطر.

يمكن لأدوات اختبار Fuzz إنشاء مدخلات كثيرة لاكتشاف السلوك غير المتوقع.

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

لا تستطيع أداة واحدة ضمان الأمان.

يجمع تطوير Solidity الاحترافي عادةً بين اختبارات الوحدات واختبارات التكامل واختبارات Fuzz ومراجعة الكود والتدقيق ونصوص النشر والمراقبة والتخطيط للاستجابة للحوادث.

ينبغي للمبتدئين البدء بعقود صغيرة وشبكات اختبار قبل التعامل مع أموال حقيقية.

ينبغي للفرق المتقدمة استخدام مسارات بناء قابلة لإعادة الإنتاج وضوابط إصدار صارمة.

اختبار عقود Solidity

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

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

تتحقق اختبارات التكامل من كيفية عمل عقود متعددة معًا.

تحاكي اختبارات Fork سلوك العقد مقابل حالة سلسلة حقيقية منسوخة إلى بيئة محلية.

تجرب اختبارات Fuzz كثيرًا من المدخلات العشوائية أو المنظمة لاكتشاف الحالات الحدية.

تتحقق اختبارات الثوابت من بقاء القواعد المهمة صحيحة عبر إجراءات كثيرة.

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

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

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

لا ينبغي الوثوق بكود Solidity غير المختبر بأموال ذات قيمة ملموسة.

عمليات التدقيق

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

يمكن للتدقيق اكتشاف الأخطاء وعيوب التصميم ومشكلات ضبط الوصول والمخاطر الاقتصادية ومشكلات الترقية وفجوات التوثيق.

لا يضمن التدقيق أن العقد آمن.

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

تعتمد جودة التدقيق على النطاق والوقت ومهارة المدقق وتغطية الاختبارات والتوثيق وكيفية معالجة الفريق للنتائج.

ينبغي للمستخدمين قراءة ما إذا كانت نتائج التدقيق قد حُلّت أو قُبلت.

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

قد يخضع مشروع للتدقيق ثم ينشر لاحقًا ترقيات غير مدققة.

تكون عمليات التدقيق أكثر فائدة عندما تقترن بالتحقق العلني ومكافآت اكتشاف الأخطاء والمراقبة وحدود إطلاق متحفظة.

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

Solidity والتفاعلات مع المحافظ

تساعد المحافظ المستخدمين على توقيع المعاملات التي تستدعي عقود Solidity.

قد تعرض المحفظة عنوان العقد واسم الدالة والمعلمات وموافقات الأصول ورسوم الغاز ورسائل التحذير.

لا تعرف المحفظة دائمًا ما إذا كان العقد آمنًا.

قد تطلب بعض المواقع الضارة من المستخدمين توقيع معاملات خطيرة تستدعي دوال Solidity حقيقية بطرق ضارة.

تكتسب موافقات التوكنات أهمية خاصة لأن الموافقة قد تسمح لعقد بإنفاق توكنات من محفظة حتى مبلغ محدد.

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

وينبغي لهم تجنب توقيع معاملات لا يفهمونها.

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

تتيح Solidity تفاعلات قابلة للبرمجة، لكن المستخدمين يظلون مسيطرين على التوقيعات من محافظهم.

يمكن لتوقيع معاملة نقل الأموال بصورة دائمة أو منح صلاحيات.

Solidity وموافقات التوكنات

موافقات التوكنات نمط شائع في Solidity يتيح لعنوان ما إنفاق توكنات نيابة عن عنوان آخر.

في توكن بأسلوب ERC-20، تعيّن approve عملية سماح، وتستخدم transferFrom تلك السماح.

يجعل هذا التصميم مبادلات DeFi والإيداعات والمدفوعات والإجراءات الآلية ممكنة.

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

الموافقات غير المحدودة ملائمة لكنها تزيد التعرض للمخاطر.

ينبغي للمستخدمين اعتماد ما يحتاجونه فقط عندما يكون ذلك عمليًا.

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

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

ينبغي للمدققين فحص معالجة السماح بحثًا عن حالات السباق والفحوصات المفقودة والافتراضات غير الآمنة.

تُعد الموافقات إحدى أكثر الطرق شيوعًا لتفاعل المستخدمين العاديين مع مخاطر Solidity.

Solidity والتحقق الرسمي

يستخدم التحقق الرسمي أساليب رياضية لإثبات أن خصائص محددة للعقد تتحقق وفق افتراضات معرفة.

قد يكون ذلك مفيدًا للأنظمة عالية القيمة والبروتوكولات المالية والجسور ووحدات الحوكمة ومنطق المحاسبة الأساسي.

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

لا يلغي التحقق الرسمي الحاجة إلى الاختبار والتدقيق.

إنه يثبت فقط الخصائص التي جرى تحديدها فعليًا.

إذا كانت المواصفة غير مكتملة أو خاطئة، فقد يغفل الإثبات مخاطر واقعية.

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

وتكون أكثر قوة عند تطبيقها على منطق حاسم ذي قواعد واضحة.

بالنسبة إلى Solidity، يُعد التحقق الرسمي جزءًا من عملية أمنية ناضجة.

ويكون مفيدًا بصفة خاصة عندما قد يؤدي فشل العقد إلى خسائر كبيرة.

مزايا Solidity

الميزة الأولى لـ Solidity هي اعتمادها في المنظومة.

تدعم Solidity أدوات وعروضًا تعليمية وعمليات تدقيق ومعايير ومكتبات ومجتمعات مطورين كثيرة للعقود الذكية.

الميزة الثانية هي التوافق مع EVM.

يمكن لعقود Solidity استهداف Ethereum وبيئات أخرى داعمة لـ EVM عندما تكون قواعد الشبكة وإعدادات النشر متوافقة.

الميزة الثالثة هي قابلية التركيب.

يمكن لعقود Solidity استدعاء عقود أخرى والبناء على معايير التوكنات وواجهات البروتوكولات القائمة.

الميزة الرابعة هي القدرة التعبيرية.

يمكن للمطورين بناء التوكنات وأنظمة DeFi ومنظمات DAO والألعاب وNFT والمنطق المالي الآلي.

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

توضح هذه المزايا لماذا تظل Solidity إحدى أهم لغات العقود الذكية في الكريبتو.

مخاطر وقيود Solidity

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

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

الخطر الثالث هو أن عقود Solidity تتفاعل غالبًا مع عقود أخرى، ما ينشئ مخاطر التبعيات.

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

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

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

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

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

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

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

الأخطاء الشائعة في Solidity

من الأخطاء الشائعة كتابة ضبط وصول لا يحمي الدوال الحساسة.

وخطأ آخر هو إجراء استدعاءات خارجية قبل تحديث الحالة الداخلية بأمان.

والخطأ الثالث هو الوثوق بـ tx.origin للتفويض، وهو ما تحذر منه وثائق أمان Solidity.

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

والخطأ الخامس هو افتراض أن كل توكن بأسلوب ERC-20 يتصرف بالطريقة نفسها تمامًا.

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

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

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

والخطأ التاسع هو منح مفتاح مسؤول واحد صلاحيات مفرطة.

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

كيفية تقييم عقد Solidity

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

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

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

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

راجع سك التوكنات وحرقها وإيقافها والقائمة السوداء والرسوم وقيود التحويل عند تقييم عقود التوكنات.

راجع مصادر Oracle وقواعد الضمانات ومنطق التصفية والمحاسبة عند تقييم عقود DeFi.

تحقق من وجود عمليات تدقيق وما إذا كانت نتائج التدقيق قد عولجت.

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

راجع المعاملات والأحداث الأخيرة لمعرفة كيفية استخدام العقد.

ينبغي تقييم عقد Solidity بوصفه كودًا وبنية تحتية وحوكمة وتصميمًا اقتصاديًا معًا.

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

استخدم إصدارًا حديثًا ومستقرًا من مترجم Solidity بعد قراءة ملاحظات الإصدار واختبار السلوك.

ثبّت إصدارات المترجم وإصدارات التبعيات لعمليات البناء الإنتاجية.

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

استخدم ضبط وصول واضحًا وصلاحيات وفق مبدأ أقل امتياز.

اتبع أنماط الاستدعاء الخارجي الآمنة، مثل Checks-Effects-Interactions، عند الاقتضاء.

اكتب اختبارات للمسارات العادية ومسارات الفشل والحالات الحدية وسلوك المستخدمين الضارين.

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

وثّق صلاحيات المسؤول وصلاحيات الترقية وافتراضات Oracle وضوابط الطوارئ.

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

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

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

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

قارن عناوين العقود بمصادر المشروع الرسمية بدل الوثوق بروابط الرسائل العشوائية.

راجع موافقات التوكنات قبل توقيع المعاملات.

توخ الحذر مع الموافقات غير المحدودة وألغِ الصلاحيات غير المستخدمة عندما يكون ذلك عمليًا.

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

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

لا تودع الأموال في عقود لا تستطيع فهمها أو الوثوق بها بصورة مستقلة.

استخدم محافظ أجهزة أو أمانًا قويًا للمحفظة في التفاعلات عالية القيمة.

توخ الحذر مع عقود Solidity الجديدة أو غير المدققة أو عالية العائد أو مجهولة الهوية.

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

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

فيما تُستخدم Solidity؟

تُستخدم Solidity لكتابة العقود الذكية لـ Ethereum وبيئات البلوكشين الأخرى المتوافقة مع EVM.

هل Solidity عملة مشفرة؟

لا، Solidity هي لغة برمجة وليست عملة مشفرة أو توكنًا.

هل تقتصر Solidity على Ethereum؟

صُممت Solidity لـ Ethereum، لكنها تُستخدم أيضًا على شبكات بلوكشين أخرى تدعم آلة Ethereum الافتراضية أو بيئات تنفيذ متوافقة.

ما هو عقد Solidity الذكي؟

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

ما هو مترجم Solidity؟

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

ما هي ABI في Solidity؟

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

هل Solidity آمنة؟

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

هل يمكن تغيير عقود Solidity بعد النشر؟

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

لماذا تحتاج عقود Solidity إلى التدقيق؟

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

كيف يمكن للمستخدمين فحص عقد Solidity؟

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

الخلاصة

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

وتتيح للمطورين كتابة قواعد مقروءة بشريًا تُترجم إلى بايت كود EVM وتنفذها عُقد البلوكشين.

تنبع قوة Solidity من منظومتها الكبيرة ومعايير العقود الذكية وقابلية التركيب والأدوات والدعم الواسع لـ EVM.

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

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

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

بالنسبة إلى المبتدئين، من الأفضل فهم Solidity باعتبارها اللغة التي يستخدمها المطورون لكتابة برامج البلوكشين.

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

في سياق مسرد الكريبتو، تعني Solidity اللغة الرئيسية عالية المستوى المستخدمة لبناء العقود الذكية التي تنفذ على بيئات البلوكشين المشابهة لـ Ethereum ونشرها.

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