كتلة أوراكل على أساس أوراكل عشوائي على أساس التوقيع الرقمي

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



فكرة


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


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


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


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


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


ولكن ، كما اتضح ، جعله محددًا أمر ممكن بالفعل.


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


مع القليل من التفكير والتجنيد بدعم من المحللين المحليين ، ولدت سير عمل VECRO.


VECRO عبارة عن اختصار لـ Oracle Verphiable Curve Random Oracle ، والذي يعني باللغة الروسية وجود أوراكل عشوائي محدد على منحنيات إهليلجية.


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


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


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


في الإجمال ، يجب أن يوفر oracle للمستخدمين وظيفتين: التهيئة ، والتي تحدد قيمة R ، والتوقيع ، والتي تُرجع قيمة S.. علاوة على ذلك ، فإن الزوج R ، S هو توقيع يتم التحقق منه بشكل منتظم لرسالة مستخدم يحتوي على قيمة ثابتة ل R وبيانات مستخدم تعسفية.


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


لمدة نصف عام ، كانت فكرة التنفيذ في رأسي حتى النهاية كان هناك دافع في شكل منحة من Waves Labs . مع منحة كبيرة تأتي مسؤولية كبيرة ، ثم يجب أن يكون المشروع!


تطبيق


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


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


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


من أجل استخدام خدمة أوراكل ، يجب عليك:


  • إصلاح ص.
    • إرسال ما لا يقل عن 0.005 موجات إلى الاسم المستعار أوراكل init @ vecr ؛
    • الحصول على رمز R في حقل المرفق في نقل رمز R-vecr واحد من أوراكل إلى المستخدم ؛
  • الحصول على توقيع
    • أرسل ما لا يقل عن 0.005 من الموجات إلى الاسم المستعار أوراكل العشوائي @ vecr ، وتشير ALWAYS دائمًا إلى رمز R وبيانات المستخدم الإضافية التي تم تلقيها مسبقًا في حقل المرفقات ؛
    • احصل على S-code في حقل المرفقات في نقل رمز S-vecr واحد من أوراكل إلى المستخدم ؛
  • استخدم S-code كمصدر رقم عشوائي زائف.

الفروق الدقيقة في التنفيذ الحالي:


  • تستخدم الموجات المرسلة إلى أوراكل كعمولة لمعاملة عكسية للمستخدم ، بحد أقصى 1 موجات ؛
  • كود R هو تسلسل بايت الحرف R و القيمة 32 بايت R في ترميز base58 ؛
  • يجب أن يكون رمز R في المرفق الأول ، وتأتي بيانات المستخدم بعد رمز R ؛
  • كود S هو تسلسل البايت للحرف 'S' و 32 بايت من قيمة S في ترميز base58 ؛
  • S هو نتيجة لتقسيم modulo ؛ وبالتالي ، لا يمكن استخدام S كرقم عشوائي شبه كامل 256 بت (يمكن اعتبار هذا الرقم بحد أقصى عشوائي للرقم الزائف 252 بت) ؛
  • أبسط خيار هو استخدام التجزئة من S-code كرقم عشوائي شبه.

مثال على الحصول على كود S:



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


سأكون سعيدًا للإجابة على الأسئلة وقبول التعليقات ، شكرًا.


تحديث 8 مايو 2019


كان مخطئا حول VRF. نعم ، في الواقع ، لا يمكن استخدام توقيع ECVRF كمصدر للرقم العشوائي الزائف ، ولكن لا يتم استخدامه لهذا الغرض. يلزم توقيع لإنشاء دليل على تفرد قيمة جاما ( القسم 5.3 ، الخطوة 6). لكن قيمة جاما التي تم التحقق منها باستخدام التوقيع تشارك بالفعل كمصدر لرقم عشوائي زائف ( القسم 5.2 ، الخطوة 5). بفضل Oleg Taraskin Crittografo على الإشارة إلى هذه النقطة ، أعترف بخطأي . ECVRF لديه كل الحق في الحياة.


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


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

Source: https://habr.com/ru/post/ar449340/


All Articles