كيف يمكن حل مشكلة الأرقام العشوائية على السلسلة؟ Oasis قدمت الحل

ما هي نقطة الضعف القاتلة في البلوكشين؟ الشفافية. كل العقد يمكنها رؤية جميع البيانات، وهذا يجعل وجود أرقام عشوائية حقيقية شبه مستحيل.

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

كيف حلّت Oasis المشكلة؟

استخدمت طريقتين:

الخطوة الأولى: إنشاء RNG على مستوى البلوك

• Sapphire (بيئة تشغيل EVM السرية من Oasis) تحصل على مفتاح سري من مدير المفاتيح
• تشفر RNG بمفتاح قصير الأجل (يتم تدويره كل epoch)، لضمان عدم استرجاع المفاتيح القديمة
• هذه المفاتيح موجودة فقط داخل بيئة التنفيذ الموثوقة TEE، ولا يمكن للمراقبين الخارجيين رؤية حالة RNG
• تستخدم خوارزميات مشتقة من SHA-3 (TupleHash، KMAC256) لمعالجة هذه العشوائية وإنتاج RNG فريد لكل بلوك

الخطوة الثانية: فصل RNG على مستوى المعاملة

• كل معاملة تحتاج رقم عشوائي خاص بها
• يتم اشتقاق RNG على مستوى المعاملة من خلال Merlin transcripts من RNG الجذري
• يتم تخصيص العشوائية ببيانات خاصة بالمعاملة لضمان الخصوصية والعدالة وعدم القدرة على التنبؤ

كيف يستخدمها المطورون؟

بسطر برمجي واحد:

bytes memory randomPad = Sapphire.randomBytes(32, “”);

أو لإنشاء زوج مفاتيح توقيع بواسطة رقم عشوائي:

bytes memory pk; bytes memory sk; (pk, sk) = Sapphire.generateSigningKeyPair( Sapphire.SigningAlg.Ed25519Pure, Sapphire.randomBytes(32, “”) );

المزايا الأساسية

✓ تجريد التعقيد — لا يحتاج المطور لفهم التفاصيل التقنية لـ RNG على البلوكشين ✓ تدوير المفاتيح — مفتاح جديد لكل epoch والمفاتيح القديمة يتم تدميرها تلقائياً ✓ حماية الخصوصية — حالة RNG تظهر فقط داخل TEE ✓ قابلية التدقيق — مبني على VRF وأدوات التشفير، ويمكن تدقيقه

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