تعارف

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

جیسا کہ خفیہ نگاری سے بالکل مضبوط سائفر کے تصور کے ساتھ، حقیقی "عوامی طور پر قابل تصدیق رینڈم بیکن" (اس کے بعد PVRB) پروٹوکول صرف مثالی اسکیم کے زیادہ سے زیادہ قریب جانے کی کوشش کرتے ہیں، کیونکہ حقیقی نیٹ ورکس میں یہ اس کی خالص شکل میں لاگو نہیں ہوتا ہے: ایک بات پر سختی سے متفق ہونا ضروری ہے، بہت سے راؤنڈ ہونے چاہئیں، اور تمام پیغامات بالکل تیز اور ہمیشہ ڈیلیور ہونے چاہئیں۔ یقیناً، حقیقی نیٹ ورکس میں ایسا نہیں ہے۔ لہذا، جدید بلاک چینز میں مخصوص کاموں کے لیے PVRBs کو ڈیزائن کرتے وقت، نتیجے میں پیدا ہونے والی بے ترتیب پن اور کرپٹوگرافک طاقت کو کنٹرول کرنے کے ناممکن ہونے کے علاوہ، بہت سے خالصتاً تعمیراتی اور تکنیکی مسائل پیدا ہوتے ہیں۔

PVRB کے لیے، بلاک چین بنیادی طور پر ایک مواصلاتی ذریعہ ہے جس میں پیغامات = لین دین۔ یہ آپ کو نیٹ ورک کے مسائل، پیغامات کی عدم فراہمی، مڈل ویئر کے ساتھ مسائل سے جزوی طور پر خلاصہ کرنے کی اجازت دیتا ہے - یہ تمام خطرات وکندریقرت نیٹ ورک کے ذریعہ فرض کیے جاتے ہیں، اور PVRB کے لیے اس کی بنیادی قیمت پہلے سے بھیجے گئے لین دین کو منسوخ یا خراب کرنے میں ناکامی ہے۔ شرکاء کو پروٹوکول میں شرکت سے انکار کرنے کی اجازت نہ دیں، جب تک کہ وہ اتفاق رائے پر کامیاب حملہ نہ کریں۔ سیکیورٹی کی یہ سطح قابل قبول ہے، اس لیے PVRB کو شرکاء کی ملی بھگت سے بالکل اسی حد تک مزاحم ہونا چاہیے جس حد تک مین بلاکچین چین ہے۔ اس کے علاوہ، یہ اشارہ کرتا ہے کہ اگر نیٹ ورک مین بلاکچین پر متفق ہے تو PVRB کو اتفاق رائے کا حصہ ہونا چاہیے، یہاں تک کہ اگر وہ صرف منصفانہ نتیجے کے بے ترتیب پر بھی متفق ہو۔ یا، PVRB صرف ایک اسٹینڈ اسٹون پروٹوکول ہے جو ایک سمارٹ کنٹریکٹ کے ذریعے نافذ کیا جاتا ہے جو بلاک چین اور بلاکس کے حوالے سے متضاد طور پر کام کرتا ہے۔ دونوں طریقوں کے اپنے فوائد اور نقصانات ہیں، اور ان کے درمیان انتخاب انتہائی غیر معمولی ہے۔

PVRB کو لاگو کرنے کے دو طریقے

آئیے ہم PVRB کو لاگو کرنے کے لیے دو آپشنز کو مزید تفصیل سے بیان کرتے ہیں - اسٹینڈ اسٹون ورژن، جو بلاکچین سے آزاد ایک سمارٹ کنٹریکٹ کا استعمال کرتے ہوئے کام کرتا ہے، اور پروٹوکول میں بنایا گیا اتفاق رائے سے مربوط ورژن، جس کے مطابق نیٹ ورک بلاکچین پر متفق ہے اور لین دین کو شامل کیا جائے۔ تمام صورتوں میں، میرا مطلب مقبول بلاکچین انجنوں سے ہوگا: Ethereum، EOS، اور ان سے ملتے جلتے تمام وہ جس طرح سے وہ سمارٹ معاہدوں کی میزبانی اور عمل کرتے ہیں۔

اسٹینڈ لون معاہدہ

اس ورژن میں، PVRB ایک سمارٹ کنٹریکٹ ہے جو بے ترتیب پروڈیوسرز کے لین دین کو قبول کرتا ہے (جسے بعد میں RP کہا جاتا ہے)، ان پر کارروائی کرتا ہے، نتائج کو یکجا کرتا ہے، اور نتیجے کے طور پر، ایک خاص قدر پر پہنچتا ہے جو کوئی بھی صارف اس معاہدے سے حاصل کر سکتا ہے۔ اس قدر کو براہ راست معاہدے میں ذخیرہ نہیں کیا جا سکتا ہے، بلکہ اس کی نمائندگی صرف ڈیٹا کے ذریعے کی جا سکتی ہے جس سے نتیجے میں آنے والی بے ترتیب میں سے ایک اور صرف ایک قدر تعین کے لحاظ سے حاصل کی جا سکتی ہے۔ اس اسکیم میں، RPs بلاکچین کے صارف ہیں، اور کسی کو بھی جنریشن کے عمل میں حصہ لینے کی اجازت دی جا سکتی ہے۔

اسٹینڈ اکیلے معاہدے کے ساتھ آپشن اچھا ہے:

• پورٹیبلٹی (معاہدوں کو بلاکچین سے بلاکچین تک گھسیٹا جا سکتا ہے)
• عمل درآمد اور جانچ میں آسانی (معاہدے لکھنے اور جانچنے میں آسان ہیں)
• اقتصادی اسکیموں کو لاگو کرنے میں سہولت (اپنا اپنا ٹوکن بنانا آسان ہے، جس کی منطق PVRB کے مقاصد کو پورا کرتی ہے)
• پہلے سے کام کرنے والے بلاکچینز پر لانچ کرنے کا امکان

اس کے نقصانات بھی ہیں:

• کمپیوٹنگ کے وسائل، لین دین کے حجم اور اسٹوریج پر سخت حدود (دوسرے الفاظ میں، cpu/mem/io)
• معاہدے کے اندر کارروائیوں پر پابندیاں (تمام ہدایات دستیاب نہیں ہیں، بیرونی لائبریریوں کو جوڑنا مشکل ہے)
• لین دین سے زیادہ تیزی سے پیغام رسانی کو منظم کرنے میں ناکامی بلاکچین میں شامل ہے۔

یہ آپشن ایسے PVRB کو لاگو کرنے کے لیے موزوں ہے جسے موجودہ نیٹ ورک پر چلانے کی ضرورت ہے، اس میں پیچیدہ خفیہ نگاری نہیں ہے اور اس میں بڑی تعداد میں تعاملات کی ضرورت نہیں ہے۔

متفقہ مربوط

اس ورژن میں، PVRB بلاکچین نوڈ کوڈ میں لاگو کیا گیا ہے، بلٹ ان یا بلاکچین نوڈس کے درمیان پیغامات کے تبادلے کے ساتھ متوازی طور پر چل رہا ہے۔ پروٹوکول کے نتائج براہ راست تیار کردہ بلاکس میں لکھے جاتے ہیں، اور پروٹوکول پیغامات نوڈس کے درمیان p2p نیٹ ورک پر بھیجے جاتے ہیں۔ چونکہ پروٹوکول کے نتیجے میں وہ نمبر ہوتے ہیں جو بلاکس میں لکھے جاتے ہیں، اس لیے نیٹ ورک کو ان پر اتفاق رائے ہونا چاہیے۔ اس کا مطلب یہ ہے کہ PVRB پیغامات، جیسے لین دین، نوڈس کے ذریعے تصدیق شدہ اور بلاکس میں شامل ہونے چاہئیں تاکہ کوئی بھی نیٹ ورک شریک PVRB پروٹوکول کی تعمیل کی توثیق کر سکے۔ یہ خود بخود ہمیں واضح حل کی طرف لے جاتا ہے - اگر نیٹ ورک کسی بلاک کے بارے میں اتفاق رائے پر اتفاق کرتا ہے اور اس میں لین دین کرتا ہے، تو PVRB کو اتفاق رائے کا حصہ ہونا چاہیے، نہ کہ اسٹینڈ اکیلے پروٹوکول۔ دوسری صورت میں، یہ ممکن ہے کہ ایک بلاک متفقہ نقطہ نظر سے درست ہو، لیکن PVRB پروٹوکول کی پیروی نہیں کی جاتی ہے، اور PVRB نقطہ نظر سے بلاک کو قبول نہیں کیا جا سکتا۔ لہذا اگر "اتفاق سے مربوط" اختیار کا انتخاب کیا جاتا ہے، تو PVRB اتفاق رائے کا ایک اہم حصہ بن جاتا ہے۔

نیٹ ورک اتفاق رائے کی سطح پر PVRB کے نفاذ کو بیان کرتے وقت، کوئی بھی کسی بھی طرح سے حتمی مسائل سے بچ نہیں سکتا۔ حتمییت ایک ایسا طریقہ کار ہے جو تعییناتی اتفاق رائے میں استعمال ہوتا ہے جو ایک بلاک (اور اس کی طرف جانے والی زنجیر) میں بند ہوجاتا ہے جو حتمی ہے اور اسے کبھی نہیں پھینکا جائے گا، یہاں تک کہ اگر کوئی متوازی کانٹا آجائے۔ مثال کے طور پر، Bitcoin میں ایسا کوئی طریقہ کار نہیں ہے - اگر آپ زیادہ پیچیدگی کی زنجیر شائع کرتے ہیں، تو یہ زنجیروں کی لمبائی سے قطع نظر کسی بھی کم پیچیدہ کی جگہ لے لے گا۔ اور EOS میں، مثال کے طور پر، آخری نام نہاد آخری ناقابل واپسی بلاکس ہیں، جو اوسطاً ہر 432 بلاکس (12*21 + 12*15، پری ووٹ + پری کمٹ) ظاہر ہوتے ہیں۔ یہ عمل بنیادی طور پر بلاک پروڈیوسر کے 2/3 دستخطوں کا انتظار کر رہا ہے (اس کے بعد BP کہا جاتا ہے) جب فورکس ظاہر ہوتے ہیں جو آخری LIB سے زیادہ پرانے ہوتے ہیں، تو انہیں آسانی سے ضائع کر دیا جاتا ہے۔ یہ طریقہ کار اس بات کی ضمانت دینا ممکن بناتا ہے کہ لین دین بلاک چین میں شامل ہے اور اسے کبھی واپس نہیں لیا جائے گا، چاہے حملہ آور کے پاس کوئی بھی وسائل کیوں نہ ہوں۔ نیز، حتمی بلاکس وہ بلاکس ہیں جن پر Hyperledger، Tendermint اور دیگر pBFT پر مبنی اتفاق رائے میں 2/3 BP کے ذریعے دستخط کیے گئے ہیں۔ اس کے علاوہ، اتفاق رائے کے حتمی ہونے کو یقینی بنانے کے لیے ایک پروٹوکول بنانا سمجھ میں آتا ہے، کیونکہ یہ بلاکس کی تیاری اور اشاعت کے ساتھ متضاد طور پر کام کر سکتا ہے۔ یہاں ایک اچھا ہے۔ مضمون Ethereum میں حتمی کے بارے میں.

فائنل صارفین کے لیے انتہائی اہم ہے، جو اس کے بغیر اپنے آپ کو "ڈبل اسپنڈ" حملے کا شکار پا سکتے ہیں، جہاں BP "ہولڈ" ہے، اور نیٹ ورک کی جانب سے اچھی لین دین کو "دیکھنے" کے بعد شائع کرتا ہے۔ اگر کوئی حتمی بات نہیں ہے، تو شائع شدہ فورک بلاک کو "خراب" فورک سے دوسرے کے ساتھ "اچھی" لین دین سے بدل دیتا ہے، جس میں وہی فنڈز حملہ آور کے پتے پر منتقل کیے جاتے ہیں۔ PVRB کے معاملے میں، فائنل کے تقاضے اور بھی سخت ہیں، کیونکہ PVRB کے لیے کانٹے بنانے کا مطلب ہے کہ حملہ آور کے لیے بہت سے بے ترتیب آپشنز تیار کرنے کا موقع ہے تاکہ سب سے زیادہ منافع بخش کو شائع کیا جا سکے، اور ممکنہ حملے کے وقت کو محدود کرنا۔ اچھا حل.

لہذا، بہترین آپشن یہ ہے کہ PVRB اور فائنلیت کو ایک پروٹوکول میں یکجا کیا جائے - پھر حتمی شکل دی گئی بلاک = حتمی شکل دی گئی، اور یہ وہی ہے جو ہمیں حاصل کرنے کی ضرورت ہے۔ اب کھلاڑیوں کو N سیکنڈز میں ایک گارنٹی شدہ رینڈم ملے گا، اور اس بات کا یقین ہو سکتا ہے کہ اسے واپس رول کرنا یا اسے دوبارہ چلانا ناممکن ہے۔

اتفاق رائے سے مربوط آپشن اچھا ہے:

• بلاکس کی تیاری کے سلسلے میں غیر مطابقت پذیر عمل درآمد کا امکان - بلاکس معمول کے مطابق تیار کیے جاتے ہیں، لیکن اس کے ساتھ ساتھ، PVRB پروٹوکول کام کر سکتا ہے، جو ہر بلاک کے لیے بے ترتیب پن پیدا نہیں کرتا ہے۔
• سمارٹ معاہدوں پر عائد پابندیوں کے بغیر، بھاری خفیہ نگاری کو بھی نافذ کرنے کی صلاحیت
• لین دین سے زیادہ تیزی سے پیغامات کے تبادلے کو منظم کرنے کی صلاحیت بلاکچین میں شامل ہے، مثال کے طور پر، پروٹوکول کا حصہ نیٹ ورک پر پیغامات کی تقسیم کے بغیر نوڈس کے درمیان کام کر سکتا ہے۔

اس کے نقصانات بھی ہیں:

• جانچ اور ترقی میں مشکلات - آپ کو نیٹ ورک کی غلطیوں، گمشدہ نوڈس، نیٹ ورک ہارڈ فورکس کی تقلید کرنی ہوگی۔
• نفاذ کی غلطیوں کے لیے نیٹ ورک ہارڈ فورک کی ضرورت ہوتی ہے۔

PVRB کو لاگو کرنے کے دونوں طریقوں میں زندگی کا حق ہے، لیکن جدید بلاک چینز میں سمارٹ معاہدوں پر عمل درآمد کمپیوٹنگ کے وسائل میں اب بھی کافی محدود ہے، اور سنگین خفیہ نگاری کی طرف منتقلی اکثر ناممکن ہے۔ اور ہمیں سنگین خفیہ نگاری کی ضرورت ہوگی، جیسا کہ ذیل میں دکھایا جائے گا۔ اگرچہ یہ مسئلہ واضح طور پر عارضی ہے، بہت سے مسائل کو حل کرنے کے لیے معاہدوں میں سنجیدہ خفیہ نگاری کی ضرورت ہے، اور یہ بتدریج ظاہر ہو رہا ہے (مثال کے طور پر، Ethereum میں zkSNARKs کے لیے نظام کے معاہدے)

بلاکچین، جو ایک شفاف اور قابل اعتماد پروٹوکول میسجنگ چینل فراہم کرتا ہے، مفت میں ایسا نہیں کرتا ہے۔ کسی بھی وکندریقرت پروٹوکول کو سائبیل حملے کے امکان کو مدنظر رکھنا چاہیے؛ کوئی بھی کارروائی متعدد اکاؤنٹس کی مشترکہ قوتوں کے ذریعے کی جا سکتی ہے، اس لیے، ڈیزائن کرتے وقت، حملہ آوروں کی قابلیت کو مدنظر رکھنا ضروری ہے کہ وہ پروٹوکول کی صوابدیدی تعداد میں تشکیل دے سکیں۔ شراکت دار ملی بھگت سے کام کر رہے ہیں۔

PVRB اور بلاک متغیرات۔

میں نے جھوٹ نہیں بولا جب میں نے کہا کہ کسی نے ابھی تک ایک اچھا PVRB نافذ نہیں کیا ہے، جس کا تجربہ بہت سی جوئے کی ایپلی کیشنز کے ذریعے کیا گیا ہے، بلاک چینز میں۔ پھر Ethereum اور EOS پر جوئے کی اتنی زیادہ درخواستیں کہاں سے آتی ہیں؟ یہ مجھے اتنا ہی حیران کرتا ہے جتنا کہ یہ آپ کو حیران کرتا ہے، انہیں مکمل طور پر متعین ماحول میں اتنے "مسلسل" بے ترتیب کہاں سے ملے؟

بلاکچین میں بے ترتیب ہونے کا پسندیدہ طریقہ یہ ہے کہ بلاک سے کسی قسم کی "غیر متوقع" معلومات لیں اور اس کی بنیاد پر بے ترتیب معلومات بنائیں - بس ایک یا زیادہ اقدار کو ہیش کرکے۔ ایسی اسکیموں کے مسائل کے بارے میں اچھا مضمون یہاں. آپ بلاک میں "غیر متوقع" قدروں میں سے کوئی بھی لے سکتے ہیں، مثال کے طور پر، بلاک ہیش، لین دین کی تعداد، نیٹ ورک کی پیچیدگی، اور دیگر قدریں جو پہلے سے نامعلوم ہیں۔ پھر ان کو ہیش کریں، ایک یا زیادہ، اور، تھیوری میں، آپ کو ایک حقیقی بے ترتیب ملنا چاہیے۔ یہاں تک کہ آپ وائٹ پیپر میں یہ بھی شامل کرسکتے ہیں کہ آپ کی اسکیم "پوسٹ کوانٹم سیکیور" ہے (چونکہ کوانٹم پروف ہیش فنکشنز ہیں :))۔

لیکن کوانٹم کے بعد کے محفوظ ہیشز بھی کافی نہیں ہیں، افسوس۔ راز PVRB کے تقاضوں میں مضمر ہے، میں آپ کو پچھلے مضمون سے ان کی یاد دلاتا ہوں:

1. نتیجہ میں ثابت شدہ طور پر یکساں تقسیم ہونا ضروری ہے، یعنی ثابت شدہ مضبوط خفیہ نگاری پر مبنی ہونا چاہیے۔
2. نتیجے کے کسی بھی بٹس کو کنٹرول کرنا ممکن نہیں ہے۔ نتیجے کے طور پر، نتائج کی پیشگی پیش گوئی نہیں کی جا سکتی.
3. آپ پروٹوکول میں حصہ نہ لے کر یا حملے کے پیغامات کے ساتھ نیٹ ورک کو اوور لوڈ کر کے جنریشن پروٹوکول کو سبوتاژ نہیں کر سکتے۔
4. مندرجہ بالا سبھی کو بے ایمان پروٹوکول شرکاء کی ایک جائز تعداد کی ملی بھگت کے خلاف مزاحم ہونا چاہیے (مثال کے طور پر، 1/3 شرکاء)۔

اس صورت میں، صرف ضرورت 1 پوری ہوتی ہے، اور ضرورت 2 پوری نہیں ہوتی ہے۔ بلاک سے غیر متوقع قدروں کو ہیش کرنے سے، ہمیں یکساں تقسیم اور اچھے رینڈم ملیں گے۔ لیکن بی پی کے پاس کم از کم یہ اختیار ہے کہ "بلاک شائع کریں یا نہیں۔" اس طرح، بی پی کم از کم دو بے ترتیب آپشنز میں سے انتخاب کر سکتا ہے: "اپنا" اور ایک جو نکلے گا اگر کوئی اور بلاک بناتا ہے۔ BP پہلے سے "اسنوپ" کر سکتا ہے اگر وہ ایک بلاک شائع کرتا ہے تو کیا ہوگا، اور اسے کرنے یا نہ کرنے کا فیصلہ کرتا ہے۔ اس طرح، کھیلتے وقت، مثال کے طور پر، رولیٹی میں "Even-odd" یا "red/black"، وہ صرف اس صورت میں بلاک شائع کر سکتا ہے جب اسے جیت نظر آئے۔ یہ استعمال کرنے کی حکمت عملی کو بھی بناتا ہے، مثال کے طور پر، ایک بلاک ہیش "مستقبل سے" ناقابل عمل۔ اس معاملے میں، وہ کہتے ہیں کہ "رینڈم استعمال کیا جائے گا، جو موجودہ ڈیٹا اور مستقبل کے بلاک کی اونچائی کے ہیش کو ہیش کرکے حاصل کیا جاتا ہے، مثال کے طور پر، N + 42، جہاں N موجودہ بلاک کی اونچائی ہے۔ یہ اسکیم کو تھوڑا مضبوط کرتا ہے، لیکن پھر بھی بی پی کو اجازت دیتا ہے، اگرچہ مستقبل میں، یہ انتخاب کر سکتا ہے کہ آیا بلاک رکھنا ہے یا شائع کرنا ہے۔

اس معاملے میں بی پی سافٹ ویئر زیادہ پیچیدہ ہو جاتا ہے، لیکن زیادہ نہیں۔ بس، ایک بلاک میں ٹرانزیکشن کی توثیق کرتے وقت اور اس کو شامل کرتے وقت، یہ دیکھنے کے لیے فوری جانچ پڑتال کی جاتی ہے کہ آیا جیت ہوگی، اور، ممکنہ طور پر، جیتنے کے زیادہ امکانات حاصل کرنے کے لیے ایک لین دین کے پیرامیٹرز کا انتخاب۔ ایک ہی وقت میں، ایسی ہیرا پھیری کے لیے اسمارٹ بی پی کو پکڑنا تقریباً ناممکن ہے؛ ہر بار آپ نئے پتے استعمال کر سکتے ہیں اور شکوک پیدا کیے بغیر تھوڑا تھوڑا جیت سکتے ہیں۔

لہذا بلاک سے معلومات کو استعمال کرنے کے طریقے PVRB کے عالمگیر نفاذ کے طور پر موزوں نہیں ہیں۔ ایک محدود ورژن میں، شرط کے سائز پر پابندی، کھلاڑیوں کی تعداد پر پابندی اور/یا KYC رجسٹریشن (ایک کھلاڑی کو متعدد پتے استعمال کرنے سے روکنے کے لیے) کے ساتھ، یہ اسکیمیں چھوٹے گیمز کے لیے کام کر سکتی ہیں، لیکن اس سے زیادہ کچھ نہیں۔

PVRB اور عزم ظاہر کرنا۔

ٹھیک ہے، ہیشنگ کا شکریہ اور کم از کم بلاک ہیش اور دیگر متغیرات کی نسبتاً غیر متوقع صلاحیت۔ اگر آپ سامنے سے چلنے والے کان کنوں کا مسئلہ حل کرتے ہیں، تو آپ کو کچھ زیادہ مناسب ملنا چاہیے۔ آئیے صارفین کو اس اسکیم میں شامل کریں - انہیں بے ترتیب ہونے پر بھی اثر انداز ہونے دیں: کوئی بھی تکنیکی معاون ملازم آپ کو بتائے گا کہ آئی ٹی سسٹمز میں سب سے زیادہ بے ترتیب چیز صارفین کے اعمال ہیں :)

ایک سادہ اسکیم، جب صارفین محض بے ترتیب نمبر بھیجتے ہیں اور نتیجہ کا حساب لگایا جاتا ہے، مثال کے طور پر، ان کی رقم کا ایک ہیش، مناسب نہیں ہے۔ اس صورت میں، آخری کھلاڑی، اپنا بے ترتیب انتخاب کرکے، اس بات پر قابو پا سکتا ہے کہ نتیجہ کیا نکلے گا۔ یہی وجہ ہے کہ بہت بڑے پیمانے پر کمٹ-ریویئل پیٹرن استعمال کیا جاتا ہے۔ شرکاء پہلے اپنے رینڈم (کمیٹ) سے ہیش بھیجتے ہیں، اور پھر بے ترتیب خود کھولتے ہیں (انکشاف کرتے ہیں)۔ "ظاہر" کا مرحلہ صرف ضروری وعدوں کے جمع ہونے کے بعد شروع ہوتا ہے، لہذا شرکاء بالکل وہی بے ترتیب ہیش بھیج سکتے ہیں جہاں سے انہوں نے پہلے بھیجا تھا۔ اب آئیے ان سب کو ایک بلاک کے پیرامیٹرز کے ساتھ ملاتے ہیں، اور مستقبل سے لیے گئے ایک سے بہتر (بے ترتیب پن صرف مستقبل کے بلاکس میں سے ایک میں پایا جا سکتا ہے)، اور voila - بے ترتیب پن تیار ہے! اب کوئی بھی کھلاڑی نتیجے میں ہونے والی بے ترتیب پن کو متاثر کرتا ہے، اور بدنیتی پر مبنی بی پی کو اپنے، پہلے سے نامعلوم، بے ترتیب پن سے اوور رائیڈ کر کے اسے "شکست" دے سکتا ہے... آپ پروٹوکول کو ظاہر کرنے کے مرحلے پر نہ کھول کر اسے سبوتاژ کرنے کے خلاف تحفظ بھی شامل کر سکتے ہیں - بس لین دین کرتے وقت ایک مخصوص رقم کو منسلک کرنے کی ضرورت سے - ایک سیکورٹی ڈپازٹ، جو صرف ظاہر کرنے کے طریقہ کار کے دوران واپس کیا جائے گا۔ اس صورت میں ارتکاب کرنا اور ظاہر نہ کرنا بے فائدہ ہوگا۔

یہ ایک اچھی کوشش تھی، اور اس طرح کی اسکیمیں گیمنگ DApps میں بھی موجود ہیں، لیکن افسوس، یہ دوبارہ کافی نہیں ہے۔ اب نہ صرف کان کن، بلکہ پروٹوکول میں شریک کوئی بھی نتیجہ پر اثر انداز ہو سکتا ہے۔ کم تغیر کے ساتھ اور قیمت پر خود ہی قدر کو کنٹرول کرنا اب بھی ممکن ہے، لیکن، جیسا کہ کان کن کے معاملے میں، اگر ڈرائنگ کے نتائج PVRB پروٹوکول میں شرکت کی فیس سے زیادہ قیمتی ہیں، تو بے ترتیب پروڈیوسر (RP) فیصلہ کر سکتا ہے کہ آیا ظاہر کرنا ہے اور پھر بھی کم از کم دو بے ترتیب اختیارات میں سے انتخاب کر سکتا ہے۔
لیکن ان لوگوں کو سزا دینا ممکن ہو گیا جو ارتکاب کرتے ہیں اور ظاہر نہیں کرتے، اور یہ سکیم کام آئے گی۔ اس کی سادگی ایک سنجیدہ فائدہ ہے - زیادہ سنجیدہ پروٹوکول کے لیے بہت زیادہ طاقتور حساب کی ضرورت ہوتی ہے۔

PVRB اور تعییناتی دستخط۔

RP کو ​​ایک چھدم بے ترتیب نمبر فراہم کرنے پر مجبور کرنے کا ایک اور طریقہ ہے جس پر وہ اثر انداز نہیں ہو سکتا اگر اسے "پری امیج" فراہم کیا جاتا ہے - یہ ایک تعییناتی دستخط ہے۔ ایسا دستخط، مثال کے طور پر، RSA ہے، اور ECS نہیں ہے۔ اگر RP کے پاس چابیاں کا ایک جوڑا ہے: RSA اور ECC، اور وہ اپنی نجی کلید کے ساتھ ایک خاص قدر پر دستخط کرتا ہے، تو RSA کی صورت میں اسے ایک اور صرف ایک دستخط ملے گا، اور ECS کی صورت میں وہ کسی بھی نمبر کو تیار کر سکتا ہے۔ مختلف درست دستخط۔ اس کی وجہ یہ ہے کہ ECS دستخط بناتے وقت، ایک بے ترتیب نمبر استعمال کیا جاتا ہے، جسے دستخط کنندہ نے منتخب کیا ہے، اور اسے کسی بھی طرح سے منتخب کیا جا سکتا ہے، جس سے دستخط کنندہ کو کئی دستخطوں میں سے ایک کو منتخب کرنے کا موقع ملتا ہے۔ RSA کی صورت میں: "ایک ان پٹ ویلیو" + "ایک کلیدی جوڑی" = "ایک دستخط"۔ یہ پیشین گوئی کرنا ناممکن ہے کہ دوسرے RP کو ​​کیا دستخط ملے گا، لہذا ایک PVRB کو متعدد شرکاء کے RSA دستخطوں کو ملا کر ترتیب دیا جا سکتا ہے جنہوں نے ایک ہی قیمت پر دستخط کیے تھے۔ مثال کے طور پر، گزشتہ بے ترتیب. یہ اسکیم بہت سارے وسائل بچاتی ہے، کیونکہ دستخط دونوں پروٹوکول کے مطابق درست رویے کی تصدیق اور بے ترتیب ہونے کا ذریعہ ہیں۔

تاہم، متعین دستخطوں کے باوجود، اسکیم اب بھی "آخری اداکار" کے مسئلے کا شکار ہے۔ آخری شرکت کنندہ اب بھی فیصلہ کر سکتا ہے کہ دستخط شائع کرنا ہے یا نہیں، اس طرح نتیجہ کو کنٹرول کیا جا سکتا ہے۔ آپ اسکیم میں ترمیم کر سکتے ہیں، اس میں بلاک ہیشز شامل کر سکتے ہیں، راؤنڈ بنا سکتے ہیں تاکہ نتیجہ کا پیشگی اندازہ نہ لگایا جا سکے، لیکن یہ تمام تکنیکیں، یہاں تک کہ بہت سی تبدیلیوں کو بھی مدنظر رکھتے ہوئے، اجتماعی طور پر ایک شریک کے اثر و رسوخ کے مسئلے کو حل نہ ہونے کے برابر چھوڑ دیتی ہیں۔ ایک ناقابل اعتماد ماحول کا نتیجہ ہے اور صرف اقتصادی اور وقت کی پابندیوں کے تحت کام کر سکتا ہے. اس کے علاوہ، RSA کیز (1024 اور 2048 بٹس) کا سائز کافی بڑا ہے، اور بلاک چین ٹرانزیکشنز کا سائز ایک انتہائی اہم پیرامیٹر ہے۔ بظاہر مسئلہ کو حل کرنے کا کوئی آسان طریقہ نہیں ہے، آئیے آگے بڑھتے ہیں۔

PVRB اور خفیہ شیئرنگ اسکیمیں

خفیہ نگاری میں، ایسی اسکیمیں ہیں جو نیٹ ورک کو ایک اور صرف ایک PVRB قدر پر متفق ہونے کی اجازت دے سکتی ہیں، جبکہ ایسی اسکیمیں کچھ شرکاء کے کسی بھی بدنیتی پر مبنی عمل کے خلاف مزاحم ہوتی ہیں۔ ایک مفید پروٹوکول جس سے اپنے آپ کو واقف کرنے کے قابل ہے وہ شامیر کی خفیہ شیئرنگ اسکیم ہے۔ یہ ایک راز (مثال کے طور پر، ایک خفیہ کلید) کو کئی حصوں میں تقسیم کرتا ہے، اور ان حصوں کو N شرکاء میں تقسیم کرتا ہے۔ راز کو اس طرح تقسیم کیا گیا ہے کہ N میں سے M حصے اسے بازیافت کرنے کے لیے کافی ہیں، اور یہ کوئی بھی M حصے ہو سکتے ہیں۔ اگر انگلیوں پر، پھر کسی نامعلوم فنکشن کا گراف رکھتے ہوئے، شرکاء گراف پر پوائنٹس کا تبادلہ کرتے ہیں، اور M پوائنٹس حاصل کرنے کے بعد، پورے فنکشن کو بحال کیا جا سکتا ہے۔
میں ایک اچھی وضاحت دی گئی ہے۔ وکیپیڈیا لیکن عملی طور پر اس کے ساتھ کھیلنا آپ کے دماغ میں پروٹوکول کھیلنے کے لیے مفید ہے۔ ڈیمو صفحہ

اگر FSSS (Fiat-Shamir Secret Sharing) اسکیم اس کی خالص شکل میں لاگو ہوتی، تو یہ ایک ناقابل تباہی PVRB ہوگی۔ اس کی آسان ترین شکل میں، پروٹوکول اس طرح نظر آسکتا ہے:

• ہر شریک اپنا اپنا بے ترتیب تخلیق کرتا ہے اور اس سے شیئر دوسرے شرکاء میں تقسیم کرتا ہے
• ہر شریک دوسرے شرکاء کے رازوں کا اپنا حصہ ظاہر کرتا ہے۔
• اگر کسی شریک کے پاس M سے زیادہ شیئرز ہیں، تو اس شرکت کنندہ کی تعداد کا حساب لگایا جا سکتا ہے، اور یہ منفرد ہوگا، قطع نظر ظاہر کردہ شرکاء کے سیٹ سے
• انکشاف شدہ بے ترتیبوں کا مجموعہ مطلوبہ PVRB ہے۔

یہاں، ایک انفرادی شریک پروٹوکول کے نتائج کو مزید متاثر نہیں کرتا، سوائے ان صورتوں کے جہاں بے ترتیب انکشاف کی حد کا حصول صرف اس پر منحصر ہو۔ لہذا، یہ پروٹوکول، اگر پروٹوکول پر کام کرنے والے RPs کا مطلوبہ تناسب موجود ہے اور دستیاب ہے، کام کرتا ہے، کرپٹوگرافک طاقت کے تقاضوں کو نافذ کرتا ہے، اور "آخری اداکار" کے مسئلے کے خلاف مزاحم ہوتا ہے۔

یہ ایک مثالی آپشن ہو سکتا ہے، اس PVRB سکیم کی بنیاد Fiat-Shamir خفیہ اشتراک پر ہے مثال کے طور پر اس مضمون لیکن، جیسا کہ اوپر بتایا گیا ہے، اگر آپ اسے بلاکچین میں لاگو کرنے کی کوشش کرتے ہیں، تو تکنیکی حدود ظاہر ہوتی ہیں۔ یہاں EOS سمارٹ کنٹریکٹ میں پروٹوکول کے ٹیسٹ کے نفاذ کی ایک مثال ہے اور اس کا سب سے اہم حصہ - شائع شدہ حصہ لینے والے کی جانچ کرنا: کوڈ. آپ کوڈ سے دیکھ سکتے ہیں کہ ثبوت کی توثیق کے لیے کئی اسکیلر ضربوں کی ضرورت ہوتی ہے، اور استعمال کیے گئے نمبر بہت بڑے ہیں۔ یہ سمجھنا چاہیے کہ بلاکچینز میں، تصدیق اس وقت ہوتی ہے جب بلاک پروڈیوسر ٹرانزیکشن پر کارروائی کرتا ہے، اور عام طور پر، کسی بھی شریک کو آسانی سے پروٹوکول کی درستگی کی تصدیق کرنی چاہیے، اس لیے تصدیق کے فنکشن کی رفتار کے تقاضے بہت سنگین ہیں۔ . اس آپشن میں، آپشن غیر موثر نکلا، کیونکہ تصدیق لین دین کی حد (0.5 سیکنڈ) میں فٹ نہیں تھی۔

عام طور پر، بلاکچین میں کسی بھی جدید کرپٹوگرافک اسکیموں کے استعمال کے لیے تصدیق کی کارکردگی سب سے اہم تقاضوں میں سے ایک ہے۔ ثبوت بنانا، پیغامات تیار کرنا - ان طریقہ کار کو آف چین لیا جا سکتا ہے اور اعلیٰ کارکردگی والے کمپیوٹرز پر انجام دیا جا سکتا ہے، لیکن تصدیق کو نظرانداز نہیں کیا جا سکتا - PVRB کے لیے یہ ایک اور اہم ضرورت ہے۔

PVRB اور حد کے دستخط

خفیہ اشتراک کی اسکیم سے واقف ہونے کے بعد، ہم نے کلیدی لفظ "تھریش ہولڈ" کے ذریعے متحد پروٹوکولز کی ایک پوری کلاس دریافت کی۔ جب کچھ معلومات کے افشاء کے لیے N میں سے ایم ایماندار شرکاء کی شرکت کی ضرورت ہوتی ہے، اور ایماندار شرکاء کا سیٹ N کا من مانی سب سیٹ ہو سکتا ہے، ہم "تھریش ہولڈ" اسکیموں کی بات کرتے ہیں۔ یہ وہی ہیں جو ہمیں "آخری اداکار" کے مسئلے سے نمٹنے کی اجازت دیتے ہیں، اب اگر حملہ آور اپنے راز کے حصے کو ظاہر نہیں کرتا ہے، تو دوسرا، ایماندار شریک اس کے لیے کرے گا۔ یہ اسکیمیں ایک اور صرف ایک معنی پر معاہدے کی اجازت دیتی ہیں، چاہے کچھ شرکاء کے ذریعہ پروٹوکول کو سبوتاژ کیا گیا ہو۔

ڈیٹرمنسٹک دستخطوں اور تھریشولڈ اسکیموں کے امتزاج نے PVRB کو لاگو کرنے کے لیے ایک بہت ہی آسان اور امید افزا اسکیم تیار کرنا ممکن بنایا - یہ ڈیٹرمنسٹک تھریشولڈ دستخط ہیں۔ یہاں مضمون تھریشولڈ دستخطوں کے مختلف استعمال کے بارے میں، اور یہاں ایک اور اچھا ہے۔ طویل پڑھنا ڈیش سے

آخری مضمون BLS دستخطوں کی وضاحت کرتا ہے (BLS کا مطلب ہے Boneh-Lynn-Shacham، یہاں مضمون)، جو پروگرامرز کے لیے بہت اہم اور انتہائی آسان معیار کا حامل ہے - عوامی، خفیہ، عوامی کلیدوں اور BLS دستخطوں کو ریاضی کی سادہ کارروائیوں کا استعمال کرتے ہوئے ایک دوسرے کے ساتھ جوڑا جا سکتا ہے، جب کہ ان کے مجموعے درست کلیدیں اور دستخط رہتے ہیں، جس سے آپ آسانی سے بہت سی چیزوں کو جمع کر سکتے ہیں۔ ایک میں دستخط اور ایک میں کئی عوامی چابیاں۔ وہ تعیین پسند بھی ہیں اور ایک ہی ان پٹ ڈیٹا کے لیے ایک ہی نتیجہ پیدا کرتے ہیں۔ اس معیار کی بدولت، BLS دستخطوں کے امتزاج بذات خود ایک درست کلید ہیں، جو ایک ایسے آپشن کو نافذ کرنے کی اجازت دیتا ہے جس میں N کے شرکاء ایک اور صرف ایک دستخط تیار کرتے ہیں جو تعییناتی، عوامی طور پر قابل تصدیق، اور غیر متوقع ہے جب تک کہ اسے Mth کے ذریعہ کھولا نہیں جاتا ہے۔ شریک

تھریشولڈ BLS دستخطوں والی اسکیم میں، ہر شریک BLS کا استعمال کرتے ہوئے کسی چیز پر دستخط کرتا ہے (مثال کے طور پر، پچھلا بے ترتیب)، اور عام حد کا دستخط مطلوبہ بے ترتیب ہوتا ہے۔ BLS دستخطوں کی خفیہ خصوصیات بے ترتیب معیار کے تقاضوں کو پورا کرتی ہیں، حد کا حصہ "آخری اداکار" سے تحفظ فراہم کرتا ہے، اور چابیاں کا منفرد امتزاج بہت سے مزید دلچسپ الگورتھم کو لاگو کرنا ممکن بناتا ہے جو کہ اجازت دیتے ہیں، مثال کے طور پر، پروٹوکول پیغامات کی موثر جمع .

لہذا، اگر آپ اپنے بلاکچین پر PVRB بنا رہے ہیں، تو آپ کا اختتام غالباً BLS تھریشولڈ دستخطی اسکیم کے ساتھ ہوگا، کئی پروجیکٹس پہلے ہی اسے استعمال کر رہے ہیں۔ مثال کے طور پر، DFinity (یہاں بینچ مارک جو سرکٹ کو لاگو کرتا ہے، اور یہاں مثال کے طور پر قابل تصدیق خفیہ اشتراک کا نفاذ)، یا Keep.network (یہاں ان کا بے ترتیب بیکن ہے پیلا کاغذاور یہاں مثال کے طور پر پروٹوکول کی خدمت کرنے والا سمارٹ معاہدہ)۔

PVRB کا نفاذ

بدقسمتی سے، ہمیں ابھی تک PVRB بلاکچینز میں لاگو کیا گیا کوئی تیار شدہ پروٹوکول نظر نہیں آتا جس نے اس کی حفاظت اور استحکام کو ثابت کیا ہو۔ اگرچہ پروٹوکول خود تیار ہیں، تکنیکی طور پر انہیں موجودہ حل پر لاگو کرنا آسان نہیں ہے۔ مرکزی نظاموں کے لیے، PVRB کا کوئی مطلب نہیں ہے، اور وکندریقرت والے تمام کمپیوٹنگ وسائل میں سختی سے محدود ہیں: CPU، میموری، اسٹوریج، I/O۔ PVRB کو ڈیزائن کرنا مختلف پروٹوکولز کا مجموعہ ہے تاکہ کچھ ایسا بنایا جا سکے جو کم از کم کچھ قابل عمل بلاکچین کی تمام ضروریات کو پورا کرے۔ ایک پروٹوکول زیادہ مؤثر طریقے سے حساب کرتا ہے، لیکن RPs کے درمیان زیادہ پیغامات کی ضرورت ہوتی ہے، جب کہ دوسرے کو بہت کم پیغامات کی ضرورت ہوتی ہے، لیکن ثبوت بنانا ایک ایسا کام ہوسکتا ہے جس میں دسیوں منٹ، یا گھنٹے بھی لگتے ہیں۔

میں ان عوامل کی فہرست دوں گا جن پر آپ کو معیار PVRB کا انتخاب کرتے وقت غور کرنا ہوگا:

• کرپٹوگرافک طاقت. آپ کا PVRB سختی سے غیرجانبدار ہونا چاہیے، جس میں ایک بٹ کو بھی کنٹرول کرنے کی صلاحیت نہ ہو۔ کچھ اسکیموں میں ایسا نہیں ہوتا ہے، اس لیے کرپٹوگرافر کو کال کریں۔
• "آخری اداکار" کا مسئلہ. آپ کا PVRB ان حملوں کے خلاف مزاحم ہونا چاہیے جہاں ایک یا زیادہ RPs کو کنٹرول کرنے والا حملہ آور دو نتائج میں سے کسی ایک کا انتخاب کر سکتا ہے۔
• پروٹوکول تخریب کاری کا مسئلہ. آپ کا PVRB ان حملوں کے خلاف مزاحم ہونا چاہیے جہاں ایک یا ایک سے زیادہ RPs کو کنٹرول کرنے والا حملہ آور فیصلہ کرتا ہے کہ آیا بے ترتیب ہونا ہے یا نہیں اور اس کی ضمانت دی جا سکتی ہے یا اس پر اثر انداز ہونے کے امکان کے ساتھ۔
• پیغامات کی تعداد کا مسئلہ. آپ کے RPs کو بلاکچین کو کم از کم پیغامات بھیجنے چاہئیں اور ممکنہ حد تک مطابقت پذیر کارروائیوں سے گریز کرنا چاہیے جیسے کہ "میں نے کچھ معلومات بھیجی ہیں، میں کسی مخصوص شریک کے جواب کا انتظار کر رہا ہوں۔" p2p نیٹ ورکس میں، خاص طور پر جغرافیائی طور پر منتشر، آپ کو فوری جواب پر اعتماد نہیں کرنا چاہیے۔
• کمپیوٹیشنل پیچیدگی کا مسئلہ. PVRB آن چین کے کسی بھی مرحلے کی تصدیق انتہائی آسان ہونی چاہیے، کیونکہ یہ نیٹ ورک کے تمام کلائنٹس کے ذریعے انجام دیا جاتا ہے۔ اگر عمل درآمد سمارٹ کنٹریکٹ کا استعمال کرتے ہوئے کیا جاتا ہے، تو رفتار کی ضروریات بہت سخت ہیں۔
• رسائی اور زندہ رہنے کا مسئلہ. آپ کے PVRB کو ایسے حالات میں لچک پیدا کرنے کی کوشش کرنی چاہیے جہاں نیٹ ورک کا کچھ حصہ کچھ وقت کے لیے دستیاب نہ ہو اور RP کا کچھ حصہ کام کرنا چھوڑ دے
• قابل اعتماد سیٹ اپ اور ابتدائی کلیدی تقسیم کا مسئلہ. اگر آپ کا PVRB پروٹوکول کا بنیادی سیٹ اپ استعمال کرتا ہے، تو یہ ایک الگ بڑی اور سنجیدہ کہانی ہے۔ یہاں مثال کے طور پر. اگر شرکاء کو پروٹوکول شروع کرنے سے پہلے ایک دوسرے کو اپنی چابیاں بتانا ضروری ہیں، تو یہ بھی ایک مسئلہ ہے اگر شرکاء کی ساخت تبدیل ہو جاتی ہے۔
• ترقیاتی مسائل. مطلوبہ زبانوں میں لائبریریوں کی دستیابی، ان کی حفاظت اور کارکردگی، پبلسٹی، پیچیدہ ٹیسٹ وغیرہ۔

مثال کے طور پر، تھریشولڈ BLS دستخطوں میں ایک اہم مسئلہ ہے - کام شروع کرنے سے پہلے، شرکاء کو ایک دوسرے کو چابیاں تقسیم کرنی چاہئیں، ایک گروپ کو منظم کرنا چاہیے جس کے اندر حد کام کرے گی۔ اس کا مطلب یہ ہے کہ وکندریقرت نیٹ ورک میں تبادلے کے کم از کم ایک دور کا انتظار کرنا پڑے گا، اور یہ دیکھتے ہوئے کہ پیدا ہونے والا رینڈ، مثال کے طور پر، گیمز میں ضروری ہے، تقریباً حقیقی وقت میں، اس کا مطلب ہے کہ اس مرحلے پر پروٹوکول کو سبوتاژ کرنا ممکن ہے۔ , اور تھریشولڈ اسکیم کے فوائد ختم ہو گئے ہیں۔ یہ مسئلہ پہلے کے مقابلے میں پہلے سے ہی آسان ہے، لیکن پھر بھی تھریشولڈ گروپس کی تشکیل کے لیے ایک الگ طریقہ کار کی ترقی کی ضرورت ہے، جس کی پیروی نہ کرنے والے شرکاء سے جمع اور فنڈز کی واپسی (کمی) کے ذریعے اقتصادی طور پر محفوظ ہونا پڑے گا۔ پروٹوکول. اس کے علاوہ، قابل قبول سطح کی حفاظت کے ساتھ BLS کی توثیق صرف فٹ نہیں ہوتی، مثال کے طور پر، معیاری EOS یا Ethereum ٹرانزیکشن میں - تصدیق کے لیے کافی وقت نہیں ہے۔ کنٹریکٹ کوڈ WebAssembly یا EVM ہے، جسے ایک ورچوئل مشین کے ذریعے عمل میں لایا جاتا ہے۔ کرپٹوگرافک فنکشنز مقامی طور پر لاگو نہیں کیے گئے ہیں (ابھی تک)، اور روایتی کرپٹوگرافک لائبریریوں کے مقابلے دسیوں گنا سست کام کرتے ہیں۔ بہت سے پروٹوکول صرف کلیدی حجم کی بنیاد پر ضروریات کو پورا نہیں کرتے ہیں، مثال کے طور پر RSA کے لیے 1024 اور 2048 بٹس، Bitcoin اور Ethereum میں معیاری لین دین کے دستخط سے 4-8 گنا بڑے۔

مختلف پروگرامنگ زبانوں میں نفاذ کی موجودگی بھی ایک کردار ادا کرتی ہے - جن میں سے بہت کم ہیں، خاص طور پر نئے پروٹوکول کے لیے۔ اتفاق رائے میں انضمام کے ساتھ آپشن کے لیے پلیٹ فارم کی زبان میں پروٹوکول لکھنے کی ضرورت ہوتی ہے، لہذا آپ کو گو فار گیتھ، رسٹ فار پیریٹی میں، EOS کے لیے C++ میں کوڈ تلاش کرنا ہوگا۔ ہر ایک کو جاوا اسکرپٹ کوڈ تلاش کرنا ہوگا، اور چونکہ جاوا اسکرپٹ اور کرپٹوگرافی خاص طور پر قریبی دوست نہیں ہیں، اس لیے WebAssembly مدد کرے گا، جو اب یقینی طور پر اگلا اہم انٹرنیٹ معیار ہونے کا دعویٰ کرتا ہے۔

حاصل يہ ہوا

میں پچھلے ایک میں امید کرتا ہوں آرٹیکل میں آپ کو یہ باور کرانے میں کامیاب ہو گیا کہ بلاکچین پر بے ترتیب نمبر بنانا وکندریقرت نیٹ ورکس کی زندگی کے بہت سے پہلوؤں کے لیے اہم ہے، اور اس مضمون کے ساتھ میں نے ظاہر کیا کہ یہ کام انتہائی مہتواکانکشی اور مشکل ہے، لیکن اچھے حل پہلے سے موجود ہیں۔ عام طور پر، پروٹوکول کا حتمی ڈیزائن بڑے پیمانے پر ٹیسٹ کرنے کے بعد ہی ممکن ہے جس میں سیٹ اپ سے لے کر فالٹ ایمولیشن تک کے تمام پہلوؤں کو مدنظر رکھا جاتا ہے، اس لیے آپ کو ٹیم کے وائٹ پیپرز اور آرٹیکلز میں ریڈی میڈ ریسپیز ملنے کا امکان نہیں ہے، اور ہم یقینی طور پر ایسا نہیں کریں گے۔ اگلے ایک یا دو سال میں فیصلہ کریں "اس طرح کرو، بالکل ٹھیک"۔

الوداع، بلاک چین میں ہمارے PVRB کے لیے سے Haya، ہم نے حد BLS دستخطوں کو استعمال کرنے پر طے کیا، ہم متفقہ سطح پر PVRB کو لاگو کرنے کا ارادہ رکھتے ہیں، کیونکہ قابل قبول سطح کے سیکورٹی کے ساتھ اسمارٹ معاہدوں میں تصدیق ابھی ممکن نہیں ہے۔ یہ ممکن ہے کہ ہم ایک ساتھ دو اسکیمیں استعمال کریں: پہلی، مہنگی خفیہ شیئرنگ طویل مدتی random_seed بنانے کے لیے، اور پھر ہم اسے اعلی تعدد بے ترتیب جنریشن کی بنیاد کے طور پر deterministic threshold BLS دستخطوں کا استعمال کرتے ہوئے استعمال کریں، شاید ہم خود کو صرف ان تک محدود رکھیں گے۔ اسکیموں میں سے ایک. بدقسمتی سے، یہ پہلے سے کہنا ناممکن ہے کہ پروٹوکول کیا ہوگا؛ صرف اچھی بات یہ ہے کہ سائنس کی طرح انجینئرنگ کے مسائل میں بھی منفی نتیجہ نکلتا ہے، اور اس مسئلے کو حل کرنے کی ہر نئی کوشش ایک اور قدم ہے۔ مسئلے میں شامل ہر فرد کی تحقیق۔ کاروباری ضروریات کو پورا کرنے کے لیے، ہم ایک مخصوص عملی مسئلہ کو حل کرتے ہیں - گیمنگ ایپلی کیشنز کو اینٹروپی کے ایک قابل اعتماد ذریعہ کے ساتھ فراہم کرنا، اس لیے ہمیں خود بلاکچین پر بھی توجہ دینی ہوگی، خاص طور پر سلسلہ کی تکمیل اور نیٹ ورک گورننس کے مسائل پر۔

اور اگرچہ ہمیں ابھی تک بلاک چینز میں ایک ثابت مزاحم PVRB نظر نہیں آتا ہے، جسے حقیقی ایپلی کیشنز، متعدد آڈٹ، بوجھ اور یقیناً حقیقی حملوں کے ذریعے جانچنے کے لیے کافی وقت کے لیے استعمال کیا گیا ہو گا، لیکن ممکنہ راستوں کی تعداد اس بات کی تصدیق کرتی ہے۔ ایک حل موجود ہے، اور آخر کار ان الگورتھم میں سے کیا مسئلہ حل ہو جائے گا۔ ہمیں نتائج کا اشتراک کرنے میں خوشی ہوگی اور دوسری ٹیموں کا شکریہ ادا کریں گے جو اس مسئلے پر مضامین اور کوڈ کے لیے بھی کام کر رہی ہیں جو انجینئرز کو ایک ہی ریک پر دو بار قدم نہیں رکھنے کی اجازت دیتی ہیں۔

لہٰذا، جب آپ کسی پروگرامر سے ملتے ہیں جو ڈی سینٹرلائزڈ رینڈم ڈیزائن کرتے ہیں، تو دھیان دیں اور خیال رکھیں، اور اگر ضروری ہو تو نفسیاتی مدد فراہم کریں :)

ماخذ: www.habr.com