اما آڈٹ – فیز 6

تعارف

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

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

آڈٹ شدہ کمٹ ہے۔ 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc اور دائرہ کار میں درج ذیل معاہدے شامل ہیں:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (ٹیسٹ اور پولیگون معاہدوں کو چھوڑ کر)
• financial-templates/optimistic-rewarder/* (ٹیسٹ معاہدوں کو چھوڑ کر)

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

تمام خارجی کوڈ اور معاہدے کے انحصار کو دستاویزی طور پر کام کرنے کے لیے فرض کیا گیا تھا۔

سسٹم کا جائزہ

موجودہ Governance معاہدہ رسک لیبز فاؤنڈیشن کو گورننس کے نئے اقدامات تجویز کرنے کی اجازت دیتا ہے جن کی UMA ٹوکن ہولڈرز کی توثیق کی جا سکتی ہے۔ نیا Proposer معاہدے کا مقصد تجویز کنندہ کا کردار ادا کرنا ہے، کسی کو بھی اس وقت تک نئی تجاویز دینے کی اجازت دیتا ہے جب تک کہ وہ ایک بانڈ فراہم کرتے ہیں جو تجویز کے ناکام ہونے کی صورت میں قربان کیا جائے گا۔ تجاویز دینے کے لیے کوئی خاص ترغیب نہیں ہے۔ ارادہ یہ یقینی بنانا ہے کہ صرف وہی اعمال تجویز کیے جائیں گے جن کے قبول کیے جانے کا بہت زیادہ امکان ہے۔

نیا کراس چین میکانزم گورننس کی تجویز کو Ethereum مینیٹ سے Optimism اور Arbitrum چینز تک منتقل کرنے کی اجازت دیتا ہے۔ اس طرح، لیئر 1 پر UMA گورننس میکانزم کو سپورٹڈ لیئر 2 چینز پر UMA کنٹریکٹس کو چلانے کے لیے استعمال کیا جا سکتا ہے۔ یہ طریقہ کار قیمت کی درخواستوں اور قراردادوں کو تہوں کے درمیان آگے بھیجنے کی بھی اجازت دیتا ہے، لہذا پرت 2 کی زنجیروں پر آپٹیمسٹک اوریکلز کو مین نیٹ ڈیٹا کی تصدیق کے طریقہ کار کے ذریعے اسی طرح محفوظ کیا جا سکتا ہے جس طرح پرت 1 آپٹیمسٹک اوریکل کو DVM کے ذریعے محفوظ کیا جاتا ہے۔

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

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

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

نازک شدت

[C01] غلط انعام پر تنازعہ نہیں کر سکتا

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

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 9e15557 in PR3690.

[C02] بار بار تجاویز کو حل کریں۔

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ b152718 in PR3689.

اعلی شدت

کوئی بھی نہیں.

درمیانی شدت

[M01] ایونٹ کے غلط پیرامیٹرز

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

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

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ f04eef9 in PR3694.

کم شدت

[L01] چھٹکارے کے تنازعہ کے بعد ایونٹ کے اخراج کی کمی

۔ OptimisticRewarderBase معاہدہ کی وضاحت کرتا ہے a Disputed تقریب اگر کسی چھٹکارے پر اختلاف ہو تو اسے متحرک کرنا مقصود ہے۔ تاہم، یہ واقعہ اس کے اندر یا باہر خارج نہیں ہوتا ہے۔ OptimisticRewarderBase معاہدہ.

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ c275e92 in PR3695.

[L02] متضاد ری اینٹرینسی گارڈ

۔ Optimism_ParentMessenger اور Arbitrum_ParentMessenger معاہدے متضاد طور پر لاگو ہوتے ہیں۔ nonReentrant ترمیم کرنے والا اسے تمام عوامی کاموں میں شامل کرنے پر غور کریں۔

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 6275c39 in PR3677.

[L03] گمراہ کن تبصرے۔

یہاں کچھ گمراہ کن تبصرے ہیں جن کی ہم نے اپنے جائزے کے دوران نشاندہی کی:

• ChildMessengerConsumerInterface.sol:
  • لائن 5 "چائلڈ میسنجر" کے بجائے "والدین میسنجر" کہتا ہے
• GovernorSpoke.sol:
  • لائنیں 49-51 کے لنکس Gnosis فائل اگرچہ تبصرہ کہتا ہے کہ اس کا ٹکڑا کاپی کیا گیا تھا۔ Governor.sol. مزید برآں، اس کا ٹکڑا اس میں سے ایک جیسا نہیں ہے۔ Governor.sol

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ cc350f9 in PR3678.

[L04] ذیلی ڈیٹا سٹیمپ غائب ہے۔

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ fdb845d in PR3668.

[L05] NatSpec پیرامیٹر غائب ہے۔

میں بہت سے افعال OptimisticRewarderBase کنٹریکٹ غائب ہیں @return ان کے قدرتی تفصیلات کے تبصروں میں پیرامیٹر۔ مکمل ہونے کے لیے اسے شامل کرنے پر غور کریں۔

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 8920f38 in PR3679.

[L06] بقایا الاؤنس

آپٹیمسٹک اوریکل کو دعوت دینے کے لیے، OptimisticRewarderBase کنٹریکٹ اسے ٹوکن الاؤنس دیتا ہے۔، تو یہ بانڈ کی ادائیگیوں کو کھینچ سکتا ہے۔ اگر تجویز ناکام ہو جاتی ہے، انعام کی ادائیگی منسوخ کر دی گئی ہے۔ لیکن الاؤنس دوبارہ ترتیب نہیں دیا گیا ہے۔ لہذا، Optimistic Oracle اس وقت تک غیر ضروری بقایا الاؤنس برقرار رکھے گا جب تک کہ اگلی بار کوئی تنازعہ شروع نہ ہوجائے۔ اگر تجویز ناکام ہو جاتی ہے تو الاؤنس کو منسوخ کرنے پر غور کریں۔

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ c2d444b in PR3698.

[L07] ریفنڈ کا غلط پتہ

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

اسے ایک درست L2 ایڈریس پر سیٹ کرنے پر غور کریں۔

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ b3f2dd1 in PR3687.

[L08] چائلڈ میسنجر کو تبدیل کرنے کا طریقہ کار

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

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 7c9e061 in PR3688.

نوٹس اور اضافی معلومات

[N01] بانڈ ٹوکن تبدیل کریں۔

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

: اپ ڈیٹ کریں کوئی مسئلہ نہیں۔ اس مسئلے کے لیے UMA کا بیان:

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

[N02] نامکمل انٹرفیس

۔ ChildMessengerInterface a کی وضاحت نہیں کرتا processMessageFromCrossChainParent فنکشن، اگرچہ یہ فرض کیا جاتا ہے کہ یہ والدین میسنجر کے ذریعہ موجود ہے۔ مکمل ہونے کے لیے اسے شامل کرنے پر غور کریں۔

: اپ ڈیٹ کریں طے شدہ نہیں۔ اس مسئلے کے لیے UMA کا بیان:

ہم نے جان بوجھ کر اس انٹرفیس کو متضاد چھوڑنے کا انتخاب کیا کیونکہ اسے چائلڈ میسنجر انٹرفیس کے اندر لاگو کرنے سے Polygon_ChildMessenger کے ساتھ مطابقت ٹوٹ جاتی ہے کیونکہ دیگر زنجیروں سے پیغامات پر کارروائی کرنے کے لیے پولیگون کے طریقہ کار کے لیے کسی حد تک حسب ضرورت منطق کی ضرورت ہوتی ہے جس میں اندرونی طریقہ کو _processMessageFromRoot کہا جاتا ہے۔

[N03] غلط انٹرفیس

۔ GovernorSpoke غلط معاہدہ کا استعمال کرتا ہے ChildMessengerConsumerInterface قسم اس کی وضاحت کرنے کے لئے messenger متغیر کے استعمال پر غور کریں۔ ChildMessengerInterface بجائے.

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ f31a527 in PR3680.

[N04] اسٹور کے لیے ٹوکن کھینچیں۔

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

: اپ ڈیٹ کریں تسلیم کیا۔ اس مسئلے کے لیے UMA کا بیان:

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

[N05] کوڈ میں ٹوڈو

کوڈ بیس میں "TODO" کے تبصرے ہیں جنہیں پروجیکٹ کے مسائل کے بیک لاگ میں ٹریک کیا جانا چاہیے۔ مثال کے طور پر:

• لائن 37 of Arbitrum_ParentMessenger کنٹریکٹ
• لائن 25 of Optimism_ChildMessenger کنٹریکٹ
• لکیریں 83 اور 146 of OracleHub معاہدہ.

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

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

اس معلومات کو شامل کرنے کے لیے TODO کے تبصروں کو اپ ڈیٹ کرنے پر غور کریں۔ مکمل اور سراغ لگانے کے لیے، ایک دستخط اور ٹائم اسٹیمپ شامل کیا جا سکتا ہے۔ مثال کے طور پر:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 5d57b5b in PR3684.

[N06] ٹائپوگرافیکل غلطیاں

کوڈ بیس میں درج ذیل ٹائپوگرافیکل غلطیاں ہیں:

• میں Admin_ChildMessenger معاہدہ ، impleenting ہونا چاہئے implementing
• میں OptimisticRewarderBase معاہدہ ، timestap ہونا چاہئے timestamp.
• میں OptimisticRewarderBase معاہدہ ، liveness liveness ہونا چاہئے liveness.
• میں GovernorSpoke معاہدہ ، only called ہونا چاہئے only be called.
• میں Optimism_ChildMessenger معاہدہ:

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 9b92b0b in PR3681.

[N07] غیر استعمال شدہ درآمدات

کوڈ کی پڑھنے کی اہلیت کو بہتر بنانے کے لیے، درج ذیل غیر استعمال شدہ درآمدات کو ہٹانے پر غور کریں:

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 40b7221 in PR3682.

[N08] L2 ٹرانزیکشن آرڈرنگ

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

: اپ ڈیٹ کریں عہد کے مطابق طے شدہ 0fb2e7b in PR3703. GovernorHub اب L2 لین دین کی ایک صف کو ریلے کر سکتے ہیں۔

نتیجہ

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

ماخذ: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6