سمارٹ کنٹریکٹس کو اپ گریڈ کرنا

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

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

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

پیشگی شرائط

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

سمارٹ کنٹریکٹ اپ گریڈ کیا ہے؟

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

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

یہ درج ذیل طریقوں سے کیا جا سکتا ہے:

1. سمارٹ کنٹریکٹ کے متعدد ورژنز بنانا اور پرانے کنٹریکٹ سے حالت (یعنی ڈیٹا) کو کنٹریکٹ کی نئی مثال (instance) میں منتقل کرنا۔

2. بزنس لاجک اور حالت کو ذخیرہ کرنے کے لیے الگ الگ کنٹریکٹس بنانا۔

3. ناقابلِ تبدیلی پراکسی کنٹریکٹ سے قابلِ ترمیم لاجک کنٹریکٹ میں فنکشن کالز کو تفویض کرنے کے لیے پراکسی پیٹرنز کا استعمال کرنا۔

4. ایک ناقابلِ تبدیلی مین کنٹریکٹ بنانا جو مخصوص فنکشنز کو انجام دینے کے لیے لچکدار سیٹلائٹ کنٹریکٹس کے ساتھ انٹرفیس کرتا ہے اور ان پر انحصار کرتا ہے۔

5. پراکسی کنٹریکٹ سے لاجک کنٹریکٹس میں فنکشن کالز کو تفویض کرنے کے لیے ڈائمنڈ پیٹرن کا استعمال کرنا۔

اپ گریڈ کا طریقہ کار #1: کنٹریکٹ کی منتقلی

کنٹریکٹ کی منتقلی ورژنگ (versioning) پر مبنی ہے—یعنی ایک ہی سافٹ ویئر کی منفرد حالتوں کو بنانے اور منظم کرنے کا خیال۔ کنٹریکٹ کی منتقلی میں موجودہ سمارٹ کنٹریکٹ کی ایک نئی مثال تعینات کرنا اور سٹوریج اور بیلنس کو نئے کنٹریکٹ میں منتقل کرنا شامل ہے۔

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

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

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

کنٹریکٹ کی منتقلی کے بارے میں مزید۔ (opens in a new tab)

اپ گریڈ کا طریقہ کار #2: ڈیٹا کی علیحدگی

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

لاجک کنٹریکٹ میں وہ کوڈ ہوتا ہے جو اس وقت چلتا ہے جب صارفین ایپلی کیشن کے ساتھ تعامل کرتے ہیں۔ یہ سٹوریج کنٹریکٹ کا پتہ بھی رکھتا ہے اور ڈیٹا حاصل کرنے اور سیٹ کرنے کے لیے اس کے ساتھ تعامل کرتا ہے۔

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

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

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

ڈیٹا کی علیحدگی کا پیٹرن کنٹریکٹ کی منتقلی کے مقابلے میں لاگو کرنا بلاشبہ آسان ہے۔ تاہم، آپ کو متعدد کنٹریکٹس کا انتظام کرنا ہوگا اور سمارٹ کنٹریکٹس کو بدنیتی پر مبنی اپ گریڈز سے بچانے کے لیے پیچیدہ اجازت کی سکیمیں (authorization schemes) نافذ کرنی ہوں گی۔

اپ گریڈ کا طریقہ کار #3: پراکسی پیٹرنز

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

پراکسی پیٹرن میں یہ ہوتا ہے:

1. صارفین پراکسی کنٹریکٹ کے ساتھ تعامل کرتے ہیں، جو ڈیٹا کو ذخیرہ کرتا ہے، لیکن اس میں بزنس لاجک نہیں ہوتی۔

2. پراکسی کنٹریکٹ لاجک کنٹریکٹ کا پتہ ذخیرہ کرتا ہے اور delegatecall فنکشن کا استعمال کرتے ہوئے تمام فنکشن کالز کو لاجک کنٹریکٹ (جس میں بزنس لاجک ہوتی ہے) کو تفویض کرتا ہے۔

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

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

Solidity کی دستاویزات (opens in a new tab) سے:

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

پراکسی کنٹریکٹ جانتا ہے کہ جب بھی کوئی صارف کسی فنکشن کو کال کرتا ہے تو delegatecall کو کیسے طلب کرنا ہے کیونکہ اس میں ایک fallback فنکشن شامل ہوتا ہے۔ Solidity پروگرامنگ میں فال بیک فنکشن (opens in a new tab) اس وقت چلایا جاتا ہے جب کوئی فنکشن کال کنٹریکٹ میں بیان کردہ فنکشنز سے میل نہیں کھاتی۔

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

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

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

پراکسی پیٹرنز سمارٹ کنٹریکٹس کو اپ گریڈ کرنے کا ایک مقبول طریقہ ہیں کیونکہ یہ کنٹریکٹ کی منتقلی سے وابستہ مشکلات کو ختم کرتے ہیں۔ تاہم، پراکسی پیٹرنز استعمال کرنے میں زیادہ پیچیدہ ہیں اور اگر انہیں غلط طریقے سے استعمال کیا جائے تو یہ اہم خامیاں متعارف کرا سکتے ہیں، جیسے کہ فنکشن سلیکٹر کے تصادم (opens in a new tab)۔

پراکسی پیٹرنز کے بارے میں مزید (opens in a new tab)۔

اپ گریڈ کا طریقہ کار #4: حکمت عملی کا پیٹرن

یہ تکنیک حکمت عملی کے پیٹرن (opens in a new tab) سے متاثر ہے، جو ایسے سافٹ ویئر پروگرام بنانے کی حوصلہ افزائی کرتی ہے جو مخصوص خصوصیات کو نافذ کرنے کے لیے دوسرے پروگراموں کے ساتھ انٹرفیس کرتے ہیں۔ ایتھیریم ڈیولپمنٹ پر حکمت عملی کے پیٹرن کو لاگو کرنے کا مطلب ایک ایسا سمارٹ کنٹریکٹ بنانا ہوگا جو دوسرے کنٹریکٹس سے فنکشنز کو کال کرتا ہے۔

اس صورت میں مین کنٹریکٹ میں بنیادی بزنس لاجک ہوتی ہے، لیکن یہ کچھ فنکشنز کو انجام دینے کے لیے دوسرے سمارٹ کنٹریکٹس ("سیٹلائٹ کنٹریکٹس") کے ساتھ انٹرفیس کرتا ہے۔ یہ مین کنٹریکٹ ہر سیٹلائٹ کنٹریکٹ کا پتہ بھی ذخیرہ کرتا ہے اور سیٹلائٹ کنٹریکٹ کے مختلف نفاذ کے درمیان سوئچ کر سکتا ہے۔

آپ ایک نیا سیٹلائٹ کنٹریکٹ بنا سکتے ہیں اور مین کنٹریکٹ کو نئے پتہ کے ساتھ کنفیگر کر سکتے ہیں۔ یہ آپ کو سمارٹ کنٹریکٹ کے لیے حکمت عملیاں تبدیل کرنے (یعنی نئی لاجک نافذ کرنے) کی اجازت دیتا ہے۔

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

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

اپ گریڈ کا طریقہ کار #5: ڈائمنڈ پیٹرن

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

ڈائمنڈ پیٹرن میں لاجک کنٹریکٹس کو facets کے نام سے جانا جاتا ہے۔ ڈائمنڈ پیٹرن کو کام کرنے کے قابل بنانے کے لیے، آپ کو پراکسی کنٹریکٹ میں ایک میپنگ بنانے کی ضرورت ہے جو فنکشن سلیکٹرز (opens in a new tab) کو مختلف facet کے پتوں سے میپ کرتی ہے۔

جب کوئی صارف فنکشن کال کرتا ہے، تو پراکسی کنٹریکٹ اس فنکشن کو چلانے کے ذمہ دار facet کو تلاش کرنے کے لیے میپنگ چیک کرتا ہے۔ پھر یہ (فال بیک فنکشن کا استعمال کرتے ہوئے) delegatecall کو طلب کرتا ہے اور کال کو مناسب لاجک کنٹریکٹ کی طرف موڑ دیتا ہے۔

ڈائمنڈ اپ گریڈ پیٹرن کے روایتی پراکسی اپ گریڈ پیٹرنز پر کچھ فوائد ہیں:

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

2. تمام سمارٹ کنٹریکٹس (بشمول پراکسی پیٹرنز میں استعمال ہونے والے لاجک کنٹریکٹس) کی سائز کی حد 24KB ہوتی ہے، جو ایک رکاوٹ ہو سکتی ہے—خاص طور پر پیچیدہ کنٹریکٹس کے لیے جنہیں زیادہ فنکشنز کی ضرورت ہوتی ہے۔ ڈائمنڈ پیٹرن فنکشنز کو متعدد لاجک کنٹریکٹس میں تقسیم کر کے اس مسئلے کو حل کرنا آسان بناتا ہے۔

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

ڈائمنڈ پیٹرن کے بارے میں مزید (opens in a new tab)۔

سمارٹ کنٹریکٹس کو اپ گریڈ کرنے کے فوائد اور نقصانات

سمارٹ کنٹریکٹس کو اپ گریڈ کرنے کے لیے تحفظات

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

2. سمارٹ کنٹریکٹس کو اپ گریڈ کرنا ایک پیچیدہ سرگرمی ہے اور کمزوریوں کے تعارف کو روکنے کے لیے اعلیٰ سطح کی مستعدی کی ضرورت ہوتی ہے۔

3. اپ گریڈز کو نافذ کرنے کے عمل کو لامركزی بنا کر اعتماد کے مفروضے کم کریں۔ ممکنہ حکمت عملیوں میں اپ گریڈز کو کنٹرول کرنے کے لیے ملٹی سگ والیٹ کنٹریکٹ کا استعمال کرنا، یا اپ گریڈ کی منظوری پر ووٹ دینے کے لیے DAO کے اراکین سے تقاضا کرنا شامل ہے۔

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

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

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

وسائل

اوپن زیپلن اپ گریڈز پلگ انز - اپ گریڈ کے قابل سمارٹ کنٹریکٹس کو تعینات اور محفوظ کرنے کے لیے ٹولز کا ایک مجموعہ۔

• GitHub (opens in a new tab)
• دستاویزات (opens in a new tab)

ٹیوٹوریلز

• پیٹرک کولنز کی جانب سے اپنے سمارٹ کنٹریکٹس کو اپ گریڈ کرنا | یوٹیوب ٹیوٹوریل (opens in a new tab)
• آسٹن گریفتھ کی جانب سے ایتھیریم سمارٹ کنٹریکٹ کی منتقلی کا ٹیوٹوریل (opens in a new tab)
• پرنیش اے ایس کی جانب سے سمارٹ کنٹریکٹس کو اپ گریڈ کرنے کے لیے UUPS پراکسی پیٹرن کا استعمال (opens in a new tab)
• fangjun.eth کی جانب سے Web3 ٹیوٹوریل: اوپن زیپلن کا استعمال کرتے ہوئے اپ گریڈ کے قابل سمارٹ کنٹریکٹ (پراکسی) لکھیں (opens in a new tab)

مزید مطالعہ

• سینٹیاگو پیلاڈینو کی جانب سے سمارٹ کنٹریکٹ اپ گریڈز کی حالت (opens in a new tab)
• Solidity سمارٹ کنٹریکٹ کو اپ گریڈ کرنے کے متعدد طریقے (opens in a new tab) - کرپٹو مارکیٹ پول بلاگ
• سیکھیں: سمارٹ کنٹریکٹس کو اپ گریڈ کرنا (opens in a new tab) - اوپن زیپلن دستاویزات
• نوین ساہو کی جانب سے Solidity کنٹریکٹس کی اپ گریڈ ایبلٹی کے لیے پراکسی پیٹرنز: شفاف بمقابلہ UUPS پراکسیز (opens in a new tab)
• نک مج کی جانب سے ڈائمنڈ اپ گریڈز کیسے کام کرتے ہیں (opens in a new tab)