مواجهة العقود الذكية: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

هناك أكثر من طريقة لوضع الرمز على blockchain

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

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

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

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

أساسيات Blockchain

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

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

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

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

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

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

دعونا نبدأ بقواعد المعاملات ، أول هذه التحديات ، ونرى كيف يتم التعبير عنها في Fabric و MultiChain و Ethereum و Corda على التوالي.

قواعد المعاملات

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

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

مدخلات ومخرجات

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

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

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

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

العقود والرسائل

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

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

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

قواعد المثال

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

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

مجتمعة ، هذان الشرطان كل ما هو مطلوب لإنشاء نظام مالي بسيط ولكنه قابل للحياة.

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

1. تحقق من أن المرسل قد قام بتوقيع المعاملة.
2. تحقق من أن المرسل لديه أموال كافية.
3. اقتطع الكمية المطلوبة من صف المرسل.
4. أضف هذه الكمية إلى صف المستلم.

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

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

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

قواعد مدمجة

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

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

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

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

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

قواعد المعاملات	القماش	متعدد السلاسل	إثيريم	حبل
الموديل	رسالة العقد	المدخلات والمخرجات	رسالة العقد	المدخلات والمخرجات
مدمجة	بدون اضاءة	أذونات + أصول + تيارات	بدون اضاءة	بدون اضاءة

الحتمية

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

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

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

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

مصادر اللا حتمية

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

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

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

الإعدام الحتمي

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

تختار فلاتر MultiChain وعقود Corda نهجًا مختلفًا من خلال تكييف لغات البرمجة الحالية وبيئات وقت التشغيل. يستخدم MultiChain جافا سكريبت قيد التشغيل في Google V8 المحرك ، الذي يشكل أيضًا جوهر متصفح Chrome والنظام الأساسي Node.js ، ولكن مع تعطيل مصادر عدم الحتمية. وبالمثل ، يستخدم كوردا جافا أو كوتلن، وكلاهما يتم تجميعها إلى "Java bytecode" الذي يتم تنفيذه داخل Java Virtual Machine ("JVM"). في الوقت الحالي ، تستخدم Corda JVM القياسي غير الحتمية من Oracle ، ولكن العمل جار لدمج نسخة حتمية. في هذه الأثناء ، يجب على مطوري عقود Corda الاهتمام بعدم السماح للحتمية في التعليمات البرمجية الخاصة بهم.

كيف تقارن نقاء Ethereum مع النهج التطوري الذي اتخذته MultiChain و Corda؟ الميزة الرئيسية لـ Ethereum هي تقليل المخاطر - من غير المرجح أن تحتوي الآلة الافتراضية المخصصة للغرض على مصدر غير مقصود للحتمية. في حين أنه يمكن إصلاح أي إشراف من هذا القبيل عن طريق تحديث البرامج ، إلا أنه قد يكون مدمرًا لأي سلسلة كانت غير محظوظة بما يكفي لمواجهتها. ومع ذلك ، فإن مشكلة Ethereum هي أن Solidity و EVM يشكلان نظامًا بيئيًا صغيرًا وناشئًا في السياق الأوسع للغات البرمجة وبيئات التشغيل. بالمقارنة ، جافا سكريبت وجافا هي أفضل لغتين على Githubتعمل على بلايين الأجهزة الرقمية ولديها أوقات تشغيل تم تحسينها على مدار عقود. من المفترض أن هذا هو السبب في أن blockchain العام لـ Ethereum يفكر في الانتقال إلى eWASM، شوكة حتمية لمعيار WebAssembly الناشئة.

الحتمية بالتصديق

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

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

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

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

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

الحتمية	القماش	متعدد السلاسل	إثيريم	حبل
الموديل	موافقات	وقت التشغيل المعدل	VM بنيت لهذا الغرض	وقت التشغيل المعدل
اللغات	اذهب + جافا + جافا سكريبت	جافا سكريبت	Solidity	جافا + كوتلن
رؤية التعليمات البرمجية	الأطراف المقابلة + المصدقين	كتلة سلسلة	كتلة سلسلة	الأطراف المقابلة + المعالين
فرض	لا	نعم	نعم	لا حتى الان)

منع الصراع

لقد ناقشنا حتى الآن كيف تعبر منصات blockchain المختلفة عن قواعد المعاملات في التعليمات البرمجية ، وكيف تضمن بشكل قاطع أن كل عقدة تطبق هذه القواعد بنفس الطريقة. حان الوقت الآن للحديث عن جانب ثالث من المواجهة: كيف تتعامل كل منصة مع احتمال أن تتعارض معاملتان ، ساريتان في حد ذاتها ، مع بعضها البعض؟ في أبسط مثال ، تخيل أن Alice لديها 10 دولارات في دفتر الأستاذ المالي وبث معاملتين - واحدة ترسل 8 دولارات إلى بوب والأخرى ترسل 7 دولارات إلى تشارلي. من الواضح أنه لا يمكن السماح إلا بإجراء واحد فقط من هذه المعاملات.

نموذجان

يمكننا البدء بتجميع نهج MultiChain و Corda لهذه المشكلة معًا. كما هو موضح سابقًا ، يستخدم كلاهما نموذج إدخال - إخراج لتمثيل المعاملات وقواعدها ، حيث ينفق كل إدخال معاملة ناتج معاملة سابق. هذا يؤدي إلى مبدأ بسيط لمنع الصراعات: لا يمكن إنفاق كل ناتج إلا مرة واحدة. يمكن لمرشحات MultiChain وعقود Corda الاعتماد على منصاتهم الخاصة لفرض هذا التقييد على الإطلاق. نظرًا لأن Alice's $ 10 يمثلها ناتج معاملة سابق ، فإن قاعدة الإنفاق المنفرد هذه توقفها تلقائيًا عن إرسالها إلى كل من Bob و Charlie.

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

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

المخرجات مقابل العقود

لقد رأينا حتى الآن طريقتين مختلفتين لمنع المعاملات المتضاربة - مخرجات الإنفاق الواحد في MultiChain و Corda ، والتحقق المستند إلى العقد في Ethereum. إذن أيهما أفضل؟

للمساعدة في الإجابة عن هذا السؤال ، دعنا نفكر في مثال على حساب "1-of-2 multisignature" الذي يحمل 100 دولار نيابة عن Gavin and Helen ، ويسمح لأي منهما بإنفاق هذا المال بشكل مستقل. يوجه جافين طلبه إلى دفع 80 دولارًا لدونا ، وبعد بضع ثوانٍ ، تريد هيلين إرسال 40 دولارًا إلى إدوارد. نظرًا لعدم وجود أموال كافية لكلا الدفعتين ، فإن هذه المعاملات ستتعارض حتمًا. في حالة بث كلا العمليتين ، سيتم تحديد النتيجة من خلال أيهما يجعلها أولاً في السلسلة. لاحظ أنه على عكس مثال أليس ، هذا الصراع هو من غير قصد، حيث لا أحد يحاول كسر قواعد التطبيق - لديهم ببساطة توقيت غير محظوظ.

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

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

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

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

مجموعات القراءة والكتابة

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

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

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

منع الصراع	القماش	متعدد السلاسل	إثيريم	حبل
الموديل	مجموعات القراءة والكتابة	الإنفاق الفردي	فحص العقود	الإنفاق الفردي
التحقق	مستقل	مستقل	مستقل	كتاب العدل الموثوق بهم
سرعة	~ 10 ث (تأكيد)	~ 1 ثانية (الانتشار)	~ 10 ث (تأكيد)	0 ~ 5 ث (كاتب العدل)

خيار معقد

في هذه المقالة ، استعرضنا العديد من الطرق المختلفة التي تعالج بها Corda و Ethereum و Fabric و MultiChain التحديات الرئيسية لـ "العقود الذكية" أو رمز التطبيق المضمّن في blockchain. ولكل منصة إجابات مختلفة على أسئلتنا الأساسية الثلاثة: كيف يتم تمثيل قواعد المعاملات؟ كيف يتم تنفيذ الرمز بشكل حتمي؟ وكيف نمنع الصراعات؟

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

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