مقدمة
تقدم هذه المقالة مشروعًا ابتكر حلاً جديدًا لمشكلة متكررة في تقنية (البلوكتشين) . يتعاون باحثون ومهندسون من جامعة واين ستيت وجامعة نيو جلوبال للتنمية والجامعة الجنوبية للعلوم والتكنولوجيا وجامعة بوردو وجامعة هونغ كونغ للفنون التطبيقية وجامعة هونغ كونغ وجامعة ديلاوير في هذا المشروع.
معضلة (البلوكتشين)
عندما يتعلق الأمر بتطوير (البلوكتشين) ، فإن التسليم هو قيد رئيسي. بمعنى آخر: كيف يمكننا تطبيق تقنية (البلوكتشين) في سيناريوهات الحياة الواقعية؟ لتحقيق هذا الهدف ، نقوم بعمل افتراضات ثابتة حول تطبيقات هذه التقنية في مجالات مثل الألعاب والفواتير والرموز غير القابلة للاستبدال. لكن حالات الاستخدام هذه تخدش فقط سطح القدرات الكاملة لـ (البلوكتشين) . يمكننا مقارنة حالة استخدام (البلوكتشين) اليوم بمستوى الاعتماد الحالي لتقنية 5G ، وهي غنية بالميزات والوظائف ولكنها في الواقع تُستخدم في الغالب لمجرد اختبارات السرعة.
إذا لم تكن السيناريوهات مثل الألعاب مناسبة لتقنية (البلوكتشين) ، فمن المنطقي أن نسأل أين يمكننا العثور على سيناريوهات أكثر ملاءمة. ومع ذلك ، هناك تحدٍ: تقنية (البلوكتشين) هي نظام معزول. من أجل السلامة والأمن ، لا تثق (البلوكتشين) إلا في بياناتها الموجودة على السلسلة. لا تقبل البيانات المتدفقة من خارج بيئة (البلوكتشين) الأصلية الخاصة بها. على سبيل المثال ، يتم إنشاء ناتج المعاملة غير المنفقة (يو تي اكس او) من المعاملات على السلسلة. كمثال آخر ، عند تنفيذ عقد ذكي ، يمكن فقط الوصول إلى البيانات الموجودة على السلسلة من خلال عدد قليل من الواجهات.
نتيجة لذلك ، إذا أراد المستخدمون العمل باستخدام تقنية (البلوكتشين) ، فلا يمكنهم الاعتماد على المعلومات خارج السلسلة ، على الرغم من حقيقة أن مثل هذه التفاعلات مطلوبة في معظم سيناريوهات العالم الحقيقي. هذا القيد غير متزامن مع متطلبات العديد من حالات الاستخدام اليومية التي يمكن أن تكون مناسبة لتقنية (البلوكتشين) . على سبيل المثال لا الحصر:
تتطلب التطبيقات التي يستخدمها الأشخاص على هواتفهم المحمولة اتصالاً بالإنترنت.
تحتاج تطبيقات حجز التذاكر إلى معلومات في الوقت الفعلي حول الأرقام المتبقية وأسعار التذاكر.
تحتاج تطبيقات التداول إلى الوصول إلى معلومات التسعير.
تحتاج تطبيقات التوصيل إلى الوصول إلى أحدث المعلومات اللوجستية.
خلاصة القول: لبعض الوقت ، لم تكن هناك طريقة لاستخدام (البلوكتشين) لإنجاز مثل هذه المهام.
استجابة للحاجة إلى توسيع سيناريوهات تطبيق (البلوكتشين) والوصول إلى إمكاناته الكاملة ، ولدت طريقة تفاعل: (اوراكل)، والتي يمكنها تغذية تدفق البيانات خارج السلسلة إلى (البلوكتشين) .
جمال (أوراكل)
أوراكل (البلوكتشين) هو طرف ثالث موثوق به يتعامل بين الإنترنت التقليدي و (البلوكتشين) . يجب أن يثق العقد الذكي على (البلوكتشين) في كل من البيانات المقدمة من شركة أوراكل ومصداقية أوراكل (مع الثقة في أنها خالية من تزوير البيانات أو التلاعب بها). لتوفير هذه الثقة لـ (البلوكتشين) ، يجب على نظام (أوراكل) ضمان سلامة وأمن نظامه الخاص. على سبيل المثال ، يستخدم (تشين لينك) ، وهو أوراكل مشهور ، العقد الموزعة لتجميع البيانات لضمان صحتها. كمثال آخر ، يعتمد الوصول إلى السوق العالمي (يو ام ايه) آلية تسوية المنازعات للكشف عن البيانات التي بها مشاكل.
أوراكل هي حصن قوي من الثقة خارج بيئة (البلوكتشين) الأصلية. يمكن أن توفر حصن الثقة هذا تقريبًا أي نوع من البيانات خارج السلسلة لـ (البلوكتشين) . تعمل هذه القدرة على توسيع سيناريوهات تطبيق (البلوكتشين) بشكل كبير وتكشف عن مستقبل مشرق لتقنية (البلوكتشين) . ليس من المبالغة أن نقول إن أوراكل هي الثورة العظيمة الثانية في (البلوكتشين) بعد العقود الذكية.
عيب أوراكل الفادح
من الواضح أنه من الأخبار الجيدة أن استخدام أوراكل يحل مشكلة هيكلية كانت عائقًا حاسمًا أمام مستقبل (البلوكتشين) ، وقد أدى توفر (أوراكل) إلى تعزيز تطوير (البلوكتشين) . لكن لسوء الحظ ، فإن نظام أوراكل الحالي به أيضًا عيب فادح: وقت الإستجابة.
يمكن تشغيل نظام أوراكل بإحدى طريقتين رئيسيتين:
كخيار واحد ، يمكن تشغيل الطلب من خلال عقد ذكي ، وبعد ذلك يمكن لـ (أوراكل) الوصول إلى البيانات خارج السلسلة وفقًا للطلب. ثم يقوم أوراكل بإرجاع البيانات إلى العقد الذكي.
أو يمكن أن يقوم أوراكل بمزامنة البيانات باستمرار على السلسلة. طالما أن تغيير البيانات خارج بيئة (البلوكتشين) يتجاوز الحد الأدنى ، فسيتم تشغيل معاملة لتحديث البيانات الموجودة على السلسلة لضمان أن المستخدمين يمكنهم استخدام البيانات الأكثر دقة.
لكن كلا النوعين من الأوراكل بهما عيب أساسي: العملية التي تستغرق وقتًا طويلاً للحصول على البيانات من خلال الإجماع. يقدم الشكل 3 مثالاً على هذه المشكلة: يرسل المستخدم أولاً معاملة إلى شبكة (البلوكتشين) . بعد جولة إجماع (على سبيل المثال 15 ثانية) ، يرمي العقد الذكي المقابل طلب بيانات. ثم يلتقط (أوراكل) الطلب (يستغرق حوالي 100 مللي ثانية). بعد التقاط الطلب ، يرسل (أوراكل) طلبات البيانات إلى المصدر خارج بيئة (البلوكتشين) . بعد ذلك ، سيتم إرسال الملاحظات إلى شبكة (البلوكتشين) في شكل معاملة (تستغرق حوالي 100 مللي ثانية أخرى).
في هذا المثال ، يمكننا أن نرى أن هناك على الأقل زمن انتقال 15 ثانية + 100 مللي ثانية + 100 مللي ثانية بين وقت بدء المستخدم للمعاملة ووقت إرجاع مصدر البيانات النهائي للبيانات. قد يبدو هذا الكمون صغيرًا. ولكن في حالة وقوع حدث البجعة السوداء أو هجوم القراصنة ، فإن وقت الاستجابة لمدة عشر ثوانٍ أو أكثر سيكون قاتلاً.
لا نحتاج إلى النظر إلى أبعد من الهجوم الذي حدث على سلسلة (بنب) هذا الشهر لنرى الخراب الذي يمكن أن يحدثه هذا النوع من وقت الإستجابة : استفاد المتسللون من تأخر سعر أوراكل وسرقوا 15 مليون دولار من الرموز المعادلة. الهجوم ، اقرأ كيف حقق المهاجمون 15 مليون دولار من (ستاكينج بلاتفورم هيليو) بعد أنكر إكسبلويت).
الحل: أوراكل بدون وقت الإستجابة
على مدار العام الماضي ، ازداد قلق فريق بحث المشروع لدينا بشأن مشكلة الكمون الخطيرة في نظام أوراكل الحالي. أصبحت هذه المشكلة أكثر إثارة للقلق في عام 2022 في ضوء حدث (لونا) وإفلاس (اف تي اكس) . في حدث (لونا) ، تقلب سعر (لونا) بنسبة تصل إلى 50 ٪ في غضون دقيقة عند ذروته ، وتقلب سعر (اف تي اكس) بنسبة تصل إلى 20 ٪ في غضون دقيقة. لا يمكن مزامنة الأسعار شديدة التقلب مع السلسلة في الوقت المناسب بواسطة أنظمة أوراكل التقليدية. بناءً على هذه المشكلات المقلقة في عالم (البلوكتشين) ، نعتقد بقوة أن وجود نظام (أوراكل) يمكنه تعيين 100٪ من بيانات التسعير خارج السلسلة إلى (البلوكتشين) أمر لا بد منه.
لحسن الحظ ، مشكلة التأخير في أوراكل ليست مستعصية على الحل.
يتمثل الحل التقليدي لوقت الاستجابة في أن يرسل المستخدمون طلب البيانات مباشرة إلى أوراكل دون المرور عبر (البلوكتشين) . تعزل أنظمة أوراكل التقليدية (بغض النظر عن هياكلها) نفسها دائمًا عن المستخدم الذي يتفاعل أولاً مع (البلوكتشين) . بعد ذلك ، يتفاعل (البلوكتشين) مع (أوراكل).
هناك نوعان من الأسباب المنطقية لاستخدام هذه الطريقة التقليدية:
أولاً ، تجعل هذه الطريقة من السهل نسبيًا على المستخدم التفاعل مباشرة مع (البلوكتشين) ، وإعادة استخدام جميع أنظمة المحفظة الحالية بالكامل. لا يحتاج المستخدم إلى معرفة كيفية تشغيل العقد لطلبات البيانات أو كيفية الوصول إلى البيانات.
ثانيًا ، يتجنب هذا الهيكل رسوم الغاز. باستخدام هذه الطريقة ، سيدفع المستخدم رسوم الغاز أولاً ، ثم يقدم أوراكل الخدمة. (إذا تفاعل المستخدم مع أوراكل مباشرة ، فستكون رسوم الغاز الناتجة مشكلة.)ومع ذلك ، فإن هذا النهج التقليدي له مشاكله الخاصة:
سيقدم أوراكل الخدمة في البداية قبل الحصول على سداد رسوم الغاز من المستخدم. إذا تم التعامل مع هذه الإستراتيجية بشكل غير صحيح ، فستزيد من خطر هجوم رفض الخدمة. على سبيل المثال ، إذا طلب أوراكل البيانات وأسس معاملة أوراكل لمهاجم ، فسيتم إرجاع تنفيذ معاملة أوراكل ، مما يؤدي إلى دفع أوراكل رسوم معاملة أوراكل ولكن عدم تمكنه من الحصول على تعويض من المهاجم ، وبالتالي استنفاد غاز عقد أوراكل.
أيضًا ، من الصعب تجميع البيانات التي يطلبها المستخدم مع البيانات التي حصل عليها أوراكل. لا يمكننا ببساطة ربط مجموعتي البيانات معًا: يجب أن توفر أوراكل ، بصفتها موفر بيانات تابعًا لجهة خارجية ، بيانات قابلة للتحقق ، ويجب أن يكون العقد المتعلق بالسلسلة قابلاً للتحقق. يجب أن يكون العقد الذكي على (البلوكتشين) قادرًا على التحقق من أن البيانات التي يحصل عليها مطلوبة بالفعل من قبل المستخدم ، والتحقق من أن الطلب قد بدأ بالفعل من قبل المستخدم ، والتحقق من عدم إعادة استخدام الطلب.لقد وجد فريق البحث لدينا حلاً لمعالجة هذه المشكلات من خلال تمكين أوراكل بدون وقت الإستجابة ، كما هو موضح في الشكل 4.
سيمكن هذا الحل من تنفيذ هيكل تفاعل المستخدم المباشر مع أوراكل بطريقة آمنة.
تحقيقا لهذه الغاية ، يركز عمل فريق البحث لدينا على ما يلي:
اعتماد بيئة تنفيذ موثوقة (تي إي إي) لتعزيز أمان عقد أوراكل. (تي إي إي) في بيئة تنفيذ معزولة. هذا يعني أنه حتى إذا قام المهاجمون بكسر نظام تشغيل عقد أوراكل ، فلن يتمكنوا من كسر المنطق الأساسي المحمي بواسطة (تي إي إي) أو العبث بالبيانات المطلوبة بواسطة ارتباط (تي إل اس) الذي بدأه (تي إي إي) .
استخدم آلية اللجنة للدفاع عن نقطة فشل واحدة (اس بي او اف). على الرغم من أن (تي إي إي) توفر أمانًا قويًا لضمان عدم العبث بمنطق التنفيذ والبيانات الداخلية ، فلا يزال يتعين على (تي إي إي) العمل على جهاز مادي. هذا يعني أن المهاجم يمكنه تنفيذ هجوم (دي او اس) فعلي على عقدة أوراكل. قد يستخدم المهاجمون المتطرفون حتى هجمات القنوات الجانبية لخرق (تي إي إي) لفترات طويلة من الوقت ، وبالتالي ، فإننا نستخدم آلية اللجنة التي تستخدم (تي إي إي) متعددة لمعالجة طلبات بيانات المستخدم بشكل مشترك. لضمان أمان نظام (أوراكل) بالكامل ، يمكن أن تكون عقد (تي إي إي) الخاصة باللجنة من مؤسسات مختلفة (أو حتى من تطبيقات (تي إي إي) مختلفة).
استخدم التجزئة الهيكلية لحزم طلبات المستخدم بالبيانات. لضمان إمكانية التحقق من طلبات بيانات المستخدم والبيانات المعبأة بواسطة أوراكل ، نشير إلى بروتوكول التجزئة والتوقيع الهيكلي الذي اقترحه (إي آي بي 712) لإنشاء هيكل طلبات بيانات المستخدم ومعاملات أوراكل المستخدمة لإرسال البيانات.
ما التالي للمشروع
مر مشروع أوراكل هذا بعدة أشهر من البحث والتصميم والتنفيذ والاختبار ، وقمنا بتطوير نموذج أولي للنظام. لقد اختبرنا نظام (أوراكل) الخاص بنا بأكثر من 200 نقطة بيانات تسعير. بناءً على هذا الاختبار ، أكدنا أن النظام يمكن أن يزود المستخدمين “ما تراه هو ما تحصل عليه” (WYSIWYG) مكالمات البيانات خارج السلسلة بزمن انتقال 100 مللي ثانية ، مما يحقق حالة قريبة من الخطأ للجميع تدفقات البيانات.
تم الانتهاء من الورقة ذات الصلة ، وطلب البراءة ذي الصلة معلق.
يتطلع فريق البحث لدينا إلى الخطوات التالية في فتح مسار آمن إلى مستوى جديد من حالات الاستخدام في العالم الحقيقي في عالم تقنية (البلوكتشين) .
يتعلم أكثر
مقال سابق لهذا المؤلف عن نظام أوراكل متاح هنا: Oracle Machine.