اسمارٹ کنٹریکٹس کا تعارف

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

باقاعدہ معاہدہ بمقابلہ ہوشیار معاہدہ

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

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

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

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

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

سمارٹ کنٹریکٹ کی تعریف

عام طور پر، اصطلاحات کو خود محقق نک سابو نے تیار کیا تھا اور پہلی بار 1994 میں استعمال کیا گیا تھا، اور اسے 1997 میں ایک مضمون میں دستاویز کیا گیا تھا جو سمارٹ معاہدوں کے بالکل خیال کو بیان کرتا ہے۔

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

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

ایک سادہ مثال - یسکرو سروس

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

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

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

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

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

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

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

ہاسٹل اور ریفریجریٹر کے ساتھ مثال

آئیے ایک مزید پیچیدہ مثال کو دیکھتے ہیں جو ایک سمارٹ معاہدے کی صلاحیتوں کو زیادہ واضح طور پر ظاہر کرتی ہے۔

ہم کہتے ہیں کہ تین لڑکے ہیں جو حال ہی میں ایک ہی چھاترالی کمرے میں منتقل ہوئے ہیں۔ ان تینوں کو اپنے کمرے کے لیے فریج خریدنے میں دلچسپی ہے جسے وہ ایک ساتھ استعمال کر سکیں۔ ان میں سے ایک نے رضاکارانہ طور پر فریج خریدنے اور بیچنے والے سے بات چیت کے لیے ضروری رقم جمع کی۔ تاہم، وہ حال ہی میں ایک دوسرے سے ملے تھے اور ان کے درمیان کافی اعتماد نہیں ہے۔ ظاہر ہے کہ ان میں سے دو تیسرے کو پیسے دے کر خطرہ مول لے رہے ہیں۔ اس کے علاوہ، انہیں بیچنے والے کے انتخاب میں ایک معاہدے تک پہنچنے کی ضرورت ہے۔

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

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

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

سمارٹ معاہدوں کی درجہ بندی

درجہ بندی کے لیے، آپ معیار کے مختلف گروپس ترتیب دے سکتے ہیں۔ تاہم، ٹیکنالوجی کی ترقی کے وقت، ان میں سے چار متعلقہ ہیں۔

سمارٹ معاہدوں کو ان کے عملدرآمد کے ماحول سے ممتاز کیا جا سکتا ہے، جو یا تو مرکزی یا وکندریقرت ہو سکتا ہے۔ وکندریقرت کے معاملے میں، اسمارٹ معاہدوں پر عمل کرتے وقت ہمارے پاس بہت زیادہ آزادی اور غلطی کی رواداری ہے۔

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

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

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

ذیل میں ہم موجودہ موضوع کی تفہیم میں مزید وضاحت لانے کے لیے پہلے تین معیارات پر گہری نظر ڈالیں گے۔

رن ٹائم کے حساب سے اسمارٹ معاہدے

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

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

ایک اور مثال دی جا سکتی ہے: انٹرنیٹ بینکنگ کی توسیعی فعالیت کے ساتھ روایتی بینک اور بہت آسان معاہدوں جیسے کہ باقاعدہ ادائیگی، آنے والی ادائیگیوں کی خودکار تبدیلی، مخصوص اکاؤنٹ میں سود کی خودکار کٹوتی وغیرہ۔

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

شرائط کو ترتیب دینے اور پورا کرنے کے طریقے سے سمارٹ معاہدے

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

صوابدیدی سمارٹ معاہدے بھی ہیں، لیکن ٹورنگ مکمل معاہدے نہیں ہیں۔ اس میں Bitcoin اور Litecoin اپنے اسکرپٹ کے ساتھ شامل ہیں۔ اس کا مطلب یہ ہے کہ آپ کسی بھی ترتیب میں صرف کچھ آپریشنز استعمال کر سکتے ہیں، لیکن اب آپ لوپس اور اپنے الگورتھم نہیں لکھ سکتے۔

اس کے علاوہ، سمارٹ کنٹریکٹ پلیٹ فارم موجود ہیں جو پہلے سے طے شدہ سمارٹ معاہدوں کو لاگو کرتے ہیں۔ ان میں Bitshares اور Steemit شامل ہیں۔ Bitshares کے پاس ٹریڈنگ، اکاؤنٹ مینجمنٹ، خود پلیٹ فارم کے انتظام اور اس کے پیرامیٹرز کے لیے سمارٹ کنٹریکٹس کی ایک رینج ہے۔ Steemit ایک ایسا ہی پلیٹ فارم ہے، لیکن اب یہ Bitshares کی طرح ٹوکن جاری کرنے اور ٹریڈنگ پر توجہ نہیں دے رہا ہے، بلکہ بلاگنگ پر، یعنی یہ ایک وکندریقرت طریقے سے مواد کو اسٹور اور پروسیس کرتا ہے۔

صوابدیدی ٹورنگ-مکمل معاہدوں میں ایتھریم پلیٹ فارم اور روٹ اسٹاک شامل ہیں، جو ابھی تک ترقی کے مراحل میں ہے۔ لہذا، ذیل میں ہم Ethereum سمارٹ کنٹریکٹ پلیٹ فارم پر تھوڑی اور تفصیل سے بات کریں گے۔

آغاز کے طریقہ کار کے ذریعہ اسمارٹ معاہدے

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

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

ایتھریم اکاؤنٹس

ایتھریم اکاؤنٹ کی اقسام

آئیے دیکھتے ہیں کہ Ethereum پلیٹ فارم پر کس قسم کے اکاؤنٹس ہو سکتے ہیں۔ یہاں صرف دو قسم کے اکاؤنٹس ہیں اور کوئی دوسرا آپشن نہیں ہے۔ پہلی قسم کو صارف اکاؤنٹ کہا جاتا ہے، دوسری قسم کا معاہدہ اکاؤنٹ ہے۔ آئیے معلوم کریں کہ وہ کس طرح مختلف ہیں۔

صارف کے اکاؤنٹ کو صرف الیکٹرانک دستخط کی ذاتی کلید سے کنٹرول کیا جاتا ہے۔ اکاؤنٹ کا مالک ECDSA (Elliptic Curve Digital Signature Algorithm) الگورتھم کا استعمال کرتے ہوئے الیکٹرانک دستخط کے لیے اپنا کلیدی جوڑا تیار کرتا ہے۔ صرف اس کلید کے ساتھ دستخط شدہ لین دین ہی اس اکاؤنٹ کی حالت بدل سکتے ہیں۔

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

Ethereum پر اکاؤنٹس کیسے بنائے جاتے ہیں۔

صارف اکاؤنٹ کی صورت میں، مالک آزادانہ طور پر ECDSA کا استعمال کرتے ہوئے ایک کلیدی جوڑا تیار کرتا ہے۔ یہ نوٹ کرنا ضروری ہے کہ Ethereum الیکٹرانک دستخطوں کے لیے بالکل وہی الگورتھم اور بالکل وہی بیضوی وکر استعمال کرتا ہے جیسا کہ Bitcoin، لیکن پتہ کا حساب قدرے مختلف طریقے سے کیا جاتا ہے۔ یہاں، ڈبل ہیشنگ کا نتیجہ اب استعمال نہیں کیا جاتا ہے، جیسا کہ Bitcoin میں، لیکن سنگل ہیشنگ 256 بٹس کی لمبائی میں Keccak فنکشن کے ساتھ فراہم کی جاتی ہے۔ کم سے کم اہم بٹس نتیجے کی قدر سے کاٹ دیے جاتے ہیں، یعنی آؤٹ پٹ ہیش ویلیو کے کم از کم اہم 160 بٹس۔ نتیجے کے طور پر، ہمیں Ethereum میں ایک پتہ ملتا ہے۔ اصل میں، یہ 20 بائٹس لیتا ہے.

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

ایک اہم خصوصیت ہے اور وہ یہ ہے کہ عام ڈیٹا بیس کی سطح پر صارف کا اکاؤنٹ اس وقت بنتا ہے جب وہ پہلی آنے والی ادائیگی قبول کرتا ہے۔

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

ہر سمارٹ کنٹریکٹ میں لازمی طور پر اس کا اپنا کنسٹرکٹر ہوتا ہے (اس معاہدے کا)۔ یہ خالی ہو سکتا ہے یا اس میں مواد ہو سکتا ہے۔ کنسٹرکٹر کے مکمل ہونے کے بعد، ایک سمارٹ کنٹریکٹ اکاؤنٹ شناخت کنندہ بنایا جاتا ہے، جس کا استعمال کرتے ہوئے آپ سکے بھیج سکتے ہیں، کچھ سمارٹ کنٹریکٹ طریقوں کو کال کر سکتے ہیں، وغیرہ۔

ایتھریم ٹرانزیکشن کا ڈھانچہ

اسے واضح کرنے کے لیے، ہم Ethereum ٹرانزیکشن کی ساخت اور ایک مثال سمارٹ کنٹریکٹ کوڈ کو دیکھنا شروع کریں گے۔

ایتھریم ٹرانزیکشن کئی شعبوں پر مشتمل ہوتا ہے۔ ان میں سے پہلا، غیر،، اکاؤنٹ سے متعلق لین دین کا ایک مخصوص سیریل نمبر ہے جو اسے تقسیم کرتا ہے اور اس کا مصنف ہے۔ یہ دوہرے لین دین میں فرق کرنے کے لیے ضروری ہے، یعنی جب ایک ہی لین دین کو دو بار قبول کیا جائے تو اس صورت کو خارج کر دیا جائے۔ شناخت کنندہ کا استعمال کرتے ہوئے، ہر ٹرانزیکشن کی ایک منفرد ہیش ویلیو ہوتی ہے۔

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

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

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

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

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

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

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

سولیڈیٹی کے لیے سمارٹ کنٹریکٹ کوڈ کی مثال

آئیے اب ایک مثال کا استعمال کرتے ہوئے آسان ترین سمارٹ کنٹریکٹ پر گہری نظر ڈالتے ہیں۔

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

اوپر ایک آسان سورس کوڈ ہے جو صارفین کے سکے پکڑ سکتا ہے اور مانگنے پر واپس کر سکتا ہے۔

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

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

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

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

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

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

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

Ethereum نیٹ ورک پر ایک مکمل نوڈ کیسے کام کرتا ہے؟

آئیے منصوبہ بندی سے دیکھتے ہیں کہ ایتھریم پلیٹ فارم پر اس طرح کے سمارٹ معاہدوں کو کیسے عمل میں لایا جاتا ہے اور ایک مکمل نیٹ ورک نوڈ کیسے کام کرتا ہے۔

Ethereum نیٹ ورک پر ایک مکمل نوڈ میں کم از کم چار ماڈیولز ہونے چاہئیں۔
پہلا، جیسا کہ کسی بھی وکندریقرت پروٹوکول کے لیے، P2P نیٹ ورکنگ ماڈیول ہے - نیٹ ورک کنکشن اور دوسرے نوڈس کے ساتھ کام کرنے کے لیے ایک ماڈیول، جہاں بلاکس، لین دین، اور دیگر نوڈس کے بارے میں معلومات کا تبادلہ ہوتا ہے۔ یہ تمام وکندریقرت کرپٹو کرنسیوں کے لیے ایک روایتی جزو ہے۔

اگلا، ہمارے پاس بلاکچین ڈیٹا کو ذخیرہ کرنے، پروسیسنگ کرنے، ترجیحی شاخ کا انتخاب کرنے، بلاکس کو شامل کرنے، بلاکس کو ان لنک کرنے، ان بلاکس کی تصدیق وغیرہ کے لیے ایک ماڈیول موجود ہے۔

تیسرے ماڈیول کو EVM (Ethereum ورچوئل مشین) کہا جاتا ہے - یہ ایک ورچوئل مشین ہے جو Ethereum ٹرانزیکشنز سے بائٹ کوڈ وصول کرتی ہے۔ یہ ماڈیول کسی خاص اکاؤنٹ کی موجودہ حالت لیتا ہے اور موصول ہونے والے بائی کوڈ کی بنیاد پر اس کی حالت میں تبدیلیاں کرتا ہے۔ ہر نیٹ ورک نوڈ پر ورچوئل مشین کا ورژن ایک جیسا ہونا چاہیے۔ ہر Ethereum نوڈ پر ہونے والے حسابات بالکل یکساں ہیں، لیکن وہ ایک متضاد طریقے سے ہوتے ہیں: کوئی اس لین دین کو پہلے چیک کرتا ہے اور اسے قبول کرتا ہے، یعنی اس میں موجود تمام کوڈ پر عمل کرتا ہے، اور کوئی بعد میں۔ اس کے مطابق، جب کوئی ٹرانزیکشن بنتی ہے، تو اسے نیٹ ورک پر تقسیم کیا جاتا ہے، نوڈس اسے قبول کرتے ہیں، اور تصدیق کے وقت، جس طرح Bitcoin میں Bitcoin Script پر عمل کیا جاتا ہے، اسی طرح یہاں ورچوئل مشین کا بائیک کوڈ بھی عمل میں لایا جاتا ہے۔

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

سمارٹ معاہدوں کی خرافات اور حدود

جہاں تک پابندیوں کا تعلق ہے جو Ethereum جیسے سمارٹ کنٹریکٹ پلیٹ فارمز کے لیے موجود ہیں، درج ذیل کا حوالہ دیا جا سکتا ہے:

• کوڈ پر عمل درآمد؛
• میموری مختص کریں؛
• بلاکچین ڈیٹا؛
• ادائیگی بھیجیں؛
• نیا معاہدہ بنائیں؛
• دوسرے معاہدوں کو کال کریں۔

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

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

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

Ethereum کے نقصانات

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

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

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

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

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

لہذا، مضمون کا موضوعی حصہ مکمل ہو گیا ہے، آئیے ان سوالات کی طرف چلتے ہیں جو اکثر پیدا ہوتے ہیں۔

اکثر پوچھے گئے سوالات

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

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

- کیا ہوگا اگر ثالث شریک فریقین میں سے کسی ایک کے ساتھ معاہدہ کرتا ہے: ایسکرو یا سمارٹ معاہدہ؟ کیا سمارٹ کنٹریکٹ میں ثالث کی ضرورت ہے؟

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

— کیا ایک ایتھریم ٹرانزیکشن کے ذریعے آپ کے پتے سے مختلف ٹارگٹ ایڈریسز پر بہت سے مختلف ٹوکنز کو منتقل کرنا ممکن ہے، مثال کے طور پر، ان ایڈریس کا تبادلہ جہاں ان ٹوکنز کی تجارت ہوتی ہے؟

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

Ethereum پلیٹ فارم کے بارے میں افسانوں میں سے ایک یہ ہے کہ ان حالات کو بیان کرنا ناممکن ہے جو کسی بیرونی انٹرنیٹ وسائل کے ڈیٹا پر منحصر ہوں گے، تو پھر کیا کریں؟

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

بلاکچین پر آن لائن کورس کے لیکچرز میں سے ایک اس موضوع کے لیے وقف ہے - “اسمارٹ کنٹریکٹس کا تعارف".

ماخذ: www.habr.com