المُنشئ (Constructor)

ما المُنشئ في الكريبتو؟

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

في تطوير العملات المشفرة، يُناقش المُنشئ غالبًا في سياق Solidity، وهي لغة برمجة العقود الذكية المستخدمة في الشبكات المتوافقة مع Ethereum Virtual Machine.

توضح وثائق Solidity الرسمية حول المُنشئات أن المُنشئ اختياري، ويستخدم الكلمة المفتاحية constructor، ويُنفذ أثناء إنشاء العقد.

يُستخدم المُنشئ أساسًا لتعيين القيم الأولية للعقد الذكي قبل أن يبدأ المستخدمون بالتفاعل معه.

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

بعبارات بسيطة، المُنشئ هو خطوة الإعداد التي تجهّز العقد الذكي للعمل على السلسلة.

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

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

المعنى المبسط للمُنشئ

المُنشئ هو دالة الإعداد الأولى للعقد الذكي.

يُنفذ أثناء النشر، ويعين القيم الأولية، ثم لا يعود جزءًا من التفاعل المعتاد مع العقد.

على سبيل المثال، قد يستخدم عقد توكن مُنشئًا لتعيين اسم التوكن ورمزه ومقدار العرض الأولي ومحفظة المسؤول.

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

وقد يستخدم عقد NFT مُنشئًا لتعيين اسم المجموعة وعنوان URI الأساسي للبيانات الوصفية ومستلم حقوق الملكية أو جهة مخولة بالسك.

لا يستدعي المستخدمون المُنشئ عادةً مباشرةً بعد النشر، لأنه ليس جزءًا من الواجهة العامة المعتادة للعقد.

يحدد المطورون منطق المُنشئ عادةً قبل النشر، ويمررون أي معاملات لازمة إليه ضمن معاملة النشر.

لذلك ينبغي مراجعة قيم المُنشئ بعناية قبل تشغيل العقد.

آلية عمل المُنشئ

عندما ينشر المطور عقدًا ذكيًا، تتضمن معاملة النشر رمز إنشاء العقد.

يوضح دليل Ethereum لنشر العقود الذكية أن نشر العقد يتضمن إرسال معاملة تحتوي على رمز العقد المترجم من دون تحديد عنوان مستلم عادي.

أثناء عملية الإنشاء هذه، يُنفذ المُنشئ كجزء من مسار النشر.

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

بعد اكتمال النشر، يخزن البلوكشين الرمز الثنائي لوقت التشغيل الخاص بالعقد عند عنوان العقد الجديد.

ولا يُستدعى المُنشئ مرة أخرى في الاستخدام المعتاد للعقد.

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

ينبغي للمطورين فهم دورة حياة العقد هذه قبل بناء التوكنات أو بروتوكولات DeFi أو عقود NFT أو أنظمة Staking أو عقود الخزينة.

المُنشئ في Solidity

في Solidity، يُكتب المُنشئ باستخدام الكلمة المفتاحية constructor داخل جسم العقد.

يمكن لمُنشئ Solidity تلقي معاملات، وهي قيم تُمرر عند نشر العقد.

على سبيل المثال، قد يتلقى مُنشئ توكن اسم التوكن ورمزه وعنوان المالك الأولي والعرض الأولي.

تسمح Solidity لكل عقد بمُنشئ واحد فقط.

إذا لم يعرّف العقد مُنشئًا، يتعامل المترجم معه كما لو كان لديه مُنشئ افتراضي فارغ.

يمكن للمُنشئات استدعاء مُنشئات العقود الأصلية عند استخدام الوراثة.

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

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

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

أهمية المُنشئات في العقود الذكية

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

يوضح دليل Ethereum للتحقق من العقود الذكية أن العقود الذكية غير قابلة للتغيير عمومًا، وتنفذ منطق الأعمال المحدد في الرمز عند النشر.

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

قد يؤدي تعيين عنوان مالك خاطئ إلى منع الفريق من الوصول إلى وظائف الإدارة.

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

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

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

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

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

معاملات المُنشئ

معاملات المُنشئ هي القيم التي تُمرر إليه أثناء النشر.

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

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

قد يبقى الرمز المصدري للعقد كما هو، بينما تغير معاملات المُنشئ إعدادات العقد المنشور النهائية.

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

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

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

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

المُنشئ ونشر العقود

يرتبط المُنشئ ارتباطًا وثيقًا بمعاملة النشر التي تنشئ عنوان العقد الذكي.

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

أثناء النشر، يُنفذ المُنشئ ويجهز الحالة النهائية.

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

يشير دليل Ethereum لبنية العقود الذكية إلى أن دوال المُنشئ تُنفذ مرة واحدة عند نشر العقد لأول مرة.

لذلك يُعد النشر لحظة عالية المخاطر لمشاريع الكريبتو.

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

وبعد النشر على الشبكة الرئيسية، قد تؤثر اختيارات المُنشئ في العقد طوال فترة عمله.

المُنشئ مقابل الدالة العادية

يختلف المُنشئ عن دالة العقد الذكي العادية.

يمكن عادةً استدعاء الدالة العادية بعد النشر إذا سمحت قواعد الرؤية والوصول بذلك.

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

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

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

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

وقد يربك ذلك المبتدئين الذين يتوقعون استدعاء المُنشئ مثل أي دالة عادية.

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

المُنشئ وعقود التوكنات

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

قد يحدد مُنشئ توكن قابل للاستبدال اسم التوكن ورمزه وعدد المنازل العشرية والعرض الأولي والمالك الأولي.

وقد يحدد مُنشئ NFT اسم المجموعة ورمزها وموقع بياناتها الوصفية ومستلم حقوق الملكية والجهة المسؤولة عن السك.

وقد يحدد مُنشئ توكن حوكمة قواعد قوة التصويت وإعدادات التفويض أو صلاحيات السك.

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

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

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

لذلك تُعد مراجعة المُنشئ جزءًا من العناية الواجبة بشأن التوكن.

المُنشئ وبروتوكولات DeFi

تستخدم بروتوكولات DeFi المُنشئات لربط الأجزاء المهمة من النظام.

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

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

وقد يحدد عقد Staking توكن المكافآت وتوكن Staking ومعدل المكافآت وفترتها ومحفظة الخزينة.

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

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

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

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

المُنشئ والتحكم في الوصول

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

غالبًا ما تعيّن المُنشئات الأدوار الأولى للتحكم في الوصول.

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

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

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

ينبغي ألا يمنح المُنشئ السلطة عرضًا للعنوان الخطأ.

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

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

المُنشئ والقيم غير القابلة للتغيير

تدعم Solidity المتغيرات غير القابلة للتغيير، وهي قيم يمكن تعيينها أثناء إنشاء العقد ثم التعامل معها على أنها ثابتة بعد النشر.

تفيد هذه المتغيرات عندما يحتاج العقد إلى إعداد ينبغي ألا يتغير بعد الإطلاق.

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

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

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

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

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

المُنشئ والعقود القابلة للترقية

غالبًا ما تستخدم العقود الذكية القابلة للترقية المُنشئات بطريقة تختلف عن العقود العادية.

يوضح دليل OpenZeppelin لكتابة العقود القابلة للترقية أن قابلية الترقية القائمة على Proxy تتطلب من المطورين استبدال المُنشئات بدوال التهيئة.

ويعود ذلك إلى تفاعل المستخدمين مع عقد Proxy، بينما يحتوي عقد التنفيذ على المنطق.

في كثير من أنماط Proxy، لا يهيئ مُنشئ عقد التنفيذ مساحة تخزين Proxy.

وبدلًا من ذلك، يستخدم المطورون دالة initialize تُنفذ مرة واحدة عبر Proxy.

وهذا يجعل أمن دوال التهيئة بالغ الأهمية.

إذا تُركت دالة التهيئة مفتوحة، فقد يحاول مهاجم تهيئة العقد والاستيلاء على الأدوار الرئيسية.

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

المُنشئ مقابل دالة التهيئة

يُنفذ المُنشئ مرة واحدة أثناء النشر العادي للعقد.

أما دالة التهيئة فهي دالة عادية مصممة لتعمل عمل المُنشئ في العقود القابلة للترقية.

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

غالبًا ما تستخدم دوال التهيئة معدّلات تسمح بتشغيلها مرة واحدة فقط.

يضمن مسار نشر العقد أمان المُنشئات التي تقتصر على التنفيذ مرة واحدة.

أما دوال التهيئة، فيجب أن تحقق هذا الأمان عبر الرمز البرمجي.

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

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

المُنشئ وعقود المصنع

عقد المصنع هو عقد ذكي ينشر عقودًا ذكية أخرى.

غالبًا ما تمرر المصانع معاملات المُنشئ إلى العقود التي تنشئها.

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

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

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

تستخدم بعض تصميمات المصانع نسخًا مصغرة من Proxy لتقليل تكلفة النشر.

يصف معيار EIP-1167 للـ Proxy المصغر نمط Proxy خفيفًا يفوض الاستدعاءات إلى عنوان تنفيذ معروف.

عند استخدام أنماط النسخ، قد تتم التهيئة عبر دالة تهيئة بدلًا من المُنشئ التقليدي.

المُنشئ وCREATE2

CREATE2 ميزة في EVM تتيح توقع عنوان العقد قبل النشر في ظل شروط معينة.

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

قد تؤثر معاملات المُنشئ في تجزئة رمز الإنشاء، ما قد يؤثر في عنوان العقد النهائي عند استخدام CREATE2.

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

إذا غيّر المطورون معاملات المُنشئ، فقد يتغير العنوان المتوقع أيضًا.

تنقل بعض الأنظمة الإعدادات من المُنشئ إلى دالة تهيئة للحفاظ على ثبات الرمز الثنائي للنشر.

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

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

المُنشئ وتكاليف الغاز

قد تؤثر المُنشئات في تكاليف الغاز عند النشر.

عادةً ما يتطلب منطق المُنشئ الأكثر تعقيدًا عمليات حسابية أكثر أثناء النشر.

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

وقد تجعل معاملات المُنشئ الكبيرة بيانات النشر أكبر حجمًا.

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

غالبًا ما يحاول المطورون إبقاء منطق المُنشئ واضحًا وآمنًا وغير معقد أكثر من اللازم.

يوازن التصميم الجيد للمُنشئ بين الأمان وسهولة القراءة وكفاءة الغاز.

في مشاريع الكريبتو، لا ينبغي أن يأتي توفير الغاز على حساب التهيئة غير الآمنة.

المُنشئ والتحقق من العقد

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

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

عندما يعرض العقد الذي جرى التحقق منه مدخلات المُنشئ، يستطيع المستخدمون الاطلاع على المعلمات الأولية المستخدمة عند النشر.

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

يعزز التحقق الشفافية، لكنه لا يثبت تلقائيًا أن العقد آمن.

فما زال على المستخدمين فهم الرمز والصلاحيات والاعتماديات والمخاطر.

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

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

أخطاء شائعة في المُنشئات

من الأخطاء الشائعة تعيين عنوان المالك الخطأ أثناء النشر.

ومنها أيضًا تمرير عنوان توكن خاطئ إلى عقد DeFi.

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

أما الخطأ الرابع فهو وضع منطق معقد جدًا داخل المُنشئ من دون اختبارات مناسبة.

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

والخطأ السادس هو عدم توثيق معاملات المُنشئ للمستخدمين والمدققين.

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

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

أفضل الممارسات للمُنشئات

ينبغي للمطورين إبقاء منطق المُنشئ بسيطًا وسهل المراجعة.

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

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

كما ينبغي اختبار سلوك المُنشئ على شبكات الاختبار وشبكات التطوير المحلية قبل النشر على الشبكة الرئيسية.

وينبغي توثيق جميع معاملات المُنشئ في سجلات النشر.

كما ينبغي التحقق من العقود بعد نشرها، كي يتمكن المستخدمون من مراجعة الرمز المصدري وقيم المُنشئ.

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

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

أهمية المُنشئات للمستخدمين

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

قد يكشف مُنشئ التوكن عن الجهة التي تلقت العرض الأولي.

وقد يكشف مُنشئ عقد Staking عن التوكن الذي يجري تخزينه فعليًا والتوكن المستخدم للمكافآت.

وقد يكشف مُنشئ الخزينة عن الأصل الذي تديره الخزينة وعنوان الاستراتيجية التي تستخدمها.

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

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

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

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

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

ما المُنشئ في العقد الذكي؟

المُنشئ دالة إعداد خاصة تُنفذ مرة واحدة فقط عند نشر العقد الذكي.

ما استخدام المُنشئ في الكريبتو؟

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

هل يمكن استدعاء المُنشئ بعد النشر؟

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

هل المُنشئ مثل الدالة العادية؟

لا، يمكن استدعاء الدالة العادية بعد النشر، بينما لا يُنفذ المُنشئ إلا أثناء النشر.

هل يمكن لعقد Solidity أن يحتوي على أكثر من مُنشئ واحد؟

لا، يمكن لعقد Solidity تعريف مُنشئ واحد فقط.

ماذا يحدث إذا لم يتضمن العقد مُنشئًا؟

إذا لم يُعرّف مُنشئ، فسيتصرف العقد كما لو كان لديه مُنشئ افتراضي فارغ.

لماذا تستخدم العقود القابلة للترقية دوال التهيئة بدلًا من المُنشئات؟

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

هل يمكن إصلاح أخطاء المُنشئ لاحقًا؟

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

هل تؤثر معاملات المُنشئ في التحقق من العقد؟

نعم، تساعد معاملات المُنشئ على توضيح كيفية إنشاء الرمز الثنائي المنشور والحالة الأولية.

لماذا ينبغي للمستخدمين التحقق من قيم المُنشئ؟

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

الخلاصة

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

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

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

أما في العقود القابلة للترقية، فيستبدل المطورون المُنشئات غالبًا بدوال التهيئة، لأن أنظمة Proxy تستخدم نموذجًا مختلفًا للتخزين والنشر.

يؤثر تصميم المُنشئ في الأمان والشفافية واستخدام الغاز والتحقق وثقة المستخدمين.

ينبغي للمطورين اختبار منطق المُنشئ بعناية والتحقق من مدخلات النشر والتحقق من العقود وتوثيق معاملات المُنشئ.

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

يساعد المُنشئ المصمم جيدًا العقد الذكي على البدء بالشكل الصحيح، بينما قد يتسبب المُنشئ السيئ في مشكلات دائمة داخل نظام يعمل على السلسلة.