مقدمة

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

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

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

طريقتان لتنفيذ PVRB

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

عقد مستقل

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

الخيار مع العقد المستقل جيد:

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

كما أن لها عيوب:

• قيود قوية على موارد الحوسبة وحجم المعاملات والتخزين (وبعبارة أخرى، وحدة المعالجة المركزية/الذاكرة/الIO)
• قيود على العمليات ضمن العقد (ليست كل التعليمات متوفرة، من الصعب ربط المكتبات الخارجية)
• عدم القدرة على تنظيم الرسائل بشكل أسرع من المعاملات المضمنة في blockchain

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

الإجماع المتكامل

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

عند وصف تطبيقات PVRB على مستوى إجماع الشبكة، لا يمكن للمرء بأي حال من الأحوال تجنب قضايا النهاية. النهائية هي آلية تستخدم في الإجماع الحتمي الذي يقفل كتلة (والسلسلة المؤدية إليها) نهائية ولن يتم التخلص منها أبدًا، حتى في حالة حدوث شوكة موازية. على سبيل المثال، في Bitcoin لا توجد مثل هذه الآلية - إذا قمت بنشر سلسلة أكثر تعقيدًا، فسوف تحل محل أي أقل تعقيدًا، بغض النظر عن طول السلاسل. وفي EOS، على سبيل المثال، فإن النهائيات هي ما يسمى بالكتل الأخيرة التي لا رجعة فيها، والتي تظهر في المتوسط ​​كل 432 كتلة (12*21 + 12*15، التصويت المسبق + الالتزام المسبق). تنتظر هذه العملية بشكل أساسي 2/3 من توقيعات منتجي الكتل (المشار إليهم فيما بعد باسم BP). عندما تظهر الشوكات الأقدم من آخر LIB، يتم التخلص منها ببساطة. تتيح هذه الآلية ضمان تضمين المعاملة في blockchain ولن يتم التراجع عنها أبدًا، بغض النظر عن الموارد التي يمتلكها المهاجم. كما أن الكتل النهائية هي كتل موقعة بواسطة 2/3 BP في Hyperledger وTendermint وغيرها من الإجماعات المستندة إلى pBFT. ومن المنطقي أيضًا إنشاء بروتوكول لضمان النهاية كإضافة إلى الإجماع، لأنه يمكن أن يعمل بشكل غير متزامن مع إنتاج الكتل ونشرها. هذه فكرة جيدة مقالة حول النهاية في Ethereum.

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

ولذلك، فإن الخيار الأفضل هو الجمع بين PVRB والنهائية في بروتوكول واحد - ثم الكتلة النهائية = عشوائية نهائية، وهذا هو بالضبط ما نحتاج إلى الحصول عليه. الآن سيحصل اللاعبون على عشوائي مضمون في N ثانية، ويمكنهم التأكد من أنه من المستحيل استرجاعه أو إعادة تشغيله مرة أخرى.

الخيار المتكامل الإجماع جيد:

• إمكانية التنفيذ غير المتزامن فيما يتعلق بإنتاج الكتل – يتم إنتاج الكتل كالمعتاد ولكن بالتوازي مع ذلك يمكن أن يعمل بروتوكول PVRB الذي لا ينتج عشوائية لكل كتلة
• القدرة على تنفيذ التشفير الثقيل، دون القيود المفروضة على العقود الذكية
• القدرة على تنظيم تبادل الرسائل بشكل أسرع من المعاملات المضمنة في blockchain، على سبيل المثال، جزء من البروتوكول يمكن أن يعمل بين العقد دون توزيع الرسائل عبر الشبكة

كما أن لها عيوب:

• صعوبات في الاختبار والتطوير - سيتعين عليك محاكاة أخطاء الشبكة والعقد المفقودة والشوكات الصلبة للشبكة
• تتطلب أخطاء التنفيذ وجود شوكة صلبة للشبكة

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

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

PVRB ومتغيرات الكتلة.

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

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

ولكن حتى التجزئات الآمنة ما بعد الكمية ليست كافية، للأسف. السر يكمن في متطلبات PVRB دعوني أذكركم بها في المقال السابق:

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

في هذه الحالة، تم استيفاء المتطلب 1 فقط، ولم يتم استيفاء المتطلب 2. من خلال تجزئة قيم غير متوقعة من الكتلة، سنحصل على توزيع موحد وعشوشات جيدة. لكن لدى شركة BP على الأقل خيار "نشر الحظر أم لا". وبالتالي، يمكن لشركة BP على الأقل الاختيار من بين خيارين عشوائيين: الخيار "الخاص بها" والخيار الذي سيحدث إذا قام شخص آخر بالكتلة. يمكن لشركة BP "التطفل" مسبقًا على ما سيحدث إذا قام بنشر الكتلة، ويقرر ببساطة القيام بذلك أم لا. وبالتالي، عند اللعب، على سبيل المثال، بـ "زوجي فردي" أو "أحمر/أسود" في لعبة الروليت، يمكنه نشر كتلة فقط إذا رأى فوزًا. وهذا أيضًا يجعل استراتيجية استخدام، على سبيل المثال، كتلة التجزئة "من المستقبل" غير قابلة للتطبيق. في هذه الحالة، يقولون أنه “سيتم استخدام العشوائي، والذي يتم الحصول عليه عن طريق تجزئة البيانات الحالية وتجزئة الكتلة المستقبلية بارتفاع، على سبيل المثال، N + 42، حيث N هو ارتفاع الكتلة الحالية. وهذا يقوي المخطط قليلاً، لكنه لا يزال يسمح لشركة BP، وإن كان ذلك في المستقبل، باختيار ما إذا كانت ستحتفظ بالكتلة أو تنشرها.

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

لذا فإن الطرق التي تستخدم المعلومات من الكتلة ليست مناسبة كتطبيق عالمي لـ PVRB. في إصدار محدود، مع قيود على أحجام الرهان، وقيود على عدد اللاعبين و/أو تسجيل KYC (لمنع لاعب واحد من استخدام عناوين متعددة)، يمكن أن تعمل هذه المخططات في الألعاب الصغيرة، ولكن ليس أكثر.

PVRB وكشف الالتزام.

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

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

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

PVRB والتوقيعات الحتمية.

هناك طريقة أخرى لإجبار RP على تقديم رقم عشوائي زائف لا يمكنه التأثير عليه إذا تم تزويده بـ "صورة مسبقة" - وهذا توقيع حتمي. مثل هذا التوقيع هو، على سبيل المثال، RSA، وليس ECS. إذا كان لدى RP زوج من المفاتيح: RSA وECC، وقام بتوقيع قيمة معينة باستخدام مفتاحه الخاص، ففي حالة RSA سيحصل على توقيع واحد فقط، وفي حالة ECS يمكنه إنشاء أي عدد من التوقيعات. توقيعات صالحة مختلفة. وذلك لأنه عند إنشاء توقيع ECS يتم استخدام رقم عشوائي، يتم اختياره من قبل الموقع، ويمكن اختياره بأي شكل من الأشكال، مما يتيح للموقع فرصة اختيار واحد من عدة توقيعات. في حالة RSA: "قيمة إدخال واحدة" + "زوج مفاتيح واحد" = "توقيع واحد". من المستحيل التنبؤ بالتوقيع الذي سيحصل عليه RP آخر، لذلك يمكن تنظيم PVRB ذو التوقيعات الحتمية من خلال الجمع بين توقيعات RSA للعديد من المشاركين الذين وقعوا على نفس القيمة. على سبيل المثال، العشوائية السابقة. هذا المخطط يوفر الكثير من الموارد، لأنه التوقيعات هي تأكيد للسلوك الصحيح وفقًا للبروتوكول ومصدر للعشوائية.

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

PVRB وخطط المشاركة السرية

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

إذا كان مخطط FSSS (المشاركة السرية فيات شامير) قابلاً للتطبيق في شكله النقي، فسيكون PVRB غير قابل للتدمير. في أبسط صوره، قد يبدو البروتوكول كما يلي:

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

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

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

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

PVRB والتوقيعات العتبة

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

إن الجمع بين التوقيعات الحتمية ومخططات العتبة جعل من الممكن تطوير مخطط مناسب وواعد للغاية لتنفيذ PVRB - وهذه توقيعات عتبة حتمية. هنا مقالة حول الاستخدامات المختلفة لتوقيعات العتبة، وإليك فكرة جيدة أخرى longread من داش.

تصف المقالة الأخيرة توقيعات BLS (BLS تعني Boneh-Lynn-Shacham، هنا مقالة)، والتي تتمتع بجودة مهمة جدًا ومريحة للغاية للمبرمجين - يمكن دمج المفاتيح العامة والسرية والعامة وتوقيعات BLS مع بعضها البعض باستخدام عمليات رياضية بسيطة، بينما تظل مجموعاتها مفاتيح وتوقيعات صالحة، مما يسمح لك بتجميع العديد منها بسهولة التوقيعات في واحد والعديد من المفاتيح العامة في واحد. كما أنها حتمية وتنتج نفس النتيجة لنفس بيانات الإدخال. بفضل هذه الجودة، تعد مجموعات توقيعات BLS في حد ذاتها مفاتيح صالحة، مما يسمح بتنفيذ خيار يقوم فيه المشاركون من عدد M بإنتاج توقيع واحد فقط يكون حتميًا ويمكن التحقق منه علنًا ولا يمكن التنبؤ به حتى يتم فتحه بواسطة Mth مشارك .

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

لذا، إذا كنت تقوم ببناء PVRB على blockchain الخاص بك، فمن المرجح أن ينتهي بك الأمر إلى نظام توقيعات عتبة BLS، حيث تستخدمه العديد من المشاريع بالفعل. على سبيل المثال، دي فينيتي (هنا المعيار الذي ينفذ الدائرة، و هنا مثال على تنفيذ مشاركة سرية يمكن التحقق منها)، أو Keep.network (هنا منارة عشوائية خاصة بهم اصفرار، ولكن مثال العقد الذكي الذي يخدم البروتوكول).

تنفيذ PVRB

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

سأقوم بإدراج العوامل التي يجب عليك مراعاتها عند اختيار PVRB عالي الجودة:

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

على سبيل المثال، تواجه توقيعات عتبة BLS مشكلة كبيرة - قبل البدء في العمل، يجب على المشاركين توزيع المفاتيح على بعضهم البعض، وتنظيم المجموعة التي ستعمل ضمنها العتبة. وهذا يعني أنه سيتعين على جولة واحدة على الأقل من التبادل في شبكة لا مركزية الانتظار، ونظرًا لأن الراند الذي تم إنشاؤه، على سبيل المثال، ضروري في الألعاب، تقريبًا في الوقت الفعلي، فهذا يعني أن تخريب البروتوكول ممكن في هذه المرحلة , وتضيع مزايا مخطط العتبة . هذه المشكلة أبسط بالفعل من المشكلات السابقة، ولكنها لا تزال تتطلب تطوير إجراء منفصل لتشكيل مجموعات العتبة، والتي يجب حمايتها اقتصاديًا، من خلال الودائع وسحب الأموال (التخفيض) من المشاركين الذين لا يتبعون السياسة. بروتوكول. كما أن التحقق من BLS بمستوى مقبول من الأمان لا يتناسب ببساطة، على سبيل المثال، مع معاملة EOS أو Ethereum القياسية - ببساطة لا يوجد وقت كافٍ للتحقق. رمز العقد هو WebAssembly أو EVM، ويتم تنفيذه بواسطة جهاز افتراضي. لم يتم تنفيذ وظائف التشفير محليًا (حتى الآن)، وتعمل بشكل أبطأ بعشرات المرات من مكتبات التشفير التقليدية. لا تلبي العديد من البروتوكولات المتطلبات بناءً على حجم المفتاح ببساطة، على سبيل المثال 1024 و2048 بت لـ RSA، وهو أكبر بـ 4-8 مرات من توقيع المعاملة القياسي في Bitcoin وEthereum.

يلعب أيضًا وجود تطبيقات بلغات برمجة مختلفة دورًا - وهو قليل، خاصة بالنسبة للبروتوكولات الجديدة. يتطلب خيار التكامل في الإجماع كتابة بروتوكول بلغة النظام الأساسي، لذلك سيتعين عليك البحث عن التعليمات البرمجية في Go for geth، وفي Rust for Parity، وفي C++ لـ EOS. سيتعين على الجميع البحث عن كود JavaScript، وبما أن JavaScript والتشفير ليسا صديقين مقربين بشكل خاص، فإن WebAssembly سيساعد، والذي يدعي الآن بالتأكيد أنه معيار الإنترنت المهم التالي.

اختتام

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

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

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

لذلك، عندما تقابل مبرمجًا يصمم عشوائيًا لامركزيًا، كن منتبهًا ومهتمًا، وقدم المساعدة النفسية إذا لزم الأمر :)

المصدر: www.habr.com