العقود الذكية: الخير والشر والكسل

لماذا لا ينبغي أن تكون البلوكشين الخاصة حريصة على تشغيل التعليمات البرمجية

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

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

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

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

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

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

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

فهم Ethereum

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

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

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

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

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

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

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

تقسمها

الآن بعد أن عرفنا كيف تعمل العقود الذكية لـ Ethereum ، يمكننا تقسيمها إلى خمسة أجزاء مكونة:

1. التعبير عن منطق الأعمال كبرامج كمبيوتر.
2. تمثيل الأحداث التي تؤدي إلى هذا المنطق كرسائل إلى البرامج.
3. استخدام التوقيعات الرقمية لإثبات من أرسل الرسائل.
4. وضع البرامج والرسائل والتوقيعات على blockchain.
5. تنفيذ كل برنامج لكل رسالة على كل عقدة.

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

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

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

مشكلة الحساب

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

1. المجموعات x إلى رقم واحد من اختيارك
2. المجموعات y إلى 123 * س + 567
3. المجموعات x إلى آخر رقمين من y، أي ص مودولو 100
4. If x أكثر من 2 ثم ارجع إلى الخطوة 2
5. وإلا توقف وإخراج قيمة x

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

If x is 0, 1, 2, 5, 6, 7 or 8، يتوقف البرنامج بسرعة إلى حد ما. لكن اذا x is 3, 4 or 9، يستمر إلى أجل غير مسمى. لا تصدقني؟ افتح برنامج Excel وجرب بنفسك (ستحتاج إلى وظيفة "MOD").

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

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

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

العقود الذكية مقابل التزامن

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

تعمل العقود الذكية بشكل سيئ من أجل إنتاجية عالية للمعاملات.

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

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

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

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

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

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

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

نقطة رئيسية حول dapp dev لم أكن أقدرها حقًا: المشكلة الرئيسية ليست تكلفة tx ؛ يمكن أن تتعامل ppl 0.001 دولار. هو الكمون. ppl تريد 500 مللي ثانية وليس 17 ثانية.

- فيتاليك بوترين (فيتاليك بوترين) 27 سبتمبر 2015

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

لصالح Ethereum

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

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

منع المعاملات المزعجة

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

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

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

البراهين البيانات المدمجة

في blockchain ، يتم ملء الكتل في الغالب بالمعاملات التي يؤكدونها. ومع ذلك ، تحتوي كل كتلة أيضًا على "رأس" مضغوط ، والذي يحتوي على معلومات مهمة مثل الطابع الزمني ورابط إلى الكتلة السابقة. للكتل العامة على أساس دليل على تجزئة العمل، إدخال خوارزمية التجزئة هو رأس الكتلة هذا وحده. هذا يعني أنه يمكن تقييم سلطة السلسلة بواسطة "عميل خفيف الوزن" دون تنزيل معظم محتوياتها. على سبيل المثال ، اعتبارًا من نوفمبر 2015 ، يبلغ حجم المجموعة الكاملة من رؤوس البيتكوين 30 ميغابايت مقارنةً بـ 45 جيجا بايت للسلسلة الكاملة. هذه نسبة 1500: 1 ، مما يحدث فرقًا كبيرًا للأجهزة المحمولة ذات النطاق الترددي والتخزين المحدودين.

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

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

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

الحكم على blockchains الخاصة

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

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

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

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

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

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

بلوكشين مزدوج الطابق

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

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

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

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

العقود الذكية في blockchains العامة

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

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

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

الخاتمه

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

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

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

إذا كانت العقود الذكية لا تفي بوعودها ، فلماذا ندفع ثمنها؟

شكرا لقرائتك.