احذر العقد الذكي المستحيل

المفاهيم الخاطئة الثلاثة الأكثر شيوعًا للعقد الذكي

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

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

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

لسوء الحظ ، فإن حقيقة العقود الذكية أكثر دنيوية من كل ذلك:

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

هذا هو. هل حقا. العقد الذكي هو مجرد اسم فاخر للرمز الذي يعمل على blockchain ، ويتفاعل مع حالة blockchain تلك. و ماذا is الشفرة؟ إنها باسكال ، إنها بايثون ، إنها PHP. إنها جافا ، إنها فورتران ، إنها C ++. إذا كنا نتحدث عن قواعد البيانات ، فهو كذلك الإجراءات المخزنة مكتوب في امتداد SQL. جميع هذه اللغات متكافئة بشكل أساسي ، حيث تحل نفس أنواع المشاكل بنفس أنواع الطرق. بالطبع ، لكل منها نقاط قوته وضعفه - سيكون من الجنون إنشاء موقع ويب في C أو ضغط الفيديو عالي الدقة في Ruby. ولكن من حيث المبدأ على الأقل ، يمكنك ذلك إذا أردت ذلك. كنت ستدفع ثمنا باهظا من حيث الراحة والأداء ، وربما شعرك.

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

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

الاتصال بالخدمات الخارجية

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

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

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

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

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

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

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

فرض المدفوعات على السلسلة

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

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

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

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

إخفاء البيانات السرية

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

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

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

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

ما هي العقود الذكية

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

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

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

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

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

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

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

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

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

يرجى نشر أي تعليقات في LinkedIn.