سمارٹ کنٹریکٹ شو ڈاؤن: ہائپر لیجر فیبرک بمقابلہ ملٹی چین بمقابلہ ایتھریم بمقابلہ کورڈا

بلاکچین پر کوڈ ڈالنے کے ایک سے زیادہ طریقے ہیں۔

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

From a technical viewpoint, a smart contract is something more specific: computer code that lives on a blockchain and defines the rules for that chain’s transactions. This description sounds simple enough, but behind it lies a great deal of variation in how these rules are expressed, executed and validated. When choosing a blockchain platform for a new application, the question “Does this platform support smart contracts?” isn’t the right one to ask. Instead, we need to be asking: “What type of smart contracts does this platform support?”

اس آرٹیکل میں، میرا مقصد سمارٹ کنٹریکٹ اپروچز اور ان کی نمائندگی کرنے والے ٹریڈ آف کے درمیان کچھ بڑے فرقوں کا جائزہ لینا ہے۔ میں یہ چار مشہور انٹرپرائز بلاک چین پلیٹ فارمز کو دیکھ کر کروں گا جو حسب ضرورت آن چین کوڈ کی کچھ شکلوں کو سپورٹ کرتے ہیں۔ سب سے پہلے، IBM کا Hyperledger فیبرک، جو اپنے معاہدوں کو "چین کوڈ" کہتا ہے۔ دوسرا، ہمارا ملٹی چین پلیٹ فارم، جو متعارف کراتا ہے۔ سمارٹ فلٹرز ورژن 2.0 میں۔ تیسرے، ایتھرم (اور اس کی اجازت ہے۔ Quorum اور دفن اسپن آفز)، جس نے "سمارٹ کنٹریکٹ" نام کو مقبول بنایا۔ اور آخر میں، R3 Corda، جو اپنے لین دین میں "معاہدے" کا حوالہ دیتا ہے۔ تمام مختلف اصطلاحات کے باوجود، بالآخر یہ سب ایک ہی چیز کا حوالہ دیتے ہیں - اطلاق کے لیے مخصوص کوڈ جو سلسلہ کے اصولوں کی وضاحت کرتا ہے۔

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

بلاکچین کی بنیادی باتیں

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

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

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

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

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

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

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

لین دین کے قوانین

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

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

آدانوں اور نتائج

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

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

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

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

معاہدے اور پیغامات

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

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

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

مثال کے اصول

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

1. ٹرانزیکشن کے آؤٹ پٹس میں اثاثوں کی کل مقدار کو اس کے ان پٹس میں کل سے مماثل ہونا چاہئے۔ یہ صارفین کو من مانی رقم بنانے یا حذف کرنے سے روکتا ہے۔
2. ہر لین دین پر اس کے ہر ان پٹ کے مالک کے دستخط ہونے ہوتے ہیں۔ یہ صارفین کو بغیر اجازت ایک دوسرے کے پیسے خرچ کرنے سے روکتا ہے۔

ایک ساتھ مل کر، یہ دونوں شرائط ایک سادہ لیکن قابل عمل مالیاتی نظام بنانے کے لیے درکار ہیں۔

معاہدہ-پیغام کے ماڈل میں، اثاثہ کا معاہدہ "پیمنٹ بھیجیں" پیغام کی حمایت کرتا ہے، جس میں تین پیرامیٹرز ہوتے ہیں: بھیجنے والے کا پتہ، وصول کنندہ کا پتہ، اور بھیجی جانے والی مقدار۔ جواب میں، معاہدہ مندرجہ ذیل چار مراحل پر عمل کرتا ہے:

1. تصدیق کریں کہ لین دین پر بھیجنے والے نے دستخط کیے تھے۔
2. چیک کریں کہ بھیجنے والے کے پاس کافی رقم ہے۔
3. بھیجنے والے کی قطار سے مطلوبہ مقدار کاٹ لیں۔
4. اس مقدار کو وصول کنندہ کی قطار میں شامل کریں۔

اگر پہلے دو مراحل میں سے کوئی بھی چیک ناکام ہو جاتا ہے تو معاہدہ ختم ہو جائے گا اور کوئی ادائیگی نہیں کی جائے گی۔

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

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

بلٹ ان رولز

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

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

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

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

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

لین دین کے قوانین	فیبرک	ملٹی چین	ایتھرم	Corda
ماڈل	معاہدہ - پیغام	ان پٹ آؤٹ پٹ	معاہدہ - پیغام	ان پٹ آؤٹ پٹ
بلٹ ان	کوئی بھی نہیں	اجازتیں + اثاثے + سلسلے	کوئی بھی نہیں	کوئی بھی نہیں

تعیناتیزم

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

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

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

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

عدم استحکام کے ذرائع

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

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

ہمارے چار بلاکچین پلیٹ فارمز ان خرابیوں سے بچنے کے لیے کئی مختلف طریقے استعمال کرتے ہیں۔

تعییناتی عمل درآمد

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

ملٹی چین فلٹرز اور کورڈا کنٹریکٹس موجودہ پروگرامنگ زبانوں اور رن ٹائم ماحول کو اپناتے ہوئے ایک مختلف نقطہ نظر کا انتخاب کرتے ہیں۔ ملٹی چین گوگل میں چلنے والی جاوا اسکرپٹ کا استعمال کرتا ہے۔ V8 انجن، جو کروم براؤزر اور Node.js پلیٹ فارم کا بنیادی حصہ بھی بناتا ہے، لیکن غیر تعین کے ذرائع کے ساتھ غیر فعال ہے۔ اسی طرح، کورڈا جاوا یا استعمال کرتا ہے۔ کوٹلن، دونوں کو "جاوا بائیک کوڈ" پر مرتب کیا گیا ہے جو جاوا ورچوئل مشین ("JVM") کے اندر عمل میں آتا ہے۔ ابھی کے لیے، کورڈا اوریکل کا معیاری نان ڈیٹرمنسٹک JVM استعمال کرتا ہے، لیکن ایک کو مربوط کرنے کے لیے کام جاری ہے۔ تعییناتی ورژن. اس دوران، Corda معاہدہ کے ڈویلپرز کو اپنے کوڈ میں عدم استحکام کی اجازت نہ دینے کا خیال رکھنا چاہیے۔

Ethereum کی purism کا موازنہ MultiChain اور Corda کے ارتقائی نقطہ نظر سے کیسے ہوتا ہے؟ Ethereum کا بنیادی فائدہ خطرے کو کم کرنا ہے - ایک تعمیر شدہ ورچوئل مشین میں غیر ارادی طور پر غیر ارادی طور پر ہونے کا امکان کم ہوتا ہے۔ اگرچہ ایسی کسی بھی نگرانی کو سافٹ ویئر اپ ڈیٹ کے ذریعے طے کیا جا سکتا ہے، لیکن یہ کسی بھی چین کے لیے خلل ڈالنے والا ہو گا جو اس کا سامنا کرنے کے لیے کافی بدقسمت تھا۔ ایتھریم کا مسئلہ، تاہم، یہ ہے کہ سالیڈٹی اور ای وی ایم پروگرامنگ زبانوں اور رن ٹائم ماحول کے وسیع تناظر میں ایک چھوٹا اور نیا ماحولیاتی نظام تشکیل دیتے ہیں۔ مقابلے کے لحاظ سے، JavaScript اور Java ہیں۔ Github پر سب سے اوپر کی دو زبانیں۔، اربوں ڈیجیٹل آلات پر چلتے ہیں، اور رن ٹائمز ہیں جو کئی دہائیوں سے بہتر کیے گئے ہیں۔ غالباً یہی وجہ ہے کہ عوامی ایتھریم بلاکچین میں منتقلی پر غور کر رہا ہے۔ eWASM، ابھرتے ہوئے WebAssembly معیار کا ایک تعییناتی فورک۔

توثیق کے ذریعے عزم

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

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

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

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

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

تعیناتیزم	فیبرک	ملٹی چین	ایتھرم	Corda
ماڈل	تدوین	موافقت پذیر رن ٹائم	مقصد سے بنایا ہوا VM	موافقت پذیر رن ٹائم
زبانیں	Go + Java + JavaScript	جاوا سکرپٹ	سالمیت	جاوا + کوٹلن
کوڈ کی مرئیت	کاؤنٹر پارٹیز + حمایت کرنے والے	Blockchain	Blockchain	کاؤنٹر پارٹیز + انحصار
نافذ	نہیں	جی ہاں	جی ہاں	نہیں (ابھی کے لیے)

تنازعات کی روک تھام

اب تک، ہم نے اس بات پر تبادلہ خیال کیا ہے کہ کس طرح مختلف بلاکچین پلیٹ فارمز کوڈ میں لین دین کے قوانین کا اظہار کرتے ہیں، اور وہ کس طرح اس بات کو یقینی بناتے ہیں کہ ہر نوڈ ان اصولوں کو یکساں طور پر لاگو کرتا ہے۔ اب وقت آگیا ہے کہ ہم اپنے شو ڈاون کے تیسرے پہلو کے بارے میں بات کریں: ہر پلیٹ فارم اس امکان سے کیسے نمٹتا ہے کہ دو لین دین، جو اپنے آپ میں درست ہیں، ایک دوسرے سے متصادم ہیں؟ آسان ترین مثال میں، تصور کریں کہ ایلس کے پاس مالیاتی لیجر میں $10 ہے اور وہ دو ٹرانزیکشنز کو براڈکاسٹ کرتی ہے - ایک باب کو $8 بھیجتا ہے، اور دوسرا چارلی کو $7 بھیجتا ہے۔ واضح طور پر، ان میں سے صرف ایک لین دین کو کامیاب ہونے کی اجازت دی جا سکتی ہے۔

دو ماڈل

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

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

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

آؤٹ پٹ بمقابلہ معاہدے

اب تک ہم نے متضاد لین دین کو روکنے کے لیے دو مختلف تکنیکیں دیکھی ہیں - ملٹی چین اور کورڈا میں سنگل اسپینڈ آؤٹ پٹ، اور ایتھریم میں کنٹریکٹ پر مبنی تصدیق۔ تو کون سا بہتر ہے؟

اس سوال کے جواب میں مدد کرنے کے لیے، آئیے ایک مثال "1-میں سے-2 کثیر دستخط" اکاؤنٹ پر غور کریں جو گیون اور ہیلن کی جانب سے $100 رکھتا ہے، اور ان میں سے کسی کو بھی اس رقم کو آزادانہ طور پر خرچ کرنے کی اجازت دیتا ہے۔ گیون اپنی درخواست کو ڈونا کو $80 ادا کرنے کی ہدایت کرتا ہے، اور چند سیکنڈ بعد، ہیلن ایڈورڈ کو $40 بھیجنا چاہتی ہے۔ چونکہ دونوں ادائیگیوں کے لیے ناکافی فنڈز ہیں، اس لیے یہ لین دین لازمی طور پر متصادم ہوگا۔ دونوں ٹرانزیکشنز نشر ہونے کی صورت میں، نتائج کا تعین اس بات سے کیا جائے گا کہ جو بھی اسے سلسلہ میں پہلے لائے گا۔ نوٹ کریں کہ ایلس کی مثال کے برعکس، یہ تنازعہ ہے۔ حادثاتی, چونکہ کوئی بھی درخواست کے قواعد کو توڑنے کی کوشش نہیں کر رہا ہے – ان کے پاس صرف بدقسمت وقت تھا۔

اس تنازعہ کے پیش آنے کے امکان پر غور کرتے ہوئے، اہم سوال یہ ہے: گیون کے اپنا لین دین بھیجنے کے بعد، ہیلن کے نوڈ کو یہ جاننے میں کتنا وقت لگے گا کہ اس کی ادائیگی ناکام ہو سکتی ہے؟ یہ مدت جتنی کم ہوگی، اتنا ہی زیادہ امکان ہے کہ ہیلن کو اس ادائیگی کی کوشش کرنے سے روک دیا جائے، اور اسے اور اس کی درخواست کو بعد میں آنے والے سرپرائز سے بچایا جائے۔

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

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

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

پڑھنے لکھنے کے سیٹ

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

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

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

تنازعات کی روک تھام	فیبرک	ملٹی چین	ایتھرم	Corda
ماڈل	پڑھنے لکھنے کے سیٹ	اکیلا خرچ	معاہدہ چیک	اکیلا خرچ
توثیق	آزاد	آزاد	آزاد	قابل اعتماد نوٹری
رفتار تیز	~10s (تصدیق)	~1s (پروپیگیشن)	~10s (تصدیق)	0~5s (نوٹری)

ایک پیچیدہ انتخاب

اس ٹکڑے میں، ہم نے بہت سے مختلف طریقوں کا جائزہ لیا جس میں Corda، Ethereum، Fabric اور MultiChain "سمارٹ کنٹریکٹس"، یا ایپلیکیشن کوڈ کے کلیدی چیلنجوں سے نمٹتے ہیں جو بلاک چین میں سرایت کرتے ہیں۔ اور ہر پلیٹ فارم کے پاس ہمارے تین بنیادی سوالات کے مختلف جوابات ہیں: لین دین کے قوانین کی نمائندگی کیسے کی جاتی ہے؟ کوڈ کو تعییناتی طور پر کیسے عمل میں لایا جاتا ہے؟ اور ہم تنازعات کو کیسے روک سکتے ہیں؟

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

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