i18n(ur): automated Crowdin translation import (part 09 of 13)

public/content/translations/ur/developers/tutorials/smart-contract-security-guidelines/index.md

@@ -0,0 +1,91 @@
+---
+title: "اسمارٹ کنٹریکٹ سیکیورٹی گائیڈ لائنز"
+description: "اپنا ڈیپ بناتے وقت غور کرنے کے لیے سیکیورٹی گائیڈ لائنز کی ایک چیک لسٹ"
+author: "Trailofbits"
+tags: [ "solidity", "اسمارٹ معاہدات", "سیکورٹی" ]
+skill: intermediate
+lang: ur-in
+published: 2020-09-06
+source: Building secure contracts
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
+---
+
+مزید محفوظ اسمارٹ کنٹریکٹس بنانے کے لیے ان اعلیٰ سطحی سفارشات پر عمل کریں۔
+
+## ڈیزائن کے رہنما اصول {#design-guidelines}
+
+کنٹریکٹ کے ڈیزائن پر پہلے سے، کوڈ کی کوئی بھی لائن لکھنے سے پہلے بات چیت کی جانی چاہیے۔
+
+### دستاویزات اور وضاحتیں {#documentation-and-specifications}
+
+دستاویزات مختلف سطحوں پر لکھی جا سکتی ہیں، اور کنٹریکٹس کو نافذ کرتے وقت اسے اپ ڈیٹ کیا جانا چاہیے:
+
+- **سسٹم کی سادہ انگریزی میں تفصیل**، یہ بیان کرتے ہوئے کہ کنٹریکٹس کیا کرتے ہیں اور کوڈبیس پر کوئی بھی مفروضہ۔
+- **اسکیما اور آرکیٹیکچرل ڈایاگرام**، بشمول کنٹریکٹ کے تعاملات اور سسٹم کی اسٹیٹ مشین۔ [Slither پرنٹرز](https://github.com/crytic/slither/wiki/Printer-documentation) ان اسکیماز کو بنانے میں مدد کر سکتے ہیں۔
+- **مکمل کوڈ دستاویزات**، [Natspec فارمیٹ](https://docs.soliditylang.org/en/develop/natspec-format.html) Solidity کے لیے استعمال کیا جا سکتا ہے۔
+
+### آن چین بمقابلہ آف چین کمپیوٹیشن {#onchain-vs-offchain-computation}
+
+- **جتنا ہو سکے کوڈ کو آف چین رکھیں۔** آن چین لیئر کو چھوٹا رکھیں۔ آف چین کوڈ کے ساتھ ڈیٹا کو اس طرح پہلے سے پروسیس کریں کہ آن چین تصدیق آسان ہو۔ کیا آپ کو ایک ترتیب شدہ فہرست کی ضرورت ہے؟ فہرست کو آف چین ترتیب دیں، پھر اس کی ترتیب کو صرف آن چین چیک کریں۔
+
+### اپ گریڈ ایبلٹی {#upgradeability}
+
+ہم نے [ہمارے بلاگ پوسٹ](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) میں مختلف اپ گریڈ ایبلٹی حل پر تبادلہ خیال کیا ہے۔ کوئی بھی کوڈ لکھنے سے پہلے اپ گریڈ ایبلٹی کو سپورٹ کرنے یا نہ کرنے کا دانستہ انتخاب کریں۔ یہ فیصلہ اس بات پر اثرانداز ہوگا کہ آپ اپنے کوڈ کی ساخت کیسے بناتے ہیں۔ عام طور پر، ہم تجویز کرتے ہیں:
+
+- **اپ گریڈ ایبلٹی پر [کنٹریکٹ مائیگریشن](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) کو ترجیح دینا۔** مائیگریشن سسٹم میں اپ گریڈ ایبل سسٹم جیسے بہت سے فوائد ہوتے ہیں، بغیر ان کی خامیوں کے۔
+- **delegatecallproxy کے بجائے ڈیٹا سیپریشن پیٹرن کا استعمال۔** اگر آپ کے پروجیکٹ میں واضح تجریدی علیحدگی ہے، تو ڈیٹا سیپریشن کا استعمال کرتے ہوئے اپ گریڈ ایبلٹی کے لیے صرف چند ایڈجسٹمنٹ کی ضرورت ہوگی۔ delegatecallproxy کے لیے EVM کی مہارت درکار ہے اور یہ بہت زیادہ غلطی کا شکار ہے۔
+- **تعیناتی سے پہلے مائیگریشن/اپ گریڈ کے طریقہ کار کو دستاویز کریں۔** اگر آپ کو بغیر کسی رہنما اصول کے دباؤ میں رد عمل ظاہر کرنا پڑا تو آپ غلطیاں کریں گے۔ پیروی کرنے کے لیے طریقہ کار پہلے سے لکھیں۔ اس میں شامل ہونا چاہیے:
+  - وہ کالز جو نئے کنٹریکٹس شروع کرتی ہیں
+  - چابیاں کہاں محفوظ ہیں اور ان تک کیسے رسائی حاصل کی جائے
+  - تعیناتی کو کیسے چیک کریں! ایک پوسٹ-ڈیپلائمنٹ اسکرپٹ تیار اور ٹیسٹ کریں۔
+
+## نفاذ کے رہنما اصول {#implementation-guidelines}
+
+**سادگی کے لیے کوشش کریں۔** ہمیشہ سب سے آسان حل استعمال کریں جو آپ کے مقصد کے مطابق ہو۔ آپ کی ٹیم کا کوئی بھی رکن آپ کے حل کو سمجھنے کے قابل ہونا چاہیے۔
+
+### فنکشن کمپوزیشن {#function-composition}
+
+آپ کے کوڈبیس کا فن تعمیر آپ کے کوڈ کا جائزہ لینا آسان بنانا چاہیے۔ ایسے آرکیٹیکچرل انتخاب سے گریز کریں جو اس کی درستگی کے بارے میں استدلال کرنے کی صلاحیت کو کم کرتے ہیں۔
+
+- **اپنے سسٹم کی منطق کو تقسیم کریں**، یا تو متعدد کنٹریکٹس کے ذریعے یا اسی طرح کے فنکشنز کو ایک ساتھ گروپ کرکے (مثال کے طور پر، توثیق، ریاضی، ...)۔
+- **چھوٹے فنکشنز لکھیں، ایک واضح مقصد کے ساتھ۔** یہ آسان جائزہ لینے میں سہولت فراہم کرے گا اور انفرادی اجزاء کی جانچ کی اجازت دے گا۔
+
+### وراثت {#inheritance}
+
+- **وراثت کو قابل انتظام رکھیں۔** وراثت کو منطق کو تقسیم کرنے کے لیے استعمال کیا جانا چاہیے، تاہم، آپ کے پروجیکٹ کا مقصد وراثت کے درخت کی گہرائی اور چوڑائی کو کم کرنا ہونا چاہیے۔
+- **کنٹریکٹس کے درجہ بندی کو چیک کرنے کے لیے Slither کے [وراثت پرنٹر](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) کا استعمال کریں۔** وراثت پرنٹر آپ کو درجہ بندی کے سائز کا جائزہ لینے میں مدد کرے گا۔
+
+### ایونٹس {#events}
+
+- **تمام اہم کارروائیوں کو لاگ کریں۔** ایونٹس ڈیولپمنٹ کے دوران کنٹریکٹ کو ڈیبگ کرنے، اور تعیناتی کے بعد اس کی نگرانی کرنے میں مدد کریں گے۔
+
+### معروف نقصانات سے بچیں {#avoid-known-pitfalls}
+
+- **سب سے عام سیکیورٹی مسائل سے آگاہ رہیں۔** عام مسائل کے بارے میں جاننے کے لیے بہت سے آن لائن وسائل موجود ہیں، جیسے کہ [Ethernaut CTF](https://ethernaut.openzeppelin.com/)، [Capture the Ether](https://capturetheether.com/)، یا [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/)۔
+- **[Solidity دستاویزات](https://docs.soliditylang.org/en/latest/) میں وارننگ سیکشنز سے آگاہ رہیں۔** وارننگ سیکشنز آپ کو زبان کے غیر واضح رویے کے بارے میں آگاہ کریں گے۔
+
+### انحصار {#dependencies}
+
+- **اچھی طرح سے ٹیسٹ شدہ لائبریریوں کا استعمال کریں۔** اچھی طرح سے ٹیسٹ شدہ لائبریریوں سے کوڈ درآمد کرنا اس امکان کو کم کر دے گا کہ آپ بگ والا کوڈ لکھیں۔ اگر آپ ERC20 کنٹریکٹ لکھنا چاہتے ہیں، تو [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20) استعمال کریں۔
+- **ایک ڈیپنڈنسی مینیجر کا استعمال کریں؛ کوڈ کو کاپی پیسٹ کرنے سے گریز کریں۔** اگر آپ کسی بیرونی ماخذ پر انحصار کرتے ہیں، تو آپ کو اسے اصل ماخذ کے ساتھ اپ ٹو ڈیٹ رکھنا چاہیے۔
+
+### جانچ اور تصدیق {#testing-and-verification}
+
+- **مکمل یونٹ ٹیسٹ لکھیں۔** اعلیٰ معیار کا سافٹ ویئر بنانے کے لیے ایک وسیع ٹیسٹ سویٹ بہت ضروری ہے۔
+- **[Slither](https://github.com/crytic/slither)، [Echidna](https://github.com/crytic/echidna) اور [Manticore](https://github.com/trailofbits/manticore) کسٹم چیکس اور پراپرٹیز لکھیں۔** خودکار ٹولز آپ کے کنٹریکٹ کو محفوظ بنانے میں مدد کریں گے۔ موثر چیکس اور پراپرٹیز لکھنے کا طریقہ جاننے کے لیے اس گائیڈ کے باقی حصے کا جائزہ لیں۔
+- **[crytic.io](https://crytic.io/) کا استعمال کریں۔** Crytic GitHub کے ساتھ مربوط ہوتا ہے، نجی Slither ڈیٹیکٹرز تک رسائی فراہم کرتا ہے، اور Echidna سے کسٹم پراپرٹی چیکس چلاتا ہے۔
+
+### Solidity {#solidity}
+
+- **0.4 اور 0.6 پر Solidity 0.5 کو ترجیح دیں۔** ہماری رائے میں، Solidity 0.5 زیادہ محفوظ ہے اور 0.4 کے مقابلے میں بہتر بلٹ ان پریکٹسز رکھتا ہے۔ Solidity 0.6 پروڈکشن کے لیے بہت غیر مستحکم ثابت ہوا ہے اور اسے پختہ ہونے کے لیے وقت درکار ہے۔
+- **کمپائل کرنے کے لیے ایک مستحکم ریلیز کا استعمال کریں؛ وارننگز چیک کرنے کے لیے تازہ ترین ریلیز کا استعمال کریں۔** چیک کریں کہ آپ کے کوڈ میں تازہ ترین کمپائلر ورژن کے ساتھ کوئی رپورٹ شدہ مسئلہ نہیں ہے۔ تاہم، Solidity کا ایک تیز ریلیز سائیکل ہے اور اس میں کمپائلر بگز کی تاریخ ہے، اس لیے ہم تعیناتی کے لیے تازہ ترین ورژن کی سفارش نہیں کرتے ہیں (Slither کی [solc ورژن کی سفارش](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) دیکھیں)۔
+- **ان لائن اسمبلی کا استعمال نہ کریں۔** اسمبلی کے لیے EVM کی مہارت درکار ہے۔ EVM کوڈ نہ لکھیں اگر آپ نے یلو پیپر میں _مہارت_ حاصل نہیں کی ہے۔
+
+## تعیناتی کے رہنما اصول {#deployment-guidelines}
+
+ایک بار جب کنٹریکٹ تیار اور تعینات ہو جائے:
+
+- **اپنے کنٹریکٹس کی نگرانی کریں۔** لاگز دیکھیں، اور کنٹریکٹ یا والیٹ کے سمجھوتے کی صورت میں رد عمل ظاہر کرنے کے لیے تیار رہیں۔
+- **اپنی رابطہ کی معلومات [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts) میں شامل کریں۔** یہ فہرست تیسرے فریق کو آپ سے رابطہ کرنے میں مدد کرتی ہے اگر کوئی سیکیورٹی خامی دریافت ہوتی ہے۔
+- **مراعات یافتہ صارفین کے والیٹس کو محفوظ بنائیں۔** اگر آپ ہارڈ ویئر والیٹس میں چابیاں محفوظ کرتے ہیں تو ہماری [بہترین طریقوں](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) پر عمل کریں۔
+- **واقعہ کے جواب کا منصوبہ بنائیں۔** غور کریں کہ آپ کے اسمارٹ کنٹریکٹس سے سمجھوتہ کیا جا سکتا ہے۔ یہاں تک کہ اگر آپ کے کنٹریکٹس بگ سے پاک ہیں، ایک حملہ آور کنٹریکٹ کے مالک کی چابیوں پر کنٹرول حاصل کر سکتا ہے۔