وہیل سیٹس کے لیے تقسیم شدہ رجسٹری: ہائپرلیجر فیبرک کے ساتھ ایک تجربہ

ہیلو، میں DRD KP پروجیکٹ کی ٹیم میں کام کرتا ہوں (وہیل سیٹ کے لائف سائیکل کی نگرانی کے لیے تقسیم شدہ ڈیٹا رجسٹری)۔ یہاں میں ٹیکنالوجی کی رکاوٹوں کے تحت اس پروجیکٹ کے لیے ایک انٹرپرائز بلاک چین تیار کرنے میں اپنی ٹیم کے تجربے کا اشتراک کرنا چاہتا ہوں۔ میں زیادہ تر Hyperledger Fabric کے بارے میں بات کروں گا، لیکن یہاں بیان کردہ نقطہ نظر کو کسی بھی اجازت یافتہ بلاکچین میں بڑھایا جا سکتا ہے۔ ہماری تحقیق کا حتمی مقصد انٹرپرائز بلاک چین سلوشنز تیار کرنا ہے تاکہ حتمی پروڈکٹ استعمال میں خوشگوار ہو اور اسے برقرار رکھنا زیادہ مشکل نہ ہو۔

یہاں کوئی دریافتیں نہیں ہوں گی، غیر متوقع حل ہوں گے، اور یہاں کوئی منفرد پیش رفت کو نمایاں نہیں کیا جائے گا (کیونکہ میرے پاس کوئی نہیں ہے)۔ میں صرف اپنے معمولی تجربے کا اشتراک کرنا چاہتا ہوں، یہ ظاہر کرنا چاہتا ہوں کہ "یہ ممکن تھا" اور، شاید، تبصروں میں اچھے اور اتنے اچھے فیصلے نہ کرنے کے دوسرے لوگوں کے تجربات کے بارے میں پڑھنا چاہتا ہوں۔

مسئلہ: بلاک چینز ابھی تک پیمانہ نہیں ہیں۔

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

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

وائٹ پیپرز اور میڈیا کے نعرے ہم سے وعدہ کرتے ہیں کہ اگلی ترقی ہمیں فی سیکنڈ لاکھوں لین دین کرنے کی اجازت دے گی۔ یہ واقعی کیا ہے؟

Mainnet Ethereum فی الحال ~30 tps پر چل رہا ہے۔ صرف اس کی وجہ سے، اسے کسی بھی طرح سے کارپوریٹ ضروریات کے لیے موزوں بلاکچین کے طور پر سمجھنا مشکل ہے۔ اجازت یافتہ حلوں میں ایسے بینچ مارکس ہیں جو 2000 tps دکھا رہے ہیں (Quorum) یا 3000 ٹی پی ایس (Hyperledger فیبرک، اشاعت میں تھوڑا سا کم ہے، لیکن آپ کو اس بات کو ذہن میں رکھنا ہوگا کہ بینچ مارک پرانے متفقہ انجن پر کیا گیا تھا)۔ تھا ریڈیکل فیبرک پروسیسنگ کی کوشش، جس نے بدترین نتائج نہیں دیے، 20000 tps، لیکن اب تک یہ صرف علمی تحقیق ہے، اس کے مستحکم نفاذ کا انتظار ہے۔ اس بات کا امکان نہیں ہے کہ ایک کارپوریشن جو بلاکچین ڈویلپرز کے شعبہ کو برقرار رکھنے کی استطاعت رکھتی ہو، اس طرح کے اشارے پیش کرے گی۔ لیکن مسئلہ صرف تھرو پٹ کا نہیں ہے، تاخیر بھی ہے۔

تاخیر

سسٹم کے ذریعے ٹرانزیکشن شروع ہونے سے لے کر اس کی حتمی منظوری میں تاخیر کا انحصار نہ صرف اس رفتار پر ہوتا ہے جس سے پیغام کی توثیق اور ترتیب کے تمام مراحل سے گزرتا ہے، بلکہ بلاک کی تشکیل کے پیرامیٹرز پر بھی ہوتا ہے۔ یہاں تک کہ اگر ہمارا بلاکچین ہمیں 1000000 tps کی رفتار سے کمٹمنٹ کرنے کی اجازت دیتا ہے، لیکن 10 MB بلاک بنانے کے لیے 488 منٹ درکار ہیں، تو کیا یہ ہمارے لیے آسان ہو جائے گا؟

آئیے Hyperledger Fabric میں لین دین کے لائف سائیکل پر گہری نظر ڈالتے ہیں تاکہ یہ سمجھ سکیں کہ وقت کہاں گزارا جاتا ہے اور یہ بلاک جنریشن پیرامیٹرز سے کیسے متعلق ہے۔

یہاں سے لیا: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

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

لیکن یہ سب کچھ نہیں ہے۔ "آرڈرر ایک بلاک بناتا ہے" کے الفاظ نہ صرف لین دین کی ترتیب کو چھپاتے ہیں، بلکہ لیڈر سے پیروکاروں تک 3 ترتیب وار نیٹ ورک کی درخواستوں کو بھی چھپاتے ہیں: لیڈر لاگ میں ایک پیغام جوڑتا ہے، پیروکاروں کو بھیجتا ہے، بعد میں اسے شامل کرتا ہے۔ ان کے لاگ پر، لیڈر کو کامیاب نقل کی تصدیق بھیجتا ہے، رہنما پیغام کا ارتکاب کرتا ہے، پیروکاروں کو تصدیق بھیجتا ہے، پیروکار کمٹ کرتے ہیں۔ بلاک کی تشکیل کا سائز اور وقت جتنا چھوٹا ہوگا، آرڈرنگ سروس کو اتفاق رائے قائم کرنا ہوگا۔. Hyperledger Fabric میں بلاک کی تشکیل کے لیے دو پیرامیٹرز ہیں: BatchTimeout - بلاک بنانے کا وقت اور BatchSize - بلاک کا سائز (لین دین کی تعداد اور بلاک کا سائز بائٹس میں)۔ جیسے ہی پیرامیٹرز میں سے ایک حد تک پہنچ جاتا ہے، ایک نیا بلاک جاری کیا جاتا ہے. جتنے زیادہ آرڈر نوڈز، اس میں اتنا ہی زیادہ وقت لگے گا۔ لہذا، آپ کو BatchTimeout اور BatchSize بڑھانے کی ضرورت ہے۔ لیکن چونکہ RWSets کو ورژن بنایا گیا ہے، ہم جتنا بڑا بلاک بناتے ہیں، MVCC تنازعات کا امکان اتنا ہی زیادہ ہوتا ہے۔ اس کے علاوہ، جیسے جیسے BatchTimeout بڑھتا ہے، UX تباہ کن طور پر گرتا جاتا ہے۔ ان مسائل کے حل کے لیے درج ذیل اسکیم میرے لیے معقول اور واضح معلوم ہوتی ہے۔

بلاک کو حتمی شکل دینے کے انتظار سے کیسے بچیں اور لین دین کی حیثیت کو ٹریک کرنے کی صلاحیت سے محروم نہ ہوں۔

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

سب سے پہلے، ہمیں بڑے بلاک سائز کی وجہ سے MVCC تنازعات کو کسی طرح حل کرنے کی ضرورت ہے، جس میں ایک ہی ورژن کے ساتھ مختلف RWSets شامل ہو سکتے ہیں۔ ظاہر ہے، کلائنٹ کی طرف (بلاکچین نیٹ ورک کے سلسلے میں، یہ بیک اینڈ ہو سکتا ہے، اور میرا مطلب ہے) آپ کو ضرورت ہے MVCC تنازعہ ہینڈلرجو کہ یا تو ایک علیحدہ سروس ہو سکتی ہے یا کال کے اوپر ایک باقاعدہ ڈیکوریٹر ہو سکتی ہے جو دوبارہ کوشش کی منطق کے ساتھ لین دین کا آغاز کرتی ہے۔

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

اگلا مرحلہ سسٹم کے ساتھ کلائنٹ کے تعامل کو غیر مطابقت پذیر بنانا ہے تاکہ یہ 15، 30 یا 10000000 سیکنڈز کا انتظار نہ کرے، جسے ہم BatchTimeout کے طور پر سیٹ کریں گے۔ لیکن ایک ہی وقت میں، اس بات کی تصدیق کرنے کی صلاحیت کو برقرار رکھنا ضروری ہے کہ لین دین کے ذریعے شروع کی گئی تبدیلیاں بلاک چین میں درج نہیں ہیں۔
لین دین کی حیثیت کو ذخیرہ کرنے کے لیے ڈیٹا بیس کا استعمال کیا جا سکتا ہے۔ استعمال میں آسانی کی وجہ سے سب سے آسان آپشن CouchDB ہے: ڈیٹا بیس میں ایک UI آؤٹ آف دی باکس، ایک REST API ہے، اور آپ آسانی سے اس کے لیے نقل اور شارڈنگ ترتیب دے سکتے ہیں۔ آپ آسانی سے اسی CouchDB مثال میں ایک علیحدہ مجموعہ بنا سکتے ہیں جو فیبرک کو اس کی عالمی حالت کو ذخیرہ کرنے کے لیے استعمال کرتا ہے۔ ہمیں اس قسم کے دستاویزات کو ذخیرہ کرنے کی ضرورت ہے۔

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

یہ دستاویز ڈیٹابیس پر لکھی جاتی ہے اس سے پہلے کہ لین دین کو ساتھیوں کو بھیجا جائے، ہستی ID صارف کو واپس کر دی جاتی ہے (وہی ID ایک کلید کے طور پر استعمال ہوتی ہے) اگر یہ تخلیق کا عمل ہے، اور پھر Status، TxID اور ایرر فیلڈز ہیں۔ ساتھیوں سے متعلقہ معلومات موصول ہونے پر اپ ڈیٹ کیا جاتا ہے۔

اس اسکیم میں صارف بلاک کے آخر میں بننے کا انتظار نہیں کرتا، 10 سیکنڈ تک سکرین پر گھومنے والے پہیے کو دیکھتا ہے، اسے سسٹم سے فوری جواب ملتا ہے اور وہ کام کرتا رہتا ہے۔

ہم نے لین دین کے سٹیٹس کو ذخیرہ کرنے کے لیے BoltDB کا انتخاب کیا کیونکہ ہمیں میموری کو بچانے کی ضرورت ہے اور ایک علیحدہ ڈیٹا بیس سرور کے ساتھ نیٹ ورک کے تعامل پر وقت ضائع نہیں کرنا چاہتے، خاص طور پر جب یہ تعامل ایک سادہ ٹیکسٹ پروٹوکول کے ذریعے ہوتا ہے۔ ویسے، چاہے آپ CouchDB کا استعمال اوپر بیان کردہ اسکیم کو لاگو کرنے کے لیے کرتے ہیں یا صرف ورلڈ اسٹیٹ کو اسٹور کرنے کے لیے، کسی بھی صورت میں CouchDB میں ڈیٹا کو اسٹور کرنے کے طریقے کو بہتر بنانا سمجھ میں آتا ہے۔ پہلے سے طے شدہ طور پر، CouchDB میں، b-tree نوڈس کا سائز 1279 بائٹس ہے، جو ڈسک پر موجود سیکٹر کے سائز سے بہت چھوٹا ہے، جس کا مطلب ہے کہ درخت کو پڑھنے اور دوبارہ متوازن کرنے کے لیے ڈسک تک زیادہ جسمانی رسائی کی ضرورت ہوگی۔ زیادہ سے زیادہ سائز معیار کے مساوی ہے۔ ایڈوانسڈ فارمیٹ اور 4 کلو بائٹ ہے۔ بہتر بنانے کے لیے ہمیں پیرامیٹر سیٹ کرنے کی ضرورت ہے۔ btree_chunk_size برابر 4096 CouchDB کنفیگریشن فائل میں۔ BoltDB اس طرح کی دستی مداخلت کے لیے ضرورت نہیں.

بیک پریشر: بفر حکمت عملی

لیکن بہت سارے پیغامات ہو سکتے ہیں۔ اس سے زیادہ جو سسٹم ہینڈل کر سکتا ہے، ڈایاگرام میں دکھائی گئی خدمات کے علاوہ ایک درجن دیگر خدمات کے ساتھ وسائل کا اشتراک کرنا - اور یہ سب ان مشینوں پر بھی بے عیب طریقے سے کام کرنا چاہیے جن پر Intellij Idea کو چلانا انتہائی تکلیف دہ ہوگا۔

مواصلاتی نظام، پروڈیوسر اور صارفین کی مختلف صلاحیتوں کا مسئلہ مختلف طریقوں سے حل ہوتا ہے۔ آئیے دیکھتے ہیں کہ ہم کیا کر سکتے ہیں۔

چھوڑنا: ہم دعویٰ کر سکتے ہیں کہ ہم زیادہ تر X ٹرانزیکشنز پر T سیکنڈ میں کارروائی کرنے کے اہل ہیں۔ اس حد سے تجاوز کرنے والی تمام درخواستوں کو مسترد کر دیا جاتا ہے۔ یہ بہت آسان ہے، لیکن پھر آپ UX کو بھول سکتے ہیں۔

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

بفیرنگ: ان پٹ ڈیٹا سٹریم کو روکنے کی کوشش کرنے کے بجائے، ہم اس سلسلے کو بفر کر سکتے ہیں اور مطلوبہ رفتار سے اس پر کارروائی کر سکتے ہیں۔ ظاہر ہے کہ اگر ہم ایک اچھا صارف تجربہ فراہم کرنا چاہتے ہیں تو یہ بہترین حل ہے۔ ہم نے RabbitMQ میں ایک قطار کا استعمال کرتے ہوئے بفر کو لاگو کیا۔

اسکیم میں دو نئی کارروائیاں شامل کی گئی ہیں: (1) API کو درخواست آنے کے بعد، لین دین کو کال کرنے کے لیے ضروری پیرامیٹرز کے ساتھ ایک پیغام قطار میں رکھا جاتا ہے، اور کلائنٹ کو ایک پیغام موصول ہوتا ہے کہ ٹرانزیکشن کو قبول کر لیا گیا ہے۔ سسٹم، (2) پسدید قطار سے ترتیب میں مخصوص رفتار سے ڈیٹا کو پڑھتا ہے۔ اسٹیٹس اسٹور میں لین دین شروع کرتا ہے اور ڈیٹا کو اپ ڈیٹ کرتا ہے۔
اب آپ تشکیل کے وقت کو بڑھا سکتے ہیں اور صارف سے تاخیر کو چھپاتے ہوئے جتنا چاہیں بلاک کر سکتے ہیں۔

دوسرے اوزار۔

چین کوڈ کے بارے میں یہاں کچھ نہیں کہا گیا، کیونکہ، ایک اصول کے طور پر، اس میں اصلاح کے لیے کچھ نہیں ہے۔ چین کوڈ جتنا ممکن ہو آسان اور محفوظ ہونا چاہیے - بس اتنا ہی اس کی ضرورت ہے۔ فریم ورک ہمیں آسانی اور محفوظ طریقے سے چین کوڈ لکھنے میں مدد کرتا ہے۔ CCKit S7 Techlab اور جامد تجزیہ کار سے ^CC کو بحال کریں۔.

اس کے علاوہ، ہماری ٹیم فیبرک کے ساتھ کام کو آسان اور پرلطف بنانے کے لیے افادیت کا ایک سیٹ تیار کر رہی ہے: بلاکچین ایکسپلوررکے لئے ایک افادیت خودکار نیٹ ورک کنفیگریشن تبدیلیاں (تنظیموں کو شامل کرنا/ ہٹانا، RAFT نوڈس)، کے لیے افادیت سرٹیفکیٹ کی منسوخی اور شناخت کا خاتمہ. اگر آپ اپنا حصہ ڈالنا چاہتے ہیں تو آپ کا استقبال ہے۔

حاصل يہ ہوا

یہ نقطہ نظر آپ کو آسانی سے Hyperledger Fabric کو Quorum، دیگر نجی Ethereum نیٹ ورکس (PoA یا یہاں تک کہ PoW) سے تبدیل کرنے کی اجازت دیتا ہے، اصل تھرو پٹ کو نمایاں طور پر کم کرتا ہے، لیکن ساتھ ہی ساتھ نارمل UX (براؤزر میں صارفین اور مربوط نظاموں کے لیے دونوں) کو برقرار رکھتا ہے۔ اسکیم میں فیبرک کو ایتھریم سے تبدیل کرتے وقت، آپ کو صرف MVCC تنازعات کی پروسیسنگ سے لے کر ایٹمک نانس انکریمنٹ اور دوبارہ بھیجنے تک دوبارہ کوشش کرنے والی سروس/ڈیکوریٹر کی منطق کو تبدیل کرنے کی ضرورت ہوگی۔ بفرنگ اور اسٹیٹس اسٹوریج نے ردعمل کے وقت کو بلاک بنانے کے وقت سے دوگنا کرنا ممکن بنایا۔ اب آپ ہزاروں آرڈر نوڈس شامل کر سکتے ہیں اور خوفزدہ نہ ہوں کہ بلاکس اکثر بنتے ہیں اور آرڈرنگ سروس لوڈ کر سکتے ہیں۔

بنیادی طور پر، میں صرف اتنا ہی اشتراک کرنا چاہتا تھا۔ مجھے خوشی ہوگی اگر اس سے کسی کو ان کے کام میں مدد ملتی ہے۔

ماخذ: www.habr.com