آف چین ڈیٹا کے ساتھ بلاک چینز کو اسکیل کرنا

جب ایک ہیش کی قیمت ایک ملین الفاظ ہے۔

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

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

مثال کے طور پر، ملٹی چین 1.0 نے بلاکچین پر ایک یا زیادہ نام کی "اسٹریمز" بنانے کی اجازت دی اور پھر خام ڈیٹا کو ذخیرہ کرنے اور بازیافت کرنے کے لیے استعمال کیا۔ ہر اسٹریم کے پاس لکھنے کی اجازتوں کا اپنا سیٹ ہوتا ہے، اور ہر نوڈ آزادانہ طور پر منتخب کر سکتا ہے کہ کن اسٹریمز کو سبسکرائب کرنا ہے۔ اگر کوئی نوڈ کسی سٹریم میں سبسکرائب کیا جاتا ہے، تو یہ اس سلسلے کے مواد کو ریئل ٹائم میں انڈیکس کرتا ہے، جس سے آئٹمز کو ان کے آرڈرنگ، ٹائم اسٹیمپ، بلاک نمبر یا پبلشر ایڈریس کے ساتھ ساتھ "کلید" (یا لیبل) کے ذریعے تیزی سے بازیافت کیا جا سکتا ہے۔ جس کے ذریعے اشیاء کو ٹیگ کیا جا سکتا ہے۔ ملٹی چین 2.0 (الفا 1 کے بعد سے) یونیکوڈ ٹیکسٹ یا JSON ڈیٹا کے ساتھ ساتھ فی آئٹم اور متعدد آئٹمز فی ٹرانزیکشن کو سپورٹ کرنے کے لیے توسیعی سلسلہ۔ اس نے خلاصہ کرنے کے فنکشنز بھی شامل کیے جیسے "JSON مرج" جو ایک ہی کلید یا ناشر کے ساتھ آئٹمز کو مفید طریقے سے جوڑتا ہے۔

رازداری اور اسکیل ایبلٹی

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

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

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

اگر ہم ایک آسان کیس لیں، جہاں ہر آئٹم 100 بائٹس کا ایک چھوٹا JSON ڈھانچہ ہے، مجموعی طور پر ڈیٹا تھرو پٹ 100 کلو بائٹس فی سیکنڈ ہوگا، جس کا حساب 500 × (100+100) سے کیا جاتا ہے۔ اس کا ترجمہ 1 میگا بٹ/سیکنڈ بینڈوڈتھ سے کم ہے، جو کسی بھی جدید انٹرنیٹ کنکشن کی گنجائش کے اندر آرام سے ہے۔ ڈیٹا ہر سال تقریباً 3 ٹیرا بائٹس کی شرح سے جمع ہوگا، جو کہ کوئی چھوٹی رقم نہیں ہے۔ لیکن اب 12 ٹیرا بائٹ ہارڈ ڈرائیوز کے ساتھ وسیع پیمانے پر موجود، اور RAID کنٹرولرز جو متعدد فزیکل ڈرائیوز کو ایک ہی منطقی میں یکجا کرتے ہیں، ہم آسانی سے ہر نوڈ پر 10-20 سال کا ڈیٹا بہت زیادہ پریشانی یا خرچ کے بغیر محفوظ کر سکتے ہیں۔

تاہم، چیزیں بہت مختلف نظر آتی ہیں اگر ہم معلومات کے بڑے ٹکڑوں کو ذخیرہ کر رہے ہیں، جیسے اسکین شدہ دستاویزات۔ کاغذ کی A4 شیٹ کا معقول معیار کا JPEG اسکین 500 کلو بائٹ سائز کا ہو سکتا ہے۔ اسے 500 ٹرانزیکشنز فی سیکنڈ سے ضرب دیں، اور ہم 250 کے تھرو پٹ کو دیکھ رہے ہیں میگا بائٹ فی سیکنڈ. اس کا ترجمہ 2 گیگا بٹس/سیکنڈ بینڈوتھ میں ہوتا ہے، جو کہ زیادہ تر مقامی نیٹ ورکس سے تیز ہے، انٹرنیٹ سے کنکشن کو تو چھوڑ دیں۔ ایمیزون ویب سروسز کی سب سے سستی پر شائع شدہ قیمت $0.05 فی گیگا بائٹ، اس کا مطلب ہے $400,000 فی نوڈ کا سالانہ بینڈوتھ بل۔ اور ہر نوڈ سالانہ پیدا ہونے والے 8000 ٹیرا بائٹس نئے ڈیٹا کو کہاں ذخیرہ کرے گا؟

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

ہیشنگ حل

تو ہم ڈیٹا اسکیل ایبلٹی کے مسئلے کو کیسے حل کرتے ہیں؟ اس ڈیٹا کو چین کے ہر نوڈ میں نقل کیے بغیر، ہم بلاکچین کے ڈیٹا کی وکندریقرت نوٹرائزیشن سے کیسے فائدہ اٹھا سکتے ہیں؟

جواب ٹیکنالوجی کے ایک ہوشیار ٹکڑے کے ساتھ ہے جسے "ہیش" کہا جاتا ہے۔ ایک ہیش ایک لمبی تعداد ہے (سوچئے 256 بٹس، یا تقریباً 80 اعشاریہ ہندس) جو ڈیٹا کے ایک ٹکڑے کی منفرد شناخت کرتی ہے۔ ایک کا استعمال کرتے ہوئے ڈیٹا سے ہیش کا حساب لگایا جاتا ہے۔ ایک طرفہ تقریب جس میں ایک اہم کرپٹوگرافک خاصیت ہے: ڈیٹا کے کسی بھی ٹکڑے کو دیکھتے ہوئے، اس کی ہیش کا حساب لگانا آسان اور تیز ہے۔ لیکن ایک خاص ہیش کو دیکھتے ہوئے، اعداد و شمار کا ایک ٹکڑا تلاش کرنا کمپیوٹیشنل طور پر ناممکن ہے جو اس ہیش کو تیار کرے۔ اور جب ہم کہتے ہیں کہ "حسابیاتی طور پر ناقابل عمل"، تو ہمارا مطلب ہے کہ معلوم کائنات میں موجود ایٹموں سے زیادہ حساب کتاب۔

ہیشز تمام بلاک چینز میں لین دین اور بلاکس کی منفرد شناخت کرکے اہم کردار ادا کرتی ہیں۔ وہ بٹ کوائن جیسے پروف آف ورک سسٹمز میں کمپیوٹیشنل چیلنج کو بھی برداشت کرتے ہیں۔ BLAKE2، MD5 اور RIPEMD160 جیسے gobbledygook ناموں کے ساتھ بہت سے مختلف ہیش فنکشنز تیار کیے گئے ہیں۔ لیکن کسی بھی ہیش فنکشن پر بھروسہ کرنے کے لیے، اسے وسیع تعلیمی جائزہ اور جانچ کو برداشت کرنا ہوگا۔ یہ ٹیسٹ حملوں کی کوشش کی صورت میں آتے ہیں، جیسے کہ "پری امیج" (دیئے گئے ہیش کے ساتھ ایک ان پٹ تلاش کرنا)، "سیکنڈ پری امیج" (دیئے گئے ان پٹ کے ساتھ اسی ہیش کے ساتھ دوسرا ان پٹ تلاش کرنا) اور "تصادم" (کسی کو تلاش کرنا) ایک ہی ہیش کے ساتھ دو مختلف ان پٹ)۔ ٹوٹے ہوئے ہیش فنکشنز کی ایک طویل اور المناک تاریخ کے ساتھ اس گنٹلیٹ سے بچنا آسان نہیں ہے: "اپنا اپنا کرپٹو رول نہ کریں۔"

اپنے اصل مسئلے کی طرف واپس جانے کے لیے، ہم ڈیٹا کی بجائے، لین دین کے اندر ڈیٹا کے بڑے ٹکڑوں کی ہیش کو ایمبیڈ کرکے بلاک چینز میں ڈیٹا اسکیل ایبلٹی کو حل کر سکتے ہیں۔ ہر ہیش اپنے ان پٹ ڈیٹا کے لیے "عزم" کے طور پر کام کرتا ہے، جس میں ڈیٹا خود بلاک چین یا "آف چین" سے باہر محفوظ ہوتا ہے۔ مثال کے طور پر، مقبول SHA256 ہیش فنکشن کا استعمال کرتے ہوئے، 500 کلو بائٹ JPEG امیج کو 32-بائٹ نمبر، 15,000× سے زیادہ کی کمی کے ذریعے دکھایا جا سکتا ہے۔ یہاں تک کہ 500 امیجز فی سیکنڈ کی شرح سے بھی، یہ ہمیں چین میں محفوظ کردہ ڈیٹا کے لحاظ سے، قابل عمل بینڈوتھ اور اسٹوریج کی ضروریات کے علاقے میں آرام سے واپس لے جاتا ہے۔

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

ترسیل کا سوال

اب تک، بہت اچھا. اصل ڈیٹا کی بجائے بلاک چین میں ہیشز کو سرایت کرنے سے، ہمارے پاس اسکیل ایبلٹی کے مسئلے کا آسان حل ہے۔ بہر حال، ایک اہم سوال باقی ہے:

ہم اصل آف چین مواد کو ان نوڈس تک کیسے پہنچائیں گے جن کو اس کی ضرورت ہے، اگر خود چین کے ذریعے نہیں؟

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

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

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

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

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

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

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

ملٹی چین 2.0 میں آف چین ڈیٹا

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

نہیں واقعی، ہمارا مطلب ہے۔ سب کچھ. ملٹی چین پر ایک ڈویلپر کی عمارت کے طور پر، آپ کو ہیش، مقامی اسٹوریج، مواد کی دریافت، وکندریقرت کی ترسیل یا ڈیٹا کی تصدیق کے بارے میں فکر کرنے کی ضرورت نہیں ہوگی۔ یہاں پردے کے پیچھے کیا ہوتا ہے:

1. پبلشنگ ملٹی چین نوڈ اپنے مقامی سٹوریج میں نیا ڈیٹا لکھتا ہے، بڑی اشیاء کو آسانی سے ہضم اور ترسیل کے لیے ٹکڑوں میں کاٹتا ہے۔
2. آف چین اسٹریم آئٹمز کو شائع کرنے کا لین دین خود بخود بن جاتا ہے، جس میں بائٹس میں chunk hash(es) اور سائز(s) ہوتے ہیں۔
3. اس لین دین پر دستخط کیے جاتے ہیں اور نیٹ ورک پر نشر ہوتے ہیں، نوڈس کے درمیان پھیلتے ہوئے اور معمول کے مطابق بلاکچین میں داخل ہوتے ہیں۔
4. جب کسی اسٹریم کو سبسکرائب کیا ہوا نوڈ کچھ آف چین ڈیٹا کا حوالہ دیکھتا ہے، تو یہ اس ڈیٹا کے لیے chunk hashes کو اس کی بازیافت کی قطار میں شامل کرتا ہے۔ (جب کسی پرانے سلسلے کو سبسکرائب کرتے ہیں تو، ایک نوڈ پہلے سے شائع شدہ آف چین آئٹمز کو بازیافت کے لیے قطار میں کھڑا کرتا ہے۔)
5. پس منظر کے عمل کے طور پر، اگر نوڈ کی بازیافت کی قطار میں کچھ حصے ہیں، تو ان حصوں کو تلاش کرنے کے لیے سوالات نیٹ ورک کو بھیجے جاتے ہیں، جیسا کہ ان کی ہیشز سے شناخت ہوتی ہے۔
6. یہ تعداد کے سوالات نیٹ ورک کے دوسرے نوڈس پر پیئر ٹو پیئر انداز میں پھیلائے جاتے ہیں (ابھی کے لیے دو ہاپس تک محدود – نیچے تکنیکی تفصیلات دیکھیں)۔
7. کوئی بھی نوڈ جس میں حصہ کا ڈیٹا ہوتا ہے وہ جواب دے سکتا ہے، اور یہ جواب سبسکرائبر کو اسی راستے پر واپس بھیج دیا جاتا ہے جس طرح استفسار کیا جاتا ہے۔
8. اگر کوئی نوڈ chunk کے سوال کا جواب نہیں دیتا ہے، تو حصہ کو بعد میں دوبارہ کوشش کرنے کے لیے واپس قطار میں واپس کر دیا جاتا ہے۔
9. بصورت دیگر، سبسکرائبر ایک حصہ کے لیے سب سے زیادہ امید افزا ذریعہ کا انتخاب کرتا ہے (ہپس اور رسپانس ٹائم کی بنیاد پر)، اور اسے اس حصے کے ڈیٹا کے لیے درخواست بھیجتا ہے، دوبارہ اسی پیر ٹو پیئر راستے کے ساتھ پچھلے جواب کی طرح۔
10. سورس نوڈ اسی راستے کو دوبارہ استعمال کرتے ہوئے درخواست کردہ ڈیٹا فراہم کرتا ہے۔
11. سبسکرائبر اصل درخواست کے خلاف ڈیٹا کے سائز اور ہیش کی تصدیق کرتا ہے۔
12. اگر سب کچھ چیک آؤٹ ہو جاتا ہے، تو سبسکرائبر ڈیٹا کو اپنے مقامی اسٹوریج میں لکھتا ہے، جس سے اسے اسٹریم APIs کے ذریعے بازیافت کے لیے فوری طور پر دستیاب ہو جاتا ہے۔
13. اگر مطلوبہ مواد نہیں پہنچا، یا مطلوبہ ہیش یا سائز سے مماثل نہیں ہے، تو حصہ کسی دوسرے ذریعہ سے مستقبل میں بازیافت کے لیے قطار میں واپس کردیا جاتا ہے۔

سب سے اہم بات یہ ہے کہ یہ سب بہت تیزی سے ہوتا ہے۔ کم لیٹنسی والے نیٹ ورکس میں، آف چین ڈیٹا کے چھوٹے ٹکڑے سبسکرائبرز کے پاس ٹرانزیکشن کے ایک الگ سیکنڈ کے اندر پہنچ جائیں گے جو ان کا حوالہ دیتا ہے۔ اور زیادہ لوڈ ایپلی کیشنز کے لیے، ہماری جانچ سے پتہ چلتا ہے کہ ملٹی چین 2.0 الفا 3 ایک مہذب کے ساتھ درمیانے فاصلے کے سرور (کور i1000) پر 25 سے زیادہ آف چین آئٹمز یا 7 MB آف چین ڈیٹا فی سیکنڈ کی شرح کو برقرار رکھ سکتا ہے۔ انٹرنیٹ کنکشن. 1 GB تک کے آف چین آئٹمز کے ساتھ سب کچھ ٹھیک کام کرتا ہے، آن چین ڈیٹا کے لیے 64 MB کی حد سے کہیں زیادہ۔ یقینا، ہم ان نمبروں کو مزید بہتر کرنے کی امید کرتے ہیں کیونکہ ہم اس کے بیٹا مرحلے کے دوران ملٹی چین 2.0 کو بہتر بنانے میں وقت صرف کرتے ہیں۔

اسٹریمز میں آن چین ڈیٹا کے بجائے آف چین استعمال کرتے وقت، ملٹی چین ایپلیکیشن ڈویلپرز کو بالکل دو چیزیں کرنے پڑتے ہیں:

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

بلاشبہ، ہر نوڈ کو ہر آف چین آئٹم کو بازیافت کرنے سے روکنے کے لیے، آئٹمز کو ایک مناسب انداز میں اسٹریمز میں گروپ کیا جانا چاہیے، ہر نوڈ کو دلچسپی کے ان سلسلوں کو سبسکرائب کرنے کے ساتھ۔

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

اگر آپ آف چین اسٹریم آئٹمز کو آزمانا چاہتے ہیں، تو بس ملٹی چین کی باقاعدہ پیروی کریں۔ شروع ٹیوٹوریل، اور یقینی بنائیں کہ سیکشن 5 کو نہ چھوڑیں۔

تو آگے کیا ہے؟

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

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

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

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

براہ کرم کوئی تبصرہ پوسٹ کریں۔ لنکڈ پر.

تکنیکی تفصیلات

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

• فی سلسلہ پالیسیاں۔ جب ایک ملٹی چین سٹریم بنایا جاتا ہے، تو اسے اختیاری طور پر صرف آن چین یا آف چین ڈیٹا کی اجازت دینے کے لیے محدود کیا جا سکتا ہے۔ ایسا کرنے کی کئی ممکنہ وجوہات ہیں، بجائے اس کے کہ ہر ناشر کو خود فیصلہ کرنے کی اجازت دی جائے۔ مثال کے طور پر، آن-چین آئٹمز آئرن کلڈ دستیابی کی گارنٹی پیش کرتے ہیں، جب کہ پرانی آف چین آئٹمز ناقابل واپسی ہو سکتی ہیں اگر ان کے ناشر اور دوسرے سبسکرائبر نیٹ ورک چھوڑ دیتے ہیں۔ دوسری طرف، آن چین اشیاء کو بلاک چین میں ترمیم کیے بغیر "بھولایا" نہیں جا سکتا، جبکہ آف چین آئٹمز زیادہ لچکدار ہوتے ہیں۔ یہ ڈیٹا پرائیویسی کے قوانین کے لحاظ سے اہم ہو سکتا ہے، جیسے کہ یورپ کے نئے GDPR ضوابط۔
• آن چین میٹا ڈیٹا۔ آف چین آئٹمز کے لیے، آن چین ٹرانزیکشن میں اب بھی آئٹم کے ناشر، کلید، فارمیٹ (JSON، متن یا بائنری) اور کل سائز شامل ہوتا ہے۔ یہ سب بہت کم جگہ لیتا ہے، اور ایپلیکیشن ڈویلپرز کو یہ تعین کرنے میں مدد کرتا ہے کہ آیا کسی خاص سلسلہ کے سوال کے لیے آف چین آئٹم کی عدم دستیابی تشویشناک ہے۔
• دو ہاپ کی حد۔ پیئر ٹو پیئر نیٹ ورک پر نمبر سوالات کو ریلے کرتے وقت، قابل رسائی اور کارکردگی کے درمیان تجارت ہوتی ہے۔ اگرچہ یہ اچھا ہو گا کہ ہر سوال کو ہر ایک راستے پر پھیلایا جائے، یہ نیٹ ورک کو غیر ضروری "چٹر" سے روک سکتا ہے۔ لہٰذا فی الحال چند سوالات دو ہاپس تک محدود ہیں، مطلب یہ ہے کہ نوڈ اپنے ساتھیوں کے کسی بھی ہم مرتبہ سے آف چین ڈیٹا بازیافت کرسکتا ہے۔ 1000 سے کم نوڈس کے چھوٹے نیٹ ورکس میں جو انٹرپرائز بلاکچینز کی خصوصیت رکھتے ہیں، ہمیں یقین ہے کہ یہ بالکل ٹھیک کام کرے گا، لیکن اگر ہم غلط نکلے تو ہمارے لیے اس رکاوٹ کو ایڈجسٹ کرنا (یا اسے پیرامیٹر کے طور پر پیش کرنا) آسان ہے۔
• مقامی ذخیرہ. ہر ملٹی چین نوڈ ایک موثر بائنری فارمیٹ اور لیول ڈی بی انڈیکس کا استعمال کرتے ہوئے اپنی باقاعدہ بلاکچین ڈائرکٹری کی "چنکس" ڈائرکٹری کے اندر آف چین ڈیٹا اسٹور کرتا ہے۔ ہر ایک سبسکرائب شدہ سلسلے میں آئٹمز کے ساتھ ساتھ نوڈ کے ذریعہ شائع کردہ اشیاء کے لیے ایک علیحدہ ذیلی ڈائرکٹری استعمال کی جاتی ہے۔ ان ذیلی ڈائریکٹریوں میں سے ہر ایک کے اندر، ڈپلیکیٹ ٹکڑے (ایک ہی ہیش کے ساتھ) صرف ایک بار محفوظ کیے جاتے ہیں۔ جب کوئی نوڈ کسی سٹریم سے ان سبسکرائب کرتا ہے، تو یہ انتخاب کر سکتا ہے کہ اس سلسلے کے لیے حاصل کردہ آف چین ڈیٹا کو صاف کرنا ہے یا نہیں۔
• بائنری کیشے۔ بائنری ڈیٹا کے بڑے ٹکڑوں کو شائع کرتے وقت، چاہے آن چین ہو یا آف چین، ایپلیکیشن ڈویلپرز کے لیے اس ڈیٹا کو ایک ہی JSON-RPC درخواست میں MultiChain کے API کو بھیجنا عملی نہیں ہو سکتا۔ لہذا ملٹی چین 2.0 ایک بائنری کیش کو لاگو کرتا ہے، جو ڈیٹا کے بڑے ٹکڑوں کو متعدد API کالوں پر تیار کرنے کے قابل بناتا ہے، اور پھر ایک مختصر آخری مرحلے میں شائع کیا جاتا ہے۔ بائنری کیش میں موجود ہر آئٹم کو بلاکچین ڈائرکٹری کی "کیشے" سب ڈائرکٹری میں ایک سادہ فائل کے طور پر محفوظ کیا جاتا ہے، جس سے گیگا بائٹس ڈیٹا کو براہ راست فائل سسٹم کے ذریعے بھیجا جا سکتا ہے۔
• مانیٹرنگ APIs۔ ملٹی چین 2.0 الفا 3 آف چین ڈیٹا کی غیر مطابقت پذیر بازیافت کی نگرانی کے لیے دو نئے APIs کا اضافہ کرتا ہے۔ پہلا API قطار کی موجودہ حالت کی وضاحت کرتا ہے، یہ دکھاتا ہے کہ کتنے حصے (اور کتنا ڈیٹا) انتظار کر رہے ہیں یا استفسار یا بازیافت کیا جا رہا ہے۔ دوسرا API نوڈ کے شروع ہونے کے بعد سے بھیجے گئے تمام سوالات اور درخواستوں کے مجموعی اعدادوشمار فراہم کرتا ہے، بشمول مختلف قسم کی ناکامی کے شمار۔
• شائع کرنے پر فلش کریں۔ کسی آف چین آئٹم کو شائع کرتے وقت، ملٹی چین اس بات کو یقینی بناتا ہے کہ ڈیٹا کی اس کی مقامی کاپی مکمل طور پر فزیکل ڈسک ڈرائیو پر لکھی گئی ہے (یا "فلش") ٹرانزیکشن سے پہلے کہ ڈیٹا نیٹ ورک پر نشر ہوتا ہے۔ بصورت دیگر، اگر نوڈ اتنا بدقسمت تھا کہ لین دین کو نشر کرنے کے فوراً بعد پاور سے محروم ہو جائے، تو آف چین ڈیٹا مستقل طور پر ضائع ہو سکتا ہے۔ یہ خود ملٹی چین کے لیے کوئی مسئلہ نہیں ہے، کیونکہ ایک حصہ کی بازیافت کی کوششوں کے درمیان تاخیر وقت کے ساتھ ساتھ خود بخود بڑھ جاتی ہے۔ لیکن یہ ایپلیکیشن کی سطح پر مسائل کا سبب بن سکتا ہے، جہاں ہر کوئی کچھ ڈیٹا کی موجودگی کے بارے میں جانتا ہے لیکن کوئی بھی اسے تلاش کرنے کے قابل نہیں ہے۔
• اشاعت کی کارکردگی۔ اس طرح سے آف چین ڈیٹا کو ڈسک پر فلش کرنے سے، ملٹی چین کو کارکردگی کا جرمانہ ہو سکتا ہے، کیونکہ فزیکل ڈسک سست ہیں۔ مثال کے طور پر، ایک درمیانی رینج 7200 rpm ہارڈ ڈرائیو صرف 100 کے قریب بے ترتیب ڈیٹا رائٹ فی سیکنڈ پرفارم کر سکتی ہے، جس سے اس شرح کو محدود کر دیا جاتا ہے جس پر ایک انفرادی نوڈ آف چین آئٹمز شائع کر سکتا ہے۔ اس مسئلے کے لیے تین ممکنہ حل ہیں۔ سب سے پہلے اور سب سے آسان، نوڈس باقاعدہ ہارڈ ڈرائیو کے بجائے سالڈ اسٹیٹ ڈیوائس (SSD) ڈرائیو استعمال کر سکتے ہیں، جو فی سیکنڈ 10,000 بے ترتیب تحریری کارروائیوں کو سپورٹ کرتی ہے۔ دوسرا، "createrawsendfrom" API کا استعمال کرتے ہوئے ایک ہی لین دین میں متعدد آف چین آئٹمز شائع کیے جا سکتے ہیں۔ اس صورت میں، ملٹی چین ایک ہی ڈسک آپریشن میں لین دین کے ذریعے حوالہ کردہ تمام آف چین ڈیٹا لکھتا ہے۔ آخر میں، ملٹی چین کو ترتیب دیا جا سکتا ہے کہ اس لین دین کو نشر کرنے سے پہلے آف چین ڈیٹا کو ڈسک پر فلش نہ کیا جائے جو اس کا حوالہ دیتا ہے۔ اس اختیار کو احتیاط کے ساتھ استعمال کریں۔
• مقامی کرنسی کا انضمام۔ استعمال کے معاملات کے لیے جن کی ضرورت ہوتی ہے، ملٹی چین نے ہمیشہ بلاک چین پر مقامی کرنسی استعمال کرنے کا آپشن پیش کیا ہے تاکہ ٹرانزیکشن سپیم کو روکا جا سکے اور/یا بلاک ویڈیٹرز ("کان کنوں") کو ترغیب دی جا سکے۔ ان صورتوں میں، لین دین کے لیے کان کنوں کو کم از کم فیس کی پیشکش کرنی چاہیے جو بائٹس میں ان کے سائز کے متناسب ہو، تاکہ سلسلہ پر ریلے اور تصدیق کی جا سکے۔ اس طریقہ کار کو بڑھا دیا گیا ہے تاکہ آف چین سپیم کو روکا جا سکے، لین دین میں حوالہ کردہ آف چین ڈیٹا کے فی کلو بائٹ کے حساب سے کم از کم اضافی فیس کی ضرورت ہوتی ہے۔
• آرکائیو نوڈس۔ اگر کوئی نوڈ ہر سلسلہ کو سبسکرائب کرنا چاہتا ہے، اور اس لیے شائع شدہ ہر آف چین آئٹم کو بازیافت اور ذخیرہ کرنا چاہتا ہے، تو اسے "آٹو سبسکرائب" رن ٹائم پیرامیٹر کا استعمال کرتے ہوئے ایسا کرنے کے لیے کنفیگر کیا جا سکتا ہے۔ ایسا کوئی بھی نوڈ پورے نیٹ ورک کے لیے بیک اپ کے طور پر کام کرے گا، اس بات کی ضمانت دیتا ہے کہ آف چین آئٹمز ضائع یا دستیاب نہیں ہوں گے، چاہے دوسرے نوڈس غائب ہوں۔ کوئی تصور کر سکتا ہے کہ تیسری پارٹی کی کمپنیاں اسے تجارتی سروس کے طور پر پیش کر رہی ہیں۔

تمام متعلقہ API کالز اور پیرامیٹرز کی مکمل تفصیلات پر مل سکتی ہیں۔ ملٹی چین 2.0 پیش نظارہ صفحہ.