TON鈥檚 تکنیکی خصوصیات اور سمارٹ کنٹریکٹ ڈویلپمنٹ پیراڈائم کی تفصیلی وضاحت

اصل مصنف: @Web3 ماریو

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

TON کا بنیادی ڈیزائن تصور - اعلی ہم آہنگی اور اعلی اسکیل ایبلٹی

یہ کہا جا سکتا ہے کہ TON میں تمام پیچیدہ ٹکنالوجی کے انتخاب کا مقصد اعلی ہم آہنگی اور اعلی اسکیل ایبلٹی کے حصول سے آتا ہے۔ یقیناً اس کی پیدائش کے پس منظر سے یہ سمجھنا ہمارے لیے مشکل نہیں ہے۔ TON، یا اوپن نیٹ ورک، ایک وکندریقرت کمپیوٹنگ نیٹ ورک ہے جو ایک L1 بلاکچین اور متعدد اجزاء پر مشتمل ہے۔ TON کو اصل میں Telegrams کے بانی Nikolai Durov اور ان کی ٹیم نے تیار کیا تھا، اور اب اسے دنیا بھر میں آزاد تعاون کرنے والوں کی کمیونٹی کے ذریعے سپورٹ اور برقرار رکھا جاتا ہے۔ اس کی پیدائش 2017 کی ہے، جب ٹیلی گرام ٹیم نے اپنے لیے بلاکچین حل تلاش کرنا شروع کیا۔ چونکہ اس وقت کوئی L1 بلاکچین موجود نہیں تھا جو ٹیلیگرام کے نو ہندسوں والے صارف کی بنیاد کو سپورٹ کر سکے، اس لیے انہوں نے اپنا بلاکچین ڈیزائن کرنے کا فیصلہ کیا، جسے اس وقت ٹیلیگرام اوپن نیٹ ورک کہا جاتا تھا۔ 2018 کا وقت آگیا۔ TON کو حاصل کرنے کے لیے درکار وسائل حاصل کرنے کے لیے، ٹیلی گرام نے 2018 کی پہلی سہ ماہی میں گرام ٹوکن (بعد میں ٹن کوائن کا نام تبدیل کر دیا گیا) کی فروخت شروع کی۔ 2020 میں، ریگولیٹری مسائل کی وجہ سے، ٹیلی گرام کی ٹیم TON سے دستبردار ہو گئی۔ پروجیکٹ اس کے بعد، اوپن سورس ڈویلپرز اور ٹیلیگرام مقابلہ جیتنے والوں کے ایک چھوٹے سے گروپ نے TON کوڈبیس پر قبضہ کر لیا، پروجیکٹ کا نام بدل کر دی اوپن نیٹ ورک رکھ دیا، اور اصل TON وائٹ پیپر میں بیان کردہ اصولوں پر عمل کرتے ہوئے آج تک بلاکچین کو فعال طور پر تیار کرنا جاری رکھا۔

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

لہذا، مندرجہ بالا دو مسائل کو حل کرنے کے لیے، TON نے مرکزی دھارے کے بلاکچین پروٹوکول کے لیے دو اصلاحیں کی ہیں:

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

• ایکٹر ماڈل کی بنیاد پر مکمل طور پر متوازی عملدرآمد کے ماحول کو متعارف کرانے سے، نیٹ ورک TPS کو بہت بہتر بنایا گیا ہے۔

ایک بلاک چین چین بنیں - لامحدود شارڈنگ صلاحیتوں کے ذریعے، ہر اکاؤنٹ میں ایک وقف اکاؤنٹ چین ہوتا ہے۔

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

اسے خلاصہ کرنے کے لئے، TON میں زنجیر کی ساخت کی چار پرتیں ہیں:

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

• شارڈ چین: زیادہ تر سیاق و سباق میں، شارڈ چین TON کی اصل جزو اکائی ہے۔ نام نہاد شارڈ چین اکاؤنٹ کی زنجیروں کا مجموعہ ہے۔

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

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

اس تمثیل کو اپنانے سے، TON نیٹ ورک میں درج ذیل تین خصوصیات ہیں:

• متحرک شارڈنگ: TON لوڈ میں ہونے والی تبدیلیوں کو اپنانے کے لیے شارڈ چینز کو خود بخود تقسیم اور ضم کر سکتا ہے۔ اس کا مطلب یہ ہے کہ نئے بلاکس ہمیشہ تیزی سے تیار ہوتے ہیں اور لین دین میں طویل انتظار کا وقت نہیں لگتا۔

• انتہائی قابل توسیع: لامحدود شارڈنگ پیراڈیم کے ذریعے، TON تقریباً لامحدود تعداد میں شارڈز کو سپورٹ کرنے کے قابل ہے، نظریاتی طور پر 60 ورکنگ چینز کی طاقت سے 2 تک۔

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

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

فرض کریں کہ ورک چین 1 میں اکاؤنٹ A ورک چین 3 میں اکاؤنٹ C کو پیغام بھیجنا چاہتا ہے۔ پھر میسج روٹنگ کے مسئلے کو ڈیزائن کرنے کی ضرورت ہے۔ اس مثال میں، روٹنگ کے دو راستے ہیں، ورک چین 1 -> ورک چین 2 -> ورک چین 3، اور ورک چین 1 -> ورک چین 4 -> ورک چین 3۔

جب زیادہ پیچیدہ حالات کا سامنا کرنا پڑتا ہے، تو میسج مواصلت کو تیزی سے مکمل کرنے کے لیے ایک موثر اور کم لاگت والے روٹنگ الگورتھم کی ضرورت ہوتی ہے۔ TON نے کراس چین میسج کمیونیکیشن روٹنگ دریافت حاصل کرنے کے لیے نام نہاد ہائپر کیوب روٹنگ الگورتھم کا انتخاب کیا۔ نام نہاد ہائپر کیوب ڈھانچہ ایک خاص نیٹ ورک ٹوپولوجی سے مراد ہے۔ ایک n-جہتی ہائپر کیوب 2^n چوٹیوں پر مشتمل ہوتا ہے، جن میں سے ہر ایک کو n-bit بائنری نمبر سے منفرد طور پر شناخت کیا جا سکتا ہے۔ اس ڈھانچے میں، کوئی بھی دو سرے ملحقہ ہیں اگر وہ بائنری نمائندگی میں صرف ایک بٹ سے مختلف ہوں۔ مثال کے طور پر، ایک 3-جہتی ہائپر کیوب میں، vertex 000 اور vertex 001 ملحقہ ہیں کیونکہ وہ صرف آخری حصے میں مختلف ہیں۔ مندرجہ بالا مثال ایک 2 جہتی ہائپر کیوب ہے۔

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

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

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

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

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

اداکار پر مبنی سمارٹ معاہدے اور مکمل طور پر متوازی عملدرآمد کا ماحول

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

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

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

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

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

• انکیپسولیشن اور آزادی: ہر ایکٹر پیغامات پر کارروائی کرنے میں مکمل طور پر آزاد ہے اور ایک دوسرے کے ساتھ مداخلت کیے بغیر متوازی طور پر پیغامات پر کارروائی کر سکتا ہے۔

• پیغام کی منتقلی: اداکار صرف پیغامات بھیجنے اور وصول کرنے کے ذریعے بات چیت کرتے ہیں، اور پیغام کی منتقلی غیر مطابقت پذیر ہے۔

• متحرک ڈھانچہ: اداکار رن ٹائم میں مزید اداکار بنا سکتے ہیں۔ یہ حرکیات اداکار ماڈل کو ضرورت کے مطابق نظام کو وسعت دینے کے قابل بناتی ہے۔

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

تاہم، یہ ڈیزائن کچھ نئے اثرات بھی لاتا ہے۔ DApp ڈویلپرز کے لیے، ان کے عادی ترقی کے نمونے کو توڑ دیا جائے گا، جیسا کہ:

1. سمارٹ معاہدوں کے درمیان غیر مطابقت پذیر کالیں: بیرونی معاہدوں کو کال کرنا یا TON鈥檚 سمارٹ معاہدوں کے اندر ایٹمی طور پر بیرونی معاہدے کے ڈیٹا تک رسائی حاصل کرنا ناممکن ہے۔ ہم جانتے ہیں کہ سولیڈیٹی میں، کنٹریکٹ A کے فنکشن 1 سے کنٹریکٹ B کے فنکشن 2 کو کال کرنا، یا کنٹریکٹ C کے صرف پڑھنے کے فنکشن 3 کے ذریعے مخصوص اسٹیٹ ڈیٹا تک رسائی حاصل کرنا، یہ سارا عمل ایٹمی ہے اور ایک لین دین میں انجام پاتا ہے، جو کہ بہت آسان ہے۔ چیز تاہم، TON میں، یہ ممکن نہیں ہوگا۔ بیرونی سمارٹ معاہدوں کے ساتھ کسی بھی تعامل کو نئے لین دین کی پیکیجنگ کے ذریعے متضاد طور پر انجام دیا جائے گا۔ سمارٹ معاہدوں کے ذریعے شروع ہونے والے اس طرح کے لین دین کو اندرونی پیغامات بھی کہا جاتا ہے۔ اور پھانسی کا نتیجہ حاصل کرنے کے لیے پھانسی کے عمل کو بلاک نہیں کیا جا سکتا۔

مثال کے طور پر، اگر ہم ایک DEX تیار کرتے ہیں اور EVM میں عام پیرا ڈائم کو اپناتے ہیں، تو عام طور پر ٹرانزیکشن روٹنگ کو منظم کرنے کے لیے ایک متحد راؤٹر کنٹریکٹ ہو گا، اور ہر پول ایک مخصوص تجارتی جوڑی سے متعلق LP ڈیٹا کو الگ سے منظم کرے گا۔ فرض کریں کہ اس وقت دو پول ہیں، USDT-DAI اور DAI-ETH۔ جب کوئی صارف براہ راست USDT کے ذریعے ETH خریدنا چاہتا ہے، تو وہ ایٹم لین دین کو مکمل کرنے کے لیے راؤٹر کنٹریکٹ کے ذریعے ایک لین دین میں ترتیب وار ان دو پولز کی درخواست کر سکتا ہے۔ تاہم، TON میں حاصل کرنا اتنا آسان نہیں ہے، اور ہمیں ترقی کے ایک نئے نمونے کے بارے میں سوچنے کی ضرورت ہے۔ اگر ہم اب بھی اس تمثیل کو دوبارہ استعمال کرتے ہیں تو معلومات کا بہاؤ اس طرح ہو سکتا ہے: اس درخواست کے ساتھ صارف کی طرف سے شروع کردہ ایک خارجی پیغام اور تین اندرونی پیغامات ہوں گے (نوٹ کریں کہ اس کا استعمال فرق کو واضح کرنے کے لیے کیا جاتا ہے۔ حقیقی ترقی میں، یہاں تک کہ ERC 20 پیراڈیم کو دوبارہ ڈیزائن کرنے کی ضرورت ہے)۔

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

3. کچھ پیچیدہ معاملات میں، پہلے موصول ہونے والی لین دین کو پہلے انجام نہیں دیا جا سکتا، اس لیے اس وقت کا رشتہ پہلے سے طے نہیں کیا جا سکتا۔ غیر مطابقت پذیر اور متوازی سمارٹ کنٹریکٹ کالز کے ایسے نظام میں، پروسیسنگ آپریشنز کی ترتیب کی وضاحت کرنا مشکل ہو سکتا ہے۔ یہی وجہ ہے کہ TON میں ہر پیغام کا اپنا منطقی وقت Lamport time ہوتا ہے (اس کے بعد اسے lt کہا جاتا ہے)۔ اس کا استعمال یہ سمجھنے کے لیے کیا جاتا ہے کہ کس واقعے نے دوسرے کو متحرک کیا اور تصدیق کنندہ کو پہلے کیا کارروائی کرنے کی ضرورت ہے۔ ایک سادہ ماڈل کے لیے، پہلے موصول ہونے والی لین دین کو پہلے انجام دیا جانا چاہیے۔

اس ماڈل میں، A اور B بالترتیب دو سمارٹ معاہدوں کی نمائندگی کرتے ہیں، اور ایک وقت کا رشتہ ہے کہ اگر msg 1 _lt

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

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

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

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

ایکس لنکس: https://x.com/web3_mario

ٹیلیگرام ہینڈل: @MarioChin Web3

یہ مضمون انٹرنیٹ سے لیا گیا ہے: TON鈥檚 کی تکنیکی خصوصیات اور سمارٹ کنٹریکٹ ڈویلپمنٹ پیراڈائم کی تفصیلی وضاحت

متعلقہ: انٹرپریٹنگ بیسڈ میمز اور بیسڈ انسٹی ٹیوٹ: بیس ایکو سسٹم کا مستقبل کہاں ہے؟

اصل ماخذ: جیسی پولاک مرتب کردہ: اوڈیلی پلینٹ ڈیلی وینسر ایڈیٹرز نوٹ: 2024 کے گرم ترین L2 ماحولیاتی نظام میں سے ایک کے طور پر، بیس کے عروج کو صحیح وقت، صحیح جگہ اور صحیح لوگوں کا نتیجہ کہا جا سکتا ہے – ایسا نہیں ہے۔ Memecoin کے جنون کے ذریعے صرف گڈ ایسنڈ کا موقع لایا گیا ہے، بلکہ OP ماحولیاتی نظام پر مبنی L2 کم گیس نیٹ ورک اور Coinbase کی حمایت یافتہ، اور پروٹوکول لیڈر جیسی پولاک اور ایکو سسٹم بنانے والوں کے ایک گروپ کی سخت محنت۔ جہاں تک بیس ایکو سسٹم کا تعلق ہے، جس کا TVL 5.5 بلین امریکی ڈالر تک پہنچ گیا ہے، جیسی نے حال ہی میں نیویارک میم ہیکاتھون میں ایک مختصر جائزہ اور خلاصہ دیا، اور حال ہی میں زورا پر مواد کو NFT کی شکل میں ڈالا، اور 4,000 سے زیادہ…