مقدمة إلى العقود الذكية

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

العقد العادي مقابل. العقد الذكي

قبل أن نخوض في التفاصيل، دعونا نأخذ مثالاً على الاختلافات بين العقد العادي، المحدد على الورق، والعقد الذكي، الذي يتم تمثيله رقمياً.

مقدمة إلى العقود الذكية

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

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

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

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

تعريف العقد الذكي

بشكل عام، المصطلح نفسه صاغه الباحث نيك زابو واستخدم لأول مرة في عام 1994، وتم توثيقه في عام 1997 في مقال يصف فكرة العقود الذكية ذاتها.

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

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

مثال بسيط - خدمة الضمان

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

مقدمة إلى العقود الذكية

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

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

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

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

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

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

مثال مع عنبر وثلاجة

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

مقدمة إلى العقود الذكية

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

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

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

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

تصنيف العقود الذكية

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

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

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

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

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

أدناه سنلقي نظرة فاحصة على المعايير الثلاثة الأولى لإضفاء مزيد من الوضوح على فهم الموضوع الحالي.

العقود الذكية حسب وقت التشغيل

مقدمة إلى العقود الذكية

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

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

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

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

العقود الذكية بطريقة تحديد الشروط وتحقيقها

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

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

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

تشمل عقود تورينج الكاملة التعسفية منصة Ethereum وRootStock، والتي لا تزال قيد التطوير. لذلك، أدناه سنتناول المزيد من التفاصيل حول منصة العقود الذكية لـ Ethereum.

العقود الذكية حسب طريقة البدء

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

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

حسابات الايثيريوم

أنواع حسابات الإيثريوم

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

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

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

كيف يتم إنشاء الحسابات على الايثيريوم

في حالة حساب المستخدم، يقوم المالك بشكل مستقل بإنشاء زوج مفاتيح باستخدام ECDSA. من المهم ملاحظة أن إيثريوم يستخدم نفس الخوارزمية تمامًا ونفس المنحنى الإهليلجي تمامًا للتوقيعات الإلكترونية مثل بيتكوين، ولكن يتم حساب العنوان بطريقة مختلفة قليلاً. هنا، لم يعد يتم استخدام نتيجة التجزئة المزدوجة، كما هو الحال في البيتكوين، ولكن يتم توفير التجزئة الفردية مع وظيفة Keccak بطول 256 بت. يتم قطع البتات الأقل أهمية من القيمة الناتجة، أي أقل 160 بت أهمية من قيمة تجزئة الإخراج. نتيجة لذلك، نحصل على عنوان في Ethereum. في الواقع، يستغرق الأمر 20 بايت.

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

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

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

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

هيكل المعاملات الايثيريوم

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

مقدمة إلى العقود الذكية

تتكون معاملة Ethereum من عدة حقول. أول هذه العناصر، nonce، هو رقم تسلسلي معين للمعاملة المتعلقة بالحساب نفسه الذي يوزعها وهو مؤلفها. يعد ذلك ضروريًا للتمييز بين المعاملات المزدوجة، أي لاستبعاد الحالة التي يتم فيها قبول نفس المعاملة مرتين. باستخدام معرف، يكون لكل معاملة قيمة تجزئة فريدة.

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

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

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

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

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

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

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

مثال على رمز العقد الذكي لـ Solidity

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

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

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

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

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

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

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

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

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

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

كيف تعمل العقدة الكاملة على شبكة الإيثيريوم؟

دعونا نلقي نظرة تخطيطية على كيفية تنفيذ هذه العقود الذكية على منصة Ethereum وكيفية عمل عقدة الشبكة الكاملة.

مقدمة إلى العقود الذكية

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

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

الوحدة الثالثة تسمى EVM (جهاز Ethereum الظاهري) - وهي جهاز افتراضي يتلقى الرمز الثانوي من معاملات Ethereum. تأخذ هذه الوحدة الحالة الحالية لحساب معين وتقوم بإجراء تغييرات على حالته بناءً على الرمز الثانوي المستلم. يجب أن يكون إصدار الجهاز الظاهري على كل عقدة شبكة هو نفسه. الحسابات التي تتم على كل عقدة إيثريوم هي نفسها تمامًا، ولكنها تحدث بطريقة غير متزامنة: يقوم شخص ما بفحص هذه المعاملة وقبولها مسبقًا، أي تنفيذ جميع التعليمات البرمجية الموجودة فيها، ويقوم شخص ما لاحقًا. وفقًا لذلك، عند إنشاء معاملة، يتم توزيعها على الشبكة، وتقبلها العقد، وفي وقت التحقق، وبنفس الطريقة التي يتم بها تنفيذ Bitcoin Script في Bitcoin، يتم تنفيذ الرمز الثانوي للجهاز الظاهري هنا.

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

الخرافات والقيود على العقود الذكية

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

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

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

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

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

عيوب الإيثريوم

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

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

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

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

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

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

الأسئلة المتداولة

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

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

— ماذا لو أبرم الوسيط اتفاقية مع أحد الأطراف المشاركة: الضمان أو العقد الذكي؟ هل الوسيط مطلوب في العقد الذكي؟

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

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

هذا سؤال جيد ويتعلق بنموذج معاملة Ethereum وكيف يختلف عن نموذج Bitcoin. والفرق جذري. إذا قمت ببساطة في نموذج معاملة Ethereum بنقل العملات المعدنية، فسيتم نقلها فقط من عنوان إلى آخر، دون تغيير، فقط المبلغ المحدد الذي حددته. بمعنى آخر، هذا ليس نموذجًا للمخرجات غير المنفقة (UTXO)، ولكنه نموذج للحسابات والأرصدة المقابلة. من الممكن نظريًا إرسال عدة رموز مختلفة في معاملة واحدة في وقت واحد إذا كتبت عقدًا ذكيًا ماكرًا، ولكن سيظل يتعين عليك إجراء العديد من المعاملات، وإنشاء عقد، ثم نقل الرموز المميزة والعملات المعدنية إليه، ثم استدعاء الطريقة المناسبة . يتطلب هذا جهدًا ووقتًا، لذلك من الناحية العملية لا يعمل الأمر بهذه الطريقة ويتم إجراء جميع المدفوعات في Ethereum في معاملات منفصلة.

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

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

إحدى محاضرات الدورة التدريبية عبر الإنترنت حول Blockchain مخصصة لهذا الموضوع - "مقدمة إلى العقود الذكية".

المصدر: www.habr.com

إضافة تعليق