لماذا العديد من حالات تطبيق العقد الذكي ببساطة غير ممكن

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

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



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

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

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

العقد الذكي هو مجرد اسم رنان لرمز يعمل على blockchain ويتفاعل مع حالته. ما هذا الكود؟ هذا هو باسكال أو بيثون أو PHP. أو ربما جافا ، فورتران أو سي ++. إذا كنت تفكر في تنسيق قاعدة البيانات ، فيمكن تمثيلها في شكل إجراءات مكتوبة في بعض امتداد SQL.

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

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

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

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

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

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

1. التفاعل مع الخدمات الخارجية

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. دفع المدفوعات داخل السلسلة

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

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

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

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

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

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

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

3. ضرورة إخفاء البيانات الحساسة

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

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

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

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

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

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

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

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

ما هو الغرض من العقود الذكية؟

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

تتيح لك Blockchains التخلي عن التوسط في العمل مع البيانات ، مما قد يؤدي إلى تبسيط كبير وخفض التكاليف.

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

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

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

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

يتم استخدام القاعدة في السجل المالي: يجب ألا يتعارض إجمالي مبلغ الأموال في السجلات المحذوفة مع المبلغ الإجمالي في السجلات التي تم إنشاؤها. (يعتبر التغيير في السجل بمثابة حذف لهذا السجل وإعادة إنشائه بالقيم الضرورية).

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

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

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

لذلك ، بالعودة إلى السؤال عن ما هي العقود الذكية: فهي مطلوبة عندما لا يكون من الممكن تنفيذ حالة blockchain باستخدام تقييد المعاملات.

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

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

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

, , . - . , .