من الفكرة إلى التنفيذ: تعديل مخطط توقيع المنحنى الإهليلجي الحالي ليكون حتميًا ويوفر وظائف عليه للحصول على إمكانية التحقق من خلال الأرقام العشوائية الكاذبة للكتلة.
فكرة
في خريف عام 2018 ، عندما تم تنشيط العقود الذكية الأولى على سلسلة Waves blockchain ، ظهر موضوع الحصول على أرقام عشوائية مزيفة بطريقة موثوق بها.
بالتفكير في الأمر ، توصلت إلى استنتاج مفاده أن أي blockchain هو نوع من القفص ، والحصول على مصدر موثوق من الانتروبيا في نظام مغلق أمر مستحيل.
ومع ذلك ، أحببت فكرة واحدة. إذا وقعت أوراكل عشوائي على بيانات المستخدم باستخدام خوارزمية حتمية ، فسيكون المستخدم قادرًا دائمًا على التحقق من هذا التوقيع بواسطة المفتاح العمومي للتأكد من أن القيمة التي تم الحصول عليها فريدة من نوعها. لن تتمكن أوراكل من إجراء أي تغييرات لأن الخوارزمية تأتي بنتيجة ذات قيمة واحدة. في الأساس ، يقوم المستخدم بإصلاح النتيجة ولكنه لا يعرفها حتى يتم نشرها بواسطة أوراكل. لذلك ، قد لا تثق في أوراكل على الإطلاق ، ولكن لا يزال بإمكانك التحقق من نتيجة عملها. بعد ذلك ، في حالة التحقق الناجح ، يمكن أن يكون هذا التوقيع مصدرًا للانتروبيا للحصول على رقم عشوائي مزيف.
على Waves blockchain ، يتم استخدام مخطط التوقيع EdDSA البديل Ed25519 . في هذا المخطط ، يتكون التوقيع من القيم R و S. R تعتمد على قيمة عشوائية ويتم حساب S على أساس رسالة موقعة ومفتاح خاص ونفس رقم عشوائي مثل R. لا يوجد اعتماد فريد ، وتوجد عدة تواقيع صالحة لنفس رسالة المستخدم.
على ما يبدو ، لا يمكن استخدام هذا النوع من التوقيع في حد ذاته كمصدر للأرقام العشوائية المزيفة لأنه غير محدد ، وبالتالي يمكن بسهولة التلاعب به من قبل أوراكل.
ومع ذلك ، كما اتضح ، من الممكن بالفعل أن نجعلها حتمية.
تم تعيين آمالي الكبيرة على الوظيفة العشوائية القابلة للتحقق (VRF) ، ولكن بعد دراسة تفاصيلها ، يجب أن أرفض هذا الخيار. على الرغم من أن VRF تقدم إصدارًا محددًا من التوقيع وإثباتاته ، فإن الخوارزمية لها مكان غريب يفتح ثقبًا أسودًا للتلاعب به من قبل أوراكل (هذه العبارة خاطئة ، راجع التحديث ). على وجه التحديد ، لحساب قيمة k ( القسم 5.1 ) ، يتم استخدام مفتاح خاص ، والذي لا يزال غير معروف للمستخدم ، لذلك لا يمكن للمستخدم التحقق من صحة حساب k. نتيجة لذلك ، يمكن أن تستخدم أوراكل أي قيمة k التي تحتاج إليها وتشغيل قاعدة بيانات في وقت واحد للعلاقات بين k والبيانات الموقعة لتكون قادرة على إعادة احتساب النتيجة الصحيحة دائما ل VRF. إذا رأيت سحبًا قائمًا على VRF دون الكشف عن المفتاح الخاص ، فيمكنك التوضيح والإشارة إلى الحاجة إما إلى الكشف عن المفتاح أو إزالته من حساب k بحيث سيكشف نفسه تلقائيًا بعد التوقيع الأول. بشكل عام ، كما ذكر أعلاه ، هذا مخطط غريب للأوراكل العشوائي.
بناءً على بعض التأمل وبدعم من المحللين المحليين ، وُلد مخطط لعملية VECRO.
يرمز VECRO إلى Veriliable Elliptic Curve Random Oracle. اتضح أن تكون بسيطة إلى حد ما. لتحقيق الحتمية ، نحتاج إلى إصلاح قيمة R قبل ظهور الرسالة المراد توقيعها. إذا كانت R ثابتة وكانت R جزءًا من الرسالة ، فهي تضمن بالإضافة إلى ذلك أن R ثابتة قبل الرسالة. يتم تحديد قيمة S تمامًا بواسطة رسالة مستخدم ، وبالتالي ، يمكن استخدامها كمصدر للأرقام العشوائية المزيفة.
في مخطط من هذا النوع ، فإن مدى دقة تحديد R غير ذي صلة ولا يزال في منطقة مسؤولية أوراكل. المهم هو أن S يتم تحديده بالكامل من قبل المستخدم ، ولكن لا يتم الكشف عن قيمته حتى يتم نشره بواسطة أوراكل. هذا هو بالضبط ما أردنا!
عند الحديث عن إصلاح R ، لاحظ أن إعادة استخدام R لتوقيع مختلف الرسائل يكشف تمامًا عن المفتاح الخاص في مخطط EdDSA. بالنسبة إلى مالك oracle ، من الضروري استبعاد إعادة استخدام R لتوقيع رسائل المستخدم المختلفة. أي ، في أي تلاعب أو تواطؤ ، فإن أوراكل دائما خطر فقدان مفتاحها الخاص.
لذلك ، سوف يقدم أوراكل وظيفتين للمستخدم: التهيئة ، والتي تحدد قيمة R وتوقيع ، والتي ترجع قيمة S. وفي الوقت نفسه ، فإن زوج R ، S هو توقيع منتظم يمكن التحقق منه لرسالة مستخدم تحتوي على ثابت قيمة R والبيانات العشوائية للمستخدم.
يمكن للمرء أن يجادل بأنه في blockchain ، هذا ليس سوى مخطط كشف التزام منتظم. في الأساس ، هذا ما هو عليه. ولكن هناك بعض الفروق الدقيقة. أولاً ، يستخدم أوراكل نفس المفتاح في جميع المعاملات ، والذي ، على سبيل المثال ، مناسب للعقود. ثانياً ، هناك خطر فقدان مفتاح خاص من قبل أوراكل بسبب الأداء غير الصحيح. على سبيل المثال ، إذا كان أوراكل يسهل اختبارات النتيجة ، فسيكون اختباران فقط كافيين لمعرفة المفتاح الخاص والوصول إلى المحفظة. ثالثا ، التوقيع الذي تم التحقق منه أصلا على blockchain ، والذي هو مصدر العشوائية ، هو مجرد جميل.
لمدة ستة أشهر ، كانت هذه الفكرة تنبت ، حتى وصل الحافز لتنفيذها في شكل منحة من Waves Labs . مع المنحة الكبرى تأتي مسؤولية كبيرة ، وهذا يعني أن يكون المشروع!
تطبيق
تم تنفيذ VECRO على blockchain Waves في وضع الطلب / الرد باستخدام معاملات النقل بين المستخدم والأوراكل. على حساب أوراكل ، يتم تعيين البرنامج النصي الذي يتحكم في العملية بدقة وفقا للمنطق الموضح أعلاه. يتم التحقق من المعاملات أوراكل عن طريق إعادة سلسلة كاملة من تفاعل المستخدم. وتشارك جميع المعاملات الأربعة في التحقق من القيمة النهائية. يضيف العقد الذكي جميعهم إلى خيط التحقق الصارم ، والتحقق من القيم خطوة بخطوة ولا يترك مجالًا لأي عمليات تلاعب.
دعونا نحاول وضعه بعبارات بسيطة. أوراكل لا يعمل فقط في إطار المخطط المقترح. يتم التحكم في تشغيلها بالكامل على مستوى blockchain من خلال عقد ذكي ميت . أي تحويل صغير سيؤدي إلى رفض المعاملة. لذلك ، إذا كانت المعاملة موجودة في blockchain ، فلن يضطر المستخدمون إلى التحقق من أي شيء ، حيث أن كل عملية التحقق قد تم بالفعل بواسطة مئات من عقد blockchain.
في الوقت الحالي ، يمكن تشغيل جهاز VECRO على شبكة Waves الرئيسية. يمكنك بالفعل إطلاق برنامجك: إنه أمر بسيط ، فقط انظر إلى مثال التكوين . يعمل الرمز الحالي على PHP (على WavesKit ، التي ناقشتها سابقًا ).
لاستخدام أوراكل ، تحتاج إلى:
- إصلاح R
- إرسال ما لا يقل عن 0.005 WAVES إلى الاسم المستعار أوراكل init @ vecr ؛
- تلقي رمز R في حقل المرفق في نقل الرمز المميز R-vecr من oracle إلى المستخدم ؛
- الحصول على توقيع
- إرسال ما لا يقل عن 0.005 WAVES إلى الاسم المستعار أوراكل العشوائية @ vecr. يجب عليك أيضًا إدخال رمز R وبيانات المستخدم الإضافية في حقل المرفقات ؛
- تلقي رمز S في حقل المرفق في نقل الرمز المميز S-vecr من أوراكل إلى المستخدم ؛
- استخدم S-code كمصدر للأرقام العشوائية المزيفة.
الفروق في التنفيذ الحالي:
- تستخدم WAVES المرسلة إلى أوراكل كرسوم لمعاملة العودة للمستخدم ، بحد أقصى 1 WAVES ؛
- كود R هو عبارة عن تسلسل لبايتة الرمز 'R' وقيمة R 32 بايت في تشفير base58 ؛
- يجب أن يسبق رمز R في المرفق بيانات المستخدم ؛
- الكود S عبارة عن تسلسل لبايت الرمز 'S' وقيمة 32 بايت S في تشفير base58 ؛
- 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 ، فإنه يحتل مكانته في أي حال ويسمح لك بالعمل دون أي وظائف إضافية.