تعارف

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

جيئن ته ڪرپٽ گرافي مان هڪ بلڪل مضبوط سيفر جي تصور سان، حقيقي "عوامي طور تي تصديق ٿيل رينڊم بيڪن" (هتان کان پوء PVRB) پروٽوڪول صرف مثالي اسڪيم کي ممڪن حد تائين ويجهي وڃڻ جي ڪوشش ڪندا آهن، ڇاڪاڻ ته حقيقي نيٽ ورڪن ۾ اهو ان جي خالص شڪل ۾ لاڳو نه آهي: اهو ضروري آهي ته هڪ ساٽ تي سختي سان اتفاق ڪيو وڃي، اتي ڪيترائي رائونڊ هجڻ گهرجن، ۽ سڀئي پيغام بلڪل تيز ۽ هميشه پهچائڻ گهرجن. يقينا، اهو معاملو حقيقي نيٽ ورڪن ۾ ناهي. تنهن ڪري، جڏهن جديد بلاڪچين ۾ مخصوص ڪمن لاءِ PVRBs کي ڊزائين ڪرڻ، نتيجي ۾ بي ترتيبي ۽ ڪرپٽوگرافڪ طاقت کي ڪنٽرول ڪرڻ جي ناممڪن کان علاوه، ڪيترائي وڌيڪ خالص تعميراتي ۽ ٽيڪنيڪل مسئلا پيدا ٿين ٿا.

PVRB لاءِ، بلاڪچين پاڻ بنيادي طور تي هڪ رابطي جو ذريعو آهي جنهن ۾ پيغام = ٽرانزيڪشن. اهو توهان کي جزوي طور تي نيٽ ورڪ جي مسئلن، پيغامن جي غير ترسيل، مڊل ويئر سان مسئلن کان نجات حاصل ڪرڻ جي اجازت ڏئي ٿو - اهي سڀئي خطرا غير مرڪزي نيٽ ورڪ طرفان فرض ڪيا ويا آهن، ۽ PVRB لاء ان جي بنيادي قيمت اڳ ۾ ئي موڪليل ٽرانزيڪشن کي رد ڪرڻ يا خراب ڪرڻ جي ناڪامي آهي. شرڪت ڪندڙن کي پروٽوڪول ۾ حصو وٺڻ کان انڪار ڪرڻ جي اجازت نه ڏيو، جيستائين اھي اتفاق راء تي ڪامياب حملو نه ڪن. سيڪيورٽي جي هي سطح قابل قبول آهي، تنهن ڪري PVRB کي لازمي طور تي ساڳئي حد تائين شرڪت ڪندڙن جي ميلاپ جي خلاف مزاحمت ڪرڻ گهرجي جيئن مکيه بلاڪ چين. انهي سان گڏ، اهو اشارو ڏئي ٿو ته PVRB لازمي طور تي اتفاق جو حصو هجڻ گهرجي جيڪڏهن نيٽ ورڪ مکيه بلاڪچين تي متفق آهي، جيتوڻيڪ اهو پڻ اتفاق آهي صرف منصفانه نتيجو بي ترتيب تي. يا، PVRB صرف هڪ اسٽائل پروٽوڪول آهي جيڪو هڪ سمارٽ معاهدي پاران لاڳو ڪيو ويو آهي جيڪو ڪم ڪري ٿو هم وقت سازي سان بلاڪچين ۽ بلاڪ جي حوالي سان. ٻنهي طريقن جا پنهنجا فائدا ۽ نقصان آهن، ۽ انهن جي وچ ۾ انتخاب انتهائي غير معمولي آهي.

PVRB کي لاڳو ڪرڻ جا ٻه طريقا

اچو ته وڌيڪ تفصيل سان بيان ڪريون PVRB کي لاڳو ڪرڻ لاءِ ٻن آپشنز - اسٽينڊل ورزن، جيڪو ڪم ڪري ٿو سمارٽ ڪانٽريڪٽ استعمال ڪندي بلاڪچين کان آزاد، ۽ اتفاق سان مربوط ورزن، پروٽوڪول ۾ ٺهيل آهي، جنهن مطابق نيٽ ورڪ بلاڪچين تي متفق آهي ۽ ٽرانزيڪشن کي شامل ڪيو وڃي. سڀني صورتن ۾، منهنجو مطلب ٿيندو مشهور بلاڪچين انجڻ: Ethereum، EOS، ۽ اهي سڀئي انهن سان ملندڙ جلندڙ طريقي سان جيڪي هو ميزباني ڪن ٿا ۽ سمارٽ معاهدن تي عمل ڪن ٿا.

اڪيلو معاهدو

هن نسخي ۾، PVRB هڪ سمارٽ معاهدو آهي جيڪو بي ترتيب پيدا ڪندڙن جي ٽرانزيڪشن کي قبول ڪري ٿو (هتي RP طور حوالو ڏنو ويو آهي)، انهن کي پروسيس ڪري ٿو، نتيجن کي گڏ ڪري ٿو، ۽ نتيجي طور، هڪ خاص قيمت تي پهچي ٿو جيڪو ڪو به صارف هن معاهدي مان حاصل ڪري سگهي ٿو. اهو قدر سڌو سنئون معاهدي ۾ محفوظ نه ٿي سگهي، بلڪه صرف ڊيٽا جي نمائندگي ڪري سگهجي ٿو جنهن مان نتيجو بي ترتيب جي هڪ ۽ صرف هڪ قيمت مقرر ڪري سگهجي ٿي. هن اسڪيم ۾، RPs بلاڪچين جا استعمال ڪندڙ آهن، ۽ ڪنهن کي به اجازت ڏئي سگهجي ٿي ته اها نسل جي عمل ۾ حصو وٺي.

اسٽينڊل-معاهدي سان اختيار سٺو آهي:

• پورائيبلٽي (معاهدي کي ڇڪي سگھجي ٿو blockchain کان blockchain)
• عمل درآمد ۽ جانچ ۾ آساني (معاهدو لکڻ ۽ جانچڻ ۾ آسان آهن)
• اقتصادي اسڪيمن کي لاڳو ڪرڻ ۾ سهولت (توهان جو پنهنجو ٽوڪن ٺاهڻ آسان آهي، جنهن جي منطق PVRB جي مقصدن کي پورو ڪري ٿي)
• اڳ ۾ ئي ڪم ڪندڙ بلاڪچين تي لانچ ڪرڻ جو امڪان

اهو پڻ نقصان آهي:

• ڪمپيوٽنگ وسيلن تي مضبوط حدون، ٽرانزيڪشن جي مقدار ۽ اسٽوريج (ٻين لفظن ۾، سي پي يو / ايم / آئي او)
• معاهدي جي اندر عملن تي پابنديون (سڀئي هدايتون دستياب نه آهن، ٻاهرين لائبريرين کي ڳنڍڻ ڏکيو آهي)
• بلاڪچين ۾ ٽرانزيڪشن کان وڌيڪ تيزيءَ سان ميسيجنگ کي منظم ڪرڻ ۾ ناڪامي شامل آهي

هي اختيار PVRB لاڳو ڪرڻ لاءِ موزون آهي جنهن کي موجوده نيٽ ورڪ تي هلائڻ جي ضرورت آهي، ان ۾ پيچيده ڪرپٽوگرافي شامل نه آهي ۽ وڏي تعداد ۾ رابطي جي ضرورت ناهي.

اتفاق سان گڏ ٿيل

هن نسخي ۾، PVRB بلاڪچين نوڊ ڪوڊ ۾ لاڳو ڪيو ويو آهي، بلٽ ان يا بلاڪچين نوڊس جي وچ ۾ پيغامن جي تبادلي سان متوازي طور تي هلندڙ. پروٽوڪول جا نتيجا سڌو سنئون ٺاهيل بلاڪ ۾ لکيل آهن، ۽ پروٽوڪول پيغام موڪليا ويا آهن p2p نيٽ ورڪ تي نوڊس جي وچ ۾. جيئن ته پروٽوڪول جي نتيجي ۾ انگن اکرن کي بلاڪ ڪيو وڃي ٿو، نيٽ ورڪ انهن تي اتفاق راء تائين پهچڻ گهرجي. هن جو مطلب اهو آهي ته PVRB پيغام، ٽرانزيڪشن وانگر، نوڊس جي تصديق ٿيڻ گهرجي ۽ بلاڪ ۾ شامل ڪيو وڃي ته جيئن ڪو به نيٽ ورڪ شرڪت ڪندڙ PVRB پروٽوڪول جي تعميل جي تصديق ڪري سگهي. اهو خود بخود اسان کي واضح حل ڏانهن وٺي ٿو - جيڪڏهن نيٽورڪ هڪ بلاڪ بابت اتفاق راءِ تي اتفاق ڪري ٿو ۽ ان ۾ ٽرانزيڪشن، پوءِ PVRB کي اتفاق راءِ جو حصو هجڻ گهرجي، ۽ هڪ اسٽينڊ اڪيلو پروٽوڪول نه. ٻي صورت ۾، اهو ممڪن آهي ته هڪ بلاڪ اتفاق راء جي نقطي کان صحيح آهي، پر PVRB پروٽوڪول جي پيروي نه ڪئي وئي آهي، ۽ PVRB نقطي نظر کان بلاڪ قبول نه ٿو ڪري سگهجي. تنهن ڪري جيڪڏهن ”اتفاق سان مربوط“ آپشن چونڊيو وڃي ٿو، PVRB اتفاق راءِ جو هڪ اهم حصو بڻجي وڃي ٿو.

جڏهن نيٽ ورڪ اتفاق راءِ جي سطح تي PVRB عمل درآمد کي بيان ڪندي، هڪ به طريقي سان حتمي مسئلن کان پاسو نٿو ڪري سگهي. حتمييت هڪ ميکانيزم آهي جيڪو تعيناتي اتفاق راءِ ۾ استعمال ڪيو ويندو آهي جيڪو هڪ بلاڪ (۽ ان ڏانهن ويندڙ زنجير) انجام ڏئي ٿو جيڪو حتمي آهي ۽ ڪڏهن به پري نه ڪيو ويندو، جيتوڻيڪ هڪ متوازي ڪانٽو ٿئي ٿي. مثال طور، Bitcoin ۾ ڪو به اهڙو ميکانيزم نه آهي - جيڪڏهن توهان هڪ وڏي پيچيدگي واري زنجير کي شايع ڪندا آهيو، اهو ڪنهن به گهٽ پيچيده کي تبديل ڪندو، قطع نظر زنجيرن جي ڊيگهه جي. ۽ EOS ۾، مثال طور، فائنل وارا نام نهاد آخري ناقابل واپسي بلاڪ آهن، جيڪي ظاهر ٿيندا آهن سراسري طور تي هر 432 بلاڪ (12 * 21 + 12 * 15، اڳ-ووٽ + پري ڪمٽ). اهو عمل لازمي طور تي 2/3 بلاڪ-پيداوارن جي انتظار ۾ آهي (هتي بي پي جي طور تي حوالو ڏنو ويو آهي) دستخط. جڏهن فورڪ ظاهر ٿيندا آهن جيڪي آخري LIB کان پراڻا آهن، اهي صرف رد ڪيا ويا آهن. هي ميکانيزم انهي کي يقيني بڻائي ٿو ته اها ضمانت آهي ته ٽرانزيڪشن بلاڪچين ۾ شامل آهي ۽ ڪڏهن به واپس نه ڪيو ويندو، ڪابه پرواهه ناهي ته حملي ڪندڙ وٽ ڪهڙا وسيلا آهن. ان سان گڏ، حتمي بلاڪ بلاڪ آهن 2/3 BP پاران دستخط ٿيل Hyperledger، Tendermint ۽ ٻين pBFT-بنياد اتفاق سان. انهي سان گڏ، اهو سمجهه ۾ اچي ٿو ته هڪ پروٽوڪول کي يقيني بڻائڻ جي لاءِ حتمي اتفاق راءِ ۾ اضافو، ڇاڪاڻ ته اهو بلاڪ جي پيداوار ۽ اشاعت سان گڏ ڪم ڪري سگهي ٿو. هتي هڪ سٺو آهي هڪ مضمون Ethereum ۾ حتمي بابت.

صارفين لاءِ فائنل انتهائي اهم آهي، جيڪي ان کان سواءِ پاڻ کي ”ٻئي خرچ“ جي حملي جو شڪار ٿي سگهن ٿا، جتي BP ”هڪ رکي ٿو“ بلاڪ، ۽ نيٽ ورڪ جي ”ڏسڻ“ کان پوءِ سٺي ٽرانزيڪشن کي شايع ڪري ٿو. جيڪڏهن ڪو حتمي نتيجو نه آهي، پوء شايع ٿيل ڪانٽو بلاڪ کي "سٺو" ٽرانزيڪشن سان ٻئي سان تبديل ڪري ٿو، هڪ "خراب" ڪانٽو کان، جنهن ۾ ساڳيو فنڊ حملو ڪندڙ جي ايڊريس تي منتقل ڪيو ويو آهي. PVRB جي صورت ۾، فائنل لاءِ گهرجون اڃا به وڌيڪ سخت آهن، ڇاڪاڻ ته PVRB لاءِ فورڪس ٺاهڻ جو مطلب آهي هڪ حملي آور لاءِ موقعو آهي ته هو ڪيترن ئي بي ترتيب آپشنز کي تيار ڪري ته جيئن سڀ کان وڌيڪ فائدي وارو شايع ڪري، ۽ ممڪن حملي جي وقت کي محدود ڪري. سٺو حل.

تنهن ڪري، بهترين اختيار اهو آهي ته PVRB ۽ فائنل کي هڪ پروٽوڪول ۾ گڏ ڪيو وڃي - پوء حتمي بلاڪ = حتمي بي ترتيب، ۽ اهو ئي آهي جيڪو اسان کي حاصل ڪرڻ جي ضرورت آهي. ھاڻي رانديگرن کي N سيڪنڊن ۾ بي ترتيب جي ضمانت ملي ويندي، ۽ پڪ ٿي سگھي ٿو ته ان کي واپس ڪرڻ يا ان کي ٻيهر هلائڻ ناممڪن آھي.

اتفاق سان مربوط آپشن سٺو آهي:

• بلاڪ جي پيداوار جي سلسلي ۾ غير مطابقت واري عمل جو امڪان - بلاڪ عام طور تي پيدا ڪيا ويا آهن، پر ان سان گڏ، PVRB پروٽوڪول ڪم ڪري سگهي ٿو، جيڪو هر بلاڪ لاء بي ترتيب پيدا نٿو ڪري.
• سمارٽ معاهدن تي لاڳو پابندين کان سواءِ ، بھاري ڪرپٽوگرافي کي لاڳو ڪرڻ جي صلاحيت
• پيغامن جي مٽاسٽا کي منظم ڪرڻ جي صلاحيت ٽرانزيڪشن جي ڀيٽ ۾ تيزيءَ سان بلاڪچين ۾ شامل آهي، مثال طور، پروٽوڪول جو حصو نيٽ ورڪ تي پيغامن کي ورهائڻ کان سواءِ نوڊس جي وچ ۾ ڪم ڪري سگهي ٿو.

اهو پڻ نقصان آهي:

• ٽيسٽ ۽ ڊولپمينٽ ۾ مشڪلاتون - توهان کي نيٽ ورڪ جي غلطين، غائب نوڊس، نيٽ ورڪ هارڊ فورڪز کي نقل ڪرڻو پوندو
• عمل جي غلطين کي نيٽ ورڪ hardfork جي ضرورت آهي

PVRB لاڳو ڪرڻ جا ٻئي طريقا زندگي گذارڻ جو حق رکن ٿا، پر جديد بلاڪچين ۾ سمارٽ معاهدن تي عمل درآمد اڃا تائين ڪمپيوٽنگ وسيلن ۾ ڪافي محدود آهي، ۽ سنگين ڪرپٽوگرافي ڏانهن ڪا به منتقلي اڪثر ڪري ناممڪن آهي. ۽ اسان کي سنجيده ڪرپٽوگرافي جي ضرورت پوندي، جيئن هيٺ ڏيکاريو ويندو. جيتوڻيڪ اهو مسئلو واضح طور تي عارضي آهي، ڪيترن ئي مسئلن کي حل ڪرڻ لاءِ معاهدن ۾ سنجيده ڪرپٽوگرافي جي ضرورت آهي، ۽ اهو بتدريج ظاهر ٿي رهيو آهي (مثال طور، Ethereum ۾ zkSNARKs لاءِ سسٽم معاهدو)

Blockchain، جيڪو هڪ شفاف ۽ قابل اعتماد پروٽوڪول پيغام رسائيندڙ چينل مهيا ڪري ٿو، اهو مفت ۾ نٿو ڪري. ڪنهن به غير مرڪزي پروٽوڪول کي لازمي طور تي سيبل حملي جي امڪان کي نظر ۾ رکڻ گهرجي؛ ڪو به عمل ڪيترن ئي اڪائونٽن جي گڏيل قوتن طرفان ڪري سگهجي ٿو، تنهن ڪري، ڊزائين ڪرڻ وقت، اهو ضروري آهي ته حملي ڪندڙن جي قابليت کي حساب ۾ رکڻ گهرجي ته پروٽوڪول جو هڪ خودمختيار نمبر ٺاهي. شرڪت ڪندڙ گڏجاڻي ۾ ڪم ڪري رهيا آهن.

PVRB ۽ بلاڪ متغير.

مون ڪوڙ نه ڳالهايو جڏهن مون چيو ته اڃا تائين ڪنهن به سٺي PVRB تي عمل نه ڪيو آهي، ڪيترن ئي جوا جي ايپليڪيشنن پاران آزمائشي، بلاڪچين ۾. پوءِ ايٿيريم ۽ EOS تي ڪيتريون ئي جوا جون ايپليڪيشنون ڪٿان اچن ٿيون؟ اهو مون کي حيران ڪري ٿو جيترو اهو توهان کي حيران ڪري ٿو، انهن کي مڪمل طور تي متعين ماحول ۾ تمام گهڻو "مسلسل" بي ترتيب ڪٿي مليو؟

بلاڪچين ۾ بي ترتيب ٿيڻ جو پسنديده طريقو اهو آهي ته بلاڪ مان ڪنهن قسم جي ”غير متوقع“ معلومات ورتي وڃي ۽ ان جي بنياد تي هڪ بي ترتيب ٺاهيو وڃي - صرف هڪ يا وڌيڪ قدرن کي هٽائڻ سان. اهڙين منصوبن جي مسئلن بابت سٺو مضمون هتي. توهان بلاڪ ۾ "غير متوقع" قدرن مان ڪو به وٺي سگهو ٿا، مثال طور، بلاڪ هيش، ٽرانزيڪشن جو تعداد، نيٽورڪ پيچيدگي، ۽ ٻيا قدر جيڪي اڳ ۾ اڻڄاتل آهن. پوء انهن کي هٽايو، هڪ يا وڌيڪ، ۽، نظريي ۾، توهان کي حقيقي بي ترتيب حاصل ڪرڻ گهرجي. توهان وائيٽ پيپر ۾ به شامل ڪري سگهو ٿا ته توهان جي اسڪيم ”پوسٽ ڪوانٽم سيڪيور“ آهي (جيئن ته ڪوانٽم پروف هيش افعال آهن :)).

پر جيتوڻيڪ پوسٽ-ڪانٽم محفوظ هيش ڪافي نه آهن، افسوس. راز PVRB جي گهرج ۾ آهي، مون کي توهان کي انهن جي پوئين مضمون مان ياد ڏيارڻ ڏيو:

1. نتيجو لازمي طور تي يونيفارم تقسيم هجڻ گهرجي، يعني ثابتي طور تي مضبوط ڪرپٽوگرافي تي ٻڌل هجي.
2. نتيجي جي ڪنهن به بٽ کي ڪنٽرول ڪرڻ ممڪن ناهي. نتيجي طور، نتيجو اڳ ۾ پيش نه ٿو ڪري سگھجي.
3. توهان پروٽوڪول ۾ حصو نه وٺڻ يا حملي واري پيغامن سان نيٽ ورڪ کي اوور لوڊ ڪندي نسل پروٽوڪول کي سبوتاز نٿا ڪري سگهو
4. مٿين سڀني کي لازمي طور تي بي ايماني پروٽوڪول شرڪت ڪندڙن جي جائز تعداد جي ميلاپ جي خلاف مزاحمت ڪرڻ گهرجي (مثال طور، شرڪت ڪندڙن جو 1/3).

ان صورت ۾، صرف 1 جي گهرج پوري ڪئي وئي آهي، ۽ ضرورت 2 پوري نه ڪئي وئي آهي. بلاڪ مان غير متوقع قدرن کي هٽائڻ سان، اسان هڪ يونيفارم ورهائڻ ۽ سٺو بي ترتيب حاصل ڪنداسين. پر BP وٽ گهٽ ۾ گهٽ اختيار آهي ته ”بلاڪ شايع ڪريو يا نه. اهڙيء طرح، BP گهٽ ۾ گهٽ ٻن بي ترتيب اختيارن مان چونڊجي سگهي ٿو: "پنهنجو" ۽ هڪ جيڪو ٻاهر نڪرندو جيڪڏهن ڪو ٻيو بلاڪ ٺاهي. BP اڳ ۾ ئي ”اسنوپ“ ڪري سگهي ٿو ته ڇا ٿيندو جيڪڏهن هو هڪ بلاڪ شايع ڪري، ۽ بس فيصلو ڪري ته اهو ڪرڻ يا نه. اهڙيءَ طرح، جڏهن راند ڪري، مثال طور، روليٽي ۾ ”جيون-اڊڊ“ يا ”ڳاڙهو/ڪارو“، هو صرف هڪ بلاڪ شايع ڪري سگهي ٿو جيڪڏهن هو کٽي ڏسي. اهو پڻ استعمال ڪرڻ جي حڪمت عملي ٺاهي ٿو، مثال طور، هڪ بلاڪ هيش "مستقبل کان" ناقابل عمل. انهي صورت ۾، اهي چون ٿا ته "بي ترتيب استعمال ڪيو ويندو، جيڪو موجوده ڊيٽا کي هٽائڻ سان حاصل ڪيو ويندو آهي ۽ مستقبل جي بلاڪ جي هيش جي اونچائي سان، مثال طور، N + 42، جتي N موجوده بلاڪ جي اوچائي آهي. هي اسڪيم کي ٿورڙي مضبوط ڪري ٿو، پر اڃا به BP کي اجازت ڏئي ٿو، جيتوڻيڪ مستقبل ۾، اهو چونڊڻ لاء ته بلاڪ کي رکڻ يا شايع ڪرڻ.

هن معاملي ۾ بي پي سافٽ ويئر وڌيڪ پيچيده ٿي، پر گهڻو نه. بس، جڏهن هڪ بلاڪ ۾ هڪ ٽرانزيڪشن جي تصديق ڪرڻ ۽ شامل ڪرڻ، اتي هڪ تڪڙو چيڪ آهي ڏسڻ لاء ته اتي هڪ جيت هوندي، ۽، ممڪن آهي، هڪ ٽرانزيڪشن پيٽرولر جو انتخاب کٽڻ جي اعلي امڪان حاصل ڪرڻ لاء. ساڳي ئي وقت، اهڙي قسم جي ڦيرڦار لاء هڪ سمارٽ بي پي کي پڪڙڻ تقريبا ناممڪن آهي؛ هر ڀيري توهان نوان ايڊريس استعمال ڪري سگهو ٿا ۽ شڪ پيدا ڪرڻ کان سواء ٿوري دير سان کٽي سگهو ٿا.

تنهن ڪري بلاڪ مان معلومات استعمال ڪرڻ جا طريقا PVRB جي عالمگير عمل جي طور تي مناسب نه آهن. هڪ محدود ورزن ۾، شرطن تي پابندي، رانديگرن جي تعداد تي پابندي ۽/يا KYC رجسٽريشن (هڪ رانديگر کي ڪيترن ئي ايڊريس استعمال ڪرڻ کان روڪڻ لاءِ)، اهي اسڪيمون ننڍين رانديون لاءِ ڪم ڪري سگهن ٿيون، پر وڌيڪ ڪجهه به نه.

PVRB ۽ عزم-ظاهر.

ٺيڪ آهي، هيشنگ جي مهرباني ۽ گهٽ ۾ گهٽ لاڳاپو غير متوقع طور بلاڪ هيش ۽ ٻين متغيرن جي. جيڪڏهن توهان اڳيان هلندڙ معدنيات جو مسئلو حل ڪيو، توهان کي ڪجهه وڌيڪ مناسب حاصل ڪرڻ گهرجي. اچو ته صارفين کي هن اسڪيم ۾ شامل ڪريون - انهن کي پڻ بي ترتيب تي اثر انداز ڪرڻ ڏيو: ڪو به ٽيڪنيڪل سپورٽ ملازم توهان کي ٻڌائيندو ته آئي ٽي سسٽم ۾ سڀ کان وڌيڪ بي ترتيب شيء آهي صارفين جا عمل :)

هڪ سادي اسڪيم، جڏهن صارف صرف بي ترتيب نمبر موڪليندا آهن ۽ نتيجو ڳڻيو ويندو آهي، مثال طور، انهن جي رقم جو هڪ هيش، مناسب ناهي. انهي حالت ۾، آخري پليئر ڪري سگهي ٿو، پنهنجي بي ترتيب کي چونڊڻ سان، ڪنٽرول ڪري سگھي ٿو ته نتيجو ڇا ٿيندو. اهو ئي سبب آهي ته وڏي پيماني تي استعمال ٿيل عزم-ظاهر نموني استعمال ڪيو ويندو آهي. شرڪت ڪندڙ پهريان انهن جي بي ترتيبن (ڪميٽ) مان هيش موڪليندا آهن، ۽ پوءِ بي ترتيب پاڻ کي کوليو (ظاهر ڪري ٿو). "ظاهر" مرحلو صرف ضروري ڪمن کي گڏ ڪرڻ کان پوء شروع ٿئي ٿو، تنهن ڪري شرڪت ڪري سگھن ٿا بلڪل بي ترتيب واري هيش جنهن کان انهن اڳ موڪليو هو. ھاڻي اچو ته اھو سڀ ھڪڙي بلاڪ جي پيرا ميٽرن سان گڏ رکون، ۽ مستقبل کان وٺي ھڪڙي کان بھتر آھي (بي ترتيب صرف مستقبل جي ھڪڙي بلاڪ ۾ ڳولي سگھجي ٿو)، ۽ وائيلا - بي ترتيب تيار آھي! ھاڻي ڪو به پليئر نتيجي ۾ بي ترتيبيءَ تي اثرانداز ٿئي ٿو، ۽ بدڪاري واري بي پي کي ”ماتي“ ڪري سگھي ٿو ان کي پنھنجي، اڻڄاتل اڳواٽ، بي ترتيبيءَ سان اوور رائيڊ ڪري... توھان پروٽوڪول کي سبوتاز ڪرڻ جي خلاف تحفظ پڻ شامل ڪري سگھو ٿا ان کي ظاھر ڪرڻ واري مرحلي تي نه کولڻ سان- بس هڪ خاص رقم جي ضرورت سان ٽرانزيڪشن سان ڳنڍڻ لاءِ جڏهن ڪم ڪيو وڃي - هڪ حفاظتي جمع، جيڪو صرف ظاهر ڪرڻ واري عمل دوران واپس ڪيو ويندو. انهي صورت ۾، ڪم ڪرڻ ۽ ظاهر نه ڪرڻ غير منافع بخش ٿيندو.

اها هڪ سٺي ڪوشش هئي، ۽ اهڙيون اسڪيمون گیمنگ ڊي ايپس ۾ پڻ موجود آهن، پر افسوس، اهو ٻيهر ڪافي ناهي. هاڻي نه رڳو معدني، پر پروٽوڪول ۾ ڪنهن به شرڪت ڪندڙ پڻ نتيجو تي اثر انداز ڪري سگهي ٿو. اهو اڃا تائين ممڪن آهي ته قيمت پاڻ کي ڪنٽرول ڪرڻ لاء، گهٽ متغير ۽ قيمت تي، پر، جيئن ته مائنر جي صورت ۾، جيڪڏهن ڊرائنگ جا نتيجا PVRB پروٽوڪول ۾ حصو وٺڻ جي فيس کان وڌيڪ قيمتي آهن، پوء بي ترتيب. -producer(RP) اهو فيصلو ڪري سگهي ٿو ته ڇا ظاهر ڪرڻ ۽ اڃا به گهٽ ۾ گهٽ ٻن بي ترتيب اختيارن مان چونڊجي سگهي ٿو.
پر اهو ممڪن ٿي ويو ته انهن کي سزا ڏيڻ لاء جيڪي ڪم ڪن ٿا ۽ ظاهر نه ڪن، ۽ هي اسڪيم هٿ ۾ ايندي. ان جي سادگي هڪ سنگين فائدو آهي - وڌيڪ سنجيده پروٽوڪول گهڻو وڌيڪ طاقتور حساب جي ضرورت آهي.

PVRB ۽ مقرراتي دستخط.

ھڪڙو ٻيو طريقو آھي RP کي مجبور ڪرڻ لاءِ ھڪڙو بي ترتيب نمبر مهيا ڪرڻ لاءِ جيڪو اھو اثر انداز نٿو ڪري سگھي جيڪڏھن اھو مهيا ڪيو ويو آھي "پري اميج" - اھو ھڪڙو تعيناتي دستخط آھي. اهڙو دستخط، مثال طور، RSA، ۽ ECS نه آهي. جيڪڏهن RP وٽ چاٻين جو هڪ جوڙو آهي: RSA ۽ ECC، ۽ هو پنهنجي پرائيويٽ ڪنجي سان هڪ خاص قدر تي دستخط ڪري ٿو، ته پوءِ RSA جي صورت ۾ هن کي هڪ ۽ صرف هڪ دستخط ملندو، ۽ ECS جي صورت ۾ هو ڪي به نمبر ٺاهي سگهي ٿو. مختلف صحيح دستخط. اهو ئي سبب آهي جڏهن هڪ ECS دستخط ٺاهيندي، هڪ بي ترتيب نمبر استعمال ڪيو ويندو آهي، جيڪو دستخط ڪندڙ طرفان چونڊيو ويو آهي، ۽ اهو ڪنهن به طريقي سان چونڊيو وڃي ٿو، دستخط ڪندڙ کي ڪيترن ئي دستخطن مان هڪ چونڊڻ جو موقعو ڏئي ٿو. RSA جي صورت ۾: "هڪ ان پٽ قيمت" + "هڪ اهم جوڙو" = "هڪ دستخط". اهو اڳڪٿي ڪرڻ ناممڪن آهي ته ٻيو RP ڪهڙو دستخط حاصل ڪندو، تنهن ڪري هڪ PVRB مقرري واري دستخط سان گڏ ڪيترن ئي شرڪت ڪندڙن جي RSA دستخطن کي گڏ ڪري منظم ڪري سگهجي ٿو جن ساڳئي قيمت تي دستخط ڪيا. مثال طور، اڳوڻو بي ترتيب. هي اسڪيم ڪيترن ئي وسيلن کي بچائيندو آهي، ڇاڪاڻ ته دستخط ٻئي پروٽوڪول جي مطابق صحيح رويي جي تصديق ۽ بي ترتيب ٿيڻ جو هڪ ذريعو آهن.

تنهن هوندي به، تعيناتي دستخطن سان گڏ، اسڪيم اڃا تائين "آخري اداڪار" جي مسئلي لاء خطرناڪ آهي. آخري شرڪت ڪندڙ اڃا تائين فيصلو ڪري سگھي ٿو ته ڇا دستخط شايع ڪرڻ يا نه، ان جي نتيجي ۾ ڪنٽرول ڪري. توھان اسڪيم کي تبديل ڪري سگھو ٿا، ان ۾ بلاڪ ھيش شامل ڪريو، گول ٺاھيو ته جيئن نتيجو اڳ ۾ پيش نه ڪري سگھجي، پر اھي سڀ ٽيڪنڪ، جيتوڻيڪ ڪيترن ئي تبديلين کي مدنظر رکندي، اڃا تائين اجتماعي تي ھڪڙي شرڪت جي اثر جي مسئلي کي حل نه ڪيو وڃي. نتيجي ۾ هڪ ناقابل اعتماد ماحول آهي ۽ صرف اقتصادي ۽ وقت جي پابنديون تحت ڪم ڪري سگهي ٿو. ان کان علاوه، RSA ڪنجين جي سائيز (1024 ۽ 2048 بِٽ) ڪافي وڏي آهي، ۽ بلاڪچين ٽرانزيڪشن لاءِ سائيز هڪ انتهائي اهم پيٽرولر آهي. بظاهر مسئلو حل ڪرڻ جو ڪو سادو طريقو ناهي، اچو ته اڳتي وڌون.

PVRB ۽ ڳجهي شيئرنگ اسڪيمون

cryptography ۾، اهڙا اسڪيمون آهن جيڪي نيٽ ورڪ کي اجازت ڏئي سگھن ٿيون ته هڪ ۽ صرف هڪ PVRB قدر تي متفق ٿين، جڏهن ته اهڙيون اسڪيمون ڪجهه شرڪت ڪندڙن جي بدسلوڪي عملن جي خلاف مزاحمتي هونديون آهن. ھڪڙو مفيد پروٽوڪول جيڪو پاڻ کي واقف ڪرڻ جي لائق آھي شمير جي ڳجھي شيئرنگ اسڪيم آھي. اهو هڪ راز کي ورهائڻ جي خدمت ڪري ٿو (مثال طور، هڪ ڳجهي چيڪ) ڪيترن ئي حصن ۾، ۽ انهن حصن کي N شرڪت ڪندڙن ۾ ورهايو. راز کي اهڙي طرح ورهايو ويو آهي ته N مان نڪرندڙ M حصا ان کي ٻيهر حاصل ڪرڻ لاءِ ڪافي آهن، ۽ اهي M حصا ٿي سگهن ٿا. جيڪڏهن آڱرين تي، پوء هڪ اڻڄاتل فنڪشن جو گراف هجڻ سان، شرڪت ڪندڙ گراف تي پوائنٽون مٽائي، ۽ M پوائنٽ حاصل ڪرڻ کان پوء، سڄي فنڪشن کي بحال ڪري سگهجي ٿو.
هڪ سٺي وضاحت ڏنل آهي رڪن پر توهان جي سر ۾ پروٽوڪول کي راند ڪرڻ لاء عملي طور تي ان سان راند ڪرڻ لاء ڪارائتو آهي Demo صفحو.

جيڪڏهن FSSS (Fiat-Shamir Secret Sharing) اسڪيم ان جي خالص روپ ۾ لاڳو ٿئي ٿي، اهو هڪ ناقابل تباهي PVRB هوندو. ان جي آسان ترين شڪل ۾، پروٽوڪول هن طرح نظر اچي سگھي ٿو:

• هر حصو وٺندڙ پنهنجو بي ترتيب ٺاهي ٿو ۽ ان مان حصيداري ٻين شرڪت ڪندڙن ۾ ورهائي ٿو
• هر شرڪت ٻين شرڪت ڪندڙن جي رازن جو حصو ظاهر ڪري ٿو
• جيڪڏهن هڪ شرڪت ۾ M کان وڌيڪ شيئرز آهن، ته پوء هن شرڪت ڪندڙ جو تعداد شمار ڪري سگهجي ٿو، ۽ اهو منفرد هوندو، ظاهر ڪيل شرڪت ڪندڙن جي سيٽ کان سواء.
• ظاهر ڪيل بي ترتيبين جو ميلاپ مطلوب PVRB آهي

هتي، هڪ فرد شرڪت ڪندڙ پروٽوڪول جي نتيجن کي وڌيڪ اثر انداز نٿو ڪري، سواء ان صورتن ۾ جتي بي ترتيب جي ظاهر ٿيڻ واري حد جي حاصلات صرف ان تي منحصر آهي. تنهن ڪري، هي پروٽوڪول، جيڪڏهن پروٽوڪول تي ڪم ڪندڙ RPs جو هڪ گهربل تناسب آهي ۽ دستياب آهي، ڪم ڪري ٿو، cryptographic طاقت جي ضرورتن کي لاڳو ڪرڻ، ۽ "آخري اداڪار" جي مسئلي جي مزاحمت ڪرڻ.

اھو ھڪڙو مثالي اختيار ٿي سگھي ٿو، ھي PVRB اسڪيم تي ٻڌل آھي Fiat-Shamir ڳجھي شيئرنگ مثال طور بيان ڪيو ويو آھي هي مضمون. پر، جيئن مٿي ذڪر ڪيو ويو آهي، جيڪڏهن توهان ان کي لاڳو ڪرڻ جي ڪوشش ڪندا هيڊ آن بلاڪ ۾، ٽيڪنيڪل حدون ظاهر ٿينديون. هتي EOS سمارٽ معاهدي ۾ پروٽوڪول جي امتحان تي عمل درآمد جو هڪ مثال آهي ۽ ان جو سڀ کان اهم حصو - شايع ٿيل شيئر شرڪت ڪندڙ کي چيڪ ڪرڻ: ڪوڊ. توهان ڪوڊ مان ڏسي سگهو ٿا ته ثبوت جي تصديق لاءِ ڪيترن ئي اسڪالر ضربن جي ضرورت آهي، ۽ استعمال ٿيل انگ تمام وڏا آهن. اهو سمجهڻ گهرجي ته بلاڪچين ۾، تصديق ان وقت ٿيندي آهي جڏهن بلاڪ پيدا ڪندڙ ٽرانزيڪشن کي پروسيس ڪري ٿو، ۽ عام طور تي، ڪنهن به شرڪت ڪندڙ کي آساني سان پروٽوڪول جي درستي جي تصديق ڪرڻ گهرجي، تنهنڪري تصديق جي ڪارڪردگي جي رفتار لاء گهرجون تمام سنجيده آهن. . هن اختيار ۾، اختيار غير موثر ثابت ٿيو، ڇاڪاڻ ته تصديق ٽرانزيڪشن جي حد (0.5 سيڪنڊن) جي اندر مناسب نه هئي.

تصديق جي ڪارڪردگي، عام طور تي، بلاڪچين ۾ ڪنهن به ترقي يافته cryptographic منصوبن جي استعمال لاء سڀ کان اهم ضرورتن مان هڪ آهي. ثبوت ٺاهڻ، پيغام تيار ڪرڻ - اهي طريقا بند ڪري سگھجن ٿا ۽ اعليٰ ڪارڪردگي واري ڪمپيوٽرن تي ڪيا وڃن ٿا، پر تصديق کي نظرانداز نٿو ڪري سگهجي - PVRB لاءِ اها هڪ ٻي اهم ضرورت آهي.

PVRB ۽ حد جي دستخط

ڳجهي شيئرنگ اسڪيم کان واقف ٿيڻ بعد، اسان دريافت ڪيو پروٽوڪول جو هڪ سڄو ڪلاس لفظ ”درج“ سان گڏيل. جڏهن ڪجهه معلومات جي ظاهر ٿيڻ جي ضرورت آهي ايم ايماندار شرڪت ڪندڙن جي شموليت N کان ٻاهر، ۽ ايماندار شرڪت ڪندڙن جو سيٽ ٿي سگهي ٿو N جو هڪ صوابديدي ذيلي سيٽ، اسان "درج" اسڪيمن بابت ڳالهايون ٿا. اهي ئي آهن جيڪي اسان کي "آخري اداڪار" جي مسئلي سان معاملو ڪرڻ جي اجازت ڏين ٿا، هاڻي جيڪڏهن حملو ڪندڙ پنهنجي راز جو حصو ظاهر نه ڪندو آهي، هڪ ٻيو، ايماندار حصو وٺندڙ هن لاء ڪندو. اهي اسڪيمون هڪ ۽ صرف هڪ معني تي معاهدي جي اجازت ڏين ٿيون، جيتوڻيڪ پروٽوڪول کي ڪجهه شرڪت ڪندڙن طرفان سبوتاژ ڪيو ويو آهي.

مقرراتي دستخطن ۽ حد جي اسڪيمن جي ميلاپ کي PVRB لاڳو ڪرڻ لاءِ هڪ تمام آسان ۽ واعدو ڪندڙ اسڪيم تيار ڪرڻ ممڪن بڻايو - اهي مقرري واري حد جا دستخط آهن. هتي هڪ مضمون حد جي دستخط جي مختلف استعمالن بابت، ۽ هتي هڪ ٻيو سٺو آهي ڊگهو پڙهيل ڊيش کان.

آخري آرٽيڪل بيان ڪري ٿو BLS دستخط (BLS جو مطلب آهي Boneh-Lynn-Shacham، ڏس آرٽيڪل)، جنهن ۾ پروگرامرز لاءِ هڪ تمام اهم ۽ انتهائي آسان معيار آهي - عوامي، ڳجهي، عوامي چابيون ۽ BLS دستخط آسان رياضياتي عملن کي استعمال ڪندي هڪ ٻئي سان ملائي سگھجن ٿا، جڏهن ته انهن جو مجموعو صحيح چيڪ ۽ دستخط رهي ٿو، توهان کي آساني سان ڪيترن ئي کي گڏ ڪرڻ جي اجازت ڏئي ٿو. هڪ ۾ دستخط ۽ هڪ ۾ ڪيترائي عوامي چابيون. اهي پڻ مقرر آهن ۽ ساڳئي ان پٽ ڊيٽا لاء ساڳيو نتيجو پيدا ڪن ٿا. هن معيار جي مهرباني، BLS دستخطن جا مجموعا پاڻ ۾ صحيح ڪنجيون آهن، جيڪي هڪ آپشن کي لاڳو ڪرڻ جي اجازت ڏين ٿيون جنهن ۾ M of N شرڪت ڪندڙ هڪ ۽ صرف هڪ دستخط پيدا ڪن ٿا، جيڪو مقرري، عوامي طور تي تصديق لائق، ۽ غير متوقع آهي جيستائين اهو Mth پاران کوليو وڃي. حصو وٺندڙ

حد BLS دستخطن سان گڏ هڪ اسڪيم ۾، هر شرڪت ڪندڙ BLS استعمال ڪندي ڪجهه نشانو ڪري ٿو (مثال طور، پوئين بي ترتيب)، ۽ عام حد جي دستخط گهربل بي ترتيب آهي. BLS دستخطن جي cryptographic خاصيتون بي ترتيب معيار جي گهرجن کي پورو ڪن ٿيون، حد جو حصو "آخري-اداڪار" جي خلاف حفاظت ڪري ٿو، ۽ چابين جي منفرد ميلاپ کي ممڪن بڻائي ٿو ته ڪيترن ئي وڌيڪ دلچسپ الگورتھم کي لاڳو ڪرڻ جي اجازت ڏين ٿيون، مثال طور، پروٽوڪول پيغامن جي موثر مجموعي کي. .

تنهن ڪري، جيڪڏهن توهان پنهنجي بلاڪچين تي PVRB ٺاهي رهيا آهيو، توهان گهڻو ڪري ختم ٿي ويندا BLS حد جي دستخط اسڪيم سان، ڪيترائي منصوبا اڳ ۾ ئي استعمال ڪري رهيا آهن. مثال طور، DFinity (هتي بينچ مارڪ جيڪو سرڪٽ کي لاڳو ڪري ٿو، ۽ هتي مثال طور تصديق ٿيل ڳجهي شيئرنگ جو نفاذ)، يا Keep.network (هتي انهن جي بي ترتيب بيڪن آهي پيلو پيپر۽ هتي مثال سمارٽ معاهدو پروٽوڪول جي خدمت ڪندي).

PVRB جو نفاذ

بدقسمتي سان، اسان اڃا تائين PVRB بلاڪچين ۾ لاڳو ڪيل تيار ڪيل پروٽوڪول نه ڏسي رهيا آهيون جيڪا ان جي حفاظت ۽ استحڪام کي ثابت ڪيو آهي. جيتوڻيڪ پروٽوڪول پاڻ تيار آهن، ٽيڪنالاجي طور انهن کي موجوده حلن تي لاڳو ڪرڻ آسان ناهي. مرڪزي نظامن لاءِ، PVRB مطلب نٿو رکي، ۽ decentralized وارا سختي سان سڀني ڪمپيوٽنگ وسيلن ۾ محدود آهن: CPU، ميموري، اسٽوريج، I/O. PVRB ڊزائين ڪرڻ مختلف پروٽوڪولن جو هڪ مجموعو آهي ته جيئن ڪجهه ٺاهجي جيڪا گهٽ ۾ گهٽ ڪجهه قابل عمل بلاڪچين لاءِ سڀني گهرجن کي پورو ڪري. ھڪڙو پروٽوڪول وڌيڪ ڪارائتو حساب ڪري ٿو، پر RPs جي وچ ۾ وڌيڪ پيغامن جي ضرورت آھي، جڏھن ته ٻئي کي تمام ٿورن پيغامن جي ضرورت آھي، پر ثبوت ٺاھڻ ھڪڙو ڪم ٿي سگھي ٿو جيڪو ڏھ منٽ، يا ڪلاڪ کان وٺي.

آئون انهن عنصرن جي فهرست ڏيندس جيڪي توهان کي غور ڪرڻو پوندو جڏهن معيار PVRB چونڊيو:

• Cryptographic طاقت. توهان جي PVRB کي سختي سان غيرجانبدار هجڻ گهرجي، هڪ بٽ کي ڪنٽرول ڪرڻ جي صلاحيت سان. ڪجهه اسڪيمن ۾ اهو معاملو نه آهي، تنهنڪري هڪ cryptographer سڏ
• "آخري اداڪار" مسئلو. توهان جي PVRB حملن جي خلاف مزاحمتي هجڻ گهرجي جتي هڪ يا وڌيڪ RPs تي ڪنٽرول ڪندڙ حملي آور ٻن نتيجن مان هڪ کي چونڊي سگهي ٿو.
• پروٽوڪول جي تباهي جو مسئلو. توهان جو PVRB حملن جي خلاف مزاحمتي هجڻ گهرجي جتي هڪ يا وڌيڪ RPs تي ڪنٽرول ڪندڙ حملي آور فيصلو ڪري ٿو ته بي ترتيب هجڻ يا نه ۽ يا ته ضمانت ٿي سگهي ٿي يا ان تي اثر انداز ٿيڻ لاءِ ڏنل امڪان سان.
• پيغامن جو تعداد مسئلو. توهان جي آر پيز کي بلاڪ چين ڏانهن گهٽ ۾ گهٽ پيغام موڪلڻ گهرجي ۽ جيترو ممڪن ٿي سگهي هم وقت سازي جي عملن کان پاسو ڪرڻ گهرجي جيئن ته حالتون جهڙوڪ ”مون ڪجهه معلومات موڪلي آهي، مان هڪ مخصوص شرڪت ڪندڙ جي جواب جو انتظار ڪري رهيو آهيان. p2p نيٽ ورڪن ۾، خاص طور تي جغرافيائي طور تي منتشر، توهان کي تڪڙو جواب تي ڳڻڻ نه گهرجي
• ڪمپيوٽر جي پيچيدگي جو مسئلو. PVRB آن-چين جي ڪنهن به مرحلي جي تصديق انتهائي آسان هجڻ گهرجي، ڇاڪاڻ ته اهو نيٽ ورڪ جي سڀني مڪمل گراهڪن طرفان ڪيو ويندو آهي. جيڪڏهن عملدرآمد سمارٽ معاهدو استعمال ڪندي ڪيو ويو آهي، پوء رفتار جون گهرجون تمام سخت آهن
• رسائي ۽ زندگي جو مسئلو. توهان جي PVRB کي انهن حالتن ۾ لچڪدار ٿيڻ جي ڪوشش ڪرڻ گهرجي جتي نيٽ ورڪ جو حصو ڪجهه عرصي لاءِ دستياب نه ٿئي ۽ RP جو حصو صرف ڪم ڪرڻ بند ڪري.
• قابل اعتماد سيٽ اپ ۽ شروعاتي ڪي ورهائڻ جو مسئلو. جيڪڏهن توهان جو PVRB استعمال ڪري ٿو پروٽوڪول جي بنيادي سيٽ اپ، پوء اهو هڪ الڳ وڏي ۽ سنجيده ڪهاڻي آهي. هتي مثال. جيڪڏهن شرڪت ڪندڙن کي پروٽوڪول شروع ڪرڻ کان پهريان هڪ ٻئي کي پنهنجون چاٻيون ٻڌائڻ گهرجن، اهو پڻ هڪ مسئلو آهي جيڪڏهن شرڪت ڪندڙن جو ٺهيل تبديل ٿي وڃي
• ترقي جا مسئلا. گهربل ٻولين ۾ لائبريرين جي دستيابي، انهن جي حفاظت ۽ ڪارڪردگي، پبلسٽي، پيچيده ٽيسٽ، وغيره.

مثال طور، حد BLS دستخطن ۾ ھڪ اھم مسئلو آھي - ڪم ڪرڻ شروع ڪرڻ کان پھريائين، شرڪت ڪندڙن کي ھڪ ٻئي ڏانھن ڪنجيون ورهائڻ گهرجن، ھڪڙي گروپ کي منظم ڪرڻ، جنھن ۾ حد ڪم ڪندي. ان جو مطلب اهو آهي ته گهٽ ۾ گهٽ هڪ دور جي بدلي جي هڪ غير مرڪزي نيٽ ورڪ ۾ انتظار ڪرڻو پوندو، ۽ ڏنو ويو آهي ته ٺاهيل رينڊ، مثال طور، راندين ۾ ضروري آهي، تقريبا حقيقي وقت ۾، هن جو مطلب آهي ته پروٽوڪول جي تباهي هن مرحلي ۾ ممڪن آهي. ، ۽ حد جي اسڪيم جا فائدا گم ٿي ويا آهن. اهو مسئلو اڳين مسئلن جي ڀيٽ ۾ اڳ ۾ ئي آسان آهي، پر اڃا تائين حد جي گروهن جي ٺهڻ لاء هڪ الڳ طريقيڪار جي ترقي جي ضرورت آهي، جنهن کي اقتصادي طور تي محفوظ ڪرڻو پوندو، جمع ڪرڻ ۽ فنڊ جي واپسي جي ذريعي (سليشنگ) شرڪت ڪندڙن کان جيڪي پيروي نٿا ڪن. پروٽوڪول انهي سان گڏ، سيڪيورٽي جي قابل قبول سطح سان BLS جي تصديق آسان ناهي، مثال طور، هڪ معياري EOS يا Ethereum ٽرانزيڪشن ۾ - تصديق لاء ڪافي وقت نه آهي. معاهدو ڪوڊ WebAssembly يا EVM آهي، جيڪو ورچوئل مشين ذريعي ڪيو ويندو آهي. Cryptographic functions مقامي طور تي (اڃا تائين) لاڳو نه ڪيا ويا آهن، ۽ روايتي ڪرپٽوگرافڪ لائبريرين جي ڀيٽ ۾ ڏهه ڀيرا سست ڪم ڪن ٿا. گھڻا پروٽوڪول ضرورتن کي پورا نه ٿا ڪن صرف بنيادي حجم جي بنياد تي، مثال طور 1024 ۽ 2048 بٽس RSA لاءِ، Bitcoin ۽ Ethereum ۾ معياري ٽرانزيڪشن جي دستخط کان 4-8 ڀيرا وڏو.

مختلف پروگرامنگ ٻولين ۾ عملدرآمد جي موجودگي پڻ ڪردار ادا ڪري ٿي - جن مان ڪجھ آھن، خاص طور تي نئين پروٽوڪول لاء. اتفاق سان انضمام سان اختيار کي پليٽ فارم جي ٻولي ۾ پروٽوڪول لکڻ جي ضرورت آهي، تنهنڪري توهان کي ڪوڊ ڳولڻو پوندو Go for gath ۾، Rust for Parity ۾، C++ ۾ EOS لاءِ. هر ڪنهن کي جاوا اسڪرپٽ ڪوڊ ڳولڻو پوندو، ۽ جيئن ته جاوا اسڪرپٽ ۽ ڪرپٽوگرافي خاص طور تي ويجها دوست نه آهن، WebAssembly مدد ڪندي، جيڪا هاڻي يقيني طور تي دعوي ڪري ٿي ته ايندڙ اهم انٽرنيٽ معيار.

ٿڪل

مون کي اميد آهي ته اڳئين ۾ مضمون مان توهان کي قائل ڪرڻ ۾ ڪامياب ٿي ويو آهيان ته بلاڪچين تي بي ترتيب نمبر پيدا ڪرڻ غير مرڪزي نيٽ ورڪ جي زندگيء جي ڪيترن ئي حصن لاء اهم آهي، ۽ هن آرٽيڪل سان مون ڏيکاريو ته اهو ڪم انتهائي مهانگو ۽ ڏکيو آهي، پر سٺو حل اڳ ۾ ئي موجود آهن. عام طور تي، پروٽوڪول جي آخري ڊيزائن وڏي پيماني تي ٽيسٽ ڪرڻ کان پوءِ ئي ممڪن آهي، جيڪي سيٽ اپ کان وٺي غلطي ايموليشن تائين سڀني پهلوئن کي مدنظر رکن ٿا، تنهنڪري توهان کي ٽيم جي وائيٽ پيپرز ۽ آرٽيڪلز ۾ تيار ڪيل ترڪيبون ڳولڻ جو امڪان ناهي، ۽ اسان ضرور نه ڪنداسين. فيصلو ڪريو ايندڙ سال يا ٻن ۾ لکو "ان کي ائين ڪريو، بلڪل صحيح."

الوداع، اسان جي PVRB لاءِ بلاڪ چين ۾ ترقي ڪئي پئي وڃي Haya, اسان حد تائين BLS دستخط استعمال ڪرڻ تي آباد ٿيا آهيون، اسان اتفاق جي سطح تي PVRB کي لاڳو ڪرڻ جو منصوبو ٺاهيو، ڇو ته سمارٽ معاهدي ۾ تصديق جي قابل قبول سطح سان اڃا ممڪن ناهي. اهو ممڪن آهي ته اسان هڪ ئي وقت ۾ ٻه اسڪيمون استعمال ڪريون: پهريون، مهانگو ڳجهو شيئرنگ ڊگھي مدي واري random_seed ٺاهڻ لاءِ، ۽ پوءِ اسان ان کي استعمال ڪريون ٿا بي ترتيب واري اعليٰ تعدد واري نسل لاءِ بي بنياد حد جي بي ايل ايس دستخطن کي استعمال ڪندي، شايد اسان پاڻ کي محدود ڪري ڇڏينداسين. منصوبن مان هڪ. بدقسمتي سان، اڳ ۾ اهو چوڻ ناممڪن آهي ته پروٽوڪول ڇا هوندو؛ صرف سٺي شيء اها آهي ته، سائنس ۾، انجنيئرنگ جي مسئلن ۾، هڪ منفي نتيجو پڻ آهي، ۽ هر نئين ڪوشش جو مسئلو حل ڪرڻ لاء هڪ ٻيو قدم آهي. مسئلي ۾ ملوث هر ڪنهن جي تحقيق. ڪاروباري گهرجون پوريون ڪرڻ لاءِ، اسان هڪ خاص عملي مسئلو حل ڪريون ٿا- گيمنگ ايپليڪيشنون مهيا ڪرڻ جو هڪ قابل اعتماد ذريعو اينٽراپي سان، تنهن ڪري اسان کي پاڻ کي بلاڪچين تي به ڌيان ڏيڻو پوندو، خاص طور تي زنجير جي فائنل ۽ نيٽ ورڪ گورننس جا مسئلا.

۽ جيتوڻيڪ اسان اڃا تائين بلاڪچين ۾ هڪ ثابت مزاحمتي PVRB نه ٿا ڏسو، جيڪو حقيقي ايپليڪيشنن، گهڻن آڊٽ، لوڊ، ۽ يقينا، حقيقي حملن جي آزمائش لاء ڪافي وقت استعمال ڪيو ويندو، پر ممڪن رستن جو تعداد ان جي تصديق ڪري ٿو. ھڪڙو حل موجود آھي، ۽ انھن مان ڪھڙا الگورتھم آخرڪار مسئلو حل ڪندا. اسان نتيجن کي حصيداري ڪرڻ ۾ خوش ٿينداسين ۽ ٻين ٽيمن جو شڪرگذار ڪنداسين جيڪي پڻ هن مسئلي تي آرٽيڪل ۽ ڪوڊ لاء ڪم ڪري رهيا آهن جيڪي انجنيئرز کي ٻه ڀيرا ساڳئي ريڪ تي قدم نه رکڻ جي اجازت ڏين ٿيون.

تنهن ڪري، جڏهن توهان هڪ پروگرامر سان ملن ٿا جيڪو غير معياري ترتيب سان ترتيب ڏئي رهيو آهي، محتاط ۽ خيال رکو، ۽ ضروري هجي ته نفسياتي مدد فراهم ڪريو :)

جو ذريعو: www.habr.com