مقدمة
function getAbsolutelyRandomNumer() { return 4; // returns absolutely random number! }
كما هو الحال بالنسبة لمفهوم تشفير التشفير الآمن تمامًا ، تحاول بروتوكولات Random Beacon القابلة للتحقق علنيًا (المشار إليها فيما يلي بـ PVRB) فقط الاقتراب من المخطط المثالي قدر الإمكان. في الشبكات الحقيقية بشكلها الخالص ، لا ينطبق ذلك: من الضروري الاتفاق بشكل صارم على جزء واحد ، ويجب أن يكون هناك العديد من الجولات ، ويجب أن تكون جميع الرسائل سريعة تمامًا ويتم تسليمها دائمًا. بالطبع ، في الشبكات الحقيقية هذا ليس كذلك. لذلك ، عند تصميم PVRB للقيام بمهام محددة في مجموعات الرموز الحديثة ، بالإضافة إلى عدم القدرة على التحكم في العشوائية الناتجة وقوة التشفير ، تنشأ العديد من المشكلات المعمارية والتقنية البحتة.
و blockchain نفسه هو ل PVRB أساسا وسيلة اتصال الرسائل = المعاملات. يسمح لك هذا بتجاهل مشكلات الشبكة وتسليم الرسائل ومشكلات البرامج الوسيطة جزئيًا - كل هذه المخاطر تتحملها شبكة لا مركزية ، وتتمثل قيمتها الرئيسية لـ PVRB في عدم القدرة على سحب أو إتلاف معاملة مرسلة بالفعل - وهذا لا يسمح للمشاركين برفض المشاركة في البروتوكول ، ما لم يكن لديهم هجوم إجماع ناجح. هذا المستوى من الأمان مقبول ، لذا يجب أن يكون PVRB مقاومًا للتواطؤ بين المشاركين بنفس الطريقة تمامًا مثل سلسلة blockchain الرئيسية. أيضًا ، يشير هذا إلى أن PVRB يجب أن يكون جزءًا من الإجماع ، إذا وافقت الشبكة على سلسلة الكتل الرئيسية ، فدعها توافق في نفس الوقت على العشوائية الناتجة الصادقة فقط. أو ، PVRB هو مجرد بروتوكول قائم بذاته يتم تنفيذه بواسطة عقد ذكي يعمل بشكل غير متزامن فيما يتعلق بالكتل والكتل. كلتا الطريقتين لها مزاياها وعيوبها ، والاختيار بينهما غير تافه للغاية.
طريقتان لتنفيذ PVRB
دعونا نوضح بمزيد من التفصيل خيارين لتنفيذ PVRB: الإصدار المستقل ، الذي يعمل باستخدام عقد ذكي مستقل عن blockchain ، ومتكامل بالإجماع ، والذي تم تضمينه في البروتوكول الذي بموجبه توافق الشبكة على سلسلة من الكتل والمعاملات المضمنة. في جميع الحالات ، سأضع في اعتبارنا محركات blockchain الشهيرة: Ethereum و EOS ، وكلها مماثلة لها في طريق وضع العقود الذكية ومعالجتها.
عقد مستقل
في هذا النموذج ، يعد PVRB عقدًا ذكيًا يقبل معاملات المنتج العشوائي (يشار إليها فيما يلي باسم RP) ، ويقوم بمعالجتها ، ويجمع النتائج ، ونتيجة لذلك ، فإن قيمة ما يمكن لأي مستخدم من هذا العقد الحصول عليها. قد لا يتم تخزين هذه القيمة مباشرة في العقد ، ولكن يتم تمثيلها فقط من خلال البيانات التي يمكن من خلالها الحصول على قيمة واحدة فقط من العشوائية الناتجة. في هذا المخطط ، RPs هم مستخدمون blockchain ، ويمكن لأي شخص المشاركة في عملية التوليد.
خيار العقد المستقل جيد:
- قابلية النقل (يمكن سحب العقود من blockchain إلى blockchain)
- البساطة في التنفيذ والاختبار (العقود ملائمة للكتابة والاختبار)
- الراحة في تنفيذ المخططات الاقتصادية (من السهل أن تصنع رمزك المميز ، الذي يخدم منطقه أهداف PVRB)
- القدرة على تشغيل في block Blockins القائمة
كما أن لديها عيوب:
- قيود قوية على الموارد في العمليات الحسابية وحجم المعاملات وتخزينها (بمعنى آخر ، cpu / mem / 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 الحق في الحياة ، لكن التنفيذ الذكي للعقود في القيود الحديثة لا يزال محدودًا جدًا في موارد الحوسبة ، وغالبًا ما يكون أي انتقال إلى تشفير خطير أمرًا مستحيلًا. سنحتاج إلى تشفير خطير ، كما سيظهر لاحقًا. على الرغم من أن هذه المشكلة مؤقتة بشكل واضح ، إلا أن الأمر يتطلب تشفيرًا خطيرًا في العقود لحل العديد من المشكلات ، ويظهر تدريجيًا (على سبيل المثال ، عقود النظام لـ zkSNARKs في Ethereum)
يقوم blockchain ، الذي يوفر قناة مراسلة بروتوكول شفافة وموثوق بها ، بذلك لسبب ما. يجب أن يأخذ أي بروتوكول لامركزي في الاعتبار إمكانية حدوث هجوم من Sybil ، ويمكن القيام بأي إجراء من قبل القوات المنسقة في العديد من الحسابات ، لذلك ، عند التصميم ، من الضروري مراعاة قدرات المهاجمين على إنشاء عدد تعسفي من المشاركين في البروتوكول الذين يتصرفون بالتواطؤ.
PVRB وكتلة المتغيرات.
لم أكذب عندما قلت إنه حتى الآن لم يقم أي شخص بتطبيق PVRB جيدًا ، تم التحقق منه بواسطة العديد من تطبيقات المقامرة ، في قيود. أين ، إذن ، من بين العديد من تطبيقات المقامرة في Ethereum و EOS؟ إنه يفاجئني بقدر ما تفعل ، حسنًا ، من أين حصلت على الكثير من الأرقام العشوائية "الثابتة" من بيئة حتمية تمامًا؟
تتمثل الطريقة المفضلة للحصول على عشوائي في blockchain في أخذ نوع من المعلومات "غير المتوقعة" من الكتلة ، وبناءً عليها للقيام عشوائيًا - فقط قم بتخزين ذاكرة مؤقتة واحدة أو أكثر من القيم. مقال جيد حول مشاكل مثل هذه المخططات هنا . يمكنك أخذ بعض القيم "غير المتوقعة" في الكتلة ، على سبيل المثال ، تجزئة الكتلة ، وعدد المعاملات ، وتعقيد الشبكة ، والقيم الأخرى غير المعروفة مسبقًا. ثم قم بتخزينها مؤقتًا ، واحدًا أو أكثر ، ومن الناحية النظرية ، يجب أن تحصل على عشوائي حقيقي. يمكنك أيضًا إضافة إلى wihitepaper أن المخطط الخاص بك "آمن بعد الكم" (نظرًا لوجود وظائف تجزئة مقاومة للكم) :).
ولكن حتى التجزئات الآمنة بعد الكم ليست كافية ، للأسف. السر يكمن في متطلبات PVRB ، وأذكر لهم من مقال سابق:
- يجب أن يكون للنتيجة توزيع موحد ، على أساس التشفير القوي.
- لا يمكن التحكم في أي من أجزاء النتيجة. نتيجة لذلك ، لا يمكن التنبؤ بالنتيجة مسبقًا.
- لا يمكنك تخريب بروتوكول التوليد من خلال عدم المشاركة في البروتوكول أو التحميل الزائد للشبكة مع رسائل الهجوم
- يجب أن يكون كل ما سبق مقاومًا لتواطؤ العدد المسموح به من المشاركين غير الشرفين في البروتوكول (على سبيل المثال ، ثلث المشاركين).
في هذه الحالة ، يتم استيفاء المتطلب 1 فقط ، ولم يتم استيفاء 2. استخلاص قيم غير متوقعة من الكتلة ، نحصل على توزيع موحد وعشوائية جيدة. لكن BP لديها على الأقل القدرة على "نشر كتلة أو لا". وبالتالي ، يمكن لشركة BP على الأقل الاختيار من بين خيارين للعشوائية: "خيارنا" وخيار سينتهي إذا قام شخص آخر بعمل الكتلة. يمكن لشركة BP "التجسس" مقدمًا ما يحدث إذا نشرت كتلة ، وقررت فقط القيام بذلك أم لا. وبالتالي ، من خلال اللعب على سبيل المثال "فردي" أو "أحمر / أسود" في لعبة الروليت ، لا يمكنه نشر كتلة إلا إذا رأى فوزًا. كما أنه يجعل استراتيجية غير صالحة للاستخدام ، على سبيل المثال ، تجزئة كتلة من المستقبل. في هذه الحالة ، يقولون "سيتم استخدام عشوائي ، والذي يتم الحصول عليه عن طريق تجزئة البيانات الحالية وتجزئة الكتلة المستقبلية بارتفاع ، على سبيل المثال ، N + 42 ، حيث N هو ارتفاع الكتلة الحالي. يعمل هذا على تقوية المخطط قليلاً ، ولكنه لا يزال يسمح لشركة BP ، وإن كان ذلك في المستقبل ، باختيار أو تعليق الكتلة أو النشر.
لينة BP في هذه الحالة معقدة ، ولكن ليس كثيرا. إنه فقط عند التحقق من صحة وإدراج معاملة في الكتلة ، يتم إجراء فحص سريع لمعرفة ما إذا كان سيكون هناك مكسب ، وربما اختيار معلمات معاملة واحدة من أجل الحصول على احتمال كبير للفوز. في الوقت نفسه ، يكون الوصول إلى شركة BP ذكية ، أمرًا شبه مستحيل ، في كل مرة يمكنك استخدام عناوين جديدة ، والفوز قليلاً ، دون التسبب في الشك.
وبالتالي فإن الطرق التي تستخدم المعلومات من الكتلة ليست مناسبة لدور التنفيذ العالمي لـ PVRB. في إصدار محدود ، مع القيود المفروضة على حجم الرهانات والقيود المفروضة على عدد اللاعبين و / أو تسجيل KYC (لمنع لاعب واحد من استخدام عناوين متعددة) ، يمكن لهذه المخططات العمل للألعاب الصغيرة ، ولكن لا شيء أكثر من ذلك.
PVRB والالتزام بالكشف.
حسنًا ، بفضل التجزئة ، وعلى الأقل عدم القدرة النسبية للتجزئة للكتلة وغيرها من المتغيرات. إذا قمت بحل مشكلة عمال المناجم العاملين في المقدمة ، يجب أن تحصل على شيء أكثر ملاءمة. دعنا نضيف مستخدمين إلى هذا المخطط - وإن كانوا يؤثرون أيضًا على العشوائية: سيخبرك أي شخص يقدم الدعم الفني بأن أكثر شيء عشوائي في أنظمة تكنولوجيا المعلومات هو إجراءات المستخدم :)
مخطط السذاجة ، عندما يقوم المستخدمون ببساطة بإرسال أرقام عشوائية ، ويتم احتساب النتيجة ، على سبيل المثال ، تجزئة لمجموعها ، ليست مناسبة. في هذه الحالة ، يمكن للاعب الأخير اختيار التحكم العشوائي الخاص به في النتيجة. لذلك ، يتم استخدام نمط الالتزام كشف على نطاق واسع للغاية. يقوم المشاركون أولاً بإرسال التجزئات من التزامهم العشوائي ، ثم فتح العشوائي (عشوائية) أنفسهم. تبدأ مرحلة "الكشف" فقط بعد جمع الالتزام اللازم ، بحيث يمكن للمشاركين أن يرسلوا بالضبط العشوائية التي أرسلوا منها التجزئة سابقًا. الآن نحن أعمى كل هذا بمعلمات الكتلة ، وأفضل من تلك التي أخذت من المستقبل (يمكنك معرفة العشوائية فقط في واحدة من كتل المستقبل) ، وفويلا - أنت مستعد عشوائيًا! الآن ، أي لاعب يؤثر على العشوائية الناتجة ، ويمكنه "هزيمة" BP الخبيثة عن طريق حظره بعشوائه ، غير المعروف سابقًا ، ... يمكنك أيضًا إضافة حماية ضد تخريب البروتوكول عن طريق عدم فتحه في مرحلة الكشف - فقط يتطلب تطبيق مبلغ معين على المعاملة - وديعة تأمين ، والتي سيتم إرجاعها فقط أثناء إجراء الكشف. في هذه الحالة ، فإن القيام بالالتزام وعدم الكشف عنه سيكون أمرًا سيئًا.
لقد كانت محاولة جيدة ، وهذه المخططات موجودة أيضًا في DApps للعبة ، لكن للأسف ، هذا مرة أخرى لا يكفي. الآن ، ليس فقط عامل المناجم ، ولكن أي مشارك في البروتوكول يمكنه التأثير على النتيجة. لا يزال من الممكن التحكم في القيمة نفسها ، بدرجة أقل من التباين ، ومن أجل المال ، ولكن ، كما في حالة عامل المنجم ، إذا كانت نتائج السحب أكثر قيمة من رسوم المشاركة في بروتوكول 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 (مشاركة Fiat-Shamir Secret Sharing) قابلاً للتطبيق بشكله النقي ، فسيكون PVRB غير قابل للقتل. في أبسط إصدار ، قد يبدو البروتوكول كما يلي:
- يولد كل مشارك مشاركته العشوائية ويوزع المشاركات منه على المشاركين الآخرين
- M shares, , ,
- random- PVRB
, , threshold- . , RP , , “last actor”.
, PVRB secret sharing - , , . , , , . - EOS — share : . , proof- , . , verify , block-producer , , verify . , (0.5 ).
— - . proof-, — off-chain , — PVRB.
PVRB threshold signatures
secret sharing, , “threshold”. M N, N, “threshold” . “last actor”, , , . , .
threshold- PVRB — threshold-. threshold-, longread Dash.
BLS (BLS Boneh-Lynn-Shacham, ), — , , BLS , , . . , BLS , , M N , , publicly verifiable, , M- .
threshold BLS signatures BLS - ( ), threshold- . BLS , threshold- “last-actor”, , , , .
, PVRB , BLS threshold signatures, . , DFinity ( , , verifiable secret sharing), Keep.network ( random beacon yellowpaper , -, ).
PVRB
, , PVRB , . , , . PVRB , : CPU, memory, storage, I/O. PVRB — , , . , RP, , proof- , .
, PVRB:
- . PVRB unbiasable, . ,
- “last actor” . PVRB , , RP .
- . PVRB , , RP , ,
- . RP “ , ”. p2p , ,
- . PVRB on-chain , . -,
- liveness . PVRB , RP
- trusted setup . PVRB setup , . . - — ,
- . , , , ..
threshold BLS — , , , threshold. , , , , , , , realtime, , , threshold . , threshold-, , (slashing) , . , BLS , , EOS Ethereum — . — WebAssembly EVM, . (), . , 1024 2048 bit RSA, 4-8 , Bitcoin Ethereum.
— , . , Go geth, Rust Parity, C++ EOS. JavaScript , JavaScript , WebAssembly, -.
استنتاج
, , , , , . , , setup- , whitepaper- , - “ , ”.
, PVRB Haya , threshold BLS signatures, PVRB , - . , : secret sharing random_seed, threshold BLS , . , , , , , , — , , . — , , governance .
PVRB, , , , , , , , , , - . , , .
, , , , :)