هيلو، مان ڊي آر ڊي ڪي پي پروجيڪٽ جي ٽيم ۾ ڪم ڪريان ٿو (وييل سيٽ جي لائف سائيڪل جي نگراني لاءِ ورهايل ڊيٽا رجسٽري). هتي مان هن پروجيڪٽ لاءِ ٽيڪنالاجي جي پابندين تحت هڪ انٽرنيشنل بلاڪچين ٺاهڻ ۾ اسان جي ٽيم جي تجربي کي حصيداري ڪرڻ چاهيان ٿو. مان گهڻو ڪري ڳالهائيندس هائپرليجر فيبرڪ جي باري ۾، پر هتي بيان ڪيل طريقي سان ڪنهن به اجازت ڏنل بلاڪچين ڏانهن وڌايو وڃي ٿو. اسان جي تحقيق جو آخري مقصد اهو آهي ته انٽرپرائز بلاڪچين حل تيار ڪيو وڃي ته جيئن فائنل پراڊڪٽ استعمال ڪرڻ ۾ خوشگوار هجي ۽ برقرار رکڻ تمام ڏکيو نه هجي.
هتي ڪا به دريافت نه ٿيندي، غير متوقع حل، ۽ نه ئي ڪا منفرد ترقي هتي نمايان ڪئي ويندي (ڇاڪاڻ ته مون وٽ ناهي). مان صرف پنهنجو معمولي تجربو حصيداري ڪرڻ چاهيان ٿو، ڏيکاريو ته "اهو ممڪن هو" ۽، شايد، ٻين ماڻهن جي تجربن جي باري ۾ پڙهو سٺو ۽ نه سٺا فيصلا تبصرن ۾.
مسئلو: Blockchains اڃا تائين ماپ نه ڪندا آھن
اڄ، ڪيترن ئي ڊولپرز جي ڪوششن جو مقصد بلاڪچين کي هڪ حقيقي آسان ٽيڪنالاجي ٺاهڻ جو مقصد آهي، ۽ هڪ خوبصورت لفافي ۾ ٽائيم بم نه آهي. رياستي چينل، پراميد رول اپ، پلازما ۽ شارڊنگ شايد عام ٿي ويندا. ڪجهه ڏينهن. يا شايد TON وري ڇهن مهينن لاءِ لانچ کي ملتوي ڪندو، ۽ ايندڙ پلازما گروپ موجود ٿيڻ بند ٿي ويندو. اسان ايندڙ روڊ ميپ تي يقين ڪري سگهون ٿا ۽ رات جو شاندار سفيد ڪاغذ پڙهي سگهون ٿا، پر هتي ۽ هاڻي اسان کي ڪجهه ڪرڻ جي ضرورت آهي جيڪو اسان وٽ آهي. ڪم ڪر.
موجوده پروجيڪٽ ۾ اسان جي ٽيم لاءِ ٽاسڪ سيٽ عام طور تي هن طرح نظر اچي ٿو: اهڙا ڪيترائي مضمون آهن، ڪيترن ئي هزارن تائين پهچن ٿا، جيڪي اعتماد تي رشتا قائم ڪرڻ نٿا چاهين؛ اهو ضروري آهي ته ڊي ايل ٽي تي هڪ حل ٺاهيو جيڪو عام پي سي تي ڪم ڪندو بغير ڪنهن خاص ڪارڪردگي گهرجن ۽ صارف جو تجربو مهيا ڪندو ڪنهن به مرڪزي اڪائونٽنگ سسٽم کان وڌيڪ خراب ناهي. حل جي پويان ٽيڪنالاجي کي لازمي طور تي ڊيٽا جي بدڪاري واري ڦيرڦار جي امڪان کي گھٽائڻ گهرجي - اهو ئي سبب آهي ته blockchain هتي آهي.
سفيد ڪاغذن مان نعرا ۽ ميڊيا اسان سان واعدو ڪن ٿا ته ايندڙ ترقي اسان کي في سيڪنڊ ۾ لکين ٽرانزيڪشن ڪرڻ جي اجازت ڏيندو. اهو واقعي ڇا آهي؟
Mainnet Ethereum هن وقت ~ 30 tps تي هلندڙ آهي. ان جي ڪري اڪيلو، اهو سمجهڻ ڏکيو آهي ته ان کي بلاڪچين طور تي ڪنهن به طريقي سان ڪارپوريٽ ضرورتن لاء مناسب. اجازت ڏنل حلن ۾ اهڙا معيار آهن جيڪي ڏيکاري رهيا آهن 2000 tps () يا 3000 tps (، اشاعت ۾ ٿورڙو گهٽ آهي، پر توهان کي اهو سمجهڻ گهرجي ته معيار پراڻي اتفاق انجڻ تي ڪيو ويو آهي). هئي 20000 tps، جنهن بدترين نتيجا نه ڏنو، پر اڃا تائين اهو صرف علمي تحقيق آهي، ان جي مستحڪم عمل درآمد جي انتظار ۾. اهو ممڪن ناهي ته هڪ ڪارپوريشن جيڪا برداشت ڪري سگهي ٿي بلاڪچين ڊولپرز جي ڊپارٽمينٽ کي برقرار رکڻ لاء اهڙن اشارن سان گڏ. پر مسئلو نه رڳو ذريعي آهي، اتي پڻ دير سان آهي.
لاطيني
دير جي دير کان وٺي هڪ ٽرانزيڪشن شروع ڪئي وئي آهي سسٽم طرفان ان جي حتمي منظوري تائين نه رڳو ان رفتار تي منحصر آهي جنهن تي پيغام جي تصديق ۽ ترتيب جي سڀني مرحلن مان گذري ٿو، پر بلاڪ ٺهڻ جي پيراگراف تي پڻ. جيتوڻيڪ اسان جي بلاڪچين اسان کي 1000000 tps جي رفتار سان ڪم ڪرڻ جي اجازت ڏئي ٿي، پر 10 MB بلاڪ ٺاهڻ لاء 488 منٽن جي ضرورت آهي، ڇا اهو اسان لاء آسان ٿيندو؟
اچو ته هڪ ويجھو نظر رکون ٽرانزيڪشن لائف سائيڪل تي Hyperledger Fabric ۾ سمجھڻ لاءِ ته وقت ڪٿي خرچ ٿئي ٿو ۽ اهو ڪيئن تعلق رکي ٿو بلاڪ نسل جي پيٽرولن سان.
هتان کان ورتو:
(1) ڪلائنٽ هڪ ٽرانزيڪشن ٺاهي ٿو، ان کي تصديق ڪندڙ ساٿين ڏانهن موڪلي ٿو، بعد ۾ ٽرانزيڪشن کي نقل ڪري ٿو (موجوده حالت ۾ چين ڪوڊ پاران ڪيل تبديلين کي لاڳو ڪريو، پر ليجر سان انجام نه ڏيو) ۽ RWSet وصول ڪريو - اهم نالا، نسخو ۽ قدر CouchDB ۾ گڏ ڪيل جمعن مان ورتو ويو، (2) تصديق ڪندڙ واپس موڪلي ٿو هڪ دستخط ٿيل RWSet ڪلائنٽ ڏانهن، (3) ڪلائنٽ يا ته سڀني ضروري ساٿين جي دستخط جي موجودگي جي جانچ ڪري ٿو (تصديق ڪندڙ)، ۽ پوء ٽرانزيڪشن کي آرڊرنگ سروس ڏانهن موڪلي ٿو. ، يا ان کي بغير تصديق جي موڪلي ٿو (چڪ اڃا به بعد ۾ ٿيندي)، آرڊرنگ سروس هڪ بلاڪ ٺاهي ٿي ۽ (4) سڀني ساٿين کي واپس موڪلي ٿي، نه صرف تصديق ڪندڙ؛ peers چيڪ ڪن ٿا ته پڙهيل سيٽ ۾ اهم ورزن ڊيٽابيس ۾ ورجن سان ملن ٿا، ته سڀني تصديق ڪندڙن جا دستخط آهن، ۽ آخرڪار بلاڪ کي انجام ڏيو.
پر اهو سڀ ڪجهه ناهي. لفظ "آرڊرر هڪ بلاڪ ٺاهي ٿو" نه رڳو ٽرانزيڪشن جي ترتيب کي لڪايو، پر 3 ترتيب واري نيٽ ورڪ جي درخواستن کي ليڊر کان پوئلڳن ڏانهن ۽ واپس: ليڊر لاگ ۾ هڪ پيغام شامل ڪري ٿو، ان کي پوئلڳن ڏانهن موڪلي ٿو، بعد ۾ ان کي شامل ڪري ٿو. انهن جي لاگ ڏانهن، ليڊر کي ڪامياب نقل جي تصديق موڪلي ٿو، ليڊر پيغام موڪلي ٿو، پيروي ڪندڙن کي تصديق جي تصديق موڪلي ٿو، پيروڪار انجام ڏين ٿا. بلاڪ ٺهڻ جو سائز ۽ وقت جيترو ننڍو هوندو، اوترو ئي آرڊرنگ سروس کي اتفاق راءِ قائم ڪرڻو پوندو. Hyperledger Fabric ۾ بلاڪ ٺاھڻ لاءِ ٻه پيٽرول آھن: BatchTimeout - بلاڪ ٺاھڻ جو وقت ۽ BatchSize - بلاڪ سائيز (ٽرانزيڪشن جو تعداد ۽ بلاڪ جي سائيز بائيٽ ۾ پاڻ). جيترو جلد ئي هڪ پيراگراف جي حد تائين پهچي ٿو، هڪ نئون بلاڪ جاري ڪيو ويو آهي. وڌيڪ آرڊر نوڊس، اهو وڌيڪ وقت وٺندو. تنهن ڪري، توهان کي BatchTimeout ۽ BatchSize وڌائڻ جي ضرورت آهي. پر جيئن ته RWSets ورجن ٿيل آهن، اسان جيترو وڏو بلاڪ ٺاهينداسين، اوترو ئي وڌيڪ MVCC تڪرار جو امڪان. اضافي طور تي، BatchTimeout وڌائي ٿو، UX تباهيء سان خراب ٿئي ٿي. انهن مسئلن کي حل ڪرڻ لاءِ هيٺ ڏنل اسڪيم مون لاءِ معقول ۽ واضح لڳي ٿي.
بلاڪ کي حتمي شڪل ڏيڻ جي انتظار کان ڪيئن بچجي ۽ ٽرانزيڪشن جي صورتحال کي ٽريڪ ڪرڻ جي صلاحيت نه وڃايو
ٺهڻ جو وقت ۽ بلاڪ سائيز جيترو ڊگهو هوندو، اوترو ئي وڌيڪ بلاڪچين جي ذريعي. هڪ ٻئي کان سڌو سنئون نه آهي، پر اهو ياد رکڻ گهرجي ته RAFT ۾ اتفاق راء قائم ڪرڻ جي ضرورت آهي ٽي نيٽ ورڪ جي درخواستن جي اڳواڻ کان پوئلڳن ۽ پوئتي ڏانهن. وڌيڪ آرڊر نوڊس، اهو وڌيڪ وقت وٺندو. بلاڪ ٺهڻ جي سائيز ۽ وقت جيتري ننڍي هوندي، اوترو وڌيڪ اهڙيون ڳالهيون آهن. آخر صارف لاءِ سسٽم جي جوابي وقت کي وڌائڻ کان سواءِ نسل جي وقت ۽ بلاڪ سائيز کي ڪيئن وڌايو وڃي؟
پهرين، اسان کي ڪنهن به طريقي سان MVCC تڪرار کي حل ڪرڻ جي ضرورت آهي جيڪا وڏي بلاڪ سائيز جي ڪري ٿي سگهي ٿي، جنهن ۾ شايد ساڳئي نسخ سان مختلف RWSets شامل هجن. ظاهر آهي، ڪلائنٽ جي پاسي (بلاڪچين نيٽ ورڪ جي حوالي سان، اهو سٺو پس منظر ٿي سگهي ٿو، ۽ منهنجو مطلب اهو آهي) توهان کي ضرورت آهي MVCC تڪرار سنڀاليندڙ، جيڪا يا ته ٿي سگهي ٿي هڪ الڳ خدمت يا هڪ باقاعده سينگار ڪندڙ ڪال جي مٿان جيڪا ٽرانزيڪشن کي ٻيهر ڪوشش منطق سان شروع ڪري ٿي.
ٻيهر ڪوشش ڪري سگهجي ٿي لاڳو ٿي سگهي ٿو هڪ توسيع واري حڪمت عملي سان، پر پوءِ دير ٿي ويندي ايتري ئي تيزيءَ سان. تنهن ڪري توهان کي استعمال ڪرڻ گهرجي يا ته بي ترتيب ٿيل ٻيهر ڪوشش ڪجهه ننڍين حدن اندر، يا هڪ مسلسل. پهرين اختيار ۾ ممڪن collisions تي نظر سان.
اڳيون قدم آهي ڪلائنٽ جي رابطي کي سسٽم سان هم وقت سازي ڪرڻ آهي ته جيئن اهو 15، 30 يا 10000000 سيڪنڊن جو انتظار نه ڪري، جنهن کي اسين BatchTimeout طور سيٽ ڪنداسين. پر ساڳئي وقت، ان جي تصديق ڪرڻ جي صلاحيت کي برقرار رکڻ ضروري آهي ته ٽرانزيڪشن پاران شروع ڪيل تبديليون بلاڪچين ۾ رڪارڊ ٿيل نه آهن.
هڪ ڊيٽابيس ٽرانزيڪشن جي صورتحال کي ذخيرو ڪرڻ لاء استعمال ڪري سگهجي ٿو. آسان ترين اختيار آهي CouchDB ان جي استعمال جي آسانيءَ جي ڪري: ڊيٽابيس ۾ هڪ UI آهي دٻي مان ٻاهر، هڪ REST API، ۽ توهان آساني سان ان لاءِ نقل ۽ شارڊنگ سيٽ ڪري سگهو ٿا. توهان صرف هڪ ئي CouchDB مثال ۾ هڪ الڳ مجموعو ٺاهي سگهو ٿا جيڪو پنهنجي دنيا جي رياست کي محفوظ ڪرڻ لاءِ فيبرڪ استعمال ڪري ٿو. اسان کي انهن قسمن جا دستاويز رکڻ گهرجن.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}هي دستاويز ڊيٽابيس ڏانهن لکيو ويو آهي ان کان اڳ جو ٽرانزيڪشن ڀائيوارن ڏانهن موڪليو وڃي، اداري جي ID واپس ڪئي وئي آهي صارف کي (ساڳي ID کي استعمال ڪيو ويندو آهي ڪيچ) جيڪڏهن اهو هڪ تخليق آپريشن آهي، ۽ پوء اسٽيٽس، TxID ۽ غلطي جا شعبا آهن. اپڊيٽ ڪيو ويو جيئن لاڳاپيل معلومات ساٿين کان ملي ٿي.
هن اسڪيم ۾، صارف بلاڪ جي آخر ۾ ٺهڻ جو انتظار نٿو ڪري، 10 سيڪنڊن لاءِ اسڪرين تي اسپننگ ويل کي ڏسي، هن کي سسٽم کان فوري جواب ملي ٿو ۽ ڪم جاري رکي ٿو.
اسان ٽرانزيڪشن اسٽيٽس کي ذخيرو ڪرڻ لاءِ BoltDB چونڊيو آهي ڇو ته اسان کي ميموري کي بچائڻ جي ضرورت آهي ۽ هڪ الڳ ڊيٽابيس سرور سان نيٽ ورڪ رابطي تي وقت ضايع ڪرڻ نٿا چاهيون، خاص طور تي جڏهن اهو معاملو هڪ سادي متن پروٽوڪول استعمال ڪندي ٿئي ٿو. رستي ۾، ڇا توهان مٿي بيان ڪيل اسڪيم کي لاڳو ڪرڻ لاءِ CouchDB استعمال ڪندا آهيو يا صرف دنيا جي رياست کي محفوظ ڪرڻ لاءِ، ڪنهن به صورت ۾ اهو سمجھ ۾ اچي ٿو ته طريقي سان ڊيٽا کي CouchDB ۾ محفوظ ڪيو وڃي. ڊفالٽ طور، CouchDB ۾، b-tree nodes جي سائيز 1279 bytes آهي، جيڪا ڊسڪ تي شعبي جي سائيز کان تمام ننڍو آهي، جنهن جو مطلب آهي ته وڻ کي پڙهڻ ۽ ٻيهر توازن ڪرڻ لاءِ ڊسڪ تائين وڌيڪ جسماني رسائي جي ضرورت پوندي. بهترين ماپ معيار سان ملندو آهي ۽ 4 ڪلو بائيٽ آهي. بهتر ڪرڻ لاءِ اسان کي پيراميٽر مقرر ڪرڻو پوندو btree_chunk_size برابر 4096 CouchDB ترتيب واري فائل ۾. BoltDB اهڙي دستي مداخلت لاء .
پوئتي دٻاء: بفر حڪمت عملي
پر اتي ڪيترائي پيغام ٿي سگھن ٿا. سسٽم کان وڌيڪ سنڀالي سگھي ٿو، وسيلا شيئر ڪرڻ سان گڏ درجنين ٻين خدمتن سان گڏ جيڪي ڊاگرام ۾ ڏيکاريل آهن - ۽ اهو سڀ ڪجهه بي عيب ڪم ڪرڻ گهرجي جيتوڻيڪ انهن مشينن تي جن تي Intellij Idea هلائڻ انتهائي مشڪل هوندو.
مواصلاتي نظام جي مختلف صلاحيت جو مسئلو، پيدا ڪندڙ ۽ صارف، مختلف طريقن سان حل ڪيو ويو آهي. اچو ته ڏسون ته اسان ڇا ڪري سگهون ٿا.
لهڻ: اسان دعوي ڪري سگهون ٿا ته اسان T سيڪنڊن ۾ سڀ کان وڌيڪ ايڪس ٽرانزيڪشن تي پروسيسنگ ڪرڻ جي قابل آهيون. هن حد کان وڌيڪ سڀ درخواستون رد ڪيون ويون آهن. اهو بلڪل سادو آهي، پر پوء توهان UX بابت وساري سگهو ٿا.
ڪنٽرول ڪرڻ: صارف وٽ ڪجهه قسم جو انٽرفيس هجڻ گهرجي جنهن ذريعي، لوڊ تي منحصر ڪري، هو پيدا ڪندڙ جي TPS کي ڪنٽرول ڪري سگهي ٿو. خراب ناهي، پر اهو ڪلائنٽ جي ڊولپرز تي ذميواريون لاڳو ڪري ٿو جيڪو هن انٽرفيس کي لاڳو ڪرڻ لاء لوڊ ٺاهي ٿو. اهو اسان لاءِ ناقابل قبول آهي، ڇو ته بلاڪچين مستقبل ۾ وڏي تعداد ۾ ڊگھي موجود نظامن ۾ ضم ٿي ويندي.
ٽهڪڻ: ان پٽ ڊيٽا اسٽريم کي مزاحمت ڪرڻ جي بدران، اسان هن وهڪرو کي بفر ڪري سگھون ٿا ۽ ان کي گهربل رفتار تي پروسيس ڪري سگهون ٿا. ظاهر آهي اهو بهترين حل آهي جيڪڏهن اسان چاهيون ٿا ته سٺو صارف تجربو. اسان RabbitMQ ۾ قطار استعمال ڪندي بفر کي لاڳو ڪيو.
اسڪيم ۾ ٻه نوان ڪارناما شامل ڪيا ويا آهن: (1) API جي درخواست اچڻ کان پوءِ، ٽرانزيڪشن کي ڪال ڪرڻ لاءِ ضروري پيرا ميٽرن سان گڏ هڪ پيغام قطار ۾ رکيل آهي، ۽ ڪلائنٽ کي پيغام ملي ٿو ته ٽرانزيڪشن قبول ڪئي وئي آهي. سسٽم، (2) پس منظر ڊيٽا کي قطار مان ترتيب ۾ بيان ڪيل رفتار تي پڙهي ٿو؛ هڪ ٽرانزيڪشن شروع ڪري ٿو ۽ اسٽيٽس اسٽور ۾ ڊيٽا کي اپڊيٽ ڪري ٿو.
ھاڻي توھان وڌائي سگھوٿا ٺاھڻ جو وقت ۽ بلاڪ جي ظرفيت جيترو توھان چاھيو، صارف کان دير لڪائي.
ٻيا اوزار
هتي chaincode بابت ڪجھ به نه چيو ويو آهي، ڇاڪاڻ ته، ضابطي جي طور تي، ان ۾ بهتر ڪرڻ لاء ڪجھ به ناهي. Chaincode کي ممڪن طور تي سادو ۽ محفوظ هجڻ گهرجي - اهو سڀ ڪجهه ان جي گهربل آهي. فريم ورڪ اسان کي آسان ۽ محفوظ طور تي زنجير ڪوڊ لکڻ ۾ مدد ڪري ٿو S7 Techlab ۽ جامد تجزيي کان .
ان کان علاوه، اسان جي ٽيم يوٽيلٽيز جو هڪ سيٽ تيار ڪري رهي آهي ته جيئن فيبرڪ سان ڪم ڪرڻ آسان ۽ لطف اندوز ٿئي: ، لاءِ هڪ افاديت (شامل ڪرڻ/هٽائڻ تنظيمون، RAFT نوڊس)، يوٽيلٽي لاءِ . جيڪڏھن توھان حصو ڏيڻ چاھيو ٿا، توھان کي ڀليڪار آھي.
ٿڪل
اهو طريقو توهان کي آساني سان Hyperledger Fabric کي Quorum سان تبديل ڪرڻ جي اجازت ڏئي ٿو، ٻين نجي ايٿيريم نيٽ ورڪن (PoA يا اڃا به PoW)، خاص طور تي حقيقي throughput کي گهٽايو، پر ساڳئي وقت عام UX برقرار رکون ٿا (ٻنهي برائوزر ۾ استعمال ڪندڙن لاءِ ۽ مربوط سسٽم لاءِ). جڏهن اسڪيم ۾ فيبرڪ کي Ethereum سان تبديل ڪيو وڃي، توهان کي صرف MVCC تڪرارن جي پروسيسنگ کان وٺي ٻيهر ڪوشش ڪرڻ جي خدمت / سجاڳي جي منطق کي تبديل ڪرڻ جي ضرورت پوندي ايٽمي غير معمولي واڌ ۽ ٻيهر موڪلڻ تائين. بفرنگ ۽ اسٽيٽس اسٽوريج ان کي ممڪن بڻايو ته جوابي وقت کي بلاڪ ٺهڻ واري وقت کان ڊيڪول ڪرڻ. ھاڻي توھان ھزارين آرڊر نوڊس شامل ڪري سگھو ٿا ۽ ڊپ نه ٿيو ته بلاڪ اڪثر ٺھيل آھن ۽ آرڊرنگ سروس لوڊ ڪريو.
بنيادي طور تي، اهو سڀ ڪجهه آهي جيڪو مان حصيداري ڪرڻ چاهيان ٿو. مون کي خوشي ٿي ويندي جيڪڏهن هي ڪنهن کي پنهنجي ڪم ۾ مدد ڪري.
جو ذريعو: www.habr.com