From e19ce026cda1faf3810662cc98c730d1b6ca9336 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:09:15 +0000 Subject: [PATCH 1/2] i18n(ur): translation import part 06 of 13 (23 files) --- .../docs/smart-contracts/anatomy/index.md | 657 ++++++++++++++++++ .../docs/smart-contracts/compiling/index.md | 282 ++++++++ .../smart-contracts/composability/index.md | 76 ++ .../docs/smart-contracts/deploying/index.md | 81 +++ .../formal-verification/index.md | 284 ++++++++ .../developers/docs/smart-contracts/index.md | 112 +++ .../docs/smart-contracts/languages/index.md | 342 +++++++++ .../docs/smart-contracts/libraries/index.md | 117 ++++ .../docs/smart-contracts/naming/index.md | 101 +++ .../docs/smart-contracts/security/index.md | 576 +++++++++++++++ .../docs/smart-contracts/testing/index.md | 310 +++++++++ .../docs/smart-contracts/upgrading/index.md | 165 +++++ .../docs/smart-contracts/verifying/index.md | 113 +++ .../ur/developers/docs/standards/index.md | 59 ++ .../docs/standards/tokens/erc-1155/index.md | 146 ++++ .../docs/standards/tokens/erc-1363/index.md | 204 ++++++ .../docs/standards/tokens/erc-20/index.md | 192 +++++ .../docs/standards/tokens/erc-223/index.md | 198 ++++++ .../docs/standards/tokens/erc-4626/index.md | 227 ++++++ .../docs/standards/tokens/erc-721/index.md | 248 +++++++ .../docs/standards/tokens/erc-777/index.md | 45 ++ .../developers/docs/standards/tokens/index.md | 41 ++ .../ur/developers/docs/storage/index.md | 216 ++++++ 23 files changed, 4792 insertions(+) create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/anatomy/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/compiling/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/composability/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/deploying/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/formal-verification/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/languages/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/libraries/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/naming/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/security/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/testing/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/upgrading/index.md create mode 100644 public/content/translations/ur/developers/docs/smart-contracts/verifying/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-1155/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-1363/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-223/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-4626/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-721/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/erc-777/index.md create mode 100644 public/content/translations/ur/developers/docs/standards/tokens/index.md create mode 100644 public/content/translations/ur/developers/docs/storage/index.md diff --git a/public/content/translations/ur/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/ur/developers/docs/smart-contracts/anatomy/index.md new file mode 100644 index 00000000000..222bdc067f2 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/anatomy/index.md @@ -0,0 +1,657 @@ +--- +title: "اسمارٹ کنٹریکٹس کا تجزیہ" +description: "اسمارٹ کنٹریکٹ کے تجزیہ میں ایک گہری نظر - فنکشنز، ڈیٹا، اور متغیرات۔" +lang: ur-in +--- + +اسمارٹ کنٹریکٹ ایک پروگرام ہے جو Ethereum پر ایک ایڈریس پر چلتا ہے۔ یہ ڈیٹا اور فنکشنز سے بنے ہوتے ہیں جو ٹرانزیکشن ملنے پر عمل میں آسکتے ہیں۔ اسمارٹ کنٹریکٹ کن چیزوں سے مل کر بنتا ہے اس کا ایک جائزہ یہاں پیش ہے۔ + +## شرائط {#prerequisites} + +پہلے یہ یقینی بنائیں کہ آپ نے [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) کے بارے میں پڑھا ہے۔ یہ دستاویز یہ مان کر چلتی ہے کہ آپ پہلے ہی JavaScript یا Python جیسی پروگرامنگ زبانوں سے واقف ہیں۔ + +## ڈیٹا {#data} + +کسی بھی کنٹریکٹ ڈیٹا کو ایک مقام پر تفویض کیا جانا چاہیے: یا تو `storage` میں یا `memory` میں۔ اسمارٹ کنٹریکٹ میں اسٹوریج میں ترمیم کرنا مہنگا ہے لہذا آپ کو یہ غور کرنے کی ضرورت ہے کہ آپ کا ڈیٹا کہاں رہنا چاہیے۔ + +### اسٹوریج {#storage} + +مستقل ڈیٹا کو اسٹوریج کہا جاتا ہے اور اسے اسٹیٹ متغیرات سے ظاہر کیا جاتا ہے۔ یہ قدریں بلاک چین پر مستقل طور پر محفوظ ہو جاتی ہیں۔ آپ کو ٹائپ کا اعلان کرنے کی ضرورت ہے تاکہ کنٹریکٹ یہ ٹریک رکھ سکے کہ اسے کمپائل کرتے وقت بلاک چین پر کتنے اسٹوریج کی ضرورت ہے۔ + +```solidity +// Solidity کی مثال +contract SimpleStorage { + uint storedData; // اسٹیٹ متغیر + // ... +} +``` + +```python +# Vyper کی مثال +storedData: int128 +``` + +اگر آپ پہلے ہی آبجیکٹ اورینٹڈ زبانوں میں پروگرامنگ کر چکے ہیں، تو آپ شاید زیادہ تر ٹائپس سے واقف ہوں گے۔ تاہم، اگر آپ Ethereum ڈیولپمنٹ میں نئے ہیں تو `address` آپ کے لیے نیا ہونا چاہیے۔ + +ایک `address` ٹائپ ایک Ethereum ایڈریس رکھ سکتا ہے جو 20 بائٹس یا 160 بٹس کے برابر ہے۔ یہ ایک سرکردہ 0x کے ساتھ ہیکسا ڈیسیمل نوٹیشن میں واپس آتا ہے۔ + +دیگر ٹائپس میں شامل ہیں: + +- بولین +- انٹیجر +- فکسڈ پوائنٹ نمبرز +- فکسڈ سائز بائٹ ایریز +- متحرک سائز کے بائٹ ایریز +- ریشنل اور انٹیجر لٹرلز +- سٹرنگ لٹرلز +- ہیکسا ڈیسیمل لٹرلز +- اینمز + +مزید وضاحت کے لیے، دستاویزات پر ایک نظر ڈالیں: + +- [Vyper ٹائپس دیکھیں](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types) +- [Solidity ٹائپس دیکھیں](https://docs.soliditylang.org/en/latest/types.html#value-types) + +### میموری {#memory} + +وہ قدریں جو صرف کنٹریکٹ فنکشن کے عمل کی مدت کے لیے محفوظ کی جاتی ہیں، میموری متغیرات کہلاتی ہیں۔ چونکہ یہ بلاک چین پر مستقل طور پر محفوظ نہیں ہوتے ہیں، اس لیے ان کا استعمال بہت سستا ہوتا ہے۔ + +[Solidity دستاویزات](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack) میں EVM ڈیٹا (اسٹوریج، میموری، اور اسٹیک) کو کیسے اسٹور کرتا ہے اس کے بارے میں مزید جانیں۔ + +### انوائرمنٹ متغیرات {#environment-variables} + +آپ کے کنٹریکٹ پر آپ کے ذریعے بیان کردہ متغیرات کے علاوہ، کچھ خاص عالمی متغیرات بھی ہوتے ہیں۔ وہ بنیادی طور پر بلاک چین یا موجودہ ٹرانزیکشن کے بارے میں معلومات فراہم کرنے کے لیے استعمال ہوتے ہیں۔ + +مثالیں: + +| **پراپ** | **اسٹیٹ متغیر** | **تفصیل** | +| ----------------- | --------------- | ------------------------------------------------- | +| `block.timestamp` | uint256 | موجودہ بلاک ایپوک ٹائم اسٹیمپ | +| `msg.sender` | ایڈریس | پیغام بھیجنے والا (موجودہ کال) | + +## فنکشنز {#functions} + +آسان ترین الفاظ میں، فنکشنز آنے والے ٹرانزیکشنز کے جواب میں معلومات حاصل کر سکتے ہیں یا معلومات سیٹ کر سکتے ہیں۔ + +فنکشن کالز کی دو اقسام ہیں: + +- `internal` – یہ EVM کال نہیں بناتے + - اندرونی فنکشنز اور اسٹیٹ متغیرات تک صرف اندرونی طور پر رسائی حاصل کی جا سکتی ہے (یعنی موجودہ کنٹریکٹ کے اندر سے یا اس سے ماخوذ کنٹریکٹس سے) +- `external` – یہ EVM کال بناتے ہیں + - ایکسٹرنل فنکشنز کنٹریکٹ انٹرفیس کا حصہ ہیں، جس کا مطلب ہے کہ انہیں دوسرے کنٹریکٹس سے اور ٹرانزیکشنز کے ذریعے کال کیا جا سکتا ہے۔ ایک بیرونی فنکشن `f` کو اندرونی طور پر کال نہیں کیا جا سکتا (یعنی، `f()` کام نہیں کرتا، لیکن `this.f()` کام کرتا ہے)۔ + +وہ `public` یا `private` بھی ہو سکتے ہیں + +- `public` فنکشنز کو کنٹریکٹ کے اندر سے اندرونی طور پر یا پیغامات کے ذریعے بیرونی طور پر کال کیا جا سکتا ہے۔ +- `private` فنکشنز صرف اس کنٹریکٹ کے لیے نظر آتے ہیں جس میں ان کی تعریف کی گئی ہے اور ماخوذ کنٹریکٹس میں نہیں۔ + +فنکشنز اور اسٹیٹ متغیرات دونوں کو پبلک یا پرائیویٹ بنایا جا سکتا ہے۔ + +یہاں ایک کنٹریکٹ پر اسٹیٹ متغیر کو اپ ڈیٹ کرنے کے لیے ایک فنکشن ہے: + +```solidity +// Solidity کی مثال +function update_name(string value) public { + dapp_name = value; +} +``` + +- `string` ٹائپ کا پیرامیٹر `value` فنکشن میں پاس کیا جاتا ہے: `update_name` +- اسے `public` قرار دیا گیا ہے، یعنی کوئی بھی اس تک رسائی حاصل کر سکتا ہے +- اسے `view` قرار نہیں دیا گیا ہے، اس لیے یہ کنٹریکٹ اسٹیٹ میں ترمیم کر سکتا ہے + +### ویو فنکشنز {#view-functions} + +یہ فنکشنز کنٹریکٹ کے ڈیٹا کی اسٹیٹ میں ترمیم نہ کرنے کا وعدہ کرتے ہیں۔ عام مثالیں "گیٹر" فنکشنز ہیں – آپ اسے مثال کے طور پر صارف کا بیلنس حاصل کرنے کے لیے استعمال کر سکتے ہیں۔ + +```solidity +// Solidity کی مثال +function balanceOf(address _owner) public view returns (uint256 _balance) { + return ownerPizzaCount[_owner]; +} +``` + +```python +dappName: public(string) + +@view +@public +def readName() -> string: + return dappName +``` + +اسٹیٹ میں ترمیم کرنا کیا سمجھا جاتا ہے: + +1. اسٹیٹ متغیرات میں لکھنا۔ +2. [ایونٹس کا اخراج](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events)۔ +3. [دوسرے کنٹریکٹس بنانا](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts)۔ +4. `selfdestruct` کا استعمال۔ +5. کالز کے ذریعے ایتھر بھیجنا۔ +6. کسی بھی ایسے فنکشن کو کال کرنا جس پر `view` یا `pure` کا نشان نہ ہو۔ +7. نچلی سطح کی کالز کا استعمال۔ +8. ان لائن اسمبلی کا استعمال جس میں کچھ آپ کوڈز ہوں۔ + +### کنسٹرکٹر فنکشنز {#constructor-functions} + +`constructor` فنکشنز صرف ایک بار عمل میں آتے ہیں جب کنٹریکٹ پہلی بار تعینات ہوتا ہے۔ بہت سی کلاس پر مبنی پروگرامنگ زبانوں میں `constructor` کی طرح، یہ فنکشنز اکثر اسٹیٹ متغیرات کو ان کی مخصوص قدروں پر شروع کرتے ہیں۔ + +```solidity +// Solidity کی مثال +// کنٹریکٹ کے ڈیٹا کو شروع کرتا ہے، `owner` کو +// کنٹریکٹ بنانے والے کے ایڈریس پر سیٹ کرتا ہے۔ +constructor() public { + // تمام اسمارٹ کنٹریکٹس اپنے فنکشنز کو ٹرگر کرنے کے لیے بیرونی ٹرانزیکشنز پر انحصار کرتے ہیں۔ + // `msg` ایک عالمی متغیر ہے جس میں دیے گئے ٹرانزیکشن پر متعلقہ ڈیٹا شامل ہے، + // جیسے بھیجنے والے کا ایڈریس اور ٹرانزیکشن میں شامل ETH کی قدر۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + owner = msg.sender; +} +``` + +```python +# Vyper کی مثال + +@external +def __init__(_beneficiary: address, _bidding_time: uint256): + self.beneficiary = _beneficiary + self.auctionStart = block.timestamp + self.auctionEnd = self.auctionStart + _bidding_time +``` + +### بلٹ ان فنکشنز {#built-in-functions} + +آپ کے کنٹریکٹ پر آپ کے ذریعے بیان کردہ متغیرات اور فنکشنز کے علاوہ، کچھ خاص بلٹ ان فنکشنز بھی ہیں۔ سب سے واضح مثال ہے: + +- `address.send()` – Solidity +- `send(address)` – Vyper + +یہ کنٹریکٹس کو دوسرے اکاؤنٹس میں ETH بھیجنے کی اجازت دیتے ہیں۔ + +## فنکشنز لکھنا {#writing-functions} + +آپ کے فنکشن کو ضرورت ہے: + +- پیرامیٹر متغیر اور ٹائپ (اگر یہ پیرامیٹرز قبول کرتا ہے) +- اندرونی/بیرونی کا اعلان +- pure/view/payable کا اعلان +- ریٹرنز ٹائپ (اگر یہ قدر واپس کرتا ہے) + +```solidity +pragma solidity >=0.4.0 <=0.6.0; + +contract ExampleDapp { + string dapp_name; // اسٹیٹ متغیر + + // جب کنٹریکٹ تعینات ہوتا ہے تو کال کیا جاتا ہے اور قدر کو شروع کرتا ہے + constructor() public { + dapp_name = "My Example dapp"; + } + + // فنکشن حاصل کریں + function read_name() public view returns(string) { + return dapp_name; + } + + // فنکشن سیٹ کریں + function update_name(string value) public { + dapp_name = value; + } +} +``` + +ایک مکمل کنٹریکٹ کچھ اس طرح نظر آ سکتا ہے۔ یہاں `constructor` فنکشن `dapp_name` متغیر کے لیے ایک ابتدائی قدر فراہم کرتا ہے۔ + +## ایونٹس اور لاگز {#events-and-logs} + +ایونٹس آپ کے اسمارٹ کنٹریکٹ کو آپ کے فرنٹ اینڈ یا دیگر سبسکرائب کرنے والی ایپلی کیشنز کے ساتھ بات چیت کرنے کے قابل بناتے ہیں۔ ایک بار جب ٹرانزیکشن کی توثیق ہو جاتی ہے اور اسے بلاک میں شامل کر دیا جاتا ہے، تو اسمارٹ کنٹریکٹس ایونٹس خارج کر سکتے ہیں اور معلومات لاگ کر سکتے ہیں، جسے فرنٹ اینڈ پھر پراسیس اور استعمال کر سکتا ہے۔ + +## تشریح شدہ مثالیں {#annotated-examples} + +یہ Solidity میں لکھی گئی کچھ مثالیں ہیں۔ اگر آپ کوڈ کے ساتھ کھیلنا چاہتے ہیں، تو آپ [Remix](http://remix.ethereum.org) میں ان کے ساتھ بات چیت کر سکتے ہیں۔ + +### ہیلو ورلڈ {#hello-world} + +```solidity +// سیمنٹک ورژننگ کا استعمال کرتے ہوئے، Solidity کا ورژن بیان کرتا ہے۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +pragma solidity ^0.5.10; + +// `HelloWorld` نامی ایک کنٹریکٹ کی تعریف کرتا ہے۔ +// ایک کنٹریکٹ فنکشنز اور ڈیٹا (اس کی اسٹیٹ) کا مجموعہ ہوتا ہے۔ +// ایک بار تعینات ہونے کے بعد، ایک کنٹریکٹ Ethereum بلاک چین پر ایک مخصوص ایڈریس پر رہتا ہے۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +contract HelloWorld { + + // `string` ٹائپ کا ایک اسٹیٹ متغیر `message` کا اعلان کرتا ہے۔ + // اسٹیٹ متغیرات وہ متغیرات ہیں جن کی قدریں مستقل طور پر کنٹریکٹ اسٹوریج میں محفوظ کی جاتی ہیں۔ + // کلیدی لفظ `public` متغیرات کو کنٹریکٹ کے باہر سے قابل رسائی بناتا ہے + // اور ایک ایسا فنکشن بناتا ہے جسے دوسرے کنٹریکٹس یا کلائنٹس قدر تک رسائی کے لیے کال کر سکتے ہیں۔ + string public message; + + // بہت سی کلاس پر مبنی آبجیکٹ اورینٹڈ زبانوں کی طرح، ایک کنسٹرکٹر + // ایک خاص فنکشن ہے جو صرف کنٹریکٹ کی تخلیق پر عمل میں آتا ہے۔ + // کنسٹرکٹرز کنٹریکٹ کے ڈیٹا کو شروع کرنے کے لیے استعمال ہوتے ہیں۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + constructor(string memory initMessage) public { + // ایک سٹرنگ آرگومنٹ `initMessage` کو قبول کرتا ہے اور قدر کو + // کنٹریکٹ کے `message` اسٹوریج متغیر میں سیٹ کرتا ہے)۔ + message = initMessage; + } + + // ایک پبلک فنکشن جو ایک سٹرنگ آرگومنٹ قبول کرتا ہے + // اور `message` اسٹوریج متغیر کو اپ ڈیٹ کرتا ہے۔ + function update(string memory newMessage) public { + message = newMessage; + } +} +``` + +### ٹوکن {#token} + +```solidity +pragma solidity ^0.5.10; + +contract Token { + // ایک `address` ای میل ایڈریس کے مترادف ہے - یہ Ethereum پر ایک اکاؤنٹ کی شناخت کے لیے استعمال ہوتا ہے۔ + // ایڈریس ایک اسمارٹ کنٹریکٹ یا بیرونی (صارف) اکاؤنٹس کی نمائندگی کر سکتے ہیں۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/types.html#address + address public owner; + + // ایک `mapping` بنیادی طور پر ایک ہیش ٹیبل ڈیٹا اسٹرکچر ہے۔ + // یہ `mapping` ایک غیر دستخط شدہ انٹیجر (ٹوکن بیلنس) کو ایک ایڈریس (ٹوکن ہولڈر) کو تفویض کرتا ہے۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types + mapping (address => uint) public balances; + + // ایونٹس بلاک چین پر سرگرمی کی لاگنگ کی اجازت دیتے ہیں۔ + // Ethereum کلائنٹس کنٹریکٹ اسٹیٹ کی تبدیلیوں پر ردعمل ظاہر کرنے کے لیے ایونٹس سن سکتے ہیں۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events + event Transfer(address from, address to, uint amount); + + // کنٹریکٹ کے ڈیٹا کو شروع کرتا ہے، `owner` کو + // کنٹریکٹ بنانے والے کے ایڈریس پر سیٹ کرتا ہے۔ + constructor() public { + // تمام اسمارٹ کنٹریکٹس اپنے فنکشنز کو ٹرگر کرنے کے لیے بیرونی ٹرانزیکشنز پر انحصار کرتے ہیں۔ + // `msg` ایک عالمی متغیر ہے جس میں دیے گئے ٹرانزیکشن پر متعلقہ ڈیٹا شامل ہے، + // جیسے بھیجنے والے کا ایڈریس اور ٹرانزیکشن میں شامل ETH کی قدر۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + owner = msg.sender; + } + + // نئے ٹوکنز کی ایک مقدار بناتا ہے اور انہیں ایک ایڈریس پر بھیجتا ہے۔ + function mint(address receiver, uint amount) public { + // `require` ایک کنٹرول اسٹرکچر ہے جو کچھ شرائط کو نافذ کرنے کے لیے استعمال ہوتا ہے۔ + // اگر ایک `require` بیان `false` کا اندازہ لگاتا ہے، تو ایک استثنا ٹرگر ہوتا ہے، + // جو موجودہ کال کے دوران اسٹیٹ میں کی گئی تمام تبدیلیوں کو واپس کر دیتا ہے۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + + // صرف کنٹریکٹ کا مالک ہی اس فنکشن کو کال کر سکتا ہے + require(msg.sender == owner, "You are not the owner."); + + // ٹوکنز کی زیادہ سے زیادہ مقدار نافذ کرتا ہے + require(amount < 1e60, "Maximum issuance exceeded"); + + // `receiver` کے بیلنس کو `amount` سے بڑھاتا ہے + balances[receiver] += amount; + } + + // کسی بھی کال کرنے والے سے ایک ایڈریس پر موجودہ ٹوکنز کی ایک مقدار بھیجتا ہے۔ + function transfer(address receiver, uint amount) public { + // بھیجنے والے کے پاس بھیجنے کے لیے کافی ٹوکنز ہونے چاہئیں + require(amount <= balances[msg.sender], "Insufficient balance."); + + // دو ایڈریس کے ٹوکن بیلنس کو ایڈجسٹ کرتا ہے + balances[msg.sender] -= amount; + balances[receiver] += amount; + + // پہلے بیان کردہ ایونٹ کو خارج کرتا ہے + emit Transfer(msg.sender, receiver, amount); + } +} +``` + +### منفرد ڈیجیٹل اثاثہ {#unique-digital-asset} + +```solidity +pragma solidity ^0.5.10; + +// دیگر فائلوں سے علامتوں کو موجودہ کنٹریکٹ میں درآمد کرتا ہے۔ +// اس معاملے میں، OpenZeppelin سے مددگار کنٹریکٹس کا ایک سلسلہ۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files + +import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; +import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; +import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; +import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; + +// `is` کلیدی لفظ بیرونی کنٹریکٹس سے فنکشنز اور کلیدی الفاظ کو وراثت میں لینے کے لیے استعمال ہوتا ہے۔ +// اس معاملے میں، `CryptoPizza` `IERC721` اور `ERC165` کنٹریکٹس سے وراثت میں لیتا ہے۔ +// مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance +contract CryptoPizza is IERC721, ERC165 { + // حسابی کارروائیوں کو محفوظ طریقے سے انجام دینے کے لیے OpenZeppelin کی SafeMath لائبریری کا استعمال کرتا ہے۔ + // مزید جانیں: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + using SafeMath for uint256; + + // Solidity میں مستقل اسٹیٹ متغیرات دیگر زبانوں کی طرح ہیں + // لیکن آپ کو ایک ایسے اظہار سے تفویض کرنا چاہیے جو کمپائل وقت پر مستقل ہو۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables + uint256 constant dnaDigits = 10; + uint256 constant dnaModulus = 10 ** dnaDigits; + bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; + + // Struct ٹائپس آپ کو اپنی قسم کی تعریف کرنے دیتے ہیں + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs + struct Pizza { + string name; + uint256 dna; + } + + // Pizza structs کا ایک خالی سرنی بناتا ہے + Pizza[] public pizzas; + + // پیزا آئی ڈی سے اس کے مالک کے ایڈریس تک میپنگ + mapping(uint256 => address) public pizzaToOwner; + + // مالک کے ایڈریس سے ملکیت والے ٹوکن کی تعداد تک میپنگ + mapping(address => uint256) public ownerPizzaCount; + + // ٹوکن آئی ڈی سے منظور شدہ ایڈریس تک میپنگ + mapping(uint256 => address) pizzaApprovals; + + // آپ میپنگس کو نیسٹ کر سکتے ہیں، یہ مثال مالک کو آپریٹر کی منظوریوں سے میپ کرتی ہے + mapping(address => mapping(address => bool)) private operatorApprovals; + + // سٹرنگ (نام) اور DNA سے ایک بے ترتیب پیزا بنانے کے لیے اندرونی فنکشن + function _createPizza(string memory _name, uint256 _dna) + // `internal` کلیدی لفظ کا مطلب ہے کہ یہ فنکشن صرف + // اس کنٹریکٹ اور اس کنٹریکٹ سے ماخوذ کنٹریکٹس کے اندر نظر آتا ہے + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters + internal + // `isUnique` ایک فنکشن موڈیفائر ہے جو یہ چیک کرتا ہے کہ آیا پیزا پہلے سے موجود ہے + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers + isUnique(_name, _dna) + { + // پیزا کو پیزا کی سرنی میں شامل کرتا ہے اور آئی ڈی حاصل کرتا ہے + uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); + + // چیک کرتا ہے کہ پیزا کا مالک موجودہ صارف کے جیسا ہی ہے + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + + // نوٹ کریں کہ ایڈریس(0) صفر ایڈریس ہے، + // جو اس بات کی نشاندہی کرتا ہے کہ pizza[id] ابھی تک کسی خاص صارف کو مختص نہیں کیا گیا ہے۔ + + assert(pizzaToOwner[id] == address(0)); + + // پیزا کو مالک سے میپ کرتا ہے + pizzaToOwner[id] = msg.sender; + ownerPizzaCount[msg.sender] = SafeMath.add( + ownerPizzaCount[msg.sender], + 1 + ); + } + + // سٹرنگ (نام) سے ایک بے ترتیب پیزا بناتا ہے + function createRandomPizza(string memory _name) public { + uint256 randDna = generateRandomDna(_name, msg.sender); + _createPizza(_name, randDna); + } + + // سٹرنگ (نام) اور مالک (بنانے والے) کے ایڈریس سے بے ترتیب DNA بناتا ہے + function generateRandomDna(string memory _str, address _owner) + public + // `pure` کے طور پر نشان زد فنکشنز اسٹیٹ سے پڑھنے یا اس میں ترمیم نہ کرنے کا وعدہ کرتے ہیں + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions + pure + returns (uint256) + { + // سٹرنگ (نام) + ایڈریس (مالک) سے بے ترتیب uint بناتا ہے + uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + + uint256(_owner); + rand = rand % dnaModulus; + return rand; + } + + // مالک کے ذریعہ پائے گئے پیزا کی سرنی واپس کرتا ہے + function getPizzasByOwner(address _owner) + public + // `view` کے طور پر نشان زد فنکشنز اسٹیٹ میں ترمیم نہ کرنے کا وعدہ کرتے ہیں + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions + view + returns (uint256[] memory) + { + // صرف اس فنکشن کال کے لائف سائیکل کے لیے قدروں کو اسٹور کرنے کے لیے `memory` اسٹوریج مقام کا استعمال کرتا ہے۔ + // مزید جانیں: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack + uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); + uint256 counter = 0; + for (uint256 i = 0; i < pizzas.length; i++) { + if (pizzaToOwner[i] == _owner) { + result[counter] = i; + counter++; + } + } + return result; + } + + // پیزا اور ملکیت دوسرے ایڈریس پر منتقل کرتا ہے + function transferFrom(address _from, address _to, uint256 _pizzaId) public { + require(_from != address(0) && _to != address(0), "Invalid address."); + require(_exists(_pizzaId), "Pizza does not exist."); + require(_from != _to, "Cannot transfer to the same address."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + + ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1); + ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); + pizzaToOwner[_pizzaId] = _to; + + // درآمد شدہ IERC721 کنٹریکٹ میں بیان کردہ ایونٹ کو خارج کرتا ہے + emit Transfer(_from, _to, _pizzaId); + _clearApproval(_to, _pizzaId); + } + + /** + * دیے گئے ٹوکن آئی ڈی کی ملکیت کو محفوظ طریقے سے دوسرے ایڈریس پر منتقل کرتا ہے + * اگر ہدف ایڈریس ایک کنٹریکٹ ہے، تو اسے `onERC721Received` کو نافذ کرنا ہوگا، + * جسے ایک محفوظ منتقلی پر کال کیا جاتا ہے، اور جادوئی قدر واپس کرنا ہوگا + * `bytes4(keccak256(\"onERC721Received(address,address,uint256,bytes)\"))`؛ + * بصورت دیگر، منتقلی واپس کر دی جاتی ہے۔ + */ + function safeTransferFrom(address from, address to, uint256 pizzaId) + public + { + // solium-disable-next-line arg-overflow + this.safeTransferFrom(from, to, pizzaId, ""); + } + + /** + * دیے گئے ٹوکن آئی ڈی کی ملکیت کو محفوظ طریقے سے دوسرے ایڈریس پر منتقل کرتا ہے + * اگر ہدف ایڈریس ایک کنٹریکٹ ہے، تو اسے `onERC721Received` کو نافذ کرنا ہوگا، + * جسے ایک محفوظ منتقلی پر کال کیا جاتا ہے، اور جادوئی قدر واپس کرنا ہوگا + * `bytes4(keccak256(\"onERC721Received(address,address,uint256,bytes)\"))`؛ + * بصورت دیگر، منتقلی واپس کر دی جاتی ہے۔ + */ + function safeTransferFrom( + address from, + address to, + uint256 pizzaId, + bytes memory _data + ) public { + this.transferFrom(from, to, pizzaId); + require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received."); + } + + /** + * ہدف ایڈریس پر `onERC721Received` کو کال کرنے کے لیے اندرونی فنکشن + * کال اس وقت عمل میں نہیں آتی جب ہدف ایڈریس ایک کنٹریکٹ نہ ہو + */ + function _checkOnERC721Received( + address from, + address to, + uint256 pizzaId, + bytes memory _data + ) internal returns (bool) { + if (!isContract(to)) { + return true; + } + + bytes4 retval = IERC721Receiver(to).onERC721Received( + msg.sender, + from, + pizzaId, + _data + ); + return (retval == _ERC721_RECEIVED); + } + + // ایک پیزا کو جلاتا ہے - ٹوکن کو مکمل طور پر تباہ کرتا ہے + // `external` فنکشن موڈیفائر کا مطلب ہے کہ یہ فنکشن + // کنٹریکٹ انٹرفیس کا حصہ ہے اور دوسرے کنٹریکٹس اسے کال کر سکتے ہیں + function burn(uint256 _pizzaId) external { + require(msg.sender != address(0), "Invalid address."); + require(_exists(_pizzaId), "Pizza does not exist."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + + ownerPizzaCount[msg.sender] = SafeMath.sub( + ownerPizzaCount[msg.sender], + 1 + ); + pizzaToOwner[_pizzaId] = address(0); + } + + // ایڈریس کے لحاظ سے پیزا کی تعداد واپس کرتا ہے + function balanceOf(address _owner) public view returns (uint256 _balance) { + return ownerPizzaCount[_owner]; + } + + // آئی ڈی کے ذریعہ پائے گئے پیزا کا مالک واپس کرتا ہے + function ownerOf(uint256 _pizzaId) public view returns (address _owner) { + address owner = pizzaToOwner[_pizzaId]; + require(owner != address(0), "Invalid Pizza ID."); + return owner; + } + + // پیزا کی ملکیت منتقل کرنے کے لیے دوسرے ایڈریس کو منظور کرتا ہے + function approve(address _to, uint256 _pizzaId) public { + require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); + pizzaApprovals[_pizzaId] = _to; + emit Approval(msg.sender, _to, _pizzaId); + } + + // مخصوص پیزا کے لیے منظور شدہ ایڈریس واپس کرتا ہے + function getApproved(uint256 _pizzaId) + public + view + returns (address operator) + { + require(_exists(_pizzaId), "Pizza does not exist."); + return pizzaApprovals[_pizzaId]; + } + + /** + * دیے گئے ٹوکن آئی ڈی کی موجودہ منظوری کو صاف کرنے کے لیے نجی فنکشن + * اگر دیا گیا ایڈریس واقعی ٹوکن کا مالک نہیں ہے تو واپس کرتا ہے + */ + function _clearApproval(address owner, uint256 _pizzaId) private { + require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); + require(_exists(_pizzaId), "Pizza does not exist."); + if (pizzaApprovals[_pizzaId] != address(0)) { + pizzaApprovals[_pizzaId] = address(0); + } + } + + /* + * دیے گئے آپریٹر کی منظوری کو سیٹ یا ان سیٹ کرتا ہے + * ایک آپریٹر کو ان کی طرف سے بھیجنے والے کے تمام ٹوکنز منتقل کرنے کی اجازت ہے + */ + function setApprovalForAll(address to, bool approved) public { + require(to != msg.sender, "Cannot approve own address"); + operatorApprovals[msg.sender][to] = approved; + emit ApprovalForAll(msg.sender, to, approved); + } + + // بتاتا ہے کہ آیا کوئی آپریٹر دیے گئے مالک کے ذریعہ منظور شدہ ہے + function isApprovedForAll(address owner, address operator) + public + view + returns (bool) + { + return operatorApprovals[owner][operator]; + } + + // پیزا کی ملکیت لیتا ہے - صرف منظور شدہ صارفین کے لیے + function takeOwnership(uint256 _pizzaId) public { + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + address owner = this.ownerOf(_pizzaId); + this.transferFrom(owner, msg.sender, _pizzaId); + } + + // چیک کرتا ہے کہ آیا پیزا موجود ہے + function _exists(uint256 pizzaId) internal view returns (bool) { + address owner = pizzaToOwner[pizzaId]; + return owner != address(0); + } + + // چیک کرتا ہے کہ آیا ایڈریس مالک ہے یا پیزا منتقل کرنے کے لیے منظور شدہ ہے + function _isApprovedOrOwner(address spender, uint256 pizzaId) + internal + view + returns (bool) + { + address owner = pizzaToOwner[pizzaId]; + // Disable solium check because of + // https://github.com/duaraghav8/Solium/issues/175 + // solium-disable-next-line operator-whitespace + return (spender == owner || + this.getApproved(pizzaId) == spender || + this.isApprovedForAll(owner, spender)); + } + + // چیک کریں کہ آیا پیزا منفرد ہے اور ابھی تک موجود نہیں ہے + modifier isUnique(string memory _name, uint256 _dna) { + bool result = true; + for (uint256 i = 0; i < pizzas.length; i++) { + if ( + keccak256(abi.encodePacked(pizzas[i].name)) == + keccak256(abi.encodePacked(_name)) && + pizzas[i].dna == _dna + ) { + result = false; + } + } + require(result, "Pizza with such name already exists."); + _; + } + + // واپس کرتا ہے کہ آیا ہدف ایڈریس ایک کنٹریکٹ ہے + function isContract(address account) internal view returns (bool) { + uint256 size; + // فی الحال کسی ایڈریس میں کنٹریکٹ ہے یا نہیں یہ چیک کرنے کا اس سے بہتر کوئی طریقہ نہیں ہے + // کہ اس ایڈریس پر کوڈ کا سائز چیک کیا جائے۔ + // یہ کیسے کام کرتا ہے اس کے بارے میں مزید تفصیلات کے لیے https://ethereum.stackexchange.com/a/14016/36603 + // دیکھیں۔ + // TODO Serenity ریلیز سے پہلے اسے دوبارہ چیک کریں، کیونکہ تمام ایڈریس + // تب کنٹریکٹ ہوں گے۔ + // solium-disable-next-line security/no-inline-assembly + assembly { + size := extcodesize(account) + } + return size > 0; + } +} +``` + +## مزید پڑھیں {#further-reading} + +اسمارٹ کنٹریکٹس کے مزید مکمل جائزہ کے لیے Solidity اور Vyper کی دستاویزات دیکھیں۔ + +- [Solidity](https://docs.soliditylang.org/) +- [Vyper](https://docs.vyperlang.org/en/stable/) + +## متعلقہ موضوعات {#related-topics} + +- [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) +- [Ethereum ورچوئل مشین](/developers/docs/evm/) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [کنٹریکٹ سائز کی حد سے لڑنے کے لیے کنٹریکٹس کو چھوٹا کرنا](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– اپنے اسمارٹ کنٹریکٹ کا سائز کم کرنے کے لیے کچھ عملی نکات۔_ +- [ایونٹس کے ساتھ اسمارٹ کنٹریکٹس سے ڈیٹا لاگ کرنا](/developers/tutorials/logging-events-smart-contracts/) _– اسمارٹ کنٹریکٹ ایونٹس کا ایک تعارف اور آپ انہیں ڈیٹا لاگ کرنے کے لیے کیسے استعمال کر سکتے ہیں۔_ +- [Solidity سے دوسرے کنٹریکٹس کے ساتھ تعامل کریں](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– موجودہ کنٹریکٹ سے اسمارٹ کنٹریکٹ کو کیسے تعینات کریں اور اس کے ساتھ تعامل کریں۔_ diff --git a/public/content/translations/ur/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/ur/developers/docs/smart-contracts/compiling/index.md new file mode 100644 index 00000000000..62ad0895c12 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/compiling/index.md @@ -0,0 +1,282 @@ +--- +title: "اسمارٹ کنٹریکٹس کو کمپائل کرنا" +description: "یہ وضاحت کہ آپ کو اسمارٹ کنٹریکٹس کو کمپائل کرنے کی ضرورت کیوں ہے اور کمپائلیشن دراصل کیا کرتا ہے۔" +lang: ur-in +incomplete: true +--- + +آپ کو اپنے کنٹریکٹ کو کمپائل کرنے کی ضرورت ہے تاکہ آپ کی ویب ایپ اور Ethereum ورچوئل مشین (EVM) اسے سمجھ سکیں۔ + +## شرائط {#prerequisites} + +کمپائلیشن کے بارے میں پڑھنے سے پہلے آپ کو [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) اور [Ethereum ورچوئل مشین](/developers/docs/evm/) کے تعارف کو پڑھنا مفید معلوم ہو سکتا ہے۔ + +## EVM {#the-evm} + +[EVM](/developers/docs/evm/) کے لیے آپ کے کنٹریکٹ کو چلانے کے قابل ہونے کے لیے، اسے **بائٹ کوڈ** میں ہونا چاہیے۔ کمپائلیشن اسے اس میں بدل دیتا ہے: + +```solidity +pragma solidity 0.4.24; + +contract Greeter { + + function greet() public view returns (string memory) { + return "Hello"; + } + +} +``` + +**اس میں** + +``` +PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 +``` + +انہیں **آپ کوڈز** کہا جاتا ہے۔ EVM آپ کوڈز نچلی سطح کی ہدایات ہیں جنہیں Ethereum ورچوئل مشین (EVM) عمل میں لا سکتی ہے۔ ہر آپ کوڈ ایک مخصوص آپریشن کی نمائندگی کرتا ہے، جیسے کہ ریاضی کے آپریشنز، منطقی آپریشنز، ڈیٹا میں ہیرا پھیری، کنٹرول فلو، وغیرہ۔ + +[آپ کوڈز پر مزید](/developers/docs/evm/opcodes/) + +## ویب ایپلیکیشنز {#web-applications} + +کمپائلر **ایپلیکیشن بائنری انٹرفیس (ABI)** بھی تیار کرے گا جس کی آپ کو اپنی ایپلیکیشن کے لیے کنٹریکٹ کو سمجھنے اور کنٹریکٹ کے فنکشنز کو کال کرنے کے لیے ضرورت ہوتی ہے۔ + +ABI ایک JSON فائل ہے جو تعینات کردہ کنٹریکٹ اور اس کے اسمارٹ کنٹریکٹ فنکشنز کو بیان کرتی ہے۔ یہ ویب 2 اور ویب 3 کے درمیان فرق کو ختم کرنے میں مدد کرتا ہے + +ایک [JavaScript کلائنٹ لائبریری](/developers/docs/apis/javascript/) **ABI** کو پڑھے گی تاکہ آپ اپنی ویب ایپ کے انٹرفیس میں اپنے اسمارٹ کنٹریکٹ پر کال کر سکیں۔ + +ذیل میں ERC-20 ٹوکن کنٹریکٹ کے لیے ABI ہے۔ ایک ERC-20 ایک ٹوکن ہے جسے آپ Ethereum پر ٹریڈ کر سکتے ہیں۔ + +```json +[ + { + "constant": true, + "inputs": [], + "name": "name", + "outputs": [ + { + "name": "", + "type": "string" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": false, + "inputs": [ + { + "name": "_spender", + "type": "address" + }, + { + "name": "_value", + "type": "uint256" + } + ], + "name": "approve", + "outputs": [ + { + "name": "", + "type": "bool" + } + ], + "payable": false, + "stateMutability": "nonpayable", + "type": "function" + }, + { + "constant": true, + "inputs": [], + "name": "totalSupply", + "outputs": [ + { + "name": "", + "type": "uint256" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": false, + "inputs": [ + { + "name": "_from", + "type": "address" + }, + { + "name": "_to", + "type": "address" + }, + { + "name": "_value", + "type": "uint256" + } + ], + "name": "transferFrom", + "outputs": [ + { + "name": "", + "type": "bool" + } + ], + "payable": false, + "stateMutability": "nonpayable", + "type": "function" + }, + { + "constant": true, + "inputs": [], + "name": "decimals", + "outputs": [ + { + "name": "", + "type": "uint8" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": true, + "inputs": [ + { + "name": "_owner", + "type": "address" + } + ], + "name": "balanceOf", + "outputs": [ + { + "name": "balance", + "type": "uint256" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": true, + "inputs": [], + "name": "symbol", + "outputs": [ + { + "name": "", + "type": "string" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": false, + "inputs": [ + { + "name": "_to", + "type": "address" + }, + { + "name": "_value", + "type": "uint256" + } + ], + "name": "transfer", + "outputs": [ + { + "name": "", + "type": "bool" + } + ], + "payable": false, + "stateMutability": "nonpayable", + "type": "function" + }, + { + "constant": true, + "inputs": [ + { + "name": "_owner", + "type": "address" + }, + { + "name": "_spender", + "type": "address" + } + ], + "name": "allowance", + "outputs": [ + { + "name": "", + "type": "uint256" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "payable": true, + "stateMutability": "payable", + "type": "fallback" + }, + { + "anonymous": false, + "inputs": [ + { + "indexed": true, + "name": "owner", + "type": "address" + }, + { + "indexed": true, + "name": "spender", + "type": "address" + }, + { + "indexed": false, + "name": "value", + "type": "uint256" + } + ], + "name": "Approval", + "type": "event" + }, + { + "anonymous": false, + "inputs": [ + { + "indexed": true, + "name": "from", + "type": "address" + }, + { + "indexed": true, + "name": "to", + "type": "address" + }, + { + "indexed": false, + "name": "value", + "type": "uint256" + } + ], + "name": "Transfer", + "type": "event" + } +] +``` + +## مزید پڑھیں {#further-reading} + +- [ABI کی تفصیلات](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ + +## متعلقہ موضوعات {#related-topics} + +- [JavaScript کلائنٹ لائبریریز](/developers/docs/apis/javascript/) +- [Ethereum ورچوئل مشین](/developers/docs/evm/) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md b/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md new file mode 100644 index 00000000000..f065bc2236a --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md @@ -0,0 +1,76 @@ +--- +title: "اسمارٹ کنٹریکٹ کی ترکیب پذیری" +description: "جانیں کہ موجودہ اجزاء کا دوبارہ استعمال کرکے پیچیدہ dapps بنانے کے لیے اسمارٹ کنٹریکٹس کو لیگو بلاکس کی طرح کیسے جوڑا جا سکتا ہے۔" +lang: ur-in +incomplete: true +--- + +## ایک مختصر تعارف {#a-brief-introduction} + +اسمارٹ کنٹریکٹس Ethereum پر پبلک ہیں اور انہیں اوپن APIs کے طور پر سمجھا جا سکتا ہے۔ dapp ڈیولپر بننے کے لیے آپ کو اپنا اسمارٹ کنٹریکٹ لکھنے کی ضرورت نہیں ہے، آپ کو صرف یہ جاننے کی ضرورت ہے کہ ان کے ساتھ کیسے تعامل کیا جائے۔ مثال کے طور پر، آپ اپنی ایپ میں تمام ٹوکن سویپ منطق کو سنبھالنے کے لیے ایک وکندریقرت ایکسچینج، [Uniswap](https://uniswap.exchange/swap) کے موجودہ اسمارٹ کنٹریکٹس کا استعمال کر سکتے ہیں – آپ کو شروع سے شروع کرنے کی ضرورت نہیں ہے۔ ان کے کچھ [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) اور [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) کنٹریکٹس دیکھیں۔ + +## ترکیب پذیری کیا ہے؟ {#what-is-composability} + +ترکیب پذیری نئے نظام یا آؤٹ پٹ بنانے کے لیے الگ الگ اجزاء کو ملانا ہے۔ سافٹ ویئر ڈیولپمنٹ میں، ترکیب پذیری کا مطلب ہے کہ ڈیولپرز نئی ایپلی کیشنز بنانے کے لیے موجودہ سافٹ ویئر اجزاء کا دوبارہ استعمال کر سکتے ہیں۔ ترکیب پذیری کو سمجھنے کا ایک اچھا طریقہ یہ ہے کہ ترکیبی عناصر کو لیگو بلاکس کے طور پر سوچا جائے۔ ہر لیگو کو دوسرے کے ساتھ ملایا جا سکتا ہے، جس سے آپ مختلف لیگو کو ملا کر پیچیدہ ڈھانچے بنا سکتے ہیں۔ + +ایتھیریم میں، ہر اسمارٹ کنٹریکٹ ایک قسم کا لیگو ہے—آپ اپنے پروجیکٹ کے لیے بلڈنگ بلاکس کے طور پر دوسرے پروجیکٹس سے اسمارٹ کنٹریکٹس استعمال کر سکتے ہیں۔ اس کا مطلب ہے کہ آپ کو پہیے کو دوبارہ ایجاد کرنے یا شروع سے تعمیر کرنے میں وقت صرف کرنے کی ضرورت نہیں ہے۔ + +## ترکیب پذیری کیسے کام کرتی ہے؟ {#how-does-composability-work} + +ایتھیریم اسمارٹ کنٹریکٹس عوامی APIs کی طرح ہیں، لہذا کوئی بھی کنٹریکٹ کے ساتھ تعامل کر سکتا ہے یا اضافی فعالیت کے لیے انہیں dapps میں ضم کر سکتا ہے۔ اسمارٹ کنٹریکٹ کی ترکیب پذیری عام طور پر تین اصولوں پر کام کرتی ہے: ماڈیولریٹی، خود مختاری، اور دریافت پذیری: + +**1.** ماڈیولریٹی\*\*: یہ انفرادی اجزاء کی ایک مخصوص کام انجام دینے کی صلاحیت ہے۔ ایتھیریم میں، ہر اسمارٹ کنٹریکٹ کا ایک مخصوص استعمال کا معاملہ ہوتا ہے (جیسا کہ Uniswap کی مثال میں دکھایا گیا ہے)۔ + +**2.** خود مختاری\*\*: ترکیبی اجزاء کو آزادانہ طور پر کام کرنے کے قابل ہونا چاہیے۔ ایتھیریم میں ہر اسمارٹ کنٹریکٹ خود کار ہے اور نظام کے دوسرے حصوں پر انحصار کیے بغیر کام کر سکتا ہے۔ + +**3.** دریافت پذیری\*\*: ڈیولپرز بیرونی کنٹریکٹس کو کال نہیں کر سکتے یا سافٹ ویئر لائبریریوں کو ایپلی کیشنز میں ضم نہیں کر سکتے اگر سابقہ عوامی طور پر دستیاب نہ ہوں۔ ڈیزائن کے لحاظ سے، اسمارٹ کنٹریکٹس اوپن سورس ہیں؛ کوئی بھی اسمارٹ کنٹریکٹ کو کال کر سکتا ہے یا کوڈ بیس کو فورک کر سکتا ہے۔ + +## ترکیب پذیری کے فوائد {#benefits-of-composability} + +### مختصر ترقیاتی دور {#shorter-development-cycle} + +ترکیب پذیری اس کام کو کم کرتی ہے جو ڈیولپرز کو [dapps](/apps/#what-are-dapps) بناتے وقت کرنا پڑتا ہے۔ [جیسا کہ نیول رویکانت کہتے ہیں:](https://twitter.com/naval/status/1444366754650656770) "اوپن سورس کا مطلب ہے کہ ہر مسئلے کو ایک بار حل کرنا پڑتا ہے۔" + +اگر کوئی اسمارٹ کنٹریکٹ ہے جو ایک مسئلے کو حل کرتا ہے، تو دوسرے ڈیولپرز اسے دوبارہ استعمال کر سکتے ہیں، لہذا انہیں ایک ہی مسئلے کو حل کرنے کی ضرورت نہیں ہے۔ اس طرح، ڈیولپرز موجودہ سافٹ ویئر لائبریریوں کو لے سکتے ہیں اور نئے dapps بنانے کے لیے اضافی فعالیت شامل کر سکتے ہیں۔ + +### زیادہ جدت {#greater-innovation} + +ترکیب پذیری جدت اور تجربات کی حوصلہ افزائی کرتی ہے کیونکہ ڈیولپرز مطلوبہ نتائج پیدا کرنے کے لیے اوپن سورس کوڈ کو دوبارہ استعمال کرنے، اس میں ترمیم کرنے، نقل کرنے، یا ضم کرنے کے لیے آزاد ہیں۔ نتیجے کے طور پر، ترقیاتی ٹیمیں بنیادی فعالیت پر کم وقت صرف کرتی ہیں اور نئی خصوصیات کے ساتھ تجربات کرنے کے لیے زیادہ وقت مختص کر سکتی ہیں۔ + +### بہتر صارف کا تجربہ {#better-user-experience} + +ایتھیریم ایکو سسٹم کے اجزاء کے درمیان بین عملیت صارف کے تجربے کو بہتر بناتی ہے۔ صارفین زیادہ فعالیت تک رسائی حاصل کر سکتے ہیں جب dapps بیرونی اسمارٹ کنٹریکٹس کو مربوط کرتے ہیں بجائے اس کے کہ ایک بکھرے ہوئے ایکو سسٹم میں جہاں ایپلی کیشنز آپس میں بات چیت نہیں کر سکتیں۔ + +ہم بین عملیت کے فوائد کو واضح کرنے کے لیے ثالثی ٹریڈنگ سے ایک مثال استعمال کریں گے: + +اگر کوئی ٹوکن `ایکسچینج A` پر `ایکسچینج B` سے زیادہ ٹریڈ ہو رہا ہے، تو آپ منافع کمانے کے لیے قیمت کے فرق سے فائدہ اٹھا سکتے ہیں۔ تاہم، آپ ایسا صرف اسی صورت میں کر سکتے ہیں جب آپ کے پاس ٹرانزیکشن کو فنڈ دینے کے لیے کافی سرمایہ ہو (یعنی `ایکسچینج B` سے ٹوکن خریدنا اور اسے `ایکسچینج A` پر بیچنا)۔ + +ایسی صورت حال میں جہاں آپ کے پاس تجارت کو پورا کرنے کے لیے کافی فنڈز نہیں ہیں، فلیش لون مثالی ہو سکتا ہے۔ [فلیش لونز](/defi/#flash-loans) انتہائی تکنیکی ہیں، لیکن بنیادی خیال یہ ہے کہ آپ اثاثے (بغیر ضمانت کے) ادھار لے سکتے ہیں اور _ایک_ ٹرانزیکشن کے اندر واپس کر سکتے ہیں۔ + +ہماری ابتدائی مثال پر واپس جائیں تو، ایک ثالثی تاجر ایک بڑا فلیش لون لے سکتا ہے، `ایکسچینج B` سے ٹوکن خرید سکتا ہے، انہیں `ایکسچینج A` پر بیچ سکتا ہے، سرمایہ + سود واپس کر سکتا ہے، اور اسی ٹرانزیکشن کے اندر منافع رکھ سکتا ہے۔ اس پیچیدہ منطق کے لیے متعدد کنٹریکٹس پر کالوں کو یکجا کرنے کی ضرورت ہوتی ہے، جو ممکن نہ ہوتا اگر اسمارٹ کنٹریکٹس میں بین عملیت کی کمی ہوتی۔ + +## ایتھیریم میں ترکیب پذیری کی مثالیں {#composability-in-ethereum} + +### ٹوکن سویپس {#token-swaps} + +اگر آپ کوئی ایسا dapp بناتے ہیں جس میں ETH میں ادائیگی کی ضرورت ہوتی ہے، تو آپ ٹوکن سویپ منطق کو ضم کرکے صارفین کو دوسرے ERC-20 ٹوکنز میں ادائیگی کرنے کی اجازت دے سکتے ہیں۔ کنٹریکٹ کے ذریعے کال کیے گئے فنکشن کو انجام دینے سے پہلے کوڈ خود بخود صارف کے ٹوکن کو ETH میں تبدیل کر دے گا۔ + +### حکمرانی {#governance} + +[DAO](/dao/) کے لیے مخصوص حکمرانی کے نظام بنانا مہنگا اور وقت طلب ہو سکتا ہے۔ اس کے بجائے، آپ اپنے DAO کو بوٹسٹریپ کرنے کے لیے ایک اوپن سورس گورننس ٹول کٹ، جیسے [Aragon Client](https://client.aragon.org/) کا استعمال کر سکتے ہیں تاکہ فوری طور پر ایک گورننس فریم ورک بنایا جا سکے۔ + +### شناخت کا انتظام {#identity-management} + +ایک حسب ضرورت تصدیقی نظام بنانے یا مرکزی فراہم کنندگان پر انحصار کرنے کے بجائے، آپ صارفین کے لیے تصدیق کا انتظام کرنے کے لیے وکندریقرت شناختی (DID) ٹولز کو مربوط کر سکتے ہیں۔ ایک مثال [SpruceID](https://www.spruceid.com/) ہے، ایک اوپن سورس ٹول کٹ جو "ایتھیریم کے ساتھ سائن ان کریں" کی فعالیت پیش کرتی ہے جو صارفین کو ایتھیریم والیٹ کے ساتھ شناخت کی تصدیق کرنے دیتی ہے۔ + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [create-eth-app کے ساتھ اپنے dapp فرنٹ اینڈ ڈیولپمنٹ کو کک اسٹارٹ کریں](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– اس بات کا ایک جائزہ کہ مقبول اسمارٹ کنٹریکٹس کے ساتھ ایپس بنانے کے لیے create-eth-app کا استعمال کیسے کریں۔_ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +- [ترکیب پذیری جدت ہے](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) +- [Web3 کے لیے ترکیب پذیری کیوں اہم ہے](https://hackernoon.com/why-composability-matters-for-web3) +- [ترکیب پذیری کیا ہے؟](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/ur/developers/docs/smart-contracts/deploying/index.md new file mode 100644 index 00000000000..6eb26aae8fd --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/deploying/index.md @@ -0,0 +1,81 @@ +--- +title: "اسمارٹ کنٹریکٹس کی تعیناتی" +description: "ایتھریم نیٹ ورکس پر اسمارٹ کنٹریکٹس کو تعینات کرنے کا طریقہ سیکھیں، جس میں شرائط، ٹولز، اور تعیناتی کے مراحل شامل ہیں۔" +lang: ur-in +--- + +آپ کو اپنے اسمارٹ کنٹریکٹ کو تعینات کرنے کی ضرورت ہے تاکہ یہ ایتھریم نیٹ ورک کے صارفین کے لیے دستیاب ہو سکے۔ + +اسمارٹ کنٹریکٹ کو تعینات کرنے کے لیے، آپ صرف ایک ایتھریم ٹرانزیکشن بھیجتے ہیں جس میں اسمارٹ کنٹریکٹ کا کمپائل شدہ کوڈ شامل ہوتا ہے، بغیر کسی وصول کنندہ کی وضاحت کیے۔ + +## شرائط {#prerequisites} + +اسمارٹ کنٹریکٹس کو تعینات کرنے سے پہلے آپ کو [ایتھریم نیٹ ورکس](/developers/docs/networks/)، [ٹرانزیکشنز](/developers/docs/transactions/) اور [اسمارٹ کنٹریکٹس کی اناٹومی](/developers/docs/smart-contracts/anatomy/) کو سمجھنا چاہیے۔ + +کنٹریکٹ کی تعیناتی میں ایتھر (ETH) بھی خرچ ہوتا ہے کیونکہ وہ بلاک چین پر محفوظ ہوتے ہیں، لہذا آپ کو ایتھریم پر [گیس اور فیس](/developers/docs/gas/) سے واقف ہونا چاہیے۔ + +آخر میں، آپ کو اپنے کنٹریکٹ کو تعینات کرنے سے پہلے اسے کمپائل کرنے کی ضرورت ہوگی، لہذا یقینی بنائیں کہ آپ نے [اسمارٹ کنٹریکٹس کی کمپائلنگ](/developers/docs/smart-contracts/compiling/) کے بارے میں پڑھا ہے۔ + +## اسمارٹ کنٹریکٹ کو کیسے تعینات کریں {#how-to-deploy-a-smart-contract} + +### آپ کو کن چیزوں کی ضرورت ہوگی {#what-youll-need} + +- آپ کے کنٹریکٹ کا بائٹ کوڈ – یہ [کمپائلیشن](/developers/docs/smart-contracts/compiling/) کے ذریعے تیار کیا جاتا ہے +- گیس کے لیے ETH – آپ دیگر ٹرانزیکشنز کی طرح اپنی گیس کی حد مقرر کریں گے، لہذا آگاہ رہیں کہ کنٹریکٹ کی تعیناتی میں ایک سادہ ETH ٹرانسفر کے مقابلے بہت زیادہ گیس کی ضرورت ہوتی ہے۔ +- ایک تعیناتی اسکرپٹ یا پلگ ان +- [ایتھریم نوڈ](/developers/docs/nodes-and-clients/) تک رسائی، یا تو اپنا خود چلا کر، عوامی نوڈ سے جڑ کر، یا [نوڈ سروس](/developers/docs/nodes-and-clients/nodes-as-a-service/) کا استعمال کرتے ہوئے API کلید کے ذریعے۔ + +### اسمارٹ کنٹریکٹ تعینات کرنے کے مراحل {#steps-to-deploy} + +شامل مخصوص مراحل زیر بحث ڈیولپمنٹ فریم ورک پر منحصر ہوں گے۔ مثال کے طور پر، آپ [اپنے کنٹریکٹس کو تعینات کرنے سے متعلق Hardhat کی دستاویزات](https://hardhat.org/docs/tutorial/deploying) یا [اسمارٹ کنٹریکٹ کو تعینات کرنے اور اس کی تصدیق کرنے سے متعلق Foundry کی دستاویزات](https://book.getfoundry.sh/forge/deploying) دیکھ سکتے ہیں۔ ایک بار تعینات ہونے کے بعد، آپ کے کنٹریکٹ کا دیگر [اکاؤنٹس](/developers/docs/accounts/) کی طرح ایک ایتھریم پتہ ہوگا اور اس کی تصدیق [سورس کوڈ کی تصدیق کے ٹولز](/developers/docs/smart-contracts/verifying/#source-code-verification-tools) کا استعمال کرکے کی جاسکتی ہے۔ + +## متعلقہ ٹولز {#related-tools} + +**Remix - _Remix IDE ایتھریم جیسے بلاک چینز کے لیے اسمارٹ کنٹریکٹس کو ڈیولپ کرنے، تعینات کرنے اور ان کا انتظام کرنے کی اجازت دیتا ہے_** + +- [Remix](https://remix.ethereum.org) + +**Tenderly - _Web3 ڈیولپمنٹ پلیٹ فارم جو اسمارٹ کنٹریکٹس کو ڈیولپ کرنے، ٹیسٹ کرنے، مانیٹر کرنے اور چلانے کے لیے ڈیبگنگ، آبزرویبلٹی اور انفراسٹرکچر بلڈنگ بلاکس فراہم کرتا ہے_** + +- [tenderly.co](https://tenderly.co/) +- [دستاویزات](https://docs.tenderly.co/) +- [GitHub](https://github.com/Tenderly) +- [Discord](https://discord.gg/eCWjuvt) + +**Hardhat - _آپ کے ایتھریم سافٹ ویئر کو کمپائل کرنے، تعینات کرنے، ٹیسٹ کرنے اور ڈیبگ کرنے کا ایک ڈیولپمنٹ ماحول_** + +- [hardhat.org](https://hardhat.org/getting-started/) +- [اپنے کنٹریکٹس کو تعینات کرنے سے متعلق دستاویزات](https://hardhat.org/docs/tutorial/deploying) +- [GitHub](https://github.com/nomiclabs/hardhat) +- [Discord](https://discord.com/invite/TETZs2KK4k) + +**thirdweb - _ایک ہی کمانڈ کا استعمال کرکے کسی بھی EVM ہم آہنگ چین پر کسی بھی کنٹریکٹ کو آسانی سے تعینات کریں_** + +- [دستاویزات](https://portal.thirdweb.com/deploy/) + +**Crossmint - _اسمارٹ کنٹریکٹس کو تعینات کرنے، کریڈٹ کارڈ اور کراس چین ادائیگیوں کو فعال کرنے، اور NFTs بنانے, تقسیم کرنے, بیچنے, اسٹور کرنے اور ان میں ترمیم کرنے کے لیے APIs کا استعمال کرنے کا انٹرپرائز-گریڈ web3 ڈیولپمنٹ پلیٹ فارم۔_** + +- [crossmint.com](https://www.crossmint.com) +- [ڈاکومینٹیشن](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) +- [بلاگ](https://blog.crossmint.com) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [اپنا پہلا اسمارٹ کنٹریکٹ تعینات کرنا](/developers/tutorials/deploying-your-first-smart-contract/) _– ایتھریم ٹیسٹ نیٹ ورک پر اپنا پہلا اسمارٹ کنٹریکٹ تعینات کرنے کا تعارف۔_ +- [ہیلو ورلڈ | اسمارٹ کنٹریکٹ ٹیوٹوریل](/developers/tutorials/hello-world-smart-contract/) _– ایتھریم پر ایک بنیادی اسمارٹ کنٹریکٹ بنانے اور اسے تعینات کرنے کا ایک آسان ٹیوٹوریل۔_ +- [Solidity سے دوسرے کنٹریکٹس کے ساتھ تعامل کریں](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– موجودہ کنٹریکٹ سے اسمارٹ کنٹریکٹ کو کیسے تعینات کریں اور اس کے ساتھ تعامل کریں۔_ +- [اپنے کنٹریکٹ کا سائز کیسے گھٹائیں](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _- اپنے کنٹریکٹ کا سائز کیسے گھٹائیں تاکہ اسے حد کے اندر رکھا جا سکے اور گیس کی بچت کی جا سکے_ + +## مزید پڑھیں {#further-reading} + +- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) - _OpenZeppelin_ +- [Hardhat کے ساتھ اپنے کنٹریکٹس کی تعیناتی](https://hardhat.org/docs/tutorial/deploying) - _Nomic Labs_ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) +- [ایک ایتھریم نوڈ چلائیں](/developers/docs/nodes-and-clients/run-a-node/) +- [نوڈز-بطور-سروس](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/ur/developers/docs/smart-contracts/formal-verification/index.md new file mode 100644 index 00000000000..598e05d1993 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/formal-verification/index.md @@ -0,0 +1,284 @@ +--- +title: "اسمارٹ کنٹریکٹس کی باضابطہ تصدیق" +description: "ایتھریم اسمارٹ کنٹریکٹس کے لئے باضابطہ تصدیق کا ایک جائزہ" +lang: ur-in +--- + +[اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) غیر مرکزی، بھروسے کے بغیر، اور مضبوط ایپلیکیشنز بنانا ممکن بنا رہے ہیں جو صارفین کے لئے نئے استعمال کے معاملات متعارف کراتے ہیں اور قدر کو غیر مقفل کرتے ہیں۔ چونکہ اسمارٹ کنٹریکٹس بڑی مقدار میں قدر کو سنبھالتے ہیں، سیکیورٹی ڈیولپرز کے لیے ایک اہم غور و فکر ہے۔ + +باضابطہ تصدیق [اسمارٹ کنٹریکٹ سیکیورٹی](/developers/docs/smart-contracts/security/) کو بہتر بنانے کے لیے تجویز کردہ تکنیکوں میں سے ایک ہے۔ باضابطہ تصدیق، جو پروگراموں کی وضاحت، ڈیزائننگ اور تصدیق کے لیے [باضابطہ طریقے](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) استعمال کرتی ہے، سالوں سے اہم ہارڈویئر اور سافٹ ویئر سسٹمز کی درستگی کو یقینی بنانے کے لیے استعمال کی جا رہی ہے۔ + +جب اسمارٹ کنٹریکٹس میں لاگو کیا جاتا ہے، تو باضابطہ تصدیق یہ ثابت کر سکتی ہے کہ کنٹریکٹ کی کاروباری منطق پہلے سے طے شدہ تفصیلات پر پورا اترتی ہے۔ کنٹریکٹ کوڈ کی درستگی کا اندازہ لگانے کے دیگر طریقوں، جیسے ٹیسٹنگ، کے مقابلے میں، باضابطہ تصدیق مضبوط ضمانتیں دیتی ہے کہ ایک اسمارٹ کنٹریکٹ فعال طور پر درست ہے۔ + +## باضابطہ تصدیق کیا ہے؟ {#what-is-formal-verification} + +باضابطہ تصدیق اس عمل سے مراد ہے جس میں ایک سسٹم کی درستگی کا جائزہ ایک باضابطہ تفصیلات کے حوالے سے لیا جاتا ہے۔ آسان الفاظ میں، باضابطہ تصدیق ہمیں یہ جانچنے کی اجازت دیتی ہے کہ آیا کسی سسٹم کا رویہ کچھ تقاضوں کو پورا کرتا ہے (یعنی، یہ وہی کرتا ہے جو ہم چاہتے ہیں)۔ + +سسٹم کے متوقع رویے (اس معاملے میں ایک اسمارٹ کنٹریکٹ) باضابطہ ماڈلنگ کا استعمال کرتے ہوئے بیان کیے جاتے ہیں، جبکہ تفصیلات کی زبانیں باضابطہ خصوصیات کی تخلیق کو ممکن بناتی ہیں۔ باضابطہ تصدیق کی تکنیکیں پھر یہ تصدیق کر سکتی ہیں کہ کنٹریکٹ کا نفاذ اس کی تفصیلات کے مطابق ہے اور سابقہ کی درستگی کا ریاضیاتی ثبوت حاصل کر سکتی ہیں۔ جب کوئی کنٹریکٹ اپنی تفصیلات کو پورا کرتا ہے، تو اسے “فعال طور پر درست”، “ڈیزائن کے لحاظ سے درست”، یا “تعمیر کے لحاظ سے درست” کے طور پر بیان کیا جاتا ہے۔ + +### باضابطہ ماڈل کیا ہے؟ {#what-is-a-formal-model} + +کمپیوٹر سائنس میں، ایک [باضابطہ ماڈل](https://en.wikipedia.org/wiki/Model_of_computation) ایک حسابی عمل کی ریاضیاتی تفصیل ہے۔ پروگراموں کو ریاضیاتی افعال (مساوات) میں خلاصہ کیا جاتا ہے، جس میں ماڈل یہ بیان کرتا ہے کہ ان پٹ دیے جانے پر فنکشنز کے آؤٹ پٹ کا حساب کیسے لگایا جاتا ہے۔ + +باضابطہ ماڈل خلاصہ کی ایک سطح فراہم کرتے ہیں جس پر کسی پروگرام کے رویے کا تجزیہ کیا جا سکتا ہے۔ باضابطہ ماڈلز کا وجود ایک _باضابطہ تفصیلات_ کی تخلیق کی اجازت دیتا ہے، جو زیر بحث ماڈل کی مطلوبہ خصوصیات کو بیان کرتی ہے۔ + +باضابطہ تصدیق کے لیے اسمارٹ کنٹریکٹس کی ماڈلنگ کے لیے مختلف تکنیکیں استعمال کی جاتی ہیں۔ مثال کے طور پر، کچھ ماڈلز ایک اسمارٹ کنٹریکٹ کے اعلیٰ سطحی رویے کے بارے میں استدلال کرنے کے لیے استعمال ہوتے ہیں۔ یہ ماڈلنگ تکنیکیں اسمارٹ کنٹریکٹس پر بلیک باکس کا نظریہ لاگو کرتی ہیں، انہیں ایسے سسٹمز کے طور پر دیکھتی ہیں جو ان پٹ قبول کرتے ہیں اور ان ان پٹس کی بنیاد پر حساب کتاب کرتے ہیں۔ + +اعلیٰ سطحی ماڈلز اسمارٹ کنٹریکٹس اور بیرونی ایجنٹوں کے درمیان تعلق پر توجہ مرکوز کرتے ہیں، جیسے کہ بیرونی ملکیت والے اکاؤنٹس (EOAs)، کنٹریکٹ اکاؤنٹس، اور بلاک چین ماحول۔ ایسے ماڈل خصوصیات کی تعریف کے لیے مفید ہیں جو یہ بتاتی ہیں کہ کسی کنٹریکٹ کو کچھ صارف کے تعاملات کے جواب میں کیسا برتاؤ کرنا چاہیے۔ + +اس کے برعکس، دیگر باضابطہ ماڈل ایک اسمارٹ کنٹریکٹ کے نچلے درجے کے رویے پر توجہ مرکوز کرتے ہیں۔ اگرچہ اعلیٰ سطحی ماڈل کنٹریکٹ کی فعالیت کے بارے میں استدلال میں مدد کر سکتے ہیں، وہ نفاذ کے اندرونی کاموں کے بارے میں تفصیلات حاصل کرنے میں ناکام ہو سکتے ہیں۔ نچلے درجے کے ماڈل پروگرام کے تجزیے پر وائٹ باکس کا نظریہ لاگو کرتے ہیں اور اسمارٹ کنٹریکٹ ایپلیکیشنز کی نچلے درجے کی نمائندگیوں پر انحصار کرتے ہیں، جیسے پروگرام ٹریس اور [کنٹرول فلو گرافس](https://en.wikipedia.org/wiki/Control-flow_graph)، تاکہ کنٹریکٹ کے نفاذ سے متعلق خصوصیات کے بارے میں استدلال کیا جا سکے۔ + +نچلے درجے کے ماڈلز کو مثالی سمجھا جاتا ہے کیونکہ وہ ایتھریم کے ایگزیکیوشن ماحول (یعنی، [EVM](/developers/docs/evm/)) میں ایک اسمارٹ کنٹریکٹ کے اصل نفاذ کی نمائندگی کرتے ہیں۔ نچلے درجے کی ماڈلنگ تکنیکیں اسمارٹ کنٹریکٹس میں اہم حفاظتی خصوصیات قائم کرنے اور ممکنہ کمزوریوں کا پتہ لگانے میں خاص طور پر مفید ہیں۔ + +### باضابطہ تفصیلات کیا ہے؟ {#what-is-a-formal-specification} + +تفصیلات صرف ایک تکنیکی ضرورت ہے جسے ایک خاص سسٹم کو پورا کرنا ضروری ہے۔ پروگرامنگ میں، تفصیلات کسی پروگرام کے نفاذ کے بارے میں عمومی خیالات کی نمائندگی کرتی ہیں (یعنی، پروگرام کو کیا کرنا چاہیے)۔ + +اسمارٹ کنٹریکٹس کے تناظر میں، باضابطہ تفصیلات سے مراد _خصوصیات_ ہیں—ان ضروریات کی باضابطہ تفصیلات جنہیں کنٹریکٹ کو پورا کرنا ضروری ہے۔ ایسی خصوصیات کو "غیر متغیرات" کے طور پر بیان کیا جاتا ہے اور کنٹریکٹ کے نفاذ کے بارے میں منطقی دعووں کی نمائندگی کرتی ہیں جنہیں ہر ممکن صورت حال میں، بغیر کسی استثناء کے، سچ رہنا چاہیے۔ + +اس طرح، ہم باضابطہ تفصیلات کو ایک باضابطہ زبان میں لکھے گئے بیانات کے مجموعے کے طور پر سوچ سکتے ہیں جو ایک اسمارٹ کنٹریکٹ کے مطلوبہ نفاذ کو بیان کرتے ہیں۔ تفصیلات ایک کنٹریکٹ کی خصوصیات کا احاطہ کرتی ہیں اور یہ بتاتی ہیں کہ کنٹریکٹ کو مختلف حالات میں کیسا برتاؤ کرنا چاہیے۔ باضابطہ تصدیق کا مقصد یہ معلوم کرنا ہے کہ آیا ایک اسمارٹ کنٹریکٹ ان خصوصیات (غیر متغیرات) کا مالک ہے اور یہ کہ نفاذ کے دوران ان خصوصیات کی خلاف ورزی نہیں ہوتی ہے۔ + +اسمارٹ کنٹریکٹس کے محفوظ نفاذ کو تیار کرنے میں باضابطہ تفصیلات بہت اہم ہیں۔ وہ کنٹریکٹس جو غیر متغیرات کو نافذ کرنے میں ناکام رہتے ہیں یا جن کی خصوصیات کی نفاذ کے دوران خلاف ورزی ہوتی ہے، ان کمزوریوں کا شکار ہوتے ہیں جو فعالیت کو نقصان پہنچا سکتی ہیں یا بدنیتی پر مبنی استحصال کا سبب بن سکتی ہیں۔ + +## اسمارٹ کنٹریکٹس کے لئے باضابطہ تفصیلات کی اقسام {#formal-specifications-for-smart-contracts} + +باضابطہ تفصیلات پروگرام کے نفاذ کی درستگی کے بارے میں ریاضیاتی استدلال کو ممکن بناتی ہیں۔ باضابطہ ماڈلز کی طرح، باضابطہ تفصیلات یا تو اعلیٰ سطحی خصوصیات یا کنٹریکٹ کے نفاذ کے نچلے درجے کے رویے کو حاصل کر سکتی ہیں۔ + +باضابطہ تفصیلات [پروگرام منطق](https://en.wikipedia.org/wiki/Logic_programming) کے عناصر کا استعمال کرتے ہوئے حاصل کی جاتی ہیں، جو کسی پروگرام کی خصوصیات کے بارے میں باضابطہ استدلال کی اجازت دیتی ہیں۔ ایک پروگرام منطق کے باضابطہ اصول ہوتے ہیں جو کسی پروگرام کے متوقع رویے کو (ریاضیاتی زبان میں) ظاہر کرتے ہیں۔ باضابطہ تفصیلات بنانے میں مختلف پروگرام منطق استعمال کی جاتی ہیں، بشمول [ریچ ایبلٹی منطق](https://en.wikipedia.org/wiki/Reachability_problem)، [ٹیمپورل منطق](https://en.wikipedia.org/wiki/Temporal_logic)، اور [ہوئر منطق](https://en.wikipedia.org/wiki/Hoare_logic)۔ + +اسمارٹ کنٹریکٹس کے لئے باضابطہ تفصیلات کو وسیع پیمانے پر یا تو **اعلیٰ سطحی** یا **نچلے درجے کی** تفصیلات کے طور پر درجہ بندی کیا جا سکتا ہے۔ اس سے قطع نظر کہ تفصیلات کس زمرے سے تعلق رکھتی ہے، اسے تجزیہ کے تحت سسٹم کی خاصیت کو مناسب اور غیر مبہم طور پر بیان کرنا چاہیے۔ + +### اعلیٰ سطحی تفصیلات {#high-level-specifications} + +جیسا کہ نام سے ظاہر ہے، ایک اعلیٰ سطحی تفصیلات (جسے "ماڈل پر مبنی تفصیلات" بھی کہا جاتا ہے) ایک پروگرام کے اعلیٰ سطحی رویے کو بیان کرتی ہے۔ اعلیٰ سطحی تفصیلات ایک اسمارٹ کنٹریکٹ کو [فائنائٹ اسٹیٹ مشین](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM) کے طور پر ماڈل کرتی ہیں، جو آپریشنز انجام دے کر ریاستوں کے درمیان منتقل ہو سکتی ہے، جبکہ ٹیمپورل منطق کا استعمال FSM ماڈل کے لیے باضابطہ خصوصیات کی تعریف کے لیے کیا جاتا ہے۔ + +[ٹیمپورل منطق](https://en.wikipedia.org/wiki/Temporal_logic) "وقت کے لحاظ سے اہل تجاویز کے بارے میں استدلال کے اصول ہیں (مثلاً، "میں _ہمیشہ_ بھوکا رہتا ہوں" یا "میں _بالآخر_ بھوکا ہو جاؤں گا")۔" جب باضابطہ تصدیق پر لاگو کیا جاتا ہے، تو ٹیمپورل منطق کا استعمال اسٹیٹ مشینوں کے طور پر ماڈل کیے گئے سسٹمز کے صحیح رویے کے بارے میں دعوے کرنے کے لیے کیا جاتا ہے۔ خاص طور پر، ایک ٹیمپورل منطق مستقبل کی ان حالتوں کو بیان کرتی ہے جن میں ایک اسمارٹ کنٹریکٹ ہو سکتا ہے اور یہ کہ وہ حالتوں کے درمیان کیسے منتقل ہوتا ہے۔ + +اعلیٰ سطحی تفصیلات عام طور پر اسمارٹ کنٹریکٹس کے لیے دو اہم ٹیمپورل خصوصیات کو حاصل کرتی ہیں: **حفاظت** اور **لائیونیس**۔ حفاظتی خصوصیات اس خیال کی نمائندگی کرتی ہیں کہ "کچھ بھی برا کبھی نہیں ہوتا" اور عام طور پر غیر متغیر ہونے کا اظہار کرتی ہیں۔ ایک حفاظتی خصوصیت عمومی سافٹ ویئر کی ضروریات کی وضاحت کر سکتی ہے، جیسے [ڈیڈ لاک](https://www.techtarget.com/whatis/definition/deadlock) سے آزادی، یا کنٹریکٹس کے لیے ڈومین-مخصوص خصوصیات کا اظہار کر سکتی ہے (مثلاً، فنکشنز کے لیے رسائی کنٹرول پر غیر متغیر، ریاستی متغیرات کی قابل قبول قدریں، یا ٹوکن ٹرانسفر کے لیے شرائط)۔ + +مثال کے طور پر یہ حفاظتی ضرورت لیں جو ERC-20 ٹوکن کنٹریکٹس میں `transfer()` یا `transferFrom()` کے استعمال کے لیے شرائط کا احاطہ کرتی ہے: _"ایک بھیجنے والے کا بیلنس بھیجے جانے والے ٹوکنز کی درخواست کردہ رقم سے کبھی کم نہیں ہوتا ہے۔"_۔ کنٹریکٹ کے ایک غیر متغیر کی اس قدرتی زبان کی تفصیل کو ایک باضابطہ (ریاضیاتی) تفصیلات میں ترجمہ کیا جا سکتا ہے، جس کی پھر سختی سے درستگی کی جانچ کی جا سکتی ہے۔ + +لائیونیس خصوصیات اس بات پر زور دیتی ہیں کہ "کچھ اچھا بالآخر ہوتا ہے" اور کنٹریکٹ کی مختلف حالتوں میں ترقی کرنے کی صلاحیت سے متعلق ہیں۔ لائیونیس کی خاصیت کی ایک مثال "لیکویڈیٹی" ہے، جو ایک کنٹریکٹ کی درخواست پر صارفین کو اپنے بیلنس منتقل کرنے کی صلاحیت سے مراد ہے۔ اگر اس خاصیت کی خلاف ورزی کی جاتی ہے، تو صارف کنٹریکٹ میں محفوظ اثاثے واپس نہیں لے پائیں گے، جیسا کہ [پیریٹی والیٹ کے واقعے](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) میں ہوا تھا۔ + +### نچلے درجے کی تفصیلات {#low-level-specifications} + +اعلیٰ سطحی تفصیلات ایک کنٹریکٹ کے فائنائٹ-اسٹیٹ ماڈل کو نقطہ آغاز کے طور پر لیتی ہیں اور اس ماڈل کی مطلوبہ خصوصیات کی وضاحت کرتی ہیں۔ اس کے برعکس، نچلے درجے کی تفصیلات (جنہیں "پراپرٹی پر مبنی تفصیلات" بھی کہا جاتا ہے) اکثر پروگراموں (اسمارٹ کنٹریکٹس) کو ریاضیاتی افعال کے مجموعے پر مشتمل نظام کے طور پر ماڈل کرتی ہیں اور ایسے نظاموں کے صحیح رویے کو بیان کرتی ہیں۔ + +آسان الفاظ میں، نچلے درجے کی تفصیلات _پروگرام ٹریس_ کا تجزیہ کرتی ہیں اور ان ٹریسز پر ایک اسمارٹ کنٹریکٹ کی خصوصیات کی وضاحت کرنے کی کوشش کرتی ہیں۔ ٹریس سے مراد فنکشن کے نفاذ کی ترتیب ہے جو ایک اسمارٹ کنٹریکٹ کی حالت کو تبدیل کرتی ہے؛ لہذا، نچلے درجے کی تفصیلات کنٹریکٹ کے اندرونی نفاذ کے لیے ضروریات کی وضاحت میں مدد کرتی ہیں۔ + +نچلے درجے کی باضابطہ تفصیلات ہوئر-اسٹائل خصوصیات یا نفاذ کے راستوں پر غیر متغیرات کے طور پر دی جا سکتی ہیں۔ + +### ہوئر-اسٹائل خصوصیات {#hoare-style-properties} + +[ہوئر منطق](https://en.wikipedia.org/wiki/Hoare_logic) پروگراموں کی درستگی کے بارے میں استدلال کے لیے باضابطہ اصولوں کا ایک سیٹ فراہم کرتی ہے، بشمول اسمارٹ کنٹریکٹس۔ ایک ہوئر-اسٹائل خاصیت کو ہوئر ٹرپل `{P}c{Q}` سے ظاہر کیا جاتا ہے، جہاں `c` ایک پروگرام ہے اور `P` اور `Q` `c` (یعنی، پروگرام) کی حالت پر پیشین گوئیاں ہیں، جنہیں باضابطہ طور پر بالترتیب _پری کنڈیشنز_ اور _پوسٹ کنڈیشنز_ کے طور پر بیان کیا گیا ہے۔ + +ایک پری کنڈیشن ایک پیشین گوئی ہے جو کسی فنکشن کے صحیح نفاذ کے لیے درکار شرائط کو بیان کرتی ہے؛ کنٹریکٹ میں کال کرنے والے صارفین کو اس ضرورت کو پورا کرنا ضروری ہے۔ ایک پوسٹ کنڈیشن ایک پیشین گوئی ہے جو اس حالت کو بیان کرتی ہے جسے ایک فنکشن صحیح طریقے سے نافذ ہونے پر قائم کرتا ہے؛ صارفین فنکشن میں کال کرنے کے بعد اس حالت کے سچ ہونے کی توقع کر سکتے ہیں۔ ہوئر منطق میں ایک _غیر متغیر_ ایک پیشین گوئی ہے جو کسی فنکشن کے نفاذ سے محفوظ رہتی ہے (یعنی، یہ تبدیل نہیں ہوتی)۔ + +ہوئر-اسٹائل تفصیلات یا تو _جزوی درستگی_ یا _کل درستگی_ کی ضمانت دے سکتی ہیں۔ کنٹریکٹ فنکشن کا نفاذ "جزوی طور پر درست" ہے اگر فنکشن کے نافذ ہونے سے پہلے پری کنڈیشن سچ ثابت ہو، اور اگر نفاذ ختم ہو جائے تو پوسٹ کنڈیشن بھی سچ ہو۔ کل درستگی کا ثبوت اس وقت حاصل ہوتا ہے جب فنکشن کے نفاذ سے پہلے ایک پری کنڈیشن سچ ہو، نفاذ کے ختم ہونے کی ضمانت ہو اور جب ایسا ہوتا ہے تو پوسٹ کنڈیشن سچ ثابت ہوتی ہے۔ + +کل درستگی کا ثبوت حاصل کرنا مشکل ہے کیونکہ کچھ نفاذ ختم ہونے سے پہلے تاخیر کر سکتے ہیں، یا کبھی ختم ہی نہیں ہوتے۔ اس کے باوجود، یہ سوال کہ آیا نفاذ ختم ہوتا ہے، قابل بحث ہے کیونکہ ایتھریم کا گیس میکانزم لامحدود پروگرام لوپس کو روکتا ہے (نفاذ یا تو کامیابی سے ختم ہو جاتا ہے یا 'آؤٹ آف گیس' کی خرابی کی وجہ سے ختم ہو جاتا ہے)۔ + +ہوئر منطق کا استعمال کرتے ہوئے بنائی گئی اسمارٹ کنٹریکٹ کی تفصیلات میں ایک کنٹریکٹ میں فنکشنز اور لوپس کے نفاذ کے لیے پری کنڈیشنز، پوسٹ کنڈیشنز، اور غیر متغیرات کی تعریف کی جائے گی۔ پری کنڈیشنز میں اکثر کسی فنکشن میں غلط ان پٹ کا امکان شامل ہوتا ہے، جبکہ پوسٹ کنڈیشنز ایسے ان پٹس پر متوقع ردعمل کو بیان کرتی ہیں (مثلاً، ایک مخصوص استثناء پھینکنا)۔ اس طریقے سے ہوئر-اسٹائل خصوصیات کنٹریکٹ کے نفاذ کی درستگی کو یقینی بنانے میں مؤثر ہیں۔ + +بہت سے باضابطہ تصدیقی فریم ورک فنکشنز کی معنوی درستگی کو ثابت کرنے کے لیے ہوئر-اسٹائل تفصیلات کا استعمال کرتے ہیں۔ سولیڈیٹی میں `require` اور `assert` بیانات کا استعمال کرکے ہوئر-اسٹائل خصوصیات (بطور دعوے) کو براہ راست کنٹریکٹ کوڈ میں شامل کرنا بھی ممکن ہے۔ + +`require` بیانات ایک پری کنڈیشن یا غیر متغیر کا اظہار کرتے ہیں اور اکثر صارف کے ان پٹ کی توثیق کے لیے استعمال ہوتے ہیں، جبکہ `assert` حفاظت کے لیے ضروری ایک پوسٹ کنڈیشن کو حاصل کرتا ہے۔ مثال کے طور پر، فنکشنز کے لیے مناسب رسائی کنٹرول (حفاظتی خاصیت کی ایک مثال) کال کرنے والے اکاؤنٹ کی شناخت پر پری کنڈیشن چیک کے طور پر `require` کا استعمال کرکے حاصل کیا جا سکتا ہے۔ اسی طرح، ایک کنٹریکٹ میں ریاستی متغیرات کی قابل قبول قدروں پر ایک غیر متغیر (مثلاً، گردش میں ٹوکنز کی کل تعداد) کو `assert` کا استعمال کرکے خلاف ورزی سے بچایا جا سکتا ہے تاکہ فنکشن کے نفاذ کے بعد کنٹریکٹ کی حالت کی تصدیق کی جا سکے۔ + +### ٹریس-سطح کی خصوصیات {#trace-level-properties} + +ٹریس پر مبنی تفصیلات ان کارروائیوں کو بیان کرتی ہیں جو ایک کنٹریکٹ کو مختلف حالتوں کے درمیان منتقل کرتی ہیں اور ان کارروائیوں کے درمیان تعلقات کو۔ جیسا کہ پہلے وضاحت کی گئی ہے، ٹریس کارروائیوں کی ترتیب ہیں جو ایک کنٹریکٹ کی حالت کو ایک خاص طریقے سے تبدیل کرتی ہیں۔ + +یہ نقطہ نظر اسمارٹ کنٹریکٹس کے ماڈل پر انحصار کرتا ہے جو اسٹیٹ-ٹرانزیشن سسٹمز کے طور پر ہیں جن میں کچھ پہلے سے طے شدہ حالتیں ہیں (ریاستی متغیرات کے ذریعہ بیان کردہ) اور ساتھ ہی پہلے سے طے شدہ ٹرانزیشنز کا ایک سیٹ ہے (کنٹریکٹ فنکشنز کے ذریعہ بیان کردہ)۔ مزید برآں، ایک [کنٹرول فلو گراف](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG)، جو کسی پروگرام کے نفاذ کے بہاؤ کی ایک گرافیکل نمائندگی ہے، اکثر کنٹریکٹ کی آپریشنل سیمانٹکس کو بیان کرنے کے لیے استعمال ہوتا ہے۔ یہاں، ہر ٹریس کو کنٹرول فلو گراف پر ایک راستے کے طور پر ظاہر کیا جاتا ہے۔ + +بنیادی طور پر، ٹریس-سطح کی تفصیلات اسمارٹ کنٹریکٹس میں اندرونی نفاذ کے نمونوں کے بارے میں استدلال کرنے کے لیے استعمال ہوتی ہیں۔ ٹریس-سطح کی تفصیلات بنا کر، ہم ایک اسمارٹ کنٹریکٹ کے لیے قابل قبول نفاذ کے راستے (یعنی، ریاستی منتقلی) پر زور دیتے ہیں۔ علامتی نفاذ جیسی تکنیکوں کا استعمال کرتے ہوئے، ہم باضابطہ طور پر تصدیق کر سکتے ہیں کہ نفاذ کبھی بھی ایسے راستے پر نہیں چلتا جو باضابطہ ماڈل میں بیان نہیں کیا گیا ہے۔ + +آئیے ایک [DAO](/dao/) کنٹریکٹ کی مثال استعمال کرتے ہیں جس میں ٹریس-سطح کی خصوصیات کو بیان کرنے کے لیے کچھ عوامی طور پر قابل رسائی فنکشنز ہیں۔ یہاں، ہم فرض کرتے ہیں کہ DAO کنٹریکٹ صارفین کو درج ذیل کارروائیاں کرنے کی اجازت دیتا ہے: + +- فنڈز جمع کروائیں + +- فنڈز جمع کروانے کے بعد کسی تجویز پر ووٹ دیں + +- اگر وہ کسی تجویز پر ووٹ نہیں دیتے ہیں تو رقم کی واپسی کا دعویٰ کریں + +مثال کے طور پر ٹریس-سطح کی خصوصیات یہ ہو سکتی ہیں _"وہ صارفین جو فنڈز جمع نہیں کرواتے وہ کسی تجویز پر ووٹ نہیں دے سکتے"_ یا _"وہ صارفین جو کسی تجویز پر ووٹ نہیں دیتے انہیں ہمیشہ رقم کی واپسی کا دعویٰ کرنے کے قابل ہونا چاہئے"_۔ دونوں خصوصیات نفاذ کی ترجیحی ترتیبوں پر زور دیتی ہیں (ووٹنگ فنڈز جمع کروانے سے _پہلے_ نہیں ہو سکتی اور کسی تجویز پر ووٹ دینے کے _بعد_ رقم کی واپسی کا دعویٰ نہیں کیا جا سکتا)۔ + +## اسمارٹ کنٹریکٹس کی باضابطہ تصدیق کے لیے تکنیکیں {#formal-verification-techniques} + +### ماڈل چیکنگ {#model-checking} + +ماڈل چیکنگ ایک باضابطہ تصدیقی تکنیک ہے جس میں ایک الگورتھم ایک اسمارٹ کنٹریکٹ کے باضابطہ ماڈل کو اس کی تفصیلات کے خلاف چیک کرتا ہے۔ ماڈل چیکنگ میں اسمارٹ کنٹریکٹس کو اکثر اسٹیٹ-ٹرانزیشن سسٹمز کے طور پر ظاہر کیا جاتا ہے، جبکہ قابل اجازت کنٹریکٹ کی حالتوں پر خصوصیات کو ٹیمپورل منطق کا استعمال کرتے ہوئے بیان کیا جاتا ہے۔ + +ماڈل چیکنگ کے لیے ایک سسٹم (یعنی، ایک کنٹریکٹ) کی ایک خلاصہ ریاضیاتی نمائندگی بنانے کی ضرورت ہوتی ہے اور اس سسٹم کی خصوصیات کو [تجاویزی منطق](https://www.baeldung.com/cs/propositional-logic) پر مبنی فارمولوں کا استعمال کرتے ہوئے ظاہر کرنے کی ضرورت ہوتی ہے۔ یہ ماڈل چیکنگ الگورتھم کے کام کو آسان بناتا ہے، یعنی یہ ثابت کرنا کہ ایک ریاضیاتی ماڈل دیے گئے منطقی فارمولے کو پورا کرتا ہے۔ + +باضابطہ تصدیق میں ماڈل چیکنگ بنیادی طور پر ان وقتی خصوصیات کا جائزہ لینے کے لیے استعمال کی جاتی ہے جو وقت کے ساتھ ساتھ کنٹریکٹ کے رویے کو بیان کرتی ہیں۔ اسمارٹ کنٹریکٹس کے لیے وقتی خصوصیات میں _حفاظت_ اور _لائیونیس_ شامل ہیں، جن کی ہم نے پہلے وضاحت کی تھی۔ + +مثال کے طور پر، رسائی کنٹرول سے متعلق ایک حفاظتی خاصیت (مثلاً، _صرف کنٹریکٹ کا مالک ہی `selfdestruct` کو کال کر سکتا ہے_) کو باضابطہ منطق میں لکھا جا سکتا ہے۔ اس کے بعد، ماڈل چیکنگ الگورتھم یہ تصدیق کر سکتا ہے کہ آیا کنٹریکٹ اس باضابطہ تفصیلات کو پورا کرتا ہے۔ + +ماڈل چیکنگ اسٹیٹ اسپیس ایکسپلوریشن کا استعمال کرتی ہے، جس میں ایک اسمارٹ کنٹریکٹ کی تمام ممکنہ حالتوں کی تعمیر اور ان قابل رسائی حالتوں کو تلاش کرنے کی کوشش شامل ہے جو خاصیت کی خلاف ورزیوں کا باعث بنتی ہیں۔ تاہم، یہ لامحدود تعداد میں حالتوں کا باعث بن سکتا ہے (جسے "اسٹیٹ ایکسپلوژن پرابلم" کہا جاتا ہے)، اس لیے ماڈل چیکرز اسمارٹ کنٹریکٹس کے موثر تجزیے کو ممکن بنانے کے لیے خلاصہ تکنیکوں پر انحصار کرتے ہیں۔ + +### تھیورم کی تصدیق {#theorem-proving} + +تھیورم کی تصدیق پروگراموں، بشمول اسمارٹ کنٹریکٹس، کی درستگی کے بارے میں ریاضیاتی طور پر استدلال کرنے کا ایک طریقہ ہے۔ اس میں کنٹریکٹ کے سسٹم کے ماڈل اور اس کی تفصیلات کو ریاضیاتی فارمولوں (منطقی بیانات) میں تبدیل کرنا شامل ہے۔ + +تھیورم کی تصدیق کا مقصد ان بیانات کے درمیان منطقی مساوات کی تصدیق کرنا ہے۔ "منطقی مساوات" (جسے "منطقی دو طرفہ مضمرات" بھی کہا جاتا ہے) دو بیانات کے درمیان ایک قسم کا رشتہ ہے جس کے تحت پہلا بیان سچ ہوتا ہے _اگر اور صرف اگر_ دوسرا بیان سچ ہو۔ + +کنٹریکٹ کے ماڈل اور اس کی خاصیت کے بارے میں بیانات کے درمیان مطلوبہ رشتہ (منطقی مساوات) کو ایک قابل ثبوت بیان (جسے تھیورم کہا جاتا ہے) کے طور پر وضع کیا جاتا ہے۔ استدلال کے ایک باضابطہ نظام کا استعمال کرتے ہوئے، خودکار تھیورم پروور تھیورم کی صداقت کی تصدیق کر سکتا ہے۔ دوسرے الفاظ میں، ایک تھیورم پروور حتمی طور پر یہ ثابت کر سکتا ہے کہ ایک اسمارٹ کنٹریکٹ کا ماڈل اس کی تفصیلات سے بالکل میل کھاتا ہے۔ + +جبکہ ماڈل چیکنگ کنٹریکٹس کو محدود حالتوں کے ساتھ ٹرانزیشن سسٹم کے طور پر ماڈل کرتی ہے، تھیورم کی تصدیق لامحدود-حالت والے نظاموں کے تجزیے کو سنبھال سکتی ہے۔ تاہم، اس کا مطلب یہ ہے کہ ایک خودکار تھیورم پروور ہمیشہ یہ نہیں جان سکتا کہ آیا کوئی منطقی مسئلہ "فیصلہ کن" ہے یا نہیں۔ + +نتیجتاً، درستگی کے ثبوت حاصل کرنے میں تھیورم پروور کی رہنمائی کے لیے اکثر انسانی مدد کی ضرورت پڑتی ہے۔ تھیورم کی تصدیق میں انسانی کوششوں کا استعمال اسے ماڈل چیکنگ سے زیادہ مہنگا بناتا ہے، جو کہ مکمل طور پر خودکار ہے۔ + +### علامتی نفاذ {#symbolic-execution} + +علامتی نفاذ ایک اسمارٹ کنٹریکٹ کا تجزیہ کرنے کا ایک طریقہ ہے جس میں فنکشنز کو _ٹھوس اقدار_ (مثلاً، `x == 5`) کی بجائے _علامتی اقدار_ (مثلاً، `x > 5`) کا استعمال کرتے ہوئے نافذ کیا جاتا ہے۔ ایک باضابطہ تصدیقی تکنیک کے طور پر، علامتی نفاذ کا استعمال کنٹریکٹ کے کوڈ میں ٹریس-سطح کی خصوصیات کے بارے میں باضابطہ طور پر استدلال کرنے کے لیے کیا جاتا ہے۔ + +علامتی نفاذ ایک نفاذ کے ٹریس کو علامتی ان پٹ اقدار پر ایک ریاضیاتی فارمولے کے طور پر ظاہر کرتا ہے، جسے بصورت دیگر _پاتھ پریڈیکیٹ_ کہا جاتا ہے۔ ایک [SMT سالور](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) کا استعمال یہ جانچنے کے لیے کیا جاتا ہے کہ آیا کوئی پاتھ پریڈیکیٹ "اطمینان بخش" ہے (یعنی، کیا کوئی ایسی قدر موجود ہے جو فارمولے کو پورا کر سکتی ہے)۔ اگر ایک کمزور راستہ اطمینان بخش ہے، تو SMT سالور ایک ٹھوس قدر پیدا کرے گا جو نفاذ کو اس راستے کی طرف لے جاتا ہے۔ + +فرض کریں کہ ایک اسمارٹ کنٹریکٹ کا فنکشن ان پٹ کے طور پر ایک `uint` قدر (`x`) لیتا ہے اور جب `x` `5` سے زیادہ اور `10` سے کم ہو تو واپس ہو جاتا ہے۔ `x` کے لیے ایک ایسی قدر تلاش کرنے کے لیے جو خرابی کو متحرک کرتی ہو، ایک عام ٹیسٹنگ طریقہ کار کا استعمال کرتے ہوئے درجنوں ٹیسٹ کیسز (یا اس سے زیادہ) سے گزرنا پڑے گا بغیر اس یقین دہانی کے کہ واقعی خرابی کو متحرک کرنے والا ان پٹ مل جائے گا۔ + +اس کے برعکس، ایک علامتی نفاذ کا ٹول فنکشن کو علامتی قدر کے ساتھ نافذ کرے گا: `X > 5 ∧ X < 10` (یعنی، `x` 5 سے بڑا ہے اور `x` 10 سے کم ہے)۔ اس کے بعد متعلقہ پاتھ پریڈیکیٹ `x = X > 5 ∧ X < 10` کو حل کرنے کے لیے ایک SMT سالور کو دیا جائے گا۔ اگر کوئی خاص قدر فارمولہ `x = X > 5 ∧ X < 10` کو پورا کرتی ہے، تو SMT سالور اس کا حساب لگائے گا—مثال کے طور پر، سالور `x` کے لیے `7` کی قدر پیدا کر سکتا ہے۔ + +چونکہ علامتی نفاذ کسی پروگرام کے ان پٹس پر انحصار کرتا ہے، اور تمام قابل رسائی حالتوں کو دریافت کرنے کے لیے ان پٹس کا سیٹ ممکنہ طور پر لامحدود ہے، یہ اب بھی ٹیسٹنگ کی ایک شکل ہے۔ تاہم، جیسا کہ مثال میں دکھایا گیا ہے، علامتی نفاذ ان پٹس کو تلاش کرنے کے لیے باقاعدہ ٹیسٹنگ سے زیادہ موثر ہے جو خاصیت کی خلاف ورزیوں کو متحرک کرتے ہیں۔ + +مزید برآں، علامتی نفاذ دیگر پراپرٹی پر مبنی تکنیکوں (مثلاً، فزنگ) کے مقابلے میں کم غلط مثبت پیدا کرتا ہے جو کسی فنکشن کے لیے تصادفی طور پر ان پٹ تیار کرتی ہیں۔ اگر علامتی نفاذ کے دوران کسی خرابی کی حالت کو متحرک کیا جاتا ہے، تو خرابی کو متحرک کرنے والی ایک ٹھوس قدر پیدا کرنا اور مسئلے کو دوبارہ پیش کرنا ممکن ہے۔ + +علامتی نفاذ درستگی کا کچھ حد تک ریاضیاتی ثبوت بھی فراہم کر سکتا ہے۔ اوور فلو سے تحفظ کے ساتھ کنٹریکٹ فنکشن کی درج ذیل مثال پر غور کریں: + +``` +function safe_add(uint x, uint y) returns(uint z){ + + z = x + y; + require(z>=x); + require(z>=y); + + return z; +} +``` + +ایک نفاذ کا ٹریس جو ایک انٹیجر اوور فلو کا باعث بنتا ہے اسے فارمولہ پورا کرنے کی ضرورت ہوگی: `z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)` اس طرح کے فارمولے کو حل کرنے کا امکان نہیں ہے، لہذا یہ اس بات کا ریاضیاتی ثبوت فراہم کرتا ہے کہ فنکشن `safe_add` کبھی بھی اوور فلو نہیں ہوتا ہے۔ + +### اسمارٹ کنٹریکٹس کے لیے باضابطہ تصدیق کیوں استعمال کریں؟ {#benefits-of-formal-verification} + +#### قابل اعتمادی کی ضرورت {#need-for-reliability} + +باضابطہ تصدیق کا استعمال حفاظت کے لیے اہم نظاموں کی درستگی کا اندازہ لگانے کے لیے کیا جاتا ہے جن کی ناکامی کے تباہ کن نتائج ہو سکتے ہیں، جیسے موت، چوٹ، یا مالی بربادی۔ اسمارٹ کنٹریکٹس اعلیٰ قدر والی ایپلی کیشنز ہیں جو بہت بڑی مقدار میں قدر کو کنٹرول کرتی ہیں، اور ڈیزائن میں معمولی غلطیاں [صارفین کے لیے ناقابل تلافی نقصانات](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/) کا باعث بن سکتی ہیں۔ تاہم، تعیناتی سے پہلے کسی کنٹریکٹ کی باضابطہ تصدیق کرنے سے اس بات کی ضمانت بڑھ سکتی ہے کہ یہ بلاک چین پر چلنے کے بعد توقع کے مطابق کام کرے گا۔ + +کسی بھی اسمارٹ کنٹریکٹ میں قابل اعتمادی ایک انتہائی مطلوبہ خوبی ہے، خاص طور پر اس لیے کہ ایتھریم ورچوئل مشین (EVM) میں تعینات کوڈ عام طور پر ناقابل تغیر ہوتا ہے۔ چونکہ لانچ کے بعد اپ گریڈ آسانی سے دستیاب نہیں ہوتے، کنٹریکٹس کی قابل اعتمادی کی ضمانت دینے کی ضرورت باضابطہ تصدیق کو ضروری بناتی ہے۔ باضابطہ تصدیق مشکل مسائل کا پتہ لگانے کے قابل ہے، جیسے انٹیجر انڈر فلو اور اوور فلو، ری-اینٹرینسی، اور خراب گیس کی اصلاح، جو آڈیٹرز اور ٹیسٹرز سے بچ سکتے ہیں۔ + +#### فعالیاتی درستگی کو ثابت کریں {#prove-functional-correctness} + +پروگرام کی جانچ یہ ثابت کرنے کا سب سے عام طریقہ ہے کہ ایک اسمارٹ کنٹریکٹ کچھ ضروریات کو پورا کرتا ہے۔ اس میں ایک کنٹریکٹ کو اس ڈیٹا کے نمونے کے ساتھ نافذ کرنا شامل ہے جسے اسے سنبھالنے کی توقع ہے اور اس کے رویے کا تجزیہ کرنا۔ اگر کنٹریکٹ نمونے کے ڈیٹا کے لیے متوقع نتائج واپس کرتا ہے، تو ڈیولپرز کے پاس اس کی درستگی کا معروضی ثبوت ہوتا ہے۔ + +تاہم، یہ نقطہ نظر ان ان پٹ اقدار کے لیے درست نفاذ کو ثابت نہیں کر سکتا جو نمونے کا حصہ نہیں ہیں۔ لہذا، کسی کنٹریکٹ کی جانچ کیڑوں کا پتہ لگانے میں مدد کر سکتی ہے (یعنی، اگر کچھ کوڈ پاتھ نفاذ کے دوران مطلوبہ نتائج واپس کرنے میں ناکام ہو جاتے ہیں)، لیکن **یہ حتمی طور پر کیڑوں کی عدم موجودگی کو ثابت نہیں کر سکتی**۔ + +اس کے برعکس، باضابطہ تصدیق باضابطہ طور پر یہ ثابت کر سکتی ہے کہ ایک اسمارٹ کنٹریکٹ لامحدود حد تک نفاذ کے لیے ضروریات کو پورا کرتا ہے _بغیر_ کنٹریکٹ کو چلائے۔ اس کے لیے ایک باضابطہ تفصیلات بنانے کی ضرورت ہوتی ہے جو کنٹریکٹ کے صحیح رویوں کو ٹھیک ٹھیک بیان کرتی ہے اور کنٹریکٹ کے نظام کا ایک باضابطہ (ریاضیاتی) ماڈل تیار کرتی ہے۔ پھر ہم کنٹریکٹ کے ماڈل اور اس کی تفصیلات کے درمیان مطابقت کی جانچ کے لیے ایک باضابطہ ثبوت کے طریقہ کار کی پیروی کر سکتے ہیں۔ + +باضابطہ تصدیق کے ساتھ، یہ سوال کہ آیا کنٹریکٹ کی کاروباری منطق ضروریات کو پورا کرتی ہے، ایک ریاضیاتی تجویز ہے جسے ثابت یا رد کیا جا سکتا ہے۔ باضابطہ طور پر ایک تجویز کو ثابت کرکے، ہم محدود تعداد میں اقدامات کے ساتھ لامحدود تعداد میں ٹیسٹ کیسز کی تصدیق کر سکتے ہیں۔ اس طریقے سے باضابطہ تصدیق کے پاس یہ ثابت کرنے کے بہتر امکانات ہیں کہ ایک کنٹریکٹ ایک تفصیلات کے حوالے سے فعالیاتی طور پر درست ہے۔ + +#### مثالی تصدیقی اہداف {#ideal-verification-targets} + +ایک تصدیقی ہدف اس نظام کو بیان کرتا ہے جس کی باضابطہ تصدیق کی جانی ہے۔ باضابطہ تصدیق کا بہترین استعمال "ایمبیڈڈ سسٹمز" (سافٹ ویئر کے چھوٹے، سادہ ٹکڑے جو ایک بڑے نظام کا حصہ بنتے ہیں) میں ہوتا ہے۔ وہ خصوصی ڈومینز کے لیے بھی مثالی ہیں جن کے اصول کم ہوتے ہیں، کیونکہ اس سے ڈومین-مخصوص خصوصیات کی تصدیق کے لیے ٹولز میں ترمیم کرنا آسان ہو جاتا ہے۔ + +اسمارٹ کنٹریکٹس — کم از کم، کچھ حد تک — دونوں ضروریات کو پورا کرتے ہیں۔ مثال کے طور پر، ایتھریم کنٹریکٹس کا چھوٹا سائز انہیں باضابطہ تصدیق کے لیے موزوں بناتا ہے۔ اسی طرح، EVM سادہ اصولوں کی پیروی کرتا ہے، جو EVM میں چلنے والے پروگراموں کے لیے معنوی خصوصیات کی وضاحت اور تصدیق کو آسان بناتا ہے۔ + +### تیز تر ترقیاتی سائیکل {#faster-development-cycle} + +باضابطہ تصدیق کی تکنیکیں، جیسے ماڈل چیکنگ اور علامتی نفاذ، عام طور پر اسمارٹ کنٹریکٹ کوڈ کے باقاعدہ تجزیے (جانچ یا آڈٹ کے دوران کیے جانے والے) سے زیادہ موثر ہیں۔ اس کی وجہ یہ ہے کہ باضابطہ تصدیق دعووں کی جانچ کے لیے علامتی اقدار پر انحصار کرتی ہے ("کیا ہوگا اگر کوئی صارف _n_ ایتھر نکالنے کی کوشش کرے؟") جانچ کے برعکس جو ٹھوس اقدار کا استعمال کرتی ہے ("کیا ہوگا اگر کوئی صارف 5 ایتھر نکالنے کی کوشش کرے؟")۔ + +علامتی ان پٹ متغیرات ٹھوس اقدار کی متعدد کلاسوں کا احاطہ کر سکتے ہیں، لہذا باضابطہ تصدیق کے طریقے کم وقت میں زیادہ کوڈ کوریج کا وعدہ کرتے ہیں۔ جب موثر طریقے سے استعمال کیا جائے تو، باضابطہ تصدیق ڈیولپرز کے لیے ترقیاتی سائیکل کو تیز کر سکتی ہے۔ + +باضابطہ تصدیق مہنگی ڈیزائن کی غلطیوں کو کم کرکے غیر مرکزی ایپلی کیشنز (dapps) بنانے کے عمل کو بھی بہتر بناتی ہے۔ کمزوریوں کو ٹھیک کرنے کے لیے کنٹریکٹس کو اپ گریڈ کرنے (جہاں ممکن ہو) کے لیے کوڈ بیسز کی وسیع پیمانے پر دوبارہ تحریر اور ترقی پر زیادہ محنت کی ضرورت ہوتی ہے۔ باضابطہ تصدیق کنٹریکٹ کے نفاذ میں بہت سی غلطیوں کا پتہ لگا سکتی ہے جو ٹیسٹرز اور آڈیٹرز سے بچ سکتی ہیں اور کنٹریکٹ کو تعینات کرنے سے پہلے ان مسائل کو ٹھیک کرنے کا کافی موقع فراہم کرتی ہے۔ + +## باضابطہ تصدیق کے نقصانات {#drawbacks-of-formal-verification} + +### دستی مزدوری کی لاگت {#cost-of-manual-labor} + +باضابطہ تصدیق، خاص طور پر نیم خودکار تصدیق جس میں ایک انسان درستگی کے ثبوت حاصل کرنے کے لیے پروور کی رہنمائی کرتا ہے، کافی دستی مزدوری کی ضرورت ہوتی ہے۔ مزید برآں، باضابطہ تفصیلات بنانا ایک پیچیدہ سرگرمی ہے جس کے لیے اعلیٰ سطح کی مہارت کی ضرورت ہوتی ہے۔ + +یہ عوامل (کوشش اور مہارت) باضابطہ تصدیق کو کنٹریکٹس میں درستگی کا اندازہ لگانے کے معمول کے طریقوں، جیسے جانچ اور آڈٹ، کے مقابلے میں زیادہ مطالبہ کرنے والا اور مہنگا بناتے ہیں۔ اس کے باوجود، ایک مکمل تصدیقی آڈٹ کی قیمت ادا کرنا عملی ہے، اسمارٹ کنٹریکٹ کے نفاذ میں غلطیوں کی لاگت کو دیکھتے ہوئے۔ + +### غلط منفی {#false-negatives} + +باضابطہ تصدیق صرف یہ جانچ سکتی ہے کہ آیا اسمارٹ کنٹریکٹ کا نفاذ باضابطہ تفصیلات سے میل کھاتا ہے۔ اس طرح، یہ یقینی بنانا ضروری ہے کہ تفصیلات ایک اسمارٹ کنٹریکٹ کے متوقع رویوں کو صحیح طریقے سے بیان کرے۔ + +اگر تفصیلات خراب طریقے سے لکھی گئی ہیں، تو خصوصیات کی خلاف ورزیوں — جو کمزور نفاذ کی طرف اشارہ کرتی ہیں — کا باضابطہ تصدیقی آڈٹ کے ذریعے پتہ نہیں لگایا جا سکتا۔ اس معاملے میں، ایک ڈیولپر غلطی سے یہ فرض کر سکتا ہے کہ کنٹریکٹ بگ سے پاک ہے۔ + +### کارکردگی کے مسائل {#performance-issues} + +باضابطہ تصدیق میں کارکردگی کے متعدد مسائل کا سامنا کرنا پڑتا ہے۔ مثال کے طور پر، ماڈل چیکنگ اور علامتی جانچ کے دوران بالترتیب سامنے آنے والے اسٹیٹ اور پاتھ ایکسپلوژن کے مسائل، تصدیقی طریقہ کار کو متاثر کر سکتے ہیں۔ اس کے علاوہ، باضابطہ تصدیق کے ٹولز اکثر اپنی بنیادی تہہ میں SMT سالورز اور دیگر رکاوٹ حل کرنے والے استعمال کرتے ہیں، اور یہ سالورز کمپیوٹیشنل طور پر انتہائی شدید طریقہ کار پر انحصار کرتے ہیں۔ + +اس کے علاوہ، پروگرام کی تصدیق کرنے والوں کے لیے یہ ہمیشہ ممکن نہیں ہوتا کہ وہ یہ تعین کر سکیں کہ آیا کوئی خاصیت (جسے منطقی فارمولے کے طور پر بیان کیا گیا ہے) پوری کی جا سکتی ہے یا نہیں ( "[فیصلہ کرنے کا مسئلہ](https://en.wikipedia.org/wiki/Decision_problem)") کیونکہ ایک پروگرام کبھی ختم نہیں ہو سکتا۔ اس طرح، کسی کنٹریکٹ کے لیے کچھ خصوصیات کو ثابت کرنا ناممکن ہو سکتا ہے چاہے وہ اچھی طرح سے بیان کیا گیا ہو۔ + +## ایتھریم اسمارٹ کنٹریکٹس کے لیے باضابطہ تصدیق کے ٹولز {#formal-verification-tools} + +### باضابطہ تفصیلات بنانے کے لیے تفصیلات کی زبانیں {#specification-languages} + +**Act**: __Act اسٹوریج اپ ڈیٹس، پری/پوسٹ کنڈیشنز اور کنٹریکٹ انویرینٹس کی تفصیلات کی اجازت دیتا ہے۔ اس کے ٹول سویٹ میں پروف بیک اینڈز بھی ہیں جو Coq, SMT سالورز، یا hevm کے ذریعے بہت سی خصوصیات کو ثابت کرنے کے قابل ہیں۔__ + +- [GitHub](https://github.com/ethereum/act) +- [دستاویزات](https://github.com/argotorg/act) + +**Scribble** - __Scribble اسکربل تفصیلات کی زبان میں کوڈ تشریحات کو ٹھوس دعووں میں تبدیل کرتا ہے جو تفصیلات کی جانچ کرتے ہیں۔__ + +- [دستاویزات](https://docs.scribble.codes/) + +**Dafny** - __Dafny ایک تصدیق کے لیے تیار پروگرامنگ زبان ہے جو کوڈ کی درستگی کے بارے میں استدلال کرنے اور اسے ثابت کرنے کے لیے اعلیٰ سطحی تشریحات پر انحصار کرتی ہے۔__ + +- [GitHub](https://github.com/dafny-lang/dafny) + +### درستگی کی جانچ کے لیے پروگرام کی تصدیق کرنے والے {#program-verifiers} + +**Certora Prover** - _Certora Prover اسمارٹ کنٹریکٹس میں کوڈ کی درستگی کی جانچ کے لیے ایک خودکار باضابطہ تصدیقی ٹول ہے۔ تفصیلات CVL (Certora Verification Language) میں لکھی جاتی ہیں، جس میں جامد تجزیہ اور رکاوٹ حل کرنے کے امتزاج کا استعمال کرتے ہوئے خاصیت کی خلاف ورزیوں کا پتہ لگایا جاتا ہے۔_ + +- [ویب سائٹ](https://www.certora.com/) +- [دستاویزات](https://docs.certora.com/en/latest/index.html) + +**Solidity SMTChecker** - __Solidity کا SMTChecker SMT (Satisfiability Modulo Theories) اور Horn solving پر مبنی ایک بلٹ ان ماڈل چیکر ہے۔ یہ تصدیق کرتا ہے کہ آیا کنٹریکٹ کا سورس کوڈ تالیف کے دوران تفصیلات سے میل کھاتا ہے اور جامد طور پر حفاظتی خصوصیات کی خلاف ورزیوں کی جانچ کرتا ہے۔__ + +- [GitHub](https://github.com/ethereum/solidity) + +**solc-verify** - __solc-verify سولیڈیٹی کمپائلر کا ایک توسیعی ورژن ہے جو تشریحات اور ماڈیولر پروگرام کی تصدیق کا استعمال کرتے ہوئے سولیڈیٹی کوڈ پر خودکار باضابطہ تصدیق انجام دے سکتا ہے۔__ + +- [GitHub](https://github.com/SRI-CSL/solidity) + +**KEVM** - __KEVM ایتھریم ورچوئل مشین (EVM) کی ایک باضابطہ سیمانٹکس ہے جو K فریم ورک میں لکھی گئی ہے۔ KEVM قابل عمل ہے اور رسائی کی منطق کا استعمال کرتے ہوئے کچھ خاصیت سے متعلق دعووں کو ثابت کر سکتا ہے۔__ + +- [GitHub](https://github.com/runtimeverification/evm-semantics) +- [دستاویزات](https://jellopaper.org/) + +### تھیورم کی تصدیق کے لیے منطقی فریم ورک {#theorem-provers} + +**Isabelle** - _Isabelle/HOL ایک پروف اسسٹنٹ ہے جو ریاضیاتی فارمولوں کو باضابطہ زبان میں ظاہر کرنے کی اجازت دیتا ہے اور ان فارمولوں کو ثابت کرنے کے لیے ٹولز فراہم کرتا ہے۔ مرکزی اطلاق ریاضیاتی ثبوتوں کی رسمی شکل دینا ہے اور خاص طور پر باضابطہ تصدیق، جس میں کمپیوٹر ہارڈ ویئر یا سافٹ ویئر کی درستگی کو ثابت کرنا اور کمپیوٹر زبانوں اور پروٹوکولز کی خصوصیات کو ثابت کرنا شامل ہے۔_ + +- [GitHub](https://github.com/isabelle-prover) +- [دستاویزات](https://isabelle.in.tum.de/documentation.html) + +**Rocq** - _Rocq ایک انٹرایکٹو تھیورم پروور ہے جو آپ کو تھیورمز کا استعمال کرتے ہوئے پروگراموں کی تعریف کرنے اور درستگی کے مشین-چیک شدہ ثبوتوں کو انٹرایکٹو طور پر تیار کرنے دیتا ہے۔_ + +- [GitHub](https://github.com/rocq-prover/rocq) +- [دستاویزات](https://rocq-prover.org/docs) + +### اسمارٹ کنٹریکٹس میں کمزور نمونوں کا پتہ لگانے کے لیے علامتی نفاذ پر مبنی ٹولز {#symbolic-execution-tools} + +**Manticore** - __علامتی نفاذ پر مبنی EVM بائٹ کوڈ تجزیہ ٹول_۔_ + +- [GitHub](https://github.com/trailofbits/manticore) +- [دستاویزات](https://github.com/trailofbits/manticore/wiki) + +**hevm** - __hevm EVM بائٹ کوڈ کے لیے ایک علامتی نفاذ انجن اور مساوات چیکر ہے۔__ + +- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) + +**Mythril** - _ایتھریم اسمارٹ کنٹریکٹس میں کمزوریوں کا پتہ لگانے کے لیے ایک علامتی نفاذ کا ٹول_ + +- [GitHub](https://github.com/ConsenSys/mythril-classic) +- [دستاویزات](https://mythril-classic.readthedocs.io/en/develop/) + +## مزید پڑھیں {#further-reading} + +- [اسمارٹ کنٹریکٹس کی باضابطہ تصدیق کیسے کام کرتی ہے](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [باضابطہ تصدیق کیسے بے عیب اسمارٹ کنٹریکٹس کو یقینی بنا سکتی ہے](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) +- [ایتھریم ایکو سسٹم میں باضابطہ تصدیق کے منصوبوں کا ایک جائزہ](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [ایتھریم 2.0 ڈپازٹ اسمارٹ کنٹریکٹ کی اینڈ ٹو اینڈ باضابطہ تصدیق](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) +- [دنیا کے سب سے مشہور اسمارٹ کنٹریکٹ کی باضابطہ تصدیق](https://www.zellic.io/blog/formal-verification-weth) +- [SMTChecker اور باضابطہ تصدیق](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/index.md b/public/content/translations/ur/developers/docs/smart-contracts/index.md new file mode 100644 index 00000000000..47533cd526d --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/index.md @@ -0,0 +1,112 @@ +--- +title: "اسمارٹ کنٹریکٹس کا تعارف" +description: "اسمارٹ کنٹریکٹس کا ایک جائزہ، جس میں ان کی منفرد خصوصیات اور حدود پر توجہ مرکوز کی گئی ہے۔" +lang: ur-in +--- + +## اسمارٹ کنٹریکٹ کیا ہے؟ {#what-is-a-smart-contract} + +ایک "اسمارٹ کنٹریکٹ" محض ایک پروگرام ہے جو Ethereum بلاک چین پر چلتا ہے۔ یہ کوڈ (اس کے فنکشنز) اور ڈیٹا (اس کی اسٹیٹ) کا ایک مجموعہ ہے جو Ethereum بلاک چین پر ایک مخصوص ایڈریس پر رہتا ہے۔ + +اسمارٹ کنٹریکٹس ایک قسم کے [Ethereum اکاؤنٹ](/developers/docs/accounts/) ہیں۔ اس کا مطلب ہے کہ ان کا ایک بیلنس ہوتا ہے اور وہ ٹرانزیکشنز کا ہدف ہو سکتے ہیں۔ تاہم انہیں کسی یوزر کے ذریعے کنٹرول نہیں کیا جاتا، اس کے بجائے انہیں نیٹ ورک پر ڈیپلائے کیا جاتا ہے اور پروگرام کے مطابق چلایا جاتا ہے۔ یوزر اکاؤنٹس پھر ایسے ٹرانزیکشنز جمع کر کے ایک اسمارٹ کنٹریکٹ کے ساتھ تعامل کر سکتے ہیں جو اسمارٹ کنٹریکٹ پر بیان کردہ فنکشن کو عمل میں لاتے ہیں۔ اسمارٹ کنٹریکٹس ایک باقاعدہ کنٹریکٹ کی طرح اصولوں کی وضاحت کر سکتے ہیں، اور کوڈ کے ذریعے خود بخود ان کا نفاذ کر سکتے ہیں۔ اسمارٹ کنٹریکٹس کو بطور ڈیفالٹ ڈیلیٹ نہیں کیا جا سکتا، اور ان کے ساتھ تعاملات ناقابل واپسی ہیں۔ + +## شرائط {#prerequisites} + +اگر آپ ابھی شروعات کر رہے ہیں یا کم تکنیکی تعارف کی تلاش میں ہیں، تو ہم اپنے [اسمارٹ کنٹریکٹس کے تعارف](/smart-contracts/) کی سفارش کرتے ہیں۔ + +اسمارٹ کنٹریکٹس کی دنیا میں قدم رکھنے سے پہلے یقینی بنائیں کہ آپ نے [اکاؤنٹس](/developers/docs/accounts/)، [ٹرانزیکشنز](/developers/docs/transactions/) اور [Ethereum ورچوئل مشین](/developers/docs/evm/) کے بارے میں پڑھ لیا ہے۔ + +## ایک ڈیجیٹل وینڈنگ مشین {#a-digital-vending-machine} + +شاید ایک اسمارٹ کنٹریکٹ کے لیے بہترین استعارہ ایک وینڈنگ مشین ہے، جیسا کہ [Nick Szabo](https://unenumerated.blogspot.com/) نے بیان کیا ہے۔ صحیح ان پٹس کے ساتھ، ایک مخصوص آؤٹ پٹ کی ضمانت دی جاتی ہے۔ + +ایک وینڈنگ مشین سے اسنیک حاصل کرنے کے لیے: + +``` +پیسہ + اسنیک کا انتخاب = اسنیک دیا گیا +``` + +یہ منطق وینڈنگ مشین میں پروگرام کی گئی ہے۔ + +ایک اسمارٹ کنٹریکٹ میں، ایک وینڈنگ مشین کی طرح، منطق پروگرام کی گئی ہوتی ہے۔ یہاں ایک سادہ مثال ہے کہ یہ وینڈنگ مشین کیسی نظر آئے گی اگر یہ Solidity میں لکھا ہوا ایک اسمارٹ کنٹریکٹ ہوتا: + +```solidity +pragma solidity 0.8.7; + +contract VendingMachine { + + // کنٹریکٹ کے اسٹیٹ ویری ایبلز کا اعلان کریں + address public owner; + mapping (address => uint) public cupcakeBalances; + + // جب 'VendingMachine' کنٹریکٹ ڈیپلائے ہوتا ہے: + // 1. ڈیپلائے کرنے والے ایڈریس کو کنٹریکٹ کے مالک کے طور پر سیٹ کریں + // 2. ڈیپلائے شدہ اسمارٹ کنٹریکٹ کے کپ کیک بیلنس کو 100 پر سیٹ کریں + constructor() { + owner = msg.sender; + cupcakeBalances[address(this)] = 100; + } + + // مالک کو اسمارٹ کنٹریکٹ کے کپ کیک بیلنس کو بڑھانے کی اجازت دیں + function refill(uint amount) public { + require(msg.sender == owner, "صرف مالک ہی دوبارہ بھر سکتا ہے۔"); + cupcakeBalances[address(this)] += amount; + } + + // کسی کو بھی کپ کیک خریدنے کی اجازت دیں + function purchase(uint amount) public payable { + require(msg.value >= amount * 1 ether, "آپ کو فی کپ کیک کم از کم 1 ETH ادا کرنا ہوگا۔"); + require(cupcakeBalances[address(this)] >= amount, "اس خریداری کو مکمل کرنے کے لیے اسٹاک میں کافی کپ کیکس نہیں ہیں۔"); + cupcakeBalances[address(this)] -= amount; + cupcakeBalances[msg.sender] += amount; + } +} +``` + +جس طرح ایک وینڈنگ مشین ایک وینڈر ملازم کی ضرورت کو ختم کرتی ہے، اسی طرح اسمارٹ کنٹریکٹس کئی صنعتوں میں بیچوالوں کی جگہ لے سکتے ہیں۔ + +## بغیر اجازت کے {#permissionless} + +کوئی بھی اسمارٹ کنٹریکٹ لکھ سکتا ہے اور اسے نیٹ ورک پر ڈیپلائے کر سکتا ہے۔ آپ کو صرف ایک [اسمارٹ کنٹریکٹ لینگویج](/developers/docs/smart-contracts/languages/) میں کوڈ کرنا سیکھنے کی ضرورت ہے، اور اپنے کنٹریکٹ کو ڈیپلائے کرنے کے لیے کافی ETH ہونا چاہیے۔ ایک اسمارٹ کنٹریکٹ کو ڈیپلائے کرنا تکنیکی طور پر ایک ٹرانزیکشن ہے، لہذا آپ کو اسی طرح [گیس](/developers/docs/gas/) ادا کرنے کی ضرورت ہے جس طرح آپ ایک سادہ ETH ٹرانسفر کے لیے گیس ادا کرتے ہیں۔ تاہم، کنٹریکٹ ڈیپلائیمنٹ کے لیے گیس کے اخراجات بہت زیادہ ہیں۔ + +Ethereum میں اسمارٹ کنٹریکٹس لکھنے کے لیے ڈیولپر-فرینڈلی زبانیں ہیں: + +- Solidity +- Vyper + +[زبانوں کے بارے میں مزید](/developers/docs/smart-contracts/languages/) + +تاہم، انہیں ڈیپلائے کرنے سے پہلے کمپائل کیا جانا چاہیے تاکہ Ethereum کی ورچوئل مشین کنٹریکٹ کی تشریح اور اسے اسٹور کر سکے۔ [کمپائلیشن پر مزید](/developers/docs/smart-contracts/compiling/) + +## کمپوزیبلٹی {#composability} + +اسمارٹ کنٹریکٹس Ethereum پر پبلک ہیں اور انہیں اوپن APIs کے طور پر سمجھا جا سکتا ہے۔ اس کا مطلب ہے کہ آپ اپنے اسمارٹ کنٹریکٹ میں دوسرے اسمارٹ کنٹریکٹس کو کال کر کے جو ممکن ہے اسے بہت حد تک بڑھا سکتے ہیں۔ کنٹریکٹس دوسرے کنٹریکٹس کو بھی ڈیپلائے کر سکتے ہیں۔ + +[اسمارٹ کنٹریکٹ کمپوزیبلٹی](/developers/docs/smart-contracts/composability/) کے بارے میں مزید جانیں۔ + +## حدود {#limitations} + +اسمارٹ کنٹریکٹس اکیلے "حقیقی دنیا" کے واقعات کے بارے میں معلومات حاصل نہیں کر سکتے کیونکہ وہ آف چین ذرائع سے ڈیٹا حاصل نہیں کر سکتے۔ اس کا مطلب ہے کہ وہ حقیقی دنیا کے واقعات پر ردعمل ظاہر نہیں کر سکتے۔ ایسا ڈیزائن کے مطابق ہے۔ بیرونی معلومات پر انحصار کرنا اتفاق رائے کو خطرے میں ڈال سکتا ہے، جو سیکیورٹی اور ڈی سینٹرلائزیشن کے لیے اہم ہے۔ + +تاہم، بلاک چین ایپلی کیشنز کے لیے یہ اہم ہے کہ وہ آف چین ڈیٹا استعمال کر سکیں۔ اس کا حل [oracles](/developers/docs/oracles/) ہیں جو ایسے ٹولز ہیں جو آف چین ڈیٹا حاصل کرتے ہیں اور اسے اسمارٹ کنٹریکٹس کے لیے دستیاب کراتے ہیں۔ + +اسمارٹ کنٹریکٹس کی ایک اور حد کنٹریکٹ کا زیادہ سے زیادہ سائز ہے۔ ایک اسمارٹ کنٹریکٹ زیادہ سے زیادہ 24KB کا ہو سکتا ہے ورنہ اس کی گیس ختم ہو جائے گی۔ [The Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535) کا استعمال کر کے اس سے بچا جا سکتا ہے۔ + +## ملٹی سِگ کنٹریکٹس {#multisig} + +ملٹی سِگ (متعدد-دستخط) کنٹریکٹس اسمارٹ کنٹریکٹ اکاؤنٹس ہیں جنہیں ٹرانزیکشن کو انجام دینے کے لیے متعدد درست دستخطوں کی ضرورت ہوتی ہے۔ یہ ان کنٹریکٹس کے لیے ناکامی کے واحد نکات سے بچنے کے لیے بہت مفید ہے جن میں بڑی مقدار میں ether یا دیگر ٹوکنز موجود ہوں۔ ملٹی سِگ کنٹریکٹ کے نفاذ اور کلیدی انتظام کی ذمہ داری کو متعدد پارٹیوں کے درمیان تقسیم کرتے ہیں اور ایک واحد پرائیویٹ کلید کے کھو جانے کو روکتے ہیں جس سے فنڈز کا ناقابل واپسی نقصان ہوتا ہے۔ ان وجوہات کی بناء پر، ملٹی سِگ کنٹریکٹس کو سادہ DAO گورننس کے لیے استعمال کیا جا سکتا ہے۔ ملٹی سِگز کو عمل میں لانے کے لیے M ممکنہ قابل قبول دستخطوں میں سے N دستخطوں کی ضرورت ہوتی ہے (جہاں N ≤ M، اور M > 1)۔ `N = 3, M = 5` اور `N = 4, M = 7` عام طور پر استعمال ہوتے ہیں۔ ایک 4/7 ملٹی سِگ کے لیے سات ممکنہ درست دستخطوں میں سے چار کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ اگر تین دستخط کھو بھی جائیں تب بھی فنڈز بازیافت کیے جا سکتے ہیں۔ اس صورت میں، اس کا یہ بھی مطلب ہے کہ کلیدی ہولڈرز کی اکثریت کو متفق ہونا اور دستخط کرنا ہوگا تاکہ کنٹریکٹ عمل میں آ سکے۔ + +## اسمارٹ کنٹریکٹ کے وسائل {#smart-contract-resources} + +**OpenZeppelin Contracts -** **_محفوظ اسمارٹ کنٹریکٹ ڈیولپمنٹ کے لیے لائبریری۔_** + +- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [کمیونٹی فورم](https://forum.openzeppelin.com/c/general/16) + +## مزید پڑھیں {#further-reading} + +- [Coinbase: اسمارٹ کنٹریکٹ کیا ہے؟](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) +- [Chainlink: اسمارٹ کنٹریکٹ کیا ہے؟](https://chain.link/education/smart-contracts) +- [ویڈیو: سادہ الفاظ میں وضاحت - اسمارٹ کنٹریکٹس](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft: Web3 لرننگ اور آڈیٹنگ پلیٹ فارم](https://updraft.cyfrin.io) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/languages/index.md b/public/content/translations/ur/developers/docs/smart-contracts/languages/index.md new file mode 100644 index 00000000000..09a2725e18f --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/languages/index.md @@ -0,0 +1,342 @@ +--- +title: "اسمارٹ کنٹریکٹ کی زبانیں" +description: "دو اہم اسمارٹ کنٹریکٹ زبانوں – Solidity اور Vyper کا ایک جائزہ اور موازنہ۔" +lang: ur-in +--- + +Ethereum کے بارے میں ایک بڑی بات یہ ہے کہ اسمارٹ کنٹریکٹس کو نسبتاً ڈیولپر-دوست زبانوں کا استعمال کرتے ہوئے پروگرام کیا جا سکتا ہے۔ اگر آپ Python یا کسی بھی [کرلی-بریکٹ زبان](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages) کے ساتھ تجربہ کار ہیں، تو آپ کو مانوس سنٹیکس والی زبان مل سکتی ہے۔ + +دو سب سے زیادہ فعال اور برقرار رکھی جانے والی زبانیں ہیں: + +- Solidity +- Vyper + +Remix IDE، Solidity اور Vyper دونوں میں کنٹریکٹس بنانے اور ٹیسٹ کرنے کے لیے ایک جامع ڈیولپمنٹ ماحول فراہم کرتا ہے۔ [کوڈنگ شروع کرنے کے لیے ان-براؤزر Remix IDE آزمائیں](https://remix.ethereum.org)۔ + +زیادہ تجربہ کار ڈیولپرز Yul، جو [Ethereum ورچوئل مشین](/developers/docs/evm/) کے لیے ایک درمیانی زبان ہے، یا Yul+، جو Yul کی ایک ایکسٹینشن ہے، کا استعمال بھی کرنا چاہ سکتے ہیں۔ + +اگر آپ متجسس ہیں اور ایسی نئی زبانوں کی جانچ میں مدد کرنا پسند کرتے ہیں جو ابھی بھی بہت زیادہ ڈیولپمنٹ کے تحت ہیں، تو آپ Fe کے ساتھ تجربہ کر سکتے ہیں، جو ایک ابھرتی ہوئی اسمارٹ کنٹریکٹ زبان ہے اور فی الحال اپنے ابتدائی مرحلے میں ہے۔ + +## شرائط {#prerequisites} + +پروگرامنگ زبانوں کا پچھلا علم، خاص طور پر JavaScript یا Python کا، آپ کو اسمارٹ کنٹریکٹ زبانوں میں فرق کو سمجھنے میں مدد کر سکتا ہے۔ ہم یہ بھی تجویز کرتے ہیں کہ آپ زبان کے موازنے میں بہت گہرائی میں جانے سے پہلے اسمارٹ کنٹریکٹس کو ایک تصور کے طور پر سمجھ لیں۔ [اسمارٹ کنٹریکٹس کا تعارف](/developers/docs/smart-contracts/)۔ + +## Solidity {#solidity} + +- اسمارٹ کنٹریکٹس کو نافذ کرنے کے لیے آبجیکٹ اورینٹڈ، اعلیٰ سطحی زبان۔ +- کرلی-بریکٹ زبان جو C++ سے سب سے زیادہ متاثر ہوئی ہے۔ +- اسٹیٹیکلی ٹائپڈ (متغیر کی قسم کمپائل کے وقت معلوم ہوتی ہے)۔ +- سپورٹ کرتا ہے: + - انہیریٹنس (آپ دوسرے کنٹریکٹس کو بڑھا سکتے ہیں)۔ + - لائبریریاں (آپ دوبارہ قابل استعمال کوڈ بنا سکتے ہیں جسے آپ مختلف کنٹریکٹس سے کال کر سکتے ہیں - جیسے دیگر آبجیکٹ اورینٹڈ پروگرامنگ زبانوں میں ایک اسٹیٹک کلاس میں اسٹیٹک فنکشنز)۔ + - پیچیدہ صارف کی طرف سے متعین کردہ اقسام۔ + +### اہم لنکس {#important-links} + +- [دستاویزات](https://docs.soliditylang.org/en/latest/) +- [Solidity لینگویج پورٹل](https://soliditylang.org/) +- [Solidity بہ مثال](https://docs.soliditylang.org/en/latest/solidity-by-example.html) +- [GitHub](https://github.com/ethereum/solidity/) +- [Solidity Gitter چیٹ روم](https://gitter.im/ethereum/solidity) سے [Solidity Matrix چیٹ روم](https://matrix.to/#/#ethereum_solidity:gitter.im) پر برج کیا گیا۔ +- [چیٹ شیٹ](https://reference.auditless.com/cheatsheet) +- [Solidity بلاگ](https://blog.soliditylang.org/) +- [Solidity ٹویٹر](https://twitter.com/solidity_lang) + +### مثال کا کنٹریکٹ {#example-contract} + +```solidity +// SPDX-License-Identifier: GPL-3.0 +pragma solidity >= 0.7.0; + +contract Coin { + // کلیدی لفظ "public" متغیرات کو + // دوسرے کنٹریکٹس سے قابل رسائی بناتا ہے + address public minter; + mapping (address => uint) public balances; + + // ایونٹس کلائنٹس کو آپ کی اعلان کردہ مخصوص + // کنٹریکٹ تبدیلیوں پر رد عمل ظاہر کرنے کی اجازت دیتے ہیں + event Sent(address from, address to, uint amount); + + // کنسٹرکٹر کوڈ صرف اس وقت چلتا ہے جب کنٹریکٹ + // بنایا جاتا ہے + constructor() { + minter = msg.sender; + } + + // ایک ایڈریس پر نئے بنائے گئے کوائنز کی ایک رقم بھیجتا ہے + // صرف کنٹریکٹ بنانے والے کے ذریعے کال کیا جا سکتا ہے + function mint(address receiver, uint amount) public { + require(msg.sender == minter); + require(amount < 1e60); + balances[receiver] += amount; + } + + // کسی بھی کالر سے ایک ایڈریس پر + // موجودہ کوائنز کی ایک رقم بھیجتا ہے + function send(address receiver, uint amount) public { + require(amount <= balances[msg.sender], "ناکافی بیلنس۔"); + balances[msg.sender] -= amount; + balances[receiver] += amount; + emit Sent(msg.sender, receiver, amount); + } +} +``` + +یہ مثال آپ کو اس بات کا اندازہ دے گی کہ Solidity کنٹریکٹ کا سنٹیکس کیسا ہوتا ہے۔ فنکشنز اور متغیرات کی مزید تفصیلی تفصیل کے لیے، [دستاویزات دیکھیں](https://docs.soliditylang.org/en/latest/contracts.html)۔ + +## Vyper {#vyper} + +- پائیتھونک پروگرامنگ زبان +- مضبوط ٹائپنگ +- چھوٹا اور قابل فہم کمپائلر کوڈ +- موثر بائٹ کوڈ جنریشن +- جان بوجھ کر Solidity سے کم خصوصیات ہیں اس مقصد کے ساتھ کہ کنٹریکٹس کو زیادہ محفوظ اور آڈٹ کرنے میں آسان بنایا جائے۔ Vyper سپورٹ نہیں کرتا: + - موڈیفائرز + - انہیریٹنس + - ان لائن اسمبلی + - فنکشن اوورلوڈنگ + - آپریٹر اوورلوڈنگ + - ریکرسیو کالنگ + - لامحدود لمبائی کے لوپس + - بائنری فکسڈ پوائنٹس + +مزید معلومات کے لیے، [Vyper کا جواز پڑھیں](https://vyper.readthedocs.io/en/latest/index.html)۔ + +### اہم لنکس {#important-links-1} + +- [دستاویزات](https://vyper.readthedocs.io) +- [Vyper بہ مثال](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) +- [مزید Vyper بہ مثال](https://vyper-by-example.org/) +- [GitHub](https://github.com/vyperlang/vyper) +- [Vyper کمیونٹی ڈسکارڈ چیٹ](https://discord.gg/SdvKC79cJk) +- [چیٹ شیٹ](https://reference.auditless.com/cheatsheet) +- [Vyper کے لیے اسمارٹ کنٹریکٹ ڈیولپمنٹ فریم ورک اور ٹولز](/developers/docs/programming-languages/python/) +- [VyperPunk - Vyper اسمارٹ کنٹریکٹس کو محفوظ بنانا اور ہیک کرنا سیکھیں](https://github.com/SupremacyTeam/VyperPunk) +- [ڈیولپمنٹ کے لیے Vyper ہب](https://github.com/zcor/vyper-dev) +- [Vyper کے بہترین اسمارٹ کنٹریکٹ کی مثالیں](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [شاندار Vyper کیوریٹڈ وسائل](https://github.com/spadebuilders/awesome-vyper) + +### مثال {#example} + +```python +# کھلی نیلامی + +# نیلامی کے پیرامیٹرز + +# فائدہ اٹھانے والا سب سے زیادہ بولی لگانے والے سے رقم وصول کرتا ہے + +beneficiary: public(address) +auctionStart: public(uint256) +auctionEnd: public(uint256) + +# نیلامی کی موجودہ حالت + +highestBidder: public(address) +highestBid: public(uint256) + +# آخر میں true پر سیٹ کریں، کسی بھی تبدیلی کی اجازت نہیں دیتا + +ended: public(bool) + +# واپس کی گئی بولیوں کا ٹریک رکھیں تاکہ ہم ودڈرال پیٹرن کی پیروی کر سکیں + +pendingReturns: public(HashMap[address, uint256]) + +# `_bidding_time` کے ساتھ ایک سادہ نیلامی بنائیں + +# `_beneficiary` ایڈریس والے فائدہ اٹھانے والے کی جانب سے + +# سیکنڈ بولی لگانے کا وقت۔ + +@external +def __init__(_beneficiary: address, _bidding_time: uint256): + self.beneficiary = _beneficiary + self.auctionStart = block.timestamp + self.auctionEnd = self.auctionStart + _bidding_time + +# اس ٹرانزیکشن کے ساتھ بھیجی گئی + +# قیمت کے ساتھ نیلامی پر بولی لگائیں۔ + +# قیمت صرف اس صورت میں واپس کی جائے گی جب + +# نیلامی نہیں جیتی جاتی ہے۔ + +@external +@payable +def bid(): + # چیک کریں کہ بولی کی مدت ختم ہو گئی ہے یا نہیں۔ + assert block.timestamp < self.auctionEnd + # چیک کریں کہ بولی کافی زیادہ ہے + assert msg.value > self.highestBid + # پچھلے سب سے زیادہ بولی لگانے والے کے لیے ریفنڈ کو ٹریک کریں + self.pendingReturns[self.highestBidder] += self.highestBid + # نئی اونچی بولی کو ٹریک کریں + self.highestBidder = msg.sender + self.highestBid = msg.value + +# پہلے سے واپس کی گئی بولی واپس لیں۔ ودڈرال پیٹرن + +# یہاں ایک سیکیورٹی مسئلے سے بچنے کے لیے استعمال کیا جاتا ہے۔ اگر ریفنڈز براہ راست + +# bid() کے حصے کے طور پر بھیجے جاتے، تو ایک بدنیتی پر مبنی بولی لگانے والا کنٹریکٹ + +# ان ریفنڈز کو بلاک کر سکتا تھا اور اس طرح نئی اونچی بولیوں کو آنے سے روک سکتا تھا۔ + +@external +def withdraw(): + pending_amount: uint256 = self.pendingReturns[msg.sender] + self.pendingReturns[msg.sender] = 0 + send(msg.sender, pending_amount) + +# نیلامی ختم کریں اور سب سے اونچی بولی + +# فائدہ اٹھانے والے کو بھیجیں۔ + +@external +def endAuction(): + # یہ دوسرے کنٹریکٹس کے ساتھ تعامل کرنے والے فنکشنز کو (یعنی، وہ فنکشنز کو کال کرتے ہیں یا ایتھر بھیجتے ہیں) + # تین مراحل میں ترتیب دینے کے لیے ایک اچھی رہنما خطوط ہے: + # 1. شرائط کی جانچ کرنا + # 2. اعمال انجام دینا (ممکنہ طور پر شرائط کو تبدیل کرنا) + # 3. دوسرے کنٹریکٹس کے ساتھ تعامل کرنا + # اگر یہ مراحل آپس میں مل جاتے ہیں، تو دوسرا کنٹریکٹ + # موجودہ کنٹریکٹ میں واپس کال کر سکتا ہے اور اسٹیٹ میں ترمیم کر سکتا ہے یا + # اثرات (ایتھر کی ادائیگی) کو کئی بار انجام دینے کا سبب بن سکتا ہے۔ + # اگر اندرونی طور پر کال کیے گئے فنکشنز میں بیرونی + # کنٹریکٹس کے ساتھ تعامل شامل ہے، تو انہیں بھی بیرونی + # کنٹریکٹس کے ساتھ تعامل سمجھا جانا چاہیے۔ + + # 1. شرائط + # چیک کریں کہ نیلامی کا اختتامی وقت پہنچ گیا ہے + assert block.timestamp >= self.auctionEnd + # چیک کریں کہ یہ فنکشن پہلے ہی کال کیا جا چکا ہے + assert not self.ended + + # 2. اثرات + self.ended = True + + # 3. تعامل + send(self.beneficiary, self.highestBid) +``` + +یہ مثال آپ کو اس بات کا اندازہ دے گی کہ Vyper کنٹریکٹ کا سنٹیکس کیسا ہوتا ہے۔ فنکشنز اور متغیرات کی مزید تفصیلی تفصیل کے لیے، [دستاویزات دیکھیں](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction)۔ + +## Yul اور Yul+ {#yul} + +اگر آپ Ethereum میں نئے ہیں اور ابھی تک اسمارٹ کنٹریکٹ زبانوں کے ساتھ کوئی کوڈنگ نہیں کی ہے، تو ہم Solidity یا Vyper کے ساتھ شروع کرنے کی تجویز کرتے ہیں۔ Yul یا Yul+ کو صرف تب دیکھیں جب آپ اسمارٹ کنٹریکٹ سیکیورٹی کے بہترین طریقوں اور EVM کے ساتھ کام کرنے کی تفصیلات سے واقف ہوں۔ + +**Yul** + +- Ethereum کے لیے درمیانی زبان۔ +- [EVM](/developers/docs/evm) اور [Ewasm](https://github.com/ewasm)، جو ایک Ethereum فلیورڈ WebAssembly ہے، کو سپورٹ کرتا ہے اور اسے دونوں پلیٹ فارمز کا ایک قابل استعمال مشترکہ ڈینومینیٹر ہونے کے لیے ڈیزائن کیا گیا ہے۔ +- اعلیٰ سطحی آپٹیمائزیشن مراحل کے لیے اچھا ہدف جو EVM اور Ewasm دونوں پلیٹ فارمز کو یکساں طور پر فائدہ پہنچا سکتے ہیں۔ + +**Yul+** + +- Yul کی ایک نچلی سطح کی، انتہائی موثر ایکسٹینشن۔ +- ابتدائی طور پر ایک [آپٹیمسٹک رول اپ](/developers/docs/scaling/optimistic-rollups/) کنٹریکٹ کے لیے ڈیزائن کیا گیا ہے۔ +- Yul+ کو Yul کے لیے ایک تجرباتی اپ گریڈ تجویز کے طور پر دیکھا جا سکتا ہے، جو اس میں نئی خصوصیات شامل کرتا ہے۔ + +### اہم لنکس {#important-links-2} + +- [Yul دستاویزات](https://docs.soliditylang.org/en/latest/yul.html) +- [Yul+ دستاویزات](https://github.com/fuellabs/yulp) +- [Yul+ تعارفی پوسٹ](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) + +### مثال کا کنٹریکٹ {#example-contract-2} + +درج ذیل سادہ مثال ایک پاور فنکشن کو نافذ کرتی ہے۔ اسے `solc --strict-assembly --bin input.yul` کا استعمال کرتے ہوئے کمپائل کیا جا سکتا ہے۔ مثال کو +input.yul فائل میں محفوظ کیا جانا چاہیے۔ + +``` +{ + function power(base, exponent) -> result + { + switch exponent + case 0 { result := 1 } + case 1 { result := base } + default + { + result := power(mul(base, base), div(exponent, 2)) + if mod(exponent, 2) { result := mul(base, result) } + } + } + let res := power(calldataload(0), calldataload(32)) + mstore(0, res) + return(0, 32) +} +``` + +اگر آپ پہلے سے ہی اسمارٹ کنٹریکٹس کے ساتھ اچھی طرح سے تجربہ کار ہیں، تو Yul میں ایک مکمل ERC20 نفاذ [یہاں](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example) پایا جا سکتا ہے۔ + +## Fe {#fe} + +- Ethereum ورچوئل مشین (EVM) کے لیے اسٹیٹیکلی ٹائپڈ زبان۔ +- Python اور Rust سے متاثر۔ +- سیکھنے میں آسان ہونے کا مقصد ہے -- یہاں تک کہ ان ڈیولپرز کے لیے بھی جو Ethereum ایکو سسٹم میں نئے ہیں۔ +- Fe ڈیولپمنٹ ابھی بھی اپنے ابتدائی مراحل میں ہے، زبان کی الفا ریلیز جنوری 2021 میں ہوئی تھی۔ + +### اہم لنکس {#important-links-3} + +- [GitHub](https://github.com/ethereum/fe) +- [Fe اعلان](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [Fe 2021 روڈ میپ](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) +- [Fe ڈسکارڈ چیٹ](https://discord.com/invite/ywpkAXFjZH) +- [Fe ٹویٹر](https://twitter.com/official_fe) + +### مثال کا کنٹریکٹ {#example-contract-3} + +درج ذیل Fe میں نافذ کردہ ایک سادہ کنٹریکٹ ہے۔ + +``` +type BookMsg = bytes[100] + +contract GuestBook: + pub guest_book: map + + event Signed: + book_msg: BookMsg + + pub def sign(book_msg: BookMsg): + self.guest_book[msg.sender] = book_msg + + emit Signed(book_msg=book_msg) + + pub def get_msg(addr: address) -> BookMsg: + return self.guest_book[addr].to_mem() + +``` + +## کیسے انتخاب کریں {#how-to-choose} + +کسی بھی دوسری پروگرامنگ زبان کی طرح، یہ زیادہ تر صحیح کام کے لیے صحیح ٹول کا انتخاب کرنے کے ساتھ ساتھ ذاتی ترجیحات کے بارے میں ہے۔ + +اگر آپ نے ابھی تک کسی بھی زبان کو نہیں آزمایا ہے تو یہاں کچھ چیزیں ہیں جن پر غور کرنا ہے: + +### Solidity کے بارے میں کیا بڑی بات ہے؟ {#solidity-advantages} + +- اگر آپ ایک ابتدائی ہیں، تو وہاں بہت سے ٹیوٹوریلز اور سیکھنے کے ٹولز موجود ہیں۔ اس کے بارے میں مزید [کوڈنگ کے ذریعے سیکھیں](/developers/learning-tools/) سیکشن میں دیکھیں۔ +- اچھی ڈیولپر ٹولنگ دستیاب ہے۔ +- Solidity کی ایک بڑی ڈیولپر کمیونٹی ہے، جس کا مطلب ہے کہ آپ کو اپنے سوالات کے جوابات بہت جلد مل جائیں گے۔ + +### Vyper کے بارے میں کیا بڑی بات ہے؟ {#vyper-advatages} + +- ان Python ڈیولپرز کے لیے شروع کرنے کا بہترین طریقہ جو اسمارٹ کنٹریکٹس لکھنا چاہتے ہیں۔ +- Vyper میں کم خصوصیات ہیں جو اسے آئیڈیاز کی فوری پروٹوٹائپنگ کے لیے بہترین بناتی ہیں۔ +- Vyper کا مقصد آڈٹ کرنے میں آسان اور زیادہ سے زیادہ انسانی-پڑھنے کے قابل ہونا ہے۔ + +### Yul اور Yul+ کے بارے میں کیا بڑی بات ہے؟ {#yul-advantages} + +- سادہ اور فنکشنل نچلی سطح کی زبان۔ +- خام EVM کے بہت قریب جانے کی اجازت دیتا ہے، جو آپ کے کنٹریکٹس کے گیس کے استعمال کو بہتر بنانے میں مدد کر سکتا ہے۔ + +## زبانوں کا موازنہ {#language-comparisons} + +بنیادی سنٹیکس، کنٹریکٹ لائف سائیکل، انٹرفیس، آپریٹرز، ڈیٹا اسٹرکچرز، فنکشنز، کنٹرول فلو، اور مزید کے موازنے کے لیے Auditless کی اس [چیٹ شیٹ](https://reference.auditless.com/cheatsheet/) کو دیکھیں۔ + +## مزید پڑھیں {#further-reading} + +- [OpenZeppelin کی طرف سے Solidity کنٹریکٹس لائبریری](https://docs.openzeppelin.com/contracts/5.x/) +- [Solidity بہ مثال](https://solidity-by-example.org) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/ur/developers/docs/smart-contracts/libraries/index.md new file mode 100644 index 00000000000..1f96887ef25 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/libraries/index.md @@ -0,0 +1,117 @@ +--- +title: "اسمارٹ معاہدے کی لائبریریاں" +description: "اپنے Ethereum ڈیولپمنٹ پروجیکٹس کو تیز کرنے کے لیے دوبارہ قابل استعمال اسمارٹ معاہدے کی لائبریریوں اور بلڈنگ بلاکس کو دریافت کریں۔" +lang: ur-in +--- + +آپ کو اپنے پروجیکٹ میں ہر اسمارٹ معاہدے کو شروع سے لکھنے کی ضرورت نہیں ہے۔ بہت سی اوپن سورس اسمارٹ معاہدے کی لائبریریاں دستیاب ہیں جو آپ کے پروجیکٹ کے لیے دوبارہ قابل استعمال بلڈنگ بلاکس فراہم کرتی ہیں جو آپ کو پہیے کو دوبارہ ایجاد کرنے سے بچا سکتی ہیں۔ + +## شرائط {#prerequisites} + +اسمارٹ معاہدے کی لائبریریوں میں جانے سے پہلے، اسمارٹ معاہدے کی ساخت کی اچھی سمجھ ہونا ایک اچھا خیال ہے۔ اگر آپ نے ابھی تک ایسا نہیں کیا ہے تو [اسمارٹ معاہدے کی اناٹومی](/developers/docs/smart-contracts/anatomy/) پر جائیں۔ + +## ایک لائبریری میں کیا ہے {#whats-in-a-library} + +آپ عام طور پر اسمارٹ معاہدے کی لائبریریوں میں دو قسم کے بلڈنگ بلاکس تلاش کر سکتے ہیں: دوبارہ قابل استعمال طرز عمل جنہیں آپ اپنے معاہدوں میں شامل کر سکتے ہیں، اور مختلف معیارات کے نفاذ۔ + +### طرز عمل {#behaviors} + +اسمارٹ معاہدے لکھتے وقت، اس بات کا ایک اچھا موقع ہے کہ آپ خود کو بار بار ایک جیسے پیٹرن لکھتے ہوئے پائیں گے، جیسے کسی معاہدے میں محفوظ کارروائیوں کو انجام دینے کے لیے ایک _admin_ پتہ تفویض کرنا، یا کسی غیر متوقع مسئلے کی صورت میں ایک ہنگامی _pause_ بٹن شامل کرنا۔ + +اسمارٹ معاہدے کی لائبریریاں عام طور پر ان طرز عمل کے دوبارہ قابل استعمال نفاذ کو [لائبریریوں](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) کے طور پر یا Solidity میں [وراثت](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) کے ذریعے فراہم کرتی ہیں۔ + +مثال کے طور پر، ذیل میں [OpenZeppelin کنٹریکٹس لائبریری](https://github.com/OpenZeppelin/openzeppelin-contracts) سے [`Ownable` معاہدے](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) کا ایک آسان ورژن ہے، جو کسی پتے کو معاہدے کے مالک کے طور پر نامزد کرتا ہے، اور کسی طریقے تک رسائی کو صرف اس مالک تک محدود کرنے کے لیے ایک موڈیفائر فراہم کرتا ہے۔ + +```solidity +contract Ownable { + address public owner; + + constructor() internal { + owner = msg.sender; + } + + modifier onlyOwner() { + require(owner == msg.sender, "Ownable: caller is not the owner"); + _; + } +} +``` + +اپنے معاہدے میں اس طرح کا بلڈنگ بلاک استعمال کرنے کے لیے، آپ کو پہلے اسے امپورٹ کرنا ہوگا، اور پھر اپنے معاہدوں میں اس سے توسیع کرنی ہوگی۔ یہ آپ کو اپنے فنکشنز کو محفوظ بنانے کے لیے بیس `Ownable` معاہدے کے ذریعے فراہم کردہ موڈیفائر کو استعمال کرنے کی اجازت دے گا۔ + +```solidity +import ".../Ownable.sol"; // امپورٹ شدہ لائبریری کا پاتھ + +contract MyContract is Ownable { + // درج ذیل فنکشن کو صرف مالک ہی کال کر سکتا ہے + function secured() onlyOwner public { + msg.sender.transfer(1 ether); + } +} +``` + +ایک اور مقبول مثال [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) یا [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html) ہے۔ یہ لائبریریاں ہیں (بیس معاہدوں کے برعکس) جو اوور فلو چیک کے ساتھ ریاضی کے فنکشنز فراہم کرتی ہیں، جو زبان کے ذریعے فراہم نہیں کیے جاتے ہیں۔ اپنے معاہدے کو اوور فلو سے بچانے کے لیے مقامی ریاضیاتی کارروائیوں کے بجائے ان میں سے کسی بھی لائبریری کا استعمال کرنا ایک اچھا عمل ہے، جس کے تباہ کن نتائج ہو سکتے ہیں! + +### معیارات {#standards} + +[کمپوزیبلیٹی اور انٹرآپریبلٹی](/developers/docs/smart-contracts/composability/) کو آسان بنانے کے لیے، Ethereum کمیونٹی نے **ERCs** کی شکل میں کئی معیارات کی وضاحت کی ہے۔ آپ ان کے بارے میں [معیارات](/developers/docs/standards/) سیکشن میں مزید پڑھ سکتے ہیں۔ + +جب آپ اپنے معاہدوں کے حصے کے طور پر ERC کو شامل کرتے ہیں، تو اپنا خود کا رول آؤٹ کرنے کی کوشش کرنے کے بجائے معیاری نفاذ کو تلاش کرنا ایک اچھا خیال ہے۔ بہت سی اسمارٹ معاہدے کی لائبریریاں سب سے زیادہ مقبول ERCs کے لیے نفاذ شامل کرتی ہیں۔ مثال کے طور پر، ہر جگہ موجود [ERC20 فنجیبل ٹوکن اسٹینڈرڈ](/developers/tutorials/understand-the-erc-20-token-smart-contract/) [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md)، [DappSys](https://github.com/dapphub/ds-token/) اور [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) میں پایا جا سکتا ہے۔ مزید برآں، کچھ ERCs خود ERC کے حصے کے طور پر کینونیکل نفاذ بھی فراہم کرتے ہیں۔ + +یہ بات قابل ذکر ہے کہ کچھ ERCs اسٹینڈ الون نہیں ہیں، بلکہ دوسرے ERCs میں اضافے ہیں۔ مثال کے طور پر، [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) اس کی قابل استعمالی کو بہتر بنانے کے لیے ERC20 میں ایک توسیع کا اضافہ کرتا ہے۔ + +## لائبریری کیسے شامل کریں {#how-to} + +اپنے پروجیکٹ میں اسے شامل کرنے کے طریقے سے متعلق مخصوص ہدایات کے لیے ہمیشہ اس لائبریری کی دستاویزات کا حوالہ دیں جسے آپ شامل کر رہے ہیں۔ کئی Solidity معاہدے کی لائبریریاں `npm` کا استعمال کرتے ہوئے پیک کی جاتی ہیں، لہذا آپ انہیں صرف `npm install` کر سکتے ہیں۔ معاہدوں کو [کمپائل](/developers/docs/smart-contracts/compiling/) کرنے کے لیے زیادہ تر ٹولز آپ کے `node_modules` میں اسمارٹ معاہدے کی لائبریریوں کو دیکھیں گے، لہذا آپ درج ذیل کام کر سکتے ہیں: + +```solidity +// یہ آپ کے node_modules سے @openzeppelin/contracts لائبریری کو لوڈ کرے گا +import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; + +contract MyNFT is ERC721 { + constructor() ERC721("MyNFT", "MNFT") public { } +} +``` + +آپ جو بھی طریقہ استعمال کرتے ہیں، لائبریری شامل کرتے وقت، ہمیشہ [زبان](/developers/docs/smart-contracts/languages/) کے ورژن پر نظر رکھیں۔ مثال کے طور پر، اگر آپ اپنے معاہدے Solidity 0.5 میں لکھ رہے ہیں تو آپ Solidity 0.6 کے لیے لائبریری استعمال نہیں کر سکتے۔ + +## کب استعمال کریں {#when-to-use} + +اپنے پروجیکٹ کے لیے اسمارٹ معاہدے کی لائبریری استعمال کرنے کے کئی فائدے ہیں۔ سب سے پہلے اور سب سے اہم بات یہ ہے کہ یہ آپ کو استعمال کے لیے تیار بلڈنگ بلاکس فراہم کرکے آپ کا وقت بچاتا ہے جنہیں آپ اپنے سسٹم میں شامل کرسکتے ہیں، بجائے اس کے کہ آپ کو خود انہیں کوڈ کرنا پڑے۔ + +سیکورٹی بھی ایک بڑا پلس ہے۔ اوپن سورس اسمارٹ معاہدے کی لائبریریوں کی بھی اکثر گہری جانچ پڑتال کی جاتی ہے۔ چونکہ بہت سے پروجیکٹس ان پر انحصار کرتے ہیں، کمیونٹی کی طرف سے انہیں مسلسل جائزے میں رکھنے کے لیے ایک مضبوط ترغیب ہے۔ دوبارہ قابل استعمال معاہدے کی لائبریریوں کے مقابلے میں ایپلیکیشن کوڈ میں غلطیاں تلاش کرنا بہت زیادہ عام ہے۔ کچھ لائبریریاں اضافی سیکورٹی کے لیے [بیرونی آڈٹ](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) سے بھی گزرتی ہیں۔ + +تاہم، اسمارٹ معاہدے کی لائبریریوں کا استعمال آپ کے پروجیکٹ میں ایسے کوڈ کو شامل کرنے کا خطرہ رکھتا ہے جس سے آپ واقف نہیں ہیں۔ کسی معاہدے کو امپورٹ کرنا اور اسے براہ راست اپنے پروجیکٹ میں شامل کرنا پرکشش ہے، لیکن اس بات کی اچھی سمجھ کے بغیر کہ وہ معاہدہ کیا کرتا ہے، آپ غیر متوقع رویے کی وجہ سے نادانستہ طور پر اپنے سسٹم میں کوئی مسئلہ پیدا کر سکتے ہیں۔ ہمیشہ اس بات کو یقینی بنائیں کہ آپ جو کوڈ امپورٹ کر رہے ہیں اس کی دستاویزات پڑھیں، اور پھر اسے اپنے پروجیکٹ کا حصہ بنانے سے پہلے خود کوڈ کا جائزہ لیں! + +آخر میں، جب یہ فیصلہ کریں کہ آیا لائبریری کو شامل کرنا ہے، تو اس کے مجموعی استعمال پر غور کریں۔ ایک وسیع پیمانے پر اپنائے جانے والے کے فوائد یہ ہیں کہ اس کی ایک بڑی کمیونٹی ہے اور مسائل کے لیے اس پر زیادہ نظریں ہیں۔ اسمارٹ معاہدوں کے ساتھ تعمیر کرتے وقت سیکورٹی آپ کی بنیادی توجہ ہونی چاہیے! + +## متعلقہ ٹولز {#related-tools} + +**OpenZeppelin Contracts -** **_محفوظ اسمارٹ معاہدے کی ڈیولپمنٹ کے لیے سب سے مشہور لائبریری۔_** + +- [دستاویزات](https://docs.openzeppelin.com/contracts/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [کمیونٹی فورم](https://forum.openzeppelin.com/c/general/16) + +**DappSys -** **_اسمارٹ معاہدوں کے لیے محفوظ، سادہ، لچکدار بلڈنگ بلاکس۔_** + +- [دستاویزات](https://dappsys.readthedocs.io/) +- [GitHub](https://github.com/dapphub/dappsys) + +**HQ20 -** **_ایک Solidity پروجیکٹ جس میں معاہدے، لائبریریاں اور مثالیں ہیں جو آپ کو حقیقی دنیا کے لیے مکمل خصوصیات والی تقسیم شدہ ایپلیکیشنز بنانے میں مدد کرتی ہیں۔_** + +- [GitHub](https://github.com/HQ20/contracts) + +**thirdweb Solidity SDK -** **_کسٹم اسمارٹ معاہدوں کو موثر طریقے سے بنانے کے لیے درکار ٹولز فراہم کرتا ہے_** + +- [دستاویزات](https://portal.thirdweb.com/contracts/build/overview) +- [GitHub](https://github.com/thirdweb-dev/contracts) + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [Ethereum ڈیولپرز کے لیے سیکورٹی کے تحفظات](/developers/docs/smart-contracts/security/) _– اسمارٹ معاہدے بناتے وقت سیکورٹی کے تحفظات پر ایک ٹیوٹوریل، بشمول لائبریری کا استعمال۔_ +- [ERC-20 ٹوکن اسمارٹ معاہدے کو سمجھیں](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _-ERC20 معیار پر ٹیوٹوریل، جو متعدد لائبریریوں کے ذریعہ فراہم کیا گیا ہے۔_ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/smart-contracts/naming/index.md b/public/content/translations/ur/developers/docs/smart-contracts/naming/index.md new file mode 100644 index 00000000000..13def909b51 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/naming/index.md @@ -0,0 +1,101 @@ +--- +title: "اسمارٹ کنٹریکٹس کا نام رکھنا" +description: "ENS کے ساتھ Ethereum اسمارٹ کنٹریکٹس کا نام رکھنے کے بہترین طریقے" +lang: ur-in +--- + +اسمارٹ کنٹریکٹس Ethereum کے وکندریقرت انفراسٹرکچر کا ایک بنیادی ستون ہیں، جو خود مختار ایپلیکیشنز اور پروٹوکولز کو فعال کرتے ہیں۔ لیکن جیسے جیسے کنٹریکٹ کی صلاحیتیں تیار ہوتی ہیں، صارفین اور ڈیولپرز اب بھی ان کنٹریکٹس کی شناخت اور حوالہ دینے کے لیے خام ہیکساڈیسیمل پتوں پر انحصار کرتے ہیں۔ + +[Ethereum Name Service (ENS)](https://ens.domains/) کے ساتھ اسمارٹ کنٹریکٹس کا نام رکھنے سے ہیکسا ڈیسیمل کنٹریکٹ پتوں کو ختم کرکے صارف کے تجربے کو بہتر بنایا جاتا ہے اور ایڈریس پوائزننگ اور اسپوفنگ حملوں جیسے حملوں سے خطرہ کم ہوتا ہے۔ یہ گائیڈ بتاتا ہے کہ اسمارٹ کنٹریکٹس کا نام رکھنا کیوں اہمیت رکھتا ہے، اسے کیسے نافذ کیا جا سکتا ہے، اور اس عمل کو آسان بنانے اور ڈیولپرز کو اس عمل کو اپنانے میں مدد کرنے کے لیے [Enscribe](https://www.enscribe.xyz) جیسے ٹولز دستیاب ہیں۔ + +## اسمارٹ کنٹریکٹس کا نام کیوں رکھیں؟ {#why-name-contracts} + +### انسان کے پڑھنے کے قابل شناخت کنندہ {#human-readable-identifiers} + +`0x8f8e...f9e3` جیسے غیر واضح کنٹریکٹ پتوں کے ساتھ تعامل کرنے کے بجائے، ڈیولپرز اور صارفین `v2.myapp.eth` جیسے انسان کے پڑھنے کے قابل ناموں کا استعمال کر سکتے ہیں۔ یہ اسمارٹ کنٹریکٹ کے تعاملات کو آسان بناتا ہے۔ + +یہ [Ethereum Name Service](https://ens.domains/) کے ذریعے ممکن ہوا ہے جو Ethereum پتوں کے لیے ایک وکندریقرت نام رکھنے کی سروس فراہم کرتا ہے۔ یہ اس بات کے مترادف ہے کہ کس طرح ڈومین نیم سروس (DNS) انٹرنیٹ کے صارفین کو `104.18.176.152` جیسے IP ایڈریس کے بجائے ethereum.org جیسے نام کا استعمال کرتے ہوئے نیٹ ورک پتوں تک رسائی حاصل کرنے کے قابل بناتا ہے۔ + +### بہتر سیکیورٹی اور اعتماد {#improved-security-and-trust} + +نام والے کنٹریکٹس غلط پتے پر حادثاتی لین دین کو کم کرنے میں مدد کرتے ہیں۔ وہ صارفین کو مخصوص ایپس یا برانڈز سے منسلک کنٹریکٹس کی شناخت کرنے میں بھی مدد کرتے ہیں۔ یہ ساکھ کے اعتماد کی ایک پرت کا اضافہ کرتا ہے، خاص طور پر جب نام `uniswap.eth` جیسے معروف پیرنٹ ڈومینز سے منسلک ہوں۔ + +Ethereum ایڈریس کی 42-کریکٹر کی لمبائی کی وجہ سے، صارفین کے لیے پتوں میں چھوٹی تبدیلیوں کی شناخت کرنا بہت مشکل ہے، جہاں چند کریکٹرز میں ترمیم کی گئی ہو۔ مثال کے طور پر، `0x58068646C148E313CB414E85d2Fe89dDc3426870` جیسا پتہ عام طور پر والیٹس جیسی صارف پر مبنی ایپلیکیشنز کے ذریعے `0x580...870` تک مختصر کر دیا جاتا ہے۔ ایک صارف ممکنہ طور پر کسی نقصان دہ پتے کو نہیں دیکھ پائے گا جہاں چند کریکٹرز تبدیل کیے گئے ہوں۔ + +اس قسم کی تکنیک ایڈریس اسپوفنگ اور پوائزننگ حملوں میں استعمال کی جاتی ہے جہاں صارفین کو یہ یقین دلایا جاتا ہے کہ وہ صحیح پتے کے ساتھ تعامل کر رہے ہیں یا فنڈز بھیج رہے ہیں، جبکہ حقیقت میں وہ پتہ صرف صحیح پتے جیسا ہوتا ہے، لیکن وہی نہیں ہوتا۔ + +والیٹس اور کنٹریکٹس کے لیے ENS نام اس قسم کے حملوں سے بچاتے ہیں۔ DNS اسپوفنگ حملوں کی طرح، ENS اسپوفنگ حملے بھی کیے جا سکتے ہیں، تاہم، ایک صارف ہیکساڈیسیمل ایڈریس میں چھوٹی ترمیم کے مقابلے میں ENS نام میں ہجے کی غلطی کو زیادہ آسانی سے دیکھ سکتا ہے۔ + +### والیٹس اور ایکسپلوررز کے لیے بہتر UX {#better-ux} + +جب کسی اسمارٹ کنٹریکٹ کو ENS نام کے ساتھ کنفیگر کیا جاتا ہے، تو والیٹس اور بلاکچین ایکسپلوررز جیسی ایپس کے لیے ہیکساڈیسیمل پتوں کے بجائے اسمارٹ کنٹریکٹس کے لیے ENS نام دکھانا ممکن ہو جاتا ہے۔ یہ صارفین کے لیے صارف کے تجربے (UX) میں ایک اہم بہتری فراہم کرتا ہے۔ + +مثال کے طور پر، جب Uniswap جیسی کسی ایپ کے ساتھ تعامل کرتے ہیں، تو صارفین عام طور پر دیکھیں گے کہ جس ایپ کے ساتھ وہ تعامل کر رہے ہیں وہ ویب سائٹ `uniswap.org` پر ہوسٹ کی گئی ہے، لیکن اگر Uniswap نے اپنے اسمارٹ کنٹریکٹس کو ENS کے ساتھ نام نہیں دیا ہے تو انہیں ایک ہیکساڈیسیمل کنٹریکٹ ایڈریس پیش کیا جائے گا۔ اگر کنٹریکٹ کا نام رکھا گیا ہے، تو اس کے بجائے وہ `v4.contracts.uniswap.eth` دیکھ سکتے ہیں جو کہ بہت زیادہ مفید ہے۔ + +## ڈیپلائمنٹ کے وقت نام رکھنا بمقابلہ پوسٹ-ڈیپلائمنٹ {#when-to-name} + +دو ایسے نکات ہیں جن پر اسمارٹ کنٹریکٹس کا نام رکھا جا سکتا ہے: + +- **ڈیپلائمنٹ کے وقت**: کنٹریکٹ کو ڈیپلائے کرتے وقت اسے ایک ENS نام تفویض کرنا۔ +- **ڈیپلائمنٹ کے بعد**: موجودہ کنٹریکٹ ایڈریس کو ایک نئے ENS نام پر میپ کرنا۔ + +دونوں طریقوں میں ENS ڈومین تک مالک یا مینیجر کی رسائی پر انحصار کیا جاتا ہے تاکہ وہ ENS ریکارڈز بنا اور سیٹ کر سکیں۔ + +## کنٹریکٹس کے لیے ENS نام کیسے کام کرتا ہے {#how-ens-naming-works} + +ENS نام آن چین ذخیرہ کیے جاتے ہیں اور ENS حل کنندگان کے ذریعے Ethereum پتوں میں حل ہوتے ہیں۔ ایک اسمارٹ کنٹریکٹ کا نام رکھنے کے لیے: + +1. ایک پیرنٹ ENS ڈومین رجسٹر کریں یا کنٹرول کریں (مثلاً `myapp.eth`) +2. ایک سب ڈومین بنائیں (مثلاً `v1.myapp.eth`) +3. سب ڈومین کے `address` ریکارڈ کو کنٹریکٹ ایڈریس پر سیٹ کریں +4. کنٹریکٹ کے ریورس ریکارڈ کو ENS پر سیٹ کریں تاکہ نام کو اس کے پتے کے ذریعے تلاش کیا جا سکے + +ENS نام درجہ بندی پر مبنی ہیں اور لامحدود ذیلی ناموں کو سپورٹ کرتے ہیں۔ ان ریکارڈز کو سیٹ کرنے میں عام طور پر ENS رجسٹری اور پبلک ریزولور کنٹریکٹس کے ساتھ تعامل شامل ہوتا ہے۔ + +## کنٹریکٹس کا نام رکھنے کے لیے ٹولز {#tools} + +اسمارٹ کنٹریکٹس کا نام رکھنے کے دو طریقے ہیں۔ یا تو کچھ دستی اقدامات کے ساتھ [ENS App](https://app.ens.domains) کا استعمال کرتے ہوئے، یا [Enscribe](https://www.enscribe.xyz) کا استعمال کرتے ہوئے۔ ان کی تفصیل ذیل میں دی گئی ہے۔ + +### دستی ENS سیٹ اپ {#manual-ens-setup} + +[ENS App](https://app.ens.domains/) کا استعمال کرتے ہوئے، ڈیولپرز دستی طور پر ذیلی نام بنا سکتے ہیں اور فارورڈ ایڈریس ریکارڈ سیٹ کر سکتے ہیں۔ تاہم، وہ ENS ایپ کے ذریعے نام کے لیے ریورس ریکارڈ سیٹ کر کے اسمارٹ کنٹریکٹ کے لیے پرائمری نام سیٹ نہیں کر سکتے۔ دستی اقدامات اٹھائے جانے چاہئیں جن کا احاطہ [ENS docs](https://docs.ens.domains/web/naming-contracts/) میں کیا گیا ہے۔ + +### Enscribe {#enscribe} + +[Enscribe](https://www.enscribe.xyz) ENS کے ساتھ اسمارٹ کنٹریکٹ کا نام رکھنے کو آسان بناتا ہے، اور اسمارٹ کنٹریکٹس میں صارف کے اعتماد کو بڑھاتا ہے۔ یہ فراہم کرتا ہے: + +- **ایٹمی ڈیپلائمنٹ اور نام رکھنا**: نیا کنٹریکٹ ڈیپلائے کرتے وقت ایک ENS نام تفویض کریں +- **پوسٹ-ڈیپلائمنٹ نام رکھنا**: پہلے سے ڈیپلائے کیے گئے کنٹریکٹس کے ساتھ نام منسلک کریں +- **ملٹی چین سپورٹ**: Ethereum اور L2 نیٹ ورکس پر کام کرتا ہے جہاں ENS سپورٹ کیا جاتا ہے +- **کنٹریکٹ کی تصدیق کا ڈیٹا**: صارفین کے لیے اعتماد بڑھانے کے لیے متعدد ذرائع سے حاصل کردہ کنٹریکٹ کی تصدیق کا ڈیٹا شامل ہے + +Enscribe صارفین کے فراہم کردہ ENS ناموں، یا اگر صارف کے پاس ENS نام نہیں ہے تو اپنے ڈومینز کو سپورٹ کرتا ہے۔ + +آپ اسمارٹ کنٹریکٹس کا نام رکھنے اور دیکھنے کے لیے [Enscribe App](https://app.enscribe.xyz) تک رسائی حاصل کر سکتے ہیں۔ + +## بہترین طریقے {#best-practices} + +- **واضح، ورژن والے نام استعمال کریں** جیسے `v1.myapp.eth` تاکہ کنٹریکٹ اپ گریڈ کو شفاف بنایا جا سکے +- **ریورس ریکارڈز سیٹ کریں** تاکہ والیٹس اور بلاکچین ایکسپلوررز جیسی ایپس میں مرئیت کے لیے کنٹریکٹس کو ENS ناموں سے لنک کیا جا سکے۔ +- **میعاد ختم ہونے کی تاریخوں پر گہری نظر رکھیں** اگر آپ ملکیت میں حادثاتی تبدیلیوں کو روکنا چاہتے ہیں +- **کنٹریکٹ کا ماخذ تصدیق کریں** تاکہ صارفین بھروسہ کر سکیں کہ نام دیا گیا کنٹریکٹ توقع کے مطابق کام کرتا ہے + +## خطرات {#risks} + +اسمارٹ کنٹریکٹس کا نام رکھنا Ethereum کے صارفین کے لیے اہم فوائد فراہم کرتا ہے، تاہم، ENS ڈومینز کے مالکان کو ان کے انتظام کے حوالے سے محتاط رہنا چاہیے۔ قابل ذکر خطرات میں شامل ہیں: + +- **میعاد ختم ہونا**: بالکل DNS ناموں کی طرح، ENS ناموں کی رجسٹریشن محدود مدت کے لیے ہوتی ہے۔ لہذا یہ بہت ضروری ہے کہ مالکان اپنے ڈومینز کی میعاد ختم ہونے کی تاریخوں پر نظر رکھیں اور میعاد ختم ہونے سے بہت پہلے ان کی تجدید کریں۔ ENS ایپ اور Enscribe دونوں ڈومین مالکان کے لیے بصری اشارے فراہم کرتے ہیں جب میعاد ختم ہونے کا وقت قریب آتا ہے۔ +- **ملکیت میں تبدیلی**: ENS ریکارڈز Ethereum پر NFTs کے طور پر نمائندگی کرتے ہیں، جہاں ایک مخصوص `.eth` ڈومین کے مالک کے پاس متعلقہ NFT اس کے قبضے میں ہوتا ہے۔ لہذا اگر کوئی دوسرا اکاؤنٹ اس NFT کی ملکیت لے لیتا ہے، تو نیا مالک اپنی مرضی کے مطابق کسی بھی ENS ریکارڈ میں ترمیم کر سکتا ہے۔ + +اس طرح کے خطرات کو کم کرنے کے لیے، `.eth` 2nd لیول ڈومینز (2LD) کے مالک اکاؤنٹ کو ملٹی سگ والیٹ کے ذریعے محفوظ کیا جانا چاہیے اور کنٹریکٹ کے نام کے انتظام کے لیے سب ڈومینز بنائے جانے چاہئیں۔ اس طرح، سب ڈومین کی سطح پر ملکیت میں کسی بھی حادثاتی یا نقصان دہ تبدیلی کی صورت میں، انہیں 2LD مالک کے ذریعے اوور رائیڈ کیا جا سکتا ہے۔ + +## کنٹریکٹ نام رکھنے کا مستقبل {#future} + +کنٹریکٹ کا نام رکھنا dapp ڈیولپمنٹ کے لیے ایک بہترین طریقہ کار بنتا جا رہا ہے، اسی طرح جیسے ویب پر ڈومین ناموں نے IP پتوں کی جگہ لے لی تھی۔ جیسے جیسے والیٹس، ایکسپلوررز اور ڈیش بورڈز جیسے مزید انفراسٹرکچر کنٹریکٹس کے لیے ENS ریزولوشن کو مربوط کرتے ہیں، نام والے کنٹریکٹس پورے ایکو سسٹم میں حفاظت کو بہتر بنائیں گے اور غلطیوں کو کم کریں گے۔ + +اسمارٹ کنٹریکٹس کو پہچاننے اور ان کے بارے میں استدلال کرنے میں آسانی پیدا کر کے، نام رکھنا Ethereum پر صارفین اور ایپس کے درمیان فرق کو ختم کرنے میں مدد کرتا ہے، جس سے صارفین کے لیے حفاظت اور UX دونوں میں بہتری آتی ہے۔ + +## مزید پڑھیں {#further-reading} + +- [ENS کے ساتھ اسمارٹ کنٹریکٹس کا نام رکھنا](https://docs.ens.domains/web/naming-contracts/) +- [Enscribe کے ساتھ اسمارٹ کنٹریکٹس کا نام رکھنا](https://www.enscribe.xyz/docs)۔ diff --git a/public/content/translations/ur/developers/docs/smart-contracts/security/index.md b/public/content/translations/ur/developers/docs/smart-contracts/security/index.md new file mode 100644 index 00000000000..2fd5f507271 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/security/index.md @@ -0,0 +1,576 @@ +--- +title: "اسمارٹ کنٹریکٹ سیکیورٹی" +description: "محفوظ Ethereum اسمارٹ کنٹریکٹس بنانے کے لیے رہنما خطوط کا ایک جائزہ" +lang: ur-in +--- + +اسمارٹ کنٹریکٹس انتہائی لچکدار ہوتے ہیں، اور بڑی مقدار میں قدر اور ڈیٹا کو کنٹرول کرنے کی صلاحیت رکھتے ہیں، جبکہ بلاک چین پر تعینات کوڈ کی بنیاد پر ناقابل تغیر منطق چلاتے ہیں۔ اس نے بغیر اعتماد اور غیر مرکزی ایپلی کیشنز کا ایک متحرک ایکو سسٹم بنایا ہے جو پرانے سسٹمز کے مقابلے میں بہت سے فوائد فراہم کرتا ہے۔ یہ حملہ آوروں کے لیے بھی مواقع پیش کرتے ہیں جو اسمارٹ کنٹریکٹس میں کمزوریوں کا استحصال کرکے منافع کمانا چاہتے ہیں۔ + +عوامی بلاک چینز، جیسے Ethereum، اسمارٹ کنٹریکٹس کو محفوظ بنانے کے مسئلے کو مزید پیچیدہ بناتے ہیں۔ تعینات کردہ کنٹریکٹ کوڈ کو _عام طور پر_ سیکیورٹی خامیوں کو پیچ کرنے کے لیے تبدیل نہیں کیا جاسکتا، جبکہ اسمارٹ کنٹریکٹس سے چوری شدہ اثاثوں کو ٹریک کرنا انتہائی مشکل ہوتا ہے اور ناقابل تغیر ہونے کی وجہ سے زیادہ تر ناقابل بازیافت ہوتے ہیں۔ + +اگرچہ اعداد و شمار مختلف ہوتے ہیں، لیکن یہ اندازہ لگایا گیا ہے کہ اسمارٹ کنٹریکٹس میں سیکیورٹی نقائص کی وجہ سے چوری یا ضائع ہونے والی کل رقم آسانی سے 1 بلین ڈالر سے زیادہ ہے۔ [DAO ہیک](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3.6M ETH چوری ہوئے، آج کی قیمتوں میں $1B سے زیادہ)، [Parity ملٹی سِگ والیٹ ہیک](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) ($30M ہیکرز کے ہاتھوں ضائع ہوئے)، اور [Parity منجمد والیٹ کا مسئلہ](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) ($300M سے زیادہ ETH ہمیشہ کے لیے لاک ہو گئے)۔ + +مذکورہ بالا مسائل ڈیولپرز کے لیے محفوظ، مضبوط، اور لچکدار اسمارٹ کنٹریکٹس بنانے میں کوشش صرف کرنا لازمی بناتے ہیں۔ اسمارٹ کنٹریکٹ سیکیورٹی ایک سنجیدہ معاملہ ہے، اور ہر ڈیولپر کو اسے سیکھنا چاہئے۔ یہ گائیڈ Ethereum ڈیولپرز کے لیے سیکیورٹی کے تحفظات کا احاطہ کرے گا اور اسمارٹ کنٹریکٹ سیکیورٹی کو بہتر بنانے کے لیے وسائل کی کھوج کرے گا۔ + +## شرائط {#prerequisites} + +سیکیورٹی سے نمٹنے سے پہلے یقینی بنائیں کہ آپ [اسمارٹ کنٹریکٹ ڈیولپمنٹ کے بنیادی اصولوں](/developers/docs/smart-contracts/) سے واقف ہیں۔ + +## محفوظ Ethereum اسمارٹ کنٹریکٹس بنانے کے لیے رہنما خطوط {#smart-contract-security-guidelines} + +### 1۔ مناسب رسائی کنٹرولز ڈیزائن کریں {#design-proper-access-controls} + +اسمارٹ کنٹریکٹس میں، `public` یا `external` کے طور پر نشان زد فنکشنز کو کسی بھی بیرونی ملکیت والے اکاؤنٹس (EOAs) یا کنٹریکٹ اکاؤنٹس کے ذریعے کال کیا جاسکتا ہے۔ اگر آپ چاہتے ہیں کہ دوسرے آپ کے کنٹریکٹ کے ساتھ تعامل کریں تو فنکشنز کے لیے عوامی مرئیت کی وضاحت کرنا ضروری ہے۔ تاہم، `private` کے طور پر نشان زد فنکشنز کو صرف اسمارٹ کنٹریکٹ کے اندر موجود فنکشنز کے ذریعے کال کیا جاسکتا ہے، نہ کہ بیرونی اکاؤنٹس کے ذریعے۔ ہر نیٹ ورک شریک کو کنٹریکٹ فنکشنز تک رسائی دینا مسائل پیدا کرسکتا ہے، خاص طور پر اگر اس کا مطلب یہ ہے کہ کوئی بھی حساس آپریشنز (مثلاً، نئے ٹوکنز بنانا) انجام دے سکتا ہے۔ + +اسمارٹ کنٹریکٹ فنکشنز کے غیر مجاز استعمال کو روکنے کے لیے، محفوظ رسائی کنٹرولز کو نافذ کرنا ضروری ہے۔ رسائی کنٹرول میکانزم ایک اسمارٹ کنٹریکٹ میں کچھ فنکشنز کے استعمال کی صلاحیت کو منظور شدہ اداروں تک محدود کرتے ہیں، جیسے کہ کنٹریکٹ کا انتظام کرنے کے لیے ذمہ دار اکاؤنٹس۔ **Ownable پیٹرن** اور **کردار پر مبنی کنٹرول** اسمارٹ کنٹریکٹس میں رسائی کنٹرول کو نافذ کرنے کے لیے دو مفید پیٹرن ہیں: + +#### Ownable پیٹرن {#ownable-pattern} + +Ownable پیٹرن میں، کنٹریکٹ بنانے کے عمل کے دوران ایک ایڈریس کو کنٹریکٹ کے "مالک" کے طور پر سیٹ کیا جاتا ہے۔ محفوظ فنکشنز کو ایک `OnlyOwner` موڈیفائر تفویض کیا جاتا ہے، جو یقینی بناتا ہے کہ کنٹریکٹ فنکشن کو انجام دینے سے پہلے کال کرنے والے ایڈریس کی شناخت کی تصدیق کرے۔ کنٹریکٹ کے مالک کے علاوہ دوسرے ایڈریسز سے محفوظ فنکشنز پر کی جانے والی کالز ہمیشہ واپس ہو جاتی ہیں، جس سے غیر مطلوبہ رسائی کو روکا جاتا ہے۔ + +#### کردار پر مبنی رسائی کنٹرول {#role-based-access-control} + +ایک اسمارٹ کنٹریکٹ میں ایک ہی ایڈریس کو `Owner` کے طور پر رجسٹر کرنا مرکزیت کا خطرہ پیدا کرتا ہے اور ناکامی کے ایک واحد نقطہ کی نمائندگی کرتا ہے۔ اگر مالک کے اکاؤنٹ کیز سے سمجھوتہ ہو جاتا ہے، تو حملہ آور ملکیت والے کنٹریکٹ پر حملہ کر سکتے ہیں۔ یہی وجہ ہے کہ متعدد انتظامی اکاؤنٹس کے ساتھ کردار پر مبنی رسائی کنٹرول پیٹرن کا استعمال ایک بہتر آپشن ہوسکتا ہے۔ + +کردار پر مبنی رسائی کنٹرول میں، حساس فنکشنز تک رسائی قابل اعتماد شرکاء کے ایک سیٹ کے درمیان تقسیم کی جاتی ہے۔ مثال کے طور پر، ایک اکاؤنٹ ٹوکنز بنانے کا ذمہ دار ہوسکتا ہے، جبکہ دوسرا اکاؤنٹ اپ گریڈ کرتا ہے یا کنٹریکٹ کو روکتا ہے۔ اس طرح رسائی کنٹرول کو غیر مرکزی بنانے سے ناکامی کے واحد نکات ختم ہو جاتے ہیں اور صارفین کے لیے اعتماد کے مفروضات کم ہو جاتے ہیں۔ + +##### ملٹی سگنیچر والیٹس کا استعمال + +محفوظ رسائی کنٹرول کو نافذ کرنے کا ایک اور طریقہ کنٹریکٹ کا انتظام کرنے کے لیے [ملٹی سگنیچر اکاؤنٹ](/developers/docs/smart-contracts/#multisig) کا استعمال کرنا ہے۔ ایک باقاعدہ EOA کے برعکس، ملٹی سگنیچر اکاؤنٹس متعدد اداروں کی ملکیت ہوتے ہیں اور لین دین کو انجام دینے کے لیے کم از کم تعداد میں اکاؤنٹس — مثلاً 5 میں سے 3 — کے دستخطوں کی ضرورت ہوتی ہے۔ + +رسائی کنٹرول کے لیے ملٹی سگ کا استعمال سیکیورٹی کی ایک اضافی پرت کا اضافہ کرتا ہے کیونکہ ٹارگٹ کنٹریکٹ پر کارروائیوں کے لیے متعدد فریقوں کی رضامندی کی ضرورت ہوتی ہے۔ یہ خاص طور پر مفید ہے اگر Ownable پیٹرن کا استعمال ضروری ہو، کیونکہ یہ کسی حملہ آور یا بدمعاش اندرونی شخص کے لیے بدنیتی پر مبنی مقاصد کے لیے حساس کنٹریکٹ فنکشنز میں ہیرا پھیری کرنا زیادہ مشکل بنا دیتا ہے۔ + +### 2۔ کنٹریکٹ آپریشنز کی حفاظت کے لیے require(), assert(), اور revert() اسٹیٹمنٹس کا استعمال کریں {#use-require-assert-revert} + +جیسا کہ ذکر کیا گیا ہے، ایک بار جب آپ کا اسمارٹ کنٹریکٹ بلاک چین پر تعینات ہوجاتا ہے، تو کوئی بھی اس میں موجود عوامی فنکشنز کو کال کرسکتا ہے۔ چونکہ آپ پہلے سے یہ نہیں جان سکتے کہ بیرونی اکاؤنٹس کسی کنٹریکٹ کے ساتھ کیسے تعامل کریں گے، اس لیے تعیناتی سے پہلے پریشان کن آپریشنز کے خلاف اندرونی حفاظتی اقدامات نافذ کرنا مثالی ہے۔ آپ اسمارٹ کنٹریکٹس میں درست رویے کو نافذ کرنے کے لیے `require()`، `assert()`، اور `revert()` اسٹیٹمنٹس کا استعمال کرکے استثنیٰ کو متحرک کرسکتے ہیں اور اگر عمل درآمد کچھ ضروریات کو پورا کرنے میں ناکام رہتا ہے تو اسٹیٹ کی تبدیلیوں کو واپس کرسکتے ہیں۔ + +**`require()`**: `require` فنکشنز کے آغاز میں بیان کیے جاتے ہیں اور یقینی بناتے ہیں کہ کال کیے گئے فنکشن کو انجام دینے سے پہلے پہلے سے طے شدہ شرائط پوری ہوں۔ ایک `require` اسٹیٹمنٹ کا استعمال صارف کے ان پٹس کی توثیق کرنے، اسٹیٹ متغیرات کی جانچ کرنے، یا کسی فنکشن کے ساتھ آگے بڑھنے سے پہلے کال کرنے والے اکاؤنٹ کی شناخت کی تصدیق کرنے کے لیے کیا جاسکتا ہے۔ + +**`assert()`**: `assert()` کا استعمال اندرونی غلطیوں کا پتہ لگانے اور آپ کے کوڈ میں "invariants" کی خلاف ورزیوں کی جانچ کے لیے کیا جاتا ہے۔ ایک invariant کنٹریکٹ کی اسٹیٹ کے بارے میں ایک منطقی دعویٰ ہے جو تمام فنکشنز کے عمل درآمد کے لیے درست ہونا چاہئے۔ ایک invariant کی مثال ایک ٹوکن کنٹریکٹ کی زیادہ سے زیادہ کل سپلائی یا بیلنس ہے۔ `assert()` کا استعمال یقینی بناتا ہے کہ آپ کا کنٹریکٹ کبھی بھی کمزور اسٹیٹ تک نہ پہنچے، اور اگر ایسا ہوتا ہے، تو اسٹیٹ متغیرات میں تمام تبدیلیاں واپس لے لی جاتی ہیں۔ + +**`revert()`**: `revert()` کا استعمال if-else اسٹیٹمنٹ میں کیا جاسکتا ہے جو اگر مطلوبہ شرط پوری نہ ہو تو ایک استثنیٰ کو متحرک کرتا ہے۔ نیچے دیا گیا نمونہ کنٹریکٹ فنکشنز کے عمل درآمد کی حفاظت کے لیے `revert()` کا استعمال کرتا ہے: + +``` +pragma solidity ^0.8.4; + +contract VendingMachine { + address owner; + error Unauthorized(); + function buy(uint amount) public payable { + if (amount > msg.value / 2 ether) + revert("Not enough Ether provided."); + // Perform the purchase. + } + function withdraw() public { + if (msg.sender != owner) + revert Unauthorized(); + + payable(msg.sender).transfer(address(this).balance); + } +} +``` + +### 3۔ اسمارٹ کنٹریکٹس کی جانچ کریں اور کوڈ کی درستگی کی تصدیق کریں {#test-smart-contracts-and-verify-code-correctness} + +[Ethereum Virtual Machine](/developers/docs/evm/) میں چلنے والے کوڈ کی ناقابل تغیر نوعیت کا مطلب ہے کہ اسمارٹ کنٹریکٹس ڈیولپمنٹ کے مرحلے کے دوران اعلیٰ سطح کی کوالٹی کی تشخیص کا مطالبہ کرتے ہیں۔ اپنے کنٹریکٹ کی وسیع پیمانے پر جانچ کرنا اور کسی بھی غیر متوقع نتائج کے لیے اس کا مشاہدہ کرنا سیکیورٹی کو بہت بہتر بنائے گا اور طویل مدت میں آپ کے صارفین کی حفاظت کرے گا۔ + +عام طریقہ یہ ہے کہ موک ڈیٹا کا استعمال کرتے ہوئے چھوٹے یونٹ ٹیسٹ لکھے جائیں جس کے بارے میں کنٹریکٹ سے توقع کی جاتی ہے کہ وہ صارفین سے وصول کرے گا۔ [یونٹ ٹیسٹنگ](/developers/docs/smart-contracts/testing/#unit-testing) کچھ فنکشنز کی فعالیت کی جانچ کرنے اور یہ یقینی بنانے کے لیے اچھا ہے کہ اسمارٹ کنٹریکٹ توقع کے مطابق کام کرتا ہے۔ + +بدقسمتی سے، جب الگ تھلگ استعمال کیا جائے تو یونٹ ٹیسٹنگ اسمارٹ کنٹریکٹ سیکیورٹی کو بہتر بنانے کے لیے کم سے کم مؤثر ہے۔ ایک یونٹ ٹیسٹ یہ ثابت کرسکتا ہے کہ ایک فنکشن موک ڈیٹا کے لیے صحیح طریقے سے عمل درآمد کرتا ہے، لیکن یونٹ ٹیسٹ صرف اتنے ہی مؤثر ہوتے ہیں جتنے ٹیسٹ لکھے جاتے ہیں۔ اس سے ان چھوٹی ہوئی ایج کیسز اور کمزوریوں کا پتہ لگانا مشکل ہو جاتا ہے جو آپ کے اسمارٹ کنٹریکٹ کی حفاظت کو توڑ سکتی ہیں۔ + +ایک بہتر طریقہ یہ ہے کہ یونٹ ٹیسٹنگ کو [اسٹیٹک اور ڈائنامک تجزیہ](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) کا استعمال کرتے ہوئے کیے گئے پراپرٹی پر مبنی ٹیسٹنگ کے ساتھ ملایا جائے۔ اسٹیٹک تجزیہ قابل رسائی پروگرام اسٹیٹس اور عمل درآمد کے راستوں کا تجزیہ کرنے کے لیے نچلی سطح کی نمائندگیوں پر انحصار کرتا ہے، جیسے [کنٹرول فلو گراف](https://en.wikipedia.org/wiki/Control-flow_graph) اور [ایبسٹریکٹ سنٹیکس ٹریز](https://deepsource.io/glossary/ast/) دریں اثنا، ڈائنامک تجزیہ کی تکنیکیں، جیسے [اسمارٹ کنٹریکٹ فزنگ](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry)، سیکیورٹی خصوصیات کی خلاف ورزی کرنے والے آپریشنز کا پتہ لگانے کے لیے بے ترتیب ان پٹ ویلیوز کے ساتھ کنٹریکٹ کوڈ کو عمل درآمد کرتی ہیں۔ + +[رسمی تصدیق](/developers/docs/smart-contracts/formal-verification) اسمارٹ کنٹریکٹس میں سیکیورٹی خصوصیات کی تصدیق کے لیے ایک اور تکنیک ہے۔ باقاعدہ ٹیسٹنگ کے برعکس، رسمی تصدیق ایک اسمارٹ کنٹریکٹ میں غلطیوں کی عدم موجودگی کو حتمی طور پر ثابت کر سکتی ہے۔ یہ ایک رسمی تفصیلات بنا کر حاصل کیا جاتا ہے جو مطلوبہ سیکیورٹی خصوصیات کو حاصل کرتی ہے اور یہ ثابت کرتی ہے کہ کنٹریکٹس کا ایک رسمی ماڈل اس تفصیلات پر عمل کرتا ہے۔ + +### 4. اپنے کوڈ کا ایک آزاد جائزہ طلب کریں {#get-independent-code-reviews} + +اپنے کنٹریکٹ کی جانچ کے بعد، دوسروں سے سورس کوڈ کو کسی بھی سیکیورٹی مسئلے کے لیے چیک کرنے کو کہنا اچھا ہے۔ ٹیسٹنگ ایک اسمارٹ کنٹریکٹ میں ہر خامی کو بے نقاب نہیں کرے گی، لیکن ایک آزاد جائزہ حاصل کرنا کمزوریوں کو پہچاننے کے امکان کو بڑھاتا ہے۔ + +#### آڈٹس {#audits} + +اسمارٹ کنٹریکٹ آڈٹ کا حکم دینا ایک آزاد کوڈ کا جائزہ لینے کا ایک طریقہ ہے۔ آڈیٹرز اس بات کو یقینی بنانے میں ایک اہم کردار ادا کرتے ہیں کہ اسمارٹ کنٹریکٹس محفوظ ہوں اور کوالٹی کے نقائص اور ڈیزائن کی غلطیوں سے پاک ہوں۔ + +اس کے باوجود، آپ کو آڈٹ کو جادو کی چھڑی سمجھنے سے گریز کرنا چاہئے۔ اسمارٹ کنٹریکٹ آڈٹس ہر بگ کو نہیں پکڑیں گے اور زیادہ تر جائزوں کا ایک اضافی دور فراہم کرنے کے لیے ڈیزائن کیے گئے ہیں، جو ابتدائی ڈیولپمنٹ اور ٹیسٹنگ کے دوران ڈیولپرز کی طرف سے چھوٹ جانے والے مسائل کا پتہ لگانے میں مدد کرسکتے ہیں۔ آپ کو آڈیٹرز کے ساتھ کام کرنے کے لیے بہترین طریقوں پر بھی عمل کرنا چاہئے، جیسے کہ کوڈ کو صحیح طریقے سے دستاویز کرنا اور ان لائن تبصرے شامل کرنا، تاکہ اسمارٹ کنٹریکٹ آڈٹ کے فائدے کو زیادہ سے زیادہ کیا جاسکے۔ + +- [اسمارٹ کنٹریکٹ آڈٹ کرنے کی تجاویز اور ترکیبیں](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_ +- [اپنے آڈٹ سے زیادہ سے زیادہ فائدہ اٹھائیں](https://inference.ag/blog/2023-08-14-tips/) - _Inference_ + +#### بگ باؤنٹیز {#bug-bounties} + +ایک بگ باؤنٹی پروگرام قائم کرنا بیرونی کوڈ جائزوں کو نافذ کرنے کا ایک اور طریقہ ہے۔ ایک بگ باؤنٹی ایک مالی انعام ہے جو ان افراد (عام طور پر وائٹ ہیٹ ہیکرز) کو دیا جاتا ہے جو کسی ایپلی کیشن میں کمزوریوں کا پتہ لگاتے ہیں۔ + +جب صحیح طریقے سے استعمال کیا جائے تو، بگ باؤنٹیز ہیکر کمیونٹی کے اراکین کو آپ کے کوڈ کا اہم خامیوں کے لیے معائنہ کرنے کی ترغیب دیتی ہیں۔ ایک حقیقی زندگی کی مثال "لامحدود رقم کا بگ" ہے جو ایک حملہ آور کو [Optimism](https://www.optimism.io/) پر لامحدود مقدار میں ایتھر بنانے کی اجازت دیتا، جو Ethereum پر چلنے والا ایک [لیئر 2](/layer-2/) پروٹوکول ہے۔ خوش قسمتی سے، ایک وائٹ ہیٹ ہیکر نے [خامی کا پتہ لگایا](https://www.saurik.com/optimism.html) اور ٹیم کو مطلع کیا، [اس عمل میں ایک بڑی ادائیگی حاصل کی](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/)۔ + +ایک مفید حکمت عملی یہ ہے کہ بگ باؤنٹی پروگرام کی ادائیگی کو داؤ پر لگی رقم کے تناسب سے مقرر کیا جائے۔ جسے "[اسکیلنگ بگ باؤنٹی](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)" کے طور پر بیان کیا گیا ہے، یہ طریقہ افراد کو کمزوریوں کا استحصال کرنے کے بجائے ذمہ داری سے انکشاف کرنے کے لیے مالی ترغیبات فراہم کرتا ہے۔ + +### 5. اسمارٹ کنٹریکٹ ڈیولپمنٹ کے دوران بہترین طریقوں پر عمل کریں {#follow-smart-contract-development-best-practices} + +آڈٹس اور بگ باؤنٹیز کا وجود اعلیٰ معیار کا کوڈ لکھنے کی آپ کی ذمہ داری سے بری نہیں کرتا۔ اچھی اسمارٹ کنٹریکٹ سیکیورٹی مناسب ڈیزائن اور ڈیولپمنٹ کے عمل پر عمل کرنے سے شروع ہوتی ہے: + +- تمام کوڈ کو ایک ورژن کنٹرول سسٹم میں اسٹور کریں، جیسے کہ git + +- تمام کوڈ میں ترمیمات پل ریکویسٹس کے ذریعے کریں + +- یقینی بنائیں کہ پل ریکویسٹس کا کم از کم ایک آزاد جائزہ لینے والا ہو—اگر آپ کسی پروجیکٹ پر اکیلے کام کررہے ہیں، تو دوسرے ڈیولپرز کو تلاش کرنے اور کوڈ کے جائزوں کا تبادلہ کرنے پر غور کریں۔ + +- اسمارٹ کنٹریکٹس کی جانچ، کمپائلنگ، اور تعیناتی کے لیے ایک [ڈیولپمنٹ ماحول](/developers/docs/frameworks/) کا استعمال کریں۔ + +- اپنے کوڈ کو بنیادی کوڈ تجزیہ کے ٹولز، جیسے [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn)، Mythril اور Slither کے ذریعے چلائیں۔ مثالی طور پر، آپ کو یہ ہر پل ریکویسٹ کے ضم ہونے سے پہلے کرنا چاہئے اور آؤٹ پٹ میں فرق کا موازنہ کرنا چاہئے۔ + +- یقینی بنائیں کہ آپ کا کوڈ بغیر کسی غلطی کے کمپائل ہو، اور Solidity کمپائلر کوئی انتباہ جاری نہ کرے۔ + +- اپنے کوڈ کو صحیح طریقے سے دستاویز کریں ([NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html) کا استعمال کرتے ہوئے) اور کنٹریکٹ کے فن تعمیر کے بارے میں تفصیلات کو سمجھنے میں آسان زبان میں بیان کریں۔ اس سے دوسروں کے لیے آپ کے کوڈ کا آڈٹ اور جائزہ لینا آسان ہو جائے گا۔ + +### 6. مضبوط ڈیزاسٹر ریکوری پلانز نافذ کریں {#implement-disaster-recovery-plans} + +محفوظ رسائی کنٹرولز ڈیزائن کرنا، فنکشن موڈیفائرز نافذ کرنا، اور دیگر تجاویز اسمارٹ کنٹریکٹ سیکیورٹی کو بہتر بناسکتی ہیں، لیکن وہ بدنیتی پر مبنی استحصال کے امکان کو رد نہیں کرسکتیں۔ محفوظ اسمارٹ کنٹریکٹس بنانے کے لیے "ناکامی کے لیے تیار رہنا" اور حملوں کا مؤثر طریقے سے جواب دینے کے لیے ایک فال بیک پلان کا ہونا ضروری ہے۔ ایک مناسب ڈیزاسٹر ریکوری پلان میں درج ذیل میں سے کچھ یا تمام اجزاء شامل ہوں گے: + +#### کنٹریکٹ اپ گریڈز {#contract-upgrades} + +جبکہ Ethereum اسمارٹ کنٹریکٹس پہلے سے ناقابل تغیر ہوتے ہیں، اپ گریڈ پیٹرن کا استعمال کرکے کچھ حد تک تغیر پذیری حاصل کرنا ممکن ہے۔ کنٹریکٹس کو اپ گریڈ کرنا ان صورتوں میں ضروری ہے جہاں ایک اہم خامی آپ کے پرانے کنٹریکٹ کو ناقابل استعمال بنا دیتی ہے اور نئی منطق کو تعینات کرنا سب سے زیادہ قابل عمل آپشن ہوتا ہے۔ + +کنٹریکٹ اپ گریڈ میکانزم مختلف طریقے سے کام کرتے ہیں، لیکن "پراکسی پیٹرن" اسمارٹ کنٹریکٹس کو اپ گریڈ کرنے کے لیے زیادہ مقبول طریقوں میں سے ایک ہے۔ [پراکسی پیٹرن](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) ایک ایپلی کیشن کی اسٹیٹ اور منطق کو _دو_ کنٹریکٹس کے درمیان تقسیم کرتے ہیں۔ پہلا کنٹریکٹ (جسے 'پراکسی کنٹریکٹ' کہا جاتا ہے) اسٹیٹ متغیرات (مثلاً، صارف کے بیلنس) کو اسٹور کرتا ہے، جبکہ دوسرا کنٹریکٹ (جسے 'لاجک کنٹریکٹ' کہا جاتا ہے) کنٹریکٹ فنکشنز کو انجام دینے کے لیے کوڈ رکھتا ہے۔ + +اکاؤنٹس پراکسی کنٹریکٹ کے ساتھ تعامل کرتے ہیں، جو [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) لو-لیول کال کا استعمال کرکے تمام فنکشن کالز کو لاجک کنٹریکٹ پر بھیجتا ہے۔ ایک باقاعدہ میسیج کال کے برعکس، `delegatecall()` یقینی بناتا ہے کہ لاجک کنٹریکٹ کے ایڈریس پر چلنے والا کوڈ کال کرنے والے کنٹریکٹ کے سیاق و سباق میں انجام دیا جائے۔ اس کا مطلب ہے کہ لاجک کنٹریکٹ ہمیشہ پراکسی کے اسٹوریج میں لکھے گا (بجائے اپنے اسٹوریج کے) اور `msg.sender` اور `msg.value` کی اصل قدریں محفوظ رہتی ہیں۔ + +لاجک کنٹریکٹ پر کالز کو ڈیلیگیٹ کرنے کے لیے اس کے ایڈریس کو پراکسی کنٹریکٹ کے اسٹوریج میں اسٹور کرنے کی ضرورت ہوتی ہے۔ اس لیے، کنٹریکٹ کی منطق کو اپ گریڈ کرنا صرف ایک اور لاجک کنٹریکٹ کو تعینات کرنے اور نئے ایڈریس کو پراکسی کنٹریکٹ میں اسٹور کرنے کا معاملہ ہے۔ چونکہ پراکسی کنٹریکٹ پر بعد کی کالز خود بخود نئے لاجک کنٹریکٹ پر بھیج دی جاتی ہیں، آپ نے دراصل کوڈ میں ترمیم کیے بغیر کنٹریکٹ کو "اپ گریڈ" کر لیا ہوگا۔ + +[معاہدوں کو اپ گریڈ کرنے پر مزید](/developers/docs/smart-contracts/upgrading/). + +#### ایمرجنسی اسٹاپس {#emergency-stops} + +جیسا کہ ذکر کیا گیا ہے، وسیع پیمانے پر آڈیٹنگ اور ٹیسٹنگ کسی اسمارٹ معاہدے میں موجود تمام بگز کو ممکنہ طور پر دریافت نہیں کر سکتی ہے۔ اگر تعیناتی کے بعد آپ کے کوڈ میں کوئی کمزوری ظاہر ہوتی ہے تو اسے پیچ کرنا ناممکن ہے کیونکہ آپ معاہدے کے پتے پر چلنے والے کوڈ کو تبدیل نہیں کر سکتے۔ اس کے علاوہ، اپ گریڈ میکانزم (مثلاً، پراکسی پیٹرن) کو نافذ کرنے میں وقت لگ سکتا ہے (ان کے لیے اکثر مختلف فریقوں سے منظوری درکار ہوتی ہے)، جس سے حملہ آوروں کو مزید نقصان پہنچانے کے لیے مزید وقت مل جاتا ہے۔ + +آخری آپشن ایک "ایمرجنسی اسٹاپ" فنکشن کو نافذ کرنا ہے جو کسی معاہدے میں کمزور فنکشنز کی کالز کو بلاک کرتا ہے۔ ایمرجنسی اسٹاپس میں عام طور پر درج ذیل اجزاء شامل ہوتے ہیں: + +1. ایک عالمی بولین متغیر جو اس بات کی نشاندہی کرتا ہے کہ آیا اسمارٹ معاہدہ رکی ہوئی حالت میں ہے یا نہیں۔ معاہدہ ترتیب دیتے وقت یہ متغیر `false` پر سیٹ ہوتا ہے، لیکن معاہدہ رک جانے کے بعد `true` پر واپس آجاتا ہے۔ + +2. وہ فنکشنز جو اپنے نفاذ میں بولین متغیر کا حوالہ دیتے ہیں۔ اس طرح کے فنکشنز اس وقت قابل رسائی ہوتے ہیں جب اسمارٹ معاہدہ روکا نہیں جاتا، اور جب ایمرجنسی اسٹاپ فیچر شروع ہو جاتا ہے تو ناقابل رسائی ہو جاتے ہیں۔ + +3. ایک ایسی ہستی جس کی ایمرجنسی اسٹاپ فنکشن تک رسائی ہو، جو بولین متغیر کو `true` پر سیٹ کرتی ہے۔ بدنیتی پر مبنی کارروائیوں کو روکنے کے لیے، اس فنکشن کی کالز کو ایک قابل اعتماد پتے (مثلاً، معاہدے کا مالک) تک محدود کیا جا سکتا ہے۔ + +ایک بار جب معاہدہ ایمرجنسی اسٹاپ کو فعال کر دیتا ہے، تو کچھ فنکشنز قابلِ کال نہیں رہیں گے۔ یہ منتخب فنکشنز کو ایک موڈیفائر میں لپیٹ کر حاصل کیا جاتا ہے جو عالمی متغیر کا حوالہ دیتا ہے۔ ذیل میں [ایک مثال](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) ہے جو معاہدوں میں اس پیٹرن کے نفاذ کو بیان کرتی ہے: + +```solidity +// اس کوڈ کا پیشہ ورانہ طور پر آڈٹ نہیں کیا گیا ہے اور یہ حفاظت یا درستگی کے بارے میں کوئی وعدہ نہیں کرتا ہے۔ اپنے رسک پر استعمال کریں۔ + +contract EmergencyStop { + + bool isStopped = false; + + modifier stoppedInEmergency { + require(!isStopped); + _; + } + + modifier onlyWhenStopped { + require(isStopped); + _; + } + + modifier onlyAuthorized { + // یہاں msg.sender کی اجازت کی جانچ کریں + _; + } + + function stopContract() public onlyAuthorized { + isStopped = true; + } + + function resumeContract() public onlyAuthorized { + isStopped = false; + } + + function deposit() public payable stoppedInEmergency { + // یہاں ڈپازٹ کی منطق ہو رہی ہے + } + + function emergencyWithdraw() public onlyWhenStopped { + // یہاں ایمرجنسی ودڈرال ہو رہا ہے + } +} +``` + +یہ مثال ایمرجنسی اسٹاپس کی بنیادی خصوصیات کو ظاہر کرتی ہے: + +- `isStopped` ایک بولین ہے جو شروع میں `false` اور جب معاہدہ ایمرجنسی موڈ میں داخل ہوتا ہے تو `true` کا جائزہ لیتا ہے۔ + +- فنکشن موڈیفائرز `onlyWhenStopped` اور `stoppedInEmergency` متغیر `isStopped` کی جانچ کرتے ہیں۔ `stoppedInEmergency` کا استعمال ان فنکشنز کو کنٹرول کرنے کے لیے کیا جاتا ہے جو معاہدے کے کمزور ہونے پر ناقابل رسائی ہونے چاہئیں (مثلاً، `deposit()`)۔ ان فنکشنز کی کالز بس واپس ہو جائیں گی۔ + +`onlyWhenStopped` کا استعمال ان فنکشنز کے لیے کیا جاتا ہے جو ایمرجنسی کے دوران قابلِ کال ہونے چاہئیں (مثلاً، `emergencyWithdraw()`)۔ اس طرح کے فنکشنز صورت حال کو حل کرنے میں مدد کر سکتے ہیں، لہذا انہیں "محدود فنکشنز" کی فہرست سے خارج کیا گیا ہے۔ + +ایمرجنسی اسٹاپ کی فعالیت کا استعمال آپ کے اسمارٹ معاہدے میں سنگین کمزوریوں سے نمٹنے کے لیے ایک موثر اسٹاپ گیپ فراہم کرتا ہے۔ تاہم، یہ صارفین کے لیے ڈیولپرز پر بھروسہ کرنے کی ضرورت کو بڑھاتا ہے کہ وہ اسے خود غرضی پر مبنی وجوہات کی بنا پر فعال نہ کریں۔ اس مقصد کے لیے، ایمرجنسی اسٹاپ کے کنٹرول کو یا تو آن چین ووٹنگ میکانزم، ٹائم لاک، یا ملٹی سگ والیٹ سے منظوری کے تابع کرکے غیر مرکزی بنانا ممکنہ حل ہیں۔ + +#### ایونٹ کی نگرانی {#event-monitoring} + +[ایونٹس](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) آپ کو اسمارٹ معاہدہ فنکشنز کی کالز کو ٹریک کرنے اور اسٹیٹ متغیرات میں تبدیلیوں کی نگرانی کرنے کی اجازت دیتے ہیں۔ یہ مثالی ہے کہ آپ اپنے اسمارٹ معاہدے کو ایک ایونٹ خارج کرنے کے لیے پروگرام کریں جب بھی کوئی فریق حفاظت کے لیے اہم کارروائی کرتا ہے (مثلاً، فنڈز نکالنا)۔ + +ایونٹس کو لاگ کرنا اور ان کی آف چین نگرانی کرنا معاہدے کے آپریشنز کے بارے میں بصیرت فراہم کرتا ہے اور بدنیتی پر مبنی کارروائیوں کی تیز تر دریافت میں مدد کرتا ہے۔ اس کا مطلب ہے کہ آپ کی ٹیم ہیکس کا تیزی سے جواب دے سکتی ہے اور صارفین پر پڑنے والے اثرات کو کم کرنے کے لیے کارروائی کر سکتی ہے، جیسے کہ فنکشنز کو روکنا یا اپ گریڈ کرنا۔ + +آپ ایک آف دی شیلف مانیٹرنگ ٹول کا بھی انتخاب کر سکتے ہیں جو جب بھی کوئی آپ کے معاہدوں کے ساتھ تعامل کرتا ہے تو خود بخود الرٹس بھیجتا ہے۔ یہ ٹولز آپ کو مختلف ٹرگرز کی بنیاد پر حسب ضرورت الرٹس بنانے کی اجازت دیں گے، جیسے کہ ٹرانزیکشن کا حجم، فنکشن کالز کی فریکوئنسی، یا اس میں شامل مخصوص فنکشنز۔ مثال کے طور پر، آپ ایک ایسا الرٹ پروگرام کر سکتے ہیں جو اس وقت آئے جب ایک ہی ٹرانزیکشن میں نکالی گئی رقم ایک خاص حد سے تجاوز کر جائے۔ + +### 7. محفوظ گورننس سسٹمز ڈیزائن کریں {#design-secure-governance-systems} + +آپ اپنی ایپلیکیشن کو بنیادی اسمارٹ معاہدوں کا کنٹرول کمیونٹی کے اراکین کو سونپ کر غیر مرکزی بنانا چاہ سکتے ہیں۔ اس صورت میں، اسمارٹ کنٹریکٹ سسٹم میں ایک گورننس ماڈیول شامل ہوگا—ایک ایسا میکانزم جو کمیونٹی کے اراکین کو آن چین گورننس سسٹم کے ذریعے انتظامی کارروائیوں کی منظوری دینے کی اجازت دیتا ہے۔ مثال کے طور پر، ایک پراکسی کنٹریکٹ کو ایک نئی عمل درآمد میں اپ گریڈ کرنے کی تجویز پر ٹوکن ہولڈرز کے ذریعے ووٹ دیا جاسکتا ہے۔ + +غیر مرکزی گورننس فائدہ مند ہوسکتی ہے، خاص طور پر کیونکہ یہ ڈیولپرز اور آخری صارفین کے مفادات کو ہم آہنگ کرتی ہے۔ اس کے باوجود، اگر غلط طریقے سے نافذ کیا جائے تو اسمارٹ کنٹریکٹ گورننس میکانزم نئے خطرات پیدا کرسکتے ہیں۔ ایک قابل فہم منظر نامہ یہ ہے کہ اگر کوئی حملہ آور [فلیش لون](/defi/#flash-loans) لے کر بے پناہ ووٹنگ پاور (منعقدہ ٹوکنز کی تعداد میں ماپا جاتا ہے) حاصل کرلے اور ایک بدنیتی پر مبنی تجویز کو آگے بڑھائے۔ + +آن چین گورننس سے متعلق مسائل کو روکنے کا ایک طریقہ [ٹائم لاک کا استعمال](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/) ہے۔ ایک ٹائم لاک ایک اسمارٹ کنٹریکٹ کو کچھ کارروائیوں کو انجام دینے سے روکتا ہے جب تک کہ ایک مخصوص مدت گزر نہ جائے۔ دیگر حکمت عملیوں میں ہر ٹوکن کو اس بنیاد پر "ووٹنگ ویٹ" تفویض کرنا شامل ہے کہ اسے کتنے عرصے تک لاک کیا گیا ہے، یا موجودہ بلاک کے بجائے ایک تاریخی مدت (مثال کے طور پر، ماضی میں 2-3 بلاکس) میں کسی ایڈریس کی ووٹنگ پاور کی پیمائش کرنا۔ دونوں طریقے آن چین ووٹس کو متاثر کرنے کے لیے تیزی سے ووٹنگ پاور جمع کرنے کے امکان کو کم کرتے ہیں۔ + +مشترکہ لنکس میں [محفوظ گورننس سسٹمز ڈیزائن کرنے](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/)، [DAOs میں مختلف ووٹنگ میکانزم](https://hackernoon.com/governance-is-the-holy-grail-for-daos)، اور [DeFi کا فائدہ اٹھاتے ہوئے عام DAO حملے کے ویکٹرز](https://dacian.me/dao-governance-defi-attacks) کے بارے میں مزید۔ + +### 8۔ کوڈ میں پیچیدگی کو کم سے کم کریں {#reduce-code-complexity} + +روایتی سافٹ ویئر ڈیولپرز KISS (“اسے سادہ رکھو، بے وقوف”) اصول سے واقف ہیں، جو سافٹ ویئر ڈیزائن میں غیر ضروری پیچیدگی متعارف کرانے کے خلاف مشورہ دیتا ہے۔ یہ اس دیرینہ سوچ کی پیروی کرتا ہے کہ "پیچیدہ نظام پیچیدہ طریقوں سے ناکام ہوتے ہیں" اور مہنگی غلطیوں کے لیے زیادہ حساس ہوتے ہیں۔ + +اسمارٹ کنٹریکٹس لکھتے وقت چیزوں کو سادہ رکھنا خاص اہمیت کا حامل ہے، اس بات کو مدنظر رکھتے ہوئے کہ اسمارٹ کنٹریکٹس ممکنہ طور پر بڑی مقدار میں قدر کو کنٹرول کررہے ہیں۔ اسمارٹ کنٹریکٹس لکھتے وقت سادگی حاصل کرنے کے لیے ایک ٹپ یہ ہے کہ جہاں ممکن ہو موجودہ لائبریریوں، جیسے کہ [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)، کا دوبارہ استعمال کریں۔ چونکہ ان لائبریریوں کا ڈیولپرز کے ذریعے وسیع پیمانے پر آڈٹ اور ٹیسٹ کیا گیا ہے، ان کا استعمال شروع سے نئی فعالیت لکھ کر بگز متعارف کرانے کے امکانات کو کم کرتا ہے۔ + +ایک اور عام مشورہ یہ ہے کہ چھوٹے فنکشنز لکھیں اور کاروباری منطق کو متعدد کنٹریکٹس میں تقسیم کرکے کنٹریکٹس کو ماڈیولر رکھیں۔ سادہ کوڈ لکھنا نہ صرف ایک اسمارٹ کنٹریکٹ میں حملے کی سطح کو کم کرتا ہے، بلکہ یہ مجموعی نظام کی درستگی کے بارے میں استدلال کرنا اور ممکنہ ڈیزائن کی غلطیوں کا جلد پتہ لگانا بھی آسان بناتا ہے۔ + +### 9۔ عام اسمارٹ کنٹریکٹ کی کمزوریوں سے دفاع کریں {#mitigate-common-smart-contract-vulnerabilities} + +#### دوبارہ داخلہ {#reentrancy} + +EVM ہم آہنگی کی اجازت نہیں دیتا، جس کا مطلب ہے کہ ایک میسیج کال میں شامل دو کنٹریکٹس بیک وقت نہیں چل سکتے۔ ایک بیرونی کال کالنگ کنٹریکٹ کے عمل درآمد اور میموری کو اس وقت تک روک دیتی ہے جب تک کہ کال واپس نہ آجائے، جس کے بعد عمل درآمد معمول کے مطابق آگے بڑھتا ہے۔ اس عمل کو رسمی طور پر دوسرے کنٹریکٹ میں [کنٹرول فلو](https://www.computerhope.com/jargon/c/contflow.htm) کی منتقلی کے طور پر بیان کیا جاسکتا ہے۔ + +اگرچہ زیادہ تر بے ضرر ہے، لیکن ناقابل اعتماد کنٹریکٹس میں کنٹرول فلو کی منتقلی مسائل پیدا کرسکتی ہے، جیسے کہ دوبارہ داخلہ۔ دوبارہ داخلے کا حملہ اس وقت ہوتا ہے جب ایک بدنیتی پر مبنی کنٹریکٹ اصل فنکشن کی درخواست مکمل ہونے سے پہلے ایک کمزور کنٹریکٹ میں واپس کال کرتا ہے۔ اس قسم کے حملے کو ایک مثال سے بہترین طور پر سمجھایا جاسکتا ہے۔ + +ایک سادہ اسمارٹ کنٹریکٹ ('Victim') پر غور کریں جو کسی کو بھی ایتھر جمع کرنے اور نکالنے کی اجازت دیتا ہے: + +```solidity +// یہ کنٹریکٹ کمزور ہے۔ پروڈکشن میں استعمال نہ کریں۔ + +contract Victim { + mapping (address => uint256) public balances; + + function deposit() external payable { + balances[msg.sender] += msg.value; + } + + function withdraw() external { + uint256 amount = balances[msg.sender]; + (bool success, ) = msg.sender.call.value(amount)(""); + require(success); + balances[msg.sender] = 0; + } +} +``` + +یہ کنٹریکٹ صارفین کو کنٹریکٹ میں پہلے سے جمع شدہ ETH نکالنے کی اجازت دینے کے لیے ایک `withdraw()` فنکشن فراہم کرتا ہے۔ نکالنے کی کارروائی کرتے وقت، کنٹریکٹ درج ذیل آپریشنز انجام دیتا ہے: + +1. صارف کا ETH بیلنس چیک کرتا ہے +2. کال کرنے والے ایڈریس پر فنڈز بھیجتا ہے +3. ان کا بیلنس 0 پر ری سیٹ کرتا ہے، صارف سے مزید نکالنے کو روکتا ہے + +`Victim` کنٹریکٹ میں `withdraw()` فنکشن "چیکس-انٹریکشنز-ایفیکٹس" پیٹرن کی پیروی کرتا ہے۔ یہ _چیک_ کرتا ہے کہ آیا عمل درآمد کے لیے ضروری شرائط پوری ہوئی ہیں (یعنی، صارف کا مثبت ETH بیلنس ہے) اور کالر کے ایڈریس پر ETH بھیج کر _انٹریکشن_ انجام دیتا ہے، اس سے پہلے کہ لین دین کے _اثرات_ کو لاگو کرے (یعنی، صارف کا بیلنس کم کرنا)۔ + +اگر `withdraw()` کو ایک بیرونی ملکیت والے اکاؤنٹ (EOA) سے کال کیا جاتا ہے، تو فنکشن توقع کے مطابق عمل درآمد کرتا ہے: `msg.sender.call.value()` کالر کو ETH بھیجتا ہے۔ تاہم، اگر `msg.sender` ایک اسمارٹ کنٹریکٹ اکاؤنٹ ہے جو `withdraw()` کو کال کرتا ہے، تو `msg.sender.call.value()` کا استعمال کرکے فنڈز بھیجنا اس ایڈریس پر اسٹور کردہ کوڈ کو بھی چلائے گا۔ + +تصور کریں کہ یہ کوڈ کنٹریکٹ ایڈریس پر تعینات ہے: + +```solidity + contract Attacker { + function beginAttack() external payable { + Victim(victim_address).deposit.value(1 ether)(); + Victim(victim_address).withdraw(); + } + + function() external payable { + if (gasleft() > 40000) { + Victim(victim_address).withdraw(); + } + } +} +``` + +یہ کنٹریکٹ تین کام کرنے کے لیے ڈیزائن کیا گیا ہے: + +1. دوسرے اکاؤنٹ (ممکنہ طور پر حملہ آور کا EOA) سے ڈپازٹ قبول کریں +2. Victim کنٹریکٹ میں 1 ETH جمع کریں +3. اسمارٹ کنٹریکٹ میں اسٹور کردہ 1 ETH نکالیں + +یہاں کوئی غلطی نہیں ہے، سوائے اس کے کہ `Attacker` کے پاس ایک اور فنکشن ہے جو `Victim` میں دوبارہ `withdraw()` کو کال کرتا ہے اگر آنے والے `msg.sender.call.value` سے بچا ہوا گیس 40,000 سے زیادہ ہو۔ یہ `Attacker` کو `Victim` میں دوبارہ داخل ہونے اور `withdraw` کی پہلی درخواست مکمل ہونے سے _پہلے_ مزید فنڈز نکالنے کی صلاحیت دیتا ہے۔ یہ چکر اس طرح لگتا ہے: + +```solidity +- حملہ آور کا EOA 1 ETH کے ساتھ `Attacker.beginAttack()` کو کال کرتا ہے +- `Attacker.beginAttack()` `Victim` میں 1 ETH جمع کرتا ہے +- `Attacker` `Victim` میں `withdraw()` کو کال کرتا ہے +- `Victim` `Attacker` کا بیلنس چیک کرتا ہے (1 ETH) +- `Victim` `Attacker` کو 1 ETH بھیجتا ہے (جو ڈیفالٹ فنکشن کو متحرک کرتا ہے) +- `Attacker` دوبارہ `Victim.withdraw()` کو کال کرتا ہے (نوٹ کریں کہ `Victim` نے پہلی نکالی سے `Attacker` کا بیلنس کم نہیں کیا ہے) +- `Victim` `Attacker` کا بیلنس چیک کرتا ہے (جو اب بھی 1 ETH ہے کیونکہ اس نے پہلی کال کے اثرات لاگو نہیں کیے ہیں) +- `Victim` `Attacker` کو 1 ETH بھیجتا ہے (جو ڈیفالٹ فنکشن کو متحرک کرتا ہے اور `Attacker` کو `withdraw` فنکشن میں دوبارہ داخل ہونے کی اجازت دیتا ہے) +- یہ عمل اس وقت تک دہرایا جاتا ہے جب تک کہ `Attacker` کا گیس ختم نہ ہو جائے، جس کے بعد `msg.sender.call.value` اضافی نکالی کو متحرک کیے بغیر واپس آجاتا ہے +- `Victim` آخر میں پہلی لین دین (اور بعد کی) کے نتائج کو اپنی اسٹیٹ پر لاگو کرتا ہے، لہذا `Attacker` کا بیلنس 0 پر سیٹ ہو جاتا ہے +``` + +خلاصہ یہ ہے کہ چونکہ کالر کا بیلنس فنکشن کے عمل درآمد مکمل ہونے تک 0 پر سیٹ نہیں ہوتا ہے، اس لیے بعد کی درخواستیں کامیاب ہوں گی اور کالر کو اپنا بیلنس کئی بار نکالنے کی اجازت دیں گی۔ اس قسم کا حملہ ایک اسمارٹ کنٹریکٹ سے اس کے فنڈز نکالنے کے لیے استعمال کیا جاسکتا ہے، جیسا کہ [2016 کے DAO ہیک](https://www.coindesk.com/learn/understanding-the-dao-attack) میں ہوا تھا۔ دوبارہ داخلے کے حملے آج بھی اسمارٹ کنٹریکٹس کے لیے ایک اہم مسئلہ ہیں جیسا کہ [دوبارہ داخلے کے استحصال کی عوامی فہرستیں](https://github.com/pcaversaccio/reentrancy-attacks) دکھاتی ہیں۔ + +##### دوبارہ داخلے کے حملوں کو کیسے روکا جائے + +دوبارہ داخلے سے نمٹنے کا ایک طریقہ [چیکس-ایفیکٹس-انٹریکشنز پیٹرن](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) کی پیروی کرنا ہے۔ یہ پیٹرن فنکشنز کے عمل درآمد کو اس طرح ترتیب دیتا ہے کہ وہ کوڈ جو عمل درآمد کے ساتھ آگے بڑھنے سے پہلے ضروری چیک انجام دیتا ہے سب سے پہلے آتا ہے، اس کے بعد وہ کوڈ آتا ہے جو کنٹریکٹ کی اسٹیٹ میں ہیرا پھیری کرتا ہے، اور آخر میں وہ کوڈ آتا ہے جو دوسرے کنٹریکٹس یا EOAs کے ساتھ تعامل کرتا ہے۔ + +چیکس-ایفیکٹ-انٹریکشن پیٹرن `Victim` کنٹریکٹ کے نظر ثانی شدہ ورژن میں استعمال ہوتا ہے جو نیچے دکھایا گیا ہے: + +```solidity +contract NoLongerAVictim { + function withdraw() external { + uint256 amount = balances[msg.sender]; + balances[msg.sender] = 0; + (bool success, ) = msg.sender.call.value(amount)(""); + require(success); + } +} +``` + +یہ کنٹریکٹ صارف کے بیلنس پر ایک _چیک_ کرتا ہے، `withdraw()` فنکشن کے _اثرات_ کو لاگو کرتا ہے (صارف کا بیلنس 0 پر ری سیٹ کرکے)، اور _انٹریکشن_ انجام دینے کے لیے آگے بڑھتا ہے (صارف کے ایڈریس پر ETH بھیجنا)۔ یہ یقینی بناتا ہے کہ کنٹریکٹ بیرونی کال سے پہلے اپنے اسٹوریج کو اپ ڈیٹ کرے، جس سے دوبارہ داخلے کی شرط ختم ہو جاتی ہے جس نے پہلے حملے کو ممکن بنایا تھا۔ `Attacker` کنٹریکٹ اب بھی `NoLongerAVictim` میں واپس کال کرسکتا ہے، لیکن چونکہ `balances[msg.sender]` کو 0 پر سیٹ کردیا گیا ہے، اس لیے اضافی نکالی ایک خرابی پیدا کرے گی۔ + +ایک اور آپشن باہمی اخراج لاک (عام طور پر "میوٹیکس" کے طور پر بیان کیا جاتا ہے) کا استعمال کرنا ہے جو ایک کنٹریکٹ کی اسٹیٹ کے ایک حصے کو لاک کرتا ہے جب تک کہ فنکشن کی درخواست مکمل نہ ہو جائے۔ یہ ایک بولین متغیر کا استعمال کرکے نافذ کیا جاتا ہے جو فنکشن کے عمل درآمد سے پہلے `true` پر سیٹ ہوتا ہے اور درخواست کے مکمل ہونے کے بعد `false` پر واپس آجاتا ہے۔ جیسا کہ نیچے دی گئی مثال میں دیکھا گیا ہے، میوٹیکس کا استعمال ایک فنکشن کو بار بار کالوں سے بچاتا ہے جبکہ اصل درخواست ابھی بھی پروسیس ہورہی ہے، جس سے مؤثر طریقے سے دوبارہ داخلے کو روکا جاتا ہے۔ + +```solidity +pragma solidity ^0.7.0; + +contract MutexPattern { + bool locked = false; + mapping(address => uint256) public balances; + + modifier noReentrancy() { + require(!locked, "Blocked from reentrancy."); + locked = true; + _; + locked = false; + } + // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. + // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier + function withdraw(uint _amount) public payable noReentrancy returns(bool) { + require(balances[msg.sender] >= _amount, "No balance to withdraw."); + + balances[msg.sender] -= _amount; + (bool success, ) = msg.sender.call{value: _amount}(""); + require(success); + + return true; + } +} +``` + +آپ [پل پیمنٹس](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment) سسٹم کا بھی استعمال کرسکتے ہیں جس میں صارفین کو اسمارٹ کنٹریکٹس سے فنڈز نکالنے کی ضرورت ہوتی ہے، بجائے اس کے کہ "پش پیمنٹس" سسٹم جو اکاؤنٹس کو فنڈز بھیجتا ہے۔ یہ نامعلوم ایڈریسز پر نادانستہ طور پر کوڈ کو متحرک کرنے کے امکان کو ختم کرتا ہے (اور کچھ ڈینائل-آف-سروس حملوں کو بھی روک سکتا ہے)۔ + +#### انٹیجر انڈر فلوز اور اوور فلوز {#integer-underflows-and-overflows} + +ایک انٹیجر اوور فلو اس وقت ہوتا ہے جب ایک حسابی عمل کے نتائج قابل قبول قدروں کی حد سے باہر ہوجاتے ہیں، جس کی وجہ سے یہ سب سے کم نمائندگی کے قابل قدر پر "رول اوور" ہوجاتا ہے۔ مثال کے طور پر، ایک `uint8` صرف 2^8-1=255 تک کی قدریں اسٹور کرسکتا ہے۔ وہ حسابی عمل جن کے نتیجے میں `255` سے زیادہ قدریں آتی ہیں، اوور فلو ہو جائیں گے اور `uint` کو `0` پر ری سیٹ کر دیں گے، اسی طرح جیسے کار کا اوڈومیٹر زیادہ سے زیادہ مائلیج (999999) تک پہنچنے پر 0 پر ری سیٹ ہوجاتا ہے۔ + +انٹیجر انڈر فلوز اسی طرح کی وجوہات کی بنا پر ہوتے ہیں: ایک حسابی عمل کے نتائج قابل قبول حد سے نیچے آجاتے ہیں۔ فرض کریں کہ آپ نے `uint8` میں `0` کو کم کرنے کی کوشش کی، تو نتیجہ صرف زیادہ سے زیادہ نمائندگی کے قابل قدر (`255`) پر رول اوور ہوجائے گا۔ + +انٹیجر اوور فلوز اور انڈر فلوز دونوں ایک کنٹریکٹ کی اسٹیٹ متغیرات میں غیر متوقع تبدیلیوں کا باعث بن سکتے ہیں اور غیر منصوبہ بند عمل درآمد کا نتیجہ بن سکتے ہیں۔ نیچے ایک مثال ہے جو دکھاتی ہے کہ ایک حملہ آور کس طرح ایک اسمارٹ کنٹریکٹ میں حسابی اوور فلو کا استحصال کرکے ایک غلط آپریشن انجام دے سکتا ہے: + +``` +pragma solidity ^0.7.6; + +// یہ کنٹریکٹ ایک ٹائم والٹ کے طور پر کام کرنے کے لیے ڈیزائن کیا گیا ہے۔ +// صارف اس کنٹریکٹ میں جمع تو کرسکتا ہے لیکن کم از کم ایک ہفتے تک نکال نہیں سکتا۔ +// صارف 1 ہفتے کے انتظار کی مدت سے آگے بھی انتظار کا وقت بڑھا سکتا ہے۔ + +/* +1. TimeLock تعینات کریں۔ +2. TimeLock کے ایڈریس کے ساتھ Attack تعینات کریں۔ +3. 1 ایتھر بھیج کر Attack.attack کو کال کریں۔ آپ فوری طور پر اپنا + ایتھر نکال سکیں گے۔ + +کیا ہوا؟ +حملے نے TimeLock.lockTime کو اوور فلو کردیا اور 1 ہفتے کی انتظار کی مدت سے پہلے +نکالنے میں کامیاب رہا۔ +*/ + +contract TimeLock { + mapping(address => uint) public balances; + mapping(address => uint) public lockTime; + + function deposit() external payable { + balances[msg.sender] += msg.value; + lockTime[msg.sender] = block.timestamp + 1 weeks; + } + + function increaseLockTime(uint _secondsToIncrease) public { + lockTime[msg.sender] += _secondsToIncrease; + } + + function withdraw() public { + require(balances[msg.sender] > 0, "Insufficient funds"); + require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); + + uint amount = balances[msg.sender]; + balances[msg.sender] = 0; + + (bool sent, ) = msg.sender.call{value: amount}(""); + require(sent, "Failed to send Ether"); + } +} + +contract Attack { + TimeLock timeLock; + + constructor(TimeLock _timeLock) { + timeLock = TimeLock(_timeLock); + } + + fallback() external payable {} + + function attack() public payable { + timeLock.deposit{value: msg.value}(); + /* + اگر t = موجودہ لاک ٹائم ہے تو ہمیں x تلاش کرنے کی ضرورت ہے اس طرح کہ + x + t = 2**256 = 0 + تو x = -t + 2**256 = type(uint).max + 1 + تو x = type(uint).max + 1 - t + */ + timeLock.increaseLockTime( + type(uint).max + 1 - timeLock.lockTime(address(this)) + ); + timeLock.withdraw(); + } +} +``` + +##### انٹیجر انڈر فلوز اور اوور فلوز کو کیسے روکا جائے + +ورژن 0.8.0 کے بعد سے، Solidity کمپائلر اس کوڈ کو مسترد کردیتا ہے جس کے نتیجے میں انٹیجر انڈر فلوز اور اوور فلوز ہوتے ہیں۔ تاہم، نچلے کمپائلر ورژن کے ساتھ کمپائل کیے گئے کنٹریکٹس کو یا تو حسابی آپریشنز والے فنکشنز پر چیکس انجام دینے چاہئیں یا ایک لائبریری (مثلاً، [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)) کا استعمال کرنا چاہئے جو انڈر فلو/اوور فلو کی جانچ کرتی ہے۔ + +#### اوریکل ہیرا پھیری {#oracle-manipulation} + +[اوریکلز](/developers/docs/oracles/) آف چین معلومات حاصل کرتے ہیں اور اسے اسمارٹ کنٹریکٹس کے استعمال کے لیے آن چین بھیجتے ہیں۔ اوریکلز کے ساتھ، آپ ایسے اسمارٹ کنٹریکٹس ڈیزائن کرسکتے ہیں جو آف چین سسٹمز، جیسے کہ کیپٹل مارکیٹس، کے ساتھ باہم کام کرتے ہیں، جس سے ان کی ایپلی کیشن میں بہت زیادہ توسیع ہوتی ہے۔ + +لیکن اگر اوریکل خراب ہو جائے اور آن چین غلط معلومات بھیجے، تو اسمارٹ کنٹریکٹس غلط ان پٹس کی بنیاد پر عمل درآمد کریں گے، جو مسائل پیدا کرسکتے ہیں۔ یہ "اوریکل مسئلہ" کی بنیاد ہے، جو اس کام سے متعلق ہے کہ بلاک چین اوریکل سے حاصل کردہ معلومات درست، تازہ ترین، اور بروقت ہوں۔ + +ایک متعلقہ سیکیورٹی تشویش ایک آن چین اوریکل، جیسے کہ ایک غیر مرکزی ایکسچینج، کا استعمال کرکے کسی اثاثے کی اسپاٹ قیمت حاصل کرنا ہے۔ [غیر مرکزی فنانس (DeFi)](/defi/) صنعت میں قرض دینے والے پلیٹ فارمز اکثر یہ کام صارف کے کولیٹرل کی قدر کا تعین کرنے کے لیے کرتے ہیں تاکہ یہ تعین کیا جاسکے کہ وہ کتنا قرض لے سکتے ہیں۔ + +DEX قیمتیں اکثر درست ہوتی ہیں، بڑی حد تک ثالثی کرنے والوں کی وجہ سے جو مارکیٹوں میں برابری بحال کرتے ہیں۔ تاہم، وہ ہیرا پھیری کے لیے کھلے ہیں، خاص طور پر اگر آن چین اوریکل تاریخی تجارتی نمونوں کی بنیاد پر اثاثوں کی قیمتوں کا حساب لگاتا ہے (جیسا کہ عام طور پر ہوتا ہے)۔ + +مثال کے طور پر، ایک حملہ آور آپ کے قرض دینے والے کنٹریکٹ کے ساتھ تعامل کرنے سے ٹھیک پہلے ایک فلیش لون لے کر کسی اثاثے کی اسپاٹ قیمت کو مصنوعی طور پر بڑھا سکتا ہے۔ اثاثے کی قیمت کے لیے DEX سے پوچھ گچھ کرنے پر معمول سے زیادہ قیمت واپس آئے گی (حملہ آور کے بڑے "خرید آرڈر" کی وجہ سے اثاثے کی مانگ میں بگاڑ)، جس سے وہ اپنی ضرورت سے زیادہ قرض لے سکتے ہیں۔ اس طرح کے "فلیش لون حملوں" کا استعمال DeFi ایپلی کیشنز کے درمیان قیمت کے اوریکلز پر انحصار کا استحصال کرنے کے لیے کیا گیا ہے، جس سے پروٹوکولز کو لاکھوں ڈالر کا نقصان ہوا ہے۔ + +##### اوریکل ہیرا پھیری کو کیسے روکا جائے + +[اوریکل ہیرا پھیری سے بچنے](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) کے لیے کم از کم ضرورت یہ ہے کہ ایک غیر مرکزی اوریکل نیٹ ورک کا استعمال کیا جائے جو ناکامی کے واحد نکات سے بچنے کے لیے متعدد ذرائع سے معلومات حاصل کرتا ہے۔ زیادہ تر معاملات میں، غیر مرکزی اوریکلز میں بلٹ ان کرپٹو اکنامک مراعات ہوتی ہیں تاکہ اوریکل نوڈس کو درست معلومات رپورٹ کرنے کی ترغیب دی جاسکے، جو انہیں مرکزی اوریکلز سے زیادہ محفوظ بناتی ہیں۔ + +اگر آپ اثاثوں کی قیمتوں کے لیے ایک آن چین اوریکل سے پوچھ گچھ کرنے کا ارادہ رکھتے ہیں، تو ایک ایسا استعمال کرنے پر غور کریں جو ٹائم ویٹڈ ایوریج پرائس (TWAP) میکانزم کو نافذ کرتا ہے۔ ایک [TWAP اوریکل](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) دو مختلف اوقات میں کسی اثاثے کی قیمت سے پوچھ گچھ کرتا ہے (جسے آپ تبدیل کرسکتے ہیں) اور حاصل کردہ اوسط کی بنیاد پر اسپاٹ قیمت کا حساب لگاتا ہے۔ طویل مدت کا انتخاب آپ کے پروٹوکول کو قیمت کی ہیرا پھیری سے بچاتا ہے کیونکہ حال ہی میں انجام دیئے گئے بڑے آرڈرز اثاثوں کی قیمتوں پر اثر انداز نہیں ہوسکتے۔ + +## ڈیولپرز کے لیے اسمارٹ کنٹریکٹ سیکیورٹی وسائل {#smart-contract-security-resources-for-developers} + +### اسمارٹ کنٹریکٹس کا تجزیہ کرنے اور کوڈ کی درستگی کی تصدیق کے لیے ٹولز {#code-analysis-tools} + +- **[ٹیسٹنگ ٹولز اور لائبریریاں](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** - _اسمارٹ کنٹریکٹس پر یونٹ ٹیسٹ، اسٹیٹک تجزیہ، اور ڈائنامک تجزیہ کرنے کے لیے صنعت کے معیاری ٹولز اور لائبریریوں کا مجموعہ۔_ + +- **[رسمی تصدیق کے ٹولز](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** - _اسمارٹ کنٹریکٹس میں فنکشنل درستگی کی تصدیق کرنے اور انویرینٹس کی جانچ کے لیے ٹولز۔_ + +- **[اسمارٹ کنٹریکٹ آڈٹ کرنے کی خدمات](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** - _Ethereum ڈیولپمنٹ پروجیکٹس کے لیے اسمارٹ کنٹریکٹ آڈٹ کرنے کی خدمات فراہم کرنے والی تنظیموں کی فہرست۔_ + +- **[بگ باؤنٹی پلیٹ فارمز](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** - _بگ باؤنٹیز کو مربوط کرنے اور اسمارٹ کنٹریکٹس میں اہم کمزوریوں کے ذمہ دارانہ انکشاف پر انعام دینے کے لیے پلیٹ فارمز۔_ + +- **[Fork Checker](https://forkchecker.hashex.org/)** - _ایک فورک شدہ کنٹریکٹ کے بارے میں تمام دستیاب معلومات کی جانچ کے لیے ایک مفت آن لائن ٹول۔_ + +- **[ABI Encoder](https://abi.hashex.org/)** - _آپ کے Solidity کنٹریکٹ فنکشنز اور کنسٹرکٹر دلائل کو انکوڈ کرنے کے لیے ایک مفت آن لائن سروس۔_ + +- **[Aderyn](https://github.com/Cyfrin/aderyn)** - _Solidity اسٹیٹک اینالائزر، جو ایبسٹریکٹ سنٹیکس ٹریز (AST) سے گزر کر مشتبہ کمزوریوں کی نشاندہی کرتا ہے اور مسائل کو ایک آسان استعمال کے لیے مارک ڈاؤن فارمیٹ میں پرنٹ کرتا ہے۔_ + +### اسمارٹ کنٹریکٹس کی نگرانی کے لیے ٹولز {#smart-contract-monitoring-tools} + +- **[Tenderly ریئل ٹائم الرٹنگ](https://tenderly.co/monitoring)** - _جب آپ کے اسمارٹ کنٹریکٹس یا والیٹس پر غیر معمولی یا غیر متوقع واقعات ہوتے ہیں تو ریئل ٹائم اطلاعات حاصل کرنے کے لیے ایک ٹول۔_ + +### اسمارٹ کنٹریکٹس کی محفوظ انتظامیہ کے لیے ٹولز {#smart-contract-administration-tools} + +- **[Safe](https://safe.global/)** - _Ethereum پر چلنے والا اسمارٹ کنٹریکٹ والیٹ جس میں کسی لین دین کے ہونے سے پہلے کم از کم تعداد میں لوگوں کی منظوری کی ضرورت ہوتی ہے (M-of-N)۔_ + +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** - _انتظامی خصوصیات کو نافذ کرنے کے لیے کنٹریکٹ لائبریریاں، بشمول کنٹریکٹ کی ملکیت، اپ گریڈ، رسائی کنٹرول، گورننس، توقف پذیری، اور مزید۔_ + +### اسمارٹ کنٹریکٹ آڈٹ کرنے کی خدمات {#smart-contract-auditing-services} + +- **[ConsenSys Diligence](https://diligence.consensys.io/)** - _اسمارٹ کنٹریکٹ آڈٹ کرنے کی سروس جو بلاک چین ایکو سسٹم میں پروجیکٹس کو یہ یقینی بنانے میں مدد کرتی ہے کہ ان کے پروٹوکول لانچ کے لیے تیار ہیں اور صارفین کی حفاظت کے لیے بنائے گئے ہیں۔_ + +- **[CertiK](https://www.certik.com/)** - _بلاک چین سیکیورٹی فرم جو اسمارٹ کنٹریکٹس اور بلاک چین نیٹ ورکس پر جدید ترین رسمی تصدیق کی ٹیکنالوجی کے استعمال میں پیش پیش ہے۔_ + +- **[Trail of Bits](https://www.trailofbits.com/)** - _سائبر سیکیورٹی کمپنی جو خطرے کو کم کرنے اور کوڈ کو مضبوط کرنے کے لیے سیکیورٹی تحقیق کو حملہ آور کی ذہنیت کے ساتھ جوڑتی ہے۔_ + +- **[PeckShield](https://peckshield.com/)** - _بلاک چین سیکیورٹی کمپنی جو پورے بلاک چین ایکو سسٹم کی سیکیورٹی، رازداری اور استعمال کے لیے مصنوعات اور خدمات پیش کرتی ہے۔_ + +- **[QuantStamp](https://quantstamp.com/)** - _سیکیورٹی اور رسک اسسمنٹ خدمات کے ذریعے بلاک چین ٹیکنالوجی کو مرکزی دھارے میں لانے میں سہولت فراہم کرنے والی آڈٹ سروس۔_ + +- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** - _اسمارٹ کنٹریکٹ سیکیورٹی کمپنی جو تقسیم شدہ سسٹمز کے لیے سیکیورٹی آڈٹ فراہم کرتی ہے۔_ + +- **[Runtime Verification](https://runtimeverification.com/)** - _سیکیورٹی کمپنی جو اسمارٹ کنٹریکٹس کی رسمی ماڈلنگ اور تصدیق میں مہارت رکھتی ہے۔_ + +- **[Hacken](https://hacken.io)** - _Web3 سائبر سیکیورٹی آڈیٹر جو بلاک چین سیکیورٹی کے لیے 360 ڈگری کا نقطہ نظر لاتا ہے۔_ + +- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** - _Solidity اور Cairo آڈٹ خدمات، جو Ethereum اور Starknet پر اسمارٹ کنٹریکٹس کی سالمیت اور صارفین کی حفاظت کو یقینی بناتی ہیں۔_ + +- **[HashEx](https://hashex.org/)** - _HashEx کرپٹو کرنسیوں کی سیکیورٹی کو یقینی بنانے کے لیے بلاک چین اور اسمارٹ کنٹریکٹ آڈٹ پر توجہ مرکوز کرتا ہے، جس میں اسمارٹ کنٹریکٹ ڈیولپمنٹ، پینیٹریشن ٹیسٹنگ، بلاک چین کنسلٹنگ جیسی خدمات فراہم کی جاتی ہیں۔_ + +- **[Code4rena](https://code4rena.com/)** - _مسابقتی آڈٹ پلیٹ فارم جو اسمارٹ کنٹریکٹ سیکیورٹی ماہرین کو کمزوریاں تلاش کرنے اور ویب 3 کو زیادہ محفوظ بنانے میں مدد کرنے کی ترغیب دیتا ہے۔_ + +- **[CodeHawks](https://codehawks.com/)** - _مسابقتی آڈٹ پلیٹ فارم جو سیکیورٹی محققین کے لیے اسمارٹ کنٹریکٹس آڈٹ کے مقابلوں کی میزبانی کرتا ہے۔_ + +- **[Cyfrin](https://cyfrin.io)** - _Web3 سیکیورٹی کا پاور ہاؤس، جو مصنوعات اور اسمارٹ کنٹریکٹ آڈٹ خدمات کے ذریعے کرپٹو سیکیورٹی کو فروغ دیتا ہے۔_ + +- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** - _Web3 سیکیورٹی فرم جو تجربہ کار آڈیٹرز اور بہترین ٹولز کی ایک ٹیم کے ذریعے بلاک چین سسٹمز کے لیے سیکیورٹی آڈٹ پیش کرتی ہے۔_ + +- **[Oxorio](https://oxor.io/)** - _کرپٹو فرموں اور DeFi پروجیکٹس کے لیے EVM, Solidity, ZK, کراس چین ٹیک میں مہارت کے ساتھ اسمارٹ کنٹریکٹ آڈٹ اور بلاک چین سیکیورٹی خدمات۔_ + +- **[Inference](https://inference.ag/)** - _سیکیورٹی آڈٹ کمپنی، جو EVM پر مبنی بلاک چینز کے لیے اسمارٹ کنٹریکٹ آڈٹ میں مہارت رکھتی ہے۔ اس کے ماہر آڈیٹرز کی بدولت وہ ممکنہ مسائل کی نشاندہی کرتے ہیں اور تعیناتی سے پہلے انہیں ٹھیک کرنے کے لیے قابل عمل حل تجویز کرتے ہیں۔ + +### بگ باؤنٹی پلیٹ فارمز {#bug-bounty-platforms} + +- **[Immunefi](https://immunefi.com/)** - _اسمارٹ کنٹریکٹس اور DeFi پروجیکٹس کے لیے بگ باؤنٹی پلیٹ فارم، جہاں سیکیورٹی محققین کوڈ کا جائزہ لیتے ہیں، کمزوریوں کا انکشاف کرتے ہیں، ادائیگی حاصل کرتے ہیں، اور کرپٹو کو محفوظ بناتے ہیں۔_ + +- **[HackerOne](https://www.hackerone.com/)** - _کمزوریوں کو مربوط کرنے اور بگ باؤنٹی پلیٹ فارم جو کاروباروں کو پینیٹریشن ٹیسٹرز اور سائبر سیکیورٹی محققین سے جوڑتا ہے۔_ + +- **[HackenProof](https://hackenproof.com/)** - _کرپٹو پروجیکٹس (DeFi، اسمارٹ کنٹریکٹس، والیٹس، CEX اور مزید) کے لیے ماہر بگ باؤنٹی پلیٹ فارم، جہاں سیکیورٹی پروفیشنلز ٹرائی ایج خدمات فراہم کرتے ہیں اور محققین کو متعلقہ، تصدیق شدہ بگ رپورٹس کے لیے ادائیگی ملتی ہے۔_ + +- **[Sherlock](https://www.sherlock.xyz/)** - _ویب 3 میں اسمارٹ کنٹریکٹ سیکیورٹی کے لیے انڈر رائٹر، جس میں آڈیٹرز کے لیے ادائیگیوں کا انتظام اسمارٹ کنٹریکٹس کے ذریعے کیا جاتا ہے تاکہ یہ یقینی بنایا جاسکے کہ متعلقہ بگز کی منصفانہ ادائیگی کی جائے۔_ + +- **[CodeHawks](https://www.codehawks.com/)** - _مسابقتی بگ باؤنٹی پلیٹ فارم جہاں آڈیٹرز سیکیورٹی مقابلوں اور چیلنجوں میں حصہ لیتے ہیں، اور (جلد ہی) اپنے نجی آڈٹ میں بھی۔_ + +### معروف اسمارٹ کنٹریکٹ کی کمزوریوں اور استحصال کی اشاعتیں {#common-smart-contract-vulnerabilities-and-exploits} + +- **[ConsenSys: اسمارٹ کنٹریکٹ کی معروف حملے](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** - _سب سے اہم کنٹریکٹ کی کمزوریوں کی ابتدائی دوستانہ وضاحت، زیادہ تر معاملات کے لیے نمونہ کوڈ کے ساتھ۔_ + +- **[SWC رجسٹری](https://swcregistry.io/)** - _عام کمزوریوں کی گنتی (CWE) آئٹمز کی تیار کردہ فہرست جو Ethereum اسمارٹ کنٹریکٹس پر لاگو ہوتی ہیں۔_ + +- **[Rekt](https://rekt.news/)** - _باقاعدگی سے اپ ڈیٹ ہونے والی ہائی پروفائل کرپٹو ہیکس اور استحصال کی اشاعت، تفصیلی پوسٹ مارٹم رپورٹس کے ساتھ۔_ + +### اسمارٹ کنٹریکٹ سیکیورٹی سیکھنے کے لیے چیلنجز {#challenges-for-learning-smart-contract-security} + +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** - _بلاک چین سیکیورٹی وارگیمز، چیلنجز، اور [کیپچر دی فلیگ](https://www.webopedia.com/definitions/ctf-event/amp/) مقابلوں اور حل کے رائٹ اپس کی تیار کردہ فہرست۔_ + +- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** - _DeFi اسمارٹ کنٹریکٹس کی جارحانہ سیکیورٹی سیکھنے اور بگ ہنٹنگ اور سیکیورٹی آڈٹ میں مہارتیں بنانے کے لیے وارگیم۔_ + +- **[Ethernaut](https://ethernaut.openzeppelin.com/)** - _Web3/Solidity پر مبنی وارگیم جہاں ہر سطح ایک اسمارٹ کنٹریکٹ ہے جسے 'ہیک' کرنے کی ضرورت ہے۔_ + +- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _ایک فینٹسی ایڈونچر میں سیٹ کیا گیا اسمارٹ کنٹریکٹ ہیکنگ چیلنج۔ چیلنج کی کامیاب تکمیل نجی بگ باؤنٹی پروگرام تک رسائی بھی فراہم کرتی ہے۔ + +### اسمارٹ کنٹریکٹس کو محفوظ بنانے کے لیے بہترین طریقے {#smart-contract-security-best-practices} + +- **[ConsenSys: Ethereum اسمارٹ کنٹریکٹ سیکیورٹی کے بہترین طریقے](https://consensys.github.io/smart-contract-best-practices/)** - _Ethereum اسمارٹ کنٹریکٹس کو محفوظ بنانے کے لیے رہنما خطوط کی جامع فہرست۔_ + +- **[Nascent: سادہ سیکیورٹی ٹول کٹ](https://github.com/nascentxyz/simple-security-toolkit)** - _اسمارٹ کنٹریکٹ ڈیولپمنٹ کے لیے عملی سیکیورٹی پر مرکوز گائیڈز اور چیک لسٹوں کا مجموعہ۔_ + +- **[Solidity پیٹرنز](https://fravoll.github.io/solidity-patterns/)** - _اسمارٹ کنٹریکٹ پروگرامنگ زبان Solidity کے لیے محفوظ پیٹرنز اور بہترین طریقوں کی مفید تالیف۔_ + +- **[Solidity Docs: سیکیورٹی تحفظات](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** - _Solidity کے ساتھ محفوظ اسمارٹ کنٹریکٹس لکھنے کے لیے رہنما خطوط۔_ + +- **[اسمارٹ کنٹریکٹ سیکیورٹی تصدیق کا معیار](https://github.com/securing/SCSVS)** - _ڈیولپرز، آرکیٹیکٹس، سیکیورٹی جائزہ لینے والوں اور وینڈرز کے لیے اسمارٹ کنٹریکٹس کی سیکیورٹی کو معیاری بنانے کے لیے بنائی گئی چودہ حصوں کی چیک لسٹ۔_ + +- **[اسمارٹ کنٹریکٹ سیکیورٹی اور آڈٹ سیکھیں](https://updraft.cyfrin.io/courses/security)** - _حتمی اسمارٹ کنٹریکٹ سیکیورٹی اور آڈٹ کورس، جو ان اسمارٹ کنٹریکٹ ڈیولپرز کے لیے بنایا گیا ہے جو اپنی سیکیورٹی کے بہترین طریقوں کو بہتر بنانا اور سیکیورٹی محققین بننا چاہتے ہیں۔_ + +### اسمارٹ کنٹریکٹ سیکیورٹی پر ٹیوٹوریلز {#tutorials-on-smart-contract-security} + +- [محفوظ اسمارٹ کنٹریکٹس کیسے لکھیں](/developers/tutorials/secure-development-workflow/) + +- [اسمارٹ کنٹریکٹ بگز تلاش کرنے کے لیے Slither کا استعمال کیسے کریں](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) + +- [اسمارٹ کنٹریکٹ بگز تلاش کرنے کے لیے Manticore کا استعمال کیسے کریں](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) + +- [اسمارٹ کنٹریکٹ سیکیورٹی رہنما خطوط](/developers/tutorials/smart-contract-security-guidelines/) + +- [اپنے ٹوکن کنٹریکٹ کو صوابدیدی ٹوکنز کے ساتھ محفوظ طریقے سے کیسے مربوط کریں](/developers/tutorials/token-integration-checklist/) + +- [Cyfrin Updraft - اسمارٹ کنٹریکٹس سیکیورٹی اور آڈٹ مکمل کورس](https://updraft.cyfrin.io/courses/security) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/testing/index.md b/public/content/translations/ur/developers/docs/smart-contracts/testing/index.md new file mode 100644 index 00000000000..f4432e6d174 --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/testing/index.md @@ -0,0 +1,310 @@ +--- +title: "اسمارٹ معاہدوں کی جانچ" +description: "ایتھیریم اسمارٹ معاہدوں کی جانچ کے لیے تکنیکوں اور غور و فکر کا ایک جائزہ۔" +lang: ur-in +--- + +ایتھیریم جیسی عوامی بلاک چینز ناقابل تغیر ہوتی ہیں، جو تعیناتی کے بعد اسمارٹ معاہدے کے کوڈ کو تبدیل کرنا مشکل بناتی ہیں۔ "ورچوئل اپ گریڈ" انجام دینے کے لیے [معاہدے کے اپ گریڈ کے نمونے](/developers/docs/smart-contracts/upgrading/) موجود ہیں، لیکن ان کو نافذ کرنا مشکل ہے اور سماجی اتفاق رائے کی ضرورت ہوتی ہے۔ مزید یہ کہ، ایک اپ گریڈ صرف ایک خرابی کو اس کے دریافت ہونے کے _بعد_ ہی ٹھیک کر سکتا ہے—اگر کوئی حملہ آور پہلے کمزوری کو دریافت کر لیتا ہے، تو آپ کا اسمارٹ معاہدہ استحصال کے خطرے میں ہے۔ + +ان وجوہات کی بنا پر، Mainnet پر [تعینات کرنے](/developers/docs/smart-contracts/deploying/) سے پہلے اسمارٹ معاہدوں کی جانچ کرنا [سیکورٹی](/developers/docs/smart-contracts/security/) کے لیے ایک کم از کم ضرورت ہے۔ معاہدوں کی جانچ کرنے اور کوڈ کی درستگی کا جائزہ لینے کے لیے بہت سی تکنیکیں موجود ہیں؛ آپ کیا منتخب کرتے ہیں یہ آپ کی ضروریات پر منحصر ہے۔ اس کے باوجود، مختلف ٹولز اور طریقوں سے بنا ایک ٹیسٹ سویٹ معاہدے کے کوڈ میں معمولی اور بڑی دونوں طرح کی سیکورٹی خامیوں کو پکڑنے کے لیے مثالی ہے۔ + +## شرائط {#prerequisites} + +یہ صفحہ ایتھیریم نیٹ ورک پر تعینات کرنے سے پہلے اسمارٹ معاہدوں کی جانچ کرنے کا طریقہ بتاتا ہے۔ یہ فرض کرتا ہے کہ آپ [اسمارٹ معاہدوں](/developers/docs/smart-contracts/) سے واقف ہیں۔ + +## اسمارٹ معاہدے کی جانچ کیا ہے؟ {#what-is-smart-contract-testing} + +اسمارٹ معاہدے کی جانچ اس بات کی تصدیق کرنے کا عمل ہے کہ اسمارٹ معاہدے کا کوڈ توقع کے مطابق کام کرتا ہے۔ جانچ اس بات کی پڑتال کے لیے مفید ہے کہ آیا کوئی خاص اسمارٹ معاہدہ وشوسنییتا، استعمال پذیری، اور سیکورٹی کی ضروریات کو پورا کرتا ہے۔ + +اگرچہ طریقے مختلف ہوتے ہیں، زیادہ تر جانچ کے طریقوں میں اسمارٹ معاہدے کو ڈیٹا کے ایک چھوٹے سے نمونے کے ساتھ عمل میں لانے کی ضرورت ہوتی ہے جس کو اسے سنبھالنے کی توقع ہے۔ اگر معاہدہ نمونہ ڈیٹا کے لیے صحیح نتائج دیتا ہے، تو یہ سمجھا جاتا ہے کہ یہ صحیح طریقے سے کام کر رہا ہے۔ زیادہ تر جانچ کے ٹولز [ٹیسٹ کیسز](https://en.m.wikipedia.org/wiki/Test_case) لکھنے اور عمل میں لانے کے لیے وسائل فراہم کرتے ہیں تاکہ یہ جانچا جا سکے کہ آیا معاہدے کا عمل درآمد متوقع نتائج سے میل کھاتا ہے۔ + +### اسمارٹ معاہدوں کی جانچ کرنا کیوں ضروری ہے؟ {#importance-of-testing-smart-contracts} + +چونکہ اسمارٹ معاہدے اکثر اعلیٰ قدر کے مالی اثاثوں کا انتظام کرتے ہیں، اس لیے معمولی پروگرامنگ کی غلطیاں [صارفین کے لیے بڑے نقصانات](https://rekt.news/leaderboard/) کا باعث بن سکتی ہیں اور اکثر بنتی ہیں۔ تاہم، سخت جانچ آپ کو اسمارٹ معاہدے کے کوڈ میں خامیوں اور مسائل کو جلد دریافت کرنے اور انہیں Mainnet پر لانچ کرنے سے پہلے ٹھیک کرنے میں مدد کر سکتی ہے۔ + +اگرچہ بگ دریافت ہونے پر معاہدے کو اپ گریڈ کرنا ممکن ہے، لیکن اپ گریڈ پیچیدہ ہوتے ہیں اور اگر غلط طریقے سے سنبھالا جائے تو [غلطیوں کا نتیجہ](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) نکل سکتا ہے۔ معاہدے کو اپ گریڈ کرنا مزید ناقابل تغیر کے اصول کو رد کرتا ہے اور صارفین پر اضافی اعتماد کے مفروضوں کا بوجھ ڈالتا ہے۔ اس کے برعکس، آپ کے معاہدے کی جانچ کے لیے ایک جامع منصوبہ اسمارٹ معاہدے کے سیکورٹی خطرات کو کم کرتا ہے اور تعیناتی کے بعد پیچیدہ منطق کے اپ گریڈ کرنے کی ضرورت کو کم کرتا ہے۔ + +## اسمارٹ معاہدوں کی جانچ کے طریقے {#methods-for-testing-smart-contracts} + +ایتھیریم اسمارٹ معاہدوں کی جانچ کے طریقے دو وسیع زمروں میں آتے ہیں: **خودکار جانچ** اور **دستی جانچ**۔ خودکار جانچ اور دستی جانچ منفرد فوائد اور سمجھوتے پیش کرتے ہیں، لیکن آپ اپنے معاہدوں کا تجزیہ کرنے کے لیے ایک مضبوط منصوبہ بنانے کے لیے دونوں کو ملا سکتے ہیں۔ + +### خودکار جانچ {#automated-testing} + +خودکار جانچ ایسے ٹولز کا استعمال کرتی ہے جو خود بخود اسمارٹ معاہدے کے کوڈ کو عمل درآمد میں غلطیوں کے لیے چیک کرتے ہیں۔ خودکار جانچ کا فائدہ معاہدے کی فعالیتوں کی تشخیص کی رہنمائی کے لیے [اسکرپٹس](https://www.techtarget.com/whatis/definition/script?amp=1) کے استعمال سے آتا ہے۔ اسکرپٹڈ ٹیسٹوں کو کم سے کم انسانی مداخلت کے ساتھ بار بار چلانے کے لیے شیڈول کیا جا سکتا ہے، جو خودکار جانچ کو جانچ کے دستی طریقوں سے زیادہ موثر بناتا ہے۔ + +خودکار جانچ خاص طور پر اس وقت مفید ہے جب ٹیسٹ بار بار اور وقت طلب ہوں؛ دستی طور پر انجام دینا مشکل ہو؛ انسانی غلطی کا شکار ہوں؛ یا معاہدے کے اہم افعال کا جائزہ لینا شامل ہو۔ لیکن خودکار جانچ کے ٹولز میں خامیاں ہو سکتی ہیں—وہ کچھ بگس کو چھوڑ سکتے ہیں اور بہت سے [غلط مثبت](https://www.contrastsecurity.com/glossary/false-positive) پیدا کر سکتے ہیں۔ لہذا، اسمارٹ معاہدوں کے لیے خودکار جانچ کو دستی جانچ کے ساتھ جوڑنا مثالی ہے۔ + +### دستی جانچ {#manual-testing} + +دستی جانچ انسانی مدد سے ہوتی ہے اور اس میں اسمارٹ معاہدے کی درستگی کا تجزیہ کرتے وقت آپ کے ٹیسٹ سویٹ میں ہر ٹیسٹ کیس کو ایک کے بعد ایک عمل میں لانا شامل ہوتا ہے۔ یہ خودکار جانچ کے برعکس ہے جہاں آپ بیک وقت ایک معاہدے پر متعدد الگ تھلگ ٹیسٹ چلا سکتے ہیں اور تمام ناکام اور کامیاب ٹیسٹ دکھانے والی ایک رپورٹ حاصل کر سکتے ہیں۔ + +دستی جانچ ایک تحریری ٹیسٹ پلان پر عمل کرتے ہوئے ایک فرد کے ذریعہ کی جا سکتی ہے جو مختلف ٹیسٹ منظرناموں کا احاطہ کرتا ہے۔ آپ دستی جانچ کے حصے کے طور پر ایک مخصوص مدت کے دوران متعدد افراد یا گروہوں کو اسمارٹ معاہدے کے ساتھ تعامل کرنے کے لیے بھی کہہ سکتے ہیں۔ ٹیسٹرز معاہدے کے اصل رویے کا متوقع رویے سے موازنہ کریں گے، کسی بھی فرق کو بگ کے طور پر جھنڈا لگائیں گے۔ + +موثر دستی جانچ کے لیے کافی وسائل (مہارت، وقت، پیسہ، اور کوشش) کی ضرورت ہوتی ہے، اور یہ ممکن ہے—انسانی غلطی کی وجہ سے—ٹیسٹ کرتے وقت کچھ غلطیوں سے محروم رہ جائیں۔ لیکن دستی جانچ بھی فائدہ مند ہو سکتی ہے—مثال کے طور پر، ایک انسانی ٹیسٹر (جیسے، ایک آڈیٹر) ان ایج کیسز کا پتہ لگانے کے لیے وجدان کا استعمال کر سکتا ہے جنہیں ایک خودکار جانچ کا ٹول چھوڑ دے گا۔ + +## اسمارٹ معاہدوں کے لیے خودکار جانچ {#automated-testing-for-smart-contracts} + +### یونٹ ٹیسٹنگ {#unit-testing-for-smart-contracts} + +یونٹ ٹیسٹنگ معاہدے کے افعال کا الگ سے جائزہ لیتی ہے اور جانچتی ہے کہ ہر جزو صحیح طریقے سے کام کرتا ہے۔ اچھے یونٹ ٹیسٹ سادہ، چلانے میں تیز ہونے چاہئیں اور ٹیسٹ ناکام ہونے پر واضح خیال فراہم کرنا چاہیے کہ کیا غلط ہوا۔ + +یونٹ ٹیسٹ اس بات کی جانچ کے لیے مفید ہیں کہ فنکشنز متوقع اقدار لوٹاتے ہیں اور فنکشن کے عمل درآمد کے بعد معاہدے کا اسٹوریج مناسب طریقے سے اپ ڈیٹ ہوتا ہے۔ مزید یہ کہ، معاہدے کے کوڈ بیس میں تبدیلیاں کرنے کے بعد یونٹ ٹیسٹ چلانے سے یہ یقینی بنتا ہے کہ نئی منطق شامل کرنے سے غلطیاں پیدا نہ ہوں۔ موثر یونٹ ٹیسٹ چلانے کے لیے ذیل میں کچھ رہنما خطوط ہیں: + +#### اسمارٹ معاہدوں کی یونٹ ٹیسٹنگ کے لیے رہنما خطوط {#unit-testing-guidelines} + +##### 1۔ اپنے معاہدوں کی کاروباری منطق اور ورک فلو کو سمجھیں + +یونٹ ٹیسٹ لکھنے سے پہلے، یہ جاننے میں مدد ملتی ہے کہ ایک اسمارٹ معاہدہ کون سی فعالیتیں پیش کرتا ہے اور صارف ان فنکشنز تک کیسے رسائی حاصل کریں گے اور استعمال کریں گے۔ یہ خاص طور پر [ہیپی پاتھ ٹیسٹ](https://en.m.wikipedia.org/wiki/Happy_path) چلانے کے لیے مفید ہے جو اس بات کا تعین کرتے ہیں کہ آیا معاہدے میں فنکشنز درست صارف ان پٹس کے لیے صحیح آؤٹ پٹ لوٹاتے ہیں۔ ہم اس تصور کو [نیلامی کے معاہدے](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) کی اس (مختصر) مثال کا استعمال کرتے ہوئے بیان کریں گے۔ + +```solidity +constructor( + uint biddingTime, + address payable beneficiaryAddress + ) { + beneficiary = beneficiaryAddress; + auctionEndTime = block.timestamp + biddingTime; + } + +function bid() external payable { + + if (block.timestamp > auctionEndTime) + revert AuctionAlreadyEnded(); + + if (msg.value <= highestBid) + revert BidNotHighEnough(highestBid); + + if (highestBid != 0) { + pendingReturns[highestBidder] += highestBid; + } + highestBidder = msg.sender; + highestBid = msg.value; + emit HighestBidIncreased(msg.sender, msg.value); + } + + function withdraw() external returns (bool) { + uint amount = pendingReturns[msg.sender]; + if (amount > 0) { + pendingReturns[msg.sender] = 0; + + if (!payable(msg.sender).send(amount)) { + pendingReturns[msg.sender] = amount; + return false; + } + } + return true; + } + +function auctionEnd() external { + if (block.timestamp < auctionEndTime) + revert AuctionNotYetEnded(); + if (ended) + revert AuctionEndAlreadyCalled(); + + ended = true; + emit AuctionEnded(highestBidder, highestBid); + + beneficiary.transfer(highestBid); + } +} +``` + +یہ ایک سادہ نیلامی کا معاہدہ ہے جو بولی کی مدت کے دوران بولیاں وصول کرنے کے لیے ڈیزائن کیا گیا ہے۔ اگر `highestBid` بڑھ جاتی ہے، تو پچھلا سب سے زیادہ بولی لگانے والا اپنی رقم وصول کرتا ہے؛ بولی کی مدت ختم ہونے کے بعد، `beneficiary` اپنی رقم حاصل کرنے کے لیے معاہدے کو کال کرتا ہے۔ + +اس طرح کے معاہدے کے لیے یونٹ ٹیسٹ مختلف فنکشنز کا احاطہ کریں گے جنہیں صارف معاہدے کے ساتھ تعامل کرتے وقت کال کر سکتا ہے۔ ایک مثال ایک یونٹ ٹیسٹ ہوگا جو جانچتا ہے کہ آیا کوئی صارف نیلامی جاری رہنے کے دوران بولی لگا سکتا ہے (یعنی، `bid()` کی کالیں کامیاب ہوتی ہیں) یا ایک جو جانچتا ہے کہ آیا کوئی صارف موجودہ `highestBid` سے زیادہ بولی لگا سکتا ہے۔ + +معاہدے کے آپریشنل ورک فلو کو سمجھنا بھی یونٹ ٹیسٹ لکھنے میں مدد کرتا ہے جو جانچتے ہیں کہ آیا عمل درآمد ضروریات کو پورا کرتا ہے۔ مثال کے طور پر، نیلامی کا معاہدہ یہ بتاتا ہے کہ جب نیلامی ختم ہو چکی ہو تو صارف بولیاں نہیں لگا سکتے (یعنی، جب `auctionEndTime` `block.timestamp` سے کم ہو)۔ اس طرح، ایک ڈیولپر ایک یونٹ ٹیسٹ چلا سکتا ہے جو جانچتا ہے کہ نیلامی ختم ہونے پر `bid()` فنکشن کی کالیں کامیاب ہوتی ہیں یا ناکام (یعنی، جب `auctionEndTime` > `block.timestamp`)۔ + +##### 2۔ معاہدے کے عمل درآمد سے متعلق تمام مفروضوں کا جائزہ لیں + +معاہدے کے عمل درآمد کے بارے میں کسی بھی مفروضے کو دستاویز کرنا اور ان مفروضوں کی درستگی کی تصدیق کے لیے یونٹ ٹیسٹ لکھنا ضروری ہے۔ غیر متوقع عمل درآمد کے خلاف تحفظ فراہم کرنے کے علاوہ، جانچ کے دعوے آپ کو ان کارروائیوں کے بارے میں سوچنے پر مجبور کرتے ہیں جو اسمارٹ معاہدے کے سیکورٹی ماڈل کو توڑ سکتی ہیں۔ ایک مفید ٹپ یہ ہے کہ "خوش صارف ٹیسٹ" سے آگے بڑھیں اور منفی ٹیسٹ لکھیں جو جانچتے ہیں کہ آیا کوئی فنکشن غلط ان پٹس کے لیے ناکام ہوتا ہے۔ + +بہت سے یونٹ ٹیسٹنگ فریم ورک آپ کو دعوے بنانے کی اجازت دیتے ہیں—سادہ بیانات جو بتاتے ہیں کہ ایک معاہدہ کیا کر سکتا ہے اور کیا نہیں—اور یہ دیکھنے کے لیے ٹیسٹ چلاتے ہیں کہ آیا وہ دعوے عمل درآمد کے تحت درست ہیں۔ پہلے بیان کردہ نیلامی کے معاہدے پر کام کرنے والا ایک ڈیولپر منفی ٹیسٹ چلانے سے پہلے اس کے رویے کے بارے میں درج ذیل دعوے کر سکتا ہے: + +- صارفین نیلامی ختم ہونے یا شروع نہ ہونے پر بولیاں نہیں لگا سکتے۔ + +- اگر بولی قابل قبول حد سے کم ہو تو نیلامی کا معاہدہ واپس ہو جاتا ہے۔ + +- جو صارف بولی جیتنے میں ناکام رہتے ہیں انہیں ان کے فنڈز واپس کر دیے جاتے ہیں + +**نوٹ**: مفروضوں کی جانچ کا ایک اور طریقہ یہ ہے کہ ایسے ٹیسٹ لکھیں جو معاہدے میں [فنکشن موڈیفائرز](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) کو متحرک کریں، خاص طور پر `require`، `assert`، اور `if…else` بیانات۔ + +##### 3۔ کوڈ کوریج کی پیمائش کریں + +[کوڈ کوریج](https://en.m.wikipedia.org/wiki/Code_coverage) ایک جانچ کا میٹرک ہے جو ٹیسٹ کے دوران آپ کے کوڈ میں عمل میں لائی گئی شاخوں، لائنوں، اور بیانات کی تعداد کو ٹریک کرتا ہے۔ غیر جانچ شدہ کمزوریوں کے خطرے کو کم کرنے کے لیے ٹیسٹوں میں اچھی کوڈ کوریج ہونی چاہیے۔ ناکافی کوریج کے بغیر، آپ غلطی سے یہ فرض کر سکتے ہیں کہ آپ کا معاہدہ محفوظ ہے کیونکہ تمام ٹیسٹ پاس ہو جاتے ہیں، جبکہ غیر جانچ شدہ کوڈ پاتھس میں کمزوریاں اب بھی موجود ہیں۔ تاہم، اعلی کوڈ کوریج ریکارڈ کرنے سے یہ یقین دہانی ہوتی ہے کہ اسمارٹ معاہدے میں تمام بیانات/فنکشنز کی درستگی کے لیے کافی جانچ کی گئی تھی۔ + +##### 4. اچھی طرح سے تیار کردہ جانچ کے فریم ورک استعمال کریں + +آپ کے اسمارٹ معاہدوں کے لیے یونٹ ٹیسٹ چلانے میں استعمال ہونے والے ٹولز کا معیار بہت اہم ہے۔ ایک مثالی جانچ کا فریم ورک وہ ہے جو باقاعدگی سے برقرار رکھا جاتا ہو؛ مفید خصوصیات (مثلاً، لاگنگ اور رپورٹنگ کی صلاحیتیں) فراہم کرتا ہو؛ اور دوسرے ڈیولپرز کے ذریعہ بڑے پیمانے پر استعمال اور جانچا گیا ہو۔ + +Solidity اسمارٹ معاہدوں کے لیے یونٹ ٹیسٹنگ فریم ورک مختلف زبانوں (زیادہ تر JavaScript، Python، اور Rust) میں آتے ہیں۔ مختلف جانچ کے فریم ورک کے ساتھ یونٹ ٹیسٹ چلانا شروع کرنے کے طریقے کے بارے میں معلومات کے لیے ذیل میں کچھ گائیڈز دیکھیں: + +- **[Brownie کے ساتھ یونٹ ٹیسٹ چلانا](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** +- **[Foundry کے ساتھ یونٹ ٹیسٹ چلانا](https://book.getfoundry.sh/forge/writing-tests)** +- **[Waffle کے ساتھ یونٹ ٹیسٹ چلانا](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** +- **[Remix کے ساتھ یونٹ ٹیسٹ چلانا](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** +- **[Ape کے ساتھ یونٹ ٹیسٹ چلانا](https://docs.apeworx.io/ape/stable/userguides/testing.html)** +- **[Hardhat کے ساتھ یونٹ ٹیسٹ چلانا](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** +- **[Wake کے ساتھ یونٹ ٹیسٹ چلانا](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** + +### انٹیگریشن ٹیسٹنگ {#integration-testing-for-smart-contracts} + +جبکہ یونٹ ٹیسٹنگ معاہدے کے افعال کو الگ تھلگ میں ڈیبگ کرتی ہے، انٹیگریشن ٹیسٹ اسمارٹ معاہدے کے اجزاء کا مجموعی طور پر جائزہ لیتے ہیں۔ انٹیگریشن ٹیسٹنگ کراس-کنٹریکٹ کالز یا ایک ہی اسمارٹ معاہدے میں مختلف فنکشنز کے درمیان تعامل سے پیدا ہونے والے مسائل کا پتہ لگا سکتی ہے۔ مثال کے طور پر، انٹیگریشن ٹیسٹ یہ جانچنے میں مدد کر سکتے ہیں کہ آیا [وراثت](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) اور ڈیپنڈنسی انجیکشن جیسی چیزیں ٹھیک سے کام کرتی ہیں۔ + +انٹیگریشن ٹیسٹنگ مفید ہے اگر آپ کا معاہدہ ایک ماڈیولر فن تعمیر کو اپناتا ہے یا عمل درآمد کے دوران دوسرے آن چین معاہدوں کے ساتھ انٹرفیس کرتا ہے۔ انٹیگریشن ٹیسٹ چلانے کا ایک طریقہ یہ ہے کہ [بلاک چین کو فورک کریں](/glossary/#fork) ایک مخصوص اونچائی پر ([Forge](https://book.getfoundry.sh/forge/fork-testing) یا [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) جیسے ٹول کا استعمال کرتے ہوئے) اور اپنے معاہدے اور تعینات کردہ معاہدوں کے درمیان تعاملات کی نقالی کریں۔ + +فورک شدہ بلاک چین Mainnet کی طرح برتاؤ کرے گا اور اس میں متعلقہ ریاستوں اور بیلنس والے اکاؤنٹس ہوں گے۔ لیکن یہ صرف ایک سینڈ باکسڈ مقامی ترقیاتی ماحول کے طور پر کام کرتا ہے، یعنی آپ کو لین دین کے لیے حقیقی ETH کی ضرورت نہیں ہوگی، مثال کے طور پر، اور نہ ہی آپ کی تبدیلیاں حقیقی Ethereum پروٹوکول کو متاثر کریں گی۔ + +### پراپرٹی پر مبنی ٹیسٹنگ {#property-based-testing-for-smart-contracts} + +پراپرٹی پر مبنی ٹیسٹنگ اس بات کی جانچ کا عمل ہے کہ ایک اسمارٹ معاہدہ کچھ متعین کردہ پراپرٹی کو پورا کرتا ہے۔ پراپرٹیز معاہدے کے رویے کے بارے میں حقائق کا دعویٰ کرتی ہیں جن سے مختلف منظرناموں میں سچ رہنے کی توقع کی جاتی ہے—اسمارٹ معاہدے کی پراپرٹی کی ایک مثال یہ ہو سکتی ہے کہ "معاہدے میں ریاضی کے آپریشنز کبھی اوور فلو یا انڈر فلو نہیں ہوتے۔" + +**اسٹیٹک تجزیہ** اور **متحرک تجزیہ** پراپرٹی پر مبنی ٹیسٹنگ کو انجام دینے کے لیے دو عام تکنیکیں ہیں، اور دونوں اس بات کی تصدیق کر سکتی ہیں کہ کسی پروگرام کا کوڈ (اس معاملے میں ایک اسمارٹ معاہدہ) کچھ پہلے سے طے شدہ پراپرٹی کو پورا کرتا ہے۔ کچھ پراپرٹی پر مبنی ٹیسٹنگ ٹولز متوقع معاہدے کی پراپرٹیز کے بارے میں پہلے سے طے شدہ قوانین کے ساتھ آتے ہیں اور ان قوانین کے خلاف کوڈ کو چیک کرتے ہیں، جبکہ دیگر آپ کو اسمارٹ معاہدے کے لیے اپنی مرضی کی پراپرٹیز بنانے کی اجازت دیتے ہیں۔ + +#### اسٹیٹک تجزیہ {#static-analysis} + +ایک اسٹیٹک اینالائزر ان پٹ کے طور پر اسمارٹ معاہدے کا سورس کوڈ لیتا ہے اور نتائج آؤٹ پٹ کرتا ہے جو یہ اعلان کرتا ہے کہ آیا کوئی معاہدہ کسی پراپرٹی کو پورا کرتا ہے یا نہیں۔ متحرک تجزیہ کے برعکس، اسٹیٹک تجزیہ میں درستگی کے لیے معاہدے کا تجزیہ کرنے کے لیے اسے عمل میں لانا شامل نہیں ہے۔ اسٹیٹک تجزیہ اس کے بجائے ان تمام ممکنہ راستوں کے بارے میں استدلال کرتا ہے جو ایک اسمارٹ معاہدہ عمل درآمد کے دوران لے سکتا ہے (یعنی، سورس کوڈ کی ساخت کا جائزہ لے کر یہ تعین کرنے کے لیے کہ رن ٹائم پر معاہدے کے آپریشن کے لیے اس کا کیا مطلب ہوگا)۔ + +[Linting](https://www.perforce.com/blog/qac/what-is-linting) اور [static testing](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) معاہدوں پر اسٹیٹک تجزیہ چلانے کے عام طریقے ہیں۔ دونوں کو معاہدے کے عمل درآمد کی نچلی سطح کی نمائندگیوں کا تجزیہ کرنے کی ضرورت ہوتی ہے جیسے کہ [abstract syntax trees](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) اور [control flow graphs](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) جو کمپائلر کے ذریعہ آؤٹ پٹ ہوتے ہیں۔ + +زیادہ تر معاملات میں، اسٹیٹک تجزیہ حفاظتی مسائل کا پتہ لگانے کے لیے مفید ہے جیسے کہ غیر محفوظ تعمیرات کا استعمال، نحو کی غلطیاں، یا معاہدے کے کوڈ میں کوڈنگ کے معیارات کی خلاف ورزیاں۔ تاہم، اسٹیٹک اینالائزرز عام طور پر گہری کمزوریوں کا پتہ لگانے میں غیر صحت مند ہونے کے لیے جانے جاتے ہیں، اور ضرورت سے زیادہ غلط مثبت پیدا کر سکتے ہیں۔ + +#### متحرک تجزیہ {#dynamic-analysis} + +متحرک تجزیہ اسمارٹ معاہدے کے فنکشنز کے لیے علامتی ان پٹس (مثلاً، [علامتی عمل درآمد](https://en.m.wikipedia.org/wiki/Symbolic_execution) میں) یا ٹھوس ان پٹس (مثلاً، [فزنگ](https://owasp.org/www-community/Fuzzing) میں) پیدا کرتا ہے تاکہ یہ دیکھا جا سکے کہ آیا کوئی عمل درآمد کا ٹریس مخصوص خصوصیات کی خلاف ورزی کرتا ہے۔ پراپرٹی پر مبنی ٹیسٹنگ کی یہ شکل یونٹ ٹیسٹ سے اس لحاظ سے مختلف ہے کہ ٹیسٹ کیسز متعدد منظرناموں کا احاطہ کرتے ہیں اور ایک پروگرام ٹیسٹ کیسز کی نسل کو سنبھالتا ہے۔ + +[فزنگ](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing) اسمارٹ معاہدوں میں من مانی خصوصیات کی تصدیق کے لیے ایک متحرک تجزیہ کی تکنیک کی ایک مثال ہے۔ ایک فزر ایک ہدف معاہدے میں فنکشنز کو ایک متعین ان پٹ ویلیو کی بے ترتیب یا خراب تغیرات کے ساتھ طلب کرتا ہے۔ اگر اسمارٹ معاہدہ ایک خرابی کی حالت میں داخل ہوتا ہے (مثلاً، جہاں ایک دعویٰ ناکام ہو جاتا ہے)، تو مسئلہ کو جھنڈا لگا دیا جاتا ہے اور ان پٹس جو عمل درآمد کو کمزور راستے کی طرف لے جاتے ہیں ایک رپورٹ میں تیار کیے جاتے ہیں۔ + +فزنگ اسمارٹ معاہدے کے ان پٹ کی توثیق کے طریقہ کار کا جائزہ لینے کے لیے مفید ہے کیونکہ غیر متوقع ان پٹس کی غلط ہینڈلنگ غیر ارادی عمل درآمد کا باعث بن سکتی ہے اور خطرناک اثرات پیدا کر سکتی ہے۔ پراپرٹی پر مبنی ٹیسٹنگ کی یہ شکل کئی وجوہات کی بنا پر مثالی ہو سکتی ہے: + +1. **بہت سے منظرناموں کا احاطہ کرنے کے لیے ٹیسٹ کیسز لکھنا مشکل ہے۔** ایک پراپرٹی ٹیسٹ صرف یہ چاہتا ہے کہ آپ ایک رویے اور ڈیٹا کی ایک رینج کی وضاحت کریں جس کے ساتھ رویے کی جانچ کی جائے—پروگرام متعین کردہ پراپرٹی کی بنیاد پر خود بخود ٹیسٹ کیسز تیار کرتا ہے۔ + +2. **آپ کا ٹیسٹ سویٹ پروگرام کے اندر تمام ممکنہ راستوں کا کافی حد تک احاطہ نہیں کر سکتا۔** یہاں تک کہ 100٪ کوریج کے ساتھ بھی، ایج کیسز سے محروم رہنا ممکن ہے۔ + +3. **یونٹ ٹیسٹ یہ ثابت کرتے ہیں کہ ایک معاہدہ نمونہ ڈیٹا کے لیے صحیح طریقے سے عمل میں آتا ہے، لیکن کیا معاہدہ نمونے سے باہر کے ان پٹس کے لیے صحیح طریقے سے عمل میں آتا ہے یہ نامعلوم رہتا ہے۔** پراپرٹی ٹیسٹ ایک ہدف معاہدے کو دی گئی ان پٹ ویلیو کی متعدد تغیرات کے ساتھ عمل میں لاتے ہیں تاکہ دعوے کی ناکامی کا سبب بننے والے عمل درآمد کے نشانات تلاش کیے جا سکیں۔ اس طرح، ایک پراپرٹی ٹیسٹ زیادہ ضمانتیں فراہم کرتا ہے کہ ایک معاہدہ ان پٹ ڈیٹا کی ایک وسیع کلاس کے لیے صحیح طریقے سے عمل میں آتا ہے۔ + +### اسمارٹ معاہدوں کے لیے پراپرٹی پر مبنی ٹیسٹنگ چلانے کے لیے رہنما خطوط {#running-property-based-tests} + +پراپرٹی پر مبنی ٹیسٹنگ عام طور پر ایک پراپرٹی (مثلاً، [انٹیجر اوور فلو](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow) کی عدم موجودگی) یا پراپرٹیز کا ایک مجموعہ کی وضاحت کے ساتھ شروع ہوتی ہے جسے آپ اسمارٹ معاہدے میں تصدیق کرنا چاہتے ہیں۔ آپ کو اقدار کی ایک رینج کی وضاحت کرنے کی بھی ضرورت ہو سکتی ہے جس کے اندر پروگرام پراپرٹی ٹیسٹ لکھتے وقت لین دین کے ان پٹس کے لیے ڈیٹا تیار کر سکتا ہے۔ + +ایک بار مناسب طریقے سے ترتیب دینے کے بعد، پراپرٹی ٹیسٹنگ ٹول آپ کے اسمارٹ معاہدے کے فنکشنز کو بے ترتیب طور پر تیار کردہ ان پٹس کے ساتھ عمل میں لائے گا۔ اگر کوئی دعوے کی خلاف ورزی ہوتی ہے، تو آپ کو ٹھوس ان پٹ ڈیٹا کے ساتھ ایک رپورٹ ملنی چاہئے جو زیر تشخیص پراپرٹی کی خلاف ورزی کرتی ہے۔ مختلف ٹولز کے ساتھ پراپرٹی پر مبنی ٹیسٹنگ چلانے کے ساتھ شروع کرنے کے لیے ذیل میں کچھ گائیڈز دیکھیں: + +- **[Slither کے ساتھ اسمارٹ معاہدوں کا اسٹیٹک تجزیہ](https://github.com/crytic/slither)** +- **[Wake کے ساتھ اسمارٹ معاہدوں کا اسٹیٹک تجزیہ](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** +- **[Brownie کے ساتھ پراپرٹی پر مبنی ٹیسٹنگ](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** +- **[Foundry کے ساتھ معاہدوں کی فزنگ](https://book.getfoundry.sh/forge/fuzz-testing)** +- **[Echidna کے ساتھ معاہدوں کی فزنگ](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** +- **[Wake کے ساتھ معاہدوں کی فزنگ](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** +- **[Manticore کے ساتھ اسمارٹ معاہدوں کا علامتی عمل درآمد](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** +- **[Mythril کے ساتھ اسمارٹ معاہدوں کا علامتی عمل درآمد](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** + +## اسمارٹ معاہدوں کے لیے دستی جانچ {#manual-testing-for-smart-contracts} + +اسمارٹ معاہدوں کی دستی جانچ اکثر ترقیاتی سائیکل میں بعد میں آتی ہے جب خودکار ٹیسٹ چلائے جاتے ہیں۔ جانچ کی یہ شکل اسمارٹ معاہدے کا ایک مکمل طور پر مربوط پروڈکٹ کے طور پر جائزہ لیتی ہے تاکہ یہ دیکھا جا سکے کہ آیا یہ تکنیکی ضروریات میں بیان کردہ کے مطابق کارکردگی کا مظاہرہ کرتا ہے۔ + +### مقامی بلاک چین پر معاہدوں کی جانچ {#testing-on-local-blockchain} + +جبکہ مقامی ترقیاتی ماحول میں کی جانے والی خودکار جانچ مفید ڈیبگنگ معلومات فراہم کر سکتی ہے، آپ یہ جاننا چاہیں گے کہ آپ کا اسمارٹ معاہدہ پروڈکشن ماحول میں کیسا برتاؤ کرتا ہے۔ تاہم، مرکزی Ethereum چین پر تعینات کرنے سے گیس کی فیس لگتی ہے—اس بات کا ذکر نہ کرنا کہ اگر آپ کے اسمارٹ معاہدے میں اب بھی بگس ہیں تو آپ یا آپ کے صارف حقیقی رقم کھو سکتے ہیں۔ + +اپنے معاہدے کو مقامی بلاک چین پر جانچنا (جسے [ترقیاتی نیٹ ورک](/developers/docs/development-networks/) بھی کہا جاتا ہے) Mainnet پر جانچنے کا ایک تجویز کردہ متبادل ہے۔ ایک مقامی بلاک چین Ethereum بلاک چین کی ایک کاپی ہے جو آپ کے کمپیوٹر پر مقامی طور پر چلتی ہے جو Ethereum کی عمل درآمد کی سطح کے رویے کی نقالی کرتی ہے۔ اس طرح، آپ اہم اوور ہیڈ کے بغیر معاہدے کے ساتھ تعامل کے لیے لین دین پروگرام کر سکتے ہیں۔ + +مقامی بلاک چین پر معاہدے چلانا دستی انٹیگریشن ٹیسٹنگ کی ایک شکل کے طور پر مفید ہو سکتا ہے۔ [اسمارٹ معاہدے انتہائی ترکیب پذیر ہوتے ہیں](/developers/docs/smart-contracts/composability/)، جو آپ کو موجودہ پروٹوکول کے ساتھ مربوط ہونے کی اجازت دیتے ہیں—لیکن آپ کو اب بھی یہ یقینی بنانا ہوگا کہ اس طرح کے پیچیدہ آن چین تعاملات صحیح نتائج پیدا کریں۔ + +[ترقیاتی نیٹ ورکس کے بارے میں مزید۔](/developers/docs/development-networks/) + +### ٹیسٹ نیٹس پر معاہدوں کی جانچ {#testing-contracts-on-testnets} + +ایک ٹیسٹ نیٹ ورک یا ٹیسٹ نیٹ بالکل Ethereum Mainnet کی طرح کام کرتا ہے، سوائے اس کے کہ یہ ایتھر (ETH) کا استعمال کرتا ہے جس کی کوئی حقیقی دنیا کی قیمت نہیں ہوتی۔ اپنے معاہدے کو [ٹیسٹ نیٹ](/developers/docs/networks/#ethereum-testnets) پر تعینات کرنے کا مطلب ہے کہ کوئی بھی اس کے ساتھ تعامل کر سکتا ہے (مثلاً، dApp کے فرنٹ اینڈ کے ذریعے) بغیر فنڈز کو خطرے میں ڈالے۔ + +دستی جانچ کی یہ شکل صارف کے نقطہ نظر سے آپ کی ایپلی کیشن کے اینڈ ٹو اینڈ فلو کا جائزہ لینے کے لیے مفید ہے۔ یہاں، بیٹا ٹیسٹرز بھی ٹرائل رنز انجام دے سکتے ہیں اور معاہدے کی کاروباری منطق اور مجموعی فعالیت کے ساتھ کسی بھی مسئلے کی اطلاع دے سکتے ہیں۔ + +مقامی بلاک چین پر جانچ کے بعد ٹیسٹ نیٹ پر تعینات کرنا مثالی ہے کیونکہ سابقہ Ethereum ورچوئل مشین کے رویے کے زیادہ قریب ہے۔ لہذا، بہت سے Ethereum-native پروجیکٹس کے لیے یہ عام ہے کہ وہ dapps کو ٹیسٹ نیٹس پر تعینات کریں تاکہ حقیقی دنیا کے حالات میں اسمارٹ معاہدے کے آپریشن کا جائزہ لیا جا سکے۔ + +[Ethereum ٹیسٹ نیٹس کے بارے میں مزید۔](/developers/docs/development-networks/#public-beacon-testchains) + +## جانچ بمقابلہ رسمی تصدیق {#testing-vs-formal-verification} + +جبکہ جانچ اس بات کی تصدیق کرنے میں مدد کرتی ہے کہ ایک معاہدہ کچھ ڈیٹا ان پٹس کے لیے متوقع نتائج لوٹاتا ہے، یہ حتمی طور پر ٹیسٹ کے دوران استعمال نہ ہونے والے ان پٹس کے لیے اسی کو ثابت نہیں کر سکتا۔ لہذا، اسمارٹ معاہدے کی جانچ "فنکشنل درستگی" کی ضمانت نہیں دے سکتی (یعنی، یہ یہ نہیں دکھا سکتا کہ ایک پروگرام ان پٹ ویلیوز کے _تمام_ سیٹوں کے لیے ضرورت کے مطابق برتاؤ کرتا ہے)۔ + +رسمی تصدیق سافٹ ویئر کی درستگی کا جائزہ لینے کا ایک طریقہ ہے جس میں یہ جانچا جاتا ہے کہ آیا پروگرام کا ایک رسمی ماڈل رسمی تفصیلات سے میل کھاتا ہے۔ ایک رسمی ماڈل ایک پروگرام کی ایک تجریدی ریاضیاتی نمائندگی ہے، جبکہ ایک رسمی تفصیلات ایک پروگرام کی خصوصیات کی وضاحت کرتی ہے (یعنی، پروگرام کے عمل درآمد کے بارے میں منطقی دعوے)۔ + +چونکہ خصوصیات ریاضی کی اصطلاحات میں لکھی جاتی ہیں، اس لیے یہ ممکن ہو جاتا ہے کہ استدلال کے منطقی قوانین کا استعمال کرتے ہوئے اس بات کی تصدیق کی جائے کہ نظام کا ایک رسمی (ریاضیاتی) ماڈل ایک تفصیلات کو پورا کرتا ہے۔ اس طرح، رسمی تصدیق کے ٹولز کے بارے میں کہا جاتا ہے کہ وہ نظام کی درستگی کا 'ریاضیاتی ثبوت' پیش کرتے ہیں۔ + +جانچ کے برعکس، رسمی تصدیق کا استعمال اس بات کی تصدیق کے لیے کیا جا سکتا ہے کہ اسمارٹ معاہدے کا عمل درآمد _تمام_ عمل درآمدوں کے لیے ایک رسمی تفصیلات کو پورا کرتا ہے (یعنی، اس میں کوئی بگ نہیں ہے) بغیر نمونہ ڈیٹا کے ساتھ اسے عمل میں لانے کی ضرورت کے۔ یہ نہ صرف درجنوں یونٹ ٹیسٹ چلانے میں صرف ہونے والے وقت کو کم کرتا ہے، بلکہ یہ چھپی ہوئی کمزوریوں کو پکڑنے میں بھی زیادہ موثر ہے۔ اس نے کہا، رسمی تصدیق کی تکنیکیں ان کے نفاذ کی مشکل اور افادیت کے لحاظ سے ایک سپیکٹرم پر واقع ہیں۔ + +[اسمارٹ معاہدوں کے لیے رسمی تصدیق پر مزید۔](/developers/docs/smart-contracts/formal-verification) + +## جانچ بمقابلہ آڈٹ اور بگ باؤنٹیز {#testing-vs-audits-bug-bounties} + +جیسا کہ ذکر کیا گیا ہے، سخت جانچ شاذ و نادر ہی کسی معاہدے میں بگس کی عدم موجودگی کی ضمانت دے سکتی ہے؛ رسمی تصدیق کے طریقے درستگی کی مضبوط یقین دہانی فراہم کر سکتے ہیں لیکن فی الحال استعمال کرنا مشکل ہیں اور کافی اخراجات آتے ہیں۔ + +پھر بھی، آپ ایک آزاد کوڈ کا جائزہ لے کر معاہدے کی کمزوریوں کو پکڑنے کے امکان کو مزید بڑھا سکتے ہیں۔ [اسمارٹ معاہدے کے آڈٹ](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) اور [بگ باؤنٹیز](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) آپ کے معاہدوں کا تجزیہ کرنے کے لیے دوسروں کو حاصل کرنے کے دو طریقے ہیں۔ + +آڈٹ ان آڈیٹرز کے ذریعہ انجام دیئے جاتے ہیں جو اسمارٹ معاہدوں میں سیکورٹی کی خامیوں اور ناقص ترقیاتی طریقوں کے معاملات تلاش کرنے میں تجربہ کار ہوتے ہیں۔ ایک آڈٹ میں عام طور پر جانچ (اور ممکنہ طور پر رسمی تصدیق) کے ساتھ ساتھ پورے کوڈ بیس کا دستی جائزہ بھی شامل ہوگا۔ + +اس کے برعکس، ایک بگ باؤنٹی پروگرام میں عام طور پر کسی فرد کو مالی انعام کی پیشکش شامل ہوتی ہے (عام طور پر [وائٹ ہیٹ ہیکرز](https://en.wikipedia.org/wiki/White_hat_\(computer_security\)) کے طور پر بیان کیا جاتا ہے) جو اسمارٹ معاہدے میں کمزوری کو دریافت کرتا ہے اور اسے ڈیولپرز کو ظاہر کرتا ہے۔ بگ باؤنٹیز آڈٹ سے ملتے جلتے ہیں کیونکہ اس میں دوسروں سے اسمارٹ معاہدوں میں نقائص تلاش کرنے میں مدد کرنے کے لیے کہا جاتا ہے۔ + +بڑا فرق یہ ہے کہ بگ باؤنٹی پروگرام وسیع تر ڈیولپر/ہیکر کمیونٹی کے لیے کھلے ہیں اور منفرد مہارت اور تجربے کے ساتھ اخلاقی ہیکرز اور آزاد سیکورٹی پیشہ ور افراد کی ایک وسیع کلاس کو اپنی طرف متوجہ کرتے ہیں۔ یہ اسمارٹ معاہدے کے آڈٹ پر ایک فائدہ ہو سکتا ہے جو بنیادی طور پر ان ٹیموں پر انحصار کرتے ہیں جن کے پاس محدود یا تنگ مہارت ہو سکتی ہے۔ + +## جانچ کے ٹولز اور لائبریریاں {#testing-tools-and-libraries} + +### یونٹ ٹیسٹنگ ٹولز {#unit-testing-tools} + +- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidity میں لکھے گئے اسمارٹ معاہدوں کے لیے کوڈ کوریج ٹول۔_ + +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _جدید اسمارٹ معاہدے کی ترقی اور جانچ کے لیے فریم ورک (ethers.js پر مبنی)۔_ + +- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidity اسمارٹ معاہدوں کی جانچ کے لیے ٹول۔ Remix IDE "Solidity Unit Testing" پلگ ان کے تحت کام کرتا ہے جو معاہدے کے لیے ٹیسٹ کیسز لکھنے اور چلانے کے لیے استعمال ہوتا ہے۔_ + +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _Ethereum اسمارٹ معاہدے کی جانچ کے لیے دعوے کی لائبریری۔ یقینی بنائیں کہ آپ کے معاہدے توقع کے مطابق برتاؤ کرتے ہیں!_ + +- **[Brownie unit testing framework](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie Pytest کا استعمال کرتا ہے، جو ایک خصوصیت سے بھرپور ٹیسٹ فریم ورک ہے جو آپ کو کم سے کم کوڈ کے ساتھ چھوٹے ٹیسٹ لکھنے دیتا ہے، بڑے پروجیکٹس کے لیے اچھی طرح سے اسکیل کرتا ہے، اور انتہائی قابل توسیع ہے۔_ + +- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry Forge پیش کرتا ہے، جو ایک تیز اور لچکدار Ethereum ٹیسٹنگ فریم ورک ہے جو سادہ یونٹ ٹیسٹ، گیس کی اصلاح کی جانچ، اور معاہدے کی فزنگ کو انجام دینے کی صلاحیت رکھتا ہے۔_ + +- **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _ethers.js, Mocha, اور Chai پر مبنی اسمارٹ معاہدوں کی جانچ کے لیے فریم ورک۔_ + +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _Ethereum ورچوئل مشین کو ہدف بنانے والے اسمارٹ معاہدوں کے لیے Python پر مبنی ترقی اور جانچ کا فریم ورک۔_ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _بہترین صارف کے تجربے اور کارکردگی کے لیے pytest اور Anvil کا استعمال کرتے ہوئے، مضبوط ڈیبگنگ صلاحیتوں اور کراس چین ٹیسٹنگ سپورٹ کے ساتھ یونٹ ٹیسٹنگ اور فزنگ کے لیے Python پر مبنی فریم ورک۔_ + +### پراپرٹی پر مبنی ٹیسٹنگ ٹولز {#property-based-testing-tools} + +#### اسٹیٹک تجزیہ ٹولز {#static-analysis-tools} + +- **[Slither](https://github.com/crytic/slither)** - _کمزوریوں کو تلاش کرنے، کوڈ کی تفہیم کو بڑھانے، اور اسمارٹ معاہدوں کے لیے اپنی مرضی کے مطابق تجزیے لکھنے کے لیے Python پر مبنی Solidity اسٹیٹک تجزیہ فریم ورک۔_ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Solidity اسمارٹ معاہدے کی پروگرامنگ زبان کے لیے اسٹائل اور سیکورٹی کے بہترین طریقوں کو نافذ کرنے کے لیے Linter۔_ + +- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Rust پر مبنی اسٹیٹک اینالائزر خاص طور پر Web3 اسمارٹ معاہدے کی سیکورٹی اور ترقی کے لیے ڈیزائن کیا گیا ہے۔_ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _کمزوری اور کوڈ کے معیار کے ڈیٹیکٹرز کے ساتھ Python پر مبنی اسٹیٹک تجزیہ فریم ورک، کوڈ سے مفید معلومات نکالنے کے لیے پرنٹرز اور اپنی مرضی کے مطابق سب ماڈیولز لکھنے کے لیے سپورٹ۔_ + +- **[Slippy](https://github.com/fvictorio/slippy)** - _Solidity کے لیے ایک سادہ اور طاقتور linter۔_ + +#### متحرک تجزیہ ٹولز {#dynamic-analysis-tools} + +- **[Echidna](https://github.com/crytic/echidna/)** - _پراپرٹی پر مبنی ٹیسٹنگ کے ذریعے اسمارٹ معاہدوں میں کمزوریوں کا پتہ لگانے کے لیے تیز معاہدہ فزر۔_ + +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _اسمارٹ معاہدے کے کوڈ میں پراپرٹی کی خلاف ورزیوں کا پتہ لگانے کے لیے مفید خودکار فزنگ ٹول۔_ + +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _EVM بائٹ کوڈ کا تجزیہ کرنے کے لیے متحرک علامتی عمل درآمد کا فریم ورک۔_ + +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _ٹینٹ تجزیہ، کونکولک تجزیہ، اور کنٹرول فلو چیکنگ کا استعمال کرتے ہوئے معاہدے کی کمزوریوں کا پتہ لگانے کے لیے EVM بائٹ کوڈ کی تشخیص کا ٹول۔_ + +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble ایک تفصیلات کی زبان اور رن ٹائم تصدیق کا ٹول ہے جو آپ کو اسمارٹ معاہدوں کو ایسی خصوصیات کے ساتھ تشریح کرنے کی اجازت دیتا ہے جو آپ کو Diligence Fuzzing یا MythX جیسے ٹولز کے ساتھ معاہدوں کی خود بخود جانچ کرنے کی اجازت دیتی ہیں۔_ + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [مختلف جانچ کی مصنوعات کا ایک جائزہ اور موازنہ](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ +- [اسمارٹ معاہدوں کی جانچ کے لیے Echidna کا استعمال کیسے کریں](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) +- [اسمارٹ کنٹریکٹ بگز تلاش کرنے کے لیے Manticore کا استعمال کیسے کریں](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [اسمارٹ کنٹریکٹ بگز تلاش کرنے کے لیے Slither کا استعمال کیسے کریں](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [جانچ کے لیے Solidity معاہدوں کو کیسے موک کریں](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) +- [Foundry کا استعمال کرتے ہوئے Solidity میں یونٹ ٹیسٹ کیسے چلائیں](https://www.rareskills.io/post/foundry-testing-solidity) + +## مزید پڑھیں {#further-reading} + +- [ایتھیریم اسمارٹ معاہدوں کی جانچ کے لیے ایک گہرا گائیڈ](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) +- [ایتھیریم اسمارٹ معاہدوں کی جانچ کیسے کریں](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) +- [ڈیولپرز کے لیے MolochDAO کا یونٹ ٹیسٹنگ گائیڈ](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) +- [اسمارٹ معاہدوں کو ایک راک اسٹار کی طرح کیسے جانچیں](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/ur/developers/docs/smart-contracts/upgrading/index.md new file mode 100644 index 00000000000..0575d08631c --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/upgrading/index.md @@ -0,0 +1,165 @@ +--- +title: "اسمارٹ کانٹریکٹس کو اپ گریڈ کرنا" +description: "Ethereum اسمارٹ کانٹریکٹس کے لیے اپ گریڈ پیٹرنز کا ایک جائزہ" +lang: ur-in +--- + +Ethereum پر اسمارٹ کانٹریکٹس خود کار طریقے سے عمل درآمد کرنے والے پروگرام ہیں جو Ethereum ورچوئل مشین (EVM) میں چلتے ہیں۔ یہ پروگرامز ڈیزائن کے لحاظ سے ناقابل تغیر ہیں، جو ایک بار کانٹریکٹ کے تعینات ہونے کے بعد کاروباری منطق میں کسی بھی اپ ڈیٹ کو روکتا ہے۔ + +اگرچہ اسمارٹ کانٹریکٹس کی بے اعتمادی، غیر مرکزیت، اور سیکورٹی کے لیے ناقابل تغیر ہونا ضروری ہے، لیکن یہ بعض صورتوں میں ایک خامی ہو سکتی ہے۔ مثال کے طور پر، ناقابل تغیر کوڈ ڈیولپرز کے لیے کمزور کانٹریکٹس کو ٹھیک کرنا ناممکن بنا سکتا ہے۔ + +تاہم، اسمارٹ کانٹریکٹس کو بہتر بنانے کی تحقیق میں اضافے نے کئی اپ گریڈ پیٹرنز کو متعارف کرایا ہے۔ یہ اپ گریڈ پیٹرنز ڈیولپرز کو مختلف کانٹریکٹس میں کاروباری منطق رکھ کر اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے (ناقابل تغیر کو برقرار رکھتے ہوئے) کے قابل بناتے ہیں۔ + +## شرائط {#prerequisites} + +آپ کو [اسمارٹ کانٹریکٹس](/developers/docs/smart-contracts/)، [اسمارٹ کانٹریکٹ کی اناٹومی](/developers/docs/smart-contracts/anatomy/)، اور [ایتھریم ورچوئل مشین (EVM)](/developers/docs/evm/) کی اچھی سمجھ ہونی چاہیے۔ یہ گائیڈ یہ بھی فرض کرتا ہے کہ قارئین کو اسمارٹ کانٹریکٹس کی پروگرامنگ پر گرفت حاصل ہے۔ + +## اسمارٹ کانٹریکٹ اپ گریڈ کیا ہے؟ {#what-is-a-smart-contract-upgrade} + +ایک اسمارٹ کانٹریکٹ اپ گریڈ میں کانٹریکٹ کی حالت کو محفوظ رکھتے ہوئے اسمارٹ کانٹریکٹ کی کاروباری منطق کو تبدیل کرنا شامل ہے۔ یہ واضح کرنا ضروری ہے کہ اپ گریڈ کی اہلیت اور تغیر پذیری ایک جیسی نہیں ہیں، خاص طور پر اسمارٹ کانٹریکٹس کے تناظر میں۔ + +آپ اب بھی Ethereum نیٹ ورک پر کسی ایڈریس پر تعینات کردہ پروگرام کو تبدیل نہیں کر سکتے ہیں۔ لیکن آپ اس کوڈ کو تبدیل کر سکتے ہیں جو اس وقت عمل میں آتا ہے جب صارفین ایک اسمارٹ کانٹریکٹ کے ساتھ تعامل کرتے ہیں۔ + +یہ مندرجہ ذیل طریقوں سے کیا جا سکتا ہے: + +1. ایک اسمارٹ کانٹریکٹ کے متعدد ورژنز بنانا اور پرانے کانٹریکٹ سے کانٹریکٹ کی ایک نئی مثال میں حالت (یعنی، ڈیٹا) کو منتقل کرنا۔ + +2. کاروباری منطق اور حالت کو ذخیرہ کرنے کے لیے علیحدہ کانٹریکٹس بنانا۔ + +3. ایک ناقابل تغیر پراکسی کانٹریکٹ سے ایک قابل ترمیم منطقی کانٹریکٹ تک فنکشن کالز کو تفویض کرنے کے لیے پراکسی پیٹرنز کا استعمال کرنا۔ + +4. ایک ناقابل تغیر مرکزی کانٹریکٹ بنانا جو مخصوص فنکشنز کو انجام دینے کے لیے لچکدار سیٹلائٹ کانٹریکٹس کے ساتھ انٹرفیس کرتا ہے اور ان پر انحصار کرتا ہے۔ + +5. پراکسی کانٹریکٹ سے منطقی کانٹریکٹس تک فنکشن کالز کو تفویض کرنے کے لیے ڈائمنڈ پیٹرن کا استعمال کرنا۔ + +### اپ گریڈ میکانزم #1: کانٹریکٹ کی منتقلی {#contract-migration} + +کانٹریکٹ کی منتقلی ورژننگ پر مبنی ہے — یعنی ایک ہی سافٹ ویئر کی منفرد حالتوں کو بنانے اور ان کا انتظام کرنے کا خیال۔ کانٹریکٹ کی منتقلی میں ایک موجودہ اسمارٹ کانٹریکٹ کی نئی مثال کو تعینات کرنا اور نئے کانٹریکٹ میں اسٹوریج اور بیلنس منتقل کرنا شامل ہے۔ + +نئے تعینات کردہ کانٹریکٹ میں ایک خالی اسٹوریج ہوگا، جو آپ کو پرانے کانٹریکٹ سے ڈیٹا بازیافت کرنے اور اسے نئے نفاذ میں لکھنے کی اجازت دیتا ہے۔ اس کے بعد، آپ کو ان تمام کانٹریکٹس کو اپ ڈیٹ کرنے کی ضرورت ہوگی جنہوں نے پرانے کانٹریکٹ کے ساتھ تعامل کیا تھا تاکہ وہ نئے ایڈریس کی عکاسی کریں۔ + +کانٹریکٹ کی منتقلی کا آخری مرحلہ صارفین کو نئے کانٹریکٹ کا استعمال شروع کرنے کے لیے قائل کرنا ہے۔ نیا کانٹریکٹ ورژن صارف کے بیلنس اور ایڈریسز کو برقرار رکھے گا، جو ناقابل تغیر کو محفوظ رکھتا ہے۔ اگر یہ ٹوکن پر مبنی کانٹریکٹ ہے، تو آپ کو پرانے کانٹریکٹ کو مسترد کرنے اور نئے کانٹریکٹ کو استعمال کرنے کے لیے ایکسچینجز سے بھی رابطہ کرنا ہوگا۔ + +صارف کے تعاملات میں خلل ڈالے بغیر اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کے لیے کانٹریکٹ کی منتقلی ایک نسبتاً سیدھا اور محفوظ اقدام ہے۔ تاہم، نئے کانٹریکٹ میں صارف کے اسٹوریج اور بیلنس کو دستی طور پر منتقل کرنا وقت طلب ہے اور اس میں گیس کی زیادہ لاگت آ سکتی ہے۔ + +[کانٹریکٹ کی منتقلی کے بارے میں مزید۔](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) + +### اپ گریڈ میکانزم #2: ڈیٹا کی علیحدگی {#data-separation} + +اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کا ایک اور طریقہ کاروباری منطق اور ڈیٹا اسٹوریج کو علیحدہ کانٹریکٹس میں تقسیم کرنا ہے۔ اس کا مطلب ہے کہ صارفین منطقی کانٹریکٹ کے ساتھ تعامل کرتے ہیں، جبکہ ڈیٹا اسٹوریج کانٹریکٹ میں ذخیرہ کیا جاتا ہے۔ + +منطقی کانٹریکٹ میں وہ کوڈ ہوتا ہے جو اس وقت عمل میں آتا ہے جب صارفین ایپلیکیشن کے ساتھ تعامل کرتے ہیں۔ یہ اسٹوریج کانٹریکٹ کا ایڈریس بھی رکھتا ہے اور ڈیٹا حاصل کرنے اور سیٹ کرنے کے لیے اس کے ساتھ تعامل کرتا ہے۔ + +دریں اثنا، اسٹوریج کانٹریکٹ اسمارٹ کانٹریکٹ سے وابستہ حالت کو برقرار رکھتا ہے، جیسے کہ صارف کے بیلنس اور ایڈریسز۔ نوٹ کریں کہ اسٹوریج کانٹریکٹ منطقی کانٹریکٹ کی ملکیت ہے اور تعیناتی کے وقت مؤخر الذکر کے ایڈریس کے ساتھ کنفیگر کیا جاتا ہے۔ یہ غیر مجاز کانٹریکٹس کو اسٹوریج کانٹریکٹ کو کال کرنے یا اس کے ڈیٹا کو اپ ڈیٹ کرنے سے روکتا ہے۔ + +پہلے سے طے شدہ طور پر، اسٹوریج کانٹریکٹ ناقابل تغیر ہے—لیکن آپ اس منطقی کانٹریکٹ کو جس کی طرف یہ اشارہ کرتا ہے، ایک نئے نفاذ کے ساتھ بدل سکتے ہیں۔ یہ EVM میں چلنے والے کوڈ کو تبدیل کر دے گا، جبکہ اسٹوریج اور بیلنس کو برقرار رکھا جائے گا۔ + +اس اپ گریڈ کے طریقہ کار کو استعمال کرنے کے لیے اسٹوریج کانٹریکٹ میں منطقی کانٹریکٹ کے ایڈریس کو اپ ڈیٹ کرنا ضروری ہے۔ پہلے بیان کردہ وجوہات کی بنا پر آپ کو نئے منطقی کانٹریکٹ کو اسٹوریج کانٹریکٹ کے ایڈریس کے ساتھ بھی کنفیگر کرنا ہوگا۔ + +کانٹریکٹ کی منتقلی کے مقابلے میں ڈیٹا کی علیحدگی کا پیٹرن بلاشبہ نافذ کرنا آسان ہے۔ تاہم، آپ کو متعدد کانٹریکٹس کا انتظام کرنا ہوگا اور اسمارٹ کانٹریکٹس کو بدنیتی پر مبنی اپ گریڈ سے بچانے کے لیے پیچیدہ اجازت کی اسکیمیں نافذ کرنی ہوں گی۔ + +### اپ گریڈ میکانزم #3: پراکسی پیٹرنز {#proxy-patterns} + +پراکسی پیٹرن کاروباری منطق اور ڈیٹا کو علیحدہ کانٹریکٹس میں رکھنے کے لیے ڈیٹا کی علیحدگی کا بھی استعمال کرتا ہے۔ تاہم، ایک پراکسی پیٹرن میں، اسٹوریج کانٹریکٹ (جسے پراکسی کہا جاتا ہے) کوڈ کے نفاذ کے دوران منطقی کانٹریکٹ کو کال کرتا ہے۔ یہ ڈیٹا کی علیحدگی کے طریقہ کار کا الٹ ہے، جہاں منطقی کانٹریکٹ اسٹوریج کانٹریکٹ کو کال کرتا ہے۔ + +پراکسی پیٹرن میں یہ ہوتا ہے: + +1. صارفین پراکسی کانٹریکٹ کے ساتھ تعامل کرتے ہیں، جو ڈیٹا ذخیرہ کرتا ہے، لیکن کاروباری منطق نہیں رکھتا۔ + +2. پراکسی کانٹریکٹ منطقی کانٹریکٹ کا ایڈریس ذخیرہ کرتا ہے اور `delegatecall` فنکشن کا استعمال کرتے ہوئے تمام فنکشن کالز کو منطقی کانٹریکٹ (جو کاروباری منطق رکھتا ہے) کو تفویض کرتا ہے۔ + +3. کال کو منطقی کانٹریکٹ میں بھیجے جانے کے بعد، منطقی کانٹریکٹ سے واپس آنے والا ڈیٹا بازیافت کیا جاتا ہے اور صارف کو واپس کر دیا جاتا ہے۔ + +پراکسی پیٹرنز کا استعمال کرنے کے لیے **delegatecall** فنکشن کو سمجھنا ضروری ہے۔ بنیادی طور پر، `delegatecall` ایک اوپ کوڈ ہے جو ایک کانٹریکٹ کو دوسرے کانٹریکٹ کو کال کرنے کی اجازت دیتا ہے، جبکہ اصل کوڈ کا نفاذ کال کرنے والے کانٹریکٹ کے سیاق و سباق میں ہوتا ہے۔ پراکسی پیٹرنز میں `delegatecall` استعمال کرنے کا ایک مضمر یہ ہے کہ پراکسی کانٹریکٹ اپنے اسٹوریج میں پڑھتا اور لکھتا ہے اور منطقی کانٹریکٹ میں ذخیرہ شدہ منطق کو اس طرح انجام دیتا ہے جیسے کسی اندرونی فنکشن کو کال کر رہا ہو۔ + +[Solidity دستاویزات](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries) سے: + +> _میسج کال کی ایک خاص قسم موجود ہے، جسے **delegatecall** کہا جاتا ہے جو میسج کال کی طرح ہی ہے سوائے اس کے کہ ٹارگٹ ایڈریس پر موجود کوڈ کال کرنے والے کانٹریکٹ کے سیاق و سباق (یعنی، ایڈریس پر) میں عمل میں آتا ہے اور `msg.sender` اور `msg.value` اپنی قدریں تبدیل نہیں کرتے۔_ _اس کا مطلب یہ ہے کہ ایک کانٹریکٹ رن ٹائم پر ایک مختلف ایڈریس سے کوڈ کو متحرک طور پر لوڈ کر سکتا ہے۔_ اسٹوریج، موجودہ ایڈریس اور بیلنس اب بھی کال کرنے والے کانٹریکٹ کا حوالہ دیتے ہیں، صرف کوڈ کال کیے گئے ایڈریس سے لیا جاتا ہے۔_ + +پراکسی کانٹریکٹ کو معلوم ہوتا ہے کہ جب بھی کوئی صارف کسی فنکشن کو کال کرتا ہے تو `delegatecall` کو طلب کرنا ہے کیونکہ اس میں ایک `fallback` فنکشن بنایا گیا ہے۔ Solidity پروگرامنگ میں [فال بیک فنکشن](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) اس وقت عمل میں آتا ہے جب کوئی فنکشن کال کسی کانٹریکٹ میں بیان کردہ فنکشنز سے میل نہیں کھاتی۔ + +پراکسی پیٹرن کو کام کرنے کے لیے ایک حسب ضرورت فال بیک فنکشن لکھنا ضروری ہے جو یہ بتاتا ہے کہ پراکسی کانٹریکٹ ان فنکشن کالز کو کیسے ہینڈل کرے گا جن کی وہ حمایت نہیں کرتا۔ اس معاملے میں پراکسی کا فال بیک فنکشن ڈیلیگیٹ کال شروع کرنے اور صارف کی درخواست کو موجودہ منطقی کانٹریکٹ کے نفاذ کی طرف ری روٹ کرنے کے لیے پروگرام کیا گیا ہے۔ + +پراکسی کانٹریکٹ پہلے سے طے شدہ طور پر ناقابل تغیر ہے، لیکن اپ ڈیٹ شدہ کاروباری منطق کے ساتھ نئے منطقی کانٹریکٹ بنائے جا سکتے ہیں۔ اپ گریڈ کرنا پھر پراکسی کانٹریکٹ میں حوالہ کردہ منطقی کانٹریکٹ کا ایڈریس تبدیل کرنے کا معاملہ ہے۔ + +پراکسی کانٹریکٹ کو ایک نئے منطقی کانٹریکٹ کی طرف اشارہ کرکے، جب صارفین پراکسی کانٹریکٹ فنکشن کو کال کرتے ہیں تو عمل میں آنے والا کوڈ تبدیل ہو جاتا ہے۔ یہ ہمیں صارفین سے نئے کانٹریکٹ کے ساتھ تعامل کرنے کے لیے کہے بغیر کسی کانٹریکٹ کی منطق کو اپ گریڈ کرنے کی اجازت دیتا ہے۔ + +پراکسی پیٹرنز اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کا ایک مقبول طریقہ ہیں کیونکہ وہ کانٹریکٹ کی منتقلی سے وابستہ مشکلات کو ختم کرتے ہیں۔ تاہم، پراکسی پیٹرنز کا استعمال زیادہ پیچیدہ ہے اور اگر غلط طریقے سے استعمال کیا جائے تو یہ سنگین خامیاں پیدا کر سکتا ہے، جیسے کہ [فنکشن سلیکٹر کے تصادم](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)۔ + +[پراکسی پیٹرنز کے بارے میں مزید](https://blog.openzeppelin.com/proxy-patterns/)۔ + +### اپ گریڈ میکانزم #4: اسٹریٹیجی پیٹرن {#strategy-pattern} + +یہ تکنیک [اسٹریٹیجی پیٹرن](https://en.wikipedia.org/wiki/Strategy_pattern) سے متاثر ہے، جو ایسے سافٹ ویئر پروگرام بنانے کی ترغیب دیتی ہے جو مخصوص خصوصیات کو نافذ کرنے کے لیے دوسرے پروگراموں کے ساتھ انٹرفیس کرتے ہیں۔ Ethereum کی ڈیولپمنٹ پر اسٹریٹیجی پیٹرن کا اطلاق کرنے کا مطلب ایک ایسا اسمارٹ کانٹریکٹ بنانا ہوگا جو دوسرے کانٹریکٹس سے فنکشنز کو کال کرتا ہے۔ + +اس معاملے میں مرکزی کانٹریکٹ بنیادی کاروباری منطق پر مشتمل ہے، لیکن کچھ مخصوص فنکشنز کو انجام دینے کے لیے دوسرے اسمارٹ کانٹریکٹس ("سیٹلائٹ کانٹریکٹس") کے ساتھ انٹرفیس کرتا ہے۔ یہ مرکزی کانٹریکٹ ہر سیٹلائٹ کانٹریکٹ کا ایڈریس بھی ذخیرہ کرتا ہے اور سیٹلائٹ کانٹریکٹ کے مختلف نفاذ کے درمیان سوئچ کر سکتا ہے۔ + +آپ ایک نیا سیٹلائٹ کانٹریکٹ بنا سکتے ہیں اور مرکزی کانٹریکٹ کو نئے ایڈریس کے ساتھ کنفیگر کر سکتے ہیں۔ یہ آپ کو ایک اسمارٹ کانٹریکٹ کے لیے _اسٹریٹیجیز_ (یعنی، نئی منطق کو نافذ کرنا) کو تبدیل کرنے کی اجازت دیتا ہے۔ + +اگرچہ پہلے زیر بحث پراکسی پیٹرن کی طرح ہے، اسٹریٹیجی پیٹرن مختلف ہے کیونکہ مرکزی کانٹریکٹ، جس کے ساتھ صارفین تعامل کرتے ہیں، کاروباری منطق رکھتا ہے۔ اس پیٹرن کا استعمال آپ کو بنیادی ڈھانچے کو متاثر کیے بغیر ایک اسمارٹ کانٹریکٹ میں محدود تبدیلیاں متعارف کرانے کا موقع فراہم کرتا ہے۔ + +سب سے بڑی خامی یہ ہے کہ یہ پیٹرن زیادہ تر معمولی اپ گریڈز کو نافذ کرنے کے لیے مفید ہے۔ اس کے علاوہ، اگر مرکزی کانٹریکٹ سے سمجھوتہ کیا جاتا ہے (مثلاً، ہیک کے ذریعے)، تو آپ اس اپ گریڈ کے طریقہ کار کو استعمال نہیں کر سکتے۔ + +### اپ گریڈ میکانزم #5: ڈائمنڈ پیٹرن {#diamond-pattern} + +ڈائمنڈ پیٹرن کو پراکسی پیٹرن میں ایک بہتری سمجھا جا سکتا ہے۔ ڈائمنڈ پیٹرنز پراکسی پیٹرنز سے مختلف ہیں کیونکہ ڈائمنڈ پراکسی کانٹریکٹ ایک سے زیادہ منطقی کانٹریکٹس کو فنکشن کالز تفویض کر سکتا ہے۔ + +ڈائمنڈ پیٹرن میں منطقی کانٹریکٹس کو _فیسیٹس_ کے نام سے جانا جاتا ہے۔ ڈائمنڈ پیٹرن کو کام کرنے کے لیے، آپ کو پراکسی کانٹریکٹ میں ایک میپنگ بنانا ہوگی جو [فنکشن سلیکٹرز](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) کو مختلف فیسیٹ ایڈریسز سے میپ کرتی ہے۔ + +جب کوئی صارف فنکشن کال کرتا ہے، تو پراکسی کانٹریکٹ اس فنکشن کو انجام دینے کے لیے ذمہ دار فیسیٹ کو تلاش کرنے کے لیے میپنگ کو چیک کرتا ہے۔ پھر یہ `delegatecall` کو طلب کرتا ہے (فال بیک فنکشن کا استعمال کرتے ہوئے) اور کال کو مناسب منطقی کانٹریکٹ کی طرف ری ڈائریکٹ کرتا ہے۔ + +ڈائمنڈ اپ گریڈ پیٹرن کے روایتی پراکسی اپ گریڈ پیٹرنز کے مقابلے میں کچھ فوائد ہیں: + +1. یہ آپ کو تمام کوڈ کو تبدیل کیے بغیر کانٹریکٹ کے ایک چھوٹے سے حصے کو اپ گریڈ کرنے کی اجازت دیتا ہے۔ اپ گریڈ کے لیے پراکسی پیٹرن کا استعمال کرنے کے لیے ایک بالکل نیا منطقی کانٹریکٹ بنانے کی ضرورت ہوتی ہے، یہاں تک کہ معمولی اپ گریڈ کے لیے بھی۔ + +2. تمام اسمارٹ کانٹریکٹس (بشمول پراکسی پیٹرنز میں استعمال ہونے والے منطقی کانٹریکٹس) کی 24KB سائز کی حد ہوتی ہے، جو ایک حد ہوسکتی ہے — خاص طور پر پیچیدہ کانٹریکٹس کے لیے جن کے لیے زیادہ فنکشنز کی ضرورت ہوتی ہے۔ ڈائمنڈ پیٹرن فنکشنز کو متعدد منطقی کانٹریکٹس میں تقسیم کرکے اس مسئلے کو حل کرنا آسان بناتا ہے۔ + +3. پراکسی پیٹرنز رسائی کے کنٹرول کے لیے ایک جامع نقطہ نظر اپناتے ہیں۔ ایک ادارہ جس کے پاس اپ گریڈ فنکشنز تک رسائی ہے وہ _پورے_ کانٹریکٹ کو تبدیل کر سکتا ہے۔ لیکن ڈائمنڈ پیٹرن ایک ماڈیولر اجازتوں کا نقطہ نظر فراہم کرتا ہے، جہاں آپ اداروں کو اسمارٹ کانٹریکٹ کے اندر کچھ مخصوص فنکشنز کو اپ گریڈ کرنے تک محدود کر سکتے ہیں۔ + +[ڈائمنڈ پیٹرن کے بارے میں مزید](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w)۔ + +## اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کے فائدے اور نقصانات {#pros-and-cons-of-upgrading-smart-contracts} + +| فوائد | نقصانات | +| ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| ایک اسمارٹ کانٹریکٹ اپ گریڈ تعیناتی کے بعد کے مرحلے میں دریافت ہونے والی کمزوریوں کو ٹھیک کرنا آسان بنا سکتا ہے۔ | اسمارٹ کانٹریکٹس کو اپ گریڈ کرنا کوڈ کی ناقابل تغیر ہونے کے خیال کی نفی کرتا ہے، جس کے غیر مرکزیت اور سیکورٹی پر اثرات مرتب ہوتے ہیں۔ | +| ڈیولپرز غیر مرکزی ایپلیکیشنز میں نئی خصوصیات شامل کرنے کے لیے منطقی اپ گریڈ کا استعمال کر سکتے ہیں۔ | صارفین کو ڈیولپرز پر بھروسہ کرنا چاہیے کہ وہ اسمارٹ کانٹریکٹس میں من مانی طور پر ترمیم نہ کریں۔ | +| اسمارٹ کانٹریکٹ اپ گریڈ آخری صارفین کے لیے حفاظت کو بہتر بنا سکتے ہیں کیونکہ کیڑوں کو جلدی ٹھیک کیا جا سکتا ہے۔ | اسمارٹ کانٹریکٹس میں اپ گریڈ کی فعالیت کو پروگرامنگ کرنا پیچیدگی کی ایک اور پرت کا اضافہ کرتا ہے اور سنگین خامیوں کے امکان کو بڑھاتا ہے۔ | +| کانٹریکٹ اپ گریڈ ڈیولپرز کو وقت کے ساتھ مختلف خصوصیات کے ساتھ تجربہ کرنے اور ڈیپس کو بہتر بنانے کے لیے زیادہ گنجائش فراہم کرتے ہیں۔ | اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کا موقع ڈیولپرز کو ڈیولپمنٹ کے مرحلے کے دوران مناسب مستعدی کے بغیر منصوبوں کو تیزی سے شروع کرنے کی ترغیب دے سکتا ہے۔ | +| | اسمارٹ کانٹریکٹس میں غیر محفوظ رسائی کنٹرول یا مرکزیت بدنیتی پر مبنی اداکاروں کے لیے غیر مجاز اپ گریڈ کرنا آسان بنا سکتی ہے۔ | + +## اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کے لیے غور و فکر {#considerations-for-upgrading-smart-contracts} + +1. غیر مجاز اسمارٹ کانٹریکٹ اپ گریڈ کو روکنے کے لیے محفوظ رسائی کنٹرول/ اجازت کے میکانزم کا استعمال کریں، خاص طور پر اگر پراکسی پیٹرن، اسٹریٹیجی پیٹرن، یا ڈیٹا کی علیحدگی کا استعمال کر رہے ہوں۔ ایک مثال یہ ہے کہ اپ گریڈ فنکشن تک رسائی کو محدود کیا جائے، تاکہ صرف کانٹریکٹ کا مالک ہی اسے کال کر سکے۔ + +2. اسمارٹ کانٹریکٹس کو اپ گریڈ کرنا ایک پیچیدہ سرگرمی ہے اور کمزوریوں کے تعارف کو روکنے کے لیے اعلی سطح کی مستعدی کی ضرورت ہوتی ہے۔ + +3. اپ گریڈ کو نافذ کرنے کے عمل کو غیر مرکزی بنا کر اعتماد کے مفروضوں کو کم کریں۔ ممکنہ حکمت عملیوں میں اپ گریڈ کو کنٹرول کرنے کے لیے [ملٹی سگ والیٹ کانٹریکٹ](/developers/docs/smart-contracts/#multisig) کا استعمال، یا [DAO کے اراکین](/dao/) سے اپ گریڈ کی منظوری پر ووٹ ڈالنے کا مطالبہ کرنا شامل ہے۔ + +4. کانٹریکٹس کو اپ گریڈ کرنے میں شامل اخراجات سے آگاہ رہیں۔ مثال کے طور پر، کانٹریکٹ کی منتقلی کے دوران پرانے کانٹریکٹ سے نئے کانٹریکٹ میں حالت (مثلاً، صارف کے بیلنس) کو کاپی کرنے کے لیے ایک سے زیادہ ٹرانزیکشنز کی ضرورت پڑ سکتی ہے، جس کا مطلب ہے زیادہ گیس فیس۔ + +5. صارفین کی حفاظت کے لیے **ٹائم لاکس** کو نافذ کرنے پر غور کریں۔ ٹائم لاک سے مراد کسی سسٹم میں تبدیلیوں پر نافذ کردہ تاخیر ہے۔ اپ گریڈ کو کنٹرول کرنے کے لیے ٹائم لاکس کو ملٹی سگ گورننس سسٹم کے ساتھ ملایا جا سکتا ہے: اگر کوئی مجوزہ کارروائی مطلوبہ منظوری کی حد تک پہنچ جاتی ہے، تو یہ پہلے سے طے شدہ تاخیر کی مدت ختم ہونے تک عمل میں نہیں آتی۔ + +ٹائم لاکس صارفین کو کچھ وقت دیتے ہیں کہ اگر وہ کسی مجوزہ تبدیلی (مثلاً، منطقی اپ گریڈ یا نئی فیس اسکیمیں) سے متفق نہ ہوں تو سسٹم سے باہر نکل جائیں۔ ٹائم لاکس کے بغیر، صارفین کو ڈیولپرز پر بھروسہ کرنے کی ضرورت ہوتی ہے کہ وہ پیشگی اطلاع کے بغیر اسمارٹ کانٹریکٹ میں من مانی تبدیلیاں نہ کریں۔ یہاں خامی یہ ہے کہ ٹائم لاکس کمزوریوں کو جلدی سے ٹھیک کرنے کی صلاحیت کو محدود کرتے ہیں۔ + +## وسائل {#resources} + +**OpenZeppelin Upgrades Plugins - _قابل اپ گریڈ اسمارٹ کانٹریکٹس کو تعینات کرنے اور محفوظ کرنے کے لیے ٹولز کا ایک مجموعہ۔_** + +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades) +- [دستاویزات](https://docs.openzeppelin.com/upgrades) + +## ٹیوٹوریلز {#tutorials} + +- [اپنے اسمارٹ کانٹریکٹس کو اپ گریڈ کرنا | YouTube ٹیوٹوریل](https://www.youtube.com/watch?v=bdXJmWajZRY) بذریعہ Patrick Collins +- [Ethereum اسمارٹ کانٹریکٹ مائیگریشن ٹیوٹوریل](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) بذریعہ Austin Griffith +- [اسمارٹ کانٹریکٹس کو اپ گریڈ کرنے کے لیے UUPS پراکسی پیٹرن کا استعمال](https://blog.logrocket.com/author/praneshas/) بذریعہ Pranesh A.S +- [Web3 ٹیوٹوریل: OpenZeppelin کا استعمال کرتے ہوئے اپ گریڈ کے قابل اسمارٹ کانٹریکٹ (پراکسی) لکھیں](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) بذریعہ fangjun.eth + +## مزید پڑھیں {#further-reading} + +- [اسمارٹ کانٹریکٹ اپ گریڈز کی حالت](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) بذریعہ Santiago Palladino +- [Solidity اسمارٹ کانٹریکٹ کو اپ گریڈ کرنے کے متعدد طریقے](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Crypto Market Pool بلاگ +- [سیکھیں: اسمارٹ کانٹریکٹس کو اپ گریڈ کرنا](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin Docs +- [سولیڈیٹی کانٹریکٹس کی اپ گریڈ ایبلٹی کے لیے پراکسی پیٹرنز: ٹرانسپیرنٹ بمقابلہ UUPS پراکسیز](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) از نوین ساہو +- [ڈائمنڈ اپ گریڈ کیسے کام کرتے ہیں](https://dev.to/mudgen/how-diamond-upgrades-work-417j) از نک میج diff --git a/public/content/translations/ur/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/ur/developers/docs/smart-contracts/verifying/index.md new file mode 100644 index 00000000000..9ce1908aefd --- /dev/null +++ b/public/content/translations/ur/developers/docs/smart-contracts/verifying/index.md @@ -0,0 +1,113 @@ +--- +title: "اسمارٹ کنٹریکٹس کی تصدیق کرنا" +description: "ایتھیریم اسمارٹ کنٹریکٹس کے لیے سورس کوڈ کی توثیق کا ایک جائزہ" +lang: ur-in +--- + +[اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) کو 'بھروسے سے پاک' (trustless) ہونے کے لیے ڈیزائن کیا گیا ہے، جس کا مطلب ہے کہ صارفین کو کسی کنٹریکٹ کے ساتھ تعامل کرنے سے پہلے تیسرے فریقوں (مثلاً، ڈیولپرز اور کمپنیوں) پر بھروسہ کرنے کی ضرورت نہیں ہونی چاہیے۔ بھروسے سے پاک ہونے کی شرط کے طور پر، صارفین اور دیگر ڈیولپرز کو اسمارٹ کنٹریکٹ کے سورس کوڈ کی تصدیق کرنے کے قابل ہونا چاہیے۔ سورس کوڈ کی توثیق صارفین اور ڈیولپرز کو یقین دلاتی ہے کہ شائع شدہ کنٹریکٹ کوڈ وہی کوڈ ہے جو ایتھیریم بلاک چین پر کنٹریکٹ ایڈریس پر چل رہا ہے۔ + +"سورس کوڈ کی توثیق" اور "[رسمی توثیق](/developers/docs/smart-contracts/formal-verification/)" کے درمیان فرق کرنا ضروری ہے۔ سورس کوڈ کی توثیق، جس کی تفصیل ذیل میں بیان کی جائے گی، اس بات کی توثیق کرنے سے مراد ہے کہ ایک اعلیٰ سطحی زبان (مثلاً، Solidity) میں اسمارٹ کنٹریکٹ کا دیا گیا سورس کوڈ اسی بائٹ کوڈ میں کمپائل ہوتا ہے جسے کنٹریکٹ ایڈریس پر عمل میں لایا جانا ہے۔ تاہم، رسمی توثیق ایک اسمارٹ کنٹریکٹ کی درستگی کی توثیق کو بیان کرتی ہے، یعنی کنٹریکٹ توقع کے مطابق برتاؤ کرتا ہے۔ اگرچہ سیاق و سباق پر منحصر ہے، کنٹریکٹ کی توثیق سے مراد عام طور پر سورس کوڈ کی توثیق ہے۔ + +## سورس کوڈ کی توثیق کیا ہے؟ {#what-is-source-code-verification} + +[ایتھیریم ورچوئل مشین (EVM)](/developers/docs/evm/) میں اسمارٹ کنٹریکٹ کو تعینات کرنے سے پہلے، ڈیولپرز کنٹریکٹ کے سورس کوڈ — [Solidity](/developers/docs/smart-contracts/languages/) یا کسی دوسری اعلیٰ سطحی پروگرامنگ زبان میں لکھی گئی ہدایات — کو بائٹ کوڈ میں [کمپائل](/developers/docs/smart-contracts/compiling/) کرتے ہیں۔ چونکہ EVM اعلیٰ سطحی ہدایات کی تشریح نہیں کر سکتا، اس لیے EVM میں کنٹریکٹ کی منطق کو نافذ کرنے کے لیے سورس کوڈ کو بائٹ کوڈ (یعنی، نچلی سطح کی، مشین کی ہدایات) میں کمپائل کرنا ضروری ہے۔ + +سورس کوڈ کی توثیق ایک اسمارٹ کنٹریکٹ کے سورس کوڈ اور کنٹریکٹ کی تخلیق کے دوران استعمال ہونے والے کمپائل شدہ بائٹ کوڈ کا موازنہ کرنا ہے تاکہ کسی بھی فرق کا پتہ لگایا جا سکے۔ اسمارٹ کنٹریکٹس کی تصدیق کرنا اس لیے اہم ہے کیونکہ مشتہر کردہ کنٹریکٹ کوڈ اس سے مختلف ہو سکتا ہے جو بلاک چین پر چلتا ہے۔ + +اسمارٹ کنٹریکٹ کی توثیق مشین کوڈ پڑھے بغیر، اس اعلیٰ سطحی زبان کے ذریعے جس میں یہ لکھا گیا ہے، یہ جانچنے کے قابل بناتی ہے کہ ایک کنٹریکٹ کیا کرتا ہے۔ فنکشنز، ویلیوز، اور عام طور پر متغیر کے نام اور تبصرے اصل سورس کوڈ کے ساتھ وہی رہتے ہیں جسے کمپائل اور تعینات کیا جاتا ہے۔ یہ کوڈ کو پڑھنا بہت آسان بنا دیتا ہے۔ سورس کی توثیق کوڈ کی دستاویزات کے لیے بھی سہولت فراہم کرتی ہے، تاکہ اختتامی صارفین جان سکیں کہ ایک اسمارٹ کنٹریکٹ کیا کرنے کے لیے ڈیزائن کیا گیا ہے۔ + +### مکمل توثیق کیا ہے؟ {#full-verification} + +سورس کوڈ کے کچھ حصے ایسے ہیں جو کمپائل شدہ بائٹ کوڈ کو متاثر نہیں کرتے ہیں جیسے تبصرے یا متغیر کے نام۔ اس کا مطلب ہے کہ مختلف متغیر ناموں اور مختلف تبصروں والے دو سورس کوڈز دونوں ایک ہی کنٹریکٹ کی تصدیق کر سکیں گے۔ اس کے ساتھ، ایک بدنیتی پر مبنی اداکار سورس کوڈ کے اندر دھوکہ دہی والے تبصرے شامل کر سکتا ہے یا گمراہ کن متغیر نام دے سکتا ہے اور اصل سورس کوڈ سے مختلف سورس کوڈ کے ساتھ کنٹریکٹ کی تصدیق کروا سکتا ہے۔ + +اس سے بچنا ممکن ہے بائٹ کوڈ میں اضافی ڈیٹا کو شامل کر کے تاکہ سورس کوڈ کی درستگی کے لیے _کرپٹوگرافک گارنٹی_ کے طور پر کام کرے، اور تالیف کی معلومات کے _فنگر پرنٹ_ کے طور پر۔ ضروری معلومات [Solidity کے کنٹریکٹ میٹا ڈیٹا](https://docs.soliditylang.org/en/v0.8.15/metadata.html) میں پائی جاتی ہیں، اور اس فائل کا ہیش ایک کنٹریکٹ کے بائٹ کوڈ میں شامل کیا جاتا ہے۔ آپ اسے [میٹا ڈیٹا پلے گراؤنڈ](https://playground.sourcify.dev) میں عمل میں دیکھ سکتے ہیں + +میٹا ڈیٹا فائل میں کنٹریکٹ کی تالیف کے بارے میں معلومات ہوتی ہیں بشمول سورس فائلیں اور ان کے ہیشز۔ مطلب، اگر کوئی بھی تالیف کی ترتیبات یا یہاں تک کہ سورس فائلوں میں سے کسی ایک میں ایک بائٹ بھی تبدیل ہوتا ہے، تو میٹا ڈیٹا فائل تبدیل ہو جاتی ہے۔ نتیجتاً میٹا ڈیٹا فائل کا ہیش، جو بائٹ کوڈ میں شامل کیا جاتا ہے، بھی تبدیل ہو جاتا ہے۔ اس کا مطلب یہ ہے کہ اگر کسی کنٹریکٹ کا بائٹ کوڈ + اضافی میٹا ڈیٹا ہیش دیے گئے سورس کوڈ اور کمپائلیشن سیٹنگز سے میل کھاتا ہے، تو ہم اس بات کا یقین کر سکتے ہیں کہ یہ بالکل وہی سورس کوڈ ہے جو اصل کمپائلیشن میں استعمال ہوا تھا، یہاں تک کہ ایک بائٹ بھی مختلف نہیں ہے۔ + +اس قسم کی توثیق جو میٹا ڈیٹا ہیش کا فائدہ اٹھاتی ہے اسے **"[مکمل توثیق](https://docs.sourcify.dev/docs/full-vs-partial-match/)"** کہا جاتا ہے (جسے "کامل توثیق" بھی کہتے ہیں)۔ اگر میٹا ڈیٹا ہیشز مماثل نہ ہوں یا تصدیق میں ان پر غور نہ کیا جائے تو یہ ایک "جزوی مماثلت" ہوگی، جو فی الحال کنٹریکٹس کی تصدیق کا زیادہ عام طریقہ ہے۔ مکمل توثیق کے بغیر [بدنیتی پر مبنی کوڈ داخل کرنا](https://samczsun.com/hiding-in-plain-sight/) ممکن ہے جو تصدیق شدہ سورس کوڈ میں ظاہر نہیں ہوگا۔ زیادہ تر ڈیولپرز مکمل توثیق سے واقف نہیں ہیں اور اپنی تالیف کی میٹا ڈیٹا فائل نہیں رکھتے ہیں، اس لیے اب تک کنٹریکٹس کی تصدیق کے لیے جزوی توثیق ہی اصل طریقہ رہا ہے۔ + +## سورس کوڈ کی توثیق کیوں اہم ہے؟ {#importance-of-source-code-verification} + +### بھروسے سے پاک ہونا {#trustlessness} + +بھروسے سے پاک ہونا بلاشبہ اسمارٹ کنٹریکٹس اور [غیر مرکزی ایپلی کیشنز (dapps)](/developers/docs/dapps/) کے لیے سب سے بڑی بنیاد ہے۔ اسمارٹ کنٹریکٹس "ناقابل تغیر" ہیں اور ان میں تبدیلی نہیں کی جا سکتی؛ ایک کنٹریکٹ صرف اس کاروباری منطق کو نافذ کرے گا جو تعیناتی کے وقت کوڈ میں بیان کی گئی ہے۔ اس کا مطلب ہے کہ ڈیولپرز اور ادارے Ethereum پر تعینات کرنے کے بعد کسی کنٹریکٹ کے کوڈ میں چھیڑ چھاڑ نہیں کر سکتے۔ + +ایک اسمارٹ کنٹریکٹ کے بھروسے سے پاک ہونے کے لیے، کنٹریکٹ کا کوڈ آزادانہ توثیق کے لیے دستیاب ہونا چاہیے۔ جبکہ ہر اسمارٹ کنٹریکٹ کے لیے کمپائل شدہ بائٹ کوڈ بلاک چین پر عوامی طور پر دستیاب ہے، نچلی سطح کی زبان کو سمجھنا مشکل ہے—ڈیولپرز اور صارفین دونوں کے لیے۔ + +پروجیکٹس اپنے کنٹریکٹس کا سورس کوڈ شائع کر کے بھروسے کے مفروضوں کو کم کرتے ہیں۔ لیکن یہ ایک اور مسئلے کا باعث بنتا ہے: اس بات کی تصدیق کرنا مشکل ہے کہ شائع شدہ سورس کوڈ کنٹریکٹ بائٹ کوڈ سے میل کھاتا ہے۔ اس منظر نامے میں، بھروسے سے پاک ہونے کی قدر ختم ہو جاتی ہے کیونکہ صارفین کو ڈیولپرز پر بھروسہ کرنا پڑتا ہے کہ وہ اسے بلاک چین پر تعینات کرنے سے پہلے کنٹریکٹ کی کاروباری منطق (یعنی، بائٹ کوڈ کو تبدیل کر کے) کو تبدیل نہیں کریں گے۔ + +سورس کوڈ کی توثیق کے ٹولز اس بات کی ضمانت فراہم کرتے ہیں کہ اسمارٹ کنٹریکٹ کی سورس کوڈ فائلیں اسمبلی کوڈ سے میل کھاتی ہیں۔ نتیجہ ایک بھروسے سے پاک ماحولیاتی نظام ہے، جہاں صارفین تیسرے فریقوں پر آنکھیں بند کر کے بھروسہ نہیں کرتے اور اس کے بجائے کنٹریکٹ میں فنڈز جمع کرنے سے پہلے کوڈ کی تصدیق کرتے ہیں۔ + +### صارف کی حفاظت {#user-safety} + +اسمارٹ کنٹریکٹس کے ساتھ، عام طور پر بہت سا پیسہ داؤ پر لگا ہوتا ہے۔ یہ اسمارٹ کنٹریکٹ کو استعمال کرنے سے پہلے اعلیٰ حفاظتی ضمانتوں اور اس کی منطق کی توثیق کا مطالبہ کرتا ہے۔ مسئلہ یہ ہے کہ بے ایمان ڈیولپرز ایک اسمارٹ کنٹریکٹ میں بدنیتی پر مبنی کوڈ داخل کر کے صارفین کو دھوکہ دے سکتے ہیں۔ توثیق کے بغیر، بدنیتی پر مبنی اسمارٹ کنٹریکٹس میں [بیک ڈورز](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts)، متنازعہ رسائی کنٹرول میکانزم، قابل استحصال کمزوریاں، اور دیگر چیزیں ہو سکتی ہیں جو صارف کی حفاظت کو خطرے میں ڈالتی ہیں جن کا پتہ نہیں چل پاتا۔ + +ایک اسمارٹ کنٹریکٹ کی سورس کوڈ فائلوں کو شائع کرنے سے دلچسپی رکھنے والوں، جیسے آڈیٹرز، کے لیے ممکنہ حملے کے ویکٹرز کے لیے کنٹریکٹ کا جائزہ لینا آسان ہو جاتا ہے۔ ایک سے زیادہ فریقوں کے آزادانہ طور پر ایک اسمارٹ کنٹریکٹ کی تصدیق کرنے سے، صارفین کو اس کی حفاظت کی مضبوط ضمانتیں ملتی ہیں۔ + +## ایتھیریم اسمارٹ کنٹریکٹس کے لیے سورس کوڈ کی تصدیق کیسے کریں {#source-code-verification-for-ethereum-smart-contracts} + +[ایتھیریم پر اسمارٹ کنٹریکٹ کو تعینات کرنے](/developers/docs/smart-contracts/deploying/) کے لیے ایک خصوصی ایڈریس پر ڈیٹا پے لوڈ (کمپائل شدہ بائٹ کوڈ) کے ساتھ ایک ٹرانزیکشن بھیجنے کی ضرورت ہوتی ہے۔ ڈیٹا پے لوڈ سورس کوڈ کو کمپائل کرنے سے پیدا ہوتا ہے، نیز کنٹریکٹ انسٹنس کے [کنسٹرکٹر آرگیومنٹس](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) جو ٹرانزیکشن میں ڈیٹا پے لوڈ میں شامل کیے جاتے ہیں۔ کمپائلیشن قطعی ہے، یعنی یہ ہمیشہ ایک ہی آؤٹ پٹ (یعنی کنٹریکٹ بائٹ کوڈ) پیدا کرتا ہے اگر وہی سورس فائلیں، اور کمپائلیشن سیٹنگز (مثلاً، کمپائلر ورژن، آپٹمائزر) استعمال کی جائیں۔ + +![ایک ڈایاگرام جو اسمارٹ کنٹریکٹ سورس کوڈ کی توثیق کو دکھا رہا ہے](./source-code-verification.png) + +ایک اسمارٹ کنٹریکٹ کی تصدیق میں بنیادی طور پر درج ذیل اقدامات شامل ہیں: + +1. سورس فائلوں اور کمپائلیشن سیٹنگز کو ایک کمپائلر میں ان پٹ کریں۔ + +2. کمپائلر کنٹریکٹ کا بائٹ کوڈ آؤٹ پٹ کرتا ہے۔ + +3. دیے گئے ایڈریس پر تعینات کردہ کنٹریکٹ کا بائٹ کوڈ حاصل کریں۔ + +4. تعینات کردہ بائٹ کوڈ کا دوبارہ کمپائل شدہ بائٹ کوڈ سے موازنہ کریں۔ اگر کوڈز میل کھاتے ہیں، تو کنٹریکٹ دیے گئے سورس کوڈ اور کمپائلیشن سیٹنگز کے ساتھ تصدیق شدہ ہو جاتا ہے۔ + +5. مزید برآں، اگر بائٹ کوڈ کے آخر میں موجود میٹا ڈیٹا ہیشز میچ ہوتے ہیں، تو یہ ایک مکمل میچ ہوگا۔ + +نوٹ کریں کہ یہ توثیق کی ایک سادہ سی تفصیل ہے اور اس میں بہت سے استثناء ہیں جو اس کے ساتھ کام نہیں کریں گے جیسے [ناقابل تغیر متغیرات](https://docs.sourcify.dev/docs/immutables/) کا ہونا۔ + +## سورس کوڈ کی توثیق کے ٹولز {#source-code-verification-tools} + +کنٹریکٹس کی تصدیق کا روایتی عمل پیچیدہ ہو سکتا ہے۔ اسی لیے ہمارے پاس Ethereum پر تعینات اسمارٹ کنٹریکٹس کے لیے سورس کوڈ کی تصدیق کے لیے ٹولز ہیں۔ یہ ٹولز سورس کوڈ کی توثیق کے بڑے حصوں کو خودکار بناتے ہیں اور صارفین کے فائدے کے لیے تصدیق شدہ کنٹریکٹس کو بھی کیوریٹ کرتے ہیں۔ + +### Etherscan {#etherscan} + +اگرچہ زیادہ تر [ایتھیریم بلاک چین ایکسپلورر](/developers/docs/data-and-analytics/block-explorers/) کے طور پر جانا جاتا ہے، Etherscan اسمارٹ کنٹریکٹ ڈیولپرز اور صارفین کے لیے ایک [سورس کوڈ کی توثیق کی خدمت](https://etherscan.io/verifyContract) بھی پیش کرتا ہے۔ + +Etherscan آپ کو اصل ڈیٹا پے لوڈ (سورس کوڈ، لائبریری ایڈریس، کمپائلر سیٹنگز، کنٹریکٹ ایڈریس، وغیرہ) سے کنٹریکٹ بائٹ کوڈ کو دوبارہ کمپائل کرنے کی اجازت دیتا ہے۔ اگر دوبارہ کمپائل شدہ بائٹ کوڈ آن چین کنٹریکٹ کے بائٹ کوڈ (اور کنسٹرکٹر پیرامیٹرز) سے وابستہ ہے، تو [کنٹریکٹ کی تصدیق ہو جاتی ہے](https://info.etherscan.com/types-of-contract-verification/)۔ + +ایک بار تصدیق ہو جانے کے بعد، آپ کے کنٹریکٹ کے سورس کوڈ کو "تصدیق شدہ" کا لیبل ملتا ہے اور اسے دوسروں کے آڈٹ کے لیے Etherscan پر شائع کیا جاتا ہے۔ اسے [تصدیق شدہ کنٹریکٹس](https://etherscan.io/contractsVerified/) سیکشن میں بھی شامل کیا جاتا ہے— جو تصدیق شدہ سورس کوڈ والے اسمارٹ کنٹریکٹس کا ایک ذخیرہ ہے۔ + +Etherscan کنٹریکٹس کی تصدیق کے لیے سب سے زیادہ استعمال ہونے والا ٹول ہے۔ تاہم، Etherscan کی کنٹریکٹ کی توثیق میں ایک خامی ہے: یہ آن چین بائٹ کوڈ اور دوبارہ کمپائل شدہ بائٹ کوڈ کے **میٹا ڈیٹا ہیش** کا موازنہ کرنے میں ناکام رہتا ہے۔ لہذا Etherscan میں میچز جزوی میچز ہوتے ہیں۔ + +[Etherscan پر کنٹریکٹس کی تصدیق کے بارے میں مزید](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327)۔ + +### Blockscout {#blockscout} + +[Blockscout](https://blockscout.com/) ایک اوپن سورس بلاک چین ایکسپلورر ہے جو اسمارٹ کنٹریکٹ ڈیولپرز اور صارفین کے لیے ایک [کنٹریکٹ کی توثیق کی خدمت](https://eth.blockscout.com/contract-verification) بھی فراہم کرتا ہے۔ ایک اوپن سورس متبادل کے طور پر، Blockscout اس بات میں شفافیت پیش کرتا ہے کہ توثیق کیسے کی جاتی ہے اور کمیونٹی کے تعاون کو توثیق کے عمل کو بہتر بنانے کے قابل بناتا ہے۔ + +دیگر توثیقی خدمات کی طرح، Blockscout آپ کو بائٹ کوڈ کو دوبارہ کمپائل کرکے اور اس کا تعینات کردہ کنٹریکٹ سے موازنہ کرکے اپنے کنٹریکٹ کے سورس کوڈ کی تصدیق کرنے کی اجازت دیتا ہے۔ ایک بار تصدیق ہو جانے کے بعد، آپ کے کنٹریکٹ کو توثیقی حیثیت ملتی ہے اور سورس کوڈ آڈیٹنگ اور تعامل کے لیے عوامی طور پر دستیاب ہو جاتا ہے۔ آسان براؤزنگ اور دریافت کے لیے تصدیق شدہ کنٹریکٹس کو Blockscout کے [تصدیق شدہ کنٹریکٹس کے ذخیرے](https://eth.blockscout.com/verified-contracts) میں بھی درج کیا جاتا ہے۔ + +### Sourcify {#sourcify} + +[Sourcify](https://sourcify.dev/#/verifier) کنٹریکٹس کی تصدیق کا ایک اور ٹول ہے جو اوپن سورس اور غیر مرکزی ہے۔ یہ ایک بلاک ایکسپلورر نہیں ہے اور صرف [مختلف EVM پر مبنی نیٹ ورکس](https://docs.sourcify.dev/docs/chains) پر کنٹریکٹس کی تصدیق کرتا ہے۔ یہ دوسرے ٹولز کے لیے اس پر تعمیر کرنے کے لیے ایک عوامی انفراسٹرکچر کے طور پر کام کرتا ہے، اور اس کا مقصد میٹا ڈیٹا فائل میں پائے جانے والے [ABI](/developers/docs/smart-contracts/compiling/#web-applications) اور [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) تبصروں کا استعمال کرکے زیادہ انسانی-دوستانہ کنٹریکٹ تعاملات کو فعال کرنا ہے۔ + +Etherscan کے برعکس، Sourcify میٹا ڈیٹا ہیش کے ساتھ مکمل میچز کی حمایت کرتا ہے۔ تصدیق شدہ کنٹریکٹس کو اس کے [عوامی ذخیرے](https://docs.sourcify.dev/docs/repository/) میں HTTP اور [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs) پر پیش کیا جاتا ہے، جو ایک غیر مرکزی، [مواد-ایڈریسڈ](https://docs.storacha.network/concepts/content-addressing/) اسٹوریج ہے۔ یہ IPFS پر کسی کنٹریکٹ کی میٹا ڈیٹا فائل حاصل کرنے کی اجازت دیتا ہے کیونکہ اضافی میٹا ڈیٹا ہیش ایک IPFS ہیش ہے۔ + +مزید برآں، کوئی IPFS پر سورس کوڈ فائلیں بھی حاصل کر سکتا ہے، کیونکہ ان فائلوں کے IPFS ہیشز بھی میٹا ڈیٹا میں پائے جاتے ہیں۔ ایک کنٹریکٹ کی تصدیق اس کی API یا [UI](https://sourcify.dev/#/verifier) پر میٹا ڈیٹا فائل اور سورس فائلیں فراہم کر کے، یا پلگ انز کا استعمال کر کے کی جا سکتی ہے۔ Sourcify مانیٹرنگ ٹول نئے بلاکس پر کنٹریکٹ کی تخلیقات کو بھی سنتا ہے اور اگر ان کی میٹا ڈیٹا اور سورس فائلیں IPFS پر شائع ہوتی ہیں تو کنٹریکٹس کی تصدیق کرنے کی کوشش کرتا ہے۔ + +[Sourcify پر کنٹریکٹس کی تصدیق کے بارے میں مزید](https://soliditylang.org/blog/2020/06/25/sourcify-faq/)۔ + +### Tenderly {#tenderly} + +[Tenderly پلیٹ فارم](https://tenderly.co/) Web3 ڈیولپرز کو اسمارٹ کنٹریکٹس بنانے، جانچنے، مانیٹر کرنے، اور چلانے کے قابل بناتا ہے۔ ڈیبگنگ ٹولز کو مشاہداتی صلاحیت اور انفراسٹرکچر بلڈنگ بلاکس کے ساتھ ملا کر، Tenderly ڈیولپرز کو اسمارٹ کنٹریکٹ ڈیولپمنٹ کو تیز کرنے میں مدد کرتا ہے۔ Tenderly کی خصوصیات کو مکمل طور پر فعال کرنے کے لیے، ڈیولپرز کو کئی طریقوں کا استعمال کرتے ہوئے [سورس کوڈ کی توثیق کرنی ہوگی](https://docs.tenderly.co/monitoring/contract-verification)۔ + +ایک کنٹریکٹ کی تصدیق نجی طور پر یا عوامی طور پر کرنا ممکن ہے۔ اگر نجی طور پر تصدیق کی گئی ہے، تو اسمارٹ کنٹریکٹ صرف آپ کو (اور آپ کے پروجیکٹ کے دیگر ممبران) کو نظر آئے گا۔ ایک کنٹریکٹ کی عوامی طور پر تصدیق کرنے سے یہ Tenderly پلیٹ فارم استعمال کرنے والے ہر شخص کو نظر آتا ہے۔ + +آپ اپنے کنٹریکٹس کی تصدیق [ڈیش بورڈ](https://docs.tenderly.co/contract-verification)، [Tenderly Hardhat پلگ ان](https://docs.tenderly.co/contract-verification/hardhat)، یا [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) کا استعمال کرتے ہوئے کر سکتے ہیں۔ + +ڈیش بورڈ کے ذریعے کنٹریکٹس کی تصدیق کرتے وقت، آپ کو Solidity کمپائلر سے تیار کردہ سورس فائل یا میٹا ڈیٹا فائل، ایڈریس/نیٹ ورک، اور کمپائلر سیٹنگز کو امپورٹ کرنے کی ضرورت ہے۔ + +Tenderly Hardhat پلگ ان کا استعمال کم محنت کے ساتھ توثیق کے عمل پر زیادہ کنٹرول کی اجازت دیتا ہے، جو آپ کو خودکار (بغیر کوڈ) اور دستی (کوڈ پر مبنی) توثیق کے درمیان انتخاب کرنے کے قابل بناتا ہے۔ + +## مزید پڑھیں {#further-reading} + +- [کنٹریکٹ سورس کوڈ کی تصدیق کرنا](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/ur/developers/docs/standards/index.md b/public/content/translations/ur/developers/docs/standards/index.md new file mode 100644 index 00000000000..aeb52534c07 --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/index.md @@ -0,0 +1,59 @@ +--- +title: "ایتھریم ڈویلپمنٹ کے معیارات" +description: "ایتھریم کے معیارات بشمول EIPs، ERC-20 اور ERC-721 جیسے ٹوکن کے معیارات، اور ڈویلپمنٹ کے کنونشنز کے بارے میں جانیں۔" +lang: ur-in +incomplete: true +--- + +## معیارات کا جائزہ {#standards-overview} + +ایتھریم کمیونٹی نے بہت سے معیارات اپنائے ہیں جو پروجیکٹس (جیسے [ایتھریم کلائنٹس](/developers/docs/nodes-and-clients/) اور والیٹس) کو مختلف امپلیمنٹیشنز میں انٹرآپریبل رکھنے میں مدد کرتے ہیں، اور اس بات کو یقینی بناتے ہیں کہ اسمارٹ کنٹریکٹس اور ڈیپس کمپوزایبل رہیں۔ + +عام طور پر، معیارات [ایتھریم امپروومنٹ پروپوزلز](/eips/) (EIPs) کے طور پر متعارف کرائے جاتے ہیں، جن پر کمیونٹی کے اراکین ایک [معیاری عمل](https://eips.ethereum.org/EIPS/eip-1) کے ذریعے تبادلہ خیال کرتے ہیں۔ + +- [EIPs کا تعارف](/eips/) +- [EIPs کی فہرست](https://eips.ethereum.org/) +- [EIP GitHub ریپو](https://github.com/ethereum/EIPs) +- [EIP ڈسکشن بورڈ](https://ethereum-magicians.org/c/eips) +- [ایتھریم گورننس کا تعارف](/governance/) +- [ایتھریم گورننس کا جائزہ](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31 مارچ، 2019 - بورس مین_ +- [ایتھریم پروٹوکول ڈویلپمنٹ گورننس اور نیٹ ورک اپ گریڈ کوآرڈینیشن](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 مارچ، 2020 - ہڈسن جیمسن_ +- [تمام ایتھریم کور ڈیو میٹنگز کی پلے لسٹ](https://www.youtube.com/@EthereumProtocol) _(یوٹیوب پلے لسٹ)_ + +## معیارات کی اقسام {#types-of-standards} + +EIPs کی 3 اقسام ہیں: + +- معیارات کا ٹریک: کسی بھی ایسی تبدیلی کو بیان کرتا ہے جو زیادہ تر یا تمام ایتھریم امپلیمنٹیشنز کو متاثر کرتی ہے۔ +- [میٹا ٹریک](https://eips.ethereum.org/meta): ایتھریم کے ارد گرد ایک عمل کی وضاحت کرتا ہے یا کسی عمل میں تبدیلی کی تجویز پیش کرتا ہے +- [معلوماتی ٹریک](https://eips.ethereum.org/informational): ایتھریم کے ڈیزائن کے کسی مسئلے کو بیان کرتا ہے یا ایتھریم کمیونٹی کو عمومی رہنما خطوط یا معلومات فراہم کرتا ہے + +مزید برآں، اسٹینڈرڈ ٹریک کو 4 زمروں میں تقسیم کیا گیا ہے: + +- [کور](https://eips.ethereum.org/core): ایسی بہتری جس کے لیے کنسینسس فورک کی ضرورت ہو +- [نیٹ ورکنگ](https://eips.ethereum.org/networking): devp2p اور لائٹ ایتھریم سب پروٹوکول کے ارد گرد بہتری، نیز وسپر اور سوارم کے نیٹ ورک پروٹوکول کی تفصیلات میں مجوزہ بہتری۔ +- [انٹرفیس](https://eips.ethereum.org/interface): کلائنٹ API/RPC کی تفصیلات اور معیارات کے ارد گرد بہتری، اور زبان کی سطح کے کچھ معیارات جیسے میتھڈ کے نام اور کنٹریکٹ ABIs۔ +- [ERC](https://eips.ethereum.org/erc): ایپلیکیشن کی سطح کے معیارات اور کنونشنز + +ان مختلف اقسام اور زمروں کے بارے میں مزید تفصیلی معلومات [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) میں مل سکتی ہیں + +### ٹوکن کے معیارات {#token-standards} + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - فنجیبل (قابل تبادلہ) ٹوکنز، جیسے ووٹنگ ٹوکنز، اسٹیکنگ ٹوکنز یا ورچوئل کرنسیوں کے لیے ایک معیاری انٹرفیس۔ + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - ایک فنجیبل ٹوکن کا معیار جو ٹوکنز کو ایتھر کی طرح برتاؤ کرتا ہے اور وصول کنندگان کی طرف سے ٹوکن کی منتقلی کو سنبھالنے میں معاونت کرتا ہے۔ + - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - ERC-20 ٹوکنز کے لیے ایک ایکسٹینشن انٹرفیس جو ایک ہی ٹرانزیکشن میں وصول کنندہ کنٹریکٹس پر کال بیک کو انجام دینے میں معاونت کرتا ہے۔ +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - نان فنجیبل ٹوکنز کے لیے ایک معیاری انٹرفیس، جیسے کسی آرٹ ورک یا گانے کی ڈیڈ۔ + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - ایک معیاری ایونٹ جو مسلسل ٹوکن شناخت کنندگان کا استعمال کرتے ہوئے ایک، یا بہت سے نان فنجیبل ٹوکنز بنانے/منتقل کرنے پر جاری ہوتا ہے۔ + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - EIP-721 کنزیومر رول کے لیے انٹرفیس ایکسٹینشن۔ + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - ERC-721 ٹوکنز میں محدود اجازتوں کے ساتھ ایک وقت تک محدود رول شامل کریں۔ +- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(تجویز کردہ نہیں)** ERC-20 سے بہتر ایک ٹوکن کا معیار۔ +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ایک ٹوکن کا معیار جس میں فنجیبل اور نان فنجیبل دونوں اثاثے شامل ہو سکتے ہیں۔ +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - ایک ٹوکنائزڈ والٹ کا معیار جو منافع بخش والٹس کے تکنیکی پیرامیٹرز کو بہتر اور یکجا کرنے کے لیے ڈیزائن کیا گیا ہے۔ + +[ٹوکن کے معیارات](/developers/docs/standards/tokens/) کے بارے میں مزید جانیں۔ + +## مزید پڑھیں {#further-reading} + +- [ایتھریم امپروومنٹ پروپوزلز (EIPs)](/eips/) + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-1155/index.md new file mode 100644 index 00000000000..05894afef44 --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-1155/index.md @@ -0,0 +1,146 @@ +--- +title: "ERC-1155 ملٹی ٹوکن اسٹینڈرڈ" +description: "ERC-1155 کے بارے میں جانیں، یہ ایک ملٹی ٹوکن اسٹینڈرڈ ہے جو فنجیبل اور نان فنجیبل ٹوکنز کو ایک ہی کنٹریکٹ میں یکجا کرتا ہے۔" +lang: ur-in +--- + +## تعارف {#introduction} + +ان کنٹریکٹس کے لیے ایک معیاری انٹرفیس جو متعدد ٹوکن اقسام کا نظم کرتے ہیں۔ ایک واحد ڈیپلائے کیے گئے کنٹریکٹ میں فنجیبل ٹوکنز، نان فنجیبل ٹوکنز یا دیگر کنفیگریشنز (مثلاً، سیمی فنجیبل ٹوکنز) کا کوئی بھی امتزاج شامل ہو سکتا ہے۔ + +**ملٹی ٹوکن اسٹینڈرڈ سے کیا مراد ہے؟** + +خیال سادہ ہے اور اس کا مقصد ایک ایسا اسمارٹ کنٹریکٹ انٹرفیس بنانا ہے جو کسی بھی تعداد میں فنجیبل اور نان فنجیبل ٹوکن اقسام کی نمائندگی اور کنٹرول کر سکے۔ اس طرح، ERC-1155 ٹوکن وہی فنکشنز انجام دے سکتا ہے جو ایک [ERC-20](/developers/docs/standards/tokens/erc-20/) اور [ERC-721](/developers/docs/standards/tokens/erc-721/) ٹوکن دیتا ہے، اور یہاں تک کہ دونوں بیک وقت بھی۔ یہ ERC-20 اور ERC-721 دونوں اسٹینڈرڈز کی فنکشنلٹی کو بہتر بناتا ہے، اسے مزید مؤثر بناتا ہے اور امپلیمنٹیشن کی واضح غلطیوں کو درست کرتا ہے۔ + +ERC-1155 ٹوکن کی مکمل تفصیل [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) میں دی گئی ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ٹوکن اسٹینڈرڈز](/developers/docs/standards/tokens/)، [ERC-20](/developers/docs/standards/tokens/erc-20/)، اور [ERC-721](/developers/docs/standards/tokens/erc-721/) کے بارے میں پڑھیں۔ + +## ERC-1155 کے فنکشنز اور خصوصیات: {#body} + +- [بیچ ٹرانسفر](#batch_transfers): ایک ہی کال میں متعدد اثاثوں کی منتقلی۔ +- [بیچ بیلنس](#batch_balance): ایک ہی کال میں متعدد اثاثوں کے بیلنس حاصل کریں۔ +- [بیچ اپروول](#batch_approval): تمام ٹوکنز کو ایک ایڈریس پر منظور کریں۔ +- [ہکس](#receive_hook): ٹوکنز موصول کرنے کا ہک۔ +- [NFT سپورٹ](#nft_support): اگر سپلائی صرف 1 ہے، تو اسے NFT سمجھیں۔ +- [محفوظ منتقلی کے قواعد](#safe_transfer_rule): محفوظ منتقلی کے لیے قواعد کا مجموعہ۔ + +### بیچ ٹرانسفرز {#batch-transfers} + +بیچ ٹرانسفر باقاعدہ ERC-20 ٹرانسفرز کی طرح ہی کام کرتا ہے۔ آئیے باقاعدہ ERC-20 `transferFrom` فنکشن پر ایک نظر ڈالتے ہیں: + +```solidity +// ERC-20 +function transferFrom(address from, address to, uint256 value) external returns (bool); + +// ERC-1155 +function safeBatchTransferFrom( + address _from, + address _to, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external; +``` + +ERC-1155 میں صرف یہی فرق ہے کہ ہم ویلیوز کو ایک ارے کے طور پر پاس کرتے ہیں اور ہم آئی ڈیز کا ایک ارے بھی پاس کرتے ہیں۔ مثال کے طور پر، اگر `ids=[3, 6, 13]` اور `values=[100, 200, 5]` دیے گئے ہیں تو، نتیجے میں ہونے والی منتقلی یہ ہوں گی + +1. `_from` سے `_to` میں 3 آئی ڈی والے 100 ٹوکنز کی منتقلی۔ +2. `_from` سے `_to` میں 6 آئی ڈی والے 200 ٹوکنز کی منتقلی۔ +3. `_from` سے `_to` میں 13 آئی ڈی والے 5 ٹوکنز کی منتقلی۔ + +ERC-1155 میں ہمارے پاس صرف `transferFrom` ہے، `transfer` نہیں۔ اسے باقاعدہ `transfer` کی طرح استعمال کرنے کے لیے، صرف 'from' ایڈریس کو اس ایڈریس پر سیٹ کریں جو فنکشن کو کال کر رہا ہے۔ + +### بیچ بیلنس {#batch-balance} + +اسی طرح متعلقہ ERC-20 `balanceOf` کال کا بھی بیچ سپورٹ کے ساتھ ایک پارٹنر فنکشن ہے۔ یاد دہانی کے طور پر، یہ ERC-20 ورژن ہے: + +```solidity +// ERC-20 +function balanceOf(address owner) external view returns (uint256); + +// ERC-1155 +function balanceOfBatch( + address[] calldata _owners, + uint256[] calldata _ids +) external view returns (uint256[] memory); +``` + +بیلنس کال کے لیے اور بھی آسان، ہم ایک ہی کال میں متعدد بیلنس حاصل کر سکتے ہیں۔ ہم مالکان کا ارے پاس کرتے ہیں، جس کے بعد ٹوکن آئی ڈیز کا ارے ہوتا ہے۔ + +مثال کے طور پر، `_ids=[3, 6, 13]` اور `_owners=[0xbeef..., 0x1337..., 0x1111...]` دیے جانے پر، ریٹرن ویلیو یہ ہوگی + +```solidity +[ + balanceOf(0xbeef...), + balanceOf(0x1337...), + balanceOf(0x1111...) +] +``` + +### بیچ اپروول {#batch-approval} + +```solidity +// ERC-1155 +function setApprovalForAll( + address _operator, + bool _approved +) external; + +function isApprovedForAll( + address _owner, + address _operator +) external view returns (bool); +``` + +اپروولز ERC-20 سے قدرے مختلف ہیں۔ مخصوص رقوم کو منظور کرنے کے بجائے، آپ `setApprovalForAll` کے ذریعے آپریٹر کو منظور شدہ یا نامنظور شدہ پر سیٹ کرتے ہیں۔ + +موجودہ اسٹیٹس کو `isApprovedForAll` کے ذریعے پڑھا جا سکتا ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، یہ ایک آل-اور-نتھنگ آپریشن ہے۔ آپ یہ وضاحت نہیں کر سکتے کہ کتنے ٹوکنز کو منظور کرنا ہے یا یہاں تک کہ کس ٹوکن کلاس کو منظور کرنا ہے۔ + +یہ جان بوجھ کر سادگی کو ذہن میں رکھتے ہوئے ڈیزائن کیا گیا ہے۔ آپ صرف ایک ایڈریس کے لیے ہر چیز کو منظور کر سکتے ہیں۔ + +### ریسیو ہک {#receive-hook} + +```solidity +function onERC1155BatchReceived( + address _operator, + address _from, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external returns(bytes4); +``` + +[EIP-165](https://eips.ethereum.org/EIPS/eip-165) سپورٹ کو دیکھتے ہوئے، ERC-1155 صرف اسمارٹ کنٹریکٹس کے لیے رسیو ہکس کو سپورٹ کرتا ہے۔ ہک فنکشن کو لازمی طور پر ایک میجک، پہلے سے طے شدہ bytes4 ویلیو واپس کرنی چاہیے جو اس طرح دی گئی ہے: + +```solidity +bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) +``` + +جب وصول کرنے والا کنٹریکٹ اس ویلیو کو واپس کرتا ہے، تو یہ سمجھا جاتا ہے کہ کنٹریکٹ ٹرانسفر کو قبول کرتا ہے اور ERC-1155 ٹوکنز کو ہینڈل کرنا جانتا ہے۔ بہترین، اب کسی کنٹریکٹ میں ٹوکنز نہیں پھنسیں گے! + +### NFT سپورٹ {#nft-support} + +جب سپلائی صرف ایک ہو، تو ٹوکن بنیادی طور پر ایک نان فنجیبل ٹوکن (NFT) ہوتا ہے۔ اور جیسا کہ ERC-721 کے لیے معیاری ہے، آپ ایک میٹا ڈیٹا URL کی وضاحت کر سکتے ہیں۔ کلائنٹس کے ذریعے یو آر ایل کو پڑھا اور اس میں ترمیم کی جا سکتی ہے، [یہاں](https://eips.ethereum.org/EIPS/eip-1155#metadata) دیکھیں۔ + +### محفوظ منتقلی کا اصول {#safe-transfer-rule} + +ہم نے پچھلی وضاحتوں میں پہلے ہی چند محفوظ منتقلی کے اصولوں پر بات کی ہے۔ لیکن آئیے سب سے اہم اصولوں پر ایک نظر ڈالتے ہیں: + +1. کالر کو `_from` ایڈریس کے لیے ٹوکنز خرچ کرنے کی منظوری ہونی چاہیے یا کالر `_from` کے برابر ہونا چاہیے۔ +2. ٹرانسفر کال کو ریورٹ ہو جانا چاہیے اگر + 1. `_to` ایڈریس 0 ہے۔ + 2. `_ids` کی لمبائی `_values` کی لمبائی کے برابر نہیں ہے۔ + 3. `_ids` میں ٹوکن (ٹوکنز) کے لیے ہولڈر (ہولڈرز) کا کوئی بھی بیلنس وصول کنندہ کو بھیجی گئی `_values` میں متعلقہ رقم (رقوم) سے کم ہے۔ + 4. کوئی اور خرابی ہوتی ہے۔ + +_نوٹ_: ہک سمیت تمام بیچ فنکشنز بغیر بیچ والے ورژن کے طور پر بھی موجود ہیں۔ یہ گیس کی کارکردگی کے لیے کیا جاتا ہے، اس بات پر غور کرتے ہوئے کہ صرف ایک اثاثہ کی منتقلی اب بھی سب سے زیادہ استعمال ہونے والا طریقہ ہوگا۔ ہم نے انہیں وضاحتوں میں سادگی کے لیے چھوڑ دیا ہے، بشمول محفوظ منتقلی کے قواعد۔ نام ایک جیسے ہیں، بس 'بیچ' کو ہٹا دیں۔ + +## مزید پڑھیں {#further-reading} + +- [EIP-1155: ملٹی ٹوکن اسٹینڈرڈ](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155: Openzeppelin Docs](https://docs.openzeppelin.com/contracts/5.x/erc1155) +- [ERC-1155: GitHub Repo](https://github.com/enjin/erc-1155) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-1363/index.md new file mode 100644 index 00000000000..85d64ee32e8 --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-1363/index.md @@ -0,0 +1,204 @@ +--- +title: "ERC-1363 قابل ادائیگی ٹوکن اسٹینڈرڈ" +description: "ERC-1363، ERC-20 ٹوکنز کے لیے ایک ایکسٹینشن انٹرفیس ہے جو ٹرانسفرز کے بعد وصول کنندہ کنٹریکٹ پر، یا منظوریوں کے بعد خرچ کرنے والے کنٹریکٹ پر، ایک ہی ٹرانزیکشن کے اندر، کسٹم لاجک کو عمل میں لانے کی حمایت کرتا ہے۔" +lang: ur-in +--- + +## تعارف {#introduction} + +### ERC-1363 کیا ہے؟ {#what-is-erc1363} + +ERC-1363، ERC-20 ٹوکنز کے لیے ایک ایکسٹینشن انٹرفیس ہے جو ٹرانسفرز کے بعد وصول کنندہ کنٹریکٹ پر، یا منظوریوں کے بعد خرچ کرنے والے کنٹریکٹ پر، ایک ہی ٹرانزیکشن کے اندر، کسٹم لاجک کو عمل میں لانے کی حمایت کرتا ہے۔ + +### ERC-20 سے فرق {#erc20-differences} + +`transfer`، `transferFrom` اور `approve` جیسے معیاری ERC-20 آپریشنز، ایک الگ ٹرانزیکشن کے بغیر وصول کنندہ یا خرچ کرنے والے کنٹریکٹ پر کوڈ کے نفاذ کی اجازت نہیں دیتے۔ +یہ UI کی ڈیولپمنٹ میں پیچیدگی اور اسے اپنانے میں رکاوٹ پیدا کرتا ہے کیونکہ صارفین کو پہلے ٹرانزیکشن کے نافذ ہونے کا انتظار کرنا پڑتا ہے اور پھر دوسرا جمع کرنا پڑتا ہے۔ +انہیں دو بار GAS بھی ادا کرنا پڑتا ہے۔ + +ERC-1363 قابل تبادلہ ٹوکنز کو زیادہ آسانی سے کارروائیاں انجام دینے اور کسی بھی آف چین لسنسر کے استعمال کے بغیر کام کرنے کے قابل بناتا ہے۔ +یہ ایک ہی ٹرانزیکشن میں، ٹرانسفر یا منظوری کے بعد، وصول کنندہ یا خرچ کرنے والے کنٹریکٹ پر کال بیک کرنے کی اجازت دیتا ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے اس کے بارے میں پڑھیں: + +- [ٹوکن معیارات](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## باڈی {#body} + +ERC-1363، `transfer`، `transferFrom` یا `approve` کے بعد اسمارٹ کنٹریکٹس کے ساتھ تعامل کرنے کے لیے ERC-20 ٹوکنز کے لیے ایک معیاری API متعارف کراتا ہے۔ + +یہ معیار ٹوکنز کو منتقل کرنے کے لیے بنیادی فعالیت فراہم کرتا ہے، ساتھ ہی ٹوکنز کو منظور کرنے کی اجازت دیتا ہے تاکہ انہیں کسی دوسرے آن چین تیسرے فریق کے ذریعے خرچ کیا جا سکے، اور پھر وصول کنندہ یا خرچ کرنے والے کنٹریکٹ پر کال بیک کیا جا سکے۔ + +اسمارٹ کنٹریکٹس کے بہت سے مجوزہ استعمالات ہیں جو ERC-20 کال بیکس کو قبول کر سکتے ہیں۔ + +مثالیں یہ ہو سکتی ہیں: + +- **کراؤڈ سیلز**: بھیجے گئے ٹوکنز فوری انعام کی تقسیم کو متحرک کرتے ہیں۔ +- **سروسز**: ادائیگی ایک مرحلے میں سروس تک رسائی کو فعال کرتی ہے۔ +- **انوائسز**: ٹوکنز خود بخود انوائسز کو سیٹل کرتے ہیں۔ +- **سبسکرپشنز**: سالانہ شرح کی منظوری پہلے مہینے کی ادائیگی کے اندر سبسکرپشن کو فعال کرتی ہے۔ + +انہی وجوہات کی بنا پر اسے اصل میں **"قابل ادائیگی ٹوکن"** کا نام دیا گیا تھا۔ + +کال بیک کا رویہ اس کی افادیت کو مزید وسعت دیتا ہے، جس سے ہموار تعاملات ممکن ہوتے ہیں جیسے: + +- **اسٹیکنگ**: منتقل کیے گئے ٹوکنز اسٹیکنگ کنٹریکٹ میں خودکار لاکنگ کو متحرک کرتے ہیں۔ +- **ووٹنگ**: موصول ہونے والے ٹوکنز گورننس سسٹم میں ووٹ رجسٹر کرتے ہیں۔ +- **سواپنگ**: ٹوکن کی منظوریاں ایک ہی مرحلے میں سواپ لاجک کو فعال کرتی ہیں۔ + +ERC-1363 ٹوکنز ان تمام صورتوں میں مخصوص یوٹیلیٹیز کے لیے استعمال کیے جا سکتے ہیں جن میں ٹرانسفر یا منظوری موصول ہونے کے بعد کال بیک کو نافذ کرنے کی ضرورت ہوتی ہے۔ +ERC-1363 وصول کنندہ کی ٹوکنز کو ہینڈل کرنے کی صلاحیت کی تصدیق کر کے اسمارٹ کنٹریکٹس میں ٹوکن کے نقصان یا ٹوکن لاکنگ سے بچنے کے لیے بھی مفید ہے۔ + +دیگر ERC-20 ایکسٹینشن تجاویز کے برعکس، ERC-1363، ERC-20 کے `transfer` اور `transferFrom` طریقوں کو اوور رائڈ نہیں کرتا ہے اور ERC-20 کے ساتھ پسماندہ مطابقت کو برقرار رکھتے ہوئے نافذ کیے جانے والے انٹرفیس IDs کی وضاحت کرتا ہے۔ + +[EIP-1363](https://eips.ethereum.org/EIPS/eip-1363) سے: + +### طریقے {#methods} + +ERC-1363 معیار کو نافذ کرنے والے اسمارٹ کنٹریکٹس کو `ERC1363` انٹرفیس کے تمام فنکشنز کے ساتھ ساتھ `ERC20` اور `ERC165` انٹرفیسز کو بھی **لازمی** طور پر نافذ کرنا چاہیے۔ + +```solidity +pragma solidity ^0.8.0; + +/** + * @title ERC1363 + * @dev ERC-20 ٹوکنز کے لیے ایک ایکسٹینشن انٹرفیس جو `transfer` یا `transferFrom` کے بعد وصول کنندہ کنٹریکٹ پر کوڈ کو نافذ کرنے، یا `approve` کے بعد خرچ کرنے والے کنٹریکٹ پر کوڈ کو نافذ کرنے کی حمایت کرتا ہے، ایک ہی ٹرانزیکشن میں۔ + */ +interface ERC1363 is ERC20, ERC165 { + /* + * نوٹ: اس انٹرفیس کے لیے ERC-165 شناخت کنندہ 0xb0202a11 ہے۔ + * 0xb0202a11 === + * bytes4(keccak256('transferAndCall(address,uint256)')) ^ + * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) + */ + + /** + * @dev کالر کے اکاؤنٹ سے `to` میں `value` کی مقدار میں ٹوکنز منتقل کرتا ہے اور پھر `to` پر `ERC1363Receiver::onTransferReceived` کو کال کرتا ہے۔ + * @param to وہ ایڈریس جس پر ٹوکنز منتقل کیے جا رہے ہیں۔ + * @param value منتقل کیے جانے والے ٹوکنز کی مقدار۔ + * @return ایک بولین ویلیو جو یہ بتاتی ہے کہ آپریشن کامیاب رہا جب تک کہ کوئی خرابی نہ ہو۔ + */ + function transferAndCall(address to, uint256 value) external returns (bool); + + /** + * @dev کالر کے اکاؤنٹ سے `to` میں `value` کی مقدار میں ٹوکنز منتقل کرتا ہے اور پھر `to` پر `ERC1363Receiver::onTransferReceived` کو کال کرتا ہے۔ + * @param to وہ ایڈریس جس پر ٹوکنز منتقل کیے جا رہے ہیں۔ + * @param value منتقل کیے جانے والے ٹوکنز کی مقدار۔ + * @param data بغیر کسی مخصوص فارمیٹ کے اضافی ڈیٹا، جو `to` کو کال میں بھیجا جاتا ہے۔ + * @return ایک بولین ویلیو جو یہ بتاتی ہے کہ آپریشن کامیاب رہا جب تک کہ کوئی خرابی نہ ہو۔ + */ + function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev الاؤنس میکانزم کا استعمال کرتے ہوئے `from` سے `to` میں `value` کی مقدار میں ٹوکنز منتقل کرتا ہے اور پھر `to` پر `ERC1363Receiver::onTransferReceived` کو کال کرتا ہے۔ + * @param from وہ ایڈریس جہاں سے ٹوکنز بھیجنے ہیں۔ + * @param to وہ ایڈریس جس پر ٹوکنز منتقل کیے جا رہے ہیں۔ + * @param value منتقل کیے جانے والے ٹوکنز کی مقدار۔ + * @return ایک بولین ویلیو جو یہ بتاتی ہے کہ آپریشن کامیاب رہا جب تک کہ کوئی خرابی نہ ہو۔ + */ + function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + + /** + * @dev الاؤنس میکانزم کا استعمال کرتے ہوئے `from` سے `to` میں `value` کی مقدار میں ٹوکنز منتقل کرتا ہے اور پھر `to` پر `ERC1363Receiver::onTransferReceived` کو کال کرتا ہے۔ + * @param from وہ ایڈریس جہاں سے ٹوکنز بھیجنے ہیں۔ + * @param to وہ ایڈریس جس پر ٹوکنز منتقل کیے جا رہے ہیں۔ + * @param value منتقل کیے جانے والے ٹوکنز کی مقدار۔ + * @param data بغیر کسی مخصوص فارمیٹ کے اضافی ڈیٹا، جو `to` کو کال میں بھیجا جاتا ہے۔ + * @return ایک بولین ویلیو جو یہ بتاتی ہے کہ آپریشن کامیاب رہا جب تک کہ کوئی خرابی نہ ہو۔ + */ + function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev کالر کے ٹوکنز پر `spender` کے الاؤنس کے طور پر `value` کی مقدار میں ٹوکنز سیٹ کرتا ہے اور پھر `spender` پر `ERC1363Spender::onApprovalReceived` کو کال کرتا ہے۔ + * @param spender وہ ایڈریس جو فنڈز خرچ کرے گا۔ + * @param value خرچ کیے جانے والے ٹوکنز کی مقدار۔ + * @return ایک بولین ویلیو جو یہ بتاتی ہے کہ آپریشن کامیاب رہا جب تک کہ کوئی خرابی نہ ہو۔ + */ + function approveAndCall(address spender, uint256 value) external returns (bool); + + /** + * @dev کالر کے ٹوکنز پر `spender` کے الاؤنس کے طور پر `value` کی مقدار میں ٹوکنز سیٹ کرتا ہے اور پھر `spender` پر `ERC1363Spender::onApprovalReceived` کو کال کرتا ہے۔ + * @param spender وہ ایڈریس جو فنڈز خرچ کرے گا۔ + * @param value خرچ کیے جانے والے ٹوکنز کی مقدار۔ + * @param data بغیر کسی مخصوص فارمیٹ کے اضافی ڈیٹا، جو `spender` کو کال میں بھیجا جاتا ہے۔ + * @return ایک بولین ویلیو جو یہ بتاتی ہے کہ آپریشن کامیاب رہا جب تک کہ کوئی خرابی نہ ہو۔ + */ + function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); +} + +interface ERC20 { + event Transfer(address indexed from, address indexed to, uint256 value); + event Approval(address indexed owner, address indexed spender, uint256 value); + function transfer(address to, uint256 value) external returns (bool); + function transferFrom(address from, address to, uint256 value) external returns (bool); + function approve(address spender, uint256 value) external returns (bool); + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function allowance(address owner, address spender) external view returns (uint256); +} + +interface ERC165 { + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} +``` + +ایک اسمارٹ کنٹریکٹ جو `transferAndCall` یا `transferFromAndCall` کے ذریعے ERC-1363 ٹوکنز کو قبول کرنا چاہتا ہے اسے **لازمی** طور پر `ERC1363Receiver` انٹرفیس کو نافذ کرنا چاہیے: + +```solidity +/** + * @title ERC1363Receiver + * @dev کسی بھی کنٹریکٹ کے لیے انٹرفیس جو ERC-1363 ٹوکن کنٹریکٹس سے `transferAndCall` یا `transferFromAndCall` کو سپورٹ کرنا چاہتا ہے۔ + */ +interface ERC1363Receiver { + /** + * @dev جب بھی ERC-1363 ٹوکنز اس کنٹریکٹ میں `operator` کے ذریعے `from` سے `ERC1363::transferAndCall` یا `ERC1363::transferFromAndCall` کے ذریعے منتقل کیے جاتے ہیں، تو یہ فنکشن کال کیا جاتا ہے۔ + * + * نوٹ: ٹرانسفر کو قبول کرنے کے لیے، اسے لازمی طور پر + * `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))` + * (یعنی 0x88a7ca5c، یا اس کا اپنا فنکشن سلیکٹر) واپس کرنا چاہیے۔ + * + * @param operator وہ ایڈریس جس نے `transferAndCall` یا `transferFromAndCall` فنکشن کو کال کیا۔ + * @param from وہ ایڈریس جہاں سے ٹوکنز منتقل کیے گئے ہیں۔ + * @param value منتقل کیے گئے ٹوکنز کی مقدار۔ + * @param data بغیر کسی مخصوص فارمیٹ کے اضافی ڈیٹا۔ + * @return `bytes4(keccak256(\"onTransferReceived(address,address,uint256,bytes)\"))` اگر ٹرانسفر کی اجازت ہو جب تک کہ کوئی خرابی نہ ہو۔ + */ + function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +ایک اسمارٹ کنٹریکٹ جو `approveAndCall` کے ذریعے ERC-1363 ٹوکنز کو قبول کرنا چاہتا ہے اسے **لازمی** طور پر `ERC1363Spender` انٹرفیس کو نافذ کرنا چاہیے: + +```solidity +/** + * @title ERC1363Spender + * @dev کسی بھی کنٹریکٹ کے لیے انٹرفیس جو ERC-1363 ٹوکن کنٹریکٹس سے `approveAndCall` کو سپورٹ کرنا چاہتا ہے۔ + */ +interface ERC1363Spender { + /** + * @dev جب بھی کوئی ERC-1363 ٹوکنز کا `owner` اس کنٹریکٹ کو `ERC1363::approveAndCall` کے ذریعے اپنے ٹوکنز خرچ کرنے کی منظوری دیتا ہے، تو یہ فنکشن کال کیا جاتا ہے۔ + * + * نوٹ: منظوری کو قبول کرنے کے لیے، اسے لازمی طور پر + * `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))` + * (یعنی 0x7b04a2d0، یا اس کا اپنا فنکشن سلیکٹر) واپس کرنا چاہیے۔ + * + * @param owner وہ ایڈریس جس نے `approveAndCall` فنکشن کو کال کیا اور پہلے ٹوکنز کا مالک تھا۔ + * @param value خرچ کیے جانے والے ٹوکنز کی مقدار۔ + * @param data بغیر کسی مخصوص فارمیٹ کے اضافی ڈیٹا۔ + * @return `bytes4(keccak256(\"onApprovalReceived(address,uint256,bytes)\"))` اگر منظوری کی اجازت ہو جب تک کہ کوئی خرابی نہ ہو۔ + */ + function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +## مزید پڑھیں {#further-reading} + +- [ERC-1363: قابل ادائیگی ٹوکن اسٹینڈرڈ](https://eips.ethereum.org/EIPS/eip-1363) +- [ERC-1363: GitHub Repo](https://github.com/vittominacori/erc1363-payable-token) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md new file mode 100644 index 00000000000..f9c80893a1b --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md @@ -0,0 +1,192 @@ +--- +title: "ERC-20 ٹوکن اسٹینڈرڈ" +description: "ERC-20 کے بارے میں جانیں، جو Ethereum پر فنجیبل ٹوکنز کا ایک اسٹینڈرڈ ہے جو انٹرآپریبل ٹوکن ایپلیکیشنز کو قابل بناتا ہے۔" +lang: ur-in +--- + +## تعارف {#introduction} + +**ٹوکن کیا ہے؟** + +ٹوکنز Ethereum میں عملی طور پر کسی بھی چیز کی نمائندگی کر سکتے ہیں: + +- ایک آن لائن پلیٹ فارم میں ساکھ کے پوائنٹس +- کسی گیم میں ایک کردار کی مہارتیں +- مالیاتی اثاثے جیسے کسی کمپنی میں ایک حصہ +- ایک فیاٹ کرنسی جیسے USD +- ایک اونس سونا +- اور مزید... + +Ethereum کی ایسی طاقتور خصوصیت کو ایک مضبوط اسٹینڈرڈ کے ذریعے سنبھالا جانا چاہیے، ہے نا؟ یہیں پر +ERC-20 اپنا کردار ادا کرتا ہے! یہ اسٹینڈرڈ ڈیولپرز کو ایسی ٹوکن ایپلیکیشنز بنانے کی اجازت دیتا ہے جو دیگر مصنوعات اور خدمات کے ساتھ انٹرآپریبل ہوں۔ ERC-20 اسٹینڈرڈ [ether](/glossary/#ether) کو اضافی فعالیت فراہم کرنے کے لیے بھی استعمال ہوتا ہے۔ + +**ERC-20 کیا ہے؟** + +ERC-20 فنجیبل ٹوکنز کے لیے ایک اسٹینڈرڈ متعارف کراتا ہے، دوسرے الفاظ میں، ان میں ایک ایسی خصوصیت ہوتی ہے جو ہر ٹوکن کو دوسرے ٹوکن کی طرح بالکل +یکساں (قسم اور قدر میں) بناتی ہے۔ مثال کے طور پر، ایک ERC-20 ٹوکن بالکل ETH کی طرح کام کرتا ہے، جس کا مطلب ہے کہ 1 ٹوکن +تمام دوسرے ٹوکنز کے برابر ہے اور ہمیشہ رہے گا۔ + +## شرائط {#prerequisites} + +- [اکاؤنٹس](/developers/docs/accounts) +- [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) +- [ٹوکن معیارات](/developers/docs/standards/tokens/) + +## باڈی {#body} + +ERC-20 (Ethereum Request for Comments 20)، جسے نومبر 2015 میں Fabian Vogelsteller نے تجویز کیا تھا، ایک ٹوکن اسٹینڈرڈ ہے جو +اسمارٹ کنٹریکٹس کے اندر ٹوکنز کے لیے ایک API کو نافذ کرتا ہے۔ + +مثال کے طور پر فعالیتیں جو ERC-20 فراہم کرتا ہے: + +- ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں ٹوکنز منتقل کرنا +- کسی اکاؤنٹ کا موجودہ ٹوکن بیلنس حاصل کرنا +- نیٹ ورک پر دستیاب ٹوکن کی کل سپلائی حاصل کرنا +- منظور کرنا کہ آیا کسی اکاؤنٹ سے ٹوکن کی ایک رقم تیسرے فریق کے اکاؤنٹ کے ذریعے خرچ کی جا سکتی ہے + +اگر کوئی اسمارٹ کنٹریکٹ مندرجہ ذیل طریقوں اور ایونٹس کو نافذ کرتا ہے تو اسے ERC-20 ٹوکن کنٹریکٹ کہا جا سکتا ہے اور، ایک بار تعینات ہونے کے بعد، یہ +Ethereum پر بنائے گئے ٹوکنز کا ٹریک رکھنے کا ذمہ دار ہوگا۔ + +[EIP-20](https://eips.ethereum.org/EIPS/eip-20) سے: + +### طریقے {#methods} + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) +function approve(address _spender, uint256 _value) public returns (bool success) +function allowance(address _owner, address _spender) public view returns (uint256 remaining) +``` + +### ایونٹس {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value) +event Approval(address indexed _owner, address indexed _spender, uint256 _value) +``` + +### مثالیں {#web3py-example} + +آئیے دیکھتے ہیں کہ Ethereum پر کسی بھی ERC-20 ٹوکن کنٹریکٹ کا معائنہ کرنے کے لیے چیزوں کو ہمارے لیے آسان بنانے کے لیے ایک اسٹینڈرڈ کتنا اہم ہے۔ +کسی بھی ERC-20 ٹوکن کا انٹرفیس بنانے کے لیے ہمیں صرف کنٹریکٹ ایپلیکیشن بائنری انٹرفیس (ABI) کی ضرورت ہے۔ جیسا کہ آپ +نیچے دیکھ سکتے ہیں ہم ایک آسان کردہ ABI استعمال کریں گے، تاکہ اسے ایک کم رگڑ والی مثال بنایا جا سکے۔ + +#### Web3.py کی مثال {#web3py-example} + +سب سے پہلے، یقینی بنائیں کہ آپ نے [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python لائبریری انسٹال کر لی ہے: + +``` +pip install web3 +``` + +```python +from web3 import Web3 + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI +weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # لپٹا ہوا ایتھر (WETH) + +acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 + +# یہ ایک ERC-20 ٹوکن کنٹریکٹ کا ایک آسان کردہ کنٹریکٹ ایپلیکیشن بائنری انٹرفیس (ABI) ہے۔ +# یہ صرف طریقوں کو ظاہر کرے گا: balanceOf(address), decimals(), symbol() اور totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'decimals', + 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) +symbol = dai_contract.functions.symbol().call() +decimals = dai_contract.functions.decimals().call() +totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals +addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# DAI +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) + +weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) +symbol = weth_contract.functions.symbol().call() +decimals = weth_contract.functions.decimals().call() +totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals +addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# WETH +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) +``` + +## معلوم مسائل {#erc20-issues} + +### ERC-20 ٹوکن وصولی کا مسئلہ {#reception-issue} + +\*\*06/20/2024 تک اس مسئلے کی وجہ سے کم از کم $83,656,418 مالیت کے ERC-20 ٹوکنز ضائع ہو چکے ہیں۔ **نوٹ کریں کہ ایک خالص ERC-20 نفاذ اس مسئلے کا شکار ہے جب تک کہ آپ ذیل میں درج کردہ اسٹینڈرڈ کے اوپر اضافی پابندیوں کا ایک سیٹ نافذ نہ کریں۔** + +جب ERC-20 ٹوکنز کسی ایسے اسمارٹ کنٹریکٹ کو بھیجے جاتے ہیں جو ERC-20 ٹوکنز کو سنبھالنے کے لیے ڈیزائن نہیں کیا گیا ہے، تو وہ ٹوکنز مستقل طور پر ضائع ہو سکتے ہیں۔ ایسا اس لیے ہوتا ہے کیونکہ وصول کرنے والے کنٹریکٹ میں آنے والے ٹوکنز کو پہچاننے یا ان کا جواب دینے کی فعالیت نہیں ہوتی ہے، اور ERC-20 اسٹینڈرڈ میں وصول کرنے والے کنٹریکٹ کو آنے والے ٹوکنز کے بارے میں مطلع کرنے کا کوئی طریقہ کار نہیں ہے۔ یہ مسئلہ جن اہم طریقوں سے شکل اختیار کرتا ہے وہ یہ ہیں: + +1. ٹوکن کی منتقلی کا طریقہ کار + +- ERC-20 ٹوکنز transfer یا transferFrom فنکشنز کا استعمال کرتے ہوئے منتقل کیے جاتے ہیں + - جب کوئی صارف ان فنکشنز کا استعمال کرتے ہوئے کسی کنٹریکٹ ایڈریس پر ٹوکن بھیجتا ہے، تو ٹوکنز اس بات سے قطع نظر منتقل ہو جاتے ہیں کہ وصول کرنے والا کنٹریکٹ انہیں سنبھالنے کے لیے ڈیزائن کیا گیا ہے یا نہیں + +2. اطلاع کی کمی + - وصول کرنے والے کنٹریکٹ کو یہ اطلاع یا کال بیک موصول نہیں ہوتا کہ اسے ٹوکنز بھیجے گئے ہیں + - اگر وصول کرنے والے کنٹریکٹ میں ٹوکنز کو سنبھالنے کا کوئی طریقہ کار نہیں ہے (مثلاً، ایک فال بیک فنکشن یا ٹوکن وصولی کو منظم کرنے کے لیے ایک مخصوص فنکشن)، تو ٹوکنز مؤثر طریقے سے کنٹریکٹ کے ایڈریس میں پھنس جاتے ہیں +3. کوئی بلٹ ان ہینڈلنگ نہیں + - ERC-20 اسٹینڈرڈ میں وصول کرنے والے کنٹریکٹس کے نفاذ کے لیے کوئی لازمی فنکشن شامل نہیں ہے، جس کی وجہ سے ایسی صورت حال پیدا ہوتی ہے جہاں بہت سے کنٹریکٹس آنے والے ٹوکنز کو مناسب طریقے سے منظم کرنے سے قاصر ہوتے ہیں + +**ممکنہ حل** + +اگرچہ ERC-20 کے ساتھ اس مسئلے کو مکمل طور پر روکنا ممکن نہیں ہے، لیکن ایسے طریقے موجود ہیں جو آخری صارف کے لیے ٹوکن کے نقصان کے امکان کو نمایاں طور پر کم کر دیں گے: + +- سب سے عام مسئلہ تب ہوتا ہے جب کوئی صارف خود ٹوکن کنٹریکٹ ایڈریس پر ٹوکن بھیجتا ہے (مثلاً، USDT ٹوکن کنٹریکٹ کے ایڈریس پر USDT جمع کرایا جاتا ہے)۔ ایسی منتقلی کی کوششوں کو واپس کرنے کے لیے `transfer(..)` فنکشن کو محدود کرنے کی سفارش کی جاتی ہے۔ `transfer(..)` فنکشن کے نفاذ کے اندر `require(_to != address(this));` چیک شامل کرنے پر غور کریں۔ +- عام طور پر `transfer(..)` فنکشن کنٹریکٹس میں ٹوکن جمع کرنے کے لیے ڈیزائن نہیں کیا گیا ہے۔ `approve(..) `& transferFrom(..)`پیٹرن اس کے بجائے کنٹریکٹس میں ERC-20 ٹوکن جمع کرنے کے لیے استعمال ہوتا ہے۔ ٹرانسفر فنکشن کو محدود کرنا ممکن ہے تاکہ اس کے ساتھ کسی بھی کنٹریکٹ میں ٹوکن جمع کرنے کی اجازت نہ دی جائے، تاہم یہ ان کنٹریکٹس کے ساتھ مطابقت کو توڑ سکتا ہے جو یہ فرض کرتے ہیں کہ ٹوکنز`trasnfer(..)` فنکشن کے ساتھ کنٹریکٹس میں جمع کیے جا سکتے ہیں (مثلاً، Uniswap لیکویڈیٹی پولز)۔ +- ہمیشہ یہ فرض کریں کہ ERC-20 ٹوکنز آپ کے کنٹریکٹ میں آ سکتے ہیں چاہے آپ کے کنٹریکٹ کو کبھی کوئی ٹوکن وصول نہ کرنا ہو۔ وصول کنندگان کی طرف سے حادثاتی ڈپازٹس کو روکنے یا مسترد کرنے کا کوئی طریقہ نہیں ہے۔ ایک ایسا فنکشن نافذ کرنے کی سفارش کی جاتی ہے جو حادثاتی طور پر جمع کیے گئے ERC-20 ٹوکنز کو نکالنے کی اجازت دے۔ +- متبادل ٹوکن اسٹینڈرڈز استعمال کرنے پر غور کریں۔ + +اس مسئلے سے کچھ متبادل اسٹینڈرڈز سامنے آئے ہیں جیسے [ERC-223](/developers/docs/standards/tokens/erc-223) یا [ERC-1363](/developers/docs/standards/tokens/erc-1363)۔ + +## مزید پڑھیں {#further-reading} + +- [EIP-20: ERC-20 ٹوکن اسٹینڈرڈ](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin - ٹوکنز](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin - ERC-20 نفاذ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy - Solidity ERC20 ٹوکنز کے لیے گائیڈ](https://www.alchemy.com/overviews/erc20-solidity) + +## دیگر فنجیبل ٹوکن اسٹینڈرڈز {#fungible-token-standards} + +- [ERC-223](/developers/docs/standards/tokens/erc-223) +- [ERC-1363](/developers/docs/standards/tokens/erc-1363) +- [ERC-777](/developers/docs/standards/tokens/erc-777) +- [ERC-4626 - ٹوکنائزڈ والٹس](/developers/docs/standards/tokens/erc-4626) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-223/index.md new file mode 100644 index 00000000000..2e3e7f9cd5e --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-223/index.md @@ -0,0 +1,198 @@ +--- +title: "ERC-223 ٹوکن کا معیار" +description: "ERC-223 فنجیبل ٹوکن کے معیار کا ایک جائزہ، یہ کیسے کام کرتا ہے، اور ERC-20 سے اس کا موازنہ۔" +lang: ur-in +--- + +## تعارف {#introduction} + +### ERC-223 کیا ہے؟ {#what-is-erc223} + +ERC-223 فنجیبل ٹوکنز کا ایک معیار ہے، جو ERC-20 معیار کی طرح ہے۔ کلیدی فرق یہ ہے کہ ERC-223 نہ صرف ٹوکن API کی وضاحت کرتا ہے بلکہ بھیجنے والے سے وصول کنندہ تک ٹوکن منتقل کرنے کی منطق کی بھی وضاحت کرتا ہے۔ یہ ایک کمیونیکیشن ماڈل پیش کرتا ہے جو وصول کنندہ کی طرف سے ٹوکن کی منتقلی کو سنبھالنے کی اجازت دیتا ہے۔ + +### ERC-20 سے فرق {#erc20-differences} + +ERC-223, ERC-20 کی کچھ حدود کو دور کرتا ہے اور ٹوکن کنٹریکٹ اور ایک ایسے کنٹریکٹ کے درمیان تعامل کا ایک نیا طریقہ متعارف کراتا ہے جو ٹوکن وصول کر سکتا ہے۔ کچھ چیزیں ہیں جو ERC-223 کے ساتھ ممکن ہیں لیکن ERC-20 کے ساتھ نہیں: + +- وصول کنندہ کی طرف سے ٹوکن کی منتقلی کو سنبھالنا: وصول کنندگان یہ پتہ لگا سکتے ہیں کہ ایک ERC-223 ٹوکن جمع کیا جا رہا ہے۔ +- غلط طریقے سے بھیجے گئے ٹوکنز کو مسترد کرنا: اگر کوئی صارف ERC-223 ٹوکنز کو ایک ایسے کنٹریکٹ میں بھیجتا ہے جسے ٹوکنز وصول نہیں کرنے چاہئیں، تو کنٹریکٹ ٹرانزیکشن کو مسترد کر سکتا ہے، جس سے ٹوکن کا نقصان رک جاتا ہے۔ +- منتقلی میں میٹا ڈیٹا: ERC-223 ٹوکنز میں میٹا ڈیٹا شامل ہو سکتا ہے، جس سے ٹوکن ٹرانزیکشنز کے ساتھ من مانی معلومات منسلک کی جا سکتی ہیں۔ + +## شرائط {#prerequisites} + +- [اکاؤنٹس](/developers/docs/accounts) +- [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) +- [ٹوکن معیارات](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## باڈی {#body} + +ERC-223 ایک ٹوکن معیار ہے جو سمارٹ کنٹریکٹس کے اندر ٹوکنز کے لیے ایک API نافذ کرتا ہے۔ یہ ان کنٹریکٹس کے لیے بھی ایک API کا اعلان کرتا ہے جنہیں ERC-223 ٹوکنز وصول کرنے ہوتے ہیں۔ وہ کنٹریکٹس جو ERC-223 رسیور API کو سپورٹ نہیں کرتے ہیں، وہ ERC-223 ٹوکنز وصول نہیں کر سکتے، جس سے صارف کی غلطی کو روکا جا سکتا ہے۔ + +اگر کوئی سمارٹ کنٹریکٹ مندرجہ ذیل طریقوں اور ایونٹس کو نافذ کرتا ہے تو اسے ERC-223 ہم آہنگ ٹوکن کنٹریکٹ کہا جا سکتا ہے۔ ایک بار تعینات ہونے کے بعد، +یہ Ethereum پر بنائے گئے ٹوکنز کا ٹریک رکھنے کا ذمہ دار ہوگا۔ + +کنٹریکٹ صرف ان فنکشنز کو رکھنے کا پابند نہیں ہے اور ایک ڈویلپر مختلف ٹوکن معیارات سے کوئی دوسری خصوصیت اس کنٹریکٹ میں شامل کر سکتا ہے۔ مثال کے طور پر، `approve` اور `transferFrom` فنکشنز ERC-223 معیار کا حصہ نہیں ہیں لیکن ضرورت پڑنے پر ان فنکشنز کو نافذ کیا جا سکتا ہے۔ + +[EIP-223](https://eips.ethereum.org/EIPS/eip-223) سے: + +### طریقے {#methods} + +ERC-223 ٹوکن کو مندرجہ ذیل طریقوں کو نافذ کرنا ہوگا: + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) +``` + +ایک کنٹریکٹ جسے ERC-223 ٹوکنز وصول کرنے ہیں، اسے مندرجہ ذیل طریقہ کو نافذ کرنا ہوگا: + +```solidity +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` + +اگر ERC-223 ٹوکنز کو ایک ایسے کنٹریکٹ میں بھیجا جاتا ہے جو `tokenReceived(..)` فنکشن کو نافذ نہیں کرتا ہے، تو منتقلی ناکام ہونی چاہئے اور ٹوکنز کو بھیجنے والے کے بیلنس سے منتقل نہیں کیا جانا چاہئے۔ + +### ایونٹس {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) +``` + +### مثالیں {#examples} + +ERC-223 ٹوکن کا API، ERC-20 کے API کی طرح ہے، لہذا UI ڈویلپمنٹ کے نقطہ نظر سے کوئی فرق نہیں ہے۔ یہاں واحد استثناء یہ ہے کہ ERC-223 ٹوکنز میں `approve` + `transferFrom` فنکشنز نہیں ہو سکتے ہیں کیونکہ یہ اس معیار کے لیے اختیاری ہیں۔ + +#### Solidity کی مثالیں {#solidity-example} + +مندرجہ ذیل مثال واضح کرتی ہے کہ ایک بنیادی ERC-223 ٹوکن کنٹریکٹ کیسے کام کرتا ہے: + +```solidity +pragma solidity ^0.8.19; +abstract contract IERC223Recipient { + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} +contract VeryBasicERC223Token { + event Transfer(address indexed from, address indexed to, uint value, bytes data); + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + mapping(address => uint256) private balances; + function name() public view returns (string memory) { return _name; } + function symbol() public view returns (string memory) {return _symbol; } + function decimals() public view returns (uint8) { return _decimals; } + function totalSupply() public view returns (uint256) { return _totalSupply; } + function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } + function isContract(address account) internal view returns (bool) { + uint256 size; + assembly { size := extcodesize(account) } + return size > 0; + } + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value, _data); + return true; + } + function transfer(address _to, uint _value) public returns (bool success){ + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value, _empty); + return true; + } +} +``` + +اب ہم چاہتے ہیں کہ ایک اور کنٹریکٹ `tokenA` کے ڈپازٹس کو قبول کرے، یہ فرض کرتے ہوئے کہ tokenA ایک ERC-223 ٹوکن ہے۔ کنٹریکٹ کو صرف tokenA کو قبول کرنا چاہئے اور کسی بھی دوسرے ٹوکن کو مسترد کرنا چاہئے۔ جب کنٹریکٹ کو tokenA موصول ہوتا ہے تو اسے ایک `Deposit()` ایونٹ جاری کرنا چاہئے اور اندرونی `deposits` متغیر کی قدر میں اضافہ کرنا چاہئے۔ + +یہاں کوڈ ہے: + +```solidity +contract RecipientContract is IERC223Recipient { + event Deposit(address whoSentTheTokens); + uint256 deposits = 0; + address tokenA; // واحد ٹوکن جسے ہم قبول کرنا چاہتے ہیں۔ + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + // یہ سمجھنا ضروری ہے کہ اس فنکشن کے اندر + // msg.sender موصول ہونے والے ٹوکن کا پتہ ہے، + // msg.value ہمیشہ 0 ہوتا ہے کیونکہ ٹوکن کنٹریکٹ زیادہ تر معاملات میں ایتھر کا مالک نہیں ہوتا یا بھیجتا نہیں ہے، + // _from ٹوکن کی منتقلی کا بھیجنے والا ہے، + // _value جمع کیے گئے ٹوکنز کی رقم ہے۔ + require(msg.sender == tokenA); + deposits += _value; + emit Deposit(_from); + } +} +``` + +## اکثر پوچھے جانے والے سوالات {#faq} + +### اگر ہم کچھ tokenB کنٹریکٹ کو بھیجیں تو کیا ہوگا؟ {#sending-tokens} + +ٹرانزیکشن ناکام ہو جائے گی، اور ٹوکنز کی منتقلی نہیں ہوگی۔ ٹوکنز بھیجنے والے کے پتے پر واپس کر دیے جائیں گے۔ + +### ہم اس کنٹریکٹ میں ڈپازٹ کیسے کر سکتے ہیں؟ {#contract-deposits} + +ERC-223 ٹوکن کے `transfer(address,uint256)` یا `transfer(address,uint256,bytes)` فنکشن کو `RecipientContract` کا پتہ بتا کر کال کریں۔ + +### اگر ہم اس کنٹریکٹ میں ERC-20 ٹوکن منتقل کریں تو کیا ہوگا؟ {#erc-20-transfers} + +اگر ایک ERC-20 ٹوکن `RecipientContract` کو بھیجا جاتا ہے، تو ٹوکنز منتقل ہو جائیں گے، لیکن منتقلی کو تسلیم نہیں کیا جائے گا (کوئی `Deposit()` ایونٹ فائر نہیں ہوگا، اور ڈپازٹس کی قدر تبدیل نہیں ہوگی)۔ ناپسندیدہ ERC-20 ڈپازٹس کو فلٹر یا روکا نہیں جا سکتا۔ + +### اگر ہم ٹوکن ڈپازٹ مکمل ہونے کے بعد کوئی فنکشن عمل میں لانا چاہتے ہیں تو کیا ہوگا؟ {#function-execution} + +ایسا کرنے کے کئی طریقے ہیں۔ اس مثال میں ہم اس طریقے پر عمل کریں گے جو ERC-223 کی منتقلی کو ایتھر کی منتقلی کے مترادف بناتا ہے: + +```solidity +contract RecipientContract is IERC223Recipient { + event Foo(); + event Bar(uint256 someNumber); + address tokenA; // واحد ٹوکن جسے ہم قبول کرنا چاہتے ہیں۔ + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + require(msg.sender == tokenA); + address(this).call(_data); // آنے والی ٹرانزیکشن کو ہینڈل کریں اور بعد میں ایک فنکشن کال کریں۔ + } + function foo() public + { + emit Foo(); + } + function bar(uint256 _someNumber) public + { + emit Bar(_someNumber); + } +} +``` + +جب `RecipientContract` کو ایک ERC-223 ٹوکن موصول ہوگا تو کنٹریکٹ ٹوکن ٹرانزیکشن کے `_data` پیرامیٹر کے طور پر انکوڈ کردہ ایک فنکشن کو عمل میں لائے گا، بالکل اسی طرح جیسے ایتھر ٹرانزیکشنز فنکشن کالز کو ٹرانزیکشن `data` کے طور پر انکوڈ کرتی ہیں۔ مزید معلومات کے لیے [ڈیٹا فیلڈ](/developers/docs/transactions/#the-data-field) پڑھیں۔ + +اوپر دی گئی مثال میں، ایک ERC-223 ٹوکن کو `transfer(address,uin256,bytes calldata _data)` فنکشن کے ساتھ `RecipientContract` کے پتے پر منتقل کیا جانا چاہئے۔ اگر ڈیٹا پیرامیٹر `0xc2985578` (`foo()` فنکشن کا دستخط) ہوگا، تو ٹوکن ڈپازٹ موصول ہونے کے بعد foo() فنکشن کو طلب کیا جائے گا اور Foo() ایونٹ فائر ہو جائے گا۔ + +پیرامیٹرز کو ٹوکن کی منتقلی کے `data` میں بھی انکوڈ کیا جا سکتا ہے، مثال کے طور پر ہم `_someNumber` کے لیے 12345 کی قدر کے ساتھ bar() فنکشن کو کال کر سکتے ہیں۔ اس صورت میں `data` کو `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` ہونا چاہئے جہاں `0x0423a132` `bar(uint256)` فنکشن کا دستخط ہے اور `00000000000000000000000000000000000000000000000000000000000004d2` بطور uint256 کے 12345 ہے۔ + +## حدود {#limitations} + +اگرچہ ERC-223, ERC-20 معیار میں پائے جانے والے کئی مسائل کو حل کرتا ہے، یہ اپنی حدود سے خالی نہیں ہے: + +- اختیار اور مطابقت: ERC-223 کو ابھی تک وسیع پیمانے پر اپنایا نہیں گیا ہے، جو موجودہ ٹولز اور پلیٹ فارمز کے ساتھ اس کی مطابقت کو محدود کر سکتا ہے۔ +- پسماندہ مطابقت: ERC-223, ERC-20 کے ساتھ پسماندہ مطابقت نہیں رکھتا، جس کا مطلب ہے کہ موجودہ ERC-20 کنٹریکٹس اور ٹولز بغیر کسی ترمیم کے ERC-223 ٹوکنز کے ساتھ کام نہیں کریں گے۔ +- گیس کی لاگت: ERC-223 کی منتقلی میں اضافی جانچ اور افعال ERC-20 ٹرانزیکشنز کے مقابلے میں گیس کی زیادہ لاگت کا باعث بن سکتے ہیں۔ + +## مزید پڑھیں {#further-reading} + +- [EIP-223: ERC-223 ٹوکن کا معیار](https://eips.ethereum.org/EIPS/eip-223) +- [ابتدائی ERC-223 تجویز](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-4626/index.md new file mode 100644 index 00000000000..14fc83b0cc4 --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-4626/index.md @@ -0,0 +1,227 @@ +--- +title: "ERC-4626 ٹوکنائزڈ والٹ اسٹینڈرڈ" +description: "ییلڈ بیرنگ والٹس کے لیے ایک اسٹینڈرڈ۔" +lang: ur-in +--- + +## تعارف {#introduction} + +ERC-4626 ییلڈ بیرنگ والٹس کے تکنیکی پیرامیٹرز کو بہتر بنانے اور متحد کرنے کا ایک اسٹینڈرڈ ہے۔ یہ ٹوکنائزڈ ییلڈ بیرنگ والٹس کے لیے ایک معیاری API فراہم کرتا ہے جو ایک واحد بنیادی ERC-20 ٹوکن کے حصص کی نمائندگی کرتے ہیں۔ ERC-4626 ERC-20 کا استعمال کرتے ہوئے ٹوکنائزڈ والٹس کے لیے ایک اختیاری ایکسٹینشن کا بھی خاکہ پیش کرتا ہے، جو ٹوکن جمع کرنے، نکالنے اور بیلنس پڑھنے کے لیے بنیادی فعالیت پیش کرتا ہے۔ + +**ییلڈ بیرنگ والٹس میں ERC-4626 کا کردار** + +لینڈنگ مارکیٹس، ایگریگیٹرز، اور بنیادی طور پر سود والے ٹوکنز صارفین کو مختلف حکمت عملیوں پر عمل کرکے اپنے کرپٹو ٹوکنز پر بہترین ییلڈ تلاش کرنے میں مدد کرتے ہیں۔ یہ حکمت عملیاں معمولی تغیر کے ساتھ کی جاتی ہیں، جو غلطی کا شکار ہوسکتی ہیں یا ترقیاتی وسائل کو ضائع کرسکتی ہیں۔ + +ییلڈ بیرنگ والٹس میں ERC-4626 انضمام کی کوششوں کو کم کرے گا اور ڈیولپرز کی جانب سے بہت کم خصوصی کوششوں کے ساتھ مختلف ایپلیکیشنز میں ییلڈ تک رسائی کو غیر مقفل کرے گا، جس سے زیادہ مستقل اور مضبوط نفاذ کے نمونے تیار ہوں گے۔ + +ERC-4626 ٹوکن کی مکمل وضاحت [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) میں کی گئی ہے۔ + +**غیر مطابقت پذیر والٹ ایکسٹینشن (ERC-7540)** + +ERC-4626 ایک حد تک ایٹمک ڈپازٹس اور ریڈیمپشنز کے لیے موزوں ہے۔ اگر حد تک پہنچ جاتی ہے، تو کوئی نیا ڈپازٹ یا ریڈیمپشن جمع نہیں کیا جا سکتا۔ یہ پابندی کسی بھی ایسے سمارٹ کنٹریکٹ سسٹم کے لیے اچھی طرح سے کام نہیں کرتی جس میں والٹ کے ساتھ انٹرفیس کرنے کے لیے غیر مطابقت پذیر کارروائیاں یا تاخیر ایک شرط ہو (مثال کے طور پر، حقیقی دنیا کے اثاثہ جات کے پروٹوکول، انڈر کولیٹرلائزڈ لینڈنگ پروٹوکول، کراس چین لینڈنگ پروٹوکول، لیکویڈ اسٹیکنگ ٹوکن، یا انشورنس سیفٹی ماڈیولز)۔ + +ERC-7540 غیر مطابقت پذیر استعمال کے معاملات کے لیے ERC-4626 والٹس کی افادیت کو بڑھاتا ہے۔ موجودہ والٹ انٹرفیس (`deposit`/`withdraw`/`mint`/`redeem`) کو غیر مطابقت پذیر درخواستوں کا دعوی کرنے کے لیے مکمل طور پر استعمال کیا جاتا ہے۔ + +ERC-7540 ایکسٹینشن کی مکمل وضاحت [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540) میں کی گئی ہے۔ + +**ملٹی اثاثہ والٹ ایکسٹینشن (ERC-7575)** + +ایک گمشدہ استعمال کا معاملہ جو ERC-4626 کے ذریعے سپورٹ نہیں کیا جاتا ہے وہ والٹس ہیں جن میں متعدد اثاثے یا انٹری پوائنٹس ہیں جیسے لیکویڈیٹی پرووائیڈر (LP) ٹوکنز۔ یہ عام طور پر بوجھل یا غیر تعمیلی ہوتے ہیں کیونکہ ERC-4626 کو خود ERC-20 ہونے کی ضرورت ہوتی ہے۔ + +ERC-7575 ERC-4626 کے نفاذ سے ERC-20 ٹوکن کے نفاذ کو بیرونی بنا کر متعدد اثاثوں والے والٹس کے لیے سپورٹ شامل کرتا ہے۔ + +ERC-7575 ایکسٹینشن کی مکمل وضاحت [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575) میں کی گئی ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ٹوکن اسٹینڈرڈز](/developers/docs/standards/tokens/) اور [ERC-20](/developers/docs/standards/tokens/erc-20/) کے بارے میں پڑھیں۔ + +## ERC-4626 کے فنکشنز اور خصوصیات: {#body} + +### طریقے {#methods} + +#### اثاثہ {#asset} + +```solidity +function asset() public view returns (address assetTokenAddress) +``` + +یہ فنکشن والٹ کے لیے اکاؤنٹنگ، ڈپازٹ کرنے اور نکالنے کے لیے استعمال ہونے والے بنیادی ٹوکن کا ایڈریس واپس کرتا ہے۔ + +#### کل اثاثے {#totalassets} + +```solidity +function totalAssets() public view returns (uint256) +``` + +یہ فنکشن والٹ کے زیر قبضہ بنیادی اثاثوں کی کل رقم واپس کرتا ہے۔ + +#### حصص میں تبدیل کریں {#convertoshares} + +```solidity +function convertToShares(uint256 assets) public view returns (uint256 shares) +``` + +یہ فنکشن `حصص` کی وہ رقم واپس کرتا ہے جو فراہم کردہ `اثاثوں` کی رقم کے بدلے والٹ کے ذریعے تبدیل کی جائے گی۔ + +#### اثاثوں میں تبدیل کریں {#convertoassets} + +```solidity +function convertToAssets(uint256 shares) public view returns (uint256 assets) +``` + +یہ فنکشن `اثاثوں` کی وہ رقم واپس کرتا ہے جو فراہم کردہ `حصص` کی رقم کے بدلے والٹ کے ذریعے تبدیل کی جائے گی۔ + +#### زیادہ سے زیادہ ڈپازٹ {#maxdeposit} + +```solidity +function maxDeposit(address receiver) public view returns (uint256 maxAssets) +``` + +یہ فنکشن بنیادی اثاثوں کی زیادہ سے زیادہ رقم واپس کرتا ہے جو ایک ہی [`deposit`](#deposit) کال میں جمع کی جا سکتی ہے، `وصول کنندہ` کے لیے بنائے گئے حصص کے ساتھ۔ + +#### ڈپازٹ کا پیش منظر {#previewdeposit} + +```solidity +function previewDeposit(uint256 assets) public view returns (uint256 shares) +``` + +یہ فنکشن صارفین کو موجودہ بلاک پر اپنے ڈپازٹ کے اثرات کی تقلید کرنے کی اجازت دیتا ہے۔ + +#### ڈپازٹ {#deposit} + +```solidity +function deposit(uint256 assets, address receiver) public returns (uint256 shares) +``` + +یہ فنکشن بنیادی ٹوکنز کے `اثاثوں` کو والٹ میں جمع کرتا ہے اور `وصول کنندہ` کو `حصص` کی ملکیت دیتا ہے۔ + +#### زیادہ سے زیادہ منٹ {#maxmint} + +```solidity +function maxMint(address receiver) public view returns (uint256 maxShares) +``` + +یہ فنکشن حصص کی زیادہ سے زیادہ رقم واپس کرتا ہے جو ایک ہی [`mint`](#mint) کال میں بنائے جا سکتے ہیں، `وصول کنندہ` کے لیے بنائے گئے حصص کے ساتھ۔ + +#### منٹ کا پیش منظر {#previewmint} + +```solidity +function previewMint(uint256 shares) public view returns (uint256 assets) +``` + +یہ فنکشن صارفین کو موجودہ بلاک پر اپنے منٹ کے اثرات کی تقلید کرنے کی اجازت دیتا ہے۔ + +#### منٹ {#mint} + +```solidity +function mint(uint256 shares, address receiver) public returns (uint256 assets) +``` + +یہ فنکشن بنیادی ٹوکنز کے `اثاثوں` کو جمع کرکے `وصول کنندہ` کو بالکل `حصص` والٹ شیئرز منٹ کرتا ہے۔ + +#### زیادہ سے زیادہ نکالنا {#maxwithdraw} + +```solidity +function maxWithdraw(address owner) public view returns (uint256 maxAssets) +``` + +یہ فنکشن بنیادی اثاثوں کی زیادہ سے زیادہ رقم واپس کرتا ہے جو ایک ہی [`withdraw`](#withdraw) کال کے ساتھ `مالک` کے بیلنس سے نکالی جا سکتی ہے۔ + +#### نکالنے کا پیش منظر {#previewwithdraw} + +```solidity +function previewWithdraw(uint256 assets) public view returns (uint256 shares) +``` + +یہ فنکشن صارفین کو موجودہ بلاک پر اپنے نکالنے کے اثرات کی تقلید کرنے کی اجازت دیتا ہے۔ + +#### نکالنا {#withdraw} + +```solidity +function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) +``` + +یہ فنکشن `مالک` سے `حصص` کو جلاتا ہے اور والٹ سے بالکل `اثاثہ` ٹوکن `وصول کنندہ` کو بھیجتا ہے۔ + +#### زیادہ سے زیادہ چھڑانا {#maxredeem} + +```solidity +function maxRedeem(address owner) public view returns (uint256 maxShares) +``` + +یہ فنکشن حصص کی زیادہ سے زیادہ رقم واپس کرتا ہے جو ایک [`redeem`](#redeem) کال کے ذریعے `مالک` کے بیلنس سے چھڑایا جا سکتا ہے۔ + +#### چھڑانے کا پیش منظر {#previewredeem} + +```solidity +function previewRedeem(uint256 shares) public view returns (uint256 assets) +``` + +یہ فنکشن صارفین کو موجودہ بلاک پر اپنے چھڑانے کے اثرات کی تقلید کرنے کی اجازت دیتا ہے۔ + +#### چھڑانا {#redeem} + +```solidity +function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) +``` + +یہ فنکشن `مالک` سے `حصص` کی ایک مخصوص تعداد کو چھڑاتا ہے اور والٹ سے بنیادی ٹوکن کے `اثاثے` `وصول کنندہ` کو بھیجتا ہے۔ + +#### کل سپلائی {#totalsupply} + +```solidity +function totalSupply() public view returns (uint256) +``` + +گردش میں موجود غیر چھڑائے گئے والٹ حصص کی کل تعداد واپس کرتا ہے۔ + +#### بیلنس {#balanceof} + +```solidity +function balanceOf(address owner) public view returns (uint256) +``` + +والٹ حصص کی کل رقم واپس کرتا ہے جو `مالک` کے پاس فی الحال ہے۔ + +### انٹرفیس کا نقشہ {#mapOfTheInterface} + +![ERC-4626 انٹرفیس کا نقشہ](./map-of-erc-4626.png) + +### ایونٹس {#events} + +#### ڈپازٹ ایونٹ + +**لازمی** طور پر خارج کیا جانا چاہیے جب ٹوکنز [`mint`](#mint) اور [`deposit`](#deposit) طریقوں کے ذریعے والٹ میں جمع کیے جاتے ہیں۔ + +```solidity +event Deposit( + address indexed sender, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +جہاں `sender` وہ صارف ہے جس نے `حصص` کے بدلے `اثاثوں` کا تبادلہ کیا، اور ان `حصص` کو `مالک` کو منتقل کیا۔ + +#### نکالنے کا ایونٹ + +**لازمی** طور پر خارج کیا جانا چاہیے جب [`redeem`](#redeem) یا [`withdraw`](#withdraw) طریقوں میں ایک جمع کنندہ کے ذریعہ والٹ سے حصص نکالے جاتے ہیں۔ + +```solidity +event Withdraw( + address indexed sender, + address indexed receiver, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +جہاں `sender` وہ صارف ہے جس نے نکالنے کو متحرک کیا اور `مالک` کی ملکیت والے `حصص` کو `اثاثوں` کے بدلے تبدیل کیا۔ `receiver` وہ صارف ہے جس نے نکالے گئے `اثاثے` وصول کیے۔ + +## مزید پڑھیں {#further-reading} + +- [EIP-4626: ٹوکنائزڈ والٹ اسٹینڈرڈ](https://eips.ethereum.org/EIPS/eip-4626) +- [ERC-4626: GitHub Repo](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-721/index.md new file mode 100644 index 00000000000..3e6153feb01 --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-721/index.md @@ -0,0 +1,248 @@ +--- +title: "ERC-721 نان فنجیبل ٹوکن اسٹینڈرڈ" +description: "ERC-721 کے بارے میں جانیں، جو نان فنجیبل ٹوکنز (NFTs) کے لیے ایک معیار ہے جو ایتھیریم پر منفرد ڈیجیٹل اثاثوں کی نمائندگی کرتے ہیں۔" +lang: ur-in +--- + +## تعارف {#introduction} + +**نان فنجیبل ٹوکن کیا ہے؟** + +ایک نان فنجیبل ٹوکن (NFT) کسی چیز یا کسی شخص کی منفرد طریقے سے شناخت کرنے کے لیے استعمال ہوتا ہے۔ اس قسم کا ٹوکن ان پلیٹ فارمز پر استعمال کے لیے بہترین ہے جو جمع کرنے والی اشیاء، رسائی کیز، لاٹری ٹکٹ، کنسرٹ اور کھیلوں کے میچوں کے لیے نمبر والی سیٹیں وغیرہ پیش کرتے ہیں۔ اس خاص قسم کے ٹوکن میں حیرت انگیز امکانات ہیں اس لیے یہ ایک مناسب معیار کا مستحق ہے، ERC-721 اسے حل کرنے کے لیے آیا ہے! + +**ERC-721 کیا ہے؟** + +ERC-721 این ایف ٹی کے لیے ایک معیار متعارف کراتا ہے، دوسرے لفظوں میں، اس قسم کا ٹوکن منفرد ہوتا ہے اور اسی اسمارٹ کنٹریکٹ کے دوسرے ٹوکن سے مختلف قیمت کا ہو سکتا ہے، شاید اس کی عمر، نایابیت یا اس کے بصری جیسی کسی اور چیز کی وجہ سے۔ +انتظار کرو، بصری؟ + +جی ہاں! تمام NFTs میں `tokenId` نامی ایک `uint256` متغیر ہوتا ہے، لہذا کسی بھی ERC-721 کنٹریکٹ کے لیے، جوڑا `contract address, uint256 tokenId` عالمی سطح پر منفرد ہونا چاہیے۔ اس نے کہا، ایک ڈی ایپ میں ایک "کنورٹر" ہوسکتا ہے جو `tokenId` کو ان پٹ کے طور پر استعمال کرتا ہے اور کسی ٹھنڈی چیز کی تصویر آؤٹ پٹ کرتا ہے، جیسے زومبیز، ہتھیار، مہارتیں یا حیرت انگیز بلیاں! + +## شرائط {#prerequisites} + +- [اکاؤنٹس](/developers/docs/accounts/) +- [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) +- [ٹوکن معیارات](/developers/docs/standards/tokens/) + +## باڈی {#body} + +ERC-721 (ایتھیریم ریکویسٹ فار کمنٹس 721)، جسے جنوری 2018 میں ولیم اینٹریکن، ڈیٹر شرلی، جیکب ایونز، نستاسیا سیکس نے تجویز کیا تھا، ایک نان فنجیبل ٹوکن اسٹینڈرڈ ہے جو اسمارٹ کنٹریکٹس کے اندر ٹوکنز کے لیے ایک API نافذ کرتا ہے۔ + +یہ ایک اکاؤنٹ سے دوسرے اکاؤنٹ میں ٹوکن منتقل کرنے، کسی اکاؤنٹ کا موجودہ ٹوکن بیلنس حاصل کرنے، کسی مخصوص ٹوکن کا مالک حاصل کرنے اور نیٹ ورک پر دستیاب ٹوکن کی کل سپلائی حاصل کرنے جیسی خصوصیات فراہم کرتا ہے۔ +ان کے علاوہ اس میں کچھ دیگر خصوصیات بھی ہیں جیسے کہ یہ منظور کرنا کہ کسی اکاؤنٹ سے ٹوکن کی رقم تیسرے فریق کے اکاؤنٹ کے ذریعے منتقل کی جا سکتی ہے۔ + +اگر کوئی اسمارٹ کنٹریکٹ درج ذیل طریقوں اور ایونٹس کو نافذ کرتا ہے تو اسے ERC-721 نان فنجیبل ٹوکن کنٹریکٹ کہا جا سکتا ہے اور، ایک بار تعینات ہونے کے بعد، یہ ایتھیریم پر بنائے گئے ٹوکنز کا ٹریک رکھنے کا ذمہ دار ہوگا۔ + +[EIP-721](https://eips.ethereum.org/EIPS/eip-721) سے: + +### طریقے {#methods} + +```solidity + function balanceOf(address _owner) external view returns (uint256); + function ownerOf(uint256 _tokenId) external view returns (address); + function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; + function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; + function transferFrom(address _from, address _to, uint256 _tokenId) external payable; + function approve(address _approved, uint256 _tokenId) external payable; + function setApprovalForAll(address _operator, bool _approved) external; + function getApproved(uint256 _tokenId) external view returns (address); + function isApprovedForAll(address _owner, address _operator) external view returns (bool); +``` + +### ایونٹس {#events} + +```solidity + event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); + event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); + event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); +``` + +### مثالیں {#web3py-example} + +آئیے دیکھتے ہیں کہ ایتھیریم پر کسی بھی ERC-721 ٹوکن کنٹریکٹ کا معائنہ کرنے کے لیے چیزوں کو آسان بنانے کے لیے ایک معیار کتنا اہم ہے۔ +ہمیں کسی بھی ERC-721 ٹوکن کا انٹرفیس بنانے کے لیے صرف کنٹریکٹ ایپلیکیشن بائنری انٹرفیس (ABI) کی ضرورت ہے۔ جیسا کہ آپ +نیچے دیکھ سکتے ہیں ہم ایک آسان کردہ ABI استعمال کریں گے، تاکہ اسے ایک کم رگڑ والی مثال بنایا جا سکے۔ + +#### Web3.py کی مثال {#web3py-example} + +سب سے پہلے، یقینی بنائیں کہ آپ نے [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python لائبریری انسٹال کر لی ہے: + +``` +pip install web3 +``` + +```python +from web3 import Web3 +from web3._utils.events import get_event_data + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # کرپٹو کٹیز کنٹریکٹ + +acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # کرپٹو کٹیز سیلز آکشن + +# یہ ایک ERC-721 NFT کنٹریکٹ کا ایک سادہ کنٹریکٹ ایپلیکیشن بائنری انٹرفیس (ABI) ہے۔ +# یہ صرف طریقوں کو ظاہر کرے گا: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'name', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'ownerOf', + 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, +] + +ck_extra_abi = [ + { + 'inputs': [], + 'name': 'pregnantKitties', + 'outputs': [{'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'name': '_kittyId', 'type': 'uint256'}], + 'name': 'isPregnant', + 'outputs': [{'name': '', 'type': 'bool'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) +name = ck_contract.functions.name().call() +symbol = ck_contract.functions.symbol().call() +kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() +print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") + +pregnant_kitties = ck_contract.functions.pregnantKitties().call() +print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") + +# منتقل شدہ کٹیز کے بارے میں معلومات حاصل کرنے کے لیے ٹرانسفر ایونٹ ABI کا استعمال۔ +tx_event_abi = { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'from', 'type': 'address'}, + {'indexed': False, 'name': 'to', 'type': 'address'}, + {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'Transfer', + 'type': 'event' +} + +# ہمیں لاگز کو فلٹر کرنے کے لیے ایونٹ کے دستخط کی ضرورت ہے۔ +event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() + +logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [event_signature] +}) + +# نوٹس: +# - اگر کوئی ٹرانسفر ایونٹ واپس نہیں آتا ہے تو بلاکس کی تعداد 120 سے بڑھا دیں۔ +# - اگر آپ کو کوئی ٹرانسفر ایونٹ نہیں ملا تو آپ یہاں سے ایک ٹوکن آئی ڈی حاصل کرنے کی کوشش بھی کر سکتے ہیں: +# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events +# ایونٹ کے لاگز کو پھیلانے کے لیے کلک کریں اور اس کے "tokenId" دلیل کو کاپی کریں۔ +recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] + +if recent_tx: + kitty_id = recent_tx[0]['tokenId'] # اوپر دیے گئے لنک سے "tokenId" کو یہاں پیسٹ کریں۔ + is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() + print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") +``` + +CryptoKitties کنٹریکٹ میں معیاری ایونٹس کے علاوہ کچھ دلچسپ ایونٹس بھی ہیں۔ + +آئیے ان میں سے دو کو چیک کریں، `Pregnant` اور `Birth`۔ + +```python +# نئی کٹیز کے بارے میں معلومات حاصل کرنے کے لیے پریگننٹ اور برتھ ایونٹس ABI کا استعمال۔ +ck_extra_events_abi = [ + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}], + 'name': 'Pregnant', + 'type': 'event' + }, + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'kittyId', 'type': 'uint256'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'genes', 'type': 'uint256'}], + 'name': 'Birth', + 'type': 'event' + }] + +# ہمیں لاگز کو فلٹر کرنے کے لیے ایونٹ کے دستخط کی ضرورت ہے۔ +ck_event_signatures = [ + w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), + w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), +] + +# یہاں ایک پریگننٹ ایونٹ ہے: +# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog +pregnant_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[0]] +}) + +recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] + +# یہاں ایک برتھ ایونٹ ہے: +# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a +birth_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[1]] +}) + +recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] +``` + +## مشہور NFTs {#popular-nfts} + +- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) ٹرانسفر حجم کے لحاظ سے ایتھیریم پر سرفہرست NFT کی فہرست دیتا ہے۔ +- [CryptoKitties](https://www.cryptokitties.co/) ایک ایسا گیم ہے جو افزائش کے قابل، جمع کرنے کے قابل، اور بہت ہی پیارے مخلوقات کے ارد گرد مرکوز ہے جسے ہم CryptoKitties کہتے ہیں۔ +- [Sorare](https://sorare.com/) ایک عالمی فینٹسی فٹ بال گیم ہے جہاں آپ محدود ایڈیشن جمع کرنے والی اشیاء جمع کر سکتے ہیں، اپنی ٹیموں کا انتظام کر سکتے ہیں اور انعامات حاصل کرنے کے لیے مقابلہ کر سکتے ہیں۔ +- [The Ethereum Name Service (ENS)](https://ens.domains/) سادہ، انسانی پڑھنے کے قابل ناموں کا استعمال کرتے ہوئے بلاک چین پر اور اس سے باہر دونوں وسائل کو ایڈریس کرنے کا ایک محفوظ اور غیر مرکزی طریقہ پیش کرتا ہے۔ +- [POAP](https://poap.xyz) ان لوگوں کو مفت NFTs فراہم کرتا ہے جو ایونٹس میں شرکت کرتے ہیں یا مخصوص کارروائیاں مکمل کرتے ہیں۔ POAPs بنانے اور تقسیم کرنے کے لیے مفت ہیں۔ +- [Unstoppable Domains](https://unstoppabledomains.com/) ایک سان فرانسسکو میں مقیم کمپنی ہے جو بلاک چینز پر ڈومینز بناتی ہے۔ بلاک چین ڈومینز کرپٹو کرنسی ایڈریسز کو انسانی پڑھنے کے قابل ناموں سے بدل دیتے ہیں اور سنسرشپ سے مزاحم ویب سائٹس کو فعال کرنے کے لیے استعمال کیے جا سکتے ہیں۔ +- [Gods Unchained Cards](https://godsunchained.com/) ایتھیریم بلاک چین پر ایک TCG ہے جو ان گیم اثاثوں کو حقیقی ملکیت دلانے کے لیے NFT's کا استعمال کرتا ہے۔ +- [Bored Ape Yacht Club](https://boredapeyachtclub.com) 10,000 منفرد NFTs کا ایک مجموعہ ہے، جو، ثابت طور پر نایاب آرٹ کا ایک ٹکڑا ہونے کے ساتھ ساتھ، کلب کے لیے ایک رکنیت ٹوکن کے طور پر کام کرتا ہے، جو ممبر کے فوائد اور فوائد فراہم کرتا ہے جو کمیونٹی کی کوششوں کے نتیجے میں وقت کے ساتھ ساتھ بڑھتے ہیں۔ + +## مزید پڑھیں {#further-reading} + +- [EIP-721: ERC-721 نان فنجیبل ٹوکن اسٹینڈرڈ](https://eips.ethereum.org/EIPS/eip-721) +- [OpenZeppelin - ERC-721 دستاویزات](https://docs.openzeppelin.com/contracts/3.x/erc721) +- [OpenZeppelin - ERC-721 نفاذ](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-777/index.md new file mode 100644 index 00000000000..7f4cb7a4410 --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-777/index.md @@ -0,0 +1,45 @@ +--- +title: "ERC-777 ٹوکن اسٹینڈرڈ" +description: "ERC-777 کے بارے میں جانیں، جو کہ ہکس کے ساتھ ایک بہتر فنجیبل ٹوکن اسٹینڈرڈ ہے، حالانکہ سیکیورٹی کے لیے ERC-20 کی سفارش کی جاتی ہے۔" +lang: ur-in +--- + +## انتباہ {#warning} + +**ERC-777 کو صحیح طریقے سے نافذ کرنا مشکل ہے، اس کی [مختلف قسم کے حملوں کے تئیں حساسیت](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620) کی وجہ سے۔** **اس کے بجائے [ERC-20](/developers/docs/standards/tokens/erc-20/) استعمال کرنے کی سفارش کی جاتی ہے۔** یہ صفحہ ایک تاریخی آرکائیو کے طور پر موجود ہے۔ + +## تعارف؟ {#introduction} + +ERC-777 ایک فنجیبل ٹوکن اسٹینڈرڈ ہے جو موجودہ [ERC-20](/developers/docs/standards/tokens/erc-20/) اسٹینڈرڈ کو بہتر بناتا ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ERC-20](/developers/docs/standards/tokens/erc-20/) کے بارے میں پڑھیں۔ + +## ERC-777، ERC-20 کے مقابلے میں کیا بہتری تجویز کرتا ہے؟ {#-erc-777-vs-erc-20} + +ERC-777، ERC-20 کے مقابلے میں درج ذیل بہتریاں فراہم کرتا ہے۔ + +### ہکس {#hooks} + +ہکس ایک فنکشن ہیں جو ایک اسمارٹ کنٹریکٹ کے کوڈ میں بیان کیے جاتے ہیں۔ جب کنٹریکٹ کے ذریعے ٹوکن بھیجے یا وصول کیے جاتے ہیں تو ہکس کو کال کیا جاتا ہے۔ یہ ایک اسمارٹ کنٹریکٹ کو آنے والے یا جانے والے ٹوکنز پر ردعمل ظاہر کرنے کی اجازت دیتا ہے۔ + +[ERC-1820](https://eips.ethereum.org/EIPS/eip-1820) اسٹینڈرڈ کا استعمال کرتے ہوئے ہکس کو رجسٹر اور دریافت کیا جاتا ہے۔ + +#### ہکس کیوں بہترین ہیں؟ {#why-are-hooks-great} + +1. ہکس ایک ہی ٹرانزیکشن میں کسی کنٹریکٹ کو ٹوکن بھیجنے اور اسے مطلع کرنے کی اجازت دیتے ہیں، [ERC-20](https://eips.ethereum.org/EIPS/eip-20) کے برعکس، جس میں یہ کرنے کے لیے ڈبل کال (`approve`/`transferFrom`) کی ضرورت ہوتی ہے۔ +2. وہ کنٹریکٹس جنہوں نے ہکس رجسٹر نہیں کیے ہیں وہ ERC-777 کے ساتھ غیر موافق ہیں۔ جب وصول کرنے والے کنٹریکٹ نے ہک رجسٹر نہیں کیا ہو تو بھیجنے والا کنٹریکٹ ٹرانزیکشن کو ختم کر دے گا۔ یہ غیر-ERC-777 اسمارٹ کنٹریکٹس میں حادثاتی منتقلیوں کو روکتا ہے۔ +3. ہکس ٹرانزیکشنز کو مسترد کر سکتے ہیں۔ + +### ڈیسیملز {#decimals} + +یہ اسٹینڈرڈ ERC-20 میں `decimals` کی وجہ سے پیدا ہونے والی الجھن کو بھی دور کرتا ہے۔ یہ وضاحت ڈیولپر کے تجربے کو بہتر بناتی ہے۔ + +### ERC-20 کے ساتھ بیک ورڈز کمپیٹیبلٹی {#backwards-compatibility-with-erc-20} + +ERC-777 کنٹریکٹس کے ساتھ اس طرح تعامل کیا جا سکتا ہے جیسے کہ وہ ERC-20 کنٹریکٹس ہوں۔ + +## مزید مطالعہ {#further-reading} + +[EIP-777: ٹوکن اسٹینڈرڈ](https://eips.ethereum.org/EIPS/eip-777) diff --git a/public/content/translations/ur/developers/docs/standards/tokens/index.md b/public/content/translations/ur/developers/docs/standards/tokens/index.md new file mode 100644 index 00000000000..2e05d803c1f --- /dev/null +++ b/public/content/translations/ur/developers/docs/standards/tokens/index.md @@ -0,0 +1,41 @@ +--- +title: "ٹوکن کے معیارات" +description: "فنجیبل اور نان فنجیبل ٹوکنز کے لیے ERC-20، ERC-721، اور ERC-1155 سمیت ایتھیریم ٹوکن کے معیارات دریافت کریں۔" +lang: ur-in +incomplete: true +--- + +## تعارف {#introduction} + +ایتھیریم کے بہت سے ڈیولپمنٹ معیارات ٹوکن انٹرفیس پر توجہ مرکوز کرتے ہیں۔ یہ معیارات اس بات کو یقینی بنانے میں مدد کرتے ہیں کہ اسمارٹ کنٹریکٹس کمپوزایبل رہیں، لہذا جب کوئی نیا پروجیکٹ کوئی ٹوکن جاری کرتا ہے، تو وہ موجودہ غیر مرکزی ایکسچینجز اور ایپلیکیشنز کے ساتھ ہم آہنگ رہتا ہے۔ + +ٹوکن کے معیارات یہ متعین کرتے ہیں کہ ٹوکنز ایتھیریم ایکو سسٹم میں کس طرح برتاؤ کرتے اور تعامل کرتے ہیں۔ وہ ڈیولپرز کے لیے نئے سرے سے پہیہ ایجاد کیے بغیر تعمیر کرنا آسان بناتے ہیں، اس بات کو یقینی بناتے ہوئے کہ ٹوکنز والیٹس، ایکسچینجز، اور DeFi پلیٹ فارمز کے ساتھ بغیر کسی رکاوٹ کے کام کریں۔ چاہے گیمنگ، گورننس، یا دیگر استعمال کے معاملات میں، یہ معیارات مستقل مزاجی فراہم کرتے ہیں اور ایتھیریم کو مزید باہم مربوط بناتے ہیں۔ + +## شرائط {#prerequisites} + +- [ایتھیریم ڈیولپمنٹ معیارات](/developers/docs/standards/) +- [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) + +## ٹوکن کے معیارات {#token-standards} + +ایتھیریم پر کچھ سب سے مقبول ٹوکن معیارات یہ ہیں: + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) - فنجیبل (قابل تبادلہ) ٹوکنز، جیسے ووٹنگ ٹوکنز، اسٹیکنگ ٹوکنز یا ورچوئل کرنسیوں کے لیے ایک معیاری انٹرفیس۔ + +### NFT معیارات {#nft-standards} + +- [ERC-721](/developers/docs/standards/tokens/erc-721/) - نان فنجیبل ٹوکنز کے لیے ایک معیاری انٹرفیس، جیسے کسی آرٹ ورک یا گانے کی ڈیڈ۔ +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 زیادہ موثر تجارت اور لین دین کو بنڈل کرنے کی اجازت دیتا ہے – اس طرح لاگت کی بچت ہوتی ہے۔ یہ ٹوکن معیار یوٹیلیٹی ٹوکنز (جیسے $BNB یا $BAT) اور کرپٹو پنکس (CryptoPunks) جیسے نان فنجیبل ٹوکنز دونوں بنانے کی اجازت دیتا ہے۔ + +[ERC](https://eips.ethereum.org/erc) تجاویز کی مکمل فہرست۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ ٹیوٹوریلز {#related-tutorials} + +- [ٹوکن انٹیگریشن چیک لسٹ](/developers/tutorials/token-integration-checklist/) _– ٹوکنز کے ساتھ تعامل کرتے وقت غور کرنے والی چیزوں کی ایک چیک لسٹ۔_ +- [ERC20 ٹوکن اسمارٹ کنٹریکٹ کو سمجھیں](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– ایتھیریم ٹیسٹ نیٹ ورک پر اپنے پہلے اسمارٹ کنٹریکٹ کو ڈیپلائے کرنے کا ایک تعارف۔_ +- [سولیڈیٹی اسمارٹ کنٹریکٹ سے ERC20 ٹوکنز کی منتقلی اور منظوری](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– سولیڈیٹی زبان کا استعمال کرتے ہوئے کسی ٹوکن کے ساتھ تعامل کرنے کے لیے اسمارٹ کنٹریکٹ کا استعمال کیسے کریں۔_ +- [ایک ERC721 مارکیٹ کا نفاذ [ایک کیسے کریں گائیڈ]](/developers/tutorials/how-to-implement-an-erc721-market/) _– ٹوکنائزڈ آئٹمز کو ایک غیر مرکزی کلاسیفائیڈ بورڈ پر فروخت کے لیے کیسے پیش کریں۔_ diff --git a/public/content/translations/ur/developers/docs/storage/index.md b/public/content/translations/ur/developers/docs/storage/index.md new file mode 100644 index 00000000000..52fdb029ef6 --- /dev/null +++ b/public/content/translations/ur/developers/docs/storage/index.md @@ -0,0 +1,216 @@ +--- +title: "غیر مرکزی اسٹوریج" +description: "غیر مرکزی اسٹوریج کیا ہے اور اسے کسی dApp میں ضم کرنے کے لیے دستیاب ٹولز کا ایک جائزہ۔" +lang: ur-in +--- + +کسی ایک کمپنی یا تنظیم کے زیر انتظام مرکزی سرور کے برعکس، غیر مرکزی اسٹوریج سسٹم صارف-آپریٹرز کے ایک پیئر-ٹو-پیئر نیٹ ورک پر مشتمل ہوتے ہیں جو مجموعی ڈیٹا کا ایک حصہ رکھتے ہیں، جس سے ایک لچکدار فائل اسٹوریج شیئرنگ سسٹم بنتا ہے۔ یہ بلاک چین پر مبنی ایپلیکیشن یا کسی بھی پیئر-ٹو-پیئر پر مبنی نیٹ ورک میں ہو سکتے ہیں۔ + +ایتھیریم خود ایک غیر مرکزی اسٹوریج سسٹم کے طور پر استعمال کیا جا سکتا ہے، اور جب تمام اسمارٹ کنٹریکٹس میں کوڈ اسٹوریج کی بات آتی ہے تو ایسا ہی ہوتا ہے۔ تاہم، جب بڑی مقدار میں ڈیٹا کی بات آتی ہے، تو ایتھیریم کو اس کے لیے ڈیزائن نہیں کیا گیا تھا۔ چین مسلسل بڑھ رہی ہے، لیکن لکھنے کے وقت، ایتھیریم چین تقریباً 500GB - 1TB ہے ([کلائنٹ پر منحصر ہے](https://etherscan.io/chartsync/chaindefault))، اور نیٹ ورک پر ہر نوڈ کو تمام ڈیٹا کو اسٹور کرنے کے قابل ہونے کی ضرورت ہے۔ اگر چین بڑی مقدار میں ڈیٹا (مثلاً 5TBs) تک پھیل جائے تو تمام نوڈس کے لیے چلتے رہنا ممکن نہیں ہوگا۔ اس کے علاوہ، [گیس](/developers/docs/gas) کی فیسوں کی وجہ سے اس قدر ڈیٹا کو مین نیٹ پر تعینات کرنے کی لاگت بہت زیادہ مہنگی ہوگی۔ + +ان پابندیوں کی وجہ سے، ہمیں بڑی مقدار میں ڈیٹا کو غیر مرکزی طریقے سے اسٹور کرنے کے لیے ایک مختلف چین یا طریقہ کار کی ضرورت ہے۔ + +غیر مرکزی اسٹوریج (dStorage) کے اختیارات کو دیکھتے وقت، ایک صارف کو کچھ چیزیں ذہن میں رکھنی چاہئیں۔ + +- استقامت کا طریقہ کار / ترغیبی ڈھانچہ +- ڈیٹا برقرار رکھنے کا نفاذ +- غیر مرکزیت +- کنسنسس + +## استقامت کا طریقہ کار / ترغیبی ڈھانچہ {#persistence-mechanism} + +### بلاک چین پر مبنی {#blockchain-based} + +ڈیٹا کے ایک ٹکڑے کو ہمیشہ کے لیے برقرار رکھنے کے لیے، ہمیں استقامت کا طریقہ کار استعمال کرنے کی ضرورت ہے۔ مثال کے طور پر، ایتھیریم پر، استقامت کا طریقہ کار یہ ہے کہ نوڈ چلاتے وقت پوری چین کا حساب رکھنا ضروری ہے۔ ڈیٹا کے نئے ٹکڑے چین کے آخر میں شامل ہو جاتے ہیں، اور یہ بڑھتا ہی رہتا ہے - جس کے لیے ہر نوڈ کو تمام ایمبیڈڈ ڈیٹا کی نقل تیار کرنے کی ضرورت ہوتی ہے۔ + +اسے **بلاک چین پر مبنی** استقامت کے نام سے جانا جاتا ہے۔ + +بلاک چین پر مبنی استقامت کے ساتھ مسئلہ یہ ہے کہ چین تمام ڈیٹا کو قابل عمل طور پر برقرار رکھنے اور اسٹور کرنے کے لیے بہت بڑی ہو سکتی ہے (مثال کے طور پر، [بہت سے ذرائع](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) کا تخمینہ ہے کہ انٹرنیٹ کو 40 زیٹابائٹس سے زیادہ اسٹوریج کی گنجائش درکار ہے)۔ + +بلاک چین میں کسی قسم کا ترغیبی ڈھانچہ بھی ہونا چاہیے۔ بلاک چین پر مبنی استقامت کے لیے، ویلیڈیٹر کو ادائیگی کی جاتی ہے۔ جب ڈیٹا چین میں شامل کیا جاتا ہے، تو ویلیڈیٹرز کو ڈیٹا شامل کرنے کے لیے ادائیگی کی جاتی ہے۔ + +بلاک چین پر مبنی استقامت والے پلیٹ فارم: + +- Ethereum +- [Arweave](https://www.arweave.org/) + +### کنٹریکٹ پر مبنی {#contract-based} + +**کنٹریکٹ پر مبنی** استقامت کا خیال یہ ہے کہ ہر نوڈ کے ذریعے ڈیٹا کی نقل تیار نہیں کی جا سکتی اور اسے ہمیشہ کے لیے اسٹور نہیں کیا جا سکتا، اور اس کے بجائے اسے کنٹریکٹ کے معاہدوں کے ساتھ برقرار رکھنا ضروری ہے۔ یہ متعدد نوڈس کے ساتھ کیے گئے معاہدے ہیں جنہوں نے ایک مدت کے لیے ڈیٹا کا ایک ٹکڑا رکھنے کا وعدہ کیا ہے۔ ڈیٹا کو برقرار رکھنے کے لیے جب بھی وہ ختم ہو جائیں تو انہیں ریفنڈ یا تجدید کرنا ضروری ہے۔ + +زیادہ تر معاملات میں، تمام ڈیٹا کو آن چین اسٹور کرنے کے بجائے، اس جگہ کا ہیش جہاں ڈیٹا ایک چین پر موجود ہے، اسٹور ہو جاتا ہے۔ اس طرح، پوری چین کو تمام ڈیٹا کو رکھنے کے لیے اسکیل کرنے کی ضرورت نہیں ہے۔ + +کنٹریکٹ پر مبنی استقامت والے پلیٹ فارم: + +- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin) +- [Skynet](https://sia.tech/) +- [Storj](https://storj.io/) +- [Züs](https://zus.network/) +- [Crust Network](https://crust.network) +- [Swarm](https://www.ethswarm.org/) +- [4EVERLAND](https://www.4everland.org/) + +### اضافی غور و فکر {#additional-consideration} + +IPFS فائلوں، ویب سائٹس، ایپلیکیشنز اور ڈیٹا کو اسٹور کرنے اور ان تک رسائی کے لیے ایک تقسیم شدہ نظام ہے۔ اس میں کوئی بلٹ ان ترغیبی اسکیم نہیں ہے، لیکن اس کے بجائے اسے طویل مدتی استقامت کے لیے اوپر دیے گئے کسی بھی کنٹریکٹ پر مبنی ترغیبی حل کے ساتھ استعمال کیا جا سکتا ہے۔ IPFS پر ڈیٹا کو برقرار رکھنے کا ایک اور طریقہ پننگ سروس کے ساتھ کام کرنا ہے، جو آپ کے لیے آپ کے ڈیٹا کو "پن" کرے گی۔ آپ اپنا IPFS نوڈ بھی چلا سکتے ہیں اور اپنے اور/یا دوسروں کے ڈیٹا کو مفت میں برقرار رکھنے کے لیے نیٹ ورک میں حصہ ڈال سکتے ہیں! + +- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/) +- [Pinata](https://www.pinata.cloud/) _(IPFS پننگ سروس)_ +- [web3.storage](https://web3.storage/) _(IPFS/Filecoin پننگ سروس)_ +- [Infura](https://infura.io/product/ipfs) _(IPFS پننگ سروس)_ +- [IPFS Scan](https://ipfs-scan.io) _(IPFS پننگ ایکسپلورر)_ +- [4EVERLAND](https://www.4everland.org/)_（IPFS پننگ سروس）_ +- [Filebase](https://filebase.com) _(IPFS پننگ سروس)_ +- [Spheron Network](https://spheron.network/) _(IPFS/Filecoin پننگ سروس)_ + +SWARM ایک غیر مرکزی ڈیٹا اسٹوریج اور تقسیم کی ٹیکنالوجی ہے جس میں اسٹوریج ترغیبی نظام اور اسٹوریج کرایہ کی قیمت کا اوریکل ہے۔ + +## ڈیٹا برقرار رکھنا {#data-retention} + +ڈیٹا کو برقرار رکھنے کے لیے، سسٹمز میں کسی قسم کا طریقہ کار ہونا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ ڈیٹا برقرار ہے۔ + +### چیلنج کا طریقہ کار {#challenge-mechanism} + +اس بات کو یقینی بنانے کے سب سے مقبول طریقوں میں سے ایک یہ ہے کہ کسی قسم کے کرپٹوگرافک چیلنج کا استعمال کیا جائے جو نوڈس کو جاری کیا جاتا ہے تاکہ یہ یقینی بنایا جا سکے کہ ان کے پاس اب بھی ڈیٹا موجود ہے۔ ایک سادہ سا Arweave کے پروف-آف-ایکسیس کو دیکھنا ہے۔ وہ نوڈس کو یہ دیکھنے کے لیے ایک چیلنج جاری کرتے ہیں کہ آیا ان کے پاس سب سے حالیہ بلاک اور ماضی میں ایک بے ترتیب بلاک دونوں پر ڈیٹا موجود ہے۔ اگر نوڈ جواب نہیں دے سکتا، تو انہیں سزا دی جاتی ہے۔ + +چیلنج کے طریقہ کار کے ساتھ dStorage کی اقسام: + +- Züs +- Skynet +- Arweave +- Filecoin +- Crust Network +- 4EVERLAND + +### غیر مرکزیت {#decentrality} + +پلیٹ فارمز کی غیر مرکزیت کی سطح کو ماپنے کے لیے کوئی بہترین ٹولز نہیں ہیں، لیکن عام طور پر، آپ ایسے ٹولز استعمال کرنا چاہیں گے جن میں KYC کی کوئی شکل نہ ہو تاکہ یہ ثبوت فراہم کیا جا سکے کہ وہ مرکزی نہیں ہیں۔ + +KYC کے بغیر غیر مرکزی ٹولز: + +- Skynet +- Arweave +- Filecoin +- IPFS +- Ethereum +- Crust Network +- 4EVERLAND + +### اتفاق رائے {#consensus} + +ان میں سے زیادہ تر ٹولز کا اپنا [کنسنسس میکانزم](/developers/docs/consensus-mechanisms/) کا ورژن ہوتا ہے لیکن عام طور پر وہ یا تو [**پروف-آف-ورک (PoW)**](/developers/docs/consensus-mechanisms/pow/) یا [**پروف-آف-اسٹیک (PoS)**](/developers/docs/consensus-mechanisms/pos/) پر مبنی ہوتے ہیں۔ + +پروف-آف-ورک پر مبنی: + +- Skynet +- Arweave + +پروف-آف-اسٹیک پر مبنی: + +- Ethereum +- Filecoin +- Züs +- Crust Network + +## متعلقہ ٹولز {#related-tools} + +**IPFS - _انٹرپلینیٹری فائل سسٹم ایتھیریم کے لیے ایک غیر مرکزی اسٹوریج اور فائل ریفرنسنگ سسٹم ہے۔_** + +- [Ipfs.io](https://ipfs.io/) +- [دستاویزات](https://docs.ipfs.io/) +- [GitHub](https://github.com/ipfs/ipfs) + +**Storj DCS - _ڈویلپرز کے لیے محفوظ، نجی، اور S3-کمپیٹیبل غیر مرکزی کلاؤڈ آبجیکٹ اسٹوریج۔_** + +- [Storj.io](https://storj.io/) +- [دستاویزات](https://docs.storj.io/) +- [GitHub](https://github.com/storj/storj) + +**Sia - _ایک ٹرس ٹلس کلاؤڈ اسٹوریج مارکیٹ پلیس بنانے کے لیے کرپٹوگرافی کا استعمال کرتا ہے، جس سے خریداروں اور فروخت کنندگان کو براہ راست لین دین کرنے کی اجازت ملتی ہے۔_** + +- [Skynet.net](https://sia.tech/) +- [دستاویزات](https://docs.sia.tech/) +- [GitHub](https://github.com/SiaFoundation/) + +**Filecoin - _Filecoin کو IPFS کے پیچھے والی ٹیم نے ہی بنایا تھا۔ یہ IPFS کے نظریات کے اوپر ایک ترغیبی لیئر ہے۔_** + +- [Filecoin.io](https://filecoin.io/) +- [دستاویزات](https://docs.filecoin.io/) +- [GitHub](https://github.com/filecoin-project/) + +**Arweave - _Arweave ڈیٹا اسٹور کرنے کے لیے ایک dStorage پلیٹ فارم ہے۔_** + +- [Arweave.org](https://www.arweave.org/) +- [دستاویزات](https://docs.arweave.org/info/) +- [Arweave](https://github.com/ArweaveTeam/arweave/) + +**Züs - _Züs شارڈنگ اور بلابرز کے ساتھ ایک پروف-آف-اسٹیک dStorage پلیٹ فارم ہے۔_** + +- [zus.network](https://zus.network/) +- [دستاویزات](https://docs.zus.network/zus-docs/) +- [GitHub](https://github.com/0chain/) + +**Crust Network - _Crust، IPFS کے اوپر ایک dStorage پلیٹ فارم ہے۔_** + +- [Crust.network](https://crust.network) +- [دستاویزات](https://wiki.crust.network) +- [GitHub](https://github.com/crustio) + +**Swarm - _ایتھیریم ویب 3 اسٹیک کے لیے ایک تقسیم شدہ اسٹوریج پلیٹ فارم اور مواد کی تقسیم کی خدمت۔_** + +- [EthSwarm.org](https://www.ethswarm.org/) +- [دستاویزات](https://docs.ethswarm.org/) +- [GitHub](https://github.com/ethersphere/) + +**OrbitDB - _IPFS کے اوپر ایک غیر مرکزی پیئر ٹو پیئر ڈیٹا بیس۔_** + +- [OrbitDB.org](https://orbitdb.org/) +- [دستاویزات](https://github.com/orbitdb/field-manual/) +- [GitHub](https://github.com/orbitdb/orbit-db/) + +**Aleph.im - _غیر مرکزی کلاؤڈ پروجیکٹ (ڈیٹا بیس، فائل اسٹوریج، کمپیوٹنگ اور DID)۔ آف-چین اور آن-چین پیئر-ٹو-پیئر ٹیکنالوجی کا ایک منفرد امتزاج۔ IPFS اور ملٹی چین مطابقت۔_** + +- [Aleph.im](https://aleph.cloud/) +- [دستاویزات](https://docs.aleph.cloud/) +- [GitHub](https://github.com/aleph-im/) + +**Ceramic - _ڈیٹا سے بھرپور اور دلچسپ ایپلیکیشنز کے لیے صارف کے زیر کنٹرول IPFS ڈیٹا بیس اسٹوریج۔_** + +- [Ceramic.network](https://ceramic.network/) +- [دستاویزات](https://developers.ceramic.network/) +- [GitHub](https://github.com/ceramicnetwork/js-ceramic/) + +**Filebase - _S3-کمپیٹیبل غیر مرکزی اسٹوریج اور جیو-ریڈنڈنٹ IPFS پننگ سروس۔ Filebase کے ذریعے IPFS پر اپ لوڈ کی گئی تمام فائلیں خود بخود دنیا بھر میں 3x نقل کے ساتھ Filebase کے انفراسٹرکچر پر پن ہو جاتی ہیں۔_** + +- [Filebase.com](https://filebase.com/) +- [دستاویزات](https://docs.filebase.com/) +- [GitHub](https://github.com/filebase) + +**4EVERLAND - _ایک ویب 3.0 کلاؤڈ کمپیوٹنگ پلیٹ فارم جو اسٹوریج، کمپیوٹ اور نیٹ ورکنگ کی بنیادی صلاحیتوں کو مربوط کرتا ہے، S3 کے ساتھ کمپیٹیبل ہے اور IPFS اور Arweave جیسے غیر مرکزی اسٹوریج نیٹ ورکس پر ہم آہنگ ڈیٹا اسٹوریج فراہم کرتا ہے۔_** + +- [4everland.org](https://www.4everland.org/) +- [دستاویزات](https://docs.4everland.org/) +- [GitHub](https://github.com/4everland) + +**Kaleido - _کلک بٹن IPFS نوڈس کے ساتھ ایک بلاک چین-ایز-اے-سروس پلیٹ فارم_** + +- [Kaleido](https://kaleido.io/) +- [دستاویزات](https://docs.kaleido.io/kaleido-services/ipfs/) +- [GitHub](https://github.com/kaleido-io) + +**Spheron Network - _Spheron ایک پلیٹ فارم-ایز-اے-سروس (PaaS) ہے جو بہترین کارکردگی کے ساتھ غیر مرکزی انفرا پر اپنی ایپلیکیشنز لانچ کرنے کے خواہاں dApps کے لیے ڈیزائن کیا گیا ہے۔ یہ آؤٹ آف دی باکس کمپیوٹ، غیر مرکزی اسٹوریج، CDN اور ویب ہوسٹنگ فراہم کرتا ہے۔_** + +- [spheron.network](https://spheron.network/) +- [دستاویزات](https://docs.spheron.network/) +- [GitHub](https://github.com/spheronFdn) + +## مزید پڑھیں {#further-reading} + +- [غیر مرکزی اسٹوریج کیا ہے؟](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_ +- [غیر مرکزی اسٹوریج کے بارے میں پانچ عام خرافات کو توڑنا](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_ + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ڈیولپمنٹ فریم ورکس](/developers/docs/frameworks/) From 790e40f8922696ad6d35d1d9ed67ec80182be601 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 17:51:00 +0000 Subject: [PATCH 2/2] fix(i18n): repair escaped bold markdown in Urdu translations Fix Crowdin artifacts where bold markers (**) were escaped or split incorrectly in composability/index.md and erc-20/index.md. --- .../developers/docs/smart-contracts/composability/index.md | 6 +++--- .../ur/developers/docs/standards/tokens/erc-20/index.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md b/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md index f065bc2236a..1f6e107e4a4 100644 --- a/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/ur/developers/docs/smart-contracts/composability/index.md @@ -19,11 +19,11 @@ incomplete: true ایتھیریم اسمارٹ کنٹریکٹس عوامی APIs کی طرح ہیں، لہذا کوئی بھی کنٹریکٹ کے ساتھ تعامل کر سکتا ہے یا اضافی فعالیت کے لیے انہیں dapps میں ضم کر سکتا ہے۔ اسمارٹ کنٹریکٹ کی ترکیب پذیری عام طور پر تین اصولوں پر کام کرتی ہے: ماڈیولریٹی، خود مختاری، اور دریافت پذیری: -**1.** ماڈیولریٹی\*\*: یہ انفرادی اجزاء کی ایک مخصوص کام انجام دینے کی صلاحیت ہے۔ ایتھیریم میں، ہر اسمارٹ کنٹریکٹ کا ایک مخصوص استعمال کا معاملہ ہوتا ہے (جیسا کہ Uniswap کی مثال میں دکھایا گیا ہے)۔ +**1. ماڈیولریٹی**: یہ انفرادی اجزاء کی ایک مخصوص کام انجام دینے کی صلاحیت ہے۔ ایتھیریم میں، ہر اسمارٹ کنٹریکٹ کا ایک مخصوص استعمال کا معاملہ ہوتا ہے (جیسا کہ Uniswap کی مثال میں دکھایا گیا ہے)۔ -**2.** خود مختاری\*\*: ترکیبی اجزاء کو آزادانہ طور پر کام کرنے کے قابل ہونا چاہیے۔ ایتھیریم میں ہر اسمارٹ کنٹریکٹ خود کار ہے اور نظام کے دوسرے حصوں پر انحصار کیے بغیر کام کر سکتا ہے۔ +**2. خود مختاری**: ترکیبی اجزاء کو آزادانہ طور پر کام کرنے کے قابل ہونا چاہیے۔ ایتھیریم میں ہر اسمارٹ کنٹریکٹ خود کار ہے اور نظام کے دوسرے حصوں پر انحصار کیے بغیر کام کر سکتا ہے۔ -**3.** دریافت پذیری\*\*: ڈیولپرز بیرونی کنٹریکٹس کو کال نہیں کر سکتے یا سافٹ ویئر لائبریریوں کو ایپلی کیشنز میں ضم نہیں کر سکتے اگر سابقہ عوامی طور پر دستیاب نہ ہوں۔ ڈیزائن کے لحاظ سے، اسمارٹ کنٹریکٹس اوپن سورس ہیں؛ کوئی بھی اسمارٹ کنٹریکٹ کو کال کر سکتا ہے یا کوڈ بیس کو فورک کر سکتا ہے۔ +**3. دریافت پذیری**: ڈیولپرز بیرونی کنٹریکٹس کو کال نہیں کر سکتے یا سافٹ ویئر لائبریریوں کو ایپلی کیشنز میں ضم نہیں کر سکتے اگر سابقہ عوامی طور پر دستیاب نہ ہوں۔ ڈیزائن کے لحاظ سے، اسمارٹ کنٹریکٹس اوپن سورس ہیں؛ کوئی بھی اسمارٹ کنٹریکٹ کو کال کر سکتا ہے یا کوڈ بیس کو فورک کر سکتا ہے۔ ## ترکیب پذیری کے فوائد {#benefits-of-composability} diff --git a/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md index f9c80893a1b..9977f6e642a 100644 --- a/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md +++ b/public/content/translations/ur/developers/docs/standards/tokens/erc-20/index.md @@ -151,7 +151,7 @@ print("Addr Balance:", addr_balance) ### ERC-20 ٹوکن وصولی کا مسئلہ {#reception-issue} -\*\*06/20/2024 تک اس مسئلے کی وجہ سے کم از کم $83,656,418 مالیت کے ERC-20 ٹوکنز ضائع ہو چکے ہیں۔ **نوٹ کریں کہ ایک خالص ERC-20 نفاذ اس مسئلے کا شکار ہے جب تک کہ آپ ذیل میں درج کردہ اسٹینڈرڈ کے اوپر اضافی پابندیوں کا ایک سیٹ نافذ نہ کریں۔** +**06/20/2024 تک اس مسئلے کی وجہ سے کم از کم $83,656,418 مالیت کے ERC-20 ٹوکنز ضائع ہو چکے ہیں۔ نوٹ کریں کہ ایک خالص ERC-20 نفاذ اس مسئلے کا شکار ہے جب تک کہ آپ ذیل میں درج کردہ اسٹینڈرڈ کے اوپر اضافی پابندیوں کا ایک سیٹ نافذ نہ کریں۔** جب ERC-20 ٹوکنز کسی ایسے اسمارٹ کنٹریکٹ کو بھیجے جاتے ہیں جو ERC-20 ٹوکنز کو سنبھالنے کے لیے ڈیزائن نہیں کیا گیا ہے، تو وہ ٹوکنز مستقل طور پر ضائع ہو سکتے ہیں۔ ایسا اس لیے ہوتا ہے کیونکہ وصول کرنے والے کنٹریکٹ میں آنے والے ٹوکنز کو پہچاننے یا ان کا جواب دینے کی فعالیت نہیں ہوتی ہے، اور ERC-20 اسٹینڈرڈ میں وصول کرنے والے کنٹریکٹ کو آنے والے ٹوکنز کے بارے میں مطلع کرنے کا کوئی طریقہ کار نہیں ہے۔ یہ مسئلہ جن اہم طریقوں سے شکل اختیار کرتا ہے وہ یہ ہیں: